diff --git a/docs/本机执行清单.md b/docs/本机执行清单.md
index d066434..cbb426a 100644
--- a/docs/本机执行清单.md
+++ b/docs/本机执行清单.md
@@ -61,3 +61,41 @@ PYTHONUTF8=1 python -m ml.eval.diag_cl --ckpt ml/runs/base/last.pt --n 256 --out
 | 1 | 终端 3 行峰值 |
 | 2 | ml/runs/diag_cl.json |
 | 任一步出错 | 终端最后 30 行输出 |
+
+---
+
+## 执行回传（2026-10-19 03:55，本地 AI）
+
+### 第 0 步：同步代码
+
+monitor/pstate 按清单提交 `1f2f2a2`（"monitor: 开环指标两张图；pstate: train 归档加 review_*"），pull --rebase 后已推送。log 与预期一致：`1f2f2a2`（monitor）→ `0653cf0`（Hark fix(kin/diag)）。无训练进程在跑。
+
+### 第 1 步：gaps 显存峰值（实测）
+
+```
+n=  512 cap=  40  peak   1.05 GiB
+n= 4096 cap=   4  peak   1.40 GiB
+n= 4096 cap=  40  peak   4.46 GiB
+```
+
+前两条过线；4096×40 仍 **4.46 GiB**（>2 GiB 判据）。
+
+分层定位（独立测量）：
+- **粗筛分块工作正常**：单粗块（446 点，粗筛+块内全部精算）峰值 1.05 GiB。
+- **峰值全在顶层 `_cat_gaps` 拼接**：完整 gaps 4.54 GiB == 只做 `_cat_gaps`（parts 备好后单独调）4.54 GiB。
+- 机制：4096 点 cap=40 共 **8.63e7 细对**；顶层拼接时 10 个粗块的 parts（b/i/j int64 各 0.64 GiB、gap fp32 0.32 GiB，合计 2.25 GiB）与拼接输出（同样长大）同时存活，加上 `p['b']+s` 的临时副本，瞬时到 4.5 GiB 量级。
+- 三个可行的修法方向（未改代码）：① 逐键消费——`torch.cat([p.pop('b')+s …])` 一类，每拼完一个键释放该键 parts，峰值降到 ~2.5 GiB；② b/i/j int32 化（细对数 8.6e7 < 2^31，索引完全够），内存直接减半到 ~2.3 GiB；③ 顶层不拼大数组，消费方（dagger/collect、dag 收集）按块消费。
+- 版本对比：上一版（`573082d`）同配置 9.30 GiB → 本版 4.54 GiB；旧版（`0b47905`）36.9 GiB。
+
+### 第 2 步：闭环失败定位（含 D 段；完整 JSON 已更新到 ml/runs/diag_cl.json）
+
+A/B/C 与上轮一致（A/B 全过；C：0% 到达 / 99.6% 碰撞，主碰撞对 J3-J5）。新增输出：
+
+- **C.goal_err_ratio_p50**：0.5 s **0.967**、1.0 s **0.892**、2.0 s **0.815** —— 误差比值 <1，方向没错、在缓慢靠近，但 2 秒只缩 **18.5%**，从未接近。
+- **D0_subhead**：需子目标的题占 28.1%；need 二分类准确率 71.9%；冷启动预测的途经点 1 每关节最大误差 p50 **66.8°** / p90 **137.1°** —— 子目标头确实基本预测不对。
+- **D1_no_sub**（完全不用子目标）：到达 **0%** / 碰撞 **99.6%** / 末端误差 p50 430 mm。
+- **D2_oracle_sub**（用老师真实途经点）：到达 **0%** / 碰撞 **99.6%** / 末端误差 p50 435 mm。
+
+**D 段结论：子目标不是元凶。** D2（最有利输入）与 D1、C 基线三者到达率/碰撞率完全相同（0% / 99.6%），末端误差也一致（430/435 mm）——拿掉子目标或换成老师真值都毫无区别。子目标头虽然预测很差（p50 66.8°），但不是闭环失败的原因；策略在闭环状态里本身就完全走不动（2 s 只靠近 18.5% 且 99.6% 撞）。
+
+### 第 1、2 步都没出错，无终端报错段。