Kyeongmin/C.E.L_Slide_test2

Files

kyeongmin e7848b602d Add Phase Z runtime foundation

- add visual fit classifier, router, retry, and failure routing modules
- add composition planner and catalog-driven mapper
- add Phase Z pipeline orchestration and architecture docs

2026-05-04 08:21:28 +09:00

76 KiB

Raw Blame History

Phase Z Catalog / Runtime Design

본 문서는 Phase Z-1 사전 작업의 마지막 설계 산출물이며, Phase Z-2 본격 구현 (catalog / runtime / matching 통합) 의 입력 문서다.

⚠️ 본 문서는 1 차 — skeleton + 책임 영역 정의. 각 영역은 "무엇을 결정하는가 / 무엇을 결정하지 않는가" 까지만. 세부 설계는 단계적 추가. ⚠️ 본 문서 = 설계 책임 정리. 코드 / 파일 변경 / 기존 자산 삭제 X.

1. 문서 위치 / 목적

본 문서는 design_agent 의 Phase Z 흐름에서 catalog (frame ↔ Zone 매핑) + runtime (Jinja2 template + AI 경계) 의 책임 분리 를 정의한다.

위치 (Phase Z-1 사전 작업 산출물 흐름) :

FRAME-INTEGRATION-MAP.md — 32 frame Zone 적용 분류
PHASE-Z-FRAME-STYLE-INVENTORY.md — 32 frame + 18 token + 6 legacy
본 문서 — 위 두 인벤토리 + IMPROVEMENT-REDESIGN.md 5 단계 흐름 → catalog / runtime 책임 정리

→ Phase Z-2 본격 구현의 입력 문서. 본 문서는 코드 / 파일 변경을 지시하지 않음.

목적 :

frame inventory + style inventory 가 catalog 어디에서 책임지는지 정의
AI 가 건드리지 않는 영역 명시 (Phase R' 회귀 방지)
코드 구현 시 어떤 책임이 어디 살아야 하는지 사전 합의

2. 입력 문서

문서	본 설계가 받는 입력
`IMPROVEMENT-REDESIGN.md`	Phase Z 5 단계 흐름, 위계 + 용어, 절대 룰 (텍스트 무손실 / MDX 1 = 슬라이드 1 / 자유 디자인 금지 / 불일치 시 레이아웃 회귀)
`FRAME-INTEGRATION-MAP.md`	32 frame Zone 적용 분류 (`zone_direct` / `zone_adapt` / `zone_extract` / `reference_only`), 검토 상태, 분포
`PHASE-Z-FRAME-STYLE-INVENTORY.md`	Frame Inventory 32 행 (변환 14 + 미변환 18) + Token Inventory 18 행 (covered / gap_candidate / hierarchy_mapping_only / hold_recheck_after_conversion) + Legacy Reference 6 행

3. 핵심 원칙 (Phase Z 준수)

원칙	의미
final unit = Zone	슬라이드의 최종 조립 단위는 Zone. frame 은 절대 슬라이드에 직접 안 꽂힘
frame = reference / pattern / slot hint	frame 은 디자인 레퍼런스 / 구조 패턴 / 슬롯 힌트만. 원본 그대로 사용 X
AI = zone content only	AI 호출은 zone 안 콘텐츠 매핑 / 텍스트 다듬기 / 디자인 변형 단위로만
HTML / Jinja2 = code only	HTML 구조 / 레이아웃 / 프리셋 결정 / 새 frame 결정은 코드만 (AI 호출 X)
legacy blocks runtime reuse X	기존 `templates/blocks/structures/` 6 파일은 runtime 재사용 후보 X. 스타일 / 토큰 매핑 참고만

4. 책임 영역 (8 영역)

각 영역의 무엇을 결정하는가 / 무엇을 결정하지 않는가 만 본 1 차에서 정의. 세부 설계는 다음 차수.

4.1 Zone Catalog

결정함 :

frame ↔ Zone 매핑 룰 (어느 frame 이 어느 Zone 에 들어갈 수 있는가)
레이아웃 프리셋 (Type A / B / B' / B'') 별 Zone 구성
매칭 분기 (완벽 / 어정쩡 / 안 됨) 의 Zone 단위 의사결정
zone_application (zone_direct/adapt/extract/reference_only) 의 catalog 안 표현

결정 안 함 :

실제 frame 의 시각 스타일 (→ 4.2 Family CSS)
HTML 구조 (→ 4.3 Jinja2 Runtime Templates)
AI 호출 시점 / 입력 (→ 4.4 AI Boundary)

4.2 Family CSS

결정함 :

frame family 별 시각 / 스타일 규칙 정의
- 후보 family (Frame Inventory 의 Phase Z Target 컬럼 기반) : compare-paired.css / compare-table.css / pill-list.css / three-pillar.css / persona-cards.css / quadrant.css / split-panel.css / split-center.css 등
variant 분기 (예 : compare-paired.css 의 paired-rows vs vs-center-badge)
token (color / gradient) 사용 + 신규 token 후보 흡수 / 기각

결정 안 함 :

HTML 마크업 자체 (→ 4.3)
frame ↔ Zone 매핑 (→ 4.1)
텍스트 콘텐츠 (→ 4.4)

4.3 Jinja2 Runtime Templates

결정함 :

HTML 구조 (slide-base + body + zone slot + frame slot 의 마크업 골격)
슬롯 의미 매핑 (frame slot ↔ MDX 콘텐츠)
검증 (overflow / 시각 품질) hook 위치
본문 preview ↔ 팝업 원문 분리 위치 (텍스트 무손실 보존)

결정 안 함 :

시각 스타일 (→ 4.2)
frame 선택 (→ 4.1)
AI 호출 (→ 4.4)

4.4 AI Boundary

결정함 :

AI 호출 허용 범위 — zone 안 콘텐츠 매핑 / 텍스트 다듬기 / 슬롯 의미 미세 조정
AI 호출 금지 범위 — HTML 구조 / 레이아웃 / 프리셋 결정 / 새 frame 결정 (Phase R' 회귀 방지)
AI 입력 / 출력 형식 (zone 단위 컨텍스트만, 슬라이드 전체 X)

결정 안 함 :

AI 모델 / 프롬프트 자체 (구현 단계)
AI 호출 횟수 / 캐싱 (구현 단계)

4.5 Token Resolution

결정함 :

frame raw px (figma 1280 폭 기준) ↔ slide-body 스케일 (1200×590) 매핑 룰
hierarchy_mapping_only 행 (Token Inventory) 이 catalog 어디에서 적용되는가
신규 token (gap_candidate) 채택 / 기각 의사결정 위치
hold_recheck_after_conversion token 의 재검증 시점

결정 안 함 :

token 값 자체 (→ Style Inventory 영역)
token 파일 생성 / 변경 (구현 단계, 사용자 승인 후)

4.6 Asset Policy

결정함 :

자산 의존도 큰 frame (F01 9 자산 / F07 16 자산 / F14 사진 / F22 15 자산 등) 의 처리 정책
placeholder / 사용자 제공 / SVG 변환 / 이미지 유지 분기 룰
reference_only frame (F06) 의 자산 정책 (직접 적용 X)

결정 안 함 :

실제 자산 파일 / 경로 (구현 단계)
placeholder 의 시각 디자인 (구현 단계)

4.7 Variant Model

결정함 :

family 안 variant 의 표현 방식 후보 (CSS class modifier / data attribute / template parameter 등)
variant ↔ frame 매핑 룰 (compare-paired.css 의 paired-rows ↔ Frame 17 / vs-center-badge ↔ Frame 18 등)
variant 충돌 시 의사결정 (예 : 같은 zone 에 두 variant 가능 시)

결정 안 함 :

구체 CSS 구현 (→ 4.2)
variant 추가 / 폐기 (구현 단계)

4.8 Fallback Behavior

결정함 :

5 차 Fallback (코드 → AI 콘텐츠 조정 → 단일 프리셋 강제) 의 catalog 단위 책임
매칭 실패 시 zone 단위 동작
AI 콘텐츠 조정 (4 차) 의 입력 / 출력 경계 (frame / zone / container 유지, 콘텐츠만 조정)
레이아웃 회귀 (불일치 시 그릇 변경) 의 catalog 단위 트리거

결정 안 함 :

AI 호출 자체 (→ 4.4)
HTML 재구성 (→ 4.3)

5. 비범위

본 문서는 설계 책임 정의 만. 다음은 본 문서 비범위 :

❌ 코드 구현 (Phase Z-2 이후)
❌ 기존 templates/blocks/ 삭제 (사용자 승인 후 별도 단계)
❌ templates/styles/frame-patterns/ 신규 파일 생성 (사용자 승인 후)
❌ templates/styles/tokens/ 의 gap_candidate token 추가 (사용자 승인 후)
❌ legacy structures 6 파일 삭제 (사용자 승인 후)
❌ AI 모델 / 프롬프트 / 호출 횟수 결정
❌ Style Inventory 의 추가 항목 작성 (별도 작업)

6. 단계적 작성 계획

차수	작성 내용	상태
1 차	skeleton + 책임 영역 정의	✅
2 차	Zone Catalog 본격 — frame ↔ Zone 매핑 / 프리셋 / 매칭 분기 (본 문서 § 7)	✅
3 차	Family CSS 본격 — Area 후보 / variant 참조 / token 참조 / asset 표시 (본 문서 § 8)	✅
4 차	Jinja2 Runtime Templates 본격 — 입력 계약 / 조립 위계 / status 인터페이스 / AI 진입 (본 문서 § 9)	✅
5a 차	AI Boundary 본격 — 호출 단위 / 허용 입출력 / 금지 출력 (본 문서 § 10)	✅
5b 차	Token Resolution 본격 — 4 status 처리 룰 / scale 위계 매핑 / 보류 원칙 (본 문서 § 11)	✅
5c 차	Asset Policy 본격 — 의존도 / 자산 유형 / 5 상태 라벨 / asset_meta (본 문서 § 12)	✅
5d 차	Variant Model 본격 — 표현 방식 선택 / family 별 variant 관리 / 추가-분리-폐기 기준 (본 문서 § 13)	✅
5e 차	Fallback Behavior 본격 — status 진입 후 동작 / 5 차 Fallback / AI 경계 / 레이아웃 회귀 (본 문서 § 14)	✅
6 차	통합 검증 + Phase Z-2 구현 진입 결정 (본 문서 § 15)	✅ 검증 완료, 구현 착수 별도 승인

각 차수마다 user 검토 후 다음 진입. 6 차 완료 = 현재 위치 (1~5e 본격 설계 + 통합 검증 모두 완료). Phase Z-2 구현 착수는 별도 사용자 승인 후.

7. Zone Catalog — 2 차 본격 설계

⚠️ 본 섹션은 Zone Catalog 책임 영역만 다룬다. Family CSS / Jinja2 / Fallback 실제 동작 / AI 호출 등 다른 영역 침범 X. ⚠️ Frame Inventory / FRAME-INTEGRATION-MAP.md 의 표 / 통계는 다시 베끼지 않음 — 링크 참조 + catalog 안에서 어떻게 소비 되는지만.

7.1 Zone Catalog 의 역할

Zone Catalog 는 다음을 책임진다 :

레이아웃 프리셋 ↔ MDX 콘텐츠 결정 — Type A / B / B' / B'' 중 어느 프리셋이 본 MDX 에 적합한가
Zone 슬롯 ↔ frame 매핑 — 각 Zone 에 어느 frame 후보가 들어갈 수 있나
catalog status 라벨 부여 — zone_application × confidence 매트릭스 결과 (§ 7.4)

받는 입력 :

FRAME-INTEGRATION-MAP.md — 32 frame 의 zone_application 라벨
매칭 시스템 (V1~V4, tests/matching/) — frame ↔ MDX confidence 점수

출력 :

본 MDX 에 대한 Zone 별 catalog status 라벨
후속 영역 (Family CSS / Fallback / AI) 으로 전달되는 신호

→ Zone Catalog 는 라벨 부여까지만. 라벨 후 실제 적용은 Family CSS / Fallback Behavior / AI Boundary 영역.

7.2 레이아웃 프리셋 + Zone 타입

Phase Z 위계의 두 레벨을 분리해서 정의한다.

7.2-1 레이아웃 프리셋 후보

slide-body (≈ 1200×590) 를 어떻게 나누는가. 프리셋 4 종 (IMPROVEMENT-REDESIGN.md 참조) :

Preset	분배 형태	적합한 콘텐츠 신호
`Type A`	sidebar-right (`title / body / sidebar`)	reference 꼭지 1+
`Type B`	top + bottom (단일 강조 + 보조)	hero-detail 류
`Type B'`	two-column (좌·우 대등)	비교 류
`Type B''`	three-section (3 영역 분할)	3 카테고리 / 3 단계

→ catalog 가 결정 — MDX 콘텐츠 신호 ↔ 프리셋 선택. 결정 룰의 구체화는 추가 차수.

→ 결정 안 함 — 프리셋 안의 시각 디자인 (Family CSS), 프리셋 내부 HTML 구조 (Jinja2).

7.2-2 Zone 타입 후보

각 프리셋이 만들어낸 슬롯의 역할 후보. 슬롯 위치 ↔ 콘텐츠 role.

Zone slot 위치 (예)	받을 수 있는 콘텐츠 role 후보
`top`	summary / overview / key-insight / table-header
`bottom_l` / `bottom_r`	detail / compare-side / supporting
`sidebar`	reference / quote / supporting-list
`body` (single)	full-pattern / hero-detail / compare-rows

→ catalog 가 결정 — 어느 Zone 슬롯이 어느 콘텐츠 role 을 받을지.

→ 결정 안 함 — 슬롯 안 시각 디자인, 슬롯 안 frame 의 stylization.

7.3 frame zone_application 과 catalog 의 관계

FRAME-INTEGRATION-MAP.md 의 4 라벨 (zone_direct / zone_adapt / zone_extract / reference_only) 을 catalog 가 어떻게 소비 하는가 :

zone_application	catalog 의 소비 방식
`zone_direct`	frame 구조 그대로 zone 슬롯에 매핑. catalog 는 슬롯 사이즈만 통과
`zone_adapt`	frame 구조 동일, 사이즈 / 비율 재조정 hint 와 함께 후속 영역 (Family CSS) 에 전달
`zone_extract`	frame 의 일부 패턴만 (예 : 3-column 만 추출) hint 와 함께 후속 영역에 전달
`reference_only`	runtime 적용 X — `not_runtime_candidate` 라벨링. 디자인 톤 참고만

→ 4 라벨의 분류 자체 는 FRAME-INTEGRATION-MAP.md 가 결정. catalog 는 소비 방식 만 책임.

7.4 catalog status 라벨 — `zone_application × confidence` 매트릭스

본 catalog 의 핵심 출력. 두 축은 직교 :

zone_application = frame 자체의 Zone 적용 방식 (frame 의 고유 속성)
confidence = 특정 MDX 콘텐츠 ↔ frame 매칭 품질 (콘텐츠 ↔ frame 상호작용)

매트릭스 (4 × 3 = 12 셀, 6 라벨) :

	`high`	`medium`	`low`
`zone_direct`	`matched_zone`	`review_required`	`fallback_candidate`
`zone_adapt`	`adapt_matched_zone`	`review_required`	`fallback_candidate`
`zone_extract`	`extract_matched_zone`	`review_required`	`fallback_candidate`
`reference_only`	`not_runtime_candidate`	`not_runtime_candidate`	`not_runtime_candidate`

원칙 — medium confidence 는 자동 확정하지 않는다.

Zone 적용 방식이 zone_direct, zone_adapt, zone_extract 중 무엇이든, confidence 가 medium 이면 review_required 로 보낸다.

이유 : Phase Z 절대 룰 "불일치 시 레이아웃 회귀 — 콘텐츠 줄이지 않고 그릇 변경" 과 정합. 자동화가 과감해지는 것 방지.

각 라벨의 의미 :

라벨	의미
`matched_zone`	`zone_direct` × `high`. 즉시 적용 후보
`adapt_matched_zone`	`zone_adapt` × `high`. 사이즈 재조정 적용 후보
`extract_matched_zone`	`zone_extract` × `high`. 일부 패턴 추출 적용 후보
`review_required`	모든 `medium`. 사람 / 후속 단계 검토 필요
`fallback_candidate`	`zone_direct/adapt/extract` × `low`. fallback 진입
`not_runtime_candidate`	`reference_only` × any. 디자인 톤 참고만

fallback_candidate 는 fallback 동작을 실행한다는 뜻이 아니라, Fallback Behavior 설계로 넘길 후보 상태 를 의미한다.

→ catalog 는 라벨 부여까지만. 라벨 후의 실제 동작은 Fallback Behavior / AI Boundary / Family CSS 영역.

7.5 Zone Catalog 가 결정하지 않는 것

Skeleton § 4.1 의 "결정 안 함" 확장 + 본 2 차에서 추가 명확화 :

❌ frame 의 시각 / 스타일 (→ Family CSS, 미작성)
❌ HTML 구조 / 슬롯 마크업 (→ Jinja2 Runtime Templates, 미작성)
❌ AI 호출 시점 / 입력 형식 (→ AI Boundary, 미작성)
❌ fallback_candidate 진입 후 실제 동작 (→ Fallback Behavior, 미작성)
❌ review_required 진입 후 처리 흐름 (→ AI Boundary 또는 Fallback Behavior, 미작성)
❌ not_runtime_candidate frame 의 디자인 톤 적용 방식 (→ Asset Policy 또는 Style Inventory)
❌ variant 표현 방식 (→ Variant Model, 미작성)
❌ token 선택 / 적용 (→ Token Resolution, 미작성)
❌ confidence 임계값 자체 (예 : 몇 % 이상이 high 인가) — 매칭 시스템 (V1~V4) 의 책임. catalog 는 라벨화된 confidence 만 받음

7 차수 자체 점검 (작성 후)

✅ Zone Catalog 영역만 다룸 (Family CSS / Jinja2 / Fallback 실제 동작 / AI 호출 침범 X)
✅ Frame Inventory 32 행 표 redescription 0 — 링크 참조만
✅ FRAME-INTEGRATION-MAP.md 분포 통계 redescription 0
✅ 직교 축 (zone_application ⊥ confidence) 명시
✅ "medium 자동 확정 X" 원칙 prominent callout
✅ Skeleton § 4.1 의 "결정 안 함" 8 항목 § 7.5 에서 확장
✅ catalog 가 결정함 까지만, 결정 후 동작은 후속 영역 명시

8. Family CSS — 3 차 본격 설계

⚠️ 룰 1 — 본 섹션은 Family CSS 관점에서 variant / token / asset 을 어떻게 참조 하는지만 다룬다. Variant Model 자체, Token Resolution 자체, Asset Policy 자체는 후속 dedicated 영역 (§ 4.5 / 4.6 / 4.7) 에서 결정.

⚠️ 룰 2 — Family CSS 는 frame 별 CSS 가 아니라 family 단위 CSS 다. frame 차이는 variant / meta 로 표현한다.

8.1 Family CSS 의 역할

Family CSS 는 다음을 책임진다 :

family 단위 시각 / 스타일 규칙 정의 — 같은 family 안 frame 들의 공통 패턴
variant 슬롯 노출 — frame 차이를 family 안 variant 로 받아낼 수 있는 hook
token / asset 참조 인터페이스 — Token Inventory / Asset Policy 의 소비자

받는 입력 :

Frame Inventory 의 Phase Z Target 컬럼 (family 후보)
Token Inventory 의 4 status (covered / gap_candidate / hierarchy_mapping_only / hold)
Frame Inventory 의 Asset Notes (자산 의존도)
Zone Catalog (§ 7) 의 status 라벨 (matched_zone / adapt_matched_zone / extract_matched_zone — Family CSS 적용 후보 신호)

→ Family CSS 는 family 단위 패턴 정의까지만. variant 모델 자체 / token 채택 / asset 정책은 후속 영역.

8.2 Family CSS Area 후보 (11)

본 섹션의 centerpiece. Frame Inventory 의 Phase Z Target 컬럼을 family 단위로 수렴한 결과.

Family CSS Area 후보	흡수 frame	변형 축 (variant 후보)	asset 의존도	Notes
`compare-paired.css` (후보)	F17, F18	`paired-rows` (F17) / `vs-center-badge` (F18)	mid	F17 R16 두루마리 pill 이미지 의존. F18 의 center badge 컬럼이 variant 키
`compare-table.css` (후보)	F23, F24 (+ F30, F31 미변환 통합 후보)	`columns[N=2~4]` / `header_style` / `row_density`	low	line 은 CSS border 변환 가능. 30/31 변환 후 variant range 확정
`split-panel.css` (후보)	F21, F22	`right_items[N=3~8]` / `left_categories[N=2~5]` / `bracket_image` (optional)	high	14~15 자산 (배경 / 뱃지 / 화살표 / 행 바). Phase Z 재현 시 자산 풀 필수
`persona-cards.css` (후보)	F14	`actor_count[3]` / `actor_hue_palette` / `photo_required`	high	사진 ×3 필수 (placeholder / 사용자 자산), badge outer/inner ×6, 체크박스 ×20
`three-pillar.css` (후보)	F13	`pillars[3]` (현재 고정) / `column_hue_palette`	low	아이콘 PNG 1, 테두리 SVG 4 → CSS 변환 가능
`quadrant.css` (후보)	F16	`quadrants[4]` (고정) / `bar_style` / `center_quote` (optional)	mid	배경 텍스처 PNG ×4 동일, bar SVG → CSS gradient 변환 가능
`pill-list.css` (후보)	F09	`items[N=3~7]` / `stacking_pattern` / `arc_decoration` (optional)	low	아크 SVG / 화살표 SVG 만 이미지 유지. pill 본체 CSS
`cycle.css` (후보) + svg helpers (helper area 후보)	F12	`main_circles[3]` (현재 고정) / `accent_circles[6]`	mid	19 SVG (Ellipse) — 좌표 기반 SVG 재구성 가능. bg_texture PNG 1
`split-center.css` (후보)	F27	(sparse data — 추가 관찰 후 확정)	mid	flat.md sparse. variant range 후속 차수에서
`system-diagram.css` (후보)	F07	(sparse data — 추가 관찰 후 확정)	very high	16 자산. 자산 풀 필수
(asset-heavy / reference-like family 후보)	F01	(variant 미정 — pure CSS family 아님)	very high	9 자산 모두 이미지. CSS 패턴이라기보다 asset slot 컴포넌트. family 분류 자체 검토 후보

주의 :

Family CSS Area 후보 = 결정 X. 실제 파일 생성 / 이름은 사용자 승인 후.
11 개 → 최종 family 수는 더 줄 수 있음 (특히 sparse data F07 / F27 / F01 은 추가 검증 후 통합 / 분리 결정).
F01 은 pure CSS family 아님 — 별도 분류 필요할 수 있음 (asset-heavy / reference-like family).

→ FRAME-INTEGRATION-MAP.md 의 frame 별 분류는 redescribe 안 함. 본 표는 family 수렴 결과 만.

8.3 variant 참조 방식

Family CSS 는 frame 차이를 variant 로 받아낸다. variant 의 표현 방식 후보 :

후보 방식	예시	적합한 케이스
CSS class modifier	`.compare-paired.--vs-center-badge`	시각 / 구조가 크게 다른 variant (F17 vs F18 의 pill alternation vs center badge)
Data attribute	`[data-variant="paired-rows"]`	마크업은 같고 styling 만 분기
Template parameter	Jinja2 `{{ variant }}` 변수 + family CSS 의 조건부 selector	슬롯 수 / cardinality 차이 (예 : `columns[N=2~4]`)
Variant family 자체 분기	`compare-table--2col.css` / `compare-table--3col.css` (별도 entry)	columns 차이가 너무 클 때 (현재 시점에서는 over-split, 비추천)

Family CSS 가 결정함 : variant 별로 어느 표현 방식 을 채택하는가 (참조 인터페이스만)

Family CSS 가 결정하지 않음 : variant 자체의 분류 / 추가 / 폐기 (→ § 4.7 Variant Model, 5 차)

→ 본 차수에서는 표현 방식 후보 4 개 나열까지만. 어느 family 가 어느 방식을 쓸지의 결정은 5 차 Variant Model.

8.4 token 참조 방식

Family CSS 가 Token Inventory 의 4 status 를 어떻게 참조 하는가 :

Token Inventory status	Family CSS 의 참조 방식
`covered`	기존 token 그대로 `var(--color-block-title-from)` 등 사용. 신규 정의 X
`gap_candidate`	참조 placeholder 사용 — `var(--c-table-header-cyan)` (후보) 식으로 후보 이름 표기. 실제 token 추가 / 채택은 § 4.5 Token Resolution 의 결정
`hierarchy_mapping_only`	frame raw px (figma 1280 폭) 직접 사용 X. slide-body 위계 토큰 (`--font-zone-title` / `--font-sub-title` 등) 참조 + zoom / scale 메타는 § 4.5 의 결정
`hold_recheck_after_conversion`	Family CSS 에서 사용 X. 폐기 단정 X (32 frame 변환 후 재검증)

Family CSS 가 결정함 : 어느 token 을 어느 슬롯에 쓰는가 (참조 매핑)

Family CSS 가 결정하지 않음 : token 자체의 추가 / 변경 / 폐기 (→ § 4.5 Token Resolution, 5 차)

Token Inventory 의 4 status 표는 PHASE-Z-FRAME-STYLE-INVENTORY.md 참조. 본 섹션에서 redescribe X.

8.5 asset 의존 표시 방식

asset-heavy family 의 self-policy 표시. § 8.2 의 asset 의존도 컬럼이 이미 분류 (low / mid / high / very high). Family CSS 는 이 분류를 self-meta 로 표시.

의존도	Family CSS 의 표시 방식 (후보)
`low`	meta 표시 불필요
`mid`	family 헤더 주석에 `asset-dependency: mid` + 자산 항목 명시 (예 : SVG 아이콘 / 이미지 1~3 개)
`high`	family 헤더 주석에 `asset-dependency: high` + placeholder 정책 명시 (예 : "사진 ×3 — 사용자 제공 자산 필요")
`very high`	family 헤더 주석에 `asset-dependency: very high` + runtime 적용 시 자산 풀 / placeholder 필수 경고

특수 케이스 : F01 같은 asset-heavy / reference-like family 는 pure CSS family 가 아님 명시. family 분류 자체가 asset slot 컴포넌트 / reference 후보 임을 self-meta 로.

Family CSS 가 결정함 : 의존도 self-meta 표시 형식 (참조 인터페이스)

Family CSS 가 결정하지 않음 : asset placeholder 의 실제 디자인 / 자산 풀 / 사용자 제공 정책 (→ § 4.6 Asset Policy, 5 차)

8.6 Family CSS 가 결정하지 않는 것

Skeleton § 4.2 의 "결정 안 함" 확장 + 본 3 차에서 추가 명확화 :

❌ HTML 마크업 자체 (→ Jinja2 Runtime Templates, 미작성)
❌ frame ↔ Zone 매핑 (→ Zone Catalog, § 7 작성됨)
❌ 텍스트 콘텐츠 / AI 호출 (→ AI Boundary, 미작성)
❌ variant 모델 자체 (분류 / 추가 / 폐기) — 본 § 8.3 에서는 참조 표현 방식 후보만 (→ § 4.7 Variant Model, 5 차)
❌ token 자체 (값 / 추가 / 변경 / 폐기) — 본 § 8.4 에서는 참조 방식 만 (→ § 4.5 Token Resolution, 5 차)
❌ asset 정책 자체 (placeholder 디자인 / 자산 풀 / 사용자 제공 룰) — 본 § 8.5 에서는 self-meta 표시 만 (→ § 4.6 Asset Policy, 5 차)
❌ frame 별 CSS — Family CSS 는 family 단위 (룰 2 재확인)
❌ 실제 CSS 파일 생성 / 이름 확정 / 위치 — 사용자 승인 후 별도 단계
❌ legacy templates/blocks/structures/ 6 파일 삭제 — 사용자 승인 후

8 차수 자체 점검 (작성 후)

✅ Family CSS 영역만 다룸 (Variant Model 자체 / Token Resolution 자체 / Asset Policy 자체 / Jinja2 / AI 침범 X)
✅ Frame Inventory Phase Z Target 컬럼 redescription 0 — family 수렴 결과만
✅ Token Inventory 4 status 표 redescription 0 — 링크 참조만
✅ FRAME-INTEGRATION-MAP.md 분류 redescription 0
✅ 룰 1 (참조하는지만 다룸) + 룰 2 (frame 별 X / family 단위) 섹션 머리에 명시
✅ family 후보 11 개 centerpiece (자산 의존도 분류 포함)
✅ F01 asset-heavy / reference-like family 별도 분류 명시
✅ Skeleton § 4.2 의 "결정 안 함" 8.6 에서 확장 + 5 차 dedicated 영역 cross-reference

9. Jinja2 Runtime Templates — 4 차 본격 설계

⚠️ 룰 1 — Jinja2 는 HTML 구조를 조립한다. AI 는 Jinja2 구조를 만들지 않는다. AI 출력은 이미 정해진 zone slot 안의 콘텐츠 값으로만 들어온다.

⚠️ 룰 2 — Jinja2 는 조립 실행자 다. status label 결정 / variant 채택 결정 / fallback 정책은 다른 영역에서 받은 결정. Jinja2 는 그 결정을 받아 조립 만 한다.

9.1 Jinja2 Runtime Templates 의 역할

Jinja2 는 다음을 책임진다 :

HTML 구조 조립 — slide-base → slide-body → layout preset → zone → family partial 의 마크업 조합
슬롯 배치 — zone slot 위치에 family partial / 콘텐츠 삽입
검증 hook 위치 — overflow 측정 / 시각 품질 평가 fixture 위치
본문 preview ↔ 팝업 원문 분리 — 텍스트 무손실 보존 (Phase Z 절대 룰)

받는 입력 :

Zone Catalog (§ 7) : layout_preset, zone status label
Family CSS (§ 8) : family partial 식별자, variant
AI 출력 : zone 단위 콘텐츠
MDX 원문 : preview / popup 분리용

→ Jinja2 = 조립 실행자. 받은 결정을 마크업으로 직조하기만.

9.2 입력 데이터 계약

Jinja2 가 받는 입력의 필드 shape :

필드	출처	shape / 예시
`slide_meta`	MDX 분석 (Stage 1)	`{ chapter_title, conclusion, footer_text }`
`layout_preset`	Zone Catalog (§ 7.2-1)	`Type A` / `Type B` / `Type B'` / `Type B''`
`zones[]`	Zone Catalog (§ 7)	`[{ zone_id, slot_position, status_label, frame_id, content }, ...]`
`zone.content`	AI 출력 (zone 단위) + MDX 원문	`{ preview_text, popup_full, slot_payload }`
`family_meta`	Family CSS (§ 8)	`{ family_id, variant, asset_dependency }`

Jinja2 가 결정함 : 위 입력 shape 를 수신 하고 마크업 으로 변환.

Jinja2 가 결정하지 않음 : 필드 값 자체 (각 출처 영역의 결정), 새 필드 추가 / 변경.

9.3 조립 위계

Phase Z 위계가 Jinja2 안에서 어떻게 표현되는가 :

slide-base (existing template)
  ├─ slide-title          ← MDX 대목차 자동 매핑
  ├─ slide-divider        (고정)
  ├─ slide-body (≈ 1200×590)
  │    └─ layout preset (Type A / B / B' / B'')
  │         └─ zones[]   (preset 별 slot 정의)
  │              └─ family partial (family CSS 영역)
  │                   └─ slot content (AI 출력 + MDX 원문)
  └─ slide-footer         ← MDX 대목차 결론 자동 매핑

Jinja2 가 결정함 :

위계 각 단계의 wrapper / container 마크업
preset → zones 분배 메커니즘 (preset-specific Jinja2 partial)
zone → family partial 임베딩 위치
preview ↔ popup 분리 마크업 위치

Jinja2 가 결정하지 않음 :

preset 선택 (→ Zone Catalog § 7.2-1)
zone slot 의 콘텐츠 role 매핑 (→ Zone Catalog § 7.2-2)
family partial 의 시각 / 스타일 (→ Family CSS § 8)
frame 별 차이 (→ family variant, § 8.3)

9.4 Zone Catalog status label → 조립 인터페이스

§ 7.4 의 6 status label 을 Jinja2 가 어떻게 받아 조립하는가. 정책 결정 X, 조립 인터페이스만.

Status label	Jinja2 의 조립 인터페이스
`matched_zone`	family partial 렌더 대상. 입력 shape 그대로 마크업 조립
`adapt_matched_zone`	family partial 렌더 대상 (adapt hint 를 `family_meta` 로 전달, 실제 스타일 처리는 Family CSS)
`extract_matched_zone`	family partial 렌더 대상 (extract hint 를 `family_meta` 로 전달)
`review_required`	preview / review payload 로 분리 마크업, 검토 marker 부착
`fallback_candidate`	Jinja2 직접 렌더 대상 아님 — Fallback Behavior 로 위임
`not_runtime_candidate`	런타임 family partial 렌더 대상 아님 — 디자인 톤 참고만 (Asset Policy / Style Inventory)

본 표는 Jinja2 의 조립 인터페이스 만 정의한다. 실제 fallback 동작 / review 처리 흐름 / not_runtime 의 디자인 톤 적용은 § 4.6 / § 4.8 의 영역.

9.5 AI 출력의 Jinja2 진입 위치

AI 출력은 zone.content 의 sub-필드 (§ 9.2) 로만 들어온다.

진입 허용 필드	의미
`zone.content.preview_text`	zone slot 본문 preview (AI 가 다듬은 짧은 표시 텍스트)
`zone.content.popup_full`	팝업 / `<details>` / 별도 레이어 원문 (MDX 무손실)
`zone.content.slot_payload`	family partial 의 슬롯별 콘텐츠 (예 : `{ title, body, items[] }`)

진입 금지 영역 (Phase R' 회귀 방지) :

❌ HTML 구조 자체 (slide-base / slide-body / preset / zone / family partial 의 wrapper)
❌ class 명 / data attribute / id
❌ Jinja2 template ({% %} / {{ }} 매크로)
❌ family 선택 / variant 선택 / preset 선택
❌ 새 frame 결정 / catalog status label 결정

AI 가 출력할 수 있는 것은 콘텐츠 값 만. 구조 / 스타일 / 매핑은 모두 코드의 영역.

이 경계가 무너지면 Phase R' 의 "AI 가 HTML 구조 직접 생성" 회귀로 빠진다. Jinja2 의 입력 계약 (§ 9.2) 이 이 경계의 강제 메커니즘.

9.6 Jinja2 가 결정하지 않는 것

Skeleton § 4.3 의 "결정 안 함" 확장 + 본 4 차 추가 :

❌ frame 시각 / 스타일 (→ Family CSS § 8)
❌ frame ↔ Zone 매핑 / preset 선택 / status label 부여 (→ Zone Catalog § 7)
❌ AI 모델 / 프롬프트 / 호출 횟수 (→ AI Boundary § 4.4, 5 차)
❌ token 자체 (→ Token Resolution § 4.5, 5 차)
❌ asset 정책 자체 (→ Asset Policy § 4.6, 5 차)
❌ variant 모델 자체 (→ Variant Model § 4.7, 5 차)
❌ fallback 실제 동작 (→ Fallback Behavior § 4.8, 5 차)
❌ review_required 진입 후 검토 흐름 (→ AI Boundary 또는 Fallback Behavior, 5 차)
❌ 실제 Jinja2 파일 생성 / 마크업 코드 작성 — 사용자 승인 후 별도 단계
❌ CSS class / id naming 확정 — 구현 단계

9 차수 자체 점검 (작성 후)

✅ Jinja2 영역만 다룸 (정책 결정 / Family CSS / AI 영역 / Fallback 동작 침범 X)
✅ Frame Inventory / Token Inventory / Section 7~8 표 redescription 0
✅ 룰 1 (HTML 조립 / AI 는 zone slot 콘텐츠만) + 룰 2 (조립 실행자 / 정책 결정자 X) 섹션 머리 명시
✅ § 9.2 입력 데이터 계약 필드 shape 5 개 명시
✅ § 9.4 status label 조립 인터페이스 까지만, 정책 결정 X (fallback 동작 / review 흐름은 후속 영역)
✅ § 9.5 AI 진입 허용 / 금지 명시 — Phase R' 회귀 방지 메커니즘
✅ § 9.6 boundary 10 항목 + 5 차 dedicated 영역 cross-reference

10. AI Boundary — 5a 본격 설계

⚠️ 룰 1 — AI 호출 단위는 zone 안 콘텐츠다.

슬라이드 전체 / 레이아웃 / 프리셋 / family 선택 / 새 frame 결정 / status label 결정은 AI 의 영역이 아니다.

⚠️ 룰 2 — AI 출력은 zone.content.* 의 콘텐츠 값만이다.

HTML / CSS / class / Jinja2 / 구조 결정은 AI 출력에 포함하지 않는다.

10.1 AI Boundary 의 역할

AI Boundary 는 다음을 책임진다 :

AI 호출 단위 정의 — 한 호출 = 하나의 zone 안 콘텐츠 scope
허용 입력 / 출력 형식 정의 — AI 가 받는 것 / 만드는 것의 contract
금지 영역 정의 — AI 가 만들지 말아야 할 것 (Phase R' 회귀 방지)
Jinja2 입력 계약 (§ 9.2) 과의 정합 — zone.content.* 필드와 cross-reference

받는 입력 :

Zone Catalog (§ 7) : zone 정보 (zone_id, slot_position, frame_id, status_label)
Family CSS (§ 8) : family meta (family_id, variant, asset_dependency)
MDX 원문 : 해당 zone 에 속하는 부분

→ AI Boundary = AI 의 활동 반경 정의. 모델 / 프롬프트 / 호출 빈도는 본 차수 X.

10.2 AI 호출 단위 — zone content only (scope)

한 AI 호출 = 하나의 zone 안 콘텐츠 단위.

scope 단위	허용 / 금지
한 zone 안 콘텐츠	✅ AI 호출 단위
슬라이드 전체	❌
레이아웃 / 프리셋 결정	❌
family / variant 선택	❌
새 frame 발굴 / 결정	❌
status label 부여	❌

→ 한 슬라이드 = N 개 zone = 최대 N 회 AI 호출 (zone 별 1 회 단위). 호출 횟수 / 빈도 / 시점은 본 차수 X (파이프라인 / Fallback 영역).

10.3 허용 입력 / 허용 출력

허용 입력 (AI 가 받는 것)

필드	의미
`zone_meta`	`{ zone_id, slot_position, status_label, frame_id }`
`family_meta`	`{ family_id, variant, asset_dependency }`
`mdx_excerpt`	해당 zone 에 속하는 MDX 원문
`style_hint`	family 의 스타일 힌트 (예 : "title 위계", "body 위계") — Family CSS 영역에서 전달
`layout_meta`	`{ preset_id, neighbor_zones }` — 이웃 zone 컨텍스트 (선택)

허용 출력 (AI 가 만드는 것 — `zone.content.*`)

필드	의미
`zone.content.preview_text`	zone slot 본문 preview (짧은 표시 텍스트)
`zone.content.popup_full`	팝업 / `<details>` 원문 (MDX 무손실 또는 AI 가 재구성한 무손실 버전)
`zone.content.slot_payload`	family partial 슬롯별 콘텐츠 (예 : `{ title, body, items[] }`)

→ 출력 3 필드 모두 § 9.2 의 zone.content.* 안에 들어간다.

10.4 금지 출력

AI 가 출력에 포함하면 안 되는 것 :

❌ HTML 구조 (<div>, <section>, <table> 등 wrapper / container 마크업)
❌ CSS class 명 / id / data attribute
❌ Jinja2 template 매크로 ({% %} / {{ }})
❌ family 선택 / variant 선택 / preset 선택
❌ 새 frame 결정 / catalog status label 결정
❌ token 추가 / 변경 / 폐기 결정
❌ asset placeholder 디자인
❌ fallback 정책 / review 정책

이 금지 출력 영역이 무너지면 Phase R' 회귀 (AI 가 HTML 구조 직접 생성) 로 빠진다. § 9.5 의 진입 위치 차단 + § 10.4 의 금지 출력 명시 가 두 면 차단 메커니즘.

10.5 Jinja2 입력 계약 (§ 9.2) 과의 연결

AI 출력은 Jinja2 입력 계약의 zone.content 필드 로 들어간다. 입력 계약 안에서 AI 영역 ↔ 다른 영역 이 완전 분리됨 :

Jinja2 입력 계약 필드 (§ 9.2)	출처 영역	AI 가 만드는가
`zone.content.preview_text`	AI Boundary	✅
`zone.content.popup_full`	AI Boundary	✅
`zone.content.slot_payload`	AI Boundary	✅
`slide_meta`	MDX 분석 (Stage 1)	❌
`layout_preset`	Zone Catalog (§ 7)	❌
`zones[]` 자체 / `zone_id` / `status_label`	Zone Catalog (§ 7)	❌
`family_meta`	Family CSS (§ 8)	❌

→ Jinja2 입력 계약 자체가 boundary 강제 메커니즘. AI 가 잘못된 영역에 출력해도 입력 계약 단계에서 reject 가능 (구현 단계 결정).

10.6 AI Boundary 가 결정하지 않는 것

Skeleton § 4.4 의 "결정 안 함" 확장 + 본 5a 추가 :

❌ 구체 프롬프트 / 모델 (구현 영역)
❌ 호출 비용 / 토큰 사용량 / 응답 시간 (구현 영역)
❌ AI 호출 시점 / 빈도 — AI Boundary 는 호출 시 무엇을 받고 무엇을 만드는가 까지만, 언제 부르는가 는 파이프라인 / Fallback Behavior 영역
❌ fallback 실제 실행 절차 (→ Fallback Behavior § 4.8, 5e)
❌ review_required 의 검토 흐름 (→ Fallback Behavior 또는 파이프라인)
❌ token 자체 (값 / 추가 / 변경 / 폐기) (→ Token Resolution § 4.5, 5b)
❌ asset 정책 자체 (→ Asset Policy § 4.6, 5c)
❌ variant 모델 자체 (→ Variant Model § 4.7, 5d)
❌ HTML 구조 / Jinja2 마크업 (→ Jinja2 § 9, Phase R' 회귀 방지)
❌ AI 응답 검증 / 재호출 정책 (구현 영역)

5a 차수 자체 점검 (작성 후)

✅ AI Boundary 영역만 다룸 (Token / Asset / Variant / Fallback / Jinja2 / Zone Catalog 침범 X)
✅ Frame Inventory / Token Inventory / Section 7~9 표 redescription 0
✅ 룰 1 (호출 단위 = zone) + 룰 2 (출력 = zone.content.* 콘텐츠 값만) 섹션 머리 명시
✅ § 10.4 금지 출력 + § 9.5 금지 진입 = 두 면 Phase R' 회귀 차단
✅ § 10.5 가 § 9.2 입력 계약과의 cross-reference 명시 (AI ↔ 다른 영역 분리)
✅ § 10.6 에 "AI 호출 시점 / 빈도" 비범위 명시 (Fallback / 파이프라인 정책 침범 차단)
✅ Skeleton § 4.4 의 "결정 안 함" 10 항목으로 확장

11. Token Resolution — 5b 본격 설계

⚠️ 룰 1 — Token Resolution 은 token 적용 판단을 정의하지만 token 파일을 수정하지 않는다.

covered, gap_candidate, hierarchy_mapping_only, hold_recheck_after_conversion 은 모두 설계 상태 이며 구현 결정 이 아니다.

⚠️ 룰 2 — frame raw px 는 slide-body token 값과 직접 매칭하지 않는다.

typography / spacing / radius 는 위계 매핑 만 수행하고, 실제 값은 slide-body scale 에서 재산정한다.

11.1 Token Resolution 의 역할

Token Resolution 은 다음을 책임진다 :

4 status 적용 판단 룰 — Token Inventory 의 4 status (covered / gap_candidate / hierarchy_mapping_only / hold_recheck_after_conversion) 별 적용 가능성 판단
frame raw px ↔ slide-body scale 위계 매핑 룰 — figma 1280 폭 기준 raw px 와 slide-body 1200×590 토큰 스케일 사이의 매핑 원칙
추가 / 변경 / 폐기 보류 원칙 — token 파일 수정은 본 차수 X
family CSS 와의 참조 인터페이스 (§ 8.4 cross-reference)

받는 입력 :

Token Inventory 18 행 (PHASE-Z-FRAME-STYLE-INVENTORY.md)
Frame Inventory 의 Style Elements 관찰값
기존 templates/styles/tokens/ 3 파일 (colors / spacing / typography)

→ Token Resolution = token 적용 판단 정의. 실제 token 파일 수정 / 신규 추가 / 폐기는 본 차수 X.

11.2 Token Inventory 4 status 처리 룰

Status	Token Resolution 판단 룰
`covered`	기존 token 정확 hex 일치 검증된 상태. family CSS / runtime 에서 as-is 참조. 변경 / 추가 결정 X
`gap_candidate`	working name 후보 로만 유지. 이름 자체 (`--c-table-header-cyan` 등) 도 아직 확정 X. 실제 token 추가 / 채택 / 명명은 Phase Z-2 구현 단계 사용자 승인 후
`hierarchy_mapping_only`	typography / spacing / radius 는 raw px 직접 매칭 X. 위계만 보고 slide-body scale 에서 재산정 (§ 11.3)
`hold_recheck_after_conversion`	미사용 / 폐기 단정 X. 18 미변환 frame 변환 후 재검증

→ 본 표는 4 status 의 적용 판단 까지만. token 자체의 값 / 이름 / 추가 / 변경 / 폐기는 본 차수 X.

11.3 frame raw px ↔ slide-body scale 위계 매핑

scale 차이 :

출처	scale	예시 값
frame raw px	figma 1280 폭 기준 (zoom 0.49 ~ 1.11 다양)	title 70px / body 35~~42px / radius 5~~50px
slide-body 토큰	slide-body 1200×590 스케일	`--font-zone-title` 13px / `--font-body` 11px / `--card-radius` 6px

위계 매핑 룰 (typography 예시) :

frame raw 위계	slide-body 위계 매핑 (후보)
frame title (raw 70px Bold + gradient)	`--font-zone-title` (13px) 또는 `--font-sub-title` (12px) — 위계 매칭
frame heading (raw 45~55px Bold)	`--font-sub-title` 위계
frame body (raw 35~42px Medium)	`--font-body` (11px) 위계
frame caption (raw 30px)	`--font-caption` (10px) 위계

→ 위계 매핑 룰만 본 차수에서 결정. 실제 px 값 매핑 은 slide-body scale 재산정 영역 (구현 단계).

같은 룰이 spacing / radius 에도 적용 :

frame raw radius 5 / 30 / 50px ↔ slide-body --card-radius 위계
frame raw gap 8 / 12 / 25px ↔ slide-body --space-* 위계

11.4 family CSS 와의 참조 인터페이스 (§ 8.4 cross-reference)

§ 8.4 가 결정함 : family CSS 의 token 참조 syntax (var(--color-block-title-from) 형태) § 11.4 가 결정함 : family CSS 가 어느 token 을 어떤 조건으로 참조 가능한가의 판단

Status	family CSS 참조 가능성
`covered`	✅ 즉시 참조 가능
`gap_candidate`	△ working name 후보로 참조 (token 자체 미정 — 구현 단계 reject 가능)
`hierarchy_mapping_only`	✅ 위계 매칭으로 참조 (raw px 직접 사용 X)
`hold_recheck_after_conversion`	❌ 참조 X

→ 참조 syntax 는 § 8.4. 본 표는 Token Resolution 의 판단 perspective 만.

11.5 추가 / 변경 / 폐기 보류 원칙

행위	본 차수 결정	위임
신규 token 추가	❌ X	Phase Z-2 구현 진입 시 사용자 승인
working name 확정 (`--c-*` 등)	❌ X	사용자 승인 영역
기존 token 값 변경	❌ X (covered 는 frame 정확 일치, 변경 사유 없음)	—
hold token 폐기	❌ X	32 frame 전체 변환 후 재검증
명명 컨벤션 (`--c-` / `--g-` / `--fs-` 등) 확정	❌ X	working 단계, 사용자 승인 후 최종

→ Phase Z 절대 룰 "기존 templates 삭제 / 교체 실행 X" + "새 token / css 파일 생성 X" 와 정합.

11.6 Token Resolution 이 결정하지 않는 것

Skeleton § 4.5 의 "결정 안 함" 확장 + 본 5b 추가 :

❌ token 값 자체 (→ Style Inventory / Frame 관찰값)
❌ token 파일 생성 / 수정 / 삭제 (구현 영역)
❌ 신규 token 이름 최종 확정 (사용자 승인 영역)
❌ slide-body scale 재산정의 구체 px 값 (구현 영역)
❌ confidence 임계값 (→ 매칭 시스템 V1~V4)
❌ family CSS 의 token 참조 syntax (→ § 8.4)
❌ asset 정책 자체 (→ Asset Policy § 4.6, 5c)
❌ variant 모델 자체 (→ Variant Model § 4.7, 5d)
❌ AI 호출 자체 (→ AI Boundary § 4.4 / § 10)
❌ HTML / CSS / Jinja2 마크업 (→ § 8 / § 9)

5b 차수 자체 점검 (작성 후)

✅ Token Resolution 영역만 다룸 (Style Inventory / 구현 / family CSS syntax / Asset / Variant / AI 침범 X)
✅ Token Inventory 18 행 redescription 0 — 4 status 처리 룰 만
✅ § 8.4 의 표 redescription 0 — 참조 가능성 판단 perspective 만
✅ 룰 1 (token 파일 수정 X / 4 status = 설계 상태) + 룰 2 (raw px ≠ slide-body, 위계 매핑만) 섹션 머리 명시
✅ § 11.2 에 working name 후보 표현 (gap_candidate 이름 미확정)
✅ § 11.3 에 위계 매핑 룰만, 실제 값은 구현 영역
✅ § 11.5 추가 / 변경 / 폐기 / 명명 / 컨벤션 5 행위 모두 보류 원칙
✅ § 11.6 boundary 10 항목 + 5c~5e dedicated 영역 cross-reference

12. Asset Policy — 5c 본격 설계

⚠️ 룰 1 — Asset Policy 는 자산 처리 기준을 정의하지만 자산을 생성하지 않는다.

이미지 / SVG / texture / icon / placeholder 는 모두 설계 상태 이며, 실제 파일 생성은 구현 단계.

⚠️ 룰 2 — 자산 의존 family 는 metadata 로 표시하고, Jinja2 / Family CSS 는 그 metadata 를 참조한다.

Asset Policy 는 자산 필요 여부와 처리 분기를 정의한다. 렌더 구조나 CSS 구현은 다른 영역의 책임.

⚠️ 룰 3 — Asset Policy 는 생성 도구를 결정하지 않는다.

Gemini / imagegen / Figma export / 사용자 제공 중 무엇을 쓸지는 구현 단계 결정.

12.1 Asset Policy 의 역할

Asset Policy 는 다음을 책임진다 :

자산 의존도 등급 처리 룰 — low / mid / high / very high 정책 해석
자산 유형 분기 — 사진 / texture / icon / 다이어그램 SVG / 장식 5 분류
자산 상태 라벨 — placeholder_allowed / user_asset_required / asset_optional / convertible_to_css_or_svg / reference_only
asset_meta 정의 — Jinja2 / Family CSS 가 받을 metadata 형식
추가 / 변경 / 폐기 / 도구 보류 원칙 — 자산 파일 생성 / 도구 선택은 본 차수 X

받는 입력 :

Frame Inventory Asset Notes 컬럼 (자산 항목 / 의존도 관찰값)
Family CSS § 8.5 의 의존도 self-meta 표시 (low / mid / high / very high)

→ Asset Policy = 자산 처리 기준 정의. 자산 생성 / 도구 / placeholder 디자인은 본 차수 X.

12.2 자산 의존도 등급 처리 룰

§ 8.5 와의 perspective 분리 :

§ 8.5 = Family CSS 가 어떻게 self-meta 를 표시 하는가 (형식)
§ 12.2 = 각 등급이 정책적으로 어떻게 해석 되는가 (의미)

등급	정책 해석	처리 룰
`low`	자산 거의 X. CSS 변환으로 충분	별도 정책 불필요. `asset_meta` 불필요
`mid`	일부 자산 (1~3 개) 이미지 유지 가능	`asset_meta` 에 자산 항목 + 상태 라벨 표시
`high`	다수 자산 (10+ 또는 사진). 정책 분기 필수	`asset_meta` 에 상태 라벨 + 자산 별 처리 분기. `user_asset_required` 가능성 큼
`very high`	자산이 family 의 핵심	`asset_meta` 에 상태 라벨 + family 자체의 `reference_only` / asset-heavy 표시 검토

Frame Inventory 에서 high / very high family : split-panel (F21/F22) / persona-cards (F14) / system-diagram (F07) / F01 (reference-like) — 자세한 자산 목록은 PHASE-Z-FRAME-STYLE-INVENTORY.md 의 Asset Notes 참조 (redescription X).

12.3 자산 유형 분기

각 family 의 자산을 5 유형으로 분류 :

자산 유형	특징	처리 후보
사진 (사람 / 시공 / 풍경)	시각 의미 핵심, 재현 / 대체 곤란	`user_asset_required` 우선
texture (배경)	분위기 / 톤 표현	`placeholder_allowed` / `convertible_to_css_or_svg` / 생성 가능성 (도구 미정)
icon (단순 그래픽)	단순 형태, 의미 핵심	`convertible_to_css_or_svg` (SVG 인라인 가능성)
다이어그램 SVG (좌표 기반)	수학 재구성 가능	`convertible_to_css_or_svg` (코드 재구성 가능성)
장식 (아크 / 화살표 / 구분선)	단순 형태, 옵셔널	`asset_optional` / `convertible_to_css_or_svg`

→ "생성 가능성" 표현 까지만. 실제 도구 선택 (Gemini / imagegen / Figma export / 사용자 제공) 은 룰 3 에 따라 본 차수 X.

12.4 자산 상태 라벨 (5 후보) — centerpiece

본 섹션의 핵심. 각 자산 슬롯이 어떤 처리 정책을 갖는지 라벨링.

라벨	의미	적용 케이스 후보
`placeholder_allowed`	placeholder 로 대체 가능 (의미 보존 영향 적음)	texture / 일부 장식
`user_asset_required`	사용자 제공 필수 (placeholder 불가)	사진 (시공 / 인물) — 의미 보존 핵심. 5 라벨 중 유일한 의무
`asset_optional`	자산 없이 렌더 가능	장식 (아크 / 화살표)
`convertible_to_css_or_svg`	코드 변환 가능 (자산 불필요)	icon / 다이어그램 SVG / 단순 장식
`reference_only`	runtime 적용 X. 디자인 톤 참고만	F06 (지도) / F01 (image-heavy reference) family

자산 유형 × 상태 라벨 직교 매트릭스 (가능성 표) :

자산 유형 \ 상태	`placeholder_allowed`	`user_asset_required`	`asset_optional`	`convertible_to_css_or_svg`	`reference_only`
사진	❌	✅	❌	❌	△ (reference-like family 만)
texture	✅	△	△	✅	❌
icon	△	❌	△	✅	❌
다이어그램 SVG	❌	❌	❌	✅	△
장식	✅	❌	✅	✅	❌

→ 같은 유형이라도 family / 의도에 따라 라벨이 다를 수 있음. 라벨 부여 자체는 family 별로 결정 (Phase Z-2 구현 진입 시 사용자 승인).

12.5 `asset_meta` 정의 + Jinja2 / Family CSS 참조 인터페이스

Asset Policy 가 정의하는 metadata 형식 :

필드	shape	의미
`family_id`	string	어느 family 의 자산인가
`dependency_level`	`low` / `mid` / `high` / `very_high`	의존도 등급
`assets[]`	`[{ slot_id, asset_type, status_label, hint }, ...]`	family 안 자산 슬롯 목록
`assets[].asset_type`	`photo` / `texture` / `icon` / `diagram_svg` / `decoration`	자산 유형 (5 분류)
`assets[].status_label`	5 상태 라벨 중 하나	처리 정책
`assets[].hint`	string (optional)	자산 의미 / 위치 hint (placeholder 디자인 시 참고)

Jinja2 / Family CSS 가 받는 방식 :

Jinja2 (§ 9.2 입력 계약) 의 family_meta.asset_dependency 가 본 asset_meta.dependency_level 로 채워짐
Family CSS (§ 8.5 self-meta) 가 asset_meta 의 dependency_level + assets[].status_label 참조

→ asset_meta 정의 는 본 § 12.5. 실제 참조 syntax 는 § 8.5 / § 9.2 (perspective 분리).

12.6 Asset Policy 가 결정하지 않는 것

Skeleton § 4.6 의 "결정 안 함" 확장 + 본 5c 추가 :

❌ 실제 자산 파일 생성 / 다운로드 / 변환 (구현 영역)
❌ 생성 도구 선택 (Gemini / imagegen / Figma export / 사용자 제공) — 룰 3
❌ placeholder 의 시각 디자인 자체 (구현 영역)
❌ SVG 코드 작성 (구현 영역)
❌ 사용자 자산 수집 UX / workflow (구현 영역)
❌ asset_meta 의 어느 family 의 어느 슬롯이 어느 라벨인지 최종 부여 (사용자 승인 영역)
❌ token 자체 (→ Token Resolution § 4.5 / § 11)
❌ variant 모델 자체 (→ Variant Model § 4.7, 5d)
❌ HTML / CSS / Jinja2 syntax (→ § 8 / § 9)
❌ AI 호출 (→ AI Boundary § 4.4 / § 10)

5c 차수 자체 점검 (작성 후)

✅ Asset Policy 영역만 다룸 (Token / Variant / Fallback / Jinja2 / Family CSS syntax / AI 침범 X)
✅ Frame Inventory Asset Notes redescription 0 — 자세한 자산 목록 링크 참조
✅ § 8.5 의 self-meta 표시 redescription 0 — 정책 해석 perspective 만
✅ § 9.2 의 family_meta redescription 0 — asset_meta 정의 + cross-reference
✅ 룰 1 + 룰 2 + 룰 3 (생성 도구 결정 X) 섹션 머리 명시
✅ § 12.4 5 상태 라벨 centerpiece (placeholder_allowed / user_asset_required / asset_optional / convertible_to_css_or_svg / reference_only)
✅ _required 는 user_asset_required 만 (의무 / 정책 상태 분리)
✅ § 12.3 자산 유형 5 분류 + § 12.4 직교 매트릭스
✅ "생성 가능성" 표현 까지만 (도구 결정 X)
✅ § 12.6 boundary 10 항목 + 5d~5e dedicated 영역 cross-reference

13. Variant Model — 5d 본격 설계

⚠️ 룰 1 — Variant Model 은 frame 차이를 family 안에서 표현하는 기준을 정의한다.

frame 별 CSS 를 만들기 위한 장치가 아니라, family 단위 수렴을 유지 하기 위한 장치다.

⚠️ 룰 2 — variant 선택은 코드 / catalog 의 결정이다.

AI 는 variant 를 선택하거나 새 variant 를 만들지 않는다.

13.1 Variant Model 의 역할

Variant Model 은 다음을 책임진다 :

variant 가 필요한 경우 / 불필요한 경우 판단 기준 — § 8.3 의 4 표현 방식 후보를 언제 사용할지
표현 방식 선택 기준 — class modifier / data attribute / template parameter / variant family 중 어느 것을 어느 케이스에 적용할지의 criteria
family 별 variant 후보 관리 정책 — § 8.2 의 11 family 별 variant 축을 어떻게 관리 할지
family 분리 vs variant 흡수의 경계 기준 — 시각 / 구조 차이가 클 때 어느 쪽으로 가는지

받는 입력 :

Family CSS § 8.3 — 4 표현 방식 후보 (class modifier / data attribute / template parameter / variant family)
Family CSS § 8.2 — 11 family 후보 + 각 variant 축 1 차 정리
Frame Inventory Notes 의 variant meta (예 : F17 의 paired-rows, F18 의 vs-center-badge)

→ Variant Model = variant 의 선택 기준 / 관리 정책 정의. 실제 class 이름 / parameter 이름 / CSS 구현은 본 차수 X.

13.2 variant 가 필요한 경우 (판단 기준)

variant 는 family 를 유지하기 위한 장치 다. 다음 케이스 별 적합한 처리 :

케이스	적합한 처리
같은 family, 시각 / 구조 차이 작음	variant (class modifier 등) — § 8.3 의 4 표현 방식 후보 중
같은 family, cardinality 차이만 (예 : `columns[N=2~4]`)	template parameter
같은 family, asset 차이만	asset_meta 분기 (§ 12.5) — variant 영역 X
시각 / 구조 차이 큼	별도 family 분리 (variant 로 우겨 넣지 X)
사용 안 되는 variant	폐기 보류 — 32 frame 전체 변환 후 재검증 (§ 13.5)

🔒 핵심 원칙 — variant 는 family 를 유지 하기 위한 장치이며, family 를 억지로 유지하기 위한 장치는 아니다.

frame 차이가 family 의 시각 정체성을 깨뜨릴 정도면 variant 가 아니라 별도 family 분리 후보. § 13.5 의 분리 기준 참조.

13.3 4 표현 방식 선택 기준 (§ 8.3 cross-reference)

§ 8.3 = Family CSS perspective 에서 4 후보 표현 방식 정의. 본 § 13.3 = 어느 경우 어느 방식을 선택 할지의 criteria.

표현 방식 (§ 8.3 참조)	적합 criteria	적합하지 않은 criteria
CSS class modifier	시각 / 구조 차이가 family 안 변형 (예 : F17 `paired-rows` ↔ F18 `vs-center-badge`)	cardinality 차이만 / asset 차이만
Data attribute	마크업 같고 styling 만 분기 / runtime 동적 변경 가능성	시각 차이가 크고 구조까지 다른 경우
Template parameter	cardinality 차이 (예 : `columns[N=2~4]`, `items[N=3~7]`) / 슬롯 수 변화	시각 디자인 차이
Variant family (별도 entry)	차이가 너무 커 한 family 안 일관 표현 어려운 경우	차이 작음 (over-split 위험)

→ 본 표는 criteria 만. 어느 family 가 어느 방식을 채택할지 결정 은 § 8.3 (Family CSS perspective) + 사용자 승인. § 8.3 의 표 redescription 0.

13.4 family 별 variant 후보 (관리 perspective)

§ 8.2 = Family CSS perspective 에서 11 family 후보 + 각 variant 축 1 차 정리. 본 § 13.4 = Variant Model 측 관리 후보 perspective.

Family CSS Area	1 차 variant 축 (§ 8.2 참조)	Variant Model 관리 후보
`compare-paired.css`	`paired-rows` (F17) / `vs-center-badge` (F18)	CSS class modifier 적합 (시각 / 구조 차이 family 안 변형)
`compare-table.css`	`columns[N=2~4]` / `header_style` / `row_density`	template parameter 적합 (cardinality 차이)
`split-panel.css`	`right_items[N=3~8]` / `left_categories[N=2~5]` / `bracket_image`	template parameter 적합
`persona-cards.css`	`actor_count[3]` / `actor_hue_palette` / `photo_required`	F14 단일 frame, 추가 frame 변환 후 재검증
`three-pillar.css`	`pillars[3]` (현재 고정) / `column_hue_palette`	F13 단일 frame, 추가 frame 변환 후 재검증
`quadrant.css`	`quadrants[4]` (고정) / `bar_style` / `center_quote`	F16 단일 frame, 추가 frame 변환 후 재검증
`pill-list.css`	`items[N=3~7]` / `stacking_pattern` / `arc_decoration`	F09 단일 frame, 추가 frame 변환 후 재검증
`cycle.css`	`main_circles[3]` / `accent_circles[6]`	F12 단일 frame, 추가 frame 변환 후 재검증
`split-center.css`	(sparse data)	F27, 추가 관찰 후 확정
`system-diagram.css`	(sparse data)	F07, 추가 관찰 후 확정
`(asset-heavy / reference-like)`	F01 — pure CSS family X	variant 영역 X (→ asset_meta 영역, § 12.5)

→ § 8.2 의 11 family 표 redescription 0. 관리 perspective 만 (어느 표현 방식이 적합한가 + 단일 frame family 의 재검증 필요성).

13.5 추가 / 분리 / 폐기 기준

행위	기준	본 차수 결정
variant 추가	같은 family 안 frame 추가 시 (예 : 18 미변환 frame 변환 후) — 기존 variant 흡수 가능 vs 새 variant 필요	기준만 정의, 실제 추가는 사용자 승인
family 분리	variant 가 family 의 시각 정체성을 깨뜨리는 수준일 때 — variant 흡수 보다 family 분리 후보 (§ 13.2 핵심 원칙)	기준만 정의, 실제 분리는 사용자 승인
variant 폐기	32 frame 전체 변환 후 사용 안 되는 variant 발견 시	폐기 보류, 재검증 후 결정

→ Phase Z 절대 룰 "기존 templates 삭제 / 교체 실행 X" + "새 family CSS 파일 생성 X" 와 정합.

13.6 Variant Model 이 결정하지 않는 것

Skeleton § 4.7 의 "결정 안 함" 확장 + 본 5d 추가 :

❌ 실제 class / data attribute / parameter 이름 (구현 영역)
❌ family 분리 / 통합 최종 결정 (사용자 승인 영역)
❌ variant CSS / Jinja2 구현 (→ Family CSS § 8 / Jinja2 § 9 의 구현)
❌ AI 가 variant 선택 / 추가 / 변경 (Phase R' 회귀 방지 — 룰 2)
❌ Jinja2 parameter 이름 (구현 영역)
❌ token 자체 (→ Token Resolution § 4.5 / § 11)
❌ asset 자체 (→ Asset Policy § 4.6 / § 12)
❌ fallback 정책 (→ Fallback Behavior § 4.8, 5e)
❌ HTML / CSS / Jinja2 syntax (→ § 8 / § 9)

5d 차수 자체 점검 (작성 후)

✅ Variant Model 영역만 다룸 (Token / Asset / Fallback / Jinja2 / Family CSS 구현 / AI 침범 X)
✅ § 8.3 의 4 표현 방식 후보 표 redescription 0 — selection criteria perspective 만
✅ § 8.2 의 11 family 표 redescription 0 — 관리 perspective 만
✅ Frame Inventory Notes variant meta redescription 0 — cross-reference 만
✅ 룰 1 (frame 별 CSS X / family 수렴 장치) + 룰 2 (variant 선택은 코드/catalog, AI X) 섹션 머리 명시
✅ § 13.2 핵심 원칙 callout — "family 를 억지로 유지하기 위한 장치 X"
✅ § 13.5 추가 / 분리 / 폐기 모두 사용자 승인 영역
✅ § 13.6 boundary 9 항목 + 5e dedicated 영역 cross-reference

14. Fallback Behavior — 5e 본격 설계

⚠️ 룰 1 — Fallback Behavior 는 Zone Catalog status 라벨 진입 후의 동작 정책 이다.

status 결정 자체는 § 7 의 책임, 본 § 14 는 진입 후 동작 만 다룬다.

⚠️ 룰 2 — fallback 중 AI 호출은 zone content 조정 AI 다.

레이아웃 / family / variant / status 결정은 AI 영역이 아니다.

⚠️ 룰 3 — 레이아웃 회귀는 Zone Catalog status 변경으로만 트리거한다.

AI / Jinja2 가 직접 레이아웃을 변경하지 않는다.

14.1 Fallback Behavior 의 역할

Fallback Behavior 는 다음을 책임진다 :

Zone Catalog status 라벨 진입 후의 동작 정책 — fallback_candidate, review_required 가 어떻게 처리되는가
5 차 Fallback 단계의 catalog / runtime 책임 — IMPROVEMENT-REDESIGN.md 의 fallback 흐름 안에서 본 설계가 넘겨야 할 상태와 경계
fallback 중 AI 호출 boundary — § 10 의 룰을 fallback context 에서 재확인
레이아웃 회귀 트리거 — Phase Z 절대 룰 ("콘텐츠 줄이지 X, 그릇 변경") 의 catalog 단위 메커니즘

받는 입력 :

Zone Catalog (§ 7.4) 의 6 status 라벨 (특히 fallback_candidate, review_required)
IMPROVEMENT-REDESIGN.md 의 5 차 Fallback 흐름

→ Fallback Behavior = status 진입 후 동작 정책 정의. status 결정 / AI 호출 자체 / HTML 조립 / 레이아웃 결정은 본 차수 X.

14.2 fallback_candidate 진입 후 동작

fallback_candidate (§ 7.4 매트릭스의 low confidence cells) 진입 후의 catalog 단위 동작 :

동작	catalog / runtime 책임
zone 단위로 Fallback Behavior 흐름 진입	catalog 가 status 부여, fallback 단계는 IMPROVEMENT-REDESIGN.md 5 차 따름 (§ 14.4)
다른 family / 다른 frame 후보 검색	catalog 의 재매칭 룰 (구체 알고리즘은 매칭 시스템 V1~V4 영역)
레이아웃 회귀 트리거 검토	§ 14.6 의 절차
AI 호출 (4 차 fallback 에서)	§ 14.5 의 boundary 적용

🔒 fallback_candidate 는 AI 에게 레이아웃을 묻는 신호가 아니다.

AI 호출이 fallback 흐름 중 발생하더라도, AI 의 활동 반경은 zone content 조정 까지만. 레이아웃 / family / variant / status / 새 frame 결정은 모두 코드 / catalog 영역.

14.3 review_required 진입 후 동작

review_required (§ 7.4 의 모든 medium confidence cells) 진입 후 :

동작	catalog / runtime 책임
review payload 분리 + marker 부착	runtime (Jinja2 § 9.4)
사용자 검토 큐 진입	파이프라인 / 구현 영역 (catalog 책임 X)
검토 결과 반영	사용자 결정 → catalog 가 status 변경 (예 : `matched_zone` 으로 승격 또는 `fallback_candidate` 로 강등)

→ review 흐름 자체는 파이프라인 / 구현 영역. catalog 는 status 변경 인터페이스만 제공.

14.4 5 차 Fallback 단계 (cross-reference)

5 차 Fallback 단계 (1 차~5 차) 흐름은 IMPROVEMENT-REDESIGN.md 의 fallback 흐름 따른다.

본 문서는 그 흐름 안에서 catalog / runtime 이 넘겨야 할 상태와 금지 경계 를 정의한다 :

1~3 차 fallback (코드만) — catalog 가 재매칭 / status 재부여
4 차 fallback (AI 콘텐츠 조정) — § 14.5 의 AI 호출 boundary 적용
5 차 fallback (단일 프리셋 강제) — § 14.6 의 레이아웃 회귀 절차

→ 5 차 단계의 구체 알고리즘 / 임계값 / 호출 횟수 는 IMPROVEMENT-REDESIGN.md + 구현 영역 (redescription X).

14.5 fallback 중 AI 호출 — § 10 룰 재확인

4 차 fallback (AI 콘텐츠 조정) 에서 AI 호출 발생 시, § 10 의 룰이 그대로 적용 :

✅ AI 입력 (§ 10.3) : zone_meta, family_meta, mdx_excerpt, style_hint, layout_meta
✅ AI 출력 (§ 10.3) : zone.content.preview_text, zone.content.popup_full, zone.content.slot_payload
❌ AI 출력 금지 (§ 10.4) : HTML / class / Jinja2 / family / variant / preset / 새 frame / status

🔒 재확인 — fallback context 에서도 AI 의 호출 단위는 zone 안 콘텐츠 만.

fallback_candidate 진입 자체는 AI 호출 트리거가 아니다. AI 호출은 4 차 fallback 의 콘텐츠 조정 단계에서만 발생하며, 그때도 § 10 의 룰 (룰 1·2 + § 10.4) + § 9 의 룰 (룰 1·2 + § 9.5) = 5 면 차단 그대로 작동.

14.6 레이아웃 회귀 — Zone Catalog 트리거

Phase Z 절대 룰 "불일치 시 레이아웃 회귀 — 콘텐츠 줄이지 X, 그릇 변경" 의 catalog 단위 메커니즘 :

단계	책임
회귀 트리거 감지	catalog (§ 7) — status 분포 모니터링 (예 : 모든 zone 이 `fallback_candidate` / `review_required` 일 때)
다른 layout preset 후보 검색	catalog (§ 7.2-1 의 4 프리셋 중)
preset 변경 → zone 재구성	catalog 가 새 preset 의 zone 구성 결정 (§ 7.2-2), runtime 이 재조립 (§ 9)
AI 호출 (있다면)	§ 14.5 의 boundary — 콘텐츠 조정 까지만, 새 layout 결정 X

🔒 원칙 — 레이아웃 회귀는 그릇 변경이다.

콘텐츠, 텍스트, MDX 원문을 줄이지 않는다. AI 가 새 layout 을 만들지 않는다. 4 프리셋 Type A / B / B' / B'' 안에서 다른 그릇을 선택한다.

14.7 Fallback Behavior 가 결정하지 않는 것

Skeleton § 4.8 의 "결정 안 함" 확장 + 본 5e 추가 :

❌ Zone Catalog status 라벨 부여 자체 (→ § 7.4)
❌ AI 호출 자체 / AI 모델 / 프롬프트 / 호출 빈도 (→ § 4.4 / § 10 + 구현 영역)
❌ Jinja2 의 status 별 조립 인터페이스 (→ § 9.4)
❌ Family CSS 의 fallback 스타일링 (→ § 8 / § 4.2)
❌ token 자체 (→ § 11)
❌ asset 자체 (→ § 12)
❌ variant 자체 (→ § 13)
❌ 5 차 Fallback 의 구체 알고리즘 / 임계값 / 호출 횟수 (→ IMPROVEMENT-REDESIGN.md + 구현 영역)
❌ review 흐름의 사용자 검토 UX / 큐 메커니즘 (→ 파이프라인 / 구현 영역)
❌ 새 layout preset 추가 / 폐기 — 4 프리셋 안에서만 분기 (자유 디자인 금지)

5e 차수 자체 점검 (작성 후)

✅ Fallback Behavior 영역만 다룸 (status 부여 / AI 호출 자체 / Jinja2 조립 / Family CSS / token / asset / variant 침범 X)
✅ § 7.4 6 status 매트릭스 redescription 0 — 진입 후 동작 perspective 만
✅ § 9.4 status 별 조립 인터페이스 redescription 0
✅ § 10 AI Boundary 룰 redescription 0 — fallback context 의 재확인 만
✅ IMPROVEMENT-REDESIGN.md 5 차 Fallback 흐름 redescription 0 — § 14.4 짧은 cross-reference + 책임 perspective
✅ 룰 1 (status 진입 후 동작) + 룰 2 (AI = zone content 조정) + 룰 3 (레이아웃 회귀 = catalog 트리거) 섹션 머리 명시
✅ § 14.2 callout — "fallback_candidate 는 AI 에게 레이아웃 묻는 신호 X"
✅ § 14.5 callout — fallback context 에서도 AI = zone 콘텐츠만
✅ § 14.6 callout — "레이아웃 회귀는 그릇 변경" (Phase Z 절대 룰 prominent)
✅ § 14.7 boundary 10 항목 + 모든 dedicated 영역 cross-reference

15. 통합 검증 — 6 차

본 섹션은 1~5e 차수 결과의 검증 만 다룬다. 새 설계 없음, 기존 결정의 무결성 + Phase Z-2 진입 준비 판단만. 발견된 이슈는 § 15.4, Phase Z-2 진입 준비 판정은 § 15.5.

15.1 검증 방법

검증 도구 :

grep — 패턴 기반 무결성 / 표현 위반 탐지 (cross-reference, AI 결정 표현, legacy 재사용 표현 등)
의미 검토 — boundary 충돌 / 톤 / 후보 vs 확정 구분 (grep 만으로 잡히지 않는 경계 표현)

검증 항목 (8 개) :

항목	내용	도구
0	cross-reference 무결성	grep + 매칭
1	8 책임 영역 boundary 충돌 없음	의미 검토
2	AI 가 layout / preset / family / variant / HTML 결정 표현 없음	grep + 의미
3	Type A / B / B' / B'' 선택이 코드 / catalog 책임으로 일관	grep + 의미
4	fallback 이 AI layout 요청처럼 읽히지 않음	의미 검토
5	token / asset / variant 후보 가 구현 확정처럼 읽히지 않음	grep + 의미
6	legacy `templates/blocks` runtime 재사용처럼 읽히는 표현 없음	grep + 의미
7	Phase Z-2 구현 전 보류 항목이 명확함	grep + 의미

사전 분기 룰 (§ 15.2 결과에 따른 § 15.3 진행 방식) :

broken 수	처리
0 개	그대로 § 15.3 진행
1~2 개	즉시 수정 → § 15.3 진행, § 15.4 에 "non-blocker, 수정 완료" 기록
3~4 개	수정 후 진행, § 15.5 에 "minor drift 발견 / 수정" 명시
5 개+	§ 15.3 은 현재 상태로만 수행, § 15.5 에 "기준선 흔들림" 명시

severity 라벨 (§ 15.4) :

라벨	의미
`blocker`	Phase Z-2 진입 전 반드시 해결
`non-blocker`	Phase Z-2 진입 가능, 후속 정리

15.2 cross-reference 무결성

문서 내 § 패턴 매칭 결과 :

참조 추출 — § 4.1 ~ 4.8, § 7 / 7.1 / 7.2-1 / 7.2-2 / 7.3 / 7.4 / 7.5, § 8 ~ 14 의 모든 N.M 패턴 (50+ 회 인용)
실제 섹션 매칭 — 모든 인용이 실제 섹션 (## / ### / ####) 으로 해석됨. § 7.2-1 / 7.2-2 (sub-subsection) 도 실제 #### 헤딩 존재 (line 214 / 229)
broken 수 — 0 개

→ § 15.1 분기 룰의 "0 개" 케이스. 그대로 § 15.3 진행.

15.3 7 항목 검증 결과

항목	결과	근거 (대표 line)
1. 8 영역 boundary 충돌 없음	✅ PASS	각 영역의 "X 가 결정하지 않는 것" 섹션 (§ 7.5 / 8.6 / 9.6 / 10.6 / 11.6 / 12.6 / 13.6 / 14.7) 이 다른 영역 dedicated section 으로 cross-reference. 침범 표현 0.
2. AI 가 layout / preset / family / variant / HTML 결정 표현 없음	✅ PASS	line 47, 99, 552, 587, 617, 659, 1049, 1111, 1147 — 모두 금지 또는 Phase R' 회귀 방지 맥락. 결정 표현 0.
3. Type A / B / B' / B'' = 코드 / catalog 책임 일관	✅ PASS	line 47 ("코드만"), 196 ("catalog 가 결정"), 225, 480, 587, 617, 1158, 1181 — 모두 catalog 또는 "AI X" 로 일관.
4. fallback ≠ AI layout 요청	✅ PASS	line 291, 1111 (🔒), 1147 (🔒), 1149, 1162 (🔒) — 명시적 callout. fallback_candidate 진입 ≠ AI 호출 트리거 명시.
5. token / asset / variant 후보 ≠ 구현 확정	✅ PASS	"후보" 59 회 사용, 모두 working name / 후보 상태. line 737 ("아직 확정 X"), 785, 904, 993, 1038, 1066 — "Phase Z-2 구현 진입 시 사용자 승인" 패턴.
6. legacy `templates/blocks` runtime 재사용 표현 없음	✅ PASS	line 48 ("legacy blocks runtime reuse X ... 참고만"), 159 / 162 / 433 — 삭제 보류 + runtime 재사용 X 명시.
7. Phase Z-2 보류 항목 명확	✅ PASS	line 3, 20, 158, 181, 737, 785, 904 + "(구현 영역)" 태그 17 회 — Phase Z-2 입력 문서 위치 명확, 보류 항목 sweep 가능.

→ 7 항목 모두 PASS.

15.4 발견된 이슈

이슈	severity	처리
(없음)	—	—

→ blocker / non-blocker 모두 0 건. 검증 결과 깨끗.

15.5 Phase Z-2 진입 준비 상태

항목	상태
1~5e 차수 본격 설계	✅ 완료
cross-reference 무결성	✅ broken 0 (§ 15.2)
7 항목 boundary / 회귀 방지	✅ 7/7 PASS (§ 15.3)
발견된 issue	✅ 0 건 (§ 15.4)
Phase Z-2 입력 문서 위치	✅ 명확 (§ 1 / § 6)

판정 : Phase Z-2 진입 기준선 (설계 baseline) 준비됨.

🔒 Phase Z-2 진입 준비는 구현 시작 승인이 아니다. 구현 착수는 별도 사용자 승인 후 진행한다.

16. Phase Z-2 MVP-1 scaffold 허용 규칙

본 섹션은 § 15 통합 검증 완료 후 추가된 구현 규칙. Phase Z-2 MVP-1 이 HTML 출력을 위해 필요한 실행 껍데기 (scaffold) 의 허용 범위 + 종료 조건 명시. 예외 가 아닌 원칙 안의 허용 규칙 — legacy 재사용 X / 정식 family 확정 X 는 그대로 유지.

16.1 배경 — 왜 필요한가

Phase Z-2 MVP-1 은 :

legacy templates/blocks/structures/* runtime 재사용 X (§ 1, line 48)
신규 token / asset / variant / Family CSS 확정 보류 (§ 11.5 / 12.5 / 13.5)

→ 실제 HTML 렌더링을 위해서는 얇은 실행 껍데기 가 필요. 이를 원칙 안의 허용 규칙 으로 정의한다.

16.2 핵심 경계

항목	상태
legacy runtime 재사용	❌ 금지 (기존 룰 유지)
정식 Family CSS 확정	❌ 보류 (§ 11.5 / 12.5 / 13.5 유지)
MVP 출력용 scaffold	✅ 허용 (본 § 16 의 룰 내)

16.3 scaffold 허용 룰

룰	내용
위치	`templates/phase_z2/` (별도 디렉토리. 기존 `templates/blocks/` 와 분리)
마커	각 scaffold 파일 상단에 1 줄 주석 필수 : `<!-- Phase Z-2 MVP-1 scaffold — MVP-2 이후 정식 Family CSS partial 로 대체. legacy structures/* 는 stylization 참고만. -->`
토큰	기존 token 만 참조. 신규 token 추가 X
자산	기존 asset 만. 신규 asset 추가 X
variant	§ 8.2 의 11 family 후보 안에서만. 신규 variant 추가 X
legacy 파일 import	❌ 금지. legacy `templates/blocks/structures/.html` 는 stylization 참고만*, 직접 import / include / extend X
시각 디자인 도출	frame 메타 + Figma 좌표 + 기존 token 으로 수학적 도출. legacy 시각 모방 우회 금지

16.4 종료 조건

scaffold 의 수명 = MVP-1 ~ MVP-2 직전 :

MVP-1 : scaffold 로 HTML 출력
MVP-2 : 정식 Family CSS partial 로 대체. templates/phase_z2/ 디렉토리 삭제 또는 정식 위치로 이동
종료 조건 : MVP-2 entry 시 본 § 16 의 scaffold 룰 무효화

🔒 scaffold 는 실행 껍데기 이지 디자인 확정 이 아니다. MVP-2 에서 정식 Family CSS partial 로 대체하지 않으면 scaffold 가 영구화 되는 위험. MVP-2 진입 시 — § 16 무효화 + scaffold 삭제 + Family CSS 확정 = 3 동시 조건.

16.5 cross-reference

§ 1 line 48 — legacy runtime reuse X (유지)
§ 8 — Family CSS 정식 확정 보류 (유지)
§ 11.5 / 12.5 / 13.5 — 신규 token / asset / variant 보류 (유지)
§ 15.5 — Phase Z-2 진입 준비 상태 (본 § 16 은 진입 후 구현 시 적용)
§ 17 — MVP-1 결과 (mvp1_test5: visual fidelity FAIL) 에 따른 방향 전환. scaffold polish 중단, frame-derived partial promotion 으로 진화

17. Frame-derived Partial Promotion — MVP-1.5+

본 섹션은 § 16 scaffold 허용 룰 의 방향 전환. MVP-1 progression (mvp1_test2 ~ mvp1_test5) 에서 발견된 사실 — scaffold 가 V4 매칭한 frame 의 실제 변환물을 대체하지 못함 — 에 따른 진화. scaffold polish 는 중단, frame-derived partial promotion 으로 전환.

17.1 배경 — MVP-1 progression (교훈 보존)

run_id	결과	교훈
mvp1_test2	data chain 동작, raw dump 발견	mapper output 이 slot 모양이어야 함 (raw section dump X)
mvp1_test3	data PASS, visual FAIL (overflow + slide-base contract 미충족)	"기술 chain PASS ≠ MVP PASS". 시각 게이트 필수
mvp1_test4	overflow check PASS, 내부 clipping 미검출	`overflow:hidden` 은 안전장치. 진짜 게이트는 Selenium 내부 clipping 검출
mvp1_test5	runtime PASS, visual fidelity FAIL	scaffold polish 한계 — V4 가 고른 frame 의 실제 변환물 을 runtime 이 안 쓰면 visual fidelity 못 나옴

→ 방향 전환 : scaffold polish 중단. frame-derived partial promotion 으로 진화.

17.2 § 16 scaffold vs § 17 promotion

항목	§ 16 scaffold	§ 17 frame-derived partial
출처	코드에서 직접 작성 (token + 색 추정)	`figma_to_html_agent/blocks/{id}/index.html` (1:1 Figma 변환물)
시각 fidelity	근사	Figma 와 1:1 (정확한 색 / 비율 / 구조)
Templating	`{{ slot_payload.* }}`	`{{ slot_payload.* }}` (동일)
위치	`templates/phase_z2/frames/`	`templates/phase_z2/families/`
사용 범위	frame 미변환 시 임시 — 변환 완료 시 즉시 § 17 partial 로 대체	변환 완료된 frame 에 대한 정식 runtime partial

17.3 Promotion 규칙

룰	내용
Source	`figma_to_html_agent/blocks/{frame_id}/index.html` (1:1 변환물 필수)
Target	`templates/phase_z2/families/{template_id}.html`
변환 방식	templating — index.html 의 구조 / CSS / 색 / 비율 유지, 텍스트만 `{{ slot_payload.* }}` 로 치환
단순 복사	❌ 금지 — runtime 에서 V4 매칭한 콘텐츠 못 받음
1:1 변환물 없는 frame	변환 먼저 (figma_to_html_agent 영역, 별도 작업 + 사용자 승인 필수)
마커	partial 파일 상단에 : `<!-- Phase Z-2 frame-derived partial — derived from figma_to_html_agent/blocks/{id}/index.html. MVP-2 family CSS 확정 시 대체. -->`

17.4 § 16 scaffold 와의 관계

§ 16 scaffold = frame 미변환 시 임시 처리 로만 허용 (변환물 없는 frame)
변환 완료 시 즉시 § 17 partial 로 대체. scaffold 는 폐기
legacy templates/blocks/structures/ runtime 재사용 X 는 그대로 유지 (§ 1 line 48)

17.5 종료 조건

partial 의 수명 = MVP-1.5 ~ MVP-2 직전. MVP-2 에서 정식 Family CSS 확정 시 :

partial 위치 (templates/phase_z2/families/) → 정식 family CSS 위치로 이동 / 통합
§ 17 룰 무효화

🔒 partial = frame-derived 정확한 산출물 이지만 family CSS 확정 은 아니다. MVP-2 에서 정식 family 로 통합하지 않으면 partial 이 영구화 되는 위험. § 16 scaffold 와 동일한 lifecycle 관리 필요.

17.6 cross-reference

§ 16 — scaffold 허용 룰 (MVP-1 한정, 미변환 frame 임시 처리)
§ 8 — Family CSS 정식 확정 (MVP-2 종료 시점)
§ 11.5 / 12.5 / 13.5 — 신규 token / asset / variant 보류 (유지)

76 KiB Raw Blame History Unescape Escape

Phase Z Catalog / Runtime Design

1. 문서 위치 / 목적

2. 입력 문서

3. 핵심 원칙 (Phase Z 준수)

4. 책임 영역 (8 영역)

4.1 Zone Catalog

4.2 Family CSS

4.3 Jinja2 Runtime Templates

4.4 AI Boundary

4.5 Token Resolution

4.6 Asset Policy

4.7 Variant Model

4.8 Fallback Behavior

5. 비범위

6. 단계적 작성 계획

7. Zone Catalog — 2 차 본격 설계

7.1 Zone Catalog 의 역할

7.2 레이아웃 프리셋 + Zone 타입

7.2-1 레이아웃 프리셋 후보

7.2-2 Zone 타입 후보

7.3 frame zone_application 과 catalog 의 관계

7.4 catalog status 라벨 — zone_application × confidence 매트릭스

7.5 Zone Catalog 가 결정하지 않는 것

7 차수 자체 점검 (작성 후)

8. Family CSS — 3 차 본격 설계

8.1 Family CSS 의 역할

8.2 Family CSS Area 후보 (11)

8.3 variant 참조 방식

8.4 token 참조 방식

8.5 asset 의존 표시 방식

8.6 Family CSS 가 결정하지 않는 것

8 차수 자체 점검 (작성 후)

9. Jinja2 Runtime Templates — 4 차 본격 설계

9.1 Jinja2 Runtime Templates 의 역할

9.2 입력 데이터 계약

9.3 조립 위계

9.4 Zone Catalog status label → 조립 인터페이스

9.5 AI 출력의 Jinja2 진입 위치

9.6 Jinja2 가 결정하지 않는 것

9 차수 자체 점검 (작성 후)

10. AI Boundary — 5a 본격 설계

10.1 AI Boundary 의 역할

10.2 AI 호출 단위 — zone content only (scope)

10.3 허용 입력 / 허용 출력

허용 입력 (AI 가 받는 것)

허용 출력 (AI 가 만드는 것 — zone.content.*)

10.4 금지 출력

10.5 Jinja2 입력 계약 (§ 9.2) 과의 연결

10.6 AI Boundary 가 결정하지 않는 것

5a 차수 자체 점검 (작성 후)

11. Token Resolution — 5b 본격 설계

11.1 Token Resolution 의 역할

11.2 Token Inventory 4 status 처리 룰

11.3 frame raw px ↔ slide-body scale 위계 매핑

11.4 family CSS 와의 참조 인터페이스 (§ 8.4 cross-reference)

11.5 추가 / 변경 / 폐기 보류 원칙

11.6 Token Resolution 이 결정하지 않는 것

5b 차수 자체 점검 (작성 후)

12. Asset Policy — 5c 본격 설계

12.1 Asset Policy 의 역할

12.2 자산 의존도 등급 처리 룰

12.3 자산 유형 분기

12.4 자산 상태 라벨 (5 후보) — centerpiece

12.5 asset_meta 정의 + Jinja2 / Family CSS 참조 인터페이스

12.6 Asset Policy 가 결정하지 않는 것

5c 차수 자체 점검 (작성 후)

13. Variant Model — 5d 본격 설계

13.1 Variant Model 의 역할

13.2 variant 가 필요한 경우 (판단 기준)

13.3 4 표현 방식 선택 기준 (§ 8.3 cross-reference)

13.4 family 별 variant 후보 (관리 perspective)

13.5 추가 / 분리 / 폐기 기준

13.6 Variant Model 이 결정하지 않는 것

5d 차수 자체 점검 (작성 후)

14. Fallback Behavior — 5e 본격 설계

14.1 Fallback Behavior 의 역할

14.2 fallback_candidate 진입 후 동작

14.3 review_required 진입 후 동작

14.4 5 차 Fallback 단계 (cross-reference)

76 KiB

Raw Blame History

7.4 catalog status 라벨 — `zone_application × confidence` 매트릭스

허용 출력 (AI 가 만드는 것 — `zone.content.*`)

12.5 `asset_meta` 정의 + Jinja2 / Family CSS 참조 인터페이스