feat(check): add ci-bash-suites validator — close the gate-divergence gap

[Data-Wise]

The gap

/craft:check never ran the shell suites CI invokes directly, because pytest doesn't collect
them. The local gate and CI measured different things — and the local one reported a
comfortable green for a surface it never touched.

This is the root cause behind two of the three CI blockers the v4 branch carried (PR #290).
T3.5.2 deleted commands/git/ and cited "full pytest 2575 passed" as its verification
evidence. That was true and irrelevant: tests/test_git_shim_correctness.sh — a CI-required
check — asserted those exact files still existed. It had been red for days. Nothing local ever
said so; CI rejected the PR.

The general failure is gate divergence: CI runs checks the local gate doesn't.

Approach

A new hot-reload validator, not a change to check.md. /craft:check already discovers
.claude-plugin/skills/validation/*.md and forks each with CRAFT_MODE, so no existing logic is
disturbed — this plugs into the extension point that already exists.

The suite list is derived from .github/workflows/*.yml, not hardcoded. That's the whole
point:

• craft has 22 tests/*.sh but CI runs 6. Running all 22 would invent a gate CI never
  asked for and fail on deliberately-manual suites.
• A hardcoded list is the exact drift this validator exists to prevent. Add a suite to a
  workflow and it's picked up on the next run, no edit here.
• Non-test scripts (scripts/docs-staleness-check.sh, scripts/aggregator-sync.sh) are
  excluded — build steps, or they have their own validators.

This generalises: any repo whose CI shells out to test suites gets the same protection, matching
how test-coverage.md detects python/node/R/go rather than hardcoding one.

Modes

Follows the documented release-gated contract (same as version-check, skill-standards):

CRAFT_MODE	On a failing suite
default (--for commit / --for pr)	Advisory — reports loudly, exits 0
release (--for deploy)	Blocking — exits 1

Advisory-in-default is deliberate. check.md states validators receive their tier only via
CRAFT_MODE, which resolves to default for both --for commit and --for pr — so blocking
at that tier would block every commit on a ~3–5 min run. Advisory is enough to have caught
T3.5.2: the failure becomes visible at check time instead of at PR rejection.

Test evidence — planted defects, not just a green run

The decisive one replays the real historical bug: I restored the pre-fix
test_git_shim_correctness.sh from d41de18ee (the version that sat red for days behind a green
pytest) and confirmed the validator catches it.

replay the REAL T3.5.2 bug (pre-fix suite from d41de18ee)
    → ❌ tests/test_git_shim_correctness.sh (exit 1)
      ⚠️  WARN: 1/6 CI bash suites failing (default mode — advisory)
    → CRAFT_MODE=release: ❌ FAIL: 1/6 CI bash suites failing (release mode — blocking), exit 1

suite exits 1                        → caught; default-mode exit 0 (advisory, correct)
workflow references a missing suite  → caught: "referenced by a workflow but not found on disk"
                                       + remediation note (CI would hard-fail here)
repo with no .github/workflows       → clean SKIP, exit 0 (generic-repo safe)
clean baseline before and after      → 6/6 green

Discovery verified exact: finds CI's 6 suites (test_branch_guard, test_branch_guard_e2e,
test_no_switch_guard, test_git_shim_correctness, test_bump_version,
test_post_release_sweep), excludes the 2 non-test scripts and the 16 manual-only suites.

Note this caught something I had wrong: I'd been tracking 4 CI bash suites all along. Parsing
the workflows found 6 — there's a second step at ci.yml:194–195 running the release-pipeline
suites. Deriving from CI beats trusting a list, which is the point of the design.

Other gates:

python3 -m pytest tests/    → 2601 passed, 1 failed, 43 skipped, 1 xfailed, 1 xpassed
./scripts/validate-counts.sh → exit 0 (47/40/2 — no count cascade; validators sit
                               outside the counted surface)
markdownlint                 → 0 errors
bash -n (validator body)     → syntax OK
leak scan                    → clean

The 1 pytest failure is test_branch_guard_dogfood.py::TestHookInstallation::test_repo_copy_matches_installed
— pre-existing on dev, unrelated to this PR (verified: it fails identically on a clean dev
checkout with no validator present). Cause: PR #290 merged the v4 hook text into dev, so the
locally-installed ~/.claude/hooks/branch-guard.sh now predates the repo copy. CI runs
install-guards.sh at ci.yml:151 before the suites, so CI syncs them. Locally it's fixed by
re-running install-guards.sh — deliberately not done here, as that's global machine state.

🤖 Generated with Claude Code