停止生成首按即冲洗等待中的排队与插话消息

[wangbingyizx]

停止生成中断运行中的轮次时，把仍在等待的排队与插话消息立即转为下一轮发出，而不是滞留在收件箱失效。

验收与细节

• 现状：SessionCommandController.cancel 以 keepInbox: true 取消后，未被认领的 next-step 插话与 next-turn 排队消息被"停放"——没有任何唤醒，用户看到自己的插话气泡永远不被回答，等价于静默丢失（agent-loop/tests/cancel.spec.ts 的 "parks queued work after an active turn aborts" 即此行为）。
• 期望：停止按钮首次点击 = 停掉当前 agent loop + 等待中的用户消息立即开新轮发出；无等待消息时保持普通停止。注入的非 user 上下文不受影响。
• 验收条件：
  • running 时 cancel：收集 inbox 中 user 来源的 nextTurn+nextStep 消息，cancel(keepInbox) 后逐条 inbox.remove + followup（aborted phase 中 send 会闩住唤醒，driver 退出即重放）。
  • idle 时 cancel：行为不变。
• 用户或模型可见变化：停止后插话气泡立即被消化为新一轮的开场消息并得到回答。
• 测试证据：新增 commands-cancel-flush.host.spec.ts 覆盖 running 冲洗顺序（queued 先、steering 后、context 停放）与 idle 普通停止。
• 行业先例（中断即送达队列，是头部 harness 的既定契约）：
  • Claude Code 官方文档原文："Press Esc to interrupt the turn instead. Claude Code keeps what you queued and sends it right away."（https://code.claude.com/docs/en/interactive-mode）
  • OpenAI Codex CLI 队列提示原文："press esc to interrupt and send immediately"（https://github.com/openai/codex/issues/22599）
  • 用户将"停止丢队列"视为数据丢失缺陷：Queued/pending user input silently lost while agent is working anthropics/claude-code#20431 "Queued/pending user input silently lost while agent is working"。

[wangbingyizx]

参考实现已备好(带完整测试, 新增 commands-cancel-flush.host.spec.ts 覆盖 running 冲洗顺序与 idle 普通停止):

• 分支: https://github.com/wangbingyizx/deepseek-harness/tree/feat/regenerate-and-stop-flush
• 对上游 diff: master...wangbingyizx:feat/regenerate-and-stop-flush
• fork 上的参考 PR: feat: 重新生成回复与停止生成冲洗插话队列(参考实现, deepseek-harness Discussions #4831 #4832) wangbingyizx/deepseek-harness#1

相关提案: #4831

[liyangbing]

这个问题在 alpha.1 官方测试里有非常明确的当前契约，可以把“保留”和“送达”分开：

• SessionCommandController.cancel() 调用 agent.cancel({ kind: "user" }, { keepInbox: true })；
• Stop 之前尚未 claim 的 next-turn / next-step 输入不会被删除；
• 但 cancel.spec.ts 的现有测试明确叫 parks queued work after an active turn aborts：Agent 到 idle 后消息仍在 inbox，没有第二次模型请求；
• 只有 abort 已经触发、但 Agent 尚未收敛到 idle 的窗口内到达的新 waking message，才会被转成 next-turn 并设置 wakeRequested；
• Agent 已经 idle 后发送普通 prompt，也会唤醒 driver，并可能一起 claim 之前 parked 的输入。

所以当前症状更准确地说是 消息被保留但没有 delivery wake，不是物理删除；但对用户而言，气泡永久不被回答，确实等价于静默丢失。

建议修复时额外守住几个边界：

1. 只自动送达 user-owned 的 queued/steering message；plugin context、Goal notice、child settlement 等非 user owner 保持原有 non-waking 语义；
2. 保留原 message id、附件、来源和 FIFO，不要 remove/reinsert 后换 identity；
3. 已被 aborted driver claim 的消息不能“恢复”；
4. Stop、claim、queue edit/cancel 与重新唤醒需要串行化，确保每个 id 只会 claimed / canceled / retained 一次；
5. pre-abort steering 原本属于已终止 step，转到下一 Turn 时需要显式定义顺序和语义；
6. stopping、queued for next Turn、claimed、failed 应分别可见；
7. 测试至少覆盖 queued-first/steering-second、附件、slow abort convergence、多次 Stop、idle Stop、重连和 cold reload。

如果实现采用 inbox.remove + followup，还需要专门证明两步之间 claim 或用户 queue mutation 获胜时不会丢失、重复或断开 optimistic bubble 与 durable event 的身份关联。能够直接原子化地“保留原 id + arm one wake”会更容易形成清晰契约。

当前版本的安全人工恢复是：先等 turn/end: aborted 和 Agent idle，按 stable id 清点 parked user messages，核对外部副作用；全部仍有效时只发一条明确 wake follow-up，不要重复复制那些不可见消息。

完整的当前行为表、操作恢复和十项产品契约：https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/stuck-turn-stop-and-retry.md#stop-preserves-queued-input-but-may-not-deliver-it