docs: Arbeitsstand pausiert — Etappe 3b zu, offen 3c/#29/3a/Etappe 4

Handoff neu aufgenommen und gemessen statt erinnert: Arbeitsbaum leer,
main == origin/main, keine Datei juenger als der letzte Commit vom
2026-09-11 — es lag keine angefangene Arbeit herum.

Gegenueber dem alten Handoff ergaenzt:
- WINDOWS #29 (PATCH /users/:id ohne Rollenausweitungs-Pruefung) als
  eigener Punkt; einziger offener Sicherheitsbefund ohne Bezug zum
  Scharfschalten.
- Phase 17 ist VERIFIED, /gsd-ship lief nie — v1.2 formal nicht
  geschlossen, windows_enforce blockiert bei open_count 15.
- Einordnung der 15 offenen WINDOWS-Eintraege: welche mit 3a/3c fallen,
  welche erst mit #18 akut werden, welche Netz-Luecken sind.
- Placeholder-Suche ueber .planning/phases/ geprueft: 53 Treffer, alle
  Prosa ueber Debt-Marker, keine unfertigen Zusammenfassungen.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H77uqgDTe82JHFaVx6S71s

.planning/HANDOFF.json

@@ -1,12 +1,12 @@
 {
   "version": "1.0",
-  "timestamp": "2026-09-11T16:30:00.000Z",
+  "timestamp": "2026-09-14T08:02:29.277Z",
   "phase": null,
   "phase_name": "Mandantentrennung wirksam machen (Etappenarbeit ausserhalb der Phasen, ueber Quick-Tasks)",
   "phase_dir": null,
   "plan": null,
   "task": null,
-  "total_tasks": 4,
+  "total_tasks": 5,
   "status": "paused",
   "completed_tasks": [
     {
@@ -23,7 +23,7 @@
     },
     {
       "id": 3,
-      "name": "Zwischendurch auf Anweisung des Users: drei Datenbankregeln geschlossen (260910-jab)",
+      "name": "Auf Anweisung des Users vorgezogen: drei zu kurz greifende Datenbankregeln geschlossen (260910-jab)",
       "status": "done",
       "commit": "03fb3bf"
     },
@@ -35,37 +35,58 @@
     },
     {
       "id": 5,
-      "name": "Etappe 3b: Benutzerdimension — current_user_id(), forTenant() dreistellig, zehn Tabellen, 34 Aufrufstellen, sechs Pruefungen zu zwoelf (260911-nke, 13/13)",
+      "name": "Etappe 3b: Benutzerdimension — current_user_id(), forTenant() dreistellig, zehn Tabellen, 34 Aufrufstellen, sechs Pruefungen umgedreht (260911-nke, verifiziert 13/13)",
       "status": "done",
-      "commit": "b62a905"
+      "commit": "3b08d8e"
     }
   ],
   "remaining_tasks": [
     {
       "id": 6,
-      "name": "Etappe 3a: Anmeldenamen pro Mandant — enthaelt EINE offene Produktfrage (Subdomain vs Login-Wahl); fuer Dienstag nicht noetig; siehe docs/mandantentrennung-etappe3-auftrag.md",
+      "name": "Etappe 3c: Systemkontext fuer die sechs Hintergrunddienst-Faelle (forSystem(), dritte Sitzungsvariable) — EMPFOHLEN ALS NAECHSTES, braucht keine Produktentscheidung; schliesst WINDOWS #21 und #30; siehe docs/mandantentrennung-etappe3-auftrag.md",
       "status": "not_started"
     },
     {
       "id": 7,
-      "name": "Etappe 3c: Systemkontext fuer die sechs Hintergrunddienst-Faelle — EMPFOHLEN ALS NAECHSTES (braucht keine Produktentscheidung); siehe docs/mandantentrennung-etappe3-auftrag.md",
+      "name": "WINDOWS #29: PATCH /users/:id (UserController.update) prueft die Rollenausweitung ADMIN -> SUPER_ADMIN nicht, der Schwesterweg adminResetPassword tut es. Unabhaengig vom Scharfschalten, einziger Sicherheitspunkt vor dem Live-Gehen",
       "status": "not_started"
     },
     {
       "id": 8,
-      "name": "Etappe 4: Scharfschalten — USER WILL GEFRAGT WERDEN. Nicht noetig fuer das Live-Gehen am Dienstag 2026-09-15.",
+      "name": "Etappe 3a: Anmeldenamen pro Mandant (@@unique([tenantId, username/email]), p_tenant_id in den drei SECURITY-DEFINER-Funktionen) — enthaelt DIE EINE offene Produktfrage: Subdomain je Mandant vs. Mandantenwahl im Login; fuer Dienstag nicht noetig",
+      "status": "not_started"
+    },
+    {
+      "id": 9,
+      "name": "Etappe 4: Scharfschalten (DATABASE_URL auf eine Rolle ohne BYPASSRLS, rls-preflight.mjs davor) — USER WILL GEFRAGT WERDEN. Nicht noetig fuer das Live-Gehen am Dienstag 2026-09-15",
+      "status": "not_started"
+    },
+    {
+      "id": 10,
+      "name": "Phase 17 ist VERIFIED, aber /gsd-ship lief nie — v1.2 formal nicht geschlossen; windows_enforce blockiert den Ship bei open_count 15",
       "status": "not_started"
     }
   ],
   "blockers": [
     {
-      "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.",
+      "description": "Etappe 4 darf erst nach Etappe 3 laufen. Vorher liefern die nicht umgestellten Abfragen null Zeilen statt zu vieler; der Loeschzweig in ldap.service.ts (~1559) deutet Leere als 'Gruppe im Verzeichnis verschwunden' und loescht. Der User hat ausdruecklich verlangt, beim Scharfschalten angehalten und gefragt zu werden.",
       "type": "process",
-      "workaround": "Reihenfolge einhalten"
+      "workaround": "Reihenfolge einhalten: 3c, dann 3a, dann fragen"
     }
   ],
   "async_jobs": [],
-  "human_actions_pending": [],
+  "human_actions_pending": [
+    {
+      "action": "Produktentscheidung fuer Etappe 3a: woran der Login den Mandanten erkennt — eigene Subdomain je Mandant (Empfehlung) oder Mandantenwahl im Anmeldeformular",
+      "context": "Ohne diese Entscheidung laesst sich 3a nicht planen; mit einem Mandanten ist plattformweit = pro Mandant, deshalb fuer das Live-Gehen am 2026-09-15 nicht noetig",
+      "blocking": false
+    },
+    {
+      "action": "Freigabe fuer Etappe 4 (Scharfschalten)",
+      "context": "Ausdrueckliche Anweisung des Users seit 2026-09-09",
+      "blocking": true
+    }
+  ],
   "decisions": [
     {
       "decision": "Anmeldenamen pro Mandant eindeutig, nicht plattformweit",
@@ -74,12 +95,17 @@
     },
     {
       "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"
+      "rationale": "Produktentscheidung des Users am 2026-09-10; mit Etappe 3b umgesetzt",
+      "phase": "Etappe 3b"
+    },
+    {
+      "decision": "Helfer erweitern statt zweiten bauen — forTenant(prisma, tenantId, userId?)",
+      "rationale": "Praezedenz withTenantTransaction(); Hintergrunddienste und Verwaltungswege rufen weiter zweistellig, die Regel traegt IS-NULL",
+      "phase": "260911-nke"
     },
     {
       "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",
+      "rationale": "Bei jeder Anfrage gebaut, nirgends gelesen; Middleware war nirgends registriert",
       "phase": "260911-e2s"
     },
     {
@@ -94,6 +120,6 @@
     }
   ],
   "uncommitted_files": [],
-  "next_action": "docs/mandantentrennung-etappe3-auftrag.md lesen. Etappe 3c (Systemkontext) als /gsd-quick --validate starten — braucht keine Entscheidung des Users. Danach 3a. NICHT nachfragen ausser beim Scharfschalten.",
-  "context_notes": "Sitzung 2026-09-11 endete bei ~70% Kontext nach Etappe 3b. Verifizierer-Hinweis zu 3b: die dreistelligen forTenant()-Zusicherungen sind je Spec-Datei, nicht je Methode; das Gate 'keine zweistellige Form in den acht Dateien' ist ein Shell-Check, nicht CI — eine Methode koennte still auf zweistellig zurueckfallen (WINDOWS #34, angenommenes Risiko). Wer das schliessen will: den Check in rls-access-inventory.spec.ts einbauen. USER-ANWEISUNG 2026-09-11: 'mach #27 und dann Etappe 3, nicht nachfragen. du machst alles, was ohne mich geht. am dienstag geht eine voll funktionsfaehige version live.' Live-Gehen braucht den Schalter NICHT (ein Mandant, BYPASSRLS-Stand laeuft heute auf alpha). Etappe 3 darf das Live-Gehen nicht blockieren. Nach jedem Durchlauf pushen. Die vorige Sitzung endete mit ~65% Kontext waehrend #27 lief; der Etappe-3-Auftrag wurde deshalb als eigenes Dokument geschrieben, gemessen statt erinnert. 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."
-}
+  "next_action": "docs/mandantentrennung-etappe3-auftrag.md lesen. Etappe 3c (Systemkontext) als /gsd-quick --validate starten — braucht keine Entscheidung des Users. Danach WINDOWS #29, dann 3a. NICHT nachfragen ausser beim Scharfschalten.",
+  "context_notes": "Gemessen am 2026-09-14: git status --porcelain leer, main == origin/main, keine Datei juenger als der letzte Commit vom 2026-09-11 17:58 — es gibt KEINE angefangene Arbeit. Die Sitzung vom 11.09. lief nach Etappe 3b bei ~70% Kontext aus, der Handoff war geschrieben; dieser hier ist die Neuaufnahme desselben Standes plus zwei Punkte, die im alten fehlten (WINDOWS #29, nie gelaufener Ship von Phase 17). Verifizierer-Hinweis zu 3b: die dreistelligen forTenant()-Zusicherungen sind je Spec-Datei, nicht je Methode; das Gate 'keine zweistellige Form in den acht Dateien' ist ein Shell-Check, nicht CI (WINDOWS #34, angenommenes Risiko) — wer das schliessen will, baut den Check in rls-access-inventory.spec.ts ein. USER-ANWEISUNG 2026-09-11, weiter gueltig: 'mach #27 und dann Etappe 3, nicht nachfragen. du machst alles, was ohne mich geht. am dienstag geht eine voll funktionsfaehige version live.' Live-Gehen braucht den Schalter NICHT (ein Mandant, BYPASSRLS-Stand laeuft heute auf alpha); Etappe 3 darf es nicht blockieren. Nach jedem Durchlauf pushen. 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, uebersprungene handgepflegte Dokumentstellen, 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. Die Placeholder-Suche ueber .planning/phases/ meldet 53 Treffer, alle geprueft: es sind Prosa-Stellen, die Debt-Marker BESCHREIBEN (z.B. 17-VERIFICATION.md Zeile 135), keine unfertigen Zusammenfassungen."
+}