| name | gap-analysis |
| description | 执行完成后对照原始 RFC/Plan 检查遗漏和偏差。 触发场景:(1) 用户说"gap analysis"、"对照方案检查"、"完成度评估"、"遗漏检查"; (2) TDD 执行完成后需要系统化验证覆盖度; (3) 发布前确认所有承诺的能力都已兑现。 不适用于:代码级 review(用 requesting-code-review)、测试验证(用 verification-before-completion)。
|
Gap Analysis
对照原始 RFC/Plan 系统化检查实现完整度。
核心理念
- Plan 是合约:RFC 承诺的每一项都必须有交付证据或显式后置声明
- 偏差 ≠ 错误:执行中发现更优方案而偏离 RFC 是正常的,但必须记录理由
- "有意后置"必须显式:不能靠"没做"来隐性后置,必须写明后置原因和条件
流程
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/补做/后置 |
| "代码存在"即"能力生效" | 查集成测试证明运行时行为 |
| 偏差不记录理由 | 每个偏差必须解释为什么实际方案更优 |