open-spec-complete

将变更标记为已完成，并同步持续更新的规范。

与框架无关：无论你使用了临时变更产物、计划模式、TDD 还是直接实现，都适用。 唯一要求：specs/features/ 必须反映系统当前的行为。

---

输入：可选指定变更名称（如果使用了 specs/changes/<name>/）。否则，自动根据 Git 推断差异。

步骤

1. 了解变更内容

   git diff HEAD --stat
   git status
   

   阅读关键变更文件，了解新增、修改或移除了哪些行为。

2. 检查工作流产物

   检查 specs/changes/<name>/ 是否存在：

   • 是（结构化工作流）：更新规范时，将其中的工作产物用作规划上下文。
   • 否（计划模式 / TDD / 直接实现）：阅读变更代码，并确定 specs/features/ 中哪些需求受到差异影响。

3. 更新 specs/features/

   对于每项受影响的能力：

   • 阅读 specs/features/<capability>/spec.md
   • 根据实际行为变更，确定需要新增、修改或删除的内容
   • 使用 RFC 2119 + WHEN/THEN 格式进行必要的最小更新
   • 如果行为属于一项新能力，则创建 specs/features/<new-capability>/spec.md

   格式（参见 AGENTS.md）：

   ### Requirement: <system behavior as a declarative statement>
   <One-sentence description using SHALL/MUST.>
   
   #### Scenario: <observable outcome>
   - **WHEN** <condition or trigger>
   - **THEN** <expected system response>
   

   规范描述行为，而非实现。不要提及技术名称或框架。

4. 清理临时产物

   如果 specs/changes/<name>/ 存在：

   rm -rf specs/changes/<name>
   

   工作流脚手架不会提交——它已完成使命。

5. 报告

   展示 specs/features/ 中的变更。用户应将这些内容与代码变更一并提交。

输出

## Specs Updated

### Modified
- specs/features/learning-content-admin/spec.md — Added scenario: [...]
- specs/features/detectives-scenario-admin/spec.md — Updated requirement: [...]

### Created
- specs/features/<new-capability>/spec.md — New capability

### Cleaned up
- specs/changes/<name>/ (ephemeral artifacts removed)

Commit specs/features/ with the rest of this change.

约束

• 始终更新 specs/features/——如果可观察到的行为发生了变化，规范也必须随之更新
• 绝不归档产物——删除它们（这些文件已被 Git 忽略，且仅供临时使用）
• 规范仅描述行为：不得包含数据库架构、组件名称或端点路径
• 如果变更只是纯内部重构，没有可观察到的行为变化，则在跳过前先向用户确认
• 每项能力对应一个 spec.md，而非每项任务或 PR 对应一个
• 规范更新必须通过重建测试：开发者能否仅凭规范重建此功能？