计划与任务模板

一份 Deep Work Plan 是一个由 Markdown 文件构成的目录。该目录——以及其中每个文件——的形态，正是使一份计划能被人类与代理共同审阅的关键。

计划结构

计划目录

• .dwp/
• plans/
• PLAN_<slug>/
• README.md 目标 · 任务表 · 状态
• PROGRESS.md 仅追加的执行日志
• 1.task_<slug>.md 任务文件（十个章节）
• 2.task_<slug>.md

一份计划是 .dwp/plans/ 下一个名为 PLAN_<slug>/ 的目录。它包含：

• README.md —— 计划概览：目标、源材料、任务表与状态。
• 每项任务一个文件，命名为 <n>.task_<slug>.md。
• PROGRESS.md —— 一份持续的执行日志。

任务文件结构

每个任务文件命名为 <n>.task_<slug>.md，并遵循十段式结构：Goal、Context、Touched Surface（触及面）、Steps、Acceptance criteria、Validation、Files、Dependencies、Risks 以及 Completion & Log。这些段落始终按该顺序出现，于是任何读者都知道该往哪里看。每项任务在行动之前都会重新锚定到计划的目标，这能防止代理在漫长的、长达数小时的周期里发生漂移。

Final Review

每份计划都必须恰好以一项强制任务收尾：Final Review。它以三个有序的环节为计划收尾——安全审查环节没有任何放松：

1. 安全审查 —— 审计计划改动的一切，检查机密信息、注入风险与新的攻击面，并让 docs/SECURITY.md 保持最新。安全不是在结尾才拼接上去的独立工作流：每份计划都让自己的改动经过审计，且一项严重发现会阻止完成。
2. 最终状态验证 —— 代码仓库的完整验证在最后一次修复之后的最后相关状态上运行并通过。
3. 技能决策核对 —— 每项任务都在其证据尚且新鲜时记录了自己的技能处置；Final Review 负责核对这本台账。Executive Report 仍可按需提供。

README 与 PROGRESS 约定

计划的 README.md 必须包含一个标题（# Deep Work Plan: <name>）、一段散文式的目标陈述、一个可选的源材料段落、一个任务表（编号、任务名、状态复选框），以及一行形如 <n>/<total> tasks complete 的计划状态。

PROGRESS.md 是一份只追加的执行日志。每条记录都记下一个 ISO 8601 时间戳、任务编号与名称、做了什么，以及任何偏差或跳过的原因。由于它只会不断增长，它是计划实际如何展开的可靠历史。

标题与交叉引用

所有标题都采用首字母句式（sentence case），文档避免使用营销式语言与感叹号。这些约定让计划在不同代理之间、在时间推移中保持一致。