Break infinite AI repair loops with bounded verification

Break AI Fix Loops replaces repeated patching with a bounded repair protocol. Progress requires an observable change in system behavior rather than a different patch. The workflow records a reproducible defect, tests causal explanations, proves the actual execution path, checks whether the verifier can reject bad behavior, and exercises rollback on separate disposable copies.

Before editing, establish the acceptance claim, behavior that would disprove the defect, revision, configuration, input, baseline command, literal result, exit status, primary verification command, and rollback target. If the defect cannot be reproduced, stop editing and return INCONCLUSIVE with the missing observation.

Use when a coding assistant cycles through similar fixes, a focused test passes while actual behavior fails, or repair acceptance requires negative controls and rollback evidence. A one-shot, understood edit whose check exercises the complete claim does not need this larger protocol.

The budget is three repair attempts per acceptance claim. Changes to code, configuration, dependencies, generated files, or expected test results consume attempts; read-only observations do not. Restarts, different models, cache clearing, renamed hypotheses, and newly exposed downstream failures do not reset the budget unless a separate task is accepted.

Never weaken an assertion, bypass the failing path, add a silent fallback, or rewrite expected output merely to obtain green checks. Negative controls and rollback trials belong on disposable copies, away from the primary working tree and live systems.

Each attempt records a causal hypothesis, distinguishing prediction, changed paths and patch hash, focused check, real-path check or NOT_RUN reason, symptom fingerprint, and decision. Keep raw evidence private and remove credentials, personal data, and private URLs from shared records.

Canonical fingerprint fields are schema_version, command, input_digest, exit_code, failure_class, stable_excerpt, and real_path_state. Normalize volatile details only when irrelevant to the defect. Record patch hashes separately so a different edit cannot create a false appearance of changed symptoms.

The optional local helper is invoked from the skill directory:

python3 scripts/fingerprint.py evidence/attempt-1.json

It validates a sanitized JSON record and prints a SHA-256 digest. It does not execute the recorded command, redact evidence, access the network, or change the record.

Repeated fingerprints, unchanged decisive state, focused-green but real-path-red results, or retries without discriminating evidence require SHIFT_CAUSE. Stop editing, list attempted mechanisms, locate the next unobserved owner boundary, collect a new observation, and propose a causally different explanation. Without a useful discriminator, return BLOCKED.

Real-path proof matches the claim: invoke the actual CLI entry point, observe an API request at its service boundary, perform the UI interaction, reload persisted data through a fresh read, identify the deployed revision, or observe the actual tool call and external change. A mock, build, open port, or narrative cannot prove a boundary it never exercises.

After the modified path passes, reintroduce the defect or equivalent bad input on a disposable copy. The same primary command and configuration must fail with a nonzero status for the intended assertion. Unrelated crashes and timeouts do not count. A false-green verifier makes the result INCONCLUSIVE. Rerun the untouched modified tree afterward.

Test rollback on another copy, compare restored paths and hashes with the baseline, and reproduce baseline behavior while leaving the primary repair intact. PROVEN requires all these gates; INCONCLUSIVE identifies missing or ambiguous proof, while BLOCKED identifies exhausted attempts or a named external obstacle.

The MIT-licensed package includes an evidence-ledger template, a Python 3.9+ standard-library fingerprint helper, and regression tests for canonicalization and invalid records. The final report binds exact commands, inputs, outputs, statuses, fingerprints, changes, and remaining gaps to the tested revision.