Rereading a whole repository after one failed input can add information without clarifying its cause. Historical focused repair in my browser began with the failure boundary and nearby callers, expanding when evidence required it. That automatic repair path is now retired, but its investigation contract remains useful to explain.
An error code routes investigation without proving its cause
RepairContext uses error code, cause, tool, message and explicit source location to select candidates. Routing tables for input, frames, files and navigation narrow the starting point. The same ELEMENT_OBSCURED can involve a real overlay, painting or an old document, so a routed function is not automatically the cause.
Only paths present in the manifest remain, with a bounded number selected. Failed-check feedback and already changed files get priority. Empty hints can start with an exact symbol or narrow literal search. If the initial route is wrong, related modules can be expanded one step at a time. Sending every file and forcing a fix inside the first guessed candidate are both poor substitutes for following evidence.
Retain the current file hash alongside each fragment
Initial context pairs lines around anchors with the current full-file hash. A fragment may not contain the whole function. Ordinary routes and legacy bundled-template routes also have different line/character limits. Reading one small window is not described as understanding every semantic detail of the file.
Additional lookup requests an exact path and symbol or line and returns a bounded surrounding range. The hash identifies the original on which a later patch is based; it does not establish that the fragment is sufficient or the diagnosis correct. Missing caller conditions and exception flow require another narrow lookup rather than an assumption that a fingerprint proves comprehension.
Sending less source differs from performing less validation
Reducing investigation context does not remove full-scope preservation and independent checks. The historical design separated model-proposed fragment edits from host testing, building, installation and rollback. A one-sentence change did not justify assuming every other boundary remained safe without the required checks.
ApplyFocusedPatch validates paths, base hashes and unique before fragments before starting writes. That is not a guarantee that several file writes form one failure-atomic transaction. Sequential I/O failure and recovery remain other host responsibilities. Calling a change small must not lower validation criteria or conceal a possible persistence failure.
A failed check became evidence for the next investigation
Historical focused-repair records include independent checks failing because a new source copy lacked an output directory or proper fixture. Reading a relevant test function was separated from editing the test. The account does not describe deleting expected conditions merely to produce a passing result.
A successful one-sentence guidance repair also remains, but is not pooled with a harder editor defect to manufacture a general savings rate. Source work and browser resumption/final-answer usage retain different scopes. Preserving the actual failure location helps the next investigation avoid restarting the same repository-wide search.
Carry the investigation principle into current external work
The embedded CLI and automatic repair runtime remain removed. I called no historical repair model and performed no installation while writing this article. Current external code investigation can reuse the order of reading concrete failure conditions, expanding related evidence and retaining independent validation, without pretending the old feature runs automatically today.
The shared module only builds a small synthetic structural error report; it edits no source. Good diagnosis also does not require forwarding whole manuscripts and accounts. I publish investigation inputs and result-confirming checks as separate responsibilities so readers can describe their own program failures more precisely.