---
name: cargo-replays-cached-build-script-warnings
description: "A build-script warning in a build log dates the script's last EXECUTION, not the invocation that printed it — cargo replays cached build.rs output (warnings included) on fresh invocations that skip the script."
metadata: 
  node_type: memory
  type: project
  originSessionId: 0e501f1f-bba6-49e0-81cd-db288f425892
  modified: 2026-08-26T01:37:43.391Z
---

deployah, v0.63.0 publish (2026-08-26): the SUCCESSFUL publish build printed the
`SPT_POOL_UNCHECKED` override warning naming `assembly-signet-218` — a lane whose pool claim
had already been taken over, in an invocation where the env var was NOT set. Cause: the second
invocation finished in 0.85s and never re-ran `build.rs`; cargo replayed the cached
build-script output, warnings included. The on-disk POOL-OWNER record was correct throughout.

**Why:** cargo stores a build script's stdout/stderr (`cargo:warning=` lines included) and
replays it verbatim when fingerprints say the script need not re-run. Any diagnostic that
build.rs emits — pool-guard hatches, override announcements, environment reports — can appear
in a later log describing a state that no longer holds.

**How to apply:**
- Before reading a build-script warning as THAT build's state, check whether build.rs actually
  re-ran (build time, `Compiling` vs fresh, or touch the script's tracked inputs).
- The loud-override guarantee ("says so on every build it allows") holds at the EMISSION layer;
  the replay can also repeat it on builds that did NOT override. Judge overrides from the
  on-disk owner record + whether the var was set in the invocation, not from the log line.
- When a guard's state changes (claim takeover, release), the next log may still carry the old
  announcement — note it for readers, as deployah did, rather than leaving a trap in the record.

Related: [[pool-claim-writes-a-record-the-BUILD-enforces]].