Rbm.FamStack/docs/ROADMAP.md

Roadmap

Legende: [x] erledigt, [ ] offen. Nach jeder Phase: Build ohne Warnungen, Tests grün, Start über Aspire, Commit.

Phase 1 – Fundament

• Solution (FamilyPlanner.slnx), alle Projekte laut Architektur inkl. MigrationService
• Directory.Build.props (Nullable, TreatWarningsAsErrors), Directory.Packages.props, .editorconfig, global.json, .gitignore
• Aspire AppHost: SQL Server mit persistentem Volume, Datenbank-Ressource, MigrationService, Api, Web (WithReference, WaitFor, WaitForCompletion)
• ServiceDefaults: OpenTelemetry, /health, /alive, Resilience, Service Discovery
• EF Core AppDbContext mit Identity, AuditableEntity, Soft Delete, Audit-Interceptor, Initial-Migration
• Data Protection Keys in der Datenbank
• Seeding: Rollen Admin/Familie/Kind/Gast, Initial-Admin aus Konfiguration mit erzwungener Passwortänderung, Familieneinstellungen
• Auth-API: Login (Benutzername/E-Mail, Angemeldet bleiben), Logout, Me, Passwort ändern; Lockout; Rate Limiting; CSRF-Header
• Web-Host als BFF mit YARP (/api, /hubs, /ics)
• Blazor-Shell mit MudBlazor: Login, Passwortwechsel, Navigation (Drawer + Bottom-Navigation), Platzhalterseiten, Dark Mode, deutsche Texte
• PWA-Grundgerüst: Manifest, Icons, Service Worker, Offline-Hinweis
• Docker: Container-Images (non-root), deploy/docker-compose.yml, deploy/.env.example, Aspire-Docker-Compose-Publishing
• Backup-/Restore-Skripte (erste Version), README (erste Version)
• Tests: Unit (Rollen/Policies/Domain/Interceptor), Integration (Login-Flow über Aspire.Hosting.Testing), bUnit (Login-Seite)
• CI-Pipeline (GitHub Actions)

Phase 2 – Rollen & Admin

• Rollenmatrix vollständig als PermissionMatrix (Full/Restricted/None) + Permission-Policies, Unit-Test je Matrixzelle (ADR-0008)
• Konfigurierbare Ausnahmen: Gäste dürfen Einkaufsliste bearbeiten / Familienchat nutzen (wirken sofort auf Policies und /me)
• Fallback-Policy prüft zusätzlich das Ablaufdatum (Claim) – abgelaufene Gäste verlieren sofort den Zugriff
• Benutzerverwaltung (Api + UI): anlegen, bearbeiten, deaktivieren, löschen (Soft Delete mit Anonymisierung), Rolle, Anzeigename, Farbe
• Profilbild-Upload (PNG/JPEG/WebP ≤ 1 MB, Signaturprüfung, in der DB, ADR-0009)
• Passwort-Reset durch Admin (erzwungene Änderung), Konto entsperren, Gast-Ablaufdatum (Login danach verweigert)
• Schutz „letzter aktiver Admin“ (löschen/deaktivieren/herabstufen/ablaufen → 409)
• Sitzungen werden bei Rollen-/Status-Änderung über den Security Stamp ungültig (≤ 5 min)
• Allgemeine Einstellungen als Entität + Admin-Seite (Familienname, Zeitzone, Essenplan-Zeitraum, Mahlzeiten, Aufgaben-Kategorien, Punktesystem, Eltern-Bestätigung, Gast-Rechte)
• Audit-Log für alle administrativen Aktionen (inkl. Änderungsdetails) + Admin-Ansicht mit Paging
• Benutzerverzeichnis /api/users (Namen, Farben, Avatare für spätere Zuweisungen)
• Validierung mit FluentValidation (gemeinsame Validatoren für Api und Client), Migration Phase2AdminAndSettings
• PIN-Login für Kinder vorbereitet: PIN setzen/entfernen (nur Kinder), Endpoint hinter Features:PinLogin (ADR-0010)
• Tests: Unit (Matrix, Policies, Last-Admin, Validatoren, Avatar-Prüfung), Integration (Admin-Endpunkte, 403 für Nicht-Admins, Gast-Ablauf, Lockout, Audit), bUnit (Benutzerliste, Dialog)

Phase 3 – Einkaufsliste

• Mehrere Listen (Seed: Supermarkt = Standard, Drogerie), anlegen/umbenennen/Standard/löschen für Admin & Familie, zuletzt gewählte Liste vorausgewählt
• Schnellerfassung (ein Feld + Enter) mit Mengen-Parser („2x Milch“, „Milch 2x“, „500 g Mehl“, „Mehl 500g“, „1,5 l Saft“ …) + Unit-Tests (ADR-0012)
• Abhaken per Tippen (durchgestrichen, wandert nach unten), Entfernen per Wischgeste oder Button, „Erledigte entfernen“
• Autovervollständigung aus häufig gekauften Artikeln (Häufigkeit serverseitig + lokal, offline nutzbar)
• Standardkategorien in Laufreihenfolge, automatische Zuordnung (Stichwörter + gelernte Kategorie), manuell änderbar und gemerkt
• Rechte serverseitig: Gast lesend (Ausnahme konfigurierbar), Kind löscht nur eigene Einträge + Tests
• Datenmodell mit Soft Delete, Audit-Feldern, RowVersion; Migration Phase3Shopping
• SignalR-Live-Updates über /hubs/live (BFF), Reconnect mit unbegrenzten Wiederholungen und Neuladen nach Wiederverbindung
• Offline: Cache + Outbox im localStorage, idempotente Operationen mit Client-Ids, Sync bei Reconnect/online/alle 15 s, Konfliktstrategie (ADR-0011)
• Mobile first: große Touch-Ziele, Statusanzeige (Live/Offline/ausstehende Änderungen), Tastatur & ARIA (aria-pressed, Labels)
• Tests: Unit (Parser, Kategorien, Sortierung, Löschrechte), bUnit (Liste, Eingabe, Abhaken, Rechte, Offline-Store), Integration (CRUD, 403/409, Idempotenz, SignalR-Broadcast)
• Service-Worker-Background-Sync – bewusst nicht umgesetzt (ADR-0011)

Phase 4 – Essenplaner

• Zeitraum 7–10 Tage (Einstellung, alte Werte per Migration angepasst), Start „heute“ in der Familienzeitzone, Blättern; Mahlzeiten aus den Einstellungen (entfernte Mahlzeiten mit Einträgen bleiben sichtbar)
• Mobile Liste je Tag / Desktop-Wochenraster (Mahlzeiten × Tage), Heute/Morgen hervorgehoben
• Freitext + Autovervollständigung aus bisherigen Gerichten (übernimmt Rezeptlink und Zutaten), Notiz, Rezeptlink (nur http/https), Zutaten; Upsert je Platz mit Versionsprüfung (409 bei gleichzeitiger Änderung)
• „Zutaten auf Einkaufsliste“: Liste und Zutaten wählbar, Mengen-Parser + Kategorien, offene Artikel werden nicht doppelt eingetragen, Live-Update der Einkaufsliste
• Essenswünsche von Kindern (alle sichtbar, nur eigene offene löschbar), Übernahme in einen Platz (Ersetzen nur nach Rückfrage) oder Ablehnen durch Familie/Admin
• Drag & Drop auf anderen Tag/Mahlzeit im Wochenraster (belegter Platz → Tausch), „Verschieben …“-Menü als Alternative für Touch/Tastatur
• Live-Updates über /hubs/live (Einträge an alle, Wunschänderungen ohne Nutzdaten an die Familie), Migration Phase4MealPlanner (ADR-0013)
• Tests: Unit (Zeitraum, Mahlzeiten, Verschieben/Tauschen, URL, Zutaten → Einkauf, Wunsch-Regeln, Validatoren), bUnit (Liste/Raster, Dialoge, Rechte Kind/Gast, Drag & Drop, Live), Integration (CRUD, 403/409, Wunsch-Workflow, Tausch, Einkaufsliste, SignalR)
• Offline-Bearbeitung des Essenplans – bewusst nicht umgesetzt (nur online, Neuladen nach Reconnect; ADR-0013)

Phase 5 – Aufgaben

• Schnellerfassung (ein Feld + Enter) + ausklappbare Details: Titel, Beschreibung, Fälligkeit (Tag, optional Uhrzeit), Erinnerung, Priorität, Kategorie (aus den Einstellungen), Zuweisung, privat, Ämtchen/Punkte/Bestätigung, Wiederholung, Checkliste; Bearbeiten mit Versionsprüfung (409)
• Status offen/in Arbeit/erledigt (+ „wartet auf Bestätigung“), zustandsbasiert und idempotent; Verlauf (wer/wann/was, Begründung bei Ablehnung)
• Zuweisung an Personen oder die ganze Familie; private Aufgaben nur für Ersteller/Zugewiesene – serverseitig (auch nicht für Admins, 404 statt 403), Kinder legen nur eigene private Aufgaben an
• Wiederholungen: eigene RRULE-Teilmenge im Domain-Projekt (DAILY/WEEKLY/MONTHLY/YEARLY, INTERVAL, BYDAY inkl. 2TU/-1FR, BYMONTHDAY, BYMONTH, COUNT/UNTIL; ADR-0014), nächste Instanz nach Erledigung – fester Rhythmus ab Fälligkeit oder Abstand ab Erledigung – + Unit-Tests (Sommerzeit Europe/Berlin, Monatsende, Schaltjahr, COUNT/UNTIL)
• Ämtchen mit Punkten, Eltern-Bestätigung (Einstellung oder je Aufgabe; Punkte erst nach Bestätigung, Rückbuchung beim Wieder-Öffnen), Punktestand je Person, Punktekorrektur durch Eltern (Audit-Log), Kinderansicht; neue Berechtigung TasksApprove
• Ansichten Meine/Familie/Nach Person/Überfällig/Diese Woche (Europe/Berlin), Filter (Kategorie, Person, Priorität, Ämtchen, Erledigte), Sortierung
• Live-Updates nur an Berechtigte (user:{id}, TaskRemoved bei Sichtbarkeitsverlust), Offline-Erfassung und Status über Outbox (Bearbeiten/Löschen/Bestätigen nur online, ADR-0014); Migration Phase5Tasks
• Web-Push-Erinnerungen vorbereitet: VAPID über Aspire-Parameter/.env (tools/generate-vapid-keys.cs), Abos speichern/löschen (nur bekannte Push-Dienste), Service-Worker-Handler, Opt-in unter „Benachrichtigungen“, minimaler Erinnerungsdienst (einmalig, minütlich)
• Tests: Unit (RRULE, nächste Instanz, Status/Bestätigung/Punkte, Sichtbarkeit/Rechte, Ansichten, Validatoren, Web-Push-Kryptografie mit RFC-8291-Testvektor), bUnit (Seite, Editor, Ansichten/Filter, Kinderansicht, Bestätigung, Rechte, Dialoge, Offline-Store, Benachrichtigungen), Integration (CRUD, 403/404 je Rolle, private Aufgaben, Ämtchen-Workflow mit Punkten, Wiederholung, Idempotenz, SignalR, Push-Abos)
• Bearbeiten/Löschen/Bestätigen offline – bewusst nicht umgesetzt (nur online, ADR-0014)
• Push-Erinnerungen mit eigener Uhrzeit für ganztägige Aufgaben und Ruhezeiten – bewusst nicht umgesetzt (Erinnerung relativ zu 09:00 Uhr)

Phase 6 – Kalender

• Kalender mit Farbe und Rechten je Rolle oder Benutzer (Lesen/Eigene/Schreiben, durch die Rollenmatrix begrenzt), Admin-Kalenderverwaltung, Standardkalender „Familie“ (Gäste lesen) geseedet (ADR-0015)
• Termine: Titel, Beginn/Ende, ganztägig, Ort, Notiz, Personen-Tags inkl. „ganze Familie“, Kalender; UTC gespeichert, Europe/Berlin angezeigt; RowVersion (409), Soft Delete, Audit-Felder, idempotentes Anlegen; Migration Phase6Calendar
• Wiederholungen (RRULE-Teilmenge aus Phase 5, Expansion mit dem vorhandenen Evaluator, Wanduhrzeit über die Zeitumstellung) mit Ausnahmen: nur diesen ändern (Override/RECURRENCE-ID), nur diesen löschen (EXDATE), ganze Serie ändern (Verschiebung relativ zum Vorkommen)
• Ansichten Agenda (Smartphone-Standard) / Tag / Woche (Desktop-Standard) / Monat, Blättern, Farben je Person, Filter nach Kalender und Personen, Schnellerfassung per „Termin“-Button bzw. Tag antippen
• Aufgaben mit Fälligkeit als ein-/ausblendbare Ebene (Sichtbarkeit nach Aufgabenregeln)
• Rechte serverseitig: Kind nur eigene Termine, Gast nur freigegebene Kalender lesend, Admin-Endpunkte nur für Admins + Tests
• ICS-Feeds (alle/meine/pro Kalender, Aufgaben optional als VTODO oder Termin), eigene korrekte VTIMEZONE (Ical.Net-Fehler umgangen), stabile UIDs, RRULE/EXDATE/RECURRENCE-ID, ETag/Last-Modified/304, Rate Limiting, Sicht des Token-Inhabers (ADR-0016)
• Abo-Tokens erzeugen/neu erzeugen/widerrufen, Admin-Übersicht mit Widerruf, Seite „Kalender abonnieren“ mit webcal/https-Link, Kopieren, QR-Code (QRCoder, serverseitig) und Anleitungen für iPhone, Outlook, Google
• ICS-Import (≤ 1 MB, Duplikate per UID, Overrides, nicht unterstützte Regeln im Bericht)
• ADR CalDAV / Microsoft Graph (ADR-0017), Live-Updates CalendarChanged nur an Berechtigte, Endpunkt „Termine heute + morgen“ fürs Dashboard
• App-Start mit Wiederholungen für Boot-Ressourcen (robust bei kurzzeitigen Netzfehlern, ADR-0007)
• Tests: Unit (Rechte, Zeiten inkl. Sommerzeit, Expansion/EXDATE/Override, Tokens, ICS: VTIMEZONE, UID-Stabilität, VTODO, Escaping/Folding, Import, Roundtrip), bUnit (Agenda/Monat/Filter, Schnellerfassung, nur lesend, Live, Abo-Seite), Integration (CRUD, 403 je Rolle, Serien, Feed mit Token/ETag/304/Neu erzeugen/Widerruf, Gast-Sichtbarkeit, Import, SignalR, heute/morgen)
• „Dieser und alle folgenden Termine“ bearbeiten – bewusst nicht umgesetzt (ADR-0015)
• Stunden-Raster (Zeitachse) in Tag/Woche – Einträge werden als sortierte Liste je Tag gezeigt

Phase 7 – Dashboard

• Kacheln: Heute zu essen, Termine heute + morgen, Einkaufsliste (Anzahl + Schnellerfassung in die Standardliste), Meine Aufgaben, Familien-/Kinderaufgaben (nur Eltern, inkl. wartender Bestätigungen), Nachrichten (Zähler 0 bis Phase 8); ein aggregierter Endpunkt GET /api/dashboard, nicht erlaubte Kacheln fehlen je Rolle serverseitig (ADR-0018)
• Begrüßung mit Datum, einspaltig auf dem Smartphone (zwei Spalten ab sm, drei ab lg)
• Live-Aktualisierung: vorhandene Hub-Ereignisse (Einkauf, Essenplan, Aufgaben, Punkte, Kalender) lösen ein gebündeltes Neuladen aus, Neuladen nach Wiederverbindung, Offline-Hinweis mit letztem Stand
• Tests: Unit (Aufgabenauswahl/Sortierung/Limit), bUnit (Kacheln, leere Zustände, Gast, Schnellerfassung, Live-Bündelung, Offline, Abmelden von Ereignissen, Formatierung), Integration (401, Kacheln je Rolle, Essen/Termine heute, Einkaufszähler, private Aufgaben, Familienkachel + Bestätigungen, Gast)
• Aufgaben direkt im Dashboard abhaken – bewusst nicht umgesetzt (ADR-0018)
• Schnellerfassung Einkauf offline (Outbox) – bewusst nicht umgesetzt, nur online (ADR-0018)

Phase 8 – Chat

• Familienchat (ein geseedeter Kanal) + Direktnachrichten (ein Kanal je Personenpaar, nur Admin/Familie/Kind untereinander, nie mit Gästen); Rechte bei jedem Aufruf gegen die aktuellen Einstellungen/Rollen geprüft (ADR-0019)
• Gelesen-Stand (monoton, „bis zu dieser Nachricht“, nur bei sichtbarer Unterhaltung) mit Haken (Direkt) bzw. „Gelesen von N“ (Familie), Ungelesen-Zähler je Kanal (eine gruppierte Abfrage) in Kanalliste, Navigation (Drawer + Bottom-Navigation) und Dashboard, Tippindikator über Hub-Methode (gedrosselt, kein Echo)
• Paging (30 je Seite, Cursor auf Serverzeit + Id), „Ältere Nachrichten laden“ mit erhaltener Scrollposition, Tageswechsel-Trenner in Europe/Berlin
• Bilder (PNG/JPEG/WebP ≤ 3 MB, Typ aus der Signatur, nur für Kanalmitglieder abrufbar, Bytes nie über SignalR, beim Löschen entfernt), Emoji-Reaktionen (feste Auswahl, idempotent)
• Rechte Kind/Gast: Gast ohne Freigabe sieht nichts (404/403), mit Einstellung nur den Familienkanal; Kinder nur an Familienmitglieder; Löschen: eigene, Admin zusätzlich im Familienkanal; deaktivierte Personen: Verlauf lesbar, Senden gesperrt
• Live über /hubs/live an die jeweils berechtigten user:{id}-Gruppen, Idempotenz über Client-Ids, Migration Phase8Chat
• Tests: Unit (Rechte je Rolle/Einstellung, DM-Regeln, Text/Bild/Reaktion/Löschen, Paging-Grenzen, Drosselung), bUnit (Kanalliste, Verlauf, Paging, Senden/Fehler, Bild, Reaktionen, Löschen, Live-Nachricht sichtbar/versteckt, Tippen, Haken, Gast, nicht erreichbar, neue Unterhaltung, Reconnect), Integration (401, Familienkanal + Ungelesen, Gast-Einstellung, DM-Privatsphäre, Paging, Bilder inkl. gefälschter Typen, Reaktionen, Löschen, deaktivierter Partner, SignalR nur für Mitglieder + Tippen)
• Chat offline (Outbox) – bewusst nicht umgesetzt, nur online (ADR-0019)
• Nachrichten bearbeiten, Antworten/Zitate, Suche, frei wählbare Gruppen – bewusst nicht umgesetzt

Phase 9 – KI-Anbindung (ADR-0020)

• Gemeinsame Schnittstelle IAiProvider (Text, Bilder, strukturierte JSON-Antwort) mit anbieterunabhängigem AiRequest/AiResponse; Zugriff für Fachfunktionen nur über AiService
• Adapter: Ollama (/api/chat, Bilder als Base64, Schema über format), Claude (Messages API, Bilder, erzwungener Werkzeugaufruf für das Schema), OpenAI-kompatibel (Perplexity; später Azure OpenAI / GitHub Models als Ersatz für „Copilot“, der keine offene API hat; Bilder als Data-URL, Schema über response_format)
• Admin-Bereich „KI“ (Tab unter Verwaltung): Anbieter anlegen/ändern/löschen/aktivieren, Adresse, Modell, API-Schlüssel (mit Data Protection verschlüsselt, nie zurück an den Client, ersetzen/entfernen), Zeitlimit, Tageslimit je Person, Zweck-Zuordnung (je Zweck genau ein Anbieter), „Bilder erlaubt“ (Opt-in; Heimnetz-Adressen brauchen es nicht), Verbindungstest, Nutzungsübersicht
• Adress-Prüfung (nur http/https, keine Zugangsdaten, Cloud-Metadaten/Link-Local gesperrt, Klartext nur im Heimnetz, Claude nur https), Foto-Prüfung ohne Rückfall auf den Standard-Anbieter
• Permission AiUse (Admin/Familie) + Matrix-Test, Verwaltung nur Admin (SettingsManagement); GET /api/ai/status für Eltern (steuert später, welche KI-Knöpfe sichtbar sind)
• Tageslimit, Nutzungsprotokoll AiUsage (ohne Inhalt: Person, Zweck, Anbieter, Modell, Dauer, Tokens, Erfolg/Fehlerart), Audit-Log für Anbieter-Änderungen, eigener HttpClient ohne Standard-Resilienz, Zeitlimit je Anbieter, höchstens ein Wiederholungsversuch bei unbrauchbarer Antwort, Fehlermeldungen ohne Schlüssel/Anbietertext; Migration Phase9Ai
• Tests: Unit (Adressen/Heimnetz/Schlüsselpflicht/Limits/Zwecke/Validator, Adapter gegen Fake-Handler inkl. Fehlerübersetzung und JSON-Extraktion), bUnit (Verwaltung, Dialog, Test, Nutzung, Löschen), Integration (Rechte, Validierung, Schlüsselschutz, Zweck-Übernahme, Verbindungstest gegen Fake-Anbieter inkl. Timeout, OpenAI-Format, Tageslimit + Protokoll)

Phase 10 – Lernaufgaben (ADR-0021)

• 10a: Übungsblätter manuell anlegen/zuweisen (Entwurf → Zugewiesen → In Arbeit → Abgegeben → Geprüft), Editor für Blatt und Aufgaben (Zahl/Text/Auswahl, Hinweis, Erklärung, Schwierigkeit, Punkte), Versionsprüfung (409), Bearbeitungssperre nach dem ersten Versuch; Migration Phase10aLearning
• 10a: Kind löst digital (eigene Blätter, Versuch starten/fortsetzen, Antworten zustandsbasiert speichern, Fortschritt, Abgabe-Bestätigung, Ergebnis mit Lösungen nur nach Regel), automatische Bewertung ohne KI (Zahlenformate mit Komma/Punkt/Tausender, Toleranz, Auswahl, Freitext exakt oder offen), Elternprüfung (Warteschlange, Korrektur, Teilpunkte, Begründung, Bestätigen, erneut öffnen)
• 10a: Wiederholen (MaxAttempts, 0 = unbegrenzt), Zeitlimit serverseitig (Frist in der Datenbank, 10 s Toleranz, 409 bei späten Speicherungen, automatische Abgabe lazy und per Hintergrunddienst), Prüfungsmodus (keine Sofort-Rückmeldung/Hinweise/Lösungen bis zur Abgabe, optional gemischt und stabil je Versuch, Countdown nach Serveruhr, Auto-Abgabe), Note nach Notenschlüssel
• 10a: Punkte über das Punktebuch (anteilig, beste Wertung zählt einmal, Differenz wird gebucht, Rückbuchung beim erneuten Öffnen, Audit, Live PointsChanged), Dashboard-Kachel „Lernen“ (Kind: offene Blätter, Eltern: zu prüfen), Live LearningChanged nur an Zielperson und Eltern
• 10a: Rechte LearningManage/LearningSolve in der Matrix (Kinder nur eigene Blätter, fremde → 404, nie Musterlösung/Hinweis/Prompt vorab; serverseitig erzwungen), Navigation „Lernen“, Seiten und Komponenten (mobil, Touch-Ziele, ARIA)
• 10a: Tests: Unit (Zahlenformate, Auto-Bewertung, Zeitlimit, Wiederholen, Punkte-Differenz, Noten, Prüfungsregeln, Kinder-DTO-Sichtbarkeit, Matrix, Validatoren), bUnit (Kinderansicht, Prüfungs-Runner mit steuerbarer Uhr, Elternansicht, Editor, Prüfung, Rechte, Dashboard-Kachel), Integration (Rechte je Rolle inkl. 404, Lösungen-Leck, Auto-Bewertung, Zeitlimit-409 mit echtem Warten, Wiederholungen, Punkte-Workflow inkl. Rückbuchung, Live nur an Berechtigte)
• 10a offen: „Aufgaben aus früheren Blättern wiederverwenden“, Verknüpfung eines Blatts mit einer Familienaufgabe/einem Ämtchen, Standard-Wiederholungen als Familieneinstellung (aktuell Voreinstellung im Editor)
• 10b: KI-Erzeugung per Prompt (z. B. „20 Aufgaben Mathe, 3. Klasse, leicht bis schwer“) als Entwurf, Eltern prüfen/ändern vor dem Zuweisen, Mathe-Lösungen serverseitig nachrechnen – keine Migration (Herkunftsspalten aus 10a)
• 10b: POST /api/learning/sets/ai-draft (LearningManage + AiUse): feste Systemanweisung nur aus geprüften Auswahlwerten (Fach, Klasse, Anzahl 1–30, Schwierigkeitsverlauf), Freitext (≤ 300 Zeichen) nur abgegrenzt in der Nutzernachricht; JSON-Schema, Ausgabe-Budget nach Anzahl; jede Aufgabe einzeln geprüft (Validator, CheckSolution, Markup/Links verworfen, Duplikate, Gegenprobe über die Auto-Bewertung), Zahlaufgaben mit Rechenausdruck nachgerechnet (LearningExpression), Abweichung → verworfen, sonst Bericht; Speichern als Entwurf mit Source = Ai, Prompt/Anbieter/Modell
• 10b: Oberfläche: „Mit KI erstellen“ in der Elternübersicht (nur bei CanGenerateLearning), Assistent-Dialog mit Prüfbericht, Datenschutzhinweis bei Cloud-Anbietern (AiStatusDto.LearningGenerationIsCloud), Hinweis „KI-generiert, bitte prüfen“ im Editor; Kinder sehen nie Prompt/Herkunft
• 10b: Tests: Unit (Ausdrucks-Rechner, Prompt-Bau, Parsen/Prüfen/Nachrechnen/Verwerfen, Kinder-DTO-Leak), bUnit (Sichtbarkeit je Status, Dialog, Bericht, Escaping, Editor-Hinweis), Integration mit Fake-KI-Server (Rechte, gültig, teils falsch, kaputt, Tageslimit, keine KI, Fälschungsversuch source)
• 10c: Papierlösung per Foto (Upload je Aufgabe/Blatt), Prüfung manuell durch Eltern, danach KI-Prüfung mit Sicherheitsangabe und Eltern-Bestätigung (LearningAnswerType.Paper, LearningGrader.Ai sind als Werte vorgesehen)
• Foto-Aufbewahrungsfrist (Standard 30 Tage nach Prüfung, einstellbar, 0 = sofort) – mit 10c

Phase 11c – Lernen: Auswertung, Note, Automatik (ADR-0021)

• Tolerantere Antwort-Auswertung für Zahlen: Einheiten und Schreibweisen werden gelesen („1€ 30 Cent“ = „1,30“, „2 Euro 50“, „1,3 €“, „12 cm“, „1 m 30 cm“, „50 Cent“), Tausenderpunkte und Leerzeichen; umgerechnet wird nur bei Euro/Cent, m/cm, kg/g, l/ml (beide plausiblen Werte gelten). Ziffern ohne eindeutige Zahl („5 Äpfel und 3 Birnen“, „1 h 30 min“) bleiben offen statt falsch
• Unklare Zahlenantworten optional von der KI gegenprüfen lassen (derselbe Knopf und Endpunkt wie die Foto-Prüfung, Zweck LearningImageGrading ohne Rückfall-Anbieter, Datenschutzhinweis, Tageslimit); Ergebnis bleibt Vorschlag, Eltern bestätigen
• Kind sieht die bestätigte Note auch im Kopf des Lernzettels (Ergebnisansicht), nicht nur in der Liste
• Übungsblätter automatisch erzeugen: Zeitplan je Kind und Fach (Wochentage, Uhrzeit Europe/Berlin, Anzahl, Klassenstufe, Startschwierigkeit, Steigerung nach N Blättern), Entwurf zur Prüfung (Standard) oder direkt zuweisen (mit Warnung und Qualitätsgrenze), Hintergrunddienst LearningScheduleService (TimeProvider, idempotent, Sperre + eindeutiger Plantermin), „Jetzt ausführen“, Tageslimit/Fehler werden protokolliert und später erneut versucht, Audit ohne Inhalt; Migration Phase11cLearningAuto
• Oberfläche: Reiter „Automatisch“ in der Lernen-Seite (Liste, Dialog, Pause, Löschen, Jetzt ausführen); nur Eltern mit LearningManage + AiUse
• Tests: Unit (Zahlen mit Einheiten, Plantermine inkl. Sommerzeit, Schwierigkeit, Wartezeiten, Validator), bUnit (Reiter, Dialog, Pause, Löschen, Jetzt ausführen, Kopf-Note, KI-Knopf bei unklarer Antwort), Integration (Rechte, Jetzt ausführen, Qualitätsgrenze, Schwierigkeit, Tageslimit, Fehler, Audit, echter Lauf des Hintergrunddienstes)

Phase 11 – Härtung

• Content-Security-Policy (Basis-Header X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, HSTS sind seit Phase 1 aktiv)
• Eigener SQL-Login mit minimalen Rechten statt sa für Api/MigrationService
• Service-Worker-Cache-Version automatisch beim Build setzen
• Rate Limiting vervollständigen
• Tests vervollständigen (Policies, ICS, Wiederholungen, Integration)
• Barrierefreiheit (WCAG 2.1 AA), Performance (AOT/Trimming prüfen, Lazy Loading)

Phase 11a – Kleine Verbesserungen

• Einkaufsliste: kleiner Hinweis „hinzugefügt von …“ unter dem Eintrag (ShoppingItemDto.CreatedByName); Plausibilitätsprüfung für Kinder – offensichtlicher Unsinn wird nur nach Rückfrage gespeichert (Regelliste in Domain/Shopping/ShoppingPlausibility, ohne KI; 409 mit needsConfirmation, Wiederholung mit Confirm = true)
• Dashboard: allgemeine Info-Kachel für Freitext-Notizen (DashboardNote, Recht DashboardNotesEdit für Eltern, alle sehen sie, nur Text) – Migration Phase11aDashboardNotes
• Oberfläche: Klick auf die eigenen Initialen öffnet ein Menü (Passwort ändern, Meine Einstellungen mit Theme-Wahl, Benachrichtigungen, Abmelden)

Phase 11d – Essen: Wunschliste

• Essen: Wunschliste – Wünsche und bereits hinterlegte Gerichte landen in einer dauerhaften, durchsuchbaren Wunschliste und lassen sich jederzeit wieder in den Plan übernehmen (Migration Phase11dMealWishlist, ADR-0013)

Phase 11b – Chat-Erweiterungen (ADR-0022)

• Emoji-Auswahl: Button neben „Bild senden“, kleine eingebaute Liste nach Kategorien (ohne Pakete/Dienste), Einfügen an der Schreibmarke (sonst am Ende)
• GIF-/Meme-Suche: Server-Proxy (nur der Suchbegriff geht an Giphy, rating=g; auch die Vorschaubilder lädt der Server), Schlüssel aus Giphy__ApiKey (Aspire-Parameter/.env), ohne Schlüssel kein Button (GET /api/chat/features); gesendete GIFs werden nach Host-Whitelist, Größenlimit und Signaturprüfung wie Bilder gespeichert, Uploads bleiben ohne GIF
• KI-Chat-Kanal: ChatChannelKind.Ai (privat je Person, Absender „KI“ ohne Benutzerkonto), AiPurpose.ChatAssistant ohne Rückfall auf den Standard-Anbieter, Admin-Schalter und Kinder-Freigabe in den Familieneinstellungen (Standard aus/nur Eltern), fester kindgerechter System-Prompt, kurzer Kontext, Tageslimit, Protokoll ohne Inhalt, Fehlermeldungen ohne Anbietertext; Migration Phase11bChat
• Tests: Unit (Regeln, Prompt, GIF-Prüfung, Giphy-Adapter mit Stub), bUnit (Emoji, GIF, KI-Kanal), Integration (Rechte je Rolle, Privatsphäre, kein Rückfall, Limit, Fehler, Idempotenz)

Phase 12a – Papierblatt und Zutatenliste

• Lernen: „Papier-Abgabe“ (Foto) für das gesamte Blatt in einem Schritt einstellen, nicht nur je Aufgabe – „Alle Aufgaben auf Papier stellen“ / „Alle auf Bildschirm“ im Blatt-Editor (POST /api/learning/sets/{id}/items/paper, LearningManage, Versionsprüfung, nach dem ersten Versuch gesperrt), Schalter „Auf Papier lösen“ im KI-Entwurf (CreateAiDraftRequest.Paper); Regeln in LearningItemRules.TryConvertToPaper/ConvertToScreen, keine Migration (ADR-0021)
• Essen: Zutaten als Liste erfassen (statt Freitext) mit Knopf je Zutat „In den Einkaufskorb“ – Zeilen mit Menge und Name im Essenplan-Dialog, bereits offene Artikel der Standardliste werden markiert, Snackbar-Rückmeldung; Speicherformat unverändert (MealPlanEntry.Ingredients bleibt Liste von Texten), keine Migration (ADR-0013)

Phase 12b – KI-Protokoll und Online-Suche

• KI: vollständiges Protokoll aller KI-Aufrufe mit Prompt und Antwort in der Datenbank (AiExchange, Admin-Ansicht im KI-Tab mit Seiten, Filtern nach Zweck/Ergebnis/Person/Datum, Detail mit Prompt oben und Antwort unten, Löschen einzeln/alle mit Audit-Vermerk); Aufbewahrung AiLogRetentionDays (Standard 90, 0 = unbegrenzt) per AiExchangeRetentionService; Inhalte des privaten KI-Chats nur mit Admin-Schalter „KI-Chat-Inhalte protokollieren“ (Standard aus), sonst nur Metadaten; der Arbeitsspeicher-Log (AiExchangeLog) entfällt; ADR-0020 (Punkt 9) und ADR-0022 angepasst
• KI: optionale Online-Suche (Opt-in je Anbieter AllowWebSearch, nur Claude via Server-Werkzeug web_search; je Anfrage AiRequest.WebSearch, serverseitig erzwungen; Perplexity sucht ohnehin immer, Ollama nicht unterstützt); im KI-Entwurf für Lernblätter als Kästchen „Online recherchieren“ mit Datenschutzhinweis, Standard aus (AiStatusDto.LearningWebSearchAvailable); ADR-0020 (Punkt 10)
• Migration Phase12bAiLog; Tests: Unit (Regeln, Aufbewahrung, Adapter, Prompt), bUnit (Protokoll, Anbieter-Dialog, Entwurf-Dialog), Integration (Rechte, Filter, Löschen, Chat-Schalter, Opt-in)

Phase 12 – Deployment

• Finale docker-compose.yml (inkl. optionalem Caddy), .env.example
• Backup-/Restore-Skripte
• README: Voraussetzungen, Entwicklung, Konfiguration, Deployment, Update, Backup/Restore, Kalender-Abos

Phase 12c – CalDAV-Zwei-Wege-Sync

• Kalender freigeben und Zwei-Wege-Synchronisation mit iOS/macOS, Thunderbird und DAVx5 (CalDAV-Server in der Api unter /caldav, /.well-known/caldav → 301; BFF leitet beides weiter; ADR-0017 Nachtrag)
• Protokoll: Entdeckung (Principal, calendar-home-set), OPTIONS/PROPFIND (Depth 0/1)/REPORT (calendar-query inkl. time-range, calendar-multiget, sync-collection)/GET/PUT/DELETE, ETag je Termin (Serie + Ausnahmen), CTag/Sync-Token je Kalender, If-Match/If-None-Match mit 412
• Abbildung auf die vorhandenen Termine: ein .ics je UID (Serie + RECURRENCE-ID), Import-/Export-Code aus ADR-0016 wiederverwendet; nicht unterstützte Wiederholungen und VTODO/VJOURNAL werden mit 403 und Vorbedingung abgelehnt; Erhalt von Ersteller/Personen-Tags
• Anmeldung nur per App-Passwort (CalDavCredential: gehasht, einmalig angezeigt, widerrufbar, je Benutzer/Gerät, zuletzt benutzt), HTTP Basic nur über HTTPS (CalDav:RequireHttps), eigenes Auth-Schema ohne Zugriff auf /api, Drosselung von Fehlversuchen, Audit-Log; Migration Phase12cCalDav
• Rechte je Kalender und Benutzer bei jeder Anfrage (Kind nur eigene Termine, Gast nur lesen, unsichtbare Kalender), current-user-privilege-set je Kalender und Termin
• Oberfläche „Kalender freigeben / Mit Handy verbinden“ (Einstellungen › Kalender verbinden, Link im Kalender-Menü): Server-Adresse, Benutzername, App-Passwort erstellen/widerrufen, Anleitungen iPhone/Mac/Android (DAVx5)/Thunderbird, ehrlicher Outlook-Hinweis (nur ICS-Abo lesend)
• Tests: Unit (Pfade/Hrefs, ETag, Gruppierung, Sync-Token, XML, Filter, PUT-Prüfung, Export-Roundtrip, Drosselung), bUnit (Verbindungsseite), Integration über den BFF (Entdeckung, Round-Trip, 412, Serien, Sync, Rechte, Zugangsdaten)
• Praxistest mit echten Clients (iOS/macOS, Thunderbird, DAVx5) – noch nicht erfolgt

Phase 14 – KI-Prompts

• KI-Chat: System-Prompt deaktivieren (nur Rollen mit AiUse; ChatChannel.AiSystemPromptDisabled, Schalter + Warnung im ChatAiSettingsDialog); Kinder behalten serverseitig immer den festen Prompt
• Admin-Einstellungen je Person (AiUserSettings: Anbieter, Modell, System-Prompt, „Prompt deaktivieren“; GET/PUT /api/admin/ai/users/{id}/settings, SettingsManagement, Menü „KI-Einstellungen“ in der Benutzerverwaltung, Audit ai.user_settings_changed); Vorrang vor der Kanal-Einstellung, wirkt auch bei Kindern (ChatAssistantPrompt.Resolve)
• KI-Protokoll speichert Prompts (System-Prompt + Eingaben) und Antworten des Chats immer; Schalter AiLogChatContent entfernt; Datenschutzhinweise in Chat, Einstellungen und Protokoll angepasst
• Fehler lückenlos protokolliert (AiService.LogFailureAsync: „kein Anbieter“, Foto-Prüfung ohne Anbieter/Bilder-Freigabe, Abbruch/Unerwartetes, Modelllisten-Abruf); Filter „Fehlgeschlagen“ mit Fehlertext in der Liste
• KI-Entwurf: Admin sieht den gesendeten Prompt (POST /api/learning/sets/ai-draft/prompt), kann Systemanweisung und Nutzer-Prompt anpassen (CreateAiDraftRequest.PromptOverride, nur Admin, serverseitig 403 sonst), Schema bleibt separat, Vermerk am Blatt (AiPrompt)
• Migration Phase14AiPrompts; Tests: Unit (Auflösung, Prompt-Override, Validatoren), bUnit (Entwurf-Dialog Admin/Eltern, Benutzer-KI-Dialog), Integration (AiPromptTests, AiExchangeLogTests)

Phase 15 – Geburtstage

• Geburtsdatum (optional) für alle Benutzer: Admin setzt es in der Benutzerverwaltung (Spalte mit Alter), jeder Benutzer im Profil („Meine Einstellungen“, PUT /api/auth/me/birth-date); Validator (nicht vor 1900, nicht in der Zukunft); Alter als reine Funktion BirthdayRules.AgeOn (Schaltjahr 29.2. → 28.2.)
• Datenschutz: BirthDate im Benutzerverzeichnis nur für die eigene Person, Admins und Familie, serverseitig; Audit-Log ohne Wert
• Kalender-Vorlage „Geburtstag“: Person aus dem Verzeichnis (Datum vorbelegt) oder freie Eingabe; ganztägig, jährlich, Titel „Geburtstag von X“, Alter je Vorkommen (CalendarEvent.BirthDate, Age/DisplayTitle) in Agenda/Monat/Woche/Dashboard; ICS/CalDAV: eine Serie mit Kategorie „Geburtstag“, BirthDate bleibt beim CalDAV-PUT erhalten (ADR-0015 Nachtrag)
• Migration Phase15Birthdays; Tests: Unit (Alter/Schaltjahr, Validatoren, Normalisierung, DTO, ICS), bUnit (Vorlage, Benutzerverwaltung, Profil), Integration (BirthdayTests, CalDAV-Round-Trip)

Phase 16 – Lesetexte und Textaufgaben

• Lesetext je Blatt (LearningSet.Passage, Plain-Text mit Absätzen, höchstens 3000 Zeichen, bereinigt über LearningPassages.Normalize, nur als Text ausgegeben); Fragen sind die vorhandenen Typen (Auswahl, Kurzantwort, Zahl) plus Wahr/Falsch als Auswahlaufgabe mit festen Optionen (LearningTrueFalse) – kein neuer Antworttyp, bestehende Blätter unverändert
• Lesetext dauerhaft sichtbar: Kind-Runner (PassageCard, bei jeder Frage, auch Prüfung), Ergebnisansicht, Elternprüfung; Foto-/Antwort-KI-Prompts bekommen ihn als abgegrenztes Material; Editor-Feld „Lesetext“ (nach dem ersten Versuch gesperrt, Validator + serverseitig), Knopf „Als Wahr/Falsch-Aufgabe“
• Textaufgaben: Sachtext in der Frage, Zahlen-/Einheitenantwort über die vorhandene Zahlenprüfung; KI-Aufgabenart im Entwurf-Dialog „Standard / Leseverständnis / Textaufgaben“ (CreateAiDraftRequest.Kind), Prompt, Schema (passage Pflicht bei Leseverständnis, Typ truefalse), Parser mit Lesetext-Prüfung; Admin-Prompt-Vorschau/-Override unverändert (Schema bleibt separat)
• Migration Phase16LearningText (Spalte LearningSets.Passage); Tests: Unit (LearningPassageTests), bUnit (PassageTests), Integration (LearningPassageTests)

Phase 17 – Haus (Smart Home, ADR-0023)

• Navigation: „Haus“ (/haus, alle mit HomeUse) und „Hausverwaltung“ (/haus/verwaltung, nur Admin) unter „Verwaltung“; neue Permissions HomeUse (Admin F, Familie/Kind/Gast R – je Gerät freigegeben) und HomeManage (nur Admin) mit Matrix-Tests je Zelle
• Geräte hinter IHomeDeviceDriver (Shelly-Treiber): Gen2+ per HTTP-RPC (Switch.GetStatus/Set/Toggle, Cover.*, Light.*, Shelly.GetDeviceInfo), Gen1 per REST (/relay, /roller, /light, /status, /shelly); Arten Schalter/Steckdose/Licht/Rollo/Sensor, Raum, Symbol, Kanal; Passwort mit Data Protection verschlüsselt (Gen2 Digest-SHA-256, Gen1 Basic); Zustand lesen, schalten, Verbindungstest (auch für Entwürfe), freundliche deutsche Fehler
• SSRF-Schutz: nur http/https, nur Heimnetz (gemeinsame NetworkRules, von AiRules mitbenutzt), Link-Local/Metadaten gesperrt, jede aufgelöste IP wird beim Verbinden geprüft (DNS-Rebinding), kein Proxy, keine Weiterleitungen, 4-s-Zeitlimit, Antworten ≤ 256 KB, keine Wiederholungen (kein doppeltes Umschalten), nie Geräte-Text an den Client
• Freigaben je Gerät für Rollen (Familie/Kind/Gast) und/oder Personen (ansehen/schalten), Admin immer alles; nicht freigegeben = unsichtbar (404), nur ansehen = 403; gleiche Filter für Pins und Planbilder
• Haus-Seite: Räume mit Gerätekarten (Status als Text + Symbol, Schalter, Rollo-Tasten, Sensorwerte, offline), Zustände alle 10 s; Plan-Ansicht mit Geräte-Pins (Klick = umschalten + Details), barrierefrei (Buttons, Beschriftungen, Kurztext im Pin), mobil
• Pläne: PNG/JPEG/WebP ≤ 5 MB (Signaturprüfung, Typ nie vom Client), Bilder in der Datenbank, mehrere Pläne mit Namen, Auslieferung nur an Berechtigte; Pin-Editor (Klick, Ziehen, Pfeiltasten, Prozentfelder), relative Koordinaten 0–1
• Hausverwaltung (Admin): Geräte (anlegen/ändern/löschen mit Soft Delete, Test, Freigaben), Räume, Pläne mit Pins, Aktionsprotokoll (jede Schaltung inkl. Fehlschlägen, ohne Zugangsdaten); Audit-Log für alle Änderungen (ohne Passwörter)
• Migration Phase17Home; Tests: Unit (Adressen/SSRF, Befehle je Art, Freigaben, Koordinaten, Bilder, Validatoren, Shelly-Treiber gegen Fake-Handler inkl. Digest-Referenzwert, Fehlerübersetzung), bUnit (Haus-Seite, Gerätekarten, Plan, Verwaltung, Dialoge, Pin-Editor, Navigation), Integration mit Fake-Shelly-Server (HomeTests: Rechte je Rolle/Gerät, Schalten Gen1/Gen2/Rollo, Anmeldung, Fehler/Timeout/Weiterleitung, Protokoll, Audit, Pläne und Pins)
• Weitere Treiber (MQTT, Home Assistant), Szenen, Dimmer-Helligkeit/Rollo-Position, Live-Updates per SignalR statt Abfrage alle 10 s, Praxistest mit echten Shelly-Geräten – bewusst nicht umgesetzt (ADR-0023)

Phase 18 – Kameras (Haus, ADR-0024)

• Kameras mit MJPEG-Strom (http://…/video.mjpg?…) im Heimnetz: HomeCamera + HomeCameraAccess (Migration Phase18Cameras), Adresse mit Pfad/Query über HomeRules.NormalizeStreamUrl (Heimnetz-Regeln wie ADR-0023), optional Basic-Anmeldung (Passwort verschlüsselt)
• Die Api reicht den Strom weiter (GET /api/home/cameras/{id}/stream, nie Direktzugriff des Browsers): SSRF-Schutz über den home-HttpClient, nur MJPEG/JPEG, feste Fehlermeldungen (404/429/502), Header- und Stillstands-Zeitlimit, Kamera wird beim Weggehen losgelassen, höchstens 4 Zuschauer je Kamera
• Freigaben je Kamera (Rolle oder Person, nur ansehen); nicht freigegeben = unsichtbar (404); Nutzer-DTO ohne Adresse/Zugangsdaten
• Seite /haus/kameras (Navigation unter „Haus“), Startseiten-Kachel je Kamera (ShowOnDashboard, nur für Berechtigte), Anhalten/Neu verbinden, deutscher Hinweis bei fehlendem Bild
• Hausverwaltung → Reiter „Kameras“ (anlegen/ändern/löschen, Freigaben, Verbindungstest, Startseiten-Schalter); Audit ohne Passwörter und Query-Tokens
• Tests: Unit (StreamUrlRulesTests, HomeCameraStreamerTests), bUnit (HouseCameraTests, Navigation)
• Integrationstests mit FakeMjpegServer (HomeCameraTests: Rechte je Rolle/Person, Strom weiterreichen und loslassen, Fehlerfälle, Grenze, Dashboard, Audit) sind geschrieben, aber noch nicht gelaufen (Docker war nicht gestartet); ebenso der Aspire-Start mit echtem Strom über das Web-BFF
• RTSP/HLS/WebRTC, Digest-Anmeldung der Kamera, gemeinsamer Upstream für mehrere Zuschauer, Kameras auf dem Grundriss, Praxistest mit echter Kamera – bewusst nicht umgesetzt (ADR-0024)

Phase 19 – Lüftungsanlage (Haus, ADR-0025)

• Geräteart „Lüftungsanlage“ (HomeDeviceKind.Ventilation) mit Treiber Vallox für Vallox MV (z. B. ValloPlus 350 MV) über das WebSocket-Protokoll der Weboberfläche (READ_TABLES/WRITE_DATA, Prüfsumme, big-endian-Tabelle); keine Migration (Enums als Text)
• Profil auslesen (Zuhause, Abwesend, Stoßlüften, Kamin, Extra, Automatik inkl. Restlaufzeit), Temperaturen (Außen-, Zu-, Ab-, Fortluft), Luftfeuchte, CO₂, Lüfterstufe
• Profile aktivieren (ProfileHome/Away/Boost/Fireplace, Stoßlüften/Kamin mit der am Gerät eingestellten Dauer); Rechte, Aktionsprotokoll und SSRF-Schutz wie bei Shelly (gleicher Verbindungs-Handler)
• Hausverwaltung: Dialog ohne Generation/Kanal/Anmeldung für Lüftungsanlagen, Verbindungstest mit Modellname; Gerätekarte mit Messwerten und Profil-Knöpfen (aria-pressed)
• Tests: Unit (ValloxDriverTests: Rahmen/Prüfsumme gegen Referenzbytes, Tabelle, Profile, Schreibbefehle, Treiber, echter WebSocket über Loopback, SSRF; HomeRulesTests), bUnit (Gerätekarte, Profilwahl, nur ansehen, Verwaltungsdialog)
• Praxistest mit der echten ValloPlus 350 MV, Integrationstest mit Fake-Vallox-Server (Docker), Extra/Automatik wählen, Solltemperaturen/Lüfterstufen je Profil, Filter-/Alarmanzeige – bewusst nicht umgesetzt (ADR-0025)

Backlog

• PIN-Login-Oberfläche für ein Familien-Tablet (Profilauswahl + Ziffernblock) – Api ist vorbereitet
• Selbst-Upload des eigenen Profilbilds, Profilseite für Anzeigename/Farbe
• Endgültige Löschung eines Benutzers (DSGVO) zusätzlich zum Soft Delete
• Einkaufsliste: „Rückgängig“ nach dem Entfernen, Sortierung per Drag & Drop, eigene Kategorien je Familie
• Offline-Cache beim Abmelden leeren (geteilte Geräte)
• Belohnungskatalog für Ämtchen-Punkte
• Web-Push für Termine und Chat (Infrastruktur aus Phase 5 vorhanden)
• Chat: Nachrichten bearbeiten, Antworten, Suche, Aufräumen alter Nachrichten/Bilder
• Kalender: Stunden-Raster mit Drag & Drop, „dieser und folgende“, Erinnerungen per Web-Push für Termine
• Rezeptdatenbank
• Jahrestage; automatische Geburtstage aller Benutzer als eigene Kalenderebene
• Wand-Tablet-Modus (Kiosk-Dashboard)
• Outlook-Synchronisation über Microsoft Graph (ADR-0017): Zwei-Wege-Abgleich mit Outlook/Microsoft 365 (OAuth, Delta-Abfragen, Webhooks); Outlook kann kein CalDAV, bis dahin nur lesend per ICS-Abo
• CalDAV: Praxistest mit echten Clients (iOS/macOS, Thunderbird, DAVx5), VALARM/Teilnehmer erhalten, Admin-Übersicht und Widerruf der App-Passwörter aller Benutzer