docs(quick-260914-ebg): WINDOWS #29 abgeschlossen und verifiziert 6/6 — Zusammenfassung, Verifikation, Aktenstand

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

.planning/STATE.md

@@ -4,14 +4,14 @@ milestone: v1.2
 current_phase: 17
 current_phase_name: eigene-ausschreibungs-quellen-je-nutzer
 status: verified
-stopped_at: "Quick 260911-nke abgeschlossen: Etappe 3b Benutzerdimension — Migration 20260911120000, forTenant() mit userId, 34 Aufrufstellen, 203/203 Werkzeugpruefungen, sechs Loch-Pruefungen umgedreht, gepusht"
-last_updated: "2026-09-14T08:18:04.000Z"
-last_activity: 2026-09-10
+stopped_at: "Quick 260914-ebg abgeschlossen: WINDOWS #29 geschlossen — Zielrollen-Riegel in UserController.update/remove, 16 Spec-Tests, Falsifizierung bestanden, gepusht"
+last_updated: "2026-09-14T08:41:17.656Z"
+last_activity: 2026-09-11
 last_activity_desc: Quick 260910-jab — drei zu kurz greifende RLS-Regeln geschlossen (GroupMembership beide Seiten, ModuleGrant beide Ziele, TenderRssFeedSource Lese-/Schreibsplit), listForUser gebunden, Aktenstand kohaerent
-state_head: b62a905adb19f8c68eba45e66f2290ed978c2239
+state_head: 70d007bb47a2e39db54da47297dda162044dc79e
 progress:
   total_phases: 17
-  completed_phases: 3
+  completed_phases: 15
   total_plans: 83
   completed_plans: 82
 milestone_name: Plattform-Berechtigungen
@@ -31,7 +31,7 @@ See: .planning/PROJECT.md (updated 2026-07-17)
 Phase: 17 (eigene-ausschreibungs-quellen-je-nutzer) — VERIFIED / passed
 Plan: 3 of 3
 Status: Phase abgeschlossen und im Browser gegengeprueft — bereit fuer /gsd-ship
-Last activity: 2026-09-11 - Etappe 3b Benutzerdimension abgeschlossen (260911-nke, verifiziert 13/13); 3a und 3c offen, Auftrag in docs/mandantentrennung-etappe3-auftrag.md
+Last activity: 2026-09-14 - WINDOWS #29 geschlossen (260914-ebg, verifiziert 6/6); als naechstes Etappe 3c (Systemkontext), dann 3a, Etappe 4 nur nach Rueckfrage
 
 Progress: [██████████] 100%
 
@@ -121,6 +121,7 @@ Progress: [██████████] 100%
 | Phase quick-260910-krx P01 | 26min | 3 tasks | 7 files |
 | Phase quick-260911-cwh P01 | 21min | 3 tasks | 7 files |
 | Phase quick-260911-nke P01 | 1 Sitzung | 3 tasks | 27 files |
+| Phase quick-260914-ebg P01 | 6min | 3 tasks | 4 files |
 
 ## Accumulated Context
 
@@ -301,6 +302,7 @@ Recent decisions affecting current work:
 - [Phase 17]: 260910-krx: Bereich dashboard vollstaendig umgestellt — 12 gebunden, 1 begruendet ungebunden (Modulkatalog); getLayout/saveLayout gemeinsam gebunden; saveLayout uebersetzt PrismaClientUnknownRequestError (nicht P2002) in deutsche Konfliktmeldung; WINDOWS #25 fuer die beweisvernichtende Schleife offen angelegt
 - [Phase 17]: [quick-260911-cwh]: Bereich calendar Etappe 2 gebunden — Cache-Schluessel bleibt ohne Mandantenanteil (User.id ist plattformweit eindeutige UUID, Etappe-3-Entscheidung (1) betrifft nur username/email); keine neue Fehleruebersetzung fuer Besitzpruefungen noetig (Wettlauf-Fall wirft P2025, strukturell unerreichbar); refreshCacheInBackground zaehlt nicht als sechster Hintergrunddienst-Fall
 - [Phase 17]: 260911-nke: forTenant(prisma, tenantId, userId?) — optionaler dritter Parameter statt Schwesterhelfer, IS-NULL-OR-Form in den Regeln der zehn persoenlichen Tabellen, sechs Loch-Pruefungen umgedreht
+- [Phase 17]: [quick-260914-ebg]: Zielrollen-Riegel als eigenstaendige Pruefung nach der Mandantengrenze in UserController.update()/remove() eingezogen (Vorlage AuthService.adminResetPassword, T-FH9-04) — WINDOWS #29 geschlossen
 
 ### Pitfalls & Anti-Patterns
 
@@ -396,6 +398,7 @@ None yet.
 | 260911-nke | **Etappe 3b — Benutzerdimension in den Datenbankregeln.** Migration `20260911120000_rls_user_dimension_personal_tables`: `current_user_id()` (liest `app.current_user`, `NULLIF` fuer den Leerstring), `forTenant(prisma, tenantId, userId?)` mit optionalem drittem Parameter (kein Schwesterhelfer — der Inventar-Detektor haette ihn nicht gesehen), beide `set_config` in EINER Anweisung, `$transaction` behaelt zwei Eintraege. Regeln der ZEHN persoenlichen Tabellen in der Form `tenantId = current_tenant_id() AND (current_user_id() IS NULL OR userId = current_user_id())` — ein Aufruf ohne Benutzer (Admin, Hintergrunddienst) sieht weiter den ganzen Mandanten. `SearchProvider`/`TenderRssFeedSource` mit vier befehlsgetrennten Regeln (jab-Praezedenz), Mandantenhaelften unveraendert; GroupMembership/ModuleGrant/PasswordResetToken/TenderMatch bewusst ohne Benutzerdimension (Verwaltungs-/Anmelde-/Hintergrundobjekte). 34 Nutzer-CRUD-Aufrufstellen in 8 Diensten reichen den Benutzer durch, Scheduler und Verwaltungswege bleiben zweistellig. **SECHS loch-behauptende Pruefungen statt drei** — und die Umkehrung war nicht trivial: die alten massen OHNE Benutzer, eine naive Umkehrung waere nach der Migration rot geworden, weil der Aufruf ohne Benutzer per Absicht beide sieht; jede wurde zu ZWEI (alte Messung unter neuem Namen als gewollte Eigenschaft, Umkehrung MIT Benutzer). 13 Extraktionsstellen im Werkzeug auf die neue Migration umgeleitet. **Wirkungslos mit ausgeschaltetem Schalter** (Rolle `tessera` hat BYPASSRLS, live bestaetigt) — blockiert das Live-Gehen am Dienstag nicht. Angenommene offene Flanke, festgehalten statt verschwiegen: ein Aufrufer, der den Benutzer vergisst, sieht den ganzen Mandanten (heutiger Stand, keine Verschlechterung) — WINDOWS #34; die dreistelligen Spec-Zusicherungen sind je Datei, nicht je Methode, das Gate 'keine zweistellige Form' ist ein Shell-Check, nicht CI — vom Verifizierer als Bewusstseinspunkt vermerkt. **Verifiziert 13/13** (1020/1020 Tests, Typpruefung sauber, 203/203 Live-Pruefungen; `NULLIF` durch Rueckbau falsifiziert, 33 Pruefungen rot; alle zehn Regeln live in `pg_policies` gelesen) | 2026-09-11 | f0b531b,07fc653,b62a905 | [260911-nke-mandantentrennung-etappe-3b-benutzerdime](./quick/260911-nke-mandantentrennung-etappe-3b-benutzerdime/) |
 | 260909-eor | Etappe 1 der Mandantentrennung: Anmeldeweg mandantenfaehig gemacht und alle Zugriffe klassifiziert. **Kernfund (#20):** `forTenant()` setzte den Mandantenkontext per set_config auf der Transaktionsverbindung, dispatchte die Abfrage aber ueber den aeusseren Client — empirisch reproduziert (set_config auf Backend-PID 254999, Abfrage auf 255000, Kontext dort NULL). Die Trennung hat damit nie funktioniert, auch nicht an den Stellen, die sie scheinbar nutzten; nach dem Scharfschalten haetten diese Abfragen NULL Zeilen geliefert, was der LDAP-Loeschzweig als 'Gruppe im Verzeichnis verschwunden' gedeutet und geloescht haette. Behoben und live nachgewiesen. Der Anmeldeweg bekam drei SECURITY-DEFINER-Funktionen als schmale Ausnahme (feste Spaltenliste, Gleichheitsbedingung, LIMIT 1) — eine Policy haette nicht gereicht, weil sie zwangslaeufig die ganze Tabelle freigibt. Browser-Gegenprobe lokal bestanden: Anmeldung laedt das Portal, falsches Kennwort verraet weiterhin nicht welches Feld, Kennwort-vergessen laeuft durch (der einzige Protokollfehler war ein lokal fehlender Mailserver, also NACH dem Datenbankzugriff). Klassifikation aller 227 Zugriffe in 59 Einheiten, maschinell gegen Abdriften abgesichert: 31 muessen mandantengebunden werden, 9 teilweise, 16 betreffen keine mandantengebundene Tabelle, 3 bleiben bewusst uebergreifend. 701 Tests gruen | 2026-09-09 | da0ac04 | [260909-eor-anmeldeweg-mandantenfaehig-machen-und-al](./quick/260909-eor-anmeldeweg-mandantenfaehig-machen-und-al/) |
 | 260910-jab | Die drei zu kurz greifenden Datenbankregeln geschlossen — T-JTS-02, T-JTS-03, WINDOWS #19 (bewusste Reihenfolge-Abweichung, vorgezogen auf Nutzerwunsch, statt wie geplant nach Etappe 2). Neue, handgeschriebene, lokal angewandte Migration `20260910120000_rls_widen_membership_grant_and_platform_read`: `GroupMembership` prueft jetzt beide Seiten der Beziehung (Gruppe UND Benutzer), `ModuleGrant` prueft zusaetzlich beide moeglichen Ziele mit Leer-Zulassung (D-04), `TenderRssFeedSource` bekommt vier nach Befehl getrennte Regeln (Lesen schliesst plattformweite Zeilen ein, Schreiben verlangt weiterhin einen Mandanten — die Trennung ist noetig, weil ein einzelner USING-Ausdruck sonst auch UPDATE/DELETE mitregelt). `SearchProvider` bewusst NICHT angefasst: die WINDOWS-#19-Praemisse ist fuer dieses Modell widerlegt (kein Codeweg erzeugt eine mandantenlose Zeile). Drei loch-behauptende Pruefungen im Wegwerf-Werkzeug UMGEKEHRT statt geloescht (66→74 Pruefungen), mit Verweis auf die alten Pruefungsnamen und Befundkennungen im Meldetext. Genau EIN Anwendungspfad musste mitgebunden werden (`TenderRssFeedSourceService.listForUser`) — sonst haette die Reparatur ihn still von 'liefert nach dem Scharfschalten nichts' auf 'liefert nur die plattformweiten Zeilen, taeuscht Vollstaendigkeit vor' verschlechtert; Falsifizierungsnachweis gefuehrt (Bindung zurueckgenommen, genau ein Test rot, zurueckgesetzt). WINDOWS #19 geschlossen mit Beleg, WINDOWS #24 neu angelegt (Verwaltungsweg fuer plattformweite Zeilen unter der Anwendungsrolle fehlt weiterhin — verschwindet nicht mit #19). Aktenstand kohaerent: Klassifikation, Kritikschrift (neuer Abschnitt "Regelschluss T-JTS-02, T-JTS-03 und WINDOWS #19" mit Signaltabelle beider Fehlerrichtungen je Regel), Betriebsanleitung, WINDOWS.md — fuenf ueberholte Bestandsstellen mit Nachtraegen versehen, alte Messprotokolle bleiben woertlich stehen. Selbst gemessen statt uebernommen: Baseline 833/56 Tests, 66/66 Live-Pruefungen; Endstand 839/56, 74/74; keine zweite Sitzungsvariable fuer den Benutzer gefunden (nur `app.current_tenant`). Rule-1-Fix: implizites `any` in `tenders.controller.ts` nach der Bindung behoben. `npx prisma` versuchte ungefragt Prisma 8 herunterzuladen — abgebrochen, lokale gepinnte 6.19.3 verwendet | 2026-09-10 | f4f3115,6b23735,03fb3bf | [260910-jab-mandantentrennung-die-drei-zu-kurz-greif](./quick/260910-jab-mandantentrennung-die-drei-zu-kurz-greif/) |
+| 260914-ebg | **WINDOWS #29 geschlossen — Zielrollen-Riegel in `UserController.update()`/`remove()`.** Ein ADMIN kann den SUPER_ADMIN seines Mandanten nicht mehr aendern (Kennwort, isActive, Rolle, Anmeldename, E-Mail) oder loeschen; Riegel nach der Mandantengrenze, vor der Rollenzuweisungs-Pruefung (Vorlage `AuthService.adminResetPassword`, T-FH9-04). Acht neue Spec-Tests (8 -> 16), Baseline 1020 -> 1028 Tests / 62 Dateien, Falsifizierung durch Rueckbau `Tests 2 failed | 14 passed (16)` (Test 9/13), unabhaengig vom Verifizierer wiederholt. Kopfkommentar `adminResetPassword` nachgezogen (T-FH9-05 nicht mehr offen). Ledger 16 offen / 1 zurueckgestellt / 19 geschlossen / 36 gesamt: #29 fixed, NEU #35 (Biome-Konfiguration im Bestand nicht lauffaehig, `pnpm lint` Leerlauf) und #36 (Admin-Frontend verschluckt 403 still). Verifiziert 6/6, gepusht. | 2026-09-14 | 759ea3b,63f9df0,70d007b | [260914-ebg-windows-29-schliessen-rechteausweitung-a](./quick/260914-ebg-windows-29-schliessen-rechteausweitung-a/) |
 
 ## Deferred Items
 
@@ -435,8 +438,8 @@ sind. Kein Anlass, sie vorher erneut vorzulegen.
 
 ## Session Continuity
 
-Last session: 2026-09-14T08:18:04.000Z
+Last session: 2026-09-14T08:41:09.727Z
 Resumed: 2026-09-14 — Sitzung ueber /gsd-resume-work fortgesetzt; HANDOFF.json und .continue-here.md verbraucht und entfernt. Entscheidung des Users: WINDOWS #29 VOR Etappe 3c (Live-Gehen am 2026-09-15), danach 3c, dann 3a, Etappe 4 nur nach Rueckfrage.
-Stopped at: **ETAPPE 2 KOMPLETT, WINDOWS #27 GESCHLOSSEN, ETAPPE 3b (BENUTZERDIMENSION) KOMPLETT — 2026-09-11.** Endstand 1020 Tests / 62 Dateien, 203 Live-Pruefungen, 72 Paare in der Klassifikation, Ledger 15 offen von 34. Alles gepusht, Arbeitsbaum sauber. DER SCHALTER IST AUS. **User-Anweisung 2026-09-11: 'mach #27 und dann Etappe 3, nicht nachfragen. am dienstag [2026-09-15] geht eine voll funktionsfaehige version live.'** Live-Gehen braucht den Schalter NICHT (ein Mandant, BYPASSRLS-Stand laeuft heute auf alpha). OFFEN: **Etappe 3a** (Anmeldenamen pro Mandant — Schema `@@unique([tenantId, username/email])`, Anmeldeweg muss den Mandanten VOR der Suche kennen, SECURITY-DEFINER-Funktionen mit zweiter Gleichheitsbedingung; enthaelt EINE Produktfrage an den User: Mandant per Subdomain (Empfehlung) oder Login-Wahl; fuer Dienstag NICHT noetig, da ein Mandant) und **Etappe 3c** (Systemkontext `app.system_context` fuer die sechs Hintergrunddienst-Faelle #21/#30 und die vier beides-Uebergaben; macht DKV- und SMTP-Startpfad zu einmal-abfragen-viele-bedienen). VOLLSTAENDIGER AUFTRAG: docs/mandantentrennung-etappe3-auftrag.md (3b dort als 'Erledigt' vermerkt). Danach Etappe 4 Scharfschalten mit rls-preflight.mjs — DER USER WILL DORT GEFRAGT WERDEN. Die Sitzung vom 2026-09-11 endete bei ~70% Kontext nach 3b; Einstieg `/gsd-resume-work`, dann 3c oder 3a als `/gsd-quick --validate` mit vollstaendiger Kette (Planer, Pruefer, Executor, Verifizierer).
+Stopped at: Quick 260914-ebg abgeschlossen: WINDOWS #29 geschlossen — Zielrollen-Riegel in UserController.update/remove, 16 Spec-Tests, Falsifizierung bestanden, gepusht
 Resume file: None
-Last activity: 2026-09-10 - Completed quick task 260910-jab: Die drei zu kurz greifenden Datenbankregeln (T-JTS-02, T-JTS-03, WINDOWS #19) geschlossen
+Last activity: 2026-09-14 - Completed quick task 260914-ebg: WINDOWS #29 geschlossen, Zielrollen-Riegel in UserController.update/remove