Version 1.0.0 — Freigabe fuer den Echtbetrieb

Kein neues Modul. Zwoelf Phasen sind fertig, und die Wehr kann ab jetzt
echte Daten hineingeben, ohne befuerchten zu muessen, sie beim naechsten
Update zu verlieren.

Neu dazu, weil beides zum Betrieb gehoert:

update.sh aktualisiert auf einem Linux-Server in einem Befehl. Der Ablauf
darf an jeder Stelle abbrechen, ohne eine halb aktualisierte Anlage zu
hinterlassen: erst nachsehen ob es etwas Neues gibt, dann sichern, dann
holen und bauen (schlaegt das fehl, laeuft die alte Fassung unveraendert
weiter), dann umschalten, dann pruefen ob die Anwendung antwortet. Tut sie
es nicht, stehen die Protokollzeilen da und die Befehle fuer den Rueckweg.

docs/KURZANLEITUNG.md ist der Einstieg fuer die Wehr - nach Rollen
sortiert, aufgabenorientiert statt nach Modulen, und bei jedem heiklen
Punkt steht das Warum dabei. Die vollstaendige Anleitung hat 63 Kapitel;
die liest niemand, bevor er das erste Geraet pruefen will.

Die Roadmap haelt den Stand JEDER Freigabevoraussetzung fest, auch der
offenen: Datenuebernahme entfaellt (die Wehr pflegt von Hand ein),
Sicherungskonzept erledigt, Loeschkonzept technisch vollstaendig aber
nicht abgenommen, Schulung steht aus, Atemschutzhinweis bewusst stehen
gelassen. Eine Freigabe, die abhakt was nicht geprueft wurde, ist keine.

Nebenbei die Ursache der Testflackerei gefunden, die sich durch mehrere
Phasen zog: zwei Datenbanktests schalteten beim Aufraeumen ihre Trigger
mit ALTER TABLE ... DISABLE TRIGGER ab - eine Schemaaenderung, die fuer
die ganze Datenbank gilt. Vitest faehrt die Dateien parallel, also pruefte
eine Datei gerade dass ein Trigger greift, waehrend eine andere ihn
abgeraeumt hatte. Jetzt sitzungslokal ueber session_replication_role.

Erstmals in diesem Projekt: fuenf Unit-Testlaeufe hintereinander 601 gruen
und ein E2E-Lauf mit 268 gruen ohne Fehlschlag und ohne Flackern.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

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
 
 ---