# Roadmap Was als Nächstes drankommt, und warum in dieser Reihenfolge. **Maßstab ist der Alltag, nicht die Vollständigkeit.** Ein Punkt steht weit oben, wenn er entweder etwas Falsches richtigstellt oder jeden Monat Zeit spart. Er steht weit unten, wenn er nur schön wäre. Diese Datei ist eine Absichtserklärung, kein Vertrag. Was sich im Betrieb als wichtiger herausstellt, rutscht nach oben. Stand: 23.08.2026 · Aktuelle Fassung: **1.5.0** ([CHANGELOG](../CHANGELOG.md)) --- ## Woher die Punkte kommen Beim Bauen sind **44 Schema-Wünsche** aufgelaufen — Stellen, an denen das Datenmodell etwas nicht abbildet, was die Fachlogik gebraucht hätte. Sie liegen einzeln und begründet in [`schema-wuensche/`](schema-wuensche/), nach Modul getrennt. Diese Roadmap sortiert sie nach Dringlichkeit und bündelt sie zu Releases, die sich in einem Rutsch migrieren lassen. Dazu kommen die bekannten Einschränkungen aus dem Changelog und das, was sich im Betrieb noch zeigen wird. --- ## 1.1 — Was heute noch falsch sein kann **Ziel:** Kein Wert in der Anwendung soll unter ungünstigen Umständen falsch sein, ohne dass man es merkt. Das ist die einzige Art von Fehler, die man einem Betreuungsgericht nicht erklären kann. ### Kostenkonto der Immobilie richtigstellen `Buchung` hat kein `immobilieId`. Das Kostenkonto wertet deshalb über Buchungskategorien aus — bei **einem** Grundstück richtig, bei einem zweiten still falsch. Die Oberfläche sagt das derzeit an der Auswertung dazu; das ist ein Pflaster, keine Lösung. *Aufwand: klein. Migration: ein Feld, ein Index.* ### Umbuchungen kennen ihr Gegenkonto Eine Umbuchung zwischen zwei Konten erscheint heute als zwei unverbundene Buchungen. In der Rechnungslegung sieht das aus wie eine Ausgabe und eine Einnahme — und wer nachrechnet, fragt zu Recht nach. *Aufwand: klein. Migration: ein selbstbezüglicher Fremdschlüssel.* ### Dublettenschutz beim Import ohne Konto Der Schutz vor Doppelbuchungen greift über `(kontoId, importReferenz)`. Ist kein Konto zugeordnet, greift er nicht — ein zweimal eingelesener Auszug erzeugt dann doppelte Buchungen. *Aufwand: klein. Migration: partieller eindeutiger Index.* ### Rückkaufswert am Vertrag Der Wert hängt heute am Vermögensposten. In der Vertragsübersicht steht deshalb kein Betrag — ausgerechnet dort, wo man ihn beim Telefonat mit dem Versicherer braucht. Es ist derselbe Wert, um den es im Anschreiben an den Versicherer geht — siehe 1.2a. *Aufwand: klein. Issue: [#8](https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/issues/8).* ### Genau eine Zielspalte je Dokumentverknüpfung `DokumentVerknuepfung` hat zwölf mögliche Zielspalten; dass genau eine gesetzt ist, erzwingt bisher nur die Anwendung. Ein CHECK-Constraint macht daraus eine Zusage, die auch bei direktem Datenbankzugriff hält. *Aufwand: klein. Migration: ein Constraint.* ### Papierkorb für Saldo- und Wertstände Beide Modelle haben kein `geloeschtAm`. Ein versehentlich eingetragener Kontostand lässt sich nur endgültig löschen — was der Zusage widerspricht, dass Löschen 30 Tage rückgängig zu machen ist. *Aufwand: klein.* ### Aufgaben aus Vorlagen entfernen können Passt eine Aufgabe aus einer Vorgangs-Vorlage im Einzelfall nicht, bleibt sie dauerhaft offen stehen und verfälscht jede Fortschrittsanzeige. *Aufwand: klein.* --- ## 1.2 — Weniger tippen **Ziel:** Die Handgriffe, die sich jeden Monat wiederholen, kürzer machen. ### Nachforderungen mit stabilem Schlüssel Der Dublettenschutz beim Übernehmen der Standardcheckliste läuft über die Bezeichnung. Wer eine Zeile umbenennt, bekommt sie beim nächsten Mal doppelt. ### Bescheid und Frist verbinden Aus einem Bescheid entsteht die Widerspruchsfrist heute über einen Textschlüssel statt über einen Fremdschlüssel. Ändert sich das Zugangsdatum, wandert die Frist nicht mit. ### Statuswechsel eines Vorgangs als eigene Tabelle Der Zeitstrahl liest Statuswechsel aus dem entschlüsselten Audit-Log. Das funktioniert, ist aber langsam und hängt an einem Format, das eigentlich nur Nachweis sein soll. ### Wer hat was erfasst Fristen, Saldo- und Wertstände tragen kein Feld für den erfassenden Benutzer. Bei einer Betreuung zu zweit ist das die erste Frage. ### Ansprechpartner am Vorgang Die Sachstandsanfrage kann namentlich anreden, bekommt den Ansprechpartner mangels Feld aber nicht übergeben. Gehört zum Schriftverkehr in 1.2a: dort entsteht das Schreiben, hier fehlt ihm die Anrede. *Issue: [#9](https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/issues/9).* ### Inventarliste als eigenes Modell Wertgegenstände hängen heute an Freitext und Fotos. Für die Wohnungsauflösung wäre eine Liste mit Bezeichnung, Raum, geschätztem Wert und Verbleib das richtige Werkzeug. ### Pflegegrad-Historie Der Pflegegrad steht als einzelnes Feld in den Stammdaten. Frühere Grade mit ihren Zeiträumen gehören in eine Historie — sie werden im Jahresbericht und bei einer Höherstufung gebraucht. --- ## 1.2a — Schriftverkehr, der sich nicht wiederholt **Ziel:** Ein Schreiben wird einmal geschrieben, einmal ausgegeben und einmal abgelegt — statt viermal angefasst. Die Anschreiben an Versicherer und Behörden gibt es heute nur als Text zum Markieren und Kopieren. Was danach kommt, macht man von Hand: in Word nachbauen, ausdrucken, abschicken und anschließend noch einmal als Dokument in die Akte legen. Vergessen wird regelmäßig der letzte Schritt — und dann fehlt der Nachweis genau dort, wo er später gebraucht wird. Nach der Priorisierungsregel am Ende dieser Datei ist das Kriterium 2: Es kostet jeden Monat Zeit, und einmal im Jahr — vor Vermögensverzeichnis und Jahresbericht — besonders viel. Bisher stand das Thema als einzelne Zeile unter „Später, ohne Datum", also unter „wäre schön, und ehrlich gesagt vielleicht nie". Das war zu tief gehängt. Die Punkte bauen aufeinander auf und stehen deshalb in dieser Reihenfolge. ### Verträge überhaupt erst finden Am Anfang einer Betreuung weiß niemand, welche Verträge es gibt; es liegt kein Ordner bereit, und die betreute Person kann es oft selbst nicht mehr sagen. Die Antwort steht aber schon im System: **Wer regelmäßig abbucht, hat einen Vertrag.** Eine Auswertung der Gegenstellen nach wiederkehrenden Zahlungen macht aus hunderten Buchungszeilen eine Liste von Gesellschaften, an die zu schreiben ist. Solange die fehlt, nützt die beste Briefvorlage nichts — deshalb steht dieser Punkt vor allen anderen. *Issue: [#3](https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/issues/3).* ### Schreiben erzeugen, ablegen, nachhalten Das Kernstück: eine Word-Datei statt Text zum Kopieren, Ablage als Ausgangsdokument mit Empfänger und Versanddatum, Wiedervorlage mit vorbelegter Frist. Dazu Empfänger, zu denen es noch keinen Datensatz gibt — am Anfang schreibt man ja gerade an Stellen, von denen man erst erfahren will, ob dort etwas besteht. Der Text bleibt vor der Ausgabe änderbar, weil jeder Fall eine Besonderheit hat, die in den Brief gehört. Die Bausteine liegen bereits im Code; was fehlt, ist der durchgehende Weg. Alles Weitere in diesem Abschnitt setzt darauf auf. *Issue: [#4](https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/issues/4).* ### Dasselbe Schreiben als E-Mail Vieles geht per Mail raus, nicht per Brief. Dafür müssen Betreff und Text getrennt vorliegen und Absenderblock, Anschrift und Datumszeile verschwinden. Auseinandergebaut wird das heute von Hand, und dabei fällt regelmäßig etwas heraus, das drinbleiben sollte. *Issue: [#5](https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/issues/5).* ### Rückkaufswerte in einem Zug anfragen Vor Vermögensverzeichnis und Jahresbericht sind es jedes Mal dieselben fünf bis zehn Briefe an dieselben Gesellschaften — einzeln erzeugt, einzeln nachgehalten, und bei zwei Dritteln muss nachgefasst werden. Das ist der Handgriff, der im Jahr am meisten Zeit kostet, und derjenige, der sich am einfachsten bündeln lässt, sobald ein Schreiben ohnehin auf Knopfdruck entsteht. *Issue: [#6](https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/issues/6).* ### Eigene Vorlagen Die Brieftexte stehen fest im Programmcode. Formulierungen, die sich bei einer bestimmten Stelle bewährt haben, lassen sich nicht hinterlegen, und für Schreiben ohne mitgelieferte Vorlage — Auskunftsersuchen, Vollmachtsnachweis, Adressänderung — fängt man bei null an. Wer eine Vorlage selbst schreibt, vergisst als Erstes den Bestellungsabsatz; ohne den antwortet keine Versicherung, und dann ist ein Monat vergangen. Die Vorlagenverwaltung muss ihn deshalb einfordern, statt ihn nur anzubieten. *Issue: [#7](https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/issues/7).* ### Dauerzahlungen gelten als belegt Ist ein Vertrag erst erfasst, ist er auch der Beleg für die Zahlungen daraus. Für zwölf gleiche Lastschriften will niemand zwölf Quittungen sehen, sondern die Police. Heute bleibt dafür nur ein Freitextfeld je Buchung — stumpfe Arbeit mit einem Ergebnis, das schwächer aussieht als die Aktenlage tatsächlich ist. Das Feld gehört in dieselbe Migration wie `Buchung.immobilieId` aus 1.1; zwei Wanderungen an derselben Tabelle wären Verschwendung. *Issue: [#11](https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/issues/11). Migration: ein Feld, ein Index — gebündelt mit 1.1.* ### Was in 1.1 und 1.2 dazugehört Zwei Punkte weiter oben sind Teil derselben Sache und bleiben trotzdem stehen, wo sie stehen: „Rückkaufswert am Vertrag" ist ein möglicher Fehler und deshalb 1.1, „Ansprechpartner am Vorgang" ein Handgriff und deshalb 1.2. Gelesen gehören sie hierher — der eine liefert den Wert, um den das Anschreiben bittet, der andere die namentliche Anrede. *Issues: [#8](https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/issues/8) und [#9](https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/issues/9).* --- ## 1.2b — Passkeys abrunden Der Grundstock steht seit 1.1.0. Was noch fehlt, ist Bequemlichkeit, nicht Sicherheit. ### Passkey direkt im Anmeldefeld anbieten Browser können einen Passkey im Ausfüllvorschlag des E-Mail-Feldes anbieten (*conditional UI*), statt hinter einem eigenen Knopf. Ein Schritt weniger. Braucht einen zweiten Challenge-Weg und sorgfältiges Abbrechen, wenn stattdessen doch das Passwort getippt wird. ### Passkey umbenennen Heute geht nur anlegen und entfernen. Wer sein Gerät „Handy" genannt hat und inzwischen zwei hat, muss den Passkey neu einrichten. ### Warnen, wenn der letzte Passkey nur auf einem Gerät liegt Die Liste sagt bereits, ob ein Schlüssel gesichert ist. Wer ausschließlich ungesicherte Passkeys hat und dazu keine Wiederherstellungscodes mehr, sollte das deutlicher zu sehen bekommen als in einer Zeile Kleingedrucktem. --- ## 1.3 — Belastbarkeit **Ziel:** Die Stellen absichern, die bisher nur unter Laborbedingungen geprüft sind. ### Texterkennung gegen echtes Tesseract Bisher ist nur der Weg „nicht verfügbar, Upload funktioniert trotzdem" getestet. Ein Test im Container gegen echte Schreiben — auch schlechte Handyfotos, auch mehrseitige Bescheide — fehlt. ### CAMT.053 gegen einen echten Bankauszug Der Leser ist gegen selbst gebaute Beispiele geprüft. Ein echter Auszug der Sparkasse ist der eigentliche Test. ### Suche und Belegmappe gegen Postgres Beide sind nur in Einzelteilen geprüft, nicht end-to-end gegen die Datenbank mit einigen hundert Dokumenten. ### Wiederherstellung als Test Die Anleitung dafür steht in der README. Ein Skript, das sie einmal im Monat automatisch durchspielt — Sicherung zurückspielen, Diagnosen im Klartext prüfen, Testdatenbank verwerfen — wäre der Beweis statt der Absichtserklärung. ### Passkey-Ablehnung ohne Browser nachstellen Die Prüfung „Passkey ohne Nutzerverifikation wird abgewiesen" ist im Code doppelt abgesichert und im Browsertest belegt — dort weist allerdings schon der Browser ab, der Server kommt gar nicht dran. Ein Test, der die Antwort von Hand baut und den Browser umgeht, würde den serverseitigen Rückhalt tatsächlich beweisen. ### Barrierefreiheits-Durchgang mit einem Screenreader Semantik, Fokusreihenfolge und Kontraste sind beim Bauen beachtet und in Teilen getestet. Ein Durchgang mit NVDA oder VoiceOver ist etwas anderes als eine Testzusicherung. ### `@react-pdf/renderer` ohne Krücke `src/lib/pdf/standardschrift.ts` gleicht aus, dass die Unterabhängigkeiten für Standardschriften kein Schriftobjekt mehr liefern. Ein `overrides`- Eintrag in der `package.json` oder eine neuere Fassung macht die Datei überflüssig — sie baut sich dann selbst ab. --- ## 2.0 — Mehr als eine Betreuung **Ziel:** Was sich nur mit einem Bruch lösen lässt. Deshalb eine eigene Hauptversion — und deshalb nicht vorher. ### Zweite betreute Person im Alltag erprobt Das Datenmodell trägt es von Anfang an: Alles hängt an einer `betreuteId`, der Zugriff wird gegen sie geprüft, die Auswahl steht in der Seitenleiste. **Gelaufen ist es bisher nur mit einer.** Was fehlt, ist Erfahrung — und vermutlich ein Dashboard, das über beide hinwegsieht. ### Heimkostenmodell entwirren Der einrichtungseinheitliche Eigenanteil auf der Heimrechnung ist bereits um die Leistung der Pflegekasse gekürzt. Das Modul rechnet deshalb ausdrücklich nach der Lesart `EIGENANTEIL_NETTO` und warnt, wenn die Pflegekassenleistung zusätzlich erfasst wird. Sauberer wäre, die beiden Lesarten im Modell zu trennen, statt sie im Kopf auseinanderzuhalten. Das ändert bestehende Datensätze — also 2.0. ### Mehrere Fassungen je Bericht Heute verdrängt die DOCX-Ausgabe die abgegebene PDF-Fassung. Was einmal beim Gericht lag, sollte unverändert nachweisbar bleiben. ### Verschlüsselte Ablage auch bei S3 Beim Dateitreiber liegen Dokumente zusätzlich AES-256-GCM-verschlüsselt. Bei S3 geht das nicht, weil signierte URLs am Server vorbei ausgeliefert werden. Der Ausweg wäre, Dateien durch die Anwendung zu reichen — das kostet Durchsatz und ist eine bewusste Abwägung, keine Selbstverständlichkeit. --- ## Später, ohne Datum Sinnvoll, aber nicht dringend: - **Kalendarische Wiedervorlage per E-Mail als Wochenübersicht** statt einzelner Erinnerungen. - **Import eines Grundbuchauszugs** als strukturierte Daten statt als PDF. - **Mehrere Betreuungsgerichte** je betreuter Person (bei Umzug). - **Zwei-Personen-Prinzip** für besonders sensible Aktionen — technisch vorbereitet durch die erneute Anmeldung, fachlich noch nicht gebraucht. - **Statistik über mehrere Betreuungsjahre** für den eigenen Überblick. --- ## Bewusst nicht geplant Damit klar ist, worauf niemand warten muss: | Was | Warum nicht | |---|---| | **Automatische Rechtsberatung** | Die Anwendung kennt den Einzelfall nicht. Sie rechnet und dokumentiert; entscheiden tun Gericht, Träger und im Zweifel das Sozialgericht. | | **Prognosen zu Bewilligungschancen** | Eine Zahl, die niemand belegen kann, wird trotzdem geglaubt. Das ist schlimmer als keine Zahl. | | **Direkte Bankanbindung** | Ein dauerhafter Kontozugriff ist ein Risiko, das der Bequemlichkeit nicht wert ist. CSV und CAMT reichen. | | **Mehrmandantenfähigkeit für fremde Betreuungen** | Sobald mehrere Betreuer mit fremden Fällen auf derselben Installation arbeiten, ändert sich die datenschutzrechtliche Lage grundlegend. Mehrere Betreute **einer** Person bleiben möglich. | | **Native App für Handy und Tablet** | Die Web-Anwendung ist am Telefon vollwertig bedienbar. Eine zweite Oberfläche wäre eine zweite Oberfläche, die veraltet. | | **Cloud-Angebot für andere Betreuer** | Dann wäre ich Auftragsverarbeiter für fremde Gesundheitsdaten. Eine andere Aufgabe als die, für die das hier gebaut wurde. | | **KI-Auswertung der Akte** | Gesundheitsdaten einer nicht entscheidungsfähigen Person verlassen diesen Server nicht. Die Texterkennung läuft lokal, und dabei bleibt es. | --- ## Wie hier priorisiert wird Drei Fragen, in dieser Reihenfolge: 1. **Kann daraus ein falscher Wert in einem Bericht ans Gericht werden?** Dann sofort — auch wenn es unbequem ist. 2. **Kostet es jeden Monat Zeit?** Dann bald. 3. **Wäre es schön?** Dann irgendwann, und ehrlich gesagt vielleicht nie. Fällt ein Punkt in Kategorie 1 und wird trotzdem nicht sofort behoben, steht der Grund dabei — und die Oberfläche sagt an der betroffenen Stelle, worauf man achten muss. Ein stillschweigend falscher Wert ist das Schlimmste, was diese Anwendung produzieren kann.