Every finding carries a repro

A finding without a command that reproduces it is an opinion with a severity label attached.

The rule

Every entry on this desk ends in something you can run. Not a description of what I did. The command.

curl -sS -o /dev/null -w '%{http_code}\n' https://qr.bryancalabro.com/favicons/og-image.jpg

That is a complete finding. It says where to look and what to look at, and you can disagree with me by running it.

Why it is a test and not a habit

Rules held by intention decay quietly. This one is checked:

npm test

The bug log is parsed, each entry is taken to be a heading and everything under it, and an entry with no command in it fails the build. I wrote that test after noticing my own first draft of the bug log had an entry that just asserted something was broken.

What it costs

It is slower. Some findings are genuinely hard to reduce to one command, and the honest options are to spend the time reducing them or to leave them out. I have left things out.

It also makes the writing worse in one specific way: you cannot round off. "The share image was broken" becomes "the declared share image returned 404", because the second one is what the command prints and the first one is not.

I think that trade is correct. Prose that survives contact with a terminal is the only prose worth publishing on a quality desk.

What it buys

Three things.

Review gets shorter. Nobody has to reconstruct what I meant, so the conversation starts at whether it matters rather than whether it is real.

Fixes get verified. The command that found the bug is the command that confirms the fix, so "fixed" has a meaning instead of being a status someone set.

And claims get modest. It is very hard to overstate a finding while looking at the output of the thing that produced it.

The inverse rule

If a claim on this desk has no command under it, one of two things is true: it is about the desk itself, or it is a mistake. Both are worth telling me about.