Initial project setup: PROJECT.md, STRUCTURE.md, FUTURE.md, HISTORY.md, project-requirements.md
This commit is contained in:
parent
2f43f63c5c
commit
2677febe03
|
|
@ -0,0 +1,96 @@
|
||||||
|
# Relationship App — Planning
|
||||||
|
|
||||||
|
## Phase 1 — Foundation & Infrastructure (1.0.x)
|
||||||
|
|
||||||
|
### Batch 1.0.1: Expo Project Bootstrap (Scarlett)
|
||||||
|
- Initialize Expo project with TypeScript template
|
||||||
|
- Configure ESLint + Prettier
|
||||||
|
- Create folder architecture (app/, components/, lib/, constants/, assets/)
|
||||||
|
- Configure app entry points (app/_layout.tsx, app/index.tsx)
|
||||||
|
- Verify: `npx expo start` runs clean
|
||||||
|
|
||||||
|
### Batch 1.0.2: Navigation Foundation (Scarlett)
|
||||||
|
- Install and configure Expo Router
|
||||||
|
- Create tab layout with placeholder tabs (Home, Questions, Milestones, Settings)
|
||||||
|
- Create stack layout for detail screens
|
||||||
|
- Verify: navigation between tabs and stacks works
|
||||||
|
|
||||||
|
### Batch 1.0.3: Supabase Project Setup (Neo)
|
||||||
|
- Create Supabase project (or document connection to existing)
|
||||||
|
- Configure environment variables (.env.local, .env.example)
|
||||||
|
- Create Supabase client in lib/supabase.ts
|
||||||
|
- Create lib/supabase.ts with init and auth helpers
|
||||||
|
- Verify: client connects to Supabase instance, health check passes
|
||||||
|
|
||||||
|
### Batch 1.0.4: Database Schema — Users & Couples (Neo)
|
||||||
|
- Create `profiles` table (id, email, display_name, avatar_url, created_at)
|
||||||
|
- Create `couples` table (id, partner1_id, partner2_id, created_at)
|
||||||
|
- Create `couple_members` table (id, couple_id, user_id, joined_at)
|
||||||
|
- Row Level Security on all tables
|
||||||
|
- Verify: can insert/select with proper RLS, cross-couple isolation works
|
||||||
|
|
||||||
|
### Batch 1.0.5: Auth — Magic Link Email (Neo)
|
||||||
|
- Configure Supabase Auth for email magic links
|
||||||
|
- Auth hook: useAuth() with session state
|
||||||
|
- Protected route wrapper component
|
||||||
|
- Logout handling
|
||||||
|
- Verify: magic link flow works end-to-end
|
||||||
|
|
||||||
|
### Batch 1.0.6: Auth UI — Login Screen (Scarlett)
|
||||||
|
- Login screen with email input + "Send Magic Link" button
|
||||||
|
- Loading state, success message, error state
|
||||||
|
- Deep link handling for magic link redirect
|
||||||
|
- Verify: user can request and receive magic link, redirect works
|
||||||
|
|
||||||
|
### Batch 1.0.7: Pairing — Code Generation (Neo)
|
||||||
|
- Generate unique 6-character pair codes
|
||||||
|
- `pair_codes` table (id, code, creator_id, status, expires_at, created_at)
|
||||||
|
- API: create pair code, expire old codes
|
||||||
|
- RLS: only creator can generate, only partner can claim
|
||||||
|
- Verify: code generation works, uniqueness constraint, expiration works
|
||||||
|
|
||||||
|
### Batch 1.0.8: Pairing — Join Flow (Neo)
|
||||||
|
- Claim pair code endpoint
|
||||||
|
- Couple creation logic on successful claim
|
||||||
|
- RLS: couple_members only visible to members
|
||||||
|
- Verify: two users can pair, couple created correctly
|
||||||
|
|
||||||
|
### Batch 1.0.9: Pairing UI — Enter Code Screen (Scarlett)
|
||||||
|
- "Share Your Code" screen showing generated code with copy button
|
||||||
|
- "Enter Partner's Code" screen with input + submit
|
||||||
|
- Paired state screen showing partner info
|
||||||
|
- Loading/success/error states throughout
|
||||||
|
- Verify: full pairing flow works on device
|
||||||
|
|
||||||
|
### Batch 1.0.10: Design System — Theme & Tokens (Scarlett)
|
||||||
|
- Create constants/Colors.ts with warm color palette
|
||||||
|
- Create constants/Spacing.ts with spacing scale
|
||||||
|
- Create constants/Typography.ts with font sizes/weights
|
||||||
|
- NativeWind config extending Tailwind theme with custom tokens
|
||||||
|
- Dark mode color tokens
|
||||||
|
- Verify: tokens render correctly in both modes
|
||||||
|
|
||||||
|
### Batch 1.0.11: Design System — Base Components (Scarlett)
|
||||||
|
- Button component (variants: primary, secondary, ghost; sizes: sm, md, lg)
|
||||||
|
- Input component (text input with label, error state)
|
||||||
|
- Card component (with header, body, footer)
|
||||||
|
- Avatar component (with fallback initials)
|
||||||
|
- Verify: all components render in light/dark mode
|
||||||
|
|
||||||
|
### Batch 1.0.12: Home Screen (Scarlett)
|
||||||
|
- Home screen layout with greeting, daily question card, quick actions
|
||||||
|
- Navigation to question packs
|
||||||
|
- Warm, calm aesthetic matching design philosophy
|
||||||
|
- Verify: home screen renders with placeholder data
|
||||||
|
|
||||||
|
## Phase 2 — Core Question Engine (1.1.x)
|
||||||
|
*(Planned — not yet broken into batches)*
|
||||||
|
|
||||||
|
## Phase 3 — Milestones & Memories (1.2.x)
|
||||||
|
*(Planned — not yet broken into batches)*
|
||||||
|
|
||||||
|
## Phase 4 — Messaging & Notifications (1.3.x)
|
||||||
|
*(Planned — not yet broken into batches)*
|
||||||
|
|
||||||
|
## Phase 5 — Polish & Launch Prep (1.4.x)
|
||||||
|
*(Planned — not yet broken into batches)*
|
||||||
|
|
@ -0,0 +1,9 @@
|
||||||
|
# Relationship App — Changelog
|
||||||
|
|
||||||
|
## v1.0.0 — Phase 1 Foundation Baseline — 2026-05-13
|
||||||
|
|
||||||
|
### Project Setup
|
||||||
|
- Initialized project structure (PROJECT.md, STRUCTURE.md, FUTURE.md, project-requirements.md)
|
||||||
|
- Execution plan rewritten with small batch sizing per BATCH_SIZING.md rules
|
||||||
|
- Phase 1 broken into 12 focused batches (1.0.1 through 1.0.12)
|
||||||
|
- Agent pipeline: Scarlett → Neo → Bishop → Private_Hudson as needed
|
||||||
|
|
@ -0,0 +1,53 @@
|
||||||
|
# Relationship App — Couples Connection
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
Project: Relationship App (Couples Connection)
|
||||||
|
Created: 2026-05-13
|
||||||
|
Status: Active (Phase 1 - Foundation & Infrastructure - 1.0.x)
|
||||||
|
Build Phase: 1 (Foundation & Infrastructure)
|
||||||
|
|
||||||
|
## Description
|
||||||
|
A mobile app designed to help couples build a deeper emotional connection through meaningful interaction, guided conversations, and personal moments. Built with React Native + Expo for iOS and Android.
|
||||||
|
|
||||||
|
## Tech Stack
|
||||||
|
- **React Native** — mobile framework (cross-platform: iOS + Android)
|
||||||
|
- **Expo** — development platform and build tooling
|
||||||
|
- **TypeScript** — type safety
|
||||||
|
- **NativeWind** — Tailwind CSS for React Native
|
||||||
|
- **Supabase** — Auth, Database (PostgreSQL), Realtime, Storage
|
||||||
|
- **Cloudflare R2** — media storage
|
||||||
|
- **Expo Push Notifications** — push alerts
|
||||||
|
- **shadcn/ui-style** — component primitives adapted for mobile
|
||||||
|
|
||||||
|
## Directory Structure (Phase 1 target)
|
||||||
|
- `app/` — Expo Router screens and layouts
|
||||||
|
- `components/` — Reusable UI components
|
||||||
|
- `lib/` — Utilities, hooks, Supabase client
|
||||||
|
- `constants/` — Theme, colors, spacing
|
||||||
|
- `assets/` — Images, fonts
|
||||||
|
- `supabase/` — Migrations and config (if using CLI)
|
||||||
|
|
||||||
|
## Git
|
||||||
|
- **Branch:** `dev` (working), `main` (stable)
|
||||||
|
- **Remote:** `ssh://forgejo/null/relationship-app.git`
|
||||||
|
|
||||||
|
## Versioning
|
||||||
|
Version numbers correlate to the active phase:
|
||||||
|
- Phase 1: `1.0.x` (foundation, bootstrap, auth)
|
||||||
|
- Phase 2: `1.1.x` (core question engine)
|
||||||
|
- Phase 3: `1.2.x` (milestones & memories)
|
||||||
|
- Phase 4: `1.3.x` (messaging & notifications)
|
||||||
|
- Phase 5: `1.4.x` (polish & launch prep)
|
||||||
|
|
||||||
|
## Phase Completion Git Rule
|
||||||
|
Push to `dev` after every completed and verified batch.
|
||||||
|
- Agents do not touch git.
|
||||||
|
- Bishop verifies and updates docs.
|
||||||
|
- Ripley performs final checks, commits, and pushes to `dev`.
|
||||||
|
|
||||||
|
## Conventions
|
||||||
|
- Follow AGENTS.md for agent dispatch protocol
|
||||||
|
- All agents read project-requirements.md before starting tasks
|
||||||
|
- Ripley owns git — no agent touches git directly
|
||||||
|
- See BATCH_SIZING.md for batch sizing rules (one focused task per batch)
|
||||||
|
- NOT Next.js. NOT a web app. This is React Native + Expo.
|
||||||
|
|
@ -0,0 +1,102 @@
|
||||||
|
# Relationship App — Structure
|
||||||
|
|
||||||
|
## Agent Roles
|
||||||
|
|
||||||
|
| Area | Owner | Notes |
|
||||||
|
|------|-------|-------|
|
||||||
|
| Backend, Supabase, Auth, DB, RLS | Neo | All server-side work |
|
||||||
|
| UI, Mobile UX, NativeWind, Design System | Scarlett | All visual/interaction work |
|
||||||
|
| QA, Testing, Build Verification | Bishop | Verify everything works |
|
||||||
|
| Security Review, Content, Moderation | Private_Hudson | Security-first features |
|
||||||
|
| Coordination, Git, Deployment | Ripley | Orchestrates pipeline |
|
||||||
|
|
||||||
|
## Phase 1 — Foundation & Infrastructure (1.0.x)
|
||||||
|
|
||||||
|
Batches follow the rule: **one focused task per batch, one agent, one pass.**
|
||||||
|
|
||||||
|
### Batch 1.0.1: Expo Project Bootstrap (Scarlett)
|
||||||
|
- Initialize Expo project with TypeScript template
|
||||||
|
- Configure ESLint + Prettier
|
||||||
|
- Create folder architecture (app/, components/, lib/, constants/, assets/)
|
||||||
|
- Configure app entry points (app/_layout.tsx, app/index.tsx)
|
||||||
|
- Verify: `npx expo start` runs clean
|
||||||
|
|
||||||
|
### Batch 1.0.2: Navigation Foundation (Scarlett)
|
||||||
|
- Install and configure Expo Router
|
||||||
|
- Create tab layout with placeholder tabs (Home, Questions, Milestones, Settings)
|
||||||
|
- Create stack layout for detail screens
|
||||||
|
- Verify: navigation between tabs and stacks works
|
||||||
|
|
||||||
|
### Batch 1.0.3: Supabase Project Setup (Neo)
|
||||||
|
- Create Supabase project (or document connection to existing)
|
||||||
|
- Configure environment variables (.env.local, .env.example)
|
||||||
|
- Create Supabase client in lib/supabase.ts
|
||||||
|
- Create lib/supabase.ts with init and auth helpers
|
||||||
|
- Verify: client connects to Supabase instance, health check passes
|
||||||
|
|
||||||
|
### Batch 1.0.4: Database Schema — Users & Couples (Neo)
|
||||||
|
- Create `profiles` table (id, email, display_name, avatar_url, created_at)
|
||||||
|
- Create `couples` table (id, partner1_id, partner2_id, created_at)
|
||||||
|
- Create `couple_members` table (id, couple_id, user_id, joined_at)
|
||||||
|
- Row Level Security on all tables
|
||||||
|
- Verify: can insert/select with proper RLS, cross-couple isolation works
|
||||||
|
|
||||||
|
### Batch 1.0.5: Auth — Magic Link Email (Neo)
|
||||||
|
- Configure Supabase Auth for email magic links
|
||||||
|
- Auth hook: useAuth() with session state
|
||||||
|
- Protected route wrapper component
|
||||||
|
- Logout handling
|
||||||
|
- Verify: magic link flow works end-to-end
|
||||||
|
|
||||||
|
### Batch 1.0.6: Auth UI — Login Screen (Scarlett)
|
||||||
|
- Login screen with email input + "Send Magic Link" button
|
||||||
|
- Loading state, success message, error state
|
||||||
|
- Deep link handling for magic link redirect
|
||||||
|
- Verify: user can request and receive magic link, redirect works
|
||||||
|
|
||||||
|
### Batch 1.0.7: Pairing — Code Generation (Neo)
|
||||||
|
- Generate unique 6-character pair codes
|
||||||
|
- `pair_codes` table (id, code, creator_id, status, expires_at, created_at)
|
||||||
|
- API: create pair code, expire old codes
|
||||||
|
- RLS: only creator can generate, only partner can claim
|
||||||
|
- Verify: code generation works, uniqueness constraint, expiration works
|
||||||
|
|
||||||
|
### Batch 1.0.8: Pairing — Join Flow (Neo)
|
||||||
|
- Claim pair code endpoint
|
||||||
|
- Couple creation logic on successful claim
|
||||||
|
- RLS: couple_members only visible to members
|
||||||
|
- Verify: two users can pair, couple created correctly
|
||||||
|
|
||||||
|
### Batch 1.0.9: Pairing UI — Enter Code Screen (Scarlett)
|
||||||
|
- "Share Your Code" screen showing generated code with copy button
|
||||||
|
- "Enter Partner's Code" screen with input + submit
|
||||||
|
- Paired state screen showing partner info
|
||||||
|
- Loading/success/error states throughout
|
||||||
|
- Verify: full pairing flow works on device
|
||||||
|
|
||||||
|
### Batch 1.0.10: Design System — Theme & Tokens (Scarlett)
|
||||||
|
- Create constants/Colors.ts with warm color palette
|
||||||
|
- Create constants/Spacing.ts with spacing scale
|
||||||
|
- Create constants/Typography.ts with font sizes/weights
|
||||||
|
- NativeWind config extending Tailwind theme with custom tokens
|
||||||
|
- Dark mode color tokens
|
||||||
|
- Verify: tokens render correctly in both modes
|
||||||
|
|
||||||
|
### Batch 1.0.11: Design System — Base Components (Scarlett)
|
||||||
|
- Button component (variants: primary, secondary, ghost; sizes: sm, md, lg)
|
||||||
|
- Input component (text input with label, error state)
|
||||||
|
- Card component (with header, body, footer)
|
||||||
|
- Avatar component (with fallback initials)
|
||||||
|
- Verify: all components render in light/dark mode
|
||||||
|
|
||||||
|
### Batch 1.0.12: Home Screen (Scarlett)
|
||||||
|
- Home screen layout with greeting, daily question card, quick actions
|
||||||
|
- Navigation to question packs
|
||||||
|
- Warm, calm aesthetic matching design philosophy
|
||||||
|
- Verify: home screen renders with placeholder data
|
||||||
|
|
||||||
|
## Cross-Cutting Concerns
|
||||||
|
|
||||||
|
- **Security**: Private_Hudson reviews auth, pairing, and RLS before Phase 2
|
||||||
|
- **Testing**: Bishop verifies each batch with build + runtime check
|
||||||
|
- **Documentation**: Bishop updates docs after each verified batch
|
||||||
|
|
@ -0,0 +1,77 @@
|
||||||
|
# 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.
|
||||||
Loading…
Reference in New Issue