MPM – Phasen-Übersicht

Der Arbeitsplan sieht zehn inkrementelle Phasen vor. Nach jeder Phase muss das System startbar und testbar sein.

Phase	Bereich	Status
1	Grundgerüst (Docker, DB, Login, Rollen)	✅ Abgeschlossen
2	Benutzerverwaltung	✅ Abgeschlossen
3	Modul-System (Manifest, Installation, Lifecycle)	✅ Abgeschlossen
4	Gateway & dynamisches Routing (`/slug`)	✅ Abgeschlossen
5	Berechtigungssystem (User ↔ Module)	✅ Abgeschlossen
6	Modul-API (`/health`, `/api/manifest`, `/api/me`)	⏳ Geplant
7	Referenzmodul Kalender	⏳ Geplant
8	Modul-SDK (`platform-module-sdk`)	⏳ Geplant
9	Administration (Übersichten, Audit-UI, Einstellungen)	⏳ Geplant
10	Security Hardening & Produktivbetrieb	⏳ Geplant

Phase 1 – Grundgerüst (abgeschlossen)

Definition of Done:

Definition of Done: Admin kann Benutzer vollständig verwalten.

GET/POST/PATCH/DELETE /api/v1/users/* (nur @Roles('ADMIN'))
Benutzerliste, Benutzer anlegen (Zod-Validierung, Duplikat-Schutz 409)
Benutzer bearbeiten (Anzeigename, E-Mail, Rolle)
Benutzer deaktivieren/aktivieren (Sessions werden sofort ungültig)
Passwort-Reset durch Admin (alle Sessions des Benutzers werden gelöscht)
Schutzregeln: keine Selbst-Deaktivierung/-Löschung, letzter aktiver Admin geschützt
Profil-Endpunkte (GET /api/v1/profile, PATCH /api/v1/profile/password)
Eigenes Passwort ändern (Verifikation des aktuellen Passworts, andere Sessions werden abgemeldet)
Frontend: Benutzerverwaltungs-Seite (Tabelle, Create/Edit/Reset/Delete-Modals, Toasts)
Frontend: Profil-Seite mit Passwortänderung
UI-Komponenten: Modal, Select, Toast (Design-System erweitert)
Backend-Tests: 49 bestanden (inkl. UsersService, ProfileService)
E2E verifiziert: CRUD, RBAC (User → 403), Login-Sperre nach Deaktivierung, Passwort-Flows

Definition of Done: Modul-Datenmodell, Manifest, Installation, Registrierung, Status, Start/Stop/Restart, Healthcheck.

modules-Tabelle (Migration 002) mit Lifecycle-Status und eindeutigen Ports/Slugs
Manifest-Vertrag module.json (Zod: ID, Name, Version, Slug, Runtime, Entrypoint, Port 41000–41999, Healthcheck, apiVersion)
ZIP-Installer mit Manifest-Validierung, Größenlimit (10 MB) und Zip-Slip-Schutz
Modul-Prozess-Manager: Start/Stop (SIGTERM→SIGKILL) als Kindprozesse, minimale ENV (keine Plattform-Secrets), eigene Log-Dateien
Healthcheck-Service mit Startup-Grace (10 Retries × 500 ms)
Lifecycle: INSTALLED → STARTING → RUNNING → STOPPING → STOPPED, ERROR, DISABLED
GET/POST /api/v1/modules, POST :id/start|stop|restart, PATCH :id/enabled, GET :id/health, DELETE :id (nur ADMIN)
Duplikat-Schutz: Modul-ID, Slug und Port müssen eindeutig sein (409)
Frontend: Modulverwaltungs-Seite (ZIP-Upload, Tabelle mit Status-Badges, Lifecycle-Buttons, Health-Anzeige, Remove-Dialog)
Persistente Volumes für Modul-Dateien und Logs (modules-data, module-logs)
Demo-Modul (modules/demo) als Referenzimplementierung
Backend-Tests: 72 bestanden (inkl. ModulesService-Lifecycle, Manifest-Validierung, Installer)
E2E verifiziert: Installation (201), Start → RUNNING, Healthcheck (healthy, 2 ms), Stop, Restart, Disable (stoppt Prozess), Start-Sperre bei Disable (400), Remove, RBAC (USER → 403)

Definition of Done: Module sind über /slug erreichbar, Zugriff nur mit gültiger Session und Berechtigung.

Nginx-Routing: /slug/* → Backend-Gateway (/api/v1/gateway/slug/*) mit Ausschluss-Regex für Plattform-Pfade (api, assets, login, …)
Modul-Gateway als Middleware: Session-Check (401), Slug-Suche (404), Status-Check (503), Permission-Check (403), Proxy zum internen Port
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
Fail-closed: USERs erhalten bis Phase 5 grundsätzlich 403
Startup-Recovery: Nach Container-Neustarts werden veraltete Status zurückgesetzt und aktivierte Module automatisch neu gestartet
Backend-Tests: 81 bestanden (inkl. 9 Gateway-Tests)
E2E verifiziert: /demo → 200 (Modul-Inhalt), /demo/health → 200, unbekanntes Modul → 404, ohne Login → 401, USER → 403, gestopptes Modul → 503

Definition of Done: User ↔ Module-Zuweisung, Access Control, Permission Middleware, 401/403-Handling.

user_module_permissions-Tabelle (Migration 003, GRANTED/DENIED, UNIQUE user+module, CASCADE)
Admin-API: GET/POST/DELETE /api/v1/users/:userId/modules(/:moduleId) (nur ADMIN, auditiert)
Gateway-Permission-Check an Tabelle angebunden: ADMIN immer, USER nur mit GRANTED (fail-closed)
GET /api/v1/profile/modules: Dashboard-Module (ADMIN: alle aktivierten, USER: nur freigegebene)
Frontend: Dashboard-Modul-Kacheln ausschließlich nach tatsächlichen Berechtigungen
Frontend: Berechtigungs-Modal in der Benutzerverwaltung (Freigeben/Entziehen pro Modul)
Backend-Tests: 90 bestanden (inkl. ModulePermissionsService, Gateway GRANTED-Fall)
Testszenarien aus Arbeitsplan abgedeckt: Admin → alle Module; User ohne Berechtigung → 403; User mit GRANTED → Proxy weitergeleitet

GET /health, GET /api/manifest, GET /api/me als verbindlicher Modul-Vertrag
Zentrale Authentifizierung zwischen Plattform und Modul (Identitäts-Header validieren)
Referenzmodul um den vollständigen API-Vertrag erweitern