# Deployment Guide

Deployment moves a verified candidate into a controlled environment and proves it can be monitored, recovered, and supported. Adapt commands to [PREFERRED TECH STACK] and [DEPLOYMENT PLATFORM]; never paste real credentials into this document.

[Kit README](README.md) · [Project Overview](Project%20Overview.md) · [PRD](Full%20PRD%20Template.md) · [Master Build Prompt](Master%20Build%20Prompt.md) · [Completion Checklist](Project%20Completion%20Checklist.md)

## Environment Plan

| Environment | Purpose | Data | External Services | Access | Deployment Rule |
| --- | --- | --- | --- | --- | --- |
| Local | Development and isolated tests | Synthetic | Sandboxes/mocks | Builders | Manual |
| Preview/Test | Acceptance and integration | Synthetic or approved test | Sandbox | Team/reviewers | Per change or candidate |
| Production | Real users | Real, minimized | Live | Least privilege | Approved automated release |

## Pre-Deployment

- [ ] The exact commit/build and release owner are identified.
- [ ] Formatting, type, unit, integration, end-to-end, accessibility, security, and performance gates pass.
- [ ] Environment variables are documented with fake examples and production secrets exist in the approved secret store.
- [ ] Database or local-format migrations were rehearsed against realistic volume and backed up.
- [ ] External domains, app identifiers, callback URLs, webhooks, signing, or store settings match production.
- [ ] Monitoring, alerts, dashboards, support contacts, runbooks, backup, restore, and rollback are ready.
- [ ] Controls for unclear positioning, oversized media, broken mobile navigation are verified.
- [ ] User-facing legal/privacy/support content required by the actual project is reviewed by the responsible person.

## Release Procedure

1. Freeze and tag the approved candidate.
2. Capture a backup or recovery point appropriate to the project.
3. Apply backward-compatible data changes before code when required.
4. Deploy to preview and run the P0 smoke script.
5. Deploy using a staged, canary, phased, or small-audience method when possible.
6. Verify identity, permissions, core state change, persistence, external dependency, logs, metrics, and user-visible confirmation.
7. Monitor the first [TIME WINDOW] against explicit error, latency, cost, and domain thresholds.
8. Continue rollout, pause, or roll back based on the decision rule.

Deployment direction for this project: static hosting or a managed web platform with HTTPS, preview deployments, domain records, redirect rules, and a rollback path.

## Smoke Test

- [ ] From a supported clean state, a representative user can understand the offer within ten seconds.
- [ ] From a supported clean state, a representative user can reach any primary page in two navigation actions.
- [ ] From a supported clean state, a representative user can submit a contact request with clear confirmation.
- [ ] An invalid or unavailable path recovers safely.
- [ ] Logs and metrics record the operation without sensitive payloads.
- [ ] A restart, refresh, reconnect, or relaunch preserves expected durable state.
- [ ] The deployed version and support path are visible to operators.

## Rollback Decision

Roll back or disable the affected capability if a high-severity privacy/security issue appears, durable data is corrupted, core completion falls below [THRESHOLD], errors exceed [THRESHOLD], cost becomes uncontrolled, or recovery is uncertain. Define who may decide, the exact rollback mechanism, migration implications, and how users are informed.

## Post-Deployment

- Record release time, version, owner, evidence, incidents, and deviations.
- Verify scheduled jobs, backups, notifications, certificates/signing, and usage budgets.
- Keep the previous known-good release available for [RETENTION WINDOW].
- Review feedback and monitoring after [24 HOURS / 7 DAYS] before expanding scope.