01 ▸ 워크플로우 위치
사용자 요청 (모호)
│
▼
Clarification
│
▼
┌─────────────────────────────┐
│ plan-crafting (ACTIVE) │
│ 계획 작성 + 코드 포함 │
└──────────────┬──────────────┘
│
▼
run-plan
│
▼
review-work
02 ▸ 언제 사용하나요?
Clarification이 단순(Simple, 5-8점) 판정으로 완료된 직후. 또는 이미 범위가 명료할 때 직접 호출합니다.
주요 트리거
계획 세워줘, 플랜 만들어줘 커맨드 입력 시- Context Brief 파일이 준비되었을 때
- 명확한 목표 + 범위가 있고 단계별 계획이 필요할 때
입출력
입력: Context Brief 파일 (clarification 출력)
출력: 실행 가능한 계획 문서 (파일 매핑 + 작업 분해)
03 ▸ 어떻게 동작하나요?
핵심 원리: 계획은 실행 문서입니다. 코드가 없는 단계는 계획 결함입니다.
실행 단계
- 검증 인프라 탐색: e2e, 통합, 테스트 스위트, 빌드 — 가장 높은 수준 검증을 찾아 Final Verification Task를 결정합니다.
- 파일 구조 매핑: 함께 변경되는 파일은 같은 작업, 다른 책임은 분리.
- 작업 분해 — Worker-Validator 구조: 같은 파일 수정은 직렬, 독립 작업은 병렬.
- 모든 단계에 실제 코드: TBD, TODO, "적절한 에러 처리 추가" — 모두 금지.
- Self-Review: 사양 커버리지, 타입 일관성, 의존성 검증, 검증 커버리지 자체 점검.
04 ▸ 플레이스홀더 금지 목록
TBD, TODO, implement later — 계획 결함- "적절한 에러 처리 추가" — 구체적 코드 없으면 결함
- "Task N과 유사" — 실제 코드를 반복해야 함
05 ▸ 하드 게이트
- 모든 단계는 실행 가능해야 함: 플레이스홀더는 절대 허용되지 않습니다.
- 작업 충돌 방지: 동일한 파일을 수정하는 작업은 병렬로 실행될 수 없습니다.
- Self-Review 필수: 계획 작성 후 스스로 완결성을 검증해야 합니다.
- 최소 기능 단위 분해: 하나의 작업은 하나의 명확한 결과물을 생성합니다.