amend-feature

Amend Feature

演进已发布的功能，而无需重新执行从零开始的准入流程。该功能已有获批的规范和可运行的代码；要做的是如实判断变更相对于该规范的类型，然后将其分配到仍能确保规范和测试成立的最轻量流程。

这是一条快速通道，不是绕过准入流程。每条路径最终都必须经过 test-first，任何涉及实际设计问题的变更都必须升级到 frame-change。“小”是一项需要依据现有规范证明的主张，而不是一种感觉。

1. 以现有规范为依据

找到该功能的规范——通过 docs/specs/INDEX.md 查找 docs/specs/<date>-<feature>/{requirements,design,tasks}.md——并阅读变更涉及的需求以及负责这些需求的设计部分。如果该功能完全没有规范，amend-feature 就不是合适的技能：全新能力应使用 frame-change，修复故障应使用 root-cause。

**完成条件：**你能说出变更影响的需求 ID。

2. 明确说明变更类型

像 frame-change 说明层级一样，明确说出属于哪种情况及其原因：

• Tier 0 — 不改变行为。 更换颜色、图标或标签，修改文案；所有现有验收标准仍然原样成立。→ 必须使用子技能：使用 test-first（在对应的接缝处断言视觉或行为变更）。除修正措辞已过时的验收标准外，无需修改规范。
• Tier 1 — 修改或扩展现有规范中定义的行为，耗时 ≤ 约半天。 变更修改了现有需求已承诺的内容，或为其添加了小幅后续内容。→ 迷你规范：添加或修改需求，并为必须继续正常工作的行为添加一条 ... SHALL CONTINUE TO ... 守护要求（必须使用子技能：在Tier 1 迷你规范模式下使用 specify-behavior——将修复内容和守护要求附加到所属功能的 requirements.md；不编写新功能代码，也不进行整文件审查），然后必须使用子技能：使用 test-first。
• 真正的新范围。 规范从未涵盖的新行为、存在多个实际选项的 UX 或设计决策、耗时超过约半天，或涉及多个子系统。→ 停止修订规范。必须使用子技能：使用 frame-change——这类变更需要完整流程。不要在这里规划大型新工作。

判断是否需要升级的关键问题是：现有规范的意图是否已经涵盖此行为？ 如果你正在发明它应该如何表现，那就是新范围——应升级处理。

**完成条件：**明确说明层级并选定情况。

3. 保持审计追踪准确

变更通过 test-first 完成后，其新增或变更的需求应像其他需求一样，将其 ID 写入测试标记和提交尾注中。如果你编辑了 requirements.md、design.md 或 tasks.md，必须使用子技能：使用 realign-spec 对齐 Status: 和追踪记录。否则，必须直接使用子技能：使用 audit-trace，并阅读其检查结果。检查必须无误，否则变更尚未完成。

**完成条件：**变更通过 test-first 实现，需求 ID 实现端到端追踪，且 audit-trace 检查未报告任何错误。

危险信号——你选错了流程

• 你正在发明规范从未描述的行为 → 应使用 frame-change，而不是 amend。
• “小”变更引出了存在多个实际选项的设计决策 → 升级处理；不要凭感觉在这里做决定。
• 你准备在不修改测试的情况下更改代码 → 必须始终使用 test-first。
• 该功能从未编写规范，或者功能只是出了故障 → 应使用 frame-change（新功能）或 root-cause（故障），而不是 amend。
• 你正把一个请求拆成琐碎部分和新增行为部分 → 分别处理：微调留在这里，新行为交给 frame-change。