exp: 轮次39(续)——执行余量审计：91%执行点≥0.5mm但每题最险点中位仅0.029mm；到达题全拒0.88% vs 未到达22%

docs/experiment_round39_margin_audit.json

@@ -0,0 +1,32 @@
+{
+ "n_tasks": 256,
+ "n_plans": 195,
+ "cap_mm": 0.5,
+ "run_points": 169216,
+ "gap_hist_of_run_points": {
+  "<0.02": 0.0025056733284145594,
+  "<0.05": 0.0043317414820194244,
+  "<0.10": 0.008356183767318726,
+  "<0.20": 0.019064391031861305,
+  "<0.50": 0.055952154099941254
+ },
+ "at_cap_share": 0.9097898602485657,
+ "min_gap_per_task_p50": 0.02924060821533203,
+ "plan_kind": {
+  "full": 0.7935897707939148,
+  "partial": 0.10769230872392654,
+  "rejected": 0.09871795028448105
+ },
+ "per_task": {
+  "plans_p50": 195.0,
+  "committed_steps_share": 0.9871794581413269,
+  "rejected_share_by_group": {
+   "arrived": 0.008826094679534435,
+   "failed": 0.21994824707508087
+  }
+ },
+ "rejected_step_share_by_group": {
+  "arrived": 0.01765218935906887,
+  "failed": 0.43989649415016174
+ }
+}

docs/探索日志.md

@@ -52,6 +52,15 @@
   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 那一臂因此要补跑。
 
+## 执行余量与前缀完整性审计（轮次 39 续，纯 CPU 读轮次 33 转储）
+
+- 256 题 × 195 次同步规划、commit_n=2 ⇒ 169,216 个**真正被执行过的**检查点（每步的端点+中点，间隙在 0.5 mm 截顶）。
+- **执行点的间隙分布**：≥0.5 mm（=宽裕）占 **91.0%**；0.2–0.5 mm 占 5.6%；<0.1 mm 占 0.84%；<0.02 mm 占 0.25%。每题"最险的那个执行点"的中位数只有 **0.029 mm**。
+  ⇒ 两件事：① 大多数执行是宽裕的，所以"加 0.5 mm 余量门限"只花 3 题（轮次 33 margin 已实测）是自洽的；② 但每题都会至少一次贴到 **30 µm** 级——这是胶囊模型内部的"贴"，真机的运动学与装配误差远大于这个数，**搬到实机时这条是实质风险**，不能当成"我们有余量"。
+- **前缀完整性**：满前缀 79.4%、部分前缀 10.8%、全拒 9.9%。分组看全拒率——**到达题 0.88%，未到达题 22.0%**（未到达组因此 44% 的步是零运动，与时间账量的 37% 同量级：那 37% 是"活动窗内"，这里是"×commit_n"的换算）。
+- **对 `backoff` 的预期与判据**：全拒意味着"连第 1 步的端点或中点已经穿进障碍"，缩步能不能救取决于**穿得有多深**（穿 0.1 mm 救得回，穿 3 mm 救不回）。这个数转储里没记（只记被选中那条），所以直接由 `backoff_mean`/`reject_all_mean` 来量：
+  `reject_all_mean ≈ 原全拒次数`（=backoff_mean+brakes_mean，与轮次 33 cap 的 19.55 可比），`backoff_mean/(backoff_mean+brakes_mean)` 就是"缩步能救回的比例"。这是补跑（#22）要读的第一个数。
+
 ## 轮次 38：把 `--steps` 打通之后，闭环反而变差——瓶颈从"动作质量"移到了"安全层拒绝率"
 
 
@@ -873,6 +882,7 @@
 
 ## 分支清理（2026-10-20）
 
+
 - `feat/fb-mix`（8e5431c）：反馈混合方案的中间分支，**已验证是 `exp/dagger-deploy` 的祖先**（所有提交都在后者历史里），本地/远端分支删除，内容保留在 exp/dagger-deploy。
 - `feat/abs-target`（217a70b）：绝对目标参数化负结论分支（轮次 3）；打 tag `archive/abs-target` 保留可复现实体后，删除远端分支（本地此前已删）。
 - `backup/pre-deep-squash`、`backup/pre-squash`：历史备份分支，非实验方案，保留未动。