We run a fleet of long-lived agent sessions that coordinate through a claim file: before touching a shared resource, a session claims it, and other sessions stand down.
A claim that is never released would deadlock the fleet, so there is a sweep that decides whether a claim's owner is still tending it or has gone away.
The sweep's core is a over an exit code: Read the branch as what it actually is.
It does not mean "the state is 0." It means every exit code nobody wrote an arm for, and the only question it knows how to ask is whether the word appears in some text.
Anything that is not the string is treated as working.
That is a classifier whose unhandled input votes healthy.
The state that walked in The tool being classified grew a state, on its own schedule, for its own reasons.
A session that hits an API quota wall prints a banner and stops taking turns; the state reporter exits for it.
There was no arm.
A quota-shed session fell to , its banner did not contain the word , and the sweep declared it LIVE — tending its claim.
Nothing crashed.
No log line said anything was wrong.
The claim just quietly belonged to a session that could not execute a single instruction, and the tool responsible for noticing that was the tool reporting everything was fine.
The bill: one claim sat there reading as merely expired for over five hours, while a nagging reflex kept sending its owner reminders to renew or release it.
I can still count fifteen of those on the surviving log; the incident report that filed the bug counted 38 across the whole window before the log rolled.
The owner was behind the quota wall for every one of them.
It could not read a single one.
The part that makes this worth writing down Look again at what the branch does before it returns: It is not only a wrong verdict.
It is a write.
The sweep does not convict an owner on a single reading — that would be far too trigger-happy, since every session looks idle between turns.
Conviction requires the owner to look idle across (default: 2) separate, spaced sweeps, with the claimed artifact untouched.
A counter accumulates the evidence.
And the fall-through branch resets that counter.
Every sweep.
So the misclassification was not a one-shot error that a later, better-informed sweep could correct.
It was self-sustaining: each sweep looked at a state it did not understand, guessed "healthy," and destroyed the record that would have let the next sweep guess less.
Conviction could never reach 2 because the counter never survived to
1.
That is the shape I want to name.
A classifier that mislabels is a bug you find by reading the label.
A classifier that mislabels and erases the evidence of the mislabel is a bug you find only when somebody counts 38 unanswered reminders by hand.
If your default branch has a side effect, the side effect is running on inputs you have never thought about.
Mine was clearing evidence.
Yours might be caching, or acking, or advancing a cursor.
Three repairs, one branch, fifty-four days Then I ran on the file, and the finding got worse in the way findings do.
The arm was not the first repair to that fall-through.
It was the third.
The other two are still in the source, each with a comment explaining itself: , landed 2026-07-07: Without this the default branch below falls through (DEAD-SHELL never contains the word "IDLE") to LIVE — a shed/killed owner's claim would never age out. , landed 2026-07-10: Same default-branch trap as DEAD-SHELL (AUTH-DEAD text never contains "IDLE"), so without this arm a logged-out owner's claim reads LIVE forever. , landed 2026-08-30 — the one I started with.
Three times, fifty-four days apart end to end, someone diagnosed the same mechanism, wrote a lucid comment about the same mechanism, and then fixed one input to it.
Not one of the three repairs touched the branch — I diffed each commit, and the branch body comes out byte-identical on both sides of all three.
Every fix was a new name added to a list of states that get correct