계획과 작업 템플릿

Deep Work Plan은 Markdown 파일들의 디렉터리입니다. 그 디렉터리의 형태 — 그리고 그 안의 각 파일의 형태 — 가 계획을 사람과 에이전트 모두에게 검토 가능하게 만듭니다.

계획 구조

플랜 디렉터리

.dwp/
config.json 애드온 레지스트리 · 설정
plans/
PLAN_001_<slug>/
manifest.json 플랜 식별자 · 계약 포인터
contract.json 불변의 결과 계약
journal.ndjson 추가 전용 원장 이벤트
state.json journal 투영 스냅샷
README.md 목표 · 작업 표 · 상태
1.task_<slug>.md 작업 파일(열 개 섹션)
2.task_<slug>.md
analysis_results/ 작업 산출물 · 게이트 증거

v7 DWP 플랜은 기계 가독형 계약 및 원장(contract, journal, state)과 사람이 검토 가능한 Markdown 문서 및 작업 산출물을 결합합니다.

계획은 PLAN_001_<slug>/라는 이름으로 .dwp/plans/ 아래에 있는 디렉터리입니다. 다음을 담습니다.

manifest.json — 플랜의 식별자 및 활성 계약 포인터(구체화 시 가장 먼저 작성됨).
contract.json — 계획의 사양 계약 및 범위.
journal.ndjson — 추가 전용 이벤트 저널.
state.json — journal에서 투영된 스냅샷(직접 수동 편집 금지).
README.md — 계획 개요: 목표, 작업 표, 진행 상태.
PROGRESS.md — 사람이 읽을 수 있는 시간순 실행 로그.
<n>.task_<slug>.md — 각 작업의 열 개 절로 이루어진 사양 파일.
analysis_results/ — 분석 산출물, 보고서 및 게이트 로그 저장소.

현재 7.x 팩은 v7 계획을 기본으로 생성하며, 해당 슬러그는 v6와 동일하게 2~~5단어입니다. 보존된 v5 흐름은 2~~4단어를 사용합니다(고정된 스키마가 숫자 ID를 한 단어로 계산하기 때문). 새 계획에는 최소 세 자리 숫자로 된 단조 증가 ID를 부여합니다(예: PLAN_001_add_payment_webhooks/). 기존의 번호 없는 PLAN_<slug>/ 폴더는 계속 읽을 수 있으며 이름 변경을 진행하지 않습니다. 기존 계획이 암묵적으로 마이그레이션되는 일은 없습니다. 번호가 있는 계획이 존재할 경우 latest는 숫자 ID가 가장 큰 계획을 가리킵니다.

작업 파일 구조

각 작업 파일은 <n>.task_<slug>.md라는 이름이며 설치된 스킬에서 정의한 열 개의 규범적 섹션을 따릅니다(작업 구조에 대한 상세 내용은 핵심 루프를 참고하세요). 각 작업은 행동하기 전에 계획의 목표에 다시 닻을 내리며, 이는 에이전트가 긴 시간 동안 작업하면서 방향을 잃지 않게 합니다.

Final Review

모든 계획은 유일한 필수 작업으로 끝나야 합니다: Final Review입니다. 다섯 단계의 엄격한 순서로 계획을 매듭짓습니다 — 보안 감사와 검증 게이트의 어떤 기준도 완화되지 않습니다:

보안 점검 — 플랜이 변경한 모든 내용을 비밀 값 유출, 인젝션 위험, 새로운 공격 표면에 대해 감사하고 docs/SECURITY.md를 최신으로 유지하며, 플랜의 전체 범위에 대해 필수 로컬 AI Diff Reviewer 리뷰를 실행합니다(리뷰어가 없는 경우 local reviewer not installed 발견 항목으로 기록되며 조용히 건너뛰지 않습니다). 치명적인 발견은 완료를 차단합니다.
최종 상태 검증 — 적용 가능한 모든 테스트, 린트 및 타입 검사 스위트가 최종 상태에서 실행되어 통과합니다. 리뷰 과정에서 발생한 수정은 영향을 받은 결과를 무효화하고 재실행을 트리거합니다.
스킬 결정 대조 — 각 작업이 로컬 스킬 결정을 기록했는지 검증하고, analysis_results/SKILLS_CANDIDATES.md에서 실행 가능한 스킬 작성 후보를 대조합니다.
문서 일치 대조 — 동작을 변경한 각 작업의 변경 표면을 해당 기능을 문서화하는 파일(docs/TESTING_GUIDE.md, 아키텍처 문서, AGENTS.md)과 대조하여 동기화합니다.
완료 — 플랜 기록 일치 확인(작업 목록, 진행 로그 및 v6와 v7 플랜의 경우 journal 파생 스냅샷과 영수증); 산출물, 증거 및 제한 사항을 보고하고 Executive Report를 한 번 제안합니다.

README와 PROGRESS 관례

계획 README.md는 제목(# Deep Work Plan: <name>), 산문 형태의 목표 진술, 선택적 원천 자료 절, 작업 표(번호, 작업 이름, 상태 체크박스), 그리고 <n>/<total> tasks complete 형식의 계획 상태 줄을 담아야 합니다.

PROGRESS.md는 추가 전용 실행 로그입니다. 각 항목은 ISO 8601 타임스탬프, 작업 번호와 이름, 수행한 일, 그리고 모든 이탈이나 건너뜀 이유를 기록합니다. 오직 늘어나기만 하므로, 계획이 실제로 어떻게 전개되었는지의 신뢰할 수 있는 이력입니다.

제목과 상호 참조

모든 제목은 문장형 대소문자(sentence case)를 사용하며, 문서는 마케팅 표현과 느낌표를 피합니다. 이 관례는 에이전트 전반에 걸쳐 그리고 시간이 지나도 계획을 일관되게 유지합니다.