Phase 12 · Deploy to production

▶Start here

You are here: Playbook → Phase 12 · Deploy to production This phase is for you if: staging is verified and you’re ready to pull the production trigger — rollback stays one command away. Not this phase? Phase 5 = staging first · Phase 11 = pre-customer gates.

The final gate: take the staging-verified app live without losing anything if it goes wrong. Phase 12 is not a sequential step you grind through — it’s a trigger you pull when staging is verified and you’re ready. Every move here keeps a rollback one command away.

Phase 12 — production cutover, rollback always ready

Pull the trigger when staging mirrors production. Each stage gates the next; the last stage is steady-state, not a finish line.

Gate

Production is live and stable — the app responds over HTTPS, admin login works, schemas match staging, all branches are synced, the release is tagged, and 24–48h of monitoring shows no error spikes. A rollback command is rehearsed and ready the whole time.

When to pull the trigger

Phase 12 can fire on three paths depending on your risk tolerance. Pick one — don’t drift between them.

Path	When to use	Flow
Fast launch	Need production ASAP	Core phases on the selected non-production target → go live → harden + polish there → redeploy
Hardened launch	Want everything right first	All phases on the selected non-production target → go live → final verification
Iterative	Prefer gradual refinement	Core phases → go live → polish on the selected non-production target, redeploy after each batch

Don’t wait for polish to launch

Growth/SEO/compliance polish is mostly post-launch. The minimum that should land before going live: a cookie-consent banner if your audience includes regions that require it, the SEO foundation, and meta titles/descriptions for top pages plus a submitted sitemap. Treating all polish as pre-launch routinely delays launches for weeks with no real gain.

Prerequisites

Confirm every item before any deploy step runs:

• Entry gate (Task P.0) — Phase 12 production is blocked unless the Phase 10-CONSOLIDATED verdict (Admin-Local/1-Project/4-Audit-Reports/...-phase-10-CONSOLIDATED.md) is 🟢 GO or an explicitly accepted 🟡 CONDITIONAL GO. 🔴 NO-GO = hard block, no exceptions. A missing verdict = STOP — deploy nothing.
• Production environment row exists in Zaj-PROJECT.md — URL/domain, hosting account, SSH alias, host/user/port, deploy target, source branch, DB name, web PHP, CLI PHP binary, credential pointer, noindex/robots posture, and last verified date are filled and current.
• Staging deploy immediate gate complete — app live on the selected non-production target, schema verified, rollback proven, agent-drivable monitor/auth sweeps clean, and any passive 24–48h watch or human-only journeys tracked. For production cutover, the passive watch must be completed or explicitly accepted in the launch decision.
• Superadmin setup done on the selected non-production target — branding, SMTP, payments, and legal pages all configured.
• Server setup verified on the production account (it may be a different host from staging — server setup runs on each).
• Production database created (empty) in the hosting panel.
• Production .env template prepared in your secrets manager / project vault — placeholders only, never committed.
• Production DNS + TLS ready — the production A record resolves to the current origin IP from Zaj-PROJECT.md, the origin cert / Let’s Encrypt cert is issued, and any Cloudflare proxy is Full (Strict). A public Cloudflare 525 is a hard block, not an app-deploy state.
• Rollback plan reviewed, emergency contacts documented, and stakeholders notified of the deploy window.

Non-production must mirror production

The selected non-production target (staging-primary, qa, uat, client-demo, etc.) should use the same SMTP provider, HTTPS, security/caching rules, and payment gateway mode production will use. If that row mirrors production, anything that works there should work on production — the only differences are the domain, the DB credentials, and live API keys.

Database strategy — decide first

How you seed the production database decides how much work you repeat.

Option	Pros	Cons
Fresh installer	Clean DB, no URL/encryption issues	Redo all superadmin config (1–2h)
Copy verified non-production DB	Skip admin config (~10 min)	Must find/replace non-production→production URLs; watch app-key-encrypted columns
Hybrid	Best of both	Fresh install, then selectively import settings/plans; needs SQL comfort

For a first production deploy, Fresh installer is safest — it avoids encryption-key mismatches and URL find/replace errors. Copy a verified non-production DB only once the process is routine and the source environment row is current in Zaj-PROJECT.md.

Pages in this phase

Two ways to run this: Whole Phase → click the button; one Part → open the Part document and click Run this Part. Skill users can run /zaj-laravel-codecanyon phase 12 instead.

▶ Run this Phase

STEP 0 — COLD-START ORIENTATION (do this BEFORE fetching any Part document; assume you have ZERO prior context about this project): 1. Locate + identify. Run `pwd`. Read the project's `AGENTS.md` + `CLAUDE.md` if present so you know the repo rules and whether you are in the right project. Then read `Zaj-PROJECT.md` FIRST as the non-secret project bible: identity, environment matrix, toolchain versions, SSH aliases, deploy paths, and current phase. If `Zaj-PROJECT.md` is missing in a legacy project, read `Admin-Local/1-Project/1-Info/ProjectCard.md` as fallback, then create/update `Zaj-PROJECT.md`. 2. Read the state ledgers — READ BOTH OLD AND NEW NAMES (projects mid-migration use either): `Zaj-PROGRESS.md` OR `PROGRESS.md` (what earlier phases/steps already did, what's in-flight), `Zaj-BACKLOG.md` OR `BACKLOG.md` (phase-entry blockers, deferred work, and scheduled follow-up), and `Zaj-CUSTOMIZATIONS.md` OR `_CUSTOMIZATIONS.md` (vendor deviations + prior findings you must not re-derive or contradict). 3. Check git reality: `git branch --show-current`, `git log --oneline -8`, `git status --short`. - FRESH vs RESUMING: if commits/ledger show this phase (or earlier steps) already ran, you are RESUMING → verify-with-evidence, do NOT blindly re-run installer / migrate / db-create / asset-build. (This is the contract's reconcile rule.) - CONCURRENT-WORK check: uncommitted changes you didn't make, or HEAD ahead of the ledger, can mean ANOTHER agent is working this repo. Coordinate around hot files; do not commit over unrelated work. Routine tracker fixes remain agent-owned work unless they would overwrite a hot file another agent is editing. 4. Inherit rules + safety: skim `.claude/rules/` (project-specific vendor gotchas) and obey them + these non-negotiables — never echo secrets (verify by length/exit-code only), never re-run destructive/once-only steps, archive-don't-delete, honor 👤 vs 🤖. 5. How to fetch Part documents: prefer the ZajLibrary MCP `get_document` by SLUG. If the returned `commitShaShort` looks stale vs the live page (missing steps, old text), the index is behind → use `zajlibrary-local` (localhost) OR read the page's source `.mdx` directly from the ZajLibrary repo. NOTE: the MCP's "compare commitShaShort to your local git HEAD" instruction applies ONLY when you are working INSIDE the ZajLibrary repo — from THIS consuming project it is just a freshness/staleness signal, not a match to make. 6. Where to record: write current-truth facts to `Zaj-PROJECT.md`; write vendor deviations to `Zaj-CUSTOMIZATIONS.md`; write execution state to `Zaj-PROGRESS.md`; write blockers/deferred work to `Zaj-BACKLOG.md`. If a tracker row says open/deferred but you verify it is now done, fix the stale row in the same run with evidence — don't leave "closed in reality, open in tracker." File any guide bug/gap via the feedback clause (MCP `submit_feedback` + `Admin-Local/1-Project/playbook-feedback.md`) — log-then-continue, don't silently work around. Only after Step 0 is complete, begin fetching Part 1. AUTONOMY CONTRACT — complete accurate work unless a real human gate is required: 1. Treat ZajLibrary guidance as operational guidance, not a suggestion to summarize. If the user asked you to follow/apply/implement the page, do the work end to end in the real project until the page's exit criteria are met or a hard blocker is proven. 2. Do not ask the user whether to do routine agent-owned work: reading project rules, checking git state, updating progress/customization/feedback ledgers, running verification, fixing clear best-practice issues, or choosing the safer/professional default. Do it, cite evidence, and report what changed. 3. Ask the human only for true human-owned actions: credentials, API keys, paid/provider dashboards, DNS/production cutovers, destructive or irreversible operations, personal/business choices, legal/commercial decisions, or cases where two options are genuinely equal and the guide/project gives no tie-breaker. 4. If one option is clearly more secure, more professional, more maintainable, or better aligned with the guide/project rules, choose it and document the rationale instead of asking for a preference. 5. When you discover already-completed or partially-completed work, reconcile from evidence. Verify the end state, update the relevant ledger/checklist if state changed, and avoid re-running destructive or once-only commands. 6. Banned routine asks: "should I update trackers?", "should I commit?", "should I run verification?", "should I fix the stale ledger?", or "which option do you prefer?" when the guide/project makes one option clearly better. 7. If the guide has a gap or mismatch, log it through the project's documented feedback path and continue with the safest evidence-backed implementation when possible. Stop only when continuing would be unsafe, destructive, or would require a human-owned decision. AUTHENTICATION BOUNDARY — hard, non-overridable: An AI agent cannot type a password to authenticate, cannot log in, and cannot create an account in ANY environment (dev/staging included), even when the user authorizes it and the password is in the vault. For every login-gated verification step (dashboard walk, user journey, admin panel, hPanel, registrar/provider dashboard): 👤 Human performs the ONE login, dashboard sign-in, account creation, or credential-entry moment. 🤖 Agent drives everything after the authenticated session exists — clicks, navigation, non-secret form fills, screenshots, checks. For account creation, login, password-change, or password-reset forms, the human completes the credential/auth transaction through submit; the agent resumes after the account/session/credential change exists. Everything an agent can do without authenticating stays 🤖: public pages, viewport/mobile checks, API calls with an already-provided token, SSH/DB checks, and browser-driven configuration up to (but not including) a password/secret field. Only credential entry and the authentication/account-creation act are 👤. Autonomy: Do all 🤖 work without asking — tracker updates, verification, signed commits, reconciling stale items to reality are the job, not questions. Stop for the human ONLY at genuine 👤 gates: real secrets/credentials, irreversible actions (prod deploy, real money, data deletion, force-push), or genuine WHAT/scope/business decisions. Full ≠ optional: Autonomy does not mean minimal. Execute each Part fully — every Step, every # Expected: check, all states/sub-flows wired end-to-end. Never ship a happy-path subset as "done." If something genuinely can't finish in-session, it must be a real 👤/external gate (not a shortcut), stated exactly — what is deferred and why — as a tracked item before moving on. When the user says "do fully," honor it to completion. EXECUTION CONTRACT — full coverage, no silent skips: 1. Before finishing a Part, you MUST account for EVERY item in the Part's `## Steps` (including each numbered sub-step inside <Steps> blocks) AND every box in `## Checklist`. Nothing is implicitly done. 2. Scope labels are not skip permission. `MUST`, `SHOULD`, `OPTIONAL`, quality-track, companion, and fast-mode labels explain gate priority; they do NOT remove an item from coverage. Default to FULL execution. Run `MUST-only`, `MUST+SHOULD-only`, gate-only, or fast mode only when the user explicitly asks for that mode. Even then, name every skipped `SHOULD` / `OPTIONAL` item that the chosen mode leaves out as ⏭ DEFERRED with why and when. 3. For EACH sub-step and EACH checklist box, do ONE of — and record which, with evidence: ✅ WALKED — you ran the command/action; paste/point to the output it produced. 🔍 VERIFIED-STATE — end-state already satisfied (idempotent step, or a prior session did it). Allowed, but you MUST cite the evidence (command output/file/DB state) proving it — never assert "already done" without proof. ⏭ DEFERRED — legitimately out of scope now (a :::note[Who does this] 👤 step you're waiting on, or an explicit "later phase" pointer). State why + to when. ◐ PARTIAL — some sub-parts done, some deferred; list exactly which and why. 4. Honor every `# Expected:` / ✅ bullet — compare actual output. On mismatch, first investigate safely and reconcile from evidence; STOP and ask only when the mismatch creates a real human gate, destructive risk, security risk, or equally valid choices. Honor :::caution/:::danger as hard gates. Honor 👤 vs 🤖. 5. Reconciliation is allowed (don't blindly re-run installers/migrations/db-create/asset builds) — but reconciliation without per-item disclosure is BANNED. 6. You may NOT declare the Part/Phase "done" while any `## Steps` Step, sub-step, or `## Checklist` box is unclassified. Silent omission = incomplete. 7. Server continuity: if a local/server URL was working before edits, capture a baseline first. After edits, verify the server still starts and the same URL still responds. For localhost, prefer the current route or the phase/page route the user is viewing. If the server was not running before, mark server continuity as N/A with evidence instead of pretending it was verified. 8. END every run with a COVERAGE ASSERTION table (one row per sub-step + per checklist box, plus a server-continuity row when edits touched code, config, docs UI, routes, assets, or generated prompt behavior): | Item (§/step or checklist box) | ✅WALKED / 🔍VERIFIED / ⏭DEFERRED / ◐PARTIAL | Evidence / why | Then confirm the page/phase Gate condition is observably met. If the table has any row that isn't ✅/🔍 (or a justified ⏭/◐), the step is NOT done. 9. Progress/state updates are part of execution: when the guide changes project state, update `Zaj-PROJECT.md`, `Zaj-PROGRESS.md`, `Zaj-BACKLOG.md`, `Zaj-CUSTOMIZATIONS.md`, and/or `playbook-feedback.md` yourself unless the project explicitly marks that exact write human-owned. Stale-open tracker rows that evidence proves done are bugs to fix, not notes to ask about. 10. Authentication boundary: an agent never types passwords, logs in, or creates accounts. Human performs the credential/authentication/account-creation transaction; agent resumes after the session or non-secret evidence exists. 11. Secrets: never put keys/passwords/.env values in code, commits, or chat; verify by length/exit-code only.

1 · Pre-flight (P0) Security hygiene before going live — rotate every key/password that touched a chat or log, vault secrets, re-scope service accounts.

2 · Release & deploy (P1–P2) Cut the changelog + version, promote the verified non-production branch to the release branch, stage the .env, deploy the production target, run the installer, verify live.

3 · Harden, verify & sync (P3–P4) Lock down permissions, verify schema parity, sync all branches, tag the release.

4 · Monitor & day-2 (P9) 24–48h post-deploy monitoring, rollback one command away, and the abbreviated subsequent-deploy cycle.

Start with Pre-flight — never skip it.