后台完成积压

交互式界面会将同一会话中已经就绪的连续后台进程完成事件合并为单个通知轮次。这不会增加延迟，也不承诺把在不同时间完成的任务合并在一起。失败和成功的输出都会保留在批次中；单个完成事件保留其原始文本。

进程身份在派发之前始终保持可用。因此，即使在 CLI 完成事件离开进程注册表并进入输入队列之后，显式的 process_manage wait/log/kill 消费仍可将其抑制。若一个批次被完全消费，则不会启动任何轮次。输出监视和异步委托结果仍作为单独的通知，按其原始顺序发送；它们不会被折叠进完成批次。

消费者与归属

• 经典 CLI： hermes_cli/cli_process_notifications.py 负责空闲/轮次后排空、压缩感知归属以及最终的输入解包。
• TUI 与 Desktop： tui_gateway/session_notifications.py 在检查归属后对轮询器的就绪快照进行分组。每个进程仍会发出自己的 UI 状态。繁忙会话重新排队的是结构化事件，而不是已渲染的批次字符串。
• 轮次后 TUI 安全网： tui_gateway/prompt_turn.py 使用相同的路由和渲染路径。Desktop 和 dashboard 聊天客户端共享此后端。
• 消息网关： gateway/run_notifications.py 已经使用其自己的按路由键控的短窗口批处理。此交互式积压变更不会取代该机制，也不会改变适配器发送。
• 非交互/无头消费者： 此变更不会为 API 请求、ACP 客户端或一次性 CLI 创建新的自主通知循环。

共享渲染器是 tools/process_registry_notifications.py::ProcessNotificationBatch。批次及其投递状态都不会持久化到系统提示中。定向事件仍需要可证明的归属者；另一个活跃会话无法接管它们。委托投递继续通过其现有的持久化认领/完成账本进行，每次委托一次，而非每个进程批次一次。

本地验证及其局限

evals/completion_backlog_probe.py REPO OUTPUT.json 在临时目录中启动真实的本地 shell 子进程，读取其真实的完成事件，并驱动生产环境的 CLI、TUI 轮询器和轮次后通知路由。一个回环 HTTP 轮次接收器替代了 chat / _run_prompt_submit；它记录实际派发，但不会执行模型推理、原生渲染器交互或托管平台。合成的监视和委托信封是标记为夹具的测试数据；委托认领使用真实的临时 SQLite 账本。积压用例包含一个非零退出码。

该探针检查就绪积压、单个精确有效载荷、被显式消费的结果、外部归属，以及与完成事件交错的监视/委托。它在通知边界处衡量轮次准入门槛，而非模型 token 节省量。