plan

计划

将设计意图转化为可执行的阶段计划。

输入：

• slice-nnn.md（范围）
• design.md（规范设计参考）
• 现有的 plan.toml / plan.md（如有）

流程

1. 同时阅读切片范围和 design.md。

2. 确认规划没有超前于设计：

   • 如果 design.md 缺失或为空，请停止并运行 /design，除非已收到明确指示，要求另行处理。
   • 如果 design.md 存在，但相对于当前需求或切片范围已过时，请先协调设计。如有歧义，请向用户澄清。
   • 不得将创建计划或阶段作为解决未定设计问题的替代方案。
   • 如果规划暴露出实质性的新设计问题，请先运行 /design 修订或补充设计，然后再继续。
   • 在相信设计的前提之前，务必重新 grep。 设计在撰写时已定稿，但代码树此后可能已有变化。扫描 design.md，找出具体且可通过 grep 检索的引用——文件路径、函数／类型名称、常量、配置键——并在当前代码树中逐一核实（使用 grep、ls、git show）。路径缺失、文件已移动或符号已重命名，都意味着设计依据已过时：请停止并运行 /design 协调设计，然后再基于错误路径搭建阶段表。（如果设计没有指出任何具体内容，就没有需要核查的内容——只需核查设计明确断言的内容。）
   • 检查研究建议（doctrine slice research <id>），然后依据其 Thread 2 热点图拟定切片的选择器，而不要凭记忆编写——设计阶段的选择器试运行只完成了核查的一半。

3. 搭建计划骨架：doctrine slice plan <ID> 会写入 plan.toml + plan.md（若文件已存在则拒绝覆盖）。此工具会读取这些文件，但不会重写——可自由手动编辑。

   设计审查中转交的发现（暂定）。 编写阶段前，打开切片的设计审查 RV，并阅读所有 route 为 demonstrate、probe 或 control 的发现。review show 的索引视图会显示 route 列；使用 -f 阅读每项已转交发现的响应——参见 lib:reference/review-ledger.md § Route axis。每项发现都是一项刻意未在文案中修复的义务。其响应包含一份判定标准草案和一项放置约束：在满足约束的最早阶段，将该草案转录为进入或退出标准，并在标准文本中引用 RV-NNN F-n。未转录的已转交阻断项无法如实验证；未验证的阻断项会阻止切片关闭。没有任何机制会验证这项转录。

4. 编写 plan.toml——每个有序阶段对应一个 [[phase]]：

   • id 为 PHASE-NN（补零），不可变且不得重复使用——编辑时只追加，绝不重新编号。

   • 阶段的 name 和 objective。

   • entrance_criteria（EN-n）、exit_criteria（EX-n）和 verification。验证 ID 须注明其模式：由测试验证的为 VT-n，由 Agent 验证的为 VA-n，由人工验证的为 VH-n——当测试无法判断某项标准时，请使用 VA／VH，确保后续仍会检查，而非被悄然跳过。这些 ID 在各阶段内有效，且同样不可变。

   • 结构化 VT 强制要求（不可妥协）。 每个 VT-n 行至少必须包含 test_file + keywords，以便 VT 门禁获得有效信号。缺少这些字段时，verify-vt 会报告 UNCHECKABLE——此时整个项目的门禁都形同虚设。请将此强制要求写入 TOML 行，而非正文：

     { id = "VT-1",
       expects = "round-trip unit：新函数可解析、渲染并再次解析",
       test_file = "src/your_test.rs",
       keywords = ["your_fn", "your_struct"],
       patterns = ["^\\s*pub fn"],   # 可选：更严格的行锚定结构
       waived = false }
     

     • test_file — 关键词实际出现的唯一文件 （生产源码，或该阶段会触及的测试文件）。该任务只指定一个 test_file；所有关键词都必须出现在这个文件中。 选择该阶段会修改的文件，或用于测试该阶段的测试文件——不要两者都选。 这必须是该阶段完成后确实存在的路径，而不是未来才会创建的文件。
     • keywords — 该阶段完成后必须出现在该文件中的原始子字符串。 这是适度的最低要求：对原始源码进行纯子字符串匹配（不去除注释或字符串）。
     • patterns（可选）— 以行为锚点的正则表达式，用于更强的语言无关结构断言。正则表达式由编写者负责。
     • waived — 例外项，必须提供 waived_reason。

     doctrine slice verify-vt <id> 会在 dispatch conclude/handover 时检查每项 VT 任务，而不是在审计时检查。没有关键词的 test_file 会因空条件而通过——真正让门槛发挥作用的是关键词底线，而不只是文件本身。

   • v1 中，specs / requirements 保持为空（尚无注册表）。当切片确实包含关联关系时， 应使用 doctrine link 记录（此处不使用类型化键）——参见 lib:reference/using-doctrine.md § 关联实体。

5. 编写 plan.md——说明理由和顺序的文字：为何采用这些阶段、为何按此顺序、为何这样划定边界。遵循存储规则 （lib:reference/using-doctrine.md § 存储层级）：不得在 plan.md 中放入查询或派生数据。

6. 提交。

7. 严格审视计划：有哪些内容规定不足、依赖假设、含糊不清、范围过大、过于乐观、需要验证，或存在实施风险？ 针对每项，决定需要补充哪些信息，或应采取哪些缓解措施。计划应以已知的实现细节为依据。

8. 规划修订；向用户打印修订摘要。然后逐项完成修订。

9. 修订计划；再次提交。总结变更内容。

10. 物化阶段跟踪：doctrine slice phases <ID> 会根据 plan.toml 在状态树中创建各阶段的表单。--prune 会删除已不存在的计划阶段所对应的孤立跟踪记录（此操作具有破坏性——仅在确实要删除某阶段时使用）。

11. 交接给 /phase-plan，在执行前立即扩展下一阶段的运行时阶段表单，然后交给 /execute。仅当切片范围、design.md 和 计划的内容一致后才执行。交接时记录生命周期变更： doctrine slice status <id> ready（裸数字）。

结果

• plan.toml 已可用于执行：每个阶段都有目标、EN/EX 验收标准，以及明确模式（VT/VA/VH）下的验证方式。
• plan.md 说明了理由和顺序。
• 每个阶段都有一份包含明确完成标准的运行时阶段表单。
• 如果出现计划复杂性或策略歧义，请停止并使用 /consult。