# Go-live checklist

Use this checklist in a production-like environment before admitting real users or
institutional data. Record the date, evidence location, and accountable owner for
every item. Any unchecked critical item blocks launch.

## Ownership and approval

- [ ] Executive go-live approval is recorded.
- [ ] Deployment, rollback, incident-response, privacy, finance, and academic-record
      owners are named and contactable.
- [ ] The maintenance window and user communication are approved.
- [ ] Privacy, retention, regulatory, and institutional policy reviews are complete.

## Infrastructure and secrets

- [ ] Production DNS and TLS are externally validated.
- [ ] `APP_ENV=production`, `APP_DEBUG=false`, and the canonical HTTPS `APP_URL` are
      confirmed.
- [ ] MySQL/MariaDB, Redis, private object storage, SMTP, and payment credentials use
      the production secret-management process.
- [ ] Database, Redis, storage, and application nodes are private and access-controlled.
- [ ] Demo credentials are absent from production.
- [ ] Nginx, PHP-FPM, queue workers, and the scheduler use restricted service accounts.

## Security and integrations

- [ ] Payment initiation, signed and duplicate callbacks, reconciliation, reversal,
      and refund paths pass in every provider sandbox.
- [ ] Email delivery, bounce handling, and sender-domain authentication are verified.
- [ ] Production malware scanning is connected to the private upload workflow.
- [ ] A security review and penetration test have no unresolved critical or
      high-severity findings.
- [ ] Manual keyboard, screen-reader, browser, and mobile-device testing is signed off.
- [ ] Any accepted CSP `unsafe-eval` risk is recorded, or Alpine uses its
      CSP-compatible build.

## Data, backup, and recovery

- [ ] Encrypted database and private-object backups complete successfully.
- [ ] Checksums and retention policies are verified.
- [ ] A restore into an isolated environment succeeds and is functionally checked.
- [ ] Recovery point and recovery time objectives are approved.
- [ ] Migrations are forward-compatible with the preceding application release.

## Capacity and observability

- [ ] Representative load testing covers registration, finance, results, LMS, CBT,
      reports, and public pages.
- [ ] Database, Redis, queues, PHP workers, and storage remain within agreed limits.
- [ ] Centralized logs redact secrets and personal data and have approved retention.
- [ ] Alerts cover `/up`, `/ready`, errors, latency, database saturation, queues,
      scheduler silence, storage, payment webhooks, and email.
- [ ] Alert delivery and escalation are tested with the named on-call owner.

## Deployment verification

- [ ] The exact release passes all tests, dependency audits, and the production build.
- [ ] The current backup and tested previous release are available.
- [ ] `deploy/deploy.sh` completes and migrations report current.
- [ ] `/up` and `/ready` succeed through the public production route.
- [ ] Authentication, authorization, tenant isolation, queues, scheduler, email,
      storage, one payment callback, and one authorized download pass.
- [ ] Applicant, student, lecturer, Registrar, Bursar, Examination Officer, and
      administrator role smoke tests pass.

## Launch and observation

- [ ] The rollback threshold and decision-maker are recorded.
- [ ] Errors, latency, slow queries, queues, webhooks, email, and storage are observed
      throughout the launch window.
- [ ] Support and incident channels are staffed.
- [ ] Evidence, exceptions, approvals, and final signatories are archived.

If a post-deployment check fails, stop user admission and follow
[Production deployment](DEPLOYMENT.md). Do not automatically reverse production
migrations; use a corrective migration where required.