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>

CHANGELOG.md

@@ -6,6 +6,84 @@ Alle nennenswerten Änderungen an FLORIAN. Format nach
 
 Die Regeln dazu stehen in [docs/VERSIONIERUNG.md](docs/VERSIONIERUNG.md).
 
+## [1.0.0] — 2026-09-06
+
+**Freigabe für den Echtbetrieb.**
+
+Kein neues Modul. Zwölf Phasen sind fertig, und die Wehr kann ab jetzt echte
+Daten hineingeben, ohne befürchten zu müssen, sie beim nächsten Update zu
+verlieren.
+
+Was 1.0.0 bedeutet: der Funktionsumfang ist vollständig, die Datenbank ist
+stabil, Migrationen sind aufwärtskompatibel, und ab hier gilt semantische
+Versionierung — ein Update bricht nichts, ohne dass es in der Hauptnummer
+steht.
+
+Was es nicht bedeutet: dass keine Fehler mehr da sind.
+
+### Hinzugefügt
+
+- **`update.sh`** — Aktualisieren 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 überhaupt etwas Neues gibt, dann
+  **sichern**, dann holen und bauen (schlägt das fehl, läuft die alte Fassung
+  unverändert weiter), dann umschalten, dann nachsehen, ob die Anwendung
+  antwortet. Tut sie es nicht, stehen die letzten Protokollzeilen da und die
+  Befehle, mit denen der vorherige Stand zurückkommt.
+
+  Vorher prüft es Docker, git, die `.env` und dass keine unverbuchten
+  Änderungen im Verzeichnis liegen. `--pruefen` sieht nur nach,
+  `--ohne-sicherung` gibt es für Testinstallationen.
+
+- **`docs/KURZANLEITUNG.md`** — der Einstieg, nach Rollen sortiert und auf ein
+  paar Seiten. Die vollständige Anleitung hat 63 Kapitel; die liest niemand,
+  bevor er das erste Gerät prüfen will. Diese hier ist aufgabenorientiert
+  („ein Gerät prüfen", „einen Kontoauszug einlesen") statt nach Modulen
+  geordnet, und sie sagt bei jedem heiklen Punkt dazu, warum es so ist — warum
+  ein abgeschlossenes Prüfprotokoll nicht änderbar ist, warum gegengebucht und
+  nicht korrigiert wird, warum der Atemschutzhinweis stehen bleibt.
+
+### Geändert
+
+- Version auf **1.0.0**. Ab hier gilt semantische Versionierung nach
+  [docs/VERSIONIERUNG.md](docs/VERSIONIERUNG.md).
+- Die Roadmap hält den Stand **jeder** Freigabevoraussetzung fest, auch der
+  offenen. Zwei sind organisatorisch und stehen aus: die Abnahme des
+  Löschkonzepts durch die Wehr und die Schulung. An der Software hängt nichts
+  davon ab; sie stehen dort, damit später nachlesbar ist, was zum Zeitpunkt
+  der Freigabe erledigt war und was nicht.
+
+### Behoben
+
+- **Die Testläufe flackerten seit Phase 8 — jetzt ist die Ursache weg.** Zwei
+  Datenbanktests schalteten beim Aufräumen ihre Trigger mit
+  `ALTER TABLE ... DISABLE TRIGGER` 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 die eine Datei abräumte, prüfte die andere gerade, dass genau
+  dieser Trigger greift, und sah keinen.
+
+  Das erklärt rückwirkend eine ganze Reihe von Fehlschlägen, die als
+  „Flackern" abgetan wurden und keines waren. Statt der Schemaänderung wird
+  jetzt `SET LOCAL session_replication_role = 'replica'` benutzt: dieselbe
+  Wirkung, aber nur in der eigenen Transaktion. Fünf Läufe hintereinander
+  sauber.
+
+- **Ein Datenbanktest räumte nur am Ende auf.** Brach ein Lauf ab, scheiterte
+  der nächste an einer Eindeutigkeit, die mit dem Geprüften nichts zu tun
+  hatte. Er räumt jetzt auch am Anfang auf.
+
+### Zum Stand der Freigabevoraussetzungen
+
+| Voraussetzung | Stand |
+|---|---|
+| Datenübernahme | **entfällt** — die Wehr pflegt von Hand ein |
+| Sicherungskonzept, einmal wiederhergestellt | **erledigt** (Phase 11) |
+| Löschkonzept nach DSGVO | **technisch vollständig** (Phase 11), Abnahme steht aus |
+| Schulung | **steht aus**, Grundlage ist die Kurzanleitung |
+| Atemschutzhinweis | **bewusst stehen gelassen** — FLORIAN bleibt ergänzend |
+
+---
+
 ## [0.12.0] — 2026-09-05
 
 Phase 11: Freigabereife. Die drei Software-Voraussetzungen für 1.0.0 —