docs: L4's real shape — extracting a dependency lengthens the chain, not shortens it

Author: speak-agent

.agents/docs/2026-08-13-build-optimization-status.md

@@ -28,7 +28,7 @@
 | **L1** | 按次选择工具链 `--toolchain` | **已实施** | 实测 81.8 → **32.6s**(2.51×) |
 | **L2** | 下游在 BMI 可用时即开始 | **已实施**(`schedule = "on"`) | 实测 79.9 → **34.8s**(2.30×) |
 | **L3** | 定义移出接口单元 | **不做**(改的是实现风格,见下) | 推算:链 74.6 → ~10.4s |
-| **L4** | 拆 `build.prepare` | **可做**(架构改动) | 推算:链 −8~11s |
+| **L4** | 拆 `build.prepare` | 可做,但形状已查清:需拆 `prepare_build` 本身 | 推算:链 −8~11s |
 
 ### L1:做成了「按次选择」,没有换默认
 
@@ -60,8 +60,25 @@ L3 指的是**改 mcpp 自己的 138 个模块**——把定义从接口单元
 两者都改 mcpp 自己的源码,但**不是同一类动作**:
 
 * **L4 是架构改动** —— `build.prepare` 6521 行、16.4s、占关键链 22%,是唯一的真离群点。
-  把它拆成**互不依赖的兄弟模块**既缩短关键路径,也是一个 6500 行模块本来就该做的事。
-  ⚠️ 拆成**链式**的两个模块等于什么都没做 —— 必须是兄弟。**可以做。**
+  **可以做**,但形状比"把大文件拆小"苛刻得多:
+
+  ⚠️ **把一部分抽成 prepare 的依赖,是让链变长而不是变短。**
+  `… → 新模块 → prepare → …` 仍然串行,只是多了一跳;prepare 少掉的那点成本
+  被新模块自己的成本抵掉。抽出来的东西必须是 prepare 的**兄弟** ——
+  被 prepare 的**导入者**直接使用,才能与 prepare 并行编译。
+
+  实际调查(谁 import prepare、用了什么):
+
+      configure.cppm   只用 BuildContext(一个类型)
+      execute.cppm     用 BuildContext + prepare_build
+      doctor / pack / cli.cmd_build   只用 prepare_build
+
+  所以把 `BuildContext` 抽成叶子模块能让 `configure` 不再依赖 prepare ——
+  **但链上是 prepare → execute → configure**,而 `execute` 需要 `prepare_build`,
+  configure 仍在 execute 之后。**净收益为零。**
+
+  真正能缩短关键路径的是**拆 `prepare_build` 本身**,让 `execute` 只依赖它的一部分。
+  那是对一个 6521 行模块的深度重构,不是一次抽取,需要单独立项。
 * **L3 是实现风格改动** —— 把定义从接口单元移到实现单元,要动 138 个模块。
   它对代码的组织方式提出要求,而收益只对改写了的那个工程生效。
   **不做**;要量收益就在临时分支上测,测完即弃。