the design under-estimated L3, and the two sentences that cannot both hold

§5.7.3 said the link-time check maps undefined symbols to interfaces through
SURFACE.txt; §5.5 said the engine knows no member of either set. The mapping
can only come from the graph, so L3's real shape is a second generated table
in each implementation's manifest --- about a hundred lines, from the same
script. The cost and the benefit are both different from what was written, so
L3 is not in this landing, and the consequence of its absence is now written
down rather than left implied: a consumer's requires-interfaces is still only
trusted.

Co-authored-by: Claude Code <noreply@anthropic.com>

Author: speak-agent

.agents/docs/2026-09-20-openkal-c-environment-ecosystem-design.md

@@ -504,6 +504,33 @@ L3 把这次失败从"某个用户的某个目标"提前到"包作者自己的
 少用（声明了没用的）是**提示**而不是错误——一个包可以按 feature 或按目标条件地使用
 某个接口，当前这次解析里没用到不代表声明是错的。
 
+**更正(2026-09-20，落地时发现)：L3 的代价被这份设计低估了。** 上文写 L3 的机制是
+「取消费者对象的未定义符号、与 `SURFACE.txt` 求交、映射到接口」——**这要求引擎持有
+符号到接口的映射**，而 §5.5 同时写着「引擎不认识这两个集合的任何一个成员」。两句话
+不能同时成立。
+
+映射只能来自图，因此 L3 的真实形状是实现包再声明一张表：
+
+```toml
+[kernel-abi]
+provides-interfaces = ["openkal.fs", "openkal.stream", ...]
+
+[kernel-abi.interface-symbols]        # 同样由 SURFACE.txt 生成
+"openkal.fs"     = ["kal_fs_open", "kal_fs_close", ...]
+"openkal.stream" = ["kal_stdin", "kal_stdout", ...]
+```
+
+这张表在每个实现的清单里约一百行，由同一个脚本生成，引擎只做「未定义符号 → 它属于
+哪个接口 → 该接口在不在消费者的声明里」这一串查表与集合差，仍然不认识任何名字的含义。
+
+代价与收益都变了，因此 L3 **不在本轮落地**，并且它的缺席有一个必须写下的后果：
+
+> `requires-interfaces` 在消费者一侧**目前只被信任**。一个包可以声明少于它实际调用的
+> 接口，解析期通过，在提供该接口的实现上链接也通过——只有在不提供的实现上才会炸，
+> 而那时错误出现在**用户的目标上**，不在包作者自己的构建里。
+
+这正是 §5.7.3 说 L3 要消除的那件事，它今天还在。
+
 #### 5.7.4 风险边界：写错不会静默
 
 这是"这两个事实可以由声明承载"的根据——不是因为声明可信，而是因为**每一种写错都响亮**：