---
name: fresh-pool-missing-fixture-bin-reads-as-a-code-red
description: "`cargo test -p spt --bins` in a FRESH pool fails adapter_translate_proof_gates_on_commit — --bins compiles bin targets as test harnesses into deps/ and never emits target/debug/<fixture>.exe. A rig red wearing a product red's clothes."
metadata: 
  node_type: memory
  type: project
  originSessionId: 94b5d55b-90d1-4473-8623-929bda19d570
  modified: 2026-08-21T11:22:39.964Z
---

`crates/spt` declares test-only fixtures as ordinary `[[bin]]` targets
(`translate_proof_fixture`, `post_step_fixture`), homed under `tests/` so they
never ship from `src/`. `cli::tests::adapter_translate_proof_gates_on_commit`
resolves one by PATH — `target/debug/translate_proof_fixture.exe`.

**The trap:** `cargo test -p spt --bins` compiles each bin target *as a test
harness* into `target/debug/deps/`. It does **not** produce the plain binary at
`target/debug/`. In a pool that has never had a full `cargo test -p spt`, that
file therefore does not exist and the cell panics:

```
translate_proof_fixture must be built: ...\target\debug\translate_proof_fixture.exe
(run via `cargo test -p spt`)
```

It reads as a product failure in a sweep summary — one red among hundreds of
greens, in the package you just changed. It is a fresh-pool artifact.

**Why it hides:** a lane whose pool has already run `cargo nextest run -p spt
--test <something>` HAS the artifact, so the same command passes there. My #196
lane was green on this cell and my #172 lane (fresh pool, brand-new worktree)
was red on it — same command, same tree shape, different pool history.

**How to apply:**
1. In a fresh pool, build the fixtures once before any filtered `--bins` run:
   `cargo build -p spt --bin translate_proof_fixture --bin post_step_fixture`
   (or run `cargo test -p spt` with no target filter, which does both).
2. Read the panic TEXT before classifying a red. "must be built" and a path is a
   rig error; it even names the correct invocation.
3. Kin trap in the same family: [[spt-crate-is-binary-only-no-lib]] — target
   SELECTION deciding what exists, not what is correct.

Related: [[is-this-red-mine-delta-test]], [[cargo-builds-package-bins-for-integration-tests]].

---

**⚠ THIRD MEMBER + THE REMEDY GENERALISED, 2026-08-22 (todlando, doyle-ruled).** The class is NOT
confined to `crates/spt`'s two fixtures. `adapters/mock`'s **`capture-player`** gated five test files
and produced three reds in `spt-daemon::attach_resize_capture` in a fresh pool — panic text
`prebuild the fixture binary: cargo build -p mock-adapter --bin capture-player`, which again NAMES
ITS OWN REMEDY. I prebuilt from a REMEMBERED two-name list and covered one fixture of the population.

**RULED REMEDY (replaces the two-name list): prebuild by CARGO'S OWN ENUMERATION —
`cargo build --workspace --bins`.** A hand-maintained list is the roster problem one layer down and
will keep going stale as bins are added.

**And do not census bins by grepping `[[bin]]`:** an autodiscovered `src/bin/*.rs` target has no
stanza, so a stanza grep is structurally unable to see it and will report a confident zero about the
one bin it can never find. That exact miss recorded a live bin (`xlate_choreo_fixture`) as
non-existent in the register and nearly shipped a false retraction. The single authoring site for
the requirement is `spt-term/tests/support/fixture_bin.rs`, whose `build_hint` composes the exact
command per fixture — read the hint rather than a list.