lxe/mpm
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
5d775c317a3a4aa63c72f2cf5ba22399a3c57a5d
mpm/docs/PHASES.md

5.6 KiB
Raw Blame History

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) ⏳ Geplant
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:

  • Repository-Struktur
  • Docker-Setup (docker compose up → Plattform erreichbar)
  • Frontend (React, Vite, Tailwind, Design-System-Komponenten)
  • Backend (NestJS, REST /api/v1, OpenAPI/Swagger)
  • PostgreSQL mit persistentem Volume
  • Migrationen (eigener Runner mit Advisory-Lock) + Seed (Rollen, Admin)
  • Login / Logout (Argon2id, serverseitige Sessions, HttpOnly-Cookies)
  • CSRF-Schutz, Rate Limiting, Account Lockout
  • User-Modell & Rollen (ADMIN/USER, RBAC-Guards)
  • Audit-Log (LOGIN_SUCCESS, LOGIN_FAILED, LOGOUT)
  • Health-Endpoint (/api/v1/health)
  • Admin-Dashboard sichtbar (inkl. Systemstatus)
  • Backend-Unit-Tests (Auth, Session, Passwort, Validierung)

Phase 2 – Benutzerverwaltung (abgeschlossen)

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

Phase 3 – Modul-System (abgeschlossen)

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)

Phase 4 – Gateway & dynamisches Routing (abgeschlossen)

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

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