把 GitHub Issue、评审评论和文档 Gate 绑定起来，确保线上协作轨迹可追溯、可审计。
- 一个正式交付流程必须有主 Issue。
- PRD / Tech / QA / Release 的结论必须能在 Issue 中找到。
- 评审评论不是聊天记录替代品，而是 Gate 留痕的一部分。
- 评论只有真正写入目标 Issue 后才算完成，本地草稿、pending 文件或聊天摘要都不算。
- 背景
- 目标
- 当前阶段
- 当前 owner
- 关联文档链接
- 最新 Gate 结论
- 打开的 Todo / blocker
Human Review #1 = 文档 PR 的 Human review / merge decision（不是 Agent 签字节点）
Human Review #2 = 代码 PR 的 Human review / merge decision（不是 Agent 签字节点）
Agent 可在进入 HR 前完成自己的评审与签字，但 HR 本身由 Human 执行。
- PRD Review 结束
- Tech Review 结束
- QA 结论输出
- Release 决策输出
- Major / Breaking 变更发生
- 异常升级或恢复完成
- project_id
- Gate 名称
- 决策人
- 结论
- 证据链接
- 待办与 owner
- 是否允许进入下游阶段
- 当前 Issue 状态
- 禁止只写“LGTM”“通过”“看过了”之类无结构结论
- 禁止评论结论与正式文档状态不一致
- 条件通过必须写清条件和复核人
- 评论中只放结构化结论与链接摘要，不粘贴长篇设计正文
- Agent 默认不自行关闭主 Issue，除非项目策略显式允许
- 只有 Human 可以关闭 Issue；Agent 可以发布"Issue 关闭请求"评论，但必须由 Human 执行关闭
- 自动投递评论失败时，必须把当前动作标记为失败，不能伪装成成功
- PRD / Tech / QA / Release 阶段的正式结论，只有在 Issue Comment 成功落地后才算阶段完成
- 若阶段要求存在 Comment，但目标 Issue 下查不到该 Comment，则视为未完成
- 代码 PR 创建前，应确认上游必需 Comment 已存在
- 代码 PR 合并前，应确认当前阶段 Comment 和产物链接完整
- 文档 PR 合并前，应确认 Human Review #1 结论已落到目标 Issue 或 PR
- 代码 PR 合并前，应确认 Human Review #2 结论已落到目标 Issue 或 PR
- 若当前阶段缺少必需 comment，则该阶段不能视为完成
- 若 comment 字段不完整，则必须补齐后重试
- 若 comment 与 issue / 文档状态不一致，则以更严格状态为准并触发纠正
- 必须指定修复 owner 和重试条件
- 若 comment 自动投递失败，必须返回非成功状态，阻断下游动作
- 若 Human Review 结论未真实落地，则不能把该评审视为已完成
- 开发交付：PRD → Tech → HR#1 → Implementation → QA → HR#2 → Release → Issue Close
- 纯文档交付：PRD → Tech → HR#1 → Release → Issue Close（不走 HR#2 / 代码 PR）
- 两种路径都必须保留完整的 Issue Comment 和产物回链，差异仅在于是否经过代码阶段
- PR 必须回链主 Issue
- 合并前必须确认主 Issue 的阶段状态与 PR 实际内容一致
- 若 PR 引入 Major / Breaking 变更，Issue 必须先完成重审记录
- 若 Issue Comment 缺失，不得把 PR 创建或合并视为合规完成
- 文档 PR 与代码 PR 都必须能从主 Issue 反查