名称: 规范对齐 描述: 将规范文件与实现对齐。检测规范与代码之间的漂移，呈现差异，由用户决定更新规范还是代码。当规范文件及其实现都在上下文中时使用。
规范对齐
原则（始终有效）
当规范文件及其对应的实现都在上下文中时，这些原则适用：
规范与代码必须一致
- 规范描述预期行为；代码实现它。当它们不一致时，必有一方是错误的。
- 绝不默默容忍漂移——一旦发现立即呈现。
- 用户决定每个差异的真相来源。不要假设。
漂移类别
- 类型漂移：规范定义的字段/类型与实现不匹配
- 行为漂移：规范描述的逻辑代码未遵循
- 缺失实现：规范定义了某些内容但没有对应的代码
- 缺失规范：代码实现了未在规范中描述的行为
- 约束漂移：规范声明的约束代码未强制执行
- 错误处理漂移：规范定义的错误情况代码未处理（或反之）
修改策略
- 除非用户明确为某个差异选择“更新规范”，否则不要编辑规范文件。
- 除非用户明确为某个差异选择“更新代码”，否则不要更改实现逻辑。
- 更新代码后，运行代码检查/类型检查。
- 更新规范时，保留无关部分的格式和结构。
双向感知
阅读代码时，检查是否存在规范并注意分歧。 阅读规范时，检查实现是否匹配并注意分歧。 这种感知应该是被动的——在您的响应中标记漂移，不要打断用户的主要任务，除非漂移直接相关。
工作流程（当显式对齐时）
步骤 1：定位规范
需要规范文件。搜索：
*.spec.md、*-spec.md、SPEC.mdspec/*.md、docs/*.spec.md
如果存在多个规范，询问对齐哪一个。如果不存在，停止——此工作流程需要现有规范。
完整阅读规范文件。
步骤 2：将规范映射到代码
对于每个规范部分，识别对应的实现：
| 规范部分 | 源文件 | 状态 |
|---|---|---|
## 类型 |
src/types.ts:10-40 |
已对齐 / 已漂移 / 缺失实现 / 缺失规范 |
在评估之前阅读每个映射的源文件。
步骤 3：呈现差异
对于每个差异：
### DRIFT-01: <简短描述>
**规范说明** (spec-file.md:L42):
> <引用的规范文本>
**代码行为** (src/module.ts:L87):
> <总结的代码行为>
**影响**: <什么会破坏或不一致>
使用稳定的 ID 编号 (DRIFT-NN)。将共享根本原因的相关差异分组。
步骤 4：用户决策
对于每个差异，询问：
- 更新规范 - 代码是正确的，更新规范以匹配
- 更新代码 - 规范是正确的，更新代码以匹配
- 跳过 - 推迟处理此差异
步骤 5：应用更改
规范更新：
- 使用更正后的文本编辑规范文件
- 保留无关部分的格式和结构
代码更新：
- 修复实现以匹配规范
- 更改后运行代码检查/类型检查
- 如果更改不简单，在编辑前概述更改并确认
- 如果受影响代码存在单元测试，运行它们
- 如果不存在单元测试且规范定义了可测试行为，标记它
步骤 6：总结
## 规范对齐: <文件>
**发现的差异**: N
**已解决**: X (规范: A, 代码: B, 跳过: C)
### 剩余
- DRIFT-04: <描述> (已跳过)