构建绿且有余量时，用行为不变的深度重构加深最浅模块…

适用于构建绿、测试通过且有余量，模块接口和实现一样复杂、同一改动反复触及多文件，或用户明确要求加深/改善设计质量/拉低复杂度/消耗剩余预算（如说 deepen this、invoke /ck:deepen）时，对 spec 触及的最浅模块做行为不变的加深重构。

适用场景

解决思路

1. 行为神圣：开始前和结束后测试都必须是绿的；每次变更只能缩小接口或隐藏决策，要加深，不要瞎搅动。
2. 选定最浅模块：扫描 spec 触及的模块，按浅度（接口表面 vs 实际完成的工作）排序，选出唯一的 worst offender；每次只处理一个模块，加深是外科手术，不要做代码库清扫。识别信号：只转发到另一个方法的 pass-through 方法（浅层）；调用者必须正确设置 5 个 flags 才能使用（配置泄漏）；同一抽象在两层重复（没有信息隐藏）；可追溯到令人困惑接口的 `?` 或 §B。
3. 诊断：用最直白的语言命名设计缺陷，并引用 file:line，例如 `src/auth/token.go: 6-arg ctor leaks rotation policy to every caller. shallow.`；复杂度 = 依赖 + 晦涩且会累积，只有表现为变更放大、高认知负荷或未知未知（调用者必须知道隐藏事实才能正确调用）时才算真实问题。
4. 研究加深方案：思考更深版本长什么样；若存在 codebase-design 技能，借助其 deep-module 词汇；可拉取已知模式（外部案例交给 `research` → §R），或从代码库自身更好的模块推导。加深动作：把复杂度向下拉（pull complexity down），给调用者简单路径；通过设计消除错误（define errors out of existence），让边界情况不可能发生；信息隐藏，一个决策一个模块，调用者不需要知道它；用通用接口替代一堆特殊 case 方法。
5. 提出方案：把变更起草为 spec 编辑，而不是静默重写：提出模块新的/更简单的 §I 形状；提出 §V 锁定加深后的不变式，防止未来 build 重新变浅；提出 §T 重构行，每行引用它服务的 §V/§I；交给 `spec` 来写。展示 before/after 接口，让用户看到接口收缩。
6. 验证行为保持不变：重构 ≠ 重写；开始前和结束后完整测试套件都绿。如果加深改变了行为，那是伪装成重构的功能，停止，改走 `/spec` + `/build`。为新接口增加测试，证明旧调用者仍能工作。
7. 结束条件：选定模块的接口严格更小，隐藏决策不再泄漏，测试绿，§I/§V 记录新形状，即可结束。一个模块被加深胜过五个模块被瞎折腾。
8. 还有预算：如果还有预算，选择下一个最浅模块，开启新的一轮 pass。

适用边界 · 注意事项

• 不要在功能开发中途、临近截止或压力下运行；这是有余预算时的刻意 pass，不是条件反射。
• 不要改变行为；若必须改变行为，那是伪装成重构的新功能，应走 `/spec` + `/build`。也不要直接写 `SPEC.md`，只提议 §I/§V/§T 由 `spec` 写入。
• 不要在一次 pass 中加深超过一个模块、做全库清扫，或为单次使用的代码添加抽象；投机性抽象只会增加接口表面。