# 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.