停止后队列续跑 evanw0211/dsh-queue-resume-on-stop

停止后恢复队列

一个 DSH 的小型 Host 插件，让你按下 Stop 之后，排队的消息继续流动。

问题

一轮对话运行期间，你发送的任何内容都会排进智能体的收件箱（agent.inbox.nextTurn），在下一个轮次边界被取走。

Stop 按钮会调用 agent.cancel({ kind: 'user' }, { keepInbox: true })（dsh-api-session-controller → session.cancel）。这会中止正在进行的轮次，并且刻意保留队列 —— 但之后没有任何东西重新唤醒驱动器：

- 正常的轮次结束会继续循环：只要 inbox.hasPending，turn() 就返回 true，于是下一个排队的提示词立即被取走。
- 中止会从 turn() 里抛出异常，于是 kick() 展开退出，驱动器停下。排队的提示词留在收件箱里，永远不会发给模型。

循环其实已经处理了镜像的那一种情况：中止之后到达的消息会被归类为唤醒（send() → wakingAfterAbort），它会锁存 phase.wakeRequested；kick() 的退出路径会重放这个锁存。而在 Stop 之前排队的消息从不设置锁存 —— 这正是本插件要补上的缺口。

用户看到的现象：排队的消息一直卡在队列里（永远得不到回答），直到某条新消息碰巧唤醒驱动器。

它做什么

每当出现一条持久化的 turn/end，其原因是 aborted、诱因是 user（Stop 按钮）或 parent（父级打断子级），只要同一个智能体仍有待处理的 nextTurn 提示词，插件就请求循环再唤醒一次 —— 与你在 Stop 之后片刻输入一条消息的效果完全一样。下一轮随即取走排队的提示词，发给模型。

disposed（拆除）和 hook（凭据/会话失效）导致的中止会被忽略：在那里重启工作会与拆除过程相冲突。next-step 输入（agent.inject()）刻意不唤醒，也不会被恢复。

安装

它是一个普通的 Host bundle：没有依赖，没有构建步骤。把 DSH 的插件管理器指向这个目录（绝对路径），它就会安装包、把 bundle 加进配置档，并通过 HMR 激活：

plugin_manager install_bundle <path-to-this-directory>

等价地，从命令行执行：dsh plugin --profile <name> add <path-to-this-directory>。

需要 DSH 0.2.0-rc.2。bundle 从正在运行的安装中解析每一个 Harness 包，因此它自己不声明任何依赖。

配置

cordis.patch.yml 插入一行；在你的配置档补丁里覆盖它：

- id: queue-resume-on-stop
config:
enabled: false # turn the behavior off without uninstalling

文件

| 文件 | 作用 |
| index.js | Host 插件：session/event 触发器和唤醒逻辑 |
| cordis.patch.yml | 插入 queue-resume-on-stop 行 |
| package.json | bundle 清单（dsh.bundle.patch） |
| locale/*.json | 插件管理器的显示文本 |
| dev/scan-stranded-queue.mjs | 扫描已存储的会话日志，找出「停止让队列搁浅」的发生 |
| dev/dump-session.mjs | 导出某段 session.v4.jsonl.zstd 日志 |

关于唤醒的说明

公开的 Agent 接口（followup/steer/inject/cancel/inbox）没有唤醒原语。要重新排队一条待处理的提示词，得用 inbox.remove(id) + followup(message)，这会写入一条持久化的「已取消」收件箱拼接记录并重新插入——而 Session.append() 在 session/event 观察者运行期间拒绝重入，这个监听器恰好就在那里执行。

所以插件在 wakeDriver(true) 存在时直接调用它：它只改动内存里的阶段闩锁（send() 在终止后路径上发起的调用完全一样），不向会话日志追加任何内容。如果将来的循环改了它的名字，插件就退回公开的 remove + followup() 路径，并推迟到追加之后执行。