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

156 lines
5.0 KiB
Markdown

# 🚨 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.