Investigate missing rehearsal days in people/schedule data (possible API refactor regression)

[jakebodea]

Summary

Rehearsal-only engagement days appear to be missing or under-reported compared to a few commits ago. Unclear whether the regression is in the Planning Center people API response, schedule/history hydration, or UI grouping—needs a bisect and a quick contract check.

Suspected timeframe / commits to review

Likely candidates from recent history (backend / people API / schedule work):

• 4712614 — Harden schedule frequency, people API perf, and PC tooling docs
• 1486300 — Use Planning Center org timezone for scheduling and slim people API
• 93cabe1 — Align schedule counts with history window and polish person card
• 926b34b / 7f9984c — Normalize Planning Center roster hydration

Where to look in code

• History + classification: lib/use-cases/planning-center/people/history.ts (timeType rehearsal vs service, recentRehearsalOnlyDays, upcomingRehearsals)
• API shape + defaults: people route(s) under app/api/ that assemble person payloads; compare serialized frequency fields to lib/types.ts / hooks/use-schedule-history.ts defaults
• Schedule load / includes: lib/planning-center/schedule-load-constants.ts (comment mentions parity with recentRehearsalOnlyDays)
• UI: lib/use-cases/planning-center/people/service-history-display.ts, components/schedule/schedule-candidate-tile.tsx (rehearsal counts / grouped rows)

How to confirm

1. Pick a person with known rehearsal-only plan times in PC; note expected distinct rehearsal days in the org TZ window.
2. Inspect API JSON for recentRehearsalOnlyDays, upcomingRehearsals, serviceHistory entries with timeType: "rehearsal".
3. Bisect from a known-good commit if behavior diverges before it hits the client.

Done when

Root cause is identified (data dropped in API vs never requested from PC vs UI filtering), fixed, and covered by a regression test if the bug was in transforms or serialization.