Libra: Training the Environment for Agentic Information Retrieval

# Libra: Training the Environment for Agentic Information Retrieval
Source: [https://arxiv.org/html/2607.00016](https://arxiv.org/html/2607.00016)
Xuan Zhao xuan\.zhao@salesforce\.com&Andy Chiu andy\.chiu@salesforce\.com&Gengyu Wang gengyu\.wang@columbia\.edu

###### Abstract

Information localization within massive repositories is a cornerstone of agentic LLM systems\. While synthetic data\-driven optimization has proven successful in training LLMs, little attention has been paid to optimizing the agent’s working environment \(the repository itself\) in a data\-driven manner\. To bridge this gap, we presentLibra, a self\-evolving framework that introduces mutable “catalogs” \(hierarchical Markdown files serving as navigable indices\) into the repository\.Libraruns an LLM\-driven optimization loop where a Prompter generates synthetic queries, a frozen Solver attempts to resolve them by navigating the catalogs, and a Healer rewrites the catalogs in response to the Solver’s localization failures\. Evaluations across 12SWE\-bench Literepositories demonstrate that this environmental healing yields continual, logarithmic improvements in code localization accuracy\. Furthermore, these environmental improvements transfer zero\-shot across different LLMs and problem sets\. Although the focus of this paper is to study the general behavior of such a system, we also demonstrate that a minimalist coding agent equipped withLibra\-optimized catalogs outperforms state\-of\-the\-art baselines\. Code is available at[https://github\.com/salesforce\-misc/Libra](https://github.com/salesforce-misc/Libra)and data at[https://huggingface\.co/datasets/Salesforce/Libra](https://huggingface.co/datasets/Salesforce/Libra)\.

## 1Introduction

![Refer to caption](https://arxiv.org/html/2607.00016v1/figures/architecture_v4.png)Figure 1:Overview of the Libra system\. Three frozen agents \(Prompter, Solver, Healer\) drive an adversarial loop in which only the Markdown catalog is updated\. The Prompter sees a random file chunk and fabricates a question whose answer is that chunk; the Solver does not see the chunk and must answer by searching the repository alongside the catalog; the Healer reads the accumulated failure report once per batch and edits the catalog to repair the routing signal\.Code localization within large repositories is a fundamental capability for autonomous coding agents\(Anthropic,[2024](https://arxiv.org/html/2607.00016#bib.bib29); Anysphere,[2024](https://arxiv.org/html/2607.00016#bib.bib30); Yanget al\.,[2024b](https://arxiv.org/html/2607.00016#bib.bib22); Wang and others,[2024](https://arxiv.org/html/2607.00016#bib.bib4)\)\. Localization accuracy has further been shown to correlate strongly with downstream task resolution rates\(Chenet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib2); Wanget al\.,[2026](https://arxiv.org/html/2607.00016#bib.bib3)\), making it one of the key contributors to end\-to\-end agent performance\. More broadly, information retrieval serves as the cornerstone of agentic systems and has consequently been the subject of extensive research\(Lewiset al\.,[2020](https://arxiv.org/html/2607.00016#bib.bib5); Jinet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib8); Zhanget al\.,[2026](https://arxiv.org/html/2607.00016#bib.bib9)\)\. These agentic systems generally operate on three interacting pillars: the underlying foundation*model*, the*agent design*\(prompt engineering and tool use\), and the*environment*itself \(repository contents, search indices, and documentation\)\.

To improve an agent’s ability to navigate a specific environment, a natural approach is to fine\-tune the underlying foundation model using repository\-derived data\(Jimenezet al\.,[2024](https://arxiv.org/html/2607.00016#bib.bib35); Maet al\.,[2024](https://arxiv.org/html/2607.00016#bib.bib34); Panet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib33); Weiet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib36)\)\. While this allows the model to internalize environmental knowledge into its weights using mature optimization techniques, it inherently locks the system to a specific model\. Consequently, the agent may lose access to the superior reasoning and semantic capabilities of state\-of\-the\-art commercial LLMs, rendering this approach sub\-optimal for practical, evolving applications\.

Alternatively, researchers have sought to augment the agent’s environment by constructing static or reverse indices\(Jinet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib8); Chenet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib2); Wanget al\.,[2026](https://arxiv.org/html/2607.00016#bib.bib3); Zhanget al\.,[2026](https://arxiv.org/html/2607.00016#bib.bib9)\)or hierarchical summaries\(Sarthiet al\.,[2024](https://arxiv.org/html/2607.00016#bib.bib38); Edgeet al\.,[2024](https://arxiv.org/html/2607.00016#bib.bib39)\)and equipping the agent with sophisticated tools to interact with these structures\. While these environment\-centric approaches are model\-agnostic by design, they remain static, lacking a mechanism to adapt dynamically to the agent’s specific retrieval challenges or to leverage data—such as human feedback or synthetic interaction traces—to continuously improve the system\.

A separate line of work leverages interaction trace data, allowing agents to learn from their own failures through adversarial fine\-tuning\(Yueet al\.,[2026](https://arxiv.org/html/2607.00016#bib.bib20)\)or by maintaining persistent memory artifacts within the environment\(He and Roy,[2026](https://arxiv.org/html/2607.00016#bib.bib10); Liuet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib81)\)\. Despite these advancements, the field still lacks a*model\-agnostic*,*data\-driven*framework that can*actively*evolve an agent’s information retrieval capabilities for a specific repository\.

To bridge this gap, we introduce Libra, representing a paradigm shift in repository indexing: moving from static, external embeddings to an actively evolving, plain\-text index natively integrated into the repository\. Libra constructs a hierarchy of Markdown files, termed*catalogs*, that acts as a navigation map\. Instead of relying on predefined heuristics, these catalogs are iteratively optimized through an adversarial LLM\-driven training loop\. A Prompter agent generates synthetic queries from random code chunks, while a Solver attempts to answer them using only the catalogs for guidance\. The Solver’s navigation failures provide a rich, targeted training signal for a Healer agent to continuously refine the catalogs, aligning the index structure with how language models actually search for information\.111In our implementation, we execute the Prompter separately to generate the complete training dataset upfront\. The Solver then processes these questions in batches, and the Healer analyzes the aggregated failure signals from each batch to update the catalogs\.

We evaluate Libra across the 12 Python repositories ofSWE\-bench Lite\. Our experiments demonstrate the efficacy of this LLM optimization approach: training on synthetic queries yields significant improvements in navigation accuracy that robustly transfer to resolving real\-worldSWE\-bench Liteissues\. Furthermore, we show that the fully\-trained catalogs act as a persistent, model\-agnostic resource, consistently enhancing the localization performance of various downstream models\. Compared to state\-of\-the\-art index\-based approaches like LocAgent and RepoMem, Libra achieves competitive performance while offering the distinct advantages of interpretability and portability\.

## 2Related work

#### Code localization and repository indices\.

Repository\-scale localization on benchmarks like SWE\-bench is dominated by two families: agentic search over the source tree \(SWE\-agent\(Yanget al\.,[2024b](https://arxiv.org/html/2607.00016#bib.bib22)\), Agentless\(Xiaet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib23)\), LocAgent\(Chenet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib2)\), RepoMem\(Wanget al\.,[2026](https://arxiv.org/html/2607.00016#bib.bib3)\)\) and fine\-tuned retrievers or models trained on repository data\(Reddyet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib11); Xieet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib27); Jimenezet al\.,[2024](https://arxiv.org/html/2607.00016#bib.bib35); Weiet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib36); Panet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib33)\)\. Hierarchical or graph\-structured retrievers \(RAPTOR\(Sarthiet al\.,[2024](https://arxiv.org/html/2607.00016#bib.bib38)\), GraphRAG\(Edgeet al\.,[2024](https://arxiv.org/html/2607.00016#bib.bib39)\), HippoRAG\(Gutiérrezet al\.,[2024](https://arxiv.org/html/2607.00016#bib.bib40)\)\) impose multi\-resolution structure on the corpus by clustering or LLM extraction\. All of these construct their index, graph, or model weights once and never repair them from query\-time failures; Libra keeps the agentic\-search interface but turns the index into a state variable updated by Solver failures\.

#### Synthetic Q/A generation\.

LLM\-generated queries have a long history as training data for dense retrievers \(Doc2Query\(Nogueiraet al\.,[2019](https://arxiv.org/html/2607.00016#bib.bib12)\), InPars\(Bonifacioet al\.,[2022](https://arxiv.org/html/2607.00016#bib.bib13)\), Promptagator\(Daiet al\.,[2023](https://arxiv.org/html/2607.00016#bib.bib14)\), GPL\(Wanget al\.,[2022](https://arxiv.org/html/2607.00016#bib.bib15)\)\) and for bootstrapping instruction corpora \(Self\-Instruct\(Wanget al\.,[2023b](https://arxiv.org/html/2607.00016#bib.bib16)\), Evol\-Instruct\(Xuet al\.,[2024](https://arxiv.org/html/2607.00016#bib.bib17)\)\)\. The closest precedent for our information\-asymmetry framing is Beat\-the\-AI\(Bartoloet al\.,[2020](https://arxiv.org/html/2607.00016#bib.bib19)\), where annotators exploit oracle access to write hard questions\. Libra’s Prompter follows this lineage\.

#### Self\-improving agents and persistent memory\.

Many systems improve an agent in place by editing its scratchpad \(Reflexion\(Shinnet al\.,[2023](https://arxiv.org/html/2607.00016#bib.bib7)\), Self\-Refine\(Madaanet al\.,[2023](https://arxiv.org/html/2607.00016#bib.bib70)\), STaR\(Zelikmanet al\.,[2022](https://arxiv.org/html/2607.00016#bib.bib72)\)\), by growing per\-agent libraries or memory stores \(Voyager\(Wanget al\.,[2023a](https://arxiv.org/html/2607.00016#bib.bib6)\), MemGPT\(Packeret al\.,[2024](https://arxiv.org/html/2607.00016#bib.bib78)\), A\-MEM\(Xuet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib80)\)\), or by routing self\-generated trajectories back into model weights \(AgentTuning\(Zenget al\.,[2024](https://arxiv.org/html/2607.00016#bib.bib21)\), Dr\. Zero\(Yueet al\.,[2026](https://arxiv.org/html/2607.00016#bib.bib20)\)\); for software engineering specifically, ExpeRepair\(Liuet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib81)\)and SWE\-Adept\(He and Roy,[2026](https://arxiv.org/html/2607.00016#bib.bib10)\)attach dual\-memory or git\-like stores to the issue\-resolution agent\. In all of these the memory lives inside the agent and is read\-write by the agent exclusively; Libra externalizes the memory to a plain\-text environment sharable across agents\.

#### LLMs as optimizers of textual artifacts\.

A growing line of work uses one LLM to optimize a textual artifact that another LLM later consumes: prompts via direct search \(APE\(Zhouet al\.,[2023](https://arxiv.org/html/2607.00016#bib.bib46)\), PromptBreeder\(Fernandoet al\.,[2023](https://arxiv.org/html/2607.00016#bib.bib47)\)\) or via critique\-as\-gradient \(ProTeGi\(Pryzantet al\.,[2023](https://arxiv.org/html/2607.00016#bib.bib44)\), TextGrad\(Yuksekgonulet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib43)\)\); solutions conditioned on score history \(OPRO\(Yanget al\.,[2024a](https://arxiv.org/html/2607.00016#bib.bib45)\)\); and entire LLM pipelines \(DSPy\(Khattabet al\.,[2024](https://arxiv.org/html/2607.00016#bib.bib48)\)\)\. Libra’s Healer fits this template and applies it to the realm of repository information retrieval\.

## 3Method

The Libra system consists of three independent, frozen LLM agents—Prompter, Solver, and Healer—and an orchestration mechanism that composes them into an LLM optimization loop\. LetRRdenote a source repository\. The system produces three artifacts:

1. 1\.Synthetic Q/A pairs\.Generated by the Prompter and split into disjoint train and test sets\. Training pairs drive the LLM optimization loop; test pairs evaluate the learned catalogs\.
2. 2\.Failure setℱ\\mathcal\{F\}\.The subset of training queries on which the Solver fails to retrieve the correct answer\. This intermediate artifact serves as the learning signal for the Healer\.
3. 3\.Libra catalogsKK\.A set of mutable, plain\-text Markdown files that encode repository routing information\. Once optimized, these catalogs serve as a persistent index to assist any coding agent in navigatingRR\.

In this paper, we evaluate the system on fixed repository snapshots\. While the plain\-text format of the catalogs naturally supports incremental updates as the repository evolves, we leave this extension to future work\.

### 3\.1Libra catalogs

The Libra catalogs are a set of Markdown files placed at the repository root and in each submodule directory\. Our hypothesis—validated empirically in Section[4](https://arxiv.org/html/2607.00016#S4)—is that through iterative refinement, an LLM optimizer can encode repository routing information into these files, and that this information transfers to other coding agents, improving their localization performance\. The Libra catalogs are human\-readable, human\-editable, and typically range from 100–1000 KB when fully populated\.

### 3\.2Three frozen agents

We now define the three agents that constitute the Libra system\. All three are*frozen*: their system prompts, tool configurations, and underlying model weights remain fixed across all rounds\. Only the catalogsKKare mutable\.

All three agents are tool\-using LLM agents that operate over the source repositoryRRas a shared environment\. Following standard practice, we writeRRas an input to each agent’s signature to denote tool\-mediated read access; the role\-specific tool sets \(and, for the Healer, additional write access toKK\) are detailed in Appendix[G](https://arxiv.org/html/2607.00016#A7)\.

#### Prompter \(Data Synthesizer\)\.

The Prompter generates synthetic question–answer pairs that probe the Solver’s retrieval capability\. Let𝒞​\(R\)=\{c1,…,cN\}\\mathcal\{C\}\(R\)=\\\{c\_\{1\},\\ldots,c\_\{N\}\\\}denote the set of code chunks in repositoryRR, and letπ​\(c\)\\pi\(c\)denote the unique file path containing chunkcc\. Formally,

Prompter:\(c,R\)↦\(q,p∗\),\\textsc\{Prompter\}:\\;\(c,R\)\\;\\mapsto\\;\(q,p^\{\*\}\),wherec∼Uniform​\(𝒞​\(R\)\)c\\sim\\text\{Uniform\}\(\\mathcal\{C\}\(R\)\)is a uniformly sampled chunk,qqis a natural\-language question simulating a realistic user query answerable fromcc, andp∗=π​\(c\)p^\{\*\}=\\pi\(c\)is the gold file path\.

The Prompter has full access to the sampled chunkccand may further exploreRRvia its tools to gather surrounding context\. Because the question is crafted*with*the answer in hand, correctness of the gold label is guaranteed by construction\.222Strictly, correctness holds to the extent that the Prompter LLM generates a question that is genuinely answerable from the given chunk and not from other locations in the repository\. In practice, we observe this assumption to be reliable enough for the precision of this research\.

#### Solver \(Query Resolver\)\.

The Solver is the coding agent responsible for resolving queries by navigating the repository\. It represents the downstream consumer of the catalogs\. Formally,

Solver:\(q,K,R\)↦p^,\\textsc\{Solver\}:\\;\(q,K,R\)\\;\\mapsto\\;\\hat\{p\},whereqqis a natural\-language query,KKis the current catalog state, andp^\\hat\{p\}is the predicted file path\.

While the Solver can freely traverseRRvia its tools, it has*no access*to the gold chunk or file path; it must locate the answer solely through repository exploration guided by the catalogs\. A hypothesis which we later validate empirically is that this asymmetry in information and difficulty in task creates a gap in performance between the Prompter and the Solver, from which the Healer can harvest reliable signals to refine the catalogs\.

#### Healer \(LLM Optimizer\)\.

The Healer refines the catalogs based on Solver failures, functioning as the optimizer in the Libra system\. Formally,

Healer:\(ℱ,K,R\)↦K′,\\textsc\{Healer\}:\\;\(\\mathcal\{F\},K,R\)\\;\\mapsto\\;K^\{\\prime\},whereℱ=\{\(qi,pi∗,p^i\)\}i=1\|ℱ\|\\mathcal\{F\}=\\\{\(q\_\{i\},p^\{\*\}\_\{i\},\\hat\{p\}\_\{i\}\)\\\}\_\{i=1\}^\{\|\\mathcal\{F\}\|\}is the failure set—each entry contains the queryqiq\_\{i\}, the gold pathpi∗p^\{\*\}\_\{i\}, and the Solver’s predicted pathp^i\\hat\{p\}\_\{i\}—andK′K^\{\\prime\}is the updated catalog state\. Beyond read access toRR, the Healer also holds write access toKK, which it edits in place\.

### 3\.3The LLM optimization loop

The LLM optimization loop \(also referred to as the training loop\) orchestrates the three agents overTTrounds\. Each round consists of a*testing phase*, in which the Prompter and Solver generate a batch of queries and expose failures, followed by a*Healing phase*, in which the Healer updates the catalogs\. The procedure is formalized in Algorithm[1](https://arxiv.org/html/2607.00016#algorithm1)\.

Algorithm 1Libra LLM optimization loop\.Input:repositoryRR, batch sizeBB, number of roundsTT\.State:Catalog setKK\(directory of Markdown files\), initialized empty\.fort=1,…,Tt=1,\\ldots,Tdo*// Testing phase*ℱt←∅\\mathcal\{F\}\_\{t\}\\leftarrow\\emptysetfori=1,…,Bi=1,\\ldots,Bdoci∼Uniform​\(𝒞​\(R\)\)c\_\{i\}\\sim\\text\{Uniform\}\(\\mathcal\{C\}\(R\)\)// sample a code chunk\(qi,pi∗\)←Prompter​\(ci,R\)\(q\_\{i\},p^\{\*\}\_\{i\}\)\\leftarrow\\textsc\{Prompter\}\(c\_\{i\},R\)// generate questionp^i←Solver​\(qi,K,R\)\\hat\{p\}\_\{i\}\\leftarrow\\textsc\{Solver\}\(q\_\{i\},K,R\)// resolve query using catalogsifp^i≠pi∗\\hat\{p\}\_\{i\}\\neq p^\{\*\}\_\{i\}thenℱt←ℱt∪\{\(qi,pi∗,p^i\)\}\\mathcal\{F\}\_\{t\}\\leftarrow\\mathcal\{F\}\_\{t\}\\cup\\\{\(q\_\{i\},p^\{\*\}\_\{i\},\\hat\{p\}\_\{i\}\)\\\}*// Healing phase*K←Healer​\(ℱt,K,R\)K\\leftarrow\\textsc\{Healer\}\(\\mathcal\{F\}\_\{t\},K,R\)returnKK

## 4Experiments

We evaluate Libra along five axes\. First, we run an extended training trajectory onsympyto establish our core result: catalog training continuously improves code localization accuracy, yielding logarithmic returns over time \(§[4\.2](https://arxiv.org/html/2607.00016#S4.SS2)\)\. We selectsympyas our primary testbed because it is the largest repository in theSWE\-bench Litedataset, and its well\-structured, evenly distributed submodules make it ideal for evaluating hierarchical catalogs\. Second, we verify that this improvement pattern holds across all 12SWE\-bench Literepositories \(§[4\.3](https://arxiv.org/html/2607.00016#S4.SS3)\), which vary significantly in size and structure\. Third, we test whether catalogs trained on synthetic Prompter data transfer to real\-world problem distributions by replaying on a subset ofSWE\-bench Lite\(§[4\.4](https://arxiv.org/html/2607.00016#S4.SS4)\)\.[3](https://arxiv.org/html/2607.00016#footnote3)Fourth, we assess the model\-agnosticism of the learned catalogs by replaying the training trajectory with three different Solver setups \(§[4\.5](https://arxiv.org/html/2607.00016#S4.SS5)\)\. Finally, we demonstrate how individual test queries transition from failure to success as the catalog evolves \(§[4\.6](https://arxiv.org/html/2607.00016#S4.SS6)\)\.

### 4\.1Setup

#### Data\.

For catalog training, we use synthetic data generated offline by the Prompter\. We evaluate in\-distribution learning on a held\-out test split of this synthetic data\. To assess cross\-problem generalizability, we additionally evaluate on a subset of the realSWE\-bench Liteproblem set\. Because the originalSWE\-bench Liteinstances \(300 in total\) each assume a different base commit, we filter the set down to 199 instances that can be evaluated on a single base commit per repository\.333Gold files and functions are derived from each instance’s ground\-truth patch and validated against the base commit’s file tree\. We exclude instances where \(1\) the referenced file or function does not exist at the base commit, \(2\) the referenced file or module has been moved or renamed between the instance’s original commit and the base commit, or \(3\) the instance requires multi\-hop patching spanning multiple files\.The exact number of training, testing, andSWE\-bench Liteinstances chosen for each repository, along with the base commit used to rebase theSWE\-bench Liteinstances, is detailed in Appendix[E](https://arxiv.org/html/2607.00016#A5)\(Table[5](https://arxiv.org/html/2607.00016#A5.T5)\)\. Both the synthetic Prompter splits and the re\-anchoredSWE\-bench Litesubset are released; see Appendix[D](https://arxiv.org/html/2607.00016#A4)for schema and license details\.

![Refer to caption](https://arxiv.org/html/2607.00016v1/figures/combined_training.png)Figure 2:Training trajectory onsympy\(85 healer steps, GPT\-5\-mini at 5 turns\)\.*Left*: file\-level accuracy on train and test sets\.*Middle*: average turns per query\.*Right*: catalog size growth\.Table 1:Accuracy on thesympyheld\-out test set \(300 instances, GPT\-5\-mini, 5 turns\)\. LocAgent and RepoMem report mean±\\pmSEM over 5 runs\.
#### Agents and Catalog\.

The Solver is powered by GPT\-5\-mini and operates under a strict budget ofmax\_turns=5 during training\. We constrain the Solver to ensure that routing failures are plentiful, thereby providing the Healer with adequate learning signals \(see Appendix[B](https://arxiv.org/html/2607.00016#A2)for a saturation analysis on frontier\-tier Solvers that motivates this choice\)\. By design, the Solver follows a deliberately minimalist recipe: it is equipped with only two general\-purpose tools—Bash\(restricted tols,grep, andfind\) andRead\(file read with line\-range selection\)—alongside a short system prompt that instructs it to consult the Libra catalogs\. We intentionally avoid bespoke retrieval tooling, repository graphs, or commit\-history indices used by prior work \(cf\. the 3\-tool LocAgent and 7\-tool RepoMem setups in the Baselines paragraph\), so that any performance gain can be attributed to the catalogs themselves rather than to richer agent scaffolding\. Initially, empty catalogs are created under the repository root and each Python submodule\. The root catalog is always provided as context\. For our cross\-model generalizability evaluation, we maintain this minimalist 2\-tool design but swap the underlying model to GPT\-5, Gemini\-2\.5\-Flash, or GPT\-5\-mini with an expanded budget ofmax\_turns=12\.

The Prompter and Healer both utilize Claude Opus 4\.6\. They are granted full access to the ClaudeAgentSDK tool suite444Across all training runs, the active tools observed in the agents’ trajectories areBash,Read,Write,Edit,Glob,Grep,Agent\(subagent dispatch\), andStructuredOutput\(final\-answer capture\)\. See the Claude Agent SDK documentation at[https://docs\.claude\.com/en/agent\-sdk/overview](https://docs.claude.com/en/agent-sdk/overview)\.and operate without any turn budget\.555The Prompter used to generate thesympytraining set is a slightly earlier variant: it also runs Claude Opus 4\.6 but is equipped only withBashandReadtools rather than the full ClaudeAgentSDK\.

A small set of soft heuristics, all communicated via system prompts rather than programmatically enforced, shape agent behavior\. The Healer is given structural guidelines that keep catalogs terse and discriminative \(a table\-like, hierarchical layout with bounded bullet counts and lengths\), and the Prompter is instructed to produce harder queries by avoiding exact identifiers and favoring questions that plausibly match sibling chunks\. A detailed prompt\-engineering study is outside the scope of this paper; the verbatim prompts are reproduced in Appendix[G](https://arxiv.org/html/2607.00016#A7)\.

Catalogs are initialized empty for this study\. Their content and structural conventions are indirectly shaped by the Healer design\.

#### Baselines\.

We compare against two agentic localization methods: LocAgent\(Chenet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib2)\)and RepoMem\(Wanget al\.,[2026](https://arxiv.org/html/2607.00016#bib.bib3)\)\. Like Libra, both are agentic Solvers that explore the repository through tool calls; unlike Libra, neither rewrites the environment as it runs\. LocAgent replaces ourBash/Readtools with three structure\-aware tools backed by a heterogeneous repository graph \(directories, files, classes, functions, and their contain/import/invoke/inherit edges\) plus a sparse, hierarchical entity index that falls back from exact\-ID/exact\-name lookups to BM25\(Robertson and Zaragoza,[2009](https://arxiv.org/html/2607.00016#bib.bib57)\)over entity IDs and code chunks\. RepoMem extends LocAgent with four*frozen*commit\-history tools that surface episodic and semantic memory mined offline from prior commits and edit frequencies\. Both baselines use the same Solver model \(GPT\-5\-mini\) and turn budgets as Libra to ensure a controlled comparison; full implementation details are deferred to Appendix[C](https://arxiv.org/html/2607.00016#A3)\. All baseline results are averaged over multiple independent runs \(5 runs for thesympytest set, 10 runs for theSWE\-bench Liteevaluation\), and we report the mean±\\pmSEM\.

#### Metrics\.

We measure accuracy by the exact match between the Solver’s prediction and the ground\-truth file \(File ACC\) or function \(Func ACC\)\. Because the Solver is constrained to output exactly one prediction, these metrics correspond to the Top\-1 accuracy \(ACC@1\) used in prior work\(Chenet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib2); Reddyet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib11)\)\. As file and function accuracies are highly correlated \(see Appendix[A](https://arxiv.org/html/2607.00016#A1), Figure[6](https://arxiv.org/html/2607.00016#A1.F6)\), we report file accuracy as our primary metric\.

#### Replay methodology\.

Each Healer step commits the updated catalog to version control, producing a sequence of snapshots that we term the*training trajectory*\. To evaluate performance at different stages of training, we*replay*the held\-out test set against these catalog snapshots\. This approach decouples evaluation from the training loop, allowing us to assess any combination of Solver model, setup, and problem set against any historical catalog state without retraining\.

### 4\.2Main result: extended training onsympy

We run an 85\-step training trajectory on thesympyrepository \(the largest repository inSWE\-bench Lite, with∼430\{\\sim\}430k lines of Python code\)\. Each step processes a batch of 400 training instances, totaling 34,000 instances over the full run\. The held\-out test set contains 300 instances at the same base commit\. We also evaluate the baselines LocAgent\(Chenet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib2)\)and RepoMem\(Wanget al\.,[2026](https://arxiv.org/html/2607.00016#bib.bib3)\)on the same test set using the same model and turn budget\.

Table[1](https://arxiv.org/html/2607.00016#S4.T1)and Figure[2](https://arxiv.org/html/2607.00016#S4.F2)summarize the end\-to\-end results and the full training trajectory\. We observe several key dynamics\. First, while the Libra Solver initially underperforms the baselines due to its lack of sophisticated tools and turn\-budget efficiency, its performance quickly catches up as the catalogs build up, ultimately surpassing both baselines by a significant margin\. Second, the trajectory exhibitsrapid early gains: the first 5 steps \(2,000 instances\) lift test file accuracy from60\.3%60\.3\\%to72\.0%72\.0\\%\(\+11\.7\+11\.7pp\), capturing roughly half of the total improvement\. Third, we observelogarithmic gains thereafter, with accuracy climbing in11–33pp increments from step 5 onward and plateauing near step 60 \(80\.7%80\.7\\%\)\. Finally,train and test track each otherclosely; the gap between train and test accuracy stays within∼2\{\\sim\}2pp throughout\. This confirms our hypothesis that the routing information encoded in the catalog is transferable to problems unseen during training\.666Because we train for only one epoch, every training batch is itself new to the catalog, so even training accuracy measures generalization\. We nonetheless maintain a fixed held\-out test set for additional clarity\.

### 4\.3Training on allSWE\-bench Literepositories

To assess Libra’s effectiveness across a wider spectrum of repositories varying in size, quality, and structure, we train Libra independently on all 12 repositories selected forSWE\-bench Lite\. Each repository uses the same configuration \(GPT\-5\-mini, 5 turns\), with batch sizes and step counts adapted to the repository’s size \(see Table[5](https://arxiv.org/html/2607.00016#A5.T5)in Appendix[E](https://arxiv.org/html/2607.00016#A5)for exact parameters\)\.

![Refer to caption](https://arxiv.org/html/2607.00016v1/figures/v8_file_acc_by_instances.png)Figure 3:Training curves for eachSWE\-bench Literepository \(*left*: train,*right*: test\)\.Table 2:SWE\-bench Liteevaluation \(199 instances, GPT\-5\-mini, 10 runs\)\. Values are mean \(SEM\)\. The Catalog column indicates Libra’s catalog state\. Aggregate columns report instance\-weighted accuracy and cost across all 12 repos\. Per\-repo columns report File ACC for the six largest repositories; “other” aggregates astropy \(3\), flask \(3\), pylint \(3\), requests \(2\), seaborn \(4\), xarray \(5\)\.Figure[3](https://arxiv.org/html/2607.00016#S4.F3)confirms that every repository consistently benefits from training\. The training curves exhibit the same logarithmic\-gains pattern observed onsympy: the first few hundred instances capture the steepest improvement as the Healer bootstraps the empty catalogs\. As training progresses, the gains continue and eventually plateau\. For some repositories, we observe a slight regression during the final steps, suggesting that the catalogs begin to "overfit" to the training data\. This likely occurs because chunk overlaps cause similar questions to appear repeatedly despite single\-epoch training, and variable\-length catalogs accumulate noise alongside useful information as training progresses\.

### 4\.4Replay onSWE\-bench Liteproblem set

To verify that catalogs trained on synthetic data improve the Solver’s performance on real bug\-localization queries, we evaluate the Solver across three catalog healing stages using theSWE\-bench Liteproblem set: Empty \(step 0\), Bootstrapped \(step 1\), and Trained \(final step\)\. We compare these results against our baselines and replicate all experiments with an extended turn budget of 10 to analyze the impact of turn limits across methods\. Note that RepoMem is evaluated exclusively at 10 turns, as the LLM requires more than 5 turns to effectively utilize its 7 tools\. To account for the limited number of instances in theSWE\-bench Litedataset, we average all measurements across 10 independent runs and report the mean±\\pmSEM\.

Table[2](https://arxiv.org/html/2607.00016#S4.T2)shows consistent gains on realSWE\-bench Liteinstances as the catalogs are bootstrapped and fully trained\. Furthermore, once the catalogs are fully trained, the Libra Solver achieves the best performance among all methods, surpassing both LocAgent and RepoMem in most repositories despite being trained entirely on synthetic data\.

### 4\.5Replay on different Solver setup

A central claim of our work is that training the environment is*orthogonal*to the choice of Solver model and design\. To test this, we take the first 60 steps of the catalog trajectory produced by GPT\-5\-mini training and replay the test set with three different Solver setups: GPT\-5\-mini \(the training Solver\) with extended 12\-turn budget, GPT\-5 \(a stronger sibling\), and Gemini\-2\.5\-Flash \(a different model family\)\. The catalogs are*never re\-trained*for the new Solvers\. Performance of the original trained Solver is also included as reference\.

![Refer to caption](https://arxiv.org/html/2607.00016v1/figures/v8_replay_curves_file.png)Figure 4:Replay results with different Solver models and turn budgetsAll three Solvers improve along the catalog trajectory \(Figure[4](https://arxiv.org/html/2607.00016#S4.F4)\)\. The weaker the no\-catalog baseline, the larger the absolute lift: Gemini\-2\.5\-Flash gains\+31\.0\+31\.0pp \(from46\.0%46\.0\\%to77\.0%77\.0\\%\), GPT\-5 gains\+12\.0\+12\.0pp \(from77\.3%77\.3\\%to89\.3%89\.3\\%\), and GPT\-5\-mini gains\+10\.3\+10\.3pp \(from81\.7%81\.7\\%to92\.0%92\.0\\%\)\. This supports the claim that the catalog is a*model\-agnostic*routing artifact whose value compounds with improvements in model capabilities and model cost efficiency\.

### 4\.6Healing effect on individual instances

To isolate the steady\-state gain, we trace each of the 300 test instances across all evaluation checkpoints and compute two windowed pass rates: an*early*window \(steps 0–10, 11 evaluations\) and a*later*window \(steps 40–85, 10 evaluations\)\.

![Refer to caption](https://arxiv.org/html/2607.00016v1/figures/v8_case_study.png)Figure 5:Per\-instance analysis of 300 held\-out test instances\.*Left*: Scatter plot of early pass\-rate \(steps 0–10\) vs\. later pass\-rate \(steps 40–85\)\. Instances above the diagonal show improvement, with points further to the top\-left indicating stronger healing effects\.*Right*: Pass/fail status of each instance throughout the training process\. Dashed lines mark the early and later window boundaries\. The dominant orange→\\toblue transition in theHealedband is the visual signature of catalog\-driven improvement\.Figure[5](https://arxiv.org/html/2607.00016#S4.F5)\(left\) shows the per\-instance view:163163of300300instances \(54\.3%54\.3\\%\) improve from the early to later windows, while only5050\(16\.7%16\.7\\%\) worsen, yielding a3\.3:13\.3\{:\}1ratio of improved to degraded performance\. The heatmap \(Figure[5](https://arxiv.org/html/2607.00016#S4.F5), right\) visualizes the pass/fail trajectory of each individual instance over the course of training\. It highlights a subset of instances \(healed\) that transition to a consistent pass rate \(\>66\.7%\>66\.7\\%\) in the later window, demonstrating the system’s ability to systematically correct its routing failures\.

## 5Conclusion

We introduced Libra, a framework that shifts the paradigm of agentic information retrieval from static environment augmentation and model\-specific fine\-tuning toward dynamic, self\-evolving environments\. By encoding repository routing knowledge into plain\-text catalogs through an adversarial LLM optimization loop, Libra creates a persistent, model\-agnostic artifact that continuously improves based on interaction failures\. Our findings establish that a system trained entirely on self\-generated, synthetic queries can successfully transfer its learned routing capabilities to solve real\-world software engineering tasks\. Ultimately, Libra demonstrates that optimizing text\-based indices via interaction feedback offers a viable and adaptable alternative to traditional retrieval methods\.

### 5\.1Limitations and future work

While our results are promising, several limitations present opportunities for future work\. First, the LLM optimization loop is computationally intensive; exploring more efficient Healer designs and catalog structures could reduce this overhead\. Second, our evaluation assumes static repositories\. Because real\-world codebases evolve, developing mechanisms for versioning and incremental catalog updates is crucial for practical deployment\. Third, the current Prompter primarily generates single\-hop queries; synthesizing high\-quality, multi\-hop queries would better reflect real\-world complexity and provide a stronger training signal\. Finally, while we focused on software engineering benchmarks using a specific three\-agent architecture, extending Libra to other domains \(e\.g\., general documentation\) and exploring the broader design space of agent interactions remain important directions for future research\.

## References

- Anthropic \(2024\)The claude 3 model family: opus, sonnet, haiku\.Note:[https://www\.anthropic\.com/news/claude\-3\-family](https://www.anthropic.com/news/claude-3-family)Model card; Claude Code CLI documentation at[https://docs\.anthropic\.com/en/docs/claude\-code](https://docs.anthropic.com/en/docs/claude-code)\.Cited by:[§1](https://arxiv.org/html/2607.00016#S1.p1.1)\.
- Anysphere \(2024\)Cursor: the AI code editor\.Note:[https://www\.cursor\.com/](https://www.cursor.com/)Cited by:[§1](https://arxiv.org/html/2607.00016#S1.p1.1)\.
- M\. Bartolo, A\. Roberts, J\. Welbl, S\. Riedel, and P\. Stenetorp \(2020\)Beat the AI: investigating adversarial human annotation for reading comprehension\.Transactions of the Association for Computational Linguistics \(TACL\)\.External Links:[Link](https://arxiv.org/abs/2002.00293)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px2.p1.1)\.
- L\. Bonifacio, H\. Abonizio, M\. Fadaee, and R\. Nogueira \(2022\)InPars: data augmentation for information retrieval using large language models\.InSIGIR,External Links:[Link](https://arxiv.org/abs/2202.05144)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px2.p1.1)\.
- Z\. Chen, X\. Tang, G\. Deng, F\. Wu, J\. Wu, Z\. Jiang, V\. Prasanna, A\. Cohan, and X\. Wang \(2025\)LocAgent: graph\-guided LLM agents for code localization\.InProceedings of the Annual Meeting of the Association for Computational Linguistics \(ACL\),External Links:[Link](https://arxiv.org/abs/2503.09089)Cited by:[Appendix C](https://arxiv.org/html/2607.00016#A3.p1.1),[§1](https://arxiv.org/html/2607.00016#S1.p1.1),[§1](https://arxiv.org/html/2607.00016#S1.p3.1),[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px1.p1.1),[§4\.1](https://arxiv.org/html/2607.00016#S4.SS1.SSS0.Px3.p1.1),[§4\.1](https://arxiv.org/html/2607.00016#S4.SS1.SSS0.Px4.p1.1),[§4\.2](https://arxiv.org/html/2607.00016#S4.SS2.p1.1)\.
- Z\. Dai, V\. Y\. Zhao, J\. Ma, Y\. Luan, J\. Ni, J\. Lu, A\. Bakalov, K\. Guu, K\. B\. Hall, and M\. Chang \(2023\)Promptagator: few\-shot dense retrieval from 8 examples\.InInternational Conference on Learning Representations \(ICLR\),External Links:[Link](https://arxiv.org/abs/2209.11755)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px2.p1.1)\.
- D\. Edge, H\. Trinh, N\. Cheng, J\. Bradley, A\. Chao, A\. Mody, S\. Truitt, and J\. Larson \(2024\)From local to global: a GraphRAG approach to query\-focused summarization\.arXiv preprint arXiv:2404\.16130\.External Links:[Link](https://arxiv.org/abs/2404.16130)Cited by:[§1](https://arxiv.org/html/2607.00016#S1.p3.1),[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px1.p1.1)\.
- C\. Fernando, D\. Banarse, H\. Michalewski, S\. Osindero, and T\. Rocktäschel \(2023\)Promptbreeder: self\-referential self\-improvement via prompt evolution\.arXiv preprint arXiv:2309\.16797\.External Links:[Link](https://arxiv.org/abs/2309.16797)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px4.p1.1)\.
- B\. J\. Gutiérrez, Y\. Shu, Y\. Gu, M\. Yasunaga, and Y\. Su \(2024\)HippoRAG: neurobiologically inspired long\-term memory for large language models\.InAdvances in Neural Information Processing Systems \(NeurIPS\),External Links:[Link](https://arxiv.org/abs/2405.14831)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px1.p1.1)\.
- K\. He and K\. Roy \(2026\)SWE\-Adept: an LLM\-based agentic framework for deep codebase analysis and structured issue resolution\.arXiv preprint arXiv:2603\.01327\.External Links:[Link](https://arxiv.org/abs/2603.01327)Cited by:[§1](https://arxiv.org/html/2607.00016#S1.p4.1),[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px3.p1.1)\.
- C\. E\. Jimenez, J\. Yang, A\. Wettig, S\. Yao, K\. Pei, O\. Press, and K\. Narasimhan \(2024\)SWE\-Llama: fine\-tuning LLaMA for repository\-level software engineering\.Companion to SWE\-bench \(ICLR 2024\)\.Note:Bundled with SWE\-bench \(ICLR 2024\)\.Cited by:[§1](https://arxiv.org/html/2607.00016#S1.p2.1),[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px1.p1.1)\.
- B\. Jin, H\. Zeng, Z\. Yue, J\. Yoon, S\. Ö\. Arık, D\. Wang, H\. Zamani, and J\. Han \(2025\)Search\-R1: training LLMs to reason and leverage search engines with reinforcement learning\.InConference on Language Modeling \(COLM\),External Links:[Link](https://arxiv.org/abs/2503.09516)Cited by:[§1](https://arxiv.org/html/2607.00016#S1.p1.1),[§1](https://arxiv.org/html/2607.00016#S1.p3.1)\.
- O\. Khattab, A\. Singhvi, P\. Maheshwari, Z\. Zhang, K\. Santhanam, S\. Vardhamanan, S\. Haq, A\. Sharma, T\. T\. Joshi, H\. Moazam,et al\.\(2024\)DSPy: compiling declarative language model calls into state\-of\-the\-art pipelines\.InInternational Conference on Learning Representations \(ICLR\),External Links:[Link](https://arxiv.org/abs/2310.03714)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px4.p1.1)\.
- P\. Lewis, E\. Perez, A\. Piktus, F\. Petroni, V\. Karpukhin, N\. Goyal, H\. Küttler, M\. Lewis, W\. Yih, T\. Rocktäschel,et al\.\(2020\)Retrieval\-augmented generation for knowledge\-intensive NLP tasks\.InAdvances in Neural Information Processing Systems \(NeurIPS\),Cited by:[§1](https://arxiv.org/html/2607.00016#S1.p1.1)\.
- F\. Liu, X\. Liu, M\. Wang, H\. Liu, Y\. Liu, L\. Wang, Y\. Wang, and Y\. Zhang \(2025\)ExpeRepair: dual\-memory enhanced LLM\-based repository\-level program repair\.arXiv preprint arXiv:2506\.10484\.External Links:[Link](https://arxiv.org/abs/2506.10484)Cited by:[§1](https://arxiv.org/html/2607.00016#S1.p4.1),[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px3.p1.1)\.
- Y\. Ma, R\. Cao, Y\. Cao, Y\. Zhang, J\. Chen, Y\. Liu, Y\. Liu, B\. Li, F\. Huang, and Y\. Li \(2024\)Lingma SWE\-GPT: an open development\-process\-centric language model for automated software improvement\.arXiv preprint arXiv:2411\.00622\.External Links:[Link](https://arxiv.org/abs/2411.00622)Cited by:[§1](https://arxiv.org/html/2607.00016#S1.p2.1)\.
- A\. Madaan, N\. Tandon, P\. Gupta, S\. Hallinan, L\. Gao, S\. Wiegreffe, U\. Alon, N\. Dziri, S\. Prabhumoye, Y\. Yang,et al\.\(2023\)Self\-Refine: iterative refinement with self\-feedback\.InAdvances in Neural Information Processing Systems \(NeurIPS\),External Links:[Link](https://arxiv.org/abs/2303.17651)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px3.p1.1)\.
- R\. Nogueira, W\. Yang, J\. Lin, and K\. Cho \(2019\)Document expansion by query prediction\.arXiv preprint arXiv:1904\.08375\.External Links:[Link](https://arxiv.org/abs/1904.08375)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px2.p1.1)\.
- C\. Packer, S\. Wooders, K\. Lin, V\. Fang, S\. G\. Patil, I\. Stoica, and J\. E\. Gonzalez \(2024\)MemGPT: towards LLMs as operating systems\.InConference on Language Modeling \(COLM\),External Links:[Link](https://arxiv.org/abs/2310.08560)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px3.p1.1)\.
- J\. Pan, X\. Wang, G\. Neubig, N\. Jaitly, H\. Ji, A\. Suhr, and Y\. Zhang \(2025\)SWE\-Gym: an open environment for training software engineering agents and verifiers\.InInternational Conference on Machine Learning \(ICML\),External Links:[Link](https://arxiv.org/abs/2412.21139)Cited by:[§1](https://arxiv.org/html/2607.00016#S1.p2.1),[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px1.p1.1)\.
- R\. Pryzant, D\. Iter, J\. Li, Y\. T\. Lee, C\. Zhu, and M\. Zeng \(2023\)Automatic prompt optimization with “gradient descent” and beam search\.InConference on Empirical Methods in Natural Language Processing \(EMNLP\),External Links:[Link](https://arxiv.org/abs/2305.03495)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px4.p1.1)\.
- R\. G\. Reddy, T\. Suresh, J\. Doo, Y\. Liu, X\. P\. Nguyen, Y\. Zhou, S\. Yavuz, C\. Xiong, H\. Ji, and S\. Joty \(2025\)SweRank: software issue localization with code ranking\.arXiv preprint arXiv:2505\.07849\.External Links:[Link](https://arxiv.org/abs/2505.07849)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px1.p1.1),[§4\.1](https://arxiv.org/html/2607.00016#S4.SS1.SSS0.Px4.p1.1)\.
- S\. Robertson and H\. Zaragoza \(2009\)The probabilistic relevance framework: BM25 and beyond\.Foundations and Trends in Information Retrieval3\(4\),pp\. 333–389\.Cited by:[Appendix C](https://arxiv.org/html/2607.00016#A3.SS0.SSS0.Px1.p1.1),[§4\.1](https://arxiv.org/html/2607.00016#S4.SS1.SSS0.Px3.p1.1)\.
- P\. Sarthi, S\. Abdullah, A\. Tuli, S\. Khanna, A\. Goldie, and C\. D\. Manning \(2024\)RAPTOR: recursive abstractive processing for tree\-organized retrieval\.InInternational Conference on Learning Representations \(ICLR\),External Links:[Link](https://arxiv.org/abs/2401.18059)Cited by:[§1](https://arxiv.org/html/2607.00016#S1.p3.1),[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px1.p1.1)\.
- N\. Shinn, F\. Cassano, E\. Berman, A\. Gopinath, K\. Narasimhan, and S\. Yao \(2023\)Reflexion: language agents with verbal reinforcement learning\.InAdvances in Neural Information Processing Systems \(NeurIPS\),Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px3.p1.1)\.
- B\. Wang, W\. Xu, Y\. Li, M\. Gao, Y\. Xie, H\. Sun, and D\. Chen \(2026\)Improving code localization with repository memory\.InInternational Conference on Learning Representations \(ICLR\),Cited by:[Appendix C](https://arxiv.org/html/2607.00016#A3.p1.1),[§1](https://arxiv.org/html/2607.00016#S1.p1.1),[§1](https://arxiv.org/html/2607.00016#S1.p3.1),[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px1.p1.1),[§4\.1](https://arxiv.org/html/2607.00016#S4.SS1.SSS0.Px3.p1.1),[§4\.2](https://arxiv.org/html/2607.00016#S4.SS2.p1.1)\.
- G\. Wang, Y\. Xie, Y\. Jiang, A\. Mandlekar, C\. Xiao, Y\. Zhu, L\. Fan, and A\. Anandkumar \(2023a\)Voyager: an open\-ended embodied agent with large language models\.arXiv preprint arXiv:2305\.16291\.External Links:[Link](https://arxiv.org/abs/2305.16291)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px3.p1.1)\.
- K\. Wang, N\. Thakur, N\. Reimers, and I\. Gurevych \(2022\)GPL: generative pseudo labeling for unsupervised domain adaptation of dense retrieval\.InNAACL,External Links:[Link](https://arxiv.org/abs/2112.07577)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px2.p1.1)\.
- X\. Wanget al\.\(2024\)OpenHands: an open platform for AI software developers as generalist agents\.arXiv preprint arXiv:2407\.16741\.External Links:[Link](https://arxiv.org/abs/2407.16741)Cited by:[§1](https://arxiv.org/html/2607.00016#S1.p1.1)\.
- Y\. Wang, Y\. Kordi, S\. Mishra, A\. Liu, N\. A\. Smith, D\. Khashabi, and H\. Hajishirzi \(2023b\)Self\-Instruct: aligning language models with self\-generated instructions\.InACL,External Links:[Link](https://arxiv.org/abs/2212.10560)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px2.p1.1)\.
- Y\. Wei, O\. Duchenne, J\. Copet, Q\. Carbonneaux, L\. Zhang, D\. Fried, G\. Synnaeve, R\. Singh, and S\. I\. Wang \(2025\)SWE\-RL: advancing LLM reasoning via reinforcement learning on open software evolution\.arXiv preprint arXiv:2502\.18449\.External Links:[Link](https://arxiv.org/abs/2502.18449)Cited by:[§1](https://arxiv.org/html/2607.00016#S1.p2.1),[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px1.p1.1)\.
- C\. S\. Xia, Y\. Deng, S\. Dunn, and L\. Zhang \(2025\)Agentless: demystifying LLM\-based software engineering agents\.InInternational Conference on Software Engineering \(ICSE\),External Links:[Link](https://arxiv.org/abs/2407.01489)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px1.p1.1)\.
- C\. Xie, B\. Li, C\. Gao, H\. Du, W\. Lam, D\. Zou, and K\. Chen \(2025\)SWE\-Fixer: training open\-source LLMs for effective and efficient GitHub issue resolution\.InFindings of ACL,External Links:[Link](https://arxiv.org/abs/2501.05040)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px1.p1.1)\.
- C\. Xu, Q\. Sun, K\. Zheng, X\. Geng, P\. Zhao, J\. Feng, C\. Tao, and D\. Jiang \(2024\)WizardLM: empowering large language models to follow complex instructions\.InInternational Conference on Learning Representations \(ICLR\),External Links:[Link](https://arxiv.org/abs/2304.12244)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px2.p1.1)\.
- W\. Xu, Z\. Liang, K\. Mei, H\. Gao, J\. Tan, and Y\. Zhang \(2025\)A\-MEM: agentic memory for LLM agents\.arXiv preprint arXiv:2502\.12110\.External Links:[Link](https://arxiv.org/abs/2502.12110)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px3.p1.1)\.
- C\. Yang, X\. Wang, Y\. Lu, H\. Liu, Q\. V\. Le, D\. Zhou, and X\. Chen \(2024a\)Large language models as optimizers\.InInternational Conference on Learning Representations \(ICLR\),External Links:[Link](https://arxiv.org/abs/2309.03409)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px4.p1.1)\.
- J\. Yang, C\. E\. Jimenez, A\. Wettig, K\. Lieret, S\. Yao, K\. Narasimhan, and O\. Press \(2024b\)SWE\-agent: agent–computer interfaces enable automated software engineering\.InAdvances in Neural Information Processing Systems \(NeurIPS\),External Links:[Link](https://arxiv.org/abs/2405.15793)Cited by:[§1](https://arxiv.org/html/2607.00016#S1.p1.1),[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px1.p1.1)\.
- Z\. Yue, K\. Upasani, X\. Yang, S\. Ge, S\. Nie, Y\. Mao, Z\. Liu, and D\. Wang \(2026\)Dr\. Zero: self\-evolving search agents without training data\.arXiv preprint arXiv:2601\.07055\.External Links:[Link](https://arxiv.org/abs/2601.07055)Cited by:[§1](https://arxiv.org/html/2607.00016#S1.p4.1),[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px3.p1.1)\.
- M\. Yuksekgonul, F\. Bianchi, J\. Boen, S\. Liu, Z\. Huang, C\. Guestrin, and J\. Zou \(2025\)TextGrad: automatic “differentiation” via text\.Nature639,pp\. 609–616\.External Links:[Link](https://arxiv.org/abs/2406.07496)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px4.p1.1)\.
- E\. Zelikman, Y\. Wu, J\. Mu, and N\. D\. Goodman \(2022\)STaR: bootstrapping reasoning with reasoning\.InAdvances in Neural Information Processing Systems \(NeurIPS\),External Links:[Link](https://arxiv.org/abs/2203.14465)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px3.p1.1)\.
- A\. Zeng, M\. Liu, R\. Lu, B\. Wang, X\. Liu, Y\. Dong, and J\. Tang \(2024\)AgentTuning: enabling generalized agent abilities for LLMs\.InFindings of ACL,External Links:[Link](https://arxiv.org/abs/2310.12823)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px3.p1.1)\.
- B\. Zhang, D\. Guntur, Z\. Zuo, A\. Sharma, S\. Chaudhari, W\. Zhao, F\. Dernoncourt, P\. Mathur, R\. Rossi, and N\. Lipka \(2026\)Test\-time strategies for more efficient and accurate agentic RAG\.arXiv preprint arXiv:2603\.12396\.External Links:[Link](https://arxiv.org/abs/2603.12396)Cited by:[§1](https://arxiv.org/html/2607.00016#S1.p1.1),[§1](https://arxiv.org/html/2607.00016#S1.p3.1)\.
- Y\. Zhou, A\. I\. Muresanu, Z\. Han, K\. Paster, S\. Pitis, H\. Chan, and J\. Ba \(2023\)Large language models are human\-level prompt engineers\.InInternational Conference on Learning Representations \(ICLR\),External Links:[Link](https://arxiv.org/abs/2211.01910)Cited by:[§2](https://arxiv.org/html/2607.00016#S2.SS0.SSS0.Px4.p1.1)\.

## Appendix AFile vs\. function accuracy correlation

Figure[6](https://arxiv.org/html/2607.00016#A1.F6)reports test\-set file and function accuracy along thesympytraining trajectory of §[4\.2](https://arxiv.org/html/2607.00016#S4.SS2)\(GPT\-5\-mini Solver,max\_turns=5\\texttt\{max\\\_turns\}=5\); the two curves move together across every step\. Note that thesympytrain and test splits were generated by two slightly different Prompter variants \(footnote[5](https://arxiv.org/html/2607.00016#footnote5)\), so the file/function gap visible here is a property of the test\-time gold annotations and not of the training signal\. Identical correlation behaviour holds on the other1111repositories, where train and test are produced by the same Prompter; we report file accuracy as our primary metric throughout the paper\.

![Refer to caption](https://arxiv.org/html/2607.00016v1/figures/file_vs_func.png)Figure 6:File vs\. function accuracy on thesympyheld\-out test set across the first1010training steps of the trajectory in §[4\.2](https://arxiv.org/html/2607.00016#S4.SS2)\. The two metrics are highly correlated \(r\>0\.95r\>0\.95\); we report only file accuracy hereafter\.
## Appendix BSaturation analysis on recent models

We chose GPT\-5\-mini atmax\_turns=5\\texttt\{max\\\_turns\}=5as the training\-time Solver after observing that frontier models saturate the benchmark even with no catalog\. Table[3](https://arxiv.org/html/2607.00016#A2.T3)reports the no\-catalog baseline for several recent models on the same300300\-instance test set, all run through the Libra Solver agent atmax\_turns=20\\texttt\{max\\\_turns\}=20\. Above∼85%\\sim 85\\%file\-level accuracy, methodological gains from training become hard to distinguish from noise, and the portion of failures that are due to the model giving an alternative valid fix becomes significant\. We therefore picked a model for which a tightly\-budgeted \(55\-turn\) configuration still leaves substantial headroom on this test set\.

Table 3:No\-catalog baselines on the Prompter generated300300\-instance test set for sympy\.
## Appendix CBaseline implementation details

This appendix expands on the LocAgent\[Chenet al\.,[2025](https://arxiv.org/html/2607.00016#bib.bib2)\]and RepoMem\[Wanget al\.,[2026](https://arxiv.org/html/2607.00016#bib.bib3)\]baselines summarized in §[4\.1](https://arxiv.org/html/2607.00016#S4.SS1)\. Both share Libra’s overall agentic\-localization setup \(same Solver model, same turn budgets, same gold targets\) but differ in the*retrieval substrate*the Solver is given: LocAgent exposes a structure\-aware repository graph in place ofBash/Read, while RepoMem layers an additional set of frozen commit\-history tools on top of LocAgent\. Crucially, neither substrate is rewritten during the run, which is the orthogonal axis Libra adds\.

#### LocAgent\.

LocAgent builds a directed heterogeneous graph over the repository \(nodes: directories, files, classes, functions; edges: contain, import, invoke, inherit\) and layers a sparse, hierarchical entity index on top of it: \(1\) an entity\-ID lookup keyed by fully qualified name, \(2\) an entity\-name dictionary keyed by short name \(with case\-insensitive andClass\.methodsplitting fallbacks\), \(3\) a BM25 inverted index\[Robertson and Zaragoza,[2009](https://arxiv.org/html/2607.00016#bib.bib57)\]over entity IDs as a fuzzy fallback when \(1\)/\(2\) miss, and \(4\) a BM25 inverted index over each entity’s code chunks for keywords that never appear in any ID \(e\.g\. global variables\)\. The Solver receives three tools in place of Libra’sBash/Read:

- •SearchEntity— keyword search through the four\-layer cascade above; returns matching entities with their source at one of three detail levels \(fold / preview / full\) chosen by match count\.
- •TraverseGraph— type\-aware multi\-hop BFS along contain/import/invoke/inherit edges\.
- •RetrieveEntity— full source retrieval for a chosen node\.

We use LocAgent’s reference repository defaults: each BM25 index is queried atsimilarity\_top\_k=10, with display further capped at the top 5 hits per query \(and at top 3 for non\-file/\-directory entities in the entity\-ID layer\)\. When the entity\-ID BM25 layer returns nothing, a smallrapidfuzztoken\-set retrieval \(top\-3\) is consulted before falling through to the content\-BM25 layer\.

#### RepoMem\.

RepoMem extends LocAgent with four commit\-history tools that expose*frozen*memory mined offline from the repository’s git log:

- •SearchCommit,ExamineCommit— episodic memory, BM25\-matched against commit messages from a window of7,0007\{,\}000prior commits\.
- •ViewSummary,SearchSummary— semantic memory, LLM\-generated summaries of theK=200K\{=\}200most frequently edited files\.

The memory itself is built once before evaluation and never updated by the Solver; failures cannot feed back into the index\. This contrasts with Libra, where the catalog is the artifact under training and is continuously rewritten by the Healer in response to Solver failures\.

## Appendix DRelease artifacts

We release code and Prompter data to facilitate reproducibility\. The top\-levelREADME\.mdcontains paste\-ready commands for every workflow\. The code and data are released under the CC BY NC 4\.0 License, see README and LICENSE for details\.

#### Code\.

- •agents/— the three frozen agents \(Prompter, Solver, Healer\) and their sharedRead/Bashtools\. Each role has an OpenAI\-compatible backend \(\*\_plain\.py\) and a ClaudeAgentSDK backend \(\*\_ant\.py\)\.
- •orchestrator/— the training loop \(train\.py, implementing Algorithm[1](https://arxiv.org/html/2607.00016#algorithm1)\) and the single\-shot replay evaluator \(evaluate\.py\), together with their YAML configs \(train\_config\.yaml,eval\_config\.yaml\) which expose every hyperparameter used in the experiments\.
- •scripts/init\_catalogs\.py\(seeds the emptycatalog\.mdfiles the Healer rewrites\) andscripts/replay\_test\_eval\.py\(replays the test set against any historical catalog snapshot\)\.
- •llm\.py\(LLM client\),pyproject\.toml\+uv\.lock\(pinned environment\),\.env\.example,README\.md\.

#### Data \(1313configs,≈86\\approx\\\!86MB Parquet\)\.

- •prompter\_<repo\>\(1212configs, one perSWE\-bench Literepository\) — synthetic Q/A pairs from the Prompter at the per\-repo base commit listed in Table[5](https://arxiv.org/html/2607.00016#A5.T5)\. Each config has atrainand atestsplit \. See Table[5](https://arxiv.org/html/2607.00016#A5.T5)for the per\-repository instance counts \(90,73690\{,\}736train and3,2873\{,\}287test in total\)\. Schema:\(instance\_id, problem\_statement, gold\_files, gold\_functions, gold\_reasoning, chunk\_content, line\_numbers, is\_valid\_chunk\)\.
- •SWE\-bench\_Lite\_Libra\(11config,199199instances\) — the199199SWE\-bench Litebug reports that re\-anchor on a single base commit per repository \(Table[5](https://arxiv.org/html/2607.00016#A5.T5)\), augmented withgold\_files/gold\_functionsderived from the ground\-truth patches\.

## Appendix ETraining cost breakdown

Table[5](https://arxiv.org/html/2607.00016#A5.T5)reports the one\-time Prompter data\-generation cost and the per\-epoch training cost for each of the 12SWE\-bench Literepositories\. The Prompter and Healer both run Claude Opus 4\.6; the Solver runs GPT\-5\-mini at 5 turns\. We split the training cost into Train\-Eval \(Solver evaluation on each training batch\) and Healer \(catalog\-rewrite proposer \+ writer agents\); their sum is the total Training cost reported in the rightmost column\. Test\-set evaluation cost \(the periodic test\-eval that runs everyNNbatches during training, plus any standalone test\-eval\) is excluded\. Every repository trains for exactly one epoch\. All dollar figures in this section are computed from the per\-token list prices in Table[4](https://arxiv.org/html/2607.00016#A5.T4)\.

Table 4:List prices \(USD per 1M tokens\) used to compute every cost figure in this section\.cache\_ris the cached\-input read rate; Anthropic additionally charges a one\-time cache\-creation rate \($6\.25/1M for Opus 4\.6\) which we fold into the input column when relevant\.Table 5:Per\-repository training parameters and cost breakdown\.*Step size*is the number of instances per healer batch\.*Base Commit*is the single pinned commit per repo used for training and evaluation\.*Training*= Train\-Eval \+ Healer\.∗\*Sympy Prompter data generation predates per\-call cost instrumentation; the value is estimated by extrapolating from the other repos\.

#### Zoom: per\-step cost on django\.

Figure[7](https://arxiv.org/html/2607.00016#A5.F7)unpacks the django row of Table[5](https://arxiv.org/html/2607.00016#A5.T5)step\-by\-step\. The root catalog is always provided in the system prompt, so as it grows, we notice that the Solver’s input token grows accordingly\. However, the cache\-hit rate also climbs as the root catalog stays the same across queries within a batch\. As a result, the Train\-Eval cost stays relatively flat\. Healer cost dominates the bill as we’re using the higher\-end Claude Opus 4\.6 model to rewrite the catalogs\.

![Refer to caption](https://arxiv.org/html/2607.00016v1/figures/django_usage_curves.png)Figure 7:Per\-step training cost on django\.*Top row*: Train\-Eval / Healer / total $ per step \(left\), Solver input tokens \(middle\), Solver output tokens \(right\)\.*Bottom row*: cumulative catalog size in KB \(left\), Solver cache\-hit ratecache\_read / input\(middle\), accumulated cost \(right; final values Train\-Eval$​48\.64\\mathdollar 48\.64, Healer$​119\.54\\mathdollar 119\.54, total$​168\.18\\mathdollar 168\.18, matching the django row of Table[5](https://arxiv.org/html/2607.00016#A5.T5)modulo cent\-level rounding\)\.

## Appendix FTraining dynamics: additional case studies

For reference, we walk through two healed\-stable test instances from the top\-left cluster of Figure[5](https://arxiv.org/html/2607.00016#S4.F5)\. For each instance the*trajectory*string records the evaluation outcome on that instance every55training steps \(at steps\{0,5,…,85\}\\\{0,5,\\ldots,85\\\}\),Tfor a file\-level pass andFfor a fail, with bars separating the early \(0−100\{\-\}10\), transition \(15−3515\{\-\}35\) and late \(40−8540\{\-\}85\) windows\. The*trigger*and*diff*we list are the training\-batch failure and the resultingcatalog\.mdedit that we believe fixed the instance stably going forward\.

### 1\.prompter\_173—\_solve\_system\(nonlinear path vs\. linear\-path trigger\)

Test\.Goldsolvers/solvers\.py::\_solve\_system; trajectoryFFF\|FFTFF\|TTTTTTTTTT; question:*“When iteratively solving a system of equations symbol by symbol, what happens if a candidate solution for one variable contains references to variables that were already determined in earlier iterations?”*\(the*nonlinear*branch\)\.

Trigger \(heal step 20\)\.prompter\_8387; same gold function but a*different sub\-path*:*“How does the system of simultaneous first\-degree symbolic equations get converted into an augmented coefficient table before being dispatched to a linear\-system resolution routine?”*\(the*linear*branch\)\. Solver predictedsolvers/solveset\.py::linear\_eq\_to\_matrix\.

Diff \(solvers/catalog\.md\)\.

\-‘\_solve\_system\(exprs,symbols,\*\*flags\)‘\(L1631\-L1829\)\-

\-Solvessystemsofequations\.Fornonlinearpolynomialsystems

\-withmoreunknownsthanequations,enumeratessubsetsoffree

\-symbols\(sizedtomatchequationcount\),calls

\-‘solve\_poly\_system‘oneachsubset,\.\.\.

\+‘\_solve\_system\(exprs,symbols,\*\*flags\)‘\(L1631\-L1829\)\-

\+Solvessystemsofequations\.

\+\-Linearpath:whenallpolyexpressionsarefirst\-degree,

\+constructsanaugmentedcoefficientmatrix\(nx\(m\+1\)\)by

\+iteratingmonomialterms,placingeachdegree\-1coefficientat

\+thecorrespondingslot\.\.\.

\+\-Nonlinearpath:forpolynomialsystemswithmoreunknownsthan

\+equations,enumeratessubsetsoffreesymbols\(sizedtomatch

\+equationcount\),calls‘solve\_poly\_system‘oneachsubset,

\+anddiscardscandidatesolutionsthatre\-introducealready\-

\+eliminatedsymbols\.

The trigger was about the*linear*branch; the test query lands on the*nonlinear*branch via the same now\-richer entry\.

### 2\.prompter\_157—lib\_interval\.cosvia wholesale interval\-math enumeration

Test\.Goldplotting/intervalmath/lib\_interval\.py::cos; trajectoryFFT\|TTTTT\|TTTTTTTTTT\(a clean flip from no useful prediction at step 5 to steady\-state from step 10\); question:*“I’m getting incorrect results when evaluating the cosine of a plain numeric value \(not a range\) through the interval math plotting module\. The output looks like it’s returning the sine value instead\. Where is this likely implemented?”*

Trigger \(heal step 5\)\.prompter\_2097and the near\-duplicateprompter\_2279; both have goldplotting/intervalmath/lib\_interval\.py::cosh\(*different function*, same file\):*“When computing the hyperbolic cosine over a range that crosses zero \(e\.g\., from a negative to a positive value\), how does the interval arithmetic library determine the lower bound of the result?”*Solver predictedcore/expr\.py::\_eval\_intervalfor the first andfunctions/elementary/hyperbolic\.py::Cosh\.\_eval\_intervalfor the second — both wrong files in the wrong submodule\.

Diff \(sympy/catalog\.md, root catalog\)\.

\-‘intervalmath/‘\-Intervalarithmeticengine\(‘interval\(\)‘\)

foradaptiveimplicit\-plotsampling;usedby‘plot\_implicit‘\.

\+\-‘lib\_interval\.py‘:interval\-awaremathfunctions\(‘sin‘,

\+‘cos‘,‘cosh‘withzero\-crossingminimumdetection,‘exp‘,

\+‘log‘,‘atan‘,etc\.\)\.

Even though both trigger queries asked specifically aboutcosh’s zero\-crossing minimum logic, the Healer’s edit was written at the file level: a single bullet enumerating the interval\-aware math functions inlib\_interval\.py, includingcosverbatim\. The test query aboutcossin/cos confusion in the interval\-math module then flips on the very next evaluation step \(heal step5→5\\totest step1010\) purely because the catalog now mentionslib\_interval\.py::cosby name\.

## Appendix GAgent prompts

This appendix reproduces verbatim the prompts used for the three frozen agents in our main experiments\.

### G\.1Prompter

The Prompter receives a∼100\\sim\\\!100\-line code chunk together with a randomly\-sampled additional rule and emits a JSON object containing a developer\-style question, afile::functionanswer, and a booleanis\_valid\_chunkflag \(used to drop pure\-boilerplate chunks\)\.

#### System prompt \(prompter\_system\)\.

YougenerateevaluationQ/Apairsfromcodechunks\.EachpairtestswhetheranagenticRAGsystemcanlocatethecorrectfileandfunctionforadeveloper'squerybasedpurelyonsemanticunderstanding,NOTkeywordmatching\.

Thechunkyoureceiveistheground\-truthlocation\.Yourjob:writeaquestionarealdeveloperwouldaskthatthischunkanswers,thengivetheanswerasafile::functionlocator\.

\#\#\#QUESTIONSTYLES\(varyacrossthese\)

\-"Howdoesthesystemhandle\[concept\]?"\-targetsaspecificmechanism

\-"Igot\[error/symptom\]when\[operation\]"\-bugreport/debugging

\-"Howtosupport\[usecase\]in\[area\]?"\-featureextension

\-"Whereis\[behavior\]implemented?"\-localization

\#\#\#RULES

1\.\*\*Noself\-reference\.\*\*Neversay"inthissnippet","theprovidedcode",etc\.Writeasifyou'readeveloperqueryingacodebase\.

2\.\*\*Groundthequestionintheenclosingfile\.\*\*Youmayexplorebeyondtheprovidedchunk\-readsurroundingcodeinthesamefile,orreadotherpartsoftherepoforcontext\.However,thefinalquestionmustbeanswerablebythefilethatcontainstheprovidedchunk\.

3\.\*\*Targetcorelogic,notnames\.\*\*Don'tjustask"whatdoesthiscodedo?"\-askaboutaspecificdetail,edgecase,ormechanisminsideit\.

4\.\*\*NOEXACTIDENTIFIERS\(CRITICAL\)\.\*\*YoumustNOTusetheexactnamesofclasses,functions,variables,orfilesinyourquestion\.Insteadofasking"HowdoestheWavefunctionclassdeterminelimits\.\.\.",ask"Howdoesthesystemrepresentquantumstateswhendeterminingcoordinateboundaries\.\.\."\.Forcetheevaluatingagenttousesemanticsearch\.

5\.\*\*Deadchunks\.\*\*Ifthechunkispureboilerplate\(onlyimports,whitespace,closingbrackets\)withnomeaningfullogic,setis\_valid\_chunktofalse\.

6\.Strictlyfollowtheadditionalrulesprovidedbytheuserifany\.

\#\#\#ANSWERFORMAT

Usethemostspecificlocatorvisibleinthechunk:

\-Top\-levelfunction:\`filepath::function\_name\`

\-Methodonaclass:\`filepath::ClassName\.method\_name\`

\-Ifmultiplefunctionsarerelevant,picktheprimaryone\.

\#\#\#REASONING\(thinkstepbystepbeforegenerating\)

1\.Explorethechunk'senclosingfileandmoduleandwriteabriefsummaryofthefunctionsofthechunk,fileandmoduleintherepo\.

2\.Identifythekeyelementsinthechunk:functions,classes,logicbranches,comments,edgecases\.

3\.\*\*ListForbiddenWords:\*\*Explicitlylisttheexactclassnames,functionnames,andhighlyspecificvariablenamesfoundinthechunk\.Youarebannedfromusingtheseinthequestion\.

4\.Pickthemostinterestingornon\-obviousaspect\-abug,anedgecase,adesignchoice,aspecificbehavior\.

5\.Writeaquestiontargetingthataspectusingconceptualsynonymsinsteadofyourforbiddenwords\.

\#\#\#TOOLS

Whenusingtools\(Read,Grep,Bash,etc\.\)toexplorethecodebase,alwaysuse

\*\*relativepaths\*\*\(e\.g\.\`core/expr\.py\`\),neverabsolutepaths\.Theworking

directoryisalreadysettotherepositoryroot\.

#### User template \(prompter\_user\_template\)\.

Filepath:$filepath

Lines:$start\_line\-$end\_line

\-\-\-CHUNK\-\-\-

$chunk\_content

\-\-\-ENDCHUNK\-\-\-

\-\-\-ADDITIONALRULES\-\-\-

$additional\_rules

\-\-\-ENDADDITIONALRULES\-\-\-

GenerateanevaluationQ/Apairforthischunk\.OutputrawJSONonly\-nomarkdownfences,noextratext\.

\{

"reasoning":"Step\-by\-stepreasoningfollowingthesystempromptguidelines\.",

"is\_valid\_chunk":true,

"question":"Arealisticdeveloperquery\.",

"answer":"filepath::Class\.methodorfilepath::function",

\}

#### Additional rules\.

At each call we sample one rule uniformly at random and substitute it into$additional\_rules\. The two rules used in our runs are:

\#rule\_banDomainVocab

\*\*NOMODULE/DOMAINVOCABULARY\(CRITICAL\)\.\*\*DoNOTusewordsthatmapdirectlytomoduleordirectorynamesinthecodebase\.Bannedtermsinclude\(butarenotlimitedto\):$ban\_domain\_vocabulary\.Anywordthatwouldreturnhitsifyou\`grep\`\-editagainstthecodebase'sdocstringsorcommentsisBANNED\.Replaceconcretelibraryjargonwithitsabstractformalequivalent\.

\*\*Examples:\*\*

Instead,describetheconceptabstractlyorfromauser\-behaviorperspective\.

\*\*Examples:\*\*

\-BAD:"Howdoesthegeometrymodulecomputetrianglearea?"

GOOD:"Howdoesthesystemcomputetheareaofathree\-sidedplanarfigure?"

\-BAD:"WhereispolynomialGCDimplemented?"

GOOD:"Whereisthegreatest\-common\-divisoralgorithmforsymbolicalgebraicexpressionsimplemented?"

\-BAD:"Howdoestheprettyprinterhandlematrixdisplay?"

GOOD:"Howdoesthehuman\-readableoutputformatterrendertwo\-dimensionaltabulardatastructures?"

\#rule\_preferEdgeCase

\*\*PREFEREDGECASESOVERPRIMARYPURPOSE\(CRITICAL\)\.\*\*Yourquestionshouldtargetaspecificconditionalbranch,edgecase,error\-handlingpath,orspecial\-caselogicvisibleinthechunk\-NOTthemain/obviouspurposeofthecode\.Focusonif/elsebranches,try/exceptblocks,boundarychecks,type\-specificdispatches,orfallbackbehaviors\.

\*\*Examples:\*\*

\-BAD:"Howdoesthematrixconstructorwork?"

GOOD:"Whathappenswhenthebuilderreceivesanentrythatisitselfatwo\-dimensionalarrayratherthanascalar?"

\-BAD:"Howdoestheparsertokenizeinput?"

GOOD:"Howdoesthetokenizerrecoverwhenitencountersanunterminatedstringliteralatend\-of\-file?"

\-BAD:"Whereisthecachinglayerimplemented?"

GOOD:"Whatfallbackbehaviortriggerswhenthecachestorereportsaconnectionfailuremid\-read?"

### G\.2Solver

The Solver receives only the problem statement as the user message; the rootcatalog\.mdis inlined into the system prompt\. We report results withtop\_k=1\\texttt\{top\\\_k\}=1in the main paper; thetop\_k=5\\texttt\{top\\\_k\}=5variant differs only in output schema\.777In the released code, the Solver is namedLocator\(visible in the template identifierlocator\_plain\_system\_templatebelow\)\. The two names refer to the same agent\.

#### System prompt \(locator\_plain\_system\_template\)\.

Youareabug\-localizationagent\.Givenaproblemstatement,explorethe

repositorytofindthesinglemostrelevantfileandfunctionthatwould

needtobeeditedtofixtheissue\.

Therepositorycontainscatalog\.mdfilesattheprojectrootandwithin

eachmodule/sub\-package\.Thesecatalogssummarizethecontentsandpurpose

oftheirrespectivedirectories\.Therootcatalog\.mdisprovidedbelow\.Useittoorientyourself,\*\*thendrillintomodule\-levelcatalog\.mdfilesasneeded\*\*\.

\#\#Rootcatalog\.md

$catalog

\#\#Toolsavailable

\-read:readafilebyitspath\(relativetothereporoot\)\.Optionally

specifystart\_lineandend\_linetoreadonlyaportionofthefile\.

\-bash:runashellcommand\.ONLYls,grep,andfindarepermitted\.

\#\#Outputformat

Whenyouareconfident,respondwithONLYaJSONobject\(noextratext\):

\{"file":"<relativepath\>","function":"<Class\.methodorfunction\_name\>","reasoning":"<onesentence\>"\}

### G\.3Healer

The Healer receives one target catalog file and a batch of Solver failure reports whosetarget\_mdwas assigned to that file by a deterministic path\-prefix match\. It diagnoses each failure, optionally drops it, and applies all surviving edits in\-place viaRead/Edit/Grep/Bashtools\.

#### System prompt \(healer\_system\_template\)\.

Youareacatalog\-healingagent\.Youwillreceiveabatchoffailurereports

fromacode\-localizationsystem\-caseswheretheSolverpredictedthewrong

fileforagiven\*\*ProblemStatement\*\*\.Eachfailurealsoincludesa\*\*Gold

Reasoning\*\*\-thecorrectchainofthoughtthatwouldhaveledtotheright

answer\.Yourjobistodiagnoseeachfailure,identifythosethatpinpointa

gapinthecatalog,andimprovethecatalogin\-placetoclosethatgap\.

You'llbeworkingunderthedirectory$cwd\.

\#CatalogSpec\(theartifactyouarehealing\)

AcatalogfileisanavigationaidfortheSolver:terse,definitiveprose

thatletsitpicktherightfile/modulewithoutreadingthesource\.

Structure:

\-\*\*Modulecatalog\*\*:top\-levelsectionsgroup\`\.py\`filesbyrole\.Each

\`\.py\`file\(linkingtosource\)isasub\-headerinsideitssection\.

\-\*\*Rootcatalog\*\*:sameshape,buteach\*\*submodule\*\*playstheroleofa

\`\.py\`file\-onesub\-headerpersubmodulewithasummaryandlinktoits

modulecatalog\.

\-Optional\*\*Glossary\*\*,\*\*ArchitectureOverview\*\*,and\*\*Notes\*\*sections

atthetop\.

\-Testfilesareexcluded\.

Per\-entrycontent\(fileorsubmodulesub\-header\):

1\.Aone\-linesummaryofwhatthefile/submoduledoes\.

2\.Functions/classeswith\*\*adaptiveverbosity\*\*\-matchdetailtocomplexity:

\-Trivial/obvious\-omitentirely\.

\-Simplehelpers/utils\-listnameordeclarationonly\.

\-Moderatecomplexity\-name\+shortsummary\.

\-Highcomplexity\-bulletlistofkeyfunctionalities,logicflow,

components,etc\.

Eachlistedsection\(class,function,method,etc\.\)MUSTbeannotated

withitssourcelinerangeintheform\`\(L<start\>\-L<end\>\)\`immediately

afterthename/declaration\(e\.g\.\`process\_batch\(L42\-L88\)\`\)\.Verifyrangesbyreadingthesourcefile\-donotguess\.

3\.\(Optional\)brief"Caveats"noteforsurprisesoreasy\-to\-misusebehavior\.

Fixesmust\*\*strictly\*\*followtheseconstraints:

\-Beconcise\.

\-Bedefinitive,notdescriptive\(assertwhatsomethingIS,nothowitworks\)\.

\-Respectadaptiveverbosity\-don'tpromotetrivialentriestoverboseones\.

\-Onlyeditthetargetcatalogfilespecifiedintheusermessage\.

\-Nevercreatenew\.mdfilesordeleteexistingones\.

\-AnyaddedormodifiedcontentmustconformtotheCatalogSpecabove

\(requiredstructure\+per\-entrycontent\)\.Donotinventnewstructural

conventionsthatdeviatefromthespec\.

\-DoNOTcross\-referenceentries\-performSharpenEntryinstead\.

\-DoNOTincludeimplementationdetails\.

\-DoNOTincludeexamples\.

Maintainthesecataloginvariants:

\-Eachbullet/line<=250characters;iflonger,splitintomultiplebullets\.

\-Eachsection<=20bulletpoints;ifmore,mergeandpurgeto<=15bullets

keepingonlythemostdiscriminatinginformation\.

Ifafailurecanonlybefixedbyviolatingtheabove,dropit\.Generalizabilitybeatscompleteness\.

YouwillbegivenONEcatalogfiletofocuson\.FollowthesestepsINORDER\.

Usetools\(Read,Edit,Grep,Bash,etc\.\)freely\.

\#Steps

\#\#Step1\-Gatherevidence

Foreachfailureinthebatch:

\-Study\*\*GoldChunk\*\*\-thecodetheSolvershouldhavefound\.Optionally

readthefull\*\*GoldFile\*\*formorecontext\.

\-Read\*\*PredictedFile\*\*\-whattheSolverchose,toseewhyitlooked

plausible\.

\-Compare\*\*GoldReasoning\*\*to\*\*PredictionReasoning\*\*\.Identifyprecisely

wheretheSolverdiverged\.

\#\#Step2\-Triage:isthecatalogactuallytoblame?

Beforediagnosing,decidewhetherthecatalogisresponsible\.Dropthe

failure\(noedit,countasdropped\)ifANYofthefollowinghold\-theseare

\*\*not\*\*catalogissues:

\-\*\*Solverreasoningerror\*\*\-thecatalogcontextwasadequate,butthe

Solverfailedtoreasonaboutorbreakdowntheproblemcorrectly\.

\-\*\*Ambiguousproblemstatement\*\*\-thequestionisunderspecifiedor

misleading;nocatalogchangecouldhavedeterministicallyroutedthe

Solvertothegoldtarget\.

\-\*\*Intra\-fileconfusion\*\*\-theproblemhingesonimplementationdetails

insidethefilethataren'ttiedtoitshigh\-levelrole\.

\-\*\*Out\-of\-scopetarget\*\*\-thegoldfileisatestfileorotherwise

excludedfromthecatalogspec\.

\-\*\*Solvergivescorrectalternative\*\*\-thepredictedfilecanfix/answertheproblem

justaswellasthegoldfile;it'sessentiallyanalternativeanswer\.

Skiptherestofthestepsifthefailureisnotcatalog\-attributable\.

\#\#Step3\-Diagnoserootcause

Foreachremaining\(catalog\-attributable\)failure,pickoneormoreof:

\-\*\*InformationGap\*\*\-thecatalogentryforthegoldtargetismissingthe

keysignal\(function/class/role\)thatwouldhaveanchoredtheSolver\.

\-\*\*CatalogNoise\*\*\-theentryistooverbose/over\-detailed;therelevant

signalisburied\.Oftenmeansverbosityissettoohighforthecomplexity\.

\-\*\*NarrowSeparation\*\*\(common\)\-thegoldentryandaconfusablesibling

entrydon'tdistinguishtheirfunctionalitiesclearly\.

\-\*\*StructuralIssue\*\*\-entriesaremis\-grouped,mis\-sectioned,orthe

cataloglacksthesections/glossary/caveatstheSolverneeded\.

\#\#Step4\-Proposefixes

Choosefixesthattargetthediagnosedrootcause\.Examples\(notexhaustive\):

\-\*\*EnrichEntry\*\*\-addthemissingsignalsothegoldtargetis

distinguishablefromcommonlyconfusedalternatives\.

\-\*\*CompactEntry\*\*\-droptheentrytoalowerverbositytier\(e\.g\.moderate

\-\>simple,orhigh\-\>moderate\);stripimplementationnoise\.

\-\*\*SharpenEntry\*\*\-rewritedefinitionsofsimilarentriessoeachone

assertswhatituniquelyowns\.

\-\*\*Reorganize\*\*\-regroupentriesintosectionsthatbetterreflectrole\.

\-\*\*MetaChange\*\*\-add/modifyglossary,caveats,orappendixentrieswhen

thedisambiguatingsignaliscross\-cutting\.

\#\#Step5\-Applyfixes

Applyallnecessarychangestothetargetcatalogfilein\-placeusingyour

editingtools\.Combineinsightsfrommultiplefailures\-ifseveralfailures

pointtothesamegap,makeonecoherentfixratherthanredundantedits\.If

thereare\>5fixesrequired,usetheagenttooltoparallelizefixeswith

subagents\.

#### User template \(healer\_user\_template\)\.

TargetCatalogFile:$target\_md

Beloware$n\_failureslocalizationfailure\(s\)whereTargetCatalogFilemaybe

relevant\.Diagnoseeachoneandapplyanynecessaryfixestothetargetfile\.

$failures\_block

#### Per\-failure template \(failure\_template\)\.

The user message embeds one block per failure, formatted as:

\-\-\-Failure$failure\_idx\-\-\-

Instance:$instance\_id

ProblemStatement:

$problem\_statement

GoldFile:$gold\_files

GoldFunction:$gold\_functions

GoldChunk\(lines$line\_numbers\):

$chunk\_content

GoldReasoning:

$gold\_reasoning

PredictedFile:$pred\_file

PredictedFunction:$pred\_func

PredictionReasoning:

$reasoning