# Public launch checklist

This checklist separates properties the repository can verify from decisions
that require the operator, a provider, or jurisdiction-specific legal review.
Checking a box is an operator record, not proof created by the application.
Do not replace unknown values with estimates.

## 1. Freeze the candidate

- [ ] Record the candidate Git revision and immutable application, PostGIS,
      socket-proxy, and edge image references.
- [ ] Confirm that the target is the independent production checkout, Compose
      project, database, volumes, secrets, Google/Firebase project, SMTP
      credentials, and Android identity.
- [ ] Keep development, hackathon test, and production credentials separate.
- [ ] Run the repository quality suite and retain its non-secret evidence.

```bash
git rev-parse HEAD
./scripts/quality.sh
```

## 2. Verify production configuration without exposing secrets

Run both checks against the single ignored production `.env`. The first reports
capabilities; the second additionally enforces the repository's release
requirements.

```bash
./scripts/validate-production-env.sh .env whoneedhelp.com
./scripts/check-environment-readiness.sh .env --require-release
```

The release check covers the application origin and secrets, database
selection, SMTP and support routing, Google OAuth, browser VAPID, Firebase/FCM,
Android package/signing configuration, and production App Links. It does not
prove that external providers will deliver successfully after deployment.

## 3. Record human and legal decisions

The following decisions are intentionally not generated by code:

- [ ] Launch jurisdictions and the exact local emergency contacts shown to
      users have been approved.
- [ ] Privacy notice, Terms, medicine/prohibited-items guidance, and voluntary
      payment/reimbursement wording have been reviewed for those jurisdictions.
- [ ] A retention and anonymisation schedule defines each account, safety,
      dispute, moderation, support, legal, tracking-evidence, and backup record.
- [ ] The account-deletion executor and operator procedure have been approved
      and tested against that schedule before destructive execution is enabled.
- [ ] Moderation, support, privacy, account-deletion, content-removal, and
      incident queues have named owners and monitored contact paths.
- [ ] Provider terms and capacity are approved for email, map tiles, Google
      identity, Web Push, Firebase/FCM, database hosting, backups, and monitoring.
- [ ] Google Analytics for Firebase remains disabled until the operator has
      approved a purpose and event allow-list, updated the privacy notice,
      implemented an explicit user analytics preference, and verified that the
      Android client does not initialise Analytics before the user opts in.
      Analytics events must not contain email addresses, account or device
      identifiers owned by Who Need Help, request/chat/support text, medicine
      details, exact or approximate coordinates, handover codes, social-account
      data, or moderation and safety evidence. The initial useful event set is
      limited to coarse product milestones such as `registration_completed`,
      `request_created`, `helper_joined`, `handover_completed`, and
      `push_opened`; every event and parameter requires a privacy review before
      release. Enabling Firebase Analytics later is a separate change from the
      server-side `ProductAnalytics` context, which stores only allow-listed
      daily aggregate counters without user identifiers.
- [ ] Representative load measurements from the intended host and traffic shape
      justify database pools, action-limit policies, replica counts, memory/CPU
      allocation, alerts, and any scaling thresholds.
- [ ] Backup ownership, encryption-key custody, off-site destination, restore
      procedure, and measured recovery objectives have been approved.

Until the retention decision and tested executor exist, account-deletion cases
remain an audited operator workflow and automatic erasure stays disabled. The
software must not claim that an unresolved legal or operational item is
complete.

## 4. Rehearse recovery before promotion

Create a current custom-format backup and restore it only into the isolated
drill database. Then rehearse the current release against that backup.

```bash
backup_output=$(./scripts/backup-compose.sh)
backup_path=$(printf '%s\n' "$backup_output" | sed -n 's/^Backup: //p')
./scripts/restore-drill-compose.sh "$backup_path"
./scripts/upgrade-rehearsal-compose.sh "$backup_path"
./scripts/production-rollback-drill.sh
```

Local backups and local MinIO drills verify mechanics but are not proof of
off-site durability or a production recovery policy.

The implemented external workflow can be rehearsed without restoring over the
source database:

```bash
./scripts/bootstrap-restic.sh
./scripts/production-offsite-backup.sh plan
./scripts/production-offsite-backup.sh run
systemctl --user status who-need-help-production-backup.service --no-pager
ssh buyvm-maya \
  'systemctl --user status who-need-help-production-monitor.timer --no-pager'
```

Do not mark backup ownership complete merely because this command passes. The
operator must still store the Restic key independently and approve retention,
RPO, RTO, capacity, and responsible owners.

## 5. Promote with an explicit rollback point

Use the release workflow in `docs/operations.md`; do not copy mutable source
over a running production checkout. A successful release must retain the
generated rollback manifest, the pre-release backup checksum/catalog, and the
previous immutable image references. A forward-only migration must be treated
as forward-only rather than receiving an invented database rollback.

## 6. Verify the deployed product

- [ ] Public HTTPS home, liveness, readiness, WebSocket upgrade, manifest, and
      `assetlinks.json` return the expected production identity.
- [ ] Registration, returning-user login, and settings linking complete against
      the production Google OAuth client and exact callback origin.
- [ ] A production-generated authentication email reaches an external mailbox;
      sender identity and every URL use the production domain.
- [ ] Browser Web Push reaches a real subscribed browser.
- [ ] The production Android build signs in, opens verified App Links, receives
      FCM, and performs user-started foreground location sharing on a physical
      device.
- [x] The full two-person help flow passes: create, discover, accept, chat,
      optional tracking, start, handover code, both confirmations, blind review,
      report/block, and notification delivery.
- [x] The Activity flow passes: create, request to join, approve/decline,
      withdraw, rejoin, group chat, exact-location disclosure only after
      approval, and reporting.
- [ ] Support, privacy/data, account-deletion, general content-removal, and
      TAKE IT DOWN submissions reach the correct production operator queues.
- [ ] Database, application, worker, email, push, backup, and edge monitoring
      are visible to the responsible operator.

Record observed timestamps, revision/image identities, and non-secret evidence
paths in `docs/verification.md`. Record failed checks as failed; do not convert
them into documentation-only success.