Cell lacks tuple-style constructors (asymmetry with Scalar) — param-authoring reach mis-aims at the wrong type #100

New Issue

2026-06-18T21:14:33+02:00

Brummel commented

2026-06-18 21:14:33 +02:00

The Runway milestone-close fieldtest (docs/specs/0055-fieldtest-runway-real-data-seam.md) recorded an ergonomic papercut, adversarially confirmed as friction (not a bug):

A consumer hand-authoring params reaches for aura_core::Cell::I64(3) / Cell::F64(1.0) — mirroring the side-by-side aura_core::Scalar, which IS a tagged enum with public I64(..)/F64(..) variants. But Cell is pub struct Cell(u64) exposing only from_i64/from_f64/from_bool/from_ts, so the reach fails to compile:

error[E0599]: no associated item named `I64` found for struct `aura_core::Cell`

The compiler suggestion is clean (it names from_i64 etc.), so it self-corrects in seconds — hence friction, not a bug.

Nuance from the verifier: per the ledger (INDEX.md C19 region), the param-authoring entry point is in fact Scalar (build / bind / compile_with_params / sweep), and Cell is the hot-path node-output buffer carrier — so the natural reach is mis-aimed at the wrong type, which makes the snag slightly less "natural" than a raw symmetry gap.

Two candidate resolutions (a small design choice for a future cycle):

(a) add Cell::I64(..)/F64(..)/... tuple-style constructors or From<i64>/From<f64> impls to mirror Scalar; OR
(b) docwriter nudge — document on Cell that Scalar (not Cell) is the param-authoring surface, and that from_* are the buffer-carrier constructors.

Low priority; ergonomic only. The task always completed.

context: Runway milestone-close fieldtest, finding [friction].

The Runway milestone-close fieldtest (`docs/specs/0055-fieldtest-runway-real-data-seam.md`) recorded an ergonomic papercut, adversarially confirmed as `friction` (not a bug): A consumer hand-authoring params reaches for `aura_core::Cell::I64(3)` / `Cell::F64(1.0)` — mirroring the side-by-side `aura_core::Scalar`, which IS a tagged enum with public `I64(..)`/`F64(..)` variants. But `Cell` is `pub struct Cell(u64)` exposing only `from_i64`/`from_f64`/`from_bool`/`from_ts`, so the reach fails to compile: ``` error[E0599]: no associated item named `I64` found for struct `aura_core::Cell` ``` The compiler suggestion is clean (it names `from_i64` etc.), so it self-corrects in seconds — hence `friction`, not a bug. Nuance from the verifier: per the ledger (`INDEX.md` C19 region), the param-authoring entry point is in fact `Scalar` (build / bind / compile_with_params / sweep), and `Cell` is the hot-path node-output buffer carrier — so the natural reach is mis-aimed at the wrong type, which makes the snag slightly less "natural" than a raw symmetry gap. Two candidate resolutions (a small design choice for a future cycle): - (a) add `Cell::I64(..)`/`F64(..)`/... tuple-style constructors or `From<i64>`/`From<f64>` impls to mirror `Scalar`; OR - (b) docwriter nudge — document on `Cell` that `Scalar` (not `Cell`) is the param-authoring surface, and that `from_*` are the buffer-carrier constructors. Low priority; ergonomic only. The task always completed. context: Runway milestone-close fieldtest, finding [friction].

Brummel added the idea label 2026-06-18 21:14:33 +02:00

Brummel referenced this issue

2026-06-22 11:08:15 +02:00

Meta-level (composable analysis + project-as-crate authoring): keep in focus, resolve the CLI-vs-Rust authoring line #109

Brummel commented

2026-06-22 11:23:56 +02:00

Resolved during a /boss run as a direct orchestrator edit (doc-only, no cycle).

Fork (option a: add Cell::I64(..)/From impls — vs — option b: doc-nudge):
decided (b), the doc-nudge. Substantive reason, not effort: option (a) would
make Cell look self-describing/tagged, which softens the C7 boundary the
carrier-split deliberately drew — the value carries no tag; the kind lives in
the schema/column/port. A Cell::I64 constructor re-introduces exactly that tag.
Scalar already is the kind-tagged param-authoring surface (build / bind /
compile_with_params / sweep points / RunManifest), and Cell::from_* are the
hot-path carrier ctors. So the asymmetry is correct by design; the papercut was a
discoverability gap, fixed by documenting the split on Cell itself.

Edit: crates/aura-core/src/cell.rs struct doc now names Scalar as the value to
reach for when authoring, and states the no-tagged-ctors choice is by design (C7).

Resolved during a `/boss` run as a direct orchestrator edit (doc-only, no cycle). **Fork (option a: add `Cell::I64(..)`/`From` impls — vs — option b: doc-nudge): decided (b), the doc-nudge.** Substantive reason, not effort: option (a) would make `Cell` look self-describing/tagged, which softens the C7 boundary the carrier-split deliberately drew — the value carries *no* tag; the kind lives in the schema/column/port. A `Cell::I64` constructor re-introduces exactly that tag. `Scalar` already is the kind-tagged param-authoring surface (build / bind / `compile_with_params` / sweep points / `RunManifest`), and `Cell::from_*` are the hot-path carrier ctors. So the asymmetry is correct by design; the papercut was a *discoverability* gap, fixed by documenting the split on `Cell` itself. Edit: `crates/aura-core/src/cell.rs` struct doc now names `Scalar` as the value to reach for when authoring, and states the no-tagged-ctors choice is by design (C7).

Brummel referenced this issue from a commit

2026-06-24 10:26:29 +02:00

docs(cell): name Scalar as the param-authoring surface; no tagged Cell ctors by design

Brummel closed this issue

2026-06-24 10:26:29 +02:00

Brummel referenced this issue from a commit

2026-06-24 10:26:29 +02:00

audit(visual-world-cut-2): cycle close 0062 — ledger records cut 2 (#102 + #108)

Sign in to join this conversation.