zzz-od-dev-pr-review

name	zzz-od-dev-pr-review
description	当要审查/验证一个 open PR 是否可合并时用。英文 review/verify a PR、check if mergeable、validate PR functionality、PR code review。

PR 审查验证

审查一个 PR 时,按 L0→L4 逐级验证,每级有则记无则跳,最终给"可合并 / 可合并但有建议 / 需返工 / 无法验证(写明缺什么)"结论。 先 L0 分诊(判是否适用)→ 适用 PR 做 L1/L2(总做、不依赖环境)→ 再按 PR 类型决定 L3/L4。 L0 判定 skip 的(前端/CI/纯 git 启动逻辑)不做 L1/L2。游戏流程类 PR,L4 live 是硬性要求(不是可选项)。

0. 准备:分支与基线(每个 PR 必做)

原则:在"PR + 当前 main"的集成结果上审查,不在旧 base 上审。 PR 基于旧 main,旧 base 上审会漏集成问题(API 不兼容、被 main 改过的同文件、依赖 main 新加的文件等)。

• 用提交者分支(gh pr checkout <n>,拉的是 PR 当前 HEAD;不要用可能被本地 merge 污染的旧本地分支)。
• 先 git fetch origin main 再 git merge origin/main:fetch 确保 remote 引用最新(否则 merge 的是旧 origin/main,审查基线仍落后);merge 后确保改动在当前代码上成立——老 PR 不 merge 可能缺文件 / 跑崩,merge 后才有"这个 PR 真能合、合了不崩"的判断基线。
• merge 冲突 → 见 §6(先解冲突再审,解的过程本身也暴露集成影响)。
• 审完再决定改不改:看到 review comment(CodeRabbit / 人)不要先改代码——先在 merged 代码上审(理解改动 + 框架语义),再决定 comment 采纳(改)还是驳回(说明理由)。顺序:merge → 审 → 评 comment → 改。
• 每个 PR 开一个 notes,记:背景核实 / 改动合理性 / 每级验证结果 / 结论 / 给 reviewer 的要点。
• 测试仓也必须切到 PR 同名分支(和主仓 gh pr checkout 对应):处理每个 PR 前,无论该 PR 有无配套测试仓 PR,都先在测试仓确保有同名分支——git -C zzz-od-test checkout <PR 同名分支>(无则 checkout -b 本地新建,不必等测试 PR),再 git -C zzz-od-test fetch origin && git merge origin/main(和主仓一样,确保测试改动在最新测试仓 main 上成立)。PR 的测试改动(新测试 / 截图 fixture)只进该分支,绝不直接 commit/push 测试仓 main。测试改动走 git -C zzz-od-test(主仓 gitignore 会静默跳过)。
  • 先建分支的目的:人一上来就在正确分支,后续补测试时不会忘记切分支 → 误 commit 测试仓 main(就是 #2348 的 4ca301d 教训:测试直接进 main → 所有 PR test-check 红)。哪怕该 PR 暂时没测试,也先把分支建好占位。