docs(quick-260909-mir): Etappe 2 Bereich dkv abgeschlossen, zwei Doku-Luecken behoben

.planning/STATE.md

@@ -376,6 +376,7 @@ None yet.
 | 260909-ipc | Mandantentrennung Etappe 2, Bereich ldap: alle 21 klassifizierten Zugriffe in `ldap-config.service.ts` (9) und `ldap.service.ts` (12) an `forTenant()` gebunden. **Zuerst gemessen, dann gebaut:** `rls-scratch-check.mjs` um `runLdapAreaChecks` erweitert (13/13 bestanden), Beleg ist die Zeile `ldapconfig-ungebunden-null-zeilen` gegen die echte, ausgelieferte Policy — die Umkehr der Fehlerrichtung ist damit gemessen, nicht behauptet. Die geforderte Kritikschrift liegt in `docs/mandantentrennung-etappe2-fehlerrichtung.md` mit Signaltabelle je Pfad und vier namentlich benannten Stellen, die Leere als Abwesenheit deuten. **Sicherheitsluecke nebenbei geschlossen (T-IPC-01):** `DELETE /ldap/config/mappings/:id` nahm nur die Kennung — ein Administrator von Mandant A konnte die Feldzuordnung von B loeschen; der Mandant kommt jetzt aus der Sitzung. **Drei Stellen bleiben bewusst ungebunden, jede mit Begruendung im Code:** `getAllActiveConfigs` und die Start-Nachverschluesselung lesen zwingend uebergreifend; `resolveEmailForWrite` darf nicht gebunden werden, weil `email`/`username` plattformweit eindeutig sind — gebunden saehe die Kollisionspruefung keinen fremden Halter, meldete 'frei', und aus einer sauber berichteten Kollision wuerde ein P2002-Abbruch (Produktfrage fuer Etappe 3). **Befund, der die Testlage aendert:** `forTenant` war in `ldap.service.spec.ts` als Identitaet gemockt — die Tests haetten den Umbau in keiner Richtung bemerkt; ersetzt durch zwei unterscheidbare Clients. `rls-access-inventory.spec.ts` um eine `Stand`-Spalte und Erkennung gebundener Fundstellen erweitert, dabei zwei bisher unbekannte Paare gefunden (`auth.service.ts`/`passwordResetToken`, `ldap.service.ts`/`groupMembership`), Klassifikationsdokument auf 61 Paare nachgezogen. Schema, Migrationen, Compose und Umgebungsdateien unberuehrt, Schalter weiter aus. **Verifiziert 7/7** (unabhaengig nachgemessen: 719/719 Tests, Typpruefung sauber, 13/13 Live-Pruefungen gegen den echten Container) | 2026-09-09 | a0c9ef0,9a57fa7,e1586a4 | [260909-ipc-mandantentrennung-etappe-2-bereich-ldap-](./quick/260909-ipc-mandantentrennung-etappe-2-bereich-ldap-/) |
 | 260909-jts | Mandantentrennung Etappe 2, Bereich groups — die Berechtigungsschicht. Alle 34 echten Zugriffe in `groups.service.ts` (21) und `module-grants.service.ts` (13) gebunden, dazu fuenf Zugriffe, die **keine Pruefung dieses Projekts je gesehen hatte**: sie laufen innerhalb einer Transaktion ueber den Callback-Parameter, den der Detektor der Inventarpruefung nicht kannte — einer davon ist der Schreibvorgang, der Modulfreigaben vergibt. Das Paar `(groups.service.ts, tenantModuleActivation)` fehlte im Klassifikationsdokument komplett und ist ergaenzt; der Detektor sieht jetzt auch Transaktionsparameter. **Kernbefund — neues Hilfsmittel `withTenantTransaction()`:** die Frage, welche Transaktionsform den Mandantenkontext auf derselben Verbindung traegt, wurde an der lebenden Datenbank gemessen statt angenommen. Form (i) faellt durch (zwei verschiedene `pg_backend_pid()`), Form (ii) besteht die Einzelmessung, bricht aber unter 40 gleichzeitigen Aufrufen mit P2028 ab, weil jeder Aufruf eine verschachtelte Transaktion aus demselben endlichen Verbindungsvorrat oeffnet; Form (iii) besteht beides. Alle weiteren Bereiche bauen darauf auf. **Die Lastprobe war zunaechst nur Fliesstext** — eine Zahl, die eine Entscheidung trug, ohne nachvollziehbar zu sein; vom Verifizierer beanstandet und als `runConcurrencyProbe` nachgereicht (604428a), laeuft seither bei jedem Werkzeuglauf mit: 24 Verletzungen von 40 fuer Form (ii), 0 von 40 fuer Form (iii). **Zwei Datenbankregeln greifen kuerzer als gedacht** und sind bewusst nur gemessen und festgehalten, nicht repariert: die Regel fuer Gruppenmitgliedschaften prueft nur die Gruppen-, nicht die Benutzerseite (T-JTS-02), die fuer Modulfreigaben nur die Mandantenkennung, nicht die referenzierte Gruppe (T-JTS-03) — dort haengt der Schutz allein an `assertTargetBelongsToTenant`. Umgekehrter Gefahrenfall geschlossen: `ensureDefaultGroup` deutet Leere als 'Mandant hat noch keine Gruppe' und baut alles neu auf, eine halb umgestellte Fassung haette eine zweite Standardgruppe samt Freigaben erzeugt — Zaehler und Transaktion sind deshalb gemeinsam gebunden. Beide Testdateien hatten gar keine Attrappe fuer den Helfer, waeren nach der Umstellung also aus dem falschen Grund rot gewesen; ersetzt durch den Zwei-Client-Nachweis, vom Verifizierer durch Rueckbau falsifiziert. Schema, Migrationen, Compose und Umgebungsdateien unberuehrt, Schalter aus. **Verifiziert 9/9** (743/743 Tests, Typpruefung sauber, 23/23 Live-Pruefungen) | 2026-09-09 | fd0b9f7,7f08b27,abb6c8b,604428a | [260909-jts-mandantentrennung-etappe-2-bereich-group](./quick/260909-jts-mandantentrennung-etappe-2-bereich-group/) |
 | 260909-laa | Mandantentrennung Etappe 2, Bereich tenders — anders geschnitten als die bisherigen: von 23 Paaren werden nur 5 umgestellt (die Nutzer-CRUD-Dienste fuer gespeicherte Suchen, Bearbeitungsstand, Benachrichtigungen, Postfach, RSS), 10 bleiben bewusst ungebunden, weil der Ausschreibungskatalog plattformweit ist (D-03), 2 sind Verteiler, die absichtlich ueber alle Mandanten lesen, und 6 sind Mischfaelle, deren uebergreifende Haelfte zu Etappe 3 gehoert — nur die Je-Treffer-Schleifen wurden gebunden. **Die gefaehrlichste Grenze lag in `tender-rss-feed.service.ts`:** dort haben plattformweite RSS-Quellen ein leeres Mandantenfeld; drei der vier Zugriffe duerfen deshalb NICHT binden, sonst waeren diese Quellen nach dem Scharfschalten fuer JEDEN unsichtbar statt nur fuer fremde (WINDOWS #19). Die Datei endet bewusst auf Stand `gemischt`, und das einzelne bedingte Loeschen blieb eine Anweisung — es aufzuteilen haette das Pruef-/Nutzungsfenster geoeffnet, das der Dateikopf vermeidet. **Neue Gegenrichtung, die die Bindung selbst erzeugt:** drei `upsert`-Pfade laufen auf Eindeutigkeitsschluesseln ohne Mandantendimension; ist die Zeile unter dem gebundenen Kontext unsichtbar, wird aus stillem Ueberschreiben ein harter Fehler — jetzt als deutsche Meldung statt als 500. **Der Verifizierer fand, dass genau eine der drei fehlte** (`setTriage`), obwohl die Zusammenfassung alle drei behauptete; nachgereicht mit 8cbf4c1 samt zwei Tests, deren Rotwerden durch Rueckbau belegt ist. **Befund E, festgehalten statt repariert:** alle fuenf Policies dieses Bereichs lesen nur `tenantId = current_tenant_id()` und haben KEINE Benutzerdimension — zwei Nutzer desselben Mandanten sind auf Datenbankebene fuereinander vollstaendig sichtbar; die Trennung haengt allein am Anwendungscode, der stichprobenartig als korrekt belegt wurde. Produktfrage vor dem zweiten Kunden. **Befund K, neue Reihenfolgebedingung fuer Etappe 4:** der Mailversand holt SMTP aus dem noch nicht umgestellten Bereich `settings` — nach dem Scharfschalten ginge fuer NIEMANDEN mehr eine Mail raus; `settings` muss vor Etappe 4 durch sein. Vierte Zaehlkorrektur des Vorhabens: 62 Rohtreffer sind 61 Modellzugriffe, und von zehn vermeintlichen Controller-Stellen brauchten acht die Durchreichung. **Verifiziert 8/9, Luecke behoben** (772/772 Tests, Typpruefung sauber, 32/32 Live-Pruefungen) | 2026-09-09 | 3498147,3336a6e,df5c5b7,8cbf4c1 | [260909-laa-mandantentrennung-etappe-2-bereich-tende](./quick/260909-laa-mandantentrennung-etappe-2-bereich-tende/) |
+| 260909-mir | Mandantentrennung Etappe 2, Bereich dkv — Tankkarten-Modul. Alle 21 klassifizierten Zugriffe in `dkv.service.ts` gebunden (am Ende 22, weil der neue Besitzriegel einen Lesezugriff hinzufuegt); genau einer bleibt bewusst ungebunden. **Bereits bestehende Fremdzugriffsluecke geschlossen (T-MIR-03):** `getExportFile(tenantId, filename)` nahm die Mandantenkennung entgegen und benutzte sie nie — die Datei kam allein ueber ihren Namen aus dem gemeinsamen `user-files/`-Verzeichnis, ein Administrator eines beliebigen Mandanten konnte die Tankkarten-Auswertung eines anderen herunterladen. Der Riegel leitet die Zugehoerigkeit jetzt aus `DkvInvoiceHistory.exportFilename` ab; in der Oberflaeche gegengeprueft, dass jeder angebotene Dateiname aus einer Historienzeile stammt, die regulaere Nutzung aendert sich also nicht. Die Luecke ist keine Folge des Umbaus, sie bestand seit jeher. **Zerstoerender Fehler in umgekehrter Richtung behoben:** `saveConfig` verschluckte im Zweig, der ein gespeichertes Passwort erhalten soll, Lese- und Entschluesselungsfehler und machte mit leeren Werten weiter — nach dem Scharfschalten haette er ein vorhandenes Passwort durch ein leeres ersetzt und verschluesselt abgelegt, ohne Meldung, nicht rekonstruierbar. **Dritte Variante der Testluecke:** der Bereich hatte gar keine Testdatei (nicht wie ldap eine, die nichts prueft, nicht wie groups/tenders eine, die abstuerzen wuerde); `dkv.service.spec.ts` neu angelegt. **WINDOWS #21, bewusste Entscheidung:** der Planer-Startpfad bleibt ungebunden und wird als benannte Altlast weitergefuehrt — binden ist unmoeglich (`onModuleInit` hat strukturell keinen Mandanten), Umbau auf einmal-abfragen-viele-bedienen waere die in 07-04 zurueckgestellte Mehrmandanten-Planung. Unsymmetrie zum ldap-Praezedenzfall ausgeschrieben: jener ist heute korrekt und verstummt spaeter, dieser ist HEUTE bereits falsch (bedient einen willkuerlichen Mandanten, bei inaktiver Zeile niemanden) UND verstummt zusaetzlich. Dreifach markiert. Erster Bereich, dessen Kopfzahl beim Hineinsehen NICHT kleiner wurde. **Ausfuehrung brach am 2026-09-09 gegen Ende von Aufgabe 3 an einem Sitzungslimit ab** — zwei Aufgaben committet, die dritte vollstaendig im Arbeitsbaum; am 2026-09-10 nachgetragen. Aufgefallen durch `git status`, nicht durch den Bericht. **Verifiziert 9/9, zwei Dokumentationsluecken danach behoben** (Hintergrunddienst-Abschnitt um den vierten Fall erweitert, Falsifizierungsnachweise nachgetragen). 789/789 Tests, Typpruefung sauber, 41/41 Live-Pruefungen | 2026-09-10 | 761e5e2,222f453,5e8237d | [260909-mir-mandantentrennung-etappe-2-bereich-dkv-a](./quick/260909-mir-mandantentrennung-etappe-2-bereich-dkv-a/) |
 | 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/) |
 
 ## Deferred Items
@@ -418,6 +419,6 @@ sind. Kein Anlass, sie vorher erneut vorzulegen.
 
 Last session: 2026-09-09T12:13:05.681Z
 Resumed: 2026-09-09 — Sitzung ueber /gsd-resume-work fortgesetzt; Einstiegspunkt Etappe 2 (Bereich ldap), Auswahl des Nutzers steht aus.
-Stopped at: Etappe 2, drei von elf Bereichen durch (ldap 260909-ipc, groups 260909-jts, tenders 260909-laa). Naechster Bereich: dkv (21 Zugriffe), danach user, module-registry, dashboard, calendar, tenant, favorites, settings. ACHTUNG settings: Befund K aus 260909-laa macht ihn zur Reihenfolgebedingung fuer Etappe 4 — ohne ihn kein Mailversand nach dem Scharfschalten. Der User hat am 2026-09-09 gesagt, die restlichen Bereiche sollen ohne Rueckfrage durchlaufen; beim Scharfschalten (Etappe 4) wird ausdruecklich angehalten.
+Stopped at: Etappe 2, vier von elf Bereichen durch (ldap 260909-ipc, groups 260909-jts, tenders 260909-laa, dkv 260909-mir). Naechster Bereich: user (17 Zugriffe), danach module-registry, dashboard, calendar, tenant, favorites, settings. ACHTUNG settings: Befund K aus 260909-laa macht ihn zur Reihenfolgebedingung fuer Etappe 4 — ohne ihn kein Mailversand nach dem Scharfschalten. Der User hat am 2026-09-09 gesagt, die restlichen Bereiche sollen ohne Rueckfrage durchlaufen; beim Scharfschalten (Etappe 4) wird ausdruecklich angehalten.
 Resume file: None
-Last activity: 2026-09-09 - Completed quick task 260909-laa: Mandantentrennung Etappe 2, Bereich tenders (verifiziert 8/9, Luecke behoben)
+Last activity: 2026-09-10 - Completed quick task 260909-mir: Mandantentrennung Etappe 2, Bereich dkv (verifiziert 9/9, zwei Doku-Luecken behoben)