---
name: sql-lesson
description: Produce or continue a SQL bootcamp lesson for dinotable, or review Zoha's submitted SQL/ERD work. Use when Zoha asks for the next SQL lesson, help with a SQL exercise, or review of schema/query work.
---

# dinotable SQL bootcamp

Curriculum: the 8-lesson outline in `docs/design/system-design.md` §16
(tables/constraints → joins → normalization → indexes/EXPLAIN → transactions
→ locking → window functions/CTEs → migrations discipline). Lessons live in
`docs/sql-bootcamp/lesson-N-<slug>.md`.

## Two modes

**Lesson mode** (default when asked for "the next lesson"):

1. Check `docs/sql-bootcamp/` for existing lessons; continue the sequence.
2. Every exercise uses the dinotable domain — Users, Restaurants, Branches,
   Tables, ServicePeriods, Slots, Reservations. Never use generic
   employees/departments examples.
3. Lesson structure:
   - **Concept** — the idea and the real problem it solves in this project
   - **Setup** — exact commands; a throwaway dockerized Postgres 16
     (`docker run --rm -e POSTGRES_PASSWORD=dev -p 5432:5432 postgres:16`
     plus `psql` via `docker exec`) so lessons work before the repo has any
     code. No installs on the host.
   - **Guided exploration** — queries to type and observe, with expected output
   - **Exercises** — 3–6, escalating difficulty, each framed as a real
     dinotable need ("the host needs tonight's reservations ordered by slot…")
   - **Solutions** — in a separate `lesson-N-solutions.md`, not inline.
     The lesson ends with: attempt everything before opening solutions.
4. Lessons 5 and 6 (transactions, locking) must include "break it on
   purpose": two concurrent psql sessions racing for the same slot, observing
   the anomaly, then fixing it.

**Review mode** (when Zoha shares SQL, a schema, or an ERD):

- Review like a senior reviewing a promising junior: ask questions before
  giving answers ("what happens if two rows have the same phone?" rather than
  "add a unique constraint").
- Point out what's *right* explicitly — calibration is part of teaching.
- Escalate: question → hint → concrete fix. Full corrected SQL only after
  Zoha has had a real attempt.
- Check the things juniors miss: constraint coverage, NULL semantics, index
  vs. query-shape mismatch, implicit assumptions about time zones.

Never write schema/migration files into the workspace (`apps/`, `libs/`) —
all SQL lives in lesson docs until Zoha carries it into the project during a
milestone.