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

.planning/HANDOFF.json

@@ -1,6 +1,6 @@
 {
   "version": "1.0",
-  "timestamp": "2026-09-09T09:16:11.548Z",
+  "timestamp": "2026-09-11T13:00:00.000Z",
   "phase": null,
   "phase_name": "Mandantentrennung wirksam machen (Etappenarbeit ausserhalb der Phasen, ueber Quick-Tasks)",
   "phase_dir": null,
@@ -9,27 +9,30 @@
   "total_tasks": 4,
   "status": "paused",
   "completed_tasks": [
-    {"id": 1, "name": "Etappe 1 / forTenant() auf eine Verbindung zwingen, live nachgewiesen", "status": "done", "commit": "bbf1795"},
-    {"id": 2, "name": "Etappe 1 / Anmeldeweg ueber drei SECURITY-DEFINER-Funktionen", "status": "done", "commit": "de50297"},
-    {"id": 3, "name": "Etappe 1 / alle 227 Zugriffe klassifiziert, maschinell abgesichert", "status": "done", "commit": "5f3a39c"},
-    {"id": 4, "name": "Etappe 1 / Browser-Gegenprobe der Anmeldung (lokal)", "status": "done", "commit": "da0ac04"}
+    {"id": 1, "name": "Etappe 1 / forTenant() repariert, Anmeldeweg ueber SECURITY DEFINER, 227 Zugriffe klassifiziert", "status": "done", "commit": "5228f28"},
+    {"id": 2, "name": "Etappe 2 / alle zwoelf Bereiche gebunden, jeder einzeln verifiziert (260909-ipc .. 260911-gwh)", "status": "done", "commit": "1240932"},
+    {"id": 3, "name": "Zwischendurch auf Anweisung des Users: drei Datenbankregeln geschlossen (260910-jab)", "status": "done", "commit": "03fb3bf"}
   ],
   "remaining_tasks": [
-    {"id": 5, "name": "Etappe 2: 31 Einheiten vollstaendig + 9 teilweise auf forTenant umstellen, nach Bereichen gebuendelt (tenders 62, groups 37, ldap 21, dkv 21, user 17, module-registry 17, dashboard 13, calendar 12, tenant 8, favorites 7, settings 4)", "status": "not_started"},
-    {"id": 6, "name": "Etappe 3: Systemkontext fuer Hintergrundlaeufe plus WINDOWS #19 (nullable tenantId bei SearchProvider und TenderRssFeedSource)", "status": "not_started"},
-    {"id": 7, "name": "Etappe 4: Scharfschalten (DATABASE_URL auf tessera_app) mit Vorabpruefung und dokumentiertem Rueckweg", "status": "not_started"}
+    {"id": 4, "name": "WINDOWS #27 schliessen: Relations-Blindstelle der Bestandsaufnahme (include:/_count: in fremde Tabellen) — ZWINGEND vor Etappe 4", "status": "not_started"},
+    {"id": 5, "name": "Etappe 3a: Anmeldenamen pro Mandant eindeutig (Produktentscheidung User 2026-09-10) — Schema @@unique([tenantId, username/email]), Anmeldeweg kennt Mandant VOR der Suche, SECURITY-DEFINER-Funktionen mit zwei Gleichheitsbedingungen", "status": "not_started"},
+    {"id": 6, "name": "Etappe 3b: Benutzerdimension in den Regeln (Produktentscheidung User 2026-09-10) — app.current_user/current_user_id(), forTenant() um userId erweitern, Regeln der zehn nutzerbezogenen Tabellen", "status": "not_started"},
+    {"id": 7, "name": "Etappe 3c: Systemkontext fuer die sechs Hintergrunddienst-Faelle (#21 dkv, #30 settings, vier beides-Uebergaben aus tenders/ldap)", "status": "not_started"},
+    {"id": 8, "name": "Etappe 4: Scharfschalten (DATABASE_URL auf tessera_app) mit rls-preflight.mjs — Vorabpruefung muss die stillen Leere-Faelle #23/#25/#26/#28/#31/#32 abdecken. USER WILL HIER GEFRAGT WERDEN.", "status": "not_started"}
   ],
   "blockers": [
-    {"description": "Etappe 4 darf erst nach Etappe 2 und 3 laufen. Wird vorher scharf geschaltet, liefern die noch nicht umgestellten Abfragen null Zeilen statt zu vieler.", "type": "technical", "workaround": "Reihenfolge einhalten; rls-preflight.mjs vor dem Umschalten laufen lassen"}
+    {"description": "Etappe 4 darf erst nach Etappe 3 und nach Schliessen von WINDOWS #27 laufen. Der User hat ausdruecklich verlangt, beim Scharfschalten angehalten und gefragt zu werden.", "type": "process", "workaround": "Reihenfolge einhalten"}
   ],
   "async_jobs": [],
   "human_actions_pending": [],
   "decisions": [
-    {"decision": "Anmeldeweg ueber SECURITY-DEFINER-Funktionen statt Policy oder zweiter Rolle", "rationale": "Eine Policy ist ein Zeilenpraedikat und haette zwangslaeufig die ganze Benutzertabelle freigegeben. Die Funktion pinnt die Ausnahme auf feste Spaltenliste, Gleichheitsbedingung und LIMIT 1.", "phase": "Etappe 1"},
-    {"decision": "Benanntes Volume fuer user-files statt Bind-Mount", "rationale": "Das Image uebereignet /app/user-files an uid 1001; ein frisch angelegtes Host-Verzeichnis gehoert root und haette aus dem Datenverlust einen kaputten Upload gemacht.", "phase": "Quick 260909-cx0"},
-    {"decision": "Datenverlust in der Datenbank ist derzeit hinnehmbar", "rationale": "Ausdrueckliche Aussage des Users am 2026-09-09: nichts laeuft produktiv. Erlaubt beim Scharfschalten den direkten Weg. Gilt nur, solange das so bleibt.", "phase": "Etappe 4 (Vorgriff)"}
+    {"decision": "Anmeldenamen pro Mandant eindeutig, nicht plattformweit", "rationale": "Produktentscheidung des Users am 2026-09-10 — m.schmidt darf es bei Firma A und B geben", "phase": "Etappe 3"},
+    {"decision": "Kollegen derselben Firma strikt getrennt — Benutzerdimension in die Datenbankregeln", "rationale": "Produktentscheidung des Users am 2026-09-10; heute trennt nur der Anwendungscode, die Datenbank kennt nur den Mandanten", "phase": "Etappe 3"},
+    {"decision": "req.tenantPrisma entfernt, Middleware geloescht", "rationale": "Bei jeder Anfrage gebaut, nirgends gelesen; Middleware war nirgends registriert; neun Bereiche haben dienst-internes forTenant() als Konvention festgelegt", "phase": "260911-e2s"},
+    {"decision": "Datenbankregeln VOR Abschluss von Etappe 2 vorgezogen", "rationale": "Ausdrueckliche Anweisung des Users am 2026-09-10 — offene Loecher werden vergessen", "phase": "260910-jab"},
+    {"decision": "Datenverlust in der Datenbank ist derzeit hinnehmbar", "rationale": "User 2026-09-09: nichts laeuft produktiv. Gilt nur solange das so bleibt.", "phase": "Etappe 4 (Vorgriff)"}
   ],
   "uncommitted_files": [],
-  "next_action": "Etappe 2 beginnen: docs/mandantentrennung-zugriffsklassifikation.md lesen und den ersten Bereich buendeln. Sinnvoller Einstieg ist NICHT der groesste Bereich, sondern ldap (21 Zugriffe, 9 davon bereits mandantengebunden) — dort sitzt der gefaehrlichste Loeschzweig, und die Wirkung ist dort am besten pruefbar.",
-  "context_notes": "Die Sitzung lief ueber Quick-Tasks, nicht ueber Phasen; es gibt daher kein aktives Phasenverzeichnis. Der entscheidende Fund war, dass forTenant() selbst kaputt war (Kontext auf einer Verbindung, Abfrage auf einer anderen) — die Mandantentrennung hat nie funktioniert. Das ist behoben und live belegt. Wichtig fuer die Fortsetzung: erst pruefen, ob das Fundament traegt, bevor darauf gebaut wird; genau das hat hier einen stillen Datenverlust verhindert. Der Arbeitsbaum ist sauber, alles ist gepusht, die CI ist gruen."
+  "next_action": "WINDOWS #27 schliessen (Relations-Blindstelle), dann Etappe 3 planen. NICHT direkt scharfschalten.",
+  "context_notes": "Etappe 2 lief ueber zwoelf Quick-Tasks plus einen Regel-Durchlauf, jeder mit Planer, Plan-Pruefer, Executor, Verifizierer. ZEHN Lieferungen wurden vom jeweils NAECHSTEN Schritt gefangen, nie vom eigenen: vier geschrumpfte Zaehlungen, zwei nicht committete Messungen, zwei Zusammenfassungen mit N statt N-1, handgepflegte Dokumentstellen uebersprungen, Falsifizierungsnachweise nur in Commit-Nachrichten, eine Wegwerf-Tabelle ohne createdAt/updatedAt, ein Selbstwiderspruch, ein Pruefer der etwas als plausibel durchwinkte, ein still fehlgeschlagener git add, und zwei Agenten die am Sitzungslimit NACH getaner Arbeit abbrachen (dkv-Executor, gwh-Planer — beide Male lag die Arbeit vollstaendig auf der Platte; git status ist die Wahrheit, nicht der Bericht). Die vollstaendige Liste steht in jedem Planer-Auftrag der spaeten Bereiche. Nebenfunde ohne Mandantenbezug, alle behoben: DKV-Download-Luecke, drohender DKV-Passwortverlust, Selbstloesch-Riegel der nie griff, Startfehler bei Neuinstallation, adminResetPassword ohne Mandanten- und Rollenpruefung, Widget-Besitzriegel bei Favoriten, sechs luegende Kommentare, und fuenf Bereiche ohne jede Testdatei."
 }