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.