exp+fix: 轮次39——backoff=0+cert_batch1 与轮次33 cap 逐项相同(重写批量分支无行为变化)；修 backoff 指标被 eval_cl 显式键列表丢掉

docs/探索日志.md

@@ -47,6 +47,10 @@
   - 待测：`len_w ∈ {0.1, 0.3, 1.0}` 三臂，看行程比能压到多少、到达与时限各付多少。这条杠杆与"到达率"是相互冲突的目标（惩罚行程=主动走慢），所以必须成对汇报，不能只报行程变好。
   - 单位口径要说清：`len_w` 的量纲是"mm 误差 / 一个归一 STEP 的累计行程"，16 步满速在 3 条轴上大约是 48，所以 0.1~1.0 对应的惩罚是 5~50 mm 当量——这是扫这三个值的原因，不是随手取的。
 - 测试 `tests/test_eval_cl.py` 38→40 项、全套 43→45 项（`python -m unittest discover -s tests`，2.2 s 全绿）。GPU 队列顺序：backoff A/B → `--safety 0` 判别 → 候选档位 → 行程惩罚。
+- **等价闸门先过了**：`--backoff 0 --cert_batch 1 --inc_cap 1` 的 256 题与轮次 33 cap（`--cert_batch 0`）**逐项完全相同**（`docs/experiment_round38_backoff0.json` 对 `docs/experiment_round33_cap.json`，把两个 metrics 字典做键并集比较，差异集合为空，含 success 0.523438、time_ok 0.265625、brakes 19.55…）⇒ 轮次 36 我把批量认证分支重写（加缩步档那一段）没有改动任何行为。
+- **两个我自己的操作失误，如实记在这里**：
+  1. 新加的 `backoff` 指标一度在产物里根本没有——`ml/eval/eval_cl.py:run()` 的 `out` 是**自己显式列键**的，不是从 `rollout` 返回的字典通抄，所以我往 `res` 加的 `backoff_mean` 被无声丢掉。已改成从逐题 `per['backoff']` 汇总（`backoff_mean` + `reject_all_mean = backoff+brakes`，后者才是与"原来全拒次数"可比的量）。**教训：加指标要顺着输出链路走到底，别只改生产端。**
+  2. 停后台 GPU 作业时，`TaskStop` 之后 `bash` 脚本链会活下来并继续拉起下一个 python；而 `nvidia-smi --query-compute-apps` 在这台机器上列不出这些 python（只列 ShellHost/wallpaper32 之类），据此判断"卡已空"会误判。我第一次按 PID 杀子进程后，链条 30 秒后又起了一个新的 eval。第二次我按进程树杀，但**把父子关系读反了**（Windows 的 PPID 在父进程已死时是陈旧值），结果误杀了新链的第一臂。正确做法：重启前用命令行正则列出全量候选、数 python 个数确认单租户，重启后再数一次；杀之前先按 `StartTime` 判新旧。backoff 那一臂因此要补跑。
 
 ## 轮次 38：把 `--steps` 打通之后，闭环反而变差——瓶颈从"动作质量"移到了"安全层拒绝率"