Release path

From you

nothing

Two keys: documented process, not code-enforced

The rule: RELEASE-GO <tag> <main sha7> from both Jean and Brick on the Release issue, Brick also approves the release PR, a new commit needs new GOs. docs/operations/release-process.md line 48; CLAUDE.md line 191.
A repo-wide grep for RELEASE-GO at HEAD hits only those two lines. Nothing under .github/workflows or app/scripts reads it, and the Release issue form (.github/ISSUE_TEMPLATE/release.yml) has no RELEASE-GO field.
What a machine does check on the release PR: PR Validate Gate (pr-validate.yml 588 to 649), Release source guard (release-source.yml 25 to 52) and 1 approval on main (release-process.md 151). --admin bypasses the approval and never consults the contexts (CLAUDE.md 195 to 201).
Both the Jean and Brick apps sit on the Release tags (v*) bypass list, so either can publish a release alone (release-process.md 48 and 149).

What code enforces on the way to production

release.yml 76 to 81: the tag must match vYYYY.MM.DD[.N], the GitHub Release must exist and be neither draft nor prerelease.
release.yml 69 to 71 and 93 to 103: the sha is pinned at publish time so a moved tag cannot change what ships, and the commit must be an ancestor of origin/main.
release.yml 105 to 163: the production deployment is created by the Vercel API from that sha, polled to READY, then the production target is asserted or promoted; the token comes from the production environment secret.
jobs-deploy.yml 53 to 59 and profile-crop-worker-deploy.yml 37 to 43: image builds refuse a commit not on main. terraform.yml 327 to 329: apply runs only on release or a dispatch from main.
release-source.yml 49 to 52: a PR into main fails if app/vercel.json loses git.deploymentEnabled.main = false, the switch that keeps a main push from deploying (app/vercel.json 3 to 7).

Migrations: before publishing, on the signed path

release.yml 24 to 27: the release workflow applies no migration; its run summary lists the .sql files added since the previous v* tag (165 to 194).
prod-migrate.yml 36 to 85: runs only on main, refuses a PROD_DATABASE_URL that is not the prod Neon host, needs a JSON array of at least two raw signed events, runs db:migrate:prod:ci --approval (app/package.json 34), then audits the apply records.
verifyMigrationApproval (app/scripts/lib/nostr-approval.ts 237) needs two NEON-APPROVE signatures over each file's sha256 from two different non-authors: Jean plus Brick, or one of them plus Sherlock or Nick. The signature rules and the approve reply are drawn in the migration-gate workflow diagram (workflow-migration-gate); they are not redrawn here.
Migrations never roll back; write a forward fix (release-process.md 135).

Beta, back-merge and the hotfix lane

develop is the default branch; every push deploys the Vercel beta custom environment at tortterminal-dev.com (release-process.md 19, beta-environment.md 10). beta-migrate.yml and beta-reset.yml apply develop's migrations to the Neon beta branch, which is not drawn.
backmerge.yml 34 to 55 runs on every main push and fails when develop lacks non-merge commits from main; it prints the back-merge commands but never opens the PR, because letting Actions create PRs would also let any workflow approve them (lines 8 to 10).
Hotfix: branch from main, PR into main, squash on green, publish a release, then back-merge main into develop with a merge commit (release-process.md 84 to 87). release-source.yml 58 to 84 refuses a hotfix that adds a migration while develop holds unreleased ones.
The Sequence schema has no alt or opt fragments; the hotfix path is drawn as its own segment band after the main path.

Left out, and why

llm-key-rotate.yml is a workflow_dispatch utility that pushes a new Secret Manager version of llm-api-key (lines 1 to 18); it is not on the release path and is not drawn.
release-source.yml is on the path (required check on main, release-process.md 23) and is drawn at the release PR step.
ui-review.yml runs on PRs into develop only (lines 15 to 18); release PRs into main carry no UI Review context (lines 10 to 11).
Vercel team and project ids sit in release.yml env (46 to 48); this diagram names them only as the Vercel project.
Rollback: Vercel Instant Rollback for the app alone, release.yml workflow_dispatch with an older published tag for everything, image workflows re-run from that tag (release-process.md 131 to 135).