diff --git a/.planning/todos/pending/2026-09-23-flackernder-test-tenant-selector-zeitueberschreitung.md b/.planning/todos/pending/2026-09-23-flackernder-test-tenant-selector-zeitueberschreitung.md
new file mode 100644
index 0000000..76c26b5
--- /dev/null
+++ b/.planning/todos/pending/2026-09-23-flackernder-test-tenant-selector-zeitueberschreitung.md
@@ -0,0 +1,51 @@
+---
+created: 2026-09-23
+title: Flackernder Test "TenantContextSelector" — Zeitüberschreitung bei 5 s, hat die Freigabe 1.3.1 blockiert
+area: apps/web
+severity: flake
+trigger: sobald wieder an apps/web gearbeitet wird — spätestens vor der nächsten Freigabe, weil der Fall dort teuer ist.
+relates_to: Freigabe v1.3.1 (CI-Lauf 418, Job 1262)
+---
+
+## Was passiert ist
+
+Beim Freigeben von 1.3.1 lösen drei Pipelines gleichzeitig aus (`main`, Zweig
+`live`, Tag `v1.3.1`). Auf dem Tag-Lauf fiel der Test
+
+```
+src/app/(portal)/marketplace/tenant-selector.test.tsx
+  > TenantContextSelector > renders tenant options for SUPER_ADMIN; renders nothing for ADMIN
+```
+
+mit `Error: Test timed out in 5000ms` aus. **Derselbe Commit** (`ad004b28`) war
+im selben Zeitraum auf `main` (Lauf 1025) und auf `live` (Lauf 1026) grün — es
+ist also kein Fehler im Code, sondern der Läufer war mit drei parallelen
+Pipelines ausgelastet und der Test lief in sein 5-Sekunden-Limit.
+
+## Warum das teuer war
+
+Der Abbild-Bau hängt am Test-Job. Rot heißt: **„Build & Publish Images" und
+„Desktop-Pakete bauen" wurden übersprungen** — die Freigabe war damit getaggt,
+aber nicht gebaut. Kein `live`-Abbild, kein Gitea-Release, keine
+Desktop-Pakete. Erst ein Neustart des Laufs (Gitea-API,
+`POST /actions/runs/418/rerun`) hat alles nachgeholt.
+
+Das trifft **jede** Freigabe, weil jede Freigabe drei gleichzeitige Läufe
+auslöst. Der Fall wiederholt sich also, nicht zufällig.
+
+## Was zu tun ist
+
+1. Den Test ansehen: warum braucht er überhaupt nahe 5 s? Verdacht ist ein
+   `waitFor` auf etwas, das erst nach einem Datenabruf erscheint, oder zwei
+   Fälle (SUPER_ADMIN und ADMIN) in EINEM `it`, das dadurch doppelt so lange
+   läuft — der Testname nennt beide Fälle in einem Satz.
+2. Entweder auftrennen (zwei `it`-Blöcke) oder die Wartezeit gezielt erhöhen.
+   Ein globales Hochsetzen von `testTimeout` versteckt nur, dass hier etwas
+   langsam ist.
+3. Prüfen, ob weitere Tests nahe am Limit liegen — die Läuferlast bleibt ja.
+
+## Nicht die Lösung
+
+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.