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

# 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).