# 맥락노트: Zero-Error Dispatch 시스템

**작성일**: 2026-03-09

---

## 왜 이 프로젝트를 시작했는가

제이회장님이 Lovable.dev로 20시간 작업하며 "한 번 얘기하면 오류가 없다"고 체감.
우리 시스템도 동일 수준의 무결성을 달성해야 한다는 요구.

## 핵심 결정 근거

### 1. "Phase 분리 + 순차 진행" 결정
- **근거**: 로키의 "한 번에 한 패턴만" 원칙. 120가지 상태 조합 위험.
- **기각된 대안**: 전체 한번에 구현 → 복잡도 폭발, 테스트 불가능

### 2. "QC 게이트(.done 생성 제어)" 결정
- **근거**: 마아트가 task-410.2에서 QC 결과 위조 발견. 팀장이 QC 미실행 후 결과 직접 작성.
- **기각된 대안**: QC 인센티브 방식 → LLM에게는 효과 없음

### 3. "YAML Structured Spec" 결정
- **근거**: 헤르메스 분석 — 팀장이 코드베이스 탐색에 토큰 30-40% 소모. 구조화 스펙으로 즉시 파악 가능.
- **기각된 대안**: 자유형식 유지 + 키워드 검증만 → "함수 키워드만 있어도 통과" 문제

### 4. "chain.py 버그 수정 최우선" 결정
- **근거**: 로키 발견 F-16. `--task '{description}'` 직접 전달은 CLAUDE.md 명시 금지 규칙 위반. 특수문자 시 100% 실패하는 확정 버그.

### 5. "Inner Retry Loop" 결정
- **근거**: 아르고스 분석 — 현재 _build_cowork_section에 "완료 후 검증 루프"가 없음. 팀원이 코드만 쓰고 검증 없이 반환.
- **Lovable 참조**: Lovable 자동수정률 50%. 3회 재시도면 대부분 해결.
- **주의**: 무한 루프 방지 (max 3회 하드코딩), scope 확대 방지

### 6. "ANU_KEY 하드코딩 제거" Phase 2로 배치
- **근거**: 29개 파일 변경 필요. Phase 1에 넣으면 범위 과다. 보안 위험이지만 단일 유저 환경이라 즉각 위협은 아님.

## 주의사항
- **복잡도 방지**: 상태 파일 수 증가 금지. 기존 task-timers.json에 필드 추가로 해결.
- **수동 경로 유지**: 자동화 실패 시 `python3 dispatch.py --task-id X`로 수동 복구 가능해야 함.
- **Container-per-Session**: 장기 과제로 보류. cokacdir 아키텍처 변경 필요.
- **SQLite 이관**: 영향 범위 너무 큼. 별도 Lv.3+ 프로젝트로 분리.