diff --git a/docs/Disaggregated/notes/p12/CREATE-WINDOW-MEASURED.md b/docs/Disaggregated/notes/p12/CREATE-WINDOW-MEASURED.md
index 59c88b8a..bf84171b 100644
--- a/docs/Disaggregated/notes/p12/CREATE-WINDOW-MEASURED.md
+++ b/docs/Disaggregated/notes/p12/CREATE-WINDOW-MEASURED.md
@@ -253,7 +253,41 @@ if (x.replySeq != seq) return ... MOBILEGL_ERR_PROTOCOL_MISMATCH;   // 等的是
 
 实验状态已还原（环回到 8、探针全部删除），四个车道 172+13+22+103 全绿。
 
-## 11. 复算
+## 11. 第 0b 步：预算关掉 + 环 1024 —— 收益是量出来的，不是外推的
+
+§10 证明「环够深，延后的答案就都读得回来」，但那一轮 `by_op 2 = 3,443` 里绝大多数是**预算**触发的
+（3,395），所以「W 变小能不能换来墙钟」还没答。于是再做一次一行实验：**环 1024 + 把预算关掉**
+（`kCreateReplyResidency` 抬到不可能达到），W=2 与 W=4 各跑一轮：
+
+| 臂 | waits | rtt_mean | `by_op 2` | **墙钟** |
+|---|---|---|---|---|
+| W=1（现默认） | 4,543 | 5,672 µs | 4,536 | 28.66 s |
+| 预算开 + 环 8 | 9,078 | 2,598 µs | 9,071 | 27.04 s |
+| 环 1024 + 预算 7 | 3,450 | 5,367 µs | 3,443 | 23.04 s |
+| **环 1024 + 预算关，W=2** | **2,560** | **4,916 µs** | **2,553** | **16.80 s** |
+| **环 1024 + 预算关，W=4** | **1,691** | **4,224 µs** | **1,684** | **11.45 s** |
+
+（W=4 那轮的窗口读数：`taken=4498/4500 pushed=4500 blocked=0 readfail=0`。）
+
+**结论一：分水岭答了，而且是好的一侧。** 等待数减半/减到 1/2.7，墙钟跟着减半/减到 1/2.5，
+而 **`rtt_mean` 没有变大**（4,916 / 4,224 µs，比基线的 5,672 µs 还低）。这说明那 ~5 ms 是**唤醒往返**，
+而且**服务端一次唤醒吃掉一整批**——所以 W 深一档就少一档唤醒，等待数与墙钟同步下降。
+（审计把这条列为「仓库里判不出来、只有真机能答」的分水岭，它同时也是「这件事值不值得做」的分水岭。）
+
+**结论二：收益比 handoff 的地板还低。** handoff §0.4 估计「窗口生效后 15-20 s」，而那把客户端 CPU（~13.4 s）
+当成与等待**相加**；实测这个帧是等待主导的，等待摊薄之后 W=4 到 **11.45 s**——比估计的地板还低 3.5 s。
+
+**注意 1024 是替身，不是设计。** 它能工作只因为「这个负载下 1024 恰好够深」；1024 个条目最坏是 ~2 GiB
+（`ReadPixels` 的答案可到 2 MiB），审计已点名。**保留表给的正是同一个性质（答案还在）而有界**，
+所以这一步的结论是「按审计的形状去实现」，而不是「把环改成 1024」。
+
+实验状态已还原（环回 8、预算回 7、探针删除），172 + 13 全绿。
+
+**顺带更正 §7 的第 1 条路**（审计 F15）：在 stream 臂上 `SEG_REPLY` / Hello 的 `ReplySlotCount` **与答案无关**
+——答案走 Reply 帧、`StreamLink::ReadReply` 读客户端自己的 store，池只用来给 `MaxReplyBytes()` 定尺寸。
+所以「加深池子 + 抬 `ReplyBytes`」根本没有针对实测那条臂，别为它付 8× 常驻内存。
+
+## 12. 复算
 
 ~~~sh
 # 两臂的帧读数（handoff-2 §1 的读法）