[보관] MOR-2516 투영 규칙

2026-10-18에 확인한 현행 규약은 v0.5.6이다. mordor-wiki origin/main a0f8b01961의 §0.1이 현행 값을 명시한다. 파일명 schema-v0.5.md는 MAJOR.MINOR만 따르므로 v0.5.6에서도 그대로다.

아래 18개 사례의 version: "0.5" 입력과 기존 분석·전후 이미지는 보존했다. 정본은 이 옛 표기를 0.5.0으로 읽는다. 다만 입력의 버전 표기와 분석에 인용한 규약 판본은 다르다. 기존 대조 기준(a80aa5c097)의 schema·capability 표·JSON은 최신 main과 내용이 같아, 8개 규칙의 판정도 v0.5.6에서 유지된다.

v0.5.6에서 함께 읽을 범위: 생성기는 36종을 쓰고 enum·IIS·검색은 45종을 인식한다. 생성기는 해당 카테고리가 읽는다고 선언한 내용만 필드에 쓰며, 나머지 내용은 items에 담는다(B-33). P3는 카테고리가 바뀌는 fallback 엣지의 규칙이므로 생성이나 같은 카테고리의 슬롯 정렬에 자동 적용되는 조항으로 읽지 않는다. 생성 시점 의무·P3 적용 범위

규약 버전	변경 내용
0.5.0	종전 `0.5` 표기. 아래 보존 사례가 사용하는 입력 형식이다.
0.5.1	`component.type` 필수화. 당시 골든 470개는 이미 모두 type을 갖고 있었다.
0.5.2	type의 대분류 21값을 제거하고 결합값을 사용한다.
0.5.3	PageNavigation 4종을 enum에 반영해 인식 어휘를 41종에서 45종으로 맞췄다.
0.5.4	NestedScope의 children 필수 조건을 빼고 선택 속성 `direction: inward \| outward`를 추가했다.
0.5.5	type 필수 여부와 어휘 수의 오래된 문구를 정정했다.
0.5.6 · 현행	첫 출시 생성기에서 9종 제외(45종 중 36종). `generatable`·`generatorRedirect`와 B-33 쓰기 의무를 반영했다. 생성기 범위의 제약이며 기존 산출물을 소급해 무효로 보지 않는다.

변경 내역은 정본 §0.1 버전 이력을 요약했다. 세 자리 표기를 받고 PATCH 차이만으로 거부하지 않는 것이 규약의 검증 원칙이다.

원본 저장소에도 이전 표기가 남아 있다. 프로젝트 README는 0.5.4, 생성물 README는 0.5.1이라고 적는다. 현행 버전은 두 안내문보다 정본 §0.1의 0.5.6을 따른다.

문서와 구현의 구분: 정본 §0.1에는 버전 규칙의 “코드 반영은 아직”이라는 문구도 남아 있다. 그러나 Eregion origin/main e6ffa4bdf6의 검증 코드는 이미 0.5와 0.5.0~0.5.99를 함께 받는다. 버전 문자열을 받는 것과 개별 투영 정책의 구현·동기화 완료는 별개다.

대조 근거: 기존 a80aa5c097 → 최신 a0f8b01961에서 spec/ diff 없음. 핵심 세 파일의 Git blob도 동일하다. 이 규약 버전 대조에서는 기존 18개 사례를 재생성·재렌더하지 않았다. 별도 2.6 전수 조사에는 개별 PR의 새 비교 5쌍을 추가했다.

아래 「규칙별 통합 판단」 표의 규칙 8개에서 정할 일은 여덟 가지다. 각각 A·B·C 세 안을 놓고, 안마다 화면 글이 어떻게 바뀌고 무엇이 같이 따라오는지 적었다. 아래에서 안을 고르면 카드가 그 안의 결과로 바뀌고, 맨 아래 「선택한 조합」이 조합 전체의 화면 글·충돌·배포 영향을 다시 계산한다.

2026-10-22 작성·측정 · 모든 안을 실제로 구현해 같은 자료로 쟀다. 제안 안은 실험 사본에만 덧댔고 운영 코드는 그대로다. 썸네일은 2.6판 컴포넌트에 제품 대치(buildFrameReplacement, 글자 축소 끔)와 preview 렌더러로 그렸다. PR 상태는 2026-10-22에 다시 봤다 — #1484·#1485·#1486·#1487·#1488 모두 OPEN, head는 아래 「현재 PR head」 표와 같다.

4가지 기준으로 규칙 분석

측정	자료	무엇을 보나
후보 전수 합성 검사	2.6판 후보 212,617행(excluded=false, 2026-10-17 사본)	모든 후보에 같은 모양의 합성 질의를 넣고 실제 Rust 정렬을 돌린다. 글자 수·빈칸·내용 손실·빈 bullet 을 판끼리 비교한다. 장애율이 아니라 「이 조건이면 어디까지 닿나」를 보는 상한이다.
저장 입력 변환	생성 기록의 유효 컴포넌트 1,409개(Rust 로 못 읽는 4개 포함)	평탄화·measure 정리·질의 Frame 을 판끼리 비교한다.
fallback 엣지	Rust 어휘 45종의 fallback 130개 · 벤더 TS 122개	모든 내용 필드를 든 공통 entity 를 투영해 판끼리 비교한다. D2 는 벤더 TS 와 Rust 의 차이를 잰다.
회차 1016 재실행	판정 회차 1016 3,114행(입력 243개)	행마다 그 D.O. 하나만 든 풀로 검색해 대치 글·비용·tier 를 판끼리 비교한다. 순위는 재현하지 않는다.
전체 풀 순위	회차 1016 고유 문서 481개 + 저장 생성 기록 문서 1,305개	2.6판 212,617행 전체를 한 풀로 올려 문서마다 검색한다(top 50). 1위 후보·1위 대치 글·상위 10개 묶음·순서가 바뀐 문서를 센다. caps 레코드는 싣지 않았다(슬롯의 cap 은 있다) — 모든 판이 같은 조건이다.
생성 YAML 표 분석	회차 1013·1016 고유 YAML 972개 + 저장 YAML 1,320개	D4 전용. 머리글보다 칸이 많은 행을 세고, 사용자 원문과 맞는 칸 합치기를 찾는다.

여덟 규칙은 모두 「코드가 글 앞에 무언가를 붙인다」로 보이지만, 아래 4가지 기준으로 보면 성격이 셋으로 갈린다. 떼면 끝나는 것(키가 뜻을 싣지 않음), 떼면 뜻이 사라지는 것(키가 뜻을 실음), 애초에 글이 아닌 것(신호)이다.

「추천 조합」은 이 네 원칙을 결정마다 그대로 적용한 결과다. 원칙에 동의하지 않으면 해당 결정에서 다른 안을 고르면 되고, 그때 생기는 충돌은 맨 아래에 뜬다.

정하는 순서

결정 고르기

스크립트가 꺼져 있으면 고르기와 조합 계산은 동작하지 않는다. 아래 카드에는 모든 안이 펼쳐져 있다.

규칙	화면에 붙는 글	① 그 글자는 누가 썼나	② 키가 뜻을 싣나	③ 값이 글인가	④ 정본이 정했나	결정
1 · period·label	`period: 1009~1225`	키는 코드, 값은 사용자	아니다 — 날짜·이름이 스스로 뜻을 말한다	글이다	fallback은 P3 「이름: 값」, tier 1은 정하지 않음	D1
1 · 역할 필드(author·source·speaker·organization)	`source: 2025 고객 조사`	키는 코드, 값은 사용자	그렇다 — 누가 말했는지, 어디서 왔는지를 키가 말한다	글이다	위와 같다	D1
1b · 빈 값	`period:␣`	코드	—	값이 없다	정하지 않음	D2
2 · value	`값: 70억원`	코드	아니다	글이다	P3 (지금 어휘로는 닿지 않음)	D3
3 · 표 여분 칸	`열 3: 000원 → 000원`	코드가 머리글을 지어냈다(#1458로 해결)	—	글이지만 생성기가 쪼갰다	P4는 정하지 않음	D4
4 · 평탄화	`value: 40명`	코드	아니다	글이다	§8.7 예시 하나뿐	D5
5 · 측정값	`target: 80`	코드	그렇다 — 목표·범위·증감·임계를 키가 말한다	숫자다	fallback P5→P3, tier 1은 정하지 않음	D7
6 · 신호	`weight: 82 · emphasis: true`	코드	—	아니다(true·0.8·a.png). 다만 weight가 유일한 수치일 때가 있다	§2·§3.5는 옮긴다	D6
7 · 관계	`비교: 설명 → 설명`	코드(#1458로 해결)	아니다	글이다	P7 — desc만, tier 1에는 안 돈다	D8

문자열 필드의 키 이름

규칙 1 ↓ · #1487 · MOR-2770 · MOR-2820 D7

쟁점 · 후보에 그 필드 자리가 없으면 tier 1 정렬(pass 2)과 fallback 투영 P3가 값을 items로 옮기면서 period:·label:·author: 같은 필드 키를 앞에 붙인다. 판정 회차 1016에서 49행(입력 16개)이 이렇게 나왔고, 판정 모델도 「연도 텍스트 앞에 'period:'가 추가」라고 짚었다.

왜 갈리나 · 키는 영어 식별자라 사용자에게는 잡음이다. 그런데 정본 P3는 fallback에 「이름: 값」을 정해 뒀고, author·source처럼 키가 역할을 말하는 필드는 키를 떼면 누가 말했는지, 어디서 왔는지가 사라진다. 원칙 ㄱ과 ㄴ이 이 규칙 안에서 갈린다.

D1 선택A 값만 남긴다B 성격으로 나눈다 추천C 지금대로 둔다

추천 B · 원칙 ㄱ·ㄴ을 그대로 따르는 안이다. 실측에서 지금 데이터의 결과는 A와 한 글자도 다르지 않았다(회차 49행·전체 풀 순위 모두 같다). 더 드는 것은 표시 이름 표와 합성 후보 전수 기준 글자 수 +6.7M(A가 줄인 양의 28%)이다.

A 모든 문자열 필드에서 값만 남긴다 (#1487 그대로) 실측

지금 main

* 최초의 장기 안정 왕조
* period: 1009~1225

label: 해당 악기의 GAIN, LEVEL 올리기

author: 김민지
source: 2025 고객 조사

A를 고르면

* 최초의 장기 안정 왕조
* 1009~1225

해당 악기의 GAIN, LEVEL 올리기

김민지
2025 고객 조사

역할 필드 · 2.6판 13556260 Group_8 · QuoteTestimonial → HighlightedMessage(tier 2), 합성 문서

역할 필드 · 2.6판 13556260 Group_8 · 지금 main — 지금 main

역할 필드 · 2.6판 13556260 Group_8 · A · #1487 — A · #1487

결과

회차 1016 재실행 3,114행 중 49행(입력 15개)에서 키가 사라진다. 전체 풀 순위에서 회차 문서 481개 중 56개, 저장 문서 1,301개 중 137개의 후보 글이 바뀌었고, 1위 대치 글이 바뀐 문서는 7개·24개, 1위 후보 자체가 바뀐 문서는 0개·4개다. 저장 입력 질의 Frame 24/1,409개, fallback 엣지 15/130개가 바뀐다. 후보 212,617행 합성 검사에서 205,652행의 글이 짧아졌고(−24.3M자) 내용 손실·빈칸은 늘지 않았다.

부작용

작성자와 출처가 한 본문에 모이면 둘을 구분할 수 없다 — 아래 썸네일의 「김민지 · 2025 고객 만족도 조사」. 실제 데이터에는 역할 필드가 0건이라 합성 문서로 그렸다.
fallback 에서 정본 P3와 달라진다. 정본과 Eregion 을 고치기 전까지 TS(Eregion 벤더)와 Rust 결과가 갈린다(엣지 15개).
글이 짧아져 저장 문서 4개에서 1위 후보가 바뀌었다. 검색 결과가 바뀌는 변경이다.
공백뿐인 값은 빈 bullet 로 남는다 — D2 의 C 썸네일. D2에서 막아야 한다.

할 일

#1487 머지 · MOR-2770 P3 개정·Eregion · MOR-2776 대조 · 규약 변경: P3 「값만」 개정 · 검색 결과가 바뀐다

B period·label은 값만, 역할 필드(author·source·speaker·organization)는 사람 말 이름을 붙인다 실측추천

지금 main

* 최초의 장기 안정 왕조
* period: 1009~1225

label: 해당 악기의 GAIN, LEVEL 올리기

author: 김민지
source: 2025 고객 조사

B를 고르면

* 최초의 장기 안정 왕조
* 1009~1225

해당 악기의 GAIN, LEVEL 올리기

작성자 김민지
출처 2025 고객 조사

역할 필드 · 2.6판 13556260 Group_8 · QuoteTestimonial → HighlightedMessage(tier 2), 합성 문서

역할 필드 · 2.6판 13556260 Group_8 · B · 표시 이름 — B · 표시 이름

결과

지금 데이터에서는 A와 결과가 같다. 회차 49행·전체 풀 순위(회차 481·저장 1,301 문서)·저장 입력 변환 1,409개 모두 A와 차이 0이다 — 실제 입력에 author·source·speaker·organization 이 한 건도 없다. 차이는 역할 필드가 있을 때만 난다: fallback 엣지 130개 중 9개가 A와 다르고, 후보 212,617행 합성 검사에서 글이 A보다 6.7M자 길다(A의 감소량 −24.3M → −17.5M). 내용 손실·빈칸은 A와 같다.

부작용

필드마다 표시 이름 표가 필요하다(이번 실험은 화자·작성자·출처·소속). 다국어라서 문구 표를 호출자가 넘길지 규약에 고정할지 정해야 한다. D7-B와 같은 표를 쓸 수 있다.
역할 필드가 있는 후보는 「작성자 」만큼 글이 길어져 용량 계산에 들어간다(합성 기준 A 대비 +28%).
정본 P3의 「이름」을 표시 이름으로 읽으면 period·label 의 표시 이름이 빈 문자열인 셈이라 정본 문구를 크게 바꾸지 않는다.
#1487 에 필드별 분기를 더해야 한다. A처럼 검색 결과가 바뀐다.

할 일

#1487 보완 · MOR-2770 표시 이름 표·P3 문구 · MOR-2776 대조 · 규약 변경: P3 「표시 이름: 값」 개정 · 검색 결과가 바뀐다

C 정본 P3의 「이름: 값」을 그대로 쓴다 실측

지금 main

* 최초의 장기 안정 왕조
* period: 1009~1225

label: 해당 악기의 GAIN, LEVEL 올리기

author: 김민지
source: 2025 고객 조사

C를 고르면 · 지금과 같다

* 최초의 장기 안정 왕조
* period: 1009~1225

label: 해당 악기의 GAIN, LEVEL 올리기

author: 김민지
source: 2025 고객 조사

역할 필드 · 2.6판 13556260 Group_8 · C는 지금 main 그대로다

역할 필드 · 2.6판 13556260 Group_8 · C · 지금 main — C · 지금 main

결과

바뀌는 것이 없다. 회차 49행(입력 15개)이 계속 영어 키를 보인다. BAD 판정을 받은 Steps 사례에도 이 접두어가 있었다.

부작용

코드·정본 변경이 없고 검색 결과도 그대로다.
tier 1 정렬의 접두어(label: 포함)는 정본이 정하지 않은 채로 남는다. MOR-2820 D7도 그대로다.
D5·D7에서 키를 떼면 이 규칙만 키가 남아 한 화면에서 표기가 섞인다.

할 일

#1487 닫기 · MOR-2770에 현행 유지 기록 · 규약 변경: 없음 · 검색 결과 그대로

빈 값·공백 값

규칙 1b ↓ · #1488 · MOR-2778 · MOR-2770 · MOR-2768

쟁점 · period: ""나 " " 같은 빈 값도 옮겨지면 지금은 「period: 」처럼 빈 접두 줄이 생긴다. D1에서 키를 떼면 공백만 든 bullet이 남아 글상자가 목록 모양이 되고 왼쪽 위로 밀린다.

왜 갈리나 · 빈 값을 막자는 데는 이견이 없다. 갈리는 건 어디서 막느냐다. 읽는 쪽(Rust)만 막으면 규약·Eregion과 어긋나고, 규약에서 막으면 생성기 검증까지 건드린다.

D2 선택A Rust에서만 막는다B 규약에서 막는다 추천C 막지 않는다

추천 B · 막는 기준이 규약·Eregion·Rust 세 곳에서 같아야 MOR-2776 대조가 깨끗하게 끝난다. 화면은 A와 같다.

A Rust 정렬·P3·용량 사전 필터에서 trim 뒤 빈 값을 옮기지 않는다 (#1488 그대로) 실측

지금 main

* 본문
* period:

A를 고르면

* 본문
(빈 값은 옮기지 않는다)
남는 설명 칸 → 「설명을 입력해주세요.」

빈 period · 2.6판 13482509 Group_2 · Timeline 3개 entity 의 period: "", 합성 문서

빈 period · 2.6판 13482509 Group_2 · 지금 main — 지금 main

빈 period · 2.6판 13482509 Group_2 · A · #1488 — A · #1488

결과

지금 데이터에는 빈 값이 0건이라 바뀌는 것이 없다 — 회차 1016 재실행 3,114행, 전체 풀 순위(회차 481·저장 1,301 문서), 저장 입력 변환 1,409개, 엣지 130개 모두 차이 0. 빈 값을 넣은 합성 검사에서는 205,652행의 binding 이 바뀌고 빈칸이 29,196행 늘었다. 아래 사례의 비용은 25.11 → 60.59 로 올랐다.

부작용

쓰레기 글로 채워지던 칸이 빈칸이 되어 임시 문구와 fieldBlank 벌점을 받는다(썸네일의 「설명을 입력해주세요.」). MOR-2768 범위다.
Eregion 벤더 TS 는 여전히 옮긴다 — 벤더 엣지 122개 중 15개가 빈·공백 값을 「period: 」 같은 줄 18개로 옮겼다(2026-10-22 실측). MOR-2776 대조에서 차이로 잡힌다.

할 일

#1488 머지 · MOR-2778 종료 · 규약 변경: 없음 · 지금 데이터에선 검색 결과 그대로(로직은 바뀐다)

B 규약에 「빈·공백 문자열은 필드가 없는 것과 같다」를 넣고 Rust·Eregion을 같은 기준으로 맞춘다 실측추천

지금 main

* 본문
* period:

B를 고르면

* 본문
(빈 값은 옮기지 않는다)
남는 설명 칸 → 「설명을 입력해주세요.」

빈 period · 2.6판 13482509 Group_2 · Rust 화면은 A와 같다

결과

Rust 결과는 A와 같다(지금 데이터 차이 0, 사례 비용 25.11 → 60.59). 다른 점은 TS 쪽이다: 같은 기준(빈·공백 = 필드 없음)을 벤더 TS 에 적용하면 빈 값 줄을 옮기는 엣지가 15/122 → 0 이 되어 TS·Rust 대조가 일치한다.

부작용

규약 개정과 Eregion PR 이 하나 더 든다.
생성기 검증에서 빈 값을 지울지 거부할지 정해야 한다. 거부하면 재시도가 늘고 두 번 다 실패한 필수 레벨은 422다. 생성 기록(회차 YAML 972개·저장 1,320개)에 빈 값이 0건이라 지금 재시도는 늘지 않는다.
직접 입력한 YAML 경로도 같은 기준을 받는다.

할 일

#1488 머지 · MOR-2770 규약·Eregion · MOR-2776 대조 · 규약 변경: 빈 값 = 필드 없음 명시 · 지금 데이터에선 검색 결과 그대로(로직은 바뀐다)

C 빈 값 방어를 넣지 않는다 실측

지금 main

* 본문
* period:

C를 고르면 · 지금과 같다

* 본문
* period:

공백 period · 2.6판 13482509 Group_2 · 왼쪽 C(지금 main) · 가운데 C + D1-A · 오른쪽 A(#1488)

공백 period · 2.6판 13482509 Group_2 · C · 지금 main — C · 지금 main

공백 period · 2.6판 13482509 Group_2 · C + D1-A(#1487) — C + D1-A(#1487)

공백 period · 2.6판 13482509 Group_2 · A · #1488 — A · #1488

결과

지금 데이터에 빈 값이 0건이라 지금 화면은 그대로다.

부작용

D1을 A나 B로 고르면 공백 값이 빈 bullet 로 남는다 — 아래 썸네일 가운데(#1487 만 적용): 「period:␣␣␣」이 「␣␣␣」만 남은 bullet 이 된다.
생성기가 빈 값을 쓰기 시작하면 그대로 화면에 나간다.

할 일

#1488 닫기 · 규약 변경: 없음 · 검색 결과 그대로

value 이동의 「값:」

규칙 2 ↓ · #1484 · MOR-2770 · MOR-2820 D7

쟁점 · P3 안의 분기가 value를 옮길 때 「값:」을 붙인다. 그런데 지금 어휘에서는 P5가 먼저 value·unit을 처리해서 이 분기에 닿는 입력이 없다.

왜 갈리나 · 화면 효과가 0인 변경을 머지할 가치가 있는지, 그리고 D1과 표기 방향을 맞출지의 문제다.

D3 선택A 방어적 정리로 머지 추천B 도달 경로까지 보류C 닫고 분기를 지운다

추천 A · 화면 효과는 없지만 D1과 같은 방향의 정리라 남겨 둘 이유가 적다. 다만 화면 개선으로 세지 않는다.

A 머지하되 PR 설명에 「도달 경로 없음 · 방어적 정리」를 적는다 실측추천

지금 main

값: 70억원   (지금 어휘로는 닿지 않는 분기)

A를 고르면

70억원   (단위 테스트로만 확인)

결과

모든 측정에서 차이 0이다 — 저장 입력 변환 1,409개, 엣지 130개, 전체 풀 순위(회차 481·저장 1,301 문서). 판을 다시 구울 일이 없다. 화면이 바뀌지 않아 썸네일이 없다.

부작용

D1을 C로 고르면 P3 안에서 「값:」만 떼고 「period:」는 남아 같은 규칙 안에서 표기가 섞인다.
화면 개선으로 세면 안 된다.

할 일

#1484 머지 · PR 설명에 도달 경로 없음 명시 · 규약 변경: 없음 · 검색 결과 그대로

B 실제 공개 투영 경로로 닿는 사례를 찾을 때까지 PR을 열어 둔다 실측

지금 main

값: 70억원   (지금 어휘로는 닿지 않는 분기)

B를 고르면 · 지금과 같다

값: 70억원   (지금 어휘로는 닿지 않는 분기)

결과

출력 변화는 0이다(A와 같은 측정).

부작용

열린 PR이 main과 계속 벌어져 충돌을 다시 풀어야 한다.
결론이 안 날 수 있다. 「닿지 않는다」는 조사 결과이지 증명이 아니다.

할 일

MOR-2770에서 도달 사례 확보 · 규약 변경: 없음 · 검색 결과 그대로

C PR을 닫고 닿지 않는 분기 자체를 지운다 실측

지금 main

값: 70억원   (지금 어휘로는 닿지 않는 분기)

C를 고르면

(분기 없음)

결과

출력 변화는 0이다(A와 같은 측정).

부작용

나중에 value를 읽지 않는 도착 카테고리가 P5 없이 생기면 value가 조용히 사라진다. 그 경우를 막는 테스트가 필요하다.
「모든 입력에서 닿지 않는다」는 증명이 아니라서 지우는 근거가 약하다.

할 일

#1484 닫기 · 분기 제거 PR · 규약 변경: 없음 · 검색 결과 그대로

표에서 쪼개진 칸

규칙 3 ↓ · #1458 ✓ merged · MOR-2779

쟁점 · #1458로 「열 3:」 같은 지어낸 머리글은 사라졌다. 그런데 회차 11행(입력 2개)의 진짜 원인은 생성기가 「1,000원」을 따옴표 없이 써서 YAML이 「1」과 「000원」 두 칸으로 쪼갠 것이다. 지금 화면에는 금액이 갈린 채로 나온다.

왜 갈리나 · 쪼개진 값을 읽는 쪽에서 다시 붙일지, 쓰는 쪽에서 막을지다. #1458의 방어(A)는 이미 main에 있어서 B와 C는 그 위에 얹는다. 실측해 보니 생성 YAML 의 쪼개진 행 37개 중 15개(41%)는 쉼표가 마지막이 아닌 칸에 있었다 — 읽는 쪽에서는 어느 칸이 쪼개졌는지 알 수 없다.

D4 선택A 지금대로 + 규약 보충B 읽는 쪽에서 다시 붙인다C 쓰는 쪽에서 막는다 추천

추천 C · 원인을 고치는 유일한 안이다. B는 진짜로 열이 빠진 표와 구분할 방법이 없다.

A #1458 구현을 그대로 두고 MOR-2779에서 P4 예외만 정본에 적는다 실측

지금 main

* 내용: 1
* 000원

A를 고르면 · 지금과 같다

* 내용: 1
* 000원

쿠폰 금액 · 2.6판 12100260 Group_9 · 회차 314-399, ListingTable → List

쿠폰 금액 · 2.6판 12100260 Group_9 · A · 지금 main — A · 지금 main

수험 상품 비교 · 2.6판 12741234 HStack_1 · 회차 314-212, ComparisonTable → List

수험 상품 비교 · 2.6판 12741234 HStack_1 · A · 지금 main — A · 지금 main

결과

회차 1016에서 쪼개진 표는 입력 2개·11행이다. 지어낸 머리글은 없지만 금액이 「1 · 000원」처럼 갈린 채 남는다. 생성 YAML 기준으로는 회차 1016 고유 YAML 485개 중 6개(1.2%), 1013 487개 중 6개, 저장 1,320개 중 10개에 이런 행이 있다.

부작용

코드 변경이 없다.
사용자는 「1」과 「000원」을 따로 본다.

할 일

MOR-2779 P4 문서 보충 · 규약 변경: P4 예외 보충 · 검색 결과 그대로

B 머리글보다 많은 칸을 마지막 열에 쉼표로 다시 붙인다 (평탄화) 실측

지금 main

* 내용: 1
* 000원

B를 고르면

* 내용: 1,000원

쿠폰 금액 · 2.6판 12100260 Group_9 · B가 맞게 붙인 경우

쿠폰 금액 · 2.6판 12100260 Group_9 · 지금 main — 지금 main

쿠폰 금액 · 2.6판 12100260 Group_9 · B · 마지막 열에 붙임 — B · 마지막 열에 붙임

수험 상품 비교 · 2.6판 12741234 HStack_1 · B가 잘못 붙인 경우 — 쉼표는 공단기 칸에 있었다

수험 상품 비교 · 2.6판 12741234 HStack_1 · 지금 main — 지금 main

수험 상품 비교 · 2.6판 12741234 HStack_1 · B · 마지막 열에 붙임 — B · 마지막 열에 붙임

결과

회차 1016에서 11행(입력 2개)의 글이 바뀐다. 314-399 는 「1,000원」이 돌아오고 비용이 9.34 → 1.61 로 내려간다. 그러나 314-212 는 잘못 합친다: 쉼표가 공단기 칸(「신규·환승·재수강, 룰렛이벤트」)에 있었는데 마지막 칸에 「얼리버드중심,환급,…」을 붙인다. 회차 1013·1016 의 쪼개진 행 37개를 원문과 맞춰 보니 B가 맞는 행 22개(59%), 틀린 행 15개(41%)였다 — 12개는 첫 칸(「기획, 연출 및 행정관리 | 5.6」)이 쪼개진 경우다. 전체 풀 순위: 회차 4개·저장 8개 문서의 순서가 바뀌고 저장 2개 문서의 1위가 바뀐다.

부작용

쉼표 뒤 공백을 알 수 없어 「스파르타반, 기숙연계반」은 「스파르타반,기숙연계반」이 된다(쪼개진 행 가운데 15개는 원문 쉼표 뒤에 공백이 있었다).
41%의 행에서 값을 엉뚱한 칸에 붙인다. 숫자가 마지막 칸이면 글과 숫자가 한 칸에 섞인다.
정본 P4에 새 규칙이 들고 Rust·TS 평탄화와 질의 Frame 이 바뀐다(저장 입력 12/1,409개).

할 일

평탄화 PR · MOR-2779 · 규약 변경: P4에 칸 합치기 규칙 · 검색 결과가 바뀐다

C 생성 검증에서 행의 칸 수가 열 수와 다르면 실패로 보고 다시 생성한다 실측 · 대리 지표추천

지금 main

* 내용: 1
* 000원

C를 고르면

* 내용: 1,000원   (재생성이 따옴표를 붙이면)

쿠폰 금액 · 2.6판 12100260 Group_9 · 오른쪽은 생성기가 쉼표 칸을 따옴표로 썼을 때

쿠폰 금액 · 2.6판 12100260 Group_9 · C · 따옴표로 다시 생성했을 때 — C · 따옴표로 다시 생성했을 때

수험 상품 비교 · 2.6판 12741234 HStack_1 · 쉼표가 가운데 칸에 있어도 맞게 나온다

수험 상품 비교 · 2.6판 12741234 HStack_1 · C · 따옴표로 다시 생성했을 때 — C · 따옴표로 다시 생성했을 때

결과

쪼개진 행이 있는 생성 YAML 은 회차 1016 고유 485개 중 6개(1.2%)·저장 1,320개 중 10개다 — 이 비율만큼 생성 검증이 실패하고 다시 생성한다. 다시 생성한 문서가 따옴표를 붙이면 두 사례 모두 원문 그대로 나온다(썸네일 오른쪽, 314-399 비용 9.34 → 1.61). 다만 그냥 다시 생성해서는 잘 안 고쳐진다: 같은 입력을 회차 1013·1016 이 따로 생성한 242개 중, 1013에서 쪼개졌던 6개 입력 가운데 5개가 1016에서도 쪼개졌다(대리 지표). 재시도 프롬프트에 「쉼표 든 칸은 따옴표로」를 넣는 것이 필요하다. 그 재시도의 성공률은 LLM 자격 증명이 없어 재지 못했다.

부작용

걸린 문서마다 LLM 호출이 한 번 더 든다(지금 비율 1.2%). 두 번 다 실패하면 필수 레벨은 422 generation_failed 다.
피드백 없는 재시도는 6개 중 1개만 고쳐졌다 — 재시도 문구를 같이 바꾸지 않으면 422 위험이 남는다.
직접 입력한 YAML 경로에는 효과가 없어 A의 방어는 그대로 둬야 한다.
서버 생성 검증(generate/validate.rs)에는 지금 이 검사가 없다(2026-10-22 확인).

할 일

생성 검증 PR · MOR-2779 · 규약 변경: 행 칸 수 = 열 수 명시 · 검색 결과 그대로

평탄화 줄의 키

규칙 4 ↓ · #1485 · MOR-2777 · MOR-2820 D7

쟁점 · 중첩을 벗기거나(N3·N4 peel) 마지막 단계(N5)에서 필드를 줄로 풀 때 「value: 40명」처럼 키를 붙인다. 회차에는 중첩이 없어 0행이고, 저장 입력에서는 query Frame 5개가 바뀐다.

왜 갈리나 · 키를 떼자는 데는 이견이 없다. 뗀 뒤에 label과 값을 두 줄로 둘지 한 줄로 합칠지가 남는다. 줄 수는 Frame의 items 개수라서 검색에 닿는다.

D5 선택A 키만 뗀다 · 두 줄 추천B 한 줄로 합친다C 지금대로 둔다

추천 A · 실측이 있고 손실이 없다. 한 줄로 합치는 안(B)은 MOR-2777에서 따로 재 보고 고른다.

A 키만 떼고 label과 값은 두 줄로 둔다 (#1485 그대로) 실측추천

지금 main

* 총 대상
* value: 40명

A를 고르면

* 총 대상
* 40명

경력 기간 · 2.6판 13211792 HStack_0 · 저장 생성 기록 ResumeCV — 전체 풀 1위

경력 기간 · 2.6판 13211792 HStack_0 · 지금 main — 지금 main

경력 기간 · 2.6판 13211792 HStack_0 · A · #1485 — A · #1485

중첩 벗기기 · 2.6판 13631655 VStack_3 · 합성 문서(stage N3)

중첩 벗기기 · 2.6판 13631655 VStack_3 · 지금 main — 지금 main

중첩 벗기기 · 2.6판 13631655 VStack_3 · A · #1485 — A · #1485

결과

전체 풀 순위에서 저장 문서 2개의 1위 대치 글이 바뀐다(순서는 그대로). 회차 1016 에는 중첩이 없어 0행이다. 저장 입력의 평탄화 결과 59개·질의 Frame 5개가 바뀌고, 합성 검사 205,652행에서 글이 짧아졌다(−19.7M자). 손실·빈칸·빈 bullet 은 늘지 않았다.

부작용

label 과 값이 서로 다른 bullet 이라 어느 값이 어느 항목인지 줄 순서에 기댄다(썸네일 2번째: 「하반기 신규 계약」 아래 「42건」).
검색 결과가 바뀐다(저장 2개 문서의 1위 글).

할 일

#1485 머지 · 한 줄 결합은 MOR-2777 · 규약 변경: 없음 · 검색 결과가 바뀐다

B 키를 떼고 label과 값을 한 줄로 합친다 실측

지금 main

* 총 대상
* value: 40명

B를 고르면

* 총 대상: 40명

중첩 벗기기 · 2.6판 13631655 VStack_3 · 합성 문서(stage N3)

중첩 벗기기 · 2.6판 13631655 VStack_3 · B · 한 줄 — B · 한 줄

결과

실제 문서의 검색 결과는 A와 같다 — 전체 풀 순위(회차 481·저장 1,301 문서)에서 A와 차이 0. 저장 입력은 평탄화 31개·질의 Frame 1개가 A와 다르다. 값이 있는 중첩 사례에서는 「하반기 신규 계약: 42건」 한 줄이 되고 비용이 13.52 → 11.63 으로 내려간다. 반면 후보 212,617행 합성 검사에서는 A보다 빈칸이 3,747개(1,784행) 늘었다 — 줄이 줄어 채울 items 칸이 비는 후보가 생긴다.

부작용

줄 수가 줄어 items 칸이 남는 후보에서 빈칸이 생긴다(합성 1,784행).
최상위 entity 는 label 자리가 「총 대상: 40명」이 되고 items 가 비어, label 과 값을 다른 칸에 두던 템플릿과 짝이 달라진다.
사용자가 쓴 콜론과 코드가 넣은 콜론을 구분할 규칙, 출처 등 다른 필드의 결합 규칙이 필요하다(MOR-2777).

할 일

#1485 보완 · MOR-2777 · 규약 변경: §8.7 한 줄 표기 일반화 · 검색 결과가 바뀐다

C 평탄화 줄의 키를 그대로 둔다 실측

지금 main

* 총 대상
* value: 40명

C를 고르면 · 지금과 같다

* 총 대상
* value: 40명

중첩 벗기기 · 2.6판 13631655 VStack_3 · C는 지금 main 그대로다

중첩 벗기기 · 2.6판 13631655 VStack_3 · C · 지금 main — C · 지금 main

결과

바뀌는 것이 없다.

부작용

D1에서 키를 떼면 P3 줄은 값만, 평탄화 줄은 키가 붙어 한 화면에서 표기가 섞인다.

할 일

#1485 닫기 · 규약 변경: 없음 · 검색 결과 그대로

신호 필드(emphasis·weight·avatar)

규칙 6 ↓ · #1486 · MOR-2770 · MOR-2771 · MOR-2828 E5 · MOR-2832 F1 · MOR-2829 E6 · MOR-2833 F3

쟁점 · emphasis(true)·weight(0.8, 82)·avatar(a.png)는 값이 글이 아닌데, 정렬과 투영이 「emphasis: true」「weight: 82」로 글에 옮긴다. 그런데 weight가 그 항목의 유일한 수치일 때가 있다.

왜 갈리나 · 원칙 ㄷ의 두 절, 「글이 아니면 옮기지 않는다」와 「유일한 정보면 지킨다」가 부딪친다. 게다가 감사 MOR-2828 E5는 같은 문제를 반대 방향(질의 비트를 끄고 §3.5 이동은 둔다)으로 풀자고 한다. 같이 정하지 않으면 두 수정이 서로를 되돌린다.

D6 선택A 일괄 제외B 조건부 보존 추천C 감사 E5 방향

추천 B · 원칙 ㄷ의 두 절을 모두 지키는 유일한 안이다. MOR-2828 E5와 한 번에 정한다.

A 글로 옮기지 않고, 같은 이름 슬롯도 비우고, 질의 비트는 남긴다 (#1486 그대로) 실측

지금 main

L1  * 82%
    * weight: 82
L2  일반 회원 → weight: 82
강조 칸  true

A를 고르면

L1  * 82%
L2  일반 회원 → (설명 임시 문구)
강조 칸  (임시 문구 「강조」)

weight 만 있는 수치 · 2.6판 13332795 Group_11 · 저장 생성 기록 L2 Pyramid

weight 만 있는 수치 · 2.6판 13332795 Group_11 · 지금 main — 지금 main

weight 만 있는 수치 · 2.6판 13332795 Group_11 · A · #1486 — A · #1486

결과

전체 풀 순위에서 저장 문서 4개의 순서가 바뀌고 2개의 1위가 바뀐다. weight 만 가진 L2 Pyramid 문서는 82·15·3 이 사라지며 1위가 13332795(비용 10.12)에서 13332928(31.14)로 나빠졌다. 강조가 든 BigNumber 문서는 1위가 바뀌었다(9.61 → 3.33). 회차 1016 에는 신호 필드가 없어 0행이다. 합성 검사에서는 빈칸이 29,423행 늘었다.

부작용

weight 에만 있던 수치가 사라진다(실제 저장 입력에서 재현, 썸네일).
비운 강조 칸에 임시 문구와 fieldBlank 벌점이 붙는다 — 질의 비트가 강조 슬롯 후보를 먼저 고르는데 그 칸이 벌점을 받는 역전이다.
정본 §3.5와 어긋나고 E5와 방향이 반대다.

할 일

#1486 머지 · MOR-2770 §2·§3.5 개정 · MOR-2833 임시 문구 근거 · 규약 변경: §2·§3.5 신호 이동 삭제 · 검색 결과가 바뀐다

B weight는 본문에 같은 수치가 없을 때만 값으로 남기고 emphasis·avatar는 뺀다. 비운 강조 칸은 fieldBlank에서 뺀다 실측추천

지금 main

L1  * 82%
    * weight: 82
L2  일반 회원 → weight: 82
강조 칸  true

B를 고르면

L1  * 82%   (중복 weight는 뺀다)
L2  일반 회원 → 82
강조 칸  (비움 · 벌점 없음)

weight 만 있는 수치 · 2.6판 13332795 Group_11 · 저장 생성 기록 L2 Pyramid

weight 만 있는 수치 · 2.6판 13332795 Group_11 · B · 조건부 보존 — B · 조건부 보존

결과

L1·L2 두 사례가 모두 의도대로 간다. L1 은 본문에 같은 수치(82%)가 있어 weight 가 빠지고, L2 는 82·15·3 이 값으로 남아 비용이 main 과 같은 10.12 다. 전체 풀 순위에서 A가 망친 L2 문서의 1위가 main 과 같은 13332795 로 돌아온다(A 대비 1위 1개·순서 3개 문서 차이). BigNumber 강조 문서는 A와 같다. 합성 검사에서 A보다 빈칸이 54,987개 줄고(29,195행), weight 를 받을 칸이 없는 305행에서 그 글이 버려졌다.

부작용

「같은 수치」 판정이 필요하다 — 이번 실험은 본문 숫자가 weight 와 같거나 weight×100 과 같으면 중복으로 봤다(0.82 와 82%). TS·Rust·Eregion 세 곳이 같아야 한다.
weight 를 받을 칸이 없는 후보에서는 그 수치가 버려진다(합성 305행). 실제 데이터에서는 0건이었다.
구현이 #1486보다 크다: 정렬·투영·평탄화 세 곳과 fieldBlank 집계를 고친다. 정본 §2·§3.5 도 고친다.

할 일

#1486 보완 · MOR-2770 보존 규칙 · MOR-2771 엣지별 구현 · MOR-2828 E5와 함께 · 규약 변경: §2·§3.5 조건부 보존 · 검색 결과가 바뀐다

C 질의가 신호로 슬롯·비트를 만들지 않고, fallback 투영의 §3.5 이동은 정본대로 둔다 실측

지금 main

L1  * 82%
    * weight: 82
L2  일반 회원 → weight: 82
강조 칸  true

C를 고르면

L1  * 82%   (weight 슬롯·비트 없음)
L2  일반 회원 → (설명 임시 문구)   (tier 1 에서도 수치가 사라진다)
강조 칸  비트 없음 → 역전 없음
fallback  * emphasis: true   (§3.5 대로 남는다)

weight 만 있는 수치 · 2.6판 13332795 Group_11 · 저장 생성 기록 L2 Pyramid

weight 만 있는 수치 · 2.6판 13332795 Group_11 · C · E5 — C · E5

결과

전체 풀 순위에서 저장 문서 3개의 1위가 바뀐다. 질의에 신호 슬롯·비트가 없어 tier 1 에서도 weight 수치가 사라진다 — L2 Pyramid 의 82·15·3 이 A처럼 없어지고(사례 비용 31.34, A와 같다) 1위는 다른 템플릿(12120349, 19.21)으로 간다. weight 비트가 사라진 L1 Pyramid 는 다른 템플릿이 열려 1위 비용이 11.74 → 1.14 로 크게 내려간다. 합성 검사(질의를 직접 짓는 검사)에는 나타나지 않는다.

부작용

weight 만 있던 수치가 A처럼 사라진다(썸네일).
fallback 에서는 정본 §3.5 대로 「emphasis: true」「weight: 82」 줄이 계속 보인다. D1·D5에서 키를 떼는 방향과 반대다.
#1486 을 닫거나 다시 써야 한다. avatar 비트 10 불일치(MOR-2829 E6)는 따로 남는다.

할 일

#1486 닫기 · MOR-2828 E5 구현 · 규약 변경: 없음 · 검색 결과가 바뀐다

측정값(measure) 표기

규칙 5 ↓ · MOR-2769 · MOR-2812 C6 · MOR-2832 F1

쟁점 · min·max·target·delta·thresholds는 키가 뜻(범위·목표·증감·임계)을 싣는다. 회차에는 measure가 0행이지만 저장 입력에는 measure가 5개(delta 1개) 있다. 측정값 생성을 켜면 바로 화면에 나온다.

왜 갈리나 · 원칙 ㄴ이 걸리는 자리다. 키를 떼면 숫자만 남고, 두면 영어 키와 state 값(warn)이 보인다.

D7 선택A 키를 둔다B 뜻을 사람 말로 추천C 키를 다 뗀다

추천 B · 원칙 ㄴ을 따른다. 측정값 생성을 켤 때 같이 넣는다.

A 지금 표기(target: 80 · delta: 15.4)를 그대로 둔다 실측

지금 main

* 65%
* target: 80
* threshold: 50 주의 (warn)

A를 고르면 · 지금과 같다

* 65%
* target: 80
* threshold: 50 주의 (warn)

임계값이 든 Gauge · 2.6판 13606965 VStack_2 · Gauge → BigNumber(tier 2), 합성 문서

임계값이 든 Gauge · 2.6판 13606965 VStack_2 · A · 지금 main — A · 지금 main

결과

바뀌는 것이 없다.

부작용

영어 키와 state 값(warn)이 화면에 나온다.
D1·D5에서 키를 떼면 측정값만 키가 남는다.

할 일

MOR-2769에 현행 유지 기록 · 규약 변경: 없음 · 검색 결과 그대로

B 「범위 0–100% · 목표 80% · 변화 +5 · 주의 기준 50%」처럼 적는다 실측추천

지금 main

* 65%
* target: 80
* threshold: 50 주의 (warn)

B를 고르면

* 65%
* 목표 80%
* 주의 기준 50%

임계값이 든 Gauge · 2.6판 13606965 VStack_2 · Gauge → BigNumber(tier 2), 합성 문서

임계값이 든 Gauge · 2.6판 13606965 VStack_2 · 지금 main — 지금 main

임계값이 든 Gauge · 2.6판 13606965 VStack_2 · B · 사람 말 — B · 사람 말

결과

저장 입력 measure 5개 중 1개(delta 가 든 것)의 글이 바뀌고, 전체 풀 순위에서 그 문서의 1위 대치 글이 바뀐다(순서는 그대로). Gauge 사례는 「주의 기준 50% · 위험 기준 90% · 범위 0–100%」가 되고 비용이 14.84 → 12.84 로 내려간다. 합성 검사에서 글이 7.7M자 줄었지만 빈칸이 11,349개(7,790행) 늘었다 — 최소·최대를 「범위」 한 줄로 합쳐 items 칸이 남는다.

부작용

범위를 한 줄로 합치면 줄 수가 줄어 빈칸이 생긴다(합성 7,790행). 최소·최대를 따로 두면 이 부작용은 없다.
다국어 문구 표가 필요하다. D1-B를 고르면 같은 표를 쓴다.
delta 에는 단위를 붙이지 않았다(「변화 +15.4」) — 주 값의 단위(억 원)를 붙이면 뜻이 바뀐다. state(warn)는 적지 않았다.

할 일

MOR-2769 표기 결정·구현 · MOR-2812 C6 · 규약 변경: 측정값 표기 신설 · 검색 결과가 바뀐다

C 키를 일괄 제거한다 실측

지금 main

* 65%
* target: 80
* threshold: 50 주의 (warn)

C를 고르면

* 65%
* 80
* 50

임계값이 든 Gauge · 2.6판 13606965 VStack_2 · Gauge → BigNumber(tier 2), 합성 문서

임계값이 든 Gauge · 2.6판 13606965 VStack_2 · C · 키 제거 — C · 키 제거

결과

B와 같은 1개 문서의 글이 바뀐다. Gauge 사례는 「50 주의 · 90 위험 · 0 · 100」만 남는다(비용은 main 과 같은 14.84). 합성 검사에서 글이 13.0M자 줄고 빈칸은 늘지 않았다.

부작용

「0」「100」이 무엇인지 알 수 없다 — 범위·목표·증감·임계를 구분하지 못한다. 원칙 ㄴ과 정면으로 어긋난다.
「delta: 5」(MOR-2832 F1)는 사라지지만 5가 무엇인지도 같이 사라진다.

할 일

권하지 않는다 · 규약 변경: P3·P5 측정값 키 삭제 · 검색 결과가 바뀐다

tier 1의 relationGap 벌점

규칙 7의 남은 범위 ↓ · #1458 ✓ merged · MOR-2819 D6

쟁점 · #1458로 관계 설명은 접두어 없이 옮겨진다. 남은 것은 순위다. tier 1은 투영을 거치지 않아 P7이 돌지 않는다. 그래서 그 카테고리가 그리지 못하는 relation이 질의에 남고, 그 종류가 없는 후보마다 relation 하나당 3을 깎는다(weights.json relationGap: 3). tier 2·3은 P7이 relation을 빼 줘서 벌점이 없다.

왜 갈리나 · 같은 문서가 tier 에 따라 다른 기준으로 채점되는 것처럼 보인다. 그런데 순위에 실제로 닿는지는 재 봐야 안다. 고치는 방법은 로직(P7 범위)과 설정(가중치) 두 가지다.

D8 선택A 지금대로 둔다 추천B tier 1에도 P7C 가중치를 낮춘다

추천 A · 실측해 보니 tier 1의 relationGap 은 순위를 바꾸지 못한다 — 그 카테고리의 후보는 모두 그 relation 이 없어 같은 벌점을 똑같이 받는다. B는 비용 숫자만 고치고, C는 이 문제와 상관없는 Versus 순위를 바꾼다.

A tier 1의 relationGap 벌점을 그대로 둔다 실측추천

지금 main

화면 글: 「일회성 노출과 … 대비된다.」 (접두어 없음)
순위: 그 relation이 없는 tier 1 후보마다 −3

A를 고르면 · 지금과 같다

화면 글: 「일회성 노출과 … 대비된다.」 (접두어 없음)
순위: 그 relation이 없는 tier 1 후보마다 −3

결과

실제 문서의 relation 48개 중 13개(회차 1·저장 12)가 그 카테고리가 그리지 못하는 종류다(Transformation·Steps·List·ComparisonTable 등). 이 문서들에서 벌점은 tier 1 후보 전부에 똑같이 붙는다 — 예: 저장 문서의 List(intersects) 는 tier 1 후보 50개 모두가 +3을 받는다. 그래서 순서는 바뀌지 않는다.

부작용

비용 숫자에는 tier 마다 다른 기준이 남는다. 나중에 비용을 tier·문서끼리 직접 비교하는 기능이 생기면 문제가 될 수 있다.
MOR-2819 D6 은 「순위 영향 없음」으로 정리할 근거가 생긴다.

할 일

MOR-2819에 유지 기록 · 규약 변경: 없음 · 검색 결과 그대로

B tier 1 질의에서도 그 카테고리가 그리지 못하는 relation을 뺀다 (desc는 지금처럼 items로) 실측

지금 main

화면 글: 「일회성 노출과 … 대비된다.」 (접두어 없음)
순위: 그 relation이 없는 tier 1 후보마다 −3

B를 고르면

화면 글: 같다
순위: 순서 그대로(실측 0건) · 비용 숫자만 −3

결과

전체 풀 순위(회차 481·저장 1,301 문서)에서 순서·1위·대치 글이 바뀐 문서는 0개다. 비용 숫자만 저장 문서 9개에서 바뀌었다(그 relation 벌점 −3). 화면 글도 같아 썸네일이 없다.

부작용

결과가 같은데 로직이 바뀌므로 골든이 바뀌면 (a)/(b) 처리 방식을 PR 에 적어야 한다.
정본에 「P7은 tier 1 질의에도 적용한다」를 적어야 한다.

할 일

로직 PR · MOR-2819 · 규약 변경: P7 적용 범위에 tier 1 · 지금 데이터에선 검색 결과 그대로(로직은 바뀐다)

C 환경별 config.json 덮어쓰기로 relationGap 가중치를 낮춘다 실측

지금 main

화면 글: 「일회성 노출과 … 대비된다.」 (접두어 없음)
순위: 그 relation이 없는 tier 1 후보마다 −3

C를 고르면

화면 글: 같다
순위: Versus 에서 compares 자리 없는 템플릿이 올라온다
      (가중치 0: 1위 교체 회차 1·저장 12)

「콘텐츠의 지속성」 Versus 문서의 1위 · 회차 문서 r199 — 왼쪽은 지금 1위(13231031), 오른쪽은 relationGap 0 일 때 1위(12567967). 대치 글은 같고 템플릿만 다르다.

「콘텐츠의 지속성」 Versus 문서의 1위 · 지금 main 1위 — 지금 main 1위

「콘텐츠의 지속성」 Versus 문서의 1위 · C · 가중치 0 의 1위 — C · 가중치 0 의 1위

결과

0으로 낮추면 회차 문서 1개·저장 문서 12개의 1위가 바뀌고(저장 28개 순서 변화), 1로 낮추면 1위는 그대로이고 순서만 회차 1개·저장 25개에서 바뀐다. 1위가 바뀐 13개 문서는 모두 Versus(compares) 다 — 관계를 그리는 카테고리에서 compares 자리가 없는 템플릿이 올라온다. 사례: 「콘텐츠의 지속성」 문서의 1위가 13231031 에서 12567967 로 바뀐다(그 후보의 비용 4.31 → 1.31).

부작용

이 결정의 대상(그리지 못하는 relation)은 순위에 영향이 없으니, C가 바꾸는 것은 전부 정당한 벌점을 받던 Versus 후보다.
근본 원인(P7 범위)은 그대로다. 설정이라 재배포 없이 되돌릴 수 있다.

할 일

config.json 덮어쓰기 · MOR-2819 · 규약 변경: 없음 · 설정만 바뀐다

규칙 · PR · 판단	무엇이 바뀌나 · 접두어 정리인가	어디서 생기나 · 판정 회차 실측	정본 · 조사 결과	권장 보완 · Jira
1 · 문자열 필드 #1487 PR 진행 중 보완 후 권장 조사·구현·사례 보기 ↓ · 판정 사례 ↓	`period: 2018년 → 2018년` Rust 정렬·투영·용량 사전 필터와 공유 TS `p3Text`에 값만 이동을 구현했다. Eregion 벤더 투영은 아직 동기화 전이다. 접두어 정리 · 맞다. 필드 키를 코드가 붙인다. 판정 회차에서는 정본 P3 대상이 아닌 `label:`도 나왔다 — #1487은 이것도 뗀다.	tier 1·fallback 둘 다. tier 1은 정렬 pass 2(후보 유닛에 그 슬롯이 없을 때), fallback은 투영 P3와 정렬. 판정 회차 1016 · 49행·입력 16개 tier 1 9행: Timeline `period:` 7 · Steps·List `label:` 2 fallback 40행: Timeline→List·Steps `period:` 26(투영 P3) · 표→List·LongForm `label:` 14(정렬)	P3의 `이름: 값`과 다르다. 저장 입력 24개의 query Frame 변화는 확인했지만, 작성자·출처의 역할 구분은 합성 사례로만 검토했다. 「`이름: 값`」은 fallback 투영에만 걸린다(v0.5.6에서 범위 명시). tier 1 정렬의 접두어(`label:` 포함)는 정본이 정하지 않는다.	MOR-2770에서 P3·Eregion을 맞추고 #1488과 공백 방어를 통합 확인한다. 작성자·출처가 한 본문에 섞일 때 의미를 남길 표기도 정한다. 감사 연결 · MOR-2820 D7 — 옮겨지는 글의 모양(P3 「이름: 값」 → 값만)이 겹친다. 정리 ↓
1b · 빈 문자열·공백 #1488 PR 진행 중 Rust 보완 반영 조사·구현·사례 보기 ↓ · 판정 사례 ↓	`빈 값·공백뿐인 값 → 이동하지 않음` Rust 정렬·P3·용량 사전 필터에 공백 방어를 구현했다. 실제 내용의 공백·콜론은 보존한다. 상세 구현·검증 기록 ↗ 접두어 정리 · 아니다. 빈 값 방어다. 접두어를 떼면 남는 빈 줄·빈 bullet을 막는다.	둘 다 — 규칙 1과 같은 경로. 판정 회차 · 0행(빈 문자열을 쓴 YAML이 없다)	P3에 빈 값·공백 규정은 없다. 기존 공백 bullet 사례는 보완 전 기록이며, 조사·썸네일은 재실행하지 않았다.	MOR-2778은 Rust PR 추적, MOR-2770은 규약·Eregion, MOR-2776은 공백 기준과 결과의 TS/Rust 일치를 확인한다. 빈 슬롯의 임시 문구·벌점은 별도 검토한다.
2 · value 접두 #1484 PR 진행 중 도달 경로 확인 조사·구현·사례 보기 ↓ · 판정 사례 ↓	`값: 70억원 → 70억원` Rust P3 내부 분기의 `값:`만 제거했다. value·unit 결합 조건은 유지했고, TS 벤더 변경은 포함하지 않는다. 접두어 정리 · 맞다(`값:`). 다만 지금 어휘로는 닿지 않는 가지다.	fallback만, 그것도 지금 어휘로는 닿지 않는다(P5가 먼저 value·unit을 남긴다). 판정 회차 · 0행	P3의 접두 규정과 다르다. 입력 1,405개·엣지 130개에서 출력 변화는 0이었다. P5가 value·unit을 먼저 처리한다.	MOR-2770에서 실제 공개 투영 경로로 이 분기에 도달하는 사례를 먼저 확보한다. 도달하지 않으면 방어적 코드 정리로 설명하고, 화면 개선으로 계산하지 않는다. MOR-2776도 같은 경로로 대조한다. 감사 연결 · MOR-2820 D7 — 「값:」 접두가 지금 어휘에서 닿지 않는다는 진단이 이 조사와 같다. 정리 ↓
3 · 표 머리글 #1458 merged 구현 유지 · 규약 보충 구현·기존 사례 보기 ↓ · 판정 사례 ↓	`열 4: 연락 → 연락 / 원인: 생활관리 유지` main에 Rust·TS 표 평탄화를 반영했다. 실제 머리글은 보존하고, 머리글 누락·빈 문자열·공백에는 가짜 `열 N:`을 만들지 않는다. 접두어 정리 · 맞다. 코드가 머리글을 지어냈다.	fallback만 — P4·N5 평탄화. 이 줄을 만드는 `table_entity_cells`·`matrix_entities`는 tier 1 질의 Frame에서 불리지 않는다. 판정 회차 1016 · 11행·입력 2개, 모두 fallback(표 → List). 원인은 생성기가 쉼표 든 셀을 따옴표 없이 쓴 것이다.	실제 머리글 보존은 P4와 일치한다. 머리글 없는 경우의 예외는 정본에 없다. 기존 표 사례는 분리 전 렌더 기록이다.	MOR-2779에서 P4·entities+columns에 예외와 범위를 명시한다. 실제 머리글이 `열 4`인 경우도 보존한다. 빈 셀의 `값 없음` 정책은 MOR-2768에서 다룬다.
4 · 평탄화 접두 #1485 PR 진행 중 접두 제거 권장 조사·구현·사례 보기 ↓ · 판정 사례 ↓	`value: 42% → 42%` Rust·TS 본문 평탄화의 필드 접두를 제거했다. label·값은 여전히 별도 줄이며, 이 PR 단독으로는 신호의 값도 글로 남는다. 접두어 정리 · 맞다(`value:`·`values:`·`period:` 등).	중첩 사다리와 fallback — N3·N4 peel 잔여·N5 평탄화·투영 보조(P6 행·children 앞당김). 중첩 없는 tier 1에서는 돌지 않는다. 판정 회차 · 0행(중첩·children 없음)	함수 결과 59개·query Frame 5개가 바뀌었고 0·단위·사용자 콜론을 보존했다. §8.7은 `매출 12억원` 예시만 있어 일반 줄 표기는 미정이다.	MOR-2777에서 label+값 결합·출처·다른 필드·들여쓰기를 정하고 본문·용량·골든을 함께 맞춘다. 접두 제거를 티켓 전체 완료로 표시하지 않는다. 감사 연결 · MOR-2820 D7 — 「value: 12억원」 접두와 「매출: 12억원」 한 줄 표기 질문이 겹친다. 정리 ↓
5 · 측정값 MOR-2769 Jira 초안 정책 결정 후 구현 조사·구현·사례 보기 ↓ · 판정 사례 ↓	`target: 80 · delta: 15.4 등 기존 표기 유지` 현재 분리 PR은 min·max·target·delta·thresholds의 표기를 바꾸지 않는다. 별도 구현 PR은 이 묶음에 없다. 접두어 정리 · 아니다(표기 정책). 키가 뜻(범위·목표·증감·임계)을 실어, 떼면 숫자만 남는다.	둘 다 — tier 1은 질의 Frame을 짓는 `build_frame_for_structure`가 measure를 펴며 `min: 0` 등을 items에 넣고, fallback은 P5 → P3. 판정 회차 · 0행(measure 없음)	fallback의 `이름: 값`은 P5→P3를 따른다. 같은 카테고리(tier 1)의 Frame 표기는 미정이다. 실제 measure 입력 5개가 있으므로 후보의 measure 데이터셋 0행을 무영향 근거로 쓰지 않는다.	MOR-2769에서 목표·범위·증감·임계값의 의미와 state 표기를 정한다. delta에 주 값의 단위를 자동으로 붙이지 않고, tier 1·fallback을 나눠 검증한다. 감사 연결 · MOR-2812 C6(색인·질의의 measure 지도) · MOR-2832 F1의 「delta: 5」 — 측정값을 생성할 때 함께 켠다. 정리 ↓
6 · 신호 필드 #1486 PR 진행 중 일괄 제외 보류 조사·구현·사례 보기 ↓ · 판정 사례 ↓	`emphasis·weight·avatar의 글 이동·정렬 제외` Rust 투영·정렬·별칭/폴백 호스트·용량과 Rust·TS 평탄화에서 제외했다. 같은 이름의 슬롯도 정렬에서 채우지 않는다. 접두어 정리 · 아니다. 값 자체(`true`·`0.8`·`a.png`)가 글이 아니다. 접두어가 붙는 건 일부 경로뿐이다.	둘 다 — tier 1은 `entity_to_unit`이 같은 이름 슬롯에 `true`를 싣고 정렬 pass 2가 `emphasis: true`를 items로, fallback은 투영 P3·평탄화. 판정 회차 · 0행	§2의 내용 분류·§3.5의 엣지 서술과 다르다. query Frame 4개 변화 중 weight만 가진 82·15·3 손실이 재현됐다. 중복 수치 제거만으로 일괄 제외를 권장할 수 없다.	MOR-2770에서 수치를 보존할 정책을 먼저 정하고 MOR-2771이 엣지별로 구현한다. 티켓은 “도착지가 읽는 필드 유지”지만 PR은 정렬 슬롯도 막으므로 강조 슬롯의 수용 범위를 함께 맞춘다. 감사 연결 · MOR-2832 F1은 수정안이 #1486과 같다. MOR-2828 E5는 해법이 반대다(질의 비트를 끄고 투영 P3의 `emphasis: true` 이동은 둔다). MOR-2829 E6은 URL 누출만 겹치고 비트 10 불일치가 남는다. MOR-2833 F3은 비운 강조 슬롯에 뜨는 임시 문구의 근거다. 정리 ↓ 2026-10-19 리뷰 · 질의 비트는 강조 슬롯이 있는 후보를 stage 0에서 먼저 고르는데, 그 슬롯이 이제 비어 `fieldBlank` 벌점을 받는다. 강조 슬롯이 없는 후보는 벌점이 없어 순위가 거꾸로 선다. V3가 신호 필드를 만들지 않아 운영 영향은 0이다. E5와 같이 정한다.
7 · 관계 설명 #1458 merged 현재 구현 유지 구현·기존 사례 보기 ↓ · 판정 사례 ↓	`교집합: 설명 → 설명` main의 Rust 정렬에서 관계 종류 접두를 제거하고 desc만 옮긴다. 빈 문자열 desc는 건너뛰어 빈 이동 기록을 만들지 않는다. 접두어 정리 · 맞다. 관계 종류(`교집합:`·`비교:`)를 코드가 붙였다.	둘 다 — tier 1은 정렬 `align_relations`, fallback은 P7. 판정 회차 1016 · 12행·입력 3개 — tier 1 Versus 11행, fallback 1행	desc만 이동하는 원칙은 P7과 일치한다. 빈 desc 생략은 구현 방어다. 기존 관계 사례는 분리 전 렌더 기록이다.	MOR-2516·#1458의 완료 범위로 유지한다. 빈 관계 desc와 #1488의 문자열 필드 방어는 서로 다른 범위다. 추가 정책 변경 근거는 이번 조사에서 확인하지 않았다. 감사 연결 · MOR-2819 D6 — 남는 범위는 tier 1에 P7이 적용되지 않아 붙는 relationGap 벌점 하나다. desc는 #1458 머지로 tier 1에서도 접두어 없이 items에 붙어 「desc 유실」은 뺐다. 정리 ↓

PR	확인 head / merged 커밋	현재 상태
#1458	`6b99594353` / merged `826cda2e31`	✓ merged
#1484	`aa58b8a6d0`	OPEN · base main
#1485	`2e75e0f91a`	OPEN · base main
#1486	`86e58f05d4` 10-18 `2f6f0a4950` → main 병합 `9ea9eb5e6` → 테스트 위치 정리	OPEN · base main · 충돌 없음(10-19)
#1487	`5d9150628e` 10-18 `bec77cb1bd` → main 병합(`p3_text`는 이 PR 본문 + #1499의 `pub(crate)`)	OPEN · base main · 충돌 없음(10-19)
#1488	`cb9ba9d989`	OPEN · base main

규칙	사례 · tier · 후보
1	period tier 1 D.O. 13482509 TimelineSchedule_Timeline→TimelineSchedule_Timeline quote-author-source tier 1 D.O. 13050011 Utterance_QuoteTestimonial→Utterance_QuoteTestimonial quote-to-highlighted fallback · tier 2 D.O. 13556260 Utterance_QuoteTestimonial→TextBasedCommunication_HighlightedMessage profile-org-noslot tier 1 D.O. 13514020 PortraitProfile_ProfileCard→PortraitProfile_ProfileCard
1b	timeline-empty-period tier 1 D.O. 13579287 TimelineSchedule_Timeline→TimelineSchedule_Timeline
3	listing-ragged-col fallback · tier 2 D.O. 13625758 Enumeration_ListingTable→Enumeration_List
4	nested-peel tier 1 D.O. 13631655 Enumeration_List→Enumeration_List
5	gauge-thresholds fallback · tier 2 D.O. 13606965 KPIKeyMetric_Gauge→KPIKeyMetric_BigNumber gauge-tier1 tier 1 D.O. 12821819 KPIKeyMetric_Gauge→KPIKeyMetric_Gauge gauge-to-bignumber fallback · tier 2 D.O. 13602576 KPIKeyMetric_Gauge→KPIKeyMetric_BigNumber gauge-to-highlighted fallback · tier 2 D.O. 13579650 KPIKeyMetric_Gauge→TextBasedCommunication_HighlightedMessage gauge-to-list fallback · tier 2 D.O. 13636373 KPIKeyMetric_Gauge→TextBasedCommunication_HighlightedMessage
6	profile-org-avatar tier 1 D.O. 13470888 PortraitProfile_ProfileCard→PortraitProfile_ProfileCard bignumber-emphasis-slot tier 1 D.O. 12793308 KPIKeyMetric_BigNumber→KPIKeyMetric_BigNumber pyramid-weight tier 1 D.O. 13616844 Hierarchy_Pyramid→Hierarchy_Pyramid bignumber-emphasis tier 1 D.O. 13549097 KPIKeyMetric_BigNumber→KPIKeyMetric_BigNumber
7	versus-compares tier 1 D.O. 13209109 AttributeComparison_Versus→AttributeComparison_Versus list-intersects tier 1 D.O. 13634877 Enumeration_List→Enumeration_List

슬롯	전	후
items	period: 2018년	2018년
items	period: 2019년	2019년
items	period: 2024년	2024년

슬롯	전	후
label	* 배송이 빠르고 포장이 꼼꼼해서 다음에도 이용하고 싶어요 * source: 2025 고객 만족도 조사	* 배송이 빠르고 포장이 꼼꼼해서 다음에도 이용하고 싶어요 * 2025 고객 만족도 조사

슬롯	전	후
items	author: 김민지	김민지
items	source: 2025 고객 만족도 조사	2025 고객 만족도 조사

슬롯	전	후
items	* 브랜드 경험 설계 * organization: 미리디 디자인팀	* 브랜드 경험 설계 * 미리디 디자인팀
items	* 편집기 성능 개선 * organization: 미리디 개발팀	* 편집기 성능 개선 * 미리디 개발팀

슬롯	전	후
items	* 전체 공개	전체 공개

슬롯	전	후
items	* 원인: 생활관리 * 열 4: 연락	* 원인: 생활관리 * 연락

슬롯	전	후
items	* 제조·유통 3곳 * 하반기 신규 계약 * value: 42건 * period: 2025 하반기	* 제조·유통 3곳 * 하반기 신규 계약 * 42건 * 2025 하반기

슬롯	전	후
items	* 브랜드 경험 설계 * avatar: avatar-kim.png	브랜드 경험 설계
items	* 편집기 성능 개선 * avatar: avatar-lee.png	편집기 성능 개선

슬롯	전	후
emphasis	true	(빈 필드 · 임시 문구)

슬롯	전	후
label	* 응용 * weight: 0.2	응용
label	* 이해 * weight: 0.5	이해
label	* 기억 * weight: 0.8	기억

슬롯	전	후
label	* 신규 가입자 * emphasis: true	신규 가입자

슬롯	전	후
items	* 정책자금·상품 설명부터 하는 것 * 비교: 피해야 할 시작과 좋은 시작의 접근 방식을 비교한다.	* 정책자금·상품 설명부터 하는 것 * 피해야 할 시작과 좋은 시작의 접근 방식을 비교한다.

슬롯	전	후
label	* 끈기 * 교집합: 겹치는 부분은 문제해결력이다.	* 끈기 * 겹치는 부분은 문제해결력이다.

검사	분모	결과
#1487 · 비어 있지 않은 문자열 5종	후보 212,617행	205,652행에서 대치 글이 짧아짐. 내용 손실·blank 증가 없음.
#1487 · 공백 문자열 5종	같은 후보 전수	205,652행에서 빈 bullet 증가. 저장 자료의 발생 건수가 아닌 합성 스트레스 조건.
#1488 · 빈 문자열 5종	같은 후보 전수	205,652행의 binding 변화. 기존 일반 본문 보존. blank 증가 29,196행은 빈 필드 이동을 없앤 결과.
#1488 · 공백 문자열 5종	같은 후보 전수 · 보완 전 head	`33cfb07bf8` 당시 출력 변화 0, #1487 결합에서도 공백 bullet 잔존. 후속 수정·회귀 검증을 추가했다. 이 전수 실험은 재실행하지 않았다.
#1485 · 평탄화 글	같은 후보 전수	205,652행에서 글이 짧아짐. 내용 손실·blank·빈 bullet 증가 없음.
#1486 · 신호 없는 일반 본문	같은 후보 전수	1행에서 본문 binding 1 → 0. 위 구조 경계 사례; 실제 노출 확인 아님.
저장 입력의 query Frame 변화	유효 컴포넌트 1,405개	#1487 24 / #1488 0 / #1484 0 / #1485 5 / #1486 4. PR끼리 중복 가능한 수치.
공통 entity의 fallback 결과 변화	엣지 130개	#1487 15 / #1488 0 / #1484 0 / #1485 0 / #1486 9. 빈 값·평탄화 전용 경로는 다른 검사로 보충.

티켓	현재 티켓 범위	보완 제안
MOR-2770 초안	P3 규칙 1·1b·2의 규약·Eregion·단위 테스트, §2 신호 정의·강조 슬롯 검토.	빈 값 범위를 공백까지 명시한다. 작성자·출처의 역할, #1484 도달 경로, weight 수치 보존을 결정해 2771·2776에 넘긴다. 감사 연결 · MOR-2828 E5(비트·투영 해법), MOR-2820 D7(P3 문구), MOR-2833 F3(강조 슬롯 임시 문구). 코멘트 ↗
MOR-2771 초안	규칙 6의 §3.5 엣지 표·Eregion 구현. 도착지가 읽는 필드의 유지 정책은 임의로 바꾸지 않도록 명시돼 있다.	“신호 일괄 제외”를 바로 확정하기보다 2770의 의미 보존 결정을 먼저 받는다. #1486의 정렬 슬롯 제외와 투영 정책을 구분해 대조한다. 감사 연결 · MOR-2828 E5는 §3.5의 `emphasis: true` 이동을 두는 쪽이라 방향이 반대다. 코멘트 ↗
MOR-2778 초안	빈 문자열 버그·재현·Rust #1488 추적. 공백 방어 보완은 댓글에 기록됐다.	PR merged 여부와 #1487 결합 결과를 확인한다. 원래의 빈 값 재현과 이후 공백 보완 head를 구분한다.
MOR-2777 초안	평탄화 줄 표기 결정과 Rust·TS 본문 평탄화·골든. label+value, 다른 필드·values·들여쓰기를 검토한다.	현재 접두 제거 PR은 #1485로 연결한다. 본문의 초기 #1458 기록을 현재 담당 PR이나 main 반영으로 오해하지 않도록 구분한다. 감사 연결 · MOR-2820 D7의 「매출: 12억원」 한 줄 대 두 줄 질문이 같다. 코멘트 ↗
MOR-2769 초안	측정값 표기·P5·코드·골든. tier 1과 fallback 경로, 다국어 문구 정책을 포함한다.	옛 V3 생성기 범위 설명은 당시 전제로 읽는다. 저장 입력 5개와 직접 입력 경로를 보존하고, 목표·증감·임계값의 의미와 단위를 검증한다. 감사 연결 · MOR-2832 F1의 「delta: 5」, MOR-2812 C6의 measure 지도. 코멘트 ↗
MOR-2779 초안	P4·entities+columns의 머리글 누락·빈 값·공백 예외를 정본에 보충한다.	구현은 #1458로 main 반영됐다. 남은 일은 규약 보충이다. 실제 “열 4” 머리글·사용자 콜론·0·단위 보존을 문서 사례에 넣는다.
MOR-2768 초안	지어낸 항목·속성 N·본문 N·값 없음·내용 등의 채움 글 정책을 정하고, 빈 슬롯 선택 시 용량·순위 영향을 잰다.	빈 값 이동을 막는 #1488과 구분한다. 빈 슬롯이 임시 문구·벌점으로 바뀌는 사례를 연결해 영향 검증의 담당을 확정한다. 감사 연결 · MOR-2820 D7의 두 칸 들여쓰기, MOR-2833 F3의 빈 자리 채우기. 코멘트 ↗
MOR-2776 초안	확정한 Eregion 머지 커밋을 iUi에 sync하고 VENDOR.json·TS/Rust 통합 대조·결과를 기록한다.	1·1b·2·6의 정책이 확정된 결과를 입력으로 받는다. 4는 2777의 본문 평탄화, 5는 2769의 측정값 작업으로 연결하며 임의로 같은 sync 범위로 합치지 않는다.

감사 티켓	내용	겹치는 규칙·티켓·PR	겹치는 이유	남는 범위
MOR-2832 초안	F1 강조 노드에 "true", items에 "emphasis: true"·"delta: 5" 코멘트 ↗	규칙 6 · #1486 규칙 5 · MOR-2769	정렬 세 단계·용량 사전 필터에서 신호 필드를 글로 싣지 않고, 비트는 남기고, 강조 슬롯은 임시 문구로 두는 수정안이 #1486과 같다.	신호 부분은 #1486 머지로 해결된다. 「delta: 5」는 MOR-2769로 넘긴다.
MOR-2828 초안	E5 emphasis·weight를 글 슬롯·shape 비트로 만든다 코멘트 ↗	규칙 6 · #1486 MOR-2770 · MOR-2771	문제는 같은데 해법이 반대다. E5는 질의가 슬롯도 비트도 만들지 않고 투영 P3의 `emphasis: true` 이동(§3.5)은 둔다. #1486은 비트를 남기고 투영에서도 버린다.	비트를 남길지 끌지, §3.5를 어느 쪽으로 맞출지 한 번에 정한다. 정하기 전에는 두 수정이 서로를 되돌린다.
MOR-2829 초안	E6 avatar — 질의는 비트 10을 켜고 색인은 0행 코멘트 ↗	규칙 6 · #1486	#1486이 정렬 pass 2의 「avatar: URL」 이동을 막는다.	색인에 avatar가 0행이라 비트 10이 어긋나는 문제는 E6에 남는다.
MOR-2820 초안	D7 옮겨지는 내용의 글자 모양이 규약 예시와 다르다 코멘트 ↗	규칙 1·2·4 · #1487·#1484·#1485 MOR-2777 · MOR-2770 · MOR-2768	「값:」이 지금 어휘에서 닿지 않는다는 진단은 규칙 2 조사와 같다. 「value: 12억원」은 #1485, `period: …`는 #1487이 값만 남긴다. 「매출: 12억원」 한 줄 대 두 줄은 MOR-2777, P3 문구는 MOR-2770, 들여쓰기는 MOR-2768이다.	정렬이 값을 첫 items 앞에 두는 위치 차이만 D7에 남는다.
MOR-2812 초안	C6 I.I.S. measure 지도를 읽는 빌더가 없다 코멘트 ↗	규칙 5 · MOR-2769	둘 다 「measure를 생성하게 되면」이 전제다. C6은 색인·질의의 dataset, MOR-2769는 대치 글 표기다.	켤 때 함께 켠다. 관련 PR은 없다.
MOR-2819 초안	D6 관계를 그리지 않는 종의 tier 1에 relation을 그대로 싣는다 코멘트 ↗	규칙 7 · #1458	#1458이 정렬의 관계 종류 접두(「교집합:」·「비교:」)를 뗐다.	tier 1에 P7이 적용되지 않아 relationGap 벌점이 붙는다 — 이 하나만 남긴다. tier 1은 투영을 거치지 않아 그 종이 그리지 못하는 relation이 질의에 남고, 그 종류가 없는 후보마다 relation 하나당 3을 깎는다. tier 2·3은 P7이 relation을 빼 줘 벌점이 없다. 「desc 유실」은 뺐다 — #1458 머지로 tier 1의 desc가 접두어 없이 그대로 items에 붙는다(그 전에도 같은 자리에 붙었고 「교집합:」 접두어만 달려 있었다). 범위 코멘트 ↗
MOR-2833 초안	F3 임시 문구 정책(MOR-2627)이 규약에 없다 코멘트 ↗	규칙 6 · #1486 MOR-2770 · MOR-2768	#1486이 비운 강조 슬롯에 MOR-2627 규칙으로 임시 문구가 뜬다. 그 근거가 규약에 없다.	규약을 쓸 때 강조 슬롯 정책(MOR-2770)·채움 글(MOR-2768)과 같이 본다.

기존 head에서 실행한 로컬 결과다. 머지 후 main에서 재실행한 결과나 개별 PR의 최종 렌더 결과를 뜻하지 않는다.

PR	검증 head	Rust 통과	TS 통과
#1458 merged	`6b99594353`	888개	2,532개 · 51 skip
#1488	`33cfb07bf8`	891개	2,532개 · 51 skip
#1487	`bec77cb1bd`	891개	2,532개 · 51 skip
#1487 main 병합 후	`5d9150628e`	903개	2,631개 · 51 skip · 실패 1*
#1484	`aa58b8a6d0`	888개	2,532개 · 51 skip
#1485	`2e75e0f91a`	889개	2,533개 · 51 skip
#1486	`2f6f0a4950`	894개	2,533개 · 51 skip
#1486 main 병합 후	`86e58f05d4`	906개	2,632개 · 51 skip · 실패 1*

공통 검사: Rust 전체 테스트·fmt·workspace Clippy(--all-targets --all-features -- -D warnings), TS 132파일, 저장소 format:check·lint(오류 0·기존 경고 238)·앱 tsc·diff 검사. 분리·충돌 해소 후 별도 코드 리뷰에서도 추가 결함이 없었다.

2026-10-19 main 병합 후 · Rust 워크스페이스 테스트 전부 통과·fmt·Clippy 경고 0. TS는 src/comp-frame·comp-frame-shared·comp-frame-client 139파일을 돌렸다(main이 커져 수가 늘었다). * 실패 1건은 tableChart.test.ts의 Rust 사본 대조로, 그 테스트와 대상 파일을 PR이 건드리지 않아 main과 같다. format:check 통과·lint 오류 0·tsc node·scripts 0건, app은 기존 wasm-fx 5건이다.

PR 분리: 통합 PR #1483 닫힘 · 미머지은 닫고 후속 정책을 독립 PR로 나눴다. 빈 문자열 필드는 마지막으로 #1488에 분리했다. 커밋별 수정·검증 내역은 정리 전 기록에 보관했다.

담당 재정리: 2778과 겹치던 P3 규약·Eregion 구현은 2770에 모으고, 2776은 동기화·통합 검증만 맡도록 했다. 미결정인 측정값 정책은 2769에 남겼다. 당시 대조는 분리 전 기록에서 확인할 수 있다.

Jira 근거: PR 범위·검증·배포 조건 정정 · period 문제의 담당 PR 보충.

정본: mordor-wiki 규약·schema-v0.5.md. Eregion: 원본 TS 구현. 두 원천의 2026-10-18 origin/main을 다시 확인했다. 카드의 코드 위치·실측은 각 사례 당시 기준이다. 별도 origin/main 대조 기록.

규칙별 근거에 보존한 기존 18개 사례 썸네일은 분리 전 통합판의 역사적 비교다. 전 = 당시 origin/main 962dde1f5(1b만 cb3645e60), 후 = 별칭 리뷰 보강 전 4634def6e(18개 사례). 이후 통합 head ca5d4c555의 별칭 호스트 수정은 당시 회귀 테스트로 확인했다. 기존 18개 사례는 그대로 보존했다. 개별 PR의 새 렌더 5쌍은 2.6 전수 조사에서 별도 비교한다. 두 판의 comp-pass-logic::run_document_search 를 2.6판 후보 풀(excluded=false)에 돌리고, comp-frame-client buildFrameReplacement 로 대치해 preview 렌더러로 그렸다(글자 축소 끔). 문서 제목(pageTitle)은 넘기지 않아 경계 밖 제목 자리는 임시 문구다 — 전·후 조건은 같다. 「V3 생성 기록」은 iui.visual_summary_generations 의 YAML 그대로, 「합성 문서」는 V3 가 만들지 않는 필드를 보이려고 손으로 쓴 최소 v0.5 문서다. 재현 스크립트: ~/Documents/miricanvas-iui-pr-assets/mor-2516/scripts/.

현행 규약 v0.5.6

결정해야 할 사항 · 고르면 어떻게 되나

4가지 기준으로 규칙 분석

정하는 순서

결정 고르기

A 모든 문자열 필드에서 값만 남긴다 (#1487 그대로) 실측

B period·label은 값만, 역할 필드(author·source·speaker·organization)는 사람 말 이름을 붙인다 실측추천

C 정본 P3의 「이름: 값」을 그대로 쓴다 실측

A Rust 정렬·P3·용량 사전 필터에서 trim 뒤 빈 값을 옮기지 않는다 (#1488 그대로) 실측

B 규약에 「빈·공백 문자열은 필드가 없는 것과 같다」를 넣고 Rust·Eregion을 같은 기준으로 맞춘다 실측추천

C 빈 값 방어를 넣지 않는다 실측

A 머지하되 PR 설명에 「도달 경로 없음 · 방어적 정리」를 적는다 실측추천

B 실제 공개 투영 경로로 닿는 사례를 찾을 때까지 PR을 열어 둔다 실측

C PR을 닫고 닿지 않는 분기 자체를 지운다 실측

A #1458 구현을 그대로 두고 MOR-2779에서 P4 예외만 정본에 적는다 실측

B 머리글보다 많은 칸을 마지막 열에 쉼표로 다시 붙인다 (평탄화) 실측

C 생성 검증에서 행의 칸 수가 열 수와 다르면 실패로 보고 다시 생성한다 실측 · 대리 지표추천

A 키만 떼고 label과 값은 두 줄로 둔다 (#1485 그대로) 실측추천

B 키를 떼고 label과 값을 한 줄로 합친다 실측

C 평탄화 줄의 키를 그대로 둔다 실측

A 글로 옮기지 않고, 같은 이름 슬롯도 비우고, 질의 비트는 남긴다 (#1486 그대로) 실측

B weight는 본문에 같은 수치가 없을 때만 값으로 남기고 emphasis·avatar는 뺀다. 비운 강조 칸은 fieldBlank에서 뺀다 실측추천

C 질의가 신호로 슬롯·비트를 만들지 않고, fallback 투영의 §3.5 이동은 정본대로 둔다 실측

A 지금 표기(target: 80 · delta: 15.4)를 그대로 둔다 실측

B 「범위 0–100% · 목표 80% · 변화 +5 · 주의 기준 50%」처럼 적는다 실측추천

C 키를 일괄 제거한다 실측

A tier 1의 relationGap 벌점을 그대로 둔다 실측추천

B tier 1 질의에서도 그 카테고리가 그리지 못하는 relation을 뺀다 (desc는 지금처럼 items로) 실측

C 환경별 config.json 덮어쓰기로 relationGap 가중치를 낮춘다 실측

선택한 조합

화면 글 미리보기 · 지금 main과 비교

충돌과 주의

배포까지

규칙별 통합 판단 · PR·규약·Jira

1 · 문자열 필드 #1487

1b · 빈 문자열·공백 #1488

2 · value 접두 #1484

3 · 표 머리글 #1458

4 · 평탄화 접두 #1485

5 · 측정값 MOR-2769

6 · 신호 필드 #1486

7 · 관계 설명 #1458

PR #1458✓ merged

판정 회차 사례 · 규칙별 2026-10-19

Timeline 후보에 period 자리가 없다

Steps 후보의 유닛에 label 자리가 없다

Timeline → List, 투영 P3가 period를 옮긴다

ListingTable → List, 투영 뒤 정렬이 label을 옮긴다

ListingTable → List, 머리글 없는 셋째 칸

ComparisonTable → List, 머리글 없는 여섯·일곱째 칸

Versus 후보, 관계 설명에 종류가 붙었다

Transformation → Versus, 같은 정렬이 desc를 옮긴다

예시와 근거

구현 경로

분리 전 YAML·전후 이미지 · 4개

기간 슬롯이 없는 Timeline

출처 슬롯이 없는 QuoteTestimonial

QuoteTestimonial → HighlightedMessage (tier 2)

organization 슬롯이 없는 ProfileCard

구현 경로

분리 전 YAML·전후 이미지 · 1개

기간 슬롯이 없는 Timeline 에 period ""

구현 경로

구현 경로

분리 전 YAML·전후 이미지 · 1개

열 3개짜리 표에 칸 4개인 행 (ListingTable → List)

구현 경로

분리 전 YAML·전후 이미지 · 1개

중첩 컴포넌트를 벗기는 peel (stage N3)

구현 경로

분리 전 YAML·전후 이미지 · 5개

Gauge → Gauge, fallback 없음

Gauge → BigNumber (tier 2)

Gauge → BigNumber 의 임계값

Gauge → HighlightedMessage (P5)

Gauge → List (P5)

구현 경로

별칭 호스트 제외 · 분리 전 구현 검토

분리 전 YAML·전후 이미지 · 4개

ProfileCard 의 avatar

PR #1458 merged