Refresh Play and launch verification records

docs/google-play-pre-upload-audit-2026-08-03.md

@@ -38,9 +38,15 @@ require Play Console. It contains no account credentials or signing keys.
 - The Play application exists as app ID `4972430103169452589`, package
   `org.whoneedhelp.mobile`; it is a free app, not a game, with no ads.
 - Play App Signing was accepted.
-- The exact version-code `1` release AAB is retained in an internal-testing
+- The exact version-code `1` release AAB is active only on the Internal testing
-  draft. The internal release is not yet available to testers, so its
+  track as `0.1.0 internal verification`.
-  Play-generated signing identity and Play-delivered behavior remain unknown.
+- Every Play App Signing identity displayed for the accepted artifact was
+  recorded outside Git and reconciled with production Firebase, Google OAuth,
+  and Android App Links.
+- The Play-delivered build passed installer/signature/domain verification,
+  production Google sign-in, verified App Links, production FCM, foreground
+  location while minimized, notification Stop, offline recovery, process
+  recreation, and exact fixture cleanup on the authorised physical phone.
 
 ## Required before Play review
 
@@ -62,18 +68,15 @@ require Play Console. It contains no account credentials or signing keys.
 - Recheck the store listing, screenshots, support contact, and privacy-policy
   URL in Play Console against the prepared files under `android/play-store/`.
 
-## Required immediately after the internal release is accepted
+## Required after Internal verification
 
-- Record the Google Play App Signing SHA-1 and SHA-256. These are different from
+- Keep the recorded Play App Signing identities, provider reconciliation, and
-  the upload-certificate fingerprints documented for the local artifact.
+  Play-delivered physical-device replay as the Internal-release baseline.
-- Add the Play App Signing fingerprints to the production Firebase Android app
+- Complete the remaining Play App content and listing declarations from the
-  and production App Links association, then recheck domain verification.
+  source-controlled material under `android/play-store/`.
-- Install the Play-delivered build from the internal-testing opt-in link and
+- Prepare the closed test with at least 12 continuously opted-in testers for at
-  repeat production-origin, sign-in, push-notification, foreground/background
+  least 14 days before requesting production access. Closed testing and a
-  location, stop-sharing, and App Link smoke tests.
+  Production rollout have not been started.
-- Only after the Play-delivered build passes, prepare the closed test with at
-  least 12 continuously opted-in testers for at least 14 days before requesting
-  production access.
 
 ## Scope protection
 

docs/google-play-release-candidate-2026-08-03.md

@@ -78,9 +78,14 @@ SHA-256 fingerprint.
 
 The verified personal developer account contains the Who Need Help application
 with Play application ID `4972430103169452589`. Play App Signing was accepted.
-The internal-testing draft contains the exact version-code `1` AAB identified
+Google Play accepted the exact version-code `1` AAB identified above as release
-above, but the release has not yet been saved/published to testers. A failed
+`0.1.0 internal verification`, and that release is active only on the Internal
-duplicate-upload row must not be confused with the accepted artifact.
+testing track. No Closed or Production rollout has been created or started.
+
+Every Play App Signing SHA-1 and SHA-256 identity displayed for the accepted
+artifact is retained in the ignored mode-`0600` provider inventory. Production
+Firebase, Google OAuth, and Android App Links were reconciled with those
+identities without removing the independent upload identity.
 
 The exact release label, localized notes, pre-publication checks, and
 post-publication sequence are frozen in
@@ -88,20 +93,21 @@ post-publication sequence are frozen in
 
 The remaining Console sequence is:
 
-1. Keep the accepted version-code `1` artifact and remove only the failed
+1. Keep the accepted version-code `1` Internal release unchanged while its
-   duplicate-upload row from the draft.
+   verified device evidence remains the release baseline.
-2. Save/publish the internal release and obtain every Play App Signing SHA-1
+2. Complete the prepared store listing and App content sections using
-   and SHA-256 shown under **Test and release → Setup → App signing**.
-3. Complete the prepared store listing and App content sections using
    `android/play-store/` and `android/store-assets/`, including the mandatory
    location foreground-service declaration and demonstration video described
    in `android/play-store/location-and-fgs-declaration.md`.
-4. Install the Play-delivered build from the internal-test opt-in link and
+3. Start a closed test with at least 12 continuously opted-in testers for at
-   repeat the production-origin, sign-in, notification, location, and App Link
-   smoke tests.
-5. Start a closed test with at least 12 continuously opted-in testers for at
    least 14 days before requesting production access.
 
+The Play-delivered Internal build has already passed physical-device checks for
+Google sign-in, verified App Links, production FCM, user-started foreground
+location sharing while minimized, the notification Stop action, offline
+recovery, and process recreation. Exact evidence and cleanup are recorded in
+`docs/verification.md`.
+
 Official references:
 
 - https://support.google.com/googleplay/android-developer/answer/9859152

docs/public-launch-checklist.md

@@ -13,13 +13,20 @@ Do not replace unknown values with estimates.
       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.
+- [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 at local revision `e779188` 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 exact systemd unit result and resource observation are
+recorded in `docs/verification.md`.
+
 ## 2. Verify production configuration without exposing secrets
 
 Run both checks against the single ignored production `.env`. The first reports

docs/verification.md

@@ -2208,6 +2208,7 @@ promoted.
   `{"status":"ready"}`; the WebSocket handshake returned HTTP 101. The
   association response named `org.whoneedhelp.mobile` and published four
   SHA-256 signing identities.
+
 - The compact application container remained healthy with zero restarts and no
   OOM kill. One point-in-time sample observed 189.3 MiB container memory, 25
   PIDs and 0.32% CPU. The host reported 1,224,523,776 bytes available memory
@@ -2238,3 +2239,30 @@ promoted.
   restored to that exact running image ID. Compose configuration then passed;
   edge, test application and test database start timestamps were unchanged,
   and both production and frozen-test readiness remained HTTP 200.
+
+# 2026-08-09 local aggregate-delivery monitoring quality run
+
+- Local revision `e779188` added privacy-bounded aggregate SMTP delivery
+  counters and an authenticated external Prometheus scrape. The exported email
+  counters are tagged only with the bounded result `ok` or `error`; recipient,
+  message, request, and account identifiers are not metric labels.
+- The external monitor keeps a per-node counter baseline and alerts only when
+  HTTP exceptions, bounded Oban queue failures, SMTP delivery errors, or SMTP
+  exceptions increase. The first observation and a counter reset establish a
+  new baseline instead of creating a false incident. A readiness or metrics
+  scrape failure changes monitor health and produces only transition alerts.
+- The Python monitor suite passed all seven parser/baseline/reset/transition
+  tests, the Phoenix metrics controller tests passed, and the full ExUnit run
+  passed 451 tests.
+- The isolated `scripts/quality.sh` systemd unit
+  `codex-heavy-wnh-quality-email-monitor-20260809-070511-2847948.service`
+  exited with result `success` and status `0` after 4 minutes 57 seconds. The
+  unit reported a 386 MiB memory peak. Every configured quality and security
+  gate passed, and the final Debian 13.6 runtime-image scan reported zero
+  detected vulnerabilities.
+- Run-scoped quality/security images were cleaned automatically. Two unrelated
+  old local test tags with no container references were removed by exact tag;
+  no container or volume was removed by that cleanup.
+- This is local verification only. The new aggregate delivery counters and
+  authenticated metrics scrape have not yet been deployed to production, and
+  the frozen hackathon test deployment and public Git remote were not changed.