From ff699f507954bf33532a66c129e04f5dc084ca87 Mon Sep 17 00:00:00 2001 From: AskaEth Date: Mon, 5 Oct 2026 20:25:58 +0800 Subject: [PATCH] =?UTF-8?q?docs(05):=20=E9=94=9A=E7=82=B9=E8=A1=A5?= =?UTF-8?q?=E8=AE=B0=E5=8D=81=E5=85=AB=E2=80=94=E2=80=94W47=20=E9=9D=99?= =?UTF-8?q?=E9=BB=98=E6=8C=89=E4=BA=8B=E6=95=85=E5=A4=8D=E4=BD=8D=EF=BC=88?= =?UTF-8?q?=E6=B8=85=E9=9B=B6=E7=82=B9=E6=94=B6=E8=BF=9B=E4=B8=80=E4=B8=AA?= =?UTF-8?q?=E7=BA=AF=E5=88=A4=E6=8D=AE=E3=80=81=E4=BA=8B=E6=95=85=3D?= =?UTF-8?q?=E9=98=9F=E5=88=97=E7=A9=BA=E5=88=B0=E7=A9=BA=EF=BC=89=EF=BC=8C?= =?UTF-8?q?=E5=90=AB=E4=B8=BA=E4=BB=80=E4=B9=88=E4=B8=8D=E9=80=89=E3=80=8C?= =?UTF-8?q?=E5=8F=AA=E5=9C=A8=E6=88=90=E5=8A=9F=E6=97=B6=E6=B8=85=E9=9B=B6?= =?UTF-8?q?=E3=80=8D=E4=B8=8E=E4=B8=89=E6=9D=A1=E9=AA=8C=E6=94=B6=E4=BD=93?= =?UTF-8?q?=E9=AA=8C?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- devdocs/05-开发进度与交接.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/devdocs/05-开发进度与交接.md b/devdocs/05-开发进度与交接.md index d612850..8c73959 100644 --- a/devdocs/05-开发进度与交接.md +++ b/devdocs/05-开发进度与交接.md @@ -1208,3 +1208,28 @@ curl -s -X PATCH "$BASE/api/v1/sessions/$SID" -H "Authorization: Bearer $TOK" \ > **不是我方本地状态的 bug**（我方与 `devdocs/03:141`「thinking / tool_call：仅 WS 实时有」逐字一致）。后端**其实已经把工具调用落进 `flow_graphs`**，缺的是「取出来给聊天端」。 > 已登记进 `02`（`b8399b5`）：要可选字段（`omitempty`，缺席=老行为逐字不变）、覆盖面对齐 `turnId`、**归属要明确**、允许开独立端点。 > 我方接线点：目前 `ToolCard` 在「已落库消息」那条渲染路径上是**不可达代码**（渲染器签名里没有 tools 参数）——字段一到即可接。 + +> ## ★★ 锚点补记十八（2026-10-06 · W47 队列静默改为「按事故复位」） +> +> ### 状态 +> `android` = **合并提交见下**；分支提交 `ce50bd2`；主树 **1158 测试 / 0 失败 / 0 错误**。W47 worktree 已清。 +> +> ### 主人裁决 +> 「静默持续到某次补发成功（A）vs 每批结束复位（B）——**哪个从体验上更好就用哪个**」。**判定：B**，但把 B 改准成「**按事故复位**」。 +> **为什么不选 A（原实现）**：A 只在「某次补发**成功**」时清零 ⇒ 若一个坏网络时段的队列最后**以回滚/被收编结束**（而不是以成功结束），静默会**一直挂着**；之后连接恢复、再断一次、用户又发消息时**永远得不到解释**。那不是减少噪音，是**把解释永久关掉**。 +> +> ### 改了什么 +> - `ui/chat/SendQueue.kt` 新增纯函数 **`queuedResendFailuresAfterDelivery(failures, sent, drained) = if (sent || drained) 0 else failures`** —— 清零点判据的唯一出处（与 `queuedSendNoticeAllowed` 同一写法）。 +> - `ChatViewModel.forgetQueuedNoticeIfDrained(sent)` 从「只清 `queuedNoticeTold`」改成**同时按新判据复位 `queuedResendFailures`**；`dropQueuedSend` 里原来那行 `if (sent) queuedResendFailures = 0` 删掉，改为出队后调它 ⇒ **两个清零点收在同一个函数里**。 +> - **阈值仍是 3**、「一批从空到非空只说一次」仍由 `queuedNoticeTold` 负责、`withoutQueuedSend` 等队列操作**一行未动**。 +> +> ### 「事故」的界定与验收体验（已写进 KDoc） +> **事故 = 队列从空到非空、再回到空的那一段**（与 `queuedNoticeTold` 的「一轮」同口径）。结束就复位，**不管它是怎么结束的**。 +> - **一次事故内**连发几条 ⇒ 只有**一次**横幅（重试本身不产生横幅）； +> - **事故结束后**再遇新事故 ⇒ 计数已复位 ⇒ **会重新解释**，不会永久闭嘴； +> - **长期断网**不停发 ⇒ 消息**堆在队列里、队列不清空** ⇒ 不算新事故 ⇒ **不会每条都弹横幅**； +> - **静默 ≠ 丢弃**：计数只进告知判据，`silence never touches the queue` 那条用例继续通过。 +> +> ### 未做 +> - **设备验证**（任务书禁碰 adb）：「一次事故一次横幅」的体验只由纯函数单测 + KDoc 钉住。若要设备验收，用 `ws_block_proxy.py` 造场景即可。 +> - 项目没有 `ChatViewModel` 单测装置，所以复位判据提成纯函数来钉（与 W43 同一做法）；清零点被调用这件事靠既有架构保证。