Brummel/Aura
1
0
Fork 0
Code Issues 31 Pull Requests Actions Packages Projects Releases Wiki Activity

Write per-member traces (or reject --trace) on a blueprint sweep #168

New Issue
Closed
opened 2026-07-01 00:35:03 +02:00 by Brummel · 2 comments
Brummel commented 2026-07-01 00:35:03 +02:00
Owner
Copy Link
Copy Source

aura sweep <blueprint.json> --trace <fam> (cycle 0093, #166) sets persist=true
in SweepBlueprintArgs, but run_blueprint_sweep (crates/aura-cli/src/main.rs)
does let _ = persist and always persists the family (manifests + metrics) via
append_family — it writes no per-member trace series to the trace store.

Consequence (verified by the cycle-0093 architect review): for a blueprint sweep,
--trace <fam> and --name <fam> behave identically (family persisted, no traces)
— diverging from the hard-wired run_sweep, where --trace writes the per-member
tap series + runs ensure_name_free. The flag silently under-delivers.

Resolve: either implement per-member trace-writing for blueprint sweeps (mirror
run_sweep's --trace path) so --trace writes traces + --name only persists the
family, or make the flag honest (reject --trace until traces land, or document the
family-only semantics). Surfaced by the cycle-0093 architect drift review
(classified debt-medium).

`aura sweep <blueprint.json> --trace <fam>` (cycle 0093, #166) sets `persist=true` in `SweepBlueprintArgs`, but `run_blueprint_sweep` (crates/aura-cli/src/main.rs) does `let _ = persist` and always persists the *family* (manifests + metrics) via `append_family` — it writes **no per-member trace series** to the trace store. Consequence (verified by the cycle-0093 architect review): for a blueprint sweep, `--trace <fam>` and `--name <fam>` behave identically (family persisted, no traces) — diverging from the hard-wired `run_sweep`, where `--trace` writes the per-member tap series + runs `ensure_name_free`. The flag silently under-delivers. Resolve: either implement per-member trace-writing for blueprint sweeps (mirror `run_sweep`'s `--trace` path) so `--trace` writes traces + `--name` only persists the family, or make the flag honest (reject `--trace` until traces land, or document the family-only semantics). Surfaced by the cycle-0093 architect drift review (classified debt-medium).
Brummel added the idea label 2026-07-01 00:35:03 +02:00
Brummel added this to the Triage harvest 2026-07 — surface honesty & authoring ergonomics milestone 2026-07-09 17:31:15 +02:00
Brummel added bug and removed idea labels 2026-07-09 17:31:22 +02:00
Brummel commented 2026-07-09 17:31:44 +02:00
Author
Owner
Copy Link
Copy Source

Triage 2026-07-09 (tree at 68317ec) — the flag is still a silent no-op, and the surrounding surface has moved in ways that sharpen the fix:

  • crates/aura-cli/src/main.rs:1702 still reads let _ = persist; in run_blueprint_sweep ("reserved for the deferred per-member trace path" per its own comment).
  • The clap help lies: SweepCmd (:2177) promises "also persists each member's taps", WalkforwardCmd (:2204) likewise; the chart NotFound hint (:449-450) still recommends aura sweep --trace as the way to record traces.
  • On the --real arm all four sugar translators set persist_taps: vec![] (crates/aura-cli/src/verb_sugar.rs:150/223/419/545).
  • Precedent exists for the honest option: aura run rejects --trace (main.rs:2586-2589) and mc rejects --name/--trace (:2387-2389).
  • The designed per-member mechanism now exists: campaign presentation.persist_taps writes traces//<cell_key>/ via persist_campaign_traces (crates/aura-cli/src/campaign_run.rs:638).

Two honest resolutions: reject --trace on sweep/walkforward (matching the run/mc precedent, fixing the two help lines and the chart hint), or translate --trace into a persist_taps campaign presentation block. Either ends the silent under-delivery. Label adjusted to bug: observable misbehaviour (help text promises what the code discards).

Triage 2026-07-09 (tree at 68317ec) — the flag is still a silent no-op, and the surrounding surface has moved in ways that sharpen the fix: - crates/aura-cli/src/main.rs:1702 still reads `let _ = persist;` in run_blueprint_sweep ("reserved for the deferred per-member trace path" per its own comment). - The clap help lies: SweepCmd (:2177) promises "also persists each member's taps", WalkforwardCmd (:2204) likewise; the chart NotFound hint (:449-450) still recommends `aura sweep --trace` as the way to record traces. - On the --real arm all four sugar translators set `persist_taps: vec![]` (crates/aura-cli/src/verb_sugar.rs:150/223/419/545). - Precedent exists for the honest option: `aura run` rejects --trace (main.rs:2586-2589) and mc rejects --name/--trace (:2387-2389). - The designed per-member mechanism now exists: campaign `presentation.persist_taps` writes traces/<name>/<cell_key>/ via persist_campaign_traces (crates/aura-cli/src/campaign_run.rs:638). Two honest resolutions: reject --trace on sweep/walkforward (matching the run/mc precedent, fixing the two help lines and the chart hint), or translate --trace into a persist_taps campaign presentation block. Either ends the silent under-delivery. Label adjusted to `bug`: observable misbehaviour (help text promises what the code discards).
Brummel commented 2026-07-09 22:51:23 +02:00
Author
Owner
Copy Link
Copy Source

Decision: refuse-with-forward-pointer (/boss)

Fork: fix the dishonesty by (a) rejecting --trace on sweep/walkforward, or (b)
implementing per-member trace-writing (translate --trace into a persist_taps
campaign block).

Decision: (a) reject with a forward-pointer. Basis: derived — the project's
established idiom for a capability advertised on a path but not yet implemented
there is refuse-with-a-forward-pointer (the #215 "--select plateau is not yet
available on the campaign path; see #215" pattern; the same shape used for the
#159/#220 path refusals). Applying it here: sweep/walkforward reject --trace
with a "not yet available on <verb>; see #224" message (mirroring the existing
aura run --trace and aura mc --name/--trace refusals), and the two clap help
lines + the chart NotFound hint drop the "also persists each member's taps"
promise. Implementing per-member trace-writing is new behaviour across two sweep
paths (run_blueprint_sweep + the --real sugar) — filed forward as #224
(feature), not laundered into this bug fix.

Scope: the observable bug (the lying help/hint + the silent-no-op flag) is fixed
now; #224 lifts the refusal once the traces actually land.

## Decision: refuse-with-forward-pointer (/boss) Fork: fix the dishonesty by (a) rejecting `--trace` on sweep/walkforward, or (b) implementing per-member trace-writing (translate `--trace` into a `persist_taps` campaign block). Decision: **(a) reject with a forward-pointer.** Basis: derived — the project's established idiom for a capability advertised on a path but not yet implemented there is refuse-with-a-forward-pointer (the #215 "--select plateau is not yet available on the campaign path; see #215" pattern; the same shape used for the #159/#220 path refusals). Applying it here: `sweep`/`walkforward` reject `--trace` with a "not yet available on `<verb>`; see #224" message (mirroring the existing `aura run` --trace and `aura mc` --name/--trace refusals), and the two clap help lines + the chart `NotFound` hint drop the "also persists each member's taps" promise. Implementing per-member trace-writing is new behaviour across two sweep paths (`run_blueprint_sweep` + the `--real` sugar) — filed forward as **#224** (feature), not laundered into this bug fix. Scope: the observable bug (the lying help/hint + the silent-no-op flag) is fixed now; #224 lifts the refusal once the traces actually land.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
BLOCKER
Core functionality blocked; preempts other selection
 bug
Observable misbehaviour
 feature
Substantial extension; no full spec required
 idea
Droppable; no commitment
No Label bug
Milestone
No items
No Milestone Triage harvest 2026-07 — surface honesty & authoring ergonomics
Projects
Clear projects
No project
Assignees
Clear assignees
claude (Claude) Brummel
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Brummel/Aura#168
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?