pr-review-loop

在预算内把 PR 审到可合并：blocker 已修复验证，其余意见都有书面处置。审查回答的是「本 PR 的意图是否交付」，不是「这段代码还能挑出什么」；守住范围和修 bug 同样是你的职责。合并另按已有授权执行。

测试失败时先执行「测试失败处置」，尚未开 PR 也适用；任务仅为处理测试失败时，完成该节即结束。

开 PR 之前

模版里的「创建 PR 前完成」就是交付门槛：缺项会先被审查者当意见提出来，白白多一轮。

1. 用仓库自己的模版：.github/PULL_REQUEST_TEMPLATE.md（含全小写与 .github/PULL_REQUEST_TEMPLATE/ 目录）、docs/ 下的模版、CONTRIBUTING.md 指定的模版。整份按它的结构填满，冲突时以仓库为准；HTML 注释只当填写说明，正文不带注释。
2. 仓库没有模版时用 references/pr-template.md：占位项换成仓库的真实入口，无关小节删掉。
3. 在描述里写清意图：必须交付的行为、必须保持的不变量、明确不做的范围。分级以它为准；已有 PR 先从原始需求恢复意图。
4. 写满「创建 PR 前完成」再创建：GitHub gh pr create --body-file '<文件>'，Forgejo fj pr create，其他宿主按仓库入口提交同一份正文。

测试失败处置

1. 分诊：保存提交、命令、失败签名（用例与断言）、日志和并发条件，区分代码缺陷、测试缺陷与基础设施故障；证据不足时保留未定。复跑通过只证明结果不稳定；隔离通过或本 PR 未改相关文件，都不能排除真实竞态。
2. 有目的地复跑：首次可复跑一次失败用例或 gate，写明要验证的假设；隔离运行只作对照。同签名再次阻塞，或没有新的假设、修复、环境变化时，转用 $diagnosing-bugs 建立复现并定位；重复全量门禁须能检验新假设或验证处置结果。次数与证据跨提交、会话和代理累计。
3. 处置：本次引入的回归、关键正确性问题立即修复。仅在证据确认是既有测试缺陷、且有其他可靠覆盖保护关键行为时，才可将具体用例临时移入独立运行并报告失败的非阻塞检查；同时关联问题、负责人、恢复期限与恢复条件。仓库没有隔离机制时先修复或建立该机制，原门禁仍保持阻塞。调度、工具链等基础设施故障修复或明确报告阻塞，缺失的验证记未完成。
4. 验证与记录：修复后在原失败条件下做有界重复验证，并确认断言仍能发现目标缺陷，再跑受影响的必需检查。沿用仓库的问题追踪与记录位置；同一问题的次数、证据汇总更新，随实质处置批量提交，不为计数单独推送。复用已有检查前核对最终源码、工具链与覆盖范围，只补失效或缺失的证据。