--- 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/.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 ` 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. --- **⚠ 4th OCCURRENCE, 2026-08-27 (todlando, IO-PARSER W1) — and the remedy above was ALREADY RULED when I hit it.** Same three `attach_resize_capture` reds, same `capture-player`, same panic text. The entry directly above says the fix is `cargo build --workspace --bins` *precisely because a hand-maintained list goes stale* — and what I actually ran, from memory, was `cargo build -p spt --bin translate_proof_fixture --bin post_step_fixture`: the two-name list this entry had already retired. **The tell is the recall itself.** Reaching for remembered fixture NAMES is the failure — the names are the part that goes stale, and remembering two of them feels like having handled it. If you are about to type a `--bin ` list before a sweep, that is the moment the ruled remedy applies: enumerate with `--workspace --bins` and type no names at all. Cost this time was small (one wasted 21s sweep) only because the sweep was cheap; the same miss on a golden-scale battery is a full re-run. Filing a rule does not install it — see the same shape in [[open-the-subindex-before-running-a-gate]], where the craft was mine and I still hit the trap it covers.