roosterwijs/PLAN.md

# Plan – Roostersoftware Speciaal Onderwijs

Modulair, flexibel roostersysteem voor het speciaal onderwijs. Kleine aantallen, veel flexibiliteit per leerling, groep, subgroep, leerkracht en ondersteuner.

## 1. Uitgangspunten

- **Type**: webapplicatie (browser, werkt op pc en tablet).
- **Bouw**: Claude bouwt het leeuwendeel; jij stuurt, test en geeft richting.
- **MVP-focus**: (1) basisroostering, (2) flexibiliteit & uitzonderingen, (3) conflictdetectie.
- **Schaal**: één school, kleine aantallen — dus eenvoud boven complexe infrastructuur, maar het datamodel moet de flexibiliteit echt aankunnen.

## 2. Kernidee: het rooster als bouwstenen

De kracht voor speciaal onderwijs zit in *modulariteit*. In plaats van één vast groepsrooster bouwen we het rooster op uit losse **roosterblokken** die je aan wie dan ook kunt koppelen. Een blok = "wie doet wat, wanneer, waar, met wie".

Een blok kan toegewezen worden aan:

- een hele **groep**,
- een **subgroep** (deel van een groep),
- een **individuele leerling** (afwijking van het groepsrooster),
- met daaraan gekoppeld één of meer **leerkrachten** en/of **ondersteuners**.

Het rooster van een individuele leerling is dan: het groepsrooster **plus/min** zijn persoonlijke uitzonderingen. Zo houd je kleine aantallen overzichtelijk én volledig flexibel.

## 3. Datamodel (de modules)

Onafhankelijke, herbruikbare entiteiten:

- **Persoon** – basis voor leerling, leerkracht, ondersteuner (één tabel, met rol/type).
  - Leerling: hoort bij een groep, kan in subgroepen zitten.
  - Leerkracht / Praktijkondersteuner / Klassenondersteuner: inzetbaarheid, beschikbaarheid.
- **Groep** – klas; bevat leerlingen.
- **Subgroep** – flexibele deelverzameling van leerlingen (bv. niveaugroepje rekenen), kan groep-overstijgend zijn.
- **Activiteit/Vak** – wat er gedaan wordt (rekenen, gym, therapie, pauze…).
- **Locatie** – lokaal/ruimte (optioneel maar handig voor conflictdetectie).
- **Tijdslot** – dag + begin/eindtijd. We werken met **vaste schooltijden** (een instelbaar dagritme), maar tijdslots blijven aanpasbaar.
- **Roosterblok** – de spil: koppelt activiteit + tijdslot + doelgroep (groep/subgroep/leerling) + begeleiders + locatie.
- **Uitzondering** – afwijking voor een individu of dag (afwezigheid, vervanging, eenmalige wijziging).
- **Schooljaar / Kalender** – jaaroverzicht met studiedagen, vrije dagen en vakanties. Een vrije/vakantiedag schakelt automatisch de roosterblokken op die dag uit, zodat het weekrooster en het jaaroverzicht altijd kloppen.

Modulair betekent: elke entiteit staat los en is later uitbreidbaar (bv. ouders, vervoer, doelen/handelingsplan) zonder de kern te herbouwen.

## 4. Conflictdetectie

Bij het plaatsen/wijzigen van een blok controleert het systeem automatisch op:

- **Dubbele inzet leerkracht/ondersteuner** – staat iemand op twee plekken tegelijk.
- **Dubbele inzet leerling** – zit een leerling in twee blokken op hetzelfde moment.
- **Locatiebotsing** – twee blokken in dezelfde ruimte tegelijk.
- **Onderbezetting** – blok zonder begeleider (waarschuwing, niet blokkerend).

Conflicten tonen we als duidelijke waarschuwingen; jij beslist of het mag.

## 5. Technische opzet

- **Backend**: Django (Python) met Django REST Framework. Django's **"apps"** vormen ons modulesysteem: elke functie is een losse, in-/uitschakelbare app.
- **Frontend**: React – het roosterraster en de schermen.
- **Database**: SQLite om te starten (geen serverbeheer); later 1-op-1 te upgraden naar PostgreSQL.
- **Auth/rechten**: Django's ingebouwde gebruikers- en rechtensysteem (basis aanwezig, volledig uitgerold in de multi-user-module).
- **Draaien**: lokaal te starten; later te hosten op een eenvoudige server of clouddienst.

## 5b. Modulaire architectuur — een echt plugin-framework (verkoopargument)

Modulariteit is een **verkoopargument**: een school koopt de kern en schakelt naar wens modules bij. Modules moeten daarom écht aan/uit te zetten zijn — niet alleen nette code, maar instelbaar per school via een beheerscherm.

**Het plugin-framework (onderdeel van de kern):**

- **Moduleregister** – elke module meldt zichzelf aan met naam, beschrijving, versie en afhankelijkheden.
- **Aan/uit per school** – een beheerder zet modules in een **beheerscherm** in of uit; uitgeschakelde modules zijn onzichtbaar (geen menu's, geen schermen, geen API).
- **Vaste aanhechtpunten (hooks)** – de kern biedt nette uitbreidpunten (menu, schermen, rooster-acties, exports) waar een module zich op aanhaakt, zónder de kern te wijzigen.
- **Afhankelijkheden & licenties** – het register bewaakt afhankelijkheden tussen modules en biedt een haak voor licenties/feature-flags, zodat modules per school verkocht en geactiveerd kunnen worden.

Zo kun je het product gelaagd aanbieden: iedereen krijgt de kern, en modules als printen, ouderportaal of multi-user zijn losse, activeerbare uitbreidingen.

**Kern (altijd aan):** personen, groepen, subgroepen, activiteiten, locaties, tijdslots, roosterblokken, schooljaar/kalender, conflictdetectie + het plugin-framework zelf.

**Modules (in-/uitschakelbaar per school):**

- **Printen/Exporteren** – roosters als PDF/print, per groep/leerling/leerkracht.
- **Multi-user & toegang** – inloggen met rollen: leerling, ouder, leerkracht, ondersteuner en diverse lagen collega's (bv. directie, administratie), elk met eigen rechten en weergave.
- *(later mogelijk)* ouderportaal, vervoer, doelen/handelingsplan, meldingen.

## 6. Gefaseerde aanpak

**Fase 0 – Fundament + plugin-framework**
Django-project, React-frontend, database, basis-UI-skelet én het plugin-framework: moduleregister, aan/uit-beheerscherm en uitbreidpunten. Dit framework is de ruggengraat van het verkoopargument, dus het komt meteen in fase 0.

**Fase 1 – Basisgegevens (CRUD)**
Personen (leerlingen, leerkrachten, ondersteuners), groepen, subgroepen, activiteiten, locaties invoeren en beheren.

**Fase 2 – Schooljaar & roostering**
Schooljaarkalender (studiedagen/vrije dagen/vakanties) + roosterblokken toewijzen aan groep/subgroep/leerling met begeleiders. Weekrooster tonen per groep, per leerling en per leerkracht.

**Fase 3 – Flexibiliteit & uitzonderingen**
Individuele afwijkingen, subgroep-roosters, afwezigheid/vervanging. Leerlingrooster = groepsrooster + uitzonderingen. Vrije/vakantiedagen schakelen blokken automatisch uit.

**Fase 4 – Conflictdetectie**
Automatische controle bij plaatsen/wijzigen, met heldere waarschuwingen.

**Fase 5 – Module: Printen/Exporteren**
Eerste echte losse module — roosters als PDF/print, per groep/leerling/leerkracht.

**Fase 6 – Module: Multi-user & toegang**
Inloggen met rollen (leerling, ouder, leerkracht, ondersteuner, collega-lagen), elk met eigen rechten en weergave.

Na elke fase heb je een werkende versie die je kunt uitproberen; we passen aan op basis van wat je ziet. De modules (fase 5–6) bewijzen meteen dat de modulaire opzet werkt.

## 7. Beslissingen (vastgelegd)

- **Techstack**: Django (backend, modules via apps) + React (frontend) + SQLite → later PostgreSQL.
- **Tijden**: vaste schooltijden, plus een jaaroverzicht met studiedagen, vrije dagen en vakanties.
- **Locaties**: meenemen in de MVP (ook voor conflictdetectie).
- **Multi-user**: niet in de MVP, maar als losse module gebouwd (leerling-, ouder- en gelaagde collega-logins).
- **Modulariteit**: een echt plugin-framework als verkoopargument — modules per school in-/uitschakelbaar via een beheerscherm, met haak voor licenties. Komt al in fase 0.

## 8. Volgende stap

Ik start met **Fase 0**: Django-project met modulestructuur, React-frontend en database opzetten — zodat we snel een werkend skelet hebben om op verder te bouwen. Zeg het woord en ik begin.