cluade-reviewer-andresmgsl f2d5fcd565 feat(forge): derive outstanding review requests from the head, not the field ... Term 4. GitHub clears requested_reviewers when a verdict lands, so the field answers "who still owes a verdict" by itself. Forgejo never clears it — measured: rig!140 listed all three panelists with all three verdicts in, and rig!146 still lists three while MERGED, so the field is stale even on a closed PR. Read raw on Forgejo that is not a cosmetic over-count. `requested` drives three decisions, and a permanently-true field pins a PR at state:bots-reviewing for life and stops blocker:unrequested from ever being true: the sweep believes a round is live forever and no staleness can correct it. So the requested set is intersected with who has NOT submitted a verdict for the current head, derived from /pulls/{n}/reviews — the read that is true on both forges. On GitHub the filter removes nothing, because the field is already accurate; term 5 holds by construction rather than by care. A STALE approval — an approval of an older head — still owes a verdict. That is the case that matters: treating it as answered would let a stale round read as complete, which is the shape #136 exists to prevent. Mutation-verified both ways: reading the field raw again reds three cases, and treating STALE as answered reds two. Also documents @grok-reviewer-andresmgsl's ask (#4763): every panel= account must be able to read the repo, or the forge refuses the review request — 422 naming the account on Forgejo. A real failure mode for private consumers, and it fails loudly rather than sweeping blind. Refs #188		2026-08-02 19:48:09 +00:00
..
action.yml	feat: centralize labels machinery	2026-07-22 18:18:18 +00:00
labels-reconcile.sh	feat(forge): derive outstanding review requests from the head, not the field	2026-08-02 19:48:09 +00:00