diff --git a/README.md b/README.md index 7566b26..4ba1444 100644 --- a/README.md +++ b/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` diff --git a/docs/codex.md b/docs/codex.md index f62ad98..82d2764 100644 --- a/docs/codex.md +++ b/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이 된다. +즉, 입력 원문부터 최종 결과까지 전부 저장소 안에 둔다. diff --git a/docs/run-001/01-input/01. 건설산업 DX의 올바른 이해(0127).mdx b/docs/run-001/01-input/01. 건설산업 DX의 올바른 이해(0127).mdx new file mode 100644 index 0000000..949d7e6 --- /dev/null +++ b/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 기술 도입 수준으로 한정하는 인식 확산 +
+ 혼용 대표 사례 + +
+ * **[스마트 건설 활성화 방안(2022.07)]** + * 추진과제 : 건설산업 디지털화 + * 실행과제 : BIM 전면 도입, BIM 전문인력 양성 + * **[제7차 건설기술진흥 기본계획(2023.12)]** + * 추진방향 : 디지털 전환을 통한 스마트 건설 확산 + * 추진과제 : BIM 도입으로 건설산업 디지털화 +
+
+ + + * 건설산업의 DX를 올바르게 이해하기 위해 각 용어의 정의, 역할, 상호관계에 대한 체계적 정립 필요 + +
+--- + + +## 1. 용어 정의 + +
+ +* **건설산업** + * 다양한 시설물을 각 산업마다의 광범위한 기술을 통합 및 융합하여 만들어내는 종합산업 + * 목적 시설물의 품질 욕구를 충족시키면서 최단기간내에 최소 비용으로 편리하고 안전하며 우수한 성능의 시설물 완성을 목표로 함 + +
+ +* **BIM(Building Information Modeling) : 디지털 전환을 위한 핵심 기술** + * 시설물의 생애주기동안 발생한 모든 정보를 3차원 모델 기반으로 통합·관리하는 정보 관리 도구 + * 건설 정보와 절차를 표준화된 방식으로 연계하고 디지털 협업이 가능하도록 하는 핵심 인프라 기술 +
+ *건설산업 BIM 기본지침, 국토교통부, 2020* +
+ +
+ +* **DX(Digital Transformation) : 산업 패러다임의 변화** + * 디지털 기술을 기반으로 산업 전반의 업무방식과 가치 창출 구조를 전환하는 과정 및 결과 + * 단순한 기술 도입이 아닌, 고객 가치와 의사결정 방식의 근본적인 변화로 산업의 새로운 방향을 정립하는 것을 의미함 +
+ *Digital Transformation, IBM Institute for Business Value, 2011 / What is Digital Transformation?, Agile Elephant, 2015* +
+ + +--- +
+ +## 2. 용어간 상호관계 + +* DX는 BIM과 같은 디지털기술을 기반으로 산업 전반의 프로세스를 혁신하는 상위개념 +* 건설산업의 DX는 GIS(공간정보), BIM, 디지털 트윈(가상환경)의 기술융합을 통해서만 실현 또는 구현 가능 + * GIS의 역할 : 지리적 데이터를 공간 분석하여 시각적으로 표현, 위치기반 정보 제공 + * BIM의 역할 : 형상정보와 내용정보가 포함된 3D모델로, 건설 정보 기반의 Process와 Product를 제공 +![DX와 핵심기술간 상호관계](/assets/images/DX1.png) +
+ *[그림 1] DX와 핵심기술간 상호관계* +
+ +
+
+ + + +
+ DX와 BIM의 구분 + +
+ | DX | 구분 | BIM | + | :--- | :---: | ---: | + | **BIM << DX**
(Engineering + Management 통합) | **범위** | **Only 3D**
(형상 구현 중심) | + | **제작 및 운영**(상용 + 전용 40~80개)
[Rhino, Sketchup, Blender..] + [EG-BIM 등] | **S/W** | **모델 제작용 상용 SW**
[Revit, Civil 3D, Navisworks, Autocad] | + | **근본적 문제의식을 통한 개선** | **프로세스** | **기존 2D 설계 방식 유지** | + | **공학 정보 및 콘텐츠 연계에 집중**
**도면, 수량, 시공계획 등 일식** | **성과품** | **3D 모델 중심**
**기존 성과품 유지** | + | **설계/시공 생산성 혁신**(개념의 재정립) | **활용** | **3D 모델에 의한 일반적 이해 향상** | + | **전 생애주기 활용 시스템** | **확장성** | **(설계/시공/운영) 분야별 단절** | + | **구체화(복잡) - 적극적/구체적 실현 방안** | **수행 개념** | **단순화(오류) - 수동적/집단적 동질화** | + | **적극적, 주체적인 기술 접목/융합** | **CIVIL + IT** | **소극적, 상용 기술에 의존** | + | **자체 수행 능력 - 지속가능성 확보** | **주체** | **S/W 제작사 판매 정책에 의존** | + | **차별화 및 경쟁력 확보, 해외 진출** | **발주처** | **평준화, 국내 중심** | + | **IT + CIVIL ENG 220명 운영 + 기술 개발** | **설계사** | **소규모 BIM팀 운영 + 단순교육에 집중** | + | **분야 확장 모델 및 시스템** | **시공사** | **국내 토목 소극적/해외 토목증가** | +
+
+ +
+ +--- + +:::note[핵심 요약] +* BIM은 건설산업의 디지털전환(DX)을 수행하는 과정에서 **가장 기초가 되는 일부분**이다 +::: + diff --git a/docs/run-001/01-input/input-review.md b/docs/run-001/01-input/input-review.md index a5b7471..b0831d7 100644 --- a/docs/run-001/01-input/input-review.md +++ b/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의 위치를 설명하는 콘텐츠 diff --git a/docs/run-001/04-plan/artifact-bridge-notes.md b/docs/run-001/04-plan/artifact-bridge-notes.md index 01e88cd..0672590 100644 --- a/docs/run-001/04-plan/artifact-bridge-notes.md +++ b/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 경로다. diff --git a/docs/stage-1/STAGE-1-Overview.md b/docs/stage-1/STAGE-1-Overview.md index cf788e6..d43d8be 100644 --- a/docs/stage-1/STAGE-1-Overview.md +++ b/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를 안 쓰는 방식으로 개선하기`로 넘어갈 수 있다.