improve-codebase-architecture

# 改进代码库架构 发现架构摩擦点，提出**深化机会**——将浅模块变为深模块的重构。目标：可测试性与 AI 可导航性。 使用 [references/LANGUAGE.md](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](references/INTERFACE-DESIGN.md)。 ### 4. 实施 用户选定候选项并批准接口设计后： 1. 参考 [references/DEEPENING.md](references/DEEPENING.md) 制定具体深化策略 2. 编写新的集成测试，通过新接口测试行为 3. 合并模块，删掉旧的浅层测试（它们已成废代码） 4. 确认所有测试通过，删除任何遗留的原型代码 ## 参考文档 - [references/LANGUAGE.md](references/LANGUAGE.md) — 完整词汇表与定义 - [references/DEEPENING.md](references/DEEPENING.md) — 按依赖类型的深化策略 - [references/INTERFACE-DESIGN.md](references/INTERFACE-DESIGN.md) — 并行子代理接口设计模式