Files
Sportstime/.planning/phases/09-trip-planner-modes-tdd/09-01-PLAN.md
Trey t 0f2cf9e4af docs(09): create phase 9 plans - Trip Planner Modes TDD
Phase 09: Trip Planner Modes TDD
- 3 plans created (09-01, 09-02, 09-03)
- 29 total tests planned across all scenarios
- TDD approach: Write tests first, fix code if tests fail

Plan 09-01: Scenario A Timezone & Conflict TDD (8 tests)
- Feature 1: Timezone boundary handling for date range (4 tests)
- Feature 2: Same-day multi-city conflict detection (4 tests)

Plan 09-02: Scenario B Filler Conflict TDD (9 tests)
- Feature 1: Filler game timing conflict prevention (4 tests)
- Feature 2: Impossible geographic combination detection (5 tests)

Plan 09-03: Scenario C Corridor Efficiency TDD (12 tests)
- Feature 1: Travel corridor game inclusion (5 tests)
- Feature 2: Geographic efficiency validation / anti-backtracking (7 tests)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2026-01-10 12:43:22 -06:00

7.2 KiB

phase, plan, type
phase plan type
09-trip-planner-modes-tdd 01 tdd
Test-driven validation of Scenario A (date range planning) timezone boundary handling and same-day multi-city conflict detection.

Purpose: Ensure date range boundaries respect timezone context and detect impossible same-day games in different cities. Tests define correctness - code must match. Output: Working timezone boundary handling and conflict detection with passing TDD tests.

<execution_context> ~/.claude/get-shit-done/workflows/execute-phase.md ./summary.md </execution_context>

@.planning/PROJECT.md @.planning/ROADMAP.md @.planning/STATE.md @.planning/phases/08-dag-system-tdd/08-01-SUMMARY.md @.planning/phases/08-dag-system-tdd/08-02-SUMMARY.md @SportsTime/Planning/Engine/ScenarioAPlanner.swift @SportsTimeTests/ScenarioAPlannerSwiftTests.swift @SportsTimeTests/GameDAGRouterTests.swift

Tech stack available: Swift Testing framework, GameDAGRouter with dynamic beam scaling Established patterns: Swift Testing @Test/@Suite, TDD RED-GREEN-REFACTOR, makeStadium/makeGame/date helpers Constraining decisions:

  • Phase 08-01: Tests validate behavior via findRoutes() rather than testing internal methods directly
  • Phase 08-02: Dynamic beam width scaling for performance (800+ games use width 50)

Issues being addressed: None (new test coverage)

Feature 1: Timezone boundary handling for date range SportsTimeTests/ScenarioAPlannerSwiftTests.swift SportsTime/Planning/Engine/ScenarioAPlanner.swift Test cases for date range timezone boundary correctness:

Case 1: Game at range start in different timezone (included)

  • Date range: Jan 5 00:00 PST to Jan 10 23:59 PST
  • Game: Jan 5 19:00 EST (New York) = Jan 5 16:00 PST
  • Expected: Game included (within PST range)

Case 2: Game just before range start in different timezone (excluded)

  • Date range: Jan 5 00:00 PST to Jan 10 23:59 PST
  • Game: Jan 4 22:00 EST (New York) = Jan 4 19:00 PST
  • Expected: Game excluded (before PST range start)

Case 3: Game at range end in different timezone (included)

  • Date range: Jan 5 00:00 PST to Jan 10 23:59 PST
  • Game: Jan 10 21:00 EST (New York) = Jan 10 18:00 PST
  • Expected: Game included (within PST range)

Case 4: Game just after range end in different timezone (excluded)

  • Date range: Jan 5 00:00 PST to Jan 10 23:59 PST
  • Game: Jan 11 02:00 EST (New York) = Jan 10 23:00 PST
  • Expected: Game excluded (after PST range end when converted)

Note: DateInterval.contains() handles Date correctly across timezones - verify it works as expected. If tests fail due to timezone conversion issues:

  1. Verify DateInterval uses absolute Date comparison (it should)
  2. Check game.startTime is constructed in correct timezone
  3. Ensure date range boundaries are interpreted in user's timezone (not UTC)
  4. Fix ScenarioAPlanner filtering logic if needed
Feature 2: Same-day multi-city conflict detection SportsTimeTests/ScenarioAPlannerSwiftTests.swift SportsTime/Planning/Engine/ScenarioAPlanner.swift Test cases for impossible same-day game scheduling:

Case 1: Same-day games in cities <4 hours apart (feasible)

  • LA game at 1pm, San Diego game at 7pm (120 miles, 2hr drive)
  • Expected: Both games in route (enough time to drive between)

Case 2: Same-day games in distant cities (infeasible)

  • LA game at 1pm, San Francisco game at 7pm (380 miles, 6hr drive)
  • Expected: Route picks ONE game (cannot attend both same day)

Case 3: Same-day games in opposite coasts (obviously infeasible)

  • LA game at 1pm, New York game at 7pm EST (2800 miles)
  • Expected: Route picks ONE game (impossible same day)

Case 4: Three same-day games, two feasible combinations

  • LA 1pm, Anaheim 4pm (30mi), San Diego 7pm (90mi from Anaheim)
  • Expected: Route includes LA→Anaheim→SD OR picks best option
  • Constraint: Cannot include NY game on same day

Current behavior: GameDAGRouter.canTransition() checks time/distance feasibility. Tests verify routes respect these constraints when multiple same-day options exist. If tests fail:

  1. GameDAGRouter.canTransition() may need to check calendar day conflicts
  2. ScenarioAPlanner may need to pre-filter impossible same-day combinations
  3. RouteFilters may need same-day conflict detection
  4. Fix the appropriate layer (likely GameDAGRouter or ScenarioAPlanner)

Do NOT weaken test assertions - fix the code to match expected behavior.

All tests pass: ```bash xcodebuild -project SportsTime.xcodeproj -scheme SportsTime \ -destination 'platform=iOS Simulator,name=iPhone 17,OS=26.2' \ -only-testing:SportsTimeTests/ScenarioAPlannerSwiftTests test ```

Specific tests to verify:

  • Timezone boundary tests: 4 new tests (range start/end, before/after, cross-timezone)
  • Same-day conflict tests: 4 new tests (feasible close, infeasible far, opposite coasts, three-game selection)

<success_criteria>

  • 8 new tests added to ScenarioAPlannerSwiftTests.swift
  • All tests follow TDD pattern (RED → GREEN → REFACTOR)
  • Each feature produces 2-3 commits (test, feat, optional refactor)
  • No test assertions weakened
  • All existing tests continue to pass
  • Tests use existing helper patterns (makeStadium, makeGame, date) </success_criteria>
After completion, create `.planning/phases/09-trip-planner-modes-tdd/09-01-SUMMARY.md`:

Phase 09 Plan 01: Scenario A Timezone & Conflict TDD Summary

[Substantive one-liner - what shipped, not "phase complete"]

Performance

  • Duration: [actual time]
  • Started: [timestamp]
  • Completed: [timestamp]

Accomplishments

Feature 1: Timezone Boundary Handling

  • RED: [What tests were written, expected failures]
  • GREEN: [What code changes made tests pass, or "tests passed on first run"]
  • REFACTOR: [Cleanup done, or "no refactor needed"]

Feature 2: Same-Day Multi-City Conflicts

  • RED: [What tests were written, expected failures]
  • GREEN: [What code changes made tests pass, or "tests passed on first run"]
  • REFACTOR: [Cleanup done, or "no refactor needed"]

Task Commits

List of commits produced (2-3 per feature):

  1. test(09-01): add timezone boundary tests for date range filtering
  2. feat(09-01): fix timezone handling in ScenarioAPlanner (if needed)
  3. test(09-01): add same-day multi-city conflict tests
  4. feat(09-01): add conflict detection to ScenarioAPlanner (if needed)

Files Created/Modified

  • SportsTimeTests/ScenarioAPlannerSwiftTests.swift - Added 8 tests
  • SportsTime/Planning/Engine/ScenarioAPlanner.swift - [describe changes, or "no changes - tests passed"]

Decisions Made

[Key decisions and rationale, or "None - tests validated existing behavior"]

Deviations from Plan

Auto-fixed Issues

[Any blocking issues fixed during execution, or "None"]

Deferred Enhancements

[Any issues logged to ISSUES.md, or "None"]

Issues Encountered

[Problems and resolutions, or "None"]

Next Phase Readiness

  • Scenario A timezone and conflict handling validated
  • Ready for Plan 09-02: Scenario B Filler Conflict TDD
  • No blockers