Phase 10: Mandantenfaehigkeit

Ein Server, mehrere Wehren. Ein Konto, mehrere Zugehoerigkeiten. Eine
Kreisebene, die zusieht.

Datenmodell und RLS trugen seit Phase 0 mehrere Wehren. Was fehlte, war
alles darueber: bis hierher war die Personenakte zugleich das Anmeldekonto,
und die gehoert genau einer Wehr. Wer in zweien gefuehrt wurde, brauchte
zwei Passwoerter, und die Anmeldung per E-Mail war mehrdeutig.

Neu sind `Benutzer` (das Konto) und `Mitgliedschaft` (die Zugehoerigkeit).
Das Konto traegt bewusst keine Mandantenkennung und kann keine tragen - es
ist der Angelpunkt, an dem ein Mensch zu mehreren Wehren gehoert. Geschuetzt
wird es deshalb ueber Rechte statt ueber RLS, wie `Berechtigung` seit Phase
0. Was es in einer Wehr darf, entscheidet seine Mitgliedschaft.

Die Sitzung behaelt ihre Form und entsteht nur anders - aus der aktiven
Mitgliedschaft statt aus der Person. Von 414 Fundstellen in 61 Dateien
musste dadurch keine angefasst werden. Die eine Ausnahme ist Absicht:
`personId` ist nullbar geworden, weil eine Aufsichtssitzung keine Akte hat,
und der Typechecker hat daraus genau die fuenf Stellen gemacht, an denen
die Kreisaufsicht nichts verloren hat.

Ihre Rechte werden gefiltert statt aufgezaehlt: alles, was `.lesen` heisst,
minus Kasse, Audit-Log, KI-Protokoll und Personenexport. So bekommt sie
neue Leserechte automatisch und neue Schreibrechte nie.

Die Migration ist datenerhaltend und bricht ab, statt einen halben Zustand
zu hinterlassen.

Nebenbei behoben: `db:test-reset` liess die Nachbarwehr stehen, der
Fehlversuch-Test sperrte das gemeinsame Testkonto, ein Testaufbau war
nicht wiederholbar, und die Wartelogik der Bildschirmfotos konnte
ausloesen, bevor eine Seite ueberhaupt geladen war.

581 Unit-Tests und 266 E2E-Tests gruen.

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

docs/ROADMAP.md

@@ -19,6 +19,7 @@ Phase 6  ████████████████████  fertig
 Phase 7  ████████████████████  fertig      0.8.0
 Phase 8  ████████████████████  fertig      0.9.0
 Phase 9  ████████████████████  fertig      0.10.0
+Phase 10 ████████████████████  fertig      0.11.0
 Freigabe ░░░░░░░░░░░░░░░░░░░░  offen       1.0.0
 ```
 
@@ -260,6 +261,35 @@ ein Skript oder ein Import würden sonst reichen, um den geprüften Bestand zu
 **Die Wehr kann jetzt:** ihre Kasse führen und den Kassenprüfbericht auf
 Knopfdruck erzeugen.
 
+## 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.
+
 ## 1.0.0 — Freigabe
 
 Kein neues Modul, sondern eine Entscheidung: die Wehr setzt FLORIAN im
@@ -282,6 +312,9 @@ Am 03.09.2026 entschieden:
 |---|---|
 | 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
@@ -292,10 +325,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.