# Phase 1 Acceptance Gate

Mark every item only after testing on the real staging server.

## Deployment integrity

- [ ] Application lives outside a publicly browsable directory; only `public/` is the document root.
- [ ] PHP is 8.3 or later and Composer installed cleanly with no unresolved security advisories.
- [ ] `.env` is private, `APP_DEBUG=false`, HTTPS is enforced, and no credentials are in the ZIP or repository.
- [ ] Database uses a dedicated user and current encrypted backups exist.
- [ ] `php artisan test` passes on staging-equivalent PHP and database versions.

## Public website

- [ ] Homepage, favicon, header mark, footer logo, theme toggle, language toggle, and responsive navigation are visually correct at 320, 375, 481, 768, 1024, and 1440 pixels.
- [ ] Hero content is fully understandable on a typical laptop viewport without an unnecessary initial scroll.
- [ ] Privacy Policy and Terms of Service support both themes.
- [ ] Staging returns `noindex` directives and `robots.txt` blocks crawling.
- [ ] Contact form is disabled, clearly labelled as a preview, and sends/stores nothing.
- [ ] Email and WhatsApp links use the correct ZumaX destinations.

## Identity and access

- [ ] `/office/register` does not exist.
- [ ] Owner was created with `php artisan zumax:create-owner`; no password appears in shell history.
- [ ] Inactive accounts cannot sign in or retain a session.
- [ ] Users without `office.view` receive 403.
- [ ] Six seeded roles and their permissions match the accepted blueprint.
- [ ] Owner has unrestricted access; Auditor remains read-only.

## Two-factor authentication

- [ ] Every authenticated user without confirmed TOTP is restricted to the Security page.
- [ ] Password confirmation is required before enabling, disabling, or regenerating 2FA data.
- [ ] QR setup and six-digit confirmation work with at least two mainstream authenticator apps.
- [ ] Recovery codes are shown, saved securely, single-use, and can be regenerated.
- [ ] Disabling 2FA immediately blocks operational access until setup is repeated.
- [ ] Login and 2FA endpoints rate-limit repeated failures.

## Audit and privacy

- [ ] Successful login, failed login, lockout, logout, password changes, 2FA changes, and Owner creation create activity records.
- [ ] Each web response includes `X-Request-ID`; activity records can be correlated to it.
- [ ] Activity records contain only keyed IP hashes; any raw IP is limited to short-lived session infrastructure and normal host access logs under documented retention.
- [ ] Passwords, tokens, 2FA secrets, and recovery codes never appear in logs or activity `changes`.
- [ ] Activity records cannot be edited or deleted through application models.
- [ ] Security headers are present and office responses use `Cache-Control: no-store`.

## Operational handoff

- [ ] `APP_KEY`, database, `.env`, and recovery procedure are backed up securely.
- [ ] SMTP password recovery works from `no-reply@zumaxenterprises.com`; SPF, DKIM, and DMARC pass.
- [ ] At least two Owner recovery-code copies are stored separately under business control.
- [ ] The current public site and its verified enquiry process remain available as rollback.
- [ ] Phase 2 requirements are approved before any public form or message database is activated.

Acceptance decision: **Do not promote Phase 1 directly to production.** Approval means the foundation may be used as the base for Phase 2.