可执行计划

计划说明做什么、先后关系和如何验收。它复用用户请求、已批准的 Spec、issue 和项目现有记录，不另造一套需求材料。

流程

1. 从现有证据确定目标、范围、验收和依赖。只就影响结果的未定取舍询问用户；常规实现选择自己决定，并写明必要的假设。
2. 优先更新项目已有的计划载体；没有惯例且确需持久计划时，用 docs/plans/YYYY-MM-DD--<topic>-plan.md。短任务用对话计划；一句话能描述且没有跨文件依赖的改动，不落盘计划文件。
3. 写目标、范围、可执行工作项、验证方式、重要依赖或风险。多阶段任务写最终整体验收（final_integration_claim），因为每步各自通过不等于整体成功。
4. Markdown 工作项用 checkbox；issue 或现有 tracker 保留其原生状态。多工作项计划把依赖写成边：每项带 依赖: #N（无则写「无」），让计划成为任务图——前置全部完成的项即可开工，ship 据此并行派发。切分规则：
   • 纵向切片：每项贯穿所需各层、可独立验证、一个新上下文窗口装得下；需要的预重构排最前（先让改动变容易，再做容易的改动）。
   • 全仓机械改动（改名、改共享类型，一改即破大量调用点）不硬切纵向，走 expand–contract：先加新形式且不破坏旧的 → 按爆炸半径分批迁移调用点（每批一项，依赖 expand）→ 最后删旧形式（依赖全部迁移批）。
   • 共享文件：两项会改同一共享文件（配置表、消息目录、共享类型）时，加依赖边让它们串行，或在计划里预先定死各自新增的名字。
5. 恢复面：只有需要跨会话恢复的轨道才建文件，短任务零文件；项目已有别的 tracker（issue、看板等）时复用它，不另建 .harness/。用 .harness/ 时开一条轨道：在 .harness/index.md 的 | 轨道 | 状态 | 入口 | 表里加一行（状态 active，入口链接到 tracks/<id>.md），并建 .harness/tracks/<id>.md，写 Objective:、Status:、Entry:、Evidence:、Next:、Limits: 六行，Entry: 指向本计划文件。链接用相对路径；只动本轨道，不改其他轨道的行或文件。项目 AGENTS.md 还没有指向 .harness/index.md 的读取指引时补一行。格式细节以 writing-for-agents 的恢复面政策为准；项目有 scripts/harness_lint.py 时提交前跑一次。
6. 用户只要求计划时，交付后结束。已授权实现时继续执行可推进的步骤；写计划不是新的批准门槛。

验证与提交

• 验证受阻时记录缺口、可用证据和不能作出的声明，继续不依赖缺口的工作。不要把工具暂缺自动变成重新搭建工作台的任务。
• 不用替代检查冒充原验收；改变约定的验收标准需要用户同意。
• commit 可用于有意义的里程碑，不是每个计划的必填项。提交需满足项目约定和相关验证；项目没有提交约定时，以 implement 的提交规则为准。
• 不强制为每项重复填写 acceptance_criteria、verification_commands、success_definition；行动和成功条件写清楚即可。

之后

• 已授权且需要改动：implement；有多个可同时开工的工单：ship；根因未知：diagnose。
• 用户要求审阅，或改动需要深入检查：review。
• 计划被放弃或否决：用 cleanup 关轨道。
• 只在真实的工作台缺口需要修复时用 harness-builder；只要计划时直接结束。