docs: allow direct reference doc updates

2026-06-13 11:06:22 +00:00
parent 04020af4d4
commit 3d47a86cbf
3 changed files with 9 additions and 6 deletions
@@ -165,7 +165,7 @@ GitHub issue 是长期需求、缺陷、阻塞和决策的 source of record。

 issue 内容必须自包含，至少写清楚背景、外部收益、当前观察、需求范围、非目标、验收标准和关联任务。不要只贴聊天摘要或只写“见某任务”；Code Queue worker 可能看不到 issue，也可能无法访问完整历史，因此 issue 是人类和指挥官恢复全局态势的记录，不是 worker prompt 的替代品。

-长任务和跨回合排障应把专题 issue 的评论区作为进展锚点。调查结论、细化方案、阶段性修复、rollout 状态、阻塞原因、复测 trace、最终验收和后续风险都应追加到同一个专题 issue 评论中，并引用相关 PR、commit、job、trace 或 runtime revision；正文只保留稳定背景、范围、验收标准和当前摘要，不写成每一步流水账。上下文压缩、切换指挥官或恢复中断后，先读取专题 issue 最新评论，再继续执行，避免只依赖聊天记忆或本地临时文件。写评论必须使用 `bun scripts/cli.ts gh issue comment create ... --body-file <file|->`，长正文不得用 shell 参数拼接。
+长任务和跨回合排障应把专题 issue 的评论区作为进展锚点。调查结论、细化方案、阶段性修复、rollout 状态、阻塞原因、复测 trace、最终验收和后续风险都应追加到同一个专题 issue 评论中，并引用相关 PR、commit、job、trace 或 runtime revision；正文只保留稳定背景、范围、验收标准和当前摘要，不写成每一步流水账。每次从上下文压缩、切换指挥官、resume 或中断恢复后，都必须先读取专题 issue 最新评论；只要任务已有或应有专题 issue，继续任何实质操作前还必须先写一条“恢复锚点”评论，说明当前北京时间、已完成内容、当前运行 / PR / commit / PipelineRun、剩余下一步和阻塞点。即使压缩摘要看起来完整、状态未变化或 agent session memory 可用，也不得跳过恢复锚点评论。写评论必须使用 `bun scripts/cli.ts gh issue comment create ... --body-file <file|->`，长正文不得用 shell 参数拼接。

 如果某个 worker 任务需要依赖 GitHub issue 内容，但 runner 的 issue 可达性尚未被单独验证，指挥官不能默认 worker 已能读取该 issue。此时 worker prompt 必须直接内嵌完整需求、约束和验收点，issue URL 只能作为辅助引用。若要把 issue 作为任务输入源，先单独做可达性探测，再决定是否把 issue 作为常规前置条件。