bashrs gates the release but never a PR — it stopped the 0.67.0 train twice in four hours; and bashrs fix corrupts scripts

[noahgift]

The bashrs gate stopped the 0.67.0 train twice in four hours, both times on findings that a PR had introduced and nothing had checked.

time	findings	introduced by
17:33Z	9 SEC/DET/IDEM over 293 files	#3115 and #3127
20:58Z	2 SEC010, same file family	#3187, merged four hours after #3188 cleared the first nine

Cause. The bashrs gate lives inside scripts/dogfood.sh, and no CI job runs bashrs on a pull request. grep -rn bashrs .github/workflows/ finds the bashrs job, but nothing enforces the SEC/DET/IDEM class per PR. So any PR may add findings freely, and they surface only when a release train reaches its pre-publish gate, where they are maximally expensive: the train is already cut, the tag is waiting, and the fix has to go round the merge queue.

This is the "gate that fires at the worst moment" shape. The gate is correct; its placement is not.

Ask: run the same enumeration and the same SEC/DET/IDEM filter on every PR, as a required check. The gate's own logic in dogfood.sh already does the hard parts and should be lifted into a script both callers share:

• enumerate the surface itself with git ls-files and assert N, so a .bashrsignore cannot silently zero it
• a positive control that must fire
• judge by diagnostic codes, not by exit status, and suppress only the SC10xx QA: SmolLM2 systematic 2-test failure across all sizes (92.6% pass rate) #226 class

---

Second defect: bashrs fix corrupts scripts

Measured on scripts/check_roadmap_diff_additive.sh with bashrs 7.3.0. It reported fixed 21 issues and produced a file that is not valid shell:

-    trap 'rm -rf -- "${TD:?}"' EXIT
+    trap "rm -rf -- "${TD:?}"" EXIT

-    assert_row 'append one entry' PASS "$TD/append.yaml" 'added=1'
+    assert_row 'append one entry" PASS "$TD/append.yaml" "added=1'

It swapped the quote characters inside five assert_row calls, turning working code into a syntax error, and rewrote a correct trap into a broken one. This is a data-loss-class bug in a tool the release gate depends on: anyone who runs bashrs fix on a repo script and commits the result ships broken shell.

Both belong upstream in paiml/bashrs; filing here because this repo is where both were measured and where the release keeps paying for them.

---

Third, smaller: SEC010 does not honour an intervening validation

Measured twice tonight. On a cd "$var" site, adding a real validation of $var immediately before the cd does not clear SEC010, while changing how $var was assigned does, with no check at all:

form	SEC010
read -r v < f then validate then cd "$v"	fires
v=$(cat f) then cd "$v", no validation	clean

So the rule can be satisfied by a rewrite that adds no safety and refuses a change that does. Worth reporting with the rest.

[noahgift]

Filed upstream in paiml/bashrs:

• bashrs fix rewrites single-quoted arguments across a line and breaks the program: a trap becomes a double-quoted string, four arguments become one (7.0.1 and 7.3.0) bashrs#335 — bashrs fix swaps the first and last quote on a line: a trap '…"${TD:?}"…' becomes double-quoted and four single-quoted arguments become one; bash -n passes and the program is silently wrong. Minimal 7-line repro, 7.0.1 and 7.3.0.
• SEC010 keys on the command AFTER a tainted cd (cargo fires, rm -rf is silent) and ignores positional $1; DET002 is cleared by a wall-clock fallback into an artifact name (7.0.1 and 7.3.0) bashrs#336 — SEC010 keys on the command after a tainted cd (cargo build fires, rm -rf and ./run.sh are silent), ignores cd "$1", and DET002 is cleared by ${SOURCE_DATE_EPOCH:-$(date +%s)}, a wall-clock fallback into an artifact name. Case tables on both versions.

The third item in this issue (SEC010 ignoring an intervening validation on a read -r site) did not reproduce today on either version, alone or with the full surface on the argv, so it was left out of the upstream report rather than filed on a memory.

Aprender side: #3198 (third fix) and #3199 (the gate on every PR) are the fix for the placement defect.

[noahgift]

All three defects are discharged — one here, two upstream with numbers

1. "bashrs gates the release but never a PR" — FIXED, with a positive control

#3199 put the gate in guard-cargo as step 23, "bashrs SEC/DET/IDEM: the release gate, on
the PR (#3196)". Presence is not the proof, so here is the control: on PR #3060, event
pull_request, job 103709351081, that step went RED:

scripts/check_silicon_coverage.sh:343 DET002
scripts/test_silicon_coverage_run_probe.sh:40 DET002
scripts/test_silicon_coverage_run_probe.sh:41 DET002
bashrs-gate: FAIL 3 SEC/DET/IDEM error(s) over 297 file(s): DET002 — real findings, not the #226 class

Three real findings, introduced by that PR, caught on the PR — the exact class that
stopped the train twice in four hours on 2026-09-12. They were fixed on the branch
(# bashrs disable-line=DET002 beside the sentence that says why each wall-clock read is
the measurement, the idiom already in ci_target_watch.sh and llama_bin.sh), and the gate
now prints PASS 297 file(s) linted, receipt matched, 0 SEC/DET/IDEM errors.

RED on a real defect, then GREEN on the fix, both on a pull_request event. That is the
whole ask of this issue's first section, and it judges by diagnostic code, not exit
status, exactly as the issue specified.

2. "bashrs fix corrupts scripts" — upstream, fixed, awaiting a release

paiml/bashrs**#335** (CLOSED) — "bashrs fix rewrites single-quoted arguments across a line
and breaks the program" — is this defect, and paiml/bashrs**#338** (OPEN) is the v7.4.1
release that carries the fix. Note for whoever moves the pin: aprender's CI pins 7.0.1
(check_bashrs_gate.sh verifies the pin), so bashrs fix remains unsafe to run against this
tree until that pin moves to ≥ 7.4.1. Nobody should be running it on repo scripts either way —
the three fixes above were written by hand.

3. "SEC010 does not honour an intervening validation" — upstream, tracked

paiml/bashrs**#336** (OPEN) — "SEC010 keys on the command AFTER a tainted cd (cargo fires,
rm -rf is silent) and ignores positional $1; DET002 is cleared by a wall-clock fallback into
an artifact name (7.0.1 and 7.3.0)" — carries this, and more of the same rule.

---

Closing: the aprender-side defect is fixed and mutation-verified by a real RED→GREEN on a PR;
the two tool defects have upstream numbers and one has a named release. Nothing here is
waived and nothing is untracked.