docs: move commander report to issue

2026-05-20 08:04:43 +00:00
parent fee1b1b710
commit f0728c6c84
2 changed files with 3 additions and 382 deletions
@@ -43,7 +43,7 @@

 ## GitHub Issue 和 PR 使用

-GitHub issue 是长期需求、缺陷、阻塞和决策的 source of record。聊天上下文、Code Queue final response 和过程简报可以帮助恢复现场，但不能替代 issue 中的可检索记录。
+GitHub issue 是长期需求、缺陷、阻塞和决策的 source of record。聊天上下文、Code Queue final response 和指挥简报可以帮助恢复现场，但不能替代 issue 中的可检索记录。指挥简报自身也按 issue 主体维护，当前入口是 GitHub issue #24；后续只更新 #24 正文，不在评论区追加，且所有时间统一使用北京时间。

 指挥官应在以下情况创建或更新 GitHub issue：

@@ -89,7 +89,7 @@ PR 支持本身是 Code Queue 能力的一部分。实现前，指挥官可以

 禁止在检查前用批量 read 动作清空完成未读任务。每个完成任务必须先单独审阅，再用 `bun scripts/cli.ts codex read <taskId>` 单独标记已读，使未读状态继续代表“仍需审阅”。

-每次新增 Code Queue 任务、补发 follow-up task，或处理一批完成未读任务后，都必须同步更新 GitHub 总看板 issue `#20` 的正文主表。看板更新应反映当前任务分布、关键 blocker 和粗略进度，不要只改聊天上下文或只改单个 issue，而让总态势图落后于实际调度状态。
+每次新增 Code Queue 任务、补发 follow-up task，或处理一批完成未读任务后，都必须同步更新 GitHub 总看板 issue `#20` 的正文主表；如果发生实质态势变化，还要同步更新指挥简报 issue `#24` 的正文。看板更新应反映当前任务分布、关键 blocker 和粗略进度，不要只改聊天上下文或只改单个 issue，而让总态势图落后于实际调度状态。

 ## 指挥工作流

@@ -109,7 +109,7 @@ PR 支持本身是 Code Queue 能力的一部分。实现前，指挥官可以
 只有存在明确理由时才干预。

 - 如果任务还在运行且 trace 或 scheduler heartbeat 新鲜，应引导而不是 interrupt。
- 对运行中任务的引导应优先使用正式 CLI。若源码或 runtime 已有 `steer` 能力但 CLI 尚未暴露，临时通过受控 microservice proxy 调用可以作为现场恢复手段；这类临时绕行必须记录到指挥简报头部的常驻观察，并创建正式 issue 补齐 CLI 能力，避免长期依赖隐式 API。
+- 对运行中任务的引导应优先使用正式 CLI。若源码或 runtime 已有 `steer` 能力但 CLI 尚未暴露，临时通过受控 microservice proxy 调用可以作为现场恢复手段；这类临时绕行必须记录到指挥简报 issue #24 主体的常驻观察，并创建正式 issue 补齐 CLI 能力，避免长期依赖隐式 API。
 - 如果任务进入终态但缺少必要验收证据，应使用聚焦 continuation prompt retry 同一任务。
 - 如果任务被可复用基础设施缺陷阻塞，应把该缺陷分配给合适的空闲或低风险队列，让原业务任务等待，或在修复后 retry。
 - 如果基础设施缺陷影响 Code Queue 控制面可用性，指挥官可以执行恢复队列所需的最小受控部署，然后验证原任务能继续。