Harden Linear XLSX end to end

docs/README.md

@@ -31,7 +31,7 @@ ausdrücklich getrennt und dürfen nicht als bereits implementiert verstanden we
 - [Entwicklungs- und Contributor-Workflow](development-workflow.md)
 - [Deployment und Betrieb](deployment.md)
 
-## Aktive Revit-Umstellung
+## Revit / Linear XLSX
 
 - [Projektversionen und externer Modellaustausch](project-history-and-external-model-architecture.md)
 - [Revit-Integration über Linear-Excel](spec/revit-excel-integration-requirements.md) –
@@ -39,6 +39,8 @@ ausdrücklich getrennt und dürfen nicht als bereits implementiert verstanden we
 - [Phase-14-Plan R0–R10](spec/revit-excel-phase-14-plan.md) – Status,
   Paketgrenzen und Linear-Freigabepunkt nach R2
 - [R0-Bestandsaudit](spec/revit-excel-r0-audit.md)
+- [R10-Abnahme](spec/revit-excel-r10-validation.md) – Ende-zu-Ende- und
+  5.000-Objekte-Nachweis
 - [LLM-Kontext für Phase 14](revit-requirements-llm-context.md)
 
 ## Zukunftsarchitektur

docs/building-structure.md

@@ -101,7 +101,7 @@ bleiben.
 ## Offen
 
 - Revit: Eine Übernahme des Gebäudes aus Revit ist derzeit nicht geplant. Die
-  aktive Phase 14 verwendet Linear-XLSX; das Modell steht der expliziten
+  abgeschlossene Phase 14 verwendet Linear-XLSX; das Modell steht der expliziten
   Raumzuordnung im Importwizard nicht im Weg.
 - Raumflächen werden derzeit ausschließlich manuell gepflegt. Ein späterer
   Revit-Abgleich muss die Phase-14-Regeln mit externem Modellzustand, Vorschau

docs/circuit-list-editor-api.md

@@ -67,8 +67,9 @@ Prüfsumme; Ersetzen übernimmt die Grobbilanzen atomar und mit Undo/Redo,
 Duplizieren vergibt neue IDs. Transferformat 1 bleibt ohne Grobbilanzen
 importierbar.
 
-Das aktuelle Projekt-Snapshot-Schema 9 enthält die logischen Einspeisungsverweise
-der Verteilungen; Versionen 1–8 werden mit leeren Verweisen hochgestuft. Schema 8
+Das aktuelle Projekt-Snapshot-Schema 10 enthält Linear-XLSX-Zustand und die in
+Schema 9 eingeführten logischen Einspeisungsverweise der Verteilungen;
+Versionen 1–8 werden mit leeren Verweisen hochgestuft. Schema 8
 enthält außerdem die optionale Netto-Raumfläche `rooms[].areaM2`.
 Snapshot-Versionen 1–7 werden dafür mit
 `areaM2 = null` hochgestuft. Restore, Export und Import erhalten vorhandene
@@ -485,40 +486,32 @@ read nor write project data; applying a result uses `circuit.update` through
 
 Full request example and calculation rules: `docs/cable-sizing-module.md`.
 
-## Revit CSV Foundation
+## Revit / Linear XLSX
 
-- `GET /projects/:projectId/external-csv/configuration`
-  - returns the complete versioned project configuration or `null`
-- `PUT /projects/:projectId/external-csv/configuration`
-  - request: `expectedRevision` and the complete validated configuration
-  - executes `external-csv-configuration.update`
-  - returns configuration, revision and project history state
-- `POST /projects/:projectId/external-csv/preview`
-  - request: file name and Base64-encoded CSV content up to 18 MB
-  - requires a stored project configuration
-  - returns transport metadata, SHA-256, row classifications, suspect row
-    numbers and mapped source values for every recognized IFC object
-  - does not persist a draft, mutate project state or create a revision
-- `POST /projects/:projectId/external-csv/initial-import/plan`
-  - reparses the file and returns grouped room/family decisions plus current
-    room, distribution-board and ProjectDevice catalogs
-  - is stateless and rejects an already imported external source
-- `POST /projects/:projectId/external-csv/initial-import/apply`
-  - requires the expected revision, configuration version, file hash and one
-    decision for every room and exact family/type group
-  - reparses the file, blocks unknown family/type values and executes
-    `external-import.apply-initial` as one undoable project revision
-  - creates no Circuit or CircuitDeviceRow
-- `GET /projects/:projectId/circuit-lists/:circuitListId/external-objects`
-  - resolves the circuit list's distribution board server-side
-  - returns only external objects assigned to that board, with unassigned
-    objects first, their source room/marker values and current row-link status
-  - returns an empty list when the optional Revit import does not exist
-  - is read-only and exposes no stored command payloads or import bytes
+- `GET|PUT /projects/:projectId/external-model/configuration` reads or writes
+  the complete XLSX configuration. PUT requires `expectedRevision`.
+- `POST /projects/:projectId/external-model/configuration/detect` detects the
+  sheet layout and columns from an uploaded `.xlsx` sample without persisting.
+- `GET /projects/:projectId/external-model/import-status` returns the latest
+  batch metadata, object count and current missing-object count.
+- `POST .../initial-import/plan|apply` provides the stateless initial plan and
+  its confirmed atomic application. Apply retransmits and reparses the XLSX.
+- `POST .../follow-up-import/plan|apply` classifies exact Worksharing-ID
+  additions, source changes, unchanged and missing objects. Apply requires the
+  preview hash and source decisions and updates linked row quantities atomically.
+- `GET|PUT .../external-model/objects` loads one compact project list and
+  applies revision-safe multi-object planning changes.
+- `POST .../objects/assign-row|assign-new-row|assign-new-circuit|detach-row`
+  changes external-object row assignments through persistent commands.
+- `POST .../objects/delete-missing` requires `confirmed: true`, deletes only
+  objects marked missing and adjusts linked row quantities in the same command.
+- `POST .../external-model/return-workbook` creates the structure-preserving
+  return XLSX for all, deviating or selected objects.
+- `GET .../external-model/export-batches` returns append-only export metadata.
 
-Parser errors expose stable codes such as `header-not-found`,
-`ambiguous-header`, `invalid-ifc-guid` and `duplicate-ifc-guid`. The confirmed
-import uploads and parses the file again and verifies its hash.
+Uploads accept only `.xlsx` up to 10 MiB. Worksharing-IDs are exact and
+case-sensitive; IfcGUID is optional and non-unique. Undo/Redo uses persisted
+command states and never reparses workbook bytes.
 
 ## Document Branding (print view)
 

docs/circuit-list-editor-known-limitations.md

@@ -9,11 +9,11 @@
 - Named and automatic logical project snapshots can be listed and restored
   through the project page with persistent Undo/Redo. Automatic snapshots are
   created every 25 revisions and only their newest 12 entries are retained.
-- Die Linear-XLSX-Anbindung bis R9 ist umgesetzt: Erst- und Folgeimport,
+- Die Linear-XLSX-Anbindung bis R10 ist umgesetzt: Erst- und Folgeimport,
   Objektplanung und Editorzuordnung, strukturtreue Rückgabe sowie bestätigtes
-  Löschen fehlender Objekte verwenden persistente Commands. Offen ist die
-  R10-Härtung des gesamten Ablaufs mit mehreren Tausend synthetischen Objekten,
-  Messungen sowie Snapshot-/Transfer- und Neustarttests.
+  Löschen fehlender Objekte verwenden persistente Commands. Die vollständige
+  Kette ist mit 5.000 synthetischen Objekten sowie Snapshot-, Transfer- und
+  Neustarttests geprüft.
 - Persistence currently targets local SQLite; PostgreSQL is an architectural option, not an implemented runtime.
 - The global device library supports basic CRUD and copy operations, but has no
   versioning, permissions or controlled synchronization model.

docs/current-architecture.md

@@ -626,7 +626,7 @@ Oberfläche: `/projects/:projectId/grobbilanz`. Details:
   `toLowerCase()` gegen das vollständige Register der Stromkreisliste und wird
   von jedem Anlage-/Umbenennungspfad für Stromkreise und Verteilerkomponenten
   aufgerufen, auch dort, wo zuvor kein Vorab-Check existierte. Snapshot- und
-  Transfer-Integration verwenden aktuell Snapshot-Schema 9. Persistente
+  Transfer-Integration verwenden aktuell Snapshot-Schema 10. Persistente
   Insert/Delete/Update-Commands für veränderliche Verteilerkomponenten,
   Gruppen einschließlich befüllter Unterbäume sowie vollständige
   Gruppensortierung sind integriert. Der Editor zeigt die geschützte Struktur
@@ -643,7 +643,7 @@ PostgreSQL ist bewusst nicht implementiert. Die Domainregeln und
 Transaktionsgrenzen sollen portabel bleiben; Schema und Betriebsmodell benötigen
 bei einem späteren Wechsel trotzdem einen eigenen PostgreSQL-Adapter.
 
-## Revit-Anbindung: Linear-XLSX-Erstimport nach R5
+## Revit-Anbindung: Linear-XLSX nach R10
 
 R3 hat den Backend- und Persistenz-Cutover abgeschlossen. Migration `0014`
 entfernt die alten externen CSV-Entwicklungsdaten, nachdem verknüpfte
@@ -678,173 +678,32 @@ derselben Transaktion. Er erzeugt weder CircuitDeviceRows noch Circuits oder
 BMKs. Seine vollständige Inverse macht Undo/Redo nach Neustart möglich, ohne
 Workbookbytes erneut einzulesen oder zu parsen.
 
-### Historische Ausgangslage vor R3
+R6 bis R9 ergänzen die einmal geladene, clientseitig gefilterte und
+virtualisierte Projektobjektliste, revisionierte Sammelplanung, atomare
+Zuordnung im Stromkreislisteneditor, strukturtreue Rückgabe und den
+vollständigen Folgeimport. Der Folgeimport trennt fachliche Quelländerungen
+von noch nicht nach Revit übernommenen Rückgabewerten, aktualisiert akzeptierte
+Mengen samt Row-Summe und markiert fehlende Objekte ohne ihren Link zu lösen.
+Eine gesondert bestätigte Aktion löscht fehlende Objekte samt Mengenübergang;
+Undo stellt Objekt, Link und Menge wieder her.
 
-Der folgende Text beschreibt den Stand nach R1 und ist keine aktuelle
-Laufzeitdokumentation mehr.
+R10 weist den Ablauf über Rückgabe, Folgeimport, Snapshot-Restore,
+Projektduplikat und Undo/Redo nach Datenbankneustart nach. Persistenzpfade für
+vollständige externe Zustände schreiben große Mengen in begrenzten
+SQLite-Blöcken. Der synthetische Abnahmetest verarbeitet 5.000 Objekte; Details
+und Messwerte stehen in
+[R10-Abnahme](spec/revit-excel-r10-validation.md).
 
-Der nachfolgende Abschnitt beschreibt den am Ende von R1 noch vorhandenen
-Legacy-Laufzeitpfad. Er verwendet CSV und IfcGUID und ist die geprüfte
-Ausgangslage für den schrittweisen Cutover; er darf nicht erweitert werden.
-Das verbindliche Ziel ist der XLSX-Austausch des Linear-Plugins mit exakter,
-case-sensitiver Worksharing-ID. Details:
-[Excel-Anforderungen](spec/revit-excel-integration-requirements.md) und
-[R0–R10-Plan](spec/revit-excel-phase-14-plan.md).
+## Historische CSV-Unterlagen
 
-Der reine Adapter unter `src/external-model/csv` validiert die projektweite
-Transport- und Mappingkonfiguration und parst UTF-8-CSV verlustarm in eine
-klassifizierte Zellmatrix. Er erkennt Metadaten, Header, Passthrough-, Objekt-
-und Verdachtszeilen, prüft IFCGUIDs und serialisiert unveränderte Revit-Exporte
-einschließlich BOM, CRLF und Quotierung bytegleich zurück. Der lokale Befehl
-`npm run revit:verify-reference` prüft die bereitgestellte Referenzdatei.
-
-`external_csv_configurations` enthält höchstens eine versionierte Konfiguration
-je Projekt. `external-csv-configuration.update` schreibt Anlage, Änderung oder
-Entfernung zusammen mit Revision und persistentem Undo/Redo. Snapshot-Schema 5–8,
-Restore und portabler Projekttransfer enthalten diesen Zustand; beim Duplizieren
-werden Konfigurations-UUID und Projektlink remapped.
-
-Migration `0003` ergänzt die relationale Grundlage für genau eine implizite
-`revit_csv`-Quelle je Projekt, geordnete Importbatches, normalisierte
-Quellraummappings und über `(sourceId, ifcGuid)` eindeutige externe Objekte.
-Batches halten Konfigurationssnapshot, Originalbytes und die klassifizierte
-Zellmatrix zusammen. Migration `0004` ergänzt die monotone projektweite
-Konfigurationsversion am Batch, getrennt von der Schema-Version des
-Konfigurationsformats. Quellwerte, lokale Planungswerte und Override-Metadaten
-der Objekte sind getrennt; optionale Links auf Raum, Verteilung, ProjectDevice
-und CircuitDeviceRow bleiben nullable. `ExternalModelStateRepository` liest den
-vollständigen Zustand deterministisch und unterscheidet unbekannte von noch
-nicht importierten Projekten. Der letzte bestätigte Batch wird aus der
-Batchreihenfolge abgeleitet statt redundant an der Quelle gespeichert.
-Snapshot/Transfer v5 erfasst zusätzlich `manualQuantity`; Version 4 wird mit
-dem bisherigen Gesamtwert als manuellem Anteil hochgestuft. Originalbytes,
-Matrix und alle internen Links werden weiterhin vollständig erfasst,
-stellt sie in Fremdschlüsselreihenfolge wieder her und remappt beim
-Projektduplikat jede interne UUID; IFCGUID und Quelltransport bleiben
-unverändert. `external-import.apply-initial` ist die atomare Schreibgrenze für
-einen bestätigten Erstimport. Vor dem Insert prüft sie den aktuellen
-Konfigurationsstand, SHA-256 und Base64-Kanonizität, parst die Originalbytes
-erneut, vergleicht Matrix, vollständige IFCGUID-Menge und Quellwerte und
-validiert alle Raum-, Verteiler- und ProjectDevice-Links gegen das Projekt.
-Nicht explizit als Override markierte Planungswerte müssen dem regelbasierten
-Vorschlag entsprechen. Der Command erzeugt und verknüpft ausdrücklich keine
-CircuitDeviceRow; Undo entfernt den vollständigen unveränderten Importzustand,
-Redo verwendet dieselben UUIDs und Bytes. Bloße Vorschau und Importplanung
-erzeugen weiterhin keine dieser Zeilen.
-
-Migration `0005` trennt bei `CircuitDeviceRow` den manuellen Mengenanteil vom
-weiterhin materialisierten Gesamtwert. Bestehende Daten werden mit
-`manualQuantity = quantity` übernommen. Die Fachregel für spätere externe
-Zuordnungs-Commands lautet `quantity = manualQuantity + Summe der
-effectiveQuantity aller verknüpften ExternalModelObjects`; Link und beide
-Mengenwerte müssen innerhalb desselben Projekt-Commands wechseln.
-`external-object.update-row-assignment` ist diese atomare Schreibgrenze für
-bestehende Gerätezeilen. Sie weist mehrere externe Einzelobjekte zu, verschiebt
-sie zwischen vorhandenen Rows oder löst ihre Links. Vor dem Schreiben werden
-die vollständigen erwarteten Row- und Objektsnapshots, Projektzugehörigkeit,
-Verteilung, Gruppenkategorie, Raum und Selektionskennzeichen geprüft.
-Abweichende lokale Planungswerte benötigen eine explizite Konfliktbestätigung;
-unterschiedliche Räume, Kategorien oder Selektionskennzeichen werden nicht
-still zusammengeführt. Alle betroffenen materialisierten Mengen werden aus dem
-unveränderten manuellen Anteil und sämtlichen Ziel-Objektlinks validiert. Die
-Gegenrichtung enthält dieselben vollständigen Snapshots und funktioniert nach
-Neustart; beim Lösen des letzten Objekts bleibt die Row bestehen.
-`external-object.assign-to-new-row` fügt unzugeordnete Objekte atomar als neue
-Gerätezeile in einen vorhandenen Stromkreis ein. Der manuelle Anteil dieser Row
-ist null; Gesamtmenge, Raum, Verteilung, Kategorie, Selektionskennzeichen und
-Planungswerte werden vor dem Schreiben geprüft. Undo löst exakt diese Objekte
-und löscht die erzeugte Row nur, wenn sie und ihre Linkmenge unverändert sind.
-Der Löschbefehl ist ausschließlich für die Projekthistorie zugelassen; eine
-normale spätere Trennung lässt die Row gemäß der allgemeinen Zuordnungsregel
-bestehen.
-`external-object.assign-to-new-circuit` erzeugt einen neuen Stromkreis mit
-vorab festgeschriebenem BMK, abgeleiteter Projektspannung, genau einer
-externen Row und verpflichtendem Standardschutz zusammen mit den Objektlinks.
-Verteilungs-, Gruppen-, Raum-, Mengen- und Planungsregeln werden vor dem Insert
-gegen den aktuellen Projektstand geprüft. Der historische Gegenbefehl ist kein
-allgemeiner Löschpfad: Er entfernt den vollständigen Circuit-Teilbaum nur bei
-unverändertem Snapshot und unveränderter Objektlinkmenge. Redo verwendet exakt
-dieselben IDs, dasselbe BMK und denselben Schutzsnapshot.
-Die drei Zuordnungsadapter teilen sich
-`external-object-assignment.persistence.ts` für Snapshotvergleich,
-Kompatibilitätsregeln und link-sichere Updates.
-`GET /api/projects/:projectId/circuit-lists/:circuitListId/external-objects`
-liefert die verteilungsbezogene Read-Projektion für den späteren Editor-Drawer.
-Die CircuitList bestimmt den Verteiler serverseitig; die Antwort enthält nur
-dessen externe Objekte, sortiert unzugeordnet vor zugeordnet, sowie kompakte
-Quell-, Raum-, Planungs- und Linkangaben. Originalbytes und vollständige
-Command-Snapshots werden nicht an diese Oberfläche gegeben. Ohne optionalen
-Revit-Import ist die Projektion leer.
-`GET` und `PUT /api/projects/:projectId/external-csv/configuration` lesen oder
-ändern die Konfiguration; der PUT plant Identität und nächsten
-Konfigurationsstand serverseitig und verwendet den typisierten Command.
-`POST /api/projects/:projectId/external-csv/preview` nimmt Dateiname und
-Base64-kodierte CSV bis 18 MB entgegen. Der zustandsfreie Service liefert Hash,
-Dialekt, Header, Klassifikationszahlen, Verdachtszeilen und gemappte
-Objektquellwerte. Er schreibt weder Entwurf noch Projektdaten.
-`POST /api/projects/:projectId/external-csv/initial-import/plan` verwendet
-denselben begrenzten Transport, setzt eine gespeicherte Konfiguration und einen
-noch leeren externen Projektzustand voraus und bleibt ebenfalls zustandsfrei.
-Die Antwort gruppiert Quellräume, schlägt bei genau einer identischen
-Raumnummer den vorhandenen Raum vor, gruppiert exakte Familie-und-Typ-Werte,
-liefert regelbasierte Objektplanungswerte und Konfliktzahlen und enthält die
-vorhandenen Ebenen, Räume, Verteilungen und ProjectDevices als Auswahlkataloge.
-Unbekannte Familien, ungültige Leistungen/Mengen und Objekte ohne Raum bleiben
-sichtbare Warnungen; es wird keine Entscheidung automatisch bestätigt.
-`POST /api/projects/:projectId/external-csv/initial-import/apply` nimmt Datei,
-erwarteten Hash, Konfigurationsversion und Projektrevision erneut entgegen.
-Vollständige Entscheidungen ordnen jeden Quellraum optional einem vorhandenen
-Raum und einer Standardverteilung sowie jede exakte Familiengruppe optional
-einem vorhandenen ProjectDevice zu. Unklassifizierte Familien oder fehlende
-Gruppenentscheidungen blockieren. Der Server parst und plant erneut, erzeugt
-stabile interne UUIDs und übergibt den vollständigen Zustand an
-`external-import.apply-initial`; CSV-Stromkreiswerte bleiben reine Quellwerte
-und alle `circuitDeviceRowId` bleiben `null`.
-Die Projektseite öffnet über „Revit-CSV“ ein deutsches Modal für Dialekt,
-Spaltenzuordnung, zusätzliche Quellfelder und exakte Familie-und-Typ-Regeln.
-Nach dem revisionierten Speichern kann eine lokale CSV gewählt und über den
-zustandsfreien Endpunkt geprüft werden. Die Oberfläche zeigt Kennzahlen und nur
-die ersten 25 erkannten Objekte; die vollständigen Objekte bleiben in der
-Response verfügbar, ohne alle Zeilen in den DOM einzufügen. Der anschließende
-Erstimport-Wizard gruppiert Quellräume und exakte Familie-und-Typ-Werte. Er
-zeigt eindeutige, mehrdeutige und neue Raumtreffer, lässt vorhandene Räume,
-Standardverteilungen und ProjectDevices explizit zuordnen und blockiert die
-Übernahme bei unklassifizierten Familien. Erst nach einem Bestätigungsdialog
-wird der vollständige Import als eine persistente, rückgängig machbare
-Projektrevision angewendet. Dabei entstehen keine Stromkreise oder Gerätezeilen.
-Fehlende Räume und ProjectDevices können direkt aus der jeweiligen Gruppe über
-die regulären Projektformulare angelegt werden. Revit-Werte befüllen diese
-Formulare vor, werden aber vor dem Speichern sichtbar vom Nutzer bestätigt.
-Die Kataloganlage ist jeweils ein eigener Projekt-Command; der Wizard übernimmt
-den neuen Datensatz anschließend in seinen lokalen Auswahlkatalog und markiert
-ihn für die betroffene Gruppe.
-
-### Freigegebener Zielpfad ab R2
-
-R2 ersetzt zunächst nur den Transportadapter und endet mit einem realen
-Linear-Rückimporttest. R3 bleibt bis zu dessen Freigabe gesperrt. Scheitert der
-ExcelJS-Roundtrip, wird vor R3 ein Adapter vorgeschlagen, der die Original-XLSX
-direkt auf OOXML-Ebene ändert.
-
-Der Zielzustand verwendet Worksharing-ID als exakten, case-sensitiven externen
-Schlüssel; IfcGUID bleibt optional. Die Konfiguration hat keinen eigenen
-Versionszähler. `expectedRevision` bindet Vorschau und Apply, Importbatches
-speichern eine Konfigurationskopie. Nur der letzte Batch hält Workbook und
-Matrix vollständig, ältere Batches nur Metadaten. Apply parst die erneut
-übertragene Datei, Undo/Redo arbeitet nur auf persistierten Zuständen.
-
-Die eigene Route `/projects/:projectId/revit` lädt eine kompakte Objektliste
-einmal und stellt sie clientseitig gefiltert, sortiert und virtualisiert dar.
-Verknüpfte Objekte folgen dem Verteiler ihrer Row. Row-, Circuit- und
-Gruppenlöschungen lösen externe Links nach Warnung im selben Command; Undo
-stellt sie wieder her. Raum- und Verteilerlöschungen bleiben bei externen
-Referenzen gesperrt.
+Der vor R3 vorhandene CSV-/IfcGUID-Laufzeitpfad ist entfernt. Seine damalige
+Ausgangslage bleibt ausschließlich im [R0-Audit](spec/revit-excel-r0-audit.md)
+und in den als abgelöst markierten CSV-Spezifikationen nachvollziehbar. Alte
+CSV-Snapshots und CSV-History werden weiterhin ausdrücklich abgelehnt.
 
 ## Noch nicht unterstützt
 
 - Mehrbenutzerbetrieb und Konfliktauflösung
-- R10-Härtung des Linear-XLSX-Ablaufs für große Datenmengen sowie
-  Ende-zu-Ende-Nachweise über Snapshot, Transfer und Neustart
 - vollständige elektrische Dimensionierung
 - Produktionsdeployment
 

docs/print-view.md

@@ -131,8 +131,9 @@ ihren Wert.
 Vor dem Anwenden der additiven Migrationen einschließlich `0012` eine verifizierte
 Datenbanksicherung mit `npm run db:backup` erstellen. Die neuen Projekt- und
 Verteilerfelder bleiben bei bestehenden Datensätzen zunächst leer (`null`).
-Snapshot-Schema 9 enthält zusätzlich die logischen Einspeisungsverweise; die
-unterstützten Versionen 1–8 werden mit leeren Verweisen hochgestuft. Restore und
+Snapshot-Schema 10 enthält den aktuellen Projektzustand; die in Schema 9
+eingeführten Einspeisungsverweise werden in den unterstützten Versionen 1–8
+mit leeren Verweisen hochgestuft. Restore und
 Projektkopie erhalten beziehungsweise remappen die neuen Angaben. Globale
 Büroangaben und Logo gehören zur Datenbanksicherung, nicht
 zum logischen Projektsnapshot oder Projekttransfer.

docs/project-history-and-external-model-architecture.md

@@ -116,8 +116,8 @@ Implemented automatic-snapshot policy:
 
 Phase 14 is active and follows the
 [Linear-Excel requirements](spec/revit-excel-integration-requirements.md) and
-[R0–R10 plan](spec/revit-excel-phase-14-plan.md). The existing CSV/IFCGUID
-runtime is a legacy starting point for the cutover, not the target model.
+[R0–R10 plan](spec/revit-excel-phase-14-plan.md). The CSV/IFCGUID runtime has
+been removed; the implemented runtime uses Linear XLSX and exact Worksharing-ID.
 
 External model exchange should use explicit staging and link entities instead of writing imported rows directly into circuits.
 
@@ -152,6 +152,12 @@ Required behavior:
 - Missing objects and duplicate/conflicting Worksharing-IDs are reported,
   never silently reassigned.
 
+R10 verifies the complete implemented path through initial import, planning,
+row assignment, return workbook, follow-up import, snapshot restore, portable
+duplicate and restart-safe Undo/Redo. Large state replacement uses bounded
+SQLite insert batches so imports, restores and duplicates do not exceed the
+driver's SQL-variable limit.
+
 The project configuration has no separate revision counter. Stateless plans
 and apply requests bind to `expectedRevision`; every applied import batch holds
 its configuration copy. Apply reparses the retransmitted workbook. Undo and

docs/revit-requirements-llm-context.md

@@ -1,15 +1,17 @@
 # LLM-Kontext für die Revit-Integration
 
-Die frühere offene Revit-/CSV-Anforderungsplanung ist abgeschlossen und
-abgelöst. Für Arbeiten an Phase 14 sind vollständig zu lesen:
+Die frühere Revit-/CSV-Anforderungsplanung ist abgelöst und Phase 14 ist mit
+R10 abgeschlossen. Für Arbeiten an der Linear-XLSX-Anbindung sind vollständig
+zu lesen:
 
 - [Revit-Integration über Linear-Excel](spec/revit-excel-integration-requirements.md)
 - [R0–R10-Plan](spec/revit-excel-phase-14-plan.md)
 - [R0-Bestandsaudit](spec/revit-excel-r0-audit.md)
+- [R10-Abnahme](spec/revit-excel-r10-validation.md)
 - [Aktuelle Systemarchitektur](current-architecture.md)
 - [Projekt-History und externer Modellzustand](project-history-and-external-model-architecture.md)
 
 Bei Widersprüchen gilt das Anforderungsdokument. CSV, IfcGUID als Schlüssel,
-Dynamo, Revit-API und JSON-Transport sind keine Zielpfade. Der derzeit noch im
-Code vorhandene CSV-Stand ist ausschließlich die in R1 dokumentierte
-Legacy-Ausgangslage für den schrittweisen Cutover.
+Dynamo, Revit-API und JSON-Transport sind keine Zielpfade. Der CSV-Laufzeitpfad
+ist entfernt; alte CSV-Snapshots und CSV-History werden mit einer deutschen
+Migrationsmeldung abgelehnt.

docs/spec/07-implementation-phases-todo.md

@@ -532,6 +532,9 @@ Acceptance criteria:
 
 ## Phase 14: External Model Round-Trip
 
+Status: abgeschlossen am 30.09.2026 mit R10. Siehe
+[R10-Abnahme](revit-excel-r10-validation.md).
+
 Status: R0 ist mit Korrekturen freigegeben; R1 stellt die Dokumentation auf
 Linear-XLSX und Worksharing-ID um. Die frühere CSV-Planung 14.0–14.6 ist
 abgelöst und wird nicht fortgeschrieben.

docs/spec/08-current-product-backlog.md

@@ -162,7 +162,7 @@ ProjectDevices and device rows (#20).
 3. [x] Snapshot-to-revision descriptions and history presentation.
 4. [x] Distribution-board power summary and project column layout.
 
-The Revit/Linear-XLSX round-trip is now the separately planned active Phase 14.
-It uses exact Worksharing-ID identity and must not be inferred from these
-unrelated backlog tasks. See
+The Revit/Linear-XLSX round-trip was completed separately in Phase 14. It uses
+exact Worksharing-ID identity and must not be inferred from these unrelated
+backlog tasks. See
 [the R0–R10 plan](revit-excel-phase-14-plan.md).

docs/spec/revit-excel-integration-requirements.md

@@ -478,6 +478,14 @@ synthetischen großen Workbooks. Die virtualisierte Tabelle rendert nur den
 sichtbaren Ausschnitt, während Filterung, Sortierung und Auswahl auf der einmal
 geladenen kompakten Liste arbeiten.
 
+Umsetzungsstand R10: Die vollständige Kette ist mit dateibasierter SQLite-
+Persistenz und Neustart getestet. Der synthetische Lasttest verarbeitet 5.000
+Objekte, misst Transport, Planung, Transaktionen, Command-/Snapshotgröße,
+Heap und Clientprojektion und prüft Restore sowie Projektduplikat. Große
+Zustandsersetzungen verwenden begrenzte Insertblöcke innerhalb derselben
+atomaren Transaktion. Die Ergebnisse sind in der
+[R10-Abnahme](revit-excel-r10-validation.md) dokumentiert.
+
 Jedes Paket R1–R10 führt fokussierte Tests sowie aus:
 
 ```text

docs/spec/revit-excel-phase-14-plan.md

@@ -18,7 +18,7 @@ Der alte CSV-Plan 14.0–14.6 ist abgelöst und wird nicht fortgeschrieben.
 | R7 | abgeschlossen | Gruppierter Editorbereich, drei Drag-and-drop-Ziele, Row-Indikator, ausdrückliches Lösen und atomare Löschübergänge mit exaktem Undo/Redo. |
 | R8 | abgeschlossen | Rückgabe-Excel für alle, abweichende oder ausgewählte Objekte und append-only Exportnachweis sind umgesetzt. |
 | R9 | abgeschlossen | Vollständiger Folgeimport nach exakter Worksharing-ID mit Quellentscheidungen, fehlenden Objekten, bestätigtem Löschen und persistentem Undo/Redo. |
-| R10 | offen | Ende-zu-Ende-Härtung, große Datenmengen und Abschlussdokumentation. |
+| R10 | abgeschlossen | Ende-zu-Ende-Kette, 5.000-Objekte-Lasttest, gebatchte Zustandspersistenz und Abschlussdokumentation. |
 
 ## R0 – Audit
 
@@ -214,6 +214,15 @@ Zusätzlich: mehrere Tausend synthetische Objekte, virtualisierte UI,
 Speicher-/Payload-/Transaktionsmessungen, Löschwarnungen samt Link-Inversen,
 alte CSV-Ablehnungen und Dokumentation auf den ausgelieferten Stand.
 
+Umsetzungsstand vom 30.09.2026: Der dateibasierte Integrationstest deckt die
+vollständige Kette bis zu Undo/Redo nach einem Datenbankneustart ab. Ein
+synthetisches Workbook mit 5.000 Objekten durchläuft Erst- und Folgeimport,
+Snapshot-Restore, Projektduplikat sowie die extrahierte Clientfilter- und
+Virtualisierungslogik. Die dabei gefundene SQLite-Grenze ungebatchter Inserts
+ist für alle vollständigen External-Model-Zustandspfade behoben. Messwerte und
+Abnahme stehen in [R10-Abnahme](revit-excel-r10-validation.md). Phase 14 ist
+damit abgeschlossen.
+
 ## Pflichtprüfungen je Paket R1–R10
 
 ```text

docs/spec/revit-excel-r10-validation.md

@@ -0,0 +1,60 @@
+# R10-Abnahme der Linear-XLSX-Anbindung
+
+Stand: 30.09.2026. R10 schließt Phase 14 mit synthetischen, reproduzierbaren
+Integrations- und Lasttests ab. Die reale Musterdatei wird dafür nicht benötigt
+und bleibt unversioniert.
+
+## Ende-zu-Ende-Nachweis
+
+`tests/revit-xlsx-end-to-end.test.ts` verwendet eine dateibasierte SQLite-
+Datenbank und prüft in einer Kette:
+
+```text
+Erstimport → Objektplanung → Row-Zuordnung → Rückgabe-XLSX
+  → Folgeimport → Snapshot/Restore → Projektduplikat
+  → Datenbankneustart → Undo → Redo
+```
+
+Der Test bestätigt insbesondere die materialisierte Row-Menge, die Reduktion
+des älteren Importbatches auf Metadaten, das Remapping aller internen UUIDs im
+Duplikat und parserfreies Undo/Redo nach dem Neustart.
+
+## Last- und Größenmessung
+
+`tests/revit-xlsx-scale.test.ts` erzeugt 5.000 synthetische Objekte in einer
+Linear-kompatiblen XLSX. Der Test misst Erst- und Folgeimport, Command- und
+Snapshotgröße, Heap-Wachstum sowie clientseitiges Filtern, Sortieren und das
+virtuelle Fenster. Er führt außerdem Snapshot-Restore und Projektduplikat mit
+dem vollständigen Zustand aus.
+
+Messung auf der Entwicklungsumgebung am 30.09.2026:
+
+| Messwert | Ergebnis |
+| --- | ---: |
+| Objekte | 5.000 |
+| XLSX-Datei | 191.019 Bytes |
+| Erstimport-Command | 15.598.253 Bytes |
+| logischer Projektsnapshot | 15.598.071 Bytes |
+| XLSX-Erstplanung | 6.831 ms |
+| atomare Erstimporttransaktion | 672 ms |
+| XLSX-Folgeplanung | 6.303 ms |
+| atomare Folgeimporttransaktion | 887 ms |
+| Clientfilter, Sortierung und Fenster | 37 ms |
+| Heap-Zuwachs des erfolgreichen Gesamtlaufs | 154.125.568 Bytes |
+
+Der Heap-Wert ist wegen Garbage Collection und der absichtlich verwendeten
+In-Memory-Datenbank nicht deterministisch. Wiederholte Auditläufe lagen unter
+der Testobergrenze von 768 MiB. Das virtuelle Fenster enthält bei 520 px Höhe
+maximal 22 statt 5.000 Zeilen.
+
+## Gefundene und behobene Grenze
+
+Der erste 5.000-Objekte-Lauf scheiterte an einem ungebatchten SQLite-
+Mehrfach-Insert. `insertManyInBatches` begrenzt nun die Insertblöcke für
+Erstimport, Folgeimport, Snapshot-Restore und Projektduplikat. Alle Blöcke
+bleiben Teil der jeweiligen bestehenden Transaktion; ein Fehler rollt weiterhin
+die gesamte Operation zurück.
+
+Die vorhandenen Tests decken außerdem die deutschen Ablehnungen alter
+CSV-Snapshots und CSV-History, Löschwarnungen, atomare Link-Inversen und den
+Schutz referenzierter Räume und Verteiler ab.