章 02
中核ループ
DWP は、計画を目標から完了したレビュー可能な作業へと進める、小さな操作の集合を定義します。すなわち create → execute → refine → resume → status であり、結果を確認する適合チェックとして verify が加わります。これらが合わさって、エージェントが計画の生涯を通じて従うループを形づくります。エージェントは一度に一つのタスクを実行し、次へ進む前に各ステップを検証します。
このループは、仕様駆動開発の運用上のかたちです。計画はエージェントが照らして実行する仕様であり、各タスクは明示的な受け入れ基準を備え、検証のステップは完了の主張をその証拠へと変えるゲートです。計画とその進捗ログがリポジトリの中に存在するため、ループはセッションとエージェントをまたいで再開可能です。
操作
- create — 目標から新しい計画を生成します。エージェントは目標を分析し、逐次的なタスクへと分解し、計画ファイルを書きます。目標が曖昧なときは、書く前に明確化のための質問をすべきです。
- execute — 計画をタスクごとに実行します。エージェントは各タスクのあとに進捗ログを更新し、そのタスクの完了状態を記します。理由を記録せずにタスクを飛ばしてはなりません。
- refine — 既存の計画を修正します。エージェントはタスクを追加、削除、並べ替えできますが、完了済みの作業を保持し、タスク表を更新しなければなりません。
- resume — 中断された計画を続行します。エージェントは進捗ログとタスクファイルを読んで状態を再構築し、最初の未完了タスクから続行します。
- status — 実行せずに進捗を報告します。エージェントは完了済み、進行中、保留中のタスクを要約し、何も変更しません。
- verify — 何も変更せずに適合性を確認します。エージェントは、リポジトリが標準を満たしているか、計画がよく形成されているか、すなわちすべてのタスクが受け入れ基準と検証ゲートを備えているかを報告します。仕様の適合性ドキュメントを参照してください。
.dwp/ 出力ディレクトリ
すべての DWP 成果物は、リポジトリのルートにある gitignore された .dwp/ ディレクトリの配下に存在します。作業領域をバージョン管理の外に置くことで、計画の作業状態がプロジェクトの履歴を汚すことは決してありません。
.dwp/
├── plans/
│ └── PLAN_<slug>/
│ ├── README.md
│ ├── PROGRESS.md
│ └── <n>.task_<slug>.md
└── config.yaml九つの節からなるタスク構造
- 01 目標
- 02 コンテキスト
- 03 手順
- 04 受け入れ基準
- 05 検証
- 06 ファイル
- 07 依存関係
- 08 リスク
- 09 完了とログ
すべてのタスクファイルは、これら九つの節をこの順序で含みます。この構造は、各作業単位が自己完結しレビュー可能であることを保証します。
- Goal（目標） — タスクが何を達成するかを述べる一段落。
- Context（コンテキスト） — 背景、リンク、そしてこのタスクが存在する理由。
- Steps（手順） — 実行すべき、順序づけられた具体的な行動。
- Acceptance criteria（受け入れ基準） — 完了を定義する条件のチェックリスト。
- Validation（検証） — 作業を検証するために実行するコマンドやテスト。
- Files（ファイル） — 作成または変更されると見込まれるパス。
- Dependencies（依存関係） — 他のタスクや外部の前提条件。
- Risks（リスク） — 何がうまくいかない可能性があるか、そしてその緩和策。
- Completion & Log（完了とログ） — 状態マーカーと時系列の記録。
検証、完了、再開
検証はタスクの一部であり、後付けではありません。各タスクは完了を証明するコマンドやテストを指定し、エージェントは完了を記す前にそれらを実行します。完了は、Completion & Log の節に明示的な状態マーカー（[ ] 未着手、[~] 進行中、[x] 完了、[!] 阻害）で記録されます。再開はこれらのマーカーと進捗ログに依拠します。エージェントは計画がどこで止まったかを正確に再構築し、完了した作業をやり直すことなく、最初の未完了タスクから続行できます。