Files
ARCADIA-Studio/harness/experiments/navigation-rename-cache-rejection-20260913

Rejected cross-checkout build-cache attempt

The Windows navigation/rename gate on source 208268c8aa rejected its first test listing. It must not be counted as successful compilation or testing of that source, despite Cargo returning exit zero. This report is stored on the experiment evidence branch; it does not change the frozen union source.

Observation and admission failure

The explicit checkout in the runner and Cargo metadata both resolved to the navigation/rename union. All 577 input records matched the fresh attempt's capture by path, byte length and SHA-256. Nevertheless Cargo check finished in 5.44 seconds and the test profile in 3.35 seconds using the shared target/debug executable from the preceding source4b experiment. The listing contained 918 tests and its prior experiment names, with zero navigation_union_tests and zero preview_scroll_tests. The new source requires six and four respectively. The runner recorded selectionValid=false and exited with an error before any full-suite acceptance.

The prior source4b experiment's 23 tests remain separately evidenced in ../behavior-anchor-plan-gates-20260913/README.md. This cache rejection does not invalidate those executions, earlier explicitly compiled navigation/core results, or any published release asset. No fresh union success is claimed here.

Correction and verification policy

The rejected raw logs, receipts, runner and input capture are preserved unchanged here, with byte/SHA-256/Git-blob bindings in artifacts.json. The initial check receipt's selectionValid=true applies only to its then-unchecked command; this report explicitly rejects that result for source attribution.

The shared target directory had been reused across worktrees whose local package names and target paths coincide. Correct Cargo workspace selection alone did not prevent stale reuse in this observed case. The exact internal Cargo invalidation cause has not been isolated. A timestamp/source-identity cache collision is a hypothesis, not a proven general Cargo defect.

With all prior compiler jobs terminal, the parent ran cargo clean --target-dir /target -p oa-desktop -p oa-core --profile dev. Its dry-run paths were resolved and checked to remain under the intended root/target/debug directory before cleanup. Third-party dependency artifacts, source trees and published packages were retained. The raw dry-run and cleanup logs are included. A new evidence directory was created; old receipts were not overwritten. A fresh 577-input capture matched the old capture exactly, and the new check began by explicitly compiling oa-core from the union checkout. Its eventual result belongs to a subsequent report.

For subsequent verification with this shared target, invalidate affected local workspace package artifacts whenever changing checkouts, retain identified inputs, require expected test membership, and freeze the compiler checkout throughout the gate. A separate target directory is another valid isolation strategy. A short Fresh result, exit zero, or input hashes by themselves do not establish that the intended code was executed.

Environment: Windows PowerShell, stable-x86_64-pc-windows-gnullvm Rust/Cargo1.98.1, local LLVM MinGW20260908 UCRT, jobs1/incremental0, locked/offline dependencies. Linux remains user-deferred. Live integration ownership and later results: Gitea issue27, comments771 and774.