Warn when the loaded project dylib is stale against the project source #237

New Issue

2026-07-10T17:15:54+02:00

Brummel commented

2026-07-10 17:15:54 +02:00

The project loader loads the cdylib load-and-hold per invocation (crates/aura-cli/src/project.rs:349-403): it shells to cargo metadata, sha256s the dylib, validates the ABI stamps and the vocabulary charter. Nothing checks staleness: editing src/ without cargo build silently runs the previous dylib. Provenance records dylib_sha256 and a -dirty commit suffix, but no warning is printed — the run looks current.

For the role-2 authoring loop (edit → build → run; C25) this is a silent-wrong-results footgun: a forgotten build produces plausible, stale numbers. A missing dylib already refuses with a "run cargo build in the project first" hint (project.rs:55-60); a stale one says nothing.

a source file newer than the loaded dylib produces a stderr warning naming both timestamps (a refusal is not warranted: a stale run is still deterministic and manifest-stamped)

The project loader loads the cdylib load-and-hold per invocation (crates/aura-cli/src/project.rs:349-403): it shells to `cargo metadata`, sha256s the dylib, validates the ABI stamps and the vocabulary charter. Nothing checks staleness: editing `src/` without `cargo build` silently runs the previous dylib. Provenance records `dylib_sha256` and a `-dirty` commit suffix, but no warning is printed — the run looks current. For the role-2 authoring loop (edit → build → run; C25) this is a silent-wrong-results footgun: a forgotten build produces plausible, stale numbers. A missing dylib already refuses with a "run cargo build in the project first" hint (project.rs:55-60); a stale one says nothing. - [ ] a source file newer than the loaded dylib produces a stderr warning naming both timestamps (a refusal is not warranted: a stale run is still deterministic and manifest-stamped)

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

Brummel commented

2026-07-10 21:04:13 +02:00

Landed as 143c87c (RED: mtime-pinned e2e — dylib stamped 2001, src/lib.rs stamped 2033, run must warn on stderr naming both timestamps while still exiting 0 with a valid report) + e44b0cb (GREEN). The loader compares the newest mtime under src/ + Cargo.toml against the dylib mtime immediately after the existing missing-dylib refusal and prints exactly one warning line, then proceeds unchanged — warn, never refuse, per the acceptance box. Mechanism decided: plain mtime scan (no cargo invocation, no source hashing); date render is a dependency-free Hinnant civil_from_days. All I/O failures in the scan degrade to skip-and-continue so staleness can never escalate into a refusal; the fresh-build inverse (no warning) is unit-pinned. Independent quality review: approved, no gating findings. Closes via commit on merge.

Landed as 143c87c (RED: mtime-pinned e2e — dylib stamped 2001, src/lib.rs stamped 2033, run must warn on stderr naming both timestamps while still exiting 0 with a valid report) + e44b0cb (GREEN). The loader compares the newest mtime under src/ + Cargo.toml against the dylib mtime immediately after the existing missing-dylib refusal and prints exactly one warning line, then proceeds unchanged — warn, never refuse, per the acceptance box. Mechanism decided: plain mtime scan (no cargo invocation, no source hashing); date render is a dependency-free Hinnant civil_from_days. All I/O failures in the scan degrade to skip-and-continue so staleness can never escalate into a refusal; the fresh-build inverse (no warning) is unit-pinned. Independent quality review: approved, no gating findings. Closes via commit on merge.

Brummel referenced this issue from a commit

2026-07-11 15:18:17 +02:00

test(cli): RED — a stale project dylib loads silently with no staleness warning

Brummel referenced this issue from a commit

2026-07-11 15:18:17 +02:00

feat(cli): warn when the loaded project dylib is stale against the source tree

Brummel closed this issue

2026-07-11 15:18:17 +02:00

Brummel referenced this issue from a commit

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

audit: real-project-readiness run close — drift-clean, one low debt noted

Sign in to join this conversation.