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

• 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.

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.

./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.

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.

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.
• 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.
• 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.