repair loop

Three properties separate a repair loop from a button labelled "fix this".

It is automatic. The loop is entered by the failure itself, not by a person noticing a red error and choosing to act. Nobody has to recognise that something is wrong, which matters most for the people least able to tell.

It is fed by structured diagnostics. The model does not receive "it broke". It receives the file, the line, the error code and the message the failing stage produced — the same information a developer would read. Repair quality tracks diagnostic quality almost exactly, which is why the cheap, precise checks run first.

It is bounded. A loop that can run forever will, on the day it meets a problem it cannot solve. After a fixed number of attempts the failure surfaces to the person, with what failed and what was tried. An unbounded loop is not persistence; it is a way of burning money quietly.

In sup3rapp, a repaired build re-enters the verification chain at the first stage rather than resuming where it failed, because a change that fixes a type error can break a test. The share of failures a repair loop resolves without human involvement is the single most useful quality metric for a generation pipeline.