From 897a94381500badc8427fe9d427e857dcda7487f Mon Sep 17 00:00:00 2001 From: SimpleTest Date: Sat, 8 Aug 2026 16:50:47 +0300 Subject: [PATCH] Record pilot readiness verification --- android/play-store/closed-test.md | 4 +- android/play-store/release-checklist.md | 18 +++--- ...oogle-play-release-candidate-2026-08-03.md | 15 +++-- docs/verification.md | 59 +++++++++++++++++-- 4 files changed, 78 insertions(+), 18 deletions(-) diff --git a/android/play-store/closed-test.md b/android/play-store/closed-test.md index 050e9b8..9ec3ccc 100644 --- a/android/play-store/closed-test.md +++ b/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, diff --git a/android/play-store/release-checklist.md b/android/play-store/release-checklist.md index 8d412ac..15d8d6d 100644 --- a/android/play-store/release-checklist.md +++ b/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 - upload makes Play generate the app-signing key and before any tester - rollout. -- [ ] Add the Play App Signing SHA-256 to production Google/Firebase Android - configuration. +- [ ] Record every Play App Signing SHA-1 and SHA-256 displayed by Play after + the first AAB upload makes Play generate its signing identities and + before any tester rollout. Do not assume that a new app has only one + Play certificate: current Play quantum-ready hybrid signing can expose + 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 diff --git a/docs/google-play-release-candidate-2026-08-03.md b/docs/google-play-release-candidate-2026-08-03.md index 9108096..020611c 100644 --- a/docs/google-play-release-candidate-2026-08-03.md +++ b/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 -the first upload, record the Play-generated certificate separately and add its -fingerprints to production Google/Firebase configuration and the production -App Links association. +This upload certificate is not a Google Play App Signing certificate. After +the first upload, record every Play-generated signing certificate separately +and add every applicable fingerprint to production Google/Firebase +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 - SHA-256 from **Test and release → Setup → App signing**. +2. Save/publish the internal release and obtain every Play App Signing SHA-1 + 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 diff --git a/docs/verification.md b/docs/verification.md index 08a78ed..9cbe169 100644 --- a/docs/verification.md +++ b/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.