exp: 轮次36——规划起点 r 分布实测，循环内共享 FK(#19) 在部署 r3 口径只值 0.03 ms/次，判掉

docs/探索日志.md

@@ -738,6 +738,22 @@
 - **循环内还剩的可复用点**：`replan='empty'` 且队列为空时 `qe == q`，此时目标反馈 DLS 与末态打分的 FK 和特征用的是同一姿态，可以共享一份 `cum_xf`（部署 `r=3` 时不成立，要按 r 分支）。这条待测（#19）。
 - **守卫补一个**：`gaps()` / `gm_groups()` 现在拒绝行数与 `q` 不符的 `xf`（之前会静默按别的行做宽相位，实测触发 CUDA device-side assert 或给出错间隙），测试 34→35 项；`python -m ml.eval.check_parity` 仍 PASS（2000 样本，间隙差 2.52e−13 mm、碰撞布尔差 0、特征差 5.96e−08）。
 
+## 轮次 36：规划起点队列长度实测——#19（循环内共享 FK）判掉
+
+- **要判的问题**：轮次 35 留下"循环内唯一可省项"是 `qe == q` 时把 features 已算的 `cum_xf` 共享给反馈/打分，实测那份 `cum_xf` 在 B=1 值 **3.631 ms**。但它只在规划时队列为空（`r = queue.shape[1] == 0`）才成立，而部署口径是 `replan='r3'`。先量 r 的分布再决定，不靠推测。
+- **做法**：`rollout(..., return_traj=True)` 顺带记每次规划的 `r`（`plans['r']`，纯诊断，不参与任何判据）。32 题同批、K=8、fb 2.2、dls_safety 1、`docs/experiment_round36_plan_r_hist.json`：
+
+  | 口径 | 规划次数 | r 分布 | r==0 占比 | 平摊可省 |
+  |---|---|---|---|---|
+  | empty / commit 2 / 不限幅 | 175 | r=0 全部 | 1.000 | 3.631 ms/次 |
+  | **r3 / commit 3 / 不限幅** | 118 | r=3:116、r=2:1、r=0:1 | **0.0085** | **0.031 ms/次** |
+  | r3 / commit 3 / inc_cap 1 | 118 | 同上 | 0.0085 | 0.031 ms/次 |
+  | empty / commit 3 / inc_cap 1 | 117 | r=0 全部 | 1.000 | 3.631 ms/次 |
+
+- **结论（不做）**：部署 r3 稳态每次规划都从队列第 3 步之后开始，`qe` 是前缀末端而不是 `q`，与 features 的姿态不同 ⇒ 共享率 1.7%，平摊收益 0.03 ms，为它加一条按 r 分支的参数面不值。**评测口径（empty）能省 3.6 ms 这件事不能当成部署收益汇报**——发布的那批 57.4% 数字是在 empty 下跑的，若将来把部署也改成"队列空了才规划"，这条要重开。
+- **顺带记下的实测**：同一批 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']` 只增不改）。
+
 ## 分支清理（2026-10-20）
 
 - `feat/fb-mix`（8e5431c）：反馈混合方案的中间分支，**已验证是 `exp/dagger-deploy` 的祖先**（所有提交都在后者历史里），本地/远端分支删除，内容保留在 exp/dagger-deploy。