docs: Etappe 2 der Mandantentrennung abgeschlossen — alle zwoelf Bereiche gebunden und verifiziert

.planning/.continue-here.md

@@ -1,13 +1,13 @@
 ---
 context: default
-phase: mandantentrennung-etappe-2
+phase: mandantentrennung-etappe-3
 task: null
-total_tasks: 3
+total_tasks: 5
 status: paused
-last_updated: 2026-09-09T09:16:11.548Z
+last_updated: 2026-09-11T13:00:00.000Z
 ---
 
-# Wiedereinstieg — Mandantentrennung, vor Etappe 2
+# Wiedereinstieg — Mandantentrennung, ETAPPE 2 ABGESCHLOSSEN, vor WINDOWS #27 und Etappe 3
 
 ## Critical Anti-Patterns
 
@@ -21,15 +21,21 @@ Alle vier stammen aus tatsaechlichen Fehlschlaegen dieser Sitzung, nicht aus Vor
 | Zeichensatz beim Veroeffentlichen angenommen | Die Handbuch-Webseite ging mit zerlegten Umlauten live ("Für" statt "Fuer"), weil im lokalen Test der Zeichensatz fehlte und ich annahm, das Veroeffentlichen setze ihn schon richtig. | advisory | Seiten mit deutschem Text als reines ASCII ausliefern (Sonderzeichen als `\uXXXX` in den Daten). Dann kann kein Zeichensatz sie falsch auslegen. Die fertige Datei mit `all(ord(c)<128 ...)` pruefen. |
 
 <current_state>
-Etappe 1 der Mandantentrennung ist abgeschlossen, committet und gepusht (`5228f28`).
-Der Arbeitsbaum ist sauber, die CI gruen, 701 Tests gruen.
+**Etappe 2 ist am 2026-09-11 abgeschlossen.** Alle zwoelf Bereiche sind gebunden und
+einzeln verifiziert (ldap, groups, tenders, dkv, user, module-registry, dashboard,
+calendar, tenant, auth, favorites+settings); die drei Datenbankregeln wurden auf
+Anweisung des Users vorgezogen (260910-jab). Endstand: 994 Tests in 62 Dateien
+(Ausgang 701/53), 137 Live-Pruefungen (Ausgang 8), 65 Paare / 68 ungebunden /
+178 gebunden — jeder ungebundene Zugriff liegt auf einer plattformglobalen Tabelle
+oder einem benannten Startpfad. Alles gepusht, Arbeitsbaum sauber.
 
-Die Sitzung lief ueber Quick-Tasks, nicht ueber Phasen — es gibt daher kein
-aktives Phasenverzeichnis. Der Meilenstein v1.2 ist seit dem 2026-09-07 zu, ein
-neuer wurde nicht begonnen.
+**Der Umstellungsschalter ist AUS.** `DATABASE_URL` zeigt weiter auf die Rolle
+`tessera` mit BYPASSRLS. Der User hat ausdruecklich verlangt, beim Scharfschalten
+angehalten und gefragt zu werden.
 
-Der Umstellungsschalter ist AUS: `DATABASE_URL` zeigt weiterhin auf die Rolle
-`tessera` mit BYPASSRLS. Das ist Absicht — siehe Sperrgrund unten.
+Die maschinelle Bestandsaufnahme hat eine bekannte Blindstelle (WINDOWS #27):
+`include:`/`_count:` in fremd geschuetzte Tabellen sieht sie nicht. Alle heutigen
+Instanzen sind einzeln geprueft; der Mechanismus muss VOR Etappe 4 geschlossen werden.
 </current_state>
 
 <completed_work>
@@ -132,10 +138,15 @@ dafuer ist jeder Code, der Leere als Abwesenheit deutet und daraufhin loescht. V
 Umstellung eines Bereichs ist zu pruefen, ob er solchen Code enthaelt.
 
 <next_action>
-Etappe 2 beginnen, und zwar NICHT mit dem groessten Bereich. Einstieg ist `ldap`
-(21 Zugriffe, davon 9 bereits mandantengebunden): dort sitzt der gefaehrlichste
-Loeschzweig, die Wirkung ist dort am besten pruefbar, und der Bereich ist klein genug
-fuer einen Durchlauf. Danach `groups` (37), dann `tenders` (62).
+1. WINDOWS #27 schliessen — Detektor in `rls-access-inventory.spec.ts` um
+   `include:`/`select:`/`_count:` auf Modellnamen erweitern, Zieltabelle als eigene
+   Fundstelle fuehren. Zwingend vor Etappe 4.
+2. Etappe 3 planen (drei Teile): (a) Anmeldenamen pro Mandant — Schema-Aenderung,
+   Anmeldeweg muss den Mandanten VOR der Suche kennen, SECURITY-DEFINER-Funktionen
+   mit zwei Gleichheitsbedingungen; (b) Benutzerdimension — `app.current_user`,
+   `current_user_id()`, forTenant() erweitern, Regeln der zehn nutzerbezogenen
+   Tabellen; (c) Systemkontext fuer die sechs Hintergrunddienst-Faelle.
+3. Etappe 4 — Scharfschalten. NUR nach Rueckfrage beim User.
 
 Frische Sitzung, dann `/gsd-resume-work`.
 </next_action>