Consolidate run-001 inputs and docs into repository

README.md

@@ -3,12 +3,25 @@
 이 저장소는 슬라이드 생성 작업을 단계별로 해석, 계획, 실행, 검증하고 그 결과를 반복적으로 개선하기 위한 작업 공간이다.
 
 ## 구성
-- `docs/`: 방향성 문서, Stage 1 문서, run 기록, 실행 결과
+- `docs/`: 방향성 문서, Stage 1 문서, run 기록, 입력 원문, 실행 결과
 - `scripts/`: 후반부 실행과 실험을 위한 스크립트
 - `issues/`: Gitea 이슈 탭에 등록할 step별 이슈 본문 초안
 
 ## 현재 포함된 항목
 - 단계별 운영 문서
-- run-001 해석/구조화/계획/검증 기록
+- run-001 입력 원문, 해석/구조화/계획/검증 기록
 - 실행 결과와 측정 결과
 - 반복 실행을 위한 템플릿
+
+## 운영 원칙
+- 원본 입력 파일은 각 run의 `01-input/` 폴더 안에 함께 둔다.
+- 위키는 기준과 절차를 관리한다.
+- 이슈는 step별 실행 지시와 실행 결과 코멘트를 관리한다.
+- `docs/run-xxx/`는 실제 산출물과 중간 결과를 저장한다.
+
+## 현재 run 예시
+- 입력 원문: `docs/run-001/01-input/01. 건설산업 DX의 올바른 이해(0127).mdx`
+- 입력 검토: `docs/run-001/01-input/input-review.md`
+- 실행 계획: `docs/run-001/04-plan/execution-plan.md`
+- 최종 결과: `docs/run-001/05-execution/final.html`
+- 검증 결과: `docs/run-001/06-validation/validation-result.md`

docs/codex.md

@@ -1,23 +1,23 @@
 # codex.md
 
 ## 목적
-이 문서는 `design_agent`를 현재 구현 상태에서 바로 뜯어고치는 대신, 먼저 작업 절차와 판단 기준을 `design_agnet_codex`의 위키/이슈 체계로 외부화한 뒤, 이를 기반으로 `Kei API` 의존을 제거하는 방향과 실행 계획을 정리한 기준 문서다.
+이 문서는 `C.E.L._slide_test` 저장소 하나만으로 입력, 절차, 실행, 결과를 닫힌 구조로 운영하기 위한 방향과 실행 계획을 정리한 기준 문서다.
 
 핵심 목표는 다음과 같다.
 
 - `design_agent`의 현재 프로세스를 위키와 이슈 체계로 정리한다.
-- `Kei API`가 담당하던 사고 단계를 문서 기반/에이전트 기반 단계로 치환한다.
-- 후반부의 계산, 생성, 검증, 렌더링은 기존 코드 자산을 최대한 활용한다.
-- 최종적으로 `Kei API` 없이도 `design_agent`가 운영 가능하도록 구조를 옮긴다.
+- 초기 해석 단계는 이슈와 문서 기반으로 수행하고, 후반부 계산과 생성과 검증은 기존 코드 자산을 활용한다.
+- run마다 입력 원문, 중간 산출물, 실행 결과, 검증 결과를 모두 저장소 안에 남긴다.
+- 최종적으로 `C.E.L._slide_test` 저장소 하나만 보면 전체 루프를 이해하고 재실행할 수 있게 만든다.
 
 ## 현재 인식
 현재 `design_agent`는 다음과 같은 구조를 가진다.
 
-- 일부 초기 판단 단계에서 `Kei API`를 호출한다.
+- 일부 초기 판단 단계에서 외부 해석 로직에 의존한다.
 - 이후 단계에서는 공간 계산, HTML 생성, 검증, 렌더링, 측정, 품질 게이트를 코드로 수행한다.
-- 즉, 전체 시스템이 전부 `Kei API`에 의존하는 것은 아니고, 초반의 해석/구조화 단계가 특히 의존적이다.
+- 즉, 전체 시스템이 하나의 외부 서비스에만 의존하는 것은 아니고, 초반의 해석/구조화 단계가 특히 분리 필요하다.
 
-문제가 되는 핵심 의존 구간은 다음과 같다.
+문제가 되는 핵심 초기 단계는 다음과 같다.
 
 - topic extraction
 - concept refinement
@@ -25,18 +25,18 @@
 - expression_hint 정리
 - source_data 보강
 
-이 부분은 현재 `Kei API`가 맡고 있지만, 앞으로는 위키와 이슈를 기반으로 Codex 또는 Claude Code가 수행하도록 전환해야 한다.
+이 부분은 앞으로 위키와 이슈를 기반으로 Codex 또는 Claude Code가 수행하고, 그 결과를 run 산출물로 저장해야 한다.
 
 ## 기본 방향
-앞으로의 구조는 아래처럼 바뀌어야 한다.
+앞으로의 구조는 아래처럼 정리한다.
 
 기존 구조:
-- `design_agent code -> kei_client.py -> Kei API -> 결과 수신 -> 후속 코드 실행`
+- `design_agent code -> 외부 해석 -> 결과 수신 -> 후속 코드 실행`
 
 목표 구조:
 - `위키 1/2/3 -> 이슈에서 현재 작업 정리 -> Codex/Claude가 초기 해석 수행 -> 구조화 산출물 생성 -> design_agent 코드가 후반부 실행`
 
-즉, `Kei API`가 하던 사고 단계는 위키+이슈+에이전트가 맡고, 계산과 생성과 검증은 코드가 맡는 구조로 바꾼다.
+즉, 초기 사고 단계는 위키+이슈+에이전트가 맡고, 계산과 생성과 검증은 코드가 맡는 구조로 바꾼다.
 
 ## 역할 분리
 ### 위키
@@ -53,7 +53,7 @@
 이슈는 다음을 기록한다.
 
 - 이번 작업의 실제 입력
-- Kei 기준 해석 결과
+- 해석 결과
 - 구조화 결과
 - 단계별 진행 기록
 - 검증 결과
@@ -74,188 +74,14 @@
 
 즉, 코드는 실행기다.
 
-## 위키 체계
-현재 `design_agnet_codex`에는 다음 구조를 두는 방향으로 정리한다.
+## 저장소 운영 원칙
+현재 `C.E.L._slide_test`에는 다음 구조를 유지한다.
 
-### 위키 1 계열
-Kei의 판단 기준
+- `docs/run-xxx/01-input/`: 입력 원문과 입력 검토 결과
+- `docs/run-xxx/02-kei-interpretation/`: 초기 해석 결과
+- `docs/run-xxx/03-structure/`: 구조화 결과
+- `docs/run-xxx/04-plan/`: 실행 계획과 수동 보강 산출물
+- `docs/run-xxx/05-execution/`: 실제 실행 결과
+- `docs/run-xxx/06-validation/`: 검증 결과
 
-- Kei 사고방식과 프로세스
-- Kei 역할과 운영 원칙
-
-### 위키 2 계열
-design_agent 상위 작업 절차
-
-- 입력 확인
-- Kei 기준 해석
-- 콘텐츠 구조화
-- 실행 계획 수립
-- 실제 수행
-- 검증 및 기록
-
-### 위키 3 계열
-design_agent 상세 파이프라인
-
-- Stage 0 입력 로드 및 MDX 정규화
-- Stage 1A topic extraction
-- Stage 1B concept refinement
-- Stage 1.5a 폰트 위계와 비율 계획
-- Stage 1.7 참조 블록 선정
-- Stage 1.5b 디자인 버짓 재계산
-- Stage 2 HTML 생성
-- Stage 2 검증 및 재시도
-- Stage 3 렌더와 측정
-- Stage 4 품질 게이트와 최종화
-
-## 가장 중요한 전환 원칙
-위키를 만든다고 자동으로 `Kei API`가 사라지는 것은 아니다.
-진짜 전환은 아래 조건이 충족될 때 일어난다.
-
-- Stage 1A와 Stage 1B를 `Kei API 호출 단계`가 아니라 `위키/이슈 기반 해석 단계`로 재정의한다.
-- Codex 또는 Claude Code가 위키를 읽고 topic/concept/expression_hint/source_data를 직접 정리한다.
-- 이 결과를 코드가 읽을 수 있는 중간 산출물로 남긴다.
-- 이후 후반부 파이프라인은 기존 코드가 그대로 또는 최소 수정으로 수행한다.
-
-즉, 핵심은 `Kei API 제거`가 아니라 `Kei 사고 단계를 외부화`하는 것이다.
-
-## 단계별 실행 계획
-### 1단계. 현재 design_agent 문서화
-목적:
-현재 `design_agent`가 어떤 순서로 동작하는지, 어떤 단계가 코드에 있고 어떤 단계가 `Kei API`에 의존하는지 문서로 고정한다.
-
-할 일:
-- 위키 2와 위키 3을 현재 구조 기준으로 정리한다.
-- 각 stage의 입력/출력/검증 기준을 문서화한다.
-- `Phase T` 기준 변경점도 함께 반영한다.
-
-### 2단계. 위키/이슈 기반 작업 체계 완성
-목적:
-Codex/Claude가 `Kei persona 프롬프트` 대신 위키와 이슈를 읽고 움직이도록 만든다.
-
-할 일:
-- 위키 1 계열 완성
-- 위키 2 계열 완성
-- 위키 3 계열 완성
-- 이슈 템플릿 작성
-
-이 단계가 끝나면 작업 방식은 다음과 같아야 한다.
-- 위키 2를 기준으로 현재 작업 step을 정한다.
-- 판단은 위키 1을 기준으로 한다.
-- 상세 실행은 위키 3을 따른다.
-- 중간 결과와 최종 결과는 이슈에 남긴다.
-
-### 3단계. Kei API 역할 외부화
-목적:
-초기 판단 단계가 더 이상 API 호출을 기본 전제로 하지 않게 만든다.
-
-할 일:
-- Stage 1A를 `위키 기반 topic extraction`으로 재정의한다.
-- Stage 1B를 `위키 기반 concept refinement`로 재정의한다.
-- relation_type, expression_hint, source_data를 사람이 읽고 검토 가능한 형태로 정리한다.
-- 이를 이슈 또는 별도 산출물 파일에 저장한다.
-
-### 4단계. 중간 산출물 포맷 정의
-목적:
-에이전트가 정리한 초기 해석 결과를 코드가 받아 쓸 수 있게 만든다.
-
-예상 산출물 예시:
-- `topics.json`
-- `refined_concepts.json`
-- `design_context.json`
-- 또는 단계별 markdown 기록
-
-이 단계에서 중요한 것은 파일 형식보다도 아래 항목이 안정적으로 남는 것이다.
-- 핵심 topic
-- refined concept
-- relation 정보
-- expression hint
-- source data
-- 검증 기준
-
-### 5단계. 코드 경로 전환
-목적:
-`design_agent`가 기본적으로 `Kei API`를 호출하지 않도록 흐름을 바꾼다.
-
-할 일:
-- `kei_client` 호출을 기본 경로에서 제거하거나 optional fallback으로 내린다.
-- Stage 1A/1B 입력을 API 응답이 아니라 중간 산출물로 바꾼다.
-- 후반부 파이프라인은 최대한 기존 코드 자산을 유지한다.
-
-원칙:
-- 계산, 생성, 검증 로직은 함부로 다시 쓰지 않는다.
-- 먼저 입력 경로만 바꾼다.
-- 코드 변경은 작고 명확하게 진행한다.
-
-### 6단계. 운영 방식 정착
-목적:
-실제 작업이 `위키 -> 이슈 -> 코드 실행` 흐름으로 안정적으로 반복되게 만든다.
-
-운영 흐름:
-1. 작업 이슈 생성
-2. 위키 2의 현재 step 확인
-3. 위키 1 기준으로 해석
-4. 위키 3 기준으로 상세 실행 계획 수립
-5. 초기 해석 결과 작성
-6. 코드 실행
-7. 검증 결과 기록
-8. 필요한 단계만 재시도
-
-## Phase T 반영 원칙
-현재는 `Phase T` 진행 중이므로, 위키 2와 위키 3은 단순히 기존 구현 복제가 아니라 `Phase T 목표 구조`를 반영해야 한다.
-
-특히 반드시 반영해야 할 항목은 다음과 같다.
-
-- Stage 0 MDX normalization
-- Stage 1A / 1B 분리
-- Stage 1.5a / 1.7 / 1.5b 분리
-- font hierarchy first
-- PipelineContext 기반 사고
-- 단계별 validation
-- partial retry
-- quality gate
-
-즉, 위키는 현재 코드 설명서이면서 동시에 `Phase T 전환 가이드`여야 한다.
-
-## 코드와 문서의 관계
-문서는 코드를 대체하지 않는다.
-문서는 코드가 어떤 역할을 해야 하는지 지시한다.
-
-예시:
-- 위키: `MDX 정규화의 목적, 입력, 출력, 검증 기준 정의`
-- 코드: 실제 정규화 수행
-
-- 위키: `topic extraction에서 무엇을 뽑아야 하는지 정의`
-- 에이전트 또는 코드: 실제 추출 수행
-
-- 위키: `HTML 생성의 원칙과 실패 기준 정의`
-- 코드: 실제 HTML 생성 수행
-
-즉:
-- 위키는 기준
-- 이슈는 기록
-- 코드는 실행
-
-## 당장 해야 할 일
-우선순위는 다음과 같다.
-
-1. `design_agnet_codex`의 위키 문서명을 Gitea 형식에 맞게 정리한다.
-2. 위키 3의 Stage 1A/1B 내용을 `Kei API 호출형`이 아니라 `위키/이슈 기반 해석형`으로 수정한다.
-3. `이슈 템플릿` 문서를 만든다.
-4. `Kei API`가 하던 초기 판단 산출물 포맷을 정의한다.
-5. 그 다음에야 실제 코드 경로를 전환한다.
-
-## 기준 문장
-앞으로 Codex 또는 Claude Code에게는 아래와 같은 운영 문장을 사용한다.
-
-`현재 작업은 위키 2의 상위 작업 절차를 기준으로 진행한다. 판단 기준이 필요하면 위키 1 계열을 참조한다. 상세 실행과 검증은 위키 3 계열을 따른다. 초기 해석 결과와 중간 결과와 최종 결과는 이슈에 기록한다. 가능하면 Kei API를 호출하지 않고 위키와 이슈를 기반으로 Stage 1A와 Stage 1B를 수행한다.`
-
-## 결론
-이번 작업의 핵심은 단순히 `Kei API를 끄는 것`이 아니다.
-진짜 목표는 `Kei의 사고 단계를 API 안에 가두지 않고, 위키와 이슈와 에이전트 실행 흐름으로 꺼내는 것`이다.
-
-이 전환이 완료되면 `design_agent`는 다음과 같은 구조를 갖게 된다.
-
-- 사고 기준은 위키에 있고
-- 작업 기억은 이슈에 있고
-- 계산과 생성은 코드가 수행하며
-- `Kei API`는 필수가 아니라 선택적 fallback이 된다.
+즉, 입력 원문부터 최종 결과까지 전부 저장소 안에 둔다.

docs/run-001/01-input/01. 건설산업 DX의 올바른 이해(0127).mdx

@@ -0,0 +1,120 @@
+---
+title: 건설산업 DX의 올바른 이해
+sidebar:
+  order: 00
+---
+
+* **용어의 혼용**
+
+  * 건설산업의 디지털 전환 논의에서 DX(Digital Transformation)와 BIM(Building Information Modeling)이 개념적으로 명확히 정립되지 않은채 혼용되어 사용되고 있음  
+  * 이로인해 BIM기술의 도입을 DX의 완성으로 오인하거나, DX를 BIM 기술 도입 수준으로 한정하는 인식 확산    
+  <details>
+    <summary style={{cursor: 'pointer', fontWeight: 'bold', color: '#555'}}>혼용 대표 사례</summary>
+      
+    <div style={{marginTop: '10px', paddingLeft: '15px', borderLeft: '3px solid #ddd', fontSize: '0.9rem', color: '#666'}}>
+    * **[스마트 건설 활성화 방안(2022.07)]**
+      * 추진과제 : 건설산업 디지털화   
+      * 실행과제 : BIM 전면 도입, BIM 전문인력 양성
+    * **[제7차 건설기술진흥 기본계획(2023.12)]**
+      * 추진방향 : 디지털 전환을 통한 스마트 건설 확산  
+      * 추진과제 : BIM 도입으로 건설산업 디지털화
+    </div>
+  </details>
+
+
+  * 건설산업의 DX를 올바르게 이해하기 위해 각 용어의 정의, 역할, 상호관계에 대한 체계적 정립 필요
+
+<br/>
+---
+
+
+## 1. 용어 정의
+
+<br/>
+
+* **건설산업**
+  * 다양한 시설물을 각 산업마다의 광범위한 기술을 통합 및 융합하여 만들어내는 종합산업
+  * 목적 시설물의 품질 욕구를 충족시키면서 최단기간내에 최소 비용으로 편리하고 안전하며 우수한 성능의 시설물 완성을 목표로 함
+
+<br/>
+
+* **BIM(Building Information Modeling) : 디지털 전환을 위한 핵심 기술**
+  * 시설물의 생애주기동안 발생한 모든 정보를 3차원 모델 기반으로 통합·관리하는 정보 관리 도구
+  * 건설 정보와 절차를 표준화된 방식으로 연계하고 디지털 협업이 가능하도록 하는 핵심 인프라 기술
+      <div style={{ 
+    fontSize: '0.8rem', 
+    color: '#999', 
+    marginTop: '5px', 
+    lineHeight: '1.4',
+    paddingLeft: '0px' }}>
+    *건설산업 BIM 기본지침, 국토교통부, 2020*
+    </div>
+
+<br/>
+
+* **DX(Digital Transformation) : 산업 패러다임의 변화**
+  * 디지털 기술을 기반으로 산업 전반의 업무방식과 가치 창출 구조를 전환하는 과정 및 결과   
+  * 단순한 기술 도입이 아닌, 고객 가치와 의사결정 방식의 근본적인 변화로 산업의 새로운 방향을 정립하는 것을 의미함
+  <div style={{ 
+    fontSize: '0.8rem', 
+    color: '#999', 
+    marginTop: '5px', 
+    lineHeight: '1.4',
+    paddingLeft: '0px' }}>
+    *Digital Transformation, IBM Institute for Business Value, 2011 / What is Digital Transformation?, Agile Elephant, 2015*
+    </div>
+
+
+---
+<br/>
+
+## 2. 용어간 상호관계
+
+* DX는 BIM과 같은 디지털기술을 기반으로 산업 전반의 프로세스를 혁신하는 상위개념
+* 건설산업의 DX는 GIS(공간정보), BIM, 디지털 트윈(가상환경)의 기술융합을 통해서만 실현 또는 구현 가능  
+  * GIS의 역할 : 지리적 데이터를 공간 분석하여 시각적으로 표현, 위치기반 정보 제공
+  * BIM의 역할 : 형상정보와 내용정보가 포함된 3D모델로, 건설 정보 기반의 Process와 Product를 제공  
+![DX와 핵심기술간 상호관계](/assets/images/DX1.png)
+    <div style={{ 
+      fontSize: '0.8rem', 
+      color: '#999', 
+      marginTop: '5px', 
+      lineHeight: '1.4',
+      paddingLeft: '0px' }}>
+      *[그림 1] DX와 핵심기술간 상호관계*
+      </div>
+
+<br/>
+<br/>
+
+
+
+  <details>
+    <summary style={{cursor: 'pointer', fontWeight: 'bold', color: '#555'}}>DX와 BIM의 구분</summary>
+      
+    <div style={{marginTop: '10px', paddingLeft: '15px', borderLeft: '3px solid #ddd', fontSize: '0.9rem', color: '#666'}}>
+    | DX | 구분 | BIM |
+    | :--- | :---: | ---: |
+    | **BIM &lt;&lt; DX**<br/>(Engineering + Management 통합) | **범위** | **Only 3D**<br/>(형상 구현 중심) |
+    | **제작 및 운영**(상용 + 전용 40~80개)<br/>[Rhino, Sketchup, Blender..] + [EG-BIM 등] | **S/W** | **모델 제작용 상용 SW**<br/>[Revit, Civil 3D, Navisworks, Autocad] |
+    | **근본적 문제의식을 통한 개선** | **프로세스** | **기존 2D 설계 방식 유지** |
+    | **공학 정보 및 콘텐츠 연계에 집중**<br/>**도면, 수량, 시공계획 등 일식** | **성과품** | **3D 모델 중심**<br/>**기존 성과품 유지** |
+    | **설계/시공 생산성 혁신**(개념의 재정립) | **활용** | **3D 모델에 의한 일반적 이해 향상** |
+    | **전 생애주기 활용 시스템** | **확장성** | **(설계/시공/운영) 분야별 단절** |
+    | **구체화(복잡) - 적극적/구체적 실현 방안** | **수행 개념** | **단순화(오류) - 수동적/집단적 동질화** |
+    | **적극적, 주체적인 기술 접목/융합** | **CIVIL + IT** | **소극적, 상용 기술에 의존** |
+    | **자체 수행 능력 - 지속가능성 확보** | **주체** | **S/W 제작사 판매 정책에 의존** |
+    | **차별화 및 경쟁력 확보, 해외 진출** | **발주처** | **평준화, 국내 중심** |
+    | **IT + CIVIL ENG 220명 운영 + 기술 개발** | **설계사** | **소규모 BIM팀 운영 + 단순교육에 집중** |
+    | **분야 확장 모델 및 시스템** | **시공사** | **국내 토목 소극적/해외 토목증가** |
+    </div>
+  </details>
+
+<br/>
+
+---
+
+:::note[핵심 요약]
+* BIM은 건설산업의 디지털전환(DX)을 수행하는 과정에서 **가장 기초가 되는 일부분**이다
+:::
+

docs/run-001/01-input/input-review.md

@@ -2,7 +2,7 @@
 
 ## Source
 - input file: `01. 건설산업 DX의 올바른 이해(0127).mdx`
-- source path: `D:\ad-hoc\kei\design_agnet_codex\runs\run-001\01-input\01. 건설산업 DX의 올바른 이해(0127).mdx`
+- source path: `docs/run-001/01-input/01. 건설산업 DX의 올바른 이해(0127).mdx`
 
 ## Request Understanding
 - 주제: 건설산업에서 DX와 BIM의 개념적 혼용 문제를 바로잡고, DX의 올바른 의미와 BIM의 위치를 설명하는 콘텐츠

docs/run-001/04-plan/artifact-bridge-notes.md

@@ -1,7 +1,7 @@
 # Artifact Bridge Notes
 
 ## 목적
-이 파일들은 `Kei API` 없이도 기존 `design_agent`의 후반부 코드를 사용할 수 있도록 만든 입력 산출물이다.
+이 파일들은 외부 초기 해석 없이도 기존 `design_agent`의 후반부 코드를 사용할 수 있도록 만든 입력 산출물이다.
 
 ## 파일
 - `stage-1a-topics.json`: Stage 1A 수동 대체 결과
@@ -12,13 +12,13 @@
 ```powershell
 cd D:\ad-hoc\kei\design_agent
 python scripts\run_from_artifacts.py `
-  --input "D:\ad-hoc\kei\design_agnet_codex\runs\run-001\01-input\01. 건설산업 DX의 올바른 이해(0127).mdx" `
-  --stage1a "D:\ad-hoc\kei\design_agnet_codex\runs\run-001\04-plan\stage-1a-topics.json" `
-  --stage1b "D:\ad-hoc\kei\design_agnet_codex\runs\run-001\04-plan\stage-1b-refined-concepts.json" `
-  --output-dir "D:\ad-hoc\kei\design_agnet_codex\runs\run-001\05-execution"
+  --input "D:\ad-hoc\C.E.L._slide_test\docs\run-001\01-input\01. 건설산업 DX의 올바른 이해(0127).mdx" `
+  --stage1a "D:\ad-hoc\C.E.L._slide_test\docs\run-001\04-plan\stage-1a-topics.json" `
+  --stage1b "D:\ad-hoc\C.E.L._slide_test\docs\run-001\04-plan\stage-1b-refined-concepts.json" `
+  --output-dir "D:\ad-hoc\C.E.L._slide_test\docs\run-001\05-execution"
 ```
 
 ## 주의
-- 이 경로는 `Kei API`를 사용하지 않는다.
+- 입력 원문과 수동 보강 산출물은 모두 `C.E.L._slide_test` 저장소 안에 둔다.
 - 다만 Stage 2의 Claude/Anthropic 호출과 로컬 렌더링 환경은 필요하다.
-- 품질 게이트는 Kei vision 대신 `measurement + screenshot`만 수행하는 lite 경로다.
+- 품질 게이트는 vision 대신 `measurement + screenshot`만 수행하는 lite 경로다.

docs/stage-1/STAGE-1-Overview.md

@@ -2,25 +2,25 @@
 
 ## 목적
 이 문서는 1단계의 기준 문서다.
-1단계의 목표는 `design_agent`의 현재 구조를 충분히 이해하고, 그 이해를 `design_agnet_codex`의 위키 및 관련 문서로 정리하는 것이다.
+1단계의 목표는 `design_agent`의 현재 구조를 충분히 이해하고, 그 이해를 `C.E.L._slide_test`의 위키 및 관련 문서로 정리하는 것이다.
 
-이 단계에서는 아직 `Kei API`를 제거하지 않는다.
+이 단계에서는 아직 전체 구조를 뜯어고치지 않는다.
 먼저 현재 구조와 목표 구조를 명확히 분리해서 기록한다.
 
 ## 1단계의 핵심 질문
 1. 현재 `design_agent`는 실제로 어떤 순서로 동작하는가
 2. 어떤 단계가 코드로 구현되어 있는가
-3. 어떤 단계가 `Kei API`에 의존하는가
+3. 어떤 단계가 외부 해석에 의존하는가
 4. `Phase T`는 현재 구조에서 무엇을 바꾸려 하는가
 5. 위키 1/2/3 체계로 이 내용을 어떻게 옮길 것인가
 
 ## 현재 design_agent에 대한 이해
-현재 `design_agent`는 완전히 새로운 Phase T 구현체라기보다, Phase S 중심의 실행 경로 위에 일부 T 방향 수정이 얹혀 있는 상태로 이해하는 것이 정확하다.
+현재 `design_agent`는 완전히 새로운 Phase T 구현체라기보다, 기존 실행 경로 위에 일부 T 방향 수정이 얹혀 있는 상태로 이해하는 것이 정확하다.
 
 현재 흐름은 크게 다음과 같다.
 
 1. 입력 수신
-2. Kei 기반 초기 해석
+2. 초기 해석
 3. 공간/영역 제약 계산
 4. HTML 생성
 5. 콘텐츠 검증 및 부분 재시도
@@ -29,11 +29,11 @@
 8. 품질 게이트
 9. 결과 저장 및 응답
 
-즉, 전체 시스템의 후반부는 코드 기반으로 꽤 많이 구현되어 있고, 초반부의 의미 해석과 개념 정리가 `Kei API`에 의존하는 구조다.
+즉, 전체 시스템의 후반부는 코드 기반으로 꽤 많이 구현되어 있고, 초반부의 의미 해석과 개념 정리가 별도 해석 단계로 분리 가능한 구조다.
 
 ## 현재 구현과 위키 계층의 연결
 ### 위키 1
-- Kei가 어떻게 판단하는가
+- 어떻게 판단하는가
 - 어떤 의미를 보존해야 하는가
 - 무엇을 경계해야 하는가
 
@@ -65,8 +65,6 @@
 - partial retry
 - quality gate
 
-즉, 위키 3은 단순 구현 설명서가 아니라 `현재 구현 + Phase T 목표 구조`를 함께 보여주는 문서여야 한다.
-
 ## 1단계 산출물
 1단계에서 만들어야 할 핵심 산출물은 다음과 같다.
 
@@ -74,22 +72,13 @@
 - 위키 2 계열 정리
 - 위키 3 계열 정리
 - 현재 코드와 위키 단계 매핑 문서
-- Kei API 의존 지점 정리 문서
+- 외부 해석 의존 지점 정리 문서
 - Phase T 반영 포인트 정리 문서
 
 ## 완료 기준
 1단계는 아래 조건을 만족하면 완료로 본다.
 
 - `design_agent`의 전체 흐름을 위키 2와 위키 3으로 설명할 수 있다.
-- 어떤 단계가 코드 책임인지, 어떤 단계가 Kei 책임인지 구분되어 있다.
-- `Kei API` 제거 전환 시 무엇을 바꿔야 하는지 문서로 드러난다.
+- 어떤 단계가 코드 책임인지, 어떤 단계가 초기 해석 책임인지 구분되어 있다.
+- 초기 해석 단계를 분리 전환할 때 무엇을 바꿔야 하는지 문서로 드러난다.
 - `Phase T` 반영 포인트가 누락되지 않는다.
-
-## 1단계 이후로 넘어갈 수 있는 상태
-1단계가 끝나면 다음 질문에 답할 수 있어야 한다.
-
-- `Kei API`를 제거하려면 어느 단계부터 바꿔야 하는가
-- 어떤 중간 산출물이 필요할까
-- 어떤 코드는 유지하고 어떤 입력 경로만 바꾸면 되는가
-
-그 상태가 되면 2단계인 `Kei API를 안 쓰는 방식으로 개선하기`로 넘어갈 수 있다.