diff --git a/docs/google-play-release-candidate-2026-08-09-v3.md b/docs/google-play-release-candidate-2026-08-09-v3.md index e93dfc0..7a5af0e 100644 --- a/docs/google-play-release-candidate-2026-08-09-v3.md +++ b/docs/google-play-release-candidate-2026-08-09-v3.md @@ -92,13 +92,14 @@ authenticated Play Console foreground-service form was saved with **User-initiated location sharing** and this URL. This does not claim Google approval. -The remaining gates, rechecked read-only on 2026-08-14, are: +The remaining gates, rechecked read-only through 2026-08-26, are: 1. recheck the saved foreground-service declaration before submitting a new bundle or release and respond to any Play policy feedback; -2. complete the Play Console public contact task; the Store listing is now - marked complete, the Dashboard reports 10 of 11 tasks complete, and Closed - testing remains locked; +2. keep the public contact route monitored: Store settings contain + `contact@whoneedhelp.com`, and a controlled inbound test observed the exact + alias forwarding successfully to Gmail through ImprovMX. This verifies + receipt and forwarding, not a standalone mailbox or reply-from identity; 3. recruit the required tester cohort only after Closed testing is unlocked; the Dashboard currently reports `0 testers currently opted-in`; 4. keep Closed and Production tracks untouched until their separate gates are diff --git a/docs/public-launch-checklist.md b/docs/public-launch-checklist.md index 4c64975..a62d413 100644 --- a/docs/public-launch-checklist.md +++ b/docs/public-launch-checklist.md @@ -80,6 +80,15 @@ In particular, a configured `SUPPORT_INBOX_ADDRESS` is not evidence of inbound mail delivery: verify its MX routing and complete a real receive-and-reply test before using it in Google Play or public support pages. +The production public contact passed a controlled inbound-routing check on +2026-08-26. Public MX resolved to ImprovMX, the exact +`contact@whoneedhelp.com` alias forwarded a uniquely addressed message to the +operator mailbox, the forwarding log recorded Gmail's successful SMTP receipt, +and Gmail found the exact message. Random unconfigured local parts were +rejected rather than forwarded through a catch-all. This proves the currently +configured receive-and-forward path; it does not provide a standalone mailbox +or prove reply-from identity. + If the optional Brevo inbound path is selected, also verify the dedicated receiving subdomain, exact `SUPPORT_INBOUND_RECIPIENT`, authenticated webhook, provider `MessageId` deduplication, confirmation-gated staff visibility, and a diff --git a/docs/verification.md b/docs/verification.md index e1420ad..995e98a 100644 --- a/docs/verification.md +++ b/docs/verification.md @@ -3828,3 +3828,50 @@ promoted. - The frozen hackathon test deployment, shared Caddy, public Git remote, real users, and unrelated production support records were not changed by this controlled verification. + +# 2026-08-26 inbound contact and production operations recheck + +- A controlled inbound-routing check used one uniquely titled technical + message addressed to `contact@whoneedhelp.com`. The existing ImprovMX + configuration showed the domain active, the exact contact alias forwarding + to the operator Gmail mailbox, MX priorities 10 and 20 for + `mx1.improvmx.com.` and `mx2.improvmx.com.`, and the configured ImprovMX SPF + include. No forwarding or DNS setting was changed. +- The provider log recorded that exact message entering its queue at + 2026-08-26 00:36:32 EEST and being forwarded to Gmail, whose destination + server returned SMTP `2.0.0 OK`. Gmail exact-subject search found the same + message with the project label. It was not present in Inbox. Provider logs + also showed unrelated random local parts rejected with `5.1.1`, rather than + forwarded through a catch-all. This proves the observed inbound forwarding + route; it does not establish a standalone mailbox or reply-from identity. +- Public read-only probes returned HTTP 200 with the expected live and ready + payloads. The unauthenticated metrics endpoint returned the expected HTTP + 401. Production application and edge containers were healthy with zero + observed restarts. +- The external monitor's last DOWN transition covered two checks at 21:31 and + 21:32 UTC on 2026-08-25: both its readiness and authenticated metrics + requests timed out, while backup freshness remained up. It recovered at + 21:33 UTC. Production application logs independently showed successful + readiness traffic reaching the application throughout the same interval, + and the monitor's timed-out requests were absent from those logs. Together + these observations support a transient path failure between the external + monitor and production; they do not establish a production application + outage. +- The workstation backup timer was loaded, enabled, active, and waiting. Its + scheduled 2026-08-26 00:00 EEST execution completed successfully after + catalog and checksum validation, encrypted off-server transfer, and the + isolated restore drill. The independent heartbeat had mode `0600`, reported + `restore_verified: true`, and the external monitor reported readiness, + metrics, and backup freshness all up against the operator-selected 36-hour + threshold. +- An earlier stale-backup transition at 10:43 UTC on 2026-08-25 measured the + restore-verified heartbeat older than the configured 129,600-second limit. + The preceding scheduled archive and checksum had succeeded, but its isolated + restore database was still starting when the readiness check ran. The later + committed readiness helper waits for PostgreSQL initialisation and a direct + SQL probe against the final postmaster; its regression test exists in + `test/scripts/production_offsite_backup_readiness_test.sh`. A controlled + rerun recovered the monitor at 10:52 UTC, and the following scheduled run + passed as recorded above. +- These checks did not change the frozen hackathon test deployment, shared + Caddy, production application, Play Console, or public Git remote.