work-ally 0.2.0-alpha.1

package/docs/issues/resolved/REPORT-ally-runtime-turn-delivery-3b42fb8-2026-03-15.md

@@ -0,0 +1,373 @@
+# 报告：Ally 在 `3b42fb8` release 下的 turn 终态误判、用户语义失真与证据链
+
+更新时间：2026-03-15  
+面向版本：`work-ally` release 对应 commit `3b42fb8`  
+排查对象：`Ally` 助理  
+助理办公桌：`/Users/allenfeng/.work-ally/assistants/Ally`  
+工作仓库：`/Users/allenfeng/Development/Repositories/work-ally`
+
+## 1. 这份报告回答什么
+
+这份报告只回答当前这次真实问题，不讨论泛泛的架构理想。
+
+要回答的是：
+
+1. 这次问题面向哪一个版本。
+2. 查的是什么问题。
+3. 出问题的是哪个助理。
+4. 这次到底是谁出的问题。
+5. 证据是什么。
+6. 为什么中间层会把对应 turn 判成 failed。
+7. 这种“判失败 + 提示连接中断”的设计是不是有问题。
+
+## 2. 先给结论
+
+### 2.1 版本结论
+
+本次排查面向的版本是：
+
+- release 对应 commit：`3b42fb8`
+- commit 标题：`Stabilize auto-approved turn final-state handling`
+
+### 2.2 对象结论
+
+本次问题面向的助理是：
+
+- 助理名称：`Ally`
+- 办公桌路径：`/Users/allenfeng/.work-ally/assistants/Ally`
+
+### 2.3 事故结论
+
+这次你在飞书里看到的：
+
+> `【系统消息】 Codex App Server 连接中断，当前任务状态未确认。若未自动恢复，请重新发送上一条消息。`
+
+**在这次具体事件里，不代表 Codex App Server 真的断了，也不代表 Codex 那边的会话真的停掉了。**
+
+更准确的事实是：
+
+1. bridge 在 `3b42fb8` 版本里对 turn 终态采用了一个有界轮询确认模型。
+2. 这一轮在 20 秒窗口内没有读到 turn 的 final state。
+3. `runtime-client` 于是直接把 turn 判成 failed，错误文本是 `runtime turn final state unavailable`。
+4. `receiver` 又把这类错误统一翻译成“Codex App Server 连接中断，当前任务状态未确认”。
+5. 但 Codex 侧真实会话并没有停，后面继续执行，最终还给出了 commentary、final answer 和 `task_complete`。
+6. 这些后续真实结果没有再被中间层补捞并转发回飞书。
+
+所以，这次事故的根因不是“上游没干完”，而是：
+
+> **中间层把“本轮终态在本地确认窗口内未拿到”错误地升级成了“turn failed”，再进一步错误地翻译成了“连接中断”。**
+
+## 3. 我查了什么问题
+
+本次排查聚焦的用户问题是：
+
+- 2026-03-15 UTC+8 17:00 左右，`Ally` 在飞书会话里先给出正常工作中进度，随后提示“Codex App Server 连接中断，当前任务状态未确认”。
+- 用户想确认：
+  - 这是否意味着 Codex 那边也停工了。
+  - 恢复后系统到底做了什么。
+  - 中间层有没有继续读取 Codex 的后续输出。
+  - 中间层有没有把后续真实结果忠实转发回来。
+
+同时，本次报告继续回答一个更上位的问题：
+
+> 为什么中间层要把 turn 判成 failed？这种设计是否已经偏离了“老老实实转发”的产品职责？
+
+## 4. 哪个助理出的问题
+
+这次问题发生在：
+
+- 助理：`Ally`
+- 会话：`feishu--oc_1890ff7f9132a7d90b09765f27ff5bc8`
+- 对应用户消息：`继续`
+- 对应 turn：`019cf0b9-0a0a-7e40-9c29-ad5483945bd1`
+
+相关运行资产路径：
+
+- 会话视图：`/Users/allenfeng/.work-ally/assistants/Ally/conversations/2026-03-15--feishu--oc_1890ff7f9132a7d90b09765f27ff5bc8.md`
+- archive 原材料：`/Users/allenfeng/.work-ally/assistants/Ally/.system/archive/2026/03/15/feishu--oc_1890ff7f9132a7d90b09765f27ff5bc8.ndjson`
+- bridge 日志：`/Users/allenfeng/.work-ally/assistants/Ally/.system/logs/bridge-2026-03-15.log`
+- runtime session 台账：`/Users/allenfeng/.work-ally/assistants/Ally/.system/runtime/sessions/feishu--oc_1890ff7f9132a7d90b09765f27ff5bc8/`
+- Codex rollout 原始轨迹：`/Users/allenfeng/.work-ally/assistants/Ally/.system/codex-home/sessions/2026/03/14/rollout-2026-03-14T18-04-33-019cebce-0481-7be3-98ce-38432074d5bd.jsonl`
+
+## 5. 证据链
+
+### 5.1 用户消息和中间层已接收
+
+archive 记录表明：
+
+- `2026-03-15T08:59:43.771Z` 收到用户消息 `继续`
+- `2026-03-15T08:59:44.304Z` 发出 ack reaction
+- `2026-03-15T08:59:46.235Z` 发出 `已收到，开始处理。`
+
+这说明消息已经进入中间层，不存在“飞书没收到”的问题。
+
+### 5.2 Codex 的 commentary 已经真实产出且已被转发一次
+
+archive 记录表明：
+
+- `2026-03-15T08:59:59.714Z` 记到 system event：
+  - `我现在直接把文档落地，不再只停在判断层。先做两件事：迁移三份已完成 spec 到 docs/completed，再把桌面端 spec 按“全局单例桌面 App”模型重写，同时把产品账本里的相关引用和描述一起对齐。`
+- `2026-03-15T09:00:00.317Z` 这条 commentary 已经作为 `⏳ 工作中` 被真正转发到飞书。
+
+这说明当时并不是完全卡死，Codex 的中间进度已经通过 bridge 回来了。
+
+### 5.3 bridge 在 20 秒轮询窗口后先把 turn 判失败
+
+`bridge-2026-03-15.log` 显示：
+
+- `2026-03-15T08:59:44.522Z` turn 启动，turn id 是 `019cf0b9-0a0a-7e40-9c29-ad5483945bd1`
+- `2026-03-15T08:59:44Z` 到 `2026-03-15T09:00:25Z` 之间，bridge 反复发送 `thread/read`
+- `2026-03-15T09:00:25.412Z` 触发 `runtime.turn_final_state_poll_timeout`
+- 同时记录：
+  - `status: "active"`
+  - `activeFlags: []`
+- 随后 `2026-03-15T09:00:25.412Z` 直接执行 `receiver.turn_failed`
+
+这里最关键的一点是：
+
+> 在这个时间窗口里，没有对应的 `runtime.connect_closed` 日志。
+
+也就是说，这次 **不是 bridge 先观察到真实 websocket 断开，再告诉用户“连接中断”**；而是 **它先因为终态轮询超时，把 turn 判成 failed**。
+
+### 5.4 用户看到的“连接中断”是中间层翻译后的兜底文案，不是底层真实事件
+
+同一条 archive 记录表明：
+
+- `2026-03-15T09:00:25.414Z` system event 里记录的原始错误是：
+  - `runtime turn final state unavailable: 019cf0b9-0a0a-7e40-9c29-ad5483945bd1`
+- `2026-03-15T09:00:25.966Z` 发给用户的 error reply 却变成：
+  - `【系统消息】 Codex App Server 连接中断，当前任务状态未确认。若未自动恢复，请重新发送上一条消息。`
+
+这说明“连接中断”是 **receiver 侧的统一用户文案归一化结果**，不是这次事故现场观察到的底层事实。
+
+### 5.5 Codex 会话没有停，后面还继续执行并最终完成
+
+Codex rollout 原始轨迹显示：
+
+- `2026-03-15T09:00:54.885Z` 还有新的 commentary：
+  - “迁档已经开始落地了，桌面端那份旧 spec 我也已经整体重写成‘全局单例桌面 App’的版本……”
+- `2026-03-15T09:01:04.011Z` 还有新的 commentary：
+  - “我已经先把三份已完成 spec 真实迁走了，也把桌面端主 spec 重写成了‘全局单例桌面 App’版本……”
+- `2026-03-15T09:01:14.562Z` Codex 产出了 final answer
+- `2026-03-15T09:01:14.563Z` 记录了 `task_complete`
+
+所以这次对 Codex 侧的真实描述应该是：
+
+> **Codex 会话继续运行，而且完成了。**
+
+### 5.6 中间层没有把这些迟到但真实存在的结果补发回来
+
+飞书 archive 和 conversation view 里没有看到：
+
+- `09:00:54` 的 commentary
+- `09:01:04` 的 commentary
+- `09:01:14` 的 final answer
+
+用户只看到了：
+
+1. 已收到，开始处理
+2. 一条“⏳ 工作中” commentary
+3. 然后直接看到“连接中断，当前任务状态未确认”
+
+这说明：
+
+> **中间层在把 turn 提前判失败之后，没有继续把 Codex 迟到到达的真实终态结果重新对账并补发。**
+
+## 6. 为什么会把对应 turn 判成 failed
+
+面向 `3b42fb8` 版本的源码，可以明确看到这次误判不是偶然，而是产品当前设计的直接结果。
+
+### 6.1 `runtime-client` 的终态确认模型是有界轮询 + 超时即 reject
+
+`3b42fb8` 版本的 `bridge/src/runtime-client.ts` 中，`pollTurnFinalState()` 的逻辑是：
+
+1. 对同一个 turn 持续做 `thread/read(includeTurns=true)`。
+2. 如果读到了该 turn 的终态，就 resolve。
+3. 如果在 `TURN_FINAL_POLL_TIMEOUT_MS` 窗口内一直读不到终态，且 thread 也没进入等待人工输入的状态，就直接 reject。
+
+这个 reject 分两种文案：
+
+- 如果 thread 已 idle：`runtime turn reconciliation failed: idle thread without completed turn event (...)`
+- 否则：`runtime turn final state unavailable: ...`
+
+而默认超时值是：
+
+- `TURN_FINAL_POLL_TIMEOUT_MS = 20000`
+
+也就是 20 秒。
+
+### 6.2 这次 turn 不是“真的失败”，而是“20 秒内没等到终态”
+
+这次 turn 在 `09:00:25` 被判失败时：
+
+- bridge 自己记录的状态还是 `active`
+- 没有记录真实 `connect_closed`
+- 之后 49 秒左右，Codex 自己给出了 `task_complete`
+
+因此，这次的失败语义并不是“上游执行失败”，而是：
+
+> **中间层在自己的确认窗口内没有看到终态，于是把“未确认”升级成了“失败”。**
+
+### 6.3 `receiver` 又把这类失败包装成了“连接中断”
+
+`3b42fb8` 版本的 `bridge/src/receiver.ts` 中，`normalizeErrorReplyText()` 明确把下面两类错误统一改写为基础设施失败文案：
+
+- `runtime turn final state unavailable`
+- `runtime turn reconciliation failed`
+
+对应的用户文案来自 `bridge/src/translator.ts`：
+
+> `Codex App Server 连接中断，当前任务状态未确认。若未自动恢复，请重新发送上一条消息。`
+
+这就造成了语义错位：
+
+- 底层真实错误：`终态未在本地确认窗口内拿到`
+- 用户看到的文案：`连接中断`
+
+## 7. 这种设计是不是有问题
+
+结论：**有问题，而且是产品语义层面的结构性问题。**
+
+### 7.1 中间层把“未确认”过早升级成“失败”
+
+作为中间层，最重要的职责不是尽快结束一个本地 Promise，而是：
+
+- 不丢用户消息
+- 不丢上游结果
+- 不把不确定性伪装成确定性
+
+但当前设计在 20 秒后直接把 turn 归类为 failed，这本质上是在用本地等待窗口替代事实真相。
+
+### 7.2 更严重的问题不是判 failed，而是错误对用户说“连接中断”
+
+如果用户看到的是：
+
+- “系统暂未确认上一轮是否已完成，我会继续补捞结果”
+
+这还是诚实的。
+
+但这次真实情况是：
+
+- 没观察到真实断连
+- 上游实际上继续执行并完成了
+- 用户却被告知“连接中断”
+
+这会把用户逼到一个错误判断里：
+
+- 以为 Codex 没干了
+- 以为必须立刻重发
+- 以为之前那轮一定已经死了
+
+### 7.3 这已经偏离了“老老实实转发”的产品职责
+
+用户真正需要的是：
+
+> 只要 Codex 那边后来真的产出了状态、reply、final answer，中间层就应该尽量把它捞回来并转发，而不是先告诉用户“连接中断”，让用户自己猜。
+
+从这个角度看，当前设计存在三个偏航：
+
+1. 把“本地确认窗口结束”当成“这一轮失败”。
+2. 把“终态未确认”误说成“连接中断”。
+3. 在判失败后没有继续对账并补发迟到到达的真实结果。
+
+## 8. 对“长连接是否真的有必要”的判断
+
+### 8.1 对最终交付正确性来说，长连接不应该是前提
+
+如果产品目标是：
+
+- 稳定性优先于即时性
+- 中间层只需要忠实转发 Codex 状态与结果
+
+那么 **最终结果交付** 不应该建立在长连接的连续观察上。
+
+更合理的主模型应该是：
+
+> **pull-primary，push-assisted**
+
+也就是：
+
+- 最终 reply、turn 终态、是否完成，以主动 `thread/read` / turn 对账为准。
+- push 或长连接只负责更好的实时体验，以及审批、等待用户输入这类在线交互承接。
+
+### 8.2 纯 pull 是可以认真评估的
+
+如果你当前最看重的是：
+
+- 不要再有“中断”“未确认”这种误导性系统提示
+- 即时性可以退一点
+- 只要保证最终状态和结果稳定可见
+
+那么“定时主动拉取”的方向是合理的，至少在用户可见交付层是合理的。
+
+它的优点是：
+
+1. 把正确性建立在可重试读取上，而不是实时事件流上。
+2. 不再要求桥始终在线地盯住每一个瞬时事件。
+3. 可以把“迟到结果”自然收进正常路径，而不是当成异常分支。
+
+### 8.3 但即使保留长连接，也不应该再让它承担正确性职责
+
+这里真正的问题不是“是否一定要 websocket”。
+
+真正的问题是：
+
+> **现在的系统把用户语义正确性，压在了实时连接和有界确认窗口上。**
+
+这才是根因。
+
+所以，即便继续保留长连接：
+
+- 它也应该只是体验增强层
+- 不应该再是“用户最终能否拿到结果”的真相来源
+
+## 9. 对当前产品的直接结论
+
+### 9.1 为什么要判 turn failed？
+
+在当前实现里，判 failed 是为了：
+
+- 让 `runTurn()` 尽快收口
+- 防止一个 turn 永久卡在 in-progress
+- 给用户一个明确状态
+
+但这套设计的问题是：
+
+- 它把“状态明确”建立在“过早宣告失败”上
+- 而不是建立在“持续对账直到拿到事实真相”上
+
+### 9.2 这种设计是否应该改
+
+我的判断是：**应该改，而且是根模型要改。**
+
+至少应该改到下面这个层级：
+
+1. **无真实 `connect_closed` 证据时，不得对用户说“连接中断”。**
+2. **`runtime turn final state unavailable` 不应直接等价为 failed。**
+3. **turn 在超出本地确认窗口后，应进入 `final_state_pending` / `awaiting_reconcile` 之类的中间态，而不是 failed。**
+4. **只要 Codex 后来给出了 final answer，中间层就必须继续尝试补捞并补发。**
+5. **用户可见的主文案应从“你重发吧”改成“我先继续确认；若稍后仍拿不到，再请你决定是否重发”。**
+
+### 9.3 如果要进一步往你说的方向收口
+
+那下一步最合理的产品方向就是：
+
+- 用户可见交付链路改成 **主动取为主**
+- 实时 push 退化成 commentary / approval / waiting 状态增强
+- turn 不再因为本地等待窗口结束而直接 failed
+- “重发上一条消息”从默认动作降级为最后兜底动作
+
+## 10. 最终结论
+
+对这次 `Ally` / `3b42fb8` release 的事故，可以压缩成一句话：
+
+> 不是 Codex 会话先停了，而是中间层先把“终态暂未确认”误判成 failed，再错误翻译成“连接中断”，导致用户看不到 Codex 随后真实完成的结果。
+
+如果再压缩成产品判断，就是：
+
+> 当前设计确实有问题。它没有做到“老老实实转发事实”，而是在本地确认窗口结束后，过早替用户下了结论。
+
+这也是为什么你的 pull-first 直觉是对的：
+
+> **对于最终结果交付，稳定事实读取应该高于实时连接观察。**
+

package/docs/manual-acceptance.md

@@ -0,0 +1,127 @@
+# 人工验收清单
+
+## 1. 一键初始化
+
+- [x] `ally setup <name> --workspace <path>` 成功
+- [x] 自动创建 assistant 办公桌
+- [x] 自动生成 `~/.work-ally/assistants/<name>/.system/config.env`
+- [x] 自动初始化 assistant 办公桌 Git 仓库
+- [x] 自动生成默认 `SOUL.md`
+- [x] 已有 assistant 再执行 `ally assistant ensure` 时，不会静默改写现有 `SOUL.md`
+- [x] 同一项目允许绑定多个 assistant，不会因为新建 assistant 静默覆盖旧绑定
+- [x] 同一项目绑定到 3 个 assistant 后，隐式 `ally status` 会明确报错要求带 `--assistant`，显式 `--assistant <name>` 仍能分别启动/查看/停止
+
+## 2. 最小配置路径
+
+- [x] 默认配置只保留最小必要项
+- [x] 用户不需要手工创建 assistant 配置文件
+- [x] 用户可直接 `ally start --assistant <name>`
+- [x] 如果 Feishu 机器人还不能发消息，`ally start` 会直接失败，不假装启动成功
+
+## 3. Assistant 独占性
+
+- [x] 同一个 assistant 在项目 A 中启动成功
+- [x] 在任意目录显式执行 `ally start --assistant <name>` 时，会落到该 assistant 绑定的项目上下文，而不是当前 cwd
+- [x] 当同一项目绑定多个 assistant 时，隐式命令不会误选，必须显式带 `--assistant <name>`
+
+## 4. 资产归属
+
+- [x] `conversations/` 落在 assistant 办公桌
+- [x] `journal/` 落在 assistant 办公桌
+- [x] `SOUL.md` / `MEMORY.md` / `MISTAKES.md` / `NOW.md` 落在 assistant 办公桌
+- [x] `.system/archive/` / `.system/routines/` 落在 assistant 办公桌
+- [x] 项目目录默认不承载 `.work-ally/` 运行态
+
+## 5. 办公桌 Git
+
+- [x] assistant 初始化后已有 Git 仓库
+- [x] 启动时自动 checkpoint
+- [x] 关闭时自动 checkpoint
+- [x] 未配置远端时跳过 push
+- [x] 配置远端后会尝试 push
+
+## 6. Feishu 回复体验
+
+- [x] 普通最终回复默认不是纯文本降级，而是 Markdown-rich 渲染
+- [x] 表格类回复继续走可读的 card 路径
+- [x] 在 Feishu 里回复 assistant 某条历史消息时，reply target 会被识别
+- [x] 若 reply target 可读取，其正文会进入本轮 prompt 上下文
+- [x] 若 reply target 拉取失败，本轮消息仍能正常继续
+- [x] Feishu 飞书平台最小权限配置正确：开启“读取用户发给机器人的单聊消息”、开启“接收群聊中@机器人消息事件”、不启用“获取群组中所有消息（敏感权限）”
+- [x] Feishu 群聊里，未显式 `@assistant` 的普通消息默认忽略
+- [x] Feishu 群聊里，显式 `@assistant` 时会正常触发；reply assistant 或群里裸控制命令不作为支持路径
+- [x] 同一 assistant 的私聊会话与群聊会话会进入两条独立 thread，并能各自正确回投到原 Feishu 会话
+
+## 7. 状态可见性
+
+- [x] 用户发消息后，正常路径默认只保留 reaction ack，不再额外补 `已收到，开始处理。` 这类通用系统状态噪音
+- [x] 长耗时任务中，用户能看到 `正在处理...` 或后续工作中心跳
+- [x] 若 runtime 已明确进入 `waitingOnApproval` / `waitingOnUserInput`，即使等待时间超过 pull-primary 终态超时窗口，也不会误报 `runtime turn final state unavailable`
+- [x] 审批出现时，除审批卡外还能看到 `当前已暂停，等待你审批后继续。`
+- [x] 等待审批时，下一条消息若严格等于 `OK` / `同意` / `NO` / `拒绝`，会直接作为审批处理；其他文本不会透传给 Codex
+- [x] 同一轮出现多项待审批时，前台默认合并成一张审批卡，用户一次回复即可整批通过或整批拒绝
+- [x] 补充信息出现时，除提问文案外还能看到 `当前已暂停，等待你回复后继续。`
+- [x] 若 runtime 只暴露 `waitingOnApproval` / `waitingOnUserInput` 标记、但前台还没有真正可操作的审批卡或提问内容，bridge 默认保持静默，不再额外解释“artifact 还没同步到前台”
+- [x] waiting_user 建立后，不再继续发送通用 thinking heartbeat
+- [x] 正常长任务默认不再补 `正在处理...` / `正在思考中，请稍候…` 这类通用状态噪音
+- [x] assistant 存在 active turn 时，普通自然语言 follow-up 默认优先沿协议主路径进入当前 turn，而不是被 bridge 自创 busy gate 先拦住
+- [x] 只有审批 / 补充信息这类已经对用户可见的阻塞请求，后续自然语言才会在桥层被拦下并明确提示先处理当前阻塞
+- [x] assistant 忙时发送 `/new` 不会隐式抢占当前轮，而是提示先 `/stop`
+- [x] 如果本轮实际上已结束、但没有可见正文可发，会明确补一条 `本轮已结束，当前没有更多动作；如需继续，请直接发下一条消息。`
+- [x] 如果同一条旧消息因渠道重投再次到达，但会话已经被更新消息推进，不会突然把旧任务重新做一遍
+- [x] 如果旧 turn 已被新消息抢占，旧 turn 后续迟到的进度或结果不会再突然回到用户面前
+- [x] 即使用户消息刚到 bridge 时 ack 发送失败，inbound ledger 里仍能看到该消息已被 bridge 接住
+- [x] 一旦 `turn/start` 成功，inbound ledger 会落成 `threadId / turnId / acceptedAt`，不再只能靠日志猜“有没有真正进 Codex”
+- [x] 即使在线 `turn/completed` 事件丢失，只要 `thread/read(includeTurns=true)` 已经有终态，最终回复仍能正常回来
+- [x] bridge↔runtime 连续 20 轮 ping-pong 往返后，不残留 stale active turn，最终回复顺序稳定
+- [x] runtime recovery notice 发出后，对应 turn ledger 仍保持真实终态（例如 `failed`），不再额外伪造 `recovery_required` 执行态
+- [x] recovery 成功补发最终结果后，对应 turn ledger 会落成 `deliveryStatus=delivered` 或 `delivery_unavailable`
+- [x] 旧 turn 被新消息推进后，对应 turn ledger 会落成 `deliveryStatus=suppressed`，并记录 `suppressedByMessageId` / `suppressionReason` 这类 suppression provenance
+- [x] `ally status` 显示 assistant 名
+- [x] `ally status` 显示 assistant codex home
+- [x] `ally status` 显示 assistant autosave
+- [x] `ally status` 显示 assistant lock status
+- [x] `ally status` 显示 channel lock status
+- [x] 远程 `/status` 显示 assistant mode 信息
+
+## 8. 无人值守恢复
+
+- [x] `ally start` 后 `supervisor` 存活
+- [x] bridge 异常退出后可自动恢复
+- [x] `ally status` 能看到 `supervisor`
+- [x] `ally logs supervisor` 可查看托管日志
+- [x] 在受管 AI 执行环境中直接 `ally start` 会被明确拒绝，不再伪装成后台已成功托管
+- [x] `WORK_ALLY_FOREGROUND=1 ally start` 仍可用于前台联调
+
+## 9. Nightly Digest 可见性
+
+- [x] `nightly-memory-digest` 默认按 assistant 本地时区 23:00 调度
+- [x] digest 完成后，如存在可用 Feishu 投递目标，会主动推送本次提炼摘要
+- [x] 当次无新增稳定记忆时，系统消息会明确说明，而不是静默结束
+- [x] 最近一次运行结果仍可在 `.system/runtime/routines-state.json` 与 `.system/runs/latest.json` 追溯
+
+## 10. 审批自治边界
+
+- [x] 当前项目目录内的低风险本地验证动作（例如跑测试、`git add`、`git commit`）默认自动放行
+- [x] assistant 办公桌内的低风险文件改动默认自动放行，不再逐条打断用户
+- [x] shell 包裹的本地自测 / 提交命令，只要仍落在项目根内且不含高风险片段，默认自动放行
+- [x] 自动放行后的低风险本地动作默认对用户静默，不再额外刷“已自动放行”系统说明；审计仍保留在内部事件与状态里
+- [x] 需要人工拍板时，审批卡会明确说明“为什么这一步超出默认自决边界”
+- [x] 非 allowlisted 的 MCP 工具确认仍保持人工确认，不被本地默认放行误吞
+
+## 11. 中间层异常透明化
+
+- [x] 若上一轮已经产出结果，但当时未能稳定送达，用户下一次发消息时 bridge 会先自动补发上一轮结果；只有补发仍失败时才退回系统说明
+- [x] runtime transport 生命周期默认不再直接透传给用户；用户侧只保留必要的事实型说明，不暴露实现层的断开/恢复术语
+- [x] runtime final-state timeout 若随后可补读到终态结果，会优先自动补回结果，而不是直接要求用户重发
+- [x] runtime recovery attempt、stale cleanup、artifact pending 这类内部过程默认不再直接暴露给用户
+- [x] runtime recovery required / infrastructure failure 仍会明确提示事实型说明，例如“系统暂时还没确认这一轮是否已完成 / 请重发上一条消息”
+- [x] 出站链路异常不会把 turn 误判成成功送达，同时 turn ledger 可追溯 delivery unavailable
+
+## 12. 稳定发布边界
+
+- [x] 默认 `ally` 入口走 npm 安装形态（install-first）
+- [x] 在源码仓库里持续修改实现时，不会自动影响默认稳定入口
+- [x] 执行 npm 安装/升级后，`ally` 入口行为与发布版本一致
+- [x] `ally status` 能看见 install channel 与 implementation/install root 信息
+

package/docs/ops-runbook.md

@@ -0,0 +1,44 @@
+# 运维手册
+
+## 日常命令
+
+```bash
+ally status --assistant <name>
+ally logs timeline --assistant <name>
+ally logs supervisor --assistant <name>
+ally restart --assistant <name>
+ally stop --assistant <name>
+ally assistant rename <old> <new>
+ally global list
+```
+
+## 安装发布口径
+
+当前默认 `ally` 入口走 npm 安装形态（install-first）。
+
+运维判断分两层：
+
+- 源码是否已修好
+- 目标机器是否已执行 npm 安装/升级
+
+如果用户反馈“代码改了但行为没变”，先确认：
+
+```bash
+npm i -g work-ally@alpha
+```
+
+然后让用户回传：
+
+```bash
+ally status --assistant <name>
+```
+
+重点看 `install channel`、`implementation`、`install root`。
+
+## 运行边界
+
+后台由 `supervisor` 托管 `bridge` 与 `assistant-autosave`。
+
+- Codex runtime 为 assistant 私有 stdio child process
+- 不需要用户关心本地端口
+- runtime child 异常后由 bridge 在后续请求中拉起