ProgrammerAnthony/improve-codebase-architecture

改进代码库架构

发现架构摩擦点，提出深化机会——将浅模块变为深模块的重构。目标：可测试性与 AI 可导航性。

使用 references/LANGUAGE.md 中的词汇表，所有建议中严格使用这些术语。

核心词汇（速查）

• 模块（Module）：有接口和实现的任何东西（函数、类、包、切片）。
• 接口（Interface）：调用者需要了解的一切：类型、不变量、错误模式、顺序、配置。不只是类型签名。
• 深度（Depth）：接口背后的杠杆——大量行为隐藏在小接口后面是深，接口复杂度接近实现复杂度是浅。
• 接缝（Seam）：可以不编辑内部代码而改变行为的地方。
• 适配器（Adapter）：在接缝处满足接口的具体实现。
• 删除测试（Deletion test）：想象删掉这个模块。复杂度消失了？那它是透传层。复杂度在 N 个调用者处重新出现？那它值得存在。

流程

1. 探索

先读取项目的领域词汇表（CONTEXT.md、UBIQUITOUS_LANGUAGE.md 等）和相关 ADR。

使用 Explore 子代理遍历代码库。有机探索，记录摩擦点：

• 理解一个概念需要在多个小模块间来回跳转的地方？
• 接口复杂度接近实现的浅模块？
• 为可测试性提取出来的纯函数，但真正的 Bug 隐藏在调用方式中（无局部性）？
• 紧耦合模块跨接缝泄漏的地方？
• 未测试或难以通过当前接口测试的代码？

对可疑的浅模块做删除测试：删掉它会集中复杂度，还是只是移动了它？"集中"是你要找的信号。

2. 提出候选项

呈现编号的深化机会列表。每个候选项包含：

1. 模块标识：名称 + 文件路径
2. 浅度诊断：为什么它是浅的（接口太多、散布在 N 个调用者、透传层、测试只能通过实现细节）
3. 深化思路：合并哪些模块、接缝放哪里、哪些依赖需要端口
4. 可测试性收益：深化后如何改善测试（更少 Mock、直接可测接口、局部性更好）
5. 工作量估算：小/中/大（不做具体行数预估）

在提出候选项时停下，等待用户选择。 不要直接开始重构。

3. 为选定候选项设计接口（可选）

若用户想要对选定候选项探索多种接口设计，使用并行子代理模式——详见 references/INTERFACE-DESIGN.md。

4. 实施

用户选定候选项并批准接口设计后：

1. 参考 references/DEEPENING.md 制定具体深化策略
2. 编写新的集成测试，通过新接口测试行为
3. 合并模块，删掉旧的浅层测试（它们已成废代码）
4. 确认所有测试通过，删除任何遗留的原型代码

参考文档

• references/LANGUAGE.md — 完整词汇表与定义
• references/DEEPENING.md — 按依赖类型的深化策略
• references/INTERFACE-DESIGN.md — 并行子代理接口设计模式