Coaching eligibility evaluates Central evening availability against the UTC calendar day
Why
Sales reproduced a production eligibility mismatch for Jack Allred (coa_5aa0e8bc-dbdc-4509-84af-c5d75aae8cde) while constructing a Dallas offer at Legacy Gardens. Coaching's authoritative profile shows Jack active, covering the requested service area, with an active Thursday availability template from 15:00 through 20:00 in America/Chicago and no availability exception on July 30, 2026.
The broad Coaching availability read correctly materializes that Thursday band as 2026-07-30T20:00:00Z through 2026-07-31T01:00:00Z. However, eligibility-by-description rejects the final hour, 19:00 through 20:00 Central, as no_band.
Production evidence
Sales queried the same organization, coach, service area, ZIP, and certification shape across two adjacent one-hour windows:
| Requested local window | UTC window | Coaching result for Jack |
|---|---|---|
| Thursday 18:00 through 19:00 Central | 2026-07-30T23:00:00Z through 2026-07-31T00:00:00Z |
Eligible, free, capacity 1 |
| Thursday 19:00 through 20:00 Central | 2026-07-31T00:00:00Z through 2026-07-31T01:00:00Z |
Ineligible, no_band, capacity 0 |
The eligibility result changes exactly when the requested start crosses midnight UTC, even though both windows are inside the same Thursday 15:00 through 20:00 Central template.
Sales traced the mismatch to coaching/modules/availability/service.ts. evaluateCoach derives the candidate day with dayStart(opts.lessonStart), and computeDaysForCoach matches templates with date.getUTCDay(). For the 19:00 Central request, the UTC instant is Friday, so Coaching materializes Friday's local template instead of Thursday's local template. The generated Friday interval starts many hours after the requested instant and the band-fit predicate returns false.
Past lesson start times are valid inputs for the Sales operator workflow. Please preserve that behavior. This memo is about local-calendar evaluation, not adding a future-only validation rule.
Ask
Please correct Coaching's eligibility band evaluation so recurring templates are selected by the template's local calendar date and timezone, not by the UTC weekday of lesson_start.
The implementation should also use local-day boundaries when applying availability exceptions, active bookings, and travel buffers. A narrow timestamp shift in Sales or a special case for Central time would not be acceptable because it would make consumer behavior timezone-dependent and would leave exception filtering incorrect around UTC midnight.
Please add regression coverage for the reproduced Thursday 19:00 through 20:00 Central window, the adjacent 18:00 through 19:00 window, an out-of-band 20:00 through 21:00 window, overnight templates, and daylight-saving boundaries. After deployment, please reply on this thread with the Coaching commit, focused test results, and a production eligibility read showing Jack eligible for the reproduced in-band window.
No contract change appears necessary. ADR-0018 and coach-availability v2 already define continuous availability bands in local template time; this is an implementation defect against that behavior.
References
- ADR-0018:
adrs/ADR-0018-continuous-availability-bands-and-lesson-projection.md - Coach availability v2:
contracts/coach-availability/README.v2.md - Coaching eligibility service:
coaching/modules/availability/service.ts - Sales consumer:
sales/lib/coaching/eligibility-client.ts - Sales Workbench renderer:
sales/app/workbench/_components/AvailabilityPlannerDrawer.tsx