Files
mpm/docs/PHASES.md

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

  • 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

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