fix(adversarial): a veto panel too small to block must not report PASS

[stranske]

The defect

adversarial.aggregate_veto reported PASS whenever the reviewer population shrank below
veto_threshold. The threshold was then unreachable by construction, and the failure presented
as silence.

Observed live, not inferred (experiment advice:a6cc531b8010; full provenance in the capability's
ledger notes, since the evidence is instance-local and not committed). With
reviewers=["codex","vibe"] and veto_threshold=2, vibe returned null:

{"verdict": "PASS", "n_reviewers": 1, "n_vetoes": 1, "veto_threshold": 2,
 "blockers": [{"severity": "high", "confidence": 0.99, "finding": "..."}]}

verdict: "PASS" while carrying a high-severity 0.99-confidence blocker. aggregate_veto([])
was the same bug at its worst: zero reviewers returning read as a clean pass.

The module's own docstring says "Adjudicate, don't obey" — which is exactly why the aggregate must
refuse to say PASS when PASS is the only thing it could have said.

Why it survived: the selftest asserted it

# one high veto below threshold 2 -> still PASS (needs corroboration)
assert aggregate_veto([{"blocker": True, "severity": "high", "finding": "x"}], 2)["verdict"] == "PASS"

In a passing test that is indistinguishable from the intended minority-veto behaviour. The two cases
were never separated: a panel that could have blocked and declined to (a real PASS), versus a
panel too small to block at all.

The fix

• n_reviewers < veto_threshold yields a distinct INCONCLUSIVE verdict that still carries the
  blockers — the gate fails toward motion, not silence.
• The payload reports the drainable quantity beside the blocking one: reviewers_requested,
  reviewers_missing, threshold_reachable, and a summary of the form
  "1 veto / threshold 2, reviewers returned 1 of 2". The measuring window (reviewers that
  returned) was never the same population as the window the threshold is chosen against (reviewers
  requested); both are now stated in one place.
• review() passes reviewers_requested=len(reviewers).
• A reachable threshold the panel declines to meet is still PASS, so the
  no-single-voice-tyranny property the minority-veto design exists for is unchanged.

_threshold_reachable is a named function rather than an inline comparison specifically so the
selftest can break it.

Behaviour, before → after

case	before	after
1 of 2 returned, 1 high veto, threshold 2	PASS	INCONCLUSIVE — 1 veto / threshold 2, reviewers returned 1 of 2
0 of 3 returned, threshold 2	PASS	INCONCLUSIVE — 0 vetoes / threshold 2, reviewers returned 0 of 3
3 of 3 returned, 1 high veto, threshold 2	PASS	PASS (unchanged)
2 high vetoes, threshold 2	BLOCKED	BLOCKED (unchanged)

Test gate

python3 adversarial.py --selftest (run by verify.py's selftest discovery). Pins all four cases
above, plus a None-placeholder case, plus a deliberate break → revert on _threshold_reachable
that asserts "break did not change behaviour — test is vacuous" — so the shortfall branch cannot
silently stop being load-bearing.

Dedup finding (CLAUDE.md §0)

Grepped by concept for veto / threshold / quorum / inconclusive / n_reviewers / aggregate across
*.py. No sufficiency or quorum check existed anywhere. runtime_ac_panel.adjudicate_panel is
the nearest neighbour and is a separate aggregation this change deliberately does not touch —
ARCHITECTURE.md:394 and roles.py:751 pin both as rails. The only other references to
aggregate_veto were docs and the module's own selftest. Not a new capability: the existing rail is
extended. Recorded in the capability's ledger notes, not only here.

Downstream

• tick.py passes the verdict through to feedback.record_completion_event(status=...), which
  normalises free-form status — no enum to extend.
• pattern_miner.POSITIVE_VERDICTS excludes inconclusive, so an inconclusive panel correctly does
  not train as a pass.
• roles.adjudication_case_for_disagreement will now read INCONCLUSIVE against a gate PASS as a
  disagreement and open an adjudication case. Intended — that is the fail-toward-motion behaviour —
  and inert today because ORCH_RUN_ADVERSARIAL_REVIEW defaults off.

Verification

python3 verify.py locally: 365 passed, 3 failed, 82/82 selftests ran, ledger valid.

The 3 failures are pre-existing and unrelated — proven by stashing this change and re-running,
where they reproduce identically. All three are the evidence-acquisition capability, registered in
this instance's local ledger with entrypoint evidence_acquisition.py:run, a file present in no tree
and no commit. They are instance-local ledger state, so CI (which bootstraps an empty
ORCH_LOCAL_RUNTIME) should not see them. Being tracked separately; untouched here.

Mirror verification is pending — orch-sync-mirror.sh defaults its source to the canonical clone,
which cannot carry this change until it is merged and pulled. The owner owns that sync.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your current included review allowance is based on your included PR review attempts over the past 7 days.

Next review available in: 47 minutes

Limit details: You’ve used the included review currently available. Your 70 included PR review attempts over the past 7 days set your current allowance at 1 review per hour.

Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 6bb373bd-2a6a-4456-a656-76777363c14e

📥 Commits

Reviewing files that changed from the base of the PR and between 14c0ac4 and 7ed2e77.

📒 Files selected for processing (1)

• adversarial.py

---

_{Comment @coderabbitai help to get the list of available commands.}