docs(changelog): Version 1.4.0 abgeschlossen

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
docs(quick-260924-m4n): Test-Flake und DashboardImage Stufe 2
2026-09-25 07:58:45 +02:00 · 2026-09-24 16:13:05 +02:00 · 2026-09-24 16:09:36 +02:00 · 2026-09-24 16:02:45 +02:00
18 changed files with 541 additions and 348 deletions
@@ -7,7 +7,7 @@ status: verified
 stopped_at: "22.09.2026: 1.3.0 freigegeben; danach quick-260922-hk4 — Bilderrahmen-Bilder liegen jetzt im Dateibereich (user-files) statt in der Datenbank, Umzug laeuft automatisch beim Start, Selbstheilung aus der alten data-Spalte eingebaut; im Browser nachgewiesen. NAECHSTER SCHRITT, vom Nutzer noch nicht bestaetigt: (1) einmaliges Aufraeumen, damit ein Modul seine Dashboard-Kachel selbst mitbringt (heute sieben Hartkodierungen je Kachel; Katalog zeigt auch Kacheln gesperrter Module; gesperrte Kachel bleibt leer statt zu erklaeren) — das Geruest WIDGET_MODULE_MAP existiert und ist leer; (2) danach das Proxmox-Modul (PVE/PBS/PMG) und seine Kachel. Offen beim Nutzer: Live-Server auf 1.3.0 ziehen, neuen Client per Browser installieren."
 last_updated: "2026-09-23T15:30:00.000Z"
 last_activity: 2026-09-23
-last_activity_desc: Quick 260924-i8v — Proxmox-Kachel fuers Dashboard; davor CI-Runner haengte (Neustart, Lauf 423 gruen)
+last_activity_desc: Quick 260924-m4n — flackernder Test entschaerft, alte DashboardImage-Spalte entfernt (mit Schutzklausel); 1.4.0 vom Nutzer ausdruecklich NICHT freigegeben
 state_head: 4d485432c003a6caf68f6d85aff7de0bd27794e2
 progress:
  total_phases: 18
@@ -474,6 +474,7 @@ Gerettet aus `.continue-here.md`. Relevant fuer die noch offenen Live-Tests.
 | 260923-lrr | **Favoriten: eigenes Symbol hochladen, Symbol sofort aktualisiert, Cloudflare-Meldung.** Versionszaehler `iconVersion` an der Symboladresse (`?v=`) statt 24-h-Zwischenspeicher mit fester Adresse (Ursache „neue Logo-Adresse, nichts passiert“); `Cache-Control: private`. Upload PNG/JPEG/GIF/WebP/ICO/SVG bis 512 KB nach Dateiinhalt, Ablage `user-files/favorite-icons/<userId>/<id>.<ext>`, Vorrang vor Logo-Adresse, Entfernen-Knopf. Neue Logo-Adresse wird beim Speichern einmal zur Probe abgerufen; scheitert es (Cloudflare-Pruefung, 403), bleibt das Formular offen mit deutscher Meldung und Hinweis aufs Hochladen. Aufraeumen der Dateien auch beim Loeschen einer Kachel/eines Reiters (T-LRR-07 geschlossen). Browser-Nachweis: rot hochgeladen -> sofort rot (v=1), blau -> sofort blau (v=2), Entfernen -> altes Logo (v=3), httpbin 403 -> Meldung, google favicon -> sofort (v=4). Nachtrag Orchestrator: Zeile `dashboard.service.ts`/`favoriteLink` in der Zugriffsklassifikation. api 1368, web 742 gruen. | 2026-09-23 | 7704372,61f95c8 | [260923-lrr-favoriten-eigenes-symbol-hochladen-und-s](./quick/260923-lrr-favoriten-eigenes-symbol-hochladen-und-s/) |
 | 260924-h7x | **Proxmox-Seite neu gestaltet (Status bestimmt das Bild) und Dashboard-Reiter in die Kopfzeile.** Nutzer hob am 24.09. die Umbausperre vom 23.09. selbst auf. Design-Plan aus dem frontend-design-Skill: Statusfarben als OKLCH-Tokens (`--status-ok/warn/down/idle/orphan`, dazu `-fg`-Textvarianten fuer 4,5:1), Gesundheitsbalken mit Legende, Karten mit Statusleiste links und im Statuston getoentem Schatten, eingelassene Messfelder, Knoten als Einschuebe mit Balken nach Schwellen (80/92 %, Sicherung > 26 h), PMG-Zahlfelder. **Deaktivierter Server = „Offline & verwaist“** (Vorrang vor allem, keine alten Werte, gestrichelt). Sortierung down/warn/ok/idle/orphan, Spaltenfluss statt Raster. Reiter als eingelassener Umschalter per Portal in der Kopfzeilenmitte (`header-center-slot`), eigene Zeile entfallen, Pfeiltasten, weiche Randausblendung bei Ueberlauf; unter 640 px Logo nur Bildmarke. Browser: hell/dunkel 1400 px, 390 px ohne Ueberlauf. web 789 gruen. | 2026-09-24 | 0fa7ce0,57c338f,7416a92,0b659d6,57a4196 | [260924-h7x-proxmox-seite-status-design-und-dashboar](./quick/260924-h7x-proxmox-seite-status-design-und-dashboar/) |
 | 260924-i8v | **Proxmox-Kachel fuers Dashboard.** Modul-Kachel ueber den Weg aus 260922-m1h (Typ `proxmox` in packages/shared + Modulbindung, API-Freigabeliste, Registry, Katalog), nur fuer Benutzer mit Modulzugriff. Kompakter Gesundheitsbalken + Zusammenfassung in Worten, Serverliste nach Dringlichkeit mit je einer Kennzahl (Gaeste/Auslastung, aelteste Sicherung, eingehende Mails, unbekannt nie 0), Links auf /modules/proxmox (nicht im Bearbeitungsmodus), liest jede Minute den Zwischenstand (pausiert bei verborgenem Tab, loest NIE eine Abfrage aus), Titel + Serverauswahl an der Kachel und unter Einstellungen > Dashboard, Groessenstufen per Container-Query. Gemeinsame Teile nach `components/proxmox/` verschoben. Browser: Katalog, Kachel hell/dunkel, schmale Stufe (nur Punkte+Namen). web 864, api 1370 gruen. | 2026-09-24 | a906c67,92bf130,a217d60,377b6e3,586da44,602a45c | [260924-i8v-proxmox-kachel-fuers-dashboard](./quick/260924-i8v-proxmox-kachel-fuers-dashboard/) |
+| 260924-m4n | **Flackernden Test entschaerft, alte Bildspalte entfernt.** (1) `tenant-selector.test.tsx`: Ursache war das Laden der Bausteine INNERHALB des ersten Tests (zaehlte in dessen 5-s-Grenze) -> Import vorab, Doppelfall getrennt, dasselbe in zwei weiteren Marktplatz-Tests; langsamster Web-Test jetzt < 2 s (mit 2 Kernen 1,3 s); act()-Warnungen der Proxmox-Kachel weg. (2) DashboardImage Stufe 2: Migration `20260924120000_dashboard_image_drop_data` mit Schutz (bricht ab, wenn noch Zeilen ohne `storagePath`; Zeilenschutz fuer die Pruefung abgeschaltet, sonst saehe sie still 0), `storagePath` NOT NULL, `data` weg, `system_read_policy` weg, Bootstrap-Umzug + `forSystem()` entfernt, Upload legt Zeile gleich mit Pfad an. Vorbedingung alpha geprueft (0 von 3 ohne Pfad); Live nicht pruefbar. Rueckweg bei Abbruch in `docs/anleitung-betrieb.md` Kap. 4. Browser/API: Bilder laden, Upload+Anzeige+Loeschen ok. api 1364, web 865 gruen. | 2026-09-24 | b10734f,dd54ec5 | [260924-m4n-flackernden-test-entschaerfen-und-dashbo](./quick/260924-m4n-flackernden-test-entschaerfen-und-dashbo/) |

 ## Deferred Items

@@ -0,0 +1,69 @@
+---
+quick_id: 260924-m4n
+type: quick
+wave: 1
+autonomous: true
+---
+
+# Quick 260924-m4n — Flackernden Test entschaerfen; DashboardImage Stufe 2 (Spalte `data` entfernen)
+
+Nutzerfreigabe 24.09.: beide offenen Punkte erledigen. Keine Freigabe/kein Tag.
+
+## Task 1 — Flackernder Test `TenantContextSelector`
+
+Todo: `.planning/todos/pending/2026-09-23-flackernder-test-tenant-selector-zeitueberschreitung.md`
+(lesen, dort steht die Analyse). Test: `apps/web/src/app/(portal)/marketplace/tenant-selector.test.tsx:100`.
+
+- Ursache ansehen (warum nahe 5 s?). Den Doppelfall (SUPER_ADMIN + ADMIN in EINEM `it`) in zwei
+  `it` auftrennen; langsame Stellen (unnoetige echte Wartezeiten, schwere Importe je Test)
+  beseitigen. KEIN globales Hochsetzen von `testTimeout`.
+- Messen: `vitest run --reporter=verbose` fuer die ganze Web-Suite, die 10 langsamsten Tests
+  auflisten (Dauer). Jeder Test ueber 2 s wird in der SUMMARY genannt; wenn eine Ursache offensichtlich
+  und klein ist, gleich beheben, sonst nur auflisten.
+- Nebenbei (klein, gleiche Datei-Gruppe erlaubt): die `act(...)`-Warnungen aus
+  `apps/web/src/components/dashboard/widgets/proxmox-widget.test.tsx` beseitigen (auf das Ende der
+  Zustandsaenderung warten statt sie ins Leere laufen zu lassen) — sie blaehen das CI-Protokoll auf.
+- Todo-Datei nach `.planning/todos/done/` verschieben (git mv), mit kurzem Nachtrag „erledigt in 260924-m4n“.
+
+## Task 2 — DashboardImage Stufe 2
+
+Todo: `.planning/todos/pending/2026-09-22-dashboard-image-data-spalte-entfernen.md` — die dort
+genannten Schritte 2–4 umsetzen. Vorbedingung geprueft vom Orchestrator: alpha
+`count(storagePath IS NULL) = 0` (3 Zeilen). Live ist von hier nicht pruefbar (Live laeuft 1.3.1, die den
+Bootstrap-Umzug enthaelt).
+
+- Neue Migration mit aktuellem Zeitstempel (NACH allen vorhandenen, `ls apps/api/prisma/migrations`),
+  Name `..._dashboard_image_drop_data`. ZUERST ein Schutz, der den Datenverlust ausschliesst:
+
+  ```sql
+  DO $$
+  BEGIN
+    IF EXISTS (SELECT 1 FROM "DashboardImage" WHERE "storagePath" IS NULL) THEN
+      RAISE EXCEPTION 'DashboardImage: es gibt noch Zeilen ohne storagePath — Umzug (quick-260922-hk4) zuerst mit einer Version >= 1.3.1 laufen lassen, dann erneut deployen';
+    END IF;
+  END $$;
+  ALTER TABLE "DashboardImage" ALTER COLUMN "storagePath" SET NOT NULL;
+  ALTER TABLE "DashboardImage" DROP COLUMN "data";
+  ```
+
+  Achtung RLS: die Migration laeuft als Eigentuemer; pruefen, dass der `EXISTS`-Check nicht von einer
+  Zeilenregel auf 0 gefiltert wird (FORCE ROW LEVEL SECURITY?). Wenn ja, den Check so formulieren, dass
+  er alle Zeilen sieht (z. B. `SET LOCAL row_security = off` falls als Eigentuemer erlaubt, oder ueber die
+  vorhandene `system_read_policy`). Das Ergebnis der Pruefung in die SUMMARY.
+- Schema, Dienst (Bootstrap-Umzug + `forSystem()` raus), `FORSYSTEM_ALLOWED_CALL_SITES`, Tests
+  18/21/22/23, Zugriffsklassifikation (Zahlen per Gate-Schleife neu messen, nicht abschreiben),
+  `system_read_policy` auf `DashboardImage` per `DROP POLICY IF EXISTS` in derselben Migration entfernen
+  und die Klassifikation/Aufzaehlung nachziehen.
+- Lokal anwenden (DB ohne Host-Port: Container-IP, `tessera:tessera_dev`), vorher/nachher
+  `pg_total_relation_size` messen, danach `VACUUM FULL "DashboardImage";` lokal.
+- Negativtest der Schutzklausel lokal nachweisen: in einer Wegwerf-Datenbank oder Transaktion eine Zeile
+  mit `storagePath NULL` anlegen → Migration bricht mit der Meldung ab (Protokoll in die SUMMARY).
+- CHANGELOG „Unveröffentlicht“ nur, wenn für Nutzer sichtbar (eher nicht) — sonst weglassen.
+- `docs/anleitung-betrieb.md`: kurzer Hinweis im Abschnitt Aktualisieren/Freigabe, dass die nächste
+  Version die alte Bildspalte entfernt und bei Abbruch mit der Meldung zuerst 1.3.1 laufen muss.
+- Todo-Datei nach `.planning/todos/done/` verschieben.
+
+## Tore
+
+- API-Tests KOMPLETT (inkl. `src/prisma/rls-access-inventory.spec.ts`), Web-Tests komplett,
+  `pnpm turbo run type-check lint` gruen, Biome-Warnungen web ≤ 53, api ≤ 82.
@@ -0,0 +1,165 @@
+---
+quick_id: 260924-m4n
+type: quick
+status: complete
+subsystem: apps/web-tests, apps/api/dashboard, apps/api/prisma
+tags: [flake, vitest, act, prisma-migration, rls, bilderrahmen]
+requires: [quick-260922-hk4]
+provides:
+  - Marktplatz-Tests ohne dynamischen Import im Test (Flake der Freigabe 1.3.1 entschärft)
+  - Proxmox-Kachel-Tests ohne act-Warnungen
+  - Migration 20260924120000_dashboard_image_drop_data (Stufe 2, mit Schutzprüfung)
+affects: [Freigabe der nächsten Version nach 1.3.1, docs/anleitung-betrieb.md Kap. 4]
+key-files:
+  created:
+    - apps/api/prisma/migrations/20260924120000_dashboard_image_drop_data/migration.sql
+  modified:
+    - apps/web/src/app/(portal)/marketplace/tenant-selector.test.tsx
+    - apps/web/src/app/(portal)/marketplace/marketplace.test.tsx
+    - apps/web/src/app/(portal)/marketplace/marketplace-filters.test.tsx
+    - apps/web/src/components/dashboard/widgets/proxmox-widget.test.tsx
+    - apps/api/prisma/schema.prisma
+    - apps/api/src/dashboard/dashboard-images.service.ts
+    - apps/api/src/dashboard/dashboard-images.service.spec.ts
+    - apps/api/src/prisma/rls-access-inventory.spec.ts
+    - apps/api/src/proxmox/proxmox.service.ts
+    - docs/anleitung-betrieb.md
+    - docs/mandantentrennung-zugriffsklassifikation.md
+decisions:
+  - "Flake-Ursache: Komponenten wurden per await import() IM Test geladen, das Laden zählte in die 5-s-Frist; Lösung statische Importe + Doppelfall aufgetrennt, kein globales testTimeout"
+  - "Migration heißt 20260924120000_dashboard_image_drop_data statt der im Todo vorgemerkten 20260922120100, weil sie hinter allen vorhandenen Migrationen liegen muss"
+  - "Schutzprüfung der Migration schaltet row_security für die Transaktion ab: ein Eigentümer ohne BYPASSRLS würde sonst still 0 Zeilen sehen, jetzt scheitert er laut"
+  - "Upload vergibt die UUID selbst (randomUUID) und legt die Zeile gleich mit storagePath an, weil storagePath Pflicht ist"
+  - "system_read_policy auf DashboardImage in derselben Migration entfernt (kein Leser mehr)"
+metrics:
+  duration: ~45 min
+  completed: 2026-09-24
+actuals:
+  tokens: 21900
+  tasks: 2
+  commits: 2
+plan_head_before: dd09c0831142b7068f060f09ece471eb1e27560b
+---
+
+# Quick 260924-m4n: Flackernden Test entschärft, alte Bildspalte des Bilderrahmens entfernt – Zusammenfassung
+
+Der Marktplatz-Test, der die Freigabe 1.3.1 blockiert hat, lädt seine Komponenten jetzt beim Einlesen der Testdatei statt im Test selbst und ist in zwei Einzelfälle aufgeteilt. Die Proxmox-Kachel-Tests erzeugen keine act-Warnungen mehr (81 weniger im CI-Protokoll). Außerdem ist Stufe 2 der Bilderrahmen-Umstellung umgesetzt: Die Spalte `data` ist weg, `storagePath` ist Pflicht. Eine Schutzprüfung bricht die Migration ab, bevor Daten verloren gehen könnten.
+
+## Aufgabe 1 – Flackernder Test `TenantContextSelector` (Commit b10734f)
+
+**Ursache:** `tenant-selector.test.tsx` hat `TenantContextSelector` und die Marktplatzseite per `await import(...)` **innerhalb** der Tests geladen. Der erste Test einer Datei hat damit das Laden und Umwandeln der Module in seiner 5-s-Frist mitbezahlt. Lokal waren das nur rund 115 ms. Bei jeder Freigabe laufen aber drei Pipelines gleichzeitig, und unter dieser Last reißt der Test die Frist. `waitFor` selbst war nicht der Grund: Es bricht schon nach 1 s mit einer eigenen Meldung ab, nicht erst nach 5 s.
+
+**Behoben:**
+- Statische Importe: `vi.mock` wird über die Importe gehoben, das Laden fällt damit in die Einlesephase der Datei.
+- Der Doppelfall steckt jetzt in zwei `it`: „renders tenant options for SUPER_ADMIN“ sowie „renders nothing for ADMIN and does not load the tenant list“. Der ADMIN-Fall prüft zusätzlich, dass kein Abruf stattfindet.
+- Die gleiche Umstellung gilt für `marketplace.test.tsx` und `marketplace-filters.test.tsx`, die aus demselben Ordner stammen. In `marketplace-filters` ist `userEvent` jetzt per `userEvent.setup({ advanceTimers: vi.advanceTimersByTime })` an die simulierte Uhr gekoppelt. Vorher hat jede Eingabe auf das langsame Nachschieben in Echtzeit durch `shouldAdvanceTime` gewartet. Der Test „typing in search … after debounce“ läuft allein jetzt in 358 ms statt vorher rund 1,1 s in der Gesamtsuite.
+- `testTimeout` wurde nicht global erhöht.
+
+**Proxmox-Kachel (`proxmox-widget.test.tsx`):** `renderWidget()` rendert jetzt innerhalb von `await act(async () => …)`. Dadurch laufen die drei Zustandsänderungen nach dem ersten Laden (`setServers`, `setLoadFailed`, `setNow`) innerhalb von act() und nicht mehr danach ins Leere. Den Test „Verlassen des Bearbeitungsmodus“ habe ich genauso umgestellt, und die Komponente wird ebenfalls statisch importiert.
+- act-Warnungen in der ganzen Web-Suite: **vorher 102, davon 81 von ProxmoxWidget. Nachher 21, davon 0 von ProxmoxWidget.** Die restlichen 21 stammen aus VehicleTable (8), WidgetSettingsPanel (8), DashboardPage (3), CalendarWidget (1) und Header (1). Sie lagen außerhalb des Auftrags und sind nicht angefasst.
+
+**Messung:** `vitest run --reporter=verbose --reporter=json` über die ganze Web-Suite mit 91 Dateien und 865 Tests, alle grün.
+
+Die 10 langsamsten Tests nach der Änderung im normalen Lauf mit 12 Kernen:
+
+| # | Dauer | Datei | Test |
+|---|---|---|---|
+| 1 | 1136 ms | components/settings/smtp-settings-form.test.tsx | Test 2: PUT-Payload trägt den Wert; leeres Feld -> null |
+| 2 | 1044 ms | components/bug-report/bug-report-button.test.tsx | Test 1: Bild VOR dem Dialog … |
+| 3 | 882 ms | components/settings/proxmox-widget-config-form.test.tsx | lädt die Server einmal und zeigt die Auswahl … |
+| 4 | 839 ms | app/(portal)/marketplace/marketplace-filters.test.tsx | typing in search filters the grid … after debounce |
+| 5 | 799 ms | components/proxmox/proxmox-server-picker.test.tsx | zeigt je Server ein Kästchen … |
+| 6 | 798 ms | modules/tender-radar/settings/components/SourceConfigForm.test.tsx | editing the interval and clicking Speichern … |
+| 7 | 749 ms | modules/dkv-fleet/settings/components/VehicleTable.test.tsx | clicking trash icon opens confirm dialog … |
+| 8 | 746 ms | components/settings/picture-frame-config-form.test.tsx | Test 4: Pfeile … |
+| 9 | 742 ms | app/(portal)/admin/users/user-access-modal.test.tsx | rolls back the direct checkbox … |
+| 10 | 741 ms | app/(portal)/admin/users/users-page.test.tsx | zeigt den Servertext im offenen Löschdialog … |
+
+Zusätzlich lief die ganze Suite gedrosselt auf 2 Kerne (`taskset -c 0-1`, 6 Worker), um die Last beim Freigeben nachzustellen. Alle 865 Tests waren grün, der langsamste brauchte 1302 ms (smtp-settings-form Test 2). Die Tests von `tenant-selector` lagen dort bei höchstens 950 ms.
+
+**Kein Test lag über 2 s**, weder im normalen noch im gedrosselten Lauf. Damit gibt es nichts weiter zu beheben oder aufzulisten.
+
+**Beobachtung, nicht behoben:** Das Muster „Komponente per `await import()` im Test laden“ steckt noch in 37 weiteren Web-Testdateien. Es macht jeweils den ersten Test einer Datei unter Last anfälliger. Keiner dieser Tests liegt heute nahe am Limit. Umgestellt sind nur der Marktplatz-Ordner und die Proxmox-Kachel.
+
+## Aufgabe 2 – DashboardImage Stufe 2 (Commit dd54ec5)
+
+**Migration `20260924120000_dashboard_image_drop_data`:**
+1. Eine Schutzprüfung im `DO`-Block: Existiert noch eine Zeile mit `storagePath IS NULL`, bricht die Migration mit `RAISE EXCEPTION` ab, und zwar mit der Meldung aus dem Plan.
+2. `ALTER COLUMN "storagePath" SET NOT NULL`, danach `DROP COLUMN "data"`.
+3. `DROP POLICY IF EXISTS system_read_policy ON "DashboardImage"`.
+
+Die Migration musste einen anderen Namen bekommen als im Todo vorgemerkt (`20260922120100`), weil sie hinter allen vorhandenen Migrationen liegen muss (die letzte war `20260923160000`).
+
+**Prüfung des Zeilenschutzes (RLS), Ergebnis:**
+- `DashboardImage` hat `FORCE ROW LEVEL SECURITY`, das gilt auch für den Eigentümer. Heute läuft `migrate deploy` als `tessera`. Die Rolle ist lokal gemessen Superuser mit BYPASSRLS und Eigentümerin der Tabelle, sieht also alle Zeilen.
+- **Die Falle ist real, lokal nachgewiesen:** Ein Eigentümer **ohne** BYPASSRLS bekommt bei `SELECT EXISTS (… storagePath IS NULL)` das Ergebnis `f`, obwohl eine solche Zeile existiert. Die Schutzprüfung wäre dann stumm wirkungslos. Getestet habe ich das mit einer Wegwerf-Rolle `m4n_owner` in einer Transaktion, die danach zurückgerollt wurde.
+- **Lösung:** Die Prüfung setzt `set_config('row_security', 'off', true)`. Sie sieht damit entweder alle Zeilen, oder PostgreSQL bricht laut ab. Die Meldung „ERROR: query would be affected by row-level security policy for table "DashboardImage"“ ist unter derselben Wegwerf-Rolle nachgewiesen. Als `tessera` greift die Schutzprüfung wie gewollt, auch das ist nachgewiesen. Die Datenbank sieht also nie „0 Zeilen, weiter“.
+
+**Negativtest der Schutzprüfung** in einer Wegwerf-Datenbank `tessera_m4n_neg`, die danach gelöscht wurde. Alle Migrationen bis `20260923160000` wurden angewendet, dann eine Zeile mit Pfad und eine ohne Pfad angelegt:
+```
+Applying migration `20260924120000_dashboard_image_drop_data`
+Error: P3018
+Database error code: P0001
+ERROR: DashboardImage: es gibt noch Zeilen ohne storagePath — Umzug (quick-260922-hk4) zuerst mit einer Version >= 1.3.1 laufen lassen, dann erneut deployen
+```
+Danach war nichts geändert: `data` und `storagePath` waren weiterhin NULLbar, und `system_read_policy` stand noch.
+
+**Nebenbefund, im Betriebshandbuch beschrieben:** Nach dem Abbruch verweigert auch 1.3.1 den Start mit `P3009` („failed migrations in the target database“). Den Ausweg habe ich vollständig durchgespielt. Zuerst wird der fehlgeschlagene Eintrag in `_prisma_migrations` als zurückgenommen markiert: `UPDATE … SET rolled_back_at = now() WHERE migration_name = '…' AND finished_at IS NULL`. Danach meldet der Stand von 1.3.1 „No pending migrations“. Anschließend habe ich den Umzug nachgestellt, und die neue Version lief sauber durch: NOT NULL gesetzt, Spalte entfernt, nur noch `tenant_isolation_policy` vorhanden. Der Ablauf steht in drei Schritten in `docs/anleitung-betrieb.md` Kapitel 4.
+
+**Lokal angewendet** über die Container-IP 172.19.0.2 mit `tessera:tessera_dev`:
+
+| Zeitpunkt | `pg_total_relation_size` | Zeilen |
+|---|---|---|
+| vorher (0 ohne Pfad, 1 Zeile mit 502 Bytes in `data`) | 65536 (64 kB) | 2 |
+| nach DROP | 65536 (64 kB) | 2 |
+| nach `VACUUM FULL "DashboardImage"` | 65536 (64 kB) | 2 |
+
+Lokal ist keine Verkleinerung messbar. In `data` standen nur 502 Bytes, und die Tabelle belegt schon mit Tabelle, TOAST und zwei Indizes die Mindestgröße ganzer 8-kB-Seiten. Auf alpha und live mit echten Bildern ist der Gewinn größer. Dort gilt ebenfalls, dass PostgreSQL den Platz erst nach `VACUUM FULL` an das Dateisystem zurückgibt. Ob man das dort ausführt, entscheidest du; ich habe keinen Server angefasst.
+
+**Dienst (`dashboard-images.service.ts`):**
+- `onApplicationBootstrap()` samt `forSystem()` ist entfernt, ebenso die Selbstheilung aus `data` in `getBytes`.
+- `upload` vergibt die UUID selbst mit `randomUUID()` und legt die Zeile gleich mit `storagePath` an, weil das Feld jetzt Pflicht ist. Das nachträgliche `update` entfällt. Das Verhalten bei halb fertigen Zuständen bleibt gleich: erst die Zeile, dann die Datei, und scheitert das Schreiben, wird die Zeile wieder gelöscht und 500 zurückgegeben.
+- Schema: `data Bytes?` ist gestrichen, `storagePath String?` wird zu `storagePath String`.
+
+**Tests:** Die Fälle 18 und 21–23 entfallen wie geplant. Dazu fallen **10b und 10c** weg, weil sie die Selbstheilung aus `data` geprüft haben, die es nicht mehr gibt. Test 16 liest jetzt eine JPEG-Datei statt „Datei schlägt Zeilenbytes“, Test 13 prüft die UUID und den Pfad im `create`, und Test 12 prüft die neue Aufrufreihenfolge ohne `update` und ohne `forSystem`. Die Dienst-Spec hat damit 19 statt 25 Tests.
+
+**Erlaubnisliste und Klassifikation:**
+- `FORSYSTEM_ALLOWED_CALL_SITES`: Der Eintrag `dashboard-images.service.ts` ist entfernt, jetzt 5 Dateien mit 6 Aufrufen.
+- `docs/mandantentrennung-zugriffsklassifikation.md`: Der Stand des Paars `dashboard-images.service.ts`/`dashboardImage` geht von `system-gebunden` zurück auf `gebunden`. Die Zahlen habe ich mit der Gate-Schleife (`for d in apps/api/src/*/`) **neu gemessen**:
+  - Bereich `dashboard` geht auf **1/29/0**. Im Dokument stand 1/28/1, gemessen waren vor dieser Änderung aber schon 1/31/1, weil quick-260923-lrr zwei Treffer (favoriteLink) hinzugefügt hatte, ohne die Zeile nachzuziehen. Diese Änderung selbst zieht 2 gebundene Treffer und 1 System-Treffer ab.
+  - Bereich `favorites` geht auf **0/12/0**. Im Dokument stand 0/8/0, auch hier war die Zeile nach quick-260923-lrr nicht nachgezogen worden.
+  - Die Summe geht auf **61/213/6**, vorher 61/208/7.
+  - Die Aufzählung der Tabellen mit `system_read_policy` ist korrigiert. Es sind jetzt sechs Tabellen (lokal gemessen), `ProxmoxServer` fehlte bisher in der Aufzählung, und `DashboardImage` ist nur noch als vorübergehender Fall erwähnt.
+  - Gegenprobe: Den Stand habe ich absichtlich auf `system-gebunden` zurückgedreht. `rls-access-inventory.spec.ts` wurde rot („dokumentiert=system-gebunden, gemessen=gebunden“), danach habe ich die Datei zurückgesetzt.
+- Einen veralteten Kommentarverweis auf `DashboardImagesService` als Vorbild habe ich in `proxmox.service.ts` entfernt.
+
+**CHANGELOG:** bewusst nicht ergänzt, weil die Änderung für Nutzer nicht sichtbar ist.
+**Betriebshandbuch:** Kapitel 4 hat einen Hinweis für die erste Version nach 1.3.1 bekommen: was die Meldung bedeutet und die drei Schritte zur Wiederherstellung.
+
+## Tore
+
+- API-Tests komplett: **84 Dateien, 1364 Tests, grün**, einschließlich `rls-access-inventory.spec.ts` mit 30 Tests.
+- Web-Tests komplett: **91 Dateien, 865 Tests, grün**, auch gedrosselt auf 2 Kerne.
+- `pnpm turbo run type-check lint`: **9/9 Aufgaben erfolgreich**.
+- Biome-Warnungen: **web 53** (Grenze 53), **api 82** (Grenze 82).
+
+## Abweichungen vom Plan
+
+1. **[Rule 3 – blockierend] Todo-Ordner:** Den Ordner `.planning/todos/done/` aus dem Plan gibt es nicht, die Ablage im Projekt heißt `.planning/todos/completed/`. Beide Todos liegen deshalb dort, jeweils mit einem Nachtrag „Erledigt in quick-260924-m4n“.
+2. **[Rule 1 – Bug] Weg zurück nach einem Abbruch:** Die Meldung der Schutzprüfung rät, zuerst 1.3.1 laufen zu lassen. Allein das hätte aber nicht funktioniert, weil 1.3.1 danach mit P3009 abbricht. Der fehlende Zwischenschritt steht jetzt im Betriebshandbuch und im Kopfkommentar der Migration, und ich habe ihn durchgespielt.
+3. **[Rule 1 – Bug] Upload-Ablauf:** Mit `storagePath` als Pflichtfeld hätte der bisherige Ablauf (Zeile ohne Pfad anlegen, Pfad nachtragen) an der Datenbank scheitern müssen. Deshalb vergibt der Dienst die UUID jetzt selbst.
+4. **Zusätzliche Tests entfallen:** Neben 18 und 21–23 sind auch 10b und 10c weg (siehe oben).
+5. **Mehr Marktplatz-Dateien umgestellt:** Neben `tenant-selector` sind auch `marketplace.test.tsx` und `marketplace-filters.test.tsx` umgestellt. Es ist dasselbe Muster im selben Ordner.
+6. **Drift in der Klassifikation nachgeholt:** Die Zeilen `favorites` und `dashboard` stimmten schon vorher nicht mit der Messung überein. Beides ist jetzt nachgeholt und im Dokument begründet.
+
+## Offen / für dich
+
+- Live konnte ich von hier aus nicht prüfen. Die nächste Freigabe nach 1.3.1 setzt voraus, dass live einmal auf 1.3.1 gelaufen ist. Wenn nicht, bricht die Migration mit einer klaren Meldung ab, der Weg zurück steht in Kapitel 4.
+- Optional nach dem Einspielen auf alpha und live: `VACUUM FULL "DashboardImage";`, damit PostgreSQL den Platz der alten Bilddaten tatsächlich an das Dateisystem zurückgibt.
+
+## Self-Check: PASSED
+
+- FOUND: apps/api/prisma/migrations/20260924120000_dashboard_image_drop_data/migration.sql
+- FOUND: .planning/todos/completed/2026-09-23-flackernder-test-tenant-selector-zeitueberschreitung.md
+- FOUND: .planning/todos/completed/2026-09-22-dashboard-image-data-spalte-entfernen.md
+- FOUND: b10734f, dd54ec5 (gemessen: `git rev-list --count dd09c08..HEAD` = 2)
@@ -80,3 +80,21 @@ nichts. Der Gewinn der Umstellung (kleiner `pg_dump`) ist bereits da, weil
 neue Uploads keine Bytes mehr in die Zeile schreiben. Nur die Bytes der
 ALTEN Bilder bleiben bis dahin doppelt vorhanden — einmal in der Datei,
 einmal in der Spalte.
+
+## Erledigt in quick-260924-m4n (24.09.2026)
+
+- Migration heißt `20260924120000_dashboard_image_drop_data` (nicht
+  `20260922120100`: sie muss hinter allen vorhandenen Migrationen liegen).
+  Sie prüft zuerst, dass keine Zeile ohne `storagePath` existiert, und bricht
+  sonst mit Meldung ab, bevor sie etwas ändert; `row_security` ist für die
+  Prüfung aus, damit ein Eigentümer ohne BYPASSRLS nicht still 0 Zeilen sieht
+  (lokal nachgewiesen). Danach `storagePath` NOT NULL, `DROP COLUMN "data"`,
+  `DROP POLICY IF EXISTS system_read_policy ON "DashboardImage"`.
+- Dienst: Bootstrap-Umzug, `forSystem()` und die Selbstheilung aus `data`
+  entfernt; der Upload vergibt die UUID selbst und legt die Zeile gleich mit
+  Pfad an. Erlaubnisliste, Tests (10b, 10c, 18, 21–23 entfallen) und
+  Zugriffsklassifikation nachgezogen (Zahlen mit der Gate-Schleife gemessen).
+- Wiederherstellungsweg nach einem Abbruch (fehlgeschlagene Migration als
+  zurückgenommen vermerken, 1.3.1 laufen lassen, erneut einspielen) in
+  `docs/anleitung-betrieb.md` Kapitel 4, in einer Wegwerf-Datenbank
+  durchgespielt.
@@ -49,3 +49,17 @@ auslöst. Der Fall wiederholt sich also, nicht zufällig.
 Die drei parallelen Pipelines abschalten: der Lauf auf `main` und der auf dem
 Tag prüfen unterschiedliche Dinge, und der `live`-Lauf ist die Absicherung,
 dass der Zweig für sich genommen grün ist.
+
+## Erledigt in quick-260924-m4n (24.09.2026)
+
+- Ursache: `TenantContextSelector` und die Marktplatzseite wurden per
+  `await import(...)` INNERHALB der Tests geladen. Das Laden und Umwandeln der
+  Module zählte damit in die 5-s-Frist des ersten Tests — unter Läuferlast
+  (drei Pipelines je Freigabe) reicht das, um die Frist zu reißen.
+- Behoben: statische Importe (vi.mock wird darüber gehoben), der Doppelfall
+  SUPER_ADMIN/ADMIN in zwei `it` aufgetrennt (der ADMIN-Fall prüft zusätzlich,
+  dass kein Abruf passiert). Dieselbe Umstellung in `marketplace.test.tsx` und
+  `marketplace-filters.test.tsx`; dort ist userEvent zusätzlich an die falsche
+  Uhr gekoppelt (`advanceTimers`). Kein globales `testTimeout`.
+- Messung (ganze Web-Suite, lokal und auf 2 Kerne gedrosselt): kein Test über
+  2 s; der langsamste lag gedrosselt bei rund 1,3 s.
@@ -4,6 +4,8 @@ Diese Liste beschreibt in einfachen Worten, was sich von Version zu Version an T

 ## Unveröffentlicht

+## 1.4.0 – 2026-09-25
+
 ### Neu

 - Das Dashboard hat jetzt mehrere Reiter: Sie können beliebig viele Dashboards anlegen, jeder mit eigenen Kacheln und eigener Anordnung, per Ziehen umsortierbar, wobei der erste Reiter beim Öffnen geladen wird. Ihre vorhandenen Kacheln bleiben dabei unverändert auf dem ersten Reiter liegen.
@@ -0,0 +1,53 @@
+-- quick-260924-m4n — Stufe 2 der Umstellung aus quick-260922-hk4: die alte
+-- Bildspalte "data" faellt, "storagePath" wird Pflicht.
+--
+-- Stufe 1 (20260922120000_dashboard_image_to_disk) hat "storagePath"
+-- angelegt und "data" nur NULLbar gemacht, weil `prisma migrate deploy` VOR
+-- dem Anwendungsstart laeuft: ein sofortiges DROP haette die Bytes
+-- vernichtet, bevor der Bootstrap-Umzug (DashboardImagesService,
+-- Version 1.3.1) sie auf die Platte schreiben konnte (T-HK4-03). Dieser
+-- Umzug ist mit dieser Version aus dem Code entfernt.
+--
+-- SCHUTZ VOR DATENVERLUST: gibt es noch eine Zeile ohne "storagePath", hat
+-- der Umzug auf diesem Server nie gearbeitet (der Server hat eine Version
+-- < 1.3.1 uebersprungen). Dann bricht die Migration mit einer Meldung ab,
+-- BEVOR irgendetwas geaendert wird (die Pruefung steht vor jeder Aenderung),
+-- `migrate deploy` stoppt, die API startet nicht. Abhilfe
+-- (docs/anleitung-betrieb.md, Kapitel 4, gemessen in einer Wegwerf-DB):
+-- den fehlgeschlagenen Eintrag in "_prisma_migrations" als zurueckgenommen
+-- vermerken (sonst verweigert auch 1.3.1 den Start mit P3009), dann eine
+-- Version >= 1.3.1 einmal starten lassen (der Umzug laeuft beim Start von
+-- selbst), danach erneut auf diese Version gehen.
+--
+-- ZEILENSCHUTZ (RLS) UND DIE PRUEFUNG: "DashboardImage" hat FORCE ROW LEVEL
+-- SECURITY (20260921120000). FORCE wirkt auch auf den Tabelleneigentuemer —
+-- ohne Sitzungsvariablen wuerde die Mandantenregel dem EXISTS jede Zeile
+-- wegfiltern, die Pruefung saehe 0 Zeilen und der Schutz waere stumm
+-- wirkungslos. Heute laeuft die Migration als `tessera` (Superuser mit
+-- BYPASSRLS, gemessen 24.09.2026 lokal) und sieht alles. Fuer den Fall, dass
+-- sie spaeter ueber TESSERA_MIGRATE_DATABASE_URL als Eigentuemer OHNE
+-- BYPASSRLS laeuft (docs/mandantentrennung-datenbankrolle.md), schaltet die
+-- Pruefung `row_security` fuer diese Transaktion ab: PostgreSQL filtert dann
+-- NICHT still, sondern bricht mit "query would be affected by row-level
+-- security policy" ab. Die Pruefung sieht also entweder alle Zeilen oder
+-- scheitert laut — nie "0 gesehen, weiter".
+DO $$
+BEGIN
+  PERFORM set_config('row_security', 'off', true);
+  IF EXISTS (SELECT 1 FROM "DashboardImage" WHERE "storagePath" IS NULL) THEN
+    RAISE EXCEPTION 'DashboardImage: es gibt noch Zeilen ohne storagePath — Umzug (quick-260922-hk4) zuerst mit einer Version >= 1.3.1 laufen lassen, dann erneut deployen';
+  END IF;
+  PERFORM set_config('row_security', 'on', true);
+END $$;
+
+ALTER TABLE "DashboardImage" ALTER COLUMN "storagePath" SET NOT NULL;
+ALTER TABLE "DashboardImage" DROP COLUMN "data";
+
+-- Die Systemkontext-Leseregel aus 20260922120000 hatte genau einen Zweck:
+-- den Bootstrap-Umzug, der ueber ALLE Mandanten las (`forSystem()`). Der
+-- Umzug ist entfernt, niemand liest "DashboardImage" mehr systemgebunden —
+-- eine offene Leseregel ohne Leser waere nur Angriffsflaeche. Es bleibt
+-- allein "tenant_isolation_policy" (Mandant UND Benutzer). IF EXISTS, damit
+-- die Migration auch auf einer Datenbank durchlaeuft, auf der die Regel von
+-- Hand entfernt wurde.
+DROP POLICY IF EXISTS system_read_policy ON "DashboardImage";
@@ -265,14 +265,11 @@ model DashboardImage {
  originalName String
  mimeType     String
  size         Int
-  // Stufe 1 der zweistufigen Umstellung (Migration 20260922120000): die
-  // Spalte bleibt NULLbar stehen, bis der Bootstrap-Umzug auf allen Servern
-  // gelaufen ist. Neue Uploads schreiben sie nie. DROP kommt mit
-  // 20260922120100 (vorgemerkt in .planning/todos/pending/).
-  data         Bytes?
-  // Relativ zur Monorepo-Wurzel; NULL nur fuer Zeilen, die der
-  // Bootstrap-Umzug noch nicht angefasst hat. Wird in Stufe 2 NOT NULL.
-  storagePath  String?
+  // Relativ zur Monorepo-Wurzel, z. B.
+  // "user-files/dashboard-images/<userId>/<id>.png". Die Bytes liegen seit
+  // quick-260922-hk4 im Dateibereich; die alte Spalte `data` ist mit Stufe 2
+  // (Migration 20260924120000_dashboard_image_drop_data) entfernt.
+  storagePath  String
  createdAt    DateTime @default(now())

  @@index([userId])
@@ -4,21 +4,21 @@ import * as path from 'node:path';
 import { afterAll, beforeAll, beforeEach, describe, expect, it, vi } from 'vitest';

 /**
- * Bindung an forTenant()/forSystem() — dasselbe Muster wie
- * dashboard.service.spec.ts (260910-krx): der gebundene Klient ist ein
- * ZWEITES, von `prisma` unterscheidbares Objekt ueber DEMSELBEN Speicher,
- * das protokolliert, welche Aufrufe ueber ihn liefen. Ein vergessener
- * Bindungsaufruf faellt damit auf (`prisma.dashboardImage` waere dann ohne
- * Protokoll-Eintrag). Seit quick-260922-hk4 gibt es einen zweiten
- * Klienten-Typ: der Systemkontext des Bootstrap-Umzugs (`forSystem()`,
- * liest ueber ALLE Mandanten, Muster dkv.service.ts) — das Protokoll
- * unterscheidet beide ueber `via`.
+ * Bindung an forTenant() — dasselbe Muster wie dashboard.service.spec.ts
+ * (260910-krx): der gebundene Klient ist ein ZWEITES, von `prisma`
+ * unterscheidbares Objekt ueber DEMSELBEN Speicher, das protokolliert,
+ * welche Aufrufe ueber ihn liefen. Ein vergessener Bindungsaufruf faellt
+ * damit auf (`prisma.dashboardImage` waere dann ohne Protokoll-Eintrag).
+ * `forSystem` steht als Spion daneben: seit Stufe 2 (quick-260924-m4n,
+ * Bootstrap-Umzug entfernt) darf der Dienst ihn nie mehr rufen.
 */
 vi.mock('../prisma/prisma-tenant.extension', () => ({
  forTenant: vi.fn((prisma: FakePrisma, tenantId: string, userId?: string) =>
    prisma.__makeBoundClient(tenantId, userId),
  ),
-  forSystem: vi.fn((prisma: FakePrisma) => prisma.__makeSystemClient()),
+  forSystem: vi.fn(() => {
+    throw new Error('forSystem darf der Bilderdienst seit Stufe 2 nicht mehr rufen');
+  }),
 }));

 import { BadRequestException, InternalServerErrorException, NotFoundException } from '@nestjs/common';
@@ -39,15 +39,18 @@ import { DashboardImagesService } from './dashboard-images.service';
 * `forTenant(prisma, tenantId, userId)` mit dem Benutzer als drittem
 * Argument aufruft.
 *
- * Dazu die Grenze Dienst -> Dateibereich (hk4, Tests 13-22): KEIN
+ * Dazu die Grenze Dienst -> Dateibereich (hk4, Tests 13-20): KEIN
 * `fs`-Mock, sondern ein echtes Verzeichnis unter `os.tmpdir()` (Muster
 * desktop.service.spec.ts) ueber den Testschalter
 * `DASHBOARD_IMAGES_DIR` — der Dienst schreibt und liest wirklich.
 * Geprueft werden Ablageort und Dateiname (IMMER die UUID der Zeile plus
 * die Endung aus dem ERKANNTEN Typ, NIE `originalName`, T-HK4-01), das
 * Zuruecknehmen der Zeile bei fehlgeschlagenem Schreiben (T-HK4-04), 404
- * bei fehlender Datei, das Mitloeschen der Datei und der automatische
- * Umzug beim Start (T-HK4-03).
+ * bei fehlender Datei und das Mitloeschen der Datei.
+ *
+ * Stufe 2 (quick-260924-m4n): die Spalte `data` ist weg, `storagePath` ist
+ * Pflicht. Mit ihr entfallen die Faelle 10b/10c (Selbstheilung aus `data`),
+ * 18 (Zeile ohne `storagePath`) und 21-23 (Bootstrap-Umzug).
 */

 interface ImageRow {
@@ -57,13 +60,11 @@ interface ImageRow {
  originalName: string;
  mimeType: string;
  size: number;
-  data: Uint8Array | null;
-  storagePath: string | null;
+  storagePath: string;
  createdAt: Date;
 }

 interface BoundCall {
-  via: 'tenant' | 'system';
  tenantId: string;
  userId: string | undefined;
  model: string;
@@ -77,7 +78,6 @@ interface FakePrisma {
  __rows: ImageRow[];
  __boundCallLog: BoundCall[];
  __makeBoundClient(tenantId: string, userId?: string): { dashboardImage: ModelMethods };
-  __makeSystemClient(): { dashboardImage: ModelMethods };
 }

 const PNG = Buffer.from([0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0, 0, 0, 13]);
@@ -102,16 +102,21 @@ afterAll(() => {
  }
 });

+/**
+ * Eine Zeile OHNE Datei auf der Platte; der Pfad folgt der Form, die der
+ * Dienst selbst vergibt (`storagePath` ist seit Stufe 2 Pflicht).
+ */
 function makeRow(overrides: Partial<ImageRow> = {}): ImageRow {
+  const id = overrides.id ?? 'img-1';
+  const userId = overrides.userId ?? 'user-1';
  return {
-    id: overrides.id ?? 'img-1',
-    userId: overrides.userId ?? 'user-1',
+    id,
+    userId,
    tenantId: overrides.tenantId ?? 'tenant-1',
    originalName: overrides.originalName ?? 'foto.png',
    mimeType: overrides.mimeType ?? 'image/png',
    size: overrides.size ?? PNG.length,
-    data: overrides.data === undefined ? null : overrides.data,
-    storagePath: overrides.storagePath === undefined ? null : overrides.storagePath,
+    storagePath: overrides.storagePath ?? `user-files/dashboard-images/${userId}/${id}.png`,
    createdAt: overrides.createdAt ?? new Date('2026-01-01'),
  };
 }
@@ -123,11 +128,10 @@ function makeRow(overrides: Partial<ImageRow> = {}): ImageRow {
 */
 function makeStoredRow(overrides: Partial<ImageRow> = {}, bytes: Buffer = PNG): ImageRow {
  const row = makeRow(overrides);
-  const relative = `user-files/dashboard-images/${row.userId}/${row.id}.png`;
  const absolute = path.join(imagesDir, row.userId, `${row.id}.png`);
  fs.mkdirSync(path.dirname(absolute), { recursive: true });
  fs.writeFileSync(absolute, bytes);
-  return { ...row, storagePath: overrides.storagePath === undefined ? relative : overrides.storagePath };
+  return row;
 }

 function storedFile(userId: string, id: string, ext = 'png'): string {
@@ -148,7 +152,7 @@ function makeFakePrisma(rows: ImageRow[] = []): FakePrisma {
  const dashboardImage: ModelMethods = {
    findMany: vi.fn(async (raw: unknown) => {
      const args = raw as {
-        where: { tenantId?: string; userId?: string; storagePath?: string | null };
+        where: { tenantId?: string; userId?: string };
        select?: Record<string, boolean>;
      };
      const where = args.where ?? {};
@@ -156,9 +160,6 @@ function makeFakePrisma(rows: ImageRow[] = []): FakePrisma {
        .filter((r) => {
          if (where.tenantId !== undefined && r.tenantId !== where.tenantId) return false;
          if (where.userId !== undefined && r.userId !== where.userId) return false;
-          if ('storagePath' in where && where.storagePath === null && r.storagePath !== null) {
-            return false;
-          }
          return true;
        })
        .slice()
@@ -195,11 +196,11 @@ function makeFakePrisma(rows: ImageRow[] = []): FakePrisma {
    }),
  };

-  function wrap(via: 'tenant' | 'system', tenantId: string, userId?: string) {
+  function wrap(tenantId: string, userId?: string) {
    const wrapped: ModelMethods = {};
    for (const method of Object.keys(dashboardImage)) {
      wrapped[method] = async (...args: unknown[]) => {
-        boundCallLog.push({ via, tenantId, userId, model: 'dashboardImage', method });
+        boundCallLog.push({ tenantId, userId, model: 'dashboardImage', method });
        return dashboardImage[method](...args);
      };
    }
@@ -211,10 +212,7 @@ function makeFakePrisma(rows: ImageRow[] = []): FakePrisma {
    __rows: rows,
    __boundCallLog: boundCallLog,
    __makeBoundClient(tenantId: string, userId?: string) {
-      return wrap('tenant', tenantId, userId);
-    },
-    __makeSystemClient() {
-      return wrap('system', '', undefined);
+      return wrap(tenantId, userId);
    },
  };
  return fake;
@@ -340,37 +338,6 @@ describe('DashboardImagesService (quick-260921-pi9)', () => {
    expect(Buffer.from(result.data).equals(PNG)).toBe(true);
  });

-  it('Test 10b: getBytes — Datei fehlt, aber die alte Spalte `data` traegt die Bytes noch: wiederherstellen statt 404', async () => {
-    // Fall aus dem Browser-Rundgang 22.09.2026: ein `pg_dump` von vor dem Umzug
-    // traegt die Bytes noch, das Volume `user-files` wird getrennt gesichert —
-    // wer nur den Abzug zurueckspielt, haette sonst Zeilen ohne Datei.
-    const row = makeRow({
-      id: 'img-alt',
-      data: PNG,
-      storagePath: 'user-files/dashboard-images/user-1/img-alt.png',
-    });
-    const prisma = makeFakePrisma([row]);
-    expect(fs.existsSync(storedFile('user-1', 'img-alt'))).toBe(false);
-
-    const result = await makeService(prisma).getBytes('img-alt', 'user-1', 'tenant-1');
-
-    expect(Buffer.from(result.data).equals(PNG)).toBe(true);
-    expect(fs.existsSync(storedFile('user-1', 'img-alt'))).toBe(true);
-    expect(fs.readFileSync(storedFile('user-1', 'img-alt')).equals(PNG)).toBe(true);
-  });
-
-  it('Test 10c: getBytes — Datei fehlt UND `data` ist leer -> 404', async () => {
-    const row = makeRow({
-      id: 'img-weg',
-      data: null,
-      storagePath: 'user-files/dashboard-images/user-1/img-weg.png',
-    });
-    const prisma = makeFakePrisma([row]);
-    await expect(makeService(prisma).getBytes('img-weg', 'user-1', 'tenant-1')).rejects.toThrow(
-      NotFoundException,
-    );
-  });
-
  it('Test 11: remove — eigenes Bild wird geloescht und { id } geliefert; fremdes (Benutzer ODER Mandant) -> 404 ohne Loeschung', async () => {
    const prisma = makeFakePrisma([
      makeStoredRow({ id: 'eigen' }),
@@ -399,13 +366,13 @@ describe('DashboardImagesService (quick-260921-pi9)', () => {
      expect(call[1]).toBe('tenant-1');
      expect(call[2]).toBe('user-1');
    }
-    // Jeder Modellaufruf steht im Protokoll des gebundenen Klienten; der
-    // Upload schreibt den Ablageort in einem zweiten Schritt nach, weil die
-    // UUID der Zeile erst nach `create` feststeht (hk4).
+    // Jeder Modellaufruf steht im Protokoll des gebundenen Klienten. Seit
+    // Stufe 2 vergibt der Dienst die UUID selbst und legt die Zeile gleich
+    // MIT Pfad an — kein nachtraegliches `update` mehr (m4n).
    const methods = prisma.__boundCallLog.map((c) => c.method);
-    expect(methods).toEqual(['findMany', 'count', 'create', 'update', 'findUnique', 'findUnique', 'delete']);
+    expect(methods).toEqual(['findMany', 'count', 'create', 'findUnique', 'findUnique', 'delete']);
+    expect(vi.mocked(forSystem)).not.toHaveBeenCalled();
    for (const c of prisma.__boundCallLog) {
-      expect(c.via).toBe('tenant');
      expect(c.tenantId).toBe('tenant-1');
      expect(c.userId).toBe('user-1');
    }
@@ -421,10 +388,15 @@ describe('DashboardImagesService — Ablage im Dateibereich (quick-260922-hk4)',
    expect(fs.existsSync(onDisk)).toBe(true);
    expect(fs.readFileSync(onDisk).equals(PNG)).toBe(true);
    expect(prisma.__rows[0].storagePath).toBe(`user-files/dashboard-images/user-1/${result.id}.png`);
-    // Die Bytes gehen NICHT mehr in die Zeile (das ist der ganze Zweck).
-    expect(prisma.__rows[0].data).toBeNull();
+    // Die Zeile traegt den Pfad schon beim Anlegen (Pflichtfeld seit Stufe 2),
+    // die Kennung ist eine vom Dienst vergebene UUID, und Bytes gehen nie in
+    // die Zeile.
    const createArgs = vi.mocked(prisma.dashboardImage.create).mock.calls[0][0] as { data: Record<string, unknown> };
-    expect(createArgs.data.data).toBeUndefined();
+    expect(createArgs.data.storagePath).toBe(`user-files/dashboard-images/user-1/${result.id}.png`);
+    expect(createArgs.data.id).toBe(result.id);
+    expect(result.id).toMatch(/^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/);
+    expect(createArgs.data).not.toHaveProperty('data');
+    expect(prisma.dashboardImage.update).not.toHaveBeenCalled();
  });

  it('Test 14: der Dateiname ist IMMER die UUID plus die Endung des ERKANNTEN Typs — originalName kommt nie im Pfad vor (T-HK4-01)', async () => {
@@ -435,7 +407,7 @@ describe('DashboardImagesService — Ablage im Dateibereich (quick-260922-hk4)',

    // Erkannt wurde JPEG (Magic Bytes), also .jpg — nicht .png aus dem Namen.
    expect(result.mimeType).toBe('image/jpeg');
-    const stored = prisma.__rows[0].storagePath ?? '';
+    const stored = prisma.__rows[0].storagePath;
    expect(stored).toBe(`user-files/dashboard-images/user-1/${result.id}.jpg`);
    expect(stored).not.toContain('passwd');
    expect(stored).not.toContain('..');
@@ -462,10 +434,10 @@ describe('DashboardImagesService — Ablage im Dateibereich (quick-260922-hk4)',
    }
  });

-  it('Test 16: getBytes liest den Dateiinhalt (nicht die Zeile) — auch wenn in der Zeile noch alte Bytes stehen', async () => {
-    const prisma = makeFakePrisma([makeStoredRow({ id: 'img-1', data: Uint8Array.from(TEXT) }, PNG)]);
-    const result = await makeService(prisma).getBytes('img-1', 'user-1', 'tenant-1');
-    expect(Buffer.from(result.data).equals(PNG)).toBe(true);
+  it('Test 16: getBytes liest den Dateiinhalt unter dem Pfad aus der Zeile', async () => {
+    const prisma = makeFakePrisma([makeStoredRow({ id: 'img-16' }, JPEG)]);
+    const result = await makeService(prisma).getBytes('img-16', 'user-1', 'tenant-1');
+    expect(Buffer.from(result.data).equals(JPEG)).toBe(true);
  });

  it('Test 17: Zeile vorhanden, Datei fehlt -> NotFoundException (die Kachel zeigt „Bild nicht verfügbar")', async () => {
@@ -479,11 +451,6 @@ describe('DashboardImagesService — Ablage im Dateibereich (quick-260922-hk4)',
    );
  });

-  it('Test 18: Zeile ohne storagePath (noch nicht umgezogen) -> NotFoundException statt Absturz', async () => {
-    const prisma = makeFakePrisma([makeRow({ id: 'img-1', data: Uint8Array.from(PNG) })]);
-    await expect(makeService(prisma).getBytes('img-1', 'user-1', 'tenant-1')).rejects.toThrow(NotFoundException);
-  });
-
  it('Test 19: remove loescht Zeile UND Datei', async () => {
    const prisma = makeFakePrisma([makeStoredRow({ id: 'weg' })]);
    const onDisk = storedFile('user-1', 'weg');
@@ -504,69 +471,3 @@ describe('DashboardImagesService — Ablage im Dateibereich (quick-260922-hk4)',
    expect(prisma.__rows).toHaveLength(0);
  });
 });
-
-describe('DashboardImagesService — Umzug beim Start (quick-260922-hk4, T-HK4-03)', () => {
-  it('Test 21: onApplicationBootstrap schreibt die Bytes alter Zeilen auf die Platte und setzt storagePath — systemgebunden lesen, je Zeile mandantengebunden schreiben', async () => {
-    const alt = makeRow({ id: 'alt-1', data: Uint8Array.from(PNG) });
-    const fremderMandant = makeRow({
-      id: 'alt-2',
-      userId: 'user-9',
-      tenantId: 'tenant-2',
-      mimeType: 'image/jpeg',
-      data: Uint8Array.from(JPEG),
-    });
-    const schonUmgezogen = makeStoredRow({ id: 'neu-1' });
-    const prisma = makeFakePrisma([alt, fremderMandant, schonUmgezogen]);
-
-    await makeService(prisma).onApplicationBootstrap();
-
-    expect(fs.readFileSync(storedFile('user-1', 'alt-1')).equals(PNG)).toBe(true);
-    expect(fs.readFileSync(storedFile('user-9', 'alt-2', 'jpg')).equals(JPEG)).toBe(true);
-    expect(prisma.__rows[0].storagePath).toBe('user-files/dashboard-images/user-1/alt-1.png');
-    expect(prisma.__rows[1].storagePath).toBe('user-files/dashboard-images/user-9/alt-2.jpg');
-
-    // Gelesen wird EINMAL ueber den Systemkontext, geschrieben je Zeile
-    // ueber einen Klienten, der auf Mandant UND Benutzer DIESER Zeile
-    // gebunden ist.
-    expect(vi.mocked(forSystem)).toHaveBeenCalledTimes(1);
-    expect(vi.mocked(forSystem).mock.calls[0][0]).toBe(prisma);
-    const leseAufrufe = prisma.__boundCallLog.filter((c) => c.via === 'system');
-    expect(leseAufrufe.map((c) => c.method)).toEqual(['findMany']);
-    const findManyArgs = vi.mocked(prisma.dashboardImage.findMany).mock.calls[0][0] as {
-      where: Record<string, unknown>;
-    };
-    expect(findManyArgs.where.storagePath).toBeNull();
-
-    expect(vi.mocked(forTenant)).toHaveBeenCalledTimes(2);
-    expect(vi.mocked(forTenant).mock.calls[0].slice(1)).toEqual(['tenant-1', 'user-1']);
-    expect(vi.mocked(forTenant).mock.calls[1].slice(1)).toEqual(['tenant-2', 'user-9']);
-    const schreibAufrufe = prisma.__boundCallLog.filter((c) => c.via === 'tenant');
-    expect(schreibAufrufe.map((c) => c.method)).toEqual(['update', 'update']);
-
-    // Die bereits umgezogene Zeile wird nicht angefasst.
-    expect(prisma.__rows[2].storagePath).toBe('user-files/dashboard-images/user-1/neu-1.png');
-  });
-
-  it('Test 22: ohne offene Zeilen bleibt der Start still — kein Schreibzugriff, keine Bindung je Mandant', async () => {
-    const prisma = makeFakePrisma([makeStoredRow({ id: 'neu-2' })]);
-    await makeService(prisma).onApplicationBootstrap();
-
-    expect(vi.mocked(forSystem)).toHaveBeenCalledTimes(1);
-    expect(vi.mocked(forTenant)).not.toHaveBeenCalled();
-    expect(prisma.dashboardImage.update).not.toHaveBeenCalled();
-  });
-
-  it('Test 23: der Umzug ist wiederholbar — ein zweiter Lauf findet nichts mehr und ueberschreibt nichts', async () => {
-    const prisma = makeFakePrisma([makeRow({ id: 'alt-3', data: Uint8Array.from(PNG) })]);
-    const service = makeService(prisma);
-    await service.onApplicationBootstrap();
-    const ersterStand = fs.statSync(storedFile('user-1', 'alt-3')).mtimeMs;
-
-    vi.mocked(forTenant).mockClear();
-    await service.onApplicationBootstrap();
-
-    expect(vi.mocked(forTenant)).not.toHaveBeenCalled();
-    expect(fs.statSync(storedFile('user-1', 'alt-3')).mtimeMs).toBe(ersterStand);
-    expect(prisma.__rows[0].storagePath).toBe('user-files/dashboard-images/user-1/alt-3.png');
-  });
-});
@@ -4,12 +4,12 @@ import {
  InternalServerErrorException,
  Logger,
  NotFoundException,
-  type OnApplicationBootstrap,
 } from '@nestjs/common';
+import { randomUUID } from 'node:crypto';
 import * as fs from 'node:fs/promises';
 import * as path from 'node:path';
 import type { AuthUser, UploadedFileLike } from '../auth/types/auth-user';
-import { forSystem, forTenant } from '../prisma/prisma-tenant.extension';
+import { forTenant } from '../prisma/prisma-tenant.extension';
 import { PrismaService } from '../prisma/prisma.service';
 import {
  DASHBOARD_IMAGE_MAX_COUNT,
@@ -46,13 +46,22 @@ import {
 * (T-HK4-02); das Volume haengt in keinem Webserver.
 *
 * HALBE ZUSTAENDE (T-HK4-04, bewusst benannt): beim Upload entsteht ZUERST
- * die Zeile (erst danach steht die UUID fest), dann die Datei; scheitert
- * das Schreiben, wird die Zeile wieder geloescht und 500 geworfen. Beim
+ * die Zeile (mit der vom Dienst vergebenen UUID und dem daraus gebildeten
+ * Pfad), dann die Datei; scheitert das Schreiben, wird die Zeile wieder
+ * geloescht und 500 geworfen. Beim
 * Loeschen faellt ZUERST die Zeile, ein Fehler beim Entfernen der Datei
 * wird protokolliert und geschluckt — eine Dateileiche ist harmloser als
 * eine haengende Loeschung. Fehlt die Datei beim Lesen, ist die Antwort
 * 404 und die Kachel zeigt „Bild nicht verfügbar".
 *
+ * STUFE 2 DER UMSTELLUNG (quick-260924-m4n, Migration
+ * 20260924120000_dashboard_image_drop_data): die alte Spalte `data` ist
+ * weg, `storagePath` ist Pflicht. Mit ihr sind der Bootstrap-Umzug
+ * (`onApplicationBootstrap()` mit `forSystem()`) und die Selbstheilung aus
+ * `data` in `getBytes` entfallen — der Umzug hatte auf allen Servern seine
+ * Arbeit getan, die Migration bricht ab, falls doch noch eine Zeile ohne
+ * Pfad existiert.
+ *
 * Besitz: ein Bild gehoert dem hochladenden Benutzer (gleicher Mandant UND
 * gleicher Benutzer). Die Besitzpruefung in `getBytes`/`remove` (Zeile
 * holen, `userId` UND `tenantId` gegen den Sitzungsnachweis vergleichen,
@@ -145,6 +154,33 @@ function relativeStoragePath(userId: string, id: string, extension: string): str
  return `${STORAGE_PREFIX}${userId}/${id}.${extension}`;
 }

+/**
+ * Servergenerierter relativer Pfad fuer ein neues Bild: UUID der Zeile plus
+ * Endung aus dem ERKANNTEN Typ (T-HK4-01).
+ */
+function storagePathFor(userId: string, id: string, mimeType: string): string {
+  const extension = extensionFor(mimeType);
+  if (extension === null) {
+    // detectImageMime liefert nur die vier bekannten Typen; ein anderer
+    // Wert hier waere ein Programmierfehler, kein Benutzerfehler.
+    throw new InternalServerErrorException(`Unbekannter Bildtyp '${mimeType}'`);
+  }
+  return relativeStoragePath(userId, id, extension);
+}
+
+/**
+ * Schreibt die Bytes an den servergenerierten Ort. Der Ordner je Benutzer
+ * entsteht dabei (`recursive: true`).
+ */
+async function writeImageFile(storagePath: string, bytes: Uint8Array): Promise<void> {
+  const absolute = absoluteImagePath(storagePath);
+  if (absolute === null) {
+    throw new Error(`Ungueltiger Ablageort '${storagePath}'`);
+  }
+  await fs.mkdir(path.dirname(absolute), { recursive: true });
+  await fs.writeFile(absolute, bytes);
+}
+
 /**
 * Wandelt den in der Zeile gespeicherten Pfad in einen absoluten Pfad im
 * Bilderverzeichnis um — und gibt `null` zurueck, sobald der Wert nicht
@@ -162,69 +198,11 @@ function absoluteImagePath(storagePath: string): string | null {
 }

@Injectable()
-export class DashboardImagesService implements OnApplicationBootstrap {
+export class DashboardImagesService {
  private readonly logger = new Logger(DashboardImagesService.name);

  constructor(private readonly prisma: PrismaService) {}

-  /**
-   * Einmaliger Umzug der Bestandsbilder beim Start (T-HK4-03), damit der
-   * Betreiber nichts von Hand ausfuehren muss.
-   *
-   * ZWEISTUFIG, und deshalb steht die Spalte `data` noch im Schema: die
-   * SQL-Migration 20260922120000 legt nur `storagePath` an und macht `data`
-   * NULLbar; `migrate deploy` laeuft VOR dem Anwendungsstart, ein sofortiges
-   * DROP haette die Bytes vernichtet, bevor dieser Umzug sie lesen konnte.
-   * Die DROP-Migration 20260922120100 kommt erst, wenn alpha UND live
-   * einmal mit einer Version >= dieser gelaufen sind (vorgemerkt in
-   * `.planning/todos/pending/`).
-   *
-   * GELESEN WIRD SYSTEMGEBUNDEN (`forSystem()`, Muster
-   * `DkvService.loadActiveConfigsForScheduler()`): der Umzug betrifft alle
-   * Mandanten, ein Startpfad hat keinen Mandanten im Ruecken. Geschrieben
-   * wird je Zeile MANDANTENGEBUNDEN (`forTenant()` mit Mandant UND Benutzer
-   * dieser Zeile) — unter Systemkontext ist nur Lesen geoeffnet
-   * (`system_read_policy ... FOR SELECT`, fuer `DashboardImage` angelegt in
-   * 20260922120000). Einmal-lesen-viele-bedienen, genau wie beim
-   * DKV-Planer.
-   *
-   * Wiederholbar: die Abfrage nimmt nur Zeilen ohne `storagePath`, ein
-   * zweiter Lauf findet nichts mehr. Eine einzelne fehlgeschlagene Zeile
-   * wird protokolliert und haelt den Start nicht auf.
-   */
-  async onApplicationBootstrap(): Promise<void> {
-    const systemPrisma = forSystem(this.prisma);
-    const pending = await systemPrisma.dashboardImage.findMany({
-      where: { storagePath: null },
-      select: { id: true, userId: true, tenantId: true, mimeType: true, data: true },
-      orderBy: { createdAt: 'asc' },
-    });
-
-    let moved = 0;
-    for (const row of pending) {
-      if (row.data === null) continue;
-      try {
-        const storagePath = await this.writeImageFile(row.userId, row.id, row.mimeType, row.data);
-        const tenantPrisma = forTenant(this.prisma, row.tenantId, row.userId);
-        await tenantPrisma.dashboardImage.update({
-          where: { id: row.id },
-          data: { storagePath },
-        });
-        moved += 1;
-      } catch (error) {
-        this.logger.error(
-          `Bilderrahmen-Bild ${row.id} konnte nicht auf die Festplatte umgezogen werden: ${
-            error instanceof Error ? error.message : String(error)
-          }`,
-        );
-      }
-    }
-
-    if (moved > 0) {
-      this.logger.log(`${moved} Bilderrahmen-Bilder auf die Festplatte umgezogen`);
-    }
-  }
-
  /** Eigene Bilder, aelteste zuerst, nur Metadaten. */
  async list(userId: string, tenantId: string): Promise<DashboardImageMeta[]> {
    const tenantPrisma = forTenant(this.prisma, tenantId, userId);
@@ -240,10 +218,12 @@ export class DashboardImagesService implements OnApplicationBootstrap {
   * begrenzt, gespeichert wird der erkannte Typ — die Bytes auf der Platte,
   * die Zeile haelt den Pfad.
   *
-   * Reihenfolge (T-HK4-04): Zeile zuerst, weil der Dateiname die UUID der
-   * Zeile IST. Scheitert danach das Schreiben oder das Nachtragen des
-   * Pfades, wird die Zeile wieder geloescht — lieber gar kein Bild als eine
-   * Zeile ohne Datei.
+   * Reihenfolge (T-HK4-04): die UUID vergibt der Dienst selbst
+   * (`randomUUID()`, dieselbe Form wie Prismas `@default(uuid())`), damit
+   * die Zeile ihren Pfad gleich beim Anlegen traegt — `storagePath` ist seit
+   * Stufe 2 Pflicht. Zeile zuerst, dann die Datei; scheitert das Schreiben,
+   * wird die Zeile wieder geloescht — lieber gar kein Bild als eine Zeile
+   * ohne Datei.
   */
  async upload(user: AuthUser, file: UploadedFileLike | undefined): Promise<DashboardImageMeta> {
    if (!file) {
@@ -265,8 +245,12 @@ export class DashboardImagesService implements OnApplicationBootstrap {
      );
    }

+    const id = randomUUID();
+    const storagePath = storagePathFor(user.id, id, mimeType);
    const created = await tenantPrisma.dashboardImage.create({
      data: {
+        id,
+        storagePath,
        userId: user.id,
        tenantId: user.tenantId,
        originalName: file.originalname.slice(0, ORIGINAL_NAME_MAX),
@@ -277,11 +261,7 @@ export class DashboardImagesService implements OnApplicationBootstrap {
    });

    try {
-      const storagePath = await this.writeImageFile(user.id, created.id, mimeType, file.buffer);
-      await tenantPrisma.dashboardImage.update({
-        where: { id: created.id },
-        data: { storagePath },
-      });
+      await writeImageFile(storagePath, file.buffer);
    } catch (error) {
      this.logger.error(
        `Bilderrahmen-Bild ${created.id} konnte nicht gespeichert werden, Zeile wird zurueckgenommen: ${
@@ -297,8 +277,8 @@ export class DashboardImagesService implements OnApplicationBootstrap {

  /**
   * Bytes und gespeicherter Typ eines eigenen Bildes; fremd/unbekannt ->
-   * 404. Gelesen wird die Datei, nicht die Zeile — eine Zeile ohne Pfad
-   * (noch nicht umgezogen) und eine fehlende Datei ergeben denselben 404.
+   * 404. Gelesen wird die Datei; ein ungueltiger Pfad und eine fehlende
+   * Datei ergeben denselben 404.
   */
  async getBytes(
    id: string,
@@ -311,7 +291,7 @@ export class DashboardImagesService implements OnApplicationBootstrap {
      throw new NotFoundException(`Image with id '${id}' not found`);
    }

-    const absolute = row.storagePath === null ? null : absoluteImagePath(row.storagePath);
+    const absolute = absoluteImagePath(row.storagePath);
    if (absolute === null) {
      this.logger.warn(`Bilderrahmen-Bild ${id} hat keinen gueltigen Ablageort`);
      throw new NotFoundException(`Image with id '${id}' not found`);
@@ -321,26 +301,6 @@ export class DashboardImagesService implements OnApplicationBootstrap {
      const data = await fs.readFile(absolute);
      return { mimeType: row.mimeType, data };
    } catch (error) {
-      // Selbstheilung waehrend der Umstellung (T-HK4-03): fehlt die Datei,
-      // steckt aber noch die alte Spalte `data` in der Zeile, wird die Datei
-      // daraus neu geschrieben und ausgeliefert. Der Fall ist real: ein
-      // `pg_dump` aus der Zeit vor dem Umzug traegt die Bytes noch, das
-      // Volume `user-files` wird getrennt gesichert — wer nur den Abzug
-      // zurueckspielt, haette sonst Zeilen ohne Datei. Nach dem Entfernen der
-      // Spalte (eigenes Todo) faellt dieser Zweig ersatzlos weg.
-      if (row.data !== null) {
-        try {
-          await this.writeImageFile(row.userId, row.id, row.mimeType, row.data);
-          this.logger.log(`Bilderrahmen-Bild ${id} aus der Datenbank wiederhergestellt`);
-          return { mimeType: row.mimeType, data: row.data };
-        } catch (writeError) {
-          this.logger.error(
-            `Bilderrahmen-Bild ${id} konnte nicht wiederhergestellt werden: ${
-              writeError instanceof Error ? writeError.message : String(writeError)
-            }`,
-          );
-        }
-      }
      this.logger.warn(
        `Bilderrahmen-Bild ${id} fehlt im Dateibereich: ${
          error instanceof Error ? error.message : String(error)
@@ -363,7 +323,7 @@ export class DashboardImagesService implements OnApplicationBootstrap {
    }
    await tenantPrisma.dashboardImage.delete({ where: { id } });

-    const absolute = row.storagePath === null ? null : absoluteImagePath(row.storagePath);
+    const absolute = absoluteImagePath(row.storagePath);
    if (absolute !== null) {
      try {
        await fs.unlink(absolute);
@@ -378,31 +338,4 @@ export class DashboardImagesService implements OnApplicationBootstrap {

    return { id };
  }
-
-  /**
-   * Schreibt die Bytes an den servergenerierten Ort und liefert den
-   * relativen Pfad fuer die Zeile zurueck. Der Ordner je Benutzer entsteht
-   * dabei (`recursive: true`).
-   */
-  private async writeImageFile(
-    userId: string,
-    id: string,
-    mimeType: string,
-    bytes: Uint8Array,
-  ): Promise<string> {
-    const extension = extensionFor(mimeType);
-    if (extension === null) {
-      throw new Error(`Unbekannter Bildtyp '${mimeType}'`);
-    }
-
-    const storagePath = relativeStoragePath(userId, id, extension);
-    const absolute = absoluteImagePath(storagePath);
-    if (absolute === null) {
-      throw new Error(`Ungueltiger Ablageort fuer Bild ${id}`);
-    }
-
-    await fs.mkdir(path.dirname(absolute), { recursive: true });
-    await fs.writeFile(absolute, bytes);
-    return storagePath;
-  }
 }
@@ -173,9 +173,16 @@ const RELATION_SPEC_EXCEPTIONS = new Set<string>(['apps/api/src/tenders/backfill
 * `ProxmoxServer`, Migration 20260923140000), registriert je Mandant einen
 * Cron-Auftrag, und schreibt danach ausschliesslich je Zeile gebunden ueber
 * `forTenant()`. Summe neu: 6 Dateien, 7 Aufrufe.
+ *
+ * quick-260924-m4n: der SIEBTE FALL ist wieder ENTFERNT. Stufe 2 der
+ * Bilderrahmen-Umstellung (Migration 20260924120000_dashboard_image_drop_data)
+ * loescht die Spalte `data`; der Bootstrap-Umzug in
+ * `dashboard-images.service.ts` hat damit nichts mehr zu lesen und ist samt
+ * seinem `forSystem()`-Aufruf aus dem Dienst entfernt. Dieselbe Migration
+ * nimmt die `system_read_policy` auf "DashboardImage" zurueck. Summe neu:
+ * 5 Dateien, 6 Aufrufe.
 */
 const FORSYSTEM_ALLOWED_CALL_SITES = new Map<string, number>([
-  ['apps/api/src/dashboard/dashboard-images.service.ts', 1],
  ['apps/api/src/dkv/dkv.service.ts', 1],
  ['apps/api/src/ldap/ldap-config.service.ts', 2],
  ['apps/api/src/proxmox/proxmox.service.ts', 1],
@@ -623,7 +623,7 @@ export class ProxmoxService {
   * `const systemPrisma = forSystem(this.prisma);`, nur lesend, OHNE
   * `include` auf das Zwischenlager — die Zwischenlagertabelle hat bewusst
   * keine Systemlese-Regel, das Nachziehen laeuft je Zeile gebunden
-   * (Muster `DkvSchedulerService`/`DashboardImagesService`, einmal lesen,
+   * (Muster `DkvSchedulerService`, einmal lesen,
   * viele bedienen).
   */
  async loadActiveServersForScheduler(): Promise<
@@ -1,6 +1,9 @@
 import { act, cleanup, render, screen, waitFor } from '@testing-library/react';
 import userEvent from '@testing-library/user-event';
 import { afterEach, beforeEach, describe, expect, it, vi } from 'vitest';
+// Statisch statt je Test dynamisch importiert: Laden/Umwandeln der Seite faellt
+// in die Sammelphase, nicht in die 5-s-Frist eines Tests (quick-260924-m4n).
+import Page from './page';

 vi.mock('next-intl', () => ({
  useTranslations: () => (key: string, params?: Record<string, string>) => {
@@ -110,14 +113,14 @@ afterEach(() => {
  vi.restoreAllMocks();
 });

-async function importPage() {
-  const mod = await import('./page');
-  return mod.default;
-}
-
 describe('Marketplace Filters', () => {
+  // userEvent an die falsche Uhr koppeln: sonst wartet jede Eingabe auf das
+  // langsame Echtzeit-Nachschieben von shouldAdvanceTime (quick-260924-m4n).
+  let user: ReturnType<typeof userEvent.setup>;
+
  beforeEach(() => {
    vi.useFakeTimers({ shouldAdvanceTime: true });
+    user = userEvent.setup({ advanceTimers: vi.advanceTimersByTime });
    mockAuthStore.mockImplementation(
      (selector: (state: { user: { id: string; username: string; displayName: string; role: string; tenantId: string } }) => unknown) =>
        selector({
@@ -132,7 +135,6 @@ describe('Marketplace Filters', () => {
  });

  it('typing in search filters the grid to only matching modules after debounce', async () => {
-    const Page = await importPage();
    render(<Page />);

    await waitFor(() => {
@@ -142,7 +144,7 @@ describe('Marketplace Filters', () => {
    expect(screen.getByText('Email Tool')).toBeInTheDocument();

    const searchInput = screen.getByPlaceholderText('Module suchen...');
-    await userEvent.type(searchInput, 'Domain');
+    await user.type(searchInput, 'Domain');

    act(() => {
      vi.advanceTimersByTime(350);
@@ -155,7 +157,6 @@ describe('Marketplace Filters', () => {
  });

  it('selecting the Aktiviert status tab shows only activated modules', async () => {
-    const Page = await importPage();
    render(<Page />);

    await waitFor(() => {
@@ -163,7 +164,7 @@ describe('Marketplace Filters', () => {
    });

    const activeTab = screen.getByRole('tab', { name: /Aktiviert/i });
-    await userEvent.click(activeTab);
+    await user.click(activeTab);

    await waitFor(() => {
      expect(screen.getByText('Domaincheck')).toBeInTheDocument();
@@ -173,7 +174,6 @@ describe('Marketplace Filters', () => {
  });

  it('selecting a category chip shows only modules of that category; Alle shows all', async () => {
-    const Page = await importPage();
    render(<Page />);

    await waitFor(() => {
@@ -181,7 +181,7 @@ describe('Marketplace Filters', () => {
    });

    const utilitiesChip = screen.getByRole('button', { name: 'Utilities' });
-    await userEvent.click(utilitiesChip);
+    await user.click(utilitiesChip);

    await waitFor(() => {
      expect(screen.getByText('Converter')).toBeInTheDocument();
@@ -189,7 +189,7 @@ describe('Marketplace Filters', () => {
    });

    const allChip = screen.getByRole('button', { name: 'Alle' });
-    await userEvent.click(allChip);
+    await user.click(allChip);

    await waitFor(() => {
      expect(screen.getByText('Domaincheck')).toBeInTheDocument();
@@ -198,7 +198,6 @@ describe('Marketplace Filters', () => {
  });

  it('search + status + category filters compose together (AND)', async () => {
-    const Page = await importPage();
    render(<Page />);

    await waitFor(() => {
@@ -207,11 +206,11 @@ describe('Marketplace Filters', () => {

    // Filter to Domain-Tools category
    const domainChip = screen.getByRole('button', { name: 'Domain-Tools' });
-    await userEvent.click(domainChip);
+    await user.click(domainChip);

    // Filter to available only
    const availableTab = screen.getByRole('tab', { name: /Verfuegbar/i });
-    await userEvent.click(availableTab);
+    await user.click(availableTab);

    // Domain-Tools + Available = only Email Tool (Domaincheck is active)
    await waitFor(() => {
@@ -222,7 +221,6 @@ describe('Marketplace Filters', () => {
  });

  it('renders filtered-empty heading when filters produce zero results', async () => {
-    const Page = await importPage();
    render(<Page />);

    await waitFor(() => {
@@ -230,7 +228,7 @@ describe('Marketplace Filters', () => {
    });

    const searchInput = screen.getByPlaceholderText('Module suchen...');
-    await userEvent.type(searchInput, 'zzz-nonexistent');
+    await user.type(searchInput, 'zzz-nonexistent');

    act(() => {
      vi.advanceTimersByTime(350);
@@ -1,5 +1,8 @@
 import { cleanup, render, screen, waitFor } from '@testing-library/react';
 import { afterEach, beforeEach, describe, expect, it, vi } from 'vitest';
+// Statisch statt je Test dynamisch importiert: Laden/Umwandeln der Seite faellt
+// in die Sammelphase, nicht in die 5-s-Frist eines Tests (quick-260924-m4n).
+import Page from './page';

 // Mock next-intl
 vi.mock('next-intl', () => ({
@@ -79,12 +82,6 @@ afterEach(() => {
  vi.restoreAllMocks();
 });

-// Lazy import after mocks
-async function importPage() {
-  const mod = await import('./page');
-  return mod.default;
-}
-
 describe('MarketplacePage', () => {
  beforeEach(() => {
    // Default: admin user
@@ -106,7 +103,6 @@ describe('MarketplacePage', () => {
      }),
    );

-    const Page = await importPage();
    render(<Page />);

    await waitFor(() => {
@@ -126,7 +122,6 @@ describe('MarketplacePage', () => {
      }),
    );

-    const Page = await importPage();
    render(<Page />);

    await waitFor(() => {
@@ -156,7 +151,6 @@ describe('MarketplacePage', () => {
      }),
    );

-    const Page = await importPage();
    render(<Page />);

    await waitFor(() => {
@@ -176,7 +170,6 @@ describe('MarketplacePage', () => {
      }),
    );

-    const Page = await importPage();
    render(<Page />);

    await waitFor(() => {
@@ -1,6 +1,13 @@
 import { cleanup, render, screen, waitFor } from '@testing-library/react';
 import userEvent from '@testing-library/user-event';
 import { afterEach, beforeEach, describe, expect, it, vi } from 'vitest';
+// Komponenten statisch importiert (vi.mock wird ueber die Importe gehoben): das
+// Laden und Umwandeln faellt so in die Sammelphase der Datei und nicht in die
+// 5-s-Frist des ersten Tests. Frueher lag der dynamische Import im Test und hat
+// unter Laeuferlast (drei parallele Pipelines bei jeder Freigabe) die Frist
+// gerissen (Todo 2026-09-23, quick-260924-m4n).
+import { TenantContextSelector } from './components/TenantContextSelector';
+import Page from './page';

 vi.mock('next-intl', () => ({
  useTranslations: () => (key: string, params?: Record<string, string>) => {
@@ -86,19 +93,8 @@ afterEach(() => {
  mockBumpSidebarRefresh.mockClear();
 });

-async function importPage() {
-  const mod = await import('./page');
-  return mod.default;
-}
-
-async function importTenantSelector() {
-  const mod = await import('./components/TenantContextSelector');
-  return mod.TenantContextSelector;
-}
-
 describe('TenantContextSelector', () => {
-  it('renders tenant options for SUPER_ADMIN; renders nothing for ADMIN', async () => {
-    // SUPER_ADMIN case
+  it('renders tenant options for SUPER_ADMIN', async () => {
    mockAuthStore.mockImplementation(
      (selector: (state: { user: { id: string; username: string; displayName: string; role: string; tenantId: string } }) => unknown) =>
        selector({
@@ -116,16 +112,13 @@ describe('TenantContextSelector', () => {
      }),
    );

-    const TenantContextSelector = await importTenantSelector();
-    const { unmount } = render(<TenantContextSelector />);
+    render(<TenantContextSelector />);

-    await waitFor(() => {
-      expect(screen.getByText('Tenant Alpha')).toBeInTheDocument();
-    });
+    expect(await screen.findByText('Tenant Alpha')).toBeInTheDocument();
    expect(screen.getByText('Tenant Beta')).toBeInTheDocument();
-    unmount();
+  });

-    // ADMIN case
+  it('renders nothing for ADMIN and does not load the tenant list', () => {
    mockAuthStore.mockImplementation(
      (selector: (state: { user: { id: string; username: string; displayName: string; role: string; tenantId: string } }) => unknown) =>
        selector({
@@ -133,8 +126,12 @@ describe('TenantContextSelector', () => {
        }),
    );

+    const fetchMock = vi.fn();
+    vi.stubGlobal('fetch', fetchMock);
+
    const { container } = render(<TenantContextSelector />);
    expect(container.innerHTML).toBe('');
+    expect(fetchMock).not.toHaveBeenCalled();
  });

  it('calls setSelectedTenantId when selector value changes', async () => {
@@ -155,7 +152,6 @@ describe('TenantContextSelector', () => {
      }),
    );

-    const TenantContextSelector = await importTenantSelector();
    render(<TenantContextSelector />);

    await waitFor(() => {
@@ -190,7 +186,6 @@ describe('ActivationDialog', () => {
      }),
    );

-    const Page = await importPage();
    render(<Page />);

    await waitFor(() => {
@@ -224,7 +219,6 @@ describe('ActivationDialog', () => {
      }),
    );

-    const Page = await importPage();
    render(<Page />);

    await waitFor(() => {
@@ -12,6 +12,9 @@ import type { ReactElement } from 'react';
 import { afterEach, beforeEach, describe, expect, it, vi } from 'vitest';
 import type { ProxmoxMetrics, ProxmoxServer } from '@/lib/proxmox-api';
 import de from '@/messages/de.json';
+// Statisch importiert (vi.mock wird darueber gehoben) — das Laden faellt in die
+// Sammelphase, nicht in die Frist des ersten Tests (quick-260924-m4n).
+import { ProxmoxWidget } from './proxmox-widget';

 // Echter next-intl-Provider mit den deutschen Texten (Muster
 // proxmox-page-roles.test.tsx) — die Kachel braucht ICU-Plural und useLocale.
@@ -119,17 +122,27 @@ function makeServer(
  };
 }

+/**
+ * Rendert die Kachel und wartet INNERHALB von act() das Ende des ersten
+ * Ladens ab (aufgeloestes listServers-Versprechen -> setServers/setLoadFailed/
+ * setNow). Ohne das liefen diese Zustandsaenderungen nach dem Rendern ins Leere
+ * und React meldete je Test drei „not wrapped in act(...)“-Warnungen
+ * (quick-260924-m4n).
+ */
 async function renderWidget(
  props: { config?: Record<string, unknown>; isEditMode?: boolean } = {},
 ) {
-  const { ProxmoxWidget } = await import('./proxmox-widget');
-  return render(
-    <ProxmoxWidget
-      instanceId="w-1"
-      config={props.config ?? {}}
-      isEditMode={props.isEditMode ?? false}
-    />,
-  );
+  let result!: ReturnType<typeof render>;
+  await act(async () => {
+    result = render(
+      <ProxmoxWidget
+        instanceId="w-1"
+        config={props.config ?? {}}
+        isEditMode={props.isEditMode ?? false}
+      />,
+    );
+  });
+  return result;
 }

 beforeEach(() => {
@@ -617,13 +630,15 @@ describe('ProxmoxWidget: Bearbeitungsmodus mit Titel und Serverauswahl (quick-26

  it('Verlassen des Bearbeitungsmodus schliesst die Auswahl', async () => {
    mockListServers.mockResolvedValue([makeServer('ok')]);
-    const { ProxmoxWidget } = await import('./proxmox-widget');
    const ui = (isEditMode: boolean) => (
      <NextIntlClientProvider locale="de" messages={de} timeZone="Europe/Berlin">
        <ProxmoxWidget instanceId="w-1" config={{}} isEditMode={isEditMode} />
      </NextIntlClientProvider>
    );
-    const { rerender } = rtlRender(ui(true));
+    let rerender!: ReturnType<typeof rtlRender>['rerender'];
+    await act(async () => {
+      ({ rerender } = rtlRender(ui(true)));
+    });
    await screen.findByTestId('proxmox-summary');

    fireEvent.click(screen.getByRole('button', { name: 'Server auswählen' }));
@@ -221,6 +221,35 @@ der `.env` als `IMAGE_TAG` steht, siehe Kapitel 9.)
 sie auf dem Server abweichen.) Liegt `StartedAt` **vor** `Created` des Images, läuft
 noch die alte Version – dann `--force-recreate` nachholen.

+**Hinweis für die erste Version nach 1.3.1 – alte Bildspalte fällt weg:** Diese
+Version entfernt die alte Spalte, in der die Bilder des Bilderrahmen-Widgets
+früher in der Datenbank lagen (Migration `20260924120000_dashboard_image_drop_data`).
+Die Bilder selbst liegen seit 1.3.1 im Volume `user-files`; 1.3.1 hat sie beim
+ersten Start von selbst dorthin umgezogen. Hat ein Server 1.3.1 übersprungen, wäre
+der Umzug dort nie gelaufen – dann bricht die Migration ab, **bevor** sie etwas
+ändert, und der `api`-Container startet nicht. In `docker compose logs api` steht
+dann die Meldung „DashboardImage: es gibt noch Zeilen ohne storagePath — Umzug
+(quick-260922-hk4) zuerst mit einer Version >= 1.3.1 laufen lassen, dann erneut
+deployen“. Es gehen dabei keine Bilder verloren. Abhilfe in drei Schritten:
+
+1. Den abgebrochenen Versuch als zurückgenommen vermerken – sonst verweigert
+   auch 1.3.1 jeden Start, weil Prisma eine fehlgeschlagene Migration in der
+   Datenbank sieht (Fehler `P3009`):
+
+   ```bash
+   docker compose -f docker-compose.prod.yml exec db \
+     psql -U tessera -d tessera -c \
+     "UPDATE _prisma_migrations SET rolled_back_at = now() WHERE migration_name = '20260924120000_dashboard_image_drop_data' AND finished_at IS NULL;"
+   ```
+
+2. In der `.env` `IMAGE_TAG=v1.3.1` setzen, `pull` und `--force-recreate` wie
+   oben, den Start abwarten – der Umzug läuft dabei von selbst.
+3. `IMAGE_TAG` zurück auf den Kanal (`live` bzw. `beta`) und erneut einspielen;
+   jetzt läuft die Migration durch.
+
+(Dieser Ablauf ist am 24.09.2026 in einer Wegwerf-Datenbank vollständig
+durchgespielt.)
+
 ## 5. Datenbank-Migrationen

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

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

@@ -691,7 +691,7 @@ werden.
 | apps/api/src/auth/auth.service.ts | user | muss-mandantengebunden | gebunden | Klassenkorrektur (260911-fh9, Aufgabe 2/3): wechselt von `gemischt` auf `gebunden` — `getMe`, `changePassword`, `adminResetPassword` binden seit Aufgabe 2 je über GENAU EINEN Klienten `tenantPrisma` an den Mandanten aus dem Sitzungsnachweis (`@CurrentUser().tenantId`); für die oberste Rolle (SUPER_ADMIN) löst der Controller den Mandanten des ZIELS über den gebundenen Fan-out `UserService.findByIdForPlatformAdmin` auf. `adminResetPassword` verweigert zusätzlich einem Nicht-SUPER_ADMIN das Kennwort eines SUPER_ADMIN (T-FH9-04). Die drei Anmeldesuchen (`validateUser`, `requestPasswordReset`, `resetPassword`) laufen weiterhin über die drei SECURITY-DEFINER-Funktionen (`$queryRaw`, keine Modellzugriffe — `$` liegt nicht in `[a-zA-Z]`) und bleiben unverändert auf dem ungebundenen Klienten. Etappe-3-Vorbehalt: die Bindung hängt am Claim `tenantId` und an `User.id` (plattformweite UUID), nicht an `username`/`email` — der Anmeldeweg-Umbau für je Mandant eindeutige Anmeldenamen betrifft diese Bindung nicht, siehe `docs/mandantentrennung-etappe2-fehlerrichtung.md`, Abschnitt "## Bereich auth", (h4)(a). |
 | apps/api/src/bug-reports/bug-reports.service.ts | user | muss-mandantengebunden | gebunden | Fehler-melden-Knopf (quick-260914-m97): eine gebundene Leseoperation auf die Zeile des angemeldeten Benutzers (Anzeigename, E-Mail, Rolle fuer den Bericht), Mandant ausschliesslich aus dem Sitzungsnachweis. |
 | apps/api/src/calendar/calendar.service.ts | calendarSource | muss-mandantengebunden | gebunden | Kalenderquellen eines Nutzers je Mandant gebunden (encryptedPassword traegt Zugangsdaten zu externen Exchange-/CalDAV-Servern), `tenantId`-Spalte vorhanden. Seit 260911-cwh (Aufgabe 2) laufen alle zwoelf Zugriffe (`getSources`, `addSource`, beide Abfragen von `updateSource`/`deleteSource`, alle drei Abfragen von `testConnection`, Laden plus beide Synchronstatus-Rueckschreibungen von `fetchAndCacheEvents`) ueber `forTenant()`, ein Klient je Methode; `fetchAndCacheEvents`/`refreshCacheInBackground` nehmen die Mandantenkennung als Parameter, Letztere traegt die Kennung der urspruenglichen Anfrage. Die drei Besitzpruefungen (`updateSource`/`deleteSource`/`testConnection`, Vergleich gegen `userId` aus dem Sitzungsnachweis) bleiben zusaetzlich bestehen — die Regel auf `CalendarSource` kennt keine Benutzerdimension (260911-cwh, Aufgabe 1, gemessen), sie sind bis zur Etappe-3-Entscheidung (2) der einzige Schutz zwischen Kollegen DESSELBEN Mandanten. Benutzerdimension seit 20260911120000 (260911-nke). |
-| apps/api/src/dashboard/dashboard-images.service.ts | dashboardImage | muss-mandantengebunden | system-gebunden | **260922-hk4:** Stand von `gebunden` auf `system-gebunden` — NICHT weil ein Anfrageweg aufgeweicht wurde, sondern weil EIN Startpfad dazugekommen ist: `onApplicationBootstrap()` zieht die Bilder einmalig aus der Spalte `data` in den Dateibereich (`user-files/dashboard-images/<userId>/<id>.<ext>`) und muss dafür die noch nicht umgezogenen Zeilen ALLER Mandanten sehen (`const systemPrisma = forSystem(this.prisma)`, ein Aufruf, Erlaubnisliste in `rls-access-inventory.spec.ts`; Leserecht über `system_read_policy … FOR SELECT` auf "DashboardImage", Migration 20260922120000). GESCHRIEBEN wird auch dort je Zeile über `forTenant(prisma, row.tenantId, row.userId)` — einmal-lesen-viele-bedienen, Muster DKV-Planer. Die Bytes selbst liegen seither auf der Platte, die Zeile hält nur noch `storagePath` (Muster `User.avatarPath`); der Dateiname ist IMMER servergeneriert (UUID der Zeile + Endung aus dem ERKANNTEN Mime-Typ), `originalName` kommt in keinem Pfad vor (T-HK4-01). Alle vier Anfragewege sind unverändert mandantengebunden: Hochgeladene Bilder des Bilderrahmen-Widgets (quick-260921-pi9), gehoeren dem hochladenden Benutzer; `tenantId`-Spalte vorhanden, Regel `tenant_isolation_policy` MIT Benutzerdimension von Anfang an (Migration 20260921120000, Form aus 20260911120000). Alle vier Methoden (`list`, `upload`, `getBytes`, `remove`) holen je einen Klienten `const tenantPrisma = forTenant(this.prisma, tenantId, userId)`; Liste und Zaehler filtern zusaetzlich explizit `where: { tenantId, userId }`, `getBytes`/`remove` pruefen den Besitz anwendungsseitig (`row.userId !== userId || row.tenantId !== tenantId` -> 404, nie 403) — zweites Netz, kein Ersatz, weil der RLS-Schalter heute aus ist. `select` der Liste/Upload-Antwort ohne `data` (Bytes nur ueber `GET :id`). |
+| apps/api/src/dashboard/dashboard-images.service.ts | dashboardImage | muss-mandantengebunden | gebunden | **quick-260924-m4n:** Stand zurück von `system-gebunden` auf `gebunden`. Stufe 2 der Umstellung (Migration 20260924120000_dashboard_image_drop_data) löscht die Spalte `data` und macht `storagePath` zur Pflicht; der Bootstrap-Umzug hatte auf allen Servern gearbeitet und ist samt seinem einzigen `forSystem()`-Aufruf entfernt (Eintrag aus `FORSYSTEM_ALLOWED_CALL_SITES` gestrichen). Dieselbe Migration entfernt die `system_read_policy` auf "DashboardImage" — auf der Tabelle bleibt allein `tenant_isolation_policy` (Mandant UND Benutzer). Alle vier Anfragewege laufen wie bisher ausschließlich über `forTenant(this.prisma, tenantId, userId)`; der Upload vergibt die UUID jetzt selbst und legt die Zeile gleich mit Pfad an. Vorher: **260922-hk4:** Stand von `gebunden` auf `system-gebunden` — NICHT weil ein Anfrageweg aufgeweicht wurde, sondern weil EIN Startpfad dazugekommen ist: `onApplicationBootstrap()` zieht die Bilder einmalig aus der Spalte `data` in den Dateibereich (`user-files/dashboard-images/<userId>/<id>.<ext>`) und muss dafür die noch nicht umgezogenen Zeilen ALLER Mandanten sehen (`const systemPrisma = forSystem(this.prisma)`, ein Aufruf, Erlaubnisliste in `rls-access-inventory.spec.ts`; Leserecht über `system_read_policy … FOR SELECT` auf "DashboardImage", Migration 20260922120000). GESCHRIEBEN wird auch dort je Zeile über `forTenant(prisma, row.tenantId, row.userId)` — einmal-lesen-viele-bedienen, Muster DKV-Planer. Die Bytes selbst liegen seither auf der Platte, die Zeile hält nur noch `storagePath` (Muster `User.avatarPath`); der Dateiname ist IMMER servergeneriert (UUID der Zeile + Endung aus dem ERKANNTEN Mime-Typ), `originalName` kommt in keinem Pfad vor (T-HK4-01). Alle vier Anfragewege sind unverändert mandantengebunden: Hochgeladene Bilder des Bilderrahmen-Widgets (quick-260921-pi9), gehoeren dem hochladenden Benutzer; `tenantId`-Spalte vorhanden, Regel `tenant_isolation_policy` MIT Benutzerdimension von Anfang an (Migration 20260921120000, Form aus 20260911120000). Alle vier Methoden (`list`, `upload`, `getBytes`, `remove`) holen je einen Klienten `const tenantPrisma = forTenant(this.prisma, tenantId, userId)`; Liste und Zaehler filtern zusaetzlich explizit `where: { tenantId, userId }`, `getBytes`/`remove` pruefen den Besitz anwendungsseitig (`row.userId !== userId || row.tenantId !== tenantId` -> 404, nie 403) — zweites Netz, kein Ersatz, weil der RLS-Schalter heute aus ist. `select` der Liste/Upload-Antwort ohne `data` (Bytes nur ueber `GET :id`). |
 | apps/api/src/dashboard/dashboard.service.ts | dashboard | muss-mandantengebunden | gebunden | quick-260923-ad9 — Reiter (mehrere Dashboards je Benutzer), `tenantId`-Spalte vorhanden, Regel `tenant_isolation_policy` MIT Benutzerdimension von Anfang an (Migration 20260923120000, Form aus 20260911120000/20260921120000). Task 1: `listDashboards` liest ueber `forTenant()` und legt bei Bedarf genau einen Reiter an (Transaktionssperre `pg_advisory_xact_lock` innerhalb `withTenantTransaction`, T-AD9-07); der Riegel `assertOwnedDashboard` liest ueber DENSELBEN, bereits gebundenen Klienten des Aufrufers (kein zweiter `forTenant()`-Aufruf) und wirft fuer "gibt es nicht", "gehoert einem Kollegen" und "liegt bei einem fremden Mandanten" dieselbe `NotFoundException` (T-AD9-01/02/03). Task 2: `createDashboard`/`renameDashboard` laufen als Einzeloperationen ueber `forTenant()`, je Methode ein Klient (Riegel zuerst bei `renameDashboard`). `deleteDashboard`/`reorderDashboards` laufen je als EINE `withTenantTransaction` (mehrschrittig, muss atomar sein) — `withTenantTransaction` setzt KEINE Benutzerdimension in der Sitzung, deshalb traegt jede Bedingung `userId` selbst (`tx.dashboard.deleteMany({where:{id,userId}})`, `tx.dashboard.updateMany({where:{id,userId},...})`), wortgleiches Muster zu `favorites.service.ts`/`reorder` (260917-jdd). `deleteDashboard` entfernt zusaetzlich die Kacheln (`tx.widgetInstance.deleteMany`) und die Anordnung (`tx.dashboardLayout.deleteMany`) des Reiters in DERSELBEN Transaktion. |
 | apps/api/src/dashboard/dashboard.service.ts | dashboardLayout | muss-mandantengebunden | gebunden | Anordnung eines Reiters, `tenantId`-Spalte vorhanden. Seit 260910-krx (Aufgabe 2) laufen `getLayout`/`saveLayout` GEMEINSAM ueber `forTenant()`, ein Klient je Methode; `saveLayout` uebersetzt eine `PrismaClientUnknownRequestError` (RLS-Konflikt, gemessen in Aufgabe 1 — NICHT die `P2002`-Form, die der Bereich `tenders` abfaengt) in eine deutsche Konfliktmeldung. quick-260923-ad9 (Task 1): die eindeutige Spalte ist jetzt `dashboardId` statt `userId` (D-02) — beide Methoden pruefen vorher ueber `assertOwnedDashboard`, dass der Reiter dem Aufrufer gehoert. |
 | apps/api/src/dashboard/dashboard.service.ts | favoriteLink | muss-mandantengebunden | gebunden | quick-260923-lrr — nur LESEND, zum Aufraeumen hochgeladener Favoriten-Symbole: `removeWidget` und `deleteDashboard` lesen VOR dem Loeschen die Favoriten mit hochgeladenem Symbol (`findMany`, Bedingung traegt `userId` UND `widgetId`) ueber DENSELBEN, bereits gebundenen Klienten `tenantPrisma` der Methode (kein zweiter `forTenant()`-Aufruf). Die Zeilen selbst verschwinden ueber den Fremdschluessel-Kaskadenweg; danach werden die Dateien best effort entfernt, ein Dateifehler bricht das Loeschen nie ab. |
@@ -830,9 +830,13 @@ werden.
  Anmeldenamen pro Mandant (Etappe 3a) bleibt offen. **Systemkontext
  (Etappe 3c) — erledigt (260914-eym):** Migration
  `20260914120000_rls_system_context_read` (`is_system_context()`,
-  `system_read_policy … FOR SELECT` auf fünf Tabellen; seit 260922-hk4
-  kommt "DashboardImage" als sechste dazu, angelegt in der Migration
-  20260922120000 für den Bootstrap-Umzug der Bilderrahmen-Bilder),
+  `system_read_policy … FOR SELECT` auf fünf Tabellen; seit 260923-dhh
+  kommt "ProxmoxServer" als sechste dazu, Migration 20260923140000.
+  "DashboardImage" trug die Regel nur vorübergehend — angelegt in
+  20260922120000 für den Bootstrap-Umzug der Bilderrahmen-Bilder, mit
+  Stufe 2 der Umstellung wieder entfernt, Migration
+  20260924120000_dashboard_image_drop_data, quick-260924-m4n; gemessen
+  24.09.2026 lokal: sechs Tabellen mit der Regel),
  Schwesterhelfer
  `forSystem()`, fünfte Erkennungsform des Detektors mit Erlaubnisliste;
  siehe `docs/mandantentrennung-etappe2-fehlerrichtung.md`, Abschnitt
Author	SHA1	Message	Date
schalli	9225ed1bf9	docs(changelog): Version 1.4.0 abgeschlossen Tessera CI/CD / Build & Publish Images (push) Successful in 2m54s Details Tessera CI/CD / Lint & Type Check (push) Successful in 44s Details Tessera CI/CD / Tests (push) Successful in 1m17s Details Tessera CI/CD / Desktop-Pakete bauen (push) Successful in 5m30s Details Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-25 07:58:45 +02:00
schalli	da0ee8256f	docs(quick-260924-m4n): Test-Flake und DashboardImage Stufe 2 Tessera CI/CD / Lint & Type Check (push) Successful in 49s Details Tessera CI/CD / Tests (push) Successful in 1m14s Details Tessera CI/CD / Desktop-Pakete bauen (push) Successful in 19s Details Tessera CI/CD / Build & Publish Images (push) Successful in 3m7s Details Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-24 16:13:05 +02:00
schalli	dd54ec5d42	feat(260924-m4n): Bilderrahmen Stufe 2 - alte Bildspalte data entfernt, storagePath Pflicht - Migration 20260924120000_dashboard_image_drop_data: Schutzpruefung (bricht ab, solange eine Zeile ohne storagePath existiert; row_security aus, damit ein Eigentuemer ohne BYPASSRLS nicht still 0 Zeilen sieht), dann NOT NULL, DROP COLUMN data, DROP POLICY system_read_policy - Dienst: Bootstrap-Umzug samt forSystem() und Selbstheilung aus data entfernt; Upload vergibt die UUID selbst, Zeile gleich mit Pfad - FORSYSTEM_ALLOWED_CALL_SITES, Tests, Zugriffsklassifikation (per Gate-Schleife gemessen: 61/213/6) nachgezogen - Betriebshandbuch Kap. 4: Hinweis und Wiederherstellungsweg bei Abbruch - Todo 2026-09-22 nach completed/ Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-24 16:09:36 +02:00
schalli	b10734f382	test(260924-m4n): flackernden Marktplatz-Test entschaerfen, act-Warnungen der Proxmox-Kachel weg - tenant-selector: Komponenten statisch statt im Test dynamisch importiert (Laden zaehlte in die 5-s-Frist des ersten Tests), SUPER_ADMIN/ADMIN in zwei it aufgetrennt - marketplace/marketplace-filters: gleiche Umstellung; userEvent an die falsche Uhr gekoppelt statt auf shouldAdvanceTime zu warten - proxmox-widget: Rendern wartet das erste Laden in act() ab (81 Warnungen weg) - Todo 2026-09-23 nach completed/ Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>	2026-09-24 16:02:45 +02:00