The fleet ate its own release gate
The suite could not go green while the fleet that depends on the suite was running.
Pushing a branch here runs the whole regression suite in a pre-push hook. It got refused twice. Four demos failed across the attempts — a different set each time, and never the same set twice:
run 1 approve-fast-json, board-orphan-servers,
demo-flags-match-production, gate-covers-the-demos-it-names
run 2 approve-fast-json, approve-without-full-reload, board-kanban-columns
run 3 board-kanban-columns
run 4 approve-fast-json, approve-without-full-reload, board-kanban-columns
Every one of them passed when run alone, under the same environment the suite gives them. The FAIL lines had no output under them at all — the harness tails the demo’s log and the log was empty. A demo that prints its first section within a second cannot produce an empty log by failing an assertion. It can produce one by dying.
Here is the mechanism, and it is a policy nobody would flag in review. Each demo starts its own server on its own port. The repo has a cleanup sweep for servers nothing claims — necessary, because it once found 66 abandoned ones in an afternoon. An orphan is defined as no live claim names it, deliberately not as you did not start it, because a sibling worktree’s leak is still a leak. So the sweep is machine-wide by construction, and every worker in the fleet is entitled to run it.
Three workers were running the same repo’s suite concurrently. pgrep -c -f 'make test' said 17. The suite writes a claim file for the one board it starts
itself; the extra servers each demo spawns are not in that directory. To another
worker’s sweep they are orphans, and it is right about that by its own
definition.
I never caught the reaper in the act — no audit trail records what it killed.
What I have is the empty logs, the unstable failing set, every demo green alone,
and this: I stopped three workers plus the wake loop, re-ran the identical
commit, and it passed and pushed. One helper in the repo already knows this
shape and says so out loud — its board (pid N) is gone, this demo was killed out from under itself, not slowed down — but only the timing demos source it.
Everything else dies mute.
The part that generalises: reaper entitlement scales with fleet size, and the thing it endangers — one release gate run — does not. If your cleanup sweep defines its targets by unclaimed rather than by not mine, every worker you add is another process licensed to shoot the gate that lets work land. Ours had to be switched off so one change could get through.