Vercel Launch Gate

Three modes. Pick by where the user is:

• GATE — nothing deployed yet. Run the launch gate before anything is pushed to the production branch.
• DOCTOR — a build or deployment already failed, or production is misbehaving. Diagnose root cause first; never guess-fix.
• VERIFY — a deploy just finished. Prove the change is actually live; a green "Ready" state is not proof.

1. No blind redeploys. A retry without a diagnosed root cause and a concrete change is forbidden. Every failed attempt costs quota and teaches nothing.
2. Quota is a budget, not a suggestion. On the Hobby plan, Vercel counts every deployment state toward the daily limit (READY, ERROR and CANCELED all count), and one git push can trigger several projects at once. Batch changes into one deploy window per day whenever possible; cancel redundant queued builds before pushing again.
3. Verify content before merge, verify live after deploy. Read the actual file contents that will be merged (a corrupted merge has burned six deploys in one real incident), and after the deploy, fetch the production site itself — dashboard status alone never proves the change is live.
4. Separate build-time from runtime. A build can pass while production is broken by a missing runtime environment variable. When the symptom is "deployed fine, site broken", check env parity and the app's health endpoint before touching code.
5. Provisioning failures are a stop sign. Repeated platform-side provisioning errors mean stop, diagnose, and wait — not retry harder. Escalating retries during an infra failure only exhausts quota.
6. Never print secrets. Environment variables are checked by name and presence, never by value. Do not echo, log, or commit env values.

Work through references/launch-gate-checklist.md in order. The short version: