Testing a Bounded AI LaTeX Repair Loop
A reproducible repair loop must rebuild the intended document, expose a bounded compiler trace, constrain environment changes, and stop when the evidence does not improve.
A repair agent needs a stricter success condition than “the model explained the error.” It must compile the intended root, isolate a small failure class, perform a bounded action, and rebuild the same document. If any one of those facts is missing, the trace is incomplete.
Define success in artifacts, not prose
The useful unit of evidence is one run that links the selected root, first compiler result, write or environment action, retry, and final artifact. A response that merely says the issue was fixed cannot satisfy this contract.
select exact root
→ compile once
→ classify one supported failure
→ apply one bounded action
→ compile the same root once
→ stop or repeat within the documented cap
→ record PDF or unresolved failureKeep the build target stable
A repository may contain several files named main.tex. TeX64’s compile_document defaults to the active document captured for the Axiom turn. A nested active file is not silently replaced by a similarly named file at the workspace root. A file-local magic root is also honored.
Package recovery is narrower than shell access
The model does not receive a general shell tool. Managed missing-package recovery is available only when TeX64 owns the TeX tree. The compiler log must identify a missing .sty or .cls, and TeX Live Manager search must resolve the exact basename to a package. Each successful recovery rebuilds the same document; the current implementation permits at most four recovery attempts before returning the remaining failure. The upstream behavior is documented by the TeX Live Manager reference.
| Failure class | Allowed action | Boundary |
|---|---|---|
| Missing managed package | Resolve exact file, install the containing package, and rebuild the same root | TeX64-managed tree; at most four recovery attempts |
| Source syntax failure | Apply a file-bound edit through guarded tools | No arbitrary shell and no path outside the workspace |
| Protected structure removal | Reject the model-facing edit | Document class and document boundaries stay protected |
| Repeated unchanged error | Return unresolved status | Do not loop indefinitely |
Test real failures and a real PDF
The public fixture contains a broken workspace-root sentinel and an active nested document at documents/repair/main.tex. The first real compiler run selected the nested root and failed at line 9 with Undefined control sequence. The actual replace_lines tool changed that one line, then compile_document retried the same root successfully.
| Stage | Recorded artifact | Verified result |
|---|---|---|
| Selected root | documents/repair/main.tex | same root before and after repair |
| First compiler result | line 9: Undefined control sequence | failure retained in JSON trace |
| Bounded action | one replace_lines write in one file | 73d1a084… → f4e90bc6… |
| Retry | compile_document on documents/repair/main.tex | success with no parsed issues |
| Output | axiom-repair.pdf | SHA-256 f6a8f835… |
The applied diff,compiler/action/retry trace, andcompiled PDF are bound by the public SHA-256 manifest.
Not every compiler error should be repaired automatically
Semantic mistakes, project-specific build scripts, unavailable fonts, shell-escape requirements, and ambiguous roots may require a person to decide the next action. A bounded loop should preserve the first failure, state what changed, return the second failure, and stop. It should never convert lack of progress into a success claim.
Primary sources
Report changed behavior, failed reproductions, or errors through TeX64 support.