feat: Phase 4 – Modul-Gateway mit dynamischem Routing und Startup-Recovery

docs/PHASES.md

@@ -7,7 +7,7 @@ Der Arbeitsplan sieht zehn inkrementelle Phasen vor. Nach jeder Phase muss das S
 | 1 | Grundgerüst (Docker, DB, Login, Rollen) | ✅ Abgeschlossen |
 | 2 | Benutzerverwaltung | ✅ Abgeschlossen |
 | 3 | Modul-System (Manifest, Installation, Lifecycle) | ✅ Abgeschlossen |
-| 4 | Gateway & dynamisches Routing (`/slug`) | ⏳ Geplant |
+| 4 | Gateway & dynamisches Routing (`/slug`) | ✅ Abgeschlossen |
 | 5 | Berechtigungssystem (User ↔ Module) | ⏳ Geplant |
 | 6 | Modul-API (`/health`, `/api/manifest`, `/api/me`) | ⏳ Geplant |
 | 7 | Referenzmodul Kalender | ⏳ Geplant |
@@ -69,8 +69,21 @@ Definition of Done: Modul-Datenmodell, Manifest, Installation, Registrierung, St
 - [x] Backend-Tests: 72 bestanden (inkl. ModulesService-Lifecycle, Manifest-Validierung, Installer)
 - [x] E2E verifiziert: Installation (201), Start → RUNNING, Healthcheck (healthy, 2 ms), Stop, Restart, Disable (stoppt Prozess), Start-Sperre bei Disable (400), Remove, RBAC (USER → 403)
 
-## Nächste Schritte (Phase 4 – Gateway & Routing)
+## Phase 4 – Gateway & dynamisches Routing (abgeschlossen)
 
-- Dynamisches Routing: `/slug` → Modul-Prozess (Nginx-Konfiguration zur Laufzeit)
-- Zugriffskontrolle beim Routing (Session → Permission Check → 403/Proxy)
-- Modul-Gateway mit sicherer Identitätsübergabe an das Modul
+Definition of Done: Module sind über `/slug` erreichbar, Zugriff nur mit gültiger Session und Berechtigung.
+
+- [x] Nginx-Routing: `/slug/*` → Backend-Gateway (`/api/v1/gateway/slug/*`) mit Ausschluss-Regex für Plattform-Pfade (api, assets, login, …)
+- [x] Modul-Gateway als Middleware: Session-Check (401), Slug-Suche (404), Status-Check (503), Permission-Check (403), Proxy zum internen Port
+- [x] Sichere Identitätsübergabe über interne Header (`x-user-id`, `x-user-username`, `x-user-display-name`, `x-user-role`); Session-Cookie wird nie an Module weitergereicht
+- [x] Fail-closed: USERs erhalten bis Phase 5 grundsätzlich 403
+- [x] Startup-Recovery: Nach Container-Neustarts werden veraltete Status zurückgesetzt und aktivierte Module automatisch neu gestartet
+- [x] Backend-Tests: 81 bestanden (inkl. 9 Gateway-Tests)
+- [x] E2E verifiziert: `/demo` → 200 (Modul-Inhalt), `/demo/health` → 200, unbekanntes Modul → 404, ohne Login → 401, USER → 403, gestopptes Modul → 503
+
+## Nächste Schritte (Phase 5 – Berechtigungssystem)
+
+- `user_module_permissions`-Tabelle (GRANTED/DENIED)
+- Admin-API: Benutzer ↔ Module zuweisen (`POST /api/v1/users/:id/modules/:moduleId`)
+- Gateway-Permission-Check an die Tabelle anbinden (USER mit GRANTED → Zugriff)
+- Dashboard: Modul-Kacheln anhand der tatsächlichen Berechtigungen