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

## Nächste Schritte (Phase 3 – Modul-System)

- Modul-Datenmodell (`modules`-Tabelle) und Manifest-Vertrag (`module.json`)
- Modul-Installation als ZIP-Paket (Validierung, Dateien, Registrierung)
- Modul-Lifecycle (INSTALLED/STARTING/RUNNING/STOPPING/STOPPED/ERROR/DISABLED)
- Prozessverwaltung der Modul-Prozesse über Supervisor
- Healthchecks und Statusanzeige im Admin-Bereich