work-ally 0.2.0-alpha.1

package/docs/planning/SPEC-runtime-abstraction-phase-1.md

@@ -0,0 +1,424 @@
+# Runtime Abstraction Phase 1
+
+## Status
+
+- Target project: `work-ally`
+- Audience: product owner / implementation engineer
+- Scope: runtime contract, Codex adapter refactor, bridge decoupling, compatibility guardrails
+- Status: planning
+- Goal: introduce a formal runtime abstraction layer behind the current Codex implementation without changing shipped product behavior
+
+## Summary
+
+Phase 1 是一次**重构型 spec**，不是功能扩展 spec。
+
+它要解决的问题不是“现在就支持 Claude”，而是：
+
+> 先把 `work-ally` 里和底层 runtime 相关的隐式假设收成稳定 contract，并把当前 Codex 路径改造成第一套正式 implementation。
+
+这条 spec 有一个硬约束：
+
+> **Phase 1 做完后，现有用户功能、默认行为、产品语义都不应变化。**
+
+也就是说：
+
+- 现在用 Codex 的用户不需要学习新概念
+- Feishu 侧现有 thread / approval / user input / progress / recover / routine 行为都应维持
+- Phase 1 的价值是架构清晰度、测试边界和未来扩展能力，而不是对外新 feature
+
+如果未来永远不做 Claude，Phase 1 仍然值得做；因为它本身就能让 `work-ally` 从“Codex 绑定实现”升级成“Codex-first 的 runtime bridge”。
+
+## Background
+
+当前仓库已经有一些 runtime seam，但它们仍然是隐式的、工程方便层的：
+
+- `bridge/src/receiver.ts` 中存在 `RuntimeLike`
+- `bridge/src/server.ts` 中已经可以在 fake / codex 之间切换
+- `bridge/src/fake-runtime-client.ts` 已经承担了大量 integration 测试职责
+
+但与此同时，当前 shipped 能力又明显依赖 Codex 语义：
+
+- thread / turn 连续性
+- approval / user input
+- interrupt / recover
+- progress heartbeat
+- runtime connection lifecycle
+- routine 执行与只读运行约束
+
+这就形成了一个典型问题：
+
+- 不抽象，后续任何第二 runtime 接入都会重新痛一次
+- 抽象过猛，又容易把现有 Codex 行为打散，伤到主线稳定性
+
+因此必须先有一份明确的 Phase 1 spec，把“怎么抽”和“什么绝对不能动”一次写清楚。
+
+## Problem Statement
+
+Phase 1 要解决四个问题。
+
+### 1. 当前 runtime contract 是隐式的
+
+现在 bridge、server、routine、tests 对 runtime 的要求分散在多个文件里，没有一份正式合同说明：
+
+- runtime 必须提供什么
+- runtime 可选提供什么
+- bridge 允许按什么能力降级
+
+### 2. 代码里还存在 Codex-specific 主逻辑分叉
+
+当前一些行为仍然通过具体实现类型判断，例如：
+
+- 直接依赖 `CodexRuntimeClient`
+- 用 `instanceof` 判断是否启用某些 runtime 特性
+
+这会让未来的第二 runtime 接入变成“到处补例外”。
+
+### 3. 没有明确的兼容性护栏
+
+当前虽然知道“不能把 Codex 搞坏”，但没有一份明确的产品级、测试级护栏说明：
+
+- 哪些能力必须零回归
+- 哪些行为允许内部重构但对外不变
+- 哪些文档和验收口径需要跟着更新
+
+### 4. 后续扩展路径还没被产品化定义
+
+Phase 1 之后的产品应该是什么？
+
+正确答案不是“现在支持多 runtime”，而是：
+
+- 产品口径升级为 runtime bridge
+- Codex 成为第一套 reference implementation
+- 后续 runtime 可以按 contract 接入
+
+如果这点不写清楚，Phase 1 很容易被误读成“为未来可能存在的功能做技术预埋”。
+
+## Product Decision
+
+### Decision 1: Phase 1 是必做的内功，不依赖 Claude 是否成立
+
+Phase 1 的成立条件不包含 Claude。
+
+它本身就是一个独立成立的产品改进：
+
+- 明确 runtime contract
+- 收紧代码边界
+- 固化回归护栏
+- 保住 Codex 当前稳定体验
+
+### Decision 2: Phase 1 严禁用户语义变化
+
+这条 spec 的最重要约束是：
+
+> 不允许把“架构重构”包装成“顺手改行为”。
+
+Phase 1 期间禁止借机改动：
+
+- 用户入口命令语义
+- 默认 approval / sandbox 行为
+- `/status` 的核心语义
+- Feishu 进度、恢复、审批、user input 的产品合同
+- routine 的运行模式与只读边界
+
+### Decision 3: Codex 是第一套正式 adapter，不是历史包袱
+
+Phase 1 不是把 Codex 边缘化，而是把它提升成：
+
+- 第一套正式 runtime adapter
+- capability 最完整的 reference implementation
+- 所有未来 runtime 的对照基线
+
+### Decision 4: 抽象只到 `work-ally` 真正需要的层级
+
+Phase 1 不做：
+
+- 通用模型平台
+- provider 配置中台
+- 跨 runtime 原生 thread 迁移
+- 大而全多引擎控制面
+
+只做：
+
+- `work-ally` 真正依赖的 runtime contract
+- bridge 对 runtime 能力的消费边界
+
+## Goals
+
+1. 在仓库内建立正式 runtime contract
+2. 把当前 Codex 路径改造成 contract 下的第一套正式 implementation
+3. 让 bridge / server / routine / tests 依赖 contract，而不是直接依赖 Codex 实现类
+4. 为未来第二 runtime 接入留出明确扩展口
+5. 在整个 Phase 1 过程中保持现有产品功能和行为稳定
+
+## Non-goals
+
+Phase 1 不做：
+
+- 新增第二 runtime 的正式支持
+- 对用户开放 runtime 切换能力
+- 自建统一 prompt / persona / provider 平台
+- 重写 approval / recovery / scheduler 产品语义
+- 借重构名义推进新的用户功能
+
+## Scope
+
+### In scope
+
+1. 定义正式 runtime contract 与 capability profile
+2. 定义 runtime-native IDs 与 `work-ally` product IDs 的边界
+3. 重构 `CodexRuntimeClient` 为正式 Codex adapter
+4. 升级 fake runtime，使其跟正式 contract 对齐
+5. 让以下模块只依赖 contract：
+   - `Receiver`
+   - `RuntimeApp`
+   - routine 执行入口
+   - runtime status / recovery orchestration
+6. 补齐回归测试与验收基线
+7. 回写相关 planning / README / implementation 口径
+
+### Out of scope
+
+1. Claude Runtime Host
+2. 第二 runtime 的生产接入
+3. 用户可见 runtime selector
+4. 跨 runtime 会话迁移
+
+## Runtime Contract
+
+Phase 1 需要定义一份正式 contract。建议至少包含下面这些对象。
+
+### 1. Core interfaces
+
+- `RuntimeAdapter`
+- `RuntimeCapabilityProfile`
+- `RuntimeSessionStatus`
+- `RuntimeTurnResult`
+- `RuntimeProductEvent`
+
+### 2. Product-owned identifiers
+
+由 `work-ally` 自己持有：
+
+- `conversation_ref`
+- `session_key`
+- delivery target
+- assistant / workspace 绑定关系
+
+由 runtime 提供并由 adapter 挂接：
+
+- `runtime_name`
+- `runtime_session_id` / `runtime_thread_id`
+- `runtime_turn_id`
+- runtime-native gate IDs
+
+原则：
+
+> `work-ally` 不把自己的产品主身份交给 runtime 托管。
+
+### 3. Required capabilities
+
+正式 runtime 至少必须满足：
+
+1. `healthcheck`
+2. `start_session`
+3. `run_turn`
+4. `interrupt_turn`
+5. `read_session_status`
+6. `disconnect`
+
+关于 `resume_session`：
+
+- Phase 1 文档中要明确它是重要能力
+- 但是否把它列为所有正式 runtime 的硬门槛，可留给后续产品判断
+- 对 Codex adapter 而言，仍必须保留当前 resume 语义
+
+### 4. Optional capabilities
+
+可选能力至少包括：
+
+- structured progress stream
+- turn result recovery
+- connection lifecycle events
+- finer-grained active flags
+- runtime-native metadata
+
+bridge 可以基于 capability profile 做降级，但降级语义必须明文定义。
+
+### 5. Product gate semantics
+
+Phase 1 先把合同定义好：
+
+- bridge 依赖的是“产品级 gate semantics”
+- 不要求所有 runtime 的原生 gate 事件长得一样
+
+但在 Phase 1 内，Codex adapter 仍应完整保留当前 approval / user input 行为。
+
+## Compatibility Guardrails
+
+这是 Phase 1 的核心章节。
+
+### 1. 必须零回归的能力面
+
+Phase 1 完成后，以下能力必须零回归：
+
+- thread / session 连续性
+- approval flow
+- user input flow
+- interrupt / stop
+- turn recovery
+- `/status` 输出的核心语义
+- progress heartbeat
+- routine / scheduler 执行链路
+- runtime connection lifecycle 可见性
+
+### 2. 不允许变化的用户口径
+
+以下对外口径不得在 Phase 1 被静默改变：
+
+- 用户入口仍只有 `ally.sh`
+- 当前默认底层 runtime 仍是 Codex
+- 现有 Feishu 回复、审批、异常回告语义不变
+- 现有 desk / workspace / runtime 资产边界不变
+
+### 3. 不允许为了抽象而削平 Codex 体验
+
+如果某抽象会让 Codex 当前 richer semantics 被迫退化成最小公分母，就应视为错误抽象。
+
+产品判断非常明确：
+
+> Phase 1 的抽象必须服务于稳定扩展，而不是反向阉割当前最成熟的实现。
+
+## Implementation Direction
+
+### Step 1: Contract first
+
+先定义类型和接口，不先大改实现。
+
+需要先落地：
+
+- runtime contract types
+- capability profile
+- bridge 消费 contract 的最小接口
+
+### Step 2: Codex adapter
+
+把当前 Codex 路径收成正式 adapter，例如：
+
+- `CodexRuntimeAdapter`
+
+要求：
+
+- 现有行为不变
+- 现有测试继续成立
+- 不再让外层主逻辑直接依赖 `CodexRuntimeClient`
+
+### Step 3: Fake runtime alignment
+
+把 fake runtime 升级成正式 contract 下的测试实现。
+
+目标：
+
+- integration tests 继续跑得动
+- 后续第二 runtime 不需要重写整套测试思路
+
+### Step 4: Bridge decoupling
+
+逐步把以下模块切到 contract：
+
+- `Receiver`
+- `RuntimeApp`
+- routine 入口
+- recovery / status / lifecycle 编排
+
+### Step 5: Documentation and acceptance
+
+完成后同步回写：
+
+- README 的长期产品口径
+- implementation guide 中的架构边界描述
+- planning 文档中关于 runtime 的术语
+
+## Testing And Validation
+
+Phase 1 必须把“零回归”做成明确验证项，而不是口头承诺。
+
+### 1. Unit / integration baseline
+
+至少保住当前这些方向的测试：
+
+- runtime client / adapter
+- approval flow
+- user input flow
+- control commands
+- continuity flow
+- progress heartbeat
+- routine delivery
+- recovery semantics
+
+### 2. Manual acceptance baseline
+
+至少需要重新走一轮最小人工验收：
+
+- 正常对话
+- 继续同一 thread
+- `/new`
+- approval
+- user input
+- interrupt
+- runtime 短暂断连后的恢复语义
+
+### 3. Refactor discipline
+
+Phase 1 期间如果发现：
+
+- 某抽象会导致现有测试大面积改写
+- 某模块必须大量引入 runtime-specific 例外逻辑
+
+应先停下来回看 contract，而不是硬往前推。
+
+## Deliverables
+
+Phase 1 完成时，应至少交付：
+
+1. 一份正式 runtime contract
+2. 一套 `CodexRuntimeAdapter`
+3. 一套跟 contract 对齐的 fake runtime
+4. 一组明确的 compatibility tests / acceptance baseline
+5. 回写后的项目文档口径
+
+## Acceptance Criteria
+
+1. 仓库内存在正式 runtime contract，而不是分散的隐式假设
+2. bridge / server / routine 主链路已依赖 contract，而不是直接依赖 Codex 类
+3. Codex 现有用户路径零回归
+4. fake runtime 已对齐 contract，测试夹具继续可用
+5. Phase 1 结束后，用户默认仍只感知到 Codex 路径，没有新增学习成本
+6. README / implementation / planning 对 runtime 的口径已经统一到“runtime bridge, Codex-first”
+
+## Risks
+
+### 1. 抽象过早，做成平台化工程
+
+会拖慢节奏，也会偏离 `work-ally` 的产品边界。
+
+### 2. 抽象过薄，只是换名字
+
+如果只是把类名改掉，而没有 contract 和 capability profile，未来第二 runtime 接入时仍然会重新痛一次。
+
+### 3. 兼容性护栏不够硬
+
+如果没有测试和人工验收护栏，Phase 1 很容易在“内部看起来更优雅”的同时，悄悄损伤 Codex 主线体验。
+
+## Open Questions
+
+1. `resume_session` 是否应在长期上被定义为正式 runtime 的硬门槛
+2. `/status` 中是否要在 Phase 1 就先补一层 runtime capability 摘要，还是等第二 runtime 真出现再加
+3. README 是否在 Phase 1 完成后就更新为 runtime bridge 口径
+
+## Product Judgment
+
+Phase 1 不是在给 Claude 铺路而已。
+
+它本身就是一个独立成立的产品整理动作：
+
+> 把 `work-ally` 从“Codex 绑定实现”收成“Codex-first 的 runtime bridge”，同时不让当前用户承担任何行为变化成本。

package/docs/planning/SPEC-runtime-connection-and-turn-recovery-semantics.md

@@ -0,0 +1,274 @@
+# SPEC: Runtime Connection And Turn Recovery Semantics
+
+更新时间：2026-03-14  
+状态：Draft / In implementation
+
+## 1. 背景
+
+两份 incident / analysis 已经把问题说清楚了：
+
+- 当前 bridge 已经有 runtime 断连可见性、stale turn suppression、bounded recovery
+- 但最终正确性仍然过度依赖在线事件顺序
+- 一旦 `turn/completed` 丢失、transport 抖动、渠道发送失败，系统就会对三件事失去确定性：
+  - 这条 inbound message 是否真的进入了 Codex turn
+  - 这轮 turn 最终是否已经完成
+  - 完成后的结果是否真的送到了用户面前
+
+因此，本专题不再把问题理解成“补一个 recovery patch”，而是收口为：
+
+> bridge 需要最小的 inbound acceptance + turn execution + delivery ledger，并把最终 turn 真相切到 pull-primary，才能把异常路径从“靠猜”变成“有据可查”。
+
+## 2. 问题定义
+
+当前缺口不是没有 recovery，而是没有一份足够收敛的 durable truth model 来回答下面五个问题：
+
+1. 这条用户消息是否已经被 bridge 接住
+2. 它是否已经真正进入 Codex thread，并绑定到某个 turn
+3. 当前处于 running / waiting / pending_recovery / recovery_required / completed 哪一态
+4. 终态结果是否已经被 bridge 持久化
+5. 用户所在渠道是否真的收到过这份结果
+
+如果没有这套模型，bridge 就只能做到：
+
+- 在线时尽量转发
+- 异常时尽量猜测
+- 猜不到就要求用户重发
+
+这不足以支撑 `work-ally` 作为稳定协作入口的产品定位。
+
+## 3. 目标
+
+1. 在不把中间层做成厚重任务引擎的前提下，补齐最小的 inbound acceptance + turn execution + delivery ledger
+2. 把 turn 终态确认从 push-first 调整为 pull-primary, push-assisted
+3. 明确区分“入站确认状态”“执行状态”和“送达状态”
+4. 让 stale / superseded / recovery_required 都成为持久事实，而不是只留在日志里
+5. 继续坚持 `Connection state != Task state`
+6. 为后续 `/status`、异常透明化、迟到结果策略提供稳定基础
+
+## 4. 非目标
+
+本期不做：
+
+- 不实现 exactly-once 提交协议
+- 不实现断点续跑执行引擎
+- 不实现自动重投 worker
+- 不新增复杂监控面板
+- 不把 threadId / turnId 暴露给普通飞书用户
+- 不把 approval / user-input 请求重构成完全离线恢复协议
+
+## 5. 核心判断
+
+### 5.1 pull-primary, push-assisted
+
+- 最终答复、最终失败/中断状态、recovery 对账，以 `thread/read(includeTurns=true)` 主动拉取为准
+- `turn/completed`、`item/*`、`thread/status/changed` 不再承担最终真相职责；它们最多是缓存或实时体验线索
+- approval / user input 继续走在线事件流承接，因为当前协议没有等价的稳定 pull 列表接口来取回 request payload 与 callback id
+- runtime transport 生命周期默认只作为内部可观测性，不再直接翻译成面向用户的“连接已断开 / 已恢复”产品文案
+
+### 5.2 事件是线索，不是最终账本
+
+以下能力都只是账本收敛的输入，不是唯一真相：
+
+- `turn/completed`
+- `thread/status/changed`
+- runtime push item events
+- runtime reconnect lifecycle
+
+其中真正承担 durable terminal truth 的，是 bridge 主动发起的 `thread/read(includeTurns=true)` 对账。
+
+### 5.3 Session Store 需要从“会话台账”升级到“acceptance + turn ledger”
+
+当前 session store 已经负责：
+
+- conversation -> thread 映射
+- active turn
+- approvals / user inputs
+- inbound dedupe
+
+本期在此基础上增加两层最小持久事实：
+
+- `inbound-ledger/`：每条 inbound message 一份 JSON，记录该消息是否已被 bridge 接住、是否已真正进入某个 turn
+- `turn-ledger/`：每个 turn 一份 JSON，记录 bridge 已经天然知道的执行与送达事实
+
+不新增第二套 runtime，也不把 bridge 做成任务引擎。
+
+### 5.4 执行完成不等于送达完成
+
+bridge 至少要区分：
+
+- runtime 已经产生终态结果
+- 用户已经在渠道里看到结果
+
+否则 channel 抖动会被误读成“模型没做完”。
+
+### 5.5 stale suppression 不是“静默忽略”，而是 superseded
+
+一旦会话已被新消息推进：
+
+- 对用户：旧 turn 输出必须被抑制，避免串话
+- 对账本：旧 turn 必须进入 `superseded`
+
+## 6. V1 Inbound Acceptance Ledger 合同
+
+每条 inbound message 至少记录：
+
+- `messageId`
+- `threadId`
+- `turnId`
+- `createdAt`
+- `updatedAt`
+- `acceptedAt`
+- `executionStatus`
+  - `received`
+  - 以及与 turn ledger 对齐后的 `running / waiting_approval / waiting_user_input / pending_recovery / recovery_required / completed / failed / interrupted / superseded`
+
+它回答的问题是：
+
+- 这条消息是否只是到达 bridge
+- 它是否已经真正绑定到某个 `turnId`
+- 如果 bridge 中途抖动，这条消息是否允许被重新处理
+
+## 7. V1 Turn Ledger 合同
+
+每个 turn 至少记录：
+
+- `turnId`
+- `threadId`
+- `messageId`
+- `promptPreview`
+- `executionStatus`
+  - `running`
+  - `waiting_approval`
+  - `waiting_user_input`
+  - `pending_recovery`
+  - `recovery_required`
+  - `completed`
+  - `failed`
+  - `interrupted`
+  - `superseded`
+- `runtimeStatus`
+- `replyPreview`
+- `error`
+- `resultPersistedAt`
+- `deliveryStatus`
+  - `not_ready`
+  - `pending`
+  - `delivered`
+  - `suppressed`
+  - `delivery_unavailable`
+- `deliveredAt`
+- `supersededByMessageId`
+- `supersededByTurnId`
+- `supersededReason`
+
+## 8. 状态流转
+
+### 8.1 正常路径
+
+1. `noteInboundObserved` -> inbound ledger 进入 `received`
+2. `turn/start` 成功返回 `turnId` 后，入站账本绑定 `threadId / turnId / acceptedAt`
+3. 启动 pull-primary final-state poll；在线 `turn/completed` 只作为 fast-path
+4. approval / user input / progress 仍通过 push 通道实时承接
+5. terminal result persisted -> `completed / failed / interrupted`, `deliveryStatus=pending`
+6. 渠道发送成功 -> `deliveryStatus=delivered`
+7. 渠道发送失败但属于 non-fatal channel delivery -> `deliveryStatus=delivery_unavailable`
+8. 若上一轮终态结果已持久化但当时未稳定送达，则下一条 inbound 到来时优先自动补发；只有补发仍失败时才退回系统说明
+
+### 8.2 recovery 路径
+
+1. runtime infra error 进入 recovery attempt -> `pending_recovery`
+2. recovery 成功补读终态 -> 正常收口到 terminal state
+3. recovery 失败并提示用户重发 -> `recovery_required`
+
+### 8.3 session advanced 路径
+
+如果旧 turn 已被新消息推进：
+
+- 旧 turn 输出对用户不可见
+- 账本标记 `executionStatus=superseded`
+- `deliveryStatus=suppressed`
+- 记录 `supersededByMessageId / supersededByTurnId / supersededReason`
+
+## 9. 实现要求
+
+### 9.1 Session Store
+
+- 增加 `inbound-ledger/` 目录
+- 增加 `turn-ledger/` 目录
+- 提供最小 inbound acceptance API：
+  - observed / received
+  - accepted_to_turn
+  - execution_status synced from turn ledger
+- 提供最小 turn ledger API：
+  - running
+  - waiting_approval
+  - waiting_user_input
+  - pending_recovery
+  - recovery_required
+  - terminal persisted
+  - delivered / delivery_unavailable
+  - superseded
+
+### 9.2 Receiver
+
+- 在 inbound receipt claim 时先记录 `received`
+- 在 `onTurnStarted` 时把 inbound 与 `threadId / turnId` 绑定
+- 在 approval、user-input、recovery、final delivery 等关键路径更新 ledger
+- stale suppression 不只写 archive event，还要把旧 turn 标记为 `superseded`
+- 对 recovery required、final reply、completion without reply、terminal error 等用户可见消息，记录 delivery outcome
+- 对 `delivery_unavailable` 的上一轮终态结果，在后续 inbound 进入时优先自动补发；只有补发失败时才发解释性系统说明
+
+### 9.3 Runtime Client
+
+- 一旦 `turn/start` 返回 `turnId`，立即启动 bounded pull poll
+- `turn/completed` 与 runtime push item 事件继续保留，但不再作为 final reply / terminal status 的可信来源
+- 断连后不立即把活动 turn 判死，而是优先等待 pull-primary 对账
+- 对用户不再主动转发 runtime transport 生命周期，只保留任务状态语义
+- 不额外承担 delivery ledger 逻辑
+
+## 10. 验收标准
+
+1. 收到 inbound 后，即使后续 ack 发送失败，仍能在 `inbound-ledger/<messageId>.json` 看见 `executionStatus=received`
+2. `turn/start` 成功后，对应 inbound ledger 必须落成：
+   - `threadId` 与 `turnId` 已绑定
+   - `acceptedAt` 已写入
+3. 即使在线 `turn/completed` 丢失，只要 `thread/read(includeTurns=true)` 已经看到该 turn 终态，`runTurn()` 仍能正常返回最终结果
+4. runtime infra error 触发 recovery required 后，对应 turn ledger 必须落成：
+   - `executionStatus=recovery_required`
+   - `deliveryStatus=delivered` 或 `delivery_unavailable`
+5. recovery 成功补发最终结果后，对应 turn ledger 必须落成：
+   - `executionStatus=completed`
+   - `deliveryStatus=delivered` 或 `delivery_unavailable`
+6. 旧 turn 被新消息推进后，对应 turn ledger 必须落成：
+   - `executionStatus=superseded`
+   - `deliveryStatus=suppressed`
+7. 多轮 ping-pong 后，不残留错误 active turn，且账本不把新 turn 覆盖成旧 turn
+8. 若上一轮终态结果已持久化且 `deliveryStatus=delivery_unavailable`，下一条 inbound 到来时会优先自动补发上一轮结果；只有补发仍失败时才提示用户
+9. 文档明确说明：connection 恢复 != task 恢复；执行完成 != 用户已收到；bridge 收到 inbound != 已进入 Codex turn
+
+## 11. 风险与边界
+
+### 风险 1：会不会把中间层做太厚
+
+当前判断：不会。
+
+原因是这层 ledger 只记录 bridge 已经天然知道的事实，不新增第二套任务执行语义，不替代 runtime。
+
+### 风险 2：为什么不直接做自动重投
+
+因为那是下一层能力。
+
+本期先把“我是否知道这轮发生了什么”补齐；真相没收干净之前，先堆自动重投会继续放大歧义。
+
+## 12. 结论
+
+本专题从“连接恢复语义”进一步收束为一句更准确的话：
+
+> bridge 不是只负责转发事件，而是要为每条 inbound 与每一轮 turn 维护最小的确认、执行与送达账本，并把最终 turn 真相切到主动拉取。
+
+这样即使 runtime 断连、事件迟到、会话前进，系统也能明确知道：
+
+- 这条用户消息是否真的进入了 Codex
+- 这轮做到哪一步
+- 用户有没有真的收到
+- 这轮是不是已经被后续回合覆盖