Echo/list a plain aura run's recorded trace handle (and document its trace-dir name) #309

New Issue

2026-07-22T00:37:23+02:00

claude commented

2026-07-22 00:37:23 +02:00

Source

Fieldtest of the tap-subscribers cycle (#283 + #77), examples tap_1_record_spread and tap_4_measure_ic. Combines friction F1 + spec_gap SG1 from that fieldtest — two facets of one gap: a plain aura run's recorded taps are neither echoed nor documented.

Problem

aura run <bp.json> records declared taps under runs/traces/<blueprint-name>/, but its stdout (the manifest + metrics JSON) never names that directory. To then aura chart or aura measure ic those taps, the consumer must already know the run name — which is the blueprint's root-composite name (graph by default) — and there is no lister: aura runs families is empty for a single run. The name is currently discoverable only by ls runs/traces/. Contrast: campaign runs print trace_name, sweeps print a family handle.

Separately, the docs never state this naming rule. aura chart's not-found error enumerates only sweep / walk-forward / campaign handle sources, implying a plain aura run cannot produce a chartable run — yet it does.

Action

Code: have aura run echo the recorded run name/handle on stdout (as campaign and sweep runs already do), or add an aura runs traces-style lister.
Docs: state the plain-run trace-store subdir name (the blueprint root-composite name) in the authoring guide / ledger, and fold it into the aura chart not-found remedy.

Non-blocking: the record/measure paths work correctly; this is discoverability friction. Filed at cycle close of #283.

## Source Fieldtest of the tap-subscribers cycle (#283 + #77), examples `tap_1_record_spread` and `tap_4_measure_ic`. Combines friction F1 + spec_gap SG1 from that fieldtest — two facets of one gap: a plain `aura run`'s recorded taps are neither echoed nor documented. ## Problem `aura run <bp.json>` records declared taps under `runs/traces/<blueprint-name>/`, but its stdout (the manifest + metrics JSON) never names that directory. To then `aura chart` or `aura measure ic` those taps, the consumer must already know the run name — which is the blueprint's root-composite name (`graph` by default) — and there is no lister: `aura runs families` is empty for a single run. The name is currently discoverable only by `ls runs/traces/`. Contrast: campaign runs print `trace_name`, sweeps print a family handle. Separately, the docs never state this naming rule. `aura chart`'s not-found error enumerates only sweep / walk-forward / campaign handle sources, implying a plain `aura run` cannot produce a chartable run — yet it does. ## Action - **Code:** have `aura run` echo the recorded run name/handle on stdout (as campaign and sweep runs already do), or add an `aura runs traces`-style lister. - **Docs:** state the plain-run trace-store subdir name (the blueprint root-composite name) in the authoring guide / ledger, and fold it into the `aura chart` not-found remedy. Non-blocking: the record/measure paths work correctly; this is discoverability friction. Filed at cycle close of #283.

claude added the feature label 2026-07-22 00:37:23 +02:00

Brummel referenced this issue from a commit

2026-07-22 00:42:33 +02:00

fieldtest: tap-subscribers — 5 examples, 0 bugs / 2 friction / 3 spec-gap

claude referenced this issue

2026-07-23 06:36:23 +02:00

Persist a price/signal tap pair so `measure ic` is reachable from the release binary #312

claude added this to the Trace store — completing the tap-subscriber cut milestone 2026-07-23 13:42:57 +02:00

claude commented

2026-07-24 23:43:32 +02:00

Absorbed scope (m37 milestone fieldtest, 2026-07-24)

A second face of the same "a plain run tells you nothing about what it recorded" gap, observed by the M2 milestone fieldtest (binary eb2b0a1, fieldtests/m37-data-authorability-boundary/m37_1): a fold-selected run (--tap spread=mean ...) computes its one scalar summary row, but aura run's stdout is manifest+metrics only — byte-identical to the default run's. The value is reachable only via the trace JSON (runs/traces/graph/spread.json) or the HTML chart; no CLI verb prints a bound fold's scalar as text (measure is IC-only). When this issue lands the trace-handle echo, consider surfacing the bound-fold summary rows the same way (e.g. an aura: note: line per bound fold, or a small read-back over the persisted summary trace).

## Absorbed scope (m37 milestone fieldtest, 2026-07-24) A second face of the same "a plain run tells you nothing about what it recorded" gap, observed by the M2 milestone fieldtest (binary eb2b0a1, `fieldtests/m37-data-authorability-boundary/m37_1`): a fold-selected run (`--tap spread=mean ...`) computes its one scalar summary row, but `aura run`'s stdout is manifest+metrics only — byte-identical to the default run's. The value is reachable only via the trace JSON (`runs/traces/graph/spread.json`) or the HTML chart; no CLI verb prints a bound fold's scalar as text (`measure` is IC-only). When this issue lands the trace-handle echo, consider surfacing the bound-fold summary rows the same way (e.g. an `aura: note:` line per bound fold, or a small read-back over the persisted summary trace).

Brummel referenced this issue from a commit

2026-07-25 02:28:20 +02:00

fieldtest: m37 data-authorability-boundary — 3 scenarios, 0 bugs / 2 friction / 1 spec-gap / 4 working

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Brummel/Aura#309

Echo/list a plain aura run's recorded trace handle (and document its trace-dir name) #309

Source

Problem

Action

Absorbed scope (m37 milestone fieldtest, 2026-07-24)

Echo/list a plain `aura run`'s recorded trace handle (and document its trace-dir name) #309