후속 PR 5개는 진행 중. 모두 main 기준으로 열려 있으며, 원래 period: 노출 문제는 #1487의 머지·배포·결과 확인까지 추적한다. 여섯 PR의 CI·자동 리뷰 검사는 통과했다(2026-10-18 확인).
현행 규약 v0.5.6 · 기존 v0.5 사례 보존
2026-10-18에 확인한 현행 규약은 v0.5.6이다. mordor-wiki origin/maina0f8b01961의 §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 적용 범위
v0.5 → v0.5.6 변경 내역·버전 표기 점검
규약 버전
변경 내용
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 차이만으로 거부하지 않는 것이 규약의 검증 원칙이다.
문서와 구현의 구분: 정본 §0.1에는 버전 규칙의 “코드 반영은 아직”이라는 문구도 남아 있다. 그러나 Eregion origin/maine6ffa4bdf6의 검증 코드는 이미 0.5와 0.5.0~0.5.99를 함께 받는다. 버전 문자열을 받는 것과 개별 투영 정책의 구현·동기화 완료는 별개다.
대조 근거: 기존 a80aa5c097 → 최신 a0f8b01961에서 spec/ diff 없음. 핵심 세 파일의 Git blob도 동일하다. 버전·규약만 재확인했으며 사례를 새로 생성하거나 렌더하지 않았다.
규칙 한눈에 보기
표의 변화는 각 PR의 목표 범위이며, 정본 대조는 v0.5.6 · 2026-10-18 최신 main 기준이다. 아래 규칙 카드의 v0.5 입력·실측·썸네일은 분리 전 통합판 분석을 보존했다. 측정·렌더 기준
어긋남 (의도) 구현 방향에 맞춰 규약을 고칠 대상정본 없음 규약 보충 필요일치 현재 규약과 같음열린 문제 해석·표기 결정 필요
도착이 안 읽는 내용 필드는 그 entity 의 items 맨 뒤에 이름: 값 으로 붙인다.
정본대로면 period: 2018년 이 화면에 그대로 찍힌다. 필드 이름은 매핑 메타데이터(moves)에만 남긴다.
구현 범위:p3_text를 유지해 신호 필드의 기존 표기는 바꾸지 않는다. 신호 제외는 규칙 6에서 따로 처리한다.
2.6판 영향 범위 · 분리 전 측정 — 2.6판에서 그 필드 슬롯이 없고 글 자리(label·items)가 있는 행 — 선언 카테고리 안에서: period(Timeline·ResumeCV) 1,837행, speaker 123행, author 922행, source 1,836행, organization 5,268행. 카테고리와 상관없이 세면 20만 행 안팎이다(검증기가 필드를 카테고리로 막지 않는다).
통합판에서 키를 떼고 값만 옮기자 빈 항목이 드러났다. 분리 후에는 접두 제거(규칙 1)와 독립적으로 빈 문자열 자체를 이동 대상에서 제외한다. 접두를 붙이기 전에 빈 값인지 검사하므로 접두 제거에 의존하지 않는다. 비어 있지 않은 값의 표기는 이 규칙이 바꾸지 않는다. 정본은 빈 값을 다루지 않는다.
MOR-2778. 이 사례만 전 = 분리 전 통합판의 보강 전 head cb3645e60, 후 = 접두 제거와 빈 값 보강이 함께 든 4634def6e다. 이번 빈 문자열 PR의 단독 렌더는 아니다. 빈 bullet 이 붙으면 글상자가 목록 모양이 되어 왼쪽 위로 밀린다.
version: "0.5"
title: 서비스 출시 일정
components:
- type: TimelineSchedule.Timeline
structure:
entities:
- label: 베타 오픈
period: "2025년 3월"
items:
- 초대 사용자 대상
- label: 정식 출시
period: ""
items:
- 전체 공개
- label: 해외 진출
period: "2026년"
items:
- 일본·대만
검색 경로에서는 닿지 않는다. ① value 를 reads.content 로 선언한 카테고리는 BigNumber(measure?)·Gauge(measure) 둘뿐이다(vocab.json 45종·kernel 41종). ② 선택 dataset 도 dataset 을 가진 것으로 보니(capability_data.rs:136has_dataset) value 를 안 읽는 도착은 measure 도 못 읽어 P5 가 늘 같이 걸린다(projection.rs:80-83). ③ P5 가 걸리면 unread 에서 Value·Unit 을 지운다(projection.rs:224-228). BigNumber↔Gauge 는 서로 value 를 읽어 unread 가 아니다. 그래서 썸네일 사례가 없고, 단위 테스트(p3_merges_unread_value_and_unit_into_one_line·p3_keeps_unit_when_only_value_is_unread)로만 확인했다.
2.6판 영향 범위 · 분리 전 측정 — matrix 를 못 읽는 fallback·tier 3 도착(Versus·List·Steps·HighlightedMessage·LongForm·Timeline)의 items 행 118,431.
보충할 규칙: 실제 머리글이 있으면 열이름: 값을 유지하고, 머리글이 없거나 공백뿐이면 열 N이나 콜론을 생성하지 않고 값(단위가 있으면 단위 포함)만 보존한다. entities+columns 평탄화에도 같은 규칙을 명시해야 한다. 이 예외를 규약에 보충하는 작업은 아직 남아 있다.
사례 1개 · YAML·전후 이미지
열 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
평탄화한 줄에 필드 이름을 붙이지 않는다
value · unit · period · … · values
전value: 42% · values: 77→ 후42% · 77
어디서 생기나
평탄화 — 중첩 peel·종단 N5·표 행·용량 계산이 쓰는 글 줄
visual_summary/summary_content.rs:18 entity_lines
정본과 대조
열린 문제
schema-v0.5.md:956 · 8.7절 예시
위 예시가 평탄화되면 1분기 항목의 items 가 [신규 계약 12건, 매출 12억원] 이 된다
정본은 「중첩은 평탄화된다」(:115)까지만 규칙으로 적고 줄 표기는 정하지 않았다. 다만 예시는 { label: 매출, value: 12, unit: 억원 } 을 매출 12억원한 줄로 적는다. MOR-2516 수정은 키만 뗐고, label 과 값은 여전히 두 줄(매출 · 12억원)로 나눈다 — 예시와 다르다.
화면에는 중첩 컴포넌트를 벗길 때(peel)와 종단(List 등)으로 내려갈 때 보인다. 골든 nested.json·summary_content.json 이 이 변화를 잠근다.
2.6판 영향 범위 · 분리 전 측정 — 종단 세 카테고리의 items 행 107,398. peel 자식은 어느 카테고리든 되므로 상한은 items 행 전체 174,648.
사례 1개 · YAML·전후 이미지
중첩 컴포넌트를 벗기는 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 하반기
선택 내용 — period, weight, speaker, author, source, avatar, organization, children … → 옮긴다 (P3, P7)
mordor-wiki capability-table.md:315–317 · §3.5
BigNumber → List | value, unit, delta, emphasis 가 items 로 간다
mordor-wiki capability-table.md:389–391 · §3.5
ProfileCard → List | avatar, organization
mordor-wiki capability-table.md:392·394 · §3.5
Pyramid → List·Staircase | weight 가 items 로 간다
열린 문제
mordor-wiki capability-table.md:393 · §3.5
Pyramid → NestedScope | weight 는 표현 선택이라 버린다
정본 안에서 weight 가 엣지마다 다르게 적혀 있다. MOR-2516 수정은 늘 버린다.
schema-v0.5.md:51
강조(Element.Highlight)는 대치가 내용으로 채우는 노드 … entity.emphasis 가 담는다
강조 노드를 비울지, 강조된 entity 의 내용을 실을지는 정본 해석이 갈린다. MOR-2516 수정은 비운다(임시 문구).
2.6판에는 avatar 슬롯이 0행, weight 3행, emphasis 165행뿐이라 거의 늘 items 로 흘러 true·0.8·파일 이름이 찍혔다.
별칭 호스트도 신호 필드를 제외한다
적재는 FIELD_ORDER 순으로 같은 Text 노드의 첫 필드를 호스트로 잡는다. emphasis·weight가 speaker·author·source·organization보다 먼저 잡으면 본문 필드는 그 신호 슬롯의 별칭이 된다. pass 1.5는 쿼리 신호 필드를 걸렀지만 호스트에서는 Marker만 제외해, 일반 본문이 강조·가중치 칸에 들어갈 수 있었다.
호스트에도 !host.is_signal()을 적용했다. 신호 칸은 빈 필드로 남고, 본문은 다음 일반 별칭 호스트 또는 기존 items·폴백 경로를 따른다. 저장 데이터의 손상이 아니라 화면의 대치 위치가 잘못되는 문제다. 검색 후 용량 게이트는 정렬 결과를 다시 보므로 이번 누락으로 용량 초과 후보가 검사를 우회하는 것은 아니다.
2.6판 영향 범위 · 분리 전 측정 — BigNumber 중 emphasis 슬롯 있음 158 / 없음 8,063, Pyramid 중 weight 슬롯 있음 2 / 없음 360, ProfileCard 중 avatar 슬롯 0 (글 자리 있는 행 7,284).
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
관계는 종류 없이 desc 만 옮긴다
relations (intersects · compares)
전교집합: 겹치는 부분은…→ 후겹치는 부분은…
어디서 생기나
정렬 — 관계 desc 를 그 유닛 items 뒤에 붙인다
align.rs:1187 align_relations
정본과 대조
일치
mordor-wiki capability-table.md:290 · §3.4 P7
도착이 관계를 못 그리면 relation.desc 를 of 첫 항목의 items 맨 뒤로 보낸다
이번엔 코드가 정본에 맞춘 쪽이다. TS relationLines 는 2026-09-13 부터 이미 desc 만 옮겼고, Rust 정렬만 종류를 붙이고 있었다.
V3 가 실제로 만드는 relations 에서 나는 누출이라 운영 결과가 바뀐다.
빈 관계 설명:정렬도 Rust relation_lines·TS relationLines처럼 빈 desc를 건너뛴다. 회귀 테스트에서 본문·대치 종류·내용 손실이 관계 없음과 동일함을 확인했다. 이 보강은 빈 문자열 필드 PR #1488과 구분한다.
2.6판 영향 범위 · 분리 전 측정 — Versus·Venn 의 글 자리 행 3,128. 관계 desc 는 어느 후보의 items 에도 붙으니 상한은 글 자리 행 전체 205,288.
사례 2개 · YAML·전후 이미지
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 (투영 없음)
공통 검사: Rust 전체 테스트·fmt·workspace Clippy(--all-targets --all-features -- -D warnings), TS 132파일, 저장소 format:check·lint(오류 0·기존 경고 238)·앱 tsc·diff 검사. 분리·충돌 해소 후 별도 코드 리뷰에서도 추가 결함이 없었다.
이전 기록·출처·렌더 기준
PR 분리: 통합 PR #1483⊘ 닫힘 · 미머지은 닫고 후속 정책을 독립 PR로 나눴다. 빈 문자열 필드는 마지막으로 #1488에 분리했다. 커밋별 수정·검증 내역은 정리 전 기록에 보관했다.
담당 재정리: 2778과 겹치던 P3 규약·Eregion 구현은 2770에 모으고, 2776은 동기화·통합 검증만 맡도록 했다. 미결정인 측정값 정책은 2769에 남겼다. 당시 대조는 분리 전 기록에서 확인할 수 있다.
썸네일은 분리 전 통합판의 역사적 비교다. 전 = 당시 origin/main962dde1f5(1b만 cb3645e60), 후 = 별칭 리뷰 보강 전 4634def6e(18개 사례). 이후 통합 head ca5d4c555의 별칭 호스트 수정은 당시 회귀 테스트로 확인했다. 재분리한 개별 PR은 아직 재렌더하지 않았다. 두 판의 comp-pass-logic::run_document_search 를 2.6판 후보 풀(excluded=false)에 돌리고, comp-frame-clientbuildFrameReplacement 로 대치해 preview 렌더러로 그렸다(글자 축소 끔). 문서 제목(pageTitle)은 넘기지 않아 경계 밖 제목 자리는 임시 문구다 — 전·후 조건은 같다. 「V3 생성 기록」은 iui.visual_summary_generations 의 YAML 그대로, 「합성 문서」는 V3 가 만들지 않는 필드를 보이려고 손으로 쓴 최소 v0.5 문서다. 재현 스크립트: ~/Documents/miricanvas-iui-pr-assets/mor-2516/scripts/.
