Assessor_2.0/MIGRATION.md

# ASSESSOR – Migration von exxTableReader

## Legacy-Referenz

- Quelle: `exxTableReader.html`
- Unveränderte Kopie: `reference/exxTableReader-legacy.html`
- SHA-256 beider Dateien: `7742596C5C31E7D2E79F79AC12B0311B944A848B0FE5A512F37A32734631AE50`

## Erfasster Ausgangszustand

Die Legacy-Anwendung bietet:

- Einzel- und Mehrdateiimport für Excel, CSV/Text, JSON, XML und HTML
- vier Ansichten: Datensätze, Kacheln, Raster und Rohdaten
- Suche, Treffer-Navigation, wählbare Titelspalte und numerische Sortierung
- automatische Scan-Tool-Erkennung für PurpleKnight sowie Hinweise auf PingCastle und CIS-CAT Pro
- Purple-Knight-Sheetpriorisierung, Standard-Weight-Sortierung und Statusfilter
- Actionlist/Workspace mit Status, Priorität, Owner, Frist, Kommentaren und Markierungen
- lokale Review-Persistenz
- Result-Dateiverknüpfung über Dateinamen, Identitäts-Tokens und gemeinsame Wörter
- CSV-, Markdown-, HTML-Dashboard- und Snapshot-Exporte
- Dark-, Light- und Systemdarstellung

## Migrationsgrenze

Die neue React-Anwendung verwendet reine TypeScript-Module für Import, Analyse,
Profile, Result-Linking, Persistenz und Exporte. Die ursprüngliche Datei bleibt
die funktionale und visuelle Referenz. `src/legacy/legacy-controller.ts` markiert
den Übergangsbereich und darf keine neuen Funktionen aufnehmen.

Das stark geschichtete Legacy-CSS wurde nicht automatisch "bereinigt", weil
dadurch ein hohes Regressionsrisiko entstünde. Stattdessen bildet die neue App
die vorhandene kompakte Security-Reader-Sprache in getrennten Token-, Basis-,
Layout-, Komponenten- und Theme-Dateien nach. Ein pixelgenauer Abgleich bleibt
eine spätere, isolierte Migrationsstufe.

## Verifikation

- `npm run build`: erfolgreich (Vite 7.3.6)
- `npm test`: 12 Testdateien, 22 Tests plus Local-only-Sicherheitscheck, alle erfolgreich
- Vite-Devserver: HTTP 200 auf `127.0.0.1:5173`
- `cargo check`: erfolgreich
- `npm run tauri -- build --debug`: Anwendung, MSI und NSIS-Setup erfolgreich gebaut
- Statische Laufzeitprüfung: kein CDN, kein `window.XLSX`, kein Fetch/XHR/WebSocket und keine Shell-/Dateisystem-Capabilities
- Dynamische Leerlaufprüfung der gebauten Desktop-App: keine TCP- oder UDP-Verbindung

Details zum Sicherheitsmodell und zu den automatisierten Regressionen stehen in
`SECURITY.md`.

## Bekannte Hinweise

- Das gebündelte JavaScript ist wegen der lokal enthaltenen SheetJS-Bibliothek größer als 500 kB; Code-Splitting ist eine spätere Optimierungsstufe und keine Funktionsvoraussetzung.
- Der Auftrag verlangt ausdrücklich die Legacy-kompatible npm-Version `xlsx@0.18.5`. Die Schutzmaßnahmen gegen Formel- und VBA-Ausführung bleiben aktiv; `npm audit` und `npm audit --omit=dev` melden im Abschlussstand von Phase 10 keine bekannten Schwachstellen.
- Tauri erzeugt MSI und NSIS erfolgreich, warnt aber beim optionalen Updater-Bundle-Marker vor einer Versionsabweichung zwischen CLI und Rust-Crate. Es ist kein Updater aktiviert; Start und Bundles sind davon nicht blockiert.
## Lokales Backend ab Phase 10

Die Zielarchitektur ist nun auf dem Entwicklungsrechner ausführbar. Der gebaute
Node.js-Server liefert React und `/api/v1` über `http://127.0.0.1:4173` aus.
Die App erkennt diese Verbindung und verschiebt Dateiimporte dann auf die
serverseitige, weiterhin deterministische Engine. Ohne Server bleibt der
Browser-/Tauri-Pfad als Übergang erhalten.

Das Backend verwendet noch die In-Memory-Referenz des `AssessorRepository`.
Dauerhafte Daten, Mehrbenutzerbetrieb und PostgreSQL gehören zur nächsten
Migrationsphase. Details stehen in `docs/LOCAL_BACKEND.md`.
## PostgreSQL ab Phase 11

Das lokale Backend kann nun über `ASSESSOR_DATABASE_URL` dauerhaft mit
PostgreSQL arbeiten. Versionierte und prüfsummengeschützte Migrationen erzeugen
Fremdschlüssel, Integritätsregeln, Transaktions- und Suchindizes. Im
Abschlusslauf wurden PostgreSQL 16, alle 108 Tests, ein kompletter Import- und
Löschworkflow, Produktionsbuild, gestartetes Backend sowie `pg_dump` und
`pg_restore` gegen eine getrennte Wiederherstellungsdatenbank geprüft.

Ohne Datenbank-URL bleibt der bisherige In-Memory-Modus für die Entwicklung
verfügbar. Eine fehlerhafte konfigurierte Datenbank fällt nicht still darauf
zurück. Setup und Betrieb stehen in `docs/POSTGRESQL.md`.
## Mehrdateiworkflow ab Phase 12

Dateiauswahl führt nicht mehr unmittelbar zum Austausch des sichtbaren Datenbestands. ASSESSOR erstellt zunächst eine technische und semantische Vorschau mit SHA-256, Werkzeugerkennung, Konfidenzen, Mappingbestätigungen, Warnungen, Fehlern und Dubletten. Einzelne fehlerhafte Dateien können ausgelassen werden; unterschiedliche Werkzeuge dürfen gemeinsam in ein heterogenes Assessment einfließen.

Im Backendbetrieb wird die bestätigte Auswahl gegen die unveränderte serverseitige Vorschau geprüft und anschließend als kanonisches Projekt/Assessment einschließlich Findingdaten und Fingerprint-Historie atomar im Repository gespeichert. PostgreSQL-Migration 002 stellt die dauerhafte Dublettenerkennung bereit. Der Browserfallback behält nur eine lokale Übergangshistorie. Details stehen in `docs/IMPORT_WORKFLOW.md`.
## Importhärtung ab Phase 13

Alle Formate durchlaufen nun eine gemeinsame Ressourcenrichtlinie. Im
Serverbetrieb werden Parseraufträge in eigenen Workern mit Zeit-, Speicher-,
Parallelitäts- und Warteschlangengrenzen ausgeführt. ZIP-/Excel-, XML- und
HTML-Eingaben werden vor dem eigentlichen Parser gehärtet; umfangreiche
PingCastle-HTML-Berichte wechseln in eine stack-sichere Tabellenextraktion.
Auch die Base64-API-Prüfung und das gemeinsame Großzeilenmodell arbeiten
iterativ. CSV-Ausgaben neutralisieren spreadsheet-aktive Formeln, während
interne Originalwerte unverändert bleiben.

Der Vorschaucache ist zeitlich und mengenmäßig begrenzt. Manipulierte oder zu
große Dateien erzeugen strukturierte Fehler pro Datei und erreichen die
Persistenz nicht. Die verbindlichen Zahlen, Konfigurationsvariablen und
verifizierten Angriffsfälle stehen in `docs/IMPORT_SECURITY_LIMITS.md`.