test(criteria): 闭环——判据自报条数 + 每文件期望条数（只增不减的棘轮）

pi 指出的残余缺口：我上一轮加的自检 4 是**文本证据**（文件里有 `test(` / `check(` /
`process.exit(1)`），只能证明"**有能红的路径**"，不能证明"**它跑过**"。反例很短：

```js
const check = () => {};     // 实现被换空（现实形态：合并冲突改坏实现）
check('a', false);          // 存在、也执行了，但什么都不会红
console.log('主题：通过');   // 有输出
```

## 落地（pi 给的闭环形状）

1. 自定义 `check()` 的判据结尾打一行机器可读汇总 `RESULT pass=<条数> fail=<失败数>`
   （`node:test` 的判据不用改，已有 `# pass N`）；
2. `run-all.mjs` **只解析这个固定 marker**（不猜口语汇总——「窄屏布局：全部通过」里没有数字，
   按数字猜会误报，这一点我上轮已经实测过）；
3. 与清单里登记的**期望条数**比对，**低于 → 红**。

关键细节：**计数写在 `check()` 内部**（theme/background 原本就在内部 ++；
narrow-layout 只有 failed 计数，补了 passed；markdown-xss 按 payload 条数算）。
写在调用点或靠扫源码的话，"实现被换空"就看不见了。

棘轮"只增不减"：加判据**不用**改那个数，只有"条数掉了"才红。期望值按**实测**回填
（9/52/8/30/42/15/28/5/23/5/3/2）。

附带的可见性收益：这几轮我一直用"13→14""19→28""34→42"当信号，现在它成了判据 ——
某次改动顺手删掉两条判据、或某条被跳过，会立刻红。

## 变异

- pi 那个反例（`check` 换成空函数）→ 红（`自报 0 条 < 登记的 30 条`）；
- 删掉 5 条 `check(` 调用 → 红（`自报 47 条 < 登记的 52 条`）。

## 规范

§6.5 新增"涉及运行时行为的结论必须实测过才能写进规范/判据"——同一个错这轮犯了两次
（我从"报告 0 个测试、退出 0"推断"退出码被吞"，实测是照传；pi 拿我这个结论又建了一个洞）。
规则：**一次观察只支撑你看到的那一层**。
§6.6 记闭环形状与代价（故意删判据要同步改数字，属于一次可复核的显式编辑）。

⚠️ 并且如实记下一次**我自己违反规范**的事：写 §3 那条"变异后别用 `git checkout` 还原"的人
（就是我）在这次变异验证里又用了 `git checkout -- <文件>`，把刚加、尚未提交的 marker 抹掉了。
规矩写下来不等于会遵守 —— 已把这条实例写进规范，让人知道它是活人踩的坑。

## 验证

`npm test` 退出码 0（12 个判据文件全绿 + vitest 258/258）；`run-all` 单独跑也 exit 0。

client/electron/test/CRITERIA.md

@@ -121,6 +121,48 @@ const ALLOW = [ /* { name, replacement, why } */ ];
   `process.exit(1)` 吞掉**，于是"变异后依然 exit 0"看起来像判据失效（本仓刚踩过这一次：
   自检 3 其实是好的，是我用错了入口去验它）。**验判据要模拟用户/CI 真正跑的那一行。**
 
+## 6.5 涉及**运行时行为**的结论，必须实测过才能写进规范/判据（pi 2026-09-14）
+
+同一个错在本仓犯了两次，方向相反但错法相同：**从观察推断机制、没跑**。
+
+- 我从"`node --test test/run-all.mjs` 报 0 个测试、退出 0"这个**观察**，推断出
+  "runner 吞掉了 `process.exit(1)`" —— 实测下来退出码照传（见 §6 末），我错了；
+- pi 拿我那个结论直接往下建了一个洞（"配错 flag = 绿"）—— 他也错了。
+
+规则：**一次观察只支撑你看到的那一层**。"报告里 0 个测试"是真的，"退出码被吞"是推断的。
+凡涉及运行时行为的结论（退出码、计数、回调时机、事件触发），
+**先贴真实样本再写规则** —— 这也是 §1 的推论。
+
+## 6.6 闭环：自报条数 + 每文件期望条数（只增不减）
+
+文本证据只能到"**存在**"为止：`test(` / `check(` / `process.exit(1)` 的存在性
+证明"有能红的路径"，**不证明它跑过**。反例（现实事故形态：合并冲突把 `check` 的实现改空）：
+
+```js
+const check = () => {};     // 实现被换空
+check('a', false);          // 存在、也执行了，但什么都不会红
+console.log('主题：通过');   // 有输出
+```
+
+所以 `run-all.mjs` 现在做三件事：
+
+1. 自定义 `check()` 的判据**自报条数**：结尾打一行
+   `RESULT pass=<条数> fail=<失败数>`（`node:test` 的判据不用改，已有 `# pass N`）；
+2. runner **只解析这个固定 marker**（不猜口语汇总 —— 「窄屏布局：全部通过」里没有数字，
+   靠猜数字会误报）；
+3. 与清单里登记的**期望条数**比对，**低于 → 红**。
+
+棘轮是"只增不减"：**加判据不用改那个数**；只有"条数掉了"才红 ——
+那正是要看见的事（顺手删两条判据、某条被跳过、`check` 实现被改坏）。
+代价：**故意删判据时要同步改数字**（这是一次显式的、能被复核的编辑，可以接受）。
+
+计数必须写在 **`check()` 内部**：写在调用点或靠扫源码，"实现被换空"就看不见了
+—— 上面那个反例的 `pass` 会是 0，正是靠这一条才有分辨力。
+
+> ⚠️ 本节的作者在写完之后**又踩了一次 §3 那条**：变异验证时用 `git checkout -- <文件>`
+> 还原，把尚未提交的改动（刚加的 marker）一起抹掉了。**规矩写下来不等于会遵守**；
+> 变异前先 `cp` 备份，从备份还原。
+
 ## 7. 判据要钉用户真正会点的那一层
 
 （移交信里交代的头号纪律）判据通过了但用户点不到，等于没做。