Basis: Certvia dev@a48c5fb als Fundament für Craftvia

Unveränderter Stand von certvia/dev (a48c5fb) plus Craftvia-Spezifikation
und Brandbook unter docs/craftvia/. ISMS-Module werden im Folgecommit entfernt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/wizard-uebergabe/01_Planung/Berater-Anweisung-Fachcontent.md

@@ -0,0 +1,68 @@
+# Anweisung an den Berater — Fachcontent-Zulieferung (parallel zur Entwicklung)
+
+Der Onboarding-Wizard hat seinen größten Engpass **nicht im Code, sondern im Fachcontent**. Die folgenden Arbeitspakete **C1–C9** laufen **parallel** zur Entwicklung und schalten jeweils eine oder mehrere Entwickler-Epics scharf. Bitte im angegebenen **Format** liefern und die **„muss vorliegen bis"**-Reihenfolge einhalten — sonst werden C2/C3/C4/C5/C6 zum kritischen Pfad.
+
+> Bezug: Entwickler-Epics siehe `Wizard-Entwickler-Backlog.md`. Bestehendes Vorlagenpaket: `seed/isms-vorlagenpaket-v2/` (34 Dokumente, `mapping.json`, `_verify.py`).
+
+---
+
+## Übersicht (was schaltet was frei)
+
+| WP | Inhalt | Schaltet frei | Format | Muss vorliegen bis |
+|---|---|---|---|---|
+| **C1** | AL2/AL3-Kennzeichnung + Prüfziel-Zuordnung je Control | A2 (Scoping/Filter) | Tabelle/CSV je Control | vor M2 |
+| **C2** | Fragenkatalog + Antwort→Wirkung-Mapping | B2 Regel-Engine, B3 Fragebogen | strukturierte Tabelle | vor M1/M2 |
+| **C3** | Regelfähige Vorlagen-Auszeichnung | B4 Richtlinien | Annotation im Vorlagenpaket | vor M2 |
+| **C4** | VDA-/Standard-Risiko-Katalog + Standardmaßnahmen | A6 Risiko | Tabelle/CSV | vor M4 |
+| **C5** | Reifegrad-Logik je Control | A7 Control-Assessment | Regeltabelle | vor M5 |
+| **C6** | Umsetzungshinweise je Teilanforderung | B5 + A7 | strukturierter Text je Anforderung | fortlaufend, Kern vor M3 |
+| **C7** | ISMS-Soll-Rollenmodell + Funktionstrennung | A4 Rollen | Regelliste + Vorlagen | vor M3 |
+| **C8** | Priorisierungslogik Gap + Quick-Wins | A8 Gap | Regeltext | vor M6 |
+| **C9** | Auswertungs-/Interpretationstexte + Export-Layout | B7 Readiness | Text + Layout-Skizze | vor M6 |
+
+---
+
+## Arbeitspakete im Detail
+
+### C1 — Scoping-Grundlage (→ A2)
+Je VDA-ISA-Control angeben: Zutreffen bei **AL2 / AL3** (SEHR HOCH), Zuordnung zu **Prüfzielen** (Info-Sicherheit / Prototypenschutz / Datenschutz), typische **Ausschluss-/Scope-Regeln**.
+**Format:** eine Zeile je Control/Teilanforderung mit Spalten `Control-ID · Typ (MUSS/SOLL/HOCH/SEHR HOCH) · AL2? · AL3? · Prüfziel · Scope-Bedingung`. (Baut auf den vorhandenen Flags/Typen im `mapping.json` auf.)
+
+### C2 — Fragenkatalog + Antwort→Wirkung-Mapping (→ B2, B3)
+Der geführte Fragebogen (Schritt 2) **und** die Regel-Engine hängen hieran. Je Frage: Text, Antworttyp, **Bedingung** (wann anzeigen), und die **Wirkung** jeder Antwort: welche **Variable/Platzhalter** gefüllt wird, welche **Klausel** ein-/ausgeblendet wird, welche **Controls/Assets/Risiken** betroffen sind, ob eine **Aufgabe** entsteht.
+**Format:** Tabelle `Frage-ID · Frage · Antwortoptionen · Anzeige-Bedingung · Wirkung(Variable / Klausel / Control / Risiko / Aufgabe)`. **Kritischer Pfad — bitte zuerst.**
+
+### C3 — Regelfähige Vorlagen-Auszeichnung (→ B4)
+Die 34 Vorlagen so **annotieren**, dass klar ist: welche **Klausel/Baustein** bei welcher **Antwort/Flag** erscheint bzw. entfällt, und welche **Controls** ein Dokument belegt.
+**Format:** Auszeichnung direkt im Vorlagenpaket-Stil (bestehende `{{#if FLAG}}`-Mechanik + `mapping.json`-Control-Verknüpfung); danach `python3 _verify.py` → **OK**.
+
+### C4 — Risiko-Katalog (→ A6)
+Kuratierter **Standard- und VDA-geforderter Risiko-Katalog**: je Risiko Beschreibung, betroffene **Assets/Controls**, empfohlene **Standardmaßnahmen**, Default-Bewertungshinweis.
+**Format:** Tabelle `Risiko-ID · Titel · Beschreibung · Controls · Asset-Typen · Standardmaßnahme(n) · Default-Einschätzung`.
+
+### C5 — Reifegrad-Logik (→ A7)
+Regeln, wie aus vorhandenen **Belegen** (Dokument/Risiko/Asset + Validierungsstatus) ein **Reifegrad-Vorschlag** je Control entsteht, und was der **Zielreifegrad** ist. Vorschlag ist regelbasiert, **Bestätigung durch Bearbeiter Pflicht**.
+**Format:** Regeltabelle `Control · Bedingung(Belege) · Reifegrad-Vorschlag · Zielreifegrad · offene-Punkt-Kriterium`.
+
+### C6 — Umsetzungshinweise (→ B5, A7)
+Je **Teilanforderung** ein Hinweis mit: **organisatorischer** Umsetzungsoption, **technischer** Option, typischen **Nachweisen**, passender **Vorlage** (Verweis), **Ressourcenindikation** (Tool/Personal/Budget/Zeit). Filterbar nach AL2/AL3.
+**Format:** strukturierter Block je Anforderungs-ID (Felder org/tech/Nachweise/Vorlage/Ressourcen). **Fortlaufend, Kern-Set vor M3.**
+
+### C7 — ISMS-Soll-Rollenmodell + Funktionstrennung (→ A4)
+Soll-Rollen (GF, ISB, DSB, IT-Verantwortung), **Funktionstrennungs-Regeln** (welche Kombination unzulässig), und die **Bestellungs-/Ernennungs-Vorlagen** (ISB-Bestellung etc.) mit Rollen-Platzhaltern.
+**Format:** Regelliste + Vorlagen im Paket-Stil (Platzhalter).
+
+### C8 — Priorisierungslogik Gap (→ A8)
+Wie offene Punkte priorisiert werden (Muss-/AL3-kritisch = hoch), Dedup-Kriterien, Definition **Quick-Wins**.
+**Format:** kurzer Regeltext + Beispiel-Priorisierung.
+
+### C9 — Auswertung & Export (→ B7)
+Interpretationstexte fürs Reifegrad-Dashboard, empfohlene nächste Schritte vor dem Assessment, und das **Layout des VDA-ISA-Katalog-Exports** (Reihenfolge, Felder, „bestätigt/unbestätigt").
+**Format:** Textbausteine + Layout-Skizze.
+
+---
+
+## Prozess-Hinweise
+- Zulieferung **iterativ** je Kapitel/Control-Gruppe möglich (nicht „alles auf einmal") — die Entwicklung kann teilbefüllt starten.
+- **ISB-Freigabe** der neuen/angepassten Texte (VA/Richtlinien) ist ein eigener fachlicher Schritt (steht bereits offen auf `dev`).
+- Alle Vorlagen-/Katalog-Änderungen nach dem Einspielen mit **`python3 seed/isms-vorlagenpaket-v2/_verify.py` → OK** gegenprüfen.

docs/wizard-uebergabe/01_Planung/Onboarding-Wizard-Machbarkeitsanalyse.md

@@ -0,0 +1,120 @@
+# Onboarding-Wizard — Machbarkeitsanalyse (Product Owner)
+
+Bewertung des Berater-Fahrplans (`Onboarding_Wizard_Fahrplan_Detail.md`) gegen den dokumentierten Funktionsstand (`HANDOVER-PM.md`, Stand 2026-07-20). Ziel: Umsetzbarkeit, Wiederverwendung vorhandener Funktionen, neue Funktionen, Komplexitäten — als Grundlage für die anschließende Aufgaben-/Epic-Definition.
+
+**Status-Legende:** ✅ Vorhanden (direkt nutzbar) · 🟡 Teilweise (erweitern) · 🟥 Neu (bauen)
+**Aufwand:** S ≤ 1 Tag · M 2–4 Tage · L > 1 Woche (Entwicklung; Fachcontent separat)
+
+---
+
+## 1. Gesamturteil
+
+**Der Wizard ist umsetzbar — und sitzt auf einem für dieses Vorhaben ungewöhnlich starken Fundament.** Rund zwei Drittel der fachlichen Bausteine existieren bereits produktiv (Assets/BIA, Risikoanalyse, Richtlinien-/Template-Engine mit Control-Mapping, importierter VDA-ISA-Katalog mit 316 Anforderungen/45 Controls, AL2/AL3-Schalter, Vier-Augen-Freigabe, Lieferanten-Reifegrad-/Gate-Logik, Coverage-Matrix, Audit-Log, Mandantenfähigkeit).
+
+Der Wizard ist damit **weniger „neues Modul" als vielmehr eine geführte Orchestrierung vorhandener Module** plus einige neue Quer­schnitts-Engines. Der eigentliche Aufwand liegt — wie der Fahrplan selbst richtig betont — **nicht in der Software, sondern im Fachcontent** (regelfähige Vorlagen, VDA-Risiko-Katalog, Umsetzungshinweise, Reifegrad-Logik). Das ist der kritische Pfad und zugleich die Stelle, an der die GEFIM-Projekt-DNA (~100 Projekte) zum Tragen kommt.
+
+**Drei Dinge müssen früh und sauber gebaut werden, sonst werden sie später teuer nachgezogen:** (1) ein generisches Aufgaben-Modul, (2) der generische Validierungs-Workflow, (3) der Regel-/Mapping-Layer. Sie sind die Klammer um alle Schritte.
+
+---
+
+## 2. Querschnittsmechaniken (Kap. 2 des Fahrplans)
+
+| Mechanik | Status | Vorhanden (wiederverwendbar) | Neu zu bauen | Aufwand | Risiko |
+|---|:--:|---|---|:--:|---|
+| **2.1 Validierungs-Workflow** | 🟡 | Vier-Augen-Freigabe Richtlinien (Entwurf→In Freigabe→Freigegeben), Lieferanten-ISB-Reifegrad-Freigabe, RBAC, Audit-Log | **Generisches** Status-/Review-Modell über alle Objekttypen (Modul/Richtlinie/Risiko/Control-Bewertung), Rolle „externer Berater" als Validierer, Kommentare, „unbestätigt zählt nicht" in der Auswertung | M | Querschnitt — früh bauen, nicht anflanschen |
+| **2.2 Umsetzungshinweise** | 🟡→🟥 | `implementation`-Feld je Anforderung im Katalog, Anwender-Handbuch (kuratiert, Deep-Links) | Strukturiertes Hinweis-Modell (org/tech/Nachweise/Vorlagen-Verweis/**Ressourcenindikation**), Scope-/Antwort-Filter, Inline-Panel | Backend S · FE S · **Content L** | Content-Flaschenhals (SME) |
+| **2.3 Maßnahmen → Aufgaben-Modul** | 🟡 | Maßnahmen-Kanban (risikobezogen), berechnetes Restrisiko | **Generisches** Aufgaben-Objekt (Typ/Verantwortlich/Fälligkeit/Priorität/**Ressourcen**/Herkunft/Verknüpfung Control·Risiko·Dok·Asset), Auto-Vorschlag aus Triggern + Bestätigung | M–L | **Keystone** — alle Schritte hängen daran |
+| **2.4 Audit-Trail & Versionierung** | 🟡 | Audit-Log vorhanden | Echte Versionierung (Richtlinien-Diff ist offen), Versionierung von Katalog/Templates/Risiko-Katalog + Instanz-Referenz + Update-Propagation | M–L | Verzahnt mit offener „Versionierung+Diff" & destruktivem Re-Import |
+
+---
+
+## 3. Fachliche Bausteine / Datenobjekte (Kap. 3)
+
+| Baustein | Status | Vorhanden | Neu / Lücke | Aufwand |
+|---|:--:|---|---|:--:|
+| Control-Katalog VDA ISA | ✅ | Import 316 Anforderungen / 45 Controls, je Anforderung adressierbar, Typen MUSS/SOLL/HOHER/SEHR HOHER | Ggf. explizite AL2/AL3-Kennzeichnung je Anforderung sichtbar machen (Flags vorhanden) | S |
+| Template-Bibliothek | ✅ | 28 Dokumente, Platzhalter/Variablen, optionale Klauseln via `{{#if}}`, Control-Verknüpfung, Freigabe | Regel-Tagging über Feature-Flags hinaus (Scope/Antwort-getrieben) | S–M |
+| Upload eigener Dokumente | 🟡 | (geplant) Word-Upload als Block-Modell + Anhang, versioniert | Control-Zuordnung des Uploads in die Nachweislage; Upload selbst ist noch offen | M |
+| Fakten-/Fragemodell | 🟡 | Variablen-Pflegestelle, Stammdaten (Settings) → ISMS-Variablen | **Dynamischer, bedingter Fragebogen** als wiederverwendbare Faktenobjekte | M |
+| Risiko-Katalog | 🟡 | Bedrohungs-/Schwachstellen-Kataloge, Risikoregister, Control-Verknüpfung | Kuratierter **Standard-/VDA-Risiko-Katalog** (vordefiniert, erweiterbar) | Backend M · **Content L** |
+| Regel-/Mapping-Layer | 🟡 | Handlebars-Flags, Variablen-Mapping, Lieferanten-Anforderungs-Engine (Schutzbedarf→Stufen) | **Generalisierung:** Antwort → betroffene Controls/Assets/Risiken (nicht nur Dokument-Klauseln) | L | 
+| Reifegrad-/Gap-Engine | 🟡 | Coverage-Matrix (Control↔Dokument), Lieferanten-Reifegrad-Freigabe, Gate→Risiko | Control-**Scoring aus Belegen** + Markierung offener Teilanforderungen | Backend M–L · SME M |
+
+---
+
+## 4. Die neun Schritte (Kap. 4)
+
+| Schritt | Status | Trägt auf vorhandenem auf | Neu zu bauen | Aufwand |
+|---|:--:|---|---|:--:|
+| **1 Scoping** | 🟡 | AL2/AL3-Schalter (global + Override), TISAX-Level in Settings | Scope-Objekt (Prüfziele/Standorte/Geltungsbereich/Ausschlüsse) + **Filterung** der Control-/Template-/Risiko-Sets | FE S · Backend M |
+| **2 Kontextaufnahme** | 🟡 | Stammdaten→Variablen | Geführter, **bedingter Fragebogen** + wiederverwendbare Faktenobjekte + Propagation | M |
+| **3 Rollen & Verantwortlichkeiten** | 🟡 | RBAC/Rollen je Mandant, RACI-Matrix (Lieferanten) | ISMS-Rollenmodell (GF/ISB/DSB/IT), **Funktionstrennungs-Prüfung**, Rollen-Platzhalter in Dokumenten (ISB-Bestellung) | Backend M · FE S |
+| **4 Richtlinien & VA** | ✅🟡 | Template-Tailoring (a) voll: variablenbasiert, Klausel-Ein/Ausblendung, Freigabe | (b) Upload+Control-Mapping (Upload offen); (c) „später erstellen" → Aufgabe (hängt an 2.3) | (a) ✅ · (b) M · (c) S |
+| **5 Asset-Inventar** | ✅ | Assets & BIA: C/I/A, Schutzbedarf, Eigentümer, Vererbung, Abhängigkeiten, Risiko-Verknüpfung | „unvollständig/kein Eigentümer" → Aufgabe (Trigger) | S |
+| **6 Risikomanagement** | ✅🟡 | 5×5-Heatmap, Register, Behandlung, Maßnahmen, Control-Verknüpfung | VDA-Risiko-Katalog-Auswahl; Maßnahme→Aufgabe (2.3); Methodik konfigurierbar (siehe Offen #2) | M |
+| **7 Control-Zuordnung & Reifegrad** | 🟡→🟥 | Coverage-Matrix, Beleg-Verknüpfung, Lieferanten-Reifegrad-Muster | **Control-Assessment-Oberfläche** (SoA ist bisher Platzhalter) + Reifegrad-Selbsteinschätzung + Gap-Markierung je Teilanforderung | Backend L · FE L · SME L |
+| **8 Gap- & Maßnahmenableitung** | 🟥 | Ergebnisse aus 6/7 | Aggregation/Dedup/Priorisierung → konsolidierte Gap-Liste (hängt an 2.3) | M |
+| **9 Assessment-Readiness** | 🟥 | validierte Objekte, Coverage-Daten | Reifegrad-Dashboard + vorausgefüllte VDA-ISA-Katalogsicht + **Export** (koppelt an offenen DOCX/PDF-Export) | Backend M · FE L |
+| **Wizard-Shell (implizit)** | 🟥 | — | Geführter Multi-Step-Flow: Zustand, Fortschritt, Gates, Wiederaufnahme, „bestätigt/unbestätigt"-Propagation | M–L |
+
+---
+
+## 5. Was wirklich neu gebaut werden muss (verdichtete Liste)
+
+1. **Wizard-Shell / State-Machine** (Flow, Fortschritt, Gates, Resume). 🟥 M–L
+2. **Generisches Aufgaben-Modul** (2.3) — Keystone. 🟡→ M–L
+3. **Generischer Validierungs-Workflow** (2.1) inkl. externer-Berater-Rolle. 🟡→ M
+4. **Regel-/Mapping-Layer generalisiert** (Antwort→Controls/Assets/Risiken). 🟡→ L
+5. **Scope-Objekt + Filter-Engine** (Schritt 1). 🟥 M
+6. **Dynamischer Fragebogen** (Schritt 2). 🟥 M
+7. **ISMS-Rollenmodell + Funktionstrennung** (Schritt 3). 🟥 M
+8. **Control-Assessment / Reifegrad-Gap-Engine** (Schritt 7, SoA-Surface). 🟥 L
+9. **Gap-Konsolidierung** (Schritt 8). 🟥 M
+10. **Assessment-Readiness-Dashboard + Export** (Schritt 9, koppelt an DOCX/PDF-Export). 🟥 L
+11. **Umsetzungshinweis-Content-Modell + Inline-Panel** (2.2). 🟡→ Backend/FE S, Content L
+12. **Versionierung/Diff + Update-Propagation** (2.4; löst zugleich offenen destruktiven Re-Import). 🟡→ M–L
+
+**Direkt wiederverwendbar (kaum/kein Neubau):** Assets/BIA · Risikoanalyse (Kern) · Richtlinien-Template-Engine · Control-Katalog VDA-ISA · AL2/AL3-Schalter · Vier-Augen-Freigabe (als Muster) · Coverage-Matrix · Lieferanten-Anforderungs-/Reifegrad-Engine (als Muster) · Audit-Log · Multi-Tenant/RBAC · Stammdaten→Variablen.
+
+---
+
+## 6. Größte Komplexitäten & Risiken (priorisiert)
+
+1. **Fachcontent ist der kritische Pfad** (bestätigt der Fahrplan selbst): regelfähige Vorlagen, VDA-Risiko-Katalog, **Umsetzungshinweise je Teilanforderung**, Reifegrad-Logik. Muss **parallel und früh** von der Beratung erstellt werden — sonst blockiert er M3/M4/M5/M7.
+2. **Regel-/Mapping-Engine (Generalisierung).** Heute: Klausel-Flags + Variablen + Lieferanten-Engine. Neu: eine Antwort steuert Dokument-Klauseln **und** Control-Relevanz **und** Risiko-/Asset-Bezug. Architektur-Kernrisiko — Regel-Syntax und Test­barkeit früh festzurren.
+3. **Control-Assessment/Reifegrad (Schritt 7).** Das „SoA & Controls"-Modul ist bisher nur Platzhalter; hier entsteht die eigentliche Assessment-Oberfläche. Größter einzelner FE/Backend-Block.
+4. **Versionierung & Update-Propagation.** Solange Re-Import destruktiv ist und Richtlinien keine echte Versionierung haben, sind laufende Kundeninstanzen bei Katalog-/Template-Updates gefährdet. Muss vor „Katalog lebt beim Kunden" gelöst sein.
+5. **Keystones Aufgaben-Modul & Validierungs-Workflow** früh, sonst teurer Umbau (Schritte 3–9 hängen daran).
+6. **Export/North-Star** (vorausgefüllter VDA-ISA-Katalog) koppelt an den offenen DOCX/PDF-Export.
+
+---
+
+## 7. Antworten auf die offenen Entscheidungspunkte des Fahrplans (Kap. 7), PO-Sicht
+
+1. **Upload-Gap-Check:** Start mit **manueller Control-Zuordnung** (deckt sich mit dem bereits geplanten Word-Upload); automatischer Inhalt↔Anforderung-Abgleich später als KI-Ausbaustufe (koppelt an geplanten „KI-Wizard").
+2. **Risiko-Methodik:** **mandantenspezifisch konfigurierbar**, aber zuvor die zwei bestehenden Matrizen (5×5 Risikoanalyse / 4×4 FB-80-04 im Richtlinienmodul) **auf eine zentrale Skala vereinheitlichen** (steht bereits als offener Punkt).
+3. **Versionierung/Propagation:** **nicht-destruktives Update mit Diff** und expliziter Übernahme je Instanz (löst zugleich den destruktiven Re-Import). Voraussetzung für „Katalog beim Kunden".
+4. **Validierungs-Granularität:** **pro Objekt** (einzelne Richtlinie/Risiko/Control-Bewertung) **plus** Modul-Gate — die Freigabe-Logik ist heute schon objektbezogen (Richtlinien) und wird generalisiert.
+5. **Aufgaben-Modul:** existiert **nur teilweise** (Maßnahmen-Kanban, risikobezogen) → **muss generalisiert werden**; die Task-Erzeugung ist mitzuplanen (Keystone).
+6. **Reifegrad-Vorschlag:** **regelbasiert vorgeschlagen, mit Pflicht zur Bestätigung** durch den Bearbeiter (entspricht dem vorhandenen Lieferanten-Reifegrad-Freigabe-Muster).
+
+---
+
+## 8. Empfohlene Reihenfolge (für die Aufgaben-Definition)
+
+Angelehnt an M1–M7 des Fahrplans, sortiert nach Abhängigkeit und Wiederverwendung:
+
+1. **Querschnitt-Keystones zuerst:** Aufgaben-Modul (2.3), Validierungs-Workflow (2.1), Versionierung/Diff (2.4), Wizard-Shell. *(sonst später teurer Umbau)*
+2. **Regel-/Scope-Fundament:** Scope-Objekt + Filter (Schritt 1), Regel-/Mapping-Layer, Fragebogen (Schritt 2).
+3. **Wiederverwendung einklinken:** Richtlinien (Schritt 4, größtenteils vorhanden), Assets (Schritt 5, vorhanden), Risiko (Schritt 6, Kern vorhanden + VDA-Katalog).
+4. **Neuer Kern:** Control-Assessment/Reifegrad (Schritt 7), Gap-Konsolidierung (Schritt 8).
+5. **Output:** Assessment-Readiness-Dashboard + Export (Schritt 9).
+6. **Durchgängig parallel:** Fachcontent (SME/Beratung) + Umsetzungshinweise (2.2).
+
+---
+
+## 9. Nächster Schritt
+Auf dieser Basis die **Entwickler-Aufgaben als Epics/Stories** definieren — vorgeschlagene Epic-Schnitte:
+**E1** Aufgaben-Modul · **E2** Validierungs-Workflow · **E3** Wizard-Shell & Navigation · **E4** Scope & Regel-/Mapping-Layer · **E5** Fragebogen/Fakten · **E6** ISMS-Rollen & Funktionstrennung · **E7** Richtlinien-Anbindung (Upload/Control-Mapping) · **E8** Risiko-Katalog & -Anbindung · **E9** Control-Assessment/Reifegrad-Gap · **E10** Gap-Konsolidierung · **E11** Assessment-Readiness/Export · **E12** Versionierung/Propagation · **E13** Umsetzungshinweise (Content+Panel) · **C1** Fachcontent (querlaufend).
+
+> Offen für die Feinspezifikation: Regel-Syntax, Aufgaben-Objekt-Schema, Reifegrad-Scoring-Formel, Export-Format des VDA-ISA-Katalogs. Diese vier zuerst festzurren — sie determinieren den Rest.

docs/wizard-uebergabe/01_Planung/Wizard-Entwickler-Backlog.md

@@ -0,0 +1,133 @@
+# Onboarding-Wizard — Entwickler-Backlog (2 Full-Stack-Lanes, parallel auf `dev`)
+
+Grundlage: `Onboarding_Wizard_Fahrplan_Detail.md` (Berater), `STAND-dev-branch.md` (Ist-Stand `dev`, 2026-07-24), `Onboarding-Wizard-Machbarkeitsanalyse.md`.
+Aufbau: **2 Entwickler**, je **vertikaler Feature-Slice** (BE+FE+Migration) auf eigenem **Feature-Branch unter `dev`**. Umfang: **kompletter Wizard**. Manueller Richtlinien-Upload: **UI/Modell jetzt, Datei-Speicher später** (Storage-Adapter gestubbt).
+
+> Fachliche Zulieferungen (SME/Berater) sind je Epic mit **🧩 SME** markiert und in `Berater-Anweisung-Fachcontent.md` als Arbeitspakete C1–C9 ausformuliert.
+
+---
+
+## 0. Arbeitsmodell, Branching & Definition of Done
+
+**Branching**
+- Basis-Branch: **`dev`** (nicht `main`). Alle Feature-Branches zweigen von `dev` ab, PR-Ziel ist `dev`.
+- Namensschema: **`dev/<lane><n>-<slug>`** — z. B. `dev/a1-wizard-shell`, `dev/b2-regel-engine`.
+- **Dev A = Lane A** („Flow, Governance & Bewertung"), **Dev B = Lane B** („Engines, Inhalte & Ausgabe").
+- Häufig auf `dev` rebasen (mind. täglich), kleine PRs je Epic, Review durch die jeweils andere Person.
+
+**Definition of Done (jede Story)**
+- `npx tsc --noEmit` → `npm run lint` → `npm run build` grün (der `prebuild`-Guard-Check läuft mit).
+- Neue Server-Action-Datei ist in **`scripts/check-module-guards.ts`** eingetragen (Modul-Key oder `EXEMPT`).
+- Neues tenant-gebundenes Modell in **`TENANT_MODELS`** (`src/server/db.ts`) **und** RLS-Policy in der Migration.
+- Migration erstellt (Prisma-7-Flow) inkl. manuell angehängtem **RLS-DO-Block**; läuft via `migrate deploy`.
+- Wenn Seed/Vorlagenpaket berührt: `python3 seed/isms-vorlagenpaket-v2/_verify.py` → **OK**.
+- Browser-Verifikation der Kern-Flows; Demo-Daten/Seed weiterhin lauffähig.
+
+**Geteilte „Hot Files" — nur koordiniert anfassen (Konflikt-Risiko):**
+`prisma/schema.prisma` · Migrationsreihenfolge · `src/lib/modules.ts` · `scripts/check-module-guards.ts` · `src/server/db.ts` (`TENANT_MODELS`) · das Wizard-Shell-Step-Registry (Lane A liefert, Lane B registriert Steps).
+→ Migrationen **nie gleichzeitig** ohne Absprache erzeugen; jede Lane hält ihre Migration isoliert und rebased vor dem Erstellen.
+
+---
+
+## 1. Zuerst festzurren — Foundation-Contracts (gemeinsam, VOR den Lanes)
+
+Ein kurzer gemeinsamer Branch **`dev/foundation-contracts`** (1 Person federführend, andere reviewt), **zuerst nach `dev` gemergt**. Legt die vier Verträge fest, die alles andere determinieren:
+
+1. **Aufgaben-Objekt-Schema** — Erweiterung des bestehenden `Task`/`TaskComment` (heute Typ `policy_approval`) um: `type` (`document_create` / `evidence_provide` / `technical` / `organizational` / `validation`), `owner`, `dueDate`, `priority`, `status`, **`resources` (JSON: tool/budget/personnel/time)**, **`origin` (auslösender Schritt)**, polymorphe Verknüpfung (`control` / `risk` / `document` / `asset`). RLS wie gehabt.
+2. **Objekt-Validierungs-Status** — einheitliches Enum `offen → in_bearbeitung → zur_validierung → validiert | zurueckgewiesen(+Kommentar)` als wiederverwendbares Feld/Mixin über Objekttypen; Rolle **`external_validator`** (externer Berater).
+3. **Regel-/Mapping-DSL** — Vertrag: `Bedingung(Antwort/Scope/Flag) → Wirkung(Klausel ein/aus · Control relevant/irrelevant · Risiko/Asset-Bezug · Aufgabe)`. JSON-basiert, testbar; baut auf vorhandenen Handlebars-Flags + Lieferanten-Anforderungs-Engine auf.
+4. **Assessment-Readiness-Export-Format** — Datenschema des vorausgefüllten VDA-ISA-Katalogs (Control → Teilanforderungen → Reifegrad/Belege/offene Punkte/Status „bestätigt|unbestätigt").
+
+**Aufwand:** M (Schema-/Typ-Definitionen + Migration `tasks`-Erweiterung). **DoD:** Typen/Interfaces + Task-Migration gemergt, damit beide Lanes darauf bauen.
+
+---
+
+## 2. Lane A — Dev A: „Flow, Governance & Bewertung"
+
+| Epic | Branch | Hängt ab von | Aufwand | 🧩 SME |
+|---|---|---|---|:--:|
+| **A1 Wizard-Shell & Navigation** | `dev/a1-wizard-shell` | Foundation | M–L | – |
+| **A2 Scoping + AL2/AL3 zentral (Adminportal) + Scope-Filter** | `dev/a2-scoping-admin-al` | A1 | M | 🧩 C1 |
+| **A3 Validierungs-Workflow generalisieren** | `dev/a3-validation-workflow` | Foundation, B1 | M | – |
+| **A4 ISMS-Rollen & Funktionstrennung (Schritt 3)** | `dev/a4-isms-rollen` | A1, A3 | M | 🧩 C7 |
+| **A5 Asset-Anbindung Wizard (Schritt 5, Reuse)** | `dev/a5-assets-step` | A1 | S | – |
+| **A6 Risiko-Katalog & Anbindung (Schritt 6)** | `dev/a6-risiko-katalog` | A1, B2 | M–L | 🧩 C4 |
+| **A7 Control-Assessment & Reifegrad/Gap (Schritt 7, SoA)** | `dev/a7-control-assessment` | A2, B1, B2, B5 | L | 🧩 C5, C6 |
+| **A8 Gap-Konsolidierung (Schritt 8)** | `dev/a8-gap-konsolidierung` | A6, A7, B1 | M | 🧩 C8 |
+
+**A1 — Wizard-Shell & Navigation.** Neuer Bereich `src/app/(app)/onboarding/**` + `src/server/actions/onboarding.ts` (in `check-module-guards.ts` registrieren; neues Modul `onboarding` in `src/lib/modules.ts`). Multi-Step-State-Machine mit Fortschritt, **Gates** (Schritt „validiert" bevor weiter), **Wiederaufnahme**, und einem **Step-Registry**, in das Lane B ihre Schritt-Komponenten einklinkt (klare Datei-Trennung je Schritt). Persistenter Wizard-Fortschritt je Mandant. *Akzeptanz:* Flow ist resumierbar; Gates blockieren korrekt; Schritte sind als eigenständige Module registrierbar.
+
+**A2 — Scoping + AL2/AL3 zentral im Adminportal.** (Explizite Anforderung.) Der **AL2/AL3-Schalter wird zentral im Superadmin-/Adminportal** gesetzt (`src/app/(platform)/admin/**` + `src/server/actions/admin.ts`/`platform.ts`) als Teil der Mandanten-Kern-Config — **einzige Quelle der Wahrheit**. Schritt 1 (Scoping) liest ihn **read-only** (nur Superadmin ändert), plus Prüfziele/Standorte/Geltungsbereich/Ausschlüsse → **Scope-Objekt**. Scope filtert nachgelagert Control-/Template-/Risiko-Sets (an vorhandene Coverage-Filter-Logik nach Assessment-Level andocken). *Akzeptanz:* AL nur im Adminportal änderbar; Änderung propagiert in Coverage/Zusatzanforderungen; nicht relevante Controls/Templates ausgeblendet. **🧩 C1** (AL2/AL3-Kennzeichnung + Prüfziel-Zuordnung je Control).
+
+**A3 — Validierungs-Workflow generalisieren.** Den bestehenden Vier-Augen-Freigabe-/Task-Mechanismus (`policy_approval`) zu einem **generischen Objekt-Review** über alle Typen ausbauen (Modul/Richtlinie/Risiko/Control-Bewertung): Status-Feld (Foundation #2), Reviewer-Zuweisung inkl. **externer Berater**, Kommentare, „unbestätigt zählt nicht" in Auswertungen. Wiederverwendet `src/server/actions/tasks.ts` + `submitForApproval`. *Akzeptanz:* jedes Objekt trägt Review-Status; nur „validiert" zählt als bestätigt; externer Validierer-Rolle testbar.
+
+**A4 — ISMS-Rollen & Funktionstrennung (Schritt 3).** ISMS-Rollenmodell (GF/ISB/DSB/IT) auf Basis vorhandener RBAC/RACI; **Funktionstrennungs-Prüfung** (z. B. ISB ≠ IT); Rollen-Platzhalter in Dokumente (ISB-Bestellung aus Vorlage). Konflikt → Hinweis/Aufgabe (A3/B1). *Akzeptanz:* Funktionstrennungs-Konflikt wird erkannt und als Aufgabe ausgewiesen. **🧩 C7**.
+
+**A5 — Asset-Anbindung Wizard (Schritt 5).** Dünne Wizard-Schicht auf das bestehende Assets/BIA-Modul (C/I/A, Schutzbedarf, Eigentümer, Abhängigkeiten sind vorhanden). Trigger „Inventar unvollständig / kein Eigentümer" → Aufgabe (B1). *Akzeptanz:* Wizard nutzt Bestands-Assets; Trigger erzeugt Aufgabe.
+
+**A6 — Risiko-Katalog & Anbindung (Schritt 6).** Bewertungs-/Register-Kern existiert (5×5, Behandlung, Control-Verknüpfung). Neu: **kuratierter Standard-/VDA-Risiko-Katalog** (Auswahl + eigene Ergänzung), Verknüpfung Asset/Control, Maßnahme→Aufgabe (B1). *Akzeptanz:* VDA-geforderte Risiken auswählbar; inakzeptables Risiko hat Behandlung; Maßnahmen erzeugen Aufgaben. **🧩 C4** (Kataloginhalt + Standardmaßnahmen).
+
+**A7 — Control-Assessment & Reifegrad/Gap (Schritt 7, SoA).** Größter Block: baut die bislang fehlende **SoA-/Control-Oberfläche**. Je Control: Beleg-Verknüpfung (Dok/Risiko/Asset), **Reifegrad-Selbsteinschätzung** mit regelbasiertem Vorschlag (aus Belegen) **+ Pflichtbestätigung** (Muster: Lieferanten-Reifegrad-Freigabe), Markierung offener Teilanforderungen; unter Ziel → Aufgabe. Nutzt Coverage-Daten + Foundation-Export-Schema. *Akzeptanz:* jede relevante Teilanforderung adressiert; Reifegradvorschlag nachvollziehbar an Belege gekoppelt. **🧩 C5** (Reifegrad-Logik), **🧩 C6** (Umsetzungshinweis-Content, via B5).
+
+**A8 — Gap-Konsolidierung (Schritt 8).** Aggregation/Dedup/Priorisierung (Muss/AL3 = hoch) aus Schritt 6+7 zu einer konsolidierten Gap-/Maßnahmenliste, abgeglichen mit Aufgaben (B1). *Akzeptanz:* keine Dopplungen; jeder offene Punkt hat Priorität + ggf. Aufgabe. **🧩 C8** (Priorisierungslogik/Quick-Wins).
+
+---
+
+## 3. Lane B — Dev B: „Engines, Inhalte & Ausgabe"
+
+| Epic | Branch | Hängt ab von | Aufwand | 🧩 SME |
+|---|---|---|---|:--:|
+| **B1 Aufgaben-Modul erweitern** | `dev/b1-tasks-erweiterung` | Foundation | M | – |
+| **B2 Regel-/Mapping-Layer** | `dev/b2-regel-engine` | Foundation | L | 🧩 C2 |
+| **B3 Fragebogen/Fakten (Schritt 2)** | `dev/b3-fragebogen` | A1, B2 | M | 🧩 C2 |
+| **B4 Richtlinien: Import-bei-Aktivierung + manueller Upload + Control-Mapping (Schritt 4 + Menü)** | `dev/b4-richtlinien-import-upload` | Foundation | M–L | 🧩 C3 |
+| **B5 Umsetzungshinweise (Content-Modell + Inline-Panel)** | `dev/b5-umsetzungshinweise` | A1 | S (Code) | 🧩 C6 |
+| **B6 Versionierung/Propagation** | `dev/b6-versionierung` | B4 | M–L | – |
+| **B7 Assessment-Readiness & Export (Schritt 9)** | `dev/b7-readiness-export` | A7, A8 | L | 🧩 C9 |
+
+**B1 — Aufgaben-Modul erweitern.** Das generische `Task`-Modell (heute `policy_approval`) um die Foundation-Felder erweitern; **Auto-Generierung** aus Triggern (Schritt 3/4/6/7/8, Zurückweisung) als **Vorschlag mit Bestätigung**; Ressourcenfelder editierbar; Verknüpfungen Control/Risiko/Dok/Asset; Anzeige/Filter im bestehenden Modul „Aufgaben" (`src/app/(app)/tasks/`). *Akzeptanz:* Trigger erzeugt Aufgabenvorschlag mit korrekten Verknüpfungen/Ressourcen; Bestätigung übernimmt.
+
+**B2 — Regel-/Mapping-Layer.** Umsetzung der DSL (Foundation #3) als testbare Engine `src/lib/rules/**`: Antwort/Scope/Flag → Klausel-Ein/Ausblendung (Handlebars-Flags erweitern), betroffene Controls/Assets/Risiken, Aufgaben-Trigger. Isoliert + unit-getestet. *Akzeptanz:* Regelauswertung deterministisch, mit Testfällen belegt; Änderung einer Antwort propagiert sichtbar. **🧩 C2** (Antwort→Wirkung-Mapping).
+
+**B3 — Fragebogen/Fakten (Schritt 2).** Dynamischer, **bedingter Fragebogen**; Antworten als **wiederverwendbare Faktenobjekte** (an vorhandene zentrale Variablen/Stammdaten andocken, ohne die Sperre der zentralen Variablen zu verletzen). Bedingte Sichtbarkeit über B2. *Akzeptanz:* Antworten wiederverwendbar; Änderung propagiert in abhängige Objekte/Platzhalter. **🧩 C2** (Fragenkatalog).
+
+**B4 — Richtlinien: Import-bei-Aktivierung + manueller Upload + Control-Mapping.** (Explizite Anforderung.) Zwei Wege:
+- **(a) Vorlagen-Import bei Modul-Aktivierung:** Wird das **Richtlinien-Modul im Superadmin/Adminportal aktiviert**, wird das Vorlagenpaket **mandantenweit importiert** — die vorhandene **nicht-destruktive** Logik (`prisma/import-policies.ts`, Diff/Upsert/`archivedAt`) als **serverseitig auslösbare Aktion/Job** kapseln (statt nur CLI/Seed). Zusätzlich Button „Vorlagen importieren/aktualisieren" (Admin bzw. `/policies`). Idempotent, Änderungsreport.
+- **(b) Manueller Upload eigener Richtlinien direkt im Menü `/policies`:** Einstiegspunkt + Metadaten-/Block-Modell + **Control-Zuordnung** jetzt bauen; **Datei-Persistenz über einen Storage-Adapter-Interface stubben** (echtes Storage-Backend = Folge-Epic **S1**, außerhalb dieses Batches). Upload erfasst Datei-Referenz/Platzhalter + Control-Mapping in die Nachweislage. *Akzeptanz:* Modul-Aktivierung importiert Vorlagen nicht-destruktiv; unter `/policies` existiert „Eigene Richtlinie hochladen" mit Control-Zuordnung; Storage-Adapter ist gekapselt und später ohne UI-Änderung verdrahtbar. **🧩 C3** (regelfähige Vorlagen-Auszeichnung).
+
+**B5 — Umsetzungshinweise (Content-Modell + Inline-Panel).** Strukturiertes Hinweis-Modell (org/tech/Nachweise/Vorlagen-Verweis/**Ressourcenindikation**), Scope-/Antwort-Filter (B2), kontextsensitives Inline-Panel an Teilanforderungen/Risiken/Templates. Code klein — **Inhalt ist der Aufwand**. *Akzeptanz:* passende Hinweise werden nach Scope/Antworten gefiltert eingeblendet; führen bei Maßnahme zu Aufgabe (B1). **🧩 C6**.
+
+**B6 — Versionierung/Propagation.** Versionierung von Katalog/Templates/Risiko-Katalog + **Instanz-Referenz auf genutzte Version** + **Diff & gesteuerte Übernahme** bei Updates (löst zugleich den heute noch offenen Richtlinien-Diff und flankiert den nicht-destruktiven Re-Import). *Akzeptanz:* laufende Kundeninstanz bekommt bei Update einen Diff und übernimmt kontrolliert; nichts wird still überschrieben.
+
+**B7 — Assessment-Readiness & Export (Schritt 9).** Reifegrad-Dashboard je Kapitel/gesamt, vorausgefüllte **VDA-ISA-Katalogsicht**, Maßnahmenplan; „bestätigt vs. unbestätigt" nach Validierungsstatus (A3); **Export** (koppelt an den offenen DOCX/PDF-Export). *Akzeptanz:* Kennzahlen stimmen mit Einzelbewertungen; Export vollständig/nachvollziehbar. **🧩 C9** (Auswertungs-/Interpretationstexte, Export-Layout).
+
+---
+
+## 4. Sequenz / Meilensteine (2 Lanes im Takt)
+
+| Takt | Dev A (Lane A) | Dev B (Lane B) | Gate |
+|---|---|---|---|
+| **M0** | Foundation-Contracts (gemeinsam) | Foundation-Contracts (gemeinsam) | Contracts + `tasks`-Migration auf `dev` |
+| **M1** | A1 Wizard-Shell | B1 Tasks-Erweiterung · B2 Regel-Engine (Kern) | Shell + Task-API stehen |
+| **M2** | A2 Scoping/Admin-AL | B4 Richtlinien-Import/Upload · B3 Fragebogen | AL zentral · Import läuft |
+| **M3** | A3 Validierung · A4 Rollen | B5 Umsetzungshinweise | Review generisch |
+| **M4** | A5 Assets · A6 Risiko-Katalog | B6 Versionierung | Katalog/Risiko nutzbar |
+| **M5** | A7 Control-Assessment (SoA) | (Puffer/Review A7) · Start B7 | Kern-Bewertung steht |
+| **M6** | A8 Gap-Konsolidierung | B7 Readiness & Export | North-Star: Readiness-Export |
+
+**Kürzester Pfad zur Assessment-Readiness:** M0→M1→M2→…→M6. Governance (A3/B1/B5/B6) läuft bewusst mit, nicht am Ende.
+
+---
+
+## 5. Explizite Anforderungen (Kurz-Referenz)
+- **AL2/AL3 zentral im Adminportal:** → **A2** (einzige Quelle im Superadmin/Admin; Scoping liest read-only; treibt Coverage/AL3-Zusatzanforderungen).
+- **Richtlinien-Vorlagen-Import bei Modul-Aktivierung + manueller Upload im Menü:** → **B4** (Import nicht-destruktiv on-enable; manueller Upload jetzt als UI/Modell/Control-Mapping, Datei-Speicher via Storage-Adapter später = Folge-Epic **S1**).
+
+## 6. Außerhalb dieses Batches (Folge-Epics)
+- **S1 Storage-Backend** (Coolify-Volume/MinIO) — schaltet echten Datei-Upload (B4b, Netzplan REG-NET, Nachweis-Upload) scharf.
+- **Paket 4** (SMTP/Einladung), **NIS2-Modul**, **Admin Phase 2** (Impersonation/Plan-Limits) — unverändert im Backlog.
+
+---
+
+## 7. Nächster Schritt
+Foundation-Contracts (Abschnitt 1) gemeinsam finalisieren und mergen → dann Lanes starten. Fachliche Zulieferung C1–C9 parallel anstoßen (siehe `Berater-Anweisung-Fachcontent.md`), sonst werden C2/C3/C4/C5/C6 zum kritischen Pfad für A2/A6/A7 und B2/B3/B4/B5.

docs/wizard-uebergabe/01_Planung/Wizard-Stories.md

@@ -0,0 +1,174 @@
+# Onboarding-Wizard — Story-Backlog (umsetzungsreif, mit Fachcontent C1–C9)
+
+Basis: `Wizard-Entwickler-Backlog.md` (2 Lanes) + Fachcontent `Fachcontent_Wizard_C1-C9` + Dev-Stand `dev` (2026-07-24).
+Jede Story: **ID · Titel · (Lane/Branch) · User Story · Akzeptanzkriterien · Technik/Dateien · Fachcontent · Abhängigkeit**.
+
+**Konventionen (für alle Stories):** DoD wie im Backlog (§0: `tsc`+`lint`+`build`/Guard-Check, `TENANT_MODELS`+RLS, Migration+RLS-DO-Block, `_verify.py`→OK bei Seed-Änderung, Browser-Verifikation). Story-Größe: S/M/L.
+**Fachcontent-Referenzen:** C1 = Scoping/AL-Tabelle (412 Anf.), C2 = Fragenkatalog+Wirkung, C3 = Vorlagen-Annotation, C4 = Risikokatalog (39 Risiken), C5 = Reifegrad R0–R3, C6 = Umsetzungshinweise (~397 Blöcke), C7 = Rollen/FT-01…06, C8 = Priorisierung/Dedup, C9 = Auswertung/Export.
+
+---
+
+## F — Foundation-Contracts (`dev/foundation-contracts`, gemeinsam, zuerst mergen)
+
+### F1 — Aufgaben-Objekt-Schema erweitern (M)
+**Als** Entwickler **möchte ich** das bestehende `Task`/`TaskComment`-Modell um Wizard-Felder erweitern, **damit** alle Schritte Aufgaben einheitlich erzeugen.
+- **AK:** `Task` besitzt `type` (`document_create|evidence_provide|technical|organizational|validation`), `owner`, `dueDate`, `priority`, `status`, `resources` (JSON: tool/budget/personnel/time), `origin` (Schritt), polymorphe Verknüpfung `control|risk|document|asset`. Bestehender Typ `policy_approval` bleibt lauffähig.
+- **Technik:** `prisma/schema.prisma` (`Task`), Migration `tasks_wizard_fields`, `TENANT_MODELS`+RLS, `src/server/actions/tasks.ts` erweitern (in `check-module-guards.ts` registriert).
+- **Fachcontent:** C2 §8 (Task-Trigger), C8 (Priorität/Dedup als Feldsemantik).
+
+### F2 — Einheitlicher Objekt-Validierungsstatus + externe-Validierer-Rolle (M)
+**Als** ISB/Berater **möchte ich** jedes bewertbare Objekt gleich validieren.
+- **AK:** wiederverwendbares Status-Feld `offen|in_bearbeitung|zur_validierung|validiert|zurueckgewiesen(+Kommentar)`; Rolle `external_validator` in RBAC; „unbestätigt zählt nicht" ist als Query-Helfer verfügbar.
+- **Technik:** Mixin/Enum in `schema.prisma`; RBAC-Recht; baut auf `submitForApproval`/`tasks.ts`.
+- **Fachcontent:** C5 (Validierungsstatus je Beleg), C9 (bestätigt/unbestätigt).
+
+### F3 — Regel-/Mapping-DSL-Vertrag (M)
+**Als** Entwickler **möchte ich** einen testbaren Regel-Vertrag, **damit** Antworten/Scope/Flags Wirkungen auslösen.
+- **AK:** JSON-Schema `Bedingung(Antwort|Scope|Flag) → Wirkung(Klausel|Control|Risiko|Asset|Aufgabe)`; Referenz-Testfälle aus C2 §5 (Q-FEAT-01…10) grün.
+- **Technik:** `src/lib/rules/dsl.ts` (Typen) + Unit-Test-Harness. Noch keine UI.
+- **Fachcontent:** C2 (Wirkungsmatrix), C1 (Scope-Bedingung-Spalte).
+
+### F4 — Wizard-Variablen/Flags erweitern (`variables.schema.json`) (S)
+**Als** Content-Owner **möchte ich** neue Flags/Variablen registriert haben, **damit** `_verify.py` sie kennt.
+- **AK:** `FLAG_PROTOTYPE_PROTECTION`, `FLAG_ISB_EXTERNAL`, `FLAG_ISB_INTERNAL` + fehlende `ROLE_*`/`TECH_*` aus C2 ergänzt; `python3 _verify.py` → **OK**.
+- **Technik:** `seed/isms-vorlagenpaket-v2/variables.schema.json`.
+- **Fachcontent:** C0 (offene Punkte 2), C2 §3–6, C7 §3. **Abh.:** vor B2/B3/B4/A4.
+
+---
+
+## Lane A — Dev A
+
+### A1 — Wizard-Shell & Navigation (`dev/a1-wizard-shell`)
+**A1-1 Step-Registry & State-Machine (L).** Multi-Step-Flow mit Fortschritt, Gates, Wiederaufnahme; Schritte als registrierbare Module.
+- **AK:** Fortschritt je Mandant persistent; ein Gate blockiert „weiter", bis das Vorgänger-Objekt `validiert` ist (F2); Steps sind per Registry einklinkbar (Lane B liefert Step-Inhalte).
+- **Technik:** `src/app/(app)/onboarding/**`, `src/server/actions/onboarding.ts`, neues Modul `onboarding` in `src/lib/modules.ts`; Migration `onboarding_progress`.
+**A1-2 Fortschritts-/Status-Dashboard-Kachel (S).** Kachel „Onboarding-Fortschritt" analog vorhandener Dashboard-Kachel.
+
+### A2 — Scoping + AL2/AL3 zentral im Adminportal (`dev/a2-scoping-admin-al`)
+**A2-1 AL2/AL3 zentral im Admin/Superadmin (M).** *(Explizite Anforderung.)*
+- **AK:** Der Assessment-Level (AL2/AL3) wird **ausschließlich** im Admin-/Superadmin-Portal je Mandant gesetzt (einzige Quelle); im Scoping read-only; treibt bestehende Coverage-Filter + `FLAG_HIGH/VERY_HIGH_PROTECTION`.
+- **Technik:** `src/app/(platform)/admin/**`, `src/server/actions/admin.ts`/`platform.ts`; Mandanten-`/settings` verliert die Änderungs-Kompetenz (nur Anzeige).
+**A2-2 Scope-Objekt + Filter-Engine (M).**
+- **AK:** Scoping erfasst Prüfziele (IS/Prototyp/Datenschutz), Standorte, Geltungsbereich, Ausschlüsse → Scope-Objekt; Filter blendet Anforderungen nach **AL + Flag + Prüfziel** exakt gemäß C1 aus (z. B. `HOCH` nur bei `FLAG_HIGH_PROTECTION`; 8.x nur bei Prototyp).
+- **Technik:** Scope-Modell + `src/lib/scope-filter.ts`; Import der C1-Tabelle als Datenquelle je Anforderung.
+- **Fachcontent:** **C1** (AL2/AL3 + Prüfziel + Scope-Bedingung je Anforderung, 412 Zeilen). **Abh.:** F3, A1.
+
+### A3 — Validierungs-Workflow generalisieren (`dev/a3-validation-workflow`)
+**A3-1 Generisches Objekt-Review (M).**
+- **AK:** Richtlinie/Risiko/Control-Bewertung/Modul tragen Review-Status (F2); Reviewer-Zuweisung inkl. `external_validator`; Kommentare; Auswertung zählt nur `validiert`.
+- **Technik:** Ausbau `src/server/actions/tasks.ts` + `submitForApproval`; generische Review-Komponente.
+- **Fachcontent:** C9 §1 (bestätigt/unbestätigt). **Abh.:** F1, F2.
+
+### A4 — ISMS-Rollen & Funktionstrennung (`dev/a4-isms-rollen`)
+**A4-1 Rollenmodell + Platzhalter (M).**
+- **AK:** Rollen `ROLE_MANAGEMENT/ISB/IT_LEAD/HR_LEAD/DPO` erfassbar (aus C2 Abschnitt B), befüllen Vorlagen-Platzhalter; ISB-Bestellung aus Vorlage generierbar.
+- **Technik:** Rollen-Modell; Anbindung zentrale Variablen (`src/lib/policy-variables.ts`).
+**A4-2 Funktionstrennungs-Prüfung FT-01…06 (M).**
+- **AK:** Regeln **FT-01…FT-06** aus C7 implementiert; Konflikt/Lücke → Hinweis + Aufgabe (F1); Option „Trennung herstellen" **oder** „kompensierende Kontrolle dokumentieren".
+- **Fachcontent:** **C7** (Rollen, FT-Regeln, `VA-00_ISB-Bestellung.md`, Flags `FLAG_ISB_EXTERNAL/INTERNAL`). **Abh.:** F4, A3.
+
+### A5 — Asset-Anbindung Wizard (`dev/a5-assets-step`)
+**A5-1 Asset-Schritt auf Bestandsmodul (S).**
+- **AK:** Schritt 5 nutzt vorhandenes Assets/BIA (C/I/A, Schutzbedarf, Eigentümer); Trigger „unvollständig/kein Eigentümer" → Aufgabe (F1). Keine Doppel-Datenhaltung.
+
+### A6 — Risiko-Katalog & Anbindung (`dev/a6-risiko-katalog`)
+**A6-1 Risiko-Katalog-Datenmodell + Import (M).**
+- **AK:** 39 Katalog-Risiken (11 Kategorien) importiert mit ID `R-<KAT>-<nr>`, Controls, Asset-Typen, Standardmaßnahmen, Default `E/S`; erweiterbar; „nicht anwendbar"-Begründung möglich.
+- **Technik:** Risiko-Katalog-Seed + Auswahl-UI im vorhandenen Risikomodul; 5×5 wie C4.
+**A6-2 Maßnahme → Aufgabe + Restrisiko (M).**
+- **AK:** ausgewähltes Risiko → Bewertung (5×5) → Behandlung → Standardmaßnahme erzeugt Aufgabe (F1), verknüpft Risiko+Control; Restrisiko > Akzeptanz erfordert dokumentierte Akzeptanz (VA-09).
+- **Fachcontent:** **C4** (Katalog + Bewertungslogik + Standardmaßnahmen). **Abh.:** F1, B2.
+
+### A7 — Control-Assessment & Reifegrad/Gap (`dev/a7-control-assessment`, SoA)
+**A7-1 Control-/SoA-Oberfläche (L).**
+- **AK:** je relevantem Control: Belege verknüpfen (Dok/Risiko/Asset), Teilanforderungen sichtbar (aus C1/`mapping.json`), offene Teilanforderungen markiert; Inline-Umsetzungshinweise (B5/C6).
+**A7-2 Reifegrad-Engine R0–R3 + Pflichtbestätigung (L).**
+- **AK:** Reifegrad-Vorschlag exakt nach **C5**-Regeln (R0/R1a-c/R2/R3, Sonderfälle, Aktualitätsregel ≤12 Mon., Deckelung bei Widerspruch); Vorschlag ist **an Belege gekoppelt und nachvollziehbar**; Bearbeiter-Bestätigung Pflicht; Zielreifegrad nach C5 §3 (AL2→2, AL3→3, HOCH/SEHR HOCH→3).
+- **AK:** Reifegrad < Ziel / offene Teilanforderung → Aufgabe (F1).
+- **Technik:** `src/app/(app)/soa/**` (bislang Platzhalter) + `src/server/actions/soa.ts`; Reifegrad-Berechnung `src/lib/maturity.ts` (unit-getestet gegen C5-Beispiele).
+- **Fachcontent:** **C5** (Reifegradlogik), **C6** (Umsetzungshinweise). **Abh.:** A2, B1, B2, B5.
+
+### A8 — Gap-Konsolidierung (`dev/a8-gap-konsolidierung`)
+**A8-1 Aggregation + Dedup + Priorisierung (M).**
+- **AK:** offene Punkte aus Schritt 6/7 zusammengeführt; **Dedup-Schlüssel** (Control+Teilanforderung / verknüpfte Aufgabe) nach C8 §2; Priorität **Hoch/Mittel/Niedrig** nach C8 §1 mit Zusatzsortierung (betroffene Controls, Risikohöhe, Aufwand); keine Dopplungen; jeder Punkt hat Priorität + ggf. Aufgabe.
+**A8-2 Quick-Win-Kennzeichnung (S).**
+- **AK:** Quick-Win-Kriterien aus C8 §3; im Maßnahmenplan hervorgehoben („erst Quick-Wins").
+- **Fachcontent:** **C8**. **Abh.:** A6, A7, B1.
+
+---
+
+## Lane B — Dev B
+
+### B1 — Aufgaben-Modul erweitern (`dev/b1-tasks-erweiterung`)
+**B1-1 Auto-Generierung mit Bestätigung (M).**
+- **AK:** Trigger aus Schritt 3/4/6/7/8 + Zurückweisung erzeugen **Aufgabenvorschlag** (Typ/Verknüpfung/Ressourcen aus F1); Bearbeiter bestätigt/verwirft; Anzeige/Filter im Modul „Aufgaben" (`src/app/(app)/tasks/`).
+- **Fachcontent:** C2 §8 (konkrete Trigger). **Abh.:** F1.
+
+### B2 — Regel-/Mapping-Engine (`dev/b2-regel-engine`)
+**B2-1 Engine-Kern + Klausel-Flags (L).**
+- **AK:** DSL (F3) ausgewertet: Antwort/Scope/Flag → Klausel ein/aus (Handlebars-Flags), Control-Relevanz, Risiko-/Asset-Bezug, Aufgabe; deterministisch, unit-getestet gegen **C2** Q-FEAT-01…10.
+- **Technik:** `src/lib/rules/**`; koppelt an vorhandene `{{#if FLAG}}`-Renderer + Lieferanten-Anforderungs-Engine.
+**B2-2 Propagation bei Antwortänderung (M).**
+- **AK:** Änderung einer Antwort propagiert sichtbar in abhängige Objekte/Platzhalter/Controls.
+- **Fachcontent:** **C2** (Wirkungsmatrix), C1 (Scope-Bedingungen). **Abh.:** F3, F4.
+
+### B3 — Fragebogen/Fakten (`dev/b3-fragebogen`)
+**B3-1 Dynamischer, bedingter Fragebogen (M).**
+- **AK:** Abschnitte A–F aus C2 mit Antworttypen + Anzeige-Bedingungen; Antworten als wiederverwendbare Faktenobjekte; Baseline-Fragen (E) als vorbelegte Defaults aus `Technische-Sicherheits-Baseline.md` (nur bestätigen).
+- **AK:** zentrale Variablen bleiben serverseitig gesperrt (nur `/settings`), Fragebogen respektiert das.
+- **Technik:** `src/app/(app)/onboarding/steps/context/**` (im A1-Registry); Faktenmodell + Migration.
+- **Fachcontent:** **C2** (Fragen A–F, Baseline-Defaults). **Abh.:** A1, B2, F4.
+
+### B4 — Richtlinien: Import-bei-Aktivierung + manueller Upload + Control-Mapping (`dev/b4-richtlinien-import-upload`)
+**B4-1 Vorlagen-Import bei Modul-Aktivierung (M).** *(Explizite Anforderung.)*
+- **AK:** Aktiviert der Superadmin das Richtlinien-Modul, wird das Paket mandantenweit **nicht-destruktiv** importiert (bestehende Logik `prisma/import-policies.ts` als Server-Action/Job gekapselt); Button „Vorlagen importieren/aktualisieren" in Admin und `/policies`; idempotent, Änderungsreport.
+**B4-2 Manueller Upload eigener Richtlinien im Menü (M).** *(Explizite Anforderung; Storage später.)*
+- **AK:** unter `/policies` „Eigene Richtlinie hochladen" mit **Pflicht-Control-Zuordnung** (Multi-Select Control-Katalog, optional Anforderungs-IDs, siehe C3 §4); Metadaten/Block-Modell angelegt; Datei-Persistenz über gestubbtes **Storage-Adapter-Interface** (echtes Backend = Folge-Epic S1); Zuordnung fließt als `<!-- REQ -->`-Äquivalent in die Nachweislage (Schritt 7).
+**B4-3 Proto/DS-Vorlagen P01/D01 + mapping.json (M).**
+- **AK:** neue Vorlagen `P01_Prototypenschutz.md` (+ `VA-20`) und `D01_Datenschutz.md` nach C3-Konvention angelegt; `mapping.json`-Einträge im gleichen Schema (8.x/9.x); `FLAG_PROTOTYPE_PROTECTION` genutzt; `_verify.py` (um neue Anker erweitert) → **OK**.
+- **Fachcontent:** **C3** (Annotationskonvention + P01/D01), C1/C6 (Dekomposition 8.x/9.x). **Abh.:** F4.
+
+### B5 — Umsetzungshinweise (`dev/b5-umsetzungshinweise`)
+**B5-1 Hinweis-Datenmodell + Import (S Code).**
+- **AK:** Hinweis-Objekt je Teilanforderung mit Feldern **organisatorisch/technisch/Nachweise/Vorlage/Ressourcen/AL-Filter**; Import der ~397 C6-Blöcke; Baseline-Referenzen (`BL-*`) statt harter Werte.
+**B5-2 Kontextsensitives Inline-Panel (S).**
+- **AK:** Panel an Teilanforderung/Risiko/Template; gefiltert nach Scope/Antworten (B2) und AL; Ressourcen-Hinweis mit Beschaffungsbedarf → Aufgabe (F1).
+- **Fachcontent:** **C6** (Hinweise), C0 offener Punkt 3 (Baseline-Codes vor Verdrahtung gegen `Technische-Sicherheits-Baseline.md` normalisieren). **Abh.:** A1.
+
+### B6 — Versionierung/Propagation (`dev/b6-versionierung`)
+**B6-1 Versionierung Katalog/Templates/Risiko + Instanz-Referenz (M).**
+- **AK:** Kundeninstanz referenziert genutzte Template-/Katalog-Version; Änderungen erzeugen Diff.
+**B6-2 Gesteuerte Übernahme (Diff) (M).**
+- **AK:** bei Update erhält die Instanz einen Diff mit kontrollierter Übernahme; nichts wird still überschrieben (ergänzt nicht-destruktiven Re-Import + löst offenen Richtlinien-Diff). **Abh.:** B4.
+
+### B7 — Assessment-Readiness & Export (`dev/b7-readiness-export`)
+**B7-1 Reifegrad-Dashboard + Interpretationstexte (M).**
+- **AK:** Aggregation je Kapitel/gesamt (Ø, „unbestätigt zählt nicht"); Textbänder nach C9 §1; Kennzahlen (Anteil bestätigt, offene Punkte je Priorität, Abdeckung je Prüfziel); dynamische „nächste Schritte" (C9 §2).
+**B7-2 VDA-ISA-Katalog-Export (L).**
+- **AK:** Export-Layout exakt nach **C9 §3** (Felder Control-ID/Frage/Reifegrad/Status/Umsetzungsbeschreibung MUSS→SOLL→HOCH→SEHR HOCH/Belege/offene Punkte); Reihenfolge IS→Proto→DS; „unbestätigt" markiert; **XLSX** (Katalog+Kennzahlen) + DOCX/PDF-Management-Summary (koppelt an bestehenden Export); Zusatzartefakte (Maßnahmenplan, Nachweisregister) nach C9 §4.
+- **Fachcontent:** **C9**. **Abh.:** A7, A8.
+
+---
+
+## Content-Integration & offene Fachpunkte (aus C0)
+
+| ID | Story | Owner | Abh. |
+|---|---|---|---|
+| **X1** | Neue `FLAG_*`/Variablen in `variables.schema.json` (siehe F4) | B (mit SME) | vor B2/B3/B4/A4 |
+| **X2** | P01/D01 + `VA-20` Vorlagen + `mapping.json`-Einträge (B4-3) | B (mit SME) | C3 |
+| **X3** | Baseline-`BL-*`-Codes aus C6 gegen `Technische-Sicherheits-Baseline.md` normalisieren | B5 (mit SME) | vor B5-Verdrahtung |
+| **X4** | ISB-Freigabe aller neuen/angepassten Fachtexte (VA/Richtlinien/P01/D01) | ISB (fachlich, kein Code) | vor Produktivsetzung |
+
+---
+
+## Sprint-Vorschlag (2 Lanes)
+
+- **Sprint 0:** F1–F4 (gemeinsam) → mergen.
+- **Sprint 1:** A1 · B1 + B2-1.
+- **Sprint 2:** A2 (+C1) · B4 (+C3) + B3 (+C2).
+- **Sprint 3:** A3 · A4 (+C7) · B5 (+C6).
+- **Sprint 4:** A5 · A6 (+C4) · B6.
+- **Sprint 5:** A7 (+C5/C6).
+- **Sprint 6:** A8 (+C8) · B7 (+C9).
+
+> „Definition of Ready" je Story: zugehöriges C-Paket eingespielt und (wo Seed) `_verify.py` → **OK**. Fehlt der Fachcontent, bleibt die Story blockiert (kritischer Pfad: C2 → C1/C3 → C5/C6).