• Why It Exists
• Game Highlights
• Tech Stack
• Getting Started
• Architecture Snapshot
• Project Layout
• Shoutouts

• 🎯 Showcase of full-stack Flutter + FastAPI work
• 🧠 Space to practice product thinking, not just TODO apps
• 🧑‍🤝‍🧑 Built for my Survivor group so we can talk trash each week

• ✅ Weekly picks with no-repeat rules and instant eliminations
• 📊 Live leaderboards powered by cached pick availability
• 🧭 Pool owners control their seasons, contestants, and eliminations
• 🔄 Season data is treated as TV canon and reused across every pool

• Flutter for a single codebase across web and mobile
• FastAPI service with JWT auth, routing, and CORS baked in
• MongoDB schema built for immutable TV facts plus fast leaderboards
• Docker Compose plus mise tasks (with uv for backend deps) to launch everything quickly

# install tool versions from mise.toml
mise install

# install project dependencies
mise run bootstrap

# run everything (MongoDB + backend + frontend) inside tmux
mise run start

# or drive services individually
mise run mongo
mise run backend
mise run frontend

• Default Flutter target is iOS, but you can switch with flutter run -d web-server or any connected device.
• mise run bootstrap wires up Flutter packages and uses uv to sync backend requirements.
• mise attach drops you into the dev tmux session; mise run stop shuts everything down cleanly.

• .env.dev and .env.prod live in the repo root and only carry backend settings (Mongo URL, DB name, CORS rule).
• The backend task in mise.toml loads .env.dev, so mise run backend (and mise run start, which shells into that task) get their env from that file; other tasks run clean.
• mise run prod delegates to Docker Compose, whose backend service references .env.prod through env_file, so production containers read the same values.
• don't put secrets in frontend

• 🎨 Frontend: Flutter app lives in frontend/survivor_pool, designed mobile-first with web support.
• ⚙️ Backend: FastAPI service (backend/src) coordinates game rules, picks, and pool logic.
• 🗃️ Database: MongoDB holds normalized pool data while seasons stay immutable inside a single document (db/init/init.js).
• 🔌 APIs: REST endpoints grouped by domain (pools, picks, seasons, users) with strict CORS configuration.

Whenever I want AI to extend the static Survivor data, this prompt nails the next week's events:

I have the information of survivor events in db/init/init.js up through week x of season __. I'd like you to add the events for week y. Make sure to get all eliminations, tribe changes, and advantages. Use fetch mcp. Double check yourself to make sure the data is accurate. Use sources like [Survivor Wiki](https://survivor.fandom.com/) or [Survivor recaps, reviews, data, and records](https://www.truedorktimes.com/)

.
├── frontend/          # Flutter application
├── backend/           # FastAPI service and routers
├── db/init/           # Mongo seed scripts and season canon data
├── docs/              # PRD + database design notes
└── scripts/           # Dev utilities (tmux, Mongo shell helpers)

• 🙌 Thanks to my Survivor crew for the constant feature requests.
• 📺 Inspired by the real show format—every twist keeps the product fun.