who_need_help/docs/public-launch-checklist.md

# 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

- [x] Record the candidate Git revision and immutable image references for the
      services that actually exist in the target topology, plus the externally
      hosted database version. Production has no project-local PostGIS or
      socket-proxy container.
- [x] Confirm that the target is the independent production checkout, Compose
      project, database, volumes, secrets, Google/Firebase project, SMTP
      credentials, and Android identity.
- [x] Keep development, hackathon test, and production credentials separate.
- [x] Run the repository quality suite and retain its non-secret evidence.

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

The 2026-08-09 isolated run covering the E2E-cleanup implementation now
committed as `3c731b5` exited successfully: 451 ExUnit tests passed, all
configured compiler/format/xref/Credo/Sobelow/Dialyzer/dependency/container/
Compose/Helm/migration/rollback/observability gates passed, and the final
runtime image scan reported zero detected vulnerabilities. The final
manifest-transport-only shell adjustment then passed `bash -n`, ShellCheck,
and the complete production browser E2E replay. Exact identities and evidence
paths are recorded in `docs/verification.md`.

A later 2026-08-09 local browser replay passed all 17 Chromium scenarios,
including the new end-to-end support and legal-removal workflow. Its focused
and full structured results are recorded in `docs/verification.md`. This is
local isolated evidence only and does not mark the production support/legal or
SMTP checklist items complete.

The latest complete local rerun on 2026-08-10 passed 459 ExUnit tests,
fourteen browser-asset tests, every configured quality/security gate, and the
final image scans after updating Phoenix LiveView from advisory-affected
`1.2.8` to patched `1.2.9`. Exact unit, timing, memory, cleanup, and dependency
evidence are recorded in `docs/verification.md`.

The current 2026-08-12 launch-boundary rerun passed 462 ExUnit tests, fourteen
browser map-asset tests, the migration-registry completeness check, all
configured quality/security and production-release drills, and the final image
scans with zero detected vulnerabilities. The isolated unit completed in
4 minutes 47.572 seconds with a measured 222.3 MiB memory peak and left no
run-scoped container or temporary image. Exact email-flow and migration evidence
is recorded in `docs/verification.md`.

## 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

- [x] 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.
- [x] A production-generated authentication email reaches an external mailbox
      and is DKIM-signed by the production domain.
- [ ] Authentication-email action URLs use the production domain directly.
      Brevo currently rewrites the action href through its tracking domain even
      though the visible fallback origin is `https://whoneedhelp.com/`.
- [x] The Web Push provider accepts a production notification for a real active
      browser subscription without disabling the device.
- [ ] A person has observed the resulting operating-system browser notification
      and its navigation target on the subscribed workstation.
- [x] 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.