kita-planer/docs/FUNKTIONSUEBERSICHT.md

Kita-Planer – Funktionsübersicht und aktueller Stand

Ergänzung vom 12.10.2026: Manuelle Planung und Zugriffsrechte

• Die manuelle Notdienst-Zuweisung gruppiert verfügbare Haushalte zuerst. Familien ohne Verfügbarkeit für den gewählten Tag bleiben als abgestimmter Sonderfall auswählbar und werden nach einer solchen Einteilung ausdrücklich gekennzeichnet. Geschwister zählen als ein Haushalt; Einteilungszahlen gelten ebenfalls je Haushalt. Die Anzeige verwendet dieselben gültigen Monatstage wie die Planung. Bestehende Alarm- und Schließtagssperren bleiben bestehen.
• Kita-Admins verwalten Zugriffsrollen unter /dashboard/zugriffsrechte sowie direkt bei Personen in Familien- und Teamverwaltung. Die Übersicht enthält auch Konten ohne eigenen Haushalt, eine Suche und die letzten 15 protokollierten Rollenänderungen der eigenen Kita.
• Haushaltskonten können Eltern, Notdienst-Koordination oder Kita-Admin sein. Ohne Haushalt stehen Koordination und Kita-Admin zur Verfügung. Konten mit Personalprofil können Fachkraft oder Kita-Admin sein; Arbeitszeiten, Anträge und Haushalt bleiben erhalten. Ein Personalprofil wird durch eine Rollenänderung nicht neu angelegt. Systemadmins werden hier nicht verwaltet. Ämter wie „Vorstand“ verleihen keine Zugriffsrechte.
• Rollenänderungen prüfen Akteur und Zielkonto erneut innerhalb einer serialisierbaren Transaktion. Eine zwischenzeitlich geänderte Rolle wird nicht überschrieben. Das bestehende Login liest die Rolle bei jeder Anfrage neu; eigene Herabstufung führt zurück zur Übersicht. Offene Aktivierungslinks benötigen weiterhin die Aktivierung, bevor Zugang entsteht.
• Mindestens ein aktiver Kita-Admin mit verifiziertem Konto, Passwort und Datenschutzzustimmung bleibt erhalten. Herabstufung, eigene Kontolöschung, Support-Löschung/-Sperre und eine E-Mail-Änderung mit erneuter Aktivierung berücksichtigen denselben Schutz. Offene Einladungen, deaktivierte/gesperrte Konten oder fehlende Zustimmung zählen nicht als Ersatz. Gleichzeitige Änderungen werden abgefangen.
• Eltern mit Admin-/Koordinationsrolle erhalten weiterhin Haushaltsalarme, können über ihre persönlichen Links antworten und erhalten Mails nach manueller Umteilung. Fachkräfte mit Admin-Rolle können ihr verknüpftes Personalprofil weiter nutzen; persönliche Benachrichtigungseinstellungen und offene Fachkraftaktivierungen bleiben funktionsfähig.
• Kein Schema-Upgrade erforderlich.

Prüfbefehl: TEST_DATABASE_URL=postgresql://USER:PASSWORD@127.0.0.1:PORT/kita_roles_test npm run test:roles nach Anwendung der vorhandenen Migrationen auf dieser separaten lokalen Testdatenbank. Die 27 Rollen-/PostgreSQL-Tests und sechs tatsächlichen Komponenten-Rendertests verwenden synthetische Konten und ersetzte Mailtransporte.

Abnahme: 33 neue Tests und 193 bestehende Sicherheits-, Planungs-, Kalender-, Versand-, Familien-, Personal- und Alarmtests erfolgreich (226 insgesamt, keine übersprungenen Tests). Browserprüfung auf Desktop und bei 390 Pixeln: verfügbare und bewusst abweichende Einteilung, Rollenänderung aus Familien-/Teamverwaltung, Suche, Änderungshistorie, Schutz für einzigen Admin und eigene Herabstufung mit unmittelbar verweigertem Verwaltungszugriff. Produktionsbuild und TypeScript erfolgreich; ESLint ohne Fehler mit sieben bestehenden Warnungen.

Ergänzung vom 12.10.2026: Notdienst-Benachrichtigungen

• Automatische Erinnerungen erfassen auch unvollständige Verfügbarkeiten. Das Soll wird aus allen aktiven Kindern und die Istzahl aus unterschiedlichen gültigen Tagen berechnet. Admin-/Koordinationskonten mit eigenem Haushalt gehören zur Eltern-Empfängergruppe.
• Die Erinnerungsfrist bezieht sich jetzt ausdrücklich auf den 26. als Ende der Eintragsfrist. Standard: sieben Tage vorher ab 9 Uhr Berliner Zeit; 0 deaktiviert die automatische Runde. Verpasste Läufe werden innerhalb der noch offenen Frist nachgeholt. Jede Kita/Folgemonat erhält eine automatische Runde; manuelle Erinnerungen sind je Konto/Tag dedupliziert.
• Beim ersten Veröffentlichen werden Mailaufträge in derselben Transaktion gespeichert. Pro erreichbarem Konto wird eine gemeinsame Nachricht mit den aktuellen eigenen Diensten erzeugt. Mehrfaches Veröffentlichen erzeugt keine zweite Runde. Mailfehler ändern den veröffentlichten Status nicht.
• Die Monatsplanung zeigt Versandzahlen und Einzelstatus sowie eine manuelle Wiederholung offener/fehlgeschlagener Nachrichten. Bereits versendete oder inzwischen überholte Aufträge werden dabei nicht neu verschickt.
• Der bestehende geschützte Notdienstjob verarbeitet die Nachrichten automatisch. Gespeicherte Reservierungen, Idempotenzschlüssel, zunehmende Wiederholungsabstände und erneute Berechtigungs-/Einteilungsprüfung sichern die Verarbeitung. Der Produktionsstart startet einen abgebrochenen Worker erneut.
• Additive Migration: 20261012000000_notdienst_notifications. Sie erhält die bisherigen Constraints und ergänzt drei weitere Tenant-Fremdschlüssel. Einrichtung und Grenzen stehen in deploy/README.md.

Prüfbefehle: npm run test:mail, npm run test:runtime, npm run test:notdienst und TEST_DATABASE_URL=postgresql://USER:PASSWORD@127.0.0.1:PORT/kita_notifications_test npm run test:notdienst:notifications nach Anwendung der Migrationen auf dieser separaten Testdatenbank. Die Versandtests verwenden ersetzte Transporte; reale Eltern werden nicht angeschrieben.

Abnahme: 33 neue Versand-Integrationstests, vier Tests des tatsächlichen SDK-Transports, zwei Supervisor-Tests, sechs Datums-/Fristtests sowie 106 bestehende Sicherheits-, Planungs-, Kalender- und Elternablauftests erfolgreich (151 insgesamt, keine übersprungenen Tests). Browserprüfung mit lokalem Mailserver: automatische Erinnerung einmalig, Veröffentlichung trotz simuliertem Versandfehler, sichtbare Einzelstatus, erfolgreiche Wiederholung und mobile Anzeige. TypeScript und Produktionsbuild erfolgreich; ESLint ohne Fehler mit acht bestehenden Warnungen. Zusätzliche Upgrade-Prüfung gegen das vorige Schema: vorhandene Familien, Konten, Kinder, veröffentlichter Plan und Einteilung unverändert erhalten; keine nachträglichen Veröffentlichungsmails angelegt. Die Zahl der ergänzenden Tenant-Fremdschlüssel steigt von 41 auf 44.

Ergänzung vom 12.10.2026: Kalender und kleine Bedienungsverbesserungen

• Eigene Mitbringbeiträge lassen sich direkt mit Speichern/Abbrechen bearbeiten. Enter speichert; Escape schließt den Termindialog und verwirft den Entwurf. Eingaben werden auf 1 bis 500 Zeichen begrenzt; fremde Beiträge können auch von Admin/Koordination nicht umgeschrieben werden. Ein bestätigter Termin mit aktiver Mitbringliste und die Kita-/Autorzuordnung werden serverseitig geprüft.
• Eltern mit Admin- oder Koordinationsrolle können für den eigenen Haushalt Dienste tauschen. Kalenderknöpfe und offene eingehende/ausgehende Anfragen stehen ihnen ebenfalls zur Verfügung. Tauschmails berücksichtigen verifizierte, aktive Elternkonten aller drei Rollen im jeweils beteiligten Haushalt. Konten ohne eigenen Haushalt erhalten dadurch kein Tauschrecht; fremde Angebote und aktive Alarme bleiben gesperrt.
• Die fest eingetragene „4“ am Menüpunkt Notdienst wurde entfernt.
• Kein Schema-Upgrade erforderlich. Automatische Erinnerungen und Veröffentlichungsmails bleiben die nächste Etappe.

Prüfbefehl für die neuen Abläufe: TEST_DATABASE_URL=postgresql://USER:PASSWORD@127.0.0.1:PORT/kita_quickwins_test npm run test:calendar:integration. Er verlangt eine ausdrücklich benannte lokale Testdatenbank mit den vorhandenen Migrationen. Die 26 Fälle prüfen echte Server Actions und PostgreSQL; Mailtransport und Anmeldesession werden isoliert ersetzt. Die bestehenden Elternabläufe wurden ebenfalls mit 9 Integrationstests und 9 Berechnungstests geprüft.

Im Browser geprüft: eigener Beitrag speichern und abbrechen, Anzeige bei 390 Pixeln, fehlender Bearbeiten-Knopf bei fremden Beiträgen, Navigation ohne festen Zähler, Admin-Tauschanfrage mit eigenem Angebot sowie Anzeige und Annahme durch Koordination. E-Mails wurden dabei ausschließlich im Entwicklungsmodus simuliert.

Abnahme dieser Etappe: 26 neue Integrationstests, 18 bestehende Elternablauftests und 28 Sicherheitstests erfolgreich (72 insgesamt, keine übersprungenen Tests). TypeScript und Produktionsbuild erfolgreich; projektweites ESLint ohne Fehler mit acht bestehenden Warnungen.

Ergänzung vom 12.10.2026: Verlässliche Notdienst-Planungsregeln

• Das Verfügbarkeitssoll wird aus allen aktiven Kindern des angemeldeten Haushalts berechnet. Ausgelassene, doppelte, fremde oder inaktive Kinder werden zurückgewiesen; doppelte Datumsangaben zählen nur einmal.
• Oberfläche, Speicherung, Generierung und manuelle Zuweisung verwenden gemeinsame Regeln: nur Werktage des Planungsmonats, ohne bestätigte Schließtage und Teamtage. Mehrtägige Termine schließen beide Randtage ein; Kalenderzeiten werden in Europe/Berlin ausgewertet. Ausstehende/abgelehnte Termine und Termine anderer Kitas blockieren nichts.
• Alte ungültige Verfügbarkeiten werden nicht für neue Pläne verwendet. Vor der Veröffentlichung werden Entwürfe auf zulässige Tage und aktive Kinder geprüft. Ungültige vorhandene Einteilungen bleiben sichtbar und können über „Manuell zuweisen“ entfernt werden; aktive Alarme und vergangene veröffentlichte Dienste behalten ihre Bearbeitungssperre.
• Kindlöschung im Elternprofil und in der Familienverwaltung ist bei heutigen/zukünftigen veröffentlichten Notdiensten oder aktiven Alarmen gesperrt. Zuerst muss die Koordination die Einteilung klären. Prüfung und Löschung laufen in derselben serialisierbaren Transaktion mit einer Sperre der betroffenen Kinder.
• Kein Schema-Upgrade erforderlich. Automatische Erinnerungen und Benachrichtigungen bei Erstveröffentlichung sind weiterhin offen.

Prüfbefehle: npm run test:notdienst (Datumsregeln) und TEST_DATABASE_URL=postgresql://USER:PASSWORD@127.0.0.1:PORT/kita_notdienst_test npm run test:notdienst:integration (echte Server Actions und PostgreSQL). Der Integrationsbefehl verlangt ausdrücklich eine separate lokale Testdatenbank; fehlende Konfiguration führt zu einem Fehler. Zuvor die vorhandenen Migrationen auf dieser Testdatenbank anwenden.

Abnahme: 4 Datumstests, 34 PostgreSQL-Regressionstests und 28 bestehende Sicherheitstests erfolgreich. Im Browser geprüft: gesperrter Teamtag/Wochenende, Speicherung des vollständigen Haushaltssolls, Veröffentlichungssperre, Entfernen einer alten ungültigen Einteilung und gültige manuelle Zuweisung mit anschließender Veröffentlichung. TypeScript und Produktionsbuild erfolgreich; projektweites ESLint ohne Fehler mit acht bestehenden Warnungen.

Ergänzung vom 09.10.2026: Notdienstalarm

Der Notdienstalarm ist inzwischen umgesetzt. Admins und Koordination alarmieren die eingeteilte Familie für einen ganzen Tag oder ein Zeitfenster. Persönliche Rückmeldelinks erzeugen eine gemeinsame Haushaltsantwort; Dashboard-Hinweise, eine 30-Minuten-Frist, Klärungsbedarf, verspätete Freigabe, telefonische Korrektur, Stornierung, Versandstatus und Hintergrundprüfung sind angebunden. Aktive Alarme sperren Planumzuordnung und Diensttausche. Siehe NOTDIENSTALARM.md für Bedienung und benötigte Hosting-Konfiguration.

Die folgende ursprüngliche Bestandsaufnahme bleibt als historischer Stand erhalten; darin als offen bezeichnete Alarmfunktionen sind durch diese Ergänzung überholt.

Stand: 07.10.2026

Geprüfter Ausgangsbranch: codex/notdienst-swaps

Geprüfter Commit: ec3f4f933d42068c9d8446dc95de9815d5779238

Dokumentationsbranch: codex/funktionsinventar

Ergänzung vom 07.10.2026: Auf codex/personalbereich wurde anschließend der Personalbereich für Arbeitszeit, Urlaub und Freizeitausgleich umgesetzt. Diese Bestandsaufnahme bleibt als Beschreibung des Ausgangsstands erhalten; der neue Umfang, Berechnungsregeln, Einrichtung und aktuelle Prüfungen stehen in PERSONALBEREICH.md. Die Aussagen unten zu fehlender Zeiterfassung, Accountverknüpfung und Tests beziehen sich auf den Ausgangscommit.

Ergänzung vom 08.10.2026: Der Personalbereich enthält jetzt auch Aktivierungsmails, Antrags- und Entscheidungshinweise sowie eine Abschalteinstellung im Fachkraftprofil. Der aktuelle Umfang und die Versandkonfiguration stehen ebenfalls in PERSONALBEREICH.md.

1. Grundlage der Prüfung

Diese Bestandsaufnahme beschreibt die im Repository vorhandenen Produktfunktionen. Geprüft wurden Seiten und Navigation, Formulare und Dialoge, Server Actions, API-Routen, Datenmodell, E-Mail-Anbindung und Betriebsdateien. Die Planung in planung.md, die UI-Liste in UI-TODO.md und der frühere Live-Testplan wurden mit dem aktuellen Code abgeglichen.

„Vorhanden“ bedeutet hier: Oberfläche und zugehörige Verarbeitung sind im Code angebunden. Es bedeutet keine Bestätigung durch einen aktuellen Live-Test. Es wurden keine Produktionsdaten verändert, keine E-Mails verschickt und keine Datenbankänderungen ausgeführt. Die tatsächliche Zustellung von E-Mails, das Verhalten im Browser und die produktive Konfiguration bleiben gesondert zu prüfen.

Status:

Kennzeichnung	Bedeutung
Vorhanden	Im aktuellen Code als erreichbarer Ablauf umgesetzt.
Teilweise	Funktion vorhanden, aber mit konkreten Einschränkungen oder fehlender Anbindung.
Vorbereitet	Datenmodell, Komponente oder Aktion vorhanden; vollständiger Nutzerablauf fehlt.
Offen	In der Planung vorgesehen, im geprüften Code nicht umgesetzt.

2. Gesamtüberblick

Die Anwendung besitzt bereits eine breite MVP-Grundlage für mehrere unabhängige Kitas: Registrierung, Einrichtung, Familien und Kinder, Notdienst-Verfügbarkeiten und Planung, Diensttausch, Kalender, Mitbringlisten, Abwesenheiten, Kontaktdaten und Superadmin-Support. Einige beworbene Abläufe sind jedoch noch nicht vollständig nutzbar, insbesondere Alarmierung, Eltern-Rückmeldungen zu Events und die Anzeige des Schwarzen Bretts für Eltern.

Bereich	Stand	Wichtigste Einschränkung
Öffentliche Website und Kontakt	Vorhanden	Impressum und Datenschutz enthalten Platzhalter.
Registrierung, Login, Kita-Einrichtung	Vorhanden	Kein selbstständiger Passwort-Reset; Modulschalter wirken nur teilweise.
Dashboard	Vorhanden	News-, RSVP- und Alarm-Komponenten sind nicht eingebunden.
Profil und eigene Kinder	Vorhanden	Persönlicher Name, E-Mail und Rolle sind im Profil nur lesbar.
Familienverwaltung und feste Ämter	Vorhanden	Kein vollständiger Einladungs-Support mit erneutem Versand/Widerruf.
Notdienst-Verfügbarkeiten	Vorhanden	Wochenenden und Schließtage werden nur in der Oberfläche ausgeschlossen.
Notdienst-Planung	Vorhanden	Keine automatische Erinnerung und keine E-Mail bei Erstveröffentlichung.
Notdienst-Tausch	Vorhanden	Nur Elternrolle kann neue Tauschanfragen starten.
Notdienst-Alarmierung	Vorbereitet	Auslösebutton ist auf keiner Seite eingebunden.
Kalender und Mitbringlisten	Vorhanden	Keine Kollisionsprüfung für Raumbuchungen; Mitbringsel nicht direkt bearbeitbar.
Event-Teilnahme/RSVP	Teilweise	Verwaltung vorhanden, Eltern-Eingabe nicht in eine Seite eingebunden.
Abwesenheiten	Vorhanden	Gruppenfilter verwendet eine künstliche Zuordnung.
Schwarzes Brett	Teilweise	Veröffentlichung vorhanden, Elternanzeige und Lesestatus fehlen im aktuellen Dashboard.
Adressbuch	Vorhanden	Opt-in gilt für Kontaktdaten; weitere Haushaltsdaten bleiben sichtbar.
ErzieherInnen-Stammdaten	Vorhanden	Stammdatensatz und Benutzerrolle ERZIEHER sind getrennte Konzepte.
Superadmin-Verwaltung	Vorhanden	Einladungszähler verwenden ein anderes Modell als der reale Einladungsablauf.
Betrieb und Qualität	Teilweise	TypeScript erfolgreich, ESLint mit Fehlern; keine automatisierte Testsuite gefunden.

3. Rollen und Zugriffsbereiche

Rolle	Aktuelle Möglichkeiten
SUPERADMIN	Systemweite Kita-Übersicht, Kita-Diagnosen, Support-Aktionen und Audit-Protokoll. Standardmäßig ohne Kita-Zuordnung und mit eigener Oberfläche unter /admin.
ADMIN	Verwaltung der eigenen Kita: Familien, Ämter, ErzieherInnen, Dienste, Meldungen, Kalender und Notdienst. Mit eigenem Haushalt auch Elternfunktionen nutzbar.
KOORDINATOR	Notdienstplanung, Kalenderverwaltung, Event-Anmeldungen und Abwesenheitsübersicht. Mit eigenem Haushalt auch Verfügbarkeiten eintragbar.
ERZIEHER	Dashboard, Kalender, Adressbuch, Profil und Abwesenheitsübersicht. Kein Zugriff auf die Notdienst-Eingabeseite.
ELTERN	Eigener Haushalt/Kinder, Verfügbarkeiten, Kalender, Terminanfragen, Mitbringsel, Diensttausch, Abwesenheitsmeldungen und Adressbuch.

Navigation und serverseitige Rollenprüfungen sind vorhanden. Die Rolle ERZIEHER existiert im Datenmodell und wird in Berechtigungen verwendet. Die ErzieherInnen-Verwaltung erstellt jedoch nur Namen als Stammdaten und keine Benutzerkonten. Ein regulärer Dialog zur Einladung von Erzieher-Accounts oder zur Vergabe von Admin-/Koordinatorrollen wurde nicht gefunden.

Quellen: Navigation, Zugriffsprüfungen, Datenmodell.

4. Funktionsinventar nach Bereich

4.1 Öffentliche Website und Kontakt

• Startseite mit Produktbeschreibung, Funktionsvorschauen, Rollenbeschreibung, Einstieg in Registrierung und Login sowie Kontaktbereich.
• Fünf öffentliche Detailseiten: Notdienst-Planer, Kita-Kalender, Eltern-Adressbuch, Krankmeldung und Schwarzes Brett.
• Kontaktformular für allgemeine Fragen, Demo-Anfragen und individuelles Setup.
• Eingaben: Name, optionale Kita, E-Mail-Adresse, Anfrageart und Nachricht.
• Versand einer Anfrage an den konfigurierten Kontakt-Empfänger und einer Bestätigung an die anfragende Person; passende Antwortadressen werden gesetzt.
• Bot-Schutz durch ein unsichtbares Zusatzfeld und ein Limit von fünf Kontaktanfragen je IP-Adresse pro Stunde. Das Limit liegt im Arbeitsspeicher des jeweiligen Prozesses.
• Sitemap, Robots-Datei und Metadaten für öffentliche Seiten.
• Optionales Umami-Tracking über Umgebungsvariablen, auf eine Liste öffentlicher Seiten beschränkt. Suchparameter und URL-Fragmente werden ausgeschlossen; Do-Not-Track wird berücksichtigt.
• Impressum und Datenschutzerklärung sind als Seiten vorhanden, enthalten aber noch Betreiber-, Hosting- und weitere Platzhalter.

Quellen: Startseite, Feature-Inhalte, Kontaktaktion, Analytics, Impressum, Datenschutz.

4.2 Registrierung, Anmeldung und Einrichtung

• Gründerregistrierung mit Vorname, Nachname, E-Mail-Adresse, Passwort und verpflichtender Datenschutzannahme.
• Prüfung auf bereits verwendete E-Mail-Adressen und Passwort-Hashing mit bcrypt.
• Gründer erhält zunächst die Adminrolle ohne Kita-Zuordnung und wird direkt angemeldet.
• Kita-Einrichtung mit Name, eindeutigem Slug, Aktivierung von Notdienst/Kalender/Adressbuch und Mindestzahl an Verfügbarkeiten pro Kind.
• Bei aktivem Notdienstmodul ist mindestens ein Verfügbarkeitstag erforderlich; die Einrichtung erlaubt höchstens 31.
• Kita-Anlage und Zuordnung des Gründers erfolgen in einer Datenbanktransaktion; erneute Einrichtung desselben Kontos wird abgefangen.
• Login mit E-Mail und Passwort, Rückleitung zu einer internen Zielseite und allgemeine Fehlermeldung bei falschen Zugangsdaten.
• Abmeldung über Desktop-Navigation und mobiles Menü.
• Nach zehn Fehlversuchen wird das betreffende Konto für 15 Minuten gesperrt; erfolgreicher Login setzt den Zähler zurück.
• JWT-basierte Sessions mit Benutzer-, Kita-, Familien- und Rolleninformationen. Rolle und Zuordnungen werden bei weiteren Session-Aufrufen mit der Datenbank abgeglichen.
• Geschützte Seiten leiten nicht angemeldete Personen zum Login und Gründer ohne Kita zur Einrichtung weiter.
• Datenschutzannahme wird mit Zeitpunkt und Versionskennung gespeichert. Die Sonderseite für fehlende Zustimmung verweist auf Support; sie enthält kein Formular zum Nachholen der Zustimmung.

Einschränkungen: Kein Passwort-vergessen-/Passwort-ändern-Ablauf. Die Gründerregistrierung setzt emailVerifiedAt unmittelbar, ohne Bestätigungsmail. Ein allgemeines IP-Limit für Login oder Registrierung ist nicht angebunden; das Kontaktformular hat sein eigenes Limit.

Quellen: Registrierung, Einrichtung, Login, Authentifizierung, Proxy, Consent-Seite.

4.3 Dashboard und Navigation

• Begrüßung mit Kita-Namen, Benutzernamen und aktuellem Datum.
• Kennzahlen zu Familien, aktiven Kindern, eingetragenen Notdienst-Verfügbarkeiten des Folgemonats und rechnerisch heute anwesenden Kindern.
• Direktes Melden einer Kinderabwesenheit und Übersicht der laufenden/bevorstehenden eigenen Abwesenheiten.
• Schnellzugriffe auf Familienverwaltung, Kalender, Notdienstplanung und Adressbuch. Die drei letztgenannten berücksichtigen die Modulschalter bei der Anzeige.
• Hinweisdialog bei unvollständigem Profil: Telefon, Adresse sowie gegebenenfalls Haushalt und Kinder. Fortschritt wird angezeigt; der Hinweis kann im lokalen Browser dauerhaft ausgeblendet werden.
• Rollenabhängige Seitenleiste und ein auf kleinen Bildschirmen aufklappbares Menü.

Einschränkungen: Die Notdienstkennzahl zählt Verfügbarkeitseinträge, keine tatsächlich besetzten Plantage. Schnellzugriffe auf Verwaltung werden nicht vollständig nach Rolle ausgeblendet; die Zielseiten besitzen Rollenprüfungen. Die Notdienst-Badge 4 in der Seitenleiste ist fest hinterlegt.

Quellen: Dashboard, Profilhinweis, Dashboard-Rahmen.

4.4 Profil, Haushalt und eigene Kinder

• Anzeige von Name, E-Mail-Adresse, Rolle, Kita, Haushalt, angelegtem Konto und zugewiesenen festen Ämtern.
• Bearbeiten von Telefonnummer, Straße, Postleitzahl und Ort.
• Adressbuchfreigabe erteilen oder zurückziehen; Zeitpunkt der Freigabe wird gespeichert.
• Eigenen Haushalt anlegen, wenn noch keiner zugeordnet ist.
• Eigene Kinder anlegen, bearbeiten und löschen; Vor-/Nachname sowie optionales Geburtsdatum.
• Bei Eingabe eines Geburtsdatums: gültiges Datum, nicht in der Zukunft, höchstens sieben Jahre zurück.
• Datenänderungen an Kindern werden auf den eigenen Haushalt und die eigene Kita begrenzt.
• Eigenes Konto nach Bestätigung löschen. Bestehen aktuelle oder zukünftige veröffentlichte Notdienstpflichten des Haushalts, wird die Selbstlöschung abgelehnt.
• Beim letzten Benutzer eines Haushalts wird die Familie samt abhängigen Kindern gelöscht; bei weiteren Benutzern bleibt der Haushalt bestehen.

Einschränkungen: Name, E-Mail und Rolle lassen sich im persönlichen Profil nicht ändern. Eine Sperre der Kinderlöschung bei bestehenden Notdienstpflichten ist in deleteMyChild nicht vorhanden, obwohl die Kontolöschung diese Pflichten prüft.

Quellen: Profilseite, Profilaktionen.

4.5 Familienverwaltung, Eltern-Einladungen und feste Ämter

• Adminübersicht aller Familien mit Eltern und Kindern; Suche nach Familie, Eltern, E-Mail und Kindern.
• Umschalten zwischen Tabelle und Karten.
• Neue Familie mit einem oder zwei Elternteilen sowie einem bis zehn Kindern anlegen.
• Familienname, Namen/E-Mail-Adressen der Eltern und Kindernamen bearbeiten.
• Zweiten Elternteil ergänzen, neue Kinder hinzufügen und Kinder entfernen. Der Bearbeitungsablauf verlangt mindestens ein verbleibendes Kind und höchstens zwei Elternteile.
• Neue Elternkonten erhalten die Rolle ELTERN und einen Einladungslink zur Passwortvergabe mit sieben Tagen Gültigkeit.
• Aktivierung prüft Link, Ablaufdatum, Passwortlänge, Passwortbestätigung und Datenschutzannahme; optionales Adressbuch-Opt-in.
• Nach Aktivierung werden Passwort und Zustimmungen gespeichert, der Token gelöscht und die Person direkt angemeldet.
• Die Familienliste zeigt anhand der Kontoverifikation, ob eine Einladung noch offen ist.
• Feste Ämter mit Name und optionaler Beschreibung anlegen und löschen.
• Ein oder mehrere Ämter an einzelne Benutzer vergeben und Zuordnungen entfernen; doppelte identische Zuordnungen werden verhindert.
• Ämter sind im Profil und Adressbuch sichtbar.

Einschränkungen: Kein regulärer Dialog zum erneuten Versand oder Widerruf einer Einladung. Einladungen werden im tatsächlichen Ablauf in VerificationToken gespeichert. Das separate Modell Invitation ist dafür nicht angebunden. Scheitert der Mailversand nach der Datenanlage, bleibt die Familie angelegt und eine Fehlermeldung wird zurückgegeben. Eine vollständige Familienlöschung durch Kita-Admins ist nicht angeboten.

Quellen: Familienaktionen, Familienliste, Einladungsaktivierung, Ämter.

4.6 Notdienst-Verfügbarkeiten für Eltern

• Eingabe für den Folgemonat, bezogen auf aktive Kinder des eigenen Haushalts.
• Mindestzahl an ausgewählten Tagen entspricht Anzahl der Kinder × Kita-Einstellung.
• Bereits gespeicherte Haushaltseinträge werden geladen und können erneut gespeichert werden.
• Monatskalender mit Terminen, Kategorien, Veranstaltungsdetails und auswählbaren Verfügbarkeitstagen.
• Die Oberfläche lässt Montag bis Freitag zu und sperrt bestätigte Schließtage.
• Auswahlfortschritt und Rückmeldung bei zu wenigen Tagen.
• Die ausgewählten verschiedenen Tage werden beim Speichern reihum auf die angegebenen Kinder verteilt; bestehende Einträge dieser Kinder im Zielmonat werden ersetzt.
• Eingabefrist ist im Code fest: bis einschließlich 26. des aktuellen Monats, gesperrt ab dem 27.
• Ohne aktive eigene Kinder erscheint ein Hinweis mit Verweis zum Profil.

Einschränkungen: Die Server Action prüft Datumsformat, Zielmonat, Mindestzahl und Haushaltszugehörigkeit, aber keine Wochenenden oder Schließtage. Die Frist ist nicht im Einstellungsdialog konfigurierbar. Abwesenheitsmeldungen werden bei den Verfügbarkeiten nicht automatisch berücksichtigt.

Quellen: Elternseite, Kalendereingabe, Speichern, Fristregel.

4.7 Notdienst-Planungszentrale

• Admins und Koordinatoren können über Monat/Jahr navigieren; Vorgabe ist der Folgemonat.
• Übersicht von Haushalten, Kindern, Verfügbarkeitstagen, Haushalten mit/ohne Rückmeldung und Planstatus.
• Automatische Erzeugung eines monatlichen Entwurfs; ein bestehender Monatsplan verhindert erneute Generierung.
• Für jeden Montag bis Freitag wird aus verfügbaren Kindern ein Haushalt ausgewählt, der im bisherigen Monatsdurchlauf möglichst selten eingeteilt wurde. Bei Gleichstand kommt Zufall zum Einsatz; der Zähler startet jeden Monat neu.
• Tage ohne Verfügbarkeiten bleiben unbesetzt.
• Vorschau und manuelle Zuordnung zu einem aktiven Kind der Kita; Tage können auch geleert werden.
• Entwurf veröffentlichen; veröffentlichte Einteilungen erscheinen im Kalender.
• Veröffentlichte Pläne nachbearbeiten, solange der betreffende Tag nicht vergangen ist.
• Nach manuellen Änderungen eines veröffentlichten Plans werden E-Mails an betroffene Elternkonten der Rolle ELTERN angestoßen; betroffene offene Tauschanfragen werden ungültig.
• Entwurfsplan mit Bestätigungsdialog zurücksetzen und löschen. Veröffentlichte Pläne werden serverseitig vom Reset ausgeschlossen.
• Kita-Einstellungen für Mindestverfügbarkeiten und Erinnerungs-Vorlauf speichern.
• Manuell Erinnerungen an Haushalte versenden, die im ausgewählten Monat gar keinen Verfügbarkeitseintrag haben.
• „Als PDF exportieren“ öffnet den Browser-Druckdialog (window.print()); die PDF-Datei entsteht über die Druckfunktion des Browsers.

Einschränkungen: Keine garantierte optimale oder über mehrere Monate ausgeglichene Verteilung. Die Generierung berücksichtigt keine Feiertage, Schließtage, Teamtage oder Kinderabwesenheiten. Ein Erinnerungs-Vorlauf wird gespeichert, aber kein zeitgesteuerter Job verwendet ihn. Haushalte mit zu wenigen Einträgen erhalten über diese Erinnerungsaktion keine Erinnerung, sobald wenigstens ein Eintrag vorliegt. Beim erstmaligen Veröffentlichen wird keine Zuteilungsmail versendet; die entsprechende E-Mail-Vorlage allein ist kein angebundener Versand.

Quellen: Planungsseite, Planaktionen, Planoberfläche.

4.8 Notdienst-Tausch zwischen Familien

• Eltern können im Kalender einen fremden Notdienst anfragen und einen eigenen veröffentlichten Dienst zum Tausch anbieten; optionale Nachricht bis 500 Zeichen.
• Beide Dienste müssen derselben Kita angehören, veröffentlicht und heute oder zukünftig sein. Ein Tausch im eigenen Haushalt wird abgewiesen.
• Dienste mit wartender oder bestätigter Alarmierung sind vom Tausch ausgeschlossen.
• Bereits beteiligte Dienste mit offenen Tauschanfragen können keine weitere offene Anfrage erhalten.
• Der angefragte Haushalt erhält eine E-Mail und sieht die offene Anfrage im Kalender.
• Angefragter Haushalt kann annehmen oder ablehnen; anfragender Haushalt kann zurückziehen.
• Annahme vertauscht beide Kinder-Zuordnungen in einer Transaktion, speichert die Entscheidung und storniert weitere betroffene offene Anfragen.
• Annahme und Ablehnung lösen Benachrichtigungen an beide Familien aus; Rücknahme speichert den Status ohne eigenen Mailversand.
• Kalender und Notdienstansichten werden nach Änderungen neu validiert.

Einschränkungen: Neue Anfragen sind auf die exakte Rolle ELTERN beschränkt; Eltern mit Admin-/Koordinatorrolle können sie nicht starten. Die Oberfläche zeigt offene Anfragen, keine vollständige abgeschlossene Tauschhistorie. Eine erneute Verfügbarkeitsprüfung für die getauschten Tage erfolgt nicht.

Quellen: Tauschaktionen, Kalender und Anfragen, Tauschdialog.

4.9 Notdienst-Alarmierung

Die am 09.10.2026 abgestimmte Erweiterung ist in NOTDIENSTALARM_PLAN.md beschrieben. Sie ist zunächst geplant; der folgende Abschnitt beschreibt den vorhandenen Code.

Vorbereitet sind:

• Server Action zum Auslösen eines Alarms durch Admin/Koordinator für eine Einteilung.
• Kita-Prüfung und Abweisung einer bereits alarmierten Einteilung.
• Eigene Alarmdatensätze und E-Mails für die Elternkonten der eingeteilten Familie mit Rolle ELTERN.
• Bestätigungsseite unter /alert/[token]; der Link erlaubt die Bestätigung ohne Login.
• Statuswechsel von PENDING auf CONFIRMED mit Zeitstempel; erneute Bestätigung wird abgewiesen.
• Vorbereitete Button-Komponente für das Auslösen.

Aktueller Stand: AlertButton wird von keiner Seite eingebunden. Ein erreichbarer Auslöseablauf und eine laufende Statusübersicht für die Koordination fehlen damit in der aktuellen Oberfläche. Das Datenmodell kann eine erkrankte Fachkraft und Notizen speichern, aber die Aktion nimmt nur die Einteilungs-ID entgegen. Eine Auswahl der Fachkraft, Alarmstornierung, Eskalation oder zeitliche Token-Gültigkeit ist nicht angebunden.

Quellen: Alarmaktion, ungebundener Alarmbutton, Bestätigung.

4.10 Kalender, Terminanfragen und Mitbringlisten

• Gemeinsamer Kalender für bestätigte Termine, eigene ausstehende Terminanfragen, geplante Elterndienste und veröffentlichte Notdienste.
• Listen-, Monats- und Agendaansicht; Monatsnavigation und Sprung zu heute.
• Tagesdialog mit Termindetails, Diensten und Mitbringlisten.
• Suche nach Titel/Beschreibung und bei Diensten nach Familie beziehungsweise Kind.
• Kategorienfilter und Umschaltung zwischen eigenen und allen Diensten; reguläre Kita-Termine bleiben auch im eigenen Filter sichtbar.
• Kategorien: Kita-Fest, Schließtag, Teamtag, Mitmach-Tag, Elternabend, Mitgliederversammlung, Elterncafé, interner/externer Geburtstag und Sonstiges.
• Terminanfrage mit Titel, Beschreibung, Kategorie, Anfang/Ende und Ganztagsangabe.
• Eigene Anfragen werden als ausstehend angezeigt; Admins/Koordinatoren können ausstehende Anfragen bestätigen oder mit Begründung ablehnen.
• Admins/Koordinatoren können bestätigte Termine direkt anlegen, bearbeiten und endgültig löschen.
• Datumsprüfung: Beginn nicht in der Vergangenheit, Ende nicht vor Beginn.
• Mitbringliste je Termin aktivieren/deaktivieren; Textbeiträge hinzufügen.
• Eigene Beiträge löschen; Admins/Koordinatoren können auch fremde Beiträge löschen.
• Verweise aus Dienst-/Notdienstterminen in die entsprechenden Verwaltungsseiten; Diensttausch über den Kalender.

Einschränkungen: Ausstehende Anfragen blockieren keinen Zeitraum durch eine serverseitige Kollisionsprüfung. Eine Anfrage ist für andere Eltern nicht allgemein als reservierter Slot sichtbar. Mitbringbeiträge lassen sich nicht direkt bearbeiten, sondern nur löschen und neu anlegen. Es wurde kein Kalenderabo, ICS-Export oder Serientermin-Ablauf gefunden.

Quellen: Kalenderseite, Kalenderansichten, Terminaktionen, Mitbringliste.

4.11 Event-Anmeldungen und RSVP

• Admins/Koordinatoren können Termine mit Teilnahmeabfrage, optionaler Rückmeldefrist und Hinweisen für Teilnehmende anlegen/bearbeiten.
• Verwaltungsseite listet Termine samt Status und zeigt pro Event Zusagen, Absagen und ausstehende Antworten.
• Kindbezogene Teilnehmerliste über alle aktiven Kinder der Kita.
• Server Action für Zu-/Absage eines eigenen aktiven Kindes, inklusive Prüfung von Kita, Haushalt, bestätigtem Termin und Frist.
• Fehlt eine eigene Frist, gilt der Eventbeginn als Rückmeldeschluss. Eine bestehende Antwort kann bis dahin überschrieben werden.
• Teilnehmerhinweise werden im Kalender bei Admin/Koordinator und bei einem Haushalt mit mindestens einer Zusage angezeigt.

Aktueller Stand: Die Eltern-Eingabekomponente RsvpActionCard existiert, wird aber von keiner Seite verwendet. Eltern besitzen deshalb im aktuellen Seitenaufbau keinen eingebundenen Zu-/Absagedialog. Außerdem wird participantInfo bereits an den Kalender-Client übertragen und nur bei der Darstellung ausgeblendet; die Anzeigeprüfung ist keine serverseitige Zugriffsbeschränkung für diese Information.

Quellen: RSVP-Aktionen, Event-Verwaltung, ungebundene Elternkomponente, Kalenderdaten.

4.12 Krank- und Abwesenheitsmeldungen

• Eigenes aktives Kind aus dem Haushalt auswählen und für einen Tag oder Zeitraum abmelden.
• Gründe: Krankheit, Urlaub und Sonstiges; optionale Notiz bis 500 Zeichen.
• Ende darf nicht vor dem Beginn liegen; sich überschneidende Meldungen desselben Kindes werden abgewiesen.
• Eigene laufende/bevorstehende Meldungen anzeigen und löschen.
• Tagesübersicht für Admin, Koordinator und Erzieherrolle mit Kind, Familie, Grund, Zeitraum und Notiz.
• Tagesnavigation zurück/vor/heute und freie Datumswahl.
• Grundfilter, Kennzahlen und Hinweise zu Wochenende, Schließtag/Teamtag sowie Tagen mehr als 30 Tage in der Zukunft.
• Abwesenheiten sind nicht als echte Anwesenheitserfassung mit Check-in/Check-out implementiert; „anwesend“ ist aus Kinderzahl minus Meldungen abgeleitet.

Einschränkungen: Gruppen „Krippe“ und „Elementar“ werden aus dem ersten Zeichen des Kindernamens künstlich abgeleitet (mockGroup). Das Datenmodell hat keine echte Gruppenzuordnung. Die Anwesenheitszahl dieser Ansicht verwendet die gefilterten Fehlmeldungen bei weiterhin gesamter Kinderzahl und kann deshalb bei aktivem Filter irreführend sein. Eine bestehende Abwesenheit kann nur gelöscht und neu gemeldet, nicht direkt bearbeitet werden.

Quellen: Abwesenheitsaktionen, Elternformular, Tagesübersicht, Filter.

4.13 Wöchentlicher Dienstplan

• Separater Dienstplan für Haushalte, unabhängig von festen personenbezogenen Ämtern und Notdienst.
• Diensttypen mit Name/Beschreibung anlegen und löschen.
• Wochenraster mit wählbarem Beginn und Zeitraum; Standard zwölf Wochen, maximal 104 Wochen.
• Haushalt je Diensttyp/Kalenderwoche auswählen oder Zuordnung entfernen; Änderungen werden direkt gespeichert.
• Kita-Zugehörigkeit von Diensttyp und Familie wird geprüft.
• Einteilungen erscheinen im gemeinsamen Kalender.
• Manuelle Erinnerungsaktion für noch nicht erinnerte geplante Dienste, deren Beginn in der aktuellen Woche liegt.
• Versand an verifizierte Benutzer der Familie; erfolgreicher Versand wird mit reminderSentAt gespeichert. Erneute Zuordnung setzt diesen Wert zurück.

Einschränkungen: Kein automatisch laufender Erinnerungsjob. Status DONE und CANCELLED existieren im Datenmodell, aber ein regulärer Abschluss-/Stornoablauf ist nicht eingebunden. Eine Änderung setzt den Dienst wieder auf PLANNED. Das Löschen eines Diensttyps löscht durch die Datenrelationen auch dessen Einteilungen.

Quellen: Dienstplanseite, Raster, Dienstaktionen.

4.14 Schwarzes Brett, E-Mail und Anhänge

• Admins können eine Ankündigung mit Titel und Markdown-Inhalt erstellen; Vorschau ist im Formular vorhanden.
• PDF-, JPG- und PNG-Anhänge bis zehn MB je Datei.
• Speicherung der Anhangdateien auf dem Server und der Metadaten in der Datenbank.
• Abruf über geschützte API mit Prüfung auf angemeldeten Benutzer und dieselbe Kita; keine Auslieferung über ein öffentliches Uploadverzeichnis.
• Optionaler E-Mail-Versand an verifizierte Haushaltskonten, Erzieherkonten oder beide Gruppen. Die Auswahl betrifft E-Mail-Empfänger und wird nicht als Sichtbarkeitsgruppe der Meldung gespeichert.
• Adminseite zeigt die letzten acht veröffentlichten Meldungen mit Autor, Zeitpunkt und Anhanganzahl.
• Bei Dateischreibfehlern werden die neue Meldung und angefangene Dateien zurückgenommen; bei Mailfehlern bleibt die Meldung gespeichert und eine Warnung wird zurückgegeben.
• Lesestatusmodell und Aktion zum Markieren als gelesen sind vorhanden; NewsTicker enthält einen vorbereiteten Meldungsdialog.

Aktueller Stand: NewsTicker ist nicht in das Dashboard oder eine andere Seite eingebunden. Eltern können neue Meldungen daher derzeit über den optionalen Mailversand erhalten, besitzen aber keine eingebundene Meldungsliste in der App. Eine Adminauswertung der Lesebestätigungen sowie Bearbeiten/Löschen von Meldungen sind nicht umgesetzt.

Quellen: Meldungsaktionen, Adminseite, Formular, ungebundener Ticker, Anhang-API.

4.15 Adressbuch

• Interne Übersicht der Haushalte, bei denen mindestens ein Benutzer der Kontaktfreigabe zugestimmt hat.
• Anzeige von Haushaltsname, Kindern, Elternnamen und festen Ämtern; alphabetische Gruppierung nach Haushaltsnamen.
• E-Mail, Telefon und Adresse werden nur für den jeweiligen Benutzer mit Opt-in geladen.
• Suche nach Familienname, Eltern-/Kindernamen oder sichtbarer E-Mail.
• Filter für Telefonnummer, Ämter und Haushalte mit Opt-in aller zugeordneten Benutzer.
• Detaildialog je Familie; E-Mail- und Telefonlinks starten den jeweiligen Mail-/Telefonhandler.
• Sichtbarkeitsdialog erklärt die Freigabe und führt zum eigenen Profil.
• Optionales Geburtsdatum eines Kindes ist im Detaildialog sichtbar.

Einschränkung: Namen und Ämter eines zweiten Elternteils ohne Kontaktfreigabe sowie Kinderinformationen sind innerhalb eines sichtbaren Haushalts weiterhin sichtbar. Die Freigabe ist technisch kein Opt-in für sämtliche Haushaltsinformationen.

Quellen: Adressbuchdaten, Adressbuchoberfläche.

4.16 ErzieherInnen-Stammdaten

• Admins können Fachkräfte mit Vor- und Nachname anlegen, bearbeiten und löschen.
• Aktivstatus wird gepflegt und dargestellt.
• Diese Datensätze sind keine Login-Konten; die separate Benutzerrolle ERZIEHER ist hiervon unabhängig.
• Referenz für Notdienstalarme im Datenmodell vorhanden, aber derzeit keine Fachkraftauswahl im Alarmauslöser.

Quellen: Erzieheraktionen, Erzieheroberfläche.

4.17 Systemweite Superadmin-Verwaltung

• Übersicht aller Kitas mit Slug, Modulstatus, Benutzer-/Familien-/Kinderzahlen, Terminen, Abwesenheiten, Meldungen, offenen Einladungen und letztem Login.
• Hinweise auf Benutzer ohne Kita, Kontosperren, fehlende Datenschutzzustimmung und Familien ohne Benutzer.
• Kita-Diagnose mit Benutzerliste, Rollen, Familien, Verifikationsstatus, Consent, Fehlversuchen und Sperren; zusätzlich Zähler für Konten ohne Passwort und abgelaufene Einladungen.
• Diagnoseaufrufe werden im Audit-Protokoll gespeichert.
• Kita endgültig löschen nach exakter Namensbestätigung, mit kaskadierender Löschung abhängiger Datenbankdatensätze.
• Kita-gebundene Benutzer löschen nach Bestätigung ihrer E-Mail-Adresse; dabei zugehörige Verifikationstokens entfernen.
• Benutzer für weitere Logins sperren, entsperren oder Fehlversuche zurücksetzen. Sperrung setzt lockedUntil weit in die Zukunft; Entsperren löscht die Sperre und setzt den Zähler zurück.
• Eigene und andere Superadmin-Konten sowie Konten ohne Kita werden durch diese Support-Aktionen nicht verändert.
• Auditansicht zeigt die neuesten 200 Einträge samt Akteur, Ziel, Zeitpunkt, Aktion und Metadaten. Protokolle können auch nach Löschung der Zielobjekte bestehen bleiben.

Einschränkungen: Offene und abgelaufene Einladungen werden über Invitation gezählt, während die tatsächlichen Familien-Einladungen VerificationToken nutzen. Eine Superadmin-Benutzerlöschung entfernt nicht automatisch einen nun leeren Haushalt. Eine Sperre wird bei der Anmeldung geprüft; das sofortige Beenden bereits bestehender Sessions ist nicht umgesetzt.

Quellen: Adminübersicht und Diagnose-Daten, Support-Aktionen, Auditseite.

5. Datenmodell und technische Querschnittsfunktionen

• PostgreSQL mit Prisma. Eine Kita ist ein Mandant; fachliche Daten sind über kitaId zugeordnet.
• Datenmodelle für Kitas, Benutzer, Haushalte, Kinder, Fachkräfte, feste Ämter, Diensttypen/-einteilungen, Abwesenheiten, Meldungen, Anhänge, Lesestatus, Termine, Teilnahme, Mitbringsel, Notdienstpläne/-verfügbarkeiten/-einteilungen/-alarme/-tausche sowie Auditprotokolle und Tokens.
• Eindeutigkeitsregeln unter anderem für E-Mail, Kita-Slug, Monatsplan, Einteilung je Plantag, Verfügbarkeit je Kind/Tag, Teilnahme je Event/Kind und Amt je Benutzer.
• Eingabeprüfung überwiegend mit Zod, Schreibabläufe teilweise als Datenbanktransaktionen, Aktualisierung von Seiten nach Änderungen.
• Gemeinsamer E-Mail-Versand über Resend mit Fehlerbehandlung. Ohne API-Key werden E-Mails nur in der Entwicklungsumgebung simuliert; diese Simulation bestätigt keine Zustellung.
• Vorlagen für Einladung, Alarm, Verfügbarkeitserinnerung, Einteilungsänderung, Diensttausch, Wochen-Diensterinnerung, News und Kontakt. Eine weitere Vorlage für erstmalige Notdienst-Zuteilung ist vorhanden, aber nicht an die Veröffentlichung angebunden.
• Rollen-, Kita- und Consent-Prüfungen über gemeinsame Helfer. Geschützte Dashboard-/Adminlayouts, Seiten und Aktionen setzen Zugriffsprüfungen ein; nicht jede Aktion verwendet denselben Consent-Helfer.
• Viele Datenbankrelationen löschen abhängige Datensätze mit. Das ist nicht gleichbedeutend mit vollständiger Bereinigung von Dateien, allgemeinen Verifikationstokens oder Audit-Snapshots.
• Der Hilfsmodus TEST_MODE=true liefert in requireRole und requireKitaSession künstliche Sessions und umgeht dort die regulären Prüfungen. Er ist nicht auf die Entwicklungsumgebung begrenzt.

Quelle: Schema, Mail, Auth-Helfer.

6. Seiten- und Schnittstellenverzeichnis

Route	Zweck/Zugriff
/	Öffentliche Startseite und Kontakt.
/features/notdienst-planer	Öffentliche Notdienst-Beschreibung.
/features/kita-kalender	Öffentliche Kalender-Beschreibung.
/features/eltern-adressbuch	Öffentliche Adressbuch-Beschreibung.
/features/krankmeldung	Öffentliche Abwesenheits-Beschreibung.
/features/schwarzes-brett	Öffentliche Meldungs-Beschreibung.
/impressum, /datenschutz	Öffentliche Informationsseiten mit noch offenen Platzhaltern.
/register, /login	Gründerregistrierung und Anmeldung.
/onboarding	Kita einrichten nach Anmeldung.
/onboarding/consent	Hinweis bei fehlender Datenschutzannahme.
/invite/[token]	Elternkonto über Einladungslink aktivieren.
/alert/[token]	Notdienstalarm über Link bestätigen.
/forbidden	Hinweis bei verweigertem Zugriff.
/dashboard	Kita-Übersicht und eigene Abwesenheiten.
/dashboard/profil	Eigener Haushalt, Kinder, Kontakte und Kontolöschung.
/dashboard/notdienst	Verfügbarkeiten; Eltern, Admin, Koordinator.
/dashboard/notdienst/plan	Planung; Admin, Koordinator.
/dashboard/kalender	Kita-Kalender und Diensttausch.
/dashboard/adressbuch	Internes Adressbuch.
/dashboard/families	Familien und feste Ämter; Admin.
/dashboard/erzieher	Fachkraft-Stammdaten; Admin.
/dashboard/admin/dienste	Wochen-Dienstplan; Kita-Admin. Die Aktion erlaubt zusätzlich Superadmin mit Kita-Kontext.
/dashboard/admin/news	Meldungen veröffentlichen; Admin.
/dashboard/admin/kalender	Termine und Event-Anmeldungen; Admin, Koordinator.
/dashboard/admin/abwesenheiten	Tagesübersicht; Admin, Koordinator, Erzieherrolle.
/admin	Systemweite Kita-Übersicht; Superadmin.
/admin/kitas/[kitaId]	Kita-Diagnose und Benutzersupport; Superadmin.
/admin/audit	Systemweites Audit-Protokoll; Superadmin.
/api/auth/[...nextauth]	Auth.js-Endpunkte.
/api/announcements/attachments/[id]	Geschützter Anhangdownload.
/sitemap.xml, /robots.txt	Suchmaschinensteuerung.

7. Betrieb, Entwicklung und Prüfstand

• Stack laut package.json: Next.js 16.2.4, React 19.2.4, TypeScript, Prisma 6, Auth.js/NextAuth v5 beta, PostgreSQL, Tailwind CSS und Resend.
• Lokaler Entwicklungsstart führt vor Next.js automatisch prisma db push und den Seed aus.
• Seed legt Demonstrationsdaten mit mehreren Rollen und fachlichen Beispielen an; regulärer Seed ist bei bereits befüllter Datenbank zurückhaltend. Ein separater Reset-Modus existiert.
• Docker-Build und Produktionsstart sind vorhanden; Produktionsstart wendet das Schema über prisma db push --skip-generate an. Versionierte Prisma-Migrationen liegen nicht im geprüften Dateibestand.
• Lokale Compose-Datei stellt PostgreSQL bereit; Coolify-Compose enthält App, PostgreSQL, pgAdmin und persistente Datenbank-/Uploadvolumes.
• Umgebungsvariablen-Vorlage und Produktionscheckliste sind vorhanden; ihre tatsächliche Erfüllung wurde nicht auf einem Server geprüft.
• UPLOAD_DIR ist persistent vorgesehen. Die Dateihilfsfunktionen hängen noch announcements an diesen Pfad an; bei der aktuellen Compose-Konfiguration ergibt sich /app/uploads/announcements/announcements.
• Kein Testskript und keine automatisierte Testdateisuite im geprüften Repository gefunden. Demo-Seed und manueller Live-Testplan ersetzen keine automatisierten Tests.

Ausgeführte technische Prüfungen

Die Prüfungen liefen auf dem unveränderten Ausgangscheckout mit den dort bereits installierten Abhängigkeiten. Es wurden keine Bibliotheken installiert und keine Builds oder Datenbankoperationen ausgeführt.

Prüfung	Ergebnis
./node_modules/.bin/tsc --noEmit --incremental false	Erfolgreich, Exit-Code 0.
npm run lint	Fehlgeschlagen, Exit-Code 1: zwei Fehler und neun Warnungen.
Quellenprüfung von Seiten, Aktionen, Komponenten und Schema	Durchführung für die oben beschriebenen Funktionsbereiche.
Aktueller Browser-/End-to-End-Test	Nicht durchgeführt.
Mailzustellung und produktives Deployment	Nicht geprüft.

Beide ESLint-Fehler betreffen as any im Testmodus von src/lib/auth-utils.ts (Zeilen 57 und 91). Die Warnungen betreffen ungenutzte Variablen/Imports im Seed, Kalender, Adressbuch und Abwesenheiten. Diese Bestandsaufnahme ändert keinen Anwendungscode.

Der vorhandene Live-Testplan vom 17.05.2026 dokumentiert erfolgreiche Tests von Landingpage/Kontakt, Gründerregistrierung, Einrichtung, Dashboard, Familienanlage und Teilen des Login-Ablaufs. Eltern-Einladungsaktivierung und anschließende Bereinigung sind dort noch offen. Dies sind historische Einträge, keine aktuellen Testnachweise für den geprüften Commit. Die abgehakten Punkte in UI-TODO.md sind ebenfalls historische Angaben; viele der dort ehemals fehlenden Handler sind inzwischen im Code vorhanden.

Quellen: Paket und Skripte, Deployment, Produktionscheckliste, Seed, Coolify-Compose.

8. Konkrete offene Punkte für die weitere Arbeit

Die Reihenfolge ist ein Vorschlag aus der Bestandsaufnahme; es wurde nichts davon umgesetzt.

Reihenfolge	Thema	Konkreter nächster Schritt
1	Fehlende Elternabläufe	NewsTicker und RSVP-Eingabe an eine erreichbare Seite anbinden; Daten dafür laden.
2	Notdienstalarm	Auslösebutton, Fachkraftauswahl und Statusanzeige in den aktuellen Seitenaufbau integrieren.
3	Moduldeaktivierung	Modulschalter in Navigation, Seiten und Server Actions einheitlich prüfen; spätere Einstellungen anbieten.
4	Notdienstregeln	Wochenenden/Schließtage serverseitig ausschließen und Generierung um Schließtage ergänzen; Abwesenheitsregel festlegen.
5	Erinnerungen	Automatische Ausführung ergänzen und unterscheiden, ob gar keine oder zu wenige Verfügbarkeiten vorliegen.
6	Erstveröffentlichung	Zuteilungsmails beim Veröffentlichen anbinden und Mailfehler sichtbar behandeln.
7	Einladungssupport	Tokenmodell und Superadmin-Zähler vereinheitlichen; erneuten Versand, Ablauf und Widerruf erreichbar machen.
8	Rechtevergabe	Regulären Ablauf für Koordinator-/Erzieherkonten und Rollenänderungen ergänzen.
9	Abwesenheitsgruppen	Echte Gruppenzuordnung einführen oder den künstlichen Gruppenfilter entfernen; Kennzahlen konsistent berechnen.
10	Buchungskonflikte	Fachliche Reservierungsregeln definieren und Überschneidungen serverseitig prüfen.
11	Selbstverwaltung	Passwort-Reset/-Änderung und direkte Bearbeitung von Abwesenheiten/Mitbringbeiträgen ergänzen.
12	Löschabläufe	Kinderlöschung bei bestehenden Verpflichtungen prüfen; Anhangdateien und Tokens bei Kita-/Kontolöschungen bereinigen; Audit-Aufbewahrung gesondert definieren.
13	Zugriffsprüfungen	Testmodus an Entwicklungsumgebung binden; Consent-/Session-Prüfungen und Teilnehmerhinweise serverseitig vereinheitlichen.
14	Technischer Zustand	Zwei ESLint-Fehler beheben, Migrationsablauf einführen und aussagekräftige Tests für die zentralen Abläufe ergänzen.
15	Aktuelle Abnahme	Rollenbasierte Browserprüfung, Mailzustellung, Elternaktivierung und Bereinigung anhand eines aktualisierten Testplans durchführen.
16	Öffentliche Texte	Platzhalter in Impressum/Datenschutz mit den tatsächlichen Betriebsangaben vervollständigen und Marketingversprechen mit dem implementierten Verhalten abgleichen.

9. Nicht als fertige Produktfunktion vorhanden

Im geprüften Code wurden kein Abonnement-/Zahlungsablauf, keine Import-/Exportverwaltung für Familien, kein externer Kalenderabgleich, keine Push-/SMS-Alarmierung, keine echte Kita-Gruppenverwaltung und keine Zeiterfassung/Check-in-Funktion gefunden. Vorhandene Planungs- oder Marketingtexte sind dafür kein Umsetzungsnachweis.