---
name: spt-crate-is-binary-only-no-lib
description: "The `spt` crate has no lib target — gate with `--bins`, because `--lib` exits 101 and reads like a red"
metadata: 
  node_type: memory
  type: project
  originSessionId: f438335b-fb84-458b-874d-de4b67400c4b
  modified: 2026-08-19T22:23:46.920Z
---

The `spt` crate is **binary-only**. `cargo nextest run -p spt --lib <filter>` fails with:

```
error: no library targets found in package `spt`
... exited with code 101
```

**Why:** that 101 is a *rig* error, not a test failure — and it lands in a gate log looking exactly like a defect. Same class as the known `spt-daemon --lib` gotcha. A per-crate gate script that assumes every crate has a lib target will produce a red that costs someone an investigation.

**How to apply:** use `-p spt --bins` for the `spt` crate's unit tests (they live in the binary target — `spt::bin/spt api::tests::...`). When a leg exits 101, read the leg's output before reporting it: distinguish "no targets matched" from a real failure. Report rig errors *as* rig errors when handing a gate summary over, so they don't get mis-filed later.

**Second face (2026-08-19, #178 gate):** I hit this AGAIN with the entry already filed and GATE-TEST-INDEX already opened that session. Mechanism: the gate script was authored by extending a prior script (gate-164 had no spt-unit leg), and the new leg was written from habit — the index was consulted at session start, not at the moment of ADDING a leg. The consult that matters is per-leg-authored, not per-session: when adding a unit leg for a crate, derive the target shape first (`--bins` vs `--lib`) instead of defaulting. Cost was small only because the 101 was classified MINE before reporting (is-this-red-mine discipline caught it).

**THIRD FACE, AND IT IS THE DANGEROUS ONE (2026-08-21, #196 lane):** with plain
`cargo test` rather than `nextest`, the same mistake **exits 0**, not 101:

```
$ cargo test -p spt --lib the_inert
error: no library targets found in package `spt`
$ echo $?
0
```

So `--lib` on this crate is a red under nextest and a **silent PASS** under
cargo — the word `error:` on stderr above a zero exit, which any wrapper,
script, or `&&` chain reads as success. I ran it to check three brand-new unit
cells and would have reported them green having executed NONE of them. The
2026-08-19 face said "when a leg exits 101, read the output"; that advice is
blind to this face, because there is no 101 to notice.

**How to apply:** never take a filtered run's exit code as the verdict — read
the `test result:` line and the COUNT. `0 passed; 0 filtered out` means the
filter matched nothing, whatever the exit says. Kin: [[zero-match-filter-reads-as-absent]],
[[env-gated-test-returns-vacuous-green]] (a green too fast to have done the work).

Related: [[verdict-from-exit-not-from-silence]], [[gate-int-tests-with-nextest-not-bare-cargo-test]], [[w2-two-key-subnet-progress]], [[open-the-subindex-before-running-a-gate]].

## [root-merge 2026-08-23] lines present only in the .claude copy (union-merged at alt-profile migration; placement lost, content verbatim)

Related: [[verdict-from-exit-not-from-silence]], [[gate-int-tests-with-nextest-not-bare-cargo-test]], [[w2-two-key-subnet-progress]].