feat: Phase 2 – Benutzerverwaltung (CRUD-API, Profil, UI)

docs/ARCHITECTURE.md

@@ -134,8 +134,24 @@ Security Hardening (Penetrationstests, Dependency/Container-Scans, HSTS, Backup/
 | POST | `/api/v1/auth/logout` | Session | Beendet die aktuelle Session |
 | GET | `/api/v1/auth/me` | Session | Angemeldeter Benutzer (Id, Rolle, …) |
 | GET | `/api/v1/health` | Public | Systemstatus (Backend, DB-Latenz, Version, Uptime) |
+| GET | `/api/v1/users` | Admin | Alle Benutzer |
+| POST | `/api/v1/users` | Admin | Benutzer anlegen (409 bei Duplikat) |
+| GET | `/api/v1/users/:id` | Admin | Einzelner Benutzer |
+| PATCH | `/api/v1/users/:id` | Admin | Bearbeiten / Aktivieren / Deaktivieren |
+| PATCH | `/api/v1/users/:id/password` | Admin | Passwort zurücksetzen |
+| DELETE | `/api/v1/users/:id` | Admin | Benutzer löschen |
+| GET | `/api/v1/profile` | Session | Eigenes Profil |
+| PATCH | `/api/v1/profile/password` | Session | Eigenes Passwort ändern |
 
-OpenAPI/Swagger UI: `/api/docs` · Ab Phase 2: `/api/v1/users/*`, `/api/v1/modules/*`, `/api/v1/permissions/*`, `/api/v1/audit/*`.
+OpenAPI/Swagger UI: `/api/docs` · Ab Phase 3: `/api/v1/modules/*`, `/api/v1/permissions/*`, `/api/v1/audit/*`.
+
+### Schutzregeln der Benutzerverwaltung
+
+- Keine Selbst-Deaktivierung und keine Selbst-Löschung (400)
+- Der letzte aktive Administrator kann nicht herabgestuft, deaktiviert oder gelöscht werden (400)
+- Deaktivierte Benutzer werden sofort von allen Sessions abgemeldet
+- Passwort-Reset (Admin) meldet den Benutzer von allen Sessions ab
+- Eigenes Passwort ändern meldet alle übrigen Sessions ab (aktuelle bleibt aktiv)
 
 ## 9. Modul-Vertrag (Ausblick Phase 3+)
 

docs/PHASES.md

@@ -5,7 +5,7 @@ Der Arbeitsplan sieht zehn inkrementelle Phasen vor. Nach jeder Phase muss das S
 | Phase | Bereich | Status |
 |---|---|---|
 | 1 | Grundgerüst (Docker, DB, Login, Rollen) | ✅ Abgeschlossen |
-| 2 | Benutzerverwaltung | ⏳ Geplant |
+| 2 | Benutzerverwaltung | ✅ Abgeschlossen |
 | 3 | Modul-System (Manifest, Installation, Lifecycle) | ⏳ Geplant |
 | 4 | Gateway & dynamisches Routing (`/slug`) | ⏳ Geplant |
 | 5 | Berechtigungssystem (User ↔ Module) | ⏳ Geplant |
@@ -33,9 +33,28 @@ Definition of Done:
 - [x] Admin-Dashboard sichtbar (inkl. Systemstatus)
 - [x] Backend-Unit-Tests (Auth, Session, Passwort, Validierung)
 
-## Nächste Schritte (Phase 2 – Benutzerverwaltung)
+## Phase 2 – Benutzerverwaltung (abgeschlossen)
 
-- Benutzerliste, Benutzer erstellen/bearbeiten/deaktivieren
-- Passwortänderung und Reset durch Admin
-- `GET/POST/PATCH/DELETE /api/v1/users/*` mit `@Roles('ADMIN')`
-- Frontend-Seite `/admin/users` mit Tabelle, Formular und Bestätigungsdialogen
+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