diff --git a/docs/report/202605/20260520_Commander.md b/docs/report/202605/20260520_Commander.md
index f88dc029..cf97a12f 100644
--- a/docs/report/202605/20260520_Commander.md
+++ b/docs/report/202605/20260520_Commander.md
@@ -319,3 +319,61 @@ worker prompt 必须包含目标分支，final response 必须报告：
 - 需要显式验证 gh 工具、认证和可见性边界。
 
 同时也补了长期监督规范：当 worker 任务依赖 issue 内容而 runner 还没验证可达性时，prompt 必须自包含，issue 只能当辅助引用。后续若要把 issue 当成常规输入源，必须先单独做可达性探测。
+
+## 更新 2026-05-20 07:30 UTC
+
+本轮围绕总看板 #20 做了收口和纠偏：
+
+- #4、#6、#7 已按“评审/决策/报告职责完成”关闭，并从 #20 的 OPEN 表移入 CLOSED 表。
+- #14、#16、#18 的完成未读任务已在上一轮审阅、标记已读并关闭对应 issue，本轮继续把它们保留在 #20 CLOSED 表作为基线。
+- 新建 #21：`Code Queue runner 启动环境缺失 codex：posix_spawn 失败导致新任务无法开始`，并补入 #20 OPEN 表。
+
+当前 Code Queue 态势：
+
+- #12 后端/API 任务 `codex_1779247780398_1` 仍处于运行态，但已经给出实质成果：commit `93e4630497334054fb85dd5a5a46678b08580eec` 修复 Trace/STEP 合同，并完成 direct recreate 与 live API 验证。因为任务尚未终态，指挥官暂不标记已读，也暂不关闭 #12。
+- #13 任务 `codex_1779248021103_1` 尚未进入业务修复，attempt 多次在 app-server 启动前失败，错误为 `posix_spawn 'codex'` / `ENOENT`。这不是统计曲线业务根因，已拆到 #21。
+- #15、#17 仍在队列中，后续会受到同一 `codex` runtime 问题影响，暂不继续增加同类任务压力。
+
+现场诊断：
+
+- D601 host 的 ubuntu 用户路径原本没有 `codex`，`command -v codex` 为空。
+- `code-queue-backend` 容器内存在 `/usr/local/bin/codex`，版本为 `codex-cli 0.128.0`。
+- 因此判断为 runner app-server spawn 的真实执行环境与容器工具链边界不一致：容器内有 `codex`，但当前任务的 `cwd=/home/ubuntu` 和 spawn 环境找不到 `codex`。
+- 已做最小临时恢复：在 D601 ubuntu 用户路径安装 `@openai/codex@0.128.0`，当前 `command -v codex` 返回 `/home/ubuntu/.local/bin/codex`，`codex --version` 返回 `codex-cli 0.128.0`。
+
+不符合预期的行为：
+
+- judge 将 `posix_spawn 'codex'` 归类为可重试业务 attempt，导致 #13 在未开始执行的情况下消耗 attempt 并反复 retry。它应该是 infra-blocked/degraded，而不是业务 retry。
+- `codex submit` 当前没有模型或 agent-port 选择参数，指挥官不能把同一任务临时切到 opencode lane 来绕过 `codex` runtime 缺失。
+- `gh issue create --body` 对反引号敏感，直接 shell 拼接会触发命令替换。本轮误触发后产生了空文件 `emptynD601`，已确认是指挥官命令误伤并清理。
+
+长期化建议：
+
+- Code Queue health/diagnostics 应暴露每个 agentPort 的 runtime preflight：实际 spawn PATH、`codex` 路径、版本和 app-server dry-run 结果。
+- runner 缺 runtime 时，应进入明确的 infra-blocked/degraded 状态，不应继续消耗业务 task attempt，也不应让 judge 只给“继续重试业务任务”的提示。
+- 提交 GitHub issue 正文应优先使用 JSON stdin 或 body-file，避免把包含反引号、尖括号或命令片段的正文直接拼到 shell 参数里。
+
+## 更新 2026-05-20 07:35 UTC
+
+临时 `codex` runtime 恢复已被真实任务验证有效：
+
+- #13 任务 `codex_1779248021103_1` 已从 `retry_wait` 进入 attempt10 `running`。
+- 最新 trace 显示 worker 已开始真实读取 `src/components/microservices/code-queue-mgr/src-rs/main.rs`，并判断 Rust `code-queue-mgr` 是实际 Docker 入口，stats endpoint 仍为 `skipped`，这能解释前端统计面板长期 `0 / 暂无统计`。
+- #21 已追加评论，明确这次只是 D601 host 用户级临时恢复，长期仍要补 runtime preflight、持久化安装路径和 infra-blocked 状态。
+
+已处理完成未读：
+
+- `codex_1779247780398_1`（#12 后端/API）已审阅并标记已读。
+- 两个关键提交 `93e4630497334054fb85dd5a5a46678b08580eec` 与 `bd334bab4a525ef24c16846189bb95c82a757c0b` 均已确认是 `origin/master` 祖先。
+- #12 前端 lane 早前已完成 prod 部署，commit `941fa853904a9701cd1a8de2e88ff4e4e035f8e3`。
+
+对 #12 的指挥判断：
+
+- 用户可见的 TraceView / STEP 展示问题已经基本完成：前端已 prod，后端/API 已在 D601 direct runtime 做 live API 验证。
+- 暂不关闭 #12，因为 code-queue/code-queue-mgr 标准 prod artifact CD 仍被 registry manifest 缺口阻塞；该残留应归入 #9 CI/CD 标准化继续收口，而不是把 #12 误判为纯展示 bug 未修。
+- #20 已更新：#12 进度调整为 95%，验收状态为 `DEV、PROD`；#13 调整为 55%；#21 调整为 55%。
+
+下一轮重点：
+
+- 继续监督 #13 attempt10，等待其提交统计 API 修复、回归测试和 DEV/必要 prod 验证。
+- #15、#17 仍在同一 `code-queue` 队列排队，不额外加压，避免再次把刚恢复的 codex lane 打满。