fix: report a missing ref once, and audit the two repositories it never saw

[bgard68]

What happened

The weekly run failed on 24 Aug with ToDoApp 4 open code-scanning/alerts and opened #4. That finding is now stale — ToDoApp#140 cleared those four Trivy alerts by refreshing the pinned base-image digests, and ToDoApp does not appear in today's output at all.

A manual run today (#14) came back red for a different reason:

=== branch-level ===
  FAIL  LotteryApp/frontend no required status checks
  FAIL  LotteryApp/frontend {"message":"No no permissions block
  FAIL  LotteryApp/frontend commit no permissions block
  FAIL  LotteryApp/frontend found no permissions block
  FAIL  LotteryApp/frontend for no permissions block
  FAIL  LotteryApp/frontend the no permissions block
  FAIL  LotteryApp/frontend ref no permissions block
  FAIL  LotteryApp/frontend frontend","documentation_url":"...","status":"404"} no permissions block

AUDIT: 8 failure(s)

LotteryApp is down to a single branch — git ls-remote --heads returns only main — so LotteryApp:frontend in BRANCHES points at a ref that no longer exists.

Why one missing branch became eight findings

gh prints the JSON error body to stdout on a non-2xx and exits non-zero. wfs() discarded only stderr, so the 404 body became its return value:

{"message":"No commit found for the ref frontend","documentation_url":"...","status":"404"}

for f in $(wfs "$r" "$b") then word-split that into seven tokens, and each token was audited as a workflow file — each failing the permissions: grep, each filing its own failure, one of them printing a fragment of the 404 where a file name belongs.

This is the rule in AUDIT.md inverted. A check that cannot run must not look like a check that passed; here a check that could not run looked like seven that failed, and buried the one fact worth reporting — a configured branch is gone — under six impostors and a piece of JSON. Same family as the missing-jq run in the README that read twelve empty answers as twelve disabled controls.

The fix

Read the exit status, not just the text. api() captures output and returns non-zero when gh does, so an error can no longer be mistaken for data. Callers then report what actually happened:

• Branch existence is asked once, up front. Its absence is reported as the configuration problem it is, rather than rediscovered by every check that reads the ref.
• A failed workflow listing says so, instead of yielding fabricated file names.
• A workflow that cannot be read says so, instead of being audited as empty and failing the permissions check on that basis.
• File names are read a line at a time, so word splitting cannot invent them — and a name containing a space cannot either.
• The secrets sweep gets the same treatment. A 404 body cannot contain a secret name, so an unreadable branch quietly pushed every secret toward "used nowhere". It now skips a branch it cannot list rather than counting silence as evidence of absence.

LotteryApp:frontend stays on the list, as requested. It now reports as one line:

  FAIL  LotteryApp/frontend branch not found - restore it, or drop it from BRANCHES

Which is the decision to make, stated once, by the tool whose job is to notice.

Targets

DevSecOpsSentinel and WidgetWorks are added to REPOS and BRANCHES. Both are public, both deploy from main, and neither has ever been audited — the weekly run has been reporting on five repositories while saying nothing about the two at the top of the profile. Ten deploying branches now, up from eight.

Expect this PR's audit run to be red. Two repositories are being looked at for the first time, plus the LotteryApp line above. That backlog is the point of adding them; it is not a regression from this change.

Also

rt() now uses its own temporaries. b, s and p are the branch loop's names too — nothing leaks today only because rt is called inside $( ), which is a thin guarantee to leave standing.

Left alone deliberately

• README.md:24, docs/FINDINGS.md and docs/HARDENING.md say "four repositories" about the sitting that produced this repository. That is history, and still true.
• docs/PIPELINE.md:3 says "across all five repositories". It now documents five of the seven under audit — writing up the two new pipelines is a larger job than this PR, flagging rather than silently rewriting.

Verification

• bash -n scripts/audit.sh passes; mode stays 100755.
• shellcheck is not installed in my environment — the Lint job runs it.
• The Lint probe still holds: an unknown target now fails the branch-existence check, so a failing audit still exits non-zero.
• This PR touches scripts/audit.sh, so the Weekly audit workflow runs on it — that run is the real test of the new output.

Closes #4 once green.

---

Generated by Claude Code