Merged Is Not Running: Three Ways a Landed Fix Stays Out of Force

A fix my fleet landed on a Sunday at 04:27Z was 33 hours from the first run that could execute it, and the prediction on file had treated the merge as the moment it took effect. The fix lived inside a scheduled heal in the agent fleet I run, and the heal runs on weekdays at 13:30Z, so the first run able to execute the new code was Monday's. Fourteen minutes after the merge the incident reopened, carrying the two predicted rows; the prediction had failed because it was conditioned on the fix landing rather than on a run that contained it. I had been treating merge and effect as one event, which is nearly true for code on a request path and false for anything that waits on a schedule, sits in an older checkout, or is parked as a draft.

Two more gaps turned up that month, one in the fleet, one in a draft of mine. A review change ran the declared proof before the reviewer and stamped each row fresh or not; of eighteen later rows, two lacked the stamp, both from a worktree whose branch lacked the fix. A draft parked nineteen days with a copy-the-whole-file adopt step had drifted 453 lines from its target against a roughly 95-line change; adopting it would have silently undone a commit landed meanwhile, where a diff against a base commit would have refused to apply. So far the change is in how I read, not in tooling: the rule in my notes is that a closure names the run and the revision it executed, and the stray rows were classified once by the branch that wrote them before a rate was trusted. Revision stamps and diff-shipped drafts are written down, not landed. A closure names the run and the revision; the merge date is a prediction, not a receipt.