Florian Wilde
0128bf71e7
Am Schreibtisch war "Mein Konto" praktisch nicht zu finden - und damit auch nicht Passwortwechsel, zweiter Faktor und Passkey-Verwaltung. Die Seitenleiste hatte keine feste Hoehe und wuchs mit der Seite mit. Ihr Fuss mit dem Benutzermenue landete deshalb am Ende der SEITE statt am unteren Bildschirmrand: auf /heute bei 1632 Pixel in einem 900 Pixel hohen Fenster. Nachgemessen, nicht geraten - im Browser auf fuenf Seiten. Der Fehler sah nach nichts aus. Kein Element fehlte, nichts war kaputt, die Seite sah richtig aus. Man musste nur ganz nach unten scrollen. Behoben mit lg:sticky, lg:top-0, lg:h-dvh und lg:self-start. Das self-start gehoert dazu, weil ein Flex-Kind sonst auf die volle Zeilenhoehe gestreckt wird und die feste Hoehe wieder verliert. Die Navigation dazwischen hat bereits overflow-y-auto und scrollt bei Bedarf in sich selbst. Am Handy war es nie ein Problem - dort sitzt das Menue in der ohnehin festen Kopfzeile. Neu: e2e/benutzermenue.spec.ts fragt nicht, ob das Menue im DOM ist, sondern ob es im sichtbaren Bereich steht - auf fuenf Seiten, an drei Scrollpositionen, auf einem flachen Laptopfenster und am Handy. Die Position in der Mitte ist Absicht: Am Seitenende wird eine mitwachsende Leiste zufaellig doch sichtbar, der Test waere gruen und der Fehler trotzdem da. Beide Sichtbarkeitstests sind gegen den kaputten Zustand gegengeprueft und schlagen dort an. Refs #1
295 lines
11 KiB
Markdown
295 lines
11 KiB
Markdown
# 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.1.2** ([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.
|
|
|
|
*Aufwand: klein.*
|
|
|
|
### 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.
|
|
|
|
### 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.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.
|
|
- **Vorlagen für eigene Anschreiben**, über die mitgelieferten hinaus.
|
|
- **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.
|