msolarczekandClaude Opus 5
c8e6f30a27
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>
121 lines
9.1 KiB
Markdown
121 lines
9.1 KiB
Markdown
# Kickoff-Prompt — B1: Assessment und Readiness für zwei Frameworks
|
||
|
||
Du baust die **Bewertungs- und Readiness-Schicht** für ISO 27001 neben TISAX. Alles andere steht bereits: Der Dokumentensatz trägt beide Normen, `mapping-iso.json` liefert 120 ISO-Anforderungen, die Framework-Dimension im Datenmodell ist gebaut (AP1–AP5), ein ISO-Mandant hat SoA, Kennzahlen, Managementbewertung und Korrekturmaßnahmen.
|
||
|
||
**Was fehlt:** `maturity.ts`, `scope-filter.ts`, `assessment-level.ts` und `readiness.ts` kennen kein Framework und rechnen durchgängig VDA ISA — AL2/AL3, Prüfziele, Reifegrad 0–3, MUSS/SOLL. Der belegte Bruch: `src/server/soa-context.ts:151` und `src/server/export-context.ts:49` lesen `controlAssessment`; **keine einzige Stelle liest `soaEntry`**. Das SoA-Modul ist von der Auswertung abgekoppelt.
|
||
|
||
**Pflichtlektüre vor der ersten Zeile Code:** `docs/FEINDESIGN-framework-assessment.md` — vollständig, insbesondere §1 (Leitentscheidung) und §7a (Priorisierung). Hintergrund: `docs/FRAMEWORK-MAPPING-ISO27001.md`, `docs/UEBERGABE-framework-iso27001.md`.
|
||
|
||
## Repo & Branch
|
||
- **origin:** `git.certvia.de/msolarczek/certvia`; zweiter Remote `local-gitea`.
|
||
- **Basis ist `feature/iso27001-framework-mapping`**, nicht `dev`.
|
||
- Arbeite auf `feature/framework-assessment`, PR gegen den Basis-Branch.
|
||
|
||
## Kundenlage — sie bestimmt, was jetzt gebaut wird
|
||
|
||
Die Mehrzahl der Mandanten führt **TISAX**, **ein** Mandant **ISO**, **keiner beide**.
|
||
|
||
Daraus folgt: **Das Regressionsrisiko dominiert dieses Paket.** Der gefährlichste Teil ist nicht die ISO-Logik — die ist schlank — sondern die verhaltensgleiche Extraktion der bestehenden TISAX-Logik. Sie betrifft jeden Bestandsmandanten. Schritt 1 ist deshalb keine Kür.
|
||
|
||
**Zurückgestellt** (betrifft ausschließlich den Doppel-Mandanten, den es heute nicht gibt):
|
||
- Vorbelegung über `ISO_TO_ISA` (Übernahmevorschlag zwischen den Frameworks)
|
||
- Reiter-UI in `/soa` und `/audit-readiness` — bei einem aktiven Framework wird direkt angezeigt
|
||
|
||
**Nicht zurückstellen:** die **Strategie-Schnittstelle** und den **Framework-Parameter** in `buildAssessment`. Beides kostet jetzt fast nichts und ist später teuer, weil sonst sieben Aufrufstellen erneut angefasst werden. Die Architektur bleibt zweigleisig, die Oberfläche zeigt vorerst ein Gleis.
|
||
|
||
## Die eine Leitentscheidung
|
||
|
||
**Die Belegbasis liegt unterhalb der Framework-Strategie.** Ob R08 freigegeben ist, ist eine Tatsache über die Organisation, keine Frage der Norm. `ControlEvidence` (`src/lib/maturity.ts:54`) wird geteilt; nur Scope, Zielwert, Bewertung und Vokabular sind framework-eigen.
|
||
|
||
```
|
||
Schicht 3 Sichten /soa · /audit-readiness · Exporte → je Framework (Reiter später)
|
||
Schicht 2 Strategie Scope · Zielwert · Bewertung → je Framework
|
||
Schicht 1 Belegbasis loadEvidenceResolver → ControlEvidence → GETEILT
|
||
Schicht 0 Fachdaten PolicyDocument · Evidence · Asset … → GETEILT
|
||
```
|
||
|
||
**Review-Kriterium, hart:** `loadEvidenceResolver` darf `FrameworkKey` nicht kennen. Sobald die Belegauflösung anfängt, das Framework zu fragen, ist der Schnitt gerissen und wir bekommen zwei Bewertungen derselben Realität, die auseinanderlaufen.
|
||
|
||
## Nicht anfassen
|
||
|
||
- **`seed/isms-vorlagenpaket-v2/**` und `-en/**`** — generiert. Änderungen nur über `_iso_crosswalk.json` / `_iso_sections.json` / `_iso_texts_en.json` + `python3 _generate_iso.py [--lang en]`.
|
||
- **Die VDA-ISA-Fachlogik inhaltlich** — `suggestMaturity`, `targetMaturity`, `openPoints`, `activeRequirements` werden **verschoben, nicht verändert**.
|
||
- **`readiness.ts` und `gap-consolidation.ts`** — numerisch standard-agnostisch, werden von beiden Strategien gefüttert.
|
||
|
||
## Arbeitsschritte
|
||
|
||
### 1 — Snapshot der heutigen TISAX-Ausgabe *(zuerst, vor jeder Änderung)*
|
||
`buildControlRows` für den Demo-Mandanten festhalten: Reifegradvorschlag, Zielwert, Belegstatus und offene Punkte je Control, als JSON im Repo. Ablage als `scripts/test-framework-assessment.ts` in der Hausform der übrigen `test-*.ts`.
|
||
**DoD:** Test läuft grün gegen den unveränderten Stand und ist als Merge-Gate gesetzt.
|
||
|
||
### 2 — `ControlSpec` einführen
|
||
`C5ControlSpec` (`src/lib/maturity.ts:16`) auf ein neutrales `ControlSpec` reduzieren (`control`, `title`, `policy[]`, `verfahren[]`, `needsAsset`, `needsRisk`); `C5ControlSpec` erweitert es um `target`. `loadEvidenceResolver` (`src/server/soa-context.ts:50`) nimmt künftig `ControlSpec`.
|
||
**DoD:** Snapshot unverändert grün, `tsc` sauber.
|
||
|
||
### 3 — ISO-Specs generieren
|
||
`_generate_iso.py` erzeugt zusätzlich `src/lib/control-specs-iso.ts` — analog zu `control-titles-iso.ts` und `iso-isa-crosswalk.ts`. Quelle ist `mapping-iso.json` (`policy` und `verfahren` stehen dort je Anforderung); `needsAsset`/`needsRisk` über `ISO_TO_ISA` vom ISA-Spec erben, für die 33 ISO-eigenen Abschnitte explizit setzen — sinnvoll nur bei A.5.9 (`needsAsset`) sowie 6.1.2/6.1.3/8.2/8.3 (`needsRisk`).
|
||
**DoD:** Generator idempotent, `_verify_iso.py` DE und EN grün, keine handgepflegte Zweitliste.
|
||
|
||
### 4 — `FrameworkStrategy` + `TisaxStrategy` *(reine Extraktion)*
|
||
Interface nach §3 des Feindesigns. `TisaxStrategy` verdrahtet die vorhandenen Funktionen um: `loadScopeInput` + `controlsInScope` → `controlsInScope`, `suggestMaturity` + `targetMaturity` → `evaluate`, `openPoints` → `gaps`, `computeReadiness` → `summarise`.
|
||
**DoD:** Snapshot bitgenau grün. Jede Abweichung ist eine Regression, kein „ist besser geworden".
|
||
|
||
### 5 — `IsoStrategy`
|
||
| Aspekt | Regel |
|
||
|---|---|
|
||
| Scope | `SoaEntry.applicable = true`; Klauseln 4–10 immer im Scope |
|
||
| Zielwert | `implementationStatus = "umgesetzt"`, keine Stufung |
|
||
| Vorschlag | Richtlinie *und* Verfahren `validiert` + geforderte Verknüpfungen → `umgesetzt`; teilweise → `teilweise`; sonst `geplant` |
|
||
| Bestätigung | `SoaEntry.implementationStatus`; der Vorschlag überschreibt ihn nie |
|
||
| Lücken | fehlende Begründung, fehlender Nachweis, Status ≠ „umgesetzt" bei anwendbarem Control |
|
||
|
||
**DoD:** ISO-Mandant bekommt eine Bewertung über alle anwendbaren Controls; leere SoA meldet „Anwendbarkeit noch nicht erklärt" statt 0 %.
|
||
|
||
### 6 — `buildAssessment(db, tenantId, framework)`
|
||
Ersetzt `buildControlRows` (`src/server/soa-context.ts:146`) und delegiert an die Strategie. Sieben Dateien rufen es direkt; insgesamt hängen 13 an der Assessment-Logik.
|
||
**DoD:** Alle Aufrufstellen umgestellt, Snapshot grün, `tsc`/`lint`/`build` grün.
|
||
|
||
### 7 — ISO-Readiness-Bänder und Beschriftung
|
||
`REIFEGRAD_BANDS` (`src/lib/readiness.ts:16`) ist TISAX-Sprache („Assessment-reif", „AL-Ziel"). ISO bekommt eigene Bänder auf Basis des Umsetzungsgrads: < 50 % Aufbau · 50–79 % In Umsetzung · 80–99 % Zertifizierungsnah · 100 % Zertifizierungsreif.
|
||
**DoD:** In der ISO-Sicht erscheint kein AL-, Prüfziel- oder Reifegradbegriff. Ein ISO-Bericht argumentiert mit „umgesetzt, hier ist der Beleg", nicht mit „Reifegrad 2,4".
|
||
|
||
### 8 — ISO-Exporte
|
||
SoA-Export und Annex-A-Gap-Report. Der VDA-ISA-Export bleibt TISAX-only und unverändert.
|
||
**DoD:** Der ISO-Mandant kann die Eingaben für seine Managementbewertung aus dem Tool ziehen.
|
||
|
||
**Zusatznutzen, bitte mitnehmen:** Die 33 ISO-Anforderungen ohne ISA-Gegenstück als eigene Liste ausweisbar machen. Das ist genau die Delta-Arbeit, die ISO gegenüber TISAX zusätzlich verlangt — die erste Frage jedes TISAX-Kunden, der über ISO nachdenkt.
|
||
|
||
## Validierungs-Gate vor jedem PR
|
||
|
||
```bash
|
||
npx tsc --noEmit && npm run lint && npm run build
|
||
npx tsx scripts/test-framework-assessment.ts # Snapshot TISAX → 0 Abweichungen
|
||
npx tsx scripts/test-framework-dryrun.ts # Paket + Import → alle Prüfungen bestanden
|
||
cd seed/isms-vorlagenpaket-v2
|
||
python3 _generate_iso.py && python3 _generate_iso.py --lang en # beide idempotent
|
||
python3 _verify.py && python3 _verify_iso.py && python3 _verify_iso.py --lang en
|
||
python3 _render_diff.py HEAD # TISAX-Renderdiff → 0 Abweichungen
|
||
```
|
||
|
||
Weitere Konventionen: Migrationsflow Prisma 7 mit manuell angehängtem RLS-DO-Block (`docs/HANDOVER-DEV.md:100`); neue mandantengebundene Modelle in `TENANT_MODELS` (`src/server/db.ts:81`) **und** RLS-Policy in der Migration; jede neue Datei unter `src/server/actions/` in `scripts/check-module-guards.ts` eintragen, sonst schlägt der Build fehl.
|
||
|
||
## Definition of Done (gesamt)
|
||
|
||
| Prüfung | Erwartung |
|
||
|---|---|
|
||
| Snapshot TISAX | 0 Abweichungen zur Ausgabe vor dem Umbau |
|
||
| Bestandsmandant (TISAX) | Verhalten und Beschriftung unverändert |
|
||
| ISO-Mandant | Readiness und SoA rechnen; kein TISAX-Vokabular in der Oberfläche |
|
||
| Architektur | Strategie-Schnittstelle und Framework-Parameter vorhanden, auch wenn die UI nur ein Gleis zeigt |
|
||
| Belegbasis | `loadEvidenceResolver` kennt `FrameworkKey` nicht |
|
||
| Kennzahlen | je Framework eine eigene, **keine** gemischte Gesamtzahl |
|
||
| Gate | alle Prüfungen oben grün |
|
||
|
||
## Aufwand
|
||
|
||
4–6 PT im vorgezogenen Umfang. Schritte 1–4 hängen aneinander und sind Pflicht; 5–8 sind danach teilbar. Schwerpunkt liegt auf Schritt 4, nicht auf der ISO-Logik.
|
||
|
||
## Nicht dein Scope
|
||
|
||
Vorbelegung zwischen den Frameworks und die Reiter-UI (siehe Kundenlage). Ebenso Paket- und Freigabearbeit: `REVIEW_CYCLE`-Split an 32 Bestandsstellen, ISB-Freigabe der 19 ISO-Abschnittstexte, Review des Crosswalks.
|