后台完成 backlog
交互式界面把同一对话下、已就绪的连续后台进程完成事件，合并为单条通知轮次。这不会增加延迟，也不承诺合并在不同时刻完成的任务。失败与成功输出都留在该批次中；单个完成保留其原文。
进程身份在分发前一直可用。因此，显式的 process_manage wait/log/kill 消费即使在一条 CLI 完成消息已离开进程注册表、进入输入队列之后，仍能抑制它。一个被完全消费的批次不开启任何轮次。监听输出与异步委派结果仍是独立通知，保持原有顺序；它们不并入完成批次。
消费者与归属
- 经典 CLI：
hermes_cli/cli_process_notifications.py负责空闲/轮次后的排空、感知压缩的归属判定，以及最终输入解包。 - TUI 与 Desktop：
tui_gateway/session_notifications.py在检查归属后，对轮询器的就绪快照分组。每个进程仍发出自己的 UI 状态。繁忙会话重新入队结构化事件，而非渲染后的批次字符串。 - 轮次后 TUI 安全网：
tui_gateway/prompt_turn.py使用相同的路由与渲染路径。Desktop 与 dashboard 聊天客户端共享此后端。 - 消息 gateway：
gateway/run_notifications.py已使用自己按路由键的短窗口批处理。本次交互式 backlog 改动不替换该机制，也不改变适配器发送。 - 非交互/无头消费者： 本次改动不为 API 请求、ACP 客户端或一次性 CLI 创建新的自主通知循环。
共享渲染器是 tools/process_registry_notifications.py::ProcessNotificationBatch。批次及其投递状态都不写入系统提示词。已寻址事件仍需可证明的归属者；另一个活跃会话不能接管它们。委派投递继续走其既有的持久 claim/complete 账本，按每次委派而非每个进程批次计一次。
本地验证及其局限
evals/completion_backlog_probe.py REPO OUTPUT.json 在临时目录里启动真实的本地 shell 子进程，读取它们真实的完成事件，并驱动生产 CLI、TUI 轮询器与轮次后通知路径。一个回环 HTTP 轮次接收器替换 chat / _run_prompt_submit；它记录真实分发，但不触达模型推理、原生渲染器交互或托管平台。合成的监听与委派信封是带标签的夹具；委派 claim 使用真实的临时 SQLite 账本。backlog 案例包含非零退出。
该探针检查一个就绪 backlog、单个精确载荷、被显式消费的结果、外来归属，以及与完成事件交错的监听/委派。它衡量的是通知边界处的轮次准入，而非模型 token 节省。