Re-running a different blueprint into a same-named trace dir orphans still-chartable tap files #311

New Issue

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

claude commented

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

Source

Fieldtest of the tap-subscribers cycle (#283 + #77), spec_gap SG3 (borderline bug). Observed running tap_1_record_spread then tap_4_measure_ic — both default to blueprint name graph, so both record into runs/traces/graph/.

Observed misbehaviour

The second run rewrote runs/traces/graph/index.json to ["signal","price"] but left the first run's spread.json in place. aura chart graph (overlay, index-driven) correctly ignores the orphan, but aura chart graph --tap spread still renders it — data from a different topology than the run's own index.json describes.

Why this is unspecified

Nothing in C18/C27 says begin_run clears the run dir, or that a run name must be unique. The record path streams new tap files and rewrites index.json without removing stale siblings. Likely pre-existing (dir-per-blueprint-name predates #283) and orthogonal to the subscription model — NOT a regression of this cycle.

Fork

(a) Clear the run dir on begin_run — a run owns its trace dir; stale siblings from a prior topology are removed. Closes the --tap inconsistency as a side effect.
(b) Reject a name collision — begin_run refuses if the dir exists with a different tap set, forcing a distinct run name.
(c) Ratify current behaviour — document that --tap <name> is not index-validated and a re-run into an existing dir is the caller's hazard.

If judged a correctness bug, route via debug (RED-first) once the contract is chosen. Filed at cycle close of #283.

## Source Fieldtest of the tap-subscribers cycle (#283 + #77), spec_gap SG3 (borderline bug). Observed running `tap_1_record_spread` then `tap_4_measure_ic` — both default to blueprint name `graph`, so both record into `runs/traces/graph/`. ## Observed misbehaviour The second run rewrote `runs/traces/graph/index.json` to `["signal","price"]` but left the first run's `spread.json` in place. `aura chart graph` (overlay, index-driven) correctly ignores the orphan, but `aura chart graph --tap spread` still renders it — data from a *different* topology than the run's own `index.json` describes. ## Why this is unspecified Nothing in C18/C27 says `begin_run` clears the run dir, or that a run name must be unique. The record path streams new tap files and rewrites `index.json` without removing stale siblings. Likely **pre-existing** (dir-per-blueprint-name predates #283) and orthogonal to the subscription model — NOT a regression of this cycle. ## Fork - **(a) Clear the run dir on `begin_run`** — a run owns its trace dir; stale siblings from a prior topology are removed. Closes the `--tap` inconsistency as a side effect. - **(b) Reject a name collision** — `begin_run` refuses if the dir exists with a different tap set, forcing a distinct run name. - **(c) Ratify current behaviour** — document that `--tap <name>` is not index-validated and a re-run into an existing dir is the caller's hazard. If judged a correctness bug, route via `debug` (RED-first) once the contract is chosen. Filed at cycle close of #283.

claude added the bug label 2026-07-22 00:37:24 +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 added this to the Trace store — completing the tap-subscriber cut milestone 2026-07-23 13:42:58 +02:00

claude referenced this issue

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

Generalize the trace store into a recorded-stream store for all engine inputs #320

claude commented

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

Second observation of the cross-run tap-file lifecycle gap (m37 milestone fieldtest, 2026-07-24)

Same lifecycle class as this issue, now reachable without a blueprint-name collision: with #310's per-run tap plans, a default run records slow_ma, a later --tap-planned run leaves it unbound — and runs/traces/graph/slow_ma.json lingers from the earlier run while index.json's taps lists only the three bound taps. The chart stays clean (index-gated), but the ledger (C27) does not say whether a run prunes taps it did not produce; "file lingers, index is authoritative" and "prune to the current plan" were both defensible readings for a source-blind consumer (fieldtests/m37-data-authorability-boundary/m37_1, binary eb2b0a1). Whichever of the three candidate contracts this issue picks should also pin the per-run-plan case, and C27's tap-store paragraph should record the chosen lifecycle.

## Second observation of the cross-run tap-file lifecycle gap (m37 milestone fieldtest, 2026-07-24) Same lifecycle class as this issue, now reachable without a blueprint-name collision: with #310's per-run tap plans, a default run records `slow_ma`, a later `--tap`-planned run leaves it unbound — and `runs/traces/graph/slow_ma.json` lingers from the earlier run while `index.json`'s `taps` lists only the three bound taps. The chart stays clean (index-gated), but the ledger (C27) does not say whether a run prunes taps it did not produce; "file lingers, index is authoritative" and "prune to the current plan" were both defensible readings for a source-blind consumer (`fieldtests/m37-data-authorability-boundary/m37_1`, binary eb2b0a1). Whichever of the three candidate contracts this issue picks should also pin the per-run-plan case, and C27's tap-store paragraph should record the chosen lifecycle.

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

claude referenced this issue

2026-07-25 03:12:05 +02:00

No op names a blueprint — everything registers as `graph` #331

Brummel referenced this issue from a commit

2026-07-25 11:39:12 +02:00

feat(aura-engine, aura-cli): the blueprint name op — name_gate on every authored intake

Sign in to join this conversation.