programmeranthony 改进代码库架构
发现架构摩擦点，提出深化机会——将浅模块变为深模块的重构。目标：可测试性与 AI 可导航性。
使用 references/LANGUAGE.md 中的词汇表，所有建议中严格使用这些术语。
核心词汇（速查）
- 模块（Module）：有接口和实现的任何东西（函数、类、包、切片）。
- 接口（Interface）：调用者需要了解的一切：类型、不变量、错误模式、顺序、配置。不只是类型签名。
- 深度（Depth）：接口背后的杠杆——大量行为隐藏在小接口后面是深，接口复杂度接近实现复杂度是浅。
- 接缝（Seam）：可以不编辑内部代码而改变行为的地方。
- 适配器（Adapter）：在接缝处满足接口的具体实现。
- 删除测试（Deletion test）：想象删掉这个模块。复杂度消失了？那它是透传层。复杂度在 N 个调用者处重新出现？那它值得存在。
流程
1. 探索
先读取项目的领域词汇表（CONTEXT.md、UBIQUITOUS_LANGUAGE.md 等）和相关 ADR。
使用 Explore 子代理遍历代码库。有机探索，记录摩擦点：
- 理解一个概念需要在多个小模块间来回跳转的地方？
- 接口复杂度接近实现的浅模块？
- 为可测试性提取出来的纯函数，但真正的 Bug 隐藏在调用方式中（无局部性）？
- 紧耦合模块跨接缝泄漏的地方？
- 未测试或难以通过当前接口测试的代码？
对可疑的浅模块做删除测试：删掉它会集中复杂度，还是只是移动了它？"集中"是你要找的信号。
2. 提出候选项
呈现编号的深化机会列表。每个候选项包含：
- 模块标识：名称 + 文件路径
- 浅度诊断：为什么它是浅的（接口太多、散布在 N 个调用者、透传层、测试只能通过实现细节）
- 深化思路：合并哪些模块、接缝放哪里、哪些依赖需要端口
- 可测试性收益：深化后如何改善测试（更少 Mock、直接可测接口、局部性更好）
- 工作量估算：小/中/大（不做具体行数预估）
在提出候选项时停下，等待用户选择。 不要直接开始重构。
3. 为选定候选项设计接口（可选）
若用户想要对选定候选项探索多种接口设计，使用并行子代理模式——详见 references/INTERFACE-DESIGN.md。
4. 实施
用户选定候选项并批准接口设计后：
- 参考 references/DEEPENING.md 制定具体深化策略
- 编写新的集成测试，通过新接口测试行为
- 合并模块，删掉旧的浅层测试（它们已成废代码）
- 确认所有测试通过，删除任何遗留的原型代码
参考文档
- references/LANGUAGE.md — 完整词汇表与定义
- references/DEEPENING.md — 按依赖类型的深化策略
- references/INTERFACE-DESIGN.md — 并行子代理接口设计模式