---
name: test-name-asserts-what-fixture-never-creates
description: "An uncovered arm reads as covered when the test NAME and comment assert a condition the fixture never constructs — the gate is not fooled, the human reader is."
metadata: 
  node_type: memory
  type: project
  originSessionId: 83743243-8adb-457e-9564-529945996ac9
  modified: 2026-08-19T02:27:25.848Z
---

A test named for a hazard can read as covering that hazard while its fixture never constructs
the discriminating condition. The traceability gate is NOT fooled — it only checks a tag exists.
The HUMAN is fooled, by the name.

Measured 2026-08-03 at `b7b00c3` on `REQ-HAZARD-WINDOWS-PID-RECYCLE` (activated, impl+unit,
spanning `spt` and `spt-msg`). Sharpest instance:

`crates/spt-msg/src/deliver.rs:344` — `recycled_pid_address_does_not_misdeliver`, comment
"(e.g. recycled to this test process)". The fixture writes the registry row with
`std::process::id()` and the probe reads that same live process back. **Nothing is recycled.**
What it proves is that a dead ADDRESS spools. The recycled-pid premise lives in the name and
comment only.

The same shape ran across all four of that REQ's unit tags: three exercise a genuinely ALIVE pid
(`std::process::id()`, or the runner's real parent), so "only the dead arm is tested" is FALSE and
refutable with one grep. The TRUE claim is stronger and survives every test: **every alive-arm
test presents a pid that is alive AND genuinely the recorded process. No identity mismatch exists
anywhere in the REQ's evidence** — which is the exact condition the hazard is named for.

**Why:** naming is the cheapest place to assert a property and the only place nothing checks it.
A fixture built from `std::process::id()` is always self-consistent, so the test passes forever
and its name keeps promising the arm is covered. Auditing by grepping REQ tags finds the tag;
auditing by reading test NAMES finds the promise; only reading the FIXTURE finds the hole.

**How to apply:** when auditing hazard coverage, read what the fixture CONSTRUCTS, never what the
test is called. Ask "what condition does this hazard need, and does any line here build it?" For
identity/recycle hazards specifically, `std::process::id()` and `parent_pid()` can never
construct a mismatch — they are the recorded process by definition.

Corollary that merges test debt with site debt: if the discriminating condition needs a field
that does not exist (here: no parent-side birth stamp anywhere in the tree — `Seed` carries
parent_pid/session_id/cwd/created, `info.json` stamps `pid_started_at` for `pid` only), then the
unit tag CANNOT be honestly satisfied until that field ships. Tell whoever takes the site half,
or they write another own-pid test and the REQ reads covered a second time.

**Second face — the fixture HELPER decides the outcome, and the arm's own comment cannot show you
(2026-08-18, golden 32205195794, `twohost_cli.rs:987`, `gated_cli_role_b`).** Two arms of one rung
ran the SAME CLI verb with the SAME flags and diverged: one accepted, one `ACCESS_REFUSED …
PolicyForbids{FORK, Closed}`. The whole difference was which seeding helper wrote each fixture.
`AccessStore::allow_surfaces` (`spt-store/src/access.rs:1689`) ends with
`if acl.modes.is_empty() { acl.modes.set_all(Mode::Closed) }` — whitelisting an endpoint silently
sets its per-surface POSTURE closed. The other arm seeded through `apply_mutation` under
`Authority::SameNodeUser`, which never touches modes. The seam then reads
`may_grant_node_subject` → `effective_posture` (endpoint modes FIRST) and refuses one, allows the
other. The rung's comment described the fixture correctly and STILL could not surface this: it named
the whitelist, not the mode write the helper does on the way.

Two riders. **A structurally impossible arm looks exactly like a flake until you state its
requirements together:** this one needed the endpoint resolvable-by-peer (⇒ whitelist ⇒ posture
Closed) AND an endpoint-authored node-subject grant accepted (⇒ posture Open) — mutually exclusive
under the policy, so it could not go green on any box, which is why its 1-execution/1-failure record
was the honest number and no rerun bought anything. **And subject-matter adjacency is not causal
proximity:** the refusal's topic (FORK, closed posture, engine room) sat squarely on three milestone
members, which is what made "product before rig" the intuitive read — the seeding path refuted it.
Go to the fixture's helper bodies before reasoning from what a refusal is ABOUT.

Caught by [[audit-the-boring-claims]] in the direction that matters — hertz audited MY sharpening
and refuted three specifics of it, one falsifiable as written, before it shipped into a filing.
Kin: [[zero-match-filter-reads-as-absent]], [[setup-suppresses-failing-arm]],
[[every-return-arm-is-a-copy]], [[a-predicate-without-its-tool-is-not-evidence]].