Context
The miner's create/iterate loop can produce multiple plausible candidate fixes for a claimed issue across iteration attempts, for example one worktree per attempt. Today the loop stops and submits as soon as it reaches an attempt it predicts will pass the gate, rather than comparing attempts against each other. A single accept-first-passing-attempt policy is a direct contributor to the documented number one strategic risk: it optimizes for gate-passing, not for value, and a fleet running this policy at scale is exactly the slop-at-scale failure mode the design invariants (value-weighted self-review, reward-MERGED-net-positive) exist to prevent. A naive pairwise LLM-judge comparison between two candidates is also known to be order-biased — the judge can favor whichever candidate is presented first — so a single comparison call is not trustworthy evidence of which candidate is actually better.
Goal
When more than one plausible candidate fix exists for a claimed issue, select the best one via a pairwise self-comparison judge call run twice with the candidates' presentation order swapped, and only trust a verdict that is stable under the swap.
Requirements
- Trigger the comparison step only when the create/iterate loop has produced two or more candidates that each independently pass the miner's own local pre-submission checks (not just the first one reached).
- Implement the comparison as a judge call scored against the value-weighted self-review criteria already established for miner self-review, not a new independent rubric.
- Run the judge call twice per candidate pair: once as (A, B) and once as (B, A); compare the two verdicts.
- If the verdict is stable under the swap (same candidate wins both orderings), select that candidate.
- If the verdict flips under the swap, treat the comparison as inconclusive: do not pick by default-first, fall back to a defined tie-break (for example, lowest-diff-size or earliest-attempt) and record the inconclusive result for observability.
- Bound the number of candidates carried into the comparison stage (a max fan-in) so the pairwise cost does not grow unbounded across many iteration attempts.
- Ensure this stage runs strictly before the Miner-Local Governor chokepoint, since Governor approval is for the single selected candidate, not for every candidate produced.
Deliverables
Expected outcomes
- Selected-candidate quality (measured via reward-MERGED-net-positive outcome tracking) improves relative to accept-first-passing-attempt baseline
- Order-flip rate is visible and trending measurable, giving a concrete signal for whether the judge call itself needs tuning
Context
The miner's create/iterate loop can produce multiple plausible candidate fixes for a claimed issue across iteration attempts, for example one worktree per attempt. Today the loop stops and submits as soon as it reaches an attempt it predicts will pass the gate, rather than comparing attempts against each other. A single accept-first-passing-attempt policy is a direct contributor to the documented number one strategic risk: it optimizes for gate-passing, not for value, and a fleet running this policy at scale is exactly the slop-at-scale failure mode the design invariants (value-weighted self-review, reward-MERGED-net-positive) exist to prevent. A naive pairwise LLM-judge comparison between two candidates is also known to be order-biased — the judge can favor whichever candidate is presented first — so a single comparison call is not trustworthy evidence of which candidate is actually better.
Goal
When more than one plausible candidate fix exists for a claimed issue, select the best one via a pairwise self-comparison judge call run twice with the candidates' presentation order swapped, and only trust a verdict that is stable under the swap.
Requirements
Deliverables
Expected outcomes