# FamilyDashboard morning routine countdown + admin day-detail editor

Use when the FamilyDashboard morning status card / `Loslaufen in ...` timer needs to guide children through the pre-school routine, or when Admin must edit per-day routine timing around the timetable.

## UX/product pattern

- Model the morning countdown as **two phases**, not a single departure countdown:
  1. Before teeth/WC/shoes start: large card says `Zähneputzen in X Min.` and `remaining_minutes` points to the teeth start.
  2. From teeth/WC/shoes start until departure: large card says `Loslaufen in X Min.` and `remaining_minutes` points to `leave_home`.
- Default relationship: teeth/WC/shoes starts **10 minutes before Loslaufen**, but make it configurable per child/day.
- Keep the timeline range `teeth_shoes` from `teeth_start` to `leave_home`, then `leave_home` to `school_start`.
- Keep later departure targets distinct (`nextDepartureTime`, `minutesUntilNextDeparture`) so the morning card never accidentally counts down to lunch/afternoon/external activity.
- In copy, use child-friendly German: `Zähneputzen`, `Zähne / WC / Schuhe – dann los`, `Danach: Loslaufen in 10 Min.`

## Data/API pattern

- Add a per-child/per-ISO-weekday routine table, e.g. `RoutineDaySetting`:
  - `child_id`, `weekday` unique
  - optional `wake_time`
  - optional/configurable `teeth_start`
  - `leave_countdown_minutes` default 10
  - `timer_hooks` string such as `10,3`
  - `notes`, `active`, `updated_at`
- Include routine settings in `GET /api/schedule/current` as `routine_settings` so the Admin timetable editor can open without an extra round trip.
- Add PIN-protected Admin CRUD/upsert endpoint, e.g. `PUT /api/admin/schedule-routines`.
- Apply the routine in `child_timeline()` before building the morning timeline:
  - routine `wake_time` overrides the default/wake heuristic for that child/day.
  - routine `teeth_start` overrides computed `leave_home - leave_countdown_minutes`.
  - fallback teeth start should be near `leave_home - 10`, while preserving legacy minimums when needed.

## Admin UI pattern

- Keep the Admin editor integrated with the existing Stundenplan grid.
- Make the **day header clickable** (`Montag`, `Dienstag`, …) and label it `Details`.
- Clicking a day opens a modal for that weekday, with one card per child:
  - Aufstehen optional
  - Zähneputzen ab
  - Minuten bis Loslaufen
  - Timer-Hooks / Warnungen (`10,3`)
  - Notiz
  - aktiv/inaktiv
- Continue to let block cards edit school/external schedule blocks, and empty cells create blocks. Day header = routine/day detail; cells = timetable blocks.
- Invalidate schedule/admin schedule/dashboard queries after saving routine details.

## Regression tests

Add/adjust backend tests so they prove:

- Morning before teeth start returns `primaryMessage == "Zähneputzen in N Min."` and `remaining_minutes == N`.
- Morning after teeth start but before departure returns `primaryMessage == "Loslaufen in N Min."` and `remaining_minutes == N`.
- `nextDepartureTime` / `minutesUntilNextDeparture` can still point to later lunch/afternoon events, but does not control morning `remaining_minutes`.
- `morningTeethStart` and `minutesUntilTeeth` are exposed for client/debug visibility.

## Verification checklist

- Back up production SQLite before schema/API changes.
- Run narrow dashboard/schedule backend tests in the backend container.
- Run frontend `npm run build` / typecheck because schedule types and Admin TSX usually change together.
- Rebuild/deploy without `down -v`; verify `/api/health` and frontend HTTP 200.