Doc status: Latest (rolling). See Versions.

This roadmap is intentionally written as a phased plan with clear, reviewable deliverables. It covers both delivery work (apps + backend) and organisational readiness (governance, approvals, volunteers). 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 — Accounts, approvals, and operational prerequisites (v0.2.0)

Scope (non-code, but blocking for release)

• Apple Developer account
  • Enrol and verify organisation (or individual initially, if needed)
  • Set up App Store Connect access roles
• Google / Android release readiness
  • Create Play Console account
  • Set up signing keys and release tracks
• Emergency / critical notifications approval
  • iOS: request the appropriate entitlements/approval for loud/critical alerts (external process)
  • Define a policy for when emergency alerts may be used (misuse controls)
• Business / NFP structure
  • Decide and create the legal entity structure (NFP/charity/co-op as applicable)
  • Basic governance: directors/owners, bank account, record-keeping
• Volunteer operations
  • Roles, onboarding, code of conduct, access control (who gets admin rights)
  • Basic moderation/incident-review workflow (even if manual)
• Publicity and partnerships
  • Messaging and community outreach plan
  • Identify local partners (council/community groups)
• Funding
  • Identify grant opportunities and prepare an evidence/impact plan

Exit criteria

• Release accounts and approvals are in progress or obtained
• Governance/ownership and admin access model is defined
• A minimal volunteer onboarding plan exists

Phase 2 — MVP implementation (v0.3.0) ✅

Scope

• Sign-in (@react-native-firebase/auth native SDK — Google Sign-In + Sign in with Apple)
• Join group via invite code
• Register device for push notifications
• Trigger incident → push fan-out to group
• Encrypted incident payload for address package (on-device only): AES-256-GCM + ML-KEM-768 envelopes (optionally signed with ML-DSA-44)
• Admin: pause/ban member, broadcast

Integration checklist

• Wire up @react-native-firebase/auth native SDK in:
  • Mobile (iOS/Android) — initializes via google-services.json / GoogleService-Info.plist
  • Admin web (Cloudflare Zero Trust + Microsoft Entra ID SSO)
• Configure Cloudflare Worker environment (prod):
  • Firebase project id
  • Service account JSON (secret)
  • iOS critical alerts flag (only if approved)
• Deploy:
  • Worker API via Wrangler
  • Admin web (hosting choice; keep minimal)
  • Docs via Cloudflare Pages (custom domain: nwatch.incitat.io)

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)
• No plaintext addresses stored or logged; address package decrypts only on recipient devices

Testing checklist (MVP)

• iOS: push receives reliably (foreground/background), expected alert tone/behavior
• Android: notification channel importance/sound set correctly
• Abuse checks: paused/banned user cannot trigger alerts
• Manager actions: create invite, ban/pause, broadcast

Phase 3 — Verification & hardening (v0.4.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 4 — Operational readiness (v0.5.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
• "Join a different group" in-app option

See the Feature Backlog for detailed specifications on each item.

Phase 5 — Licensing & payments (v0.6.0) ✅

Scope

• Stripe integration (REST API, no SDK) for group license subscriptions
• License types: paid (Stripe) and granted (super admin)
• License statuses: active, expired, revoked, trial
• Stripe Checkout flow (monthly / annual plans)
• Webhook processing: checkout.session.completed, invoice.payment_succeeded, invoice.payment_failed, customer.subscription.deleted
• License gate on incident triggering (402 if no active license)
• Payment records and notification log

Admin dashboard

• Group license status display
• Stripe checkout initiation (monthly/annual)
• Payment history per group

Super admin dashboard

• All licenses overview (with grant/revoke)
• All payments overview
• User role management (standard/manager/super_admin)
• All users and groups listing

Exit criteria

• End-to-end payment flow works (checkout → webhook → license activation)
• License enforcement blocks alerts for unlicensed groups
• Super admin can grant/revoke licenses manually
• Payment records stored for audit

Phase 6 — Critical Alerts & notification hardening (v0.7.0)

Scope

• iOS Critical Alerts entitlement: Apply to Apple for the Critical Alerts entitlement; update APNs payload to include { "sound": { "critical": 1, "volume": 1.0 } } once approved. Critical Alerts bypass DND, silent mode, and Focus.
• Android alarm-priority channel: Create a dedicated notification channel with IMPORTANCE_MAX, setBypassDnd(true), and fullScreenIntent to wake the device and play an alarm sound until acknowledged.
• Alert persistence: Write alerts to local storage on receipt; display an "Active Alerts" list in the app; alerts remain until a manager resolves the incident from the admin dashboard.
• Incident lifecycle: Manager can resolve/clear an alert from the admin dashboard → push sent to group confirming resolution → app updates alert status.
• Admin audit log: Full audit trail in admin dashboard — super admin sees everything; managers see only their group(s).

Action items

1. Submit Apple Critical Alerts entitlement request (external process)
2. Add ACCESS_NOTIFICATION_POLICY permission + alarm channel config plugin for Android
3. Implement full-screen intent activity for Android alert display
4. Implement in-app alert persistence (AsyncStorage or SQLite)
5. Add "Resolve Alert" endpoint + admin UI ✅ Done — POST /v1/admin/groups/:gid/incidents/:iid/resolve + Incident Detail modal
6. Build audit log page in admin dashboard (super admin vs manager scoping) ✅ Done — Audit Log tab with role-scoped filtering + incident notes with visibility levels

Exit criteria

• Alerts sound at full volume and bypass DND/silent on both platforms
• Alerts persist in-app until manager resolves
• Admin audit log shows all relevant actions with role-based scoping

See the Feature Backlog for detailed specifications.