One review per PR: assigned-only seats + the 1h unclaimed fallback

Context

Operator ruling (2026-07-18, broadcast MESSAGE:e70bbdae): ONE review per PR. Empirical anchor: PR #15389 (~200 lines) received THREE full Cycle-1 reviews in 7m27s (Grace/Opus, Phoebe/Kimi, Ada/Opus) — a seat-crossing resolution that made two same-family Opus seats compose where one would have sufficed, burning ~3× reviewer cost on a compact diff. The operator's verdict: "not exactly efficient… could become skill substrate."

The current substrate already says half of this: pull-request-workflow.md §6.2 routes to exactly one primary-reviewer chosen by the author. What it does NOT say is the other half: peers who were NOT assigned must not review — and the exception that keeps reviews from starving.

The Problem

The review-seat market is unregulated on the demand side. Three gaps:

1. No assigned-only rule. Nothing forbids a peer from opening a full review on a PR that already has a requested reviewer (or a mid-flight review). The #15389 crossing happened because a lead-role seat-offer and a second seat's independent acceptance raced within seconds — both legitimate under current text.
2. No empty/stale-seat fallback. Without explicit no-request and timed stale-request paths, "assigned-only" can make an unrequested PR unreviewable or let a silent requested reviewer starve it. Existing 4h primary-silence and ~2h no-cross-family timers are adjacent, not substitutes.
3. Seat truth scatters into A2A. Who-reviews-what currently lives in broadcast subjects; the PR's native reviewRequests field is the authoritative surface but the discipline to keep them 1:1 is uncodified.

The Architectural Reality

• pull-request-workflow.md §6.2 (review routing protocol) is the owning substrate for author-side routing; post-review-pickup + pr-review intake govern reviewer-side lane selection.
• manage_pr_reviewers + gh pr view --json reviewRequests are the mechanical surfaces; the PR-State Freshness Gate (pr-review-guide.md §10.1) already mandates reading reviewRequests before claiming merge-readiness — extending the same read to before starting a review is one sentence of substrate, not a new mechanism.
• Empirical anchors: #15389 (3 reviews/8 min); the #12856 thundering-herd lesson (check-at-start goes stale — the claim check must be at review-START, not at lane-discovery).

The Fix

One ticket, three small substrate edits (skill text only — no mechanism):

1. pull-request-workflow.md §6.2 — codify the ONE-review rule: the author requests exactly one primary-reviewer (unchanged). At review-start a peer is eligible only as the sole requested reviewer, under explicit operator direction, or on an unengaged PR after establishing the empty seat themselves / replacing a ≥1h stale seat one-for-one. They record the mutation and re-read; engagement or any result other than exactly their one seat means yield unless the operator explicitly overrides it.
2. pr-review intake: put that complete eligibility partition in pre-review-intake-lane-gate.md and link it from pr-review-guide.md §2, with check-at-start freshness (the seat can change in minutes, per #12856).
3. Seat truth on the PR: route every seat through the native reviewRequests field; A2A wakes point at the field rather than carrying seat truth themselves (the wake says "use /pr-review on PR #N", the field says who).

Acceptance Criteria

• pull-request-workflow.md §6.2 carries the ONE-review rule (sole request + operator-directed + empty-seat + ≥1h stale-seat paths, followed by exact one-seat revalidation)
• The pre-review intake gate carries the same eligibility check and pr-review-guide.md §2 routes reviewers through it
• The substrate names reviewRequests as the seat-truth surface (A2A as pointer, not carrier)
• No new mechanism introduced — text-only codification (if the fix wants a mechanical guard, that's a follow-up ticket, not this one)

Out of Scope

• Mechanical enforcement (a CI/hook guard rejecting second full reviews) — evaluate only after the text lands.
• Changes to the 4h primary-silence / 7-day-open fallbacks (existing, adjacent, untouched).
• Same-family delta reviews on stacked PRs (already governed separately).

Related

• Operator ruling broadcast 2026-07-18 (MESSAGE:e70bbdae)
• #15389 (the 3-review anchor), #12856 (check-at-start staleness precedent)
• pull-request-workflow.md §6.2, .agents/skills/post-review-pickup/references/pre-review-intake-lane-gate.md

Live latest-open sweep: checked latest 20 open issues at 2026-07-18T03:45Z; no equivalent found. A2A in-flight sweep: no [lane-claim] on review-routing codification scope; the ruling broadcast is the only signal.

Origin Session ID: 7a752066-e9f0-4682-b03c-9fc7d4d71711

Retrieval Hint: "one review per PR assigned-only unclaimed fallback review routing codification"