4 · Installer + harden

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: 4 · Installer + harden
- url: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/05-deploy-staging/04-installer-smoke/
- shelf: Build & Create
- doc_type: implementation playbook
- status: current
- kind: playbook
- category: tech-stack
- subcategory: laravel
- topic: codecanyon
- phase: 5
- part_number: 4 (legacy stepNumber frontmatter)
- legacy_step_number: 4
- est_time: ~20 min
- description: Temporarily unblock /install, run the CodeCanyon web installer wizard, verify the app loads, then immediately re-block /install + /update and re-harden storage and .env permissions from the installer's insecure 777 state.
- tags: codecanyon, laravel, installer, hardening

## Execution rules (binding)
- This is Part 4 of phase 5 (~20 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.

---

# 4 · Installer + harden

## TL;DR

**Objective** — install the app the CodeCanyon way (a web wizard, not artisan migrations): temporarily unblock `/install`, run the wizard against the selected non-production DB from `Zaj-PROJECT.md`, verify the app loads, then immediately re-block `/install` + `/update` and re-harden permissions — because you opened a writable, installable surface to the public web.

**Steps at a glance:**
1. **Temporarily unblock the `/install` route** — Phase 3 added `.htaccess` rules (and possibly a Cloudflare WAF
   rule) blocking `/install`, `/update`, and `/upgrade-script`.
2. **Run the installer wizard** — With browser automation, the agent drives non-secret wizard screens in an
   isolated browser; the human handles every secret field and any admin-account creation transaction.
3. **Verify the installation** — The human signs in once; browser automation resumes after the session exists,
   snapshots the dashboard, and tails logs on errors.
4. **Re-block `/install` and `/update`** — The writable, installable surface must close as soon as the wizard
   finishes.
5. **Re-harden permissions** — Walk back the temporary 777 from page 3 to least-privilege.

:::note[User part + done-when]
**🔀 User part** — the agent drives non-secret `/install` screens when browser automation is available, then pauses for the human to fill every secret field and complete any admin-account creation. For `/login`, the human performs the one sign-in; the agent resumes after the authenticated session exists. Toggling the optional Cloudflare WAF rule is still a dashboard action. An agent drives the `.htaccess` unblock/re-block, permission harden, public curl checks, and post-session browser verification.

**Done when** the wizard reports "Installation Complete", the human-created admin session works, browser evidence exists, `/install` is re-blocked (403), the Cloudflare WAF rule is restored, and permissions are walked back to least-privilege. &nbsp;·&nbsp; **⏱ ~20 min** &nbsp;·&nbsp; 🔀 mixed (🤖 non-secret browser + SSH, 👤 auth/secret fields + WAF fallback).
:::

## Background

CodeCanyon apps install through a web wizard, not artisan migrations. Phase 3 blocked `/install` and `/update` for safety, so this page **temporarily** unblocks them, runs the wizard, then re-blocks and re-hardens. The harden step is not optional — you opened a writable, installable surface to the public web.

## Steps

### 1. Temporarily unblock the `/install` route

Phase 3 added `.htaccess` rules (and possibly a Cloudflare WAF rule) blocking `/install`, `/update`, and `/upgrade-script`. Comment them out so the wizard can load.

<Steps>

1. **Unblock the install routes and remove any stale lock.**

   ```bash
   # Is /install currently blocked?
   ssh <non-prod-alias> "grep 'RewriteRule ^install' ~/domains/nonprod.example.com/deploy/current/public/.htaccess 2>/dev/null"

   # Comment out the blocking rules (idempotent — skip lines already commented)
   ssh <non-prod-alias> 'cd ~/domains/nonprod.example.com/deploy/current/public && \
     grep -q "^RewriteRule ^install" .htaccess && \
     sed -i "s/^RewriteRule ^install/# RewriteRule ^install/" .htaccess; \
     grep -q "^RewriteRule ^update" .htaccess && \
     sed -i "s/^RewriteRule ^update/# RewriteRule ^update/" .htaccess; \
     grep -q "^RewriteRule ^upgrade-script" .htaccess && \
     sed -i "s/^RewriteRule ^upgrade-script/# RewriteRule ^upgrade-script/" .htaccess; \
     echo "install/update unblocked"'

   # Remove any stale install lock
   ssh <non-prod-alias> "rm -f ~/domains/nonprod.example.com/deploy/shared/storage/installed 2>/dev/null && echo 'lock removed'"
   # Expected: "install/update unblocked" and "lock removed"
   ```

   - ✅ The blocking rules are commented out and any stale `installed` lock is removed.

2. **Confirm the wizard is reachable.**

   ```bash
   curl -sI https://nonprod.example.com/install 2>&1 | head -1   # expect HTTP/2 200
   # Expected: HTTP/2 200
   ```

   - ✅ `/install` returns `HTTP/2 200`.

</Steps>

If you created a Cloudflare WAF rule in Phase 3, toggle it **OFF** now (👤): *Cloudflare → Security → WAF → "Block install and update routes" → OFF*.

:::note[A 500 on `/` is still expected here]
The database is empty until the wizard runs — the homepage may 500. You're only confirming `/install` returns 200.
:::

### 2. Run the installer wizard

Run `https://nonprod.example.com/install` with the safest actor split: browser automation drives non-secret wizard screens when available; the human fills secret fields and completes account-creation/authentication transactions.

:::note[Who does this]
🔀 **AI-driven, human supplies secrets/auth** — if claude-in-chrome, Chrome MCP, Playwright, or another browser automation tool is loaded or loadable, the agent drives non-secret wizard screens in an isolated browser instance. For first-time staging setup this is the default path, not an optional courtesy: do not mark the whole wizard human-only just because it runs in a browser. The agent must never type, reveal, or store a password and must never create the admin account: pause at **Database Password** and at any admin-account screen, let the human complete the secret/account transaction from the project vault, then resume after the non-secret screen state exists. If no browser tools exist, the user runs the whole wizard manually.
:::

<Steps>

1. **Decide the browser path.**

   | Condition | Action |
   |---|---|
   | Browser automation available | Agent opens an isolated browser instance, navigates to `/install`, and drives every non-secret screen |
   | Browser automation unavailable | User opens `/install` and runs the wizard manually |
   | Secret field or account-creation screen appears | Human completes the credential/account transaction; agent waits, then resumes after the non-secret state exists |

   - ✅ The run mode is chosen before any installer field is touched.

2. **Requirements** — agent-driven when browser automation exists. Confirm all checks are green, then record the web-SAPI PHP version displayed by the wizard. That screen is the authoritative web PHP cross-check for this environment; it can differ from SSH `php -v`.

   - ✅ Every requirement check is green.
   - ✅ The web-SAPI PHP version is recorded in `Zaj-PROJECT.md` or the phase notes.

3. **File permissions** — agent-driven when browser automation exists. Confirm every writable check is green. Reds usually mean the page-3 permission unblock missed a path.

   - ✅ Every permissions check is green.

4. **Environment configuration** — agent fills non-secret values from `Zaj-PROJECT.md` and the selected environment's `.env.<env-key>` (`.env.staging` is the simple example): app name, app URL, DB host, DB port, DB username, and DB name. If **Database Password** is required, it is a human-only field from the project vault. If the vendor labels it optional and falls back to the already-rendered server `.env`, the agent leaves it blank and proceeds. After the human handles any required secret field, the agent clicks **Test Connection** and continues.

   - ✅ Test Connection succeeds against the selected non-production DB.
   - ✅ Required secret fields are human-filled; optional password fields that fall back to `.env` are left blank; the agent never types or prints passwords.

5. **Admin account** — conditional. Some vendors show an admin-create screen; some seed default admin rows instead. If a screen appears, the human completes the account-creation transaction, including password entry and submit. The agent may prepare non-secret context (name and non-production email) for the human to copy, then confirms the new admin login is saved to the project vault without seeing the password. If no screen appears, prove the vendor seeds defaults by citing the seeder grep from Phase 3/installer notes or a bounded post-install user query, then flag every default for Phase 6 rotation.

   - ✅ Admin account handled: either created with a human-entered password, or `N/A — vendor seeds defaults` is proven and every default is flagged for Phase 6 rotation.

6. **Settings** — agent-driven when browser automation exists. Confirm app name (e.g. "Your App — QA") and URL from the selected `Zaj-PROJECT.md` environment row.

   - ✅ App name and URL are set for the selected non-production environment.

7. **Install / Finish** — agent-driven when browser automation exists. Click through the install/finish screen and confirm "Installation Complete".

   - ✅ The wizard reports "Installation Complete".

</Steps>

:::note[Vendor admin-screen pattern]
WorkDo and Froiden-family installers often seed default admin users instead of showing an admin-create screen. For WorkDo Dash SaaS, the installer may have no admin-password screen, and the DB password field may be optional because the app reads the rendered `.env`; the known seeded defaults are rotated later in Phase 6. Other vendors may require a DB password or add an admin-password field. The rule stays the same: the human handles every required secret, credential, login, or account-creation transaction; the agent fills and verifies the non-secret rest.
:::

Use the table to recover from a wizard that won't load or stalls:

| Installer result | Action |
|---|---|
| Wizard loads | Continue |
| 403 Forbidden | `.htaccess` still blocking — re-run section 1 |
| 404 | Installer route missing — confirm the app ships one |
| 500 | `tail -50 …/deploy/current/storage/logs/laravel.log` |
| 504 Gateway Timeout | PHP timeout too low — confirm `shared/.user.ini` has `max_execution_time = 300` (page 1, step 7), then retry |
| "Access Denied" mid-wizard | Stale cached config with old DB values — `optimize:clear` with the versioned PHP binary (page 3, step 2), then retry |
| "Already installed" | Remove `storage/installed` (section 1) |

:::danger[Broken-state 500 on `/install` — first install only]
If a partial/failed migration leaves the database half-built, a 500 can persist. **Only on a first install with no real data**, reset and retry:

```bash
# GUARD FIRST — refuse to wipe a DB that already holds users. `--force` skips
# the interactive prompt, so prose like "first install only" is not a safeguard
   # on a shared/re-run non-production DB. Abort unless the users table is empty (0 rows).
ssh <non-prod-alias> 'cd ~/domains/nonprod.example.com/deploy/current && \
  USERS=$(php artisan tinker --execute="echo \DB::table(\"users\")->count();" 2>/dev/null | tail -1) && \
  if [ "${USERS:-1}" != "0" ]; then echo "ABORT: users table has $USERS row(s) — not a clean first install"; exit 1; fi && \
  php artisan db:wipe --force'
ssh <non-prod-alias> "rm -f ~/domains/nonprod.example.com/deploy/shared/storage/installed"
# then reload /install in the browser
```

Use `db:wipe`, not `migrate:fresh` — the web installer builds the schema correctly, while `migrate:fresh` can trip over CodeCanyon migration-ordering bugs. This **destroys all data** — the guard above blocks it once the app holds users; never lift the guard on a DB you care about.
:::

### 3. Verify the installation

Sign in and confirm the app is healthy after the wizard.

:::note[Who does this]
🔀 **User login, agent post-session verification** — the agent may navigate to `/login` and snapshot the public form, but 👤 **User** performs the one sign-in transaction. After the authenticated session exists in the isolated browser, 🤖 **Agent** waits for dashboard text, snapshots the dashboard, walks non-secret checks, and checks logs if anything errors. 👤 **User** is fallback only when no browser automation exists after sign-in.
:::

<Steps>

1. **Sign in at `/login` and walk the post-install checks.**

   Visit `https://nonprod.example.com/login`; the human signs in with the admin account, then hands the authenticated browser session back to the agent for checks.

   | Check | Pass |
   |---|---|
   | Dashboard loads | [ ] |
   | Navigation works | [ ] |
   | No PHP errors | [ ] |
   | CSS/JS loading | [ ] |
   | SSL padlock shows | [ ] |

   If the browser shows a 500, a blank dashboard, or broken assets, tail the Laravel log before continuing:

   ```bash
   ssh <non-prod-alias> "tail -80 ~/domains/nonprod.example.com/deploy/current/storage/logs/laravel.log"
   # Expected: no new fatal error for the login/dashboard request
   ```

   - ✅ Human admin sign-in works, all five post-install checks pass in the post-session browser, and no new fatal log entry appears.

</Steps>

### 4. Re-block `/install` and `/update`

The writable, installable surface must close as soon as the wizard finishes.

<Steps>

1. **Re-comment the blocking rules and confirm `/install` is forbidden.**

   ```bash
   ssh <non-prod-alias> 'cd ~/domains/nonprod.example.com/deploy/current/public && \
     grep -q "^# RewriteRule ^install" .htaccess && \
     sed -i "s/^# RewriteRule ^install/RewriteRule ^install/" .htaccess; \
     grep -q "^# RewriteRule ^update" .htaccess && \
     sed -i "s/^# RewriteRule ^update/RewriteRule ^update/" .htaccess; \
     grep -q "^# RewriteRule ^upgrade-script" .htaccess && \
     sed -i "s/^# RewriteRule ^upgrade-script/RewriteRule ^upgrade-script/" .htaccess; \
     echo "install/update re-blocked"'

   curl -sI https://nonprod.example.com/install 2>&1 | head -1   # expect HTTP/2 403
   # Expected: "install/update re-blocked" then HTTP/2 403
   ```

   - ✅ The rules are restored and `/install` returns `HTTP/2 403`.

</Steps>

Re-enable the Cloudflare WAF rule if you toggled it off (👤).

:::danger[Do not skip the re-block]
An installable, world-writable app on the public web can be reinstalled by anyone who finds `/install`, wiping or hijacking the database. Re-blocking and re-hardening are part of "the installer ran," not a follow-up nicety.
:::

### 5. Re-harden permissions

Walk back the temporary 777 from page 3 to least-privilege.

<Steps>

1. **Restore least-privilege on storage and `.env`.**

   ```bash
   # storage: dirs 775, files 664
   ssh <non-prod-alias> "cd ~/domains/nonprod.example.com/deploy/shared/storage && \
     find . -type d -exec chmod 775 {} \; && find . -type f -exec chmod 664 {} \;"

   # .env: 640
   ssh <non-prod-alias> "chmod 640 ~/domains/nonprod.example.com/deploy/shared/.env"
   # Expected: storage dirs 775 / files 664; .env 640
   ```

   - ✅ Storage dirs are `775`, files `664`, and `.env` is `640`.

</Steps>

## Checklist

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

- [ ] **🔀 Wizard completed** — `/install` reachable (200), browser automation drove all non-secret screens when available, human filled secret fields, and "Installation Complete" shown.
- [ ] **🔀 App verified** — browser automation verified login/dashboard when available; all five post-install checks pass; admin login works.
- [ ] **🔀 Routes re-blocked** — `/install` re-blocked (403); Cloudflare WAF rule restored.
- [ ] **🤖 Permissions re-hardened** — storage dirs `775` / files `664`; `.env` `640`.

:::next[Next step]
[Schedule, migrations + schema](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/05-deploy-staging/05-secure-verify-schema/)
:::

# 4 · Installer + harden

> Source: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/05-deploy-staging/04-installer-smoke/

## TL;DR

**Objective** — install the app the CodeCanyon way (a web wizard, not artisan migrations): temporarily unblock `/install`, run the wizard against the selected non-production DB from `Zaj-PROJECT.md`, verify the app loads, then immediately re-block `/install` + `/update` and re-harden permissions — because you opened a writable, installable surface to the public web.

**Steps at a glance:**
1. **Temporarily unblock the `/install` route** — Phase 3 added `.htaccess` rules (and possibly a Cloudflare WAF
   rule) blocking `/install`, `/update`, and `/upgrade-script`.
2. **Run the installer wizard** — With browser automation, the agent drives non-secret wizard screens in an
   isolated browser; the human handles every secret field and any admin-account creation transaction.
3. **Verify the installation** — The human signs in once; browser automation resumes after the session exists,
   snapshots the dashboard, and tails logs on errors.
4. **Re-block `/install` and `/update`** — The writable, installable surface must close as soon as the wizard
   finishes.
5. **Re-harden permissions** — Walk back the temporary 777 from page 3 to least-privilege.

:::note[User part + done-when]
**🔀 User part** — the agent drives non-secret `/install` screens when browser automation is available, then pauses for the human to fill every secret field and complete any admin-account creation. For `/login`, the human performs the one sign-in; the agent resumes after the authenticated session exists. Toggling the optional Cloudflare WAF rule is still a dashboard action. An agent drives the `.htaccess` unblock/re-block, permission harden, public curl checks, and post-session browser verification.

**Done when** the wizard reports "Installation Complete", the human-created admin session works, browser evidence exists, `/install` is re-blocked (403), the Cloudflare WAF rule is restored, and permissions are walked back to least-privilege. &nbsp;·&nbsp; **⏱ ~20 min** &nbsp;·&nbsp; 🔀 mixed (🤖 non-secret browser + SSH, 👤 auth/secret fields + WAF fallback).
:::

## Background

CodeCanyon apps install through a web wizard, not artisan migrations. Phase 3 blocked `/install` and `/update` for safety, so this page **temporarily** unblocks them, runs the wizard, then re-blocks and re-hardens. The harden step is not optional — you opened a writable, installable surface to the public web.

## Steps

### 1. Temporarily unblock the `/install` route

Phase 3 added `.htaccess` rules (and possibly a Cloudflare WAF rule) blocking `/install`, `/update`, and `/upgrade-script`. Comment them out so the wizard can load.

<Steps>

1. **Unblock the install routes and remove any stale lock.**

   ```bash
   # Is /install currently blocked?
   ssh <non-prod-alias> "grep 'RewriteRule ^install' ~/domains/nonprod.example.com/deploy/current/public/.htaccess 2>/dev/null"

   # Comment out the blocking rules (idempotent — skip lines already commented)
   ssh <non-prod-alias> 'cd ~/domains/nonprod.example.com/deploy/current/public && \
     grep -q "^RewriteRule ^install" .htaccess && \
     sed -i "s/^RewriteRule ^install/# RewriteRule ^install/" .htaccess; \
     grep -q "^RewriteRule ^update" .htaccess && \
     sed -i "s/^RewriteRule ^update/# RewriteRule ^update/" .htaccess; \
     grep -q "^RewriteRule ^upgrade-script" .htaccess && \
     sed -i "s/^RewriteRule ^upgrade-script/# RewriteRule ^upgrade-script/" .htaccess; \
     echo "install/update unblocked"'

   # Remove any stale install lock
   ssh <non-prod-alias> "rm -f ~/domains/nonprod.example.com/deploy/shared/storage/installed 2>/dev/null && echo 'lock removed'"
   # Expected: "install/update unblocked" and "lock removed"
   ```

   - ✅ The blocking rules are commented out and any stale `installed` lock is removed.

2. **Confirm the wizard is reachable.**

   ```bash
   curl -sI https://nonprod.example.com/install 2>&1 | head -1   # expect HTTP/2 200
   # Expected: HTTP/2 200
   ```

   - ✅ `/install` returns `HTTP/2 200`.

</Steps>

If you created a Cloudflare WAF rule in Phase 3, toggle it **OFF** now (👤): *Cloudflare → Security → WAF → "Block install and update routes" → OFF*.

:::note[A 500 on `/` is still expected here]
The database is empty until the wizard runs — the homepage may 500. You're only confirming `/install` returns 200.
:::

### 2. Run the installer wizard

Run `https://nonprod.example.com/install` with the safest actor split: browser automation drives non-secret wizard screens when available; the human fills secret fields and completes account-creation/authentication transactions.

:::note[Who does this]
🔀 **AI-driven, human supplies secrets/auth** — if claude-in-chrome, Chrome MCP, Playwright, or another browser automation tool is loaded or loadable, the agent drives non-secret wizard screens in an isolated browser instance. For first-time staging setup this is the default path, not an optional courtesy: do not mark the whole wizard human-only just because it runs in a browser. The agent must never type, reveal, or store a password and must never create the admin account: pause at **Database Password** and at any admin-account screen, let the human complete the secret/account transaction from the project vault, then resume after the non-secret screen state exists. If no browser tools exist, the user runs the whole wizard manually.
:::

<Steps>

1. **Decide the browser path.**

   | Condition | Action |
   |---|---|
   | Browser automation available | Agent opens an isolated browser instance, navigates to `/install`, and drives every non-secret screen |
   | Browser automation unavailable | User opens `/install` and runs the wizard manually |
   | Secret field or account-creation screen appears | Human completes the credential/account transaction; agent waits, then resumes after the non-secret state exists |

   - ✅ The run mode is chosen before any installer field is touched.

2. **Requirements** — agent-driven when browser automation exists. Confirm all checks are green, then record the web-SAPI PHP version displayed by the wizard. That screen is the authoritative web PHP cross-check for this environment; it can differ from SSH `php -v`.

   - ✅ Every requirement check is green.
   - ✅ The web-SAPI PHP version is recorded in `Zaj-PROJECT.md` or the phase notes.

3. **File permissions** — agent-driven when browser automation exists. Confirm every writable check is green. Reds usually mean the page-3 permission unblock missed a path.

   - ✅ Every permissions check is green.

4. **Environment configuration** — agent fills non-secret values from `Zaj-PROJECT.md` and the selected environment's `.env.<env-key>` (`.env.staging` is the simple example): app name, app URL, DB host, DB port, DB username, and DB name. If **Database Password** is required, it is a human-only field from the project vault. If the vendor labels it optional and falls back to the already-rendered server `.env`, the agent leaves it blank and proceeds. After the human handles any required secret field, the agent clicks **Test Connection** and continues.

   - ✅ Test Connection succeeds against the selected non-production DB.
   - ✅ Required secret fields are human-filled; optional password fields that fall back to `.env` are left blank; the agent never types or prints passwords.

5. **Admin account** — conditional. Some vendors show an admin-create screen; some seed default admin rows instead. If a screen appears, the human completes the account-creation transaction, including password entry and submit. The agent may prepare non-secret context (name and non-production email) for the human to copy, then confirms the new admin login is saved to the project vault without seeing the password. If no screen appears, prove the vendor seeds defaults by citing the seeder grep from Phase 3/installer notes or a bounded post-install user query, then flag every default for Phase 6 rotation.

   - ✅ Admin account handled: either created with a human-entered password, or `N/A — vendor seeds defaults` is proven and every default is flagged for Phase 6 rotation.

6. **Settings** — agent-driven when browser automation exists. Confirm app name (e.g. "Your App — QA") and URL from the selected `Zaj-PROJECT.md` environment row.

   - ✅ App name and URL are set for the selected non-production environment.

7. **Install / Finish** — agent-driven when browser automation exists. Click through the install/finish screen and confirm "Installation Complete".

   - ✅ The wizard reports "Installation Complete".

</Steps>

:::note[Vendor admin-screen pattern]
WorkDo and Froiden-family installers often seed default admin users instead of showing an admin-create screen. For WorkDo Dash SaaS, the installer may have no admin-password screen, and the DB password field may be optional because the app reads the rendered `.env`; the known seeded defaults are rotated later in Phase 6. Other vendors may require a DB password or add an admin-password field. The rule stays the same: the human handles every required secret, credential, login, or account-creation transaction; the agent fills and verifies the non-secret rest.
:::

Use the table to recover from a wizard that won't load or stalls:

| Installer result | Action |
|---|---|
| Wizard loads | Continue |
| 403 Forbidden | `.htaccess` still blocking — re-run section 1 |
| 404 | Installer route missing — confirm the app ships one |
| 500 | `tail -50 …/deploy/current/storage/logs/laravel.log` |
| 504 Gateway Timeout | PHP timeout too low — confirm `shared/.user.ini` has `max_execution_time = 300` (page 1, step 7), then retry |
| "Access Denied" mid-wizard | Stale cached config with old DB values — `optimize:clear` with the versioned PHP binary (page 3, step 2), then retry |
| "Already installed" | Remove `storage/installed` (section 1) |

:::danger[Broken-state 500 on `/install` — first install only]
If a partial/failed migration leaves the database half-built, a 500 can persist. **Only on a first install with no real data**, reset and retry:

```bash
# GUARD FIRST — refuse to wipe a DB that already holds users. `--force` skips
# the interactive prompt, so prose like "first install only" is not a safeguard
   # on a shared/re-run non-production DB. Abort unless the users table is empty (0 rows).
ssh <non-prod-alias> 'cd ~/domains/nonprod.example.com/deploy/current && \
  USERS=$(php artisan tinker --execute="echo \DB::table(\"users\")->count();" 2>/dev/null | tail -1) && \
  if [ "${USERS:-1}" != "0" ]; then echo "ABORT: users table has $USERS row(s) — not a clean first install"; exit 1; fi && \
  php artisan db:wipe --force'
ssh <non-prod-alias> "rm -f ~/domains/nonprod.example.com/deploy/shared/storage/installed"
# then reload /install in the browser
```

Use `db:wipe`, not `migrate:fresh` — the web installer builds the schema correctly, while `migrate:fresh` can trip over CodeCanyon migration-ordering bugs. This **destroys all data** — the guard above blocks it once the app holds users; never lift the guard on a DB you care about.
:::

### 3. Verify the installation

Sign in and confirm the app is healthy after the wizard.

:::note[Who does this]
🔀 **User login, agent post-session verification** — the agent may navigate to `/login` and snapshot the public form, but 👤 **User** performs the one sign-in transaction. After the authenticated session exists in the isolated browser, 🤖 **Agent** waits for dashboard text, snapshots the dashboard, walks non-secret checks, and checks logs if anything errors. 👤 **User** is fallback only when no browser automation exists after sign-in.
:::

<Steps>

1. **Sign in at `/login` and walk the post-install checks.**

   Visit `https://nonprod.example.com/login`; the human signs in with the admin account, then hands the authenticated browser session back to the agent for checks.

   | Check | Pass |
   |---|---|
   | Dashboard loads | [ ] |
   | Navigation works | [ ] |
   | No PHP errors | [ ] |
   | CSS/JS loading | [ ] |
   | SSL padlock shows | [ ] |

   If the browser shows a 500, a blank dashboard, or broken assets, tail the Laravel log before continuing:

   ```bash
   ssh <non-prod-alias> "tail -80 ~/domains/nonprod.example.com/deploy/current/storage/logs/laravel.log"
   # Expected: no new fatal error for the login/dashboard request
   ```

   - ✅ Human admin sign-in works, all five post-install checks pass in the post-session browser, and no new fatal log entry appears.

</Steps>

### 4. Re-block `/install` and `/update`

The writable, installable surface must close as soon as the wizard finishes.

<Steps>

1. **Re-comment the blocking rules and confirm `/install` is forbidden.**

   ```bash
   ssh <non-prod-alias> 'cd ~/domains/nonprod.example.com/deploy/current/public && \
     grep -q "^# RewriteRule ^install" .htaccess && \
     sed -i "s/^# RewriteRule ^install/RewriteRule ^install/" .htaccess; \
     grep -q "^# RewriteRule ^update" .htaccess && \
     sed -i "s/^# RewriteRule ^update/RewriteRule ^update/" .htaccess; \
     grep -q "^# RewriteRule ^upgrade-script" .htaccess && \
     sed -i "s/^# RewriteRule ^upgrade-script/RewriteRule ^upgrade-script/" .htaccess; \
     echo "install/update re-blocked"'

   curl -sI https://nonprod.example.com/install 2>&1 | head -1   # expect HTTP/2 403
   # Expected: "install/update re-blocked" then HTTP/2 403
   ```

   - ✅ The rules are restored and `/install` returns `HTTP/2 403`.

</Steps>

Re-enable the Cloudflare WAF rule if you toggled it off (👤).

:::danger[Do not skip the re-block]
An installable, world-writable app on the public web can be reinstalled by anyone who finds `/install`, wiping or hijacking the database. Re-blocking and re-hardening are part of "the installer ran," not a follow-up nicety.
:::

### 5. Re-harden permissions

Walk back the temporary 777 from page 3 to least-privilege.

<Steps>

1. **Restore least-privilege on storage and `.env`.**

   ```bash
   # storage: dirs 775, files 664
   ssh <non-prod-alias> "cd ~/domains/nonprod.example.com/deploy/shared/storage && \
     find . -type d -exec chmod 775 {} \; && find . -type f -exec chmod 664 {} \;"

   # .env: 640
   ssh <non-prod-alias> "chmod 640 ~/domains/nonprod.example.com/deploy/shared/.env"
   # Expected: storage dirs 775 / files 664; .env 640
   ```

   - ✅ Storage dirs are `775`, files `664`, and `.env` is `640`.

</Steps>

## Checklist

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

- [ ] **🔀 Wizard completed** — `/install` reachable (200), browser automation drove all non-secret screens when available, human filled secret fields, and "Installation Complete" shown.
- [ ] **🔀 App verified** — browser automation verified login/dashboard when available; all five post-install checks pass; admin login works.
- [ ] **🔀 Routes re-blocked** — `/install` re-blocked (403); Cloudflare WAF rule restored.
- [ ] **🤖 Permissions re-hardened** — storage dirs `775` / files `664`; `.env` `640`.

:::next[Next step]
[Schedule, migrations + schema](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/05-deploy-staging/05-secure-verify-schema/)
:::

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 — install the app the CodeCanyon way (a web wizard, not artisan migrations): temporarily unblock /install, run the wizard against the selected non-production DB from Zaj-PROJECT.md, verify the app loads, then immediately re-block /install + /update and re-harden permissions — because you opened a writable, installable surface to the public web.

Steps at a glance:

Temporarily unblock the /install route — Phase 3 added .htaccess rules (and possibly a Cloudflare WAF rule) blocking /install, /update, and /upgrade-script.
Run the installer wizard — With browser automation, the agent drives non-secret wizard screens in an isolated browser; the human handles every secret field and any admin-account creation transaction.
Verify the installation — The human signs in once; browser automation resumes after the session exists, snapshots the dashboard, and tails logs on errors.
Re-block /install and /update — The writable, installable surface must close as soon as the wizard finishes.
Re-harden permissions — Walk back the temporary 777 from page 3 to least-privilege.

🔀 User part — the agent drives non-secret /install screens when browser automation is available, then pauses for the human to fill every secret field and complete any admin-account creation. For /login, the human performs the one sign-in; the agent resumes after the authenticated session exists. Toggling the optional Cloudflare WAF rule is still a dashboard action. An agent drives the .htaccess unblock/re-block, permission harden, public curl checks, and post-session browser verification.

Done when the wizard reports “Installation Complete”, the human-created admin session works, browser evidence exists, /install is re-blocked (403), the Cloudflare WAF rule is restored, and permissions are walked back to least-privilege. · ⏱ ~20 min · 🔀 mixed (🤖 non-secret browser + SSH, 👤 auth/secret fields + WAF fallback).

Background

CodeCanyon apps install through a web wizard, not artisan migrations. Phase 3 blocked /install and /update for safety, so this page temporarily unblocks them, runs the wizard, then re-blocks and re-hardens. The harden step is not optional — you opened a writable, installable surface to the public web.

Steps

1. Temporarily unblock the `/install` route

Phase 3 added .htaccess rules (and possibly a Cloudflare WAF rule) blocking /install, /update, and /upgrade-script. Comment them out so the wizard can load.

Unblock the install routes and remove any stale lock.

# Is /install currently blocked?
ssh <non-prod-alias> "grep 'RewriteRule ^install' ~/domains/nonprod.example.com/deploy/current/public/.htaccess 2>/dev/null"

# Comment out the blocking rules (idempotent — skip lines already commented)
ssh <non-prod-alias> 'cd ~/domains/nonprod.example.com/deploy/current/public && \
  grep -q "^RewriteRule ^install" .htaccess && \
  sed -i "s/^RewriteRule ^install/# RewriteRule ^install/" .htaccess; \
  grep -q "^RewriteRule ^update" .htaccess && \
  sed -i "s/^RewriteRule ^update/# RewriteRule ^update/" .htaccess; \
  grep -q "^RewriteRule ^upgrade-script" .htaccess && \
  sed -i "s/^RewriteRule ^upgrade-script/# RewriteRule ^upgrade-script/" .htaccess; \
  echo "install/update unblocked"'

# Remove any stale install lock
ssh <non-prod-alias> "rm -f ~/domains/nonprod.example.com/deploy/shared/storage/installed 2>/dev/null && echo 'lock removed'"
# Expected: "install/update unblocked" and "lock removed"

✅ The blocking rules are commented out and any stale installed lock is removed.

Confirm the wizard is reachable.

curl -sI https://nonprod.example.com/install 2>&1 | head -1   # expect HTTP/2 200
# Expected: HTTP/2 200

✅ /install returns HTTP/2 200.

If you created a Cloudflare WAF rule in Phase 3, toggle it OFF now (👤): Cloudflare → Security → WAF → “Block install and update routes” → OFF.

2. Run the installer wizard

Run https://nonprod.example.com/install with the safest actor split: browser automation drives non-secret wizard screens when available; the human fills secret fields and completes account-creation/authentication transactions.

Decide the browser path.

Condition	Action
Browser automation available	Agent opens an isolated browser instance, navigates to `/install`, and drives every non-secret screen
Browser automation unavailable	User opens `/install` and runs the wizard manually
Secret field or account-creation screen appears	Human completes the credential/account transaction; agent waits, then resumes after the non-secret state exists

✅ The run mode is chosen before any installer field is touched.

Requirements — agent-driven when browser automation exists. Confirm all checks are green, then record the web-SAPI PHP version displayed by the wizard. That screen is the authoritative web PHP cross-check for this environment; it can differ from SSH php -v.
- ✅ Every requirement check is green.
- ✅ The web-SAPI PHP version is recorded in Zaj-PROJECT.md or the phase notes.
File permissions — agent-driven when browser automation exists. Confirm every writable check is green. Reds usually mean the page-3 permission unblock missed a path.
- ✅ Every permissions check is green.
Environment configuration — agent fills non-secret values from Zaj-PROJECT.md and the selected environment’s .env.<env-key> (.env.staging is the simple example): app name, app URL, DB host, DB port, DB username, and DB name. If Database Password is required, it is a human-only field from the project vault. If the vendor labels it optional and falls back to the already-rendered server .env, the agent leaves it blank and proceeds. After the human handles any required secret field, the agent clicks Test Connection and continues.
- ✅ Test Connection succeeds against the selected non-production DB.
- ✅ Required secret fields are human-filled; optional password fields that fall back to .env are left blank; the agent never types or prints passwords.
Admin account — conditional. Some vendors show an admin-create screen; some seed default admin rows instead. If a screen appears, the human completes the account-creation transaction, including password entry and submit. The agent may prepare non-secret context (name and non-production email) for the human to copy, then confirms the new admin login is saved to the project vault without seeing the password. If no screen appears, prove the vendor seeds defaults by citing the seeder grep from Phase 3/installer notes or a bounded post-install user query, then flag every default for Phase 6 rotation.
- ✅ Admin account handled: either created with a human-entered password, or N/A — vendor seeds defaults is proven and every default is flagged for Phase 6 rotation.
Settings — agent-driven when browser automation exists. Confirm app name (e.g. “Your App — QA”) and URL from the selected Zaj-PROJECT.md environment row.
- ✅ App name and URL are set for the selected non-production environment.
Install / Finish — agent-driven when browser automation exists. Click through the install/finish screen and confirm “Installation Complete”.
- ✅ The wizard reports “Installation Complete”.

Use the table to recover from a wizard that won’t load or stalls:

Installer result	Action
Wizard loads	Continue
403 Forbidden	`.htaccess` still blocking — re-run section 1
404	Installer route missing — confirm the app ships one
500	`tail -50 …/deploy/current/storage/logs/laravel.log`
504 Gateway Timeout	PHP timeout too low — confirm `shared/.user.ini` has `max_execution_time = 300` (page 1, step 7), then retry
”Access Denied” mid-wizard	Stale cached config with old DB values — `optimize:clear` with the versioned PHP binary (page 3, step 2), then retry
”Already installed”	Remove `storage/installed` (section 1)

Broken-state 500 on /install — first install only

If a partial/failed migration leaves the database half-built, a 500 can persist. Only on a first install with no real data, reset and retry:

# GUARD FIRST — refuse to wipe a DB that already holds users. `--force` skips
# the interactive prompt, so prose like "first install only" is not a safeguard
   # on a shared/re-run non-production DB. Abort unless the users table is empty (0 rows).
ssh <non-prod-alias> 'cd ~/domains/nonprod.example.com/deploy/current && \
  USERS=$(php artisan tinker --execute="echo \DB::table(\"users\")->count();" 2>/dev/null | tail -1) && \
  if [ "${USERS:-1}" != "0" ]; then echo "ABORT: users table has $USERS row(s) — not a clean first install"; exit 1; fi && \
  php artisan db:wipe --force'
ssh <non-prod-alias> "rm -f ~/domains/nonprod.example.com/deploy/shared/storage/installed"
# then reload /install in the browser

Use db:wipe, not migrate:fresh — the web installer builds the schema correctly, while migrate:fresh can trip over CodeCanyon migration-ordering bugs. This destroys all data — the guard above blocks it once the app holds users; never lift the guard on a DB you care about.

3. Verify the installation

Sign in at /login and walk the post-install checks.

Visit https://nonprod.example.com/login; the human signs in with the admin account, then hands the authenticated browser session back to the agent for checks.

Check Pass
Dashboard loads [ ]
Navigation works [ ]
No PHP errors [ ]
CSS/JS loading [ ]
SSL padlock shows [ ]

If the browser shows a 500, a blank dashboard, or broken assets, tail the Laravel log before continuing:
Terminal window
```
ssh <non-prod-alias> "tail -80 ~/domains/nonprod.example.com/deploy/current/storage/logs/laravel.log"
# Expected: no new fatal error for the login/dashboard request
```
- ✅ Human admin sign-in works, all five post-install checks pass in the post-session browser, and no new fatal log entry appears.

Check	Pass
Dashboard loads	[ ]
Navigation works	[ ]
No PHP errors	[ ]
CSS/JS loading	[ ]
SSL padlock shows	[ ]

4. Re-block `/install` and `/update`

The writable, installable surface must close as soon as the wizard finishes.

Re-comment the blocking rules and confirm /install is forbidden.

ssh <non-prod-alias> 'cd ~/domains/nonprod.example.com/deploy/current/public && \
  grep -q "^# RewriteRule ^install" .htaccess && \
  sed -i "s/^# RewriteRule ^install/RewriteRule ^install/" .htaccess; \
  grep -q "^# RewriteRule ^update" .htaccess && \
  sed -i "s/^# RewriteRule ^update/RewriteRule ^update/" .htaccess; \
  grep -q "^# RewriteRule ^upgrade-script" .htaccess && \
  sed -i "s/^# RewriteRule ^upgrade-script/RewriteRule ^upgrade-script/" .htaccess; \
  echo "install/update re-blocked"'

curl -sI https://nonprod.example.com/install 2>&1 | head -1   # expect HTTP/2 403
# Expected: "install/update re-blocked" then HTTP/2 403

✅ The rules are restored and /install returns HTTP/2 403.

Re-enable the Cloudflare WAF rule if you toggled it off (👤).

5. Re-harden permissions

Walk back the temporary 777 from page 3 to least-privilege.

Restore least-privilege on storage and .env.

# storage: dirs 775, files 664
ssh <non-prod-alias> "cd ~/domains/nonprod.example.com/deploy/shared/storage && \
  find . -type d -exec chmod 775 {} \; && find . -type f -exec chmod 664 {} \;"

# .env: 640
ssh <non-prod-alias> "chmod 640 ~/domains/nonprod.example.com/deploy/shared/.env"
# Expected: storage dirs 775 / files 664; .env 640

✅ Storage dirs are 775, files 664, and .env is 640.

Checklist

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

🔀 Wizard completed — /install reachable (200), browser automation drove all non-secret screens when available, human filled secret fields, and “Installation Complete” shown.
🔀 App verified — browser automation verified login/dashboard when available; all five post-install checks pass; admin login works.
🔀 Routes re-blocked — /install re-blocked (403); Cloudflare WAF rule restored.
🤖 Permissions re-hardened — storage dirs 775 / files 664; .env 640.

Schedule, migrations + schema

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: 4 · Installer + harden
- url: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/05-deploy-staging/04-installer-smoke/
- shelf: Build & Create
- doc_type: implementation playbook
- status: current
- kind: playbook
- category: tech-stack
- subcategory: laravel
- topic: codecanyon
- phase: 5
- part_number: 4 (legacy stepNumber frontmatter)
- legacy_step_number: 4
- est_time: ~20 min
- description: Temporarily unblock /install, run the CodeCanyon web installer wizard, verify the app loads, then immediately re-block /install + /update and re-harden storage and .env permissions from the installer's insecure 777 state.
- tags: codecanyon, laravel, installer, hardening

## Execution rules (binding)
- This is Part 4 of phase 5 (~20 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.

---

# 4 · Installer + harden

## TL;DR

**Objective** — install the app the CodeCanyon way (a web wizard, not artisan migrations): temporarily unblock `/install`, run the wizard against the selected non-production DB from `Zaj-PROJECT.md`, verify the app loads, then immediately re-block `/install` + `/update` and re-harden permissions — because you opened a writable, installable surface to the public web.

**Steps at a glance:**
1. **Temporarily unblock the `/install` route** — Phase 3 added `.htaccess` rules (and possibly a Cloudflare WAF
   rule) blocking `/install`, `/update`, and `/upgrade-script`.
2. **Run the installer wizard** — With browser automation, the agent drives non-secret wizard screens in an
   isolated browser; the human handles every secret field and any admin-account creation transaction.
3. **Verify the installation** — The human signs in once; browser automation resumes after the session exists,
   snapshots the dashboard, and tails logs on errors.
4. **Re-block `/install` and `/update`** — The writable, installable surface must close as soon as the wizard
   finishes.
5. **Re-harden permissions** — Walk back the temporary 777 from page 3 to least-privilege.

:::note[User part + done-when]
**🔀 User part** — the agent drives non-secret `/install` screens when browser automation is available, then pauses for the human to fill every secret field and complete any admin-account creation. For `/login`, the human performs the one sign-in; the agent resumes after the authenticated session exists. Toggling the optional Cloudflare WAF rule is still a dashboard action. An agent drives the `.htaccess` unblock/re-block, permission harden, public curl checks, and post-session browser verification.

**Done when** the wizard reports "Installation Complete", the human-created admin session works, browser evidence exists, `/install` is re-blocked (403), the Cloudflare WAF rule is restored, and permissions are walked back to least-privilege. &nbsp;·&nbsp; **⏱ ~20 min** &nbsp;·&nbsp; 🔀 mixed (🤖 non-secret browser + SSH, 👤 auth/secret fields + WAF fallback).
:::

## Background

CodeCanyon apps install through a web wizard, not artisan migrations. Phase 3 blocked `/install` and `/update` for safety, so this page **temporarily** unblocks them, runs the wizard, then re-blocks and re-hardens. The harden step is not optional — you opened a writable, installable surface to the public web.

## Steps

### 1. Temporarily unblock the `/install` route

Phase 3 added `.htaccess` rules (and possibly a Cloudflare WAF rule) blocking `/install`, `/update`, and `/upgrade-script`. Comment them out so the wizard can load.

<Steps>

1. **Unblock the install routes and remove any stale lock.**

   ```bash
   # Is /install currently blocked?
   ssh <non-prod-alias> "grep 'RewriteRule ^install' ~/domains/nonprod.example.com/deploy/current/public/.htaccess 2>/dev/null"

   # Comment out the blocking rules (idempotent — skip lines already commented)
   ssh <non-prod-alias> 'cd ~/domains/nonprod.example.com/deploy/current/public && \
     grep -q "^RewriteRule ^install" .htaccess && \
     sed -i "s/^RewriteRule ^install/# RewriteRule ^install/" .htaccess; \
     grep -q "^RewriteRule ^update" .htaccess && \
     sed -i "s/^RewriteRule ^update/# RewriteRule ^update/" .htaccess; \
     grep -q "^RewriteRule ^upgrade-script" .htaccess && \
     sed -i "s/^RewriteRule ^upgrade-script/# RewriteRule ^upgrade-script/" .htaccess; \
     echo "install/update unblocked"'

   # Remove any stale install lock
   ssh <non-prod-alias> "rm -f ~/domains/nonprod.example.com/deploy/shared/storage/installed 2>/dev/null && echo 'lock removed'"
   # Expected: "install/update unblocked" and "lock removed"
   ```

   - ✅ The blocking rules are commented out and any stale `installed` lock is removed.

2. **Confirm the wizard is reachable.**

   ```bash
   curl -sI https://nonprod.example.com/install 2>&1 | head -1   # expect HTTP/2 200
   # Expected: HTTP/2 200
   ```

   - ✅ `/install` returns `HTTP/2 200`.

</Steps>

If you created a Cloudflare WAF rule in Phase 3, toggle it **OFF** now (👤): *Cloudflare → Security → WAF → "Block install and update routes" → OFF*.

:::note[A 500 on `/` is still expected here]
The database is empty until the wizard runs — the homepage may 500. You're only confirming `/install` returns 200.
:::

### 2. Run the installer wizard

Run `https://nonprod.example.com/install` with the safest actor split: browser automation drives non-secret wizard screens when available; the human fills secret fields and completes account-creation/authentication transactions.

:::note[Who does this]
🔀 **AI-driven, human supplies secrets/auth** — if claude-in-chrome, Chrome MCP, Playwright, or another browser automation tool is loaded or loadable, the agent drives non-secret wizard screens in an isolated browser instance. For first-time staging setup this is the default path, not an optional courtesy: do not mark the whole wizard human-only just because it runs in a browser. The agent must never type, reveal, or store a password and must never create the admin account: pause at **Database Password** and at any admin-account screen, let the human complete the secret/account transaction from the project vault, then resume after the non-secret screen state exists. If no browser tools exist, the user runs the whole wizard manually.
:::

<Steps>

1. **Decide the browser path.**

   | Condition | Action |
   |---|---|
   | Browser automation available | Agent opens an isolated browser instance, navigates to `/install`, and drives every non-secret screen |
   | Browser automation unavailable | User opens `/install` and runs the wizard manually |
   | Secret field or account-creation screen appears | Human completes the credential/account transaction; agent waits, then resumes after the non-secret state exists |

   - ✅ The run mode is chosen before any installer field is touched.

2. **Requirements** — agent-driven when browser automation exists. Confirm all checks are green, then record the web-SAPI PHP version displayed by the wizard. That screen is the authoritative web PHP cross-check for this environment; it can differ from SSH `php -v`.

   - ✅ Every requirement check is green.
   - ✅ The web-SAPI PHP version is recorded in `Zaj-PROJECT.md` or the phase notes.

3. **File permissions** — agent-driven when browser automation exists. Confirm every writable check is green. Reds usually mean the page-3 permission unblock missed a path.

   - ✅ Every permissions check is green.

4. **Environment configuration** — agent fills non-secret values from `Zaj-PROJECT.md` and the selected environment's `.env.<env-key>` (`.env.staging` is the simple example): app name, app URL, DB host, DB port, DB username, and DB name. If **Database Password** is required, it is a human-only field from the project vault. If the vendor labels it optional and falls back to the already-rendered server `.env`, the agent leaves it blank and proceeds. After the human handles any required secret field, the agent clicks **Test Connection** and continues.

   - ✅ Test Connection succeeds against the selected non-production DB.
   - ✅ Required secret fields are human-filled; optional password fields that fall back to `.env` are left blank; the agent never types or prints passwords.

5. **Admin account** — conditional. Some vendors show an admin-create screen; some seed default admin rows instead. If a screen appears, the human completes the account-creation transaction, including password entry and submit. The agent may prepare non-secret context (name and non-production email) for the human to copy, then confirms the new admin login is saved to the project vault without seeing the password. If no screen appears, prove the vendor seeds defaults by citing the seeder grep from Phase 3/installer notes or a bounded post-install user query, then flag every default for Phase 6 rotation.

   - ✅ Admin account handled: either created with a human-entered password, or `N/A — vendor seeds defaults` is proven and every default is flagged for Phase 6 rotation.

6. **Settings** — agent-driven when browser automation exists. Confirm app name (e.g. "Your App — QA") and URL from the selected `Zaj-PROJECT.md` environment row.

   - ✅ App name and URL are set for the selected non-production environment.

7. **Install / Finish** — agent-driven when browser automation exists. Click through the install/finish screen and confirm "Installation Complete".

   - ✅ The wizard reports "Installation Complete".

</Steps>

:::note[Vendor admin-screen pattern]
WorkDo and Froiden-family installers often seed default admin users instead of showing an admin-create screen. For WorkDo Dash SaaS, the installer may have no admin-password screen, and the DB password field may be optional because the app reads the rendered `.env`; the known seeded defaults are rotated later in Phase 6. Other vendors may require a DB password or add an admin-password field. The rule stays the same: the human handles every required secret, credential, login, or account-creation transaction; the agent fills and verifies the non-secret rest.
:::

Use the table to recover from a wizard that won't load or stalls:

| Installer result | Action |
|---|---|
| Wizard loads | Continue |
| 403 Forbidden | `.htaccess` still blocking — re-run section 1 |
| 404 | Installer route missing — confirm the app ships one |
| 500 | `tail -50 …/deploy/current/storage/logs/laravel.log` |
| 504 Gateway Timeout | PHP timeout too low — confirm `shared/.user.ini` has `max_execution_time = 300` (page 1, step 7), then retry |
| "Access Denied" mid-wizard | Stale cached config with old DB values — `optimize:clear` with the versioned PHP binary (page 3, step 2), then retry |
| "Already installed" | Remove `storage/installed` (section 1) |

:::danger[Broken-state 500 on `/install` — first install only]
If a partial/failed migration leaves the database half-built, a 500 can persist. **Only on a first install with no real data**, reset and retry:

```bash
# GUARD FIRST — refuse to wipe a DB that already holds users. `--force` skips
# the interactive prompt, so prose like "first install only" is not a safeguard
   # on a shared/re-run non-production DB. Abort unless the users table is empty (0 rows).
ssh <non-prod-alias> 'cd ~/domains/nonprod.example.com/deploy/current && \
  USERS=$(php artisan tinker --execute="echo \DB::table(\"users\")->count();" 2>/dev/null | tail -1) && \
  if [ "${USERS:-1}" != "0" ]; then echo "ABORT: users table has $USERS row(s) — not a clean first install"; exit 1; fi && \
  php artisan db:wipe --force'
ssh <non-prod-alias> "rm -f ~/domains/nonprod.example.com/deploy/shared/storage/installed"
# then reload /install in the browser
```

Use `db:wipe`, not `migrate:fresh` — the web installer builds the schema correctly, while `migrate:fresh` can trip over CodeCanyon migration-ordering bugs. This **destroys all data** — the guard above blocks it once the app holds users; never lift the guard on a DB you care about.
:::

### 3. Verify the installation

Sign in and confirm the app is healthy after the wizard.

:::note[Who does this]
🔀 **User login, agent post-session verification** — the agent may navigate to `/login` and snapshot the public form, but 👤 **User** performs the one sign-in transaction. After the authenticated session exists in the isolated browser, 🤖 **Agent** waits for dashboard text, snapshots the dashboard, walks non-secret checks, and checks logs if anything errors. 👤 **User** is fallback only when no browser automation exists after sign-in.
:::

<Steps>

1. **Sign in at `/login` and walk the post-install checks.**

   Visit `https://nonprod.example.com/login`; the human signs in with the admin account, then hands the authenticated browser session back to the agent for checks.

   | Check | Pass |
   |---|---|
   | Dashboard loads | [ ] |
   | Navigation works | [ ] |
   | No PHP errors | [ ] |
   | CSS/JS loading | [ ] |
   | SSL padlock shows | [ ] |

   If the browser shows a 500, a blank dashboard, or broken assets, tail the Laravel log before continuing:

   ```bash
   ssh <non-prod-alias> "tail -80 ~/domains/nonprod.example.com/deploy/current/storage/logs/laravel.log"
   # Expected: no new fatal error for the login/dashboard request
   ```

   - ✅ Human admin sign-in works, all five post-install checks pass in the post-session browser, and no new fatal log entry appears.

</Steps>

### 4. Re-block `/install` and `/update`

The writable, installable surface must close as soon as the wizard finishes.

<Steps>

1. **Re-comment the blocking rules and confirm `/install` is forbidden.**

   ```bash
   ssh <non-prod-alias> 'cd ~/domains/nonprod.example.com/deploy/current/public && \
     grep -q "^# RewriteRule ^install" .htaccess && \
     sed -i "s/^# RewriteRule ^install/RewriteRule ^install/" .htaccess; \
     grep -q "^# RewriteRule ^update" .htaccess && \
     sed -i "s/^# RewriteRule ^update/RewriteRule ^update/" .htaccess; \
     grep -q "^# RewriteRule ^upgrade-script" .htaccess && \
     sed -i "s/^# RewriteRule ^upgrade-script/RewriteRule ^upgrade-script/" .htaccess; \
     echo "install/update re-blocked"'

   curl -sI https://nonprod.example.com/install 2>&1 | head -1   # expect HTTP/2 403
   # Expected: "install/update re-blocked" then HTTP/2 403
   ```

   - ✅ The rules are restored and `/install` returns `HTTP/2 403`.

</Steps>

Re-enable the Cloudflare WAF rule if you toggled it off (👤).

:::danger[Do not skip the re-block]
An installable, world-writable app on the public web can be reinstalled by anyone who finds `/install`, wiping or hijacking the database. Re-blocking and re-hardening are part of "the installer ran," not a follow-up nicety.
:::

### 5. Re-harden permissions

Walk back the temporary 777 from page 3 to least-privilege.

<Steps>

1. **Restore least-privilege on storage and `.env`.**

   ```bash
   # storage: dirs 775, files 664
   ssh <non-prod-alias> "cd ~/domains/nonprod.example.com/deploy/shared/storage && \
     find . -type d -exec chmod 775 {} \; && find . -type f -exec chmod 664 {} \;"

   # .env: 640
   ssh <non-prod-alias> "chmod 640 ~/domains/nonprod.example.com/deploy/shared/.env"
   # Expected: storage dirs 775 / files 664; .env 640
   ```

   - ✅ Storage dirs are `775`, files `664`, and `.env` is `640`.

</Steps>

## Checklist

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

- [ ] **🔀 Wizard completed** — `/install` reachable (200), browser automation drove all non-secret screens when available, human filled secret fields, and "Installation Complete" shown.
- [ ] **🔀 App verified** — browser automation verified login/dashboard when available; all five post-install checks pass; admin login works.
- [ ] **🔀 Routes re-blocked** — `/install` re-blocked (403); Cloudflare WAF rule restored.
- [ ] **🤖 Permissions re-hardened** — storage dirs `775` / files `664`; `.env` `640`.

:::next[Next step]
[Schedule, migrations + schema](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/05-deploy-staging/05-secure-verify-schema/)
:::

# 4 · Installer + harden

> Source: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/05-deploy-staging/04-installer-smoke/

## TL;DR

**Objective** — install the app the CodeCanyon way (a web wizard, not artisan migrations): temporarily unblock `/install`, run the wizard against the selected non-production DB from `Zaj-PROJECT.md`, verify the app loads, then immediately re-block `/install` + `/update` and re-harden permissions — because you opened a writable, installable surface to the public web.

**Steps at a glance:**
1. **Temporarily unblock the `/install` route** — Phase 3 added `.htaccess` rules (and possibly a Cloudflare WAF
   rule) blocking `/install`, `/update`, and `/upgrade-script`.
2. **Run the installer wizard** — With browser automation, the agent drives non-secret wizard screens in an
   isolated browser; the human handles every secret field and any admin-account creation transaction.
3. **Verify the installation** — The human signs in once; browser automation resumes after the session exists,
   snapshots the dashboard, and tails logs on errors.
4. **Re-block `/install` and `/update`** — The writable, installable surface must close as soon as the wizard
   finishes.
5. **Re-harden permissions** — Walk back the temporary 777 from page 3 to least-privilege.

:::note[User part + done-when]
**🔀 User part** — the agent drives non-secret `/install` screens when browser automation is available, then pauses for the human to fill every secret field and complete any admin-account creation. For `/login`, the human performs the one sign-in; the agent resumes after the authenticated session exists. Toggling the optional Cloudflare WAF rule is still a dashboard action. An agent drives the `.htaccess` unblock/re-block, permission harden, public curl checks, and post-session browser verification.

**Done when** the wizard reports "Installation Complete", the human-created admin session works, browser evidence exists, `/install` is re-blocked (403), the Cloudflare WAF rule is restored, and permissions are walked back to least-privilege. &nbsp;·&nbsp; **⏱ ~20 min** &nbsp;·&nbsp; 🔀 mixed (🤖 non-secret browser + SSH, 👤 auth/secret fields + WAF fallback).
:::

## Background

CodeCanyon apps install through a web wizard, not artisan migrations. Phase 3 blocked `/install` and `/update` for safety, so this page **temporarily** unblocks them, runs the wizard, then re-blocks and re-hardens. The harden step is not optional — you opened a writable, installable surface to the public web.

## Steps

### 1. Temporarily unblock the `/install` route

Phase 3 added `.htaccess` rules (and possibly a Cloudflare WAF rule) blocking `/install`, `/update`, and `/upgrade-script`. Comment them out so the wizard can load.

<Steps>

1. **Unblock the install routes and remove any stale lock.**

   ```bash
   # Is /install currently blocked?
   ssh <non-prod-alias> "grep 'RewriteRule ^install' ~/domains/nonprod.example.com/deploy/current/public/.htaccess 2>/dev/null"

   # Comment out the blocking rules (idempotent — skip lines already commented)
   ssh <non-prod-alias> 'cd ~/domains/nonprod.example.com/deploy/current/public && \
     grep -q "^RewriteRule ^install" .htaccess && \
     sed -i "s/^RewriteRule ^install/# RewriteRule ^install/" .htaccess; \
     grep -q "^RewriteRule ^update" .htaccess && \
     sed -i "s/^RewriteRule ^update/# RewriteRule ^update/" .htaccess; \
     grep -q "^RewriteRule ^upgrade-script" .htaccess && \
     sed -i "s/^RewriteRule ^upgrade-script/# RewriteRule ^upgrade-script/" .htaccess; \
     echo "install/update unblocked"'

   # Remove any stale install lock
   ssh <non-prod-alias> "rm -f ~/domains/nonprod.example.com/deploy/shared/storage/installed 2>/dev/null && echo 'lock removed'"
   # Expected: "install/update unblocked" and "lock removed"
   ```

   - ✅ The blocking rules are commented out and any stale `installed` lock is removed.

2. **Confirm the wizard is reachable.**

   ```bash
   curl -sI https://nonprod.example.com/install 2>&1 | head -1   # expect HTTP/2 200
   # Expected: HTTP/2 200
   ```

   - ✅ `/install` returns `HTTP/2 200`.

</Steps>

If you created a Cloudflare WAF rule in Phase 3, toggle it **OFF** now (👤): *Cloudflare → Security → WAF → "Block install and update routes" → OFF*.

:::note[A 500 on `/` is still expected here]
The database is empty until the wizard runs — the homepage may 500. You're only confirming `/install` returns 200.
:::

### 2. Run the installer wizard

Run `https://nonprod.example.com/install` with the safest actor split: browser automation drives non-secret wizard screens when available; the human fills secret fields and completes account-creation/authentication transactions.

:::note[Who does this]
🔀 **AI-driven, human supplies secrets/auth** — if claude-in-chrome, Chrome MCP, Playwright, or another browser automation tool is loaded or loadable, the agent drives non-secret wizard screens in an isolated browser instance. For first-time staging setup this is the default path, not an optional courtesy: do not mark the whole wizard human-only just because it runs in a browser. The agent must never type, reveal, or store a password and must never create the admin account: pause at **Database Password** and at any admin-account screen, let the human complete the secret/account transaction from the project vault, then resume after the non-secret screen state exists. If no browser tools exist, the user runs the whole wizard manually.
:::

<Steps>

1. **Decide the browser path.**

   | Condition | Action |
   |---|---|
   | Browser automation available | Agent opens an isolated browser instance, navigates to `/install`, and drives every non-secret screen |
   | Browser automation unavailable | User opens `/install` and runs the wizard manually |
   | Secret field or account-creation screen appears | Human completes the credential/account transaction; agent waits, then resumes after the non-secret state exists |

   - ✅ The run mode is chosen before any installer field is touched.

2. **Requirements** — agent-driven when browser automation exists. Confirm all checks are green, then record the web-SAPI PHP version displayed by the wizard. That screen is the authoritative web PHP cross-check for this environment; it can differ from SSH `php -v`.

   - ✅ Every requirement check is green.
   - ✅ The web-SAPI PHP version is recorded in `Zaj-PROJECT.md` or the phase notes.

3. **File permissions** — agent-driven when browser automation exists. Confirm every writable check is green. Reds usually mean the page-3 permission unblock missed a path.

   - ✅ Every permissions check is green.

4. **Environment configuration** — agent fills non-secret values from `Zaj-PROJECT.md` and the selected environment's `.env.<env-key>` (`.env.staging` is the simple example): app name, app URL, DB host, DB port, DB username, and DB name. If **Database Password** is required, it is a human-only field from the project vault. If the vendor labels it optional and falls back to the already-rendered server `.env`, the agent leaves it blank and proceeds. After the human handles any required secret field, the agent clicks **Test Connection** and continues.

   - ✅ Test Connection succeeds against the selected non-production DB.
   - ✅ Required secret fields are human-filled; optional password fields that fall back to `.env` are left blank; the agent never types or prints passwords.

5. **Admin account** — conditional. Some vendors show an admin-create screen; some seed default admin rows instead. If a screen appears, the human completes the account-creation transaction, including password entry and submit. The agent may prepare non-secret context (name and non-production email) for the human to copy, then confirms the new admin login is saved to the project vault without seeing the password. If no screen appears, prove the vendor seeds defaults by citing the seeder grep from Phase 3/installer notes or a bounded post-install user query, then flag every default for Phase 6 rotation.

   - ✅ Admin account handled: either created with a human-entered password, or `N/A — vendor seeds defaults` is proven and every default is flagged for Phase 6 rotation.

6. **Settings** — agent-driven when browser automation exists. Confirm app name (e.g. "Your App — QA") and URL from the selected `Zaj-PROJECT.md` environment row.

   - ✅ App name and URL are set for the selected non-production environment.

7. **Install / Finish** — agent-driven when browser automation exists. Click through the install/finish screen and confirm "Installation Complete".

   - ✅ The wizard reports "Installation Complete".

</Steps>

:::note[Vendor admin-screen pattern]
WorkDo and Froiden-family installers often seed default admin users instead of showing an admin-create screen. For WorkDo Dash SaaS, the installer may have no admin-password screen, and the DB password field may be optional because the app reads the rendered `.env`; the known seeded defaults are rotated later in Phase 6. Other vendors may require a DB password or add an admin-password field. The rule stays the same: the human handles every required secret, credential, login, or account-creation transaction; the agent fills and verifies the non-secret rest.
:::

Use the table to recover from a wizard that won't load or stalls:

| Installer result | Action |
|---|---|
| Wizard loads | Continue |
| 403 Forbidden | `.htaccess` still blocking — re-run section 1 |
| 404 | Installer route missing — confirm the app ships one |
| 500 | `tail -50 …/deploy/current/storage/logs/laravel.log` |
| 504 Gateway Timeout | PHP timeout too low — confirm `shared/.user.ini` has `max_execution_time = 300` (page 1, step 7), then retry |
| "Access Denied" mid-wizard | Stale cached config with old DB values — `optimize:clear` with the versioned PHP binary (page 3, step 2), then retry |
| "Already installed" | Remove `storage/installed` (section 1) |

:::danger[Broken-state 500 on `/install` — first install only]
If a partial/failed migration leaves the database half-built, a 500 can persist. **Only on a first install with no real data**, reset and retry:

```bash
# GUARD FIRST — refuse to wipe a DB that already holds users. `--force` skips
# the interactive prompt, so prose like "first install only" is not a safeguard
   # on a shared/re-run non-production DB. Abort unless the users table is empty (0 rows).
ssh <non-prod-alias> 'cd ~/domains/nonprod.example.com/deploy/current && \
  USERS=$(php artisan tinker --execute="echo \DB::table(\"users\")->count();" 2>/dev/null | tail -1) && \
  if [ "${USERS:-1}" != "0" ]; then echo "ABORT: users table has $USERS row(s) — not a clean first install"; exit 1; fi && \
  php artisan db:wipe --force'
ssh <non-prod-alias> "rm -f ~/domains/nonprod.example.com/deploy/shared/storage/installed"
# then reload /install in the browser
```

Use `db:wipe`, not `migrate:fresh` — the web installer builds the schema correctly, while `migrate:fresh` can trip over CodeCanyon migration-ordering bugs. This **destroys all data** — the guard above blocks it once the app holds users; never lift the guard on a DB you care about.
:::

### 3. Verify the installation

Sign in and confirm the app is healthy after the wizard.

:::note[Who does this]
🔀 **User login, agent post-session verification** — the agent may navigate to `/login` and snapshot the public form, but 👤 **User** performs the one sign-in transaction. After the authenticated session exists in the isolated browser, 🤖 **Agent** waits for dashboard text, snapshots the dashboard, walks non-secret checks, and checks logs if anything errors. 👤 **User** is fallback only when no browser automation exists after sign-in.
:::

<Steps>

1. **Sign in at `/login` and walk the post-install checks.**

   Visit `https://nonprod.example.com/login`; the human signs in with the admin account, then hands the authenticated browser session back to the agent for checks.

   | Check | Pass |
   |---|---|
   | Dashboard loads | [ ] |
   | Navigation works | [ ] |
   | No PHP errors | [ ] |
   | CSS/JS loading | [ ] |
   | SSL padlock shows | [ ] |

   If the browser shows a 500, a blank dashboard, or broken assets, tail the Laravel log before continuing:

   ```bash
   ssh <non-prod-alias> "tail -80 ~/domains/nonprod.example.com/deploy/current/storage/logs/laravel.log"
   # Expected: no new fatal error for the login/dashboard request
   ```

   - ✅ Human admin sign-in works, all five post-install checks pass in the post-session browser, and no new fatal log entry appears.

</Steps>

### 4. Re-block `/install` and `/update`

The writable, installable surface must close as soon as the wizard finishes.

<Steps>

1. **Re-comment the blocking rules and confirm `/install` is forbidden.**

   ```bash
   ssh <non-prod-alias> 'cd ~/domains/nonprod.example.com/deploy/current/public && \
     grep -q "^# RewriteRule ^install" .htaccess && \
     sed -i "s/^# RewriteRule ^install/RewriteRule ^install/" .htaccess; \
     grep -q "^# RewriteRule ^update" .htaccess && \
     sed -i "s/^# RewriteRule ^update/RewriteRule ^update/" .htaccess; \
     grep -q "^# RewriteRule ^upgrade-script" .htaccess && \
     sed -i "s/^# RewriteRule ^upgrade-script/RewriteRule ^upgrade-script/" .htaccess; \
     echo "install/update re-blocked"'

   curl -sI https://nonprod.example.com/install 2>&1 | head -1   # expect HTTP/2 403
   # Expected: "install/update re-blocked" then HTTP/2 403
   ```

   - ✅ The rules are restored and `/install` returns `HTTP/2 403`.

</Steps>

Re-enable the Cloudflare WAF rule if you toggled it off (👤).

:::danger[Do not skip the re-block]
An installable, world-writable app on the public web can be reinstalled by anyone who finds `/install`, wiping or hijacking the database. Re-blocking and re-hardening are part of "the installer ran," not a follow-up nicety.
:::

### 5. Re-harden permissions

Walk back the temporary 777 from page 3 to least-privilege.

<Steps>

1. **Restore least-privilege on storage and `.env`.**

   ```bash
   # storage: dirs 775, files 664
   ssh <non-prod-alias> "cd ~/domains/nonprod.example.com/deploy/shared/storage && \
     find . -type d -exec chmod 775 {} \; && find . -type f -exec chmod 664 {} \;"

   # .env: 640
   ssh <non-prod-alias> "chmod 640 ~/domains/nonprod.example.com/deploy/shared/.env"
   # Expected: storage dirs 775 / files 664; .env 640
   ```

   - ✅ Storage dirs are `775`, files `664`, and `.env` is `640`.

</Steps>

## Checklist

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

- [ ] **🔀 Wizard completed** — `/install` reachable (200), browser automation drove all non-secret screens when available, human filled secret fields, and "Installation Complete" shown.
- [ ] **🔀 App verified** — browser automation verified login/dashboard when available; all five post-install checks pass; admin login works.
- [ ] **🔀 Routes re-blocked** — `/install` re-blocked (403); Cloudflare WAF rule restored.
- [ ] **🤖 Permissions re-hardened** — storage dirs `775` / files `664`; `.env` `640`.

:::next[Next step]
[Schedule, migrations + schema](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/05-deploy-staging/05-secure-verify-schema/)
:::