Commit Graph
24 Commits
Author SHA1 Message Date
msolarczekandClaude Opus 4.8 c963ffadea Fix: AUTH_TRUST_HOST an app-Container durchreichen (Default true)
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>
2026-07-20 14:26:39 +02:00
msolarczekandClaude Opus 4.8 52e30010f1 Feat: optionaler Demo-Seed im migrate-Job via RUN_DEMO_SEED (Testserver)
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>
2026-07-20 14:22:43 +02:00
msolarczekandClaude Opus 4.8 79c79fdde7 Docs: AUTH_TRUST_HOST=true in Coolify-Env-Referenz (Auth.js v5 hinter Proxy)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-20 14:02:37 +02:00
msolarczekandClaude Opus 4.8 34dd0cd457 Fix: HOSTNAME=0.0.0.0 für Next-Standalone-Server (Erreichbarkeit/Healthcheck)
Next.js standalone server.js bindet sonst an den von Docker gesetzten HOSTNAME
(Container-ID) statt 0.0.0.0 -> Healthcheck (127.0.0.1:3000) schlägt fehl, Container
wird unhealthy, Traefik/Coolify-Proxy routet nicht -> 404. ENV HOSTNAME=0.0.0.0 (+PORT=3000)
behebt beides. Entspricht dem offiziellen Next-Standalone-Dockerfile.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-20 13:57:08 +02:00
msolarczekandClaude Opus 4.8 8e69935cf4 Fix: DATABASE_URL-Platzhalter für Build-Zeit + .dockerignore
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>
2026-07-20 13:06:56 +02:00
msolarczekandClaude Opus 4.8 27cbb286d0 Fix: Docker-Build nutzt npm install statt npm ci (lightningcss musl-Binary)
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>
2026-07-20 12:39:55 +02:00
msolarczekandClaude Opus 4.8 e3ea5828fe Fix: package-lock.json mit npm 10 synchronisieren (Docker-Build)
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>
2026-07-20 12:24:40 +02:00
msolarczekandClaude Opus 4.8 81722f0cb4 DevOps: Coolify-Testserver-Deployment (Compose, Migrations-Job, Runbook)
- docker-compose.coolify.yml: Coolify-taugliche Variante (kein host-port,
  Env via Coolify-Variablen, migrate-Init-Job vor app, app-Healthcheck)
- .env.coolify.example: Referenz der Coolify-Env-Variablen (nur Platzhalter)
- docs/DEPLOY-COOLIFY.md: Runbook (Gitea-Deploy-Key, Ressource, Env, Domain, Seed)
- .gitignore: .env.coolify.example whitelisten

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-20 11:41:24 +02:00
msolarczekandClaude Opus 4.8 71361df588 Übergabe-Dokument: DevOps (Deployment Test → Produktiv)
docs/HANDOVER-DEVOPS.md: Runtime-Architektur (Next standalone + Postgres/pgvector/
Redis/MinIO/Mailhog), Umgebungsvariablen, Build/Start, kritische Migrations-/
Bootstrap-Strategie (Migrationen laufen nicht beim Container-Start; erster
Superadmin fehlt), Persistenz/Backup, bekannte Lücken (worker-Script fehlt, MinIO-
Env, Reverse-Proxy/TLS, Healthcheck), Test-vs-Prod-Unterschiede, Deploy-Checkliste.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-20 10:58:46 +02:00
msolarczekandClaude Opus 4.8 081c00043a Übergabe-Dokumente: PM-Statusbericht + Entwickler-Onboarding
- docs/HANDOVER-PM.md: umgesetzte Module + offene Themen nach Priorität (Hoch/
  Mittel/Niedrig) mit grobem Aufwand (S/M/L) für die Weiterplanung.
- docs/HANDOVER-DEV.md: Repo/Zugriff (Gitea HTTP, Token im Schlüsselbund),
  Tech-Stack + Versionen, vollständige Setup-Anleitung (Compose/Prisma/Seed/Dev),
  Architektur & Konventionen (Tenant-Guard, RLS, RBAC, Modul-Gating, Prisma-7-
  Migrationsflow), Verzeichnisstruktur, Fallstricke, Einstiegspunkte.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-20 10:46:24 +02:00
msolarczekandClaude Opus 4.8 6ddeedf0b6 Serverseitige Modul-Durchsetzung (§3.4)
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>
2026-07-19 20:46:14 +02:00
msolarczekandClaude Opus 4.8 0e3ed82b21 Admin-Konsole & Mandantenverwaltung (Phase 1)
Plattform-Admin-Konsole (Superadmin) + Kunden-Einstellungsbereich:

- Datenmodell: TenantSettings (Quelle der ISMS-Template-Variablen), TenantModule
  (Feature-Toggles je Mandant), Tenant += short/sector, TenantStatus += ARCHIVED,
  AuditLog += scope (tenant|platform); RLS für die neuen Tenant-Tabellen.
- Wiederverwendbare Provisionierung (server/provision.ts): Rollen+Permissions,
  erster Admin-User, Einstellungen, alle Module, optional Richtlinienpaket-Seed +
  TISAX-Default; idempotent + Audit (§3.7). syncPolicyVariablesFromSettings mappt
  Stammdaten → ISMS-Variablen (ORG_NAME, ISMS_SCOPE, ROLE_* …).
- Admin-Konsole /admin (Guard isPlatformAdmin): Mandantenliste, „Neuer Kunde"
  (anlegen + provisionieren), Detailseite mit Modul-Toggles, Lebenszyklus
  (aktiv/gesperrt/archiviert), Nutzerliste. Aktionen im Plattform-Audit-Log.
- Kunden-Einstellungen /settings (Guard tenant:manage): Unternehmensdaten,
  verantwortliche Rollen, Branding/Regionales, TISAX-Level — Stammdaten speisen
  die ISMS-Variablen (eine Pflegestelle). Modul-Übersicht.
- Modul-Gating der Navigation (deaktivierte Module ausgeblendet); Login bereits
  für gesperrte/archivierte Mandanten blockiert (auth.authorize).
- Seed: Demo-Mandant mit Einstellungen, 12 aktiven Modulen; admin@demo.example
  = Superadmin.

Verifiziert: tsc/lint/build grün; Seed rollt Einstellungen/Module/Superadmin aus.
(Browser-Verifikation diese Sitzung nicht möglich — Preview-Tools getrennt.)

Offen (Phase 2): separater Superadmin-Store + eigener Login + MFA-Pflicht;
Impersonation (zeitlich begrenzt, protokolliert); Plan/Limits; Logo-Upload/
Objektspeicher; SMTP/Benachrichtigungen; per-Route-Modul-Enforcement (serverseitig);
Datenexport/Löschung/Retention (DSGVO); SSO.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-19 20:38:10 +02:00
msolarczekandClaude Opus 4.8 eab16c861d Richtlinien-Update: 316 Anforderungen/45 Controls + Schutzbedarf-/TISAX-Schalter
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>
2026-07-08 11:23:07 +02:00
msolarczekandClaude Opus 4.8 222046a362 Referenzmatrix nach Mockup + Risiko-Bewertungsmatrix editierbar
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>
2026-07-08 07:20:12 +02:00
msolarczekandClaude Opus 4.8 92c184dfc6 Richtlinien-Editor: Experten-Modus (Rohtext) mit Einfüge-Hilfen & Auto-Variablen
Ergänzung zum variablenbasierten Standard-Bearbeitungsmodus:

- Modus-Umschalter „Standard (Variablen) ↔ Experten-Modus" auf /policies/[code]/edit.
- Experten-Modus (Client-Editor policy-expert-editor.tsx): voller Vorlagen-/Markdown-
  Editor mit Formatierungsleiste (fett/kursiv/Überschrift/Liste/Tabelle),
  Einfüge-Dropdowns für Variablen und Dokument-/Register-Verweise ({{LINK:CODE}},
  Deep-Links {{LINK:R08#4.1.2}}), „Neue Variable"-Feld; Live-Vorschau (bei Speichern).
- Beim Speichern werden neue {{VARIABLEN}} automatisch als PolicyVariable angelegt
  (danach im Standard-Modus pflegbar).

Verifiziert: Umschalter, Editor + Toolbar, „Neue Variable" fügt {{STANDORT_WERK}}
ein, Speichern legt die Variable automatisch an; Vorschau rendert.

Zu Bildern/KI-Formulierungshilfe: siehe Antwort — Bilder brauchen Storage/Upload,
KI-Hilfe braucht Anthropic-API-Anbindung (beides als eigener Schritt sinnvoll).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 16:56:16 +02:00
msolarczekandClaude Opus 4.8 3cffd3f32e Richtlinien-Bearbeitungsmodus am Mockup ausgerichtet: Variablen + Vier-Augen-Freigabe
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>
2026-07-07 16:45:58 +02:00
msolarczekandClaude Opus 4.8 094229011d Richtlinien: Lesemodus als eigene Seite + Bearbeitungsmodus (§8)
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>
2026-07-07 16:29:18 +02:00
msolarczekandClaude Opus 4.8 e2b6dee788 Richtlinien Phase 2a: verwaltete Register-Tabellen + Anwender-Handbuch (§7b, §9.7)
Vier neue, in die Bibliothek integrierte Dokumente (öffnen als interaktive Popups):

- Krypto-Register (VA-07): editierbare Tabelle der eingesetzten Verschlüsselung
  mit Ablaufüberwachung (läuft-ab/abgelaufen-Markierung), Baseline-Bezug
  (BL-CRY-…), voller CRUD (add/edit/delete).
- Risiko-Bewertungsmatrix (R03/VA-09): zentrale Pflegestelle mit FB-80-04-Defaults
  — 4×4-Heatmap (Schadensausmaß × EW), Risikoklassen + Akzeptanzinstanz
  (Niedrig≤3 / Mittel≤6 / Hoch≤9 / Kritisch≥12, editierbar), EW-Skala,
  7 Schadenskategorien. (Rückkopplung in die 5×5-Heatmap der Risikoanalyse folgt.)
- Klassifizierungs-Handhabungsmatrix (R02/VA-08): AA-80-20-Defaults, 4 Schutzklassen
  × 14 Aspekte mit eskalierenden Regeln; Zellen inline editierbar, Aspekt/Klasse
  hinzufügbar.
- Anwender-Handbuch (§9.7): kuratierte Themen (Passwörter/MFA, Zugriffsrechte,
  Klassifizierung, mobiles Arbeiten, E-Mail, Vorfälle) in verständlicher Sprache;
  Werte via {{VARIABLE}}-Templating → automatisch synchron zur Baseline; Deep-Links
  in die Quellabschnitte (z. B. R08 §4.1.2).

Zusätzlich: Richtlinien/Verfahren, die eine verwaltete Tabelle einbetten
(R09/VA-07, R03/VA-09, R02/VA-08), zeigen im Lesemodus einen „Vollständige Tabelle
öffnen"-Callout auf das jeweilige Register (§7b).

Datenmodell: CryptoEntry, ClassificationClass/HandlingAspect/HandlingRule,
RiskMatrixClass/RiskEwLevel/RiskDamageDimension, HandbookTopic (+ RLS).
Server-Actions mit RBAC (policy:write) + Audit-Log. Seed aus FB-80-04/AA-80-20.

Verifiziert im Browser: alle vier Register gerendert, Ablauf-/Farb-/Deep-Link-Logik,
Krypto-CRUD (add + delete) end-to-end.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 15:55:46 +02:00
msolarczekandClaude Opus 4.8 89b0e3a5a5 Richtlinien & Verfahren (Phase 1): Import, Rendering-Engine, Bibliothek, Coverage
Fundament des VDA-ISA-2027-Richtlinienmoduls (Spec §1–9):

- Datenmodell: PolicyDocument, PolicyRequirement, PolicyVariable (Variablen +
  Feature-Flags), PolicyBaselineParam, PolicyEvidence — inkl. RLS + Tenant-Guard
- Seed-Importer (import-policies.ts): liest die echten .md-Dateien (15 Richtlinien
  L00/R01–R14 + 11 Verfahren), mapping.json (120 Anforderungen/46 Controls),
  variables.schema.json (53 Variablen/Flags), Technische-Sicherheits-Baseline
  (31 BL-Parameter) und Nachweisregister; idempotent pro Mandant
- 6 im Vorlagenpaket beschädigte Variablen-Tokens (VA-08/09/10/12/13) repariert
  (dokumentiert im README des Übergabepakets)
- Rendering-Engine (policy-render.ts, Handlebars + marked): verschachtelte
  {{#if FLAG}}, {{VARIABLE}}, {{LINK:…}}-Deeplinks, Hidden-Anker + BL-Referenzen
  im Lesemodus entfernt (Wert bleibt), zentral verwaltete Abschnitte unterdrückt,
  wiederholtes „Umsetzung bei <Org>" reduziert (§7a); lenienter Fallback +
  Residue-Check über alle Flag-Kombinationen (analog _verify.py)
- UI: Bibliothek mit Typ-Chips/KPIs, Lesemodus-Popup (einklappbare Info-Tabelle,
  Control-Chips, Richtlinie↔Verfahren-Verlinkung), Coverage-Matrix
  (Control → Richtlinie → MUSS/SOLL → Verfahren → Anforderungs-IDs)
- Nav-Punkt „Richtlinien" aktiviert; de/en-Übersetzungen

Verifiziert: Import 28 Dokumente/120 Anforderungen; Rendering rückstandsfrei
über alle Flag-Kombinationen; Bibliothek, Lesemodus (R08 nested flags), Coverage
im Browser.

Später (Phase 2+): Bearbeiten/Freigabe-Workflow mit Versionierung, verwaltete
Tabellen (Krypto-/Risiko-/Klassifizierungsregister), Anwender-Handbuch,
DOCX/PDF-Export, Word-Upload, KI-Wizard, zentrale Baseline-/Variablen-Einstellseite.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 13:35:59 +02:00
msolarczekandClaude Opus 4.8 2706424c08 Lieferanten-/IT-Service-Cockpit direkt auf der Asset-Seite öffnen
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>
2026-07-06 13:55:46 +02:00
msolarczekandClaude Opus 4.8 db710c43cf Asset-Inventar verlinkt Lieferanten/IT-Services ins Fach-Cockpit
- 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>
2026-07-06 13:27:23 +02:00
msolarczekandClaude Opus 4.8 ee4e554554 IT-Service-Detail auf Asset-Grundgerüst + Schutzbedarf-Layout gefixt
- 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>
2026-07-03 16:31:58 +02:00
msolarczekandClaude Opus 4.8 d994c94ebb IT-Service-Detail mit RACI-Matrix (VDA-ISA 6.1.3)
- 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>
2026-07-03 14:06:04 +02:00
msolarczek 394c05aa08 Initial commit from Create Next App 2026-07-02 11:26:45 +02:00