exp+feat: 轮次36(续)——时间账证明限幅后的损失是"站住"不是巡航；全拒缩步顶上(backoff，默认关)

docs/探索日志.md

@@ -754,6 +754,22 @@
 - **顺带记下的实测**：同一批 32 题上 empty/commit2 到达 0.469、r3/commit3 0.438、加 inc_cap 后 0.406（n=32，只作方向参考，不足以定论；256 题口径见轮次 33）。规划次数差 1.5 倍（175 vs 118）——r3 每次只新增 commit 步却已含 3 步前缀，所以同样墙钟时间内规划得更少，这正是它更贴近部署的原因。
 - 测试 35 项仍全过（`plans['r']` 只增不改）。
 
+## 时间账：限幅之后 time_ok 的损失在"站住"上，不在巡航速度上（2026-10-20，轮次 36 续）
+
+- **口径**：直接吃轮次 33 的 256 题轨迹转储（`ml/runs/round33_cap.pt`、`round33_base.pt`，离线分析 `ml/runs/_time_audit.py`，产物 `docs/experiment_round36_time_audit.json`），按每题的活动窗把每一步按「该步最大关节位移 / VMAX·DT」分四档：零运动、<0.5、0.5–0.95、≥0.95。切片时踩了一个自己的坑：`per['traj']` 是 `torch.stack(traj, 1)` 出来的 **[B,T,6]** 而不是 [T,B,6]，按列切成了"同一时刻不同题"，比值全是 70~230 的 nonsense；加了 `traj[i][0] == q0` 的断言之后才挡住这类错。
+- **实测（占活动窗的比例）**
+
+  | 组 | 题数 | 零运动 | <0.5 | 0.5–0.95 | ≥0.95 | 刹停段/题 | 平均段长 |
+  |---|---|---|---|---|---|---|---|
+  | base 到达且按时 | 100 | 1.9% | 4.0% | 19.4% | 74.8% | 1.2 | 1.5 步 |
+  | base 到达但超时 | 47 | 10.5% | 7.2% | 25.5% | 56.8% | 10.1 | 1.7 步 |
+  | base 未到达 | 109 | 32.6% | 9.9% | 32.8% | 24.7% | 38.6 | 2.1 步 |
+  | cap(限幅) 未到达 | 122 | 30.1% | 9.7% | 31.0% | 29.1% | 35.9 | 2.1 步 |
+
+- **判读**：限幅并没有把动作整体拖慢——未到达组的 ≥0.95 档反而从 24.7% 升到 29.1%；真正吃掉时限的是**零运动**（占活动窗 30%，平均每题 1.54 s）和**长刹停段**（最长 41 步 = 0.82 s 原地不动）。所以 #17 不该往"打分里加剩余时限"这种间接方向做，直接打"全拒⇒站住"这一条。
+- **改动（默认关，`--backoff`）**：全拒时不再站住，把首选候选按 1/2、1/4、1/8…（档数 = backoff）**并进同一次批量认证**（零额外几何调用），只在原候选连第 1 步都不安全时顶上；缩步候选不参与"前缀更长者优先"的比较，所以正常路径的选择逐位不变。新增 `backoff_mean` 指标记录缩步次数。测试 35→38 项（全拒→慢爬、有安全前缀时插手无效、未开批量认证时报错）。
+- **待测**：256 题 A/B（`--inc_cap 1 --cert_batch 1 --backoff 0/1/2/3`）——GPU 先让给 K-MF E1，这轮排在其后。
+
 ## 分支清理（2026-10-20）
 
 - `feat/fb-mix`（8e5431c）：反馈混合方案的中间分支，**已验证是 `exp/dagger-deploy` 的祖先**（所有提交都在后者历史里），本地/远端分支删除，内容保留在 exp/dagger-deploy。