Add non-destructive dev seed on startup

planung.md

@@ -0,0 +1,127 @@
+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.