# ATC Mock Integration Plan

## Purpose
- Keep Ballbox implementation moving while real ATC access is still pending.

## Rule
- Do not fake a production integration.
- Build stable boundaries and mock data flows so the product can evolve without blocking on credentials.
- Treat mocks as a bridge toward a likely `read+write` ATC integration, not as justification for a permanently read-only product.

## Recommended Approach

### 1. Define an ATC client boundary
- one internal interface for:
  - sportclubs
  - courts
  - availability
  - bookings
  - optionally players

### 2. Provide two implementations
- `mockAtcClient`
- future `realAtcClient`

### 3. Keep Ballbox product logic behind that boundary
- do not spread ATC-shaped payloads across the app
- map into Ballbox-local domain objects early

### 4. Use feature flags or environment-based selection
- local/dev: mock
- real integration env: real client

## What Mocks Should Cover
- list clubs
- list courts
- simple availability snapshots
- simple booking records
- representative edge cases:
  - no availability
  - stale booking data
  - overlap conflict
  - permission/access failure

## What This Enables
- UI and workflow prototyping
- domain mapping decisions
- product review without live credentials
- easier switch to real API later

## Commercial/Product Note
- Current Ballbox direction is to prefer ATC `read+write` for the real sellable workflow when evidence and access support it.
- A mock or read-only phase is acceptable as a temporary technical step, but likely weak as the end-user value proposition if coaches still need to complete key actions elsewhere.

## What This Does Not Prove
- real ATC data quality
- real auth flow
- real permissions
- real latency/failure patterns

## Next Technical Step
- once a wedge is chosen, define the exact minimum ATC client surface needed for that loop before touching implementation