Doku: Produktionshärtung + Benutzer-/Rollenverwaltung in HANDOVER-DEV/PM

- HANDOVER-DEV §10: neue Härtungs-/Verwaltungspakete dokumentiert (Modul-Guard,
  Plattform-Admin-Store + optionale MFA, nicht-destruktiver Re-Import, Benutzer-/
  Rollenverwaltung, Force-Change, Passwort-Policy, Nutzer-MFA) inkl. Dateiverweise;
  §11 aktualisierte Einstiegspunkte (Paket 4 SMTP, tenant-weite MFA-Pflicht).
- HANDOVER-PM: Statusblock „Neu auf dev" mit umgesetzten Paketen; Paket 4 als
  zurückgestellt markiert. Stand/Branch-Zeilen aktualisiert.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/HANDOVER-DEV.md

@@ -1,8 +1,8 @@
 # Entwickler-Übergabe — ISMS-Tool
 
-> Stand: 2026-07-20 · Branch `main` · letzter Commit `6ddeedf`
+> Stand: 2026-07-22 · Branch `dev` (Produktionshärtung + Benutzerverwaltung) · Basis `main`
 > Zweck: Kontext, Setup und Konventionen, damit ein neuer Entwickler direkt weiterarbeiten kann.
-> Fachlicher Status (fertig/offen) siehe **`docs/HANDOVER-PM.md`**.
+> Fachlicher Status (fertig/offen) siehe **`docs/HANDOVER-PM.md`**. Neue Härtungs-/Verwaltungspakete: §10.
 
 ---
 
@@ -165,10 +165,25 @@ Nach jeder Änderung: **`npx tsc --noEmit`** → **`npm run lint`** → **`npm r
 
 ---
 
-## 10. Nächste sinnvolle Aufgaben (Einstiegspunkte)
+## 10. Produktionshärtung & Benutzerverwaltung (umgesetzt, Branch `dev`)
 
-- **API-Modul-Enforcement vervollständigen (S):** `await requireModule("<key>")` in den `guard()`/Action-Einstiegen der übrigen Action-Dateien ergänzen (Vorlage: `actions/policies.ts`).
+Aufbauend auf dem Fundament wurden mehrere Härtungspakete umgesetzt (feingranulare Commits auf `dev`):
+
+- **API-Modul-Durchsetzung (§3.4):** zentraler `moduleGuard("<key>")` in `src/server/action-guard.ts`; jede mutierende Action eines gegateten Moduls läuft über `guard(...)` (Session → `assertModuleEnabled` → RBAC). Vollständigkeitscheck `scripts/check-module-guards.ts` (Registry Action→Modul) als `prebuild` — Build failt bei nicht zugeordneter Action-Datei. Neue Action-Datei ⇒ dort eintragen (Modul-Key oder `EXEMPT`).
+- **Plattform-Admins getrennt:** Store `PlatformAdmin` (kein `tenant_id`), eigene NextAuth-Instanz `src/server/platform-auth.ts` (eigener Cookie/basePath `/api/platform-auth`, Session ohne Tenant), Login `/platform/login`, Bereich unter `src/app/(platform)/…`. **MFA (TOTP, `src/server/mfa.ts`) ist optional** — Enrollment nur erzwungen, wenn `PlatformSetting.mfaRequired` (Singleton) an ist; Umschaltung + Self-Service unter `/platform/profile`. Rate-Limit/Lockout am Login bleiben. Audit `scope=platform` via `writePlatformAudit`.
+- **Nicht-destruktiver Richtlinien-Re-Import:** siehe §9 Punkt 2.
+- **Benutzer- & Rollenverwaltung (ohne E-Mail-Flow):**
+  - Plattform-Admin je Mandant: `src/server/actions/platform-users.ts` + `components/platform-tenant-users.tsx`, eingebettet in `/admin/[id]`. Anlegen mit **Initial-/Einmal-Passwort** (selbst setzen oder generiert, einmalig angezeigt), Rollen, Deaktivieren/Reaktivieren, Passwort-Reset.
+  - Mandanten-Admin intern: `src/server/actions/tenant-users.ts` + `components/tenant-users-manager.tsx`/`role-manager.tsx`, Seite `/settings/users` (nur `user:manage`/`role:manage`). Benutzer-CRUD **und** Rollen-CRUD (eigene Rollen + Permissions; Standardrollen schreibgeschützt/klonbar). Strikt `dbForTenant(session)` → kein Cross-Tenant. **Lockout-Schutz** für den letzten aktiven Mandanten-Admin.
+  - **Force-Change:** neue Nutzer starten mit `mustChangePassword=true`; das `(app)`-Layout leitet autoritativ (DB) auf `/change-password` und sperrt deaktivierte Konten. Passwort-Policy: `src/lib/password-policy.ts` (Validierung, client-safe) + `src/server/password.ts` (Argon2id-Hash + Generator); Quelle `TenantSettings.securityPolicy.password`.
+  - **Nutzer-MFA optional:** Tenant-Login (`auth.ts`) verlangt TOTP nur bei eingerichteter MFA; Self-Service unter `/account`. `role:manage` ist neu im RBAC-Katalog (Mandanten-Admin).
+- **Zukunftssicher:** `createTenantUser`/`createUser` kapseln die Aktivierung über Initial-/Einmal-Passwort — der spätere **E-Mail-Einladungs-Flow (Paket 4)** lässt sich als alternative Aktivierung (Token statt Passwort) einhängen, ohne die UI umzubauen.
+
+## 11. Nächste sinnvolle Aufgaben (Einstiegspunkte)
+
+- **SMTP + Einladungs-/Aktivierungs-/Reset-Flow (Paket 4, M):** transaktionale Mails (Nodemailer), signierte Einladungs-/Reset-Tokens; ersetzt/ergänzt den Initial-Passwort-Weg.
 - **Admin Phase 2 — Impersonation (M):** neues Modell `ImpersonationSession`, Cookie-basierter effektiver Tenant + Banner, Ablauf, Audit.
+- **Tenant-weite MFA-Pflicht scharfschalten (S):** `securityPolicy.mfaRequired` wird von `disableOwnMfa` bereits respektiert; Enrollment-Erzwingung analog zum Force-Change-Gate (Seite außerhalb der `(app)`-Shell) nachziehen.
 - **NIS2-Modul (L):** eigenes Modul inkl. Incident-Reporting mit Fristen-Timern.
 - **Richtlinien-Versionierung/Diff (M–L)** und **DOCX/PDF-Export (M)**.