Deployment and rollback runbook

Scope and gates

• Feature branches target staging; staging verification precedes any promotion.
• main/production promotion requires Alex's explicit approval of the exact candidate.
• No deployment runbook authorizes environment, DNS, provider, database, credential, role, payment, or destructive changes.

Staging release evidence

For an exact staging commit:

1. Confirm the PR head, base branch, and changed-file scope.
2. Run npm test, npm run check, and npm run build against that head.
3. Confirm the dependency audit policy for the exact lockfile.
4. Merge through the protected staging workflow only after independent review.
5. Read the deployment record for the resulting staging SHA to terminal status.
6. Run the declared public health checks and any approved read-only authenticated smoke checks.
7. Record the exact SHA, deployment evidence, validation commands, and verifier in the release packet.

The tracked railway.toml declares the current build/start/healthcheck inputs. Do not edit platform policy or trigger a provider operation from this document.

Production promotion

Use the August 28 release packet as the example structure. The promotion packet must state the exact staging tree, independent verification, migration impact, rollback boundary, and Alex's approval. A staging deployment or green CI does not prove production deployment.

Code-only rollback

When the approved release has no schema/data change, create a new protected PR that restores the known-good application tree. Then verify the resulting production SHA, deployment, and public/read-only smoke checks. Never force-push a protected branch or erase release evidence.

For any release with a migration, data change, or provider change, stop and use the separate approved backup/restore and migration packet first.