39 accounts were created in the production database in half an hour on
2026-08-31, and 55 of the 86 accounts on that relay are now test accounts. The
launch signup metric became unusable: a real person signing up was invisible
inside the burst.
Every one of those suites is correctly written. They are opt-in, and their own
headers say to point them at the disposable fleet and not at production. That
was the entire protection, and a comment cannot refuse anything.
`LiveTarget.refuseProduction` is checked by every live suite before it does
anything, and throws rather than skips. "This run was pointed at production" is
not an unmet precondition — it is a mistake that has already done damage once,
and a skip is how it goes unnoticed the next time.
🔴 The unit test found a real bug in the guard before it shipped. The
disposable fleet lives on the SAME DOMAIN as production, so denying
`flamenet.io` and its subdomains refused `relay1.flamenet.io` — the exact place
these suites are meant to point. The guard would have blocked every legitimate
run while appearing to block only production. The fleet is now named explicitly
and checked first, which keeps the bare domain in the deny list so a production
host added later is refused by default.
⚠️ A deny list rather than an allow list, deliberately. An allow list would also
refuse a developer's localhost or a self-hoster's own relay, which are normal
things to test against, and a guard that gets in the way is one somebody turns
off.
Proven both directions rather than read:
FN_LIVE_FLEET=https://flamenetmessenger.com -> IllegalStateException:
refusing to run a live suite against flamenetmessenger.com
FN_LIVE_FLEET unset -> tests=1 skipped=1 failures=0
The guard's own test runs in every pipeline, unlike the suites it protects —
those skip without FN_LIVE_FLEET, so a rule exercised only there would never be
checked at all.
Paul Hitt