work-ally 0.2.0-alpha.1

package/docs/planning/SPEC-bridge-app-server-protocol-alignment.md

@@ -0,0 +1,667 @@
+# SPEC: Bridge App Server Protocol Alignment
+
+更新时间：2026-03-17  
+状态：Ready for implementation  
+Owner：work-ally engineering  
+相关文档：
+- `docs/planning/SPEC-runtime-connection-and-turn-recovery-semantics.md`
+- `docs/planning/SPEC-session-presence-and-state-visibility.md`
+- `docs/issues/resolved/ANALYSIS-runtime-turn-delivery-and-recovery-2026-03-14.md`
+- `docs/issues/resolved/ANALYSIS-codex-app-server-transport-disconnect-semantics-2026-03-14.md`
+- `docs/issues/resolved/REPORT-ally-runtime-turn-delivery-3b42fb8-2026-03-15.md`
+
+## 1. Summary
+
+这份 spec 不是再补一个“断连恢复” patch，而是把 `work-ally` 的 bridge 重新收回到正确边界：
+
+> bridge 不是任务裁判，也不是第二个 agent；它应该是 **Codex App Server 协议事实的转发器 + 最小编排器**。
+
+当前稳定性问题的根因，已经不再应理解成“Codex 经常不稳定”，而应理解成：
+
+1. 我们的 bridge 还保留了一层自定义的任务语义
+2. 这层语义与官方 App Server 原语并不完全一致
+3. 一旦 transport 抖动、waiting request、迟到终态或用户追问叠在一起，bridge 就会替用户过早下结论，导致消息没正确转给 Codex，或 Codex 的真实结果没被稳定转回来
+
+本次要做的，是一次协议对齐型重构：
+
+1. 普通自然语言输入回归 `turn/start` / `turn/steer` 主路径
+2. `waitingOnApproval` / `waitingOnUserInput` 回归线程事实，而不是 bridge 主观阻塞结论
+3. 最终结果继续坚持 `pull-primary`
+4. transport 生命周期降回内部可观测性，不再直接翻译成任务终态
+5. 只有 slash 命令和明确的 approval / user-input 回答，才由 bridge 本地消费
+
+这份 spec 写完之后，未来的实现工作应直接按本文件推进，而不是继续依赖“记得之前聊过什么”。
+
+## 2. 背景
+
+目前我们已经做过几轮稳定性修复，收住了几件重要事情：
+
+1. 最终结果已经切到 `pull-primary`
+2. `turn/completed` 不再是唯一真相
+3. inbound / turn / delivery ledger 已经建立最小台账
+4. waiting artifact 是否已真正可见，已经进入状态判断
+
+这些工作是正确方向，但它们还没有彻底解决一个更根本的问题：
+
+> bridge 仍然在协议事实之上，额外创造了一层“本地任务语义”。
+
+这层语义主要体现在：
+
+1. busy 时，普通自然语言会被本地拦截，而不是优先回到协议原语
+2. waiting 时，bridge 可能先根据 thread flag 自己认定“现在不能转给 Codex”
+3. 某些终态会被 bridge 翻译成 `当前任务已停止`、`当前已暂停`、`请重发` 等结论性语言
+4. transport 生命周期、任务状态、用户可见状态，这三层仍然存在混淆
+
+这就是为什么用户会体感到：
+
+1. 我的话到底有没有传给 Codex，不确定
+2. Codex 明明已经继续工作了，但飞书前面看不到结果
+3. assistant 明明只是卡在 approval / user input，可用户前面像“人没了”
+4. 中间层表现得像在“帮我判断真相”，而不是在“老老实实转发真相”
+
+## 3. 问题定义
+
+当前问题不是单点 bug，而是 4 类系统性偏差。
+
+### 3.1 输入路由偏差
+
+除 slash 命令外，飞书用户的输入本应默认属于“发给 Codex”。
+
+但当前 bridge 仍会在某些 busy / waiting 场景下，先做本地拦截和本地解释。这会导致两个问题：
+
+1. 用户以为自己在追问 Codex，实际却在和中间层对话
+2. bridge 一旦判断错，就会把用户输入吞在自己这里
+
+### 3.2 waiting 语义偏差
+
+`waitingOnApproval` / `waitingOnUserInput` 是 runtime thread 的事实，不等于“用户前台已经拿到了可操作实体”。
+
+当前系统虽然已经开始区分“flag visible”与“artifact visible”，但整体语义仍未完全收口：
+
+1. waiting 是线程事实
+2. blocking 是用户视角事实
+3. 只有当 approval card / user-input prompt 已稳定送达时，bridge 才能说“当前轮到你了”
+
+### 3.3 终态语义偏差
+
+bridge 仍然在一些路径上替用户下结论，例如：
+
+1. `当前任务已停止`
+2. `当前已暂停`
+3. `请重发上一条`
+
+其中有些是合理的产品翻译，有些则属于过度推断。
+
+正确边界应该是：
+
+1. `/stop` 触发的明确中断，才可以稳定翻译成“已停止”
+2. 其他 interrupted / transport failure / final-state unconfirmed，都只是事实不足，不该被 bridge 翻译成“任务就这样结束了”
+3. 只要终态还可继续对账，bridge 就不应过早终止用户理解
+
+### 3.4 传输层与任务层混淆
+
+官方 App Server 给的是协议原语和线程事实，不要求客户端把 transport 生命周期直接上升成任务语义。
+
+当前 bridge 虽然已经比以前克制，但整体设计上仍受到“在线 push 事件驱动 UI 语义”的影响。
+
+这会带来两个后果：
+
+1. 容易把 transport 抖动误读成任务失败
+2. 容易把在线事件缺失误读成 turn 不存在或任务没继续
+
+## 4. 为什么现在做
+
+现在必须做，不适合继续拖。
+
+原因有四个：
+
+1. 这已经不是一个“体验小瑕疵”，而是在损伤产品最核心的可信度
+2. 现在已经有足够多事故和证据，问题边界已比较清楚，再继续打补丁只会让状态机更脏
+3. 当前产品已经进入内部多人、多 assistant、长期打磨阶段，中间层语义如果不收干净，后续所有 feature 都会建立在错误地基上
+4. 这件事如果拖到更晚再做，后面要兼容的行为和文档只会更多，返工成本会更高
+
+## 5. 目标
+
+本次重构必须达成下面 8 个目标。
+
+1. 普通自然语言输入默认回归 Codex，而不是默认被 bridge 私自吞掉
+2. `turn/start` / `turn/steer` / `turn/interrupt` 成为输入控制主骨架
+3. `waitingOnApproval` / `waitingOnUserInput` 只表达线程事实，不直接等价于用户阻塞事实
+4. approval / user-input 只有在可操作实体已可见时，才进入真正 blocking 状态
+5. 最终结果继续以 `thread/read(includeTurns=true)` 为 pull-primary 真相源
+6. transport 生命周期彻底降级为内部可观测性，不再直接驱动用户任务结论
+7. `当前任务已停止` 这类强结论文案只保留在明确 `/stop` 语义内
+8. 测试门禁按协议矩阵重排，避免以后再按症状补 case
+
+## 6. 非目标
+
+这次明确不做：
+
+1. 不在本期把 transport 从 websocket 直接切到 stdio
+2. 不重做 Codex runtime host
+3. 不做新的 dashboard / GUI 运维面板
+4. 不做 exactly-once 分布式协议
+5. 不做 approval / user-input 的完全离线重放协议
+6. 不把 threadId / turnId 暴露给普通飞书用户
+7. 不在本期引入复杂队列系统或任务编排引擎
+
+说明：
+
+`stdio` 方向是值得考虑的，但那是独立运输层专题；本 spec 先解决“即便 transport 有波动，bridge 也不能误判任务语义”这个更核心的问题。
+
+## 7. 官方协议对齐判断
+
+本次重构只认下面这些官方事实。
+
+### 7.1 协议与传输
+
+1. App Server 是双向 JSON-RPC 协议
+2. 官方默认传输是 `stdio`
+3. `websocket` 在官方文档里仍是 experimental transport
+4. 客户端应围绕协议原语和线程事实构建 UI，而不是自行脑补第二套真相
+
+### 7.2 输入控制原语
+
+App Server 已给出 3 个关键输入控制原语：
+
+1. `turn/start`：开始新 turn
+2. `turn/steer`：向当前 in-flight turn 追加新的用户输入
+3. `turn/interrupt`：显式打断当前 turn
+
+### 7.3 线程状态事实
+
+App Server 已给出线程状态事件：
+
+1. `thread/status/changed`
+2. `activeFlags` 包括 `waitingOnApproval` / `waitingOnUserInput`
+
+### 7.4 审批事实
+
+App Server 会主动向客户端发起审批请求：
+
+1. `item/commandExecution/requestApproval`
+2. `item/fileChange/requestApproval`
+3. `serverRequest/resolved` 表示待处理请求已被回答或清除
+
+因此 bridge 的边界应该是：
+
+1. 接住这些协议事实
+2. 把它们翻译成用户能理解的最小产品语义
+3. 绝不把它们改写成 bridge 自己想象的另一个任务世界
+
+## 8. 产品定义与用户路径
+
+### 8.1 一句话产品定义
+
+本次重构后，`work-ally` 的 bridge 应表现为：
+
+> 除 slash 命令外，用户发给飞书的内容默认都是发给 Codex；bridge 只负责把协议事实稳定送进去，再把 Codex 的真实状态和结果稳定带回来。
+
+### 8.2 输入分类
+
+V1 只保留三类输入路径。
+
+#### A. 本地控制命令
+
+仍由 bridge 本地消费：
+
+- `/status`
+- `/stop`
+- `/new`
+- `/approve`
+- `/deny`
+- 其他明确 slash 控制命令
+
+#### B. Pending request 的直接回答
+
+当已经存在 **用户可见** 的 approval / user-input 请求时：
+
+1. 用户直接回复 `同意` / `拒绝` / 选项 / 表单答案
+2. bridge 将其解释为对当前 pending request 的回答
+3. 回答仍然要写回 Codex runtime
+
+这类输入不是“bridge 吞掉了用户的话”，而是 bridge 在履行协议里的 request/response 责任。
+
+#### C. 其他普通自然语言
+
+其余所有非 slash 文本，默认都视为要转给 Codex。
+
+默认路由规则：
+
+1. 当前无 active turn：`turn/start`
+2. 当前有 active turn 且没有 unresolved blocking request：`turn/steer`
+3. 当前有 unresolved blocking request：不新建本地任务，不假装“已经转发给 Codex”，而是明确告诉用户“当前正在等你处理这个 request；先完成它，这轮才能继续”
+
+这里最关键的约束是：
+
+> bridge 只在“官方协议本身明确要求先回答 pending request”时阻塞普通文本，而不是再发明额外的 busy gate 规则。
+
+### 8.3 用户主路径
+
+#### 路径 1：空闲线程中的普通提问
+
+1. 用户发消息
+2. bridge ack
+3. `turn/start`
+4. 结果以 pull-primary 收口
+5. 最终回复回到飞书
+
+#### 路径 2：active turn 中的追问 / 补充
+
+1. 用户发普通文本
+2. bridge 不本地吃掉
+3. 若线程可继续接受输入，则走 `turn/steer`
+4. Codex 在同一 turn 内继续处理
+
+#### 路径 3：approval / user-input 阻塞中
+
+1. runtime 发出 request
+2. bridge 先把可操作实体送达给用户
+3. 只有送达成功后，bridge 才进入 blocking waiting 状态
+4. 用户若直接回答该 request，则 bridge resolve 给 runtime
+5. 用户若发的是其他普通文本，则 bridge 明确说明“当前卡在这个 request 上”，但不把这条文本伪装成已转给 Codex
+
+#### 路径 4：用户显式停止
+
+1. 用户发 `/stop`
+2. bridge 走 `turn/interrupt`
+3. 只有当该 turn 确实以用户停止语义结束时，才向用户显示 `当前任务已停止。`
+
+#### 路径 5：transport 抖动 / 在线事件缺失
+
+1. 不直接向用户宣布 transport 层事件
+2. turn 终态继续靠 pull-primary 对账
+3. 若终态已存在，补发结果
+4. 若终态仍无法确认，再进入 recovery-required 用户解释路径
+
+## 9. 机制设计
+
+## 9.1 三层事实模型
+
+本次明确把状态分成 3 层，不再混读。
+
+### A. Protocol fact
+
+来自 App Server 的原始事实：
+
+- `turn/start` result
+- `turn/steer` result
+- `turn/interrupt` result
+- `thread/status/changed`
+- `turn/completed`
+- `thread/read(includeTurns=true)`
+- `item/*/requestApproval`
+- `item/tool/requestUserInput`
+- `mcpServer/elicitation/request`
+- `serverRequest/resolved`
+
+### B. Bridge ledger fact
+
+bridge 在本地持久化的已知事实：
+
+- inbound receipt / acceptance
+- current thread / active turn binding
+- visible approval / visible user-input request
+- terminal result persisted
+- delivery delivered / delivery_unavailable / suppressed
+- superseded
+
+### C. User-visible semantic
+
+只有在前两层都支持的前提下，bridge 才能对用户说：
+
+- 正在处理
+- 当前等你审批
+- 当前等你回复
+- 本轮已停止
+- 本轮结果暂未确认
+
+原则：
+
+> 用户语义只能从协议事实和账本事实推出，不能从 bridge 的主观猜测推出。
+
+## 9.2 输入路由状态机
+
+### Idle
+
+- 普通文本 -> `turn/start`
+- slash -> 本地控制
+
+### Active / Steerable
+
+满足条件：
+
+1. session 有 `threadId + activeTurnId`
+2. 不存在 unresolved visible approval / user-input request
+3. runtime 线程仍 active，或至少未被 pull-primary / ledger 证明终结
+
+行为：
+
+- 普通文本 -> `turn/steer(expectedTurnId=activeTurnId)`
+- slash `/stop` -> `turn/interrupt`
+- slash 其他命令 -> 本地控制
+
+### Active / Waiting on visible request
+
+满足条件：
+
+1. runtime 显示 waiting flag
+2. 且该 approval / user-input 实体已对用户稳定可见
+
+行为：
+
+- 对 request 的直接回答 -> resolve request
+- 其他普通文本 -> 明确告知当前正等待该 request，不伪装为已转给 Codex
+- 不再额外套 busy gate 文案体系
+
+### Active / Flag visible but artifact not yet visible
+
+满足条件：
+
+1. runtime waiting flag 已出现
+2. 但 approval card / prompt 尚未稳定送达
+
+行为：
+
+1. 这时不能说“当前轮到你了”
+2. 也不能永久阻塞后续输入
+3. 先把 request 视为 `pending_visibility`
+4. 只有一旦 artifact 送达成功，才升级成真正 blocking
+
+## 9.3 waiting 可见性模型
+
+approval / user-input 记录统一加一个可见性维度。
+
+建议状态：
+
+- `pending_visibility`
+- `visible`
+- `resolved`
+- `failed_visibility`
+
+约束：
+
+1. runtime thread flag 只决定“Codex 当前正在等什么”
+2. 用户是否真的被阻塞，取决于该 request 是否已经 `visible`
+3. `failed_visibility` 不能长期把会话锁死；要么重投，要么明确降级处理
+
+## 9.4 终态模型
+
+### 终态真相
+
+继续保持：
+
+1. `thread/read(includeTurns=true)` 是最终真相主来源
+2. `turn/completed` 是 fast-path，不是唯一真相
+
+### 可对用户说“已停止”的唯一条件
+
+只在下面条件同时成立时：
+
+1. 本次停止来自用户显式 `/stop`
+2. 该 turn 确实被 `turn/interrupt` 针对
+3. 终态与该 stop 请求可对应
+
+除此之外：
+
+- interrupted + 无 reply：默认不是“已停止”，而是“本轮状态未确认”或 recovery path
+- transport 抖动：不是“已停止”
+- 在线事件缺失：不是“已停止”
+
+### Non-completed but reply exists
+
+如果 turn 非 completed，但已经有可见 reply：
+
+1. reply 优先交付
+2. bridge 不再用本地状态文案盖掉真实 reply
+
+## 9.5 Transport 语义模型
+
+transport 生命周期从产品层退回实现层。
+
+规则：
+
+1. runtime / channel 的 connect / disconnect / reconnect 默认不直接面向用户出声
+2. 只有当它们影响到任务事实，才通过任务语义折射给用户
+3. `connection != task`
+4. `reconnected != task resumed`
+
+说明：
+
+如果未来单独做 `stdio` 迁移，应在 transport spec 中推进；本 spec 先确保即使 transport 继续保留 websocket，任务语义也不再被 transport 误导。
+
+## 9.6 Slash 命令边界
+
+本次进一步明确：
+
+1. slash 是 bridge 与用户的本地协定
+2. 非 slash 文本默认不是 bridge 的 command surface
+3. bridge 不应把普通自然语言当成本地工作流按钮来吞掉
+
+## 10. 需要修改的模块
+
+### 10.1 `bridge/src/runtime-client.ts`
+
+目标：把 runtime client 收回协议原语层。
+
+必须补齐或调整：
+
+1. 增加 `turn/steer` 客户端接口
+2. 明确 `turn/start` / `turn/steer` / `turn/interrupt` 的错误归一化
+3. `serverRequest/resolved` 进入本地事件流，用来清理 pending request
+4. `thread/status/changed` 继续只作为线程事实缓存，不上升成最终任务结论
+5. 保持 `pull-primary` 终态收口不回退
+
+### 10.2 `bridge/src/receiver.ts`
+
+目标：删掉过厚的本地任务判定，让输入路由和状态语义都回归协议边界。
+
+必须调整：
+
+1. 重新定义非 slash 文本的主路由
+2. 把现有 busy gate 从“默认拦截自然语言”改成“只有协议明确 blocking request 时才拦截”
+3. waiting follow-up 逻辑改成基于 visible artifact，而不是仅基于 runtime flag
+4. `当前任务已停止` 只保留 `/stop` 确认路径
+5. 其他 interrupted / recovery-required / unconfirmed 统一回到事实型文案
+
+### 10.3 `bridge/src/session-store.ts`
+
+目标：把 visible request、turn routing、delivery fact 再收清楚。
+
+需要补齐：
+
+1. approval / user-input 的 visibility state
+2. active turn 是否 steerable 的最小账本支持
+3. stop 请求与 turn 的对应关系
+4. stale / superseded 后的 active turn 清理逻辑
+
+### 10.4 `bridge/src/translator.ts`
+
+目标：收口用户语义，而不是继续扩工程内部状态文案。
+
+需要调整：
+
+1. 删除或弱化不必要的“任务停止/暂停”强结论文案
+2. 明确哪些文案是 slash 控制结果
+3. 明确哪些文案是协议 blocking request 的用户翻译
+4. 避免把 transport 实现术语再次暴露给用户
+
+### 10.5 测试体系
+
+目标：按协议矩阵重排，而不是继续按症状堆 case。
+
+## 11. 子任务拆解
+
+### Task A：Runtime protocol surface 对齐
+
+目标：让 runtime client 成为纯协议绑定层。
+
+DoD：
+
+- [ ] 有 `turn/steer` 明确接口
+- [ ] `turn/start / steer / interrupt` 错误归一化一致
+- [ ] `serverRequest/resolved` 可被消费
+- [ ] 单元测试覆盖 start / steer / interrupt / resolved
+
+### Task B：输入路由状态机重构
+
+目标：非 slash 文本默认回归 Codex。
+
+DoD：
+
+- [ ] idle 文本走 `turn/start`
+- [ ] active 且 steerable 的文本走 `turn/steer`
+- [ ] 只有 unresolved visible request 时才阻塞普通文本
+- [ ] 不再存在“bridge 自创 busy gate 抢先拦截普通追问”的默认行为
+
+### Task C：waiting visibility 模型收口
+
+目标：把 waiting 事实和 blocking 事实分开。
+
+DoD：
+
+- [ ] approval / user-input 具有 visibility state
+- [ ] runtime waiting flag 但 artifact 不可见时，不会把会话永久锁死
+- [ ] artifact visible 后，阻塞解释一致
+- [ ] `serverRequest/resolved` 或本地 resolve 后，blocking 状态清除
+
+### Task D：终态与用户语义收口
+
+目标：停止让 bridge 自己下结论。
+
+DoD：
+
+- [ ] `当前任务已停止。` 只在 `/stop` 确认路径出现
+- [ ] interrupted + no reply 默认不再被翻译成“已停止”
+- [ ] non-completed with reply 继续以 reply 为准
+- [ ] recovery-required / final-state-unconfirmed 统一走事实型说明
+
+### Task E：文档与维护口径更新
+
+目标：让后续维护者不再按旧心智继续加补丁。
+
+DoD：
+
+- [ ] 本 spec 成为后续主参考
+- [ ] 旧的 runtime recovery / presence spec 按新边界更新关系说明
+- [ ] README / implementation guide / troubleshooting 中相关 shipped model 口径同步
+
+### Task F：协议矩阵门禁重排
+
+目标：让自动化测试直接对应协议风险面。
+
+DoD：
+
+- [ ] 测试地图里新增 protocol-alignment 角度说明
+- [ ] 单元测试覆盖 start / steer / interrupt / waiting / resolved / final arbitration
+- [ ] 集成测试覆盖文本追问、pending request、late terminal、delivery unavailable、superseded
+- [ ] 不再新增“杂糅型大测试文件”
+
+## 12. DoD（总完成标准）
+
+只有当下面全部满足，这个专题才算完成。
+
+### 12.1 行为 DoD
+
+1. 除 slash 命令外，普通文本默认不会再被 bridge 私自吞掉
+2. active turn 下，普通追问默认走 `turn/steer`，而不是 busy gate 拦截
+3. waiting flag 只有在可操作实体已可见时，才真正阻塞后续输入
+4. approval / user-input 回答能稳定清理 blocking 状态
+5. `/stop` 之外不再轻易出现 `当前任务已停止。`
+6. Codex 已完成但在线事件丢失时，最终结果仍能通过 pull-primary 回到用户面前
+7. transport 生命周期不再直接成为用户看到的任务结论
+
+### 12.2 自动化 DoD
+
+1. 新增或重构后的 unit / integration tests 全部通过
+2. 协议矩阵至少覆盖：
+   - start
+   - steer
+   - interrupt
+   - waiting approval
+   - waiting user input
+   - serverRequest resolved
+   - late terminal
+   - non-completed with reply
+   - interrupted without reply
+   - stale / superseded
+3. 测试地图更新完成
+4. 不把新增协议测试继续塞回单个巨型文件
+
+### 12.3 文档 DoD
+
+1. 本 spec 已可支撑低上下文工程师直接开工
+2. 相关维护文档已对齐新 shipped model
+3. 旧 spec 若与本 spec 冲突，已明确关系或更新
+
+## 13. 验收标准
+
+1. 当用户在 active turn 中发普通追问时，bridge 会优先尝试 `turn/steer`，而不是默认本地拦截
+2. 当 runtime 进入 `waitingOnApproval` 但 approval card 尚未真正送达时，系统不会提前把这轮永久锁成 waiting_user
+3. 当 approval / user-input 已 visible 时，用户发 `同意` / `拒绝` / 回答内容，bridge 能正确 resolve 给 runtime，并清掉 blocking 状态
+4. 当用户发 `/stop` 后，对应 turn 才会向用户明确显示 `当前任务已停止。`
+5. 当 turn interrupted 但并非用户 stop 且没有 reply 时，系统不会误导性地声称“任务已停止”
+6. 当 turn 非 completed 但已有真实 reply 时，用户看到的是 reply，而不是 bridge 的本地终态文案
+7. 当 transport 抖动但 `thread/read(includeTurns=true)` 已能确认终态时，最终结果仍会正常补回
+8. 当上一轮结果未送达、用户又发新消息时，bridge 仍会先做 delivery ledger 对账与必要补发
+9. README / implementation docs / test coverage map 能让后续维护者看懂当前模型
+
+## 14. 风险、假设、待决问题
+
+### 风险 1：`turn/steer` 在某些 waiting 状态下不接受普通文本
+
+这是可接受风险，但必须诚实处理。
+
+原则是：
+
+1. 先按协议尝试正确路由
+2. 若协议本身要求先回答 pending request，则 bridge 明确告诉用户“当前卡在这个 request 上”
+3. 不允许 bridge 伪装成“我已经把你的追问转给 Codex 了”
+
+### 风险 2：旧测试和旧文案会阻碍收口
+
+这是现实风险。
+
+处理方式：
+
+1. 先写清协议矩阵
+2. 再按矩阵迁移旧测试
+3. 不兼容的旧文案直接删，不做双轨长期兼容
+
+### 假设 1：当前 transport 先继续保留 websocket
+
+本 spec 假设短期内不切 transport，但行为语义不能再依赖 websocket 在线性。
+
+### 假设 2：approval / user-input 仍需要在线 request/response 承接
+
+本期不做离线 request 重放协议，因此 blocking request 仍以内存中 pending record + 可见性账本为主。
+
+### 待决问题
+
+1. `turn/steer` 在 `waitingOnApproval` / `waitingOnUserInput` 下的最优退化策略，是否需要一次明确的协议级探测和错误分类
+2. 后续是否要单独立一个 transport spec，把 websocket 实验通道替换为 stdio child-process client
+3. `/new` 在 active turn 下最终是否保留，还是收成更强约束的显式 interrupt + new-thread 语义
+
+## 15. 实施顺序建议
+
+为了避免边改边乱，建议严格按下面顺序实施。
+
+1. 先改 `runtime-client`，把 `turn/steer`、`serverRequest/resolved`、错误归一化补齐
+2. 再改 `receiver` 输入路由主状态机
+3. 再改 waiting visibility 和 pending request 模型
+4. 再收终态文案与 `当前任务已停止` 语义
+5. 最后更新测试矩阵、文档与人工验收口径
+
+不建议反过来先改文案或先补若干 case，因为那样会继续围绕旧心智打补丁。
+
+## 16. Ready for implementation 结论
+
+这份 spec 当前结论是：`Ready for implementation`。
+
+原因：
+
+1. 问题已经不是“有没有 spec”，而是已经需要一份统一 spec 来阻止继续打补丁
+2. 关键边界已经明确：协议事实、bridge 账本事实、用户可见语义三层分离
+3. 子任务、DoD、验收和实施顺序都已经可直接派工
+
+后续实现默认以本文件为主，不再依赖前序口头讨论。