C.E.L._slide_test/docs/codex.md

# codex.md

## 목적
이 문서는 `C.E.L._slide_test` 저장소 하나만으로 입력, 절차, 실행, 결과를 닫힌 구조로 운영하기 위한 방향과 실행 계획을 정리한 기준 문서다.

핵심 목표는 다음과 같다.

- `design_agent`의 현재 프로세스를 위키와 이슈 체계로 정리한다.
- 초기 해석 단계는 이슈와 문서 기반으로 수행하고, 후반부 계산과 생성과 검증은 기존 코드 자산을 활용한다.
- run마다 입력 원문, 중간 산출물, 실행 결과, 검증 결과를 모두 저장소 안에 남긴다.
- 최종적으로 `C.E.L._slide_test` 저장소 하나만 보면 전체 루프를 이해하고 재실행할 수 있게 만든다.

## 현재 인식
현재 `design_agent`는 다음과 같은 구조를 가진다.

- 일부 초기 판단 단계에서 외부 해석 로직에 의존한다.
- 이후 단계에서는 공간 계산, HTML 생성, 검증, 렌더링, 측정, 품질 게이트를 코드로 수행한다.
- 즉, 전체 시스템이 하나의 외부 서비스에만 의존하는 것은 아니고, 초반의 해석/구조화 단계가 특히 분리 필요하다.

문제가 되는 핵심 초기 단계는 다음과 같다.

- topic extraction
- concept refinement
- relation_type 정리
- expression_hint 정리
- source_data 보강

이 부분은 앞으로 위키와 이슈를 기반으로 Codex 또는 Claude Code가 수행하고, 그 결과를 run 산출물로 저장해야 한다.

## 기본 방향
앞으로의 구조는 아래처럼 정리한다.

기존 구조:
- `design_agent code -> 외부 해석 -> 결과 수신 -> 후속 코드 실행`

목표 구조:
- `위키 1/2/3 -> 이슈에서 현재 작업 정리 -> Codex/Claude가 초기 해석 수행 -> 구조화 산출물 생성 -> design_agent 코드가 후반부 실행`

즉, 초기 사고 단계는 위키+이슈+에이전트가 맡고, 계산과 생성과 검증은 코드가 맡는 구조로 바꾼다.

## 역할 분리
### 위키
위키는 다음을 정의한다.

- 무엇을 해야 하는가
- 어떤 순서로 해야 하는가
- 어떤 기준으로 판단하는가
- 각 단계의 입력, 출력, 검증 조건은 무엇인가

즉, 위키는 실행 기준서다.

### 이슈
이슈는 다음을 기록한다.

- 이번 작업의 실제 입력
- 해석 결과
- 구조화 결과
- 단계별 진행 기록
- 검증 결과
- 남은 문제와 다음 액션

즉, 이슈는 실행 기록이자 작업 메모리다.

### 코드
코드는 다음을 수행한다.

- 공간 계산
- 디자인 budget 계산
- HTML 생성
- 콘텐츠 검증
- 렌더링
- 높이 측정
- 품질 게이트

즉, 코드는 실행기다.

## 저장소 운영 원칙
현재 `C.E.L._slide_test`에는 다음 구조를 유지한다.

- `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/`: 검증 결과

즉, 입력 원문부터 최종 결과까지 전부 저장소 안에 둔다.