---
name: an-exhaustive-match-pins-placement-not-walk-list-membership
description: "A `_`-free match forces a new variant to be PLACED, never to be added to the hand-built list a walk test iterates — so coverage silently shrinks while every compiler pin holds."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 49302556-9da6-4935-bef4-5d1ca3f941f7
  modified: 2026-09-09T11:25:07.249Z
---

Measured 2026-09-09 (releases#289 commit 2, todlando). I added `PeerSilent` to
`KnockSendOutcome`. Both renderers (`knock_remote_refusal_line`, `knock_landing`)
match EXHAUSTIVELY with no `_` arm, and their doc comments say exactly that: a new
variant "fails to BUILD until it is placed on one side or the other." True — and
it stopped there. Two walk TESTS iterate a **hand-typed array** of variants:

- `every_send_outcome_is_answered_by_exactly_one_renderer` (asserts the partition)
- `the_remote_knock_refusals_render_as_prose` (RENDERS each line and asserts no
  run of spaces — the guard that exists because three lines once shipped with a
  lost `\` continuation baked into the output)

My variant was in NEITHER, and everything was green: the build, five unit cells,
four int cells, treqs. The list's own `assert_eq!(len, 8)` passed because I had
not changed the list. **The compiler pins PLACEMENT; MEMBERSHIP of a walk list is
unpinned by construction**, and the test that would have caught my own collapsed
`KNOCK_PEER_SILENT` literal was the one silently not covering it.

**Why:** a walk test reads like a compiler-backed guarantee because it sits beside
one, and its `len` assert reads like a pin. It is neither — it can only check the
variants somebody remembered to type, and a missing entry is invisible: no red, no
warning, one fewer iteration.

**How to apply:** after adding a variant to any enum, grep the enum name across
tests for array/`vec![`/`for … in [` literals and add it there too — the
exhaustive match will NOT remind you. Treat a `len` assert next to a hand-built
list as documentation of what someone typed, not as coverage. And the thread that
led me there was a STALE COUNT in a doc comment ("three NON-DELIVERY outcomes")
that my change made wrong: fixing the count is what made me open the walks. A
stale count is rarely cosmetic — it is a pointer at the coverage that did not
follow the change. See [[a-kept-caveat-goes-stale-when-the-evidence-narrows]] and
[[correcting-a-body-leaves-every-citing-surface-lying]].