docs(quick-260921-m34): 288 any auf 15 gesenkt, jede verbliebene mit Urteil

Zusammenfassung mit Urteilsregister und STATE.md zum Quick-Vorgang
260921-m34.

Der groesste Posten war ein einziges Missverstaendnis: 105 Stellen
trugen eine Zusicherung an der Mandantenbindung, die nie noetig war -
prisma.$extends() liefert laengst einen getypten Klienten.

Die tenantId-Frage wurde hergeleitet statt nach Bequemlichkeit
entschieden: string ohne Fragezeichen, belegt aus Pflichtspalte im
Schema, Bestandstyp und dem Super-Admin-Zweig der Mandantenpruefung -
der diesen Typ gar nicht liest und deshalb nicht zu totem Code werden
kann. Der Waechter blieb ueber den ganzen Lauf unveraendert.

Vier Befunde gemeldet statt still repariert. Zwei brauchen eine
Entscheidung, beide wuerden Verhalten aendern - darunter ein
sicherheitsrelevanter: die IMAP-Einstellung STARTTLS erzwingt nichts,
weil die gesetzte Option in imapflow 1.4.3 nicht existiert.

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

.planning/STATE.md

@@ -4,8 +4,8 @@ milestone: v1.2
 current_phase: 18
 current_phase_name: desktop-client-fertigstellen
 status: verified
-stopped_at: "Neun Quick-Vorgaenge am 2026-09-21 (9ie, a1d, bi2, fi3, gof, i8x, iwr, jt4, ldf). Der Wackeltest aus CI-Lauf 395 ist geklaert und war ein Produktfehler. Offen: 288 any in apps/api (reine Typarbeit), danach zwei neue Dashboard-Widgets. Das erste ist ein Bilderrahmen: Bilder werden hochgeladen ODER per https-Webadresse eingebunden (Browser laedt direkt, kein Server-Abruf, damit keine SSRF-Flaeche); Einstellungen fuer Bildausschnitt, Wechselintervall, Reihenfolge/Zufall, Bildunterschrift, Klick zeigt gross. Das zweite Widget hat der Nutzer noch nicht benannt. ldf ist noch nicht gepusht."
-last_updated: "2026-09-21T14:15:00.000Z"
+stopped_at: "Zehn Quick-Vorgaenge am 2026-09-21. Der gesamte Lint- und Fehlerrueckstand ist abgearbeitet (2923 → 125 Diagnosen, 0 Fehlerstufe). ZWEI BEFUNDE WARTEN AUF ENTSCHEIDUNG DES NUTZERS, beide aus m34 Aufgabe 3, beide wuerden Verhalten aendern: (B-06, Sicherheit) imap.provider.ts setzt requireTLS, das es in imapflow 1.4.3 nicht gibt — die Einstellung STARTTLS erzwingt nichts und faellt bei fehlender Server-Unterstuetzung unverschluesselt zurueck; richtig waere doSTARTTLS: true, Folge: solche Postfaecher scheitern dann statt im Klartext zu verbinden. (B-05) imap.provider.ts:78 liest .parameters von einer Zeichenkette, Outlook-Anhaenge werden ueber Content-Disposition nicht erkannt, betrifft den DKV-Rechnungseinzug. Danach: zwei neue Dashboard-Widgets, das erste ein Bilderrahmen (Upload ODER https-Webadresse, Browser laedt direkt), das zweite noch unbenannt. m34 ist noch nicht gepusht."
+last_updated: "2026-09-21T16:10:00.000Z"
 last_activity: 2026-09-21
 last_activity_desc: Quick 260921-9ie, a1d, bi2, fi3 und gof — Lint-Tor scharf, Benutzerverwaltung meldet abgewiesene Aktionen, Lint-Rueckstand 2923 → 446, erzwungener Passwortwechsel an der API durchgesetzt (war eine tote Sperre), 21 Effekt-Abhaengigkeiten einzeln beurteilt; alle fuenf verifiziert, die letzten drei am laufenden System
 state_head: 4d485432c003a6caf68f6d85aff7de0bd27794e2
@@ -31,7 +31,7 @@ See: .planning/PROJECT.md (updated 2026-07-17)
 Phase: 18 (desktop-client-fertigstellen) — COMPLETE (2026-09-17, Verifikation passed, Windows-Bedienprobe bestanden)
 Plan: 6 of 6
 Status: Alle 18 Phasen abgeschlossen; Version 1.2.0 freigegeben. Kein laufender Meilenstein. Nach 1.2.0 auf main (Beta): Bildmarke in Akzentfarbe, CI-Desktop-Skip, Favoriten-Symbol/-Sortierung, Desktop-Server-Adresse, Update in der App (signiert), Versionszeile auf der Setup-Seite — alles verifiziert und auf VM/CI nachgewiesen
-Last activity: 2026-09-21 - Quick 260921-ldf: der Wackeltest aus CI-Lauf 395 war ein echter Produktfehler — der Fehler-melden-Dialog stand bei jedem Oeffnen kurz mit ausgeschaltetem Haekchen da; Ursache behoben, nicht der Test beruhigt
+Last activity: 2026-09-21 - Quick 260921-m34: 288 any im Backend auf 15 gesenkt, jede verbliebene mit Urteil; dabei vier Befunde gemeldet statt still repariert, darunter ein sicherheitsrelevanter: die IMAP-Einstellung STARTTLS erzwingt nichts, weil die gesetzte Option in imapflow gar nicht existiert
 
 Progress: [██████████] 99%
 
@@ -453,6 +453,7 @@ Gerettet aus `.continue-here.md`. Relevant fuer die noch offenen Live-Tests.
 | 260921-iwr | **Listenschluessel und Ausrufezeichen-Zusicherungen: 30 Stellen geprueft, wieder kein echter Fehler.** Damit ist der fehlerverdaechtige Rueckstand abgearbeitet. **Zwei Vorannahmen des Orchestrators widerlegt, beide durch Messung statt Argument:** (1) Die LDAP-Seite galt als heisser Kandidat, weil dort Zuordnungsregeln hinzugefuegt und geloescht werden — die Liste, die tatsaechlich waechst und schrumpft (`config.fieldMappings`), benutzt jedoch laengst `key={mapping.id}`; die sechs Meldungen betreffen zustandslose Textlisten. (2) Im Cert-Manager galt eine Zusicherung auf hochgeladenen Dateiinhalt als moeglicher Absturz — der Planer hat eine 83-Byte-Schrottdatei gebaut, die node-forge `bag.cert = null` setzen laesst, und gegen den echten Dienst laufen lassen: **alle vier Pfade enden mit 400, nie 500**, und `certificateToPem(null)` wirft nachweislich, statt still ein falsches Zertifikat zu bauen. Also weder Verfuegbarkeits- noch Integritaetsluecke, sondern eine irrefuehrende Fehlermeldung. **Ein Fund dreht die Richtung um:** bei `admin/modules/grants/page.tsx:246` waere die Korrektur schaedlich — die Gruppierung fasst nur aufeinanderfolgende Kategorien zusammen, die Positionsnummer ist dort fuer die Eindeutigkeit noetig, ohne sie entstuenden doppelte Schluessel. **Geaendert: 5 Stellen** (drei Waechter im Cert-Manager, die den Meldungstext praezisieren — Status bleibt 400, rot-dann-gruen belegt; zwei ueberfluessige Zusicherungen in `imap.provider.ts`, die imapflow ohnehin als Pflichtfeld typisiert). **25 Stellen bleiben bewusst stehen und bleiben in der Zaehlung sichtbar** — mit Begruendung je Stelle in der Akte, damit der naechste Durchgang sie nicht erneut aufrollt; kein Unterdrueckungskommentar, um die Zahl zu schoenen. **Das Tor hat sich selbst bewaehrt:** der erste Entwurf eines Waechters erzeugte einen neuen Lint-Fund (430 statt 429) und wurde von der Verifikation des Plans gefangen; die Reparatur brach `tsc`, weil `@types/node-forge` `Bag.cert` als `Certificate | undefined` deklariert, waehrend die Bibliothek zur Laufzeit `null` zuweist — Endfassung prueft beides. **Zahlen:** 434 → 429, `noArrayIndexKey` unveraendert 19 (alle geprueft, alle harmlos), `noNonNullAssertion` 11 → 6, web-Tests 68/481 → 69/484, api 72/1137 → 72/1143, type-check 4/4, lint 5/5. | 2026-09-21 | 8716fa5,b4aaed4,27909e4,de69863 | [260921-iwr-listenschluessel-per-positionsnummer-und](./quick/260921-iwr-listenschluessel-per-positionsnummer-und/) |
 | 260921-jt4 | **Barrierefreiheit von 30 auf 1 Befund, plus die vier zurueckgestellten Restposten.** Die 30 a11y-Befunde galten seit bi2 als "braucht Bedienentscheidungen"; die hat der Orchestrator getroffen, und der Planer hat **zwei davon widerlegt**: (1) Der vorgesehene Rueckfallweg (`role` + `tabIndex` + Tastaturhandler, wo kein echter Knopf geht) tauscht gemessen drei Befunde gegen einen neuen `useSemanticElements` — eine Regel, die bi2 gerade erst auf 0 gebracht hatte; wird nirgends benutzt, fuer den Verschachtelungsfall (Marktplatz-Karte) tritt eine deckende Geschwister-Schaltflaeche an seine Stelle. (2) **Vier der elf "Klick"-Befunde sind gar keine Klicks**, sondern `onError`-Handler an `<img>` — da gibt es keinen Tastaturweg zu schaffen, sie bekommen `aria-hidden`. **Ein Fund darueber hinaus:** alle fuenf ARIA-Befunde sind `aria-label` auf rollenlosen Elementen — die werden von Vorleseprogrammen still verworfen, die Beschriftungen kamen also bei niemandem an; jetzt mit korrekter Rolle. Sechs Stellen wurden zu echten `<button>` (Aussehen unveraendert), vier `autoFocus` auf Seiten entfernt (auf Seiten reisst er beim Laden den Fokus an sich — im Dialog waere er richtig gewesen, alle vier waren Seiten). **Ein Befund bleibt bewusst stehen und bleibt gezaehlt** (`calculator-widget.tsx:323`), samt ausdruecklich verworfener Umgehung. **Restposten:** ZIP-Name uebersetzt mit getesteter Schutzfunktion `zip-filename.ts` (der frueher genannte Umlaut-Einwand trifft fuer "Zertifikate.zip" nicht zu, die Schutzfunktion sichert kuenftige Uebersetzungen ab); die ueberfluessige `case`-Marke im Normalisierer aufgeloest, Absicht in den Kommentar gewandert; Kalender-Verschwendung abgestellt. **Zur `t`-Frage eine Korrektur an gof:** `use-intl` 4.13 erzeugt `t` in einem `useMemo`, es ist also in der Bibliothek stabil — instabil ist es nur in den Test-Attrappen, und daher kam der Beleg von damals. Die acht Korrekturen aus gof bleiben richtig und schaedlich sind sie nicht, aber die Begruendung war zu breit; ein Test an der Wurzel misst es jetzt. **Laufzeitnachweis vom Orchestrator** (Browser, 90 Tage Vorschau — bei der Voreinstellung 30 tritt der Doppelabruf gar nicht auf, die Messung haette also nichts gezeigt): drei Monatswechsel holen `calendar/sources` nur noch **1x statt 4x**, und der Termin-Abruf mit identischem Zeitraum ist weg (3 Klicks → 2 Abrufe statt 3). Der 5-Minuten-Auffrischer bleibt unangetastet — belegt nicht durch Warten im Browser (zwei Messversuche waren ungueltig, weil das Werkzeug die Seite zwischendurch neu laedt: nach 330 s Wartezeit war das Dokument 37 s alt), sondern durch Test 19 mit gestellter Uhr: nach `advanceTimersByTime(300_000)` werden **beide** Abrufe erneut ausgefuehrt. **Zahlen:** 429 → 399, a11y 30 → 1, web-Tests 69/484 → 73/529, api 72/1143 unveraendert, type-check 4/4, lint 5/5, keine neuen Unterdrueckungen. | 2026-09-21 | a8531d4,3d0bc0b,0c89c13,b601141,e651c24,+7 | [260921-jt4-barrierefreiheit-mit-bedienentscheidunge](./quick/260921-jt4-barrierefreiheit-mit-bedienentscheidunge/) |
 | 260921-ldf | **Der Wackeltest war ein echter Produktfehler — nachgewiesen, nicht vermutet.** CI-Lauf 395 war rot; durchgefallen war ein Test aus quick-260914-m97, rund einmal in 17 vollen Laeufen, isoliert nie. Symptom: Vorschaubild da, Haekchen "Bildschirmfoto anhaengen" aus. **Ursache:** der Fehler-melden-Dialog war dauerhaft eingehaengt, sein `useState(screenshot !== null)` lief damit genau einmal — beim allerersten Laden der Seite, als noch kein Bild existierte — und der richtige Wert wurde erst von einem `useEffect` nachgezogen, der bauartbedingt nach dem Commit laeuft. **Beleg, deterministisch statt statistisch:** ein MutationObserver ueber jeden einzelnen DOM-Commit zeigt gegen den alten Stand, ohne jede kuenstliche Verzoegerung: `COMMIT dialog=true img=ja box=AUS` gefolgt von `COMMIT dialog=true img=ja box=AN`. Der falsche Zustand entsteht bei JEDEM Oeffnen, nicht nur unter Last, und haelt zwei Makrotask-Runden — dazwischen darf der Browser zeichnen, ein Nutzer kann es also sehen. **Ehrliche Einordnung der Tragweite:** die Korrektur kommt binnen Millisekunden, lange bevor jemand "Senden" treffen kann. Der befuerchtete Fall (Bild gesehen, abgeschickt, Bild fehlt) ist NICHT erreichbar; es bleibt ein kurzes Flackern. Repariert wurde trotzdem der Produktcode, nicht der Test — wer einen wirklich vorhandenen falschen Zustand im Test wegberuhigt, laesst ihn stehen. **Zwei Teilursachen, einzeln reicht keine:** der Dialog wird nur noch eingehaengt, solange er offen ist (frischer Mount je Oeffnen, der zuruecksetzende Effekt entfaellt), und das Haekchen wird beim Rendern abgeleitet statt nachgezogen. Dieselbe Ursache lag an einer zweiten Stelle: nach einem Versand stand beim erneuten Oeffnen zwei Runden lang der alte Danke-Bildschirm im DOM. **Zur Statistik, weil es der Kern der Sache ist:** 20 volle Laeufe ohne Fehlschlag gelten ausdruecklich NICHT als Beweis — bei der Ausgangsrate 1:17 waeren sie auch ohne Reparatur zu rund 30 Prozent zu erwarten. Tragend ist, dass der falsche Zwischenzustand nicht mehr existiert und die neuen Tests gegen den alten Stand 5 von 5 rot sind. Kein `retry`, kein hoeheres Zeitlimit — die Ursache war nie blosse Zeit. **Zwei Konstruktionsfehler des Tests mitbehoben:** das `expect` innerhalb der Attrappe (wirft es, landet der Fehler mitten im `await` von `captureScreenshot`, dessen `catch` still `null` liefert — der Test waere viel spaeter mit "kein Vorschaubild" durchgefallen, also in die falsche Richtung zeigend) und die per `Object.defineProperty` gesetzte `document.body`-Groesse, die `cleanup()` ueberlebte und alle zwoelf folgenden Tests derselben Datei 3200x1000 sehen liess. **Widerlegt unterwegs:** der Verdacht auf den dynamischen Import von `html-to-image` — er loest auf, bevor ein zuvor gesetzter `setTimeout(0)` feuert, ueberschreitet also keine Makrotask-Grenze. **Zahlen:** Warnungen 399 unveraendert, web-Tests 529 → 531, api 72/1143 unveraendert, type-check 4/4, lint 5/5. | 2026-09-21 | c0ab5b5,de7fdb7,9f02fcc,a6181e2 | [260921-ldf-wackeltest-fehler-melden-haekchen-bildsc](./quick/260921-ldf-wackeltest-fehler-melden-haekchen-bildsc/) |
+| 260921-m34 | **288 `any` im Backend beurteilt: 15 bleiben, mit Urteil je Stelle.** Drei Durchgaenge. **Der groesste Posten war ein einziges Missverstaendnis:** 105 Stellen trugen `forTenant(...) as any`, obwohl `prisma.$extends()` laengst einen getypten Klienten liefert — die Zusicherung war nie noetig. Entfernen ergab genau EINEN Folgefehler, und der war selbst ein Befund (eine Handannotation, die nur existierte, um unter dem ungetypten Klienten eine Meldung zu umgehen, und falsch geworden war). **Aufgabe 2 war die sicherheitsrelevante:** ein gemeinsamer Typ `AuthUser` fuer die Aufrufer-Identitaet. Die `tenantId`-Frage wurde HERGELEITET, nicht nach Bequemlichkeit entschieden — `string | undefined` erzeugt 8 Fehler, `string` keinen, und das war ausdruecklich kein Argument. Belege: Pflichtspalte in `schema.prisma:38`, Bestandstyp `SessionUser`, und der Super-Admin-Zweig in `TenantGuard`. Der dritte Beleg widerlegt `string` NICHT, weil der Waechter sein Anfrageobjekt ungetypt holt und `AuthUser` gar nicht liest — der Zweig kann also nicht zu totem Code werden. Dass es ihn gibt, steht trotzdem im Typsystem: `AuthenticatedRequest.tenantId` ist `string | null | undefined`, das `null` stammt nur von dort, mit Warnkommentar. `tenant.guard.ts` ueber den ganzen Lauf 0 geaenderte Zeilen (Tor). **Aufgabe 3 ist zugleich das Urteilsregister:** typisiert 252, auf `unknown` umgestellt 21, bleibt 15 — jede der 15 mit Begruendung im Code (6 node-forge, wo die mitgelieferten Typen die Bibliothek nachweislich falsch beschreiben; 3 Cron; 4 `withTenantTransaction`, wo der genaue Typ eine bewusst unvollstaendige Test-Attrappe braeche; 2 imapflow). Null war ausdruecklich NICHT das Ziel. **Vier Befunde gemeldet statt still repariert** — zwei davon brauchen eine Entscheidung des Nutzers: (B-06, sicherheitsrelevant) `imap.provider.ts:402` setzt `requireTLS`, das es in imapflow 1.4.3 NIRGENDS gibt (vom Orchestrator unabhaengig nachgeprueft: kein Treffer im ganzen Paket). Die Option wird still verworfen, die Einstellung "STARTTLS" erzwingt also nichts; die Bibliothek faellt dann auf ihr Standardverhalten zurueck und setzt laut eigener Dokumentation unverschluesselt fort, wenn der Server kein STARTTLS anbietet — sie nennt das selbst eine Downgrade-Angriffsflaeche. Richtig waere `doSTARTTLS: true`. Die `as any`-Zusicherung hatte das verdeckt. (B-05) `imap.provider.ts:78` liest `.parameters` von einer Zeichenkette (imapflow deklariert `disposition: string`, die Parameter liegen in `dispositionParameters`) — zur Laufzeit immer `undefined`, Outlook-Anhaenge als `application/octet-stream` werden ueber Content-Disposition nicht erkannt; betrifft den DKV-Rechnungseinzug. Dazu (B-04) eine Falle im RLS-Erkenner (er zaehlt jede `select:`-Angabe ausserhalb eines Modellaufrufs als Verstoss) — Erkenner NICHT aufgeweicht, Typ anders hergeleitet; und (B-07) httpntlm liefert den Rumpf als Zeichenkette, nicht als Buffer. **Zahlen:** Diagnosen 399 → 125, `any` im Quellcode 288 → 15, `apps/web` 1 → 0, Disziplin-Zaehler unveraendert (`as unknown as` 33, `noNonNullAssertion` 56, Unterdrueckungen 1, `ts-expect-error` 0), api 72/1143, web 73/531, type-check 4/4, lint 5/5, RLS-Waechter 30/30. | 2026-09-21 | b188946,f2fc39f,7c9d7c1,52668c2,32591b6,3892c5f,d8fb9ae | [260921-m34-288-any-im-backend-einzeln-beurteilen-un](./quick/260921-m34-288-any-im-backend-einzeln-beurteilen-un/) |
 
 ## Deferred Items
 
@@ -498,4 +499,4 @@ Last session: 2026-09-21T04:50:00Z
 Resumed: 2026-09-21 — Sitzung ueber /gsd-resume-work fortgesetzt. Stand geprueft: Arbeitsbaum sauber, main == origin/main auf 55aa287, CI-Lauf 387 fuer 55aa287 erfolgreich (Beta-Images gebaut). Push und CI aus dem letzten Stopp-Punkt sind damit erledigt.
 Stopped at: Warte auf Nutzerentscheidung, womit weitergearbeitet wird. Offen fuer den User: alpha pullen (web+api) und danach am Windows-VM-Client die echte Fehlermeldung schicken (Betreff `[Desktop/Windows]` + `Herkunft:`-Zeile pruefen); eigenen Arbeitsplatz-Client einmal per Browser-Installer erneuern; Freigabe 1.3.0 auf Zuruf. Technisch offen im Ledger: WINDOWS #35 (Biome laeuft nicht — biome.json:3 `organizeImports` ist in Biome 2.5.0 unbekannt, `biome check` bricht mit Konfigurationsfehler ab, reproduziert 2026-09-21) und WINDOWS #36 (403-Antworten bleiben in handleSubmit/handleDelete ohne sichtbare Reaktion).
 Resume file: None
-Last activity: 2026-09-21 - Quick 260921-ldf: der Wackeltest aus CI-Lauf 395 war ein echter Produktfehler — der Fehler-melden-Dialog stand bei jedem Oeffnen kurz mit ausgeschaltetem Haekchen da; Ursache behoben, nicht der Test beruhigt
+Last activity: 2026-09-21 - Quick 260921-m34: 288 any im Backend auf 15 gesenkt, jede verbliebene mit Urteil; dabei vier Befunde gemeldet statt still repariert, darunter ein sicherheitsrelevanter: die IMAP-Einstellung STARTTLS erzwingt nichts, weil die gesetzte Option in imapflow gar nicht existiert

.planning/quick/260921-m34-288-any-im-backend-einzeln-beurteilen-un/260921-m34-SUMMARY.md

@@ -0,0 +1,414 @@
+---
+phase: quick-260921-m34
+plan: 01
+subsystem: apps/api (Typdisziplin)
+tags: [typescript, any, refactor, mandantentrennung, prisma, node-forge, imapflow]
+status: complete
+requires: []
+provides:
+  - "apps/api/src/auth/types/auth-user.ts (AuthUser, AuthenticatedRequest, JwtPayload, UploadedFileLike)"
+  - "apps/api/src/prisma/prisma-error.ts (prismaErrorCode, prismaErrorTarget)"
+affects:
+  - "apps/api/src (48 Dateien)"
+  - "apps/web/src/test/setup.ts"
+tech-stack:
+  added: []
+  patterns:
+    - "catch (e: unknown) plus Form-Eingrenzung statt catch (e: any)"
+    - "Mitgelieferte Bibliothekstypen vor eigenen Handschnittstellen"
+    - "Ehrliches any mit geschriebener Begruendung statt erzwungener Zusicherung"
+key-files:
+  created:
+    - apps/api/src/auth/types/auth-user.ts
+    - apps/api/src/prisma/prisma-error.ts
+  modified:
+    - apps/api/src/prisma/prisma-tenant.extension.ts
+    - apps/api/src/cert-manager/cert-manager.service.ts
+    - apps/api/src/inbox/imap.provider.ts
+    - apps/api/src/inbox/exchange-inbox.provider.ts
+    - apps/api/src/calendar/providers/exchange.provider.ts
+    - apps/api/src/user/user.service.ts
+    - apps/api/src/groups/groups.service.ts
+    - apps/api/src/ldap/ldap.service.ts
+    - apps/api/src/mail/mail.service.ts
+decisions:
+  - "AuthUser.tenantId ist string, aus drei Belegen hergeleitet; der SUPER_ADMIN-Zweig in TenantGuard bleibt unangetastet"
+  - "Fehlereingrenzung per Form-Pruefung statt instanceof PrismaClientKnownRequestError, weil alle Testdoppel angehaengte .code-Felder werfen"
+  - "15 Befunde bleiben mit Urteil und Begruendung stehen; Null war ausdruecklich nicht das Ziel"
+metrics:
+  duration: "1h 20min (16:09 bis 17:29 Uhr, 21.09.2026)"
+  completed: 2026-09-21
+actuals:
+  tokens: 151201
+  tasks: 3
+  commits: 7
+plan_head_before: 8d845e7
+---
+
+# Quick-Aufgabe 260921-m34: 288 any im Backend einzeln beurteilen Summary
+
+Die 288 `any`-Befunde in `apps/api` sind auf **15** gefallen, jeder der 288 hat
+ein Urteil mit Begruendung, und die Arbeit hat sieben falsche Annahmen im
+Bestandscode aufgedeckt, die alle gemeldet und keine still repariert wurden.
+
+## Die Zahl, und was sie bedeutet
+
+| Groesse | Ausgang | Ende |
+|---|---|---|
+| `lint/suspicious/noExplicitAny` in `apps/api/src` | **288** (48 Dateien) | **15** (7 Dateien) |
+| dasselbe in `apps/web/src` | 1 | 0 |
+| `lint/style/noNonNullAssertion` in `apps/api/src` | 56 | 56 |
+| `as unknown as` in `apps/api/src` | 33 | 33 |
+| `ts-expect-error` / `ts-ignore` | 0 / 0 | 0 / 0 |
+| Lint-Unterdrueckungsmarker | 1 | 1 |
+| Befunde der Schwere `error` | 0 | 0 |
+
+Die vier Zeilen in der Mitte sind die wichtigsten der Tabelle. Sie belegen, dass
+die 273 verschwundenen Befunde tatsaechlich getypt und nicht bloss stillgelegt
+wurden: haette die Arbeit die bequeme Abkuerzung genommen, waere mindestens einer
+dieser Zaehlwerte gestiegen. Keiner ist gestiegen.
+
+### Aufteilung der 288 auf die drei Urteile (D-01)
+
+| Urteil | Anzahl | Was dahintersteckt |
+|---|---:|---|
+| **typisiert** | 252 | Die Zusicherung war ueberfluessig oder der richtige Typ war ableitbar — aus Prismas Erweiterungstypen, aus den beiden Signierstellen des Tokens, aus `schema.prisma`, oder aus den mitgelieferten Typen einer Fremdbibliothek. |
+| **auf `unknown` umgestellt** | 21 | 18 Fehlerfaenger, die beiden `.then((results: unknown[]) => ...)` in `prisma-tenant.extension.ts` und `intercept(): Observable<unknown>`. |
+| **bleibt** | 15 | Register unten. Jede Stelle traegt ihre Begruendung ausserdem direkt im Code. |
+| | **288** | |
+
+Der Plan hat 20 bis 40 verbleibende Befunde erwartet; es sind 15 geworden. Der
+Unterschied kommt nicht daher, dass hier mehr erzwungen wurde, sondern aus drei
+Messungen, die guenstiger ausfielen als die Vorschau: `@types/node-forge`
+beschreibt PKCS7 besser als angenommen (die vier `p7: any` liessen sich mit dem
+mitgelieferten `Captured<...>`-Typ aufloesen), `imapflow` deklariert
+`node.parameters` bereits vollstaendig, und `expect.extend(matchers)` in
+`apps/web` brauchte seine Zusicherung schlicht nicht mehr. Die Zaehlwerte oben
+sind der Beleg, dass dabei nichts gegen eine Behauptung getauscht wurde.
+
+## Urteilsregister: die 15 Stellen, die bleiben
+
+Jede dieser Zeilen steht so auch als Kommentar an der Codestelle. Wer spaeter
+hier aufraeumen will, findet die Begruendung dort, wo er zuerst nachsieht.
+
+| # | Datei:Zeile | Form | Begruendung (gemessen) |
+|---|---|---|---|
+| 1 | `cert-manager/cert-manager.service.ts:296` | `cert.publicKey as any` | `@types/node-forge` kennt nur `PublicKey = rsa.PublicKey \| ed25519.Key` (index.d.ts:232). Der EC-Zweig darunter liest `curve` und `params.curve.q.bitLength()` — Felder, die node-forge zur Laufzeit liefert, die der mitgelieferte Typ aber gar nicht kennt. Eine Umdeutung ueber zwei Stufen wuerde dieselbe Luecke verdecken und zusaetzlich geprueft aussehen. |
+| 2 | `cert-manager/cert-manager.service.ts:318` | `(e: any)` | `Certificate.extensions` ist in `@types/node-forge` als `any[]` deklariert (index.d.ts:435). Der mitgelieferte Typ sagt ueber den Inhalt einer Erweiterung nichts aus. |
+| 3 | `cert-manager/cert-manager.service.ts:319` | `(sanExt as any)` | wie 2 — `sanExt` stammt aus demselben `any[]`. |
+| 4 | `cert-manager/cert-manager.service.ts:319` | `(n: any)` | wie 2. Eine eigene Schnittstelle fuer `altNames` waere unbelegt: der Compiler koennte sie an keiner Stelle gegen etwas pruefen, sie saehe aber geprueft aus (D-02). |
+| 5 | `cert-manager/cert-manager.service.ts:589` | `null as any` | node-forge 1.4.0 nimmt hier einen fehlenden Schluessel an und erzeugt ein reines Zertifikatsbuendel; `@types/node-forge` schliesst `null` aus. Die mitgelieferten Typen beschreiben die Bibliothek an dieser Stelle nachweislich falsch. |
+| 6 | `cert-manager/cert-manager.service.ts:752` | `null as any` | wie 5, zweite Aufrufstelle. |
+| 7 | `dkv/dkv-scheduler.service.ts:144` | `job as any` | Ohne die Zusicherung meldet `tsc`, dass das lokale `job` nur die Form `{ start(): void }` hat, waehrend `addCronJob()` einen vollstaendigen `CronJob` verlangt. Ursache ist der `require()`-Umweg aus 07-04 (pnpm-Isolation, `cron` ist nur mittelbare Abhaengigkeit). Aufloesen hiesse die Beschaffung der Klasse aendern (Verhaltensaenderung, D-03) oder `cron` direkt aufnehmen (neue Abhaengigkeit, D-04). |
+| 8 | `tenders/tender-digest.scheduler.ts:94` | `job as any` | wie 7. |
+| 9 | `tenders/tender-scheduler.service.ts:143` | `job as any` | wie 7. |
+| 10 | `groups/groups.service.ts:373` | `(u: any)` | Gefolge von 12: `tx` ist selbst `any`, und `any.map()` gibt dem Parameter keine kontextuelle Typisierung. Faellt automatisch mit 12. |
+| 11 | `groups/groups.service.ts:390` | `(a: any)` | wie 10. |
+| 12 | `prisma/prisma-tenant.extension.ts:264` | `fn: (tx: any)` | In Aufgabe 1 gemessen und verworfen: `Prisma.TransactionClient` erzwingt an den vier Aufrufstellen vollstaendige Prisma-Erzeugungstypen und bricht das absichtlich unvollstaendige Testdoppel in `prisma-tenant.extension.spec.ts` (TS2322). Das waere eine Aenderung an einer Teststruktur, kein ehrliches Typisieren. |
+| 13 | `prisma/prisma-tenant.extension.ts:266` | `async (tx: any)` | wie 12, dieselbe Funktion. |
+| 14 | `inbox/imap.provider.ts:78` | `(node as any).disposition...` | **Befund B-05.** Bleibt absichtlich sichtbar: der Ausdruck liest `.parameters` von einer Zeichenkette und ist zur Laufzeit immer `undefined`. Umbiegen auf `dispositionParameters` waere eine Verhaltensaenderung. |
+| 15 | `inbox/imap.provider.ts:402` | `} as any` | **Befund B-06.** Bleibt absichtlich sichtbar: die Zusicherung verdeckt, dass `requireTLS` in imapflow 1.4.3 gar nicht existiert. Die Option zu entfernen waere eine stille Reparatur. |
+
+Die Gruppen dahinter sind klein: sechs Stellen an node-forge, drei an der
+Cron-Beschaffung, vier an der Transaktionshilfe, zwei absichtlich stehen
+gelassene Befunde an imapflow.
+
+## Die aufgedeckten falschen Annahmen (D-03)
+
+Diese Aufgabe hat ohne bekannten Fehler begonnen. Das hier ist ihr eigentlicher
+Ertrag: sieben Stellen, an denen der Bestandscode etwas annimmt, was nicht
+stimmt. **Keine davon wurde still repariert** — das Verhalten der API ist
+unveraendert.
+
+**B-01 — `tenders/tender-matching.service.ts:159` (Aufgabe 1).**
+Die Handannotation `(match: { tender: unknown })` verengte den Wert falsch,
+sobald der Prisma-Klient richtig getypt war. Sie existierte nur, um unter dem
+`any`-Klienten TS7006 zu vermeiden. Annotation geloescht, damit der hergeleitete
+Typ durchkommt; keine Zusicherung an ihrer Stelle.
+
+**B-02 — `dashboard/dashboard.controller.ts:74` (Aufgabe 2b).**
+Der Handler las `req.user?.role` nach `extractContext()` und gab die Rolle an
+`getWidgets(role: Role)` weiter, das sie zwingend verlangt. Die Annahme "hier
+gibt es immer einen Aufrufer" stimmt — die Pruefung "No user context" erzwingt
+sie —, aber sie stand in einer anderen Methode, wo der Compiler sie nicht sehen
+konnte. `extractContext()` gibt die Rolle jetzt mit zurueck: keine neue Pruefung,
+kein erfundener Wert, gleiche Reihenfolge, gleiche Meldungen.
+
+**B-03 — `tenders/tenders.controller.ts:142` (Aufgabe 2b).**
+`resolveRequestingTenantId()` erklaerte `string | undefined`, liest aber
+`req.tenantId`, das `TenantGuard` fuer einen SUPER_ADMIN ohne Mandanten auf
+`null` setzt. Die Erklaerung war nie vollstaendig. Auf
+`string | null | undefined` erweitert — reine Erklaerung: die Funktion
+entscheidet seit jeher ueber den Wahrheitswert und faellt bei `null` wie bei
+`undefined` zu (nur global sichtbare Ausschreibungen).
+
+**B-04 — Falle im Mandantentrennungs-Erkenner (Aufgabe 3b).**
+Die naheliegende Prisma-Schreibweise `Prisma.UserGetPayload<{ select: typeof X }>`
+laesst `rls-access-inventory.spec.ts` rot werden: der Erkenner zaehlt **jede**
+`select:`-Angabe ausserhalb eines erkannten Modellaufrufs als Verstoss und
+unterscheidet Typposition nicht von Aufrufposition. Beim ersten Versuch gemessen.
+Der Erkenner ist die Mandantenkontrolle (T-M34-03) und wurde **nicht**
+aufgeweicht — stattdessen leitet der Zeilentyp ueber `Pick<User, keyof typeof
+PLATFORM_USER_SELECT>` her, was ohne das Wort `select` auskommt. Wer kuenftig
+`UserGetPayload` einsetzen will, muss zuerst den Erkenner erweitern, nicht die
+Ausnahmeliste.
+
+**B-05 — `inbox/imap.provider.ts:78` (Aufgabe 3c). Sicherheitsnah, offen.**
+`(node as any).disposition?.parameters?.filename` liest `.parameters` von einer
+**Zeichenkette**: imapflow deklariert `disposition` als `string`
+(`imap-flow.d.ts:448`, also "attachment"/"inline"), die zugehoerigen Parameter
+liegen in einem eigenen Feld `dispositionParameters` (:450). Der Ausdruck ist zur
+Laufzeit **immer** `undefined`, `dispositionFilename` ist stets `''`. Folge:
+Anhaenge, die als `application/octet-stream` kommen (typisch fuer Outlook),
+werden ueber den Dateinamen aus Content-Disposition **nicht** erkannt — nur ueber
+den aus Content-Type. Betrifft den DKV-Rechnungseinzug. Nicht repariert, weil das
+Umbiegen erstmals Anhaenge einsammeln wuerde, die heute uebersprungen werden —
+eine Verhaltensaenderung, die ein Mensch entscheiden muss.
+
+**B-06 — `inbox/imap.provider.ts:402` (Aufgabe 3c). Sicherheitsnah, offen.**
+`requireTLS: config.encryption === 'starttls'` wird an `new ImapFlow(...)`
+uebergeben, aber `requireTLS` kommt in imapflow 1.4.3 **nirgends** vor — weder in
+`ImapFlowOptions` (`lib/imap-flow.d.ts`) noch im Laufzeitcode
+(`lib/imap-flow.js`), beides durchsucht. Die Option wird still verworfen; ein
+STARTTLS-Zwang entsteht durch sie nicht. Genau das `} as any` hat es verdeckt.
+Die Einstellung "STARTTLS" in der Postfach-Konfiguration bewirkt damit nicht das,
+was ihr Name verspricht. Nicht repariert (D-03), Zusicherung bleibt sichtbar
+stehen, damit der Befund in der Zaehlung nicht verschwindet.
+
+**B-07 — httpntlm-Antwortrumpf (Aufgabe 3c). Ohne Auswirkung, aber falsch.**
+Beide Exchange-Wege riefen `res.body?.toString('utf-8')` auf und nahmen damit
+einen Buffer an. Gemessen: httpntlm reicht an httpreq durch, und httpreq gibt den
+Rumpf als **Zeichenkette** zurueck, solange die Option `binary` nicht gesetzt ist
+(`httpreq@1.1.1/lib/httpreq.js:391`) — keiner der beiden Aufrufer setzt sie. Das
+ging bisher nur gut, weil `String.prototype.toString()` sein Argument ignoriert.
+Die Testdoppel reichen umgekehrt wirklich einen Buffer herein, beide Formen kommen
+also vor. `NtlmResponse.body` nennt jetzt beide; die Fallunterscheidung liefert
+fuer jede exakt dasselbe Ergebnis wie zuvor.
+
+## Die `tenantId`-Entscheidung im gemeinsamen Aufrufer-Typ
+
+`AuthUser.tenantId` ist **`string`**, nicht `string | undefined`. Die Messung
+allein haette in die falsche Richtung gedraengt (`string | undefined` erzeugte
+acht Fehler im Produktivcode, `string` keinen); entschieden wurde auf drei
+Belegen:
+
+1. `apps/api/prisma/schema.prisma` deklariert `User.tenantId String` **ohne** `?`.
+   Die Spalte ist Pflicht, und beide Signierstellen schreiben genau diesen
+   Spaltenwert — seit dem ersten Commit des Anmeldedienstes (6190f3d) gibt es
+   keine Token-Erzeugung ohne diesen Anspruch.
+2. Der Bestand beschreibt dasselbe Objekt in `SessionUser`
+   (`bug-reports.service.ts`) bereits als `tenantId: string`. `SessionUser` ist
+   jetzt ein `Pick<>` von `AuthUser`, damit es keine zweite, abweichende
+   Beschreibung desselben Objekts gibt.
+3. `TenantGuard` haelt fuer SUPER_ADMIN einen Zweig ohne Mandanten vor und setzt
+   dort `req.tenantId = null`.
+
+Beleg 3 spricht **nicht** gegen `string`, und genau daran haengt die
+Sicherheitsfrage: der Zweig in `TenantGuard` ist eine Tiefenverteidigung gegen
+ein Token ohne diesen Anspruch, und er liest `AuthUser` gar nicht — der Waechter
+holt sein Anfrageobjekt ungetypt. Dieser Typ kann den Zweig also nicht zu totem
+Code machen. Dass es den Zweig gibt, steht ausserdem weiterhin im Typsystem, nur
+an der richtigen Stelle: `AuthenticatedRequest.tenantId` ist
+`string | null | undefined`.
+
+Am Typ steht dazu eine ausdrueckliche Warnung fuer spaetere Leser, dass der
+SUPER_ADMIN-Zweig ein Schutzzweig ist und nicht entfernt oder wegtypisiert werden
+darf (T-M34-01). `tenant.guard.ts` wurde in diesem ganzen Lauf **nicht
+angefasst** — in Aufgabe 2 per `git diff --stat` nachgewiesen.
+
+## Was die Arbeit sonst noch geaendert hat
+
+**Zwei neue Dateien, beide klein und begruendet.**
+`apps/api/src/auth/types/auth-user.ts` traegt den gemeinsamen Aufrufer-Typ; jedes
+Feld hat seine Herkunft als Kommentar. `apps/api/src/prisma/prisma-error.ts`
+traegt `prismaErrorCode()` und `prismaErrorTarget()`.
+
+**Warum die Fehlereingrenzung Form-Pruefungen macht und kein `instanceof`.**
+Der naheliegende Weg waere
+`err instanceof Prisma.PrismaClientKnownRequestError` gewesen. Gemessen: samtliche
+Testdoppel in `apps/api` werfen `new Error(...)` mit angehaengtem `.code`
+(groups, user, ldap, tenders, module-grants, admin-seed) und
+`dashboard.service.spec.ts:451` ein reines `{ code: 'P2002' }`. Ein
+`instanceof`-Test haette all diese Werte in den jeweils **anderen** Zweig
+geschickt — eine Verhaltensaenderung, und nach T-M34-06 genau die Art von
+Aenderung, die einen Hintergrundlauf kuenftig abbrechen laesst, der heute
+weiterlaeuft. Die Helfer bilden `err?.code` und `err?.meta?.target` deshalb eins
+zu eins ab, nur ohne `any`.
+
+**Nebengewinne ohne neue Zusicherungen.** In `cert-manager.service.ts` sind 25
+Zusicherungen der Form `file.buffer as Buffer` weggefallen, weil `file` kein
+`any` mehr ist. In `dkv` und `settings` fielen `req.tenantId as string |
+undefined` weg. `as unknown as` ist trotzdem bei 33 geblieben — dieselbe Zahl wie
+zu Beginn.
+
+## Abweichungen vom Plan
+
+**1. [Regel 3 — blockierend] Neue Datei `prisma/prisma-error.ts` statt 18
+Eingrenzungen von Hand.** Der Plan nennt fuer Aufgabe 3 Schritt A keine neue
+Datei. 18 Fehlerfaenger einzeln mit einer vierzeiligen Form-Pruefung zu versehen
+haette dieselbe Logik achtzehnmal wiederholt und die Begruendung, warum kein
+`instanceof` verwendet wird, achtzehnmal daneben. Die Datei liegt in `prisma/`,
+weil alle Aufrufer Prisma-Fehlercodes pruefen. Keine neue Abhaengigkeit.
+Commit: `32591b6`.
+
+**2. [Regel 1 — Fehler] Erste Fassung von `user.service.ts` machte die
+Mandanten-Spec rot.** `Prisma.UserGetPayload<{ select: typeof X }>` hat
+`rls-access-inventory.spec.ts` gebrochen (siehe B-04). Sofort im selben Schritt
+auf `Pick<User, ...>` umgestellt, der Erkenner blieb unangetastet, Spec wieder
+30/30. Commit: `3892c5f`.
+
+**3. [Messung weicht vom Plan ab] `calendar.service.ts:206/255` sind keine
+Prisma-JSON-Eingaben.** Der Plan vermutete `Prisma.InputJsonValue`. Gemessen:
+es sind dynamisch gebaute Erzeugungs- und Aenderungseingaben fuer
+`CalendarSource`. Richtig getypt mit
+`Prisma.CalendarSourceUncheckedCreateInput` / `...UncheckedUpdateInput`.
+Commit: `3892c5f`.
+
+**4. [Messung weicht vom Plan ab] node-forge war besser beschrieben als
+erwartet.** Der Plan rechnete damit, dass ein Teil der elf Stellen bleibt.
+Gemessen: die vier `p7: any` liessen sich mit dem mitgelieferten
+`Captured<PkcsEnvelopedData | PkcsSignedData>` aufloesen, `cert.siginfo` war
+ohnehin getypt. Sechs bleiben, fuenf wurden getypt. Commit: `d8fb9ae`.
+
+## Pruefungen — die echten Ausgaben
+
+### `noExplicitAny`, `noNonNullAssertion`, `error`-Befunde
+
+```
+$ npx biome lint --reporter=json --max-diagnostics=2000 apps/api/src | python3 -c "..."
+any 15 nonnull 56 error 0
+Rueckgabewert: 0
+```
+
+Schranke der Aufgabe: `any <= 45`, `nonnull <= 56`, `error == 0`. Alle drei
+eingehalten.
+
+### Vollstaendige Restliste (Pruefung 2 der Aufgabe)
+
+```
+apps/api/src/cert-manager/cert-manager.service.ts:296:40  |  const pubKey = cert.publicKey as any;
+apps/api/src/cert-manager/cert-manager.service.ts:318:48  |  const sanExt = cert.extensions?.find((e: any) => e.name === 'subjectAltName');
+apps/api/src/cert-manager/cert-manager.service.ts:319:41  |  const san: string[] = ((sanExt as any)?.altNames ?? []).map((n: any) =>
+apps/api/src/cert-manager/cert-manager.service.ts:319:71  |  const san: string[] = ((sanExt as any)?.altNames ?? []).map((n: any) =>
+apps/api/src/cert-manager/cert-manager.service.ts:589:19  |  null as any, // cert-only PFX - null key accepted by node-forge 1.4.0
+apps/api/src/cert-manager/cert-manager.service.ts:752:19  |  null as any, // cert-only PFX - null key accepted by node-forge 1.4.0
+apps/api/src/dkv/dkv-scheduler.service.ts:144:55  |  this.schedulerRegistry.addCronJob(jobName, job as any);
+apps/api/src/groups/groups.service.ts:373:33  |  data: users.map((u: any) => ({
+apps/api/src/groups/groups.service.ts:390:39  |  data: activations.map((a: any) => ({
+apps/api/src/inbox/imap.provider.ts:78:15  |  ((node as any).disposition?.parameters?.filename as string | undefined)?.toLowerCase() ?? '';
+apps/api/src/inbox/imap.provider.ts:402:10  |  } as any);
+apps/api/src/prisma/prisma-tenant.extension.ts:264:12  |  fn: (tx: any) => Promise<T>,
+apps/api/src/prisma/prisma-tenant.extension.ts:266:41  |  return prisma.$transaction(async (tx: any) => {
+apps/api/src/tenders/tender-digest.scheduler.ts:94:63  |  this.schedulerRegistry.addCronJob(this.JOB_NAME, job as any);
+apps/api/src/tenders/tender-scheduler.service.ts:143:61  |  this.schedulerRegistry.addCronJob(this.JOB_NAME, job as any);
+TOTAL 15
+```
+
+Jede dieser 15 Zeilen steht im Urteilsregister oben. `apps/web/src` liefert
+keine Zeile mehr.
+
+### Unterdrueckungsmarker
+
+```
+### 3. Unterdrueckungsmarker
+keine stillgelegten Stellen
+```
+
+Das heisst im Einzelnen: `ts-expect-error` 0, `ts-ignore` 0, `biome-ignore` 1
+(der eine Bestandsmarker), `as unknown as` 33.
+
+### `biome.json` und Abhaengigkeiten
+
+```
+### 4. biome.json
+biome.json unberuehrt
+
+### 5. Abhaengigkeiten
+keine neuen Abhaengigkeiten, keine Versionsspruenge
+```
+
+Geprueft ueber `git diff --stat HEAD` gegen `biome.json`, alle drei
+`package.json` und `pnpm-lock.yaml` — jede Ausgabe leer.
+
+### Typlauf und Lint
+
+```
+### 6. type-check / lint
+type-check 4/4, lint 5/5
+```
+
+### Testsuiten
+
+```
+$ pnpm --dir apps/api run test
+ Test Files  72 passed (72)
+      Tests  1143 passed (1143)
+   Duration  8.05s
+
+$ pnpm --dir apps/web run test
+ Test Files  73 passed (73)
+      Tests  531 passed (531)
+   Duration  23.48s
+```
+
+Unveraenderte Zahlen gegenueber dem Ausgang (72/1143 und 73/531).
+
+### Mandantentrennungs-Erkenner, ausdruecklich einzeln
+
+```
+$ pnpm --dir apps/api exec vitest run src/prisma/rls-access-inventory.spec.ts
+ Test Files  1 passed (1)
+      Tests  30 passed (30)
+   Duration  557ms
+```
+
+Das ist die Kontrolle aus T-M34-03. Sie war in Aufgabe 3b einmal rot (B-04) und
+wurde nicht durch Aufweichen, sondern durch eine andere Typschreibweise wieder
+gruen.
+
+## Commits
+
+| Commit | Aufgabe | `any` in `apps/api` danach |
+|---|---|---:|
+| `b188946` | 1 — Mandantenbindung entzaubert, 105 unnoetige Zusicherungen | 149 |
+| `f2fc39f` | 2a — gemeinsamer Aufrufer-Typ, aus den Signierstellen abgeleitet | 137 |
+| `7c9d7c1` | 2b — getypte Anfrage in elf Controllern, zwei Befunde gemeldet | 66 |
+| `52668c2` | 2c — Hochladewege getypt, 25 Zusicherungen fallen mit | 56 |
+| `32591b6` | 3a — 18 Fehlerfaenger auf `unknown`, mit echter Eingrenzung | 38 |
+| `3892c5f` | 3b — Prisma-nahe Formen getypt, Erkenner-Falle gemeldet | 31 |
+| `d8fb9ae` | 3c — Randschicht beurteilt, drei Befunde gemeldet | **15** |
+
+Jeder Commit war fuer sich gruen: nach jedem lief `pnpm type-check` 4/4,
+`pnpm lint` 5/5 mit 0 Befunden der Schwere `error`, und beide Testsuiten mit
+unveraenderten Zahlen (D-05, D-06).
+
+## Offene Punkte fuer den Menschen
+
+Zwei der sieben Befunde brauchen eine Entscheidung, die diese Aufgabe nicht
+treffen durfte, weil beide das Verhalten aendern wuerden:
+
+- **B-05** (`imap.provider.ts:78`): sollen Anhaenge mit
+  `application/octet-stream` kuenftig auch ueber den Dateinamen aus
+  Content-Disposition erkannt werden? Heute werden sie es nicht.
+- **B-06** (`imap.provider.ts:402`): soll die Postfach-Einstellung "STARTTLS"
+  tatsaechlich einen Zwang bewirken? Heute wird die Option von imapflow
+  verworfen.
+
+Beide sind im Code markiert und stehen in der Zaehlung, verschwinden also nicht
+aus dem Blick.
+
+## Self-Check
+
+**BESTANDEN.**
+
+Geprueft, nicht behauptet:
+
+- Beide neu angelegten Dateien existieren auf der Platte
+  (`apps/api/src/auth/types/auth-user.ts`,
+  `apps/api/src/prisma/prisma-error.ts`).
+- Alle sieben genannten Commits sind in `git log` vorhanden.
+- `apps/api/src/tenant/tenant.guard.ts` ist ueber den gesamten Lauf
+  (`git diff --stat 8d845e7..HEAD`) unveraendert — keine einzige Zeile.
+- Die 15 Zeilen der Restliste stammen aus der maschinellen Biome-Ausgabe, nicht
+  aus dem Gedaechtnis, und stimmen eins zu eins mit dem Urteilsregister ueberein.
+- Die Aufteilung 252 + 21 + 15 ergibt 288.