Reviewer queue selection must prove ordering before selecting next PR #321

New Issue

2026-07-07T01:30:23-05:00

jcwalker3 commented

2026-07-07 01:30:23 -05:00

Reviewer workflows list open PRs but do not always explain whether the API response is newest-first, oldest-first, or explicitly sorted before selecting the next PR.

Observed behavior

A reviewer report listed PR #291 first and PR #286 later, then selected PR #286 as the next actionable PR. This may be correct if the queue policy is oldest-first by PR number or creation date, but the report did not explicitly prove the ordering rule.

Required behavior

Reviewer workflows must state the queue ordering policy:
- oldest PR number first
- oldest created date first
- priority label
- project-specific order
If the API response order differs from the selection order, the workflow must explicitly sort or explain the selection.
For every earlier actionable PR skipped by policy, report why.
For newer PRs listed before the selected PR, clarify that they are newer and not earlier in the review queue if using oldest-first policy.

Acceptance criteria

Reports cannot claim next eligible PR without queue ordering proof.
Reports include the selection policy used.
Tests cover newest-first API response, oldest-first API response, blocked earlier PRs, and priority overrides.

Reviewer workflows list open PRs but do not always explain whether the API response is newest-first, oldest-first, or explicitly sorted before selecting the next PR. ## Observed behavior A reviewer report listed PR #291 first and PR #286 later, then selected PR #286 as the next actionable PR. This may be correct if the queue policy is oldest-first by PR number or creation date, but the report did not explicitly prove the ordering rule. ## Required behavior 1. Reviewer workflows must state the queue ordering policy: * oldest PR number first * oldest created date first * priority label * project-specific order 2. If the API response order differs from the selection order, the workflow must explicitly sort or explain the selection. 3. For every earlier actionable PR skipped by policy, report why. 4. For newer PRs listed before the selected PR, clarify that they are newer and not earlier in the review queue if using oldest-first policy. ## Acceptance criteria * Reports cannot claim `next eligible PR` without queue ordering proof. * Reports include the selection policy used. * Tests cover newest-first API response, oldest-first API response, blocked earlier PRs, and priority overrides.

jcwalker3 referenced this issue

2026-07-07 03:16:44 -05:00

Reject reviewer queue-status reports that violate loaded workflow proof gates #339

jcwalker3 added the status:in-progress label 2026-07-07 04:05:37 -05:00

jcwalker3 referenced this issue from a commit

2026-07-07 04:06:45 -05:00

feat: enforce queue ordering proof in reviewer reports (Closes #321)

jcwalker3 referenced a pull request that will close this issue

2026-07-07 04:06:58 -05:00

feat: enforce queue ordering proof in reviewer reports (Closes #321) #351

jcwalker3 referenced this issue from a commit

2026-07-07 04:27:44 -05:00