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

Registered blueprints drop their declared taps — sweep --trace never persists a declared tap despite the op doc calling it recordable #327

New Issue
Open
opened 2026-07-24 11:05:41 +02:00 by claude · 1 comment
claude commented 2026-07-24 11:05:41 +02:00
Collaborator
Copy Link
Copy Source

Observed (binary-only M1 milestone fieldtest, 2026-07-24, binary d26f0c8)

graph build --help documents the op tap as "declare a recordable tap on a wire (expose's output-side twin)". The chain breaks at registration:

  • aura graph build < tapped.oplist.json DOES serialize the declarations: the emitted blueprint carries "taps":[{"name":"signal",…},{"name":"price",…}].
  • After aura sweep <bp> --real EURUSD --trace t (which registers the blueprint), the store copy under runs/blueprints/<content-id>.json has NO taps field at all — the declarations are silently stripped on the registration path.
  • The trace index.json consequently lists only the closed presentation set (equity, exposure, r_equity); measure ic --signal signal and chart --tap signal then report the tap does not exist.

Repro corpus: fieldtests/m1-self-description/s5_trace_measurement/ (tapped.oplist.json + README).

Resolution fork (belongs with the #312 design)

Either persist declared taps through register + trace — which is exactly the missing mechanism #312 needs (a persistable signal/price pair for measure ic) — or drop "recordable" from the op's stated meaning. The former makes #312 nearly free; deciding it is M6 scope.

Same silent-drop family as #326, one path further in: there the op-list parser drops unknown fields, here the registration path drops a known, documented one.

## Observed (binary-only M1 milestone fieldtest, 2026-07-24, binary d26f0c8) `graph build --help` documents the op `tap` as "declare a recordable tap on a wire (expose's output-side twin)". The chain breaks at registration: - `aura graph build < tapped.oplist.json` DOES serialize the declarations: the emitted blueprint carries `"taps":[{"name":"signal",…},{"name":"price",…}]`. - After `aura sweep <bp> --real EURUSD --trace t` (which registers the blueprint), the store copy under `runs/blueprints/<content-id>.json` has NO `taps` field at all — the declarations are silently stripped on the registration path. - The trace `index.json` consequently lists only the closed presentation set (`equity`, `exposure`, `r_equity`); `measure ic --signal signal` and `chart --tap signal` then report the tap does not exist. Repro corpus: `fieldtests/m1-self-description/s5_trace_measurement/` (tapped.oplist.json + README). ## Resolution fork (belongs with the #312 design) Either persist declared taps through register + trace — which is exactly the missing mechanism #312 needs (a persistable signal/price pair for `measure ic`) — or drop "recordable" from the op's stated meaning. The former makes #312 nearly free; deciding it is M6 scope. Same silent-drop family as #326, one path further in: there the op-list parser drops unknown fields, here the registration path drops a known, documented one.
claude added the bug label 2026-07-24 11:05:41 +02:00
claude added this to the Measurement reachable — measure ic end-to-end on robust signals milestone 2026-07-24 14:30:07 +02:00
claude commented 2026-07-24 14:30:18 +02:00
Author
Collaborator
Copy Link
Copy Source

Triage (2026-07-24)

Sorted into the Measurement reachable milestone: this bug is the missing mechanism for #312 (see the fieldtest evidence comment there), so the milestone-internal sequence becomes #327 → #312+#294 (together) → #318.

## Triage (2026-07-24) Sorted into the **Measurement reachable** milestone: this bug is the missing mechanism for #312 (see the fieldtest evidence comment there), so the milestone-internal sequence becomes **#327 → #312+#294 (together) → #318**.
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 Measurement reachable — measure ic end-to-end on robust signals
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#327
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?