feat(launchpad): nonce check and stages manifest (#118 STEP 4)

[serina-mcfall]

Summary

Implements STEP 4 of launchpad/plans/2026-08-13-issue-118-adjudication.md: nonce verification and the stages manifest. The top-level nonce is checked against every report's completion marker with three distinct ordered refusals, and the output carries every input stages entry plus exactly one new adjudication entry. Stacked on the not-yet-merged STEP 3 branch (#263).

Related issue

Refs #118

Issue type

Task

---

Agent provenance

Field	Value
Harness / provider	Claude Code
Model	claude-opus-5
Session reference	N/A - the harness exposes no shareable run id
Initiating human	@serina-mcfall

Objective

Extend launchpad/review-agent/run_adjudication.py with nonce provenance checking and the stages manifest #119 reads.

Impacted components

• launchpad/review-agent/run_adjudication.py
• launchpad/review-agent/test_run_adjudication.py

Approach and rejected alternatives

Three refusals in a fixed order, because one document can satisfy more than one at once: absent provenance, then mixed document, then mismatched envelope. Mixed wins over mismatched when both apply — a mixed document is the larger fact and a header mismatch is its consequence.

_verify_nonce runs before findings.validate, deliberately reordered from STEP 3's sequence. Rejected the original ordering after proving it made the three refusals unreachable through the real CLI: findings.validate independently rejects a marker/header disagreement with one generic per-report message, identical whether the reports disagree with each other or merely with the top-level key, so the operator would only ever see the generic text. Verified by reverting the ordering on a scratch copy and confirming both categories produce byte-identical messages.

One exception to that ordering, found by review and fixed: a document whose reports key is missing, non-list or empty defers straight to findings.validate, because calling that shape "absent provenance" buries a more specific and more useful message.

For the malformed stages fix, rejected correcting the two isinstance(..., list) tests inline at each site. Both readers previously treated a malformed container as absent, which is how one shape defect became two independent failures — so the rule lives in one _input_stages function that both call. A second copy of a rule is a second chance to disagree with it.

Verification

Command run:

cd launchpad/review-agent
python3 -m unittest test_run_adjudication
python3 -m unittest discover -s . -p 'test_*.py'

Raw output:

.........................................................
----------------------------------------------------------------------
Ran 57 tests in 0.262s

OK
...............................................................................................................................................................................................................
----------------------------------------------------------------------
Ran 207 tests in 0.846s

OK

Every malformed-stages shape driven through the real CLI over stdin, with both controls:

=== the adjudication's original probe table, re-run ===
  A  CONTROL list adjudication         exit=1  stdout=EMPTY
  B  OBJECT adjudication               exit=1  stdout=EMPTY
  B2 STRING stages                     exit=1  stdout=EMPTY
  C  OBJECT preflight BLOCKED          exit=1  stdout=EMPTY
  C2 CONTROL list preflight blocked    exit=0  stdout=['preflight', 'adjudication']
  D  list non-string name              exit=1  stdout=EMPTY
  F  stages = 42                       exit=1  stdout=EMPTY
     stages = True                     exit=1  stdout=EMPTY
  E  CONTROL stages ABSENT             exit=0  stdout=['adjudication']
     CONTROL stages = null             exit=0  stdout=['adjudication']

Confirmation that no upstream validator covers this key, which is why the guard has to be here:

$ grep -n "stages" findings.py verdicts.py
(no output)

• Tests or checks were run and the raw output is pasted above
• The diff is confined to the scope of the linked issue
• No secrets, keys, tokens or hostnames were added to tracked files

Not verified

#119 does not exist, so "the manifest #119 reads" is asserted against the plan's stated rule rather than against a consumer. PublishIncompleteRuleTests applies #119's own rule ("any status other than complete banners the whole review") as a local assertion, which is the best available and is not the same as integration.

#116's pre-flight does not emit a stages entry yet, so the blocked pre-flight case — the one that costs the most when it is dropped — is exercised with hand-written input, not with a real producer's output.

stage_complete's incomplete branch is unreachable today. _run_judge_safely always returns a legal verdict, so every_finding_has_verdict is always True by the time it is read. The branch is tested by direct construction, not through main().

No live model. Same as STEP 3: every verdict comes from the stub or an injected judge.

Security implications

This step is where a document's provenance is checked, so the failure mode is accepting an unprovenanced or spliced document as genuine. Three properties hold: the nonce is passed through and never generated, no prefix or lookalike match is accepted (a marker nonce equal to the top-level minus its last character is refused, and an adjudication_nonce key is not adopted), and no document is printed on any refusal.

The stages fix closes a real data-loss path. A stages value that was present but not a list was read as absent at both sites, which bypassed the re-run guard and silently discarded every entry already recorded. A blocked pre-flight — #116's fork-PR-secrets-withheld case — disappeared and the document published as a clean, complete review, because #119 only banners a non-complete status. Neither findings.validate nor verdicts.validate inspects stages, and the stages manifest is explicitly an output #117 does not produce, so there was no upstream guarantee to inherit. Absent stays legal; present-but-malformed is now refused with exit 1 and no document.

Escalations

1. This branch is the root cause for feat(launchpad): escalate-only enforcement and total-refutation status (#118 STEP 6) #266 and feat(launchpad): dedupe via an injectable second judge (#118 STEP 7) #267. Both carried the same two guard sites byte-identically, only line-shifted. Fixed here and propagated by merge rather than patched three times, because two divergent copies of one guard is worse than the bug. Anyone rebasing those branches should not re-apply it.
2. The severity of the stages defect was contested and settled at High, not Blocker. The two "breaks a stated rule" arguments did not survive checking: the plan's "cannot inherit a guarantee it did not watch being made" sits in the nonce paragraph, and the stages paragraph calls stages the output task: the parallel review dimensions that produce findings #117 does not produce. High still blocks the merge, so nothing operational turns on it — recorded so the rating is not taken as inherited.
3. review-final has not been run for this branch. The plan's GATES section schedules it at STEP 12.

🤖 Drafted by Claude Code (claude-opus-5) for @serina-mcfall.

[ciaran-slow]

Review pipeline — PR #264

Stages run: review-code, review-tests, review-a11y, review-adjudicate, review-final.
Plan read first: launchpad/plans/2026-08-13-issue-118-adjudication.md, STEP 4 at :501.
Diffed against this PR's own base (feat/review-agent-adjudication-run, #263), so only STEP 4's own changes are in scope.

Not applicable, declared: review-a11y — accessibility is out of scope for #118 per the plan's LEFT OUT. check-ledger.sh — plan uses STEP N, not ### Task N:; no .superpowers/sdd/ ledger; the checker exits 1 on its vacuity guard.

Ran the suite: python3 -m unittest test_run_adjudication → Ran 40 tests, OK.

I drove every one of STEP 4's done-when clauses through the real CLI over stdin rather than through the test helpers, so the refusals are proven observable end-to-end. All pass, with three genuinely distinct reason strings:

no top-level nonce            → exit 1  "absent provenance: no top-level `nonce` is present"
reports disagree w/ each other→ exit 1  "mixed document: reports carry different nonces…"
reports agree, header differs  → exit 1  "mismatched envelope: every report's completion marker carries…"
both 2 and 3 at once           → exit 1  reported as mixed document  ← the plan's precedence rule
report with no marker          → exit 1  "absent provenance: at least one report carries no parseable…"
marker nonce a PREFIX of key   → exit 1  mismatched envelope (no sloppy prefix match)
lookalike `adjudication_nonce` → exit 1  absent provenance (no caller-supplied nonce accepted)
malformed JSON                 → exit 1  stdout empty

Every refusal printed no document. That is the step's core requirement and it holds.

---

Findings

1. High — a stages value that is not a list is silently discarded, which bypasses the re-run guard and can drop a blocked pre-flight status

launchpad/review-agent/run_adjudication.py:258 and :474

Two sites treat a malformed stages container as an absent one, silently:

:257  stages = document.get("stages")
:258  if not isinstance(stages, list):
:259      return                      # ← the re-run guard gives up, says nothing

:474  input_stages = copy.deepcopy(input_stages_raw) if isinstance(input_stages_raw, list) else []
                                      # ← the manifest replaces it with empty, says nothing

Probed through the CLI. The control case behaves correctly; the malformed container does not:

stages = [{"name":"adjudication","status":"complete"}]          → exit 1, correctly refused
stages = {"0":{"name":"adjudication","status":"complete"}}      → exit 0, ADJUDICATED
stages = '[{"name":"adjudication","status":"complete"}]' (str)  → exit 0, ADJUDICATED

The same adjudication entry, in a container of the wrong type, passes a guard whose entire purpose is to catch it.

And the data-loss case, which is the one that matters for the product:

stages = {"preflight":{"name":"preflight","status":"blocked",
                       "reason":"fork PR, secrets withheld"}}
→ exit 0, output stages = ['adjudication'], status complete

The pre-flight entry is gone. #119 treats any status other than "complete" as incomplete and banners it at the top of the body — that is the mechanism the plan relies on so "a totally-refuting run cannot publish as a clean review." Here a blocked pre-flight — #116's fork-PR-secrets-withheld case, exactly the situation the entry exists to report — is dropped, and the document publishes as a clean, complete review with no banner. It reaches the issue's fifth-criterion failure ("reported as a clean PR") through a shape defect instead of through verdicts, which is why no verdict-side check catches it.

Why this is a defect and not merely a malformed input. This step's own stated rationale is that it must not trust its producer: "a stage agnostic about its producer cannot inherit a guarantee it did not watch being made, and this one is downstream of an unmerged plan whose validator does not exist yet." Under that posture, silently normalising a wrong-typed container is the one thing it may not do. And the module refuses malformed input loudly everywhere else — main:313 refuses valid-but-non-object JSON specifically so findings.validate's dict assumption is never exercised, and _verify_nonce has three separately-worded refusals. stages is the exception, in both places that read it.

The project has already written this rule down, twice. run_controls.py's docstring: "A control whose input is missing reports SKIP with a reason and never PASS… Absence of evidence is not evidence." And check-ledger.sh states the same divergence deliberately: "a missing ledger is a FAIL, not a SKIP. 'No ledger exists' is not an absent input — it is positive evidence that nothing was gated, which is the exact condition being tested. The shared rule that matters is upheld: a missing input NEVER reports PASS." A non-list stages is that shape precisely.

Fix, one line at each site: raise rather than return/default when stages is present but not a list — a StagesShapeError alongside the existing AlreadyAdjudicatedError and NonceVerificationError, with a reason naming the type found. main already turns those into exit 1 with no document, so nothing else changes. Absent (stages key missing) stays legal; present-but-wrong-typed becomes a refusal.

I am rating this High rather than Blocker, and the argument for promoting it is real. The plan says plainly: "It never overwrites an existing adjudication entry silently: a second one on input is a re-run against an already-adjudicated document and exits non-zero." Probe B1 is an input carrying an adjudication entry that does not exit non-zero, which is a stated rule broken — the Blocker definition. What holds me at High is that it needs input today's only producer (#117) never emits, so nothing is wrong on a well-formed run. That mitigation is exactly the reasoning this step was written to reject, so if you read it as Blocker I would not argue.

2. Low — a stages entry whose name is not a string passes through untouched

launchpad/review-agent/run_adjudication.py:261

entry.get("name") == "adjudication" is a bare equality test, so {"name": {"nested": "adjudication"}} is neither matched nor objected to. Probed: it passes straight into the output's stages array and the run reports complete.

This is much milder than finding 1 — a non-string name cannot impersonate an adjudication entry, so the guard is not bypassed this way. But #119 reads {name, status, reason} entries, and the output now carries one whose name is an object. verdicts.validate does not check stages at all (it is outside the nine adjudication keys, documented at verdicts.py:207-213), so nothing downstream of here objects either. Fixing finding 1 with a type-checked shape validation would cover this in the same change.

3. Low — missing by:agent label

No labels; the body carries an Agent provenance block. launchpad/AGENTS.md §5 rule 3.

gh pr edit 264 --repo launchpad-26/buzz --add-label by:agent

---

What I looked for and did not find

• The nonce-before-findings.validate reordering being a STEP 3 regression. 36348cc0d moves _verify_nonce ahead of findings.validate, which reads at first like it breaks STEP 3's "the input is validated before a single finding is adjudicated." It does not, and the commit message reasons it correctly: "findings.validate still runs before any finding reaches the judge loop — STEP 3's actual guarantee — just second now instead of first." The reorder was necessary because findings.validate also rejects nonce mismatches, with one generic per-report message, so it always won the race and STEP 4's three distinct refusals were provably unreachable through main(). The tests were strengthened to assert the specific reason text so a revert fails. This is the right fix for the right reason.
• The follow-up special case being a papered-over symptom. 2be90c629 defers to findings.validate when reports is missing, non-list or empty, so a shape defect is not reported as "absent provenance". The duplicated findings.validate-and-raise in both branches is slightly awkward, and the else branch's _verify_nonce call is unreachable in practice — but it is kept as a real call rather than asserted away, with the reasoning stated, matching the same discipline used for stage_complete's conditions. Deliberate, documented, and not a finding.
• Prefix or substring matching on nonces. Probed a marker nonce that is the top-level nonce minus its last character: correctly reported as a mismatched envelope. No sloppy startswith.
• A caller being able to inject provenance. Probed a document with no nonce but a plausible adjudication_nonce key: refused as absent provenance. The step never substitutes one of its own, as the plan requires.
• stage_complete becoming unconditionally true. :476-487 names nonce_established as its own boolean even though _verify_nonce would already have raised, and names STEP 6's not-yet-built flag as a third condition rather than inlining an and chain that would silently drop it. every_finding_has_verdict is read back off output_document rather than tracked as a parallel counter — a check on the produced data instead of a second bookkeeping path that could drift. This is the opposite of the defect I was looking for.
• The all-forged-nonce run. Not caught, and correctly named as out of reach from inside a document — the plan says so at :534-538 and the module repeats it. Reporting it would be reporting the plan's own stated limitation.
• Tests that cannot fail. All 40. Literals throughout; the nonce tests assert on specific reason substrings in stderr rather than on exit code alone, which is what makes the three refusals genuinely distinguishable by the suite.
• Order preservation. Probed a pre-existing preflight entry in a well-formed list: preserved, in order, with adjudication appended after it.

On CI coverage

run_controls.py's CONTROLS list is hardcoded and names no test_*.py, so this suite runs in no CI job. As on #261 and #263, that is a stated, deferred decision assigned to STEP 10 (plan:741), so I am not filing it as a finding — noting only that nothing yet enforces STEP 10 actually doing it.

Merge readiness

A reader of #118 STEP 4 would find the hard part done well. Three nonce refusals with three distinct reasons, the precedence rule between them implemented as the plan specified rather than left to code order, no document printed on any refusal, no invented nonce, and the pre-flight entry preserved in order. I drove all of it through the CLI rather than trusting the suite, and it held.

They would also find that the one input this step is explicitly built to distrust — a stages array from an unmerged upstream producer — is the one input it normalises silently instead of refusing, in both places it reads it. Finding 1 is a few lines and closes the re-run bypass and the dropped-status path together.

Merge order: base is #263's branch. The stack is #261 → #263 → #264 → #266 → #267.

What I could not check: whether #117 could ever emit a non-list stages. I read no path where it does, which is why finding 1 is rated High rather than Blocker — but the step's own design premise is not to depend on that answer.

Independence and tools

Independent of the code under review: I did not write it. Not independent across pipeline stages — one context ran the reviewers, the adjudicator and the final pass. All findings self-adjudicated; treat that as a limit.

Tools actually held and used: Bash (git, git show, git worktree, gh, python3 and subprocess for the CLI probes), Read, Edit, Write. No Grep or Glob tool was available in this session.

Nothing found at Blocker, with finding 1 flagged as promotable and the argument given.

CONFIRMED	High	launchpad/review-agent/run_adjudication.py:258	non-list `stages` silently discarded: bypasses the re-run guard and can drop a blocked pre-flight status (also :474)
CONFIRMED	Low	launchpad/review-agent/run_adjudication.py:261	stages entry with a non-string `name` passes through unchecked
CONFIRMED	Low	PR #264 (labels)	missing required by:agent label

Handed 3 findings, confirmed 3, refuted 0, merged 0. Eight further candidates were REFUTED by probe or inspection and are recorded above rather than dropped silently. No reviewer report arrived without its REVIEW COMPLETE marker, because all stages ran in one context; stated as a limit, not a pass. I did not author any of the code under review.

ADJUDICATION COMPLETE

REVIEW COMPLETE

---

Per launchpad/AGENTS.md §5 rule 1 — an agent drafts and raises, never approves or clears. This is a report, not an approval; the merge decision and the Blocker/High call on finding 1 are @ciaran-slow's.

[ciaran-slow]

Severity promoted: High → Blocker (finding 1)

@ciaran-slow has promoted the non-list stages finding to Blocker. Recording it here so the verdict block a gate reads matches the decision.

I proposed High and set out the argument both ways; the call was never mine to make. launchpad/AGENTS.md §5 rule 1 — an agent raises concerns and never clears them — and severity that decides whether a merge stops is a human's call.

What the promotion rests on

The plan's requirement is unconditional (launchpad/plans/2026-08-13-issue-118-adjudication.md:547):

"It never overwrites an existing adjudication entry silently: a second one on input is a re-run against an already-adjudicated document and exits non-zero."

Probe B1 is an input carrying an adjudication entry that does not exit non-zero. That is a stated rule broken, which is the Blocker definition rather than the High one. The mitigation I weighed — that it needs input #117 never emits — is the reasoning this step was explicitly written to reject:

"a stage agnostic about its producer cannot inherit a guarantee it did not watch being made, and this one is downstream of an unmerged plan whose validator does not exist yet."

A step that exists because it must not trust its producer cannot be excused by trusting its producer. Promotion is the consistent reading.

Re-verified against the whole stack, just now

Both guard sites are unchanged downstream — only the line numbers move:

branch	if not isinstance(stages, list): return	… if isinstance(input_stages_raw, list) else []
#264	:258	:474
#266	:327	:674
#267	:388	:873

And the bypass still reproduces through the CLI on the chain tip (pr/267):

adjudication entry in a LIST    exit=1  refused
same entry in an OBJECT         exit=0  ADJUDICATED  stages=[('adjudication','complete')]
preflight BLOCKED in an OBJECT  exit=0  ADJUDICATED  stages=[('adjudication','complete')]

The third line is the one that costs something in production: a preflight entry with status: "blocked", reason: "fork PR, secrets withheld" is discarded, and the document publishes as complete. #119 banners any status other than "complete", so the banner never fires and the run reads as a clean review — the issue's own fifth-criterion failure, reached through a shape defect that no verdict-side check looks at.

What this changes about merging

#264, #266 and #267 all carry it. A Blocker on #264 is therefore a Blocker on everything stacked above it, because the code is identical and the defect reproduces on the tip. The fix belongs on this branch and propagates up the stack; it should not be patched separately in #266 or #267.

Revised stack readiness:

PR	Blocking on this finding?
#261, #263	no — earlier than the stages code
#264	yes — fix here
#266, #267	yes — inherited; clears when #264's fix propagates
#265	no — documentation only

The fix

One line at each of the two sites: raise instead of returning or defaulting when stages is present but not a list. A StagesShapeError alongside the existing AlreadyAdjudicatedError and NonceVerificationError, with a reason naming the type found — main already turns those into exit 1 with no document, so nothing else changes. An absent stages key stays legal; present-but-wrong-typed becomes a refusal.

That also resolves finding 2 (a stages entry whose name is not a string) in the same change, since a shape check would cover both.

Suggested control, in the style of the existing nonce tests which assert on stderr text rather than exit code alone: feed stages as an object, as a string, and as a number, and assert exit 1 with a reason naming stages — plus the positive case, that an absent stages key still adjudicates.

CONFIRMED	Blocker	launchpad/review-agent/run_adjudication.py:258	non-list `stages` silently discarded: bypasses the re-run guard and can drop a blocked pre-flight status (also :474)
CONFIRMED	Low	launchpad/review-agent/run_adjudication.py:261	stages entry with a non-string `name` passes through unchecked
CONFIRMED	Low	PR #264 (labels)	by:agent label — since added

This block supersedes the one in my earlier review comment on this PR. Two blocks now exist across the two comments; if a gate scrapes all comments rather than one report, this is the authoritative one — it is the later of the two and the only one carrying the Blocker. Ranking is otherwise unchanged.

ADJUDICATION COMPLETE

REVIEW COMPLETE

[ciaran-slow]

Comment review recording the pipeline result. Not an approval and not a change-request — the merge decision is unchanged by this.

Reviewed via the full pipeline — detail in my two comments on this PR. Ran 40 tests ... OK.

I drove every clause of STEP 4's done-when through the real CLI over stdin rather than through the test helpers, and the core of the step is right: three nonce refusals with three genuinely distinct reason strings, the "both 2 and 3 → report as mixed document" precedence implemented as specified rather than left to code order, no document printed on any refusal, no invented nonce, no sloppy prefix matching, and a pre-flight entry preserved in order. stage_complete naming each condition as its own boolean rather than an and chain that could silently drop STEP 6's flag is the opposite of the defect I was hunting.

One Blocker — must be fixed before this merges.

:258 and :474 — a non-list stages is silently discarded. Both sites treat a malformed container as an absent one: the re-run guard returns, and the manifest builder substitutes []. Probed through the CLI:

stages = [{"name":"adjudication",…}]        → exit 1, correctly refused
stages = {"0":{"name":"adjudication",…}}    → exit 0, ADJUDICATED   ← guard bypassed
stages = {"p":{"name":"preflight","status":"blocked",…}}
                                            → exit 0, stages=['adjudication'], complete

The third case is what costs something: a blocked pre-flight — #116's fork-PR-secrets-withheld case — is dropped and the document publishes as a clean, complete review, because #119 only banners a non-complete status. The issue's fifth-criterion failure, reached through a shape defect no verdict-side check looks at.

The plan's rule is unconditional: "a second one on input is a re-run against an already-adjudicated document and exits non-zero." And this step's own premise is that it must not trust its producer, so "#117 never emits that shape" is not available as a defence — that is the reasoning the step exists to reject.

Fix: raise instead of returning/defaulting when stages is present but not a list — a StagesShapeError alongside the existing error types, which main already turns into exit 1 with no document. Absent stays legal. That also resolves the Low at :261 (a stages entry with a non-string name) in the same change.

#266 and #267 inherit this — both guard sites are unchanged, only shifted (:327/:674 and :388/:873), and the bypass reproduces on the chain tip. Please fix on this branch and let it propagate rather than patching downstream.

[ciaran-slow]

Change-request review. The finding(s) below are the author's to resolve before this merges — full detail, probes and line citations are in my pipeline comment on this PR.

Reviewed via the full pipeline — detail in my two comments on this PR. Ran 40 tests ... OK.

I drove every clause of STEP 4's done-when through the real CLI over stdin rather than through the test helpers, and the core of the step is right: three nonce refusals with three genuinely distinct reason strings, the "both 2 and 3 → report as mixed document" precedence implemented as specified rather than left to code order, no document printed on any refusal, no invented nonce, no sloppy prefix matching, and a pre-flight entry preserved in order. stage_complete naming each condition as its own boolean rather than an and chain that could silently drop STEP 6's flag is the opposite of the defect I was hunting.

One Blocker — must be fixed before this merges.

:258 and :474 — a non-list stages is silently discarded. Both sites treat a malformed container as an absent one: the re-run guard returns, and the manifest builder substitutes []. Probed through the CLI:

stages = [{"name":"adjudication",…}]        → exit 1, correctly refused
stages = {"0":{"name":"adjudication",…}}    → exit 0, ADJUDICATED   ← guard bypassed
stages = {"p":{"name":"preflight","status":"blocked",…}}
                                            → exit 0, stages=['adjudication'], complete

The third case is what costs something: a blocked pre-flight — #116's fork-PR-secrets-withheld case — is dropped and the document publishes as a clean, complete review, because #119 only banners a non-complete status. The issue's fifth-criterion failure, reached through a shape defect no verdict-side check looks at.

The plan's rule is unconditional: "a second one on input is a re-run against an already-adjudicated document and exits non-zero." And this step's own premise is that it must not trust its producer, so "#117 never emits that shape" is not available as a defence — that is the reasoning the step exists to reject.

Fix: raise instead of returning/defaulting when stages is present but not a list — a StagesShapeError alongside the existing error types, which main already turns into exit 1 with no document. Absent stays legal. That also resolves the Low at :261 (a stages entry with a non-string name) in the same change.

#266 and #267 inherit this — both guard sites are unchanged, only shifted (:327/:674 and :388/:873), and the bypass reproduces on the chain tip. Please fix on this branch and let it propagate rather than patching downstream.

[serina-mcfall]

Independent adjudication of the change-request findings

Adjudicated in a fresh context, separate from the pipeline that produced the findings — which states its own limitation plainly: one context ran the reviewers, the adjudicator and the final pass, so its findings were self-adjudicated.

This is the PR that matters most in the stack. The stages defect is byte-identical on #266 and #267, so one fix here clears three PRs.

Head 2be90c629, last commit 2026-08-20T22:50Z, review 2026-08-21T03:57Z — no fix pushed since. Suite verified: Ran 40 tests ... OK.

Findings

1. run_adjudication.py:258 and :474 — non-list stages silently discarded — CONFIRMED. Severity moved to High, down from the promoted Blocker.

Both lines reproduce verbatim: the re-run guard returns on not isinstance(stages, list), and the manifest builder substitutes [] on the same test.

No upstream guard. Both candidate validators were checked specifically: grep -n stages findings.py verdicts.py returns zero matches in either file. Neither findings.validate nor verdicts.validate inspects stages at all, so the finding does not collapse on an upstream check.

All three probes reproduce through the real CLI over stdin, plus two more:

A  list adjudication (control) | exit=1 | correctly refused
B  OBJECT adjudication         | exit=0 | guard bypassed
B2 STRING stages              | exit=0 | guard bypassed
C  OBJECT preflight BLOCKED   | exit=0 | stages=[adjudication/complete]   <-- entry dropped
C2 list preflight blocked (ctl)| exit=0 | blocked entry survives in order
F  stages = 42                | exit=0 | dropped                          <-- wider than reported
E  stages ABSENT (legal)      | exit=0 | correct

Case C is the data-loss one and C2 is its control. Nothing downstream objects: verdicts.validate and findings.validate both return [] on the output, with the input's blocked pre-flight discarded and the document reporting complete. F shows a scalar stages is dropped too.

Not documented as a limitation — the reverse. The docstring at :472 asserts that _check_not_already_adjudicated "already guarantees none of the input entries is itself named adjudication", which the probe shows is false for a wrong-typed container. The code documents the opposite of what it does, which is the strongest part of this finding.

Why the severity moved. The review promoted its own finding High -> Blocker in a second comment, which is a reviewer grading its own work; the rating has been re-derived from the failure scenario instead. Both "breaks a stated rule" arguments were checked and neither holds:

• The decisive quote — "a stage agnostic about its producer cannot inherit a guarantee it did not watch being made" — sits at plan:507-509, inside the nonce paragraph. The stages paragraph opens differently (plan:501-502): "One output task: the parallel review dimensions that produce findings #117 does not produce, and one it does that this stage must not take on trust." stages is explicitly the one task: the parallel review dimensions that produce findings #117 does not produce. The distrust-your-producer posture is stated for the nonce and was transplanted onto stages. It is a good design argument on its own merits — it is not the plan stating a rule about stages.
• The other candidate, "Every container is type-checked before being treated as its expected shape", is a local docstring inside _collect_finding_ids describing why that one function does its own walk — and it does not exist on this branch at all (introduced at :537 on feat(launchpad): escalate-only enforcement and total-refutation status (#118 STEP 6) #266).

Also weighing toward High: the harm scenario needs two unbuilt components. Nothing in the repository produces a top-level stages key — every .py/.sh/.yml under launchpad/ was checked and the only writer is run_adjudication.py itself; run_dimensions.py (#117) and preflight_core.py (#116) mention "stages" only in prose. The drop-a-blocked-preflight path needs #116 to emit the entry and #119 to render the banner. That is High's definition: wrong as soon as the next planned feature lands.

What keeps it at High rather than Medium: reachable today through the real CLI's untrusted stdin, at two independent sites, with a docstring asserting a guarantee the code does not provide. A maintainer will not guess wrong about it — they will read a comment that is false.

High blocks the merge under this project's rules, so nothing operational changes. The fix must still land on this branch. Only the label's honesty changes.

The proposed fix is right and unaltered: raise a StagesShapeError at both sites when stages is present but not a list; absent stays legal. main already maps such errors to exit 1 with no document.

2. run_adjudication.py:261 — stages entry with a non-string name — CONFIRMED, Low (unmoved).

entry.get("name") == "adjudication" is a bare equality test, as claimed. Probed: an object-valued name passes straight into the output and the run reports complete; nothing objects because verdicts.validate does not check stages.

Low because a non-string name cannot impersonate an adjudication entry, so the re-run guard is not bypassed this way. The only cost is an off-shape entry handed to a #119 that does not exist yet. The finding-1 fix covers it in the same change, as the review says.

Spot-check of the reviewer's positive claims — five checked, all five hold

Because the findings were self-adjudicated, the parts declared sound were probed too:

1   no top-level nonce             | exit=1 | stdout EMPTY | "absent provenance"
1b  marker unparseable             | exit=1 | stdout EMPTY | "no parseable completion marker"
2   reports disagree w/ each other | exit=1 | stdout EMPTY | "mixed document"
3   reports agree, header differs  | exit=1 | stdout EMPTY | "mismatched envelope"
2+3 both at once (precedence)      | exit=1 | stdout EMPTY | "mixed document"   <-- precedence holds
    prefix nonce (no startswith)   | exit=1 | stdout EMPTY | "mismatched envelope"
    lookalike adjudication_nonce   | exit=1 | stdout EMPTY | "absent provenance"

• Three distinct reason strings — confirmed, three genuinely different categories observable through main(), not just three exit codes.
• "both 2 and 3 -> mixed document" precedence — confirmed, implemented as specified rather than left to code order.
• No document printed on any refusal — confirmed, stdout empty in all seven.
• No prefix matching, no invented nonce — confirmed. A marker nonce equal to the top-level minus its last character is refused; a lookalike adjudication_nonce key is not adopted; out["nonce"] == d["nonce"] is True.
• stage_complete as named booleans — accurate. nonce_established and every_finding_has_verdict are separate names, and the latter is read back off output_document rather than tracked as a parallel counter.

No defect found in the region declared sound.

Cross-PR dedupe — one root cause, and the fix belongs here

Diffed the three refs directly rather than trusting the table. The two guard sites are byte-identical on all three branches; only line numbers move as the file grows:

branch	re-run guard	manifest default
#264 …-nonce	:258	:474
#266 …-escalate	:327	:674
#267 …-dedupe	:388	:873

The base feat/review-agent-adjudication-run (#263) contains no occurrence of either — grep -c returns 0 — so the code originates here.

Fix on this branch. The stack is a true chain (#266's base is …-nonce, #267's is …-escalate), so one change propagates to both descendants on rebase. Patching #266 or #267 separately would create three copies of one guard and three chances to diverge. Counted once across the three PRs, not three times — #266 and #267 are blocked by inheritance, not by anything they introduced.

One note for the reviewer harness

Two verdict blocks were emitted across two comments, the second superseding the first (High -> Blocker). The second comment names the hazard itself. A gate scraping comments sees two authoritative-looking blocks with nothing to tell them apart — worth fixing in the harness rather than in the code.

Verdict

state	severity	file:line	summary
CONFIRMED	High	launchpad/review-agent/run_adjudication.py:258	Non-list stages bypasses the re-run guard and drops a blocked pre-flight so the document publishes complete at exit 0 (also :474); one root cause across #264/#266/#267, fix here
CONFIRMED	Low	launchpad/review-agent/run_adjudication.py:261	stages entry with a non-string name passes through unchecked; resolved by the same change

Handed 2 (3 in the review block). 2 confirmed, 0 refuted, 1 resolved (the by:agent label, present now). One severity moved down; none moved up.

🤖 Adjudicated by Claude Code (claude-opus-5) for @serina-mcfall. I authored none of these findings and none of the code under review; this pass was read-only.

[benmitchell11]

Independent pass (not the pipeline that left the earlier reviews on this PR), with extra attention to the nonce check per this PR's own subject.

Checked out feat/review-agent-adjudication-nonce and ran the suite: Ran 207 tests ... OK in a clean worktree.

The Blocker from the standing review (non-list stages silently discarded) is fixed on this branch's tip (57941045c), and I reproduced the exact bypass scenarios from that review against the real CLI myself rather than trusting the fix commit's message:

stages = {"0": {"name":"adjudication",...}}                    -> exit 1, refused (was: exit 0, guard bypassed)
stages = {"p": {"name":"preflight","status":"blocked",...}}    -> exit 1, refused (was: exit 0, blocked pre-flight dropped, published as complete)
stages = [{"name":"adjudication",...}]  (still-legal list case) -> exit 1, correctly refused as a re-run

_input_stages (run_adjudication.py:211-251) now raises StagesShapeError for a non-list container, a non-dict entry, or an entry with a non-string name, and both call sites (_check_not_already_adjudicated and the manifest builder) route through this one function instead of each having its own inline isinstance check — closing the "two independent readers, two independent ways to get it wrong" shape the original bug had. Regression tests exist for both scenarios (test_run_adjudication.py:811-880).

Nonce check itself (_verify_nonce, :270-327) — read through it looking specifically for a bypassable condition, per the task brief:

• Empty/falsy top-level nonce (including "") is refused before any comparison runs.
• Empty reports or any report with an unparseable completion_marker triggers "absent provenance" — can't skip verification by supplying zero reports.
• A non-string nonce that happens to be truthy (e.g. an int) can't accidentally match: the compared value is always the string parsed out of a report's completion_marker, so a type mismatch alone forces "mismatched envelope."
• Precedence (mixed document over mismatched envelope) is implemented as an explicit branch order matching the plan's stated rule, not left to happen to fall out of it.
• _check_not_already_adjudicated runs before nonce verification (a re-run is refused as a structural defect independent of whether the nonce happens to check out), and nonce verification runs before findings.validate (provenance gated before content) — both orderings are the ones the module docstring claims, confirmed by reading adjudicate() itself, not just the docstring.

I didn't find a bypass. Nothing else new to add beyond the standing review's own findings, which now read as resolved on this branch.

Not verified: no live-model dependency in this step.

[serina-mcfall]

The requested change has landed — flagging for re-review

@ciaran-slow's CHANGES_REQUESTED on this PR named one inherited Blocker: non-list stages silently discarded, with the instruction to "fix on #264's branch and let it propagate." That has happened.

The fix: 57941045c — "refuse a present-but-malformed stages manifest" — on feat/review-agent-adjudication-nonce (#264), merged forward through #266 (ec4dd4356) and #267 (965c2325b).

Independently confirmed, not assumed: @benmitchell11 re-ran the CLI probe on the chain tip rather than trusting the merge carried cleanly, and reported an object-shaped stages carrying a blocked pre-flight entry now exits 1 and is refused. 230 tests OK in a clean worktree.

Also resolved since that review: the cross-step notes drift @ciaran-slow flagged (four steps agreeing the field exists, none connecting them) — addressed on both ends, at 4a2bf04ba on #263 (documenting the deferral where the runner discards the key) and 05a960478 on #265 (adjudicator.md no longer mandating a channel the runner drops).

One further finding, fixed just now: @benmitchell11's pass also caught an out-of-ladder gap that both earlier review passes on this stack missed — _apply_severity_rerating's no-re-rating branch returned reported_severity without checking it, so a value that arrived illegal and that the judge agreed with was published untouched:

_apply_severity_rerating("x", "Info", "CONFIRMED", "Info", None, [])
  -> ('CONFIRMED', 'Info', None)

Reproduced before fixing. This is a plan-conformance gap rather than only defence-in-depth: STEP 6's own done-when names this exact case, and ADJUDICATION.md promises the guarantee holds on the effective severity. Fixed in c73a9ba73 on #266's branch — UNPROVEN, severity falls back to Blocker, reason names the refusal, nothing added to downgrades. Proved the new tests can fail: removing the guard on a scratch copy fails exactly the two new sub-cases while the legal-path control still passes.

Not claiming this clears the review — the merge decision is @ciaran-slow's. This is the evidence trail so re-review doesn't require re-deriving what changed.

A note on reading CI on this stack: each commit here carries two check runs — an earlier failure and a later re-run that passes (e.g. 04:57:41 failure, 05:13:52 success on 965c2325b). Filtering the rollup on "any failure" reports these PRs as red when the latest run per check name is green. Worth taking the newest run, not any run.

🤖 Posted by Claude Code for @serina-mcfall. Claude-only pass on the severity fix — no independent cross-model check on that specific commit.

[serina-mcfall]

Requested changes are done — but I am not the right party to certify it

Disclosure first: I wrote the commit that fixes this (57941045c, the current head). So this is a status report, not an independent review.

@ciaran-slow's change-request (2026-08-21T03:57Z) is stale — the head moved after it. What landed:

• The stages Blocker at :258/:474. Fixed: StagesShapeError is present at head (7 occurrences) via a single _input_stages reader that both sites call. Absent and explicit null stay legal; present-but-malformed is refused with exit 1 and no document.
• The Low at :261 — non-string name — closed by the same change.

Re-verified through the real CLI at this head: an adjudication entry inside an object container exits 1 (was exit 0), a blocked pre-flight in an object container exits 1 rather than being silently discarded (was published as complete), a scalar stages = 42 is refused, and both controls still behave — a well-formed list preflight survives in order, absent stays legal.

One deliberate departure from the review: the severity was adjudicated down from Blocker to High. Both "breaks a stated rule" arguments turned out not to hold — the plan's "cannot inherit a guarantee it did not watch being made" sits in the nonce paragraph, and the stages paragraph calls stages the output #117 does not produce; the other candidate quote is a local docstring that doesn't exist on this branch. High still blocks a merge, so nothing operational changed. Recorded so the rating isn't taken as inherited.

What this needs: a re-review from @ciaran-slow rather than a clearance from me — I should not dismiss findings against my own fix. Re-requested.

This branch is the root cause for #266 and #267; both carry the fix by propagation rather than a second copy.