76 lines
4.5 KiB
Markdown
76 lines
4.5 KiB
Markdown
# 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`) | ⏳ Geplant |
|
||
| 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:
|
||
|
||
- [x] Repository-Struktur
|
||
- [x] Docker-Setup (`docker compose up` → Plattform erreichbar)
|
||
- [x] Frontend (React, Vite, Tailwind, Design-System-Komponenten)
|
||
- [x] Backend (NestJS, REST `/api/v1`, OpenAPI/Swagger)
|
||
- [x] PostgreSQL mit persistentem Volume
|
||
- [x] Migrationen (eigener Runner mit Advisory-Lock) + Seed (Rollen, Admin)
|
||
- [x] Login / Logout (Argon2id, serverseitige Sessions, HttpOnly-Cookies)
|
||
- [x] CSRF-Schutz, Rate Limiting, Account Lockout
|
||
- [x] User-Modell & Rollen (ADMIN/USER, RBAC-Guards)
|
||
- [x] Audit-Log (LOGIN_SUCCESS, LOGIN_FAILED, LOGOUT)
|
||
- [x] Health-Endpoint (`/api/v1/health`)
|
||
- [x] Admin-Dashboard sichtbar (inkl. Systemstatus)
|
||
- [x] Backend-Unit-Tests (Auth, Session, Passwort, Validierung)
|
||
|
||
## Phase 2 – Benutzerverwaltung (abgeschlossen)
|
||
|
||
Definition of Done: Admin kann Benutzer vollständig verwalten.
|
||
|
||
- [x] `GET/POST/PATCH/DELETE /api/v1/users/*` (nur `@Roles('ADMIN')`)
|
||
- [x] Benutzerliste, Benutzer anlegen (Zod-Validierung, Duplikat-Schutz 409)
|
||
- [x] Benutzer bearbeiten (Anzeigename, E-Mail, Rolle)
|
||
- [x] Benutzer deaktivieren/aktivieren (Sessions werden sofort ungültig)
|
||
- [x] Passwort-Reset durch Admin (alle Sessions des Benutzers werden gelöscht)
|
||
- [x] Schutzregeln: keine Selbst-Deaktivierung/-Löschung, letzter aktiver Admin geschützt
|
||
- [x] Profil-Endpunkte (`GET /api/v1/profile`, `PATCH /api/v1/profile/password`)
|
||
- [x] Eigenes Passwort ändern (Verifikation des aktuellen Passworts, andere Sessions werden abgemeldet)
|
||
- [x] Frontend: Benutzerverwaltungs-Seite (Tabelle, Create/Edit/Reset/Delete-Modals, Toasts)
|
||
- [x] Frontend: Profil-Seite mit Passwortänderung
|
||
- [x] UI-Komponenten: Modal, Select, Toast (Design-System erweitert)
|
||
- [x] Backend-Tests: 49 bestanden (inkl. UsersService, ProfileService)
|
||
- [x] 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.
|
||
|
||
- [x] `modules`-Tabelle (Migration 002) mit Lifecycle-Status und eindeutigen Ports/Slugs
|
||
- [x] Manifest-Vertrag `module.json` (Zod: ID, Name, Version, Slug, Runtime, Entrypoint, Port 41000–41999, Healthcheck, apiVersion)
|
||
- [x] ZIP-Installer mit Manifest-Validierung, Größenlimit (10 MB) und **Zip-Slip-Schutz**
|
||
- [x] Modul-Prozess-Manager: Start/Stop (SIGTERM→SIGKILL) als Kindprozesse, minimale ENV (keine Plattform-Secrets), eigene Log-Dateien
|
||
- [x] Healthcheck-Service mit Startup-Grace (10 Retries × 500 ms)
|
||
- [x] Lifecycle: INSTALLED → STARTING → RUNNING → STOPPING → STOPPED, ERROR, DISABLED
|
||
- [x] `GET/POST /api/v1/modules`, `POST :id/start|stop|restart`, `PATCH :id/enabled`, `GET :id/health`, `DELETE :id` (nur ADMIN)
|
||
- [x] Duplikat-Schutz: Modul-ID, Slug und Port müssen eindeutig sein (409)
|
||
- [x] Frontend: Modulverwaltungs-Seite (ZIP-Upload, Tabelle mit Status-Badges, Lifecycle-Buttons, Health-Anzeige, Remove-Dialog)
|
||
- [x] Persistente Volumes für Modul-Dateien und Logs (`modules-data`, `module-logs`)
|
||
- [x] Demo-Modul (`modules/demo`) als Referenzimplementierung
|
||
- [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)
|
||
|
||
- 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 |