Summary / 14. Iterative repair / Document
Paper 2026-09-06
Shared copy: the operator's name and machine names are replaced by roles. Nothing else is changed.
Rendering…
# The Failed Attempt Is the Asset: Iterative Repair as the Minimal-Delta Repair Loop of a Weak-Model Coding Harness *Component 14 of 27 — Coding-Harness Program. This document specifies the iterative-repair stage. It sits directly AFTER component 13 (error interpretation), which converts the runtime's complaint into a grounded, provenance-backed diagnosis, and BEFORE the verification and repair-consolidation components, which judge whether a repair is actually good and then bank it. Where component 13 reads the failed attempt and names its cause, this component takes the diagnosis and acts — turning interpretation into the repair loop. The prior candidate is not thrown away; it is a partially-finished solution. This paper translates the program's thesis into the repair build contract: seed each round with the diff, the failure evidence, and the diagnosis; emit a minimal delta (repair, never re-roll); keep a failure-signature ledger so the harness learns from every failed attempt; and cap-and-escalate so a stuck loop thrashes its way to a better instrument rather than repeating a losing guess.* --- ## Abstract Iterative repair is the stage that converts component 13's diagnosis into action, and it is the component where the program's oldest temptation lives: the urge to discard a failed candidate and "try again." This paper argues that a failed attempt is the asset, not the garbage — that the run which failed, the evidence it produced, the diagnosis that named its cause, and the candidate that almost worked are all information a repair loop must spend rather than delete. The prior candidate is a partially-finished solution: it already encodes the correct approach at every site it did not touch, so the correct unit of repair is a minimal delta against it, never a from-scratch re-roll that throws the surviving correct code away. Each round is therefore seeded with the diff of the last patch, the failure evidence from components 11–12, and the diagnosis from component 13; the model emits a bounded, minimal repair that states exactly what the last patch fixed, what remains wrong, what evidence establishes both, and what it is not allowed to break; every failure signature is hashed into a ledger that records what fixed it so recurrence is recognized instead of re-debugged; and an attempt counter caps the loop and escalates to a stronger instrument — more evidence, a deeper diagnosis — rather than letting the same model thrash against the same wall. The paper reviews the repair literature across ten parts — REFINE as the anchor whose whole effect is iterative refinement [1], RePair's reward-critic-until-no-gain loop [2], DynaFix's dynamic search-space discipline [3], the validation-evidence study that measures what feedback actually buys [4], ChatRepair's conversational repair [5], TokenRepair's token-level deltas [6], the feedback-friction result that even near-perfect feedback is under-absorbed [7], CYCLE's revision-cycle analysis [8], Self-Refine [9], traceability and the art-of-repair budget results [10][11], multi-turn training [12], and the decomposition mention [13], beneath them the classical delta-debugging lineage of Zeller [14]. It derives seven design principles, then specifies a deterministic pipeline (D) with exactly one learned entry (L): seeding, ledger lookup, and the cap-and-escalate gate are deterministic software, and the single L entry is minimal-delta repair generation — the one bounded call in which the model decides what to change next. It closes with a recursive self-improvement protocol and a measurement plan whose honest instruments — the per-attempt resolve curve, delta minimality, the not-allowed-to-break regression guard, thrash rate, and ledger hit-rate — exist to keep the harness from declaring victory on a repair it never proved, or spinning forever on one that is not working. ## 1. Introduction The coding-harness program has, through components 01 through 13, assembled machinery that reads a repository, decomposes a request, generates and lands a patch, runs it under deterministic execution (component 11), records the run with instrumentation (component 12), and reads the failure like evidence — parsing, classifying, and causally diagnosing it into a provenance-backed artifact (component 13). Component 14 is where that machinery must finally do the thing the whole pipeline exists for: fix the code. And the moment it must fix code, it collides with the single most consequential design decision in the entire program — what to do with the candidate that just failed. The naive answer, the one every off-the-shelf loop takes, is to discard the failed candidate and generate again from the original problem statement, hoping this attempt is better. This paper argues that the naive answer throws away the most valuable object the harness possesses. A candidate that ran and failed has already paid the cost of discovering the repository's shape, the test's expectations, and the failing path; it encodes a correct approach at every site it did not touch. It is not garbage. It is a partially-finished solution, and the correct unit of repair is the smallest delta that moves it from failing to passing — never a re-roll that regenerates from scratch and throws the surviving correct code into the trash with the bug. The thesis of this paper is stated plainly. **The failed attempt is the asset, not the garbage.** A failed execution is information, and the prior candidate is a partially-finished solution: seed each round with the diff + failure evidence + diagnosis, emit a minimal delta (repair, not re-roll), keep a failure-signature ledger, and cap-and-escalate to stop thrash. And it carries a strong rule for Piper that governs this component's every design choice, stated verbatim: **Never say "that didn't work — try again"; say exactly what the last patch fixed, what remains wrong, what evidence establishes both, and what she is not allowed to break.** The rule is a compression of the whole component's discipline into one sentence of speech. "Try again" is the sound of a harness that has learned nothing from the failed attempt — it re-rolls, discarding the diff, the evidence, the diagnosis, and the partially-correct candidate, and hopes. The rule's four clauses are each load-bearing: *what the last patch fixed* forces the harness to credit the prior candidate's surviving correctness instead of deleting it wholesale; *what remains wrong* forces it to state the residual gap that the next delta must close; *what evidence establishes both* forces it to ground each claim in components 11–13's observed reality rather than the model's confidence; and *what she is not allowed to break* forces it to declare the boundary — the passing tests, the API contract, the behavior the task explicitly preserves — that the repair must respect, so a "fix" that breaks something it was never allowed to touch is caught before it is believed. Every design choice in Section 4 exists to make that one sentence mechanically true. The weak-model problem makes this the highest-leverage and the most failure-prone stage in the harness. Repair is where a weak model most wants to guess: it has already written one wrong patch, and nothing disciplines a model like a failure it cannot explain. The literature supplies the sobering frame. The most direct number is REFINE's: iterative feedback-refinement alone, without any of the scaffolding this harness adds, lifts SWE-bench Lite by +14.67 percentage points to 51.67% and SWE-bench Verified by +12.2%, an average improvement of roughly 14% — the entire gain coming from feeding the model its own failure and letting it refine rather than regenerate [1]. But the same literature warns that refinement is bounded by what the model does with feedback: the feedback-friction result shows that even near-perfect feedback is only partially absorbed by a self-repairing model [7], and the art-of-repair result shows that repair gains concentrate in the first few iterations and then saturate, so unbounded iteration is not more repair, it is thrash [11]. The discipline of this component is therefore double: *make the failed attempt spendable* so each round carries real information, and *make the loop stop* so that information is not burned on an infinite repeat of a losing guess. The two halves are the thesis's seed-each-round-and-minimal-delta on the one side and its failure-signature-ledger-and-cap-and-escalate on the other. The paper proceeds as follows. Section 2 reviews the repair literature in ten parts — the refinement anchor, the reward-critic loop, dynamic search-space, the validation-evidence measurement, conversational repair, token-level deltas, feedback friction, the revision-cycle study, honourable mentions, and the classical delta-debugging roots. Section 3 derives seven design principles. Section 4 specifies the architecture, labeling every node deterministic (D) or learned (L) and stating the invariant that the L column holds exactly one entry. Section 5 states the recursive self-improvement protocol. Section 6 gives the measurement plan. Section 7 concludes. ## 2. Related Work The literature divides into ten lines — the refinement anchor, the reward-critic loop, the dynamic search-space repairer, a validation-evidence measurement study, conversational repair, token-level deltas, the feedback-friction result, a revision-cycle analysis, honourable mentions, and the classical delta-debugging roots beneath them all. Each answers one question the iterative-repair stage must resolve: does iterating on one's own failure work, when does the loop stop, how much of the candidate does repair actually touch, what evidence separates useful feedback from noise, does conversation help, how small can a repair be, why do models under-absorb even good feedback, how do real repair loops spend their budget, what do the recent tools add, and what classical result makes the failed state the unit of analysis. ### 2.1 The anchor: REFINE **REFINE** (Pabba, Chen, Mathai, Chakraborty, and Ray, preprint, arXiv:2510.03588, October 2025) is the anchor for this component because its headline numbers are, quite literally, the thesis in arithmetic: an iterative feedback-refinement loop — generate, get feedback, refine, repeat — lifts SWE-bench Lite by +14.67 percentage points to 51.67% and SWE-bench Verified by +12.2%, roughly a 14% average improvement over the non-iterative baseline, with the entire gain attributable to the model refining its own prior output rather than regenerating from scratch [1]. The effect confirms the central claim this component rests on — the failed or suboptimal attempt is an asset, because the model that sees its own output plus feedback does materially better than the model that starts over. REFINE also supplies the caution the design must answer: if the gain comes purely from iterating, then the loop's stopping condition and its per-round information quality are what determine whether those gains compound into a working repair or decay into thrash — which is exactly the gap between REFINE's refinement and this component's seed-with-diff-and-evidence, ledger, and cap-and-escalate discipline. ### 2.2 RePair **RePair** (Zhao et al., first author Yuze Zhao, Findings of ACL 2024, arXiv:2408.11296) contributes the reward-critic form of the repair loop: a candidate is generated and then iteratively repaired under the guidance of a reward critic, on the CodeNet4Repair benchmark, and the loop is instructed to keep iterating until no further gain is observed or a maximum number of steps is reached [2]. RePair's iterate-until-no-gain-or-max-step stopping rule is the direct ancestor of this component's cap-and-escalate (P6): a repair loop needs an explicit, mechanistic stopping criterion rather than a model's sense that it is done, and it needs an upper bound so that a loop which is not converging cannot burn unbounded budget. The reward-critic mechanism is also the seed of this component's insistence that each round be judged on evidence (Section 6), because a loop that cannot tell whether its last delta helped cannot decide whether to continue — it can only thrash. ### 2.3 DynaFix **DynaFix** (Zhili Huang et al., eight authors, Chongqing University, preprint v1, arXiv:2512.24635, 31 December 2025) contributes the search-space discipline this component adopts as a principle rather than a luxury: a repairer that dynamically prunes and narrows the space it searches, rather than exploring the full space on every attempt. Its results anchor the effect at scale — 186 Defects4J bugs, roughly 10% over the prior state of the art, including 38 bugs previously unfixed, reached within at most 35 attempts while cutting the search space by roughly 70% [3]. The numbers matter to this component in two ways. The ~70% search-space cut is the quantified version of minimal-delta repair (P2): a repairer that spends its budget pruning the space it has already learned is wrong — rather than re-exploring it — does more with less. And the ≤35-attempt bound is the empirical warrant that a hard cap is compatible with strong results: 38 previously-unfixed bugs were reached inside 35 attempts, so a bounded loop is not a crippled loop, it is a disciplined one. ### 2.4 Validation Evidence **Validation Evidence** (Xiaonan Xu and Wenjing Wu, preprint, arXiv:2607.28871, July 2026) is the measurement study this component leans on for its sobering evidence section: it studies what validation and feedback evidence actually contributes during repair rollouts, over a corpus of 3,730 events drawn from 643 rollouts across 110 tasks, and reports two headline figures — 46.0% and 23.8% [4]. Its placement in this review, immediately after the failure-evidence machinery of component 13 and before the verification stage this component feeds, is deliberate: it is the study that asks whether the evidence a repair loop feeds back into its next round is being spent where it helps. The wide gap between its two figures is the standing caution that feedback is not uniformly valuable — some validation evidence materially changes a repair and some does not, and the harness that cannot tell the difference spends its budget on the noise. It is the empirical floor under this component's P4 (evidence establishes both) and its Section 6 instruments: a repair loop must be able to say which evidence moved the last delta, or it cannot know whether its next delta is informed. ### 2.5 ChatRepair **ChatRepair** (Xia and Zhang, ISSTA 2024, arXiv:2304.00385) contributes the conversational form of program repair, in which a repair is not a single generated patch but a conversation between the user and the repair system — the user reports the failure, the system asks for and consumes clarification, and the patch emerges from the dialogue rather than from a one-shot inference. Its results anchor the cost regime this harness operates in: 162 bugs fixed of 337 at a cost of roughly $0.42 per repair [5]. (A naming caution belongs in the same breath: the earlier "Conversational APR" work of 2301.13246 is a DIFFERENT paper and must not be conflated with or cited as ChatRepair [5].) Two lessons transfer. The per-repair cost of roughly $0.42 confirms that a repair loop can run cheaply enough to iterate many times within a budget, which is precisely why a harness can afford a cap of a handful of rounds rather than one lucky shot. And the conversational frame is the ancestor of this component's insistence that each round say exactly what remains wrong — a repair that states its residual gap in words is a repair that the next round can act on. ### 2.6 TokenRepair **TokenRepair** (Kong et al., SMU, arXiv:2511.18001, November 2025) contributes the token-level form of repair, and it is the strongest statement of this component's minimal-delta principle (P2) in the literature: instead of regenerating whole functions or files, the repair is expressed and constrained at the level of the smallest meaningful token deltas that move a failing program toward passing. Its results are reported as an 8.2–34.9% improvement range on Defects4J 1.2, with 88 of 139 bugs fixed [6]. The headline transfer is the discipline that a repair should be as small as the change that fixes the bug — the failed candidate is treated as mostly-correct and only the faulty residue is rewritten — which is TokenRepair's token-level granularity applied as a general rule. The 88-of-139 result also sets a sobering ceiling that no amount of delta-minimality removes: even a repairer that touches only the failing tokens resolves only a fraction of bugs, so the loop must be free to escalate (P6) when a minimal delta at the obvious site does not close the gap. ### 2.7 Feedback Friction **Feedback Friction** (Dongwei Jiang, Zhang, Wang, Andrews, and Khashabi, Johns Hopkins, arXiv:2506.11930) is the result that most disciplines this component's expectations, and its first author is Dongwei Jiang — the work must not be attributed as "Wang et al." The finding is blunt: even when a self-repairing model is given near-perfect feedback about what is wrong, it substantially under-absorbs that feedback — it does not reliably convert the correct diagnosis into the correct repair. Attempting mitigation through temperature escalation and rejection sampling helps, but does not close the gap [7]. This is the strongest available warrant for why this component refuses to treat "feed the failure back and refine" as sufficient (the REFINE baseline [1]) and insists instead on the structural mechanics of Section 4: the seed is not a sentence of feedback but a structured round record carrying the diff, the typed evidence, and the diagnosis; the delta is constrained to be minimal and boundary-respecting; and the loop is capped and escalated because a model that under-absorbs feedback will not converge by being given the same feedback a fifth time — it will need a stronger instrument. ### 2.8 CYCLE **CYCLE** (Ding, Min, Kaiser, and Ray, OOPSLA 2024, arXiv:2403.18746) contributes the revision-cycle analysis that connects this stage to the broader self-improvement program: it studies the cycles of revision — generate, critique, revise — that self-improving agents and models run, and analyzes where in those cycles effort is spent and lost. (A naming caution belongs here: "CIRCLE" attributed to Bouzenia and Pradel is a GHOST conflation and must not be cited; CYCLE is the real paper, and this is its correct authorship and venue [8].) For this component, CYCLE is the theoretical frame that a repair loop is itself a revision cycle, and that the cycle's quality is governed not by the model's willingness to keep revising but by whether each revision has access to the information that makes it a genuine step forward rather than a re-roll. It is the link that lets Section 5 treat this component's repair protocol as an instance of the program-wide recursive self-improvement protocol rather than a separate loop. ### 2.9 Honourable mentions The surrounding repair lineage contributes tools, budget facts, and training results without anchoring the component. **Self-Refine** (Madaan et al., NeurIPS 2023, arXiv:2303.17651) is the origin of the iterative self-refine pattern — generate, self-feedback, refine — reporting roughly 20% absolute improvement across 7 tasks, driven by intrinsic self-feedback with no oracle [9]; it is the ancestor every later refine loop refines, and the later no-self-correction results (which component 13 details) are the reason this component does not trust intrinsic feedback alone and grounds each round in observed evidence. **Traceability** (Ceka et al., ISSTA '26, arXiv:2506.08311) studies how repair relates to the candidates and feedback that preceded it, contrasting iterative-refinement agents (OpenHands, SWE-Agent, AutoCodeRover) with parallel-sampling agents (MASAI, Agentless); its finding that only MASAI refines across candidates is the caution that many "iterative" agents do not actually build on prior candidates, which is the precise failure this component's seed-each-round design exists to prevent [10]. **Art of Repair** (Vallecillos Ruiz, Hort, and Moonen, EASE 2025, arXiv:2505.02931) studies repair under a patch budget of 10 and finds the gains concentrate in roughly the first three iterations, then saturate — the empirical warrant for cap-and-escalate (P6), because unbounded iteration past the point of saturation is not more repair, it is thrash [11]. **Golubev et al.** (arXiv:2508.03501, preprint) take the multi-turn repair loop into training — applying rejection fine-tuning and DAPO to train a model on multi-turn repair for SWE, taking a Qwen2.5-72B from 11% to 39% on SWE-bench Verified — evidence that the loop this component runs at inference time is worth training into the model itself [12]. **MASAI** (Arora et al., arXiv:2406.11638, preprint — no formal venue, and must not be named as any conference) is the decomposition mention: its modular sub-agent design includes a dedicated repairer that acts on a prior candidate, which is why Traceability [10] singles it out as the agent that actually refines across candidates [13]. ### 2.10 Classical roots Beneath all of these sits the delta-debugging lineage of Andreas Zeller, and this component's entire posture — the failed attempt as asset, the minimal delta as the unit of repair — is Zeller's made into a repair discipline. Zeller's ESEC/FSE 1999 result, *"Yesterday, My Program Worked. Today, It Does Not. Why?"* (cited by lineage, DOI 10.1145/318774.318946, not on arXiv), introduced delta debugging: given a program that used to work and now fails, isolate the minimal change — the smallest delta to inputs, config, or state — responsible for the regression [14]. The name this component carries is inherited directly: repair is delta debugging run in the other direction. Where Zeller minimized the failing change to find the cause, iterative repair minimizes the repairing change to preserve the fix — and both rest on the same insight that the state between "worked" and "failed" is dense with information, and that the correct unit of analysis is the smallest meaningful difference, not the whole program. Every minimal-delta repair in Section 4 is a Zeller-style reduction applied to the candidate's correctness rather than to its failure. ## 3. Design Principles Seven principles follow from the review, each tied to the evidence above and each a clause of the strong Piper rule made mechanical. **P1 — Seed every round with the diff + failure evidence + diagnosis.** No round of repair is a fresh generation from the problem statement. Each round is seeded with the three things that make the failed attempt an asset: the diff of the last patch (so the model sees exactly what it already changed and can credit what survived), the failure evidence from components 11–12 (the typed observations of what actually failed), and the diagnosis from component 13 (the grounded root-cause hypothesis). REFINE's +14.67pp to 51.67% gain is the empirical warrant that a model iterating on its own output and feedback beats a model regenerating from scratch [1]; Traceability's finding that only MASAI actually refines across candidates is the caution that seeding must be structural, not hoped-for [10]. The seed is the round record, and a round without it is not a repair, it is a re-roll. **P2 — Emit a minimal delta: repair, not re-roll.** The unit of repair is the smallest delta that moves the candidate from failing to passing, never a from-scratch regeneration. The prior candidate is a partially-finished solution — it is correct at every site it did not touch, and a re-roll discards all of that surviving correctness along with the bug. DynaFix's ~70% search-space cut by dynamic pruning [3] and TokenRepair's 8.2–34.9% gains from token-level deltas [6] are the quantified warrants that smaller, targeted repair outperforms broad regeneration; Zeller's delta debugging is the lineage — minimize the change, whether to find the cause or to preserve the fix [14]. The delta is bounded and explicit, so downstream stages can audit exactly what changed rather than diffing two opaque generations. **P3 — State what the last patch fixed and what remains wrong.** Each round's output opens by crediting the prior candidate — what the last patch actually fixed — and then states precisely what remains wrong, the residual gap the next delta must close. This is the first half of the strong Piper rule made structural: never "that didn't work — try again," because that sentence throws away the diff and the progress. ChatRepair's conversational repair, where the residual problem is stated in words and the next patch consumes that statement [5], and the feedback-friction result that under-absorption is the failure mode [7], are the warrants: a repair that cannot say what remains wrong is a repair the next round cannot build on, and a repair that credits its own progress is a repair that stops re-rolling its own successes. **P4 — Ground every claim in evidence: what establishes both.** The rule's third clause — what evidence establishes both the fix and the remaining wrong — makes each round's two claims falsifiable. "Fixed X" and "Y remains wrong" must each point at the observed evidence from components 11–12 that establishes them — the passing test that now passes, the failing test that still fails, the traceback that moved, the value that changed. The validation-evidence study's gap between 46.0% and 23.8% is the caution that feedback is not uniformly valuable [4]; grounding each claim in evidence is how the harness tells the informative evidence from the noise. A round that asserts a fix or a residual gap it cannot support with evidence is a round the ledger and the gate reject, mirroring component 13's evidence-citation gate. **P5 — Keep a failure-signature ledger.** Every failure the loop encounters is hashed into a signature — the failure class, the message template, and the site — and the ledger records, for each signature, what the round tried and whether it worked. The ledger is what turns a repeated failure from a mystery into a lookup: when a signature recurs, the harness knows what has already been tried and what did not fix it, so it does not re-debug a bug it has already debugged. This is the memory that makes the failure-signature-ledger clause of the thesis concrete, and it is the mechanism by which the harness learns across rounds and across repositories (Section 5), rather than treating each failed attempt as an isolated event to be forgotten. **P6 — Cap-and-escalate to stop thrash.** The loop has a hard attempt cap, and when it is reached without resolution the harness does not let the model try the same kind of thing a fourth time — it escalates to a stronger instrument: more evidence from component 12, a deeper diagnosis from component 13, or a wider delta once minimal deltas at the obvious site have failed. The art-of-repair result that gains concentrate in the first ~3 iterations and then saturate [11], and DynaFix's ≤35-attempt bound on fixing previously-unfixed bugs [3], are the empirical warrants that a bounded loop is not a crippled loop; CYCLE's revision-cycle frame [8] is the theoretical one. Thrash is the specific failure — the same model, the same evidence, the same losing guess, repeated — and cap-and-escalate is the mechanism that converts a stuck loop into a prompt for a better instrument. **P7 — Declare and enforce the not-allowed-to-break boundary.** Each round declares, as part of its seed, what it is not allowed to break — the passing tests it must keep green, the API contract the task preserves, the behavior the request explicitly leaves alone — and the delta is validated against that boundary before it is believed. This is the fourth clause of the strong Piper rule made structural. A repair that fixes the target failure by breaking a passing test or an API contract is not a repair, it is a regression wearing a fix's clothes; the boundary is what lets the harness catch it. The boundary is enforced deterministically by the delta-validation stage (Section 4) against component 11's execution and the repository's existing tests, so the model never gets to declare success on a change that violates what it was told not to break. ## 4. The Architecture The repair loop is a sequence of stages; every node is labeled D (deterministic software) or L (a learned model). The invariant that governs the whole is: the L column contains exactly one entry, and every upstream and downstream step is deterministic software on CPU — a single weak-LLM minimal-delta-repair-generation call, with seeding, ledger bookkeeping, validation, boundary enforcement, and the cap-and-escalate gate all deterministic. The concrete inputs are the failed candidate, the diff of the last patch, the failure evidence from component 12, the diagnosis from component 13, and the declared not-allowed-to-break boundary; the output is a validated minimal-delta repair that the verification component judges. The flow, in the five deterministic stages (a) through (e) plus the one learned entry (L): 1. **(a) Round seeding and boundary assembly [D].** The failed candidate, the diff of the last patch, the typed failure evidence, and the diagnosis are assembled deterministically into a structured RoundRecord — the seed of the round. The record carries exactly: the candidate at its current state, the diff that produced it, the failing test(s) and their evidence, the diagnosis's root-cause hypothesis and its evidence citations, and the not-allowed-to-break boundary (P7). The seed is the failed attempt made spendable: the round never regenerates from the problem statement, it refines from this record (P1). The boundary is extracted deterministically from the task spec and the repository's passing tests — what must stay green — so the model never gets to choose what it is not allowed to break. 2. **(b) Failure-signature ledger lookup [D].** The current failure is hashed into a signature — failure class, message template, and site — and looked up in the failure-signature ledger (P5). If the signature recurs, the ledger returns what prior rounds tried and whether they worked, so the round is seeded with the knowledge that a given approach already failed rather than re-trying it blind. If the round count for this signature is at or past the cap, the ledger triggers the escalation path rather than permitting another attempt at the same level of evidence. The lookup is a deterministic hash-and-index; the model never reasons about whether it has tried this before, the ledger answers that. 3. **(L) Minimal-delta repair generation [L] — the single learned entry.** The weak model, seeded with the RoundRecord and the ledger's recurrence knowledge, emits a minimal delta: the smallest set of edits that moves the candidate toward passing, and nothing more (P2). Its output opens by crediting the prior candidate — exactly what the last patch fixed — then states exactly what remains wrong and what evidence establishes both, and closes by confirming the delta respects the not-allowed-to-break boundary (P3, P4, P7). This is the one place in the pipeline where a language model decides what to change; every other judgment about whether the change is legal, minimal, bounded, or recorded is deterministic. The model is not asked to judge its own repair, only to propose it. 4. **(c) Delta validation and boundary enforcement [D].** The proposed delta is validated deterministically before it is believed. It is checked for minimality (does it touch only the residue the diagnosis and remaining-wrong statement implicate, or is it a disguised re-roll that rewrites correct regions?); it is checked against the not-allowed-to-break boundary by running the boundary's passing tests under component 11's execution (did the delta keep green what it was told to keep green?); and it is checked against the failure evidence (does it plausibly address the diagnosed cause rather than a surface symptom?). A delta that breaks the boundary or rewrites correct code is rejected and fed back as a constraint violation — never silently accepted as a repair. 5. **(d) Ledger write-back [D].** The outcome of the round — the signature, the delta that was emitted, and, once verification returns, whether it resolved the failure — is recorded deterministically in the failure-signature ledger (P5). This is the mechanism by which the harness learns from every failed attempt, so that a failure which recurs in a later round or a later repository is recognized and met with the record of what has already been tried, rather than re-debugged from zero. 6. **(e) Cap-and-escalate gate [D].** The attempt counter is advanced and compared against the cap (P6). If the cap is reached without resolution, the gate does not permit a fourth attempt at the same level — it escalates deterministically: to component 12 for more evidence, to component 13 for a deeper diagnosis, or to a wider delta scope once minimal deltas at the obvious site have failed, and the escalated round is seeded afresh rather than repeating the exhausted one. Thrash is impossible by construction, because the gate is a counter, not a model's judgment about whether to keep going. The primitive set the harness exposes is deterministic except where noted: `assemble_round` (build the RoundRecord seed from candidate, diff, evidence, diagnosis, and boundary), `lookup_signature` (hash and index the failure against the ledger), `repair_minimally` (the single learned call emitting the minimal delta with its fixed/remains/evidence/boundary statement), `validate_delta` (check minimality and run the boundary's tests), `record_signature` (write the round's outcome to the ledger), and `attempt_gate` (advance the counter, cap, and escalate). The target is explicit and checkable: stages (a)–(e) are software on CPU, and the L column holds exactly one entry — the minimal-delta-repair-generation call that decides what to change next. Any proposed addition that would put a language model elsewhere in the pipeline — having the model judge its own repair, decide when to stop, or choose its own seed — is a regression against P1–P7 and must clear the same bar as in earlier components: beat the deterministic stage on the honest metrics of Section 6, on held-out repositories, at a defensible cost, or be rejected. The invariant is stated again so it can be enforced mechanically: **"the L column contains exactly one entry."** ## 5. Recursive Self-Improvement Protocol Component 14 of 27 follows the program's uniform protocol: the executable specification is written to 100%, round 1 lands at approximately 80% of the specified behavior, and later rounds close the gap. Each round is A/B-gated against the honest metrics of Section 6 — never the end-to-end resolve rate alone, which would let a lucky patch mask a badly-shaped loop. The three-way split that disciplines every change is the component-wide stance: semantic judgment goes to the LLM's single entry, mechanics go to deterministic software, and every change to either is A/B-gated on honest metrics, never on vibes. Because repair is the stage where the harness most wants to guess, its self-improvement protocol is built around measuring the shape of the loop rather than trusting its endpoint, and the machinery itself accumulates the knowledge that improves it in four concrete loops. First, *seed-quality tracking*: the harness measures whether richer seeds — the diff, the evidence, the diagnosis — actually move the resolve curve (Section 6's per-attempt metric), and tunes the seeding stage to spend the seed budget on the components that most improve each round, guided by REFINE's evidence that iteration is worth exactly as much as the feedback it consumes [1] and the validation-evidence study's warning that not all evidence is equal [4]. Second, *ledger growth*: the failure-signature ledger accumulates across rounds and across repositories, and the harness measures its hit-rate — how often a recurring signature is met with the record of a prior attempt rather than re-debugged — and feeds the ledger's successful repairs back as exemplars, so the loop literally gets better at its own bugs the more it repairs, which is the thesis's failed-attempt-as-asset made cumulative rather than per-round. Third, *cap-and-escalation calibration*: the harness measures the distribution of attempts-until-resolution and tunes the cap and the escalation thresholds against it — the art-of-repair saturation in the first ~3 iterations [11] and DynaFix's ≤35-attempt bound [3] are the empirical anchors — so the cap is set where further attempts stop paying and escalation fires when a different instrument, not another attempt, is what will resolve the bug. Fourth, *delta-minimality audit*: the harness measures whether its rounds actually emit minimal deltas or drift into disguised re-rolls, and tightens the delta-validation stage (stage c) to reject increasingly subtle rewrites of correct code, because a loop that re-rolls its own successes is a loop that has quietly abandoned the thesis it is supposed to embody. Because every round record is versioned and tied to the seed that produced it, a regression in repair behavior — more thrash, wider deltas, boundary violations — is visible in the repair logs long before it surfaces as a failed resolve, and each A/B change must justify itself on held-out repositories at a defensible cost before it ships. ## 6. Measurement & Evaluation Iterative repair is measured *separately* and *honestly*, because a stage whose whole purpose is to turn a failed attempt into a working fix can be defeated by the harness or the model declaring victory on a repair it never proved, or spinning forever on one that is not working. The instruments are built to keep the loop accountable to its own shape, not just its endpoint. **Per-attempt resolve curve.** The primary instrument reports, for each attempt number, the fraction of failures resolved by that attempt or earlier — the resolve rate as a function of repair budget. This is the honest measure of the loop, and it is what makes cap-and-escalate principled rather than arbitrary: if resolution concentrates in the first attempts and flatlines, the curve has shown where the cap belongs, echoing the art-of-repair saturation in the first ~3 iterations [11]. A loop whose resolve curve keeps climbing past the cap is under-capped; one that flatlines early is spending its budget on thrash, and the curve reveals which. **Delta minimality.** The companion instrument measures whether the emitted deltas are actually minimal — the fraction of the candidate the delta rewrote, the number of regions touched beyond the residue the diagnosis implicated, the incidence of disguised re-rolls that rewrite correct code. DynaFix's ~70% search-space cut [3] and TokenRepair's token-level gains [6] are the warrants that minimality is a measurable, improvable property, not an aesthetic. A loop whose deltas are small and targeted is repairing; a loop whose deltas rewrite whole functions is re-rolling, and the instrument says which, catching the silent abandonment of P2 before it becomes a habit. **The not-allowed-to-break regression guard.** The boundary instrument audits whether repairs kept green what they were told to keep green: every accepted repair's delta is re-run against the boundary's passing tests under component 11's execution, and any repair that broke a passing test or an API contract it was told to preserve is flagged as a regression-wearing-a-fix. This is the mechanical enforcement of P7, and it is the instrument that stops a repair loop from trading the target failure for a newly broken test — the failure mode that the resolve rate alone would cheerfully reward. **Thrash rate and escalation firing.** The loop-health instruments measure the pathologies the cap exists to stop: the thrash rate (attempts that repeat a prior losing guess at the same evidence level, detected via the ledger) and the escalation firing rate (how often the cap is reached and a stronger instrument is invoked). The feedback-friction result that models under-absorb even near-perfect feedback [7] is the standing warrant that a loop can repeat without learning, and the thrash-rate instrument is what surfaces it. A low thrash rate with a healthy escalation firing rate means the cap is catching stuck loops and routing them to better instruments; a high thrash rate means the seeding and ledger stages are failing to make each round a genuine step forward. **Ledger hit-rate.** The learning instrument measures the failure-signature ledger's value: of the failures that recurred across rounds or repositories, how many were met with the record of a prior attempt rather than re-debugged from zero, and how often the recorded prior attempt's successful delta was actually reused. This is the cumulative measure of the thesis — the failed attempt as asset banked across time rather than spent once — and it is what shows whether the harness is learning from its own repair history or forgetting each bug the moment it is fixed. A failure-mode audit closes the positive instruments by naming how a repair loop lies. *Re-roll-in-disguise* is when a "repair" regenerates broadly and rewrites correct regions, the minimality instrument catches; *fix-the-surface* is when the delta addresses the symptom but not the diagnosed cause, which the seed's evidence-citation discipline and the per-attempt curve (a shallow fix recurs next round) expose; *regression-wearing-a-fix* is when a delta resolves the target by breaking the boundary, the regression guard catches; *silent-repeat* is when the loop emits the same losing guess it emitted last round, the ledger and thrash-rate instruments catch; *infinite-refine* is when the loop never escalates and spins against the same wall, the cap catches; and *no-credit* is when the round discards the prior candidate's surviving correctness and re-rolls it, which the minimality instrument and the seed's fixed-claim audit catch. Each mode has a guard, and each guard is an instrument in this section, so the loop is measured on its shape as well as its endpoint. Two honest caveats close the section. First, the strong-model numbers of Section 2 — REFINE's +14.67pp to 51.67% [1], DynaFix's ~10% over SOTA and 38 new bugs [3], TokenRepair's 88 of 139 [6], Golubev et al.'s 11→39% multi-turn training [12] — will NOT reproduce on a weak model; they were achieved with strong models, and a weak-model harness should expect materially lower absolute resolve rates, which is precisely why its repair loop must lean on deterministic seeding, validation, ledgering, and cap-and-escalate to compensate for weak repair *judgment* with strong repair *discipline*. Second, all repair metrics must be reported on held-out and out-of-benchmark repositories, exactly as in the earlier components, so that a loop that has memorized a repository's bugs cannot score well without its deltas having been validated and its failures ledgered against evidence the harness actually ran. ## 7. Conclusion Iterative repair is the stage where the coding harness finally fixes code, and it is the stage where the program's oldest temptation lives — the urge to discard a failed candidate and "try again." This paper has argued that the temptation is the design error. The failed attempt is not garbage; it is the asset. The candidate that ran and failed has paid the cost of discovering the repository's shape and the failing path, and it is correct at every site it did not touch — it is a partially-finished solution, and the correct unit of repair is the smallest delta that completes it, never a from-scratch re-roll that throws the surviving correct code away with the bug. It has reviewed the evidence that makes this stance load-bearing — REFINE's +14.67pp to 51.67% from iterating on one's own output [1], DynaFix's ~70% search-space cut from dynamic pruning and its 38 new bugs inside 35 attempts [3], the validation-evidence study's warning that not all feedback is equal [4], the feedback-friction result that even near-perfect feedback is under-absorbed [7], and the art-of-repair saturation that makes unbounded iteration thrash [11] — and it has designed a loop that spends the failed attempt rather than deleting it: each round seeded with the diff, the failure evidence, and the diagnosis; each repair a minimal delta constrained by a declared not-allowed-to-break boundary; each failure signature recorded in a ledger so recurrence is recognized instead of re-debugged; and each loop capped and escalated so a stuck round becomes a prompt for a better instrument, not a fourth losing guess. The architecture is deterministic end to end with exactly one learned entry: the deterministic stages — round seeding and boundary assembly, failure-signature ledger lookup, delta validation and boundary enforcement, ledger write-back, and the cap-and-escalate gate — are software on CPU, and the single L entry is minimal-delta repair generation, the one bounded call in which the model decides what to change next. The principle that has governed every choice is the one with which this paper began and closes, stated as the strong rule for Piper: **Never say "that didn't work — try again"; say exactly what the last patch fixed, what remains wrong, what evidence establishes both, and what she is not allowed to break.** The harness seeds, validates, ledgerizes, and caps deterministically; the model contributes the one thing only it can — the judgment of what minimal delta moves the partially-finished solution to finished. Because for a weak model, the only repair worth believing is the one that built on what the failed attempt already got right, changed as little as possible, and broke nothing it was told to preserve. --- ## References 1. Pabba, Chen, Mathai, Chakraborty, and Ray. *REFINE.* Preprint, October 2025. arXiv:2510.03588. *(Iterative feedback-refinement anchor; +14.67pp to 51.67% on SWE-bench Lite, +12.2% on SWE-bench Verified, ~14% average improvement — refining one's own output beats regenerating from scratch.)* 2. Zhao et al. (first author Yuze Zhao). *RePair.* Findings of ACL 2024. arXiv:2408.11296. *(CodeNet4Repair; reward-critic-guided iterative repair; iterate until no gain or max step — the iterate-until-no-gain-or-max-step stopping rule is the ancestor of cap-and-escalate.)* 3. Zhili Huang et al. (eight authors, Chongqing University). *DynaFix.* Preprint v1, 31 December 2025. arXiv:2512.24635. *(186 Defects4J bugs; ~10% over prior SOTA; 38 previously-unfixed bugs; reached within ≤35 attempts; ~70% search-space cut by dynamic pruning — the quantified warrant for minimal-delta repair and bounded loops.)* 4. Xiaonan Xu and Wenjing Wu. *Validation Evidence.* Preprint, July 2026. arXiv:2607.28871. *(Measurement study over 3,730 events / 643 rollouts / 110 tasks; reports 46.0% and 23.8% — the caution that validation feedback is not uniformly valuable.)* 5. Xia and Zhang. *ChatRepair.* ISSTA 2024. arXiv:2304.00385. *(Conversational APR; 162 bugs fixed of 337 at ~$0.42 per repair. NOTE: the earlier Conversational APR at arXiv:2301.13246 is a DIFFERENT paper and must not be cited or conflated as ChatRepair.)* 6. Kong et al. (SMU). *TokenRepair.* November 2025. arXiv:2511.18001. *(Token-level repair deltas; 8.2–34.9% improvement on Defects4J 1.2; 88 of 139 bugs fixed — the strongest statement of minimal-delta repair.)* 7. Dongwei Jiang, Zhang, Wang, Andrews, and Khashabi. *Feedback Friction.* Johns Hopkins. arXiv:2506.11930. *(First author is Dongwei Jiang, NOT "Wang et al." Even near-perfect feedback is substantially under-absorbed by self-repairing models; temperature escalation and rejection sampling help but do not close the gap.)* 8. Ding, Min, Kaiser, and Ray. *CYCLE.* OOPSLA 2024. arXiv:2403.18746. *(Revision-cycle analysis. NOTE: "CIRCLE — Bouzenia & Pradel" is a GHOST conflation and must NOT be cited; CYCLE is the real paper with this authorship and venue.)* 9. Madaan et al. *Self-Refine.* NeurIPS 2023. arXiv:2303.17651. *(Origin of the iterative self-refine pattern; ~20% absolute improvement across 7 tasks; intrinsic self-feedback, no oracle.)* 10. Ceka et al. *Traceability.* ISSTA '26. arXiv:2506.08311. *(Iterative-refinement agents — OpenHands, SWE-Agent, AutoCodeRover — vs parallel-sampling agents — MASAI, Agentless; only MASAI refines across candidates.)* 11. Vallecillos Ruiz, Hort, and Moonen. *Art of Repair.* EASE 2025. arXiv:2505.02931. *(Repair under a patch budget of 10; gains concentrate in the first ~3 iterations then saturate — the empirical warrant for cap-and-escalate.)* 12. Golubev et al. *Multi-turn RL for SWE.* Preprint. arXiv:2508.03501. *(Multi-turn reinforcement learning for software repair via RFT + DAPO; Qwen2.5-72B from 11% to 39% on SWE-bench Verified.)* 13. Arora et al. *MASAI.* Preprint. arXiv:2406.11638. *(No formal venue — cite as a preprint, do not name a conference. Modular sub-agent decomposition with a dedicated repairer that acts on a prior candidate.)* 14. Andreas Zeller. *Yesterday, My Program Worked. Today, It Does Not. Why?* ESEC/FSE 1999. DOI 10.1145/318774.318946. Not on arXiv. *(Cited by lineage. Delta debugging: isolate the minimal change responsible for a failure — the minimal-delta ancestor of repair.)*