[ViperJuice]

.github/workflows/release.yml triggers only on tag push — the tag push is
the publish (build → PyPI trusted publishing → GitHub release from a CHANGELOG
awk extraction). It therefore never appears in a PR check, and every guard that
protected #188's change to it was run by hand, once. The next PR touching it
inherited none of them, on the one file where a mistake is invisible until a
release breaks.

The nastiest known mutant is silent: change the tag pattern "v*" to "V*" and
the workflow stays valid, passes actionlint, and simply never runs at tag push.
There is no red X anywhere; a version just sits tagged-but-unshipped.

Two new test.yml jobs, plus scripts/check_workflows.py.

Checked by invariant — scripts/check_workflows.py

On the parsed release.yml, whatever the diff looks like:

• the file exists at all (outright deletion of the release path);
• on.push.tags is exactly ["v*"];
• publish needs build, github-release needs publish (both scalar and
  list forms of needs: accepted — the file uses the scalar);
• publish has environment: release by name. environment: dev passes a
  presence check and ships, because GitHub auto-creates unprotected
  environments;
• no if: and no continue-on-error on publish/github-release, at job
  level and on every step within them. The job-level rule alone is bypassed
  one level down: continue-on-error: true on the "Publish to PyPI" step makes
  a tag push report green while the upload failed;
• permissions: equals the committed map exactly at both levels — job-level
  and workflow-level (absent). Checking only the job level is a concrete bypass:
  a workflow-level permissions: write-all leaves every job map untouched while
  widening build;
• every uses: equals the committed reference exactly, so the publish action
  cannot be repointed at a fork;
• the job set is exactly {build, publish, github-release} — an added job with
  the release environment in scope is statically decidable, so it fails here.

And across every workflow file (both .yml and .yaml): each job carries a
timeout-minutes that is an int, not a bool, in 10..30. A floor with no
ceiling reopens #187 — timeout-minutes: 360 is valid, preserves the job set,
and re-creates the six-hour default that issue exists to fix.

Checked by drift

For each changed path under .github/workflows/ (from
git diff --no-renames --diff-filter=ACMRD <base>...HEAD, which includes
deletions — a worktree glob cannot see a file that is gone), the base job set
is compared against the head's, and any job that disappeared fails. A rename is
a removal plus an addition. A deleted file has an empty job set and is
reported, naming every job removed, rather than raising. A genuinely new
workflow file has no base version and passes.

Drift fails closed on a base that does not resolve — a shallow clone, a bad
ref, a failed fetch. Treating that the same as "the file is new" would exit 0
with all drift protection silently disabled. The base is resolved per event:
github.event.pull_request.base.sha on pull_request, github.event.before on
push, none on schedule/workflow_dispatch (invariants only, and the log
says so). github.event.before is a PushEvent field and is unset on
pull_request; wiring only that would have skipped drift on every PR.

Checked by acknowledgement

check_workflows.py is an allowlist — it catches bad states it knows how to
name. release-diff-ack is the tripwire for the remainder: any PR whose diff
touches release.yml fails unless it carries a release-change-approved label.
Labels are read live from the API, not from
github.event.pull_request.labels, because that context is frozen at trigger
time and a re-run replays the frozen payload — so "apply the label, then re-run"
actually works. It mirrors the existing changelog/skip-changelog job,
including branching on the lookup's exit status rather than on emptiness.

Explicitly NOT covered

• A timeout above the floor but below a job's real p100 (e.g. build
  20 → 12). Not statically decidable. This is the one uncovered mutant, and it
  is in the mutation matrix with its real green exit code rather than omitted.
• Environment protection rules, which are configured in GitHub settings and
  invisible to any file check. gh api says the release environment has
  "protection_rules": [] today, so the environment: release invariant guards
  a name, not a gate.
• if:-skipping the guard job itself. GitHub counts a skipped job as
  satisfying a required check, so if: false on workflows merges green as
  far as branch protection is concerned. actionlint catches the literal form and
  not the equivalent non-constant one; the test job's assertions catch both,
  unless the same PR disables that job too.
• Related: the guard runs from the PR branch, so a PR can keep the job name
  while gutting its steps. .github/CODEOWNERS is the only backstop for these,
  and required_pull_request_reviews is null today, so it gates nothing.
• SHA-pinning pypa/gh-action-pypi-publish (currently the mutable
  @release/v1). The uses: invariant makes a change to it fail; it does not
  make it safe. Worth doing, needs its own issue.

Evidence

.consiliency/evidence/mutation-189.md. 30 mutants from
scripts/_mutate_workflow.sh, which is the single source of the set — the
loop consumes --list verbatim and a test asserts the suite exercises nothing
outside it. Mutants are committed on a scratch branch, because drift's
three-dot diff only ever sees committed changes; mutating the working tree makes
drift a silent no-op while the invariants cover for it.

• 25 of 25 killed, each by the check meant to kill it (asserted on the reported
  reason, not just the exit code).
• Drift shown load-bearing by stubbing job_set_drift to return []:
  maintenance-deleted, changelog-job-deleted and workflows-job-deleted all
  go green, because the release and timeout invariants only see files that
  survived.
• The 5 expected-green cases are named individually with real exit codes.
• actionlint 1.7.12 — the only static gate the repo had before — killed 4 of 30,
  all schema-class, and none of the ones that leave a workflow both valid and
  silent. It is pinned by archive digest (asserted before extraction) and kept
  for schema validation only.
• release-diff-ack proven in all three directions (plus label-applied-then-rerun,
  lookup-failure fallback, and label-removed), as a local simulation of the
  shipped step body. Only the "PR does not touch release.yml" direction is live
  here — this PR does not touch release.yml.

Note for review

The uses: and permissions: allowlists are exact, so a legitimate edit to
release.yml — bumping an action, granting a scope — must update the constants
in scripts/check_workflows.py in the same PR. That is intended: on the one
workflow with no PR-time feedback, a change should be deliberate enough to be
spelled twice.

Not done here, by design: workflows and release-diff-ack still need adding
to required_status_checks.contexts via gh api after this merges. Until
then a PR that deletes the workflows job means the job never runs — drift
cannot fire, because it is what was deleted.

see #189

🤖 Generated with Claude Code

https://claude.ai/code/session_01T61zMNiPF4K29186r3uqc3

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}