6 · Consolidated verdict & launch handoff

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.

# ZajLibrary — implementation playbook

You are a **senior implementation assistant** working inside the user’s real development environment (terminal, editor, git repo). You are **not** a documentation writer, tutor, or library editor.

**Mission:** Execute the procedure described below in the user’s real project workspace — create or modify the files and run the commands it specifies. Do not just summarize it.

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 👤.

## Metadata
- title: 6 · Consolidated verdict & launch handoff
- url: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/10-audit-qa/06-sign-off/
- shelf: Build & Create
- doc_type: implementation playbook
- status: current
- kind: playbook
- category: tech-stack
- subcategory: laravel
- topic: codecanyon
- phase: 10
- part_number: 6 (legacy stepNumber frontmatter)
- legacy_step_number: 6
- est_time: ~45 min
- description: Synthesize the Phase 10 sub-reports into one GO / CONDITIONAL GO / NO-GO verdict, then prepare the Phase 11/12 handoff without running the production launch.
- tags: codecanyon, laravel, launch, checklist

## Execution rules (binding)
- This is Part 6 of phase 10 (~45 min) — execute this Part fully, then stop at its `## Checklist`.
- 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.
- For playbooks, treat a Part as the `.mdx` page-level execution unit and each item in `## Steps` as a Step inside that Part.
- Follow `## Steps` in order. Do not skip Steps or declare the work complete early.
- Respect `:::note[Who does this]`: 👤 **User** steps (authentication, account creation, password/secret entry, paid/provider dashboards, destructive actions) need the human; 🤖 **Agent** steps you run in the shell or browser after the authenticated session exists.
- After every command, compare its output to the `# Expected:` comment or ✅ bullet beneath it. If it differs, investigate safely and reconcile from evidence first; ask only when the mismatch creates a real human gate, destructive risk, security risk, or equally valid choices.
- Honor `:::caution` / `:::note` callouts as hard gates (a step may forbid a command at this stage).
- Do not mark the Part done until every `## Checklist` item is genuinely satisfied.
- Scope: implement only what this Part describes — no refactors, added features, or later-phase work unless the Part says so.
- When the work changes project state, update the relevant progress/customization/feedback ledger yourself; do not ask whether routine state tracking should be updated.
- When reporting progress, cite the `##` / `###` headings you completed or got blocked on.
- Secrets: never put API keys, passwords, or `.env` values in frontend code, commits, or chat logs — use server-side `.env` / config only, and keep `.env` gitignored.
- 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.

---

# 6 · Consolidated verdict & launch handoff

## TL;DR

**Objective** — synthesize the Phase 10 sub-reports into one **GO / CONDITIONAL GO / NO-GO** verdict, then prepare the Phase 11/12 handoff — the final audit gate where any unresolved high-risk item means **do not advance**.

**Steps at a glance:**
1. **Consolidated verdict** — Synthesize the existing audit evidence. Do not run new tests here; missing
   evidence sends you back to the relevant Phase 10 step.
2. **Walk the pre-launch checklist** — Confirm every area below before anyone makes a go/no-go call.
3. **Prepare the Phase 11/12 handoff** — With a green checklist, record what Phase 11 must re-verify and what
   Phase 12 must execute later. Do **not** deploy production here.

:::note[User part + done-when]
**👤 User part** — a person accepts the GO / CONDITIONAL GO / NO-GO verdict and accepts any advisory risk. The agent verifies evidence and writes the handoff, but Phase 10 does not authorize production deploy, live payments, or the 24–48h production watch.

**Done when** the consolidated verdict is recorded in `Zaj-PROGRESS.md`, every checklist area is green with zero unresolved high-risk items, every deferred polish row is routed to `Zaj-BACKLOG.md`, and the Phase 11/12 handoff clearly states what can advance and what remains blocked. &nbsp;·&nbsp; **⏱ ~45 min** &nbsp;·&nbsp; 🔀 mixed (👤 verdict/advisory acceptance, 🤖 verification + handoff).
:::

## Background

The final gate. Phase 10 is not done until the static, deep, and functional audit evidence is consolidated into a single verdict. Everything before this phase fed into one decision — whether the app is ready for paying users.

## Steps

### 1. Consolidated verdict

Synthesize the existing audit evidence. Do **not** run new tests here; missing evidence sends you back to the relevant Phase 10 step.

Confirm these three sub-reports exist in `Admin-Local/1-Project/4-Audit-Reports/` before producing the verdict:

- `YYYY-MM-DD-phase-10-A-security.md`
- `YYYY-MM-DD-phase-10-B-perf-db-seo-a11y-cookies.md`
- `YYYY-MM-DD-phase-10-C-testing-debugger.md`

| # | Dimension | Evidence source | Verdict |
|---:|---|---|---|
| 1 | Code quality / static audit | Phase 10 static audit | Green / advisory / blocker |
| 2 | Composer CVEs | Phase 10 static audit | Green / advisory / blocker |
| 3 | Git hygiene + per-environment state | Phase 10 static audit | Green / advisory / blocker |
| 4 | Secrets and env exposure | Phase 10 static audit | Green / advisory / blocker |
| 5 | Production config / debug state | Phase 10 security audit | Green / advisory / blocker |
| 6 | Default admin credential rotation | Phase 10 security audit | Green / advisory / blocker |
| 7 | Demo content, vendor creds, and vendor-integrity scan | Phase 10 security audit | Green / advisory / blocker |
| 8 | Headers, TLS, and exposed files | Phase 10 security audit | Green / advisory / blocker |
| 9 | Storage, admin, and upload exposure | Phase 10 security audit | Green / advisory / blocker |
| 10 | Runtime auth, rate limits, and IDOR checks | Phase 10 functional QA | Green / advisory / blocker |
| 11 | Core Web Vitals / LCP | Phase 10 performance audit | Green / advisory / blocker |
| 12 | Database indexes, slow queries, and N+1 checks | Phase 10 DB audit | Green / advisory / blocker |
| 13 | SEO indexing, canonical, robots, and sitemap | Phase 10 SEO audit | Green / advisory / blocker |
| 14 | Accessibility | Phase 10 accessibility audit | Green / advisory / blocker |
| 15 | Cookies, consent, and privacy links | Phase 10 cookies audit | Green / advisory / blocker |
| 16 | Functional golden paths | Phase 10 functional QA | Green / advisory / blocker |
| 17 | Payment lifecycle | Phase 10 functional QA | Green / advisory / blocker |
| 18 | Transactional email delivery | Phase 10 functional QA | Green / advisory / blocker |
| 19 | Debugger/log review | Phase 10 functional QA | Green / advisory / blocker |
| 20 | Monitoring data received | `Admin-Local/1-Project/1-Info/monitoring-state.md` | Green / advisory / blocker |
| 21 | Backup and rollback readiness | Phase 7 + launch checklist | Green / advisory / blocker |
| 22 | Open follow-ups classified | `Zaj-BACKLOG.md` audit deferrals | Green / advisory / blocker |

Classify every unresolved item as one of:

- **Blocker** — launch cannot proceed.
- **Advisory** — launch can proceed only if the user explicitly accepts the risk.
- **Deferred to `Zaj-BACKLOG.md`** — low severity or multi-hour vendor-template deferrals, such as lazy-load sweeps or bulk alt-text work.

:::danger[Vendor seed-surface sweep blocks GO]
🔴 Vendor seed-surface sweep (blocks GO): confirm the default admin credentials were rotated (no `admin@example.com` / vendor default), all demo users + demo content are removed, and vendor-shipped encrypted creds/keys are not live. For CodeCanyon apps, re-run the vendor-integrity scan (license-beacon / injected-script grep — a vendor update since Phase 6 can re-introduce it). Any survivor = **NO-GO**.
:::

| Verdict | Meaning |
|---|---|
| **GO** | All 22 rows are nonblank, zero blockers remain, advisories are explicitly accepted, and Phase 11 can start. Production deploy still waits for Phase 12. |
| **CONDITIONAL GO** | No blockers remain, but one or more advisories need named owner/date follow-up before or immediately after launch. |
| **NO-GO** | Any blocker remains, the vendor seed-surface sweep fails, reports are missing, or staging proof is incomplete. |

Before stamping **GO**, confirm all of the following:

- All 22 rows are filled in.
- Rows 6 and 7 pass; any default admin, demo data, vendor credential, license beacon, or injected-script survivor is **NO-GO**.
- Zero red/blocker rows remain.
- Every advisory is accepted by the user with owner + review date.
- At least one functional end-to-end golden path passed on the selected launch-candidate environment today.
- `Admin-Local/1-Project/1-Info/monitoring-state.md` shows monitoring data is being received or a row is marked N/A with reason.
- `Zaj-PROGRESS.md` logs the verdict, date, signer, and path to the consolidated report.
- `Zaj-BACKLOG.md` rows from the deferred items carry source, severity, effort, trigger, and acceptance criterion — no disguised blockers ("defer" for a production breaker = **NO-GO**) and no vague/no-trigger rows.

Write the consolidated report to `Admin-Local/1-Project/4-Audit-Reports/YYYY-MM-DD-phase-10-CONSOLIDATED.md`. Phase 11's first step transfers the `📋 Deferred to Zaj-BACKLOG.md` rows into root `Zaj-BACKLOG.md`.

### 2. Walk the pre-launch checklist

Confirm every area below before anyone makes a go/no-go call.

| Area | Verify |
|---|---|
| Blockers | No unresolved HIGH / open ISSUE / SECURITY items in `Zaj-BACKLOG.md` or the Phase 10 audit reports |
| Infrastructure | SSL > 30 days, DNS + www resolve, CDN proxy on, SSL mode Full (strict) |
| Security | `APP_DEBUG=false`, `.env` returns 403/404, no debug toolbar, **Grade A** headers (securityheaders.com) + **SSL Labs (TLS)** A/A+ |
| Monitoring | Error tracking captures a test event, uptime monitor + backups verified |
| Payments | Staging/test payment path passed, production keys/webhook are vaulted and scoped, and the Phase 11/12 human live-charge/refund gate is named |
| Communications | Inbox-delivered welcome/reset/invoice emails, chat widget live |
| Legal | Privacy, Terms, Cookie, Refund pages published + linked; consent banner enforced |
| Content | No placeholder text, favicon, OG/meta, sitemap, `robots.txt` correct |
| Team readiness | Admin creds in a vault with 2FA, rollback documented, 24h monitor assigned |

:::note[Who does this]
👤 **User** makes the go/no-go sign-off — a launch authorization only a person can give. 🤖 **Agent** verifies the technical items (headers, `.env` blocking, webhook config) and reports status per area.
:::

<Steps>

1. **Verify every area, then make the go/no-go call.** If any high-risk item is unresolved, **do not launch**.

   - ✅ All nine areas are green with zero unresolved HIGH / SECURITY items, and the sign-off is recorded.

</Steps>

### 3. Prepare the Phase 11/12 handoff

With a green checklist, write the handoff that tells the next phases exactly what to re-verify and what not to run yet.

:::note[Who does this]
🔀 **User + Agent** — the agent writes the handoff and reconciles trackers; 👤 **User** accepts the verdict/advisories. Production backup, release tag, deploy, live payment, go-live, and the 24–48h production watch are Phase 12 actions.
:::

<Steps>

1. **Write the handoff inside the consolidated report and update trackers.** The consolidated report must end with a short "Next-phase handoff" section.

   ```markdown
   ## Next-phase handoff

   Verdict: GO | CONDITIONAL GO | NO-GO
   Phase 11 may start: yes/no
   Phase 12 production deploy may start now: no — wait for Phase 11 signoff and Phase 12 Task P.0

   Phase 11 re-verifies:
   - Technical readiness gates
   - Business/legal readiness
   - Support/onboarding readiness
   - Tiered go/no-go

   Phase 12 executes later:
   - production secret rotation/preflight
   - production backup/tag/release branch/deploy
   - live installer/auth checks
   - production seed-surface sweep
   - 24–48h production monitor

   Blockers:
   - none | list each blocker with owner and required proof

   Deferred polish transferred to Zaj-BACKLOG.md:
   - list each row source/severity/effort/trigger/acceptance
   ```

   ```bash
   grep -n "Next-phase handoff" Admin-Local/1-Project/4-Audit-Reports/*phase-10-CONSOLIDATED.md
   grep -n "Phase 10-CONSOLIDATED" Zaj-PROGRESS.md
   grep -n "Deferred to Zaj-BACKLOG.md" Zaj-BACKLOG.md
   # Expected: consolidated report includes the handoff, Zaj-PROGRESS.md links the verdict,
   # and every deferred-polish row landed in Zaj-BACKLOG.md.
   ```

   :::caution[Do not run production from Phase 10]
   No `git tag`, production DB dump, release-branch merge, `dep deploy production`, live payment charge, go-live switch, or production 24–48h watch runs here. Those are Phase 12 actions after Phase 11 and Phase 12 Task P.0 clear.
   :::

   - ✅ The consolidated report contains the next-phase handoff, `Zaj-PROGRESS.md` links the verdict, and every deferred polish row is in `Zaj-BACKLOG.md`.

</Steps>

## Checklist

Do not mark this step done until **every** box below is checked.

- [ ] **🤖 Blockers clear** — no unresolved HIGH / open ISSUE / SECURITY items in `Zaj-BACKLOG.md` or the Phase 10 audit reports.
- [ ] **🔀 Consolidated verdict recorded** — all 22 rows complete, verdict written to `Admin-Local/1-Project/4-Audit-Reports/YYYY-MM-DD-phase-10-CONSOLIDATED.md`, and `Zaj-PROGRESS.md` links it.
- [ ] **🤖 Infrastructure ready** — SSL > 30 days, DNS + www resolve, CDN proxy on, SSL mode Full (strict).
- [ ] **🤖 Security verified** — `APP_DEBUG=false`, `.env` returns 403/404, no debug toolbar; **Grade A** at securityheaders.com; **SSL Labs (TLS)** A or A+.
- [ ] **🤖 Vendor seed-surface sweep** — default admin credentials rotated, demo users/content removed, vendor-shipped encrypted creds/keys absent, and vendor-integrity scan clean; any survivor = NO-GO.
- [ ] **🤖 Monitoring live** — error tracking captures a test event, uptime monitor + backups verified.
- [ ] **🔀 Payments ready** — staging/test path passed; production keys/webhook are vaulted/scoped; live charge + refund are explicitly named as the later human gate.
- [ ] **🤖 Communications working** — inbox-delivered welcome/reset/invoice emails, chat widget live.
- [ ] **🤖 Legal published** — Privacy, Terms, Cookie, Refund pages published + linked; consent banner enforced.
- [ ] **🤖 Content complete** — no placeholder text, favicon, OG/meta, sitemap, `robots.txt` correct.
- [ ] **🔀 Handoff ready** — admin creds vaulted with 2FA, rollback documented, 24h monitor owner named, and the Phase 11/12 handoff is recorded.

:::next[Next step]
[Phase 11 · Pre-customer verification](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/11-pre-customer/)
:::

# 6 · Consolidated verdict & launch handoff

> Source: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/10-audit-qa/06-sign-off/

## TL;DR

**Objective** — synthesize the Phase 10 sub-reports into one **GO / CONDITIONAL GO / NO-GO** verdict, then prepare the Phase 11/12 handoff — the final audit gate where any unresolved high-risk item means **do not advance**.

**Steps at a glance:**
1. **Consolidated verdict** — Synthesize the existing audit evidence. Do not run new tests here; missing
   evidence sends you back to the relevant Phase 10 step.
2. **Walk the pre-launch checklist** — Confirm every area below before anyone makes a go/no-go call.
3. **Prepare the Phase 11/12 handoff** — With a green checklist, record what Phase 11 must re-verify and what
   Phase 12 must execute later. Do **not** deploy production here.

:::note[User part + done-when]
**👤 User part** — a person accepts the GO / CONDITIONAL GO / NO-GO verdict and accepts any advisory risk. The agent verifies evidence and writes the handoff, but Phase 10 does not authorize production deploy, live payments, or the 24–48h production watch.

**Done when** the consolidated verdict is recorded in `Zaj-PROGRESS.md`, every checklist area is green with zero unresolved high-risk items, every deferred polish row is routed to `Zaj-BACKLOG.md`, and the Phase 11/12 handoff clearly states what can advance and what remains blocked. &nbsp;·&nbsp; **⏱ ~45 min** &nbsp;·&nbsp; 🔀 mixed (👤 verdict/advisory acceptance, 🤖 verification + handoff).
:::

## Background

The final gate. Phase 10 is not done until the static, deep, and functional audit evidence is consolidated into a single verdict. Everything before this phase fed into one decision — whether the app is ready for paying users.

## Steps

### 1. Consolidated verdict

Synthesize the existing audit evidence. Do **not** run new tests here; missing evidence sends you back to the relevant Phase 10 step.

Confirm these three sub-reports exist in `Admin-Local/1-Project/4-Audit-Reports/` before producing the verdict:

- `YYYY-MM-DD-phase-10-A-security.md`
- `YYYY-MM-DD-phase-10-B-perf-db-seo-a11y-cookies.md`
- `YYYY-MM-DD-phase-10-C-testing-debugger.md`

| # | Dimension | Evidence source | Verdict |
|---:|---|---|---|
| 1 | Code quality / static audit | Phase 10 static audit | Green / advisory / blocker |
| 2 | Composer CVEs | Phase 10 static audit | Green / advisory / blocker |
| 3 | Git hygiene + per-environment state | Phase 10 static audit | Green / advisory / blocker |
| 4 | Secrets and env exposure | Phase 10 static audit | Green / advisory / blocker |
| 5 | Production config / debug state | Phase 10 security audit | Green / advisory / blocker |
| 6 | Default admin credential rotation | Phase 10 security audit | Green / advisory / blocker |
| 7 | Demo content, vendor creds, and vendor-integrity scan | Phase 10 security audit | Green / advisory / blocker |
| 8 | Headers, TLS, and exposed files | Phase 10 security audit | Green / advisory / blocker |
| 9 | Storage, admin, and upload exposure | Phase 10 security audit | Green / advisory / blocker |
| 10 | Runtime auth, rate limits, and IDOR checks | Phase 10 functional QA | Green / advisory / blocker |
| 11 | Core Web Vitals / LCP | Phase 10 performance audit | Green / advisory / blocker |
| 12 | Database indexes, slow queries, and N+1 checks | Phase 10 DB audit | Green / advisory / blocker |
| 13 | SEO indexing, canonical, robots, and sitemap | Phase 10 SEO audit | Green / advisory / blocker |
| 14 | Accessibility | Phase 10 accessibility audit | Green / advisory / blocker |
| 15 | Cookies, consent, and privacy links | Phase 10 cookies audit | Green / advisory / blocker |
| 16 | Functional golden paths | Phase 10 functional QA | Green / advisory / blocker |
| 17 | Payment lifecycle | Phase 10 functional QA | Green / advisory / blocker |
| 18 | Transactional email delivery | Phase 10 functional QA | Green / advisory / blocker |
| 19 | Debugger/log review | Phase 10 functional QA | Green / advisory / blocker |
| 20 | Monitoring data received | `Admin-Local/1-Project/1-Info/monitoring-state.md` | Green / advisory / blocker |
| 21 | Backup and rollback readiness | Phase 7 + launch checklist | Green / advisory / blocker |
| 22 | Open follow-ups classified | `Zaj-BACKLOG.md` audit deferrals | Green / advisory / blocker |

Classify every unresolved item as one of:

- **Blocker** — launch cannot proceed.
- **Advisory** — launch can proceed only if the user explicitly accepts the risk.
- **Deferred to `Zaj-BACKLOG.md`** — low severity or multi-hour vendor-template deferrals, such as lazy-load sweeps or bulk alt-text work.

:::danger[Vendor seed-surface sweep blocks GO]
🔴 Vendor seed-surface sweep (blocks GO): confirm the default admin credentials were rotated (no `admin@example.com` / vendor default), all demo users + demo content are removed, and vendor-shipped encrypted creds/keys are not live. For CodeCanyon apps, re-run the vendor-integrity scan (license-beacon / injected-script grep — a vendor update since Phase 6 can re-introduce it). Any survivor = **NO-GO**.
:::

| Verdict | Meaning |
|---|---|
| **GO** | All 22 rows are nonblank, zero blockers remain, advisories are explicitly accepted, and Phase 11 can start. Production deploy still waits for Phase 12. |
| **CONDITIONAL GO** | No blockers remain, but one or more advisories need named owner/date follow-up before or immediately after launch. |
| **NO-GO** | Any blocker remains, the vendor seed-surface sweep fails, reports are missing, or staging proof is incomplete. |

Before stamping **GO**, confirm all of the following:

- All 22 rows are filled in.
- Rows 6 and 7 pass; any default admin, demo data, vendor credential, license beacon, or injected-script survivor is **NO-GO**.
- Zero red/blocker rows remain.
- Every advisory is accepted by the user with owner + review date.
- At least one functional end-to-end golden path passed on the selected launch-candidate environment today.
- `Admin-Local/1-Project/1-Info/monitoring-state.md` shows monitoring data is being received or a row is marked N/A with reason.
- `Zaj-PROGRESS.md` logs the verdict, date, signer, and path to the consolidated report.
- `Zaj-BACKLOG.md` rows from the deferred items carry source, severity, effort, trigger, and acceptance criterion — no disguised blockers ("defer" for a production breaker = **NO-GO**) and no vague/no-trigger rows.

Write the consolidated report to `Admin-Local/1-Project/4-Audit-Reports/YYYY-MM-DD-phase-10-CONSOLIDATED.md`. Phase 11's first step transfers the `📋 Deferred to Zaj-BACKLOG.md` rows into root `Zaj-BACKLOG.md`.

### 2. Walk the pre-launch checklist

Confirm every area below before anyone makes a go/no-go call.

| Area | Verify |
|---|---|
| Blockers | No unresolved HIGH / open ISSUE / SECURITY items in `Zaj-BACKLOG.md` or the Phase 10 audit reports |
| Infrastructure | SSL > 30 days, DNS + www resolve, CDN proxy on, SSL mode Full (strict) |
| Security | `APP_DEBUG=false`, `.env` returns 403/404, no debug toolbar, **Grade A** headers (securityheaders.com) + **SSL Labs (TLS)** A/A+ |
| Monitoring | Error tracking captures a test event, uptime monitor + backups verified |
| Payments | Staging/test payment path passed, production keys/webhook are vaulted and scoped, and the Phase 11/12 human live-charge/refund gate is named |
| Communications | Inbox-delivered welcome/reset/invoice emails, chat widget live |
| Legal | Privacy, Terms, Cookie, Refund pages published + linked; consent banner enforced |
| Content | No placeholder text, favicon, OG/meta, sitemap, `robots.txt` correct |
| Team readiness | Admin creds in a vault with 2FA, rollback documented, 24h monitor assigned |

:::note[Who does this]
👤 **User** makes the go/no-go sign-off — a launch authorization only a person can give. 🤖 **Agent** verifies the technical items (headers, `.env` blocking, webhook config) and reports status per area.
:::

<Steps>

1. **Verify every area, then make the go/no-go call.** If any high-risk item is unresolved, **do not launch**.

   - ✅ All nine areas are green with zero unresolved HIGH / SECURITY items, and the sign-off is recorded.

</Steps>

### 3. Prepare the Phase 11/12 handoff

With a green checklist, write the handoff that tells the next phases exactly what to re-verify and what not to run yet.

:::note[Who does this]
🔀 **User + Agent** — the agent writes the handoff and reconciles trackers; 👤 **User** accepts the verdict/advisories. Production backup, release tag, deploy, live payment, go-live, and the 24–48h production watch are Phase 12 actions.
:::

<Steps>

1. **Write the handoff inside the consolidated report and update trackers.** The consolidated report must end with a short "Next-phase handoff" section.

   ```markdown
   ## Next-phase handoff

   Verdict: GO | CONDITIONAL GO | NO-GO
   Phase 11 may start: yes/no
   Phase 12 production deploy may start now: no — wait for Phase 11 signoff and Phase 12 Task P.0

   Phase 11 re-verifies:
   - Technical readiness gates
   - Business/legal readiness
   - Support/onboarding readiness
   - Tiered go/no-go

   Phase 12 executes later:
   - production secret rotation/preflight
   - production backup/tag/release branch/deploy
   - live installer/auth checks
   - production seed-surface sweep
   - 24–48h production monitor

   Blockers:
   - none | list each blocker with owner and required proof

   Deferred polish transferred to Zaj-BACKLOG.md:
   - list each row source/severity/effort/trigger/acceptance
   ```

   ```bash
   grep -n "Next-phase handoff" Admin-Local/1-Project/4-Audit-Reports/*phase-10-CONSOLIDATED.md
   grep -n "Phase 10-CONSOLIDATED" Zaj-PROGRESS.md
   grep -n "Deferred to Zaj-BACKLOG.md" Zaj-BACKLOG.md
   # Expected: consolidated report includes the handoff, Zaj-PROGRESS.md links the verdict,
   # and every deferred-polish row landed in Zaj-BACKLOG.md.
   ```

   :::caution[Do not run production from Phase 10]
   No `git tag`, production DB dump, release-branch merge, `dep deploy production`, live payment charge, go-live switch, or production 24–48h watch runs here. Those are Phase 12 actions after Phase 11 and Phase 12 Task P.0 clear.
   :::

   - ✅ The consolidated report contains the next-phase handoff, `Zaj-PROGRESS.md` links the verdict, and every deferred polish row is in `Zaj-BACKLOG.md`.

</Steps>

## Checklist

Do not mark this step done until **every** box below is checked.

- [ ] **🤖 Blockers clear** — no unresolved HIGH / open ISSUE / SECURITY items in `Zaj-BACKLOG.md` or the Phase 10 audit reports.
- [ ] **🔀 Consolidated verdict recorded** — all 22 rows complete, verdict written to `Admin-Local/1-Project/4-Audit-Reports/YYYY-MM-DD-phase-10-CONSOLIDATED.md`, and `Zaj-PROGRESS.md` links it.
- [ ] **🤖 Infrastructure ready** — SSL > 30 days, DNS + www resolve, CDN proxy on, SSL mode Full (strict).
- [ ] **🤖 Security verified** — `APP_DEBUG=false`, `.env` returns 403/404, no debug toolbar; **Grade A** at securityheaders.com; **SSL Labs (TLS)** A or A+.
- [ ] **🤖 Vendor seed-surface sweep** — default admin credentials rotated, demo users/content removed, vendor-shipped encrypted creds/keys absent, and vendor-integrity scan clean; any survivor = NO-GO.
- [ ] **🤖 Monitoring live** — error tracking captures a test event, uptime monitor + backups verified.
- [ ] **🔀 Payments ready** — staging/test path passed; production keys/webhook are vaulted/scoped; live charge + refund are explicitly named as the later human gate.
- [ ] **🤖 Communications working** — inbox-delivered welcome/reset/invoice emails, chat widget live.
- [ ] **🤖 Legal published** — Privacy, Terms, Cookie, Refund pages published + linked; consent banner enforced.
- [ ] **🤖 Content complete** — no placeholder text, favicon, OG/meta, sitemap, `robots.txt` correct.
- [ ] **🔀 Handoff ready** — admin creds vaulted with 2FA, rollback documented, 24h monitor owner named, and the Phase 11/12 handoff is recorded.

:::next[Next step]
[Phase 11 · Pre-customer verification](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/11-pre-customer/)
:::

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.

TL;DR

Objective — synthesize the Phase 10 sub-reports into one GO / CONDITIONAL GO / NO-GO verdict, then prepare the Phase 11/12 handoff — the final audit gate where any unresolved high-risk item means do not advance.

Steps at a glance:

Consolidated verdict — Synthesize the existing audit evidence. Do not run new tests here; missing evidence sends you back to the relevant Phase 10 step.
Walk the pre-launch checklist — Confirm every area below before anyone makes a go/no-go call.
Prepare the Phase 11/12 handoff — With a green checklist, record what Phase 11 must re-verify and what Phase 12 must execute later. Do not deploy production here.

Background

The final gate. Phase 10 is not done until the static, deep, and functional audit evidence is consolidated into a single verdict. Everything before this phase fed into one decision — whether the app is ready for paying users.

Steps

1. Consolidated verdict

Synthesize the existing audit evidence. Do not run new tests here; missing evidence sends you back to the relevant Phase 10 step.

Confirm these three sub-reports exist in Admin-Local/1-Project/4-Audit-Reports/ before producing the verdict:

YYYY-MM-DD-phase-10-A-security.md
YYYY-MM-DD-phase-10-B-perf-db-seo-a11y-cookies.md
YYYY-MM-DD-phase-10-C-testing-debugger.md

#	Dimension	Evidence source	Verdict
1	Code quality / static audit	Phase 10 static audit	Green / advisory / blocker
2	Composer CVEs	Phase 10 static audit	Green / advisory / blocker
3	Git hygiene + per-environment state	Phase 10 static audit	Green / advisory / blocker
4	Secrets and env exposure	Phase 10 static audit	Green / advisory / blocker
5	Production config / debug state	Phase 10 security audit	Green / advisory / blocker
6	Default admin credential rotation	Phase 10 security audit	Green / advisory / blocker
7	Demo content, vendor creds, and vendor-integrity scan	Phase 10 security audit	Green / advisory / blocker
8	Headers, TLS, and exposed files	Phase 10 security audit	Green / advisory / blocker
9	Storage, admin, and upload exposure	Phase 10 security audit	Green / advisory / blocker
10	Runtime auth, rate limits, and IDOR checks	Phase 10 functional QA	Green / advisory / blocker
11	Core Web Vitals / LCP	Phase 10 performance audit	Green / advisory / blocker
12	Database indexes, slow queries, and N+1 checks	Phase 10 DB audit	Green / advisory / blocker
13	SEO indexing, canonical, robots, and sitemap	Phase 10 SEO audit	Green / advisory / blocker
14	Accessibility	Phase 10 accessibility audit	Green / advisory / blocker
15	Cookies, consent, and privacy links	Phase 10 cookies audit	Green / advisory / blocker
16	Functional golden paths	Phase 10 functional QA	Green / advisory / blocker
17	Payment lifecycle	Phase 10 functional QA	Green / advisory / blocker
18	Transactional email delivery	Phase 10 functional QA	Green / advisory / blocker
19	Debugger/log review	Phase 10 functional QA	Green / advisory / blocker
20	Monitoring data received	`Admin-Local/1-Project/1-Info/monitoring-state.md`	Green / advisory / blocker
21	Backup and rollback readiness	Phase 7 + launch checklist	Green / advisory / blocker
22	Open follow-ups classified	`Zaj-BACKLOG.md` audit deferrals	Green / advisory / blocker

Classify every unresolved item as one of:

Blocker — launch cannot proceed.
Advisory — launch can proceed only if the user explicitly accepts the risk.
Deferred to Zaj-BACKLOG.md — low severity or multi-hour vendor-template deferrals, such as lazy-load sweeps or bulk alt-text work.

Verdict	Meaning
GO	All 22 rows are nonblank, zero blockers remain, advisories are explicitly accepted, and Phase 11 can start. Production deploy still waits for Phase 12.
CONDITIONAL GO	No blockers remain, but one or more advisories need named owner/date follow-up before or immediately after launch.
NO-GO	Any blocker remains, the vendor seed-surface sweep fails, reports are missing, or staging proof is incomplete.

Before stamping GO, confirm all of the following:

All 22 rows are filled in.
Rows 6 and 7 pass; any default admin, demo data, vendor credential, license beacon, or injected-script survivor is NO-GO.
Zero red/blocker rows remain.
Every advisory is accepted by the user with owner + review date.
At least one functional end-to-end golden path passed on the selected launch-candidate environment today.
Admin-Local/1-Project/1-Info/monitoring-state.md shows monitoring data is being received or a row is marked N/A with reason.
Zaj-PROGRESS.md logs the verdict, date, signer, and path to the consolidated report.
Zaj-BACKLOG.md rows from the deferred items carry source, severity, effort, trigger, and acceptance criterion — no disguised blockers (“defer” for a production breaker = NO-GO) and no vague/no-trigger rows.

Write the consolidated report to Admin-Local/1-Project/4-Audit-Reports/YYYY-MM-DD-phase-10-CONSOLIDATED.md. Phase 11’s first step transfers the 📋 Deferred to Zaj-BACKLOG.md rows into root Zaj-BACKLOG.md.

2. Walk the pre-launch checklist

Confirm every area below before anyone makes a go/no-go call.

Area	Verify
Blockers	No unresolved HIGH / open ISSUE / SECURITY items in `Zaj-BACKLOG.md` or the Phase 10 audit reports
Infrastructure	SSL > 30 days, DNS + www resolve, CDN proxy on, SSL mode Full (strict)
Security	`APP_DEBUG=false`, `.env` returns 403/404, no debug toolbar, Grade A headers (securityheaders.com) + SSL Labs (TLS) A/A+
Monitoring	Error tracking captures a test event, uptime monitor + backups verified
Payments	Staging/test payment path passed, production keys/webhook are vaulted and scoped, and the Phase 11/12 human live-charge/refund gate is named
Communications	Inbox-delivered welcome/reset/invoice emails, chat widget live
Legal	Privacy, Terms, Cookie, Refund pages published + linked; consent banner enforced
Content	No placeholder text, favicon, OG/meta, sitemap, `robots.txt` correct
Team readiness	Admin creds in a vault with 2FA, rollback documented, 24h monitor assigned

Verify every area, then make the go/no-go call. If any high-risk item is unresolved, do not launch.
- ✅ All nine areas are green with zero unresolved HIGH / SECURITY items, and the sign-off is recorded.

3. Prepare the Phase 11/12 handoff

With a green checklist, write the handoff that tells the next phases exactly what to re-verify and what not to run yet.

Write the handoff inside the consolidated report and update trackers. The consolidated report must end with a short “Next-phase handoff” section.

## Next-phase handoff

Verdict: GO | CONDITIONAL GO | NO-GO
Phase 11 may start: yes/no
Phase 12 production deploy may start now: no — wait for Phase 11 signoff and Phase 12 Task P.0

Phase 11 re-verifies:
- Technical readiness gates
- Business/legal readiness
- Support/onboarding readiness
- Tiered go/no-go

Phase 12 executes later:
- production secret rotation/preflight
- production backup/tag/release branch/deploy
- live installer/auth checks
- production seed-surface sweep
- 24–48h production monitor

Blockers:
- none | list each blocker with owner and required proof

Deferred polish transferred to Zaj-BACKLOG.md:
- list each row source/severity/effort/trigger/acceptance

grep -n "Next-phase handoff" Admin-Local/1-Project/4-Audit-Reports/*phase-10-CONSOLIDATED.md
grep -n "Phase 10-CONSOLIDATED" Zaj-PROGRESS.md
grep -n "Deferred to Zaj-BACKLOG.md" Zaj-BACKLOG.md
# Expected: consolidated report includes the handoff, Zaj-PROGRESS.md links the verdict,
# and every deferred-polish row landed in Zaj-BACKLOG.md.

✅ The consolidated report contains the next-phase handoff, Zaj-PROGRESS.md links the verdict, and every deferred polish row is in Zaj-BACKLOG.md.

Checklist

Do not mark this step done until every box below is checked.

Phase 11 · Pre-customer verification

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.

# ZajLibrary — implementation playbook

You are a **senior implementation assistant** working inside the user’s real development environment (terminal, editor, git repo). You are **not** a documentation writer, tutor, or library editor.

**Mission:** Execute the procedure described below in the user’s real project workspace — create or modify the files and run the commands it specifies. Do not just summarize it.

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 👤.

## Metadata
- title: 6 · Consolidated verdict & launch handoff
- url: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/10-audit-qa/06-sign-off/
- shelf: Build & Create
- doc_type: implementation playbook
- status: current
- kind: playbook
- category: tech-stack
- subcategory: laravel
- topic: codecanyon
- phase: 10
- part_number: 6 (legacy stepNumber frontmatter)
- legacy_step_number: 6
- est_time: ~45 min
- description: Synthesize the Phase 10 sub-reports into one GO / CONDITIONAL GO / NO-GO verdict, then prepare the Phase 11/12 handoff without running the production launch.
- tags: codecanyon, laravel, launch, checklist

## Execution rules (binding)
- This is Part 6 of phase 10 (~45 min) — execute this Part fully, then stop at its `## Checklist`.
- 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.
- For playbooks, treat a Part as the `.mdx` page-level execution unit and each item in `## Steps` as a Step inside that Part.
- Follow `## Steps` in order. Do not skip Steps or declare the work complete early.
- Respect `:::note[Who does this]`: 👤 **User** steps (authentication, account creation, password/secret entry, paid/provider dashboards, destructive actions) need the human; 🤖 **Agent** steps you run in the shell or browser after the authenticated session exists.
- After every command, compare its output to the `# Expected:` comment or ✅ bullet beneath it. If it differs, investigate safely and reconcile from evidence first; ask only when the mismatch creates a real human gate, destructive risk, security risk, or equally valid choices.
- Honor `:::caution` / `:::note` callouts as hard gates (a step may forbid a command at this stage).
- Do not mark the Part done until every `## Checklist` item is genuinely satisfied.
- Scope: implement only what this Part describes — no refactors, added features, or later-phase work unless the Part says so.
- When the work changes project state, update the relevant progress/customization/feedback ledger yourself; do not ask whether routine state tracking should be updated.
- When reporting progress, cite the `##` / `###` headings you completed or got blocked on.
- Secrets: never put API keys, passwords, or `.env` values in frontend code, commits, or chat logs — use server-side `.env` / config only, and keep `.env` gitignored.
- 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.

---

# 6 · Consolidated verdict & launch handoff

## TL;DR

**Objective** — synthesize the Phase 10 sub-reports into one **GO / CONDITIONAL GO / NO-GO** verdict, then prepare the Phase 11/12 handoff — the final audit gate where any unresolved high-risk item means **do not advance**.

**Steps at a glance:**
1. **Consolidated verdict** — Synthesize the existing audit evidence. Do not run new tests here; missing
   evidence sends you back to the relevant Phase 10 step.
2. **Walk the pre-launch checklist** — Confirm every area below before anyone makes a go/no-go call.
3. **Prepare the Phase 11/12 handoff** — With a green checklist, record what Phase 11 must re-verify and what
   Phase 12 must execute later. Do **not** deploy production here.

:::note[User part + done-when]
**👤 User part** — a person accepts the GO / CONDITIONAL GO / NO-GO verdict and accepts any advisory risk. The agent verifies evidence and writes the handoff, but Phase 10 does not authorize production deploy, live payments, or the 24–48h production watch.

**Done when** the consolidated verdict is recorded in `Zaj-PROGRESS.md`, every checklist area is green with zero unresolved high-risk items, every deferred polish row is routed to `Zaj-BACKLOG.md`, and the Phase 11/12 handoff clearly states what can advance and what remains blocked. &nbsp;·&nbsp; **⏱ ~45 min** &nbsp;·&nbsp; 🔀 mixed (👤 verdict/advisory acceptance, 🤖 verification + handoff).
:::

## Background

The final gate. Phase 10 is not done until the static, deep, and functional audit evidence is consolidated into a single verdict. Everything before this phase fed into one decision — whether the app is ready for paying users.

## Steps

### 1. Consolidated verdict

Synthesize the existing audit evidence. Do **not** run new tests here; missing evidence sends you back to the relevant Phase 10 step.

Confirm these three sub-reports exist in `Admin-Local/1-Project/4-Audit-Reports/` before producing the verdict:

- `YYYY-MM-DD-phase-10-A-security.md`
- `YYYY-MM-DD-phase-10-B-perf-db-seo-a11y-cookies.md`
- `YYYY-MM-DD-phase-10-C-testing-debugger.md`

| # | Dimension | Evidence source | Verdict |
|---:|---|---|---|
| 1 | Code quality / static audit | Phase 10 static audit | Green / advisory / blocker |
| 2 | Composer CVEs | Phase 10 static audit | Green / advisory / blocker |
| 3 | Git hygiene + per-environment state | Phase 10 static audit | Green / advisory / blocker |
| 4 | Secrets and env exposure | Phase 10 static audit | Green / advisory / blocker |
| 5 | Production config / debug state | Phase 10 security audit | Green / advisory / blocker |
| 6 | Default admin credential rotation | Phase 10 security audit | Green / advisory / blocker |
| 7 | Demo content, vendor creds, and vendor-integrity scan | Phase 10 security audit | Green / advisory / blocker |
| 8 | Headers, TLS, and exposed files | Phase 10 security audit | Green / advisory / blocker |
| 9 | Storage, admin, and upload exposure | Phase 10 security audit | Green / advisory / blocker |
| 10 | Runtime auth, rate limits, and IDOR checks | Phase 10 functional QA | Green / advisory / blocker |
| 11 | Core Web Vitals / LCP | Phase 10 performance audit | Green / advisory / blocker |
| 12 | Database indexes, slow queries, and N+1 checks | Phase 10 DB audit | Green / advisory / blocker |
| 13 | SEO indexing, canonical, robots, and sitemap | Phase 10 SEO audit | Green / advisory / blocker |
| 14 | Accessibility | Phase 10 accessibility audit | Green / advisory / blocker |
| 15 | Cookies, consent, and privacy links | Phase 10 cookies audit | Green / advisory / blocker |
| 16 | Functional golden paths | Phase 10 functional QA | Green / advisory / blocker |
| 17 | Payment lifecycle | Phase 10 functional QA | Green / advisory / blocker |
| 18 | Transactional email delivery | Phase 10 functional QA | Green / advisory / blocker |
| 19 | Debugger/log review | Phase 10 functional QA | Green / advisory / blocker |
| 20 | Monitoring data received | `Admin-Local/1-Project/1-Info/monitoring-state.md` | Green / advisory / blocker |
| 21 | Backup and rollback readiness | Phase 7 + launch checklist | Green / advisory / blocker |
| 22 | Open follow-ups classified | `Zaj-BACKLOG.md` audit deferrals | Green / advisory / blocker |

Classify every unresolved item as one of:

- **Blocker** — launch cannot proceed.
- **Advisory** — launch can proceed only if the user explicitly accepts the risk.
- **Deferred to `Zaj-BACKLOG.md`** — low severity or multi-hour vendor-template deferrals, such as lazy-load sweeps or bulk alt-text work.

:::danger[Vendor seed-surface sweep blocks GO]
🔴 Vendor seed-surface sweep (blocks GO): confirm the default admin credentials were rotated (no `admin@example.com` / vendor default), all demo users + demo content are removed, and vendor-shipped encrypted creds/keys are not live. For CodeCanyon apps, re-run the vendor-integrity scan (license-beacon / injected-script grep — a vendor update since Phase 6 can re-introduce it). Any survivor = **NO-GO**.
:::

| Verdict | Meaning |
|---|---|
| **GO** | All 22 rows are nonblank, zero blockers remain, advisories are explicitly accepted, and Phase 11 can start. Production deploy still waits for Phase 12. |
| **CONDITIONAL GO** | No blockers remain, but one or more advisories need named owner/date follow-up before or immediately after launch. |
| **NO-GO** | Any blocker remains, the vendor seed-surface sweep fails, reports are missing, or staging proof is incomplete. |

Before stamping **GO**, confirm all of the following:

- All 22 rows are filled in.
- Rows 6 and 7 pass; any default admin, demo data, vendor credential, license beacon, or injected-script survivor is **NO-GO**.
- Zero red/blocker rows remain.
- Every advisory is accepted by the user with owner + review date.
- At least one functional end-to-end golden path passed on the selected launch-candidate environment today.
- `Admin-Local/1-Project/1-Info/monitoring-state.md` shows monitoring data is being received or a row is marked N/A with reason.
- `Zaj-PROGRESS.md` logs the verdict, date, signer, and path to the consolidated report.
- `Zaj-BACKLOG.md` rows from the deferred items carry source, severity, effort, trigger, and acceptance criterion — no disguised blockers ("defer" for a production breaker = **NO-GO**) and no vague/no-trigger rows.

Write the consolidated report to `Admin-Local/1-Project/4-Audit-Reports/YYYY-MM-DD-phase-10-CONSOLIDATED.md`. Phase 11's first step transfers the `📋 Deferred to Zaj-BACKLOG.md` rows into root `Zaj-BACKLOG.md`.

### 2. Walk the pre-launch checklist

Confirm every area below before anyone makes a go/no-go call.

| Area | Verify |
|---|---|
| Blockers | No unresolved HIGH / open ISSUE / SECURITY items in `Zaj-BACKLOG.md` or the Phase 10 audit reports |
| Infrastructure | SSL > 30 days, DNS + www resolve, CDN proxy on, SSL mode Full (strict) |
| Security | `APP_DEBUG=false`, `.env` returns 403/404, no debug toolbar, **Grade A** headers (securityheaders.com) + **SSL Labs (TLS)** A/A+ |
| Monitoring | Error tracking captures a test event, uptime monitor + backups verified |
| Payments | Staging/test payment path passed, production keys/webhook are vaulted and scoped, and the Phase 11/12 human live-charge/refund gate is named |
| Communications | Inbox-delivered welcome/reset/invoice emails, chat widget live |
| Legal | Privacy, Terms, Cookie, Refund pages published + linked; consent banner enforced |
| Content | No placeholder text, favicon, OG/meta, sitemap, `robots.txt` correct |
| Team readiness | Admin creds in a vault with 2FA, rollback documented, 24h monitor assigned |

:::note[Who does this]
👤 **User** makes the go/no-go sign-off — a launch authorization only a person can give. 🤖 **Agent** verifies the technical items (headers, `.env` blocking, webhook config) and reports status per area.
:::

<Steps>

1. **Verify every area, then make the go/no-go call.** If any high-risk item is unresolved, **do not launch**.

   - ✅ All nine areas are green with zero unresolved HIGH / SECURITY items, and the sign-off is recorded.

</Steps>

### 3. Prepare the Phase 11/12 handoff

With a green checklist, write the handoff that tells the next phases exactly what to re-verify and what not to run yet.

:::note[Who does this]
🔀 **User + Agent** — the agent writes the handoff and reconciles trackers; 👤 **User** accepts the verdict/advisories. Production backup, release tag, deploy, live payment, go-live, and the 24–48h production watch are Phase 12 actions.
:::

<Steps>

1. **Write the handoff inside the consolidated report and update trackers.** The consolidated report must end with a short "Next-phase handoff" section.

   ```markdown
   ## Next-phase handoff

   Verdict: GO | CONDITIONAL GO | NO-GO
   Phase 11 may start: yes/no
   Phase 12 production deploy may start now: no — wait for Phase 11 signoff and Phase 12 Task P.0

   Phase 11 re-verifies:
   - Technical readiness gates
   - Business/legal readiness
   - Support/onboarding readiness
   - Tiered go/no-go

   Phase 12 executes later:
   - production secret rotation/preflight
   - production backup/tag/release branch/deploy
   - live installer/auth checks
   - production seed-surface sweep
   - 24–48h production monitor

   Blockers:
   - none | list each blocker with owner and required proof

   Deferred polish transferred to Zaj-BACKLOG.md:
   - list each row source/severity/effort/trigger/acceptance
   ```

   ```bash
   grep -n "Next-phase handoff" Admin-Local/1-Project/4-Audit-Reports/*phase-10-CONSOLIDATED.md
   grep -n "Phase 10-CONSOLIDATED" Zaj-PROGRESS.md
   grep -n "Deferred to Zaj-BACKLOG.md" Zaj-BACKLOG.md
   # Expected: consolidated report includes the handoff, Zaj-PROGRESS.md links the verdict,
   # and every deferred-polish row landed in Zaj-BACKLOG.md.
   ```

   :::caution[Do not run production from Phase 10]
   No `git tag`, production DB dump, release-branch merge, `dep deploy production`, live payment charge, go-live switch, or production 24–48h watch runs here. Those are Phase 12 actions after Phase 11 and Phase 12 Task P.0 clear.
   :::

   - ✅ The consolidated report contains the next-phase handoff, `Zaj-PROGRESS.md` links the verdict, and every deferred polish row is in `Zaj-BACKLOG.md`.

</Steps>

## Checklist

Do not mark this step done until **every** box below is checked.

- [ ] **🤖 Blockers clear** — no unresolved HIGH / open ISSUE / SECURITY items in `Zaj-BACKLOG.md` or the Phase 10 audit reports.
- [ ] **🔀 Consolidated verdict recorded** — all 22 rows complete, verdict written to `Admin-Local/1-Project/4-Audit-Reports/YYYY-MM-DD-phase-10-CONSOLIDATED.md`, and `Zaj-PROGRESS.md` links it.
- [ ] **🤖 Infrastructure ready** — SSL > 30 days, DNS + www resolve, CDN proxy on, SSL mode Full (strict).
- [ ] **🤖 Security verified** — `APP_DEBUG=false`, `.env` returns 403/404, no debug toolbar; **Grade A** at securityheaders.com; **SSL Labs (TLS)** A or A+.
- [ ] **🤖 Vendor seed-surface sweep** — default admin credentials rotated, demo users/content removed, vendor-shipped encrypted creds/keys absent, and vendor-integrity scan clean; any survivor = NO-GO.
- [ ] **🤖 Monitoring live** — error tracking captures a test event, uptime monitor + backups verified.
- [ ] **🔀 Payments ready** — staging/test path passed; production keys/webhook are vaulted/scoped; live charge + refund are explicitly named as the later human gate.
- [ ] **🤖 Communications working** — inbox-delivered welcome/reset/invoice emails, chat widget live.
- [ ] **🤖 Legal published** — Privacy, Terms, Cookie, Refund pages published + linked; consent banner enforced.
- [ ] **🤖 Content complete** — no placeholder text, favicon, OG/meta, sitemap, `robots.txt` correct.
- [ ] **🔀 Handoff ready** — admin creds vaulted with 2FA, rollback documented, 24h monitor owner named, and the Phase 11/12 handoff is recorded.

:::next[Next step]
[Phase 11 · Pre-customer verification](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/11-pre-customer/)
:::

# 6 · Consolidated verdict & launch handoff

> Source: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/10-audit-qa/06-sign-off/

## TL;DR

**Objective** — synthesize the Phase 10 sub-reports into one **GO / CONDITIONAL GO / NO-GO** verdict, then prepare the Phase 11/12 handoff — the final audit gate where any unresolved high-risk item means **do not advance**.

**Steps at a glance:**
1. **Consolidated verdict** — Synthesize the existing audit evidence. Do not run new tests here; missing
   evidence sends you back to the relevant Phase 10 step.
2. **Walk the pre-launch checklist** — Confirm every area below before anyone makes a go/no-go call.
3. **Prepare the Phase 11/12 handoff** — With a green checklist, record what Phase 11 must re-verify and what
   Phase 12 must execute later. Do **not** deploy production here.

:::note[User part + done-when]
**👤 User part** — a person accepts the GO / CONDITIONAL GO / NO-GO verdict and accepts any advisory risk. The agent verifies evidence and writes the handoff, but Phase 10 does not authorize production deploy, live payments, or the 24–48h production watch.

**Done when** the consolidated verdict is recorded in `Zaj-PROGRESS.md`, every checklist area is green with zero unresolved high-risk items, every deferred polish row is routed to `Zaj-BACKLOG.md`, and the Phase 11/12 handoff clearly states what can advance and what remains blocked. &nbsp;·&nbsp; **⏱ ~45 min** &nbsp;·&nbsp; 🔀 mixed (👤 verdict/advisory acceptance, 🤖 verification + handoff).
:::

## Background

The final gate. Phase 10 is not done until the static, deep, and functional audit evidence is consolidated into a single verdict. Everything before this phase fed into one decision — whether the app is ready for paying users.

## Steps

### 1. Consolidated verdict

Synthesize the existing audit evidence. Do **not** run new tests here; missing evidence sends you back to the relevant Phase 10 step.

Confirm these three sub-reports exist in `Admin-Local/1-Project/4-Audit-Reports/` before producing the verdict:

- `YYYY-MM-DD-phase-10-A-security.md`
- `YYYY-MM-DD-phase-10-B-perf-db-seo-a11y-cookies.md`
- `YYYY-MM-DD-phase-10-C-testing-debugger.md`

| # | Dimension | Evidence source | Verdict |
|---:|---|---|---|
| 1 | Code quality / static audit | Phase 10 static audit | Green / advisory / blocker |
| 2 | Composer CVEs | Phase 10 static audit | Green / advisory / blocker |
| 3 | Git hygiene + per-environment state | Phase 10 static audit | Green / advisory / blocker |
| 4 | Secrets and env exposure | Phase 10 static audit | Green / advisory / blocker |
| 5 | Production config / debug state | Phase 10 security audit | Green / advisory / blocker |
| 6 | Default admin credential rotation | Phase 10 security audit | Green / advisory / blocker |
| 7 | Demo content, vendor creds, and vendor-integrity scan | Phase 10 security audit | Green / advisory / blocker |
| 8 | Headers, TLS, and exposed files | Phase 10 security audit | Green / advisory / blocker |
| 9 | Storage, admin, and upload exposure | Phase 10 security audit | Green / advisory / blocker |
| 10 | Runtime auth, rate limits, and IDOR checks | Phase 10 functional QA | Green / advisory / blocker |
| 11 | Core Web Vitals / LCP | Phase 10 performance audit | Green / advisory / blocker |
| 12 | Database indexes, slow queries, and N+1 checks | Phase 10 DB audit | Green / advisory / blocker |
| 13 | SEO indexing, canonical, robots, and sitemap | Phase 10 SEO audit | Green / advisory / blocker |
| 14 | Accessibility | Phase 10 accessibility audit | Green / advisory / blocker |
| 15 | Cookies, consent, and privacy links | Phase 10 cookies audit | Green / advisory / blocker |
| 16 | Functional golden paths | Phase 10 functional QA | Green / advisory / blocker |
| 17 | Payment lifecycle | Phase 10 functional QA | Green / advisory / blocker |
| 18 | Transactional email delivery | Phase 10 functional QA | Green / advisory / blocker |
| 19 | Debugger/log review | Phase 10 functional QA | Green / advisory / blocker |
| 20 | Monitoring data received | `Admin-Local/1-Project/1-Info/monitoring-state.md` | Green / advisory / blocker |
| 21 | Backup and rollback readiness | Phase 7 + launch checklist | Green / advisory / blocker |
| 22 | Open follow-ups classified | `Zaj-BACKLOG.md` audit deferrals | Green / advisory / blocker |

Classify every unresolved item as one of:

- **Blocker** — launch cannot proceed.
- **Advisory** — launch can proceed only if the user explicitly accepts the risk.
- **Deferred to `Zaj-BACKLOG.md`** — low severity or multi-hour vendor-template deferrals, such as lazy-load sweeps or bulk alt-text work.

:::danger[Vendor seed-surface sweep blocks GO]
🔴 Vendor seed-surface sweep (blocks GO): confirm the default admin credentials were rotated (no `admin@example.com` / vendor default), all demo users + demo content are removed, and vendor-shipped encrypted creds/keys are not live. For CodeCanyon apps, re-run the vendor-integrity scan (license-beacon / injected-script grep — a vendor update since Phase 6 can re-introduce it). Any survivor = **NO-GO**.
:::

| Verdict | Meaning |
|---|---|
| **GO** | All 22 rows are nonblank, zero blockers remain, advisories are explicitly accepted, and Phase 11 can start. Production deploy still waits for Phase 12. |
| **CONDITIONAL GO** | No blockers remain, but one or more advisories need named owner/date follow-up before or immediately after launch. |
| **NO-GO** | Any blocker remains, the vendor seed-surface sweep fails, reports are missing, or staging proof is incomplete. |

Before stamping **GO**, confirm all of the following:

- All 22 rows are filled in.
- Rows 6 and 7 pass; any default admin, demo data, vendor credential, license beacon, or injected-script survivor is **NO-GO**.
- Zero red/blocker rows remain.
- Every advisory is accepted by the user with owner + review date.
- At least one functional end-to-end golden path passed on the selected launch-candidate environment today.
- `Admin-Local/1-Project/1-Info/monitoring-state.md` shows monitoring data is being received or a row is marked N/A with reason.
- `Zaj-PROGRESS.md` logs the verdict, date, signer, and path to the consolidated report.
- `Zaj-BACKLOG.md` rows from the deferred items carry source, severity, effort, trigger, and acceptance criterion — no disguised blockers ("defer" for a production breaker = **NO-GO**) and no vague/no-trigger rows.

Write the consolidated report to `Admin-Local/1-Project/4-Audit-Reports/YYYY-MM-DD-phase-10-CONSOLIDATED.md`. Phase 11's first step transfers the `📋 Deferred to Zaj-BACKLOG.md` rows into root `Zaj-BACKLOG.md`.

### 2. Walk the pre-launch checklist

Confirm every area below before anyone makes a go/no-go call.

| Area | Verify |
|---|---|
| Blockers | No unresolved HIGH / open ISSUE / SECURITY items in `Zaj-BACKLOG.md` or the Phase 10 audit reports |
| Infrastructure | SSL > 30 days, DNS + www resolve, CDN proxy on, SSL mode Full (strict) |
| Security | `APP_DEBUG=false`, `.env` returns 403/404, no debug toolbar, **Grade A** headers (securityheaders.com) + **SSL Labs (TLS)** A/A+ |
| Monitoring | Error tracking captures a test event, uptime monitor + backups verified |
| Payments | Staging/test payment path passed, production keys/webhook are vaulted and scoped, and the Phase 11/12 human live-charge/refund gate is named |
| Communications | Inbox-delivered welcome/reset/invoice emails, chat widget live |
| Legal | Privacy, Terms, Cookie, Refund pages published + linked; consent banner enforced |
| Content | No placeholder text, favicon, OG/meta, sitemap, `robots.txt` correct |
| Team readiness | Admin creds in a vault with 2FA, rollback documented, 24h monitor assigned |

:::note[Who does this]
👤 **User** makes the go/no-go sign-off — a launch authorization only a person can give. 🤖 **Agent** verifies the technical items (headers, `.env` blocking, webhook config) and reports status per area.
:::

<Steps>

1. **Verify every area, then make the go/no-go call.** If any high-risk item is unresolved, **do not launch**.

   - ✅ All nine areas are green with zero unresolved HIGH / SECURITY items, and the sign-off is recorded.

</Steps>

### 3. Prepare the Phase 11/12 handoff

With a green checklist, write the handoff that tells the next phases exactly what to re-verify and what not to run yet.

:::note[Who does this]
🔀 **User + Agent** — the agent writes the handoff and reconciles trackers; 👤 **User** accepts the verdict/advisories. Production backup, release tag, deploy, live payment, go-live, and the 24–48h production watch are Phase 12 actions.
:::

<Steps>

1. **Write the handoff inside the consolidated report and update trackers.** The consolidated report must end with a short "Next-phase handoff" section.

   ```markdown
   ## Next-phase handoff

   Verdict: GO | CONDITIONAL GO | NO-GO
   Phase 11 may start: yes/no
   Phase 12 production deploy may start now: no — wait for Phase 11 signoff and Phase 12 Task P.0

   Phase 11 re-verifies:
   - Technical readiness gates
   - Business/legal readiness
   - Support/onboarding readiness
   - Tiered go/no-go

   Phase 12 executes later:
   - production secret rotation/preflight
   - production backup/tag/release branch/deploy
   - live installer/auth checks
   - production seed-surface sweep
   - 24–48h production monitor

   Blockers:
   - none | list each blocker with owner and required proof

   Deferred polish transferred to Zaj-BACKLOG.md:
   - list each row source/severity/effort/trigger/acceptance
   ```

   ```bash
   grep -n "Next-phase handoff" Admin-Local/1-Project/4-Audit-Reports/*phase-10-CONSOLIDATED.md
   grep -n "Phase 10-CONSOLIDATED" Zaj-PROGRESS.md
   grep -n "Deferred to Zaj-BACKLOG.md" Zaj-BACKLOG.md
   # Expected: consolidated report includes the handoff, Zaj-PROGRESS.md links the verdict,
   # and every deferred-polish row landed in Zaj-BACKLOG.md.
   ```

   :::caution[Do not run production from Phase 10]
   No `git tag`, production DB dump, release-branch merge, `dep deploy production`, live payment charge, go-live switch, or production 24–48h watch runs here. Those are Phase 12 actions after Phase 11 and Phase 12 Task P.0 clear.
   :::

   - ✅ The consolidated report contains the next-phase handoff, `Zaj-PROGRESS.md` links the verdict, and every deferred polish row is in `Zaj-BACKLOG.md`.

</Steps>

## Checklist

Do not mark this step done until **every** box below is checked.

- [ ] **🤖 Blockers clear** — no unresolved HIGH / open ISSUE / SECURITY items in `Zaj-BACKLOG.md` or the Phase 10 audit reports.
- [ ] **🔀 Consolidated verdict recorded** — all 22 rows complete, verdict written to `Admin-Local/1-Project/4-Audit-Reports/YYYY-MM-DD-phase-10-CONSOLIDATED.md`, and `Zaj-PROGRESS.md` links it.
- [ ] **🤖 Infrastructure ready** — SSL > 30 days, DNS + www resolve, CDN proxy on, SSL mode Full (strict).
- [ ] **🤖 Security verified** — `APP_DEBUG=false`, `.env` returns 403/404, no debug toolbar; **Grade A** at securityheaders.com; **SSL Labs (TLS)** A or A+.
- [ ] **🤖 Vendor seed-surface sweep** — default admin credentials rotated, demo users/content removed, vendor-shipped encrypted creds/keys absent, and vendor-integrity scan clean; any survivor = NO-GO.
- [ ] **🤖 Monitoring live** — error tracking captures a test event, uptime monitor + backups verified.
- [ ] **🔀 Payments ready** — staging/test path passed; production keys/webhook are vaulted/scoped; live charge + refund are explicitly named as the later human gate.
- [ ] **🤖 Communications working** — inbox-delivered welcome/reset/invoice emails, chat widget live.
- [ ] **🤖 Legal published** — Privacy, Terms, Cookie, Refund pages published + linked; consent banner enforced.
- [ ] **🤖 Content complete** — no placeholder text, favicon, OG/meta, sitemap, `robots.txt` correct.
- [ ] **🔀 Handoff ready** — admin creds vaulted with 2FA, rollback documented, 24h monitor owner named, and the Phase 11/12 handoff is recorded.

:::next[Next step]
[Phase 11 · Pre-customer verification](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/11-pre-customer/)
:::