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