The other half of check

./blog.sh check reads the whole archive and says what is wrong: media a post asks for and hasn't got, links to addresses nothing answers at, two posts that would be served at one address. Through 1.3 that was where it ended — a list of findings and an exit code, with the fixing left to you and a text editor.

--repair walks it with you

check --repair is the checker's other half: for each finding it offers the one repair that finding allows — an old address written into the target post's redirect_from, a relative link rewritten to the address it means, an orphaned file moved to the trash. Nothing is applied without a keypress, nothing is deleted outright, and a finding with no obvious answer — two posts colliding, an image only a human can judge — is shown and passed over rather than guessed at.

It proved itself before it shipped: on a real archive it took 238 findings down to 42, and the 21 repairs it proposed matched what a person had already decided by hand, one for one.

--json says everything

The screen shows twenty of a kind and totals the rest — right for reading, useless for a script. check --json prints every finding, uncapped, each with its kind and its data, so anything that wants to act — a migration script, a cron report — works from the same facts the screen summarizes.

And check itself got stricter

The rule behind the new findings is one sentence: an archive check calls sound must be one the build will run on. A file that will not parse, a date nothing can read, text that is not a list of blocks, a slug that is not one path segment — each is now a finding, because each is a build that stops. The one tool whose job is to say otherwise no longer says "sound" about any of them.