ea4e7b56e0
9 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Cal Corum
|
fc0e2f100c |
CLAUDE: Integrate X-Check advancement with full GameState support
Updated X-Check runner advancement functions to properly delegate to existing result handlers for non-error cases. Changes: - Updated x_check_g1/g2/g3 signatures to accept GameState, hit_location, and defensive_decision parameters - Updated x_check_f1/f2/f3 signatures to accept GameState and hit_location - Implemented delegation logic: error cases use simple tables, non-error cases delegate to existing tested result handlers (_execute_result, _fb_result_*) - Updated PlayResolver._get_x_check_advancement() to pass new parameters - Updated all tests to provide required GameState fixtures Benefits: - Reuses 13 existing groundball + 4 flyball result handlers (DRY) - No DP probability needed - X-Check d20 already tested defender - Full game context: real lineup IDs, outs count, conditional logic - Error cases remain simple and efficient Test Results: 264/265 core tests passing (1 pre-existing dice failure) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> |
||
|
Cal Corum
|
fb282a5e54 |
CLAUDE: Fix critical X-Check bugs and improve dice rolling
Fixed two critical bugs in Phase 3D X-Check implementation plus improved dice audit trail for better tracking. BUG #1: on_base_code Mapping Error (Sequential vs Bit Field) ============================================================ The implementation incorrectly treated on_base_code as a bit field when it is actually a sequential lookup mapping. WRONG (bit field): Code 3 (0b011) → R1 + R2 Code 4 (0b100) → R3 only CORRECT (sequential): Code 3 → R3 only Code 4 → R1 + R2 Fixed: - build_advancement_from_code() decoder (sequential mapping) - build_flyball_advancement_with_error() decoder (sequential mapping) - 13 test on_base_code values (3↔4 corrections) - Updated documentation to clarify NOT a bit field BUG #2: Table Data Not Matching Official Charts ================================================ 7 table entries in G1_ADVANCEMENT_TABLE and G2_ADVANCEMENT_TABLE did not match the official rulebook charts provided by user. Fixed table entries: - G1 Code 1, Infield In: Changed Result 3 → 2 - G1 Code 3, Normal: Changed Result 13 → 3 - G1 Code 3, Infield In: Changed Result 3 → 1 - G1 Code 4, Normal: Changed Result 3 → 13 - G1 Code 4, Infield In: Changed Result 4 → 2 - G2 Code 3, Infield In: Changed Result 3 → 1 - G2 Code 4, Normal: Changed Result 5 → 4 Also fixed 7 test expectations to match corrected tables. IMPROVEMENT: Better Dice Audit Trail ===================================== Updated _resolve_x_check() in PlayResolver to use proper dice_system.roll_fielding() instead of manual die rolling. Benefits: - All dice tracked in audit trail (roll_id, timestamp, position) - Automatic error_total calculation (no manual 3d6 addition) - Consistent with codebase patterns - Position recorded for historical analysis Testing: - All 59 X-Check advancement tests passing (100%) - All 9 PlayResolver tests passing (100%) - All table entries validated against official charts - Complete codebase scan: no bit field operations found Files modified: - backend/app/core/x_check_advancement_tables.py - backend/tests/unit/core/test_x_check_advancement_tables.py - backend/app/core/play_resolver.py - .claude/implementation/PHASE_3D_CRITICAL_FIX.md (documentation) - .claude/implementation/GROUNDBALL_CHART_REFERENCE.md (new) - .claude/implementation/XCHECK_TEST_VALIDATION.md (new) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> |
||
|
Cal Corum
|
10515cb20d |
CLAUDE: Implement Phase 3C - X-Check Resolution Logic
Implemented complete X-Check resolution system in PlayResolver with defense range and error table lookups. Changes: - Added X_CHECK case to resolve_outcome() method - Implemented _resolve_x_check() main resolution method - Added _adjust_range_for_defensive_position() for playing in logic - Added _lookup_defense_table() for defense range table lookups - Added _apply_hash_conversion() for G2#/G3# to SI2 conversion - Added _lookup_error_chart() for error determination - Added _determine_final_x_check_outcome() for final outcome mapping - Added XCheckResult to PlayResult dataclass - Integrated all Phase 3B tables (defense, error, holding runners) Features: - Full defense table lookup (infield, outfield, catcher) - Error chart lookup with priority ordering (RP > E3 > E2 > E1 > NO) - Range adjustment for playing in (+1, max 5) - Hash conversion based on playing in OR holding runner - Error overrides outs to ERROR outcome - Rare play handling - Detailed X-Check audit trail in XCheckResult Placeholders (to be completed in later phases): - Defender retrieval from lineup (currently uses placeholder ratings) - SPD test implementation (currently defaults to G3) - Batter handedness from player model - Runner advancement tables (Phase 3D) Testing: - All 9 PlayResolver tests passing - All 36 X-Check table tests passing - All 51 runner advancement tests passing - 325/327 total tests passing (2 pre-existing failures unrelated) - play_resolver.py compiles successfully Phase 3C Status: 100% COMPLETE ✅ Ready for Phase 3D (Runner Advancement Tables) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> |
||
|
Cal Corum
|
a696473d0a |
CLAUDE: Integrate flyball advancement with RunnerAdvancement system
Major Phase 2 refactoring to consolidate runner advancement logic: **Flyball System Enhancement**: - Add FLYOUT_BQ variant (medium-shallow depth) - 4 flyball types with clear semantics: A (deep), B (medium), BQ (medium-shallow), C (shallow) - Updated helper methods to include FLYOUT_BQ **RunnerAdvancement Integration**: - Extend runner_advancement.py to handle both groundballs AND flyballs - advance_runners() routes to _advance_runners_groundball() or _advance_runners_flyball() - Comprehensive flyball logic with proper DECIDE mechanics per flyball type - No-op movements recorded for state recovery consistency **PlayResolver Refactoring**: - Consolidate all 4 flyball outcomes to delegate to RunnerAdvancement (DRY) - Eliminate duplicate flyball resolution code - Rename helpers for clarity: _advance_on_single_1/_advance_on_single_2 (was _advance_on_single) - Fix single/double advancement logic for different hit types **State Recovery Fix**: - Fix state_manager.py game recovery to build LineupPlayerState objects properly - Use get_lineup_player() helper to construct from lineup data - Correctly track runners in on_first/on_second/on_third fields (matches Phase 2 model) **Database Support**: - Add runner tracking fields to play data for accurate recovery - Include batter_id, on_first_id, on_second_id, on_third_id, and *_final fields **Type Safety Improvements**: - Fix lineup_id access throughout runner_advancement.py (was accessing on_first directly, now on_first.lineup_id) - Make current_batter_lineup_id non-optional (always set by _prepare_next_play) - Add type: ignore for known SQLAlchemy false positives **Documentation**: - Update CLAUDE.md with comprehensive flyball documentation - Add flyball types table, usage examples, and test coverage notes - Document differences between groundball and flyball mechanics **Testing**: - Add test_flyball_advancement.py with 21 flyball tests - Coverage: all 4 types, DECIDE scenarios, no-op movements, edge cases 🚀 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> |
||
|
Cal Corum
|
e2f1d6079f |
CLAUDE: Implement Week 7 Task 6 - PlayResolver Integration with RunnerAdvancement
Major Refactor: Outcome-First Architecture - PlayResolver now accepts league_id and auto_mode in constructor - Added core resolve_outcome() method - all resolution logic in one place - Added resolve_manual_play() wrapper for manual submissions (primary) - Added resolve_auto_play() wrapper for PD auto mode (rare) - Removed SimplifiedResultChart (obsolete with new architecture) - Removed play_resolver singleton RunnerAdvancement Integration: - All groundball outcomes (GROUNDBALL_A/B/C) now use RunnerAdvancement - Proper DP probability calculation with positioning modifiers - Hit location tracked for all relevant outcomes - 13 result types fully integrated from advancement charts Game State Updates: - Added auto_mode field to GameState (stored per-game) - Updated state_manager.create_game() to accept auto_mode parameter - GameEngine now uses state.auto_mode to create appropriate resolver League Configuration: - Added supports_auto_mode() to BaseGameConfig - SbaConfig: returns False (no digitized cards) - PdConfig: returns True (has digitized ratings) - PlayResolver validates auto mode support and raises error for SBA Play Results: - Added hit_location field to PlayResult - Groundballs include location from RunnerAdvancement - Flyouts track hit_location for tag-up logic (future) - Other outcomes have hit_location=None Testing: - Completely rewrote test_play_resolver.py for new architecture - 9 new tests covering initialization, strikeouts, walks, groundballs, home runs - All 9 tests passing - All 180 core tests still passing (1 pre-existing failure unrelated) Terminal Client: - No changes needed - defaults to manual mode (auto_mode=False) - Perfect for human testing of manual submissions This completes Week 7 Task 6 - the final task of Week 7! Week 7 is now 100% complete with all 8 tasks done. 🎯 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> |
||
|
Cal Corum
|
8ecce0f5ad |
CLAUDE: Implement forced outcome feature for terminal client testing
Add ability to force specific play outcomes instead of random dice rolls, enabling targeted testing of specific game scenarios. Changes: - play_resolver.resolve_play(): Add forced_outcome parameter, bypass dice rolls when provided, create dummy AbRoll with placeholder values - game_engine.resolve_play(): Accept and pass through forced_outcome param - terminal_client/commands.py: Pass forced_outcome to game engine Testing: - Verified TRIPLE, HOMERUN, and STRIKEOUT outcomes work correctly - Dummy AbRoll properly constructed with all required fields - Game state updates correctly with forced outcomes Example usage in REPL: resolve_with triple resolve_with homerun Fixes terminal client testing workflow to allow controlled scenarios. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> |
||
|
Cal Corum
|
6880b6d5ad |
CLAUDE: Complete Week 6 - granular PlayOutcome integration and metadata support
- Renamed check_d20 → chaos_d20 throughout dice system - Expanded PlayOutcome enum with granular variants (SINGLE_1/2, DOUBLE_2/3, GROUNDBALL_A/B/C, etc.) - Integrated PlayOutcome from app.config into PlayResolver - Added play_metadata support for uncapped hit tracking - Updated all tests (139/140 passing) Week 6: 100% Complete - Ready for Phase 3 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> |
||
|
Cal Corum
|
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>
|
||
|
Cal Corum
|
0d7ddbe408 |
CLAUDE: Implement GameEngine, PlayResolver, and GameValidator
Core Components: ✅ GameValidator (validators.py) - Validates game state and decisions - Rule enforcement for baseball gameplay - Game-over and inning continuation logic ✅ PlayResolver (play_resolver.py) - Resolves play outcomes using AbRoll system - Simplified result charts for MVP - Handles wild pitch/passed ball checks - Runner advancement logic for all hit types - PlayOutcome enum with 12 outcome types ✅ GameEngine (game_engine.py) - Orchestrates complete game flow - Start game, submit decisions, resolve plays - Integrates DiceSystem with roll context - Batch saves rolls at end of each half-inning - Persists plays and game state to database - Manages inning advancement and game completion Integration Features: - Uses advanced AbRoll system (not simplified d20) - Roll context tracking per inning - Batch persistence at inning boundaries - Full audit trail with roll history - State synchronization between memory and database Architecture: GameEngine → PlayResolver → DiceSystem ↓ ↓ GameValidator StateManager ↓ ↓ Database In-Memory Cache Ready For: ✅ End-to-end at-bat testing ✅ WebSocket integration ✅ Result chart configuration ✅ Advanced decision logic (Phase 3) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> |