[Throughput] org-queue-sweep's org-wide review-dispatch budget (1 per 15-min tick) bottlenecks every repo, not just the offending one

[seonghobae]

Observed behavior

`pr-review-merge-scheduler.yml`'s `org-queue-sweep` job runs on the `*/15 * * * *` schedule and walks every organization repository, but the review-dispatch budget it enforces appears to be shared across the entire sweep run, org-wide, not per-repository.

Evidence from run 32556682284 (job 96991889320, 2026-08-22T06:36Z), sweeping ContextualWisdomLab/RankWeave:

PR #36: wait: current head has completed Strix evidence; review dispatch limit reached
PR #40: wait: current head has completed Strix evidence; review dispatch limit reached
PR #41: wait: current head has completed Strix evidence; review dispatch limit reached
...
Org sweep budget consumed: review dispatches=1/1, branch updates=1/1.

All three of RankWeave's open PRs had passed every required check (Strix, coverage-evidence) and had zero unresolved review threads at the time of this sweep, yet none could be dispatched for the actual OpenCode LLM review because the sweep's total org-wide budget for the entire 15-minute tick was already 1/1 — consumed before or during this repository's turn, with more repos (ThreadWeave, EgressWeave, and presumably others) still left to sweep in the same run.

Why this matters

At 1 review-dispatch per 15-minute sweep org-wide, a backlog of N ready-to-review PRs across the organization takes roughly N × 15 minutes to clear through the fallback sweep alone, regardless of how many repositories or PRs are actually ready simultaneously. As the organization adds repositories (RankWeave, LineageWeave, ThreadWeave, EgressWeave, and others observed in this same sweep log), this ceiling does not scale — it gets worse. This was directly blocking RankWeave PR #36 (a governance-loop fix), #40, and #41 from ever reaching required-review coverage through the sweep path.

Not something I patched directly

This budget almost certainly exists to bound LLM API cost/rate-limit exposure per sweep tick, and I don't have visibility into what quota or cost ceiling it was sized against. Raising it blindly risked a real provider rate-limit or budget problem across the whole org, so I'm filing this with the concrete evidence instead of unilaterally changing a shared organization-wide throttle.

Suggested directions (for whoever has the cost/quota context)

• Make the review-dispatch budget per-repository per-sweep instead of org-wide per-sweep, so one repository's backlog cannot starve every other repository's ready PRs in the same tick.
• Or increase the org-wide budget if the current "1" is simply an unconsidered default rather than a deliberate cost ceiling.
• Or prioritize dispatch order by PR age / explicit priority label so the same PRs don't get starved indefinitely if the sweep always processes repositories in the same order and exhausts budget on the first repo(s) it visits.

Cross-reference

Discovered while working ContextualWisdomLab/RankWeave PR #36/#40/#41 through the review→fix→merge loop; see that repository's docs/product-technical-gap-baseline.md for the immediate-consumer-side account of this block.

[seonghobae]

2026-09-02 current consumer canary: ContextualWisdomLab/ConceptWeave now has two genuine stacked PRs whose base is the foundation feature branch rather than the repository default branch. PR #6 exact head bc25e6f29f16bf5afa8df220f466e688f030aa3e currently has only one check-run (rust-quality, queued) and no central OpenCode review/check; PR #5 exact head 398d8d6878706251397267d8fd8a660d4c2ecc7e likewise has its repository Product run queued. I re-read current main: pr_review_merge_scheduler.py does contain the dedicated stacked-PR path and ORG_SWEEP_STACKED_REVIEW_DISPATCH_LIMIT, and docs/doctoring/org-queue-sweep-rotation.md records the rotation repair, so this is not evidence that stacked support is absent from source and I am not creating a duplicate workflow patch or raising provider budgets blindly.

Acceptance evidence for this issue should include a live rotated sweep dispatching at least one unchanged stacked consumer head through the central OpenCode path (not merely documenting the code path), with the dispatch/check/review bound to that exact head. If the current default stacked budget of 1 continues to leave eligible stacked heads without dispatch across a full repository-count rotation, treat that as a remaining throughput/fairness defect and repair the owning scheduler/budget policy with measured provider capacity rather than leaf workflow churn. Queued repository-owned checks remain non-passing and do not justify a bypass.