Zwei Fehler, beide erst im Betrieb sichtbar.
1. Schritt 3 der Ersteinrichtung meldete "Bitte pruefe die markierten
Felder" - und markierte keines. Man kam dort nicht weiter.
Das kurze Formular schickt neun Felder, das vollstaendige unter
Stammdaten alle. Beide gehen durch dasselbe Schema, und die optionalen
Felder waren zwar nullable, aber nicht optional: Ein Feld, das gar
nicht abgeschickt wurde, ist undefined, nicht null. Beanstandet wurden
also zwei Dutzend Felder, die auf dem Bildschirm nie standen.
Damit das nicht wiederkommt, unterscheidet die Aktion jetzt zwischen
Eingabefehler und Formular-Schema-Bruch: Beanstandet die Pruefung ein
Feld, das nicht abgeschickt wurde, sagt sie das ausdruecklich und
schreibt es ins Serverlog, statt es dem Nutzer als Eingabefehler
unterzuschieben, den er nirgends finden kann.
2. Eine betreute Person liess sich nicht endgueltig loeschen. Postgres
setzt beim Loeschen den Verweis im Audit-Log auf NULL, und genau
dieses UPDATE hat der Unveraenderlichkeits-Trigger abgewiesen. Damit
scheiterte auch das Leeren des Papierkorbs nach 30 Tagen.
Der Trigger erlaubt jetzt genau eine Ausnahme: das Nullen der beiden
Fremdschluessel. Jede andere Aenderung bleibt verboten, auch das
Setzen eines Fremdschluessels auf einen anderen Wert. Der Nachweis
bleibt vollstaendig - es verschwindet nur der Verweis auf einen
Datensatz, den es nicht mehr gibt.
Geprueft: sieben neue Tests gegen die tatsaechlichen Formularinhalte, der
Ablauf einmal komplett im Browser bis zum Dashboard, und der Trigger
gegen eine laufende Datenbank - Loeschen gelingt, Faelschen scheitert.
Etappe: 8
Phase: Haertung
Damit ist Etappe 1 fachlich vollstaendig.
Ersteinrichtung in drei Schritten, bewusst ausserhalb des
Anwendungsrahmens: der setzt Benutzer, zweiten Faktor UND eine betreute
Person voraus - beim allerersten Start gibt es nichts davon. Die Aktion
fuer den ersten Zugang sperrt sich selbst, sobald ein Benutzer existiert.
Zweiter Faktor: Das Geheimnis wird zuerst nur abgelegt, ohne
totpAktiviertAm. Erst ein echter Code aus der App schaltet ihn scharf.
Wer sich beim Abtippen vertut oder die falsche App nimmt, wuerde sich
sonst dauerhaft aussperren. Erst danach gibt es die
Wiederherstellungscodes - einmal angezeigt, danach nur noch als Hash.
Betreuungsjahr (src/lib/stammdaten/betreuungsjahr.ts): laeuft ab dem Tag
der Bestellung, nicht ab dem Kalenderjahr. Schrittweise vorwaerts
gerechnet statt ueber eine Differenz, damit Schaltjahre und der
29. Februar von selbst stimmen. Daran haengen Jahresbericht,
Rechnungslegung und die Ausschlussfrist der Aufwandspauschale.
Aendert sich das Bestellungsdatum, werden die Pflichtfristen neu
abgeleitet - ueber einen dynamischen Import, damit die Stammdaten auch
dann speicherbar bleiben, wenn das Fristenmodul fehlt.
Protokollansicht zeigt je Eintrag die geaenderten Felder als alt -> neu.
Die Aenderungen liegen verschluesselt, weil dort Diagnosen und
Kontostaende stehen koennen.
Seed legt bewusst keine echten Personendaten an, nur den ersten Zugang.
Mit SEED_DEMO=true kommt ein vollstaendiger Beispielfall dazu - Erika
Musterfrau, COPD GOLD III, Pflegegrad 3, Heimeinzug Januar 2026,
leerstehendes Haus, zwei Versicherungen, laufender Antrag beim Bezirk
mit acht Nachforderungen. Nur ausserhalb der Produktion.
Docker Compose ohne Reverse Proxy - der ist auf dem Zielserver
vorhanden. Die Datenbank hat keine Portfreigabe und ist nur ueber das
interne Netz erreichbar; die Anwendung horcht auf 127.0.0.1.
Etappe: 1
Phase: Fundament
Florian Wilde