中断之后，排队消息只剩「编辑/删除」：唯一的发送按钮被 running 门挡成灰色

[mengge237]

一轮任务被停止之后，输入框上方「N 条排队消息」里那些行的发送按钮就永久变灰，悬停给出「仅运行中可插话发送」。此刻队列里的内容发不出去、也没有任何提示告诉它什么时候会走；唯一出路是再敲一条新消息把它顺带带出去。

环境

• @deepseek-ai/dsh 0.1.7-rc.2（npm dist-tag next，发布 2026-09-24T14:18:11Z），dsh --version 同读数
• 界面：dsh web（本机 GUI，未使用桌面端）
• Windows 11 / Node 22
• 源码位置另按仓库克隆 a5701f7（2026-09-06）列一份；两处口径一致，个别行号随重构会漂移，以产物为准

这条链上只有官方包，插件不参与

本机 profiles/web/node_modules 里除 @deepseek-ai 之外，对 updateQueue / QueueDock / steerQueue 的引用只有 1 处，且是某个第三方包的 .d.ts 注释里提到 "GoalDock/QueueDock seam"，没有任何调用点。下列判据全部读自官方包产物。

代码位置

1. 停止按钮走的是「保留队列」的取消：packages/host/apiproxy/src/api-proxy.ts:2534-2548 → agent.cancel({ kind: 'user' }, { keepInbox: true })（产物：@deepseek-ai/dsh-api-session-controller/lib/index.js:998）。keepInbox 为真时不清 inbox（packages/core/agent-loop/src/agent.ts:135）。
2. 队列变更动作只有三种：edit / remove / steer（产物 schema：@deepseek-ai/dsh-api-session-controller/lib/typert.host.js:728、:736；分支：api-proxy.ts:2525-2530）。没有一个是「空闲时把这行投递出去」。
3. steer 在空闲时被硬拒：api-proxy.ts:2518-2524 —— action.kind === 'steer' && (target !== 'next-turn' || agent.status !== 'running') → steer-unavailable / current turn no longer accepts steering（产物：dsh-api-session-controller/lib/index.js:966）。
4. 前端把那枚按钮写成 running-only：packages/client/ui-conversation/src/client/queue/QueueDock.tsx:186-192 —— disabled={busy !== null || !running}、title={running ? undefined : t('queue.steer.unavailable')}；文案在 src/client/locales.ts:167「仅运行中可插话发送」（产物：dsh-client-ui-conversation/lib/client.js:15508-15513）。队列头部只有折叠/展开（QueueDock.tsx:87），没有整批投递入口。键盘和牌面同一口径：canSteerQueue 也要求 running（产物 dsh-client-ui-conversation/lib/client.js:17220）。
5. 同一份代码里，新发的消息在空闲时是能落地的：产物 dsh-api-session-controller/lib/index.js:882-883 —— request.mode === 'steer' ? agent.steer(message) : agent.followup(message)；而 followup() 就是「投进 next-turn 并唤醒」（dsh-agent-loop/lib/index.js:806-807）。唤醒能力现成存在，只是队列那条 API 没有指向它的动作。

这不是队列被意外留下，是你们明确期望的状态

packages/core/agent-loop/tests/cancel.spec.ts:103 的用例名就叫 cancel({ keepInbox: true }) parks queued work after an active turn aborts，断言 abort 之后 agent.inbox.nextTurn 仍为 1 条，直到下一次 send 才按 ['active', 'preserved', 'wake it'] 的顺序跑完。也就是说「停在队列里等下一轮」是设计，缺的是让人知道这件事、并能主动触发它的入口——现在队列行露出来的只有编辑和删除，读起来就像这条消息除了丢掉没有别的处置方式。

复现（不依赖任何插件，消耗 2 轮请求）

1. 开一条会话，发一句会让它跑起来的话（例如让它执行一个 sleep 30 的命令）。
2. 运行中在输入框再打一条普通消息并发送 → 它进入「1 条排队消息」。
3. 点停止，等状态回空闲。
4. 展开队列那一行：发送图标灰色不可点，悬停「仅运行中可插话发送」；行上只剩编辑与删除。
5. 再随便发一条新消息，第 2 步那条排队内容才会被带出去。

判据（只在缺陷成立时出现）：第 4 步那枚按钮 disabled 且 title 是那六个字；第 5 步之后你新发的消息晚于排队内容被处理（每轮只从 next-turn 取一条：dsh-agent-loop/lib/index.js:105 的 mutate('next-turn', 0, 1, ...)）。哪天第 4 步变成可点、或队列头部出现整批投递入口，本条判据即失效。

请求（任一条都行）

• 给 updateQueue 加一个空闲也可用的动作（例如 kind: 'deliver'，直接走已有的 agent.followup(message)），QueueDock 那枚按钮在 !running 时改成「立即发送」而不是变灰。改动量看着就是一个 schema 分支加一处 label。
• 或者只把预期说清楚：停止时若 next-turn 非空，在队列头部显示一句「本轮已停止，N 条排队消息将在下一次发送时带出」。宁可多一行字，也不要让人以为输入被吞了。

说明

第 4 步的灰按钮与「只能靠再发一条消息」是本机使用中的实际遭遇（未记时刻、未截图）；第 1-5 步是按上面那些代码路径写的复现流程，本方尚未逐步骤截图留档。代码行号、schema 分支与那条测试断言，都是本方在自己机器上的安装产物与仓库克隆里逐条读过的。

[mengge237]

自纠：这条与 #4832 重复，本条撤回请求 1，只留两点 #4832 没覆盖、能在 0.1.7-rc.2 产物上复算的补充，后续以 #4832 为主线。

发这条之前我没读上游自己的设计备忘 2026-07-30-web-queue-steer-action.md（本机克隆 a5701f7 把它放在 .agents/notes/implemented/feature/ 下，另有 .zh.md 一份；这条线后来被归档到 .agents/notes/archived/feature/），也没做线程查重。#4832（2026-08-28，仍 open）已经把「停止保留队列但不送达」报清楚了：liyangbing 在那条下给的当前契约表——SessionCommandController.cancel() → agent.cancel({kind:'user'},{keepInbox:true})、cancel.spec.ts 的 parks queued work after an active turn aborts、以及「消息被保留但没有 delivery wake，不是物理删除」这个准确口径——比我这条更准；wangbingyizx 那边还有参考实现分支与 commands-cancel-flush.host.spec.ts。

撤回请求 1（给 updateQueue 加一个空闲可用的 deliver 动作、内部走 agent.followup(message)、按钮由灰改成「立即发送」）。备忘「考虑过的替代方案」一节明文不予采纳过同形状的一条：「恢复向上箭头对应的 Queue 前移操作 —— 不予采纳，因为把某个项移到队首仍然会创建一个独立接纳的轮次。该控件承诺的是当前轮次 steering，而不是 Queue 内的优先级。」我那条请求就是它。liyangbing 也在 #4832 那段边界清单末尾另起一段写了「如果实现采用 inbox.remove + followup，还需要专门证明两步之间 claim 或用户 queue mutation 获胜时不会丢失、重复或断开身份关联」，并说「能够直接原子化地『保留原 id + arm one wake』会更容易形成清晰契约」。

留下两点补充：

1. 一次 wake 只救得了队首那条。 @deepseek-ai/dsh-agent-loop/lib/index.js:105 的 claim() 写的是 this.mutate("next-turn", 0, 1, [], false) —— deleteCount 恰为 1；而同一函数 :104 那侧的 next-step 是按 this.nextStep.length 整批取。所以「停止时排了三条」这个场景，即便按 停止生成首按即冲洗等待中的排队与插话消息 #4832 的建议补上 delivery wake，后面两条仍要各自再有一轮才走。若实现选「保留原 id + arm one wake」，claim 里这个 1 得一起定口径，否则修复只对队首生效。复算命令（产物目录里直接跑，输出非空即这条还没动）：rg -n 'mutate\("next-turn", 0, 1' node_modules/@deepseek-ai/dsh-agent-loop/lib/index.js
2. 界面上没有任何一处说出「这轮不走、下轮才带出」。 备忘写的是严格拒绝「保留原入队项、经 Queue 继续执行且不显示失败」——我同意不该弹失败；但用户能看到的信号全指向另一头：QueueDock 那枚箭头在空闲时 disabled，悬停是 locales.ts:167 的「仅运行中可插话发送」，队列头部只有折叠/展开（QueueDock.tsx:87）。三条加起来读起来就是「这条消息除了编辑和删除没有去处」。请求收窄成一处纯文案/状态、不动投递语义：停止时若 next-turn 非空，队列头部显示一句「本轮已停止，N 条排队消息将在下一次发送时带出」。判据：rg -n 'queue\.(steer\.unavailable|nextTurnWillDeliver)' packages/client/ui-conversation/src/client/locales.ts 出现新的下一轮口径文案即算动过。

第 2 点若上游认为「不显示失败」就是终局设计、宁可什么都不说，直说一句即可，我按 #4832 跟进，不再在本条追。