Adding a ticket state breaks the build at every match site — how do you sequence that change across a large codebase?

## The error list is the migration plan The reason a closed, exhaustively checked type is worth its cost shows up exactly here. In most codebases, "where does this change need attention?" is answered by searching, by memory and by whoever has been here longest. With this mechanism the answer is computed: add the variant, compile, and the build hands you a list of sites that must decide what an escalated ticket means. Within the code being compiled, and excluding the gaps named below, that list is **complete** — it includes the paths no test covers and the modules nobody remembers. The skill being probed is not enjoying the list. It is knowing the order to work it in, and knowing what it leaves out. ## Sequence it so the errors arrive under no traffic 1. **Declare the variant, construct it nowhere.** The type grows a fifth state, but no code path can produce one. The build breaks immediately and broadly, with zero tickets in that state anywhere. 2. **Work the compiler's list, deciding each site.** For every error, answer the actual question — where does an escalated ticket route, does it count as open work, does the response-time clock run? Each site gets a decision, not a copied default. 3. **Resist the shortcut.** Pasting a catch-all at each site to get to green converts a one-off cost into a permanent loss of the guarantee, and the next variant will be silently absorbed at every site you touched. 4. **Audit the sites the compiler could not name** (below) before declaring the migration done. 5. **Then turn on production of the variant**, readers first, producers last. The ordering principle is that a build error under no traffic is the cheapest possible form of this change, and every step that delays production of the variant keeps the change in that cheap regime. ## What the list cannot contain The compiler reports **gaps**, and a site with no gap is invisible to it regardless of whether it is correct: - Matches that already ended in a **catch-all** — still total, still silent, and now quietly applying an old branch to the new state. - Dispatch built from a **chain of equality tests** on a state tag, whose final fallback absorbs anything unrecognised. - **Tables or maps keyed by state**, which are data rather than code; a missing key surfaces, if at all, wherever the lookup happens. - Code matching a value that was **widened** to a more general type before the match, where the variant set being enumerated is not the one you changed. - Anything **outside this compilation** — a separate component, or persisted data. | Where the new variant can hide | Does the build flag it? | How it shows up instead | |---|---|---| | Match listing every variant | Yes | A compile error naming the site | | Match ending in a catch-all | No | The new state runs an old branch | | Chain of equality tests on a tag | No | The final fallback absorbs it | | Table keyed by state | No | A lookup miss or a default, at run time | | A component built before the variant | No | Its decoder meets a value it cannot name | A search for all-matching cases over that type is the cheap first pass on rows two and three, and it is worth doing *before* the variant is added rather than during. ## Outside the program The proof covers values that are already instances of the closed type. It says nothing about the text or bytes those values were decoded from. So the boundary needs its own plan: - Every **decoder** of a stored or received state gains a case for the new variant, and keeps an explicit error path for input it does not recognise. - A component **built before the variant existed** now reads records containing it. Its decoder meets a value it has no case for and does whatever it does with unrecognised input: fail loudly if it has an error path, produce a wrong default if it does not. Nothing inside the closed type can protect it. - Therefore **update and deploy every reader first**, and only then allow anything to write the new state. Reversing that order is the most common way a well-checked change still causes an incident. ## Deciding, not defaulting The last piece is cultural rather than mechanical. A large error list is uncomfortable, and the temptation to make it disappear uniformly is strong. But the list is precisely the set of places where somebody once wrote down what each state means, which makes them the places that must be told about a new one. Working them individually is the cost of the guarantee; paying it once per variant is the deal the closed type offered in the first place, and it is a deal that only pays out while the catch-alls stay out.