NeighbourhoodWatch

Appearance

Doc status: Latest (rolling). See Versions.

This roadmap is intentionally written in a waterfall-style phased plan. Each phase produces a clear, reviewable deliverable. Version tags represent documentation + interface snapshots, not marketing.

Phase 0 — Definition & invariants (v0.1.x) ​

Exit criteria

  • Requirements are explicit: roles, join-by-invite, alert trigger, admin pause/ban/broadcast
  • Data minimisation invariants are explicit: no exact addresses; avoid exact lat/lng where possible
  • Authorization invariants are explicit: all privileged actions verified server-side

Artifacts

  • Versioned docs snapshot (see /v/<version>/)
  • API contract list (endpoints + auth header expectations)

Phase 1 — MVP implementation (v0.2.0) ​

Scope

  • Sign-in (Firebase Auth)
  • Join group via invite code
  • Register device for push notifications
  • Trigger incident → push fan-out to group
  • Admin: pause/ban member, broadcast

Exit criteria

  • End-to-end flow works on iOS + Android (non-critical audio behavior acceptable)
  • Server enforces membership + role checks for privileged endpoints
  • Minimal PII stored (reviewed)

Phase 2 — Verification & hardening (v0.3.0) ​

Scope

  • Contract tests for API endpoints
  • Abuse controls (rate limiting + dedupe where relevant)
  • Audit logging (server-side event trail)

Exit criteria

  • Basic abuse scenarios tested and mitigated
  • Operational logging sufficient for incident reviews

Phase 3 — Operational readiness (v0.4.0) ​

Scope

  • Monitoring/alerting for API errors and push failures
  • Runbooks (how to ban, revoke invites, respond to abuse)
  • Staging environment parity (where practical)

Exit criteria

  • On-call / maintenance burden is low and documented
  • Clear rollback and incident response procedure exists

Phase 4 — Enhancements (v0.5.0+) ​

Candidate items (only if they don’t violate the minimal UX constraint)

  • Multi-group membership
  • Incident lifecycle (acknowledge/close) with strict permissions
  • Admin audit log UI

iOS Critical Alerts ​

iOS Critical Alerts require Apple entitlement approval. The system can support the payload flags, but the entitlement process is external and should be tracked as a separate operational workstream.