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>
