docs(versions): 补登三条提交与仪器陷阱

依据 = `rulings.md` **§C59.6**（采纳 **P-31**：vitest `--outputFile` 异步写盘）+ **§C59.11**（**时序假警报**的驳回与纪律）+ 控制方裁决里的 **P-32**（PowerShell `Set-Content -Encoding UTF8` 写出 BOM ⇒ commitlint 拒绝提交）与 **P-33**（`update-ref` 静默失败 ⇒ 一切 ref 移动走脚本并验退出码）。
形态 = **纯追加**（在 v0.22「跨批发现 · 本机工具链的读数陷阱与门禁真相」节的「陷阱 4」块之后、「工具链真相 1」之前，**新增陷阱 5 / 陷阱 6 两块**；既有各节一字未改）⇒ 本提交 **+13 行 / −0 行**（本提交只含第二批追加）。

【逐字对照：改了哪几行 / 原文是什么】
- **位点**：`v0.22`「陷阱 4 · 批 4 收口新增的五条仪器陷阱…」块与其后的 `**工具链真相 1 · 本地提交门禁此前从未武装…**` 之间。
- **原文（保留，一字未动）**：陷阱 4 的五条 · `**工具链真相 1 · …**` 标题与其正文（含中间那个空行）。
- **加注（新增两块）**：
  · **陷阱 5 · 批 7 收口新增的三条提交/仪器陷阱（台账入册 P-31 / P-32 / P-33）**：① **P-31** vitest `--outputFile` **异步写盘** ⇒ 读到的可能是**上一跑**的读数（T22 首版因此误读、自查后加 **mtime 守卫** ⇒ 🎯 登记为正例）；🔴 **与既有 P17（路径按 `app/` 解析 ⇒ ENOENT 却 `exit 0`）配套**：**读任何 `--outputFile` 产物前先查 mtime** + **路径一律绝对** + **JSON 不可读必须非零退出**。② **P-32** PowerShell 5.1 的 `Set-Content -Encoding UTF8` **写出 BOM** ⇒ commitlint 读成 **`subject may not be empty`** 并**拒绝提交** ⇒ **写提交信息一律用 node `fs.writeFileSync(p, s, "utf8")`**。③ 🔴🔴 **P-33** `update-ref` **必须从独立脚本执行、且必须查退出码** —— T22 实测 PowerShell 传参把 `update-ref` **静默搞失败**而**未查 `$LASTEXITCODE`** ⇒ **表面成功、ref 未动** ⇒ **一切 ref 移动走 node / 文件脚本 + 断言退出码 + 成功后立即 `git rev-parse HEAD` 回读验证**（与陷阱 4 第 4 条同族：**原生命令的静默失败面**）。
  · **陷阱 6 · 「扫描即快照」的推断会系统性误报在飞单元**：事实 = 某侦察单元主张「T22 的收口件不在盘上 ⇒ 从未落盘」并据此 STOP；控制方实测**扫描当时 `tmp/t22/` 三目录 mtime `2026-09-13T03:53`** ⇒ T22 **仍在运行**，两件随后 **04:04:39 / 04:05:27** 落盘 ⇒ 🔴 **不是「从未落盘」，是「尚未落盘」**（该判定与派生项作废）。T21 于终态回写时实测两件均在盘（**109,327 B / 693 行** 与 **41,469 B / 323 行**）。🔴 **纪律**：**对「某产物不存在」的判定必须排除「正在被生成中」** —— 至少查**同名目录 / 文件的 mtime** 或**该单元是否仍在飞**；**本仓并行度高，「扫描即快照」会系统性误报在飞单元**。

【门禁读数（串行，工作树；与基线逐条对账）】
- `docs-check` ⇒ **exit 0** ·「扫描 **281** / 检查 **181**，五项全 ✅」⇒ 与基线 **281/181 逐字一致**
- `line-limits --full` ⇒ **exit 0** ·「>600 硬限 **0** · 301–600 档 **121** · 登记条目 **121**」⇒ 与基线**逐字一致**
- `check-command-registry` ⇒ **exit 0** ·「定义 **311** / 注册 **311** / 重复 **0**」⇒ 与基线**逐字一致**
- `git diff --numstat`（本提交口径）⇒ **13 / 0**；`git diff` 的 `^-` 行数 = **0**；🔴 **纯空白行删除 = 0 行**
- 🔴 **结构自证**：标题**子序列校验** = **被删/被改 0 处 · 新增 0**（本提交不新增标题）

【诚实边界】
- 🔴 **P-31/P-33 的「实测」引自 §C59.6 / 控制方裁决与 T22 报告**，T21 **未独立复现**（复现需要跑 vitest `--outputFile` 与一次失败的 `update-ref`；后者是**破坏性动作**，**不在只改文档的单元权限内**）。
- 🔴 **本提交的 13 行是「第二批追加」**：它在上一条提交（`docs(versions): 回写批 7 的终态八闸与懒侧基线`）之上叠加，两处追加的**内容边界**由 §C18.2 的 **blob 构造**保证（中间 blob 已存档为 `tmp/t21/v022-partial.md`，事件证据 `tmp/t21/v022-second-addition.md`）。
- ⚠️ **本轮实施中我曾误删一个空行**（`**工具链真相 1**` 标题与其正文之间），**提交前自查发现并恢复** ⇒ 除「标题子序列对拍」外，本轮另加了一道 **「纯空白行删除 = 0」** 的检查。**该事故与修复逐字登记在报告中。**

Author: Aparencia

docs/versions/v0.22.md

@@ -994,6 +994,18 @@
 4. 🟡 **`git commit --only -- <paths>` 会提交未暂存的改动**（与 `git add --` 的直觉不同）：提交前必须 `git status --porcelain` 确认工作树里**只有要提交的那些文件**（记录形态，不是缺陷）。
 5. 🟡 **`core.autocrlf=true` 下新写文件的 LF 警告不影响行数**：`warning: LF will be replaced by CRLF the next time Git touches it`；实测提交 blob 与工作树**都是 0 个 CRLF**（`git show HEAD:<path>` 的 `\r\n` 计数 = 0），**行数读数不受影响**。
 
+**陷阱 5 · 批 7 收口新增的三条提交/仪器陷阱（2026-09-13，T22 实测 + 控制方采信；台账入册 P-31 / P-32 / P-33）**
+
+1. 🔴 **P-31：vitest `--outputFile` 是异步写盘 ⇒ 读到的可能是**上一跑**的读数**：T22 **首版因此误读，自查后加 mtime 守卫** ⇒ 🎯 **登记为正例**（自查 + 修复 + 上报）。🔴 **与既有「陷阱 4 第 1 条」（**P17**：`--outputFile` 的相对路径按 `app/` 解析 ⇒ 断言器 ENOENT 却仍 `exit 0`）**配套使用**：⇒ **纪律 = 读任何 `--outputFile` 产物前先查 mtime**；**路径一律绝对**；**JSON 不可读必须非零退出**。两条合起来才封住「无证据的绿」。
+2. 🔴 **P-32：PowerShell 5.1 的 `Set-Content -Encoding UTF8` 会写出 BOM** ⇒ commitlint 把它读成 **`subject may not be empty`** 并**拒绝提交**。⇒ **纪律：写提交信息一律用 node `fs.writeFileSync(p, s, "utf8")`**（或 `git commit -F` 读 node 写出的无 BOM 文件），**不要**用 `Set-Content` / `Out-File -Encoding UTF8`。
+3. 🔴🔴 **P-33：`update-ref` 必须从独立脚本执行、且必须查退出码** —— T22 实测：**PowerShell 传参把 `update-ref` 静默搞失败**，而它**没有查 `$LASTEXITCODE`** ⇒ **表面成功、ref 未动**（最危险的一类：自证看起来通过、提交其实不存在）。⇒ **纪律**：**一切 ref 移动走 node / 文件脚本**，**断言退出码**，**成功后立即 `git rev-parse HEAD` 回读验证**。（与「陷阱 4 第 4 条」`git commit --only` 的形态同族 —— 都是**原生命令的静默失败面**。）
+
+**陷阱 6 · 「扫描即快照」的推断会系统性误报在飞单元（2026-09-13，批 7 收口；控制方驳回一次 STOP 后登记）**
+
+**事实**：批 7 的一个侦察单元主张「T22 的收口件（`task-22-report.md` / `closing-review.md`）**不在盘上** ⇒ T22 跑过但报告**从未落盘**」，并据此提出 STOP。
+**控制方实测（决定性）**：扫描当时 `tmp/t22/` 已含 `lib/` `logs/` `trees/` 三目录、**mtime `2026-09-13T03:53`** ⇒ **T22 仍在运行**；两件随后于 **04:04:39 / 04:05:27** 落盘 ✅ ⇒ 🔴 **不是「从未落盘」，是「尚未落盘」**（该判定与其派生项一并作废）。T21 于终态回写时实测两件均在盘（**109,327 B / 693 行** 与 **41,469 B / 323 行**）。
+🔴 **纪律**：**对「某产物不存在」的判定，必须排除「该产物正在被生成中」这一可能** —— 至少查**同名目录 / 同名文件的 mtime**，或**该单元是否仍在飞**。**本仓并行度很高，「扫描即快照」的推断会系统性误报在飞单元**（本条与「诚实边界」里那句「**未判定 ≠ 不存在**」同族）。
+
 **工具链真相 1 · 本地提交门禁此前从未武装（2026-09-11，批 0-C1 Task 4 发现，已修正）**
 
 本克隆此前**从未安装 husky** —— `core.hooksPath` **为空**、无 `.git/hooks/pre-commit`、无 `node_modules` ⇒ `.husky/pre-commit`（lint-staged）与 `.husky/commit-msg`（commitlint）在本机**对所有提交都是静默失效的**：不只是某个批次，而是**历史上每一次提交**，**包括批 0-A / 0-B / 0-C1 的全部交付提交**（旁证：控制方在本会话提交 40+ 次，从未见过任何 lint-staged / commitlint 输出）。⇒ **新克隆若未 `npm install`，门禁默认失效且无任何提示**（不报错、不警告，提交照常成功）。