tessera-ctl/docs/mandantentrennung-zugriffsklassifikation.md

# Mandantentrennung — Zugriffsklassifikation

Dieses Dokument gehört zusammen mit `docs/mandantentrennung-datenbankrolle.md`
zur Vorbereitung der Mandantentrennung auf Datenbankebene (WINDOWS #18/#20).
Während die Datenbankrolle-Anleitung beschreibt, **wie** die Umstellung
technisch abläuft, hält dieses Dokument fest, **welche** der 227
`this.prisma.*`-Fundstellen in `apps/api/src` beim Umbau in den folgenden
Etappen angefasst werden müssen und welche bewusst unverändert bleiben.

Die Bestandsaufnahme unten wird **maschinell aus dem Quelltext ermittelt**
(nicht von Hand zusammengeschrieben) und durch
`apps/api/src/prisma/rls-access-inventory.spec.ts` bei jedem Testlauf gegen
den tatsächlichen Stand geprüft. Verschiebt sich eine Zeile, bleibt die
Prüfung grün — Vergleichsschlüssel sind Datei und Prisma-Modellname, keine
Zeilennummer. Kommt eine neue Fundstelle hinzu oder verschwindet eine
bestehende, schlägt die Prüfung fehl, bis dieses Dokument nachgezogen wird.

## Die drei Klassen

- **`muss-mandantengebunden`** — berührt auf Rechnung genau eines Mandanten
  eine Tabelle mit `tenantId` (oder eine Tabelle, die ihre Mandantenregel
  über einen Join auf eine solche Tabelle bezieht). Muss in Etappe 2 auf
  `forTenant()` umgestellt werden.
- **`bewusst-uebergreifend`** — muss über Mandanten hinweg sehen, mit
  ausgeschriebenem Grund. Braucht in Etappe 3 eine sichtbare Kennzeichnung
  (Systemkontext), aber keinen `forTenant()`-Umbau.
- **`keine-mandantengebundene-tabelle`** — betrifft eines der acht Modelle
  ohne `tenantId` bzw. eine bewusst plattformweite Tabelle (D-03). Kein
  Umbau nötig.
- **`beides`** — ein vierter, im Plan ausdrücklich verlangter Sonderfall:
  ein Hintergrunddienst, der zurecht über alle Mandanten hinweg eine Liste
  aufbaut (bewusst übergreifend), aber *innerhalb* der Schleife je Mandant
  binden muss (muss mandantengebunden werden). Beide Anteile sind in
  derselben Datei vorhanden; die Fundstelle bekommt hier eine
  Sammelklassifikation, die Aufteilung auf Zeilenebene steht in der
  Begründung.

## Zwei belegte Befunde

**`req.tenantPrisma` wird gesetzt, aber nirgends gelesen.**
`tenant.middleware.ts:44` und `tenant.guard.ts:41` setzen
`req.tenantPrisma = forTenant(this.prisma, tenantId)`. Eine Volltextsuche
über `apps/api/src` nach `tenantPrisma` außerhalb dieser beiden Dateien und
ihrer Tests findet keine lesende Stelle — kein Controller greift darauf zu.
Die Verdrahtung besteht, wird aber nicht genutzt. Für Etappe 2 ist zu
entscheiden, ob die Controller künftig darüber gehen (dann bräuchte es keinen
zweiten `forTenant()`-Aufruf je Service-Methode) oder ob der Weg ersatzlos
entfällt. Dieser Plan entscheidet das nicht, hält den Befund nur fest.

**Entschieden (260911-e2s, Aufgabe 2):** ersatzloser Entfall, fuer ALLE
Bereiche der Etappe 2, nicht nur fuer `tenant`. Gemessen: außerhalb von
`tenant.middleware.ts` und `tenant.guard.ts` gab es KEINEN Leser (Suchumfang
oben bestaetigt, ebenso erneut gemessen in 260911-e2s Aufgabe 1, Befund B);
`tenant.middleware.ts` war zudem NIRGENDS verdrahtet (kein
`MiddlewareConsumer`, kein `configure(` in ganz `apps/api`, gemessen)
und hatte — anders als der urspruengliche Befund oben suggerierte — auch
KEINE eigenen Tests, ebenso wenig wie der Guard (`ls apps/api/src/tenant/`
vor 260911-e2s: einzige Testdatei war `tenant.service.spec.ts`). Entscheidung:
`tenant.middleware.ts` ist GELOESCHT, `tenant.guard.ts` setzt nur noch
`req.tenantId` und hat keine Prisma-Abhaengigkeit mehr. Grund: alle neun vor
diesem Bereich umgestellten Bereiche binden ausnahmslos dienst-intern (ein
Klient je Methode) — die Konvention ist durch Praxis entschieden, und tote
Verdrahtung, die wie ein Sicherheitsmechanismus aussieht, ist schlimmer als
keine. Siehe `docs/mandantentrennung-etappe2-fehlerrichtung.md`, Abschnitt
"## Bereich tenant", (n4)(a), fuer Messung und Begruendung im Volltext.

**WINDOWS #19 — nullbares `tenantId` bei `SearchProvider` und
`TenderRssFeedSource` — GESCHLOSSEN (260910-jab, Aufgabe 1/2).** Beide Modelle
tragen ein nullbares `tenantId` (`SearchProvider` für admin-gepflegte
Vorgabe-Suchmaschinen; `TenderRssFeedSource` für plattformweite RSS-Quellen
wie den geseedeten `service.bund.de`-Feed, D-06). Die ausgelieferte Policy
`"tenantId" = current_tenant_id()` verglich `NULL` nie gleich — nach dem
Scharfschalten wären plattformweite Zeilen für JEDEN Mandanten unsichtbar
gewesen, nicht nur für fremde.

Geschlossen durch Migration
`20260910120000_rls_widen_membership_grant_and_platform_read`, lokal
angewandt und gegen den Systemkatalog der lebenden Datenbank gemessen:
`TenderRssFeedSource` bekommt vier nach Befehl getrennte Regeln —
`tenant_platform_read_policy` (SELECT) schließt Zeilen ohne Mandant
ausdrücklich ein, `tenant_insert_policy`/`tenant_update_policy`/
`tenant_delete_policy` verlangen weiterhin ausnahmslos einen Mandanten. Die
Trennung nach Befehl ist notwendig, weil ein einzelner `USING`-Ausdruck auch
bestimmt, welche Zeilen `UPDATE`/`DELETE` erreichen — eine Leseregel, die
plattformweite Zeilen einschließt, hätte ohne Trennung jedem Mandanten auch
das Ändern/Entfernen dieser Zeilen erlaubt.

Die Hälfte zur Suchanbietertabelle (`SearchProvider`) schließt NICHT als
gelöstes Problem, sondern als **widerlegte Prämisse**: lokal gemessen gibt es
keinen Codeweg, der eine mandantenlose `SearchProvider`-Zeile erzeugt — der
einzige Schreibweg (`dashboard.service.ts`) verlangt die Mandantenkennung als
Pflichtparameter, und die Vorgabe-Suchmaschinen kommen laut 05-02-Entscheidung
aus Konstanten, nicht aus der Datenbank. Die Regel bleibt deshalb bewusst
unverändert streng; eine Lockerung wäre hier die falsche Richtung, weil sie
eine künftige mandantenlose Zeile jedem Mandanten zeigen würde.

Was diese Reparatur NICHT löst: unter der Anwendungsrolle lässt sich eine
plattformweite `TenderRssFeedSource`-Zeile weder anlegen noch entfernen, in
der alten wie in der neuen Regel, weil jede Schreibregel einen Mandanten
verlangt. Als eigener offener Ledger-Eintrag festgehalten (WINDOWS #24),
damit dieser Rest nicht mit #19 verschwindet.

## Übersicht je Bereich (Zeilentreffer je Bereich, ungebunden vs. gebunden)

**Wichtig, seit 260909-ipc (Aufgabe 3):** die Spalte "Ungebunden" zählt NUR
noch `this.prisma.<Modell>`-Rohtreffer — eine unveränderte Spaltenüberschrift
über einer veränderten Bedeutung wäre die nächste stille Falle, seit ein
Bereich (`ldap`) tatsächlich gebundene Zugriffe hat, die aus dieser Zählung
verschwinden. Die neue Spalte "Gebunden" zählt daneben die
`forTenant()`-gebundenen Rohtreffer (`tenantPrisma.<Modell>`, Konvention
dieses Codes — siehe `rls-access-inventory.spec.ts` für die allgemeinere,
namensunabhängige Erkennung über die `const <Name> = forTenant(`-Zuweisungsform).
Beide Spalten sind Rohtreffer (mehrere Vorkommen desselben Modells in
derselben Datei zählen mehrfach), nicht (Datei, Modell)-Paare wie in der
Bestandsaufnahme unten.

Gemessen mit
`grep -ro "this\.prisma\.[a-zA-Z]*" apps/api/src/<bereich> | grep -v spec | wc -l`
bzw. `grep -ro "tenantPrisma\.[a-zA-Z]*\." apps/api/src/<bereich> | grep -v spec | wc -l`
am 2026-09-09, **nach** den Änderungen aus Aufgabe 2/3 dieses Plans (260909-jts):

**Methodische Lücke, seit 260909-jts sichtbar:** die zweite Zählung sucht
ausschließlich den Namen `tenantPrisma` — die Konvention, die `ldap` und
(bis auf die drei Transaktionen) auch `groups` verwenden. Die drei
`withTenantTransaction()`-Aufrufe in `groups.service.ts` binden zusätzliche
neun Modellzugriffe über den Namen `tx` (den Transaktionsparameter), die
diese einfache Rohtrefferzählung strukturell NICHT sieht — anders als die
maschinelle, namensunabhängige Erkennung in `rls-access-inventory.spec.ts`
(Befund B), die auch diese Form erfasst. Die Zahl 31 unten ist deshalb der
Bodensatz, nicht die vollständige Zahl gebundener Zugriffe in `groups`; die
Bestandsaufnahme unten (Spalte "Stand", je (Datei, Modell)-Paar) ist die
autoritative Quelle.

**Zweite methodische Lücke, seit 260911-mkj geschlossen — aber nur in der
Bestandsaufnahme:** die beiden Rohtreffer-Greps dieser Tabelle
(`this\.prisma\.[a-zA-Z]*` bzw. `tenantPrisma\.[a-zA-Z]*\.`) zählen
Relationsziele (`include:`, `select:`, `_count:`, Relationsfilter in
`where:`/`orderBy:`) strukturell NICHT — ein `include: { module: true }`
auf `tenantPrisma.tenantModuleActivation` erzeugt keinen Rohtreffer auf
`module`, weil `module` in der Datei nie als `tenantPrisma.module` steht.
Die Spalten und die Summenzeile behalten deshalb ihre bisherige Bedeutung
und ihre bisherigen Werte (weiterhin 68 ungebunden / 178 gebunden, NACH-
GERECHNET, nicht abgeschrieben) — sie zählen weiterhin nur direkte
Modellaufrufe. Autoritativ für Relationszugriffe ist allein die
Bestandsaufnahme unten, deren vierte Erkennungsform
(`rls-access-inventory.spec.ts`, `analyzeSource`) die Ziele als eigene
Paare führt: sieben der 72 Paare dort tauchen in KEINER Rohtrefferzahl
dieser Übersicht auf, zum Beispiel
`module-registry/module-access.service.ts`/`group` (nur über den
Relationsfilter `group: { memberships: { some: { userId } } }` sichtbar,
niemals als `tenantPrisma.group` im Quelltext).

**Dritte Spalte `System` (260914-eym, Etappe 3c):** Rohtreffer
`systemPrisma\.[a-zA-Z]*\.` je Bereich, gleiche Grep-Form wie die beiden
anderen Spalten (nur `.ts` ohne `.spec.ts`) — die direkten Modellaufrufe
über den Systemkontext-Klienten `forSystem()`. Dieselbe Grenze wie die
anderen beiden Spalten: Relationsziele (`include: { fieldMappings }` in
`ldap-config.service.ts`) zählt auch sie NICHT; autoritativ bleibt die
Bestandsaufnahme unten (Stand `system-gebunden`). Die Werte aller drei
Spalten sind mit der Schleife aus dem Gate von 260914-eym nachgerechnet
(`for d in apps/api/src/*/`), nicht abgeschrieben.

| Bereich | Ungebunden | Gebunden | System | Hinweis |
|---|---|---|---|---|
| tenders | 33 | 27 | 2 | **war 62/0**, dann 36/26 nach 260909-laa — 260910-jab (Aufgabe 2) hat `tender-rss-feed.service.ts`/`listForUser` zusätzlich auf `forTenant()` umgestellt (WINDOWS #19 geschlossen, Befund F: ungebunden hätte die Reparatur den Pfad sonst still auf nur die plattformweiten Zeilen reduziert): ein Rohtreffer wandert von ungebunden nach gebunden (36→35, 26→27). Die 35 verbleibenden ungebundenen Treffer sind die zwölf bewusst nicht angefassten Paare (D-03-Katalog, zwei Fan-out-Adapter) plus die zwei bewusst ungebundenen RSS-Pfade (`createPlatform`/`remove`, WINDOWS #24) plus die übergreifenden Hälften der beiden Hintergrunddienste (Etappe-3-Übergabe). **260914-eym:** diese beiden Hälften (Kandidatenabfrage des Digest, Profilabfrage des Abgleichs) lesen jetzt über `forSystem()` — 35→33 ungebunden, 2 System |
| groups | 0 | 31 | 0 | **war 37/0** — Aufgabe 2/3 (260909-jts) haben `groups.service.ts` (12 Methoden) und `module-grants.service.ts` (5 Methoden) vollständig auf `forTenant()`/`withTenantTransaction()` umgestellt. Die neun zusätzlichen, über `tx` gebundenen Zugriffe innerhalb der drei Transaktionen zählt dieses einfache Muster nicht mit (siehe Methodenhinweis oben) |
| ldap | 1 | 27 | 2 | **war 21/0** — Aufgabe 2/3 (260909-ipc) haben `ldap-config.service.ts` (5 Methoden) und `ldap.service.ts` (6 Methoden, 11 Abfragen) auf `forTenant()` umgestellt. Die 4 verbleibenden ungebundenen Treffer waren bewusst: `getAllActiveConfigs`/`onApplicationBootstrap` (Befund B) und `resolveEmailForWrite` (Befund A, T-IPC-04). **260914-eym:** die beiden Leser in `ldap-config.service.ts` laufen über `forSystem()` (4→1 ungebunden, 2 System), die Schreibzeile der Nachverschlüsselung über `forTenant()` (26→27 gebunden); der eine verbleibende ungebundene Rohtreffer ist `resolveEmailForWrite` |
| dkv | 0 | 22 | 1 | **war 21/0** — Aufgabe 2/3 (260909-mir) haben `dkv.service.ts` vollständig auf `forTenant()` umgestellt: Konfigurationspfade (`loadConfig`, `getConfigForApi`, `saveConfig`, `testConnection`), Historie, Fahrzeugstammdaten und der neue Besitzriegel vor dem Ausfuhrdatei-Download. Gebunden sind es 22 statt 21, weil der Riegel einen zusätzlichen Lesezugriff auf `dkvInvoiceHistory` einführt (T-MIR-03). Der eine verbleibende ungebundene Treffer war der benannte Planer-Startpfad `loadAnyActiveConfigForScheduler()` (Befund D, WINDOWS #21). **260914-eym:** ersetzt durch `loadActiveConfigsForScheduler()` über `forSystem()` (1→0 ungebunden, 1 System) — WINDOWS #21 geschlossen |
| user | 8 | 18 | 0 | **Nachgemessen quick-260929-9wc:** 8/18/0 — die Zeile nannte 17 gebunden, gemessen sind 18 (Drift aus quick-260928-ujj, Hintergrund pro Benutzer, nachgeholt). Vorher: **quick-260925-bow:** +3 gebunden in `user.controller.ts`, „Was ist neu“-Fenster, `GET me/release-notice` (ein `findUnique`) und `POST me/release-seen` (`findUnique` + `update`), beide über `forTenant()` mit `where: { id: currentUser.id }`, nachgemessen mit der Gate-Schleife: 8/17/0. Vorher: **war 17/0** — Aufgabe 2/3 (260910-das) haben `user.service.ts` (`findById`/`create`/`update`/`deactivate`/`delete` sowie die zwei neuen Plattform-Administratorsicht-Methoden), `admin-seed.service.ts` (Erstanlage des Administrators) und `user.controller.ts` (Benutzerliste des ADMIN-Zweigs, alle drei Kennungswege ueber die Dienstmethoden, alle fuenf Selbstbedienungszugriffe) auf `forTenant()` umgestellt. Die 8 verbleibenden ungebundenen Rohtreffer sind bewusst: `findByUsername` in `user.service.ts` (plattformweit eindeutiger Schluessel, derselbe Fall wie `resolveEmailForWrite` im Bereich `ldap`), die Erstanlage-Pruefung und beide Zugriffe auf `tenant` in `admin-seed.service.ts`, sowie der neue Schleifentreiber `this.prisma.tenant.findMany` der beiden Plattform-Administratorsicht-Methoden in `user.service.ts` (`Tenant` traegt keinen Zeilenschutz) |
| module-registry | 7 | 10 | 0 | **war 17/0** — Aufgabe 2/3 (260910-exd) haben `module-access.service.ts` (`getAccessibleModuleIds`: Kurzschlusszweig, Direktweg, Gruppenweg, Schnittmenge; `getCatalogFlags`: eigener Aktivierungs-Lesezugriff) und `module-registry.service.ts` (`findActiveForTenant`, `activateForTenant`, `deactivateForTenant`, `isModuleActive`) auf `forTenant()` umgestellt. Die 7 verbleibenden ungebundenen Rohtreffer sind bewusst: der eine Katalogzugriff in `module-access.service.ts` (`findAccessibleModules`) und die sechs Katalogzugriffe in `module-registry.service.ts` (`findAll`, `findBySlug`, die beiden Katalog-Existenzpruefungen in `activateForTenant`/`deactivateForTenant`, die Katalogsuche in `isModuleActive`, `seedModule`) — der Modulkatalog (`Module`) traegt heute keinen Zeilenschutz, eine Bindung waere heute wirkungslos, nicht katastrophal; katastrophal wuerde sie erst, WENN Etappe 3 dieser Tabelle eine Regel gibt (Befund E) |
| dashboard | 1 | 29 | 0 | **quick-260924-m4n (Stufe 2 der Bilderrahmen-Umstellung):** nachgemessen mit der Gate-Schleife 1/29/0 — die Zeile nannte zuletzt 1/28/1, gemessen waren vor dieser Änderung aber schon 1/31/1: quick-260923-lrr hatte in `dashboard.service.ts` zwei gebundene `tenantPrisma.favoriteLink.`-Rohtreffer (Aufräumen hochgeladener Favoriten-Symbole) hinzugefügt, ohne diese Zeile nachzuziehen, und die ad9-Zählung lag um eins zu niedrig. Diese Änderung selbst: −2 gebunden und −1 System in `dashboard-images.service.ts` — der Bootstrap-Umzug ist entfernt (sein `systemPrisma.dashboardImage.findMany` und sein je Zeile gebundenes `update`), und der Upload legt die Zeile gleich MIT `storagePath` an (UUID vom Dienst), das nachträgliche `update` entfällt. Übrig in `dashboard-images.service.ts`: 7 gebundene Rohtreffer (`findMany`, `count`, `create`, `delete` beim Zurücknehmen, zweimal `findUnique`, `delete`). Vorher: **quick-260923-ad9 (Task 5, Endstand nach Task 2):** 24→28 gebunden — Task 2 (Reiter anlegen/umbenennen/löschen/umsortieren) bringt vier weitere gebundene `tenantPrisma.dashboard.`-Rohtreffer in `dashboard.service.ts`: `createDashboard` (`findMany` der vorhandenen Namen, `create`), `renameDashboard` (`update`), `deleteDashboard` (die Zählung vor dem Löschen). Die Schreib-/Lese-Zugriffe INNERHALB der `withTenantTransaction` in `deleteDashboard`/`reorderDashboards` (`tx.dashboard.*`, `tx.widgetInstance.deleteMany`, `tx.dashboardLayout.deleteMany`) zählt diese einfache Rohtrefferzählung strukturell NICHT mit — dieselbe dokumentierte Lücke wie bei `groups.service.ts` (siehe Kopf dieses Abschnitts); sie sind trotzdem gebunden (jeder Aufruf von `withTenantTransaction(` zählt als gebunden) und stehen deshalb bereits als `gebunden` in den Paaren `dashboard`/`widgetInstance`/`dashboardLayout` unten. Nachgemessen mit der Gate-Schleife. Vorher: **quick-260923-ad9 (Task 1):** 21→24 gebunden — die neue Reitertabelle bringt drei gebundene `dashboard`-Rohtreffer in `dashboard.service.ts` (zwei `findMany` in `listDashboards`, ein `findUnique` im Riegel `assertOwnedDashboard`), nachgemessen mit der Gate-Schleife. Vorher: **260922-hk4:** 18→21 gebunden, 0→1 System — die Bilderrahmen-Bilder liegen jetzt im Dateibereich statt in der Spalte `data`. Drei zusätzliche gebundene Rohtreffer in `dashboard-images.service.ts`: das Nachtragen von `storagePath` nach dem Upload (die UUID steht erst nach `create` fest), das Zurücknehmen der Zeile bei fehlgeschlagenem Schreiben, und das Nachtragen im Umzug beim Start. Der eine System-Rohtreffer ist die Lesehälfte dieses Umzugs (`onApplicationBootstrap`, Zeilen ohne `storagePath` über ALLE Mandanten, Muster DKV-Planer) — geschrieben wird auch dort je Zeile mandantengebunden. Nachgemessen mit der Gate-Schleife. Vorher: **260921-pi9:** 12→18 gebunden — `dashboard-images.service.ts` (Bilderrahmen) bringt sechs gebundene `dashboardImage`-Rohtreffer (`findMany`, `count`, `create`, zweimal `findUnique`, `delete`), nachgemessen mit der Gate-Schleife. Vorher: **war 13/0** — Aufgabe 2/3 (260910-krx) haben `dashboard.service.ts` vollständig umgestellt: `getLayout`/`saveLayout` (gemeinsam gebunden), `getWidgets`/`addWidget`/`updateWidgetConfig`/`removeWidget` sowie `getSearchProviders`/`addSearchProvider`/`removeSearchProvider` laufen über `forTenant()`, je Methode ein Klient. Der eine verbleibende ungebundene Rohtreffer ist bewusst: der Modulkatalog (`Module`) trägt heute keinen Zeilenschutz, eine Bindung wäre heute wirkungslos, nicht katastrophal — katastrophal würde sie erst, WENN Etappe 3 dieser Tabelle eine Regel gibt (Befund E aus `module-registry`, hier übernommen) |
| auth | 3 | 10 | 0 | **war 8/5** — 260911-fh9 (Aufgabe 2) hat `getMe`, `changePassword`, `adminResetPassword` (fünf Rohtreffer auf `user`, drei Methoden) auf `forTenant()` umgestellt. Die 3 verbleibenden ungebundenen Rohtreffer sind die `$queryRaw`-Aufrufe der drei Anmeldefunktionen (`validateUser`, `requestPasswordReset`, `resetPassword`) — KEINE Modellzugriffe (`$` liegt nicht in `[a-zA-Z]`, die Bestandsaufnahme führt sie deshalb nicht als (Datei, Modell)-Paar), bewusst und dauerhaft ungebunden, siehe `20260909160000_auth_lookup_functions` und `docs/mandantentrennung-etappe2-fehlerrichtung.md`, Abschnitt "## Bereich auth", (h1) |
| calendar | 0 | 12 | 0 | **war 12/0** — Aufgabe 2 (260911-cwh) hat `calendar.service.ts` vollständig auf `forTenant()` umgestellt: `getSources`, `addSource`, beide Abfragen von `updateSource`/`deleteSource`, alle drei Abfragen von `testConnection`, Laden plus beide Synchronstatus-Rückschreibungen von `fetchAndCacheEvents` — je Methode ein Klient. Anders als bei den sieben Bereichen davor bleibt KEIN ungebundener Rest übrig: `CalendarSource` trägt eine Pflicht-Mandantenkennung, und kein Pfad dieses Bereichs liest über Mandanten hinweg |
| tenant | 8 | 3 | 0 | **war 8/0** — 260911-e2s (Aufgabe 3) hat drei gebundene Benutzerzähler in `tenant.controller.ts` eingeführt (Fan-out je Mandant nach dem Muster von `UserService.findAllForPlatformAdmin`, ersetzt die drei vorherigen Relationszähler); die acht `tenant`-Zugriffe selbst BLEIBEN ungebunden — `Tenant` trägt keine Regel in irgendeiner ausgelieferten Migration (260911-e2s Aufgabe 1, Prüfung 1/2), hier ist Ungebundenheit richtig, nicht geduldet |
| favorites | 0 | 12 | 0 | **Nachgemessen quick-260924-m4n: 12 gebundene Rohtreffer** — die Zeile nannte 8; die vier weiteren `tenantPrisma.favoriteLink.`-Rohtreffer kamen mit quick-260923-lrr (Favoriten-Symbol hochladen/ausliefern/entfernen) in `favorites.service.ts` hinzu, ohne dass die Zeile nachgezogen wurde. Vorher: **war 7/0** — 260911-gwh (Aufgabe 2) hat `favorites.service.ts` vollständig auf `forTenant()` umgestellt: `list`, `create`, `update`, `remove`, `getIconBytes` laufen je über EINEN Klienten `tenantPrisma` (7 gebundene `favoriteLink`-Rohtreffer); `create` prüft zusätzlich über einen gebundenen `widgetInstance.findUnique`, dass das Ziel-Widget dem Aufrufer gehört (T-GWH-05, Befund F aus Aufgabe 1: der Fremdschlüssel prüft am Zeilenschutz vorbei) — der achte gebundene Rohtreffer dieser Zeile |
| bug-reports | 0 | 1 | 0 | neu (260914-m97), ein gebundener Zugriff |
| settings | 0 | 4 | 0 | **Nachgemessen 260921-pi9: 4 gebundene Rohtreffer** (die Tabelle nannte 3; der vierte `smtpConfig`-Zugriff kam mit 260914-m97/`bugReportRecipient` hinzu, ohne dass die Zeile nachgezogen wurde). **war 4/0** — 260911-gwh (Aufgabe 2) hat `getSmtpConfig`, `saveSmtpConfig`, `getDecryptedSmtpConfig` auf `forTenant()` umgestellt (3 gebundene `smtpConfig`-Rohtreffer). Der eine verbleibende ungebundene Rohtreffer war der umbenannte Planer-Startpfad `loadAnySmtpConfigForStartupTransport()` (Befund D, WINDOWS #30). **260914-eym:** GELÖSCHT — `MailService` baut je Versand einen Transport über `getDecryptedSmtpConfig(tenantId)` (1→0 ungebunden, 0 System, kein Systemkontext nötig); Befund K (`tenders`/`dkv`/`mail` hängen an `getDecryptedSmtpConfig`) ist damit erfüllt — WINDOWS #30 geschlossen |
| proxmox | 0 | 11 | 1 | **quick-260923-dhh (Aufgabe 5, Endstand):** 7→11 gebunden — `updateServer` (`proxmoxServer.findUnique` UND `.update`) und `deleteServer` (`proxmoxServer.findUnique` UND `.delete`) bringen vier weitere gebundene Rohtreffer, je ein Klient je Methode. Nachgemessen mit der Gate-Schleife (`grep -c` ueber `tenantPrisma\.\(proxmoxServer\|proxmoxServerStatus\)\.` in `proxmox.service.ts`: 10 fuer `proxmoxServer`, 1 fuer `proxmoxServerStatus`). Vorher: **quick-260923-dhh (Aufgabe 4):** 4→7 gebunden, 0→1 System — `proxmox.service.ts` bringt drei weitere gebundene Rohtreffer (`pollServer` mit `include: { status: true }` bleibt EIN Klient, `testConnection`, `listActiveServerIdsForTenant`, `loadActiveServersForTenantScheduling` — vier neue Methoden, aber `pollServer`s zweiter Zugriff war schon gezaehlt, macht drei zusaetzliche) und einen System-Rohtreffer (`loadActiveServersForScheduler()`, der einzige `forSystem()`-Aufruf des Moduls, Erlaubnisliste in `rls-access-inventory.spec.ts`). Vorher: **quick-260923-dhh (Aufgabe 1):** neu, vier gebundene Rohtreffer: `createServer` (`proxmoxServer.create`), `listWithStatus` (`proxmoxServer.findMany`), `pollServer` (`proxmoxServer.findUnique` UND `proxmoxServerStatus.upsert`, DERSELBE Klient in derselben Methode) |
| custom-modules | 0 | 6 | 0 | **Nachgemessen quick-260929-dzu:** 0/6/0 — persönliche Einträge je Benutzer: `create` trägt jetzt zwei Klienten in getrennten Zweigen (gemeinsam ohne Benutzer, persönlich mit Benutzer, je ein `tenantPrisma.customModule.create`), die gemeinsame Ladefunktion `loadVisible` trägt das einzige `findUnique` für `getOne`/`update`/`remove` (vorher je Methode eines): `list` 1, `create` 2, `loadVisible` 1, `update` 1, `remove` 1. Das Ergebnis ist ein Treffer weniger als bei quick-260929-9wc, obwohl der Zugriff strenger geworden ist. Vorher: **quick-260929-9wc:** neu, sieben gebundene Rohtreffer in `custom-modules.service.ts` (`list` 1, `getOne` 1, `create` 1, `update` 2, `remove` 2), nachgemessen mit der Gate-Schleife: 0/7/0. Kein ungebundener Zugriff, kein Systemkontext. |
| reminders | 0 | 12 | 1 | **quick-260929-if2 (Aufgabe 3):** nachgemessen mit der Gate-Schleife: 0/12/1 — +5 gebunden, +1 System. `reminders.service.ts` +1 gebunden (`getEmailAvailability`: `user.findFirst` für die eigene E-Mail-Adresse, an Mandant und Benutzer gebunden). NEU `reminder-mail.scheduler.ts`: +4 gebunden je Kandidatenzeile (`reminder.updateMany` als Anspruch, `reminder.findFirst`, `user.findFirst` für die Adresse des Besitzers, `reminder.updateMany` als Freigabe bei Transportfehler; alle über `forTenant(prisma, c.tenantId)` ohne Benutzer) und +1 System (`systemPrisma.reminder.findMany`, die Kandidatenabfrage über alle Mandanten, nur skalarer Select). Vorher: **quick-260929-if2 (Aufgabe 2):** nachgemessen mit der Gate-Schleife: 0/7/0 — +4 gebunden: `update` (`update`), `snooze` (`update`), `remove` (`delete`) und die gemeinsame Besitzprüfung `loadOwn` (`findFirst`, ein Treffer für alle drei; fremde und unbekannte Kennungen sind dort ununterscheidbar 404, D-05). Vorher: **quick-260929-if2 (Aufgabe 1, Tracer):** neu, drei gebundene Rohtreffer in `reminders.service.ts`, nachgemessen mit der Gate-Schleife: 0/3/0 — `list` (`findMany`), `create` (`count` fuer die Grenze von 100 und `create`). Persönliche Erinnerungen je Benutzer, jede Methode bindet mit Mandant UND Benutzer (`forTenant(prisma, tenantId, userId)`). Kein ungebundener Zugriff, kein Systemkontext in diesem Bereich (der E-Mail-Planer folgt in Aufgabe 3). |
| **Summe** | **61** | **235** | **7** | **Nachgemessen quick-260929-if2 (Aufgabe 3):** mit der Gate-Schleife (`for d in apps/api/src/*/`, nur .ts ohne spec), nicht abgeschrieben: 61/235/7. Gegenüber der bisherigen Zeile (61/230/6): Gebunden +5 und System +1 = `reminders` (siehe dortige Zeile), Ungebunden unverändert. Vorher: **Nachgemessen quick-260929-if2 (Aufgabe 2):** mit der Gate-Schleife (`for d in apps/api/src/*/`, nur .ts ohne spec), nicht abgeschrieben: 61/230/6. Gegenüber der bisherigen Zeile (61/226/6): Gebunden +4 = `reminders` +4 (siehe dortige Zeile), Ungebunden/System unverändert. Vorher: **Nachgemessen quick-260929-if2 (Aufgabe 1):** mit der Gate-Schleife (`for d in apps/api/src/*/`, nur .ts ohne spec), nicht abgeschrieben: 61/226/6. Gegenüber der bisherigen Zeile (61/223/6): Gebunden +3 = `reminders` +3 (neu, siehe dortige Zeile), Ungebunden/System unverändert. Vorher: **Nachgemessen quick-260929-dzu:** mit der Gate-Schleife (`for d in apps/api/src/*/`, nur .ts ohne spec), nicht abgeschrieben: 61/223/6. Gegenüber der bisherigen Zeile (61/224/6): Gebunden −1 = `custom-modules` −1 (7→6, siehe dortige Zeile), Ungebunden/System unverändert. Vorher: **Nachgemessen quick-260929-9wc:** mit der Gate-Schleife (`for d in apps/api/src/*/`, nur .ts ohne spec), nicht abgeschrieben: 61/224/6. Gegenueber der bisherigen Zeile (61/216/6): Gebunden +8 = `user` +1 (Drift aus quick-260928-ujj, siehe dortige Zeile; gemessen war schon vorher 61/217/6) und `custom-modules` +7 (neu, siehe dortige Zeile), Ungebunden/System unveraendert. Vorher: **quick-260925-bow:** nachgerechnet mit der Gate-Schleife (`for d in apps/api/src/*/`), nicht abgeschrieben: 61/216/6. Gegenüber der bisherigen Zeile (61/213/6): Gebunden +3 = `user` +3 (die zwei Selbstbedienungswege des „Was ist neu“-Fensters in `user.controller.ts`, siehe dortige Zeile), Ungebunden/System unverändert. Vorher: **quick-260924-m4n:** nachgerechnet mit der Gate-Schleife (`for d in apps/api/src/*/`), nicht abgeschrieben: 61/213/6. Gegenüber der bisherigen Zeile (61/208/7): Gebunden +5 = `favorites` +4 (Drift aus quick-260923-lrr nachgeholt) und `dashboard` +1 (Drift +3 nachgeholt, diese Änderung −2; siehe dortige Zeilen), System −1 (`dashboard`, Bootstrap-Umzug der Bilderrahmen-Bilder entfernt). Vorher: **quick-260923-dhh (Aufgabe 5, Endstand):** Gebunden 204→208 (`proxmox` +4, siehe dortige Zeile), Ungebunden/System unverändert — nachgerechnet mit derselben Gate-Schleife, nicht abgeschrieben. Vorher: **quick-260923-dhh (Aufgabe 4):** Gebunden 201→204 (`proxmox` +3, siehe dortige Zeile), System 6→7 (`proxmox` +1) — nachgerechnet mit derselben Gate-Schleife, nicht abgeschrieben. Vorher: **quick-260923-dhh (Aufgabe 1):** Gebunden 197→201 (`proxmox` neu, +4, siehe dortige Zeile), Ungebunden/System unverändert. Vorher: **quick-260923-ad9 (Task 5, Endstand nach Task 2):** Gebunden 193→197 (`dashboard` +4, siehe dortige Zeile), Ungebunden/System unverändert — nachgerechnet mit derselben Gate-Schleife, nicht abgeschrieben. Vorher: **quick-260923-ad9 (Task 1):** Gebunden 190→193 (`dashboard` +3, siehe dortige Zeile), Ungebunden/System unverändert — nachgerechnet mit derselben Gate-Schleife, nicht abgeschrieben. **260922-hk4:** Gebunden 187→190, System 5→6 (beides `dashboard`, siehe dortige Zeile), Ungebunden unverändert — nachgerechnet mit derselben Gate-Schleife, nicht abgeschrieben. **260921-pi9:** Gebunden 179→187, nachgerechnet mit der Gate-Schleife: +6 in `dashboard` (Bilderrahmen), +1 in `settings` (Zeile war seit 260914-m97 um eins zu niedrig), +1 fuer `bug-reports` (Zeile seit 260914-m97 vorhanden, in der Summe aber nie mitgezaehlt) — die Summe stimmt damit wieder mit den Bereichszeilen ueberein. **260914-eym:** Ungebunden 68→61 (`tenders` −2, `ldap` −3, `dkv` −1, `settings` −1), Gebunden 178→179 (`ldap` +1), System 5 (`dkv` 1, `ldap` 2, `tenders` 2) — nachgerechnet mit der Gate-Schleife, nicht abgeschrieben. Vorgeschichte: Ungebunden: war 118 nach 260910-das, dann 108 nach 260910-exd (module-registry 17→7), dann 107 nach 260910-jab (`tenders` 36→35, `listForUser` gebunden), dann 95 nach 260910-krx (`dashboard` 13→1), dann 83 nach 260911-cwh (`calendar` 12→0), unverändert nach 260911-e2s (`tenant` bleibt bei 8 ungebundenen Rohtreffern), dann 78 nach 260911-fh9 (`auth` 8→3), jetzt 68 nach 260911-gwh (`favorites` 7→0, `settings` 4→1). Gebunden: war 124, dann 134 nach 260910-exd (zusätzlich 10 in `module-registry`), dann 135 nach 260910-jab (zusätzlich 1 in `tenders`), dann 147 nach 260910-krx (zusätzlich 12 in `dashboard`), dann 159 nach 260911-cwh (zusätzlich 12 in `calendar`), dann 162 nach 260911-e2s (zusätzlich 3 in `tenant`), dann 167 nach 260911-fh9 (zusätzlich 5 in `auth`), jetzt 178 nach 260911-gwh (zusätzlich 8 in `favorites`, 3 in `settings`). Dies ist der ENDSTAND der Etappe 2: jeder verbleibende ungebundene Rohtreffer ist einer der in diesem Dokument benannten, bewusst ungebundenen Fälle. Diese Übersicht ist eine Buchführungshilfe; **autoritativ ist die Fundstellentabelle unten**, die `rls-access-inventory.spec.ts` bei jedem Lauf gegen den Quelltext prüft |

## Klassen-Verteilung (nach (Datei, Modell)-Fundstellen, 83 Paare)

Stand 260909-jts (Aufgabe 3): 61 Paare aus dem vorherigen Durchlauf
(260909-ipc) plus ein bisher vollstaendig unsichtbares Paar
(`groups.service.ts`/`tenantModuleActivation`), das erst die um
Transaktionsparameter erweiterte Erkennung (Befund B, Aufgabe 2 dieses
Plans) sichtbar macht — der einzige Zugriff auf dieses Modell in dieser
Datei lief bis dahin ausschliesslich ueber den Rueckgabeparameter der
interaktiven Transaktion in `ensureDefaultGroup` und war weder ueber
`this.prisma.<Modell>` noch ueber `<gebundener Client>.<Modell>` erfassbar.
Die Zahl ist der Ausgabe der Pruefung in
`apps/api/src/prisma/rls-access-inventory.spec.ts` entnommen, nicht
geschaetzt.

**Nachtrag 260921-pi9:** 74 Paare — ein neues Paar
`dashboard/dashboard-images.service.ts`/`dashboardImage`
(muss-mandantengebunden, gebunden) fuer die hochgeladenen Bilder des
Bilderrahmen-Widgets. Nachgezaehlt mit `grep -cE` ueber die Fundstellen-
tabelle: vor diesem Eintrag standen dort bereits 73 Zeilen, nicht 72 — das
Paar `bug-reports/bug-reports.service.ts`/`user` (260914-m97,
muss-mandantengebunden) war in der Tabelle eingetragen, in dieser
Verteilung aber nie mitgezaehlt. Beide Korrekturen (72→74, 35→37) sind
gemessen, nicht geschaetzt.

**Nachtrag 260923-ad9 (Task 1, Dashboard-Reiter):** 75 Paare — ein neues
Paar `dashboard/dashboard.service.ts`/`dashboard` (muss-mandantengebunden,
gebunden) fuer die neue Reitertabelle (`listDashboards`,
`assertOwnedDashboard`). Nachgezaehlt mit `grep -cE "^\| apps/api/src/"
docs/mandantentrennung-zugriffsklassifikation.md` ueber die
Fundstellentabelle: vor diesem Eintrag standen dort 74 Zeilen. Die
Uebersichtszeile `dashboard` und die Summenzeile unten sind mit derselben
Gate-Schleife nachgerechnet (Rohtreffer, nicht Paare): `dashboard.service.ts`
traegt jetzt drei zusaetzliche gebundene `tenantPrisma.dashboard.`-Rohtreffer
(zwei `findMany` in `listDashboards`, ein `findUnique` in
`assertOwnedDashboard`) — Bereich `dashboard` 21→24 gebunden, Summe
190→193 gebunden, ungebunden und System unveraendert.

**Stand 260909-laa (Aufgabe 2):** dieselben 62 Paare, keine neue Fundstelle
hinzugekommen oder verschwunden — nur EINE Klasse hat sich verschoben:
`tender-rss-feed.service.ts`/`tenderRssFeedSource` wechselt von
`muss-mandantengebunden` auf `beides` (WINDOWS #19 — `createForUser` bindet,
`listForUser`/`createPlatform`/`remove` bleiben bewusst uebergreifend), der
exakte Praezedenzfall aus `ldapConfig` in 260909-ipc.

**Stand 260910-das (Aufgabe 3):** 63 Paare — 62 aus dem vorherigen
Durchlauf plus EIN neues Paar (`user.service.ts`/`tenant`, Klasse
`keine-mandantengebundene-tabelle`, Stand `ungebunden`): der Schleifentreiber
der neu eingefuehrten Plattform-Administratorsicht (Befund F/N, Aufgabe 1/2).
Zusaetzlich ZWEI Klassenkorrekturen, jede mit eigener Begruendung an der
Fundstelle in der Bestandsaufnahme oben: `user.service.ts`/`user` wechselt
von `muss-mandantengebunden` auf `beides` — wortgleich derselbe
Praezedenzfall wie `ldap.service.ts`/`user` in 260909-ipc
(`resolveEmailForWrite`, hier `findByUsername`); `admin-seed.service.ts`/`user`
wechselt von `bewusst-uebergreifend` auf `beides`, weil die bisherige
Begruendung nachweislich falsch war (Befund J: der Mandant ist bei der
Erstanlage des Administrators bereits bekannt, nicht strukturell fehlend).
Alle drei Zahlen sind der Ausgabe von `rls-access-inventory.spec.ts`
entnommen, nicht geschaetzt.

**Stand 260910-krx (Aufgabe 3): unveraendert, ausdruecklich festgehalten
statt uebersprungen.** Weiterhin 63 Paare, keine Klasse verschoben sich.
Die vier Paare des Bereichs `dashboard`
(`dashboard.service.ts`/`dashboardLayout`, `/module`, `/searchProvider`,
`/widgetInstance`) waren bereits vor diesem Durchlauf korrekt klassifiziert
(drei `muss-mandantengebunden`, eines `keine-mandantengebundene-tabelle`) —
dieser Plan aendert nur ihre `Stand`-Spalte (`ungebunden` auf `gebunden`
fuer drei der vier Paare), keine ihrer Klassen. Eine unveraenderte Tabelle
ohne diesen Vermerk waere von einer vergessenen Nachziehung nicht zu
unterscheiden — deshalb steht die Abwesenheit einer Aenderung hier
ausdruecklich, statt stillschweigend uebersprungen zu werden.

**Stand 260911-cwh (Aufgabe 3): unveraendert, ausdruecklich festgehalten
statt uebersprungen.** Weiterhin 63 Paare, keine Klasse verschoben sich. Das
eine Paar des Bereichs `calendar` (`calendar.service.ts`/`calendarSource`)
war bereits vor diesem Durchlauf korrekt klassifiziert (`muss-mandantengebunden`)
— Aufgabe 2 (260911-cwh) aendert nur seine `Stand`-Spalte (`ungebunden` auf
`gebunden`), nicht seine Klasse. Eine unveraenderte Tabelle ohne diesen
Vermerk waere von einer vergessenen Nachziehung nicht zu unterscheiden —
deshalb steht die Abwesenheit einer Aenderung hier ausdruecklich, statt
stillschweigend uebersprungen zu werden.

**Stand 260911-e2s (Aufgabe 3):** 64 Paare — 63 aus dem vorherigen
Durchlauf plus EIN neues Paar (`tenant.controller.ts`/`user`, Klasse
`muss-mandantengebunden`, Stand `gebunden`): die drei gebundenen
Benutzerzähler des Fan-outs (Befund F/G aus 260911-e2s Aufgabe 1). Keine
bestehende Klasse verschiebt sich — die beiden `tenant`-Paare
(`tenant.controller.ts`/`tenant`, `tenant.service.ts`/`tenant`) bleiben
`keine-mandantengebundene-tabelle`/`ungebunden`, nur ihre Begründung wird
fortgeschrieben (siehe Fundstellentabelle unten).

**Stand 260911-fh9 (Aufgabe 3): unveraendert, ausdruecklich festgehalten
statt uebersprungen.** Weiterhin 64 Paare, keine Klasse verschiebt sich. Das
Paar `apps/api/src/auth/auth.service.ts`/`user` war bereits vor diesem
Durchlauf korrekt klassifiziert (`muss-mandantengebunden`) — Aufgabe 2
(260911-fh9) aendert nur seine `Stand`-Spalte (`gemischt` auf `gebunden`),
nicht seine Klasse. Das Paar `apps/api/src/auth/auth.service.ts`/
`passwordResetToken` bleibt `muss-mandantengebunden`/`gebunden`,
unveraendert. Eine unveraenderte Tabelle ohne diesen Vermerk waere von
einer vergessenen Nachziehung nicht zu unterscheiden — deshalb steht die
Abwesenheit einer Aenderung hier ausdruecklich, statt stillschweigend
uebersprungen zu werden.

**Stand 260911-gwh (Aufgabe 3):** 65 Paare — 64 aus dem vorherigen Durchlauf
plus EIN neues Paar (`favorites.service.ts`/`widgetInstance`, Klasse
`muss-mandantengebunden`, Stand `gebunden`): der Besitzriegel in `create()`
(T-GWH-05, Aufgabe 1 Pruefung 7 hat den Fremdschluessel-Durchgriff
bestaetigt). Zwei Paare aendern nur ihre `Stand`-Spalte, keine ihrer Klasse:
`favorites.service.ts`/`favoriteLink` (`ungebunden` auf `gebunden`) und
`settings.service.ts`/`smtpConfig` (`ungebunden` auf `gemischt`). Das ist
der ENDSTAND der Etappe 2 — die Zahl ist der Ausgabe von
`rls-access-inventory.spec.ts` entnommen, nicht geschaetzt.

**Stand 260911-mkj (Aufgabe 1/2):** 72 Paare — 65 aus dem Endstand der
Etappe 2 plus SIEBEN neue Paare der vierten Erkennungsform (WINDOWS #27):
`groups/module-grants.service.ts`/`module` (`keine-mandantengebundene-tabelle`,
`gebunden`), `ldap/ldap-config.service.ts`/`tenant`
(`keine-mandantengebundene-tabelle`, `ungebunden`),
`module-registry/module-access.service.ts`/`group` UND `/groupMembership`
(beide `muss-mandantengebunden`, `gebunden`),
`tenders/tender-digest.scheduler.ts`/`tender`
(`keine-mandantengebundene-tabelle`, `gebunden`) UND `/tenderSavedSearch`
(`muss-mandantengebunden`, `gebunden`),
`tenders/tenders.controller.ts`/`tenderSource`
(`keine-mandantengebundene-tabelle`, `ungebunden`). Drei Paare aendern ihren
Stand, eines davon zusaetzlich die Klasse:
`ldap-config.service.ts`/`ldapFieldMapping` wechselt von
`muss-mandantengebunden`/`gebunden` auf `beides`/`gemischt` — der
uebergreifende Planer-Lesepfad `getAllActiveConfigs()` reicht ueber
`include: { fieldMappings: true }` in `LdapFieldMapping` hinein, dieselbe
Unterabfrage-Form, die WINDOWS #27 aufgedeckt hat.
`module-registry.service.ts`/`module` und `tender-matching.service.ts`/
`tender` wechseln je von `ungebunden` auf `gemischt`, ihre Klasse bleibt.
Die Zahl 72 ist der Ausgabe von `rls-access-inventory.spec.ts` entnommen,
nicht geschaetzt.

**Stand 260911-nke:** die Paarzahl (72) und die Klassen-Verteilung sind
UNVERÄNDERT — Etappe 3b (Benutzerdimension in den Regeln, `forTenant()`
bekommt ein drittes Argument) fügt keine neue Fundstelle hinzu und ändert
keine bestehende von mandanten-gebunden auf mandanten-ungebunden oder
umgekehrt; benutzer-gebunden ist keine eigene Klasse in diesem Schema. Die
Benutzerdimension steht stattdessen in der Begründungsspalte der drei
betroffenen Bestandsaufnahme-Zeilen (`calendarSource`, `widgetInstance`,
`favoriteLink`) oben und im Abschnitt "Was diese Etappe NICHT entscheidet".


**Stand 260914-eym:** die Paarzahl (72) und die Klassen-Verteilung sind
UNVERÄNDERT — die fünfte Erkennungsform (`const X = forSystem(`) bringt
keine neue Fundstelle und lässt keine verschwinden. Sieben Paare ändern nur
ihren Stand: SECHS auf den neuen Wert `system-gebunden` —
`dkv/dkv.service.ts`/`dkvModuleConfig`,
`ldap/ldap-config.service.ts`/`ldapConfig`, `/ldapFieldMapping`, `/tenant`,
`tenders/tender-digest.scheduler.ts`/`tenderMatch`,
`tenders/tender-matching.service.ts`/`tenderSavedSearch` — und EINES auf
`gebunden` (`settings/settings.service.ts`/`smtpConfig`, Startpfad
gelöscht). Der neue Stand-Wert bedeutet: mindestens ein Zugriff dieses
Paars läuft über den Systemkontext-Klienten und KEIN Zugriff ist ungebunden;
Vorrang: ungebunden vorhanden UND anderes → `gemischt`, nur ungebunden →
`ungebunden`, System ohne ungebunden → `system-gebunden` (auch neben
mandantengebundenen Zugriffen — die Begründungsspalte nennt sie), sonst
`gebunden`. Die Zahlen sind der Ausgabe von `rls-access-inventory.spec.ts`
entnommen (30 Zusicherungen, darunter der Wachhund
`FORSYSTEM_ALLOWED_CALL_SITES`).

| Klasse | Anzahl Paare |
|---|---|
| muss-mandantengebunden | 44 |
| keine-mandantengebundene-tabelle | 21 |
| beides | 16 |
| bewusst-uebergreifend | 2 |
| **Summe** | **83** |

quick-260923-dhh (Aufgabe 1): +2 `muss-mandantengebunden` (`proxmox.service.ts`/`proxmoxServer`
und `/proxmoxServerStatus`, beide `gebunden`) — nachgerechnet mit der Gate-Schleife, nicht
abgeschrieben.

quick-260929-9wc: nachgezaehlt mit `grep -cE '^\| apps/api/src/'` gegen die Bestandsaufnahme:
Vorher standen 78 Zeilen (41 `muss-mandantengebunden`) im Dokument, Ueberschrift und Tabelle
nannten aber noch 77 Paare/40 `muss-mandantengebunden` — Drift, eine Zeile war nach der
Tabelle hinzugekommen, ohne sie fortzuschreiben. Jetzt +1 `muss-mandantengebunden`
(`custom-modules.service.ts`/`customModule`, `gebunden`): 79 Paare, davon 42
`muss-mandantengebunden`, 21 `keine-mandantengebundene-tabelle`, 14 `beides`,
2 `bewusst-uebergreifend`.

quick-260929-dzu: keine neue (Datei, Modell)-Zeile, Verteilung unverändert (79 Paare); geändert
haben sich nur die Zeile `custom-modules.service.ts`/`customModule` (Benutzerdimension) und die
Bereichs-/Summenzeile (Gebunden 224→223, nachgemessen mit der Gate-Schleife).

quick-260929-if2 (Aufgabe 1): +1 `muss-mandantengebunden` (`reminders.service.ts`/`reminder`, `gebunden`):
80 Paare, davon 43 `muss-mandantengebunden`, 21 `keine-mandantengebundene-tabelle`, 14 `beides`,
2 `bewusst-uebergreifend` — nachgezaehlt mit `grep -cE '^\| apps/api/src/'` gegen die Bestandsaufnahme.

quick-260929-if2 (Aufgabe 3): +3 Paare (`reminders.service.ts`/`user` als `muss-mandantengebunden`,
`reminder-mail.scheduler.ts`/`reminder` und `/user` als `beides`): 83 Paare, davon 44
`muss-mandantengebunden`, 21 `keine-mandantengebundene-tabelle`, 16 `beides`,
2 `bewusst-uebergreifend` — nachgezaehlt mit `grep -cE '^\| apps/api/src/'` gegen die Bestandsaufnahme.

## Der Hintergrunddienst als Falle — sechs Fälle

Ein Planer, der über alle Mandanten iteriert, liest zu Recht übergreifend —
muss aber *innerhalb* der Schleife je Mandant binden. Vier Dateien sind in
diesem Sinne `beides`-Fälle, davon einer (260910-das) der bislang EINZIGE,
der auf BEIDEN Hälften bereits richtig ist; der fünfte, seit 260909-mir
bekannte Fall ist von anderer Art und deshalb unten getrennt aufgeführt — er
iteriert gar nicht, sondern greift sich eine beliebige Zeile heraus. Der
sechste Fall (seit 260911-gwh) ist von DERSELBEN Bauart wie der fünfte —
kein Iterieren, eine beliebige-aber-vorhandene Zeile, kein Mandantenkontext
beim Start — mit einer zusätzlichen Verdeckungsschicht, siehe unten:

- **`ldap.service.ts`** (AD-Abgleich) — **Stand 260909-ipc, Aufgaben 2/3:
  geschlossen.** Iteriert nicht selbst über alle Mandanten (der Sync läuft
  je Aufruf für einen übergebenen Mandanten). Vor dieser Etappe blieben
  Lesezugriffe auf `group`, `ldapConfig` und `user` innerhalb der
  Sync-Methoden teils ungebunden, obwohl der Mandant zu diesem Zeitpunkt
  bereits bekannt war — nur 4 der inzwischen 11 `forTenant()`-Aufrufstellen
  deckten die Lese-/Schreibpfade ab. Jetzt sind `group` und `ldapConfig`
  vollständig gebunden; bei `user` bleibt ausschließlich
  `resolveEmailForWrite` bewusst ungebunden (Befund A, T-IPC-04 — siehe
  Bestandsaufnahme unten). Der als gefährlichster Punkt benannte
  Löschzweig (`syncBoundGroupsForTenant`, WINDOWS #20) war bereits seit
  Etappe 1 gebunden. **Die seinerzeit offen geführte Reihenfolgebedingung
  für Etappe 4 — die Übergabe unmittelbar vor der Löschung
  (`this.groupsService.reassignDefaultBeforeDelete(tenantId, group.id)` und
  `ensureDefaultGroup(tenantId)` in `groups.service.ts`) — ist mit
  260909-jts (Aufgabe 2) GESCHLOSSEN:** beide Methoden laufen seither über
  `forTenant()`/`withTenantTransaction()` (siehe Bestandsaufnahme unten,
  `groups.service.ts`/`group`, Stand `gebunden`). Nachtrag, nicht
  Neuschrieb: der ursprüngliche Befund bleibt oben lesbar, weil er den
  Zustand zum Zeitpunkt der ldap-Umstellung korrekt beschreibt und für
  spätere Etappen als Beleg dient, siehe auch
  `docs/mandantentrennung-etappe2-fehlerrichtung.md`, Abschnitt (e), Befund D.

  **Nachtrag (260911-mkj):** WINDOWS #27 geschlossen — derselbe Bereich
  `ldap` traegt
  einen zweiten, bislang unsichtbaren Planer-Lesezugriff:
  `LdapConfigService.getAllActiveConfigs()` (`ldap-config.service.ts`)
  reicht ueber `include: { tenant: true, fieldMappings: true }` sowohl in
  `Tenant` (schutzlos, harmlos) als auch in `LdapFieldMapping` (geschuetzt
  ueber Join auf `LdapConfig`) hinein. Nach dem Scharfschalten verstummt
  die Feldzuordnung mit der Elternzeile, nicht getrennt von ihr — der
  Etappe-3-Systemkontext muss BEIDE Tabellen sehen. Die Bestandsaufnahme
  fuehrt `ldapFieldMapping` deshalb seither als `beides`/`gemischt` statt
  `muss-mandantengebunden`/`gebunden` (siehe Bestandsaufnahme unten,
  `ldap-config.service.ts`/`ldapFieldMapping`).
- **`tender-digest.scheduler.ts`** (Ausschreibungs-Digest) — **Stand
  260909-laa, Aufgabe 3: Je-Treffer-Hälfte geschlossen, übergreifende
  Hälfte an Etappe 3 übergeben.** Liest `tenderMatch` (Kandidatenabfrage,
  `findMany` mit `distinct: ['userId']`) bewusst über ALLE Mandanten in
  einem einzigen `findMany` (ein einziger globaler Cron-Job, kein Mandant
  im Job selbst — so von Anfang an entworfen, Pitfall 1 in den Kommentaren
  der Datei) — diese Kandidatenabfrage bleibt UNGEBUNDEN und ist im Code
  als Etappe-3-Übergabe kommentiert. Sie wählt zusätzlich das
  denormalisierte `tenantId` der Treffer-Zeile mit aus, damit die Schleife
  binden kann; der Sonderfall eines Nutzers mit Treffern unter zwei
  verschiedenen Mandanten (Mandantenwechsel) ist NICHT gelöst, siehe
  `docs/mandantentrennung-etappe2-fehlerrichtung.md`. Innerhalb der
  Schleife laufen `tenderNotificationPref.findUnique`,
  `tenderMatch.findMany`/`updateMany` und `user.findUnique` je
  Kandidatenzeile über `forTenant()`, gebunden an deren Mandanten.
- **`tender-matching.service.ts`** (Ausschreibungs-Sofortmeldung) —
  **Stand 260909-laa, Aufgabe 3: Je-Treffer-Hälfte geschlossen, übergreifende
  Hälfte an Etappe 3 übergeben.** `tenderSavedSearch.findMany` (Profile ALLER
  Mandanten) und der Lesezugriff auf den plattformweiten `tender`-Katalog
  (D-03) bleiben UNGEBUNDEN, beide im Code als Etappe-3-Übergabe bzw. D-03
  kommentiert. Innerhalb der Profilschleife laufen die Treffer-Anlage
  (`tenderMatch.upsert`) und — im nachgelagerten Instant-Dispatch —
  `tenderMatch.findMany`/`updateMany` sowie `user.findUnique` über
  `forTenant()`, EIN gebundener Client je Profil, gebunden an dessen
  Mandanten.
- **`admin-seed.service.ts`** (`ensureDefaultGroupsForAllTenants`) — **Stand
  260910-das, Aufgabe 2: der vierte Fall dieser Art und der bislang EINZIGE,
  der auf BEIDEN Hälften bereits richtig ist.** Liest `tenant.findMany()`
  bewusst über ALLE Mandanten (Treiber, ungebunden — `Tenant` trägt keinen
  Zeilenschutz, Aufgabe 1 gemessen, `tenant-tabelle-ohne-zeilenschutz-bleibt-lesbar`)
  und ruft je Mandant `groupsService.ensureDefaultGroup(tenant.id)` auf —
  dieser Rumpf ist seit 260909-jts vollständig über `forTenant()`/
  `withTenantTransaction()` gebunden (siehe Bestandsaufnahme,
  `groups.service.ts`/`group`, Stand `gebunden`). Anders als bei den drei
  Fällen oben musste hier in Aufgabe 2/3 (260910-das) NICHTS umgestellt
  werden — der Rumpf war es bereits, bevor der Bereich `user` überhaupt an
  der Reihe war. Einschränkung, bewusst nicht verschwiegen: der äußere
  `try/catch` in `ensureDefaultGroupsForAllTenants()` verschluckt jeden
  Fehler des Treibers (`tenant.findMany`) in eine Protokollzeile — läuft die
  Mandantenliste nach dem Scharfschalten aus irgendeinem Grund leer,
  entsteht keine Fehlermeldung, sondern gar keine Ausgabe (Befund K).

**Der fünfte Fall, anderer Bauart — `dkv-scheduler.service.ts` /
`DkvService.loadAnyActiveConfigForScheduler()`** (260909-mir, Befund D,
WINDOWS #21): **offen, als benannte Altlast weitergeführt.** Dieser Dienst
gehört nicht in dieselbe Klasse wie die drei oben. Jene lesen bewusst über alle
Mandanten und müssen lediglich innerhalb der Schleife binden — sie sind heute
korrekt und verstummen erst nach dem Scharfschalten. Der DKV-Planer iteriert
überhaupt nicht: `findFirst()` ohne jede Bedingung zieht bei mehreren Mandanten
EINEN beliebigen und bedient die übrigen NIE. Ist ausgerechnet die gezogene
Zeile inaktiv, bedient er niemanden, obwohl ein zweiter Mandant aktiv wäre. Er
ist damit **heute bereits falsch** und verstummt nach dem Scharfschalten
zusätzlich (`null` statt einer beliebigen Zeile; der Planer protokolliert das als
Normalfall und richtet für JEDEN Mandanten nichts ein, ohne Alarm).

Binden ist hier keine Lösung: `onModuleInit()` hat beim Start strukturell keinen
Mandantenkontext, ein gebundener Aufruf liefe garantiert leer. Der Umbau auf
einmal-abfragen-viele-bedienen ist die in Phase 07-04 zurückgestellte
Mehrmandanten-Planung — eine Funktionsänderung, kein Bindungsumbau, und deshalb
in Etappe 2 nicht vorgenommen. Der Zugriff bleibt deshalb ungebunden, aber
dreifach markiert: eigene benannte Methode mit Kopfkommentar (bewusst KEINE
Verzweigung hinter einem optionalen Parameter, die jemand später
„vereinheitlicht"), fortgeschriebener Kopfkommentar in
`dkv-scheduler.service.ts`, Ledger-Eintrag WINDOWS #21. Das Signal für das
Verstummen gehört in die Vorabprüfung von Etappe 4 (`rls-preflight.mjs`).

**Der sechste Fall, gleicher Bauart wie der fünfte — `mail.module.ts` /
`SettingsService.loadAnySmtpConfigForStartupTransport()`** (260911-gwh,
Befund D, WINDOWS #30): offen, als benannte Altlast weitergeführt. Dieselbe
Form wie der fünfte Fall — `findFirst()` ohne jede Bedingung zieht bei
mehreren Mandanten EINEN beliebigen und bedient die übrigen NIE; **heute
bereits falsch**, weil der SMTP-Server und die Absenderadresse EINES
beliebigen Mandanten die Kennwort-Zurücksetzungs- und Willkommensmails
ALLER Mandanten tragen (T-GWH-03, Nutzung fremder Zugangsdaten). Binden ist
auch hier keine Lösung: `useFactory` hat beim Start strukturell keinen
Mandantenkontext. Der Umbau auf Transport je Versand aus
`getDecryptedSmtpConfig(tenantId)` — die Form, die `DkvMailService`/
`TenderMailService` bereits haben — ist eine Funktionsänderung
(Umbau des Mailmoduls), kein Bindungsumbau, deshalb NICHT in Etappe 2
vorgenommen.

Die UNSYMMETRIE zu BEIDEN Präzedenzfällen: `ldap.service.ts`/
`getAllActiveConfigs` ist heute korrekt und verstummt erst später; der
DKV-Planer (fünfter Fall) ist heute bereits falsch und verstummt zusätzlich
später, ABER MIT einer Protokollzeile ("no active config found"). Der
Mail-Startpfad ist heute bereits falsch UND verstummt später OHNE
Protokollzeile, weil `mail.module.ts`s Rückfallkette (Priorität 2 `MAIL_*`,
3 `TESSERA_SMTP_*`, 4 `localhost:1025`) einen FALSCHEN, aber vorhandenen
Transport an die Stelle der Leere setzt — `MailService` fängt den
Transportfehler (T-02-12), der Controller antwortet `200`. Das Verstummen
ist damit DOPPELT verdeckt, eine dritte Ausprägung, die keiner der beiden
Vorlagen (`ldap`, `dkv`) vollständig entspricht.

Dreifache Markierung: eigene benannte Methode mit Kopfkommentar (dkv-
Präzedenzfall, ein Name, den niemand für einen Anfrageweg hält), Modul-
kommentar in `mail.module.ts`, Ledger-Eintrag WINDOWS #30 (EIGENER Eintrag
statt Anschluss an #21: andere Datei, andere Reparatur, andere
Verdeckungsform). Das Signal für das Verstummen gehört ebenfalls in die
Vorabprüfung von Etappe 4 (`rls-preflight.mjs`).

Befund K ist mit dieser Bindung ERFÜLLT: `getDecryptedSmtpConfig(tenantId)`
— der einzige Versandpfad von `tender-mail.service.ts` und
`dkv-mail.service.ts` — läuft seit 260911-gwh über `forTenant()`
(siehe Bestandsaufnahme-Zeile `settings.service.ts`/`smtpConfig` oben und
`docs/mandantentrennung-etappe2-fehlerrichtung.md`, Abschnitte "## Bereich
tenders" (t4) und "## Bereich dkv" (d4), jeweils Nachtrag 260911-gwh); die
Etappe-4-Vorabprüfung muss diese Reihenfolgebedingung ab jetzt NICHT mehr
führen.

**Stand 260911-gwh — der Bereich `favorites` fügt diesem Abschnitt keinen
weiteren Fall hinzu, gemessen statt angenommen (Befund K).** Anweisung:
`grep -rn "@Cron\|onModuleInit\|onApplicationBootstrap\|setInterval\|setTimeout" apps/api/src/favorites apps/api/src/settings --include=*.ts | grep -v spec`
liefert außerhalb von Testdateien genau EINEN Treffer,
`icon-discovery.service.ts:255` — ein `setTimeout` für den Abbruch eines
HTTP-Abrufs, kein Planer (dieselbe Form wie `ics.provider.ts:100` in
260911-cwh). Die Bauform dieses Abschnitts (übergreifend LESEN über alle
Mandanten, dann je Mandant BINDEN) kommt in `favorites` an keiner Stelle
vor; der einzige Hintergrund-Zugriff des Bereichspaares ist der oben
beschriebene sechste Fall, und der lebt nicht in `favorites`, sondern in
`mail.module.ts`/`settings.service.ts`.

**Stand 260910-exd — kein sechster Fall, gemessen statt angenommen.** Der
Bereich `module-registry` fügt diesem Abschnitt KEINEN sechsten Fall hinzu.
`ModuleRegistryService.seedModule()` (die Katalogpflege beim Start,
aufgerufen aus vier Seed-Dateien) schreibt zwar ohne Mandantenkontext — sie
iteriert aber über NICHTS je Mandant, sondern schreibt genau eine Zeile je
Aufruf auf den plattformweiten Katalog `Module`. Damit fehlt ihr die Bauform
der fünf oben geführten Fälle (übergreifend LESEN über alle Mandanten, dann
je Mandant BINDEN) — sie ist deshalb kein Kandidat für diese Liste. Dieser
Satz hält die Abwesenheit fest, damit sie nicht wie ein Übersehen aussieht.

**Stand 260910-krx — auch der Bereich `dashboard` fügt diesem Abschnitt
keinen sechsten Fall hinzu, gemessen statt angenommen.** Anweisung (260910-krx,
Aufgabe 1): `grep -rn "onModuleInit\|onApplicationBootstrap\|@Cron\|setInterval\|Scheduler" apps/api/src/dashboard --include=*.ts`
liefert null Treffer außerhalb von Testdateien — der einzige Dienst dieses
Bereichs, `dashboard.service.ts`, enthält keinen Hintergrunddienst, keinen
Planer und keinen Start-Hook. Jede seiner neun mandantengebundenen Methoden
wird ausschließlich synchron aus einer Anfrage eines einzelnen, bereits
bekannten Nutzers heraus aufgerufen — die Bauform dieses Abschnitts
(übergreifend LESEN über alle Mandanten, dann je Mandant BINDEN) kommt in
diesem Bereich an keiner Stelle vor.

**Stand 260911-cwh — auch der Bereich `calendar` fügt diesem Abschnitt
keinen sechsten Fall hinzu, gemessen statt angenommen (260911-cwh, Aufgabe 1,
Befund B).** `grep -rn "@Cron\|onModuleInit\|onApplicationBootstrap\|setInterval\|setTimeout" apps/api/src/calendar --include=*.ts`
liefert außerhalb von Testdateien genau einen Treffer,
`providers/ics.provider.ts:100` — ein `setTimeout` für den Abbruch eines
HTTP-Abrufs nach acht Sekunden, kein Planer. Der einzige Dienst dieses
Bereichs, `calendar.service.ts`, enthält keinen Hintergrunddienst, keinen
Planer und keinen Start-Hook — die Bauform dieses Abschnitts (übergreifend
LESEN über alle Mandanten, dann je Mandant BINDEN) kommt an keiner Stelle
vor. Es gibt aber einen benannten Sonderfall, anderer Bauart als die fünf
Fälle oben: `refreshCacheInBackground` (private Methode) ist eine
ABGEKOPPELTE FORTSETZUNG einer Anfrage — `aggregateEvents` stößt sie an,
wartet nicht auf sie, und sie ruft `fetchAndCacheEvents` mit den Parametern
der ursprünglichen Anfrage auf. Sie iteriert NICHT über mehrere Mandanten
und hat deshalb keine übergreifende Hälfte zu binden — sie trägt die
Mandantenkennung der Anfrage, die sie ausgelöst hat, und kann strukturell
keine andere haben. Kein Kandidat für diese Liste; dieser Absatz hält die
Abwesenheit fest, damit sie nicht wie ein Übersehen aussieht.

Auch der Bereich `tenant` fügt diesem Abschnitt keinen sechsten Fall hinzu,
gemessen statt angenommen (260911-e2s, Aufgabe 1, Befund J). Anweisung:
`grep -rn "@Cron\|onModuleInit\|onApplicationBootstrap\|setInterval\|setTimeout\|Scheduler" apps/api/src/tenant --include=*.ts`
und `grep -rn '\$transaction(\|\$queryRaw\|\$executeRaw' apps/api/src/tenant --include=*.ts`
liefern je null Treffer — kein Hintergrunddienst, kein Roh-SQL, keine
Transaktion in diesem Bereich. `TenantService.create` ruft nach dem Anlegen
eines Mandanten `groupsService.ensureDefaultGroup(tenant.id)` auf; dieser
Aufruf läuft seit 260909-jts bereits vollständig über den gebundenen Weg des
Bereichs `groups` (`forTenant()`/`withTenantTransaction()`, siehe
Fundstellentabelle unten, `groups.service.ts`/`group`, Stand `gebunden`) —
nichts an dieser Übergabe musste in 260911-e2s umgestellt werden.

**Stand 260911-fh9 — auch der Bereich `auth` fügt diesem Abschnitt keinen
sechsten Fall hinzu, gemessen statt angenommen (Befund J).** Anweisung:
`grep -rn "@Cron\|onModuleInit\|onApplicationBootstrap\|setInterval\|setTimeout" apps/api/src/auth --include=*.ts`
und `grep -rn '\$transaction(' apps/api/src/auth --include=*.ts` liefern je
null Treffer außerhalb von Testdateien — kein Hintergrunddienst, keine
Transaktion in diesem Bereich. `grep -rn "include:\|_count\|select:"
apps/api/src/auth --include=*.ts | grep -v spec` findet genau EINEN
Treffer, das `select` in `getMe` — ausschließlich skalare Felder von
`User`, keine Relation (WINDOWS #27 hier ohne Ausprägung). Die einzige
Stelle, an der dieser Bereich ohne Mandantenkontext liest, ist der
Anmeldeweg (`validateUser`, `requestPasswordReset`, `resetPassword`) —
geloest durch die drei SECURITY-DEFINER-Funktionen, nicht durch die Bauform
"übergreifend lesen, dann je Mandant binden".

**Regelschluss (260914-eym) — Etappe 3c hat den Systemkontext gebaut; je Fall:**

- **Regelschluss (260914-eym), Fall ldap** (`getAllActiveConfigs()` und die
  Nachverschlüsselung in `onApplicationBootstrap()`): beide Methoden lesen
  über `forSystem()` (`system_read_policy … FOR SELECT` auf LdapConfig und —
  für `include: { fieldMappings }` — auf LdapFieldMapping); die
  Nachverschlüsselung schreibt je Altzeile GEBUNDEN über
  `forTenant(this.prisma, config.tenantId)`, weil Schreiben unter
  Systemkontext abgewiesen wird (gemessen P2025/42501). `Tenant` braucht
  keine Regel. Der Detektor zählt zwei `forSystem(`-Aufrufe in dieser Datei.
- **Regelschluss (260914-eym), Fall tender-digest** (`runDigest`): die
  Kandidatenabfrage liest über `forSystem()` (Regel auf TenderMatch), die
  Schleife bleibt je Kandidatenzeile gebunden, bewusst ohne Benutzer.
- **Regelschluss (260914-eym), Fall tender-matching** (`matchDelta`): die
  Profilabfrage liest über `forSystem()` (Regel auf TenderSavedSearch);
  Treffer-Anlage und Sofortmeldung bleiben je Profil gebunden, der
  Katalog-Lesezugriff (`tender`, D-03) bleibt ungebunden.
- **Regelschluss (260914-eym), Fall admin-seed**: GEMESSEN — der einzige
  Lesezugriff außerhalb der Schleife ist `tenant.findMany` auf `Tenant`, das
  in keiner Migration `ENABLE ROW LEVEL SECURITY` trägt. Nichts umgebaut,
  Datei unverändert (Gate gegen `5e0e408`), nur dokumentiert; Stand bleibt
  `ungebunden`.
- **Regelschluss (260914-eym), fünfter Fall (DKV-Planer, WINDOWS #21
  GESCHLOSSEN)**: `loadActiveConfigsForScheduler()` liest über `forSystem()`
  ALLE aktiven Konfigurationen (Regel auf DkvModuleConfig), der Planer
  registriert je Mandant einen eigenen Auftrag `dkv-inbox-poll:<tenantId>`
  (einmal-abfragen-viele-bedienen); mit einem Mandanten beobachtbar
  identisch (Cron-Expression, Tick, Protokollzeile — je ein Test).
- **Regelschluss (260914-eym), sechster Fall (Mail-Startpfad, WINDOWS #30
  GESCHLOSSEN)**: der sechste Fall EXISTIERT NICHT MEHR — der Startpfad
  (`findFirst()` beim Boot) ist entfernt, nicht umgestellt; `MailService`
  baut je Versand einen Transport aus `getDecryptedSmtpConfig(tenantId)`
  des Empfänger-Mandanten. Deshalb trägt SmtpConfig keine
  `system_read_policy`.
- **Nachtrag quick-260929-if2 — neuer Fall: `reminder-mail.scheduler.ts`
  (E-Mail-Planer der Erinnerungen).** Gleiche Bauart wie der Digest
  (`tender-digest.scheduler.ts`): EIN globales Intervall alle 30 Sekunden
  liest die fälligen Erinnerungen über ALLE Mandanten und handelt danach je
  Zeile gebunden. Die Kandidatenabfrage läuft über `forSystem()`
  (`reminder.findMany`, `system_read_policy ... FOR SELECT` auf "Reminder",
  Migration 20260929140000) und ist bewusst nur skalar: ein `include:` oder
  `select:` auf `user` im Systemklienten machte `User` zum Systemlese-Modell
  (WINDOWS #27). Alles Weitere — der Anspruch (`updateMany` mit
  `emailSentAt: null`, atomar), das Laden von Zeile und Adresse, die
  Freigabe bei Transportfehler — läuft über `forTenant(prisma, c.tenantId)`
  ohne Benutzer. Eine leere Kandidatenliste ist Nichtstun. Ohne diese
  Regel sähe der Planer nach dem Scharfschalten keine Erinnerung und
  verstummte (zu-wenig-statt-zu-viel). `FORSYSTEM_ALLOWED_CALL_SITES` pinnt
  genau einen Aufruf in dieser Datei (neue Summe: 6 Dateien, 7 Aufrufe).

## Bestandsaufnahme

Maschinell ermittelt, `rls-access-inventory.spec.ts` hält Vollständigkeit
nach. Spalten: Datei, Modell (Prisma-Modellname wie in `this.prisma.<Modell>`
oder — seit 260909-ipc, Befund G — in `<gebundener Client>.<Modell>`
oder — seit 260914-eym — in `<System-Client>.<Modell>` verwendet), Klasse,
Stand (`gebunden`/`ungebunden`/`gemischt`/`system-gebunden`, seit
260909-ipc maschinell gegen den Quelltext geprüft), Begründung.

**Fünfte Erkennungsform und vierter Stand-Wert (260914-eym, Etappe 3c):**
`const <Name> = forSystem(` und danach `<Name>.<Modell>` — der benannte
Systemkontext der Hintergrunddienste (liest über ALLE Mandanten, nur lesend,
Regel `system_read_policy … FOR SELECT`). Relationsziele über `include`/
`select` auf einem System-Klienten zählen ebenfalls als system-gebunden.
Vorrang der Stände je Paar: ungebunden vorhanden UND anderes → `gemischt`;
nur ungebunden → `ungebunden`; Systemkontext vorhanden und KEIN ungebundener
Zugriff → `system-gebunden` (auch wenn daneben mandantengebundene Zugriffe
stehen — die Begründungsspalte nennt sie); nur mandantengebunden →
`gebunden`. Wer `forSystem(` rufen darf, steht mit EXAKTER Zahl je Datei in
`FORSYSTEM_ALLOWED_CALL_SITES` (Detektor) — jede Fremddatei, jede Abweichung
der Zahl und jeder veraltete Eintrag machen die Spec rot.

**Erkennungslücke GESCHLOSSEN (260911-mkj, WINDOWS #27):** bis 260911-e2s sah
die Bestandsaufnahme ausschließlich (Datei, Modell)-Paare über
`this.prisma.<Modell>` bzw. `<gebundener Client>.<Modell>` — eine
Relationseinbindung (`include:`, `select:`, Relationszähler `_count`) in
eine ZWEITE Tabelle erzeugte kein eigenes Paar und war für das Werkzeug
strukturell unsichtbar, obwohl Prisma sie als Unterabfrage/Join auf die
zweite Tabelle unter DEREN Regel rendert. Eine vierte Erkennungsform in
`rls-access-inventory.spec.ts` (`analyzeSource`, `SCHEMA_RELATIONS`) löst
Relationsfelder über `schema.prisma` auf ihr Zielmodell auf und trägt das
Zielmodell seither als eigene Fundstelle derselben Datei — gebunden, wenn
der Empfänger des erkannten Modellaufrufs gebunden ist, sonst ungebunden.
Das erfasst `include:`, `select:`, `_count: { select: ... }`, `_count:
true`, Relationsfilter in `where:`, `orderBy:` über Relationen und
verschachtelte Schreibzugriffe in `data:`.

Bewusst NICHT gesehen, und wie das begrenzt ist: ein Empfänger außerhalb der
fünf Erkennungsformen (`this.prisma`, eine `const X = forTenant(`-Zuweisung,
ein Transaktionsparameter, `withTenantTransaction(`, seit 260914-eym eine
`const X = forSystem(`-Zuweisung) — begrenzt durch den
Waechter Rohzahl (`include|select|_count` über den gesamten kommentarfreien
Quelltext) gegen die innerhalb erkannter Aufrufe gezählte Zahl, mit
begründeter Ausnahmeliste `RELATION_SPEC_EXCEPTIONS`; ein `include:`/
`select:`-Wert aus einer fremden Datei oder ohne aufzulösende Konstante —
begrenzt durch den Wertform-Waechter (`unresolvedRelationSpecValues`); die
Kurzschreibweise `include: { x }` — gemessen null Vorkommen im gesamten
API-Quelltext, kein Prisma-Idiom für diese drei Schlüssel; eine
Vorlagen-Interpolation (`${tx.user.count()}`) — zählt in der Rohzahl und
fällt damit laut, statt still zu verschwinden.

Gemessen (260911-mkj, Ausgabe von `rls-access-inventory.spec.ts`): SIEBEN
neue Paare, DREI fortgeschriebene Stände, EINE Ausnahmedatei
(`RELATION_SPEC_EXCEPTIONS`). Die einzige zur Planungszeit bereits bekannte
gefährliche Ausprägung (ungebundener äußerer Aufruf auf einer
UNGESCHÜTZTEN Tabelle, Einbindung in eine GESCHÜTZTE Tabelle) war
`tenant.controller.ts` — bereits in 260911-e2s behoben (Fan-out ersetzt den
Relationszähler), von der vierten Erkennung erneut bestätigt: kein
Relationszugriff mehr dort. Seit 260911-mkj führt die Spalte `Modell` auch
RELATIONSZIELE, die in der Datei selbst nie als `<Klient>.<Modell>` stehen,
sondern nur über den Schlüsselpfad eines erkannten Modellaufrufs sichtbar
werden.

| Datei | Modell | Klasse | Stand | Begründung |
|---|---|---|---|---|
| apps/api/src/auth/auth.service.ts | passwordResetToken | muss-mandantengebunden | gebunden | Kein eigenes `tenantId`, RLS ueber Join auf `User` (Migration 20260618112133). `requestPasswordReset`/`resetPassword` laufen vollstaendig ueber `forTenant()` (Etappe 1, WINDOWS #20, Aufgabe 1) — von der alten, nur `this.prisma.*` erkennenden Suche nie erfasst, weil bereits gebunden; die erweiterte Erkennung aus Aufgabe 2 (260909-ipc) macht diese Fundstelle erstmals sichtbar. |
| apps/api/src/auth/auth.service.ts | user | muss-mandantengebunden | gebunden | Klassenkorrektur (260911-fh9, Aufgabe 2/3): wechselt von `gemischt` auf `gebunden` — `getMe`, `changePassword`, `adminResetPassword` binden seit Aufgabe 2 je über GENAU EINEN Klienten `tenantPrisma` an den Mandanten aus dem Sitzungsnachweis (`@CurrentUser().tenantId`); für die oberste Rolle (SUPER_ADMIN) löst der Controller den Mandanten des ZIELS über den gebundenen Fan-out `UserService.findByIdForPlatformAdmin` auf. `adminResetPassword` verweigert zusätzlich einem Nicht-SUPER_ADMIN das Kennwort eines SUPER_ADMIN (T-FH9-04). Die drei Anmeldesuchen (`validateUser`, `requestPasswordReset`, `resetPassword`) laufen weiterhin über die drei SECURITY-DEFINER-Funktionen (`$queryRaw`, keine Modellzugriffe — `$` liegt nicht in `[a-zA-Z]`) und bleiben unverändert auf dem ungebundenen Klienten. Etappe-3-Vorbehalt: die Bindung hängt am Claim `tenantId` und an `User.id` (plattformweite UUID), nicht an `username`/`email` — der Anmeldeweg-Umbau für je Mandant eindeutige Anmeldenamen betrifft diese Bindung nicht, siehe `docs/mandantentrennung-etappe2-fehlerrichtung.md`, Abschnitt "## Bereich auth", (h4)(a). |
| apps/api/src/bug-reports/bug-reports.service.ts | user | muss-mandantengebunden | gebunden | Fehler-melden-Knopf (quick-260914-m97): eine gebundene Leseoperation auf die Zeile des angemeldeten Benutzers (Anzeigename, E-Mail, Rolle fuer den Bericht), Mandant ausschliesslich aus dem Sitzungsnachweis. |
| apps/api/src/calendar/calendar.service.ts | calendarSource | muss-mandantengebunden | gebunden | Kalenderquellen eines Nutzers je Mandant gebunden (encryptedPassword traegt Zugangsdaten zu externen Exchange-/CalDAV-Servern), `tenantId`-Spalte vorhanden. Seit 260911-cwh (Aufgabe 2) laufen alle zwoelf Zugriffe (`getSources`, `addSource`, beide Abfragen von `updateSource`/`deleteSource`, alle drei Abfragen von `testConnection`, Laden plus beide Synchronstatus-Rueckschreibungen von `fetchAndCacheEvents`) ueber `forTenant()`, ein Klient je Methode; `fetchAndCacheEvents`/`refreshCacheInBackground` nehmen die Mandantenkennung als Parameter, Letztere traegt die Kennung der urspruenglichen Anfrage. Die drei Besitzpruefungen (`updateSource`/`deleteSource`/`testConnection`, Vergleich gegen `userId` aus dem Sitzungsnachweis) bleiben zusaetzlich bestehen — die Regel auf `CalendarSource` kennt keine Benutzerdimension (260911-cwh, Aufgabe 1, gemessen), sie sind bis zur Etappe-3-Entscheidung (2) der einzige Schutz zwischen Kollegen DESSELBEN Mandanten. Benutzerdimension seit 20260911120000 (260911-nke). |
| apps/api/src/dashboard/dashboard-images.service.ts | dashboardImage | muss-mandantengebunden | gebunden | **quick-260924-m4n:** Stand zurück von `system-gebunden` auf `gebunden`. Stufe 2 der Umstellung (Migration 20260924120000_dashboard_image_drop_data) löscht die Spalte `data` und macht `storagePath` zur Pflicht; der Bootstrap-Umzug hatte auf allen Servern gearbeitet und ist samt seinem einzigen `forSystem()`-Aufruf entfernt (Eintrag aus `FORSYSTEM_ALLOWED_CALL_SITES` gestrichen). Dieselbe Migration entfernt die `system_read_policy` auf "DashboardImage" — auf der Tabelle bleibt allein `tenant_isolation_policy` (Mandant UND Benutzer). Alle vier Anfragewege laufen wie bisher ausschließlich über `forTenant(this.prisma, tenantId, userId)`; der Upload vergibt die UUID jetzt selbst und legt die Zeile gleich mit Pfad an. Vorher: **260922-hk4:** Stand von `gebunden` auf `system-gebunden` — NICHT weil ein Anfrageweg aufgeweicht wurde, sondern weil EIN Startpfad dazugekommen ist: `onApplicationBootstrap()` zieht die Bilder einmalig aus der Spalte `data` in den Dateibereich (`user-files/dashboard-images/<userId>/<id>.<ext>`) und muss dafür die noch nicht umgezogenen Zeilen ALLER Mandanten sehen (`const systemPrisma = forSystem(this.prisma)`, ein Aufruf, Erlaubnisliste in `rls-access-inventory.spec.ts`; Leserecht über `system_read_policy … FOR SELECT` auf "DashboardImage", Migration 20260922120000). GESCHRIEBEN wird auch dort je Zeile über `forTenant(prisma, row.tenantId, row.userId)` — einmal-lesen-viele-bedienen, Muster DKV-Planer. Die Bytes selbst liegen seither auf der Platte, die Zeile hält nur noch `storagePath` (Muster `User.avatarPath`); der Dateiname ist IMMER servergeneriert (UUID der Zeile + Endung aus dem ERKANNTEN Mime-Typ), `originalName` kommt in keinem Pfad vor (T-HK4-01). Alle vier Anfragewege sind unverändert mandantengebunden: Hochgeladene Bilder des Bilderrahmen-Widgets (quick-260921-pi9), gehoeren dem hochladenden Benutzer; `tenantId`-Spalte vorhanden, Regel `tenant_isolation_policy` MIT Benutzerdimension von Anfang an (Migration 20260921120000, Form aus 20260911120000). Alle vier Methoden (`list`, `upload`, `getBytes`, `remove`) holen je einen Klienten `const tenantPrisma = forTenant(this.prisma, tenantId, userId)`; Liste und Zaehler filtern zusaetzlich explizit `where: { tenantId, userId }`, `getBytes`/`remove` pruefen den Besitz anwendungsseitig (`row.userId !== userId || row.tenantId !== tenantId` -> 404, nie 403) — zweites Netz, kein Ersatz, weil der RLS-Schalter heute aus ist. `select` der Liste/Upload-Antwort ohne `data` (Bytes nur ueber `GET :id`). |
| apps/api/src/dashboard/dashboard-images.service.ts | user | muss-mandantengebunden | gebunden | **quick-260930:** `remove` setzt im selben Vorgang die Hintergrund-Wahl des Benutzers (`User.dashboardBackground`) auf `{ kind: 'none' }` zurück, wenn sie auf das gelöschte Bild zeigte — ein bedingtes `updateMany` mit `where: { id: userId, dashboardBackground: { path: ['imageId'], equals: id } }` über denselben gebundenen Klienten `forTenant(this.prisma, tenantId, userId)` wie der Rest der Methode. Nur die eigene Zeile, kein Kennungsparameter von außen (die Bild-Kennung ist zu diesem Zeitpunkt schon als eigenes Bild geprüft). |
| apps/api/src/dashboard/dashboard.service.ts | dashboard | muss-mandantengebunden | gebunden | quick-260923-ad9 — Reiter (mehrere Dashboards je Benutzer), `tenantId`-Spalte vorhanden, Regel `tenant_isolation_policy` MIT Benutzerdimension von Anfang an (Migration 20260923120000, Form aus 20260911120000/20260921120000). Task 1: `listDashboards` liest ueber `forTenant()` und legt bei Bedarf genau einen Reiter an (Transaktionssperre `pg_advisory_xact_lock` innerhalb `withTenantTransaction`, T-AD9-07); der Riegel `assertOwnedDashboard` liest ueber DENSELBEN, bereits gebundenen Klienten des Aufrufers (kein zweiter `forTenant()`-Aufruf) und wirft fuer "gibt es nicht", "gehoert einem Kollegen" und "liegt bei einem fremden Mandanten" dieselbe `NotFoundException` (T-AD9-01/02/03). Task 2: `createDashboard`/`renameDashboard` laufen als Einzeloperationen ueber `forTenant()`, je Methode ein Klient (Riegel zuerst bei `renameDashboard`). `deleteDashboard`/`reorderDashboards` laufen je als EINE `withTenantTransaction` (mehrschrittig, muss atomar sein) — `withTenantTransaction` setzt KEINE Benutzerdimension in der Sitzung, deshalb traegt jede Bedingung `userId` selbst (`tx.dashboard.deleteMany({where:{id,userId}})`, `tx.dashboard.updateMany({where:{id,userId},...})`), wortgleiches Muster zu `favorites.service.ts`/`reorder` (260917-jdd). `deleteDashboard` entfernt zusaetzlich die Kacheln (`tx.widgetInstance.deleteMany`) und die Anordnung (`tx.dashboardLayout.deleteMany`) des Reiters in DERSELBEN Transaktion. |
| apps/api/src/dashboard/dashboard.service.ts | dashboardLayout | muss-mandantengebunden | gebunden | Anordnung eines Reiters, `tenantId`-Spalte vorhanden. Seit 260910-krx (Aufgabe 2) laufen `getLayout`/`saveLayout` GEMEINSAM ueber `forTenant()`, ein Klient je Methode; `saveLayout` uebersetzt eine `PrismaClientUnknownRequestError` (RLS-Konflikt, gemessen in Aufgabe 1 — NICHT die `P2002`-Form, die der Bereich `tenders` abfaengt) in eine deutsche Konfliktmeldung. quick-260923-ad9 (Task 1): die eindeutige Spalte ist jetzt `dashboardId` statt `userId` (D-02) — beide Methoden pruefen vorher ueber `assertOwnedDashboard`, dass der Reiter dem Aufrufer gehoert. |
| apps/api/src/dashboard/dashboard.service.ts | favoriteLink | muss-mandantengebunden | gebunden | quick-260923-lrr — nur LESEND, zum Aufraeumen hochgeladener Favoriten-Symbole: `removeWidget` und `deleteDashboard` lesen VOR dem Loeschen die Favoriten mit hochgeladenem Symbol (`findMany`, Bedingung traegt `userId` UND `widgetId`) ueber DENSELBEN, bereits gebundenen Klienten `tenantPrisma` der Methode (kein zweiter `forTenant()`-Aufruf). Die Zeilen selbst verschwinden ueber den Fremdschluessel-Kaskadenweg; danach werden die Dateien best effort entfernt, ein Dateifehler bricht das Loeschen nie ab. |
| apps/api/src/dashboard/dashboard.service.ts | module | keine-mandantengebundene-tabelle | ungebunden | Modulkatalog ist plattformweit, kein `tenantId` (Migration 20260909140000, Gruppe b). MESSUNG (260910-krx, Aufgabe 1, uebernommen aus `module-registry`-Pruefung `module-tabelle-traegt-keinen-zeilenschutz`): die Tabelle traegt heute keinen Zeilenschutz, eine Bindung waere heute wirkungslos, nicht katastrophal. BEDINGUNG: katastrophal wuerde sie erst, WENN Etappe 3 dieser Tabelle eine Regel gibt. Die Katalogaufloesung fuer den Widget-Modulfilter (`ModuleAccessService.getAccessibleModuleIds`) bindet bereits seit 260910-exd in ihrem eigenen Dienst — hier NICHT ein zweites Mal gebunden. |
| apps/api/src/dashboard/dashboard.service.ts | searchProvider | muss-mandantengebunden | gebunden | `tenantId` nullbar. WINDOWS #19 geschlossen (260910-jab) als **widerlegte Prämisse** für dieses Modell. In diesem Durchlauf (260910-krx, Aufgabe 1) EIGENSTAENDIG nachgeprueft, nicht aus 260910-jab abgeschrieben: `grep -rn "searchProvider\|SearchProvider" apps packages prisma --include=*.ts --include=*.mjs --include=*.js --include=*.sql --include=*.json` (ohne `node_modules`, `dist/`, `.next/`) findet weiterhin genau einen Schreibweg, `dashboard.service.ts:addSearchProvider` (`create`), mit `tenantId: string` als Pflichtparameter — keine Seed-Datei, kein Skript. Seit Aufgabe 2/3 laufen `getSearchProviders`/`addSearchProvider`/`removeSearchProvider` ueber `forTenant()`; die Regel auf `SearchProvider` bleibt UNVERAENDERT streng, zusaetzlich datenbankseitig verteidigt durch `searchprovider-gebundenes-einfuegen-ohne-mandant-abgelehnt` (Aufgabe 1). |
| apps/api/src/dashboard/dashboard.service.ts | widgetInstance | muss-mandantengebunden | gebunden | Platzierte Kacheln eines Reiters, `tenantId`-Spalte vorhanden. Seit 260910-krx (Aufgabe 2) laufen `getWidgets`, `addWidget` sowie beide Paare aus Besitzpruefung und Schreibzugriff (`updateWidgetConfig`/`removeWidget`) ueber `forTenant()`; die vorgeschalteten Besitzpruefungen ueber die Benutzerkennung bleiben zusaetzlich bestehen (die Regeln dieses Bereichs kennen keine Benutzerdimension). Benutzerdimension seit 20260911120000 (260911-nke). quick-260923-ad9 (Task 1): `getWidgets`/`addWidget` filtern/schreiben ueber `dashboardId` statt `userId` (D-02) — `assertOwnedDashboard` prueft vorher, dass der Reiter dem Aufrufer gehoert. |
| apps/api/src/dkv/dkv.service.ts | dkvInvoiceHistory | muss-mandantengebunden | gebunden | DKV-Rechnungshistorie je Mandant, `tenantId`-Spalte vorhanden. Seit 260909-mir (Aufgabe 3) laufen beide Historien-Schreibzugriffe der Verarbeitungsstrecke, beide parallelen Lesezugriffe von `getHistory` und der neue Riegel vor dem Ausfuhrdatei-Download vollstaendig ueber `forTenant()`. |
| apps/api/src/dkv/dkv.service.ts | dkvModuleConfig | muss-mandantengebunden | system-gebunden | Postfach-/Zugangsdaten des DKV-Moduls je Mandant. Seit 260909-mir (Aufgabe 2) laufen `loadConfig`, `getConfigForApi`, `saveConfig`, `testConnection` und der Konfigurations-Lesezugriff der Verarbeitungsstrecke ueber `forTenant()`. Seit 260914-eym liest der Planer-Startpfad `loadActiveConfigsForScheduler()` ueber `forSystem()` (alle aktiven Konfigurationen, nur lesend, `system_read_policy`) — kein ungebundener Zugriff mehr, WINDOWS #21 geschlossen; alle uebrigen Zugriffe bleiben mandantengebunden (Stand-Vorrang: system ohne ungebunden = `system-gebunden`). |
| apps/api/src/dkv/dkv.service.ts | dkvVehicleMaster | muss-mandantengebunden | gebunden | Fahrzeugstammdaten des DKV-Moduls je Mandant. Seit 260909-mir (Aufgabe 3) laufen Fahrzeugliste, Anlegen, beide Paare aus Besitzpruefung und Schreibzugriff (Aendern/Loeschen), beide Zweige des CSV-Imports und der gebuendelte Lesezugriff beim Aufbau der Ausfuhrzeilen vollstaendig ueber `forTenant()`; die vorgeschalteten Besitzpruefungen bei Aendern/Loeschen bleiben zusaetzlich bestehen (Befund G — ein gebundenes UPDATE ueber die Kennung allein trifft eine fremde Zeile still, nicht laut). |
| apps/api/src/favorites/favorites.service.ts | favoriteLink | muss-mandantengebunden | gebunden | Favoriten-Links eines Nutzers, `tenantId`-Spalte vorhanden. Seit 260911-gwh (Aufgabe 2) laufen `list`, `create`, `update`, `remove`, `getIconBytes` vollstaendig ueber `forTenant()`, je Methode EIN Klient `tenantPrisma`; die Besitzpruefungen (`findUnique`, Vergleich `link.userId !== userId`, dann Schreibzugriff auf DEMSELBEN Klienten) bleiben zusaetzlich bestehen — die Regel auf `FavoriteLink` kennt keine Benutzerdimension (Aufgabe 1, Pruefung 4), die `userId`-Filter sind bis zur Etappe-3-Entscheidung (2) der einzige Schutz gegen Quer-Lesen zwischen Nutzern DESSELBEN Mandanten. Die Mandantenquelle ist dieselbe wie bei `dashboard` (`extractContext` im Controller), nicht das Claim wie bei `auth`. Benutzerdimension seit 20260911120000 (260911-nke). Nachtrag (260917-jdd): `reorder()` laeuft als Mehrschritt ueber `withTenantTransaction()` (einzige gemessene atomare Form, siehe prisma-tenant.extension.ts) — diese Form setzt KEINE Benutzerdimension in der Sitzung, deshalb traegt jede Bedingung innerhalb der Transaktion `userId` UND `widgetId`; der Stand bleibt `gebunden` (Erkennungsform 2 des Detektors). |
| apps/api/src/favorites/favorites.service.ts | widgetInstance | muss-mandantengebunden | gebunden | NEUE Fundstelle (260911-gwh, Aufgabe 2): `create()` prueft ueber einen gebundenen `widgetInstance.findUnique` (`select: { userId: true }`), dass das Ziel-Widget (`dto.widgetId`) dem Aufrufer gehoert, BEVOR die Zeile angelegt wird — der Fremdschluessel `FavoriteLink.widgetId` prueft an der Zeilenschutz-Regel von `WidgetInstance` VORBEI (dokumentiertes PostgreSQL-Verhalten, Aufgabe 1 Pruefung 7 hat das GELINGEN eines gebundenen `create` mit einer fremdmandantigen `widgetId` bestaetigt); ohne den Riegel waere der Unterschied zwischen "Widget existiert nicht" (FK-Verletzung) und "gehoert einem fremden Mandanten" (gelingt) ein Existenzorakel ueber Mandantengrenzen (T-GWH-05). |
| apps/api/src/groups/groups.service.ts | group | muss-mandantengebunden | gebunden | Gruppen sind je Mandant, `tenantId`-Spalte vorhanden. Alle 12 Methoden laufen seit 260909-jts (Aufgabe 2) ueber `forTenant()` bzw. `withTenantTransaction()`. |
| apps/api/src/groups/groups.service.ts | groupMembership | muss-mandantengebunden | gebunden | Kein eigenes `tenantId`, RLS über Join auf `Group` (Migration 20260618112133-Nachfolger) — braucht trotzdem `forTenant()`, damit der Join-Kontext gesetzt ist. Seit 260909-jts gebunden, einschliesslich der drei Zugriffe innerhalb des Standardgruppen-Aufbaus (`ensureDefaultGroup`), die zuvor ueber den Transaktionsparameter liefen und fuer keine Pruefung dieses Projekts sichtbar waren (Befund B). |
| apps/api/src/groups/groups.service.ts | moduleGrant | muss-mandantengebunden | gebunden | Modulfreigaben je Mandant, `tenantId`-Spalte vorhanden. Seit 260909-jts gebunden, einschliesslich des Zugriffs innerhalb des Standardgruppen-Aufbaus (Befund B). |
| apps/api/src/groups/groups.service.ts | tenantModuleActivation | muss-mandantengebunden | gebunden | Welche Module ein Mandant aktiviert hat. Bis 260909-jts vollstaendig unsichtbar (Befund B, 260909-jts-PLAN.md): der einzige Zugriff dieser Datei lief innerhalb der interaktiven Transaktion von `ensureDefaultGroup` ueber den Rueckgabeparameter (`tx.tenantModuleActivation.findMany`) — weder `this.prisma.<Modell>` noch `<gebundener Client>.<Modell>` sahen das, weil `tx` weder `this.prisma` noch aus einer `forTenant(`-Zuweisung stammte. Die um Transaktionsparameter erweiterte Erkennung aus Aufgabe 2 macht dieses Paar erstmals sichtbar; die Stelle ist seit derselben Aufgabe gebunden (ueber `withTenantTransaction()`). |
| apps/api/src/groups/groups.service.ts | user | muss-mandantengebunden | gebunden | Nutzerverwaltung innerhalb eines Mandanten. Seit 260909-jts gebunden; `addUserToDefaultGroup` prueft seither zusaetzlich, dass der Zielbenutzer zum Mandanten gehoert (Befund E, T-JTS-02). Bis 20260910120000_rls_widen_membership_grant_and_platform_read pruefte die Regel auf `GroupMembership` nachweislich nur die Gruppenseite — seit 260910-jab prueft sie beide Seiten, die Anwendungspruefung bleibt trotzdem bestehen (Schalter weiterhin aus, #18). |
| apps/api/src/groups/module-grants.service.ts | group | muss-mandantengebunden | gebunden | Wie groups.service.ts. Seit 260909-jts (Aufgabe 3) gebunden — `assertTargetBelongsToTenant` erzeugt seinen eigenen Kontext, `getMatrix` teilt sich einen Kontext mit den beiden anderen parallelen Teilabfragen. |
| apps/api/src/groups/module-grants.service.ts | groupMembership | muss-mandantengebunden | gebunden | Kein eigenes `tenantId`, RLS über Join auf `Group`. Seit 260909-jts gebunden; der `where`-Filter über die Beziehung zur Gruppe bleibt zusätzlich stehen, weil die Regel auf dieser Tabelle nachweislich nur die Gruppenseite prüft (Aufgabe 1). |
| apps/api/src/groups/module-grants.service.ts | module | keine-mandantengebundene-tabelle | gebunden | NEUE Fundstelle (260911-mkj, WINDOWS #27): nur ueber `include: { module: true }` auf `tenantPrisma.tenantModuleActivation.findMany` erreicht (`getMatrix`, Zeilen 196 und 253). `Module` traegt plattformweit keinen Zeilenschutz (Migration 20260909140000, Gruppe b) — die Bindung des Elternaufrufs ist fuer die Unterabfrage wirkungslos, nicht schaedlich, dieselbe Einordnung wie `module-registry.service.ts`/`module` unten. |
| apps/api/src/groups/module-grants.service.ts | moduleGrant | muss-mandantengebunden | gebunden | Modulfreigaben je Mandant. Seit 260909-jts gebunden; die Mandanten-Gegenprüfung vor jedem Erteilen (`assertTargetBelongsToTenant`) bleibt zusätzlich bestehen. Bis 20260910120000_rls_widen_membership_grant_and_platform_read prüfte die Regel auf dieser Tabelle nur die Mandantenkennung der Zeile, nicht die referenzierte Gruppe/den referenzierten Benutzer (Befund F, T-JTS-03, Aufgabe 1) — seit 260910-jab prüft sie beide Ziele zusätzlich, die Anwendungsprüfung bleibt trotzdem der erste Schutz (Schalter weiterhin aus, #18). |
| apps/api/src/groups/module-grants.service.ts | tenantModuleActivation | muss-mandantengebunden | gebunden | Welche Module ein Mandant aktiviert hat, `tenantId`-Spalte vorhanden. Seit 260909-jts gebunden. |
| apps/api/src/groups/module-grants.service.ts | user | muss-mandantengebunden | gebunden | Zielbenutzer eines Grants innerhalb des Mandanten. Seit 260909-jts gebunden; die Mandanten-Gegenprüfung bleibt bestehen. |
| apps/api/src/ldap/ldap-config.service.ts | ldapConfig | beides | system-gebunden | `getConfig`, `createConfig` und `updateConfig` laufen ueber `forTenant()`, gebunden an den aus der Anfrage bereits bekannten Mandanten. `getAllActiveConfigs()` (Planer-Lesezugriff ueber ALLE Mandanten) und die Start-Nachverschluesselung in `onApplicationBootstrap` laufen, bevor bzw. unabhaengig davon, ob ein einzelner Mandantenkontext feststeht (Befund B, 260909-ipc-PLAN.md) — seit 260914-eym lesen beide ueber `forSystem()` (`system_read_policy`), die Schreibzeile je Altzeile der Nachverschluesselung laeuft ueber `forTenant(this.prisma, config.tenantId)`; kein ungebundener Zugriff mehr. Korrektur der Klasse von `muss-mandantengebunden`: das Paar ist tatsaechlich `beides`, keine Verhaltensaenderung. |
| apps/api/src/ldap/ldap-config.service.ts | ldapFieldMapping | beides | system-gebunden | Klassenkorrektur (260911-mkj, WINDOWS #27): wechselt von `muss-mandantengebunden` auf `beides`. Kein eigenes `tenantId`, RLS ueber Join auf `LdapConfig`. `addFieldMapping` und `removeFieldMapping` nehmen den Mandanten als Parameter entgegen und laufen vollstaendig ueber `forTenant()` (T-IPC-01, 260909-ipc-PLAN.md) — schliesst zugleich die Fremdzugriffsluecke beim Loeschen einer Feldzuordnung ueber ihre Kennung. Die vierte Erkennung (260911-mkj) macht sichtbar, dass der bewusst uebergreifende Planer-Lesepfad `getAllActiveConfigs()` ueber `include: { fieldMappings: true }` in `LdapFieldMapping` hineinreicht — dieselbe Unterabfrage-Form wie die drei `tenant`-Zaehler aus WINDOWS #27, hier aber KEIN neuer Befund: der Elternpfad ist als erster Fall der Hintergrunddienst-Falle bereits an Etappe 3 uebergeben, die Feldzuordnungen teilen nach dem Scharfschalten sein Schicksal (Regel auf `LdapFieldMapping` ueber Join auf `LdapConfig`, Migration 20260618112133). Die Klasse folgt der Elternzeile `ldapConfig` (`beides`). Seit 260914-eym liest der Elternpfad ueber `forSystem()`, das Relationsziel ist damit `system-gebunden` und traegt eine eigene `system_read_policy` (Migration 20260914120000). |
| apps/api/src/ldap/ldap-config.service.ts | tenant | keine-mandantengebundene-tabelle | system-gebunden | NEUE Fundstelle (260911-mkj, WINDOWS #27): `getAllActiveConfigs()` `include: { tenant: true, fieldMappings: true }` auf `ldapConfig.findMany`; `Tenant` traegt keinen Zeilenschutz (260911-e2s Aufgabe 1, `tenant-tabelle-ohne-zeilenschutz-bleibt-lesbar`). Seit 260914-eym laeuft der Ankeraufruf ueber `forSystem()` — der Stand folgt dem Empfaenger (`system-gebunden`), eine Regel braucht `Tenant` weiterhin nicht. |
| apps/api/src/ldap/ldap.service.ts | group | beides | gebunden | AD-Abgleich: `listGroups` (die "bereits importiert"-Markierung) und `importGroupsByDn` (die Idempotenzpruefung ueber `ldapObjectGuid`) sind mit Aufgabe 3 (260909-ipc) auf `forTenant()` umgestellt — zusammen mit den bereits vorher gebundenen Stellen (Anlage, Mitgliedschafts- und Gruppenabgleich) ist damit jeder `group`-Zugriff dieser Datei gebunden. Die Klasse bleibt `beides`, weil ein zukuenftiger uebergreifender Lesezugriff (z. B. ein neuer Planer-Pfad) hier ebenso legitim waere wie bei `ldapConfig` unten — nicht, weil heute noch ein ungebundener Zugriff bestuende. |
| apps/api/src/ldap/ldap.service.ts | groupMembership | muss-mandantengebunden | gebunden | Kein eigenes `tenantId`, RLS ueber Join auf `Group`. `syncGroupMembershipsForTenant` laeuft vollstaendig ueber `forTenant()` (Plan 16-03/16-05) — von der alten, nur `this.prisma.*` erkennenden Suche nie erfasst, weil bereits gebunden; die erweiterte Erkennung aus Aufgabe 2 (260909-ipc) macht diese Fundstelle erstmals sichtbar. |
| apps/api/src/ldap/ldap.service.ts | ldapConfig | beides | gebunden | Die `lastSyncAt`-Fortschreibung am Ende von `syncUsersForTenant` ist mit Aufgabe 3 (260909-ipc) auf den in derselben Methode bereits vorhandenen `forTenant()`-Client umgestellt — es entsteht kein zweiter. Damit ist der einzige `ldapConfig`-Zugriff dieser Datei gebunden. |
| apps/api/src/ldap/ldap.service.ts | user | beides | gemischt | Mit Aufgabe 3 (260909-ipc) sind `upsertMappedUser` (Identitaetssuche und Aktualisierung), `searchUsers` (die "bereits importiert"-Markierung), `importUsersByDn` (Dedup und ldapDn-Nachtrag) und die Deaktivierungsschleife in `syncUsersForTenant` auf `forTenant()` umgestellt. `resolveEmailForWrite` bleibt ausdruecklich UNGEBUNDEN (Befund A, T-IPC-04): `email`/`username` sind plattformweit eindeutig, eine mandantengebundene Suche saehe einen fremden Halter nicht mehr und meldete faelschlich "frei" — die geloeste Klasse waere `muss-mandantengebunden` gewesen, bleibt wegen dieser einen bewusst uebergreifenden Abfrage `beides`. Der Loeschzweig um `syncBoundGroupsForTenant` (WINDOWS #20) ist bereits seit Etappe 1 gebunden und war nie Teil dieses Befunds. |
| apps/api/src/module-registry/module-access.service.ts | group | muss-mandantengebunden | gebunden | NEUE Fundstelle (260911-mkj, WINDOWS #27): Relationsfilter `where: { tenantId, group: { memberships: { some: { userId } } } }` auf `tenantPrisma.moduleGrant.findMany` (Zeile 73, `getAccessibleModuleIds`, Gruppenweg). Prisma rendert das als Unterabfrage auf `Group` unter DEREN Regel; der Klient ist gebunden, `Group` gehoert demselben Mandanten. |
| apps/api/src/module-registry/module-access.service.ts | groupMembership | muss-mandantengebunden | gebunden | NEUE Fundstelle (260911-mkj, WINDOWS #27): derselbe Relationsfilter wie bei `group` oben, zwei Ebenen tief (`group > memberships`) auf `tenantPrisma.moduleGrant.findMany` (Zeile 73). Prisma rendert das als Unterabfrage auf `GroupMembership` unter DEREN Regel; gebunden, derselbe Mandant. |
| apps/api/src/module-registry/module-access.service.ts | module | keine-mandantengebundene-tabelle | ungebunden | Modulkatalog ist plattformweit, kein `tenantId`. Bleibt bewusst ungebunden (260910-exd, Aufgabe 1, Befund E): keine Regel auf der Tabelle, eine Bindung waere heute wirkungslos, nicht katastrophal — katastrophal erst, WENN Etappe 3 dieser Tabelle eine Regel gibt. |
| apps/api/src/module-registry/module-access.service.ts | moduleGrant | muss-mandantengebunden | gebunden | Modulfreigaben je Mandant. Seit 260910-exd (Aufgabe 2) laufen Direktweg und Gruppenweg von `getAccessibleModuleIds` ueber `forTenant()`, EIN Klient je Methode. |
| apps/api/src/module-registry/module-access.service.ts | tenantModuleActivation | muss-mandantengebunden | gebunden | Aktivierung je Mandant, `tenantId`-Spalte vorhanden. Seit 260910-exd (Aufgabe 2) laufen Kurzschlusszweig, Schnittmengenabfrage und der eigene Lesezugriff von `getCatalogFlags` ueber `forTenant()`. |
| apps/api/src/module-registry/module-registry.service.ts | module | keine-mandantengebundene-tabelle | gemischt | Stand-Aenderung (260911-mkj, WINDOWS #27): `ungebunden` -> `gemischt`, Klasse bleibt. Modulkatalog ist plattformweit. Der ungebundene Anteil bleibt bewusst so (260910-exd, Aufgabe 1, Befund E): keine Regel auf der Tabelle, eine Bindung waere heute wirkungslos, nicht katastrophal — katastrophal erst, WENN Etappe 3 dieser Tabelle eine Regel gibt. `findBySlug` ist zusaetzlich die Stelle, die `ModuleGuard` bei JEDER Modulanfrage aufruft. Die neu sichtbare gebundene Haelfte stammt ausschliesslich aus `include: { module: true }` auf `tenantPrisma.tenantModuleActivation` (Zeilen 56, 97, 148) — fuer die schutzlose Katalogtabelle wirkungslos, nicht schaedlich. |
| apps/api/src/module-registry/module-registry.service.ts | tenantModuleActivation | muss-mandantengebunden | gebunden | Aktivierung je Mandant. Seit 260910-exd (Aufgabe 3) laufen `findActiveForTenant`, `activateForTenant`, beide Zugriffe von `deactivateForTenant` (ueber EINEN Klienten) und `isModuleActive` ueber `forTenant()`, je Methode EIN Klient. |
| apps/api/src/settings/settings.service.ts | smtpConfig | muss-mandantengebunden | gebunden | SMTP-Zugangsdaten je Mandant, `tenantId`-Spalte vorhanden. Seit 260911-gwh (Aufgabe 2) laufen `getSmtpConfig`, `saveSmtpConfig`, `getDecryptedSmtpConfig` ueber `forTenant()`. Der bis 260914-eym einzige ungebundene Zugriff — der Startpfad des Mailmoduls (`findFirst()` beim Boot, WINDOWS #30, sechster Fall der Hintergrunddienst-Falle) — ist GELOESCHT: `MailService` baut je Versand einen Transport aus `getDecryptedSmtpConfig(tenantId)` des Empfaenger-Mandanten. Befund K (`tender-mail.service.ts`/`dkv-mail.service.ts`/`mail.service.ts` haengen an `getDecryptedSmtpConfig`) ist damit erfuellt. |
| apps/api/src/tenant/tenant.controller.ts | tenant | keine-mandantengebundene-tabelle | ungebunden | `Tenant` ist die Mandantentabelle selbst — hat keine eigene `tenantId`-Spalte, kann sie per Definition nicht haben (Migration 20260909140000, Gruppe b). Gemessen 260911-e2s (Aufgabe 1, Prüfung 1/2): keine Regel auf `Tenant` in irgendeiner der 34 ausgelieferten Migrationen einschließlich `20260910120000_rls_widen_membership_grant_and_platform_read`; gebunden und ungebunden liefern über Roh-SQL UND generierten Client dieselben Zeilen. |
| apps/api/src/tenant/tenant.controller.ts | user | muss-mandantengebunden | gebunden | Seit 260911-e2s (Aufgabe 3): `findAll`/`findOne`/`remove` zählen Benutzer je Mandant über drei gebundene Aufrufstellen (`tenantPrisma.user.count`, Fan-out-Muster aus `UserService.findAllForPlatformAdmin`) statt über den früheren Relationszähler (`include: { _count: { select: { users } } }`), der nach dem Scharfschalten unter der Regel von `User` unbemerkt null geliefert hätte (260911-e2s Aufgabe 1, Prüfungen 5-7). `where: { tenantId }` bleibt heute (Rolle mit BYPASSRLS, WINDOWS #18) der einzige wirksame Filter. |
| apps/api/src/tenant/tenant.service.ts | tenant | keine-mandantengebundene-tabelle | ungebunden | Dieselbe Begründung. Gemessen 260911-e2s (Aufgabe 1, Prüfung 1/2): keine Regel auf `Tenant` in irgendeiner der 34 ausgelieferten Migrationen einschließlich `20260910120000_rls_widen_membership_grant_and_platform_read`. |
| apps/api/src/tenders/adapters/email-alert.adapter.ts | tenderEmailConfig | bewusst-uebergreifend | ungebunden | `fetchTenders()` liest bewusst jede aktive `TenderEmailConfig`-Zeile über ALLE Mandanten in einer Abfrage (Plattform-Scheduler, ein Tick pro Postfach, D-13/D-01) — ausführlich im Dateikopf begründet, darf laut Kommentar niemals in `forTenant()` verpackt werden. |
| apps/api/src/tenders/adapters/rss.adapter.ts | tenderRssFeedSource | bewusst-uebergreifend | ungebunden | Fan-out über jeden aktiven Feed, plattformweit UND persönlich, in einer Abfrage (Zeilen 55–83 im Dateikopf begründet) — dieselbe Scheduler-Ebene wie beim E-Mail-Adapter. |
| apps/api/src/tenders/tender-dedup.service.ts | tender | keine-mandantengebundene-tabelle | ungebunden | Explizit im Dateikopf: "platform-global, RLS-exempt tables. Never wrap these queries in forTenant()." (D-03) |
| apps/api/src/tenders/tender-dedup.service.ts | tenderSource | keine-mandantengebundene-tabelle | ungebunden | Dieselbe Begründung. |
| apps/api/src/tenders/tender-digest.scheduler.ts | tender | keine-mandantengebundene-tabelle | gebunden | NEUE Fundstelle (260911-mkj, WINDOWS #27): `include: { tender: true, savedSearch: true }` auf `tenantPrisma.tenderMatch.findMany` (Zeile 149) innerhalb der Mandantenschleife des Planers. `Tender` ist der plattformglobale Katalog (D-03) — die Bindung des Elternaufrufs ist fuer die Unterabfrage wirkungslos, nicht schaedlich. |
| apps/api/src/tenders/tender-digest.scheduler.ts | tenderMatch | beides | system-gebunden | Ein einziger globaler Cron-Job liest über ALLE Mandanten (bewusst übergreifend, Pitfall-1-Kommentar im Dateikopf) — seit 260909-laa (Aufgabe 3) laufen die Je-Treffer-Abfrage (`findMany` nach Mandant) und die Stempelung (`updateMany`) je Kandidatenzeile über `forTenant()`; seit 260914-eym liest die Kandidatenabfrage (`findMany` mit `distinct`) über `forSystem()` (`system_read_policy`, nur lesend) statt ungebunden. |
| apps/api/src/tenders/tender-digest.scheduler.ts | tenderNotificationPref | beides | gebunden | Präferenzen werden je Kandidatenzeile gelesen. Seit 260909-laa (Aufgabe 3) läuft der einzige Zugriff über `forTenant()`, gebunden an den Mandanten der jeweiligen Zeile. |
| apps/api/src/tenders/tender-digest.scheduler.ts | tenderSavedSearch | muss-mandantengebunden | gebunden | NEUE Fundstelle (260911-mkj, WINDOWS #27): `include: { savedSearch: true }` plus `orderBy` ueber `savedSearch` auf `tenantPrisma.tenderMatch.findMany` (Zeile 149) innerhalb der Mandantenschleife des Planers. `TenderSavedSearch` ist mandantengebunden und ueber denselben gebundenen Klienten erreicht. |
| apps/api/src/tenders/tender-digest.scheduler.ts | user | beides | gebunden | E-Mail-Adressen für den Versand werden je Kandidatenzeile gelesen. Seit 260909-laa (Aufgabe 3) läuft der einzige Zugriff über `forTenant()`. |
| apps/api/src/tenders/tender-email-config.service.ts | tenderEmailConfig | muss-mandantengebunden | gebunden | Nutzer-CRUD für die eigene Postfachanbindung (Phase 17, D-01) — anders als der Fan-out-Adapter oben, hier ist der Mandant aus der Anfrage bekannt. Seit 260909-laa (Aufgabe 2) laufen `getConfigForApi` (beide Lesezugriffe), `saveConfig` und `testConnection` vollständig über `forTenant()`. |
| apps/api/src/tenders/tender-fingerprint-backfill.service.ts | tender | keine-mandantengebundene-tabelle | ungebunden | Einmaliges Backfill-Skript über den plattformweiten `Tender`-Katalog (D-03). |
| apps/api/src/tenders/tender-ingestion.service.ts | tender | keine-mandantengebundene-tabelle | ungebunden | Explizit im Dateikopf: "Multi-tenant safety (D-03, T-10-09): uses the plain, non-tenant-scoped ... queries ... these are platform-global". |
| apps/api/src/tenders/tender-ingestion.service.ts | tenderSourcePollConfig | keine-mandantengebundene-tabelle | ungebunden | Plattformweiter Poll-Status, kein `tenantId` (Migration 20260909140000, Gruppe b). |
| apps/api/src/tenders/tender-matching.service.ts | tender | keine-mandantengebundene-tabelle | gemischt | Stand-Aenderung (260911-mkj, WINDOWS #27): `ungebunden` -> `gemischt`, Klasse bleibt. Liest den plattformweiten Katalog (D-03), um Treffer zu berechnen — kein `tenantId`. Die neu sichtbare gebundene Haelfte stammt aus `include: { tender: true }` auf `tenantPrisma.tenderMatch.findMany` (Zeile 139) im Sofortmeldungs-Dispatch — fuer die schutzlose Katalogtabelle wirkungslos, nicht schaedlich. |
| apps/api/src/tenders/tender-matching.service.ts | tenderMatch | beides | gebunden | Sofortmeldung — siehe Abschnitt "Der Hintergrunddienst als Falle". Seit 260909-laa (Aufgabe 3) laufen sowohl die Treffer-Anlage (`upsert`) als auch der Instant-Dispatch (`findMany`/`updateMany`) vollständig über `forTenant()`, EIN gebundener Client je Profil. |
| apps/api/src/tenders/tender-matching.service.ts | tenderSavedSearch | beides | system-gebunden | Gespeicherte Suchprofile ALLER Mandanten werden gegen neue Treffer geprüft — bewusst übergreifend; seit 260914-eym über `forSystem()` (`system_read_policy`, nur lesend), die Etappe-3-Übergabe aus 260909-laa ist damit eingelöst. Treffer-Anlage und Sofortmeldung bleiben je Profil gebunden. |
| apps/api/src/tenders/tender-matching.service.ts | user | beides | gebunden | E-Mail-Adressen für die Sofortmeldung. Seit 260909-laa (Aufgabe 3) läuft der einzige Zugriff über `forTenant()`, gebunden an den Mandanten des jeweiligen Profils. |
| apps/api/src/tenders/tender-notification-pref.service.ts | tenderNotificationPref | muss-mandantengebunden | gebunden | Nutzer-CRUD für die eigenen Benachrichtigungseinstellungen — Mandant aus der Anfrage bekannt. Seit 260909-laa (Aufgabe 2) laufen `getForUser`/`setForUser` vollständig über `forTenant()`; `setForUser` übersetzt eine P2002-Verletzung (Befund F) in eine verständliche deutsche Meldung. |
| apps/api/src/tenders/tender-rss-feed.service.ts | tenderRssFeedSource | beides | gemischt | Nutzer-CRUD für die eigenen RSS-Quellen (anders als der Fan-out in `adapters/rss.adapter.ts`). Seit 260909-laa (Aufgabe 2) bindet `createForUser` (Zähler + Anlage, beide ausschließlich auf persönlichen Zeilen mit gesetztem Mandanten) über `forTenant()`. Seit 260910-jab (Aufgabe 2, WINDOWS #19 geschlossen) bindet zusätzlich `listForUser` — die neue Leseregel (`tenant_platform_read_policy`, 20260910120000_rls_widen_membership_grant_and_platform_read) schließt die plattformweite Zeile ausdrücklich ein, ungebunden hätte die Reparatur den Pfad sonst still auf nur die plattformweiten Zeilen reduziert (Befund F). `createPlatform`/`remove` bleiben bewusst ungebunden — beide Pfade lassen sich unter der Anwendungsrolle grundsätzlich nicht anlegen/entfernen, weil jede Schreibregel einen Mandanten verlangt (WINDOWS #24, eigener offener Punkt). Klasse `beides` bleibt korrekt: zwei gebundene, zwei bewusst ungebundene Zugriffe in derselben Datei. |
| apps/api/src/tenders/tender-saved-search.service.ts | tenderSavedSearch | muss-mandantengebunden | gebunden | Nutzer-CRUD für die eigenen gespeicherten Suchprofile — Mandant aus der Anfrage bekannt. Seit 260909-laa (Aufgabe 2) laufen `list`/`create`/`update`/`remove` vollständig über `forTenant()`. |
| apps/api/src/tenders/tender-scheduler.service.ts | tenderSourcePollConfig | keine-mandantengebundene-tabelle | ungebunden | Plattformweiter DÖE-Poll-Status, kein `tenantId` — im Dateikopf explizit als "genuine platform-wide singleton" begründet. |
| apps/api/src/tenders/tender-triage.service.ts | tenderTriage | muss-mandantengebunden | gebunden | Favorisierungs-/Ablehnungsstatus eines Nutzers, `tenantId`-Spalte vorhanden. Seit 260909-laa (Aufgabe 2) laufen `setTriage`/`listForUser`/`favoriteIds` vollständig über `forTenant()`. |
| apps/api/src/tenders/tenders.controller.ts | tender | keine-mandantengebundene-tabelle | ungebunden | Lesezugriff auf den plattformweiten Katalog (D-03). |
| apps/api/src/tenders/tenders.controller.ts | tenderSource | keine-mandantengebundene-tabelle | ungebunden | NEUE Fundstelle (260911-mkj, WINDOWS #27): `getTender` (Zeile 612) `include: { sources: { select: ... } }` auf `this.prisma.tender.findUnique`; `TenderSource` plattformweit ohne Zeilenschutz (dieselbe Einordnung wie `tender-dedup.service.ts`/`tenderSource`). |
| apps/api/src/tenders/tenders.controller.ts | tenderSourcePollConfig | keine-mandantengebundene-tabelle | ungebunden | Plattformweiter Poll-Status, admin-verwaltet, kein `tenantId`. |
| apps/api/src/tenders/tenders.module.ts | tenderSourcePollConfig | keine-mandantengebundene-tabelle | ungebunden | Singleton-Bestückung beim Boot — im Dateikopf explizit als "global, RLS-exempt (D-03)" begründet. |
| apps/api/src/user/admin-seed.service.ts | tenant | keine-mandantengebundene-tabelle | ungebunden | Legt beim ersten Start den Standard-Mandanten selbst an und liest beim Start alle Mandanten fuer die Standardgruppen-Reparatur — `Tenant` hat keine `tenantId`-Spalte und traegt keinen Zeilenschutz (Aufgabe 1, `tenant-tabelle-ohne-zeilenschutz-bleibt-lesbar`). Fuenfter und bislang einziger bereits vollstaendig richtiger Fall der Hintergrunddienst-Falle (Befund K, siehe Abschnitt unten). 3c-Befund (260914-eym): einziger Lesezugriff außerhalb der Schleife, `Tenant` ohne Regel — kein Systemkontext nötig, Datei unverändert, Stand bleibt `ungebunden`. |
| apps/api/src/user/admin-seed.service.ts | user | beides | gemischt | Klassenkorrektur (260910-das, Aufgabe 3): wechselt von `bewusst-uebergreifend` auf `beides`, weil die bisherige Begruendung ("es gibt strukturell keinen Mandanten zum Binden") nachweislich FALSCH war (Befund J) — der Mandant wird eine Anweisung vorher angelegt und ist bekannt. Die Erstanlage-Pruefung bleibt bewusst ungebunden (kein Mandant existiert zu diesem Zeitpunkt, `username` ist plattformweit eindeutig); die Erstanlage des Administrators selbst laeuft seit Aufgabe 2 ueber `forTenant()`, gebunden an den unmittelbar zuvor angelegten Mandanten. Eine P2002-Kollision beim Anlegen wird wie "Administrator existiert bereits" behandelt statt den Start abzubrechen (Befund I). |
| apps/api/src/user/user.controller.ts | user | muss-mandantengebunden | gebunden | Nutzerverwaltung innerhalb des Mandanten des anfragenden Admins (260910-das, Aufgabe 3): die Benutzerliste des ADMIN-Zweigs, alle drei Kennungswege (rollenabhaengig ueber `UserService.findById`/`findByIdForPlatformAdmin`) und alle fuenf Selbstbedienungszugriffe (Bild hochladen/loeschen/ausliefern, Akzentfarbe) laufen ueber `forTenant()`; seit quick-260925-bow ebenso die drei Zugriffe der zwei Selbstbedienungswege des „Was ist neu“-Fensters (`GET me/release-notice` liest, `POST me/release-seen` liest und schreibt `lastSeenReleaseVersion`), weiterhin `forTenant()` mit `where: { id: currentUser.id }` und ohne Kennungsparameter; seit quick-260928-ujj schreibt der Selbstbedienungsweg `PATCH me/dashboard-background` das Feld `dashboardBackground` (vorher geprueft durch `parseDashboardBackground` aus `@tessera/shared`), ebenfalls `forTenant()` mit `where: { id: currentUser.id }` und ohne Kennungsparameter; die Rollenverzweigung zwischen mandantengebundener ADMIN-Sicht und der uebergreifenden `SUPER_ADMIN`-Sicht (ueber `UserService.findAllForPlatformAdmin`) bleibt bestehen. Der wirkungslose Selbstloesch-Riegel (Befund H, verglich gegen `currentUser.sub`, ein im Sitzungsnachweis nicht existierendes Feld) ist auf `currentUser.id` korrigiert. |
| apps/api/src/user/user.service.ts | tenant | keine-mandantengebundene-tabelle | ungebunden | Schleifentreiber der neuen Plattform-Administratorsicht (`findAllForPlatformAdmin`/`findByIdForPlatformAdmin`, 260910-das, Aufgabe 2, Befund F/N) — `Tenant` hat keine `tenantId`-Spalte und traegt keinen Zeilenschutz (Aufgabe 1, `tenant-tabelle-ohne-zeilenschutz-bleibt-lesbar`). |
| apps/api/src/user/user.service.ts | user | beides | gemischt | Klassenkorrektur (260910-das, Aufgabe 3): wechselt von `muss-mandantengebunden` auf `beides` wegen der einen bewusst ungebundenen Suche — wortgleich derselbe Praezedenzfall wie `ldap.service.ts`/`user` in 260909-ipc (`resolveEmailForWrite`). `findById`/`create`/`update`/`deactivate`/`delete` sowie die beiden neuen Plattform-Administratorsicht-Methoden laufen ueber `forTenant()`; `create`/`update` uebersetzen eine plattformweite Eindeutigkeitsverletzung (P2002) in eine deutsche Konfliktmeldung ohne Halter/Mandant zu nennen. `findByUsername` bleibt bewusst UNGEBUNDEN: der Anmeldeweg laeuft seit Etappe 1 ueber die drei SECURITY-DEFINER-Funktionen und hat diese Methode nicht mehr als Aufrufer (260910-das, Aufgabe 1, Teil 3: genau ein Treffer, die eigene Definition); eine gebundene Suche saehe einen fremden Halter des plattformweit eindeutigen `username` nicht und meldete faelschlich "frei". |
| apps/api/src/proxmox/proxmox.service.ts | proxmoxServer | muss-mandantengebunden | system-gebunden | **quick-260923-dhh, Aufgabe 4:** Stand von `gebunden` auf `system-gebunden` — NICHT weil ein Anfrageweg aufgeweicht wurde, sondern weil EIN Startpfad dazugekommen ist: `loadActiveServersForScheduler()` liest beim Start des Planers `const systemPrisma = forSystem(this.prisma);` (ein Aufruf, Erlaubnisliste in `rls-access-inventory.spec.ts`; Leserecht ueber `system_read_policy … FOR SELECT` auf "ProxmoxServer", Migration 20260923140000) — der Planer muss die aktiven Server ALLER Mandanten sehen, um je Mandant einen Cron-Auftrag zu registrieren (Muster `DkvSchedulerService`). GESCHRIEBEN wird auch dort nur je Zeile gebunden. Sechs mandantengebundene Zugriffe blieben nach Aufgabe 4 bestehen: `createServer` (`proxmoxServer.create`), `listWithStatus` (`findMany`), `pollServer` (`findUnique`, mit `include: { status: true }` fuer die Zehn-Sekunden-Sperre), `testConnection` (`findUnique`), `listActiveServerIdsForTenant` (`findMany`), `loadActiveServersForTenantScheduling` (`findMany` auf `proxmoxServer`, `select: { pollIntervalMin: true }`). **Aufgabe 5** ergaenzt vier weitere: `updateServer` (`findUnique` UND `update`) und `deleteServer` (`findUnique` UND `delete`), je ein Klient je Methode — macht zehn mandantengebundene `proxmoxServer`-Rohtreffer insgesamt, plus der eine System-Rohtreffer aus Aufgabe 4. Vorher (Aufgabe 1): vom Administrator eingetragene Proxmox-Server (PVE/PBS/PMG), `tenantId`-Spalte vorhanden, Regel `tenant_isolation_policy` OHNE Benutzerdimension (Migration 20260923140000, Form aus `DkvModuleConfig`) — Verwaltungsdaten des Mandanten, nicht persoenliche Daten eines Benutzers. `listWithStatus` waehlt die beiden Geheimnisfelder (`encryptedTokenSecret`/`encryptedPassword`) per `select` gar nicht erst aus (T-DHH-01). |
| apps/api/src/proxmox/proxmox.service.ts | proxmoxServerStatus | muss-mandantengebunden | gebunden | quick-260923-dhh, Aufgabe 1/4 — Zwischenlager je Server (D-05), `tenantId`-Spalte vorhanden, Regel `tenant_isolation_policy` OHNE Benutzerdimension (Migration 20260923140000, dieselbe Form wie `proxmoxServer`). `pollServer` schreibt ueber `tenantPrisma.proxmoxServerStatus.upsert()`, DENSELBEN Klienten wie das Lesen des Servers in derselben Methode; dieselbe Methode liest zusaetzlich `include: { status: true }` fuer die Zehn-Sekunden-Sperre (Aufgabe 4, T-DHH-06) — ebenfalls ueber den gebundenen Klienten. Bewusst KEINE `system_read_policy` auf dieser Tabelle (anders als `proxmoxServer`) — der Planer-Startpfad liest nur die Serverzeilen, das Zwischenlager wird ausschliesslich je Mandant gebunden geschrieben, ein Systemlesezugriff hat keinen Aufrufer. |
| apps/api/src/custom-modules/custom-modules.service.ts | customModule | muss-mandantengebunden | gebunden | **quick-260929-9wc:** neu — vom Administrator angelegte Seitenleisten-Eintraege („Eigene Module“, Name, https-Adresse, Kategorie), fuer alle Benutzer des Mandanten sichtbar. `tenantId`-Spalte vorhanden, Regel `tenant_isolation_policy` OHNE Benutzerdimension (Migration 20260929120000, Form aus `ProxmoxServer`) — Verwaltungsdaten des Mandanten, nicht persoenliche Daten eines Benutzers. Bewusst KEINE `system_read_policy`: es gibt keinen Hintergrunddienst, der eigene Module ueber alle Mandanten liest. Sieben mandantengebundene Rohtreffer, je Methode ein eigener Klient (`const tenantPrisma = forTenant(this.prisma, tenantId)`): `list` (`findMany` mit `where: { tenantId }`), `getOne` (`findUnique`), `create`, `update` (`findUnique` UND `update`), `remove` (`findUnique` UND `delete`). `getOne`/`update`/`remove` pruefen zusaetzlich `row.tenantId !== tenantId` und antworten mit 404 — zweites Netz, solange der RLS-Schalter aus ist (Muster `dashboardImage`). **quick-260929-dzu — persönliche Einträge:** neue Spalte `ownerUserId` (NULL = gemeinsam, gesetzt = persönlich, nur für den Besitzer sichtbar). Klasse und Stand unverändert (`muss-mandantengebunden`, `gebunden`); der Zeilenschutz bekommt die Benutzerdimension nach dem Muster `SearchProvider` (Migration 20260929130000): vier nach Befehl getrennte Regeln — Lesen: Mandant UND (kein Benutzer gesetzt ODER `ownerUserId` NULL ODER eigene Zeile), Schreiben (INSERT/UPDATE/DELETE): Mandant UND (kein Benutzer gesetzt ODER eigene Zeile). Persönliche Zugriffe binden mit Benutzer (`forTenant(prisma, tenantId, user.id)`); das Schreiben GEMEINSAMER Einträge bindet bewusst OHNE Benutzer, weil die Regel einem Benutzerkontext das Schreiben gemeinsamer Zeilen verwehrt — davor prüft der Dienst die Rolle (nur Administrator, sonst 403). Fremde persönliche Einträge sind für jeden anderen Benutzer, auch Administratoren, ununterscheidbar 404. Sechs mandantengebundene Rohtreffer (siehe Bereichszeile). |
| apps/api/src/reminders/reminders.service.ts | reminder | muss-mandantengebunden | gebunden | **quick-260929-if2:** neu — persönliche, einmalige Erinnerungen des Dashboard-Widgets „Erinnerungen“ (Titel, Beschreibung, Fälligkeit). `tenantId`- und `userId`-Spalte vorhanden, Regel `tenant_isolation_policy` MIT Benutzerdimension (Migration 20260929140000, Form aus `DashboardImage`): Mandant UND (kein Benutzer gesetzt ODER eigene Zeile). Jede Methode bindet mit Mandant UND Benutzer (`const tenantPrisma = forTenant(this.prisma, tenantId, userId)`), jedes `where` trägt zusätzlich `tenantId` und `userId` (Anwendungspruefung, solange der RLS-Schalter aus ist). Fremde oder unbekannte Kennungen sind ununterscheidbar 404, nie 403 (D-05). Sieben mandantengebundene Rohtreffer: `list` (`findMany`), `create` (`count` und `create`), `update` (`update`), `snooze` (`update`), `remove` (`delete`) und die gemeinsame Besitzprüfung `loadOwn` (`findFirst` mit `where: { id, tenantId, userId }`, für `update`/`snooze`/`remove`). Das Verschieben setzt `emailSentAt` und `emailAttempts` zurück (D-03). |
| apps/api/src/reminders/reminders.service.ts | user | muss-mandantengebunden | gebunden | quick-260929-if2 (Aufgabe 3): `getEmailAvailability` liest die eigene E-Mail-Adresse des Aufrufers (`user.findFirst` mit `where: { id: userId, tenantId }`), gebunden mit Mandant UND Benutzer über denselben Klienten wie die übrigen Zugriffe der Methode. Grundlage für den Schalter „zusätzlich per E-Mail“ und die 400-Antwort bei `emailEnabled` ohne Adresse. |
| apps/api/src/reminders/reminder-mail.scheduler.ts | reminder | beides | system-gebunden | quick-260929-if2 (Aufgabe 3): der E-Mail-Planer der Erinnerungen ist ein globales 30-Sekunden-Intervall über ALLE Mandanten (bewusst übergreifend, siehe Dateikopf). Die Kandidatenabfrage (`findMany`, nur skalarer Select, `take 200`) liest über `forSystem()` (`system_read_policy ... FOR SELECT`, Migration 20260929140000, nur lesend); Anspruch (`updateMany`), Laden (`findFirst`) und Freigabe (`updateMany`) laufen je Kandidatenzeile über `forTenant(prisma, c.tenantId)`. Der Anspruch ist atomar (`emailSentAt: null` und unveränderte `dueAt` in der Bedingung), damit mehrere Instanzen nie doppelt senden. |
| apps/api/src/reminders/reminder-mail.scheduler.ts | user | beides | gebunden | quick-260929-if2 (Aufgabe 3): die Empfängeradresse wird je Kandidatenzeile gelesen (`user.findFirst` mit `where: { id, tenantId }`), gebunden an den Mandanten dieser Zeile — bewusst NICHT als Relation im Systemklienten der Kandidatenabfrage (sonst würde `User` zum Systemlese-Modell). |

## Was diese Etappe NICHT entscheidet

- ~~Ob Controller künftig über `req.tenantPrisma` statt eines erneuten
  `forTenant()`-Aufrufs im Service gehen (offener Befund oben). Der Bereich
  `ldap` (260909-ipc) hat sich für den Dienst-internen Weg entschieden —
  `forTenant(this.prisma, tenantId)` wird in jeder umgestellten Methode neu
  erzeugt, wie es die vier Bestandsstellen in `ldap.service.ts` und die drei
  in `auth.service.ts` bereits vormachten. Der Bereich `groups` (260909-jts)
  hat sich für denselben dienst-internen Weg entschieden — jede Methode in
  `groups.service.ts` und `module-grants.service.ts` erzeugt ihren eigenen
  `forTenant()`- bzw. `withTenantTransaction()`-Aufruf, gebundene Clients
  werden nicht zwischen Methoden weitergereicht. Der Bereich `dashboard`
  (260910-krx) hat sich für denselben dienst-internen Weg entschieden — jede
  der neun umgestellten Methoden in `dashboard.service.ts` erzeugt ihren
  eigenen `forTenant()`-Aufruf, wie alle sieben Bereiche vor ihm. Der Bereich
  `calendar` (260911-cwh) hat sich für denselben dienst-internen Weg
  entschieden — jede der sechs umgestellten Methoden in `calendar.service.ts`
  erzeugt ihren eigenen `forTenant()`-Aufruf, wie alle acht Bereiche vor ihm.
  Die Frage bleibt für alle übrigen Bereiche der Etappe 2 offen.~~
  **Aufgelöst (260911-e2s):** die Frage ist für ALLE Bereiche entschieden,
  nicht nur für `tenant` — dienst-intern, ein Klient je Methode, ist die
  Konvention. Die Anfrageobjekt-Eigenschaft existiert nicht mehr:
  `tenant.guard.ts` setzt nur noch `req.tenantId`, `tenant.middleware.ts`
  (der nie verdrahtete Zwilling mit identischer Logik) ist gelöscht. Siehe
  Abschnitt "Zwei belegte Befunde" oben und
  `docs/mandantentrennung-etappe2-fehlerrichtung.md`, "## Bereich tenant",
  (n4)(a).
- ~~Wie die WINDOWS-#19-Policy für `SearchProvider`/`TenderRssFeedSource`
  am Ende genau lautet — nur, dass sie vor dem Scharfschalten gelöst sein
  muss.~~ Aufgelöst (260910-jab): `TenderRssFeedSource` bekommt vier nach
  Befehl getrennte Regeln, `SearchProvider` bleibt unverändert streng
  (widerlegte Prämisse). Siehe Abschnitt "Zwei belegte Befunde" oben. Was
  weiterhin offen ist: der Verwaltungsweg für plattformweite Zeilen unter
  der Anwendungsrolle (WINDOWS #24).
- Die Reihenfolge und Zuschnitt der Etappe-2-Pläne — dafür ist die
  Klassen-Verteilung oben der Arbeitsvorrat, siehe `<next_stages>` im
  Plan `260909-eor-PLAN.md`.
- **Wie der Anmeldeweg unter je Mandant eindeutigen Anmeldenamen (Etappe-3-
  Entscheidung (1)) den Mandanten VOR der Benutzersuche erfaehrt (260911-fh9).**
  `auth_lookup_user_by_username(p_username)` stuetzt sich heute auf
  `username @unique` plattformweit und braucht kuenftig
  `(p_tenant_id, p_username)` — die drei SECURITY-DEFINER-Funktionen aus
  Etappe 1 werden dabei ENGER (zwei Gleichheitsbedingungen statt einer),
  nicht weiter; `local.strategy.ts` braucht dann eine Mandantenangabe VOR
  der Suche. Die Bindung der drei Nach-Anmeldungs-Methoden dieses Bereichs
  (`getMe`, `changePassword`, `adminResetPassword`) ist davon NEUTRAL — sie
  haengt am Claim `tenantId` und an `User.id` (plattformweite UUID), nicht
  an `username`/`email`. Siehe
  `docs/mandantentrennung-etappe2-fehlerrichtung.md`, "## Bereich auth",
  (h4)(a).
- **Wie die Benutzerdimension in die Regeln der zehn persönlichen Tabellen
  kommt (Etappe-3-Entscheidung (2)).** **Aufgelöst (260911-nke):** Migration
  `20260911120000_rls_user_dimension_personal_tables` (Etappe 3b) bringt
  `app.current_user`/`current_user_id()` und die `IS NULL OR`-Form in die
  Regeln aller zehn persönlichen Tabellen; `forTenant(prisma, tenantId,
  userId?)` bekommt den optionalen dritten Parameter, 34 Nutzer-CRUD-
  Aufrufstellen reichen ihn durch. Siehe
  `docs/mandantentrennung-etappe2-fehlerrichtung.md`, Abschnitt
  "Regelschluss Benutzerdimension (Etappe 3b, 260911-nke)". Was weiterhin
  offen ist: ein Aufrufer, der `userId` vergisst, sieht den ganzen
  Mandanten (kein Wächter gebaut, siehe `.planning/WINDOWS.md`);
  Anmeldenamen pro Mandant (Etappe 3a) bleibt offen. **Systemkontext
  (Etappe 3c) — erledigt (260914-eym):** Migration
  `20260914120000_rls_system_context_read` (`is_system_context()`,
  `system_read_policy … FOR SELECT` auf fünf Tabellen; seit 260923-dhh
  kommt "ProxmoxServer" als sechste dazu, Migration 20260923140000.
  "DashboardImage" trug die Regel nur vorübergehend — angelegt in
  20260922120000 für den Bootstrap-Umzug der Bilderrahmen-Bilder, mit
  Stufe 2 der Umstellung wieder entfernt, Migration
  20260924120000_dashboard_image_drop_data, quick-260924-m4n; gemessen
  24.09.2026 lokal: sechs Tabellen mit der Regel),
  Schwesterhelfer
  `forSystem()`, fünfte Erkennungsform des Detektors mit Erlaubnisliste;
  siehe `docs/mandantentrennung-etappe2-fehlerrichtung.md`, Abschnitt
  "## Systemkontext (Etappe 3c, 260914-eym)" und den Regelschluss je Fall
  im Hintergrunddienst-Abschnitt oben.
- **Wie das Mailmodul künftig je Mandant versendet (260911-gwh).** ~~Der
  Startpfad bleibt bewusst ungebunden (sechster Fall der
  Hintergrunddienst-Falle, WINDOWS #30, siehe oben) — ein Umbau auf
  Transport je Versand aus `getDecryptedSmtpConfig(tenantId)`, die Form,
  die `DkvMailService`/`TenderMailService` bereits haben, ist eine
  Funktionsänderung (Umbau des Mailmoduls), kein Bindungsumbau, und deshalb
  NICHT Gegenstand dieser Etappe.~~ **Aufgelöst (260914-eym):** genau dieser
  Umbau ist gebaut — Startpfad und Mailer-Fabrik entfernt, `MailService`
  baut je Versand einen Transport nach Mandant des Empfängers, WINDOWS #30
  geschlossen. Siehe
  `docs/mandantentrennung-etappe2-fehlerrichtung.md`, "## Bereich settings",
  (s4)(a) mit Nachtrag.