reroute-plan

Reroute Plan

当发现推翻已批准计划的问题时，用于决定是否在执行中回退。这是一个轻量路由器：它决定哪个工件现在已失效，以及要回退多远，然后按下方“轻量路由器出口”所述交由其他流程处理。build-in-waves 遇到“计划本身有误”或根本原因位于当前任务之上的断路器时，会转交至此；用户也可以在察觉不对劲时立即直接调用。

按顺序分为三个阶段：诊断、分类、路由。设有两个硬性停止点，绝不自动改写。

谁发现了变化，谁就决定入口。 你或工作者发现了变化 → 阶段 1。变化写在操作者自己的消息中——他们说明要添加、修改或删去什么 → 参见下文“操作者修订”。

操作者修订——其消息同时代表两项批准

说出“把状态删掉”的操作者已经批准继续并选定了变更；阶段 1 和阶段 2 不再暂停确认。十二次基线运行中，操作者在开会期间发出了此类消息，直到 4 点才结束；其中一次运行停在阶段 1，一整个下午什么也没做；另有三次自行阅读了此技能，并擅自跳过了其中的停止点。

1. 按阶段 2 的方式对最低层级的失效工件进行分类，并追加台账记录（见下文“幂等性”）。层级决定哪些工件要变更；无需询问任何人。
2. 按照负责该工件的技能所规定的方式，编辑这些工件及其以下的所有内容，不必经过该技能的文件审批停止点。
3. 按操作者的指示继续构建。
4. 报告结尾必须包含一个检查此措辞区块：逐字列出你撰写或删除的每一条需求、设计和任务内容，并注明其文件。此区块用于补上被跳过的审批。在十二次基线修订中，有十一次改写了标记为 Approved 的规范，却没有一次引用自己写下的内容。

阶段 1 — 诊断（用户硬性停止点）

这是一次发现问题——不是操作者修订。

撰写一份包含五个标注部分的结构化诊断通知：

• 问题：哪里有误或发生了什么变化
• 位置：偏差出现在哪里
• 原因：为什么当前计划不再有效
• 影响：对剩余执行有何影响
• 其他作出决定所需的背景信息

呈现通知并停止。不要分类，不要触碰任何工件，在用户明确作出决定前不要继续。

完成条件： 用户已明确决定继续或不继续。

如果用户拒绝：不修改规范或代码，并交还控制权，不执行回退。这是一次干净的空操作，不是部分回退——磁盘上的任何内容都不会改动。

第 2 阶段 — 对失效程度最低的产物进行分类

仅在获得诊断许可后执行。找出链条中失效程度最低且确实失效的层级，并引用相关证据：

层级	发现推翻了……	重新进入（第 3 阶段）
任务局部	仅当前任务的方案；规范仍然成立	返回 build-in-waves/test-first
计划	任务拆分／顺序／覆盖范围；设计仍然成立	plan-tasks
设计	架构／设计决策；需求仍然成立	design-solution → plan-tasks
需求	已承诺的内容——某项标准有误或缺失	specify-behavior → 设计 → 计划
愿景	功能前提与产品范围冲突	当已发布的代码／规范与新前提冲突时，指定 /assess-pivot-impact；否则返回愿景层（/define-project），再否则向人工升级

**分类原则：**选择有证据支持的最低层级。没有更高层级的证据，却为了“保险起见”回退到更高层级，禁止。如果某项发现仅破坏了当前任务的方案，不会仅仅因为回退到 specify-behavior 感觉更安全、更全面，就值得这么做。

提交一份变更提案——说明所选层级、相关证据和建议的重新进入点——然后停止，等待用户批准后再进行路由。

**完成条件：**用户批准提案。

提案是临时的：它只在对话中用于决定是否继续，绝不会作为独立产物写入磁盘。docs/specs/ 下的任何内容都不会记录“已提出变更”；只有后续重新进入的技能所做的编辑以及下面的台账会留下记录。

幂等性 — 证据台账

每次回退都必须由新发现的证据驱动，不能只是重新审视同一事实。分类前，先读取 .skills/<CODE>/corrections.md（临时、被 git 忽略的草稿文件，与 .skills/<CODE>/progress.md 并列，作用范围限于当前进行中的计划）。其中每条已处理的修正占一行，包含一个证据指纹、所选层级和结果。

如果当前偏差会把同一条已处理证据重新归类到同一个失效程度最低的产物，且没有新证据，不要再次进入该层级。改为向用户升级处理——这样可以在 build-in-waves → reroute-plan → write-* → realign-spec → build-in-waves 循环启动前将其打断。此规则不妨碍处理真正的新发现：记录其指纹、层级和结果，作为新的台账条目，然后照常分类。

**完成条件：**分类前已读取台账，并且要么触发了升级处理（重复出现，且没有新证据），要么记录了新条目（确有新证据）。

请注意，台账是草稿，而不是持久化的规范产物——将内容记录到台账中，不会与上述临时提案规则冲突；该规则针对的是变更提案，而不是此修正日志。

阶段 3 — 路由并重新进入

提案获批后，路由到相应的重新进入点。将每项都作为必需子技能直接调用——绝不要只建议用户运行它——并让该技能运行自己的审批门槛：

• 任务局部 → 返回 build-in-waves/test-first；不回退任何上游产物。
• 计划 → 必需子技能：使用 plan-tasks。
• 设计 → 必需子技能：使用 design-solution，该技能会继续流转到 plan-tasks。
• 需求 → 必需子技能：使用 specify-behavior，该技能会继续流转到设计和计划。
• 愿景 → 如果已交付的代码或规格与新前提冲突，向用户指出 /assess-pivot-impact（由用户调用；不要调用它）。如果冲突仅存在于文档中，且 docs/product/vision.md 存在，则指出 /define-project（更新）。如果这两个层面都不存在，则升级给用户处理；只有在用户同意该前提确实存疑时，才重新进入必需子技能：使用 frame-change。

完成条件： 已直接调用相应的子技能，且该技能自己的审批门槛正在运行——reroute-plan 不会在其之上另行虚构一道审批步骤。

精简路由器退出 — 委派、协调、记录、恢复

reroute-plan 绝不自行改写需求、设计、计划、任务或审计跟踪元数据。所有规格内容的生成都委派给 write-* 技能；所有三元组协调都委派给 realign-spec。

重新进入技能的审批门槛通过后：

1. 协调。 如果重新进入修改了已获批产物或其跟踪链接，则必需子技能：使用 realign-spec 重新协调 Status 和审计跟踪——它负责带理由的删除线退役和 INDEX 更新；reroute-plan 不会重新实现其中任何部分。
2. 记录。 如果最终获批的变更带有架构影响，则通过必需子技能：使用 define-domain 将其记录为 ADR。设计层级的回退通常符合条件；需求或愿景层级的回退仅在架构影响重大时符合条件。任务局部和计划层级绝不记录 ADR。对于用户未批准的提案，绝不保存 ADR。
3. 恢复。 将控制权交还给 build-in-waves，它会根据自己的账本，基于修正后的计划自动恢复——无需手动重启。对于任务局部回退，.skills/<CODE>/progress.md 保持不变。对于改写了 tasks.md 的计划／设计／需求回退，必须先重新校准账本：保留其已提交工作在改写后仍然有效的条目，删除被改写取代的条目，让 build-in-waves 从最后一个仍然有效的已完成任务之后恢复，而不是依据过时的任务编号。该账本是被 git 忽略的临时文件，因此不会触及任何规格产物。

完成条件： 如果产物发生变更，则已执行协调；ADR 仅在有必要且获批时存在；并且 build-in-waves 正在依据与（可能已改写的）tasks.md 相符的账本恢复运行。

危险信号——使用了错误的技能

• 功能上线后的范围内调整，针对已上线功能（重新着色、修改文案、小幅后续调整）→ 应使用 amend-feature，而不是 reroute-plan。这里并没有什么“先获批、后失效”的情况——功能已经上线。
• 针对仍然有效的规范的代码缺陷 → 应使用 root-cause，而不是 reroute-plan。规范仍然成立；出错的只是实现。
• realign-spec 是退出流程，不是决策者。 它是机械式的协调器，在回退决策之后运行，重新对齐 Status 和追踪记录。reroute-plan 决定哪个制品不成立；它不负责 realign-spec 的记录工作，而 realign-spec 也不做回退决策。
• build-in-waves 中的前置计划审查（其派发前一致性扫描）发生在执行前，不属于执行中发现——这不是本技能的触发条件。

想法	实际情况
“这个发现看起来影响很大，我还是直接回退到需求阶段以防万一吧”	根据证据，将失效的制品归类到最低层级。没有更高层级的证据却向上多回退是被禁止的——这会浪费该发现并未争取到的审批。
“用户已经同意有问题了，我可以直接开始分流”	诊断的继续/停止决定与变更提案审批是两个不同的关卡。同意存在问题，不等于批准了特定的重新进入路径。
“我直接修改计划文件就好，更快”	reroute-plan 不负责编辑。应转交给 plan-tasks/design-solution/specify-behavior——内容及其各自的关卡由它们负责。
“同一个缺陷又出现了，我再回退一次”	先阅读 .skills/<CODE>/corrections.md。证据相同、层级相同、没有新发现 → 应升级交由用户处理，而不是继续循环。