The tooling said it worked.

One real order sat in the dispatch queue three times. Nobody had done anything twice. The business could have sent three deliveries and billed for one.

1. A launch routine copied a 53 MB SQLite file inline, while the server was already taking traffic.
2. A concurrent write hit database is locked.
3. The intake endpoint returned 500.
4. The upstream SMS gateway did what gateways do, and retried.
5. The retry landed as a brand new row, because the endpoint had no idempotency key.

The fix persists the gateway's own receipt timestamp as an external key and lets a unique database constraint arbitrate. An application-level "have I seen this before?" check would race under exactly the conditions that caused the bug. Separately, the database moved to WAL so a backup stops blocking writers at all.

Proven by deleting the constraint and confirming the test went red. A fix that cannot be made to fail has not been tested. Negative control: a customer genuinely ordering the same thing twice must still produce two records.

There was no symptom. A 265,000-row message archive imported cleanly, no errors, no warnings. The absence of a symptom is the reason this one is here.

The parser matched one row shape and quietly skipped another: group messages, which included real customer orders. It surfaced only by ignoring the importer's own reporting and counting raw rows in the source instead. A second defect fell out of the same pass, where 27,264 dates failed to parse because one month was abbreviated with four letters where the format string expected three.

The recovered data was material. A single year's records went from 155,546 to 181,371. A clean exit is not verification. Reconcile against a count taken from the source, never from the tool doing the work.

A Spanish-derived character was rendering wrong throughout imported customer data, in names and in street addresses. The obvious fix is Unicode normalisation.

The obvious fix does nothing. The source contained a combining diaeresis where a tilde belonged, and Unicode has no precomposed form for that letter and diaeresis pair, so normalising is a no-op that raises no error and changes no bytes. It would have passed review, shipped, and silently accomplished nothing.

The real fix swaps the combining mark first, then normalises, scoped to the single affected letter so legitimate umlauts elsewhere survive. A test now guards the no-op case specifically, so nobody reintroduces the plausible version.

The reported scope was ten fields. It was twenty, and nine of those were street addresses, which is what a courier actually reads on the way to a delivery. Worth considerably more than the names.

A session summary written by an AI assistant reported the state of a codebase. Every specific claim in it was confident, precise, and false.

It cost five tickets deferred for no reason and a full working session spent proving nothing was broken. The response was a standing rule: any handoff's claims about the state of the code are untrusted until re-checked against the repository. Migrations listed, fields grepped, versions printed.

Roughly one minute of checking, against a session of phantom work. This is why I work AI-assisted and still verify before I act on anything a summary tells me.

A client reported their register crashing during service and sent a screen recording with the report. An explanation presented itself early and fit the description well, so I shipped against it.

It was not the fault. Decoding the recording frame by frame afterwards showed a different failure entirely, and the original one was still there. The cost was a pointless deploy to a machine a business takes money with.

When a report ships evidence, decode all of it and reproduce the actual failure before writing a line of the fix. A hypothesis that explains the symptom is not a verified hypothesis. Plausibility is precisely the thing that makes a wrong diagnosis expensive.