Anlegen/Bearbeiten von Nutzern erfolgt jetzt wie bei Assets über URL-gesteuerte
Popups (?new/?edit, modal.tsx) statt Inline in der Tabelle.
- Neue generische Komponenten: user-table.tsx (reine Anzeige-Tabelle, Zeilen
verlinken auf ?edit, Button auf ?new) und user-forms.tsx (UserCreateForm /
UserEditForm; Name/E-Mail + Rollen + Status + Passwort-Reset; Einmal-Passwort
im Popup). Actions werden als gebundene Props übergeben — dieselben Formulare
für Plattform- und Mandanten-Verwaltung.
- /settings/users und /admin/[id] rendern die Tabelle + Modals; die alten
Inline-Komponenten (platform-tenant-users, tenant-users-manager) entfernt.
- Einstellungen: „Benutzer & Rollen"-Kachel ist als Ganzes klickbar (Link).
Browser-verifiziert: Anlegen im Popup (Einmal-Passwort + Fertig), Zeilenklick
öffnet Bearbeiten-Popup vorbefüllt; Admin-Portal analog. tsc + lint + build +
Guard-Check grün.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Zentrale Variablen (Organisation + Rollen + Schutzbedarf-Flags, lib/policy-variables.ts)
sind im Richtlinien-Editor ausgeblendet und werden nur noch in den Einstellungen
gepflegt; updatePolicyVariable/updateScopedVariables blocken zentrale Keys zusätzlich
serverseitig.
- Schutzbedarf/TISAX wird ausschließlich zentral gesteuert (Superadmin): Override je
Richtlinie entfernt (setProtectionOverride + UI weg), globaler TISAX-Schalter im
Policy-Modul entfernt (setGlobalTisaxLevel weg) → nur noch Read-only-Anzeige im
Editor und in der Bibliothek. Rendering nutzt stets den globalen Level.
- Coverage-/Referenzmatrix zeigt nur Anforderungen des aktiven Assessment-Levels
(Bedingung erfüllt): bei AL2 keine „sehr hoch"-Controls (browser-verifiziert:
297 statt 316 Anforderungen, 0 SEHR HOCH); AL3 zeigt alle.
tsc + lint + build grün; Edit-Seite: Schutzbedarf read-only, zentrale Variablen gesperrt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Nachschärfung der Benutzer-/Rollenverwaltung auf Basis des Feedbacks.
- Nutzer editierbar: Name & E-Mail (eindeutig je Mandant) je Nutzer in beiden
Konsolen — updateTenantUser (Plattform) / updateUser (Tenant), inline-Formular
in platform-tenant-users.tsx und tenant-users-manager.tsx. Rollen/Status/Reset
bestanden bereits (browser-verifiziert: Name/E-Mail, Rollen, Deaktivieren, Reset).
- Kern-Einstellungen ausschließlich Superadmin: TISAX-/Schutzbedarf-Tiefe wandert
in die Admin-Konsole (setTenantTisaxLevel, AL2/AL3 in /admin/[id]); aus den
Tenant-Einstellungen entfernt (nur noch Read-only-Anzeige). updateTenantSettings
fasst tisaxLevel/Schutzbedarf-Flags nicht mehr an. Module waren bereits Superadmin.
- Tenant-Einstellungen: „Benutzer & Rollen"-Bereich verlinkt und sichtbar
(user:manage/role:manage) — Verwaltung unter /settings/users.
Browser-verifiziert: Admin-Konsole editiert Name/E-Mail/Rollen/Status/Passwort und
schaltet TISAX AL3; /settings zeigt Benutzer-Bereich + TISAX read-only;
/settings/users listet Nutzer mit Editierfeldern. tsc + lint + build + Guard grün.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Eigener Bereich /settings/users (verlinkt aus /settings), sichtbar nur mit
user:manage bzw. role:manage. Strikt mandantenintern (dbForTenant über die eigene
Session) — kein Cross-Tenant-Zugriff. Audit-Scope: tenant.
- actions/tenant-users.ts:
- Benutzer (user:manage): createUser (Initial-/Einmal-Passwort, mustChangePassword),
resetUserPassword, setUserStatus (deaktivieren/reaktivieren), setUserRoles.
- Rollen (role:manage): createRole (+ Permissions), updateRolePermissions
(Standardrollen schreibgeschützt), cloneRole (Standard klonbar), deleteRole
(nur eigene, nur ohne zugewiesene Nutzer — sonst Umzug-Hinweis).
- Lockout-Schutz: letzter aktiver Mandanten-Admin kann nicht deaktiviert werden
und ihm kann die Admin-Rolle nicht entzogen werden.
- Komponenten tenant-users-manager.tsx (Benutzer) und role-manager.tsx (Rollen +
gruppierter Permission-Katalog); Bestands-UI/Dark-Theme wiederverwendet.
Browser-verifiziert: Mandanten-Admin sieht Benutzer + Rollen des eigenen Mandanten,
legt eine eigene Rolle „Externer Prüfer" mit ausgewählten Rechten an (asset:read,
audit:read, policy:read → korrekt gespeichert); Standardrollen als schreibgeschützt
markiert. tsc + lint + build + Guard-Check grün.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
MFA ist nicht mehr erzwungen, sondern freiwillig; die Erzwingung bleibt über ein
Policy-Flag als Option erhalten (Anpassung von Phase-1-Paket 2).
Plattform-Admins:
- (platform)/layout erzwingt Enrollment nur noch, wenn PlatformSetting.mfaRequired
aktiv ist (Default: aus) → Login ohne MFA möglich.
- Profil & Sicherheit (/platform/profile): MFA freiwillig aktivieren (Enroll-Flow)
bzw. deaktivieren (nur solange keine Pflicht gilt); Recovery-Code-Anzeige.
- Policy-Flag „MFA-Pflicht" umschaltbar (setPlatformMfaRequired) — stellt die
Erzwingung ohne Codeumbau wieder her. Rate-Limit/Lockout/Audit bleiben unverändert.
Mandanten-Nutzer (analog):
- auth.ts verlangt den TOTP-/Recovery-Code beim Login nur, wenn der Nutzer MFA
eingerichtet hat; Login-Formular um optionales MFA-Feld ergänzt (i18n de/en).
- Persönliches Konto (/account): MFA selbst aktivieren (QR + Bestätigung, Recovery-
Codes) bzw. deaktivieren; disableOwnMfa respektiert eine tenant-weite MFA-Pflicht
(securityPolicy.mfaRequired) als fortbestehende Option.
Browser-verifiziert: Plattform-Login ohne MFA → /admin; Tenant-Login zeigt das
MFA-Feld; /account bietet QR-Enrollment. tsc + lint + build + Guard-Check grün.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
In der Mandanten-Detailansicht (/admin/[id]) kann der Plattform-Admin je Kunde
Benutzer anlegen und verwalten — ohne E-Mail-Flow, über Initial-/Einmal-Passwort.
- actions/platform-users.ts (Platform-Session-Guard, dbForTenant(zielTenant),
Audit scope=platform):
- createTenantUser: Name, E-Mail (eindeutig je Mandant), ≥1 Rolle; Initialpasswort
selbst setzen ODER policy-konformes Einmal-Passwort erzeugen (einmalig angezeigt);
Nutzer mit mustChangePassword=true.
- resetTenantUserPassword: neues Einmal-Passwort + erzwungener Wechsel.
- setTenantUserStatus: deaktivieren/reaktivieren.
- setTenantUserRoles: Mehrfach-Rollenzuweisung.
- Lockout-Schutz: letzter aktiver Mandanten-Admin kann nicht deaktiviert werden
und ihm kann die Admin-Rolle nicht entzogen werden.
- components/platform-tenant-users.tsx: Anlege-Formular (useActionState, zeigt das
Einmal-Passwort), Benutzerkarten mit Rollen-Checkboxen, Status-Toggle und Reset.
- /admin/[id] lädt Nutzer inkl. Rollen + Mandanten-Rollen und rendert die Verwaltung.
- Passwort-Generierung/-Prüfung gegen die Mandanten-Passwort-Policy.
- Zukunftssicher gekapselt: Einladungs-Flow (Paket 4) als alternative Aktivierung
(Token statt Initialpasswort) später einhängbar.
tsc + lint + build + Guard-Check grün. Browser-E2E folgt zusammen mit Paket C.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Plattform-Administratoren sind nicht länger isPlatformAdmin-Nutzer innerhalb eines
Mandanten, sondern ein getrennter Store mit eigener Auth-Domäne — Voraussetzung
für den sicheren Betrieb beim ersten echten Kunden.
Store & Migration
- Neues Modell PlatformAdmin (kein tenant_id): Argon2id-Hash, TOTP-Secret,
Recovery-Codes (nur SHA-256-Hashes), Fehlversuchszähler + Sperre, lastLogin.
- AuditLog.tenant_id nullable → mandantenlose Plattform-Ereignisse (scope=platform).
- Datenmigration: bestehende isPlatformAdmin-Nutzer in den neuen Store übernommen
(gleicher Hash → Login sofort möglich), Flag mandantenweit auf false gesetzt.
Getrennter Login + MFA
- Zweite NextAuth-Instanz (server/platform-auth.ts) mit eigenem Cookie und
eigenem basePath /api/platform-auth; Session trägt bewusst KEINEN tenantId.
- TOTP-MFA (otplib): Enrollment beim ersten Login (/platform/enroll-mfa, QR +
Klartext-Secret), danach bei jedem Login erzwungen; 10 einmalige Recovery-Codes.
- Härtung: Konto-Sperre nach 5 Fehlversuchen (15 min), Audit aller Anmeldungen,
Fehlversuche und Sperren (scope=platform).
Autorisierung / Trennung
- Admin-Konsole nach (platform)/admin verschoben; (platform)/layout.tsx erzwingt
Plattform-Session + aktivierte MFA. Mandanten-Session hat KEINEN Zugriff auf /admin.
- Mandanten-Shell zeigt keinen /admin-Link mehr; admin-Actions prüfen die
Plattform-Session statt des abgelösten Flags.
- provision/seed setzen isPlatformAdmin nicht mehr; Seed legt den Demo-Plattform-
Admin (admin@demo.example) im getrennten Store an.
Browser-verifiziert: Plattform-Login → erzwungenes MFA-Enrollment → Recovery-Codes →
/admin; Login ohne Code scheitert (?error=1); Mandanten-Session auf /admin wird auf
/platform/login umgeleitet. tsc + lint + build + Guard-Check grün.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Der requireModule-Guard war bislang nur exemplarisch in den Policy-Actions
gesetzt. Jetzt läuft jede mutierende Server-Action eines gegateten Moduls über
einen zentralen, modul- und rechteprüfenden Guard — ein für den Mandanten
deaktiviertes Modul weist damit auch Writes serverseitig ab (nicht nur Reads
über die Route-Layouts).
- action-guard.ts: moduleGuard("<key>") erzeugt je Modul einen guard(...perms),
der Session → Modul-Aktivierung → RBAC prüft und {session, db} zurückgibt.
- modules.ts: assertModuleEnabled(session, key) wirft (statt Redirect) bei
Deaktivierung und protokolliert die Verweigerung (Audit-Aktion "denied").
- audit.ts: Audit-Aktion "denied" + optionaler scope-Parameter.
- Alle gegateten Action-Dateien umgestellt: assets→assets, processes→bia,
risks→risk, measures→measures, suppliers/services→suppliers, policies→policies.
Freigabe/Ablehnung der Richtlinien laufen jetzt ebenfalls über den Modul-Guard.
- Vollständigkeitscheck scripts/check-module-guards.ts (Registry Action→Modul):
schlägt fehl bei nicht zugeordneter Datei, fehlendem moduleGuard oder einer
Action ohne guard(...). Als prebuild verdrahtet ⇒ Build failt bei vergessenem
Endpoint. admin/tenant-settings sind als EXEMPT (eigene Auth) markiert.
Verifiziert: tsc sauber, lint sauber, Guard-Check grün (9 Dateien), Negativ-Probe
(ungemappte Action-Datei) failt den Check wie erwartet.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Compose reicht nur explizit im environment-Block gelistete Vars an den Container.
AUTH_TRUST_HOST fehlte -> Auth.js v5 hinter dem Proxy warf UntrustedHost. Jetzt mit
Default true, muss in Coolify nicht extra gesetzt werden.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Der migrate-Container beendet sich nach 'migrate deploy' (restart:no) und der
app-Container hat kein tsx/keine Seed-Dateien -> manueller Seed unpraktisch.
Lösung: migrate führt bei RUN_DEMO_SEED=true nach der Migration den idempotenten
Demo-Seed aus (admin@demo.example / Demo1234!). In Prod die Variable weglassen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
prisma.config.ts löst env("DATABASE_URL") beim Laden auf; Coolify reicht die
Variable nur als Build-ARG (nicht in process.env) -> 'prisma generate' bricht mit
PrismaConfigEnvError ab. Lokal maskiert, weil die lokale .env ins Image kopiert wurde.
- builder-Stage: Dummy-DATABASE_URL als ENV (Runtime-Wert aus Coolify-Env überschreibt)
- .dockerignore: .env & Co. aus dem Build-Kontext (keine Secrets im Image; bildet
die Coolify-Bedingung lokal ab)
Verifiziert per Docker-Build ohne .env: prisma generate + next build laufen durch.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
npm ci installiert unter node:22-alpine (musl) die plattformspezifischen
optionalen Native-Pakete (lightningcss/@tailwindcss/oxide *-musl) nicht
zuverlässig -> 'next build' bricht mit "Cannot find module
...lightningcss.linux-*-musl.node" ab. Lokal mit vollem Docker-Build
(builder-Target) verifiziert: mit npm install kompiliert next build sauber.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
npm 11 (lokal) und npm 10 (node:22-Image) lösen @swc/helpers unterschiedlich
auf; der Lock enthielt 0.5.23 nicht -> 'npm ci' im Build brach ab. Lock mit
npm@10.9.0 regeneriert, Konsistenz via 'npm ci --dry-run' geprüft.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Deaktivierte Module werden nicht nur in der Navigation ausgeblendet, sondern
serverseitig gesperrt:
- requireModule-Guard (server/modules.ts): prüft TenantModule und leitet bei
deaktiviertem Modul auf /dashboard?module=disabled um (fehlende Zeile = aktiv).
- Modul-Layout je Routenbereich (assets, processes, risks, measures, policies,
suppliers, dependencies) — deckt alle Unterrouten mit ab (GET-Zugriff).
- API-Ebene: requireModule zusätzlich im gemeinsamen guard() der Policy-Actions
(Layout-Guard läuft bei Server-Actions erst nach der Mutation).
Verifiziert im Browser: bei deaktiviertem Policies-Modul werden /policies und
/policies/R08 auf /dashboard?module=disabled umgeleitet; Nav blendet den Punkt aus.
Hinweis: Das gleiche guard()-Einzeiler-Muster kann auf die Actions der übrigen
Module übertragen werden (bislang exemplarisch für Policies); die Route-Layouts
sichern bereits alle Modul-Seiten.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Delta-Update des VDA-ISA-2027-Vorlagenpakets eingepflegt:
- Aktualisiertes Seed-Paket (ersetzt bisherigen Stand): 316 Anforderungen
(122 MUSS · 132 SOLL · 43 HOCH · 19 SEHR HOCH) über 45 Controls; VA-01/VA-05
jetzt enthalten (13 Verfahren vollständig). Beschädigte RACI-Tokens (VA-05/08/09/
10/12/13) repariert. Importer: Umsetzungstext aus den .md-IMPL-Ankern extrahiert
(mapping.json führt ihn nicht mehr), neue Obligation-Typen HOCH/SEHR HOCH.
- Neue Schutzbedarf-Flags (variables.schema): FLAG_HIGH_PROTECTION,
FLAG_VERY_HIGH_PROTECTION, FLAG_ELEVATED_PROTECTION (abgeleitet). Render-Helper
applyProtection: HIGH stets an, VERY_HIGH aus Global/Override, ELEVATED = HIGH||VH
(nie manuell) — angewandt in Lese-, Bearbeiten-, Handbuch- und Coverage-Rendering.
- TISAX-Level-Schalter (AL2/AL3) zentral auf der Bibliothek (setGlobalTisaxLevel);
AL2 = MUSS/SOLL/HOCH, AL3 = zusätzlich SEHR HOCH. Override je Richtlinie im
Bearbeitungsmodus (setProtectionOverride, Feld protection_override); effektiver
Wert = Dokument-Override sonst global.
- KPIs zeigen 316 Anforderungen mit Aufschlüsselung; Coverage/Badges für HOCH/SEHR
HOCH; Control-Titel-Fallback.
Verifiziert: Import 316/45; Rendering rückstandsfrei über AL2/AL3 × Flag-Kombis;
Override R04→AL3 zeigt SEHR-HOCH-Inhalt, R02 (global AL2) nicht; global bleibt AL2.
Architektur-Hinweis: applyProtection kapselt das Level→Flags-Mapping, sodass die
globale Ebene später ohne Umbau zur TISAX-AL2/AL3-Auswahl wird (bereits so gebaut).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Referenz-/Coverage-Matrix (§9.3) wie im GEFIM-Mockup aufgebaut:
- Zwei Richtungen „nach Control" und „nach Dokument" (Umschalter) + Assessment-
Export-Button (Platzhalter).
- nach Control: Control-Nr + -Titel, je Anforderung MUSS/SOLL-Badge + Text,
Richtlinie-Link, Verfahren-Chips.
- nach Dokument: gruppiert je Richtlinie (Kopfzeile), Zeilen Control · Anforderung
· Umsetzung (Variablen aufgelöst, BL entfernt) · Verfahren.
- 44 Control-Titel aus dem Mockup übernommen (lib/control-titles.ts), numerische
Control-Sortierung.
Risiko-Bewertungsmatrix jetzt editierbar (war nur anzeigend / Edit-Popover wurde
vom overflow-Container abgeschnitten):
- Risikoklassen, Eintrittswahrscheinlichkeit UND Schadenskategorien inline
bearbeitbar (Klick auf Zeile klappt Formular auf — kein abgeschnittenes Popover).
- Neue Actions updateEwLevel/updateDamageDimension; Krypto-Register-Clipping
(overflow-x-auto) ebenfalls entfernt.
Verifiziert: beide Referenz-Richtungen gerendert; Risikoklasse-Edit end-to-end
gespeichert (persistiert).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Korrektur nach Mockup-Abgleich: Der Bearbeitungsmodus editiert NICHT den Rohtext,
sondern (wie im Mockup und Akzeptanzkriterium „im Bearbeiten nur dokumentbezogene
Variablen") die dokument-bezogenen Variablen — freie Blocktext-Änderungen sind
dem KI-Wizard vorbehalten.
- Edit-Seite neu: gerendertes Dokument links, rechts Karte „Dokument-Variablen"
(nur die im Dokument vorkommenden, inkl. BL-gebundene; zentrale Pflegestelle §8)
+ „Freigabe"-Leiste. Rohtext-Textarea entfernt.
- Freigabe-Workflow (Vier-Augen, §8): Status Entwurf → In Freigabe → Freigegeben;
submitForApproval/approvePolicy/rejectPolicy; Freigabe erfordert policy:approve
UND Freigebender ≠ Einreichender; Ablehnung mit Begründung → zurück auf Entwurf;
alles im Audit-Log. Neue Felder submitted_by/approved_by/approved_at.
- updateScopedVariables: gebündeltes Speichern der Dokument-Variablen.
Verifiziert: Editor zeigt Variablen-Karte + Freigabe-Leiste (kein Rohtext);
R08 „Erneut einreichen" → In Freigabe; Vier-Augen-Sperre greift (Anna = Autor).
Offen (nächste Ausbaustufe): echte Versionierung mit Entwurf-neben-Freigegeben +
block-/klauselgenauer Diff; KI-Wizard für Blocktext; DOCX/PDF-Export; Word-Upload.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Auf Wunsch: Dokumente öffnen nicht mehr als Popup, sondern als eigene Seite
mit Zurück-Navigation.
- Neue Routen /policies/[code] (Lesen) und /policies/[code]/edit (Bearbeiten);
Popup-Modals durch PolicyReadView/PolicyRegisterView ersetzt. Alle Deeplinks
({{LINK}}, Coverage, Bibliothek, Register-Callouts) zeigen auf /policies/CODE.
- Detailseite: „← Zurück zur Bibliothek", Titel/Status/Version, Control-Chips,
„Bearbeiten"-Button (nur Vorlagen-Dokumente, policy:write).
- Bearbeitungsmodus für Leitlinie/Richtlinien/Verfahren:
* Vorlagen-Markdown-Editor (Textarea) mit Live-Vorschau (Lesemodus),
Speichern via updatePolicyTemplate.
* Dokument-bezogene Variablen (§8 Variablen-Scoping): nur die im Dokument
vorkommenden Variablen — inkl. über BL-Referenzen gebundene — einzeln
editierbar; Änderung propagiert zentral in alle Dokumente (eine Pflegestelle).
- Register-Actions revalidieren jetzt /policies per layout (Detailseiten aktuell).
Verifiziert: R08 als Seite (kein Modal), Editor mit 23 dokument-bezogenen
Variablen; PW_MIN_LENGTH 12→14 propagiert in R08 und Handbuch; Template-Speichern
mit Redirect zur Ansicht; zurückgesetzt.
Hinweis: Der Vier-Augen-Freigabe-Workflow mit Versionierung/Diff (§8) folgt als
nächster Schritt — aktuell speichert der Editor direkt (mit Audit-Log).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Statt beim Klick auf ein Lieferanten-/IT-Service-Asset zur Lieferanten-Seite zu
wechseln, wird das Fach-Cockpit jetzt als Popup auf /assets gerendert; Schließen,
Bearbeiten, Speichern und Löschen bleiben auf der Asset-Seite.
- backHref-Prop an SupplierDetail/Edit- und ServiceDetail/Edit-Modal: alle
Schließen-/Bearbeiten-/Abbrechen-Links leiten sich davon ab (Default /suppliers)
- withQuery-Helper (lib/supplier) für korrekte ?/&-Verkettung
- updateSupplier/updateService lesen returnTo (verstecktes Feld) und leiten dorthin
zurück; deleteSupplier/deleteService bekommen returnTo-Parameter
- Kind-Actions revalidieren zusätzlich /assets, damit das Popup dort aktuell bleibt
- SUPPLIER_INCLUDE/SERVICE_INCLUDE in lib/supplier-include ausgelagert und von
beiden Seiten genutzt
- assets/page.tsx bestimmt die Popup-Art vorab (supplier/service/asset) und rendert
das passende Cockpit mit backHref="/assets"; profillose Alt-Assets bleiben Assets
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Klick auf ein SUPPLIER-Asset öffnet /suppliers?detail=, ein IT_SERVICE-Asset
/suppliers?tab=services&detail= statt der generischen Asset-Detailansicht
- Routing ist profil-abhängig: nur Assets mit SupplierProfile/ITServiceProfile
gehen ins Cockpit; profillose Alt-Assets (z. B. "Cloud-Hoster (IaaS)") bleiben
in der normalen Asset-Detailansicht (kein Null-Zugriff auf refNo)
- Direkte /assets?detail=/?edit=-Aufrufe solcher Assets werden serverseitig ins
Cockpit umgeleitet, damit auch Links aus anderen Modulen dort landen
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- ServiceDetailModal spiegelt jetzt das normale Asset-Detail: links
"■ Stammdaten" (violette Karte, CIA-Badge, Provider/Kritikalität, Notizen,
zugeordnete Prozesse), rechts "◆ Abhängigkeiten" (Verknüpfte-Assets-Tabelle
mit Typ + CIA + CiaLegend, Reverse-Liste, Link zum Abhängigkeitsgraph),
darunter das Risiken-Band — und erst darunter die Verantwortungsmatrix (RACI)
- SERVICE_INCLUDE um Typ/CIA der verknüpften Assets und Risk-Score erweitert,
RACI nach controlRef sortiert
- Schutzbedarf (C/I/A) in Lieferanten- und IT-Service-Bearbeiten-Formular:
vom gequetschten flex-Layout auf das saubere Asset-Formular-Muster umgestellt
(grid mit Einzellabels Vertraulichkeit/Integrität/Verfügbarkeit + Normal…Sehr hoch)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- IT-Services als Assets (type IT_SERVICE) mit ITServiceProfile, Provider-Verknüpfung
- Detail-Cockpit: Stammdaten, verknüpfte Assets/Prozesse, Risiken
- RACI-/Shared-Responsibility-Matrix über den ISA-Control-Katalog
(Control hinzufügen via datalist, Verantwortung per Klick durchschalten,
PROVIDER/US/SHARED, Nachweis-Referenz, Löschen)
- Lieferanten/IT-Services als Pillen-Tabs (FilterTabs) auf /suppliers
- Server-Actions services.ts (create/update/delete/addRaci/cycleRaci/deleteRaci)
mit Zod, RBAC (supplier:write) und Audit-Log
- ISA_CONTROLS-Vorschlagsliste (isa-controls.ts)
- Demo-IT-Service "Managed ERP-Hosting" mit 5 RACI-Zeilen im Seed
- de/en Übersetzungen (services, raciParty)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Mitte, erzeugte Assets rechts)
- Anzeige-Kanten rollenabhängig orientiert: primäre/erzeugte Assets
rechts vom Prozess, unterstützende Abhängigkeiten links (Pfeile
fließen sauber links→rechts, Label "erzeugt" bzw. "unterstützt")
- Analyse-Adjazenz (SPOF, kritischer Pfad, transitive Abhängigkeiten)
von der Anzeige entkoppelt und über alle Asset-Bezüge berechnet
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Referenz: docs/ISMS-Abhaengigkeitskarte-GEFIM.html
- Zentrale Theme-Definition in globals.css auf das dunkle GEFIM-Muster:
Flächen (--bg-0/1, --panel, --elevated), Text (--txt/--muted),
Marke (aufgehelltes Violett #7d6fd6), Status (--ok/warn/risk/info),
Verläufe (--grad-primary/--grad-critical), Glow-Ambiente auf dem Body,
Fokus-Ring, Punktraster-Utility
- Alle shadcn-Tokens (background/card/popover/primary/muted/border/
sidebar …) auf Dunkelwerte gemappt; neue semantische Flächen-Tokens
(panel/elevated/surface-soft/band/band-text/band-brd) ergänzt
- Hardcodierte Hex projektweit auf Tokens umgestellt: Panel-/Band-
Flächen, Status-Pillen (Alpha-Tints), Tags, Trend-/Prioritätsfarben,
Kanban, Login-Fehler, Topbar, Filter-Tabs
- GEFIM-Logo als weißes Negativ auf Dunkel (Sidebar + Login)
- Ampel-Segmentbalken/Score-Skala bleiben als semantische Statusfarben
Dark ist Default; Light-Mode später über dieselben Token-Namen möglich.
Verifiziert: Dashboard, Risiko-Detail, Asset-Bearbeiten dunkel & lesbar.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Detail-Popups einheitlich: Name/Bezeichner steht immer im Titel
(Risiko "R-001 · <Name>", Maßnahme "M-001 · <Name>", Prozess <Name>)
- Bewertungsbalken (Schutzbedarf/Schadenshöhe) + Score-Pillen als
einheitliche Ampel: 1 grün, 2 gelb, 3 orange, 4 rot; Risiko-Pillen
folgen exakt der Heatmap-Skala (medium = gelb statt blau, elevated =
orange) — Restrisiko-Pille jetzt korrekt gelb
- Risiko-Detailkarte: Farbskala von der Mitte nach oben verschoben;
alle Detail-/Bearbeiten-Popups etwas breiter (max-w-4xl)
- CiaGauge-Beschriftung vereinheitlicht: VER/INT/VFB erscheint einmal
pro Tabelle als Spaltenüberschrift (Asset-Liste + Popup-Tabellen),
keine Labels mehr pro Zeile; Standalone-Gauges in Detailkarten
behalten die Labels
Verifiziert: alle vier Ampelfarben im DOM, Restrisiko-Pille gelb,
Legende in Tabellenköpfen, Titel mit Name.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Referenz: docs/ISMS-GUI-Verbesserungen-GEFIM.html
- CiaGauge: Schutzbedarf/Schadenshöhe als 4er-Segmentbalken (Farblogik
1–4) statt Zahlen-Quadrate — einheitlich in allen Tabellen/Karten;
in Detailkarten mit VER/INT/VFB-Labels
- SegmentedRating: 1–4 anklickbare, farbige Stufen-Buttons (Client-
Komponente mit Hidden-Input + HTML-form-Association) für Asset-
Schutzbedarf und BIA-Schadenshöhe statt Dropdowns
- Prozess-Bearbeiten aufgeräumt: Sprungnavigation (Grunddaten/Assets/
BIA), genau EIN Speichern-Button (Stammdaten + BIA in einer Action
saveProcessAll, Felder per form-Attribut verbunden), Löschen ins
⋯-Überlaufmenü verschoben; Asset-Zuordnung als entfernbare Chips mit
Segmentbalken
Verifiziert: kombiniertes Speichern (Name + BIA-Schadenshöhe in einem
Vorgang, Kritikalität neu berechnet), SegmentedRating-Wert korrekt
übernommen, ⋯-Menü mit Löschen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Maßnahmen-Bereich unterhalb der Stammdaten über die komplette Breite
(Tabelle mit ID, Titel, editierbarer Minderung je Dimension)
- Zwei Aktionen als aufklappbare Buttons: "Maßnahme hinzufügen"
(bestehende auswählen) und "Neue Maßnahme erstellen" (legt an und
verknüpft direkt mit dem Risiko, Rest-Risiko wird neu berechnet)
- Risiko-Detail: Brutto→Rest als zwei farbig abgesetzte Karten (rot/
orange) mit Pfeil, großer Score-Zahl und Level-Chip; darunter
Farbskala (grün→rot) mit Markern für Brutto und Rest (Referenz:
docs/ISMS-GUI-Verbesserungen-GEFIM.html)
Verifiziert: neue Maßnahme -0,75 → Rest 1,75 × 4 = 7; Skala/Karten
korrekt gerendert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Risikoanalyse:
- Risiko direkt aus dem Asset-Popup erstellbar ("+ Risiko erstellen"
→ Anlege-Popup mit vorverknüpftem Asset)
- Brutto-/Rest-Risiko detailliert: Eintrittswahrscheinlichkeit und
Schaden als beschriftete Werte (X × Y = Score-Pille)
- Rest-Risiko wird NICHT mehr manuell erfasst, sondern automatisch aus
den verknüpften Maßnahmen berechnet (Minderung je Dimension, Summe,
Untergrenze 1; src/server/risk-calc.ts); Neuberechnung bei jeder
Änderung an Bewertung oder Maßnahmen-Verknüpfungen
- Risikoregister unterhalb der Heatmap in voller Breite
Maßnahmen-Modul (SPEC §4.4):
- Measure/RiskMeasure-Schema mit RLS, laufende Nummer (M-001),
Status/Priorität/Owner/Fälligkeit
- Kanban-Board mit Drag-and-Drop (dnd-kit): Karten zwischen Offen /
In Umsetzung / Erledigt verschieben aktualisiert den Status per
Server-Action inkl. Audit-Log; überfällige Karten rot markiert
- Maßnahmen-Popups (Detail read-only / Bearbeiten / Anlegen) nach
App-Muster; Detail zeigt verknüpfte Risiken mit Minderung
- Im Risiko-Bearbeiten: bestehende Maßnahme verknüpfen ODER neue
Maßnahme direkt anlegen & verknüpfen (jeweils mit Minderung
Wahrscheinlichkeit/Schaden); "Notwendige Maßnahmen" im Risiko-Detail
jetzt echt
- Seed: 4 Beispiel-Maßnahmen, Rest-Risiken daraus berechnet
Verifiziert im Browser: DnD-Statuswechsel (beide Richtungen, Audit-
Einträge), Rest-Risiko-Berechnung (R-001: 4×5=20 → 2×4=8), Risiko-
Anlage aus dem Asset inkl. automatischer Verknüpfung.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Wiederverwendbares, serverseitig gerendertes Modal (searchParams-
gesteuert: ?detail= / ?edit= / ?new=1) — Browser-Zurück schließt,
kein Client-State nötig
- Assets: Read-only-Detail-Popup (Stammdaten, C/I/A, Abhängigkeiten,
Prozesse, Risiken-Platzhalter), Bearbeiten-Popup (Formular +
Abhängigkeiten verwalten + Löschen), Anlegen-Popup
- Prozesse: "Bearbeiten" wechselt jetzt innerhalb des Popups in den
Editiermodus (Stammdaten, Asset-Zuordnung, BIA, Löschen) statt auf
die alte Detailseite zu springen; Anlegen ebenfalls als Popup
- Server-Actions leiten auf die Popup-URLs zurück (Speichern im
Bearbeiten-Popup → Detail-Popup; BIA-/Zuordnungs-Änderungen lassen
das Popup offen); BIA-Formular remountet nach dem Speichern (key)
- Alte Routen (/assets/[id], /assets/new, /processes/[id], …) leiten
auf die Popup-URLs um
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Neue Mockup-Bausteine (mockup-ui.tsx): PageHead mit Crumb/Untertitel,
KPI-Kapseln, C/I/A-Quadrate in Mockup-Farben, Tag-Chips, Owner-Chips
mit Mini-Avatar ("kein Owner" als rote Pille), Status-/Kritikalitäts-
Pillen, Pillen-Filter-Tabs
- Asset-Inventar wie im Mockup: Seitenkopf mit Zähler-Untertitel und
Ghost-Buttons (Excel-Import/Export, deaktiviert bis zur Funktion),
4 KPI-Kapseln (gesamt, hoher Schutzbedarf, ohne Owner, Lieferanten),
Typ-Filter als Pillen-Tabs + Filtersuche in der Tabellenkarte,
Abhängigkeiten-Spalte
- BIA-Seite wie im Mockup: "Kritikalität der Prozesse" mit RTO/RPO/MTD
und Kritikalitäts-Pillen; Prozess-Detail als schließbares, schreib-
geschütztes Popup (?detail=id, serverseitig gerendert): primäres Asset
mit violettem Kartenrand, Sekundär-Tabelle, BIA-Kennzahlen-Band,
Bearbeiten-Button führt zur Editier-Seite
- Tabellenköpfe uppercase/muted, Zeilen-Hover wie im Mockup; Asset-
Detail und Prozess-Editier-Seite auf die neuen Bausteine umgestellt
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- GEFIM-Farbwelt aus dem Mockup als shadcn-Theme: Violett #5d52a3 als
Primärfarbe, Magenta/Hellblau-Akzente, Ink-Text, #f5f6fa-Hintergrund,
Verlaufs-Utilities (bg-grad, bg-grad-soft), Karten-Schatten
- Fonts Poppins (Überschriften/Buttons) + Open Sans (Text), self-hosted
über next/font — kein Google-CDN-Aufruf zur Laufzeit (DSGVO)
- Sidebar mit extrahiertem GEFIM-Logo (public/gefim-logo.png), aktive
Navigation in Violett wie im Prototyp
- Sticky Topbar mit globaler Suche (leitet vorerst auf die Asset-Suche),
Nutzer-Info und Verlaufs-Avatar mit Initialen; Logout in die Topbar
- Primär-Buttons mit Verlaufshintergrund, Level-Badges als Pillen in
Mockup-Farben, Login-Seite im GEFIM-Look
- Dashboard im Mockup-Stil: KPI-Karten (Assets, Prozesse, kritische
Prozesse, Risiken-Platzhalter) und Letzte-Aktivitäten-Feed aus dem
echten Audit-Log
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- App-Shell mit Seitennavigation (alle 12 Module, kommende ausgegraut),
shadcn/ui-Setup (Base-UI-Variante) mit hellem Theme
- Asset-Inventar: filterbare Liste (Suche/Typ/Status), Anlegen/Bearbeiten/
Löschen, Detailansicht mit Schutzbedarf (C/I/A 1–4), Abhängigkeiten
(beide Richtungen, hinzufügen/entfernen), zugeordneten Prozessen mit
Primär-/Sekundär-Rolle und Platzhalter für zugeordnete Risiken
- Prozesse & BIA: Liste mit Kritikalität/RTO/MTD, Prozess-Detail mit
Asset-Zuordnung nach Rolle (primär/sekundär), BIA-Formular
(RTO/RPO/MTD, Schadenshöhe je Schutzziel, Kritikalität nach Max-Prinzip)
- Server-Actions mit Zod-Validierung, requirePermission und Audit-Log
für jede schreibende Aktion; Tenant-Guard um upsert-Injektion erweitert
- Prisma: Asset, AssetRelation, Process, ProcessAsset, BiaEntry
inkl. RLS-Policies; Seed mit Beispiel-Assets, Prozessen und BIA
- Im Browser verifiziert: CRUD, Relationen, BIA-Speichern, Audit-Einträge
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
