Record pilot readiness verification

android/play-store/closed-test.md

@@ -9,7 +9,9 @@ before production access can be requested.
 1. Complete Play developer identity and contact verification.
 2. Create the Play app with package `org.whoneedhelp.mobile`.
 3. Enable Play App Signing.
-4. Add the Play App Signing SHA-256 fingerprint to production App Links and
+4. Record every signing-certificate fingerprint shown by Play, including all
+   identities shown for quantum-ready hybrid signing when present. Add every
+   applicable Play App Signing SHA-256 to production App Links and
    Google/Firebase configuration, then verify the production association files.
 5. Upload the source-bound production AAB.
 6. Complete the store listing, App content, privacy, Data Safety, content rating,

android/play-store/release-checklist.md

@@ -15,14 +15,17 @@
 - [x] Accept Play App Signing.
 - [x] Record the upload-certificate SHA-1 and SHA-256 with the source-bound
       candidate.
-- [ ] Record the distinct Play App Signing SHA-1 and SHA-256 after the first AAB
+- [ ] Record every Play App Signing SHA-1 and SHA-256 displayed by Play after
-      upload makes Play generate the app-signing key and before any tester
+      the first AAB upload makes Play generate its signing identities and
-      rollout.
+      before any tester rollout. Do not assume that a new app has only one
-- [ ] Add the Play App Signing SHA-256 to production Google/Firebase Android
+      Play certificate: current Play quantum-ready hybrid signing can expose
-      configuration.
+      multiple classical/post-quantum identities for different Android
+      generations.
+- [ ] Add every applicable Play App Signing SHA-256 to production
+      Google/Firebase Android configuration.
 - [ ] Publish and verify
       `https://whoneedhelp.com/.well-known/assetlinks.json` for the Play
-      certificate.
+      certificate identities used to sign delivered APKs.
 
 ## Build
 
@@ -45,7 +48,8 @@
       warnings. The validator did not print secret values and did not modify
       production.
 - [ ] Pass the stricter `--require-release` gate. Its only remaining blocking
-      item on 2026-08-08 is the not-yet-generated Play App Signing SHA-256;
+      item on 2026-08-08 is the not-yet-generated set of Play App Signing
+      SHA-256 fingerprints;
       every other capability reported `READY`.
 
 ## Store presence

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

@@ -26,10 +26,13 @@ fingerprint after the build.
 - SHA-1:
   `8C:84:D5:CA:2F:B7:EA:2B:7E:08:2D:D1:CD:E8:AC:60:56:AA:1B:3C`
 
-This upload certificate is not the Google Play App Signing certificate. After
+This upload certificate is not a Google Play App Signing certificate. After
-the first upload, record the Play-generated certificate separately and add its
+the first upload, record every Play-generated signing certificate separately
-fingerprints to production Google/Firebase configuration and the production
+and add every applicable fingerprint to production Google/Firebase
-App Links association.
+configuration and the production App Links association. Current Play signing
+can expose multiple identities for quantum-ready hybrid signing, so the live
+Console is authoritative; do not assume that there will be only one Play
+SHA-256 fingerprint.
 
 ## Validation evidence
 
@@ -83,8 +86,8 @@ The remaining Console sequence is:
 
 1. Keep the accepted version-code `1` artifact and remove only the failed
    duplicate-upload row from the draft.
-2. Save/publish the internal release and obtain the Play App Signing SHA-1 and
+2. Save/publish the internal release and obtain every Play App Signing SHA-1
-   SHA-256 from **Test and release → Setup → App signing**.
+   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

docs/verification.md

@@ -1,6 +1,6 @@
 # Who Need Help — implementation verification
 
-Observed through 2026-08-03 in the local workspace. This report separates observed
+Observed through 2026-08-08 in the local workspace. This report separates observed
 results from product limits and unknown production properties.
 
 ## Public/mobile and Android candidate check on 2026-08-03
@@ -28,7 +28,7 @@ results from product limits and unknown production properties.
 
 This verifies the sideloaded candidate and its visible launch state. It does
 not replace a Play-delivered internal-track test or prove FCM and verified App
-Links under the Play App Signing certificate.
+Links under every Play App Signing certificate used for delivery.
 
 ## Production browser E2E on 2026-08-03
 
@@ -1991,9 +1991,9 @@ complete.
   `org.whoneedhelp.mobile.development` and its signed certificate, and the
   verified implicit same-origin App Link rendered in the API 37 smoke. Before
   a Play release, publish the already accepted source-bound AAB from the
-  internal-testing draft, record the Play App Signing certificate fingerprint
+  internal-testing draft, record every Play App Signing certificate fingerprint
   alongside the existing upload fingerprint, repeat domain verification with
-  that Play certificate, and complete store policy/release work. The Play
+  the complete Play certificate set, and complete store policy/release work. The Play
   application and internal draft exist, but a Play-delivered build has not yet
   been tested.
 - The independent encrypted off-site backup, isolated restore, daily timer, and
@@ -2053,3 +2053,54 @@ migration-policy drills. The transient Compose project, database volume and
 audit images were removed by the run's cleanup trap. This verifies the local
 candidate only; production browser E2E must be repeated after that candidate is
 promoted.
+
+# 2026-08-08 pilot-readiness verification
+
+- The isolated `play-readiness-20260808` quality/security run passed all 449
+  ExUnit tests and every configured compiler, formatting, xref, Credo,
+  Sobelow, Dialyzer, dependency, container, Compose, Helm, migration,
+  rollback, observability, and image-security gate. The retained audit is
+  `output/regression/play-readiness-20260808/`; the log SHA-256 is
+  `1889d89c731909dc49fd3f466213611da36cf13074aa1f838e0f7798b0ee0d9b`.
+  Its run-scoped containers, images, volumes, and systemd unit were absent or
+  inactive after cleanup.
+- The full production browser replay at production revision
+  `0ad9a5430e1a2e23ab976999faf1280bf53bcdc1` passed both the two-person help
+  flow and the activity approval/privacy/reporting flow. Readiness was healthy
+  before and after the run, and exact fixture cleanup restored every measured
+  product-table count to its pre-run value. Evidence is retained at
+  `output/production-full-e2e/production-e2e-20260808-0ad9a54/`.
+- A later live read-only sample observed the compact production application at
+  182 MiB resident container memory, 4.35% CPU, 25 PIDs, zero restarts, and no
+  OOM kill, with readiness still healthy. The 4-GiB host reported 1.3 GiB
+  available memory and 101 GiB free disk space. PostgreSQL reported a
+  21,452,479-byte production database and five database connections (one
+  active and four idle) during the query. These are point-in-time measurements,
+  not capacity limits. Two Bandit read-timeout log lines were observed without
+  a crash marker or readiness failure; their remote-client cause was not
+  established from the available log context.
+- The daily encrypted off-site backup timer was active and enabled. Its latest
+  completed run backed up production PostgreSQL 18.4 to the separately hosted
+  Restic repository and passed an isolated restore drill. Evidence is retained
+  at `output/production-operations/20260807T210010Z-1503616`. The independent
+  external monitor was active on its minute schedule and most recently
+  recorded HTTP 200 with the expected readiness payload. These checks prove
+  mechanics and current execution, not operator key custody, retention, RPO,
+  RTO, or database-availability policy.
+- The current source-bound Play candidate still passes store-asset validation,
+  the Android location/foreground-service policy contract, and source
+  fingerprint verification. Its AAB SHA-256 remains
+  `03d39a9a08e9ca7569caccf1c7bd75e9349f7655935e7bbf23d1998cd37b3837`.
+- The connected physical device reports installed package
+  `org.whoneedhelp.mobile` version `0.1.0`, signed by the recorded upload
+  certificate, with `whoneedhelp.com` in Android's verified domain state. Its
+  installer is absent, so this is explicitly a sideloaded-build observation
+  and not Play-delivered evidence.
+- The already-authenticated Chrome dev-port instance exposed two Play Console
+  pages, including the Who Need Help internal-release preparation page.
+  Playwright connected to its DevTools WebSocket but could not import the 94
+  live Chrome targets before the CLI's 300-second timeout. Therefore the live
+  draft contents were not re-asserted on this date. No Play Console field was
+  changed and no release was saved, submitted, or published. The Play App
+  Signing certificate set and Play-delivered device flow remain unverified
+  gates.