improvise/context/code/tooling.md

The repository's own checkers

scripts/ holds the gates this repo runs on itself. They are code, and they are held to the rule they exist to enforce: a check nobody has seen fail is indistinguishable from one that always passes, so each of them carries a self-test whose cases are injected faults (doctrine(check_the_checker)).

Four docstrings in scripts/check-comment-runs.py point here. This is the file they mean.

---

1. The comment cap

check-comment-runs.py fails a .rs file carrying more than two consecutive comment lines. The rule is context/design-principles.md §6: reasoning lives in context/ prose, where it can be read, corrected and audited, not in a comment that nothing checks against the code.

The whole difficulty is deciding what is a comment line. Ten silent successes have been found in this one function, every one of them failing in the direction that looks like passing — a file that should have been flagged and was not:

• "test" in line matched #[cfg(test)], so every cfg-gated fixture cleared a gate written to reject exactly those. Anchor the match; an unanchored substring is a filter that over-matches, and a filter that over-matches fails in the direction that looks like success. (The same class as the bd ID audit's exclusion list, and as _JS_TEST's exclusion of .skip/.only.)
• A proptest! flag was set and never cleared, so the first proptest! in a file made every later fn — helpers included — count as a test.
• An attribute holding a bracket inside a string (#[cfg(feature = "[")]) left the bracket depth unbalanced and exempted the rest of the file. Every question is therefore asked of the scanner, never of the raw line: the scanner knows Rust strings, raw strings, char literals and nested block comments, and the attribute depth is counted over code text only.
• A fence that opens and never closes exempted everything after it.

Two rules that are decisions rather than accidents. A fence **suspends** the run rather than ending it, so two lines above a fence and two below is a run of four — a reader meets it as one uninterrupted block. And only a *runnable* fence earns the exemption: rustdoc executes a bare or rust and does not execute text, ignore or no_run, so the rest is prose wearing a fence.

2. The evidence check

--check-evidence holds context/test-evidence/ and the tests it describes to each other, in two directions:

• Orphans. Every heading shaped like a test name must name a test that runs.
• Unstated. Every test whose doc comment cites context/test-evidence/ must have an entry there.

Neither direction is "every test has evidence". Most tests have none and should not be forced to have one; what is checkable is a claim, and both directions are claims. The failure they close is the same one a dead ticket ID is: a pointer that reads as a promise the thing exists.

A leaf is not an identity

The names cargo lists are module paths, and the checker keeps them whole. Six leaf names collide in this workspace — two of them cited in evidence — so reducing a path to its last segment made a heading satisfiable by a test in another module answering another question. Renaming ui::project::tests::a_load_that_fails_is_not_a_rebase, the one its entry actually describes, left the checker at 579 entries, all name a test that runs, exit 0: the surviving ui::host::tests namesake answered for it.

So a bare leaf resolves only when it is unique, and an ambiguous one is a refusal naming the candidates — not a warning, because a warning re-creates the problem for anyone who does not read it. The heading is then written with its module path, which is also what makes the entry say which test it is about.

Note the two halves are both needed and neither is sufficient. The refusal forces qualification but cannot survive a rename on its own: rename one of a colliding pair and the leaf becomes unique, silently resolving to the survivor. Qualification is what closes that, and the refusal is what makes somebody write it.

What stays open is collision across binaries: --list prints module paths with no crate and no binary, so two crates sharing one could not be told apart (improvise-sxsf). Measured 2026-09-21 and still latent — 1444 names, zero duplicate full paths, and zero duplicate (crate, path) pairs.

The fix the ticket proposes — --list per package with the crate prefixed — was measured and is declined twice over. It costs 45.2s against 2.4s for the one workspace call (11 members, warm), 18× for an unreachable case, and --check-evidence needs the --ignored twin too, so the real figure is 22 invocations. More to the point it does not close the class it names: a package is not a binary. improvise alone carries five integration test binaries beside its lib, and an integration test's top-level fn lists with no module path at all — 60 of the 1444 names are bare — so -p improvise prefixes all six identically and tests/a.rs::foo still cannot be told from tests/b.rs::foo. A fix that ever becomes worth having is per-target (--lib, --test <name>), not per-package, and the ticket's proposal would have bought 18× for a partial cure.

The names come from cargo, not from the source

A heading is diffed against cargo test --workspace -- --list, minus the names that --list --ignored reports. It used to be scraped out of .rs text, and four shapes defeated that, all of them "evidence for a check that never runs" (improvise-rm4s):

shape	why the scrape accepted it
#[test] fn x inside a raw string literal	the scanner reads inside strings
#[cfg(feature = "…")] #[test]	the feature is never enabled
#[cfg(target_arch = "wasm32")] #[test]	cargo test --workspace is native
#[test] #[ignore]	it compiles, and never runs

The third is the realistic one here: this repo has real wasm32-only code and a wasm CI job that only runs cargo check. Adopting the stricter source cost nothing — all 539 headings resolved against a real listing on the commit that made the change — which is the moment to tighten a gate rather than the moment to argue about it.

Demonstrated before the fix, by injecting all four shapes into src/draw.rs and context/test-evidence/tui.md at once: the previous checker printed 543 entries, all name a test that exists, exit 0. The current one names all four.

What this costs: --check-evidence now needs a toolchain and a compiled workspace, about three seconds warm. A missing cargo says so rather than raising. The comment-cap check is unaffected and needs neither.

--rust-tests FILE takes a saved listing for a caller that has one, and it requires --rust-tests-ignored FILE: a first version took one file, called cargo_test_names with one argument, and so skipped the ignored rule entirely while printing the same success line as the honest path. A flag that is strictly more permissive and indistinguishable in the log is a bypass, not a convenience — so the pair is mandatory and the success line names its source. CI passes neither and runs cargo itself.

A missing context/test-evidence/ is not an early return either. It used to be, and it exited 0 while 170 tests cited a directory that was not there; the walk now yields nothing and every citation is reported unstated, which is loud.

Note what the self-test can and cannot carry here. The listing reader is testable from fixtures — a leaf name taken off a module path, an --ignored name subtracted, cargo's own prose not mistaken for a test — and those cases are in SELF_TEST_LISTING. The four source shapes are not: once defined comes from cargo, a fixture asserting "a heading with an empty listing is an orphan" is the same case however the Rust beside it is spelled, and writing four of them would be four copies of one assertion dressed as coverage. The evidence for those is the injection above, against the real tree.

What it does not close: citing is still scraped, so a citation inside a string literal would be reported as a test owing an entry. That is a false positive in the safe direction — loud, not silent — and it has no instance.

A demotion is a reviewer's job, not a gate's

A heading is classified by shape: a bare identifier is a Rust test, a quoted string a JS test, anything else is prose about the section (Helper — x, Note — y, a file's own scope). So any orphaned heading can be retired by rewriting it with a space and a dash, and nothing can check whether the prose is honest — no mechanism could, because the question is whether a sentence is true (improvise-9za9).

Two things make that tolerable. The unsafe direction is the one that fails loudly: prose that looks like an identifier is classified as a Rust claim and reported as an orphan, so the error you can make by accident is the noisy one. And the mechanism is git diff context/test-evidence/ — a demotion shows up there as a ### identifier line becoming prose, in the diff every reviewer already reads. The live instance, PR #69 demoting a heading while PR #72 restored its coverage under another name, is what says a reviewer rather than a gate has to catch it.

The printed count of prose headings is a convenience, not a guard: nothing stores the previous count and nobody diffs two CI logs, so a retirement moves a number no one is watching. Saying otherwise would claim a detectability it cannot support, which is the class of defect §7's adjacent-check section is about.

A flag adds a question; it never selects one away

--check-evidence used to early-return, so the flagged run answered the evidence question and said nothing at all about the comment-run cap. Three agents hit that independently in one campaign, and in one case a local gate went green while CI went red on a three-line doc comment (improvise-ijql). It is now additive: main runs check_cap first, then check_evidence, and returns the worse of the two.

The ticket offered a cheaper shape — leave the early return and print one line saying the cap did not run — on the precedent of PR #83 making --rust-tests name its source. That precedent does not reach this case, and the distinction is worth keeping. A provenance line and a disclaimer are not the same object. Naming which listing the names came from qualifies an answer the run actually gave; saying "the cap did not run" qualifies an answer it did not give, while still exiting 0. Exit 0 is what CI branches on and what a human reads as clean, so a disclaimer leaves the gate exactly as skippable and merely documents the skip. The rule the fix is written to is therefore stated over the exit code: a tree with a long comment run must not pass any invocation that can exit 0.

Which invocations those are is a decision, not a sweep. --self-test and --list-doctests are excluded and neither is an exception to the rule: the first scans no tree, and the second is a listing that renders no verdict. Only the two that answer "is this tree clean" are in SELF_TEST_DISPATCH.

That table is checked by running the script as a subprocess against a temporary tree, which is the only level at which this bug is visible — every unit in this file was correct, and the defect lived in main's dispatch. Both arms are needed and both were demonstrated: restoring the early return fails DISPATCH: --check-evidence: exited 0 over a four-line comment run, and forcing the cap to always report a violation fails the clean arm for both invocations, which is what stops an always-fail from satisfying the first. The temporary tree also has no context/test-evidence/ and no JS roots, so the evidence half is vacuously clean there and the cap is the only thing that can decide the exit code — the isolation is what makes the assertion name one question.

Two headings, one test

An orphan is a heading whose test nobody can find; the mirror image is a test that two headings answer for, and it is invisible to every rule above — each copy names a test that runs, so each copy passes. PR #92 shipped two entries under one heading where the older described a fixture the test no longer had and repeated a claim an adversarial review had measured false. A reader meeting the older one first has no way to know a successor exists two thousand lines down, so the stale copy reads as current. That is worse than an orphan, which at least announces itself as broken.

It is a refusal and not a warning, on the precedent improvise-rm4s set for the ambiguous leaf: the two are the same defect seen from opposite ends — one name answered by two tests, and one test answered by two names — so they are answered the same way. The refusal names the file and every line, in file order.

The key is the resolved test, not the spelling. ### f beside ### m::tests::f is two headings for one test, and grouping by the string would miss it precisely because qualification is the repair rm4s asks for; a heading qualified in one file and bare in another would have been the first way this came back. Resolution reuses the same leaf table the ambiguity rule uses, so a leaf that is genuinely ambiguous canonicalises to itself and is reported as ambiguous rather than as a duplicate — two different tests sharing a leaf are not two entries for one test, and conflating them would file the wrong repair. The check is over the whole directory rather than per file, because a heading keys a test name and a test name is unique workspace-wide once qualified.

What it still cannot see, and neither can any of the others: an entry that exists, names a live test, is the only one that does — and describes it backwards.

3. The others

scripts/kb is the only writer of prolog-sessions/kb.pl; its own reasoning is in context/code/kb-tool.md. scripts/node-test.sh, scripts/kb-test.sh, scripts/pr-watch-test.sh and scripts/assemble-stamp-test.sh are the same shape as this file's subject: a guard, plus a suite that makes the guard refuse what it claims to refuse. Each is wired into .github/workflows/ci.yml in the same job as the thing it guards, because a check that only runs locally is a convention.

scripts/check-ci-graph.py is the workflow's own gate: pages-deploy must needs every other job in ci.yml. The rule "every check job" was written down (improvise-x7cq) and a job added during review of PR #83 was still ungated with nothing noticing, which is what moved it from a sentence to a check. It reads the job keys and the needs: list off indentation, tracking which job a needs: belongs to — taking the first one seen would read another job's list as the deploy's and pass. README.md therefore states the rule and deliberately does not list the jobs: a second copy with nothing holding it to the first is what went stale, twice.

pr-watch and mergeability (improvise-edpl, improvise-zlj2)

scripts/pr-watch is what the orchestrator's merge procedure stands on, and until improvise-edpl its verdict failed only on mergeable == CONFLICTING. GitHub computes mergeability lazily: for a while after the base moves it reports UNKNOWN for both mergeable and mergeStateStatus. PRs #172 and #179 both exited 0 at UNKNOWN/UNKNOWN … 0 failed. A PR that has just become conflicting is in exactly that window, so it could pass the watch. It is the same shape as improvise-b4ks: an uncertain state read as success.

The rule now:

• UNKNOWN in either field is not an answer, so it is waited on. On timeout it exits 3, the same code as a check still running. It never exits 0.
• MERGEABLE/BLOCKED with no failed check is waited on too (improvise-zlj2). A required check that never runs therefore times out at exit 3, and does not exit 1.
• A known answer ends the wait early: a failed check (exit 1 whatever mergeability says, since waiting would turn a known red into a timeout), or mergeable == CONFLICTING. "Whatever mergeability says" includes MERGEABLE/BLOCKED, which is how a failed required check reports here, so it is the commonest red this script sees (improvise-9pfs).
• A PR that is no longer open ends the wait on the first poll that sees it closed, with exit 5 (improvise-1qaa). That poll is the first when the PR was already merged, and can come mid-wait when someone merges it during the watch. A merged PR reports UNKNOWN/UNKNOWN permanently (#189, read live), so the UNKNOWN wait slept the whole timeout there and then blamed mergeability. A closed one need not: #74 reads CONFLICTING/DIRTY, which already ended the wait, but as a misleading exit 1. The script now fetches state. Exit 5 is its own code, not 1 or 0, because under merge-as-soon-as-green "someone else already merged it" is a normal answer, and the caller should hear it as that.
• The head checks come first, and the ended check after them (improvise-24lz). A PR that merged at a head the watcher never saw is the PR #67 hazard in a new form. It exits 2, whether the head moved during the watch or --expect names another. Only then is a closed PR exit 5. On the first poll the pin block only records the head, so an already-merged PR still ends on its first read.
• The pass condition is an allowlist: mergeable == MERGEABLE and mergeStateStatus in CLEAN, UNSTABLE or HAS_HOOKS. Anything else exits
  1. That includes null and any state GitHub adds later, so the check fails closed.

Why each state is where it is. The main ruleset (gh api repos/fiddlerwoaroof/improvise/rules/branches/main, read 2026-09-22) requires three status checks. It requires no approvals, and its required checks are not strict.

• BLOCKED with a MERGEABLE flag means a required check has not passed. A failing one is already in the rollup, so the script has exited 1 before it reads the state. What is left is a required check that has not registered yet, and every healthy push passes through that state. The required Browser harness (OPFS contract + shell) check comes from the browser job, which needs: build. GitHub creates its check run only after build completes. For a second or three per push, then, every registered check is COMPLETED/SUCCESS, the required one does not exist, and GitHub reports MERGEABLE/BLOCKED. The first version of this rule refused BLOCKED, and so exited 1 on a healthy PR whenever a poll landed in that gap. The reviewer put that at 5–15% of watches at the 20s interval. An "unrun" required check and a "not yet registered" one look the same from the rollup, so the state is waited on. A check that genuinely never runs costs a timeout, exit 3, not a false exit 1. An earlier version of this section said that nothing else produces BLOCKED here. That was wrong: the needs: gap produces it.
• DIRTY can wear MERGEABLE for a moment while the two fields settle. It is refused.
• BEHIND needs strict required checks, which this repo does not set. DRAFT cannot be merged. Both are refused.
• UNSTABLE means a non-required check is unhappy. It stays a pass, as it was before. It is safe because the loop only reads the state once every registered check is COMPLETED, and any failed one has already exited 1. So whatever UNSTABLE is reporting, it is not a check in the rollup that is still running or red.
• HAS_HOOKS is GitHub Enterprise's "mergeable, with pre-receive hooks". It is harmless to allow.

The suite enumerates the whole mergeable × mergeStateStatus table, plus an unshipped value and null, rather than hand-picking cases. Why: improvise-90ea.

The suite also plays the needs: gap through, poll by poll: build running, then build done with no harness check, then the harness running, then CLEAN. That sequence must exit 0. The rollup it starts from is PR #189's, copied from gh pr view --json. Each earlier poll is derived from it with jq, by dropping entries or rewinding them to IN_PROGRESS.

Why the Pages deploy fails on "Found 0 artifact(s)" (improvise-864a)

actions/deploy-pages@v5 intermittently fails a push to main with No artifacts named "github-pages" were found for this workflow run, while the upload step was green in that same run. The ticket framed this as concurrent merges racing on one Pages environment, and PR #46 proposed skipping the deploy unless the commit is the tip of main. Both the framing and the guard are wrong, and measurement says so.

What was measured. All 100 push-to-main CI runs from 2026-09-19T22:02Z to 2026-09-21T05:02Z, from the run, job, step and log APIs (job metadata and logs outlive artifacts, which expire in a day and are all 404 now — so this is reproducible where the ticket's own artifact-count table is not):

deploys	with another run's SUCCESSFUL deploy completing inside this run's own upload→deploy window
12 artifact-not-found failures	12 (100%)
56 successes	2 (3.6%)
4 other failures	0 — all four are the unrelated Create Pages site failed: Resource not accessible by integration, from before enablement: false (improvise-3gy)

The direction is settled, and it is neither of the two the ticket offered. The oldest run of the 17:47Z batch failed at 17:47:23Z — before the next deploy in the batch had started (17:47:31Z) and before any Pages deployment existed at all, since deploy-pages fetches the artifact metadata before it creates a deployment. So the failure cannot have been caused by this run's own deploy, by supersession, or by a concurrent deploy. The artifact was already gone. The reaper is another run's successful deployment.

It is scoped by artifact NAME, not by run. In run 35560726456 the build job finalized three artifacts seconds apart — harness-serve, wasm-bundles and github-pages, each with an id — and 2m21s later that run's own lookup reported Found 2 artifact(s) and no github-pages. Same run, same token, same call, same retention: the two siblings survived and only github-pages was missing. That one observation rules out the whole family of general explanations — service flakiness, eventual consistency, retention, a token scope, a v3/v4 backend mismatch — because any of them would have taken the siblings too.

Four things this kills. Queue depth is not the mechanism: the three deploys of the 17:47Z batch never queued, running 9s and 17s apart with each failure taking one second, so the pages group serialized nothing. Retention is not it either — all three shared retention-days: 1, and since the newest-finalized expires last, expiry can produce 0/1/1 or 0/0/1 but never the ticket's 0/1/0. Nothing in deploy-pages deletes an artifact (an upstream feature request asks for exactly that capability, which is only open because nothing does). And the action-version theory dies on the interleaving: successes and failures alternate minute by minute on identically-resolved action SHAs.

One clause of the ticket's own correction is falsified, and the conclusion still holds. The correction argued the tip-of-main guard would have skipped the one deploy that published "and let 52507a6 deploy and fail anyway" — which assumed 52507a6's artifact loss was independent of its neighbour. It was not: 5f871f7's deploy completed at 17:47:40Z, four seconds before 52507a6's began. Fewer successful deploys really is the right lever, so PR #46 aimed at the right quantity for the wrong reason. It should still not be shipped, because the association is not a mechanism and the mechanism is not deterministic: 5f871f7 had a foreign deploy land inside its own window too and survived. A guard measured at nothing, against a probabilistic effect, is doctrine(measure_the_obvious_fix_before_reporting_it_as_the_fix) exactly.

What the evidence does license. The risk lives entirely in the upload→deploy window — every victim had a foreign deploy land inside its own — so shortening that window is the one lever with evidence behind it, and consolidating the build already did some of that. Closing it properly means no two runs holding a github-pages artifact across a deployment, which is a real change to the job graph with real costs and is not attempted here. A retry is not a fix: the artifact is gone rather than transiently unlistable, so a retry cannot find it.

4. The release preflight, and why a loud failure was not enough

scripts/release-preflight.sh answers, before a tag exists, the question the Release workflow answers after. The procedure is RELEASING.md; this section is the argument behind it, and the split is deliberate — a checklist followed at 2am is not read for its reasoning, and one that carries it does not get followed.

The root cause was a missing document, not a missing check. Nothing in this repo said bump the version before you tag — release.yml is cargo-dist's autogenerated mechanism, README.md §Installation describes the result, and context/plan.md Phase 3 carries one-time setup instructions from the launch plan. So the preflight is the second half of the fix; RELEASING.md is the first.

What happened. v0.1.0-rc3 was pushed while every crate still said 0.1.0-rc2. dist matches a tag against the root package's version, refused with "This workspace doesn't have anything for dist to Release!", and the four jobs behind plan skipped. Nothing was wrong with the workflow, which is worth stating plainly because the instinct on a failed release run is to edit the YAML. The trigger is correct, the pattern matches, the workflow is enabled; dist plan --tag=v0.1.0-rc2 succeeds today and --tag=v0.1.0-rc3 reproduces the CI error exactly.

The decisive evidence is a shipped release, not that local run, and an earlier draft of this passage rested on the weaker half. v0.1.0-rc1 and v0.1.0-rc2 both carry complete published GitHub Releases from 2026-04-11 — tarballs for all four targets, their .sha256 files, sha256.sum, dist-manifest.json, source.tar.gz and improvise-installer.sh (gh release view v0.1.0-rc2 --json assets). So the workflow is not merely expected to work: it demonstrably ran end to end the last time a tag and the version agreed. Note how nearly the opposite was concluded — gh run list came back empty and was read as "only one tag push ever ran this", when Actions logs simply age out at 90 days and those tags are five months old. An empty log is a statement about retention, not about history; the artefact a run published outlives the run, so ask the releases before asking the runs. "The four jobs behind plan skipped" is true of the rc3 run alone and must not be read as "no release has ever been built".

A tag push has failed this way before — and how much that proves is worth being exact about. gh run list --workflow=release.yml --event=push keeps the whole tag history, and it reads: rc1 failed twice (14s each) before succeeding on the third push (3m25s), rc2 succeeded first time (3m9s), rc3 failed (21s). All three failures carry the identical signature — plan: failure with build-local-artifacts, build-global-artifacts, host and announce all skipped — checked per job, not inferred from the durations.

A shared signature is not a shared cause, and rc1's is not knowable now. Only rc3's was reproduced (dist plan --tag=v0.1.0-rc3); rc1's logs aged out at 90 days, and its two failures sit on commits titled "feat: cargo dist info" and "chore: update version", i.e. during initial setup, where plan could as easily have failed on an incomplete dist config. So the honest claim is: this failure shape has now cost four pushes across two releases, and the one time anyone has diagnosed it, it was the version/tag disagreement. That is ample reason for RELEASING.md and a check before the irreversible step, and it is not a claim that the same mistake was made three times — a first draft of this paragraph said exactly that, from the durations alone, which is the same asserted-not-asked error the two paragraphs around it correct.

The signature is worth memorising because it is so cheap to read: plan fails in ~20s with four jobs skipped, where a real build takes about three minutes. Note the workflow also triggers on pull_request, where it plans without a tag and passes in ~20s — so a green 20s Release run on a PR and a failed 20s one on a tag look alike at a glance and mean opposite things.

Why a loud, precise failure still cost something. dist named the right answer in its own error text — "--tag=v0.1.0-rc2 will Announce: improvise". The problem is not the message, it is when it arrives: a tag is public and immutable by the time CI reads it, so the repair is a new version rather than an edit, and the tag that failed stays published forever. A check that runs after the irreversible step is a check in the wrong place, however good its message. So the preflight runs before tagging and prints the tag command only once it has passed — the honest path made the easy one, the same shape as Basis having no public constructor (gotcha 43).

"All three remotes" was wrong when it was finally checked. aa4e901's commit message said v0.1.0-rc3 had been pushed to all three, and that was copied from there into this section and into RELEASING.md before anyone ran git ls-remote. Run, it showed the tag on gh alone. That commit message is superseded on this point and cannot be corrected, which is why context/design-principles.md §6 says an argument must not live only in one. The irony was local: it sat two paragraphs from an empty log is a statement about retention, not about history — the same failure, a remote-shaped fact asserted rather than asked.

Then the fact changed again, within hours, and that is the better lesson. Three measurements of the same thing in one session: present on all three remotes and locally; then on gh alone; then nowhere at all — rc3 was deleted while this branch was in review. Only the first reading was careless. The second and third were each correct when taken, by two different people, and they disagree.

So the rule this section reaches for is not "ask rather than assert". It is that a remote-shaped fact has a shelf life even after you ask: a verified answer decays, and prose cannot distinguish a stale line from a live one, so a reader at 2am has no way to tell which they are holding. A document that records an inventory is therefore wrong on a schedule it does not control. This section and RELEASING.md consequently record how to ask — git tag -l, git ls-remote --tags <remote> — and deliberately record no inventory of which tags exist where. What never decayed is the principle: a wrong tag is left dead and the next version is cut. Note which half of the original correction survives and which did not: the commit message was wrong is durable, because it is a fact about a fixed text; the tag is on gh alone was true and is now false. The keeper is the one whose subject cannot change.

The primary check is textual and the dist plan run is a second opinion. An absent dist must not read as a pass, so the script says which of the two ran. It also tolerates a locally-installed dist whose version differs from the one pinned in dist-workspace.toml: that stops dist before it plans, and reporting it as a refusal would train the reader to ignore refusals.

Only the root package's version can disagree with a tag. dist-workspace.toml says members = ["cargo:."], so gp-tree sitting at 0.1.0 while everything else is on 0.1.0-rc2 is not a finding. The script lists such crates and says so rather than failing, because a deliberate split should stay deliberate and a silent one should be visible.

The test's first version was vacuous, and the fault injection is what showed it. scripts/release-preflight-test.sh originally asserted only did it refuse. Every negative case passed with the tag comparison replaced by if false; — because the script refuses a dirty working tree first, and this repo's tree is almost always dirty, bd auto-exporting .beads/issues.jsonl on nearly every command. Four of five checks were answering is the tree dirty while claiming to answer does it catch a bad tag. The test now runs the negative cases against a clean throwaway checkout and asserts the refusal names the version mismatch, so a refusal for the wrong reason is a failure rather than a pass. Two rival faults were injected against the repaired version — the comparison disabled, and expected derived from the tag itself — and each produces four failures and exit 1.

That is context/design-principles.md §7's "a check that looks like the answer, answering a neighbouring question", found in a checker written to prevent exactly that class, within an hour of writing it.

And the repair opened a second blind spot in the same place — which is the more useful half. Moving the negative cases to a clean checkout is what made the tag comparison reachable at all, and it thereby removed the only circumstance in which the test could observe the dirty-tree guard. Disabling that guard outright left all six checks green and the script exiting 0: the guard whose precedence caused the original vacuity had become the one thing the suite could not see, and the repair's own shape is what hid it. A vacuity and its repair are not two events here; the repair relocated the blind spot rather than closing it.

The check that closes it is therefore aimed the other way — a tag that matches the version, run against a dirtied checkout, so the comparison passes and a refusal can only be the tree. That is §7's assert the direction the default cannot supply applied to a fixture rather than to a default: the clean checkout is the fixture, and the discriminating input is the one that makes it dirty. The two faults are independent in both directions — with the comparison disabled the dirty-tree check still passes, and with the guard disabled the three tag checks still pass — which is what makes the seventh check worth having rather than a restatement of the other six.

What is still unchecked, and why that is a decision. The dist plan second opinion can be disabled — its refusal arm rewritten never to match — with the suite green, because every input the test feeds it is one the textual check has already refused. That follows from the arm's own design rather than being an oversight: it runs after the primary check, it is allowed to be absent entirely, and an absent dist already prints that only the textual check ran. Pinning it would mean installing a dist matching cargo-dist-version, which is the very mismatch the script tolerates on purpose. Stated here rather than guarded, so the next reader does not mistake the silence for coverage.

Where it runs. The kb job, beside scripts/pr-watch-test.sh — this repo keeps its check_the_checkers there, not in test. The step needs no trealla and no nix of its own; it is sh, git archive and awk.

---

5. One shell, one environment: scripts/checkers.sh (improvise-f9qf)

scripts/pr-reviews-test.sh passed 19/19 locally and 2/19 in CI on the same commit, because a multi-assignment local does not evaluate left to right on bash 5 while macOS's bash 3.2 tolerates it. Two real bugs were invisible to the machine that wrote them. This section is what that cost to close, and the half of it that is not obvious is worth more than the half that is.

The obvious half: two platform splits, neither detected

At 22ab58f there were sixteen shell scripts in scripts/: eleven #!/usr/bin/env bash, four #!/bin/sh, one #!/usr/bin/env sh. That is two splits, not one. bash is 3.2 on macOS and 5.2 on the CI runner; sh is bash-in-sh-mode on macOS and dash on the runner. Neither split had anything watching it, and the second had never been noticed at all.

Both are now #!/usr/bin/env bash, and checkers.sh refuses any other shell shebang in scripts/. Converting the sh scripts cost nothing — they were already a subset — and the point is not that dash is bad, it is that a script whose interpreter depends on the machine is a script nothing has tested.

The half that decides the design: direnv gives the right bash and the wrong environment

The cheap fix looks like "run scripts through direnv", and .envrc does put a nix bash 5.3.15 on PATH, which really is CI's semantics. It is not enough, and the reason generalises far past this ticket.

pkgs.mkShell exports a pile of generically-named lowercase variables that CI does not have. Measured inside this repo's dev shell: name, out, outputs, system, shell, builder, stdenv, phases, patches, buildInputs, nativeBuildInputs, doCheck, strictDeps and about twenty more. A script under set -u that reads one of them by accident is silent inside the dev shell and fatal in CI.

That is exactly what happened. fixture_file's broken third clause read $name — and inside the dev shell $name was nix-shell-env, so set -u never fired, the [ -f "$f" ] || fallback re-evaluated $name correctly on its own line, and the suite passed. Reproduced at 051f541^, on one machine, in one sitting:

how the suite was run	result
macOS /bin/bash 3.2	19 passed, 0 failed
direnv exec . ./scripts/pr-reviews-test.sh (nix bash 5.3)	19 passed, 0 failed
the same, with name unset	2 passed, 17 failed

The middle row is the finding. Two different reasons for green, one of them the correct interpreter, and the whole point of reaching for direnv was that it would not be green. A dev shell is not a reproduction of CI; it is a third environment, and it is the one that hides set -u faults.

The decision, and the two options that were weighed with numbers

A nix shebang was the ticket's first option and the user's own suggestion. Measured warm on the orchestrator's machine, 20 invocations each:

	ms per invocation
ambient bash -c true	5.1
nix shell nixpkgs#bash --command true	61.8
nix-shell -p bash --run true (the manpage shebang form)	675.2

61.8 ms is affordable; 675 ms is 132× the ambient cost, and scripts/beads-merge-driver.sh runs inside git's merge machinery. But the cost that decides it is not startup: only the kb job installs nix. build, test, wasm, js, harness-lint, browser and pages-deploy have none, so a nix shebang on assemble-stamp-test.sh or node-test.sh would need an installer step added to three more jobs — paid on every run, to reach a bash those runners already have. Declined.

zsh was the other option. It is not a shebang change: word splitting differs, arrays index from 1, globbing differs. Porting sixteen scripts means reading sixteen scripts, and the review cost is the whole diff rather than the shebang line. The runner also does not ship zsh, so every job would need an apt-get. Declined.

What was adopted instead pins the interpreter and the environment together, in one place, with no per-invocation nix cost:

scripts/checkers.sh is the one entry point for every check_the_checker. CI calls it and the local gate calls it, so there is no second invocation to drift. It does three things a bare ./scripts/X-test.sh does not:

1. Pins a bash ≥ 5. The ambient one is tried first, so a runner that already has bash 5.2 pays nothing; nix supplies one only when the ambient bash is older, which on macOS outside the dev shell it is. No bash ≥ 5 and no nix is exit 3 — a refusal, never a quiet run under 3.2.
2. Scrubs the environment to an allowlist (env -i plus PATH, HOME, TMPDIR, the NIX_* and GITHUB_* names, extensible through CHECKERS_KEEP). This is the part that closes the direnv hole above, and it is a positive list on purpose: the failure mode of a missing name is a loud "command not found", where the failure mode of an extra name is the silence this section is about.
3. Enforces the shebang rule, so the sh/bash split cannot come back.

The pinned bash's directory goes on the front of PATH, so a script the suite invokes through its own #!/usr/bin/env bash — or through sh, which nixpkgs' bash also provides — gets the pinned one too. Pinning only the outer shell would have left every inner one on the system bash, which is where the fault actually lived.

A suite is X-test.sh where X or X.sh is present beside it. That rule exists because scripts/node-test.sh matches *-test.sh and is a test runner, not a suite — the first version of the glob ran it with no arguments, which printed its usage inside an otherwise green gate. The naming convention ("a check_the_checker is named after the thing it checks") was already true; it is now load-bearing.

What the old local gate actually was

The gate in circulation was for t in scripts/*-test.sh; do sh "$t"; done. That loop overrides every shebang with /bin/sh, so on macOS it ran every suite under bash 3.2 in sh-mode no matter what the file said — the worst of the available shells, chosen by the gate rather than by any script. It is replaced by ./scripts/checkers.sh.

What is still not covered

web/*.sh is outside scripts/ and outside the shebang check; web/build.sh and web/assemble.sh are still whatever their own first lines say. The allowlist is a list, so a suite that comes to need a new variable fails loudly and someone edits it — deliberate, but it is a maintenance edge. And the scrubbing protects the suites; a production script run by hand inside the dev shell still inherits name and friends. Closing that would mean a guard in every script, which scripts/beads-merge-driver.sh — running inside git's merge machinery, possibly outside direnv — is a good reason not to write.

The seventh site is not a shell file

Seven places ran a repo script through an explicit sh, overriding the callee's own shebang — five in scripts/, one in web/assemble.sh, and one in dist-workspace.toml:

build = ["sh", "scripts/build-web-release.sh"]

All seven now invoke the script directly. The TOML one is the interesting one, and it is why the shebang rule alone is not the whole answer: checkers.sh scans first lines, so it cannot see an interpreter named in a build configuration. A script may declare #!/usr/bin/env bash, pass the gate, and still be handed to dash by whatever invokes it. The only defence there is reading, which is how this one was found — by grepping for the call after fixing the declaration, rather than stopping at the gate going green.