Summary / 09. Patch and code generation / Document
Paper 2026-09-06
Shared copy: the operator's name and machine names are replaced by roles. Nothing else is changed.
Rendering…
# The Constrained Repair: Bounded Candidate Generation, Semantic/Mechanical Separation, and Deterministic Edit Gates for a Weak-Model Coding Harness *Component 09 of 27 — Coding-Harness Program. This document specifies the patch/code-generation stage: the narrow, named semantic-transformation step in which, for the first time, the pipeline's accumulated precision is cashed into a concrete artifact — one or more candidate code changes. It sits after component 08 (context construction), which decided what of everything the pipeline knows the model sees for each decision, and before the components that execute, validate, and repair the generated candidates (10–11 and 17–18). It is the FIRST stage in the program whose output IS the artifact: every prior component — interaction, action selection, repository modeling, retrieval, localization, impact analysis, planning, and context construction — existed to bound this one, and every later component exists to check it. Generation is therefore a constrained phase with typed inputs and outputs, not an autonomous coding activity; it produces a bounded set of syntactically valid candidate changes and then stops, leaving execution and validation to the components downstream. It is written to drive a reversible build; the executable specification follows in a companion document.* --- ## Abstract Patch generation is the stage of the coding-harness program where intent becomes artifact: every earlier component bounded the problem — interaction, action selection, repository modeling, retrieval, localization, impact analysis, planning, and context construction — and here, at last, the model is asked to produce the code change those components exist to scope. This paper argues that generation should be a narrow semantic transformation stage, not an autonomous coding activity: the model should receive a precise change obligation assembled into an explicit intent package and emit several bounded repair candidates in the cheapest reliable edit representation; semantic repair should be separated from mechanical edit application; and deterministic syntax gates should reject malformed candidates before they consume downstream validation resources. Candidate generation is the one genuinely learned decision, and it is deliberately made narrow and resampleable; everything that turns a candidate into safe repository bytes is deterministic software on CPU. The paper reviews six lines of evidence — the constrained-repair result that generation is a bounded phase and not open-ended agency [1], the context-coupling decomposition that separates reasoning and inspection from edit execution [2], the semantic-sketch/mechanical-application cascade that keeps an expensive reasoning model from regenerating unchanged source [3], the feedback-bottleneck result of self-explanation and repair [4], the flow-engineering result that test-anchored staged generation beats a single well-designed prompt [5], and the outlier finding that the binding constraint may be the semantic specification rather than the generator [6] — together with the training-and-selection side that turns patch shape into a learned and verifier-scored commodity, honourable mentions, and the classical roots beneath them. It derives seven design principles and specifies an architecture in which every stage except a single learned candidate-generation call is deterministic software on CPU, so the L column holds exactly one entry and the generator's job is kept narrow enough for a weak model to perform. It closes with the recursive self-improvement protocol and a measurement plan whose key instrument is the resolve rate at a fixed candidate budget — candidates-per-resolved at bounded generation cost — because a generator that cannot be shown to beat a single greedy shot on resolve, without a cost regression, has not earned its candidate sampling at all. ## 1. Introduction The coding-harness program decomposes software engineering into a sequence of questions, and components 01 through 08 answered the opening eight: how to *interact* with code (01), how to *choose* an action (02), what the repository *is* (03), what context is *relevant* (04), *where the fault is* (05), *what an edit will break* (06), *in what order, against what checkpoints, the whole request should proceed* (07), and *what the model should actually see for its next decision* (08). This paper answers the question every earlier component has been quietly converging on: *what code change should the model actually propose?* Component 09, patch/code generation, is the first stage in the program whose output is the artifact — the candidate change that will be applied, executed, and validated — and every prior component existed to bound this one. Localization (05) decided where the fault lives; impact analysis (06) decided what an edit will break; planning (07) produced the change obligation, its acceptance criteria, and its required validation; context construction (08) assembled the exact window of evidence from which the change will be generated. Generation is where that accumulated precision is finally spent: the model is handed a precise change obligation and asked to emit one or more repair candidates in a form the harness can apply deterministically. And every later component exists to check this one: the execution and validation components (10–11, 17–18) will run the candidates against tests and requirements, and the repair loops will feed their failures back. Generation therefore ends, by design, at the production of a bounded, normalized set of syntactically valid candidates; it does not run tests, does not decide further actions, does not explore the repository, and does not choose among its own outputs. Its only product is the candidate set, and that discipline is what this component specifies. The central fact of the problem is that most of the difficulty of patch generation is organizational, not generative — and that naive picture of the stage as the most "LLM-ish" in the whole system is precisely what the evidence inverts. By the time localization, impact analysis, planning, and context construction have run, the model is no longer being asked to decide which file matters, which function is responsible, what the user actually wanted, or what downstream code might break; those questions were answered by components 05–08. The generation task has collapsed to something close to *transform this known location so it satisfies this stated requirement, preserving these constraints.* Agentless demonstrates how far that collapse alone goes: a simple, three-phase, non-agentic pipeline — localize, repair, validate — that never lets the LLM decide future actions or operate complex tools matched or beat far costlier agentic frameworks of its era on SWE-bench Lite, because its repair stage was boxed in with typed inputs and a fixed edit format rather than asked to improvise [1]. Yet the practitioner default still asks a model to solve the whole open-ended problem at once — to understand the task, understand the repository, construct a solution, remember the syntax of a diff, and locate exact source text all in one context window. SWE-Edit shows that this *context coupling* is itself a measured cause of failure, not a stylistic choice: forcing inspection, planning, and edit execution into a single window degrades edit reliability, and decomposing the interface into a Viewer and an Editor is worth over two points of resolve [2]. A second, reinforcing fact is that mechanical format failures masquerade as reasoning failures. A perfect localisation and a correct semantic plan are wasted by a malformed diff, a hallucinated context line, an off-by-one line number, or — the classic catastrophic failure — a whole-file rewrite that silently drops unrelated functions. The edit *representation* is a measured variable, not a fixed convention: models differ sharply in reliability across whole-file rewrites, line-numbered diffs, and search/replace blocks, and the same change is more or less appliable depending on how it is expressed [1][5]. A whole class of generation "failures" are in fact representation and application failures that no amount of reasoning ability fixes, because they are failures of the channel between the model's decision and the repository bytes. The implication for this component is that the LLM should decide *what the corrected code ought to mean*, and the harness should do as much as possible of turning that decision into safe repository bytes — a division of labour that Cascaded Code Editing makes explicit and that this paper elevates to a governing principle [3]. A third fact is that single-shot generation leaves easy wins on the table. A language model's output over a repair is a *distribution*, not a point: sampling the same intent several times and letting executable evidence discriminate among the samples reliably beats trusting one greedy completion, because the model has genuine variance across near-correct alternatives that a single greedy draw cannot explore. Agentless samples forty candidate patches per bug and lets regression and reproduction tests plus majority voting choose [1]; SWE-Gym shows that a trained verifier reranking candidate solutions keeps improving as both the sample count and the verifier improve [8]; AlphaCodium lifts GPT-4's pass@5 on CodeContests from 19% with a single well-designed prompt to 44% with a test-anchored, multi-stage flow [5]. For a weak model the lesson is stronger than for a frontier model: a weak model has less capacity to be right on the first draw, so the bounded-candidate mechanism — generate several, let evidence discriminate — is not an optional luxury but the primary route to adequate resolution. And the same logic that justifies sampling bounds it: because candidates are cheap and independent, the correct quantity to grow is the *diversity* of the candidate set under a budget, never the number of blind retries against an unchanged prompt. The thesis follows from these observations. **Patch generation should be a narrow semantic transformation stage, not an autonomous coding activity: once localization, impact analysis, planning, and context construction have produced a precise change obligation, the model should generate several bounded repair candidates from an explicit intent package; semantic repair should be separated from mechanical edit application; the cheapest reliable edit representation should be selected for the change's scope; and deterministic syntax gates should reject malformed candidates before they consume downstream validation resources. The LLM decides what the corrected code ought to mean; the harness does as much as possible of turning that decision into safe repository bytes.** The paper proceeds as follows. Section 2 reviews six lines of prior work plus the training-and-selection side, honourable mentions, and classical roots, each with its claims, numbers, venue caveats, and weak-model implication. Section 3 derives seven design principles. Section 4 specifies the architecture, labeling every node deterministic (D) or learned (L) and holding the invariant that the L column contains 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 six modern lines — a constrained-repair anchor, a context-coupling decomposition, a semantic/mechanical cascade, a feedback-bottleneck result, a flow-engineering result, and an outlier that relocates the bottleneck to the semantic specification — plus a training-and-selection side that treats patch shape and patch choice as learnable commodities, a set of honourable mentions, and the classical roots beneath all of them. Each modern line answers one question the generation stage must resolve: is generation a phase or an agent, how are reasoning and edit execution coupled, how is semantic intent separated from mechanical application, what makes repair loops work, does the structure around generation dominate the raw model, and what exactly is the generator being asked to reproduce. Six lines, presented below, are followed by the side literature and the roots. ### 2.1 The anchor and the constrained-repair lesson: Agentless **Agentless** [1] is the anchor for this component, and it appears here differently than it does elsewhere in the program, where it has been cited for its localization phase. The point for generation is how deliberately its *repair phase* is boxed in. Agentless is an agentless approach to automated software engineering built on a simple three-phase process — localization, repair, patch validation — *without letting the LLM decide future actions or operate with complex tools* [1]. By the time repair runs, the model's entire job is to emit a well-formed edit over the localized regions it is shown, with no tools and no wandering: the prompt carries the issue text, the localized code with line numbers, and the surrounding context, and the model asks for a patch in a fixed search/replace format *only* over those localized snippets, not whole files and not unified diffs [1]. The repair is two-round by design: an initial generation from issue and code, then — for failures — a second round that injects test information (failing-test output, regression results) as fresh context, so feedback enters as structured prompt material rather than as open-ended retrying [1]. The numbers anchor the argument that constraining the phase is a performance strategy, not just a safety one. Agentless reached 32.00% on SWE-bench Lite (96 correct fixes of 300) at an average cost of $0.70 per issue, matching or beating much costlier agentic frameworks of its era on a GPT-4-class base [1]. Its repair procedure is explicitly a *distribution to be aggregated*: the body draws four samples of edit locations per issue and, for each set, generates ten patches (one greedy and nine sampled at higher temperature) — forty candidate patches per bug in total — and then normalizes candidates (ignoring surface differences such as extra spaces, newlines, and comments) and selects by majority voting [1]. Two caveats from the primary source must be carried precisely. First, the ordering: the normalization and majority vote are the *final* re-ranking step, applied *after* the regression and reproduction-test filtering, not before testing, so the characterization "normalized, deduplicated, and majority-voted before any test runs" sometimes attributed to the paper is order-inaccurate. Second, the venue and cost: "NeurIPS 2024" is *not* stated in the arXiv record — the record and full text carry no venue — and while the $0.70 average per issue is confirmed in the abstract and full text, the often-repeated lower bound of $0.34 appears nowhere in the record and is unsupported [1]. The weak-model implication is the reason this component treats generation as a named stage with typed inputs and outputs rather than as a sub-case of open-ended agency. Generation inherits a decision that localization, impact analysis, planning, and context construction have already largely made; the residual inference problem is far smaller than the one agentic systems pose to the model, and a weak model is precisely the regime where shrinking the problem is worth more than improving the model. Agentless's more subtle gift is the candidate-set discipline: because a weak model is even less likely than a strong one to be right on a single greedy draw, treating the generator as a sampleable distribution and letting deterministic evidence choose among the samples is not an optional refinement but the structural answer to weak-model resolution. ### 2.2 The context-coupling fix: SWE-Edit **SWE-Edit** [2] contributes the decomposition this component is built around, and it is the most directly relevant modern paper for separating semantic reasoning from edit execution. It identifies a *context coupling problem*: the standard code-editing interface forces code inspection, modification planning, and edit execution into a single context window, so an agent must interleave exploratory viewing with strictly formatted edit generation — irrelevant context accumulates and edit reliability degrades [2]. Its fix is to decompose the editing interface into two specialized subagents: a *Viewer* that extracts task-relevant code on demand, and an *Editor* that executes modifications from high-level natural-language plans, letting the main agent focus on reasoning while delegating context-intensive operations to clean context windows [2]. On SWE-bench Verified this decomposition raises resolve rate by 2.1 percentage points (69.9% baseline to 72.0%), cuts inference cost by 17.9% ($243.7 to $200.1), and raises the edit-success rate from 93.4% to 96.9%, with consistent gains across reasoning-model families (Kimi-K2, MiniMax-M2.1, GLM-4.7) [2]. SWE-Edit's second finding is the one that elevates edit representation from a detail to a design variable: it shows that effective edit-format selection can be trained into a small model rather than requiring frontier-scale capacity — GRPO training on Qwen3-8B with an *adaptive find-replace / whole-file-rewrite policy* improves edit success by 12.5 percentage points and brings an 8B open-source editor to parity with GPT-5-nano on downstream SWE-bench resolve rate [2]. The numbers are confirmed against the primary source (69.9→72.0, $243.7→$200.1, edit-success 93.4→96.9 for the combined SWE-Edit configuration); the venue is not recorded in the arXiv record, though the affiliation and released repository are Microsoft's [2]. The weak-model lesson is twofold: separate the reasoning context from the edit context so that a weak main model is never also responsible for producing a correctly formatted mechanical edit, and treat *which* edit format to use as a decision that can be learned and scoped rather than fixed once. Both are forms of narrowing the single learned call. ### 2.3 The semantic/mechanical cascade: Cascaded Code Editing **Cascaded Code Editing** [3] goes one step further than SWE-Edit, and its argument names the economic reason a single LLM should not own both semantics and mechanics. It decomposes code editing into two stages: *edit-sketch generation*, in which a large model produces a concise sketch representing the requisite modification (the more challenging phase), and *edit-sketch application*, in which a smaller model integrates that sketch into the original code to produce the final edited output (the simpler phase) [3]. The motivation is direct and quantitative: an expensive reasoning model regenerating an entire modified file wastes the majority of its output tokens on unchanged source, while a smaller model can do the mechanical integration cheaply — but smaller models lack the long-context and cross-file comprehension that accurate sketch application requires, which is precisely the gap a fine-tuned application model closes [3]. The headline numbers, confirmed in the paper and its FSE 2026 acceptance comment, are: using DeepSeek R1 as the sketch-generation model with a fine-tuned Qwen2.5-Coder-14B for application improves Aider Pass@2 by 11.1% *relative* over direct DeepSeek R1 editing — that is +7.5 percentage points absolute (67.6 to 75.1) — while reducing execution time by 12.9% (27.31h to 23.80h) and cost by 18.7% ($6.54 to $5.32) [3]. The relative-versus-absolute reading matters and is stated precisely here to avoid the inflation a careless citation introduces. The core argument — an expensive reasoning model should not regenerate unchanged source — is the same argument this component makes about a weak model and its harness: the model's marginal intelligence should be spent on the semantic decision, and the mechanical turning of that decision into repository bytes should be delegated to the cheapest reliable executor, which in Piper's case is deterministic software rather than a second, smaller LLM [3]. ### 2.4 The feedback bottleneck: Self-Debug **Self-Debug** [4] contributes the generation-side lesson that repair should be scheduled as rounds with structured feedback between them — and the boundary on how far self-feedback can carry a weak model. The paper teaches a model to debug its own predicted program via few-shot demonstrations of *rubber-duck debugging*: without human feedback on correctness or error messages, the model investigates execution results and explains its generated code in natural language, identifies its own mistakes, and rewrites [4]. The numbers, confirmed against the primary source, are more precise than the popular summary: on the Spider benchmark, where there are no unit tests to verify predictions, self-debugging with code explanation improves the baseline by 2–3%, and improves accuracy on the hardest-level problems by 9%; on TransCoder and MBPP, where unit tests are available, it improves accuracy by up to 12% [4]. The frequently repeated claim of "+10+ percentage points across benchmarks" is an over-simplification — the double-digit gain holds only where unit tests exist — and the paper also shows the subtler result that gains sometimes appear *without* execution feedback, purely from self-generated explanation [4]. Two caveats are carried: the venue "ICLR 2024" is not stated in the arXiv record and should be treated as unconfirmed, and the double-digit framing above is scoped to test-bearing benchmarks [4]. The weak-model implication is a caution inside a principle. Self-explanation is a cheap context generator for the next attempt — a model that can describe what its own candidate is meant to do often surfaces a mistake before any executor runs — and that is valuable for a weak model that cannot afford blind retry. But self-feedback is bounded by the model's own diagnostic ability, which is precisely what a weak model lacks most, so the harness must supply the richer external feedback (failing-test output, error messages, lint findings) that makes each round informative rather than hopeful [4]. Generation should be scheduled as rounds with feedback between them, never as retries against an unchanged prompt. ### 2.5 The flow-engineering result: AlphaCodium **AlphaCodium** [5] contributes the structural claim that dominates the entire stage: generation quality is governed less by the raw model than by the *structure around* generation. Its framing, "from prompt engineering to flow engineering," proposes a test-based, multi-stage, code-oriented iterative flow in place of a single prompt: reason about the problem, reflect on test behavior, generate a candidate, run it against public and self-generated tests, fix, and repeat [5]. On the CodeContests validation set, the flow lifts GPT-4's accuracy (pass@5) from 19% with a single well-designed direct prompt to 44% with the AlphaCodium flow [5]. Two errors in the common secondary record must be corrected against the primary source: the arXiv identifier is **2401.08500**, not the 2401.01365 that sometimes appears (which resolves to an unrelated mathematics paper), and the authors are Tal Ridnik, Dedy Kredo, and Itamar Friedman of CodiumAI — the "Grozman & Konyushkof" attribution sometimes attached to the paper is wrong [5]. The weak-model implication is that a weak model's raw distribution can be converted into reliable output by the same machinery a strong model needs, only more so: if anchoring generation to tests and structuring it as a staged flow is worth 25 points of pass@5 for GPT-4, then the structure around generation is where a harness with a weak model should spend its design budget, because the harness cannot buy capability by prompting alone [5]. Flow engineering is the ancestor of this component's bounded-candidate-plus-evidence-discrimination design. ### 2.6 The outlier — the semantic specification is the bottleneck: PATCH **PATCH** [6] is the outlier in this group because it attacks a different question: *maybe the limitation is not the patch-generation model at all, but the semantic specification it is given.* PATCH argues that most LLM repair approaches feed the model primarily the buggy code snippet, and that this underspecifies the task. Its patch-generation stage instead augments the buggy code with *dependence context* and *programmer intent* — what the code is meant to do and what it depends on — before asking for the repair [6]. Drawing on bug-management practice, it decomposes bug fixing into four stages — bug reporting, bug diagnosis, patch generation, and patch verification — performed interactively by LLMs to simulate the collaborative behavior of programmers, and it implements the whole on the dialogue-based ChatGPT, evaluating on the BFP benchmark [6]. The venue is confirmed: the arXiv record's comment field carries "Preprint, to appear in the ACM Transactions on Software Engineering and Methodology (TOSEM)" [6]. The weak-model implication is the one this component adopts as a principle rather than as a mechanism: the difference between a bare "fix this buggy snippet" prompt and a structured intent package — the programmer intent, the target, the dependency context, the constraints, the required validation — is not merely "more context"; it is *intent-structured context* that tells the generator what the corrected code ought to mean, so the generator is not left to reconstruct intent from buggy source alone [6]. For a weak model, which has little spare capacity to reverse-engineer intent from a bug, handing it the intent explicitly is close to the whole battle. Component 09 inherits exactly this structure: the change obligation of component 07, the impact obligations of component 06, the curated window of component 08, and the requirements of the user request are assembled into the intent package that drives generation. ### 2.7 Training and selection Three papers sit on the side of generation rather than in its six core lines, and they answer the questions of *how a generator learns patch shape* and *how a set of candidates is chosen*. **SWE-RL** [7] trains the generator: its reward is a lightweight rule-based signal — the difflib.SequenceMatcher similarity between the generated patch and the real merged pull-request patch, with no execution feedback (and a −1 for an incorrectly formatted response) — making it scalable to the software-evolution record of open repositories, and the resulting Llama3-SWE-RL-70B reaches a 41.0% solve rate on SWE-bench Verified, the best reported for a medium (<100B) model and comparable to GPT-4o [7]. An affiliation caveat from the primary source: although most authors are Meta AI and the corresponding author is Meta, the *first* author, Yuxiang Wei, is at UIUC, so the attribution should name the first author's institution rather than the corporate majority; the NeurIPS 2025 venue appears in the PDF footer, not the arXiv metadata [7]. **SWE-Gym** [8] supplies the selection side: an outcome-supervised reward model trained on agent trajectories scores candidate *trajectories* (the problem statement, trajectory, and current git diff) so that best-of-N-style sampling at inference can pick a winner without running every candidate's tests — selection is reported as Best@k, not literally "best-of-N," and reaches 32.0% on SWE-bench Verified and 26.0% on Lite — and it shows that both more samples and a better verifier keep improving resolution, with the 32B verifier continuing to improve at k=8 where a 7B verifier plateaus after k=4 [8]. The framing nuance matters: the verifier scores trajectories rather than bare patches, but the essence holds — patch generation is really generation *plus* a ranking problem, and the ranker can be a separately trained artifact [8]. **Is Self-Repair a Silver Bullet for Code Generation?** [9] is the corrective to the "just iterate with feedback" reflex: holding compute fixed, self-repair's gains over plain resampling are often modest, vary a lot between subsets, and are sometimes absent, and the bottleneck is the *feedback* stage — models are much better at generating repairs from a good diagnosis than at diagnosing their own failures, and human-written feedback dramatically outperforms model-written feedback at the same repair step [9]. Its ICLR 2024 venue is confirmed by external indexes though not by the arXiv metadata, which carries none [9]. Together the three fix this component's stance: candidate shape is trainable with a cheap non-executable reward; candidate choice is a separable learned problem that scales with samples and verifier quality; and any repair loop is only worth its cost when the feedback it feeds on is rich rather than self-generated guesswork. ### 2.8 Honourable mentions Six recent works sharpen specific decisions without anchoring the component. **RepoCoder** (EMNLP 2023) is the repository-aware completion model — the same generator idea one level down, generation conditioned on retrieved cross-file context with the generation feeding retrieval back [10]. **Diff-XYZ** is a benchmark for code-diff understanding whose cross-format study is the cleanest confirmation that a patch's *output format* is itself a performance variable: search/replace representation performs best for larger models across most tasks while structured udiff variants are similar but slightly weaker, and smaller open models benefit little from any formatting choice — a result that interacts with model size and argues for measuring, not assuming, the edit representation [11]. **SWE-smith** scales the *training-data* side, synthesizing software-engineering task instances at scale — a dataset of 50k instances from 128 repositories, an order of magnitude larger than prior datasets, driving an open model to 40.2% Pass@1 on SWE-bench Verified [12]. **PAGENT** contributes a failure taxonomy of 769 wrong patches produced by seven top agents across 114 unresolved SWE-bench Lite issues, and one of its findings is often misstated: type inference is a major and deliberately chosen category, but it is *not* the leading one — shallow understanding of code context and architecture is (the most common failure pattern), while type and data-structure handling is the second category, and the paper itself says type is "not the most frequent failure pattern," so it should be described as a major, localized category chosen for tractability rather than as the top cause [13]. The **plastic-surgery hypothesis** (Barr et al., FSE 2014) — that most fixes are recombinations of code already present in the repository — quietly explains why retrieval-grounded generation works as well as it does: a generator that can pull the correct existing idiom out of context is largely recombining rather than inventing [14]. And **Behavioral Analysis of AI Code Generation Agents: Edit, Rewrite, and Repetition** is not a method but a field study of what generators actually emit in the wild: analyzing AIDev pull-request patches from Claude Code, Copilot, Cursor, Devin, and OpenAI Codex across five languages, it measures whether each agent edits or rewrites existing code via token-level similarity of added versus removed segments, and repetition via n-gram ratios and Shannon entropy, giving each agent a behavioural fingerprint — some are editors, some rewriters, some notably more repetitive — of exactly the kind that benchmark resolution rates hide [15]. It is an ACM/MSR 2026 paper (DOI 10.1145/3793302.3793605) and is *not* on arXiv. Together these are the reminder that "produces candidate code" and "produces code a maintainer will merge" are different objectives, and that the edit representation and the repository grounding are both measured levers. ### 2.9 The classical roots The modern lines rest on six classical results, cited here for lineage rather than numbers. **CodeT** (Chen et al., ICLR 2023) is the ancestor of generate-many plus test-based selection — the candidate-set discipline of P2 in its original form [16]. **"Can It Edit?"** (Cassano et al., 2024) is a benchmark of 105 instructed code-editing problems (corrective, perfective, adaptive) that established the open-versus-closed-model gap and released a permissively-licensed training dataset — the ancestor of measuring editing as a task in its own right, though not of comparing edit *representations* [17]. **Aider's edit formats** (Gauthier, 2023–24) are the practitioner benchmarks that made search/replace and unified-diff reliability a public, reproducible object of study [18]. **RepairAgent** (Bouzenia et al., 2024) is the LLM agent built around a repair-tool prompt stack, the ancestor of treating repair as a bounded tool-using phase [19]. **AutoCodeRover** (Zhang et al., 2024) supplies the clean two-stage localize-then-patch split that Agentless shares, the lineage of naming generation as its own stage [20]. And **SWE-agent** (Yang et al., 2024) — cross-referenced from context construction — contributes the edit-lint-and-revert guard, the apply-then-parse rollback discipline that becomes P7 in this component [21]. These six appear throughout the program's later components; here they are the substrate on which the constrained-repair architecture stands. ## 3. Design Principles Seven principles follow from the review, each tied to the evidence above. **P1 — Generation is a constrained repair phase, not exploration.** By the time generation runs, localization, planning, impact analysis, and context construction have already decided the file, the function, the requirement, and the impact; generation is a *named stage* with typed inputs and outputs whose only job is to emit a well-formed edit over the regions it is shown. Agentless is the warrant: a three-phase, non-agentic pipeline that never lets the model decide future actions or operate complex tools reached 32% on SWE-bench Lite by boxing repair into exactly this shape [1]. The residual inference problem — "transform this known location so it satisfies this stated requirement" — is dramatically smaller than the open-ended one an agentic system poses, and a weak model is precisely where shrinking the problem is worth more than upgrading the model. Generation does not run tests, does not choose among its own outputs, and does not wander; it produces candidates and stops. **P2 — A bounded candidate set plus evidence discrimination, never one greedy shot.** Generate N bounded candidates from the same intent and let executable evidence — parse validity, regression tests, reproduction tests, a verifier — choose among them, rather than trusting a single completion. Agentless's forty patches per bug with normalization and majority voting after test filtering [1], SWE-Gym's verifier that reranks sampled trajectories and keeps improving with sample count [8], and AlphaCodium's test-anchored staged flow that lifted GPT-4 from 19% to 44% pass@5 [5] are the joint warrant that the generator's output is a distribution to be aggregated, and the aggregation is where reliability comes from. For a weak model the warrant is decisive: it is even less likely to be right on the first draw, so the candidate mechanism is the primary route to adequate resolution, and the budget that governs N is set by cost and diversity, never by the hope that one more blind draw succeeds. **P3 — Semantic repair is separated from mechanical edit application.** The LLM decides *what the corrected code ought to mean*; the harness turns that decision into safe repository bytes. Cascaded Code Editing makes the split explicit — an expensive sketch generator produces the semantics, a cheap application model (here, deterministic software) integrates them — precisely so the expensive reasoning model does not regenerate unchanged source [3]. SWE-Edit separates the reasoning context from the edit context so a model is never simultaneously responsible for understanding, planning, and producing a correctly formatted edit [2]. The governing idea is that the model is good at the semantic decision and the harness is good at the exact bytes; do not force the model to solve both merely because conventional coding agents do. **P4 — The cheapest reliable edit representation is selected for the change's scope.** The edit format is a measured variable, not a fixed convention, and the default is search/replace over localized spans — the cheapest representation that applies and reparses reliably — with whole-file rewrite admitted only when the change's scope genuinely requires a structural rewrite. Agentless's search/replace-over-localized-snippets format [1], and Diff-XYZ's finding that format choice interacts with model size and reliability — the format is a measured variable — [11] are the warrant. Edit-representation selection is a deterministic classification of the change's scope, per SWE-Edit's learned adaptive find-replace/whole-file policy [2], rather than a per-candidate model choice. **P5 — Generation is driven by an explicit intent package, not a bare buggy snippet.** The model receives the programmer intent, dependency context, constraints, and validation obligations — not just the code to fix — so it does not have to reverse-engineer intent from buggy source. PATCH is the warrant: augmenting the buggy code with dependence context and programmer intent is its core intervention [6]. The intent package is assembled deterministically from the change obligation of component 07, the impact obligations of component 06, the curated window of component 08, and the user request, and it is what makes generation's input *intent-structured* rather than merely voluminous. **P6 — Feedback-iterated refinement with a cap; the feedback quality is the bottleneck.** Repair proceeds in rounds with structured feedback between them — a failure and its output become fresh context for the next round — never as blind retries against an unchanged prompt. Self-Debug's rubber-duck rounds show feedback-driven rewriting improves code accuracy, sometimes without execution feedback [4]; Is Self-Repair a Silver Bullet shows the gains are bounded precisely by the *quality* of the feedback, since models repair well from a good diagnosis and diagnose their own failures poorly [9]; AlphaCodium shows test-anchored iteration converts a raw distribution into reliable output [5]. The cap is structural: two to three rounds at most, each fed genuinely new information, then escalate to re-localization rather than thrash, because unbounded regeneration against a static prompt is the anti-Self-Debug. **P7 — Deterministic syntax and application gates reject malformed candidates before they consume validation resources.** A candidate that does not apply cleanly or does not parse is rejected by deterministic software *before* it is ever handed to the execution and validation components, and application is apply-then-parse with rollback on failure so a malformed edit never corrupts the repository. SWE-agent's edit-lint-and-revert guard [21] is the ancestor; the whole point is that mechanical format failures are caught at the cheapest possible stage, so the expensive downstream validation only ever sees syntactically valid candidates. This is what makes the distinction between semantic failure and format failure clean: by the time a candidate reaches validation, a format failure is impossible by construction. ## 4. The Architecture The pipeline 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 — a single learned candidate-generation call — and every upstream and downstream step is deterministic software on CPU.* The deterministic path is the default; the single learned call fires once, produces the bounded candidate set, and is then done — generation itself ends at the production of that valid, normalized set, and execution and validation belong to components 10–11 and 17–18. The concrete inputs are the precise change obligation and its validated context, already assembled by the earlier components: the target location and fault of component 05, the impact obligations of component 06, the change obligation, acceptance criteria, and required validation of component 07, and the decision window of component 08. The flow, from intent to candidate set: 1. **Intent-package assembly [D].** The change obligation, the target code, the requirement, the dependency context, the constraints, and the validation obligations — drawn from components 05, 06, 07, and 08 — are gathered into one typed *intent package*: target, requirement, dependencies, constraints, and required validation, each a structured field. This is P5 made concrete: the generator receives programmer intent plus dependency context plus constraints, not a bare buggy snippet [6]. Assembly is deterministic collection and normalization; nothing here invokes a model. 2. **Edit-representation selection [D].** The change's *scope* is classified deterministically — a localized edit (search/replace over a scoped span) versus a structural rewrite (a larger region or file) — and the cheapest reliable edit format for that scope is selected. Search/replace over localized spans is the default, per P4 and the evidence that it is the most reliably appliable representation for strong models [1][11]; structural rewrite is admitted only when the localized span cannot express the change. This is a deterministic classification, not a model choice, mirroring the adaptive find-replace/whole-file decision SWE-Edit trains into a small model [2]. 3. **Candidate generation [L].** *The single learned node.* The LLM emits N bounded repair candidates in the selected edit format, from the intent package, at a temperature greater than zero for diversity, in one logical call that produces N candidates. The output is schema-constrained — search/replace blocks with exactly the fields the deterministic applicator expects — so that the model cannot drift into an unappliable format. This is P1 and P2 together: the call is narrow (emit well-formed edits over known spans from a typed intent package), and it is sampled to produce a bounded set [1]. It is the sole entry in the L column, and it is deliberately the *only* learned step because every other operation in this stage is something deterministic software does more reliably and more cheaply than a weak model. 4. **Mechanical edit application [D].** A deterministic transformer applies each candidate to the repository bytes exactly as the edit format specifies — locating the search block, verifying it matches uniquely, and replacing it — then reparses the result. This is P3 made concrete: the harness, not the model, performs the byte-level transformation, so a correct semantic decision is not lost to a formatting slip [3]. Application is deterministic and auditable: the same candidate always produces the same repository change or a reported failure. 5. **Syntax / lint gate [D].** Each applied candidate is checked by deterministic syntax and lint gates; a candidate that does not parse is rejected and the repository is rolled back to its pre-application state, so a malformed edit never persists and never reaches validation. This is P7: the gate runs *before* any candidate consumes downstream validation resources, so the valid set handed onward is syntactically sound by construction [21]. A format failure is made impossible downstream, which is what keeps the semantic/mechanical distinction clean. 6. **Normalization and deduplication [D].** Surviving candidates are normalized — whitespace and comments are ignored for comparison — and near-identical candidates are collapsed, so the valid set handed to the validation components contains distinct candidates rather than N copies of the same edit, exactly as Agentless normalizes before its final majority-vote selection [1]. The normalized, deduplicated, syntactically valid candidate set is the component's only output. The target is explicit and checkable: the L column holds exactly one entry — the candidate-generation call — and every stage before and after it (intent-package assembly, edit-representation selection, mechanical application, syntax/lint gating, normalization and deduplication) is deterministic software on CPU. Any proposed addition that would put a language model elsewhere in this stage — a learned edit-representation chooser, a learned patch ranker inside generation, a model-in-the-loop repair of malformed output — is a regression against P1–P7 and the L-column invariant, 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. Ranking among the valid candidates, and any repair of them, is the explicit job of the downstream validation and repair components (10–11, 17–18), not of this stage. ## 5. Recursive Self-Improvement Protocol Component 09 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 bare end-to-end resolve rate alone, which would let downstream validation quality mask generation quality. The deterministic stages (1, 2, 4–6) improve by direct engineering, measured by ablation against the candidate-generation call with no surrounding gates, and against a single-greedy-candidate baseline with no sampling at all. The single learned stage (3) improves only by direct improvement to the generator — a better prompt over the intent package, a better temperature schedule, a better sample count under the budget — measured by whether the resulting candidate set resolves more at fixed cost. And because P4 and P6 hold that the cheapest representation and capped iteration are correct defaults, a *removal* is as much an improvement as an addition: any gate, any normalization step, any cap whose removal does not degrade the honest metrics is deleted, and the "never add a generation mechanism because it sounds sensible" discipline of Section 6 is thereby made mechanical. The candidate set is diffable as it changes, so a generation regression — collapsing diversity, a drift toward whole-file rewrites, a normalization that merges genuinely distinct candidates — is visible in the produced set long before it surfaces as a failed resolve. ## 6. Measurement & Evaluation Patch generation is measured *separately* and *honestly*, in five instruments plus a set of explicit caveats, because a stage that cannot be scored apart from its downstream validators cannot be diagnosed apart from them. **Edit-success rate.** The fraction of generated candidates that apply cleanly and parse — the direct score of the mechanical-application and syntax-gate stages, and the metric SWE-Edit reports (93.4% baseline rising to 96.9% with its decomposition) [2]. It isolates format and application reliability from semantic correctness: a low edit-success rate means the channel between the model's decision and the repository bytes is failing, which is a harness problem, not a reasoning problem. **Resolve rate at a fixed candidate budget / tokens-per-resolved.** The key instrument. For a bounded generation budget (N candidates, a fixed token ceiling), the candidate set must beat a single greedy shot on resolve — the set resolves strictly more than any one of its members alone would — with no cost regression, measured as resolve per generation token consumed. This is the instrument that makes P2 falsifiable: if sampling N candidates resolves the same as a single greedy draw at higher cost, the candidate mechanism is not earning its tokens, regardless of how elegant the diversity rationale reads on paper. Agentless's forty-patches-per-bug lift (roughly 27% to 32% from sampling and selection) is the external reference for what this instrument should show [1]. **Candidate diversity.** Do the N candidates actually differ, or are they near-duplicates? A candidate set that collapses to one effective edit has paid N× the generation cost for no diversity, which is why stage 6 normalizes and deduplicates — the instrument measures whether the normalization is merging genuine duplicates or destroying real alternatives, and whether temperature sampling is producing distinct repairs of the same intent. **Ablation.** The instrument that enforces the discipline of Section 5 mechanically: remove each mechanism — candidate sampling (drop to one greedy shot), the intent package (feed a bare target instead), edit-format selection (force whole-file rewrites), the syntax/lint gate (forward all candidates to validation) — in turn, and measure the honest metrics with it absent. A mechanism is *deleted* if its removal does not degrade the honest metrics, and is kept only if it demonstrably earns its place. This is the "never add a generation mechanism because it sounds sensible" rule turned into a standing gate. **Format-robustness probe.** The instrument that checks P4 and P7: verify that search/replace candidates over localized spans apply more reliably than whole-file rewrites of the same change, and that burying a malformed format — a missing search block, a non-unique match, an off-by-one context line — causes a clean rejection by the syntax gate rather than silent corruption of the repository. It confirms that the chosen representation and the rollback-on-failure gate are load-bearing rather than decorative, in the spirit of SWE-agent's edit-lint guard [21] and Diff-XYZ's format-dependence finding [11]. Two honest caveats close the section. First, the strong-model-transfer caveat: the headline numbers of Section 2 — Agentless's 32.00% on a GPT-4-class base [1], SWE-Edit's +2.1pp with reasoning-model families [2], AlphaCodium's 19→44% for GPT-4 [5], SWE-RL's 41.0% for a 70B model [7] — were all obtained with strong models, and a weak model should not be expected to reproduce them; this architecture's deterministic stages carry the load precisely because the single learned call will underperform, and the edit-success and tokens-per-resolved instruments are the ones that will show whether the surrounding harness is doing so. Second, the held-out and memorization caution inherited from the earlier components: a model that has memorized a repository's shape — or, worse, a benchmark's reference patches, which is why the SWE-bench citation above is a strong-model *reference*, not a target — will score well in-benchmark without the intent package or the candidate mechanism having done constructive work, so all generation metrics must be reported on held-out and out-of-benchmark repositories, exactly as the planning, localization, and context-construction metrics were. ## 7. Conclusion Patch generation is the stage where the coding-harness program's accumulated precision becomes an artifact: after interaction, repository modeling, retrieval, localization, impact analysis, planning, and context construction have bounded the problem, generation is the first stage whose output is the candidate change that downstream components will execute, validate, and repair. This paper has argued that generation must therefore be a narrow semantic transformation stage, not an autonomous coding activity — a named stage with typed inputs and outputs that produces a bounded set of syntactically valid repair candidates from an explicit intent package, and then stops. It has argued, on the strongest results in its review, for the thesis in full: the model generates several bounded candidates because its output is a distribution that executable evidence discriminates among, never one greedy shot whose failure ends the attempt [1][8]; semantic repair is separated from mechanical edit application because the model should decide what the code ought to mean while the harness turns that decision into safe bytes [2][3]; the cheapest reliable edit representation is selected for the change's scope because the format is a measured variable, not a fixed convention [1][11]; and deterministic syntax and application gates reject malformed candidates before they consume downstream validation resources, so a format failure is impossible by the time validation runs [21]. The single learned decision is the candidate-generation call that emits the bounded set; everything around it — intent-package assembly, edit-representation selection, mechanical application, syntax/lint gating, and normalization — is deterministic software on CPU, so the L column holds exactly one entry and generation is audited deterministically. For a weak model, the consequence is the design's dividing line made concrete: *the LLM decides what the corrected code ought to mean; the harness does as much as possible of turning that decision into safe repository bytes.* The honest metrics of Section 6 — above all the resolve rate at a fixed candidate budget, and the edit-success rate that separates format failure from reasoning failure — decide whether the generator is earning its candidate set or quietly paying N× for a single greedy answer. --- ## References 1. Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, and Lingming Zhang. *Agentless: Demystifying LLM-based Software Engineering Agents.* 2024. arXiv:2407.01489. *(Venue caveat: "NeurIPS 2024" is not stated in the arXiv record or full text — the venue is unconfirmed. Numbers verified against the primary source: 32.00% = 96/300 on SWE-bench Lite; $0.70 average per issue confirmed, the $0.34 lower bound appears nowhere and is unsupported; 40 patches = 4 edit-location samples × 10 patches per bug; search/replace edits over localized snippets; normalization + majority voting is the FINAL post-filter re-ranking after regression and reproduction-test filtering, not a pre-test step.)* 2. Yikai Zhang, et al. *SWE-Edit: Rethinking Code Editing for Efficient SWE-Agent.* 2026. arXiv:2604.26102. *(Microsoft; resolved by title search. No venue in the arXiv record. Verified: resolve 69.9% → 72.0% (+2.1pp); cost $243.7 → $200.1 (−17.9%); edit-success 93.4% → 96.9% for the combined configuration; GRPO on Qwen3-8B with adaptive find-replace/whole-file-rewrite policy +12.5pp edit success, 8B editor to GPT-5-nano parity.)* 3. Chaozheng Wang, et al. *Cascaded Code Editing: Large-Small Model Collaboration for Effective and Efficient Code Editing.* FSE 2026. arXiv:2604.19201. *(FSE 2026 confirmed in the arXiv comment field. Verified: DeepSeek R1 sketch + fine-tuned Qwen2.5-Coder-14B apply improves Aider Pass@2 +11.1% RELATIVE over direct R1 = +7.5pp absolute (67.6 → 75.1); execution time −12.9% (27.31h → 23.80h); cost −18.7% ($6.54 → $5.32).)* 4. Xinyun Chen, Maxwell Lin, Nathanael Schärli, and Denny Zhou. *Teaching Large Language Models to Self-Debug.* 2024. arXiv:2304.05128. *(Venue caveat: "ICLR 2024" is not stated in the arXiv record — unconfirmed. Numbers verified: Spider (no unit tests) +2–3%, hardest level +9%; TransCoder and MBPP (unit tests available) up to +12%; the "+10+ pp across benchmarks" summary is an over-simplification — double-digit gains hold only where unit tests exist; sometimes improves without execution feedback.)* 5. Tal Ridnik, Dedy Kredo, and Itamar Friedman. *Code Generation with AlphaCodium: From Prompt Engineering to Flow Engineering.* 2024. arXiv:2401.08500. *(ID and author corrections: the source ID 2401.01365 resolves to an unrelated mathematics paper, and the "Grozman & Konyushkof" attribution is wrong; correct authors are Ridnik, Kredo, and Friedman of CodiumAI. Verified: GPT-4 pass@5 on CodeContests validation 19% → 44% with the AlphaCodium flow.)* 6. Yuwei Zhang, Zhi Jin, Ying Xing, Ge Li, Fang Liu, Jiaxin Zhu, Wensheng Dou, and Jun Wei. *PATCH: Empowering Large Language Model with Programmer-Intent Guidance and Collaborative-Behavior Simulation for Automatic Bug Fixing.* 2025. arXiv:2501.16149. *(ACM TOSEM venue confirmed in the arXiv comment field. Verified: patch generation augmented with dependence context and programmer intent, not buggy code alone; four stages — bug reporting, bug diagnosis, patch generation, patch verification.)* 7. Yuxiang Wei, et al. *SWE-RL: Advancing LLM Reasoning via Reinforcement Learning on Open Software Evolution.* NeurIPS 2025. arXiv:2502.18449. *(Affiliation caveat: the first author, Yuxiang Wei, is at UIUC — most authors are Meta AI and the corresponding author is Meta, but the first author is not. NeurIPS 2025 appears in the PDF footer, not the arXiv metadata. Verified: rule-based reward = difflib.SequenceMatcher similarity between predicted and oracle merged-PR patch, no execution feedback; Llama3-SWE-RL-70B at 41.0% on SWE-bench Verified.)* 8. Jiayi Pan, Xingyao Wang, Graham Neubig, Navdeep Jaitly, Heng Ji, Alane Suhr, and Yizhe Zhang. *Training Software Engineering Agents and Verifiers with SWE-Gym.* 2024. arXiv:2412.21139. *(Framing nuance: the trained verifier scores agent TRAJECTORIES, and selection is reported as Best@k, not literally "best-of-N". Verified: 32.0% Verified / 26.0% Lite; more samples and a better verifier keep improving (32B continues at k=8, 7B plateaus after k=4).)* 9. Theo X. Olausson, Jeevana Priya Inala, Chenglong Wang, Jianfeng Gao, and Armando Solar-Lezama. *Is Self-Repair a Silver Bullet for Code Generation?* ICLR 2024. arXiv:2306.09896. *(ICLR 2024 confirmed by external indexes, not by the arXiv metadata which carries no venue. Verified: self-repair gains over resampling modest/inconsistent; bottleneck is the feedback stage; human-written feedback dramatically outperforms model-written feedback.)* 10. Fengji Zhang, Bei Chen, Yue Zhang, Jacky Keung, Jin Liu, Daoguang Zan, Yi Mao, Jian-Guang Lou, and Weizhu Chen. *RepoCoder: Repository-Level Code Completion Through Iterative Retrieval and Generation.* EMNLP 2023. arXiv:2303.12570. 11. Evgeniy Glukhov, Michele Conti, Egor Bogomolov, Yaroslav Golubev, and Alexander Bezzubov. *Diff-XYZ: A Benchmark for Evaluating Diff Understanding.* 2025. arXiv:2510.12487. *(Cross-format finding: search/replace best for larger models across most tasks; smaller open models benefit little from any formatting choice — format is a performance variable with a model-size interaction.)* 12. John Yang, et al. *SWE-smith: Scaling Data for Software Engineering Agents.* 2025. arXiv:2504.21798. *(Verified: 50k instances from 128 repositories; open model at 40.2% Pass@1 on SWE-bench Verified.)* 13. Haoran Xue, Gias Uddin, and Song Wang. *PAGENT: Learning to Patch Software Engineering Agents.* 2025. arXiv:2506.17772. *(Verified: 769 failed patches from 7 agents across 114 unresolved SWE-bench Lite issues; 6-category taxonomy. Refinement: type inference is a major category but NOT the leading one — shallow understanding of code context and architecture is the most common pattern; the paper calls type "not the most frequent failure pattern.")* 14. Earl T. Barr, Yuriy Brun, Premkumar Devanbu, Mark Harman, and Federica Sarro. *The Plastic Surgery Hypothesis.* FSE 2014. *(Lineage citation; not independently re-verified in this pass.)* 15. Mahdieh Abazar, Reyhaneh Farahmand, Gouri Ginde, Benjamin Tan, and Lorenzo De Carli. *Behavioral Analysis of AI Code Generation Agents: Edit, Rewrite, and Repetition.* MSR 2026. ACM DOI 10.1145/3793302.3793605. *(NOT on arXiv — an ACM/MSR paper; DOI verified via ACM-family sources. Analyzes AIDev PR patches from Claude Code, Copilot, Cursor, Devin, and OpenAI Codex across five languages; measures edit-vs-rewrite via token-level similarity and repetition via n-gram ratios and Shannon entropy.)* 16. Bei Chen, et al. *CodeT: Code Generation with Generated Tests.* ICLR 2023. *(Lineage citation — generate-many plus test-based selection; not independently re-verified in this pass.)* 17. Federico Cassano, et al. *"Can It Edit? Evaluating the Ability of Large Language Models to Follow Code Editing Instructions."* 2024. arXiv:2312.12450. *(A benchmark of 105 code-editing problems — corrective/perfective/adaptive — showing open models lag closed models and releasing a permissively-licensed training dataset that closes much of that gap. NOTE: this paper does NOT compare edit representations; the earlier "reliability gap between representations" attribution was wrong and belongs to Diff-XYZ, reference 11. Verified: the source IDs 2406.08446 and 2403.04002 both resolve to unrelated papers.)* 18. Paul Gauthier. *Aider edit formats and search/replace benchmarks.* 2023–2024. https://aider.chat. *(Practitioner benchmark lineage; not independently re-verified in this pass.)* 19. Islem Bouzenia, Premkumar Devanbu, and Michael Pradel. *RepairAgent: An Autonomous, LLM-Based Agent for Program Repair.* 2024. arXiv:2403.17134. *(Lineage citation; not independently re-verified in this pass.)* 20. Yuntong Zhang, et al. *AutoCodeRover: Autonomous Program Improvement.* 2024. arXiv:2404.05427. *(Cross-referenced from context construction; lineage citation for the two-stage localize-then-patch split.)* 21. John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. *SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering.* 2024. arXiv:2405.15793. *(Cross-referenced from context construction; the edit-lint-and-revert guard is the ancestor of P7. Venue caveat as in component 08: "NeurIPS 2024" is not in the arXiv record.)*