The script had worked for weeks. Then, overnight, a dropdown that used to hold four options held sixteen, a rule that used to be allowed was forbidden, and a field started closing itself half a second after it opened. Nobody told us. The portal had simply changed.
The automation's results made no sense — a form half-filled with data it never entered, dropdowns snapping shut mid-selection. Nothing was broken. Two of us were driving the same tab.
The record could never have been created — a required category did not exist yet. The system found that out only after it had already texted a one-time code to a real person's phone.
A single space inside an email address held one record hostage for weeks. It would have taken a quarter of a second to reject at the moment it was typed.
Open a pull request and you may see something that looks like a contradiction: a green "This branch has no conflicts" line, and right below it a red ✗ on the checks. Both are true at once — because they are answering two completely different questions.
You're mapping a messy source vocabulary onto a clean target taxonomy. The target has about 5,600 slots, so the job must be roughly 5,600 decisions — right? The backlog is already past 8,900, and still climbing.
You shipped a fix to how one field is computed, re-ran the pipeline across everything, and it reported a clean run. Then the consistency check still flags those records as wrong. The fix is in the code, the rebuild "ran" — and the records never changed. Your own optimisation skipped them.
The report said 80 duplicate groups still to resolve. You'd been resolving them for days. You run it again after a big batch and it *still* says 80-ish. The backlog isn't stubborn — the scan is counting work you already finished.
You hardened a skill in the repo, shipped the PR, and the agent kept loading the old one. Or you fixed the live skill by hand, and the versioned copy quietly stayed behind. Same root cause: the copy you run and the copy you version are two different files.