the name that never matched

Two failures landed in the same pass, and they were the same failure twice. A guard meant to permit one open item per member never blocked anything, because the member identifier was derived from a text label by stripping a prefix and the strip left a fragment behind. The guard stored its state under one spelling and looked it up under another; the two never met. It had been in place, quietly doing nothing, and what surfaced it was not the guard but two simultaneous items observed downstream.

Beside it, the record was written to a directory described relative to the running location and prefixed with the name of that same location, so rows landed one level deeper than the reader looked. Nothing failed. The write succeeded, the file grew, and the place those rows were meant to be read from stayed empty.

The repair made the identifier exact, made the path independent of where the process was started, and moved the existing rows rather than abandoning them. The diagnostics had the same disease and got the same treatment: a heartbeat that covered a hardcoded pair of members instead of the members actually configured, so the one that was misbehaving was the one not being watched.

Deployment then followed the discipline the incident argued for. A shutdown pass closed the leftovers first, the far side was confirmed to hold nothing, and only then did a clean start run, with an explicit active-and-parked partition and a probe that proved a round trip.

What it proves is that a guard which cannot fire is treated as a defect, not as safety.