A finding is a hypothesis at the evaluator-fed fix stages

[aaddrick]

Depends on #162.

Problem

The two contrarian revision stages tell the model to verify a challenger's claim before acting on it:

• :4262-4264 "A challenger finding is a HYPOTHESIS, not a directive: verify each against the actual tree/state first. Adopt it if confirmed; REBUT it with concrete evidence if wrong. Do not capitulate to an unverified claim, gates oscillate precisely when a wrong Major is adopted without verification."
• :4403-4405 the same, plus a requirement to cite new evidence when overturning an adjudicated decision.

None of the fix stages carry it. They open with "Address code review feedback" and paste the reviewer's text.

There is also no way for a fixer to disagree. FIX_SCHEMA at :641 has status, commit, files_changed, fixes_applied, summary, error, notes_for_downstream. A fixer that believes a finding is wrong has only two moves: comply, or return status: 'error' and fail the issue.

This matters because reversals are majority-beneficial. In one decomposition of 58.19% "sycophantic" behaviour, 43.52% was movement toward the correct answer and only 14.66% away from it. A blanket never-comply rule would discard the majority that were corrections. The correct shape is evidence-gated, which is what settledBlock at :1861-1862 already asks for at the gates.

Scope: three stages, not five

Apply to the evaluator-fed fix stages, where the input is a judge's opinion:

• quality-fix :2957, fed rev.comments from a code-reviewer agent
• test-quality-fix :3479, fed v.comments from a test-validator agent
• pr-fix :4675, fed spec.comments and code.comments

Do not apply to the oracle-fed stages:

• test-fix :3430, fed t.failures from a real suite run
• browser-fix :3146, fed bw.failures from a real browser run

Both already carry an explicit anti-rebuttal guard ("Fix the real defect, do NOT delete or weaken assertions just to make the failure disappear"). Telling those fixers a failing test is a hypothesis inverts a correct guard. Grounding a gate in something checkable removes oscillation rather than reducing it, and a real failure is an absorbing boundary with nothing to negotiate.

Change

1. Lift the verify-then-adopt-or-rebut framing into a shared constant beside HANDOFF_ASK (:1867) and COMMIT_SHA_ASK (:1872), and use it at the three evaluator-fed stages only.
2. Add rebutted: [{ finding_id, evidence }] to FIX_SCHEMA, referencing the finding ids the dependency issue introduces.
3. Ship a deterministic consumer in the same issue. A prompt rule guarding a prompt rule is exactly the pattern docs/architecture/metrics.md records code review rejecting once already, and a real guardrail has to be deterministic. The rule: a fix returning rebutted.length > 0 && (fixes_applied || []).length === 0 records its own disposition, and on the final iteration of its gate forces carried-unresolved plus a Verification Gaps line rather than allowing an approval.

Prompt text, schema field, and JS rule ship together so the change reverts as a unit.

Explicitly not doing

The original draft also proposed stripping reviewer attribution ('Spec review:' / 'Code review:') from the text handed to fixers. That is dropped. The relevant finding endorses external attribution as one of its two acceptable options ("attribute externally, or strip attribution entirely"), what :4680-4681 does is external attribution, and no fix prompt contains authority framing today. Removing it would cost the fixer the ability to tell two reviewers apart for no measured benefit.

Acceptance criteria

• The three evaluator-fed stages carry the framing. The two oracle-fed stages do not, and their anti-rebuttal guards are untouched.
• rebutted entries require cited evidence; an entry with an empty evidence is treated as no rebuttal.
• The JS rule is unit-tested above the split marker.
• A fix stage that rebuts every finding and applies none terminates its gate as carried-unresolved with a Verification Gaps line, never as approved.
• A fix stage that rebuts some findings and fixes the rest proceeds normally.
• A fix stage that returns no rebutted field behaves exactly as it does today.
• node --test stays green. Extend tests/quality-loop.test.js, tests/pr-review-gate.test.js, tests/test-loop.test.js.

Documentation target

Document in CHANGELOG.md and in docs/architecture/gate-hygiene.md, adding its row to docs/architecture/index.md's file map if not already present.

Do NOT edit docs/architecture/pipeline.md, metrics.md, or failure-semantics.md. Their moved prose is hash-frozen by tests/architecture-provenance.test.js, and since the tech-docs stage runs at :4707, after the last test-loop execution, a frozen-prose edit surfaces only as a red CI check on the batch PR. New pages are authored text and are explicitly allowed; see docs/architecture/CLAUDE.md.

[aaddrick]

Ticketmill Claimed

batch: Batch_2026-07-28_134922
run: 2026-07-28-gate-hygiene-t2
host: tanngrisnir
started: 1785261199
Queued in an active ticketmill run — will be processed even if work has not visibly started (concurrency queue). Claims older than 12h are stale.

[aaddrick]

Starting Automated Processing

Batch integration branch: Batch_2026-07-28_134922

Pipeline: research → evaluate + contrarian → plan + contrarian → tasks with quality loops → tests → docs → PR → review → merge

[aaddrick]

Evaluation: Best Path

Complexity: standard. One file's control flow at three call sites, one schema field, one shared prompt constant, one metrics counter, plus tests and an authored doc section. The shape is well precedented: #162 added normalizeFindings/findingsBlock and the findings_empty_exits counter the same way, and #163 added the quality gate key to recordGateOutcome the same way. Behaviour risk is real but bounded, and every piece is unit-drivable through tests/harness.js.

Recommended approach

Build directly on #162's machinery. Five pieces, one commit.

1. FINDING_HYPOTHESIS_ASK, a shared constant beside HANDOFF_ASK (:1882) and COMMIT_SHA_ASK (:1887). Same *_ASK naming, same placement. Wired into exactly three prompts: quality-fix-* (:2938), test-quality-fix-i* (:3435), pr-fix-i* (:4823). The two oracle-fed stages are not touched and keep their anti-rebuttal guards verbatim. The text carries four clauses:

• verify each finding against the tree before acting; fix it if confirmed
• if it is wrong, do not change code to satisfy it, record it in rebutted with the concrete check that disproves it (file:line, command output, test result)
• list every fix you did make in fixes_applied, and rebut only findings you did not fix
• state the consequence plainly: rebutting everything and applying nothing ends this gate for human review

The fourth clause is deliberate. An undisclosed trap on a new schema field is a field models trip by accident.

2. rebutted on FIX_SCHEMA (:463). {type:'array', items:{type:'object', required:['finding_id','evidence'], properties:{finding_id:{type:'string'}, evidence:{type:'string'}}}}. Not in FIX_SCHEMA.required, matching how issues stays out of REVIEW_SCHEMA.required: a fix that omits the key entirely is byte-for-byte today's behaviour.

3. normalizeRebuttals(raw, findings), a pure helper beside normalizeFindings (:2051), above the harness split marker. Non-array in, [] out. Drops any entry with a blank finding_id or a blank evidence (the acceptance criterion that empty evidence is no rebuttal). Drops any finding_id that is not in the id set actually rendered to that fixer, which for pr-fix is the union of specFindings and codeFindings. Every drop fails toward today's behaviour, so an invented id cannot be used to exit a gate. Consequence worth stating up front: when a reviewer omitted issues entirely there are no ids, so no rebuttal validates and that path stays exactly as it is today.

4. The deterministic rule, uniform across all three gates. rebuttalOnly(fix, findings) is true when normalizeRebuttals(...).length > 0 && (fix.fixes_applied || []).length === 0, the issue's own predicate. When it fires, the gate ends there:

• record recordGateOutcome(ctx, gate, [], 'carried-unresolved'). Empty findings array at the quality and pr-review gates because that iteration's findings were already tallied a few lines above as re-litigated, and passing them again would double the count and severity columns. The test gate has no recordGateOutcome call today, so there it records the iteration's vFindings under a new test-quality key, which is purely additive to computeGateYield's by_gate rollup.
• push one VERIFY_SKIPS line naming issue, gate, iteration and the rebutted ids, so it lands in the batch PR's Verification Gaps section.
• pushDecision the rebuttal with its evidence. This is free reuse: decisionChain(ctx) is already in the quality review (:2907) and both PR reviewers' prompts (:4729, :4749), so the evidence reaches the humans and the reviewers rather than dying in the response object. Test validation does not render the decision chain, so at that gate the evidence reaches the record only.
• exit through each gate's existing non-clean path, adding no new terminal state: quality breaks unapproved, which returns 'degraded' and is non-fatal to the issue (callers only branch on 'halted'), exactly like the existing cap exhaustion; test-quality returns {ok:false, error:...} into the caller's existing needs_human handling; pr-review sets haltReason and breaks into the existing if (!approved) return fail(ctx, 'needs_human', ...), so the PR is left open and never merged.

Uniform beats per-gate special cases here. "Fires on the last iteration only" needs three different definitions of last (quality MAX_QUALITY_ITERATIONS, test MAX_TEST_ITERATIONS at 10 which is effectively unreachable, and pr-review MAX_PR_REVIEW_ITERATIONS - 1, since capReached breaks before the fix stage ever runs), and it leaves the actual hole open: a rebuttal-only pr-fix on iteration 2 sends an unchanged tree back to reviewers who can approve it on iteration 3 and merge. Ending the gate at the rebuttal closes that with one rule instead of three.

5. New counter ctx.metrics.rebuttal_only_exits, mirroring findings_empty_exits. tests/harness.js's freshMetrics() must be updated in the same commit or tests/harness.test.js's parity check goes red.

Rationale

The gap the issue names is real and asymmetric. Three fix stages are handed a judge's opinion with no instruction to check it and no field to disagree in, so the only in-schema move is compliance. Adding the framing without the field would produce a fixer that verifies, concludes the finding is wrong, and then has to comply anyway or fail the issue. Adding the field without a consumer would produce a prompt rule guarded by a prompt rule, which docs/architecture/metrics.md records code review rejecting once already. Shipping the three together is what makes the change revert as a unit and behave as one.

Grounding the escape hatch in evidence rather than permission is what keeps the reversal statistics on the right side. Partial rebuttal plus real fixes proceeds untouched, which is the common and correct case. Total rebuttal with zero changes is the one shape where the engine has a validator saying one thing, a fixer saying the opposite, and nothing in the tree that changed to adjudicate between them. That is not something the engine can settle, so the correct terminal state is a human with the evidence in front of them, not an approval.

Risks

• New hard-fail path at the test gate. {ok:false} there fails the issue to needs_human, where the quality gate's equivalent is non-fatal. A chatty validator plus a confident fixer can now stop an issue that would previously have merged. Mitigated by the id-matching and evidence requirements, and it fails safe (open PR, gap line) rather than merging something unverified.
• Disclosing the consequence cuts both ways. Telling the fixer that rebut-all escalates may suppress honest rebuttals, or invite lazy ones. Silence is worse: an undisclosed trap on a brand new field gets tripped by accident. Worth watching in the run ledger via rebuttal_only_exits.
• fixes_applied is not required by FIX_SCHEMA. A fixer that applies real fixes, omits the array, and rebuts one finding would trip the rule. Mitigated in the prompt clause that makes fixes_applied mandatory whenever anything was fixed. Adding (files_changed || []).length === 0 to the predicate would harden it further but would also let a fixer touch one unrelated file to slip the guard, so the issue's literal two-term predicate stands.
• Lockstep. workflows/ticketmill.js and .claude/workflows/ticketmill.js must stay byte-identical or scripts/lint-engine.js fails the whole test command. Sync with node scripts/lint-engine.js --fix, never by hand-editing the copy.
• Frozen prose. Documentation goes in CHANGELOG.md and a new authored section in docs/architecture/gate-hygiene.md, whose index.md row already exists and needs its wording refreshed. pipeline.md, metrics.md and failure-semantics.md stay untouched; their prose is hash-frozen and tech-docs runs after the last test-loop pass, so a violation only shows up as a red check on the batch PR.
• Engine size. The engine is under a 512 KiB launch cap. Long rationale belongs in docs/architecture/engine-internals.md with a one-line pointer at the code, per the existing convention.

Alternatives rejected

• Fire only on the gate's final iteration. Three incompatible definitions of "final", and it leaves the pr-review approve-an-unchanged-tree hole open.
• A fifth disposition value such as rebutted. computeGateYield buckets four names and the Gate Yield renderer just gained its Re-litigated and Carried columns in df44b9d. A fifth value would tally into gate_findings and then be silently dropped from every rollup, so it would need two more consumers widened for no gain over carried-unresolved, which already means the gate did not settle.
• Apply the framing to all five fix stages. Inverts the correct anti-rebuttal guard at the two oracle-fed stages. A failing test is not a hypothesis.
• Prompt text plus schema field, deterministic consumer deferred. A prompt rule guarding a prompt rule, already rejected once in this repo's own review history.
• A dedicated rebuttalBlock() feeding rebuttals into the next review round. Real value, but pushDecision plus decisionChain already delivers it at two of the three gates for free. Worth a follow-up issue for the test gate, not this one.
• Strip reviewer attribution from fix prompts. Already dropped in the issue body, and correctly: external attribution is one of the two endorsed options and it is what the fixer uses to tell two reviewers apart.

[aaddrick]

Contrarian: Approach Challenge (Iteration 1)

Verdict: needs_rework — the shape is right, three exit-path details are wrong. Every finding below is a bounded correction inside the proposed design, not a call to redesign it.

Strengths (steel-man)

The asymmetry the approach builds on is real and correctly drawn. Oracle-fed fixers get a failing assertion; evaluator-fed fixers get an opinion, and FIX_SCHEMA (:463, required: ['status','summary']) gives them no way to say "I checked, it's wrong" except status:'error', which fails the issue. Keeping rebutted out of required mirrors REVIEW_SCHEMA.issues exactly, so an omitting fixer is byte-identical to today — that is the right no-op discipline, and normalizeRebuttals dropping unknown ids means an invented id can never open a gate. Refusing to add a fifth disposition is also correct: computeGateYield (:5399) buckets exactly four names, so a fifth would tally into count and vanish from every column. Rejecting the literal "final iteration" wording is well argued — capReached at :4788 does break before pr-fix ever runs, so a literal reading is unimplementable at that gate. And the pure helper lands at :2051, comfortably above the split marker at :6487, so all of this is unit-drivable.

Findings

[Major] The test gate's exit is not "needs_human handling" — it fails the issue as failed, before a PR exists

• Assumption challenged: that {ok:false} from runTestLoop lands in the caller's needs_human path.
• Failure scenario: :4652 reads const tl = await runTestLoop(ctx); if (!tl.ok) return fail(ctx, STOP.tripped ? 'halted' : 'failed', 'test-loop', tl.error). Status is failed, stage is test-loop, and the PR stage runs after the test loop — so a test-validator/fixer disagreement over hollow assertions discards a complete implementation with no PR open, filed under a stage name that says the suite broke. The second call site is worse: :3555 is the mandatory post-rebase re-run inside runMergeAutoResolve, whose caller (:4898) renders mandatory post-rebase test loop failed: <rebuttal text> and blocks the merge of an already-approved PR.
• Impact: the softest of the three gates gets the harshest terminal state, mislabeled, and a new way to strand an approved PR at the merge boundary.
• Recommendation: return a distinguishable shape ({ok:false, rebuttal:true, error}) and branch it at :4652 to fail(ctx, 'needs_human', 'test-quality', …). Better still, given no PR exists yet: at this gate record carried-unresolved plus the VERIFY_SKIPS line and return {ok:true}, letting the disagreement surface at the PR gate where a human is already reading. Either way, do not route it through 'test-loop'.

[Major] "Quality breaks unapproved, same as cap exhaustion" has no correct implementation as written

• Assumption challenged: that runQualityLoop has one non-clean exit. It has two, and they differ.
• Failure scenario: a bare break leaves approved=false, degraded=false, which falls into :2977's if (!approved && !degraded) and pushes a fabricated quality gate capped at 5 iterations without a clean review line into the batch PR body after one iteration. Setting degraded = true instead avoids that but does what cap exhaustion explicitly does not: ctx.degrades.push(true) at :2988 feeds the rolling window, so three rebuttal-only exits across an issue's tasks (window 5, max 3) return 'halted', and :4638 converts that into fail(ctx,'halted','quality-loop', 'quality degrade rate exceeded … systemic problem, human review required') — an honest, evidence-backed rebuttal reported as engine-wide degradation.
• Impact: either a false verification-gap line on every fire, or a mislabeled issue-level halt on the third.
• Recommendation: add a third loop flag (let rebutted = false) that exits the loop, is excluded from ctx.degrades, suppresses the :2977 cap branch, and still returns the 'degraded' string. Also worth stating plainly in the doc section: at this gate "left for human review" means the issue still merges with a VERIFY_SKIPS line, exactly like cap exhaustion — the strong human-review guarantee only holds at pr-review.

[Major] The predicate fires on schema-legal output that applied real fixes

• Assumption challenged: that fixes_applied is a reliable proxy for "changed nothing". It is not in FIX_SCHEMA.required.
• Failure scenario: a fixer commits three real fixes, rebuts one finding with evidence, populates files_changed, and omits fixes_applied — fully schema-valid. rebuttalOnly fires, the gate ends, and at pr-review that is fail(ctx,'needs_human',…) on an issue whose work was actually done. The approach's stated mitigation is a prompt clause, i.e. a prompt rule guarding the deterministic rule — the pattern the issue itself cites docs/architecture/metrics.md as having rejected. The counter-argument for omitting files_changed (a fixer could touch one unrelated file to slip the guard) does not hold: omitting rebutted is a strictly easier evasion available today, so the conjunct costs nothing against an adversary and buys real protection against a forgetful one.
• Impact: the one component in the design that does not fail toward today's behavior, at the gate with the most expensive exit.
• Recommendation: rebutted.length > 0 && (fixes_applied||[]).length === 0 && (files_changed||[]).length === 0. Place the check after each site's existing !fix || fix.status === 'error' guard so a dead or erroring stage keeps its current path, and cover the omitted-fixes_applied-with-files case explicitly in the tests.

[Minor] The framing is rendered even when no finding ids exist

• Failure scenario: when a reviewer omits issues, normalizeFindings returns null and findingsBlock renders prose with no ids. The constant still tells the fixer to record rebutted with a finding_id; anything it invents is dropped by normalizeRebuttals, so a fixer that verifies and disagrees applies nothing, the rule cannot fire, and the gate re-reviews an unchanged tree until it caps — the oscillation the issue is trying to remove, on the one path where today's behavior was supposed to be preserved.
• Recommendation: render the constant conditionally on findings !== null at all three sites, so the prose path stays byte-identical.

[Minor] pushDecision is the wrong channel for the evidence, and it does not reach the reviewers

• Failure scenario: decisionChain (:1833) elides the middle when d.length > 12, keeping the first 4 and last 6 — by PR-review time on a multi-task issue, a quality-gate rebuttal is exactly what gets elided. And at the gate that fires, the loop ends, so no further reviewer round runs there at all; the claim that the evidence reaches "the humans and the reviewers" holds only for a quality-gate rebuttal later read at pr-review, and only if it survives elision. If it does not, the PR reviewers re-raise the same finding, pr-fix rebuts again, and the issue escalates a second time.
• Recommendation: use settleDecision alongside pushDecision. settledBlock (:1868) keeps the last 6, is rendered to the quality reviewer (:2908) and both PR reviewers (:4730/:4750), and already carries the "re-open only with new evidence" contract — it is the ledger built for exactly this.

[Minor] Two accounting defects in the gate tally

• Failure scenario: recordGateOutcome's disposition map counts how each gate iteration resolved (:2020). Recording carried-unresolved after the re-litigated call a few lines above books two dispositions for one iteration, so the Re-litigated and Carried columns added in df44b9d both increment for a single round. Separately, a test-quality key written only on the rebuttal-only path produces a Gate Yield row that exists exclusively when that gate fails: ratio —, carried-only, no denominator.
• Recommendation: pass the disposition through one call per iteration rather than adding a second, and either wire recordGateOutcome(ctx,'test-quality',…) at all four test-validation outcomes (approved / empty-findings / proceeding-to-fix / rebuttal-only — four one-liners) so the key has an honest denominator, or leave the test gate untallied as it is today.

What I am not challenging

The three-vs-five stage split, the reuse of carried-unresolved, the uniform fire-on-rebuttal rule over a per-gate "last iteration", and shipping prompt + schema + consumer as one commit are all correct and well evidenced. The rework is confined to how the rule exits each of the three gates and to one term in the predicate.

[aaddrick]

Revised Evaluation (after contrarian iteration 1)

All six findings verified against the tree before revising. All six confirmed, five adopted as written, one adopted in defect but implemented differently (stated below with the reasoning). The shape the contrarian endorsed is unchanged: three evaluator-fed stages, optional rebutted mirroring REVIEW_SCHEMA.issues, the uniform fire-on-rebuttal predicate, one commit.

What I verified

Claim	Verified at	Verdict
Test gate {ok:false} fails as 'failed' / 'test-loop', pre-PR	:4652-4653 fail(ctx, ..., 'failed', 'test-loop', tl.error)	confirmed
Second call site blocks merge of an approved PR	:3555 inside runMergeAutoResolve, caller :4897-4898 -> needs_human / merge-auto-resolve, message reads "mandatory post-rebase test loop failed"	confirmed
A bare break lands in the cap branch	:2977 if (!approved && !degraded) emits "quality gate capped at 5 iterations without a clean review"	confirmed
degraded = true feeds the degrade window	:2960 ctx.degrades.push(degraded), :2990-2995 halt, caller :4638-4639 labels it "systemic problem"	confirmed
fixes_applied is not required	FIX_SCHEMA.required = ['status','summary'] at :464	confirmed
Prose fallback has no ids	findingsBlock at :2073 returns bare prose when findings === null; normalizeRebuttals would drop every entry	confirmed
settledBlock is the better channel	:1867, last 6, rendered at :2908 (quality review), :4730 / :4751 (both PR reviewers), carries the re-open contract	confirmed
Double-booked disposition	recordGateOutcome at :2933 and :4790 fires before the fix stage; a second call per iteration inflates the disposition map against a per-iteration denominator	confirmed

I also checked the doc constraint I was going to rely on: docs/architecture/index.md's frozen segment is lines: 6 from # Ticketmill Architecture, which ends above the file map. Editing the gate-hygiene.md row is safe; AGENTS.md and CLAUDE.md in that directory are byte-identical twins and both need the same edit.

Revision 1: per-gate exits, each through that gate's own existing non-clean path

The old text said "uniform exit". That was the defect. The predicate is uniform; the exit is per-gate, and each one reuses a path that gate already has.

Quality (runQualityLoop). New third loop flag let rebutted = false, adopted exactly as proposed. It breaks the loop, degraded stays false so ctx.degrades.push(degraded) at :2960 records no degrade and ctx.metrics.quality_degrades is untouched, the cap branch becomes if (!approved && !degraded && !rebutted) so no fabricated "capped at 5 iterations" line is emitted, and the function still returns the 'degraded' string, which both callers (:4637, :4849) treat as non-fatal.

Test quality (runTestLoop). Adopting the contrarian's preferred option: record the Verification Gaps line and return { ok: true }. No {ok:false}, no new {rebuttal:true} shape, no branch at :4652, nothing routed through the 'test-loop' stage key. This mirrors the empty-findings exit five lines above at :3427-3433 byte-for-byte in structure, which is the established precedent for "this gate ended unresolved, non-fatally, and a human reads it in the batch PR body". It is also the only choice that is correct at the second call site: from :3555, {ok:true} means a test-quality rebuttal can never block the merge of an already-approved PR nor get rendered as a test-suite failure.

PR review (reviewAndMerge). Unchanged from the prior approach: set haltReason, break, fall into the existing if (!approved) return fail(ctx, 'needs_human', 'pr-review', haltReason) at :4853. The PR is left open.

Stated plainly in the doc section, because the prior write-up implied a guarantee it does not have: at quality and test-quality, "left for human review" means the issue still merges carrying a Verification Gaps line, exactly like cap exhaustion and the empty-findings exit. The strong guarantee, where rebuttal-only actually stops a merge, exists only at pr-review.

Revision 2: the predicate gains the files_changed conjunct

rebuttalOnly = normalizeRebuttals(fix.rebutted, findings).length > 0 &&
               (fix.fixes_applied || []).length === 0 &&
               (fix.files_changed || []).length === 0

I rejected this conjunct in the prior round on the grounds that a fixer could touch one unrelated file to slip the guard. That reasoning does not hold and I am withdrawing it. rebutted is not in FIX_SCHEMA.required either, so simply omitting it is a strictly easier way to reach the same normal-fix-round path, available today with no extra work. The conjunct therefore costs nothing against an adversary and buys real protection against the case that actually happens: a schema-legal fix that applied genuine changes and forgot to populate fixes_applied, which under the prior predicate would have had its work discarded and its gate terminated. Placed after each site's existing !fix || fix.status === 'error' guard. Tests cover the omitted-fixes_applied-with-files_changed case explicitly.

Revision 3: the framing constant renders only when findings exist

FINDING_HYPOTHESIS_ASK is now conditional on findings !== null at all three sites (at pr-fix, on specFindings !== null || codeFindings !== null). Asking for a rebuttal keyed to a finding_id when findingsBlock rendered bare prose asks for something the fixer cannot produce and normalizeRebuttals would silently discard. The prose path stays byte-identical to today.

Its consequence clause is also rewritten to one sentence that is true at all three gates: rebutting every finding while applying no fix ends this gate immediately, no further fix round runs, and the disagreement is recorded as an unresolved verification gap for a human. At pr-review that is a superset (the PR is also left open), so no gate is over-promised.

Revision 4: settleDecision alongside pushDecision

Adopted. decisionChain is elidable under its own 12-entry cap and carries no re-open contract, and at pr-review no further reviewer round runs at all, so the evidence would reach nobody. settledBlock keeps the last 6, is rendered to the quality reviewer and to both PR reviewers, and already carries the "re-open only with concrete new evidence" wording. Both are written: pushDecision for the narrative chain, settleDecision for the ledger that the next reviewer actually has to argue against. Noted risk below about the 6-entry window.

Revision 5: gate tally accounting

The 'test-quality' key is dropped entirely. The test gate is untallied today and a key written only on the rebuttal path would have no honest denominator; wiring all four validation outcomes is a separate change and out of scope here.

At quality and pr-review the double-book is real and is fixed, but not by the contrarian's literal remedy. "One call per iteration" is not reachable at these two sites: the tally at :2933 and :4790 necessarily fires before the fix stage runs, so the disposition is booked before the information exists, and moving it below the fix stage would drop the tally on the fix-died and cap-reached paths that currently depend on it. Instead I add a small pure helper beside recordGateOutcome:

retypeGateDisposition(ctx, gate, from, to)

which moves exactly one already-booked disposition from one bucket to another, no-op if the key or the source bucket is absent or zero, never touching count or severity. Net dispositions per gate iteration stays exactly 1, which is the invariant the finding is protecting, and the iteration reads carried-unresolved, which is what the issue's acceptance criteria ask for. Unit-tested above the split marker. This is the one place I diverge from the proposed remedy, and I am flagging it rather than quietly substituting it.

Unchanged from the prior approach

Single commit in workflows/ticketmill.js plus the byte-identical lockstep copy via node scripts/lint-engine.js --fix. Three evaluator-fed sites only (quality-fix :2938, test-quality-fix :3435, pr-fix :4823); the oracle-fed test-fix and browser-fix keep their anti-rebuttal guards untouched. rebutted added to FIX_SCHEMA but not to required. Pure normalizeRebuttals(raw, findings) beside normalizeFindings, every drop failing toward existing behavior. New ctx.metrics.rebuttal_only_exits with tests/harness.js freshMetrics() updated in the same commit, since tests/harness.test.js enforces parity. Tests extend tests/quality-loop.test.js, tests/test-loop.test.js, tests/pr-review-gate.test.js. Docs: CHANGELOG.md, a new section in docs/architecture/gate-hygiene.md, and the extended file-map row in index.md plus its AGENTS.md / CLAUDE.md twins; pipeline.md / metrics.md / failure-semantics.md stay untouched.

Residual risks

• Two of three gates end in a merge with a Verification Gaps line, not a block. Accepted deliberately and documented in plain words so the guarantee is not overread.
• settledBlock keeps only the last 6 entries, so a rebuttal recorded early could be evicted by later approach or plan settlements before the PR reviewers read it. Accepted: the Verification Gaps line is the durable record and is not elidable.
• retypeGateDisposition is new engine surface (roughly eight lines). Mitigated by being pure, above the split marker, and directly unit-tested.
• A fixer can still evade the rule by omitting rebutted, which is true today and unchanged by this issue. The rule catches honest disagreement, not concealment.

[aaddrick]

Contrarian: Approach Challenge (Iteration 2)

Verdict: needs_rework — five of six iteration-1 findings are correctly and verifiably closed. The sixth (my own settleDecision recommendation) was adopted as written and turns out to be wrong in a way that matters, and one consequence of the fire-on-first-rebuttal rule only became visible once that remedy was in place. Both remaining items are bounded corrections inside this design.

Strengths (steel-man)

I re-checked every revision against workflows/ticketmill.js at b591d71 rather than accepting the revision table.

• Quality exit (revision 1) is correct. :2869 really is for (let iter = 1; !approved && !degraded && iter <= MAX_QUALITY_ITERATIONS; iter++), :2977 really is if (!approved && !degraded), and :2960 really is ctx.degrades.push(degraded). A third rebutted flag that breaks, leaves degraded false, and gates :2977 is the only exit that avoids both the fabricated cap line and the :2991 degrade-window halt. Confirmed.
• Test exit (revision 1) is correct and is the stronger of the two options I offered. :3555 is runTestLoop(ctx, true) inside runMergeAutoResolve and :3556 renders mandatory post-rebase test loop failed: …. {ok:true} is the only return that cannot strand an approved PR at the merge boundary, and :3428-3433 is a byte-for-byte structural precedent.
• The files_changed conjunct (revision 2) is right. FIX_SCHEMA.required is ['status','summary'] at :464; fixes_applied alone is not a safe proxy.
• retypeGateDisposition (revision 5) is a better remedy than the one I proposed. recordGateOutcome at :2933 books carried-unresolved already when iter === MAX_QUALITY_ITERATIONS, and at :4790 capReached/bothNothingToFix both break before pr-fix runs — so a retype keyed 're-litigated' -> 'carried-unresolved' is a no-op exactly where it should be and net dispositions per iteration stays 1. Confirmed.
• A hazard I checked and cleared: buildGateStatePayload at :831 does (… o.settled …).slice(-6), which snapshots the array, so a settleDecision call made after postGateState(ctx,'pr-review-i'+iter) at :4798 cannot mutate ctx.gate_state_intent and cannot produce a false mismatch in verifyGateState's Report sweep. No finding there.
• Engine is 465,677 bytes against the 512 KiB launch cap — ample headroom for this change.

Findings

[Major] Writing the rebuttal to settleDecision tells the only remaining backstop that re-raising the finding is a process failure

• Assumption challenged: that settledBlock is a neutral, durable delivery channel for the evidence. It is not — it is an adjudication ledger with a suppression contract attached.
• Failure scenario: settledBlock (:1867) closes every render with Re-open a settled decision ONLY with concrete evidence not considered at adjudication … Re-litigating a settled decision without new evidence is itself a process failure. (:1876-1877), and that trailer applies to every entry in the block, so no wording of the entry itself can cancel it. It is rendered to the quality reviewer (:2908) and to both PR reviewers (:4730, :4751). Every existing settleDecision call site — consolidation :3816, approach :4324, plan :4476 — fires only when a challenge was accepted, i.e. an adjudicated outcome. A fixer's rebuttal is one party's unrebutted claim; the design itself books it as carried-unresolved, which means precisely "this gate did not settle." So the same change books the dispute as unsettled in the tally and as settled in the ledger. Concretely: task 1's quality-fix rebuts finding X and exits; task 2's quality reviewer and later both PR reviewers are handed X as adjudicated. Since quality and test-quality rebuttals still merge by design, pr-review is the sole backstop — and it is the reviewer being instructed not to re-litigate.
• Impact: a fixer can, in a single response, end its own gate and suppress the only mechanism that could have caught it being wrong. This inverts the intent of the issue, which is anti-oscillation, not anti-scrutiny. This is a defect in the remedy I recommended at iteration 1, not in the evaluator's adoption of it.
• Recommendation: keep pushDecision, drop settleDecision, and add a small contestedBlock(ctx) beside settledBlock (pure, above the split marker, same cost profile as retypeGateDisposition) rendered at the same three sites with inverted framing: "A fix stage contested this finding with the evidence below and changed nothing. This is UNADJUDICATED. If the finding still stands, re-raise it and address the cited evidence directly." That keeps the anti-oscillation value — the next reviewer must engage the evidence — without borrowing a contract the dispute has not earned.

[Major] At pr-review the rebuttal never reaches the reviewer who raised the finding, so the cheapest disagreement is escalated instead of settled

• Assumption challenged: that a rebuttal-only pr-fix is always a disagreement the engine cannot adjudicate. The most common shape of it is one the engine adjudicates for free.
• Failure scenario: the highest-frequency honest rebuttal is "this finding is already resolved / the reviewer read a stale tree." Today that round ends with the fixer saying so, the loop continues, iteration 2's reviewers see the current tree, approve, and the PR merges. Under the proposed rule the fixer populates rebutted (the new prompt clause instructs it to), rebuttalOnly fires, haltReason is set, and :4853 returns fail(ctx,'needs_human','pr-review',…). Revision 4 concedes the missing half itself: "at pr-review no further reviewer round runs at all, so the evidence would reach nobody" — so there is no path in this design where the reviewer that raised the finding ever sees the rebuttal and withdraws. The evaluation's stated reason for firing on any iteration was that "reviewers can approve an unchanged tree on iteration 3 and merge" — but reviewers approving after seeing a correct rebuttal is adjudication, not the hole.
• Impact: at the one gate with the expensive terminal state, the rule converts a routinely self-resolving round into a human escalation, and does so for the trigger most likely to occur. Note this is also the acceptance criterion the issue body actually asked for ("on the final iteration of its gate") and that I endorsed dropping at iteration 1 — the cost of that override lands exactly where the issue's own wording would have avoided it.
• Recommendation: bounded and naturally capped by the existing budget. MAX_PR_REVIEW_ITERATIONS = 3 (:52) and capReached breaks before pr-fix, so pr-fix only ever runs at i1 and i2. At pr-review only: on the first rebuttal-only round, record carried-unresolved + the contested block + the VERIFY_SKIPS line and continue with the rebutted ids stashed on ctx; halt to needs_human only when a later round rebuts an id already rebutted, or when the cap is reached. Worst case that is one extra review round. Quality and test-quality can keep the immediate exit — neither blocks a merge, so the cost of firing early there is a Verification Gaps line, not an escalation.

[Minor] The quality gate's Verification Gaps line will be chatty in exactly the way the engine already fixed once

• Failure scenario: runQualityLoop is called once per task plus once per PR-fix round — the comment at :2963-2976 says so and is why cap exhaustion writes through ctx.quality_cap_skip_index into a single rolled-up line. A per-fire VERIFY_SKIPS.push for rebuttal-only reproduces the exact defect that roll-up exists to prevent: a five-task issue can print five near-identical gap lines in the batch PR body.
• Recommendation: reuse the same idiom with its own index (ctx.quality_rebuttal_skip_index), accumulating the step labels and rebutted ids into one line per issue.

[Minor] Placing the predicate immediately after the status === 'error' guard skips the fabricated-SHA check and the handoff notes

• Failure scenario: collectNotes and collectPostedCommit run at :2953-2954, :3451-3452 and :4845-4846. collectPostedCommit is what pushes the posted commit SHA … does NOT exist in the worktree — possible fabricated SHA gap line (:3223). A rebuttal-only fix that nonetheless reports a commit SHA and notes_for_downstream loses both if the check short-circuits above them.
• Recommendation: put the rebuttalOnly branch after collectNotes/collectPostedCommit and before the gate's own bookkeeping. tallyTouches is a no-op under the predicate, so ordering costs nothing.

[Minor] The conditional render fixes the all-prose path but not the mixed one at pr-fix

• Failure scenario: specFindings !== null || codeFindings !== null renders the constant when only one reviewer returned structured issues. findingsBlock (:2073) then renders bare prose for the other, so the fixer is asked for finding_ids that exist for one reviewer only. Rebuttals aimed at the prose reviewer are silently dropped by normalizeRebuttals, restoring the oscillate-to-cap behaviour the conditional was added to remove — and if the fixer rebuts only the id-bearing reviewer while ignoring real prose findings, rebuttalOnly fires on a half-verified round.
• Recommendation: one clause in the constant: only findings rendered with an id prefix can be rebutted; anything without an id must be fixed or explained in summary.

What I am not challenging

Revisions 1, 2, 3 and 5 as verified above; the three-vs-five stage split and the untouched oracle-fed guards; rebutted staying out of FIX_SCHEMA.required; every normalizeRebuttals drop failing toward today's behaviour; dropping the test-quality gate key; the single-commit-plus-lockstep shape; rebuttal_only_exits with the freshMetrics() parity update; and the doc plan, whose index.md frozen-provenance safety I re-confirmed. The rework is confined to the evidence channel and to the pr-review exit timing.

[aaddrick]

Revised Evaluation (after contrarian iteration 2)

Verdict on the challenge: both majors confirmed and adopted, all three minors confirmed and adopted. One mechanism inside major 2 is rebutted and replaced, because the halt it specifies cannot fire.

Major 1 (settleDecision) CONFIRMED, adopted in full

Verified at head b591d71:

• settledBlock() (:1867-1881) closes with two fixed lines applying to every entry it renders: "Re-open a settled decision ONLY with concrete evidence not considered at adjudication" and "Re-litigating a settled decision without new evidence is itself a process failure."
• It is rendered to the quality reviewer (:2908), the spec reviewer (:4730) and the code reviewer (:4751).
• Quality returns 'degraded', which neither caller treats as fatal, and test-quality returns {ok:true}. Neither can block a merge. So the PR reviewers are the only backstop for a contested finding, and writing an unadjudicated fixer claim into settled would hand that backstop an instruction not to re-raise it. That is the exact inversion the issue is trying to prevent, and it also contradicts the carried-unresolved disposition the same code path books.

My iteration-1 recommendation was wrong. Revised:

• settleDecision is not called on this path at all. pushDecision stays.
• New pure contestedBlock(ctx) beside settledBlock, above the TICKETMILL-TEST-HARNESS-SPLIT marker, same shape and cost profile as settledBlock (last 6 entries, per-field slice caps, '' when empty so prompts stay byte-identical on every run with no rebuttal).
• Rendered at the same three sites, immediately after settledBlock and self-contained, because the two blocks land adjacent in the prompt and the contested block has to say plainly that its entries are not settled. Heading: contested findings, rebutted by a fixer, NOT adjudicated. Body per entry: gate, finding id, the fixer's evidence. Closing contract, inverted: no one has ruled on this; if you still believe the finding stands, re-raise it and address the cited evidence directly; a rebuttal you do not answer is not a resolution.
• ctx.contested is lazily initialized and read defensively ((ctx && ctx.contested) || []), following the documented ctx.quality_caps precedent at :2966-2972, so tests/harness.js's makeCtx() needs no change. Deliberately NOT added to the run record at :2700/:4963: durable visibility already comes from the decision chain, the gate_findings disposition bucket, and the Verification Gaps line.

Major 2 (pr-review ends on the first rebuttal) CONFIRMED, adopted, with one mechanism replaced

Verified: MAX_PR_REVIEW_ITERATIONS = 3 (:52), and if (capReached) { haltReason = ...; break } sits above the pr-fix stage, so pr-fix only ever runs at i1 and i2. Continuing after a rebuttal-only round costs at most one extra review round and stays inside the existing budget. The claim that the raising reviewer never sees the rebuttal is also correct: reviewAndMerge returns fail(...) from inside the loop.

Adopted at pr-review only. Quality and test-quality keep the immediate exit; neither blocks a merge, so a second round there buys nothing.

Rebuttal of the proposed halt condition. The challenge says: halt to needs_human "when a later round rebuts an already-rebutted id". That test can never fire. Finding ids are engine-assigned as source + '-' + (i+1) with the source string embedding the iteration (normalizeFindings(spec.issues, 'spec-i' + iter), 'code-i' + iter, :4780-4781). Round 2's ids are spec-i2-*/code-i2-*, disjoint by construction from round 1's spec-i1-*/code-i1-*. An id-equality halt would be dead code and the loop would fall through to the cap every time.

Replaced with a per-loop counter: at most ONE rebuttal-only round per reviewAndMerge call. A second rebuttal-only round halts to needs_human immediately. Since pr-fix only runs at i1 and i2, this is behaviourally what the challenge intended, and it is actually implementable. The rebutted ids are still stashed on ctx for the contested block and the Verification Gaps line; they are simply not the halt signal.

One thing the challenge did not name. The rebuttal-only branch must continue before runQualityLoop(ctx, 'pr-fix-i' + iter, ..., fix.files_changed) at the end of the loop body. With files_changed empty, runSimplify fails open (!Array.isArray || length === 0), so the full simplify/review loop would run against a tree the fixer did not touch, burning a whole quality gate and possibly manufacturing findings of its own.

Acceptance-criterion tension, stated openly rather than smuggled. The issue says "A fix stage that rebuts every finding and applies none terminates its gate as carried-unresolved with a Verification Gaps line, never as approved." Under the continuation, a rebuttal at i1 followed by two clean reviews at i2 ends the gate approved and the PR merges. I read the criterion's intent as: a rebuttal must never be self-approving. That intent holds exactly. The i1 round is booked carried-unresolved and keeps that bucket forever; the approval at i2 comes from two independent reviewers who were shown the contested block and the unchanged tree. The literal reading would instead escalate the single most common honest rebuttal ("already fixed", "you read a stale tree") to a human every time.

The residual risk is the reviewer capitulating in the other direction, approving because the fixer pushed back. Three mitigations, all deterministic:

1. The Verification Gaps line is written at the moment of the rebuttal and is never retracted, so the batch PR body shows the gap even on a merged PR.
2. The carried-unresolved disposition on that iteration is permanent in gate_findings and in the gate-state post.
3. The contested block's closing contract is the inverted one, not the settled one.

If the criterion is meant literally, say so on this issue and I will make the pr-review branch halt immediately like the other two; it is a one-line change and every other piece of this plan is unaffected.

Minor 1 (VERIFY_SKIPS chattiness) CONFIRMED, adopted

runQualityLoop runs once per task plus once per PR-fix round, which is why cap exhaustion writes through ctx.quality_cap_skip_index into a single rolled-up line (:2963-2987). A per-fire push at the quality gate reproduces exactly that. Adopting the same idiom with its own index: ctx.quality_rebuttals accumulates stepLabel plus the rebutted ids, ctx.quality_rebuttal_skip_index rewrites one line per issue.

At pr-review the lines stay un-rolled: pr-fix runs at i1 and i2 only and the second rebuttal-only round halts, so the per-issue bound is two lines, and each names a different round and a different outcome.

Minor 2 (predicate placement) CONFIRMED, adopted

Placing the branch immediately after the !fix || fix.status === 'error' guard would short-circuit collectNotes/collectPostedCommit at all three sites (:2952-2953, :3459-3460, :4845-4846), dropping handoff notes and, more importantly, dropping the posted commit out of probeCommitShas (:3202-3226). A fixer that applied nothing but posted a SHA anyway is precisely the case that check exists for. The branch now sits after collectNotes/collectPostedCommit and before the gate's own bookkeeping; tallyTouches is a verified no-op on an empty array (:1981-1987), so the ordering costs nothing.

Decision-chain ordering detail: at pr-fix, pushDecision(ctx, 'PR Review Fix (i' + iter + ')', fix.summary) at :4844 already fires for every non-error fix and renders the fixer's own summary, so the pr-review branch adds no second entry. Quality and test-quality have no such call, so their branches push one Gate: findings contested, none applied entry mirroring the existing Gate: no findings to fix entries at :2928/:3430. One decision entry per round at every site.

Minor 3 (mixed structured/prose path at pr-fix) CONFIRMED, adopted

specFindings !== null || codeFindings !== null does render the constant when only one reviewer returned structured issues, and findingsBlock(null, ...) renders bare prose with no ids (:2073-2077), so the fixer would be asked for finding_ids that exist for one reviewer only. One clause added to the constant: only findings rendered with a bracketed id can be rebutted, and anything without one must be fixed or explained in summary. True and harmless at all three sites, so no per-site variation.

Revised approach, consolidated

One commit in workflows/ticketmill.js plus the byte-identical lockstep copy via node scripts/lint-engine.js --fix.

1. FINDING_HYPOTHESIS_ASK beside HANDOFF_ASK (:1882) and COMMIT_SHA_ASK (:1887), wired into the three evaluator-fed fix prompts only (quality-fix :2938, test-quality-fix :3435, pr-fix :4823), rendered conditionally on findings being present, and carrying the id-prefix clause from minor 3. Oracle-fed test-fix (:3392) and browser-fix (:3164) untouched.
2. rebutted: [{finding_id, evidence}] added to FIX_SCHEMA (:463), not in required, mirroring REVIEW_SCHEMA.issues.
3. Pure normalizeRebuttals(raw, findings) beside normalizeFindings (:2051), above the split marker. Non-array to []; drop blank finding_id/evidence; drop ids absent from the rendered finding set. Every drop fails toward today's behaviour.
4. Uniform predicate rebuttalOnly = normalizeRebuttals(fix.rebutted, findings).length > 0 && (fix.fixes_applied || []).length === 0 && (fix.files_changed || []).length === 0, evaluated after collectNotes/collectPostedCommit at each site.
5. Per-gate exits through each gate's own existing non-clean path. Quality: third loop flag rebutted that breaks, leaves degraded false (so ctx.degrades, quality_degrades and the three-degrade halt at :2990 are untouched), gates the cap branch to !approved && !degraded && !rebutted so no fabricated cap line is emitted, still returns 'degraded'. Test-quality: mirrors the empty-findings exit at :3427-3433 and returns {ok:true}, never {ok:false}, so nothing routes through the 'test-loop' stage key at :4652 and the post-rebase call site at :3555 cannot be turned into a merge block. PR-review: books carried-unresolved, records the contested entries and the Verification Gaps line, and continues; a second rebuttal-only round sets haltReason and breaks into the existing if (!approved) return fail(ctx, 'needs_human', 'pr-review', ...) at :4853, leaving the PR open.
6. Evidence goes to contestedBlock, not settledBlock (major 1).
7. Gate tally: no new 'test-quality' key; at quality and pr-review a pure retypeGateDisposition(ctx, gate, from, to) moves exactly one already-booked disposition bucket to carried-unresolved without touching count or severity, keeping dispositions-per-iteration at exactly 1.
8. New ctx.metrics.rebuttal_only_exits, with tests/harness.js's freshMetrics() updated in the same commit (tests/harness.test.js enforces key-set parity).

Tests extend tests/quality-loop.test.js, tests/test-loop.test.js, tests/pr-review-gate.test.js, plus unit tests above the split marker for normalizeRebuttals, contestedBlock (including that it renders nothing when empty and that its closing contract is the inverted one), retypeGateDisposition, and the predicate, including the omitted-fixes_applied-with-files_changed case. New pr-review cases: continue-then-approve at i2, continue-then-second-rebuttal halts, and the quality loop does not run on a rebuttal-only round.

Docs: CHANGELOG.md, a new section in docs/architecture/gate-hygiene.md stating plainly that only pr-review blocks a merge and why the pr-review path continues where the other two exit, and the extended file-map row in docs/architecture/index.md plus its byte-identical AGENTS.md/CLAUDE.md twins. pipeline.md, metrics.md and failure-semantics.md untouched.

[aaddrick]

Contrarian: Approach Challenge (Iteration 3)

Verdict: needs_rework — both iteration-2 majors and all three minors are correctly closed and verified. Two new defects fall directly out of the iteration-2 remedies themselves: the pr-review continuation invalidated the prompt sentence that was engineered in revision 3 to be true at all three gates, and the contestedBlock that replaces settleDecision lands in front of a reviewer whose own standing instruction tells it to do the opposite. Both are one-clause prompt fixes inside this design; no structural rework.

Strengths (steel-man)

I re-checked every iteration-2 adoption against workflows/ticketmill.js at b591d71 rather than trusting the revision table.

• Major 1 (drop settleDecision) is correctly closed and my iteration-1 recommendation really was wrong. settledBlock (:1867-1879) closes with the fixed "Re-litigating a settled decision without new evidence is itself a process failure" trailer applying to every entry, and it renders at :2908, :4730 and :4751. Replacing it with a purpose-built contestedBlock carrying the inverted contract is the right call.
• Major 2 (pr-review continues) is correctly closed, and the evaluator's rebuttal of my proposed halt mechanism is right. Ids really are source + '-' + (i+1) with the iteration baked into source (:4780-4781), so round 2's ids are spec-i2-*/code-i2-*, disjoint by construction from round 1's. An id-equality halt would have been dead code. The per-loop counter is the implementable version of what I meant.
• The unnamed catch is real and load-bearing. runQualityLoop(ctx, 'pr-fix-i' + iter, …, fix.files_changed) at :4849 really does sit at the tail of the loop body, and runSimplify at :2867 fails open on an empty filesChanged, so a continue that did not precede it would burn a whole 5-iteration quality gate against an untouched tree. Good catch by the evaluator, not by me.
• Minor 2 (predicate placement) is verified. collectPostedCommit at :2953/:3451/:4846 is what feeds the fabricated-SHA gap line, and tallyTouches (:1981-1987) is a genuine no-op on an empty array, so the reordering is free.
• A hazard I checked and cleared: retypeGateDisposition mutates ctx.gate_findings, and postGateState(ctx, 'pr-review-i' + iter) fires at :4798 before the fix stage. But buildGateStatePayload (:816-834) embeds only schema/repo/issue/run/batch/epoch/write_seq/boundary/group_id/members/seeded_from/gate_budgets/settled — no gate_findings. A retype after the post is therefore invisible to the gate-state comment and cannot produce a false mismatch in the verify sweep. No finding.
• Doc plan re-checked: docs/architecture/gate-hygiene.md already owns a findings_empty_exits counter section (:192), so the new counter has an established home and metrics.md (which carries scoring weights, not a key inventory) is correctly left alone.

Adjudication you asked for

You asked whether the acceptance criterion "never as approved" is meant literally. It is not — read it as "a rebuttal must never be self-approving", which is what the continuation delivers. Keep the pr-review continuation. Finding 2 below is the price of that choice and must ship with it.

Findings

[Major] The consequence clause is now false at pr-review, and the approach does not say it was rewritten

• Assumption challenged: that revision 3's consequence sentence survived the major-2 remedy. It did not, and nothing in the consolidated approach revises it.
• Failure scenario: revision 3 set the clause to one sentence chosen precisely because it was true at all three gates — "rebutting every finding while applying no fix ends this gate immediately, no further fix round runs, and the disagreement is recorded as an unresolved verification gap for a human" — and justified it with "at pr-review that is a superset (the PR is also left open), so no gate is over-promised". Under the major-2 remedy that is exactly backwards at pr-review: the branch continues, a full spec+code review round runs at i2, and an approval there merges the PR. The consolidated approach's item 1 lists only the conditional render and the id-prefix clause from minor 3, so the shipped constant states something the engine does not do at one of its three sites.
• Impact: the deliverable of this issue is telling an evaluator-fed fixer the truth about what a rebuttal costs. A fixer told a rebuttal is terminal and human-escalating will do the thing the issue exists to prevent — comply with a finding it believes is wrong rather than pay a price it has been told is nuclear. The chilling effect lands hardest at pr-review, the one gate where the new machinery was deliberately made cheap.
• Recommendation: either give the constant a per-gate consequence string (it is already built per call site), or weaken the shared sentence to something true everywhere and stop asserting a mechanism: "A round that rebuts every finding and applies no fix never counts as resolving this gate — it is recorded as an unresolved verification gap that a human reads, and it can never approve this gate on your say-so." Drop "ends this gate immediately" and "no further fix round runs" entirely. Add a test asserting the rendered pr-fix prompt does not contain the immediate-exit wording, so the next revision cannot silently reintroduce it.

[Major] contestedBlock tells the sole backstop to re-raise; the same prompt already tells it not to

• Assumption challenged: that the inverted closing contract is sufficient to make the i2 reviewers actually re-raise a contested finding. Their own standing instruction, added long before this issue, pushes the other way.
• Failure scenario: :4757 in the code-review prompt reads verbatim 'Read issue and PR comments for context. On iteration 2+, do not re-flag issues already addressed or accepted.', and :4737 in the spec-review prompt reads 'own prior spec reviews — do not reverse a prior scope approval without new information.'. At i2 the code reviewer is handed a contested entry in which a fixer asserts it checked finding X and X is wrong. "Already addressed" is a natural reading of that assertion, and the two instructions sit in the same prompt with no precedence rule. The revised evaluation's own mitigation 3 for the acceptance-criterion tension is "the contested block's closing contract is the inverted one" — so the mitigation and the conflicting line are the two halves of the same prompt.
• Impact: this is the milder twin of the settledBlock defect I raised at iteration 2, on new evidence (:4757, not settledBlock), and it lands on the same target: since quality returns 'degraded' (non-fatal at :4638 and :4849) and test-quality returns {ok:true}, the pr-review reviewers are the only backstop for a contested finding. If they read the rebuttal as "addressed", i2 approves an unchanged tree and the PR merges — the exact capitulation the design named as its residual risk, delivered by a prompt line rather than by model weakness.
• Recommendation: one clause in contestedBlock's closing contract that names the conflict and resolves it: "A contested finding is NOT 'already addressed' — no code changed and no one has ruled on it. The iteration-2+ instruction not to re-flag addressed issues does not apply to anything in this block." Cheap, deterministic, and unit-testable as a string assertion in the contestedBlock test already planned.

[Minor] contestedBlock renders an opaque id with no statement of what was contested

• Failure scenario: rebutted entries carry only {finding_id, evidence}, so an entry renders as gate + spec-i1-2 + the fixer's evidence. The finding's own text is never stored — normalizeFindings output is a local at each call site and nothing persists it. At i2 a PR reviewer sees an id from a review round whose text lives only in a PR comment; across tasks it is worse, since task 2's quality reviewer sees quality-task-1-i1-2 with no summary and no comment to hunt for. A reviewer that cannot tell what was contested cannot meaningfully engage the evidence, which is the entire value proposition of the block.
• Recommendation: normalizeRebuttals already joins each finding_id against the rendered finding set to decide whether to drop it, so it has f.summary in hand at zero extra cost. Attach it to the normalized entry and render gate + id + finding summary + evidence, with the same slice caps settleDecision uses (:1861-1864).

[Minor] rebuttal_only_exits counts a round that is not an exit

• Failure scenario: after the major-2 remedy the first rebuttal-only round at pr-review continues the loop; only the second one exits. The counter therefore mixes two gate terminations with a non-termination under a name that asserts termination, and computeGateYield-adjacent reporting and mill-review trend reads will treat them as the same event.
• Recommendation: rename to rebuttal_only_rounds (one word, same parity update in tests/harness.js freshMetrics()), and say plainly in the gate-hygiene.md section that at pr-review the first increment is a continuation, not an exit.

What I am not challenging

The three-vs-five stage split and the untouched oracle-fed guards; rebutted staying out of FIX_SCHEMA.required (:464 confirmed still ['status','summary']); every normalizeRebuttals drop failing toward today's behaviour; the files_changed conjunct; the conditional render plus the id-prefix clause; the quality third-flag exit and the test-quality {ok:true} exit; retypeGateDisposition and the no-new-test-quality-key decision; the pr-review continuation and its per-loop counter; the VERIFY_SKIPS roll-up split (rolled at quality, un-rolled and bounded at two at pr-review); the single-commit-plus-lockstep shape; and the doc plan. The rework is confined to two prompt strings and two names.

[aaddrick]

Proceeding After Contrarian Cap (Approach)

the approach challenge hit its 3-iteration cap without full acceptance;
implementation continues with these unresolved caveats carried into the decision chain:
Both iteration-2 majors and all three minors are correctly closed and independently verified against workflows/ticketmill.js at b591d71 (settledBlock trailer at :1867-1879 and its three render sites; iteration-scoped finding ids at :4780-4781 making the proposed id-equality halt dead code; the runQualityLoop-at-:4849 continue catch; collectPostedCommit/tallyTouches ordering). I also cleared a hazard I went looking for: buildGateStatePayload (:816-834) carries no gate_findings, so retypeGateDisposition after postGateState cannot produce a false verify-sweep mismatch. Two new defects fall out of the iteration-2 remedies themselves. First, the pr-review continuation invalidated revision 3's consequence sentence ("ends this gate immediately, no further fix round runs"), which was chosen precisely because it was true at all three gates; the consolidated approach lists no rewrite, so the shipp