craftvia/docs/wizard-uebergabe/00_Entwicklerpakete/Paket-DevB-Engines-Richtlinien.md

Umsetzungspaket Dev B — Aufgaben, Regel-Engine, Fragebogen & Richtlinien-Import/Upload

Claude-Code-Prompt für Entwickler B. Parallel zu Paket Dev A. Basis-Branch dev. Fachcontent: C2_Fragenkatalog-Wirkung.md, C3_Vorlagen-Annotation.md, C0_README (offene Punkte). Repo-Doku: docs/HANDOVER-DEV.md, STAND-dev-branch.md.

Auftrag (Kurz)

Baue die Regel-Engine, den Fragebogen, die Aufgaben-Erzeugung und die Richtlinien: Import bei Modul-Aktivierung + manueller Upload. Du lieferst die Inhalte/Engines, die sich in die Wizard-Shell von Dev A einklinken.

Branches (unter dev abzweigen, PR-Ziel dev)

• dev/b1-tasks-erweiterung
• dev/b2-regel-engine
• dev/b3-fragebogen
• dev/b4-richtlinien-import-upload Häufig auf dev rebasen. Kleine PRs je Story.

Datei-Hoheit (nur DU fasst diese an)

src/server/actions/tasks.ts (Task-Modell/Logik) · src/lib/rules/** · seed/isms-vorlagenpaket-v2/variables.schema.json · Fragebogen unter src/app/(app)/onboarding/steps/context/** und .../policies/** (in Dev-A-Registry eingeklinkt) · prisma/import-policies.ts · src/app/(app)/policies/** (Upload/Import-Einstieg) · seed/isms-vorlagenpaket-v2/ (P01/D01/VA-20). Koordiniert (mit Dev A abstimmen): prisma/schema.prisma (Migrations-Reihenfolge), scripts/check-module-guards.ts, Step-Registry-Schnittstelle (§5).

---

Story F1 — Aufgaben-Objekt-Schema erweitern (dev/b1-tasks-erweiterung)

• Erweitere das bestehende Task/TaskComment (heute Typ policy_approval) um die Felder aus Contracts §1 (type, owner, dueDate, priority, status, resources JSON, origin, polymorphe links). Bestehender Freigabe-Flow bleibt lauffähig.
• Migration tasks_wizard_fields; TENANT_MODELS+RLS bleiben.
• AK: neue Felder vorhanden/typisiert; policy_approval-Flow unverändert grün.

Story B1 — Auto-Generierung mit Bestätigung (dev/b1-tasks-erweiterung)

• Aus Triggern (Schritt 3/4/6/7/8 + Zurückweisung) Aufgabenvorschlag erzeugen (Vorschlag → Bearbeiter bestätigt/verwirft). Trigger-Set exakt aus C2 §8 (z. B. „ISB nicht benannt" → organizational/Control 1.2.2; „externe IT-Dienstleister = ja" → evidence_provide/Control 6.1.1; „kein Restore-Test" → technical/BL-OPS-06/Control 5.2.9).
• Anzeige/Filter im Modul „Aufgaben" (src/app/(app)/tasks/), Ressourcenfelder editierbar.
• AK: Trigger erzeugt korrekt verknüpften Vorschlag; Bestätigung übernimmt; Verwerfen dokumentiert.

---

Story F4 — Variablen/Flags erweitern (dev/b2-regel-engine)

• In seed/isms-vorlagenpaket-v2/variables.schema.json ergänzen: FLAG_PROTOTYPE_PROTECTION, FLAG_ISB_EXTERNAL, FLAG_ISB_INTERNAL + fehlende ROLE_*/TECH_* aus C2. Namen = Contracts §3 (fix, da Dev A darauf entwickelt).
• AK: python3 seed/isms-vorlagenpaket-v2/_verify.py → OK.

Story F3 + B2 — Regel-/Mapping-Engine (dev/b2-regel-engine)

• DSL (Contracts §7) als Typen in src/lib/rules/dsl.ts; Engine in src/lib/rules/engine.ts: Bedingung(Antwort|Scope|Flag) → Wirkung(Klausel ein/aus · Control relevant · Risiko/Asset-Bezug · Aufgabe).
• Koppelt an vorhandene {{#if FLAG}}-Render-Flags und die Lieferanten-Anforderungs-Engine (Muster).
• Regeldaten aus C2 §5 (Q-FEAT-01…10) als Regelobjekte hinterlegen (z. B. FLAG_CLOUD_USED → R12-Klauseln + Controls 5.3.2/5.3.4/6.1.3 + Risiken R-CLOUD-*).
• AK / Tests: Unit-Tests, die für jede Q-FEAT-Antwort die erwarteten Wirkungen prüfen; Antwortänderung propagiert deterministisch.

Story B3 — Fragebogen/Fakten (Schritt 2) (dev/b3-fragebogen)

• Dynamischer, bedingter Fragebogen mit Abschnitten A–F aus C2 (Antworttypen + Anzeige-Bedingungen); Antworten als wiederverwendbare Faktenobjekte (Migration wizard_facts, RLS).
• Abschnitt E (Baseline) als vorbelegte Defaults aus Technische-Sicherheits-Baseline.md — nur bestätigen/anpassen, keine Ersteingabe.
• Zentrale Variablen bleiben serverseitig gesperrt (nur /settings, siehe src/lib/policy-variables.ts) — Fragebogen schreibt Fakten/Flags, nicht die gesperrten Variablen.
• Einklinken über Dev-A-Step-Registry (§5), Schritt-Key context.
• AK: Fragen A–F vorhanden; bedingte Sichtbarkeit über Flags; Antwort propagiert in abhängige Objekte (via B2); Baseline-Defaults vorbelegt.

---

Story B4 — Richtlinien: Import bei Aktivierung + manueller Upload (dev/b4-richtlinien-import-upload)

B4-1 Vorlagen-Import bei Modul-Aktivierung (M) — explizite Anforderung

• Aktiviert der Superadmin das Richtlinien-Modul für einen Mandanten, wird das Vorlagenpaket mandantenweit nicht-destruktiv importiert: kapsle die bestehende Logik prisma/import-policies.ts (Diff/Upsert/archivedAt, {dryRun}) als serverseitig aufrufbare Action/Job. Zusätzlich Button „Vorlagen importieren/aktualisieren" in Admin und unter /policies.
• AK: Modul-Aktivierung triggert Import; idempotent; Status/Freigabe/Overrides/Variablenwerte bleiben erhalten; Änderungsreport sichtbar.

B4-2 Manueller Upload eigener Richtlinien im Menü (M) — explizite Anforderung; Storage später

• Unter /policies Einstieg „Eigene Richtlinie hochladen" mit Pflicht-Control-Zuordnung (Multi-Select aus Control-Katalog, optional Anforderungs-IDs) gemäß C3 §4.
• Datei-Persistenz über ein gestubbtes Storage-Adapter-Interface src/server/storage/adapter.ts (echtes Backend = Folge-Epic S1). Upload legt Metadaten + Block-Modell + Control-Mapping an; die Zuordnung fließt wie ein <!-- REQ -->-Anker in die Nachweislage (Schritt 7).
• AK: „Eigene Richtlinie hochladen" vorhanden mit Control-Zuordnung; Storage-Adapter gekapselt (später ohne UI-Änderung verdrahtbar); hochgeladenes Dokument erscheint in der Coverage/Nachweislage.

B4-3 Proto/DS-Vorlagen P01/D01 + VA-20 + mapping.json (M)

• Neue Vorlagen P01_Prototypenschutz.md (+ Verfahren VA-20_Prototypen-Zutritt-und-Transport) und D01_Datenschutz.md nach C3 §2-Konvention anlegen; mapping.json-Einträge im gleichen Schema für 8.x/9.x (IDs aus C1/C6-Dekomposition); Prototyp-Klauseln in {{#if FLAG_PROTOTYPE_PROTECTION}}.
• _verify.py um die neuen Verzeichnisse/Anker erweitern.
• AK: python3 _verify.py → OK; neue Anforderungen erscheinen im Scope, wenn Prüfziel Prototyp/Datenschutz aktiv (Dev-A-Filter).

Fachcontent: C3 (Annotationskonvention + P01/D01), C2 (Flag-Wirkung), C0 (offene Punkte 1–3).

---

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) · bei Seed-Änderung _verify.py → OK · Browser-Verifikation.

Reihenfolge

F1 → B1 → F4 → (F3+B2) → B3 → B4-1 → B4-2 → B4-3. Danach (Folge-Paket): A6-Risikokatalog-Anbindung (C4), B5 Umsetzungshinweise (C6), B6 Versionierung, B7 Export (C9).

---

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

§1 Task-Objekt (du besitzt das Modell): 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?} }. Dev A/Wizard-Gates rufen deine createTask-Action zum Erzeugen von Aufgaben.

§2 Validierungsstatus (Dev A besitzt das Enum, du konsumierst): enum ObjectReviewStatus { offen, in_bearbeitung, zur_validierung, validiert, zurueckgewiesen } + reviewComment, reviewerId. Rolle external_validator.

§3 Flags (du pflegst 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 (Dev A definiert, du konsumierst): registerStep({ key, title, order, guard, component }); du lieferst Komponenten für context (Schritt 2) und policies (Schritt 4).

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

---

Gemeinsamer Kickoff (15 Min., beide Entwickler, vor Story-Start)

Contracts §1–§6 gemeinsam bestätigen (Feldnamen, Enum-Werte, Flag-Namen, Registry-Signatur, Migrations-Reihenfolge). Danach arbeiten beide Pakete konfliktarm parallel; einzige echte Nahtstellen sind schema.prisma, check-module-guards.ts und die Step-Registry — alle drei sind im Contracts-Anhang fixiert.