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