pikasTech-unidesk/docs/report/202605/20260520_Commander.md

2026-05-20 指挥简报

范围

本文是 Code Queue 指挥官针对 GitHub issue #9、#12、#13、#14、#15、#16 的过程恢复记录。目标是在上下文压缩或指挥交接后，能快速恢复当前态势。

当前生效的指挥规则：

• 指挥官仓库固定使用 /root/unidesk 的最新 master，不得为指挥工作创建 worktree。
• 仍有未完成任务时，约每 5 分钟轮询一次。
• 每轮轮询后视情况追加简报；只有活跃/排队/完成未读、相关 commit、阻塞点或下一步发生变化时才追加。
• 完成未读任务必须先审阅，再标记已读。
• 不在 master server 上跑重型 check、全量 e2e 或 Playwright。
• backend-core 和 D601 Code Queue 的生产变更默认只在 dev 验证，除非用户明确批准。
• 简报和长期参考文档使用中文。

快照 2026-05-20 04:16 UTC

仓库状态：

• 指挥官 worktree：/root/unidesk
• origin/master：3a5d60140044（fix: read k3s artifact labels via root ctr）
• 写入本简报前，指挥官 worktree 除新简报文件外无其它变更。

队列状态：

• 运行中：2
  • codex_1779247780398_1，队列 code-queue：#12 后端/API trace 与 STEP 合同。
  • codex_1779247828759_1，队列 frontend：#12 前端与 dev/prod 部署验证。
• 排队中：4
  • codex_1779248021103_1：#13 后端/API stats。
  • codex_1779248492207_1：#15 PR 支持。
  • codex_1779248052767_1：#13 前端 stats。
  • codex_1779248189933_1：#14 split-brain UI。
• 完成未读：1
  • codex_1779248781778_1，队列 infra：#16 CLI 渐进式披露和 skill 注入。

诊断：

• Code Queue 仍报告 live split-brain：PostgreSQL 中存在 active task，但本地 scheduler active slot 为空；同时 scheduler heartbeat 新鲜。
• 当前推荐动作仍是 continue-supervision，不是 stale recovery。

Issue 状态

• #12：两条 lane 仍在执行。前端 lane 已经推送并部署过 dev frontend health commit，随后修复了通过 root ctr 读取 k3s artifact label 的问题。后端 lane 仍在收口 API/data contract 和类型验证。
• #13：排在 #12 后面。
• #14：排在 frontend lane 后面。
• #15：排在 code-queue lane 后面。
• #16：Code Queue 终态为 succeeded，但指挥官审阅发现发布风险。

审阅记录

#16 的 Code Queue final response 声称提交了 commit ed6f8a0586c0423eca4f3763fe0cf4ebd25ab0f6，提交信息为 feat: tighten code queue supervision cli。

指挥官在 04:16 UTC 的验证结果：

• origin/master 仍是 3a5d6014004412d08efe3b83f5b7c7201ec4633c。
• 在指挥官仓库中执行 git cat-file -t ed6f8a0586c0423eca4f3763fe0cf4ebd25ab0f6 没有找到对象。
• worker 路径 /workspace/unidesk/.worktrees/codequeue-16 在指挥官机器上不可见。

判断：

• 暂不将 #16 标记已读。
• #16 功能方向看起来有价值，但在 commit 能从 origin/master 获取，或 worker 解释 final response 中 commit 不可见的原因之前，不能验收。

下一步

• 持续轮询 #12 后端和前端两条运行 lane。
• 继续审阅 #16，必要时派一个 follow-up Code Queue 任务恢复/推送缺失 commit，或将发布失败写入 issue。
• #12 lane 完成后先审阅，再决定是否接受 #13/#14/#15 后续任务结论。
• 后续轮询如果态势变化，继续向本文追加简报。

更新 2026-05-20 04:20 UTC

已检查 #16 commit ed6f8a0586c0423eca4f3763fe0cf4ebd25ab0f6 是否推到了其它分支，包括 release/v1。

结果：

• origin/master：3a5d60140044
• origin/release/v1：0cf73d817f14
• git branch -r --contains ed6f8a0586c0423eca4f3763fe0cf4ebd25ab0f6：无结果。
• git tag --contains ed6f8a0586c0423eca4f3763fe0cf4ebd25ab0f6：无结果。
• git log --all --grep='tighten code queue supervision cli'：无结果。

结论：

• #16 仍不能验收/标记已读。final response 引用的 commit 当前不在已拉取的任何远端 ref 中。
• 下一步继续使用 Code Queue 指挥机制，而不是指挥官本地接手实现：派 follow-up queue task 恢复/推送缺失 commit，或记录 #16 发布失败。

不符合预期的 Code Queue 行为：

• 任务进入 succeeded 且 judge 为 complete，但其声明的 commit 不能从任何远端分支拉取。
• 这是指挥官可见的验收缺陷：任务“完成”不能等同于“交付完成”，Git 远端 source-of-truth 缺失时不能接受。

长期化建议：

• 为 Git-backed delivery task 增加 Code Queue 完成后验收门禁：
  • 从 worker final response 或结构化元数据解析目标分支和 commit；
  • 对 origin/<target-branch> 执行 git ls-remote / fetch 校验；
  • commit 远端不可见时，任务应标记为 succeeded_unverified，或至少暴露明确验收告警；
  • 在指挥官接受或派出恢复任务之前，保持未读。
• worker prompt 和 final response 必须包含目标分支、推送 commit、远端可见性证据。

指挥规则新增 2026-05-20 04:22 UTC

以后每个 Code Queue 派发任务都必须显式写明目标线：

• master：用于主动开发和集成线。
• release/v1：仅用于明确批准的稳定维护修复。

worker prompt 必须包含目标分支，final response 必须报告：

• 实际推送的分支；
• 远端 commit hash；
• 该 commit 是否可从 origin/<target-branch> 获取。

“push to master” 或 “push current branch” 这类含糊说法不再满足指挥官派单要求。