Automated repair loops

Automated repair lets a stage try to fix its own blocking validation failures before they ever reach you. When a stage finishes but a blocking validator fails, Ringmaster can feed that failure back to the agent as revision context and run another attempt, up to a limit you set. If one of those attempts passes, the stage moves on as though it had succeeded the first time. If none do, it stops for you exactly as it would have anyway. You configure it per stage, in the workflow manifest.

Automated repair is a licensed feature; see Installation & licensing.

Turning it on

Add a repair: block to a stage, alongside its validators::

    validators:
      - type: markdown_sections
        artifact: spec.md
        required: [Overview, Requirements, Non-Goals]
    repair:
      enabled: true
      maxAttempts: 2
      triggeredBy: [markdown_sections]

Field	Required	Notes
enabled	no	Turns the loop on. Defaults to false.
maxAttempts	no	How many repair attempts to run after the first failure. A whole number from 1 to 10; defaults to 2.
triggeredBy	no	The validator types whose blocking failure should trigger repair. Omit it, or leave it empty, to react to any blocking failure. Otherwise list the types you care about: artifact_exists, markdown_sections, json_schema, custom_script.

What happens during a run

When an attempt finishes with a blocking validation failure that matches triggeredBy, Ringmaster gathers the specific failures, hands them back to the runtime as revision feedback ("the previous attempt failed these checks, fix them"), and runs a fresh attempt. The stage shows Repairing in the gap between attempts so you can see the loop is working rather than waiting on you.

Two ways it ends:

• It converges. A repair attempt passes validation. The stage succeeds and any downstream stages unblock, the same as a clean first run.
• It runs out. Every attempt up to the limit still fails. The stage stops at the review gate as a normal failure. Every attempt is kept, so you can read what each one tried, pick one up by hand, or revise it yourself.

The loop always runs before the human gate, never after. It runs once per initial attempt: once it has had its turn, control is yours.

Bounding the loop

maxAttempts is the stage's own ceiling. A workspace policy can also cap repair with maxRepairIterations, and the effective limit is whichever is smaller. Setting the policy value to 0 turns automated repair off for everything in its scope, which is a clean way to disable self-correction across a project without editing every workflow.

Single-agent stages only

Repair runs on single-agent stages. A multi-agent stage (parallel, race, consensus, or specialist) that sets repair.enabled: true is rejected when the workflow is validated, with a message telling you which stage to fix. Choosing between candidates is a judgment call, so those stages always come to you.

Without a license

Automated repair is a Professional feature. Without it, the loop simply doesn't run: a workflow that declares repair: still runs fine, a failing stage just stops at the review gate instead of trying to fix itself. Nothing is paywalled out of working, you only lose the self-correction.

Seeing what repair did

Repair never hides what it did. In the inspector, an attempt the loop produced is labeled Automated repair of 001, pointing at the attempt it was fixing, and its provenance records that the decision to revise was the engine's, not yours. The run's Timeline marks when each repair attempt started and whether the loop converged or ran out. All of this is visible with or without a license, because it is part of the run's record.