docs(plan): 回填第八条 —— 生态验证挖出的 DT_RPATH 继承缺陷

Author: speak-agent

.agents/docs/2026-09-07-package-identity-and-doc-alignment.md

@@ -330,6 +330,30 @@ manifest 注释,因为它是唯一能回答「为什么这个还要我写」的
 注释里,是「同一份 manifest 的两条**轴**」。跨包的版本分歧是另一件事,而告警码是给机器
 读的分类。新码是 `xlings/version-override`。
 
+### 10.8 生态验证顺手挖出一个引擎缺陷:`DT_RPATH` 的继承没被建模
+
+为了让 `rules-ascendc` 的诊断真的被编译一次(五个夹具没有一个激活它),我拿 cann 示例
+跑了一遍。它被拒绝了,消息点名**八个**库找不到。
+
+**而它刚刚链接出来的那个产物,把其中七个都解析掉了** —— 直接跑一次,加载器只在第八个
+上失败,那一个属于这台机器没有的驱动。模型与加载器给出相反的读数。
+
+真因:`DT_RPATH` 被整条依赖链继承,`DT_RUNPATH` 不被继承;而闭包模型只查**发起请求
+的那个对象自己**的搜索路径。厂商工具包恰好是最坏的形状 —— 库与库之间按裸 SONAME 互相
+依赖、自己都不带搜索路径,而它们所在的目录只写在**可执行文件**的 `DT_RPATH` 里。
+
+三条值得记下来的:
+
+1. **这与本轮的身份工作无关,是既有缺陷**。用已发布的 2026.9.6.5 加已发布的 plugins
+   0.2.3 复现,读数一字不差 —— 先做这个对照,再动手。
+2. **它只在「跑一次」时暴露**。构建被拒绝,而拒绝消息本身是自洽的;唯一能分开「模型对」
+   和「加载器对」的动作,是执行那个产物。
+3. **抑制的那一半必须一起写**:带 `DT_RUNPATH` 的对象不使用任何 RPATH,自己的和继承的
+   都不用。只写正向那条,一个无条件继承的实现同样通过。
+
+⭐ 更一般的形状:**为了让一段没人跑过的代码被编译一次而去跑它,挖到的往往不是那段代码
+的问题。** 五个夹具覆盖五条规则里的四条,而第五条一次都没被编译过。
+
 ### 10.7 落地顺序(不可交换)
 
 | # | 仓库 | 内容 | 前置 |