craftvia/docs/wizard-uebergabe/00_Entwicklerpakete/Paket-DevA-Wizard-Scoping.md

Umsetzungspaket Dev A — Wizard-Fundament, Scoping & AL2/AL3 zentral

Claude-Code-Prompt für Entwickler A. Parallel zu Paket Dev B. Basis-Branch dev. Fachcontent: Fachcontent_Wizard_C1-C9/C1_Scoping-AL-Pruefziel.md. Repo-Doku: docs/HANDOVER-DEV.md, STAND-dev-branch.md.

Auftrag (Kurz)

Baue das Wizard-Grundgerüst, den Scoping-Schritt und verlege den AL2/AL3-Schalter zentral ins Admin-/Superadmin-Portal. Du lieferst die Klammer, in die Dev B seine Schritt-Inhalte einklinkt.

Branches (unter dev abzweigen, PR-Ziel dev)

• dev/a1-wizard-shell
• dev/a2-scoping-admin-al Häufig auf dev rebasen. Kleine PRs je Story.

Datei-Hoheit (nur DU fasst diese an)

src/app/(app)/onboarding/** · src/server/actions/onboarding.ts · src/lib/scope-filter.ts · src/app/(platform)/admin/** (AL-Einstellung) · src/lib/modules.ts (nur Eintrag onboarding) · Scope-/Progress-Modelle in prisma/schema.prisma. Koordiniert (mit Dev B abstimmen, siehe Contracts-Anhang): prisma/schema.prisma (Migrations-Reihenfolge), scripts/check-module-guards.ts (deine neuen Actions eintragen), Validierungsstatus-Enum.

---

Story A1 — Wizard-Shell & Navigation (dev/a1-wizard-shell)

A1-1 Step-Registry & State-Machine (L)

• Neues Modul onboarding in src/lib/modules.ts (Default aktiv für Bestands-Tenants).
• Bereich src/app/(app)/onboarding/** mit einer Step-Registry: Schritte registrieren sich mit { key, title, order, guard, component }. Dev B klinkt „context" (Schritt 2) und „richtlinien" (Schritt 4) ein — definiere die Registry-Schnittstelle stabil (Contracts-Anhang §5).
• State-Machine: offen → in_bearbeitung → zur_validierung → validiert je Schritt; Gate: „Weiter" ist gesperrt, solange das Vorgänger-Objekt nicht validiert ist (nutzt Validierungsstatus, Contracts §2).
• Persistenter Fortschritt je Mandant: Modell OnboardingProgress (tenant-gebunden, TENANT_MODELS+RLS), Migration onboarding_progress.
• Server-Action-Datei src/server/actions/onboarding.ts über moduleGuard("onboarding"); in scripts/check-module-guards.ts eintragen.
• AK: Fortschritt resumierbar; Gate blockiert korrekt; Schritte via Registry einklinkbar; build/Guard-Check grün.

A1-2 Dashboard-Kachel (S)

• Kachel „Onboarding-Fortschritt" in dashboard/page.tsx analog der bestehenden Freigabe-Kachel (Anteil erledigter Schritte, nächster offener Schritt).

---

Story F2 (dein Anteil der Foundation) — Validierungsstatus-Enum (dev/a1-wizard-shell)

• Lege das wiederverwendbare Enum ObjectReviewStatus + Feld-Konvention an (Contracts §2), das Wizard-Gates und später A3 nutzen. RBAC-Recht validate_objects; Rolle external_validator ergänzen.
• AK: Enum + Recht vorhanden; Wizard-Gate liest den Status; Rolle im RBAC klonbar.
• Hinweis: Die vollständige Generalisierung über alle Objekttypen ist Story A3 (späterer Branch) — hier nur Enum + Wizard-Nutzung.

---

Story A2 — Scoping + AL2/AL3 zentral im Adminportal (dev/a2-scoping-admin-al)

A2-1 AL2/AL3 zentral (M) — explizite Anforderung

• Der Assessment-Level (AL2/AL3) wird ausschließlich im Admin-/Superadmin-Portal je Mandant gesetzt → einzige Quelle der Wahrheit. UI in src/app/(platform)/admin/**, Action in src/server/actions/admin.ts/platform.ts.
• Mandanten-/settings und der Scoping-Schritt zeigen AL nur read-only an (kein Änderungsrecht mehr im Tenant).
• AL treibt die bestehenden Flags FLAG_HIGH_PROTECTION/FLAG_VERY_HIGH_PROTECTION und den vorhandenen Coverage-Filter (Coverage zeigt bei AL2 keine „sehr hoch"-Controls — Verhalten beibehalten, Quelle umziehen).
• AK: AL ist nur im Adminportal änderbar; Änderung propagiert in Coverage + Zusatzanforderungen; Tenant kann AL nicht mehr selbst setzen.

A2-2 Scope-Objekt + Filter-Engine (M)

• Scoping (Schritt 1) erfasst: Prüfziele (Informationssicherheit / Prototypenschutz / Datenschutz), Standorte, Geltungsbereich, Ausschlüsse → Modell WizardScope (tenant-gebunden, RLS).
• src/lib/scope-filter.ts: gegeben (AL, gesetzte FLAG_*, aktive Prüfziele) → liefert die aktiven Anforderungen. Datengrundlage: C1-Tabelle (412 Zeilen: Control · Anforderungs-ID · Typ · AL2 · AL3 · Prüfziel · Scope-Bedingung(Flag)), als Seed/JSON seed/scoping/c1-scope.json einlesen (ID = mapping.json-id).
• Filterlogik exakt nach C1-Methodik: MUSS/SOLL = AL2+AL3 (SOLL über FLAG_INCLUDE_SHOULD); HOCH nur bei FLAG_HIGH_PROTECTION; SEHR HOCH nur bei FLAG_VERY_HIGH_PROTECTION; Kapitel 8.x nur bei Prüfziel Prototyp, 9.x nur bei Datenschutz.
• AK / Tests: Unit-Tests gegen repräsentative C1-Zeilen (z. B. 1.2.2-H1 erscheint nur bei FLAG_HIGH_PROTECTION; 1.1.1-S1 nur bei FLAG_INCLUDE_SHOULD; 8.* nur bei Prototyp). Geänderter Scope blendet nachgelagerte Schritte korrekt.

Fachcontent: C1_Scoping-AL-Pruefziel.md. Abhängigkeit: A1 (Shell), Contracts §2 (Status), §3 (Flags-Namen von Dev B/F4 — bis dahin gegen die im Contracts-Anhang fixierten Namen entwickeln).

---

Definition of Done (jede Story)

npx tsc --noEmit → npm run lint → npm run build (Guard-Check) grün · neue Action in check-module-guards.ts · neue tenant-Modelle in TENANT_MODELS+RLS+Migration (RLS-DO-Block) · Browser-Verifikation · Demo-Seed lauffähig.

Reihenfolge

A1-1 → F2 → A1-2 → A2-1 → A2-2. Danach (Folge-Paket): A3 (Validierung generalisieren), A5/A6/A7/A8.

---

Contracts-Anhang (identisch in Paket A und B — an der Naht abstimmen)

§1 Task-Objekt (Dev B besitzt das Modell, du konsumierst es): Task { type: 'document_create'|'evidence_provide'|'technical'|'organizational'|'validation'|'policy_approval', owner, dueDate, priority: 'hoch'|'mittel'|'niedrig', status, resources: {tool,budget,personnel,time}, origin, links: {control?,risk?,document?,asset?} }. Gates/Trigger erzeugen Aufgaben über die Action von Dev B.

§2 Validierungsstatus (du besitzt das Enum): enum ObjectReviewStatus { offen, in_bearbeitung, zur_validierung, validiert, zurueckgewiesen } + reviewComment, reviewerId. Rolle external_validator. „Nur validiert zählt als bestätigt."

§3 Flags (Dev B pflegt variables.schema.json, Namen sind fix): FLAG_INCLUDE_SHOULD, FLAG_HIGH_PROTECTION, FLAG_VERY_HIGH_PROTECTION, FLAG_ELEVATED_PROTECTION, FLAG_PERSONAL_DATA, FLAG_PROTOTYPE_PROTECTION, FLAG_CLOUD_USED, FLAG_AI_USED, FLAG_OT_USED, FLAG_DEV_INHOUSE, FLAG_MOBILE_WORK, FLAG_MOBILE_DEVICES, FLAG_CRYPTO_PKI, FLAG_EXTERNAL_IT, FLAG_CUSTOMER_SYSTEMS, FLAG_ISB_EXTERNAL, FLAG_ISB_INTERNAL.

§4 Prüfziele: informationssicherheit | prototypenschutz | datenschutz.

§5 Step-Registry (du definierst, B konsumiert): registerStep({ key, title, order, guard, component }); Schritt-Keys: 1 scoping · 2 context · 3 roles · 4 policies · 5 assets · 6 risks · 7 controls · 8 gap · 9 readiness.

§6 Migrations-Protokoll: Vor dem Erzeugen einer Migration auf dev rebasen; Migrationen nie gleichzeitig ohne Absprache erstellen; je Branch genau eine Migration pro Story.