Sven laptop
40 lines
2.8 KiB
Markdown
40 lines
2.8 KiB
Markdown
# 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. |