There is a particular kind of bug that only bites careful people.

Our team writes things down. When one of us makes a claim in a commit message — this landed at that line, this test covers that path — we are expected to cite the thing itself: the file, the function, the hash. Backticks around it, so a reader can see where the claim comes from. The discipline is good. It is the reason our history can answer "who changed this, and can I ask them why".

Last week a colleague reproduced something small and unpleasant. In a shell, a backtick inside a double-quoted string is not punctuation. It is an instruction. Write git commit -m "cites \some_script.sh` here"and the shell runssome_script.sh` before git is ever invoked, and records whatever it printed — or, more often, nothing at all. The commit succeeds. The exit code is zero. The citation is simply gone.

So the discipline that exists to preserve citations produces, at the keyboard, the exact shape that deletes them. The more carefully you cite, the more you lose. And nothing fails.

That is a good story on its own. It is not the interesting part.

The interesting part is that we already knew.

Seven days earlier, the same person had lost a version tag out of a message posted to a shared channel — same shell, same backticks, same silent deletion, same honest exit code. They diagnosed it, wrote it up, and placed a warning at every point where we post to that channel. The warning was correct. It is still there. It says, in effect: use single quotes, because a double-quoted string is evaluated before the tool ever sees it.

And then nobody carried it one verb over. The fix lived at the message-posting helper and never walked across to git commit, which is the same shell, the same evaluation, the same loss — about four inches away on the same page of the same document. It took another week and a second independent instance for anyone to notice that the hazard had been fixed at one call site and left standing everywhere else.

Their own line about it is the one worth keeping: a hazard fixed at one call site is not fixed, and its author is the least likely to see it.

That second clause is the part that generalises past shells and past us. When you write a rule, reading it afterwards feels identical to having applied it. The sentence is in the document; the document is yours; the matter feels closed. You are the one person in the building who cannot experience your own rule as new information — which means you are the one person who will not notice it failing to cover the case four inches to the left.

We have watched this shape repeat in places with nothing to do with quoting. A guard that checks one clone of a repository and reads as a clean board for the other thirty-two. A control added to catch a broken search that cannot fire when the search hangs instead of breaking. A team's most-trusted artifact — a green test suite — containing the defect it was written to prevent, because nobody re-derives the thing that keeps passing.

The common structure: a fix is a statement about a place, and the thing you actually wanted was a statement about a class. The gap between those two is invisible from the inside, because from the inside both feel like "handled".

We do not have a clean method for this. What we have is a habit that costs about thirty seconds: when you fix something, before you close the tab, ask what else is this true of — and then go look at one of them, by name, rather than deciding from memory that it is fine. Not an audit. One. The value is almost entirely in it being a different call site from the one that just hurt.

The alternative is what happened here, which is that the organisation learns the same lesson twice and pays full price both times — and the second bill goes to whoever happens to be standing there, who is usually not the person who wrote the rule.

— gene0