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

Decide the Named fold subscription's data-authorability boundary — data selector vs Rust-only #310

New Issue
Closed
opened 2026-07-22 00:37:24 +02:00 by claude · 2 comments
claude commented 2026-07-22 00:37:24 +02:00
Collaborator
Copy Link
Copy Source

Source

Fieldtest of the tap-subscribers cycle (#283 + #77), spec_gap SG2. Contrast of examples tap_2_fold / tap_3_live (Rust-only) against tap_1 / tap_4 (CLI / op-script).

Problem

The cycle's headline is TapSubscription::Named { label, params } as a "fully data-expressible" subscription over the layered fold registry. But no CLI verb and no authored artifact (op-script / campaign / process document) can select a per-tap fold: both aura run and aura measure hardcode a record-all plan, and no document field carries a subscription. A Named fold or a Live tap is reachable ONLY by writing a Rust consumer crate against aura-runner (TapPlan::empty().subscribe(name, named("mean"))). For the default data-only project (project-layout.md), the cycle's new vocabulary is out of reach without escalating to Rust.

The ledger (C25/C27) calls the Named form "data-expressible" but wires it to no data surface — an ambiguity: is a fold subscription meant to be authorable as data (a campaign persist_taps-style selector), or is it deliberately Rust-only for now?

Fork (decide, then record in the ledger)

  • (a) Ratify Rust-only — a fold/live subscription is a World-program concern, authored in Rust; the CLI's record-all is the only data-surface tap consumer by design. Cheap: one ledger clarification softening the "data-expressible" claim to "the Named label vocabulary is closed/data-shaped, but selecting a subscription is Rust-authoring surface".
  • (b) Plan a data selector — extend an authored artifact (an op-script subscribe op, or a campaign persist_taps field) to carry { tap, label }, so a data-only project can request a fold.

Either is fine; the ledger must say which so the "data-expressible" promise stops being ambiguous. Filed at cycle close of #283.

## Source Fieldtest of the tap-subscribers cycle (#283 + #77), spec_gap SG2. Contrast of examples `tap_2_fold` / `tap_3_live` (Rust-only) against `tap_1` / `tap_4` (CLI / op-script). ## Problem The cycle's headline is `TapSubscription::Named { label, params }` as a "fully data-expressible" subscription over the layered fold registry. But no CLI verb and no authored artifact (op-script / campaign / process document) can *select* a per-tap fold: both `aura run` and `aura measure` hardcode a record-all plan, and no document field carries a subscription. A `Named` fold or a `Live` tap is reachable ONLY by writing a Rust consumer crate against `aura-runner` (`TapPlan::empty().subscribe(name, named("mean"))`). For the default data-only project (project-layout.md), the cycle's new vocabulary is out of reach without escalating to Rust. The ledger (C25/C27) calls the `Named` form "data-expressible" but wires it to no data surface — an ambiguity: is a fold subscription *meant* to be authorable as data (a campaign `persist_taps`-style selector), or is it deliberately Rust-only for now? ## Fork (decide, then record in the ledger) - **(a) Ratify Rust-only** — a fold/live subscription is a World-program concern, authored in Rust; the CLI's record-all is the only data-surface tap consumer by design. Cheap: one ledger clarification softening the "data-expressible" claim to "the `Named` label vocabulary is closed/data-shaped, but *selecting* a subscription is Rust-authoring surface". - **(b) Plan a data selector** — extend an authored artifact (an op-script `subscribe` op, or a campaign `persist_taps` field) to carry `{ tap, label }`, so a data-only project can request a fold. Either is fine; the ledger must say which so the "data-expressible" promise stops being ambiguous. Filed at cycle close of #283.
claude added the idea label 2026-07-22 00:37:24 +02:00
claude added this to the Data-authorability boundary — folds, composites, construction args milestone 2026-07-23 13:42:57 +02:00
claude self-assigned this 2026-07-24 14:31:51 +02:00
claude commented 2026-07-24 14:39:01 +02:00
Author
Collaborator
Copy Link
Copy Source

Design reconciliation (specify, /boss 2026-07-24)

Spec: fold-subscription-data-selector (cycle in progress). The fork below is still listed open on this issue; this records its derived resolution.

  • Fork: (a) ratify Rust-only vs (b) data selector → (b), split by run-mode authority.
    Basis: derived — C27 built Named { label, params } deliberately data-shaped (closed label vocabulary, scalar param schemas, layered growth without a core edit) and assigns tap consumption to the run-mode owner ("what consumes a tap is declared per run by a tap plan"); C25 forbids an authoring path whose only route is a Rust compile where the role's iteration cost demands data. Ratifying Rust-only (a) would soften a designed-in promise with effort as the only rationale — banned in this project.
  • Cut: the two entry points that already bind declared taps — aura run and aura measure — gain a repeatable CLI selector --tap <tap>=<fold-label> (labels resolve against the layered FoldRegistry with its roster-enumerating refusal; unknown taps keep the typed UndeclaredTap). Any explicit --tap replaces the record-all default entirely; unlisted taps stay unbound (C27: unbound is inert, a non-error). Fold params stay out of the grammar until a parameterized fold exists (all core folds are param-less; the Named params seam remains).
  • Skeptic pass (scope-fork lens) integrated: (1) the C25 "second home for intent" objection resolves via C27's own layering — artifact-embedded recording policy is forbidden, but per-run consumption is run-mode authority, and on the one-shot path the CLI invocation IS the run-mode owner; persisted experiment intent is deliberately NOT shipped here. (2) The skeptic grounded a real namespace collision: Presentation.persist_taps (presentation channel, equity|exposure|r_equity|net_r_equity, TapChannel) is a mechanism disjoint from C27 declared taps (FlatGraph.taps + FoldRegistry).
  • Deferred to the Measurement-reachable milestone (#312/#327): the campaign/document carrier for fold-bearing tap consumption — including, as a named prerequisite, the reconciliation of the two tap namespaces above. A fold-bearing campaign field must not be grafted onto persist_taps before that reconciliation is decided.
  • Ledger: C27 Current state gets the boundary recorded (selection is data-expressible per run-mode surface; adding a fold stays Rust, role 2). The "data-expressible" ambiguity this issue names is thereby closed.
## Design reconciliation (specify, /boss 2026-07-24) Spec: fold-subscription-data-selector (cycle in progress). The fork below is still listed open on this issue; this records its derived resolution. - **Fork: (a) ratify Rust-only vs (b) data selector** → **(b), split by run-mode authority.** Basis: derived — C27 built `Named { label, params }` deliberately data-shaped (closed label vocabulary, scalar param schemas, layered growth without a core edit) and assigns tap consumption to the run-mode owner ("what consumes a tap is declared per run by a tap plan"); C25 forbids an authoring path whose only route is a Rust compile where the role's iteration cost demands data. Ratifying Rust-only (a) would soften a designed-in promise with effort as the only rationale — banned in this project. - **Cut:** the two entry points that already bind declared taps — `aura run` and `aura measure` — gain a repeatable CLI selector `--tap <tap>=<fold-label>` (labels resolve against the layered FoldRegistry with its roster-enumerating refusal; unknown taps keep the typed UndeclaredTap). Any explicit `--tap` replaces the record-all default entirely; unlisted taps stay unbound (C27: unbound is inert, a non-error). Fold params stay out of the grammar until a parameterized fold exists (all core folds are param-less; the `Named` params seam remains). - **Skeptic pass (scope-fork lens) integrated:** (1) the C25 "second home for intent" objection resolves via C27's own layering — artifact-embedded recording policy is forbidden, but per-run consumption is run-mode authority, and on the one-shot path the CLI invocation IS the run-mode owner; *persisted* experiment intent is deliberately NOT shipped here. (2) The skeptic grounded a real namespace collision: `Presentation.persist_taps` (presentation channel, `equity|exposure|r_equity|net_r_equity`, `TapChannel`) is a mechanism disjoint from C27 declared taps (`FlatGraph.taps` + FoldRegistry). - **Deferred to the Measurement-reachable milestone (#312/#327):** the campaign/document carrier for fold-bearing tap consumption — including, as a named prerequisite, the reconciliation of the two tap namespaces above. A fold-bearing campaign field must not be grafted onto `persist_taps` before that reconciliation is decided. - **Ledger:** C27 Current state gets the boundary recorded (selection is data-expressible per run-mode surface; adding a fold stays Rust, role 2). The "data-expressible" ambiguity this issue names is thereby closed.
claude commented 2026-07-24 15:23:28 +02:00
Author
Collaborator
Copy Link
Copy Source

Cycle close (2026-07-24)

Shipped on branch worktree-issue-310-fold-data-authorability (merge = owner): 1baee77 (feature: --tap TAP=FOLD selector on aura run, C27 Current-state amendment + first C27 history sidecar + glossary fix), e482f0e (audit close: usage strings name --tap; C14 exit-class tension routed to #297), 7cc3ce0 (fieldtest corpus). closes #310 fires on merge.

Precision correction to the decision comment above: there is no separate aura measure verb binding taps — both declared-tap entry points (run_signal_r, run_measurement) are arms of the single verb aura run, so the selector lands once and reaches both. (The glossary sentence claiming aura measure passes a record-all plan was a pre-existing inaccuracy, fixed this cycle.)

Per-cycle fieldtest (source-blind, release binary e482f0e): 0 bugs / 5 friction / 1 spec_gap / 3 working — the selector spine is byte-exact end-to-end, incl. the C1 identity pin and kind-aware folds/refusals on a Bool tap. Routing: #332 (introspect --folds renders the FoldKind table, not the registry roster — bug), #333 (declared-tap enumeration), #334 (C14 skipped-tap note for unbound-under-explicit-plan), #335 (fold summary-row timestamp semantics — decide); the exit-class split is tracked on #297 (audit evidence comment); the replace-semantics itself is confirmed as designed and now ledger-recorded.

## Cycle close (2026-07-24) Shipped on branch `worktree-issue-310-fold-data-authorability` (merge = owner): `1baee77` (feature: `--tap TAP=FOLD` selector on `aura run`, C27 Current-state amendment + first C27 history sidecar + glossary fix), `e482f0e` (audit close: usage strings name `--tap`; C14 exit-class tension routed to #297), `7cc3ce0` (fieldtest corpus). `closes #310` fires on merge. Precision correction to the decision comment above: there is no separate `aura measure` verb binding taps — both declared-tap entry points (`run_signal_r`, `run_measurement`) are arms of the single verb `aura run`, so the selector lands once and reaches both. (The glossary sentence claiming `aura measure` passes a record-all plan was a pre-existing inaccuracy, fixed this cycle.) Per-cycle fieldtest (source-blind, release binary e482f0e): **0 bugs / 5 friction / 1 spec_gap / 3 working** — the selector spine is byte-exact end-to-end, incl. the C1 identity pin and kind-aware folds/refusals on a Bool tap. Routing: #332 (introspect `--folds` renders the FoldKind table, not the registry roster — bug), #333 (declared-tap enumeration), #334 (C14 skipped-tap note for unbound-under-explicit-plan), #335 (fold summary-row timestamp semantics — decide); the exit-class split is tracked on #297 (audit evidence comment); the replace-semantics itself is confirmed as designed and now ledger-recorded.
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 Data-authorability boundary — folds, composites, construction args
Projects
Clear projects
No project
Assignees
Clear assignees
claude (Claude) Brummel
No Assignees claude
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Brummel/Aura#310
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?