Help the agent take an app live on accounts the human owns. The golive script handles supported\nprovider operations after approval and records what its checks establish. The human connects\naccounts and handles purchases; app migrations, business flows and guided steps need their own\nreview. Never turn an infrastructure check into a claim that the entire app works.
node <this-skill-dir>/scripts/golive.mjs <command> --json\n<this-skill-dir> is the folder containing this SKILL.md. Every command prints one JSON document.\nExit code 2 means \"worked, but something needs attention\": read the JSON.
At the start of a new deployment run, run version --json and update-check --json using the\nscript above. The runtime verifies the complete instruction/reference/script bundle before\naccessing accounts. Update checking reads only public metadata, is cached and bounded, and an\noffline/unavailable result does not block the deployment flow. GOLIVE_UPDATE_CHECK=0 disables it.\nRead references/updates.md for installation ownership, explicit updates, rollback and opt-in\nautomatic replacement. Automatic replacement is off by default and only runs between deployment\nruns for copies owned by our installer. Skills CLI and plugin copies stay with their managers.\nNever update between a plan and its apply. A changed release requires a new plan and human approval.
golive.yaml, non-secret .golive/state.json, and\nlatest golive plan/result first. Resume the current stage; don't restart onboarding or treat a\nquestion as approval. Credentials, .env, and vendor login files are never context to read.docs/GOLIVE-<stage>-PLAN.md and\ndocs/GOLIVE-<stage>-RESULT.md; link them in chat. The CLI's final report is GOLIVE_REPORT.md.\nPreserve older artifacts as evidence and say which current document supersedes them.cat, or paste a secret value (.env files, API keys, tokens, database\nURLs, ~/.config/golive/credentials). Refer to secrets by name. The script never prints them.pk_test_…, pk_live_…) are public, so the human may give them in\nchat. Never sk_, rk_ or whsec_.init, and report files can be prepared during onboarding. Explain plan and get a\nclear yes before apply. Pass --confirm-live (live payments, production data, or a first\nproduction deploy — the first write to a destination golive has never deployed; e.g. the\nauth:test-user account, the auth:isolation second account, auth-signup's throwaway probe and\nthe auth:recovery password rotation), --confirm-dns (DNS records) or\n--confirm-destroy (deletions) only if the human explicitly approved those categories. Say why\nyou are asking each one: steps[].needs names the flags a step requires, and a first production\ndeploy needs --confirm-live because approving the plan approves what that deploy contains, not\nthe first write to production itself. Later deploys of that target need no extra flag.done: false is\nopen. done: null (a manual item, or its check skipped) cannot be verified by golive: confirm it\nwith the human and name it as not verified by golive in your final summary. A skipped check's\nevidence names the recorded outcome of the step it verifies when state has one, so a done: null\nitem never contradicts .golive/state.json: if the evidence says the step is recorded done, the\nwork ran and only this invocation could not re-check it — say that, not that it is unproven.golive runs in your shell, so a token the human exports in their own terminal never reaches it.\nIn order of preference:
vercel login, supabase login, resend login). The human runs\nit in a separate terminal window (the Terminal app or their IDE's terminal), not with Claude\nCode's ! prefix: ! runs commands without a terminal (no TTY, stdin is /dev/null), so these\ninteractive logins fail or hang there. A real user-controlled terminal can be opened for them\nwhen the host supports it; the human completes the login. Check the CLI is on PATH after install.\nA working CLI login does not prove golive's fallback implements every required operation.\nNothing is copied. Never suggest a --token / --key login flag, even when a CLI's error hint\ndoes: it puts the secret on the command line (and, with !, into this chat).\nIf macOS Keychain or the vendor login requests system authentication, explain which app is\nrequesting access and why; the human responds to that system-controlled prompt. Name the buttons:\n\"Allow\" answers that one read (the dialog returns next time), \"Always Allow\" records the permission\npermanently for that item. Golive's Supabase read is a read-only security helper and never\nchanges the Keychain; if the dialog goes unanswered, say that the CLI-covered reads keep working\nand the rest is a handoff, then re-run so the human can answer it. Never collect\ntheir Mac login password yourself or imitate an OS authorization prompt.credentials --prompt NAME --lang en --json (use zh when appropriate).\nPass only the variable name, never its value. The human types or pastes directly into the native\ndialog. Do not inspect the dialog, clipboard, credential file or raw child output to retrieve it.\nThis is local API-key entry, not a request for their Mac password. Storage remains the private\nplaintext credentials file, not Keychain. The dialog states the path and purpose.\nsaved means local storage succeeded; rerun the provider check to validate access. If a named\nentry already exists, confirm it is the intended one to replace before using --replace.\nIf cleanupRequired is true, treat a saved key as saved and repair only local cleanup; do not\nprompt for it again or retry replacement. See references/troubleshooting.md for the recovery.\nA cancellation means stop and wait; do not reopen the prompt or switch entry methods unasked.\nIf envOverride is true, explain the existing process environment takes precedence; do not\nprint its value or repeatedly replace the file entry. Use the manual fallback only when the\nplatform/dialog is unavailable or the human prefers it, and explain the reason. Filesystem or\nconcurrent-change failures need repair first; follow references/troubleshooting.md.~/.config/golive/credentials (path shown by doctor).\nFirst run credentials --setup --json yourself: it creates a private empty file and missing\ndirectories, preserves existing contents, and returns metadata only. Never inspect those contents.\nGive the human the exact variable name, token page, resource scope and permissions for this stage\nbefore they open their own editor and add NAME=value. If suggesting nano, always spell out\nCtrl+O → Enter → Ctrl+X (save, confirm filename, exit). The agent never enters token values.\nOn Windows the setup command reports privacy as unknown; don't claim POSIX modes verify Windows ACLs.Removing a stored credential. credentials --remove NAME --yes deletes that one entry and returns\nmetadata only (removed: false when the name was not stored — the file is left unchanged, and that is\nnot an error). Every other entry, comment, blank line and line ending survives. --yes is required\nbecause the deletion is irreversible for a human who no longer holds the value anywhere else: pass it\nonly when the human asked to remove that specific credential — never to tidy up on your own initiative,\nand never for a name they did not name. Removing golive's copy does not end access; revoking the token\nat the provider does.
Vercel deploys always run through the Vercel CLI, so it must be installed (npm i -g vercel) either\nway; VERCEL_TOKEN only replaces vercel login. Use doctor's howToFix to preserve the correct\nlogin, variable and permissions, but present only the applicable entry method in the human's language;\ndo not recite editor setup when the native prompt is available. A login it\nshows as ! <cmd> goes in a separate terminal window too. Supabase can reuse a supported CLI\nproduction-profile login for the complete Management API flow, including new projects and Auth\nsettings: read references/supabase.md for the CLI version and OS credential-store limits. An\nexplicit SUPABASE_ACCESS_TOKEN still takes precedence; a rejected explicit token never silently\nswitches accounts through CLI fallback. Request a manual token only when needed by the supported\ncredential path, and explain why. Do not make users do both login and token setup unnecessarily.
Netlify can reuse netlify login for deployment and API env wiring; Neon can reuse neon auth\nthrough its CLI API transport. Read references/netlify.md / references/neon.md when selected.\nDo not require MCP installation: these adapters use vendor CLI/API paths. Netlify + Neon passed a\nsupervised throwaway live run covering provisioning, env wiring, deployment and DB connectivity,\nplus separately approved schema/API/browser acceptance. This does not validate every framework,\npairing or an Auth provider; explain the applicable limits when presenting the stack.
When a setup command fails, help resolve that specific failure before continuing. Keep the app\ndirectory, chosen stack, approved plan and completed resource IDs; onboarding does not restart.\nAn install success is not proof that the user's terminal or the agent can find the executable.\nFor command not found, installation/PATH/version differences, failed login or an interrupted\nprovider operation, read references/troubleshooting.md. Use narrow diagnostics that cannot expose\ncredentials, verify the repair with the appropriate CLI/account check, and return to the same\ndeployment stage. Explain what failed / what now passes / the next deployment step. A repaired\ncommand does not authorize new destinations, paid operations or a changed plan.
detect --jsonTell the human the framework, the providers the code already uses, and the env var names it\nexpects. Fix every critical finding in the code first (e.g. secret-in-client-env: a server\nsecret in a browser-exposed name; config-inlines-all-env: the framework config inlines every env\nvar into the browser). Until they are gone, golive won't write server secrets to that app's host.\nRead notes too (webhook events not found, a define golive couldn't resolve, …).
menu --json, then initAsk only about pieces the app needs and doesn't have yet. List what's already in the repo\nfirst and preserve those choices unless the human requests a change. Offer compatible providers,\nmark \"automated\" vs \"guided\", and include Other — tell me the provider (guided, best effort).\nFor example, an app already using Supabase can keep it while choosing Vercel, Netlify or another\ncompatible host; this does not imply an existing Supabase cloud project or a tested cross-pairing.\nExplain relevant framework limitations before presenting a provider as compatible. If they say\n\"you pick\", suggest the option with the fewest new accounts and say why in one line.\nFor Other, use the menu's provider id when listed, or a lowercase letters/digits/hyphens id for an\nunlisted provider (for example, hosting=example-host), never the placeholder other. An accepted\nid records the choice; it does not add an adapter or guarantee deployment. Read\nreferences/guided.md: check current official documentation, prefer a suitable official CLI,\nconsider an available official MCP or API when safe, then guide dashboard steps. No MCP install is\nrequired. Stop with a concrete blocker when no safe documented path is available.\nAsk whether they have a custom domain and which \"from\" address emails use.\nFor DNS, distinguish the registrar (where the domain was bought) from the authoritative DNS host.\nCloudflare, GoDaddy and Porkbun DNS are automated; a domain bought at one may use another's DNS.\nThe GoDaddy/Porkbun adapters check public delegation and do not move nameservers or buy domains.\nNeon supplies server-side Postgres connections, not the Supabase SDK or Supabase Auth. Choosing it\ndoes not migrate an existing Supabase app. For an existing Neon database explicitly select its\nbranch, database and role; show those selectors in the approval summary. New Free projects use\nthe documented initial defaults. Schema migrations and app-level authorization need separate review.
init --stack hosting=<id>,db=<id>,auth=<id>,payments=<id>,email=<id>,dns=<id>\n [--domain example.com] [--email-from hello@example.com]\n [--project hosting=<id|name>,db=<id|name>] [--webhook-path /api/...] [--events a,b]\n [--stripe-publishable test=pk_test_…,live=pk_live_…] --json\n--project for a deliberately chosen existing project. Otherwise\ngolive may propose adopting a same-named project or creating one; neither implies consent. In a\nthrowaway test, stop on a same-name collision and choose a fresh name instead of adopting it.detect.webhooks[], both path and events (the event types the\nhandler handles), against the handler code. Pass --webhook-path / --events if either is wrong\nor events is empty.doctor --jsonFor each provider with ok: false, give the human its howToFix (see \"How the human connects\naccounts\"). credentials shows the credentials file's path, whether it's private, and the names\nin it. Re-run until everything is ok or the rest are guided.\nFor a guided provider, doctor can return ok: false and exit code 2 because no adapter exists;\nthis alone is not a login failure or a reason to request another credential. Verify its account\nthrough the chosen official tool or dashboard, following references/guided.md.\nFor Supabase, distinguish token capabilities from resource scope: \"Full access\" to one\nproject cannot create another project or manage its organization. A /profile 403 can mean a\nproject-scoped token, not an invalid key. Explain the required scope; don't blindly ask for another\nFull access token. A passing account check doesn't prove every later endpoint permission.
plan --jsonExplain the steps by provider, in plain language, and call out:
\nneeds --confirm-live / --confirm-dns / --confirm-destroydeploy:production needs --confirm-live when this plan carries the project's first production\ndeploy (state records no successful production deploy for that target); the step's own preview says\nwhy, and deploy:production:final carries the same flag when it runs with that first deploy. It is\nthe first write to a live destination: explain why you are asking — approving the plan approves what\nthat deploy contains, and this flag is the separate approval to write production there for the first\ntime. A failed attempt records no deploy, so the gate stays; once golive records a successful one,\nlater deploys of that target need no extra flag.project:hosting / project:db: which project and account every write goes to. If a step\ncreates a project, its preview lists existing projects; ask whether to use one of those instead\n(init --project <axis>=<name>, then plan again). Creating a project can cost money.handoffs: what only the human can do. For a missing Stripe publishable key, ask for the pk_ key\nand run init --stripe-publishable <mode>=pk_<mode>_…, then plan again.auth:settings / auth:redirects (Supabase Auth): the auth policy comes from auth in\ngolive.yaml (signup, requireEmailConfirm, passwordMinLength; set or change those keys and\nre-run plan) and the redirects from the production URL. They are separate steps, each writing\nonly what differs; show the before → after lines as the change being approved.auth:smtp: only when the human opted in with auth.smtp: resend and the email axis is Resend.\nSay plainly that it points the project's auth emails at Resend's SMTP (smtp.resend.com:465, user\nresend) as the sender email.from already names, and that the SMTP password is a sending key\ngolive already issued: the one the email journey issued in this run, otherwise one golive issues for\nSMTP alone (golive-…-smtp, recorded in state like every other key). Never ask for that password —\ngolive never prints, stores or reports it, and the provider never returns it (it answers a hash), so\nthe step confirms the host/port/user/sender it can read back and a real auth email arriving is the\nonly full proof. It also raises the project's auth email rate limit (rate_limit_email_sent) in\nthe same approved write — the provider keeps that limit with custom SMTP in place, so wiring the\nmailer alone does not free a run's four sends — to 30 per hour, or to auth.emailRateLimitPerHour\nfrom golive.yaml; the plan and the step's changes name it (auth email rate limit: 2 → 30 per hour). Then auth-policy reports custom SMTP via Resend instead of the built-in-mailer warning\nplus the limit the project now holds, and the journeys below no longer depend on that mailer's rate\nlimit.auth:test-user: only when the human opted in with auth.e2e: true, auth.testEmail and (for the\napp route) auth.protectedPath. Say plainly that it creates a real account in their project\n(a --confirm-live write), that the generated password lives only in that run, and that the\nconfirmation email goes to their inbox: clicking that link is their one manual step\n(auth:confirm-email). Once they click, golive handoff reports that handoff done — auth-signup\nproves the journey from the provider's own reads, without needing that run's password — and a fresh\nplan + apply rotates the password so auth-signup / auth-session also prove the confirmed\naccount can sign in. Those two checks also sign up one throwaway probe account each run, so verify\nwrites when auth.e2e is on; with it off they skip and nothing is created.auth:recovery: only when the human opted in with auth.recovery: true and a confirmed test\naccount is already recorded (the journey above; a plan says so and waits when it is not). Say plainly\nthat it rotates that test account's password — a --confirm-live write — through the provider's\nown recovery calls: it asks for a real recovery email, mints the link with the admin API, exchanges\nthe token for a session and sets the new password with that session. The old and new passwords and\nthe token live only in that run's memory, and the recovery email lands in the human's inbox: clicking\nit is their step (auth:recovery-email, non-blocking, closed by auth-recovery). It never touches\nany other account, and a captcha or the provider's mail throttle stops it with the reason.auth:isolation: only when the human opted in with auth.isolation: true and auth.e2e: true\nalready seeds the first account. Say plainly that it creates a second real account in their\nproject (a --confirm-live write) whose address is auth.testEmail plus +gl-isolation, that\ngolive confirms that second account through the provider's admin API (so no second click is\nneeded; the confirmation email it also receives is a side effect), and that the passwords live only\nin that run's memory. Then say what the isolation check needs from the app: two routes named by\nauth.identityPath (the caller's own identity as JSON) and auth.isolationPath (the caller's own\nrows; a POST stores one row for the caller), both refusing anonymous callers. When those are not\ndeclared, auth:isolation-routes (non-blocking, closed by auth-isolation) is the app-code task to\nhand to the coding agent — the check itself writes one marker row per account through\nauth.isolationPath while it runs, so verify stores two small rows in the app's own data when\nthis opt-in is on.preview:deploy / release:check: only with release.preview: true in golive.yaml and\npreview in targets. Say plainly that the deploy makes a real preview deployment of the current\nworking tree (the branch is named in its preview; the preview env is filled from the same\ndatabase/auth project as production, so a preview touches production data), that it records the\nprovider's own deployment id, and that needs includes --confirm-live when a live-mode value fills\na preview env name. release:check writes nothing; it depends on preview:deploy and re-reads\nthat deployment from the provider and scans the HTML/JavaScript it serves, and fails the plan when\neither fails — that failure is the gate, and nothing is promoted by those two steps. Say plainly what\nthat gate does and does not stop, because the step's own text does: it is the last step, so it stops\nnothing that came before it — a production deploy this plan emits runs earlier and is not gated by it\n— and what it gates is the promotion (a later plan, which re-runs the check before any production\nwrite). apply --only release:check is refused while preview:deploy has no completed evidence, so\nthe gate is never run against a deployment the plan did not make. A host with no per-deployment\npreview read (Vercel) makes both checks skip: say that the preview is unverified rather than implying\nit passed, and point the human at the provider's own dashboard or CLI. These step ids are new, so a\nplan approved before the opt-in no longer matches: re-plan and get a fresh approval.promote:production / release:rollback: only with their own opt-ins (release.promote: true on\ntop of the preview opt-in, or release.rollback: true on its own; both set means golive plans\nneither and says why). Say plainly, in the human's language:\nrelease:check in the same plan (re-read from the provider, bundle scanned) are the approval.\nA failing check stops the plan before production changes.preview:deploy + release:check at the end of\nthe plan, a new candidate) or release (release:check + promote:production). Say plainly\nthat in a cut plan the check gates the candidate, not the plan: everything else it does — a\nproduction deploy included — runs before the preview steps, so nothing that came before the gate is\nstopped by it, and the promotion stays in the next approved plan. In the release plan the check\nis the promotion's prerequisite and a red gate stops the re-point. While release.promote is set,\nevery plan asks for a release: run the plan the human actually asked for, and after a release tell\nthem the flag is a standing request — remove it (or set it to false) when they do not want\nanother release planned. Do not loop plan/apply for it.deployed:history); it is never automatic, never deletes anything, and only an approved plan run\nperforms one. Once golive has rolled production back it reports that instead of planning the same\nrollback again. A deployment built by the provider's dashboard, a Git push or a pull request is\nnever a promotion or rollback target: that stays with the human and their provider.warnings and findings, and unmappedEnv: env names golive can't fill (e.g. OPENAI_API_KEY).\nThe human types those into the host's dashboard. Never ask for the value.Before asking for approval, put a short consent summary directly in chat, even when a detailed\nplan document exists. Read the destinations from steps[].preview (with the step's destination\nwhen it has one) and steps[].needs for the confirm flags, plus verified provider metadata — never\nguessed names. A teardown plan's targets is empty: its steps[].preview lines are the summary:
GOLIVE-…-PLAN.md, name the planId, and ask for an explicit yes\nto these exact destinations and writes. Say they can choose another team/org first.Adapt the bullets to the selected providers. Include IDs in the detailed plan to disambiguate names.\nA long document, a slug alone, or \"looks ready\" is not a substitute for this summary. Unknown scope\nor cost needs resolution before asking for approval; never infer consent from \"what's next?\".\nRemember the approved planId; changing destination requires a fresh plan and approval.
apply --plan <planId> --yes [--confirm-live] [--confirm-dns] [--confirm-destroy] --jsonReport each outcome. For a failed or blocked step, read its error/next, fix the cause, and\nrun apply again (completed steps are skipped). If a write may have reached the provider, first\nfollow references/troubleshooting.md to reconcile its remote outcome; missing local state alone\nis not permission to repeat creation. If apply says the plan changed, or domain:dns\nsays the records the host requires changed since approval, run plan again and get approval again\n(with --confirm-dns for DNS). Some things only appear after the first deploy (webhook, site URL): run\nplan again after a successful apply until it shows only the zero-write project pins. If the gate\nrelease:check failed, fix the cause and run plan + apply again: the failure is recorded, so the\nnext cut deploys a fresh preview of whatever was fixed and checks that deployment, and a promotion plan\nre-runs the check against the recorded candidate — a candidate whose check failed is never promoted.\nThe two release checks can also be re-run against the current preview with verify --only preview-deploy,preview-bundle, whose result is evidence, not a new gate. A promote:production or\nrelease:rollback step in the plan is applied the same way — one approved plan, and its own run\nre-reads both sides around the write — and it needs no extra confirmation flag: the plan names the\nexact deployment id.
teardown --json, then apply --plan <teardown planId> --yes --confirm-destroy [--confirm-dns] --jsonteardown is the inverse plan: it lists ONLY resources golive can prove it created — golive-owned DNS\nrecords at the configured provider, recorded webhook endpoints, issued sending keys, and the host\nproject whose creation marker matches. Adopted projects, records golive did not write, and anything\nwithout a capability become non-blocking manual handoffs (Supabase/Neon projects, the Resend sending\ndomain) — and so does anything the inventory could not even read: a DNS zone whose provider golive\ncannot use, cannot tell golive-owned records apart in, or cannot delete from, and a linked host\nproject golive cannot reach or whose host exposes no project deletion. Those rows name what remains\nand the fix (reconnect the provider and re-run teardown, name that provider in golive.yaml again,\nor delete it in the dashboard), so golive never goes quiet about records left pointing at a project\nthe same teardown may delete. Show the list, get explicit approval, then apply with --confirm-destroy;\nDNS deletions also need --confirm-dns and live-mode endpoints --confirm-live. An already-removed\nresource is a harmless no-op, and a blocked deletion step deleted nothing — resolve and re-run. A\nremoval the provider's answer says is gone forgets that resource's recorded id/baseline (the DNS\nbaseline, the webhook endpoint id, the sending key id), and removing the host project forgets its\ndeploy facts, so a later status does not report golive's own teardown as drift. A webhook delete is\nre-read from the provider; a revoked sending key stays unverified (no provider read exists for an\nissued key) and is reported as a warning, never a pass.
verify --jsonRuns the live checks and writes GOLIVE_REPORT.md. A skip means blocked or not applicable, never\npassed: its evidence says blocked by: <id>. If accounts fails, fix logins first and re-run;\nmost other checks skip until then. verify --only <id> produces a partial report for this invocation;\nold results are not carried forward. Run full verification for a current check set. A check report\ndoes not establish deployment readiness or replace reviewing pending plan steps and app acceptance.
Check scope:
\n| id | \nchecks | \n
|---|---|
accounts | \nevery automated provider is logged in | \n
env-parity | \nthe host has every env name the code needs, per environment (names only) | \n
domain-live | \ncustom domain is attached at an automated host (ok), resolves, serves HTTPS; with a guided host, DNS + HTTPS only (attachment not confirmed) | \n
netlify-public-access | \nNetlify's confirmed production homepage accepts an anonymous request; a private gate needs the exact-project visibility UI handoff, without changing team defaults or exposing previews | \n
bundle-secrets | \nknown secret patterns in fetched production HTML/JavaScript; incomplete fetches or scan limits warn instead of passing | \n
rls-probe | \ntables not readable with the public key | \n
db-connection | \nselected Neon database and role accept a fixed read-only query; does not verify migrations, deployed app access or user isolation | \n
auth-redirects | \nauth site URL / redirect allowlist point at production | \n
auth-policy | \nauth signup/confirmation/password policy matches the app and golive.yaml (site URL and redirects are auth-redirects); the mailer is reported as the provider's built-in one (with its rate limit) or as the custom SMTP it is (Resend's own host named), with the provider's own auth email rate limit and a medium warning when it is below the four accepted sends an auth journey run needs; a setting the provider does not report is named, never assumed, and the SMTP password is never read back | \n
auth-signup | \nthe auth.e2e journey: a fresh probe address gets a confirmation email, cannot sign in before confirming, and the test account reads back confirmed (email_confirmed_at) — a sign-in of that account is extra evidence when this run holds its password (golive never sees the inbox: delivery and the click stay human-confirmed) | \n
auth-session | \nthe auth.e2e journey: the test account's password login returns a session, the token resolves to that user, an anonymous request is refused, and a declared auth.protectedPath is not publicly readable | \n
auth-recovery | \nthe auth.recovery journey: the provider accepts the recovery request for the test account, an address with no account gets the same answer (a different one is account enumeration), the token this run spent is refused when replayed, the new password signs in and the one it replaced is refused, and the token's window is named from otpExpirySeconds when the provider reports it (a 429 only warns: the mail throttle decides what a run can prove) | \n
auth-isolation | \nthe auth.isolation journey: two recorded accounts sign in at once, both declared routes refuse an anonymous caller, each account's identity route answers with its own id and never the other's, and each account's rows route returns its own marker row and none of the other's (an anonymous 200, a crossed id or another account's marker fails critical) | \n
webhook-unsigned | \nthe production webhook rejects unsigned POSTs (a non-HTML 401/403 only warns: it may be an auth wall) | \n
webhook-registered | \nthe endpoint exists, enabled, for the right URL and events | \n
stripe-live-ready | \nthe Stripe account can take live payments | \n
email-dns | \nthe sending domain's SPF/DKIM/DMARC records are published | \n
email-verified | \nthe email provider marks the domain verified and the records it lists for that domain resolve in public DNS: a domain the provider still calls verified whose records are gone fails; a lookup that failed, a provider that cannot list its records, or one that lists none, warns or skips — never a pass; a record golive wrote inside the 48 h propagation window warns instead of failing | \n
preview-deploy | \nwith release.preview: true: the hosting provider's own read confirms the preview deployment golive recorded (deployed:preview:id) is ready, belongs to the linked project and is not the production deployment; skips once golive itself promoted that deployment (it is production then, not a preview to gate) | \n
preview-bundle | \nwith release.preview: true: the HTML/JavaScript the provider-confirmed preview URL serves carries no known credential patterns (a protected preview skips; an incomplete scan only warns) | \n
production-release | \nwith release.promote/release.rollback (or a recorded release, even after the opt-in is removed): the provider's own read of what production serves is the deployment golive promoted or rolled back to, naming what production served before. Skips without a recorded release and on a host that cannot answer that read (Vercel); warns when production serves a deployment golive never recorded (a dashboard, Git or PR-built one — a handoff, action for the human); fails when it serves another deployment golive recorded (something moved production after the release) | \n
auth-signup and auth-session are opt-in: without auth.e2e: true in golive.yaml they skip with\nthat reason and create nothing. With it on, each run signs up one throwaway probe account (address\nauth.testEmail plus a plus-tag). The seeded account's password exists only in the run that seeded or\nrotated it, so auth-session skips with blocked by: no password for the test account in this run\noutside such a run; auth-signup needs no password — it passes on the provider's own reads (the\nprobe's signup, its refused login, the account's email_confirmed_at) and adds the confirmed login as\nextra evidence when that run holds the password. Never report the inbox leg as verified by golive.
auth-recovery is opt-in too (auth.recovery: true), needs a seeded account (blocked by: auth:test-user without one) and only passes in the run that carries the auth:recovery step: the\npassword it set and the token it spent exist there and nowhere else, so a plain verify skips with\nthis run holds none of what the recovery check needs. It spends up to two auth emails per run, so a\n429 warns rather than fails, and it never reads the inbox: the click stays with the human. This check\npassed a disposable live run on 2026-09-24 (accepted request, an unknown address answered\nidentically, the spent token refused on replay, the new password signing in and the one it replaced\nrefused), so the journey is proven for Supabase — but only in the exact pass that report carries: the\nhuman's inbox click stays human-confirmed, and a project's captcha or mail throttle can still make a\nrun skip or warn. Never present the inbox leg as verified by golive.
auth-isolation is opt-in too (auth.isolation: true, plus auth.identityPath and\nauth.isolationPath), needs the second account the auth:isolation step seeds (blocked by: auth:isolation without one) and needs BOTH accounts' passwords, which exist only in the run that\nseeds or rotates them: a plain verify skips with that reason. A skip — never a pass — is also the\nanswer when a route is undeclared or answers 404 (the skip names the app-code task), when a route\nrefuses the session token golive holds, when the host cannot confirm the production URL, or when the\nprovider or the app rate-limits a request. Treat it as implemented and mock-covered, not\nlive-validated: until a live run's report says pass, never present account isolation as proven on\nthe human's project, and never read it as covering an app whose routes golive could not read.
preview-deploy and preview-bundle only mean anything after an opted-in preview deploy recorded\ndeployed:preview:id: without one they skip with that reason, and a plan without release.preview\nnever produces one. Treat them the same way — implemented and mock-covered, not live-validated —\nand note that on a host exposing no per-deployment preview read (Vercel) both skip, so the preview is\nunverified by golive rather than gated; say that plainly instead of presenting the preview as checked.
production-release is the same: implemented and mock-covered, not live-validated. It only has\nsomething to confirm when a promotion or a rollback recorded one (deployed:release), and on Vercel\nit skips with exposes no read of what production serves — that is not a pass. Report its warn branch\nas a handoff (the human confirms or changes that deployment in the provider's own dashboard), and its\nfail branch as an open problem: production moved after the release, so re-plan (golive plan) and\napply the release step it shows if production should serve a deployment golive created.
Finish with a short summary: the live URL, what passed, what is still open (handoff --json), and\nevery done: null / skipped item named as not verified by golive. Say who owns each remaining item —\nthe human's login, purchase or dashboard step, a recurring job, or golive's own next run.
status --jsonRun this once the app is live: before a release, and after a run that changed providers or\nsettings. It compares what golive recorded (the DNS records it wrote, the env names it delivered,\nthe webhook endpoint, the domain attachment, the db project and its connection selectors, the sending\ndomain, the payment account, the host project, unfinished release state) with reads taken now. It\nwrites nothing — no report, no state, no provider write — and exits 2 when any item has an\naction other than none.
expected is recorded by golive action: verify → re-establish it with that item's checkId (verify --only <checkId>);\nreconcile → plan, get approval, apply (DNS needs --confirm-dns); human → only the human can\ndecide (an account switch, a project that cannot be read).medium and info items often say the change may be intentional: ask the human instead of\nreporting a fault. info + action: none is nothing to act on (e.g. DNS still inside the\npropagation window).unverifiable: true, and every notChecked entry, means golive could not read that subject:\nsay so plainly and never present it as clean. verified lists what was read and found unchanged —\nthe only thing a \"nothing changed\" statement may cover.status as a gate. Do not block plan, apply or a release on it, and never\nre-baseline anything by hand: only an approved write moves a baseline. Drift is a review list for\nthe human, not a decision the agent may take for them.For the durable ownership record, run handoff --write --json (add --force only when the human\nagrees to replace a file golive did not generate). It writes GOLIVE_HANDOVER.md and\n.golive/handover.json: the accounts and login route, every resource golive provably created with the\nproof it is golive's, what is still manual, what recurs (DMARC tightening, key rotation, backups,\ndomain renewal), how removal works, and the commands that re-check each subject. Every row is tagged\n[verified by golive], [recorded <date>, not re-checked], [not verifiable by golive] or\n[unknown] — treat the last three as unverified, and never present the document as drift detection,\nbecause nothing was re-checked unless its row says so (use status to re-check those subjects). It\ncontains no secret values, but it names accounts and resources: tell the human to review it before\nsharing it. The CLI's report is GOLIVE_REPORT.md. Recommend adding .golive/, GOLIVE_REPORT.md\nand GOLIVE_HANDOVER.md to the app's own .gitignore: state, report and handover carry resource ids\nand account names, while credential values live outside the repo in the private credentials file.
references/plan-and-verify.md: detect findings, plan steps and ordering, handoffs, what each\ncheck needs and why it skips, and what status compares.references/guided.md: when the chosen provider isn't automated.references/troubleshooting.md: setup failures, CLI/PATH mismatches and resuming after a repair.references/<provider>.md: vercel, netlify, supabase, neon, stripe, resend, cloudflare-dns, godaddy, porkbun.