This commit captures work from multiple sessions building the statistics system and frontend component library. Backend - Phase 3.5: Statistics System - Box score statistics with materialized views - Play stat calculator for real-time updates - Stat view refresher service - Alembic migration for materialized views - Test coverage: 41 new tests (all passing) Frontend - Phase F1: Foundation - Composables: useGameState, useGameActions, useWebSocket - Type definitions and interfaces - Store setup with Pinia Frontend - Phase F2: Game Display - ScoreBoard, GameBoard, CurrentSituation, PlayByPlay components - Demo page at /demo Frontend - Phase F3: Decision Inputs - DefensiveSetup, OffensiveApproach, StolenBaseInputs components - DecisionPanel orchestration - Demo page at /demo-decisions - Test coverage: 213 tests passing Frontend - Phase F4: Dice & Manual Outcome - DiceRoller component - ManualOutcomeEntry with validation - PlayResult display - GameplayPanel orchestration - Demo page at /demo-gameplay - Test coverage: 119 tests passing Frontend - Phase F5: Substitutions - PinchHitterSelector, DefensiveReplacementSelector, PitchingChangeSelector - SubstitutionPanel with tab navigation - Demo page at /demo-substitutions - Test coverage: 114 tests passing Documentation: - PHASE_3_5_HANDOFF.md - Statistics system handoff - PHASE_F2_COMPLETE.md - Game display completion - Frontend phase planning docs - NEXT_SESSION.md updated for Phase F6 Configuration: - Package updates (Nuxt 4 fixes) - Tailwind config enhancements - Game store updates Test Status: - Backend: 731/731 passing (100%) - Frontend: 446/446 passing (100%) - Total: 1,177 tests passing Next Phase: F6 - Integration (wire all components into game page) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
5.6 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
- Player action → WebSocket → Backend
- Validate against in-memory state
- Process + resolve outcome
- Update in-memory state
- Async write to PostgreSQL
- 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:
- Authentication (Discord OAuth)
- Game creation & lobby
- Complete turn-based gameplay with all strategic decisions
- Real-time WebSocket updates
- Game persistence & recovery
- Spectator mode
- Mobile-optimized UI
- 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
Current Implementation Status
Phase 3E-Final: ✅ COMPLETE (2025-01-10)
Backend is production-ready for frontend integration:
- ✅ All 15 WebSocket event handlers implemented
- ✅ Strategic decisions (defensive/offensive)
- ✅ Manual outcome workflow (dice rolling + card reading)
- ✅ Player substitutions (3 types)
- ✅ Box score statistics (materialized views)
- ✅ Position ratings integration (PD league)
- ✅ 730/731 tests passing (99.9%)
Next Phase: Vue 3 + Nuxt 3 frontend implementation with Socket.io client
Note: Subdirectories have their own CLAUDE.md files with implementation-specific details to minimize context usage.