GitHub App 代码审查
配置 OriginAI GitHub App，依据 Pull Request 声称实现的发布需求，严格审查工程代码是否缺漏、多余或冲突。
OriginAI GitHub App 能够精准提取 Pull Request（PR）所声称实现的规格版本差异，并据此深度审查工程代码的实现质量。它的核心审查逻辑始终聚焦于一个根本性问题：当前 PR 的代码变更，是否准确、完整且不多不少地实现了已发布的需求规格？
- 缺漏（Missing）：需求规格中已明确定义的功能项或状态，在工程代码中未找到对应实现。
- 多余（Extra）：工程代码中引入了超出需求范围的用户可见行为或未经确认的冗余逻辑。
- 冲突（Wrong）：代码中的实现行为与已发布的规格规则产生实质性矛盾。
审查结论将以 Check Run 形式挂载在 PR 上。更重要的是：当审查发现并非代码写错、而是产品规格本身需要更新补充时，App 会在 OriginAI 中暂存一份变更请求供人类审阅确认，绝不会直接覆写动态工作区。
审查触发机制与执行策略
GitHub App 严格以代码仓库中 .origin.json 配置的 release_hash 为基线——该哈希指向当前仓库已完全对齐的最近一次已发布 Release 快照。
| 触发场景 | 具体执行行为 |
|---|---|
| PR 创建、重新打开或推送新 Commit | 仅当该 PR 修改了 .origin.json 中的 release_hash（表明声明对齐新规格）时才执行审查；普通纯业务代码提交会自动跳过。 |
在 PR 评论中回复 @originai-review | 强制执行全量审查（支持 GitHub 原生的 @ 用户名补全）。此时因无新增需求变更，App 将重点排查代码中的“多余”与“冲突”项。兼容旧版 @originai review 指令。 |
在 PR 评论中回复 @originai-review <hash> | 即使本地 .origin.json 尚未推进，App 也会直接对照指定的 Release 哈希开展审查。极为契合刚刚发布新规格后立即验证 PR 的场景。 |
所有处于草稿态（Draft）的 PR 在被标记为 Ready for review 之前，均会自动跳过审查。
审查结论以名为 originai / spec-review 的 Check Run 形式呈现。App 本身绝不会在 PR 讨论流中刷屏发布嘈杂的长评论。当审查完全通过时状态为 success；当发现潜在分歧时，Findings 将以**信息性中立通知（neutral）**方式给出——Check 不会直接标记为失败，因而在 CI 规则中不会粗暴阻断 PR 合并。团队可以根据 Check 报告中清晰标注的严重级别（阻断 Blocker / 严重 Major / 次要 Minor）自主决定是否合入。
若本地 .origin.json 中配置了 proposal_id（通常通过执行 npx originai get-proposal-diff <id> --bind 注入），App 会精准对比该变更请求所建议的文件树与基准 Release 的差异，对照审查代码。同一份 PR 中关于规格层面的修订发现，会自动汇聚并暂存为一条来源标记为 GitHub 的变更请求。
配置与安装指引
- 在 GitHub 目标组织或代码仓库中安装官方 GitHub App。安装完成后，GitHub 会自动重定向至 App 的设置引导页面（Setup Page）。
- 在设置页面中填入由控制台生成的 OriginAI 个人访问令牌。仅需配置只读权限令牌即可满足诉求——该令牌具备拉取已发布 Release 与暂存变更请求的权限，但无法直接批准应用。令牌经强加密后与当前安装实例安全绑定。
- 确保本地仓库已完成关联初始化：
npx originai login
npx originai link首次完成此配置的 OriginAI 账户将成为该 GitHub 安装实例的默认管理所有者。后续若需重新绑定或轮换，必须使用归属于同一个 OriginAI 工作区的有效令牌进行操作。
产研审查闭环流程
发布需求规格 → PR 推进 release_hash → GitHub App 触发审查
├─ 完全通过 (Success) → 批准合并代码
└─ 发现差异 (Findings) → 针对性修复后重新触发根据审查报告指出的问题根源，选择对应的闭环路径：
- 若属于代码实现有误：在代码库中修复并推送最新提交。新的 Commit 会自动唤醒重跑审查。
- 若属于产品规格有待校准：在 OriginAI 工作台中打开由 App 暂存的变更请求，确认应用并发布新的 Release 版本，随后在 PR 评论区回复
@originai-review <全新版本哈希>再次触发验证。审查通过后，在本地终端执行npx originai sync提交最新的同步指针。
GitHub App 严格秉承只读原则，绝不会擅自向你的 Git 分支推送任何代码提交；推进 release_hash 的提交动作始终由人类或团队的受控工作流主导。
已知约束与设计边界
- 现阶段仅支持识别并解析位于代码仓库根目录的单个
.origin.json文件；单代码仓库（Monorepo）内挂载多个独立规格项目的场景尚在演进中。 - 超大规模的特大 Diff PR 在进入模型审查前会进行必要的分块截断，并在 Check 摘要中予以显式告知。
- 审查引擎主要基于当前 PR 的 Diff 代码展开推演，而非全库静态深度扫描；当某些代码行为深度依赖外部既有模块而上下文不足时，审查偏向保守，避免造成过度误报。