60 lines
3.0 KiB
Markdown
60 lines
3.0 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) | ⏳ 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 |