docs(plan): the validation item gets a criterion and a slot, and that criterion was wrong

Review pass over the whole document. Three findings, one of which is a defect
in a criterion rather than an omission.

OMISSION -- the validation experiment had neither a criterion nor a stage. It
was described at length in section 10 and then appeared in neither the criteria
table nor the staging table, so nothing tied it to the rest of the plan. Added
as C9 and as a staging row with 13.1 explaining where it sits.

DEFECT -- C9's decisive criterion, "git diff src/ is empty", cannot tell two
failures apart:

  * the diff carries an Ascend-specific identifier   -> the claim is refuted
  * the diff is a general capability like exports    -> the engine is merely
    missing general infrastructure, which is what sections 2-6 exist to add

Both read the same, so running it before the general gaps land would report the
second as the first. Replaced by two levels: the primary criterion is that
test_core_vendor_probes.cpp stays green after the port, which judges by
property rather than by whether anything changed and therefore needs no
precondition; "git diff src/ empty" is kept as a stricter additional statement,
valid only after stages one to three.

That also unblocks running the experiment early: the primary criterion works at
any time, and an early run may surface a fifth general gap, which is cheaper
than discovering it after three stages of engine work.

ORPHAN -- kind = "device" appeared once, in the attribution table, with no
criterion and no stage. It sits in a cross box: engine-side by test 2, but
domain by the section 0.1 admission line, because it talks about accel. Two
rulers, and they cross. Stated explicitly and scoped to docs/20 rather than
left ambiguous.

Also marked the superseded half of revision two in the change record, so a
reader scanning the log does not take an overturned conclusion as current.

Author: speak-agent

.agents/docs/2026-09-07-general-build-infrastructure-gaps-design.md

@@ -343,6 +343,11 @@ Fortran,数值栈的一大块进不来。
 | 2 | 它是否改变**产物是什么**(符号面、包内布局、身份)? | **引擎**。packer、索引、消费者三方必须就此达成一致,而这种一致无法住在插件里 |
 | 3 | 它是否**新增一种边或节点**? | **引擎**。插件声明边,不发明边的种类 |
 
+三条测试判的是**引擎侧还是插件侧**,不判**通用还是领域**。后者由 §0.1 的准入线判。
+两把尺子会交叉,`kind = "device"` 就落在交叉格里:它是引擎侧(测试 2),但它谈的是
+`accel`,按 §0.1 的准入线属**领域**。因此它**不在本文的缺口清单、判据与分期里**,
+归 docs/20;此处列出只是为了让归属表完整。
+
 应用到已识别的各项:
 
 | 项 | 归属 | 触发的测试 |
@@ -353,7 +358,7 @@ Fortran,数值栈的一大块进不来。
 | `accelerator = "none"` | 引擎 | 3(谓词词表) |
 | 生成输入粒度 | 引擎 | 3 |
 | Fortran | 引擎 | 3 |
-| `kind = "device"` | 引擎 | 2 —— 它让 `mcpp pack` 能**测量**出 `accel` 而不是抄声明 |
+| `kind = "device"` | 引擎,但**属领域侧**(见下) | 2 —— 它让 `mcpp pack` 能**测量**出 `accel` 而不是抄声明 |
 | 探测库 | 插件/包 | 1 |
 | **RDC** | **插件** | 均不触发(见 §0.2) |
 | `.omp` 岛、`.stdpar` 岛 | 插件 | 1 |
@@ -625,15 +630,35 @@ Triton IR → Linalg IR → AscendNPU IR → 算子二进制,配套 `triton-asce
 
 ### 10.5 裁决判据
 
-阶段一(`rules-ascendc` + 一个 hello kernel)两条,第二条是重点:
+阶段一(`rules-ascendc` + 一个 hello kernel)两条:
+
+1. **设备执行。** 在 `sim` 模式下跑出正确结果,**断言设备名/执行路径而非结果数值**
+   (数值在 `cpu` 模式与静默回退时同样正确)。**不得用 `cpu` 模式充当这条** ——
+   理由见 §10.3.1。`sim` 调用 `bisheng` 已证实,因此这条落在正确的对象上。
+2. **引擎无厂商知识。** 见下,这条初稿写错了。
+
+#### 10.5.1 第二条判据的更正:`git diff src/` 为空分不开两种失败
+
+初稿把它写成"`git diff src/` 为空"。**这个判据的"否"有两个成因,而它分不开:**
 
-1. 在 `sim` 模式下跑出正确结果,**断言设备名/执行路径而非结果数值**(数值在 `cpu`
-   模式与静默回退时同样正确)。**不得用 `cpu` 模式充当这条** —— 理由见 §10.3.1。
-   `sim` 调用 `bisheng` 已证实(§10.3.1),因此这条判据落在正确的对象上。
-2. **`git diff src/` 为空。**
+| 若 `src/` 有改动 | 含义 | 是否推翻主张 |
+|---|---|---|
+| 改动里出现昇腾专有标识 | 引擎吸收了厂商知识 | **推翻** |
+| 改动是 `exports` / `link-flag` 这类**通用**能力 | 引擎缺一项通用基础设施 | **不推翻** —— 那正是 §2–§6 在补的东西 |
+
+两者读数相同,所以这条判据在通用缺口落地**之前**跑,必然把第二种误报成第一种。
 
-第二条为否,即"这条架构主张在第一个陌生厂商面前就没成立"。这个结论比移植成功更有
-价值,也更该早点知道。
+**更正后的两级判据:**
+
+| 级 | 判据 | 何时可跑 |
+|---|---|---|
+| **主** | 移植完成后,`tests/unit/test_core_vendor_probes.cpp` **仍然绿** —— 它以文件数为分母,断言 `src/` 去注释后不含厂商工具名 | **任何时候**。它按性质判定,不按有没有改动判定 |
+| 严 | `git diff src/` 为空 | 仅在 §13 的一、二、三期落地**之后**才有意义 |
+
+主判据才是这条架构主张的直接检验,而且它不需要前置。严判据是附加的更强陈述。
+
+主判据为否 —— 即为了让昇腾跑起来,不得不把厂商标识写进 `src/` —— 那就是"这条架构
+主张在第一个陌生厂商面前没有成立"。这个结论比移植成功更有价值,也更该早点知道。
 
 ### 10.6 范围警告
 
@@ -668,6 +693,7 @@ Triton IR → Linalg IR → AscendNPU IR → 算子二进制,配套 `triton-asce
 | C6 | 探测库在一台**没有宿主编译器**的机器上仍能完成探测。这是 §5.2 唯一能证伪的判据 |
 | C7 | 声明 `cfg(accelerator = "none")` 的回退源码,在 `accel` 为空时编译、在任意后端被命名时不编译;**且新增一个后端后该谓词的行为不变** —— 这条才是本项的理由,单后端下绿零信息量 |
 | C8 | 一个包同时具备生成头与千级编译边时,生成头**不**阻塞与它无关的编译边。对照组是今天的包级栅栏 |
+| **C9** | **验证项(§10)。** 昇腾切片移植完成后:(a) `test_core_vendor_probes.cpp` 仍绿 —— 主判据,按性质判定,任何时候可跑;(b) `sim` 模式下跑出正确结果且**断言执行路径而非数值**;(c) 四项通用缺口够用,否则暴露的第五项本身就是产出。**不得用 `cpu` 模式充当 (b)** —— 它不走岛(§10.3.1) |
 
 **Fortran(§6.3)没有判据,因为本文没有给它设计。** 这是有意的:一个没有设计的条目配上
 一条判据,会让它看起来比实际成熟。它在 §13 里也不占期次。
@@ -688,16 +714,33 @@ C6 值得单独说明:它是这批里唯一无法在开发机上验证的判据
 | 五 | 生成输入粒度 | 触发条件明确(§6.2),未达到该规模前不做 |
 | — | Fortran | 已识别,本文不给设计 |
 | 并行 | RDC(`rules-cuda`)、`.omp` 岛 | 插件侧,不依赖以上任何一项 |
+| **验证** | **昇腾切片(§10)** | 见下 |
 
 一、二、三期合计的引擎改动量小于 RDC 一项,且互不阻塞。RDC 归插件侧之后,**关键路径
 上不再有大件**。
 
+### 13.1 验证项的位置
+
+**主判据(C9a)不依赖任何一期,随时可跑。** 它按性质判定 —— 移植后 `src/` 里有没有
+出现厂商标识 —— 而不是按有没有改动判定。
+
+**严判据(`git diff src/` 为空)必须在一、二、三期之后。** 在那之前跑,一次"缺通用
+能力"会被误读成"引擎吸收了厂商知识"(§10.5.1)。
+
+因此推荐的顺序是:**一、二、三期落地 → 昇腾切片**。但如果想更早拿到信息,只跑主判据
+也是有效的,而且它可能提前暴露第五项通用缺口 —— 那种情况下,缺口清单本身就被验证
+补全了一次,这比等到三期做完再发现要便宜。
+
+**这一项不是引擎工作量,是判断整套设计对不对的实验。** 它的产出是一份带判据的报告
+加一个规则包(§10.6),不是一个要长期维护的 fork。
+
 ## 14. 变更记录
 
 | 版本 | 变更 |
 |---|---|
 | 初稿 | 四处通用缺口:`exports`、`link-flag`、包内布局、探测库。配置头与包内布局在核实 main 后各自缩小 |
 | 修订一 | 两处判断被推翻并就地更正:**RDC 归插件侧,引擎零改动**(§0.2);**stdpar 可岛化,初稿的"互斥"说法过头**(§8.1)。新增三处缺口(§6)、归属规则(§7)、编程模型三分法(§8)、术语对齐建议(§9)、以及用陌生厂商证伪的实验(§10) |
-| 修订二 | §10 的三处不确定实地调研(§10.3),两处证实一处未证实。第三处更正:**"有硬件或模拟器"不是开工硬闸**,架构验证完全在构建期(§10.4);真实前置只有毕昇的合规取得。新增两条实测结论:`cpu` 模式**不走岛**因而不能充当设备判据(§10.3.1),以及 CMake 把 Ascend C 当作一门语言 —— 同一条轴、不同归属的第三方佐证(§10.3.4) |
+| 修订二(第三处结论已被修订三推翻) | §10 的三处不确定实地调研(§10.3),两处证实一处未证实。第三处更正:**"有硬件或模拟器"不是开工硬闸**,架构验证完全在构建期(§10.4);真实前置只有毕昇的合规取得。新增两条实测结论:`cpu` 模式**不走岛**因而不能充当设备判据(§10.3.1),以及 CMake 把 Ascend C 当作一门语言 —— 同一条轴、不同归属的第三方佐证(§10.3.4) |
 | 修订三 | §10.3.3 的结论被**推翻**:工具包官方镜像 `swr.cn-south-1.myhuaweicloud.com/ascendhub/cann` **可匿名拉取**(走完 token 握手实测),且从厂商自有 registry 取正落在不变量允许的一档。同时纠正一个框架错误:毕昇与模拟器**在同一个包里**,是一个获取问题不是两个。**至此该实验没有阻碍项。** 另记 AscendNPU IR 已开放,规则包存在第二个切入高度(§10.3.3b) |
+| 修订五 | 综合复核。两处补齐:验证项此前**既无判据也无期次**,现补为 C9 与 §13.1;`kind = "device"` 此前是孤儿条目,现按"两把尺子"说明它落在引擎侧但属领域,归 docs/20。一处更正:C9 的严判据 `git diff src/` 为空**分不开两种失败**(吸收了厂商知识 vs 缺一项通用能力),改为两级判据,主判据用既有的 vendor-probe 测试(§10.5.1) |
 | 修订四 | 最后一条待确认项闭合:`sim` **确实调用 bisheng**,由 `asc-devkit` 内 vendored 的 `ASC_CMake` 证实 —— ASC 是一门 CMake 语言,其编译器就是 `bisheng`,且**全仓 `RUN_MODE` 判断只区分 `cpu` 与非 `cpu`,不存在 `sim` 分支**。至此 §10 无待确认项 |