diff --git a/README.md b/README.md
index 0ca51c4..9d76d7c 100644
--- a/README.md
+++ b/README.md
@@ -1,158 +1,269 @@
-# C.E.L. Slide Pipeline
+# Design Agent / C.E.L Slide Automation
 
-## 이 프로젝트는 무엇인가
+## 1. 프로젝트 개요
 
-MDX 기반 콘텐츠를 입력하면, 1280×720 슬라이드 HTML로 자동 변환하는 파이프라인입니다.
+MDX 문서를 입력받아 1280×720 프레젠테이션 슬라이드 HTML 로 자동 변환하는 파이프라인입니다.
 
-텍스트 콘텐츠를 넣으면, 구조를 분석하고 BEPs(Figma) 디자인을 매칭하여 슬라이드를 만들어줍니다.
+- **입력**: MDX 파일 (텍스트 + 표 + 불릿 + JSX 블록 + details + 이미지)
+- **변환 흐름**: V4 매칭 → Phase Z 렌더 파이프라인
+- **출력**: `final.html` (단일 슬라이드) + 단계별 산출물 (의사결정 추적)
+- **최종 목표**: 파이프라인 + AI 보정 + DB / 카탈로그 + 프론트엔드 에디터가 연결된 *제품형* 시스템
 
----
+### 핵심 용어 (처음 보는 분 위해)
 
-## 어떻게 구성/구현되어 있는가
+| 용어 | 의미 |
+|---|---|
+| **MDX** | 마크다운 + JSX 컴포넌트 결합 형식. 슬라이드의 *원본 콘텐츠* |
+| **Figma BEPs frame** | 디자인 원천. 32 개의 Figma 프레임을 HTML / CSS 로 변환해 `figma_to_html_agent/blocks/` 에 누적 |
+| **V4** | MDX 섹션 ↔ Figma 프레임 매칭 시스템 (네 번째 버전). 콘텐츠 의미 / 구조 / 키워드 / 카디널리티 등 5 개 축으로 점수화. `tests/matching/v4_full32_result.yaml` 에 결과 저장 |
+| **Phase Z** | 현재 활성 렌더 파이프라인. V4 매칭 결과를 받아 슬라이드 HTML 로 만듦 |
+| **프레임 (Frame)** | Figma 디자인 단위. 1 개의 슬라이드 영역(zone) 안에 들어감 |
+| **Internal Region** | zone 내부의 콘텐츠 배치 단위 (text 영역, table 영역, image 영역 등) |
+| **Frame Slot** | frame 내부의 콘텐츠 자리 (예: pillar_1, quadrant_1, process_column) |
 
-### 전체 흐름
+### 위계
 
 ```
-MDX 입력 → 정규화 → 꼭지 추출(AI) → zone 구분 → BEPs 매칭 → 조립 → 검증 → 출력
-```
-
-### 구조
-
-- **slide-base:** 1280×720 슬라이드 프레임. 대목차 + 구분선 + 본문 영역 + 핵심 인사이트(footer)
-- **레이아웃:** slide-body 안의 zone 분배 형태 (Type A/B/B'/B'')
-- **zone:** 레이아웃이 정한 콘텐츠 영역 (top/bottom 등)
-- **프레임 (구 "블록"):** zone 안에 들어가는 디자인 단위. Figma에서 추출한 BEPs 디자인을 HTML/CSS로 변환한 것
-- **catalog:** 프레임의 메타 정보 (구조, 슬롯, 매칭 조건)
-
-> ⚠️ Phase Z (2026-04-28) 부터 "블록" → "프레임" 으로 용어 통일. 기존 코드 (`block_reference.py`, `templates/blocks/`, `BLOCK-RULES.md` 등) 는 점진적 정리.
-
-### 주요 파일
-
-| 파일 | 역할 |
-|------|------|
-| `src/pipeline.py` | 파이프라인 오케스트레이션 |
-| `src/section_parser.py` | 중목차 추출, 구조 분류 |
-| `src/block_reference.py` | BEPs 디자인 매칭 |
-| `src/block_assembler.py` | 슬라이드 HTML 조립 |
-| `templates/blocks/slide-base.html` | 슬라이드 프레임 |
-| `templates/catalog.yaml` | 블록 메타 정보 |
-
-### 산출물
-
-각 실행은 `data/runs/{run_id}/` 아래에 저장됩니다.
-
-| 파일 | 내용 |
-|------|------|
-| `final.html` | 최종 슬라이드 |
-| `final_context.json` | 파이프라인 결과 데이터 |
-| `steps/*.html` | 단계별 디버그 보드 |
-| `첨부*_상세*.html` | popup 상세 내용 |
-
----
-
-## 무슨 문제가 있는가
-
-| 문제 | 설명 |
-|------|------|
-| **블록마다 스타일이 제각각** | 각 블록 HTML 안에 font-size, color, padding이 직접 박혀있어서, 같은 슬라이드 안에서 블록이 섞이면 위계가 안 맞음 |
-| **slide-base에 구조+스타일 혼재** | 프레임 HTML 안에 전체 CSS가 인라인으로 들어있어서 유지보수가 어려움 |
-| **블록이 완성 HTML** | 블록이 구조+스타일+값을 모두 포함하고 있어서, 재사용/조합이 안 됨 |
-| **매칭 안 되면 고정 렌더** | BEPs에 맞는 블록이 없을 때 코드가 1회 고정 렌더하고 끝. 반복 조정 없음 |
-| **빈 공간/overflow 방치** | 렌더 후 빈 공간이 있어도 조정 안 하고, overflow만 감지 |
-| **검증이 약함** | overflow 측정만 하고, 정렬/위계/가독성 같은 시각 품질은 미검증 |
-
----
-
-## 어떻게 개선하려 하는가
-
-핵심은 3가지입니다.
-
-1. **블록을 구조 부품화** — 완성 HTML이 아니라, 구조만 담고 스타일은 토큰으로 분리
-2. **스타일을 토큰으로 통일** — 블록마다 제각각인 폰트/색/여백을 공통 기준으로
-3. **2경로 파이프라인** — 매칭되면 바로 쓰고(direct-fit), 안 되면 재구성(recipe)
-
-### AS-IS → TO-BE
-
-> ⚠️ 아래 AS-IS / TO-BE 는 Phase Q ~ T 시점의 흐름. **현재 (Phase Z) 흐름은 [`IMPROVEMENT-REDESIGN.md`](IMPROVEMENT-REDESIGN.md)** 참조.
-
-```
-AS-IS (Phase Q ~ T):
-  AI가 먼저 꼭지를 추출하고
-  → 매칭 블록이 있으면 삽입, 없으면 코드가 1회 고정 렌더
-  → 빈 공간이 있어도 그냥 둠
-  → 블록마다 font-size, color가 직접 박혀있어서 섞이면 위계 안 맞음
-
-TO-BE (Phase Q ~ T):
-  중목차 기준으로 zone을 먼저 나누고
-  → TF-IDF로 BEPs 매칭 시도
-  → 매칭되면 블록 삽입 + 크기 조절 (direct-fit)
-  → 안 되면 AI가 꼭지 정리 + 유사 디자인으로 redesign + 반복 조정 (recipe)
-  → 빈 공간/overflow를 자동 재분배
-  → 모든 블록이 토큰 기반이라 스타일 통일
-
-NEW (Phase Z, 2026-04-28 ~):
-  STAGE 1) MDX 분석 + 레이아웃 매칭 (Type A/B/B'/B'')
-  STAGE 2) Zone 별 텍스트 1차 배치
-  STAGE 3) Zone 별 프레임 매칭 — V1~V4 (완벽/어정쩡/안됨 분기)
-  STAGE 4) 프레임 검토 + 컨테이너 조정 (5차 Fallback)
-  STAGE 5) HTML 조립 (slide-base + Jinja2) + 검증 + 출력
-  ⭐ AI = zone 안 콘텐츠만 / HTML 구조 = 코드 (Jinja2)
-  ⭐ 자유 디자인 금지 — 프레임 DB 참고 필수
-  ⭐ MDX 원문 무손실 보존
+Slide → Zone → Internal Region → Frame → Frame Slot → Content
 ```
 
 ---
 
-## 현재 상태
+## 2. 전체 실행 구조 (22 단계 파이프라인)
 
-| 대상 | 슬라이드 변환 | 파이프라인 자동화 |
-|------|-------------|----------------|
-| MDX 03 (3개 목표 + 비교표) | ✅ 완료 | ✅ 파이프라인 연결 |
-| MDX 02 (목표 + 프로세스 + 상세표) | ✅ 완료 | △ 파이프라인 연결, 시각 품질 개선 중 |
-| MDX 01 (Type A, sidebar 구조) | ✅ 완료 (개별) | 미연결 |
-| 토큰 기반 CSS 체계 | - | ✅ 정의 완료, slide-base 적용 |
-| Figma 블록 추출 | - | 진행 중 (`figma_to_html_agent/blocks/`) |
-| **매칭 시스템 (V1~V4)** | - | **✅ 별도 검증 완료** (`tests/`) — TARGET 3/4 |
-| **Phase Z 통합 설계** | - | **✅ 설계 완료** (`IMPROVEMENT-REDESIGN.md`) — 구현 대기 |
+22 단계를 3 개 블록으로 묶어 운영합니다:
+
+- **블록 A — 렌더 전 계획 (Step 0~12)**: 모든 의사결정. 가장 중요한 영역.
+- **블록 B — 렌더 (Step 13)**: Jinja2 + 프레임 partial → final.html.
+- **블록 C — 렌더 후 점검 / 예외 처리 (Step 14~22)**: 시각 검증 + 필요 시 재시도. *블록 A 가 정밀하면 거의 동작 안 함*.
+
+```mermaid
+flowchart TD
+    Input([MDX 입력])
+
+    subgraph BlockA["블록 A — 렌더 전 계획 (Step 0~12)"]
+        S0["Step 0<br/>사전 준비<br/><sub>카탈로그 / 컨트랙트 / V4 결과</sub>"]
+        S1["Step 1<br/>MDX 업로드"]
+        S2["Step 2<br/>MDX 정규화<br/><sub>frontmatter / 목차 / 푸터 분리</sub>"]
+        S3["Step 3<br/>콘텐츠 객체 추출<br/><sub>텍스트 / 표 / 이미지 / details</sub>"]
+        S4["Step 4<br/>섹션 내부 구성 계획<br/><sub>전체 / 묶기 / 분할</sub>"]
+        S5["Step 5<br/>V4 매칭 후보 추출<br/><sub>거절 제외 최대 6 개</sub>"]
+        S6["Step 6<br/>구성 계획<br/><sub>어떤 섹션 묶음 = 한 zone</sub>"]
+        S7["Step 7<br/>슬라이드 레이아웃 계획<br/><sub>8 개 프리셋 중 선택</sub>"]
+        S8["Step 8<br/>Zone / Region 비율 계획"]
+        S9["Step 9<br/>적용 계획<br/><sub>V4 후보를 어떻게 넣을지 번역</sub>"]
+        S10["Step 10<br/>프레임 컨트랙트 확인"]
+        S11["Step 11<br/>콘텐츠 → Region → Frame Slot 매핑"]
+        S12["Step 12<br/>슬롯 데이터 생성"]
+    end
+
+    subgraph BlockB["블록 B — 렌더 (Step 13)"]
+        S13["Step 13<br/>HTML 렌더<br/><sub>Jinja2 + 프레임 partial → final.html</sub>"]
+    end
+
+    subgraph BlockC["블록 C — 렌더 후 점검 / 예외 처리 (Step 14~22)"]
+        S14["Step 14<br/>시각 점검<br/><sub>Selenium 으로 실제 렌더 검사</sub>"]
+        S15["Step 15<br/>문제 분류<br/><sub>오버플로우 / 잘림 / 비율 어긋남</sub>"]
+        S16["Step 16<br/>재시도 라우터<br/><sub>어떤 조치를 할지 선택</sub>"]
+        S17["Step 17<br/>조치 실행<br/><sub>zone 비율 재시도 / 팝업 전환 / ...</sub>"]
+        S18["Step 18<br/>실패 분류"]
+        S19["Step 19<br/>다음 조치 제안"]
+        S20["Step 20<br/>슬라이드 상태 결정<br/><sub>PASS / 시각 회귀 / ...</sub>"]
+        S21["Step 21<br/>디버그 / 추적 기록"]
+        S22["Step 22<br/>사용자 확인 / 내보내기"]
+    end
+
+    Visual{"시각 점검 OK?"}
+    Repair{"수정 방식?"}
+    AI["AI 보정 / 재구성<br/><i>(향후 예정)</i>"]
+
+    Input --> S0 --> S1 --> S2 --> S3 --> S4 --> S5
+    S5 --> S6 --> S7 --> S8 --> S9 --> S10 --> S11 --> S12
+    S12 --> S13 --> S14 --> Visual
+    Visual -->|예| S20 --> S21 --> S22
+    Visual -->|아니오| S15 --> S16 --> S17 --> S18 --> S19 --> Repair
+    Repair -->|결정론적<br/>zone 재시도 / 팝업 / 레이아웃 조정| S13
+    Repair -->|AI 필요<br/>재구성 / 점수 낮음 / 반복 오버플로우| AI
+    AI --> S13
+
+    classDef plan fill:#e7f5ff,stroke:#1971c2,color:#000
+    classDef render fill:#fff3cd,stroke:#f59f00,color:#000
+    classDef check fill:#f3f0ff,stroke:#7048e8,color:#000
+    classDef decision fill:#ffd8a8,stroke:#d9480f,color:#000
+    classDef future fill:#f8f9fa,stroke:#868e96,color:#000,stroke-dasharray: 5 5
+
+    class S0,S1,S2,S3,S4,S5,S6,S7,S8,S9,S10,S11,S12 plan
+    class S13 render
+    class S14,S15,S16,S17,S18,S19,S20,S21,S22 check
+    class Visual,Repair decision
+    class AI future
+```
+
+각 단계의 자세한 진행 상태는 [`PHASE-Z-PIPELINE-STATUS-BOARD.md`](docs/architecture/PHASE-Z-PIPELINE-STATUS-BOARD.md) 가 단일 출처입니다 (자주 갱신됨).
 
 ---
 
-## 다음 단계 방향 — Phase Z 매칭 시스템 통합
+## 3. 현재 완료 수준
 
-상세: [IMPROVEMENT-REDESIGN.md](IMPROVEMENT-REDESIGN.md)
+### 3.1 MDX03 정상 경로 — 통과
 
-| 단계 | 내용 |
-|------|------|
-| Phase Z-1 | 통합 prototype — Stage 1.7 만 V4 로 교체, MDX 03 회귀 |
-| Phase Z-2 | 매칭 + 프리셋 (Type A/B/B'/B'') 통합 |
-| Phase Z-3 | 컨테이너 검증 + 5 차 Fallback |
-| Phase Z-4 | 전체 통합 + 검증 |
+기준 샘플 (`samples/mdx_batch/03.mdx`) 의 자동 렌더 경로가 정상으로 닫혔습니다.
 
-**핵심 위계** (Phase Z 정리) :
 ```
-slide → slide-base → slide-body → 레이아웃 → Zone → 프레임
+overall                : PASS
+visual_check_passed    : true
+full_mdx_coverage      : true
+adapter_needed_count   : 0
+content_truncated_count: 0
+units                  : 03-1 → F13 (그대로 사용 가능, 0.927)
+                         03-2 → F29 (그대로 사용 가능, 0.920)
 ```
 
-**5 단계 새 흐름** :
-1. MDX 분석 + 레이아웃 매칭
-2. Zone 별 텍스트 배치
-3. Zone 별 프레임 매칭 (완벽 / 어정쩡 / 안 됨)
-4. 프레임 검토 + 컨테이너 조정
-5. HTML 조립 + 검증 + 출력
+### 3.2 22 단계 진행 수준
+
+전체 약 **65~70%**. MDX03 정상 경로는 닫혔고, 일반화 (다른 MDX / 예외 케이스 / 재시도 / UI) 는 진행 중.
+
+상세 ✅ / ⚠ / ❌ 표는 [`PHASE-Z-PIPELINE-STATUS-BOARD.md`](docs/architecture/PHASE-Z-PIPELINE-STATUS-BOARD.md) 에서 확인.
+
+### 3.3 검증 / 실험 저장소 성격
+
+본 저장소는 *제품형 시스템* 까지 가는 과정에서 다음 샘플을 *검증 재료* 로 사용:
+
+- `samples/mdx_batch/03.mdx` — 기준 샘플 (정상 경로 확인)
+- `samples/mdx_batch/04.mdx` — 다음 검증 예정
+- `samples/mdx/01. ...mdx` / `02. ...mdx` — 향후 검증
+
+**샘플 MDX 는 로드맵 단계가 아니라 22 단계 파이프라인을 보완하기 위한 검증 재료입니다.**
+
+### 3.4 결정 변경 이력
+
+설계 변경 / 폐기된 안 / 일치 정정의 시간 순 기록은 [`PHASE-Z-CHANGE-LOG.md`](docs/architecture/PHASE-Z-CHANGE-LOG.md) 참조.
+
+---
+
+## 4. 향후 로드맵
+
+```mermaid
+flowchart LR
+    R1["1. 22 단계 파이프라인<br/>안정화<br/><sub>프레임 연결 / 시각 점검 보강 /<br/>MDX 정리 / 01·02·04 검증</sub>"]
+    R2["2. 옛 코드 검토<br/>및 반영<br/><sub>Phase Q 25 모듈 audit</sub>"]
+    R3["3. AI 보정 /<br/>재구성 단계<br/><sub>점수 낮음 / 모두 거절 /<br/>재구성 / 오버플로우 반복</sub>"]
+    R4["4. DB / 카탈로그<br/>정리<br/><sub>프레임 / V4 / 실행이력 / 사용자 변경</sub>"]
+    R5["5. 프론트엔드 연결<br/><sub>실행 목록 / 타임라인 /<br/>매칭 후보 / 적용 계획</sub>"]
+    R6["6. HTML 수정 기능<br/><sub>user_overrides.json</sub>"]
+    R7["7. 프레임 지속<br/>업데이트<br/><sub>Figma → Phase Z 어댑터 추가</sub>"]
+
+    R1 --> R2 --> R3 --> R4 --> R5 --> R6 --> R7
+
+    classDef current fill:#fff3cd,stroke:#f59f00,color:#000
+    classDef future fill:#f3f0ff,stroke:#7048e8,color:#000
+    classDef later fill:#f8f9fa,stroke:#868e96,color:#000,stroke-dasharray: 5 5
+
+    class R1 current
+    class R2,R3 future
+    class R4,R5,R6,R7 later
+```
+
+**현재 위치**: 단계 1 (22 단계 파이프라인 안정화). MDX03 정상 경로 닫힘 → 일반화 진행 중.
+
+### 단계별 상세
+
+**1. 22 단계 파이프라인 안정화 (현재)**
+
+- 프레임 ↔ Phase Z 연결 구조 정리
+  - F14 / F11 / F18 등 Phase Z 가 아직 받지 못하는 Figma 프레임의 어댑터 추가
+  - *Figma 새 디자인이나 V4 새 매칭이 아니라*, 이미 두 곳 (Figma / V4) 에 있는 프레임을 Phase Z 런타임이 받아 쓸 수 있게 연결만
+- 시각 점검 범위 확장 (Step 14)
+  - 누락 이미지 / 표 잘림 / 이미지 비율 어긋남 / 빈 공간 검사
+- MDX 정규화 / 정리 방법 적용 (Step 2 / 3 / 4)
+- MDX 01 / 02 / 04 검증으로 예외 케이스 발견 + 파이프라인 일반화
+
+**2. 옛 코드 검토 및 반영**
+
+- `src/` 안 옛 25 개 모듈 (slide_measurer, space_allocator, content_editor 등) 각각 검토
+- 살릴 기능 / 폐기할 모듈 / 학습 자료로만 둘 것 분류
+- 살릴 것은 Phase Z 로 이식
+
+**3. AI 보정 / 재구성 단계**
+
+- 점수 낮음 / 모두 거절 / 재구성 필요 / 오버플로우 반복 케이스 처리
+- AI 가 MDX 원문은 보존하면서 슬롯 데이터 / Region / 팝업 / 레이아웃 제안
+- 연결되는 단계: Step 9 / 12 / 17 / 19 / 21
+
+**4. DB / 카탈로그 정리**
+
+- 프레임 카탈로그 / 컨트랙트
+- V4 결과
+- 실행 이력 / 단계별 산출물
+- 사용자 변경 이력 (어떤 후보를 골랐는지 등)
+
+**5. 프론트엔드 연결**
+
+- 실행 목록 / preview.png / final.html 보기
+- 22 단계 타임라인 (각 단계 산출물 시각화)
+- V4 1~6 위 후보 표시 + 사용자 선택
+- 레이아웃 / Region / 적용 계획 표시
+- 시각 점검 / 재시도 / 다음 조치 결과
+
+**6. HTML 수정 기능**
+
+- 텍스트 수정
+- 이미지 크기 / 위치 조정
+- 프레임 후보 변경 (V4 의 1 위 외 다른 위 선택)
+- 레이아웃 / Region 조정
+- `user_overrides.json` 으로 저장 (final.html 직접 수정 X — MDX 원문 보존 원칙 정합)
+
+**7. 프레임 지속 업데이트**
+
+- Figma → HTML 변환 추가 (`figma_to_html_agent/`)
+- Phase Z 어댑터 연결 (단계 1 의 작업과 같은 방식)
+- 컨트랙트 / partial / 빌더 추가
+- V4 카탈로그와 런타임 동기화
+
+---
+
+## 5. 운영 원칙
+
+### 5.1 절대 원칙
+
+- **MDX 원문 무손실 보존** — AI 가 일반 경로에서 MDX 원문을 *재작성 / 삭제 / 요약하지 않음*. 원문은 본문 미리보기 또는 자세히보기 / 팝업 어딘가에 *반드시* 보존.
+- **자유 디자인 금지** — Figma 프레임 DB / 카탈로그 / 컨트랙트 기반으로만 디자인 결정. AI 가 프레임 / 레이아웃 / 새 디자인 패턴을 *생성하지 않음*.
+- **그릇 변경 원칙** — 콘텐츠가 안 맞을 때 *콘텐츠를 줄이지 않음*. 대신 *그릇* (레이아웃 / zone / Region / 프레임 / 표시 방식) 을 변경. 공통 CSS / padding / tolerance 임의 축소 *금지*.
+- **dropped 절대 룰** — `text_block / table / image / details` 콘텐츠는 *절대 삭제하지 않음*. 장식 요소 (decorative_element) 만 공간 부족 시 dropped 가능.
+
+### 5.2 V4 ↔ Phase Z 책임 분담
+
+| 시스템 | 역할 |
+|---|---|
+| **V4** | 프레임 *선택* — 점수 + 라벨 (그대로 사용 / 가벼운 편집 / 재구성 / 거절) |
+| **Step 5** | V4 후보를 거절 제외 최대 6 개로 정리 |
+| **Step 6** | 구성 단위 결정 (어느 섹션 묶음 = 1 zone) — 현재는 V4 1 위를 그대로 채택 |
+| **Step 9** | V4 후보를 *어떻게 적용할지* 번역 (V4 점수를 다시 계산하지 않음) |
+
+V4 라벨 → 적용 방식 변환:
+- `그대로 사용` → 바로 삽입
+- `가벼운 편집` → 같은 프레임에 약간 조정
+- `재구성` → 레이아웃 / Region 변경 (자동으로는 적용 안 함, 사람 확인)
+- `거절` → 제외
+
+### 5.3 렌더 정책
+
+- 현재 렌더는 V4 의 1 위 후보 사용
+- 2~6 위는 보존만 — 향후 프론트엔드에서 사용자가 선택할 수 있게
+- `final.html` 을 직접 수정하지 않음 — 프론트엔드에서 변경 시 `user_overrides.json` 으로 누적 (원문 보존 원칙과 정합)
 
 ---
 
 ## 참고 문서
 
-| 문서 | 내용 |
-|------|------|
-| [IMPROVEMENT-REDESIGN.md](IMPROVEMENT-REDESIGN.md) | **Phase Z 통합 설계** (위계 / 용어 / 5 단계 흐름) |
-| [docs/architecture/FRAME-INTEGRATION-MAP.md](docs/architecture/FRAME-INTEGRATION-MAP.md) | **32 frame Zone 적용 분류** (`zone_direct/adapt/extract/reference_only`) |
-| [docs/architecture/PHASE-Z-FRAME-STYLE-INVENTORY.md](docs/architecture/PHASE-Z-FRAME-STYLE-INVENTORY.md) | **Frame / Style / Token 인벤토리** (32 frame + 18 token + 6 legacy) |
-| [PROCESS_OVERVIEW.html](PROCESS_OVERVIEW.html) | 임원 보고용 A4 2 페이지 (프로세스 + 구조도) |
-| [tests/PIPELINE.md](tests/PIPELINE.md) | 매칭 시스템 (V1~V4) 통합 정리 |
-| [PROGRESS.md](PROGRESS.md) | 전체 Phase 이력 (Phase 1~T + R' + Z) |
-| [CLAUDE.md](CLAUDE.md) | 프로젝트 규칙 + Phase Z 위계 |
-| [IMPROVEMENT-PLAN.md](docs/architecture/IMPROVEMENT-PLAN.md) | 개선 설계 (이전 Phase Q 까지) |
-| [TOKENS-v1.md](docs/architecture/TOKENS-v1.md) | 토큰 위계 기준표 |
-| [BLOCK-RULES.md](docs/architecture/BLOCK-RULES.md) | 블록 작성 규칙 |
+| 문서 | 역할 |
+|---|---|
+| [`CLAUDE.md`](CLAUDE.md) | 프로젝트 규칙 + Phase Z 위계 |
+| [`PHASE-Z-PIPELINE-OVERVIEW.md`](docs/architecture/PHASE-Z-PIPELINE-OVERVIEW.md) | 22 단계 도면 (구조 잠금) |
+| [`PHASE-Z-PIPELINE-STATUS-BOARD.md`](docs/architecture/PHASE-Z-PIPELINE-STATUS-BOARD.md) | 현재 진행 상태 (✅ / ⚠ / ❌) |
+| [`PHASE-Z-CHANGE-LOG.md`](docs/architecture/PHASE-Z-CHANGE-LOG.md) | 결정 변경 이력 |
+| [`PHASE-Z-CONTENT-OBJECT-SUBZONE-SPEC.md`](docs/architecture/PHASE-Z-CONTENT-OBJECT-SUBZONE-SPEC.md) | 콘텐츠 객체 + Internal Region + Frame Slot 명세 |
+| [`PHASE-Z-FIT-CLASSIFIER-ROUTER-SPEC.md`](docs/architecture/PHASE-Z-FIT-CLASSIFIER-ROUTER-SPEC.md) | Step 14~19 점검 / 라우팅 명세 |
+| [`IMPROVEMENT-REDESIGN.md`](IMPROVEMENT-REDESIGN.md) | Phase Z 통합 설계 |
+| [`PROCESS_OVERVIEW.html`](PROCESS_OVERVIEW.html) | 임원 보고용 A4 2 페이지 (프로세스 + 구조도) |
+| [`PROGRESS.md`](PROGRESS.md) | 전체 Phase 이력 (Phase 1~T + R' + Z) |