---
name: spt-bin-lane-fixture-bins
description: "`cargo nextest run -p spt --bin spt` on a cold target reds one row because it never builds the package's sibling FIXTURE binary — a lane artifact, not a product failure"
metadata: 
  node_type: memory
  type: reference
  originSessionId: 0124b43e-03c3-4f05-8ea3-5033762b4fe5
  modified: 2026-08-02T10:02:47.825Z
---

`cargo nextest run -p spt --bin spt` (my standing unit lane) builds only the `spt` test binary. Some rows shell out to a **sibling fixture binary** in the same package — e.g. `adapter_translate_proof_gates_on_commit` needs `target/debug/translate_proof_fixture.exe` and panics with "translate_proof_fixture must be built (run via `cargo test -p spt`)".

On a warm shared target it passes (the fixture is already there from an earlier build), so this only bites after a **branch switch or a fresh target** — which is exactly when a red is easiest to misread as "my change broke it".

**How to apply:** build the package's bins first (`cargo build -p spt --bins`), then run the lane. On this box that build prints `Access is denied. (os error 5)` while linking `target/debug/spt.exe` — the live agents hold that exe ([[live-agents-lock-target-debug-spt-exe]]) — but the fixture still lands and the test binaries are unaffected, so the lane goes green anyway. Do not chase the os-error-5 as a build break.

Do NOT switch to the full `-p spt` package lane to fix this: that pulls in the e2e binaries, which cannot run from a live endpoint (`$SPT_ENDPOINT_ID` set ⇒ `DAEMON_STOP_REFUSED`) and red immediately. Related: [[spt-verification-gates]], [[shared-target-stale-false-green]].