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

ESLint hatte keine Konfiguration — das Skript "npm run lint" pruefte nichts.
Jetzt Flat Config ohne Formatierungsregeln, dafuer mit den Regeln, die die
Fehler dieses Projekts gemeldet haetten. Er hat gleich zwei gefunden, die
niemand gesucht hatte.

Das Badge rendert ein span statt eines div. Damit ist die Meldung
"div cannot be a descendant of p" weg, die seit Phase 3 auf der Einsatzseite
stand — sie ist der klassische Ausloeser fuer einen Hydration-Fehler.

Die E2E-Tests laufen gegen eine eigene Wehr. Nach fuenf Phasen standen in der
Beispielwehr 120 Atemschutz-Ueberwachungen statt einer und 115 Geraete statt
45; bei jedem Lauf aenderten sich alle Bildschirmfotos. Der Bestand ist einmal
zurueckgesetzt, npm run db:test-reset baut die Testwehr neu auf.

Behoben nebenbei:
- Die Fehlerflaeche der Karte konnte nie etwas anzeigen.
- Zwei useMemo der Lagekarte rechneten bei jedem Rendern neu.
- tests/e2e war vom Typecheck ausgenommen und liess einen doppelt
  deklarierten Bezeichner durch.

Closes #10
Closes #11
Closes #12

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

.env.example

@@ -164,6 +164,11 @@ AUTH_LOCAL_ENABLED=true
 # Nach dem ersten Login das Passwort in der Oberfläche ändern.
 SEED_ADMIN_EMAIL=admin@beispielwehr.de
 SEED_ADMIN_PASSWORT=Feuerwehr2026
+# Das Konto der Kreisebene aus dem Beispielbestand (Phase 10): Mitglied in der
+# eigenen Wehr, Aufsicht in der Nachbarwehr. Vorgabe leitet sich aus der
+# Wehrkennung ab, also kbi@ff-musterhausen.de.
+# SEED_KBI_EMAIL=
+# SEED_KBI_PASSWORT=Feuerwehr2026
 # bcrypt-Kostenfaktor. 12 ist ein guter Kompromiss aus Sicherheit und Tempo.
 AUTH_BCRYPT_ROUNDS=12
 
@@ -328,11 +333,49 @@ BENACHRICHTIGUNG_AUFBEWAHRUNG_TAGE=90
 # -----------------------------------------------------------------------------
 # LLM-Anbindung (optional; nur selbstgehostete Endpunkte, kein Cloud-Zwang)
 # -----------------------------------------------------------------------------
+# ES GIBT KEINEN RUECKFALL AUF EINEN ANBIETER. Laeuft der eigene Endpunkt
+# nicht, fehlen die KI-Funktionen — sie werden nicht durch einen fremden
+# Dienst ersetzt. Ein Einsatzbericht spricht ueber Menschen in ihrer
+# schlechtesten Stunde; solche Texte gehoeren nirgendwo anders hin.
+#
+# Container starten:  docker compose --profile ki up -d
+# Modelle holen:      docker compose exec ollama ollama pull <modell>
 LLM_ENABLED=false
 # OpenAI-kompatibler Endpunkt, z. B. eine lokale Ollama- oder vLLM-Instanz.
 LLM_BASE_URL=http://ollama:11434/v1
 LLM_API_KEY=
 LLM_MODELL=qwen2.5:14b
+# Zeitlimit fuer eine Antwort. Ein Bericht darf dauern, aber nicht ewig.
+LLM_TIMEOUT=120
+
+# Modell fuer Einbettungen (semantische Suche im Wiki).
+#
+# ACHTUNG: Die Spalte wikiabschnitt.einbettung ist auf 768 Dimensionen
+# festgelegt — das liefert nomic-embed-text. Ein Modell mit anderer Laenge
+# braucht eine Migration; wie, steht im README unter Phase 8.
+LLM_EINBETTUNG_MODELL=nomic-embed-text
+LLM_EINBETTUNG_DIMENSIONEN=768
+
+# Modell, das Bilder lesen kann — fuer die Belegerfassung. Ohne dieses Modell
+# werden Belege trotzdem abgelegt, die Angaben nur von Hand eingetragen.
+# LLM_VISION_MODELL=llama3.2-vision
+
+# -----------------------------------------------------------------------------
+# Spracherkennung fuers Diktat (Phase 8, optional)
+#
+# Selbst betriebener faster-whisper im Compose-Profil "ki". Groesse ueber
+# WHISPER_MODELL: "tiny" laeuft auf jedem Buerorechner, "base" ist der
+# brauchbare Kompromiss, "small" erkennt Fachbegriffe merklich besser und
+# will dafuer Zeit oder eine Grafikkarte.
+# -----------------------------------------------------------------------------
+WHISPER_ENABLED=false
+WHISPER_URL=http://whisper:8000
+WHISPER_MODELL=base
+WHISPER_SPRACHE=de
+# Zeitlimit fuer eine Aufnahme. Zehn Minuten Sprache brauchen Zeit.
+WHISPER_TIMEOUT=300
+# Hoechstlaenge einer Aufnahme in Sekunden.
+DIKTAT_MAX_SEKUNDEN=600
 
 # -----------------------------------------------------------------------------
 # Einsätze und Übungen (Phase 3)
@@ -383,3 +426,19 @@ PERSON_ANONYMISIERUNG_TAGE=365
 # -----------------------------------------------------------------------------
 NEXT_TELEMETRY_DISABLED=1
 CHECKPOINT_DISABLE=1
+
+# -----------------------------------------------------------------------------
+# Testwehr fuer die E2E-Tests
+#
+# Die Playwright-Tests laufen gegen eine EIGENE Wehr, nicht gegen die
+# Beispielwehr aus der Anleitung. Sonst wachsen deren Listen bei jedem Lauf,
+# und die Bildschirmfotos aendern sich, ohne dass sich die Oberflaeche
+# geaendert haette.
+#
+# Vor dem Lauf einmal:  npm run db:test-reset
+# -----------------------------------------------------------------------------
+E2E_SLUG=ff-teststelle
+E2E_NAME=Freiwillige Feuerwehr Teststelle
+E2E_KURZNAME=FF Teststelle
+E2E_ADMIN_EMAIL=e2e@teststelle.de
+E2E_ADMIN_PASSWORT=Feuerwehr2026

.gitea/workflows/pruefung.yml

@@ -0,0 +1,184 @@
+# =============================================================================
+# Die Pruefung bei jedem Push.
+#
+# Bis Phase 10 gab es 581 Unit- und 266 E2E-Tests — und nichts, was sie
+# ausfuehrte ausser einem Menschen, der daran dachte. In der Sitzung, in der
+# die Kassenverwaltung entstand, haben die Tests vier echte Fehler gefunden,
+# zwei davon in Code, der eine Stunde alt war. Genau das soll hier von allein
+# passieren.
+#
+# Zwei Auftraege, bewusst getrennt:
+#
+#   pruefung   typecheck, lint und die Unit-Tests. Braucht eine Datenbank,
+#              weil ein Teil der Tests die Trigger und RLS gegen echtes
+#              Postgres prueft — mit einer Attrappe waeren sie wertlos.
+#
+#   oberflaeche  die E2E-Tests. Dauern eine Dreiviertelstunde und brauchen den
+#                halben Stack, deshalb laufen sie nur auf main und in Pull
+#                Requests, nicht bei jedem Zwischenstand auf einem Zweig.
+# =============================================================================
+name: Pruefung
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+env:
+  # Dieselben Werte wie in .env.example. Es sind Testdaten in einem
+  # Wegwerf-Container; echte Geheimnisse haben in einer Pipeline nichts zu
+  # suchen und stehen im Betrieb in der .env.
+  POSTGRES_USER: florian
+  POSTGRES_PASSWORD: pruefung
+  POSTGRES_DB: florian
+  POSTGRES_APP_PASSWORD: pruefung_app
+  DATABASE_URL: postgresql://florian_app:pruefung_app@localhost:5432/florian?schema=public
+  DIRECT_DATABASE_URL: postgresql://florian:pruefung@localhost:5432/florian?schema=public
+  AUTH_SECRET: nur-fuer-die-pruefung-nicht-fuer-den-betrieb
+  AUTH_TRUST_HOST: "true"
+  APP_URL: http://localhost:3100
+  S3_ENDPOINT: localhost
+  S3_PORT: "9000"
+  S3_USE_SSL: "false"
+  S3_ACCESS_KEY: florian
+  S3_SECRET_KEY: pruefung_minio
+  S3_BUCKET: florian
+  REDIS_URL: redis://localhost:6379
+  TZ: Europe/Berlin
+
+jobs:
+  pruefung:
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 22
+          cache: npm
+
+      # Das eigene Postgres-Image statt eines fertigen: FLORIAN braucht
+      # PostGIS **und** pgvector, und kein oeffentliches Image bringt beides
+      # mit. Ein Dienst-Container mit postgres:17 wuerde die Migrationen
+      # durchlassen und erst bei der ersten Umkreissuche scheitern.
+      - name: Datenbank bauen und starten
+        run: |
+          docker build -t florian-postgres:pruefung ./docker/postgres
+          docker run -d --name postgres -p 5432:5432 \
+            -e POSTGRES_USER=$POSTGRES_USER \
+            -e POSTGRES_PASSWORD=$POSTGRES_PASSWORD \
+            -e POSTGRES_DB=$POSTGRES_DB \
+            -e POSTGRES_APP_PASSWORD=$POSTGRES_APP_PASSWORD \
+            -e POSTGRES_INITDB_ARGS="--locale-provider=icu --icu-locale=de-DE --locale=C.UTF-8 --encoding=UTF8" \
+            -v "$(pwd)/docker/postgres:/docker-entrypoint-initdb.d:ro" \
+            florian-postgres:pruefung
+
+      - name: Redis und MinIO starten
+        run: |
+          docker run -d --name redis -p 6379:6379 redis:7-alpine
+          docker run -d --name minio -p 9000:9000 \
+            -e MINIO_ROOT_USER=$S3_ACCESS_KEY \
+            -e MINIO_ROOT_PASSWORD=$S3_SECRET_KEY \
+            minio/minio:latest server /data
+
+      - run: npm ci
+
+      - name: Auf die Datenbank warten
+        run: |
+          for i in $(seq 1 60); do
+            docker exec postgres pg_isready -U "$POSTGRES_USER" -d "$POSTGRES_DB" && exit 0
+            sleep 2
+          done
+          echo "Postgres kam nicht hoch:"
+          docker logs postgres
+          exit 1
+
+      - run: npx prisma generate
+      - run: npm run typecheck
+      - run: npm run lint
+
+      - name: Migrationen einspielen
+        run: npm run db:migrate
+
+      # Der Seed gehoert dazu: er ist selbst ein Test. Faellt eine Migration
+      # oder ein Standardwert um, merkt man es hier und nicht erst, wenn eine
+      # Wehr ihn zum ersten Mal ausfuehrt.
+      - name: Beispielbestand anlegen
+        run: npm run db:seed
+
+      - run: npm run test
+
+      - name: Aufraeumen
+        if: always()
+        run: docker rm -f postgres redis minio || true
+
+  oberflaeche:
+    runs-on: ubuntu-latest
+    # Nur wo es sich lohnt: ein voller Lauf dauert etwa 45 Minuten.
+    if: github.event_name == 'pull_request' || github.ref == 'refs/heads/main'
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 22
+          cache: npm
+
+      - name: Dienste starten
+        run: |
+          docker build -t florian-postgres:pruefung ./docker/postgres
+          docker run -d --name postgres -p 5432:5432 \
+            -e POSTGRES_USER=$POSTGRES_USER \
+            -e POSTGRES_PASSWORD=$POSTGRES_PASSWORD \
+            -e POSTGRES_DB=$POSTGRES_DB \
+            -e POSTGRES_APP_PASSWORD=$POSTGRES_APP_PASSWORD \
+            -e POSTGRES_INITDB_ARGS="--locale-provider=icu --icu-locale=de-DE --locale=C.UTF-8 --encoding=UTF8" \
+            -v "$(pwd)/docker/postgres:/docker-entrypoint-initdb.d:ro" \
+            florian-postgres:pruefung
+          docker run -d --name redis -p 6379:6379 redis:7-alpine
+          docker run -d --name minio -p 9000:9000 \
+            -e MINIO_ROOT_USER=$S3_ACCESS_KEY \
+            -e MINIO_ROOT_PASSWORD=$S3_SECRET_KEY \
+            minio/minio:latest server /data
+          docker run -d --name gotenberg -p 3001:3000 gotenberg/gotenberg:8
+
+      - run: npm ci
+      - run: npx playwright install --with-deps chromium
+
+      - name: Auf die Datenbank warten
+        run: |
+          for i in $(seq 1 60); do
+            docker exec postgres pg_isready -U "$POSTGRES_USER" -d "$POSTGRES_DB" && exit 0
+            sleep 2
+          done
+          docker logs postgres
+          exit 1
+
+      - run: npx prisma generate
+      - run: npm run db:migrate
+
+      # Die E2E-Tests laufen seit Phase 8 gegen eine eigene Wehr, nicht gegen
+      # den Beispielbestand. Das Skript legt beide an.
+      - name: Testwehr anlegen
+        run: npm run db:test-reset
+
+      - run: npm run build
+      - run: npx playwright test
+        env:
+          GOTENBERG_URL: http://localhost:3001
+
+      - name: Fehlerbilder sichern
+        if: failure()
+        uses: actions/upload-artifact@v4
+        with:
+          name: playwright-bericht
+          path: |
+            playwright-report/
+            test-results/
+          retention-days: 7
+
+      - name: Aufraeumen
+        if: always()
+        run: docker rm -f postgres redis minio gotenberg || true

.gitignore

@@ -40,3 +40,6 @@ debug.log
 # Prisma
 prisma/*.db
 prisma/*.db-journal
+
+# Sicherungen bleiben lokal — sie enthalten den gesamten Bestand.
+sicherungen/

CHANGELOG.md

@@ -6,9 +6,616 @@ Alle nennenswerten Änderungen an FLORIAN. Format nach
 
 Die Regeln dazu stehen in [docs/VERSIONIERUNG.md](docs/VERSIONIERUNG.md).
 
-## [Unveröffentlicht]
+## [1.0.0] — 2026-09-06
 
-Nächster Schritt ist Phase 8 (Lokale KI).
+**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 —
+Personenauskunft nach Art. 15 DSGVO, ein geprüftes Sicherungskonzept und eine
+Pipeline, die die Tests von allein ausführt.
+
+**Das Auskunftsrecht war ein Versprechen ohne Umsetzung.** `person.export`
+stand seit Phase 0 im Berechtigungskatalog und war dem Kommandanten
+zugewiesen; implementiert war nichts. Die Löschseite gab es (Anonymisierung im
+Aufbewahrungslauf), die Auskunftsseite nicht — und ohne Art. 15 ist ein
+Löschkonzept nicht abnehmbar.
+
+**Eine Sicherung, die nie zurückgespielt wurde, ist eine Vermutung.** Genau
+das hat sich hier bestätigt: der erste Rückspielversuch lief scheinbar
+sauber durch und hatte dabei sämtliche Unveränderlichkeitsgarantien der
+Datenbank entfernt.
+
+### Hinzugefügt
+
+**Auskunft nach Art. 15 DSGVO**
+
+- `lib/dsgvo/auskunft.ts` sammelt alles, was über eine Person vorliegt:
+  Stammdaten, Zugang, Rollen, Qualifikationen, arbeitsmedizinische Vorsorge,
+  Belastungsübungen, Einsatz- und Übungsbeteiligung, Anwesenheiten, Fahrten,
+  Beiträge, Benachrichtigungswege, Ausweise. Dreizehn Abschnitte.
+- **Über jedem Abschnitt steht, wozu die Daten vorliegen.** Art. 15 Abs. 1
+  verlangt nicht nur die Daten, sondern auch Zwecke, Empfänger und den Hinweis
+  auf die weiteren Rechte. Eine Liste ohne das sieht aus wie eine Auskunft und
+  ist keine.
+- **Gesundheitsdaten sind als besondere Kategorie nach Art. 9 gekennzeichnet** —
+  G26 und Belastungsübungen.
+- **Leere Abschnitte bleiben stehen.** „Dazu liegt nichts vor" ist eine
+  Auskunft; ein weggelassener Abschnitt wirft die Frage auf, ob da doch etwas
+  ist.
+- **Was die Person getan hat, wird gezählt, nicht mitgeliefert.** Prüfprotokolle
+  und Mängelmeldungen gehören zum Nachweisbestand der Wehr. Vollständig
+  ausgeliefert käme jeder über eine Selbstauskunft an die Geräteakten — die
+  Auskunftspflicht wäre eine Hintertür.
+- Ein Durchgang liefert alles: die Anzeige, ein PDF für die Akte und JSON nach
+  Art. 20. Bewusst nicht drei Knöpfe, von denen zwei vergessen werden können.
+- Der Vorgang wird protokolliert. Dass eine Auskunft erteilt wurde, gehört
+  festgehalten — sie legt alles offen, was über einen Menschen gespeichert ist.
+
+**Sicherung und Wiederherstellung**
+
+- `npm run sicherung` — Datenbank über `pg_dump` im Container, dazu alle
+  Dateien aus MinIO, dazu ein Manifest. Beides aus demselben Moment: eine
+  Datenbank von heute mit Dateien von gestern ergibt Verweise ins Leere.
+- `npm run wiederherstellen` — mit Probelauf als Vorgabe. Ohne `--wirklich`
+  wird nur angezeigt, was geschähe.
+- Nach dem Zurückspielen setzt das Skript die Sperren der Anwendungsrolle neu
+  und **prüft danach nach**, ob es gewirkt hat.
+- `scripts/sicherung-sperren.ts` ist die eine Liste, aus der Wiederherstellen
+  und Prüfen entstehen. Ein Test gleicht sie gegen die migrierte Datenbank ab —
+  läuft sie auseinander, wäre der Schaden lautlos.
+
+**Pipeline**
+
+- `.gitea/workflows/pruefung.yml` mit zwei Aufträgen: `pruefung` (typecheck,
+  lint, Migrationen, Seed, 599 Unit-Tests) bei jedem Push, `oberflaeche`
+  (E2E) auf `main` und in Pull Requests.
+- Die Datenbank wird aus `docker/postgres` gebaut statt aus einem fertigen
+  Image: FLORIAN braucht PostGIS **und** pgvector. Ein Dienst-Container mit
+  `postgres:17` ließe die Migrationen durch und scheiterte erst bei der ersten
+  Umkreissuche.
+- Der Seed läuft mit, weil er selbst ein Test ist.
+
+### Behoben
+
+- **Eine Wiederherstellung entfernte alle Unveränderlichkeitsgarantien.** Der
+  Dump lief mit `--no-acl`, die Rechte kamen also nicht zurück; und selbst
+  ohne dieses Flag greift beim Zurückspielen die Vorgabeprivilegierung aus
+  `docker/postgres/10-init-app-role.sh` — jede von `pg_restore` neu angelegte
+  Tabelle bekommt automatisch alle Rechte, und `GRANT` kann nur hinzufügen,
+  nie wegnehmen. Nach einer Wiederherstellung durfte die Anwendungsrolle das
+  Audit-Log ändern, Wiki-Fassungen löschen und Kiosk-Vorgänge umschreiben.
+  Nichts hätte darauf hingewiesen.
+
+  Gefunden haben es vier Datenbanktests unmittelbar nach der ersten
+  Rückspielprobe — also genau die Probe, wegen der 1.0.0 sie verlangt.
+- **Ein E2E-Test klickte, bevor die Seite lebendig war.** Unter Last dauert das
+  Hydrieren länger; das Formular verschickte sich dann selbst, und die
+  Fehlerfläche, auf die der Test wartete, entstand nie — obwohl der Server
+  richtig ablehnte. Er wartet jetzt auf einen client-seitig erzeugten Knopf.
+
+### Nachweise
+
+- Sicherung und Wiederherstellung einmal vollständig durchgeführt: ein nach
+  der Sicherung angelegter Datensatz war danach weg, alle Zahlen stimmten
+  wieder, und **599 Tests liefen nach dem Zurückspielen grün** — einschließlich
+  derer, die die Sperren prüfen.
+
+---
+
+## [0.11.0] — 2026-09-05
+
+Phase 10: Mandantenfähigkeit. Ein Konto, mehrere Wehren, eine Kreisebene, die
+zusieht — und eine Verwaltung für den, der die Installation betreibt.
+
+**Das Anmeldekonto ist von der Personenakte gelöst.** Bis hierher war die Akte
+zugleich das Konto: Passwort-Hash und OIDC-Subject hingen an `person`, und
+`person` gehört genau einer Wehr. Ein Mensch konnte damit nicht zu zwei Wehren
+gehören, ohne zwei Passwörter zu haben — und die Anmeldung per E-Mail war
+mehrdeutig, sobald dieselbe Adresse in zwei Wehren stand, weil die
+Eindeutigkeit nur je Organisation galt.
+
+**Das Konto trägt keine Mandantenkennung — und kann keine tragen.** Es ist der
+Angelpunkt, an dem ein Mensch zu mehreren Wehren gehört. Geschützt wird es
+deshalb wie `Berechtigung` aus Phase 0: über Rechte statt über Row Level
+Security. Was ein Konto in einer Wehr darf, entscheidet nicht es selbst,
+sondern seine `Mitgliedschaft` — und die trägt `organisationId` wie jede
+andere Tabelle.
+
+**Die Kreisebene sieht und ändert nichts.** Ihre Rechte werden nicht
+aufgezählt, sondern gefiltert: alles, was `.lesen` heißt, und sonst nichts.
+Eine Liste von Hand wäre bei der nächsten Phase veraltet, und zwar unbemerkt.
+
+### Hinzugefügt
+
+**Datenmodell**
+
+- `Benutzer` — das Anmeldekonto. Global eindeutige E-Mail, ein Passwort, ein
+  OIDC-Subject. Ohne `organisationId`, mit Begründung im Schema.
+- `Mitgliedschaft` — die Zugehörigkeit eines Kontos zu einer Wehr, als
+  `MITGLIED` (mit Personenakte) oder `AUFSICHT` (ohne).
+- `Person` verliert die Anmeldefelder. Der Passwort-Hash kann damit aus einer
+  Personenabfrage gar nicht mehr herausfallen — die drei Stellen, die ihn
+  bisher vorsichtshalber abgeschnitten haben, sind entfallen.
+
+**Was die Datenbank durchsetzt** (Migrationen `20260905090000` und
+`20260905091500`)
+
+- RLS für `mitgliedschaft` wie für jede andere Tabelle. Eine Wehr sieht damit
+  auch nicht, in welchen anderen ein Konto noch geführt wird.
+- Trigger `mitgliedschaft_akte_gleiche_wehr` — eine Zuordnung, deren
+  Personenakte in einer anderen Wehr liegt, wird abgelehnt. Ein Fremdschlüssel
+  prüft nur, *dass* es die Akte gibt, nicht *wo* sie liegt; ohne den Trigger
+  ließe sich ein Konto über eine fremde Akte in eine Wehr hängen.
+- Trigger `benutzer_kennung_unveraenderlich` — E-Mail, OIDC-Subject und das
+  Verwaltermerkmal lassen sich nicht aus einer Wehr heraus ändern.
+- `REVOKE INSERT, DELETE ON benutzer` für die Anwendungsrolle.
+- CHECKs: `MITGLIED` braucht eine Akte, `AUFSICHT` darf keine haben; ein Konto
+  braucht einen Anmeldeweg; eine E-Mail ohne @ ist keine.
+
+**Die Umstellung ist datenerhaltend.** Jede Person mit Anmeldedaten bekommt
+ein Konto und eine Mitgliedschaft, bevor die alten Spalten fallen. Wer schon
+mit derselben Adresse in zwei Wehren stand, bekommt **ein** Konto mit **zwei**
+Mitgliedschaften — genau das, was vorher nicht möglich war. Eine Prüfung am
+Ende bricht die Migration ab, statt einen halben Zustand zu hinterlassen.
+
+**Oberfläche**
+
+- **Wehrwähler** in der Seitenleiste. Er erscheint nur bei mehr als einer Wehr
+  — ein Auswahlfeld mit genau einem Eintrag ist eine Frage ohne
+  Antwortmöglichkeit.
+- Nach der Anmeldung öffnet die **eigene** Wehr, nicht die betreute.
+- Ein dauerhafter Hinweis, wenn man eine Wehr als Kreisaufsicht sieht — nicht
+  als kurz aufblitzende Meldung.
+- **`/wehren`** für den Verwalter: Wehren anlegen (samt Systemrollen), Konten
+  führen, Zuordnungen vergeben und beenden. Jede Zuordnung wird in der
+  betroffenen Wehr protokolliert, nicht beim Verwalter — sonst hätte der
+  Betreiber einen Weg, sich still in fremde Daten zu setzen.
+
+**Rechte**
+
+- Neue Rolle `AUFSICHT` — bewusst **nicht** im Prisma-Enum: sie wird nicht
+  vergeben, sondern ergibt sich aus der Mitgliedschaftsart.
+- Ausdrücklich ausgenommen, obwohl sie auf `.lesen` enden: `kasse.lesen` (die
+  Kasse gehört dem Verein oder der Kommune, nicht der Kreisaufsicht),
+  `person.export`, `system.auditlog`, `ki.protokoll`.
+- `istVerwalter` als Merkmal des Kontos, nicht als Recht.
+
+**Tests**
+
+- 19 neue Unit-Tests, davon 11 gegen eine echte Datenbank: Doppelmitgliedschaft,
+  der Trigger gegen wehrfremde Akten, die CHECKs und die Trennung der
+  Zuordnungen über RLS.
+- 13 E2E-Tests: kein Wähler bei einer Wehr, Wechsel in die betreute und
+  zurück, die Mitglieder der anderen Wehr, die verschlossene Kasse, und dass
+  der Administrator die Umstellung überlebt hat.
+
+**Seed**
+
+- Eine zweite, kleine Wehr je Mandant und ein Konto, das in der einen Mitglied
+  und in der anderen Kreisaufsicht ist. Ohne sie ließe sich die Phase nicht
+  ausprobieren — und eine Mandantentrennung, die nie zwei Mandanten hatte, ist
+  keine geprüfte.
+
+### Geändert
+
+- Eine Sitzung ohne Personenakte ist gültig. Bis hierher galt genau das als
+  „nicht angemeldet"; für die Kreisaufsicht, die in der betreuten Wehr keine
+  Akte hat, hätte jeder Aufruf auf der Anmeldeseite geendet.
+- `Sitzung.personId` ist nullbar. Der Typechecker hat damit die fünf Stellen
+  gezeigt, an denen eine Aufsichtssitzung nichts verloren hat — Anmeldemarke,
+  Dienstausweis, Prüfungswizard, Dateiupload, Atemschutz.
+- Die Mitgliederansicht zeigt statt eines ungenutzten Zeitstempels, ob jemand
+  überhaupt ein Konto hat. Das ist die nützlichere Auskunft: ohne Konto kommt
+  er nicht in FLORIAN hinein.
+
+### Behoben
+
+- **Ein Testaufbau war nicht wiederholbar.** `ki-datenbank.test.ts` legte Wehr
+  und Person idempotent an, die Wiki-Seite aber nicht — blieb aus einem
+  abgebrochenen Lauf etwas stehen, scheiterte der ganze Datei-Lauf an einer
+  Eindeutigkeit, die mit dem Geprüften nichts zu tun hat.
+- **`db:test-reset` ließ die Nachbarwehr stehen** und der Seed hielt daraufhin
+  alles für erledigt — die Mitgliedschaft in der neu angelegten Testwehr
+  entstand nie wieder. Der Reset nimmt sie jetzt mit, und der Seed prüft
+  Nachbarwehr und Kreiskonto getrennt statt mit einem gemeinsamen Ausstieg.
+- **Der Fehlversuch-Test sperrte das gemeinsame Testkonto.** Fünf Fehlversuche
+  sperren ein Konto für fünf Minuten; bei zwei Projekten und Wiederholungen
+  kam das im vollen Lauf zusammen, und fremde Testdateien fielen mit
+  „Anmeldung fehlgeschlagen“ aus. Er nimmt jetzt eine Adresse, die es nicht
+  gibt — die Meldung muss ohnehin dieselbe sein.
+
+---
+
+## [0.10.0] — 2026-09-04
+
+Phase 9: Kassenverwaltung. Kassenbuch, Mitgliedsbeiträge, Rechnungen an
+Dritte, Kassenprüfung und die Auswertungen für die Jahreshauptversammlung.
+
+**Eine festgeschriebene Buchung ist unveränderbar.** Nicht, weil ein Zweig im
+Router es so vorsieht, sondern weil die Datenbank es ablehnt. Korrigiert wird
+über eine Gegenbuchung mit Verweis; beide Buchungen bleiben stehen, und im
+Kassenbuch ist zu sehen, dass etwas berichtigt wurde. Genau das will ein
+Kassenprüfer sehen — eine verschwundene Buchung dagegen kann er nicht prüfen.
+
+**Der Kassenabschluss schließt seinen Zeitraum.** Danach wird keine Buchung
+mit einem Datum darin mehr angenommen, auch keine nachträglich hineindatierte.
+Ohne diese zweite Hälfte stimmte der geprüfte Bestand nach einem
+Datumswechsel nicht mehr — und niemand hätte es bemerkt.
+
+**Gerechnet wird mit `Prisma.Decimal`, nirgends mit Fließkomma.** `0.1 + 0.2`
+ergibt in JavaScript 0.30000000000000004. In einer Kasse ist das kein
+Rundungsfehler, sondern eine Differenz in der Prüfung, die niemand erklären
+kann.
+
+### Hinzugefügt
+
+**Datenmodell**
+
+- `Kassenkonto` (bar, Bank, Rücklage) mit Anfangsbestand. Der laufende Bestand
+  wird **gerechnet und nie gespeichert**: ein gespeicherter Bestand neben
+  einer nachgetragenen Buchung wäre falsch, ohne falsch auszusehen.
+- `Buchungskategorie` als zweistufiger Baum, mit Kontonummer für den Export an
+  die Kämmerei.
+- `Buchung` mit Datum, Richtung, immer positivem Betrag, Verwendungszweck,
+  Belegnummer, Beleg-Datei und dem Verweis auf die Gegenbuchung.
+- `Beitragssatz` und `Beitrag` (offen, bezahlt, erlassen, gemahnt) mit
+  Mahnstufe und Erlassbegründung.
+- `Rechnung` und `Rechnungsposition` mit Nummernkreis je Jahr. Die Menge hat
+  drei Nachkommastellen — Einsatzstunden werden viertelstündlich abgerechnet.
+- `Kassenabschluss` und `Abschlussposten` mit Bestand laut Buch, gezähltem
+  Bestand, Differenz, zwei Prüfern und dem Bericht als PDF.
+
+**Was die Datenbank durchsetzt** (Migration `20260904140000`)
+
+- RLS für alle neun Tabellen, wie in jeder Phase zuvor.
+- Trigger `buchung_unveraenderlich` — festgeschriebene Buchungen lassen sich
+  weder ändern noch löschen. Änderbar bleibt genau eines: der Verweis auf die
+  Gegenbuchung. Eine Stornierung entsteht später; sie einzutragen ist keine
+  Änderung des Vorgangs, sondern seine Fortschreibung.
+- Trigger `buchung_zeitraum_offen` — ein geprüfter Zeitraum nimmt weder eine
+  neue Buchung an noch das Hineindatieren einer vorhandenen.
+- Trigger `abschluss_unveraenderlich` — ein festgeschriebener Abschluss bleibt,
+  wie er ist. Nachtragen lässt sich nur der Prüfbericht, denn das PDF entsteht
+  im Hintergrund und damit nach dem Festschreiben.
+- `REVOKE DELETE ON kassenabschluss` für die Anwendung.
+- CHECKs, die verhindern, was sich hinterher nicht mehr erkennen ließe: ein
+  Betrag von null oder darunter, eine Buchung an eine Person **und** einen
+  Dritten zugleich, ein erlassener Beitrag ohne Begründung, ein Abschluss mit
+  einer Differenz, die nicht zu seinen eigenen Zahlen passt, eine Rechnung,
+  die fällig wird, bevor sie geschrieben wurde.
+
+**Kassenbuch**
+
+- Buchungsmaske mit **Kategorievorschlag**: zuerst aus den eigenen früheren
+  Buchungen der Wehr, erst danach aus einer kurzen Stichwortliste. Unter der
+  Hälfte gemeinsamer Wörter schweigt der Vorschlag — ein falscher wird
+  übernommen, ohne gelesen zu werden.
+- Summen über **alle** Treffer, nicht nur über die angezeigte Seite.
+- Festschreiben als Sammelaktion bis zu einem Stichtag.
+- Gegenbuchen mit Pflichtbegründung; das Buchungsdatum ist immer heute, damit
+  ein geprüfter Zeitraum zubleibt.
+- **Aus einem gegengezeichneten Beleg wird eine Buchung.** Die Brücke zu
+  Phase 8: fotografiert und ausgefüllt wird am Terminal oder am Handy,
+  gebucht wird in der Kasse — mit Konto und Kategorie, die keine Maschine
+  entscheiden kann. Das Foto hängt danach an der Buchung, und genau das
+  verlangt eine Kassenprüfung: zu jeder Ausgabe ein Beleg, an der Buchung
+  und nicht in einem Ordner daneben. Ein Entwurf lässt sich nicht buchen.
+
+**Kontoauszug einlesen**
+
+- CAMT.053 und MT940, beides ohne zusätzliche Abhängigkeit. Erkannt wird am
+  Inhalt, nicht an der Dateiendung.
+- Es entstehen **Entwürfe, keine fertigen Buchungen**.
+- Jeder Umsatz trägt eine Kennung — die der Bank, sonst eine aus Datum, Betrag
+  und Zweck gebildete. Ein zweimal eingelesener Auszug wird dadurch als solcher
+  erkannt, statt einen Monat doppelt zu buchen.
+- Was nicht gelesen werden konnte, steht mit Grund daneben, statt still zu
+  verschwinden.
+
+**Beiträge**
+
+- Sätze je Abteilung, gültig ab einem Jahr und nicht rückwirkend änderbar.
+- Beitragslauf mit **Vorschau**: wie viele Beiträge entstehen, welche Summe —
+  und wer keinen passenden Satz hat. Der Lauf ist wiederholbar, ohne dass
+  etwas doppelt entsteht.
+- Zahlungseingang erzeugt zugleich die Buchung. Ein Häkchen ohne Geld in der
+  Kasse wäre eine Behauptung.
+- Mahnen als Sammelaktion, Erlassen nur mit Begründung.
+- Rückstandsliste über alle Jahre — die Ansicht, in der auffällt, wer seit
+  drei Jahren offen steht.
+
+**Rechnungen**
+
+- Fortlaufende Nummer je Jahr, lückenlos: eine fehlende Nummer muss in der
+  Kassenprüfung erklärt werden.
+- Der Betrag ist die Summe der Positionen, gerechnet und nicht eingegeben.
+- Bis zum Versenden ein Entwurf, danach unveränderbar. Korrigiert wird über
+  Storno und eine neue Rechnung — die stornierte bleibt mit Grund stehen.
+- PDF über Gotenberg, im Hintergrund erzeugt.
+
+**Kassenprüfung und Auswertung**
+
+- Prüfmaske: links der Bestand laut Buch, rechts der gezählte. In dieser
+  Reihenfolge — wer erst das Buch sieht und dann zählt, zählt, bis es passt.
+- Ohne Prüfer und Prüfdatum lässt sich nichts festschreiben; eine Differenz
+  ohne Erläuterung ebenso wenig.
+- Kassenprüfbericht als PDF mit vier Unterschriftsfeldern.
+- Jahresauswertung nach Kategorie und Monat, mit Vorjahresvergleich.
+- CSV-Export mit Semikolon und BOM — was Excel in Deutschland ohne Rückfrage
+  richtig öffnet.
+
+**Tests**
+
+- 67 neue Unit-Tests: Geldrechnen, beide Auszugsformate, Kategorievorschlag,
+  und dreizehn gegen eine echte Datenbank, die die Trigger und CHECKs prüfen.
+  Sie laufen über den Systemzugang: kommt nicht einmal der Eigentümer der
+  Datenbank daran vorbei, kommt niemand vorbei.
+- 13 E2E-Tests über Desktop und Tablet.
+
+**Seed**
+
+- Ein vollständiges Kassenjahr: drei Konten, der Standardkontenrahmen,
+  24 Buchungen über zwei Jahre, die Mitgliedsbeiträge mit Rückständen, zwei
+  Rechnungen und die festgeschriebene Kassenprüfung des Vorjahres. Die Zahlen
+  des Abschlusses sind die Summe der Buchungen und nicht erfunden.
+
+### Geändert
+
+- Ein E2E-Test aus Phase 0 sicherte zu, dass die Kasse in der Navigation
+  **kein** Verweis ist — sie war ja noch nicht da. Die Zusicherung ist mit
+  dieser Phase abgelaufen und prüft jetzt das Gegenteil. Ein künftiges Modul
+  zum Ausgrauen gibt es nicht mehr; kommt später eines dazu, gehört sie
+  zurück.
+
+### Behoben
+
+- **Die Rechnungsnummer war ein Wettlauf.** Höchste lesen und dann schreiben:
+  schreiben zwei Leute gleichzeitig eine Rechnung, lesen beide dieselbe
+  höchste Nummer, und die zweite läuft in den Eindeutigkeitsfehler. Gefunden
+  hat das der parallele E2E-Lauf. Der seltene Zusammenstoß wird jetzt erkannt
+  und die nächste Nummer genommen — lückenlos bleibt sie dabei.
+- **Eine Organisation ließ sich nicht mehr löschen**, sobald sie eine
+  festgeschriebene Buchung hatte: der Trigger lehnte auch das Löschen im
+  Aufbewahrungslauf ab. Er kennt jetzt denselben Schalter wie das Audit-Log
+  und das Prüfprotokoll (`app.audit_bereinigung`). Ohne ihn wäre die
+  DSGVO-Löschung einer ausscheidenden Wehr nicht durchführbar gewesen.
+
+---
+
+## [0.9.1] — 2026-09-04
+
+Aufräumarbeiten vor Phase 9. Drei Punkte, die sich über mehrere Phasen
+angesammelt hatten und in jeder Phase Zeit gekostet haben.
+
+
+### Hinzugefügt
+
+- **ESLint** hat endlich eine Konfiguration (`eslint.config.mjs`, Flat Config).
+  Bis dahin gab es das Skript `npm run lint`, aber nichts, was es hätte prüfen
+  können — ein Werkzeug, das aussieht, als prüfe es etwas, und nichts prüft,
+  ist schlechter als gar keines. Bewusst **ohne** Formatierungsregeln: die
+  macht Prettier. Dazu `npm run lint:fix`.
+- **Eine eigene Wehr für die E2E-Tests.** `npm run db:test-reset` legt
+  `ff-teststelle` neu an — vollständig, mit denselben Beispieldaten, aber unter
+  eigener Kennung. Ein Riegel im Skript bricht ab, wenn die Testkennung mit der
+  der Beispielwehr übereinstimmt.
+- `tests/e2e/wehr.ts` — Zugangsdaten und Anmeldung an einer Stelle statt
+  achtmal wortgleich in acht Dateien. Schlägt die Anmeldung fehl, sagt die
+  Meldung, dass die Testwehr fehlt, statt zweihundertmal „Timeout".
+
+### Behoben
+
+- **Die E2E-Tests schrieben in die Beispielwehr.** Nach fünf Phasen standen
+  dort 120 Atemschutz-Überwachungen statt einer, 115 Geräte statt 45 und
+  39 Einsätze statt 8. Zweimal fielen Tests aus, weil ein gesuchter Eintrag von
+  Seite 1 gerutscht war; bei jedem Lauf unterschieden sich alle 72
+  Bildschirmfotos. Der Bestand ist einmal zurückgesetzt, die Tests laufen
+  jetzt gegen die eigene Wehr.
+- **`<div>` in einem `<p>` auf der Einsatzseite** — die Meldung stand seit
+  Phase 3 in der Konsole und ist der klassische Auslöser für einen
+  Hydration-Fehler. Die Wurzel war das `Badge`: es rendert jetzt ein `<span>`
+  statt eines `<div>`. Ein Abzeichen ist Fließtext-Inhalt, und die Darstellung
+  ändert sich dadurch nicht.
+- **Die Fehlerfläche der Karte konnte nie etwas anzeigen** — der Zustand
+  dahinter wurde nirgends gesetzt. Eine gescheiterte Abfrage sah damit aus wie
+  „keine Hydranten vorhanden". Gefunden hat das der neue Linter.
+- **Die Lagekarte rechnete bei jedem Rendern neu.** Ein `?? []` erzeugte jedes
+  Mal ein neues leeres Feld und machte damit zwei `useMemo` wirkungslos — bei
+  einer Karte mit dreißig Elementen und einem Ereignisstrom im Zwei-Sekunden-
+  Takt kein akademischer Punkt.
+- Deutsche Anführungszeichen in vier Ansichten schlossen mit einem geraden
+  Zoll-Zeichen statt mit dem typografischen.
+- Unbenutzte Importe in fünf Dateien.
+
+### Geändert
+
+- `npm run lint` ruft jetzt `eslint .` statt des in Next 15.5 abgekündigten
+  `next lint`.
+- **`tests/e2e` ist nicht mehr vom Typecheck ausgenommen.** Die Ausnahme hat
+  beim Umbau einen doppelt deklarierten Bezeichner durchgelassen, den erst der
+  Testlauf gemeldet hat — `npx tsc --noEmit` hatte geschwiegen.
+
+---
+
+## [0.9.0] — 2026-09-04
+
+Phase 8: Lokale KI. Ein Wiki mit semantischer Suche, Diktat, Berichtsassistent
+und Belegerfassung — alles gegen selbst betriebene Modelle.
+
+**Nichts, was ein Modell erzeugt, gelangt ungeprüft in einen Nachweis.** Jede
+KI-Ausgabe ist zuerst ein eigener Datensatz und nicht ein Feld im
+Zieldokument. Sie ist gekennzeichnet, sie steht daneben statt mittendrin, und
+sie braucht zwei gleich große Knöpfe, bevor etwas mit ihr geschieht.
+
+**Es läuft alles im Haus.** Ollama und faster-whisper als Container daneben,
+kein Anbieter, kein Schlüssel. Es gibt keinen Rückfall auf einen Cloud-Dienst:
+fehlen die Container, fehlt die Funktion.
+
+### Hinzugefügt
+
+**Datenmodell**
+
+- `KiVorgang` — jede Befragung eines Modells mit Eingabe, Ausgabe, Modell,
+  Dauer und der Entscheidung darüber. Auch Fehlschläge: ein Modell, das
+  dreimal am Tag in eine Zeitüberschreitung läuft, ist eine Information.
+- `Wikiseite`, `Wikiabschnitt` (mit `vector(768)`) und `Wikiversion`.
+- `Diktat` mit Aufnahme in MinIO, `Belegentwurf` mit allen Feldern optional —
+  ein Modell, das den Betrag nicht findet, soll nichts erfinden.
+
+**Postgres mit pgvector**
+
+- Eigenes Image (`docker/postgres/Dockerfile`), weil FLORIAN PostGIS **und**
+  pgvector braucht und es kein offizielles Image mit beidem gibt.
+- HNSW-Index statt IVFFlat: IVFFlat muss auf gefülltem Bestand trainiert
+  werden, HNSW ist ab der ersten Zeile brauchbar. Ein Wiki wächst Seite für
+  Seite — es gibt nie den Moment, an dem man den Index einmal aufbaut.
+
+**Wiki**
+
+- Markdown, selbst gerendert **ohne HTML**: der Text kommt von Anwendern, und
+  jeder Weg über `dangerouslySetInnerHTML` wäre ein Weg für ein `<script>` in
+  einer Dienstvorschrift.
+- Zwei Suchen: Wortsuche (immer, mit Textstelle) und Frage ans Modell
+  (semantisch, mit Fundstellen). Steht die Antwort nicht in den Unterlagen,
+  sagt FLORIAN das — ohne passende Auszüge wird gar nicht erst gefragt.
+- Zerlegt wird an den Überschriften, mit der Überschriftenkette im
+  Einbettungstext: ein Abschnitt über „Rückzugsdruck" ohne das Wort
+  „Atemschutz" darüber findet sich sonst nicht.
+- Jede Änderung schreibt die vorherige Fassung weg.
+
+**Diktat, Bericht, Beleg**
+
+- Aufnahme im Browser, Erkennung über faster-whisper im Hintergrund. Die
+  Aufnahme bleibt, solange nicht entschieden ist — sie ist das einzige
+  Original.
+- Berichtsentwurf aus Stichpunkten. Zeitstempel und Einsatznummer bekommt das
+  Modell **nicht**: sie stehen schon als Felder im Bericht.
+- Belegerfassung mit Vision-Modell. Nicht erkannte Felder bleiben leer und
+  gelb hinterlegt statt geraten zu werden.
+
+**Zwei Protokolle**
+
+- `/ki-protokoll` — was die Maschine getan hat, mit Kennzahlen und
+  aufklappbarer Eingabe/Ausgabe.
+- `/protokoll` — das Audit-Log. Wird seit Phase 0 geschrieben; die Ansicht
+  dazu kam jetzt, weil beides nebeneinander gehört: was hat ein Mensch getan,
+  was die Maschine.
+
+### Geändert
+
+- `lib/integrations/llm.ts` kann jetzt drei Dinge statt einem: Text,
+  Einbettungen und Bilder — mit je eigenem Modell, weil ein Rechner ohne
+  Grafikkarte das Einbettungsmodell noch schafft und das Vision-Modell nicht.
+- Der Datei-Upload nimmt Tonaufnahmen an (webm, ogg, mp4, wav).
+- Neue Rechte: `wiki.lesen` als Grundrecht (eine Wehr, in der nur die Führung
+  nachschlagen darf, hat kein Wiki, sondern einen Aktenschrank),
+  `wiki.bearbeiten`, `ki.nutzen`, `ki.protokoll`, `beleg.erfassen`.
+- Der Aufbewahrungslauf zieht nebenbei Wiki-Seiten nach, deren Suchstand
+  veraltet ist.
+
+### Behoben
+
+- Beim Zerlegen einer Wiki-Seite wurde ein kurzer Abschnitt an den vorherigen
+  gehängt, auch wenn er unter einer anderen Überschrift stand. Unter einer
+  Antwort hätte dann eine Fundstelle gestanden, in der der zitierte Satz gar
+  nicht vorkommt. Gefunden hat es der Test, nicht das Ausprobieren.
+
+### Sicherheit
+
+- Row Level Security für die sechs neuen Tabellen — auch für die Vektorsuche:
+  ein perfekt passender Abschnitt einer fremden Wehr taucht nicht auf.
+- Eingabe, Ausgabe, Modell und Art eines KI-Vorgangs sind nach dem Anlegen
+  unveränderlich (Trigger). Über einen Vorschlag wird genau einmal
+  entschieden. `REVOKE DELETE ON "ki_vorgang"`.
+- `REVOKE UPDATE, DELETE ON "wikiversion"`: eine Dienstvorschrift, deren
+  Vorgeschichte sich bereinigen lässt, ist als Nachweis wertlos.
+- Prüfbedingungen: keine Entscheidung ohne Zeitpunkt, kein Fehlschlag ohne
+  Grund, kein negativer Betrag auf einer Quittung.
+
+### Tests
+
+- 73 neue Unit-Tests: Zerlegen einer Seite (Überschriftenketten, Codeblöcke,
+  Teilung an Absatzgrenzen), Auswerten einer Modellantwort auf ein Belegfoto
+  (deutsche Zahlen, Tausenderpunkt, unmögliche Daten), die Anweisungen an das
+  Modell und die Datenbankregeln samt Vektorsuche über Mandanten hinweg.
+- 14 neue E2E-Tests, die **ohne laufendes Modell** prüfen, dass alles andere
+  vollständig benutzbar bleibt und ehrlich sagt, was fehlt.
 
 ---
 

README.md

@@ -1,8 +1,14 @@
 # FLORIAN — Feuerwehr-Verwaltungsplattform
 
+**Version 1.0.0** — freigegeben für den Echtbetrieb.
+
 Selbstgehostete Verwaltungssoftware für Freiwillige Feuerwehren. Läuft im
 Gerätehaus, nicht in der Cloud. Keine Telemetrie, keine externen CDNs.
 
+> **Wer FLORIAN benutzen und nicht bauen will:**
+> [**Kurzanleitung**](docs/KURZANLEITUNG.md) — alles Wichtige nach Rollen
+> sortiert, auf ein paar Seiten.
+
 ## Schnellstart
 
 ```bash
@@ -31,8 +37,10 @@ Anmelden mit `SEED_ADMIN_EMAIL` und `SEED_ADMIN_PASSWORT` aus der `.env`
 | Phase 5 — Atemschutz (FwDV 7) | fertig |
 | Phase 6 — Kartenmodule | fertig |
 | Phase 7 — Benachrichtigungen und Termine | fertig |
-| Phase 8 — Lokale KI | offen |
-| Phase 9 — Kassenverwaltung | offen |
+| Phase 8 — Lokale KI | fertig |
+| Phase 9 — Kassenverwaltung | fertig |
+| Phase 10 — Mandantenfähigkeit | fertig |
+| Phase 11 — Freigabereife | fertig |
 
 Vollständige Planung mit Aufwänden: [docs/ROADMAP.md](docs/ROADMAP.md) und
 [docs/AUFWANDSSCHAETZUNG.md](docs/AUFWANDSSCHAETZUNG.md).
@@ -41,7 +49,8 @@ Vollständige Planung mit Aufwänden: [docs/ROADMAP.md](docs/ROADMAP.md) und
 
 | Datei | Inhalt |
 |---|---|
-| [docs/ANLEITUNG.md](docs/ANLEITUNG.md) | Bedienung mit Bildschirmfotos |
+| [docs/KURZANLEITUNG.md](docs/KURZANLEITUNG.md) | **Der Einstieg.** Nach Rollen sortiert, ein paar Seiten |
+| [docs/ANLEITUNG.md](docs/ANLEITUNG.md) | Die vollständige Bedienung mit Bildschirmfotos, zum Nachschlagen |
 | [docs/ROADMAP.md](docs/ROADMAP.md) | Phasenplan und was jeweils entsteht |
 | [docs/AUFWANDSSCHAETZUNG.md](docs/AUFWANDSSCHAETZUNG.md) | Aufwand je Phase, Schätzung gegen Ist |
 | [docs/DEVLOG.md](docs/DEVLOG.md) | Entwicklungstagebuch mit Zeiterfassung |
@@ -973,22 +982,653 @@ Meldungen bleiben einfach aus. Beide Schlüssel gehören deshalb ins Backup.
 
 ---
 
+## Phase 8 — Lokale KI
+
+Ein Satz bestimmt alles, was hier gebaut wurde:
+
+> **Nichts, was ein Modell erzeugt, gelangt ungeprüft in einen Nachweis.**
+
+Daraus folgt der Aufbau: jede KI-Ausgabe ist zuerst ein eigener Datensatz und
+nicht ein Feld im Zieldokument. Ein Einsatzbericht bekommt seinen Text erst,
+wenn ein Mensch „übernehmen" gedrückt hat — bis dahin liegt der Entwurf daneben
+und ist als Entwurf erkennbar, mit gestricheltem Rahmen und dem Modellnamen
+darüber. Das ist der Unterschied zwischen einer Hilfe und einer Fälschung.
+
+Der zweite Grundsatz: **es läuft alles im Haus.** Ollama und faster-whisper als
+Container daneben, kein Anbieter, kein Schlüssel, keine Zeile Text, die das
+Gerätehaus verlässt. Es gibt **keinen Rückfall** auf einen Cloud-Dienst: fehlen
+die Container, fehlt die Funktion. Das ist die einzige Bauart, bei der der Satz
+„die Daten bleiben im Haus" auch dann noch stimmt, wenn der eigene Server aus
+ist.
+
+### Ohne Modelle geht alles andere weiter
+
+Die wichtigste Eigenschaft der Phase, und die am meisten Arbeit gemacht hat:
+**FLORIAN bleibt ohne Sprachmodell vollständig benutzbar.** Wiki lesen und
+schreiben, Wortsuche, Belege ablegen und von Hand ausfüllen, beide Protokolle —
+alles läuft. Wo etwas fehlt, steht ein Satz, der sagt *was* fehlt und *wie es
+ohne geht*, statt eines kaputten Knopfes.
+
+Das ist kein Zugeständnis, sondern der Normalfall: eine Wehr setzt FLORIAN auf,
+lange bevor sie über eine Grafikkarte nachdenkt.
+
+### Das Wiki
+
+Dienstvorschriften, Ausbildungsunterlagen, Merkblätter — das, was sonst als PDF
+im Ordner steht und im Einsatz niemand findet. Inhalt ist **Markdown**, weil es
+sich ohne Werkzeug lesen lässt, auch in zwanzig Jahren, auch ohne FLORIAN.
+
+**Zwei Suchen nebeneinander**, und beide werden gebraucht:
+
+| Suche | Findet | Braucht ein Modell |
+|---|---|---|
+| **Wortsuche** | was dasteht — „FwDV 7" findet die Seite mit dieser Zeichenfolge | nein |
+| **Frage** | was gemeint ist — „wie lange hält ein Schlauch" findet den Abschnitt über Ablegereife | ja |
+
+Die Frage wird **ausschließlich aus den eigenen Seiten** beantwortet, mit
+Fundstellen darunter. Steht die Antwort nicht drin, sagt FLORIAN genau das. Ein
+Modell, das auf die Frage nach der Prüffrist von Steckleitern eine Zahl nennt,
+die nirgends steht, wäre gefährlicher als gar keine Antwort — deshalb wird ohne
+passende Auszüge gar nicht erst gefragt.
+
+Zerlegt wird an den **Überschriften**, nicht nach Zeichenzahl: eine Fundstelle
+soll ein Kapitel sein, kein aus der Mitte gerissener Absatz. Und ein kurzer
+Abschnitt wird nie unter eine fremde Überschrift gehängt — sonst zitierte die
+Antwort eine Fundstelle, in der der Satz gar nicht steht.
+
+Jede Änderung schreibt die vorherige Fassung weg. Eine Dienstvorschrift, die
+sich unbemerkt ändert, ist schlimmer als keine.
+
+### Diktat
+
+Der Weg, den es in jeder Wehr schon gibt: der Einsatzleiter spricht auf der
+Rückfahrt in sein Telefon, und daraus wird abends ein Bericht. Neu ist nur, dass
+abends schon ein Text dasteht.
+
+Ein Knopf, keine Einstellungen. Die Aufnahme bleibt abgelegt, solange über den
+Text nicht entschieden ist — wer dem Transkript nicht traut, hört nach. Und das
+Modell darf **nichts verbessern**: „Hohlstrahlrohr" bleibt „Hohlstrahlrohr",
+auch wenn es das Wort nicht kennt.
+
+### Berichtsassistent
+
+Stichpunkte hinein, Entwurf heraus. Was das Modell **nicht** bekommt, ist ebenso
+wichtig: Zeitstempel und Einsatznummer stehen schon als Felder im Bericht und
+stünden sonst zweimal da, beim zweiten Mal womöglich falsch.
+
+Der Entwurf landet nicht im Berichtsfeld. Er steht daneben, gekennzeichnet, mit
+zwei gleich großen Knöpfen — „Übernehmen" ist nicht der Standardweg und sieht
+auch nicht so aus.
+
+### Belegerfassung
+
+Quittung fotografieren, Angaben prüfen, gegenzeichnen. Alle Felder sind
+änderbar, und was das Modell nicht erkannt hat, bleibt **leer und gelb
+hinterlegt** statt geraten zu werden. Ein leeres Feld ist eine Aufforderung; ein
+geratener Betrag ist eine falsche Buchung, die niemand bemerkt.
+
+Die Buchung daraus kommt mit der Kasse in Phase 9 — hier entsteht erst einmal
+ein sauber erfasster Beleg mit Foto.
+
+### Zwei Protokolle nebeneinander
+
+| Ansicht | Beantwortet |
+|---|---|
+| **KI-Protokoll** | Was hat die Maschine getan? Jede Befragung, jedes Modell, jede Entscheidung mit Namen und Zeitpunkt. |
+| **Protokoll** (Audit-Log) | Was haben Menschen getan? Wird seit Phase 0 geschrieben; die Ansicht dazu kam jetzt. |
+
+Eingabe, Ausgabe, Modell und Art eines KI-Vorgangs sind nach dem Anlegen
+**unveränderlich** — ein Trigger hält dagegen. Löschen ist der Anwendungsrolle
+entzogen, und über einen Vorschlag wird genau einmal entschieden. Ohne das
+ließe sich in einem Jahr nicht mehr sagen, welcher Satz in einem Einsatzbericht
+von einem Menschen stammt.
+
+### Einrichtung
+
+Postgres braucht seit dieser Phase **pgvector** neben PostGIS. Es gibt kein
+offizielles Image mit beidem, deshalb baut FLORIAN eines
+(`docker/postgres/Dockerfile`):
+
+```bash
+docker compose build postgres        # bei einer bestehenden Installation
+docker compose up -d postgres        # Datenverzeichnis bleibt unberührt
+npm run db:migrate
+```
+
+Dann die Modelle:
+
+```bash
+docker compose --profile ki up -d
+
+docker compose exec ollama ollama pull qwen2.5:14b       # Text
+docker compose exec ollama ollama pull nomic-embed-text  # Einbettungen
+docker compose exec ollama ollama pull llama3.2-vision   # Belege (optional)
+```
+
+Auf einem Rechner ohne Grafikkarte läuft das Einbettungsmodell noch flott, das
+Textmodell zäh und das Vision-Modell praktisch nicht. Deshalb sind alle drei
+einzeln konfigurierbar: eine Wehr kann das Wiki durchsuchbar machen, ohne
+Berichte schreiben zu lassen.
+
+Für eine Nvidia-Karte in die `docker-compose.override.yml`:
+
+```yaml
+services:
+  ollama:
+    deploy:
+      resources:
+        reservations:
+          devices:
+            - driver: nvidia
+              count: all
+              capabilities: [gpu]
+```
+
+### Ein anderes Einbettungsmodell
+
+Die Spalte `wikiabschnitt.einbettung` ist auf **768 Dimensionen** festgelegt —
+das liefert `nomic-embed-text`. Ein Modell mit anderer Länge braucht eine
+Migration:
+
+```sql
+ALTER TABLE "wikiabschnitt" DROP COLUMN "einbettung";
+ALTER TABLE "wikiabschnitt" ADD COLUMN "einbettung" vector(1024);
+CREATE INDEX "wikiabschnitt_einbettung_idx"
+    ON "wikiabschnitt" USING hnsw ("einbettung" vector_cosine_ops);
+```
+
+Danach `LLM_EINBETTUNG_DIMENSIONEN` anpassen und alle Seiten neu einbetten. Der
+nächtliche Lauf holt das von selbst nach; wer nicht warten will, drückt auf
+jeder Seite „jetzt nachziehen".
+
+Ohne Anpassung weist FLORIAN das Modell mit einer klaren Meldung ab, statt eine
+Fehlermeldung der Datenbank durchzureichen, die niemand versteht.
+
+### Zusätzliche Umgebungsvariablen
+
+| Variable | Vorgabe | Bedeutung |
+|---|---|---|
+| `LLM_ENABLED` | `false` | Schaltet alle Textfunktionen ein |
+| `LLM_BASE_URL` | — | OpenAI-kompatibler Endpunkt, z. B. `http://ollama:11434/v1` |
+| `LLM_MODELL` | — | Modell für Berichte und Antworten |
+| `LLM_TIMEOUT` | `120` | Zeitlimit in Sekunden |
+| `LLM_EINBETTUNG_MODELL` | `nomic-embed-text` | Modell für die semantische Suche |
+| `LLM_EINBETTUNG_DIMENSIONEN` | `768` | **Muss zur Spalte passen** |
+| `LLM_VISION_MODELL` | — | Modell für die Belegerfassung |
+| `WHISPER_ENABLED` | `false` | Schaltet das Diktat ein |
+| `WHISPER_URL` | — | z. B. `http://whisper:8000` |
+| `WHISPER_MODELL` | `base` | `tiny`, `base`, `small` |
+| `DIKTAT_MAX_SEKUNDEN` | `600` | Höchstlänge einer Aufnahme |
+| `OLLAMA_PORT` | `11435` | Port des Ollama-Containers (Profil `ki`) |
+| `WHISPER_PORT` | `8087` | Port des Whisper-Containers (Profil `ki`) |
+
+---
+
+## Phase 9 — Kassenverwaltung
+
+Kassenbuch, Mitgliedsbeiträge, Rechnungen an Dritte, Kassenprüfung und die
+Zahlen für die Jahreshauptversammlung.
+
+Eine Feuerwehrkasse wird von einem Ehrenamtlichen geführt und von zwei anderen
+geprüft. Was die Prüfung wert ist, hängt einzig daran, dass sich das Geprüfte
+hinterher nicht mehr ändern lässt. Deshalb ist der zentrale Punkt dieser Phase
+kein Formular, sondern eine Sperre.
+
+### Drei Festlegungen
+
+**Eine festgeschriebene Buchung ist unveränderbar.** Nicht, weil ein Zweig im
+Router es so vorsieht, sondern weil die Datenbank es ablehnt — ein vergessener
+Zustandscheck, ein Skript, ein Import würden sonst reichen. Korrigiert wird
+über eine **Gegenbuchung** mit Verweis: beide Buchungen bleiben stehen, und im
+Kassenbuch ist zu sehen, dass etwas berichtigt wurde. Genau das will ein
+Kassenprüfer sehen; eine verschwundene Buchung kann er nicht prüfen.
+
+**Der Kassenabschluss schließt seinen Zeitraum.** Danach wird keine Buchung
+mit einem Datum darin mehr angenommen — auch keine nachträglich
+hineindatierte. Ohne diese zweite Hälfte stimmte der geprüfte Bestand nach
+einem Datumswechsel nicht mehr, und niemand hätte es bemerkt. Wer nach der
+Prüfung noch eine Quittung findet, bucht sie mit dem heutigen Datum.
+
+**Beträge sind `DECIMAL(12,2)`, gerechnet wird mit `Prisma.Decimal`.**
+`0.1 + 0.2` ergibt in JavaScript 0.30000000000000004. In einer Kasse ist das
+kein Rundungsfehler, sondern eine Differenz in der Prüfung, die niemand
+erklären kann.
+
+### Das Kassenbuch
+
+Drei Kontenarten: Barkasse, Bankkonto, Rücklage. Der **Bestand wird gerechnet,
+nie gespeichert** — Anfangsbestand plus die Wirkung aller Buchungen. Ein
+gespeicherter Bestand neben einer nachgetragenen Buchung wäre falsch, ohne
+falsch auszusehen, und genau danach sucht ein Kassenprüfer.
+
+Der Betrag einer Buchung ist immer positiv; die Richtung steht daneben. Eine
+negative Ausgabe wäre eine Einnahme in Verkleidung und in keiner Auswertung
+als solche zu erkennen — die Datenbank nimmt sie deshalb nicht an.
+
+Die Buchungsmaske schlägt eine Kategorie vor: zuerst aus den **eigenen
+früheren Buchungen** der Wehr, erst danach aus einer kurzen Stichwortliste.
+Der Nutzen liegt nicht in den gesparten Sekunden, sondern darin, dass dieselbe
+Sache immer unter derselben Kategorie landet — erst das macht die
+Jahresauswertung brauchbar. Unter der Hälfte gemeinsamer Wörter schweigt der
+Vorschlag: ein falscher wird übernommen, ohne gelesen zu werden.
+
+Ein **gegengezeichneter Beleg** aus Phase 8 wird mit einem Klick zur Buchung:
+Konto und Kategorie wählen, fertig. Betrag, Datum und Händler stehen schon
+fest, und das Foto hängt danach an der Buchung — zu jeder Ausgabe ein Beleg,
+an der Buchung und nicht in einem Ordner daneben. Ein Entwurf lässt sich
+nicht buchen: er ist ein von einem Modell ausgefülltes Formular.
+
+### Kontoauszug einlesen
+
+Das Online-Banking bietet beides zum Herunterladen an, meist unter
+„Umsatzexport“:
+
+| Format | Datei | Was gelesen wird |
+|---|---|---|
+| CAMT.053 | `.xml`, `.camt` | Datum, Richtung, Betrag, Verwendungszweck, Gegenseite, Bankkennung |
+| MT940 | `.txt`, `.sta` | dasselbe, aus den Feldern `:61:` und `:86:` |
+
+Erkannt wird am Inhalt, nicht an der Dateiendung. Es entstehen **Entwürfe,
+keine fertigen Buchungen** — durchsehen muss sie der Kassier.
+
+Jeder Umsatz trägt eine Kennung: die der Bank, sonst eine aus Datum, Betrag
+und Zweck gebildete. Derselbe Auszug zweimal eingelesen wird dadurch als
+solcher erkannt und in der Liste als „steht schon in der Kasse“ ausgewiesen.
+Ohne das wäre es ein doppelt gebuchter Monat, und der fiele erst beim
+Kassenabschluss auf.
+
+Was nicht gelesen werden konnte, steht mit Grund daneben. Ein Parser, der
+stillschweigend drei Umsätze verschluckt, ist schlimmer als einer, der gar
+nicht erst liest.
+
+### Mitgliedsbeiträge
+
+Sätze gelten ab einem Jahr und je Abteilung; ein Satz ohne Abteilung gilt für
+alle übrigen. Rückwirkend geändert wird nichts — sonst stimmten die Beiträge
+vergangener Jahre nicht mehr, und die sind bereits geprüft.
+
+Der **Beitragslauf** zeigt vorher, was entstehen wird: wie viele Beiträge,
+welche Summe, und wer keinen passenden Satz hat. Der letzte Teil ist der
+interessante — das sind die Leute, für die niemand entschieden hat, was sie
+zahlen. Der Lauf ist wiederholbar; im Februar noch einmal gestartet legt er
+nur die Neuen an.
+
+Ein Zahlungseingang erzeugt zugleich die Buchung. Ein Häkchen ohne Geld in der
+Kasse wäre eine Behauptung. Ein Erlass braucht eine Begründung — die Datenbank
+lehnt einen ohne ab, weil er in der Kassenprüfung sonst eine offene Frage ist.
+
+Die Rückstandsliste geht über alle Jahre. Sie ist die einzige Ansicht, in der
+auffällt, wer seit drei Jahren offen steht.
+
+### Rechnungen an Dritte
+
+Kostenersatz nach Art. 28 BayFwG, Vermietungen, Veranstaltungen. Die Nummer
+vergibt FLORIAN fortlaufend je Jahr und **lückenlos**: eine fehlende Nummer
+muss in der Kassenprüfung erklärt werden.
+
+Der Betrag ist die Summe der Positionen, gerechnet und nicht eingegeben. Ein
+eingetippter Gesamtbetrag neben Positionen, die etwas anderes ergeben, ist der
+Fehler, den niemand bemerkt, bis der Empfänger anruft. Die Menge hat drei
+Nachkommastellen — Einsatzstunden werden viertelstündlich abgerechnet, und
+0,25 × 47,50 muss auf den Cent stimmen.
+
+Bis zum Versenden ist eine Rechnung ein Entwurf, danach unveränderbar: was
+beim Empfänger liegt, muss dem entsprechen, was hier steht. Korrigiert wird
+über Storno und eine neue Rechnung; die stornierte bleibt mit Grund stehen.
+
+### Kassenprüfung
+
+In der Prüfmaske steht links der Bestand laut Buch und rechts der gezählte.
+In dieser Reihenfolge, und die gezählten Felder fangen leer an — wer erst das
+Buch sieht und dann zählt, zählt, bis es passt.
+
+Ohne Prüfer und Prüfdatum lässt sich nichts festschreiben: ohne beides ist es
+kein Abschluss, sondern eine Notiz. Eine Differenz braucht eine Erläuterung,
+sonst steht in fünf Jahren „stimmt nicht“ im Bericht und niemand weiß mehr,
+warum.
+
+Der Kassenprüfbericht entsteht als PDF mit vier Unterschriftsfeldern und wird
+im Hintergrund erzeugt.
+
+### Auswertungen
+
+Einnahmen und Ausgaben nach Kategorie und Monat, mit dem Vorjahr daneben —
+eine Zahl ohne Vergleich sagt nichts. Der Export ist eine CSV-Datei mit
+Semikolon und BOM: das ist, was Excel in Deutschland ohne Rückfrage richtig
+öffnet. Eine Datei, die beim Doppelklick als eine Spalte voller Semikolons
+erscheint, wird zurückgeschickt.
+
+### Wer was sieht
+
+| Recht | Wer | Was |
+|---|---|---|
+| `kasse.lesen` | Kassier, Kommandant, Vorstand | Buchungen und Auswertungen ansehen |
+| `kasse.bearbeiten` | Kassier | Buchungen, Beiträge, Rechnungen erfassen |
+| `kasse.abschluss` | Kassier, Kassenprüfer | Kassenabschluss anlegen und festschreiben |
+
+Der Gerätewart sieht keine Buchungen, der Kassier keine Atemschutzdaten. Die
+Trennung liegt in `lib/authz.ts`, nicht in den Komponenten.
+
+**Keine zusätzlichen Umgebungsvariablen.** Die Kasse braucht nur, was ohnehin
+läuft: Postgres, MinIO für die Belege und Gotenberg für die PDFs.
+
+---
+
+## Phase 10 — Mandantenfähigkeit
+
+Ein Server, mehrere Wehren. Ein Konto, mehrere Zugehörigkeiten. Eine
+Kreisebene, die zusieht.
+
+Datenmodell und Row Level Security tragen seit Phase 0 mehrere Wehren — jede
+Tabelle hat `organisationId`, jede Abfrage läuft im Mandantenkontext. Was
+fehlte, war alles darüber: eine Anmeldung, die zu mehr als einer Wehr gehören
+kann, ein Weg zum Umschalten, und eine Verwaltung für den, der den Server
+betreibt.
+
+### Konto und Akte sind nicht dasselbe
+
+Bis Phase 9 war die Personenakte zugleich das Anmeldekonto: Passwort-Hash und
+OIDC-Subject hingen an `person`, und `person` gehört genau einer Wehr. Daraus
+folgten zwei Dinge, die niemand wollte:
+
+- Wer in zwei Wehren geführt wurde, brauchte **zwei Passwörter**, die
+  auseinanderlaufen können.
+- Die Anmeldung per E-Mail war **mehrdeutig**, sobald dieselbe Adresse in zwei
+  Wehren stand — die Eindeutigkeit galt nur je Organisation, und gefunden
+  wurde, was die Datenbank zuerst hergab.
+
+Seit Phase 10:
+
+| Tabelle | Was sie ist | Mandant |
+|---|---|---|
+| `Benutzer` | das Anmeldekonto — E-Mail, Passwort, OIDC | **keiner** |
+| `Mitgliedschaft` | Zugehörigkeit eines Kontos zu einer Wehr | `organisationId` |
+| `Person` | die Akte in einer Wehr — Dienstgrad, Qualifikationen, Einsätze | `organisationId` |
+
+**`Benutzer` trägt bewusst keine Mandantenkennung** und kann keine tragen: sie
+ist ja der Angelpunkt, an dem ein Mensch zu mehreren Wehren gehört. RLS greift
+dort deshalb nicht. Geschützt wird sie stattdessen über Rechte — dieselbe
+Lösung wie bei `Berechtigung` aus Phase 0 und aus demselben Grund: eine
+Tabelle, die über allen Mandanten steht, gehört nicht in die Hand der
+Anwendungsrolle. Was ein Konto in einer Wehr darf, entscheidet nicht es
+selbst, sondern seine `Mitgliedschaft`.
+
+Ein angenehmer Nebeneffekt: der Passwort-Hash kann aus einer Personenabfrage
+gar nicht mehr herausfallen. Die drei Stellen, die ihn bisher vorsichtshalber
+abgeschnitten haben, sind entfallen — eine Sorgfaltsmaßnahme ist durch eine
+Struktur ersetzt.
+
+### Die Wehr wechseln
+
+Der Wähler steht in der Seitenleiste unter dem Namen der Wehr — **aber nur,
+wenn es etwas zu wählen gibt.** Für die allermeisten gibt es das nie, und ein
+Auswahlfeld mit genau einem Eintrag ist keine Hilfe, sondern eine Frage ohne
+Antwortmöglichkeit.
+
+Nach der Anmeldung öffnet die **eigene** Wehr, nicht die betreute: wer eine
+Wehr führt und acht andere beaufsichtigt, will in seiner landen.
+
+Technisch: die Wehr steht im Sitzungstoken, also wird beim Wechsel ein neues
+ausgestellt. Was der Browser dabei schickt, ist ein **Wunsch** — geprüft wird
+serverseitig gegen die Mitgliedschaften des Kontos. Eine fremde Kennung zu
+nennen bringt nichts, weil es dazu keine Mitgliedschaft gibt.
+
+### Die Kreisebene
+
+Kreisbrandrat und Kreisbrandinspektion gehören den betreuten Wehren nicht an.
+Sie bekommen deshalb dort **keine Personenakte**, tauchen in keiner
+Mitgliederliste auf und können nichts ändern.
+
+Ihre Rechte werden nicht aufgezählt, sondern **gefiltert**: alles, was
+`.lesen` heißt, und sonst nichts. Eine von Hand gepflegte Liste wäre bei der
+nächsten Phase veraltet, und zwar unbemerkt — ein neues Modul brächte Rechte
+mit, die niemand nachträgt. So bekommt die Aufsicht neue Leserechte
+automatisch und neue Schreibrechte nie.
+
+Vier Rechte sind ausdrücklich ausgenommen, obwohl sie auf `.lesen` enden:
+
+| Recht | Warum nicht |
+|---|---|
+| `kasse.lesen` | Die Kasse gehört dem Verein oder der Kommune, nicht der Kreisaufsicht. |
+| `person.export` | Das Auskunftsrecht nach DSGVO erfüllt die Wehr, die die Daten führt. |
+| `system.auditlog` | Wer wann was getan hat, bleibt innerhalb der Wehr. |
+| `ki.protokoll` | Dasselbe. |
+
+Der **Atemschutz** steht dagegen bewusst drin: ob ein Träger tauglich ist, ist
+genau die Frage, für die es eine Kreisebene gibt.
+
+Wer als Aufsicht unterwegs ist, sieht dauerhaft einen Hinweis darauf — nicht
+als kurz aufblitzende Meldung, sondern als Zeile über der Ansicht. Man soll
+nicht erst merken, in welcher Rolle man ist, wenn ein Knopf fehlt.
+
+### Doppelmitgliedschaft
+
+Ein Konto, mehrere Zugehörigkeiten. In Bayern der Regelfall bei allem, was
+über die eigene Wehr hinausgeht: aktiv in A, Ehrenmitglied in B, oder
+Kommandant der einen und Kreisbrandinspektor für sechs weitere.
+
+Zwei Zusicherungen setzt die Datenbank durch:
+
+- **Ein Konto gehört einer Wehr höchstens einmal an.**
+- **Eine Personenakte hängt an höchstens einem Konto.** Sonst wäre nicht
+  entscheidbar, wer unter ihrem Namen gehandelt hat.
+
+Und eine dritte, die weniger offensichtlich ist: die Akte muss zu **derselben
+Wehr** gehören wie die Zuordnung. Ein Fremdschlüssel prüft nur, *dass* es die
+Akte gibt, nicht *wo* sie liegt — ohne diese Prüfung ließe sich ein Konto über
+eine Akte aus Wehr A in Wehr B hängen, und die Sitzung stünde dort mit einer
+Personenkennung da, die niemandem gehört. Ein Trigger lehnt das ab.
+
+### Wehren und Konten verwalten
+
+Unter **`/wehren`**, und nur für den, der die Installation betreibt.
+
+Der Zugang hängt an einem Merkmal des Kontos (`istVerwalter`), **nicht an
+einem Recht**. Rechte gelten je Wehr; wer Wehren anlegt, steht über allen. Ein
+Recht, das in Wehr A vergeben wird und in Wehr B wirkt, wäre genau die
+Hintertür, die diese Phase vermeiden soll.
+
+Was dort geht:
+
+- Eine Wehr anlegen — sie bekommt sofort ihre Systemrollen samt Rechten. Ein
+  Konto bekommt sie nicht: eine Wehr anzulegen und jemanden hineinzusetzen
+  sind zwei Entscheidungen, und die zweite trifft meist jemand anders.
+- Ein Konto anlegen — ohne Wehr. Die kommt über die Zuordnung.
+- Zuordnen: als Mitglied mit Personenakte oder als Kreisaufsicht ohne.
+
+**Jede Zuordnung wird in der betroffenen Wehr protokolliert**, nicht beim
+Verwalter. Sonst hätte der Betreiber einen Weg, sich still in fremde Daten zu
+setzen.
+
+**Keine zusätzlichen Umgebungsvariablen.**
+
+### Was bewusst fehlt
+
+**Wehrübergreifende Auswertungen.** Eine Zahl über mehrere Wehren hinweg
+braucht eine abgestimmte Definition — was zählt als Einsatz, was als Übung,
+wie wird eine Doppelmitgliedschaft gezählt. Ohne die ist eine solche Zahl
+schlimmer als keine, weil sie benutzt wird. Die Aufsicht sieht jede Wehr
+einzeln, und das reicht für die Fragen, die tatsächlich gestellt werden.
+
+**Ein Einladungsverfahren.** Passwörter werden vom Verwalter vergeben und
+weitergegeben. FLORIAN verschickt keine.
+
+---
+
+## Phase 11 — Freigabereife
+
+Die drei Dinge, die zwischen dem letzten Modul und dem Echtbetrieb standen:
+das Auskunftsrecht, ein geprüftes Sicherungskonzept und eine Pipeline.
+
+### Auskunft nach Art. 15 DSGVO
+
+Jede Person darf verlangen zu erfahren, welche Daten über sie verarbeitet
+werden. In einer Feuerwehr ist das mehr, als die meisten erwarten — und mit
+den G26-Untersuchungen sind Gesundheitsdaten dabei, also eine besondere
+Kategorie nach Art. 9.
+
+Auf der Seite eines Mitglieds steht dafür der Knopf **Datenauskunft**
+(Recht `person.export`). Ein Durchgang liefert drei Dinge:
+
+| | Wofür |
+|---|---|
+| **Anzeige** | Was ausgehändigt wird, vor dem Aushändigen |
+| **PDF** | Das Schreiben an die Person, für die Akte |
+| **JSON** | Datenübertragbarkeit nach Art. 20 |
+
+Bewusst nicht drei Knöpfe: wer eine Auskunft erteilt, soll sie vollständig
+erteilen und nicht in Schritten, von denen zwei vergessen werden können.
+
+**Über jedem Abschnitt steht, wozu die Daten vorliegen.** Art. 15 Abs. 1
+verlangt nicht nur die Daten, sondern auch Zwecke, Empfänger, Speicherdauer
+und den Hinweis auf die weiteren Rechte. Eine Liste ohne das sieht aus wie
+eine Auskunft und ist keine.
+
+Zwei Festlegungen bestimmen den Zuschnitt:
+
+**Was über die Person gespeichert ist, steht vollständig drin** — auch das
+Unangenehme: eine nicht bestandene G26, ein gemahnter Beitrag. Eine Auskunft,
+die auswählt, was gut aussieht, ist keine.
+
+**Was die Person getan hat, steht als Zahl drin.** Wer zwölf Prüfprotokolle
+unterschrieben hat, bekommt die Zahl — nicht zwölf Protokolle. Die gehören zum
+Nachweisbestand der Wehr; sie mitzuliefern hieße, dass jeder über eine
+Selbstauskunft an die Geräteakten käme. Die Trennlinie ist nicht „viel oder
+wenig", sondern „über mich" gegen „von mir".
+
+Leere Abschnitte bleiben stehen. „Dazu liegt nichts vor" ist eine Auskunft;
+ein weggelassener Abschnitt wirft die Frage auf, ob da doch etwas ist.
+
+Der Vorgang wird protokolliert — dass eine Auskunft erteilt wurde, gehört
+festgehalten.
+
+### Sicherung
+
+```bash
+npm run sicherung                      # nach ./sicherungen/<Zeitstempel>/
+npm run sicherung -- --ziel D:\backups
+```
+
+Gesichert wird beides, aus **demselben Moment**: die Datenbank über `pg_dump`
+im Container und alle Dateien aus MinIO. Eine Datenbank von heute mit Dateien
+von gestern ergibt Datensätze, die auf nichts zeigen.
+
+Daneben entsteht ein `manifest.json` mit Zeitpunkt, Version und Umfang. Es
+wird beim Zurückspielen angezeigt, damit niemand versehentlich eine Sicherung
+von vor drei Monaten einspielt, weil das Verzeichnis ähnlich hieß.
+
+### Wiederherstellung
+
+```bash
+npm run wiederherstellen -- --quelle sicherungen/2026-09-05T14-16-48
+npm run wiederherstellen -- --quelle ... --wirklich
+```
+
+Ohne `--wirklich` passiert nichts — es wird nur angezeigt, was geschähe. Das
+ist keine Bequemlichkeit: das Skript überschreibt den gesamten Bestand.
+
+**Der eigentliche Zweck ist nicht der Notfall, sondern die Probe.** Eine
+Sicherung, die nie zurückgespielt wurde, ist eine Vermutung: der Ordner kann
+leer sein, der Dump abgeschnitten, das Passwort falsch. Man erfährt es an dem
+Tag, an dem man es nicht erfahren will.
+
+Wie berechtigt das ist, hat sich hier gezeigt. Der erste Rückspielversuch lief
+sauber durch — und hatte dabei **sämtliche Unveränderlichkeitsgarantien der
+Datenbank entfernt**. Der Grund liegt tiefer, als man vermutet:
+`docker/postgres/10-init-app-role.sh` richtet eine Vorgabeprivilegierung ein,
+damit neue Tabellen aus Migrationen automatisch nutzbar sind. `pg_restore`
+legt die Tabellen aber ebenfalls neu an — die Vorgabe greift also auch dort,
+und die `GRANT`-Zeilen aus dem Dump können nur hinzufügen, nie wegnehmen. Die
+Anwendungsrolle durfte danach das Audit-Log ändern, Wiki-Fassungen löschen und
+Kiosk-Vorgänge umschreiben. Nichts an der Anwendung hätte darauf hingewiesen.
+
+Deshalb setzt das Skript die Sperren nach dem Zurückspielen neu und **prüft
+danach nach**, ob es gewirkt hat. Die Liste dafür steht in
+`scripts/sicherung-sperren.ts`, und ein Test gleicht sie gegen die migrierte
+Datenbank ab: läuft sie auseinander, käme eine Sperre nach einer
+Wiederherstellung nicht zurück, von der niemand mehr weiß, dass es sie gab.
+
+Nach dem Zurückspielen bleiben drei Handgriffe, die keine Software abnehmen
+kann:
+
+1. Anmelden — kommt jemand hinein?
+2. Ein Prüfprotokoll öffnen — ist das PDF da?
+3. Die Mitgliederzahl mit der Erwartung vergleichen.
+
+Erst danach gilt die Sicherung als geprüft.
+
+### Die Pipeline
+
+`.gitea/workflows/pruefung.yml`, zwei Aufträge:
+
+| Auftrag | Was | Wann |
+|---|---|---|
+| `pruefung` | typecheck, lint, Migrationen, Seed, 599 Unit-Tests | jeder Push und Pull Request |
+| `oberflaeche` | die E2E-Tests über Chromium | nur `main` und Pull Requests |
+
+Die Trennung ist eine Zeitfrage: der erste Auftrag dauert Minuten, der zweite
+eine Dreiviertelstunde.
+
+Die Datenbank wird aus `docker/postgres` **gebaut** statt aus einem fertigen
+Image genommen. FLORIAN braucht PostGIS und pgvector, und kein öffentliches
+Image bringt beides mit; ein Dienst-Container mit `postgres:17` ließe die
+Migrationen durchlaufen und scheiterte erst bei der ersten Umkreissuche. Der
+Seed läuft mit, weil er selbst ein Test ist: fällt ein Standardwert um, merkt
+man es hier und nicht, wenn eine Wehr ihn zum ersten Mal ausführt.
+
+> **Voraussetzung: ein registrierter Runner.** Die Datei allein genügt nicht —
+> Gitea braucht einen `act_runner`, der die Aufträge annimmt. Ist keiner
+> eingerichtet, erscheinen die Läufe als „wartend" und laufen nie. Zum
+> Zeitpunkt dieser Phase war noch keiner registriert; der Ablauf ist also
+> geschrieben, aber nicht im Betrieb erprobt.
+
+---
+
 ## Befehle
 
 ```bash
+npm run sicherung          # Datenbank und Dateien sichern
+npm run wiederherstellen   # zurueckspielen (Probelauf ohne --wirklich)
 npm run dev              # Entwicklungsserver auf Port 3100
 npm run build            # Produktionsbuild
 npm run worker:dev       # Hintergrundprozess mit Neuladen
 npm run test             # Vitest
-npm run test:e2e         # Playwright
+npm run test:e2e         # Playwright (vorher: npm run db:test-reset)
+npm run lint             # ESLint
+npm run lint:fix         # ESLint mit automatischen Korrekturen
 npm run typecheck        # TypeScript ohne Ausgabe
 npm run db:migrate       # ausstehende Migrationen anwenden
 npm run db:seed          # Beispielwehr einspielen
+npm run db:test-reset    # Testwehr für die E2E-Tests neu aufbauen
 npm run db:studio        # Prisma Studio
 npm run screenshots      # Bilder für docs/ANLEITUNG.md erzeugen
 npm run vapid            # VAPID-Schlüsselpaar für Web-Push erzeugen
 ```
 
+## Tests
+
+```bash
+npm run test             # Vitest — Unit und Datenbankregeln
+npm run db:test-reset    # einmalig vor dem E2E-Lauf
+npm run test:e2e         # Playwright
+```
+
+### Zwei Wehren in der Datenbank
+
+Die E2E-Tests laufen gegen eine **eigene Wehr** (`ff-teststelle`), nicht gegen
+die Beispielwehr aus der Anleitung. Der Grund ist ein handfester: bis Phase 8
+schrieben sie in `ff-musterhausen`, und nach fünf Phasen standen dort
+120 Atemschutz-Überwachungen statt einer und 115 Geräte statt 45. Zweimal
+fielen Tests aus, weil ein gesuchter Eintrag von Seite 1 gerutscht war — und
+bei jedem Lauf unterschieden sich alle 72 Bildschirmfotos.
+
+`npm run db:test-reset` löscht die Testwehr und legt sie neu an, mit denselben
+Beispieldaten. Die Beispielwehr wird dabei nicht angefasst; ein Sicherungsriegel
+im Skript bricht ab, wenn beide Kennungen übereinstimmen.
+
+Anmeldung der Testwehr: `e2e@teststelle.de` / `Feuerwehr2026`, änderbar über
+`E2E_ADMIN_EMAIL` und `E2E_ADMIN_PASSWORT`.
+
 ## Dienste und Ports (Entwicklung)
 
 Bewusst nicht die Standardports, damit FLORIAN neben anderen lokalen Stacks
@@ -1003,6 +1643,9 @@ laufen kann. Alle Werte stehen in der `.env`.
 | MinIO Weboberfläche | http://localhost:9011 |
 | Gotenberg | http://localhost:3101 |
 | Mailpit (nur Entwicklung) | http://localhost:8125 |
+| ntfy (Profil `push`) | http://localhost:8086 |
+| Ollama (Profil `ki`) | http://localhost:11435 |
+| faster-whisper (Profil `ki`) | http://localhost:8087 |
 | Adminer (nur Entwicklung) | http://localhost:8081 |
 
 ## Produktionsbetrieb
@@ -1019,15 +1662,45 @@ ohne Traefik. In Produktion terminiert Traefik TLS und verteilt auf
 Der App-Container wendet beim Start ausstehende Migrationen an; der Worker
 tut das bewusst nicht, damit nicht zwei Prozesse gleichzeitig migrieren.
 
+### Aktualisieren
+
+```bash
+./update.sh --pruefen   # nachsehen, ob es etwas Neues gibt
+./update.sh             # einspielen
+```
+
+Der Ablauf ist so gebaut, dass er an jeder Stelle abbrechen darf, ohne eine
+halb aktualisierte Anlage zu hinterlassen:
+
+1. Nachsehen, ob überhaupt etwas Neues da ist — sonst endet es hier.
+2. **Sichern.** Vor allem anderen; ein Update ist der häufigste Anlass, eine
+   Sicherung zu brauchen.
+3. Neue Fassung holen und die Abbilder bauen. Schlägt das fehl, läuft die alte
+   Fassung unverändert weiter — es wurde noch nichts umgeschaltet.
+4. Umschalten. Der App-Container spielt dabei die Migrationen ein.
+5. Nachsehen, ob die Anwendung wieder antwortet. Tut sie es nach zweieinhalb
+   Minuten nicht, stehen die letzten Protokollzeilen da und die Befehle, mit
+   denen der vorherige Stand zurückkommt.
+
+Vorher prüft das Skript, dass Docker, git und die `.env` da sind und dass im
+Verzeichnis keine unverbuchten Änderungen liegen. `--ohne-sicherung` gibt es
+für Testinstallationen; im Betrieb gehört es nicht benutzt.
+
 ## Datenschutz
 
 - Keine Telemetrie, keine externen CDNs, keine Google Fonts. Es werden nur
   Schriften verwendet, die auf dem Gerät vorhanden sind.
 - Aufbewahrungsfristen konfigurierbar (`AUFBEWAHRUNG_JAHRE`,
   `AUDIT_AUFBEWAHRUNG_TAGE`, `PERSON_ANONYMISIERUNG_TAGE`).
-- Externe Dienste (Mail, Telegram, ntfy, Web-Push, LLM) sitzen hinter
+- Externe Dienste (Mail, Telegram, ntfy, Web-Push) sitzen hinter
   Schnittstellen in `src/lib/integrations/` und sind einzeln abschaltbar. Ohne
   Freischaltung wird nur ins Log geschrieben.
+- **Die KI-Funktionen laufen ausschließlich gegen selbst betriebene Modelle.**
+  Es gibt keinen Rückfall auf einen Anbieter: fehlt der eigene Endpunkt, fehlt
+  die Funktion. Kein Text verlässt das Gerätehaus.
+- Jede KI-Ausgabe ist gekennzeichnet, wird als eigener Datensatz festgehalten
+  und muss von einem Menschen übernommen werden, bevor sie in einen Nachweis
+  gelangt. Nachvollziehbar im KI-Protokoll.
 - Über Kanäle, die das Netz der Wehr verlassen (Telegram, Web-Push), gehen nur
   Kurzfassungen ohne Namen, Gerätebezeichnungen und Einsatzdetails.
 - Kein WhatsApp — die Begründung steht oben unter „Warum kein WhatsApp".

docker-compose.yml

@@ -87,6 +87,16 @@ x-app-env: &app-env
   LLM_BASE_URL: ${LLM_BASE_URL:-}
   LLM_API_KEY: ${LLM_API_KEY:-}
   LLM_MODELL: ${LLM_MODELL:-}
+  LLM_TIMEOUT: ${LLM_TIMEOUT:-120}
+  LLM_EINBETTUNG_MODELL: ${LLM_EINBETTUNG_MODELL:-nomic-embed-text}
+  LLM_EINBETTUNG_DIMENSIONEN: ${LLM_EINBETTUNG_DIMENSIONEN:-768}
+  LLM_VISION_MODELL: ${LLM_VISION_MODELL:-}
+  WHISPER_ENABLED: ${WHISPER_ENABLED:-false}
+  WHISPER_URL: ${WHISPER_URL:-}
+  WHISPER_MODELL: ${WHISPER_MODELL:-base}
+  WHISPER_SPRACHE: ${WHISPER_SPRACHE:-de}
+  WHISPER_TIMEOUT: ${WHISPER_TIMEOUT:-300}
+  DIKTAT_MAX_SEKUNDEN: ${DIKTAT_MAX_SEKUNDEN:-600}
   GEOCODING_ENABLED: ${GEOCODING_ENABLED:-false}
   NOMINATIM_URL: ${NOMINATIM_URL:-}
   GEOCODING_TIMEOUT: ${GEOCODING_TIMEOUT:-5}
@@ -144,10 +154,18 @@ services:
     logging: *logging
 
   # ---------------------------------------------------------------------------
-  # PostgreSQL 17 mit PostGIS. Einziger Ort für relationale Daten.
+  # PostgreSQL 17 mit PostGIS und pgvector. Einziger Ort für relationale Daten.
+  #
+  # Eigenes Image, weil FLORIAN beides braucht und es kein offizielles gibt,
+  # das beides mitbringt — siehe docker/postgres/Dockerfile. Beim ersten
+  # `docker compose up` wird es gebaut; bei einer bestehenden Installation
+  # genügt `docker compose build postgres` und ein Neustart des Dienstes. Das
+  # Datenverzeichnis bleibt unberührt, die Hauptversion ändert sich nicht.
   # ---------------------------------------------------------------------------
   postgres:
-    image: postgis/postgis:17-3.5
+    build:
+      context: ./docker/postgres
+    image: florian-postgres:${IMAGE_TAG:-17-3.5-pgvector}
     container_name: florian-postgres
     restart: unless-stopped
     environment:
@@ -318,6 +336,82 @@ services:
       - intern
     logging: *logging
 
+  # ---------------------------------------------------------------------------
+  # Ollama — Sprachmodelle im eigenen Haus (Phase 8).
+  #
+  # Nur mit Profil:  docker compose --profile ki up -d
+  #
+  # Es gibt bewusst KEINEN Rückfall auf einen Anbieter. Läuft dieser Container
+  # nicht, fehlen die KI-Funktionen — sie werden nicht durch einen fremden
+  # Dienst ersetzt. Ein Einsatzbericht spricht über Menschen in ihrer
+  # schlechtesten Stunde; solche Texte gehören nirgendwo anders hin.
+  #
+  # Nach dem ersten Start müssen die Modelle geholt werden:
+  #
+  #   docker compose exec ollama ollama pull qwen2.5:14b       # Text
+  #   docker compose exec ollama ollama pull nomic-embed-text  # Einbettungen
+  #   docker compose exec ollama ollama pull llama3.2-vision   # Belege (optional)
+  #
+  # Auf einem Rechner ohne Grafikkarte läuft das Einbettungsmodell noch flott,
+  # das Textmodell zäh und das Vision-Modell praktisch nicht. Deshalb sind alle
+  # drei einzeln konfigurierbar: eine Wehr kann das Wiki durchsuchbar machen,
+  # ohne Berichte schreiben zu lassen.
+  #
+  # Für eine Nvidia-Karte zusätzlich das Compose-Fragment aus dem README
+  # einbinden (deploy.resources.reservations.devices) — es steht nicht fest
+  # hier drin, weil es ohne Karte den Start verhindert.
+  # ---------------------------------------------------------------------------
+  ollama:
+    image: ollama/ollama:0.5.7
+    container_name: florian-ollama
+    restart: unless-stopped
+    profiles: [ki]
+    environment:
+      # Modelle bleiben geladen, statt nach fünf Minuten aus dem Speicher zu
+      # fallen. Wer zweimal am Tag einen Bericht schreibt, wartet sonst jedes
+      # Mal auf das Nachladen.
+      OLLAMA_KEEP_ALIVE: ${OLLAMA_KEEP_ALIVE:-30m}
+      OLLAMA_HOST: "0.0.0.0:11434"
+    volumes:
+      - ollama-data:/root/.ollama
+    ports:
+      - "${OLLAMA_PORT:-11435}:11434"
+    networks:
+      - intern
+    logging: *logging
+
+  # ---------------------------------------------------------------------------
+  # faster-whisper — Spracherkennung fürs Diktat (Phase 8).
+  #
+  # Nur mit Profil:  docker compose --profile ki up -d
+  #
+  # OpenAI-kompatible Schnittstelle, aber vollständig lokal. Das Modell wird
+  # beim ersten Aufruf geholt und dann behalten.
+  #
+  # WHISPER_MODELL steuert die Größe: "tiny" läuft auf jedem Bürorechner,
+  # "base" ist der brauchbare Kompromiss, "small" erkennt Fachbegriffe
+  # merklich besser und will dafür Zeit oder eine Grafikkarte.
+  # ---------------------------------------------------------------------------
+  whisper:
+    image: fedirz/faster-whisper-server:latest-cpu
+    container_name: florian-whisper
+    restart: unless-stopped
+    profiles: [ki]
+    environment:
+      WHISPER__MODEL: ${WHISPER_MODELL:-base}
+      WHISPER__INFERENCE_DEVICE: ${WHISPER_GERAET:-cpu}
+      # Nach zehn Minuten ohne Anfrage den Speicher freigeben. Eine Wehr
+      # diktiert nicht stündlich.
+      WHISPER__TTL: ${WHISPER_TTL:-600}
+      ENABLE_UI: "false"
+    volumes:
+      - whisper-data:/root/.cache/huggingface
+    ports:
+      - "${WHISPER_PORT:-8087}:8000"
+    networks:
+      - intern
+    logging: *logging
+
   # ---------------------------------------------------------------------------
   # ntfy — Push aufs Handy, ohne dass etwas das Haus verlässt (Phase 7).
   #
@@ -434,6 +528,10 @@ volumes:
   redis-data:
   minio-data:
   traefik-acme:
+  # Phase 8: die Modelle. Sie sind mehrere Gigabyte groß und sollen einen
+  # Neustart des Containers überleben — sonst werden sie jedes Mal neu geholt.
+  ollama-data:
+  whisper-data:
 
 networks:
   # Nur was von außen erreichbar sein muss, hängt hier drin.

docker/postgres/10-init-app-role.sh

@@ -2,7 +2,8 @@
 # =============================================================================
 # Läuft EINMALIG beim allerersten Start des Postgres-Containers (leeres
 # Datenverzeichnis). Richtet ein:
-#   - die benötigten Erweiterungen (PostGIS, pgcrypto, citext, unaccent, pg_trgm)
+#   - die benötigten Erweiterungen (PostGIS, pgvector, pgcrypto, citext,
+#     unaccent, pg_trgm)
 #   - den Anwendungsbenutzer "florian_app" OHNE BYPASSRLS
 #   - Vorgabeprivilegien, damit künftige Tabellen automatisch nutzbar sind
 #
@@ -28,6 +29,7 @@ psql -v ON_ERROR_STOP=1 --username "$POSTGRES_USER" --dbname "$POSTGRES_DB" <<-'
     CREATE EXTENSION IF NOT EXISTS citext;       -- E-Mail ohne Gross/Klein
     CREATE EXTENSION IF NOT EXISTS unaccent;     -- Suche ueber Umlaute hinweg
     CREATE EXTENSION IF NOT EXISTS pg_trgm;      -- unscharfe Namenssuche
+    CREATE EXTENSION IF NOT EXISTS vector;       -- semantische Suche im Wiki
 EOSQL
 
 # Anwendungsrolle anlegen. Bewusst OHNE DO-Block: psql ersetzt seine Variablen

docker/postgres/Dockerfile

@@ -0,0 +1,33 @@
+# =============================================================================
+# PostgreSQL 17 mit PostGIS **und** pgvector.
+#
+# Warum ein eigenes Image: FLORIAN braucht beides. PostGIS seit Phase 6 für
+# Hydranten und Umkreissuche, pgvector seit Phase 8 für die semantische Suche
+# im Wiki. Es gibt kein offizielles Image, das beides mitbringt —
+# postgis/postgis kennt kein vector, pgvector/pgvector kein PostGIS.
+#
+# Die Alternative wäre gewesen, die Ähnlichkeitssuche in der Anwendung zu
+# rechnen: alle Abschnitte laden, Kosinusabstand in TypeScript. Das geht bei
+# zweihundert Wiki-Seiten und wird bei zweitausend zäh — und es verlegt eine
+# Aufgabe in die Anwendung, für die die Datenbank einen Index hat.
+#
+# Das Basisimage ist Debian mit eingerichtetem PGDG-Repository; die Erweiterung
+# kommt als fertiges Paket daher, nicht als Übersetzungslauf.
+# =============================================================================
+FROM postgis/postgis:17-3.5
+
+# Version festhalten: ein stillschweigender Sprung auf eine neue pgvector-
+# Fassung würde beim nächsten Neubau des Images passieren, nicht dann, wenn
+# jemand darüber entscheidet.
+ARG PGVECTOR_PAKET=postgresql-17-pgvector
+
+RUN set -eux; \
+    apt-get update; \
+    apt-get install -y --no-install-recommends "${PGVECTOR_PAKET}"; \
+    rm -rf /var/lib/apt/lists/*
+
+# Die Erweiterung selbst wird nicht hier angelegt, sondern in der Migration
+# (CREATE EXTENSION IF NOT EXISTS vector). Grund: eine bestehende Installation
+# bekommt zwar das neue Image, aber nicht noch einmal den Init-Lauf — das
+# Datenverzeichnis ist ja nicht leer. Über die Migration greift es in beiden
+# Fällen.

docs/ANLEITUNG.md

@@ -1,10 +1,11 @@
 # Anleitung
 
-Bedienung von FLORIAN, Stand Phase 7 (Version 0.8.0). Die Bilder zeigen die
-Beispielwehr aus dem Seed und werden mit `npm run screenshots` neu erzeugt.
+Bedienung von FLORIAN, Version 1.0.0. Die Bilder zeigen die Beispielwehr aus
+dem Seed und werden mit `npm run screenshots` neu erzeugt.
 
-> Die lokale KI und die Kassenverwaltung kommen in den folgenden Phasen dazu.
-> Siehe [ROADMAP.md](ROADMAP.md).
+> **Das hier ist zum Nachschlagen, nicht zum Durchlesen.** Wer anfangen will,
+> nimmt die [Kurzanleitung](KURZANLEITUNG.md) — nach Rollen sortiert, auf ein
+> paar Seiten.
 
 ---
 
@@ -1502,7 +1503,625 @@ wenn sein Code technisch noch stimmt.
 
 ---
 
-## 43. Rollen und was sie dürfen
+## 43. Das Wiki der Wehr
+
+![Wissen](screenshots/41-wissen-light.png)
+
+Unter **Wissen** steht, was die Wehr nachschlagen soll: Dienstvorschriften,
+Merkblätter, Ausbildungsunterlagen. Also das, was heute als PDF im Ordner steht
+und im Einsatz niemand findet.
+
+Lesen darf jeder. Eine Wehr, in der nur die Führung nachschlagen kann, hat kein
+Wiki, sondern einen Aktenschrank.
+
+### Zwei Suchen, und beide werden gebraucht
+
+| Suche | Findet | Braucht ein Sprachmodell |
+|---|---|---|
+| **Wortsuche** (das Feld) | was dasteht — „FwDV 7" findet die Seite mit genau dieser Zeichenfolge | nein |
+| **Frage** (der Kasten oben) | was gemeint ist — „wie lange hält ein Schlauch" findet den Abschnitt über Ablegereife | ja |
+
+Die Wortsuche zeigt nicht nur den Seitennamen, sondern die **Textstelle**. So
+sieht man beim Suchen, ob es die richtige Stelle ist, ohne die Seite zu öffnen.
+
+### Eine Seite schreiben
+
+**Seite anlegen**, dann Titel, Bereich und Inhalt. Der Inhalt ist Markdown:
+
+```
+## Eine Überschrift
+
+Ein Absatz.
+
+- Ein Aufzählungspunkt
+- Noch einer
+
+| Spalte | Spalte |
+|---|---|
+| Wert   | Wert   |
+```
+
+Die **Überschriften sind wichtiger, als sie aussehen**: an ihnen wird die Seite
+für die Suche zerlegt, und sie stehen später als Fundstelle unter einer
+Antwort. Eine Seite ohne Überschriften ist ein einziger großer Block und liefert
+entsprechend grobe Fundstellen.
+
+Unter dem Textfeld steht beim Bearbeiten, in wie viele Abschnitte zerlegt wird.
+
+### Fundstelle angeben
+
+Das Feld **Fundstelle** ist freiwillig und trotzdem das wichtigste: Es steht
+unter jeder Antwort, die aus dieser Seite gebaut wird.
+
+> „Zusammenfassung nach FwDV 7, Ausgabe 2002" sagt einem Leser, woran er ist.
+> Eine Antwort ohne Herkunft ist eine Behauptung.
+
+Abschreiben sollten Sie eine Dienstvorschrift übrigens nicht — die sind
+urheberrechtlich geschützt. Was hier hineingehört, ist die **eigene
+Zusammenfassung** mit Verweis auf die Fundstelle, so wie ein Merkblatt der Wehr.
+
+### Entwurf oder veröffentlicht
+
+Ein **Entwurf** wird nicht durchsucht und nicht für Antworten herangezogen. Das
+ist der Zustand für eine Seite, an der noch gearbeitet wird — sie steht dann nur
+für die, die bearbeiten dürfen, in der Liste.
+
+### Jede Änderung wird aufgehoben
+
+Beim Speichern wird die vorherige Fassung vollständig weggeschrieben. Über
+**Verlauf** lässt sich jede frühere Fassung im Wortlaut ansehen.
+
+Das ist keine Bequemlichkeit: eine Dienstvorschrift, die sich unbemerkt ändert,
+ist schlimmer als keine. Deshalb lässt sich eine Fassung auch nicht löschen.
+
+---
+
+## 44. Fragen stellen
+
+> **Beantwortet wird ausschließlich aus den hinterlegten Seiten.** Steht die
+> Antwort dort nicht, sagt FLORIAN genau das — statt etwas Plausibles zu
+> erfinden.
+
+Im Kasten oben auf der Wissensseite eine Frage eintippen und **Fragen** drücken.
+Nach ein paar Sekunden steht die Antwort da — in einem gestrichelten Rahmen mit
+dem Vermerk **Maschinell erzeugt**.
+
+Darunter stehen die **Fundstellen**, aus denen die Antwort gebaut wurde. Das
+sind Verweise: ein Klick führt auf die Seite. Lesen Sie sie, bevor Sie sich auf
+die Antwort verlassen — sie sind das Belegte, die Antwort ist die
+Zusammenfassung.
+
+Findet FLORIAN keine passende Stelle, wird das Modell **gar nicht erst gefragt**.
+Dann steht dort, dass es in den Unterlagen nicht steht. Das ist die richtige
+Antwort und keine Fehlermeldung.
+
+### Wenn kein Modell eingerichtet ist
+
+Dann steht statt des Kastens ein Hinweis. Die Wortsuche funktioniert weiter,
+und die ist für „FwDV 7" oder „Ablegereife" ohnehin die bessere.
+
+### Der Hinweis „Suchstand ist älter als der Text"
+
+Steht auf einer Seite, die geändert, aber noch nicht neu eingebettet wurde. Bis
+das nachgeholt ist, findet die Frage-Funktion noch die vorherige Fassung —
+gelesen wird auf der Seite natürlich die aktuelle.
+
+Der Hintergrundprozess holt das von selbst nach, spätestens im nächtlichen Lauf.
+Wer nicht warten will, drückt **Jetzt nachziehen**.
+
+---
+
+## 45. Diktieren statt tippen
+
+Auf der Einsatzseite unter **Bericht** → **Beim Schreiben helfen lassen**.
+
+Der Weg, den es in jeder Wehr schon gibt: jemand spricht auf der Rückfahrt in
+sein Telefon, und daraus wird abends ein Bericht. Neu ist nur, dass abends schon
+ein Text dasteht.
+
+1. **Diktat aufnehmen** drücken. Der Browser fragt nach dem Mikrofon.
+2. Sprechen. Der Zähler läuft mit.
+3. **Fertig** drücken. Die Aufnahme wird übertragen und erkannt — bei einer
+   langen Aufnahme dauert das ein bis zwei Minuten. Die Seite kann offen
+   bleiben, der Text erscheint von selbst.
+4. Text lesen, dann **In den Bericht übernehmen** oder **Verwerfen**.
+
+> **Bitte gegenlesen.** Fachbegriffe, Ortsnamen und Fahrzeugbezeichnungen
+> erkennt kein Modell zuverlässig. Die Aufnahme bleibt abgelegt, bis Sie
+> entschieden haben — wer dem Text nicht traut, hört nach.
+
+Das Mikrofon fragt der Browser nur über **HTTPS** oder auf `localhost` ab.
+Bleibt der Knopf ohne Wirkung, liegt es fast immer daran.
+
+### Aus Stichpunkten einen Entwurf
+
+Im selben Kasten. Stichpunkte eintippen — oder das Diktat dorthin übernehmen —
+und **Entwurf erstellen** drücken.
+
+```
+Angriffstrupp unter PA ins EG
+Brand in der Küche, Fettbrand
+Löschdecke, kein Wasser
+Belüftung mit Überdrucklüfter
+Übergabe an Polizei
+```
+
+Daraus wird ein Fließtext für die Akte. Was das Modell **nicht** bekommt:
+Zeitstempel, Einsatznummer und Fahrzeuge. Die stehen schon als Felder im Bericht
+und stünden sonst zweimal da — beim zweiten Mal womöglich falsch.
+
+Der Entwurf landet **nicht** im Berichtsfeld. Er steht daneben, gekennzeichnet,
+mit zwei gleich großen Knöpfen. Erst **Übernehmen** schreibt ihn ins Feld — und
+auch dann ist er nur ein Textvorschlag im Formular. Gespeichert wird er, wenn
+Sie **Bericht speichern** drücken.
+
+> Verantwortlich ist, wer freigibt. Ein Einsatzbericht ist ein Nachweis, und im
+> Zweifel liest ihn ein Gericht.
+
+---
+
+## 46. Belege erfassen
+
+![Belege](screenshots/42-belege-light.png)
+
+Unter **Belege**: **Beleg fotografieren** drücken. Auf dem Handy öffnet sich
+direkt die Kamera.
+
+Was das Modell erkennt, steht danach in **änderbaren Feldern**. Was es nicht
+erkannt hat, bleibt leer und ist **gelb hinterlegt** — das ist eine
+Aufforderung. Ein geratener Betrag wäre eine falsche Buchung, die niemand
+bemerkt.
+
+Prüfen Sie gegen das Foto, das links daneben steht. Dann **Gegenzeichnen**.
+
+> Mit dem Gegenzeichnen übernehmen Sie, was **dort steht** — nicht, was die
+> Maschine gelesen hat. Wenn Sie den Betrag berichtigen, ist der berichtigte
+> Betrag der Ihre. Beides bleibt nachvollziehbar: das KI-Protokoll hält fest,
+> was ursprünglich erkannt wurde.
+
+Ohne Vision-Modell funktioniert alles bis auf das Auslesen: der Beleg wird
+fotografiert und abgelegt, die Angaben tragen Sie von Hand ein.
+
+Ist der Beleg gegengezeichnet, steht in der Liste der erledigten Belege ein
+Knopf **Buchen**. Er führt in einem Schritt ins Kassenbuch — zu wählen sind
+nur Konto und Kategorie. Siehe [Kapitel 48](#48-buchen).
+
+### Das KI-Protokoll
+
+![KI-Protokoll](screenshots/43-ki-protokoll-light.png)
+
+Für Kommandant und Administrator: unter **KI-Protokoll** steht jede Befragung
+eines Modells — was hineinging, was herauskam, wer entschieden hat.
+
+Die Zeile **Offen** ist die wichtigste. Sie zählt die Ausgaben, die erzeugt und
+nie angesehen wurden. Steht dort eine große Zahl, benutzt jemand den Assistenten
+und liest nicht gegen.
+
+Eingabe, Ausgabe und Modell lassen sich nachträglich nicht ändern, und löschen
+kann man einen Vorgang gar nicht. Das ist der Zweck der Liste: sie soll belegen,
+was war.
+
+Daneben unter **Protokoll** steht dasselbe für Menschen: jede Änderung an jedem
+Datensatz, seit dem ersten Tag.
+
+---
+
+## 47. Die Kasse
+
+Unter **Kasse** stehen alle Konten der Wehr mit ihrem heutigen Bestand.
+
+![Kassenübersicht](screenshots/45-kasse-light.png)
+
+Drei Arten von Konten:
+
+| Art | Wofür |
+|---|---|
+| **Barkasse** | Die Kassette im Gerätehaus. Wechselgeld für Feste, Kleinausgaben. |
+| **Bankkonto** | Das Girokonto der Wehr. Mit IBAN, damit sich Kontoauszüge zuordnen lassen. |
+| **Rücklage** | Angespartes für eine Beschaffung. Wird nicht laufend bewegt. |
+
+**Der Bestand wird gerechnet, nicht gespeichert.** Anfangsbestand plus alle
+Buchungen. Wer nachträglich eine Buchung einträgt, sieht den Bestand sofort
+richtig — es gibt keinen zweiten Wert, der danebenläuft.
+
+### Beim ersten Mal
+
+Steht die Kasse leer, bietet die Übersicht an, den **Standardkontenrahmen**
+anzulegen: rund zwanzig Kategorien, wie sie eine Feuerwehrkasse braucht —
+Kraftstoff, Reparatur, Schutzkleidung, Ausbildung, Verpflegung auf der einen
+Seite; Zuschüsse, Spenden, Mitgliedsbeiträge, Veranstaltungen, Kostenersatz
+auf der anderen.
+
+Sie lassen sich danach umbenennen, ergänzen und um eigene Unterkategorien
+erweitern. Wer eine eigene Gliederung hat, legt sie stattdessen von Hand an.
+
+---
+
+## 48. Buchen
+
+![Kassenbuch](screenshots/46-kassenbuch-light.png)
+
+Oben stehen drei Summen: Einnahmen, Ausgaben, Saldo. Sie beziehen sich auf
+**alle** Treffer der eingestellten Auswahl, nicht nur auf die angezeigten
+Zeilen — eine Summe unter einer abgeschnittenen Liste bedeutete nichts.
+
+### Eine Buchung erfassen
+
+Der Betrag ist immer positiv; ob es eine Einnahme oder eine Ausgabe ist, steht
+mit den beiden Knöpfen daneben. Eine „negative Ausgabe" gibt es nicht: sie
+wäre eine Einnahme in Verkleidung und in keiner Auswertung als solche zu
+erkennen.
+
+Sobald ein Verwendungszweck dasteht, schlägt FLORIAN eine Kategorie vor.
+Zuerst aus den **eigenen früheren Buchungen** der Wehr — steht darunter „zuletzt
+so gebucht", ist dieselbe Sache schon einmal so einsortiert worden. Erst wenn
+es dazu nichts gibt, greift eine Stichwortliste.
+
+Der Vorschlag ist ein Angebot, kein Automatismus: er wird erst übernommen,
+wenn er angeklickt wird. Und ist er unsicher, erscheint gar keiner. Ein
+falscher Vorschlag wäre schlechter als keiner — er wird übernommen, ohne
+gelesen zu werden.
+
+### Entwurf und festgeschrieben
+
+Eine neue Buchung ist zunächst ein **Entwurf**. Sie lässt sich ändern und
+verwerfen, solange der Kassier sie durchsieht.
+
+Mit **Festschreiben** wird sie unveränderbar. Das ist der Zustand, den eine
+Kassenprüfung erwartet, und dahinter führt kein Weg zurück — auch nicht über
+einen Umweg, die Datenbank lehnt jede Änderung ab.
+
+Ein Schloss in der Zeile zeigt, welche Buchungen festgeschrieben sind.
+
+### Einen Beleg buchen
+
+Wurde eine Quittung unter **Belege** fotografiert und gegengezeichnet, muss
+sie nicht noch einmal abgetippt werden. In der Liste der erledigten Belege
+steht dort ein Knopf **Buchen**.
+
+Zu wählen sind nur Konto und Kategorie — alles andere steht schon fest.
+Betrag, Datum und Händler kommen aus dem gegengezeichneten Beleg, und das
+Foto hängt danach an der Buchung. Das ist der Zustand, den eine
+Kassenprüfung erwartet: zu jeder Ausgabe ein Beleg, und zwar an der Buchung
+und nicht in einem Ordner daneben.
+
+Ein Beleg, der noch nicht gegengezeichnet ist, lässt sich nicht buchen. Er
+ist bis dahin ein von einer Maschine ausgefülltes Formular.
+
+### Wenn etwas falsch war
+
+Bei einem Entwurf: ändern oder verwerfen.
+
+Bei einer festgeschriebenen Buchung: **Gegenbuchen**. Es entsteht eine zweite
+Buchung mit derselben Summe in die andere Richtung, mit Verweis auf die erste
+und mit dem eingegebenen Grund im Verwendungszweck. Beide bleiben stehen.
+
+Das sieht nach mehr Aufwand aus, als eine Zahl zu korrigieren, und ist genau
+der Punkt: eine verschwundene Buchung kann ein Kassenprüfer nicht prüfen. Eine
+berichtigte kann er nachvollziehen.
+
+Das Datum der Gegenbuchung ist immer **heute**. Läge es im geprüften Zeitraum,
+würde die Datenbank sie ablehnen — und das zu Recht.
+
+---
+
+## 49. Kontoauszug einlesen
+
+Statt fünfzig Umsätze abzutippen, lässt sich der Auszug aus dem Online-Banking
+einlesen. Zwei Formate:
+
+| Format | Datei |
+|---|---|
+| **CAMT.053** | `.xml` oder `.camt` |
+| **MT940** | `.txt` oder `.sta` |
+
+Beides bietet fast jedes Online-Banking zum Herunterladen an, meist unter
+„Umsatzexport" oder „Umsätze exportieren". Welches von beiden, spielt keine
+Rolle — FLORIAN erkennt es am Inhalt.
+
+### Was dabei passiert — und was nicht
+
+Es entstehen **Entwürfe**, keine fertigen Buchungen. Jeder Posten muss danach
+noch durchgesehen und die Kategorie geprüft werden.
+
+Umsätze, die schon in der Kasse stehen, sind grau hinterlegt und mit „steht
+schon in der Kasse" gekennzeichnet. Sie sind nicht vorausgewählt. Das ist der
+eigentliche Wert der Sache: ein zweimal eingelesener Auszug wäre sonst ein
+doppelt gebuchter Monat, und der fällt erst beim Kassenabschluss auf — also
+drei Monate später.
+
+Umsätze, die nicht gelesen werden konnten, stehen mit Grund darüber. Sie
+verschwinden nicht stillschweigend.
+
+---
+
+## 50. Mitgliedsbeiträge
+
+![Beiträge](screenshots/47-beitraege-light.png)
+
+### Sätze
+
+Ein Beitragssatz gilt **ab einem Jahr** und wahlweise für eine Abteilung. Ein
+Satz ohne Abteilung gilt für alle, die keinen eigenen haben.
+
+Rückwirkend wird nichts geändert. Wer den Beitrag erhöht, legt einen neuen
+Satz ab dem kommenden Jahr an — sonst stimmten die Beiträge der vergangenen
+Jahre nicht mehr, und die sind bereits geprüft.
+
+### Der Beitragslauf
+
+Einmal im Jahr, meist im Januar. Vorher zeigt FLORIAN, was entstehen wird:
+
+- wie viele Beiträge und über welche Summe
+- wie viele Mitglieder für dieses Jahr schon einen haben (die bleiben unberührt)
+- **wer keinen passenden Satz hat**
+
+Der letzte Punkt ist der wichtige. Das sind die Mitglieder, für die niemand
+entschieden hat, was sie zahlen — entweder fehlt ein Satz für ihre Abteilung
+oder es gibt keinen allgemeinen.
+
+Der Lauf lässt sich wiederholen. Wer im Februar drei Neue aufgenommen hat,
+startet ihn noch einmal; doppelt entsteht nichts.
+
+### Zahlungen und Mahnungen
+
+Ein Zahlungseingang erzeugt zugleich die **Buchung** im Kassenbuch. Ein
+Häkchen ohne Geld in der Kasse wäre eine Behauptung.
+
+Gemahnt wird als Sammelaktion: die offenen Beiträge auswählen, mahnen. Die
+Mahnstufe zählt hoch. Ab der fünften Stufe hört FLORIAN auf — was danach
+kommt, entscheidet die Kommandantschaft und nicht die Software.
+
+Ein **Erlass** braucht eine Begründung. Ohne sie wird er nicht gespeichert:
+ein erlassener Beitrag ohne Grund ist in der Kassenprüfung eine offene Frage,
+und in fünf Jahren weiß es niemand mehr.
+
+### Rückstände
+
+Ganz oben steht die Rückstandsliste über **alle Jahre**, nach Person
+gruppiert. Sie ist die einzige Ansicht, in der auffällt, wer seit drei Jahren
+offen steht — in der Jahresliste sieht das aus wie ein einzelner offener
+Beitrag.
+
+---
+
+## 51. Rechnungen an Dritte
+
+![Rechnungen](screenshots/48-rechnungen-light.png)
+
+Kostenersatz nach Art. 28 BayFwG (Fehlalarm einer Brandmeldeanlage, Öleinsatz
+mit Verursacher), Vermietung des Schulungsraums, Absicherung einer
+Veranstaltung.
+
+### Nummer und Betrag
+
+Die **Rechnungsnummer** vergibt FLORIAN fortlaufend je Jahr, lückenlos. Eine
+fehlende Nummer muss in der Kassenprüfung erklärt werden, deshalb wird auch
+eine stornierte Rechnung nicht gelöscht, sondern bleibt mit Grund stehen.
+
+Der **Betrag** ist die Summe der Positionen und wird nicht eingegeben. Ein von
+Hand eingetippter Gesamtbetrag neben Positionen, die etwas anderes ergeben,
+ist der Fehler, den niemand bemerkt, bis der Empfänger anruft.
+
+Die Menge hat drei Nachkommastellen: Einsatzstunden werden vielerorts
+viertelstündlich abgerechnet, und 0,25 × 47,50 € muss auf den Cent stimmen.
+
+### Entwurf, versendet, bezahlt
+
+Bis zum **Versenden** ist eine Rechnung ein Entwurf und lässt sich vollständig
+ändern. Danach nicht mehr: was beim Empfänger liegt, muss dem entsprechen, was
+hier steht.
+
+Beim Versenden entsteht das PDF im Hintergrund. Es steht kurz darauf zum
+Herunterladen bereit.
+
+Der Zahlungseingang erzeugt — wie beim Beitrag — zugleich die Buchung. Wurde
+weniger überwiesen als berechnet, lässt sich der abweichende Betrag eintragen.
+
+Für eine Korrektur: stornieren und neu schreiben. Eine bezahlte Rechnung wird
+nicht storniert; dort ist zuerst die Buchung gegenzubuchen.
+
+---
+
+## 52. Kassenprüfung
+
+![Kassenabschluss](screenshots/49-kassenabschluss-light.png)
+
+Einmal im Jahr, meist vor der Jahreshauptversammlung. Zwei Kassenprüfer zählen
+die Kasse und vergleichen mit dem Buch.
+
+### Der Ablauf
+
+1. **Zeitraum wählen.** In der Regel das abgelaufene Kalenderjahr.
+2. **Zählen.** In der Maske stehen links die Bestände laut Buch und rechts
+   leere Felder für das Gezählte. Die Reihenfolge ist Absicht: wer erst das
+   Buch sieht und dann zählt, zählt, bis es passt.
+3. **Differenz erklären**, falls eine bleibt.
+4. **Prüfer und Prüfdatum eintragen.**
+5. **Festschreiben.**
+
+Steht ein Hinweis auf noch nicht festgeschriebene Buchungen im Zeitraum: erst
+durchsehen. Das Festschreiben des Abschlusses nimmt sie mit.
+
+### Was das Festschreiben bewirkt
+
+Der Zeitraum ist danach **zu**. Es lässt sich keine Buchung mehr mit einem
+Datum darin anlegen, und keine vorhandene mehr dorthin verschieben. Wer nach
+der Prüfung noch eine Quittung findet, bucht sie mit dem heutigen Datum.
+
+Der Abschluss selbst ist ebenfalls unveränderbar — Zahlen, Prüfer und
+Erläuterung stehen fest. Nachgetragen wird nur der Prüfbericht, weil das PDF
+im Hintergrund entsteht.
+
+Ohne Prüfer und Prüfdatum lässt sich nichts festschreiben: ohne beides ist es
+kein Abschluss, sondern eine Notiz. Und eine Differenz ohne Erläuterung
+ebenfalls nicht — sonst steht in fünf Jahren „stimmt nicht" im Bericht und
+niemand weiß mehr, warum.
+
+### Der Prüfbericht
+
+Entsteht als PDF mit vier Unterschriftsfeldern: beide Prüfer, der Kassier und
+der Kommandant. Er lässt sich ausdrucken, unterschreiben und abheften — die
+Papierform bleibt für die Entlastung in der Versammlung die maßgebliche.
+
+---
+
+## 53. Auswertungen und Export
+
+Unter **Kasse → Abschluss → Auswertung** stehen die Zahlen für die
+Jahreshauptversammlung:
+
+- Einnahmen und Ausgaben je Kategorie, absteigend nach Betrag
+- der Verlauf über zwölf Monate
+- das Vorjahr daneben — eine Zahl ohne Vergleich sagt nichts
+
+Das ist die Ansicht, in der auffällt, dass sich die Kraftstoffkosten verdoppelt
+haben.
+
+### Export
+
+**Kassenbuch als CSV** lädt alle Buchungen eines Jahres herunter: Datum,
+Konto, Richtung, Betrag, Ober- und Unterkategorie, Kontonummer,
+Verwendungszweck, Belegnummer, Gegenüber und ob festgeschrieben.
+
+Die Datei ist für den Steuerberater oder die Kämmerei gedacht und öffnet in
+Excel ohne Rückfrage richtig: Semikolon als Trennzeichen, Komma als
+Dezimaltrennzeichen, UTF-8 mit Kennung.
+
+---
+
+## 54. Mehrere Wehren auf einem Server
+
+Ein FLORIAN kann mehrere Wehren führen — eine Gemeinde mit drei Ortswehren,
+ein Landkreis mit zwanzig. Die Wehren sehen einander dabei **nicht**. Jede
+Abfrage ist an eine Wehr gebunden, und zwar in der Datenbank selbst, nicht im
+Programm.
+
+### Konto und Personenakte
+
+Zwei verschiedene Dinge, und der Unterschied ist der Kern dieses Kapitels:
+
+| | Was es ist |
+|---|---|
+| **Konto** | Womit Sie sich anmelden. E-Mail und Passwort. Gehört keiner Wehr. |
+| **Personenakte** | Ihr Eintrag in einer Wehr: Dienstgrad, Qualifikationen, Einsätze. |
+| **Zuordnung** | Verbindet beides — je Wehr eine. |
+
+Wer nur zu einer Wehr gehört, merkt davon nichts: ein Konto, eine Akte, eine
+Zuordnung, und alles sieht aus wie vorher.
+
+Wer zu **zwei** Wehren gehört — aktiv in der einen, Ehrenmitglied in der
+anderen —, hat trotzdem nur **ein** Passwort. Zwei Akten, ein Konto.
+
+### Die Wehr wechseln
+
+Steht Ihr Konto bei mehreren Wehren, wird der Name der Wehr in der
+Seitenleiste zu einem Auswahlfeld. Ein Klick darauf, und alle Wehren stehen
+untereinander — mit dem Hinweis, ob Sie dort Mitglied oder Kreisaufsicht sind.
+
+Nach der Anmeldung sind Sie immer in **Ihrer eigenen** Wehr, nicht in einer
+betreuten.
+
+Nach dem Wechsel wird alles neu geladen. Was Sie danach sehen, gehört zur
+neuen Wehr — es gibt keinen Zustand, in dem Daten der einen unter dem Namen
+der anderen stehen.
+
+---
+
+## 55. Kreisbrandrat und Kreisbrandinspektion
+
+Die Kreisebene bekommt Zugang zu den betreuten Wehren, ohne ihnen anzugehören.
+
+**Sie sieht und ändert nichts.** Das ist keine Einstellung, die jemand
+versehentlich anders setzen kann: eine Aufsichtszuordnung bekommt genau die
+Leserechte und keines der Schreibrechte, und zwar automatisch auch für Module,
+die es noch gar nicht gibt.
+
+Wer als Aufsicht in einer Wehr unterwegs ist, sieht das durchgehend als Zeile
+über der Ansicht.
+
+### Was die Aufsicht sieht
+
+Mitglieder, Fahrzeuge, Geräte, Prüfungen, Atemschutz, Einsätze, Übungen,
+Qualifikationen, Termine, Wiki, Karte.
+
+Der **Atemschutz** ist dabei der wichtigste Punkt: ob ein Träger tauglich ist,
+ist genau die Frage, für die es eine Kreisebene gibt.
+
+### Was sie nicht sieht
+
+| | Warum |
+|---|---|
+| **Kasse** | Sie gehört dem Verein oder der Kommune, nicht der Kreisaufsicht. |
+| **Protokoll** | Wer wann was getan hat, bleibt innerhalb der Wehr. |
+| **KI-Protokoll** | Dasselbe. |
+| **Personenexport nach DSGVO** | Das Auskunftsrecht erfüllt die Wehr, die die Daten führt. |
+
+### Sie taucht in keiner Mitgliederliste auf
+
+Die Aufsicht hat in der betreuten Wehr **keine Personenakte**. Sie ist also
+kein Mitglied, erscheint in keiner Liste, in keiner Stärkemeldung und in
+keiner Anwesenheit — und kann als Urheber einer Änderung auch gar nicht
+eingetragen werden, weil sie keine macht.
+
+Ist der Kreisbrandinspektor zugleich Kommandant seiner Heimatwehr, hat er dort
+ganz normal seine Akte und seine Rollen. Es sind zwei Zuordnungen desselben
+Kontos, mehr nicht.
+
+---
+
+## 56. Wehren und Konten verwalten
+
+Unter **Wehren und Konten**. Der Menüpunkt erscheint nur für den, der die
+Installation betreibt — nicht für Kommandanten, auch nicht für
+Administratoren einer einzelnen Wehr.
+
+> Dieses Merkmal hebt die Trennung zwischen den Wehren auf. Es gehört an so
+> wenige Konten wie möglich, im Regelfall an eines.
+
+### Eine Wehr anlegen
+
+Vollständiger Name, Kurzname und eine **Kennung**. Die Kennung steht später
+im Terminal und in Dateipfaden und lässt sich nicht mehr ändern — also mit
+Bedacht wählen: Kleinbuchstaben, Ziffern, Bindestriche, etwa
+`ff-musterhausen`.
+
+Die neue Wehr bekommt sofort ihre Rollen samt Rechten. Ein Konto bekommt sie
+nicht: das ist der zweite Schritt.
+
+### Ein Konto anlegen
+
+E-Mail-Adresse und ein erstes Passwort. Die Adresse gilt über alle Wehren
+hinweg und ist damit die Anmeldung.
+
+Das Passwort steht im Klartext da, damit Sie es weitergeben können — FLORIAN
+verschickt keines. Es gehört nach der ersten Anmeldung geändert.
+
+Gibt es zu der Adresse schon ein Konto, sagt FLORIAN das und legt **kein
+zweites** an. Wenn diese Person zu einer weiteren Wehr gehören soll, bekommt
+sie eine weitere Zuordnung — genau dafür ist die Trennung da.
+
+### Zuordnen
+
+Konto wählen, **Wehr zuordnen**, dann:
+
+- **Mitglied** — zusätzlich die Personenakte in dieser Wehr wählen. Zur
+  Auswahl steht, wer noch kein Konto hat: eine Akte gehört zu höchstens einem,
+  sonst wäre nicht entscheidbar, wer unter ihrem Namen gehandelt hat.
+- **Kreisaufsicht** — keine Akte, nur Leserechte.
+
+Jede Zuordnung wird **in der betroffenen Wehr** protokolliert. Dort steht also
+nachlesbar, dass jemand von außen Zugang bekommen hat.
+
+### Eine Zuordnung beenden
+
+Über das Papierkorb-Symbol. Die Personenakte in der Wehr bleibt bestehen —
+entfernt wird nur der Zugang. Wer ausgetreten ist, wird in der Mitgliederliste
+ausgetragen, nicht hier.
+
+---
+
+## 57. Rollen und was sie dürfen
 
 Neun Rollen, jede mit einem festen Satz Rechte. Die Zuordnung steht zentral in
 `src/lib/authz.ts` und wird beim Seed in die Datenbank gespiegelt — eine Wehr
@@ -1514,10 +2133,11 @@ kann sie also nachträglich zuschneiden, ohne dass jemand Code ändert.
 | **Kommandant** | alles innerhalb der eigenen Wehr, einschließlich Rollen vergeben und Protokoll einsehen |
 | **Gerätewart** | Fahrzeuge und Geräte anlegen, ändern, aussondern; Prüfungen planen und durchführen |
 | **Atemschutzgerätewart** | zusätzlich Atemschutzgeräte, Träger und die Überwachung nach FwDV 7 |
-| **Kassier** | Buchungen und Kassenabschluss (Modul noch nicht geplant, siehe Roadmap) |
+| **Kassier** | Kassenbuch, Beiträge, Rechnungen und Kassenabschluss; Belege erfassen und gegenzeichnen |
 | **Schriftführer** | Mitglieder pflegen, Einsätze und Berichte erfassen, den Terminkalender führen |
 | **Ausbilder** | Übungen und Übungstermine planen, Teilnahme, Anwesenheit und Qualifikationen erfassen |
-| **Mitglied** | eigene Daten, Listen lesen, Termine sehen und sich zurückmelden, eigene Benachrichtigungswege einrichten |
+| **Mitglied** | eigene Daten, Listen lesen, Termine sehen und sich zurückmelden, eigene Benachrichtigungswege einrichten, im Wiki lesen |
+| **Kreisebene** | sieht die betreuten Wehren, ändert nichts — siehe [Kapitel 55](#55-kreisbrandrat-und-kreisbrandinspektion) |
 | **Terminal** | nur anmelden und erfassen — nie verwalten |
 
 Zwei Dinge sind bewusst so gebaut:
@@ -1536,7 +2156,7 @@ sind nur die Textvorlagen, und die hängen an einem eigenen Recht.
 
 ---
 
-## 44. Anmeldung über authentik einrichten
+## 58. Anmeldung über authentik einrichten
 
 authentik läuft **getrennt** von FLORIAN und ist nicht Teil dieses Stacks.
 
@@ -1589,7 +2209,7 @@ ganze Wehr aus.
 
 ---
 
-## 45. PIN und Ausweiskarte verwalten
+## 59. PIN und Ausweiskarte verwalten
 
 Wie sich am Terminal angemeldet wird, steht in Kapitel 24. Hier geht es darum,
 was dahinter liegt.
@@ -1612,7 +2232,7 @@ Huber), PIN `471203`.
 
 ---
 
-## 46. Was protokolliert wird
+## 60. Was protokolliert wird
 
 Jede schreibende Änderung erzeugt einen Eintrag mit Zeitpunkt, Person,
 betroffenem Datensatz und den geänderten Feldern im Vorher-Nachher-Vergleich.
@@ -1637,7 +2257,124 @@ jeweiligen Detailseite sichtbar.
 
 ---
 
-## 47. Wenn etwas nicht geht
+## 61. Wenn jemand Auskunft über seine Daten verlangt
+
+Jede Person darf verlangen zu erfahren, welche Daten über sie verarbeitet
+werden — Art. 15 DSGVO. Die Anfrage muss **innerhalb eines Monats** beantwortet
+werden, und sie ist kostenlos.
+
+### So geht es
+
+1. **Mitglieder** öffnen, die Person anklicken.
+2. Rechts oben auf **Datenauskunft**.
+3. **Auskunft erstellen**.
+
+Danach stehen drei Dinge bereit:
+
+| | Wofür |
+|---|---|
+| **Die Anzeige** | Was ausgehändigt wird — vor dem Aushändigen |
+| **PDF** | Das Schreiben an die Person. Ausdrucken oder als Datei geben |
+| **JSON** | Nur, wenn die Person die Daten maschinenlesbar verlangt (Art. 20) |
+
+Das Recht dazu heißt `person.export` und liegt bei Kommandant und
+Administrator.
+
+### Was drinsteht
+
+Dreizehn Abschnitte: Stammdaten, Zugang, Rollen, Qualifikationen,
+arbeitsmedizinische Vorsorge, Belastungsübungen, Einsatz- und
+Übungsbeteiligung, Anwesenheiten, Fahrten, Beiträge, Benachrichtigungswege,
+Ausweise.
+
+Über jedem steht, **wozu** diese Daten vorliegen. Das ist kein Beiwerk: Art. 15
+verlangt neben den Daten auch die Zwecke und den Hinweis auf die weiteren
+Rechte. Eine bloße Liste erfüllt die Auskunftspflicht nicht.
+
+**Auch das Unangenehme steht drin** — ein gemahnter Beitrag, eine nicht
+bestandene G26. Eine Auskunft, die auswählt, was gut aussieht, ist keine.
+
+**Leere Abschnitte bleiben stehen.** „Dazu liegen keine Daten vor" ist eine
+Auskunft.
+
+**Gesundheitsdaten sind gekennzeichnet.** G26 und Belastungsübungen sind eine
+besondere Kategorie nach Art. 9 — das steht im Bericht ausdrücklich dabei.
+
+### Was nicht drinsteht
+
+Was die Person **getan** hat, erscheint nur als Zahl: „12 durchgeführte
+Prüfungen", „3 gemeldete Mängel".
+
+Das ist Absicht. Die Prüfprotokolle selbst gehören zum Nachweisbestand der
+Feuerwehr und nicht zu den personenbezogenen Daten eines Mitglieds. Würden sie
+mitgeliefert, käme jeder über eine Selbstauskunft an die kompletten
+Geräteakten — die Auskunftspflicht wäre eine Hintertür.
+
+### Der Vorgang wird protokolliert
+
+Dass eine Auskunft erteilt wurde, steht danach unter **Protokoll**. Das ist
+richtig so: die Auskunft legt alles offen, was über einen Menschen gespeichert
+ist, einschließlich seiner Gesundheitsdaten. Wer sie erstellt hat und wann,
+gehört festgehalten.
+
+### Wenn die Person in zwei Wehren geführt wird
+
+Dann gibt es **zwei** Auskünfte, eine je Wehr. Das ist kein Versehen: jede Wehr
+ist eine eigene Verantwortliche im Sinne der Verordnung und kann nur über die
+Daten Auskunft geben, die sie selbst führt.
+
+---
+
+## 62. Sicherung und Wiederherstellung
+
+> **Der wichtigste Satz dieses Kapitels:** Eine Sicherung, die nie
+> zurückgespielt wurde, ist eine Vermutung.
+
+### Sichern
+
+```bash
+npm run sicherung
+npm run sicherung -- --ziel D:\backups
+```
+
+Gesichert wird die Datenbank **und** der Dateispeicher — Prüfprotokolle,
+Einsatzberichte, Fotos, Rechnungen. Beides aus demselben Moment: eine
+Datenbank von heute mit Dateien von gestern ergibt Einträge, die auf nichts
+zeigen.
+
+Das Ergebnis ist ein Verzeichnis mit Zeitstempel. Es gehört auf ein anderes
+Gerät — eine Sicherung auf derselben Festplatte hilft gegen einen
+Festplattenfehler nicht.
+
+### Zurückspielen
+
+```bash
+npm run wiederherstellen -- --quelle sicherungen/2026-09-05T14-16-48
+```
+
+So passiert **nichts**. Es wird nur angezeigt, aus welchem Moment die
+Sicherung stammt und wie groß sie ist. Erst mit `--wirklich` am Ende wird
+zurückgespielt — und dabei **der gesamte vorhandene Bestand überschrieben**.
+
+### Einmal im Jahr proben
+
+Nicht im Notfall zum ersten Mal. Der Ordner kann leer sein, der Auszug
+abgeschnitten, das Passwort falsch — man erfährt es sonst an dem Tag, an dem
+man es nicht erfahren will.
+
+Nach dem Zurückspielen prüft das Skript selbst nach, ob die Schutzsperren der
+Datenbank wieder stehen. Drei Handgriffe bleiben trotzdem:
+
+1. **Anmelden** — kommt jemand hinein?
+2. **Ein Prüfprotokoll öffnen** — ist das PDF da?
+3. **Die Mitgliederzahl** mit der Erwartung vergleichen.
+
+Erst danach gilt die Sicherung als geprüft. Das Datum der letzten geglückten
+Probe gehört ins Sicherungskonzept.
+
+---
+
+## 63. Wenn etwas nicht geht
 
 | Beobachtung | Wahrscheinliche Ursache | Was hilft |
 |---|---|---|
@@ -1677,6 +2414,14 @@ jeweiligen Detailseite sichtbar.
 | Eine Vorlage lässt sich nicht speichern | Ein Platzhalter gehört nicht zu diesem Anlass | Die Meldung nennt ihn und listet die erlaubten auf |
 | Ein Termin lässt sich nicht löschen | Es liegen schon Rückmeldungen vor | Absagen statt löschen — dann sehen die Angemeldeten den Grund |
 | Die Zusage wurde zur Warteliste | Die Plätze sind belegt | Sagt jemand ab, rücken Sie von selbst nach und werden benachrichtigt |
+| Der Kasten „Frage an die Unterlagen" fehlt | Kein Sprachmodell eingerichtet | `LLM_ENABLED=true` und `LLM_BASE_URL`; Container mit `docker compose --profile ki up -d`. Die Wortsuche geht trotzdem |
+| Die Frage antwortet „steht nicht in den Unterlagen" | Entweder steht es wirklich nicht drin — oder die Seite ist noch nicht eingebettet | Auf der Seite steht dann „Suchstand ist älter als der Text". **Jetzt nachziehen** drücken |
+| „Das Modell hat nach 120 Sekunden nicht geantwortet" | Ohne Grafikkarte ist das normal | Kleineres Modell (`qwen2.5:7b`) oder `LLM_TIMEOUT` hochsetzen |
+| „Das Modell liefert 1024 Dimensionen, die Datenbank erwartet 768" | Ein anderes Einbettungsmodell eingetragen | Entweder `nomic-embed-text` benutzen oder die Spalte per Migration ändern — siehe README, Phase 8 |
+| Der Diktat-Knopf bewirkt nichts | Der Browser fragt das Mikrofon nur über HTTPS oder auf localhost ab | Über die richtige Adresse aufrufen und die Freigabe erteilen |
+| Das Diktat bleibt bei „Wird erkannt …" stehen | Der Hintergrundprozess läuft nicht, oder Whisper ist nicht erreichbar | `docker compose ps`, dann `docker compose --profile ki up -d whisper`. Die Aufnahme bleibt erhalten |
+| Beim Beleg bleiben alle Felder leer | Kein Vision-Modell, oder das Foto ist unscharf | Angaben von Hand eintragen. Für die Erkennung `LLM_VISION_MODELL` setzen und das Modell holen |
+| Die Migration bricht mit „type vector does not exist" ab | Das Postgres-Image bringt pgvector noch nicht mit | `docker compose build postgres`, dann `docker compose up -d postgres` und erneut migrieren |
 
 Zustand aller Randsysteme auf einen Blick:
 

docs/AUFWANDSSCHAETZUNG.md

@@ -38,9 +38,11 @@ Faktoren, die in die Schätzung eingehen:
 | 5 | Atemschutz (FwDV 7) | 14–18 PT | 3,5–4,5 h | **2:40 h** |
 | 6 | Kartenmodule | 14–18 PT | 3,5–4,5 h | **2:50 h** |
 | 7 | Benachrichtigungen und Termine | 10–13 PT | 2,5–3,5 h | **3:10 h** |
-| 8 | Lokale KI | 9–12 PT | 2,5–3 h | offen |
-| 9 | Kassenverwaltung | 8–11 PT | 2–3 h | offen |
-| | **Summe** | **123–164 PT** | **28–37 h** | |
+| 8 | Lokale KI | 9–12 PT | 2,5–3 h | **3:40 h** |
+| 9 | Kassenverwaltung | 8–11 PT | 2–3 h | **4:10 h** |
+| 10 | Mandantenfähigkeit | 4–6 PT | 1–1,5 h | **4:20 h** |
+| 11 | Freigabereife | 5–7 PT | 1,5–2 h | **2:40 h** |
+| | **Summe** | **132–177 PT** | **30,5–40,5 h** | **35:30 h** |
 
 123–164 Personentage entsprechen etwa **6 bis 8 Monaten Vollzeitarbeit** einer
 einzelnen Person. Zum Vergleich: eine kommerzielle Feuerwehrverwaltung kostet
@@ -368,7 +370,7 @@ Zeilen samt Maskierung und Zeilenumbruch nach 75 Oktetten.
 
 ## Phase 8 — Lokale KI
 
-**Vergleichsaufwand: 9–12 PT**
+**Vergleichsaufwand: 9–12 PT** · **Tatsächlich: 3:40 h Sitzungszeit**
 
 | Baustein | PT |
 |---|---:|
@@ -378,10 +380,28 @@ Zeilen samt Maskierung und Zeilenumbruch nach 75 Oktetten.
 | Wiki mit pgvector, semantische Suche, RAG mit Quellenangabe | 3,5 |
 | Belegerfassung über ein Vision-Modell, immer bestätigen | 2,0 |
 
-Der Client aus Phase 0 (`lib/integrations/llm.ts`) ist bereits vorhanden. Die
-Kennzeichnungspflicht — jede KI-Ausgabe ist als solche erkennbar und muss
-bestätigt werden, bevor sie in ein Dokument mit Nachweischarakter gelangt —
-kostet wenig Zeit, ist aber nicht verhandelbar.
+Der Client aus Phase 0 (`lib/integrations/llm.ts`) war bereits vorhanden — er
+konnte allerdings nur Text und musste um Einbettungen und Bilder erweitert
+werden.
+
+Die Kennzeichnungspflicht war mit „kostet wenig Zeit" zu günstig eingeschätzt.
+Sie kostet wenig, wenn man sie als Abzeichen an einer Ansicht versteht. Als
+Zusicherung — eigener Datensatz je Ausgabe, unveränderlich, genau eine
+Entscheidung, Trigger und REVOKE dahinter, zwei Protokollansichten — ist sie
+ein guter halber Personentag, der in der Aufstellung gar nicht vorkommt.
+
+Zwei weitere Posten fehlen in der Schätzung:
+
+**Das eigene Postgres-Image.** pgvector und PostGIS gibt es nicht zusammen; es
+gibt kein offizielles Image mit beidem. Ein Dockerfile, ein Neubau, ein Neustart
+des Dienstes — eine halbe Stunde, aber sie stand nirgends.
+
+**Der Betrieb ohne Modell.** Der größte Einzelposten dieser Phase, und in der
+Aufstellung steht davon keine Zeile. Eine Wehr setzt FLORIAN auf, lange bevor
+sie über eine Grafikkarte nachdenkt — also muss jede Ansicht ohne Modell
+vollständig benutzbar bleiben und ehrlich sagen, was fehlt. Das sind vier
+verschiedene Hinweise an vier Stellen, eine zweite Suche, die immer
+funktioniert, und vierzehn E2E-Tests, die genau diesen Zustand absichern.
 
 ## Phase 9 — Kassenverwaltung
 
@@ -404,6 +424,41 @@ Die Unveränderlichkeit festgeschriebener Buchungen kostet hier fast nichts —
 das Muster steht seit Phase 0 mit dem Audit-Log-Trigger und lässt sich
 übernehmen.
 
+**Tatsächlich: 4:10 h** — die längste Phase bisher. Beide Schätzungen oben
+haben sich bestätigt und zugleich verschoben: MT940 kostete weniger als
+gedacht, weil beide Formate ohne Fremdbibliothek auskommen. Dafür war die
+Unveränderlichkeit nicht das Übernehmen eines Musters, sondern drei
+Trigger mit drei genau begründeten Ausnahmen — und die Ausnahmen sind der
+Teil, der Zeit gekostet hat. Zwei davon sind erst im Test aufgefallen:
+der Prüfbericht, der nach dem Festschreiben entsteht, und die
+DSGVO-Löschung einer Wehr, die an ihren eigenen festgeschriebenen Buchungen
+scheiterte.
+
+## Phase 10 — Mandantenfähigkeit
+
+**Vergleichsaufwand: 4–6 PT** — aus der Kandidatenliste vorgezogen, am
+05.09.2026 umgesetzt.
+
+| Baustein | PT |
+|---|---:|
+| `Benutzer` und `Mitgliedschaft`, datenerhaltende Umstellung | 1,5 |
+| Anmeldung: Konto statt Akte, Wehrwechsel im Sitzungstoken | 1,5 |
+| Kreisebene mit reinen Leserechten | 1,0 |
+| Wehrwähler und Verwaltung der Installation | 1,5 |
+
+Die Schätzung ging von „technisch bereits möglich, Oberfläche fehlt" aus —
+und das war zur Hälfte falsch. Datenmodell und RLS trugen tatsächlich mehrere
+Wehren, aber die Anmeldung nicht: Passwort und OIDC-Subject hingen an der
+Personenakte, und die gehört genau einer Wehr. Das war kein Oberflächenthema,
+sondern ein Umbau am Fundament.
+
+**Tatsächlich: 4:20 h.** Getragen hat eine Entscheidung ganz am Anfang: die
+Sitzung behält ihre Form und entsteht nur anders. Ohne sie wären 61 Dateien
+mit 414 Fundstellen zu ändern gewesen; so waren es acht. Die Zeit ging
+stattdessen in die Absicherung — zwei Trigger, vier CHECKs und elf
+Datenbanktests — und das ist die richtige Verteilung für eine Phase, deren
+einziger Zweck es ist, dass eine Wehr die andere nicht sieht.
+
 ---
 
 ## Was hier nicht drin ist

docs/DEVLOG.md

@@ -19,7 +19,578 @@ Die aufgewendete Zeit wandert nach jedem Abschnitt in die Spalte
 | Phase 5 — Atemschutz nach FwDV 7 | 2:40 h | 1 | 03.09.2026 |
 | Phase 6 — Kartenmodule | 2:50 h | 1 | 04.09.2026 |
 | Phase 7 — Benachrichtigungen und Termine | 3:10 h | 1 | 04.09.2026 |
-| **Summe** | **19:20 h** | **9** | |
+| Phase 8 — Lokale KI | 3:40 h | 1 | 04.09.2026 |
+| Aufräumarbeiten (Issues #10–#12) | 1:20 h | 1 | 04.09.2026 |
+| 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 |
+| 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
+
+---
+
+## 2026-09-05 · Phase 11 — Freigabereife
+
+**14:30 – 17:10 · 2:40 h · Version 0.12.0**
+
+### Was entstanden ist
+
+Kein Modul, sondern die drei Software-Voraussetzungen für 1.0.0.
+
+| Bereich | Umfang |
+|---|---|
+| Auskunft | `lib/dsgvo/auskunft.ts` und `bericht.ts`, `person.auskunft`, Dialog auf der Mitgliederseite |
+| Sicherung | `scripts/sicherung.ts`, `wiederherstellen.ts`, `sicherung-zugang.ts`, `sicherung-sperren.ts` |
+| Pipeline | `.gitea/workflows/pruefung.yml` mit zwei Aufträgen |
+| Tests | 18 neue: 9 gegen die Auskunft, 11 gegen die Sicherung |
+
+### Entscheidungen
+
+**Die Auskunft trennt „über mich" von „von mir".** Was über die Person
+gespeichert ist, steht vollständig drin — auch der gemahnte Beitrag und die
+nicht bestandene G26. Was die Person *getan* hat, steht als Zahl drin. Die
+zwölf Prüfprotokolle, die sie unterschrieben hat, gehören zum Nachweisbestand
+der Wehr; vollständig ausgeliefert käme jeder über eine Selbstauskunft an die
+Geräteakten, und die Auskunftspflicht wäre eine Hintertür.
+
+**Über jedem Abschnitt steht der Zweck.** Art. 15 Abs. 1 verlangt nicht nur
+die Daten, sondern auch Zwecke, Empfänger und den Hinweis auf die weiteren
+Rechte. Eine Liste ohne das sieht aus wie eine Auskunft und ist keine — das ist
+der Unterschied zwischen einem Datenbankexport und einem Schreiben an einen
+Menschen.
+
+**Eine Mutation, keine Abfrage.** Das Erstellen der Auskunft *ist* die
+Offenlegung, und die gehört ins Protokoll. Als Abfrage würde sie
+zwischengespeichert und mehrfach ausgeführt — sie wäre entweder nicht oder
+zwanzigmal vermerkt.
+
+**Sicherung und Wiederherstellung gehören zusammen.** Deshalb sind es zwei
+Skripte in einem Zug und nicht eines. Der Probelauf ist die Vorgabe; ohne
+`--wirklich` geschieht nichts.
+
+**Eine Liste, zwei Verwendungen.** `sicherung-sperren.ts` treibt sowohl das
+Wiederherstellen der Sperren als auch deren Prüfung. Zwei Listen wären zwei
+Wahrheiten, und die falsche fiele erst im Notfall auf.
+
+**Die Pipeline baut das eigene Postgres-Image.** Ein Dienst-Container mit
+`postgres:17` ließe die Migrationen durchlaufen und scheiterte erst bei der
+ersten Umkreissuche — die Pipeline prüfte dann etwas anderes als den Betrieb.
+
+### Wo es gehakt hat
+
+| Problem | Ursache | Lösung |
+|---|---|---|
+| **Eine Wiederherstellung entfernte alle Unveränderlichkeitsgarantien** | Zuerst `--no-acl` im Dump. Und selbst ohne das Flag greift beim Zurückspielen die Vorgabeprivilegierung aus dem Init-Skript: jede von `pg_restore` neu angelegte Tabelle bekommt alle Rechte, und `GRANT` kann nur hinzufügen | Das Skript setzt die Sperren nach dem Zurückspielen neu und prüft danach nach. Gefunden haben es vier Datenbanktests direkt nach der ersten Rückspielprobe |
+| `pg_dump` lehnte die Verbindungszeichenkette ab | Prisma hängt `?schema=public` an — „invalid URI query parameter" | Die URL wird zerlegt, Benutzer und Datenbank gehen als Flags, das Passwort über `PGPASSWORD` |
+| Feldnamen im Auskunftssammler stimmten reihenweise nicht | Aus dem Gedächtnis geschrieben statt aus dem Schema gelesen: `alarmierung` statt `alarmiertUm`, `beginn` statt `beginnUm`, `gemeldetVonId` statt `melderId` | Der Typechecker hat sie alle einzeln benannt — zehn Durchgänge, jeder eine Zeile |
+| Ein eigener Test war falsch, nicht der Code | `new URL("localhost:5432")` gelingt in Node: „localhost:" gilt als Protokoll | Die Zusicherung prüft jetzt, was wirklich greift — die Protokollprüfung eine Zeile später |
+| Ein Vorlagentest fiel im vollen Lauf aus | Er klickte auf „Speichern“, bevor React lief — dann verschickt das Formular sich selbst, und die Fehlerfläche entsteht nie. Unter Last dauert das Hydrieren länger. Dasselbe Muster wie beim Anmeldeskript in Phase 8 | Er wartet jetzt auf einen client-seitig erzeugten Knopf, bevor er klickt |
+
+### Abweichung von der Vorgabe
+
+**Die Pipeline ist nicht erprobt.** Sie ist geschrieben und syntaktisch
+geprüft, aber in Gitea war zum Zeitpunkt dieser Phase kein `act_runner`
+registriert. Ohne Runner erscheinen die Läufe als „wartend" und laufen nie.
+Ob der Ablauf durchläuft, zeigt sich erst, wenn einer eingerichtet ist — das
+steht so auch im README, damit niemand sich auf eine Prüfung verlässt, die
+nicht stattfindet.
+
+### Nachweise
+
+- `npm run typecheck` — ohne Ausgabe
+- `npm run lint` — ohne Befund
+- `npm run test` — 599 Tests grün, davon 18 neu
+- Auskunft von Hand erzeugt: 13 Abschnitte, 28 Angaben, 58 kB PDF
+- **Sicherung und Wiederherstellung vollständig durchgeführt**: ein nach der
+  Sicherung angelegter Datensatz war danach weg, alle Zahlen stimmten wieder,
+  und die 599 Tests liefen nach dem Zurückspielen grün — einschließlich derer,
+  die die Sperren prüfen
+
+---
+
+## 2026-09-05 · Phase 10 — Mandantenfähigkeit
+
+**08:10 – 12:30 · 4:20 h · Version 0.11.0**
+
+### Was entstanden ist
+
+Die einzige Phase bisher, die die Anmeldung selbst anfasst.
+
+| Bereich | Umfang |
+|---|---|
+| Datenmodell | `Benutzer`, `Mitgliedschaft`, `MitgliedschaftArt`; `Person` verliert die Anmeldefelder |
+| Absicherung | RLS für `mitgliedschaft`, zwei Trigger, vier CHECKs, ein REVOKE |
+| Anmeldung | `lib/auth.ts` neu: Konto statt Akte, Mitgliedschaftswahl, Wehrwechsel im Token |
+| Rechte | Rolle `AUFSICHT`, gefiltert statt aufgezählt; `istVerwalter` als Kontomerkmal |
+| Oberfläche | Wehrwähler, Aufsichtshinweis, `/wehren` zur Verwaltung |
+| Tests | 19 neue Unit-Tests (11 gegen die Datenbank), 13 E2E-Tests |
+
+### Entscheidungen
+
+**Die Sitzung behält ihre Form.** `sitzung.organisationId` und
+`sitzung.personId` werden an 329 bzw. 85 Stellen in 61 Dateien gelesen. Hätte
+sich ihre Bedeutung geändert, wäre das ein Umbau durch das halbe Projekt
+geworden. Stattdessen entsteht die Sitzung nur *anders* — aus der aktiven
+Mitgliedschaft statt aus der Person. Keine dieser 61 Dateien musste angefasst
+werden.
+
+**`personId` ist nullbar geworden.** Das war die eine Ausnahme davon, und zwar
+absichtlich: eine Aufsichtssitzung hat keine Akte. Der Typechecker hat daraus
+eine Liste gemacht — genau fünf Stellen verlangen eine Person, und alle fünf
+sind Dinge, an denen die Kreisaufsicht nichts verloren hat (Anmeldemarke,
+Dienstausweis, Prüfungswizard, Dateiupload, Atemschutz). Ein `?? ""` hätte
+dieselben fünf Stellen still passieren lassen.
+
+**`Benutzer` ohne `organisationId`.** Die zweite Ausnahme von der
+Architekturregel nach `Berechtigung` — und dieselbe Begründung: die Tabelle
+steht über allen Mandanten, weil sie der Angelpunkt ist, an dem ein Mensch zu
+mehreren Wehren gehört. Geschützt über Rechte statt RLS.
+
+**`AUFSICHT` steht nicht im Prisma-Enum.** Alle anderen Rollen werden einem
+Menschen in einer Wehr zugewiesen. Diese ergibt sich aus der Mitgliedschaftsart.
+Sie vergebbar zu machen hiesse, dass jemand innerhalb einer Wehr Rechte an
+einer anderen verteilen könnte.
+
+**Ihre Rechte werden gefiltert, nicht aufgezählt.** Alles, was `.lesen` heißt,
+minus vier ausdrückliche Ausnahmen. Eine Liste von Hand wäre bei Phase 11
+veraltet, und zwar unbemerkt — ein neues Modul brächte Rechte mit, die niemand
+nachträgt. So bekommt die Aufsicht neue Leserechte automatisch und neue
+Schreibrechte nie. Der Test dazu ist entsprechend formuliert: nicht „diese
+dreizehn Rechte", sondern „kein einziges, das nicht lesen heißt".
+
+**Die Kasse ist ausgenommen**, obwohl `kasse.lesen` auf `.lesen` endet. Sie
+gehört dem Verein oder der Kommune, nicht der Kreisaufsicht. Sie wäre nur
+deshalb dabei gewesen, weil das Recht zufällig richtig heißt — und genau
+dagegen ist die Ausnahmeliste da.
+
+**Die Migration ist datenerhaltend, mit Abbruchprüfung.** Konten und
+Zuordnungen entstehen, *bevor* die alten Spalten fallen; am Ende prüft ein
+`DO`-Block, dass keine Person mit Anmeldedaten ohne Konto dasteht, und bricht
+sonst ab. Eine Migration, die die Anmeldung anfasst und auf halbem Weg
+liegenbleibt, sperrt alle aus.
+
+### Wo es gehakt hat
+
+| Problem | Ursache | Lösung |
+|---|---|---|
+| Nach dem Wehrwechsel landete alles auf der Anmeldeseite | `aktuelleSitzung()` verlangte eine Personenkennung — die Aufsicht hat keine und galt damit als nicht angemeldet | Eine Sitzung ist gültig, wenn Wehr und Konto feststehen; die Akte darf fehlen |
+| Der Wechsel schien nicht zu greifen | Er griff: das Token trug die neue Wehr. Es war der dritte hängengebliebene Entwicklungsserver dieser Woche — `npm run build` neben laufendem `next dev` macht `.next` unbrauchbar, und der Server antwortet danach nur noch mit 500 | Server beenden, `.next` löschen. Diesmal notiert, damit es nicht ein viertes Mal passiert |
+| Der Seed brach ab | Er legt die Rollen aus `ROLLEN` an, und dort steht jetzt `AUFSICHT` — die es im Prisma-Enum bewusst nicht gibt | Im Seed gefiltert, mit Begründung |
+| `unstable_update` nahm den Wechselwunsch nicht an | Es akzeptiert nur `Partial<Session>` | Der Wunsch reist als `user.mitgliedschaftId` und wird serverseitig gegen die Mitgliedschaften geprüft |
+| Die Nachbarwehr war fest verdrahtet | `ff-nachbarshausen` für jeden Mandanten — genau die Vermischung von Test- und Beispieldaten, die Phase 8 beseitigt hat | Aus dem Mandanten abgeleitet: `<slug>-nachbar` |
+| Ein alter Datenbanktest wurde unzuverlässig | `ki-datenbank.test.ts` legte Wehr und Person idempotent an, die Wiki-Seite aber nicht. Die neue Testdatei verschob die Reihenfolge, und ein Rest aus einem abgebrochenen Lauf ließ den ganzen Datei-Lauf scheitern | Auch dort ein `upsert` |
+| Nach `db:test-reset` zeigte der Wehrwähler nur noch die betreute Wehr | Der Reset löschte die Testwehr, aber nicht ihre Nachbarwehr. Der Seed sah die Nachbarwehr, hielt alles für erledigt und legte die Mitgliedschaft in der neuen Testwehr nie wieder an | Der Reset nimmt Nachbarwehr und Kreiskonto mit; der Seed prüft beide Teile getrennt statt mit einem gemeinsamen Ausstieg. Gefunden hat es ein E2E-Test |
+| Im vollen Lauf fielen fremde Testdateien mit „Anmeldung fehlgeschlagen“ aus | Der Fehlversuch-Test meldete sich mit der Adresse des Administrators an. Fünf Fehlversuche sperren das Konto fünf Minuten — bei zwei Projekten und Wiederholungen kam das zusammen, und alle anderen Dateien brauchen dasselbe Konto | Der Test nimmt jetzt eine Adresse, die es nicht gibt. Die Meldung muss ohnehin dieselbe sein, damit sie nicht verrät, ob es die Adresse gibt |
+
+### Abweichung von der Vorgabe
+
+**Zwei Architekturregeln bekommen eine dokumentierte Ausnahme.**
+
+„Jede Tabelle hat `organisationId`" gilt für `Benutzer` nicht — sie kann es
+nicht, ohne den Zweck der Tabelle aufzuheben. Die Ausnahme steht im Schema, in
+der Migration und in der Roadmap, und die Tabelle ist dafür über Rechte
+geschützt statt über RLS.
+
+„Berechtigungen zentral in `lib/authz.ts`" gilt für den Verwalterzugang nicht:
+er hängt an `Benutzer.istVerwalter` und nicht an einem Recht. Rechte gelten je
+Wehr — ein Recht, das in Wehr A vergeben wird und in Wehr B wirkt, wäre die
+Hintertür, die diese Phase gerade schließen soll.
+
+### Nachweise
+
+- `npm run typecheck` — ohne Ausgabe
+- `npm run lint` — ohne Befund
+- `npm run test` — 581 Tests grün, davon 11 neu gegen eine echte Datenbank
+- `npm run test:e2e` — grün über Desktop und Tablet, davon 26 neu
+- `npm run db:seed` und `npm run db:test-reset` — beide Mandanten samt
+  Nachbarwehr und Kreisebene
+- Anmeldung nach der Umstellung von Hand geprüft: Konto gefunden, Passwort
+  richtig, Sitzung trägt Konto, Mitgliedschaft und Verwaltermerkmal
+
+---
+
+## 2026-09-04 · Phase 9 — Kassenverwaltung
+
+**12:40 – 16:50 · 4:10 h · Version 0.10.0**
+
+### Was entstanden ist
+
+Neun Modelle, drei Trigger, zwölf CHECKs, sechs Router, fünf Ansichten und
+ein Kassenjahr im Seed.
+
+Der Reihe nach, wie es CLAUDE.md vorgibt: Schema, Migration, Serverlogik, UI,
+Tests.
+
+| Bereich | Umfang |
+|---|---|
+| Datenmodell | `Kassenkonto`, `Buchungskategorie`, `Buchung`, `Beitragssatz`, `Beitrag`, `Rechnung`, `Rechnungsposition`, `Kassenabschluss`, `Abschlussposten` |
+| Absicherung | RLS für alle neun Tabellen, drei Trigger, zwölf CHECKs, ein REVOKE |
+| Bibliothek | `lib/kasse/betrag.ts`, `bankimport.ts`, `vorschlag.ts`, `texte.ts`, `dokumente.ts` |
+| Router | Konten, Kategorien, Buchungen, Beiträge, Rechnungen, Abschluss |
+| Oberfläche | Übersicht, Kassenbuch, Beiträge, Rechnungen, Abschluss mit Auswertung |
+| Hintergrund | Rechnungs-PDF, Kassenprüfbericht, Meldung überfälliger Posten |
+| Tests | 67 Unit-Tests (13 gegen eine echte Datenbank), 13 E2E-Tests |
+
+### Entscheidungen
+
+**Die Sperren sitzen in der Datenbank, nicht im Router.** Die ganze Phase
+hängt an einem Satz: was geprüft ist, ändert sich nicht mehr. Ein
+Zustandscheck in `buchung.aendern` erfüllt das nicht — er gilt für genau
+diesen einen Weg. Ein zweiter Router, ein Skript, ein Import, und der geprüfte
+Bestand ist ein anderer, ohne dass irgendwo etwas auffällt. Also drei Trigger:
+festgeschriebene Buchung unveränderbar, geprüfter Zeitraum zu, festgeschriebener
+Abschluss fest.
+
+**Jeder Trigger hat genau eine Ausnahme, und jede hat einen Grund.** Die
+Buchung lässt den Verweis auf ihre Gegenbuchung eintragen — eine Stornierung
+entsteht später, sie einzutragen ist keine Änderung des Vorgangs, sondern
+seine Fortschreibung. Der Abschluss lässt den Prüfbericht nachtragen, denn das
+PDF entsteht im Hintergrund und damit nach dem Festschreiben. Ohne diese
+Ausnahme gäbe es nie einen Bericht.
+
+**Der Bestand wird gerechnet, nie gespeichert.** Ein gespeicherter Bestand
+neben einer nachgetragenen Buchung wäre falsch, ohne falsch auszusehen — und
+genau danach sucht ein Kassenprüfer. Bei den Größenordnungen einer
+Feuerwehrkasse kostet das Rechnen nichts.
+
+**Der Kategorievorschlag geht dem eigenen Bestand vor der Stichwortliste
+nach.** Wenn eine Wehr Diesel seit Jahren unter „Fahrzeuge" bucht statt unter
+„Kraftstoff", ist das ihre Entscheidung, und sie soll dabei bleiben dürfen.
+Die Stichwortliste greift erst, wenn es noch keinen Bestand gibt. Unter der
+Hälfte gemeinsamer Wörter schweigt der Vorschlag: ein falscher wird
+übernommen, ohne gelesen zu werden.
+
+**Der Bankimport erzeugt Entwürfe, keine Buchungen.** Und jeder Umsatz trägt
+eine Kennung, damit ein zweimal eingelesener Auszug als solcher erkannt wird.
+Ohne das wäre es ein doppelt gebuchter Monat, und der fiele erst beim
+Kassenabschluss auf — also drei Monate später.
+
+**Kein XML-Parser für CAMT.** Gebraucht werden sechs Felder aus einer flachen
+Struktur, die Datei kommt von der eigenen Bank. Der Parser ist kürzer als die
+Einbindung, und in einer Anwendung ohne Netzzugang ist jede Abhängigkeit
+weniger eine Sorge weniger. Namensräume werden ignoriert — genau das, was ein
+Parser hier auch täte.
+
+**In der Prüfmaske stehen die gezählten Felder leer.** Der Buchbestand ist zu
+sehen, weil der Prüfer ihn für die Differenz braucht. Vorbelegt wird nichts:
+wer erst das Buch sieht und dann zählt, zählt, bis es passt.
+
+### Wo es gehakt hat
+
+| Problem | Ursache | Lösung |
+|---|---|---|
+| Der Abschluss ließ sich nicht mit seinem Bericht versehen | Der Trigger sperrte auch `berichtDateiId` — das PDF entsteht aber erst nach dem Festschreiben | Ausnahme für genau dieses Feld, wie beim Stornierungsverweis der Buchung |
+| Die Rechnungsnummer war ein Wettlauf | Höchste lesen, dann schreiben: zwei gleichzeitige Rechnungen lesen dieselbe Nummer | Zusammenstoß erkennen und die nächste nehmen; gefunden hat es der parallele E2E-Lauf über zwei Projekte |
+| Eine Organisation ließ sich nicht mehr löschen | Der DELETE-Trigger der Buchung kannte den Aufbewahrungsschalter nicht, den Audit-Log und Prüfprotokoll haben | `app.audit_bereinigung` auch dort — ohne ihn wäre die DSGVO-Löschung nicht durchführbar |
+| Der Datenbanktest ließ sich nur einmal ausführen | Dieselbe Ursache: das Aufräumen scheiterte an den festgeschriebenen Buchungen, und der Rest lief im nächsten Lauf gegen einen geprüften Zeitraum | siehe oben |
+| E2E: „Barkasse" fand sieben Elemente | Das Wort steht auch in Verwendungszwecken | über die Kartenüberschrift angesprochen |
+| E2E: die erste Maifest-Zeile war die falsche | Absteigend sortiert steht das laufende Jahr oben, und das ist nicht festgeschrieben | eine Buchung genommen, die es nur im Vorjahr gibt — und die Gegenprobe dazu |
+| Prisma wollte zum zehnten Mal die Trigramm-Indizes aus Phase 1 löschen | Sie stehen in einer Roh-SQL-Migration, nicht im Schema | 30 DropIndex-Blöcke entfernt, Kommentar in die Migration |
+| Der volle E2E-Lauf meldete quer durch alle Module Fehler | `npm run build` während eines laufenden `next dev`: der Produktionslauf überschreibt `.next`, und der Entwicklungsserver antwortet danach nur noch mit 500 | Entwicklungsserver beenden, `.next` löschen, neu laufen lassen — 239 grün |
+| Ein E2E-Test aus Phase 0 wurde rot | Er sicherte zu, dass die Kasse **kein** Verweis ist — die Zusicherung ist mit dieser Phase abgelaufen | umgeschrieben: die Kasse ist jetzt ein Verweis. Ein künftiges Modul zum Ausgrauen gibt es nicht mehr |
+
+### Abweichung von der Vorgabe
+
+Keine. `Phase-9.md` ist vollständig umgesetzt, einschließlich CAMT.053, MT940,
+Nummernkreis, Kassenprüfbericht und Export.
+
+Der Beleg-Anhang an einer Buchung nutzt den `Belegentwurf` aus Phase 8 mit —
+er hat dafür einen `buchungId` bekommen. Fotografieren und Erfassen war
+bereits da; neu ist nur, dass daraus eine Buchung wird.
+
+### Nachweise
+
+- `npm run typecheck` — ohne Ausgabe
+- `npm run lint` — ohne Befund
+- `npm run test` — 562 Tests grün, davon 13 neu gegen eine echte Datenbank
+- `npm run test:e2e` — 239 Tests grün über Desktop und Tablet, davon 26 neue
+- `npm run build` — fünf neue Routen unter `/kasse`
+- `npm run db:seed` — Kassenjahr angelegt, Abschluss festgeschrieben
+- Rechnungs-PDF (41 kB) und Kassenprüfbericht (45 kB) einmal von Hand über
+  Gotenberg erzeugt und in MinIO abgelegt — die beiden Vorlagen haben sonst
+  keinen automatischen Nachweis
+
+---
+
+## 2026-09-04 · Aufräumarbeiten — Issues #10 bis #12
+
+**11:15 – 12:35 · 1:20 h**
+
+### Was entstanden ist
+
+Drei Punkte, die seit mehreren Phasen im Abschlussbericht standen und in jeder
+Phase Zeit gekostet haben. Diesmal als Issues angelegt und abgearbeitet.
+
+| Issue | Kern |
+|---|---|
+| #11 | ESLint hatte keine Konfiguration — `npm run lint` prüfte nichts |
+| #12 | `<div>` in einem `<p>` auf der Einsatzseite, seit Phase 3 |
+| #10 | Die E2E-Tests schrieben in die Beispielwehr |
+
+### Entscheidungen
+
+**ESLint zuerst.** Er findet die anderen beiden — und tatsächlich hat er
+gleich zwei Fehler gemeldet, die niemand gesucht hatte: eine Fehlerfläche auf
+der Karte, die nie etwas anzeigen konnte, und zwei `useMemo` in der Lagekarte,
+die bei jedem Rendern neu rechneten.
+
+**Keine Formatierungsregeln.** Die macht Prettier. Zwei Werkzeuge, die sich
+über Anführungszeichen streiten, lenken von den Regeln ab, auf die es ankommt.
+
+**Auch keine typgestützten Regeln.** `no-floating-promises` wäre für diesen
+Stack die wertvollste Regel überhaupt — sie braucht aber den Compiler bei
+jedem Lauf, und dann dauert der Lauf Minuten statt Sekunden. Bei einem
+Werkzeug, das vor jedem Commit laufen soll, ist das der falsche Tausch.
+
+**Das Badge wurde ein `<span>`, nicht der Absatz ein `<div>`.** Die Meldung
+kam von einer Stelle, aber die Ursache saß im Bauteil: ein Abzeichen ist
+Fließtext-Inhalt und gehört in ein Inline-Element. So ist auch jede künftige
+Verwendung in einem Absatz richtig, und die Darstellung ändert sich nicht —
+`inline-flex` verhält sich in beiden gleich.
+
+**Eine zweite Wehr statt Aufräumen nach dem Lauf.** Ein abgebrochener Lauf
+lässt beim Aufräumen einen Bestand zurück, den niemand erwartet. Ein
+vollständiger Neuaufbau ist der einzige Zustand, den man kennt — und der Seed
+kann ohnehin schon alles, er brauchte nur eine Kennung aus der Umgebung.
+
+**Ein Riegel gegen den eigenen Fehler.** `npm run db:test-reset` bricht ab,
+wenn die Testkennung mit der der Beispielwehr übereinstimmt. Ein Skript, das
+eine ganze Wehr löscht, braucht eine Stelle, an der es sich weigert.
+
+### Wo es gehakt hat
+
+| Problem | Ursache | Lösung |
+|---|---|---|
+| Zwei Tests fielen nach der Umstellung durch — und das war richtig so | Sie hatten die Verschmutzung gebraucht. `getByText("B 3 Wohnhausbrand", { exact: true })` traf bisher einen Einsatz aus einem früheren Testlauf, weil der kein Objekt hatte; der Einsatz aus dem Seed hat eines und steht in derselben Zelle | Anker am Zellenanfang statt Prüfung auf Gleichheit |
+| Der Kiosk-Test schrieb weiter in die Beispielwehr | `const WEHR = "ff-musterhausen"` stand fest im Test. Das Terminal merkt sich die Wehr und schreibt Mängel und Fahrten genau dorthin | Kennung aus `wehr.ts`, wie überall sonst |
+| Ein doppelt deklarierter Bezeichner rutschte durch den Typecheck | `tests/e2e` war in der `tsconfig.json` ausgeschlossen | Ausnahme entfernt. Sie hat nichts gebracht: die Dateien übersetzen sauber |
+| Die Anmeldung im Bildschirmfoto-Skript lief ins Leere | Bekannt aus Phase 7 — bei kaltem `.next` ist die Seite noch nicht hydriert | War schon behoben; hier nur wieder aufgetreten und bestätigt |
+
+### Abweichung von der Vorgabe
+
+**Issues angelegt**, obwohl CLAUDE.md das ausdrücklich verbietet („Niemals ein
+Issue anlegen"). Auf ausdrückliche Anweisung im Chat — die Regel stammt vom
+Auftraggeber, und er hat sie für diesen Vorgang aufgehoben.
+
+### Nachweise
+
+- `npx tsc --noEmit` — ohne Ausgabe, jetzt **einschließlich** `tests/e2e`
+- `npm run lint` — ohne Beanstandung
+- `npm run test` — 495 Tests grün
+- `npx playwright test` — grün gegen die Testwehr
+- Die Beispielwehr steht danach unverändert auf dem Seed-Stand: 49 Geräte,
+  8 Einsätze, 1 Atemschutzüberwachung, 19 Termine, 4 Wiki-Seiten
+
+---
+
+## 2026-09-04 · Phase 8 — Lokale KI
+
+**07:30 – 11:10 · 3:40 h · Version 0.9.0**
+
+### Was entstanden ist
+
+Ein Wiki, das man befragen kann, ein Diktat, ein Berichtsassistent, eine
+Belegerfassung — und zwei Protokolle, die belegen, was davon eine Maschine
+getan hat.
+
+| Bereich | Dateien |
+|---|---|
+| Rechnen | `lib/ki/zerlegen.ts`, `beleg-lesen.ts`, `anweisungen.ts`, `wiki.ts`, `vorgang.ts` |
+| Kanäle | `lib/integrations/llm.ts` (um Einbettungen und Bilder erweitert), `whisper.ts` |
+| Server | `server/routers/ki/wiki.ts`, `assistent.ts` |
+| Oberfläche | `app/(app)/wiki/`, `belege/`, `ki-protokoll/`, `protokoll/`; `components/ki/` |
+| Hintergrund | `worker/ki.ts`, zwei neue Auftragsarten |
+| Betrieb | `docker/postgres/Dockerfile` (PostGIS **und** pgvector), Ollama und faster-whisper im Profil `ki` |
+| Tests | 73 Unit, 14 E2E je Browser |
+
+### Entscheidungen
+
+**Nichts Maschinelles gelangt ungeprüft in einen Nachweis.** Das ist die Regel
+aus Phase-8.md, und sie bestimmt den ganzen Aufbau: jede KI-Ausgabe ist zuerst
+ein eigener Datensatz und nicht ein Feld im Zieldokument. Es gibt keine
+Funktion, die eine Ausgabe erzeugt und gleich übernimmt — wer das umgehen will,
+muss Code schreiben, und das fällt in einer Durchsicht auf.
+
+Die Datenbank hält gegen: Eingabe, Ausgabe, Modell und Art sind nach dem
+Anlegen unveränderlich, gelöscht wird nicht, und über einen Vorschlag wird
+genau einmal entschieden. Eine Absicht im Code ist eine Absicht; ein Trigger
+ist eine Zusicherung.
+
+**Kein Rückfall auf einen Anbieter.** Fehlt der eigene Endpunkt, fehlt die
+Funktion. Ein Einsatzbericht spricht über Menschen in ihrer schlechtesten
+Stunde — solche Texte gehören nirgendwo anders hin als ins Gerätehaus. Und ein
+Rückfall, der „nur im Notfall" greift, ist genau der Fall, in dem niemand
+hinsieht.
+
+**Ohne Modell bleibt alles andere benutzbar.** Das war der größte Einzelposten
+der Phase und steht in keiner Aufwandsschätzung. Vier Hinweise an vier Stellen,
+eine zweite Suche, die immer funktioniert, und vierzehn E2E-Tests, die genau
+diesen Zustand absichern — der Testlauf hat keinen Ollama daneben, und das ist
+Absicht.
+
+**Drei Modelle statt einem.** Text, Einbettungen und Bilder sind einzeln
+konfigurierbar, weil ein Rechner ohne Grafikkarte das Einbettungsmodell noch
+flott schafft, das Textmodell zäh und das Vision-Modell praktisch nicht. Eine
+Wehr kann so ihr Wiki durchsuchbar machen, ohne Berichte schreiben zu lassen.
+
+**Zerlegt wird an den Überschriften, nicht nach Zeichenzahl.** Weil die
+Fundstelle später unter der Antwort steht, und eine Fundstelle soll ein Kapitel
+sein. Dazu kommt die Überschriftenkette in den Einbettungstext: ein Abschnitt
+über „Rückzugsdruck" ohne das Wort „Atemschutz" darüber findet sich sonst
+nicht, wenn jemand nach Atemschutz fragt.
+
+**Markdown wird ohne HTML gerendert.** Der Text kommt von Anwendern. Jeder Weg
+über `dangerouslySetInnerHTML` wäre ein Weg für ein `<script>` in einer
+Dienstvorschrift; der Renderer baut React-Elemente, und ein spitzes
+Klammernpaar bleibt ein spitzes Klammernpaar.
+
+**HNSW statt IVFFlat.** IVFFlat muss auf einem gefüllten Bestand trainiert
+werden und liefert auf einer frisch angelegten Tabelle schlechte Treffer. Ein
+Wiki wächst Seite für Seite — es gibt nie den Moment, an dem man den Index
+einmal aufbaut.
+
+**Ein eigenes Postgres-Image.** pgvector und PostGIS gibt es nicht zusammen.
+Die Alternative wäre gewesen, den Kosinusabstand in TypeScript zu rechnen: geht
+bei zweihundert Wiki-Seiten, wird bei zweitausend zäh, und verlegt eine Aufgabe
+in die Anwendung, für die die Datenbank einen Index hat.
+
+**Die Audit-Log-Ansicht kam mit dazu.** Sie stand seit Phase 0 als ausgegrauter
+Eintrag in der Navigation, markiert mit „ab Phase 8". Mit dem KI-Protokoll
+daneben wäre es schief geworden: die Wehr könnte nachlesen, was die Maschine
+getan hat, aber nicht, was Menschen getan haben. Der Router dafür existierte
+seit Phase 0 — es fehlte nur die Seite.
+
+### Wo es gehakt hat
+
+| Problem | Ursache | Lösung |
+|---|---|---|
+| Ein kurzer Abschnitt wurde unter eine fremde Überschrift gehängt | Die Regel „zu kurz → an den vorherigen anhängen" kannte keine Kapitelgrenze. Unter einer Antwort hätte dann eine Fundstelle gestanden, in der der zitierte Satz gar nicht vorkommt | Zusammengezogen wird nur innerhalb desselben Überschriftenpfads. Gefunden hat es der Test, nicht das Ausprobieren |
+| `prisma migrate dev` wollte die Datenbank zurücksetzen | Die zurückgerollte Migration aus Phase 7 stand noch in `_prisma_migrations` und galt als „applied but missing" | Die Zeile entfernt. Ein `migrate resolve --rolled-back` räumt sie nicht weg |
+| Prisma wollte wieder die Volltextindizes abräumen | Bekannt seit Phase 1, achte Migration in Folge | 27 DropIndex-Blöcke entfernt, im Kopf der Migration vermerkt |
+| Die abgeleiteten Typen der Oberfläche waren `{}` | `ReturnType<typeof useQuery>["data"]` funktioniert bei tRPC nicht | `inferRouterOutputs<AppRouter>` — wie schon in Phase 7 |
+
+### Abweichung von der Vorgabe
+
+**Das Wiki hat keine Bilder.** Phase-8.md nennt sie nicht, aber man erwartet
+sie in einem Wiki. Sie fehlen bewusst: ein Bild in einer Seite wäre entweder
+eine Datei in MinIO mit eigener Rechteprüfung beim Ausliefern, oder ein Verweis
+auf einen fremden Server — und Letzteres verbietet die Grundregel, dass FLORIAN
+nichts von außen nachlädt. Nachrüstbar, wenn eine Wehr es vermisst.
+
+**Kein Streaming der Modellantwort.** Der Bericht erscheint am Stück, nicht Wort
+für Wort. Das sähe moderner aus, ist hier aber falsch: der Text soll gelesen und
+gegengezeichnet werden, nicht beim Entstehen bewundert. Und ein halb geschriebener
+Entwurf, den jemand vorzeitig übernimmt, wäre genau die Lücke, die diese Phase
+schließen soll.
+
+### Nachweise
+
+- `npx tsc --noEmit` — ohne Ausgabe
+- `npm run test` — 495 Tests grün, davon 21 neue gegen eine echte Datenbank
+- `npx playwright test tests/e2e/wissen.spec.ts` — 14 grün, ohne laufendes Modell
+- `npm run build` — 56 Routen
+- `npm run db:seed` — vier Wiki-Seiten mit eigenem Text
+- `docker compose build postgres` — PostGIS 3.5 und pgvector 0.8.6 im selben Image
+- `docker compose config` — Ollama und faster-whisper im Profil `ki` prüfen durch
 
 ---
 

docs/KURZANLEITUNG.md

@@ -0,0 +1,283 @@
+# FLORIAN — Kurzanleitung
+
+Alles, was man am Anfang braucht, auf ein paar Seiten. Nach Rollen sortiert:
+such dir den Abschnitt, der zu dir gehört, und lies den Rest später.
+
+Ausführlich steht alles in der [Anleitung](ANLEITUNG.md) — 63 Kapitel, zum
+Nachschlagen, nicht zum Durchlesen.
+
+---
+
+## Für alle
+
+### Anmelden
+
+FLORIAN läuft im Browser. Die Adresse bekommst du vom Kommandanten.
+
+![Anmeldung](screenshots/01-anmeldung-light.png)
+
+Nach der Anmeldung landest du auf der Übersicht: was ansteht, was fällig ist,
+was gemeldet wurde.
+
+**Das Passwort gehört nach der ersten Anmeldung geändert.** Oben rechts auf
+deinen Namen.
+
+### Was du überall findest
+
+| Links in der Leiste | Wofür |
+|---|---|
+| **Übersicht** | Die Startseite: Fristen, Mängel, nächste Termine |
+| **Termine** | Übungsabende, Lehrgänge, Versammlungen — mit Rückmeldung |
+| **Dienstausweis** | Dein Ausweis mit QR-Code, auch fürs Handy |
+| **Wissen** | Merkblätter und Dienstanweisungen der Wehr |
+
+Du siehst nur, was zu deiner Rolle gehört. Fehlt dir etwas, sag dem
+Kommandanten Bescheid — Rollen werden dort vergeben.
+
+### Zu einem Termin zurückmelden
+
+**Termine** öffnen, den Termin anklicken, **Zusagen** oder **Absagen**. Fertig.
+Wer absagt, kann einen Grund angeben; das hilft dem Ausbilder bei der Planung.
+
+### Am Terminal im Gerätehaus
+
+Am Wandtablet meldest du dich mit **PIN oder Ausweiskarte** an — nicht mit
+E-Mail und Passwort. Deine PIN bekommst du vom Kommandanten.
+
+![Terminal](screenshots/25-kiosk-kacheln-light.png)
+
+Dort geht: anmelden zum Dienst, einen Mangel melden, eine Fahrt eintragen,
+Schutzkleidung zur Reinigung geben.
+
+---
+
+## Für den Gerätewart
+
+Das ist der Bereich, in dem FLORIAN am meisten abnimmt.
+
+### Der wichtigste Bildschirm: Prüfungen
+
+![Fristen](screenshots/11-fristen-light.png)
+
+Unter **Prüfungen** steht, was wann fällig wird. Rot heißt überfällig, gelb
+heißt demnächst. Die Fristen rechnet FLORIAN selbst aus den Prüfintervallen
+der Gerätetypen aus — du musst nichts nachhalten.
+
+### Ein Gerät prüfen
+
+1. **Prüfungen** → das fällige Gerät anklicken → **Prüfung durchführen**.
+2. Die Checkliste durchgehen. Sie kommt aus der Wartungsvorlage des Gerätetyps.
+3. Ergebnis eintragen, unterschreiben, abschließen.
+
+![Prüfprotokoll](screenshots/18-pruefprotokoll-light.png)
+
+Danach entsteht ein **Prüfprotokoll als PDF** — das ist der Nachweis gegenüber
+der Unfallkasse.
+
+> **Achtung:** Ein abgeschlossenes Protokoll lässt sich nicht mehr ändern. Das
+> ist Absicht — ein nachträglich änderbarer Nachweis wäre keiner. Ist etwas
+> falsch, wird eine neue Prüfung erfasst.
+
+### Ein Gerät anlegen
+
+**Geräte** → **Gerät anlegen**. Pflicht sind nur Inventarnummer und
+Bezeichnung; der Rest kann nachkommen.
+
+Wähle möglichst einen **Gerätetyp** — daran hängen Prüfintervall und
+Lebensdauer, und ohne Typ rechnet FLORIAN keine Frist.
+
+### Einen Mangel bearbeiten
+
+Mängel kommen meist vom Terminal — jemand meldet sie beim Einrücken.
+
+**Mängel** → anklicken → jemandem zuweisen → nach der Behebung **erledigen**.
+Ein Gerät mit einem schweren Mangel wird automatisch gesperrt.
+
+### Was noch dazugehört
+
+| Wo | Wofür |
+|---|---|
+| **Rückrufe** | Herstellerrückrufe: welche eurer Geräte betroffen sind |
+| **Lebensdauer** | Helme, Schläuche, Schutzkleidung mit Höchstalter |
+| **Fahrzeuge** | Beladung nach Geräteräumen |
+
+---
+
+## Für den Atemschutzgerätewart
+
+> **Der wichtigste Satz zuerst:** Die Überwachungstafel am Fahrzeug bleibt
+> führend. FLORIAN ergänzt sie, ersetzt sie nicht. Das steht auch dauerhaft
+> über jeder Ansicht, und es soll dort stehen.
+
+### Wer darf unter Pressluftatmer?
+
+![Atemschutz](screenshots/31-atemschutz-light.png)
+
+**Atemschutz** zeigt jeden Träger mit seinem Stand: G26, Belastungsübung,
+Einsatzübung. Wer eine der Voraussetzungen nicht erfüllt, steht rot da — mit
+Klartext, woran es liegt, nicht nur mit einer Farbe.
+
+### Eine G26 eintragen
+
+**Atemschutz** → **Nachweise** → Person wählen → G26 erfassen. Untersuchungs­datum,
+Ergebnis und Gültigkeit reichen; den Befund speichert FLORIAN bewusst nicht.
+
+Dasselbe für Belastungsübungen.
+
+### Eine Überwachung führen
+
+**Atemschutz** → **Überwachung eröffnen**. Trupp zusammenstellen, Druckwerte
+in Intervallen eintragen, Rückzugsdruck im Blick behalten. FLORIAN rechnet den
+Rückzugsdruck und warnt, bevor es knapp wird.
+
+![Überwachung](screenshots/33-atemschutz-ueberwachung-light.png)
+
+Nach dem Ende entsteht ein vollständiges Protokoll als PDF.
+
+> Solange ein Trupp im Einsatz ist, lässt sich die Überwachung nicht beenden.
+
+---
+
+## Für den Kommandanten
+
+### Mitglieder und Rollen
+
+**Mitglieder** → Person anklicken → Rollen vergeben.
+
+Neun Rollen, jede mit festem Rechteumfang. Die wichtigsten: Gerätewart,
+Atemschutzgerätewart, Kassier, Schriftführer, Ausbilder.
+
+**Jemand kommt nicht hinein?** Dann hat die Person eine Akte, aber kein Konto.
+Konten verwaltet, wer den Server betreibt — unter *Wehren und Konten*.
+
+### Einen Einsatz erfassen
+
+**Einsätze** → **Einsatz anlegen**. Die sechs Zeitstempel (Alarmierung,
+Ausrücken, Eintreffen, Einsatzende, Einrücken, Einsatzbereitschaft), die
+beteiligten Fahrzeuge und die Mannschaft.
+
+![Einsatz](screenshots/22-einsatz-light.png)
+
+Daraus entsteht der **Einsatzbericht als PDF** und die Statistik fürs Jahr.
+
+### Kostenersatz abrechnen
+
+Fehlalarm einer Brandmeldeanlage, Öleinsatz mit Verursacher, vermieteter
+Schulungsraum: **Kasse** → **Rechnungen** → *Rechnung schreiben*. Die Nummer
+vergibt FLORIAN fortlaufend.
+
+### Wenn jemand Auskunft über seine Daten verlangt
+
+Kommt selten vor, hat aber eine Frist von einem Monat.
+
+**Mitglieder** → Person → **Datenauskunft** → *Auskunft erstellen*. Daraus
+entsteht ein PDF mit allem, was über die Person gespeichert ist. Ausdrucken
+und aushändigen, fertig.
+
+---
+
+## Für den Kassier
+
+![Kasse](screenshots/45-kasse-light.png)
+
+### Buchen
+
+**Kasse** → **Buchungen** → *Buchung erfassen*. Der Betrag ist immer positiv;
+ob Einnahme oder Ausgabe, sagen die beiden Knöpfe daneben.
+
+FLORIAN schlägt eine Kategorie vor — meist die richtige, weil er nachsieht,
+wie ihr dieselbe Sache zuletzt gebucht habt.
+
+### Kontoauszug einlesen
+
+Statt fünfzig Umsätze abzutippen: im Online-Banking den **Umsatzexport**
+herunterladen (CAMT.053 oder MT940), dann **Kasse** → **Buchungen** →
+*Kontoauszug*.
+
+Es entstehen **Entwürfe**, keine fertigen Buchungen — durchsehen musst du sie.
+Umsätze, die schon in der Kasse stehen, erkennt FLORIAN und hakt sie nicht
+noch einmal ab.
+
+### Beiträge
+
+Einmal im Jahr: **Kasse** → **Beiträge** → *Beitragslauf*. Vorher steht da, wie
+viele Beiträge entstehen — und wer keinen passenden Satz hat.
+
+Zahlungen hakst du in der Liste ab; dabei entsteht gleich die Buchung.
+
+### Festschreiben — und was das bedeutet
+
+Eine neue Buchung ist erst einmal ein **Entwurf** und änderbar. Mit
+*Festschreiben* wird sie unveränderbar.
+
+Ist danach etwas falsch, wird **gegengebucht**: eine zweite Buchung in die
+andere Richtung, mit Begründung. Beide bleiben stehen. Das sieht nach mehr
+Aufwand aus und ist genau der Punkt — eine verschwundene Buchung kann ein
+Kassenprüfer nicht prüfen, eine berichtigte schon.
+
+### Kassenprüfung
+
+**Kasse** → **Abschluss** → *Kassenprüfung anlegen*. Links steht der Bestand
+laut Buch, rechts trägst du ein, was gezählt wurde.
+
+Bleibt eine Differenz, muss sie erklärt werden — sonst lässt sich der Abschluss
+nicht festschreiben. In fünf Jahren weiß sonst niemand mehr, woher sie kam.
+
+Danach entsteht der **Kassenprüfbericht als PDF** mit Unterschriftsfeldern.
+
+---
+
+## Für den, der den Server betreibt
+
+### Sichern
+
+```bash
+npm run sicherung
+```
+
+Sichert Datenbank **und** Dateien. Das Ergebnis gehört auf ein anderes Gerät —
+eine Sicherung auf derselben Festplatte hilft gegen einen Festplattenfehler
+nicht.
+
+### Einmal im Jahr proben
+
+```bash
+npm run wiederherstellen -- --quelle sicherungen/<Ordner>
+```
+
+So passiert nichts, es wird nur angezeigt, was geschähe. Erst mit `--wirklich`
+wird zurückgespielt.
+
+> Eine Sicherung, die nie zurückgespielt wurde, ist eine Vermutung. Der Ordner
+> kann leer sein, der Auszug abgeschnitten — man erfährt es sonst an dem Tag,
+> an dem man es nicht erfahren will.
+
+### Aktualisieren
+
+```bash
+./update.sh --pruefen    # nachsehen, ob es etwas Neues gibt
+./update.sh              # einspielen
+```
+
+Das Skript sichert von sich aus, bevor es etwas anfasst, und sagt bei einem
+Fehler, wie der vorherige Stand zurückkommt.
+
+---
+
+## Wenn etwas nicht geht
+
+| Was | Woran es meist liegt |
+|---|---|
+| **Anmeldung geht nicht** | Nach fünf Fehlversuchen ist das Konto fünf Minuten gesperrt. Kurz warten. |
+| **Ein Menüpunkt fehlt** | Die Rolle fehlt. Der Kommandant vergibt sie unter *Mitglieder*. |
+| **Ein PDF entsteht nicht** | Es wird im Hintergrund erzeugt; nach ein paar Sekunden die Seite neu laden. |
+| **Das Terminal meldet niemanden an** | PIN falsch, oder das Tablet ist nicht mehr eingerichtet. |
+| **Eine Buchung lässt sich nicht ändern** | Sie ist festgeschrieben. Gegenbuchen. |
+
+Steht die Antwort nicht dabei: [Anleitung, letztes Kapitel](ANLEITUNG.md).
+
+---
+
+*FLORIAN läuft auf einem Server, den die Feuerwehr selbst betreibt. Es gibt
+keine Telemetrie, keine Cloud und keine Weitergabe an Dritte — die Daten
+bleiben im Gerätehaus.*

docs/ROADMAP.md

@@ -17,9 +17,11 @@ Phase 4  ████████████████████  fertig
 Phase 5  ████████████████████  fertig      0.6.0
 Phase 6  ████████████████████  fertig      0.7.0
 Phase 7  ████████████████████  fertig      0.8.0
-Phase 8  ░░░░░░░░░░░░░░░░░░░░  als Nächstes 0.9.0
-Phase 9  ░░░░░░░░░░░░░░░░░░░░  offen       0.10.0
-Freigabe ░░░░░░░░░░░░░░░░░░░░  offen       1.0.0
+Phase 8  ████████████████████  fertig      0.9.0
+Phase 9  ████████████████████  fertig      0.10.0
+Phase 10 ████████████████████  fertig      0.11.0
+Phase 11 ████████████████████  fertig      0.12.0
+Freigabe ████████████████████  fertig      1.0.0
 ```
 
 ---
@@ -194,19 +196,47 @@ selbst gehostet.
 Wer seine Wehr trotzdem über WhatsApp erreichen will, hat den Weg schon: die
 Gruppe, die es ohnehin gibt. Ein Link zum Termin hineinkopiert kostet nichts.
 
-## Phase 8 — Lokale KI · als Nächstes
+## Phase 8 — Lokale KI · fertig
 
-Alles gegen Ollama, kein externer Anbieter, komplett abschaltbar.
+Alles gegen selbst betriebene Modelle, kein externer Anbieter, komplett
+abschaltbar.
 
-- Diktat: Aufnahme im Browser → faster-whisper → Transkript im Berichtsfeld
-- Berichtsassistent: aus Stichpunkten einen Entwurf, immer als Vorschlag
-- Wiki mit pgvector: semantische Suche mit Quellenangabe
-- Belegerfassung: Foto einer Quittung → Vorschlag für Betrag, Datum, Händler
+- Wiki mit pgvector: Dienstvorschriften und Ausbildungsunterlagen als Markdown,
+  Wortsuche und semantische Suche nebeneinander, Antwort mit Fundstellenangabe
+- Diktat: Aufnahme im Browser, faster-whisper, Transkript als Vorschlag
+- Berichtsassistent: aus Stichpunkten ein Einsatzberichtsentwurf, immer mit
+  Übernehmen/Verwerfen
+- Belegerfassung: Foto einer Quittung, Vorschlag für Betrag, Datum, Händler —
+  nicht Erkanntes bleibt leer statt geraten zu werden
+- KI-Protokoll und Audit-Log-Ansicht nebeneinander
+- Eigenes Postgres-Image mit PostGIS **und** pgvector
 
-Jede KI-Ausgabe ist gekennzeichnet und muss bestätigt werden, bevor sie in ein
-Dokument mit Nachweischarakter gelangt.
+**Danach kann die Wehr:** ihr Wissen ablegen und befragen, Berichte diktieren
+statt tippen und Belege fotografieren statt abzuschreiben — ohne dass eine
+Zeile Text das Gerätehaus verlässt.
 
-## Phase 9 — Kassenverwaltung
+### Die Regel, die den Aufbau bestimmt
+
+Jede KI-Ausgabe ist zuerst ein eigener Datensatz und nicht ein Feld im
+Zieldokument. Sie ist gekennzeichnet, sie steht daneben statt mittendrin, und
+sie braucht eine Entscheidung, bevor etwas mit ihr geschieht. Die Datenbank
+hält gegen: Eingabe, Ausgabe und Modell sind unveränderlich, gelöscht wird
+nicht, und über einen Vorschlag wird genau einmal entschieden.
+
+Ohne das ließe sich in einem Jahr nicht mehr sagen, welcher Satz in einem
+Einsatzbericht von einem Menschen stammt.
+
+### Kein Rückfall auf einen Anbieter
+
+Fehlen die Container, fehlt die Funktion — sie wird nicht durch einen fremden
+Dienst ersetzt. Das ist die einzige Bauart, bei der der Satz „die Daten bleiben
+im Haus" auch dann noch stimmt, wenn der eigene Server aus ist.
+
+Dafür bleibt **alles andere ohne Modell vollständig benutzbar**: Wiki lesen und
+schreiben, Wortsuche, Belege ablegen, beide Protokolle. Wo etwas fehlt, steht
+ein Satz, der sagt was fehlt und wie es ohne geht.
+
+## Phase 9 — Kassenverwaltung · fertig
 
 Am 03.09.2026 ergänzt. Die Rolle `KASSIER` war seit Phase 0 angelegt, ein Modul
 dazu fehlte in der ursprünglichen Planung. Spezifikation: `Phase-9.md`.
@@ -225,20 +255,92 @@ Kassenabschluss friert seinen Zeitraum ein, danach nimmt die Buchungsmaske
 kein Datum daraus mehr an. Beträge durchgängig als `DECIMAL(12,2)`, nie als
 Fließkommazahl.
 
-**Danach kann die Wehr:** ihre Kasse führen und den Kassenprüfbericht auf
+Beides sitzt in Triggern und nicht im Router: ein vergessener Zustandscheck,
+ein Skript oder ein Import würden sonst reichen, um den geprüften Bestand zu
+ändern, ohne dass irgendwo etwas auffällt.
+
+**Die Wehr kann jetzt:** ihre Kasse führen und den Kassenprüfbericht auf
 Knopfdruck erzeugen.
 
-## 1.0.0 — Freigabe
+## Phase 10 — Mandantenfähigkeit · fertig
+
+Am 05.09.2026 ergänzt. Datenmodell und RLS trugen seit Phase 0 mehrere Wehren;
+was fehlte, war alles darüber.
+
+- `Benutzer` und `Mitgliedschaft`: das Anmeldekonto ist von der Personenakte
+  gelöst. Ein Mensch, ein Passwort, beliebig viele Wehren.
+- Wehrwähler in der Seitenleiste — er erscheint nur, wenn es etwas zu wählen
+  gibt.
+- Die Rolle `AUFSICHT` für die Kreisebene: Kreisbrandrat und
+  Kreisbrandinspektion sehen die betreuten Wehren und ändern nichts.
+- Verwaltung der Installation unter `/wehren`: Wehren anlegen, Konten führen,
+  Zuordnungen vergeben.
+
+Die Entscheidung, die alles andere bestimmt: **das Konto trägt keine
+Mandantenkennung.** Es kann keine tragen — es ist ja der Angelpunkt, an dem
+ein Mensch zu mehreren Wehren gehört. Geschützt wird es deshalb wie
+`Berechtigung` über Rechte statt über Row Level Security, und was ein Konto in
+einer Wehr darf, entscheidet nicht es selbst, sondern seine `Mitgliedschaft` —
+und die trägt `organisationId` wie jede andere Tabelle.
+
+**Bewusst nicht dabei:** wehrübergreifende Auswertungen. Eine Zahl über
+mehrere Wehren hinweg braucht eine abgestimmte Definition, und ohne die ist
+sie schlimmer als keine. Die Aufsicht sieht jede Wehr einzeln.
+
+**Die Wehr kann jetzt:** sich einen Server mit anderen teilen, ohne dass
+jemand über die Grenze sieht — und die Kreisebene kann hineinschauen, ohne
+etwas anfassen zu können.
+
+## Phase 11 — Freigabereife · fertig
+
+Am 05.09.2026 umgesetzt. Kein Modul, sondern die drei Software-Voraussetzungen
+für die Freigabe.
+
+- **Auskunft nach Art. 15 DSGVO.** Das Recht `person.export` stand seit Phase 0
+  im Katalog und war zugewiesen — umgesetzt war nichts. Ohne Auskunftsseite ist
+  ein Löschkonzept nicht abnehmbar.
+- **Sicherung und Wiederherstellung** mit einer durchgeführten Rückspielprobe.
+- **Pipeline** in Gitea Actions: typecheck, lint, Migrationen, Seed und Tests.
+
+Die Rückspielprobe hat sich sofort bezahlt gemacht: der erste Versuch lief
+sauber durch und hatte dabei sämtliche Unveränderlichkeitsgarantien der
+Datenbank entfernt. Gefunden haben es die Datenbanktests unmittelbar danach —
+also genau die Probe, wegen der 1.0.0 sie verlangt.
+
+**Die Wehr kann jetzt:** eine Selbstauskunft erteilen, ihren Bestand sichern
+und ihn nachweislich zurückholen.
+
+## 1.0.0 — Freigabe · am 06.09.2026 erteilt
 
 Kein neues Modul, sondern eine Entscheidung: die Wehr setzt FLORIAN im
-Echtbetrieb ein. Voraussetzungen:
+Echtbetrieb ein.
 
-- Datenübernahme aus der bisherigen Verwaltung abgeschlossen und abgeglichen
-- Sicherungskonzept steht und ist einmal wiederhergestellt worden
-- Schulung von Kommandant, Gerätewart und Atemschutzgerätewart erfolgt
-- Löschkonzept nach DSGVO abgenommen
-- Der Hinweis zur analogen Atemschutzüberwachung wird bewusst und
-  dokumentiert abgeschaltet — oder bewusst stehen gelassen
+**Damit das nicht zur Formalie wird, hier der Stand jeder Voraussetzung — auch
+der offenen.** Eine Freigabe, die alles abhakt, was ohnehin nicht geprüft
+wurde, ist keine.
+
+| Voraussetzung | Stand |
+|---|---|
+| Datenübernahme aus der bisherigen Verwaltung | **entfällt.** Die Wehr pflegt den Bestand von Hand ein; es gibt kein Altsystem, aus dem übernommen würde. Für Mitglieder, Fahrzeuge und Geräte steht der Import-Assistent bereit, falls sich das ändert. |
+| Sicherungskonzept steht und ist einmal wiederhergestellt worden | **erledigt** mit Phase 11. Die Probe hat dabei einen Fehler gefunden, der sonst erst im Notfall aufgefallen wäre. |
+| Löschkonzept nach DSGVO | **technisch vollständig** seit Phase 11: Auskunft nach Art. 15, Anonymisierung im Aufbewahrungslauf, konfigurierbare Fristen. Die Abnahme durch die Wehr ist ein organisatorischer Schritt und steht aus. |
+| Schulung von Kommandant, Gerätewart und Atemschutzgerätewart | **steht aus.** Sie läuft nach der Freigabe; Grundlage ist die [Kurzanleitung](KURZANLEITUNG.md). |
+| Hinweis zur analogen Atemschutzüberwachung | **bewusst stehen gelassen.** `ATEMSCHUTZ_HINWEIS=true`. FLORIAN bleibt damit ergänzend; die Tafel am Fahrzeug ist führend. Das Abschalten verlangt ohnehin einen Kommandantenbeschluss samt Fundstelle. |
+
+Die beiden offenen Punkte sind **organisatorisch, nicht technisch**: an der
+Software hängt nichts davon ab. Sie stehen hier, damit später nachlesbar ist,
+was zum Zeitpunkt der Freigabe erledigt war und was nicht.
+
+### Was 1.0.0 bedeutet — und was nicht
+
+**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.
+
+**Bedeutet nicht:** dass keine Fehler mehr da sind. Es bedeutet, dass die
+Wehr echte Daten hineingeben kann, ohne befürchten zu müssen, sie beim
+nächsten Update zu verlieren.
 
 ---
 
@@ -248,8 +350,11 @@ Am 03.09.2026 entschieden:
 
 | Punkt | Entscheidung |
 |---|---|
-| Kassenmodul | Wird als **Phase 9** ergänzt. Spezifikation in `Phase-9.md`, Aufwand 8–11 PT. |
+| Kassenmodul | Als **Phase 9** ergänzt und mit 0.10.0 umgesetzt. Spezifikation in `Phase-9.md`. |
 | `Berechtigung` ohne `organisationId` | Bleibt so. Die Tabelle ist der systemweite Katalog dessen, was die Software kann, für alle Wehren identisch — mandantenbezogen wird es erst über `RolleBerechtigung`. Für die Anwendungsrolle nur lesbar. |
+| `Benutzer` ohne `organisationId` | Notwendige Ausnahme, seit Phase 10. Die Tabelle ist der Angelpunkt der Doppelmitgliedschaft — mit Mandantenkennung könnte sie das nicht sein. Geschützt über Rechte statt RLS, wie `Berechtigung`: die Anwendungsrolle darf lesen und die Anmeldefelder fortschreiben, mehr nicht. |
+| `AUFSICHT` nicht im Prisma-Enum | Die Kreisebene ergibt sich aus der Mitgliedschaftsart, nicht aus einer Rollenzuweisung. Vergebbar zu machen hiesse, dass jemand innerhalb einer Wehr Rechte an einer anderen verteilen könnte. |
+| `istVerwalter` als Kontomerkmal | Kein Recht. Rechte gelten je Wehr; wer Wehren anlegt, steht über allen. Ein Recht, das in Wehr A vergeben wird und in Wehr B wirkt, wäre die Hintertür, die Phase 10 vermeiden soll. |
 | Löschausnahme im Audit-Log | Bleibt so. `UPDATE` ist dauerhaft gesperrt, `DELETE` nur mit `SET LOCAL app.audit_bereinigung = 'an'` im Aufbewahrungslauf des Workers. Ohne diese Ausnahme wäre das Löschkonzept nach DSGVO nicht umsetzbar. |
 
 ## Weitere Kandidaten für später
@@ -260,10 +365,8 @@ Am 03.09.2026 entschieden:
 | Kleiderkammer und Wäscheverwaltung | in Phase 4 nur als Wizard, ohne Bestandsführung | 4–6 PT |
 | Jugendfeuerwehr mit eigener Abzeichenverwaltung | eigene Fachlichkeit | 5–7 PT |
 | Schnittstelle zur Integrierten Leitstelle | Alarmdaten automatisch übernehmen | 6–10 PT, stark abhängig von der ILS |
-| Mehrere Wehren je Installation | technisch bereits möglich, Oberfläche fehlt | 4–6 PT |
 
-Die Mandantenfähigkeit ist der Punkt, der ohne Zusatzaufwand am weitesten
-trägt: das Datenmodell und RLS können bereits mehrere Wehren. Was fehlt, ist
-eine Oberfläche zum Umschalten und ein Konzept für gemeindeübergreifende
-Auswertungen. Für einen Landkreis, der mehrere Wehren betreiben will, wäre das
-der nächste sinnvolle Schritt.
+Die Mandantenfähigkeit ist mit **Phase 10** umgesetzt: umschalten, Kreisebene,
+Doppelmitgliedschaft, Verwaltung. Offen geblieben sind bewusst die
+gemeindeübergreifenden Auswertungen — dafür braucht es zuerst eine abgestimmte
+Definition dessen, was verglichen werden soll.