certvia/docs/STAND-dev-branch.md

Entwicklungsstand dev — Konsolidierte Übergabe (PM + neue Entwickler)

Stand: 2026-07-23 · Branch dev (19 Commits vor main, gepusht auf Gitea) · Basis-Doku: docs/HANDOVER-DEV.md, docs/HANDOVER-PM.md, docs/SPEC.md Zweck: Ein Dokument, das den kompletten Stand der Weiterentwicklung auf dev zusammenfasst — fachlich (für PM) und technisch (für einen neuen Entwickler). dev ist noch nicht nach main gemergt.

---

1. Executive Summary

Auf main lag das Fundament (Auth/RBAC/Mandanten-Isolation, Assets/BIA, Risiko, Maßnahmen, Abhängigkeiten, Lieferanten, Richtlinien Phase 1/2a, Admin-Konsole Phase 1). Der Branch dev ergänzt vier große Blöcke — alle mit tsc+lint+build, Modul-Guard-Check und (wo relevant) Browser-Verifikation abgeschlossen:

1. Produktionshärtung Phase 1 — API-seitige Modul-Durchsetzung, getrennter Superadmin-Store mit eigenem Login + MFA, nicht-destruktiver Richtlinien-Re-Import.
2. Benutzer- & Rollenverwaltung (ohne E-Mail-Flow) — Plattform-Admin verwaltet Nutzer je Mandant; Mandanten-Admin verwaltet Nutzer und Rollen intern; Force-Change-Passwort, Passwort-Policy, optionale MFA je Nutzer; Popup-UI wie bei Assets.
3. Freigabe-Workflow + Aufgaben-Modul — Richtlinien-Freigabe an eine konkrete Person, Bearbeitung im neuen Modul „Aufgaben", Dashboard-Kachel; plus zentralisierte Richtlinien-Governance (zentrale Variablen, Schutzbedarf, Coverage-Filter nach Assessment-Level).
4. GAP-Report-Umsetzung (Richtlinien-Vorlagenpaket) — WP1–WP4 + E2: sechs neue Verfahrensanweisungen (ISB-Volltexte), Inline-VA-Verlinkung, Rendering-Fix, generisches editierbares Register-Datenmodell.

Migrationen (6 neu, laufen beim Deploy automatisch über den Init-Container): platform_admins · policy_lifecycle_archived · user_mgmt_and_platform_settings · tasks · strip_tool_variable_articles · managed_registers

---

2. Für das Projektmanagement — fachlicher Status

✅ Neu fertig auf dev

Thema	Nutzen	Status
API-seitige Modul-Durchsetzung	Deaktiviertes Modul sperrt jetzt auch Schreibzugriffe serverseitig (nicht nur Navigation); automatischer Vollständigkeitscheck als Build-Gate	✅
Getrennter Superadmin-Login	Betreiber-Zugang unter /platform/login mit eigenem Store, ohne Mandantenkontext; Kundenfachdaten für Superadmin gesperrt	✅
MFA (optional)	TOTP für Plattform-Admins und Mandanten-Nutzer freiwillig; Policy-Flag „MFA-Pflicht" kann Erzwingung wiederherstellen; Recovery-Codes	✅
Benutzerverwaltung (Superadmin)	Superadmin legt je Kunde Nutzer an (Initial-/Einmal-Passwort), weist Rollen zu, deaktiviert/reaktiviert, setzt Passwörter zurück	✅
Benutzer- & Rollenverwaltung (Kunde)	Mandanten-Admin verwaltet intern Nutzer und Rollen (eigene Rollen + granulare Rechte, Standardrollen klonbar); strikt mandantengetrennt; Lockout-Schutz	✅
Nutzer-Onboarding ohne E-Mail	Start mit Initialpasswort + erzwungenem Wechsel beim ersten Login; E-Mail-Einladung (Paket 4) später nahtlos ergänzbar	✅
Popup-Bedienung	Anlegen/Bearbeiten von Nutzern über Popups wie bei Assets; Tabelle nur Anzeige	✅
Zuständigkeiten geklärt	Superadmin steuert Kern-Einstellungen (Module, TISAX-Tiefe); Mandanten-Admin nur seinen Bereich (Stammdaten, Nutzer/Rollen)	✅
Richtlinien-Governance zentral	Zentrale Variablen (Unternehmensname, Rollen, Schutzbedarf) nur in Einstellungen pflegbar; Coverage-Matrix zeigt nur Controls des aktiven Assessment-Levels (AL2 ohne „sehr hoch")	✅
Freigabe-Workflow + Aufgaben	Einreicher wählt Freigeber → Aufgabe; Freigeben/Ablehnen (mit Kommentar) im Modul „Aufgaben" (Vier-Augen); Dashboard-Kachel für offene Freigaben	✅
Nicht-destruktiver Re-Import	Richtlinien-Paket-Updates erhalten Status/Freigabe/Overrides/Variablenwerte; entfernte Einträge werden deaktiviert statt gelöscht; Änderungsreport	✅
GAP-Report Richtlinien	6 neue Verfahrensanweisungen (VA-14..19), alle zuständigen VAs inline verlinkt, Rendering-Fehler behoben, verwaltete Register editierbar	✅

🟥 Bewusst zurückgestellt / offen

Thema	Anmerkung
Paket 4 — SMTP + E-Mail-Einladungs-/Reset-Flow	Auf Kundenwunsch später; Aktivierung läuft vorerst über Initial-/Einmal-Passwort, gekapselt für spätere Token-Aktivierung
Tenant-weite MFA-Pflicht scharfschalten	Flag securityPolicy.mfaRequired vorhanden + von „MFA deaktivieren" respektiert; Enrollment-Erzwingung beim Login noch nicht verdrahtet (analog Force-Change-Gate)
Admin Phase 2	Impersonation, Plan/Limits, Logo-Upload, DSGVO-Export/Retention
NIS2-Modul	nie begonnen (großes Framework, Incident-Reporting mit Fristen-Timern)
Richtlinien-Versionierung/Diff, DOCX/PDF-Export	offen
ISB-Freigabe der neuen GAP-Texte	fachlicher Prozessschritt (kein Code): neue/geänderte VA-/Richtlinien-Texte durch den ISB freigeben
Platzhalter-Module	SoA & Controls, Vorfälle, Nachweise, Management-Review, KI-Chat

---

3. Für neue Entwickler — technische Landkarte

Setup, Stack, Konventionen und Fallstricke unverändert in docs/HANDOVER-DEV.md (§1–§9). Hier nur, was dev ergänzt.

3.1 Neue Datenmodelle (Prisma)

Modell	Zweck	Mandantengebunden?
PlatformAdmin	Getrennter Superadmin-Store (kein tenant_id), Argon2id, TOTP-Secret, Recovery-Codes, Lockout	nein (plattformweit)
PlatformSetting (Singleton)	Plattform-Policy, u. a. mfaRequired	nein
Task / TaskComment	Generisches Aufgaben-/Freigabe-Modell (erster Typ policy_approval), Kommentar-Historie	ja
ManagedRegister / RegisterRow	Generisches editierbares Register (code, columns JSON, Cross-Links supplier/asset)	ja
User.* neu	mustChangePassword, mfaEnrolledAt, recoveryCodes	ja
PolicyDocument.archivedAt, PolicyRequirement.archivedAt	Lifecycle für nicht-destruktiven Re-Import (deaktivieren statt löschen)	ja
AuditLog.tenantId nullable	Plattform-Ereignisse ohne Mandantenbezug (scope=platform)	—

Alle neuen tenant-gebundenen Modelle sind in TENANT_MODELS (src/server/db.ts) und haben RLS-Policies (in den jeweiligen Migrationen).

3.2 Auth-Architektur (wichtig!)

• Zwei getrennte NextAuth-Instanzen: Mandanten-Login (src/server/auth.ts, /login) und Plattform-Login (src/server/platform-auth.ts, eigener Cookie + basePath /api/platform-auth, /platform/login). Plattform-Session trägt keinen tenantId.
• Superadmin-Bereich liegt unter src/app/(platform)/… (Layout erzwingt Plattform-Session + ggf. MFA); Mandanten-App unter src/app/(app)/….
• MFA-Helfer src/server/mfa.ts (otplib TOTP + Recovery-Codes) — von Plattform- und Nutzer-MFA gemeinsam genutzt.
• Force-Change: (app)-Layout prüft Kontostatus/mustChangePassword autoritativ aus der DB → /change-password bzw. Abmelde-Screen bei deaktivierten Konten.
• Passwort-Policy: src/lib/password-policy.ts (reine Validierung, client-safe) + src/server/password.ts (Argon2id + Generator); Quelle TenantSettings.securityPolicy.password.

3.3 Modul-Durchsetzung (§3.4) — Konvention für neue Actions

• Jede mutierende Server-Action eines gegateten Moduls läuft über moduleGuard("<key>") (src/server/action-guard.ts): Session → assertModuleEnabled → RBAC.
• Vollständigkeitscheck scripts/check-module-guards.ts (als prebuild verdrahtet): jede Datei in src/server/actions/ muss dort eingetragen sein (Modul-Key oder EXEMPT), sonst failt der Build. → Neue Action-Datei? Dort eintragen.
• Neues Modul tasks in src/lib/modules.ts (für Bestands-Tenants per Default aktiv, da fehlende TenantModule-Zeile = aktiv).

3.4 Wo liegt was (neu)

• Superadmin/Plattform: src/app/(platform)/admin/**, /platform/{login,enroll-mfa,profile}, src/server/actions/{admin,platform,platform-users}.ts.
• Benutzer-/Rollenverwaltung (Kunde): src/app/(app)/settings/users/, src/server/actions/{tenant-users,account}.ts, Komponenten user-table.tsx/user-forms.tsx/role-manager.tsx.
• Aufgaben/Freigabe: src/app/(app)/tasks/, src/server/actions/tasks.ts (+ submitForApproval in policies.ts); Dashboard-Kachel in dashboard/page.tsx.
• Register: src/components/generic-register.tsx, src/server/actions/register.ts, Definitionen in prisma/import-managed.ts (GENERIC_REGISTERS).
• Richtlinien-Import (nicht-destruktiv): prisma/import-policies.ts (Diff/Upsert, { dryRun }, Änderungsreport, archivedAt).
• Vorlagenpaket (Source of Truth): seed/isms-vorlagenpaket-v2/ — 28→34 Dokumente (VA-14..19 neu), mapping.json, variables.schema.json, Baseline, Nachweisregister, _verify.py (Rendering-/Anker-Check; nach Änderungen python3 _verify.py → OK).

3.5 Konventionen / Fallstricke (Ergänzungen)

• Dev-Server & Server-Actions: Änderungen an Server-Actions greifen im Turbopack-Dev manchmal erst nach Neustart des Dev-Servers.
• Migrations-Flow Prisma 7 wie gehabt (migrate diff --from-config-datasource … --to-schema … --script, dann RLS-DO-Block manuell anhängen, migrate deploy). Data-Migrationen (z. B. strip_tool_variable_articles) sind reine SQL-UPDATE-Migrationen.
• Zentrale Variablen (Organisation/Rollen/Schutzbedarf-Flags, src/lib/policy-variables.ts) sind im Richtlinien-Editor gesperrt und werden serverseitig geblockt — nur in /settings pflegbar.
• Rendering (Variante B): Tool-Variablen-Defaults ohne führenden Artikel (TOOL_TICKET=„Ticketsystem" etc.); der Fließtext setzt Artikel/Deklination. Bestandswerte werden per Migration migriert.
• Register vs. Managed-Register-Docs: die verwalteten Register (CRYPTO/RISKMATRIX/CLASSIFICATION/HANDBUCH) sind spezifische Modelle; die neuen REG-* nutzen das generische ManagedRegister-Modell. importPolicies archiviert nur den Paket-Namensraum (L00/R*/VA-*/BASELINE/NACHWEIS) — Register bleiben unberührt.

3.6 Demo-Logins (Passwort Demo1234!)

• Mandanten-Login /login: admin@demo.example (Mandanten-Admin + ISB), bea.approver@demo.example (ISB, zweiter Freigeber für den Vier-Augen-Workflow), auditor@…, owner@…, user@….
• Plattform-Login /platform/login: admin@demo.example (getrennte Session; MFA optional, Enrollment beim ersten Login nur wenn Policy es verlangt).

---

4. Commit-Übersicht (main..dev, neueste zuerst)

95d4479 GAP WP3.1: IMPL-Texte mit verwalteten Registern verdrahtet
bd56a47 GAP WP3.0: Generisches, editierbares Register-Datenmodell + Editor
b9784e5 GAP E2: ISA 3.1.3-Stub entfernt (3.1.2 deprecated)
b7d5df4 GAP WP2.2 (Rendering Variante B) + WP4 (Feinschliff)
36c2903 GAP WP1: Neue VAs 14–19 + Register + Baseline + Eltern-Wiring
522508a GAP WP2.1: Inline-VA-Verweise + Verify-Fix (F17)
742277f Doku: Benutzer-Popups, Aufgaben-Modul, Richtlinien-Governance, Demo-Approver
1d8f563 Freigabe-Workflow + Aufgaben-Modul + Dashboard-Kachel
73c9813 Benutzerverwaltung als Popup (Einstellungen + Admin)
959d816 Richtlinien-Fixes: zentrale Variablen, Schutzbedarf zentral, Coverage nach Level
d38b265 Benutzer bearbeiten (Name/E-Mail) + Kern-Einstellungen nur Superadmin
303dcd0 Doku: Produktionshärtung + Benutzer-/Rollenverwaltung
d0821e2 Paket B — Mandanten-Admin: Benutzer- & Rollenverwaltung
3db820e Paket C — MFA optional (Superadmin + Tenant)
908b098 Paket A — Plattform-Admin: Benutzerverwaltung je Mandant
db36c79 Fundament Benutzer-/Rollenverwaltung: Schema, Passwort-Policy, Force-Change
e07dcd9 Nicht-destruktiver Richtlinien-Re-Import (Härtung Paket 3)
8e4040d Separater Superadmin-Store + eigener Login + MFA (Härtung Paket 2)
8348764 API-seitige Modul-Durchsetzung (§3.4, Härtung Paket 1)

---

5. Deployment & Verifikation

• Coolify-Deploy: dev deployen; die 6 neuen Migrationen laufen automatisch im Init-Container (prisma migrate deploy), Bootstrap-Seed legt Demo-Daten + Demo-Approver an.
• Lokale Verifikation: npx tsc --noEmit → npm run lint → npm run build (führt prebuild-Guard-Check aus); für das Vorlagenpaket python3 seed/isms-vorlagenpaket-v2/_verify.py (OK = rückstandsfrei, Mapping sauber).
• Merge dev → main: liegt beim PM/Lead (Gitea-PR: …/msolarczek/ISMS-Tool/pulls/new/dev).

---

6. Empfohlene nächste Schritte

1. ISB-Freigabe der neuen/angepassten Richtlinien- und VA-Texte (fachlich).
2. Paket 4 — SMTP + E-Mail-Einladungs-/Aktivierungs-/Reset-Flow (Aktivierung ist bereits gekapselt).
3. Tenant-weite MFA-Pflicht scharfschalten (Enrollment-Gate).
4. Admin Phase 2 (Impersonation, Plan/Limits) oder NIS2-Modul — je nach Vertriebs-/Compliance-Priorität.