---
phase: 09-trip-planner-modes-tdd
plan: 01
type: tdd
---

<objective>
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.
</objective>

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

<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)
</context>

<feature>
  <name>Feature 1: Timezone boundary handling for date range</name>
  <files>
    SportsTimeTests/ScenarioAPlannerSwiftTests.swift
    SportsTime/Planning/Engine/ScenarioAPlanner.swift
  </files>
  <behavior>
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.
  </behavior>
  <implementation>
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
  </implementation>
</feature>

<feature>
  <name>Feature 2: Same-day multi-city conflict detection</name>
  <files>
    SportsTimeTests/ScenarioAPlannerSwiftTests.swift
    SportsTime/Planning/Engine/ScenarioAPlanner.swift
  </files>
  <behavior>
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.
  </behavior>
  <implementation>
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.
  </implementation>
</feature>

<verification>
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)
</verification>

<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>

<output>
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
</output>