In-project process/campaign validate hits the cdylib wall on std-only documents #211

New Issue

2026-07-04T19:35:21+02:00

Brummel commented

2026-07-04 19:35:21 +02:00

Fieldtest cycle-0110 finding (docs/specs/fieldtest-sweep-dissolution.md, friction; observed on a fresh project): inside a project, 'aura process validate ' first fails with 'cargo metadata failed: no cdylib target', then (after cargo build) requires the built dylib — while the identical command runs dylib-free outside any project ('valid (intrinsic)'). A std-only process document references no project nodes, so the intrinsic tier (and referential-over-std) needs no compiled dylib; the CLI nonetheless loads the project env eagerly for every verb once an Aura.toml is discovered (crates/aura-cli/src/main.rs env construction precedes dispatch; crates/aura-cli/src/project.rs load is unconditional).

Pre-existing behaviour, not introduced by the 0110 cycle. The fix direction is a design decision, not a patch: it is the same eager-load coupling the #188 role-homes residue re-opens (the wiring-only project tier — Aura.toml without crate ceremony — needs a load path that does not demand a cdylib for std-only work). Resolve it there, not ad hoc.

depends on: the role-homes / wiring-only-tier design pass (#188 residue)
context: deferred so the load-boundary decision is made once, in its design home, rather than per-verb.

Fieldtest cycle-0110 finding (docs/specs/fieldtest-sweep-dissolution.md, friction; observed on a fresh project): inside a project, 'aura process validate <std-only doc>' first fails with 'cargo metadata failed: no cdylib target', then (after cargo build) requires the built dylib — while the identical command runs dylib-free outside any project ('valid (intrinsic)'). A std-only process document references no project nodes, so the intrinsic tier (and referential-over-std) needs no compiled dylib; the CLI nonetheless loads the project env eagerly for every verb once an Aura.toml is discovered (crates/aura-cli/src/main.rs env construction precedes dispatch; crates/aura-cli/src/project.rs load is unconditional). Pre-existing behaviour, not introduced by the 0110 cycle. The fix direction is a design decision, not a patch: it is the same eager-load coupling the #188 role-homes residue re-opens (the wiring-only project tier — Aura.toml without crate ceremony — needs a load path that does not demand a cdylib for std-only work). Resolve it there, not ad hoc. depends on: the role-homes / wiring-only-tier design pass (#188 residue) context: deferred so the load-boundary decision is made once, in its design home, rather than per-verb.

Brummel referenced this issue

2026-07-04 19:50:04 +02:00

Dissolve the orchestration verbs into the campaign path (sweep, mc, walkforward, generalize) #210

Brummel added this to the Real-project readiness — role-complete research loop (no freeze) milestone 2026-07-10 17:16:15 +02:00

Brummel removed this from the Real-project readiness — role-complete research loop (no freeze) milestone 2026-07-11 15:18:41 +02:00

Brummel commented

2026-07-11 15:19:07 +02:00

Moved out of the "Real-project readiness" milestone at its close (2026-07-11): per this issue's own dependency the fix direction is decided in the role-homes / wiring-only-tier design pass (#188 residue), not ad hoc — the milestone's remaining scope shipped and the deferral is the conscious re-triage its done-criterion allows.

claude referenced this issue

2026-07-14 03:03:44 +02:00

Tracker sweep + executor robustness: net-R chain, archive inventory, std::grid, per-cell fault isolation (12 issues) #270

claude commented

2026-07-15 18:10:56 +02:00

Superseded by #241 (wiring-only project load tier, shipped 2026-07-12). Verified 2026-07-15: a fresh data-only Aura.toml project is loaded with native:None, and aura process validate returns "process document valid (intrinsic)" at exit 0 with no cargo-metadata / cdylib touch — the reported fieldtest failure no longer reproduces. Control check: a genuine [nodes]-pointer project still correctly demands its built dylib, so the fix is precisely scoped. The narrower case (a std-only doc inside a [nodes]-pointer project whose dylib is not yet built) is a distinct, un-reported ask — file fresh if wanted. Closing as superseded.

Superseded by #241 (wiring-only project load tier, shipped 2026-07-12). Verified 2026-07-15: a fresh data-only `Aura.toml` project is loaded with `native:None`, and `aura process validate` returns "process document valid (intrinsic)" at exit 0 with no cargo-metadata / cdylib touch — the reported fieldtest failure no longer reproduces. Control check: a genuine `[nodes]`-pointer project still correctly demands its built dylib, so the fix is precisely scoped. The narrower case (a std-only doc inside a `[nodes]`-pointer project whose dylib is not yet built) is a distinct, un-reported ask — file fresh if wanted. Closing as superseded.

claude closed this issue

2026-07-15 18:10:56 +02:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Brummel/Aura#211