From 107a7f63e79008133a632c138b4e252a57f1345e Mon Sep 17 00:00:00 2001
From: speak-agent <248744407+speak-agent@users.noreply.github.com>
Date: Mon, 24 Aug 2026 23:18:58 +0800
Subject: [PATCH] =?UTF-8?q?docs(plan):=20=C2=A717=20=E2=80=94=E2=80=94=20?=
 =?UTF-8?q?=E8=90=BD=E5=9C=B0=E4=B9=8B=E5=90=8E,=E8=AE=A1=E5=88=92?=
 =?UTF-8?q?=E6=96=87=E6=A1=A3=E6=9C=89=E5=93=AA=E5=87=A0=E5=A4=84=E6=98=AF?=
 =?UTF-8?q?=E9=94=99=E7=9A=84?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

三份计划文档停在动手之前,而落地推翻了其中几处判断。**不回填的文档
在说谎**,于是补一节 §17,只记录被推翻或修正的部分。

⭐ **17.1 §4.1 的窄改法阈值定错了方向。** 上文写「命中点超过 ~30 处就
改为窄改法」,实测命中 22 处 —— 按本文的规则应走宽改法,而正确的仍然是
窄改法,理由与数量无关:`x86_64-linux-gnu` 是 `mcpp toolchain list` 打印
的东西,因此也是人们照抄的东西。判据从来不是「要改多少处」,而是
「哪一个是身份、哪一个是请求」。用改动面大小选设计,选出的是省事的那个。

**17.3 §12.3「二进制分发不能声明 provides」已被实验否掉。** 手写一个
`sources = []` + `provides` + `std-module` 的无源码包,零引擎改动即可
占住 c++-abi 层 —— 而上文据这个错误前提推出了一整套需要引擎改动的方案。

⭐ **17.4 新层名的发布门槛,本文完全没有涉及。** 一个键有三种结局,
其中两种都是 exit 0:

    provides = ["mcpp:compiler-runtime=…"]  19.4  exit 0  **未校验**
                                            24.1  exit 2  拒绝
                                            24.3  exit 0  解析

两个零不是同一种成功。19.4 早于层词表,整个数组被忽略 —— 它既不拒绝
也不读。CI 停在那里会在一份中心主张从未被检查过的清单上报绿。

⚠️ **17.5 一次撤回:把规范的机制当成了缺陷。** `kal_fs_props` 未定义
是 openkal SPEC 6.1 在工作(不提供的接口 = 链接期缺席),我补了那个符号、
发了 0.1.3、进了索引,然后全部撤回。**报错信息告诉你什么坏了,它不是规范。**

17.1 / 17.3 / 17.5 是同一族错误:用「做不到」或「什么坏了」当推理的前提,
而没有去读那份写着答案的文件。

design 定稿加一行落地状态并指向 §17;architecture 工作稿早已标注被取代。
---
 ...-24-graph-target-side-optimization-plan.md | 90 +++++++++++++++++++
 .agents/docs/2026-08-24-target-side-design.md |  7 ++
 2 files changed, 97 insertions(+)

diff --git a/.agents/docs/2026-08-24-graph-target-side-optimization-plan.md b/.agents/docs/2026-08-24-graph-target-side-optimization-plan.md
index 8d411793..805c1c3e 100644
--- a/.agents/docs/2026-08-24-graph-target-side-optimization-plan.md
+++ b/.agents/docs/2026-08-24-graph-target-side-optimization-plan.md
@@ -2033,3 +2033,93 @@ requires = ["mcpp:compiler=llvm"]
         ← 让一次构建里的 __udivti3 与其它链接不一致(mcpp#426 已论证);
           为省一次打包/一层建模而牺牲语义,是本文反对的那类捷径
 ```
+
+---
+
+## 17. 实测回填 —— 落地之后,本文有哪几处是错的
+
+本节写于 2026.8.24.3 发布之后。只记录**推翻或修正了上文判断**的部分;
+按计划做成了的事不在此列,因为它们已经在代码和 docs/14、docs/15 里。
+
+### 17.1 §11「§4.1 改动面有多大」—— 我给出的窄改法阈值定错了方向
+
+上文要求实施前先做纯统计,并说「命中点超过 ~30 处,应改为保留自动填充
+另存 `envExplicit` 布尔」。实测命中 **22 处,其中 10 处集中在 `triple.cppm`**。
+
+按本文的规则,22 < 30,应当走「删掉自动填充」的宽改法。**而正确的做法
+仍然是窄改法**,理由与命中点数量无关:`x86_64-linux-gnu` 是
+`mcpp toolchain list` 打印的东西,因此也是人们照抄的东西,删掉填充会让
+这个拼写变成一个**没有 C 库的三元组**。
+
+⭐ 判据从来不是「要改多少处」,而是「哪一个是身份、哪一个是请求」。
+两者都要留:规范形式当身份(输出目录、缓存键、`cfg()` 的主语),
+`envExplicit` 记住请求。一个用改动面大小来选设计的规则,选出的是省事的
+那个,不是对的那个。
+
+### 17.2 §11「gcc 能否消费 libc++ 的 std 模块」—— 仍然没测,而这是对的
+
+本文说「若有人要去证明它可行,那是一次实测,不是一次推理」。落地时没有
+去做这次实测,而是让 `openkal-llvm-runtime` 声明
+`requires = ["mcpp:compiler=llvm"]`,在编译任何东西之前拒绝这个组合。
+
+保留这条记录是因为**「不去回答一个问题」也是一种设计决定**,而它需要一个
+理由:能否让 gcc 编 libc++ 的模块,答案无论是什么都不会改变这个包的正确
+配置,所以那次实测的成本不换来任何决策。
+
+### 17.3 §12.3「二进制分发不能声明 provides」—— 已被实验否掉
+
+上文断言二进制分发形态无法声明层能力,并据此推导出一整套需要引擎改动的
+方案。**这是错的。** 手写一个 `sources = []` + `provides` + `std-module`
+的无源码包,零引擎改动即可占住 c++-abi 层。§12.3 已在本文修正。
+
+⚠️ 这一条与 17.1 是同一种错误:**用「做不到」当推理的前提,而没有去试**。
+[[reasons-written-from-memory-kill-good-fixes]]
+
+### 17.4 新层名的发布门槛 —— 本文完全没有涉及,而它决定了能不能发
+
+上文把 `mcpp:compiler-runtime` 当作一个模型问题,没有问「一个已发布的
+构建工具读到这个键会怎样」。实测,一个依赖声明一个键:
+
+| 键 | 2026.8.19.4 | 2026.8.24.1 | 2026.8.24.3 |
+|---|---|---|---|
+| `requires = ["mcpp:compiler=llvm"]` | exit 0 未校验 | exit 0 未校验 | exit 0 解析 |
+| `provides = ["mcpp:compiler-runtime=…"]` | exit 0 **未校验** | **exit 2 拒绝** | exit 0 解析 |
+
+⭐ **两个 exit 0 不是同一种成功。** 19.4 早于层词表,整个数组被当作不认识
+的键忽略 —— 它既不拒绝也不读。一个 pin 在那里的 CI 会在一份中心主张从未
+被检查过的清单上报绿。因此生态包声明新层时,`MCPP_VERSION` 必须同一改动
+里上移,理由不是兼容性而是**让断言有人执行**。
+
+拒绝窗口只有 2026.8.24.1 一个版本。判据是**索引服务哪个版本**,不是本包
+声明的 floor,也不是「新 mcpp 支持了」。
+
+### 17.5 一次撤回:把规范的机制当成了缺陷
+
+落地过程中,示例程序在 `riscv64-none-elf` 上链接失败:
+
+```
+ld.lld: error: undefined symbol: kal_fs_props
+>>> referenced by fs.cppm:136
+```
+
+据此给 `openkal-opensbi` 补了 `kal_fs_props = 0`,发布 0.1.3 并合入索引。
+**全错。** openkal SPEC 6.1:「实现不提供的接口,作为链接期定义是缺席的,
+使用它的消费者链接失败。」6.2 的表把时机分开 —— 链接器回答「是否用了它
+不提供的接口」,能力字回答「在**它提供的接口内**它如何表现」。
+
+给一个没有任何操作的接口定义能力字,是回答第二个问题而跳过第一个。
+已发 0.1.4 撤回,索引里 0.1.3 的条目整个删除。真正错的是**程序**:
+一份可移植源码可以问「这个文件系统怎样比较名字」,不可以问「这台机器
+有没有文件系统」。示例因此从「一份源码四台机器」改为三台宿主目标。
+
+⚠️ 与 17.1、17.3 同族,而这次更贵:**报错信息告诉你什么坏了,它不是规范。**
+
+### 17.6 落地后的实测数字
+
+| 项 | 值 |
+|---|---|
+| 单元测试 | 93 通过 / 0 失败 |
+| e2e(本机) | 289 通过 / 25 失败,零新增失败,修好 1 条既有失败 |
+| `prepare.cppm` 实质改动 | +153 / −25(其余 745 行是 lambda 缩进) |
+| 五层中由图供给 | 4 层(仅 compiler 来自载荷) |
+| 沙箱行为验证 | 13 断言全通过,mcpp 2026.8.24.3 自索引装出 |
diff --git a/.agents/docs/2026-08-24-target-side-design.md b/.agents/docs/2026-08-24-target-side-design.md
index 99767fdf..d4c0b147 100644
--- a/.agents/docs/2026-08-24-target-side-design.md
+++ b/.agents/docs/2026-08-24-target-side-design.md
@@ -1,3 +1,10 @@
+> ✅ **本文已实现并发布**,见 mcpp 2026.8.24.2 与 2026.8.24.3。
+> 规范化陈述在 `docs/spec/target-side.md`(SPEC-002),使用者文档在
+> `docs/14-target-side.md` 与 `docs/15-openkal-cross.md`。
+> **落地过程中被推翻的判断记在**
+> `2026-08-24-graph-target-side-optimization-plan.md` §17,读设计之后值得一读:
+> 其中三条是本文没有问对的问题,一条是把规范的机制当成了缺陷。
+
 # mcpp 目标侧设计
 
 2026-08-24 · 设计定稿