amend

Amend

演进已发布的功能，无需重新通过绿地开发关卡。该功能已有获批的规范和可运行的代码；任务是依据规范如实判定变更类型，然后将其引导到既能确保规范和测试依然成立、又最轻量的流程。

这是快速通道，不是绕过关卡。每条路径最终都要经过 tdd，任何存在实质性设计问题的情况都要升级到 brainstorm。“小”是一个需要对照现有规范验证的判断，而不是一种感觉。

1. 以现有规范为变更依据

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

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

2. 明确说明变更类型

说明属于哪种情况以及原因，方式与 brainstorm 明确说明层级相同：

• **Tier 0 — 不改变行为。**重新着色、更换图标、修改标签或文案；所有现有验收标准依然原样成立。→ 必须使用子技能：使用 tdd（在对应的切入点断言视觉或行为变更）。除修正已过时的标准措辞外，不得修改规范。
• **Tier 1 — 修改或扩展规范已有的行为，耗时 ≤ 约半天。**变更调整现有需求承诺的内容，或对其做小幅补充。→ 迷你规范：补充或修订需求，并添加一条 ... SHALL CONTINUE TO ... 守护条款，确保必须继续正常工作的行为不受影响（必须使用子技能：在 tier-1 mini-spec mode 下使用 write-requirements — 将修正和守护条款追加到所属功能的 requirements.md；不编写新的功能代码，也不进行整份文件审查），然后必须使用子技能：使用 tdd。
• **确属新范围。**规范从未涵盖的新行为、存在多个实际备选方案的 UX 或设计决策、耗时超过约半天，或涉及多个子系统。→ 停止使用 amend。必须使用子技能：使用 brainstorm — 这类情况需要完整流程。不要在此处规划大型新工作。

判断是否应升级的关键问题是：**现有规范的意图是否已经涵盖这种行为？**如果你在创造它应该如何运作的定义，那就是新范围 — 应将其提交给上一级流程。

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

3. 确保追踪记录准确

变更通过 tdd 完成后，新增或修改的需求应像其他需求一样，将其 ID 写入测试标签和提交尾注。如果你修改了 requirements.md、design.md 或 tasks.md，必须使用子技能：使用 sync-spec 使 Status: 与追踪记录重新保持一致。否则，必须直接使用 trace 并查看其发现项。检查结果必须无误，否则变更尚未完成。

**完成条件：**变更通过测试优先方式实现，需求 ID 端到端可追踪，且 trace 检查未报告任何错误。

警示信号 — 你走错了流程

• 你正在创造规范从未描述过的行为 → 应使用 brainstorm，而不是 amend。
• “小”变更引出了有多个实际备选方案的设计决策 → 应升级处理；不要凭感觉在此处拍板。
• 你准备在不修改测试的情况下改代码 → 无论如何都应使用 tdd。
• 该功能从未有过规范，或者只是出了故障 → 使用 brainstorm（新功能）或 debug（故障），而不是 amend。
• 你正把一个请求拆分成一个琐碎部分和一个新增行为部分 → 分别处理两部分：微调留在此处，新增行为交给 brainstorm。