收窄 assignment 队列职责

docs/runner-protocol-roadmap.md

@@ -51,9 +51,11 @@ controller 使用单一 Go 二进制；默认在同一进程启用 `scheduler`
   SPIFFE ID写入 sandbox metadata；通过 `extensions.poolRef=ci-vm` 使用既有 Kata Pool。
 - 结果处理顺序固定为回报 Gitea、清理后端、ACK assignment；重投时先查询 Gitea 终态，
   从而关闭后端已删除但消息尚未 ACK 的崩溃窗口。
-- pod 与 vm 使用独立 durable consumer 和并发上限。worker 持有消息期间持续 reconcile
-  后端并发送 `InProgress`；只有完整完成才 `DoubleAck`，进程退出则保留未确认消息供
-  其他实例恢复，临时后端错误使用延迟 NAK。
+- pod 与 vm 使用独立 durable consumer 和并发上限。consumer 只负责将 assignment
+  幂等落到后端；executor 与身份恢复 metadata 持久化后立即 `DoubleAck`。尚未取得
+  Pod UID 等短暂未就绪状态以及临时后端错误使用延迟 NAK。
+- assignment ACK 后的运行、结果回报和清理由 backend reconciler 根据 Kubernetes、
+  OpenSandbox 与 Gitea 的事实状态驱动，不继续占用 JetStream delivery。
 - Pod 与 VM 共享 task/executor 协议，只有环境创建和销毁实现不同。
 
 ## 实现顺序