Deploy and release

Purpose and authority

This governs source-to-release handoff. Local checks, CI, merge, deployment, migration application, and live/provider verification are distinct states. Merge, deploy, migration, provider, and outgoing-message authority are also distinct. Use the exact remote head, not a stale checkout.

Release procedure

1. Refresh origin/main and record exact SHA plus code, migration, configuration, and documentation changes in scope.
2. Run required local checks and inspect CI for the same head; a green check proves only its own scope.
3. Obtain exact-head review, including security/migration review for data-access changes.
4. Merge through the approved path and confirm the merged SHA separately from a pushed branch.
5. Deploy through the approved Vercel workflow. If needed, inspect linked migration history and apply only approved migrations.
6. Verify the affected route/function safely in the target environment. Email, webhooks, analytics, and provider effects need their own observed evidence.
7. Record SHA, checks, review, merge, deployment, migration state, and live/provider verification separately.

Rollback and escalation

Use approved platform rollback/redeploy controls for a bad deployment and preserve evidence. Database rollback needs a reviewed recovery plan; never run destructive commands. Stop for migration-history mismatch, unexpected production data, auth/RLS regression, or unapproved provider/email action.