strat-gameplay-webapp/CLAUDE.md
Cal Corum 5c75b935f0 CLAUDE: Initial project setup - documentation and infrastructure
Add comprehensive project documentation and Docker infrastructure for
Paper Dynasty Real-Time Game Engine - a web-based multiplayer baseball
simulation platform replacing the legacy Google Sheets system.

Documentation Added:
- Complete PRD (Product Requirements Document)
- Project README with dual development workflows
- Implementation guide with 5-phase roadmap
- Architecture docs (backend, frontend, database, WebSocket)
- CLAUDE.md context files for each major directory

Infrastructure Added:
- Root docker-compose.yml for full stack orchestration
- Dockerfiles for backend and both frontends (multi-stage builds)
- .dockerignore files for optimal build context
- .env.example with all required configuration
- Updated .gitignore for Python, Node, Nuxt, and Docker

Project Structure:
- backend/ - FastAPI + Socket.io game engine (Python 3.11+)
- frontend-sba/ - SBA League Nuxt 3 frontend
- frontend-pd/ - PD League Nuxt 3 frontend
- .claude/implementation/ - Detailed implementation guides

Supports two development workflows:
1. Local dev (recommended): Services run natively with hot-reload
2. Full Docker: One-command stack orchestration for testing/demos

Next: Phase 1 implementation (backend/frontend foundations)
2025-10-21 16:21:13 -05:00

5.0 KiB

🚨 CRITICAL: @ MENTION HANDLING 🚨

When ANY file is mentioned with @ syntax, you MUST IMMEDIATELY call Read tool on that file BEFORE responding. You will see automatic loads of any @ mentioned filed, this is NOT ENOUGH, it only loads the file contents. You MUST perform Read tool calls on the files directly, even if they were @ included. This is NOT optional - it loads required CLAUDE.md context. along the file path. See @./.claude/force-claude-reads.md for details.


Paper Dynasty Real-Time Game Engine - Development Guide

Project Overview

Web-based real-time multiplayer baseball simulation platform replacing legacy Google Sheets system. Consists of:

  • Shared Backend: FastAPI (Python 3.11+) with WebSocket support, PostgreSQL persistence
  • Dual Frontends: Separate Vue 3/Nuxt 3 apps per league (SBA and PD) with shared component library

Critical Business Driver: Legacy Google Sheets being deprecated - this is mission-critical replacement.

Architecture Principles

Backend Philosophy

  • Hybrid State Model: In-memory game state for performance + PostgreSQL for persistence/recovery
  • League-Agnostic Core: Polymorphic player models, config-driven league variations
  • Async-First: All I/O operations use async/await patterns
  • Type Safety: Pydantic models for validation, SQLAlchemy for ORM

Frontend Philosophy

  • Mobile-First: Primary design target is mobile portrait mode
  • Real-Time Updates: WebSocket (Socket.io) for all game state changes
  • Shared Components: Maximize reuse between league frontends
  • Type Safety: TypeScript with strict mode

Technology Stack

Backend

  • FastAPI + Socket.io (WebSocket)
  • PostgreSQL 14+ with SQLAlchemy 2.0
  • Pydantic for data validation
  • pytest for testing

Frontend (Per League)

  • Vue 3 Composition API + Nuxt 3
  • TypeScript (strict mode)
  • Tailwind CSS
  • Pinia for state management
  • Socket.io-client
  • @nuxtjs/auth-next (Discord OAuth)

Key Technical Patterns

Polymorphic Player Architecture

Use factory pattern for league-specific player types:

  • BasePlayer (abstract base)
  • SbaPlayer (simple model)
  • PdPlayer (detailed scouting data)
  • Lineup.from_api_data(config, data) factory method

WebSocket Event Flow

  1. Player action → WebSocket → Backend
  2. Validate against in-memory state
  3. Process + resolve outcome
  4. Update in-memory state
  5. Async write to PostgreSQL
  6. Broadcast state update to all clients

Game State Recovery

On reconnect: Load plays from DB → Replay to rebuild state → Send current state

Project Structure

strat-gameplay-webapp/
├── backend/              # FastAPI game engine
│   ├── app/
│   │   ├── core/         # Game engine, dice, state management
│   │   ├── config/       # League configs and result charts
│   │   ├── websocket/    # Socket.io handlers
│   │   ├── models/       # Pydantic + SQLAlchemy models
│   │   └── api/          # REST endpoints
│   └── tests/
├── frontend-sba/         # SBA League Nuxt app
├── frontend-pd/          # PD League Nuxt app
└── shared-components/    # Shared Vue components (optional)

Development Guidelines

Code Quality

  • Python: Dataclasses preferred, rotating loggers with f'{__name__}.<className>'
  • Error Handling: "Raise or Return" pattern - no Optional unless required
  • Testing: Run tests freely without asking permission
  • Imports: Always verify imports during code review to prevent NameErrors
  • Git Commits: Prefix with "CLAUDE: "

Performance Targets

  • Action response: < 500ms
  • WebSocket delivery: < 200ms
  • DB writes: < 100ms (async)
  • State recovery: < 2 seconds

Security Requirements

  • Discord OAuth for authentication
  • Server-side game logic only (zero client trust)
  • Cryptographically secure dice rolls
  • All rules enforced server-side

Phase 1 MVP Scope (Weeks 1-13)

Core Deliverables:

  1. Authentication (Discord OAuth)
  2. Game creation & lobby
  3. Complete turn-based gameplay with all strategic decisions
  4. Real-time WebSocket updates
  5. Game persistence & recovery
  6. Spectator mode
  7. Mobile-optimized UI
  8. AI opponent support

Explicitly Out of Scope for MVP:

  • Roster management
  • Marketplace
  • Tournaments
  • Advanced analytics

Critical References

  • Full PRD: /mnt/NV2/Development/strat-gameplay-webapp/prd-web-scorecard-1.1.md
  • Player Model Architecture: PRD lines 378-551
  • Database Schema: PRD lines 553-628
  • WebSocket Events: PRD lines 630-669
  • League Config System: PRD lines 780-846

League Differences

SBA League

  • Minimal player data (id, name, image)
  • Simpler rules configuration

PD League

  • Detailed scouting data on players
  • Complex probability calculations
  • Additional analytics requirements

Success Metrics

  • 90% player migration within 1 month
  • 99.5% uptime
  • < 500ms average action latency
  • 60%+ mobile usage
  • Zero data corruption

Note: Subdirectories will have their own CLAUDE.md files with implementation-specific details to minimize context usage.