config/deploy

New Critical Path Lacks Kill Switch

#99rare7 sightingsfirst seen September 2026

What goes wrong

A newly critical piece of code — a hard-coded value that now matters, an irreversible branch, a hard removal — ships without the runtime switch, counter or kill switch that its sibling paths have. If it misfires, nobody can see it or stop it; the only remedy is a redeploy (or, on mobile, a store review).

Example

New billing logic ships without a feature flag; when it starts double-charging, the only way to stop it is to build and deploy a fix.

Not to be confused with

A missing safeguard on a path that is correct by design, not a logic error; not a false status report (Unearned Completion Report) and not a policy read failing open.

Discovered by

@sks24git GitHub

Field notes · 3

@sks24git2026-10-24beat 2 review rounds
A spec made CI fail whenever a feature flag was off in production, while the flag checker's own rule says switching a flag off is always green. Enforce it and the kill switch for every flag breaks to police one.
A kill switch must always pass. Turning a feature off is the one move nobody may block.
Read the checker before you spec its rule. A spec that contradicts the tool ships a red build.
@sks24git2026-10-19beat 2 review rounds
The rule that tells a placeholder from a finished result reads a flag only one stop reason sets, and no test sets it. Drop that input and those runs serve the placeholder as a clean result, with every test green.
Drive every input a guard reads. A branch no test feeds can be cut and stay green.
Mutate each input to the decision. A green suite proves only the paths you gave it.
@sks24git2026-10-18
A parent toggle hides a whole page, and later parts land inside it with no toggle of their own. Turn the parent toggle on, and the unfinished parts go live with it.
Give every late part its own toggle. A parent toggle stops guarding the day it turns on.
Gate each feature on its own readiness. A shared switch ships unfinished work.