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

De-duplicate sample-blueprint wiring: aura-cli sma_cross/build_sample vs blueprint.rs fixture #27

New Issue
Closed
opened 2026-06-05 21:00:09 +02:00 by Brummel · 1 comment
Brummel commented 2026-06-05 21:00:09 +02:00
Owner
Copy Link
Copy Source

Cycle 0013 (#13) added sma_cross() + build_sample() to crates/aura-cli/src/main.rs to author the aura graph sample blueprint. Near-identical to the #[cfg(test)] sma_cross() helper in crates/aura-engine/src/blueprint.rs. The SMA-cross sample now exists in three shapes: the flat hand-wired sample_harness (aura run), the composite sample_blueprint (aura graph), and the engine test sma_cross fixture.

Distinct from #14 (which dedups the Recorder fixtures, not the sample-blueprint wiring).

Direction: a single canonical SMA-cross sample blueprint that both aura run and aura graph consume, and that the engine bit-identical test can reference. Intersects the deferred "refactor aura run onto sample_blueprint()" the 0013 spec named out-of-scope.

context: acknowledged debt introduced by cycle 0013; low urgency, pure tidy.

Cycle 0013 (#13) added sma_cross() + build_sample() to crates/aura-cli/src/main.rs to author the aura graph sample blueprint. Near-identical to the #[cfg(test)] sma_cross() helper in crates/aura-engine/src/blueprint.rs. The SMA-cross sample now exists in three shapes: the flat hand-wired sample_harness (aura run), the composite sample_blueprint (aura graph), and the engine test sma_cross fixture. Distinct from #14 (which dedups the Recorder fixtures, not the sample-blueprint wiring). Direction: a single canonical SMA-cross sample blueprint that both aura run and aura graph consume, and that the engine bit-identical test can reference. Intersects the deferred "refactor aura run onto sample_blueprint()" the 0013 spec named out-of-scope. context: acknowledged debt introduced by cycle 0013; low urgency, pure tidy.
Brummel added the idea label 2026-06-05 21:00:09 +02:00
Brummel commented 2026-06-05 23:26:18 +02:00
Author
Owner
Copy Link
Copy Source

Closing as won't-dedupe-cross-crate, per a deliberate scope decision in tidy 0014.

After two constraints are applied, nothing dedupable remains:

  1. The bit-identical test (blueprint.rs composite_sma_cross_runs_bit_identical_to_hand_wired) proves equivalence by constructing the graph TWO independent ways — hand_wired_sma_cross_harness (flat pole) vs the composite sma_cross. Collapsing those two poles onto one source makes the test tautological and worthless, so the flat pole and the composite pole must stay independent.
  2. Refactoring aura run / sample_harness onto sample_blueprint() was explicitly out-of-scope per the 0013 spec; a tidy does not touch the run path.

What's left is purely the cross-crate duplication of the composite sma_cross factory between aura-cli (non-test, drives aura graph) and aura-engine (#[cfg(test)], the composite pole). plan-recon confirmed there is no C9-clean home for a shared canonical factory:

  • aura-engine examples/ satisfies C9's letter but Cargo examples/ are build targets, not importable by aura-cli's non-test code.
  • A pub fn sma_cross behind a 'fixtures' feature WOULD be importable, but it makes a concrete trading signal a (feature-gated) engine pub API — exactly what C9 forbids ('no project/user signals in this repo'). It would be the first feature flag in the workspace and belongs in the ledger as a deliberate C9 bend, not a tidy.
  • aura-std is universal blocks only; a concrete sma_cross does not belong there.

Per CLAUDE.md, bending a domain invariant (C9) is a design decision, not a refactor. The remaining duplication is incidental (~12 lines of a demo/test fixture, in two crates, changing for independent reasons), so the DRY pull does not justify the C9 cost. The two fixtures stay deliberately separate.

If a future cycle introduces a real external example-project crate (per C9 'projects are external crates'), a single canonical demo strategy could live there and feed both engine tests and CLI demos — that is the clean home, and a larger piece of work than a tidy. Reopen/supersede then if desired.

Closing as won't-dedupe-cross-crate, per a deliberate scope decision in tidy 0014. After two constraints are applied, nothing dedupable remains: 1. The bit-identical test (blueprint.rs composite_sma_cross_runs_bit_identical_to_hand_wired) proves equivalence by constructing the graph TWO independent ways — hand_wired_sma_cross_harness (flat pole) vs the composite sma_cross. Collapsing those two poles onto one source makes the test tautological and worthless, so the flat pole and the composite pole must stay independent. 2. Refactoring aura run / sample_harness onto sample_blueprint() was explicitly out-of-scope per the 0013 spec; a tidy does not touch the run path. What's left is purely the cross-crate duplication of the *composite* sma_cross factory between aura-cli (non-test, drives aura graph) and aura-engine (#[cfg(test)], the composite pole). plan-recon confirmed there is no C9-clean home for a shared canonical factory: - aura-engine examples/ satisfies C9's letter but Cargo examples/ are build targets, not importable by aura-cli's non-test code. - A pub fn sma_cross behind a 'fixtures' feature WOULD be importable, but it makes a concrete trading signal a (feature-gated) engine pub API — exactly what C9 forbids ('no project/user signals in this repo'). It would be the first feature flag in the workspace and belongs in the ledger as a deliberate C9 bend, not a tidy. - aura-std is universal blocks only; a concrete sma_cross does not belong there. Per CLAUDE.md, bending a domain invariant (C9) is a design decision, not a refactor. The remaining duplication is incidental (~12 lines of a demo/test fixture, in two crates, changing for independent reasons), so the DRY pull does not justify the C9 cost. The two fixtures stay deliberately separate. If a future cycle introduces a real external example-project crate (per C9 'projects are external crates'), a single canonical demo strategy could live there and feed both engine tests and CLI demos — that is the clean home, and a larger piece of work than a tidy. Reopen/supersede then if desired.
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 idea
Milestone
No items
No Milestone
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#27
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?