The-transit-Project/handoff.md

Session Handoff

Goal: Make schedules work correctly across recurring and one-time events, with accurate per-day status/progress in the API and calendar views in the admin UI.

Current Status:

• transit_api/index.js now materializes recurring schedules into concrete occurrences for /schedules/overview.
• transit.schedule_stop_progress is now occurrence-aware via scheduled_passed_date; the API backfills old rows and writes/reads stop progress per date.
• The API check passed with node --check transit_api/index.js.
• The admin UI still needs to be wired to use the range-aware overview endpoint in its calendar data source.

Important Context:

• The schedule template lives in the database as a row with weekdays; recurring events are not stored as separate rows.
• The backend should be the source of truth for date-specific materialization and live progress/status.
• Key files: transit_api/index.js, admin_ui/src/components/ScheduleMaker.jsx, transit_api/README.md.
• The admin UI build already succeeded earlier with npm --prefix admin_ui run build.

Decisions Already Made:

• Recurring schedules are materialized on read instead of creating one DB row per occurrence. This keeps the DB simple and makes the calendar/date-range API deterministic.
• Progress must be keyed by occurrence date, not only by schedule id and stop order, otherwise a recurring schedule reuses yesterday’s stop state.
• /schedules/overview should support both single-date and date-range requests so month/week views can render all relevant occurrences with one call.

What to Avoid:

• Do not treat recurring schedules as a single mutable live schedule row for progress/status.
• Do not reuse the old schedule_id + stop_order uniqueness for stop progress.
• Avoid reworking unrelated API routes or admin screens unless they block the calendar flow.

Open Questions or Blockers:

• The admin UI calendar source still needs to be confirmed and wired to call /schedules/overview?fromDate=...&toDate=....
• If the admin calendar view expects a different event shape, map the overview response there rather than changing the backend again.

Next Best Step:

1. Inspect the calendar/timetable code path in admin_ui/src/components/ScheduleMaker.jsx and any adjacent component that renders the calendar range.
2. Wire that view to request /schedules/overview with fromDate and toDate.
3. Map returned schedules into calendar events and surface the current status/progress fields.
4. Run a focused admin UI build to confirm the change compiles.

How to Respond:

• Start by summarizing the current state in one short paragraph.
• Continue from the existing implementation instead of re-discovering the schedule model.
• If anything critical is missing, ask only the minimum question needed to proceed.