improve-codebase-architecturelisted

# 改善代码库架构 识别出代码库里的架构 friction，并提出 **deepening opportunities**——把 shallow module 变成 deep module 的重构。目标是可测试性和 AI 可导航性。 本命令以项目的 domain model 为依据，并建立在共享的设计词汇之上： - 先运行 `/codebase-design` skill 获取架构词汇（**module**、**interface**、**depth**、**seam**、**adapter**、**leverage**、**locality**）及其原则（deletion test、「interface 就是测试面」、「一个 adapter = 假想的 seam，两个 = 真实的」）。在每一条建议里都精确使用这些术语——不要滑向「component」「service」「API」或「boundary」。 - `CONTEXT.md` 里的领域语言为好的 seam 提供了命名；`docs/adr/` 里的 ADR 记录了本命令不应重新审议的 decision。 ## 流程 ### 1. 探索 **扫描之前先划定范围——YAGNI。** 深化一个 module 的回报在于让未来对它的修改更轻松，所以要格外关注代码库中最近有变动的部分。在开始看之前，先决定看_哪里_： - 如果用户指明了方向——某个 module、子系统或痛点——就顺着它走，跳过下面的推断。 - 否则，往回翻一段较长的 commit 历史（`git log --oneline`），找出代码库的 hot spots——那些反复出现的文件和区域——让这些路径最先抓住你的注意力。如果改动很分散、没有明显的 hot spot，就放宽范围。 先阅读你将要触及的领域的项目 domain glossary（`CONTEXT.md`）和任何 ADR。 然后用 `subagent_type=Explore` 的 Agent 工具走一遍代码库。不要死守僵化的启发式规则——要有机地探索��并记下你感到 friction 的地方： - 在哪里，理解一个概念需要在许多小 module 之间来回跳？ - 哪些 module 是 **shallow** 的——interface 几乎和 implementation 一样复杂？ - 哪里把纯函数抽出来只是为了可测试性，但真正的 bug 却藏在它们的调用方式里（没有 **locality**）？ - 哪些紧耦合的 module 正在穿过它们的 seam 泄漏？ - 代码库的哪些部分没有测试，或者难以通过它们当前的 interface 来测试？ 对任何你怀疑是 shallow 的东西应用 **deletion test**：删除它会聚拢复杂性，还是只是把复杂性挪个地方？「是的，会聚拢」就是你想要的信号。 ### 2. 以 HTML report 呈现 candidates 把自包含的 HTML 文件写到操作系统临时目录，确保仓库里不留任何东西。临时目录从 `$TMPDIR` 解析，回退到 `/tmp`（Windows 上是 `%TEMP%`），写到 `<tmpdir>/architecture-review-<timestamp>.html`，这样每次运行都会得到一个新文件。为你打开它——Linux 用 `xdg-open <path>`，macOS 用 `open <path>`，Windows 用 `start <path>`——并告诉用户