docs(05): 锚点补记二十二——③ 结案：阶梯机制正常（两次有效观测 route=Rest 且落库），W45 那轮异常未复现也因当时无 CyreneRoute 日志而无法定论；并写死一套可靠的设备驱动协议（确认前台→确认文字落点→从 dump 取发送键坐标）

devdocs/05-开发进度与交接.md

@@ -1313,3 +1313,28 @@ curl -s -X PATCH "$BASE/api/v1/sessions/$SID" -H "Authorization: Bearer $TOK" \
 > 结果：**`CyreneRoute` 日志为空、代理没有 POST、库里没有那条** ⇒ **`sendThroughLadder` 一次都没被调用**，即**发送没发生**。
 > 最可能的原因与前几次同源：**输入注入没命中**（45 秒时 App 可能仍在加载；我没有在打字后先确认「文字真的进了输入框」就点了发送——**这条纪律我今天写了两次，这回又没执行**）。
 > **结论：③ 仍未定论。** 下一轮的做法必须改成三步都确认：① `dumpsys` 确认前台是本 App → ② 打字后 `dump` 确认输入框里**确实有那段文字** → ③ 再点发送；然后读 `CyreneRoute` + 代理 + 库。
+
+> ## ★★ 锚点补记二十二（2026-10-06 · **③ 有结论了**：机制正常，那一次异常未复现）
+>
+> ### 结论
+> **「WS 断、HTTP 通 ⇒ 回落 REST」这条阶梯是工作的**（**两次有效观测**都走通了）；**那一次异常（W45 那轮停在队列）未能复现**，且当时 `CyreneRoute` 日志还不存在 ⇒ **无法确定它当时选了哪条路**。按完成判据，这一条以「说明为何不可复现」结案。
+>
+> ### 两次有效观测（判据一致）
+> 场景：`ws_block_proxy.py` 只掐 `/ws/chat`（503）+ `adb reverse tcp:10942 tcp:18098` + **force-stop 重启 App**（**必须重启**：否则旧连接还活着 ⇒ 会走 `Ws` 档，考不到阶梯）+ `logcat -c` 清过。
+>
+> | 次 | CyreneRoute | 网络侧 | 库 |
+> |---|---|---|---|
+> | W46 那轮 | `route=Rest reason=ConnectionNotReady` | 代理 `PASS POST /api/v1/chat -> 200` | **1 条** |
+> | 本轮（`w49`） | `route=Rest reason=ConnectionNotReady` | （未取代理日志，落库即证明 POST 成功） | **1 条**（`cli=local-32f2c53d`） |
+>
+> ### 那次异常（未复现）
+> 现象（W45 那轮）：气泡停在「**排队中 · 还没连上**」、代理**没有 POST**、库里**没有那条**。
+> 最可能的解释（**仍未证实**）：`route=Rest`，但那次 REST 死在**整通上限 10 秒**（被启动期的请求洪峰吃掉连接预算）⇒ `Unsent` ⇒ 进队列。
+> **为什么不能定论**：那轮发生在 `CyreneRoute` 日志加入之前（W46 才加），所以「它当时选了 Rest 还是 Queue」**没有证据**；之后两次复现都正常。
+>
+> ### ★ 本轮最关键的收获：**一套可靠的设备驱动协议**（写死它）
+> 这一轮之所以终于拿到数据点，是因为严格执行了三步，而且**第三步是从 dump 里取真实坐标**：
+> 1. `dumpsys window | grep mCurrentFocus` 确认**前台是本 App**；
+> 2. 打字后 **dump 并检查那段文字的 `bounds`**——判断它**在输入框里**（x 落在 275..845、y 被软键盘顶到 ~1293..1435）还是**已经成了列表里的气泡**（y < 2000）。这一步就是「发送到底触发了没有」的判据；
+> 3. **不要复用发送键坐标**：软键盘会把整条输入栏顶高约 820px。本轮 `发送` 的真实 bounds 是 `[911,1333][1003,1399]`（不是无键盘时的 `[911,2166][1003,2232]`）⇒ **从 dump 里取 bounds 再点**。
+> ⇒ 我今天在这个坑上栽了 4 次（黑屏、前台不是本 App、复用坐标、不确认文字落点）。**这四步之后，设备验证才算「可靠」。**