Zwei Fehler beim ersten Probelauf des Update-Skripts.
Der Changelog blieb leer. Das Skript las CHANGELOG.md aus der Arbeitskopie
- also aus dem LAUFENDEN Stand, der die neuen Abschnitte naturgemaess noch
nicht kennt. Jetzt kommt er ueber git show aus der Zielfassung.
Das Umschalten scheiterte an einer unversionierten Datei. Genau das
passiert beim Sprung auf die Fassung, die dieses Skript eingefuehrt hat:
Man holt es sich von Hand, und in der Zielfassung gehoert es dann dazu -
git weigert sich, eine unversionierte Datei zu ueberschreiben. Solche
Dateien werden jetzt nicht weggeworfen, sondern nach .vor-update-<zeit>
beiseite geschoben, danach laeuft das Umschalten durch.
Etappe: 8
Phase: Haertung
Bisher war Aktualisieren eine Folge von Befehlen aus der Anleitung, und
zwei davon vergisst man zuverlaessig: die Sicherung vorher und die beiden
SQL-Skripte hinterher. Genau die hat es hier schon gekostet.
./scripts/update.sh macht das in einem Durchgang - mit zwei
Eigenschaften, auf die es ankommt:
Bis zur Rueckfrage wird nichts veraendert. Der erste Entwurf hat die
eigenen Aenderungen beiseite gelegt und danach am Serverzugriff
abgebrochen - Halbzustand, aus dem man erst wieder herausfinden muss.
Jetzt laufen Pruefung, Abgleich und Changelog-Anzeige vollstaendig
durch, bevor irgendetwas angefasst wird.
Eigene Aenderungen an versionierten Dateien blockieren nicht. Im Betrieb
passt man die docker-compose.yml an, bis etwas laeuft; genau diese
Anpassungen sind spaeter oft schon eingearbeitet. Das Skript legt sie mit
git stash beiseite - rueckholbar, nicht weggeworfen - und sagt, wie man
sie zurueckbekommt. Wer sie wirklich loswerden will, nimmt --verwerfen.
Die .env bleibt immer unangetastet.
Schlaegt die Sicherung fehl, wird nicht aktualisiert. Schlaegt der Bau
fehl, nennt das Skript den Weg zurueck.
Nebenbei behoben: Der Port der MinIO-Konsole stand fest auf 9001. Lief
dort schon etwas, startete der ganze Stapel nicht. Jetzt ueber
MINIO_KONSOLE_PORT einstellbar - dieselbe Moeglichkeit, die APP_PORT
schon hatte. Aufgefallen beim Aufsetzen einer Testumgebung.
Etappe: 8
Phase: Haertung
docker-compose.yml reicht ENC_KEY_V2 immer an den Behaelter durch - mit
leerem Wert, wenn in der .env keiner steht. src/lib/env.ts erkannte
Schluessel aber am Variablennamen statt am Inhalt, fand also ein leeres
ENC_KEY_V2 und brach ab mit "Umgebungsvariable ENC_KEY_V2 fehlt".
Die Meldung war doppelt irrefuehrend: Sie nannte einen Schluessel, den
niemand wollte, und sie erschien an einer Stelle, die damit nichts zu tun
hat - beim Einrichten des zweiten Faktors, als Serverfehler ohne Text.
Betroffen war jede Stelle, die verschluesselte Felder schreibt oder
liest, also praktisch alles ausser der Anmeldung selbst. Die kam durch,
weil sie ohne Verschluesselung auskommt - der Fehler trat deshalb erst
auf der naechsten Seite auf, und der Zusammenhang war nicht zu sehen.
Leere Schluesselvariablen werden jetzt uebersprungen. Sieben Tests decken
die Auswertung ab, darunter genau diese Konstellation.
Die Meldung beim Schluesselwechsel nennt jetzt ausserdem, welche
Versionen vorhanden sind, und die richtige Reihenfolge: erst den neuen
Schluessel eintragen, dann ENC_KEY_AKTIV umstellen.
Dazu scripts/anmeldung-pruefen.mjs. Das Anmeldeformular sagt bewusst
nicht, woran eine Anmeldung scheiterte - sonst liesse sich daran ablesen,
welche Adressen es gibt. Auf dem Server darf man es wissen: Jeder Versuch
wird mit Grund protokolliert, und das Skript liest ihn vor, zusammen mit
dem Zustand des Zugangs, dem Stand der Sperre und der AUTH_URL.
Etappe: 8
Phase: Haertung
Die Anwendung zeigt das Geheimnis genau einmal an, beim Einrichten - das
ist richtig so. Wer den Zugang aber auf ein zweites Geraet legen will,
Handy und Tablet oder ein Ersatzgeraet im Schrank, braucht es noch
einmal. Bisher blieb dafuer nur, den zweiten Faktor zurueckzusetzen und
alle Wiederherstellungscodes neu zu erzeugen.
Das Skript laeuft nur auf dem Server und nur mit Zugriff auf die
Datenbank UND auf ENC_KEY_V1. Wer beides hat, kann ohnehin alles lesen -
genau deshalb liegt der Schluessel nicht in der Datenbank. Es ist also
keine Hintertuer, sondern erspart eine unnoetige Neueinrichtung.
Es gibt den otpauth-URI mit aus, aber mit dem ausdruecklichen Hinweis,
ihn in einen QR-Erzeuger auf demselben Rechner zu geben und nicht in
einen Dienst im Netz - sonst haette man das Geheimnis gerade dorthin
gegeben, wovor der zweite Faktor schuetzen soll.
Geprueft gegen den Entwicklungszugang: der ausgelesene Wert stimmt mit
SEED_DEV_TOTP_SECRET ueberein.
Etappe: 8
Phase: Haertung
Bis jetzt stand nirgends, welcher Stand laeuft. Beim Aktualisieren auf
einem Server ist das die erste Frage.
CHANGELOG.md nach Keep a Changelog, Versionsnummern nach SemVer. Der
Changelog sagt, was sich beim Arbeiten aendert - nicht, welche Datei
angefasst wurde. Dazu eine Tabelle, was Major, Minor und Patch fuer den
Betreiber praktisch bedeuten, und der Hinweis, dass sich eine
Datenbank-Migration nicht zurueckrollen laesst.
Die Version steht bewusst an zwei Stellen: package.json und
src/lib/version.ts. Ein Import der package.json waere im
Standalone-Build eine andere Datei als die des Projekts - die Zahl haenge
dann an der Laufzeit. Ein Test haelt beide zusammen, und
"npm run version" setzt sie gemeinsam samt Changelog-Abschnitt.
Committet und getaggt wird nicht automatisch. Ein Changelog-Eintrag, den
niemand gegengelesen hat, ist keinen Deut besser als keiner.
Sichtbar wird die Version unten in der Seitenleiste und unter
/api/gesundheit - dort mit Git-Stand, den der Docker-Build hineinreicht.
Auf der Anmeldeseite steht sie nicht: wer nicht angemeldet ist, muss
nicht wissen, welche Fassung hier laeuft.
Etappe: 8
Phase: Haertung
Beim Einfuegen war ein echter Zeilenumbruch in ein Zeichenkettenliteral
geraten - das Skript liess sich nicht mehr ausfuehren.
Etappe: 8
Phase: Haertung
Aufstellung, wann was entstanden ist und was es gekostet hat - zur
Nachvollziehbarkeit und zur Kostenrechnung.
Die reine Commit-Rechnung taugt hier nur bedingt: Die Etappen 2 bis 7
sind parallel entstanden, erst drei, dann fuenf Agenten gleichzeitig.
Aus der Historie sieht es aus, als haette Etappe 3 dreissig Minuten
gedauert - tatsaechlich lief sie knapp eine Stunde und gleichzeitig mit
vier anderen. Deshalb steht neben der automatischen Auswertung eine
Tabelle mit den tatsaechlichen Laufzeiten und den Ausgabe-Token je
Agent; daran bemessen sich die Kosten.
Ebenfalls festgehalten: die gut drei Stunden erzwungener Pause am
Sitzungslimit, die in der kalendarischen Spanne stecken, aber keine
Bauzeit sind. Reine Bauzeit rund zwei Stunden 45 Minuten.
Und die sechs Fehler, die waehrend des Baus aufgefallen sind - von der
Server/Client-Grenze bis zur Doppelzaehlung bei den Heimkosten. Die
stehen dort, weil sie zeigen, wo bei dieser Art Anwendung die
Fallstricke liegen.
Etappe: 8
Phase: Haertung
Etappe 8, erster Teil.
Erinnerungsmails sind bewusst eine Zugabe: Ist kein SMTP konfiguriert,
wird nichts gesendet und nichts geworfen. Die Fristen stehen ohnehin im
Dashboard und im abonnierten Kalender - eine ausgefallene Mail darf
nicht dazu fuehren, dass der Wartungslauf abbricht und danach auch das
Aufraeumen liegen bleibt.
In der Mail steht, DASS etwas faellig ist und wo man nachsieht - nicht,
worum es geht. Kein Name der betreuten Person, keine Inhalte. E-Mail ist
unterwegs unverschluesselt und landet auf fremden Servern.
Je Frist geht hoechstens eine Mail pro Vorwarnstufe raus. Taeglich waere
nach einer Woche Rauschen, das man wegklickt - und genau dann verpasst
man die eine, auf die es ankam.
Der Wartungslauf faengt jeden Schritt einzeln ab: Papierkorb leeren,
Anmeldeversuche und altes Audit-Log aufraeumen laufen auch dann, wenn
der SMTP-Server nicht antwortet. Angestossen wird er ueber
/api/wartung mit einem HMAC aus AUTH_SECRET - ohne gueltigen Schluessel
antwortet die Route mit 404 statt 401.
Ein echter Fund aus den Tests: Auth.js reicht den Fehlercode aus
authorize() nicht an die Server Action zurueck. Bei gesperrtem Zugang
sah man deshalb nur die allgemeine Meldung "stimmen nicht" und haette
ratlos weiterprobiert, obwohl die Sperre bereits lief. Die Sperre wird
jetzt zusaetzlich in der Server Action geprueft und benannt; die Pruefung
in authorize() bleibt als eigentliche Sperre bestehen.
Sechs Playwright-Tests der Anmeldung, darunter zwei, die
Sicherheitszusagen nachweisen: dass zwei Fehlversuche mit
unterschiedlicher Ursache dieselbe Meldung liefern (sonst liesse sich
ablesen, welche Adressen existieren), und dass die Anmeldeseite keine
einzige Anfrage an einen fremden Host stellt.
Etappe: 8
Phase: Haertung
Damit ist Etappe 1 abgeschlossen und betriebsfertig dokumentiert.
README mit beiden Betriebswegen. Docker Compose auf eigenem Server ist
der Hauptweg; Vercel und Neon sind vollstaendig beschrieben, aber mit
einer klaren Begruendung, warum ich davon abrate: beide Anbieter sind
US-Unternehmen und unterliegen auch bei EU-Region potenziell dem
CLOUD-Act. Bei Gesundheitsdaten einer nicht entscheidungsfaehigen Person
ist das eine Abwaegung, die man bewusst treffen muss.
Reverse-Proxy-Beispiele fuer Caddy, nginx und Traefik - der Proxy selbst
ist nicht Teil des Compose-Setups, weil er auf dem Zielserver schon
steht. Die Datenbank hat keine Portfreigabe.
Sicherung: pg_dump schreibt direkt in die Verschluesselung, der Klartext
landet nie auf der Platte. Danach eine Selbstpruefung - laesst sich die
Datei nicht wieder entschluesseln, endet der Lauf mit Fehler statt mit
einem stillen Scheinerfolg. Der jeweils erste Stand eines Monats bleibt
dauerhaft stehen.
Die README sagt ausdruecklich, was das Backup NICHT enthaelt: den
Schluessel ENC_KEY_V1 und die Dateien im Objektspeicher. Dazu eine
Anleitung, die Wiederherstellung einmal im Jahr zu ueben - mit dem
letzten Schritt, in der Anwendung nachzusehen, ob die Diagnosen im
Klartext erscheinen. Erst dann stimmt nicht nur die Datenbank, sondern
auch der Schluessel.
Verarbeitungsverzeichnis und Datenschutzhinweise als ausfuellbare
Textbausteine. Die Hinweise sind in einfacher Sprache geschrieben - sie
sollen der betreuten Person vorgelesen werden koennen. Die Seite
/datenschutz liest denselben Text aus docs/, damit es nicht zwei
Fassungen gibt, die auseinanderlaufen.
Dockerfile in drei Stufen mit Tesseract, deutschen Sprachdaten und
poppler-utils. Zeitzone Europe/Berlin ist gesetzt - ohne sie rechnet der
Server in UTC und verschiebt Fristen um einen Tag.
Etappe: 1
Phase: Fundament
Das Server-Layout filtert die Navigation danach, welche Module der
angemeldete Benutzer sehen darf. Es importierte NAV_STRUKTUR aber aus
einer Datei mit "use client" - dort kommt auf dem Server kein Wert an,
sondern nur ein Verweis. NAV_STRUKTUR.filter war entsprechend keine
Funktion, und jede Fachseite lief in einen Serverfehler.
Zweiter Fehler in derselben Zeile: die Eintraege trugen die Icons als
React-Komponenten. Die lassen sich nicht ueber die Server/Client-Grenze
reichen.
Beides behoben, indem die Struktur nach src/lib/navigation-struktur.ts
wandert und dort nur noch ein Kuerzel je Icon steht. Die Client-
Komponente uebersetzt das Kuerzel. Die Wiederausfuhr aus navigation.tsx
wurde bewusst weggelassen, sonst stellt sich dieselbe Falle wieder auf.
Dazu scripts/screenshots.mjs: meldet sich mit dem Entwicklungszugang an
und fotografiert Seiten am Schreibtisch und am Handy, hell und dunkel.
Etappe: 1
Phase: Fundament
Alle Fachentitaeten der Betreuung in einem Schema - bewusst komplett,
damit spaetere Etappen keine Migration am Fundament brauchen.
Kernentscheidungen:
- Geldbetraege durchgaengig als BigInt in Cent. Eine Rechnungslegung nach
§ 1865 BGB darf keine Rundungsfehler erben.
- Felder mit Suffix Verschluesselt tragen einen AES-256-GCM-Umschlag.
Wo trotzdem gesucht werden muss (IBAN), steht ein HMAC-Blindindex daneben.
- Fristen und Stichtage sind @db.Date, nicht DateTime - sonst verschiebt
die Zeitzone eine Frist um einen Tag.
- Frist.systemSchluessel macht die aus dem Bestellungsdatum abgeleiteten
Pflichtfristen idempotent.
- Genehmigung.beschlussDokumentId ist die technische Voraussetzung dafuer,
dass ein Vorgang ohne Beschluss nicht auf VOLLZOGEN gesetzt werden kann.
- DokumentVerknuepfung mit echten Fremdschluesseln statt loser Typ/ID-
Spalte: eine Akte muss referenzsicher sein.
- Wertstand und Saldostand sind Historien - Werte werden nie ueberschrieben.
Dazu zwei SQL-Skripte, die Prisma nicht abbilden kann:
- volltextsuche.sql: tsvector-Trigger (deutsch) mit Gewichtung A/B/C,
plus Trigram-Indizes fuer unscharfe Absendersuche.
- audit-schutz.sql: Trigger, die UPDATE und DELETE auf audit_log
verweigern. Das Log ist Nachweis gegenueber Gericht und Miterben,
also nur anhaengend - auch gegen psql.
Etappe: 1
Phase: Fundament
Grundgeruest der Anwendung: Next.js 15 (App Router), TypeScript im
strict-Modus, Tailwind mit shadcn/ui-Farbtokens.
Bewusste Festlegungen:
- Nur Systemschriften, keine externen Fonts, kein CDN.
- Grundschrift eine Stufe groesser, Fokusring immer sichtbar,
Touchziele mindestens 44px.
- Ampelfarben fuer Fristen als eigene Design-Tokens.
- Betraege werden als Cent-Ganzzahl gefuehrt, damit die Rechnungslegung
keine Rundungsfehler erbt.
- .env.example dokumentiert alle Geheimnisse; npm run schluessel erzeugt sie.
Etappe: 1
Phase: Fundament
Florian Wilde