Neue AssetType-Werte SOFTWARE und PROJECT plus 1:1-Profile:
- SoftwareProfile (Anbieter-Verknüpfung, Version/Patch-Stand, Freigabestatus
BEANTRAGT/FREIGEGEBEN/GESPERRT, Freigeber, Kritikalität, Review)
- ProjectProfile (IS-Klassifizierung, ISB-Einbindung, Projektstatus)
Migration inkl. RLS-Policies; TENANT_MODELS und Dependency-Graph (Node-Typ +
Icons Package/FolderKanban) um beide Typen erweitert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Fachliche Klärung (ISB): ISA 3.1.2 ist in VDA-ISA 2027 deprecated, ISA 3.1.3
existiert nicht. Der bisherige R07 §3.2 „(ISA 3.1.3)" war ein IMPL-Stub ohne
Anforderung/mapping-Eintrag (Waise) — der im GAP-Report vorgeschlagene 3.1.3-Text
(A-G-B2a) war eine Erfindung, nicht Teil des Standards, und wird daher NICHT
eingefügt.
- R07: Abschnitt „(ISA 3.1.3)" inkl. IMPL-3.1.3-Stub entfernt; stattdessen ein
Scope-Hinweis (3.1.2 deprecated, 3.1.3 nicht existent).
- Kein REQ/IMPL/mapping-Eintrag für 3.1.2/3.1.3.
Verifiziert: _verify.py meldet jetzt **OK** (Render 0, Mapping beidseitig sauber,
keine Waisen mehr). Re-Import in Demo: R07 ohne IMPL 3.1.3.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
WP2.2 — Rendering-Doppelartikel (Variante B, Report §6):
- Variablen-Defaults ohne führenden Artikel: TOOL_TICKET „Ticketsystem",
TOOL_NAME „ISMS-Tool", TOOL_IAM „Entra ID / Active Directory".
- Fließtext angepasst: „im/in {{VAR}}" rendert nun korrekt („im Ticketsystem");
„über {{TOOL_TICKET}}" → „über das {{TOOL_TICKET}}"; TOOL_IAM (Adjektiv) mit
korrekter Deklination ausgeschrieben („über das zentrale Verzeichnis (…)",
„im zentralen Verzeichnis (…)"). Doppeldeutige Orte „bzw. ISMS-Tool" bereits in WP1 aufgelöst.
- Wert-Migration (Prisma-Migration, idempotent): strippt den führenden Artikel aus
bestehenden, nicht angepassten Variablenwerten — auch für Bestandsmandanten/Deploy.
WP4 — Feinschliff:
- F16 (R06 2.1.4): „mobiles Arbeiten" konkret verortet (Regelung, hinterlegt im ISMS-Tool).
- F21 (VA-10): abgeschnittene RACI-Spaltentexte vervollständigt.
- F18: 13 SEHR-HOCH-Sätze in den -elev-Blöcken in {{#if FLAG_VERY_HIGH_PROTECTION}}
ausgelagert → bei AL2 kein „Bei sehr hohem Schutzbedarf …" mehr.
Verifiziert: _verify.py Render 0 / Mapping sauber; Render-Gegenprobe mit echten
Defaults ohne „im das …"; AL2/AL3-Flag-Gegenprobe rückstandsfrei (SEHR-HOCH nur bei AL3);
Browser: R08 rendert „im Ticketsystem" und „über das zentrale Verzeichnis (Entra ID / Active Directory)".
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Konzept (abgestimmt): Beim Einreichen wählt der Einreicher einen konkreten
Freigeber; die Freigabe/Ablehnung erfolgt im neuen Aufgaben-Modul (Vier-Augen).
- Modell: generisches Task + TaskComment (Migration inkl. RLS; Task/TaskComment
in TENANT_MODELS). Erster Typ policy_approval. Neues Modul „tasks" (lib/modules,
Nav, i18n) — für Bestands-Tenants per Default aktiv.
- policies.ts: submitForApproval(code, formData) verlangt einen Freigeber (aktiver
Nutzer mit policy:approve, ≠ Einreicher), setzt IN_FREIGABE und erzeugt eine
Aufgabe; Resubmit schließt alte offene Aufgaben. Alte approvePolicy/rejectPolicy
entfernt (wandern ins Aufgaben-Modul).
- actions/tasks.ts: approveTask/rejectTask (nur zugewiesener Freigeber, ≠ Einreicher;
Richtlinie → FREIGEGEBEN bzw. zurück auf ENTWURF) und commentTask (nur Beteiligte);
Kommentare/Statuswechsel historisiert, Audit.
- /tasks: Aufgaben des Nutzers (offen/erledigt) mit Freigeben/Ablehnen (Grund
erforderlich)/Kommentieren + Verlauf. Richtlinien-Editor: Freigeber-Dropdown beim
Einreichen, „Zur Freigabe bei …" + Link zur Aufgabe (keine Inline-Freigabe mehr).
- Dashboard: Kachel „N offene Aufgabe(n)" verlinkt auf /tasks.
- Seed: zweiter ISB „Bea Approver" als Freigeber (ermöglicht den Vier-Augen-Flow).
Browser-verifiziert: R08 eingereicht (Freigeber Bea) → Aufgabe; Dashboard-Kachel
bei Bea; Freigeben in /tasks → R08 FREIGEGEBEN, Task DONE, Kommentar-Historie
(submit+approve). tsc + lint + build + Guard-Check grün.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
