craftvia/docs/PROMPT-lane-framework-assessment.md

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

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.