mikkel/pokertrip
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
pokertrip/docs/gsd-kickoff.md
Mikkel Georgsen fef6f5318e Initial project docs — design spec, reference JSX, and GSD kickoff 
Personal poker tracker: Go + React + PostgreSQL PWA for tracking
home sessions and poker trips with AI-powered schedule research.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-18 09:36:56 +00:00

3.5 KiB
Raw Blame History

PokerTrip — GSD Kickoff Prompt

Project

Build PokerTrip, a personal poker tournament tracker as a PWA. Go backend + React frontend + PostgreSQL.

Key Documents

Read these before planning:

  1. Design spec: docs/2026-03-18-pokertrip-design.md — the full architecture, data model, API design, frontend layout, AI research system, and tech stack. This is the source of truth.
  2. Manila JSX reference: docs/manila-poker-tracker.jsx — a working React component for a Manila poker trip tracker. Use as UI/UX reference for the trip mode experience (card layout, action buttons, status flow, budget display, Catppuccin Mocha theming). The data is hardcoded here — in the real app it comes from the database.
  3. SaaS considerations: docs/saas-considerations.md — a checklist of things to add when going multi-tenant. Don't build these now, but make architectural choices that don't block them later (user-scoped data, storage interface abstraction, etc.).

Tech Stack

  • Backend: Go, Chi (router), pgx (Postgres driver), sqlc (codegen), goose (migrations), River (Postgres-backed job queue), golang-jwt, bcrypt
  • Frontend: React + TypeScript, Vite, Tailwind CSS (Catppuccin Mocha palette), Framer Motion, Recharts, Workbox (PWA), Zustand or Jotai (state)
  • Database: PostgreSQL at 10.5.0.109:5432/pokertrip (credentials in .env)
  • AI: OpenAI-compatible endpoint (OpenRouter/Requesty), self-hosted SearXNG for web search
  • Deploy: Single Go binary with embedded React frontend via embed.FS

What To Build

The design spec covers everything in detail, but the major systems are:

  1. Database schema + migrations — all tables from the data model section
  2. Auth — email/password, JWT access + refresh tokens, user-scoped queries
  3. Venues — CRUD, public/private visibility, venue profiles (per-user day-of-week defaults)
  4. Sessions — the core: create, status transitions, re-entries (with tilt guard data), end session, filtering
  5. Trips — CRUD, budget tracking, link to location schedules
  6. Tournament snapshots — image upload, vision model OCR extraction, stack tracking
  7. AI research system — River job, OpenAI-compatible client with tool-use (SearXNG search, URL fetch, image analysis), SSE progress streaming, review/refine/approve flow
  8. Global events scraper — nightly River job, Hendon Mob etc.
  9. Frontend mobile cockpit — Home/Trip toggle, fast session entry, action buttons, tilt guard modal, snapshot camera
  10. Frontend desktop dashboard — session history with filters, trip explorer, stats/charts, venue management, settings (AI config, model picker)
  11. PWA — manifest, service worker, offline support, optimistic sync

Architecture Principles

  • Every write is fire-and-forget from the client (202 Accepted, River processes async)
  • UI is always optimistic — never wait for DB confirmation
  • All data is user-scoped (ready for multi-tenant)
  • Storage interface abstraction (local filesystem now, S3-compatible later)
  • Separate model settings for research (powerful) vs. snapshot OCR (cheap/fast)
  • Shared tournament knowledge is anonymized and give-to-get (must run own research to access community data)

User Context

The user (Mikkel) does not code — Claude builds everything. He plays poker tournaments ad-hoc in Denmark and plans trips abroad a few times a year. Mobile UX is critical — he'll use this at the poker table. Desktop is for analysis and trip planning at home.