docs: record the CI-only failure of 237's green half (I5)

Author: speak-agent

.agents/docs/2026-08-15-issues-426-427-analysis.md

@@ -605,6 +605,26 @@ R6 断定 journal 不含参照臂的版本、只能另写 `meta.json`。核实
 对象会进入该包每一个链接单元 —— `libpurec.so` 拿到了 `mixed_cxx.o`,于是「纯 C 单元」
 在这个布局下根本不存在。改成三个独立工程。
 
+## I5 ⚠️ 237 的绿色一半断言了**机器的属性**,不是 mcpp 的行为
+
+初版的绿色一半是「加上 `allow_host_libs = true` 必须能构建」。本机绿,**CI 红**:
+
+```
+ld: cannot find crt1.o / crti.o / -lm
+```
+
+落回宿主需要宿主真有一份 C 运行时,而 runner 上一个都没有。方向与
+`shared-gcc-payload-specs-poisoning` 记的那次相反 —— 那次是本机有历史污染,这次是
+**本机有 runner 没有的宿主开发文件**。两者共同点:断言依赖了运行机器。
+
+改成不依赖机器的对照:**同一个 home、同一批载荷、同一个工程,只给 SubOS 补上
+`subos_info` 块**,必须构建成功。这同时更强 —— 它证明第 1 部分的失败确实只是降级,
+而不是这个环境本来就编不出东西。
+
+绑定哪个 glibc 也不能猜:向真实 home 的 `subos_info.runtime` 要,取不到才回落到目录
+扫描。装了两个 glibc 载荷的机器上,`ls | head -1` 会按字母序挑中工具链没有针对它打过
+补丁的那个,让对照因为与被控变量无关的原因失败。
+
 ## I4 降级时**不写** marker
 
 方案 A2 原说「降级写出的 marker 其 `glibcLib` 为空,身份可知后会自动重跑」。实现时