realign-spec

同步规范

将一个功能的规范三件套（docs/specs/<date>-<feature>/{requirements,design,tasks}.md）重新对齐到实际情况——代码、测试和任务中的实际情况。变更后未重新同步的规范会沦为虚构，而虚构比没有规范更糟。

一次处理一个功能。先确定规范目录（由用户提供、根据当前分支确定，或从 docs/specs/INDEX.md 查找）。

铁律

• 绝不重新编号需求 ID。 ID 一经批准便不可更改；下游内容都会引用它们。
• 绝不删除需求。 应将其标记为退役：~~**CODE-N.M**~~ <reason>——划掉的 ID 不再算作已定义，但历史记录仍清晰可查。
• 新需求使用其所属故事下一个可用的编号；新任务必须与现有任务格式完全一致。
• 绝不写入 Status: Shipped。 此状态转换由发布批次的 cut-release 步骤 i 完成。此技能用于重新对齐一组三件套，不负责盖上发布标记。
• 绝不写入 Status: In-progress。 此状态转换由 execute-common 会话预检完成。

步骤

a. 基线。 运行 audit-trace 检查（必需子技能：使用 audit-trace）并记录发现项——这是“之前”的情况。

b. 需求 ↔ 任务。 对比 requirements.md 与 tasks.md：

• 有未退役需求没有任何任务引用 → 按文件其余部分的相同格式追加一项覆盖该需求的任务，并以 _Requirements: CODE-N.M_ 页脚结尾。
• 可验证已完成的工作（已实现且存在其证明主张的证据），但任务框尚未勾选 → 勾选任务框。

c. 需求 ↔ 设计。 将需求 ID 与 design.md 中的 Satisfies: 行进行对比。任何未退役需求若未出现在任何 Satisfies: 行中，都要告知用户——要么为设计补充章节（扩展设计），要么该需求只是愿景目标（考虑将其退役）。不要悄悄编造设计内容。

d. 孤儿项。 列出所有页脚引用已划掉或不存在的 ID 的任务。向用户展示清单，并为每项建议处理方式（改为引用有效 ID、删除任务引用，或恢复该需求）——孤儿项需要做出决定，不能当作清理工作处理。应用测试中的旧版 ID 字符串不属于此步骤范围（仅处理文档主干）。

e. 状态转换——仅凭证据。

转换	所需证据
Draft → Approved	用户明确批准了该规范——绝不能推断
Approved / In-progress → Implemented	所有任务框均已勾选，且仅针对文档的 audit-trace 检查无错误，且 prove-claim 验证命令全部通过
Implemented → Shipped	此处不执行——cut-release 步骤 i 会将该批次的状态设为 Shipped

有证据时，执行 Draft → Approved 或 Approved / In-progress → Implemented：更新 requirements.md 中的 Status: 行以及 docs/specs/INDEX.md 中该功能对应的行。如果证据不完整，准确说明缺少什么，不要转换状态。在发布流程进行期间，若有人要求“将已发布功能标记为 Shipped”，这属于 cut-release 步骤 i，而非此技能——拒绝盖章，并提出修复单个功能规范三件套中偏差的方案。

f. 之后的情况。 重新运行 audit-trace 检查，并并列输出前后两组发现项——已解决的错误和警告、仍然存在的问题，以及为此所做的更改。确认 docs/specs/INDEX.md 反映每份规范当前的 Status: 行，并将其暂存到同一提交中。

完成条件： 之后的报告在错误方面不比之前更差；每个已标记的问题都已修改，或有待用户明确决定；并且 INDEX.md 与每份规范的 Status: 行一致。