aura run <blueprint.json> panics on an open (free-knob) blueprint instead of a clean exit-2 error #176

New Issue

2026-07-01T17:02:15+02:00

Brummel commented

2026-07-01 17:02:15 +02:00

aura run <blueprint.json> panics (exit 101) when the blueprint has ≥1 free
(unbound) knob, instead of a clean exit-2 error like the sibling verbs.

Verbatim (an OPEN blueprint):

thread 'main' panicked at crates/aura-cli/src/main.rs:3107:10:
signal binds + wraps to a valid harness: ParamArity { expected: N, got: 0 }

The run dispatch bootstraps a blueprint over the EMPTY point (a closed-blueprint
assumption) and .expect()s compile_with_params, which panics on an open
blueprint. The sibling aura mc on the SAME open blueprint gives a clean,
actionable exit-2 error ("mc requires a closed blueprint … N free knob(s) — bind
them or use aura sweep --axis"). run should refuse an open blueprint the same
way at the dispatch boundary — this is exactly the panic shape cycle 0095's
grounding-check pre-empted for the mc path.

Surfaced by the World/C21 milestone fieldtest (a naive consumer authors an open
blueprint and runs aura run on it — a natural first move — and hits a raw panic).
Detail + repro in docs/specs/fieldtest-milestone-world-c21-blueprint-data-families.md.

Fix (RED-first): aura run <open blueprint> exits 2 with a "requires a closed
(fully-bound) blueprint" message, no panic (mirror the run_blueprint_mc
closed-guard).

refs #170

`aura run <blueprint.json>` **panics** (exit 101) when the blueprint has ≥1 free (unbound) knob, instead of a clean exit-2 error like the sibling verbs. Verbatim (an OPEN blueprint): ``` thread 'main' panicked at crates/aura-cli/src/main.rs:3107:10: signal binds + wraps to a valid harness: ParamArity { expected: N, got: 0 } ``` The `run` dispatch bootstraps a blueprint over the EMPTY point (a closed-blueprint assumption) and `.expect()`s `compile_with_params`, which panics on an open blueprint. The sibling `aura mc` on the SAME open blueprint gives a clean, actionable exit-2 error ("mc requires a closed blueprint … N free knob(s) — bind them or use `aura sweep --axis`"). `run` should refuse an open blueprint the same way at the dispatch boundary — this is exactly the panic shape cycle 0095's grounding-check pre-empted for the `mc` path. Surfaced by the World/C21 milestone fieldtest (a naive consumer authors an open blueprint and runs `aura run` on it — a natural first move — and hits a raw panic). Detail + repro in docs/specs/fieldtest-milestone-world-c21-blueprint-data-families.md. Fix (RED-first): `aura run <open blueprint>` exits 2 with a "requires a closed (fully-bound) blueprint" message, no panic (mirror the `run_blueprint_mc` closed-guard). refs #170

Brummel added the bug label 2026-07-01 17:02:15 +02:00

Brummel referenced this issue from a commit

2026-07-01 17:47:37 +02:00

fix(cli): aura run refuses an open blueprint with a clean exit 2, not a panic

Brummel closed this issue

2026-07-01 17:47:37 +02:00

Brummel referenced this issue

2026-07-01 17:51:04 +02:00

Monte-Carlo and walk-forward over a loaded blueprint #170

Brummel referenced this issue from a commit

2026-07-02 09:37:09 +02:00

Merge main into the clap-adoption cycle — re-integrate the two parallel CLI fixes