Confirmation pass for green-arc-2 (FS, branch feat/green-fs @ ba2e8f4) found that tests/coreproof_production_clean.rs::the_scan_reddens_on_a_build_that_carries_the_harness fails deterministically on main @ 70c33b0 when run from a freshly-added git worktree (cold target dir): the anti-vacuity leg tries to build a coreproof-profile kernel to prove the scan can go red, and that build itself fails (CORE-PROOF PRODUCTION RATCHET ANTI-VACUITY: FAILED (coreproof build failed)). Reproduced twice in isolation (no concurrent load) via cargo test --release --no-fail-fast --locked in a clean git worktree add checkout of main. The SAME test passes on the feat/green-fs branch checkout (warm target dir, kernel already built by other gates in this session) in 0.36s, so this looks cache/environment-dependent rather than a branch regression — not part of the already-filed #687 pre-existing-red list (12 shared-QEMU targets), this is a 13th, distinct failure mode (a build failure, not a QEMU-timeout flake). Not investigated further here since it is out of scope for the FS arc; filing so it does not get silently dropped. Evidence: /private/tmp/claude-501/-Users-wrb-fun-code-breenix/d69ffb9d-4539-4cf3-8a3d-a872ff7c830b/scratchpad/gfs/confirm/host-suite-main2.log and host-suite-branch2.log (this session, not committed to the repo).
Confirmation pass for green-arc-2 (FS, branch feat/green-fs @ ba2e8f4) found that
tests/coreproof_production_clean.rs::the_scan_reddens_on_a_build_that_carries_the_harnessfails deterministically onmain@ 70c33b0 when run from a freshly-addedgit worktree(cold target dir): the anti-vacuity leg tries to build a coreproof-profile kernel to prove the scan can go red, and that build itself fails (CORE-PROOF PRODUCTION RATCHET ANTI-VACUITY: FAILED (coreproof build failed)). Reproduced twice in isolation (no concurrent load) viacargo test --release --no-fail-fast --lockedin a cleangit worktree addcheckout of main. The SAME test passes on the feat/green-fs branch checkout (warm target dir, kernel already built by other gates in this session) in 0.36s, so this looks cache/environment-dependent rather than a branch regression — not part of the already-filed #687 pre-existing-red list (12 shared-QEMU targets), this is a 13th, distinct failure mode (a build failure, not a QEMU-timeout flake). Not investigated further here since it is out of scope for the FS arc; filing so it does not get silently dropped. Evidence: /private/tmp/claude-501/-Users-wrb-fun-code-breenix/d69ffb9d-4539-4cf3-8a3d-a872ff7c830b/scratchpad/gfs/confirm/host-suite-main2.log and host-suite-branch2.log (this session, not committed to the repo).