The enum that was never written: COMPLETED for runs that did nothing

An enum value is a promise about what the system will be able to tell you later. `StepExecutionStatus.SKIPPED` sat in this project's code from the beginning with zero occurrences anywhere ^[4], so the schema described a state that no writer ever produced. Because the step view reads rows, the skip was missing from the UI for the same reason it was missing from every query ^[6]. A run that skipped every branch and a run that did the whole job were indistinguishable at every layer a person or an alert would look at ^[8], and the only surviving evidence was a JSON blob on the execution row ^[5].

Put a size on the quiet period. The author reports 27 skips a day ^[3] over weeks ^[2]. Taking that plural at its minimum, two weeks, that is at least 378 branch executions that produced no row anybody could count ^[1]. The repair took an afternoon ^[9]. The interval between the two is the whole story: nothing was hard, nothing was expensive, and nothing was visible.

What makes the write-up useful is that the obvious fix got rejected. Counts derived from the new rows are facts, and the author notes they cannot drift from what the step view shows because they come from the same rows ^[9]. The badge announcing that a finished run had processed nothing was a judgement, and the reviewer killed it inside the hour ^[10] on the grounds that a zero can be correct: a scheduled workflow on a quiet day genuinely processes nothing, and the alert only earns trust when the count is two-sided, with the run's number tied out against what the source says it handed over ^[11]. The author's own verdict on his badge is that it would have fired on every quiet day, been muted within a week, and been absent on the day it mattered ^[12].

Two partial answers appear, and both have declared edges. History gives you a baseline: zero in a normally busy slot is a signal, zero in a normally quiet one is not, which is probabilistic but enough to know where to look ^[19]. The gap the author names himself is that a new workflow has no baseline, which is exactly when a condition is most likely to have been written wrong, and his 27 branches were dead from the first run ^[20]. The other answer is placement. Per-step assertions do not scale past a handful of workflows because each assert is another thing to maintain, so the check belongs in the engine, once, where every workflow inherits it ^[18].

The deploy script two days later is the same defect in a different building. Five true green lines, including containers running and a healthy endpoint ^[15], while the shipped feature was dead because the containers had started before the environment variable it needed existed ^[15]. It was found by curling the endpoint and reading the value back, which the script never did ^[16]. Generic health checks pass on a corpse; the specific effect check is the one nobody writes ^[17]. A thread contributor described the cascade version, where a dropped local model call completed, passed an empty payload on, and every downstream node succeeded against nothing ^[21].