69 行
1.8 KiB
Markdown
69 行
1.8 KiB
Markdown
# Foundation: Refactoring And Gap Closure
|
|
|
|
## Purpose
|
|
把 `Code -> Alignment -> Refinement` 之间的关系讲清楚，防止团队把重构当成末尾装饰，把 Gap 当成补锅动作。
|
|
|
|
## When to Use
|
|
- 在实现阶段安排检查点时
|
|
- 在对齐阶段判断要补什么、不该补什么时
|
|
- 在准备验收前决定优化层级时
|
|
|
|
## Inputs
|
|
- `SPECS/*.md`
|
|
- 实现代码
|
|
- 测试结果
|
|
- 最近变更范围
|
|
|
|
## Outputs
|
|
- Gap 分类结果
|
|
- 重构批次
|
|
- 优化层级选择
|
|
|
|
## Primary Agent/Model
|
|
`GPT-5.4 Pro xhigh`
|
|
|
|
## Secondary Agent/Model
|
|
`Claude Opus 4.6`
|
|
|
|
## Required Skills
|
|
- `spec-gap-tasking`
|
|
- `code-simplifying`
|
|
- `code-refactoring`
|
|
- `architecture-audit`
|
|
|
|
## Steps
|
|
1. 先比对 Spec 和实现，分类缺口。
|
|
2. 缺口补齐后立刻做简化，避免把新增复杂度直接沉积下来。
|
|
3. 每完成一批类别，做一次增量重构。
|
|
4. 所有功能补齐后，再做全局简化、重构、必要时模块化与结构重组。
|
|
|
|
## Exit Criteria
|
|
- 已知缺口有计划、有实施、有验证
|
|
- 重构不再是“以后再说”，而是节奏化动作
|
|
- 优化层级与项目目标匹配
|
|
|
|
## Failure Recovery
|
|
- 若对齐阶段开始大规模重写无关代码，回到缺口范围定义
|
|
- 若重构修改了行为，回到最近稳定计划和测试
|
|
|
|
## Related Templates
|
|
- [`../templates/tdd-plan-template.md`](../templates/tdd-plan-template.md)
|
|
- [`../templates/todo-yaml-template.md`](../templates/todo-yaml-template.md)
|
|
|
|
## Gap Types
|
|
- `Missing`
|
|
- `Partial`
|
|
- `Divergent`
|
|
- `Untested`
|
|
- `Integration`
|
|
|
|
## Refactor Rhythm
|
|
- 实施后立即 `Simplify`
|
|
- 每 4 个类别做一次 `Refactor`
|
|
- 全库阶段做 `Architecture Audit`
|
|
|
|
## What Not To Do
|
|
- 不要在缺口分析前先写修复代码
|
|
- 不要把“代码更优雅”当成偏离 Spec 的理由
|
|
- 不要把 `Refinement` 用来掩盖前面没有对齐好的问题
|