Record current production readiness evidence
This commit is contained in:
parent
89ac07ec20
commit
b7a18b0649
|
|
@ -1,8 +1,46 @@
|
||||||
# Who Need Help — implementation verification
|
# Who Need Help — implementation verification
|
||||||
|
|
||||||
Observed through 2026-08-26 in the local workspace. This report separates observed
|
Observed through 2026-08-28 in the local workspace. This report separates observed
|
||||||
results from product limits and unknown production properties.
|
results from product limits and unknown production properties.
|
||||||
|
|
||||||
|
## Production operations, browser E2E, and Play recheck on 2026-08-28
|
||||||
|
|
||||||
|
- The production backup timer was loaded, enabled, and waiting for its next
|
||||||
|
daily invocation. Its 2026-08-28 run exited successfully after 6 minutes 59.679
|
||||||
|
seconds with a 90.5 MiB systemd-unit memory peak. The run verified the external
|
||||||
|
PostgreSQL custom-format archive and checksum, published encrypted Restic
|
||||||
|
snapshot `800d5efbf902175a622d4b4eebd0432e81dbd39a25aa76b5fb3c33e6673950c2`,
|
||||||
|
and passed the isolated restore drill.
|
||||||
|
- A read-only check from the independent BuyVM monitor host reported application
|
||||||
|
readiness, protected aggregate metrics, and restore-verified backup freshness
|
||||||
|
`up`. The observed backup age was 8,722 seconds against the configured
|
||||||
|
129,600-second threshold. Both the external monitor timer and the application
|
||||||
|
backup timer remained enabled and active.
|
||||||
|
- The run-scoped production browser workflow completed three Chromium scenarios:
|
||||||
|
mutual aid with real-time chat, consent-based tracking, handover and blind
|
||||||
|
reviews; activity approval, privacy, reporting and moderation; and staff
|
||||||
|
support/legal access. The structured Playwright result reported three expected
|
||||||
|
passes, zero skips, zero unexpected results, and zero flaky results in 67.061
|
||||||
|
seconds. Production readiness returned the exact `ready` payload before and
|
||||||
|
after the browser run.
|
||||||
|
- The browser fixture cleanup removed the six exact synthetic users and their
|
||||||
|
manifest-owned request, activity, notification, support, legal, audit and job
|
||||||
|
records. A second read-only plan for the same run ID observed zero matching
|
||||||
|
users, and the temporary remote tools image was absent. Evidence is retained
|
||||||
|
under ignored
|
||||||
|
`output/production-full-e2e/production-e2e-20260828-audit/`.
|
||||||
|
- Physical device `72551e60` passed the strict Play-delivery verifier again for
|
||||||
|
`org.whoneedhelp.mobile` version `0.1.3 (4)`: installer Google Play, signing
|
||||||
|
identity from the protected Play App Signing set, verified production App Link
|
||||||
|
resolving to `MainActivity`, and no browser OAuth callback claimed by the app.
|
||||||
|
- A read-only Firebase asset inventory for Google Cloud project
|
||||||
|
`who-need-help-staging` showed only the base service-usage, logging, billing and
|
||||||
|
project resources; no staging Firebase Android application or FCM service
|
||||||
|
account was present. The Firebase console stated that adding Firebase to this
|
||||||
|
billing-enabled project would use the pay-as-you-go Blaze plan. That
|
||||||
|
confirmation was not accepted and no Firebase resource or billing setting was
|
||||||
|
changed.
|
||||||
|
|
||||||
## Protected support and content-removal email confirmation on 2026-08-26
|
## Protected support and content-removal email confirmation on 2026-08-26
|
||||||
|
|
||||||
- Browser inspection found that the shared fragment bootstrap accepted only raw
|
- Browser inspection found that the shared fragment bootstrap accepted only raw
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue
Block a user