kita-planer/docs/ABLAUFPRUEFUNG.md

# Prüfung der Bedienabläufe im Kita-Planer

Stand: 9. Oktober 2026 · geprüfter Code: `4702bf5abb0037ab9e0913dbef01ffbe21bbb96d` (`origin/main` zum Prüfzeitpunkt).

Fortschreibung: F01 (Familieneinladungen), F02 (Abwesenheitsverwaltung) und die Entfernung des künstlichen Gruppenfilters aus F12 wurden anschließend auf `codex/family-absence-flows` bearbeitet. Den neuen Ablauf und die Deployment-Schritte beschreibt [Familien und Abwesenheiten](FAMILIEN_UND_ABWESENHEITEN.md). F03, F04 und F05 (Verfügbarkeit bei manueller Zuweisung sowie Erstveröffentlichung) sind inzwischen ebenfalls umgesetzt; den aktuellen Stand und die Prüfungen dokumentiert die Ergänzung vom 12.10.2026 in [Funktionsübersicht](FUNKTIONSUEBERSICHT.md). F06 (Agenda-Details und Mitbringen), F09 (Arbeitszeitkontext und Ein-Tages-Anträge), F10 (personenbezogene Ämter-Schaltflächen) und F11 (Passwort-Wiederherstellung/-Änderung) sind ebenfalls umgesetzt; F08 enthält nun kontoabhängiges Ausblenden des Einrichtungshinweises. Die weiteren Teile von F08 und F11 bleiben durch diese Ergänzung unberührt. F07 (Mitteilungskorrektur, Verwaltung älterer Beiträge und getrennte Versandwiederholung) ist mit der Ergänzung vom 13.10.2026 ebenfalls umgesetzt. Die folgenden Befunde dokumentieren weiterhin den ursprünglichen Prüfstand.

## Umfang und Methode

Geprüft wurden die zentralen Abläufe für Eltern, Fachkräfte, Kita-Admins und Notdienst-Koordination: Einrichtung, Familien, Profile, Einladungen, Abwesenheiten, Arbeitszeit und Urlaub, Kalender und Anmeldungen, Mitteilungen, Dienste, Notdienstplanung und Alarmierung. Login, Kontoverwaltung und die Superadmin-Oberflächen wurden ergänzend im Quellcode geprüft.

Grundlage sind die aktuellen Seiten, Formulare, Server-Aktionen und Datenmodelle. Einzelne Abläufe wurden zusätzlich in einer lokalen Vorschau mit synthetischen Testkonten nachvollzogen: Familienverwaltung, Eltern-Abwesenheiten sowie Kalender in Agenda- und Listenansicht. Dabei wurden keine fachlichen Datensätze angelegt, geändert oder gelöscht und keine E-Mails verschickt. Die produktive Website wurde nicht getestet.

Die folgenden Befunde beschreiben den bestehenden Stand. Die vorgeschlagenen Zielabläufe sind noch nicht umgesetzt. Diese Prüfung ist kein vollständiger Sicherheitstest oder Test aller Berechnungen. Die ältere `FUNKTIONSUEBERSICHT.md` wurde nicht als Beleg für fehlende Funktionen verwendet: Kalender-Anmeldungen, Mitteilungen, Personalverwaltung und Notdienstalarm sind inzwischen vorhanden.

## Bereits mit dem Nutzer geklärt

- Eltern dürfen eigene Abwesenheitsmeldungen **für zukünftige Tage** ändern und zurücknehmen. Für laufende Tage ist die Kita zuständig.
- **Kita-Admins dürfen innerhalb ihrer eigenen Kita weitere Admins und die Notdienst-Koordination ernennen.**

Diese Regeln sind für die spätere Umsetzung verbindlich. Die Datumsregel muss auch auf dem Server gelten. Für Meldungen, die einen laufenden und zukünftige Tage umfassen, ist die Behandlung des zukünftigen Teilzeitraums noch zu konkretisieren.

## Prioritäten

„Hoch“ bezeichnet einen blockierten Ablauf, widersprüchliche Rückmeldungen oder fachlich irreführende Angaben. „Mittel“ bezeichnet vermeidbare Nacharbeit oder einen fehlenden direkten Weg. „Niedrig“ bezeichnet kleinere Verbesserungen bei Benennung und Orientierung.

| ID | Priorität | Bereich | Wichtigster Befund |
| --- | --- | --- | --- |
| F01 | Hoch | Familieneinladungen | Gespeicherte Familie erscheint bei Mailfehler als fehlgeschlagener Vorgang; erneutes Senden fehlt. |
| F02 | Hoch | Kinder-Abwesenheiten | Elternlink führt zu „Zugriff verweigert“; Ändern und Zurücknehmen fehlen. |
| F03 | Hoch | Notdienst-Erinnerungen | Oberfläche verspricht Automatik, die Einstellung wird dafür nicht verwendet; unvollständige Rückmeldungen werden übergangen. |
| F04 | Hoch | Rollenverwaltung | Weitere Kita-Admins und Koordination lassen sich nicht regulär ernennen. |
| F05 | Mittel | Notdienstplan | Manuelle Einteilung zeigt Verfügbarkeit nicht am Auswahlpunkt; Erstveröffentlichung verschickt keine Nachricht. |
| F06 | Mittel | Kalender und Mitbringen | Funktionen hängen von der Ansicht ab; Mitbring-Einträge lassen sich nur löschen und neu anlegen. |
| F07 | Mittel | Mitteilungen | Korrektur und gezieltes erneutes Senden fehlen. |
| F08 | Mittel | Eigene Ersteinrichtung | Haushalt, Kinder und Kontakt werden separat gespeichert; Admins ohne eigene Kinder gelten als unvollständig. |
| F09 | Mittel | Personal | Neue Zeiterfassung verliert den betrachteten Zeitraum; Ein-Tages-Anträge verlangen zweimal das Datum. |
| F10 | Niedrig | Ämter und Dienste | Gleich benannte Ämter-Schaltflächen lassen die betroffene Person erst nach dem Öffnen erkennen. |
| F11 | Mittel | Zugang und Wiederherstellung | Passwort-Wiederherstellung fehlt; alte Aktivierungslinks und seltene Alt-Konten enden in Sackgassen. |
| F12 | Hoch / Niedrig | Filter und Anzeigen | Abwesenheitsgruppen sind aus Namen erfunden; die Notdienst-Zahl im Menü ist fest eingetragen. |

## F01 – Familieneinladungen sauber abschließen und erneut senden

**Aktueller Ablauf:** Admin legt eine Familie samt Eltern und Kindern an. Die Datenbank speichert die Familie, Konten und Aktivierungslinks. Anschließend werden die Einladungsmails versendet. Scheitert eine Mail, meldet die Aktion einen Formularfehler; der erfolgreiche Abschluss und die Aktualisierung der Ansicht bleiben aus. Ein erneuter Speicherversuch kann dann an den bereits angelegten E-Mail-Adressen scheitern. Bei mehreren Einladungen stoppt der Versand bereits beim ersten Fehler.

Die Familienliste zeigt offene Einladungen, bietet aber weder dort noch in „Details“ eine Funktion zum erneuten Senden. Das wurde im lokalen Browser bestätigt. Auch der Hinweis eines abgelaufenen Aktivierungslinks, beim Admin einen neuen Link anzufordern, hat damit keinen passenden Bedienweg.

**Vorgeschlagener Zielablauf:** Familie einmal anlegen → Erfolg anzeigen und Liste aktualisieren → Versandstatus je Elternteil anzeigen → bei Bedarf ausschließlich die Einladung erneut senden. Der Datensatz bleibt unabhängig vom Mailversand erfolgreich angelegt. Fehlgeschlagene Mails werden gespeichert und gezielt wiederholt; weitere Empfänger werden trotz eines einzelnen Fehlers bearbeitet.

**Belege:** `src/app/dashboard/families/actions.ts:125`, `:277`, `:459`; `src/app/dashboard/families/add-family-dialog.tsx`; `src/app/dashboard/families/_components/families-list-client.tsx`; `src/app/dashboard/families/edit-family-dialog.tsx`.

**Abnahme:** Simulierter Mailfehler führt zu genau einer Familie, sichtbarem Versandfehler und einem funktionierenden erneuten Senden ohne erneute Personeneingabe. Der kürzlich verbesserte Fachkräfte-Ablauf dient als Vorlage.

## F02 – Eigene Abwesenheiten direkt verwalten

**Aktueller Ablauf:** Eltern melden ein Kind ab und sehen die Meldung auf der Übersicht. Dort fehlen Änderungs- und Rücknahmeaktionen. „Alle Abwesenheiten“ führt auf eine Seite, die nur Admins, Koordination und Fachkräfte betreten dürfen. Der Elternaccount erreicht im lokalen Browser „Zugriff verweigert“.

Die vorhandene Server-Aktion `deleteAbsence` wird von keiner Oberfläche verwendet. Sie prüft die Haushaltszugehörigkeit, aber bisher keine Beschränkung auf zukünftige Tage. Eine Aktion zum Ändern fehlt. Die Kita-Übersicht bietet ebenfalls nur die Anzeige, keinen direkten Korrekturweg für laufende Meldungen.

**Vorgeschlagener Zielablauf:** „Meine Abwesenheiten“ → Meldung ansehen → zukünftige Tage bearbeiten oder zurücknehmen. Für laufende Tage führt ein verständlicher Hinweis zur Kita; berechtigte Kita-Nutzer können die Meldung in ihrer Übersicht korrigieren. Eltern bekommen eine eigene Haushaltsansicht. Die kitaweite Übersicht behält ihre bestehenden Zugriffsgrenzen.

**Belege:** `src/app/dashboard/absence-card.tsx:234`, `:241`; `src/app/dashboard/admin/abwesenheiten/page.tsx:16`; `src/actions/absences.ts:107`; `src/app/dashboard/admin/abwesenheiten/absence-table.tsx`.

**Abnahme:** Eltern erreichen ihre Meldungen ohne Zugriffsfehler. Änderungen gelten nur für den eigenen Haushalt und die erlaubten Tage; Kita-Korrekturen sind innerhalb derselben Kita möglich. Für die Datumsgrenze gilt die lokale Kita-Zeitzone.

## F03 – Notdienst-Einstellungen und Erinnerungen verständlich machen

**Aktueller Ablauf:** „Mindesteinteilungen pro Kind/Monat“ wird als Richtmaß der automatischen Verteilung erklärt. Tatsächlich bestimmt der Wert die erforderliche Anzahl gemeldeter Verfügbarkeiten. „Erinnerungsfrist“ verspricht automatische E-Mails; im geprüften Code wird die Einstellung gespeichert und angezeigt, aber von keinem Erinnerungsjob ausgewertet. Die Eingabesperre folgt stattdessen dem fest codierten Stichtag 26. Der vorhandene Notdienstalarm-Job betrifft Alarm-Erinnerungen und ersetzt diese Verfügbarkeits-Erinnerung nicht.

Die manuelle Erinnerungsaktion behandelt eine Familie schon nach einem einzigen Verfügbarkeitseintrag als beantwortet. Familien unterhalb ihrer geforderten Anzahl werden dadurch nicht angeschrieben. Einzelne Versandfehler landen im Log; die Oberfläche zeigt nur die Anzahl erfolgreicher Mails. Erneutes Auslösen wiederholt auch bereits erfolgreich versendete Mails.

Zusätzlich kann die Planung einen beliebigen Monat anzeigen. Der Link in einer Erinnerung führt dagegen ohne Monatsangabe zur Elternseite, die den nächsten Monat öffnet. Erinnerung und Eingabe können dadurch unterschiedliche Monate betreffen.

**Vorgeschlagener Zielablauf:** „Erforderliche Verfügbarkeiten“ und tatsächlichen Abgabeschluss klar benennen → Rücklauf als „fehlt / unvollständig / vollständig“ zeigen → Empfänger vor dem Versand sichtbar machen → Versandstatus und gezieltes Wiederholen anbieten. Eine automatische Erinnerung benötigt einen echten Job und eine passende Einstellung. Erinnerungen müssen den betroffenen Monat öffnen oder auf den tatsächlich bearbeitbaren Monat beschränkt sein.

**Belege:** `src/app/dashboard/notdienst/plan/_components/settings-modal.tsx:76`, `:95`; `src/app/dashboard/notdienst/page.tsx:52`; `src/lib/date-utils.ts:14`; `src/app/dashboard/notdienst/plan/actions.ts:426`, `:485`, `:503`, `:532`.

**Abnahme:** Texte entsprechen der tatsächlichen Berechnung und Automatik. Auch teilweise ausgefüllte Haushalte werden berücksichtigt. Der E-Mail-Link führt zur richtigen Eingabe; fehlgeschlagene Zustellungen können einzeln wiederholt werden.

## F04 – Rollen dort verwalten, wo Personen verwaltet werden

**Aktueller Ablauf:** Registrierung und Kita-Einrichtung erzeugen den ersten Admin. Familienanlage erzeugt Elternkonten; die Fachkräfte-Anlage erzeugt Fachkraftkonten. Es gibt keinen regulären Weg, einen weiteren Kita-Admin oder eine Notdienst-Koordination zu ernennen. Auch die Superadmin-Aktionen bieten keine Rollenänderung.

Ein festes Amt wie „Vorstand“ ist eine gesonderte Zuordnung und verleiht keine Admin-Rechte. Diese Trennung ist in der Bedienung nicht ausreichend erkennbar.

**Vorgeschlagener Zielablauf, vom Nutzer bestätigt:** Kita-Admin öffnet eine Person innerhalb seiner Kita → wählt deren Zugriffsrolle → speichert die Änderung. Zuständigkeiten/Ämter und Zugriffsrechte erhalten klar getrennte Bezeichnungen. Mindestens ein erreichbarer Kita-Admin muss bestehen bleiben. Dies muss auch bei der eigenen Kontolöschung berücksichtigt werden: `deleteMyAccount` prüft derzeit Notdienst-Verpflichtungen, aber keine letzte Admin-Rolle.

**Belege:** `src/app/register/actions.ts:91`; `src/app/onboarding/actions.ts:130`; `src/app/dashboard/families/actions.ts:236`, `:404`; `src/app/admin/actions.ts`; `src/app/dashboard/families/duty-manager.tsx`; `src/app/dashboard/profil/actions.ts:286`.

**Abnahme:** Rollenänderungen wirken innerhalb der eigenen Kita und sind nachvollziehbar. Ein Amt allein verändert keine Berechtigungen. Bestehende Fachkraftprofile und Haushaltszuordnungen werden bei einer Rollenänderung ausdrücklich berücksichtigt.

## F05 – Manuelle Notdienstplanung ohne Gegenprüfung in einer zweiten Ansicht

**Aktueller Ablauf:** Bei der manuellen Einteilung enthält die Auswahl sämtliche aktiven Kinder samt Familie und bisheriger Einteilungszahl. Ob die Familie am gewählten Tag verfügbar ist, steht nicht in dieser Auswahl. Die Koordination muss die Verfügbarkeit in einer anderen Ansicht prüfen. Geschwister erscheinen als separate Auswahlmöglichkeiten für denselben Haushalt.

Beim erstmaligen Veröffentlichen wird der Plan freigegeben, aber keine E-Mail versendet. Spätere Änderungen können dagegen Benachrichtigungen auslösen. Das ist eine uneinheitliche Kommunikation; eine Mail zur Erstveröffentlichung ist ein Verbesserungsvorschlag, bisher keine bestätigte Produktregel.

**Vorgeschlagener Zielablauf:** Tag auswählen → verfügbare Haushalte direkt erkennen → Einteilung vornehmen. Andere Haushalte bleiben für bewusst begründete Sonderfälle auswählbar und sind gekennzeichnet. Veröffentlichung bietet einen klar bezeichneten Schritt zur Information der Familien mit sichtbarem Versandstatus.

**Belege:** `src/app/dashboard/notdienst/plan/page.tsx:118`; `src/app/dashboard/notdienst/plan/plan-view.tsx:643`; `src/app/dashboard/notdienst/plan/actions.ts:139`, `:353`.

Der Übergang vom Plan zum Notdienstalarm ist dagegen bereits sinnvoll: Der Link übergibt die konkrete Einteilung, sodass diese im Alarmformular nicht erneut gesucht werden muss.

## F06 – Kalenderfunktionen in jeder Ansicht erreichbar machen

**Aktueller Ablauf:** Die Listenansicht bietet „Details“ einschließlich Mitbring-Liste. Die Monatsansicht bietet diese Inhalte über den Tagesdialog. Die Agenda zeigt zwar Termine und RSVP-Antworten, bietet aber keinen entsprechenden Detailzugang und keine Mitbring-Liste. Eltern müssen die Ansicht wechseln, um denselben Termin vollständig zu bearbeiten. Der Unterschied wurde im lokalen Browser bestätigt.

Mitbring-Einträge besitzen nur Hinzufügen und Löschen. Eine Mengenänderung oder ein Tippfehler erfordert Löschen und erneute Eingabe.

**Vorgeschlagener Zielablauf:** Einheitlicher Termindialog aus Monat, Agenda und Liste → Beschreibung, Anmeldung und Mitbringen am selben Ort. Eigene Mitbring-Einträge lassen sich direkt bearbeiten. Bestehende Berechtigungen für fremde Einträge bleiben maßgeblich. Aktueller Zeitraum und Filter bleiben beim Öffnen und Schließen erhalten.

**Belege:** `src/app/dashboard/kalender/_components/calendar-overview-client.tsx:329`, `:856`; `src/app/dashboard/kalender/_components/termin-list.tsx:326`, `:429`; `src/app/dashboard/kalender/_components/mitbringsel-list.tsx:32`, `:46`; `src/app/dashboard/kalender/actions.ts:1048`, `:1089`.

Die Anmeldung pro Familie oder Kind ist bereits vorhanden und integriert. Sie muss dafür nicht neu gebaut werden.

## F07 – Mitteilungen korrigieren und Versand unabhängig wiederholen

**Aktueller Ablauf:** Admins können eine Mitteilung erstellen und optional per E-Mail versenden. Nach der Veröffentlichung gibt es keine Bearbeitungsfunktion und keinen erneuten Versand. Die Admin-Seite zeigt nur die letzten acht Mitteilungen, ohne weiterführende Verwaltungsansicht. Eine Korrektur führt deshalb praktisch zu einem weiteren Beitrag; ein Mailfehler hat keinen Wiederholungsweg.

Positiv: Die Aktion behandelt einen Mailfehler bereits als Warnung zu einer erfolgreich gespeicherten Mitteilung. Die Familienanlage sollte denselben verständlichen Abschluss bieten.

**Vorgeschlagener Zielablauf:** Veröffentlichte Mitteilung öffnen → Inhalt korrigieren und Änderungsstand sichtbar machen → bei Bedarf über die Korrektur informieren. Für den Versand gibt es einen eigenen Status und eine gezielte Wiederholung. Ältere Mitteilungen bleiben für Admins verwaltbar.

**Belege:** `src/actions/announcements.ts:80`, `:172`, `:203`, `:211`; `src/app/dashboard/admin/news/page.tsx:50`, `:116`.

## F08 – Die eigene Ersteinrichtung zusammenführen und rollenabhängig gestalten

**Aktueller Ablauf:** Wer noch keinen eigenen Haushalt hat, legt zuerst dessen Namen an, schließt den Dialog, legt Kinder in einem anderen Dialog an und ergänzt Kontaktdaten in einem weiteren Formular. Der Einrichtungshinweis verlangt einen Haushalt samt Kindern für alle Rollen außer Fachkräften – also auch für Admins oder Koordination ohne eigene Kita-Kinder.

Dieser Befund betrifft die eigene Ersteinrichtung. Eltern, die über die Familienverwaltung eingeladen wurden, haben ihren Haushalt bereits; dort werden Eltern und Kinder zusammen erfasst.

**Vorgeschlagener Zielablauf:** Eine geführte Einrichtung mit bekannten Angaben, Kontakten und – wenn relevant – Haushalt samt Kindern. Nach jedem Schritt ist der nächste direkt erreichbar. Admins und Koordination können angeben, ob sie auch als Eltern teilnehmen; fehlende eigene Kinder dürfen sonst keinen dauerhaften Unvollständigkeitshinweis erzeugen. Diese Rollenvariante ist noch fachlich zu bestätigen.

Kleine Zusatzkorrektur: „Hinweis dauerhaft ausblenden“ wird heute über einen browserweiten Schlüssel gespeichert. Die Einstellung sollte dem jeweiligen Nutzer zugeordnet sein, damit ein anderes Konto am selben Gerät seine eigenen Hinweise behält.

**Belege:** `src/app/dashboard/profil/_components/create-family-dialog.tsx:29`, `:57`; `src/app/dashboard/profil/page.tsx`; `src/components/OnboardingDialog.tsx:46`, `:55`.

## F09 – Personalformulare mit dem betrachteten Tag verbinden

**Aktueller Ablauf:** „Arbeitszeit erfassen“ erhält nur das Personalprofil. Ein neuer Eintrag startet immer mit dem heutigen Datum, 08:00–16:00 Uhr und 30 Minuten Pause – auch wenn gerade eine andere Woche betrachtet wird. Nach dem Speichern schließt sich das Formular. Für weitere Arbeitsblöcke muss die Fachkraft es erneut öffnen und den Tag wieder wählen.

Freizeitausgleich und halber Urlaubstag verlangen laut Formular „Von = Bis“, zeigen aber zwei unabhängige Datumsfelder. Ein einzelner Tag muss damit zweimal angegeben werden.

**Vorgeschlagener Zielablauf:** „Zeit erfassen“ am konkreten Tag mit vorausgewähltem Datum. „Speichern und weiteren Block erfassen“ behält den Tag bei. Bei Ein-Tages-Anträgen genügt ein Datum; das Ende wird daraus abgeleitet. Tatsächliche Arbeitszeiten bleiben ausdrücklich eingegebene Werte, auch bei festen Arbeitstagen.

Für die erstmalige Personaleinrichtung wäre ergänzend ein geführter Abschluss für Arbeitsmodell, Urlaubskonto und Anfangssaldo hilfreich. Die getrennten Einstellungen sind für spätere Änderungen sinnvoll; die bisher vereinbarte Anlage mit anschließender Profileinrichtung ist daher kein Fehler.

**Belege:** `src/app/dashboard/personal/page.tsx:287`; `src/app/dashboard/personal/forms.tsx:368`, `:375`, `:477`, `:498`, `:643`.

## F10 – Ämter-Schaltflächen eindeutig einer Person zuordnen

**Aktueller Ablauf:** Eine Familie mit zwei Elternkonten bekommt zwei nahezu gleich beschriftete „Ämter“-Schaltflächen. Erst nach dem Öffnen zeigt der Dialog, welches Elternteil gemeint ist. Das wurde im lokalen Browser bestätigt. Ein neues Amt anzulegen und es der gerade geöffneten Person zuzuweisen sind außerdem separate Aktionen.

**Vorgeschlagener Zielablauf:** „Ämter: Vorname“ oder eine gemeinsame Familienansicht mit klar getrennten Personen. Im Personenkontext kann „Amt anlegen und zuweisen“ beide Schritte verbinden.

Die festen persönlichen Ämter und die wechselnden Elterndienste sind fachlich verschiedene Dinge. Verständliche Bezeichnungen sollten diese Unterscheidung sichtbar machen.

**Belege:** `src/app/dashboard/families/_components/families-list-client.tsx:292`; `src/app/dashboard/families/duty-manager.tsx:107`, `:123`; `prisma/schema.prisma` (`ParentDuty`, `DutyType`).

## F11 – Zugang wiederherstellen statt außerhalb der Anwendung lösen

**Aktueller Ablauf:** Im Login fehlt „Passwort vergessen“, im Profil die eigene Passwortänderung. Ein bereits verwendeter Aktivierungslink kann nach dem Löschen des Tokens eine allgemeine 404-Seite liefern. Abgelaufene Links verweisen auf den Admin; bei Familien fehlt dessen erneuter Versandweg aus F01.

Ein seltener Alt-Daten-Fall führt zusätzlich auf „Datenschutz-Einwilligung erforderlich“, bietet dort aber nur einen Verweis an Admin oder Support. Die Seite hat keinen direkten Abschluss; auch die bestehenden Support-Aktionen bieten dafür keinen passenden Korrekturablauf. Der normale Registrierungs- und Einladungsablauf erfasst die Einwilligung bereits.

**Vorgeschlagener Zielablauf:** Passwort-Wiederherstellung über einen zeitlich begrenzten Link; eindeutige Weiterleitung zum Login nach bereits erfolgter Aktivierung; passende Möglichkeit für einen neuen Einladungslink. Alt-Konten können eine fehlende Einwilligung innerhalb der Anwendung nachholen.

**Belege:** `src/app/login/login-form.tsx`; `src/app/dashboard/profil/page.tsx`; `src/app/invite/[token]/page.tsx:39`, `:84`; `src/app/invite/[token]/actions.ts:153`; `src/app/onboarding/consent/page.tsx:46`; `src/app/admin/actions.ts`.

## F12 – Fachliche Filter und Statuszahlen verlässlich anzeigen

**Hoch:** Der Gruppenfilter in der Kita-Abwesenheitsübersicht ordnet Kinder über den Zeichencode des ersten Buchstabens ihres Namens „Krippe“ oder „Elementar“ zu. Das ist keine tatsächliche Gruppenzuordnung. Der Filter kann Kinder aus einer vermeintlich fachlichen Übersicht entfernen und dadurch falsche Schlüsse nahelegen.

**Niedrig:** Das Menü zeigt beim Notdienst fest die Zahl „4“. Sie wird nicht aus offenen Aufgaben berechnet und verändert sich durch deren Erledigung nicht.

**Vorgeschlagener Zielablauf:** Gruppenfilter erst mit einer echten gespeicherten Gruppenzuordnung anbieten; bis dahin ausblenden. Statuszahlen aus den jeweiligen offenen Aufgaben berechnen und ihre Bedeutung benennen oder weglassen.

**Belege:** `src/app/dashboard/admin/abwesenheiten/_components/absences-client.tsx:69`, `:77`; `src/components/dashboard/sidebar-nav.tsx:60`.

## Bereits sinnvolle Abläufe und Prüfungsabdeckung

| Bereich | Ergebnis der Ablaufprüfung |
| --- | --- |
| Fachkraft anlegen und aktivieren | Name, Pflicht-E-Mail und Starttermin gemeinsam; Profilübergang sowie Einladungsstatus und erneutes Senden vorhanden. |
| Familie anlegen | Eltern und Kinder gemeinsam erfassbar; hauptsächlich der Abschluss bei Mailproblemen und der erneute Versand brauchen Verbesserung (F01). |
| Profil und Kinderverwaltung | Eigene Kinder und Kontaktdaten bearbeitbar; Ersteinrichtung und Wiederherstellung siehe F08/F11. |
| Adressbuch | Suchen, Filtern und Kontakt öffnen am selben Ort; Freigabe im Profil ist eine nachvollziehbare gesonderte Einstellung. |
| Kinder-Abwesenheiten | Meldung direkt vom Dashboard möglich; Verwaltung und Gruppenfilter siehe F02/F12. |
| Arbeitszeit und Urlaub | Zeiten, Wochenfreigaben, Anträge, feste Arbeitsmodelle und Konten integriert; Eingabekontext siehe F09. |
| Feiertage im Personalbereich | Eintrag im selben Personalbereich; nicht automatisch mit Kita-Schließtagen gleichsetzen, da Schließtage Arbeitstage sein können. |
| Kalender und RSVP | Anmeldung pro Familie/Kind sowie Terminverwaltung vorhanden; Detailzugang und Mitbringen siehe F06. |
| Terminanfragen und Notdiensttausch | Anfrage und Antwortaktionen vorhanden; Freigabe bzw. Zustimmung anderer Personen ist ein notwendiger fachlicher Schritt. |
| Mitteilungen | Dashboard-Anzeige und eigenes Archiv vorhanden; Korrektur und Versandverwaltung siehe F07. |
| Wechselnde Elterndienste | Dienstarten und Einteilung auf derselben Verwaltungsseite; fachliche Unterscheidung zu persönlichen Ämtern siehe F10. |
| Notdienstplanung | Automatischer Vorschlag, Vorschau, manuelle Einteilung und Veröffentlichung vorhanden; F03/F05 betreffen Orientierung und Kommunikation. |
| Notdienstalarm | Einteilung aus dem Plan vorausgewählt; Rückmeldung, Frist und Mailstatus integriert. Separater Alarmdialog ist fachlich sinnvoll. |
| Kita-Einrichtung, Login und Superadmin | Bestehende Einrichtung, Diagnose und Support geprüft; Zugriffsrollen und Wiederherstellung siehe F04/F11. Keine produktiven Support-Aktionen ausgeführt. |

„Vorhanden“ bedeutet hier, dass der Bedienweg im aktuellen Code nachvollziehbar ist. Es ist keine Zusicherung, dass jede Ausnahme oder Berechnung bereits durch diese Prüfung getestet wurde.

## Empfohlene Umsetzungspakete

1. **Sackgassen und falsche Anzeigen beseitigen:** Eltern-Abwesenheitslink und eigene Verwaltungsansicht (F02), erfundenen Gruppenfilter entfernen (F12), gespeicherte Familien bei Mailfehler korrekt abschließen und Einladungen erneut senden (F01).
2. **Notdienst-Rücklauf verlässlich machen:** Einstellungen richtig benennen, unvollständige Meldungen erkennen, Monatsbezug und Versandstatus korrigieren (F03); anschließend manuelle Einteilung und Veröffentlichung vereinfachen (F05).
3. **Personen und Zugänge verwalten:** Kita-interne Rollenverwaltung gemäß Nutzerentscheidung (F04), Passwort- und Aktivierungs-Wiederherstellung (F11).
4. **Alltagskorrekturen direkt ermöglichen:** Einheitliche Kalenderdetails und editierbare Mitbring-Einträge (F06), bearbeitbare Mitteilungen mit eigenständigem Versandstatus (F07).
5. **Weniger wiederholte Eingaben:** Tagesbezogene Arbeitszeitformulare und Ein-Tages-Anträge (F09), geführte Ersteinrichtung (F08), eindeutig beschriftete Ämter (F10) und echte Menü-Zahlen (F12).

Vor der Umsetzung der jeweiligen Zusatzregel noch zu entscheiden: Umgang mit mehrtägigen Abwesenheiten über die Grenze „heute“ hinweg; Teilnahme von Admins/Koordination ohne eigene Kinder; automatische Verfügbarkeits-Erinnerungen samt Termin; E-Mail zur ersten Planveröffentlichung. Diese Punkte verhindern nicht die bereits eindeutig beschriebenen Korrekturen.

## Verifikation und nächster Arbeitsstand

Die Quellcodebefunde wurden gegen den genannten Commit geprüft. Im lokalen Browser bestätigt wurden insbesondere der nicht nutzbare Eltern-Abwesenheitslink, die fehlenden Einladungsaktionen in Familien-Details, gleich benannte Ämter-Schaltflächen sowie unterschiedliche Detailzugänge im Kalender.

Dieses Dokument liegt auf der eigenen Arbeitsbranch `codex/flow-audit`. Für die Dokumentation wurden keine Anwendungstests oder ein neuer Build benötigt. Bei der Umsetzung gehören gezielte Tests der Datums-/Rollenregeln und der Mailfehlerfälle zu den jeweiligen Paketen.