Who Need Help — implementation verification

Observed on 2026-07-18 in the local workspace. This report separates observed results from product limits and unknown production properties.

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.
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 are intentionally a future `Activity` mode.
Map and discovery	Implemented and browser-verified	A headed Chrome session rendered the MapLibre request map, marker, controls, attribution, and configured OpenStreetMap raster tiles. Tile requests returned HTTP 200 during the check.	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.
Foreground tracking	Implemented and cross-client verified	Android emulator coordinates created an active tracking session and appeared for the matched requester. Stopping sharing made the session inactive and removed raw current positions.	No background tracking or route history is implemented.
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.
Social profiles	Implemented as manual links	Public links can be attached and are visibly labelled unverified.	OAuth/social-network verification is not implemented.
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	Debug client implemented and emulator-verified	The native package `org.whoneedhelp.mobile.debug` launches the same authenticated LiveView app. Login persistence, map, chat, and foreground geolocation were exercised on API 37. The final Docker emulator image separately passed boot/install/launch smoke verification.	Production signing, a public production origin, Play Store publication, background tracking, and iOS are not implemented.
Multiple web/worker instances	Implemented and locally verified	Docker Compose and kind each ran 2 web and 2 worker replicas. The project probes cross-node Phoenix PubSub using different BEAM nodes. Kubernetes web/worker pods were Ready with zero restarts at the final observation.	Local PostGIS is a single instance. Production database HA, backups, and recovery are operator work and are not claimed complete.

Reproducible checks

./scripts/test.sh: 121 tests, 0 failures in the final run.
mix format --check-formatted: passed in the final run.
Android Docker build target: testDebugUnitTest, lintDebug, and assembleDebug passed; the final lint report contains no errors or warnings.
Release Android guard: a release build without WNH_BASE_URL failed as intended; release configuration accepts only an explicit 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.
Browser verification used headed Chrome. Fresh requester and helper pages reported no console errors or warnings after the final rollout.

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

Android artifact:

android/dist/who-need-help-debug.apk
SHA-256: 4df66ec90e056c70f08841db2f0aa6178ba9cb64d4882478cd2cba88f5731003
Observed manifest values: version 0.1.0-debug, minimum SDK 24, target and compile SDK 37.

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 final local Compose observation found 2 users, 1 help request, and 7 messages. These are local scenario data; the database is not assumed empty.

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 load dataset or target-environment measurement. The Helm chart therefore does not invent resource limits or an HPA policy.

Known work before a public production launch

Configure a real public HTTPS origin and production-sign the Android app.
Operate PostgreSQL/PostGIS with backups, recovery testing, and the required availability model.
Load-test representative data and traffic, then set measured pool, resource, autoscaling, and action-limit policies.
Add pagination or bounded loading where real measurements show that request, chat, moderation, or leaderboard result sets require it.
Publish jurisdiction-specific emergency contacts, privacy, retention, prohibited-items, and voluntary-payment guidance after legal review.
Add OAuth identity verification only if the product chooses to make verified social accounts a trust signal.
Design the separate future social-activity mode rather than mixing it with urgent-help safety and ranking rules.

7.1 KiB Raw Blame History