# Content-Inventar & Mapping — Redesign-Guardrail (IACE + CRA + Gap)

> **Zweck:** Sicherstellen, dass das Frontend-Redesign **keine Inhalte verliert.**
> Jeder bestehende Screen/Tab ist hier mit seinen Inhalten erfasst und einem
> neuen Zuhause zugeordnet. Was kein klares Zuhause hat, steht unter
> **„Waisen / Aktiv entscheiden"** — nichts wird stillschweigend entfernt.
> Stand 2026-06-18. Quellen: `ux-screenshots/` + Code (`admin-compliance/app/sdk/…`).

## Redesign-Modell (so verlieren wir nichts)
1. **Design-Sprache (Tokens) auf ALLE Screens** anwenden — reines Re-Skin, kein Inhaltsverlust.
2. **Projekt-Dashboard → „Arbeitsbereich"** mit 3 Ebenen (Überblick → Cyber×Safety → Technik, eingeklappt). Konsolidiert die *Übersicht*, **verlinkt** in die Detail-Tabs.
3. **Detail-Tabs bleiben** als (re-skinned) Deep-Dive-Seiten, erreichbar aus dem Arbeitsbereich. **Keine Tab-Löschung** ohne explizite Freigabe.
4. **Additiv bauen:** alte Routen bleiben, bis der neue View nachweislich 100 % abdeckt.

Neue Heimat-Codes: **E1** = Ebene 1 Überblick · **E2** = Ebene 2 Cyber×Safety · **E3** = Ebene 3 Technik · **D** = bleibt Detail-/Deep-Dive-Seite (re-skinned) · **?** = Entscheidung nötig.

---

## IACE — Maschinensicherheit (CE)

| Screen / Tab | Wesentliche Inhalte (dürfen nicht verloren gehen) | Neue Heimat |
|---|---|---|
| `/iace` (Liste) | Projektkarten (Maschinenname/-typ/Hersteller, Status, Vollständigkeit %, Risiko-Summary), Schnellzugriff Linien+Bibliothek, Prozess-Flow, Neu-Projekt-Form, Init aus Firmenprofil | **D** (Projektliste, re-skinned) |
| `/iace/library` | Tabs Normen / Patterns / Maßnahmen / Dokumente (Counts) | **D** (intern/Referenz) |
| `/iace/lines` + `/lines/[lineId]` | Produktionslinien: Stationen, Aggregat-Panel, Stationsfluss/Transfer | **D** |
| `/iace/[projectId]` (Dashboard) | Statusworkflow, Maschineninfos, Risikozusammenfassung, 6-Schritt-Fortschritt, Compliance-Alerts, Varianten-Panel, Suggested-Norms, 8 Quick-Actions | **→ Arbeitsbereich E1** (Überblick) + Nav |
| `…/order` | Auftraggeber/Auftrag/Angebot/Notizen | **D** |
| `…/interview` (Grenzen) | ISO-12100-Grenzenformular (Bezeichnung, Zweck, Betriebsarten, Fehlanwendungen, räuml./zeitl. Grenzen, Personengruppen…), Init/Reinit | **D** (E1 verlinkt „Grenzen") |
| `…/clarifications` | Klärungen mit Anlagenbauer (Frage, Quelle, Status, Antwort, Begründung, Kommentare, Historie), CSV/PDF-Export, CRA-Banner | **D** |
| `…/classification` | Reg-Klassifikation (AI-Act/MaschVO/CRA/NIS2): Ergebnis, Risiko-Level, Konfidenz, Begründung | **E1** (Geltung) + **D** Detail |
| `…/components` | Komponentenbaum (SW/FW/AI/HMI/HW), present/nicht_vorhanden/gelöscht, CE-Marked, Bibliothek-Import | **D** |
| `…/hazards` | Hazard-Log, 4-Faktor-Risiko (S×F×P×A), Pattern-Match, Bibliothek, KI-Gap-Review, 3 Views (Liste/Risiko/Blöcke), Restrisiko-Filter | **D** (Kern-Detail) |
| `…/mitigations` | Maßnahmen (Design→Schutz→Information), Status, Relevanz, Norm-Refs, OSHA-Abstände, Vorschläge | **D** |
| `…/risikobewertung` | EN-62061 + Fine-Kinney-Modelle, Risiko-Matrix, ESAW/NIOSH/OSHA-Vorschläge, Live-Formeln | **E3** (Risiko-Modelle) + **D** |
| `…/fmea` | FMEA-Worksheet (S×O×D=RPZ), KI-Vorschlag je Komponente, Quelldokumente/Provenienz, Export | **D** |
| `…/operational-states` | 9 ISO-Betriebszustände, Übergänge, Delta-Analyse, Init | **D** |
| `…/verification` | Verifikation (Kundenstandard / Nachweis-Referenz), Stats, Verify-Modal | **D** |
| `…/norms` | Normenrecherche A/B/C, Suggested-Norms, Dokument-Upload | **E3** (Norm-Bezug) + **D** |
| `…/evidence` | Nachweise (Upload, Verknüpfung zu Maßnahmen/Verifikation) | **D** |
| `…/customer-standards` | Maßnahmen aus früheren Kundenprojekten übernehmen (Bulk) | **D** |
| `…/tech-file` | CE-Akte: Sektionen, Generierung, Approval, CID, Export (PDF/Word/HTML) | **D** |
| `…/knowledge-graph` | Komponenten→Gefährdung→Maßnahme als Graph | **E3** / **?** (Auditor-Tool) |
| `…/architektur` | Engine-Architektur, Pipeline-Stufen, Wissensbasen, Datenquellen/Lizenzen | **E3** / **?** (Auditor/intern) |
| `…/benchmark` | Ground-Truth-Vergleich (Coverage %, Korrelation, Abstände) | **?** (Dev/QA — intern gaten?) |
| `…/monitoring` | Post-Market: Ereignisse (Incident/Update/Reg-Change/Feedback), Stats, Resolve | **D** |
| `…/cra` (CE×Cyber) | **Bridge:** CE-Gefährdung durch Cyber wieder geöffnet; ScannerRepoPicker, Weights, CRACyberView, Snapshots | **→ Arbeitsbereich E2 (HERO)** + **D** |

---

## CRA — Cyber Resilience + Gap + Meldewesen

| Screen / Tab | Wesentliche Inhalte | Neue Heimat |
|---|---|---|
| `/gap-analysis` | Standortbestimmung: ProductWizard, GapDashboard (anwendbare Vorschriften, Lücken, Compliance %, Aufwand), Filter, DSMS-Archiv-CID | **E1**-Einstieg / **D** · **?** Überschneidung mit Intake/Scope |
| `/cra` (Liste) | ReadinessCheck (Producer-Type, Fragen, Verdict, Evidence → Klassifikation), DatasheetExtract, Projektkarten (Klassifikation, Konformitätspfad, Status), Neu-Modal | **D** (Liste + Eingangstür) |
| `/cra/[projectId]` (Dashboard) | Status-Stepper, KPIs (Annex-I-Count, Critical, Tage bis CE-Pflicht, Compliance %), Top-10-Backlog, Info-Karten (Intake/Klassifikation/Pfad/Status), Next-Step | **→ Arbeitsbereich E1** + Nav |
| `…/intake` | Software-Profil (Name, Zweck, Repo, Sprache, Flags: Firmware/Internet/Updates/PII/KRITIS) | **D** |
| `…/scope` | Annex-III/IV-Klassifikation, Begründung | **E1** (Geltung) + **D** |
| `…/path` | Konformitätspfad (Modul A / Harm. Norm / EUCC / Modul B+C), Details, Auswahl | **D** |
| `…/requirements` | 59 Annex-I-Anforderungen, Filter, ISO-27001-Mapping, Maßnahmen, Aufwand | **E3** + **D** |
| `…/backlog` | Priorisierung (Severity×Frist×Aufwand), Score, Maßnahmen, Jira-Export | **E2** (Maßnahmen-Backlog) + **D** |
| `…/checks` | Automatisierte Checks (security.txt/TLS/Update-Policy/CVD), Status, Run | **D** |
| `…/sbom` | SBOM-Upload (CycloneDX/SPDX), Versionen, Scan-Status | **D** |
| `…/vuln` | Schwachstellen + CRA-Meldefristen (24h/72h), CVSS, Reporter, Status | **D** (+ E2-Hinweis) |
| `…/documents` | CRA-Dok-Generierung (DoC, TechDoc, CVD-Policy, Update-Policy, SBOM-Report), Approval, Download | **D** |
| `…/monitoring` | CRA-Stichtage, Reporting-Verstöße, KPIs, Post-Market-Checkliste | **D** |
| `/cra-meldewesen` | Art.-14-Kaskade 24h/72h/14d, Vorfall-Form, Fristen-Countdown, ENISA-Export | **D** (eigener Workflow) |

---

## ⚠️ Waisen / Aktiv entscheiden (vor dem Bau)

1. **20-Tab-Konsolidierung (IACE):** Der „Arbeitsbereich" ist EIN Screen mit 3 Ebenen — IACE hat 20 Tabs. **Vorschlag:** Tabs bleiben als Detail-Seiten, im Arbeitsbereich nach den bestehenden Flow-Paketen gruppiert (Vorbereitung / Analyse / Doku / Betrieb) statt 20 gleichwertige Tabs. → **Bestätigen.**
2. **Auditor/Dev-Tabs `architektur`, `benchmark`, `knowledge-graph`:** kundenseitig sichtbar lassen oder intern gaten (wie Screening, per `visibleWhen`)? → **Entscheidung.**
3. **Ebene 2 im STANDALONE-CRA-Projekt:** Der echte CE×Cyber-Bridge braucht eine IACE-Maschine (Gefährdungen). Ein reines CRA-Projekt (nur Software) hat keine CE-Gefährdungen. **Was zeigt Ebene 2 dort?** (z. B. „nur Cyber-Risiken" + Hinweis „mit CE-Projekt verknüpfen"). → **Entscheidung.**
4. **Doppelte CRA-Sicht:** `/cra/[projectId]` (standalone CRA-Flow) **und** `/iace/[projectId]/cra` (CE×Cyber im Maschinenprojekt). Beide behalten + klar abgrenzen, oder zusammenführen? → **Entscheidung (kein Löschen ohne OK).**
5. **`gap-analysis` vs. `intake`/`scope`:** beide beantworten „welche Pflichten treffen das Produkt?". Beide behalten (Gap = produktübergreifend, Intake/Scope = pro CRA-Projekt) oder Einstieg zusammenführen? → **Entscheidung.**
6. **`library` (IACE):** Referenz-/Kuratierungs-Tool — kundenseitig oder intern? → **Entscheidung.**

## Abdeckungs-Zusage
Jeder oben gelistete Screen ist **entweder** einer Ebene (E1/E2/E3) zugeordnet **oder** bleibt als Detail-Seite (**D**) erhalten. Kein Element ist als „entfällt" markiert. Reduktionen passieren nur über die **Waisen-Liste** mit deiner ausdrücklichen Entscheidung.