Phase 5 · Staging deploy

The first time the app runs on a real server. The default example calls this target staging, but Zaj-PROJECT.md is the source of truth: your non-production target may be staging-primary, qa, uat, client-demo, or another environment key. Everything is validated there before production is ever touched — provisioning, DNS, the first release, the web installer, schema parity, a proven rollback, and a named observation follow-up for slow failures a quick smoke test never sees.

Phase 5 — local app → validated staging

Pages 1–6 are the MUST path and carry the immediate phase gate (page 6). Pages 7–9 are SHOULD/optional quality tracks. Non-production only — production is a separate gate (Phase 12).

Gate

The app is live on the selected non-production target, that target’s schema matches local, a one-command rollback has been proven to work, the agent-runnable monitor sweep is clean, and any 24–48h observation window is tracked as a named follow-up. No production access happens in this phase.

Phase 5 work	Tier	Owner model
Deploy to the selected non-production target	🔴 MUST	🤖 agent-run with project state/env inputs
schedule:run cron	🔴 MUST	🤖 agent/API when possible; 👤 panel fallback
Migration verification	🔴 MUST	🤖 agent-run
ServerSync capture	🟡 SHOULD	🤖 agent-run after first deploy
Deep codebase audit	🟡 SHOULD	🤖 agent-run
Atlas Cloud	🔵 OPTIONAL	N/A unless licensed/adopted
Post-deploy monitoring (24–48h)	🔴 MUST	🤖 immediate auth/page sweeps + temporary health check; 👤 password/account/email/payment moments tracked

Phase 4 → Phase 5 handoff

Start with the selected non-production row in Zaj-PROJECT.md and the Phase 4 AUTHOR evidence bundle: dep deploy "$DEPLOY_TARGET" --plan reached the symlink step, deploy.php has confirmed bin/php, env templates render cleanly, GitHub workflow/secrets are authored, DNS/TLS records are ready, and clear_paths ↔ GIT_ONLY_PATHS is symmetric. Phase 5 consumes that bundle, writes the Composer platform pin, places shared/.env, then runs the first real deploy.

One hard-won lesson gates the very first step:

Run the preflight — a real deploy died without it

A live run failed at deploy:vendors because the server PHP used for Composer did not satisfy the locked package requirements. The deploy aborted cleanly (the smoke test never ran, the symlink never switched, the live release stayed up), but the round-trip was avoidable. Preview the plan and triple-check PHP first: a preflight failure is cheap; a mid-deploy failure is not.

DEPLOY_TARGET="<selected-nonproduction-deploy-target>" # selected Deploy target from Zaj-PROJECT.md
SSH_ALIAS="<non-prod-alias>"     # example; use the selected SSH alias from Zaj-PROJECT.md
dep deploy "$DEPLOY_TARGET" --plan        # Deployer 7 uses --plan (the old --dry-run was removed)
grep -n "bin/php\\|bin/composer" deploy.php
ssh "$SSH_ALIAS" 'test -x /path/to/versioned/php && /path/to/versioned/php -v | head -1'
# Page 1 verifies the Deployer PHP/composer runtime; page 4 records the web-SAPI PHP from the installer Requirements screen.

Replace the example deploy target and SSH alias with the selected non-production row values from Zaj-PROJECT.md when your project uses names like qa, uat, or client-demo. On shared hosting the web-serving PHP is set per-domain in the control panel, while Composer and Artisan should run through Deployer’s versioned bin/php. If either side is below the strictest composer.lock requirement, raise the environment before deploying.

SHOULD / OPTIONAL tracks are evidence-classified, not silently skipped

Pages 7–9 are quality tracks after the immediate MUST gate. Default to running SHOULD work; mark true OPTIONAL work N/A only when project evidence proves it is not adopted.

• Running interactively: pages 7–8 run by default unless the operator explicitly narrows scope; if skipped, record the evidence-backed reason.
• Running a batch of phases: do all SHOULD work by default; do not invent a blanket optional-skip mode.
• Page 9 is the exception with a required decision: Atlas Cloud defaults to N/A — no Atlas Cloud license/adoption unless the project has an active Atlas Cloud license and chooses to adopt it now.
• Always list what was skipped at the end, even in fast mode. Silence is not a skip log.

This phase, page by page

MUST — pages 1–6 (the gate lives on page 6):

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 5 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 & provision host Consume the Phase 4 handoff, pin Composer to the confirmed deploy PHP, preview the plan, prepare the selected branch/target, deploy tree, .user.ini limits, shared .env (APP_KEY empty).

2 · DNS + SSL Create the non-production domain and confirm a valid TLS chain before deploying.

3 · First release Atomic deploy, APP_KEY + optimize:clear, the .env symlink BLOCKER, demo content, installer perms.

4 · Installer + harden Unblock /install, run the wizard against the selected non-production DB, verify, then re-block + re-harden.

5 · Schedule, migrations + schema Install + verify the every-minute cron (preset trap), verify migrations, export + diff the schema.

6 · Rollback + monitor Prove rollback, run the immediate monitoring sweep, open any standing observation follow-up, clear the phase gate.

SHOULD / OPTIONAL — pages 7–9 (quality tracks, after the gate):

7 · ServerSync capture 🟡 Capture installer-made server files back into Git — workflow parity, clear_paths audit, PR review.

8 · Deep codebase audit 🟡 Composer audit, Git hygiene, FVDUT, secret + debug scans, storage triage, frontend anti-patterns.

9 · Atlas Cloud 🔵 Versioned schema tracking — run only when licensed/adopted; otherwise record N/A and rely on the page-5 schema baseline.

Next

A staging deploy that survived a proven rollback, immediate monitor sweep, and tracked observation follow-up is the evidence base for Phase 6 · SuperAdmin setup and everything after. The passive 24–48h clock does not block Phase 6 when the immediate gate is green and the human-only journeys are tracked in Zaj-BACKLOG.md. If you need to revisit how the release pipeline itself is wired, that lives back in Phase 4 · Deploy pipeline.

Choosing the production path

Configure branding, SMTP, payments, plans, and admin settings on the selected non-production target first (Phase 6). Then pick how many phases to complete there before the production cutover — the choice is a speed-vs-hardening trade-off, not a one-way door:

Path	When to use	Flow
A — Fast launch	Need production ASAP	Phases 1–6 on the selected non-production target → deploy to production → Phases 7–10 on that target → redeploy
B — Hardened launch	Want everything right first	Phases 1–10 all on the selected non-production target → deploy to production → verification
C — Iterative	Prefer gradual refinement	Phases 1–6 → deploy to production → Phases 7–10 on the selected non-production target, redeploy after each batch

Production deploy is its own gate: Phase 12 · Production. No production access happens in Phase 5.