核心循环

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

任务的九段式结构

Task file

1. 01 Goal
2. 02 Context
3. 03 Steps
4. 04 Acceptance criteria
5. 05 Validation
6. 06 Files
7. 07 Dependencies
8. 08 Risks
9. 09 Completion & Log

每个任务文件都按顺序包含这九个段落。这一结构保证每个工作单元都自成一体且可审阅：

1. Goal（目标） —— 用一段文字陈述该任务达成了什么。
2. Context（上下文） —— 背景、链接，以及这项任务为何存在。
3. Steps（步骤） —— 有序、具体、要执行的动作。
4. Acceptance criteria（验收标准） —— 一份界定“完成”的条件清单。
5. Validation（验证） —— 为核实工作而要运行的命令或测试。
6. Files（文件） —— 预计将被创建或修改的路径。
7. Dependencies（依赖） —— 其他任务或外部前置条件。
8. Risks（风险） —— 可能出错之处，以及缓解措施。
9. Completion & Log（完成与日志） —— 一个状态标记外加按时间顺序排列的记录。

验证、完成与恢复

验证是任务的一部分，而非事后补充：每项任务都点明证明其完成的命令或测试，代理在标记完成之前先运行它们。完成会在“完成与日志”段落中以一个明确的状态标记记录下来（[ ] 未开始、[~] 进行中、[x] 已完成、[!] 受阻）。恢复依赖于这些标记与进展日志——代理可以确切重建出计划停在何处，并从第一项未完成的任务继续，无需重做已完结的工作。