全新 MCPP_HOME 的首次构建:rule B 对每个产物报 inconclusive(binding 求值早于 farm 落盘)

[speak-agent]

现象

在一个全新的 MCPP_HOME 里第一次构建(即用户装完 mcpp 的第一次 mcpp run),
runtime closure 校验对每一个产物报 inconclusive,刷出一屏警告:

warning: runtime closure validation is inconclusive for …/bin/helloegui:
rule B inconclusive for …/bin/helloegui: RuntimeBinding glibc@2.44 has no loader path
rule B inconclusive for …/bin/helloegui: RuntimeBinding glibc@2.44 has no library directory
warning: runtime closure validation is inconclusive for …/bin/libX11.so:
rule B inconclusive for …/bin/libX11.so: RuntimeBinding glibc@2.44 has no library directory
…（一个图形工程 13 条）

第二次构建警告全部消失。 这不是随机的:

	binding.loader	binding.library_dirs	警告
首次运行(同时在装工具链)	""	[]	13 条
第二次 mcpp build	…/xim-x-glibc/2.44/lib/ld-linux-x86-64.so.2	[…/xim-x-glibc/2.44/lib]	无

复现:rm -rf 一个全新的 MCPP_HOME(或解包 release tarball 后直接构建)即可。

分析

src/platform/runtime_binding.cppm:337-380 从 <subos>/lib64、<subos>/lib 里找
libc.so.6 和唯一的 ld-linux-* 来填这两个字段。磁盘上二者都在
(<subos>/lib/libc.so.6 符号链接 + 唯一一个 ld-linux-x86-64.so.2),而
binding.search_dirs 也确实记下了 <subos>/lib —— 只有 loader / library_dirs
是空的。

自然的读法是:首次运行时 binding 的求值早于 farm 落盘。精确接缝(binding 解析点
vs 载荷/farm 写入点)还需要一次探针确认 —— 不要照着这个推理直接改。

影响

• 新用户的第一次构建就看到一屏自己无法处理的警告
• rule B 恰好在最该生效的那一次运行里失效

必须说清楚的一点

即使 rule B 完全正常,它也抓不到 #414 那个崩溃。
src/platform/elf_runtime.cppm:761-801 只比对 libc / PT_INTERP 的同一性,不管其它
SONAME 解析到谁。修这个 issue 不能替代 #414 的顺序修复,也不要把它当成那次缺陷的
兜底。

判据

全新 MCPP_HOME 的第一次构建:要么 rule B 给出真实判决(pass/mismatch),要么
binding 明确记录"此刻还无法求值"并只说一次,而不是对每个产物各刷两条。

背景

• rule B / RuntimeBinding 引入: feat: 运行期搜索闭包 与 binding 降级 —— 链接期看得见的,运行期也要看得见 (2026.8.11.2) #413
• 相关分析: .agents/docs/2026-08-11-runtime-search-origin-precedence-analysis.md §4 D