[wz-gsa]

What

Fixes a required-status-check deadlock in this repo's CI: .github/workflows/bash32-compat.yml's job (the one backing the required check acq offline suite under bash 3.2) had a workflow-level paths: filter. When a PR's diff doesn't touch those paths, GitHub creates no check-run at all for that context — not a passing "skipped" status, nothing. Branch protection then waits forever for a context that structurally can never post, and the PR sits mergeStateStatus: BLOCKED even though every check that actually ran is green.

This is a real, reproduced problem, not theoretical: it blocked #449 (a routine dependabot actions-version bump touching only .github/workflows/release.yml) and required an admin-bypass merge to get past.

Why this shape

This is GitHub's own documented failure mode ("Handling skipped but required checks" in their required-status-checks troubleshooting docs), and the fix is their documented mitigation — a 3-job "gate" pattern:

1. changes — cheap job, computes relevance via git diff --name-only against the PR base. Same technique this repo's own markdown-quality.yml link-check job already uses, so no new marketplace action. Fails closed: any error computing the diff is a job failure, never a silent "not relevant."
2. test-acq-bash32 — the real, expensive job (builds bash 3.2.57 from source, runs the offline suite). Now conditional on changes reporting relevant. Renamed (was the required-check name; see below) to avoid two jobs racing to post the same status-check context.
3. gate — always-runs (if: always()), and is what branch protection actually requires — under the same required-check name the single job used before (acq offline suite under bash 3.2). Keeping the name unchanged means this PR needs no out-of-band branch-protection/ruleset update — a subtlety a couple of the review panel's voters specifically flagged as worth optimizing for, since a ruleset edit is live GitHub state, not reviewable in a PR diff.

The gate is fail-closed on both upstream jobs, not just the expensive one — this was the single most-repeated correctness note across the review panel:

if [ "$CHANGES_RESULT" != "success" ]; then
  exit 1   # a failure in relevance-detection must not be laundered into a pass
fi
case "$TEST_RESULT" in
  success|skipped) : ;;   # skipped is the correct, expected outcome for irrelevant diffs
  *) exit 1 ;;             # failure/cancelled always fails the gate
esac

Without that changes-result check, a broken diff-computation step would cause the expensive job to be silently skipped (because its if: condition can't evaluate true), and a naive gate would report that skip as green — quietly disabling the bash 3.2 regression-catcher while showing a passing required check. That's strictly worse than today's loud deadlock.

Process

Ran this through a 7-role nexus-agents consensus panel before implementing (architect/security/devex/pm/catfish approved; scope_steward rejected on cost-justification grounds, arguing simply dropping the paths: filter — with no gate job — would already unblock merges today, and challenging the "prevents future path-filtered required checks" framing as speculative). I adopted the gate-job design anyway because a bare needs-dependent job with no gate can still launder a failed dependency into a passing required check (GitHub's own docs flag this as "may not block merging" — not a hard guarantee either way), and this repo already has exactly one other required-conditional-check candidate shape worth getting right once. I did fold in the panel's fail-closed correctness fix (checking changes's own result, not just the expensive job's) rather than shipping the simpler two-state version most voters initially reviewed.

Independently reproduced/verified before pushing, not just read from docs:

• actionlint clean on the whole workflow.
• git diff --name-only relevance logic tested against two real commits in a scratch clone (workflow-only change → empty diff → relevant=false; acq.backends/msb.sh change → non-empty diff → relevant=true).
• Gate shell logic exercised directly against all 5 (changes result, test result) combinations — passes only on (success, success) and (success, skipped), fails on every other combination including the failure-laundering case (failure, skipped).

Docs

Added Known Failure Mode #41 documenting the deadlock, root cause, and the prevention rule ("any workflow backing a required check must have no trigger-level path filter, or must follow this gate-job pattern") so a future required-check addition doesn't reintroduce the same class of bug.

AI-assisted (OpenCode); disclosed per this repo's AGENTS.md PR-level attribution policy.