Version 1.0.0 — Freigabe für den Echtbetrieb (#17)

docs/DEVLOG.md

@@ -24,7 +24,107 @@ Die aufgewendete Zeit wandert nach jedem Abschnitt in die Spalte
 | Phase 9 — Kassenverwaltung | 4:10 h | 1 | 04.09.2026 |
 | Phase 10 — Mandantenfähigkeit | 4:20 h | 1 | 05.09.2026 |
 | Phase 11 — Freigabereife | 2:40 h | 1 | 05.09.2026 |
-| **Summe** | **35:30 h** | **14** | |
+| 1.0.0 — Freigabe | 0:50 h | 1 | 06.09.2026 |
+| **Summe** | **36:20 h** | **15** | |
+
+---
+
+## 2026-09-06 · 1.0.0 — Freigabe
+
+**09:20 – 10:10 · 0:50 h · Version 1.0.0**
+
+### Was entstanden ist
+
+Kein Modul. Zwei Dinge, die zum Betrieb gehören, und eine Entscheidung.
+
+| Was | Wofür |
+|---|---|
+| `update.sh` | Aktualisieren auf einem Linux-Server, in einem Befehl |
+| `docs/KURZANLEITUNG.md` | Der Einstieg für die Wehr, nach Rollen sortiert |
+| Version 1.0.0 | Ab hier semantische Versionierung |
+
+### Entscheidungen
+
+**Das Update-Skript sichert, bevor es irgendetwas anfasst.** Ein Update ist
+der häufigste Anlass, eine Sicherung zu brauchen — und der Moment, in dem
+niemand daran denkt. `--ohne-sicherung` gibt es, aber mit einer Warnung und
+nicht als Vorgabe.
+
+**Die Reihenfolge ist so gewählt, dass ein Abbruch harmlos bleibt.** Holen und
+Bauen passieren, bevor umgeschaltet wird: schlägt der Bau fehl, läuft die alte
+Fassung unverändert weiter. Erst danach wird umgeschaltet, und ab da nennt die
+Fehlerbehandlung die Befehle für den Rückweg.
+
+**Die Kurzanleitung ist aufgabenorientiert, nicht modulorientiert.** Die große
+Anleitung hat 63 Kapitel und ist nach Funktionsbereichen sortiert — richtig
+zum Nachschlagen, unbrauchbar zum Anfangen. Die Kurzanleitung fragt stattdessen
+„was willst du tun": ein Gerät prüfen, einen Kontoauszug einlesen, einen
+Termin absagen.
+
+**Sie erklärt bei jedem heiklen Punkt das Warum.** Warum ein abgeschlossenes
+Prüfprotokoll nicht änderbar ist, warum gegengebucht statt korrigiert wird,
+warum der Atemschutzhinweis stehen bleibt. Wer den Grund kennt, sucht nicht
+nach dem Weg drumherum.
+
+**Die Roadmap hakt nicht alles ab.** Zwei Freigabevoraussetzungen sind
+organisatorisch und stehen aus — die Abnahme des Löschkonzepts und die
+Schulung. Sie stehen mit ihrem Stand dort, statt stillschweigend als erledigt
+zu gelten. Eine Freigabe, die abhakt, was nicht geprüft wurde, ist keine.
+
+### Wo es gehakt hat
+
+**Die Ursache der Testflackerei gefunden — nach elf Phasen.**
+
+Beim abschließenden Durchlauf fielen wieder einmal fünf, dann sechs, dann ein
+Test aus, in wechselnder Besetzung. Dieses Mal habe ich nicht weitergemacht,
+sondern fünf Läufe hintereinander mitgeschrieben: betroffen waren immer
+Zusicherungen über Trigger — „Wiki-Fassungen bleiben", „Mandantentrennung",
+„abgeschlossene Prüfprotokolle".
+
+`ki-datenbank.test.ts` und `atemschutz-datenbank.test.ts` schalteten beim
+Aufräumen ihre Trigger mit `ALTER TABLE ... DISABLE TRIGGER USER` ab. Das ist
+eine Schemaänderung: sie gilt für die ganze Datenbank und für alle. Vitest
+fährt die Testdateien parallel — während also die eine Datei abräumte, prüfte
+die andere gerade, dass genau dieser Trigger greift, und sah keinen.
+
+`SET LOCAL session_replication_role = 'replica'` bewirkt dasselbe, aber nur in
+der eigenen Transaktion. Danach: fünf Läufe hintereinander 601 grün.
+
+Rückwirkend erklärt das eine Reihe von Ausfällen, die ich als Flackern
+abgetan habe — sie waren keines. Die Lehre ist unbequem: „läuft einzeln durch,
+also Umgebung" ist eine bequeme Erklärung und oft die falsche.
+
+| Weiteres | Ursache | Lösung |
+|---|---|---|
+| Ein Datenbanktest ließ sich nur einmal ausführen | `mandanten-datenbank.test.ts` räumte nur am Ende auf; ein abgebrochener Lauf legte den nächsten lahm | Räumt jetzt auch am Anfang auf — dasselbe Muster wie in Phase 10 bei `ki-datenbank` |
+
+### Abweichung von der Vorgabe
+
+**`update.sh` ist nicht auf einem Linux-Server erprobt.** Entwickelt wurde
+unter Windows; geprüft sind die Syntax (`bash -n`), die Hilfe, die
+Argumentbehandlung und der Wächter gegen unverbuchte Änderungen — alles unter
+Git Bash. Der eigentliche Ablauf (fetch, build, up, Gesundheitsprüfung) läuft
+erst dort, wo FLORIAN wirklich steht.
+
+Das ist keine Nachlässigkeit, sondern die Grenze dieser Umgebung. Beim ersten
+echten Update gehört `./update.sh --pruefen` vorangestellt: es holt nichts und
+ändert nichts, zeigt aber, ob Docker, git und die `.env` gefunden werden.
+
+### Nachweise
+
+- `npm run typecheck` — ohne Ausgabe
+- `npm run lint` — ohne Befund
+- `npm run test` — 601 Tests grün
+- `bash -n update.sh` — Syntax in Ordnung
+- `./update.sh --help` und `--quatsch` — Ausgabe und Ablehnung wie vorgesehen
+- Der Wächter gegen unverbuchte Änderungen greift (an einem schmutzigen
+  Arbeitsverzeichnis geprüft)
+- Alle acht Bilder der Kurzanleitung existieren
+- `npm run test` **fünfmal hintereinander** — jedes Mal 601 grün. Das war
+  nach elf Phasen der erste Lauf, bei dem ich das behaupten kann
+- `npm run test:e2e` — **268 grün, kein Fehlschlag, kein Flackern.** Ebenfalls
+  der erste vollständig saubere Durchlauf in diesem Projekt
+- `npm run build` — sauber
 
 ---