gap-analysis

name	gap-analysis
description	执行完成后对照原始 RFC/Plan 检查遗漏和偏差。 触发场景：(1) 用户说"gap analysis"、"对照方案检查"、"完成度评估"、"遗漏检查"； (2) TDD 执行完成后需要系统化验证覆盖度； (3) 发布前确认所有承诺的能力都已兑现。 不适用于：代码级 review（用 requesting-code-review）、测试验证（用 verification-before-completion）。

Gap Analysis

对照原始 RFC/Plan 系统化检查实现完整度。

核心理念

1. Plan 是合约：RFC 承诺的每一项都必须有交付证据或显式后置声明
2. 偏差 ≠ 错误：执行中发现更优方案而偏离 RFC 是正常的，但必须记录理由
3. "有意后置"必须显式：不能靠"没做"来隐性后置，必须写明后置原因和条件

流程

Phase 1: 提取 RFC 承诺

读取原始 RFC/implementation_plan，提取所有可交付项：

• 功能点
• API/接口变更
• 测试计划
• 安全措施
• 迁移/兼容措施

Phase 2: 逐条对比

对每项输出分类：

状态	含义	要求
✅ 完成	实现 + 测试均到位	标注验证方式
⚠️ 偏差	实现了但和 RFC 不完全一致	标注偏差原因
❌ 遗漏	RFC 承诺但未实现	判断是 bug 还是需补做
⏭️ 有意后置	确认不在本轮范围	标注后置原因和触发条件

Phase 3: 输出报告

## Gap Analysis: [RFC/Plan 名称]

### 总览
- 总承诺项：N
- ✅ 完成：X / ⚠️ 偏差：Y / ❌ 遗漏：Z / ⏭️ 后置：W

### 详细对比
| # | RFC 承诺 | 状态 | 证据/说明 |
|---|---------|------|---------|
| 1 | ... | ✅ | 测试: xxx.test.ts |
| 2 | ... | ❌ | 需要补做 |
| 3 | ... | ⏭️ | 依赖后端 API，Phase 5 |

### 行动项
- [ ] 补做项 1：...
- [ ] 补做项 2：...

### 结论
[ ] Phase X 完整闭合，可发布
[ ] 有 N 项需补做，完成后可发布

Anti-Patterns

反模式	正确做法
只检查"做了什么"	必须检查"RFC 说了什么但没做"
遗漏项默认后置	每个遗漏必须显式判断是 bug/补做/后置
"代码存在"即"能力生效"	查集成测试证明运行时行为
偏差不记录理由	每个偏差必须解释为什么实际方案更优