The development scripts report results without having run anything

[akiomik]

Split out of #396, which was narrowed to the bugs that stop the scripts from
doing what they say. This collects the other half: every way
scripts/acceptance and scripts/benchmarks produce an answer when the thing
being measured never ran. None of them fails loudly; each looks like a result.

The cases

where	what is missing	what you get
acceptance/test.sh	$PROJECT_ROOT/tmp, which is gitignored and which nothing creates	both redirects fail, the second only after paying for a cargo run
acceptance/test.sh	mdl (a Ruby gem, vendored nowhere)	empty mdl.txt; two empty files compare equal, so mado and mdl "agree"
acceptance/test.sh	$DOC_PATH, until setup.sh has run	both files empty, same false agreement
acceptance/test.sh	a build that fails, or no cargo	cargo run writes only to stderr, mado.txt empty, exit 0
benchmarks/comparison.sh	node_modules, which is gitignored and which nothing installs	hyperfine --ignore-failure publishes markdownlint and markdownlint-cli2 as roughly a thousand times faster than mado
benchmarks/comparison.sh	mado's binary, when CARGO_TARGET_DIR or build.target-dir sends it elsewhere	cargo build succeeds, hyperfine times a command that cannot start, mado "wins"
both	the repository, when run from another directory	cargo cannot find the manifest

The node_modules one is the common case, not a corner: scripts/benchmarks/
tracks package.json and package-lock.json, node_modules is gitignored,
nothing runs npm ci, and README.md documents the benchmark as setup.sh then
comparison.sh. A fresh clone following the README publishes wrong numbers.

What a fix has to decide

Not just "add a check". hyperfine --ignore-failure is there deliberately,
because the linters legitimately exit non-zero when they find violations —
mado check on a file with violations returns 1 — so the scripts cannot simply
gate on exit status. The distinction that has to be drawn is present and
built versus what it reported, and it has to be drawn for every external
tool the scripts invoke.

Whether setup.sh should also run npm ci, or the README should gain the
step, is part of the same decision.

Why the linter would not have caught it

None of these is visible to shellcheck. They are facts about
hyperfine --ignore-failure's semantics, about cargo's output path, about
which files git restores, and about what an empty file means when two are
compared — not about shell syntax. #398 is worth doing on its own terms, but it
would not have found a single row of the table above.

That is also the argument in #397, applied to these scripts rather than to
action/entrypoint.sh: the failure mode here is not that the shell is written
badly, it is that this much conditional external-tool orchestration has no
tests and no type system, and every review round finds another unguarded
dependency. Related: #399, where the same class turned destructive.

[akiomik]

#401 is the same corpus seen from the result side: with the exclusion in #396 restored, mado and mdl disagree on 36 of the 52 fixtures. test.sh has no diff and no assertion, so nothing in the repository has ever reported that — which is this issue's point about scripts producing an answer nobody checks.

[akiomik]

One more for the table, raised reviewing #396 and left out of it because it is
this issue's class rather than that pull request's:

scripts/acceptance/setup.sh — an empty find result is indistinguishable
from success. style_files=$(find test/rule_tests -name '*_style.rb')
producing nothing skips the loop body, and the for still exits 0. If upstream
relocates test/rule_tests or changes the fixture layout, find writes to
stderr and setup.sh reports success anyway; test.sh then compares every
fixture, including the ones written against other rule sets.

That is the same failure this pull request fixes — the loop silently doing
nothing — and #396 does not stop it recurring. One line closes it:

[ -n "$style_files" ] || { echo 'no *_style.rb found' >&2; exit 1; }

It is here rather than in #396 because it is error handling, and #396 was cut
back to the bugs that stop the scripts doing what they say. Worth taking
together with the rest of this issue, since the decision is the same one: which
missing input should stop these scripts, and which should not.

[akiomik]

The setup.sh item I added above is now fixed in #396 instead. It kept coming back in review, and it is the shape of the very bug that pull request fixes, so regression-proofing it there was worth the one line. Everything else in this issue stands.