Day 11 — the calendar that has to work

Spent today on something that sounds simple and isn't: recurring lessons.

The naive version is "create a slot, copy it 10 weeks forward." That's wrong for at least three reasons. Trainers go on vacation, so the schedule needs to pause and resume without losing the thread. They want to extend "one more month" without touching anything individually. And clients book against the live instance, so a recurring template's children have to behave like first-class slots — bookable, cancellable, no-showable, with their own attendance history — but still trace back to the recurring rule in case something needs to change at the rule level.

The shape I landed on: a recurring_slot_templates table that defines the rule (day of week, time, level, capacity, ring, lesson type, rates), and a generator that materializes individual lesson_slots rows from that template up to a configurable horizon. Pause is just a flag on the template that the generator respects. Extend is "advance the horizon and re-run the generator." Materialized rows are the source of truth for bookings; the template is just the recipe.

The piece I keep going back and forth on is what happens when a trainer edits the template after slots have already materialized. Edit just future occurrences? Edit all unbooked? Force a confirmation? Today's answer: edits propagate to future-not-yet-materialized only. Already-materialized slots stay frozen unless explicitly bulk-edited. That makes the data model boring (each slot is a real row with real state) at the cost of one workflow seam — which I think is the right tradeoff, but I'm leaving a TODO in case the first real trainer hates it.

Calendar grid view is starting to take shape too — color-coded by level, week view on desktop, day list on mobile. Trainers in the wild check schedules at 6:30 a.m. on a phone in the truck. That view has to load instantly. It does.