deploy

/deploy — detect, plan, arm, deploy, smoke, guard

Goal: take a change that has passed the harness's gates and /harness-claude:ship has prepared, and drive it out to a running environment — using whatever deploy mechanism the project already has — with the same boundary discipline the rest of the harness applies to outward actions. The pipeline's front door stops at the repo edge; /harness-claude:deploy is the step past it. The discipline is arm-to-fire: plan the deploy and run pre-checks, then stop and wait for an explicit arm before anything leaves your machine.

Opt-in. Invoked explicitly; nothing auto-deploys. Git boundary: /harness-claude:deploy never commits, pushes, or branches. Arm-to-fire boundary: it performs no real outward action (deploy or rollback) until you type the explicit arm signal — planning and smoke-checks are safe; firing is not, and is never implied by "looks good."

When /harness-claude:deploy, when /harness-claude:ship

• /harness-claude:ship prepares a clean commit / PR summary and stops at the repo boundary. It is the last in-repo step.
• /harness-claude:deploy is the first out-of-repo step — it pushes an already-shipped change to a live environment and verifies it there. Run ship first; deploy does not commit your work.

How it works

detect mechanism → name rollback path → pre-deploy smoke → ARM-TO-FIRE HALT
  → (on `arm deploy`) deploy in tmux → smoke the DEPLOYED artifact → guarded rollback on failure

Do this

1. Detect the deploy mechanism — never prescribe one. Find the project's existing mechanism, in priority order: vercel.json / Vercel project → Dockerfile (+ registry/compose) → a Makefile deploy/release target → CI config (.github/workflows, etc.) → package.json scripts.deploy → other declared scripts. When a platform skill matches what you detect, delegate to it rather than reinventing (e.g. vercel:deploy / vercel:vercel-cli when a Vercel project is present). If no mechanism is found, say so and stop — do not invent a deploy command. (AC-D1)
2. Name the rollback path up front. Before anything else, state the concrete rollback for the detected mechanism — e.g. vercel rollback, redeploy the previous image tag, re-run CI on the previous SHA. Surface it in the plan. If no rollback path is identifiable, say so explicitly so the risk is visible before the HALT. (AC-D2)
3. Run pre-deploy smoke checks. Confirm the change is actually deployable: repo green (/harness-claude:health), build succeeds, working tree clean. Surface any failure now, not after firing. If the build breaks, delegate the harness-claude:build-error-resolver agent to get it green.
4. HALT — arm-to-fire. Show the deploy plan: detected mechanism, exact command, target environment, and the rollback path from step 2. Then STOP. Do not proceed until the user types arm deploy. "The plan looks fine" is not an arm; only the explicit signal fires. (AC-D4)
5. On arm deploy: deploy in tmux. Run the deploy command inside a tmux session (tooling default — long deploys survive and stream). If a build break appears mid-deploy, delegate the harness-claude:build-error-resolver agent; re-arm before re-firing. (AC-D6)
6. Smoke-test the DEPLOYED artifact, then guard. Verify the live target, not just local tests — reuse /harness-claude:health's runner against the deployed URL:

   node scripts/eval/continuous.js --cmd 'curl -fsS https://<deployed-url>/health'
   

   (or the project's smoke suite pointed at the deployed target). (AC-D3) On failure: surface the rollback command from step 2 and execute it only if the user types arm rollback; otherwise HALT with the rollback ready. Never leave a known-broken deploy silently in place. (AC-D5)