Record pilot readiness verification
This commit is contained in:
parent
67990ee47f
commit
897a943815
|
|
@ -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,
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user