kita-planer/planung.md

Master-Spezifikation: SaaS Kita-Planer für Elternvereine

1. Projektübersicht Entwicklung einer mandantenfähigen (Multi-Tenant) Web-Anwendung zur Organisation von Elternvereinen/Elterninitiativen (Kitas). Das Kernziel ist die Digitalisierung des Notdienstes, der Terminplanung und der Stammdatenverwaltung. Das System wird als SaaS-Lösung (Software as a Service) aufgebaut, sodass sich unabhängige Kitas selbstständig registrieren und die Plattform nutzen können.

2. Architektur & Tech-Stack Um externe Kosten (Vendor-Lock-in) zu vermeiden, wird ein komplett offener und flexibel hostbarer Stack verwendet:

Framework: Next.js (App Router, React)

Datenbank: PostgreSQL (Lokal oder Cloud-hosted)

ORM: Prisma ORM

Authentifizierung: NextAuth.js (Auth.js) mit E-Mail/Passwort-Credentials

Styling & UI: Tailwind CSS, shadcn/ui, Lucide Icons

E-Mail-Versand: Nodemailer oder Resend (für Notdienst-Alarme und Einladungen)

Mandantenfähigkeit (Multi-Tenancy): Umsetzung strikt auf Datenbank- und Applikationsebene. Jede Kita erhält bei Registrierung eine eindeutige kita_id (Tenant-ID). Strenge Regel: Jeder Datensatz in der Datenbank (User, Kinder, Termine, Notdienste etc.) muss diese kita_id referenzieren.

3. Rollenkonzept (RBAC) Super-Admin: Systembetreuer (verwaltet die Infrastruktur, operiert außerhalb des normalen Kita-Alltags).

Admin (Vorstand): Kann alles innerhalb seiner Kita verwalten (Einstellungen ändern, Eltern einladen, Termine freigeben, Ämter verteilen). Der Gründer einer Kita erhält diese Rolle automatisch.

Notdienst-Koordinator: Spezielle Berechtigung für bestimmte Elternteile. Darf den Notdienst-Plan generieren, manuell anpassen und den Notdienst-Alarm auslösen.

Elternteil: Standard-Nutzer. Kann eigene Verfügbarkeiten eintragen, Termine sehen, das interne Adressbuch nutzen und Mitbringsel bei Festen eintragen.

4. Feature-Module Modul 0: SaaS-Onboarding & Einrichtung Landingpage: Öffentliche Startseite zur kostenlosen Registrierung einer neuen Kita.

Registrierung: Gründer gibt E-Mail/Passwort ein und wird automatisch erster Admin eines neuen Mandanten (kita_id).

Einrichtungs-Wizard:

Name der Kita festlegen.

Module aktivieren/deaktivieren (z.B. Notdienst-Modul).

Spezifische Regeln definieren (z.B. "Mindestanzahl Notdienst-Termine pro Kind im Monat").

Modul 1: Notdienst-Planung (Kern-Feature) Dateneingabe: Eltern müssen für den Folgemonat X Termine pro Kind als Verfügbarkeit eintragen. Das System validiert die Eingabe anhand der Kita-Einstellungen.

Erinnerung (Cronjob): Automatischer E-Mail-Versand an säumige Eltern ca. eine Woche vor Ende der Eintragsfrist.

Plan-Generierung: Der Notdienst-Koordinator löst die Verteilung aus. Der Algorithmus verteilt die Tage zufällig, aber fair über alle eingegebenen Verfügbarkeiten (Start jeden Monat bei null).

Manuelle Bearbeitung: Der generierte Plan ist zunächst ein Entwurf. Der Koordinator kann Tage überschreiben oder Lücken manuell füllen (z.B. nach Absprache in Messenger-Gruppen), bevor der Plan "veröffentlicht" wird.

Alarmierung (Workflow):

Bei Krankmeldung einer Fachkraft wählt der Koordinator den aktuellen Tag und klickt auf "Notdienst auslösen".

Das eingeteilte Elternteil erhält sofort eine E-Mail mit einem Bestätigungslink.

In der App sieht der Koordinator den Status: "Wartend" (gelbes Lade-Icon).

Klickt das Elternteil den Link, wechselt der Status auf "Bestätigt" (grün).

Fallback: Erfolgt keine Bestätigung, klärt der Koordinator den Rest außerhalb der App.

Modul 2: Terminkalender & Essenslisten Kalender-Sichtbarkeit: Alle bestätigten Termine sind für alle eingeloggten Nutzer einer Kita sichtbar. Kategorien: Kita-Fest, Schließtag, Interner Geburtstag, Externer Geburtstag, Sonstiges.

Buchungs-Workflow:

Eltern können Tage für private Nutzung (z.B. Kindergeburtstage) "anfragen". Status ist Ausstehend und der Slot wird blockiert.

Admin (Vorstand) muss die Anfrage bestätigen oder ablehnen.

Admins können Termine (z.B. Anfragen von Externen) direkt anlegen.

Flexible Mitbring-Listen: Der Admin kann zu jedem Termin eine Essens-/Mitbringliste aktivieren. Eltern können über ein freies Textfeld Einträge hinzufügen (z.B. "Familie Müller: Nudelsalat") und ihre eigenen Einträge bearbeiten/löschen.

Modul 3: Eltern-, Kinder- und Ämterverwaltung Onboarding (Invite-Only): Admins legen neue Eltern (Vorname, Nachname, E-Mail) im System an und verknüpft sie mit den entsprechenden Kindern. Das System sendet einen Einladungs-Link zur Passwortvergabe.

Feste Elterndienste (Ämter): Jedem Eltern-Account kann durch den Admin ein fester Dienst zugewiesen werden (z.B. "Wäschedienst", "Einkauf"). Dies ist auf dem Profil für alle sichtbar.

Kita-Adressbuch (Opt-In): Nach expliziter Zustimmung sind Eltern mit ihren Kontaktdaten im internen Kita-Adressbuch für andere Eltern sichtbar (zur Erleichterung von Spielverabredungen).

Modul 4: ErzieherInnen-Verwaltung Werden als reine Stammdaten (Namen) vom Admin in einer separaten Tabelle gepflegt.

Sie dienen ausschließlich als Referenz für die Notdienst-Logik (Auswahl: "Wer ist heute krank?").

Sie erhalten keine System-Accounts/Logins.

Modul 5: Sicherheit, DSGVO & Privacy by Design Dieses System verarbeitet sensible, personenbezogene Daten von Kindern. Das Architektur- und Datenbankdesign muss kompromisslos sicher sein. Folgende Regeln sind beim Schreiben des Codes strikt einzuhalten:

1. Strikte Mandanten-Isolierung (Tenant Isolation):

Jede Datenbankabfrage (Find, Update, Delete) muss zwingend den Filter where: { kita_id: user.kita_id } enthalten.

Es darf niemals möglich sein, dass durch Manipulation von API-Routen oder URLs ein Nutzer einer Kita auf den Datensatz einer anderen Kita zugreift. Dies ist durch Middleware oder sichere Server Actions zu validieren.

2. DSGVO-Einwilligung (Consent Logging):

Das User-Modell in Prisma muss Felder wie privacy_policy_accepted_at (DateTime) und directory_opt_in_at (DateTime) erhalten.

Ohne gesetzten Zeitstempel bei der Datenschutzerklärung wird der Zugriff auf die App-Inhalte blockiert (Redirect zum Onboarding-Screen).

3. Datenminimierung & Löschkonzept ("Recht auf Vergessenwerden"):

Es wird striktes onDelete: Cascade im Prisma-Schema verwendet. Löscht ein Admin seine Kita, müssen alle zugehörigen User, Kinder, Termine und Notdienste rückstandslos aus der Datenbank entfernt werden.

Nutzer müssen in ihren Profil-Einstellungen einen Button "Account löschen" haben, der ihre Daten und die ihrer Kinder (sofern kein anderer verknüpfter Elternteil existiert) endgültig vernichtet. Keine "Soft-Deletes" für personenbezogene Daten.

4. Authentifizierung & Transport-Sicherheit:

Vollständige Nutzung von NextAuth.js für sicheres Session-Management (HTTP-only, Secure Cookies, CSRF-Schutz).

Sicheres Hashing von Passwörtern.

5. API-Schutz (Rate Limiting):

Kritische Endpunkte (Login, Registrierung, Passwort-Reset) müssen vor Brute-Force-Attacken geschützt werden.

6. Entwicklungs-Fokus für die KI Bitte beginne mit der Initialisierung des Next.js Projekts und der Erstellung des schema.prisma. Achte von der ersten Zeile an penibel auf die Mandantenfähigkeit (kita_id) in allen relevanten Tabellen und auf die korrekten Relationen zwischen Kitas, Usern (Eltern), Kindern und Terminen. Präsentiere mir zuerst das geplante schema.prisma zur Abnahme, bevor wir mit dem Frontend oder den API-Routen beginnen.