Migration gate

From you

nothing

The prod gate, as verifyMigrationApproval enforces it

Every pending file's exact sha256 (CRLF normalised to LF, what was signed is what runs) needs two signatures; one uncovered file refuses the whole run before anything applies (nostr-approval.ts 247-258, run-migrations.js 180-188).
Signature one: a NEON-APPROVE line from Jean or Brick whose name is not among the file's git authors (nostr-approval.ts 249-250).
Signature two: the other of Jean/Brick, or Sherlock or Nick. Two different keys by construction; one agent signing twice is one signer (nostr-approval.ts 251-252).
The signer set is pinned in code, not env: MIGRATION_REVIEWERS (jean, brick) and APPROVER_PUBKEYS (sherlock, nick) in nostr-approval.ts 13-16 and 197-200. Key values are deliberately not reproduced here.
Every event must come from a pinned key, carry a matching NIP-01 id, verify under BIP-340 schnorr and sit within 45 minutes of the verification clock; otherwise it is ignored and named in the refusal (nostr-approval.ts 376-390).
Recorded on the row: approval_mode 'signed', approved_by 'reviewer + approver', sha256 of the applied text (run-migrations.js 304-309 and 493-500).

Authorship and the no-history case

Authors come from git log origin/main on the file: author name and email plus Co-authored-by trailers, matched on jean or brick with an optional -app suffix (run-migrations.js 157-178).
A file with no history on origin/main counts BOTH agents as authors, so no vetter is left and the run is refused. A human signature does not rescue it (test: 'a file with no history on origin/main counts both agents as authors (fail closed)', and the second assertion of 'Jean + Brick is not enough when one of them wrote the file').
The rig's ~/sources/CLAUDE.md remembers this as 'a file with no git history still needs a human co-signer'. The code does not do that: the file is refused until it has history on main. The rig note is what needs fixing.
The Prod migrate workflow checks out main with full history, so origin/main is readable there; on production the runner fails closed when it cannot read that ref (run-migrations.js 421-431).

The one-word 'approve' shortcut

commit 4dda49137, PR #5573

Only Sherlock or Nick. The whole trimmed message must be approve or approved, any case, one optional trailing . or ! (nostr-approval.ts 266 and 293).
It must be a reply in the vetting thread: same root (Buzz 'e' reply tag, or a NIP-10 root marker) and same channel ('h' tag). An unclear thread or an approve that is itself a thread root covers nothing (nostr-approval.ts 308-362).
It covers only Jean/Brick NEON-APPROVE events posted before it and no more than 45 minutes before it, and it never lets an agent vet its own file.
Spec by test name (migration-approval.test.ts 149-295): 'is not a blanket approval' for I don't approve, not approved, approve?, approve!!, @Jean approve; 'a non-human pubkey saying approve covers nothing, pinned agent or not'; 'a reviewer who authored the file still cannot count under a blanket'; 'reads a NIP-10 root marker, and fails closed on an unclear thread'.

Three ways a row gets its record

signed: the Prod migrate workflow, or a local db:migrate:prod with --approval from a checkout of origin/main; approved_by looks like 'jean + nick' (run-migrations.js 307).
operator: a human at a TTY runs db:migrate:prod:operator and types APPLY; no signatures are checked; approved_by is os user @ host; refused until migration 810 exists (run-migrations.js 192-206 and 255-271).
unguarded: the runner did not recognise production (beta, dev branches); approved_by NULL (run-migrations.js 542-547).
NULL approval_mode on a row applied after the 810 row means applied outside the runner (psql, Neon console). The audit fails on that, and on any unguarded row on production (audit-migration-approvals.mjs 19-29).
Migration 810 adds the three columns with CHECK constraints and backfills nothing (810-schema-migrations-apply-record.sql 39-46).

Doc vs code: release-process.md against the runner

Agree: the signer set, the author rule, the 45 minutes, the approve shortcut, the approved_by format and the workflow path all match the code (release-process.md 51-72).
Differs: release-process.md 141 ('Beta and migrations') still says prod needs 'an agent's vetting signature and a human's approval'. The code and the section above it accept Jean + Brick with no human (test: 'Jean + Brick passes when neither wrote the file (no human needed)').
Silent: the doc never says plainly that operator mode applies with no signatures. run-migrations.js 192-206 does. A human holding the owner URL at a terminal is a one-key path; the row says 'operator' and the audit passes it.
Wording: prod-migrate.yml 16 says 'within 45 minutes of the oldest signature'. The code checks each event against the clock at verification time (nostr-approval.ts 380), which comes to the same thing.
release-process.md 53 says 'CI never check[s]'. True of PR Validate; the Prod migrate workflow is CI and does check, because its target is production.

Edges of this gate

RELEASE-GO two-key (Jean and Brick on the Release issue) gates the release itself, not the migration apply. It is a separate diagram.
The gate protects the sanctioned path only. Anyone holding the owner DATABASE_URL can run DDL with psql (run-migrations.js 189-190, release-process.md 64). The audit is the detector after the fact.
isProductionDatabase pins one Neon endpoint id. If production moves, the runner goes quiet (unguarded) rather than loud, and the audit's --target production flag is what catches it (production-database.js 19-28, audit-migration-approvals.mjs 14-29).
PR Validate does not run the approval audit on purpose: CI holds no prod credentials (audit-migration-approvals.mjs 43-45). Beta applies through the same runner with no gate at all.
Not shown: release-source.yml also fails a hotfix that adds a migration while develop holds unreleased ones (release-process.md 23).

Tests as the spec

app/scripts/__tests__/migration-approval.test.ts

Passes: 'Jean + Nick passes, one event each covering every file'; 'Brick + Sherlock passes, one event per file per signer, any order'; 'Jean + Brick passes when neither wrote the file (no human needed)'.
Refusals: 'Jean + Brick is not enough when one of them wrote the file'; 'one agent signing twice is one signer'; 'refuses human-only'; 'refuses a reviewer who authored the file, and names who signed'; 'refuses the whole run when one file is partly covered'; 'refuses unpinned keys, and the defaults are the real pinned keys'.
Event hygiene: 'rejects a stale human / stale agent / edited content / forged sig / not an event'; 'a hash must end at 64 hex: a longer string approves nothing'.
Hashing: 'hashes a migration as git stores it, so a CRLF checkout matches git show | sha256sum'.