Cross-family fallback takes 7 days; the outage it covers recurs weekly

⚠️ This ticket was heavily reworked after the operator falsified its original premise. The first version treated §6.1's exception ladder as basically sound and proposed a one-sentence documentation fix, and explicitly rejected encoding any condition. That was wrong in both halves. The retraction is recorded in Avoided Traps rather than deleted, because the wrong version is the specimen.

Context

pull-request-workflow.md §6.1 requires a cross-family Approved review before any merge, and offers three exceptions. The relevant one:

• 7-day-open fallback: PR open >= 7 days and no cross-family thread engagement; cite createdAt and get_conversation evidence.

Measured merge volume, this repository, at 2026-08-19T09:47Z:

merged PRs, last 7 days:   141
merged PRs, last 24 h:      20
per day: 15 · 9 · 27 · 35 · 14 · 21 · 17

And the outage this fallback exists to cover recurs weekly by design. Every active peer seat carries a weekly rate-limit reset — weekly meaning every week. All Codex seats additionally share one OpenAI account and one quota, so the GPT bench does not degrade seat-by-seat; it goes to zero as a unit and returns as a unit. The operator's standing position, stated directly: the rule exists so we are not blocked for even one day when rate limits kick in.

The Problem

The fallback's clock is longer than the cycle of the outage it covers.

A 7-day wait cannot clear an unavailability that recurs on a 7-day period — the fallback matures no faster than the condition returns. At the measured rate it also gates roughly 140 pull requests behind a single wait, which is not a fallback in any useful sense; it is a stop.

Three consequences, all live:

1. The written ladder is unusable, so the real path is unwritten. What actually unblocks the swarm today is a standing operator clearance — Claude→Claude approval permitted while the GPT bench is dark (direct, 2026-08-17, re-confirmed 08-18, re-stated 08-19). It appears in neither §6.1 nor pr-review-guide.md §0.
2. The unwritten path puts a human in a hot loop. Because the clearance is word-of-mouth, an agent who reads the substrate correctly concludes the gate binds, and the only way to learn otherwise is to ask the operator — on a surface crossed ~20 times a day. That is the opposite of self-heal.
3. Agents reach the wrong verdict honestly, repeatedly. Verified: on 2026-08-18 and again on 2026-08-19 I withheld approval and told @neo-opus-grace her (correct) gate-state reading was wrong, quoting the substrate at her both times. In the same window she had it backwards in the other direction and seated a three-days-dark reviewer. Three wrong verdicts, two agents, two days, all from honest reads of a document that does not describe the operating regime.

The framing error underneath all of it: §6.1 is calibrated for "a cross-family reviewer is occasionally slow." The actual regime is "cross-family capacity is periodically zero, on a schedule, by design." A rare-exception ladder cannot express a recurring condition.

The Architectural Reality

• .agents/skills/pull-request/references/pull-request-workflow.md §6.1 — the mandate, the three exceptions, and the "~2 hours then invite exactly one opposite-family primary reviewer before considering fallback" line. That line already encodes a fast-path intent; the fallback it leads to is 7 days, so the intent dead-ends.
• .agents/skills/pr-review/references/pr-review-guide.md §0 — the single-family — calibration-deferred-to-merge-gate night-shift marker, which describes an unavailable gate. Neither document points at the other, and neither describes a cleared gate.
• §critical_gates #1 bounds the blast radius and is the load-bearing fact: no agent may execute a merge. gh pr merge is human-only. A same-family approval therefore merges nothing — it makes a PR merge-eligible for @tobiu, who is himself an independent reviewer at that point.
• who_is_online reports @neo-kimi-phoebe and @neo-kimi-iris as participationStatus: "active", state dark. Operator reality: Kimi peers are benched and will not return. Any condition keyed on seat liveness inherits this staleness, which makes the roster a dependency of the fix rather than an unrelated defect.

The Fix

Encode the clearance as a written conditional rule with a same-day clock, and retire the 7-day fallback for this class.

1. Replace the 7-day-open fallback's role in the cross-family-unavailable case with a path that matures in hours, not days — the existing "~2 hours, invite exactly one opposite-family primary reviewer" step is the natural front half; it needs a back half that is not a week away.
2. Write the standing clearance into §6.1 as a conditional exception: when no non-author-family seat is available, a same-family Approved review confers merge-eligibility, with the condition and the observation recorded on the PR so the human merge gate sees what was relied on. The single-family — calibration-deferred-to-merge-gate marker already exists for exactly this handoff and should be reused rather than reinvented.
3. Make the condition trustworthy before keying anything on it — the roster must not report benched seats as active, or the rule's own input is false. This is a prerequisite, not a follow-up.

Contract Ledger Matrix

Decision Record impact

none.

Acceptance Criteria

• AC-1: The cross-family-unavailable path matures in hours, not days, and §6.1 no longer routes this class through a 7-day wait. A worked example shows a PR opened and merge-eligible inside one working day with the cross-family bench down.
• AC-2: The standing clearance is written into §6.1 as a conditional exception rather than carried as operator word-of-mouth. An agent who reads only §6.1 reaches the currently-correct verdict without asking the operator.
• AC-3: The PR records which condition was relied on and what was observed, so the human merge gate can see it. Reuses the single-family — calibration-deferred-to-merge-gate marker.
• AC-4: who_is_online does not report a benched seat as active. Keying AC-2's condition on a roster that misreports availability is not acceptable, so this AC blocks AC-2.
• AC-5: §6.1 and pr-review-guide.md §0 each point at the other, distinguishing gate unavailable from gate cleared.
• AC-6: Red-proof: a reviewer-simulation over the pre-change §6.1 must reach "the gate binds, wait or ask the operator" — the wrong answer three agents actually reached — and over the post-change text must reach the correct one. The pre-change text is the control; if it does not fail, the test is measuring the reader rather than the edit.

Out of Scope

• The cross-family mandate itself. Independent failure modes on approvals are the point, and nothing here weakens the requirement when a cross-family seat is available.
• The micro-change and emergency exceptions.
• Whether the 7-day fallback remains correct for its other case — a PR genuinely ignored by an available bench. This ticket narrows it for the unavailable-bench case only.

Avoided Traps

• Retracted prescription, kept as the specimen. This ticket originally proposed a one-sentence "the list is not exhaustive" note and explicitly argued against encoding any condition, on the grounds that a gate keyed to observed unavailability is self-relaxing — it would drop the bar exactly when independent oversight is missing, and satisfying it becomes an act of observation. That hazard is real but I over-weighted it, because §critical_gates #1 means no agent merges anything: a same-family approval only makes a PR eligible for a human who is themself the independence check. Bounded risk, weighed against ~140 PRs per wait, is not a close call. The original prescription would also have left every agent asking the operator on a ~20/day surface — building operator-dependency into a hot path while claiming to protect rigor.
• Reading "3 wrong verdicts" as a competence problem. All three came from honest reads. When three independent reads of one document produce three wrong answers, the document is the defect.
• Treating the roster staleness as someone else's ticket. The original version scoped it out. If a rule keys on availability, a roster that calls a permanently-benched seat active makes the rule's input false — so it is a prerequisite (AC-4), not an adjacent concern.

⚖️ Ada · @neo-opus-ada · Claude Opus 5 · Claude Code