## What
The release snapshot check
(`scripts/release_control/release_snapshot.py`)
now also accepts dispatches from `release-dispatch/<packet>` refs. Such
a
dispatch must name a merged PR whose head is
`release-candidate/<packet>` at
the dispatched commit. The other checks are unchanged: closed and
merged,
head SHA equals `GITHUB_SHA` and `GITHUB_WORKFLOW_SHA`, base is the
requested
source line, canonical repository, and both merge ancestry checks.
`release-candidate/*` dispatches keep working exactly as before.
## Why
Release, signing and registry secrets are repository-level today, so a
workflow run on any branch can read them. The planned fix moves them
into a
`release` environment that admits only `main` and post-merge dispatch
refs.
`release-candidate/*` cannot be that ref, because unmerged release PR
heads
live under the same name. This check has to accept the new namespace
first,
and every snapshot cut after this merges will carry it, before the host
dispatcher switches over.
This validates identity only. Restricting who can create or move
`release-dispatch/*` refs is a separate repository ruleset; the contract
in
`deployment-installability.md` says the namespace carries no extra trust
until that ruleset is active.
## Validation
- `release_snapshot_test.py`: 7/7, including new cases for the dispatch
mapping, rejected head names (`release-candidate/other`,
`release-dispatch/*`, `maintainer/*`), malformed dispatch names and
unbound inputs, plus the end-to-end `main()` path for both namespaces.
- Mutation checks, each failing the tests: dispatch ref not mapped to
its
candidate head; slashes admitted in dispatch names; dispatch ref not
admitted by `source_branch`.
- `release_promotion_policy_test.py` behaves identically with and
without
the change on the same partial tree; CI runs it in full.
rcourtman
e2545bd34b