Configure

Configure is the middle commitment layer: change how a Loop runs without forking it. It opens as a sheet over the detail view and writes a per-Loop config overlay — the Loop's structure is untouched.

What you can tune

The sheet has four groups, all scoped to the checks and limits the Loop already declares:

• Verification checks — enable or disable each declared check, and for a generic command check, set the project command it runs (a test suite, a linter). Disabling a command check disables its command field. A gate that judges (an agent-judge acceptance review) cannot be removed here — that is structure.
• Human approval gate — a single switch to require, or drop, a human approval before the Loop finishes.
• Re-attempt strategy — failed-only (the default; retry only what failed) or full-body (re-run the whole body). This is where re-attempt granularity is chosen, not on the run form.
• Stop limits — the same six numeric limits as the run form's Advanced panel, each clamped at its daemon ceiling. Configure sets the per-Loop default; the run form can still override per run.

Reset to defaults restores the definition defaults and failed-only. Save persists the overlay.

What needs a fork

Configure never changes structure. These belong to the visual editor or a definition edit:

• node order or DAG structure;
• node kinds;
• input declarations;
• the contract's terminal states or shape;
• the goal or definition-of-done.

How it stores and merges

Configure writes a separate per-Loop config store keyed (workspace_id, loop_name) — distinct from the definition, which stays filesystem-as-truth. It is read and written through GET/PUT /loops/:name/config, compozy loop configure, and compozy__loop_configure.

The effective config a run actually uses is a four-layer merge, each layer bounded by the compile-time ceilings:

1. the definition's own defaults,
2. [loops.defaults.*] in config.toml,
3. this per-Loop configure overlay,
4. any per-run overrides from the run form.

GET /loops/:name/config returns the stored per-Loop override as config and the daemon-resolved first three layers as effective_config. A missing override is config: null; it is not a missing Loop and does not prevent clients from reading the effective values.

Loop run-agent workers use Loop-owned runtime_defaults and runtime_rules; they do not read [[tasks.run.task_runtime_rules]]. Runtime fields resolve independently and the daemon persists the final binder-applied provider, model, reasoning, and provenance on each generation output. The current web sheet edits checks, gates, re-attempt strategy, and stop limits. Use the structured CLI, HTTP, or native-tool config surface to write runtime defaults or rules.

From an agent

Configure is fully agent-manageable — the same overlay, written structurally:

See the compozy loop CLI and the Loops API.