Every screen of the Timetable module, its intent, route, composition, states,
permissions, platform behaviour and events. Authoritative components in
00-shared/03; this file enumerates which ones each screen uses with module
specifics. The weekly grid is the hero component — see 06 §S1 and 07 §A1.
no roomId filter exists (timetable.controller.ts:22-25) → client merges GET /timetable?classId= responses for classes using the room; native filter (planned) (IMPLEMENTATION_PLAN.md:226)
Surface the single server conflict rule: teacher or room double-booking on the same day with overlapping time (timetable.service.ts:16-30,62-69)
Trigger
409 from POST /timetable; also local pre-flight warnings before submit (races possible — server authoritative)
Placement
inside S4, above the submit button
Actions
dismiss; "Change time/teacher/room" (focus related picker)
Copy
timetable.conflict.teacher / timetable.conflict.room — one generic server message ("Schedule conflict detected", timetable.service.ts:28) mapped to the specific pre-flight cause
WeekNavigator (07 §A7): ‹ today › offset −1..0..+n (forward-looking: weekly shift) — pure client state, no server concept of "week"; entries are weekly-recurring by model (timetable.schema.ts:30-37 stores weekday + time only, no date)
Note
The backend has no date dimension — week navigation merely re-filters the same 6-day data; push notifications for "class in 15 min" (forward-looking) would need a new date-aware model