후속 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도 동일하다. 이 규약 버전 대조에서는 기존 18개 사례를 재생성·재렌더하지 않았다. 별도 2.6 전수 조사에는 개별 PR의 새 비교 5쌍을 추가했다.
period·speaker·author·source·organization의 값이 빈 문자열 또는 공백뿐이면, 접두어를 붙이기 전에 이동을 건너뛴다. 정렬·투영 P3·용량 사전 필터가 trim().is_empty()로 같은 기준을 적용한다. trim()은 검사에만 쓰며 실제 글이 있는 값의 앞뒤 공백·사용자 콜론을 보존한다.
Rust 전체 893개 통과, workspace Clippy·Rust fmt·저장소 format:check·lint(오류 0, 기존 경고 238)·diff 검사 통과. 앱 tsc는 변경하지 않은 src/page-outline/LatestOutlineForDemo.ts:38의 기존 nullable Promise 오류 1건으로 실패했다. TS 전체 테스트·2.6 전수 조사·썸네일은 이번 보완에서 재실행하지 않았다. 아래의 이전 수치·이미지는 당시 head의 기록으로 보존했다.
MOR-2778은 버그·Rust PR 추적, MOR-2770은 규약·Eregion 구현, MOR-2776은 iUi 동기화·TS/Rust 대조를 맡는다. 정본 P3는 여전히 빈 값·공백 처리를 명시하지 않는다. LOGIC_ID 유지·(b) 서빙 판 재굽기 방침을 유지하며 배포·재굽기는 실행하지 않았다.
2.6판 전수 조사 · 그대로 적용할 것과 보완할 것
문자열·평탄화 접두 제거는 유용하다. 빈 값의 공백 검사 보완은 #1488에 추가했다. 신호 필드 일괄 제외는 weight의 의미 손실부터 해결해야 한다. #1484는 현재 경로에서 출력 효과가 없었고, 측정값은 이름을 지우기 전에 표기 정책이 필요하다.
2026-10-18 · 후보 데이터 2.6 / 현행 규약 v0.5.6 / 저장 입력 v0.5 / 이 문서 v1.2.0. 서로 다른 버전이다. PR #1458이 merged된 main 826cda2e31과 각 후속 PR을 독립 비교했다.
“권장”은 변경 방향에 대한 판단이다. 규약 v0.5.6과의 어긋남이나 TS 동기화가 해결됐다는 뜻은 아니다. 아래 사례 제목을 누르면 전후 글·썸네일이 펼쳐진다. 이미지를 누르면 크게 볼 수 있다.
1 · 권장 사례 — 기간 이름만 제거하고 날짜는 남는다
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일
전 · main / #1458 merged후 · #1487 단독
1b · 권장하되 화면 확인 — 빈 접두는 사라져도 임시 문구는 생긴다
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 → 임시 문구
전 · main / #1458 merged후 · #1488 단독 / 임시 문구 표시
1·1b · 보완 전 재현 — 공백 bullet, #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:
후
* 본문
* ← 공백만 있는 항목
전 · main / #1458 merged후 · #1487 단독 / 공백 binding 잔존
6 · 권장 사례 — 본문에 수치가 있으면 weight 중복을 제거한다
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%
전 · main / #1458 merged후 · #1486 단독 / 본문 수치 보존
6 · 실제 문제 — weight에만 있던 82·15·3이 사라진다
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 → 매출 기여가 큼
전 · main / #1458 merged후 · #1486 단독 / 수치 손실
4 · 접두 제거 권장 — 값·0·단위·사용자 콜론을 보존한다
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%
2 · 현재 효과 없음 — “값:” 분기는 일반 fallback에서 실행되지 않았다
2 · 현재 효과 없음 — “값:” 분기는 일반 fallback에서 실행되지 않았다
유효 입력 1,405개 query 생성 · 현행 어휘 45종의 fallback 130개 · #1484 단독
두 검사 모두 변경된 출력은 0개다. 현재 value를 읽는 출발점에서 이를 읽지 않는 도착점으로 갈 때 P5가 먼저 적용되고, P3의 unread 목록에서 value·unit을 뺀다. #1484가 바꾸는 내부 분기만 보고 사용자 화면이 개선된다고 판단하면 안 된다. 머지 가치 판단 전에 실제 도달 경로를 추가로 제시하거나 방어적 정리임을 명시하는 편이 맞다.
값 자체·0·단위를 보존하는 방향은 타당하지만 이 조사로 화면 개선 효과를 확인한 것은 아니다. 평탄화에서 보이는 value:는 #1485, 측정값의 target: 등은 MOR-2769 범위다.
5 · 정책 먼저 — 숫자 이름을 일괄 제거하면 목표·범위를 구분할 수 없다
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 삭제 여부도 별도 결정
1·4 · 해석 주의 — 작성자와 출처의 역할은 값만으로 모호해질 수 있다
1·4 · 해석 주의 — 작성자와 출처의 역할은 값만으로 모호해질 수 있다
합성 QuoteTestimonial 입력 · author: 김민지, source: 2025 고객 조사 · 저장 자료에는 author/source/speaker/organization 사례가 없었음
이름·기관·출처를 서로 다른 전용 슬롯에 담는 경우에는 접두 제거가 읽기 좋다. 그러나 본문 한 칸으로 모으면 역할을 구분하던 정보가 표시에서 사라진다. 출처 표기가 중요한 자료에는 “작성자 김민지 · 출처 2025 고객 조사”처럼 의미를 살리는 규칙을 검토해야 한다. 이는 합성 사례에 대한 해석 위험이며, 저장 입력에서 발생한 결함 수로 세지 않았다.
전
author: 김민지
source: 2025 고객 조사
후
김민지
2025 고객 조사
6 · 구조상 경계 — 일반 글을 받을 곳이 강조 슬롯 하나뿐인 행
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건이었다. 합성 검사는 데이터셋·검색 게이트를 생략한다. 강조 슬롯을 비울지 실제 강조 본문을 받을지 정책·적재 분류를 확인할 근거로 남긴다. 현재 데이터에서 신호 필드가 별칭 호스트인 행은 없었다.
공급 전수: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행이다. 서로 다른 카테고리를 함께 가진 행은 카테고리별 합계에서 중복될 수 있다.
저장 입력 전수: 조회 기준 시각 이전 생성 기록 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다.
경계 실험: 모든 후보에 유닛·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종
같은 후보 전수 · 보완 전 head
33cfb07bf8 당시 출력 변화 0, #1487 결합에서도 공백 bullet 잔존. 후속 수정·회귀 검증을 추가했다. 이 전수 실험은 재실행하지 않았다.
#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가 서빙 중인 스냅샷 전체의 상태를 뜻하지 않는다. 기존 카드의 옛 2.6 수치는 당시 기록으로 유지했다.
고정 소스·재현 파일
기준 main 826cda2e31 (#1458 merged). 후속 head: #1487 bec77cb1bd · #1488 33cfb07bf8 · #1484 aa58b8a6d0 · #1485 2e75e0f91a · #1486 2f6f0a4950. 소스는 커밋별 별도 사본에서 빌드했다. 작업 중인 Rust 파일은 사용하지 않았다.
로컬 재현 묶음: ~/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가 없음을 확인했다.
반영 순서 제안
① #1488의 Rust 공백 방어 보완 완료; MOR-2770에서 규약·Eregion을 맞추고 #1487·1488 통합 확인 → ② #1485 접두 제거와 MOR-2777 줄 표기 결정 → ③ MOR-2770·2771에서 weight의 내용 보존·강조 슬롯 정책 결정 → ④ #1484 도달 경로와 MOR-2769 측정값 표기 확인 → ⑤ MOR-2776으로 TS 동기화·Rust 대조. 전수 조사 당시에는 분석만 갱신했다. 이후 #1488에 Rust 공백 방어를 추가했으며, Jira 상태·배포는 변경하지 않았다.
규칙 한눈에 보기 · 규약 대조
적용 판단은 위 2.6 전수 결과를 함께 본다. 아래 표는 정책과 현행 규약의 일치 여부다.
표의 변화는 각 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에 남겼다. 당시 대조는 분리 전 기록에서 확인할 수 있다.
규칙 카드의 기존 18개 사례 썸네일은 분리 전 통합판의 역사적 비교다. 전 = 당시 origin/main962dde1f5(1b만 cb3645e60), 후 = 별칭 리뷰 보강 전 4634def6e(18개 사례). 이후 통합 head ca5d4c555의 별칭 호스트 수정은 당시 회귀 테스트로 확인했다. 기존 18개 사례는 그대로 보존했다. 개별 PR의 새 렌더 5쌍은 2.6 전수 조사에서 별도 비교한다. 두 판의 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/.
