# Server Acceptance Checklist

Complete this after deploying a specific release. Mark exactly one of **Pass**, **Fail**, or **N/A** for every check and explain failures or N/A decisions in **Notes**.

## Record

- Commit SHA:
- Artifact name:
- Deployment date:
- Tester:
- Server PHP version:
- MySQL version:
- Web server:
- Deployment method:
- Active application URL:
- Date/time (UTC):
- Tester organization:
- Environment:
- Server/hosting provider and region:
- Artifact checksum:
- Deployment operator:
- Previous release/rollback target:
- Overall result (Accepted / Accepted with conditions / Rejected):

## Checks

| # | Check | Pass | Fail | N/A | Notes |
|---:|---|:---:|:---:|:---:|---|
| 1 | The homepage loads over HTTPS with a valid trusted certificate, and HTTP redirects to HTTPS. | ☐ | ☐ | ☐ | |
| 2 | CSS, JavaScript, fonts, icons, and images load from the deployed assets. | ☐ | ☐ | ☐ | |
| 3 | The homepage and assets produce no mixed-content warnings. | ☐ | ☐ | ☐ | |
| 4 | Registration creates a customer account according to the approved production policy. | ☐ | ☐ | ☐ | |
| 5 | Login succeeds with valid customer credentials and fails safely with invalid credentials. | ☐ | ☐ | ☐ | |
| 6 | Logout ends the authenticated session and protected pages require login again. | ☐ | ☐ | ☐ | |
| 7 | A password reset request is accepted without exposing whether an account exists, and configured mail handling is observed. | ☐ | ☐ | ☐ | |
| 8 | Email verification works end to end, or the environment's documented mail limitation is confirmed. | ☐ | ☐ | ☐ | |
| 9 | A newly registered or designated non-admin account has the customer role. | ☐ | ☐ | ☐ | |
| 10 | A customer is denied access to the Filament `/admin` panel. | ☐ | ☐ | ☐ | |
| 11 | An approved administrator is allowed to access the Filament `/admin` panel. | ☐ | ☐ | ☐ | |
| 12 | The administrator can view the user listing. | ☐ | ☐ | ☐ | |
| 13 | Unauthorized users cannot change roles or permissions through UI or direct requests. | ☐ | ☐ | ☐ | |
| 14 | All repository migrations completed successfully and the production schema is current. | ☐ | ☐ | ☐ | |
| 15 | `storage/` and `bootstrap/cache/` are writable by the intended process without broad unsafe permissions. | ☐ | ☐ | ☐ | |
| 16 | Application and worker logs contain no critical errors caused by the deployed release. | ☐ | ☐ | ☐ | |
| 17 | Debug output is disabled in production (`APP_DEBUG=false`). | ☐ | ☐ | ☐ | |
| 18 | The selected queue driver behaves as configured; an asynchronous driver processes a representative job, while `sync` executes inline. | ☐ | ☐ | ☐ | |
| 19 | Application cache clear/warm commands complete successfully for the selected cache store. | ☐ | ☐ | ☐ | |
| 20 | 404 and representative application error pages reveal no stack traces, secrets, paths, or other sensitive data. | ☐ | ☐ | ☐ | |

## Sign-off

- Blocking failures:
- Conditions/follow-up owner and due date:
- Evidence location (restricted; no secrets or PII):
- Tester signature/date:
- Project owner signature/date:

This checklist is blank because no server validation or deployment occurred during documentation preparation.