---
name: a-tombstone-silences-the-pump-while-status-reads-held
description: "After a prune, a roster tombstone on the LIVE peer zeroed the pump's fan-out (peers_total 0, no dial, two restarts) while subnet status still read the subnet as held; prune resolves from the ROSTER only, so a registry-only ghost is unreachable by it. Check tombstones after any prune."
metadata: 
  node_type: memory
  type: project
  originSessionId: b7f12e32-0eab-44ff-b86f-e5002979f90e
  modified: 2026-09-07T06:22:27.133Z
---

Measured 2026-09-07 05:59Z–06:20Z on the W2 field rig pair (releases#281 + its correction comment).

**Mechanism.** `spt subnet prune <node>` resolves its candidate from `roster.members` only (exact
hex / prefix / label, cli.rs `prune_candidates`); registry-snapshot eviction runs only after a roster
hit. After a re-pair, a dead identity that the roster has already forgotten but the registry still
advertises (12 endpoint rows, same label as the live successor) is NO_MATCH: prune cannot reach it.
The operator ran the LABEL form (`prune hfenduleam`, confirmed 06:22Z): the only HFENDULEAM
left in the roster was the live successor, so prune tombstoned it and printed `PRUNED:79984cca…`,
a hex the reader could have compared against the ghost's and did not (me included, reading
"pruned"). A label that names two identities across roster+registry resolves against the roster
alone, silently. `push_targets` → `members_in`
skips tombstoned rows, so the pump had `peers_total 0` and logged no `PUMP_DIAL_SUBMIT` across two
restarts, while `spt subnet status` still listed the subnet as held and `node status` said nothing.
Stripping the tombstone (file edit, backup kept) restored the dial in ONE round, no restart.

**What I got wrong first.** I read the surviving registry rows as "the running daemon re-saved them
from memory 34 s after prune" and filed that. The file mtime was a normal save; the rows survived
because prune never targeted them. A save that happens to follow your command is not evidence your
command was undone. Retracted on the issue by comment, not by edit.

**How to apply.** After ANY prune/leave/revoke on a rig or fleet home: dump `roster.json` top-level
keys and the `tombstones` list, and read the pump's `targets`/`peers_total` from
`spt subnet status --json`, before calling the trust change done. A zero-target pump with a held
subnet = look for a tombstone on the peer you still want. For a registry-only ghost: stop the daemon,
move `identity/registry/<subnet>.json` + `heard.meta` aside, start (the daemon never reads the
snapshot back, #281 face 2). Related: [[ephemeral-ports-flag-silently-beats-spt-docs-port]],
[[never-send-a-claim-composed-before-its-check-ran]].