perf+exp: gm_groups 只算特征 8 组（数值一致，features 10.4→7.1ms）；混合节奏负结论（执行反馈无提升）；浏览器部署 dag2 ONNX + fbGain/commit 参数（bench 刹车 47% 待调）；实时口径改为异步规划+tick

docs/探索日志.md

@@ -384,6 +384,21 @@
 - **结论**：**当前方案不满足 50 Hz 实时**（单次 40–80 ms，超预算 2–4 倍）；42.2% 的成绩依赖每步规划（20 ms 节奏）。实时可行节奏下：每 3 步 → 36.3%（p50 有余量、p99 需继续优化），每 6 步 → 14.8%。**实时性是当前方案的硬约束，不是仿真耗时问题**。
 - **下一步（需确认）**：① 浏览器 ONNX 路径实测（推理 P99 历史 10–12 ms；特征/安全层在 JS 端需 `tests/policy_bench.cjs` 实测）；② 特征缓存 + 安全层粗筛，目标单次 P99 < 20 ms；③ 或接受「每 3 步规划」的 60 ms 周期（36.3%）。
 
+## 轮次 24：实时性优化与新方法（exp: `exp/dagger-deploy`）
+
+- **目标**：准确率更高 + 效率满足 50 Hz（20 ms 控制步）。
+- **① 混合节奏（规划每 3 步 + 执行时每步反馈）——负结论**：plan fb1.8 + exec fb1.8 → 36.3%（与纯规划反馈的 commit_n=3 完全相同）；plan fb0 + exec fb1.8 → 仅 1.6%。执行时反馈不带来额外收益（规划时的反馈已是主要贡献），此捷径不成立。
+- **② 特征几何优化（有效）**：特征只用 8 组间隙（GP），但原实现算全部 49 组（67256 簇对）。新增 `Kin.gm_groups(q, GP, cap)`：按 7 连杆组对过滤簇对（簇索引 → `cl_g` → 组对 min/max），只算 8 组。
+  - 数值验证：与 `gaps()['gm'][:, a*7+b]` 逐项一致（diff 0）。
+  - 延迟：gm 计算 10.4→**7.1 ms**（p50），单次规划省约 3 ms。
+- **③ 浏览器部署**：导出 `webapp/models/traj_policy.onnx`（dag2 best，19.8 MB，对拍误差 3.1e-6，act_scale 1.0）；`ik-policy.js` 加全程目标反馈（`fbGain`）+ `commit` 可配；`ik-policy-glue.js` 支持 `?fb=&commit=`（默认 fb=1.8、commit=3）。
+  - JS bench（Node，10 题，fb1.8+commit1）：到达 0、**刹车率 47.3%**（每 2 次规划刹停一次）、planP50 43.8 / P99 70.5 ms。JS 安全层（5 mm 护栏 + 距离认证）比 Python（0.5 mm gap）保守，反馈+每步规划被大量拒绝。
+- **④ 实时口径的关键认识**：部署形态是**异步规划**（tick 20 ms 只执行队列；`plan()` 后台跑），所以 50 Hz 的约束是「tick < 20 ms + 规划在队列耗尽前完成」，不是「单次规划 < 20 ms」。
+  - JS 的 tick 只做队列执行 + 投影/碰撞检查（~1.5–3 ms）→ 50 Hz 可行；
+  - 规划 P99 70 ms → 需要 commit ≥ 4（80 ms 队列）才不饥饿；commit=3（60 ms）会偶发饥饿。
+  - 准确率与规划频率的 trade-off：commit1 42.2%（不可 50Hz）、commit3 36.3%、commit6 14.8%。
+- **下一步**：① 在 commit=3/4 的实时节奏下找准确率提升（候选平均、dag3_fe 冻结编码器、更高 gain）；② 把 gm_groups 同步到 JS（gapMatrix 只算 8 组）；③ 降低 JS 安全层拒绝率（margin/认证预算调参）。
+
 ## 分支清理（2026-10-20）
 
 - `feat/fb-mix`（8e5431c）：反馈混合方案的中间分支，**已验证是 `exp/dagger-deploy` 的祖先**（所有提交都在后者历史里），本地/远端分支删除，内容保留在 exp/dagger-deploy。