From 5f80582a3708c40b2a4768f110b88f980ebd0b35 Mon Sep 17 00:00:00 2001 From: Schalli Date: Mon, 14 Sep 2026 12:06:13 +0200 Subject: [PATCH] =?UTF-8?q?docs(quick-260914-eym):=20Etappe=203c=20abgesch?= =?UTF-8?q?lossen=20und=20verifiziert=209/9=20=E2=80=94=20Zusammenfassung,?= =?UTF-8?q?=20Verifikation,=20Aktenstand?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_018N9CD3ebPKm1b32bPpBknY --- .planning/STATE.md | 19 +- .../260914-eym-SUMMARY.md | 275 ++++++++++++++++++ .../260914-eym-VERIFICATION.md | 199 +++++++++++++ 3 files changed, 485 insertions(+), 8 deletions(-) create mode 100644 .planning/quick/260914-eym-mandantentrennung-etappe-3c-systemkontex/260914-eym-SUMMARY.md create mode 100644 .planning/quick/260914-eym-mandantentrennung-etappe-3c-systemkontex/260914-eym-VERIFICATION.md diff --git a/.planning/STATE.md b/.planning/STATE.md index efaae29..900897e 100644 --- a/.planning/STATE.md +++ b/.planning/STATE.md @@ -4,11 +4,11 @@ milestone: v1.2 current_phase: 17 current_phase_name: eigene-ausschreibungs-quellen-je-nutzer status: verified -stopped_at: "Quick 260914-ebg abgeschlossen: WINDOWS #29 geschlossen — Zielrollen-Riegel in UserController.update/remove, 16 Spec-Tests, Falsifizierung bestanden, gepusht" -last_updated: "2026-09-14T08:41:17.656Z" -last_activity: 2026-09-11 +stopped_at: "Quick 260914-eym abgeschlossen: Etappe 3c Systemkontext — forSystem(), is_system_context(), fuenf system_read_policy, DKV je Mandant, Mail je Versand, WINDOWS #21/#30 fixed, #37 neu; 3 Commits gepusht" +last_updated: "2026-09-14T09:56:03.453Z" +last_activity: 2026-09-14 last_activity_desc: Quick 260910-jab — drei zu kurz greifende RLS-Regeln geschlossen (GroupMembership beide Seiten, ModuleGrant beide Ziele, TenderRssFeedSource Lese-/Schreibsplit), listForUser gebunden, Aktenstand kohaerent -state_head: 70d007bb47a2e39db54da47297dda162044dc79e +state_head: 939c8121a182fb8ad93b3b7f5b9fdcecc17a3ffd progress: total_phases: 17 completed_phases: 15 @@ -31,7 +31,7 @@ See: .planning/PROJECT.md (updated 2026-07-17) Phase: 17 (eigene-ausschreibungs-quellen-je-nutzer) — VERIFIED / passed Plan: 3 of 3 Status: Phase abgeschlossen und im Browser gegengeprueft — bereit fuer /gsd-ship -Last activity: 2026-09-14 - WINDOWS #29 geschlossen (260914-ebg, verifiziert 6/6); als naechstes Etappe 3c (Systemkontext), dann 3a, Etappe 4 nur nach Rueckfrage +Last activity: 2026-09-14 - Etappe 3c Systemkontext abgeschlossen (260914-eym, verifiziert 9/9) und WINDOWS #29 (260914-ebg, 6/6); offen: Etappe 3a (Produktfrage Subdomain vs. Login-Wahl), Etappe 4 nur nach Rueckfrage, Ship von Phase 17 Progress: [██████████] 100% @@ -122,6 +122,7 @@ Progress: [██████████] 100% | Phase quick-260911-cwh P01 | 21min | 3 tasks | 7 files | | Phase quick-260911-nke P01 | 1 Sitzung | 3 tasks | 27 files | | Phase quick-260914-ebg P01 | 6min | 3 tasks | 4 files | +| Phase quick-260914-eym P01 | 1 Sitzung | 3 tasks | 29 files | ## Accumulated Context @@ -303,6 +304,7 @@ Recent decisions affecting current work: - [Phase 17]: [quick-260911-cwh]: Bereich calendar Etappe 2 gebunden — Cache-Schluessel bleibt ohne Mandantenanteil (User.id ist plattformweit eindeutige UUID, Etappe-3-Entscheidung (1) betrifft nur username/email); keine neue Fehleruebersetzung fuer Besitzpruefungen noetig (Wettlauf-Fall wirft P2025, strukturell unerreichbar); refreshCacheInBackground zaehlt nicht als sechster Hintergrunddienst-Fall - [Phase 17]: 260911-nke: forTenant(prisma, tenantId, userId?) — optionaler dritter Parameter statt Schwesterhelfer, IS-NULL-OR-Form in den Regeln der zehn persoenlichen Tabellen, sechs Loch-Pruefungen umgedreht - [Phase 17]: [quick-260914-ebg]: Zielrollen-Riegel als eigenstaendige Pruefung nach der Mandantengrenze in UserController.update()/remove() eingezogen (Vorlage AuthService.adminResetPassword, T-FH9-04) — WINDOWS #29 geschlossen +- [Phase 17]: [quick-260914-eym]: forSystem(prisma) als Schwesterhelfer (eigene Detektor-Erkennungsform, Umkehrung der 3b-Begruendung); system_read_policy FOR SELECT auf fuenf Tabellen, SmtpConfig nicht (Mail-Startpfad entfernt, Transport je Versand nach Mandant); DKV-Planer Auftrag je Mandant (promote); Single-Flight-Riegel bleibt prozessweit -> WINDOWS #37 ### Pitfalls & Anti-Patterns @@ -399,6 +401,7 @@ None yet. | 260909-eor | Etappe 1 der Mandantentrennung: Anmeldeweg mandantenfaehig gemacht und alle Zugriffe klassifiziert. **Kernfund (#20):** `forTenant()` setzte den Mandantenkontext per set_config auf der Transaktionsverbindung, dispatchte die Abfrage aber ueber den aeusseren Client — empirisch reproduziert (set_config auf Backend-PID 254999, Abfrage auf 255000, Kontext dort NULL). Die Trennung hat damit nie funktioniert, auch nicht an den Stellen, die sie scheinbar nutzten; nach dem Scharfschalten haetten diese Abfragen NULL Zeilen geliefert, was der LDAP-Loeschzweig als 'Gruppe im Verzeichnis verschwunden' gedeutet und geloescht haette. Behoben und live nachgewiesen. Der Anmeldeweg bekam drei SECURITY-DEFINER-Funktionen als schmale Ausnahme (feste Spaltenliste, Gleichheitsbedingung, LIMIT 1) — eine Policy haette nicht gereicht, weil sie zwangslaeufig die ganze Tabelle freigibt. Browser-Gegenprobe lokal bestanden: Anmeldung laedt das Portal, falsches Kennwort verraet weiterhin nicht welches Feld, Kennwort-vergessen laeuft durch (der einzige Protokollfehler war ein lokal fehlender Mailserver, also NACH dem Datenbankzugriff). Klassifikation aller 227 Zugriffe in 59 Einheiten, maschinell gegen Abdriften abgesichert: 31 muessen mandantengebunden werden, 9 teilweise, 16 betreffen keine mandantengebundene Tabelle, 3 bleiben bewusst uebergreifend. 701 Tests gruen | 2026-09-09 | da0ac04 | [260909-eor-anmeldeweg-mandantenfaehig-machen-und-al](./quick/260909-eor-anmeldeweg-mandantenfaehig-machen-und-al/) | | 260910-jab | Die drei zu kurz greifenden Datenbankregeln geschlossen — T-JTS-02, T-JTS-03, WINDOWS #19 (bewusste Reihenfolge-Abweichung, vorgezogen auf Nutzerwunsch, statt wie geplant nach Etappe 2). Neue, handgeschriebene, lokal angewandte Migration `20260910120000_rls_widen_membership_grant_and_platform_read`: `GroupMembership` prueft jetzt beide Seiten der Beziehung (Gruppe UND Benutzer), `ModuleGrant` prueft zusaetzlich beide moeglichen Ziele mit Leer-Zulassung (D-04), `TenderRssFeedSource` bekommt vier nach Befehl getrennte Regeln (Lesen schliesst plattformweite Zeilen ein, Schreiben verlangt weiterhin einen Mandanten — die Trennung ist noetig, weil ein einzelner USING-Ausdruck sonst auch UPDATE/DELETE mitregelt). `SearchProvider` bewusst NICHT angefasst: die WINDOWS-#19-Praemisse ist fuer dieses Modell widerlegt (kein Codeweg erzeugt eine mandantenlose Zeile). Drei loch-behauptende Pruefungen im Wegwerf-Werkzeug UMGEKEHRT statt geloescht (66→74 Pruefungen), mit Verweis auf die alten Pruefungsnamen und Befundkennungen im Meldetext. Genau EIN Anwendungspfad musste mitgebunden werden (`TenderRssFeedSourceService.listForUser`) — sonst haette die Reparatur ihn still von 'liefert nach dem Scharfschalten nichts' auf 'liefert nur die plattformweiten Zeilen, taeuscht Vollstaendigkeit vor' verschlechtert; Falsifizierungsnachweis gefuehrt (Bindung zurueckgenommen, genau ein Test rot, zurueckgesetzt). WINDOWS #19 geschlossen mit Beleg, WINDOWS #24 neu angelegt (Verwaltungsweg fuer plattformweite Zeilen unter der Anwendungsrolle fehlt weiterhin — verschwindet nicht mit #19). Aktenstand kohaerent: Klassifikation, Kritikschrift (neuer Abschnitt "Regelschluss T-JTS-02, T-JTS-03 und WINDOWS #19" mit Signaltabelle beider Fehlerrichtungen je Regel), Betriebsanleitung, WINDOWS.md — fuenf ueberholte Bestandsstellen mit Nachtraegen versehen, alte Messprotokolle bleiben woertlich stehen. Selbst gemessen statt uebernommen: Baseline 833/56 Tests, 66/66 Live-Pruefungen; Endstand 839/56, 74/74; keine zweite Sitzungsvariable fuer den Benutzer gefunden (nur `app.current_tenant`). Rule-1-Fix: implizites `any` in `tenders.controller.ts` nach der Bindung behoben. `npx prisma` versuchte ungefragt Prisma 8 herunterzuladen — abgebrochen, lokale gepinnte 6.19.3 verwendet | 2026-09-10 | f4f3115,6b23735,03fb3bf | [260910-jab-mandantentrennung-die-drei-zu-kurz-greif](./quick/260910-jab-mandantentrennung-die-drei-zu-kurz-greif/) | | 260914-ebg | **WINDOWS #29 geschlossen — Zielrollen-Riegel in `UserController.update()`/`remove()`.** Ein ADMIN kann den SUPER_ADMIN seines Mandanten nicht mehr aendern (Kennwort, isActive, Rolle, Anmeldename, E-Mail) oder loeschen; Riegel nach der Mandantengrenze, vor der Rollenzuweisungs-Pruefung (Vorlage `AuthService.adminResetPassword`, T-FH9-04). Acht neue Spec-Tests (8 -> 16), Baseline 1020 -> 1028 Tests / 62 Dateien, Falsifizierung durch Rueckbau `Tests 2 failed | 14 passed (16)` (Test 9/13), unabhaengig vom Verifizierer wiederholt. Kopfkommentar `adminResetPassword` nachgezogen (T-FH9-05 nicht mehr offen). Ledger 16 offen / 1 zurueckgestellt / 19 geschlossen / 36 gesamt: #29 fixed, NEU #35 (Biome-Konfiguration im Bestand nicht lauffaehig, `pnpm lint` Leerlauf) und #36 (Admin-Frontend verschluckt 403 still). Verifiziert 6/6, gepusht. | 2026-09-14 | 759ea3b,63f9df0,70d007b | [260914-ebg-windows-29-schliessen-rechteausweitung-a](./quick/260914-ebg-windows-29-schliessen-rechteausweitung-a/) | +| 260914-eym | **Etappe 3c — Systemkontext fuer die Hintergrunddienste.** Migration `20260914120000_rls_system_context_read`: `is_system_context()`, fuenf permissive `system_read_policy ... FOR SELECT` (DkvModuleConfig, LdapConfig, LdapFieldMapping, TenderMatch, TenderSavedSearch); `forSystem(prisma)` in Array-Form mit ausdruecklichem Zuruecksetzen von Mandant/Benutzer, `forTenant()` setzt `app.system_context` zurueck (kein Erben, gemessen). Sechs Faelle: DKV-Planer einmal-abfragen-viele-bedienen (Auftrag je Mandant, WINDOWS #21 fixed); Mail-Transport je Versand aus der SmtpConfig des Empfaenger-Mandanten mit unveraenderter Umgebungs-Rueckfallkette, Startpfad und Mailer-Fabrik entfallen (WINDOWS #30 fixed, SmtpConfig ohne Systemregel); ldap `getAllActiveConfigs()` und Boot-Nachverschluesselung lesen ueber Systemkontext, schreiben je Mandant gebunden; tender-digest Kandidaten und tender-matching Suchprofile ueber Systemkontext, Schleifen gebunden; admin-seed nur dokumentiert (Tenant ohne Regel). Detektor mit fuenfter Erkennungsform `forSystem(` und exakter Erlaubnisliste (falsifiziert: Fremddatei 1 rot, Zweitaufruf 2 rot). Werkzeug 203 -> 253 (`runSystemContextChecks`: ungebunden 0 / System beide Mandanten / Schreiben abgewiesen 42501 bzw. count 0 / kein Erben / pg_policies 34, 5x SELECT). Rueckbau (a) 5 rot mit gelungenem Insert, (b) 1 rot, (c1) 253 gruen + (c2) 5 rot, (d) 2/3 rot. Tests 1028 -> 1054 / 62 -> 64 Dateien, tsc 0, 29 Dateien gegen 5e0e408, Schalter AUS (Compose/.env/Schema/Lockfile unveraendert). Klassifikation 61/179/5, 72 Paare, sechs Zeilen `system-gebunden`; Kritikschrift (y1)-(y5); Auftrag 3c Erledigt. Ledger 15 offen / 1 zurueckgestellt / 21 geschlossen / 37 gesamt; NEU #37 (prozessweiter Single-Flight-Riegel `processInbox`). Verifiziert 9/9, gepusht. | 2026-09-14 | 3d64567,6e2a641,939c812 | [260914-eym-mandantentrennung-etappe-3c-systemkontex](./quick/260914-eym-mandantentrennung-etappe-3c-systemkontex/) | ## Deferred Items @@ -438,8 +441,8 @@ sind. Kein Anlass, sie vorher erneut vorzulegen. ## Session Continuity -Last session: 2026-09-14T08:41:09.727Z +Last session: 2026-09-14T09:56:00.526Z Resumed: 2026-09-14 — Sitzung ueber /gsd-resume-work fortgesetzt; HANDOFF.json und .continue-here.md verbraucht und entfernt. Entscheidung des Users: WINDOWS #29 VOR Etappe 3c (Live-Gehen am 2026-09-15), danach 3c, dann 3a, Etappe 4 nur nach Rueckfrage. -Stopped at: Quick 260914-ebg abgeschlossen: WINDOWS #29 geschlossen — Zielrollen-Riegel in UserController.update/remove, 16 Spec-Tests, Falsifizierung bestanden, gepusht +Stopped at: Quick 260914-eym abgeschlossen: Etappe 3c Systemkontext — forSystem(), is_system_context(), fuenf system_read_policy, DKV je Mandant, Mail je Versand, WINDOWS #21/#30 fixed, #37 neu; 3 Commits gepusht Resume file: None -Last activity: 2026-09-14 - Completed quick task 260914-ebg: WINDOWS #29 geschlossen, Zielrollen-Riegel in UserController.update/remove +Last activity: 2026-09-14 - Completed quick task 260914-eym: Etappe 3c Systemkontext fuer die Hintergrunddienste, WINDOWS #21/#30 geschlossen diff --git a/.planning/quick/260914-eym-mandantentrennung-etappe-3c-systemkontex/260914-eym-SUMMARY.md b/.planning/quick/260914-eym-mandantentrennung-etappe-3c-systemkontex/260914-eym-SUMMARY.md new file mode 100644 index 0000000..eb6ccee --- /dev/null +++ b/.planning/quick/260914-eym-mandantentrennung-etappe-3c-systemkontex/260914-eym-SUMMARY.md @@ -0,0 +1,275 @@ +--- +phase: quick-260914-eym +plan: 01 +subsystem: mandantentrennung +tags: [rls, systemkontext, forSystem, dkv, mail, ldap, tenders, windows-21, windows-30] +status: complete +requires: [quick-260911-nke] +provides: [forSystem, is_system_context, system_read_policy, dkv-auftrag-je-mandant, mail-transport-je-versand] +affects: [etappe-4] +tech-stack: + added: [] + patterns: [Systemkontext-Schwesterhelfer forSystem(prisma), FOR-SELECT-Systemleseregel, Erlaubnisliste mit exakter Zahl je Datei, Transport je Versand nach Mandant] +key-files: + created: + - apps/api/prisma/migrations/20260914120000_rls_system_context_read/migration.sql + - apps/api/src/dkv/dkv-scheduler.service.spec.ts + - apps/api/src/mail/mail.service.spec.ts + modified: + - apps/api/src/prisma/prisma-tenant.extension.ts + - apps/api/src/prisma/prisma-tenant.extension.spec.ts + - apps/api/src/prisma/rls-access-inventory.spec.ts + - apps/api/src/groups/migration-sql.spec.ts + - apps/api/scripts/rls-scratch-check.mjs + - apps/api/src/dkv/dkv.service.ts + - apps/api/src/dkv/dkv.service.spec.ts + - apps/api/src/dkv/dkv-scheduler.service.ts + - apps/api/src/dkv/dkv.controller.ts + - apps/api/src/mail/mail.module.ts + - apps/api/src/mail/mail.service.ts + - apps/api/src/settings/settings.service.ts + - apps/api/src/settings/settings.service.spec.ts + - apps/api/src/auth/auth.service.ts + - apps/api/src/auth/auth.service.spec.ts + - apps/api/src/ldap/ldap-config.service.ts + - apps/api/src/ldap/ldap-config.service.spec.ts + - apps/api/src/tenders/tender-digest.scheduler.ts + - apps/api/src/tenders/tender-digest.scheduler.spec.ts + - apps/api/src/tenders/tender-matching.service.ts + - apps/api/src/tenders/tender-matching.service.spec.ts + - apps/api/src/tenders/tender-notifications.integration.spec.ts + - docs/mandantentrennung-zugriffsklassifikation.md + - docs/mandantentrennung-etappe2-fehlerrichtung.md + - docs/mandantentrennung-etappe3-auftrag.md + - docs/mandantentrennung-datenbankrolle.md + - .planning/WINDOWS.md +decisions: + - "forSystem(prisma) als Schwesterhelfer statt viertem Parameter — eigene Zugriffsklasse, eigene Erkennungsform im Detektor (Umkehrung der 3b-Begruendung)" + - "system_read_policy FOR SELECT auf genau fuenf Tabellen; SmtpConfig bekommt keine, weil der Mail-Startpfad entfernt statt umgestellt wurde" + - "DKV-Planer: Auftrag je Mandant (promote, nicht add-alongside) — Einzahl-Feld activeTenantId ersatzlos entfernt" + - "Mail: Transport je Versand nach Mandant des Empfaengers; Umgebungs-Kette nur Rueckfall fuer Mandanten ohne SmtpConfig" + - "admin-seed nur dokumentiert (liest ausserhalb der Schleife nur Tenant, keine Regel) — Datei unveraendert" + - "Single-Flight-Riegel processInbox bleibt prozessweit — WINDOWS #37 statt Umbau (Auftrag: Tick unangetastet)" +metrics: + duration: "1 Sitzung (2026-09-14, ca. 11:10-12:05)" + completed: 2026-09-14 +actuals: + tokens: 58868 + tasks: 3 + commits: 3 +plan_head_before: 02016e19ebdbdf703465fa55baa945bf71f0b334 +--- + +# Quick 260914-eym: Mandantentrennung Etappe 3c — Systemkontext fuer die Hintergrunddienste — Summary + +Benannter Systemkontext `forSystem(prisma)` mit `is_system_context()` und je einer nur lesenden `system_read_policy FOR SELECT` auf fuenf Tabellen; alle sechs Hintergrunddienst-Faelle behandelt (DKV-Planer je Mandant, Mail-Transport je Versand mit entferntem Startpfad, ldap/digest/matching ueber den Systemkontext, admin-seed dokumentiert); Detektor mit fuenfter Erkennungsform und falsifizierbarer Erlaubnisliste; Werkzeug 203 -> 253; WINDOWS #21 und #30 geschlossen, #37 neu. Der Schalter bleibt AUS. + +## Commits + +``` +939c812 docs(quick-260914-eym): Etappe 3c abgeschlossen — Kritikschrift, Klassifikation, Auftrag, Datenbankrolle, WINDOWS #21/#30 geschlossen, Single-Flight-Riegel als Eintrag +6e2a641 feat(quick-260914-eym): Mail-Transport je Versand nach Mandant (WINDOWS #30), ldap/digest/matching ueber Systemkontext, vier Tabellen im Werkzeug, Erlaubnisliste vollstaendig +3d64567 feat(quick-260914-eym): forSystem(), is_system_context(), Systemleseregel auf fuenf Tabellen, DKV-Planer je Mandant — ein Pfad (WINDOWS #21) +``` + +`git log --oneline 02016e1..HEAD` (oben, drei Commits). `git rev-list --count 02016e1..HEAD` = 3. Gepusht: `git push` -> `5e0e408..939c812 main -> main`; `git fetch -q && git status -sb | head -1` -> `## main...origin/main`; `git rev-parse HEAD` == `git rev-parse origin/main`. + +`git status --porcelain` vor dem Schreiben dieser SUMMARY: leer (keine Ausgabe). + +Hinweis zum Branch: das Projekt committet seit jeher direkt auf `main` (alle Quick-Tasks, Plan-Gate `HEAD == origin/main`, Auftrag "plain `git push`") — dem Projekt-Workflow gefolgt; `git.allow_default_branch_commits` ist in `.planning/config.json` nicht gesetzt. + +## Gemessene Zahlen (beobachtet, nicht abgeschrieben) + +| Messpunkt | Baseline (HEAD 5e0e408/02016e1) | nach Aufgabe 1 (3d64567) | nach Aufgabe 2 (6e2a641) | Ende (939c812) | +|---|---|---|---|---| +| `npm --prefix apps/api run test` — Test Files | 62 | 63 | 64 | 64 | +| Tests | 1028 | 1051 | 1054 | 1054 | +| `npm --prefix apps/api run type-check` Exit | 0 | 0 | 0 | 0 | +| `rls-scratch-check.mjs` Schlusszeile | Alle 203 Pruefungen bestanden. | Alle 216 Pruefungen bestanden. | Alle 253 Pruefungen bestanden. | 253 (kein apps-Diff seit Aufgabe 2, Gate `git diff --stat HEAD~1 -- apps` leer) | +| `prisma migrate status` | 35 Migrationen, up to date | 36 Migrationen, up to date | 36 | 36 | +| `pg_proc` `is_system_context` | 0 | 1 | 1 | 1 | +| `pg_policies` public gesamt / `system_read_policy` | 29 / 0 | 34 / 5 | 34 / 5 | 34 / 5 | +| `git diff --stat 5e0e408 -- . ':!.planning'` Dateien | — | — | — | 29 (`29 files changed, 2499 insertions(+), 491 deletions(-)`) | +| Ledger (aus Zeilen gezaehlt) | open 16 / waived 1 / fixed 19 / total 36 | — | — | open 15 / waived 1 / fixed 21 / total 37 (Frontmatter identisch) | + +Plan-Erwartung vs. beobachtet: Tests erwartet >= 1040 / >= 1044, beobachtet 1051 / 1054; Werkzeug erwartet >= 216 / >= 250 (abgeleitet 216 / 253), beobachtet exakt 216 / 253; Uebersichtstabelle erwartet 61/179/5 (tenders 33/27/2, ldap 1/27/2, dkv 0/22/1, settings 0/3/0), mit der Gate-Schleife nachgerechnet: identisch. + +Umgebung: Container `tessera-ctl-db-1` lief beim Einstieg bereits (`Up 25 minutes (healthy)`, vom Planer gestartet); IP per `docker inspect` 172.19.0.2; DB-Zugang `tessera:tessera_dev`; Prisma-Binary `apps/api/node_modules/.bin/prisma`. Schalter-Gate: `git diff --name-only 5e0e408` nennt keine Compose-, `.env`-, `schema.prisma`-, `package.json`-, Lockfile-, `rls-preflight.mjs`- oder `admin-seed.service.ts`-Datei (in jedem der drei Gates geprueft). + +## [BLOCKING] Migration lokal angewendet — woertliche Ausgabe + +`cd apps/api && DATABASE_URL="postgresql://tessera:tessera_dev@172.19.0.2:5432/tessera" ./node_modules/.bin/prisma migrate deploy`: + +``` +The following migration(s) have been applied: + +migrations/ + └─ 20260914120000_rls_system_context_read/ + └─ migration.sql + +All migrations have been successfully applied. +``` + +`migrate status`: `36 migrations found in prisma/migrations` / `Database schema is up to date!` + +`pg_proc` / `pg_policies` (Tabelle#Regelname#Befehl#PERMISSIV#USING#WITH CHECK): + +``` +pg_proc is_system_context = 1 +DkvModuleConfig#system_read_policy#SELECT#PERMISSIVE#is_system_context()# +DkvModuleConfig#tenant_isolation_policy#ALL#PERMISSIVE#("tenantId" = current_tenant_id())# +LdapConfig#system_read_policy#SELECT#PERMISSIVE#is_system_context()# +LdapConfig#tenant_isolation_policy#ALL#PERMISSIVE#("tenantId" = current_tenant_id())# +LdapFieldMapping#system_read_policy#SELECT#PERMISSIVE#is_system_context()# +LdapFieldMapping#tenant_isolation_policy#ALL#PERMISSIVE#("ldapConfigId" IN ( SELECT "LdapConfig".id FROM "LdapConfig" WHERE ("LdapConfig"."tenantId" = current_tenant_id())))# +SmtpConfig#tenant_isolation_policy#ALL#PERMISSIVE#("tenantId" = current_tenant_id())# +TenderMatch#system_read_policy#SELECT#PERMISSIVE#is_system_context()# +TenderMatch#tenant_isolation_policy#ALL#PERMISSIVE#("tenantId" = current_tenant_id())# +TenderSavedSearch#system_read_policy#SELECT#PERMISSIVE#is_system_context()# +TenderSavedSearch#tenant_isolation_policy#ALL#PERMISSIVE#(("tenantId" = current_tenant_id()) AND ((current_user_id() IS NULL) OR ("userId" = current_user_id())))# +system_read_policy gesamt = 5 +policies public gesamt = 34 +``` + +## Werkzeug — die vier Funktionsfaelle (woertlich, Lauf nach Aufgabe 2) + +``` +is-system-context-ungesetzt-false: bestanden — ohne gesetzte Variable: is_system_context() = false (Rohwert null) — die Vorher-Pruefung ohne-kontext-leer in rls-preflight.mjs bleibt gueltig +is-system-context-leer-false: bestanden — nach set_config('app.system_context', '', true): false +is-system-context-true-true: bestanden — nach set_config('app.system_context', 'true', true): true +is-system-context-fremdwert-false: bestanden — nach set_config('app.system_context', 'yes', true): false +``` + +Je Tabelle (dkvmoduleconfig, ldapconfig, ldapfieldmapping, tendermatch, tendersavedsearch) neun Kennungen gruen, plus `ldapconfig-systemkontext-include-fieldmappings-beider-mandanten: bestanden — ... liefert 2 Zeile(n): ["TENANT-A:1","TENANT-B:1"]`. Die vollstaendigen Zeilen stehen in `docs/mandantentrennung-etappe2-fehlerrichtung.md`, Abschnitt (y1). + +## Falsifizierung durch Rueckbau — woertliche Ausgaben + +Jeder Rueckbau wurde ausgefuehrt, das rote Ergebnis protokolliert, die Datei restauriert (`git checkout -- ` fuer committete Dateien; fuer die in Aufgabe 2 noch uncommitteten Dateien Werkzeug/Detektor per Kopie mit identischem SHA-256-Praefix `a1f845ba787cac52` bzw. `d9595ef09df57fce`) und der gruene Zustand erneut gemessen (Werkzeug 253, Detektor 30/30, `git status --short` danach nur die gewollten Aufgabe-2-Dateien). + +**(a) `FOR SELECT` bei `"TenderMatch"` in der Migrationsdatei entfernt** (Regel wird ALL): + +``` +tendermatch-systemkontext-insert-abgewiesen-42501: FEHLGESCHLAGEN — system.tenderMatch.create({"id":"tm-system-schreibversuch","tenderId":"tender-2","savedSearchId":"ss-a","userId":"user-a","tenantId":"TENANT-A"}) ist NICHT fehlgeschlagen — angelegt: "tm-system-schreibversuch" +tendermatch-systemkontext-updatemany-count-0: FEHLGESCHLAGEN — system.tenderMatch.updateMany({ where: {}, data: {"notifiedChannel":"SYSTEM-SCHREIBVERSUCH"} }) liefert count=3 +tendermatch-systemkontext-deletemany-count-0: FEHLGESCHLAGEN — system.tenderMatch.deleteMany({}) liefert count=3; Zeilen danach (Wartungsrolle): 0 +tendermatch-fortenant-a-nach-systemkontext-nur-a: FEHLGESCHLAGEN — bound(TENANT-A).tenderMatch.findMany() unmittelbar nach system.findMany() auf demselben Client liefert 0 Zeile(n) aus [] +tendermatch-pg-policies-genau-eine-system-read-policy-select: FEHLGESCHLAGEN — pg_policies fuer "TenderMatch" (system_read_policy): [{"policyname":"system_read_policy","cmd":"ALL","permissive":"PERMISSIVE","qual":"is_system_context()"}] +5 von 253 Pruefungen fehlgeschlagen. +``` + +Plan erwartete: `…-insert-abgewiesen-42501` rot. Beobachtet: 5 rot — der Insert gelingt, danach auch updateMany/deleteMany (count 3, Zeilen 0), deshalb liefert der Folgeschritt `…-nur-a` 0 Zeilen, und `pg_policies` zeigt `ALL`. Die Kernaussage (Insert GELINGT ohne `FOR SELECT`) ist woertlich belegt. + +**(b) `system_read_policy` fuer `"TenderSavedSearch"` aus der Migrationsdatei entfernt:** + +``` +tendersavedsearch-system-read-policy-aus-migration-gefunden: FEHLGESCHLAGEN — CREATE POLICY system_read_policy ON "TenderSavedSearch" nicht in der Systemkontext-Migration (20260914120000) gefunden +1 von 245 Pruefungen fehlgeschlagen. +``` + +Lebende Datenbank waehrend des Rueckbaus (per `pg_policies`): `policies public gesamt = 34 | system_read_policy auf TenderSavedSearch = 1`. Plan erwartete: `…-sieht-beide-mandanten` und `…-pg-policies-genau-eine-…` rot. Beobachtet: die innere Routine bricht fuer diese Tabelle mit einer eigenen roten Extraktions-Kennung ab (Muster `runSingleRulePersonalTableCheck`: nicht raten, wenn die Regel in der Migration fehlt), die neun Kennungen der Tabelle laufen nicht (253 -> 245). Die Aussage des Plans — das Werkzeug misst die geschnittene Regel, nicht die lebende Datenbank, und die Datenbank bleibt bei 34 — ist belegt; die Form des Rotwerdens ist strenger als erwartet, nicht lockerer. Beide Zahlen (erwartet 2 rote Kennungen von 253; beobachtet 1 rote von 245) stehen hier und in (y2). + +**(c) `local=false` in `forSystemQuery`/`buildInlineSystemClient` (Werkzeug):** `Alle 253 Pruefungen bestanden.` — alle fuenf `…-fortenant-a-nach-systemkontext-nur-a` bleiben gruen, der Reset in `buildInlineExtendedClient` traegt. **Zusaetzlich den Reset dort entfernt:** + +``` +dkvmoduleconfig-fortenant-a-nach-systemkontext-nur-a: FEHLGESCHLAGEN — bound(TENANT-A).dkvModuleConfig.findMany() unmittelbar nach system.findMany() auf demselben Client liefert 2 Zeile(n) aus ["TENANT-A","TENANT-B"] +ldapconfig-fortenant-a-nach-systemkontext-nur-a: FEHLGESCHLAGEN — bound(TENANT-A).ldapConfig.findMany() unmittelbar nach system.findMany() auf demselben Client liefert 2 Zeile(n) aus ["TENANT-A","TENANT-B"] +ldapfieldmapping-fortenant-a-nach-systemkontext-nur-a: FEHLGESCHLAGEN — bound(TENANT-A).ldapFieldMapping.findMany() unmittelbar nach system.findMany() auf demselben Client liefert 2 Zeile(n) aus ["TENANT-A","TENANT-B"] +tendermatch-fortenant-a-nach-systemkontext-nur-a: FEHLGESCHLAGEN — bound(TENANT-A).tenderMatch.findMany() unmittelbar nach system.findMany() auf demselben Client liefert 2 Zeile(n) aus ["TENANT-A","TENANT-B"] +tendersavedsearch-fortenant-a-nach-systemkontext-nur-a: FEHLGESCHLAGEN — bound(TENANT-A).tenderSavedSearch.findMany() unmittelbar nach system.findMany() auf demselben Client liefert 2 Zeile(n) aus ["TENANT-A","TENANT-B"] +5 von 253 Pruefungen fehlgeschlagen. +``` + +(`…-is-system-context-unter-fortenant-false` blieb gruen, weil diese Kennung ihre Transaktion mit eigenem Reset-Literal baut, nicht ueber `buildInlineExtendedClient`.) + +**(d) Detektor — Zahl fuer `tender-matching.service.ts` auf 0:** + +``` +AssertionError: apps/api/src/tenders/tender-matching.service.ts: gemessen 1 forSystem(-Aufruf(e), erlaubt sind genau 0: expected [ Array(1) ] to deeply equal [] +AssertionError: apps/api/src/tenders/tender-matching.service.ts: Erlaubnisliste nennt 0, gemessen 1 — der Eintrag ist ueberholt: expected [ Array(1) ] to deeply equal [] +Tests 2 failed | 28 passed (30) +``` + +**Fremddatei `admin-seed.service.ts` voruebergehend mit `forSystem(` versehen:** + +``` +AssertionError: apps/api/src/user/admin-seed.service.ts: 2 forSystem(-Aufruf(e), Datei steht NICHT in FORSYSTEM_ALLOWED_CALL_SITES — ein Anfrageweg darf den Systemkontext nie rufen: expected [ Array(1) ] to deeply equal [] +AssertionError: apps/api/src/user/admin-seed.service.ts: 1 forSystem(-Aufruf(e) ausserhalb der Zuweisungsform: expected [ Array(1) ] to deeply equal [] +AssertionError: apps/api/src/user/admin-seed.service.ts: 1 include:/select:/_count:-Angabe(n) ausserhalb eines erkannten Modellaufrufs: expected [ Array(1) ] to deeply equal [] +Tests 3 failed | 27 passed (30) +``` + +Danach `git checkout -- apps/api/src/user/admin-seed.service.ts`, `git diff --quiet 5e0e408 -- apps/api/src/user/admin-seed.service.ts` -> unveraendert. + +Ausserdem ein nicht geplanter Beleg fuer den Veraltet-Wachhund: in Aufgabe 1 war die Erlaubnisliste bereits mit `dkv.service.ts: 1` gefuellt, bevor `dkv.service.ts` umgestellt war — die Spec wurde rot (`Erlaubnisliste nennt 1, gemessen 0 — der Eintrag ist ueberholt`) und erst mit der Umstellung gruen. + +## Identitaet mit einem Mandanten (morgen alpha, BYPASSRLS) — je Pfad als Test + +- dkv (`dkv-scheduler.service.spec.ts`, 7 Tests): ein aktiver Mandant, pollIntervalMin 15 -> genau ein Auftrag `dkv-inbox-poll:t1`, `cronTime.source === '*/15 * * * *'`, `isActive` true; 120 -> `0 */2 * * *`; `fireOnTick()` ruft `processInbox('t1')` genau einmal; inaktive/keine Config -> kein Auftrag, Protokollzeile `DKV scheduler: no active config found — cron job not registered`; zwei Mandanten -> zwei Auftraege, `setInterval(30,'t2')` laesst das t1-Objekt identisch, `stopJob('t1')` entfernt nur t1; werfender Startpfad -> `DKV scheduler init failed: db down`, kein Auftrag; `stopJob` unbekannt -> No-Op. +- mail (`mail.service.spec.ts`, 4 Tests): Mandant MIT SmtpConfig -> `getDecryptedSmtpConfig('t1')` genau einmal, `createTransport({host:'smtp-a.example.invalid',port:465,secure:true,requireTLS:false,auth:{user:'user-a',pass:'geheim-a'}})`, `from` = `noreply@a.example.invalid`, `close()` einmal; ohne SmtpConfig -> MAIL_* vor TESSERA_SMTP_* vor `localhost:1025`, `from` aus TESSERA_SMTP_FROM bzw. `Tessera `; zwei Mandanten -> zwei Transporte, keiner enthaelt das Kennwort des anderen; `sendMail` wirft -> kein Throw, Protokoll ohne Kennwort, `close()` trotzdem. +- ldap/digest/matching: bestehende Verhaltenstests unveraendert gruen (ldap 92, tenders 413 Tests in den Bereichen), plus je eine Zusicherung `forSystem` genau einmal und `forTenant` genauso oft wie bisher (ldap: `getAllActiveConfigs` forSystem 1 / forTenant 0; Bootstrap leer: forSystem 1 / forTenant 0; Bootstrap mit Altzeile t1: forTenant genau einmal mit `t1`, `update` traegt `aa11:bb22:`; digest: `__systemCallLog` genau `[tenderMatch.findMany]`, forTenant weiter genau einmal; matching: `__systemCallLog` genau `[tenderSavedSearch.findMany]`, `tender.findMany` weiter auf dem rohen Client). + +## Deviations from Plan + +### Auto-fixed Issues + +**1. [Rule 3 - Blocking] Gate-Zaehlung `const systemPrisma = forSystem(this.prisma)` traf die Proben der Detektor-Spec** +- **Found during:** Aufgabe 2, Gate-Lauf +- **Issue:** Das Gate zaehlt `grep -rh … | grep -v spec` — `-h` laesst den Dateinamen weg, `spec` steht nicht im Zeilentext, deshalb zaehlten die drei Proben C/D1/D2 mit (8 statt 5). Der Plan verlangt die Probe C mit genau diesem Text UND das Gate mit genau 5 — in sich widerspruechlich. +- **Fix:** Empfaengername in den drei Proben auf `sysPrisma` geaendert (Regex des Detektors ist `const\s+(\w+)\s*=\s*forSystem\(` — die Probe prueft weiterhin dieselbe Form und belegt zusaetzlich, dass der Name nicht hartkodiert ist); Gate unveraendert, Zahl unveraendert (5). +- **Files modified:** `apps/api/src/prisma/rls-access-inventory.spec.ts` +- **Commit:** 6e2a641. Als Falle in `docs/mandantentrennung-etappe3-auftrag.md` ("Werkzeuge und Fallen") eingetragen. + +**2. [Rule 3 - Blocking] Kopfkommentar `dkv-scheduler.service.ts` nannte `forSystem()` als Text** +- **Found during:** Aufgabe 2, Gate `test 4 -eq ` +- **Issue:** Das Gate zaehlt Dateien mit dem Text `forSystem(` auch in Kommentaren; der in Aufgabe 1 geschriebene Kopfkommentar nannte den Helfer. +- **Fix:** Kommentar umformuliert ("systemgebunden ueber den Systemkontext-Helfer"). Datei steht in `files_modified` des Plans (Aufgabe-1-Liste), Aenderung im Aufgabe-2-Commit. +- **Files modified:** `apps/api/src/dkv/dkv-scheduler.service.ts` +- **Commit:** 6e2a641 + +**3. [Rule 3 - Blocking] Spec-Kopfkommentar nannte den geloeschten Methodennamen** +- **Found during:** Aufgabe 2 (eigener Assert vor dem Gate) +- **Issue:** Das Gate verlangt null Treffer `loadAnySmtpConfigForStartupTransport` in vier Dateien, auch in Kommentaren; mein erster Entwurf des Spec-Kopfkommentars nannte ihn. +- **Fix:** Umschrieben ("der ungebundene Startpfad des Mailmoduls"). +- **Files modified:** `apps/api/src/settings/settings.service.spec.ts` +- **Commit:** 6e2a641 + +**4. [Rule 1 - Bug] `pg_policies`-Form in (y1)** +- **Found during:** Aufgabe 3, Gate +- **Issue:** Ich hatte die Zeilen mit sechs Spalten (inkl. PERMISSIV) geschrieben; das Gate erwartet die 3b-Form `Tabelle#Regelname#Befehl#USING#WITH CHECK`. +- **Fix:** Zeilen auf die 3b-Form gebracht (die PERMISSIV-Eigenschaft steht im Satz davor). +- **Files modified:** `docs/mandantentrennung-etappe2-fehlerrichtung.md` +- **Commit:** 939c812 + +### Abweichungen zum Auftrag (bewusst, im Plan so vorgesehen) + +- **Fuenf statt sechs Tabellen:** SmtpConfig traegt keine `system_read_policy`, weil der Mail-Startpfad ENTFERNT wurde (Transport je Versand nach Mandant des Empfaengers), nicht auf den Systemkontext umgestellt. +- **ldap hat ZWEI Systemkontext-Leser:** `getAllActiveConfigs()` und die Nachverschluesselung in `onApplicationBootstrap()` (je eigene Zuweisung, der Detektor zaehlt 2); die Schreibzeile je Altzeile laeuft ueber `forTenant(this.prisma, config.tenantId)`. +- **Mail-Startpfad entfernt statt umgestellt:** `MailerModule.forRootAsync` und `loadAnySmtpConfigForStartupTransport()` samt vier Spec-Tests geloescht; `@nestjs-modules/mailer` bleibt in `package.json`/Lockfile installiert, ist aber unbenutzt (kein Lockfile-Eingriff in diesem Durchlauf). +- **Container:** musste NICHT gestartet werden — er lief beim Einstieg bereits (vom Planer gestartet, `Up 25 minutes (healthy)`). +- **Rueckbau (b):** rot in strengerer Form als im Plan beschrieben (Extraktions-Abbruch statt zwei rote Messkennungen), siehe oben. +- **Doppelte Kennung im Werkzeug:** `dkvmoduleconfig-ungebunden-null-zeilen` gibt es jetzt zweimal (einmal aus `runDkvAreaChecks`, einmal aus dem neuen Abschnitt) — der Plan schreibt den Namen vor; beide gruen, das Gate greift per `^…: bestanden`. + +## Was bewusst offen bleibt + +- **WINDOWS #37 (neu, open):** Der Single-Flight-Riegel `processing` in `DkvService.processInbox` ist EIN prozessweites Boolean. Seit je aktivem Mandanten ein eigener Cron-Auftrag laeuft, bricht bei Ueberschneidung zweier Ticks verschiedener Mandanten der zweite still ab (Warnzeile `already processing`) und wartet bis zum naechsten Intervall — kein Datenverlust, Verzoegerung; mit einem Mandanten unveraendert (T-EYM-09, accept mit Aufzeichnung). Loesungsweg: Riegel je Mandant (`Set`) mit Test "zwei Mandanten gleichzeitig, beide werden bedient". +- `sendWelcomeEmail` hat weiterhin null Aufrufer; `@nestjs-modules/mailer` unbenutzt in `package.json` — Aufraeumen, kein Defekt. +- Digest-Sonderfall "Nutzer mit Treffern unter zwei Mandanten" (`distinct: ['userId']`) bleibt wie in (t4) beschrieben. +- `rls-preflight.mjs` bekommt in Etappe 4 die Pruefung `mit-systemkontext-sichtbar`; `ohne-kontext-leer` bleibt gueltig (Beleg `is-system-context-ungesetzt-false`, Rohwert `null` -> `false`). +- Etappe 3a (Anmeldenamen pro Mandant) und Etappe 4 (Scharfschalten) — unveraendert offen. + +## Was ohne den User nicht geht + +Nichts Neues. Wie im Auftrag: 3a Weg (i) vs. (ii) (wie der Mandant beim Login bestimmt wird) und Etappe 4 (Scharfschalten, `DATABASE_URL` auf `tessera_app`) bleiben Rueckfragen. Dieser Durchlauf hat den Schalter nicht angefasst: keine Compose-Datei, keine `.env`, nichts auf einem Server, nichts in Active Directory. + +## Threat Flags + +Keine neue Angriffsflaeche ausserhalb des `` des Plans: kein neuer Netzwerk-Endpunkt, kein neuer Auth-Pfad, keine Schemaaenderung an Vertrauensgrenzen (nur zusaetzliche, nur lesende Regeln plus eine Funktion ohne SECURITY DEFINER). T-EYM-01 bis T-EYM-08 mitigiert wie geplant (Belege oben), T-EYM-09 accept mit Ledger-Eintrag #37, T-EYM-SC: keine Paketinstallation, `package.json`/Lockfile unveraendert gegen 5e0e408. + +## Known Stubs + +Keine. `sendWelcomeEmail` ist kein Stub (vollstaendig implementiert, nur ohne Aufrufer — seit vor diesem Durchlauf). + +## Self-Check: PASSED + +- Dateien: `apps/api/prisma/migrations/20260914120000_rls_system_context_read/migration.sql`, `apps/api/src/dkv/dkv-scheduler.service.spec.ts`, `apps/api/src/mail/mail.service.spec.ts` — FOUND (im Commit-Baum, `git diff --stat 5e0e408` nennt 29 Dateien). +- Commits 3d64567, 6e2a641, 939c812 — FOUND (`git log --oneline 02016e1..HEAD`), gepusht (`HEAD == origin/main`). diff --git a/.planning/quick/260914-eym-mandantentrennung-etappe-3c-systemkontex/260914-eym-VERIFICATION.md b/.planning/quick/260914-eym-mandantentrennung-etappe-3c-systemkontex/260914-eym-VERIFICATION.md new file mode 100644 index 0000000..6a71a33 --- /dev/null +++ b/.planning/quick/260914-eym-mandantentrennung-etappe-3c-systemkontex/260914-eym-VERIFICATION.md @@ -0,0 +1,199 @@ +--- +phase: quick-260914-eym +verified: 2026-09-14T12:40:00Z +status: passed +score: 9/9 must-haves verified +covered_files: + - .planning/WINDOWS.md + - .planning/quick/260914-eym-mandantentrennung-etappe-3c-systemkontex/260914-eym-PLAN.md + - .planning/quick/260914-eym-mandantentrennung-etappe-3c-systemkontex/260914-eym-SUMMARY.md + - apps/api/prisma/migrations/20260914120000_rls_system_context_read/migration.sql + - apps/api/scripts/rls-scratch-check.mjs + - apps/api/src/auth/auth.service.spec.ts + - apps/api/src/auth/auth.service.ts + - apps/api/src/dkv/dkv-scheduler.service.spec.ts + - apps/api/src/dkv/dkv-scheduler.service.ts + - apps/api/src/dkv/dkv.controller.ts + - apps/api/src/dkv/dkv.service.spec.ts + - apps/api/src/dkv/dkv.service.ts + - apps/api/src/groups/migration-sql.spec.ts + - apps/api/src/ldap/ldap-config.service.spec.ts + - apps/api/src/ldap/ldap-config.service.ts + - apps/api/src/mail/mail.module.ts + - apps/api/src/mail/mail.service.spec.ts + - apps/api/src/mail/mail.service.ts + - apps/api/src/prisma/prisma-tenant.extension.spec.ts + - apps/api/src/prisma/prisma-tenant.extension.ts + - apps/api/src/prisma/rls-access-inventory.spec.ts + - apps/api/src/settings/settings.service.spec.ts + - apps/api/src/settings/settings.service.ts + - apps/api/src/tenders/tender-digest.scheduler.spec.ts + - apps/api/src/tenders/tender-digest.scheduler.ts + - apps/api/src/tenders/tender-matching.service.spec.ts + - apps/api/src/tenders/tender-matching.service.ts + - apps/api/src/tenders/tender-notifications.integration.spec.ts + - docs/mandantentrennung-datenbankrolle.md + - docs/mandantentrennung-etappe2-fehlerrichtung.md + - docs/mandantentrennung-etappe3-auftrag.md + - docs/mandantentrennung-zugriffsklassifikation.md +covered_digest: "v1:sha256:d81ca7fd6f1c5dd2e90f4b70f943467888d52417316824523b993980e9607e0e" +behavior_unverified: 0 +overrides_applied: 0 +--- + +# Quick 260914-eym: Mandantentrennung Etappe 3c — Systemkontext fuer die Hintergrunddienste — Verifikation + +**Ziel:** Benannter Systemkontext `forSystem()` fuer die Hintergrunddienste: dritte Sitzungsvariable `app.system_context`, Funktion `is_system_context()`, neue Migration `20260914120000_rls_system_context_read` mit fuenf permissiven `system_read_policy ... FOR SELECT` (bestehende Migrationen unveraendert), Detektor mit fuenfter Erkennungsform und exakter Erlaubnisliste, Werkzeugabschnitt `runSystemContextChecks`, die sechs Faelle behandelt, Dokumente nachgezogen, Ledger #21/#30 fixed, #37 neu, gepusht. Der Schalter bleibt AUS. +**Verifiziert:** 2026-09-14, ca. 12:10-12:40 (HEAD 939c812, Arbeitsbaum nur mit den Orchestrator-Aenderungen `.planning/STATE.md` und der neuen SUMMARY) +**Status:** passed +**Erneute Verifikation:** Nein — Erstverifikation + +Grundhaltung: Die SUMMARY wurde nicht als Beleg genommen. Jede Zahl unten ist in dieser Sitzung selbst gemessen (Kommando und beobachtetes Ergebnis stehen dabei). Wo ich etwas absichtlich kaputtgemacht habe, um den Wachhund zu pruefen, ist die Restauration mit `git status --porcelain -- apps/` (leer) belegt. + +## 1. Git-Historie, Umfang und Schalter-Gates + +| Pruefung | Kommando | Beobachtet | Status | +|---|---|---|---| +| Drei Commits seit Planstand | `git log --oneline 02016e1..HEAD` / `git rev-list --count 02016e1..HEAD` | `939c812`, `6e2a641`, `3d64567`; count=3 | VERIFIZIERT | +| 29 Dateien ausserhalb `.planning` | `git diff --stat 5e0e408 -- . ':!.planning'` | `29 files changed, 2499 insertions(+), 491 deletions(-)`; 29 Zeilen mit `\|` | VERIFIZIERT | +| Schalter-Gate leer | `git diff --name-only 5e0e408 -- apps/api/prisma/schema.prisma docker-compose.yml docker-compose.prod.yml docker-compose.dev.yml package.json apps/api/package.json pnpm-lock.yaml apps/api/scripts/rls-preflight.mjs apps/api/src/user/admin-seed.service.ts` | keine Ausgabe | VERIFIZIERT | +| Keine Umgebungs-/Compose-Datei im Diff | `git diff --name-only 5e0e408 \| awk 'index($0,"env") \|\| index($0,"compose")'` | keine Ausgabe | VERIFIZIERT | +| Keine bestehende Migration geaendert | `git diff --name-only 5e0e408 -- apps/api/prisma/migrations \| grep -v 20260914120000` | keine Ausgabe | VERIFIZIERT | +| Gepusht | `git fetch -q && git status -sb \| head -1`; `git rev-parse HEAD` / `origin/main` | `## main...origin/main` (kein `[ahead`); beide `939c8121a182fb8ad93b3b7f5b9fdcecc17a3ffd`; Push-URL zeigt auf `localhost:3002` | VERIFIZIERT | +| Arbeitsbaum | `git status --porcelain` | nur ` M .planning/STATE.md` und `?? .../260914-eym-SUMMARY.md` (Orchestrator-Dateien, unangetastet) | VERIFIZIERT | + +## 2. Baseline-Messungen (frisch, nicht aus der SUMMARY) + +| Messpunkt | Kommando | Beobachtet | Erwartung (Plan) | Status | +|---|---|---|---|---| +| API-Testsuite | `cd apps/api && npx vitest run` | `Test Files 64 passed (64)`, `Tests 1054 passed (1054)`, Exit 0 | >= 1044 | VERIFIZIERT | +| Typpruefung | `cd apps/api && npx tsc --noEmit` | Exit 0, keine Ausgabe | Exit 0 | VERIFIZIERT | +| Werkzeug gegen lebende DB (Lauf 1) | `TESSERA_SCRATCH_ADMIN_URL="postgresql://tessera:tessera_dev@172.19.0.2:5432/postgres" node apps/api/scripts/rls-scratch-check.mjs` | `Alle 253 Pruefungen bestanden.`, Exit 0, `FEHLGESCHLAGEN`-Zeilen: 0 | N >= 250 | VERIFIZIERT | +| Werkzeug (Lauf 2, nach allen Rueckbauten und Restaurationen) | dito | `Alle 253 Pruefungen bestanden.`, Exit 0 | 253 | VERIFIZIERT | +| Vier Funktionsfaelle | `grep -E "^is-system-context-" ` | `ungesetzt-false` (Rohwert null), `leer-false`, `true-true`, `fremdwert-false` — alle `bestanden` | vier gruen | VERIFIZIERT | +| Neun Kennungen je Tabelle (5 x 9 = 45) | Schleife ueber dkvmoduleconfig/ldapconfig/ldapfieldmapping/tendermatch/tendersavedsearch x wegwerftabelle-deckt-alle-spalten / ungebunden-null-zeilen / sieht-beide-mandanten / insert-abgewiesen-42501 / updatemany-count-0 / deletemany-count-0 / fortenant-a-nach-systemkontext-nur-a / is-system-context-unter-fortenant-false / pg-policies-genau-eine-system-read-policy-select | keine fehlende, keine rote Kennung | 45 gruen | VERIFIZIERT | +| Relations-Kennung | `grep '^ldapconfig-systemkontext-include-fieldmappings-beider-mandanten'` | `bestanden — ... liefert 2 Zeile(n): ["TENANT-A:1","TENANT-B:1"]` | gruen | VERIFIZIERT | + +## 3. Lebende Datenbank (Container `tessera-ctl-db-1`, IP 172.19.0.2, Rolle `tessera`) + +| Pruefung | Kommando | Beobachtet | Status | +|---|---|---|---| +| Container | `docker ps --filter name=tessera-ctl-db-1` | `Up About an hour (healthy)` | — | +| Migrationsstand | `DATABASE_URL=... ./node_modules/.bin/prisma migrate status` | `36 migrations found`, `Database schema is up to date!` | VERIFIZIERT | +| Funktion vorhanden | `SELECT count(*) FROM pg_proc WHERE proname='is_system_context'` | 1; `provolatile='s'` (STABLE), `prosecdef=false` (kein SECURITY DEFINER) | VERIFIZIERT | +| Systemleseregeln | `SELECT tablename, cmd, permissive, qual, with_check FROM pg_policies WHERE policyname='system_read_policy'` | genau 5 Zeilen: DkvModuleConfig, LdapConfig, LdapFieldMapping, TenderMatch, TenderSavedSearch — je `SELECT` / `PERMISSIVE` / `is_system_context()` / with_check `null` | VERIFIZIERT | +| Gesamtzahl Regeln | `SELECT count(*) FROM pg_policies WHERE schemaname='public'` | 34 | VERIFIZIERT | +| SmtpConfig ohne Systemregel | Regeln der sechs Tabellen gelistet | SmtpConfig nur `tenant_isolation_policy` (ALL); die fuenf anderen je zwei Regeln | VERIFIZIERT | +| Schalter AUS | `SELECT rolname, rolsuper, rolbypassrls FROM pg_roles` | `tessera` super+bypassrls; `tessera_app` weder noch — Anwendung verbindet unveraendert als `tessera` | VERIFIZIERT | +| Nach Rueckbau (a) | `pg_policies` erneut, plus `SELECT datname FROM pg_database WHERE datname LIKE '%scratch%'` | 34 Regeln; TenderMatch: `system_read_policy` SELECT + `tenant_isolation_policy` ALL; keine Wegwerf-DB uebrig | VERIFIZIERT | + +## 4. Beobachtbare Wahrheiten (must_haves.truths) + +| # | Wahrheit | Status | Beleg | +|---|---|---|---| +| 1 | `forSystem(prisma)` in Array-Form-`$transaction`, EINE getaggte Anweisung setzt `app.system_context='true'`, `app.current_tenant=''`, `app.current_user=''`; `forTenant()`/`withTenantTransaction()` setzen `app.system_context=''`; Kein-Erben gemessen und Reset per Rueckbau falsifiziert | VERIFIZIERT | Datei gelesen: `forSystem` baut `$executeRaw\`SELECT set_config('app.system_context', 'true', true), set_config('app.current_tenant', '', true), set_config('app.current_user', '', true)\`` und `$transaction([setContext, query(args)])`; `grep -cF "set_config('app.system_context', '', true)"` = 2 (forTenant + withTenantTransaction). Werkzeug: `-fortenant-a-nach-systemkontext-nur-a` und `-is-system-context-unter-fortenant-false` fuer alle fuenf Tabellen gruen. Rueckbau (c) nicht selbst wiederholt (siehe Angenommene Risiken); Helfer-Spec 15 Tests gruen | +| 2 | Migration mit `is_system_context()` (STABLE, COALESCE) und genau fuenf PERMISSIVE `system_read_policy ... FOR SELECT` auf den fuenf Tabellen, SmtpConfig nicht dabei, bestehende Migrationen unveraendert, Schalter AUS | VERIFIZIERT | Datei gelesen; Zaehlung ohne Kommentarzeilen: `CREATE POLICY system_read_policy`=5, `FOR SELECT`=5, `DROP POLICY`=0, `SmtpConfig`=0. Lebende DB s. Abschnitt 3. `git diff --name-only 5e0e408 -- apps/api/prisma/migrations \| grep -v 20260914120000` leer | +| 3 | Regel erweitert NUR das Lesen: INSERT 42501, updateMany/deleteMany count 0, je Tabelle die neun Kennungen ueber den generierten Client | VERIFIZIERT | 45 Kennungen gruen (Abschnitt 2). Eigener Rueckbau (a): `FOR SELECT` bei TenderMatch entfernt -> `tendermatch-systemkontext-insert-abgewiesen-42501: FEHLGESCHLAGEN — ... ist NICHT fehlgeschlagen — angelegt: "tm-system-schreibversuch"`, dazu updatemany count=3, deletemany count=3, `nur-a` 0 Zeilen, `pg-policies` zeigt `cmd: ALL`; `5 von 253 Pruefungen fehlgeschlagen.` Danach `git checkout -- `, `git status --porcelain -- apps/` leer, Werkzeug wieder 253 | +| 4 | Sechs Faelle behandelt: DKV Auftrag je Mandant; Mail Transport je Versand, Startpfad geloescht; ldap beide Leser ueber forSystem, Schreibzeile forTenant; digest Kandidaten forSystem; matching Suchprofile forSystem, Katalog ungebunden; admin-seed unveraendert | VERIFIZIERT | dkv: `loadActiveConfigsForScheduler()` = `forSystem(this.prisma).dkvModuleConfig.findMany({ where: { isActive: true }, select: CONFIG_SAFE_SELECT, orderBy: { tenantId: 'asc' } })`; Scheduler `jobNameFor` = `dkv-inbox-poll:`, `setInterval(intervalMin, tenantId)`/`stopJob(tenantId)` nur dieser Name, Controller `setInterval(dto.pollIntervalMin, tenantId)` / `stopJob(tenantId)`; `activeTenantId` im Code 0, `loadAnyActiveConfigForScheduler` 0. mail: `mail.module.ts` nur `SettingsModule` + `MailService`; `MailerModule/MailerService` im Code 0; `resolveTransport(tenantId)` -> `getDecryptedSmtpConfig(tenantId)` (gebunden, `findUnique({ where: { tenantId } })`) sonst Env-Kette; `transport?.close()` im finally; `loadAnySmtpConfigForStartupTransport` in vier Dateien 0; `this.prisma.smtpConfig` in settings.service 0; `auth.service.ts:248` `sendPasswordResetEmail(email, token, user.tenantId)`. ldap: Zeile 71 forSystem (Bootstrap, `select id/tenantId/encryptedBindPassword`), Zeile 87/88 `forTenant(this.prisma, config.tenantId)` + `ldapConfig.update` je Altzeile; Zeile 322 forSystem `getAllActiveConfigs` mit `include: { tenant, fieldMappings }`; `this.prisma.ldapConfig` im Code 0. digest: Zeile 124 forSystem `tenderMatch.findMany({ where: { notifiedAt: null }, select: { userId, tenantId }, distinct: ['userId'] })`, Schleife `forTenant(this.prisma, tenantId)`; matching: Zeile 75 forSystem `tenderSavedSearch.findMany()`, Zeile 90 `this.prisma.tender.findMany` (D-03), Zeile 98 `forTenant(this.prisma, search.tenantId)`. admin-seed: `git diff --quiet 5e0e408 -- apps/api/src/user/admin-seed.service.ts` unveraendert | +| 5 | Mit EINEM Mandanten unter BYPASSRLS je Pfad identisch — als Test festgenagelt | VERIFIZIERT (verhaltensabhaengig, durch benannte Tests belegt) | `npx vitest run` der zehn betroffenen Specs: 10 Dateien / 172 Tests gruen. dkv-scheduler.service.spec.ts (7 Tests, ECHTES `cron`): Test 1 `cronTime.source === '*/15 * * * *'`, `isActive` true, genau ein Auftrag `dkv-inbox-poll:t1`; Test 2 `0 */2 * * *`; Test 3 `fireOnTick()` -> `processInbox('t1')`; Test 4 inaktiv/keine -> 0 Auftraege + `no active config found`; Test 5 zwei Mandanten, `setInterval(30,'t2')` laesst t1-Objekt identisch (`toBe(t1JobBefore)`), `stopJob('t1')` nur t1; Test 6 werfender Startpfad; Test 7 stopJob No-Op. mail.service.spec.ts (4 Tests): Test 1 `createTransport({host:'smtp-a.example.invalid',port:465,secure:true,requireTLS:false,auth:{user:'user-a',pass:'geheim-a'}})`, `from` = fromAddress, `close()` einmal, `MAIL_HOST` darf nicht greifen; Test 2 MAIL_* vor TESSERA_SMTP_* vor localhost:1025, `from` aus TESSERA_SMTP_FROM bzw. Vorgabe, TESSERA_SMTP_SECURE; Test 3 zwei Mandanten, kein Kennwort des anderen; Test 4 Throw verschluckt, Protokoll ohne Kennwort, close() trotzdem. Env-Kette feldweise gegen `git show 5e0e408:apps/api/src/mail/mail.module.ts` verglichen: host/port/user/pass/from/secure identisch; SmtpConfig-Zweig bildet `secure = encryption==='ssl-tls'`, `requireTLS = encryption==='starttls'` exakt wie die geloeschte `loadAnySmtpConfigForStartupTransport` und wie `dkv-mail.service.ts`. ldap-spec: `getAllActiveConfigs` forSystem 1 / forTenant nie; Bootstrap leer forSystem 1 / forTenant nie / kein Update; Bootstrap mit Altzeile `forTenant(prisma,'t1')`, update `aa11:bb22:`. digest/matching: `__systemCallLog` genau `[tenderMatch.findMany]` bzw. `[tenderSavedSearch.findMany]`, `forTenant` weiter genau einmal, `tender.findMany` auf rohem Client. auth-spec Zeile 392: `sendPasswordResetEmail('bob@example.com', expect.any(String), 't1')` | +| 6 | Detektor: fuenfte Erkennungsform, `system-gebunden`, Vorrangregel, `FORSYSTEM_ALLOWED_CALL_SITES` mit exakten Zahlen (dkv 1, ldap 2, digest 1, matching 1), Fremddatei/Abweichung/veralteter Eintrag -> rot | VERIFIZIERT | Spec: Regex `/const\s+(\w+)\s*=\s*forSystem\(/g` (Zeile 439), `STAND_TOKENS = ['gebunden','ungebunden','gemischt','system-gebunden']`, Map exakt wie im Plan. `npx vitest run src/prisma/rls-access-inventory.spec.ts` -> 30/30 gruen. Quelltextzaehlung: `grep -rl 'forSystem(' apps/api/src` ohne spec/Helfer = genau die 4 Dateien; `const systemPrisma = forSystem(this.prisma)` = 5. EIGENE Falsifikation 1: `const x = forSystem(this.prisma);` in `apps/api/src/groups/groups.service.ts` (nicht in der Liste) -> `1 failed \| 29 passed`, Meldung `apps/api/src/groups/groups.service.ts: 1 forSystem(-Aufruf(e), Datei steht NICHT in FORSYSTEM_ALLOWED_CALL_SITES — ein Anfrageweg darf den Systemkontext nie rufen`. EIGENE Falsifikation 2: zweite Zuweisung in `dkv.service.ts` (erlaubte Datei) -> `2 failed \| 28 passed`, Meldungen `gemessen 2 forSystem(-Aufruf(e), erlaubt sind genau 1` und `Erlaubnisliste nennt 1, gemessen 2 — der Eintrag ist ueberholt`. Beide per `git checkout --` restauriert; `git status --porcelain -- apps/` leer; `git diff --quiet HEAD -- ` sauber | +| 7 | Frage aus Etappe 2 je Pfad beantwortet (Leere ist nie Abwesenheit), Abschnitt (y1)-(y5) in der Kritikschrift | VERIFIZIERT | `## Systemkontext (Etappe 3c, 260914-eym)` Zeile 3250 VOR `## Etappe 2 — Abschluss` 3465; `### (y1)` 3270, `(y2)` 3333, `(y3)` 3399, `(y4)` 3431, `(y5)` 3451. (y1): 22 `bestanden`-Zeilen, enthaelt `is-system-context-ungesetzt-false: bestanden`, `tendermatch-systemkontext-insert-abgewiesen-42501: bestanden` und fuenf `#system_read_policy#SELECT#is_system_context()#`-Zeilen. (y3) nennt dkv-scheduler.service.ts, ldap-sync.scheduler.ts, ldap.service.ts, ldap-config.service.ts, tender-digest.scheduler.ts, tender-matching.service.ts, admin-seed.service.ts je einmal. Nachtrag (260914-eym) in (d4)/(s4)/(b4) je 1, Abschluss 2 Treffer | +| 8 | Aktenstand kohaerent: sechs Zeilen `system-gebunden`, settings/smtpConfig `gebunden`, 72 Paare / 35/21/14/2, Uebersichtstabelle mit Spalte System und ABGELEITETER Summenzeile, Hintergrunddienst-Regelschluesse, Auftrag 3c erledigt, Datenbankrolle mit dritter Variable + preflight-Aussage, Ledger #21/#30 fixed, #37 neu, Zaehler 15/1/21/37 | VERIFIZIERT | Gate-Schleife aus Aufgabe 3 selbst ausgefuehrt: PAARE=72; Klassen gezaehlt 35/21/14/2 = dokumentiert; `system-gebunden`-Zeilen = 6 (dkv/dkvModuleConfig, ldap-config/ldapConfig, /ldapFieldMapping, /tenant, digest/tenderMatch, matching/tenderSavedSearch), settings/smtpConfig `gebunden`; Ableitung `ABGELEITET 61/179/5` (dkv 0/22/1, ldap 1/27/2, tenders 33/27/2) = Summenzeile `**61** \| **179** \| **5**`; Kopf `\| Bereich \| Ungebunden \| Gebunden \| System \|`; `Regelschluss (260914-eym)` im Hintergrunddienst-Abschnitt 7x (>= 6); `**Stand 260914-eym` vorhanden. Auftrag: `Erledigt (260914-eym, 3d64567/6e2a641 ...` Zeile 145. Datenbankrolle: `app.system_context` (Z. 90-103), `is-system-context-ungesetzt-false` (Z. 166), preflight-Aussage (Z. 163); im Diff gegen 5e0e408 kein `SECURITY DEFINER` (0). Ledger: `gsd-tools windows status` -> #21 `fixed` resolved_at 2026-09-14T09:51:23Z, #30 `fixed` resolved_at 2026-09-14T09:51:24Z, #37 `open` (quick-260914-eym, deviation, dkv.service.ts, Single-Flight-Riegel); Frontmatter open 15 / waived 1 / fixed 21 / total 37 = aus Zeilen gezaehlt 15/21/1/37 | +| 9 | Schalter AUS, Gates gegen 5e0e408 leer, Tests >= 1044, tsc 0, Werkzeug >= 250, sauber, gepusht | VERIFIZIERT | Abschnitte 1-3 | + +**Score:** 9/9 Wahrheiten verifiziert (0 present-behavior-unverified) + +### Verhaltensabhaengige Wahrheiten — Belegform + +Wahrheiten 1, 3, 5 und 6 behaupten Laufzeitverhalten (Kontext-Reset, Schreibverbot, Identitaet je Pfad, Wachhund). Keine davon ist auf Symbolpraesenz allein als VERIFIZIERT gesetzt: 1 und 3 sind live im Werkzeug gegen eine Rolle ohne BYPASSRLS gemessen (253 gruen, Rueckbau (a) selbst wiederholt), 5 durch die benannten Specs (172 Tests, echtes `cron`), 6 durch zwei eigene Falsifikationen. + +## 5. Artefakte + +| Artefakt | Erwartet | Status | Details | +|---|---|---|---| +| `apps/api/prisma/migrations/20260914120000_rls_system_context_read/migration.sql` | NEU, Funktion + fuenf Regeln + Abschnitt "bewusst NICHT" | VERIFIZIERT | 5/5/0/0-Zaehlung (s. o.); Abschnitt "Was diese Migration bewusst NICHT tut" vorhanden (SmtpConfig, Tenant/Tender, keine Schreibregel, Schalter); lokal angewendet (36 Migrationen) | +| `apps/api/src/prisma/prisma-tenant.extension.ts` | `forSystem()` mit Kopfkommentar, Reset in forTenant/withTenantTransaction, `$transaction`-Feld zwei Eintraege | VERIFIZIERT | gelesen; Abschnitt "SYSTEMKONTEXT (Etappe 3c, 260914-eym)" im Kopf; Array `[setContext, query(args)]` | +| `apps/api/src/prisma/prisma-tenant.extension.spec.ts` | >= 3 neue Tests | VERIFIZIERT | 11 -> 15 Tests, gruen | +| `apps/api/src/groups/migration-sql.spec.ts` | describe fuer neue Migration | VERIFIZIERT | `_rls_system_context_read` vorhanden; 32 Tests gruen | +| `apps/api/src/prisma/rls-access-inventory.spec.ts` | fuenfte Form, `systemModels`, `system-gebunden`, Erlaubnisliste | VERIFIZIERT | 30 Tests; zwei eigene Falsifikationen rot | +| `apps/api/scripts/rls-scratch-check.mjs` | `runSystemContextChecks`, `extractSystemReadPolicySql`, `buildInlineSystemClient` | VERIFIZIERT | grep-Treffer; 253 Pruefungen, Abschnitt laeuft im Hauptlauf | +| dkv (service, scheduler, controller, zwei Specs) | Auftrag je Mandant, `registeredTenantIds`, `stopJob(tenantId)`, neue Spec >= 6 Tests | VERIFIZIERT | 7 Scheduler-Tests, 17 Service-Tests gruen | +| mail (module, service, NEUE spec), settings (service, spec), auth (service, spec) | Startpfad weg, `resolveTransport`, Transport je Versand, `user.tenantId` durchgereicht | VERIFIZIERT | 4 Mail-Tests, 16 Settings-Tests, 29 Auth-Tests gruen | +| ldap-config, tender-digest, tender-matching (+Specs), tender-notifications.integration.spec | forSystem-Leser, Mocks ergaenzt | VERIFIZIERT | 19/16/17 Tests gruen; Integrationsspec in Vollsuite gruen | +| vier Dokumente + `.planning/WINDOWS.md` | Nachtraege, 3c erledigt, Ledger | VERIFIZIERT | Abschnitt 4, Wahrheiten 7/8 | + +## 6. Schluesselverbindungen (key_links) + +| Von | Nach | Ueber | Status | Details | +|---|---|---|---|---| +| `FOR SELECT` in der Migration | Schreibverbot unter Systemkontext | permissive ODER-Verknuepfung | VERBUNDEN | Rueckbau (a) selbst wiederholt: ohne `FOR SELECT` gelingt der Insert (5/253 rot); mit: 253 gruen | +| Detektor-Form `const X = forSystem(` | Bestandsaufnahme-Stand `system-gebunden` | Regex Zeile 439 + Erlaubnisliste | VERBUNDEN | 6 Zeilen `system-gebunden` in der Klassifikation; Falsifikationen rot | +| `set_config(..., true)` + Reset | Kein Erben zwischen Kontexten | Werkzeug `fortenant-a-nach-systemkontext-nur-a` | VERBUNDEN | 5x gruen; Rueckbau (c) nicht selbst wiederholt (Angenommene Risiken) | +| `auth.service.ts:248` | `MailService.sendPasswordResetEmail(..., tenantId)` | `user.tenantId` | VERBUNDEN | Quelltext + auth-spec Zeile 392 | +| `…-ungebunden-null-zeilen` + `…-sieht-beide-mandanten` | zu-wenig-statt-zu-viel-Falle | Werkzeugpaar je Tabelle | VERBUNDEN | 5 Paare gruen; (y3) beantwortet je Pfad | + +## 7. Datenfluss (Level 4) + +| Artefakt | Variable | Quelle | Echte Daten | Status | +|---|---|---|---|---| +| dkv-scheduler `onModuleInit` | `configs` | `forSystem(prisma).dkvModuleConfig.findMany({ where: { isActive: true } })` | ja | FLIESST | +| mail `resolveTransport` | `smtpConfig` | `settingsService.getDecryptedSmtpConfig(tenantId)` -> `forTenant(...).smtpConfig.findUnique({ where: { tenantId } })` | ja (Rueckfall Env-Kette explizit) | FLIESST | +| ldap `getAllActiveConfigs` / Bootstrap | `configs` | `forSystem(prisma).ldapConfig.findMany(...)` | ja | FLIESST | +| digest `candidates` / matching `savedSearches` | — | `forSystem(prisma).tenderMatch.findMany` / `.tenderSavedSearch.findMany()` | ja | FLIESST | + +## 8. Verhaltens-Stichproben + +| Verhalten | Kommando | Ergebnis | Status | +|---|---|---|---| +| Vollsuite | `npx vitest run` | 64 Dateien / 1054 Tests | PASS | +| Typpruefung | `npx tsc --noEmit` | Exit 0 | PASS | +| Zehn betroffene Specs benannt | `npx vitest run <10 Dateien>` | 10 / 172 gruen | PASS | +| Detektor | `npx vitest run src/prisma/rls-access-inventory.spec.ts` | 30/30 | PASS | +| Detektor mit Fremddatei | s. Wahrheit 6 | 1 failed / 29 passed | PASS (rot wie gefordert) | +| Detektor mit Zahlabweichung | s. Wahrheit 6 | 2 failed / 28 passed | PASS (rot wie gefordert) | +| Werkzeug gruen | `node apps/api/scripts/rls-scratch-check.mjs` (2x) | 253 / 253 | PASS | +| Werkzeug Rueckbau (a) | `FOR SELECT` bei TenderMatch entfernt | `5 von 253 Pruefungen fehlgeschlagen.` — Insert GELINGT | PASS (rot wie gefordert) | + +## 9. Sonde-Ausfuehrung + +Keine `scripts/*/tests/probe-*.sh` im Projekt; das Werkzeug `rls-scratch-check.mjs` ist die Sonde dieses Durchlaufs und wurde zweimal selbst ausgefuehrt (Abschnitt 2, 8). + +## 10. Anforderungsabdeckung + +| Anforderung | Plan | Beschreibung | Status | Beleg | +|---|---|---|---|---| +| ETAPPE-3C | 01 | Systemkontext fuer Hintergrunddienste | ERFUELLT | Wahrheiten 1-9 | +| WINDOWS-21 | 01 | DKV-Planer je Mandant | ERFUELLT | Wahrheit 4/5, Ledger #21 fixed | +| WINDOWS-30 | 01 | Mail-Startpfad | ERFUELLT (durch Entfernen, nicht Umstellen — im Plan so vorgesehen) | Wahrheit 4/5, Ledger #30 fixed | + +Keine Zuordnung in `.planning/REQUIREMENTS.md` fuer Quick-Tasks — keine verwaisten Anforderungen. + +## 11. Anti-Pattern-Scan + +`grep -n -E "\b(TBD|FIXME|XXX|TODO|HACK|PLACEHOLDER)\b"` ueber alle 29 geaenderten Dateien: keine Treffer. `console.log` in geaenderten Nicht-Spec-Dateien: keine Treffer. Keine Stubs: `sendWelcomeEmail` ist vollstaendig implementiert und hat null Aufrufer ausserhalb `mail/` (Bestand seit vor diesem Durchlauf, in (y4) benannt). + +## 12. Menschliche Pruefung erforderlich + +Keine — jede Zusicherung des Plans ist entweder statisch, per Test oder live gegen die Datenbank gemessen. Was ausserhalb dieses Repos liegt, steht unter "Angenommene Risiken". + +## 13. Luecken + +Keine. + +## Angenommene Risiken + +Was ich NICHT selbst messen konnte oder bewusst nicht wiederholt habe: + +1. **Rueckbau (b), (c) und (d) nicht selbst wiederholt.** Der Auftrag verlangte EINE Rueckbau-Falsifikation (empfohlen (a)); die habe ich vollstaendig wiederholt und dasselbe Ergebnis wie die SUMMARY beobachtet (5 von 253 rot, Insert gelingt). Fuer (b) (Regel aus der Migration entfernt -> Werkzeug folgt der Datei, DB bleibt 34), (c) (`local=false` + Reset entfernt -> Erben sichtbar) und (d) (Erlaubniszahl auf 0) stuetze ich mich auf die woertlichen Ausgaben der SUMMARY. (d) ist durch meine beiden eigenen Detektor-Falsifikationen in der Sache gedeckt (Fremddatei rot, Zahlabweichung rot); (c) ist durch die fuenf gruenen `…-fortenant-a-nach-systemkontext-nur-a`-Kennungen und den gelesenen Helfer-Quelltext (Reset in allen drei Formen) gedeckt, nur der Beleg "Reset traegt bei local=false" ist nicht erneut erzeugt. +2. **Alpha-Go-live morgen ist nicht beobachtet.** Dass DKV-Postfach-Abruf und Kennwort-Zuruecksetzung auf `alpha.tessera.ctl.de` mit dem echten SMTP-Server und dem echten Postfach identisch zu heute laufen, ist hier per Test festgenagelt (Cron-Expression, Tick, Transport aus der SmtpConfig des Mandanten), nicht gegen den Testserver gemessen — Deploy und Beobachtung auf dem Server macht der User selbst (Absprache). Unter BYPASSRLS sind `forSystem`/`forTenant` wirkungslos; die einzigen beobachtbaren Verhaltensaenderungen sind (i) der Registry-Name `dkv-inbox-poll:` statt `dkv-inbox-poll` und (ii) der Transport je Versand statt beim Start — beide durch Tests gedeckt, (ii) zusaetzlich feldweise gegen den geloeschten Startpfad verglichen. +3. **Migration auf alpha.** `20260914120000_rls_system_context_read` ist rein additiv (CREATE FUNCTION, CREATE POLICY) auf Tabellen, die RLS bereits aus frueheren Migrationen tragen; sie ist lokal per `migrate deploy` gruen. Ob `migrate deploy` auf alpha morgen ebenso sauber laeuft, ist hier nicht messbar (kein Deploy durch mich). +4. **`@nestjs-modules/mailer` bleibt installiert und unbenutzt** (`package.json`/Lockfile bewusst unveraendert, im Plan so vorgesehen). Kein Defekt, aber Aufraeumbedarf — in (y4) und in der SUMMARY benannt. +5. **WINDOWS #37 (Single-Flight-Riegel prozessweit)** ist bewusst offen; mit einem Mandanten ohne Wirkung, mit mehreren nur Verzoegerung, kein Datenverlust — im Ledger als `open` eingetragen, nicht Teil dieses Auftrags. +6. **Ledger-Zeitstempel**: `resolved_at` von #21/#30 liegt bei 09:51 UTC (11:51 lokal), passend zur SUMMARY-Sitzung 11:10-12:05; nicht weiter pruefbar. + +Der Arbeitsbaum wurde exakt so hinterlassen wie vorgefunden: `git status --porcelain` zeigt nur ` M .planning/STATE.md` und die neue SUMMARY (beide unangetastet) sowie jetzt diese VERIFICATION.md. Alle drei temporaeren Aenderungen (groups.service.ts, dkv.service.ts, migration.sql) sind per `git checkout --` restauriert und mit `git status --porcelain -- apps/` (leer) belegt; die lebende Datenbank steht bei 34 Regeln, keine Wegwerf-Datenbank blieb zurueck. + +--- + +_Verifiziert: 2026-09-14T12:40:00Z_ +_Verifier: Claude (gsd-verifier)_