SUPERVISED OFFLINE PROTOTYPE · APPLIED AI ENGINEERING
What makes a proposed code repair reviewable?
Autonomous Repository Maintenance System checks a bounded Python repair, preserves its evidence, and keeps verification separate from review.
- Stage
- Supervised offline engineering prototype
- My role
- Project owner; agent-assisted development
- Built with
- Python · SQLite · local Git
Problem
A plausible patch is only one part of repository maintenance. A reviewer also needs to know the starting state, permitted changes, validation result, and what happened when an attempt failed.
Engineering question
How can a small repair process make its actions and results inspectable, while keeping a candidate's passed checks separate from task acceptance?
What I built
A supervised offline repair workflow for one seeded Python retry-delay defect. It accepts a bounded source proposal, checks the eligible change, and retains the diff, local Git objects, and machine-readable evidence for review.
The original reviewed experiment moved from 6/18 baseline passes to 18/18 candidate passes. Those finite checks cover attempts zero through five at three stated base delays. The result describes this exact fixture.
Actual local captures
Architecture
A standard-library Python host admits the fixed synthetic task, reserves its local attempt in SQLite, and accepts a JSON proposal containing the task key, expected source digest, and replacement source. A restricted arithmetic interpreter checks this fixture without executing arbitrary candidate Python. Local Git and evidence records preserve the resulting change.
Evaluation
The original candidate came from a separate native coding worker during the supervised build. The later package check reused that saved proposal. These records describe different events and retain their own review states.
| Evidence event | Result | Review state |
|---|---|---|
| Original native-candidate experiment | 6/18 baseline → 18/18 candidate. One seeded retry defect. | Separate agent review for that exact original run and offline scope. |
| October 28 package check | 101 tests, zero failures; 11 documented cases. Frozen source 59016b3. | Package verification. No new review attestation. |
| Fresh supplied-candidate replay | 6/18 → 18/18; local inspection exited zero. No new model call. | Awaiting independent review. task_success: false. |
The fresh check was recorded on October 28, 2026 (Eastern). The original review remains attached to its original run; passing the same checks does not transfer that approval to a replay.
Guardrails and boundaries
The host owns the target file and protected checks. Candidate JSON cannot choose commands, alter the suite, approve a result, or publish it. A repeated completed local task returns its existing attempt; incomplete state requires reconciliation. Restoration after failed verification proceeds only when the current source still matches what that run wrote.
Failure evidence
The recorded scenarios include an incorrect repair, a forbidden-path proposal, forged approval, duplicate delivery, and a stale base. An incorrect repair fails its checks; unsupported candidate fields are refused. Those outcomes remain in the evidence instead of disappearing from the successful example.
Tradeoffs
One synthetic repository and a restricted source form make the control path small enough to inspect. The experiment demonstrates a bounded repair process; it does not measure general repository reasoning or establish correctness beyond the declared finite checks. Model cost and human effort were not measured.
Current limitations
This is an offline prototype without an operating-system sandbox, remote publisher, or unattended service. A separate agent review is an attestation for the stated experiment, not human acceptance of a live repository change.
The supported demonstration uses producer-emitted microsecond timestamps. The unchanged standalone validator has a known ordering limitation for external or stored timestamps beyond six fractional digits. Broader timestamp validation requires a successor.
What comes next
A tightly scoped private repository pilot with an exact target and base, appropriate runtime isolation, explicit budgets, and a separate publishing path that reconciles uncertain remote results. The real issue-to-draft-PR goal remains open.
Related work
AWRC provides the local evidence workspace shown in these captures. It lets a reviewer inspect imported outcomes and their supporting records without turning an imported claim into independent confirmation.