[Audit GAP-02] CI workflows still gate on `master` while the branch policy is `stable` / `dev`

[mberrys]

Problem

CI is not gating the branches the project actually uses. Verified in-tree:

• .github/workflows/ci.yml lines 4-8 — push.branches: [master], pull_request.branches: [master]
• .github/workflows/codeql.yml lines 16-18 — branches: [ "master" ]

The active development line is dev and the release line is stable. No workflow triggers on either. Every practice the CI file gets right — SHA-pinned actions, supply-chain pin verification, pinned vcpkg baseline, Ubuntu + Windows builds, ctest, the preflight corpus gate, the consolidated ci_ok status — is currently applied to a branch that carries no work.

This is a release-governance failure, not a naming nit: until it is fixed, no CI result can be cited as evidence that dev or stable is green, which undermines the #197 exit gate.

Scope

1. Make the branch strategy explicit in docs/ (stable = release, dev = integration, short-lived topic branches off dev, or whatever policy is actually intended).
2. Update ci.yml and codeql.yml triggers to that policy.
3. Keep dev as a usable, nonblocking integration branch. Protect stable with one GitHub-hosted, always-reporting aggregate release gate; do not require the full release matrix on dev.
4. Add a drift guard: a test or CI step that parses the workflow trigger lists and fails when they no longer match the documented policy. A stale trigger must break the build rather than silently stop gating.

Acceptance criteria

• ci.yml and codeql.yml trigger on the documented branches; no workflow references master unless master is part of the documented policy.
• stable requires exactly one GitHub-hosted, always-reporting aggregate release context; dev remains nonblocking during release recovery.
• The drift guard fails when a workflow trigger is edited away from the documented policy — asserted by a test that deliberately mismatches them.
• Branch policy is documented in-repo, in the repository.

Dependencies

• Blocks trusting CI as release evidence for [0.2.0] Qualify one exact release candidate and publish the evidence dossier #264, which supersedes Complete release validation and the Loupe 0.0.1 exit gate #197 for 0.0.2.
• Related: Pin actions, vcpkg revisions, packaging tools, and downloaded binaries with checksum verification #17 (supply-chain pinning) — same workflow, different concern.

---

Alignment amendment — 2026-08-10

The former requirement to make ci_ok block both dev and stable is superseded. The corrected contract is:

• dev is the nonblocking integration branch.
• stable is pull-request-only and requires one GitHub-hosted, always-reporting aggregate release gate.
• Failed, cancelled, skipped, and missing dependencies must reduce to an explicit terminal failure.
• pull_request and merge_group must both produce the required context when enabled.

PR #248 is an implementation candidate. Validate live branch protection, trigger drift, and missing/skipped/cancelled reduction before closing. Follow-up: #261.