Document Path C: user reports stay in Supabase

[lukesmmr]

Summary

• Documents the architectural decision from disasters-mobile#1: user reports do not sync to the Disasters API
• Updates CONTRACTS.md with a clear data boundary section explaining what lives where
• Removes user from the API source field documentation since user data won't flow through this API

Context

The mobile app plan originally had user reports syncing from Supabase to the API via an Edge Function. Analysis revealed this creates:

• Schema mismatch - user reports need title, phase, photos, voting, moderation, verification fields that don't exist in the disasters table
• Sync complexity - moderation cascading, visibility leaks, dedup fragility
• Semantic pollution - community actions (volunteer calls, donation points) mixed with official disaster data

Path C keeps the API focused on official government feeds. The mobile app reads from both the API and Supabase, merging client-side into a UnifiedDisasterEvent.

Test plan

• Review the data boundary section in CONTRACTS.md
• Verify the matching update was pushed to disasters-mobile main
• Confirm this aligns with the mobile app planned architecture

Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch docs/path-c-user-reports-architecture

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[js-0s]

user data could be in atproto as it already supports all the social features, mobile/ui could just request events filtered by stored disaster-urn/id. this should concern inputs, updates, me-too's or even initial mentions '@disaster-alert: heavy rain near $city'

a user 'source' is still a valid source imo, even if users should not be able to populate it directly because of validation/input structure/spam. supabase (or atproto) user-data should sync back to form a event in the da-database so that future-tooling (notify when something is near me) uses a single db for evaluation, not requesting multiple data-sources for each user which would scale badly. maybe its a 'social' source then.