아카이브 · 당시 기준

2026-10-22 보관. 1.8.0 → 1.9.0 · MINOR: 「결정해야 할 사항」의 제안 안을 모두 구현·실측해 결과·부작용을 실측값으로 바꾸고 2.6판 썸네일을 더했다. D8 추천은 실측에 따라 B → A 본문과 자동 동기화 표는 보관 당시 내용입니다.

현재 기준과 원본 보기 → · 보관 목록
miricanvas-iui · MOR-2516 · 2026-10-22 갱신 · 저자 홍지혜(jhhong) · 문서 v1.8.0 · 규약 v0.5.6 · 결정 지도 · 이전판

MOR-2516 투영 규칙

내용 대치 과정에서 코드가 붙이는 접두어를 정리하는 작업이다. 규칙별 변경·정본과의 차이·사례를 설명하고, Rust PR과 규약·Eregion·iUi 동기화의 담당을 구분한다.

현행 규약 v0.5.6

2026-10-18 정본 기준이며, 기존 v0.5 사례 18개와 분석·전후 이미지는 보존했다.

버전·분석 기준 자세히

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.1component.type 필수화. 당시 골든 470개는 이미 모두 type을 갖고 있었다.
0.5.2type의 대분류 21값을 제거하고 결합값을 사용한다.
0.5.3PageNavigation 4종을 enum에 반영해 인식 어휘를 41종에서 45종으로 맞췄다.
0.5.4NestedScope의 children 필수 조건을 빼고 선택 속성 direction: inward | outward를 추가했다.
0.5.5type 필수 여부와 어휘 수의 오래된 문구를 정정했다.
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 전수·저장 입력 1,405개·회차 1016 실측이다. 실측은 그 측정에서 나온 결과이고, 제안 · 재지 않았다는 구현도 측정도 없는 안이다. PR 상태는 2026-10-22에 다시 봤다 — #1484·#1485·#1486·#1487·#1488 모두 OPEN, head는 아래 「현재 PR head」 표와 같다.

먼저 · 규칙을 네 질문으로 가른다

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

규칙화면에 붙는 글① 그 글자는 누가 썼나② 키가 뜻을 싣나③ 값이 글인가④ 정본이 정했나결정
1 · period·labelperiod: 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

ㄱ. 코드가 붙인 키는, 그 키가 뜻을 싣지 않으면 뗀다. period·label·value·평탄화

ㄴ. 키가 뜻을 실으면 떼지 말고 사람이 읽는 말로 바꾼다. author·source·측정값

ㄷ. 값이 글이 아니면 글로 옮기지 않는다. 다만 그 값이 유일한 정보면 지킨다. weight·emphasis·avatar

ㄹ. fallback 투영에서 ㄱ~ㄷ을 따르면 정본 P3와 달라지니 정본을 같이 고친다. tier 1 정렬은 정본이 정하지 않은 자리라서 범위를 새로 적는다.

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

정하는 순서

  1. D1·D2·D3을 한 번에 — 셋 다 P3 문구라서 MOR-2770에서 한 번에 고친다. D1이 정해져야 D3(같은 방향인지)과 D2(빈 bullet이 생기는지)가 정해진다.
  2. D6을 MOR-2828 E5와 함께 — 해법이 반대라 따로 정하면 서로를 되돌린다. MOR-2771이 그 결과를 엣지별로 구현한다.
  3. D5 — 두 줄로 둘지 한 줄로 합칠지를 MOR-2777에서 재고 정한다.
  4. D7 — 측정값 생성을 켤 때 MOR-2769·MOR-2812 C6과 같이. D1-B를 골랐다면 표시 이름 표를 같이 쓴다.
  5. D4·D8 — 다른 결정과 얽히지 않아 따로 진행해도 된다.
  6. 마무리 — MOR-2776에서 Eregion·Rust를 대조하고, 검색 결과가 바뀌는 선택이 있으면 판을 다시 굽고 짝 증명서를 만든 뒤 배포한다.

결정 고르기

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

D1

문자열 필드의 키 이름

규칙 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 선택

추천 B · 원칙 ㄱ·ㄴ을 그대로 따르는 안이다. 지금 데이터에서는 A와 결과가 같아서, 더 드는 비용은 표시 이름 표 하나다.

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

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

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

author: 김민지
source: 2025 고객 조사
A를 고르면
* 최초의 장기 안정 왕조
* 1009~1225

해당 악기의 GAIN, LEVEL 올리기

김민지
2025 고객 조사
결과
회차 49행에서 키가 사라진다. 저장 입력 1,405개 중 query Frame 24개, fallback 엣지 130개 중 15개가 바뀐다. 후보 212,617행 합성 검사에서는 205,652행의 대치 글이 짧아졌고 내용 손실·빈칸 증가는 없었다.
부작용
  • 작성자와 출처가 한 본문에 모이면 둘을 구분할 수 없다(「김민지 / 2025 고객 조사」). 저장 입력에는 이런 필드가 0건이라 합성 사례로만 확인했다.
  • fallback에서 정본 P3와 달라진다. 정본을 고치고 Eregion을 맞추기 전까지 TS(Eregion 벤더)와 Rust의 결과가 갈린다.
  • 정본을 「값만」으로 고친 뒤 역할 필드를 생성하게 되면 정본을 다시 고쳐야 할 수 있다.
  • 글이 짧아져 용량 사전 필터를 통과하는 후보가 늘 수 있다. 검색 결과가 바뀐다.
  • 공백뿐인 값은 빈 bullet로 남는다. 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 고객 조사
결과
지금 데이터에서는 A와 결과가 같다. 저장 입력 1,405개와 회차 3,114행에 author·source·speaker·organization이 한 건도 없기 때문이다. 차이는 생성기가 역할 필드를 쓰기 시작할 때 생긴다. 표시 이름을 붙인 결과는 재지 않았다.
부작용
  • 필드마다 표시 이름 표가 필요하다. 다국어라서 문구 표를 호출자가 넘길지(임시 문구의 role_default_texts처럼), 규약에 고정할지 정해야 한다. D7-B와 같은 표를 쓸 수 있다.
  • 역할 필드는 「작성자 」만큼 글이 길어져 용량 계산에 들어간다.
  • 정본 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 고객 조사
결과
회차 49행이 계속 영어 키를 보인다. BAD 판정을 받은 Steps 사례에도 이 접두어가 있었다(BAD의 원인이 이것 하나인지는 따로 재지 않았다).
부작용
  • 코드·정본 변경이 없고 검색 결과도 그대로다.
  • tier 1 정렬의 접두어(label: 포함)는 정본이 정하지 않은 채로 남는다. MOR-2820 D7도 그대로다.
  • D5·D7에서 키를 떼면 이 규칙만 키가 남아 한 화면에서 표기가 섞인다.
할 일
#1487 닫기 · MOR-2770에 현행 유지 기록 · 규약 변경: 없음 · 검색 결과 그대로
D2

빈 값·공백 값

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

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

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

D2 선택

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

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

지금 main
* 본문
* period: 
A를 고르면
* 본문
(빈 값은 옮기지 않는다)
남는 설명 칸 → 「설명을 입력해주세요.」
결과
저장 입력과 회차 6,099행에 빈 값이 0건이라 운영 화면은 그대로다. 합성 검사에서는 205,652행의 binding이 바뀌고 빈칸이 29,196행 늘었다(빈 필드 이동을 없앤 결과). 사례 하나의 비용은 25.11 → 60.59로 올랐다.
부작용
  • 쓰레기 글로 채워지던 칸이 빈칸이 되어 임시 문구와 fieldBlank 벌점을 받는다. 순위가 바뀐다(MOR-2768).
  • Eregion(TS)에는 같은 방어가 없어 MOR-2776 대조에서 차이로 잡힌다.
할 일
#1488 머지 · MOR-2778 종료 · 규약 변경: 없음 · 검색 결과가 바뀐다

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

지금 main
* 본문
* period: 
B를 고르면
* 본문
(빈 값은 옮기지 않는다)
남는 설명 칸 → 「설명을 입력해주세요.」
결과
화면과 수치는 A와 같다. 차이는 TS·Rust 대조가 일치한다는 점이다.
부작용
  • 규약 개정과 Eregion PR이 하나 더 든다.
  • 생성기 검증에서 빈 값을 지울지 거부할지 정해야 한다. 거부하면 재시도가 늘고, 두 번 다 실패한 필수 레벨은 422가 된다. 지우는 쪽이 안전하다.
  • 직접 입력한 YAML 경로도 같은 기준을 받는다.
할 일
#1488 머지 · MOR-2770 규약·Eregion · MOR-2776 대조 · 규약 변경: 빈 값 = 필드 없음 명시 · 검색 결과가 바뀐다

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

지금 main
* 본문
* period: 
C를 고르면 · 지금과 같다
* 본문
* period: 
결과
빈 값이 0건이라 지금 화면은 그대로다.
부작용
  • D1을 A나 B로 고르면 공백 값이 빈 bullet로 남는다(보완 전 재현 사례).
  • 생성기가 빈 값을 쓰기 시작하면 그대로 화면에 나간다.
할 일
#1488 닫기 · 규약 변경: 없음 · 검색 결과 그대로
D3

value 이동의 「값:」

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

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

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

D3 선택

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

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

지금 main
값: 70억원   (지금 어휘로는 닿지 않는 분기)
A를 고르면
70억원   (단위 테스트로만 확인)
결과
입력 1,405개와 엣지 130개에서 출력 변화가 0이다. 검색 결과도 그대로라 판을 다시 구울 일이 없다.
부작용
  • D1을 C로 고르면 P3 안에서 「값:」만 떼고 「period:」는 남아 같은 규칙 안에서 표기가 섞인다.
  • 화면 개선으로 세면 안 된다.
할 일
#1484 머지 · PR 설명에 도달 경로 없음 명시 · 규약 변경: 없음 · 검색 결과 그대로

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

지금 main
값: 70억원   (지금 어휘로는 닿지 않는 분기)
B를 고르면 · 지금과 같다
값: 70억원   (지금 어휘로는 닿지 않는 분기)
결과
출력 변화는 0이다.
부작용
  • 열린 PR이 main과 계속 벌어져 충돌을 다시 풀어야 한다.
  • 결론이 안 날 수 있다. 「닿지 않는다」는 조사 결과이지 증명이 아니다.
할 일
MOR-2770에서 도달 사례 확보 · 규약 변경: 없음 · 검색 결과 그대로

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

지금 main
값: 70억원   (지금 어휘로는 닿지 않는 분기)
C를 고르면
(분기 없음)
결과
출력 변화는 0이다.
부작용
  • 나중에 value를 읽지 않는 도착 카테고리가 P5 없이 생기면 value가 조용히 사라진다. 그 경우를 막는 테스트가 필요하다.
  • 「모든 입력에서 닿지 않는다」는 증명이 아니라서 지우는 근거가 약하다.
할 일
#1484 닫기 · 분기 제거 PR · 규약 변경: 없음 · 검색 결과 그대로
D4

표에서 쪼개진 칸

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

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

왜 갈리나 · 쪼개진 값을 읽는 쪽에서 다시 붙일지, 쓰는 쪽에서 막을지다. #1458의 방어(A)는 이미 main에 있어서 B와 C는 그 위에 얹는다.

D4 선택

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

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

지금 main
* 내용: 1
* 000원
A를 고르면 · 지금과 같다
* 내용: 1
* 000원
결과
회차 11행에서 지어낸 머리글은 없지만 금액은 쪼개진 채 남는다.
부작용
  • 코드 변경이 없다.
  • 사용자는 「1」과 「000원」을 따로 본다.
할 일
MOR-2779 P4 문서 보충 · 규약 변경: P4 예외 보충 · 검색 결과 그대로

B 머리글보다 많은 칸을 마지막 열에 쉼표로 다시 붙인다 (평탄화) 제안 · 재지 않았다

지금 main
* 내용: 1
* 000원
B를 고르면
* 내용: 1,000원
결과
금액은 원래대로 돌아온다. 전체 영향은 재지 않았다.
부작용
  • 쉼표 뒤 공백을 알 수 없어 「스파르타반, 기숙연계반」은 「스파르타반,기숙연계반」이 된다.
  • 진짜로 머리글이 빠진 표(열이 실제로 더 많은 표)는 다른 열의 값이 한 칸에 합쳐져 뜻이 틀어진다. 둘을 구분할 방법이 없다.
  • 정본 P4에 새 규칙이 들고 Rust·TS 평탄화와 질의 Frame이 바뀐다. 검색 결과가 바뀐다.
할 일
평탄화 PR · MOR-2779 · 규약 변경: P4에 칸 합치기 규칙 · 검색 결과가 바뀐다

C 생성 검증에서 행의 칸 수가 열 수와 다르면 실패로 보고 다시 생성한다 제안 · 재지 않았다추천

지금 main
* 내용: 1
* 000원
C를 고르면
* 내용: 1,000원   (재생성이 따옴표를 붙이면)
결과
회차 11행의 원인을 없앤다. 재시도로 고쳐지는 비율은 재지 않았다. 서버 생성 검증(generate/validate.rs)에서 이 검사는 찾지 못했다(2026-10-22 확인).
부작용
  • 걸린 문서마다 LLM 호출이 한 번 더 든다. 두 번 다 실패하면 필수 레벨은 422 generation_failed다.
  • 직접 입력한 YAML 경로에는 효과가 없어 A의 방어는 그대로 둬야 한다.
  • 생성 검증을 바꾸면 특성화 골든을 다시 굽는다. 검색 로직은 그대로다.
할 일
생성 검증 PR · MOR-2779 · 규약 변경: 행 칸 수 = 열 수 명시 · 검색 결과 그대로
D5

평탄화 줄의 키

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

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

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

D5 선택

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

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

지금 main
* 총 대상
* value: 40명
A를 고르면
* 총 대상
* 40명
결과
평탄화 함수 결과 59개와 query Frame 5개가 바뀐다. 0·단위·사용자가 쓴 콜론은 그대로였다. 합성 검사 205,652행에서 글이 짧아졌고 손실·빈칸·빈 bullet은 늘지 않았다.
부작용
  • label과 값이 서로 다른 bullet이라 어느 값이 어느 항목인지 줄 순서에 기댄다.
  • 검색 결과가 바뀐다(Frame 5개).
할 일
#1485 머지 · 한 줄 결합은 MOR-2777 · 규약 변경: 없음 · 검색 결과가 바뀐다

B 키를 떼고 label과 값을 한 줄로 합친다 제안 · 재지 않았다

지금 main
* 총 대상
* value: 40명
B를 고르면
* 총 대상: 40명
결과
재지 않았다. 줄 수가 줄어 items 개수가 바뀌므로 A보다 정렬·용량·순위가 크게 움직인다.
부작용
  • 사용자가 쓴 콜론과 코드가 넣은 콜론을 구분할 규칙이 필요하다.
  • 출처나 다른 필드를 어떻게 합칠지까지 같이 정해야 한다(MOR-2777 범위).
  • 골든과 용량 계산을 같이 바꾼다. 정본 §8.7의 「매출 12억원」 예시와는 잘 맞는다.
할 일
#1485 보완 · MOR-2777 · 규약 변경: §8.7 한 줄 표기 일반화 · 검색 결과가 바뀐다

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

지금 main
* 총 대상
* value: 40명
C를 고르면 · 지금과 같다
* 총 대상
* value: 40명
결과
바뀌는 것이 없다.
부작용
  • D1에서 키를 떼면 P3 줄은 값만, 평탄화 줄은 키가 붙어 한 화면에서 표기가 섞인다.
할 일
#1485 닫기 · 규약 변경: 없음 · 검색 결과 그대로
D6

신호 필드(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 선택

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

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

지금 main
L1  * 82%
    * weight: 82
L2  일반 회원 → weight: 82
강조 칸  true
A를 고르면
L1  * 82%
L2  일반 회원 → (설명 임시 문구)
강조 칸  (임시 문구 「강조」)
결과
query Frame 4개와 fallback 엣지 9개가 바뀐다. 같은 생성 기록의 L2에서 82·15·3이 모두 사라지고 설명 두 칸이 임시 문구가 된다. 강조 칸만 글 자리인 후보 1행은 내용 손실이 0 → 2가 된다.
부작용
  • weight에만 있던 수치가 사라진다. 실제 저장 입력에서 재현했다.
  • 순위가 거꾸로 선다. 비트가 강조 슬롯 있는 후보를 stage 0에서 먼저 고르는데, 그 슬롯이 비어 fieldBlank 벌점을 받는다. 슬롯 없는 후보는 벌점이 없다.
  • 정본 §3.5(Pyramid→List의 weight를 items로, BigNumber→List의 emphasis 이동)와 어긋나고 E5와 방향이 반대다.
  • V3 생성기가 신호를 만들지 않아서 지금 운영 영향은 0이다.
할 일
#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
강조 칸  (비움 · 벌점 없음)
결과
재지 않았다. L1·L2 두 사례가 모두 의도대로 가는 유일한 안이다.
부작용
  • 「같은 수치」를 판정하는 규칙이 필요하다. 82와 82%, 0.82를 같다고 볼지 정해야 하고, TS·Rust·Eregion 세 곳이 똑같아야 한다.
  • weight에는 단위가 없어 「82」로 남길지 「82%」로 쓸지 정해야 한다.
  • 구현이 #1486보다 커서 PR을 보완해야 하고 정본 §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를 고르면
fallback  * 신규 가입자
          * emphasis: true   (남는다)
tier 1    강조 비트 없음 → 역전 없음
L2 weight만 있는 수치 → 재지 않았다
결과
재지 않았다. 정본은 고치지 않는다.
부작용
  • fallback에서 「emphasis: true」「weight: 82」 줄이 계속 보인다. D1·D5에서 키를 떼는 방향과 반대다.
  • 강조 슬롯이 있는 후보를 우대하던 검색이 사라져 그 후보들의 순위가 바뀐다.
  • #1486을 닫거나 다시 써야 한다.
  • avatar 비트 10 불일치(MOR-2829 E6)는 따로 남는다.
할 일
#1486 닫기 · MOR-2828 E5 구현 · 규약 변경: 없음 · 검색 결과가 바뀐다
D7

측정값(measure) 표기

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

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

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

D7 선택

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

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

지금 main
* 65%
* target: 80
* threshold: 50 주의 (warn)
A를 고르면 · 지금과 같다
* 65%
* target: 80
* threshold: 50 주의 (warn)
결과
바뀌는 것이 없다.
부작용
  • 영어 키와 state 값(warn)이 화면에 나온다.
  • D1·D5에서 키를 떼면 측정값만 키가 남는다.
할 일
MOR-2769에 현행 유지 기록 · 규약 변경: 없음 · 검색 결과 그대로

B 「범위 0–100% · 목표 80% · 변화 +5 · 주의 기준 50%」처럼 적는다 제안 · 재지 않았다추천

지금 main
* 65%
* target: 80
* threshold: 50 주의 (warn)
B를 고르면
* 65%
* 목표 80%
* 주의 기준 50%
결과
재지 않았다. 표기는 이 문서가 제안한 것이고 구현은 없다.
부작용
  • 다국어 문구 표가 필요하다. D1-B를 고르면 같은 표를 쓴다.
  • 단위 규칙이 까다롭다. delta에 주 값의 단위를 자동으로 붙이면 뜻이 바뀐다(1250억 원의 delta 15.4는 15.4%다).
  • tier 1(build_frame_for_structure)과 fallback(P5→P3) 두 경로를 같이 바꾼다. measure 색인(MOR-2812 C6)과 같이 켠다.
  • 검색 결과가 바뀐다.
할 일
MOR-2769 표기 결정·구현 · MOR-2812 C6 · 규약 변경: 측정값 표기 신설 · 검색 결과가 바뀐다

C 키를 일괄 제거한다 제안 · 재지 않았다

지금 main
* 65%
* target: 80
* threshold: 50 주의 (warn)
C를 고르면
* 65%
* 80
* 50
결과
범위·목표·증감·임계를 구분할 수 없다. 「0 / 100 / 80 / 5 / 50」만 남는다.
부작용
  • 의미가 사라진다. 원칙 ㄴ과 정면으로 어긋난다.
  • 「delta: 5」(MOR-2832 F1)는 사라지지만 5가 무엇인지도 같이 사라진다.
  • 검색 결과가 바뀐다.
할 일
권하지 않는다 · 규약 변경: P3·P5 측정값 키 삭제 · 검색 결과가 바뀐다
D8

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 선택

추천 B · tier와 상관없이 같은 기준으로 채점한다. C는 관계를 실제로 그리는 카테고리의 벌점까지 건드린다.

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

지금 main
화면 글: 「일회성 노출과 … 대비된다.」 (접두어 없음)
순위: 그 relation이 없는 tier 1 후보마다 −3
A를 고르면 · 지금과 같다
화면 글: 「일회성 노출과 … 대비된다.」 (접두어 없음)
순위: 그 relation이 없는 tier 1 후보마다 −3
결과
tier 1 후보 사이에서 그 relation 자리를 가진 후보가 앞선다.
부작용
  • tier 1과 tier 2·3의 채점 기준이 어긋난 채 남는다. MOR-2819 D6이 열려 있다.
할 일
MOR-2819에 유지 기록 · 규약 변경: 없음 · 검색 결과 그대로

B tier 1 질의에서도 그 카테고리가 그리지 못하는 relation을 뺀다 (desc는 지금처럼 items로) 제안 · 재지 않았다추천

지금 main
화면 글: 「일회성 노출과 … 대비된다.」 (접두어 없음)
순위: 그 relation이 없는 tier 1 후보마다 −3
B를 고르면
화면 글: 같다
순위: 그 relation 벌점 없음
결과
재지 않았다. 화면 글은 같고 순위만 바뀐다.
부작용
  • 검색 결과가 바뀐다. 골든과 특성화 골든을 다시 굽는다.
  • 정본에 「P7은 tier 1 질의에도 적용한다」를 적어야 한다.
  • 그 relation을 그릴 자리가 있는 tier 1 후보도 더는 앞서지 않는다.
할 일
로직 PR · MOR-2819 · 규약 변경: P7 적용 범위에 tier 1 · 검색 결과가 바뀐다

C 환경별 config.json 덮어쓰기로 relationGap 가중치를 낮춘다 제안 · 재지 않았다

지금 main
화면 글: 「일회성 노출과 … 대비된다.」 (접두어 없음)
순위: 그 relation이 없는 tier 1 후보마다 −3
C를 고르면
화면 글: 같다
순위: 낮춘 만큼 덜 깎는다 (모든 카테고리)
결과
재지 않았다. 재배포 없이 바로 바뀐다.
부작용
  • 가중치는 전역이라, 관계를 그리는 카테고리(Versus의 compares 등)에서 relation 자리가 없는 후보를 걸러 내던 정당한 벌점까지 약해진다.
  • 근본 원인(P7 범위)은 그대로다.
할 일
config.json 덮어쓰기 · MOR-2819 · 규약 변경: 없음 · 설정만 바뀐다

선택한 조합

결정고른 안PR정본 변경검색 결과

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

규칙별 사례에서 한 줄씩 모은 것이다. 한 문서에서 실제로 같이 나온 결과가 아니다. 바뀌는 줄은 색으로 표시했다.

결정줄지금 main이 조합

충돌과 주의

    배포까지

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

      표 머리글·관계 설명은 main 반영. 문자열·평탄화는 보완을 거쳐 적용하고, 신호 일괄 제외는 수치 보존 정책부터 정한다.

      2026-10-19 갱신 · #1486·#1487의 main 충돌을 풀어 head가 바뀌었다. 감사 마일스톤 MOR-2784의 겹치는 하위 티켓 7건을 연결했다.

      2026-10-18 확인 · 후보 데이터 2.6 · 규약 v0.5.6 · 저장 입력 v0.5
      조사는 #1458이 merged된 main 826cda2e31과 각 PR을 독립 비교한 기록이다. 현재 PR 상태·구현 범위는 아래 확인 head 기준이며, 여러 PR을 합친 결과를 재측정한 것은 아니다.

      212,617후보 행 전수
      170,717고유 디자인
      1,405Rust 유효 입력 컴포넌트
      130fallback 엣지 전수

      읽는 기준 · merged는 main 반영, PR 진행 중은 브랜치에 구현된 상태다. 적용 판단은 조사에 따른 권고이며, Jira의 완료 상태와 별개다.

      ↔ 표 안에서 좌우로 스크롤하면 나머지 열을 볼 수 있습니다.

      규칙 · 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과 공백 방어를 통합 확인한다. 작성자·출처가 한 본문에 섞일 때 의미를 남길 표기도 정한다.

      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도 같은 경로로 대조한다.

      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+값 결합·출처·다른 필드·들여쓰기를 정하고 본문·용량·골든을 함께 맞춘다. 접두 제거를 티켓 전체 완료로 표시하지 않는다.

      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을 나눠 검증한다.

      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은 정렬 슬롯도 막으므로 강조 슬롯의 수용 범위를 함께 맞춘다.

      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의 문자열 필드 방어는 서로 다른 범위다. 추가 정책 변경 근거는 이번 조사에서 확인하지 않았다.

      공통 후속: 규약·Eregion 변경을 확정한 뒤 MOR-2776에서 동기화·TS/Rust 대조한다. 빈 슬롯·지어낸 채움 글의 정책은 MOR-2768과 연결한다. 규약과 다른 정책은 해당 문서도 함께 바꿔야 한다.

      현재 PR head·Jira 상태·정본 확인 근거

      PR #1458 merged

      표 머리글·관계 desc 수정이 main에 반영됐다. 규칙 3 · 실제 머리글 보존 · 규칙 7 · 관계 설명만 이동

      머지: · 커밋 826cda2e31 · GitHub 상태 확인: 2026-10-18

      후속 PR 5개는 진행 중(2026-10-19 확인). 모두 main 기준으로 열려 있으며, 원래 period: 노출 문제는 #1487의 머지·배포·결과 확인까지 추적한다. 여섯 PR의 CI·자동 리뷰 검사는 통과했다(2026-10-18 확인).

      2026-10-18 GitHub API의 상태·diff·체크와 Jira 본문을 재확인했다. 여섯 PR의 check·comp-pass·자동 리뷰 체크는 SUCCESS다. 원격 체크 결과와 각 head의 로컬 검증 기록은 구분한다.

      PR확인 head / merged 커밋현재 상태
      #14586b99594353 / merged 826cda2e31✓ merged
      #1484aa58b8a6d0OPEN · base main
      #14852e75e0f91aOPEN · base main
      #148686e58f05d4
      10-18 2f6f0a4950 → main 병합 9ea9eb5e6 → 테스트 위치 정리
      OPEN · base main · 충돌 없음(10-19)
      #14875d9150628e
      10-18 bec77cb1bd → main 병합(p3_text는 이 PR 본문 + #1499의 pub(crate))
      OPEN · base main · 충돌 없음(10-19)
      #1488cb9ba9d989OPEN · base main

      연결된 MOR-2768·MOR-2769·MOR-2770·MOR-2771·MOR-2776·MOR-2777·MOR-2778·MOR-2779의 실제 표시 상태는 모두 초안이다. 티켓 본문에 적힌 구현 완료·미완료 표현보다 PR 상태를 우선해 구분했다.

      최신 origin/main: mordor-wiki a0f8b01961 · 현행 v0.5.6 / Eregion e6ffa4bdf6 · 기존 P3 접두·신호 이동이 남음. v0.5 입력·과거 전후 사례는 당시 기록으로 유지한다.

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

      정본 P3의 「이름: 값」은 fallback 투영에만 걸린다. tier 1에서 붙는 접두어는 정렬·질의 Frame이 혼자 정한 것이다. 그래서 같은 「접두어 떼기」라도 tier 1에서는 정본이 침묵하는 자리를 고치는 일이고, fallback 투영에서는 정본과 다르게 가는 일이다. 규칙마다 판정 회차의 실제 입력을 같은 D.O. 하나만 든 풀로 다시 돌려 지금 구현과 PR 적용을 나란히 구웠다.

      자료: 판정 회차 1016-c4-visual(run 314~320) 3,114행 전부 — 사용자 원문은 round-1016-c4-visual-material/cells.csv, YAML은 판정 원장 garbage_collector.judge_upload_rows.summary의 사본. 2.6판 iui.comp_frames(excluded=false, 2026-10-17 사본 212,617행)에서 행마다 그 D.O. 하나만 든 풀로 판별 run_document_search를 돌려 tier·투영·대치 글을 다시 냈다. 순위는 재현하지 않는다. 판별: 규칙 1 = main efdc4d638 → #1487 5d9150628, 1b·2·4 = 6b9959435 → 각 PR head, 3·7 = bcd1d0218 → #1458 6b9959435, 6 = efdc4d638 → #1486 86e58f05d. 회차 원본 그림은 그때(10-16) 코드로 구운 것이다.

      1 · 문자열 필드 · 판정 사례 4개 — tier 1 둘, fallback 둘

      ↑ 통합 표

      Timeline 후보에 period 자리가 없다

      #tier 12.6판 D.O. 13279786 · HStack_1 · TimelineSchedule_Timeline → TimelineSchedule_Timeline (투영 없음) · 판정 run 314 · ref 337 · ACCEPTABLE · 회차 그림 ↗

      Timeline 질의가 같은 카테고리 후보와 맞았다(투영 없음). 후보 유닛에 period 슬롯이 없어 정렬 pass 2가 기간을 period: …로 items 끝에 붙였다. 투영이 아니라서 정본 P3가 정한 글이 아니다. 판정 모델도 「연도 텍스트 앞에 'period:'가 추가」라고 적었다.

      사용자 입력 원문
      베트남 왕조
      리 왕조    1009~1225    최초의 장기 안정 왕조
      쩐 왕조    1225~1400    리 왕조의 선양을 받아 성립
      YAML (판정 원장 summary)
      version: "0.5"
      title: 베트남 왕조
      components:
        - type: TimelineSchedule.Timeline
          structure:
            entities:
              - label: 리 왕조
                period: "1009~1225"
                items:
                  - 최초의 장기 안정 왕조
              - label: 쩐 왕조
                period: "1225~1400"
                items:
                  - 리 왕조의 선양을 받아 성립
      지금 구현
      지금 구현 · main efdc4d638
      PR 적용
      PR 적용 · #1487 5d9150628
      지금 구현
      * 리 왕조의 선양을 받아 성립
      * period: 1225~1400
      PR 적용
      * 리 왕조의 선양을 받아 성립
      * 1225~1400
      지금 구현
      * 최초의 장기 안정 왕조
      * period: 1009~1225
      PR 적용
      * 최초의 장기 안정 왕조
      * 1009~1225

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

      #tier 12.6판 D.O. 11495150 · Graph_0 · ProcessFlow_Steps → ProcessFlow_Steps (투영 없음) · 판정 run 315 · ref 70 · BAD · 회차 그림 ↗

      Steps 질의가 Steps 후보와 맞았다(투영 없음). 네 번째 유닛에 label 슬롯이 없어 정렬 pass 2가 질의의 label을 label: …로 items에 옮겼다. label은 정본 P3 대상도 아니다.

      사용자 입력 원문
      1. 믹서 왼쪽에 위치한 멀티탭 전원 ON
      
      2. 믹서 아래쪽의 스피커 전원 버튼 ON
      
      3. 믹서 가장 오른쪽 MAIN 스피커 올리기
      
      4. 해당 악기의 GAIN, LEVEL 올리기
      YAML (판정 원장 summary)
      version: "0.5"
      title: 음향 장비 전원 및 레벨 설정 순서
      components:
        - type: ProcessFlow.Steps
          structure:
            entities:
              - label: 멀티탭 전원 ON
                items:
                  - 믹서 왼쪽에 위치
              - label: 스피커 전원 버튼 ON
                items:
                  - 믹서 아래쪽
              - label: MAIN 스피커 올리기
                items:
                  - 믹서 가장 오른쪽
              - label: 해당 악기의 GAIN, LEVEL 올리기
      지금 구현
      지금 구현 · main efdc4d638
      PR 적용
      PR 적용 · #1487 5d9150628
      지금 구현
      label: 해당 악기의 GAIN, LEVEL 올리기
      PR 적용
      해당 악기의 GAIN, LEVEL 올리기

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

      #fallback · tier 22.6판 D.O. 11891484 · Group_11 · TimelineSchedule_Timeline → Enumeration_List (P1 P2 P3) · 판정 run 314 · ref 302 · PERFECT · 회차 그림 ↗

      Timeline을 못 찾아 List로 내려갔다(P1 P2 P3). List는 period를 읽지 않아 투영 P3가 period: …를 items 맨 뒤에 붙였다. 정본 P3의 「이름: 값」 그대로라, #1487은 여기서 정본과 다르게 간다(MOR-2770).

      사용자 입력 원문
      9/29~9/30
      - 전체 기획안 정리
      - 피아테 아트페어 운영안 준비
      - 스탠드배너 방향 설정
      10/1~10/4
      - 피아테 아트페어
      10/1 ~ 10/11
      가을 꽃 축제
      10/6~10/10
      - 스탠드배너 디자인 / 출력 / 설치
      - 소금빵 A3 포스터 사전 작업
      - 독립서점 후보 리스트업 시작
      10/8~10/20
      - 독립서점 1차 컨택
      - 협업 가능 업체 확인
      - 첫 팝업 브랜드 선정
      10/15 전후
      - 소금빵 판매 및 포스터 부착
      10/15
      - 금산미학 팝업 오픈
      10/20~10/31
      - 독서 팝업 세부 운영안 확정
      - 매대 / 인테리어 / 사인물 준비
      - 상품 입고 및 최종 세팅
      11/1
      - 독서 팝업존 오픈
      YAML (판정 원장 summary)
      version: "0.5"
      title: 가을 행사 및 팝업 일정
      components:
        - type: TimelineSchedule.Timeline
          structure:
            entities:
              - label: 전체 기획안 정리
                items:
                  - 피아테 아트페어 운영안 준비
                  - 스탠드배너 방향 설정
                period: "9/29~9/30"
              - label: 피아테 아트페어
                period: "10/1~10/4"
              - label: 가을 꽃 축제
                period: "10/1~10/11"
              - label: 스탠드배너 디자인 / 출력 / 설치
                items:
                  - 소금빵 A3 포스터 사전 작업
                  - 독립서점 후보 리스트업 시작
                period: "10/6~10/10"
              - label: 독립서점 1차 컨택
                items:
                  - 협업 가능 업체 확인
                  - 첫 팝업 브랜드 선정
                period: "10/8~10/20"
              - label: 소금빵 판매 및 포스터 부착
                period: 10/15 전후
              - label: 금산미학 팝업 오픈
                period: "10/15"
              - label: 독서 팝업 세부 운영안 확정
                items:
                  - 매대 / 인테리어 / 사인물 준비
                  - 상품 입고 및 최종 세팅
                period: "10/20~10/31"
              - label: 독서 팝업존 오픈
                period: "11/1"
      지금 구현
      지금 구현 · main efdc4d638
      PR 적용
      PR 적용 · #1487 5d9150628
      지금 구현
      * 협업 가능 업체 확인
      * 첫 팝업 브랜드 선정
      * period: 10/8~10/20
      PR 적용
      * 협업 가능 업체 확인
      * 첫 팝업 브랜드 선정
      * 10/8~10/20
      지금 구현
      period: 10/1~10/4
      PR 적용
      10/1~10/4

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

      #fallback · tier 22.6판 D.O. 12806982 · Group_2 · Enumeration_ListingTable → Enumeration_List (P1 P2 P3 P4) · 판정 run 314 · ref 366 · BAD · 회차 그림 ↗

      표를 못 찾아 List로 내려갔다(P1~P4). P4가 행을 entity로 펴며 실제 머리글을 남겼고(1인당: 330396원), 후보 유닛에 label 자리가 없어 정렬이 label: 영양실조를 붙였다. fallback이어도 이 접두어는 정렬이 붙였다.

      사용자 입력 원문
      160명 기준 연간 금액
      
      영양실조
      1인당: 330,396원
      160명 52,863,360원
      
      영양결핍
      1인당 169,623원
      160명 27,139,680원
      우울증
      1인당 822,304원
      160명 131,568,640원
      
      합계
      1인당 1,322,323원
      
      160명 211,571,680원
      YAML (판정 원장 summary)
      version: "0.5"
      title: 160명 기준 연간 금액
      components:
        - type: Enumeration.ListingTable
          structure:
            entities:
              - label: 연간 금액
            dataset:
              shape: matrix
              columns:
                - label: 항목
                  role: category
                - label: 1인당
                  role: value
                  unit: 원
                - label: 160명
                  role: value
                  unit: 원
              rows:
                - [영양실조, 330396, 52863360]
                - [영양결핍, 169623, 27139680]
                - [우울증, 822304, 131568640]
                - [합계, 1322323, 211571680]
      지금 구현
      지금 구현 · main efdc4d638
      PR 적용
      PR 적용 · #1487 5d9150628
      지금 구현
      * 1인당: 330396원
      * 160명: 52863360원
      * label: 영양실조
      PR 적용
      * 1인당: 330396원
      * 160명: 52863360원
      * 영양실조
      지금 구현
      label: 연간 금액
      PR 적용
      연간 금액
      1b · 빈 문자열·공백 · 판정 사례 없음

      ↑ 통합 표

      판정 결과에서 뽑을 사례가 없다. 판정 회차 1013·1016의 YAML 6,099행 어디에도 빈 문자열·공백뿐인 값이(가) 없다. 운영 생성기(V3)가 이 필드를 쓰지 않기 때문이다. 이 규칙의 그림은 아래 「예시와 근거」의 분리 전 사례(V3 생성 기록·합성 문서)뿐이다.

      2 · value 접두 · 판정 사례 없음

      ↑ 통합 표

      판정 결과에서 뽑을 사례가 없다. 판정 회차 1013·1016의 YAML 6,099행 어디에도 entity의 value(과 그에 따른 P3 value 가지)이(가) 없다. 운영 생성기(V3)가 이 필드를 쓰지 않기 때문이다. 이 규칙의 그림은 아래 「예시와 근거」의 분리 전 사례(V3 생성 기록·합성 문서)뿐이다.

      3 · 표 머리글 · 판정 사례 2개 — 모두 fallback

      ↑ 통합 표

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

      #fallback · tier 22.6판 D.O. 12100260 · Group_9 · Enumeration_ListingTable → Enumeration_List (P1 P2 P3 P4) · 판정 run 314 · ref 399 · ACCEPTABLE · 회차 그림 ↗

      생성기가 [기존 알림받기 쿠폰, 1,000원]을 따옴표 없이 써서 YAML이 「1」·「000원」 두 칸으로 갈랐다. 머리글은 둘뿐이라 셋째 칸에 열 3:이 붙었다(P4 → List). #1458 뒤로 열 3:은 사라지지만 쪼개진 값은 남는다 — 생성기 따옴표 문제다.

      사용자 입력 원문
      | 항목 | 내용 |
      | --- | --- |
      | 운영 예정 기간 | 9/14 ~ 9/27 |
      | 대상 제품 | 골드렐라 펩타이드 28 안티멜라닌 에센스 |
      | 프로모션 목적 | 신규 고객 첫 구매 전환 + 한달사용 리뷰 확보 |
      | 기존 알림받기 쿠폰 | 1,000원 |
      | 신규 첫구매 쿠폰 | 5,000원 |
      | 한달사용 텍스트 리뷰 | 2,000P |
      | 한달사용 포토·동영상 리뷰 | 3,000P |
      YAML (판정 원장 summary)
      version: "0.5"
      title: 프로모션 운영 및 혜택 정보
      components:
        - type: Enumeration.ListingTable
          structure:
            dataset:
              shape: matrix
              columns:
                - label: 항목
                  role: category
                - label: 내용
                  role: category
              rows:
                - [운영 예정 기간, "9/14 ~ 9/27"]
                - [대상 제품, 골드렐라 펩타이드 28 안티멜라닌 에센스]
                - [프로모션 목적, 신규 고객 첫 구매 전환 + 한달사용 리뷰 확보]
                - [기존 알림받기 쿠폰, 1,000원]
                - [신규 첫구매 쿠폰, 5,000원]
                - [한달사용 텍스트 리뷰, 2,000P]
                - [한달사용 포토·동영상 리뷰, 3,000P]
      PR 적용 전
      PR 적용 전 · #1458 전 main bcd1d0218
      지금 구현 = PR 적용
      지금 구현 = PR 적용 · #1458 merged 6b9959435
      PR 적용 전
      * 내용: 5
      * 열 3: 000원
      지금 구현 = PR 적용
      * 내용: 5
      * 000원
      PR 적용 전
      * 내용: 1
      * 열 3: 000원
      지금 구현 = PR 적용
      * 내용: 1
      * 000원

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

      #fallback · tier 22.6판 D.O. 12741234 · HStack_1 · AttributeComparison_ComparisonTable → Enumeration_List (P1 P2 P3 P4) · 판정 run 314 · ref 212 · ACCEPTABLE · 회차 그림 ↗

      쉼표가 든 셀(스파르타반, 기숙연계반…)이 따옴표 없이 쓰여 행이 6~7칸이 됐다. 머리글이 5개라 열 6:·열 7:이 붙었다(P4 → List).

      사용자 입력 원문
      |  | 해커스 | 공단기 | 넥스트 | 박문각 |
      | --- | --- | --- | --- | --- |
      | 상품구조 | 패키지/패스/반등다양한상품 | 다양한패스·패키지 | 종합반 3종으로단순 | 4개 반 구성으로 단순 |
      | 가격비교 | 패키지/패스/반별비교가능 | 상품간비교어려움 | 종합반 별 가격 비교를 위해 사이트 하단까지 스크롤해야하는 불편함 | 스파르타반, 기숙연계반가격확인을위해서추가사이트를확인해야하는번거로움 |
      | 할인/혜택 | 풍부한이벤트 | 신규·환승·재수강, 룰렛이벤트 | 얼리버드중심 | 환급,재수강·환승·설명회 할인 |
      | 특징 | 상품·혜택다양 | 다양한상품 | 상품구조단순 | 상세한시험및수강정보 |
      YAML (판정 원장 summary)
      version: "0.5"
      title: 상품 비교
      components:
        - type: AttributeComparison.ComparisonTable
          structure:
            entities:
              - label: 상품 비교
            dataset:
              shape: matrix
              columns:
                - label: 비교 항목
                  role: category
                - label: 해커스
                  role: category
                - label: 공단기
                  role: category
                - label: 넥스트
                  role: category
                - label: 박문각
                  role: category
              rows:
                - [상품구조, 패키지/패스/반등다양한상품, 다양한패스·패키지, 종합반 3종으로단순, 4개 반 구성으로 단순]
                - [가격비교, 패키지/패스/반별비교가능, 상품간비교어려움, 종합반 별 가격 비교를 위해 사이트 하단까지 스크롤해야하는 불편함, 스파르타반, 기숙연계반가격확인을위해서추가사이트를확인해야하는번거로움]
                - [할인/혜택, 풍부한이벤트, 신규·환승·재수강, 룰렛이벤트, 얼리버드중심, 환급,재수강·환승·설명회 할인]
                - [특징, 상품·혜택다양, 다양한상품, 상품구조단순, 상세한시험및수강정보]
      PR 적용 전
      PR 적용 전 · #1458 전 main bcd1d0218
      지금 구현 = PR 적용
      지금 구현 = PR 적용 · #1458 merged 6b9959435
      PR 적용 전
      * 해커스: 패키지/패스/반별비교가능
      * 공단기: 상품간비교어려움
      * 넥스트: 종합반 별 가격 비교를 위해 사이트 하단까지 스크롤해야하는 불편함
      * 박문각: 스파르타반
      * 열 6: 기숙연계반가격확인을위해서추가사이트를확인해야하는번거로움
      지금 구현 = PR 적용
      * 해커스: 패키지/패스/반별비교가능
      * 공단기: 상품간비교어려움
      * 넥스트: 종합반 별 가격 비교를 위해 사이트 하단까지 스크롤해야하는 불편함
      * 박문각: 스파르타반
      * 기숙연계반가격확인을위해서추가사이트를확인해야하는번거로움
      PR 적용 전
      * 해커스: 풍부한이벤트
      * 공단기: 신규·환승·재수강
      * 넥스트: 룰렛이벤트
      * 박문각: 얼리버드중심
      * 열 6: 환급
      * 열 7: 재수강·환승·설명회 할인
      지금 구현 = PR 적용
      * 해커스: 풍부한이벤트
      * 공단기: 신규·환승·재수강
      * 넥스트: 룰렛이벤트
      * 박문각: 얼리버드중심
      * 환급
      * 재수강·환승·설명회 할인
      4 · 평탄화 접두 · 판정 사례 없음

      ↑ 통합 표

      판정 결과에서 뽑을 사례가 없다. 판정 회차 1013·1016의 YAML 6,099행 어디에도 중첩 component·children(평탄화가 도는 입력)이(가) 없다. 운영 생성기(V3)가 이 필드를 쓰지 않기 때문이다. 이 규칙의 그림은 아래 「예시와 근거」의 분리 전 사례(V3 생성 기록·합성 문서)뿐이다.

      5 · 측정값 · 판정 사례 없음

      ↑ 통합 표

      판정 결과에서 뽑을 사례가 없다. 판정 회차 1013·1016의 YAML 6,099행 어디에도 measure 데이터셋(min·max·target·delta·thresholds)이(가) 없다. 운영 생성기(V3)가 이 필드를 쓰지 않기 때문이다. 이 규칙의 그림은 아래 「예시와 근거」의 분리 전 사례(V3 생성 기록·합성 문서)뿐이다.

      6 · 신호 필드 · 판정 사례 없음

      ↑ 통합 표

      판정 결과에서 뽑을 사례가 없다. 판정 회차 1013·1016의 YAML 6,099행 어디에도 emphasis·weight·avatar이(가) 없다. 운영 생성기(V3)가 이 필드를 쓰지 않기 때문이다. 이 규칙의 그림은 아래 「예시와 근거」의 분리 전 사례(V3 생성 기록·합성 문서)뿐이다.

      7 · 관계 설명 · 판정 사례 2개 — tier 1 하나, fallback 하나

      ↑ 통합 표

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

      #tier 12.6판 D.O. 12209288 · HStack_1 · AttributeComparison_Versus → AttributeComparison_Versus (투영 없음) · 판정 run 314 · ref 339 · ACCEPTABLE · 회차 그림 ↗

      Versus 질의가 Versus 후보와 맞았다(투영 없음). 정렬 align_relations가 관계 설명을 items에 붙이며, #1458 전에는 앞에 비교:를 달았다.

      사용자 입력 원문
      콘텐츠의 지속성 = 고객 관계의 지속성
      
      SNS는 단순 노출 채널이 아니라, 고객과 관계를 쌓는 상시 브랜드 접점
      
      - 신메뉴 출시 때만 만나는 브랜드
       공지/프로모션/제품소개
       -> 이벤트 종료와 함께 관심도 종료
      
      - 일상에서 계속 대화하는 브랜드
       질문/반응/참여
       -> 친밀도를 축적하고 방문과 공유로 연결
      YAML (판정 원장 summary)
      version: "0.5"
      title: "콘텐츠의 지속성 = 고객 관계의 지속성"
      components:
        - type: AttributeComparison.Versus
          structure:
            entities:
              - label: 신메뉴 출시 때만 만나는 브랜드
                items:
                  - 공지/프로모션/제품소개
                  - 이벤트 종료와 함께 관심도 종료
              - label: 일상에서 계속 대화하는 브랜드
                items:
                  - 질문/반응/참여
                  - 친밀도를 축적하고 방문과 공유로 연결
            relations:
              - type: compares
                of: [신메뉴 출시 때만 만나는 브랜드, 일상에서 계속 대화하는 브랜드]
                desc: "일회성 노출과 지속적인 대화가 고객 관계의 지속성에서 대비된다."
      PR 적용 전
      PR 적용 전 · #1458 전 main bcd1d0218
      지금 구현 = PR 적용
      지금 구현 = PR 적용 · #1458 merged 6b9959435
      PR 적용 전
      * 이벤트 종료와 함께 관심도 종료
      * 비교: 일회성 노출과 지속적인 대화가 고객 관계의 지속성에서 대비된다.
      지금 구현 = PR 적용
      * 이벤트 종료와 함께 관심도 종료
      * 일회성 노출과 지속적인 대화가 고객 관계의 지속성에서 대비된다.

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

      #fallback · tier 22.6판 D.O. 12776332 · HStack_0 · Transformation_Transformation → AttributeComparison_Versus (P1 P2) · 판정 run 316 · ref 149 · ACCEPTABLE · 회차 그림 ↗

      Transformation을 못 찾아 Versus로 내려갔다(P1 P2). Versus는 compares를 그리므로 P7이 아니라 정렬이 desc를 옮기고, #1458 전에는 비교:가 붙었다.

      사용자 입력 원문
      BEFORE|정보 나열형 구조
      상품·가격
      → 기술 시연
      → 수출·회사 홍보
      → 핵심 기술
      → 제품 특징
      ↔ 기술 설명 반복
      → 용접 시연
      → 기술 비교
      ↔ 시연 콘텐츠 반복
      → 자동화 기술
      → 구매·사양
      → 납품·A/S·배송
      문제점
      정보 나열 → 기술 설명 반복 → 콘텐츠 간 연결 약화
      → 구매정보가 뒤늦게 등장 → 회사 신뢰 요소도 마지막에 제시
      → “그래서 이 제품이 내 공장에 왜 필요한가?”가 명확하지 않음
      AFTER|고객 설득형 구조
      첫 페이지
      → 타깃 고객 명확화
      → 고객의 문제에 공감
      → 문제 해결 솔루션 제안
      → 상품 공개 + 핵심 USP
      → 레이저용접기 VS 기존 용접기
      → 내쇼날시스템만의 기술적 차별점
      → 객관적 비교와 도입 근거
      → 리뷰·제품 구성·가격
      → 프로모션
      → 상담 및 구매 전환
      개선 효과
      제품 중심 설명
      → 고객 문제 중심 설득
      흩어진 기술 정보
      → 하나의 USP로 통합
      반복되는 시연 콘텐츠
      → 비교·근거 중심으로 정리
      뒤늦은 구매정보
      → 고객 여정에 맞춰 자연스럽게 연결
      단순 제품 소개
      → 문제 인식 → 공감 → 해결 → 신뢰 → 구매 전환
      YAML (판정 원장 summary)
      version: "0.5"
      title: 정보 나열형 구조에서 고객 설득형 구조로의 전환
      components:
        - type: Transformation.Transformation
          structure:
            entities:
              - label: BEFORE|정보 나열형 구조
                items:
                  - 상품·가격 → 기술 시연 → 수출·회사 홍보 → 핵심 기술 → 제품 특징
                  - 기술 설명 반복 ↔ 용접 시연 → 기술 비교
                  - 시연 콘텐츠 반복 ↔ 자동화 기술 → 구매·사양 → 납품·A/S·배송
                  - "문제점: 정보 나열 → 기술 설명 반복 → 콘텐츠 간 연결 약화"
                  - 구매정보가 뒤늦게 등장 → 회사 신뢰 요소도 마지막에 제시
                  - “그래서 이 제품이 내 공장에 왜 필요한가?”가 명확하지 않음
              - label: AFTER|고객 설득형 구조
                items:
                  - 첫 페이지 → 타깃 고객 명확화 → 고객의 문제에 공감 → 문제 해결 솔루션 제안
                  - 상품 공개 + 핵심 USP → 레이저용접기 VS 기존 용접기
                  - 내쇼날시스템만의 기술적 차별점 → 객관적 비교와 도입 근거
                  - 리뷰·제품 구성·가격 → 프로모션 → 상담 및 구매 전환
                  - "개선 효과: 제품 중심 설명 → 고객 문제 중심 설득"
                  - 흩어진 기술 정보 → 하나의 USP로 통합
                  - 반복되는 시연 콘텐츠 → 비교·근거 중심으로 정리
                  - 뒤늦은 구매정보 → 고객 여정에 맞춰 자연스럽게 연결
                  - 단순 제품 소개 → 문제 인식 → 공감 → 해결 → 신뢰 → 구매 전환
            relations:
              - type: compares
                of:
                  - BEFORE|정보 나열형 구조
                  - AFTER|고객 설득형 구조
                desc: 정보 나열형 구조를 고객 설득형 구조로 전환한다.
      PR 적용 전
      PR 적용 전 · #1458 전 main bcd1d0218
      지금 구현 = PR 적용
      지금 구현 = PR 적용 · #1458 merged 6b9959435
      PR 적용 전
      * 상품·가격 → 기술 시연 → 수출·회사 홍보 → 핵심 기술 → 제품 특징
      * 기술 설명 반복 ↔ 용접 시연 → 기술 비교
      * 시연 콘텐츠 반복 ↔ 자동화 기술 → 구매·사양 → 납품·A/S·배송
      * 문제점: 정보 나열 → 기술 설명 반복 → 콘텐츠 간 연결 약화
      * 구매정보가 뒤늦게 등장 → 회사 신뢰 요소도 마지막에 제시
      * “그래서 이 제품이 내 공장에 왜 필요한가?”가 명확하지 않음
      * 비교: 정보 나열형 구조를 고객 설득형 구조로 전환한다.
      지금 구현 = PR 적용
      * 상품·가격 → 기술 시연 → 수출·회사 홍보 → 핵심 기술 → 제품 특징
      * 기술 설명 반복 ↔ 용접 시연 → 기술 비교
      * 시연 콘텐츠 반복 ↔ 자동화 기술 → 구매·사양 → 납품·A/S·배송
      * 문제점: 정보 나열 → 기술 설명 반복 → 콘텐츠 간 연결 약화
      * 구매정보가 뒤늦게 등장 → 회사 신뢰 요소도 마지막에 제시
      * “그래서 이 제품이 내 공장에 왜 필요한가?”가 명확하지 않음
      * 정보 나열형 구조를 고객 설득형 구조로 전환한다.
      이 문서에 실린 기존 예시의 tier · 18개

      아래 「예시와 근거」의 분리 전 사례다(V3 생성 기록·합성 문서). 회차 1016에는 없던 규칙 1b·4·5·6의 사례는 이것뿐이다. 사례 이름을 누르면 그 사례로 간다.

      규칙사례 · tier · 후보
      1period 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
      1btimeline-empty-period tier 1 D.O. 13579287 TimelineSchedule_Timeline→TimelineSchedule_Timeline
      3listing-ragged-col fallback · tier 2 D.O. 13625758 Enumeration_ListingTable→Enumeration_List
      4nested-peel tier 1 D.O. 13631655 Enumeration_List→Enumeration_List
      5gauge-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
      6profile-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
      7versus-compares tier 1 D.O. 13209109 AttributeComparison_Versus→AttributeComparison_Versus
      list-intersects tier 1 D.O. 13634877 Enumeration_List→Enumeration_List

      예시와 근거

      표의 규칙별 링크로 조사 사례·구현 경로·기존 YAML을 함께 본다. 썸네일을 누르면 크게 볼 수 있다. 사례 제목 옆 #을 누르면 그 사례의 주소로 가고, 그 주소를 그대로 공유하면 접힌 묶음이 펼쳐진 채 열린다. 독립 PR 조사와 분리 전 통합판 렌더는 서로 다른 기록이며, 과거 후보 구조 집계는 실제 개선 건수·노출 빈도가 아니다.

      1 · 문자열 필드2.6 조사 2 · 분리 전 사례 4

      ↑ 통합 판단·PR·Jira

      1 · 권장 사례 — 기간 이름만 제거하고 날짜는 남는다

      저장 입력 V2 · d527f8fc-70fa-4587-b837-55dc1ccf3b41 / yaml_l1 · component 1b40e3f4921bbc4f · 2.6판 12070877 / HStack_1

      세 정상회담의 날짜 중 전용 period 슬롯이 없는 NATO 항목만 본문으로 이동한다. #1487은 period:만 제거했다. 원래 본문과 다른 두 날짜 슬롯은 유지됐다. Timeline 전체 5,043행을 검색한 상위 500개에서 전·후 공통 후보를 골랐다(전 순위 96). 순위 개선을 뜻하는 사례는 아니다.

      전
      * 중국을 '구조적 도전'으로 공식화
      * period: 6월 14일
      후
      * 중국을 '구조적 도전'으로 공식화
      * 6월 14일
      period · 전 · main / #1458 merged
      전 · main / #1458 merged
      period · 후 · #1487 단독
      후 · #1487 단독
      1·4 · 해석 주의 — 작성자와 출처의 역할은 값만으로 모호해질 수 있다

      합성 QuoteTestimonial 입력 · author: 김민지, source: 2025 고객 조사 · 저장 자료에는 author/source/speaker/organization 사례가 없었음

      이름·기관·출처를 서로 다른 전용 슬롯에 담는 경우에는 접두 제거가 읽기 좋다. 그러나 본문 한 칸으로 모으면 역할을 구분하던 정보가 표시에서 사라진다. 출처 표기가 중요한 자료에는 “작성자 김민지 · 출처 2025 고객 조사”처럼 의미를 살리는 규칙을 검토해야 한다. 이는 합성 사례에 대한 해석 위험이며, 저장 입력에서 발생한 결함 수로 세지 않았다.

      전
      author: 김민지
      source: 2025 고객 조사
      후
      김민지
      2025 고객 조사
      구현 경로·분리 전 사례 4개

      아래 코드 위치는 분리 전 통합판 4634def6e 기준이다. 별도 링크에 다른 head가 표시된 보완은 그 커밋 기준이다. 현재 담당 PR·규약·Jira 판단은 통합 표를 따른다.

      구현 경로

      문자열의 필드 이름은 화면 글에서 제거해도 이동 메타데이터에는 남긴다. #1487은 신호의 기존 표기까지 바꾸지 않으며, 신호 제외의 판단은 규칙 6에서 따로 다룬다.

      후보 구조 집계 · 분리 전 기록 — 2.6판에서 그 필드 슬롯이 없고 글 자리(label·items)가 있는 행 — 선언 카테고리 안에서: period(Timeline·ResumeCV) 1,837행, speaker 123행, author 922행, source 1,836행, organization 5,268행. 카테고리와 상관없이 세면 20만 행 안팎이다(구조만 센 상한이며, 생성 허용 필드나 실제 발생 건수가 아니다).

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

      기간 슬롯이 없는 Timeline

      # V3 생성 기록 2.6판 13482509 · Group_2 · tier 1 · Timeline (투영 없음)
      쿼리 YAML
      version: "0.5"
      title: 소프트웨어개발기록
      components:
        - type: TimelineSchedule.Timeline
          structure:
            entities:
              - label: v1
                period: "2018년"
              - label: v2
                period: "2019년"
              - label: v3
                period: "2024년"
      전
      전 · 962dde1f5
      후
      후 · 분리 전 통합판 4634def6e
      슬롯전후
      items
      period: 2018년
      2018년
      items
      period: 2019년
      2019년
      items
      period: 2024년
      2024년

      출처 슬롯이 없는 QuoteTestimonial

      # 합성 문서 2.6판 13050011 · VStack_0 · tier 1 · QuoteTestimonial (투영 없음)

      author 는 슬롯이 있어 제자리에 가고, source 만 옮겨진다.

      쿼리 YAML
      version: "0.5"
      title: 고객 후기
      components:
        - type: Utterance.QuoteTestimonial
          structure:
            entities:
              - label: 배송이 빠르고 포장이 꼼꼼해서 다음에도 이용하고 싶어요
                author: 김민지
                source: 2025 고객 만족도 조사
      전
      전 · 962dde1f5
      후
      후 · 분리 전 통합판 4634def6e
      슬롯전후
      label
      * 배송이 빠르고 포장이 꼼꼼해서 다음에도 이용하고 싶어요
      * source: 2025 고객 만족도 조사
      * 배송이 빠르고 포장이 꼼꼼해서 다음에도 이용하고 싶어요
      * 2025 고객 만족도 조사

      QuoteTestimonial → HighlightedMessage (tier 2)

      # 합성 문서 2.6판 13556260 · Group_8 · tier 2 · QuoteTestimonial → HighlightedMessage

      author·source 슬롯이 둘 다 없는 Quote 304행만으로는 tier 1 결과가 0건이라 tier 2 로 그렸다.

      쿼리 YAML
      version: "0.5"
      title: 고객 후기
      components:
        - type: Utterance.QuoteTestimonial
          structure:
            entities:
              - label: 배송이 빠르고 포장이 꼼꼼해서 다음에도 이용하고 싶어요
                author: 김민지
                source: 2025 고객 만족도 조사
      전
      전 · 962dde1f5
      후
      후 · 분리 전 통합판 4634def6e
      슬롯전후
      items
      author: 김민지
      김민지
      items
      source: 2025 고객 만족도 조사
      2025 고객 만족도 조사

      organization 슬롯이 없는 ProfileCard

      # 합성 문서 2.6판 13514020 · HStack_1 · tier 1 · ProfileCard (투영 없음)
      쿼리 YAML
      version: "0.5"
      title: 프로젝트 팀 소개
      components:
        - type: PortraitProfile.ProfileCard
          structure:
            entities:
              - label: 김하늘
                organization: 미리디 디자인팀
                items:
                  - 브랜드 경험 설계
              - label: 이도윤
                organization: 미리디 개발팀
                items:
                  - 편집기 성능 개선
      전
      전 · 962dde1f5
      후
      후 · 분리 전 통합판 4634def6e
      슬롯전후
      items
      * 브랜드 경험 설계
      * organization: 미리디 디자인팀
      * 브랜드 경험 설계
      * 미리디 디자인팀
      items
      * 편집기 성능 개선
      * organization: 미리디 개발팀
      * 편집기 성능 개선
      * 미리디 개발팀
      1b · 빈 문자열·공백2.6 조사 2 · 분리 전 사례 1

      ↑ 통합 판단·PR·Jira

      1b · 권장하되 화면 확인 — 빈 접두는 사라져도 임시 문구는 생긴다

      합성 경계 입력 · Timeline 3개 entity의 period: "" · 2.6판 13482509 / Group_2 · #1488 단독

      period: 만 있던 세 items binding이 사라졌다. 실제 본문을 잃은 것은 아니다. 다만 제품 대치가 남는 설명 칸에 “설명을 입력해주세요.”를 채웠고, 이 후보의 비용은 25.11 → 60.59로 올랐다. 빈 값 방어와 임시 문구 정책(MOR-2768)은 따로 확인해야 한다. 생성 기록에서는 이 다섯 문자열 필드의 빈 값을 발견하지 못했다.

      전
      items = "period: "
      후
      items binding 없음
      blank.role = Description → 임시 문구
      empty · 전 · main / #1458 merged
      전 · main / #1458 merged
      empty · 후 · #1488 단독 / 임시 문구 표시
      후 · #1488 단독 / 임시 문구 표시
      1·1b · 보완 전 재현 — 공백 bullet, #1488 후속 수정 완료

      합성 경계 입력 · items: [본문], period: " " · 2.6판 13482509 / Group_2

      #1488의 보완 전 head 33cfb07bf8은 is_empty()만 검사했다. #1487에서 접두를 떼면 공백 줄이 남고, 두 PR의 변경을 결합한 별도 실험에서도 같은 binding을 확인했다. 후속 커밋에서 이동 전 trim().is_empty() 검사를 정렬·P3·용량 사전 필터에 적용했다. 비어 있지 않은 원문의 앞뒤 공백은 보존한다. 아래 이미지와 결합 실험 수치는 보완 전 기록이다.

      아래 후 이미지는 #1487 단독이다. 렌더러가 공백 줄을 숨길 수 있으므로 빈 bullet 여부는 이미지뿐 아니라 binding 문자열로 판정했다. 실제 생성 기록의 공백 값 발생률은 이번 자료에서 0건이다.

      전
      * 본문
      * period:    
      후
      * 본문
      *    ← 공백만 있는 항목
      spaces · 전 · main / #1458 merged
      전 · main / #1458 merged
      spaces · 후 · #1487 단독 / 공백 binding 잔존
      후 · #1487 단독 / 공백 binding 잔존
      구현 경로·분리 전 사례 1개

      아래 코드 위치는 분리 전 통합판 4634def6e 기준이다. 별도 링크에 다른 head가 표시된 보완은 그 커밋 기준이다. 현재 담당 PR·규약·Jira 판단은 통합 표를 따른다.

      아래 이미지는 빈 문자열 보강 당시 기록이다. 이후 공백 방어 구현·검증은 MOR-2778 댓글에 기록했다.

      구현 경로

      MOR-2778. 이 사례만 전 = 분리 전 통합판의 보강 전 head cb3645e60, 후 = 접두 제거와 빈 값 보강이 함께 든 4634def6e다. 이번 빈 문자열 PR의 단독 렌더는 아니다. 빈 bullet 이 붙으면 글상자가 목록 모양이 되어 왼쪽 위로 밀린다.

      PR #1488 초기 head 33cfb07bf8 근거 (공백 보완 전): 정본 P3에는 빈 값 처리가 없다(MOR-2770). 정렬, 투영 P3, 용량 사전 필터가 접두어를 붙이기 전에 빈 값을 거른다. 다섯 빈 문자열 필드 회귀 테스트는 비어 있지 않은 필드의 접두 표기에 의존하지 않아 문자열 P3 PR과도 독립이다.

      후보 구조 집계 · 분리 전 기록 — 다섯 필드 중 하나라도 슬롯이 없고 items 가 있는 2.6판 행 174,648. 기간 슬롯 없는 Timeline 중 items 있는 행 1,461.

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

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

      # 합성 문서 2.6판 13579287 · Graph_1 · tier 1 · Timeline (투영 없음)

      바뀐 칸 근처만 잘라 그렸다.

      쿼리 YAML
      version: "0.5"
      title: 서비스 출시 일정
      components:
        - type: TimelineSchedule.Timeline
          structure:
            entities:
              - label: 베타 오픈
                period: "2025년 3월"
                items:
                  - 초대 사용자 대상
              - label: 정식 출시
                period: ""
                items:
                  - 전체 공개
              - label: 해외 진출
                period: "2026년"
                items:
                  - 일본·대만
      전
      전 · cb3645e60
      후
      후 · 분리 전 통합판 4634def6e
      슬롯전후
      items
      * 전체 공개
      
      전체 공개
      2 · value 접두2.6 조사 1 · 분리 전 사례 0

      ↑ 통합 판단·PR·Jira

      2 · 현재 효과 없음 — “값:” 분기는 일반 fallback에서 실행되지 않았다

      유효 입력 1,405개 query 생성 · 현행 어휘 45종의 fallback 130개 · #1484 단독

      두 검사 모두 변경된 출력은 0개다. 현재 value를 읽는 출발점에서 이를 읽지 않는 도착점으로 갈 때 P5가 먼저 적용되고, P3의 unread 목록에서 value·unit을 뺀다. #1484가 바꾸는 내부 분기만 보고 사용자 화면이 개선된다고 판단하면 안 된다. 머지 가치 판단 전에 실제 도달 경로를 추가로 제시하거나 방어적 정리임을 명시하는 편이 맞다.

      값 자체·0·단위를 보존하는 방향은 타당하지만 이 조사로 화면 개선 효과를 확인한 것은 아니다. 평탄화에서 보이는 value:는 #1485, 측정값의 target: 등은 MOR-2769 범위다.

      구현 경로·분리 전 경로 분석

      아래 코드 위치는 분리 전 통합판 4634def6e 기준이다. 별도 링크에 다른 head가 표시된 보완은 그 커밋 기준이다. 현재 담당 PR·규약·Jira 판단은 통합 표를 따른다.

      구현 경로

      당시 경로 분석에서 value를 읽는 도착은 BigNumber·Gauge였고, 선택 dataset도 has_dataset에서 있는 것으로 취급했다. value를 읽지 않는 도착에는 P5가 함께 적용되어 unread의 Value·Unit을 먼저 지웠다. BigNumber↔Gauge는 서로 value를 읽으므로 P3 이동 대상이 아니었다.

      내부 분기는 p3_merges_unread_value_and_unit_into_one_line·p3_keeps_unit_when_only_value_is_unread 단위 테스트로 확인했다. 아래 수치 0은 이 조사 경로의 결과이며, 모든 외부 입력에서 도달 불가능하다는 증명은 아니다. 렌더 사례는 없다.

      분리 전 경로 분석 — 확인한 검색 경로에서 출력 변화 0. 독립 PR 조사의 입력 1,405개·fallback 130개에서도 변화가 없었다.

      3 · 표 머리글기존 사례 1

      ↑ 통합 판단·PR·Jira

      아래 코드 위치는 분리 전 통합판 4634def6e 기준이다. 별도 링크에 다른 head가 표시된 보완은 그 커밋 기준이다. 현재 담당 PR·규약·Jira 판단은 통합 표를 따른다.

      구현 경로

      초기 구현 근거: 정본 P4의 실제 열이름: 값은 보존한다. 정본이 정하지 않은 빈 머리글·여분 열에서만 임의의 열 N을 만들지 않는 구현으로 보강했다.

      후보 구조 집계 · 분리 전 기록 — matrix 를 못 읽는 fallback·tier 3 도착(Versus·List·Steps·HighlightedMessage·LongForm·Timeline)의 items 행 118,431.

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

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

      # V3 생성 기록 2.6판 13625758 · VStack_19 · tier 2 · ListingTable → List

      바뀐 칸 근처만 잘라 그렸다.

      쿼리 YAML
      version: "0.5"
      title: 출결 원인 분석
      components:
        - type: Enumeration.ListingTable
          structure:
            entities:
              - label: 출결 원인 분석
                items:
                  - 🔴 신앙 포기
                  - 🟠 생활관리 및 기질
                  - 🟡 보고체계 미흡
                  - 🟢 개인사정
            dataset:
              shape: matrix
              columns:
                - label: 대상
                  role: category
                - label: 주요 내용
                  role: category
                - label: 원인
                  role: category
              rows:
                - [김종수, 연속 결석, 신앙 포기]
                - [김재희, 사유출석·인증, 생활관리, 연락]
                - [양기영, 인증·보고 문제, 보고체계 미흡]
                - [조부경, 대체예배, 개인 사정]
      전
      전 · 962dde1f5
      후
      후 · 분리 전 통합판 4634def6e
      슬롯전후
      items
      * 원인: 생활관리
      * 열 4: 연락
      * 원인: 생활관리
      * 연락
      4 · 평탄화 접두2.6 조사 1 · 분리 전 사례 1

      ↑ 통합 판단·PR·Jira

      4 · 접두 제거 권장 — 값·0·단위·사용자 콜론을 보존한다

      저장 입력 e79d4713-b6de-4c9c-ae70-3b19ba15103e / yaml_l2 / components[2] · a0ebc68fc2fb6679 · #1485 단독

      실제 List의 “총 대상 / 40명”, “아파트 거주 / 70.8%”에서 기계적인 value:가 사라진다. 유효 입력 1,405개 중 평탄화 함수 결과 59개, 실제 생성된 query Frame은 5개가 바뀌었다. 함수만 호출하면 바뀌는 경우와 검색 경로에서 쓰이는 경우를 구분했다.

      추가 합성 경계 입력에서 0억원과 label: 사용자 본문은 그대로였다. 다만 “매출”과 “0억원”은 여전히 별도 줄이다. label·값의 한 줄 결합, 출처·작성자의 의미 표시는 MOR-2777에서 별도로 정할 일이다.

      전
      총 대상
      value: 40명
      아파트 거주
      value: 70.8%
      후
      총 대상
      40명
      아파트 거주
      70.8%

      함께 볼 사례: 문자열·평탄화에서 작성자와 출처의 역할 구분.

      구현 경로·분리 전 사례 1개

      아래 코드 위치는 분리 전 통합판 4634def6e 기준이다. 별도 링크에 다른 head가 표시된 보완은 그 커밋 기준이다. 현재 담당 PR·규약·Jira 판단은 통합 표를 따른다.

      구현 경로

      이전 구현은 중첩 컴포넌트 peel과 종단(List 등) 변환에서 확인했으며, nested.json·summary_content.json 골든으로 결과를 고정했다. label·값의 한 줄 결합 여부는 위 통합 표의 MOR-2777 범위다.

      후보 구조 집계 · 분리 전 기록 — 종단 세 카테고리의 items 행 107,398. peel 자식은 어느 카테고리든 되므로 상한은 items 행 전체 174,648.

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

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

      # 합성 문서 2.6판 13631655 · VStack_3 · tier 1 · List (투영 없음)

      안쪽 컴포넌트의 value·period 가 부모 items 줄로 펼쳐진다.

      쿼리 YAML
      version: "0.5"
      title: 하반기 영업 성과
      components:
        - type: TimelineSchedule.Timeline
          structure:
            entities:
              - label: 하반기 신규 계약
                period: "2025 하반기"
                value: 42
                unit: 건
                components:
                  - type: Enumeration.List
                    structure:
                      entities:
                        - label: 대기업
                          items:
                            - 제조·유통 3곳
                        - label: 중견기업
                          items:
                            - IT 서비스 12곳
      전
      전 · 962dde1f5
      후
      후 · 분리 전 통합판 4634def6e
      슬롯전후
      items
      * 제조·유통 3곳
      * 하반기 신규 계약
      * value: 42건
      * period: 2025 하반기
      * 제조·유통 3곳
      * 하반기 신규 계약
      * 42건
      * 2025 하반기
      5 · 측정값2.6 조사 1 · 분리 전 사례 5

      ↑ 통합 판단·PR·Jira

      5 · 정책 먼저 — 숫자 이름을 일괄 제거하면 목표·범위를 구분할 수 없다

      저장 입력의 measure 5개 · 이 중 delta 포함 1개(3bf0c1b7e4b5fa96) · 아래는 min/max/target/threshold를 추가한 합성 경계 입력

      저장된 실제 예시는 1250억 원과 delta: 15.4, 본문의 “전년 대비 15.4% 증가”를 함께 갖는다. 중복은 줄일 수 있으나 delta에 주 값의 “억 원”을 붙이면 의미가 바뀐다. 나머지 네 measure는 값·단위만 있었다. 2.6 후보 Frame에 dataset.kind=measure가 0행인 것은 측정값을 쓸 수 없다는 뜻이 아니다. 쿼리에서 value/items로 풀어 일반 슬롯에 담는다.

      아래 이름을 전부 떼면 0 / 100 / 80 / 5 / 50의 역할을 잃는다. “범위 0–100% · 목표 80% · 변화 +5(단위 확인) · 주의 기준 50%”처럼 의미를 남길 표기를 MOR-2769에서 먼저 정해야 한다. 이는 제안 표기이며 현재 PR 결과가 아니다.

      전
      현재 재현 결과
      65%
      min: 0
      max: 100
      target: 80
      delta: 5
      threshold: 50 주의 (warn)
      후
      현 PR 적용 후에도 같은 측정값 접두 유지
      키만 일괄 삭제하는 변경은 보류
      state warn 삭제 여부도 별도 결정
      구현 경로·분리 전 사례 5개

      아래 코드 위치는 분리 전 통합판 4634def6e 기준이다. 별도 링크에 다른 head가 표시된 보완은 그 커밋 기준이다. 현재 담당 PR·규약·Jira 판단은 통합 표를 따른다.

      구현 경로

      분리 전 통합판 4634def6e도 측정값 표기를 바꾸지 않아 당시 main과 결과 목록·순위·cost가 같았다. 당시 V3 프롬프트에 KPI 타입이 없었다는 기록은 그 시점의 전제다. 현재 조사에서 확인한 저장 measure 입력 5개를 무영향으로 판단할 근거가 되지는 않는다.

      기존 접두가 남는 fallback은 P5→P3에 따른다. 같은 카테고리의 Frame 표기는 정본이 정하지 않았으므로 두 경로를 나누어 읽는다.

      후보 구조 집계 · 분리 전 기록 — items 행: Gauge 239, BigNumber 5,314, HighlightedMessage 10,266, List 69,014 (합집합 84,613).

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

      Gauge → Gauge, fallback 없음

      # 합성 문서 2.6판 12821819 · VStack_2 · tier 1 · Gauge (투영 없음)
      쿼리 YAML
      version: "0.5"
      title: 상반기 목표 달성률
      components:
        - type: KPIKeyMetric.Gauge
          structure:
            entities:
              - label: 상반기 목표 달성률
            dataset:
              shape: measure
              value: 87
              unit: "%"
              min: 0
              max: 100
              target: 80
      지금
      기존 렌더 · 당시 main과 통합판 동일 (모든 PR 범위 밖)

      Gauge → BigNumber (tier 2)

      # 합성 문서 2.6판 13602576 · Group_7 · tier 2 · Gauge → BigNumber
      쿼리 YAML
      version: "0.5"
      title: 상반기 목표 달성률
      components:
        - type: KPIKeyMetric.Gauge
          structure:
            entities:
              - label: 상반기 목표 달성률
            dataset:
              shape: measure
              value: 87
              unit: "%"
              min: 0
              max: 100
              target: 80
      지금
      기존 렌더 · 당시 main과 통합판 동일 (모든 PR 범위 밖)

      Gauge → BigNumber 의 임계값

      # 합성 문서 2.6판 13606965 · VStack_2 · tier 2 · Gauge → BigNumber
      쿼리 YAML
      version: "0.5"
      title: 서버 사용률
      components:
        - type: KPIKeyMetric.Gauge
          structure:
            entities:
              - label: CPU 사용률
            dataset:
              shape: measure
              value: 72
              unit: "%"
              min: 0
              max: 100
              thresholds:
                - at: 50
                  label: 주의
                  state: warn
                - at: 90
                  label: 위험
                  state: danger
      지금
      기존 렌더 · 당시 main과 통합판 동일 (모든 PR 범위 밖)

      Gauge → HighlightedMessage (P5)

      # 합성 문서 2.6판 13579650 · Group_3 · tier 2 · Gauge → HighlightedMessage
      쿼리 YAML
      version: "0.5"
      title: 상반기 목표 달성률
      components:
        - type: KPIKeyMetric.Gauge
          structure:
            entities:
              - label: 상반기 목표 달성률
            dataset:
              shape: measure
              value: 87
              unit: "%"
              min: 0
              max: 100
              target: 80
      지금
      기존 렌더 · 당시 main과 통합판 동일 (모든 PR 범위 밖)

      Gauge → List (P5)

      # 합성 문서 2.6판 13636373 · VStack_2 · tier 2 · Gauge → HighlightedMessage
      쿼리 YAML
      version: "0.5"
      title: 상반기 목표 달성률
      components:
        - type: KPIKeyMetric.Gauge
          structure:
            entities:
              - label: 상반기 목표 달성률
            dataset:
              shape: measure
              value: 87
              unit: "%"
              min: 0
              max: 100
              target: 80
      지금
      기존 렌더 · 당시 main과 통합판 동일 (모든 PR 범위 밖)
      6 · 신호 필드2.6 조사 3 · 분리 전 사례 4

      ↑ 통합 판단·PR·Jira

      6 · 권장 사례 — 본문에 수치가 있으면 weight 중복을 제거한다

      저장 입력 V2 · 8d16e136-492e-4b78-9dff-4baa77adc6a8 / yaml_l1 · component 0c0d0a92e5f74b9e · 2.6판 13332795 / Group_11

      일반·구독·VIP 회원 비율이 items의 82%·15%·3%에도 있다. #1486은 중복 weight를 제외해도 세 수치와 “매출 기여가 큼”을 보존한다. Pyramid 전체 363행 검색에서 전·후 같은 후보를 대치했다.

      전
      * 82%
      * weight: 82
      후
      82%
      weight-duplicate · 전 · main / #1458 merged
      전 · main / #1458 merged
      weight-duplicate · 후 · #1486 단독 / 본문 수치 보존
      후 · #1486 단독 / 본문 수치 보존
      6 · 실제 문제 — weight에만 있던 82·15·3이 사라진다

      같은 생성 기록의 yaml_l2 · component f8aee90fef12b085 · 2.6판 13332795 / Group_11 · 다른 생성 기록에서도 같은 입력 확인

      L2에는 비율이 weight에만 남아 있다. #1486 적용 후 82·15·3이 모두 대치 글에서 없어지고 앞의 두 설명 칸은 임시 문구가 됐다. 실제 저장 입력을 검색·대치·렌더해 확인한 의미 손실 사례다. 모두 제외하기 전에 의미 있는 수치를 value/items로 보존하거나, 기존 입력을 정상화할 규칙이 필요하다. 이 V2 기록을 현재 생성기의 발생 빈도로 일반화하지 않는다.

      전
      일반 회원 → weight: 82
      정기 구독 회원 → weight: 15
      연간 결제 VIP → 매출 기여가 큼 + weight: 3
      후
      일반 회원 → 설명 임시 문구
      정기 구독 회원 → 설명 임시 문구
      연간 결제 VIP → 매출 기여가 큼
      weight-only · 전 · main / #1458 merged
      전 · main / #1458 merged
      weight-only · 후 · #1486 단독 / 수치 손실
      후 · #1486 단독 / 수치 손실
      6 · 구조상 경계 — 일반 글을 받을 곳이 강조 슬롯 하나뿐인 행

      2.6판 13640649 / Group_2 · BigNumber·BarChart · emphasis 1개 + chartlike matrix · 합성 정렬 검사

      신호 입력 없이 label·items만 넣어도 기존 정렬은 emphasis 칸에 일반 글을 보냈다. #1486은 이 호스트를 막아 binding 1 → 0, content_loss 0 → 2가 됐다. 전체 후보에서 이 조건으로 일반 본문 손실이 늘어난 행은 이 1행이다.

      운영에서 노출된 회귀로 확정하지 않았다. 이 행을 포함한 BigNumber·BarChart 최소 문서를 실제 검색했을 때는 전·후 모두 후보 0건이었다. 합성 검사는 데이터셋·검색 게이트를 생략한다. 강조 슬롯을 비울지 실제 강조 본문을 받을지 정책·적재 분류를 확인할 근거로 남긴다. 현재 데이터에서 신호 필드가 별칭 호스트인 행은 없었다.

      전
      emphasis ← label + items
      content_loss: 0
      후
      emphasis ← blank
      label + items 유실 / content_loss: 2
      구현 경로·분리 전 사례 4개

      아래 코드 위치는 분리 전 통합판 4634def6e 기준이다. 별도 링크에 다른 head가 표시된 보완은 그 커밋 기준이다. 현재 담당 PR·규약·Jira 판단은 통합 표를 따른다.

      구현 경로

      정본 §3.5는 Pyramid→List·Staircase에서 weight를 items로 보내고, Pyramid→NestedScope에서는 표현 선택으로 버린다. BigNumber→List의 emphasis, ProfileCard→List의 avatar도 이동 대상으로 적혀 있다. 또한 강조 노드를 내용으로 채우는 규정이 있어, 모든 신호·슬롯을 일괄 비우는 PR과 적용 범위를 맞춰야 한다.

      옛 집계의 신호 슬롯은 avatar 0행·weight 3행·emphasis 165행이었다. 이는 슬롯 분포이며, 실제로 값이 글에 노출된 빈도가 아니다. 아래 별칭 분석도 코드 경계에 대한 기록이고, 이번 2.6 조사에서 신호 필드가 별칭 호스트인 행은 발견되지 않았다.

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

      적재는 FIELD_ORDER 순으로 같은 Text 노드의 첫 필드를 호스트로 잡는다. emphasis·weight가 speaker·author·source·organization보다 먼저 잡으면 본문 필드는 그 신호 슬롯의 별칭이 된다. pass 1.5는 쿼리 신호 필드를 걸렀지만 호스트에서는 Marker만 제외해, 일반 본문이 강조·가중치 칸에 들어갈 수 있었다.

      호스트에도 !host.is_signal()을 적용했다. 신호 칸은 빈 필드로 남고, 본문은 다음 일반 별칭 호스트 또는 기존 items·폴백 경로를 따른다. 이는 저장 데이터 손상보다 대치 위치 정책에 관한 경계다. 강조 칸을 비워 본문을 잃는 경우는 위 독립 PR 조사에서 별도로 확인했다. 검색 후 용량 게이트는 정렬 결과를 다시 보므로 이번 누락으로 용량 초과 후보가 검사를 우회하는 것은 아니다.

      후보 구조 집계 · 분리 전 기록 — BigNumber 중 emphasis 슬롯 있음 158 / 없음 8,063, Pyramid 중 weight 슬롯 있음 2 / 없음 360, ProfileCard 중 avatar 슬롯 0 (글 자리 있는 행 7,284).

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

      ProfileCard 의 avatar

      # 합성 문서 2.6판 13470888 · VStack_4 · tier 1 · ProfileCard (투영 없음)

      organization 은 슬롯이 있어 제자리에 간다.

      쿼리 YAML
      version: "0.5"
      title: 프로젝트 팀 소개
      components:
        - type: PortraitProfile.ProfileCard
          structure:
            entities:
              - label: 김하늘
                organization: 미리디 디자인팀
                avatar: avatar-kim.png
                items:
                  - 브랜드 경험 설계
              - label: 이도윤
                organization: 미리디 개발팀
                avatar: avatar-lee.png
                items:
                  - 편집기 성능 개선
      전
      전 · 962dde1f5
      후
      후 · 분리 전 통합판 4634def6e
      슬롯전후
      items
      * 브랜드 경험 설계
      * avatar: avatar-kim.png
      브랜드 경험 설계
      items
      * 편집기 성능 개선
      * avatar: avatar-lee.png
      편집기 성능 개선

      강조 슬롯이 있는 BigNumber

      # 합성 문서 2.6판 12793308 · VStack_2 · tier 1 · BigNumber (투영 없음)

      강조 칸에 true 가 찍히던 것이 빈 필드(임시 문구 「강조」)가 된다.

      쿼리 YAML
      version: "0.5"
      title: 3분기 핵심 지표
      components:
        - type: KPIKeyMetric.BigNumber
          structure:
            entities:
              - label: 신규 가입자
                value: 1200
                unit: 명
              - label: 재방문율
                value: 64
                unit: "%"
                emphasis: true
              - label: 평균 체류 시간
                value: 12
                unit: 분
      전
      전 · 962dde1f5
      후
      후 · 분리 전 통합판 4634def6e
      슬롯전후
      emphasis
      true
      (빈 필드 · 임시 문구)

      weight 슬롯이 없는 Pyramid

      # 합성 문서 2.6판 13616844 · Group_5 · tier 1 · Pyramid (투영 없음)
      쿼리 YAML
      version: "0.5"
      title: 학습 단계
      components:
        - type: Hierarchy.Pyramid
          structure:
            entities:
              - label: 응용
                weight: 0.2
              - label: 이해
                weight: 0.5
              - label: 기억
                weight: 0.8
      전
      전 · 962dde1f5
      후
      후 · 분리 전 통합판 4634def6e
      슬롯전후
      label
      * 응용
      * weight: 0.2
      응용
      label
      * 이해
      * weight: 0.5
      이해
      label
      * 기억
      * weight: 0.8
      기억

      강조 슬롯이 없는 BigNumber

      # 합성 문서 2.6판 13549097 · VStack_4 · tier 1 · BigNumber (투영 없음)

      emphasis: true 가 items 에 붙던 것이 사라진다.

      쿼리 YAML
      version: "0.5"
      title: 3분기 핵심 지표
      components:
        - type: KPIKeyMetric.BigNumber
          structure:
            entities:
              - label: 신규 가입자
                value: 1200
                unit: 명
                emphasis: true
              - label: 재방문율
                value: 64
                unit: "%"
      전
      전 · 962dde1f5
      후
      후 · 분리 전 통합판 4634def6e
      슬롯전후
      label
      * 신규 가입자
      * emphasis: true
      신규 가입자
      7 · 관계 설명기존 사례 2

      ↑ 통합 판단·PR·Jira

      아래 코드 위치는 분리 전 통합판 4634def6e 기준이다. 별도 링크에 다른 head가 표시된 보완은 그 커밋 기준이다. 현재 담당 PR·규약·Jira 판단은 통합 표를 따른다.

      구현 경로

      당시 TS relationLines는 이미 desc만 이동했고(2026-09-13부터), Rust 정렬에만 관계 종류 접두가 남아 있었다. 아래 생성 기록은 이 차이가 발생할 수 있는 실제 입력의 근거다. 운영 배포 결과를 확인한 기록은 아니다.

      빈 관계 설명: 정렬도 Rust relation_lines·TS relationLines처럼 빈 desc를 건너뛴다. 회귀 테스트에서 본문·대치 종류·내용 손실이 관계 없음과 동일함을 확인했다. 이 보강은 빈 문자열 필드 PR #1488과 구분한다.

      후보 구조 집계 · 분리 전 기록 — Versus·Venn 의 글 자리 행 3,128. 관계 desc 는 어느 후보의 items 에도 붙으니 상한은 글 자리 행 전체 205,288.

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

      Versus 의 compares

      # V3 생성 기록 2.6판 13209109 · HStack_0 · tier 1 · Versus (투영 없음)
      쿼리 YAML
      version: "0.5"
      title: 시작 방식의 비교
      components:
        - type: AttributeComparison.Versus
          structure:
            entities:
              - label: 피해야 할 시작
                items:
                  - "회사소개를 길게 하는 것"
                  - "통화 가능 여부부터 묻는 것"
                  - "정책자금·상품 설명부터 하는 것"
              - label: 좋은 시작
                items:
                  - "정책자금 신청 건 먼저 언급"
                  - "연락 목적을 짧게 설명"
                  - "바로 확인 질문으로 연결"
            relations:
              - type: compares
                of: [피해야 할 시작, 좋은 시작]
                desc: 피해야 할 시작과 좋은 시작의 접근 방식을 비교한다.
      전
      전 · 962dde1f5
      후
      후 · 분리 전 통합판 4634def6e
      슬롯전후
      items
      * 정책자금·상품 설명부터 하는 것
      * 비교: 피해야 할 시작과 좋은 시작의 접근 방식을 비교한다.
      * 정책자금·상품 설명부터 하는 것
      * 피해야 할 시작과 좋은 시작의 접근 방식을 비교한다.

      List 의 intersects

      # V3 생성 기록 2.6판 13634877 · VStack_2 · tier 1 · List (투영 없음)
      쿼리 YAML
      version: "0.5"
      title: 끈기와 적응력
      components:
        - type: Enumeration.List
          structure:
            entities:
              - label: 끈기
              - label: 적응력
            relations:
              - type: intersects
                of: [끈기, 적응력]
                desc: 겹치는 부분은 문제해결력이다.
      전
      전 · 962dde1f5
      후
      후 · 분리 전 통합판 4634def6e
      슬롯전후
      label
      * 끈기
      * 교집합: 겹치는 부분은 문제해결력이다.
      * 끈기
      * 겹치는 부분은 문제해결력이다.
      전수 범위·수치·한계·재현 근거

      세 종류의 검사를 구분했다

      1. 공급 전수: iui.comp_frames의 semantic_component_version=2.6 AND excluded=false 전량을 읽었다. 2026-10-18 02:34:29–02:35:52 KST, ID 구간 237개를 끝까지 페이지 조회했다. 212,617개 행 키가 모두 고유하고 필터 위반은 0이다. children·nested까지 슬롯·별칭을 센 결과, label/items가 있는 행 205,326, emphasis 161, weight 2, avatar 0, 신호 슬롯 합계 163행이다. 서로 다른 카테고리를 함께 가진 행은 카테고리별 합계에서 중복될 수 있다.
      2. 저장 입력 전수: 조회 기준 시각 이전 생성 기록 853건의 YAML 1,669개를 모두 읽었다. 파싱 실패 0. 완전히 같은 JSON을 합쳐 1,305문서·1,409컴포넌트를 얻었다. Rust 타입으로 읽을 수 없는 4개(items에 문자열 대신 객체)는 제외하고 1,405개를 실제 평탄화·query 생성 함수에 넣었다. 4개는 PR 적용 전부터 같은 오류이며 새 회귀로 세지 않았다. 입력은 모두 version 0.5이고 기록 날짜는 2026-09-10–10-15다.
      3. 경계 실험: 모든 후보에 유닛·children 모양이 같은 합성 쿼리를 넣어 실제 Rust align을 실행했다. 문자열 5종·빈 값·공백·신호·평탄화 글을 별도 시나리오로 검사했다. 데이터셋·nested 쿼리·관계·params와 검색·용량 게이트를 생략한 정렬 검사다. 전체 후보 × 모든 실제 입력의 검색·렌더를 수행한 것은 아니다. 별도로 현행 어휘 45종의 130개 fallback에 공통 경계 entity를 투영했고, 위 대표 사례 5쌍은 실제 검색·제품 대치·렌더를 거쳤다.
      검사분모결과
      #1487 · 비어 있지 않은 문자열 5종후보 212,617행205,652행에서 대치 글이 짧아짐. 내용 손실·blank 증가 없음.
      #1487 · 공백 문자열 5종같은 후보 전수205,652행에서 빈 bullet 증가. 저장 자료의 발생 건수가 아닌 합성 스트레스 조건.
      #1488 · 빈 문자열 5종같은 후보 전수205,652행의 binding 변화. 기존 일반 본문 보존. blank 증가 29,196행은 빈 필드 이동을 없앤 결과.
      #1488 · 공백 문자열 5종같은 후보 전수 · 보완 전 head33cfb07bf8 당시 출력 변화 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. 빈 값·평탄화 전용 경로는 다른 검사로 보충.

      이 수치를 장애율로 읽지 않는다. 합성 쿼리는 매번 같은 필드를 강제로 넣는다. 저장 입력에서 period는 115개 entity에 있었지만 speaker·author·source·organization·avatar는 없었다. 빈 문자열·공백 문자열도 없었다. weight는 6개 entity(고유 컴포넌트 2개), emphasis는 3개 entity(컴포넌트 2개)였다. 따라서 “모든 후보에 개선/결함이 발생한다”거나 현재 V3 생성기의 발생률이라고 해석할 수 없다.

      DB 읽기는 단일 트랜잭션 스냅샷이 아니다. 시작 시점의 최대 ID를 고정한 짧은 구간 읽기이며, 조회 도중의 행 수정까지 불변임을 보증하지 않는다. 공급 전수는 검색에서 제외되지 않은 2.6행 기준이고, dev/stg/prd가 서빙 중인 스냅샷 전체의 상태를 뜻하지 않는다. 규칙별 근거의 옛 후보 구조 집계는 당시 기록으로 유지했다. 이번 전수 수치와 합산하지 않는다.

      고정 소스·재현 파일

      기준 main 826cda2e31 (#1458 merged). 후속 head: #1487 bec77cb1bd · #1488 33cfb07bf8 · #1484 aa58b8a6d0 · #1485 2e75e0f91a · #1486 2f6f0a4950. 소스는 커밋별 별도 사본에서 빌드했다. 작업 중인 Rust 파일은 사용하지 않았다.

      근거 코드: P5 후 value·unit을 P3에서 제외 · 빈 문자열 검사 · measure 표기. 규약·Eregion 커밋은 위 v0.5.6 대조와 같다.

      로컬 재현 묶음: ~/Documents/miricanvas-iui-pr-assets/mor-2516/audit-2.6-2026-10-18/. data/fetch-receipt.json·census-quality.json·corpus-receipt.json, results/comparison.json, examples/ 입력·검색 결과, images/textmaps.json·새 이미지 10장, runner.rs·search-runner.rs·커밋별 소스와 빌드 기록을 보관했다. 후보 JSONL SHA-256: 04b489dd4a4cc67b4a45fb5cb1e5e32ded102bb545a871ae843ba16be78ff607.

      새 이미지 5쌍은 2026-10-18 재렌더. 제품 buildFrameReplacement·preview 렌더러, 글자 축소 끔. 후보 풀은 Timeline 5,043행 / Pyramid 363행이며 빈 값·공백 예시는 지정 디자인 1개 풀이다. 검색 문서 제목은 저장 원문 또는 합성 사례 제목을 사용했다. 경계 밖 제목을 위한 pageTitle은 전달하지 않아 남는 제목·설명 칸에 임시 문구가 보일 수 있다. 렌더에 사용한 클라이언트·프로토콜·렌더 스크립트는 기준 main과 diff가 없음을 확인했다.

      권장 반영 순서
      1. MOR-2770에서 문자열·빈 값 규약과 Eregion을 맞추고 #1487+#1488 통합 사례를 확인한다.
      2. #1485의 접두 제거를 확인하고, MOR-2777에서 label·값·출처의 줄 표기를 정한다.
      3. MOR-2770·MOR-2771에서 weight 수치 보존·도착 필드 유지·강조 슬롯 정책을 맞춘 뒤 #1486을 보완한다.
      4. #1484의 실제 도달 경로와 MOR-2769의 측정값 표기를 확인한다. MOR-2779의 P4 문서 보충은 이미 merged된 구현에 맞춘다.
      5. MOR-2776에서 확정한 Eregion·Rust 커밋을 기준으로 동기화·대조한다. 배포 전 서빙 판 재굽기·짝 증명서를 별도로 확인한다.

      이 순서는 조사에 따른 권고다. PR 머지·티켓 완료·배포 실행을 뜻하지 않는다.

      Jira 연계 · 현재 범위와 남은 확인

      규약·Eregion 구현 → iUi 동기화 → TS·Rust 대조. 2026-10-18에 아래 8개 티켓 본문과 초안 상태를 확인했다. 규칙별 판단은 위 통합 표에서 함께 본다.

      티켓별 현재 담당과 보완 제안 · 8개

      “현재 티켓 범위”는 Jira에서 읽은 내용이고, “보완 제안”은 이번 조사로 추가 확인이 필요한 항목이다.

      티켓현재 티켓 범위보완 제안
      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 범위로 합치지 않는다.
      감사 마일스톤 MOR-2784와 겹치는 티켓 · 7개 (2026-10-19)

      MOR-2784(6층 계약 정합 감사) 하위 58건 가운데 7건이 이 문서의 규칙·티켓과 겹친다. 감사 티켓은 모두 남겼다. 양쪽 티켓에 겹치는 이유와 PR 상태를 코멘트로 달고 Relates 링크 14개로 이었다. 이 문서 쪽 티켓 가운데 감사 티켓과 통째로 겹치는 것은 없어 닫은 티켓도 없다. 전체 목록은 MOR-2516의 코멘트 ↗에 있다.

      감사 티켓내용겹치는 규칙·티켓·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)과 같이 본다.

      Relates 링크: 2832↔2516·2769, 2828↔2516·2770·2771, 2829↔2516, 2820↔2516·2770·2777·2768, 2812↔2769, 2819↔2516, 2833↔2770·2768. 감사 쪽 근거 커밋은 iUi a54bfb2e0, 이 문서의 정정 근거는 iUi main 47b76932a이다.

      MOR-2776 동기화·검증 절차
      1. 입력 고정. MOR-2770·MOR-2771의 규약·Eregion PR과 실제 merged 커밋, 대응하는 Rust 기준 커밋을 기록한다.
      2. 동기화. sync-eregion으로 벤더 사본·VENDOR.json을 갱신하고 sync-eregion --check를 통과시킨다.
      3. 경로를 맞춰 대조. 벤더 결과끼리, iUi 어댑터 결과끼리 structure·params·rules·losses를 비교한다. Rust 정렬의 슬롯 제외를 Eregion 투영과 같은 기능으로 가정하지 않는다.
      4. 내용 보존도 검증. 공백 종류·비어 있지 않은 원문, value의 0·단위, weight의 유일한 수치와 중복 수치, 도착지가 읽는 필드의 유지 사례를 함께 확인한다.

      규칙 결함은 MOR-2770·MOR-2771, 동기화·대조 경계는 MOR-2776에서 수정한다. 두 구현이 같은 수치를 잃는 결과는 일치하더라도 내용 보존 조건을 통과한 것으로 보지 않는다.

      통합 후 배포

      LOGIC_ID 유지·(b) 검증 블록이 있는 서빙 판 재굽기 방침이다. stg/prd 배포 전에 판 재굽기와 태그·환경별 짝 증명서 갱신이 필요하다. 이 문서에서는 배포 완료를 확인하지 않았다.

      검증 기록 · PR별 head와 로컬 결과

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

      PR검증 headRust 통과TS 통과
      #1458 merged6b99594353888개2,532개 · 51 skip
      #148833cfb07bf8891개2,532개 · 51 skip
      #1487bec77cb1bd891개2,532개 · 51 skip
      #1487 main 병합 후5d9150628e903개2,631개 · 51 skip · 실패 1*
      #1484aa58b8a6d0888개2,532개 · 51 skip
      #14852e75e0f91a889개2,533개 · 51 skip
      #14862f6f0a4950894개2,533개 · 51 skip
      #1486 main 병합 후86e58f05d4906개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/.

      예시 이미지 확대

      2배 확대 후 스크롤로 살펴볼 수 있습니다. 바깥 영역이나 Esc 키로 닫습니다.