simpletest/who_need_help
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
7094f21394
who_need_help/docs/verification.md

3463 lines
227 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Who Need Help — implementation verification
Observed through 2026-08-14 in the local workspace. This report separates observed
results from product limits and unknown production properties.
## Current local candidate and production operations recheck on 2026-08-14
- The later production-E2E harness candidate `23776e2` passed the complete
isolated `scripts/quality.sh` pipeline in user-systemd unit
`codex-heavy-wnh-quality-23776e2-20260814-042628-2092739.service`. ExUnit
reported 480 passing tests; every configured quality and security gate
passed; and the final runtime-image scan reported zero detected
vulnerabilities. The run completed successfully after 4 minutes 44.774
seconds with a measured 313.6 MiB systemd-unit memory peak and no swap.
- Production remains on independent clean application revision
`f1947f2264a6a51da4eb8a6a11ff83b8161f1f64`. The local commits after that
revision change only the throwaway production-E2E verifier and its evidence;
they do not change the deployed application runtime. The public readiness
endpoint returned the expected `ready` payload and the application container
was healthy at the 2026-08-14 recheck. No application release, frozen-test
change, or Caddy change was performed by this recheck.
- Protected production metrics reported an idle BEAM scheduler run queue of
zero and 134,722,016 bytes of BEAM VM memory. Since the current production
process started, the fixed-purpose email counter recorded eight successful
`support_confirmation` deliveries and no failed or exceptional email series.
These process-local counters establish the purpose and adapter outcome of
those attempts; they do not prove inbox placement or receipt by a person.
- The scheduled encrypted off-server backup that began on 2026-08-14 at 00:00
EEST completed successfully after 5 minutes 13.266 seconds. It verified the
PostgreSQL custom-format catalog and checksum, created Restic snapshot
`563eb486ee2002fb0bc85b12afe5bd7ef8ada02ac3566c343ac6f83f51e73a1c`,
and passed the isolated restore drill. The independent BuyVM host held the
matching mode-`0600` restore-verified heartbeat and continued to report
readiness and aggregate metrics `up` on its minute schedule.
- Backup-freshness alerting remains deliberately disabled because no operator
maximum acceptable backup age has been selected. The successful daily
execution is therefore evidence of the mechanism, not an approved RPO or
alert threshold.
- The Google Play foreground-service declaration remains saved with the
user-initiated location-sharing task and the retained unlisted demonstration
video. The operator reviewed the video on 2026-08-14 and confirmed that it
visibly covers starting location sharing, the system permission, the active
foreground-sharing state, and stopping sharing. This is submission material,
not evidence of Google approval.
- No remote repository, production release, Play listing contact, shared Caddy
configuration, or frozen-test state changed during this recheck.
## Current local candidate and operations recheck on 2026-08-13
- Application source candidate `02ccebb5b9b0720bf7c40b5be736d4c1a1e9e656` passed the
complete isolated `scripts/quality.sh` pipeline in user-systemd unit
`codex-heavy-wnh-final-quality-02ccebb-20260813-132155-4023930.service`.
ExUnit reported 470 passing tests; the fourteen browser map tests passed;
every configured quality and security gate passed; and the
final Debian 13.6 runtime-image scan reported zero detected
vulnerabilities. The unit exited successfully after 3 minutes 8.923
seconds with a measured 327.5 MiB systemd-unit memory peak. Exact-name
inspection after the run found no remaining run-scoped container, network,
volume, or temporary quality/security image.
- The same candidate passed the complete isolated browser E2E suite in
Chromium, Firefox, and WebKit: 63 expected tests passed, with zero
unexpected or flaky results, in 324.826 seconds. Three production-only staff
queue checks were intentionally skipped because their run-scoped production
fixtures do not exist in the local E2E environment. The run covered desktop
and phone accessibility, registration and account settings, request and
activity workflows, private chat, consent-based tracking, handover and blind
reviews, notifications, viewport discovery and clustering, staff queues,
localization, and active-node failure recovery. The structured result is retained at
`output/e2e/20260813041912-1796685/results.json`; exact-name inspection found
no remaining run-scoped container, network, volume, or temporary image. A
focused local replay of the three personal-data support workflows passed in
27.323 seconds with no skips, unexpected results, or flakes; its structured
result is retained at
`output/e2e/20260813033312-437829/results.json`.
- A fresh read-only production release plan compared this candidate with
production revision `dafcdb36cbe221af0c880fd05da3321e181ddd2c`. It observed
thirty-four pending
commits, one reviewed `application_safe` migration
(`20260812120611_allow_inbox_only_nearby_subscriptions.exs`), external
PostgreSQL 18.4, unchanged shared-edge routing, and all twelve environment
capability groups `READY`. The plan completed without changing production.
- The clean release-artifact workflow prepared a complete-history Git bundle
and a compressed `linux/amd64` application-image archive under
`output/releases/02ccebb5b9b0720bf7c40b5be736d4c1a1e9e656/`. The retained
artifact set occupies 65 MiB; its manifests and adjacent SHA-256 files
validated successfully. Preparing and validating these local files did
not upload or apply them.
- Production's configured rate-limit map contains all twelve required
authentication and anonymous-intake policies with positive limits and
windows. The implementation has a retained local one-CPU benchmark, but the
selected product thresholds have not yet been validated against real-user
behaviour or an approved abuse policy; they are not presented as measured
capacity limits.
- The scheduled off-site backup that began on 2026-08-13 at 00:00 EEST
completed successfully after 4 minutes 31.812 seconds. It created Restic
snapshot
`112640d797b843c6388a5d68a5348294483a7b8dc1f46951695cc0feeb152abd`,
verified the custom-format PostgreSQL backup and checksum, and passed the
isolated restore drill. The restore-verified heartbeat was written with mode
`0600` on the independent BuyVM monitor host at
`/home/simple/.local/state/who-need-help/production-backup.json`.
- The independent BuyVM monitor remained enabled and active on its minute
schedule. Its fresh check at `2026-08-13T03:09:02Z` reported production
readiness and the authenticated aggregate metrics scrape `up`. Its installed
configuration still has no backup-freshness section because no operator
maximum acceptable backup age has been selected. The heartbeat therefore
proves current backup/restore execution but does not yet produce a stale-
backup alert or establish an RPO.
- The connected physical phone again passed
`scripts/verify-play-installed-android.sh`: package
`org.whoneedhelp.mobile`, version `0.1.2 (3)`, installer Google Play, a
signing identity from the protected Play App Signing set, verified
`whoneedhelp.com` App Link resolving to `MainActivity`, and no Android claim
on the browser-only OAuth callback.
- The local candidate is deployed only to the development environment. This
recheck did not apply the production release, modify the frozen hackathon
test deployment or shared Caddy, save Google Play Console fields, or push the
public Git remote.
### Google Play Console and store-presence observation on 2026-08-13
- A read-only inspection of the authenticated Play Console initially observed
app setup at 9 of 11 tasks. The category was subsequently saved as `Social`;
tags remain empty. A monitored public contact address and the Store listing
still require separate verification before they can be treated as complete.
The initial observation had empty public email, phone, website, listing text,
icon, feature graphic, and screenshots; recheck the Console before applying
the prepared assets because those external fields can change independently.
- The foreground-service form was subsequently saved with
**User-initiated location sharing** and the unlisted demonstration URL
`https://youtube.com/shorts/UZh_QBdlbBc`. The retained operator copy is
`/home/simple/Downloads/Who-Need-Help-Google-Play-FGS-location-review.mp4`,
SHA-256
`3c5f52019bf8a42ff42e1d9232afc126b62627390d74eed75084d82ecb33ac56`.
The saved form is submission evidence, not evidence of Google approval.
- Closed testing remains locked until app setup is complete. The Console
reported zero opted-in closed testers. Current Google Play documentation for
a new personal developer account requires at least 12 opted-in testers for
14 continuous days before production access can be requested; Internal
testing does not satisfy that gate.
- Public DNS returned no MX record for `whoneedhelp.com` or
`email.whoneedhelp.com`. Production uses `contact@whoneedhelp.com` as a
Brevo outbound sender and routes internal support alerts to the monitored
operator mailbox, but neither fact establishes inbound delivery to
`contact@whoneedhelp.com`. The address must not be saved as the public Play
support contact until an inbound route is configured and tested, or the
operator deliberately selects another monitored public address.
- Read-only account inspection did not establish an existing netcup mail
product: the authenticated customer-control-panel login stopped at the
account's required TAN challenge. The ImprovMX page was still an unauthenticated
login page. No account, alias, MX record, forwarding destination, or DNS
setting was created or changed during these checks.
- The connected physical phone again passed the strict Play-delivered build
check for `org.whoneedhelp.mobile` version `0.1.2 (3)`: installer Google
Play, signing identity from the protected Play App Signing set, verified
`whoneedhelp.com` App Link resolving to `MainActivity`, and no Android claim
on the browser-only OAuth callback.
### Frozen-test memory observation on 2026-08-13
- A read-only server inspection found production healthy at about 197 MiB of
container memory, while the frozen `test.whoneedhelp.com` application used
about 2.47 GiB. BEAM attributed about 2.45 GiB of the frozen-test VM to ETS;
table `prometheus_metrics_dist` contained 10,748,076 pending raw histogram
samples and occupied 290,222,909 machine words at the first sample.
- The frozen test runs commit
`cf7bacdf61ffb171ebac85e32dfcf12bc6972d59`, which predates the supervised
ten-second Prometheus distribution drain added in commit `882df25`. A second
read-only sample 13.071 seconds later contained 144 more rows. This directly
establishes an unbounded-in-that-revision telemetry buffer as the dominant
memory consumer; it does not establish an application-data leak.
- The test remained externally ready and its container had not been OOM-killed.
No restart, table mutation, image replacement, Caddy change, or frozen-test
checkout change was made. The corrective telemetry code exists in the local
candidate and current production ancestry, but applying it to the frozen
hackathon deployment would change submitted project material and therefore
requires a separate decision after judging.
## Current launch-boundary and transactional-email proof on 2026-08-12
- A follow-up SMTP-envelope regression run completed successfully in isolated
user-systemd unit
`codex-heavy-wnh-email-full-final-20260812-213848-711438.service`.
ExUnit reported 468 passing tests with seed `954756`. The shared mailbox
validator now covers model input, production/test environment preflight, and
every outbound envelope; malformed historical recipients cancel their exact
Oban mail job instead of reaching the SMTP adapter or retrying indefinitely.
A separately built production image loaded the same runtime validation
successfully in unit
`codex-heavy-wnh-release-runtime-email-20260812-213723-667643.service`.
- The final email-boundary quality rerun completed successfully in isolated
user-systemd unit
`codex-heavy-wnh-email-quality-final-20260812-184719-3589051.service`.
ExUnit reported 465 passing tests, the full configured quality/security
pipeline passed, dependency audits reported zero vulnerabilities, and the
run completed in 4 minutes 49.760 seconds with a measured 213.5 MiB memory
peak.
- A subsequent isolated support/legal browser replay passed the authenticated
queue workflow in Chromium, Firefox, and WebKit. Unit
`codex-heavy-wnh-email-support-e2e-final-20260812-190554-5940.service`
completed successfully; exact-name inspection found no remaining container,
network, or temporary image for Compose scope
`who_need_help_e2e_20260812160554-6599`.
- The complete isolated `scripts/quality.sh` pipeline passed in user-systemd
unit
`codex-heavy-wnh-quality-launch-boundary-20260812-163255-3402967.service`.
It completed successfully in 4 minutes 47.572 seconds with a measured
222.3 MiB memory peak. ExUnit reported 462 passing tests with seed `616444`,
and the browser map-asset suite reported fourteen passes.
- The run passed the repository policy, ShellCheck, Hadolint at the configured
threshold, actionlint, Compose, Helm, observability, format, compiler, xref,
Credo, Sobelow, Dialyzer, dependency audits, migration and rollback drills,
and the production-release orchestration drills. The final Debian 13.6
application image and all pinned infrastructure images reported zero detected
vulnerabilities.
- The migration compatibility registry is now checked against every migration
at or after the first reviewed version. The pending
`20260812120611_allow_inbox_only_nearby_subscriptions.exs` migration is
explicitly classified `application_safe`; the isolated policy drill proved
that missing registry entries are rejected while reviewed safe and
forward-only entries are accepted by their respective release paths.
- Immediate per-request nearby email is retired. Nearby matches use the private
in-app inbox and optional push; the settings UI states that an email digest is
not enabled. Support contact verification enqueues one operator alert only
after the address is verified. Requester email is limited to the first staff
response or a later public-status change, while authenticated requesters also
receive an in-app support update. Ordinary requester and staff conversation
messages do not each generate email.
- Support-contact verification, optional support updates, content-removal
confirmation/receipt/decision messages, and optional operator alerts run
through the dedicated Oban `mail` queue, whose default concurrency is one per
worker. Internal legal assignment-only changes do not email the submitter.
Fixed-purpose delivery telemetry records only the allow-listed purpose and
outcome, without email addresses or message content. Authentication links
remain synchronous by design because their database token is committed only
when delivery succeeds.
- Exact-name inspection after completion found no container or temporary image
belonging to quality scope `20260812133255-3403320` /
`wnh_quality_202608121332553403320`.
- This was local verification only. It did not deploy production, modify the
frozen hackathon-test checkout, change shared Caddy, save Google Play Console
fields, or push the public Git remote.
### Read-only production attribution and operations observations
- The production application was still running revision `dafcdb3` when checked
on 2026-08-12; the email-boundary commits above were therefore not active
there. Its Oban table had no pending email/support worker backlog. The only
observed worker group was 1,440 completed request-expiry jobs.
- Since the current production container started, the database contained 44
public support submissions: 32 were still pending contact verification and
12 had verified contact addresses. There were no content-removal notices in
the same interval and none of those support requests had a recorded staff
response email. The deployed code attempted one confirmation for each public
submission and one receipt after each successful contact verification, so
these rows can account for up to 56 support-email attempts. The process-level
legacy metric reported 60 successful SMTP deliveries and two exceptions, but
it did not carry a purpose label. The exact purpose of each legacy delivery
is therefore unknown and must not be inferred from those aggregates.
- `SUPPORT_OPERATOR_EMAIL_MODE` was absent in the production environment and
the deployed default was `disabled`; verified support requests therefore did
not generate an operator-inbox alert in that observed configuration.
- Four legacy SMTP exceptions were reproduced from stored recipients whose
local part began or ended with a dot or contained consecutive dots. The
deployed revision accepted those forms before the SMTP adapter rejected
them. This establishes the failure class, but the legacy aggregate lacks
recipient and purpose labels, so it does not prove which historical rows
produced each of the four process-level exceptions.
- The workstation-scheduled encrypted off-site backup completed successfully
at 2026-08-12 00:04:48 EEST, including its isolated restore drill. The new
restore-verified heartbeat implementation was committed later that day, so
the external monitor did not yet have a backup section or heartbeat to
evaluate. Enabling freshness alerts still requires an operator-selected
maximum acceptable age; the repository does not invent an RPO.
## Current local quality and dependency-security proof on 2026-08-10
- The complete isolated `scripts/quality.sh` pipeline passed in user-systemd
unit
`codex-heavy-wnh-quality-final-20260810-20260810-163515-639199.service`.
It completed successfully in 6 minutes 46.460 seconds with a measured
230.7 MiB memory peak. ExUnit reported 459 passing tests with seed `280346`,
and the browser asset suite reported fourteen passes.
- The run passed the configured repository policy, ShellCheck, Hadolint,
actionlint, Compose, Helm, migration/rollback, observability, formatting,
compiler, xref, Credo, Sobelow, Dialyzer, Hex audit, npm audit, and container
image gates. The final Debian 13.6 application image and the pinned
infrastructure images reported zero detected vulnerabilities.
- The initially locked Phoenix LiveView `1.2.8` was affected by
`GHSA-36m4-rm57-3prf` / `CVE-2026-64941`. The lock now selects the patched
`1.2.9` release; the subsequent Hex audit reported no retired or advisory
packages.
- The generated Gettext template was refreshed with the repository's official
extractor. Its changes are source-line references only; no message identifiers
were added or removed.
- Exact-name inspection after completion found no image, container, network,
or volume belonging to scope `20260810133515-639775` /
`wnh_quality_20260810133515639775`.
- This was local verification only. It did not deploy production, modify the
frozen hackathon-test checkout, change shared Caddy, save Google Play Console
fields, install an Android package, or push the public Git remote.
- After the physical phone was reconnected, the strict installed-build verifier
again observed `org.whoneedhelp.mobile` version `0.1.2 (3)`, installer
`com.android.vending`, a supplied Play App Signing identity, a verified
`whoneedhelp.com` App Link resolving to `MainActivity`, and no Android claim
on the browser-only Google OAuth callback. The verifier did not reinstall the
package, clear its data, or change device permissions.
## External-monitor SMTP isolation proof on 2026-08-09
- The local change set based on revision `360c7a5` adds an optional,
independently revocable SMTP credential set for the off-host production
monitor. In override mode the installer reads only `METRICS_TOKEN` from the
production environment; application SMTP values are neither requested nor
copied into the local staging configuration. The existing application-SMTP
mode remains available for a controlled transition.
- Six focused tests passed in isolated user-systemd scope
`codex-heavy-wnh-monitor-smtp-focused-20260809-224809-2206905.service`.
They covered independent and legacy installer modes, exact-key parsing,
restrictive source-file modes, transport validation, atomic replacement,
preservation of non-SMTP monitor settings, and absence of both application
and monitor passwords from command output. The modified installer also
passed ShellCheck 0.11.0 in isolated scope
`codex-heavy-wnh-monitor-smtp-shellcheck-20260809-224809-2206903.service`.
- The complete isolated `scripts/quality.sh` pipeline passed in
`codex-heavy-wnh-quality-monitor-smtp-final-20260809-224827-2217374.service`.
It completed successfully in 2 minutes 21.914 seconds with a measured
218.3 MiB memory peak, passed all configured quality and security gates,
458 ExUnit tests, fourteen browser-asset tests, the monitor suites, and the
final Debian 13.6 image scan with zero detected vulnerabilities.
- These checks were local. They did not install or reconfigure the external
monitor, rotate a provider credential, deploy production, change the frozen
hackathon-test environment, or push the public Git remote. Provider-side key
creation and the monitored mailbox receipt check remain explicit external
operations.
## Current pilot release-boundary audit on 2026-08-09
- The read-only production release plan compared local candidate `f672e9c`
with production revision `f0cb936854343be12ce58284d872c68c701ad7f3` and
observed eleven pending commits. Shared edge routing is unchanged, the
migration policy is `application_safe` with zero migrations, external
PostgreSQL reported version 18.4, and all twelve environment-readiness
capability groups reported `READY` with zero local-only warnings.
- The same plan stopped before any mutation because the production checkout is
not clean. Its exact differences are a tracked modification to
`scripts/production-play-physical-fixture.exs` and the untracked companion
`scripts/production-play-physical-fixture.sh`. Both remote SHA-256 values
match the current local files exactly. The running production application
remains healthy with zero restarts on immutable image
`who-need-help:production-f0cb93685434`.
- Read-only isolation inspection observed the frozen hackathon-test checkout
clean at `cf7bacdf61ffb171ebac85e32dfcf12bc6972d59`. Its application,
PostGIS, and Mailpit containers remain healthy, and its public readiness
endpoint returned the exact ready payload. No test file, container, database,
Git reference, or public remote was changed.
- The connected physical device is authorised over USB and still has Google
Play-delivered `org.whoneedhelp.mobile` version `0.1.1 (2)`, installed by
`com.android.vending`. Candidate `0.1.2 (3)` remains local-only; its AAB
SHA-256 is
`5f1b63d02467ce63af795d16459a75693e415426478e0788b83f0f6d35dff922`,
and a fresh Android source fingerprint still matches the recorded candidate
fingerprint.
- The daily encrypted backup timer is loaded, enabled, and active; its latest
completed service exited successfully. The independent off-host monitor
timer is likewise loaded, enabled, and active. Its latest observed checks
reported production readiness HTTP 200 with the expected payload and an
authenticated aggregate-metrics scrape.
- Advancing from this boundary still requires deliberate external mutations:
archive the two exact fixture files outside the production checkout and
restore that checkout to its observed revision, repeat the read-only plan,
approve an application-only release, publish the exact v3 AAB only to Google
Play Internal testing, and create/rotate independently scoped application
and monitor SMTP credentials with delivery checks before revocation. None of
those mutations was performed by this audit.
## Current pilot-candidate recheck on 2026-08-09
- Local revision `beb5de5eda5e7490cf8b757810bf55787cce211f` passed the
complete isolated `scripts/quality.sh` pipeline in user-systemd unit
`codex-heavy-wnh-quality-current-head-20260809-20260809-214131-211016.service`.
The unit completed successfully in 4 minutes 40.738 seconds with a measured
384.7 MiB memory peak. It passed all configured quality and security gates,
456 ExUnit tests, and the final Debian 13.6 image scan with zero detected
vulnerabilities. The later local change through `d2cba21` modifies only the
Play location-video runbook; application and Android source are unchanged.
- Android release candidate `0.1.2 (3)` remains source-bound: the current source
fingerprint and the recorded artifact fingerprint are both
`70529d3befcb0818f0b79f7869389b4fad432eb2911be08d52342529b7f22614`.
The AAB SHA-256 is
`5f1b63d02467ce63af795d16459a75693e415426478e0788b83f0f6d35dff922`,
and the location/foreground-service policy contract passes. The connected
physical phone still has Play-delivered `0.1.1 (2)` installed by
`com.android.vending`; candidate v3 has not been uploaded or delivered and is
therefore not yet Play-verified.
- Read-only production inspection observed checkout
`f0cb936854343be12ce58284d872c68c701ad7f3`, image
`who-need-help:production-f0cb93685434`, a healthy application container, and
the exact public readiness response. The checkout contains two fixture-script
paths prepared for the Play location recording. Their SHA-256 values exactly
match the current local files, and no fixture state file or fixture process
exists. They still make the checkout dirty, so the release preflight must not
proceed until those exact files are archived outside the checkout and the
tracked path is restored to the observed production revision.
- The frozen hackathon-test checkout remains clean at
`cf7bacdf61ffb171ebac85e32dfcf12bc6972d59`, its application, PostGIS, and
Mailpit containers remain healthy, and public readiness returns the exact
ready payload. This recheck did not write to either server checkout, restart a
container, or push Git.
- The daily encrypted off-site backup timer is loaded, enabled, and active. Its
latest service run on 2026-08-09 completed successfully with status 0. The
independent BuyVM monitor timer is also loaded, enabled, and active; its
latest observed run completed successfully and reported production readiness
HTTP 200 with the expected payload plus a successful aggregate-metrics scrape.
These observations leave three deliberate external changes outstanding: the
application-only production release, upload/publication of the exact v3 AAB to
Google Play Internal testing followed by Play-delivered physical-device checks,
and rotation of the exposed production Brevo SMTP credential. None was
performed by this recheck.
## Current production E2E and isolation proof on 2026-08-09
- Read-only inspection observed the independent production checkout at
`f0cb936854343be12ce58284d872c68c701ad7f3`, Compose project
`who_need_help_production`, external database `who_need_help_production`, and
one healthy application container with zero restarts. Public readiness
returned the exact `{"status":"ready"}` response before and after the browser
verification.
- Production E2E run `production-e2e-20260809-f0cb936-r3` passed both Chromium
scenarios: Activity approval/privacy/reporting and the two-person medicine
help flow with realtime chat, consent-based tracking, handover, completion,
and blind reviews. Playwright recorded two expected passes, zero unexpected
results, zero skipped tests, and zero flaky tests in 46.0 seconds. Evidence is
retained at
`output/production-full-e2e/production-e2e-20260809-f0cb936-r3/`.
- The exact cleanup manifest records `cleanup_verified=true`. Its target and
deletion totals agree for all 26 relationship types, including six users,
six user tokens, two requests, three assignments, one Activity, two request
messages, two Activity messages, one tracking session, two reviews, one
report, one category proposal, six audit events, two abuse signals, eleven
notifications, and fourteen run-owned Oban jobs. A direct production query
found zero users with the run prefix after cleanup.
- Every measured product-table count returned to its pre-run value. The global
`oban_jobs` total was one row higher in the after snapshot. A subsequent
read-only time-bounded query observed the production cron inserting
`WhoNeedHelp.Workers.ExpireRequests` maintenance jobs at 14:19, 14:20, and
14:21 UTC, including the 14:21 job between the browser completion and the
after snapshot. The run-owned fourteen job IDs were separately deleted and
verified absent by the cleanup manifest; the global count difference is
therefore concurrent maintenance activity rather than retained E2E data.
- Both local verifier images, every verifier container, the remote temporary
evidence directory, and every run-scoped fixture record were absent after
cleanup. The immutable production application image remained present.
- Independent read-only inspection observed the frozen hackathon-test checkout
still at `cf7bacdf61ffb171ebac85e32dfcf12bc6972d59`, with a clean worktree,
healthy application, PostGIS, and Mailpit containers, and public readiness
returning `ready`. The production E2E did not recreate or restart those
containers and did not push Git.
- Evidence SHA-256 values are
`16287ae10349b509ecabd3de0021bcc7764c201748efb941c9647acc318dec9e`
for `browser/results.json`,
`54ad93cbe6e541e8f0cd3663e9e63155fd96b816ee4550f947af5f1d6ea2e55c`
for `fixture.json`, and
`b6513900d7b44aae5b1b79444df6a9de88fa0f78724f46fc81e2cbf47bf743f7`
for `fixture-cleanup.log`.
## Current local-head quality and security proof on 2026-08-09
- Local revision `16956c62e55d55133f61e006f12217093ba6575c` passed the
complete isolated `scripts/quality.sh` pipeline in user-systemd unit
`codex-heavy-wnh-quality-head-16956c6-20260809-193900-637140.service`.
The unit exited with result `success` and status `0` after 4 minutes
16.637 seconds; systemd observed a 324.7 MiB memory peak.
- The pipeline passed repository policy checks, ShellCheck, production
read-only load and release/rollback/migration drills, Hadolint, actionlint,
Compose rendering, Helm linting, observability validation, source secret and
misconfiguration scans, Elixir formatting and compilation, xref, Credo,
Sobelow, Dialyzer, Hex audit, 456 ExUnit tests, fourteen browser-asset unit
tests, and npm dependency audits.
- The final Debian 13.6 production image and the pinned infrastructure images
scanned in this run reported zero detected vulnerabilities. The quality run
exited only after its own cleanup; exact-name inspection found no remaining
run-scoped image, container, network, or volume.
- The run-owned scope was
`20260809163901-637408` / `wnh_quality_20260809163901637408`.
Exact-name inspection after completion found no matching image, container,
network, or volume. Two other pre-existing quality volumes with different
run identities were intentionally not changed by this verification.
- This is local source verification. It did not deploy the local commits,
change the frozen hackathon-test checkout, or push the public Git remote.
## Production application release on 2026-08-09
- The reviewed application-only release advanced the detached production
checkout from `8ab30ce7f5bd0a28e1423b8da2846fe0e224f50c` to
`ff50a80e48181c9a650d9ec22c927567770686c6`. The release used the immutable
`who-need-help:production-ff50a80e4818` image and did not change the shared
edge/Caddy deployment or push Git.
- The release created and catalog-verified the external PostgreSQL 18.4 backup
`/srv/who_need_help-production/output/backups/production/pre-20260809T061259Z-ff50a80e4818.dump`,
copied it outside the production host, and independently verified the copied
checksum. Its mode-`0600` rollback evidence is retained at
`/srv/who_need_help-production/output/releases/20260809T061321141091841Z-ff50a80e4818/rollback-manifest.txt`.
- Environment validation reported all twelve configured readiness groups ready,
migrations were already current, and the database check observed PostgreSQL
18.4 with PostGIS 3.6. The release unit
`codex-heavy-wnh-prod-release-ff50a80-r2-20260809-091249-2537784.service`
completed successfully in 58.598 seconds with a 93.9 MiB local memory peak.
- Independent post-release inspection found a clean production checkout, one
running healthy application container with zero restarts and no OOM event,
no residual migration container, and the exact ready response. Public HTTPS
returned HTTP 200 for the home page, liveness, readiness, PWA manifest,
`robots.txt`, `sitemap.xml`, and `/.well-known/assetlinks.json`. The sitemap
contained twelve absolute entries, the manifest named Who Need Help, and the
Android association named `org.whoneedhelp.mobile`.
- The frozen hackathon-test checkout remained at
`cf7bacdf61ffb171ebac85e32dfcf12bc6972d59c`. Its application, PostGIS, and
Mailpit containers retained their existing lifetimes and remained healthy;
neither that checkout nor its data was recreated or changed.
- A subsequent production Chromium E2E run passed both the moderated Activity
and two-person mutual-aid scenarios in 44.5 seconds against this exact
revision. It covered request/activity creation and discovery, matching and
approval, private realtime chat, consent-based tracking, handover and
completion, blind reviews, withdrawal/rejoining, reporting, and moderation.
Evidence is retained at
`output/production-full-e2e/production-e2e-20260809-ff50a80/`.
- The production E2E cleanup manifest records `cleanup_verified=true`; every
cleanup target count equals its deleted count. Independent before/after
snapshots both observed 14 users, one retained audit event, 1,440 Oban jobs,
and zero records in the tested help, Activity, chat, tracking, review, report,
proposal, and notification tables. The run-specific user-prefix count was
zero afterward. The remote temporary evidence directory and verifier image
were absent after cleanup, while the immutable production image remained.
These observations prove deployment and public-health/search metadata for this
revision and the two core production browser flows. They do not by themselves
prove external authentication-email receipt, browser Web Push delivery, or
production support/legal queue routing.
## Production authentication, queue routing, and operations recheck on 2026-08-09
- A real public passwordless-login request for the existing production account
`simpletestxxx@gmail.com` returned HTTP 302 to the login check-email page and
retained one hashed login token with the configured 15-minute lifetime. In
this code path the reserved token is deleted when SMTP delivery returns an
error, so the retained token proves that the configured production SMTP
adapter accepted this dispatch. It does not by itself prove arrival in the
external Gmail mailbox; mailbox receipt remains a separate observation.
- One run-scoped authenticated support case and one run-scoped authenticated
general content-removal notice were created for the existing owner account.
Both received `contact_verified_at` immediately, the support case appeared in
the permission-scoped support queue, and the notice appeared in the
permission-scoped legal queue. The removal acknowledgement was accepted by
the configured SMTP adapter. Exact-ID cleanup then deleted only those two
records and their audit events. Before/after totals returned to zero support
cases, zero removal notices, and one pre-existing audit event.
- Production configuration inspection observed operator-email mode `disabled`.
Consequently new support/legal intake is handled through the in-application
staff queues without sending an operator email for every case; requester
acknowledgements and staff replies remain transactional email paths.
- The daily encrypted off-site backup timer was loaded, enabled, active, and
waiting. Its latest completed service exited successfully after a PostgreSQL
18.4 custom-format dump, catalog and checksum verification, encrypted
off-server storage, and an isolated restore. The retained Restic snapshot is
`869e3e3a7444d726daef7e9afbdcc9ee082962a6121ec2e29c942600396fd13c`;
evidence is under
`output/production-operations/20260808T210010Z-2802200/`.
- The independent BuyVM monitor timer was active and waiting. Repeated latest
service executions exited successfully and recorded readiness HTTP 200 with
the expected ready payload plus a successful aggregate-metrics scrape. This
proves the current external probe execution, not an availability SLO.
- The active pilot rate-limit policies observed in production were: registration
and magic-link email 4/hour per address and 120/hour per IP; password login
10/15 minutes per address and 300/15 minutes per IP; email change 3/day per
account and 60/hour per IP; support intake 5/day per account and 120/hour per
IP; content-removal intake 20/day per account and 120/hour per IP. Four live
bucket rows were present at the inspection instant. These values are the
configured pilot policies backed by this project's earlier load checks, not
a universal capacity recommendation.
- After the checks, the compact production application remained healthy with
zero restarts and no OOM event, and readiness again returned the exact ready
response. The frozen hackathon-test checkout and containers were not changed,
and the public remote repository was not updated.
## Read-only release and email-state recheck on 2026-08-13
- The guarded production release plan compared local candidate
`39ba37194f06e0cbc654630a1165eecfb5fed46c` with the still-running production
revision `dafcdb36cbe221af0c880fd05da3321e181ddd2c`. It reported 23 pending
commits, no shared Caddy-file change, and one reviewed `application_safe`
migration, `20260812120611_allow_inbox_only_nearby_subscriptions.exs`.
- The remote scope check observed the detached production checkout, compact
`who_need_help_production` Compose project, external PostgreSQL 18.4 database,
healthy application container, passing public readiness, and 100 GiB free on
the checked root filesystem. Environment validation reported all twelve
release capabilities ready. The plan did not build, transfer, migrate,
restart, or deploy anything.
- The current production process exposed 85 cumulative SMTP adapter successes
and four cumulative SMTP exceptions since that process started. It does not
expose the newer fixed-purpose counters because production still runs the
older revision. These are process-lifetime counters, not proof of 89 distinct
user messages. No active `mail`-queue job was present at inspection time.
- Source inspection of the local candidate confirmed that immediate per-request
nearby email is retired; nearby matching uses inbox and optional push. Support
emails are bounded to contact verification, the first staff response, and
later public status changes instead of every conversation message.
Content-removal confirmation, receipt, and decision messages remain separate.
Non-authentication support/removal delivery uses the dedicated Oban `mail`
queue, while authentication remains synchronous so its database token is not
committed after a failed delivery.
- Public DNS still had no MX record proving inbound delivery for
`contact@whoneedhelp.com`. The Play reviewer template was therefore changed
locally to require a tested, monitored inbound address instead of presenting
the outbound-only Brevo sender as a verified support mailbox.
## Local support/legal and complete browser E2E on 2026-08-09
- The focused isolated Chromium run exercised an authenticated support case,
Mailpit acknowledgement, permission-scoped staff discovery and assignment,
an operator reply and resolution, the requester's private case view, general
content-removal intake, the dedicated TAKE IT DOWN intake, legal-queue
processing, and the resulting decision email. Its one Playwright scenario
passed in 3.3 seconds. The structured result is retained at
`output/e2e/20260809055749-2064536/results.json`.
- The complete isolated Chromium suite then passed all 17 scenarios in 1.4
minutes. In addition to support and legal operations, it covered public and
authenticated responsive/accessibility states, authentication and settings,
localisation, mutual-aid matching/chat/tracking/handover/reviews,
notifications and data export, request discovery and location privacy,
Activity moderation, LiveView reconnect behaviour, and active web-node
failover. The structured result is retained at
`output/e2e/20260809055914-2110249/results.json`.
- Both runs used unique Compose projects and independent PostGIS volumes. After
each run, an exact-name inspection found no remaining matching container,
network, volume, or image. The ordinary development, production, and frozen
hackathon-test projects were not recreated or changed.
- The subsequent complete isolated quality run passed ShellCheck, release,
rollback and migration drills, Dockerfile and workflow linting, compilation,
xref, Credo, Sobelow, Dialyzer, Hex and npm audits, 455 ExUnit tests, Compose,
Helm, observability, backup and image checks, and the configured Trivy scans
with zero reported HIGH/CRITICAL findings. Its user-systemd unit
`codex-heavy-wnh-support-legal-quality-20260809-20260809-090528-2300548.service`
completed in 2 minutes 14.077 seconds with a 280.6 MiB observed memory peak.
Exact-name inspection after its cleanup found no run-owned Compose resource
or image.
These local results prove the implemented browser paths in the isolated E2E
topology. They do not prove production SMTP delivery, production queue routing,
or a staging deployment: the public staging runner now includes the same
support/legal scenario, but it was intentionally not run against the frozen
hackathon-test deployment.
## Public/mobile and Android candidate check on 2026-08-03
- A headed Chrome audit captured the production home at desktop and 390 × 844
mobile viewports, the signed-out requests handoff, support, account deletion,
general content removal, and the dedicated TAKE IT DOWN form. No record was
submitted. The accepted screenshots showed no confirmed horizontal overflow,
clipped primary action, blank state, or public navigation dead end. DOM
snapshots contained skip links, semantic landmarks, visible field labels,
and explicit safety/privacy guidance. The ignored evidence and audit notes
are retained under `output/playwright/production-launch-audit-20260803/`.
- The authorised physical device exposed both the production and an obsolete
development package. The exact development package
`org.whoneedhelp.mobile.development` was removed; the production package and
its data were not changed. The remaining `org.whoneedhelp.mobile` reports
version code `1`, version name `0.1.0`, target SDK `37`, and launches without
an Android fatal exception in the sampled log.
- Pulling the installed production base APK produced SHA-256
`d079a42809155faa86da72281c985f01d4134097e4410cdfbf244869b3027d21`,
exactly matching the source-bound universal APK in
`android/dist-release-20260803-162910/`. Notification and fine/coarse location
permissions remain denied until user opt-in; the foreground-service location
permission is declared/granted by the platform.
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 every Play App Signing certificate used for delivery.
## Production browser E2E on 2026-08-03
The production verifier first confirmed the exact target as detached commit
`b80bf6e9a551ff49a6201f0d2c726b1b8a63e95a`, Compose project
`who_need_help_production`, database `who_need_help_production`, and the single
healthy compact application container with zero restarts. The run did not
deploy source, reset or migrate the database, change real-user roles, send
email, edit Caddy, touch the frozen test project, or push Git.
- Chromium passed both production scenarios in 46.0 seconds. The mutual-aid
scenario exercised two users, medicine discovery and acceptance, private
realtime chat, consent-based tracking, helper replacement, handover-code
verification, both-party completion, reporting signals, and blind reviews.
The Activity scenario exercised creation, join request, organizer approval,
exact-location privacy, participant chat, reporting, moderation, withdrawal,
and rejoining.
- The verifier created six confirmed run-scoped synthetic users and only their
manifest-owned records. Its cleanup removed the exact fixture after success.
Before and after snapshots both contained 14 users, 1 audit event, 1,441 Oban
jobs, and zero help requests, assignments, messages, activities, activity
participants/messages, reports, reviews, tracking sessions/positions,
notifications, category proposals, and category votes. The run-prefix count
was zero after cleanup.
- The throwaway local and remote verifier images, containers, remote output,
and run-scoped fixture were absent after cleanup. Evidence is retained at
`output/production-full-e2e/prod-launch-20260803/`.
This proves the tested web workflow against the deployed production commit. It
does not prove production SMTP delivery, Web Push, Play-delivered Android FCM,
or Google Play review completion.
## Independent production backup and monitoring on 2026-08-03
This verification changed only the independent backup repository, operator
user-systemd units, and independent monitor host. It did not deploy application
source, change production data, modify the hackathon test deployment, push Git,
or edit the Devpost submission.
- An encrypted Restic 0.19.1 repository was initialized at
`sftp:buyvm-maya:backups/who_need_help-production`. SSH resolution verified
that this target and the production target are different hosts. The Restic
password and workflow configuration remain only in ignored mode-`0600`
local files; password-manager/offline key custody is still an operator action.
- Two production snapshots exist. The installed user-systemd execution produced
snapshot `98d7d2e8e3e7c8dbf7908bbaceeb2acedf202a7e1dfd77c5398ba668a7981236`,
passed `restic check --read-data`, and restored into a temporary database
created from `template0`. The isolated restore observed 34 public application
tables, 24 applied schema migrations, and PostGIS 3.6.4. Non-secret evidence
is retained at
`output/production-operations/20260803T012727Z-1694894/`.
- That exact systemd service exited `0/SUCCESS` after 4 minutes 31.643 seconds
wall time, 4.115 seconds local CPU time, and a 78.2 MiB local memory peak.
These are observations of one run over the selected SFTP path, not a minimum
resource requirement or recovery objective. The scheduled source dump and
every run-scoped temporary restore container and volume were absent afterward.
- The daily backup timer is enabled with `Persistent=true`. Its failure unit
routes one alert through the independent monitor host. No retention deletion,
automatic pruning, or database rollback is configured.
- The independent BuyVM monitor performs the public readiness check once per
minute. The observed check returned HTTP 200 with the exact ready payload and
the service exited successfully. Its SMTP configuration and state are mode
`0600`. A one-time monitoring test message was accepted by Brevo; mailbox
receipt has not yet been independently observed, so end-to-end alert delivery
is not claimed complete.
## Production Android bundle replay on 2026-07-28
The release tooling and application inputs below are exact local commit
`c8e95b8c77babb10a9e7578a36ba35fe6f38ff9f`. No push, hackathon-test
deployment, production deployment, Devpost edit, Play application, branch, or
tag was created or changed.
- `./scripts/quality.sh` passed the complete isolated quality/security gate,
including ShellCheck, Hadolint, actionlint, release/rollback/migration
drills, Compose/Helm validation, source and runtime-image scans, formatting,
warnings-as-errors compilation, xref, Credo, Sobelow, Dialyzer, Hex/npm
audits, and all 394 ExUnit tests. The configured scans reported zero
findings.
- The release build read only the explicit Android/OAuth/App-Links allow-list
from the production checkout's mode-`0600` `.env`. Database, SMTP, session,
and FCM service-account secrets were not copied. The temporary allow-list
file was absent after the build.
- The pipeline passed release unit tests, Android lint, R8/resource shrinking,
APK/AAB signing checks, Bundletool validation, package/origin/App-Links
validation, and generated a signed universal APK from the same AAB. The
source fingerprint in the artifact directory exactly matched the committed
tree.
- The candidate is retained at
`android/dist-release-c8e95b8-20260728T013253Z`. The Play AAB SHA-256 is
`812cf843e0f0df9cec22ac8a7e56a92ad6b07200c35548f62ea1184e8c6c419d`;
the universal APK-set SHA-256 is
`1a5794cf540a55856b465d8e20509b9835ac6604872dbaa829e3ac0689430cb7`;
and the extracted universal APK SHA-256 is
`ddd43d81b271f9dd18755f1e3fd3e62459f88206f3da293f525f43e4320b8b51`.
- The universal APK installed successfully on the authorized physical phone.
A verified `https://whoneedhelp.com/safety` App Link cold-started
`org.whoneedhelp.mobile/.MainActivity` in 571 ms. The installed package
reported version code `1`, version name `0.1.0`, minimum SDK 24, target SDK
37, and a verified `whoneedhelp.com` domain. PID-scoped logs contained no
fatal exception, AndroidRuntime, TLS, certificate, or WebView load error.
The rendered phone capture is retained at
`output/android-production-smoke/20260728-c8e95b8/safety-universal.png`.
- Read-only counts after this unauthenticated public smoke remained 14
production users and zero production push devices. The smoke did not create
an account or push-device record.
- Google Play identity review remains an external gate. The Play application
and Play App Signing certificate do not exist yet, so internal-track upload,
Play-generated signing identity, Data Safety/App Content forms, and the
required closed test cannot truthfully be marked complete.
## Physical Android and Play preflight on 2026-07-28
The application source below is exact local commit
`c863b47e5ff9a0e90240a7cf286e627bd87e04ec`. No push, hackathon-test
deployment, production deployment, Devpost edit, branch, or tag was made.
- `./scripts/quality.sh` passed ShellCheck, Hadolint at the configured
threshold, actionlint, release/rollback/migration drills, every Compose
render, Prometheus and Alertmanager validation, Helm lint, tracked-source
and runtime-image scans, formatting, warnings-as-errors compilation, xref,
Credo, Sobelow, Dialyzer, Hex/npm audits, and all 394 ExUnit tests. The
configured source and image scans reported zero vulnerability or secret
findings, and the quality run exited successfully after exact scoped
cleanup.
- The existing signed development application and its instrumentation package
were installed atomically on the connected physical Android device. The
development cross-client replay passed magic-link login, private Android to
browser and browser to Android messages, real FCM registration and
notification delivery, foreground live-location sharing, browser marker
visibility, stop-sharing cleanup, zero retained raw position, and zero
browser TLS or fatal errors. Exact cleanup retained no run-scoped users or
new push device and restored every other tracked application-table count.
Evidence is
`output/android-browser-development-e2e/20260728010201-2368495`.
- The physical-device path now reuses the explicitly selected authorized
device and already installed development packages. It refuses test/staging
variants, does not create an emulator image, and retains run diagnostics
while enforcing exact fixture cleanup after success, failure, or interrupt.
- A read-only inspection of the authenticated Play Console showed no existing
Play application. Google was still verifying the uploaded identity
documents; contact-phone verification was unavailable until that review
completes, and **Create app** was disabled. Firebase development and
production Android clients already exist, but they are not Play listings.
No duplicate Firebase, Google Cloud, or Play application was created.
## Live development deployment verification on 2026-07-25
The local development Compose project was rebuilt and restarted from exact
local commit `7a54477a308181768469bb1012b1ec561400b9fe`. This was a
development-domain deployment only. The hackathon test deployment, production
deployment, Git remote, Devpost entry, branches, and tags were not changed.
- The ordinary development Compose project runs two healthy web replicas, two
healthy worker replicas, a healthy PostgreSQL/PostGIS container, and the
development proxy. The four BEAM nodes passed the repository's realtime
cluster check.
- Both direct proxy readiness on `127.0.0.1:4010` with the configured host
header and public readiness at
`https://whoneedhelp.imalto.site/healthz/ready` returned HTTP 200 with
`{"status":"ready"}`. The public home page returned HTTP 200 and the title
`Who Need Help`.
- `./scripts/check-environment-readiness.sh .env --require-release` reported
zero blocking items and zero local-only warnings. The check found the
development origin, independent application secrets, external SMTP,
support inbox, web and Android Google sign-in, VAPID, Firebase client,
FCM service account, Android App Links, and development signing inputs
present and internally consistent; it did not print their secret values.
- A headed Chrome inspection of the public development domain confirmed the
real MapLibre demo map, localized English and Russian navigation and page
content, the searchable compact language menu, the authentication redirect
for protected request discovery, and the 390 by 844 mobile navigation
layout. The inspected page reported zero browser console errors or warnings.
A mobile viewport capture is retained at
`output/playwright/dev-live-mobile-menu-20260725.png`.
- `./scripts/staging-e2e-run.sh` passed the real public HTTPS mutual-aid flow
against `https://whoneedhelp.imalto.site`: two users, medicine request,
helper replacement, realtime private chat, consent-based tracking,
handover, both-party completion, reporting signals, and blind reviews.
Evidence is `output/staging-e2e/20260725212537-291190`.
- Exact fixture cleanup removed 3 synthetic users, 2 requests, 3 assignments,
2 messages, 1 tracking session, 2 reviews, 2 abuse signals, and 13 audit
events. The before/after application-table snapshots have the same SHA-256
(`e0effacce81c9662c448d4d073578d54c5f779bd1d9f6f9188c7911afbd55659`)
and the cleanup diff is empty. The two unreferenced temporary E2E image tags
were removed explicitly after the run.
- The full public auth/email staging drill was not run against this
development topology because its required local Mailpit endpoint at
`127.0.0.1:8027` was not running. Auth and email behavior remains covered by
the isolated 45-scenario browser matrix and 390-test local quality gate
below; this observation is not represented as a live external-email check.
## Cross-browser and release rehearsal follow-up on 2026-07-25
The observations below apply to local commit
`9875fd7d052367596d3745d130dc3c6342667419`. No push, hackathon-test
deployment, production deployment, Devpost edit, branch, or tag was made.
- `./scripts/e2e-run.sh` passed all 45 scenarios in Chromium, Firefox, and
WebKit. The run covered registration and account settings, localization,
responsive accessibility, requests and activities, viewport discovery and
clustering, exact/approximate/hidden locations, private chat, tracking,
handover, blind reviews, notifications, moderation, and serving-node
restart recovery. Evidence is
`output/e2e/20260725205052-3435033`. The run-scoped containers, networks,
volumes, and images were absent after cleanup.
- The isolated 30-second load run used 40 public HTTP, 40 Phoenix WebSocket,
and 8 authenticated mutual-aid VUs against 3 web and 2 worker replicas.
All 37,854 HTTP requests and 34,578 public checks passed. It completed
1,630 authenticated LiveView join/message/tracking-start/tracking-update/
tracking-stop cycles and 240/240 WebSocket heartbeats. Overall HTTP p95 was
8.27 ms. These are workstation measurements, not production limits.
- PostgreSQL recorded 138,772 commits with zero rollback, deadlock, conflict,
temporary file, or lock waiter. It peaked at 21 client backends and 5 active
backends with at least 76 observed connection slots of headroom. The three
web replicas recorded 177,453 Ecto queries with 0.299 ms average total
duration and 0.027 ms average queue duration. The largest observed
`pg_stat_statements` maximum was 9.808 ms. Exact fixture cleanup restored
every tracked table count. Evidence is
`output/performance/candidate-28940f9-20260725-load`.
- Under that concurrent synthetic profile, individual observed container
maxima were 355.99 MB for a web replica, 228.69 MB for a worker,
146.38 MB for PostgreSQL, and 364.17 MB for the proxy. These are load-run
samples and are not idle-memory measurements or minimum-server claims.
- The associated resilience run recorded 1,164 readiness samples with zero
failures while replacing web and worker processes. Evidence is
`output/resilience/candidate-28940f9-20260725-resilience`. Its exact
Compose project, database volume, networks, and image tags were removed.
- A mode-`0600` custom-format backup and checksum were created at
`output/backups/preprod-20260725T210230Z.dump`. A temporary restore read
33 public application tables and 1,813 rows, confirmed all 19 migrations
and PostGIS 3.6.4, and removed the temporary database.
- The same backup passed the isolated upgrade rehearsal after the rehearsal
was made to wait for the actual Traefik application route rather than only
container state. All 19 migration versions and 11 required cursor indexes
matched, application table counts were unchanged, two web and two worker
replicas formed a four-node cluster, and PubSub plus HTTP checks passed.
Evidence is `output/upgrade-rehearsal/20260725210859-3996878`; all
run-scoped Docker resources were removed. Failed rehearsal runs now retain
proxy and Docker socket-proxy logs before exact cleanup.
- `./scripts/quality.sh` passed after these changes. It included ShellCheck,
release/rollback/migration drills, Compose and Helm validation, source and
image scans, formatting, warnings-as-errors compilation, xref, Credo,
Sobelow, Dialyzer, Hex/npm audits, and 390 passing ExUnit tests. The
configured scans reported zero vulnerability findings and exact
quality-run cleanup left no scoped Docker resources.
- The signed development Android APK was rebuilt from the current source.
Unit tests, Android Lint, package/signing checks, and online App Links
validation passed. On the connected physical Android API 36 device,
`whoneedhelp.imalto.site` was reported as `verified`, `/safety` cold-started
`org.whoneedhelp.mobile.development`, and the real WebView DOM smoke passed
1/1 for `/` and `/safety`. The device sleep setting was restored after the
run. The earlier complete physical chat/FCM/tracking replay remains recorded
separately below.
## Final local candidate verification on 2026-07-25
The web/backend candidate below is exact commit
`4f2ab7d205ad1e137b07a8365e30b7cf007e2a19`. A subsequent test-only Android
commit, `c89dc78`, updates the instrumentation path for the notification
settings panel; it does not change the deployed application. No push,
hackathon-test deployment, production deployment, Devpost edit, branch, or tag
was made.
- `./scripts/e2e-run.sh` passed all 45 scenarios in Chromium, Firefox, and
WebKit. The matrix covers public and authenticated mobile layouts,
localization, accessibility, registration and Google flows, request and
Activity lifecycles, map viewport discovery and clustering, private chat,
location privacy and tracking, notifications, moderation, and restart
recovery. Evidence is `output/e2e/20260725141107-815241`; its isolated
Compose resources were removed.
- `./scripts/test.sh` and the final `./scripts/quality.sh` both reported
387 passing ExUnit tests. The quality gate also passed ShellCheck, Hadolint
at the configured threshold, actionlint, Compose profile rendering,
Prometheus and Alertmanager validation, Helm lint, formatting,
warnings-as-errors compilation, xref, strict Credo, Sobelow, Dialyzer,
Hex/npm audits, release/rollback/migration drills, and tracked-source and
runtime-image scans. The configured vulnerability scans reported zero
findings, and the run-scoped quality resources were removed.
- The isolated 30-second load profile ran 40 public HTTP, 40 Phoenix
WebSocket, and 8 authenticated mutual-aid VUs against 3 web and 2 worker
replicas. All 38,240 HTTP requests and 34,866 checks passed, 240/240
heartbeat replies arrived, and 1,679 authenticated chat/tracking iterations
completed. Overall HTTP p95 was 7.28 ms, authenticated HTTP p95 was
10.81 ms, and WebSocket-connect p95 was 4.76 ms. These are workstation
observations, not production limits or minimum resource requirements.
- PostgreSQL recorded 141,740 committed and zero rolled-back transactions,
with no deadlock, conflict, temporary file, or lock waiter. It peaked at
21 client backends and 5 active backends with at least 76 observed
connection slots of headroom. The three web replicas recorded 181,796 Ecto
queries with 0.275 ms average total duration and 0.022 ms average pool queue
duration. Exact fixture cleanup restored every tracked table count.
- The peak sum of the seven isolated application/proxy/database container
samples was 1,836.4 MiB. Individual maxima were 331.6 MiB for a web replica,
204.6 MiB for a worker, 140.7 MiB for PostgreSQL, and 323.1 MiB for the
proxy. This measured concurrent profile is not a minimum-server claim.
Complete evidence is `output/performance/final-4f2ab7d`.
- The follow-up resilience drill recorded 1,084 readiness samples with zero
failures while restarting and replacing web and worker processes. The final
three-web/two-worker cluster passed cross-node PubSub, and an Oban probe
completed on its second configured attempt after one recorded failure.
Evidence is `output/resilience/final-4f2ab7d`; its isolated stack was
removed.
- A mode-`0600` custom-format development backup was created at
`output/backups/final/dev-20260725-142457-4f2ab7d.dump`; its SHA-256 is
`94747a728f06e9d2c4901ede1236ea0c02319c4b2174e1f52fbd326c9514bd9e`.
The restore drill observed 33 tables, 1,830 rows, all 19 migrations, and
PostGIS 3.6.4 in a temporary database, then removed that database without
changing source counts.
- The same backup passed a full release upgrade rehearsal: all 19 migration
versions and 11 required cursor indexes matched, the application-table diff
was empty, two web and two worker replicas formed a four-node cluster, and
PubSub plus HTTP checks passed. Evidence is
`output/upgrade-rehearsal/20260725142518-1260191`; every run-scoped
container, network, volume, and image was removed.
- A connected physical Android device (`23122PCD1G`) passed the final
development cross-client flow. Instrumentation reported `OK (1 test)` in
16.386 seconds; Android and Chromium exchanged one private message in each
direction, the browser observed the live-location marker, FCM delivery
completed, the foreground service stopped, and the database retained zero
active tracking sessions and zero current positions. Exact fixture cleanup
removed two synthetic users, their request, assignment, two messages, push
jobs, and tracking session with a zero-byte database-count diff. Evidence is
`output/android-physical-final/physical-final-20260725145850-1557566`.
## Goal-completion replay on 2026-07-24
These observations apply to exact local commit
`4f64eab7968182faa16a6ccbc21555de4287c9ec`. The two unrelated, pre-existing
working-tree changes in the staging E2E task and wrapper were excluded from
both isolated worktrees.
- `./scripts/quality.sh` passed every configured source, Compose, Helm,
release, rollback, migration, security, dependency, static-analysis, and
production-image gate. ExUnit reported 367 passing tests; Trivy, Hex, and
npm reported no advisory or vulnerability finding at their configured
severities. The exact temporary quality worktree, containers, networks,
volumes, and image tags were absent afterward.
- A fresh detached-HEAD browser replay passed all 42 scenarios in the
Chromium, Firefox, and WebKit matrix. It exercised registration and account
changes, requests and activities, exact/approximate/hidden map discovery,
clustering, chat, consent-based tracking, handover, blind reviews,
moderation, notifications, restart recovery, accessibility, and responsive
overflow. The exact E2E project
`who_need_help_e2e_20260724185814-755941` and its isolated database were
absent afterward.
- A fresh isolated 30-second load replay used two web and two worker replicas
with 40 public HTTP, 40 WebSocket, and 8 authenticated mutual-aid virtual
users. All 34,755 checks and 38,153 HTTP requests passed, including 1,691
authenticated chat/tracking iterations and 240 WebSocket heartbeat
sessions. Overall HTTP duration averaged 3.095 ms with p95 7.198 ms; the
authenticated scenario averaged 7.48 ms with p95 11.21 ms. These are
workstation observations, not production limits.
- PostgreSQL observed no rollback, deadlock, conflict, temporary file, or lock
waiter. It peaked at 16 client backends with at least 81 observed connection
slots of headroom. Per-web Ecto telemetry recorded 183,553 queries with a
272.59 microsecond average total duration, including 246.44 microseconds of
execution and 25.20 microseconds of pool queue time. Exact fixture cleanup
restored every tracked application-table count.
- Ten sequential resource samples observed maxima of 345.4 and 359.2 MiB for
the web replicas, 225.6 and 222.1 MiB for workers, 120.0 MiB for PostgreSQL,
and 310.7 MiB for the isolated proxy. Evidence is retained under
`output/performance/goal-final-20260724`; the exact load project
`who_need_help_load_20260724190445947286` and its containers, network,
database volume, and image tags were absent afterward.
## Final local development audit on 2026-07-24
These observations apply to the local checkout, its isolated test projects, and
`https://whoneedhelp.imalto.site`. No push, test/production deployment, Devpost
edit, branch, or tag was made.
- Development Google OAuth, Firebase Android configuration, Analytics, and FCM
are consolidated in the Spark-plan project `who-need-help-development`. It
contains the Android app `org.whoneedhelp.mobile.development`, both measured
development signing-certificate fingerprints, and the dedicated
`wnh-dev-fcm-sender` service account. Public Android identifiers and the FCM
service-account credential are present only in the ignored mode-`0600`
development `.env`. `check-environment-readiness.sh .env --require-release`
reports zero blocking items and zero local-only warnings.
- The superseded project `who-need-help-dev-firebase` was audited before
shutdown on 2026-07-28. Google Analytics and BigQuery integration were not
enabled, and Firestore, Cloud Storage, Cloud SQL, BigQuery datasets, and
Firebase Authentication contained no configured data resources. Its only
non-default resource was the replaced development FCM service account and
key. Google accepted the exact project deletion request and reported the
project as shut down and scheduled for deletion with the documented 30-day
owner recovery window. The development, production, and frozen staging
projects were not selected by that operation.
- The current development workers were recreated with that FCM configuration
only after a mode-`0600` custom-format database backup was written to
`output/backups/dev-before-fcm-workers-20260724-114450.dump` and its checksum
and archive catalog passed. Web replicas, proxy, database, test, production,
public Git, and Devpost were not changed.
- The complete Android/browser development replay passed on the stable Android
37.1 Google APIs image with Google Play Services `262031038`. It completed a
magic-link login, Android-to-browser chat, browser-to-Android chat, FCM device
registration, a real FCM system notification, foreground live-location
sharing, and stop-sharing cleanup. The exact fixture retained two messages
and six tracking samples during verification, then cleanup restored the
original database counts with zero current tracking positions. Evidence is
`output/android-browser-development-e2e/20260724121700-2530398`; the
run-scoped container, AVD volume, image, and database fixture were absent
afterward.
- The same cross-client development flow then passed on a connected physical
Android device. The signed development app completed magic-link login,
registered its FCM token, exchanged one message in each direction with the
browser, displayed a real private FCM notification, started the foreground
location service, stored one physical location sample, and stopped sharing
with zero active sessions and zero retained current positions. The replay
exposed a Firebase Messaging main-thread call; auto-init and unregister now
run serially on the application Firebase executor. Instrumentation reported
`OK (1 test)` in 8.73 seconds. Exact fixture cleanup restored both synthetic
users, their request, assignment, messages, push jobs, and tracking session
to zero. Evidence is
`output/android-physical-development-e2e/physical-20260724-191948-1352510`.
- A separate signed development smoke passed on Android 37.1. Android verified
the exact App Link host, the implicit same-origin deep link opened the app,
the home and `/safety` DOM assertions passed, an unrelated HTTPS origin was
not claimed, and no WebView load or TLS error was recorded. Evidence is
`output/android-development-smoke/20260724124143-3282044`; its exact
container, volume, and image were absent afterward.
- `./scripts/test.sh` passed all 356 ExUnit tests. The final isolated browser
suite passed all 42 scenarios in Chromium, Firefox, and WebKit after updating
one stale assertion to the product's already-covered double-blind review
reveal behavior. Evidence is `output/e2e/20260724122808-2848321`; all
run-scoped containers, networks, database volume, and images were absent
afterward.
- `./scripts/quality.sh` passed ShellCheck, Hadolint at the configured threshold,
actionlint, every Compose render, Prometheus and Alertmanager validation,
Helm lint, tracked-source and image scans, formatting, warnings-as-errors
compilation, xref, strict Credo, Sobelow, Dialyzer, Hex/npm audits, all 356
ExUnit tests, and the isolated release/rollback/migration drills. The quality
project's exact temporary resources were absent afterward.
- The final isolated 30-second load run used 3 web and 2 worker replicas with 40
public HTTP, 40 WebSocket, and 8 authenticated mutual-aid virtual users. It
completed 38,364 HTTP requests and 34,890 checks with zero failures, including
1,729 authenticated chat/tracking iterations. HTTP p95 was 6.776 ms and the
authenticated HTTP p95 was 9.88 ms. These are workstation measurements, not
production limits or minimum resource requirements.
- During that load, PostgreSQL peaked at 21 client backends with at least 76
connection slots of observed headroom. It recorded zero rollbacks, deadlocks,
conflicts, temporary files, or lock-waiting backends. Ecto telemetry across
the three web replicas observed 186,908 queries with a 0.250 ms average total
duration; the largest individual statement maximum in `pg_stat_statements`
was 8.300 ms. The exact application-table cleanup diff was empty. Evidence is
`output/performance/final-local-audit-load`.
- Observed load peaks were 335.7 MiB for one web replica, 239.5 MiB for one
worker, 141.6 MiB for PostgreSQL, and 307.2 MiB for the isolated proxy.
CPU peaks occurred under the deliberately concurrent workstation replay and
are retained in `resource-summary.json`; no arbitrary production threshold is
inferred from them.
- The follow-up resilience drill restarted and sequentially replaced all 3 web
and 2 worker replicas. It recorded 1,244 readiness samples with zero failures,
observed all replacement web nodes, and passed the cross-node PubSub probe.
Application logs contained no error, fatal, panic, timeout, deadlock, or
out-of-memory marker. Evidence is
`output/resilience/final-local-audit-resilience`; the exact isolated load
project and resources were absent afterward.
- A visible Chrome session on the development origin rendered the real MapLibre
landing-page demo with its three synthetic markers and zoom controls. The
unauthenticated Requests navigation correctly redirected to login and showed
the access guard. The isolated browser suite covers the authenticated request
map, viewport discovery, clustering, and request lifecycle.
## Local dev hardening audit on 2026-07-23
These observations apply only to the local checkout, its Compose project, and
`https://whoneedhelp.imalto.site`. No push, test/production deployment, Devpost
edit, branch, or tag was made during this audit.
- The final `./scripts/quality.sh` run passed ShellCheck, Hadolint at the
configured threshold, actionlint, every Compose render, Prometheus and
Alertmanager validation, Helm lint, Trivy source and image scans, formatting,
compilation, xref, strict Credo, Sobelow, Dialyzer, Hex audit, both npm audits,
and all 353 ExUnit tests. The configured image scans reported zero
vulnerabilities, and the run left no project-scoped quality containers,
networks, volumes, or one-run image tags.
- A dedicated Brevo SMTP key and verified sender
`Who Need Help Development <dev@whoneedhelp.com>` were configured only in the
ignored local development `.env`. Brevo reported the sender domain as
authenticated with DKIM and DMARC. A release-container delivery probe sent one
non-authentication verification message to the operator inbox without
creating application or database data; Brevo's transactional log recorded
`Sent`, `Delivered`, and `First opening` for that exact subject and sender.
The disposable probe container was removed, and no test or production sender,
key, environment, container, or deployment was changed. On 2026-07-24 the
development application replicas were rebuilt and restarted with the external
SMTP and Google configuration. Port 587 produced no SMTP banner from either
the host or application container, while port 2525 completed a verified
STARTTLS handshake from both. The ignored development `.env` therefore uses
port 2525. A real application-generated Google ownership-verification message
was accepted in 853 ms and observed in the Gmail inbox from
`dev@whoneedhelp.com`.
- At this point in the audit, `./scripts/check-environment-readiness.sh .env`
still reported the four Firebase Android values and the FCM service-account
credential as blockers. They were subsequently configured and externally
exercised as recorded in the final 2026-07-24 audit above.
- The user subsequently accepted Firebase's separate terms in the authenticated
dev-port Chrome session. A separate Spark-plan development Firebase project
was then created and configured as recorded in the final audit above.
- Real browser Web Push was exercised on the development origin through the
user's existing dev-port Chrome profile. The exact origin permission was
changed from `Ask (default)` to `Allow`; the application registered a second,
user-owned Web Push device with `POST /mobile/push-devices` returning `201`.
A one-time development notification then created one dispatch job and one
device-delivery job. Both completed on their first attempt without recorded
errors, while the LiveView inbox updated to one unread notification and the
device remained active. Subscription endpoints and key material were not
printed or copied. The operating-system notification surface itself was not
programmatically observable, so no claim is made about its visual appearance.
- The same Chrome session did not expose a WebGL context on the notifications
page. Both the initial map mount and the explicit retry reported
`webgl-context-unavailable` with no server or console error. The location form
remained usable through its documented manual-coordinate fallback. This
records a browser capability observation rather than a map-server failure.
- The SSH production release `plan` action was repeated read-only. It observed
production commit `921e04b3608007675e22e7e26e0beb3975dbba58`, compact
topology, external PostgreSQL 18.4, healthy application containers, and
passing public readiness. The plan correctly refused release because the
production checkout still lacks browser VAPID, the Firebase Android client,
server FCM delivery, and Android App Links. It reported 57 pending local
commits and made no remote change.
- A separate read-only isolation check observed the public Git `main` reference
still at production commit `921e04b3608007675e22e7e26e0beb3975dbba58`.
The test checkout remained clean at
`cf7bacdf61ffb171ebac85e32dfcf12bc6972d59`, with
`DEPLOYMENT_ENV=test`, Compose project `who_need_help_test`, its own
container database, and healthy application/database containers. Both
`https://test.whoneedhelp.com/healthz/ready` and
`https://whoneedhelp.com/healthz/ready` returned `ready`; no test,
production, public-Git, or Devpost mutation was performed. The server-side
`validate-deployment-isolation.sh` check also passed across the two checkouts,
confirming independent Git metadata and one mode-`0600` `.env` per
deployment, with separate Compose projects, images, databases, OAuth
clients, email paths, and application secrets.
- A separate manual application rollback command now consumes only a successful
release's mode-`0600` manifest. Its plan verifies current/previous commits,
old application/edge images, backup checksum/catalog, runtime identity, and
public health. Apply requires an exact target/previous-commit confirmation,
atomically restores four image selectors, and recreates only the active
application topology and edge with `--no-deps --no-build`; Git, migrations,
the database, test, public Git, and Devpost are excluded. An isolated offline
fixture passed read-only plan, successful apply, and injected-edge-failure
recovery, including restoration of the original image selection.
- The clean local commit
`89851097fd5cbe58ce4dc41c2322810894cad50a` was packaged as a Git bundle under
`output/releases/89851097fd5cbe58ce4dc41c2322810894cad50a/`. Its SHA-256
checksum, bundle object graph, and `HEAD` identity all passed verification.
The isolated production rollback drill was repeated after packaging and again
passed plan, apply, and injected edge-failure recovery without contacting or
changing the production runtime.
- A current development database backup was created at
`output/backups/compose-20260723-194923.dump` with SHA-256
`4202a152751d588c19069eb46a25753901238729b47e6197945afdca20b65c2e`.
The checksum and archive catalog passed, and an isolated restore read 31
public tables and 1,717 rows, observed PostGIS 3.6.4 and all 18 migrations,
then removed the exact temporary database. The live counts remained 7 users,
12 requests, 15 messages, and 18 migrations; local and public DEV readiness
both continued to pass.
- The same backup then passed a full isolated upgrade rehearsal at source
commit `1793258f97e45c3de24d4d855465e1572890ecf2`. The rebuilt release restored
all data, retained all 18 migration versions and all 11 required cursor
indexes, produced a zero-byte application-table diff, formed a four-node
cluster with cross-node PubSub, and passed trusted-proxy/public-origin HTTP
checks on two web and two worker replicas. Evidence is
`output/upgrade-rehearsal/20260723195143-1759181`; the exact rehearsal
containers, networks, volume, database, and image were absent afterward.
- A clean deployment from the tracked archive at commit
`71510a2ab4fb5e2fb2aa65bdf05a358e5045923b` passed on Docker Engine
29.6.2 and Compose 5.3.1. It independently built the application, Docker
socket proxy, PostGIS, and Traefik images, applied all 18 migrations twice
without changing the 14 seeded categories, started two healthy web and two
healthy worker replicas, formed a four-node BEAM cluster, passed a
cross-node PubSub probe, and returned ready HTTP plus working home,
registration, and Mailpit responses. Evidence is
`output/portability/20260723195646-1902488-616f83`. After the run, exact
checks found zero project containers, networks, volumes, and one-run images;
the temporary tracked-archive workspace was absent, while both local and
public DEV readiness remained HTTP 200.
- Two web and two worker replicas, PostGIS, Mailpit, Traefik, and the scoped
Docker socket proxy were running after the audit. Both web replicas and both
workers were healthy; public liveness and readiness returned `ok` and
`ready`. Read-only database checks observed 7 users, 12 help requests, 8 help
assignments, 15 messages, 2 activities, 4 activity participants, 9 tracking
sessions, 0 current positions, 6 reviews, 4 support requests, and 18 applied
migrations.
- A same-helper withdraw/rejoin defect was reproduced against existing dev data:
messages belonged to the earlier assignment and disappeared from the rejoined
assignment. Pair chat now follows `(request, helper)` across that helper's
assignments, while a replacement helper receives a separate empty thread.
Domain tests cover both continuity and replacement isolation. The supporting
`help_assignments(request_id, helper_id)` index was created through the Ecto
migration workflow, applied to dev, and observed in PostgreSQL.
- Headed Chrome verified email magic-link login for an existing Activity
participant, completed-Activity exact-location access, participant lists, and
read-only group-chat history with no console errors or warnings. It also
verified the request pair-chat replay, mobile and desktop navigation, Escape
dismissal with focus restoration, request creation layout, viewport discovery,
and the mobile landing-page map after its lazy-load boundary. Audit screenshots
are retained under `output/playwright/`.
- A final fresh isolated browser run on commit
`0b9589f4fa327bf756ffb0b101fa1a042c3d2be9` passed its one-time administrator bootstrap
1/1 and all 42/42 scenarios in Chromium, Firefox, and WebKit. It re-exercised
authentication/settings, request discovery and clustering, location disclosure,
the full two-user medicine flow, active-node failover, Activity moderation,
notifications/export, localization, accessibility, responsive layouts, and
reconnect behavior. Evidence is retained at
`output/e2e/20260723232436-3328529`. A preceding run exposed stale E2E marker
text after the map legend improvement; the expectation was corrected to the
observed `Helper's live location` accessible name. A fresh focused auth replay
also passed 3/3 across the same browser engines. All run-scoped containers,
networks, Postgres volumes, and image tags were absent after both successful
runs.
- The isolated lifecycle load wrapper completed a scoped smoke run with 5,634 of
5,634 successful checks and 6,136 requests with zero failed requests, then
removed its exact containers, networks, named volume, temporary environment,
and image tags. The full retained measurement at
`output/performance/goal-dev-20260723-005415` recorded 35,004 successful checks,
38,270 requests with zero failures, 1,625 authenticated iterations, 240 WebSocket
sessions, a 7.63 ms HTTP p95, and a peak of 21 database connections. These are
workstation observations, not minimum server requirements.
- The retained resilience drill at
`output/resilience/goal-dev-drain-retry-20260723` observed explicit readiness
drain before sequential web replacement, replaced all 3 web and 2 worker
replicas, verified cluster/PubSub recovery and an Oban retry, and recorded zero
failed readiness samples. The ordinary deployment keeps Traefik's insecure API
disabled; the drill enables it only inside its isolated Compose networks to
inspect backend health state.
- A custom-format backup at
`output/backups/dev-goal-20260723-005318.dump` was restored into a fresh
database and verified with 31 tables, 1,722 rows, 17 then-current migrations,
and PostGIS 3.6.4. The later chat index migration explains the current dev
count of 18 migrations; the earlier backup was not rewritten.
## Local completion audit on 2026-07-22
The following results describe the uncommitted local workspace only. No test or
production deployment, repository push, or Devpost edit was performed as part of
this audit.
- `mix precommit` passed compilation with warnings treated as errors, formatting,
strict Credo and Sobelow checks, and all 337 ExUnit tests.
- The isolated Playwright suite passed all 42 scenarios in Chromium, Firefox, and
WebKit. It covers the requester/helper lifecycle, matched and Activity chat,
consent-driven location sharing, helper withdrawal and replacement, activity
leave/rejoin, moderation, notification preferences, nearby alerts, data export,
accessibility, and serving-node failure/reconnection. Evidence is retained at
`output/e2e/20260722212235-234952`.
- A fresh focused Chromium replay of nearby alerts, private notification inbox,
preferences, and data export passed in
`output/e2e/20260722213500-500926`. A separate headed Chrome session then
completed email-only registration through isolated Mailpit and rendered the
connected notifications/nearby-alert UI with zero console errors or warnings.
- The Android Docker build passed JVM unit tests, lint, debug APK assembly, debug
instrumentation APK assembly, and the configured Android test target.
- A 30-second isolated load run used 88 concurrent virtual users, completed 13,672
iterations and 38,586 HTTP requests, and recorded 35,118/35,118 successful
checks with zero failed HTTP requests. Observed HTTP latency was 2.19 ms average
and 6.42 ms p95; authenticated paths were 7.07 ms average and 9.68 ms p95.
Minimum observed database connection headroom was 76. These are workstation
measurements, not minimum server requirements. Evidence is retained at
`output/performance/goal-local-20260722`.
- The 50,000-row-per-table PostGIS benchmark measured the viewport query at about
10.985 ms, clustering at about 21.164 ms, concentrated leaderboard aggregation
at 48.566 ms, and reputation aggregation at 34.601 ms. Evidence is retained at
`output/db-scale/20260722204033-3485619`.
- Direct Web Push and FCM adapters, private payload shape, durable retries,
invalid-device cleanup, browser/device registration lifecycle, and Android deep
links are implemented and locally tested. Delivery through an external Web Push
endpoint or a physical Android device remains unverified because this local
audit had no VAPID/FCM credentials or registered external device.
- Account export is implemented as an authenticated allowlisted JSON download.
Account-deletion requests now have a moderator-only, read-only relationship
preflight. Destructive erasure/anonymisation is intentionally not enabled until
a jurisdiction-specific retention policy and operator approval workflow are
defined.
## Verified MVP capabilities
| Requirement | Status | Observed evidence | Limit |
| --- | --- | --- | --- |
| Urgent medicine-help flow | Implemented and tested | Request creation, discovery, matching, start, handover, two-party completion, and review rules are covered by the Phoenix test suite and exercised in the local UI. | The product coordinates pickup of an already purchased or reserved legal item; it is not a pharmacy, medical, or emergency service. |
| Urgent roadside help | Implemented and tested | Fuel, car wheel, bicycle, motorcycle, vehicle-breakdown, and secured-incident categories are seeded as a translated hierarchy. Server and LiveView tests exercise category paths, required fields, allowed values, boolean normalization, unknown-field rejection, and request creation. | Roadside requests require no immediate danger; this is not emergency response or professional recovery. |
| Extensible categories | Implemented and tested | Categories and validated text/select/boolean fields are stored in PostgreSQL. Proposal, vote, approve, reject, and merge paths have automated tests. | Coffee, cinema, hiking, and other social activities remain separate from urgent-help safety and ranking rules. |
| Separate Activity mode | Implemented and tested | Coffee, cinema, walk, and hiking categories use a separate activity lifecycle. Domain and two-client LiveView tests cover creation, join request, organizer approval, capacity enforcement, public/pending/chat privacy, exact-location disclosure to approved users, group chat, blocking, completion, and zero impact on helper reputation. Activity and message reports expose only the linked group conversation to an audited moderator; moderators can hide and restore reported activities. | This does not guarantee participant identity or physical safety. |
| Map and discovery | Implemented and browser-verified | The committed isolated Chromium suite rendered request and Activity maps, waited for MapLibre `idle`, and completed with no console, page, or request failures against a local PNG raster fixture. An earlier headed session rendered the configured OpenStreetMap tiles. | A production operator must configure a tile provider appropriate for its policy and traffic. |
| Private matched chat | Implemented and cross-client verified | A message sent from the helper browser appeared in the requester's browser without reload. An earlier Android emulator run also sent a message that appeared in the requester browser in real time. | There is no unsolicited general-purpose inbox. |
| Consent-driven live tracking | Implemented and cross-client verified | On API 37, Android started `TrackingService` as a location foreground service with a persistent Stop notification. The Play-delivered production build repeated the disclosure, foreground permission, minimized-app sampling, notification Stop, raw-position deletion, offline recovery, and process-recreation paths on a physical phone. | Browsers stop with the page. Android has no `ACCESS_BACKGROUND_LOCATION`, unattended start, or route history. |
| Privacy settings | Implemented and browser-verified | The profile exposed hidden, approximate public, exact for active match, and explicit exact-public options. Blocking and current-position cleanup have automated tests. | Exact public location remains a user opt-in; legal privacy and retention text still requires jurisdiction-specific review before launch. |
| Reputation and anti-abuse | Implemented at MVP level | Handover codes, two-party completion, double-blind reviews, unique-counterpart ranking, optional movement/proximity evidence, reports, blocks, abuse signals, and moderator audit paths have automated tests. | The system is not bot-proof and does not claim identity verification. No punitive numeric policy is enabled without measured and approved thresholds. |
| Account registration and sign-in | Implemented and browser/physical-device verified | Email registration is a single passwordless flow: it records the display name and acceptance once, sends a confirmation link, and does not duplicate a user on subsequent sign-in. Confirmed users can keep using magic links or add a password in settings. Google OpenID Connect registration, sign-in, link, unlink, replay prevention, verified-email enforcement, and account-ownership rules are covered by the automated suite. Real headed Chrome exercised the development callback and identity-linking paths. The Play-delivered production build then completed production Google sign-in without a secondary ownership email or duplicate account. A production authentication email was also observed in the external Gmail mailbox with `whoneedhelp.com` DKIM signing. | Brevo rewrites the action href through its tracking domain; direct production-domain action URLs remain an open deliverability/privacy check. |
| Notifications and nearby alerts | Implemented and browser/physical-device verified | Users can configure push, quiet hours, category/urgency/day/time filters, a private matching center, and 1/3/5/10/25 km radii. Durable inbox notifications and Oban push jobs are tested; public notification payloads omit chat text, exact coordinates, and the private saved-area label. Immediate per-request nearby email is retired. Development Web Push and FCM delivery were exercised. The Play-delivered production build registered its FCM device, received one run-scoped production notification, and routed its tap to the in-app inbox; exact cleanup removed that notification and its jobs. A guarded production smoke then delivered one browser-only job to the newest real active Web Push subscription on its first attempt and removed the exact job and notification. | A batched nearby email digest is not implemented; it requires a defined cadence and delivery cursor. Provider acceptance and the still-active subscription are verified; visible operating-system presentation and click navigation were not programmatically observed. |
| Social profiles | Manual links implemented; optional GitHub verification implemented and automated-tested | Manual links cannot set verification fields. The optional GitHub flow uses state, PKCE, a user-bound one-time session, unique provider ownership, and an audit record. The local protocol drill also performs real HTTP token/user exchanges without returning an access token to the application. | GitHub OAuth credentials are intentionally absent and are not required for registration or the help flow. The real external provider redirect/callback remains disabled and unverified; other providers remain manual/unverified. |
| Support and content removal | Implemented and browser-verified | Public support, account deletion, general removal, and TAKE IT DOWN forms use separate audited workflows; public support remains pending and outside the staff queue until its private email link verifies the contact, while authenticated submissions use the account email immediately. Exact pending repeats are deduplicated, email/IP intake limits are independently configurable, and moderator-only operations can update verified cases. TAKE IT DOWN accepts URLs/text only and records a 48-hour review due time. Authenticated users can download an allowlisted JSON export, and moderators can run a read-only deletion relationship preflight. | The current product hosts no user media and does not claim TAKE IT DOWN coverage. Staffing, measured rate-limit thresholds, jurisdiction-specific legal classification, final retention rules, destructive account erasure/anonymisation, and identical-media-copy handling remain operational/legal work. |
| Voluntary thanks | Implemented as an external optional link | A helper can expose an optional link after completion; the UI states that the platform does not process the payment. | The platform does not provide payments, escrow, refunds, tax reporting, or payment guarantees. |
| Android client | Play Internal build verified on a physical phone | The native packages `org.whoneedhelp.mobile.debug`, `org.whoneedhelp.mobile.development`, `org.whoneedhelp.mobile.staging`, and `org.whoneedhelp.mobile` are separated by build type and signing identity. Google Play accepted AAB SHA-256 `03d39a9a08e9ca7569caccf1c7bd75e9349f7655935e7bbf23d1998cd37b3837` as `0.1.0 (1)` on Internal testing. The Play-delivered package passed installer/signature/domain verification, Google sign-in, verified App Links, production FCM delivery, foreground-location disclosure and lifecycle, notification Stop, offline recovery, process recreation, and exact fixture cleanup. | Closed testing and Production rollout have not been started. Android has no unattended/background-location permission; iOS is not implemented. |
| Multiple web/worker instances | Implemented and locally failure/rollout-verified | The final isolated Compose drill passed BEAM crashes and sequential replacement with 3 web/2 worker replicas: all five nodes joined, PubSub passed, and 744/744 readiness requests succeeded. The project-owned kind cluster replaced all 2 web/2 worker pod UIDs under `maxUnavailable=0`; all four replacement pods joined, PubSub passed, and 363/363 samples ultimately succeeded. | Local PostGIS is a single instance. Production database HA, backups, and recovery are operator work and are not claimed complete. |
| Local observability | Implemented and protocol-verified | Pinned Prometheus scraped the exact 3 web and 2 worker targets with a file Bearer credential; Grafana provisioned a healthy datasource and ten-panel web/worker/BEAM/Ecto/Oban dashboard; Alertmanager delivered firing and resolved webhooks for an induced scoped replica stop. | Local delivery does not establish production retention, notification-provider reliability, on-call policy, or measured alert thresholds. |
| Encrypted local backup | Implemented and failure-verified | Pinned Restic streamed PostgreSQL custom format into pinned local MinIO with no host plaintext dump, passed full-data checking and a fresh-database restore, rejected a corrupted repository, and published no snapshot for an interrupted upload. The one-run MinIO project and volume were removed after retaining the non-secret evidence. | The drill proves the local mechanism, not off-site durability, database HA, or a production RPO/RTO/retention policy. |
| External protocol boundaries | Implemented and provider-verified for the current pilot paths | Assent/Req and Swoosh/gen_smtp paths have internal success/rejection/retry/replay/timeout coverage. Google OIDC discovery/authorization/token/JWKS with nonce and PKCE and the optional GitHub boundary are locally exercised through mocks. Real development checks covered Google, authenticated Brevo SMTP, Web Push, and FCM. Production checks covered Google OIDC, Brevo authentication-email receipt, browser Web Push provider acceptance, and FCM delivery. The current push code includes provider-neutral HTTP delivery plus standards-based Web Push and FCM adapters with durable Oban retries and invalid-device cleanup. UniSender observations below are retained only as historical evidence and do not describe current wiring. | The real GitHub provider, direct production-domain authentication action URL, visible browser OS-notification interaction, and APNs remain unverified. SMTP exactly-once delivery is not claimed. |
## Reproducible checks
- On 2026-07-21, commit `437650d5e2c376b7e4254265c022fff67bbafb6f`
was deployed only to `https://test.whoneedhelp.com`. Two independent headed
Chrome contexts registered dedicated requester and helper accounts and
completed the medicine-request lifecycle: validated creation, discovery,
acceptance, realtime chat, start, two consented location samples, realtime
marker movement, tracking stop and raw-position cleanup, handover code,
both-party completion, double-blind reviews, and leaderboard update. The same
run verified privacy-setting persistence, category proposal/vote, Activity
creation/join approval/private chat/exact-location disclosure/completion,
message-scoped reporting, and block/unblock behavior. Read-only database
checks confirmed two tracking samples, 175.73 metres of aggregate movement,
no active tracking session or stored current position after stop, and review
reveal only after both reviews existed. A blocked conversation still rendered
its form even though the server rejected the message; that defect was fixed,
covered by a regression test, redeployed only to test, and browser-rechecked.
The Dockerized Phoenix suite passed 286 tests, format checking passed, and
both clean password logins were repeated in fresh headed browser contexts
with zero console errors or warnings. Production remained on commit
`4f2a9aaacc8eca606f3287df5c8663be49f9595b` throughout this verification.
- On 2026-07-21, commit `811ddf4c5c3847fbb0c2861e6e72fcd6a9bd91fe`
was deployed only to `https://test.whoneedhelp.com`. Headed Chrome attached to
the user's existing dev-port profile completed real Google authorization,
one-time account creation, logout, and returning-user Google login. Browser
console inspection reported zero errors and zero warnings for the app flow.
Read-only PostgreSQL checks observed exactly `1 user / 1 Google identity / 0
duplicate provider UIDs`; the user was confirmed, had accepted terms, and
had no password. A subsequent email magic-link was delivered to the isolated
test Mailpit, required an explicit confirmation POST, signed the same user
in, and left `0` reusable `login` tokens and `1` active `session` token.
Application logs recorded only the expected 200/302 responses for those
paths. Production remained on commit
`4f2a9aaacc8eca606f3287df5c8663be49f9595b` during this verification.
- A separate non-authentication production delivery-format check was accepted
by UniSender Go and observed in Gmail from
`Who Need Help <contact@whoneedhelp.com>`. The intended HTTPS test-domain
link remained the link's actual destination because link tracking was
disabled. UniSender appended its sender attribution and an unsubscribe link
on `email.whoneedhelp.com`; this provider-added footer was observed rather
than inferred. No account or application database row was created by that
delivery check.
- On 2026-07-21, `./scripts/test.sh` and the Dockerized `mix precommit` each
passed 273 tests after the support/content-removal implementation. The full
isolated `./scripts/quality.sh` gate passed compiler, xref, Credo, Sobelow,
Dialyzer, Hex/npm audits, Compose/Helm validation, and configured source/image
scans. Headed Chrome over `https://whoneedhelp.imalto.site` verified public
support acknowledgement and contact verification, general removal intake,
the separate urgent TAKE IT DOWN form and 48-hour due time, passwordless
account confirmation, admin-only queues, audited operator response email,
account-deletion navigation, Russian localization, selected-status
preservation, and zero browser-console errors or warnings.
- On 2026-07-20, after adding Google OpenID Connect authentication,
`./scripts/test.sh` and `mix precommit` each passed 260 tests with zero
failures. The full isolated `./scripts/quality.sh` gate also passed format,
compilation with warnings as errors, xref, Credo, Sobelow, Dialyzer, Hex and
npm audits, Compose/Helm rendering, environment validation, and configured
HIGH/CRITICAL source/image scans.
- The Google boundary drill used the production Assent adapter against a local
OIDC server with discovery, authorization, token, signed ID token, JWKS,
state, nonce, PKCE, unverified-email rejection, and one-time callback replay
checks. It passed together with GitHub OAuth, SMTP, push, and two-worker Oban
paths. Evidence is retained at
`output/external-boundaries/google-auth-fixed-20260720`.
- In an earlier isolated local run, headed Chrome verified the temporary HTTPS
origin through the
email-only registration form, Mailpit confirmation link, one-time login,
password creation, logout, password login, Russian locale selection, and
Google connection settings. That run's Google credential pair was empty,
so the UI correctly left Google actions disabled. Browser console inspection
reported zero errors and zero warnings. The run-owned account and its one
cascading login token were removed after read-only relationship checks; no
help, activity, message, tracking, review, or OAuth rows belonged to it. The
browser was left open.
- The isolated Phoenix suite completed on 2026-07-19 with 172
tests and 0 failures after cursor pagination, database aggregation, and the
full localization changes
on Elixir 1.20.2 and Erlang/OTP 29.0.3.
- `mix compile --force --warnings-as-errors` and
`mix format --check-formatted`: passed against the same final source.
- `./scripts/quality.sh` passed ShellCheck 0.11.0, Hadolint 2.14.0 at warning
threshold, actionlint 1.7.12, every configured Compose profile render, Helm
lint, Trivy source/rendered-manifest scanning, xref, Credo high-priority
checks, Sobelow strict/private checks, Hex audit, 186 Phoenix tests, both npm
audits, and the
backup/MinIO/mc/external-mock/release-image vulnerability scans. The rendered
Helm manifest reported zero HIGH/CRITICAL misconfigurations; the Alpine
backup, MinIO, mc, and external-mock images and the Debian 13.6 release image
each reported zero HIGH/CRITICAL vulnerabilities under the configured gates.
The backup binary reported
Restic 0.19.1 compiled with Go 1.26.5; MinIO and mc reported their pinned
commits and Go 1.26.5.
- Dialyzer passed with three path- and warning-specific documented filters and
zero unused filters. Two findings are opaque-type warnings at Ecto
`Multi`/`MapSet` call sites; the third is the generated Gettext backend's
three-form plural-rule opaque-value warning;
the filters are visible in `.dialyzer_ignore.exs` rather than hidden by a
broad pattern. This is not a claim that third-party dependency compilation is
warning-free.
- The generated Activity migration was rolled back by exactly one step and
migrated forward again against `who_need_help_test`; both directions passed.
- The Activity-report migration was also rolled back and migrated forward. The
observed database constraint changed from exactly one of 3 urgent-help
targets to exactly one of 5 urgent-help/Activity targets.
- `mix format --check-formatted`: passed in the final run.
- Android local Docker build targets `testDebugUnitTest`, `lintDebug`,
`assembleDebug`, and `assembleDebugAndroidTest` passed. The isolated runners
then passed 7/7 instrumentation tests on API 24, API 30, API 34, and API 37.
Each API also passed the separate external process-death probe. The
sixth test verifies that the foreground service survives Home plus Activity
destruction and remains user-stoppable. The seventh forces the first
main-frame request to disconnect, checks the native recovery dialog, presses
Retry, and asserts the subsequently rendered WebView DOM. The
public-staging target passed unit tests, `lintStaging`, `assembleStaging`,
and `assembleStagingAndroidTest`; the API 37 staging smoke asserted the
rendered `/` and `/safety` DOM from the temporary HTTPS origin with no
observed load/TLS errors. Evidence is retained at
`output/android-instrumentation/api24/20260720134554-2360359`,
`output/android-instrumentation/api30/20260720135239-2511867`,
`output/android-instrumentation/api34/20260720133058-2058554`,
`output/android-instrumentation/api37-0/20260720133350-2117132`, and
`output/android-staging-smoke/20260720052802-802174`.
The AVD configuration requests a 1 GiB userdata partition. Emulator 36.6.11
nevertheless checked for approximately 7.37 GiB while initializing API 34;
two attempts exited before ADB because only 6.1-6.3 GiB remained in the
container writable layer. The runner now mounts the AVD directory on an
isolated run-scoped Docker volume, verifies that the emulator remains
running before waiting for ADB, and removes both the container and volume on
exit. The complete four-API matrix passed with that layout, and a post-run
check found no retained `who-need-help-android-avd-*` volumes.
- Release Android guard: a staging/release build with a non-HTTPS
`WNH_BASE_URL` failed at its dedicated preflight; the successful staging
build used the explicit temporary HTTPS origin.
- Helm lint, template rendering, server-side dry-run, rollout waits, readiness
checks, and cross-node PubSub verification passed in the local kind cluster.
- The hardened kind rollout then ran PostGIS as UID/GID 70 and Mailpit as
UID/GID 10001. Both used read-only root filesystems, dropped all Linux
capabilities, disabled privilege escalation, and used RuntimeDefault seccomp.
Both web and both worker replicas were Ready; their migration-wait init
containers also used read-only root filesystems and dropped capabilities.
The cross-node probe observed all four BEAM nodes, and live/readiness returned
`ok`/`ready`. Database counts remained `0 users / 0 help requests`.
- The final isolated Compose resilience drill observed a restart count increase
for one crashed web and worker BEAM process, replaced every replica
sequentially, observed all 5 cluster nodes, passed PubSub, and completed a
real Oban retry on attempt 2 after one recorded error. Its exact job row and
all fixture domain rows were absent afterward; all 744 readiness samples
succeeded.
- The final reproducible kind rolling drill replaced all four pod UIDs,
observed all 4 BEAM nodes, passed PubSub, and left the database-count diff
empty. All 363 readiness samples ultimately returned 200; two samples needed
one reconnect attempt each during local single-node NodePort endpoint
replacement.
- The final local observability drill matched all 3 web and 2 worker
Prometheus instance targets, checked the provisioned Grafana datasource and
ten-panel dashboard, received firing and resolved Alertmanager webhooks for
the exact stopped/recovered web replica, restored every target to `up`, and
left the application-table count diff empty. Its retained evidence contains
neither the metrics token nor the random Grafana password. Final evidence is
retained at
`output/observability/queue-worker-metrics-fixed-20260720`.
- The observability stop command changed only the four scoped monitoring
container states. All app/database/worker container IDs stayed unchanged and
running, and the checked user/request/message counts were identical before
and after. A subsequent full drill returned all monitoring services to
healthy.
- The final encrypted S3 drill restored 23 public application tables, all
10 current migrations, 14 categories, and PostGIS 3.6.4 into a fresh
temporary database. `restic check --read-data` passed before cleanup.
Flipping the first byte of an isolated cloned repository made
both `check` and `dump` exit nonzero. Stopping the exact backup container
after uploaded encrypted objects produced exit 130 and zero snapshots;
Restic identified and pruned 32.809 MiB of unreferenced packs, then passed a
second full-data check. The source database count diff was empty and no
configured secret appeared in retained evidence. The scoped MinIO project,
repository volume, and runtime directories were subsequently removed; the
evidence remains at
`output/backups-s3/final-backup-current-20260719`.
- The latest external-boundary drill passed real client-side OAuth token and
user HTTP exchanges, PKCE/state checks, provider denial, one-time-code replay,
a fresh flow after a temporary token error, and timeout failure. It also
passed SMTP acceptance, permanent rejection without retry, one retry after a
temporary greeting, timeout, and repeated submission. The push checks passed
the disabled adapter, rejection, HTTP retry, replay and ambiguous-timeout
deduplication, then created real acceptance/chat events against an ephemeral
PostGIS database. Two worker replicas processed them; acceptance completed on
attempt 1, chat completed on Oban attempt 2 after a temporary provider
failure, replay never reached HTTP, and the chat text was absent from the
payload. Every retained file is mode `0600`, no generated credential was
retained, no host port was published, and the exact project, volume, network,
and one-run images were absent after cleanup. Evidence is retained at
`output/external-boundaries/final-boundaries-20260719`.
- The committed browser suite passed its 1/1 bootstrap and all 30/30 scenarios:
10 each in Chromium, Firefox, and WebKit, against a fresh PostGIS volume with
two web and two worker replicas on 2026-07-20. The retained successful-run
artifact directory is `output/e2e/20260720042117-3279852`.
It covered axe checks across four pages and two themes, keyboard navigation,
three responsive widths, Activity/moderation/privacy, the two-user medicine
handover and blind reviews, public boundaries, local raster maps, and an
offline LiveSocket transport failure/reconnect. Each browser also recovered
active chat and tracking after its serving BEAM node stopped. It verified
persistent Russian/Ukrainian public language selection and the selected
Ukrainian locale inside an authenticated LiveView. The uniquely named
Compose volume and networks were removed.
- The default localization domain contains 508 current messages and the errors
domain contains 40. Russian and Ukrainian catalogs have no empty or fuzzy
current entries. Category names, descriptions, structured-field labels and
select/boolean values use locale maps with an English fallback; the
compatibility `description` column remains as a fallback for pre-existing
categories.
- The isolated database-scale harness migrated an empty PostgreSQL 18.4
database to the exact pre-index version, seeded the configured canonical
sample, captured JSON `EXPLAIN (ANALYZE, BUFFERS)` plans before and after the
generated cursor-index migration, and removed its project and volume. The
final 50,000-row-per-large-table run selected every asserted cursor index;
two consecutive request pages matched the first 50 ordered rows with no gap
or duplicate. Exact observations and their non-SLO limitations are recorded
in `docs/performance.md`.
- Browser verification used the required headed Chrome wrapper. The final
public homepage rendered its account/language controls, urgent-medicine hero,
help steps, Safety link, and three language choices. The browser reported
zero console errors or warnings; the document, fingerprinted CSS/JS, and logo
requests all returned HTTP 200. The browser was left open.
Local generated evidence (ignored by Git):
- `output/playwright/final-request-map-chat.png`
- `output/playwright/final-privacy-profile.png`
- `output/android/final-image-smoke.png`
- `output/android/foreground-notification.png`
- `output/android/staging-deep-link-safety.png`
- `output/android-instrumentation/20260719053610-2122819/results.txt`
- `output/e2e/20260719053436-2083768/`
Android artifact:
- `android/dist/who-need-help-debug.apk`
- SHA-256:
`4520aa0b50eaf53bb7052e7f4c096a73d456f45781380187586c79d7267c21c5`
- `android/dist-staging/who-need-help-staging.apk`
- SHA-256:
`08d990a9268a382052be5f2d3ba5afba2aa65a9ad5f9ae1ad4bff720f8999a6e`
- Observed staging manifest values: package
`org.whoneedhelp.mobile.staging`, version `0.1.0-staging`, minimum SDK 24,
target and compile SDK 37, cleartext traffic disabled, `singleTop`
`MainActivity`, and an exact HTTPS host of `whoneedhelp.imalto.site`.
- `apksigner verify` accepted the staging artifact's v2 generic debug
signature. That signing identity is only for installable staging verification
and is not a production release identity.
## Configuration finding
`WNH_DEBUG_BASE_URL` is a required Android build input, because the trusted
same-origin value is compiled into the debug APK. Its concrete local value is
read from the repository's ignored `.env` by `scripts/android-build.sh` and is
passed to Docker with `--build-arg`. `android/Dockerfile` only declares
`ARG WNH_DEBUG_BASE_URL`; it contains no URL default.
The example `http://10.0.2.2:4010` remains only as unit-test data for origin
matching. It is not a runtime or build default. The ignored `.env` is also
excluded from the root Docker build context.
## Database observations
The post-roadside local Compose observation found 2 users, 1 help request, 7
messages, and 1 assignment before and after deployment. Category seeding
changed only the category count from 1 to 9: 7 selectable categories and 2
inactive grouping nodes. These are local scenario data; the database is not
assumed empty.
The Activity migration then preserved those same user/help/message/assignment
counts, added empty `activities`, `activity_participants`, and
`activity_messages` tables, and expanded the category tree to 14 rows: 9 help
rows and 5 Activity rows. A validated custom-format dump was created immediately
before that migration at
`output/backups/compose-before-activity-20260718-203930.dump`; this ignored local
artifact is not a substitute for the still-required isolated restore drill.
The final kind observation found 0 users, 0 help requests, and 0 messages. That
state was queried before changing the database workload. The migration from the
old `emptyDir` Deployment created a custom-format dump, validated it with
`pg_restore --list`, changed PostGIS to a persistent StatefulSet, and restored
the dump before the Helm upgrade. The final kind database reported PostgreSQL
18.4 and PostGIS 3.6.4.
The local kind Secret contains independently generated values. Only their
decoded lengths were inspected: the PostgreSQL password is 64 characters and
each application secret is 128 characters. Secret values were not printed or
written to tracked files.
Before the local `auth_identities` migration, a PostgreSQL custom-format dump
was created at `output/backups/compose-20260720-203913.dump`; its SHA-256 is
`ed8d663b114f3823479198005857af5501a90dacbec3f0855296327ee9cd6d20`.
An isolated restore drill read 23 public tables, 1,488 rows, 12 applied
migrations, and PostGIS 3.6.4 from that dump, then removed the temporary
database. The source Compose database subsequently reported 13 applied
migrations and an empty `auth_identities` table before browser verification.
## Dependency-upgrade observations
- The running Compose and kind releases reported Elixir 1.20.2 and Erlang/OTP
29.
- Compose reported Traefik 3.7.8 and Mailpit 1.30.4; Compose and kind both
reported PostgreSQL 18.4 and PostGIS 3.6.4.
- The production asset build reported Tailwind CSS 4.3.3 and daisyUI 5.6.18;
esbuild is configured at 0.28.1.
- The isolated Node build stage reported Node.js 24.18.0, npm 12.0.1,
`npm outdated --json` returned `{}`, and `npm ci` reported zero known
vulnerabilities.
- The Android build used Android Gradle Plugin 9.3.0, Gradle 9.6.1, Command-line
Tools 22.0, and its embedded Android CLI 1.0.15857036. Unit tests, lint, and
debug assembly passed; the lint report says “No errors or warnings.” The
rebuilt emulator image contains the API 37 ps16k AVD and APK, and its emulator
36.6.11.0 binary returned its version successfully at runtime.
- The final complete `scripts/kind-up.sh` run was idempotent and finished with
both 2-replica Deployments Ready and a successful cross-replica PubSub probe.
The migration `20260718114233` and reverse block lookup index
`blocks_blocked_id_blocker_id_index` were present. An actual `EXPLAIN ANALYZE`
for that reverse lookup selected the index. The table contained no block rows,
so this confirms query shape, not production performance.
Exact production capacity, minimum CPU/RAM, and scaling thresholds are unknown:
there is no representative production dataset, traffic model, or
target-environment measurement. The isolated measurements in
`docs/performance.md` include the earlier paced public/readiness/heartbeat
comparison and a later 3-web/2-worker run with real authentication, LiveView,
chat writes, tracking writes, and explicit position deletion. The latter
completed 1,888 authenticated chains and 240 heartbeat sockets without a
functional failure and restored every tracked application table count after
fixture cleanup. Neither short run found a saturation point or represents
production traffic, so the Helm chart does not invent resource limits or an HPA
policy.
The 2026-07-20 memory investigation did identify and remove a development
runtime artifact: kind's nested container runtime exposed a huge `nofile`
limit, causing each OTP VM to allocate a roughly 1.5 GiB port table. Explicit
`+Q 65536` configuration reduced the entire kind container from 9.748 GiB to
1.796 GiB. A later rolling replacement retained that value in all four pods,
left the application-table count diff empty, and passed readiness and
cross-node PubSub. This fixes that specific over-allocation; it is not a
production minimum-RAM measurement. Detailed evidence and per-container values
are recorded in `docs/performance.md`.
The optional kind and load verification environments were stopped after their
final checks without deleting their containers or volumes. Immediately before
the pause, both isolated databases contained zero users, requests, and
messages; every kind pod was Ready. The stopped kind control plane had been
using 1.706 GiB, while the running load application/database/monitoring
containers used roughly another 1.6 GiB in the same observation. A complete
resume test measured the Kubernetes API Ready after 6.83 seconds, then
`kind-up.sh` reconciled the chart, rolled both 2-replica Deployments, passed
four-node PubSub and the BEAM port-limit checks, and `kind-stop.sh` paused it
again. The ordinary public Compose route remained HTTP 200 throughout.
## Public staging observation
On 2026-07-18, `whoneedhelp.imalto.site` was published through the existing
Ubuntu Nginx gateway and its OpenVPN path to the local Compose proxy. HTTP
redirected to HTTPS; the homepage, fingerprinted assets, and both health
endpoints returned HTTP 200. A headed Chrome session rendered the public page
with zero console errors or warnings. A complete WebSocket Upgrade request to
`/live/websocket` returned `101 Switching Protocols`.
The observed Let's Encrypt certificate had the correct
`DNS:whoneedhelp.imalto.site` SAN and an expiry of 2026-10-16. Nginx and the
Certbot renewal timer were active. This verifies the current staging path; it
does not make the workstation or gateway a production availability
environment.
Earlier on 2026-07-19 a read-only check resolved the origin to `77.110.101.144`;
HTTP redirected to HTTPS, and the homepage, Safety page, and readiness endpoint
returned HTTP 200 with successful TLS verification. The certificate still had
the exact SAN and the same expiry. The backing ordinary Compose project was
healthy and its four-node PubSub probe passed. It contained 2 users, 1 help
request, 7 messages, and 8 applied migrations. At that checkpoint no mutation
was performed before a validated backup/restore and explicit authorization.
The later authorized rollout is recorded below; this paragraph is historical,
not the current deployment state.
A mode-`0600` custom-format backup of that exact database was then created at
`output/backups/compose-20260719-060810.dump` with SHA-256
`726cca11f69b1aab5e7141ba5f13ebe92c7f27c6b14172891cd2e462acc069f0`.
Its checksum and `pg_restore` catalog were validated. The restore drill read 23
public tables and 1,484 rows from a uniquely named temporary database, observed
PostGIS 3.6.4, applied all 10 current migrations there, passed migration
readiness, and removed that database. A final read-only source check still
reported 8 migrations and the same user/request/message counts; the four
running application container IDs were unchanged.
The same archive then passed
`./scripts/upgrade-rehearsal-compose.sh` against application commit `af9018f`.
The isolated restored copy advanced from 8 to all 10 current migrations and
reported all 11 cursor indexes valid. Two web and two worker replicas formed a
four-node BEAM cluster, the cross-node PubSub probe passed, public requests
produced the expected production HTTPS redirects, trusted-proxy pages and both
health endpoints returned HTTP 200, and the application-table count diff was
empty. The exact project, database volume, networks, and one-run image were
absent after cleanup. Evidence is retained at
`output/upgrade-rehearsal/20260719062507-3274364`. The ordinary Compose
container IDs, 8-migration state, and user/request/message counts remained
unchanged.
After explicit approval to update the development Compose project, application
commit `143e159` was deployed on 2026-07-19. Immediately before the rollout, a
new mode-`0600` custom-format backup was created at
`output/backups/compose-20260719-093528.dump`; its SHA-256 is
`fd5f293c63972b19af9bc967ea229cc2617c17ad32d5fcd695f2dafafef4d790`.
The archive passed the isolated restore drill before any source-database
migration.
The ordinary Compose migration job then advanced the source database from 8 to
all 10 current migrations and started two web and two worker replicas from
image
`sha256:6685247b8e872ade5e36f2b9e88bfca09b1606823ffb3e4f1469fbcfdc15d48c`.
The complete before/after application-table snapshot had an empty diff,
including the existing 2 users, 1 request, 7 messages, 1 assignment, and 4
ended tracking sessions. Post-rollout catalog checks found the localized
category-description column and all 11 valid cursor indexes. Local live and
readiness checks, the four-node cluster/PubSub probe, public home, Safety,
live/readiness, TLS verification, and a WebSocket Upgrade all passed. The
checked web/worker log window contained no application error, warning,
exception, deadlock, or HTTP 5xx match.
Headed Chrome then rendered the updated Safety page in English and Russian,
redirected the protected Requests route to the Russian login form with the
expected authorization notice, and reported zero console errors or warnings.
The visible browser was deliberately left open. Mode-`0600` rollout evidence
is retained under
`output/staging-rollout/20260719093528-3223196/`; the browser screenshot is
retained under ignored `.playwright-cli/`.
After the Activity rollout, headed Chrome rendered the updated public
navigation, followed the Activity link to the authenticated route, and received
the expected login redirect and flash with zero console errors or warnings.
After commit `307794c`, staging was rebuilt with the optional GitHub OAuth
boundary. Both web and both worker replicas started, the cross-node PubSub probe
passed, public home/readiness returned HTTP 200, and the before/after database
counts remained `2 users / 1 request / 7 messages / 14 categories / 1
assignment / 0 activities / 0 reports / 0 social identities`.
A headed Chrome E2E run then registered a uniquely named `example.invalid`
account, consumed its confirmation link from local Mailpit, authenticated,
opened `/profile`, and observed:
- the GitHub network option and the explicit provider-disabled explanation;
- no Verify button while both OAuth environment variables were absent;
- a manually added Telegram link labelled `unverified`;
- removal of that owner-controlled manual link;
- a direct `/auth/social/github` request returning to the profile with the
controlled `provider is not configured` flash;
- zero browser console errors or warnings.
The exact E2E user was checked for every foreign-key relationship to `users`.
It had only its one authentication token and no domain records after the manual
link was removed. That exact user was then deleted through Ecto, its browser
session became invalid, the generated Mailpit message was deleted individually,
and the original database counts were observed again. The browser windows were
left open.
Local ignored browser evidence:
- `.playwright-cli/page-2026-07-18T18-09-44-303Z.png`
## Public Android and cross-client observation
The public-staging APK was built with the explicit ignored `.env`
`WNH_BASE_URL`, installed on the API 37 emulator, and connected to
`https://whoneedhelp.imalto.site`. Android package inspection found the exact
configured HTTPS authority and no filter for `attacker.example`. Because the
manifest intentionally does not claim App Link verification, a normal same-host
implicit `ACTION_VIEW` may show Android's resolver. Selecting the application
opened its native `MainActivity`; both `/` and `/safety` loaded from the public
origin with no observed WebView load or TLS errors. The external origin
resolved to the browser rather than the app.
The manifest intentionally sets `android:autoVerify="false"`: this is a
same-origin HTTPS deep link, not a claimed verified Android App Link. Enabling
verification requires the final production application ID and signing
certificate fingerprint to be published in the deployment's
`/.well-known/assetlinks.json`.
A cross-client scenario then used headed Chrome as the requester and the
public-staging Android app as the helper. The observed behavior was:
- the Android app authenticated against the public HTTPS origin and rendered
the MapLibre request;
- chat messages travelled in both directions, including an Android-bound
browser message appearing without reload;
- Android granted foreground location permissions, started
`TrackingService`, and showed its persistent Stop notification;
- after Home minimized the Activity, an emulator location change from
`50.46009833, 30.5334` to `50.4611, 30.5344` reached PostGIS and produced
`121.97` metres of observed movement;
- the headed browser received the helper marker in real time and removed it
when tracking stopped;
- notification Stop removed the Android service and notification, ended the
exact tracking session, left zero active sessions, and deleted its raw current
position.
The final reproducible cross-client runner performed the same boundary through
the staging instrumentation APK and containerized Chromium. Android consumed a
run-scoped one-time login token, chat messages crossed in both directions
without reload, Android foreground tracking produced a live marker in the
browser, and stopping it removed the marker. The fixture verifier found exactly
the two expected messages, one ended tracking session, and no raw current
position. Cleanup removed only the UUIDs recorded in the run manifest; the
before/after count diff across 19 application tables was empty. Browser,
instrumentation, fixture verification, and cleanup all passed. Evidence is
`output/android-browser-staging-e2e/20260720053109-872921`.
The browser scenario exposed one UI defect: movement evidence was persisted and
the marker updated, but the evidence badge remained stale until reload. The
tracking PubSub event now carries the already-derived movement/proximity
timestamps, and the LiveView updates its in-memory assignment from that same
event without an extra query. Domain and two-client LiveView regression tests
assert the event and badge change.
That fix was deployed with image digest
`sha256:1b991c1e07d98babb5151c010250cd0b9458195cf3de5a91972456ee72d75673`.
Both web and both worker containers used the digest, the cross-node PubSub probe
passed, local and public readiness returned HTTP 200, and no application
error/warning was found in the checked post-rollout logs. The before/after
database counts remained `2 users / 1 matched request / 7 messages / 14
categories / 1 assignment / 4 ended tracking sessions / 0 active tracking
sessions / 0 activities / 0 reports / 0 social identities`.
The exact temporary E2E users, tokens, request, assignment, messages, tracking
session, and audit records were removed in one scoped transaction. Queries by
their exact identifiers found no remaining rows and the original database
counts were restored. The headed browser windows and emulator were left open.
## Operations and metrics verification
On 2026-07-18, the Compose database was archived with PostgreSQL 18
custom-format `pg_dump`. The published archive and SHA-256 sidecar were
validated before an isolated restore. The restore drill created a database from
`template0`, restored with `pg_restore --exit-on-error`, read 23 public
application tables and 1106 restored rows, reported PostGIS 3.6.4, observed all
8 current migrations, and removed the exact temporary database. A follow-up
catalog query returned zero remaining restore-drill databases. Source counts
before and after remained `2 users / 1 help request / 7 messages / 14 categories
/ 1 assignment / 0 activities / 0 reports / 0 social identities`.
The same rollout started 2 healthy web replicas and 2 worker replicas. Local
live/readiness, public HTTPS readiness, and the public root returned HTTP 200.
The cross-node PubSub probe passed across all four connected BEAM nodes. The
protected metrics route returned HTTP 401 both locally and through public HTTPS
without credentials, returned valid Prometheus text with the generated ignored
local token, and was scraped directly from each web container. Helm 4.2.3 lint
and template rendering passed.
Before the runtime image change, every BEAM container logged that
`libsctp.so.1` was unavailable. The rebuilt Debian trixie release contains the
`libsctp1` package and the exact shared library; no SCTP, application error, or
application warning appeared in the post-rollout web/worker logs checked during
this verification window.
## Final full-stack regression
The broad pre-production regression below tested application commit `c6aa3d1`.
The later responsive-header follow-up at `768d63a` was separately subjected to
the complete quality and browser suites, deployed, and verified as recorded
after this section.
- `./scripts/quality.sh` passed the complete static, formatting, compiler,
xref, Credo, Sobelow, Dialyzer, dependency-audit, manifest, secret, and image
gates. ExUnit reported 172 passed. The final log is
`output/regression/final-20260719/quality-current.log`.
- The isolated browser project passed its bootstrap 1/1 and 27/27 scenarios:
9 in each of Chromium, Firefox, and WebKit, with no skipped, flaky, or
unexpected result. The suite includes accessibility, responsive navigation,
medicine handover, blind reviews, Activity privacy/moderation, localization,
reconnect, and active chat/tracking recovery after the serving BEAM node
stops. Evidence is `output/e2e/20260719162432-2790071`.
- Android debug and staging unit/lint/build gates passed. Seven instrumentation
tests passed independently on API 30, 34, and 37, including foreground
tracking surviving Home plus Activity destruction and native Retry recovery
after a forced main-frame disconnect. The separate API 37 public-staging
smoke asserted the home and Safety DOM over the exact temporary HTTPS origin,
matched no external-origin app filter, and observed zero load/TLS errors.
- A real public Chromium two-user scenario registered isolated requester/helper
fixtures, completed medicine discovery, acceptance, realtime chat, consent
tracking, handover, both confirmations, and blind reviews. It passed 1/1 in
12.8 seconds. Exact fixture cleanup removed its users and domain rows; the
before/after public database diff was empty. Evidence is
`output/staging-e2e/20260719170530-3787963`.
- The 600.5-second authenticated soak completed 271,072 iterations and 767,225
HTTP requests with zero failed HTTP requests. All 703,995 public checks
passed; expected-response latency was 2.337 ms average, 5.705 ms p95, and
175.955 ms maximum in this local run. Eight authenticated sessions completed
31,607 request-page/LiveView/chat/tracking start-update-stop chains and 4,800
heartbeat WebSockets without an authenticated or WebSocket error. The
database observed zero rollbacks, deadlocks, conflicts, or temporary files
during the measured interval. Exact fixture cleanup restored every tracked
table count. These are observations, not production SLOs or capacity limits;
evidence is `output/performance/authenticated-soak-10m-20260719`.
- The final isolated Compose failure/replacement drill used 3 web and 2 worker
replicas. All five nodes rejoined, PubSub passed, 744/744 readiness samples
succeeded, and the injected Oban job completed on attempt 2 after exactly one
recorded error. Evidence is
`output/resilience/final-resilience-current-20260719`.
- The final project-owned kind rolling drill replaced all four web/worker pod
UIDs, left all four replacements Ready with zero restarts, passed PubSub and
an empty database diff, and completed 363/363 readiness samples; two needed
one retry during the local single-node endpoint change. The current retained
kind release is Helm revision 13 with 2/2 web, 2/2 worker, and PostGIS 1/1
Ready. Evidence is `output/resilience/final-kind-current-20260719`.
- Prometheus matched all three direct web targets before and after the scoped
failure; Grafana provisioning passed; Alertmanager delivered both firing and
resolved webhooks for `who_need_help_load-web-19`; the database diff was
empty. Evidence is
`output/observability/final-observability-current-20260719`.
- Restic/MinIO passed encrypted streaming backup, full-data repository check,
fresh-database restore, corrupted-repository fail-closed checks, and
interruption after uploaded objects with zero published snapshots. The
source database diff was empty. Evidence is
`output/backups-s3/final-backup-current-20260719`; the one-run MinIO project
and volume were removed after the drill.
- The database-scale harness used 50,000 configured rows per large table,
captured 16 before/after plans, selected every asserted cursor index, and
verified consecutive request pages without a gap or duplicate. The exact
observations and limits are in
`output/db-scale/20260719164620-3314314` and `docs/performance.md`.
- OAuth, SMTP, and HTTP-push boundaries passed success, rejection, timeout,
retry, replay, and deduplication checks against local internal-only
counterparts. Product acceptance and chat events produced durable jobs
consumed by two worker replicas; message content was excluded from push.
GitHub OAuth remains optional and disabled without credentials. Evidence is
`output/external-boundaries/final-boundaries-20260719`.
- A clean tracked-archive deployment at `c6aa3d1` applied all 10 migrations,
repeated migration idempotently, seeded 14 categories without duplication,
started 2 web and 2 worker replicas, passed HTTP/Mailpit/cluster/PubSub, and
left its project, image, volume, and extracted workspace absent after
cleanup. Evidence is
`output/portability/20260719171321-3973031-61769f`.
- The ordinary public Compose database was backed up to mode-`0600`
`output/backups/compose-20260719-165722.dump` with SHA-256
`5b4d8a78665c5d47863af8e1e885684b110d94c278474e37c8465e0814f7000f`.
The archive passed catalog validation and an isolated restore before rollout.
The current public image ID is
`sha256:009f6754fb57a410f16252205bbfa1467a08b82a733de59c3c80e431afa8fc42`
on 2 healthy web and 2 running worker replicas. The deployment diff was
empty; the final read-only observation remains 2 users, 1 request, 7
messages, 4 ended tracking sessions, and 10 migrations.
- After the workstation restart, the development route initially timed out
because its existing OpenVPN connection was down. Read-only inspection
confirmed the gateway Nginx site still targeted the assigned client address
`10.8.0.14:4010`, while the workstation had no tunnel interface. The exact
NetworkManager profile was `openvpn__toha_nobara_pc`; its observed historical
lease was the same `10.8.0.14`.
- The profile emitted OpenVPN's warning that no server-certificate verification
method was enabled. After checking the installed NetworkManager,
NetworkManager-openvpn, and OpenVPN versions and the OpenVPN 2.7 manual, the
local profile was changed to require `remote-cert-tls=server`. Reactivation
restored `tun0` at `10.8.0.14`; the subsequent journal showed the expected
server peer and completed initialization without the certificate-verification
warning. The remaining `persist-key` and legacy cipher notices were recorded
but not changed without a separate compatibility review.
- The gateway could then reach `http://10.8.0.14:4010/healthz/ready`, and both
the public development readiness endpoint and homepage returned HTTPS 200.
The online Android App Links verifier also passed for the staging package,
staging signing certificate, and `https://whoneedhelp.imalto.site` statement.
No Nginx, test, production, Devpost, remote Git, or deployed application
configuration was changed by this recovery.
- Scoped cleanup left zero containers, volumes, and networks for the
`who_need_help_load` project and removed its ignored observability/backup-S3
runtime directories. The reusable ordinary public Compose project and the
project-owned kind cluster intentionally remain running.
## Responsive-header follow-up
Commit `768d63a` replaced the duplicated public navigation bars with one
responsive application header. At widths below 1280 px it exposes the primary
links, language selection, theme controls, and authentication actions through a
single native `details` menu; wider layouts show the same actions inline.
- `./scripts/quality.sh` passed after the change, including 172 ExUnit tests,
formatting, compiler, xref, Credo, Sobelow, Dialyzer, dependency audits,
Compose/Helm validation, and gated image scans. Evidence is
`output/regression/header-unification-quality-20260719.log`.
- The isolated browser project passed bootstrap 1/1 and 27/27 scenarios across
Chromium, Firefox, and WebKit. Its responsive accessibility case exercised
widths 360, 768, 1030, and 1440 px, asserted a single header and primary
navigation, and detected no horizontal overflow. Evidence is
`output/e2e/20260719174824-537439`.
- Before the public Compose rollout, the database was backed up to mode-`0600`
`output/backups/compose-before-header-20260719-175353.dump` with SHA-256
`fea893340d2428a61ebed8abb83816a6273b1afeb5d794763b00c81a37d15e2d`.
The archive passed an isolated restore with 23 readable public tables, 1,488
rows, all 10 migrations, and PostGIS 3.6.4 before the temporary restore
database was removed.
- The deployed image ID is
`sha256:8c3790e6b5fdd3f1feb08165d33d5b2ddaa9089b6606da44a804c5facd4765f6`
on 2 healthy web and 2 running worker replicas. The before/after database
snapshots were byte-identical: 2 users, 1 request, 7 messages, 4 tracking
sessions, and 10 migrations.
- Public HTTPS and `/healthz/ready` returned HTTP 200. The four BEAM replicas
were connected and the deployment's cross-node PubSub check passed. Headed
Chrome then verified the public page at 1030 and 360 px: one visible header,
accessible menu contents, no horizontal overflow, and zero console errors or
warnings. The visible browser was left open at 1030 px with the menu closed.
## Brand icon follow-up
Commit `c28c9a3` replaced the placeholder Phoenix mark with the selected
Who Need Help symbol. The symbol remains image-only while the header name stays
as accessible HTML text.
- One source SVG reproducibly generates 48 px browser fallback, PWA 192/512,
maskable 512/1024, Apple touch 180, Apple-ready 1024, Google Play 512, and
legacy Android density assets through `scripts/generate-brand-assets.sh`.
The Google Play file is 512×512, 8-bit RGBA PNG, and 27,107 bytes.
- The PWA manifest separates `any`, `maskable`, and `monochrome` purposes.
Android API 26+ uses foreground/background adaptive layers, API 33+ adds a
monochrome layer, and API 24/25 retain generated density resources. The
notification small icon is now a dedicated monochrome vector rather than the
launcher artwork.
- The pinned Android SDK 37 Docker build passed JVM unit tests, `lintDebug`,
`assembleDebug`, and `assembleDebugAndroidTest`. The exported debug APK and
lint report are under `android/dist/`.
- `./scripts/quality.sh` passed with 173 ExUnit tests and every static,
dependency, security, manifest, and image gate. Evidence is
`output/regression/brand-assets-quality-20260719.log`.
- The isolated responsive/accessibility browser suite passed 6/6 across
Chromium, Firefox, and WebKit. Evidence is
`output/e2e/20260719193958-2786366`.
- Before rollout, mode-`0600`
`output/backups/compose-before-brand-20260719-194155.dump` was created with
SHA-256
`9be1197a02783b959e2eee783c6d74b4bf2a65a581c6a4566f0e815c7465ea61`.
Its isolated restore retained 24 public tables, the observed domain counts,
all 10 migrations, and PostGIS 3.6.4; the temporary database was removed.
- Public image ID
`sha256:8db2281f2cf51b787fc22d99f2911ee870c9ee66a0ae6e9b801796ab1aff605f`
runs on 2 healthy web and 2 running worker replicas. The before/after
database snapshots are byte-identical and cross-node PubSub passed.
- Every public brand URL, the manifest, service worker, homepage, and readiness
endpoint returned HTTP 200. Public and repository SVG SHA-256 values matched.
Headed Chrome showed the new 36×36 header mark at 1030 px with no overflow or
console messages. Service worker `v2` activated and removed the old `v1`
cache. Evidence is `output/brand/public-header-1030-20260719.png`.
## Current public functional replay
The committed two-user medicine scenario now includes browser geolocation in
the primary path rather than relying only on the separate failure-recovery
scenario.
- Against `https://whoneedhelp.imalto.site`, the current public release passed
request creation, helper acceptance, two-way realtime chat, explicit
geolocation consent, appearance of the helper's live marker in the
requester's browser, explicit tracking stop and marker deletion, the
one-time handover code, both completion confirmations, and double-blind
review reveal. The Chromium scenario passed 1/1 in 14.7 seconds. Exact
cleanup removed its two users, request, assignment, messages, reviews,
tracking session, abuse signals, and audit events; the before/after
application-table count diff was empty. Evidence is
`output/staging-e2e/20260719202129-3641894`.
- The complete browser suite with that expanded primary path passed 27/27:
9 scenarios each in Chromium, Firefox, and WebKit against a fresh isolated
2-web/2-worker Compose cluster. The independent active-node-failure path also
verified tracking and chat recovery after the serving BEAM node restarted.
Evidence is `output/e2e/20260719202632-3770163`; its containers, networks,
and database volume were removed by the run-scoped cleanup.
The broader public-staging replay was then expanded without reusing or deleting
unrelated application records:
- One run against `https://whoneedhelp.imalto.site` passed 3/3 Chromium
scenarios covering registration, email confirmation, password setup, email
change and re-login; medicine request, helper acceptance, private realtime
chat, browser geolocation sharing and deletion, handover confirmation and
double-blind reviews; motorcycle broken-chain roadside help with helper
withdrawal and requester cancellation; Activity creation, join approval,
approved group chat, reporting, evidence, blocking/unblocking, privacy
defaults, social-link add/remove, category proposal and moderator actions.
- The fixture tool first verified the exact database name and an unused
run-specific email prefix. Cleanup validated ownership of every related
request, assignment, activity, participant, message, report, proposal,
review, tracking, audit and push-job record before deleting it. It removed
only the six observed run users and their validated relationships. Exact
Mailpit message IDs for the run were deleted separately and their absence was
rechecked. The before/after counts across 19 application tables produced an
empty diff. Evidence is
`output/staging-full-e2e/20260719210733-461538`.
- The current isolated browser matrix passed bootstrap 1/1 and application
scenarios 30/30: 10 each in Chromium, Firefox and WebKit. It includes active
BEAM-node failure while chat and browser tracking are in use, followed by
reconnect on an available replica and continued chat/tracking operation.
Evidence is `output/e2e/20260719211815-708067`; the isolated containers,
networks and PostgreSQL volume were removed automatically.
- `./scripts/quality.sh` passed on the same source state: formatting, strict
compilation, xref, Credo, Sobelow, Dialyzer, 173 ExUnit tests, dependency
audits, Compose/Helm/observability checks and the configured image scans.
Evidence is
`output/regression/full-public-web-quality-20260719.log`.
## Final Android and operational replay
Application commit `b96d443` and its exact source state were subjected to the
following additional local and temporary-origin checks:
- `./scripts/quality.sh` passed all configured source, Compose, Helm,
observability, dependency, release-image, and security gates with 174/174
ExUnit tests. Evidence is
`output/regression/android-cross-quality-20260720.log`.
- Android debug and staging unit/lint/APK builds passed. The isolated API
30/34/37 matrix passed 7/7 device tests per API. Public API 37 DOM smoke
passed 1/1. The Android/browser staging run passed Android magic-link login,
private chat in both directions, foreground tracking, browser marker
appearance/removal, fixture verification, and an empty 19-table cleanup
diff. Evidence is
`output/android-browser-staging-e2e/20260720053109-872921`.
- The external-boundary drill passed OAuth, SMTP, provider-neutral HTTP push,
product job integration, retry, rejection, timeout, replay, and
deduplication paths with two isolated workers. Its one-run project, volume,
images, network, and generated secrets were removed. Evidence is
`output/external-boundaries/final-boundaries-20260720`.
- The isolated 3-web/2-worker Compose failure drill crashed one web and one
worker BEAM process, sequentially replaced every replica, rejoined all five
nodes, passed PubSub, and completed the injected Oban job on attempt 2 after
one recorded failure. All 725 readiness samples succeeded and the exact job
was deleted. Evidence is
`output/resilience/final-resilience-20260720`.
- The 30-second, 88-VU load replay completed 13,765 iterations and 38,826 HTTP
requests. All 35,280 checks passed; HTTP failures were 0. It completed 1,765
authenticated LiveView page/chat/tracking start-update-stop chains and 240
heartbeat sockets without a functional error. PostgreSQL observed zero
rollbacks, deadlocks, conflicts, or temporary files. Exact fixture cleanup
produced an empty application-table diff. Evidence is
`output/performance/final-after-queue-20260720`.
- Prometheus exactly matched and scraped all three web targets before and after
the induced replica stop. Grafana's provisioned Prometheus datasource
returned `OK`; Alertmanager delivered firing and resolved webhooks for the
scoped instance. The database count diff was empty. Evidence is
`output/observability/final-observability-20260720`.
- Restic created and checked an encrypted local S3 snapshot, restored it into a
fresh database, rejected a corrupted repository, and published no snapshot
for an interrupted upload. The interrupted repository passed checking after
pruning unreferenced data; the source database diff was empty. Evidence is
`output/backups-s3/final-backup-20260720`.
- The 50,000-row database replay selected every asserted cursor index and
retained the same generated table counts before and after the index
migration. Its isolated project, volume, and image were removed. Evidence is
`output/db-scale/20260719233526-97476`.
- A clean deployment from `git archive b96d443` generated independent secrets,
applied all 10 migrations, repeated migration without changing its 10
migration or 14 category counts, and passed HTTP, Mailpit, four-node cluster,
and PubSub checks on 2 web/2 worker replicas. Its workspace, image, project,
volumes, and networks were absent after cleanup. Evidence is
`output/portability/20260719233712-142771-ac1883`.
- The project-owned kind cluster was rebuilt with the current image. The final
rolling drill replaced all four application pod UIDs with four Ready,
zero-restart pods, rejoined all four BEAM nodes, passed PubSub, and left an
empty database diff. All 395 readiness samples ultimately succeeded; two
used one transport retry during the local single-node NodePort endpoint
replacement. Evidence is
`output/resilience/final-kind-rollout-fixed-20260720`.
The first 2026-07-20 kind attempt exposed a race in the verification harness:
one label-based `kubectl wait` invocation retained a terminating pod in its
initial resource set. The harness now waits for old UIDs to disappear, captures
the exact four replacement pod names, and waits for those resources. The fixed
full replay above passed.
## Final public and browser replay after one-time-link hardening
The final public replay exposed a transport edge case specific to one-time
confirmation links: the server had committed the email change and consumed the
token before Chromium reported `ERR_NETWORK_CHANGED`, while the generic
navigation helper then replayed the already-consumed URL. The browser harness
now opens one-time links at most once. If that single navigation loses its
response to a transient transport reset, it verifies the committed account
state through the idempotent settings page instead of replaying the token.
- The complete public Chromium replay passed 3/3 against
`https://whoneedhelp.imalto.site`: registration and email/password changes;
medicine request, helper matching, two-way chat, browser location tracking,
marker deletion, handover and blind reviews; Activities, privacy, social
links, blocks, reports, category voting and moderation. Its cleanup restored
all 19 recorded application-table counts byte-for-byte and removed the
run-specific Mailpit messages. Evidence is
`output/staging-full-e2e/20260720042807-3462613`.
- The fresh isolated browser matrix passed bootstrap 1/1 and 30/30 application
scenarios, 10 each in Chromium, Firefox and WebKit, including realtime
recovery after the serving BEAM node was restarted. The run-scoped
containers, networks and PostgreSQL volume were removed. Evidence is
`output/e2e/20260720042117-3279852`.
- The public HTTPS PWA replay passed 1/1, covering manifest and install assets,
service-worker cache update, offline public fallback, and exclusion of
private application pages from the offline cache. Evidence is
`output/staging-pwa-e2e/20260719235520-665802`.
- `./scripts/quality.sh` passed again on the same source state with 174/174
ExUnit tests and all configured source, dependency, Compose, Helm,
observability and container-image security gates. Evidence is
`output/regression/final-single-use-quality-20260720.log`.
## Queue and ingress-policy hardening replay
The 2026-07-20 hardening pass removed the unused Oban `default` consumer and
made the two real queue limits explicit in Compose, generated local
environments, and Helm. After rebuilding the isolated load release, both
worker nodes reported exactly `maintenance: [limit: 2]` and
`push: [limit: 1]`; the five-node cluster and cross-node PubSub probe passed.
The explicit 1,000-job burst completed 1,000/1,000 jobs in the observed 4,516
ms, produced no matched application/database error, removed exactly its 1,000
run-scoped rows, left zero probe jobs, and retained identical domain-table
counts. Evidence is
`output/performance/oban-burst-1000-final-20260720`.
The Helm chart now renders one ingress NetworkPolicy for the chart instance.
Helm lint and the rendered-manifest Trivy scan pass. The manifest permits
chart-instance pod-to-pod Erlang distribution and the configured HTTP
listener while isolating other inbound pod ports. Actual packet enforcement
has not been claimed because it depends on the target cluster's CNI; that must
be verified on the eventual deployment environment.
The same source state passed `scripts/quality.sh`: 186/186 ExUnit tests,
format and warnings-as-errors compilation, xref, Credo, Sobelow, Dialyzer,
Hex/npm audits, ShellCheck, Hadolint, actionlint, every Compose render, Helm
lint, observability configuration, rendered-manifest scanning, and all
configured runtime image scans. Every reported HIGH/CRITICAL vulnerability
count was zero.
## Final pre-production audit replay on 2026-07-20
The final manual code pass fixed LiveView form metadata leaking into dynamic
category data, stale review state across replicas, forms retaining submitted
report/proposal/chat content, an invalid leave action on completed activities,
and blocked-organizer metadata remaining visible in a participant's activity
history. Regression coverage now includes all of those cases.
- `./scripts/quality.sh` passed on the final source state with 243/243 ExUnit
tests, format and warnings-as-errors compilation, xref, Credo, Sobelow,
Dialyzer, Hex/npm audits, Compose and Helm rendering, observability
validation, source secret/misconfiguration scanning, and every configured
production and infrastructure image scan. The reported configured-threshold
vulnerability count was zero.
- The final isolated 50,000-row database replay measured public help discovery
at 0.144 ms and the blocked participant-activity page at 22.837 ms for 25
returned rows on this workstation. The aggregate leaderboard and helper
reputation queries measured 45.006 ms and 38.443 ms respectively. These are
observations, not production resource requirements. Evidence is
`output/db-scale/20260720154617-630777`.
- The 30-second isolated load run used 3 web and 2 worker replicas. It completed
38,936 HTTP requests and 2,060 WebSocket sessions with zero HTTP failures;
overall HTTP p95 was 5.321 ms. It also completed 1,820 authenticated
LiveView/chat/tracking cycles. Peak sampled container memory was 296-324 MB
per web replica, 205-219 MB per worker, 121 MB for PostgreSQL, and about
1.54 GiB when summing the seven measured runtime-container maxima. Database
sampling observed no deadlocks, lock waits, temporary files, or rollbacks
during the run. Evidence is
`output/performance/final-current-20260720`.
- The subsequent replacement drill recorded 650/650 successful readiness
samples, a five-node BEAM cluster, cross-node PubSub, healthy web/worker
recovery, and an Oban probe completing on attempt 2 after its intentional
first failure. Evidence is
`output/resilience/final-current-resilience-20260720`.
- A visible-browser replay on `https://whoneedhelp.imalto.site` covered
registration and magic login, account/profile/privacy controls, social-link
semantics, medicine request creation and matching, private realtime chat,
optional live tracking UI and cleanup, handover, double confirmation,
double-blind reviews, activity creation/join approval/exact-location privacy,
group chat and completion, reports/moderation/audit evidence, category
proposal/voting/moderation, and blocking in both directions. The final fresh
post-deployment tab reported zero console errors and zero warnings.
- The first public automation replay exposed two verification defects after the
UI fixes: duplicate valid review status text made a broad locator ambiguous,
and a committed password change lost only its redirect GET to
`ERR_NETWORK_CHANGED`. Commit `9463009` scopes the review assertion to the
persistent status and submits the password mutation only once before
recovering through an idempotent settings GET. The clean replay passed 3/3.
Evidence is `output/staging-full-e2e/20260720160445-1004343`.
- The final HTTPS PWA replay passed 1/1, Android/browser chat and tracking
passed twice, and the packaged native staging APK passed its Android 37
public-origin smoke. Evidence is
`output/staging-pwa-e2e/20260720160533-1019120`,
`output/android-browser-staging-e2e/20260720160544-1022997`, and
`output/android-staging-smoke/20260720160743-1061722`.
The manually created browser-audit user, request, assignment, activity,
messages, tracking session, reviews, reports, category proposals, vote, abuse
signals, audit events, and Mailpit messages were removed by exact identifiers.
The existing helper account was restored to role `user`, no password, and no
blocks. Post-cleanup counts retained two users plus one unrelated request and
assignment; those unrelated rows were not changed.
## Production-handoff replay on 2026-07-20
Commit `14987bb` adds a first-deployment Compose path without inventing the
unknown server topology. `scripts/init-production-env.sh` generated independent
database, Phoenix, handover, BEAM-cookie and metrics values without printing
them, wrote mode `0600`, and refused to overwrite its destination.
`scripts/validate-production-env.sh` accepted the fully supplied fixture and
rejected the unresolved proxy/SMTP fixture. The configurable
`HTTP_BIND_ADDRESS` rendered as both `0.0.0.0` and `127.0.0.1`.
`compose.production.yaml` kept Mailpit inactive unless its explicit local
profile was enabled.
- The complete isolated quality/security gate passed after these changes:
244/244 ExUnit tests, format and warnings-as-errors compilation, xref, Credo,
Sobelow, Dialyzer, Hex/npm audits, ShellCheck, actionlint, all Compose/Helm
renders, observability validation, tracked-source secret/misconfiguration
scanning, and all configured production/infrastructure image scans. The
configured-threshold vulnerability count was zero.
- The deployed Compose stack applied all 12 migrations and reported two
healthy web plus two healthy worker replicas. A repeated cluster probe
observed all four BEAM nodes and passed cross-node PubSub. Fresh cgroup
observations were approximately 210-221 MB per application replica; this is
not a future server minimum or capacity promise.
- Public HTTPS returned ready/live success, HSTS, secure HttpOnly SameSite
cookies and the expected security headers. The scheme-specific CSP contained
`wss://whoneedhelp.imalto.site` and no plaintext WebSocket origin.
- A headed Chrome registration used a unique run-scoped address, received its
confirmation message in Mailpit, required explicit confirmation, and created
an authenticated session. The profile exposed location-visibility choices,
manually added unverified social-link semantics, reputation, blocks and an
optional external thank-you link. Sensitive settings correctly required
email reauthentication after the sudo window. The password form's browser
accessibility warning was fixed by associating its username; the fresh
deployed settings tab reported zero errors and zero warnings.
- A full public staging replay passed 3/3 registration/settings, mutual-aid and
activity/moderation scenarios. Its database cleanup diff was empty. Evidence
is `output/staging-full-e2e/20260720184356-3858682`.
- The public PWA install/cache-update/offline-fallback replay passed 1/1.
Evidence is `output/staging-pwa-e2e/20260720184450-3875584`.
- The current staging APK/test APK were rebuilt for the configured HTTPS
origin. The Android 37/browser replay passed magic login, bidirectional
realtime chat, foreground location sharing, a PostGIS-backed position and
notification Stop cleanup; it retained zero raw positions and its database
cleanup diff was empty. Evidence is
`output/android-browser-staging-e2e/20260720184520-3885007`.
- Backup `output/backups/compose-20260720-182338.dump` has SHA-256
`ac19d5dbb3c1b797269003d6b302a2ae3d8d9634be6ad31ea2468d7f5a837a3b`.
Its fresh-database restore drill found 23 public tables, 1,489 rows, all 12
migrations and PostGIS 3.6.4. The upgrade rehearsal passed with an empty
application-table diff, four cluster nodes, PubSub and HTTP; evidence is
`output/upgrade-rehearsal/20260720182353-3474703`.
The final manual registration account had no request, assignment, message,
activity, review, report, block, social-identity or tracking references. It and
its two session tokens were removed in one exact transaction; its two exact
Mailpit message IDs were also removed. Final domain counts returned to two
users, one unrelated request, one unrelated assignment and seven unrelated
messages. One PostgreSQL error in the audit window came from an incorrect
column name in a read-only operator query; PostgreSQL aborted that transaction.
The subsequent log window contained no matched error/warning entry.
## Private-Git and final boundary replay on 2026-07-20
The newly configured private `origin` and its `main` branch both resolved to
commit `378768b` before this replay. The observed server API identified Gitea
1.22.0. Because that release reads repository workflows from
`.gitea/workflows/`, a separate Gitea workflow now runs the same four local
gates sequentially on the dedicated `who-need-help-ci` label. Both the GitHub
and Gitea workflows passed pinned actionlint locally. Remote Actions enablement,
runner registration and an actual Gitea run remain unverified until a trusted
runner is provisioned.
This replay found and corrected two integration regressions that the ordinary
Phoenix suite did not cover: the external-boundary workers were missing the
new required metrics credential, and the drill's product request was missing
the new required safety acknowledgement. The repaired drill then passed OAuth,
SMTP, provider-neutral push, two Oban worker replicas, retry, replay
deduplication and product-event delivery. Its non-secret mode-`0600` evidence
is `output/external-boundaries/preprod-gitea-pass`.
- The final isolated quality/security gate passed with 244/244 ExUnit tests and
zero configured-threshold source/image findings. The Gitea runner state,
binary and local data directory are now excluded from Git and Docker build
contexts and covered by the quality script.
- The isolated Playwright suite passed all 30 scenarios across Chromium,
Firefox and WebKit, including medicine matching, chat, tracking, handover,
blind reviews, privacy, moderation, account changes and replica restart
recovery. Evidence is `output/e2e/20260720190130-1182`.
- The debug Android build passed unit tests, lint, debug APK and test APK
assembly using `.env.example`; no generated APK is tracked.
- The temporary HTTPS origin returned HTTP 200 from both `/healthz/live` and
`/healthz/ready`. The observed local Compose project had two healthy web and
two healthy worker replicas with zero restarts.
- One idle `docker stats --no-stream` snapshot measured approximately
1,040 MiB combined across the database, Docker API proxy, Mailpit, edge
proxy, two web replicas and two worker replicas. This workstation snapshot is
not a production minimum, limit or capacity claim.
## Compose topology and database-mode verification on 2026-07-21
- The current ExUnit suite passed 260/260 after adding the combined runtime
role and deployment-mode selection.
- The complete isolated quality/security gate passed: ShellCheck, Hadolint,
actionlint, all Compose mode renders and production-environment rejection
cases, Helm lint/render, tracked-source scanning, format, warnings-as-errors
compilation, xref, Credo, Sobelow, Dialyzer, Hex/npm audits, 260/260 ExUnit
tests, and every configured runtime/infrastructure image scan. The
configured HIGH/CRITICAL finding count was zero.
- A fresh isolated `compact + container` production render contained only
`db`, one-shot `migrate`, and `app`. Readiness and a local PubSub probe passed;
the running combined container reported the expected 65,536 Erlang port
limit. Its exact containers, networks, and database volume were removed.
- A separate PostgreSQL 18.4/PostGIS 3.6 fixture was published only on the
Docker bridge gateway. The `split + external` render contained migrate,
Docker API proxy, Traefik, two web replicas, and two worker replicas, and did
not contain a `db` service or database volume. The preflight reported
PostgreSQL/PostGIS versions and `TLS=false` for that local fixture, all 13
migrations applied, readiness passed, all four BEAM nodes joined, and a
cross-node PubSub broadcast passed. Its logs contained no error marker and
all run-scoped containers, networks, fixture container, and fixture volume
were removed.
- The first compact drill exposed an isolation defect: the generated
production environment lacked `COMPOSE_PROJECT_NAME`, so Compose selected
the ordinary project name and recreated its database container with the
drill's environment. Authentication failed before any migration ran and the
compact app remained in `Created`. Read-only checks still found 13
migrations, 2 users, and 1 request. Backup
`output/backups/compose-20260720-223237.dump` was created, the ordinary split
stack was recreated with its original ignored `.env`, the same counts and
HTTP readiness were rechecked, and the never-started compact container was
removed. The initializer now writes and validates an explicit project name,
and both subsequent isolated drills used distinct verified project names.
- The final ordinary development stack again reported two healthy web and two
healthy worker replicas, cross-node PubSub, local and temporary-public-origin
readiness, unchanged counts (13 migrations, 2 users, 1 request), and no
error marker in the post-rollout application/proxy log window.
These checks establish the mode wiring on this workstation. They do not prove
the future provider's TLS/CA policy, network reachability, backup service, high
availability, or target-server capacity.
## Retired UniSender Go delivery boundary observed on 2026-07-21
This section is retained only as historical evidence. The adapter, runtime
mode, environment variables, Compose wiring, Helm wiring, and deployment
instructions were removed when both public environments migrated to SMTP.
None of the observations below describe the current delivery path.
- The production server returned HTTP 200 and a successful authenticated result
from UniSender Go's `system/ping` Web API method. The API key was loaded from
the server's mode-`0600` credential fragment and was not printed.
- Direct TCP connection attempts from the same server to SMTP ports 25, 465,
and 587 timed out for UniSender Go; control attempts to other public SMTP
providers also timed out. This observation does not establish where the
filtering occurs.
- At that time, `WhoNeedHelp.Email.UnisenderGoAdapter` mapped the application's
existing Swoosh messages to the provider's HTTPS `email/send.json` contract. Six
focused tests passed for the exact request shape (including explicit
`track_read=0` and `track_links=0`) and API-key header, success, redacted
recipient rejection, structured API errors, invalid responses, and rejection
of unsupported or provider-invalid messages before network I/O.
The then-current runtime configuration and production environment validation
could select either `smtp` or `unisender_go` without requiring SMTP settings
in API mode. That selectable API path has since been removed.
- Authoritative DNS and the provider UI both showed the sending domain as
verified with DKIM active, while the delegated link domain showed configured.
A second real Web API message was accepted for one recipient with no rejected
recipients and reached Gmail's Inbox after one second. Gmail's original
message view reported SPF PASS, DKIM PASS with `d=whoneedhelp.com` and
selector `gokey`, and DMARC PASS.
- The delivered MIME still contained the provider's one-pixel
`go2_read_tracker` even though the request explicitly supplied
`track_read=0` and `track_links=0`. UniSender Go documents that honoring those
zero values, and using `skip_unsubscribe=1`, requires provider approval. A
support request covering all three permissions was sent to the official
support address from the account mailbox. Privacy-disable behavior and
unsubscribe removal remain unverified until the provider enables them and a
new delivered MIME is inspected.
## Development Android and provider isolation on 2026-07-23 and 2026-07-24
- The development checkout now owns
`org.whoneedhelp.mobile.development`, an independent mode-`0600` signing
identity outside the repository, and matching App Links values in its one
ignored mode-`0600` `.env`. The test/staging package remains
`org.whoneedhelp.mobile.staging`; production remains
`org.whoneedhelp.mobile`.
- The signed ephemeral development pipeline passed development unit tests,
Android lint, APK and instrumentation-APK assembly, package/certificate
verification, and offline App Links identity validation. The signed
production pipeline separately passed release tests, lint, R8/resource
shrinking, APK/AAB signing checks, Bundletool validation, and production App
Links identity validation.
- The API 37 development emulator smoke now passes the signed
`org.whoneedhelp.mobile.development` APK against
`https://whoneedhelp.imalto.site`. It observed the home and `/safety`
main-frame loads, asserted both DOMs, rejected an unrelated HTTPS origin,
found no load/TLS error, and captured the rendered phone screenshots.
Evidence is retained at
`output/android-development-smoke/20260723230559-2828624`. The Android 17
verifier reported the development host as `verified`; a real implicit
`/safety` intent cold-started `org.whoneedhelp.mobile.development`, while an
unrelated HTTPS origin remained assigned to Chrome. Its run-scoped
container, AVD volume, and image were all absent after cleanup.
- This replay exposed and fixed two stale checks rather than treating a build as
runtime proof. Development/staging APKs deliberately have Android debugging
disabled, so their previous smoke harness waited for a debug-only page-load
message even after WebView rendered successfully. Redacted path-only load
diagnostics are now enabled only for the signed non-production public build
types, while WebView debugging and the release build remain disabled. The
public DOM assertion was also updated from the retired hero copy to the
current `Need help nearby? Ask the community.` heading.
- The complete isolated quality/security gate passed with 353 ExUnit tests,
ShellCheck, Hadolint, actionlint, Compose/Helm validation, format/compiler,
xref, Credo, Sobelow, Dialyzer, Hex/npm audits, source scanning, and all
configured runtime image scans. Its unique Compose project, volume, and
temporary image tags were absent after cleanup.
- The development Google Web OAuth client is configured for the exact
`https://whoneedhelp.imalto.site` origin and callback, and its ID/secret are
present only in the ignored development `.env`. The current development
replicas were rebuilt with that configuration and remained healthy.
- On 2026-07-24 the same Google Cloud development project was checked through
the user's already-authorized dev-port Chrome profile. It contained only the
expected Web client before a separate Android client was created for
`org.whoneedhelp.mobile.development` and the SHA-1 of the stable development
signing certificate. A read-only return to the Clients page then showed
exactly the development Web and development Android clients. No test or
production client was changed.
- Real headed Chrome verification used only the user's existing dev-port
profile. The Google Web flow reached the exact development callback, required
one email-ownership confirmation before attaching a matching existing local
account, then completed a subsequent Google sign-in without another email.
Read-only PostgreSQL checks observed seven users and exactly one Google auth
identity, and the settings page reported the Google account as connected.
The application-generated confirmation email was observed in Gmail from the
development sender. No test or production OAuth client, sender, deployment,
database, public Git reference, or Devpost entry was changed.
- The isolated external-boundary drill passed OAuth and Google OIDC
success/rejection/replay/timeout cases, SMTP rejection/retry/timeout cases,
and provider-neutral push delivery with two healthy worker replicas. Its
product replay returned the retained notification and retained Oban delivery
job, the chat body stayed out of the remote payload, and the run-scoped
Compose project, containers, PostgreSQL volume, and images were absent after
cleanup. Evidence is retained at
`output/external-boundaries/local-boundaries-fix-20260723`.
- Firebase Android and server FCM credentials were subsequently configured in a
separate development-only Spark project and exercised as recorded in the
final 2026-07-24 audit above. No test or production provider configuration was
changed.
## Known work before a public production launch
The operator-facing sequence is maintained in
[`docs/public-launch-checklist.md`](public-launch-checklist.md). That checklist
separates repository-verifiable evidence from external provider, staffing, and
jurisdiction-specific decisions; an unchecked or unknown item is not claimed
complete.
- Production is already an independent checkout, Compose project, database,
secrets set, and public origin; it is not promoted from or coupled to the
frozen `test.whoneedhelp.com` deployment. The production web workflows and
public/mobile pages were verified on 2026-08-03 as recorded above. The
remaining external checks are the real production Google callback,
authentication-email receipt, Web Push delivery, and Play-delivered Android
paths listed in the public launch checklist.
- The final Android application ID is `org.whoneedhelp.mobile`. The application
publishes environment-specific `/.well-known/assetlinks.json`. The online
development response now agrees with
`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 every Play App Signing certificate fingerprint
alongside the existing upload fingerprint, repeat domain verification with
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
external readiness monitor passed their mechanical checks on 2026-08-03.
Key custody, retention, recovery objectives, alert ownership, and the intended
PostgreSQL availability model remain operator decisions rather than inferred
properties of those checks.
- The development Brevo SMTP transport and sender completed both an external
release-container probe and an application-generated authentication delivery
observed in Gmail. Production configuration readiness is not equivalent to
mailbox delivery; repeat the application-generated authentication flow on the
exact production origin and observe receipt before checking that launch gate.
- Exercise registration, sign-in, and settings linking against the production
Google OAuth client on its exact HTTPS callback origin. The production
configuration passes the repository readiness check, but that does not prove
the external browser callback flow.
- Development VAPID and isolated Firebase/FCM are configured. Real development
browser Web Push, emulator FCM, and physical-device FCM delivery all
completed successfully. The physical development replay also covered
foreground tracking while the native service was active and verified Stop
cleanup. Before a public mobile release, repeat browser/Android delivery
against the production origin and the Play-delivered Android build.
Unattended background location was not requested or verified. APNs and iOS
are outside the current scope.
- Google Analytics for Firebase is intentionally deferred rather than silently
enabled by the Firebase project wizard. Before enabling it, implement the
consent, privacy-notice, event allow-list, sensitive-field exclusions, and
opt-in initialization requirements recorded in
[`docs/public-launch-checklist.md`](public-launch-checklist.md). This is
separate from the existing identifier-free daily aggregate
`ProductAnalytics` counters.
- Load-test representative data and traffic, then set measured pool, resource,
autoscaling, and action-limit policies.
- Publish jurisdiction-specific emergency contacts, privacy, retention,
prohibited-items, and voluntary-payment guidance after legal review.
- The UI now has authenticated and external account-deletion/data-request
intake, contact verification, case status, an audited operator queue, an
authenticated allow-listed JSON export, and a read-only deletion preflight.
Actual erasure/anonymization remains non-executable until a legally reviewed
retention policy defines the treatment of linked safety and dispute records.
- Staff and monitor the implemented moderation/support queues and establish an
incident-response/on-call process for real users.
- If verified GitHub identity is desired, create and configure its OAuth App and
exercise the external redirect/callback. This is an optional enhancement, not
a registration or launch blocker.
- Production capacity, minimum CPU/RAM, database HA topology, and autoscaling
thresholds remain unknown until representative target-environment
measurements exist.
# 2026-08-03 release-candidate quality gate
The isolated full repository quality run completed successfully on 2026-08-03.
It covered shell, Compose, Helm, source-secret and infrastructure checks; Elixir
format, compilation with warnings as errors, Gettext catalog freshness, xref,
Credo, Sobelow, Dialyzer, Hex audit and the full ExUnit suite; pinned runtime
image smoke tests and vulnerability scans; and production release, rollback and
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.
- A read-only installed-build verifier now requires the exact expected version,
`com.android.vending` installer, a supplied Play App Signing SHA-256 identity,
verified `whoneedhelp.com` domain state, and production App Link resolution to
`MainActivity`. The physical device confirmed that Android resolves the link
to `MainActivity` when both the `DEFAULT` and `BROWSABLE` intent categories
are supplied. A regression gate rejects an incomplete category set,
sideloaded installer, upload-only certificate, unverified domain, or browser
resolution. The current sideloaded package therefore intentionally cannot
satisfy the Play-delivery gate.
- 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.
# 2026-08-09 Google Play internal-track and production-provider verification
- Google Play accepted the source-bound AAB with SHA-256
`03d39a9a08e9ca7569caccf1c7bd75e9349f7655935e7bbf23d1998cd37b3837`
as version `0.1.0 (1)`. The release named `0.1.0 internal verification` is
active only on the Internal testing track. No Closed or Production rollout
was created or started.
- Every Play App Signing identity displayed for the accepted artifact was
recorded in a mode-`0600`, ignored provider document. The production
Firebase Android app and Google OAuth clients were reconciled with all Play
SHA-1 identities while preserving the independent upload identity. A fresh
production Android client configuration contained four Android OAuth
clients and one Web OAuth client and passed the repository validator. Secret
provider material is intentionally not reproduced in this document.
- The production application was recreated with the reconciled provider
configuration while retaining its exact application image
`who-need-help:production-0ad9a5430e1a`. A subsequent read-only observation
reported zero container restarts, healthy Docker state, and the expected
`{"status":"ready"}` response both locally on the server and through the
public HTTPS endpoint. The frozen hackathon test containers remained healthy
and were not changed.
- The public Android association response contained one statement and four
unique SHA-256 signing identities. On the connected physical phone,
`scripts/verify-play-installed-android.sh` confirmed package
`org.whoneedhelp.mobile`, version `0.1.0 (1)`, installer Google Play, a member
of the recorded Play App Signing set, verified `whoneedhelp.com` domain
state, and production App Link resolution to `MainActivity`.
- The Play-delivered build completed production Google sign-in without a
secondary ownership email, opened `/requests` through the verified App Link,
registered its Android FCM device after the system notification permission
was granted, received one scoped production FCM notification, and routed a
tap to the in-app notifications inbox. The notification displayed the
privacy-safe localized title and body rather than the internal event copy.
- The exact scoped notification and its two related Oban jobs were deleted
after the delivery proof. A follow-up query found zero remaining
notifications for its unique idempotency key. This cleanup did not delete
any other notification or background job.
- The strict live production readiness replay reported all twelve capability
groups `READY`, zero blocking items, and zero local-only warnings. The
structural production environment validator also passed without printing
secrets. These checks verify configuration and the observed flows above;
they do not establish closed-test completion, public Production-track
approval, or capacity limits.
## Play-delivered physical foreground-location replay
- A run-scoped production fixture linked one synthetic requester and one
synthetic medicine-pickup request to the already authenticated physical
tester. Before starting, the phone reported both fine and coarse location
permissions denied and production reported no active tracking session for
that tester.
- The Play-delivered `0.1.0 (1)` build opened the exact request through the
verified production App Link. Starting sharing displayed the native
prominent disclosure first, then Android's foreground-location permission.
After consent, Android reported the `TrackingService` foreground service and
an ongoing `Sharing live location` notification with a `Stop sharing`
action.
- Production observed three samples and one retained current position while
the app was visible. After Home minimized the app, the same session remained
active, its ongoing notification remained present, and the observed sample
count increased to eleven. No raw coordinate was printed into verification
output or retained in this document.
- Invoking `Stop sharing` from the system notification removed both the
foreground service and ongoing notification. Production then observed one
inactive ended session with forty summary samples and zero retained raw
positions.
- With airplane mode enabled, a cold application start showed the native
offline screen and explicitly stated that private pages are not stored on
the device. Airplane mode was restored to its original disabled state; the
exact authenticated request returned without a new login. A subsequent
application force-stop and verified App Link restart also restored the
authenticated stopped state while leaving both the tracking service and
tracking notification absent.
- Cleanup removed exactly one fixture request, assignment, tracking session,
and synthetic requester. A follow-up production query found zero fixture
users and zero fixture requests while the pre-existing tester and its one
push device remained present. The frozen hackathon test deployment and the
public Git remote were not changed.
# 2026-08-09 production operations recheck
- The independent monitor host reported its timer loaded, enabled, active and
waiting. Its latest service execution exited successfully and recorded HTTP
200 with the expected readiness payload. This is an observed external probe,
not an availability SLO.
- The production checkout remained at
`0ad9a5430e1a2e23ab976999faf1280bf53bcdc1`. Both environment validators
passed without printing secrets: all twelve readiness capability groups were
`READY`, with zero blocking items and zero local-only warnings.
- Public HTTPS home, liveness, readiness, manifest and Android association
endpoints returned HTTP 200. The readiness payload was
`{"status":"ready"}`; the WebSocket handshake returned HTTP 101. The
association response named `org.whoneedhelp.mobile` and published four
SHA-256 signing identities.
- The compact application container remained healthy with zero restarts and no
OOM kill. One point-in-time sample observed 189.3 MiB container memory, 25
PIDs and 0.32% CPU. The host reported 1,224,523,776 bytes available memory
and 108,116,156,416 bytes available on `/`. These are observations, not
minimum requirements or capacity limits.
- The only six warning matches in the preceding hour were module-redefinition
warnings caused by the run-scoped physical verification RPC. No error,
exception, stacktrace or crash term matched in the same log interval.
- The local encrypted off-site backup timer was loaded, enabled, active and
waiting. Its latest service execution exited successfully after creating
Restic snapshot
`869e3e3a7444d726daef7e9afbdcc9ee082962a6121ec2e29c942600396fd13c`.
Restic checked all 8 snapshots and 16 packs with no errors; the isolated
restore drill observed 34 application tables, 24 schema migrations,
PostgreSQL 18.4 and PostGIS 3.6.4. Evidence is retained at
`output/production-operations/20260808T210010Z-2802200/` with directory mode
0700 and file modes 0600.
- The retained production browser replay for this exact source revision passed
both two-user flows in 52.3 seconds. Readiness was healthy before and after,
every tracked product-table count matched its pre-run value, and the fixture
prefix count was zero after cleanup. Evidence remains at
`output/production-full-e2e/production-e2e-20260808-0ad9a54/`.
- A recoverability audit found that the healthy shared edge container used the
immutable image ID
`sha256:e450c305cc0a729406392dad5064f835a6f05ef45b787519023e12c8d65cadd2`,
while the production environment referenced a removed tag for the same edge
build. The missing tag `who-need-help:caddy-production-921e04b36080` was
restored to that exact running image ID. Compose configuration then passed;
edge, test application and test database start timestamps were unchanged,
and both production and frozen-test readiness remained HTTP 200.
# 2026-08-09 local aggregate-delivery monitoring quality run
- Local revision `e779188` added privacy-bounded aggregate SMTP delivery
counters and an authenticated external Prometheus scrape. The exported email
counters are tagged only with the bounded result `ok` or `error`; recipient,
message, request, and account identifiers are not metric labels.
- The external monitor keeps a per-node counter baseline and alerts only when
HTTP exceptions, bounded Oban queue failures, SMTP delivery errors, or SMTP
exceptions increase. The first observation and a counter reset establish a
new baseline instead of creating a false incident. A readiness or metrics
scrape failure changes monitor health and produces only transition alerts.
- The Python monitor suite passed all seven parser/baseline/reset/transition
tests, the Phoenix metrics controller tests passed, and the full ExUnit run
passed 451 tests.
- The isolated `scripts/quality.sh` systemd unit
`codex-heavy-wnh-quality-email-monitor-20260809-070511-2847948.service`
exited with result `success` and status `0` after 4 minutes 57 seconds. The
unit reported a 386 MiB memory peak. Every configured quality and security
gate passed, and the final Debian 13.6 runtime-image scan reported zero
detected vulnerabilities.
- Run-scoped quality/security images were cleaned automatically. Two unrelated
old local test tags with no container references were removed by exact tag;
no container or volume was removed by that cleanup.
- This is local verification only. The new aggregate delivery counters and
authenticated metrics scrape have not yet been deployed to production, and
the frozen hackathon test deployment and public Git remote were not changed.
# 2026-08-09 current production identity and exact E2E cleanup proof
- The observed production checkout was
`8ab30ce7f5bd0a28e1423b8da2846fe0e224f50c`. Its application container used
immutable image ID
`sha256:5df2246085afca1599ed1ea40c3f1bbcf8687dcbc73f9ec8728a9135d4ceb8a0`;
the shared edge used
`sha256:e450c305cc0a729406392dad5064f835a6f05ef45b787519023e12c8d65cadd2`.
The topology used external PostgreSQL 18.4 and had no production
project-local PostGIS or socket-proxy container. The application remained
healthy with zero restarts and no OOM kill after verification.
- Read-only hash comparisons, without printing credential values, confirmed
that production and hackathon test use different database URLs,
`SECRET_KEY_BASE` values, origins, Compose projects, SMTP passwords and
senders, and Google OAuth client IDs and secrets. Production and development
likewise use different database URLs, application secrets, hosts, Compose
projects, SMTP credentials and senders, OAuth clients, Firebase/FCM
identities, VAPID private keys, and Android Firebase values. The common
production/test operator support inbox is an intentional routing destination,
not a shared application credential.
- The isolated quality unit
`codex-heavy-wnh-quality-e2e-proof-run-20260809-20260809-073901-3859326.service`
exited successfully after 4 minutes 3 seconds with a 323.2 MiB memory peak.
All 451 ExUnit tests and every configured quality/security gate passed; the
Debian 13.6 runtime-image scan reported zero detected vulnerabilities.
- Production E2E run `production-e2e-20260809-cleanup-proof-2` passed both the
activity approval/privacy/reporting scenario and the two-person medicine
help scenario in Chromium. The isolated unit
`codex-heavy-wnh-prod-e2e-cleanup-proof2-20260809-20260809-074956-10667.service`
exited successfully after 2 minutes 17 seconds with a 53.1 MiB memory peak.
Evidence is retained at
`output/production-full-e2e/production-e2e-20260809-cleanup-proof-2/`.
- The run-scoped cleanup manifest recorded `cleanup_verified=true` and exact
target/deletion agreement for 26 record types. Non-zero totals were six
users, six user tokens, one staff role, two requests, three assignments, two
request messages, one tracking session, two reviews, one activity, two
activity participants, two activity messages, one report, one category
proposal, six audit events, two abuse signals, eleven notifications, and
fourteen push jobs. The task asserted every recorded ID absent, found no
late fixture job, and found zero remaining fixture-prefix records.
- Every tracked product-table total returned to its pre-run value. The global
Oban table contained one additional row after the run; the cause of that
concurrent global change is unknown. All fourteen run-scoped Oban job IDs
were nevertheless recorded, deleted, and individually verified absent.
- Cleanup evidence SHA-256 values were
`f2ad4be23b35401404d3435a8278d7e4050846894178b77c802a6d01222ea51a`
for `browser-console.log`,
`aa4addd980e8fdd58a22acf834397fb0c2bdff6651c7025ad1d3e4af7014115d`
for `fixture.json`, and
`b6513900d7b44aae5b1b79444df6a9de88fa0f78724f46fc81e2cbf47bf743f7`
for `fixture-cleanup.log`.
- The frozen hackathon test checkout stayed at
`cf7bacdf61ffb171ebac85e32dfcf12bc6972d59`; its application, database, and
Mailpit remained healthy, and public readiness remained `ready`. The remote
repository and hackathon-test deployment were not mutated.
# 2026-08-09 local public search-discovery verification
- The public home, Privacy Policy, Safety rules, and Terms of Service pages now
expose locale-aware canonical and reciprocal `en`/`uk`/`ru`/`x-default`
alternate links. Every other route defaults to `noindex, nofollow`, so
authenticated, support, legal, moderation, request, activity, profile, and
staff surfaces are not presented as public search results.
- `/sitemap.xml` contains exactly twelve absolute entries: the four public
pages in each of the three supported locales. It contains no account,
request, activity, support, legal, moderation, notification, or staff URL.
- `/robots.txt` is environment-aware. Production permits the public pages,
lists the private route families as disallowed, and advertises the absolute
sitemap URL. Development and test configurations return `Disallow: /`.
- Nineteen focused controller tests passed against an isolated temporary
PostgreSQL database. The complete isolated quality/security gate then passed
455 ExUnit tests, all fourteen browser map-clustering tests, and every
configured compiler, formatting, xref, Credo, Sobelow, Dialyzer,
dependency, image, Compose, Helm, migration, rollback, and observability
check. The Debian 13.6 runtime-image scan reported zero detected
vulnerabilities.
- The isolated quality unit
`codex-heavy-wnh-quality-seo-rerun-20260809-20260809-082004-916736.service`
exited with status `0` after 4 minutes 47 seconds and reported a 210.9 MiB
memory peak. Its run-scoped images, containers, networks, and volumes were
removed. Two older quality database volumes remain referenced by their own
stopped containers and were not changed by this verification.
- This verification changed only the local checkout. The public Git remote,
production deployment, and frozen hackathon test deployment were not
changed.
# 2026-08-09 Google Play internal v2 physical verification
- Google Play installed `org.whoneedhelp.mobile` version `0.1.1 (2)` from the
Internal testing track. The installed-build verifier observed installer
`com.android.vending`, a recorded Play App Signing identity, verified
`whoneedhelp.com` domain state, supported App Link resolution to
`MainActivity`, and exclusion of the browser OAuth callback.
- Production Google sign-in, scoped FCM delivery and tap routing were exercised
on the physical phone. The exact notification and its two related Oban jobs
were deleted and individually verified absent afterward.
- The Play build displayed the prominent location disclosure before Android's
native permission prompt. Foreground sharing continued while minimized,
exposed an ongoing notification with a stop action, and production retained
only one current position while active. Stopping removed the service and
notification and left zero retained raw positions.
- A cold offline start displayed the native privacy-safe offline screen.
Connectivity was restored to its original state, and a later verified App
Link restart returned to the authenticated request without restarting
sharing.
- The run-scoped requester, request, assignment and tracking session were
deleted and verified absent. Production readiness remained `ready`; the
frozen hackathon test deployment and public Git remote were not changed.
- Exact hashes, screenshots, cleanup scope and remaining Google Play gates are
recorded in `docs/google-play-release-candidate-2026-08-09-v2.md` and
`android/play-store/internal-release-v2.md`.
# 2026-08-10 authorised pilot release and Google Play internal v3 verification
- The production application was updated app-only to local revision
`7c2b55917dcaed52f9788cbbfcc6f2ff0a3354f6`. The shared Caddy edge, frozen
hackathon-test checkout, and public Git remote were not changed. Production
readiness returned `ready` after the release.
- A temporary production E2E run exercised the authorised application release
and completed exact run-scoped cleanup. The temporary test identities and
records were verified absent afterward; production readiness remained
`ready`, and the frozen-test readiness endpoint also remained `ready`.
- Production and frozen-test SMTP credentials were separated and verified
without printing their values. The replaced credentials were deactivated.
- Off-site backup creation, restore validation, and the external monitor were
rechecked and healthy after the application release.
- Google Play released the exact `0.1.2 (3)` AAB only to Internal testing. Its
SHA-256 is
`5f1b63d02467ce63af795d16459a75693e415426478e0788b83f0f6d35dff922`.
Play Console showed the release available to internal testers with one
version code and no Closed or Production rollout.
- The physical phone installed the artifact through Google Play. The strict
verifier observed installer `com.android.vending`, a recorded Play App
Signing identity, exact version `0.1.2 (3)`, verified production App Link,
and `MainActivity` resolution.
- A run-scoped foreground-location replay showed the prominent disclosure,
Android permission prompt, active in-app state, and persistent notification
while minimized. Notification Stop ended sharing; server verification
observed 41 samples and zero retained raw positions. The request,
assignment, tracking session, and synthetic requester were then deleted.
- The retained 177.864689-second source take is not the final Play declaration
video because Android screen recording stopped before the Stop tap and
stopped state were captured. A separate 21.379802-second final take from the
same Play-delivered build includes the trigger, disclosure, permission prompt,
minimized persistent notification, notification Stop action, and stopped
state. Its SHA-256 is
`3c5f52019bf8a42ff42e1d9232afc126b62627390d74eed75084d82ecb33ac56`.
Hosting that take as an unlisted video, the Play foreground-service
declaration, and Closed testing remain open gates. No Production Play rollout
has been started.
- Read-only Play Console Dashboard inspection showed app setup at 9 of 11
tasks. The remaining setup tasks were category/contact details and the Store
listing. Closed testing was locked pending those tasks and showed zero
opted-in testers. No Console values were saved and neither Closed nor
Production received a release during this inspection.
# 2026-08-10 completion audit rerun
- The isolated quality unit
`codex-heavy-wnh-completion-quality-20260810-141617-460910.service` exited
successfully after 4 minutes 17.828 seconds with a measured 353.5 MiB memory
peak. ExUnit reported 459 passed tests with seed `632176`; format,
compilation, xref, Credo, Sobelow, Dialyzer, Hex audit, locked browser
dependency audit, infrastructure image scans, and the production release
image scan all passed. The final runtime image scan reported zero detected
vulnerabilities.
- Exact-name inspection after the run found no remaining container, network,
volume, or temporary `quality`/`security` image from its Compose scope.
- A read-only production recheck observed revision
`7c2b55917dcaed52f9788cbbfcc6f2ff0a3354f6`, the expected immutable image,
healthy container state, zero restarts, and `OOMKilled=false`. Production,
frozen hackathon test, and development readiness endpoints returned
`ready` without changing any deployment.
- The scheduled production off-site backup last completed successfully,
including dump, catalogue, checksum, encrypted transfer, and isolated restore
validation. The independent external monitor also reported production
readiness and aggregate metrics `up`.
- Before the physical phone was disconnected, the installed Play-delivered
`0.1.2 (3)` package again passed the strict installer, signing identity,
version, verified App Link, and activity-resolution checks. Opening the
production requests App Link kept `MainActivity` in the foreground; no
foreground location service was running or started by that navigation.
- This audit changed only local documentation. It did not push the public Git
remote, modify the frozen hackathon test deployment, save Play Console
fields, or deploy a newer production revision.
- The development `/child-safety?locale=ru` page was compared visually with
the existing `/safety?locale=ru` design at matching desktop and mobile
viewports. The page preserved the shared header, typography, reading width,
spacing, and responsive button treatment. Browser measurements reported no
horizontal overflow at `2403x1310` or `390x844`; both reporting actions were
fully inside the 390-pixel viewport, and the browser console contained zero
errors or warnings. Production and the frozen hackathon test still return
`404` for `/child-safety` because neither deployment includes this later local
revision.
- The child-safety reporting action now opens the public content-removal form
with the CSAE/CSAM category already selected. The controller accepts only
category values declared by the notice schema and ignores unknown query
values. ExUnit covers both paths. A headed browser check followed the Russian
reporting action without submitting the form and observed the expected
`child_sexual_abuse_material` selection, no horizontal overflow, and zero
console errors or warnings.
# 2026-08-10 production authentication-email and browser Web Push checks
- A production passwordless sign-in request generated an authentication email
that arrived in the external operator mailbox at 10:48 EEST.
Gmail reported `Who Need Help <contact@whoneedhelp.com>` as the sender,
`whoneedhelp.com` as the signing domain, Brevo infrastructure as the mailing
domain, and TLS transport. The message states a 15-minute lifetime and shows
`https://whoneedhelp.com/` as its fallback origin. The action href itself is
currently rewritten through a Brevo tracking domain, so the separate
direct-production-domain URL gate remains open. The inspected message was
restored to unread state after verification.
- A guarded production Web Push smoke targeted the newest active browser-only
Web Push device for the confirmed production account. It created one scoped
notification and one `DeviceDeliveryWorker` job, did not enqueue email or
target Android FCM, and verified the exact job as `completed` on attempt 1
while the device remained active. Exact cleanup removed one job and one
notification; the local state file and remote temporary files were absent
afterward. Provider acceptance to a real subscription is therefore verified;
operating-system notification presentation and click navigation were not
directly observed.
- The smoke wrapper now preserves its mode-`0600` state file plus the remote
manifest and script whenever exact record cleanup does not finish. Temporary
files are removed only after the cleanup action has deleted and rechecked the
run-scoped records. This avoids losing recovery identifiers on an interrupted
or failed cleanup.
- A read-only ADB recheck observed the connected Xiaomi `23122PCD1G` and the
Play-installed `org.whoneedhelp.mobile` package at `0.1.2 (3)`, target SDK 37,
with installer `com.android.vending`. No package reinstall, data clear, or
permission mutation was performed.
# 2026-08-13 support/legal production-E2E boundary verification
- The run-scoped production browser harness now prepares one verified support
request and one verified general content-removal notice for its synthetic
requester. Both rows are inserted directly without invoking notification or
mail contexts. The browser signs in as the run-scoped administrator, locates
each row through its permission-scoped queue, opens it read-only, and does
not submit an operator decision.
- The fixture manifest schema records the exact support and legal UUIDs.
Cleanup refuses a manifest/relationship mismatch, removes jobs addressed to
those exact records, verifies one deletion for each record, and leaves an
unrelated queued job intact. The focused cleanup regression test and the
complete 470-test ExUnit suite passed.
- The isolated quality unit
`codex-heavy-wnh-quality-support-legal-r2-20260813-071442-1645753.service`
completed successfully. Formatting, compilation, xref, Credo, Sobelow,
Dialyzer, dependency audits, image scans, Compose/Helm validation, migration,
release, rollback, backup, and observability gates passed; the scanned
runtime images reported zero high or critical vulnerabilities.
- The isolated browser E2E unit
`codex-heavy-wnh-browser-e2e-support-legal-20260813-071912-1795990.service`
completed with 63 passing tests and three expected production-only skips
across Chromium, Firefox, and WebKit. Exact post-run inspection found zero
containers, networks, volumes, or temporary images from its Compose scope.
- A read-only production plan observed the compact production application at
revision `dafcdb36cbe221af0c880fd05da3321e181ddd2c`, healthy with zero
restarts and no existing users for the proposed run prefix. The plan printed
the exact mutation and cleanup scope. No production E2E run was executed,
no production or frozen-test deployment was changed, and the public Git
remote was not pushed.
# 2026-08-14 deterministic-map production E2E replay
- The external OpenStreetMap boundary probe returned HTTP 200, `image/png`,
and a valid PNG payload. The browser flow then used the harness-owned
deterministic PNG response only for exact OpenStreetMap tile URLs, while
application requests and browser errors remained subject to the strict
failure policy. The focused browser-policy suite passed all five tests.
- Temporary production run `production-e2e-20260814-23776e2` passed all three
Chromium scenarios: activity approval/privacy/reporting, the complete
two-person medicine-help flow, and read-only staff visibility of run-scoped
support/legal fixtures. The isolated unit
`codex-heavy-wnh-prod-e2e-23776e2-20260814-041855-1873019.service` exited
successfully after 3 minutes 16.370 seconds with a 51.7 MiB memory peak.
- The browser console evidence contains no error or warning entry. Readiness
was `ready` before and after the browser flow. Exact manifest cleanup removed
all run-owned users, tokens, requests, assignments, chats, activity records,
reviews, reports, support/legal rows, notifications, audit events, tracking
state, and fourteen exact Oban jobs. Cleanup verification found zero
remaining run-prefix users and no recorded fixture relationship.
- Every tracked product-table total returned to its pre-run value. The global
Oban table contained one additional row after the run; its concurrent source
is unknown, while every run-scoped Oban job was individually recorded,
removed, and verified absent.
- The complete isolated quality/security gate for local revision `23776e2`
passed 480 ExUnit tests plus formatting, compilation, xref, Credo, Sobelow,
Dialyzer, dependency, secret, container, Compose, Helm, migration, release,
rollback, backup, and observability checks. The final Debian 13.6 runtime
scan reported zero detected vulnerabilities. Unit
`codex-heavy-wnh-quality-23776e2-20260814-042628-2092739.service` completed
after 4 minutes 44.774 seconds with a 313.6 MiB memory peak and no swap. Its
run-scoped containers, networks, volumes, and temporary images were absent
afterward.
- Read-only post-run inspection found production clean at revision
`f1947f2264a6a51da4eb8a6a11ff83b8161f1f64`, healthy with zero restarts and
public readiness `ready`. The frozen hackathon test remained clean at
`cf7bacdf61ffb171ebac85e32dfcf12bc6972d59`; its application, database and
Mailpit containers remained healthy and public readiness remained `ready`.
The remote repository, Caddy, production release, and frozen-test deployment
were unchanged.
# 2026-08-21 backup schedule and current production read-only load
- The operator workstation's user-systemd timer
`who-need-help-production-backup.timer` was loaded, enabled, active, and
waiting. It last triggered at 00:00 EEST on 21 August and is scheduled to
trigger again at 00:00 EEST on 22 August. The production host has no backup
timer or service. This matches the reviewed design: the workstation obtains
the source dump over SSH, sends the encrypted Restic snapshot to the separate
BuyVM host, and publishes the restore-verified heartbeat there.
- The scheduled service exited `0/SUCCESS` after 4 minutes 48.415 seconds. It
measured 2.294 seconds of local CPU time and a 50.8 MiB local memory peak.
PostgreSQL dump, checksum, catalogue, full repository data check, and the
isolated restore drill passed. The completed snapshot identifier is
`afdb5c5caa1df84203fc261817a153ade57d133a9102c501db10befc48fc4b77`.
- The independent monitor uses the operator-selected stale-heartbeat threshold
of 129600 seconds, or 36 hours. The current monitor state was `up`, with
readiness, metrics, and backup freshness all passing. This threshold does not
define retention, RPO, RTO, capacity, ownership, or encryption-key custody.
- A current read-only production load probe targeted exact revision
`bb7eb58c8f14d8936cae0e968b50ae721516d213` on the 2-CPU, 4,004,224-KiB host.
For 60 seconds it ran 20 HTTP virtual users against the fixed public GET
allow-list and 20 Phoenix WebSocket virtual users sending only heartbeat
frames. It performed 11,464 HTTP requests with zero failed checks and opened
20 of 20 sockets with 40 heartbeat replies and zero socket errors. HTTP
duration averaged 54.11 ms, p95 was 73.85 ms, and the maximum was 607.87 ms.
- During that probe, application-container CPU averaged 51.53% and peaked at
58.29%. Container memory peaked at 207,827,763 bytes. Host available memory
remained at or above 1,352,896 KiB. Readiness returned the exact ready payload
before and after the run. Counts for users, user tokens, and rate-limit
buckets remained `[16, 7, 20]`; PostgreSQL reported no new rollback, temporary
file, temporary byte, or deadlock count.
- This is a public read-only regression measurement, not a representative pilot
traffic model. It does not cover request creation, assignments, chat writes,
location updates, authentication delivery, support submission, push
delivery, or SMTP. No capacity limit or scaling threshold is inferred from
it. The non-secret evidence is retained under
`output/performance/production-current-bb7eb58-20260821/`.
- A headed production browser check reused the existing authenticated Chrome
session. The account menu exposed the expected Account settings route. The
route redirected to the reauthentication screen and displayed the explicit
message that reauthentication is required. No account setting was changed and
no new authentication email was requested.
- Current production metrics exposed bounded purpose labels rather than email
addresses. The observed process reported two successful
`support_confirmation` deliveries, two successful `mail` queue jobs, and no
delivery exception in the selected metric set. These counters describe only
the current application process, not historical delivery volume.
# 2026-08-21 production support and legal queue coverage
- Temporary production run `codex-support-legal-20260821-r3` passed all three
Chromium scenarios against exact deployed revision
`bb7eb58c8f14d8936cae0e968b50ae721516d213`: activity moderation, the complete
two-person medicine-help flow, and support/legal queue coverage.
- The support/legal scenario submitted authenticated support, privacy,
data-export and account-deletion requests through the public UI. Staff found
the resulting records in the permission-scoped production queue. The same
staff session found and opened distinct run-scoped general-removal and TAKE
IT DOWN records without submitting an operator decision.
- The fixture manifest used schema version 3, recorded the exact support,
general-removal and TAKE IT DOWN UUIDs, and ended with
`cleanup_verified=true`. Post-run inspection found
`fixture_prefix_count=0`; no run-owned fixture user or relationship remained.
- Anonymous contact verification was not submitted in this run because it
intentionally enqueues a real verification email. That path remains an open
controlled production-mail check rather than an inferred success.
- Non-secret evidence is retained under
`output/production-full-e2e/codex-support-legal-20260821-r3/`. The frozen
hackathon test deployment, Caddy, public Git remote and production release
were not changed by this browser run.
# 2026-08-21 Google Play Closed testing read-only recheck
- The authenticated Play Console reported `Social` as the saved app category.
Store-listing contact details remained empty. The contact editor marked only
the email address as required; phone and website were optional. The editor
was closed without saving.
- The existing `Closed testing - Alpha` track was inactive with zero of four
setup tasks complete: countries were not selected, testers were not selected,
and no release existed. Preview, review submission, Android join and web join
links were therefore unavailable.
- The tester page contained one email list named `Who Need Help Internal` with
one member, but the list was not selected for the Alpha track. The tester
feedback address was empty. No tester, country, release or public contact was
changed during this inspection.
- Completing Store settings requires an operator decision: either configure and
externally verify an inbound project address, or deliberately publish another
monitored email address. Current outbound Brevo delivery does not prove that
`contact@whoneedhelp.com` can receive mail.
# 2026-08-21 Brevo authentication-link tracking recheck
- A read-only check reused the existing authenticated Chrome dev-port tab and
inspected `Settings > Automations > Transactional emails > Tracking`. The
account exposed one control, `Anonymous email tracking`, and its observed
value was `No`. No setting was changed or saved.
- Brevo's current help documentation states that anonymous tracking continues
to record opens and clicks in aggregate while removing their association with
specific contacts. The current SMTP documentation does not publish a
per-message header that disables click tracking. Therefore neither enabling
the observed anonymous option nor adding an undocumented SMTP header is
accepted as proof that authentication action URLs remain on the production
domain.
- The direct-production-domain action-URL gate remains open. Resolving it
requires an explicit provider/account decision followed by a newly delivered
authentication message whose actual href is inspected; no provider setting,
application email format, production deployment, frozen test deployment, or
public Git remote was changed by this recheck.
# 2026-08-21 connected-device Play delivery recheck
- The authorised physical device `72551e60` reported installed package
`org.whoneedhelp.mobile` at exact version `0.1.2 (3)` with installer
`com.android.vending`.
- `scripts/verify-play-installed-android.sh` matched the installed signing
identity against the protected Play App Signing identity set. Android
reported `whoneedhelp.com` as verified, resolved the production safety URL to
`MainActivity`, and did not resolve the browser-only Google OAuth callback to
the Android application.
- This was a read-only installed-build verification. It did not launch,
install, update, uninstall, clear, or reconfigure the application. It also
did not change Play Console, production, the frozen hackathon test deployment,
or the public Git remote.
# 2026-08-21 final local quality and production-runtime recheck
- The operator selected a stale-backup alert threshold of 36 hours, or 129600
seconds. The installed external monitor configuration contained that exact
value. Its observed state was `up`: readiness, aggregate metrics, and the
restore-verified backup heartbeat all passed. The heartbeat was 6208 seconds
old when inspected. The workstation backup timer remained enabled and
waiting for its daily 00:00 EEST invocation.
- Production compact mode was checked through the running release rather than
inferred from the number of containers. The application reported role
`combined`; Phoenix Endpoint and Oban were both live children of the
application supervisor. Oban exposed the configured `maintenance`, `push`,
and `mail` queues with limits 2, 1, and 1. The database contained 1441
completed maintenance jobs and 22 completed mail jobs, with no available,
scheduled, retryable, executing, discarded, or cancelled backlog and no
non-successful job from the preceding seven days.
- The isolated quality unit
`codex-heavy-wnh-final-quality-20260821-20260821-014659-1951688.service`
exited successfully after 2 minutes 48.647 seconds with a 257.2 MiB memory
peak. ExUnit reported 484 passing tests. Formatting, compilation, xref,
Credo, Sobelow, Dialyzer, dependency audits, infrastructure checks, image
scans, Compose and release checks all passed. The final Debian 13.6 runtime
image scan reported zero detected vulnerabilities.
- Exact post-run inspection found no container, network, volume, or temporary
quality/security image from that run. Production remained healthy at
`bb7eb58c8f14d8936cae0e968b50ae721516d213`; the frozen hackathon test
remained healthy at `cf7bacdf61ffb171ebac85e32dfcf12bc6972d59`.
Both public readiness endpoints returned the exact ready payload. The public
Git remote remained at `921e04b3608007675e22e7e26e0beb3975dbba58` and was
not pushed.
- The external monitor runs independently on `209.141.50.251`, while the
production application and edge resolve to `159.195.158.59`. Its user timer
was enabled and active on the minute schedule. At
`2026-08-20T23:02:22.000569Z` its persisted state reported aggregate,
readiness, authenticated metrics, and backup freshness as `up`; the metrics
node was `who_need_help@172.19.0.2` and the configured stale-backup threshold
was exactly 129600 seconds.
- A public read-only request to `https://whoneedhelp.com/healthz/ready` returned
HTTP/2 200, the exact `{"status":"ready"}` payload, and `Via: 1.1 Caddy`.
The readiness implementation checks the database with `SELECT 1` and, for
the observed combined application role, requires the supervised Oban worker
to be running. The authenticated metrics endpoint exposes bounded HTTP
exception, Oban failure, email delivery/exception, and push outcome counters
consumed by the external monitor; database timing and VM runtime metrics are
also exported for operator diagnosis.
- The production backup user timer was enabled and active on the workstation.
Its 2026-08-21 00:00 EEST invocation finished with result `success`; the next
invocation was scheduled for 2026-08-22 00:00 EEST. Backup monitoring uses
the restore-verified heartbeat rather than mere archive creation.
- In the already authenticated operator Gmail inbox, a read-only Playwright
inspection found the unread message `[Who Need Help] Operations monitoring
test`, delivered on 2026-08-20 at 20:04 EEST and labelled Inbox plus
Projects/WhoNeedHelp. The message was not opened or marked read. Together
with the live monitor state, this proves that the responsible operator can
receive the alert channel; the monitor's unit tests cover state-transition,
recovery, bounded metric parsing, and stale-backup alert behaviour without
inducing a production outage.
# 2026-08-21 authentication-email direct URL fallback
- The HTML authentication message now contains one clickable action button and
one non-clickable, plain-text copy-and-paste URL. This prevents the fallback
itself from becoming a second provider-rewritten link.
- The focused notifier test rendered the multipart message and passed all four
test cases. It also asserted that the HTML contains exactly one `href` and
that the direct application URL remains visible as text.
- This does not prove that Brevo leaves the action button unchanged. The
provider tracking limitation remains open until a newly delivered production
message is inspected. No production or frozen test deployment was changed by
this local check.
# 2026-08-21 post-fallback full local quality recheck
- The isolated quality unit
`codex-heavy-wnh-quality-auth-url-20260821-20260821-022331-2842574.service`
exited successfully after 4 minutes 34.807 seconds with a 219.1 MiB memory
peak. It checked the exact local commit `711da82e08fb0cbbf7927bb4cbf17e2aedb46bea`.
- ExUnit reported 484 passing tests. Formatting, compilation, xref, Credo,
Sobelow, Dialyzer, Hex and browser dependency audits, infrastructure checks,
release checks, and pinned image scans all passed. The final Debian 13.6
runtime scan reported zero detected high or critical vulnerabilities.
- Exact post-run inspection found no container, network, volume, or temporary
image carrying run identifier `20260820232333-2842586`. The frozen hackathon
deployment, production deployment, Caddy, and public Git remote were not
changed by this local verification.
# 2026-08-25 manifest ownership and external-monitor final recheck
- The production Android FCM smoke and production browser E2E preparation now
exclusive-create their mode-`0600` manifests inside the same database
transaction as the run-owned records. Each manifest contains a UUID ownership
token. Failure cleanup removes a manifest only when that exact token matches,
so a concurrent process cannot cause one run to delete another run's state.
- The external-monitor installer now reads and validates the selected remote
account's actual home directory. Remote systemd, state, configuration, and
backup-heartbeat paths are derived from that observed home instead of assuming
`/home/simple`. The installer regression suite passed all six cases, including
a non-default `/home/monitor-user` account.
- A read-only external-host check observed account `simple` with home
`/home/simple` and `linger=no`. Its user timer was loaded, enabled, and active
while the user manager was running; the latest completed monitor check
reported readiness, authenticated metrics, and backup freshness as `up`.
This proves the current check completed, but it does not prove persistence
after logout or boot. No lingering setting was changed.
- The final isolated quality unit
`codex-heavy-wnh-final-quality-manifest-monitor-20260825-20260825-175845-502195.service`
exited successfully after 4 minutes 55.976 seconds. It reported 487 passing
ExUnit tests, 18 passing browser-asset tests, all configured shell/Python
regression suites, and all isolated quality and security gates passing. The
final Debian 13.6 production image and the pinned infrastructure images
reported zero detected vulnerabilities at the configured scan severity.
- The unit's measured memory peak was 438.9 MiB and swap use was zero. Exact
post-run inspection found no container, network, volume, or temporary image
from Compose project `wnh_quality_20260825145846502200` or run identifier
`20260825145846-502200`.
- This was local verification only. Production, the frozen hackathon test
deployment, shared Caddy, and the public Git remote were not changed or
pushed.
Reference in New Issue View Git Blame Copy Permalink