\section{Limitations and Conclusion}
The completed measurements establish executable restoration and a trained current-correctness predictor on the development cohort. G001 contains only three initially unsuccessful candidates and observes no repairs; its action differences largely reflect damage from budget-limited restart. The failure-enriched F1 diagnostic finds replicated repair in one task but no cross-task action crossover. Under the fixed final-state policy, these results do not support an action-conditioned success--cost advantage or justify fitting a more complex controller. The 32 development states represent eight task clusters, limiting threshold selection and baseline comparisons despite repetition over three training seeds.

The first controller makes one decision after a candidate patch is produced and uses one fixed repair model. It does not establish performance for repeated decisions along an entire trajectory or transfer across repair models. Its success probabilities are conditioned on a particular scaffold and budget; changing either can change calibration. The public-test menu is based on static path association, so inadequate coverage or misleading feedback can limit every selector built on that menu.

Data collection executes several actions per training state. Any deployment cost advantage must therefore be reported together with the cost of collecting labels and training the controller. CPU memory and timing measurements cannot determine GPU throughput, and low-rank adaptation reduces trainable parameters without eliminating the activation memory needed to process long inputs.