Reported during QA session. Future enhancement — not scheduled.
What's wrong
The map shows only live user positions. There is no way for an admin to publish fixed points of interest — evacuation centres, medical stations, relief distribution points, hazard zones — so the information that actually tells a person in an emergency where to go lives outside the system entirely.
What I'd like
An admin can place and manage named sites on the map from the admin dashboard, and those sites render on both the admin map and the mobile map for users.
Proposed change
Cross-cutting — server + admin + mobile as one unit of work (root CLAUDE.md):
- Server: a
site model (id, name, type, latitude, longitude, description, active flag, timestamps) plus admin-authenticated CRUD endpoints and a read endpoint for clients. Schema changes here have no migration tooling — follow the manual process in docs/database/migrations.md (ADR 0002). Regenerate docs/api/openapi/** and docs/database/{tables,erd}.md via the scripts rather than hand-editing (they are drift-checked in CI).
- Admin (
ui/components/MapLibre.tsx + a management screen): place a site by clicking the map, edit/delete existing ones, pick a site type.
- Mobile (
app/(drawer)/(tabs)/map.tsx): render sites as a distinct marker class from user markers, with a tap-through detail sheet. Sites should be available to any authenticated user, not just rescuers — that is the point of them.
- Site data should survive being offline: it changes rarely and matters most when connectivity is worst, so cache it locally rather than requiring a live fetch to draw the map. Consider whether it belongs in the existing sync path or a simpler cached fetch — worth deciding explicitly rather than by default.
Open questions
- Fixed site-type taxonomy (evacuation centre, medical, relief, hazard, …) or admin-defined types?
- Do sites need a capacity/status field (open, full, closed)? That is the difference between "useful in a drill" and "useful in an actual evacuation".
- Point markers only, or do hazard zones need polygons? Polygons are a materially larger change — worth splitting if so.
- Should regular users see all sites, or only sites near them?
Additional context
Independent of #323 ("authenticated users see rescuers"), but they share the same goal: making the map useful to someone who is not a rescuer. Should probably be planned together.
Reported during QA session. Future enhancement — not scheduled.
What's wrong
The map shows only live user positions. There is no way for an admin to publish fixed points of interest — evacuation centres, medical stations, relief distribution points, hazard zones — so the information that actually tells a person in an emergency where to go lives outside the system entirely.
What I'd like
An admin can place and manage named sites on the map from the admin dashboard, and those sites render on both the admin map and the mobile map for users.
Proposed change
Cross-cutting — server + admin + mobile as one unit of work (root
CLAUDE.md):sitemodel (id, name, type, latitude, longitude, description, active flag, timestamps) plus admin-authenticated CRUD endpoints and a read endpoint for clients. Schema changes here have no migration tooling — follow the manual process indocs/database/migrations.md(ADR 0002). Regeneratedocs/api/openapi/**anddocs/database/{tables,erd}.mdvia the scripts rather than hand-editing (they are drift-checked in CI).ui/components/MapLibre.tsx+ a management screen): place a site by clicking the map, edit/delete existing ones, pick a site type.app/(drawer)/(tabs)/map.tsx): render sites as a distinct marker class from user markers, with a tap-through detail sheet. Sites should be available to any authenticated user, not just rescuers — that is the point of them.Open questions
Additional context
Independent of #323 ("authenticated users see rescuers"), but they share the same goal: making the map useful to someone who is not a rescuer. Should probably be planned together.