用途：为代码重构提供安全流程与决策指导。核心前提是“重构是保持行为不变的改动”。三条规则：先修复再重构，且两者不得在同一提交，须有提交边界；小改动需要更多严谨而非更少，1–5 行改动错误率最高；超过半数改动首次失败，即便“微不足道”也要评审和测试，错误率按每次改动计算而非累积。
决策：代码当前不工作则属于修复而非重构，先修；设计根本上有问题考虑重写；改动涉及模块超过 30% 属“大重构”，考虑重写。生产宕机时只修不清理，稳定后再单独重构。
必要用法：重构前先找目标模式（本代码库最佳范例与模块约定），精确匹配或刻意确立先例。安全流程按优先级：版本控制保存起点、每次只做一个小改动、先列计划步骤、逐个改动后重编译与重测并报告结果、频繁提交、开启最严格编译警告、即使 1 行改动也必须评审。重构若导致测试失败，应回退、缩小步骤，而非深入调试。缺失前置条件时：无自动测试先用 welc-legacy-code 技能并写特征测试；无版本控制先备份；无评审者用清单式自审并增加提交与测试。
TRANSFORMER 模式把坏味道转为整洁代码且保持可观察行为：设置/拆卸坏味道封装接口、tramp data 改直接访问、重复代码抽取例程、投机性设计代码删除。行为改变属修复，先修。若违反（混合提交），推送前用 git reset --soft HEAD~1 分离后重新提交，推送后记录并在后续 PR 拆分，不对共享分支强推。其他阈值与 40 项清单见 cc-foundations.md 与 checklists.md。