tessera-ctl/docs/mandantentrennung-etappe2-fehlerrichtung.md

# Mandantentrennung, Etappe 2 — Die Fehlerrichtung dreht sich um

Dieses Dokument gehört zusammen mit
`docs/mandantentrennung-zugriffsklassifikation.md` zur Vorbereitung der
Mandantentrennung auf Datenbankebene. Während die Klassifikation festhält,
**welche** Fundstelle umgestellt wird, hält dieses Dokument fest, **woran**
man merkt, wenn eine umgestellte Fundstelle nach dem Scharfschalten
(Etappe 4) zu wenig liefert. Es ist etappenbezogen und wird nicht laufend
nachgezogen wie die Bestandsaufnahme — es beschreibt den Bereich `ldap` zum
Zeitpunkt seiner Umstellung (Etappe 2, Quick-Task 260909-ipc).

## (a) Die Leitfrage

Bis heute war der Fehlerfall einer Mandantentrennung "sieht zu viel": die
Rolle `tessera` läuft mit `BYPASSRLS`, jede Abfrage sieht alle Zeilen aller
Mandanten, unabhängig davon, ob sie an `forTenant()` gebunden ist oder nicht.
Ein vergessener `forTenant()`-Aufruf blieb bisher unsichtbar, weil die Policy
gar nicht griff.

Nach dem Scharfschalten (Etappe 4, wenn `DATABASE_URL` auf eine Rolle ohne
`BYPASSRLS` zeigt) kehrt sich das um. Jede Abfrage, die **nicht** gebunden
ist, sieht nicht mehr alle Zeilen, sondern **keine** — die Policy vergleicht
gegen `current_tenant_id()`, und ohne vorheriges `set_config` ist dieser Wert
`NULL`. `NULL = "tenantId"` ist in SQL nie wahr, auch wenn `"tenantId"`
selbst nicht `NULL` ist. Der Fehlerfall ist damit nicht mehr "ein
Administrator sieht die Konfiguration eines fremden Mandanten", sondern "der
Abgleich-Dienst sieht gar keine Konfiguration mehr, für niemanden, und tut
so, als sei nichts zu tun."

Diese Frage wird deshalb VOR der Umstellung gestellt, nicht erst beim
Scharfschalten entdeckt: **Woran würde ich merken, dass eine umgestellte
Abfrage jetzt zu WENIG liefert statt zu viel?**

## (b) Die Messung

Task 1 dieses Plans hat `apps/api/scripts/rls-scratch-check.mjs` um einen
dritten Abschnitt erweitert, der exakt das im Bereich `ldap` verwendete
Muster (Tabellen `LdapConfig`/`LdapFieldMapping`, Policies wortgleich aus der
ausgelieferten Migration `20260618112133_rls_policies/migration.sql`
herausgeschnitten) gegen eine Wegwerf-Datenbank unter einer Rolle **ohne**
`BYPASSRLS` prüft. Tatsächlich beobachtete Ausgabe dieses Laufs
(2026-09-09, gegen `tessera-ctl-db-1`, Adresse `172.19.0.2`):

```
ldapconfig-gebunden-nur-eigene-zeile: bestanden — forTenant(TENANT-A) liefert 1 Zeile(n): ["TENANT-A"]
ldapconfig-ungebunden-null-zeilen: bestanden — ungebundener SELECT auf "LdapConfig" liefert 0 Zeile(n)
fieldmapping-folgt-join-auf-ldapconfig: bestanden — forTenant(TENANT-A) liefert 1 Feldzuordnung(en): ["cfg-a"]
fieldmapping-schreiben-eigene-konfiguration-erlaubt: bestanden — INSERT mit eigener ldapConfigId erfolgreich
fieldmapping-schreiben-fremde-konfiguration-abgelehnt: bestanden — INSERT mit fremder ldapConfigId abgewiesen: ERROR: new row violates row-level security policy for table "LdapFieldMapping"
Alle 13 Pruefungen bestanden.
```

Der Beleg, der diese Kritikschrift trägt, ist die Zeile
`ldapconfig-ungebunden-null-zeilen`: der IDENTISCHE `SELECT "tenantId" FROM
"LdapConfig"` ohne vorheriges `set_config` liefert **0 Zeilen**, nicht etwa
alle 2 vorhandenen. Das ist an der echten, ausgelieferten Policy gemessen,
nicht an einer im Werkzeug nachgebauten Hilfstabelle — die Fehlerrichtung
"sieht nichts" ist damit kein aus dem Code abgeleiteter Schluss, sondern eine
beobachtete Tatsache.

## (c) Signaltabelle je umgestelltem Pfad des Bereichs `ldap`

| Pfad | Verhalten bei zu wenig Ergebnis | Konkretes Signal |
|---|---|---|
| `LdapConfigService.getConfig/createConfig/updateConfig` | `forTenant()` liefert für den anfragenden Mandanten 0 Zeilen statt der eigenen Konfiguration | `GET /ldap/config` liefert `null`; die Admin-Oberfläche zeigt "keine Konfiguration" für einen Mandanten, der tatsächlich eine hat |
| `LdapConfigService.addFieldMapping/removeFieldMapping` | Schreiben/Lesen einer Feldzuordnung läuft gebunden leer statt auf die eigene Zuordnung | `POST`/`DELETE /ldap/config/mappings` scheitert mit 404 bzw. legt scheinbar nichts an, obwohl die Konfiguration existiert |
| `LdapService.listGroups`/`searchUsers` (Markierung "bereits importiert") | Die Markierungsabfrage liefert 0 vorhandene Konten/Gruppen statt der tatsächlich vorhandenen | Die Kennzeichnung "bereits importiert" in den Auswahllisten von Gruppen und Benutzern fehlt für Einträge, die tatsächlich schon importiert sind — ein zweiter Import würde eine Dublette anlegen (bzw. bei Gruppen an der eigenen `ldapObjectGuid`-Eindeutigkeit scheitern) |
| `LdapService.upsertMappedUser`/`importUsersByDn` (Identitätssuche über `ldapDn`/`username`) | Die Suche nach dem bestehenden Konto liefert 0 Treffer statt des vorhandenen Kontos | Der Abgleich-Bericht zählt das Konto unter `created` statt `updated` — sichtbar in den Zählern created/updated/deactivated des Sync-Berichts |
| `LdapService.syncUsersForTenant` (Deaktivierungs-Kandidatenliste) | Die Kandidatenliste liefert 0 lokale LDAP-Konten statt der tatsächlich vorhandenen | Der Zähler `deactivated` bleibt 0, obwohl ein Konto im Verzeichnis entfernt wurde — harmlose Richtung: es wird zu WENIG deaktiviert, nie zu viel |
| `LdapService.syncUsersForTenant` (`lastSyncAt`-Fortschreibung) | Das `UPDATE` trifft 0 Zeilen statt der eigenen Konfiguration | Das Feld `lastSyncAt` der Konfiguration bleibt stehen, obwohl der Sync gerade lief — sichtbar in der Admin-Oberfläche als "nie synchronisiert" trotz laufendem Betrieb |
| `LdapService.importGroupsByDn` (Idempotenzprüfung über `ldapObjectGuid`) | Die Prüfung liefert 0 Treffer statt der bereits importierten Gruppe | Ein zweiter Import derselben AD-Gruppe würde eine Dublette anlegen, statt sie als "übersprungen" zu zählen — im gebundenen Zustand nicht mehr erreichbar, weil `group.create` an der eigenen `ldapObjectGuid`-Unique-Bedingung ohnehin scheitert |
| `LdapConfigScheduler` (Planer, `getAllActiveConfigs()`) | Der Planer liest 0 Konfigurationen statt aller aktiven Konfigurationen ALLER Mandanten | Die Protokollzeile "Starting LDAP sync for tenant ..." des Planers erscheint für KEINEN Mandanten mehr — siehe Abschnitt (d), Befund E |

## (d) Welcher Code deutet Leere als Abwesenheit

Diese vier Stellen sind die still gefährlichsten Orte des Bereichs `ldap`,
weil sie ein zu kleines Datenbankergebnis nicht als Fehler, sondern als
gültigen Zustand ("nichts zu tun", "Objekt existiert nicht mehr")
interpretieren:

1. **`syncGroupMembershipsForTenant`, `deleteMany` mit `notIn`** — gefährlich,
   zerstörend. Liefert die Benutzerausfrage zu wenig (weil ungebunden nach
   dem Scharfschalten 0 Zeilen zurückkommen), entfernt der anschließende
   `deleteMany({ where: { NOT: { userId: { in: [...] } } } })`-Aufruf ALLE
   LDAP-Mitgliedschaften der Gruppe, weil die Vergleichsliste leer ist und
   jede vorhandene Mitgliedschaft als "nicht mehr in der Liste" gilt. Dieser
   Pfad ist bereits gebunden (`tenantPrisma` seit Etappe 1, Zeile 1179 vor
   dieser Umstellung); die Gefahr besteht nur, falls diese Bindung jemals
   entfernt würde.

2. **Die Deaktivierungsschleife in `syncUsersForTenant`** — harmlose
   Richtung, trotzdem festgehalten. Liefert die Kandidatenliste
   (`localLdapUsers`) zu wenig, wird zu WENIG deaktiviert, nie zu viel: ein
   Konto, das eigentlich deaktiviert werden müsste, bleibt aktiv. Das ist
   unerwünscht, aber nicht destruktiv — es verliert keine Daten und sperrt
   niemanden fälschlich aus.

3. **Der Löschzweig in `syncBoundGroupsForTenant`** — die eigentliche
   Löschentscheidung fällt am VERZEICHNIS ("kein Treffer mehr für
   `objectGUID`"), nicht an der Datenbank; ein zu kleines Datenbankergebnis
   führt hier zu WENIGER Löschungen, nicht zu mehr. Gefährlich ist
   stattdessen die Übergabe unmittelbar davor:
   `this.groupsService.reassignDefaultBeforeDelete(tenantId, group.id)` und
   `ensureDefaultGroup(tenantId)` liegen in `groups.service.ts` und sind
   NICHT Teil dieser Umstellung. Nach dem Scharfschalten liefert
   `reassignDefaultBeforeDelete` still `false` (kein Ersatzkandidat
   sichtbar), der Standard-Marker wandert nicht mit, und die Gruppe wird
   trotzdem gelöscht — der Mandant bleibt ohne Standardgruppe zurück
   (Befund D, siehe (e)).

4. **`getAllActiveConfigs`** — die stillste Stelle im gesamten Bereich.
   Liefert diese Abfrage nach dem Scharfschalten 0 Zeilen (sie ist bewusst
   übergreifend und bleibt ungebunden, siehe (e)), stellt der LDAP-Abgleich
   für JEDEN Mandanten ohne Fehlermeldung, ohne Protokolleintrag und ohne
   sichtbare Änderung die Arbeit ein (Befund E). Eine Laufzeitwarnung bei
   "0 aktive Konfigurationen" wurde erwogen und VERWORFEN: der Planer läuft
   jede Minute, und auf einer frischen Installation ohne LDAP ist 0 der
   Normalfall — eine Warnung wäre Dauerlärm, der nach kurzer Zeit ignoriert
   wird und sein Signal verliert. Das Signal gehört deshalb hierhin und in
   die Vorabprüfung von Etappe 4 (`rls-preflight.mjs`), nicht in den
   Minutentakt des Planers.

## (e) Was dieser Durchlauf bewusst nicht löst

- **Befund A — `resolveEmailForWrite` muss übergreifend bleiben.** `email`
  und `username` sind in `prisma/schema.prisma` plattformweit eindeutig
  (`@unique`), nicht je Mandant. Würde diese Abfrage mitgebunden, sähe sie
  einen fremden Halter der Adresse nicht mehr, meldete "Adresse frei", und
  der anschließende Schreibvorgang liefe in die plattformweite
  Eindeutigkeitsbedingung der Datenbank — aus einer sauber berichteten
  Kollision (WINDOWS #15/T-Q3-01) würde ein P2002-Abbruch des gesamten
  Sync-Laufs. Nach dem Scharfschalten liefert diese ungebundene Abfrage
  IMMER "frei" (0 Zeilen unter jedem Mandantenkontext außer dem der
  Adresse selbst) — ein bekannter, hier bewusst offen gelassener Punkt.
  Die Lösung gehört nach Etappe 3, vermutlich als vierte
  SECURITY-DEFINER-Funktion nach dem Muster der drei Funktionen des
  Anmeldewegs (`auth_lookup_user_by_username`,
  `auth_lookup_reset_token`, plus die dritte aus Etappe 1).

- **Befund D — die Standardgruppen-Übergabe an den Bereich `groups`.** Wie
  in (d.3) beschrieben, ist der Löschzweig selbst bereits gebunden, aber
  die Übergabe an `reassignDefaultBeforeDelete`/`ensureDefaultGroup` in
  `groups.service.ts` ist es nicht. Das ist eine Reihenfolgebedingung für
  Etappe 4: der Bereich `groups` muss umgestellt sein, bevor scharf
  geschaltet wird, sonst bleibt ein Mandant nach einer Gruppen-Löschung
  ohne Standardgruppe zurück. `groups` ist ohnehin als nächster Bereich der
  Etappe 2 vorgesehen.

  **Nachtrag (260909-jts, Aufgabe 3): GESCHLOSSEN.** Der Bereich `groups`
  ist umgestellt — `reassignDefaultBeforeDelete` und `ensureDefaultGroup`
  laufen seit Aufgabe 2 dieses Plans vollständig über `forTenant()` bzw.
  `withTenantTransaction()` (siehe Abschnitt "Bereich groups" unten und
  `docs/mandantentrennung-zugriffsklassifikation.md`, Zeile
  `groups.service.ts`/`group`, Stand `gebunden`). Die Reihenfolgebedingung
  für Etappe 4 ist damit erfüllt. Der Befund oben bleibt unverändert stehen
  — er beschreibt korrekt den Zustand zum Zeitpunkt der ldap-Umstellung.

- **Die offene Architekturfrage `req.tenantPrisma`.** `tenant.middleware.ts`
  und `tenant.guard.ts` setzen `req.tenantPrisma = forTenant(...)`, aber
  kein Controller liest diesen Wert je. Dieser Durchlauf entscheidet NICHT,
  ob Controller künftig darüber gehen sollten statt eines erneuten
  `forTenant()`-Aufrufs im Service — der Bereich `ldap` bindet weiterhin
  dienst-intern, wie die vier Bestandsstellen in `ldap.service.ts` und die
  drei in `auth.service.ts` es vormachen. Die Frage bleibt für die übrigen
  Bereiche der Etappe 2 offen (siehe
  `docs/mandantentrennung-zugriffsklassifikation.md`, Abschnitt "Was diese
  Etappe NICHT entscheidet").

## Bereich groups

Dieser Abschnitt erweitert die Kritikschrift um den Bereich `groups`
(Quick-Task 260909-jts) und beschreibt ihn zum Zeitpunkt seiner Umstellung.
Die Leitfrage aus Abschnitt (a) gilt unverändert weiter — dieser Abschnitt
beantwortet sie erneut, aber für einen Bereich, der die Berechtigungsschicht
selbst ist: Gruppenmitgliedschaft und Modulfreigaben entscheiden, wer welches
Modul sehen darf.

### (g1) Die Messung

Aufgabe 1 hat `apps/api/scripts/rls-scratch-check.mjs` um einen vierten
Abschnitt (`runGroupsAreaChecks`) und eine eigene Transaktionsmessung
(`runTransactionShapeMeasurement`) erweitert, beide gegen die Wegwerf-Datenbank
unter der Rolle ohne `BYPASSRLS`, mit den vier Policies für `Group`,
`GroupMembership`, `ModuleGrant` (aus `20260804130918_groups_rls_policies`)
und `TenantModuleActivation` (aus `20260909140000_rls_remaining_tenant_tables`)
WORTGLEICH aus den ausgelieferten Migrationen extrahiert. Tatsächlich
beobachtete Ausgabe dieses Laufs (2026-09-09, gegen `tessera-ctl-db-1`,
Adresse `172.19.0.2`):

```
group-gebunden-nur-eigene-zeile: bestanden — forTenant(TENANT-A) liefert 1 Zeile(n): ["TENANT-A"]
group-ungebunden-null-zeilen: bestanden — ungebundener SELECT auf "Group" liefert 0 Zeile(n)
groupmembership-folgt-join-auf-group: bestanden — forTenant(TENANT-A) liefert 1 Mitgliedschaft(en): ["group-a"]
groupmembership-schreiben-fremde-gruppe-abgelehnt: bestanden — INSERT mit fremder groupId abgewiesen: ERROR: new row violates row-level security policy for table "GroupMembership"
groupmembership-schreiben-fremder-benutzer-nicht-verhindert: bestanden — INSERT mit A-eigener Gruppe, aber einer Benutzerkennung, die es in A nicht gibt, ist GELUNGEN — die Policy auf GroupMembership prueft nur die Gruppenseite, nicht die Benutzerseite (Befund E)
modulegrant-gebunden-nur-eigene-zeile: bestanden — forTenant(TENANT-A) liefert 1 Zeile(n): ["TENANT-A"]
modulegrant-fremde-gruppe-trotz-eigener-mandantenkennung-erlaubt: bestanden — INSERT mit korrekter eigener tenantId, aber fremder groupId ist GELUNGEN — die Policy auf ModuleGrant prueft nur die Mandantenkennung der Zeile, nicht die referenzierte Gruppe (Befund F)
tenantmoduleactivation-gebunden-nur-eigene-zeile: bestanden — forTenant(TENANT-A) liefert 1 Zeile(n): ["TENANT-A"]
```

Die Belegzeile, die diesen Abschnitt trägt, ist `group-ungebunden-null-zeilen`:
der IDENTISCHE `SELECT "tenantId" FROM "Group"` ohne vorheriges `set_config`
liefert **0 Zeilen**, nicht etwa die 2 tatsächlich vorhandenen — an der
echten, ausgelieferten Policy gemessen, nicht an einer im Werkzeug
nachgebauten Hilfstabelle.

**Die Transaktionsmessung — namentliches Ergebnis.** Drei Formen wurden
gegen einen Client beobachtet, der die Erweiterungsform aus
`prisma-tenant.extension.ts` wortgleich nachbaut, jeweils mit
`pg_backend_pid()` und `current_tenant_id()` in jeder Teilabfrage plus einem
echten Lesezugriff auf `"Group"`:

```
[beobachtet] Form (i) — Array-Form auf gebundenem Client: {"step1":{"pid":276749,"t":"TENANT-A"},"step2":{"pid":276750,"t":"TENANT-A","rows":1}}
[beobachtet] Form (ii) — interaktive Callback-Form auf gebundenem Client: {"step1":{"pid":276752,"t":"TENANT-A"},"step2":{"pid":276752,"t":"TENANT-A","rows":1}}
[beobachtet] Form (iii) — interaktive Callback-Form auf ungebundenem Client (set_config auf tx): {"step1":{"pid":276753,"applied":"TENANT-A","t":"TENANT-A"},"step2":{"pid":276753,"t":"TENANT-A","rows":1}}
mindestens-eine-transaktionsform-traegt-den-mandantenkontext: bestanden — bestanden: [Form (ii) ; Form (iii)] — nicht bestanden: [Form (i)]
```

Form (i) (Array-Form auf dem gebundenen Client) versagt eindeutig: `step1`
lief auf Verbindung 276749, `step2` auf Verbindung 276750 — zwei
verschiedene physische Verbindungen, obwohl beide Schritte denselben
Mandantenkontext lasen. Das bestätigt wortgetreu den Vorbehalt aus dem
Kopfkommentar von `prisma-tenant.extension.ts`: jede Modell-Operation eines
`$transaction`-Arrays auf dem gebundenen Client dispatcht durch
`$allOperations` und bekommt dadurch ihre EIGENE Ein-Element-Transaktion —
mehrere solche Operationen laufen auf mehreren Teiltransaktionen statt
einer gemeinsamen. In diesem konkreten Fall lieferte jede Teiltransaktion
zwar noch den korrekten Mandantenkontext (kein Datenleck), aber die
Atomarität der äußeren Transaktion ist nicht mehr gegeben — bei einem
Absturz zwischen den beiden Teiltransaktionen bliebe der Zustand
inkonsistent.

Form (ii) und Form (iii) bestanden beide die im Plan festgelegte
Einzelmessung (gleiche Verbindungskennung, korrekter Kontext, korrekte
Zeilenzahl). Über diese Einzelmessung hinaus wurde als zusätzliche,
sicherheitsrelevante Sorgfaltsprüfung (nicht durch den Plan verlangt, aber
durch die Tragweite dieses Bereichs geboten) beide Formen unter echter
Nebenläufigkeit erneut gemessen — 40 parallele Aufrufe über EINEN
gemeinsamen Client, alternierend TENANT-A/TENANT-B.

Diese Belastungsprobe lief zunächst gegen eine separate Experiment-Datenbank
und war damit **nicht nachvollziehbar** — eine Zahl, die eine Entscheidung
trug, ohne dass jemand sie hätte nachprüfen können. Genau das Anti-Muster,
das dieses Projekt sich selbst verboten hat. Sie ist deshalb als
`runConcurrencyProbe` in `apps/api/scripts/rls-scratch-check.mjs`
nachgereicht worden und läuft seither bei jedem Werkzeuglauf mit. Als
Verletzung zählt beides: ein Aufruf, der einen fremden oder gar keinen
Mandantenkontext sieht, und ein Aufruf, der abbricht.

Gemessen wird, nicht behauptet:

- **Form (ii)** bricht unter dieser Last ab, mit Fehlern der Familie
  `PrismaClientKnownRequestError: Transaction API error` (Code `P2028`).
  Ursache: jede
  `tx.$queryRaw`-Anweisung innerhalb der interaktiven Transaktion auf dem
  gebundenen Client löst selbst wieder eine VERSCHACHTELTE
  Array-Transaktion auf dem äußeren, ungebundenen Client aus (weil
  `$allOperations` bei jedem Aufruf erneut feuert) — die äußere
  interaktive Transaktion UND jede innere Verschachtelung belegen
  gleichzeitig eine Verbindung aus demselben, endlichen Pool. Unter Last
  reicht der Pool nicht mehr aus.
- **Form (iii)** besteht dieselbe Belastung ohne Verletzung — sie belegt
  pro Aufruf genau eine Verbindung, ohne Verschachtelung.

Die konkreten Zahlen eines einzelnen Laufs stehen bewusst NICHT in diesem
Dokument, sondern fallen bei jeder Ausführung neu an; der Werkzeuglauf vom
2026-09-09 ergab 24 Verletzungen von 40 für Form (ii) und 0 von 40 für
Form (iii). **Geprüft** wird nur die Eigenschaft, auf die sich der Code
stützt — Form (iii) ohne Verletzung. Das Verhalten von Form (ii) läuft
daneben als ausgedruckte Beobachtung mit und ist bewusst KEINE Bedingung
für einen grünen Lauf: ab welcher Last sie bricht, hängt an
Verbindungsvorrat und Maschine.

Das ist der entscheidende Befund für die Werkzeugentscheidung in Aufgabe 2:
obwohl Form (ii) die im Plan geforderte EINZELMESSUNG technisch besteht,
ist sie unter echter Nebenläufigkeit strukturell fragil und ein
Denial-of-Service-Risiko genau an der Stelle, die T-JTS-08 benennt (die
Startreparatur ruft `ensureDefaultGroup` für mehrere Mandanten auf). Form
(iii) ist die einzige der drei Formen, die sowohl die Einzelmessung als
auch die Belastungsprobe besteht — sie ist deshalb die Grundlage des neuen
Hilfsmittels `withTenantTransaction` in `prisma-tenant.extension.ts`.

### (g2) Signaltabelle je umzustellendem Pfad

| Pfad | Verhalten bei zu wenig Ergebnis | Konkretes Signal, Ort |
|---|---|---|
| `GroupsService.listForTenant` | Liefert 0 Gruppen statt der tatsächlich vorhandenen | Die Gruppenliste in der Verwaltung ist leer (Mitgliederzahl je Zeile fehlt ganz, weil die Zeile fehlt) |
| `GroupsService.getImpact` | Liefert `{memberCount:0, grantCount:0}` statt der tatsächlichen Zahlen | Der Löschdialog zeigt seine zwei Zahlen als 0/0 — der Administrator entscheidet über eine kaskadierende Löschung auf falscher Grundlage |
| `GroupsService.listMembers` | Liefert 0 Mitglieder statt der tatsächlich vorhandenen | Die Mitgliederliste im Gruppen-Detail ist leer |
| `ModuleGrantsService.getMatrix` | Liefert 0 Module und/oder 0 Gruppen statt der tatsächlich aktiven/vorhandenen | Die Freigabe-Matrix zeigt weder Modul- noch Gruppenachse vollständig — eine leere Zelle sieht identisch aus wie eine bewusst nicht erteilte Freigabe |
| `ModuleGrantsService.getUserAccess` | Liefert 0 Module bzw. 0 Gruppen statt der tatsächlichen | Das Benutzer-Detail zeigt für beide unabhängigen Antworten (Gruppenmitgliedschaften, Modulzugriff) fälschlich "keine" |
| `LdapService.syncBoundGroupsForTenant` (Übergabe an `reassignDefaultBeforeDelete`/`ensureDefaultGroup`) | Der Zähler `defaultMarkerMoved` im Abgleich-Bericht bleibt bei 0, obwohl tatsächlich verschoben wurde — oder eine Gruppe verliert ihre Standardmarkierung ersatzlos | Der Abgleich-Bericht des Verzeichnis-Syncs (D-05/D-06) |
| `GroupsService.addUserToDefaultGroup` | Findet die Standardgruppe nicht (0 Zeilen statt der einen vorhandenen) und tut nichts | Ein frisch angelegter Benutzer sieht nach seiner ersten Anmeldung KEIN Modul (leere Modulkacheln) |

### (g3) Welcher Code deutet Leere als Abwesenheit — Bereich groups

Ausgangspunkt ist Befund I aus der Planung, ergänzt um eine erneute Sichtung
beider Dateien:

- **`GroupsService.reassignDefaultBeforeDelete`** — zerstörend und still.
  Zwei getrennte Stellen liefern `false`: die Gruppe selbst ist nicht
  sichtbar (`findFirst` auf `Group` liefert 0 Zeilen), oder es ist kein
  Ersatzkandidat sichtbar (beide `findFirst`-Fallbacks liefern 0 Zeilen).
  Der Aufrufer im Verzeichnis-Sync (`syncBoundGroupsForTenant`) löscht die
  Gruppe danach in BEIDEN Fällen trotzdem, und die Löschung nimmt über die
  Kaskadenregeln aus 15-01 Mitgliedschaften und Modulfreigaben mit. Das ist
  Befund D aus der ldap-Kritik (Abschnitt (e) oben); ihn zu schließen ist
  ein Hauptzweck dieses Durchlaufs.
- **`GroupsService.ensureDefaultGroup`** — die einzige Stelle des Bereichs,
  an der zu wenig Lesen zu ZU VIEL Schreiben führt. Der Wächter ist
  UMGEKEHRT gepolt: null gelesene Gruppen (`group.count` liefert 0 statt
  der tatsächlichen Anzahl) heißt hier nicht "nichts zu tun", sondern
  "alles neu aufbauen". Bliebe der Zähler ungebunden, während der
  Schreibteil (die Transaktion) gebunden liefe, legte die Methode für einen
  Mandanten, der bereits Gruppen hat, eine ZWEITE Standardgruppe an, nähme
  ALLE seine Benutzer als Mitglieder auf und verteilte Freigaben für ALLE
  aktiven Module — eine stille Ausweitung von Berechtigungen, ausgelöst
  durch ein zu kleines Leseergebnis. Der partielle Eindeutigkeitsindex
  `Group_one_default_per_tenant` fängt einen Teil der Fälle ab (P2002 beim
  `group.create`, abgefangen und in `null` übersetzt) — aber nur, wenn der
  Mandant BEREITS eine markierte Standardgruppe hat. Einen Mandanten mit
  Gruppen, aber OHNE markierte Standardgruppe, fängt der Index nicht ab.
  Genau deshalb müssen Zähler und Transaktion GEMEINSAM gebunden werden,
  nie einzeln (T-JTS-05).
- **`GroupsService.getImpact`** — die Zahlen des Löschdialogs. Zwei
  Zählungen (`groupMembership.count`, `moduleGrant.count`) ohne
  Mandantenfilter, die bei Leere 0 und 0 melden. Der Administrator
  entscheidet auf dieser Grundlage über eine kaskadierende Löschung und
  bekommt "keine Mitglieder, keine Freigaben" für eine tatsächlich volle
  Gruppe angezeigt.
- **`GroupsService.addUserToDefaultGroup`** — stilles Zurückkehren ohne
  sichtbare Standardgruppe (`group.findFirst` liefert 0 Zeilen statt der
  einen vorhandenen). Jeder neu angelegte Benutzer landet dann in KEINER
  Gruppe und sieht nach seiner ersten Anmeldung kein einziges Modul. Nicht
  zerstörend, aber lautlos und in der Wirkung ein Berechtigungsverlust.

Gegenrichtung, ebenfalls festgehalten: `ModuleGrantsService.grant` (die
Aktivierungsprüfung: kein aktives `TenantModuleActivation` wirft
`BadRequestException`, statt still zu erteilen) und
`ModuleGrantsService.assertTargetBelongsToTenant` (die
Mandanten-Gegenprüfung: kein Treffer wirft `NotFoundException`) werfen bei
Leere LAUT und sind damit die harmlosen Stellen des Bereichs.

Entlastung, ausdrücklich am Frontend nachgesehen statt aus dem Backend
geschlossen: `apps/web/src/app/(portal)/admin/modules/grants/page.tsx`
schaltet die Freigabe-Matrix je Zelle einzeln (ein `POST` bzw. `DELETE` pro
Klick) — es gibt keinen Sammel-Speichern-Knopf, der einen Abgleich gegen den
gelesenen Zustand fährt. Ein zu kleines Leseergebnis führt dort also zu
einer leeren Anzeige, nicht zu einem Massen-Entzug. Das ist der Unterschied
zum `deleteMany`-mit-`notIn` des ldap-Bereichs.

### (g4) Was dieser Durchlauf bewusst nicht löst

- **Die offene Architekturfrage `req.tenantPrisma`.** Auch der Bereich
  `groups` entscheidet sie nicht — er bindet dienst-intern, wie `ldap` und
  `auth.service.ts` es vormachen.
- **Die Policies auf `GroupMembership` und `ModuleGrant` prüfen jeweils nur
  eine Seite.** Gemessen in (g1): `GroupMembership` prüft ausschließlich die
  Gruppenseite (Befund E, T-JTS-02) — eine Mitgliedschaft mit einer
  Benutzerkennung, die es im Mandanten der Gruppe nicht gibt, verletzt die
  Policy NICHT. `ModuleGrant` prüft ausschließlich die Mandantenkennung der
  Zeile selbst (Befund F, T-JTS-03) — eine Freigabe mit korrekter eigener
  Mandantenkennung, aber einer fremden Gruppenkennung, verletzt die Policy
  ebenfalls NICHT. Die Anwendungsprüfungen (die Benutzerfilterung in
  `addUserToDefaultGroup`, `assertTargetBelongsToTenant`) bleiben deshalb
  der primäre Schutz gegen diese beiden Formen der Rechteausweitung und
  werden durch diesen Durchlauf NICHT durch die Datenbank ersetzt.

### (g5) Fortschreibung des ldap-Abschnitts

Der in Abschnitt (e) oben als offen geführte Befund D — die Übergabe der
Standardgruppe vor einer Gruppenlöschung — wird durch diesen Durchlauf
geschlossen. Der Vermerk selbst steht am Ende von Abschnitt (e), gesetzt
in Aufgabe 3 dieses Plans, weil die Schließung erst zu diesem Zeitpunkt
tatsächlich vorliegt.

## Bereich tenders

Dieser Abschnitt erweitert die Kritikschrift um den Bereich `tenders`
(Quick-Task 260909-laa) und beschreibt ihn zum Zeitpunkt seiner Umstellung.
Die Leitfrage aus Abschnitt (a) gilt unverändert weiter — dieser Abschnitt
beantwortet sie erneut, aber für einen Bereich, der überwiegend NICHT
umgestellt wird: von 23 Paaren sind fünf umzustellen, zehn bleiben bewusst
der plattformweite Ausschreibungskatalog (D-03), zwei sind bewusste
Fan-outs, und sechs zerfallen in eine übergreifende Hälfte (Etappe 3) und
eine mandantengebundene Hälfte (hier). Dieser Bereich trägt außerdem eine
Fehlerform, die `ldap` und `groups` nicht hatten: zwei Benachrichtigungswege,
die bei zu kleinem Leseergebnis nicht falsch handeln, sondern GAR NICHT.

### (t1) Die Messung

Aufgabe 1 hat `apps/api/scripts/rls-scratch-check.mjs` um einen fünften
Abschnitt (`runTendersAreaChecks`) erweitert, mit den fünf Policies für
`TenderEmailConfig`, `TenderNotificationPref`, `TenderRssFeedSource`,
`TenderSavedSearch` und `TenderTriage` (alle aus der ausgelieferten
Migration `20260909140000_rls_remaining_tenant_tables`) WORTGLEICH
extrahiert, nicht im Werkzeug nachgetippt. Tatsächlich beobachtete Ausgabe
dieses Laufs (2026-09-09, gegen `tessera-ctl-db-1`, Adresse `172.19.0.2`):

```
tendersavedsearch-gebunden-nur-eigener-mandant: bestanden — forTenant(TENANT-A) liefert 2 Zeile(n): ["TENANT-A","TENANT-A"]
tendersavedsearch-ungebunden-null-zeilen: bestanden — ungebundener SELECT auf "TenderSavedSearch" liefert 0 Zeile(n)
tendersavedsearch-fremder-nutzer-desselben-mandanten-sichtbar: bestanden — forTenant(TENANT-A) liefert AUCH die Zeile des zweiten Nutzers (user-a2) — die Policy auf TenderSavedSearch prueft nur die Mandantenkennung, nicht die Benutzerkennung; die anwendungsseitige userId-Filterung bleibt der einzige Schutz gegen Quer-Lesen zwischen Nutzern desselben Mandanten und darf nicht entfallen
tenderemailconfig-gebunden-nur-eigener-mandant: bestanden — forTenant(TENANT-A) liefert 1 Zeile(n): ["TENANT-A"]
tendertriage-gebunden-nur-eigener-mandant: bestanden — forTenant(TENANT-A) liefert 1 Zeile(n): ["TENANT-A"]
tendernotificationpref-gebunden-nur-eigener-mandant: bestanden — forTenant(TENANT-A) liefert 1 Zeile(n): ["TENANT-A"]
tenderrssfeed-plattformzeile-unter-jedem-mandanten-unsichtbar: bestanden — forTenant(TENANT-A) sieht die Platform-Zeile: false, forTenant(TENANT-B) sieht sie: false — WINDOWS #19: eine plattformweite RSS-Quelle ist unter JEDEM Mandantenkontext unsichtbar; listForUser/createPlatform/remove duerfen deshalb nicht gebunden werden, solange die Policy-Semantik unveraendert ist
tenderrssfeed-gebundenes-einfuegen-ohne-mandant-abgelehnt: bestanden — gebundenes INSERT mit tenantId=NULL abgewiesen: ERROR: new row violates row-level security policy for table "TenderRssFeedSource" — createPlatform darf deshalb nicht gebunden werden
tendertriage-einfuegen-auf-unsichtbare-zeile-verletzt-eindeutigkeit: bestanden — gebundenes INSERT auf die unsichtbare (userId,tenderId)-Kombination scheitert an der Eindeutigkeitsbedingung, nicht an der Policy: Code 23505, Unique constraint failed — Befund F: aus einem stillen Ueberschreiben wird bei Aufgabe 2 ein harter, verstaendlich uebersetzter Fehler
Alle 32 Pruefungen bestanden.
```

Die Belegzeile, die diesen Abschnitt trägt, ist
`tendersavedsearch-ungebunden-null-zeilen`: der IDENTISCHE
`SELECT "tenantId" FROM "TenderSavedSearch"` ohne vorheriges `set_config`
liefert **0 Zeilen**, nicht etwa die 3 tatsächlich vorhandenen — an der
echten, ausgelieferten Policy gemessen, nicht an einer im Werkzeug
nachgebauten Hilfstabelle.

Zwei Messungen dieses Laufs tragen eine Entscheidung, die kein bisheriger
Bereich brauchte:

- `tendersavedsearch-fremder-nutzer-desselben-mandanten-sichtbar` — das
  GELINGEN (beide Nutzer von TENANT-A sind sichtbar) IST das bestandene
  Ergebnis. Alle fünf Policies dieses Bereichs lauten schlicht
  `"tenantId" = current_tenant_id()`, ohne Benutzerdimension — zwei Nutzer
  DESSELBEN Mandanten sind füreinander vollständig sichtbar. Die
  anwendungsseitige `userId`-Filterung, die alle fünf umzustellenden
  Dienste bereits führen, bleibt deshalb der einzige Schutz gegen
  Quer-Lesen zwischen Nutzern und wird bei der Umstellung NICHT entfernt.
- `tenderrssfeed-plattformzeile-unter-jedem-mandanten-unsichtbar` — die
  plattformweite RSS-Zeile (`userId`/`tenantId` beide `NULL`, wie der
  geseedete `service.bund.de`-Feed) ist unter TENANT-A UND TENANT-B
  gebunden unsichtbar, weil `NULL = current_tenant_id()` in SQL nie wahr
  ist. Das ist WINDOWS #19, hier nicht als ferne Sorge, sondern als der
  Grund, warum `listForUser`, `createPlatform` und `remove` in
  `tender-rss-feed.service.ts` NICHT gebunden werden — eine Bindung würde
  die plattformweite Quelle für JEDEN Mandanten verschwinden lassen.
  `tenderrssfeed-gebundenes-einfuegen-ohne-mandant-abgelehnt` bestätigt die
  Kehrseite: ein gebundenes `INSERT` mit `tenantId = NULL` wird von der
  ausgelieferten Policy abgewiesen — `createPlatform` würde in genau diese
  Abweisung laufen, würde man es binden.

Eine dritte Messung trägt die Fehlerbehandlung von Aufgabe 2:
`tendertriage-einfuegen-auf-unsichtbare-zeile-verletzt-eindeutigkeit` zeigt,
dass ein gebundenes `INSERT` auf ein `(userId, tenderId)`-Paar, dessen Zeile
existiert, aber einem anderen Mandanten gehört und deshalb unsichtbar ist,
an der Eindeutigkeitsbedingung scheitert (Postgres prüft Unique-Indizes
gegen die physischen Zeilen, unabhängig von der RLS-Sichtbarkeit) — NICHT
an einer Policy-Abweisung. Aus einem stillen Überschreiben wird dadurch ein
harter Fehler, der in Aufgabe 2 als verständliche deutsche Meldung
herauskommen muss, nicht als roher 500er.

TEIL 2 dieser Aufgabe hat zusätzlich nachgemessen, dass dieser Bereich
keine mandantengebundene Transaktion enthält (Befund A):
`grep -rn '\$transaction(' apps/api/src/tenders --include=*.ts | grep -v spec`
liefert genau EINEN Treffer, `tender-fingerprint-backfill.service.ts:89`,
die Array-Form auf der plattformweiten Tabelle `Tender` (D-03), außerhalb
jeder Mandantenbindung. Der im Kopf von `prisma-tenant.extension.ts`
verlangte erneute Test vor jedem neuen `forTenant()`-Fall mit eigener
Transaktion ist damit für diesen Bereich beantwortet: es fällt kein neuer
Fall an, `withTenantTransaction()` wird hier nicht gebraucht und auch
nicht eingeführt.

### (t2) Signaltabelle je umgestelltem Pfad

| Pfad | Verhalten bei zu wenig Ergebnis | Konkretes Signal |
|---|---|---|
| `TenderSavedSearchService.list` | Liefert 0 gespeicherte Suchprofile statt der tatsächlich vorhandenen | Die Suchprofil-Leiste im Ausschreibungs-Radar ist leer für einen Nutzer, der tatsächlich Profile gespeichert hat |
| `TenderSavedSearchService.create/update/remove` | Die Besitzprüfung (`findUnique` gebunden) liefert 0 Zeilen statt der eigenen Zeile | `PATCH`/`DELETE /saved-searches/:searchId` scheitert mit 404, obwohl das Profil existiert; `POST` legt scheinbar erfolgreich ein neues Profil an (unkritisch, betrifft nur den Lesepfad danach) |
| `TenderTriageService.listForUser` | Die Markierungsabfrage liefert 0 Treffer statt der tatsächlich vorhandenen | Die Trefferliste zeigt für bereits gelesene/favorisierte Ausschreibungen keine Markierung mehr — ein bereits gelesener Treffer erscheint wieder als ungelesen |
| `TenderTriageService.favoriteIds` | Liefert 0 favorisierte tenderIds statt der tatsächlich vorhandenen | Der Merklisten-Filter (`favOnly`) zeigt eine leere Liste für einen Nutzer, der tatsächlich Favoriten hat |
| `TenderNotificationPrefService.getForUser` | **Sonderfall**: kein Treffer bedeutet hier nicht "leer", sondern der Vorgabewert `daily` (D-01) | Ein Nutzer, der `off` gewählt hat, sieht in der Oberfläche wieder `daily` — ein zu kleines Leseergebnis setzt die Einstellung stillschweigend auf täglich zurück, statt sie leer zu lassen |
| `TenderEmailConfigService.getConfigForApi` | Der gebundene `findUnique` liefert 0 Zeilen statt der eigenen Konfiguration | `GET /email-config` liefert `null`; die Oberfläche zeigt "kein Postfach verbunden" für einen Nutzer, der tatsächlich eines hat |
| `TenderEmailConfigService.testConnection` | Der gebundene Rückgriff auf gespeicherte Zugangsdaten liefert 0 Zeilen statt der eigenen | Ein Verbindungstest mit leer gelassenem Formular (Rückgriff auf gespeicherte Zugangsdaten) schlägt fehl, obwohl gespeicherte Zugangsdaten existieren |
| `TenderRssFeedSourceService.listForUser`/`createPlatform`/`remove` (bewusst UNGEBUNDEN, WINDOWS #19) | Betrifft nicht diese drei Pfade selbst — sie binden nicht und liefern deshalb weiterhin die plattformweite Zeile korrekt. Das Risiko liegt in einer KÜNFTIGEN Bindung (Etappe 3), nicht in dieser Umstellung | Würde man sie binden: leere Feed-Liste bzw. 404 beim Entfernen einer plattformweiten Quelle — hier ausdrücklich als Grenze festgehalten, nicht als heute beobachtbares Verhalten |
| `TenderRssFeedSourceService.createForUser` (gebunden) | Der Zähler (`count`, gebunden) liefert 0 statt der tatsächlichen Anzahl eigener Feeds | Ein Nutzer, der bereits am Limit von 20 eigenen Feeds ist, könnte scheinbar unbegrenzt neue anlegen (harmlose Richtung: die Kappung aus T-17-10 wirkt nicht mehr, kein Datenverlust) |

### (t3) Welcher Code Leere als Abwesenheit deutet

**Sichtbare Formen** (Anzeige bleibt leer oder fällt auf einen Vorgabewert
zurück, jemand merkt es beim nächsten Blick auf die Oberfläche): siehe
Tabelle (t2) oben — Suchprofilliste, Triage-Markierung, Favoriten-Filter,
der `daily`-Sonderfall der Benachrichtigungseinstellung, und die
Postfach-Anzeige.

**Lautlose Formen — die zusätzliche Fehlerform dieses Bereichs.** Fünf
Stellen in den beiden Hintergrunddiensten deuten ein zu kleines
Leseergebnis nicht als Fehler, sondern als "nichts zu tun", und
protokollieren dabei NICHTS:

1. **`tender-digest.scheduler.ts`, `if (!candidates.length) return;`** —
   liefert die gebundene Kandidatenabfrage innerhalb eines Profildurchlaufs
   zu wenig, bricht der GESAMTE Digest für diesen Lauf ab, für ALLE
   Mandanten, ohne Protokolleintrag.
2. **`tender-digest.scheduler.ts`, `if (!matches.length) continue;`** —
   liefert die gebundene Treffer-Abfrage für einen Kandidaten zu wenig,
   bekommt dieser eine Nutzer keine Post, der Lauf macht mit dem nächsten
   Kandidaten weiter, ohne Protokolleintrag.
3. **`tender-digest.scheduler.ts`, `if (!user || !user.email) continue;`**
   — liefert die gebundene Benutzer-Abfrage zu wenig, bekommt dieser
   Nutzer keine Post, ohne Protokolleintrag.
4. **`tender-matching.service.ts`, `if (!fresh.length) continue;`** —
   liefert die gebundene Abfrage der noch nicht benachrichtigten Treffer
   innerhalb eines Profildurchlaufs zu wenig, bekommt dieser Nutzer keinen
   Sofort-Alarm, ohne Protokolleintrag.
5. **`tender-matching.service.ts`, `if (!user || !user.email) continue;`**
   — dieselbe Form wie Stelle 3, für den Sofort-Alarm-Pfad.

Keine dieser fünf Stellen protokolliert etwas — eine ausbleibende Warnung
erzeugt keine Fehlermeldung, keinen Protokolleintrag und keine Beschwerde,
außer der stillen Abwesenheit einer E-Mail, die niemand erwartet, weil
niemand wusste, dass sie hätte kommen sollen.

Entlastung in dieselbe Richtung, ebenfalls nachgesehen statt geschlossen
behauptet: weil `notifiedAt` auf `TenderMatch` nur nach ERFOLGREICHEM
Versand gestempelt wird (D-06), bleiben die betroffenen Zeilen auf
`notifiedAt IS NULL` stehen und werden beim nächsten Lauf erneut versucht.
Es geht also nichts verloren — es kommt nur nichts an, solange die Ursache
(z. B. ein nach dem Scharfschalten ungebunden gebliebener Lesepfad)
fortbesteht. Daraus ergibt sich das einzige nachprüfbare Signal dieser
Fehlerform: eine wachsende Zahl von `TenderMatch`-Zeilen mit
`notifiedAt IS NULL` bei gleichzeitig fehlendem Versandprotokoll. Dieses
Signal gehört in die Vorabprüfung von Etappe 4 (`rls-preflight.mjs`), NICHT
in diesen Durchlauf — Aufgabe 3 hält es hier fest, löst es aber nicht.

Eine Laufzeitwarnung an den fünf Stellen wurde erwogen und VERWORFEN, aus
demselben Grund wie bei `getAllActiveConfigs` im `ldap`-Durchlauf: beide
Hintergrunddienste laufen regelmäßig, und "kein passender Kandidat"/"kein
Konto mit Adresse" ist ein regulärer Zustand, kein Fehlerfall — eine
Warnung wäre Dauerlärm und verlöre ihr Signal.

### (t4) Was dieser Durchlauf bewusst nicht löst

- **WINDOWS #19 — nullbares `tenantId` bei `TenderRssFeedSource`.**
  Gemessen in (t1): eine plattformweite Zeile ist unter JEDEM
  Mandantenkontext unsichtbar, ein gebundenes Einfügen ohne Mandant wird
  abgewiesen. `listForUser`, `createPlatform` und `remove` bleiben deshalb
  bewusst UNGEBUNDEN, mit einem Codekommentar, der die Grenze benennt. Die
  Policy-Semantik selbst (eine `tenantId IS NULL OR tenantId =
  current_tenant_id()`-Lesevariante) gehört zu Etappe 3 und wird hier nicht
  angefasst.
- **Die übergreifenden Hälften der beiden Hintergrunddienste.** Aufgabe 3
  bindet nur die Je-Treffer-Hälften von `tender-digest.scheduler.ts` und
  `tender-matching.service.ts`; die Kandidatenabfrage
  (`tenderMatch.findMany`/`tenderSavedSearch.findMany`) bleibt bewusst
  über alle Mandanten hinweg ungebunden und ist als Etappe-3-Übergabe
  kommentiert — siehe `docs/mandantentrennung-zugriffsklassifikation.md`,
  Abschnitt "Der Hintergrunddienst als Falle".
- **Befund K — die Abhängigkeit vom noch nicht umgestellten Bereich
  `settings`.** `tender-mail.service.ts` holt die SMTP-Angaben über
  `SettingsService.getDecryptedSmtpConfig(tenantId)`; `settings.service.ts`
  ist noch vollständig unbound (4 Rohtreffer, siehe Übersichtstabelle in
  `docs/mandantentrennung-zugriffsklassifikation.md`). Nach dem
  Scharfschalten fände diese ungebundene Abfrage keine SMTP-Zeile mehr —
  Ergebnis: kein Versand für niemanden, mit Wiederholung bei jedem Lauf
  (dieselbe Entlastung wie in (t3)). Das ist eine Reihenfolgebedingung für
  Etappe 4, genau wie Befund D des `ldap`-Durchlaufs es für `groups` war —
  hier festgehalten, nicht gelöst.
- **Die offene Architekturfrage `req.tenantPrisma`.** Auch der Bereich
  `tenders` entscheidet sie nicht — er bindet dienst-intern, wie `ldap`
  und `groups` es vormachen.
- **Befund G — ein Administrator eines beliebigen Mandanten kann eine
  plattformweite RSS-Quelle entfernen.** `TenderRssFeedSourceService.remove`
  ist bereits heute ein einziger bedingter `deleteMany` mit der
  Besitzbedingung in der Datenbank — das ist das gewünschte Muster, keine
  Wiederholung des `ldap`-Fundes (Auflösung über die Kennung allein). Die
  eine Beobachtung, die trotzdem festgehalten gehört: ein Administrator
  EINES beliebigen Mandanten kann über diesen Pfad eine plattformweite
  Quelle entfernen, die ALLE Mandanten speist — eine Produkt-/
  Zuständigkeitsfrage im Umfeld von WINDOWS #19, kein Auftrag dieser
  Aufgabe.

### (t5) Was dieser Durchlauf bewusst nicht anfasst

Die zwölf Paare des plattformweiten Ausschreibungskatalogs (D-03,
`tender-dedup.service.ts`, `tender-fingerprint-backfill.service.ts`,
`tender-ingestion.service.ts`, `tender-matching.service.ts`/`tender`,
`tender-scheduler.service.ts`, `tenders.controller.ts`, `tenders.module.ts`)
und der beiden bewussten Fan-out-Adapter
(`adapters/email-alert.adapter.ts`, `adapters/rss.adapter.ts`) sind
geprüft und deliberat ungebunden — nicht übersehen. Jede der zwölf trägt
ihre Begründung im eigenen Dateikopf bzw. in D-03.

Befund I gehört ausdrücklich hierher: `tender-ingestion.service.spec.ts`
enthält eine Schutzprüfung, die den QUELLTEXT von
`tender-ingestion.service.ts` liest und gegen ein Vorkommen des
Bezeichners `forTenant` prüft ("never calls forTenant()"). In dieser einen
Datei darf deshalb auch kein ERKLÄRENDER Kommentar diesen Bezeichner
nennen — die Datei selbst steht ohnehin auf der Nicht-Anfassen-Liste, hier
nur festgehalten, damit niemand sie beim Nachziehen der Begründungen
"freundlich kommentiert" und den Lauf rot macht.

## Verweis

Die Bestandsaufnahme, welche Fundstelle den hier beschriebenen Übergang
bereits vollzogen hat (Stand-Spalte `gebunden`/`ungebunden`/`gemischt`),
steht in `docs/mandantentrennung-zugriffsklassifikation.md`.