# Mehrdatei-Importworkflow ## Zweck Phase 12 ersetzt den direkten Dateiimport durch einen zweistufigen Ablauf: 1. ASSESSOR prüft und parst jede ausgewählte Datei unabhängig. 2. Erst nach Sichtprüfung und ausdrücklicher Freigabe wird die Auswahl gemeinsam gespeichert und geöffnet. CSV, JSON, XML, HTML, XLSX und XLS können in einem Stapel gemischt werden. Unterschiedliche erkannte Werkzeuge werden als heterogenes Assessment zusammengeführt; Datei- und Tabellenherkunft bleiben an den Datensätzen erhalten. ## Vorschau Die Vorschau zeigt pro Datei: - technischen Status und Format - erkannte Quelle beziehungsweise Werkzeugprofil - Konfidenz der Quellenerkennung - Tabellen- und Datensatzanzahl - Parserwarnungen und verworfene Inhalte - nicht semantisch zugeordnete Felder - noch zu bestätigende unsichere Zuordnungen - SHA-256-Fingerabdruck und Dublettenhinweis - kontrollierte Parserfehler Fehlerhafte Dateien sind nicht auswählbar. Dubletten werden standardmäßig abgewählt, können aber bewusst erneut ausgewählt werden. Unsichere Zuordnungen blockieren nur die betroffene ausgewählte Datei, bis sie bestätigt wurden. Abbrechen verändert das aktuell geöffnete Projekt nicht. ## Transaktionaler Abschluss Im Serverbetrieb hält das Backend höchstens 25 aktuelle Vorschauen kurzzeitig im Arbeitsspeicher. Der Abschluss enthält die eindeutigen Vorschau-IDs und Metadaten der ausgewählten Dateien. Das Backend gleicht diese Daten gegen seine eigene geparste Vorschau ab; geänderte oder abgelaufene Auswahlen werden kontrolliert abgewiesen. Aus der bestätigten serverseitigen Vorschau entsteht ein kanonisches Modell aus: - Projekt und Assessment - einem Scan-Lauf - Importdateien mit Hash und Erkennungsdaten - Quelltabellen - Finding-Definitionen und Finding-Vorkommen - Originalfeldern, semantischen Feldzuordnungen und Provenienz - Evidenz und Importdiagnosen `commitCanonicalImport` speichert dieses Modell und die Fingerprint-Historie in genau einem Repository-Vorgang. Der PostgreSQL-Adapter verwendet dafür genau eine Datenbanktransaktion und eine gesperrte Repository-Revision. Ein Fehler hinterlässt weder ein leeres Projekt noch Teil-Findings oder einen isolierten Dubletteneintrag. Nach erfolgreichem Server-Commit ersetzt React den sichtbaren Datenbestand atomar. Der Importbericht weist importierte, übersprungene, fehlgeschlagene und als Dublette erkannte Dateien sowie Warnungen und Datensatzanzahlen aus. ## Fingerprint-Historie Der Fingerabdruck wird aus den tatsächlichen Dateibytes mit SHA-256 berechnet. PostgreSQL speichert pro Hash Dateiname, Größe, Änderungszeitpunkt, ersten und letzten Importzeitpunkt sowie einen Wiederholungszähler in `assessor_import_fingerprints`. Im reinen Vite-/Tauri-Fallback ohne Backend wird dieselbe Information unter `ASSESSOR.importFingerprints.v1` im Browser-Speicher geführt. Dieser Modus ist nur eine lokale Übergangsfunktion: Er bietet keine zentrale Mehrbenutzerhistorie und keine dauerhafte serverseitige Finding-Persistenz. ## Sicherheits- und Betriebsgrenzen - Dateien verlassen den lokalen ASSESSOR-Ursprung nicht. - Originaldateibytes werden nach Vorschau und Parsing nicht separat aufbewahrt. - Die kurzfristige Vorschau verfällt bei einem Backend-Neustart und muss dann neu erzeugt werden. - Maximal 50 Dateien sind pro Stapel zulässig. - Es gelten 100 MiB pro Datei und 140 MiB für einen Base64-JSON-Request. Ergänzend greifen die Tabellen-, Zeilen-, Spalten-, Zell-, ZIP-, Zeit-, Speicher- und Warteschlangengrenzen aus `docs/IMPORT_SECURITY_LIMITS.md`. - Für den späteren Firmenbetrieb sind Authentifizierung, Projektberechtigungen und HTTPS weiterhin Voraussetzung. ### Exakter Scanner-Reimport Ein zielgebundener Scanner-Reimport darf ausschließlich den bereits im Timeslot enthaltenen Originalreport erneut verarbeiten. Dateiname, Dateidatum, erkanntes Werkzeug und eine inhaltliche Ähnlichkeit sind dafür kein ausreichender Identitätsnachweis. - Die vollständige Menge der erneut ausgewählten Dateien muss byte-identisch zur ursprünglichen Dateimenge des zu ersetzenden Scan-Laufs sein. Verglichen werden Anzahl und vollständiges SHA-256-Multiset einschließlich mehrfach vorkommender identischer Dateien. - Bei einem Mehrdatei-Report müssen alle ursprünglichen Dateien und nur diese Dateien erneut ausgewählt werden. Eine fehlende, zusätzliche oder abweichende Datei verweigert den Reimport. - Die Vorschau prüft die Identität vor Parsing und Persistenz. Der Abschluss prüft die endgültig ausgewählte Dateimenge erneut. Local- und PostgreSQL-Repository erzwingen dieselbe Invariante als zusätzliche Persistenzbarriere. - Fehlt beim ursprünglichen Scan-Lauf ein vollständiger SHA-256-Nachweis, wird fail closed abgebrochen. Ein sicherer Reimport ist dann nicht belegbar; der bestehende Scan bleibt unverändert aktiv. - Auch die explizite Übernahme eines bereits importierten Ersatzlaufs ist nur bei exakt identischen SHA-256-Dateimengen zulässig. - Der lokale Frontend-Fallback darf einen zielgebundenen Reimport nicht ausführen, weil nur das verbundene Backend den ursprünglichen persistierten Hashnachweis verbindlich prüfen kann. Jede Abweichung erzeugt eine verständliche Fehlermeldung, verweigert den Import vollständig und lässt den bestehenden Scan-Lauf aktiv. ## Relevante Endpunkte - `POST /api/v1/import-batches/preview` - `POST /api/v1/import-batches/complete` - `GET /api/v1/assessments/:id/model` Beide POST-Endpunkte unterliegen Same-Origin-Prüfung und benötigen `X-Assessor-Request: 1`. ## Mandantenbezogener Datahub Der Datahub ist der einzige Einstieg für Dateiimporte. Dateien werden in der Bearbeitungsansicht eines gespeicherten Mandanten über `Import Data` ausgewählt; dessen Projekt-ID wird durch Vorschau und Commit bis zur kanonischen Importtransaktion weitergereicht. Ein bestehender Mandant wird dabei aktualisiert, aber weder umbenannt noch durch ein automatisch erzeugtes Scannerprojekt ersetzt. Die Mandantenkacheln trennen Auswahl und Pflege: `Open` setzt den Mandanten als aktiven Arbeitskontext und wechselt nach `Work`; ohne aktiven Mandanten bleibt `Work` deaktiviert. `Edit` öffnet keine modale Überlagerung, sondern eine eigene Datahub-Seite für Name, Bemerkung, Consultant, Dateiimport und Dateihistorie. Die Mandantenübersicht liest Dateianzahl und erkannte Quellwerkzeuge über `GET /api/v1/projects/:id/import-files`. Dieser Endpunkt liefert nur Importdateimetadaten und lädt keine Finding-Vorkommen. In der Bearbeitungsansicht werden Dateien primär nach `lastModifiedAt`, ersatzweise nach `importedAt`, absteigend angezeigt. Originaldateibytes werden weiterhin nicht separat aufbewahrt. Bearbeiten verwendet den bestehenden Projekt-Upsert. Löschen verlangt Projekt-ID und `cascade: true` und wird auf der Kachel sowie in der Bearbeitungsansicht durch einen expliziten Warnungsdialog bestätigt. ### Scan-Läufe in der Oberfläche Ein gemeinsam bestätigter Mehrdatei-Import besitzt eine gemeinsame `scanRunId` und erscheint in der Scan-Historie als genau ein Bericht. Dateianzahl, Formate und Gesamtgröße werden aggregiert; das primäre Dateidatum ist das jüngste Quelldatum des Laufs. Erkennt die Pipeline innerhalb eines Batches genau ein nicht-generisches Werkzeug, übernehmen bislang generische Begleitdateien diese Werkzeugidentität mit einer dokumentierten Batch-Inferenz. Bei mehreren tatsächlich erkannten Werkzeugen bleibt der Lauf als heterogen gekennzeichnet. Mandantenstammdaten werden über `POST /api/v1/projects` gespeichert. Die Oberfläche zeigt „In der Datenbank gespeichert.“ erst, nachdem `GET /api/v1/projects/:id` den neuen Zeitstempel sowie Name, Bemerkung und Consultant identisch zurückgeliefert hat. Abweichung oder Fehler erzeugen eine Fehlermeldung statt einer Erfolgsbestätigung. ### Mandant in Work öffnen `Open` setzt nicht nur den Mandantenkontext. Der Client liest über `GET /api/v1/projects/:id/assessments` alle Assessments des Mandanten und lädt deren kanonische Modelle parallel über `GET /api/v1/assessments/:id/model`. Aus sämtlichen Scan-Läufen, Originalfeldern, Quelltabellen und Importdateien wird eine gemeinsame Work-Datenansicht mit aggregiertem Projektblatt und getrennten laufbezogenen Quellblättern rekonstruiert. Dadurch bleiben auch ältere Excel-, CSV- und andere Scanberichte sichtbar. Besitzt der Mandant noch keinen Scan oder keine darstellbaren Findings, bleibt Work bewusst leer und zeigt einen erklärenden Status.