ee94fcfa96
6 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
9245b4e008 |
CLAUDE: Implement Week 7 Task 3 - Result chart abstraction and PD auto mode
Core Implementation: - Added ResultChart abstract base class with get_outcome() method - Implemented calculate_hit_location() helper for hit distribution - 45% pull, 35% center, 20% opposite field - RHB pulls left, LHB pulls right - Groundballs → infield positions, flyouts → outfield positions - Added PlayOutcome.requires_hit_location() helper method - Returns True for groundballs and flyouts only Manual Mode Support: - Added ManualResultChart (passthrough for interface completeness) - Manual mode doesn't use result charts - players submit directly - Added ManualOutcomeSubmission model for WebSocket submissions - Validates PlayOutcome enum values - Validates hit location positions (1B, 2B, SS, 3B, LF, CF, RF, P, C) PD Auto Mode Implementation: - Implemented PdAutoResultChart for automated outcome generation - Coin flip (50/50) to choose batting or pitching card - Gets rating for correct handedness matchup - Builds cumulative distribution from rating percentages - Rolls 1d100 to select outcome - Calculates hit location using handedness and pull rates - Maps rating fields to PlayOutcome enum: - Common: homerun, triple, doubles, singles, walks, strikeouts - Batting-specific: lineouts, popouts, flyout variants, groundout variants - Pitching-specific: uncapped singles/doubles, flyouts by location - Proper error handling when card data missing Testing: - Created 21 comprehensive unit tests (all passing) - Helper function tests (calculate_hit_location) - PlayOutcome helper tests (requires_hit_location) - ManualResultChart tests (NotImplementedError) - PdAutoResultChart tests: - Coin flip distribution (~50/50) - Handedness matchup selection - Cumulative distribution building - Outcome selection from probabilities - Hit location calculation - Error handling for missing cards - Statistical distribution verification (1000 trials) - ManualOutcomeSubmission validation tests - Valid/invalid outcomes - Valid/invalid hit locations - Optional location handling Deferred to Future Tasks: - PlayResolver integration (Phase 6 - Week 7 Task 3B) - Terminal client manual outcome command (Phase 8) - WebSocket handlers for manual submissions (Week 7 Task 6) - Runner advancement logic using hit locations (Week 7 Task 4) Files Modified: - app/config/result_charts.py: Added base class, auto mode, and helpers - app/models/game_models.py: Added ManualOutcomeSubmission model - tests/unit/config/test_result_charts.py: 21 comprehensive tests All tests passing, no regressions. |
||
|
|
c0051d2a65 |
CLAUDE: Fix defensive decision validation for corners_in/infield_in depths
- Updated validators.py to use is_runner_on_third() helper method instead of hardcoded on_base_code values - Fixed DefensiveDecision Pydantic model: infield depths now ['infield_in', 'normal', 'corners_in'] - Fixed DefensiveDecision Pydantic model: outfield depths now ['in', 'normal'] (removed 'back') - Removed invalid double_play depth tests (depth doesn't exist) - Added proper tests for corners_in and infield_in validation (requires runner on third) - All 54 validator tests now passing Changes maintain consistency between Pydantic validation and GameValidator logic. |
||
|
|
95d8703f56 |
CLAUDE: Implement Week 7 Task 1 - Strategic Decision Integration
Enhanced game engine with async decision workflow and AI opponent integration: GameState Model Enhancements: - Added pending_defensive_decision and pending_offensive_decision fields - Added decision_phase tracking (idle, awaiting_defensive, awaiting_offensive, resolving, completed) - Added decision_deadline field for timeout handling - Added is_batting_team_ai() and is_fielding_team_ai() helper methods - Added validator for decision_phase StateManager Enhancements: - Added _pending_decisions dict for asyncio.Future-based decision queue - Added set_pending_decision() to create decision futures - Added await_decision() to wait for decision submission - Added submit_decision() to resolve pending futures - Added cancel_pending_decision() for cleanup GameEngine Enhancements: - Added await_defensive_decision() with AI/human branching and timeout - Added await_offensive_decision() with AI/human branching and timeout - Enhanced submit_defensive_decision() to resolve pending futures - Enhanced submit_offensive_decision() to resolve pending futures - Added DECISION_TIMEOUT constant (30 seconds) AI Opponent (Stub): - Created ai_opponent.py with stub implementations - generate_defensive_decision() returns default "normal" positioning - generate_offensive_decision() returns default "normal" approach - TODO markers for Week 9 full AI logic implementation Integration: - Backward compatible with existing terminal client workflow - New async methods ready for WebSocket integration (Week 7 Task 4) - AI teams get instant decisions, human teams wait with timeout - Default decisions applied on timeout (no game blocking) Testing: - Config tests: 58/58 passing ✅ - Terminal client: Working perfectly ✅ - Existing workflows: Fully compatible ✅ Week 7 Task 1: Complete Next: Task 2 - Decision Validators 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> |
||
|
|
1c32787195 |
CLAUDE: Refactor game models and modularize terminal client
This commit includes cleanup from model refactoring and terminal client
modularization for better code organization and maintainability.
## Game Models Refactor
**Removed RunnerState class:**
- Eliminated separate RunnerState model (was redundant)
- Replaced runners: List[RunnerState] with direct base references:
- on_first: Optional[LineupPlayerState]
- on_second: Optional[LineupPlayerState]
- on_third: Optional[LineupPlayerState]
- Updated helper methods:
- get_runner_at_base() now returns LineupPlayerState directly
- get_all_runners() returns List[Tuple[int, LineupPlayerState]]
- is_runner_on_X() simplified to direct None checks
**Benefits:**
- Matches database structure (plays table has on_first_id, etc.)
- Simpler state management (direct references vs list management)
- Better type safety (LineupPlayerState vs generic runner)
- Easier to work with in game engine logic
**Updated files:**
- app/models/game_models.py - Removed RunnerState, updated GameState
- app/core/play_resolver.py - Use get_all_runners() instead of state.runners
- app/core/validators.py - Updated runner access patterns
- tests/unit/models/test_game_models.py - Updated test assertions
- tests/unit/core/test_play_resolver.py - Updated test data
- tests/unit/core/test_validators.py - Updated test data
## Terminal Client Refactor
**Modularization (DRY principle):**
Created separate modules for better code organization:
1. **terminal_client/commands.py** (10,243 bytes)
- Shared command functions for game operations
- Used by both CLI (main.py) and REPL (repl.py)
- Functions: submit_defensive_decision, submit_offensive_decision,
resolve_play, quick_play_sequence
- Single source of truth for command logic
2. **terminal_client/arg_parser.py** (7,280 bytes)
- Centralized argument parsing and validation
- Handles defensive/offensive decision arguments
- Validates formats (alignment, depths, hold runners, steal attempts)
3. **terminal_client/completions.py** (10,357 bytes)
- TAB completion support for REPL mode
- Command completions, option completions, dynamic completions
- Game ID completions, defensive/offensive option suggestions
4. **terminal_client/help_text.py** (10,839 bytes)
- Centralized help text and command documentation
- Detailed command descriptions
- Usage examples for all commands
**Updated main modules:**
- terminal_client/main.py - Simplified by using shared commands module
- terminal_client/repl.py - Cleaner with shared functions and completions
**Benefits:**
- DRY: Behavior consistent between CLI and REPL modes
- Maintainability: Changes in one place affect both interfaces
- Testability: Can test commands module independently
- Organization: Clear separation of concerns
## Documentation
**New files:**
- app/models/visual_model_relationships.md
- Visual documentation of model relationships
- Helps understand data flow between models
- terminal_client/update_docs/ (6 phase documentation files)
- Phased documentation for terminal client evolution
- Historical context for implementation decisions
## Tests
**New test files:**
- tests/unit/terminal_client/__init__.py
- tests/unit/terminal_client/test_arg_parser.py
- tests/unit/terminal_client/test_commands.py
- tests/unit/terminal_client/test_completions.py
- tests/unit/terminal_client/test_help_text.py
**Updated tests:**
- Integration tests updated for new runner model
- Unit tests updated for model changes
- All tests passing with new structure
## Summary
- ✅ Simplified game state model (removed RunnerState)
- ✅ Better alignment with database structure
- ✅ Modularized terminal client (DRY principle)
- ✅ Shared command logic between CLI and REPL
- ✅ Comprehensive test coverage
- ✅ Improved documentation
Total changes: 26 files modified/created
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
|
||
|
|
13e924a87c |
CLAUDE: Refactor GameEngine to forward-looking play tracking pattern
Replaced awkward "lookback" pattern with clean "prepare → execute → save" orchestration that captures state snapshots BEFORE each play. Key improvements: - Added per-team batter indices (away_team_batter_idx, home_team_batter_idx) - Added play snapshot fields (current_batter/pitcher/catcher_lineup_id) - Added on_base_code bit field for efficient base situation queries - Created _prepare_next_play() method for snapshot preparation - Refactored start_game() with hard lineup validation requirement - Refactored resolve_play() with explicit 6-step orchestration - Updated _save_play_to_db() to use snapshots (no DB lookbacks) - Enhanced state recovery to rebuild from last play (single query) - Added defensive lineup position validator Benefits: - No special cases for first play - Single source of truth in GameState - Saves 18+ database queries per game - Fast state recovery without replay - Complete runner tracking (before/after positions) - Explicit orchestration (easy to debug) Testing: - Added 3 new test functions (lineup validation, snapshot tracking, batting order) - All 5 test suites passing (100%) - Type checking cleaned up with targeted suppressions for SQLAlchemy Documentation: - Added comprehensive "Type Checking & Common False Positives" section to CLAUDE.md - Created type-checking-guide.md and type-checking-summary.md - Added mypy.ini configuration for SQLAlchemy/Pydantic 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> |
||
|
|
a287784328 |
CLAUDE: Complete Week 4 - State Management & Persistence
Implemented hybrid state management system with in-memory game states and async PostgreSQL persistence. This provides the foundation for fast gameplay (<500ms response) with complete state recovery capabilities. ## Components Implemented ### Production Code (3 files, 1,150 lines) - app/models/game_models.py (492 lines) - Pydantic GameState with 20+ helper methods - RunnerState, LineupPlayerState, TeamLineupState - DefensiveDecision and OffensiveDecision models - Full Pydantic v2 validation with field validators - app/core/state_manager.py (296 lines) - In-memory state management with O(1) lookups - State recovery from database - Idle game eviction mechanism - Statistics tracking - app/database/operations.py (362 lines) - Async PostgreSQL operations - Game, lineup, and play persistence - Complete state loading for recovery - GameSession WebSocket state tracking ### Tests (4 files, 1,963 lines, 115 tests) - tests/unit/models/test_game_models.py (60 tests, ALL PASSING) - tests/unit/core/test_state_manager.py (26 tests, ALL PASSING) - tests/integration/database/test_operations.py (21 tests) - tests/integration/test_state_persistence.py (8 tests) - pytest.ini (async test configuration) ### Documentation (6 files) - backend/CLAUDE.md (updated with Week 4 patterns) - .claude/implementation/02-week4-state-management.md (marked complete) - .claude/status-2025-10-22-0113.md (planning session summary) - .claude/status-2025-10-22-1147.md (implementation session summary) - .claude/implementation/player-data-catalog.md (player data reference) - Week 5 & 6 plans created ## Key Features - Hybrid state: in-memory (fast) + PostgreSQL (persistent) - O(1) state access via dictionary lookups - Async database writes (non-blocking) - Complete state recovery from database - Pydantic validation on all models - Helper methods for common game operations - Idle game eviction with configurable timeout - 86 unit tests passing (100%) ## Performance - State access: O(1) via UUID lookup - Memory per game: ~1KB (just state) - Target response time: <500ms ✅ - Database writes: <100ms (async) ✅ ## Testing - Unit tests: 86/86 passing (100%) - Integration tests: 29 written - Test configuration: pytest.ini created - Fixed Pydantic v2 config deprecation - Fixed pytest-asyncio configuration 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> |