work-ally 0.2.0-alpha.1

package/docs/issues/resolved/ANALYSIS-runtime-turn-delivery-and-recovery-2026-03-14.md

@@ -0,0 +1,603 @@
+# 分析报告：Ramond 办公桌 2026-03-14 21:47 断连事件与中间层交付语义治理
+
+更新时间：2026-03-14  
+状态：分析完成 / 供架构评审  
+作者：Codex
+
+## 1. 文档目的
+
+这份报告回答两件事：
+
+1. 还原 2026-03-14 21:47 左右 Ramond 办公桌一次真实断连事件的完整事实链，包括背景、日志路径、分析过程、关键证据与根因判断。
+2. 把这次 incident 提升为一类中间层设计问题来讨论，给出面向 `work-ally` 长期演进的整体治理方案，供另一位架构师评审和继续推进。
+
+这份报告不包含任何代码改动建议的落地 patch，也不把重点放在某一个函数的小修小补上。重点是把问题从“这次为什么坏了”提升到“这类问题如何从设计层面治理”。
+
+## 2. 事件背景
+
+### 2.1 用户最初问题
+
+本次分析起点不是代码 review，而是一次针对真实对话故障的排查请求。
+
+用户明确指出：
+
+- 对象是 `Ramond` 办公桌
+- 时间点是 2026-03-14 晚上 `21:47` 左右（Asia/Shanghai）
+- 用户前台看到的对话片段依次为：
+  - `【系统消息】 Codex App Server 已断开，当前任务状态待确认。`
+  - `【系统消息】 Codex App Server 连接中断，正在确认这一轮是否已完成。`
+  - `【系统消息】 Codex App Server 连接已恢复，继续确认上一轮结果。`
+  - `【系统消息】 Codex App Server 连接已恢复，但系统未能确认上一轮是否已完成。为避免漏掉结果，请重新发送上一条消息。`
+  - 用户重新发送：`进度如何`
+  - 系统回：`⏳ 工作中 正在处理，请稍候。`
+  - 最后报错：`runtime turn reconciliation failed: idle thread without completed turn event (019cec9b-c8ef-74c2-a56d-4d5d0c3c5d0c)`
+
+用户要求先查清这次故障本身，再进一步判断这种问题是否能从本质上被根治。
+
+### 2.2 这次排查的核心问题
+
+从排障目标上，本次并不是单纯问“为什么 websocket 断了”，而是问四个更关键的问题：
+
+1. `21:47` 时到底断了什么。
+2. 断开之后，上一轮任务到底有没有完成。
+3. 用户后来重新问“进度如何”时，为什么 bridge 又给出了一次错误结论。
+4. 这暴露的是单点 bug，还是中间层设计层面的系统性缺口。
+
+## 3. 排查范围与证据位置
+
+### 3.1 办公桌与运行态位置
+
+本次排查对象位于：
+
+- Ramond 办公桌根目录：`/Users/allenfeng/.work-ally/assistants/Ramond`
+- 运行态目录：`/Users/allenfeng/.work-ally/assistants/Ramond/.system`
+
+### 3.2 本次使用到的关键证据文件
+
+#### A. 用户可读对话与稳定原材料
+
+- 对话视图：`/Users/allenfeng/.work-ally/assistants/Ramond/conversations/2026-03-14--feishu--oc_6caa5cabdf488d208445714f4e4c472b.md`
+- 原材料账本：`/Users/allenfeng/.work-ally/assistants/Ramond/.system/archive/2026/03/14/feishu--oc_6caa5cabdf488d208445714f4e4c472b.ndjson`
+
+#### B. bridge 侧运行日志
+
+- 主日志：`/Users/allenfeng/.work-ally/assistants/Ramond/.system/logs/bridge-2026-03-14.log`
+- 时间线日志：`/Users/allenfeng/.work-ally/assistants/Ramond/.system/logs/timeline-2026-03-14.log`
+
+#### C. runtime session 台账
+
+- session 元信息：`/Users/allenfeng/.work-ally/assistants/Ramond/.system/runtime/sessions/feishu--oc_6caa5cabdf488d208445714f4e4c472b/meta.json`
+- session 事件流：`/Users/allenfeng/.work-ally/assistants/Ramond/.system/runtime/sessions/feishu--oc_6caa5cabdf488d208445714f4e4c472b/events.ndjson`
+- 当前 thread 记录：`/Users/allenfeng/.work-ally/assistants/Ramond/.system/runtime/sessions/feishu--oc_6caa5cabdf488d208445714f4e4c472b/current-thread.json`
+- turn 记录目录：`/Users/allenfeng/.work-ally/assistants/Ramond/.system/runtime/sessions/feishu--oc_6caa5cabdf488d208445714f4e4c472b/turns/`
+
+#### D. Codex runtime session 原始轨迹
+
+- rollout 会话轨迹：`/Users/allenfeng/.work-ally/assistants/Ramond/.system/codex-home/sessions/2026/03/14/rollout-2026-03-14T15-51-27-019ceb54-2926-7360-9e8f-0d85d7ab1505.jsonl`
+
+#### E. 相关实现代码
+
+- runtime client：`/Users/allenfeng/Development/Repositories/work-ally/bridge/src/runtime-client.ts`
+- receiver：`/Users/allenfeng/Development/Repositories/work-ally/bridge/src/receiver.ts`
+- session store：`/Users/allenfeng/Development/Repositories/work-ally/bridge/src/session-store.ts`
+- archive store：`/Users/allenfeng/Development/Repositories/work-ally/bridge/src/archive-store.ts`
+
+#### F. 现有设计文档
+
+- `README.md`
+- `docs/architecture/codex-feishu-bridge-proposal.md`
+- `docs/planning/SPEC-runtime-connection-and-turn-recovery-semantics.md`
+- `docs/completed/SPEC-middleware-exception-visibility.md`
+- `docs/planning/SPEC-session-presence-and-state-visibility.md`
+- `docs/planning/SPEC-stable-archive-contract.md`
+
+## 4. 分析过程
+
+### 4.1 第一步：确认时间轴与真实时间点
+
+用户给的是本地时间 `21:47`。Ramond 办公桌日志里大量时间戳是 UTC，因此第一步先统一时区语义：
+
+- `2026-03-14 21:47 Asia/Shanghai`
+- 等于 `2026-03-14T13:47Z`
+
+之后所有日志检索都围绕 `13:47Z ~ 13:50Z` 展开。
+
+### 4.2 第二步：先从用户可见材料反推内部 turn
+
+在 archive 与 conversation view 里，用户确实先后看到了四条系统消息，然后重发了“进度如何”，接着看到“⏳ 工作中”，最后收到 `runtime turn reconciliation failed: idle thread without completed turn event (...)`。
+
+这一步确认了两件事：
+
+1. 用户反馈与系统黑匣子是一致的，不是回忆误差。
+2. 需要同时追两轮 turn：
+   - 断线时的上一轮 turn
+   - 用户重发“进度如何”后的新一轮 turn
+
+### 4.3 第三步：在 bridge 日志里定位断开点
+
+在 `bridge-2026-03-14.log` 中，关键转折发生在 `2026-03-14T13:47:05.323Z`：
+
+- `runtime.connect_closed`，reason 为 `runtime websocket closed`
+- 紧接着 `receiver.turn_failed` 把当时正在执行的 turn 标成失败
+- 后续自动重连成功，并进入 turn recovery attempt
+
+这证明：
+
+- 断开的不是 Feishu 入站，也不是用户消息链路
+- 断的是 `bridge <-> Codex App Server` 的 websocket
+
+### 4.4 第四步：确认断线前那一轮是否真的彻底失败
+
+如果只看 bridge 当时的判断，会以为上一轮 turn 已失败；但 rollout 原始轨迹显示并非如此。
+
+在 Codex runtime 原始 session 里，长命令 `call_j8Fa...` 持续运行到 `2026-03-14T13:50:02Z` 才结束，随后还读取了发布结果文件，最后在 `2026-03-14T13:50:17Z` 生成最终答复：
+
+- 蒲公英链接：`https://www.pgyer.com/rapid_kit`
+- Build 号：`178`
+
+这说明上一轮从 runtime 角度其实是**完成了**，只是 bridge 在 websocket 断开后没能把这份结果稳定拿回来并交付给用户。
+
+### 4.5 第五步：确认用户重新发送“进度如何”后发生了什么
+
+bridge 日志显示：
+
+- `2026-03-14T13:49:17.871Z` 收到用户消息 `进度如何`
+- `2026-03-14T13:49:18.448Z` 启动新 turn：`019cec9b-c8ef-74c2-a56d-4d5d0c3c5d0c`
+- `2026-03-14T13:49:21.066Z` 发出“⏳ 工作中”
+
+到这里看上去一切正常。但 `2026-03-14T13:50:17Z` 左右出现了决定性的异常组合：
+
+- thread status 先变成 `idle`
+- 紧跟着到来的 `turn_completed_event`，对应的 turn 不是当前 turn `019cec9b-...`
+- 而是上一轮断线时的 turn `019cec94-...`
+- 随后 bridge 对当前 turn 执行 reconcile，结果失败，抛出：
+  - `runtime turn reconciliation failed: idle thread without completed turn event (019cec9b-...)`
+
+### 4.6 第六步：把日志行为映射回代码
+
+这一步不是为了“找一行错代码”，而是为了确认 bridge 现在的恢复语义到底建立在什么假设上。
+
+在 `runtime-client.ts` 中，本次故障路径涉及四个关键点：
+
+1. `runTurn()` 会把当前 turn 状态放到内存 `turnStates` 中等待完成。  
+2. websocket 关闭时，`handleSocketClosed()` 会直接 `rejectAllTurns()`，把所有活动 turn 从内存里 reject 并清掉。  
+3. 后续如果 thread 状态变成 `idle`，会对仍在 `turnStates` 里的 turn 启动 `reconcileIdleTurn()`。  
+4. `reconcileIdleTurn()` 的判断逻辑是：
+   - 先 `thread/read`
+   - 如果读不到对应 turn 的终态结果
+   - 且缓存的 thread 状态已经是 `idle`
+   - 就直接报 `idle thread without completed turn event`
+
+这一点把问题边界暴露得非常清楚：
+
+当前实现默认相信一种顺序：
+
+- turn 正常完成
+- `turn/completed` 事件按期到达
+- 如果事件没到，`thread/read` 也应该能在短时间里读到同一轮 turn 的终态
+
+一旦这个顺序被断线打乱，bridge 就会进入“猜测模式”。
+
+## 5. 关键事实链
+
+基于上述过程，可以把这次 incident 压缩成下面这条确定事实链。
+
+### 5.1 事实 1：21:47 确实发生了真实断开
+
+`2026-03-14T13:47:05.323Z`，bridge 记录：
+
+- `runtime.connect_closed`
+- reason：`runtime websocket closed`
+
+因此用户最先看到的“Codex App Server 已断开，当前任务状态待确认”不是误报，而是一次真实传输层断开。
+
+### 5.2 事实 2：断开的是中间层到 runtime 的连接，不是用户消息入口
+
+同一时间段内，Feishu 会话还在正常工作，后续用户还能继续发“进度如何”。
+
+因此这次故障本质不是“整套系统都挂了”，而是：
+
+- 入站聊天窗口仍活着
+- `bridge <-> runtime` 的语义连续性断了
+
+### 5.3 事实 3：上一轮任务没有真正失败，而是 bridge 丢失了它的确定性交付
+
+rollout 原始轨迹已经证明上一轮任务后来完成了，且产出了用户要的最终答案。
+
+因此对用户来说，真正损失的不是“模型没做完”，而是：
+
+- 模型做完了
+- 中间层没能在恢复后把结果稳稳送回去
+
+### 5.4 事实 4：用户重发后，新 turn 被建立了
+
+用户按照系统提示重发“进度如何”后，新 turn `019cec9b-...` 被正常创建并进入处理中。
+
+这说明 bridge 并没有彻底卡死，而是继续在同一 thread 上推进了新的回合。
+
+### 5.5 事实 5：bridge 把“上一轮补发的完成信号”和“当前轮等待完成的回合”混淆了
+
+`2026-03-14T13:50:17.311Z` 的 `turn_completed_event` 对应的是旧 turn `019cec94-...`，不是当前 turn `019cec9b-...`。
+
+但随后 thread 状态已经变 `idle`，bridge 对当前 turn 执行了 reconcile，并在没有读到当前 turn 的 completed 结果后判它失败。
+
+这说明 bridge 当前的恢复语义里，缺少一层更强的“回合确定性账本”，只能依赖在线事件顺序和短窗口补读结果去猜。
+
+## 6. 根因判断
+
+### 6.1 表层根因
+
+表层根因可以概括为一句话：
+
+> runtime websocket 断开后，bridge 在恢复阶段未能正确地区分“上一轮迟到的完成事实”和“当前轮仍待确认的完成事实”，导致 turn reconciliation 错配并误判失败。
+
+### 6.2 深层根因
+
+深层根因不是“某一个 if 写错了”，而是当前中间层把“turn 是否完成”这件事过度建立在**在线事件顺序**上，而不是建立在**可恢复的权威账本**上。
+
+更精确地说，当前模型有三个结构性特征：
+
+1. 活跃 turn 的真相主要存在于 bridge 进程内存的 `turnStates` 里。  
+2. websocket 一断，bridge 会立刻 reject 并清掉这些活动 turn。  
+3. 恢复后主要靠 `thread/status/changed` 与 `thread/read` 做一次有界猜测，而不是围绕某个稳定的 turn 交付记录持续收敛。
+
+这意味着系统在断线后天然会进入一个歧义区：
+
+- turn 到底没完成
+- 还是已经完成，但完成事件没及时送到 bridge
+- 还是已经完成，bridge 也短暂看见了，但本地状态先被清掉了
+- 还是上一轮结果刚回来，而用户已经开始了下一轮
+
+只要系统没有一个“哪一轮是否已完成、结果是否已持久化、结果是否已送达”的持久账本，这个歧义区就无法被真正消灭。
+
+## 7. 第一性原理分析：这是不是“快递员问题”
+
+用户在对话里给出的判断是：
+
+> 这一类问题，本质上就是作为一个中间层，没有正确地作为一个“快递员”，把我对 Codex 说的话以及 Codex 对我的回应进行来回传递。
+
+这个判断方向是对的，但还可以更精确。
+
+### 7.1 中间层不是普通快递员，而是“带签收系统的快递员”
+
+如果只把中间层理解成“把 A 发给 B，再把 B 发给 A”，那会低估它的职责。
+
+在 `work-ally` 这类桥接系统里，中间层还必须承担五个语义责任：
+
+1. **接单确认**：用户的话是否已经正式被系统接住。  
+2. **执行归属**：这句话对应哪一个 thread、哪一个 turn。  
+3. **完成确认**：Codex 是否真的已经产出终态结果。  
+4. **持久存证**：结果是否已经被中间层稳定记住，而不是只在 websocket 上飘过。  
+5. **送达确认**：结果是否真的送回了用户所在渠道。  
+
+因此它不是普通快递员，而是“快递员 + 运单系统 + 签收系统 + 异常回执系统”。
+
+### 7.2 真正的问题不是能不能转发，而是能不能在断线后保持语义确定性
+
+只要系统无法在断线后确定下面这五件事，就一定会出现“用户必须自己猜”的问题：
+
+- 这条消息有没有被正式接单
+- 这一轮有没有真正开始
+- 这一轮有没有真正完成
+- 结果有没有被中间层稳稳存住
+- 结果有没有真正送达用户
+
+本次 incident 证明，当前系统在第 3、4、5 件事上还没有足够强的确定性边界。
+
+### 7.3 第一性原理结论
+
+因此，用户的“快递员”比喻成立，但需要提升成下面这句更工程化的判断：
+
+> 这不是一个简单的消息转发 bug，而是一个“中间层缺少回合级签收账本”的设计问题。
+
+## 8. 现有设计的长处与边界
+
+为了避免分析滑向“全部推倒重来”，这里也要把当前设计里已经正确的地方讲清楚。
+
+### 8.1 已经做对的部分
+
+当前系统并不是完全没有设计，而是已经建立了若干正确方向：
+
+- 有独立的 `session store`，负责 conversation -> thread 的本地台账。
+- 有稳定 `archive` 合同，能够保留用户可见原材料与系统事件。
+- 有 `turn recovery attempt / required` 这类显式异常文案，而不是完全吞没故障。
+- 已经把“连接恢复”和“任务恢复”区分成不同文案层级。
+- 已经开始意识到 stale redelivery、middleware exception visibility、session presence 这些问题不能只靠日志解决。
+
+这些方向都是对的，也与灯塔文档和若干 planning spec 保持一致。
+
+### 8.2 当前边界为什么还不够
+
+问题在于，现有这些能力还没有形成一个闭合的“回合交付合同”。
+
+当前系统有：
+
+- 会话台账
+- 原材料归档
+- 异常提示
+
+但还缺：
+
+- 一个以 `turn` 为中心的、持久可恢复的交付状态机
+- 一个明确区分 `执行完成` 与 `用户已收到` 的持久账本
+- 一个在断线后仍然能继续收敛到唯一真相，而不是转入猜测的恢复闭环
+
+## 9. 提升为同类问题：中间层的设计层面缺口
+
+如果不把这次事件只看成一个 bug，而是看成一类问题，它暴露的是下面三层设计缺口。
+
+### 9.1 缺口 1：把“在线事件”误当成“权威事实”
+
+`turn/completed`、`thread/status/changed` 这些事件非常有价值，但它们本质上是**流式通知**，不是天然的最终账本。
+
+如果设计上把它们直接当成最终真相，就会在以下场景失稳：
+
+- websocket 断开
+- 事件延迟到达
+- 事件乱序到达
+- 用户在上一轮未决时又发了下一轮
+
+### 9.2 缺口 2：把“运行中内存态”误当成“可恢复状态”
+
+当前 `turnStates` 主要在内存里，进程断开或 socket 断开后，这些状态就先天脆弱。
+
+这在单机 happy path 下没问题，但一旦进入“正在跑 + 突然断线 + 稍后恢复”的真实世界，就会暴露出运行态和恢复态不是同一回事。
+
+### 9.3 缺口 3：中间层缺少面向用户承诺的交付合同
+
+当前 bridge 对用户暴露的是“有时能恢复、有时请重发”的 bounded confirmation 语义。
+
+这在 V1 是合理的，但如果目标是让用户把它当成稳定的远程办公入口，仅有 bounded confirmation 不够。还需要更明确地承诺：
+
+- 什么叫“已收到”
+- 什么叫“已接单”
+- 什么叫“已完成但未送达”
+- 什么叫“必须重发”
+
+否则用户虽然看到了更多系统消息，但仍然无法拥有稳定预期。
+
+## 10. 面向架构治理的整体方案
+
+下面给出的是一个设计层面的整体方案，不是单点 patch 清单。
+
+### 10.1 方案目标
+
+把 `work-ally` 中间层从“事件驱动的消息桥”升级为“带回合账本的交付桥”，目标是：
+
+1. 网络断开可以继续发生，但不再轻易造成语义不确定。  
+2. 用户不再需要通过猜测来判断上一轮是否完成。  
+3. bridge 可以明确区分：
+   - 执行是否完成
+   - 结果是否已持久化
+   - 结果是否已送达  
+4. 所有异常路径都能最终收敛到一个清晰状态，而不是悬空。
+
+### 10.2 设计原则
+
+#### 原则 A：事件是线索，账本才是真相
+
+`turn/completed`、`thread/status/changed`、`thread/read` 都应被视为收敛账本的输入，而不是最终真相本身。
+
+#### 原则 B：conversation、thread、turn、delivery 必须解耦
+
+- `conversation`：用户在哪个外部窗口里说话
+- `thread`：官方 runtime 的上下文连续性单元
+- `turn`：一次具体执行
+- `delivery`：某个 turn 的结果是否已成功送达用户
+
+当前问题的关键之一就是把 thread idle 与某个具体 turn 完成混得太近。
+
+#### 原则 C：断线后的默认状态不应是 failed，而应是 unknown / pending-recovery
+
+如果系统还没有权威证据说明 turn 失败，就不应该为了尽快清理内存态而把它直接打成失败。
+
+#### 原则 D：结果先持久化，再送达
+
+只要 runtime 已经产出终态结果，中间层就应先把这份结果写入本地稳定账本，再尝试发往 Feishu。这样即使发信道再断，语义也只是“延迟送达”，不是“结果丢失”。
+
+### 10.3 建议的回合账本模型
+
+建议在现有 session store / archive 之上，再明确一层以 turn 为中心的持久账本。最小字段建议至少包括：
+
+- `conversation_id`
+- `thread_id`
+- `turn_id`
+- `source_message_id`
+- `source_message_text_preview`
+- `accepted_at`
+- `started_at`
+- `execution_status`
+  - `accepted`
+  - `running`
+  - `waiting_user`
+  - `unknown`
+  - `completed`
+  - `failed`
+  - `interrupted`
+- `result_persisted_at`
+- `delivery_status`
+  - `not_ready`
+  - `pending`
+  - `delivered`
+  - `delivery_failed`
+- `delivery_attempts`
+- `final_reply_excerpt`
+- `final_error`
+- `superseded_by_turn_id`（如会话已推进）
+
+关键点不在字段多少，而在于把“执行状态”和“送达状态”拆开。
+
+### 10.4 建议的状态流转
+
+#### 正常路径
+
+1. 用户消息进入 bridge -> `accepted`
+2. runtime `turn/start` 成功 -> `running`
+3. runtime 返回 approval / user input -> `waiting_user`
+4. runtime 进入终态 -> `completed` 或 `failed`
+5. 终态结果写本地账本 -> `result_persisted`
+6. 结果送达 Feishu -> `delivery_status=delivered`
+
+#### 断线路径
+
+1. websocket 断开时，正在运行中的 turn 不直接改 `failed`
+2. 改为 `unknown` 或 `pending_recovery`
+3. 恢复后围绕这个 turn 持续收敛：
+   - 若补读到终态 -> 写终态与结果
+   - 若运行仍在继续 -> 回到 `running`
+   - 若在有界窗口后仍无法确认 -> 才转 `failed_unconfirmed` 或 `recovery_required`
+
+#### 会话已前进的路径
+
+如果用户已经开始下一轮，上一轮恢复出的结果不应再无条件弹给用户，而应进入明确分支：
+
+- 如果上一轮结果尚未送达且仍对当前上下文有意义，可作为“迟到结果”挂到系统通知层，由产品规则决定是否回告
+- 如果已被后续回合明确覆盖，应标记 `superseded`，写 archive，但不再在聊天中强行复活旧任务
+
+### 10.5 对 runtime 协议的依赖边界
+
+这类问题能否“彻底根治”，取决于上游 runtime 提供什么级别的协议保证。
+
+#### 如果上游只提供当前级别能力
+
+即：
+
+- `turn/completed` 事件
+- `thread/status/changed`
+- `thread/read`
+
+那么中间层仍然能做到很大程度的治理，但严格意义上的“数学级 exactly-once 交付”仍然做不到。因为系统始终可能遇到这样一个区间：
+
+- runtime 已完成
+- 完成事件未送达
+- `thread/read` 在短窗口内也未包含足够信息
+
+这种情况下，中间层只能做到“有界不确定 + 不丢证据 + 不误复活旧任务”，而不能凭空创造不存在的上游真相。
+
+#### 如果上游能提供更强契约
+
+例如：
+
+- 按 `turn_id` 直接查询终态结果
+- completed 事件可重放
+- 结果存在稳定持久化 ID
+- delivery independent result fetch
+
+那么中间层就能把这类问题治理到用户基本无感。
+
+### 10.6 面向 `work-ally` 的产品合同升级
+
+基于上述分析，建议把用户可见合同升级为下面这套更稳定的语义。
+
+#### 合同 1：已收到 != 已完成
+
+中间层必须明确区分：
+
+- 已收到
+- 已开始执行
+- 已完成但待送达
+- 已完成并送达
+
+#### 合同 2：连接恢复 != 任务恢复
+
+这条合同当前文档里已经开始强调，但还需要在内部状态机上真正落实。
+
+#### 合同 3：未确认完成前，不直接宣告失败
+
+运行基础设施错误与业务执行失败必须分开。
+
+#### 合同 4：结果已生成后，不因渠道抖动而丢失
+
+只要结果进入中间层，就必须能重新投递或由 `/status` / 系统通知找回。
+
+#### 合同 5：旧任务不应在会话已推进后被意外复活
+
+这是 `docs/completed/SPEC-middleware-exception-visibility.md` 已经指出的 stale redelivery 问题，应与 turn recovery 一并治理。
+
+## 11. 对“能否根治”的架构判断
+
+### 11.1 哪一层不能根治
+
+“网络永不断、进程永不崩、上游事件永不丢”这件事不能根治。
+
+也就是说，传输层事故本身永远存在。
+
+### 11.2 哪一层可以根治
+
+“因为中间层设计不完善，导致用户必须靠猜来判断结果是否丢了”这件事是可以被根治的。
+
+根治方式不是把所有事故消灭，而是把事故从“语义不确定”降级为“送达延迟”或“明确待确认”。
+
+### 11.3 结论
+
+因此，针对这类问题，最终判断应当是：
+
+> 传输故障本身不能根治，但中间层把故障放大成用户语义混乱，这件事可以被根治。
+
+前提是 `work-ally` 不再把自己当成“转发器”，而是明确把自己设计成“带回合账本的交付层”。
+
+## 12. 对当前仓库的具体启示
+
+本次 incident 对当前仓库至少给出六条明确启示：
+
+1. `SPEC-runtime-connection-and-turn-recovery-semantics.md` 讨论的是 bounded confirmation，但还需要继续升级为更强的 turn delivery contract。  
+2. `docs/completed/SPEC-middleware-exception-visibility.md` 提到的 swallowed-risk、stale redelivery 不是旁支，而是同一类问题。  
+3. `SPEC-session-presence-and-state-visibility.md` 中“用户不能靠猜判断 assistant 在做什么”这一点，与 recovery 语义治理是同一主线。  
+4. `SPEC-stable-archive-contract.md` 已经提供了事实原材料层；下一步缺的是“从 archive / session / delivery 合同向上收敛真相”的那一层。  
+5. `session store` 现在更像 conversation 台账，还不是回合级交付账本。  
+6. 当前 `receiver` 与 `runtime-client` 的异常路径设计，仍然偏向“尽快结束内存状态”，而不是“持续收敛回合真相”。
+
+## 13. 建议后续专题拆分
+
+如果把这件事转成后续架构工作，建议至少拆成下面几个专题，而不是混成一个大而全的“修 recovery”。
+
+### 专题 A：Turn Delivery Contract
+
+定义：
+
+- turn 的执行状态
+- turn 的结果持久化状态
+- turn 的用户送达状态
+- stale / superseded 语义
+
+### 专题 B：Runtime Recovery Truth Model
+
+定义：
+
+- 哪些 runtime 事件是线索
+- 哪些状态是账本真相
+- 哪些条件下可以从 `unknown` 收敛到 `completed` / `failed`
+
+### 专题 C：User-visible Incident Semantics
+
+定义：
+
+- 什么情况下提示“继续等待”
+- 什么情况下提示“结果已生成但尚未送达”
+- 什么情况下提示“请重发上一条消息”
+
+### 专题 D：Late Result / Stale Replay Policy
+
+定义：
+
+- 用户已经聊到后面时，旧结果是否还要回告
+- 旧结果是否只进 archive
+- `/status` 如何暴露迟到结果
+
+## 14. 最终结论
+
+这次 2026-03-14 21:47 的故障，表面上看是一次 runtime websocket 断开与 turn reconciliation 失败。
+
+但从更深层看，它暴露的不是单点 bug，而是一个典型的中间层语义问题：
+
+> 中间层当前还没有把“用户消息 -> runtime 执行 -> 结果持久化 -> 结果送达”建模成一笔可恢复的回合交易。
+
+因此它在 happy path 下是一个桥，
+但在异常路径下还不是一个足够强的交付层。
+
+如果继续把它当成“消息桥”，这类问题只能不断被修补；
+如果把它升级成“带回合账本的交付桥”，这类问题可以从用户视角被系统性治理。
+
+一句话收束：
+
+> 本次 incident 的根因不是“消息没转发过去”，而是“中间层没有掌握回合级确定性”；真正的长期解法不是补更多异常分支，而是补上这份确定性的账本与合同。