tessera-ctl/.planning/quick/260924-m4n-flackernden-test-entschaerfen-und-dashbo/260924-m4n-PLAN.md

quick_id, type, wave, autonomous

quick_id	type	wave	autonomous
260924-m4n	quick	1	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:

  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.