docs: L4 implemented — architecture win, measured zero on build time, and why

Author: speak-agent

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

@@ -37,8 +37,8 @@ on 那次命中了缓存。5 个单元相对 80s 的差值可以忽略,但记在
 |---|---|---|---|
 | **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` | 可做,但形状已查清:需拆 `prepare_build` 本身 | 推算:链 −8~11s |
+| **L3** | 定义移出接口单元 | **不做** —— 已量出它治的是 L2 同一个病 | 实测:对 mcpp **−6.2%**,对 cmake +92.3% |
+| **L4** | 拆 `build.prepare` | **已实施**(架构收益;性能上为零) | 实测:**0**,原因见下 |
 
 ### L1:做成了「按次选择」,没有换默认
 
@@ -87,7 +87,25 @@ cmake 按 BMI 的 mtime 级联,mcpp 比 BMI 的内容。**L3 是给没有 L2 的
 
 **所以 L3 的文档提示是:先要引擎的 L2,再谈重构。** 顺序反了会做很多白工。
 
-### L4 与这条界线
+### L4:已实施,而且实测收益为零 —— 这一点比数字本身重要
+
+抽出 `mcpp.build.prepare_inputs`(341 行,cfg() 谓词 + 指纹规范化),
+`prepare.cppm` 6521 → 6186 行,两个函数 re-export 所以调用方零改动。
+
+**构建时间没有变化**(off 79.23s / on 34.54s)。原因在拆分前就分析出来了,
+实测只是确认:**抽出来的东西成了 prepare 的依赖,链只会变长不会变短** ——
+`… → prepare_inputs → prepare → …` 仍然串行,prepare 少掉的成本正好由新模块付掉。
+
+要缩短关键路径,抽出的部分必须是 prepare 的**兄弟**(被 prepare 的**导入者**直接用)。
+已查清:configure 只用 `BuildContext`,execute 用 `BuildContext` + `prepare_build`,
+其余只用 `prepare_build`;而链上是 prepare → execute → configure,
+execute 离不开 `prepare_build`,所以抽类型也没人能离开这条链。
+真正有效的是拆 `prepare_build` 本身。
+
+而且 **L2 落地后这件事的收益又小了一截**:一个接口现在只阻塞导入者约 22% 的编译,
+不是全部。所以这次拆分按**架构**理由留下(6500 行的模块本就该拆),不按性能理由。
+
+### 这条界线
 
 ⚠️ **这是本轮最重要的一条界线。** 「优化 mcpp 的构建性能」指的是**通用构建性能**,
 不是把 mcpp 这一个工程调快。**通过改被测目标来变快,不能算数** ——