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>
This commit is contained in:
Claude Opus 5
@@ -0,0 +1,168 @@
|
||||
# Contracts-Checkliste — Kickoff Dev A × Dev B (15 Min.)
|
||||
|
||||
> Zweck: Die Naht zwischen **Paket Dev A** (Wizard-Shell/Scoping/AL) und **Paket Dev B**
|
||||
> (Engines/Fragebogen/Richtlinien) **einmal gemeinsam bestätigen**, bevor beide parallel starten.
|
||||
> Grundlage: der identische *Contracts-Anhang* §1–§6 in beiden Entwicklerpaketen.
|
||||
> Vorgehen: Punkt für Punkt durchgehen, abhaken, offene Entscheidungen unten eintragen, beide signieren.
|
||||
> Danach laufen A und B konfliktarm parallel — einzige echte Nahtstellen sind
|
||||
> `prisma/schema.prisma`, `scripts/check-module-guards.ts` und die Step-Registry.
|
||||
|
||||
**Basis-Branch:** `dev` · **Feature-Branches:** `dev/a*-…` (A) bzw. `dev/b*-…` (B) · **PR-Ziel:** `dev`
|
||||
Kein Push durch die Agenten; häufig auf `dev` rebasen; kleine PRs je Story.
|
||||
|
||||
---
|
||||
|
||||
## §1 Task-Objekt — **Owner: Dev B** (A konsumiert)
|
||||
|
||||
Dev B besitzt das Modell + `createTask`-Action; Dev A / Wizard-Gates rufen sie auf.
|
||||
|
||||
- [ ] `type`: `document_create | evidence_provide | technical | organizational | validation | policy_approval`
|
||||
- [ ] Felder: `owner`, `dueDate`, `priority: 'hoch'|'mittel'|'niedrig'`, `status`
|
||||
- [ ] `resources` (JSON): `{ tool, budget, personnel, time }`
|
||||
- [ ] `origin` (Herkunft/Trigger) vorhanden
|
||||
- [ ] `links` (polymorph): `{ control?, risk?, document?, asset? }`
|
||||
- [ ] Bestehender `policy_approval`-Flow bleibt unverändert lauffähig (Regression grün)
|
||||
- [ ] **Signatur der `createTask`-Action steht fix**, bevor A ihre Gates verdrahtet
|
||||
→ Signatur hier notieren: `_____________________________________________`
|
||||
|
||||
## §2 Validierungsstatus — **Owner: Dev A** (B konsumiert)
|
||||
|
||||
- [ ] `enum ObjectReviewStatus { offen, in_bearbeitung, zur_validierung, validiert, zurueckgewiesen }`
|
||||
- [ ] Zusatzfelder: `reviewComment`, `reviewerId`
|
||||
- [ ] Regel bestätigt: **„Nur `validiert` zählt als bestätigt."**
|
||||
- [ ] RBAC-Recht `validate_objects` + Rolle `external_validator` (klonbar) angelegt
|
||||
- [ ] Feld-Konvention (an welchen Objekten der Status hängt) für Wizard-Gates fix
|
||||
|
||||
## §3 Flags in `variables.schema.json` — **Owner: Dev B** (Namen fix, A entwickelt dagegen)
|
||||
|
||||
- [ ] Namen unverändert übernommen (keine Umbenennung ohne beidseitige Abstimmung):
|
||||
`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`
|
||||
- [ ] `FLAG_ELEVATED_PROTECTION` bleibt **abgeleitet** (`applyProtection`) — nie manuell setzen
|
||||
- [ ] Nach Schema-Änderung: `python3 seed/isms-vorlagenpaket-v2/_verify.py` → **OK**
|
||||
|
||||
## §4 Prüfziele — beidseitig fix
|
||||
|
||||
- [ ] Werte: `informationssicherheit | prototypenschutz | datenschutz`
|
||||
- [ ] Wirkung bestätigt: Kapitel `8.x` nur bei Prototyp, `9.x` nur bei Datenschutz
|
||||
|
||||
## §5 Step-Registry — **Owner: Dev A** (B konsumiert)
|
||||
|
||||
- [ ] Signatur fix: `registerStep({ key, title, order, guard, component })`
|
||||
- [ ] Schritt-Keys/Reihenfolge:
|
||||
`1 scoping · 2 context · 3 roles · 4 policies · 5 assets · 6 risks · 7 controls · 8 gap · 9 readiness`
|
||||
- [ ] Klar: **B liefert die Komponenten für `context` (Schritt 2) und `policies` (Schritt 4)**;
|
||||
A stellt die Registry-Schnittstelle stabil bereit, bevor B einklinkt
|
||||
|
||||
## §6 Migrations-Protokoll — beidseitig verbindlich
|
||||
|
||||
- [ ] Vor jedem Migrations-Erzeugen zuerst auf `dev` rebasen
|
||||
- [ ] **Migrationen nie gleichzeitig ohne Absprache** erstellen
|
||||
- [ ] Je Branch **genau eine Migration pro Story**
|
||||
- [ ] Prisma-7-Flow: `migrate diff --from-config-datasource … --to-schema … --script`
|
||||
→ RLS-DO-Block manuell anhängen → `migrate deploy` → `generate`
|
||||
- [ ] Neue tenant-gebundene Modelle → `TENANT_MODELS` (`src/server/db.ts`) **und** RLS-Policy
|
||||
- [ ] Neue Server-Action-Datei → in `scripts/check-module-guards.ts` eintragen (sonst Build-Fail)
|
||||
|
||||
---
|
||||
|
||||
## Erwartete Migrations-Reihenfolge (gemeinsam festlegen)
|
||||
|
||||
Beide erzeugen Migrationen an `schema.prisma` — Reihenfolge vorab abstimmen, um Konflikte zu vermeiden.
|
||||
Vorschlag (an tatsächlicher Story-Reihenfolge ausrichten):
|
||||
|
||||
| # | Story | Owner | Migration (Arbeitsname) |
|
||||
|---|-------|-------|-------------------------|
|
||||
| 1 | A1-1 | A | `onboarding_progress` |
|
||||
| 2 | F1 | B | `tasks_wizard_fields` |
|
||||
| 3 | F2 | A | (Enum `ObjectReviewStatus` + `external_validator`) |
|
||||
| 4 | A2-2 | A | `wizard_scope` |
|
||||
| 5 | B3 | B | `wizard_facts` |
|
||||
|
||||
- [x] Reihenfolge oben bestätigt / angepasst — A1-1(A) → F1(B) → F2(A) → A2-2(A) → B3(B)
|
||||
- [x] Wer erzeugt die **erste** Migration? → **Dev A** (`onboarding_progress`, A1-1) — von Dev B bestätigt; B rebast danach zuerst
|
||||
|
||||
## Offene Fachpunkte (aus C0 — vor bzw. begleitend zu klären)
|
||||
|
||||
- [ ] Neue `FLAG_*` in `variables.schema.json` ergänzt (F4, Dev B)
|
||||
- [ ] Vorlagen `P01`/`D01` + `VA-20` angelegt (B4-3, Dev B)
|
||||
- [ ] Baseline `BL-*` normalisiert
|
||||
- [ ] ISB-Freigabe der neuen/geänderten Texte (fachlich, kein Code)
|
||||
|
||||
---
|
||||
|
||||
## Sign-off
|
||||
|
||||
- Dev A bestätigt §1–§6 + Migrations-Reihenfolge: **Claude (Dev A)** (Datum: 2026-07-28)
|
||||
- Dev B bestätigt §1–§6 + Migrations-Reihenfolge: **Claude (Dev B)** (Datum: 2026-07-28)
|
||||
|
||||
> Änderungen an §1–§6 nach dem Kickoff nur **gemeinsam** und mit Update dieser Datei
|
||||
> **und** von `docs/STAND-dev-branch.md`.
|
||||
|
||||
---
|
||||
|
||||
## Dev A — Kickoff-Vorbereitung (Positionen & Vorschläge, warten auf B-Bestätigung)
|
||||
|
||||
> Nicht-bindend bis zum gemeinsamen Sign-off. „A-Vorschlag" = braucht B's Ja; „A bestätigt" =
|
||||
> liegt in A's Hoheit und ist von A's Seite geklärt.
|
||||
|
||||
**§1 Task-Objekt (Owner B):** A bestätigt die Feldliteralwerte (`type`-Werte, `priority`, `resources`,
|
||||
`origin`, `links`) wie im Anhang. **A braucht von B eine fixe `createTask`-Signatur, bevor A Gates/Trigger
|
||||
verdrahtet.** A-Vorschlag als Startpunkt:
|
||||
`createTask(input: { type, title, origin, owner?, dueDate?, priority?, resources?, links? }): Promise<Task>`
|
||||
(Server-Action in B's Hoheit; A ruft nur auf). → **B bestätigt/ändert Signatur:** ✅ **bestätigt (unverändert)** —
|
||||
`createTask(input: { type, title, origin, owner?, dueDate?, priority?, resources?, links? }): Promise<Task>`.
|
||||
Mapping/Defaults (B-Hoheit, F1): `owner` → DB-Spalte `assigneeId` (eine verantwortliche Person; optional, da B1-Vorschläge unassigned starten);
|
||||
`priority` default `'mittel'`; `resources = { tool?, budget?, personnel?, time? }` (alle optional); `links = { control?, risk?, document?, asset? }` (IDs/Refs).
|
||||
`status` setzt die Action **serverseitig** (Default `OPEN`; auto-generierte B1-Vorschläge starten im Vorschlags-Status zur Bestätigung) — **kein** Input-Feld.
|
||||
Bestehende `entityType/entityId/entityRef` bleiben für den `policy_approval`-Flow erhalten (F1 fügt nur Felder hinzu); `links.document` bildet den Dokumentbezug ab.
|
||||
|
||||
**§2 Validierungsstatus (Owner A) — A bestätigt:**
|
||||
- `enum ObjectReviewStatus { offen, in_bearbeitung, zur_validierung, validiert, zurueckgewiesen }` + `reviewComment`, `reviewerId`.
|
||||
- Regel „Nur `validiert` zählt als bestätigt" gilt für alle Wizard-Gates.
|
||||
- RBAC-Recht `validate_objects` + klonbare Rolle `external_validator`.
|
||||
- **Feld-Konvention (Gate-Quelle):** In A1-1 trägt der Schritt-Datensatz `OnboardingProgress` den Review-Status;
|
||||
das „Weiter"-Gate liest den Status des Vorgänger-Schritts. Sobald Domänenobjekte je Schritt existieren
|
||||
(spätere Stories), wandert die Statusquelle auf das jeweilige Primärobjekt (Generalisierung = A3).
|
||||
→ **B nimmt das für seine Schritte (2 context, 4 policies) so an:** ✅ **ja** — B liest für `context` (2) und `policies` (4)
|
||||
den Review-Status des Vorgänger-Schritts aus `OnboardingProgress` (Quelle A1-1); „nur `validiert` zählt". B schreibt in diesen Schritten
|
||||
nur Fakten/Flags bzw. Richtlinien-Objekte, **nicht** den Gate-Status selbst. Hinweis: Schritt 4 nutzt weiterhin den bestehenden
|
||||
`policy_approval`-Workflow für die inhaltliche Freigabe; das Wizard-„Weiter"-Gate hängt aber am `OnboardingProgress`-Status, nicht am Task.
|
||||
|
||||
**§3 Flags (Owner B):** A übernimmt die Namen aus §3 **unverändert**, benennt nichts um, behandelt
|
||||
`FLAG_ELEVATED_PROTECTION` als abgeleitet (nie manuell). A entwickelt `scope-filter.ts` gegen diese Namen,
|
||||
**bevor** F4 landet. → **B bestätigt Namensliste final:** ✅ **final** — die 17 Namen bleiben unverändert. Ist-Stand geprüft:
|
||||
**14 bereits** in `variables.schema.json` vorhanden; F4 ergänzt **genau die 3 fehlenden** `FLAG_PROTOTYPE_PROTECTION`, `FLAG_ISB_EXTERNAL`,
|
||||
`FLAG_ISB_INTERNAL` (+ fehlende `ROLE_*/TECH_*` aus C2, **ohne** FLAG-Namen anzufassen). `FLAG_ELEVATED_PROTECTION` bleibt abgeleitet. Nach F4: `_verify.py` → OK.
|
||||
|
||||
**§4 Prüfziele:** A bestätigt `informationssicherheit | prototypenschutz | datenschutz`; Kap. `8.x` nur bei
|
||||
Prototyp, `9.x` nur bei Datenschutz (C1-Methodik).
|
||||
|
||||
**§5 Step-Registry (Owner A) — A bestätigt & stellt bereit:**
|
||||
- Signatur `registerStep({ key, title, order, guard, component })`, Keys/Reihenfolge
|
||||
`1 scoping · 2 context · 3 roles · 4 policies · 5 assets · 6 risks · 7 controls · 8 gap · 9 readiness`.
|
||||
- A liefert die stabile Registry-Schnittstelle in A1-1, **bevor** B `context` (2) und `policies` (4) einklinkt.
|
||||
→ **B bestätigt Schnittstelle als ausreichend:** ✅ **ausreichend** — `registerStep({ key, title, order, guard, component })` + Keys 1–9
|
||||
genügen, um `context` (2) und `policies` (4) einzuklinken. Einzige Bitte an A: `guard` muss das **Ausblenden** eines Schrittes erlauben
|
||||
(z. B. `policies` nur bei aktivem Richtlinien-Modul) und die `component`-Client/Server-Boundary sauber halten. Keine weiteren Felder von B benötigt.
|
||||
|
||||
**§6 Migrations-Reihenfolge — A-Vorschlag:**
|
||||
|
||||
| # | Story | Owner | Migration | Anmerkung |
|
||||
|---|-------|-------|-----------|-----------|
|
||||
| 1 | A1-1 | A | `onboarding_progress` | **A erzeugt die erste Migration** |
|
||||
| 2 | F1 | B | `tasks_wizard_fields` | B rebast danach zuerst auf `dev` |
|
||||
| 3 | F2 | A | `object_review_status` (Enum + `external_validator`) | |
|
||||
| 4 | A2-2 | A | `wizard_scope` | |
|
||||
| 5 | B3 | B | `wizard_facts` | |
|
||||
|
||||
→ **Wer erzeugt die erste Migration? A-Vorschlag: Dev A (A1-1).** B bestätigt: ✅ **ja** — Dev A erzeugt `onboarding_progress` zuerst;
|
||||
B rebast danach zuerst auf `dev` und erzeugt dann `tasks_wizard_fields` (F1).
|
||||
→ Reihenfolge oben bestätigt/angepasst: ✅ **bestätigt (unverändert)** — A1-1(A) → F1(B) → F2(A) → A2-2(A) → B3(B); je Branch genau eine Migration, nie gleichzeitig.
|
||||
|
||||
**Nicht-blockierend für A1-1** (betrifft spätere A-Stories bzw. B/Berater): neue `FLAG_*` in
|
||||
`variables.schema.json` (F4), `seed/scoping/c1-scope.json` erzeugt A aus der C1-Tabelle (445 Zeilen),
|
||||
P01/D01/VA-20 + Baseline-Normalisierung (B4/Berater), ISB-Freigabe (fachlich).
|
||||
@@ -0,0 +1,82 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,100 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user