테스트 케이스 제작 로직

뷰어(PostReplaceRelayout.tsx)는 eval-out/cases/*/case.json 을 import.meta.glob 으로 읽는다. 따로 등록하는 단계가 없다 — 폴더가 생기면 화면이 바로 집는다. 그래서 「케이스를 만든다」는 곧 이 폴더를 채운다는 뜻이고, 아래가 그 목록이다.

이름이 헷갈리기 쉽다 — replaced 는 「대치된」이 아니다

replaced.json 안의 sheetJson 은 대치가 안 된 원본 그대로다 — 넣을 텍스트는 nodeTextMap 에 따로 실린다. 이름의 «replaced» 는 대치 요청이 담겼다는 뜻이다.

두 함수가 하는 일은 딱 한 군데에서만 다르다 — 대치 페이로드 (replaced.json)를 만드느냐 받느냐. 그 뒤로는 같은 함수를 부르고 같은 파일을 쓴다.

1. 참조 고르기 — pickRef

componentId(= design_objects.id)와 componentKey (= design_objects.uuid)는 1:1 이 아니다. 한 key 에 적재분이 여러 개 붙는다.

2. 시그니처 매칭 — 답이 안 나오면 케이스가 성립하지 않는다

글의 구조 해시가 컴포넌트의 구조 해시와 맞아야 대치가 성립한다. parseSummaryTree(markdown) 로 요약 트리를 만들고 buildSearchVariations 가 변형들을 편다. 매칭은 두 출처를 순서대로 본다.

3. 변형 라벨 — variantLabel

라벨은 dump-sheet-json.ts·comp-replace-render.ts 와 같은 규칙으로 만든다. 네 조각을 + 로 잇고, 아무것도 없으면 base 다.

4. 대치 페이로드 — 라이브러리 기본값을 그대로 쓴다

buildContentReplacement 의 두 번째 인자를 비워서 부른다 (relieveTopBias + ensureBgMargin, 여백 12). comp-match UI 기본값과 같아야 케이스가 그 화면에서 본 것과 같은 그림이 되기 때문이다.

케이스 폴더 이름은 언제나 design_object_id(숫자) 다. 받은 폴더 이름은 그게 아닐 수 있으니 아래 순서로 찾고, 다 실패하면 멈춘다 — 틀린 폴더에 케이스를 만드는 것이 제일 나쁘다.

배치에서는 id 를 먼저 선점한다

「이미 있으면 거부」는 파일 존재 검사라, 병렬로 돌리면 같은 id 를 가리키는 두 폴더가 둘 다 통과해 뒤엣것이 앞엣것을 덮는다. MOR-2018/TC 에서 실제로 6쌍이 그렇게 겹쳐 썼다. 그래서 importCases 는 배치를 돌리기 전에 모든 폴더의 id 를 순서대로 확정하고, 먼저 온 폴더가 그 자리를 선점한다.

어느 글을 케이스로 남길지는 사람이 고를 일이지 실행 순서가 정할 일이 아니다. 건너뛴 목록은 보고에 남는다.

오토핏을 켜면 못 담을 글이 넘침이 아니라 축소로 박힌다. 5628689 실측: 원안 38.7px → 27.1px(= 70%)에 넘침 노드 0. 그 문서를 재배치에 넣으면 후보가 고칠 것을 못 찾고, 「가독성이 떨어지게 작아졌다」는 아무도 손대지 않는다. 그래서 축소를 끈 채 굽는다.

5628689 로 실측 — 같은 페이로드로 필드만 바꿔 네 번 렌더했다.

축은 셋이고 우리가 잠그는 것은 폰트 하나다

렌더까지 끝나도 케이스는 아직 채점할 수 없다. 채점이 쓰는 두 값이 문서에 없기 때문이다 — 하나는 엔진만 알고, 하나는 리소스 원본만 안다.

굽기 전의 라벨은 거짓말이다

이것이 순서를 지켜야 하는 이유다. 판정 박스가 없으면 텍스트가 전부 「못 잰 노드」가 되고, 넘침을 세는 지표는 그 노드를 판정에서 빼므로 넘침이 0 으로 잡힌다.

2026-08-28 실측 · batch/pruneCases.ts 머리말

그래서 케이스를 들인 직후 case.json 에 적힌 verdict·problems 는 못 믿는다 — 굽고 나서 label-test-cases.ts 로 다시 붙인다.

판정은 여태 사람이 따로 스크립트를 돌려야 나왔다. 케이스가 백 건을 넘고 계속 느는데 들일 때마다 손으로 확인하는 것은 곧 아무도 안 하는 일이 된다. 그래서 case.json 을 쓸 때 판정과 problems 를 같은 계산에서 채운다.

problems 세 어휘와 그 잣대

사람이 준 값이 이긴다 — 그리고 그래서 낡는다

writeCaseLabel 은 이미 채워져 있는 problems 를 그대로 둔다(keepProblems 기본 true). 눈으로 보고 붙인 라벨이 기계값에 덮이면 그 판단이 있었다는 것조차 다음 사람이 알 수 없기 때문이다. 대가가 있다.

addTestCase 도 importCase 도 이 파일을 만들지 않고, 반환값 skipped 에 그 사실만 담아 호출자가 안내하게 한다. 새 케이스는 Expected 장이 빈 상태로 뜨는 것이 정상이다.

지운 자리는 「아직 안 만듦」이 아니다

③ 이 정답을 지우면 case.json 에 expectedResult: { status: "unsolvable", reason, at } 를 적는다. 그 표시가 있는 케이스는 판정에서 UNSOLVABLE 이고, 없으면 UNKNOWN 이다.

정답 파일이 있는 45건에는 expectedResult 필드가 없다 — 지워진 적이 없다는 뜻이다.

케이스를 들이는 것만큼 빼는 것도 제작 로직이다. before 판정이 SUCCESS 인 케이스는 대치가 아무것도 망가뜨리지 않아 재배치가 고칠 것이 없다 — 어떤 후보를 넣어도 점수가 안 움직이므로 표만 길어지고 후보 사이의 차이를 희석한다.

tsx 는 레포의 전이 의존성으로만 있어 pnpm exec tsx 가 안 먹는다. 실행기를 먼저 잡는다.

batch/ 아래는 브라우저가 아니라 Node 에서 도는 코드다 (src/text-tight-box/batch·src/resource-outline/batch 와 같은 규약). 뷰어 쪽 코드는 이 폴더를 import 하지 않는다 — 브라우저는 디스크에 못 쓰니 파일을 만드는 일은 애초에 Node 몫이다. CLI 는 scripts/ 의 껍데기이고 순서와 계약은 전부 모듈에 있다.