feat: freeze legacy code queue entry

docs/reference/code-queue-supervision.md

@@ -36,7 +36,7 @@ HWLAB 业务目标、验收和实现优先级归 `pikasTech/HWLAB#7`；UniDesk
 
 审阅 HWLAB runner 输出时，不能把 `SOURCE`、`LOCAL`、`DRY-RUN`、fixture 或只读报告误当成 `DEV-LIVE`。除非输出真的证明了 `res_boxsimu_1:DO1 -> hwlab-patch-panel -> res_boxsimu_2:DI1` 的真链路，并且带有 operation / audit / evidence 关联，否则只能归类为 support、diagnostics 或 contract。
 
-`split-brain live` 且 heartbeat/trace 新鲜时，指挥官必须继续监督，不把它当作服务中断。此类状态的优先动作是继续轮询、继续审阅、继续派单，而不是默认 interrupt 或 cancel。`codex submit` 的默认写入确认也遵守同一口径：如果 queue counts 显示 running/queued 非零，但 default summary 不能枚举 active/queued id 列表，CLI 必须返回 `idsUnavailable=true` / `itemsOmitted=true` 和 `stateDisclosure.idsUnavailableMeaning`，而不是输出看起来像“没有 active/queued 任务”的 `items=[]`。需要 raw drill-down 时使用返回的 `queue.listPreviewPolicy.rawCommand`，即 `bun scripts/cli.ts microservice proxy code-queue /api/tasks/overview?limit=30 --raw --full`。
+`split-brain live` 且 heartbeat/trace 新鲜时，指挥官必须继续监督，不把它当作服务中断。此类状态的优先动作是继续轮询、继续审阅和在 AgentRun Queue 中派发新任务，而不是默认 interrupt、cancel 或重启旧运行面。旧 `codex task/tasks/output/read/unread/queues` 的 bounded summary 仍用于历史监督；旧 `codex submit` 不再作为新任务写入确认来源。需要 raw drill-down 时使用返回的 `queue.listPreviewPolicy.rawCommand`，即 `bun scripts/cli.ts microservice proxy code-queue /api/tasks/overview?limit=30 --raw --full`。
 
 `codex tasks --view commander --limit N` 是指挥官高频轮询入口，必须保持默认 stdout 严格有界。它优先展示 active runner 精确计数与少量 active item、queued/retry_wait count、terminal unread compact counts、关键 risk counts 和 drill-down commands；历史 terminal unread item details、prompt preview、final response preview、trace/output 和 raw overview 不在默认 commander 输出中展开。需要审阅 terminal unread 详情时使用 `bun scripts/cli.ts codex unread --limit N`、`bun scripts/cli.ts codex tasks --unread --view supervisor --limit N`、`bun scripts/cli.ts codex tasks --view full --limit N` 或 per-task `bun scripts/cli.ts codex read <taskId>`。
 
@@ -91,16 +91,16 @@ HWLAB M3 口径使用同一分级：只读报告、fixture、LOCAL/DRY-RUN 和 d
 
 ## 模型和成本路由
 
-Code Queue 派单模型按成本、可信度和 blast radius 分层：GPT-5.5/Codex 处理高风险和复杂任务，DeepSeek/OpenCode 处理中等复杂度且边界清晰的任务，MiniMax/OpenCode 处理简单、低权限、可复核任务，生产重启、密钥、数据库手工写入和运行中任务控制保留给指挥官或人工。
+AgentRun 新派单和历史 Code Queue 审阅都按成本、可信度和 blast radius 分层：GPT-5.5/Codex 处理高风险和复杂任务，DeepSeek/OpenCode 处理中等复杂度且边界清晰的任务，MiniMax/OpenCode 处理简单、低权限、可复核任务，生产重启、密钥、数据库手工写入和运行中任务控制保留给指挥官或人工。
 
-当前提交合同由 `bun scripts/cli.ts codex submit` 暴露：prompt 必须来自位置参数、`--prompt-file` 或 `--prompt-stdin`；可选字段包括 `--queue/--queue-id`、`--provider-id/--provider`、`--cwd/--workdir`、`--model`、`--reasoning-effort`、`--execution-mode/--mode`、`--max-attempts` 和 `--reference-task-id/--reference/--ref`。长 prompt、多行 prompt、含引号/反引号/Markdown 表格/JSON/反斜杠的 prompt 应使用 `--prompt-stdin` 或 `--prompt-file`，例如 `cat <<'PROMPT' | bun scripts/cli.ts codex submit --prompt-stdin --queue <id> --dry-run` 或 `bun scripts/cli.ts codex submit --prompt-file /tmp/code-queue-prompt.md --queue <id> --dry-run`；位置参数只适合短单行 smoke prompt。提交前先用 `--dry-run` 检查完整 payload，确认后移除 `--dry-run`。`--execution-mode` 只表示 Code Queue runtime placement，有效值是 `default` 与 `windows-native`；像 `full-access` 这类 sandbox-like 值必须在 response 中显示 requested/effective mapping，并提示真实权限看服务级 `runnerPermissions.sandbox` / `approvalPolicy`，当前不支持每任务 sandbox override。真实提交成功只返回低噪声写入确认、task id、队列和后续查看命令，必须标记 `promptOmitted=true` 且不得回显 prompt；需要复核正文时用返回的 `codex task <taskId>` 渐进展开。这些字段写入任务 payload 后由 `code-queue-mgr` 入 PostgreSQL，核心任务字段包括 `queue_id`、`provider_id`、`execution_mode`、`model`、`cwd`、`prompt/base_prompt`、`reference_task_ids`、`reasoning_effort`、`max_attempts` 和 `task_json`；`task_json` 还保留 `requestedExecutionMode` 以便审计 requested/effective 差异；队列记录至少有 `id/name/created_at/updated_at`。模型治理应优先看任务 payload 和数据库字段，不靠 worker final response 自报。
-真实 `codex submit` 确认输出的 `queue` 是低噪声监督摘要：`queuedTaskIds.items` 必须强制包含本次新建且仍为 queued/retry_wait 的任务 ID；`activeTaskIds` 在主 server 控制面 `activeTaskIds=[]` 但 `counts.running/judging>0` 时必须回退到 PostgreSQL `databaseActiveTaskIds` 或执行诊断中的 active IDs；这些 ID 列表都只能作为带 `count/returned/omitted/truncated/source` 的有界预览，权威并发口径来自 `counts` 和 `countContext`。当预览没有展开所有 ID 时，`listPreviewPolicy` 必须明确说明 omitted counts 和 raw 查看命令，避免指挥侧误判 15-runner 目标。
+当前新任务派发合同由 `bun scripts/cli.ts agentrun v01 queue|sessions` 暴露：`queue commander` 查看 AgentRun 指挥官队列，`queue submit --json-file <task.json>` 创建任务，`queue dispatch <taskId> --json-file <dispatch.json>` 派发，`sessions trace/output/read/steer/cancel` 读取和控制 AgentRun session。本地 UniDesk bridge 只把 `--json-file`、`--prompt-file`、`--runner-json-file` 或 `--prompt-stdin` materialize 到 G14 `/root/agentrun-v01` 临时文件，再调用官方 `./scripts/agentrun --manager-url auto`；它不是旧 Code Queue adapter，不做双写，也不迁移旧历史。
+旧 `codex submit/enqueue`、`codex steer`、`codex resume`、旧 queue mutation、task move 和旧 workdir mutation 已冻结。CLI 必须返回 `ok=false`、`frozen=true`、`degradedReason=legacy-code-queue-frozen` 和 AgentRun 替代命令；服务端旧 API 写入口必须返回 410。旧 `codex task/tasks/output/read/unread/queues` 继续作为历史归档和只读排障入口，`codex interrupt|cancel` 只用于停止残留旧任务。
 
-运行态默认模型仍是 `gpt-5.5`。`CODE_QUEUE_MODELS` 当前长期合同至少包含 GPT-5.5、GPT-5.4、GPT-5.4 Mini、DeepSeek Chat、MiniMax M3 和 MiniMax M2.7 两路并行配置；`deepseek`/`deepseek-chat`、`minimax-m3` 与 `minimax-m2.7` 会走 OpenCode port，其余模型走 Codex port。PROD 集群把 `MINIMAX_MODEL` 切到 `MiniMax-M3`（M3 是新任务的默认 provider model），judge 与 opencode 跟随；M2.7 仍然作为并行配置存在，切换只需把 `MINIMAX_MODEL` 改成 `MiniMax-M2.7` 后 rollout restart。两者不存在自动 fallback 关系：M3 任务失败不会自动改派 M2.7，task 要用 M2.7 必须显式 `--model minimax-m2.7`。只有当执行面 `/health` 或等价配置已经显示 DeepSeek 模型可用、并完成轻量 runner smoke 后，才允许真实提交 `--model deepseek-chat`。
+新任务模型由 AgentRun queue payload 和 AgentRun runtime 配置决定；旧 Code Queue 的 `CODE_QUEUE_MODELS` 只作为历史任务审阅和残留运行面配置参考，长期合同至少包含 GPT-5.5、GPT-5.4、GPT-5.4 Mini、DeepSeek Chat、MiniMax M3 和 MiniMax M2.7 两路并行配置；`deepseek`/`deepseek-chat`、`minimax-m3` 与 `minimax-m2.7` 会走 OpenCode port，其余模型走 Codex port。PROD 集群把 `MINIMAX_MODEL` 切到 `MiniMax-M3`（M3 是新任务的默认 provider model），judge 与 opencode 跟随；M2.7 仍然作为并行配置存在，切换只需把 `MINIMAX_MODEL` 改成 `MiniMax-M2.7` 后 rollout restart。两者不存在自动 fallback 关系：M3 任务失败不会自动改派 M2.7，task 要用 M2.7 必须显式 `--model minimax-m2.7`。只有当执行面 `/health` 或等价配置已经显示 DeepSeek 模型可用、并完成轻量 runner smoke 后，才允许真实提交 `--model deepseek-chat`。
+
+`codex prompt-lint [prompt|--prompt-file path|--prompt-stdin]` 仍是派单前的本地 dry-run guardrail，用于检查 runner prompt 是否声明 `DEV test class`、允许的 live mutation、禁止动作和 closeout 字段。它只返回分类、缺失或矛盾项和有界 evidence，不提交任务、不连接 live service、不打印完整 prompt；新派单时由指挥官把 lint 结果纳入 AgentRun `queue submit` payload 审查。
 
-`codex submit --dry-run` 是派单前的轻量 preflight。它输出 `routingRecommendation`、`policyContract` 和模型注册表，帮助指挥官看到推荐 runner/model、风险信号、缺失的 prompt guard、模型分层、并发上限、`opencodeModels` 和 `modelPorts`；它不会修改真实提交 payload，也不会替代指挥官判断。真实派单是否使用 `--model minimax-m3`、`--model minimax-m2.7`、`--model deepseek-chat` 或 `--model gpt-5.5` 仍由指挥官显式决定。
 
-`codex prompt-lint [prompt|--prompt-file path|--prompt-stdin]` 是同一套派单前 guardrail 的本地 dry-run 入口，用于检查 runner prompt 是否声明了 `DEV test class`、是否列出允许的 live mutation、禁止动作和 closeout 字段。它只返回分类、缺失或矛盾项和有界 evidence，不提交任务、不连接 live service、不打印完整 prompt。`codex submit --dry-run` 和 `codex steer --dry-run` 会嵌入同一 `promptLint` 结果；`dispatchDisposition=needs-authorization` 时，指挥官必须补齐授权或把 prompt 降到 `read-only` 范围后再派发/steer。
 
 Device Pod 类 DS 派单必须把工具可用性设计进 prompt，而不是靠事后强制纠偏。prompt 应明确唯一 pod、workspace selector、目标工程/target、允许的 live mutation、禁止的 pod/BOOT/生产/密钥/数据库范围和 closeout 字段；文本源码修改默认要求 `hwpod ... workspace apply-patch`，新文件使用 `apply-patch --add-file`，整文件替换使用 `apply-patch --replace-file`，不要优先 `workspace put`。命令入口默认写短别名 `hwpod`，不要写长路径 `node /app/skills/device-pod-cli/scripts/device-pod-cli.mjs`；`hwpod` 必须作为 Code Queue 镜像和 provider dev container 的 PATH 命令存在，并从 `DEVICE_POD_CLI`、`UNIDESK_SKILLS_PATH/device-pod-cli`、当前 workspace 的 `skills/device-pod-cli` 或 `tools/device-pod-cli.mjs` 解析真实 CLI。添加 Keil 源文件、build clean、download、UART/JSON-RPC smoke 也应走 `hwpod`。prompt 中只允许把 `/app/tools/tran.mjs`、`/app/tools/hwlab-gateway-tran.mjs`、临时 Python/PowerShell/JS 上传脚本列为禁止绕行；如果 DS 仍然需要这些绕行，指挥官应先把缺失能力补进 `device-pod-cli`/`hwpod`，再重置 workspace 让 DS 复测。
 
@@ -226,7 +226,7 @@ GPT-5.5 PR/收口类 prompt 在提交前可先用 host commander 辅助 lint 做
 bun scripts/cli.ts commander prompt-lint --kind gpt55-pr --prompt-file /tmp/code-queue-prompt.md
 ```
 
-该检查只服务于指挥官补齐派单边界，不是业务 PR 门禁，也不改变 `codex submit` 默认行为。输出只包含 `ok`、`missingClauses`、`riskLevel`、`suggestedPatchSnippet` 和 prompt shape，不回显完整 prompt；`data.ok=false` 表示建议补齐 PR/自合并/rebase/update 授权、artifact build/publish 授权、host-owned DEV rollout、未显式 `ROLLOUT_OK` 时禁止 runner rollout、以及 PROD/secret/DB/破坏性回滚边界。
+该检查只服务于指挥官补齐派单边界，不是业务 PR 门禁；legacy `codex submit` 已冻结，新任务 payload 审查走 AgentRun Queue。输出只包含 `ok`、`missingClauses`、`riskLevel`、`suggestedPatchSnippet` 和 prompt shape，不回显完整 prompt；`data.ok=false` 表示建议补齐 PR/自合并/rebase/update 授权、artifact build/publish 授权、host-owned DEV rollout、未显式 `ROLLOUT_OK` 时禁止 runner rollout、以及 PROD/secret/DB/破坏性回滚边界。
 
 Runner preflight 优先使用执行面诊断入口：
 
@@ -275,11 +275,11 @@ bun scripts/cli.ts codex pr-preflight --remote --issue <issue-number>
 
 ### Runner Resume 收口
 
-PR 小修、冲突、rebase、补测和 reviewer feedback 默认优先 resume 原 Code Queue task，而不是派 replacement runner。正式入口是 `bun scripts/cli.ts codex resume <taskId> --prompt-file <path> [--resume-id id]`；prompt 仍必须来自位置参数、`--prompt-stdin` 或 `--prompt-file` 三选一，复杂多行内容优先文件或 stdin。真实 resume 成功只应返回 taskId、resumeId/turnId、`deliveryState`、是否复用原 `codexThreadId`/session、有界 trace confirmation 和后续 `codex task/detail/trace/output` 查询命令，不回显完整 prompt。
+PR 小修、冲突、rebase、补测和 reviewer feedback 的新执行入口是 AgentRun Queue/Sessions。仍在 AgentRun session 内的工作优先使用 `bun scripts/cli.ts agentrun v01 sessions steer <sessionId> --prompt-file <path>` 或 AgentRun reuse/turn 能力；已沉淀成新工作项时使用 `bun scripts/cli.ts agentrun v01 queue submit --json-file <task.json>`。旧 `codex resume` 已冻结，不再作为 follow-up turn 入口。
 
-`codex resume` 只用于终态或 awaiting-closeout task。running/judging task 必须结构化失败并提示改用 `codex steer`；不存在 task、不可恢复状态或运行面不支持 follow-up turn 时必须 fail closed，不得伪装成新的 `codex submit`。同一个 `resumeId` 加同 prompt 必须 duplicate-suppressed；同一个 `resumeId` 加不同 prompt 必须 409 conflict；delivery timeout 或确认缺失时输出 `deliveryUnconfirmed` 和确认命令，指挥官先查 trace，再用同一 `resumeId` 重试。
+旧 Code Queue task 只保留历史审阅和残留停止；需要基于旧任务产出继续推进时，在 AgentRun payload 中显式引用旧 task id、PR/branch 和审阅结论，而不是把旧 task 重新入队、resume 或 double-write。
 
-replacement runner 只用于方向明显错误、质量不可接受、原 task 上下文不可恢复、原分支/PR 已废弃，或 resume 结构化 blocker 已证明无法继续的情况。关闭或替换旧 PR 时必须在 PR/body/final response 中说明 superseded/replacement 关系，避免 competing branch 扩散。
+replacement runner 只用于方向明显错误、质量不可接受、原 task 上下文不可恢复、原分支/PR 已废弃，或 AgentRun reuse/steer 已证明无法继续的情况。关闭或替换旧 PR 时必须在 PR/body/final response 中说明 superseded/replacement 关系，避免 competing branch 扩散。
 
 ## 监控
 
@@ -288,16 +288,16 @@ replacement runner 只用于方向明显错误、质量不可接受、原 task
 常用入口：
 
 - `bun scripts/cli.ts codex tasks --view commander --limit N`：host commander 轮询的推荐入口。输出是有界 action map，必须直接显示 `activeRunners.count`、计数来源、split-brain/heartbeat 处置、queued/retry_wait 精确计数、terminal-unread 总数和已省略行数、active 风险数、stale/heartbeat/trace gap、`finalResponse` 已出现但仍非终态的 awaiting terminal/judge、blocker-like final response、HWLAB#7/#99/#116/#164/#317 与 UniDesk#20/#118 命中、任务分类和下一步 drill-down 命令。默认不得输出完整 prompt、完整 final response、raw output、完整 trace 或 raw overview；需要详情只能按 task id 使用 `codex task`、`codex task --trace`、`codex output`、`codex read` 或 `rawOverview` 命令渐进展开。
-- `bun scripts/cli.ts codex tasks --view supervisor --limit N`：查看默认低噪声监督视图，包括 `activeRunning`、running、完成未读、少量最近完成、queued/runnable、activity、commanderConcurrency、execution diagnostics、任务分类和下一步 drill-down 命令。默认行只保留 task id、队列、短 prompt/body 预览和原始字符数；`--limit` 是扫描/分页预算，不是返回几十条肥行的开关，CLI effective limit 安全上限为 100，输出必须用 `filters.requestedLimit`、`filters.effectiveLimit`、`filters.limitCapped`、`source.requestedLimit` 和 `source.effectiveLimit` 区分用户请求、CLI cap 和 overview 源拉取预算；例如 `--limit 260` 应明确显示 requested=260、effective=100、source=200，`running.returned` 只是低噪声返回行数。`show/detail/trace/output/full/read` 放在 section template 中，避免每条任务重复刷屏，需要更多内容再按 taskId 展开。刚执行 `codex submit` 后也可以先读 submit 返回的 `submitted.taskStates[]`、`queue.countContext`、`queue.activity.effectiveActiveTaskCount` 和 `queue.stateDisclosure`；若某个 id preview 有 `idsUnavailable=true`，不要把它当成空队列，按 `queue.listPreviewPolicy.rawCommand` 或本 supervisor 命令继续查。
+- `bun scripts/cli.ts codex tasks --view supervisor --limit N`：查看旧 Code Queue 历史默认低噪声监督视图，包括 `activeRunning`、running、完成未读、少量最近完成、queued/runnable、activity、commanderConcurrency、execution diagnostics、任务分类和下一步 drill-down 命令。默认行只保留 task id、队列、短 prompt/body 预览和原始字符数；`--limit` 是扫描/分页预算，不是返回几十条肥行的开关，CLI effective limit 安全上限为 100，输出必须用 `filters.requestedLimit`、`filters.effectiveLimit`、`filters.limitCapped`、`source.requestedLimit` 和 `source.effectiveLimit` 区分用户请求、CLI cap 和 overview 源拉取预算。新任务派发和 follow-up 不再使用旧 `codex submit/resume/steer`，统一走 AgentRun Queue/Sessions。
 - `bun scripts/cli.ts codex queues`：默认是 commander-first 队列态势摘要，`--commander` 是显式同义开关。输出前部固定使用 `.data.queues.commander`，先给出 `activeRunnerCount`、`source`、`target=15`、`slotDeficit`、`queuedCount`、`runningTasks`、`heartbeat.fresh`、`heartbeat.risk`、`heartbeat.staleRecoveryCandidates`、active/runnable queue 小页和 drill-down 命令；历史 queue item 列表保留在 `.data.queues.items[]`，但只是分页的次要行。需要完整队列行视图时加 `--full`，但 `--full` 仍默认分页，继续用 `--limit N`、`--page N` 或 `--offset N` 渐进展开。summary 和 full 都使用稳定 JSON path `.data.queues.items[]` 读取队列行，并从 `.data.queues.commander`、`.data.queues.commanderConcurrency`、`.data.queues.activity`、`.data.queues.counts` 与 `.data.queues.executionDiagnostics` 读取全局活跃计数和执行诊断；完整 upstream 只通过输出中的 raw command 显式获取。若 `/api/queues` 没有返回 task row，`runningTasks.items[].name` 会是 `null` 且 `nameSource=not-returned-by-api-queues`，此时按返回的 `codex task <taskId>` 或 supervisor 命令展开，不要假设任务没有名称。
-- `bun scripts/cli.ts codex execution-plane [--full|--raw]`：只读巡检 D601 原生 k3s `unidesk` namespace 下的正式执行面。该命令的 live collector 必须通过 UniDesk `tran`/`ssh` 维护桥访问 `D601:k3s` 和 `D601:/home/ubuntu/cq-deploy`，不得在 master server 本地调用 `kubectl`、读取本地 worktree 或把 master server 的工具缺失误报成 D601 阻塞。该命令强制使用 `KUBECONFIG=/etc/rancher/k3s/k3s.yaml` 并确认 node `d601`，默认低噪声返回 `summary.formalExecutionPlane`、`summary.deploymentDrift`、`summary.deprecatedComposeResidual`、`executionPlane.deployments[]`、`drift.status` 和 `residual.status`。它比较三类 Deployment：`code-queue` 必须是 scheduler，`code-queue-read` 必须是 read，`code-queue-write` 必须是 write；同时比较 deployment env/annotation commit、Pod `imageID` digest 和宿主 `/home/ubuntu/cq-deploy` HEAD。任何 commit/digest/worktree 不一致或缺少可比 marker 都必须输出 `deployment-drift`，不能写成 healthy。检测到 D601 上旧 Docker Compose `code-queue-backend` 或旧 `127.0.0.1:4222` 监听时必须输出 `deprecated-compose-residual`。该命令不再把 `/api/judge/probe` 或 behaviorVersion 作为门禁；Code Queue runner 能力必须用真实 `codex submit`/任务审阅和人工交互命令在目标运行面闭环验收。默认不打印完整 Kubernetes Deployment JSON、环境变量全集、SecretRef 值或命令 stdout；需要逐项展开时使用 `--full`，需要安全裁剪后的原始观察对象时使用 `--raw`。
+- `bun scripts/cli.ts codex execution-plane [--full|--raw]`：只读巡检 D601 原生 k3s `unidesk` namespace 下的旧 Code Queue 执行面。该命令用于历史归档和残留任务诊断，不作为新任务能力门禁；新任务真实运行面验收走 AgentRun `v0.1` queue/session 原入口。默认不打印完整 Kubernetes Deployment JSON、环境变量全集、SecretRef 值或命令 stdout；需要逐项展开时使用 `--full`，需要安全裁剪后的原始观察对象时使用 `--raw`。
 - `bun scripts/cli.ts codex unread --limit N`：查看完成未读审阅积压的默认 triage，按 repo、issue、status 和 queue 汇总，并给出有界最新任务紧凑行；默认行只包含 task id、状态、queue、issues、updatedAt/finishedAt 和一条 `nextStep`，不重复每任务 `show/detail/trace/output/read` 命令，也不输出 raw prompt、final response、trace 或 output。完整 per-task 命令必须显式使用 `codex unread --full`、`codex unread --view full`、`codex unread list` 或单任务 `codex task <taskId>`/`codex read <taskId>` 展开；默认输出必须保留一次性的模板命令和分页命令。
 - `bun scripts/cli.ts codex unread mark-read --repo owner/name --issue N --limit N --confirm`：批量已读入口，必须显式 `mark-read` 和 `--confirm`，否则结构化失败且不 POST `/read`。
 - `bun scripts/cli.ts codex tasks --unread --limit N`：兼容查看完成未读审阅积压；`--unread` 与 `--unread-only` 等价，不能被静默忽略。
 - `bun scripts/cli.ts codex tasks --status succeeded --unread --limit N`：按具体终态过滤监督结果；不支持的 status filter 必须显式失败，不能扩大为未过滤结果。
 - `bun scripts/cli.ts codex task <taskId>`：默认只查看原始 prompt、最终 response、最后错误和 drill-down 命令，这是完成未读任务审阅的第一步。
 - 当默认审阅摘要不足时，再逐级使用 `bun scripts/cli.ts codex task <taskId> --detail`、`bun scripts/cli.ts codex task <taskId> --trace --limit N` 或 `codex output`。
-- `bun scripts/cli.ts codex resume <taskId> --prompt-file <path>`：对已终态或 awaiting-closeout 的原 task 追加后续修正 turn，适合 PR 小修、冲突、rebase、补测和 review 修正；running/judging task 改用 `codex steer`。
+- `bun scripts/cli.ts agentrun v01 sessions steer <sessionId> --prompt-file <path>`：对 AgentRun 中仍可继续的 session 追加修正；旧 `codex resume` 已冻结。
 - 当 master 控制面状态和 D601 scheduler 状态看起来分裂时，使用 `docs/reference/observability.md` 中的活性规则判断。
 
 默认 commander/supervisor 视图必须保持低噪声。commander 视图用于回答“现在需要处理什么”，supervisor 视图用于看分区小页和红线细节。commander 的 `activeRunners.count` 是指挥官 active runner 计数，supervisor 的 `activeRunning.count` 是 running+judging 状态计数；两者都必须标明 exact/source，不能把返回行数当成并发总数。`activeRunning.count` 来源是 queue summary 的 status counts 时 `activeRunning.exact=true`，用于 redline 判断；`activeRunning.rowPage.returned` / `running.returned` 只表示本次返回的紧凑任务行。`activeRunning.redline` 必须写明 `countField`、routine target、burst redline、hard redline、`state` 和 `decisionReady`；只有 `decisionReady=true` 时，才能直接用该 count 做红线/补派判断。commander 的 `attention.items` 只返回最需要处理的有界任务，`attention.total/returned/omitted` 必须保留省略计数；`sections.recentCompleted` 不得重复 `sections.terminalUnread` 的未读终态。`running`、`completedUnread` 和 `queued` 即使传入较大的 `--limit`，默认也只返回一个很小的有界页，并通过 section `commands.next` 继续分页；`--limit` 保留为扫描/分页预算和 full view 返回预算，不得让一次 commander/supervisor 调用输出几十条肥行。每个任务行只应带 task id 和必要摘要，`show`、`detail`、`trace`、`output`、`full`、`read` 使用 section template 或 row commands 表达，让下一步渐进披露动作明确且不重复；默认不得嵌入完整 queue 列表、完整 final response、raw output 页或完整 trace 行。`recentCompleted` 必须默认限量，且不得重复 `completedUnread` 里的未读终态，避免完成历史把当前 running、阻塞和未读审阅挤出视野；需要完整当前页时显式使用 `--view full`。`executionDiagnostics` 只能展示有界 task-id/reason 预览、总数、截断标记和 omitted counts；需要全量诊断时使用输出中的 raw command。`commands.read` 只是在人工审阅后的建议命令，listing 命令绝不能自动执行。
@@ -312,7 +312,7 @@ commander 视图的任务分类必须是确定性字段，至少区分 `user-fac
 
 队列诊断中的 `split-brain` 表示控制面/执行面观测分裂，不自动证明任务已经死亡。只要任务 heartbeat 还在刷新、trace 仍在推进，就不能把它判成服务中断或要求立刻 stop；应把它视为 `splitBrainLive=true` 的 live 任务，继续监督并推进 #20 里的已排任务，而不是 interrupt、替换或把 backend 当成已经挂掉。队列摘要应显示 `effectiveLiveness=live`、`splitBrainLive=true` 和 `recommendedAction=continue-supervision`；compact 输出还应在 `executionDiagnostics.liveness` 中重复这些低噪声字段，并突出 `activeHeartbeatCount`、有界 `heartbeatFreshTaskIds`、`databaseActiveTaskCount` 和 `schedulerActiveRunSlotCount`。当 master/control-plane 的 `schedulerActiveRunSlotCount=0` 但 `heartbeatFreshTaskIds` 非空时，active 数应优先按 scheduler heartbeat 摘要解释为 live，而不是按 master 本地 slot 0 解释为执行停摆。只有 heartbeat expired/missing 或满足 stale-recovery 条件时，才应显示 `effectiveLiveness=at-risk` 并进入恢复判断。
 
-`codex submit` 成功后的 `queue` 是 submit-confirmation 即时 bounded snapshot，不是恢复判据。它必须同时区分 `submitted.taskStates[]` 中本次提交任务的 queued/running 状态、`queue.countContext.databaseActive` / `activity.databaseActiveTaskCount` 中 PostgreSQL active running、`activity.schedulerHeartbeatFreshness` 中 scheduler heartbeat freshness，以及 `activity.recovery` 中的 transient risk。若同一个提交回显里出现 `counts.running>0`、`queued>0`、`heartbeatRiskTaskCount>0` 或 `staleRecoveryCandidateTaskCount>0`，但 `lastObservedAgentEventAt` 明显早于 submit time 或还没有下一次 supervisor poll 确认，输出应保留候选可见性并给出 `re-poll supervisor before recovery`；这类单次 bounded snapshot 只能设置 `attentionRequired=true`，不得把 `commanderConcurrency.interventionRequired` 直接升级为高风险恢复。默认 drill-down 是重新运行 `codex tasks --view supervisor --limit 20` 或 raw overview，而不是 restart、cancel、interrupt 或 DB write。
+旧 Code Queue 的 bounded snapshot 只作为历史监督证据，不再作为新派单或恢复判据。新任务派发后应通过 `bun scripts/cli.ts agentrun v01 queue commander --reader-id <id>`、`queue show`、`sessions trace` 和 `sessions output` 观察 AgentRun 队列与 session。
 
 默认 supervisor poll 也遵循同一低噪声语义：heartbeat expired/missing、`heartbeatRiskTaskIds` 和 `staleRecoveryCandidateTaskIds` 必须可见，但第一次 poll 只表示 `transient-needs-repoll`，`activity.recovery.hint` 应为 `re-poll supervisor before recovery`。只有 repeated poll 仍确认 owner heartbeat expired、scheduler local no active run、database-active task 仍存在，并且输出显式带 `repeatedPollConfirmed=true` 或 confirmed stale candidate，才允许进入 bounded dry-run reconcile；真实恢复仍受高风险边界约束。
 
@@ -356,7 +356,7 @@ D601 artifact registry 的 systemd unit inactive 不等于 D601 全局离线。
 
 每次新增 Code Queue 任务、补发 follow-up task，或处理一批完成未读任务后，都必须同步更新 GitHub 总看板 issue `#20` 的正文主表；如果发生实质态势变化，还要同步更新指挥简报 issue `#24` 的正文。看板更新应反映当前任务分布、关键 blocker 和粗略进度，不要只改聊天上下文或只改单个 issue，而让总态势图落后于实际调度状态。
 
-成本路由接入 #20 看板时，#20 的每个 Code Queue 任务行都应显式保留推荐或实际 runner/model、风险等级、验证证据和审阅状态。推荐列的语义只来自指挥官判断或 `codex submit --dry-run` 的 `routingRecommendation`，不能来自 worker 自评。MiniMax 和 DeepSeek 任务在 #20 中必须先保持“待指挥官审阅”状态；只有指挥官核验 diff、commit、轻量验证和未越界后，才更新为已验收并执行 `codex read <taskId>`。若 dry-run 给出 `commander-human-only` 或 GPT-5.5 recommendation，#20 不应把该任务降级给 MiniMax/DeepSeek；若必须降级，必须在看板 progress 中写明人工接受的风险和额外审阅动作。
+成本路由接入 #20 看板时，#20 的每个 AgentRun/历史 Code Queue 任务行都应显式保留推荐或实际 runner/model、风险等级、验证证据和审阅状态。推荐列的语义来自指挥官判断或 AgentRun queue payload 审查，不能来自 worker 自评。MiniMax 和 DeepSeek 任务在 #20 中必须先保持“待指挥官审阅”状态；只有指挥官核验 diff、commit、轻量验证和未越界后，才更新为已验收并执行对应的 AgentRun/历史 read 标记。
 
 ## 指挥工作流
 
@@ -376,10 +376,10 @@ D601 artifact registry 的 systemd unit inactive 不等于 D601 全局离线。
 只有存在明确理由时才干预。
 
 - 如果任务还在运行且 trace 或 scheduler heartbeat 新鲜，应引导而不是 interrupt。
-- 对运行中任务的引导应优先使用正式 CLI：`bun scripts/cli.ts codex steer <taskId> --prompt-file <path>`。该命令和 `codex task/tasks/read` 复用同一个 backend-core stable proxy helper；`--dry-run` 会显示 `method/path/stableProxyPath`、`steerId`、retry policy、prompt 摘要、`commands.traceConfirm` 和 raw proxy 等价命令但不发送。非 dry-run 默认对 `stable-proxy-failed` 和 `backend-core-unreachable` 做一次有界重试，且每次 retry 都复用同一个 `steerId`；后端按同 `steerId`+同 prompt 抑制重复 trace 注入，返回 `duplicateSuppressed=true`，同 `steerId` 搭配不同 prompt 返回 conflict。
+- 对 AgentRun 运行中 session 的引导应优先使用正式 CLI：`bun scripts/cli.ts agentrun v01 sessions steer <sessionId> --prompt-file <path>`，再用 `sessions trace/output/read` 确认。旧 `codex steer` 已冻结，只保留历史 trace confirmation 查询。
 - 真实 steer 输出必须保持低噪声：成功显示 `steer.status`、`steer.deliveryState`、`steer.steerId`、有界 `traceConfirmation` 和后续命令，不回显 prompt 或完整 task state；失败默认不带 request body、不带 upstream body preview，也不带 raw response，需要上游预览或原始失败对象时显式重跑 `--full` 或 `--raw`。`deliveryState=accepted` 表示 backend 已接受；`not_accepted` 表示任务状态/权限/输入未接受；`accepted_response_timeout` 表示 stable proxy 响应超时但 trace confirmation 找到该 `steerId`；`unknown` 表示响应路径失败且确认查询仍未证明接受。
-- `502 provider HTTP tunnel failed`、`The operation was aborted`、约 30 秒 provider tunnel wait abort 仍失败时，先看 `.data.diagnostics.reason`、`.data.diagnostics.attempts`、`.data.traceConfirmation` 和 `.data.commands.traceConfirm`。若 `.data.steer.deliveryUnconfirmed=true`，不要立刻复制同一纠偏 prompt 再发；先运行 `bun scripts/cli.ts codex steer-confirm <taskId> --steer-id <id>`。如果确认 accepted 或 accepted_response_timeout，停止重发并继续观察 `codex task <taskId>` / `codex task <taskId> --trace --tail --limit 80`；如果仍 unknown，再用输出中的 retry 命令复用同一个 `--steer-id`。raw proxy 等价命令走同一条 tunnel，`rawProxyEquivalentIsFallback=false`，只能做诊断对照，不应作为正式 fallback。
-- 失败分流仍以 `.data.diagnostics.reason` 为准：`backend-core-unreachable` 属于本机到 core 的观察路径，`code-queue-microservice-unregistered`/`proxy-unauthorized`/`proxy-404` 属于 stable proxy 配置或权限，`steer-endpoint-404`/`upstream-runtime-rejected` 属于 D601 runtime 或任务状态，`stable-proxy-failed` 多为 provider/k3s/tunnel 链路问题。若任务已终态，CLI 返回紧凑 `task-already-terminal` 响应并给出 `bun scripts/cli.ts codex task <taskId>`、`bun scripts/cli.ts codex read <taskId>` 和 `bun scripts/cli.ts codex submit --prompt-file <path> --reference-task-id <taskId>`；指挥官应提交 follow-up task，而不是继续 steer 终态任务。若正式 CLI 自身不可用，临时通过受控 microservice proxy 调用只能作为现场恢复手段；这类绕行必须记录到指挥简报 issue #24 主体的常驻观察，并创建正式 issue 补齐 CLI 能力，避免长期依赖隐式 API。
+- 旧 Code Queue 的 provider tunnel 失败只作为历史运行面诊断线索；新任务控制面失败优先按 AgentRun `queue show`、`sessions trace/output`、G14 `agentrun-v01` manager 和 runner job 证据分流。
+- 新 AgentRun 任务失败分流以 AgentRun queue/session/runner-job 返回字段为准。旧 Code Queue `.data.diagnostics.reason` 只用于历史任务和残留运行面，不再引导新 `codex submit/steer/resume`。
 - 如果任务进入终态但缺少必要验收证据，应使用聚焦 continuation prompt retry 同一任务。
 - 如果任务被可复用基础设施缺陷阻塞，应把该缺陷分配给合适的空闲或低风险队列，让原业务任务等待，或在修复后 retry。
 - 如果基础设施缺陷影响 Code Queue 控制面可用性，指挥官可以执行恢复队列所需的最小受控部署，然后验证原任务能继续。