改进代码库架构

浮现出架构上的摩擦点，并提出加深机会——将浅模块转变为深模块的重构。

流程

1. 探索

先阅读项目的领域术语表（CONTEXT.md）以及你所触及区域中的任何 ADR（架构决策记录）。

走查代码库。不要遵循僵化的启发式规则——有机地探索，并记下你在哪里感受到摩擦：

• 在哪里理解一个概念需要在许多小模块之间来回跳转？
• 哪里的模块是浅的——接口几乎和实现一样复杂？
• 哪里仅仅为了可测试性而抽取了纯函数，但真正的 Bug 却藏在它们被调用的方式里？
• 哪里紧耦合的模块从其接缝处泄漏出来？
• 代码库的哪些部分未经测试，或者通过其当前接口难以测试？

对任何你怀疑是浅的东西应用删除测试：删掉它会让复杂性集中，还是只是把复杂性挪了个地方？

2. 将候选项呈现为 HTML 报告

将一个自包含的 HTML 文件写入操作系统的临时目录。为每个候选项渲染一张卡片，包含：

• 文件（Files）——涉及哪些文件/模块
• 问题（Problem）——当前架构为何造成摩擦
• 方案（Solution）——用通俗英语描述将要改变什么
• 收益（Benefits）——从局部性（locality）和杠杆（leverage）的角度来解释
• 改前 / 改后图示（Before / After diagram）——并排展示其浅薄之处与加深之后的效果
• 推荐强度（Recommendation strength）——Strong、Worth exploring、Speculative 之一

在报告末尾以一个**首要推荐（Top recommendation）**章节结束。

3. 拷问循环

一旦用户选定了某个候选项，运行 /grilling 技能，与他们一起走查设计树。

副作用会随着决策的成型而内联发生——运行 /domain-modeling 技能，以在过程中保持领域模型的最新状态。