第六、七轮：离线 ort/WebGPU、R9 查看器整周期、安全层截止下沉、enc_once 前瞻 bug（feat 动态轴）、UTF-8、断点 RNG 续跑与 --stop-at、R2 池无关性自检、R8 出题缓存、本机自检 selftest、冒烟 smoke；遗留清单并入审查文档第六节

docs/ML运行手册审查.md

@@ -82,3 +82,100 @@ tickGapMax 全部 ≈21.5 ms（20 ms 节拍没被卡住）。背景：第五轮
 1. ~~A 组修复并重跑 `r4`~~：已完成（本机 2026-10-18，rc=0、P99 11.25）。
 2. 接着 `FROM=gen TO=prep` 跑一次（数小时），拿 `gapDrop` 与 R2 两个口径的数——C-2 / C-3 随之消掉，B-2 的 Node 侧安全层数字可顺手从 m5 前的 bench 拿。
 3. B 组等上面的数字齐了再定；C-1 / C-5 / C-6 随第一次真跑逐项核对；A-3（离线 ort 加载）交给实现方。
+
+---
+
+## 五、实现方处置（第六轮，2026-10-18）
+
+逐条对应第二部分。分歧按第五轮第〇节规则以实现方为准，下一轮用实测数据定。
+
+**A-3 离线 ort 加载**：已修。`ik-policy-glue.js` 与 `r4_probe.html` 的本地前缀改为绝对 URL（`new URL('vendor/ort/', location.href)`），ORT 的 `import()` 不再把它当裸模块名。新增 `ml/prep/vendor_ort.sh`（`setup` 与 `r4` 自动调用）用 `npm pack onnxruntime-web@1.20.1` 把 `ort.min.js`、`ort.webgpu.min.js` 与两套 wasm/mjs 放进 `webapp/vendor/ort/`（33 MB，`.gitignore`）；探针检测到本地副本就默认用它，不再依赖间歇不可达的 jsdelivr（`ORT_LOCAL=0` 强制 CDN）。
+
+**GBK 兜底**：除了本机已补的 7 处，`pipeline.sh`、`console.bat`、`console.sh`、监控起的子进程统一 `PYTHONUTF8=1`，所有 Python 读写默认 UTF-8，不再逐处补 `encoding`。
+
+**B-1 R4 口径**：R4 保持纯推理判据（随机权重只代表推理开销，这点不变）。整周期另立 **R9**，用**训练好的模型**在**真查看器**里测：`python -m ml.eval.r4_probe --viewer`（`bench` 阶段自动跑，写 `ml/runs/r9_browser.json`），查看器 `&autotest=30` 跑与 Node bench **同种子同题**的 30 道贴柱题，判据 **整次规划 `planP99` < 45 ms 且饥饿节拍 < 1%**（饥饿 = 执行时钟到点时队列为空 = 实际丢步）。`r4.json` 另带 `viewer_ref`（随机模型的同一测试），只作参考不判定——随机策略几乎每次都要认证多条候选，安全层路径不代表真模型。验收汇总加 R9 一项。方案 R9 行同步改写（原"安全层 P99 < 5 ms"不可测也不对口径）。
+
+**B-2 安全层两把尺**：找到了原因，而且 Node 侧也一样慢，不是浏览器独有。沙箱 Node 单次调用：`gapMatrix` cap20 **3.6 ms** / cap40 **5.5 ms**、`collideFree` 1.5 ms、`criticalPairs` 3.1 ms，而推理只有 **1.5 ms**——**耗时在几何查询，不在模型**。具体三处：
+1. 截止只在候选之间检查，单条候选内部最多 40 次查询（≈150 ms）不受限 → 墙钟截止下沉到认证递归内部：第 1 条候选截止 45 ms，其余共享到 30 ms，到点判不过（`certFailWhy.time`），沿已认证刹停段停，安全性不变。
+2. `safetyMs` 从推理结束开始计，**把前瞻（第二次推理 + 8 份特征 = 8 次 gapMatrix cap40）算进去了** → 拆成 `lookaheadMs` / `safetyMs` / `planMs` 三项分别记。
+3. 前瞻在"卡死"时也触发，随机或差的策略几乎一直卡死 → 改为只在冷启动（新目标 / 目标跳变）前瞻，与仿真 `closed_loop.py`（只在首块前瞻）对齐；卡死由换向锁处理。
+沙箱 Node、同 2 道贴柱题、小模型实测（同一机器前后对比）：安全层 P99 **200.9 → 51.9 ms**，前瞻 P99 126 → 83 ms（只剩冷启动那几次），整次规划 P99 **236.7 → 63.3 ms**（P50 57.5）。代价是沙箱上 `time` 截止判不过占多数、刹停多（2 vCPU 上每次 gapMatrix 约 4 ms，45 ms 只够约 10 次查询；未训练小模型本身也差）——你机器单核快 2× 左右，真模型候选第 1 条通过率高，R9 以本机实测为准；若本机 R9 仍不过，下一轮把几何查询（特征、投影、认证）整体搬进 Worker，主线程只执行。
+另外 bench 与查看器都记 `certQueriesP99`、`certMemoHitRate`（沙箱 0.69–0.72）、`certFailWhy`；验收加"同题安全层 浏览器 / Node ≤ 3×"一项。
+
+**顺带发现并修掉一个真 bug**：第五轮 `enc_once` 后，前瞻的 8 行特征**各不相同**，但 `ortInfer` 只送了第 1 行 → 8 个候选的前瞻价值全是同一个观测算的，冷启动时的候选排序等于随机。现在 ONNX 的 `feat` 轴改为动态（1 行 = 主推理编码一次；K 行 = 前瞻逐行编码，`meta.feat_dyn=true`），导出时对拍 8 行不同特征与 `sample()` 一致（2e-7 量级）；第五轮导出的旧模型运行时自动退化为逐行推（正确但慢）。**你本机的 r4 模型需重新导出**（`bash ml/pipeline.sh r4` 会重导）。
+
+**B-3 WebGPU**：`backend not found` 的直接原因是 `ort.min.js` 里**没有 WebGPU 后端**（只在 `ort.webgpu.min.js`）。查看器与探针在 `ep=webgpu` 时改载 `ort.webgpu.min.js`；探针先记 `navigator.gpu` 与适配器信息（区分"没有 GPU"与"包不对"）；WebGPU 配置改用有界面窗口打开（无头模式拿不到真适配器），跑完自动关。
+
+**D**：`webapp/models/README.md` 已改为 fp32、第 10 步、新输入签名。
+
+**C 组**：第七轮已处置，下一步见第六节。
+
+## 六、实现方处置与待本机验证（第七轮，2026-10-18）
+
+本节是遗留问题的**唯一清单**：不需要计算的已在代码里修完（「本轮已修完」）；需要计算的只有一条技术验证命令（「本机技术验证」），由你的 PC 跑，沙箱不跑；做法已全部定下（「已定的做法」）；需要你确认的写在「还需要你确认的」。
+
+---
+
+### 6.1 本轮已修完（不需要计算）
+
+| 遗留 | 处置 | 位置 |
+|---|---|---|
+| A-3 离线 ort 加载失败 | 本地前缀改绝对 URL；`ml/prep/vendor_ort.sh` 放好 ort 本地副本，探针默认用本地、不依赖 CDN | `ik-policy-glue.js`、`r4_probe.html`、`vendor_ort.sh` |
+| GBK 读中文 json | 全流程 `PYTHONUTF8=1`（pipeline / console.bat / console.sh / 监控子进程） | `pipeline.sh` 等 |
+| B-1 R4 口径 | R4 仍判纯推理；整周期另立 R9（真查看器、训练好的模型、与 bench 同题：`planP99` < 45 ms、饥饿 < 1%），验收加 R9 | `r4_probe.py --viewer`、`acceptance.py` |
+| B-2 安全层两把尺 | 原因定位：几何查询慢（gapMatrix 3.6–5.5 ms/次），不是模型。截止下沉到认证内部；耗时拆 4 项记录；前瞻只在冷启动；验收加"同题浏览器 / Node ≤ 3×" | `ik-policy.js`、`policy_bench.cjs` |
+| 前瞻 bug（新发现） | enc_once 后前瞻只送 1 行特征 → feat 轴改动态（`meta.feat_dyn`），导出对拍 K 行 | `policy.py`、`export_onnx.py` |
+| B-3 WebGPU 零数据 | 根因：`ort.min.js` 不含 WebGPU → 改载 `ort.webgpu.min.js`；有界面窗口测；记录适配器信息 | 同上 |
+| C-3 R2 池无关性 | 每次 R2 自动以 4 倍池再测一次，记 `pool_check.independent`（差 < 0.02） | `check_r2.py` |
+| C-4 R8 出题耗时 | 出过的题按碰撞指纹缓存，`policy_bench.json` 记 `genS`、`casesCached` | `policy_bench.cjs` |
+| C-5 / C-6 本机生命周期与续跑 | 新增一条命令自检（见「本机技术验证」 V1） | `ml/selftest.sh`、`ml/selftest_proc.py` |
+| C-1 第 7–13 步零实测 | 靠断点续跑兜底（V1 验证），正式训练分三段跑、出错从该阶段续；另备 `ml/smoke.sh` 全流程冒烟，不必跑 | `ml/smoke.sh`、`configs/smoke.json` |
+| 续跑后数值不一致 | `last.pt` 存 torch / CUDA / random 随机数状态，续跑 batch 顺序与一口气跑完一致 | `ml/common/ckpt.py` |
+| D 模型目录说明过时 | 已改（fp32、第 10 步、新签名） | `webapp/models/README.md` |
+
+沙箱只做了语法检查与几秒级的对拍，**以上全部以你本机结果为准**。
+
+---
+
+### 6.2 本机技术验证（只验可行性与意外，不做正式训练）
+
+一条命令，5–10 分钟，在仓库旁的副本目录里跑，不碰本仓库的数据与产物，跑完副本可删。
+
+| # | 命令（Git Bash，仓库根目录） | 耗时 | 回传 | 验证什么 |
+|---|---|---|---|---|
+| V1 | `bash ml/pipeline.sh selftest` | 5–10 分钟 | `ml/runs/selftest.json` | 意外中断能否恢复：gen 截断续写、prep 二次运行、训练 STOP / 续训、APG 续跑；Windows 进程：控制台停止能否杀净整棵树、关掉黑窗口后流程是否继续、TERM 能否送到 python |
+
+判读：`all_pass = true`。没过就把文件发我，不用排查。
+
+不单独跑全流程冒烟：V1 通过即证明断点续跑可靠，正式训练中途某一步出错时，已完成的阶段与训练进度都保留，我修完后从出错那一步接着跑（`FROM=<阶段>`），损失只是出错到发现之间的空闲时间。为缩短这段时间，正式训练按"数据 → 训练 → 后训练与评测"三段跑，每段结束看一眼（见「正式训练」）。`ml/smoke.sh` 保留在仓库里，不作为必跑项。
+
+---
+
+### 6.3 已定的做法
+
+| 事项 | 定为 |
+|---|---|
+| R9 通过线 | 整次规划 P99 < 45 ms、饥饿节拍 < 1%（60 ms 周期留 15 ms 给渲染） |
+| 浏览器测试 | 有界面窗口（无头拿不到真 GPU） |
+| R9 本机不过 | 几何查询（特征、投影、认证）整体搬进 Worker，主线程只执行 |
+| 训练余量 3 mm、`R2_STRICT`、共识过滤 | 按正式数据段的 `stats.json` / `r2.json` 定：间隙 p10 ≥ 3 mm 保持 3 mm，否则降到 p10；R2 `pool_check.independent = true` 且截距 < 0.10 时打开 `R2_STRICT`；门 1 < 0.90 自动开共识 |
+
+---
+
+### 6.4 还需要你确认的
+
+无。V1 结果回来后，我只按结果改代码；若结果暴露出需要你决定的事，再写进本节。
+
+---
+
+### 6.5 正式训练（以后再跑，不在本轮）
+
+V1 通过后再跑，分三段，每段跑完把回传文件发我：
+
+| 段 | 命令 | 耗时 | 回传 |
+|---|---|---|---|
+| 数据 | `FROM=kin TO=prep bash ml/pipeline.sh all` | 数小时 | `ml/data/stats.json`、`ml/data/r2.json`、`ml/runs/r4.json` |
+| 训练 | `FROM=train TO=m5 bash ml/pipeline.sh all` | 约 3–6 小时 | `ml/runs/m5_gate_*.json` |
+| 后训练与评测 | `FROM=apg TO=accept bash ml/pipeline.sh all` | 约 10–20 小时 | `ml/runs/acceptance.json`、`policy_bench.json`、`r9_browser.json` |
+
+任何一段中途出错：把出错信息发我，我修完后用 `FROM=<出错阶段>` 接着跑，前面的不重做。