Ship Now

Use this only after the user explicitly requests the fast admin-merge path.
It is an intentional exception to /ship's remote-CI wait and ten-minute
merge soak: local pnpm prep:urgent, or targeted recovery of its failed lanes, is the
pre-merge validation gate. The user has authorized --admin merging once
feedback is handled. Remote CI, release, and beta deploy results are monitored
after merge, not waited on before the admin merge.

Deployment split

Merges to main trigger .github/workflows/deploy-beta-sites-prebuilt.yml,
which builds in GitHub Actions and uploads prebuilt artifacts to the independent
Netlify beta sites at beta.*.agent-native.com. Netlify Git-connected
auto-builds are disabled, so do not wait for Netlify build queues or
deploy-preview checks; verify the Actions run and its per-site smoke checks.
Production promotion is manual for other production sites. The public docs
site is the temporary exception: matching main changes trigger
.github/workflows/deploy-docs-production.yml, which publishes
www.agent-native.com directly and disables its Git-connected Netlify builds.
/ship-now monitors beta, docs production, and any release tail after the
fast merge; it does not imply that other production sites were promoted. If a
critical fix needs another production site, explicitly run the manual
promotion and monitor that result separately.

Use .github/workflows/deploy-production-sites-prebuilt.yml or the targeted
promote-netlify-deploy.yml workflow to promote a critical fix and let it
manage Netlify lock transitions. Do not manually remove or clear a Netlify lock
as a deployment step; clearing one is not the production promotion.

Auth-path post-merge gate

When a merge changes Better Auth, OAuth callback/identity plumbing, or the
shared AuthPage/onboarding surface, beta deployment is only the built-runtime
checkpoint. After the affected beta sites deploy, dispatch both lanes below
from main, using the exact affected app ids:

gh workflow run beta-e2e.yml --ref main \
  -f lane=signup \
  -f signup_apps=<email-signup-affected-apps> \
  -f signup_environments=beta
gh workflow run beta-e2e.yml --ref main \
  -f lane=public+authed \
  -f apps=<affected-beta-apps>

The signup lane's signup_apps input is independent of the browser lane's
apps input. Wait for the signup job's classified output to be exactly
success and for the affected browser lane to pass. Complete each touched
Google callback in a real browser session as well; the seeded authenticated
lane deliberately excludes Google-only Mail and Calendar. A failure,
cancellation, inconclusive Mailosaur result, missing beta deploy, or untested
provider path stays Open - do not report the auth fix as done.

Fast-path contract

/ship-now publishes the complete nonignored current-branch snapshot. Use
corepack pnpm ship:push for every checkpoint; it excludes
learnings.md, bridge/**, and data/**.

The fast gate is local pnpm prep:urgent, or the narrowest successful recovery check
for each failed prep lane. Once that gate and review resolution pass, admin
merge immediately. Do not wait for a full prep rerun, remote CI, release or
beta deploy checks, or the normal /ship soak; monitor those after the merge.

A worktree is a valid publishing checkout. When /ship-now is authorized from
a worktree, keep validation, commit, push, PR lookup, and admin merge in that
worktree's current branch and cwd. Do not copy changes into the shared
checkout, and update the existing PR rather than creating a second one.

Workflow

1. Inspect the current branch before writing or moving it:

   git status --short
   git log --oneline -5
   git branch --show-current
   gh pr list --head "$(git branch --show-current)" --state open --json number,title,url

   Stay on the current branch until its PR is merged. Do not reset, rebase,
   force-push, clean, or silently discard local work. Record the current status
   as the branch snapshot.

2. Resolve review state before merging. Read every current human and bot
   review summary and every top-level inline comment across all pages. Fix
   real issues on the current branch and reply to each addressed or declined
   comment. Recheck reply coverage after every push; a new bot review is a new
   round. Do not merge with unaddressed feedback.

3. Run the local gate:

   pnpm prep:urgent

   prep:urgent uses --kill-others-on-fail; a lane killed because a sibling
   failed is unknown, never green. Treat a non-zero, skipped, killed, or inconclusive prep result as a failure
   to classify, not as a reason to repeat the entire suite automatically. Fix
   the root cause and rerun the narrowest meaningful check for the failed lane:

   • a package typecheck failure: that package's typecheck, for example
     pnpm --filter @agent-native/desktop-app typecheck;
   • a test failure: the specific Vitest file or test command;
   • a guard failure: the named guard command;
   • formatting: pnpm exec oxfmt --check <changed-files>.

   Keep only lanes that conclusively reported success, and rerun any lane whose
   result is unknown alongside the failure. Run a full pnpm prep:urgent again only
   when the fix crosses several validation boundaries or the failure cannot be
   isolated. For a file-scoped type failure, a green
   package typecheck is the recovery gate; for a test failure, a green targeted
   test is the recovery gate. Once the targeted recovery is green and no lane
   is left unknown, continue to the branch-wide push - do not wait for a
   redundant full prep rerun. Record that prep recovered through targeted
   checks - do not claim the entire pnpm prep:urgent command itself exited 0 when it
   did not, and do not report an unknown lane as one that passed.
   Preserve exact unrelated check or environment failures rather than
   calling them green.

4. Publish the complete current-branch snapshot immediately after the local
   gate passes:

   corepack pnpm ship:push

   Verify the push landed on the current branch and update the existing ready
   PR. Do not create a second PR. Recheck the PR's mergeability and current
   review comment reply coverage after the push.

5. Admin-merge immediately when the explicit fast-path gates are true:

   • local pnpm prep:urgent passed, or every failed and unknown prep lane was fixed
     or rerun and its narrow recovery check passed as described above;
   • all nonignored local changes are pushed, with only the routine exclusions
     remaining;
   • every review item has a fix or an explicit reply;
   • the PR is not conflicting; and
   • the user has explicitly authorized this /ship-now invocation.

   Use the current PR number and no force push:

   gh pr merge <number> --squash --admin

   Do not wait for remote CI, release checks, or the normal /ship soak, and
   do not pretend that a queued merge is complete. Read the merge result,
   fetch origin/main, and verify the merge commit is present before rotating
   branches.

   6. Run /new-branch after the merge lands. Follow its activation guard,
      origin/main freshness check, stash gate, branch naming, conflict handling,
      and post-flight stash report exactly.

6. Monitor the merged PR and release tail after rotation. Check the merged PR's
   merge commit, all workflows attached to that commit, beta deployment status,
   and package publication when applicable. Keep configured, source-tested,
   built-runtime, deployed, and observed-live claims separate. A merge is not
   proof that beta is healthy, and beta is not proof that production was
   manually promoted. Include production only when that manual promotion was
   explicitly started. Re-read the merged PR for new review or bot feedback;
   fix actionable post-merge feedback on the fresh branch and invoke /ship
   for the follow-up.

7. If a post-merge CI, beta deploy, package-publish, release, or explicitly
   promoted production issue appears:

   • reproduce or read the failing artifact;
   • fix it on the fresh branch, never on the merged branch;
   • run the smallest meaningful local check, then pnpm prep when the change
     warrants it;
   • invoke /ship for the follow-up so its normal review, merge, and
     post-release gates apply.

   If no post-merge issue appears, report the PR, merge commit, fresh branch,
   release checks, and the monitoring window honestly.

Safety rules

• Never expose environment values, tokens, cookies, or private payloads in
  commits, PR text, logs, prompts, or status reports.
• Publish all nonignored local paths through corepack pnpm ship:push.
• Never silently skip a review comment, CI failure, package release failure,
  or production deploy failure.
• Never treat a Netlify lock as the production promotion mechanism or remove it
  manually to force a promotion.
• Never create a fresh branch before verifying that origin/main contains the
  merge commit.
• Never claim the fast path is complete from a successful merge command alone;
  verify the merge, branch rotation, and post-merge release state.

Related skills

• /ship for the normal guarded ship flow and follow-up fixes.
• /ship-and-monitor for the normal guarded ship flow plus this post-merge
  monitoring behavior without the fast admin-merge exception.
• /babysit-pr for review/comment/CI coverage before a merge when the user did
  not explicitly choose this fast path.
• /new-branch for the only permitted branch-rotation procedure.