fix(release): releases were disabled by the mirror-era guard; plus the leak-gate bootstrap (F.1, C.3)

[wshallwshall]

Two cutover-completion items. Read the first one — it means no release could ship.

---

1. Releases were disabled entirely (runbook F.1)

Both jobs in release.yml were gated:

if: github.repository != 'MEFORORG/MessageFoundry'

Correct when this repo was the published mirror — the mirror must never release, and publish.ps1 rewrote the private slug to the public one across *.yml, so != public-slug was the only rewrite-proof form.

Both premises died at the cutover. publish.ps1 is retired, and MEFORORG is now the source. Left inverted, the guard skips the release on the only repo that can publish — PyPI Trusted Publishing is bound to MEFORORG/MessageFoundry + release.yml (see the release.yml header, and F.1's owner prereq). The job guard and the OIDC binding pointed in opposite directions: a pushed v* tag would have silently skipped and shipped nothing.

Nobody noticed because no tag has been cut since the cutover. F.1 — "validate the release under the new OIDC binding" — is precisely the step that would have caught it.

Every other slug guard (ci.yml, codeql.yml, quality-advisory.yml, scorecard.yml) was already flipped to == at the cutover. release.yml was missed. == is also the safe form now: a fork, or the retired vault, still cannot release.

The test was pinning the bug

tests/test_release_pipeline.py asserted the inverted guard appeared at least twice, with a comment explaining the publish.ps1 rewrite. It was right for the old topology and outlived it — so the broken state looked deliberate and was enforced. Rewritten to assert the post-cutover invariant, reject the old form explicitly, and state plainly that it used to assert the opposite. Mutation-verified: restoring the inversion fails it.

F.1 is still open. Cutting vX.Y.Z-rc1 publishes to production PyPI — an owner action, not something to slip into a PR.

---

2. The leak-gate bootstrap (runbook C.3)

forbidden-content passes --require-tokens and fails closed — correct, since without it the gate loads zero detectors and passes every commit green. The flag stays. But the token list is git-ignored, so it doesn't travel with a clone or git worktree add, and the setup step was documented only inside a file you had to already know to open. CONTRIBUTING.md mentioned neither pre-commit nor the token file.

Outside contributors were permanently blocked — they can never have the real list, making the hook stricter than both CI (which branches to structural-only for fork PRs) and the scanner's own default. The supported answer is to copy the synthetic template.

Which creates the hazard this actually closes

The synthetic example populates every section, so it clears the count floor while matching nothing real. A maintainer who copied it instead of installing the real list gets a green gate that is blind — and no count could tell. So the scanner now recognises its own template and labels the run:

loaded names=7, estate=13, estate_file_scanned=12, site_prefixes=1
loaded names=5, estate=3,  ...  [SYNTHETIC EXAMPLE TOKENS — blind to real customer tokens; CI is authoritative]
loaded names=0, estate=0,  ...  [STRUCTURAL-ONLY: no token source configured]

Three states that exit 0 collapses into one. Only the first is evidence. Compared on parsed content, not bytes, so adding a comment can't silently reclassify a synthetic set as real — the direction that fails open.

File	Change
scripts/dev/setup-leak-gate.ps1	new. -From <path> (maintainers) / -Synthetic (contributors). Always ends by running the scanner and printing per-section counts, exiting non-zero if nothing loaded. Verifies the destination is git-ignored, deleting it rather than risk committing the token list.
CONTRIBUTING.md	A Leak gate section: why it fails closed, both paths, how to read the three modes.
scripts/worktree/new.ps1	Carries the token file into a new worktree, or says plainly that commits will fail closed.
scan-tokens.local.txt.example	States it's a supported contributor setup, that it's labelled on every run, and that its counts are below CI's floor — so passing locally doesn't predict CI.

Four tests, mutation-verified; the negative controls matter because "no source" and "the example" are different failures with different fixes.

C.3's ordering hazard is separately resolved and I've marked it done in the runbook: install-git-hooks.ps1 no longer writes .git/hooks/pre-commit at all (PR #4 moved the ledger gate into .pre-commit-config.yaml), so it can't collide with pre-commit install and order no longer matters.

---

Not fixed here, deliberately

The pre-commit ruff/bandit hooks scan directories CI does not — scripts/ (1 ruff finding), harness/ (74), tee/ (12), plus pre-existing bandit findings. Touching any file there blocks your commit on errors you didn't cause, invisibly to CI. I started on the one-line UP017 in vuln_metrics.py and reverted it: editing that file pulled in four unrelated bandit findings to annotate. That needs one decision — clean the dirs and add them to CI's scope, or narrow the hooks to match CI — not a drive-by under a release fix.

🤖 Generated with Claude Code