# 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` 用来掩盖前面没有对齐好的问题