# Fachliche Persistenzschnittstelle

Stand: 2026-07-17  
Zugehörige Planphase: Phase 9

## Zweck

`AssessorRepository` ist die technische Vertrauensgrenze zwischen Fachlogik und dauerhafter Speicherung. Import-, Vergleichs- und Reviewlogik kennen weder SQL noch HTTP, SQLite oder PostgreSQL. Ein späteres Backend implementiert denselben Vertrag und kann Transaktionen intern mit PostgreSQL abbilden.

Die heutige `LocalAssessorRepository`-Implementierung hält Daten ausschließlich im Arbeitsspeicher. Sie ist eine ausführbare Referenz für Semantik und Vertragstests, keine dauerhafte Produktdatenbank. Die bestehende lokale App- und Snapshotablage bleibt bis zur Backendintegration unverändert nutzbar.

## Repository-Operationen

- Projekte und Assessments anlegen, ändern und auflisten
- vollständige kanonische Assessment-Modelle laden
- Finding-Vorkommen nach Projekt, Assessment, Scan-Lauf, Tool, Definition, Severity und Status abfragen
- Reviews mit optimistischer Revisionsprüfung aktualisieren
- aktive Profilversionen registrieren
- bestätigte lokale Vergleichsregeln speichern und laden
- Vergleichsergebnisse speichern und abfragen
- vollständige Projektdaten kontrolliert exportieren
- Projekte nur nach exakter Kaskadenbestätigung löschen

Alle zurückgegebenen Objekte sind Kopien. Aufrufer können dadurch keinen gespeicherten Zustand außerhalb der Repository-Operationen verändern.

## Importtransaktion

Eine Importsitzung umfasst genau einen neuen Scan-Lauf und alle zugehörigen Objekte:

1. `beginImport` prüft Projekt, Assessment, Scan-ID und Scan-Reihenfolge.
2. `stage` sammelt Importdateien, Quelltabellen, Definitionen, Vorkommen, Evidenz und Diagnosen, ohne sie für Abfragen sichtbar zu machen.
3. `commit` prüft, dass sämtliche Querverweise zur gleichen Sitzung gehören, baut das vollständige kanonische Assessment-Modell auf und validiert es.
4. Erst nach erfolgreicher Gesamtvalidierung wird der Repository-Zustand atomar ersetzt.
5. `rollback` verwirft sämtliche gestagten Daten.

Jede Sitzung merkt sich die Repository-Revision bei ihrem Start. Wurde das Repository zwischenzeitlich verändert, schlägt der Commit mit einem Konflikt fehl. Dadurch überschreibt ein veralteter Import keine neueren Reviews, Profile oder parallelen Importe.

Ein fehlgeschlagener Commit bleibt rollbackfähig und hinterlässt weder Scan-Lauf noch Dateien oder Findings.

## Konflikte und Validierung

- doppelte Objekt-IDs erzeugen einen Konflikt,
- dieselbe Scan-Reihenfolge darf innerhalb eines Assessments nur einmal vorkommen,
- Dateien, Tabellen, Findings, Evidenz und Diagnosen dürfen keine Objekte außerhalb ihrer Importsitzung referenzieren,
- bestehende Finding-Definitionen dürfen aktualisiert, aber nicht auf einen widersprüchlichen kanonischen Schlüssel umgebogen werden,
- Reviewupdates benötigen die nächste Revision und können zusätzlich eine erwartete Vorversion angeben,
- Vergleiche dürfen nur Läufe und Findings ihres Assessments referenzieren,
- lokale Mappingregeln werden vor dem Speichern validiert.

## Export und Löschung

Der Projektexport enthält Assessments, Läufe, Importdateien, Tabellen, Definitionen, Vorkommen, Evidenz, Reviews, Diagnosen, Vergleiche und lokale Mappingregeln. Profilregistrierungen sind installationsweit und deshalb nicht Teil eines einzelnen Projektexports.

Eine Projektlöschung verlangt Projekt-ID und ausdrückliche Kaskadenbestätigung. Gelöscht werden alle ausschließlich zugehörigen Objekte. Finding-Definitionen, die weiterhin von einem anderen Projekt referenziert werden, bleiben erhalten.

## Übergang zu Backend und PostgreSQL

Phase 10 stellt den Repository-Vertrag über ein lokales Backend bereit. Der Browser spricht dann ausschließlich mit der Anwendungs-API. Phase 11 implementiert die Repository-Operationen und Importtransaktionen mit PostgreSQL-Migrationen. React erhält weder Datenbankzugangsdaten noch SQL.