文档标准

版本 5.0.0。 本标准界定了 Deep Work Plan 如何记录其结构、任务与进展，以及一个仓库应如何记录自身，从而使代理能够安全地行动。它适用于在 DWP 方法论下创建的每一份计划。本版本将文档自身的版本号与其所配套的 DWP 标准对齐——不改动任何既有要求——并新增了下文所述的精简索引预算强制机制与功能层级。关键词 MUST、SHOULD 与 MAY 按 RFC 2119 中所定义使用。

AGENTS.md 作为紧凑的入口点

根目录下的 AGENTS.md 文件 SHOULD 保持在 150–500 行的预算之内。当生成或由 harness 维护的内容将超出此预算时，代理 MUST 将细节移入拥有该内容的 docs/ 指南（或模块/功能文档）中，并从索引中链接它——没有任何内容被丢弃，只是被重新安置，且索引 MUST 链接每一份接收了被移出内容的文档。一份超出预算的手写 AGENTS.md 绝不会被静默重写：代理会提出一份具体的迁移方案（哪些内容移到哪里、新增哪些链接），并且只有在开发者同意后才应用它。符合性检查器将该预算视为建议性的，因为行数是客观的，而作者身份并非如此——该 MUST 约束的是生成或更新该文件的 harness，而非检查器对是谁写了该文件的猜测。AGENTS.md MUST NOT 链接一个不存在的 docs/ 文件。

在下文的按模块文档层级之上，还有一个功能层级：一个重大能力领域——大于单个模块——会在其代码旁获得自己的 docs/ 文件夹，并通过自己的 README.md 进入。当一个领域跨越两个或更多重大模块、拥有一个自成一体的子应用或子系统目录，或者携带多个消费方所依赖的自有契约（API 表面、事件或模式契约）时，即符合条件。一旦某个领域被记录为重大领域，其功能 docs/ SHOULD 存在，其最重要的条目 SHOULD 从其所跨越的模块以及根目录 AGENTS.md 索引中被链接，方式与按模块文档完全相同。一个被有意保持无文档状态的领域会携带一条已记录的理由——这是一项决定，而非疏漏。

计划 README

每份计划 MUST 拥有一个 README.md，其中包含：

标题 —— # Deep Work Plan: <name>。
目标 —— 一段散文式的计划目标陈述。
源材料 —— 指向规范输入的链接或路径（可选）。
任务 —— 一个 Markdown 表格，含任务编号、名称与一个状态复选框。
状态 —— 一行形如 <n>/<total> tasks complete 的内容。

任务文件

每个任务文件 MUST 命名为 <n>.task_<slug>.md，并包含十段式结构——九个经典段落外加触及面（Touched Surface）：该任务改动之物与必须验证之物之间的契约（计划面与实际面、受影响的消费方、isolated（隔离）、seam（接缝）、shared/core（共享核心）或 unknown（未知）之一的风险级别、所用的测试映射，以及所选关卡及其理由）。

PROGRESS.md

PROGRESS.md 是一份只追加的执行日志。每条记录 MUST 记下：

一个 ISO 8601 时间戳。
任务编号与名称。
做了什么。
任何偏差或跳过的原因。

状态标记

[ ] —— 未开始。
[~] —— 进行中。
[x] —— 已完成。
[!] —— 受阻。

标题

所有标题 MUST 采用首字母句式（sentence case）。文档 SHOULD 避免使用营销式语言与感叹号。

Final Review、任务内技能决策与可选报告

在本版本下编写的每份计划 MUST 恰好以一项强制任务收尾：Final Review——对计划完整变更集的安全审查、对最后相关状态的最终状态验证，以及技能决策的核对。一项严重的安全发现会阻止完成。

任务内技能决策。 每项任务的“完成与日志”段落都承载一项技能处置（skills disposition）——none（无）、对既有技能或代理的更新、一次具名创建，或一次附带理由与负责人的推迟。有依据的编写发生在所属任务内部、其验证关卡之前，并在对照 .agents/ 目录查重之后；有依据的条目以稳定候选（T{task}-{seq}）的形式记录在计划的技能候选台账中。
Executive Report 是可选的，按需生成。 在完成时提供一次；仅在明确请求时从持久证据中生成。没有回应，或一次无人值守运行，都会让计划在没有它的情况下照常完成。
旧版计划。 在更早版本下编写的计划以三项强制收尾任务收尾，且仍然符合规范——符合性检查器 MUST 接受那种形态。