work-ally 0.2.0-alpha.1

package/docs/completed/SPEC-approval-batch-and-strict-reply-shortcuts.md

@@ -0,0 +1,153 @@
+# SPEC: Approval Batch And Strict Reply Shortcuts
+
+更新时间：2026-03-18  
+状态：Completed / Shipped  
+Owner：work-ally product / engineering  
+相关文档：
+- `docs/completed/SPEC-approval-autonomy-and-safe-defaults.md`
+- `docs/completed/SPEC-conversation-noise-reduction-and-busy-input-gate.md`
+- `docs/manual-acceptance.md`
+- `bridge/src/router.ts`
+- `bridge/src/receiver.ts`
+- `bridge/src/translator.ts`
+
+## 1. Summary
+
+当前审批体验在 Feishu 里过于碎：一轮 turn 内如果连续出现多条审批，用户需要逐条 approve；而且审批卡之间还会夹杂状态提示，导致操作路径别扭。
+
+本专题做两件小事：
+
+1. 当会话处于 `waiting approval` 时，中间层接管用户下一条消息；只接受严格约定字符串：`OK` / `同意` / `NO` / `拒绝`。
+2. 同一轮 / 同一会话内出现多条待审批时，前台默认合并成一张审批卡；用户一次回复即可全部通过或全部拒绝。
+
+不做自然语言理解，不要求 reply 某一张审批卡，不引入额外面板或厚重审批队列。
+
+## 2. 目标
+
+1. 减少 Feishu 中逐条审批的摩擦。
+2. 保持审批语义明确、可预测、可审计。
+3. 只在 `waiting approval` 阻塞态下启用严格字符串快捷回复；其他场景下 `OK` / `NO` 继续透传给 Codex。
+4. 保持中间层简单，不引入新的复杂审批状态机。
+
+## 3. 非目标
+
+1. 不做自然语言审批理解。
+2. 不做“回复任意历史消息都算审批”的宽松语义。
+3. 不做审批队列面板、审批模式配置项、审批别名扩展。
+4. 不改变 runtime 原生 approval request / resolveApproval 合同。
+
+## 4. 产品定义
+
+### 4.1 严格快捷回复
+
+仅当当前会话存在可见待审批项时，bridge 才拦截用户下一条消息并按以下规则处理：
+
+- `trim` 后严格等于 `OK` 或 `同意` -> 视为批准当前待审批
+- `trim` 后严格等于 `NO` 或 `拒绝` -> 视为拒绝当前待审批
+- 其他文本 -> 不转给 Codex，直接提示用户回复约定值
+
+注意：
+
+- 这里不做大小写模糊、相似语义、表情或自然语言扩展。
+- 只做字符串 equals。
+- 不要求 reply 审批卡。
+
+### 4.2 多审批默认合并
+
+同一会话在 `pendingApprovalIds.length > 1` 时：
+
+- 前台不再逐条发多张审批卡
+- 默认发送一张合并审批卡
+- 卡片中明确列出审批数量与简要条目
+- 用户回复一次 `OK` / `同意` -> 全部批准
+- 用户回复一次 `NO` / `拒绝` -> 全部拒绝
+
+### 4.3 非 waiting approval 场景
+
+如果当前会话没有可见待审批项：
+
+- `OK` / `同意` / `NO` / `拒绝` 一律按普通用户消息处理
+- 不做审批拦截
+
+## 5. 前台文案
+
+### 5.1 单审批卡
+
+保留审批边界说明，但收紧操作提示：
+
+- 不再强调“直接回复这张审批卡”
+- 改为强调：`当前会话正在等审批；你可以直接回复 OK / 同意，或 NO / 拒绝。`
+
+### 5.2 多审批合并卡
+
+建议文案：
+
+- 标题：`审批请求（共 N 项）`
+- 说明：`这一轮有多项审批待处理。回复 OK / 同意 可全部通过；回复 NO / 拒绝 可全部拒绝。`
+- 条目：每项保留最小必要信息，如类型、动作、影响范围、工作目录
+
+### 5.3 waiting approval follow-up
+
+当用户在 waiting approval 期间发来非约定字符串：
+
+- 不把消息转给 Codex
+- 返回：`当前有待处理审批。请回复 OK / 同意，或 NO / 拒绝。`
+
+## 6. 机制设计
+
+### 6.1 Router
+
+- 保留当前 `/approve <id>` 与 `/deny <id>` 显式命令
+- 保留“reply 审批卡 + 同意/拒绝”的兼容路径
+- 新增严格快捷回复解析，但只在 receiver 判断当前会话处于 waiting approval 时启用，不在 router 层无条件把 `OK` / `NO` 解析成控制命令
+
+### 6.2 Receiver
+
+- 在 `waiting approval` follow-up 分支优先处理严格快捷回复
+- 单审批时，对当前唯一 pending approval 调用 `runtime.resolveApproval`
+- 多审批时，按当前 `pendingApprovalIds` 顺序逐个 resolve
+- 任一审批 resolve 失败时，停止后续处理，并向用户回报失败
+- 全部成功后，统一回一条结果说明
+
+### 6.3 Session Store
+
+- 继续复用当前 `pendingApprovalIds` 与 approval records
+- 不新增独立 batch object
+- 前台合并卡通过扫描当前会话下的 pending approvals 生成，不要求新增 durable 批对象
+- 合并审批只是前台展示与 follow-up 解析语义，不新增新的 durable 审批实体
+
+### 6.4 Feishu 前台
+
+- `approval_requested` 会在一个很短的合并窗口内聚合当前 turn 的 pending approvals，再决定发单卡还是合并卡
+- 同一批待审批项只保留一张可操作卡
+- 仍保持 archive / session-store 中每个 approval 独立存在，便于审计
+
+## 7. 验收标准
+
+1. 单审批出现后，用户直接发送 `OK` / `同意`，无需 reply 卡片，也能完成审批。
+2. 单审批出现后，用户直接发送 `NO` / `拒绝`，无需 reply 卡片，也能拒绝审批。
+3. waiting approval 期间用户发送其他文本时，不转给 Codex，并收到固定提示：`当前有待处理审批。请回复 OK / 同意，或 NO / 拒绝。`
+4. 没有 pending approval 时，`OK` / `NO` 会正常透传到 Codex。
+5. 同一会话出现多项 pending approval 时，前台只看到一张合并审批卡。
+6. 多审批场景下，用户一次 `OK` / `同意` 可全部通过；一次 `NO` / `拒绝` 可全部拒绝。
+7. `/approve <id>` / `/deny <id>` 旧路径仍可用。
+
+## 8. 验收结果
+
+- unit：router strict shortcut / adapter outbound card 渲染已覆盖
+- integration：单审批快捷通过 / 拒绝、非法 follow-up 拦截、无 pending approval 时 `OK` 透传、多审批合并卡与批量 resolve 已覆盖
+- 当前聚焦自动化验证：`/opt/homebrew/bin/node --test tests/unit/session/router.test.mjs tests/integration/session/approval-flow.test.mjs tests/unit/channel/feishu-adapter-outbound.test.mjs tests/integration/session/waiting-and-redelivery.test.mjs tests/integration/session/control-commands.test.mjs tests/integration/session/mcp-tool-approval-flow.test.mjs` -> `47/47` 通过
+
+## 9. 测试要求
+
+- unit：router 严格快捷回复 / reply 审批卡兼容
+- integration：单审批快捷通过 / 拒绝
+- integration：waiting approval 非法 follow-up 拦截
+- integration：无 pending approval 时 `OK` 透传
+- integration：多审批合并卡与批量 resolve
+
+## 10. 风险与边界
+
+- 合并审批只适合“当前会话 pending approval 集合”这一层，不做跨会话合并。
+- 批量 resolve 时若中途失败，前台需要明确告诉用户“本批审批未全部完成”，避免误以为全部已通过。
+- 这次优化的核心是减少 IM 摩擦，不是重做审批系统；因此坚持不引入新面板和复杂配置。

package/docs/completed/SPEC-conversation-noise-reduction-and-busy-input-gate.md

@@ -0,0 +1,538 @@
+# Conversation Noise Reduction And Busy Input Gate
+
+更新时间：2026-03-14  
+状态：Shipped / 2026-03-15 shipped baseline
+
+## 1. 这份 spec 在解决什么
+
+这份 spec 解决的是一个真实使用中已经反复暴露出来的体验问题：
+
+> Feishu 对话窗口里，中间层“正在处理”“正在思考中”“旧任务已停止”等工作状态提示过多，正在侵蚀真正的人机对话本身。
+
+如果继续沿着当前默认行为走，产品会越来越像一个会不断插嘴的中间件，而不是一个可信、克制、低打扰的 assistant。
+
+所以这条专题的重点不是“删几条文案”，而是重写一条更成熟的对话合同：
+
+1. 正常路径尽量安静
+2. 真正需要用户知道时再说话
+3. assistant 忙的时候，不再默认打断旧任务改做新任务
+4. 用户依然保有明确的控制权，尤其是 `Stop`
+
+## 2. 背景
+
+当前系统已经具备一部分状态可见性能力：
+
+- 收到消息后会有 ack reaction
+- 长耗时 turn 期间会发送 running / heartbeat 文案
+- 等审批、等补充信息、runtime 异常时会发送不同系统消息
+- 如果用户在上一轮未结束时继续发消息，系统会默认停止旧 turn，改做新 turn
+
+这些能力从“工程上补可见性”角度看是合理的，但从真实 IM 产品体验看，问题已经很明显：
+
+### 2.1 正常路径噪音过多
+
+用户本来只想和 assistant 对话，但窗口里会频繁出现：
+
+- `正在处理，请稍候。`
+- `正在思考中，请稍候…`
+- `上一轮仍在处理中；已停止旧任务，改为处理你刚发的新消息。`
+
+这些提示很多不是异常，也不是需要用户立刻决策的时刻。
+
+### 2.2 当前默认的“自动抢占”不够产品化
+
+当 assistant 还在忙时，用户再发一条自然语言消息，系统当前会默认：
+
+- 打断上一轮
+- 清理旧 active turn
+- 直接处理新消息
+- 再回告用户“旧任务已停止”
+
+这在实现层是一个简单选择，但在产品层问题很大：
+
+- 它把“是否打断当前工作”这个决定替用户做掉了
+- 它让对话结果变得不稳定，用户不容易建立预期
+- 它制造额外系统文案噪音
+- 它会让用户误以为“连续发几句 = 正常多轮聊天”，但系统其实是在隐式抢占
+
+### 2.3 “可见性”被误用成“持续出声”
+
+状态可见性的本意是降低不确定性。
+
+但在 IM 场景里，降低不确定性不等于不断发“我还在忙”。
+
+如果中间层把每一个内部阶段都翻译成文字冒泡，它虽然更“可见”，却不一定更“好用”。
+
+## 3. 产品判断
+
+先给判断。
+
+### 3.1 这条方向是对的
+
+你的方向是对的，而且不是小优化，而是一个应该单独立 spec 的产品决策。
+
+更准确的产品定义不是“少发几条工作中文案”，而是：
+
+> 让飞书会话默认回到“人和 assistant 的主对话”，而不是“人、assistant 和中间层三方混聊”。
+
+### 3.2 正常路径要降噪，异常路径要显式
+
+我们不应该走两个极端：
+
+- 不是继续保持现在这种高频工作状态输出
+- 也不是把所有状态都静默掉
+
+正确方向是：
+
+- 正常路径安静
+- 等用户动作时明确
+- 出问题时明确
+- 用户尝试在忙时插入新需求时明确
+
+### 3.3 V1 应该“拦截，不排队，不默认抢占”
+
+如果 assistant 还在处理上一轮，V1 最合理的产品语义不是：
+
+- 自动打断旧任务
+- 把新消息悄悄排队
+- 或同时维护一个隐藏堆栈
+
+而是：
+
+- 直接拦截新的自然语言消息
+- 明确告诉用户当前仍在忙
+- 告诉用户如需打断可以发送 `/stop`
+- 让用户在“等待”与“打断”之间显式做决定
+
+这样模型最简单，用户心智也最稳定。
+
+## 4. 目标
+
+这条 feature 的目标有四个。
+
+1. 保持 Feishu 会话窗口尽可能纯净，减少中间层日常噪音
+2. 阻止 assistant 忙时的自然语言消息默认抢占当前 turn
+3. 保留用户对当前轮的最终决定权，尤其是 `Stop`
+4. 不牺牲异常透明化与等待用户状态的明确性
+
+## 5. 非目标
+
+本次不做：
+
+- 不做隐藏消息队列
+- 不做复杂的多消息堆栈管理
+- 不做“边忙边继续收后续需求”的后台编排
+- 不做独立会话工作流引擎
+- 不把所有状态都搬去新的 dashboard 才看得见
+
+V1 的重点是先把默认合同收正，而不是增加复杂度。
+
+## 6. 核心概念
+
+### 6.1 `Idle`
+
+含义：当前会话没有活跃 turn，也没有等待用户才能继续的挂起状态。
+
+此时：
+
+- 用户自然语言消息可以正常进入
+- `/new`、`/status`、`/stop` 等控制命令按既有语义处理
+
+### 6.2 `Busy`
+
+含义：当前会话存在活跃 turn，assistant 仍在推进本轮工作，且现在不是用户动作回合。
+
+典型包括：
+
+- runtime 正在执行
+- bridge 正在等待本轮最终结果
+- recovery 正在确认上一轮结果
+
+此时：
+
+- 普通自然语言消息不应再默认进入
+- 不应默认打断旧任务
+- 用户如果要终止当前轮，应明确发送 `/stop`
+
+### 6.3 `WaitingUser`
+
+含义：当前轮已经暂停，后续推进明确依赖用户动作。
+
+典型包括：
+
+- 等审批
+- 等补充信息
+- 等 MCP tool confirmation
+
+此时：
+
+- 用户下一条回复应被允许进入
+- 这不是“忙时阻塞”，而是“轮到用户”
+
+### 6.4 `Problem`
+
+这条 spec 里的“问题”不是泛指一切运行状态，而是指以下几类用户必须被明确告知的异常或阻塞：
+
+1. runtime / channel / recovery 异常，导致当前轮状态不可可靠确认
+2. 中间层无法稳定处理当前消息
+3. 用户当前输入因为 assistant 忙而被拦截
+4. 当前轮已经进入等待用户动作，但用户可能不知道该轮到自己了
+
+也就是说：
+
+- `assistant 正在正常工作` 不算问题
+- `系统无法继续推进或用户当前不能推进` 才算问题
+
+## 7. 产品定义
+
+## 7.1 对话纯净度原则
+
+飞书窗口里的系统文案应只承担三种职责：
+
+1. 明确要求用户动作
+2. 明确告知用户当前动作被阻塞
+3. 明确告知用户系统出现异常或恢复失败
+
+除此之外，中间层应尽量不插话。
+
+### 7.2 正常路径默认降噪
+
+在默认正常路径里，应抑制这类常规工作中文案：
+
+- `正在处理，请稍候。`
+- `正在思考中，请稍候…`
+- 仅仅为了说明“我还在工作”的重复 heartbeat
+
+保留：
+
+- reaction ack 这类轻量、非正文干扰的收到反馈
+- assistant 最终真正要给用户的答复
+
+### 7.2.1 系统消息不应伪装成 assistant 正文
+
+即使某些系统消息仍然需要出现，它们也不应继续长得像“assistant 又回了一句自然语言”。
+
+这是当前体验里另一个明显问题：
+
+- 文案内容本来只是工作状态
+- 但视觉上却很像 assistant 正式在对人说话
+- 用户会感到窗口被“很多不像正式回复的回复”占满
+
+所以这条专题除了控制“发不发”，还必须控制“长什么样”。
+
+产品上应把飞书里的消息至少分成三层：
+
+1. `最终回复`
+   - assistant 真正对用户的答复
+   - 这是对话主内容，视觉权重最高
+2. `动作型系统消息`
+   - 等审批、等补充信息、恢复失败、明确阻塞
+   - 这是要求用户理解并采取动作的消息，权重中等偏高
+3. `状态型系统消息`
+   - 工作进展、处理中提示、轻量告知
+   - 这是被动状态，不应与最终回复争抢注意力，权重最低
+
+### 7.2.2 状态型系统消息应改成“弱提示卡”，而不是正文口吻
+
+像下面这类消息：
+
+- `⏳ 工作中 准备落文档了...`
+- `⏳ 工作中 方向已经收住了...`
+
+它们的价值是存在的：
+
+- 能让用户知道 assistant 还在推进
+- 能让用户感受到阶段性进展
+
+但它们不属于 assistant 的最终回复，也不属于必须立刻处理的阻塞消息。
+
+因此更合适的产品形态不是普通正文，而是：
+
+> 一种弱存在感的飞书状态卡。
+
+这类卡片的目标不是“解释很多”，而是“轻量露出、明确分层、不打断主对话”。
+
+### 7.2.3 飞书呈现合同
+
+在当前飞书能力下，这类消息应优先使用 card 类承载，而不是继续伪装成普通回复正文。
+
+产品合同建议如下：
+
+1. `最终回复`
+   - 继续使用当前普通回复富文本路径
+   - 不额外包系统壳
+2. `动作型系统消息`
+   - 使用清晰、可识别的系统卡
+   - 标题明确说明：等待你操作 / 需要审批 / 恢复失败 / 请重发
+3. `状态型系统消息`
+   - 使用更轻的 card
+   - 首版标题固定为 `工作进展`，不再继续把 `⏳ 工作中` 当作主标题
+   - 正文只保留一小段短句，不再在正文里重复 `⏳ 工作中`
+   - 不放审批按钮、操作按钮或长解释，只保留状态本体
+   - 使用中性、弱强调的视觉风格，不与最终回复争夺主视觉层级
+
+### 7.2.4 状态型系统消息的样式原则
+
+状态型系统消息应遵守下面四条原则：
+
+1. `像状态，不像答复`
+   - 用户一眼就能分辨：这不是 assistant 对我问题的最终回答
+2. `弱提示，不抢戏`
+   - 允许存在，但不应成为会话里最显眼的内容
+3. `短句，不展开`
+   - 只给阶段性进展，不在这里长篇解释背景
+4. `可连续出现，但不能形成视觉疲劳`
+   - 如果出现多次，用户也应感觉是在看一个稳定的状态层，而不是被很多“伪回复”刷屏
+
+### 7.3 忙时输入门控
+
+当系统判断当前会话为 `Busy` 时：
+
+- 新的普通自然语言消息不进入 runtime
+- 不再默认 interrupt 当前 turn
+- 不建立隐藏队列
+- 由中间层直接拦截并短文案提示用户
+
+建议默认文案：
+
+`我还在处理上一条，请稍后再发一次；如需打断，请发送 /stop。`
+
+这句话要同时完成三件事：
+
+- 说明为什么这条消息没进
+- 告诉用户下一步怎么做
+- 保留用户对当前轮的决定权
+
+### 7.4 忙时门控不是无限刷屏
+
+如果用户在同一个 `Busy` 窗口里连续发送多条自然语言消息，中间层不应每条都重复刷同一句拦截提示。
+
+V1 应采用“同一忙碌窗口内限频提示”的策略：
+
+- 第一次被拦截时明确提示
+- 同一忙碌窗口内后续重复拦截尽量不重复刷屏，或至少明显限频
+- 当前轮结束后，下一次进入新的 `Busy` 窗口时再重新允许提示
+
+否则“为降噪而拦截”，最后会再次制造新的噪音。
+
+### 7.5 `WaitingUser` 不受忙时门控影响
+
+当系统处于 `WaitingUser` 时，用户回复必须继续放行。
+
+原因很简单：
+
+- 这时不是 assistant 在占用对话
+- 而是当前轮已经明确交棒给用户
+
+所以这类输入不应被误判成“打断忙碌中的 assistant”。
+
+### 7.6 控制命令例外
+
+即使系统处于 `Busy`，以下显式控制动作仍应允许：
+
+- `/stop`
+- `/status`
+- 与当前 pending approval 相关的 `/approve`、`/deny`
+- 针对当前 pending user input 的直接回复
+
+V1 对 `/new` 的建议是保守处理：
+
+- 不把 `/new` 设计成忙时的隐式抢占捷径
+- 如果当前轮仍在忙，应优先要求用户先 `/stop`，再决定是否开启新会话
+
+这样可以避免控制语义重新滑回“隐式打断当前轮”。
+
+## 8. 用户路径
+
+### 8.1 正常单轮
+
+1. 用户发消息
+2. 系统用轻量 ack 表示已收到
+3. assistant 在后台工作
+4. 中途不再反复冒“正在处理”类文案
+5. assistant 给出最终答复
+
+用户感受应当是：
+
+- 对话是连贯的
+- 中间层没有抢戏
+
+### 8.2 assistant 忙时，用户又发自然语言消息
+
+1. 用户发出新消息
+2. 系统识别当前会话仍为 `Busy`
+3. 中间层拦截该消息，不送入 runtime
+4. 系统短文案提示：请稍后重发；如需打断请 `/stop`
+5. 当前轮继续，不被默认打断
+
+用户感受应当是：
+
+- 当前轮仍然稳定
+- 没有发生系统替我做决定的隐式抢占
+
+### 8.3 assistant 等审批 / 等补充信息
+
+1. 系统明确告诉用户当前已暂停，等待你操作
+2. 用户直接回复或发审批命令
+3. 输入被正常放行
+4. 当前轮继续
+
+用户感受应当是：
+
+- 现在轮到我了
+- 这不是“被 busy gate 拦住”的场景
+
+### 8.4 assistant 卡住或恢复失败
+
+1. 系统明确告诉用户这是异常 / 恢复中的状态
+2. 若恢复失败，系统明确提示用户重发上一条消息
+3. 不再继续发送误导性的“正在思考中”文案
+
+用户感受应当是：
+
+- 我知道这是系统问题
+- 我知道下一步该怎么做
+
+## 9. 与现有专题的关系
+
+### 9.1 它不是否定“状态可见性”
+
+这条 spec 不是在推翻 `session presence / state visibility`。
+
+它是在把那条专题继续产品化：
+
+- 可见性要保留
+- 但不能把“可见”误做成“高频冒泡”
+
+更准确的判断是：
+
+> 状态可见性应从“持续播报工作中”收敛为“只在状态切换真的影响用户时发声”。
+
+### 9.2 它和“异常透明化”是互补关系
+
+这条 spec 不允许中间层在正常路径里刷存在感。
+
+但它同样不允许中间层在异常路径里静默。
+
+所以两条专题必须同时成立：
+
+- 正常路径降噪
+- 异常路径显式
+
+### 9.3 它和“恢复语义”必须对齐
+
+当 runtime 断连、recovery 进行中时，产品上仍应把该会话视为 `Busy` 或 `Problem`，而不是 `Idle`。
+
+因此：
+
+- 这时新的自然语言消息仍不应默认放行
+- 系统应优先给出恢复或重发语义，而不是切回普通对话模式
+
+## 10. V1 范围
+
+V1 必做：
+
+1. 默认抑制常规 `working` / `heartbeat` 类正文提示
+2. 默认不再因为新自然语言消息而自动 interrupt 当前 active turn
+3. assistant `Busy` 时，对新自然语言消息做门控拦截
+4. 拦截文案明确提示“稍后重发”与 `/stop`
+5. `WaitingUser` 状态下继续允许用户回复进入
+6. 异常 / 恢复失败 / 等用户动作等关键状态继续显式可见
+7. 忙碌窗口内的拦截提示要限频，避免二次刷屏
+
+V1 不做：
+
+- 忙时消息排队
+- 复杂草稿箱或消息暂存
+- 自动合并用户在忙时发来的多条需求
+- 基于消息堆栈的多轮编排
+
+## 11. 标准文案方向
+
+### 11.1 忙时拦截
+
+主文案建议：
+
+`我还在处理上一条，请稍后再发一次；如需打断，请发送 /stop。`
+
+要求：
+
+- 口语化
+- 不带内部术语
+- 不出现 thread / turn / runtime 等实现概念
+
+### 11.2 等待用户
+
+继续保持类似语义：
+
+- `当前已暂停，等待你审批后继续。`
+- `当前已暂停，等待你回复后继续。`
+
+### 11.3 异常 / 恢复失败
+
+继续保持类似语义：
+
+- 系统正在确认当前轮结果
+- 若未能确认，明确要求用户重发
+
+## 12. 验收标准
+
+### 12.1 对话纯净度
+
+在一条正常长耗时 turn 中，用户不再看到连续的：
+
+- `正在处理，请稍候。`
+- `正在思考中，请稍候…`
+
+除非该轮进入真正需要用户知道的异常或等待状态。
+
+### 12.2 默认不再自动抢占
+
+当 assistant 正在忙时，用户再发普通自然语言消息：
+
+- 当前 turn 不会被默认中断
+- 新消息不会被直接送入 runtime
+- 用户会收到清晰的忙时拦截提示
+
+### 12.3 用户控制权保留
+
+当 assistant 正在忙时：
+
+- `/stop` 仍然可用
+- 用户可以显式终止当前轮
+- 系统不会替用户默认做打断决定
+
+### 12.4 `WaitingUser` 路径不受伤
+
+当系统处于等待审批或等待补充信息时：
+
+- 用户回复仍能继续进入
+- 不会被误拦截为“assistant 还在忙”
+
+### 12.5 异常透明化不退化
+
+runtime 异常、恢复失败、消息无法稳定处理等问题仍然会对用户可见。
+
+也就是说：
+
+- 正常路径更安静了
+- 异常路径没有被一起静默掉
+
+## 13. 开放问题
+
+1. 同一忙碌窗口内，拦截提示的限频粒度具体如何定义最合适
+2. `/new` 在 `Busy` 状态下是否完全阻止，还是给一个“先 `/stop` 再 `/new`”的提示
+3. 降噪后的状态可见性，是否需要更多由桌面控制面或 `/status` 来承接
+4. 某些真实 progress commentary 是否应允许透传，还是也应默认收敛到更安静的合同里
+
+## 14. 最终判断
+
+这条 feature 的本质不是“文案优化”，而是一次明确的产品取舍：
+
+> 我们要把 Feishu 会话从“中间层不断解释自己在干什么”，收回到“只在真的影响用户时才开口”。
+
+这会直接改善三件事：
+
+1. 对话纯净度
+2. 用户预期稳定性
+3. 中间层作为产品而不是噪音源的可信度