/**
 * When true, the bookings domain is served by the in-memory mock (`apis/mockApi.ts`) behind the
 * `BookingsApi` seam.
 *
 * **Mock is primary this phase.** The b9 endpoints are fully specified in swagger, but a booking only
 * exists after `bookings/convert` runs against an `accepted_awaiting_payment` **request** that was paid —
 * and both upstreams are not real on the client yet: `services/bookingRequests` is mock-primary
 * (f7, `USE_BOOKING_REQUESTS_MOCK`) and card capture (b10) isn't wired. So a real `bookings/list` would
 * return nothing to render. The mock seeds confirmed bookings + sessions + care + EVV and drives the
 * check-in/out state machine so the timeline/session/banner transitions demo end-to-end. The real
 * `clientApi` maps the routes 1:1; flip to `false` once conversion (b10) is live client-side — a single
 * config change, no hook/component edits (see `dev/shared-working-context/reports/frontend-phase-8-report.md`).
 */
export const USE_BOOKINGS_MOCK = false;

/**
 * The booking detail changes on status transitions (payment → confirmed → in_progress → completed) and
 * on EVV mutations. Keep the stale window modest and **invalidate on every EVV mutation** so the timeline
 * reflects server truth immediately rather than waiting it out.
 */
export const BOOKING_DETAIL_STALE_TIME = 30 * 1000;
export const BOOKING_DETAIL_GC_TIME = 5 * 60 * 1000;

/** The bookings list changes only on new conversions/transitions — a short stale window is plenty. */
export const BOOKING_LIST_STALE_TIME = 30 * 1000;

/** A nurse's "today" feed changes as they clock in/out — kept fresh, invalidated on every EVV mutation. */
export const TODAY_SESSIONS_STALE_TIME = 15 * 1000;

/** Per-session EVV detail is immutable once completed; a short window covers the checked-in interval. */
export const SESSION_EVV_STALE_TIME = 15 * 1000;

/** Care instructions are effectively static per booking (edited rarely by the customer) — session-cached. */
export const CARE_INSTRUCTIONS_STALE_TIME = 5 * 60 * 1000;

/** api-conventions default page size; a bookings/today page. */
export const BOOKINGS_PAGE_SIZE = 20;

/**
 * EVV GPS capture mode for the `ILocationProvider` seam (`evv/locationProvider.ts`).
 *
 *  - `off`        → the **real** browser Geolocation provider.
 *  - `in_range`   → mock returns coordinates that fall inside the seeded booking's tolerance (match `true`).
 *  - `out_of_range` → mock returns far coordinates (advisory match `false`).
 *  - `denied`     → mock returns `null` (permission denied / unavailable) — the nurse still checks in.
 *
 * Default: while the bookings domain is mock-primary, real browser GPS would never fall near the seeded
 * Tehran address, so the happy path defaults to `in_range` so «موقعیت تایید شد» is demoable out of the box.
 * Override with `NEXT_PUBLIC_EVV_MOCK_GPS`; set to `off` (or flip `USE_BOOKINGS_MOCK`) for real capture.
 */
export type EvvGpsMode = 'off' | 'in_range' | 'out_of_range' | 'denied';

export const EVV_GPS_MODE: EvvGpsMode =
  (process.env.NEXT_PUBLIC_EVV_MOCK_GPS as EvvGpsMode | undefined) ?? (USE_BOOKINGS_MOCK ? 'in_range' : 'off');

/**
 * The seeded booking's reference location + advisory tolerance, shared by the mock `ILocationProvider`
 * (its `in_range` coords sit on this point) and the mock `BookingsApi` (it computes the advisory
 * `checkInAddressMatch` against this point). Real address-match math lives server-side behind the
 * backend geocoding seam — this is mock-only. A Tehran (Saadat-Abad) point, matching the seeded address.
 */
export const MOCK_EVV_REFERENCE_LAT = 35.7869;
export const MOCK_EVV_REFERENCE_LNG = 51.3699;
export const MOCK_EVV_TOLERANCE_METERS = 150;
