pr-review-loop
请求复审后持续跟进至收敛。处理完一轮后保持对最新审查意见与检查状态的监听；一轮返回不代表任务已完成。
跟进入口
-
先读取当前 PR 的最新评论、审查结果和最新 HEAD 的检查状态，恢复工作树外的跨轮账本。快照与每一轮都核对最新 headRefOid，旧提交上的通过不能代替最新提交的检查与审查。读评论/意见列表记得带
--paginate——不带只回最旧 30 条，评论多的 PR 新意见永远不可见。 -
等齐本轮意见：本轮请求的和推送自动触发的审查者（按「审查者现状」本轮不出场、上轮已超时的不算），都在最新 HEAD 上给出结论（或按第 6 步放弃等待）后，才开始归桶和修改；只到了一部分就继续监听，不边到边改。
-
按「收敛规则」归桶 → 更新跨轮账本 → 判断是否触发方向审计。触发时先完成审计、确定收敛路径，再恢复修复；需要用户选择时按「暂停」交回用户。
-
按确定的路径修复 → 核验或补跑相关检查 → 在已有提交/推送授权范围内提交推送 → 回复。每次请求复审或继续等待自动复审前，必须把本轮处置及升级判断写回账本，向用户简短说明各子系统的连续轮数和下一步，再按「审查者现状」重新触发本轮未通过的审查者。需要额外授权时先完成可审阅的修复，再交回用户。
推送含可见 UI 改动的提交前：先重拍受影响界面、上传、
gh pr edit更新 PR 描述中的截图链接，再推送。push 时自动触发的审查者读的是当时的描述——先推后改，它按旧图审，会对已修问题再开一轮。上传前先打开图片，确认不是过渡帧或旧布局。 -
本轮处理完后继续监听最新审查意见与检查状态，新事件到达即回到第 1 步做快照。
-
审查者超过「审查者现状」里的等待上限仍无结果时，按其下的「等待上限只花一次」处理。借本账号身份发结论的 bot 可能在你的监听手段里不产生事件，等不到时按同一条规则处理。
结束跟进、因产品决策暂停、用户停止或交回用户前，撤掉仍在运行的监听。
审查者现状
当前接入的审查者与触发方式，名单变化时更新这里：