77 lines
2.8 KiB
Markdown
77 lines
2.8 KiB
Markdown
|
# Project Requirements — Relationship App
|
||
|
|
|
||
|
|
These requirements apply to all agents working on the Couples Connection app.
|
||
|
|
|
||
|
|
## Project Philosophy
|
||
|
|
|
||
|
|
- Feel private, warm, calm, intentional, and human
|
||
|
|
- Prioritize emotional connection over productivity
|
||
|
|
- Provide smooth, low-friction interactions
|
||
|
|
- Avoid social media patterns, notification spam, and addiction mechanics
|
||
|
|
- Maintain fast perceived performance
|
||
|
|
- 5 meaningful minutes > turning relationships into homework
|
||
|
|
|
||
|
|
## Technology Stack
|
||
|
|
|
||
|
|
- **Framework:** React Native + Expo
|
||
|
|
- **Language:** TypeScript
|
||
|
|
- **Backend:** Supabase (Auth, Database, Realtime, Storage)
|
||
|
|
- **Media Storage:** Cloudflare R2
|
||
|
|
- **Push Notifications:** Expo Push Notifications
|
||
|
|
- **Styling:** NativeWind (Tailwind CSS for React Native)
|
||
|
|
- **UI Components:** shadcn/ui-style primitives adapted for mobile
|
||
|
|
- **NOT Next.js.** NOT a web app. This is a mobile app built with React Native + Expo.
|
||
|
|
|
||
|
|
## Frontend Standards
|
||
|
|
|
||
|
|
- React Native with Expo (cross-platform: iOS + Android)
|
||
|
|
- NativeWind for styling (Tailwind CSS syntax for native)
|
||
|
|
- shadcn/ui-style component primitives adapted for mobile
|
||
|
|
- Responsive to phone form factors only (no desktop layout concerns)
|
||
|
|
- Smooth animations and transitions (haptics where appropriate)
|
||
|
|
- Loading states, error states, accessible interfaces
|
||
|
|
- Warm, intimate, calm design language
|
||
|
|
|
||
|
|
## Backend Standards
|
||
|
|
|
||
|
|
- Supabase for all backend services (auth, database, realtime, storage)
|
||
|
|
- Row Level Security (RLS) on all tables — strict couple access isolation
|
||
|
|
- Validate all input on both client and server side
|
||
|
|
- Supabase Edge Functions for custom logic where needed
|
||
|
|
- Structured error handling, no silent failures
|
||
|
|
|
||
|
|
## Database Standards
|
||
|
|
|
||
|
|
- PostgreSQL via Supabase
|
||
|
|
- Row Level Security (RLS) enforced on all tables
|
||
|
|
- Couples isolation: users can only access their own couple's data
|
||
|
|
- Schema migrations via Supabase dashboard or CLI
|
||
|
|
|
||
|
|
## Auth Standards
|
||
|
|
|
||
|
|
- Supabase Auth with email magic links (initial MVP)
|
||
|
|
- Optional Google/Apple login later
|
||
|
|
- No traditional passwords
|
||
|
|
- No phone auth initially
|
||
|
|
|
||
|
|
## Security & Privacy
|
||
|
|
|
||
|
|
- This app handles intimate personal data — security and privacy are paramount
|
||
|
|
- Supabase Row Level Security on all tables
|
||
|
|
- Private storage buckets with signed URLs
|
||
|
|
- Strict couple access isolation (no cross-couple data leaks)
|
||
|
|
- Encrypted transport (HTTPS/WSS)
|
||
|
|
- No tracking, no surveillance features
|
||
|
|
- Users must trust the app emotionally and privately
|
||
|
|
|
||
|
|
## Code Quality
|
||
|
|
|
||
|
|
- Readable, maintainable, no overengineering
|
||
|
|
- Remove dead code, consistent formatting
|
||
|
|
- Document non-obvious logic
|
||
|
|
- Prefer clarity over cleverness
|
||
|
|
|
||
|
|
## Requirement Change Policy
|
||
|
|
|
||
|
|
Requirements may NOT be modified without explicit approval from `_null`.
|
||
|
|
All proposed changes must include: rationale, technical impact, security implications, affected systems, rollback considerations.
|