Document Linear Excel integration

2026-09-29 22:28:16 +02:00 · 2026-09-29 22:28:16 +02:00 · d4803a18d2
commit d4803a18d2
parent ae318a51ac
16 changed files with 932 additions and 2316 deletions
--- a/.gitignore
+++ b/.gitignore
@ -9,3 +9,4 @@ dist/
 data/*.db
 data/backups/*.db
 .codex/*.log
 /docs/spec/kbp-Stromkreis.xlsx
--- a/AGENTS.md
+++ b/AGENTS.md
@ -320,29 +320,21 @@ supported versions contain circuit-group identity, distribution-board components
 separate circuit/component protection records. Portable duplicate imports
 remap component ids and protection-owner references together with the existing
 project graph.
-Project-wide Revit CSV configuration uses
+The current runtime still contains the legacy Revit-CSV/IfcGUID foundation:
-`external-csv-configuration.update`. Its complete expected/target snapshot is
+project configuration, preview, confirmed initial import, external objects and
-persisted through the shared project-command transaction, so create, update,
+the three row-assignment commands. It remains the audited starting point, not
-delete, Undo and Redo are revision-safe. Snapshot schema 5-9, restore and portable
+the Phase-14 target. Do not extend its CSV transport or IFCGUID identity model.
-project duplication preserve the configuration; duplication remaps its internal
+The approved cutover is Linear XLSX with exact case-sensitive Worksharing-ID
-id and project link.
+identity. See `docs/spec/revit-excel-integration-requirements.md` and
-The project page exposes the Revit CSV modal. It edits the complete
+`docs/spec/revit-excel-phase-14-plan.md`.
-transport/column/family-rule configuration through the revision-safe endpoint,
+
-requests a stateless preview and then shows the Phase 14.2 initial-import
+During R1/R2 no database or runtime schema changes are made. R3 will replace
-decisions. Preview responses include all mapped objects, while the UI renders
+the legacy configuration and transport additively, reject non-empty legacy CSV
-only the first 25. No preview or plan creates external objects, rows, revisions
+snapshot/history state with a German error, and introduce snapshot schema 10.
-or server-side drafts.
+The target configuration has no independent version counter; `expectedRevision`
-Phase 14.2 migration `0003` provides one implicit Revit CSV source per project,
+invalidates stale plans, and each import batch stores a configuration copy.
-immutable import batches with original bytes plus the classified cell matrix,
+Only the newest import batch retains workbook bytes and the full matrix; older
-normalized source-room mappings and external objects unique by
+batches retain date, filename, SHA-256 and object count.
 `(sourceId, ifcGuid)`. Source values, planning values and overrides are separate.
 The general external-model repository is read-only; runtime writes belong only
 to typed command adapters. Snapshot/restore and portable project transfer schema versions 5-9
 capture the complete external state and remap every internal UUID and link while
 preserving IFCGUIDs, source values, original bytes and the classified matrix.
 Import batches additionally store the monotonic project CSV configuration
 version introduced by additive migration `0004`; it is distinct from the CSV
 configuration JSON schema version.
 Phase 14.3 migration `0005` adds `CircuitDeviceRow.manualQuantity`, backfills
 existing rows from `quantity` and keeps `quantity` as the materialized total.
 Normal manual row inserts and quantity edits update both values together.
@ -363,37 +355,12 @@ protection and its external object links. Its history-only inverse requires the
 complete unchanged circuit snapshot and exact link set. Redo never recalculates
 the BMK. All three external assignment stores share
 `external-object-assignment.persistence.ts` for compatibility and link safety.
-The read-only
+The current read-only
 `GET /api/projects/:projectId/circuit-lists/:circuitListId/external-objects`
-projection resolves the board through the owned CircuitList and returns only
+projection resolves the board through the owned CircuitList and returns compact
-that board's compact external objects, unassigned first. It exposes no original
+legacy external objects. The target Revit page will load one compact project
-CSV bytes or command payloads and returns an empty list before optional import.
+list and filter/sort it client-side in a virtualized table, without server
-Confirmed initial state is written only through
+pagination or batch blobs in the DTO.
 `external-import.apply-initial`. The command rechecks configuration version,
 original-byte SHA-256, parsed matrix, complete IFCGUID/source values, explicit
 planning overrides and internal project links in the shared transaction. It
 never creates or links a CircuitDeviceRow. Its exact inverse removes the whole
 unchanged external state, and Redo restores the same UUIDs and bytes.
 `POST /api/projects/:projectId/external-csv/initial-import/plan` is a stateless
 read path for the first wizard stage. It rejects projects with an existing
 external source and returns source-room groups, exact room-number suggestions,
 exact family/type groups, projected object values, issue counts and the current
 floor/room/board/ProjectDevice catalogs. It creates no draft, revision or
 domain row. The wide modal renders these groups and catalogs as explicit
 decisions and identifies exact, ambiguous and new room matches. Missing rooms
 and ProjectDevices are created through the reused project forms with mapped
 Revit values as visible defaults. Each catalog creation remains its own project
 command; the wizard adds and selects the result without discarding its plan.
 The dedicated
 `POST /api/projects/:projectId/external-csv/initial-import/apply` endpoint
 retransmits and replans the file against the expected hash, configuration
 version and project revision. It requires one explicit decision per source-room
 and exact family/type group, blocks unclassified families, creates all stable
 external UUIDs server-side and invokes `external-import.apply-initial`.
 Room/default-board and optional ProjectDevice links are supported; CSV circuit
 values remain source-only and every `circuitDeviceRowId` remains null. The UI
 blocks unclassified families, requires a final confirmation and applies the
 whole import as one persistent Undo/Redo step.
 The central revision boundary creates an automatic logical snapshot after each
 25 new revisions and retains only the newest 12 automatic snapshots per
 project. Named snapshots are never removed by this retention policy.
@ -575,70 +542,58 @@ Required operations:
  Uploads are PNG/JPEG/SVG up to 2 MB with a content signature check; the logo
  is served with `nosniff` and a restrictive CSP.
-## Revit / CSV External Model Work
+## Revit / Linear Excel External Model Work
-Status: further Revit work (editor assignment UI, follow-up import, return
+Phase 14 is active and follows
-export) is deferred and will be tackled later. When it resumes, the exchange
+`docs/spec/revit-excel-integration-requirements.md` plus
-stays CSV-based and uses the CSV export/import of the Linear plugin in Revit.
+`docs/spec/revit-excel-phase-14-plan.md`. The old CSV requirements and phases
-The internal Revit/CAD steering committee prefers this over manipulating the
+14.0–14.6 are superseded. Dynamo, Revit API and JSON transport remain excluded.
 model directly through Dynamo. Do not start Dynamo, Revit API or JSON
 transport work. The Linear CSV layout is not yet known: check a sample export
 against the existing project CSV configuration before changing the parser.
 Earlier Dynamo considerations are archived in
 `docs/archive/revit-dynamo-leistungsbilanz-integration-konzept.md`; the
 removed diagnostic scripts remain reachable through the git tag
 `archive/dynamo-vorueberlegungen`.
-When explicitly working on Phase 14, use
+Critical target rules:
 `docs/spec/revit-csv-integration-requirements.md` as the detailed source of
 truth together with the current architecture documents.
-Critical rules:
+- Exchange uses only `.xlsx` files produced and consumed by the Linear plugin.
 - Revit integration remains optional. Import never creates a CircuitDeviceRow,
  Circuit or equipment identifier.
 - Worksharing-ID is the external key and is compared exactly and
  case-sensitively. It stays separate from internal UUIDs and circuit BMKs.
  IfcGUID is optional redundancy, never a key, and duplicate values are only a
  warning.
 - A row without Worksharing-ID is suspicious only when `Familie und Typ` is
  populated. Show a warning and skip it; do not block. Other ID-less rows,
  including the sample summary in column B, are skipped silently.
 - Source, planning and override values remain separate. Existing ProjectDevices
  remain canonical and are never silently changed.
 - Multi-socket objects remain indivisible. Row quantity stays
  `manualQuantity + sum(effectiveQuantity)`.
 - The project configuration has no independent version counter. Preview and
  apply use `expectedRevision`; import batches store a configuration copy.
 - Apply retransmits and parses the workbook. Undo/Redo never reads Excel; they
  apply only stored before/after states.
 - Only the newest import batch retains original bytes and the full matrix;
  older batches retain date, filename, SHA-256 and object count.
 - The Revit object table loads one compact list, filters/sorts in the client and
  renders it virtually; do not add server pagination.
 - Linked objects always follow their row's distribution board. Changing a
  room's default board affects only unassigned objects and is not blocked.
 - Deleting a row, circuit or group warns that X Revit objects become unassigned,
  detaches them in the same command and restores links on Undo. Only deletion
  of referenced rooms and distribution boards is blocked.
 - Missing optional return columns for designation, power, voltage or current
  produce warnings and are skipped. Only missing circuit columns for the
  selected combined/separate mode block export.
 - Missing GZF defaults visibly to 1 without separate confirmation.
 - R2 must generate a changed return workbook from the local sample. The user
  tests it in Linear before R3. If Linear rejects it, propose direct OOXML
  modification of the original workbook before starting R3.
 - All confirmed writes use typed project commands with `expectedRevision`,
  complete inverse data and the shared project-command transaction boundary.
 - Do not add automatic circuit planning, Revit circuit adoption, multi-source
  management, partial imports, PostgreSQL, background jobs or new permissions.
- Revit integration is optional. Do not make imported external data mandatory
+The real sample `docs/spec/kbp-Stromkreis.xlsx` contains project data. It is
-  for projects, rooms, project devices, circuits or device rows.
+gitignored and must never be embedded in tests or committed. Use synthetic
- Parse imports into staging first. Never write CSV rows directly into circuits
+workbooks for automated tests and accept the real file only as an explicit
-  or device rows.
+local path in the reference checker.
 - Keep external object identity separate from internal UUIDs and circuit BMKs.
  `IfcGUID` identifies the external Revit object and must never replace an
  internal UUID or `equipmentIdentifier`.
 - One imported Revit object may exist without a `CircuitDeviceRow`.
  Import, room assignment, distribution-board assignment, classification and
  ProjectDevice linking do not create a row.
 - Create or change a `CircuitDeviceRow` only after an explicit user action in
  the circuit-list editor.
 - Several external objects may link to one `CircuitDeviceRow`, while every
  external object remains individually traceable for follow-up imports and
  object-specific export.
 - Multi-socket Revit objects are indivisible. Their effective quantity may be
  greater than one, but one external object must never be split across circuits.
 - Existing ProjectDevices are canonical project templates and must not be
  overwritten from Revit values. When creating a new ProjectDevice, mapped
  Revit values may prefill the creation form.
 - Store imported source values separately from local planning values and local
  overrides. Imports never silently overwrite local values.
 - Repeated imports match deterministically by project/source and `IfcGUID`.
  New, changed, missing and conflicting objects require preview and explicit
  user decisions.
 - The first implementation assumes one complete Revit model export per project.
  Do not add visible multi-source, linked-model or partial-import management.
 - CSV configuration is project-scoped. Preserve title, header, blank, subtotal
  and unknown rows and columns for the return export.
 - Treat rows without `IfcGUID` as passthrough when they contain no object data.
  Do not report Revit subtotal rows as missing-identity objects.
 - Apply each confirmed import diff through a typed project command with
  `expectedRevision`, complete inverse data and the shared project command
  transaction boundary.
 - External-model state must be added to logical project snapshots and portable
  project transfer when it becomes part of the supported runtime.
 - Keep CSV parsing/serialization in a transport adapter. Domain services must
  not depend on CSV syntax, React, `better-sqlite3` or concrete repositories.
 - Do not implement automatic circuit planning, Dynamo/API exchange,
  PostgreSQL, background jobs or permissions as part of the initial CSV phase.
 Before implementation, audit the current ProjectDevice, CircuitDeviceRow,
 command, snapshot, transfer and editor drag-and-drop paths. Propose concrete
 domain objects and commands before adding migrations.
 ## Cable Sizing Module
@ -733,9 +688,6 @@ for the early-phase power balance by DIN 276 cost group (see
 ## Current Deferred Work
 - Revit/CSV/IFCGUID round-trip (deferred; later via Linear plugin CSV, never
  Dynamo), except when Phase 14 is explicitly requested and
  `docs/spec/revit-csv-integration-requirements.md` is being followed
 - full electrical sizing
 - multi-user/PostgreSQL operation
 - supported production deployment
--- a/README.md
+++ b/README.md
@ -9,11 +9,12 @@ Docker-Server-Stack mit gebautem Anwendungscode und ein separater
 Entwicklungsstack bereit. Ein vollständig unterstütztes Produktionsdeployment
 für mehrere gleichzeitig arbeitende Prozesse und ein vollständig unterstütztes
 Produktionsdeployment fehlen weiterhin. Anmeldung und zwei feste Rollen sind
-vorhanden. Revit-CSV-Konfiguration, Vorschau
+vorhanden. Die bisherige Revit-CSV-/IfcGUID-Grundlage mit Vorschau und
-und bestätigter Erstimport sind implementiert; die Editoroberfläche zur
+bestätigtem Erstimport ist noch im Code vorhanden. Der freigegebene
-Objektzuordnung, Folgeimporte und Rückexport stehen noch aus. Die weitere
+Phase-14-Plan ersetzt sie schrittweise durch den XLSX-Austausch des
-Revit-Arbeit ist zurückgestellt und erfolgt später über den CSV-Export/-Import
+Linear-Plugins mit Worksharing-ID als externem Schlüssel. R0 ist abgeschlossen;
-des Linear-Plugins in Revit.
+R1 aktualisiert die Dokumentation. Editorzuordnung, Folgeimport und Rückexport
 sind noch nicht als neuer Excel-Pfad ausgeliefert.
 ## Unterstützter Arbeitsablauf
@ -40,9 +41,9 @@ des Linear-Plugins in Revit.
 - grobe Leistungsbilanzen für LPH 2/3 nach Kostengruppen führen, mit der
  detaillierten Bilanz vergleichen und einzelne Zeilen als Projektgerät
  übernehmen
- Revit-CSV-Dateien konfigurieren, prüfen und nach expliziter Zuordnung von
+- den vorhandenen Legacy-Revit-CSV-Erstimport verwenden; der Zielpfad über
-  Räumen, Verteilungen und Projektgeräten erstmals importieren; dabei entstehen
+  Linear-XLSX, eigene Revit-Seite, Editorzuordnung, Rückgabe und Folgeimport
-  noch keine Stromkreise oder Gerätezeilen
+  wird gemäß Phase-14-Plan umgesetzt
 ## Technik
@ -177,6 +178,8 @@ vor der Baseline werden nicht unterstützt.
 - [Anmeldung und Benutzerverwaltung](docs/authentication.md)
 - [Entwicklungs- und Contributor-Workflow](docs/development-workflow.md)
 - [Bekannte Einschränkungen](docs/circuit-list-editor-known-limitations.md)
 - [Revit-Integration über Linear-Excel](docs/spec/revit-excel-integration-requirements.md)
 - [Phase-14-Plan R0–R10](docs/spec/revit-excel-phase-14-plan.md)
 - [Roadmap](docs/spec/07-implementation-phases-todo.md)
 Für LLM-gestützte Änderungen enthält [AGENTS.md](AGENTS.md) die verbindlichen
--- a/docs/README.md
+++ b/docs/README.md
@ -31,13 +31,18 @@ ausdrücklich getrennt und dürfen nicht als bereits implementiert verstanden we
 - [Entwicklungs- und Contributor-Workflow](development-workflow.md)
 - [Deployment und Betrieb](deployment.md)
-## Zukunftsarchitektur
+## Aktive Revit-Umstellung
 - [Projektversionen und externer Modellaustausch](project-history-and-external-model-architecture.md)
- [LLM-Kontext für die Revit-Anforderungsplanung](revit-requirements-llm-context.md)
+- [Revit-Integration über Linear-Excel](spec/revit-excel-integration-requirements.md) –
- [Revit-CSV-Anforderungen](spec/revit-csv-integration-requirements.md) –
+  verbindliche Anforderungen für XLSX und Worksharing-ID
-  zurückgestellt; später über den CSV-Export/-Import des Linear-Plugins
+- [Phase-14-Plan R0–R10](spec/revit-excel-phase-14-plan.md) – Status,
- [Phase-14-Audit und Implementierungsplan](spec/revit-csv-phase-14-audit-and-plan.md)
+  Paketgrenzen und Linear-Freigabepunkt nach R2
 - [R0-Bestandsaudit](spec/revit-excel-r0-audit.md)
 - [LLM-Kontext für Phase 14](revit-requirements-llm-context.md)
 ## Zukunftsarchitektur
 - [Zukünftige Dimensionierung](spec/06-future-sizing-and-calculations.md)
 - [Roadmap und Phasen](spec/07-implementation-phases-todo.md)
 - [Aktueller Produkt-Backlog](spec/08-current-product-backlog.md)
--- a/docs/building-structure.md
+++ b/docs/building-structure.md
@ -101,8 +101,8 @@ bleiben.
 ## Offen
 - Revit: Eine Übernahme des Gebäudes aus Revit ist derzeit nicht geplant. Die
-  Revit-Arbeit ist insgesamt zurückgestellt und läuft später über die
+  aktive Phase 14 verwendet Linear-XLSX; das Modell steht der expliziten
-  Linear-CSV; das Modell steht einer späteren CSV-Zuordnung nicht im Weg.
+  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
  und ausdrücklicher Bestätigung einhalten.
--- a/docs/circuit-list-editor-known-limitations.md
+++ b/docs/circuit-list-editor-known-limitations.md
@ -9,9 +9,10 @@
 - 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.
- Further Revit work is deferred; it will later use the CSV export/import of
+- The current Revit/CSV foundation and confirmed initial import are a legacy
-  the Linear plugin in Revit, not Dynamo.
+  starting point. The active Phase-14 plan replaces them with the Linear XLSX
- The Revit/CSV foundation and confirmed initial import are implemented.
+  exchange and exact Worksharing-ID identity.
  R2 must pass a real Linear return-import check before database cutover in R3.
  Existing-row assignment, move and detach plus creation of an external-only
  row in an existing or newly created circuit have atomic persistent commands.
  Their API planning and editor UI, follow-up import, conflict review and return
--- a/docs/current-architecture.md
+++ b/docs/current-architecture.md
@ -640,11 +640,15 @@ 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-CSV-Grundlage
+## Revit-Anbindung: Legacy-Ausgangslage und freigegebener Excel-Cutover
-**Zurückgestellt:** Die weitere Revit-Arbeit wird später angegangen, dann
+Der nachfolgende Abschnitt beschreibt den am Ende von R1 noch vorhandenen
-über den CSV-Export/-Import des Linear-Plugins in Revit statt über Dynamo.
+Legacy-Laufzeitpfad. Er verwendet CSV und IfcGUID und ist die geprüfte
-Details: [Revit-CSV-Anforderungen, Abschnitt 1](spec/revit-csv-integration-requirements.md).
+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).
 Der reine Adapter unter `src/external-model/csv` validiert die projektweite
 Transport- und Mappingkonfiguration und parst UTF-8-CSV verlustarm in eine
@ -774,11 +778,33 @@ 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.
 ## Noch nicht unterstützt
 - Mehrbenutzerbetrieb und Konfliktauflösung
- Editor-Oberfläche für die vorhandene Zuordnungslogik, Folgeimport und
+- Linear-XLSX-Transport, eigene Revit-Seite, Editor-Oberfläche für die
-  strukturtreuer Revit-Rückexport
+  Zuordnungslogik, Folgeimport und strukturtreuer Revit-Rückexport; Umsetzung
  folgt dem R0–R10-Plan
 - vollständige elektrische Dimensionierung
 - Produktionsdeployment
--- a/docs/project-history-and-external-model-architecture.md
+++ b/docs/project-history-and-external-model-architecture.md
@ -9,7 +9,8 @@ This document records architectural direction for future work. It is not a final
 - persist undo/redo across page reloads and application restarts
 - provide a project-wide version history with named restore points
 - preserve an auditable sequence of user, import, migration and restore operations
- support future Revit/CSV round-trips using stable IFCGUID-based links
+- support the Revit/Linear-XLSX round-trip using stable, exact
  Worksharing-ID-based external identity
 - keep the persistence boundary replaceable so PostgreSQL can be adopted later
 ## Separate Concerns
@ -111,11 +112,12 @@ Implemented automatic-snapshot policy:
 - automatic capture and retention run inside the same transaction as the
  triggering project revision
-## Revit / CSV / IFCGUID Round-Trip Direction
+## Revit / Linear Excel Round-Trip Direction
-**Deferred:** further Revit work will be tackled later, then through the
+Phase 14 is active and follows the
-CSV export/import of the Linear plugin in Revit instead of Dynamo. Details:
+[Linear-Excel requirements](spec/revit-excel-integration-requirements.md) and
-[Revit-CSV requirements, section 1](spec/revit-csv-integration-requirements.md).
+[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.
 External model exchange should use explicit staging and link entities instead of writing imported rows directly into circuits.
@ -124,9 +126,12 @@ Conceptual entities:
 - `ExternalModelSource`
  - identifies a Revit/IFC model or another external source within a project
 - `ExternalImportBatch`
-  - file name, checksum, import time, format/version and processing status
+  - file name, checksum, import time, object count and processing status
  - only the latest batch keeps original workbook bytes, matrix and the
    configuration copy; older batches keep date, filename, checksum and count
 - `ExternalModelObject`
-  - stable IFCGUID and optional Revit element identifiers
+  - exact case-sensitive Worksharing-ID as external identity
  - optional IfcGUID as non-unique source redundancy
  - source attributes and last-seen import batch
 - `ExternalObjectLink`
  - explicit relationship to a project device, circuit device row or another future domain entity
@ -137,13 +142,27 @@ Conceptual entities:
 Required behavior:
- IFCGUID uniqueness is scoped to project and external model source.
+- Worksharing-ID uniqueness is scoped to the external source and uses exact,
  case-sensitive comparison. IfcGUID is not a matching key.
 - Parsing writes to staging first.
 - Users preview additions, changes, missing objects and conflicts before applying them.
 - Applying an import creates one project revision and one auditable change set.
 - Imported source values and locally assigned planning values remain distinguishable.
- Export retains IFCGUID and source identifiers so Revit parameters can be matched deterministically.
+- Export retains Worksharing-ID so Linear can match rows deterministically.
- Missing objects and duplicate/conflicting identifiers are reported, never silently reassigned.
+- Missing objects and duplicate/conflicting Worksharing-IDs are reported,
  never silently reassigned.
 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
 Redo operate only on persisted complete before/after states and never parse an
 Excel file.
 Deleting a linked row, circuit or group detaches affected Revit objects in the
 same typed command after an explicit warning; its inverse restores all links.
 Only deleting referenced rooms and distribution boards is blocked. Linked
 objects always derive their board from their row, while a room default-board
 change affects only unassigned objects.
 ## SQLite and PostgreSQL Direction
@ -292,7 +311,8 @@ Remaining constraints before completing project version history:
  boundary; extend it whenever further project mutations are introduced
 - project creation remains initialization at revision zero, while global device
  templates remain outside any single project history
- do not model IFCGUID as an overloaded circuit equipment identifier
+- do not model Worksharing-ID or IfcGUID as an overloaded circuit equipment
  identifier or an internal relation id
 - keep database backup/restore checks separate from project history tests
 ## Deferred Decisions
@ -300,5 +320,6 @@ Remaining constraints before completing project version history:
 - whether large snapshot payloads remain in PostgreSQL or move to object storage
 - branch visualization after undo followed by new edits
 - user/role model and actor attribution
- supported Revit CSV dialects and parameter mapping UI
+- Linear-XLSX compatibility beyond the observed sample and any future
  project-independent mapping profiles
 - PostgreSQL deployment topology and migration date
--- a/docs/revit-requirements-llm-context.md
+++ b/docs/revit-requirements-llm-context.md
@ -1,273 +1,15 @@
-# Kontext für die Revit-Anforderungsplanung
+# LLM-Kontext für die Revit-Integration
-**Zurückgestellt:** Die weitere Revit-Arbeit wird später angegangen, dann
+Die frühere offene Revit-/CSV-Anforderungsplanung ist abgeschlossen und
-über den CSV-Export/-Import des Linear-Plugins in Revit statt über Dynamo.
+abgelöst. Für Arbeiten an Phase 14 sind vollständig zu lesen:
 Details: [Revit-CSV-Anforderungen, Abschnitt 1](spec/revit-csv-integration-requirements.md).
-## Zweck dieser Datei
+- [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)
 - [Aktuelle Systemarchitektur](current-architecture.md)
 - [Projekt-History und externer Modellzustand](project-history-and-external-model-architecture.md)
-Diese Datei ist eine kompakte Übergabe an ein anderes LLM. Sie soll dabei
+Bei Widersprüchen gilt das Anforderungsdokument. CSV, IfcGUID als Schlüssel,
-helfen, gemeinsam mit dem Anwender die fachlichen und technischen Anforderungen
+Dynamo, Revit-API und JSON-Transport sind keine Zielpfade. Der derzeit noch im
-für einen zukünftigen Revit-Datenaustausch zu klären.
+Code vorhandene CSV-Stand ist ausschließlich die in R1 dokumentierte
-
+Legacy-Ausgangslage für den schrittweisen Cutover.
 Die Revit-Schnittstelle ist **noch nicht implementiert**. Das LLM soll zunächst
 den tatsächlichen Arbeitsablauf erfragen, Unklarheiten sichtbar machen und
 daraus eine neue, überprüfbare Arbeitsanweisung erstellen. Es soll weder ein
 Dateiformat noch ein Datenbankschema oder eine UI ungefragt festlegen.
 ## Produkt und fachliches Modell
 Leistungsbilanz ist eine Webanwendung für die elektrische Ausführungsplanung.
 Ihr Kern ist ein tabellenähnlicher Stromkreislisten-Editor für Verteilungen.
 Das unterstützte Laufzeitmodell ist:
 ```text
 Project
 ├── Floor
 │   └── Room
 ├── ProjectDevice
 └── DistributionBoard
    └── CircuitList
        └── CircuitSection
            └── Circuit
                └── CircuitDeviceRow
 ```
 Wichtige fachliche Grenzen:
 - Ein `Circuit` ist nicht dasselbe wie eine Gerätezeile.
 - Ein Stromkreis kann null, eine oder mehrere `CircuitDeviceRow` enthalten.
 - BMK (`equipmentIdentifier`), Schutz- und Kabeldaten gehören zum Stromkreis.
 - Menge, Einzelleistung, Gleichzeitigkeitsfaktor, cosPhi, Raum, Kostengruppe
  und Kategorie gehören zur Gerätezeile.
 - Ein `ProjectDevice` ist eine wiederverwendbare, projektbezogene Vorlage.
 - Eine Gerätezeile kann mit einem Projektgerät verknüpft sein, behält aber
  lokale Werte und ausdrücklich erfasste Abweichungen.
 - Änderungen eines Projektgeräts überschreiben verknüpfte Zeilen niemals
  automatisch. Eine Synchronisierung benötigt Vorschau und Benutzerauswahl.
 - Manuelle, nicht mit einem Projektgerät verknüpfte Gerätezeilen sind regulär
  erlaubt.
 - Bestehende BMKs und stabile UUIDs dürfen nicht automatisch verändert werden.
 - Neunummerierung ist immer eine ausdrückliche Benutzeraktion.
 - `IFCGUID` darf nicht als BMK oder als Ersatz für eine interne UUID verwendet
  werden.
 Für einen späteren Revit-Austausch besonders relevante Daten sind:
 - Projekt: Name, interne/externe Projektnummer, Bauherr, Beschreibung,
  Kennzeichnung als öffentliches Gebäude und Projektspannungen.
 - Geschoss und Raum: interne UUID, Name beziehungsweise Raumnummer und
  Raumname.
 - Verteilung: interne UUID, Name, Etage, Netzart und Gleichzeitigkeitsfaktor.
 - Stromkreis: interne UUID, BMK, Anzeigename, Bereich, Schutz-, Kabel-,
  Spannungs-, Steuerungs-, Status- und Bemerkungsdaten.
 - Gerätezeile: interne UUID, optionale Projektgeräteverknüpfung, Name,
  Anzeigename, Phasenart, Anschlussart, Kostengruppe, Kategorie, Geschoss,
  Raum, Menge, Einzelleistung, Gleichzeitigkeitsfaktor, cosPhi und Bemerkung.
 - Projektgerät: interne UUID sowie die wiederverwendbaren Gerätewerte.
 Die Phasenart ist fachlich `1-phasig` oder `3-phasig`. Die Spannung wird daraus
 und aus den Projekteinstellungen abgeleitet; freie Sonderspannungen sind im
 aktuellen Produkt nicht vorgesehen.
 ## Aktuelle technische Architektur
 - Frontend: Next.js App Router, React und TypeScript unter `src/app` und
  `src/frontend`.
 - API: Express und Zod unter `src/server`.
 - Fachregeln und typisierte Commands: `src/domain`.
 - Persistenz: SQLite, Drizzle und Repository-Adapter unter `src/db`.
 - Laufzeitkomposition konkreter Repositories:
  `src/server/composition`.
 - Lokaler Betrieb: Browser/Next.js auf Port 3001, Express-API auf Port 3000,
  SQLite-Datei unter `data/leistungsbilanz.db`.
 - Docker Compose wird für die lokale Entwicklung unterstützt.
 - PostgreSQL und Mehrbenutzerbetrieb sind noch nicht umgesetzt.
 Der zentrale Editor liegt unter:
 ```text
 src/app/projects/[projectId]/circuit-lists/[circuitListId]/tree-edit/page.tsx
 src/frontend/components/circuit-tree-editor.tsx
 ```
 Frontend-Aktionen werden als validierte API-Commands ausgeführt. Fachregeln
 liegen in Domain-Services; konkrete SQLite-Zugriffe bleiben in
 Persistenzadaptern. Neue Revit-Fachlogik darf deshalb nicht direkt von
 `better-sqlite3`, React-Komponenten oder globalen Datenbankinstanzen abhängen.
 ## Revisionen, Undo/Redo und Sicherungspunkte
 Alle normalen projektbezogenen Änderungen laufen über eine gemeinsame
 Command- und Transaktionsgrenze:
 ```text
 Fachänderung + inverses Kommando + Revision + Undo/Redo-Übergang
 ```
 Diese Bestandteile werden atomar geschrieben oder vollständig zurückgerollt.
 Jedes Projekt besitzt eine monoton steigende `currentRevision`. Schreibbefehle
 geben die erwartete Revision mit, damit veraltete Clients keine neueren
 Änderungen überschreiben.
 Undo/Redo ist projektweit persistent und funktioniert nach Reload oder
 Anwendungsneustart. Zusätzlich gibt es:
 - eine unveränderliche Revisions-Timeline;
 - benannte und automatische logische Projektsnapshots;
 - wiederherstellbare Snapshots mit Prüfsumme;
 - einen portablen, versionierten JSON-Projekttransfer.
 Ein angewendeter Revit-Import muss später dieselbe Integritätsgrenze verwenden:
 Die bestätigten Änderungen sollen als ein nachvollziehbarer Projekt-Command
 beziehungsweise als ein fachlich definierter Änderungssatz atomar,
 revisioniert und rückgängig machbar sein.
 ## Klare Abgrenzung zum vorhandenen JSON-Projekttransfer
 Der vorhandene JSON-Export/-Import überträgt den vollständigen internen
 Projektzustand. Er dient Sicherung, Wiederherstellung und Duplizierung eines
 Projekts innerhalb von Leistungsbilanz.
 Dieser Projekttransfer ist **kein** Revit-Austauschformat. Er enthält interne
 Strukturen und UUIDs und soll nicht ohne bewusste Entscheidung als Grundlage
 für CSV-Dateien oder Revit-Parameter verwendet werden.
 Der zukünftige Revit-Workflow soll dagegen externe Modellobjekte anhand stabiler
 externer Identitäten wiedererkennen, ausgewählte Planungswerte zuordnen und
 Ergebnisse so exportieren, dass Revit sie wieder den richtigen Objekten
 zuweisen kann.
 ## Bereits vereinbarte Leitplanken für den externen Modellaustausch
 Diese Punkte gelten als Architekturvorgaben, noch nicht als fertiges
 Implementierungsdesign:
 - Ein Import schreibt niemals ungeprüft direkt in Stromkreise oder
  Gerätezeilen.
 - Eingelesene Daten landen zuerst in einem Staging-/Vorschaubereich.
 - Vor der Übernahme werden neue, geänderte, fehlende, doppelte und
  widersprüchliche Objekte angezeigt.
 - Wiederholte Importe müssen Objekte deterministisch anhand der externen Quelle
  und einer stabilen Identität, voraussichtlich IFCGUID, erkennen.
 - Die Eindeutigkeit einer IFCGUID ist mindestens auf Projekt und externe
  Modellquelle begrenzt; die genaue Quellendefinition ist noch zu klären.
 - Importierte Quellwerte und lokal in Leistungsbilanz geplante Werte müssen
  unterscheidbar bleiben.
 - Lokale Planungswerte dürfen niemals still überschrieben werden.
 - Verknüpfungen zwischen externen Objekten und internen Fachobjekten müssen
  ausdrücklich modelliert werden.
 - Fehlende oder widersprüchliche Identitäten werden gemeldet und niemals
  automatisch einem anderen Objekt zugeordnet.
 - Ein Export bewahrt IFCGUID und erforderliche Quellidentitäten, damit Revit
  die Werte deterministisch zurückschreiben kann.
 - Ein Export bezieht sich auf eine bekannte Projektrevision.
 - Große Datenmengen allein erzwingen noch keinen Wechsel von SQLite zu
  PostgreSQL. PostgreSQL wird relevant bei Mehrbenutzerbetrieb, zentralem
  Serverbetrieb oder unabhängigen Hintergrundjobs.
 Als mögliche, aber noch nicht beschlossene Konzepte wurden bisher genannt:
 - `ExternalModelSource`
 - `ExternalImportBatch`
 - `ExternalModelObject`
 - `ExternalObjectLink`
 - `ExternalParameterMapping`
 - `ExternalExportBatch`
 Diese Namen beschreiben Verantwortlichkeiten. Das andere LLM darf sie
 hinterfragen und verbessern, soll sie aber nicht als bereits vorhandene
 Tabellen behandeln.
 ## Auftrag an das andere LLM
 Erarbeite die Anforderungen dialogorientiert mit dem Anwender. Beginne mit dem
 realen Ablauf in Revit und kläre danach schrittweise mindestens:
 1. Welche Revit-Objekte beziehungsweise Kategorien werden exportiert?
 2. Wie entsteht die Ausgangsdatei in Revit und wie sieht sie technisch aus
   (CSV-Dialekt, Trennzeichen, Encoding, Dezimalformat, Kopfzeilen,
   Revit-Versionen)?
 3. Welche Identitäten stehen zur Verfügung: IFCGUID, Revit `ElementId`,
   Typ-ID, Modell-/Dateikennung oder weitere Schlüssel?
 4. Wie werden Hauptmodell, Teilmodelle, verknüpfte Modelle, Modellkopien und
   aktualisierte Revit-Dateien unterschieden?
 5. Welche Parameter kommen aus Revit und welche Werte werden ausschließlich in
   Leistungsbilanz geplant?
 6. Welche internen Ziele können externe Objekte erhalten: Projektgerät,
   Gerätezeile, Stromkreis, Raum, Verteilung oder weitere Entitäten?
 7. Werden externe Objekte einzeln oder gesammelt einem Stromkreis,
   Projektgerät, Raum oder einer Verteilung zugeordnet?
 8. Welche Werte sollen nach Revit zurückgeschrieben werden, in welchen
   Einheiten und unter welchen Revit-Parameternamen?
 9. Muss die ursprüngliche Datei einschließlich unbekannter Spalten,
   Zeilenreihenfolge und Formatierung erhalten werden, oder darf eine neue
   Rückgabedatei erzeugt werden?
 10. Wie sollen Spalten-/Parametermappings erstellt, gespeichert,
    wiederverwendet und zwischen Projekten geteilt werden?
 11. Was gilt bei erneutem Import für neue, geänderte, gelöschte, verschobene,
    doppelte oder nicht mehr sichtbare Revit-Objekte?
 12. Wer gewinnt bei Konflikten zwischen neuem Revit-Wert und lokaler Änderung?
    Welche Konflikte dürfen automatisch gelöst werden und welche benötigen
    eine Auswahl?
 13. Welche Vorschau, Filter, Sammelaktionen und Bestätigungen benötigt der
    Anwender vor der Übernahme?
 14. Welche fachlichen Validierungen und Pflichtfelder müssen eine Übernahme
    verhindern oder nur eine Warnung erzeugen?
 15. Welche Dateigrößen, Objektzahlen und Laufzeiten sind realistisch?
 16. Müssen Import und Export synchron im Browser laufen oder werden später
    Hintergrundjobs benötigt?
 17. Welche Informationen müssen für Nachvollziehbarkeit, Undo/Redo,
    Versionshistorie und Support gespeichert werden?
 18. Welche konkreten End-to-End-Beispiele und Fehlerfälle dienen als
    Abnahmekriterien?
 Stelle Rückfragen in kleinen, zusammenhängenden Blöcken. Unterscheide in deinen
 Notizen ausdrücklich:
 - vom Anwender bestätigte Anforderungen;
 - sinnvolle Vorschläge;
 - offene Entscheidungen;
 - technische Folgerungen;
 - bewusst nicht betrachtete spätere Ausbaustufen.
 ## Erwartetes Ergebnis der Anforderungsrunde
 Erstelle am Ende eine neue Arbeitsanweisung für das implementierende LLM. Sie
 soll mindestens enthalten:
 - Ziel, Umfang und ausdrücklich ausgeschlossene Funktionen;
 - vollständigen Anwenderworkflow für Erstimport, Zuordnung, Folgeimport und
  Rückexport;
 - vereinbartes Dateiformat mit einem anonymisierten Beispiel;
 - Feld- und Einheitenmapping einschließlich Richtung und Datenhoheit;
 - Identitäts-, Matching- und Quellmodell;
 - Regeln für neue, geänderte, fehlende und doppelte Objekte;
 - Konflikt-, Validierungs- und Freigaberegeln;
 - UI-Ablauf für Staging, Vorschau, Zuordnung und Bestätigung;
 - Anforderungen an Revision, Atomarität, Undo/Redo und Audit;
 - vorgeschlagene Modul- und Persistenzgrenzen, ohne bestehende
  Architekturregeln zu umgehen;
 - schrittweise Implementierungsphasen mit überprüfbaren Abnahmekriterien;
 - offene Punkte, die vor dem jeweiligen Implementierungsschritt geklärt werden
  müssen.
 Die Arbeitsanweisung soll noch keinen Code enthalten. Sie muss klar markieren,
 welche Entscheidungen der Anwender tatsächlich getroffen hat und welche Teile
 nur Architekturvorschläge des LLM sind.
 ## Weiterführende Projektdokumente
 - `AGENTS.md` – verbindliche Domänen- und Implementierungsregeln
 - `docs/current-architecture.md` – vollständiger aktueller Laufzeit- und
  Command-Pfad
 - `docs/project-history-and-external-model-architecture.md` – bisherige
  Zukunftsrichtung für Versionierung, externes Modell und PostgreSQL
 - `docs/spec/01-domain-context.md` – fachlicher Kontext
 - `docs/spec/03-data-model-concept.md` – Datenmodellkonzept
 - `docs/spec/05-linked-devices-and-sync.md` – Regeln für Projektgeräte und
  kontrollierte Synchronisierung
 - `docs/spec/07-implementation-phases-todo.md` – Roadmap, insbesondere Phase 14
 - `docs/circuit-list-editor-known-limitations.md` – noch nicht implementierte
  Funktionen
--- a/docs/spec/07-implementation-phases-todo.md
+++ b/docs/spec/07-implementation-phases-todo.md
@ -532,36 +532,34 @@ Acceptance criteria:
 ## Phase 14: External Model Round-Trip
-**Zurückgestellt:** Die weitere Revit-Arbeit wird später angegangen, dann
+Status: R0 ist mit Korrekturen freigegeben; R1 stellt die Dokumentation auf
-über den CSV-Export/-Import des Linear-Plugins in Revit statt über Dynamo.
+Linear-XLSX und Worksharing-ID um. Die frühere CSV-Planung 14.0–14.6 ist
-Details: [Revit-CSV-Anforderungen, Abschnitt 1](revit-csv-integration-requirements.md).
+abgelöst und wird nicht fortgeschrieben.
-Status: Phase 14.2 (persistente externe Objekte und bestätigter Erstimport) ist
+Verbindliche Quellen:
 implementiert. Editor-Zuordnung, Rückexport und Folgeimport folgen. Siehe
 [Phase-14-Audit und Implementierungsplan](revit-csv-phase-14-audit-and-plan.md)
 und die verbindlichen
 [Revit-CSV-Anforderungen](revit-csv-integration-requirements.md).
-Goal:
+- [Revit-Integration über Linear-Excel](revit-excel-integration-requirements.md)
 - [R0–R10-Plan](revit-excel-phase-14-plan.md)
 - [R0-Bestandsaudit](revit-excel-r0-audit.md)
-Exchange model objects and planning parameters with Revit through CSV (Linear plugin export/import).
+Die Umsetzung erfolgt ausschließlich in den Paketen R0–R10. R2 endet mit
 einer aus der realen Musterdatei erzeugten Rückgabedatei. Der Nutzer muss sie
 erfolgreich in Linear importieren, bevor R3 beginnt. Bei einem Fehlschlag wird
 zuvor eine direkte OOXML-Änderung des Originalworkbooks als Alternative
 vorgelegt.
-Tasks:
+Kernabnahme der Phase:
- model external sources, import batches and stable IFCGUID objects
+- Worksharing-ID ist der exakte, case-sensitive externe Schlüssel;
- stage and validate imports before applying them
+- XLSX-Kopfkommentare, Struktur, Formate und unbekannte Spalten bleiben beim
- show additions, changes, missing objects and conflicts
+  Rückexport erhalten;
- link external objects explicitly to project-domain entities
+- Import erzeugt keine Rows und überschreibt keine lokale Planung still;
- apply an import as one auditable project revision
+- Zuordnung, Löschung, Folgeimport und Undo/Redo sind atomar und nach Neustart
- configure inbound and outbound parameter mappings
+  reproduzierbar;
- export against a known project revision while preserving IFCGUID
+- Undo/Redo liest keine Excel-Datei;
-
+- nur der letzte Importbatch enthält Workbook und Matrix vollständig;
-Acceptance criteria:
+- mehrere Tausend Objekte bleiben über eine clientseitig gefilterte,
-
+  virtualisierte Liste bedienbar.
 - repeated imports match objects deterministically by source and IFCGUID
 - imports never silently overwrite local planning values
 - users approve the diff before it changes the project
 - exported data can be assigned back to the correct Revit objects
 PostgreSQL should be introduced when shared multi-user operation, background jobs or operational scale justify it. External-object count alone does not require an immediate migration.
--- a/docs/spec/08-current-product-backlog.md
+++ b/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/CSV/IFCGUID round-trip follows the distribution-board component
+The Revit/Linear-XLSX round-trip is now the separately planned active Phase 14.
-foundation as a separate jointly planned phase and must not be inferred from
+It uses exact Worksharing-ID identity and must not be inferred from these
-these tasks. It is currently deferred and will later use the CSV
+unrelated backlog tasks. See
-export/import of the Linear plugin in Revit, not Dynamo.
+[the R0–R10 plan](revit-excel-phase-14-plan.md).
--- a/docs/spec/revit-csv-integration-requirements.md
+++ b/docs/spec/revit-csv-integration-requirements.md
--- a/docs/spec/revit-csv-phase-14-audit-and-plan.md
+++ b/docs/spec/revit-csv-phase-14-audit-and-plan.md
@ -1,406 +1,8 @@
-# Phase 14: Audit- und Implementierungsplan für die Revit-CSV-Anbindung
+# Abgelöst: alter Phase-14-CSV-Plan
-## Status
+Die Phasen 14.0–14.6 und ihre Erledigt-Markierungen sind abgelöst. Für die
 Umstellung auf Linear-Excel gelten der [R0–R10-Plan](revit-excel-phase-14-plan.md)
 und die [neuen Anforderungen](revit-excel-integration-requirements.md).
-**Zurückgestellt:** Die weitere Revit-Arbeit wird später angegangen, dann
+Der historische Inhalt bleibt im Git-Verlauf bis einschließlich Commit
-über den CSV-Export/-Import des Linear-Plugins in Revit statt über Dynamo.
+`ae318a5` erhalten und darf nicht fortgeschrieben werden.
 Details: [Revit-CSV-Anforderungen, Abschnitt 1](revit-csv-integration-requirements.md).
 Phase 14.0 ist abgeschlossen und freigegeben. Dieses Dokument beschreibt den
 gegen den aktuellen Code geprüften Zielzuschnitt. Phase 14.1 ist abgeschlossen.
 Phase 14.2 hat mit den externen Domänenverträgen, Identitätsregeln und dem
 additiven Persistenzschema begonnen; eine bestätigte Importübernahme existiert
 noch nicht.
 Fachliche Quelle bleibt
 [Revit-CSV-Integration – Anforderungen und Implementierungsanweisung](revit-csv-integration-requirements.md).
 Dieses Dokument konkretisiert dafür Namen, Modulgrenzen, Persistenz und die
 Reihenfolge kleiner Arbeitspakete.
 ## Ergebnis des Bestandsaudits
 ### Beibehalten
 - Das Circuit-First-Modell bleibt unverändert: Ein `Circuit` besitzt null bis
  viele `CircuitDeviceRow`-Datensätze.
 - `ProjectDevice` bleibt die kanonische projektweite Vorlage. Ein Import darf
  diese Datensätze weder erzeugen noch ändern, solange der Nutzer dies nicht
  ausdrücklich bestätigt.
 - `CircuitDeviceRow.linkedProjectDeviceId` bleibt die optionale Verbindung
  zwischen einer Gerätezeile und genau einer Projektgerätevorlage.
 - Die bestehenden getrennten Drag-and-drop-Pfade für Projektgeräte,
  Gerätezeilen und Stromkreise bleiben bestehen. Externe Objekte erhalten einen
  vierten, fachlich eigenen Pfad.
 - Alle bestätigten Änderungen verwenden typisierte Commands mit
  `expectedRevision`, vollständiger Gegenrichtung und
  `project-command-transaction.persistence.ts` als gemeinsamer
  Transaktionsgrenze.
 - Snapshot-Erfassung, Restore und Projektduplikat bleiben explizite Adapter mit
  fester Fremdschlüsselreihenfolge und UUID-Remapping.
 - SQLite und die heutige Server-Komposition bleiben der einzige unterstützte
  Laufzeitadapter.
 ### Erweitern oder gezielt refaktorieren
 - `ProjectStateSnapshot` und der portable Projekttransfer werden additiv um den
  bestätigten externen Projektzustand erweitert. Bereits veröffentlichte
  Snapshot-Versionen werden nicht verändert.
 - Der Command-Dispatcher erhält schmale Stores für externe Konfiguration,
  Importübernahme, Objektplanung und Row-Zuordnung. Controller erhalten keine
  konkreten SQLite-Abhängigkeiten.
 - Der Stromkreislisteneditor erhält später einen separaten Drawer für
  unzugeordnete externe Objekte. Die bestehende Projektgeräteauswahl wird nicht
  dafür zweckentfremdet.
 - Vor der ersten externen Row-Zuordnung wird die Mengenhoheit einer
  `CircuitDeviceRow` explizit gemacht; Details stehen unter „Mengenmodell“.
 ### Hinzufügen
 - verlustarmer CSV-Transportadapter außerhalb von React und Circuit-Domain;
 - projektweite, versionierte Revit-CSV-Konfiguration;
 - eine zunächst implizite externe Modellquelle je Projekt;
 - Importbatches einschließlich Originaltransport und akzeptiertem
  Konfigurationsstand;
 - persistente externe Objekte mit `IfcGUID`, getrennten Quell- und
  Planungswerten und einzelnem Lebenszyklus;
 - Quellraum-Mappings auf interne Räume und Standardverteilungen;
 - explizite Verknüpfungen zu `ProjectDevice`, `CircuitDeviceRow` und optionaler
  abweichender Verteilung;
 - Vorschau-, Konflikt- und Exportprojektionen als reine Anwendungsservices;
 - fokussierte Parser-, Command-, Transaktions-, Snapshot-, Transfer- und
  End-to-End-Tests.
 ### Entfernen
 Es existiert kein unterstützter Revit-Laufzeitpfad. Deshalb wird in Phase 14
 kein bestehender Fachpfad entfernt und keine Legacy-Kompatibilität eingeführt.
 ## Vorgeschlagenes Domänenmodell
 Die Namen sind ab Phase 14.1 verbindliche Arbeitsnamen. Tabellen verwenden die
 jeweilige englische Pluralform in `snake_case`.
 ### `ExternalModelSource`
 - stabile interne UUID;
 - `projectId`;
 - technischer Name und Quelltyp `revit_csv`;
 - der zuletzt bestätigte Importbatch wird aus der geordneten Batchhistorie
  abgeleitet und nicht als redundanter Zeiger gespeichert.
 In der ersten Ausbaustufe wird genau eine Quelle je Projekt automatisch
 angelegt. Es gibt bewusst keine sichtbare Mehrquellenverwaltung. Die
 Eindeutigkeit eines externen Objekts ist trotzdem von Anfang an
 `(sourceId, ifcGuid)`.
 ### `ExternalCsvConfiguration`
 - stabile UUID und `projectId` mit genau einer aktiven Konfiguration;
 - Konfigurationsschema-Version;
 - CSV-Dialekt: Encoding, BOM, Trennzeichen, Zeilenende, Quote-Zeichen,
  Dezimalformat und Kopfzeilenerkennung;
 - exakte Spaltenzuordnung;
 - geordnete, exakte Familie-und-Typ-Regeln;
 - monotoner Konfigurationsstand.
 Eine Änderung ersetzt den vollständigen erwarteten Konfigurationssnapshot in
 einem Command. Jeder bestätigte Importbatch speichert zusätzlich den dabei
 verwendeten Konfigurationssnapshot. Damit bleiben ältere Importe erklärbar,
 ohne eine zweite veränderbare Historientabelle einzuführen.
 ### `ExternalImportBatch`
 - stabile UUID, `projectId`, `sourceId`, Importart und Zeitstempel;
 - Dateiname, SHA-256 und zugehörige Projektrevision;
 - verwendete monotone Konfigurationsversion und vollständiger
  Konfigurationssnapshot;
 - Originaldatei als Bytes;
 - verlustarme logische Zellmatrix mit Zeilenklassen und Dialektmetadaten.
 Die Kombination aus Originalbytes und Matrix ist bewusst gewählt: Die Bytes
 belegen den unveränderten Eingang, die Matrix erlaubt einen gezielten
 Rückexport einzelner gemappter Objektzellen, ohne unbekannte Spalten,
 Titelzeilen, Leerzeilen oder Summenzeilen neu zu interpretieren.
 ### `ExternalRoomMapping`
 - stabile UUID, `sourceId` und normalisierter Quellraumschlüssel;
 - Quellgeschoss-, Raumnummer- und Raumname-Snapshot;
 - optionales `roomId`;
 - optionale `defaultDistributionBoardId`.
 Das Mapping bleibt Teil der optionalen externen Integration. Dadurch erhält
 das allgemeine Raummodell keine Revit-spezifische Pflichtbeziehung.
 ### `ExternalModelObject`
 - stabile interne UUID, `projectId`, `sourceId` und unveränderte `ifcGuid`;
 - letzter gesehener und letzter akzeptierter Importbatch;
 - akzeptierte Quellwerte getrennt als strukturierter Snapshot;
 - lokale Planungswerte für Anzeigename, Kategorie, Anschlussart, wirksame
  Menge, Leistung je Einheit, Gleichzeitigkeitsfaktor, `cosPhi`, Kostengruppe
  und Bemerkung;
 - explizite Override-Metadaten;
 - optionales `externalRoomMappingId`;
 - optionale abweichende `distributionBoardId`;
 - optionales `linkedProjectDeviceId`;
 - optionales `circuitDeviceRowId`;
 - Anwesenheitsstatus für bestätigte fehlende Objekte.
 Die n:1-Beziehung entsteht durch `circuitDeviceRowId` am Einzelobjekt: Viele
 einzeln nachverfolgbare IFC-Objekte dürfen genau einer Gerätezeile zugeordnet
 sein. Eine Mehrfachsteckdose bleibt ein einzelnes Objekt und trägt ihre
 wirksame Menge größer eins.
 Konflikte werden soweit möglich aus akzeptiertem Quellstand, neuem
 Vorschaustand und lokalen Overrides berechnet. Nur ein vom Nutzer bestätigter
 Anwesenheits- oder Planungszustand wird persistiert.
 ## Mengenmodell der Gerätezeile
 Die heutige `CircuitDeviceRow.quantity` unterscheidet nicht zwischen manueller
 Menge und verknüpften IFC-Objekten. Ohne Erweiterung könnte das Lösen eines
 Objekts manuelle Mengen löschen oder doppelt zählen.
 Vor Phase 14.3 wird deshalb `manualQuantity` ergänzt:
 ```text
 quantity = manualQuantity
         + Summe(effectiveQuantity aller verknüpften ExternalModelObjects)
 ```
 - Bei der Migration erhält jede bestehende Row
  `manualQuantity = quantity`; ihr Ergebnis bleibt unverändert.
 - Eine ausschließlich aus externen Objekten erstellte Row startet mit
  `manualQuantity = 0`.
 - `quantity` bleibt zunächst der materialisierte Gesamtwert für bestehende
  Berechnungen, Filter und Exporte und wird im selben Command aktualisiert.
 - Ein externes Objekt wird nie geteilt und kann höchstens einer Row zugeordnet
  sein.
 - Objekte dürfen nur aggregiert werden, wenn die rowbestimmenden lokalen Werte
  übereinstimmen. Widersprüchliche Werte werden in der ersten Ausbaustufe nicht
  automatisch vereinheitlicht, sondern benötigen getrennte Rows oder eine
  ausdrückliche Nutzerentscheidung.
 - Eine bestehende Row mit manueller Menge darf externe Objekte aufnehmen; beim
  Lösen bleibt der manuelle Anteil erhalten.
 Für die UI vor Phase 14.3 bleibt noch festzulegen, ob eine nach dem Lösen leere
 Row stehen bleibt oder nach gesonderter Bestätigung gelöscht wird. Ein stiller
 Row-Lebenszyklus ist ausgeschlossen.
 ## Command-Schnittstellen
 Alle Payloads tragen `schemaVersion: 1`, vollständige erwartete und gewünschte
 Snapshots und werden mit der aktuellen Projektrevision geplant. Große
 Importcommands dürfen umfangreich sein; sie müssen für Redo deterministisch
 bleiben und dürfen spätere Quellstände nicht erneut auswerten.
 - `external-csv-configuration.update`: vollständige projektweite
  Konfiguration ändern.
 - `external-import.apply-initial`: Quelle, Batch, Raum-Mappings, externe
  Objekte und bestätigte Links atomar einfügen.
 - `external-import.apply-follow-up`: neuen Batch und die vollständigen
  erwarteten/gewünschten Änderungen bestehender, neuer und fehlender Objekte
  atomar übernehmen.
 - `external-model-object.update-planning`: lokale Werte und Overrides eines
  oder mehrerer Objekte ändern.
 - `external-model-object.update-project-device-link`: ProjectDevice-Links
  explizit setzen oder lösen, ohne das ProjectDevice zu verändern.
 - `external-object.update-row-assignment`: Ein oder mehrere Objekte einer
  bestehenden Row zuweisen, zwischen bestehenden Rows verschieben oder lösen
  und alle betroffenen materialisierten Mengen atomar aktualisieren.
 - `external-object.assign-to-new-row`: stabile neue Row einfügen,
  Objekte verknüpfen und gegebenenfalls den Reserve-Status aktualisieren.
 - `external-object.assign-to-new-circuit`: stabilen Circuit samt Schutz,
  Row und Objektlinks in einem Schritt einfügen. Das geplante BMK wird im
  Command gespeichert und bei Redo nicht neu berechnet.
 - `external-model-object.delete-missing`: nur ausdrücklich bestätigte,
  weiterhin unveränderte fehlende Objekte löschen.
 Die Erzeugung eines neuen `ProjectDevice` verwendet weiterhin den vorhandenen
 `project-device.insert`-Command. Revit-Werte füllen lediglich das sichtbare
 Formular vor; erst dessen Bestätigung erzeugt die Vorlage. CSV-Vorschau und
 Rückexport sind reine Leseoperationen. Append-only Exportnachweise verändern
 keine Projektrevision und laufen über einen eigenen Audit-Store.
 ## Snapshot-, Transfer- und Migrationsfolgen
 - Phase 14.1 führt Migration `0002` für die Konfiguration ein und erhöht das
  Project-State-Snapshot-Schema additiv von 2 auf 3. Der Upgrader von Version 2
  ergänzt `externalCsvConfiguration = null`.
 - Phase 14.2 führt Migration `0003` für Quelle, Batches, Raum-Mappings und
  Objekte ein und erhöht das Snapshot-Schema von 3 auf 4. Der Upgrader ergänzt
  leere externe Collections.
 - Phase 14.3 führt die additive Row-Spalte `manual_quantity` ein. Bestehende
  Werte werden einmalig aus `quantity` übernommen.
 - Snapshot-Capture und Restore erhalten Konfiguration, Quelle, bestätigte
  Batches, Raum-Mappings und Objekte in expliziter FK-Reihenfolge.
 - Beim Projektduplikat werden alle neuen internen UUIDs und internen Links
  remappt. `IfcGUID`, Quellwerte, Transportmatrix und unbekannte CSV-Inhalte
  bleiben unverändert.
 - Der Transfer-Envelope kann Version 1 bleiben; die enthaltene
  Project-State-Schema-Version wird additiv erhöht.
 - Vorhandene Migrationen und Snapshot-Upgrader werden nicht editiert.
 ## Implementierungsfolge
 ### 14.1 – CSV-Konfiguration und reine Vorschau
 1. Transport-Domainverträge, Dialekt- und Mappingvalidatoren sowie kleine
   synthetische Fixtures ergänzen. **Erledigt.**
 2. Zustandsfreien Parser und Serializer mit Round-trip-Tests für UTF-8-BOM,
   CRLF, Semikolon, vollständige Quotierung, Kopfzeile in Zeile 2 sowie
   Titel-, Leer-, Objekt- und Passthrough-Zeilen implementieren. **Erledigt für
   synthetische Testdaten; die Referenzdatei steht noch aus.**
 3. Konfiguration über Migration, Snapshot v3, Transfer und den Command
   `external-csv-configuration.update` persistieren. **Erledigt.**
 4. Vorschau-Endpunkt und deutschen Projekt-Wizard ergänzen. **Erledigt:**
   Konfigurations-Read/Write- und zustandsfreier Vorschau-Endpunkt sowie das
   deutsche Konfigurations-/Vorschaumodal. Der Server speichert keinen Entwurf: Bei
   Bestätigung wird die Datei erneut übertragen, erneut geparst und ihr Hash
   gegen die Vorschau geprüft.
 **Phase 14.1 ist damit technisch abgeschlossen.** Die fachliche GUI-Abnahme
 erfolgt vor Beginn der persistenten externen Objekte aus Phase 14.2.
 Abnahme: fokussierte Tests, vollständige Tests und alle vorgeschriebenen
 Build-/Typecheck-Schritte. Die lokal bereitgestellte Referenz-CSV wird mit
 `npm run revit:verify-reference` auf 897 Objektzeilen, 211 nichtleere
 Passthrough-Summenzeilen und einen bytegleichen Round-trip geprüft. Da die
 Referenzdatei reale Modelldaten enthalten kann, wird sie nicht automatisch in
 einen Commit aufgenommen.
 ### 14.2 – Persistente Objekte und Erstimport
 1. Schema, Repositories und reine Identitäts-/Matchingregeln ergänzen.
   **Erledigt:** Migration `0003`, vollständiger externer Read-State sowie
   exaktes IFCGUID-, Raum- und Familie-und-Typ-Matching sind vorhanden. Es gibt
   weiterhin keinen Import-Write außerhalb eines Commands.
 2. Snapshot v4, Restore und Projektduplikat samt UUID-Remapping ergänzen.
   **Erledigt:** Version 3 wird mit leerem externem Zustand hochgestuft;
   Capture, Restore, Undo/Redo und beide Transfermodi erhalten Originalbytes,
   Matrix und sämtliche internen Links. Duplikate remappen alle internen UUIDs,
   lassen IFCGUID und Quelltransport jedoch unverändert.
 3. Erstimport-Command mit echten SQLite-Commit-/Rollback-Tests ergänzen.
   **Erledigt:** `external-import.apply-initial` wechselt ausschließlich
   zwischen leerem und vollständig bestätigtem externem Zustand. Er prüft
   Konfigurationsversion, Original-Hash, erneut geparste Matrix, vollständige
   IFCGUID-Menge, Quellwerte, explizite Overrides und projektinterne Links.
   Der Command verbietet CircuitDeviceRow-Links, ist ein atomarer Undo-Schritt
   und verwendet für Redo dieselben UUIDs und Bytes. Migration `0004` ergänzt
   die zuvor noch fehlende monotone Konfigurationsversion am Batch; `0003`
   bleibt unverändert.
 4. Raum-, Verteilungs-, Klassifizierungs- und ProjectDevice-Schritte im Wizard
   ergänzen; der Import selbst erzeugt keine CircuitDeviceRow. **Erledigt:**
   Der zustandsfreie Planungs-Endpunkt liefert gruppierte Quellräume mit
   exaktem Raumnummernvorschlag, Familie-und-Typ-Gruppen, Objektvorschläge,
   Warnungszahlen sowie vorhandene Ebenen, Räume, Verteilungen und
   ProjectDevices. Er blockiert nach einem bereits bestätigten Erstimport und
   schreibt weder Entwurf noch Projektzustand. Der dedizierte
   Endpunkt verlangt denselben Datei-Hash und Konfigurationsstand wie die
   Planung, vollständige Entscheidungen für alle Quellräume und exakten
   Familie-und-Typ-Gruppen und baut daraus serverseitig stabile UUIDs. Nicht
   klassifizierte Familien blockieren. Raum-/Standardverteiler- und optionale
   ProjectDevice-Links werden bestätigt, Stromkreis- und Row-Links bleiben
   ausgeschlossen. Das breite Projektmodal zeigt Raumtreffer und Warnungen,
   bietet die vorhandenen Raum-, Verteiler- und ProjectDevice-Kataloge an und
   verlangt vor der atomaren Übernahme eine ausdrückliche Bestätigung. Fehlende
   Räume und ProjectDevices lassen sich über die regulären, vorausgefüllten
   Projektformulare anlegen und werden danach unmittelbar ausgewählt. Diese
   Kataloganlagen bleiben eigenständige, rückgängig machbare Projektrevisionen.
 Vor Beginn werden die oben vorgeschlagenen Namen, die erneute Dateiübertragung
 statt serverseitiger Entwürfe, die Konfigurationsversionierung und die
 Kombination aus Originalbytes und Matrix als Entscheidungen bestätigt.
 ### 14.3 – Editor und explizite Zuordnung
 1. `manualQuantity` und Mengeninvarianten migrieren und testen.
   **Erledigt:** Migration `0005` übernimmt für jede bestehende Gerätezeile
   `manualQuantity = quantity`. Neue normale Zeilen und Mengenänderungen führen
   beide Werte gemeinsam; Snapshot/Transfer v5 erhält den Anteil und stuft v4
   verlustfrei hoch. Die reine Mengenregel validiert den materialisierten Wert
   als manuellen Anteil plus Summe der unteilbaren externen Objektmengen.
 2. Commands für vorhandene Row, neue Row, neuen Circuit und Lösen ergänzen.
   **Teilweise erledigt:** `external-object.update-row-assignment` deckt
   Zuweisung zu vorhandenen Rows, Verschieben zwischen vorhandenen Rows und
   Lösen ab. Der Command prüft Projekt, Verteilung, Gruppenkategorie, Raum,
   Selektionskennzeichen und Planungswerte, verlangt für bestätigbare
   Planungsabweichungen eine explizite Objektliste und aktualisiert Links und
   Gesamtmengen in einer SQLite-Transaktion. Seine exakte Gegenrichtung ist
   dauerhaft Undo/Redo-fähig. Beim Lösen bleibt die Row mit ihrem manuellen
   Mengenanteil bestehen. `external-object.assign-to-new-row` ergänzt die
   Zuordnung ungebundener Objekte als neue Row in einem vorhandenen Circuit.
   Diese Row erhält eine stabile ID und `manualQuantity = 0`; ihr historischer
   Gegenbefehl entfernt sie nur, solange Row und Objektlinks vollständig
   unverändert sind. Ein direktes Löschen über diesen internen Gegenbefehl ist
   als Nutzeraktion gesperrt. `external-object.assign-to-new-circuit` schließt
   den dritten Zielpfad: Ein serverseitig vorgeplanter Circuit mit festem BMK,
   Standardschutz und genau einer externen Row wird gemeinsam mit den
   Objektlinks eingefügt. Seine Historiengegenrichtung prüft den vollständigen
   Circuit-Snapshot und die exakte Linkmenge, bevor sie den Teilbaum entfernt.
   BMK und UUIDs bleiben bei Redo unverändert. Damit ist die persistente
   Command-Grundlage dieses Schritts abgeschlossen; API-Planung und UI folgen.
 3. Verteilungsbezogenen Drawer, Filter und Vorschau der Mengenwirkung ergänzen.
   **Begonnen:** Die reine Read-Projektion und der projekt-/listenbezogene
   GET-Endpunkt liefern ausschließlich Objekte des zugehörigen Verteilers,
   unzugeordnete Objekte zuerst, einschließlich Quellraum, Selektionsmarker,
   Planungswerten und aktuellem Row-Link. API-Client und DTOs sind vorhanden;
   Drawer, Filter und Mengenwirkung folgen.
 4. Einzel- und Mehrfach-Drag-and-drop samt Warnungen, Undo/Redo und Reload
   testen.
 Vor Beginn werden Drawerposition, Verhalten widersprüchlicher Mehrfachauswahl,
 Warnungsdialoge und der Lebenszyklus leerer Rows festgelegt.
 ### 14.4 – Strukturtreuer Rückexport
 1. Exportprojektion gegen eine bekannte Projektrevision ergänzen.
 2. Nur gemappte Objektzellen in einer Kopie der akzeptierten Matrix ersetzen.
 3. Dialekt, Reihenfolge, unbekannte Zellen und Passthrough-Zeilen erhalten.
 4. Download und append-only Exportnachweis ergänzen.
 Zahlenformat, leere Stromkreiswerte und Dateiname werden vorher fachlich
 festgelegt.
 ### 14.5 – Folgeimport und Konflikte
 1. Deterministischen Diff nach `(sourceId, ifcGuid)` ergänzen.
 2. Neu, geändert, unverändert, fehlend und konfliktbehaftet projizieren.
 3. Einzel- und Sammelentscheidungen im Wizard ergänzen.
 4. Akzeptierten Diff als einen atomaren Command mit vollständigem Undo/Redo
   übernehmen.
 ### 14.6 – Härtung und End-to-End-Abnahme
 1. Alle Szenarien A bis G der verbindlichen Spezifikation automatisieren.
 2. Referenzdatei über Vorschau, Erstimport, Zuordnung, Export, Folgeimport,
   Snapshot/Restore und Projektduplikat prüfen.
 3. Abfrageindizes und große Payloads mit mehreren tausend Objekten messen.
 4. Architektur-, API-, Betriebs- und Nutzerdokumentation auf den tatsächlich
   ausgelieferten Stand nachziehen.
 ## Risiken und Schutzmaßnahmen
 - **Mengenverlust:** `manualQuantity` trennt manuelle und externe Anteile;
  Commands ändern Links und materialisierte Menge gemeinsam.
 - **Stilles Überschreiben:** Quellwerte, lokale Werte und Overrides sind
  getrennt; jede Übernahme benötigt eine Nutzerentscheidung.
 - **ProjectDevice-Verfälschung:** Links ändern niemals die kanonische Vorlage;
  deren bestehende Commands bleiben alleinige Schreibgrenze.
 - **Nicht reproduzierbarer Export:** Jeder Batch hält Originalbytes, Matrix,
  Dialekt, Konfiguration, Hash und Projektrevision.
 - **Sehr große Undo-Payloads:** Importcommands speichern vollständige
  erwartete/Zielzustände. Größe und Transaktionsdauer werden in 14.2 gemessen,
  nicht durch indirekte oder nachträglich neu berechnete Payloads optimiert.
 - **BMK-Drift:** Neue BMKs werden einmal bei der Planung berechnet und im
  Command gespeichert; Import, Sortierung und Redo nummerieren nie implizit.
 - **Vertrauliche Referenzdaten:** Der Referenzprüfer läuft lokal gegen die
  bereitgestellte CSV. Vor einer Aufnahme dieser Datei in Git ist gesondert zu
  klären, ob sie ausreichend anonymisiert und zur Weitergabe freigegeben ist.
 ## Freigabepunkt
 Mit der Freigabe dieses Audits beginnt Arbeitspaket 14.1.1: reine
 Transportverträge, Validatoren und synthetische CSV-Fixtures. Dieses Paket
 ändert weder Datenbank noch GUI und führt keine Projektschreibvorgänge aus.
--- a/docs/spec/revit-excel-integration-requirements.md
+++ b/docs/spec/revit-excel-integration-requirements.md
@ -0,0 +1,463 @@
 # Revit-Integration über Linear-Excel – verbindliche Anforderungen
 Stand: 29.09.2026. Dieses Dokument ist die fachliche und technische
 Arbeitsgrundlage für die neue Phase 14. Es ersetzt die frühere CSV-/IfcGUID-
 Spezifikation. Der Umsetzungsstand steht im
 [R0–R10-Plan](revit-excel-phase-14-plan.md); der geprüfte Ausgangszustand im
 [R0-Audit](revit-excel-r0-audit.md).
 ## 1. Ziel und Grenzen
 Der Austausch mit Revit erfolgt ausschließlich über den XLSX-Export/-Import
 des Linear-Plugins. Eine vollständige Revit-Bauteilliste wird importiert, in
 Leistungsbilanz geplant und mit gleichem Tabellenaufbau an Linear
 zurückgegeben. Linear ordnet enthaltene Zeilen anhand der Worksharing-ID zu.
 Nicht Teil dieser Phase sind Dynamo, Revit-API, JSON-Transport, automatische
 Stromkreisbildung, Übernahme vorhandener Revit-Stromkreiswerte,
 Teilimporte, mehrere Modellquellen, PostgreSQL und neue Rollen/Rechte.
 Die Integration bleibt optional. Manuelle Projekte, Räume, ProjectDevices,
 Stromkreise und Gerätezeilen funktionieren ohne externes Modell. Der
 Circuit-First-Aufbau, stabile interne UUIDs und BMKs, ausdrückliche
 Neunummerierung sowie die gemeinsame Project-Command-Transaktionsgrenze
 bleiben unverändert.
 ## 2. Verbindliche fachliche Regeln
 - Import erzeugt keine `CircuitDeviceRow`, keinen `Circuit` und kein BMK.
 - Quellwerte, lokale Planungswerte und Overrides bleiben getrennt.
 - Ein Folgeimport überschreibt keine lokale Planung still.
 - Fehlende Objekte werden markiert und erst nach ausdrücklicher Bestätigung
  entfernt.
 - Mehrfachsteckdosen sind unteilbare externe Objekte. Ihre wirksame Menge kann
  größer als eins sein.
 - Die Row-Menge ist
  `manualQuantity + Summe(effectiveQuantity der verknüpften Objekte)`.
 - Nach einer Row-Zuordnung ist die `CircuitDeviceRow` die Planungsebene für
  alle verknüpften Objekte.
 - Bestehende ProjectDevices bleiben kanonische Vorlagen und werden durch
  Importe nie verändert.
 - Sortieren, Filtern, Importieren, Zuordnen und Verschieben nummeriert keine
  Stromkreise automatisch neu.
 ## 3. Linear-XLSX-Profil
 Die lokale Referenzdatei `docs/spec/kbp-Stromkreis.xlsx` enthält vertrauliche
 Projektdaten. Sie wird nicht committed und nicht in Tests eingebettet. Tests
 erzeugen synthetische Workbooks. Der lokale Referenzprüfer erhält den Pfad als
 Argument.
 Beobachtetes Profil:
 - genau ein Arbeitsblatt; Blattname nach Excel-Regel maximal 31 Zeichen;
 - Kopfzeile in Zeile 1, Zeile 2 leer, Daten ab Zeile 3, erste Datenspalte A;
 - Spalte A `Worksharing-ID` im Format `<GUID>-<8 Hex>`;
 - Parameterbindungen stehen als klassische Excel-Kommentare in den übrigen
  Kopfzellen;
 - Zahlen sind typisierte Excel-Zahlen; importierte Werte bleiben unverändert,
  fachlich verwendete Leistung wird auf 0,01 W projiziert;
 - Objektzeilen dürfen keinen MEP-Raum besitzen;
 - eine Schluss-/Summenzeile ohne ID kann vorkommen und wird weder importiert
  noch zurückgegeben.
 Die Referenzdatei enthält 487 Objektzeilen, eindeutige Worksharing-IDs und
 keine doppelten nichtleeren IfcGUIDs bei exaktem, case-sensitivem Vergleich.
 Ihre Summenzeile steht in Spalte B (`CAx_Auswahlkenner`), während
 `Familie und Typ` leer ist.
 ### Zeilen ohne Worksharing-ID
 Nur eine Zeile ohne Worksharing-ID, aber mit befülltem Feld
 `Familie und Typ`, gilt als verdächtige Objektzeile. Sie erzeugt einen Hinweis
 und wird übersprungen; sie blockiert den Import nicht. Andere Zeilen ohne ID,
 einschließlich einer nur in Spalte B befüllten Summenzeile, werden ohne Hinweis
 übersprungen. Eine Objektzeile ist für den Import eine Zeile mit nichtleerer
 Worksharing-ID.
 Worksharing-ID und IfcGUID werden stets exakt, ordinal und mit
 Groß-/Kleinschreibung verglichen. Es findet kein Trimmen, Normalisieren oder
 Case-Folding für die Identität statt. Eine nichtleere Worksharing-ID mit
 unerlaubten äußeren Leerzeichen oder falschem Format blockiert. Doppelte
 Worksharing-IDs blockieren. IfcGUID ist optional, kein Schlüssel und darf
 doppelt vorkommen; Duplikate erzeugen lediglich einen Hinweis.
 ## 4. Upload und Transportadapter
 Der Server akzeptiert ausschließlich Dateien mit Endung `.xlsx` bis 10 MiB.
 `.xls` und `.xlsm` werden abgelehnt. Parsing findet serverseitig statt. Nach
 dem Einlesen gelten feste Zeilen-, Spalten- und Zellgrenzen, die in R2 anhand
 synthetischer Grenztests festgelegt und zentral definiert werden. Es gibt in
 dieser Phase keinen eigenen ZIP-Prüfer und keinen Parser-Worker.
 Der Adapter unter `src/external-model/xlsx` liest eine transportneutrale
 Zellmatrix. Eine Zelle ist `string`, `number`, `boolean` oder `empty`.
 Zusätzlich werden Blattname, Originalzeilennummer, Kopfzeilenkommentare,
 Spaltenbreiten und die für Hinweise nötigen Formelmetadaten erfasst.
 Domain-Services kennen weder ExcelJS noch XLSX, React oder SQLite.
 Formeln werden niemals ausgeführt. Ist ein gecachter skalarer Wert vorhanden,
 wird er verwendet und als Hinweis ausgewiesen. Fehlt er oder ist er ein
 Fehlerwert, bleibt das Feld leer; bei der Worksharing-ID oder einem anderen
 Pflichtfeld blockiert dies die betreffende Objektzeile beziehungsweise den
 Import.
 Genau eine gepflegte Bibliothek wird ergänzt. Vorgesehen ist `exceljs`, sofern
 R2 die Node-24-Verträglichkeit und den Roundtrip von Kopfkommentaren,
 Blattname, Spaltenbreiten, Formaten und Zelltypen bestätigt.
 ## 5. Projektkonfiguration
 Die Konfiguration ist projektweit, revisionssicher und besitzt keine eigene
 Versionszählung. Jeder Plan und jedes Apply tragen `expectedRevision`.
 Da die Projektrevision auch bei Undo/Redo strikt steigt, wird ein alter Plan
 automatisch ungültig. Jeder Importbatch speichert eine vollständige Kopie der
 beim Import verwendeten Konfiguration.
 Das Einstellungsmodal auf der Revit-Seite erkennt aus einer zustandslos
 hochgeladenen Musterdatei Kopfzeile, erste Datenzeile und erste Datenspalte.
 Diese Werte bleiben editierbar; Standard ist 1 / 3 / A. Es gibt nur ein Feld
 für die Identitätsspalte: `columns.worksharingId`. Ein separates
 `layout.idColumn` existiert nicht.
 Zielvertrag:
 ```ts
 interface ExternalModelConfiguration {
  schemaVersion: 1;
  layout: {
    headerRow: number;
    firstDataRow: number;
    firstDataColumn: number;
  };
  circuitMode: "combined" | "separate";
  columns: {
    worksharingId: string;
    ifcGuid: string | null;
    roomNumber: string | null;
    roomName: string | null;
    familyAndType: string;
    selectionMarker: string | null;
    socketCount: string | null;
    sourceRemark: string | null;
    circuitCombined: string | null;
    boardName: string | null;
    circuitIdentifier: string | null;
    designation: string | null;
    electricalPowerW: string | null;
    voltageV: string | null;
    currentA: string | null;
  };
  deviceTypes: DeviceTypeConfiguration[];
  familyTypeRules: FamilyTypeRule[];
 }
 ```
 Standardzuordnung:
 | Schlüssel | Bedeutung | Standardspalte |
 | --- | --- | --- |
 | `worksharingId` | externe Identität, Pflicht | `Worksharing-ID` |
 | `ifcGuid` | optionale Redundanz | `IfcGUID` |
 | `roomNumber` | Raumnummer | `MEP-Raum: Nummer` |
 | `roomName` | Raumname | `MEP-Raum: Name` |
 | `familyAndType` | Familie und Typ, Pflicht | `Familie und Typ` |
 | `selectionMarker` | CAx-Auswahlkenner | `CAx_Auswahlkenner` |
 | `socketCount` | Anzahl Einzelsteckdosen | `CAX_AnzahlObjekte` |
 | `sourceRemark` | Anmerkung | `CAx_Anmerkung` |
 | `circuitCombined` | Stromkreis gesamt | `kbp_Stromkreisnummer` |
 | `boardName` | Verteiler | `kbp-E-Verteiler` |
 | `circuitIdentifier` | Stromkreis-BMK | `kbp-E-Stromkreis` |
 | `designation` | Bezeichnung | `kbp-E-Bezeichnung` |
 | `electricalPowerW` | elektrische Leistung [W] | `kbp-E-Elektrische Leistung` |
 | `voltageV` | Spannung [V] | `kbp-E-Spannung` |
 | `currentA` | Stromstärke [A] | `kbp-E-Stromstärke` |
 `worksharingId` und `familyAndType` sind Pflichtmappings. Im Modus
 `combined` ist `circuitCombined` für den Rückexport Pflicht; im Modus
 `separate` sind `boardName` und `circuitIdentifier` Pflicht. Fehlende optionale
 Rückgabespalten `designation`, `electricalPowerW`, `voltageV` und `currentA`
 werden mit Hinweis übersprungen und blockieren den Export nicht.
 Jedes interne Feld besitzt im Modal ein Dropdown aus den Kopfzellen und eine
 freie Eingabe. Exakte kbp-Standardnamen werden vorbelegt. Typ und Einheit aus
 dem Linear-Kommentar werden angezeigt. Nicht gemappte Spalten bleiben beim
 Rückexport unverändert.
 ## 6. Gerätearten und Familie-und-Typ-Regeln
 Eine Geräteart besitzt stabile interne UUID, Name, Kategorie
 `lighting | single_phase | three_phase` sowie optionale Standardwerte für
 Leistung je Einheit in W, GZF, cosPhi und Kostengruppe. Jede exakte
 `Familie und Typ`-Regel verweist auf genau eine Geräteart und verwendet die
 Mengenregel `1` oder `socketCount`.
 Mehrere Revit-Familien dürfen auf dieselbe Geräteart zeigen. Jedes Revit-
 Objekt bleibt trotzdem einzeln über seine Worksharing-ID nachverfolgbar.
 Unbekannte Familien müssen im Importwizard zugeordnet oder über eine neue
 Geräteart klassifiziert werden; andernfalls blockiert Apply.
 Planungsstartwerte folgen dieser Reihenfolge:
 1. ausdrücklich verknüpftes ProjectDevice;
 2. Geräteart-Standard;
 3. leer.
 Der Anzeigename wird aus CAx-Auswahlkenner, dann Geräteartname, dann
 `Familie und Typ` vorgeschlagen. Ein fehlender GZF wird mit `1` vorbelegt,
 ohne zusätzliche Bestätigung. Standardwerte sind Startwerte, keine dauerhafte
 Synchronisierung.
 ## 7. Persistenter externer Zustand
 Pro Projekt existiert genau eine implizite Revit-XLSX-Quelle. Ein externes
 Objekt besitzt eine interne UUID und ist je `(sourceId, worksharingId)`
 eindeutig. `worksharingId` ist NOT NULL; `ifcGuid` ist nullable und nicht
 eindeutig. Interne Relationen verwenden ausschließlich interne UUIDs.
 Gespeichert werden:
 - akzeptierte Quellwerte einschließlich aller Rückgabefelder;
 - lokale Planungswerte und Override-Felder;
 - Geräteart;
 - optionales Raum-Mapping, abweichender Verteiler, ProjectDevice und
  `CircuitDeviceRow`;
 - Anwesenheitsstatus und Verweis auf den zuletzt relevanten Import;
 - effektive Menge als fachlicher Wert des unteilbaren Objekts.
 Der effektive Verteiler eines verknüpften Objekts ist immer der Verteiler
 seiner Row. Für ein unzugeordnetes Objekt gilt zuerst die explizite
 Objektabweichung, danach der Standardverteiler seines Raum-Mappings. Ändert
 sich der Standardverteiler eines Raums, betrifft das nur unzugeordnete
 Objekte; verknüpfte Objekte bleiben über ihre Row unverändert und die Änderung
 wird deshalb nicht gesperrt.
 ## 8. Importbatch-Aufbewahrung, Snapshot und Transfer
 Der aktive Projektzustand enthält den letzten Importbatch vollständig:
 Originalbytes, klassifizierte Matrix, Dateiname, SHA-256, Zeitpunkt,
 Objektzahl, Importart, Projektrevision und Konfigurationskopie. Ältere Batches
 werden zu Metadaten reduziert: Datum, Dateiname, SHA-256 und Objektzahl.
 Sie enthalten keine Originalbytes, Matrix oder Konfigurationskopie mehr.
 Snapshot-Schema 10 und portabler Projekttransfer übernehmen genau diese
 Aufteilung. Beim Duplizieren werden alle internen UUIDs und Links remapped;
 Worksharing-IDs, optionale IfcGUIDs, Quellwerte und das letzte Workbook bleiben
 unverändert.
 Versionen 1–9 ohne externe CSV-Daten werden verlustfrei auf Version 10
 hochgestuft. Enthält ein alter Stand eine CSV-Konfiguration oder einen nicht
 leeren CSV-Zustand, wird er mit klarer deutscher Fehlermeldung abgelehnt.
 Alte CSV-History-Commands werden ebenfalls vor jedem Write abgelehnt und nie
 stillschweigend übersprungen.
 ## 9. Erstimport
 Der Ablauf ist Upload → zustandslose Vorschau/Planung → erneute
 Dateiübertragung bei Apply. Apply prüft SHA-256, `expectedRevision`,
 Konfigurationskopie, Matrix und sämtliche Entscheidungen erneut. Nur Apply
 liest die Excel-Datei erneut ein.
 Undo und Redo lesen keine Excel-Datei und parsen keine gespeicherten Bytes.
 Sie arbeiten ausschließlich auf den im Command gespeicherten vollständigen
 Vorher-/Nachher-Zuständen. Dadurch bleiben sie nach Neustart deterministisch
 und unabhängig vom Parser.
 Der Wizard umfasst:
 1. Vorschau mit Objektzahl, übersprungenen und verdächtigen Zeilen,
   doppelten Worksharing-IDs, doppelten IfcGUID-Hinweisen, unbekannten
   Familien, nicht lesbaren Zahlen und Formeln;
 2. Räume anlegen oder vorhandenen Räumen/Ebenen zuordnen;
 3. Standardverteiler je Raum, Sammelzuordnung, Objektabweichungen und Objekte
   ohne Raum;
 4. Familien exakt Gerätearten und einer Mengenregel zuordnen;
 5. optional vorhandene oder neu angelegte ProjectDevices verknüpfen;
 6. Zusammenfassung und ausdrückliche Bestätigung.
 Die Übernahme ist ein atomarer Command und ein Undo-Schritt. Im Import
 entstehen keine Rows. Neu angelegte Räume und ProjectDevices verwenden ihre
 vorhandenen Commands und bleiben eigene Undo-Schritte.
 ## 10. Objektplanung und Revit-Seite
 Route: `/projects/:projectId/revit`, erreichbar aus der Projektnavigation.
 Der Revit-Button und das CSV-Modal auf der Projektübersicht entfallen.
 Die Seite besitzt:
 - Statuskarte mit letztem Import, Objektzahl, ohne Verteiler, ohne
  Stromkreis, fehlend und Abweichung zu Revit;
 - Aktionen `Import`, `Rückgabe-Excel`, `Einstellungen`;
 - einklappbare Geräteart-/Familienregel-Übersicht;
 - kompakte Objekttabelle mit Suche, Spaltenfiltern, Sortierung,
  Mehrfachauswahl und Sammelzuordnung für Verteiler, ProjectDevice und
  Planungswerte.
 Die kompakte Liste wird einmal geladen, vollständig im Client gefiltert und
 sortiert und virtualisiert dargestellt. Es gibt keine Server-Pagination.
 Originalbytes, Matrix und Command-Payloads gehören nicht in dieses DTO.
 Vor Row-Zuordnung lassen sich Leistung je Einheit, GZF, cosPhi,
 Kostengruppe, Anzeigename und Bemerkung einzeln oder gesammelt ändern.
 Geänderte Felder werden Overrides. Nach Row-Zuordnung werden diese Werte im
 Grid an der Row bearbeitet. Beim ausdrücklichen Lösen erhält das Objekt die
 aktuellen Row-Werte als Planungswerte und entsprechende Overrides.
 ## 11. Editor-Zuordnung und Löschen
 Der rechte, überlagernde Editorbereich zeigt unzugeordnete konfliktfreie
 Objekte des aktuellen Verteilers. Gruppierungsschlüssel sind interner Raum,
 Auswahlkenner, Geräteart, Kategorie, identische Planungswerte und kompatibler
 ProjectDevice-Link. Die Anzeige nennt Summe der wirksamen Mengen und Zahl der
 externen Objekte. Gruppen sind aufklappbar; Einzel- und Mehrfachauswahl sowie
 Filter bleiben möglich.
 Drag-and-drop:
 - auf vorhandene Row: genau diese Row;
 - auf Circuit: neue Row mit `manualQuantity = 0`;
 - auf freien Bereich: neuer Circuit, Schutz und Row in einem Command.
 Neue IDs und BMK werden einmal geplant; Redo rechnet sie nicht neu. Neue Rows
 übernehmen den bestätigten Gruppenzustand und die Summe der effektiven Mengen.
 An Rows zeigt ein Hinweis die Zahl verknüpfter Revit-Objekte; einzelne Objekte
 können ausdrücklich gelöst werden.
 Wird eine Row, ein Circuit oder eine Gruppe mit verknüpften Revit-Objekten
 gelöscht, zeigt die UI vor Bestätigung:
 `X Revit-Objekte werden wieder unzugeordnet`. Derselbe Löschcommand löst die
 Objekte, entfernt die Struktur und speichert alle Links in seiner Inversen.
 Undo stellt Struktur und Links exakt wieder her. Diese Löschungen werden nicht
 gesperrt.
 Das Löschen eines Verteilers oder Raums mit referenzierten externen Objekten
 bleibt gesperrt. Der Nutzer muss die Verknüpfungen beziehungsweise Zuordnungen
 zuvor ausdrücklich ändern. Die Regel gilt auch für Unterbaum- und History-
 Pfade.
 ## 12. Rückgabe-Excel
 Der Export ist eine Leseoperation ohne Projektrevision. Ein append-only
 Nachweis speichert Projektrevision, zugrunde liegenden letzten Import,
 Zeitpunkt, Dateiname, SHA-256, Konfigurationskopie beziehungsweise ihren Hash
 und Objektzahl.
 Umfang:
 - alle im letzten Import vorhandenen Objekte (Standard);
 - nur Objekte mit Abweichung zum zuletzt importierten Revit-Wert;
 - Auswahl aus der Objekttabelle.
 Die Rückgabe basiert auf einer Kopie des zuletzt importierten Workbooks.
 Zeilen oberhalb der ersten Datenzeile, Kopfkommentare, Formate,
 Spaltenbreiten, Blattname und Spaltenreihenfolge bleiben erhalten. Danach
 folgen nur die gewählten Objektzeilen in ihrer Originalreihenfolge. Alle
 Spalten bleiben enthalten; Summenzeilen entfallen.
 Stromkreiswerte:
 - `combined`: `DistributionBoard.name + Circuit.equipmentIdentifier`, ohne
  Trennzeichen;
 - `separate`: Verteilername und unverändertes BMK in getrennten Spalten;
 - ohne Circuit: Stromkreisfeld beziehungsweise beide Felder leer.
 Die Wahl des Verteilerwerts liegt in genau einer Funktion und verwendet
 zunächst `DistributionBoard.name`.
 Weitere Rückgabewerte:
 - Bezeichnung = Row-`displayName`, ohne Row Planungs-Anzeigename;
 - Leistung [W] = effektive Menge × Einzelleistung, ohne GZF;
 - Spannung = Circuit-Spannung, sonst Projektstandard der Kategorie;
 - Strom = `P / (U × cosPhi)` beziehungsweise
  `P / (sqrt(3) × U × cosPhi)`, auf 0,01 A;
 - nicht berechenbar = leere Zelle plus Hinweis.
 Zahlen werden als Excel-Zahlen geschrieben. Fehlende optionale Zielspalten
 werden mit Hinweis ausgelassen. Nur fehlende Stromkreisspalten des gewählten
 Modus blockieren. Dateiname:
 `<Projektname>_Revit-Rueckgabe_<YYYY-MM-DD>.xlsx`.
 ## 13. Verbindliche R2-Abnahme mit Linear
 R2 endet mit einer Rückgabedatei, die aus der lokalen realen Musterdatei
 erzeugt wurde und einige klar identifizierbare Rückgabewerte verändert. Diese
 Datei wird nicht committed. Der Nutzer testet sie in Linear. R3 darf erst nach
 erfolgreichem Linear-Rückimport beginnen.
 Scheitert der Linear-Import, wird vor R3 eine Alternative zur Freigabe
 vorgelegt: Die Original-XLSX wird direkt auf OOXML-Ebene kopiert und nur die
 erforderlichen Zellwerte/-typen sowie Zeilenbereiche angepasst. Die
 Alternative bleibt hinter demselben transportneutralen Adaptervertrag.
 ## 14. Folgeimport
 Jeder Import ist eine vollständige Projektbauteilliste. Matching erfolgt
 ausschließlich über exakt und case-sensitiv verglichene Worksharing-ID.
 - neu: Wizard-Schritte nur für neue Objekte und unbekannte Familien;
 - geänderte Quellwerte: Einzel- oder Sammelentscheidung;
 - akzeptierte Mengenänderung: verknüpfte Row-Menge im selben Command;
 - fehlend: markieren, Link und Menge zunächst beibehalten;
 - Löschen: erst nach gesonderter Bestätigung;
 - abweichende Rückgabefelder: Hinweis `in Revit noch nicht aktualisiert`,
  keine Übernahmeentscheidung.
 `external-import.apply-follow-up` ist atomar und ein Undo-Schritt.
 Unveränderte Objekte erzeugen keine unnötigen Objekt- oder Row-Änderungen.
 Der neue vollständige Batch wird letzter Batch; der zuvor letzte Batch wird
 auf Metadaten reduziert.
 ## 15. Commands, Persistenz und Sicherheit
 Projektbezogene Writes verwenden typisierte Commands mit vollständiger
 Gegenrichtung, `expectedRevision`, Anmeldung, CSRF-Header und
 `project-command-transaction.persistence.ts`. Dazu gehören mindestens:
 - `external-model-configuration.update`;
 - `external-import.apply-initial`;
 - `external-import.apply-follow-up`;
 - `external-model-object.update-planning`;
 - `external-model-object.update-distribution-board`;
 - `external-model-room-mapping.update`;
 - `external-model-object.update-project-device-link`;
 - `external-object.update-row-assignment`;
 - `external-object.assign-to-new-row`;
 - `external-object.assign-to-new-circuit`;
 - `external-model-object.delete-missing`;
 - die erweiterten Row-/Circuit-/Gruppen-Löschcommands mit Objekt-Link-
  Transitionen.
 Die Konfiguration selbst ist Teil der erwarteten/gewünschten Snapshots, aber
 hat keinen eigenen monotonen Zähler. Importbatches halten eine unveränderliche
 Konfigurationskopie. Preview/Plan sind zustandslos. Apply überträgt und parst
 die Datei erneut; Undo/Redo führt nur gespeicherte Zustandsübergänge aus.
 Neue Migrationen sind additiv. Vor Anwendung wird die Datenbank gesichert und
 das generierte SQL geprüft. Da nur Entwicklungsdaten existieren, darf die
 Migration alte externe CSV-Daten verwerfen. Vor dem Löschen externer Objekte
 werden betroffene Row-Mengen auf `manualQuantity` zurückgesetzt. Der Verlust
 des alten externen Entwicklungszustands wird dokumentiert.
 ## 16. Abnahme und Leistung
 Die Oberfläche muss mehrere Tausend Objekte flüssig bedienen. R10 misst
 Import, Command-/Snapshot-Größe, Speicherbedarf und Client-Interaktion mit
 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.
 Jedes Paket R1–R10 führt fokussierte Tests sowie aus:
 ```text
 npm test
 npm run build:api
 npm run build:web
 npm run typecheck:scripts
 npx tsc --noEmit -p tsconfig.next.json
 ```
 Jedes Paket erhält einen eigenen knappen imperativen Commit. Die konkrete
 Paketfolge und ihre Freigabepunkte stehen im
 [R0–R10-Plan](revit-excel-phase-14-plan.md).
--- a/docs/spec/revit-excel-phase-14-plan.md
+++ b/docs/spec/revit-excel-phase-14-plan.md
@ -0,0 +1,173 @@
 # Phase 14 neu – Plan für die Linear-Excel-Anbindung
 Verbindliche Fachgrundlage:
 [Revit-Integration über Linear-Excel](revit-excel-integration-requirements.md).
 Der alte CSV-Plan 14.0–14.6 ist abgelöst und wird nicht fortgeschrieben.
 ## Status
 | Paket | Status | Ergebnis / Freigabepunkt |
 | --- | --- | --- |
 | R0 | abgeschlossen und freigegeben | Bestandsaudit, Zielmodell, Migration und Risiken; Freigabekorrekturen in R1 eingearbeitet. |
 | R1 | abgeschlossen | Anforderungen, Plan und Architektur auf Excel/Worksharing-ID umgestellt; alle Pflichtprüfungen bestanden. |
 | R2 | offen | XLSX-Adapter, Parser, synthetische Fixtures, lokaler Referenzprüfer und reale Rückgabedatei. Danach zwingende Linear-Abnahme durch den Nutzer. |
 | R3 | gesperrt bis R2-Abnahme | Konfiguration, Identität, Migration, Snapshot 10, Transfer und Backend-CSV-Entfernung. |
 | R4 | offen | Revit-Seite, Navigation, Einstellungen, altes Projektseitenmodal entfernen. |
 | R5 | offen | Erstimportwizard mit Gerätearten, Familienregeln und optionalen ProjectDevices. |
 | R6 | offen | Virtualisierte Objekttabelle und Sammelzuordnungen. |
 | R7 | offen | Editorbereich, Gruppierung, Drag-and-drop, Lösen und integrierte Löschübergänge. |
 | R8 | offen | Rückgabe-Excel und append-only Exportnachweis. |
 | R9 | offen | Vollständiger Folgeimport nach Worksharing-ID. |
 | R10 | offen | Ende-zu-Ende-Härtung, große Datenmengen und Abschlussdokumentation. |
 ## R0 – Audit
 Ergebnis: [R0-Audit](revit-excel-r0-audit.md). Die Freigabe vom 29.09.2026
 enthält 13 Korrekturen. Bei Abweichungen zwischen dem historischen Audit und
 der aktuellen Anforderung gilt das neue Anforderungsdokument.
 ## R1 – Dokumentation
 Lieferumfang:
 - neues verbindliches Excel-Anforderungsdokument;
 - dieser R0–R10-Plan;
 - alte CSV-Anforderungen und alter Plan als kurze Ablösungshinweise;
 - LLM-Kontext auf die neue Quelle der Wahrheit kürzen;
 - `AGENTS.md`, aktuelle Architektur, History-/External-Model-Architektur,
  Roadmap, README, Dokumentationsindex und bekannte Einschränkungen anpassen;
 - reale Musterdatei per `.gitignore` vom Commit ausschließen;
 - alle internen Links auf die neuen Dokumente umstellen.
 Keine Laufzeit-, Schema- oder UI-Änderung. Abnahme: keine aktive Dokumentation
 nennt CSV/IfcGUID als künftigen Transport beziehungsweise Schlüssel; der
 aktuell noch vorhandene Legacy-Code bleibt als solcher klar benannt.
 ## R2 – XLSX-Transportadapter
 Dateien/Module: neues `src/external-model/xlsx`, synthetische Testfixtures und
 ein auf XLSX umgestellter Referenzprüfer mit Dateipfadargument. Eine neue
 direkte Bibliothek (`exceljs`, vorbehaltlich der Tests), keine DB-Änderung.
 Abnahme:
 - Kopfzeilenkommentare, Blattname, Spaltenbreiten, Formate und Zelltypen
  überleben einen strukturellen Roundtrip;
 - erste Datenzeile/-spalte und Mappings funktionieren ohne separates
  `layout.idColumn`;
 - Worksharing-ID/IfcGUID werden exakt und case-sensitiv behandelt;
 - Zeile ohne ID und ohne `Familie und Typ` wird übersprungen, die Muster-
  Summenzeile B490 blockiert nicht;
 - Zeile ohne ID mit `Familie und Typ` erzeugt Hinweis und wird übersprungen;
 - maximal 10 MiB, nur `.xlsx`, Zeilen-/Spaltengrenzen nach dem Einlesen;
 - keine Formelausführung;
 - lokale Referenzprüfung bestätigt 487 Objekte und keine ID-Duplikate;
 - aus der realen Musterdatei entsteht lokal eine nicht versionierte
  Rückgabedatei mit einigen geänderten Werten.
 Danach stoppt die Arbeit. Der Nutzer testet diese Datei in Linear. Erst sein
 erfolgreicher Rückimport gibt R3 frei. Scheitert er, wird vor R3 ein konkreter
 OOXML-Patchadapter vorgeschlagen, der das Originalworkbook direkt ändert.
 ## R3 – Datenmodell und Backend-Cutover
 - Konfiguration ohne eigene Versionszählung;
 - `worksharing_id NOT NULL`, Unique je Quelle; `ifc_guid` nullable ohne Unique;
 - additive Migration nach vorherigem DB-Backup; alte externe Entwicklungsdaten
  verwerfen und Row-Mengen vorher auf `manualQuantity` zurücksetzen;
 - Batch-Aufbewahrung: nur letzter Batch vollständig, ältere nur Metadaten;
 - Snapshot 10, Restore und Transfer; alte CSV-Zustände/History klar ablehnen;
 - Backend-CSV-Parser, Endpunkte und Verträge entfernen;
 - Apply parst erneut; Undo/Redo verwenden ausschließlich gespeicherte
  Vorher-/Nachher-Zustände.
 Risiken: Migration mit verknüpften Row-Mengen, alte History-Spitzen und
 vollständiges UUID-Remapping. Pflicht: echte SQLite-Commit-/Rollback-Tests.
 ## R4 – Revit-Seite und Einstellungen
 - Route `/projects/:projectId/revit` und Navigationseintrag;
 - Status-/Aktionsgrundgerüst;
 - Einstellungsmodal mit Musterdateierkennung, Layout und Feldzuordnung;
 - Stromkreismodus `combined | separate`;
 - Projektseiten-Button und `revit-csv-modal.tsx` entfernen;
 - nur deutsche UI-Texte und bestehende Icon-/Kartenregeln.
 ## R5 – Erstimport
 - Vorschau und Plan mit erneuter Dateiübertragung beim Apply;
 - Räume, Verteiler, Gerätearten, exakte Familienregeln und optionale
  ProjectDevices;
 - fehlender GZF als sichtbarer Startwert `1`, ohne Zusatzbestätigung;
 - Warn-/Überspringregel für ID-lose Zeilen;
 - ein atomarer Importcommand, keine Row-/Circuit-Erzeugung;
 - Undo/Redo aus Commandzuständen ohne Workbook-Parsing.
 ## R6 – Objekttabelle und Sammelaktionen
 - kompakte Objektliste einmal laden;
 - clientseitig suchen, filtern und sortieren;
 - virtualisierte Darstellung ohne Server-Pagination;
 - stabile Mehrfachauswahl und Sammelaktionen für Verteiler, ProjectDevice und
  Objektplanungswerte;
 - Standardverteileränderung wirkt nur auf unzugeordnete Objekte; verknüpfte
  Objekte folgen unverändert ihrer Row.
 ## R7 – Stromkreislisteneditor
 - gruppierter rechter Revit-Bereich mit Anzahl-Badge;
 - Drop auf Row, Circuit oder freien Bereich über vorhandene, angepasste
  Commands;
 - Row-Indikator, Objektanzeige und Lösen mit Übernahme aktueller Row-Werte;
 - Row-/Circuit-/Gruppen-Löschcommands lösen verknüpfte Objekte atomar und
  zeigen `X Revit-Objekte werden wieder unzugeordnet`;
 - Undo stellt Objektlinks exakt wieder her;
 - nur Raum-/Verteilerlöschung mit externen Referenzen bleibt gesperrt.
 ## R8 – Rückgabe-Excel
 - alle / abweichende / ausgewählte Objekte;
 - zuletzt importiertes Workbook als strukturelle Grundlage;
 - Stromkreisfelder des gewählten Modus sind Pflicht;
 - fehlende optionale Bezeichnung-/Leistung-/Spannung-/Stromspalten nur als
  Hinweis überspringen;
 - typisierte Zahlen, gemeinsame Export-/Abweichungsprojektion;
 - append-only Exportnachweis ohne Projektrevision.
 R8 baut auf der in R2 durch Linear bestätigten Transportstrategie auf.
 ## R9 – Folgeimport
 - exaktes, case-sensitives Matching nach Worksharing-ID;
 - neu, geändert, unverändert, fehlend und Rückgabefeldabweichungen;
 - Entscheidungen nur für fachliche Quelländerungen;
 - akzeptierte Mengenänderungen und Row-Summen atomar;
 - fehlende Objekte nicht automatisch lösen oder löschen;
 - neuer letzter Vollbatch, vorheriger Batch auf Metadaten reduzieren;
 - ein persistenter Undo-Schritt ohne Excel-Parsing bei Undo/Redo.
 ## R10 – Härtung
 Ende-zu-Ende-Test:
 ```text
 Import → Objektplanung → Row-Zuordnung → Rückgabe → Folgeimport
       → Snapshot/Restore → Projektduplikat → Undo/Redo nach Neustart
 ```
 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.
 ## Pflichtprüfungen je Paket R1–R10
 ```text
 fokussierte Tests
 npm test
 npm run build:api
 npm run build:web
 npm run typecheck:scripts
 npx tsc --noEmit -p tsconfig.next.json
 ```
 Jedes Paket wird mit einer knappen imperativen Commit-Message abgeschlossen.
--- a/docs/spec/revit-excel-r0-audit.md
+++ b/docs/spec/revit-excel-r0-audit.md
@ -2,12 +2,17 @@
 Stand: 29.09.2026. Geprüfter Code: `cf022b2`.
-**Status: R0 abgeschlossen, Freigabe für R1–R10 ausstehend.** Dieser Bericht
+**Status: R0 abgeschlossen und mit Korrekturen für R1 freigegeben.** Dieser Bericht
 ist ein Umsetzungsvorschlag, kein Nachweis einer bereits implementierten
 Excel-Anbindung. Der neue Nutzerauftrag ersetzt die CSV-/IfcGUID-Vorgaben und
 die alte Phasenliste 14.0–14.6. R1 bereinigt die bestehenden Dokumente; R0
 ändert weder Laufzeitcode noch Datenbank noch Oberfläche.
 Die 13 Freigabekorrekturen vom 29.09.2026 sind in den
 [verbindlichen Anforderungen](revit-excel-integration-requirements.md) und im
 [R0–R10-Plan](revit-excel-phase-14-plan.md) eingearbeitet. Bei Abweichungen
 gelten diese beiden R1-Dokumente.
 ## 1. Geprüfter Bestand und Keep/Change/Remove
 Gelesene Grundlagen: `AGENTS.md`, `docs/current-architecture.md`,
@ -90,7 +95,7 @@ Die Datei ist unversioniert und darf nicht committed werden.
 | Objektidentitäten | 487 syntaktisch passende Worksharing-IDs, keine Duplikate |
 | Kopfzeilenkommentare | 14, zu den 14 Spalten nach der ID-Spalte |
 | Fehlende Raumangaben | 67 Objekte ohne Raumnummer und Raumname |
-| IfcGUID-Duplikate | 2 Gruppen nichtleerer doppelter Werte |
+| IfcGUID-Duplikate | Keine bei exaktem, case-sensitivem Vergleich |
 | Formeln | Keine; synthetische Tests dafür erforderlich |
 | Spaltendefinitionen | 16, obwohl nur 15 Datenspalten vorhanden sind |
@ -100,9 +105,15 @@ gekürzt werden. Das Muster enthält die neuen getrennten Stromkreisfelder und
 die Bezeichnung noch nicht. Fehlende Rückgabespalten werden angezeigt; sie
 dürfen nicht ohne Linear-Parameterbindung erfunden werden.
 Die frühere Angabe von zwei IfcGUID-Duplikatgruppen war falsch: PowerShells
 standardmäßiges Gruppieren verglich ohne Beachtung der Groß-/Kleinschreibung.
 Ein erneuter ordinaler, case-sensitiver Vergleich ergab keine Duplikate. Die
 Summenzeile hat nur in B490 einen Wert; `Familie und Typ` ist leer.
 Nicht nachgewiesen: erfolgreicher Rückimport in Linear, dessen genaue
-Auswertung der Kommentar-/VML-Metadaten und der ExcelJS-Roundtrip. R2 prüft
+Auswertung der Kommentar-/VML-Metadaten und der ExcelJS-Roundtrip. R2 endet
-die Struktur, R8/R10 benötigen zusätzlich einen realen Linear-Abnahmelauf.
+deshalb mit einer aus der Musterdatei erzeugten Rückgabedatei und einem
 verbindlichen Linear-Test durch den Nutzer vor R3.
 ## 3. Bibliothek, Adapter und Uploadgrenzen
@ -123,18 +134,12 @@ Blocker wird die Bibliotheksentscheidung neu vorgelegt.
 Vorgeschlagene Grenzen, zentral konfiguriert und synthetisch getestet:
- ausschließlich `.xlsx`, passender OOXML-Inhalt und ZIP-Signatur; kein
+- ausschließlich `.xlsx`, kein `.xls` oder `.xlsm`;
-  `.xlsm`, verschlüsseltes Archiv, VBA, ActiveX oder externe Workbook-Links;
+- maximal 10 MiB Upload;
- maximal 10 MiB Upload, 100 MiB tatsächlich entpackte Daten, 2.000 ZIP-
+- genau ein Arbeitsblatt und keine Formelausführung;
-  Einträge, 50.000 Zeilen, 256 Spalten und 2 Millionen materialisierte Zellen;
+- feste Zeilen-, Spalten- und Zellgrenzen nach dem Einlesen.
- genau ein Arbeitsblatt; keine Formelausführung, kein Nachladen von URLs;
+
- ZIP-Vorprüfung vor ExcelJS: Verzeichniseinträge, doppelte Pfade,
+Es gibt keinen eigenen ZIP-Prüfer und keinen Parser-Worker.
  Kompressionsverfahren und tatsächliche entpackte Bytezahl prüfen.
  Zentralverzeichnisangaben allein schützen nicht vor manipulierten Archiven.
  Begrenzte Dekompression mit Node-Bordmitteln, keine zweite direkte Library;
 - Parser in begrenztem Worker mit Zeit-/Speichergrenze; Abbruch ohne DB-
  Schreibvorgang. API-Body-Limit auf Uploadgrenze einschließlich Base64-
  Overhead abstimmen, statt global beliebige Requestgrößen zuzulassen.
 Neutrale Matrix: Blattname, Kopfzeilen-/Startpositionen, Spaltenmetadaten
 (Index, Name, Kommentartext, erkannter Parametertyp/Einheit), geordnete
@ -144,11 +149,14 @@ optionale Transportmetadaten; fachlich zählt nur der gecachte skalare Wert.
 Fehlender Cache oder Fehlerwert erzeugt einen Hinweis bzw. bei Pflichtfeldern
 einen Blocker. Originalbytes bleiben unverändert gespeichert.
-Fehlende ID bei sonstigen Objektdaten blockiert; Leer-/eindeutige Summenzeilen
+Eine Zeile ohne Worksharing-ID ist nur verdächtig, wenn `Familie und Typ`
-werden ignoriert. Nicht passende nichtleere IDs blockieren ebenfalls.
+gefüllt ist. Sie erzeugt einen Hinweis und wird übersprungen, ohne zu
-Worksharing-ID bleibt als Quelltext erhalten, Matching ist exakt; ungültige
+blockieren. Andere ID-lose Zeilen, auch die Summenzeile mit Inhalt in B,
-Leerzeichen/uneindeutige Schreibweisen werden gemeldet statt still korrigiert.
+werden still übersprungen. Nicht passende nichtleere IDs blockieren.
-IfcGUID wird optional gespeichert, doppelte Werte sind nur Hinweise.
+Worksharing-ID und IfcGUID bleiben als Quelltext erhalten und werden exakt,
 ordinal und case-sensitiv verglichen; ungültige äußere Leerzeichen werden
 gemeldet statt still korrigiert. IfcGUID wird optional gespeichert, doppelte
 Werte sind nur Hinweise.
 Numerische Projektion rundet Leistung auf 0,01 W, nicht die gespeicherte
 Quellzelle. Mengen aus `socketCount` müssen positive ganze Zahlen sein.
@ -170,8 +178,7 @@ Neuer neutraler Vertrag `ExternalModelConfiguration`, Schema-Version 1:
 {
  schemaVersion: 1,
  layout: {
-    headerRow: 1, firstDataRow: 3, firstDataColumn: 1,
+    headerRow: 1, firstDataRow: 3, firstDataColumn: 1
    idColumn: "Worksharing-ID"
  },
  circuitMode: "combined" | "separate",
  columns: {
@ -200,8 +207,8 @@ Neuer neutraler Vertrag `ExternalModelConfiguration`, Schema-Version 1:
 ```
 Zeilen/Spalten sind intern 1-basiert; UI stellt Spalten als A, B, … dar.
-`layout.idColumn` und `columns.worksharingId` werden gemeinsam gesetzt und
+Es gibt nur `columns.worksharingId` und kein separates `layout.idColumn`.
-müssen übereinstimmen. Jede gemappte Kopfzeile muss eindeutig auflösbar sein;
+Jede gemappte Kopfzeile muss eindeutig auflösbar sein;
 doppelte Ausgabebelegungen werden abgelehnt. Freie Eingabe bleibt zulässig,
 aber ein nicht existierender Name erzeugt vor Import/Export einen konkreten
 Fehler. Erkennung und Vorbelegung nutzen die exakten Standardnamen aus dem
@ -217,8 +224,8 @@ Referenzierte Gerätearten können nicht kommentarlos entfernt werden.
 Startwerte: je Feld ProjectDevice vor Geräteart vor leer. Anzeigename:
 Auswahlkenner, sonst Geräteartname, sonst Familie/Typ. Quellleistung bleibt
 Quelle; eine Übernahme geschieht nur als sichtbare Planungsentscheidung.
-Fehlender GZF bleibt vor Zuordnung leer; verlangt der Row-Vertrag einen Wert,
+Fehlender GZF wird sichtbar mit `1` vorbelegt, ohne zusätzliche Bestätigung.
-wird `1` sichtbar vorgeschlagen und ausdrücklich bestätigt. Geräteart-
+Geräteart-
 Änderungen schreiben keine vorhandenen Objekt-Overrides oder Rows um.
 ## 5. Konkretes Persistenzschema
@ -228,20 +235,21 @@ Bestehende UUID-/Projekt-FKs und Eigentumsprüfungen werden beibehalten.
 | Tabelle | Zielspalten / Constraints |
 | --- | --- |
-| `external_model_configurations` (ersetzt CSV-Tabelle) | `id TEXT PK`, `project_id TEXT NOT NULL UNIQUE FK projects`, `configuration_version INTEGER NOT NULL CHECK > 0`, `configuration JSON NOT NULL`. Enthält obiges vollständiges Aggregat. |
+| `external_model_configurations` (ersetzt CSV-Tabelle) | `id TEXT PK`, `project_id TEXT NOT NULL UNIQUE FK projects`, `configuration JSON NOT NULL`. Enthält obiges vollständiges Aggregat; keine eigene Versionszählung. |
 | `external_model_sources` | `id`, `project_id UNIQUE`, `name`, `source_type = revit_xlsx`. Genau eine implizite Quelle je Projekt. |
-| `external_import_batches` | Bestehende IDs, Importart, Zeit, Dateiname, SHA-256, `applied_project_revision`, `configuration_version`, `configuration_snapshot JSON`, `original_bytes BLOB`, `document JSON`; Matrix jetzt typisiert und transportneutral. Unveränderlich innerhalb des aktiven Zustands; Undo/Restore darf ganze Batches entfernen/wiederherstellen. |
+| `external_import_batches` | Letzter Batch vollständig mit IDs, Importart, Zeit, Dateiname, SHA-256, Objektzahl, `applied_project_revision`, `configuration_snapshot JSON`, `original_bytes BLOB`, `document JSON`; ältere Batches nur als Metadaten Datum, Dateiname, SHA-256 und Objektzahl. |
 | `external_room_mappings` | Vorhandene Felder einschließlich normalisiertem Quellraumschlüssel, `room_id`, `default_distribution_board_id`; UNIQUE `(source_id, normalized_source_room_key)` bleibt. |
 | `external_model_objects` | Bestehende interne IDs/Links; neu `worksharing_id TEXT NOT NULL`, UNIQUE `(source_id, worksharing_id)`; `ifc_guid TEXT NULL`, ohne Unique; `device_type_id TEXT NOT NULL` als validierter Verweis in das Konfigurationsaggregat. |
 | Objektzustand | `accepted_source_values JSON` mit rohen typisierten Werten für Raum, Familie/Typ, Marker, Menge, Bemerkung und alle Rückgabefelder; `planning_values JSON` mit Anzeigename, Kategorie, Anschlussart, effektiver Menge, Einzelleistung W, nullable GZF/cosPhi/Kostengruppe/Bemerkung; `overridden_fields JSON`; bisherige Batch-/Raum-/Board-/ProjectDevice-/Row-Verweise und `presence_status` bleiben. |
-| `external_export_batches` (neu) | `id TEXT PK`, `project_id FK`, `project_revision INTEGER`, `import_batch_id TEXT`, `exported_at_iso TEXT`, `file_name TEXT`, `sha256 TEXT`, `configuration_version INTEGER`, `scope TEXT`, `object_count INTEGER`. Append-only Audit-Store. |
+| `external_export_batches` (neu) | `id TEXT PK`, `project_id FK`, `project_revision INTEGER`, `import_batch_id TEXT`, `exported_at_iso TEXT`, `file_name TEXT`, `sha256 TEXT`, `configuration_snapshot/hash`, `scope TEXT`, `object_count INTEGER`. Append-only Audit-Store. |
 `import_batch_id` des Exportnachweises ist absichtlich eine historische UUID
 ohne löschenden FK: Undo eines Imports oder Snapshot-Restore darf den Nachweis
 nicht entfernen. Exportnachweise liegen außerhalb rücksetzbarer Fachsnapshots
 und werden beim Projektduplikat nicht als dort erfolgte Exporte ausgegeben.
 Sie bleiben beim Originalprojekt erhalten; diese Abgrenzung wird in R1
-dokumentiert. Importbatches selbst gehören vollständig zu Snapshot/Transfer.
+dokumentiert. Nur der letzte Importbatch gehört mit Bytes und Matrix zu
 Snapshot/Transfer; ältere Batches werden dort nur als Metadaten erhalten.
 Indices: bisherige Projekt-/Presence-, Board- und Row-Indices behalten;
 zusätzlich `(project_id, device_type_id)`, `external_room_mapping_id`,
@ -252,9 +260,9 @@ Transaktion; bloße Existenz eines UUID-FK genügt nicht.
 Effektiver Verteiler: ein gemeinsamer Resolver verwendet bei verknüpften
 Objekten die Row/Circuit-Verteilung, sonst die Objektabweichung, sonst die
 Raumvorgabe. `distributionBoardId = null` bedeutet Raumvorgabe verwenden;
-bei fehlender Vorgabe ist das Objekt ohne Verteiler. Room-/Board-
+bei fehlender Vorgabe ist das Objekt ohne Verteiler. Eine Änderung des
-Sammeländerungen prüfen alle betroffenen Row-Links und lehnen inkonsistente
+Raum-Standardverteilers betrifft nur unzugeordnete Objekte; verknüpfte Objekte
-Umbuchungen ab, bis diese ausdrücklich gelöst/verschoben sind.
+folgen immer der Row-Verteilung und blockieren diese Änderung nicht.
 Planungswerte bleiben von Quellwerten getrennt. Nach Row-Zuordnung sind
 Objekt-Planungswerte eingefrorene Startwerte; Anzeige, Abweichung und Export
@ -272,7 +280,7 @@ Snapshots der betroffenen Datensätze, keine ungesicherten Teilpatches.
 | Command | Payload-Skizze und Gegenrichtung |
 | --- | --- |
-| `external-model-configuration.update` v1 | `{ expected, target }` einschließlich Layout, Mapping, Gerätearten und Regeln. Inverse tauscht Fachinhalt; Versionsgeneration siehe unten. |
+| `external-model-configuration.update` v1 | `{ expected, target }` einschließlich Layout, Mapping, Gerätearten und Regeln. Inverse tauscht den vollständigen Fachinhalt; keine eigene Konfigurationsversion. |
 | `external-import.apply-initial` v2 | `{ expectedConfiguration, targetConfiguration, expected, target }`. Quelle, Batch, Mapping, Objekte und neue Regeln zusammen; Inverse stellt leeren externen und vorherigen Konfigurationsinhalt wieder her. Keine Rows. |
 | `external-import.apply-follow-up` v1 | `{ configuration: transition, batch: transition, roomMappings: transitions, objects: transitions, rows: quantityTransitions, decisions }`; Server erzeugt deterministischen Diff und alle UUIDs. Inverse tauscht alle betroffenen Zustände. |
 | `external-model-object.update-planning` v1 | `{ objects: transitions }`; nur ungebundene Objekte; geänderte Felder in Overrides. Einzel-/Sammelbearbeitung identischer Regeln. |
@ -290,32 +298,29 @@ Entwürfe und werden erst mit dem Import atomar persistiert. Nach separater
 Kataloganlage aktualisiert der Wizard die Projektrevision und plant neu,
 ohne lokale Entscheidungen zu verlieren.
-Konfigurationsgeneration: `configurationVersion` erhält bei jedem
+Die Konfiguration hat keine eigene Versionszählung. Vorschau und Apply binden
-Konfigurationswechsel einschließlich Undo/Redo/Restore die neu entstehende
+sich an `expectedRevision`; weil auch Undo/Redo neue, strikt steigende
-Projektrevision. Sie ist damit strikt steigend, aber nicht lückenlos.
+Projektrevisionen erzeugen, wird ein veralteter Plan eindeutig ungültig.
-Historienbefehle vergleichen den erwarteten Fachinhalt und die aktuelle
+Importbatches speichern eine vollständige Konfigurationskopie. Prüfen:
-Projektversion; die administrative Generation wird serverseitig neu erzeugt.
+Änderung → Undo → anderer Zweig darf niemals denselben Plan wieder gültig
-Die Inverse restauriert alle Fachwerte exakt, nicht einen alten Zählerstand.
+machen.
 Importbatches behalten ihre ursprüngliche Generation und ihren Snapshot.
 Ein Restore/Projekttransfer erhält diese Herkunft; die aktive Konfiguration
 wird an die Revision des Zielprojekts gebunden. Prüfen: Änderung → Undo →
 anderer Zweig darf niemals denselben Vorschau-Token wieder gültig machen.
 XLSX wird vor der synchronen SQLite-Transaktion in einer serverinternen
 Vorbereitung geparst. Apply überträgt Bytes erneut; Hash, Matrix und
 Entscheidungen werden erneut validiert. Im Store werden Revision,
-Konfigurationsinhalt/-generation, erwartete Objekte, Links und vollständiger
+Konfigurationsinhalt, erwartete Objekte, Links und vollständiger
 vorbereiteter Plan atomar geprüft. Vorbereitete Daten sind keine vom Client
 behauptete Validierung: Generic-Command-Requests dürfen Importcommands nicht
-an dieser serverseitigen Vorbereitung vorbeischleusen. Undo/Redo benutzen
+an dieser serverseitigen Vorbereitung vorbeischleusen. Undo/Redo lesen und
-denselben Prüfdienst für persistierte Bytes vor der Transaktion. Keine
+parsen keine Excel-Datei; sie wenden ausschließlich die gespeicherten
-asynchronen Callbacks in `better-sqlite3`-Transaktionen.
+Vorher-/Nachher-Zustände an. Keine asynchronen Callbacks in
 `better-sqlite3`-Transaktionen.
-Allgemeine Row-/Circuit-/Gruppen-/Board-/Raum-/ProjectDevice-Löschungen
+Row-/Circuit-/Gruppen-Löschcommands erfassen verknüpfte Objekte vollständig.
-erhalten Guards, solange externe Referenzen betroffen sind. Nutzer lösen die
+Nach der Warnung `X Revit-Objekte werden wieder unzugeordnet` lösen sie die
-Referenzen zuvor ausdrücklich über die passenden Commands. Guards gelten
+Links im selben Command; ihre Inverse stellt sie exakt wieder her. Sperren
-auch in Unterbaum- und History-only-Pfaden. Dadurch werden vorhandene
+bleiben nur für das Löschen referenzierter Verteiler und Räume und gelten auch
-Commands nicht unbemerkt zu unvollständigen externen Löschcommands.
+in Unterbaum- und History-only-Pfaden.
 ## 7. Migration, Snapshot 10, History und Transfer
@ -351,7 +356,8 @@ allgemeine Commands können nach dem Reset zusätzlich an ihren exakten
 Vorbedingungen scheitern; das bleibt eine sichere, sichtbare Ablehnung.
 Snapshot v10 enthält aktive Excel-Konfiguration, Gerätearten/Regeln, Quelle,
-alle Batches mit Originalbytes/Matrix, Raum-Mappings, Objekte und Links.
+den letzten Batch mit Originalbytes/Matrix, ältere Batches nur als Metadaten
 sowie Raum-Mappings, Objekte und Links.
 Upgrade v1–9: bestehende nicht-externe Upgrader erhalten. Nur wenn
 `externalCsvConfiguration` fehlt/null ist **und** der externe Zustand leer
 ist, verlustfrei auf v10 heben. Auch eine gespeicherte CSV-Konfiguration
@ -389,12 +395,13 @@ separater append-only Audit-Write, ohne Projektrevision oder Undo-Schritt.
 Bei Auditfehler kein Erfolg/download; ein Eintrag belegt Dateierzeugung,
 nicht einen tatsächlich abgeschlossenen Browserdownload.
-Die Revit-Seite zeigt Status, Aktionen und eine paginierte Objekttabelle
+Die Revit-Seite lädt einmal eine kompakte Objektliste. Filterung und Sortierung
-(Vorschlag: 100 Zeilen pro Seite). Filter-/Sortierzustand, UUID-Auswahl und
+laufen im Client; die Tabelle wird virtualisiert und verwendet keine Server-
-Sammelaktionen sind unabhängig vom DOM. „Alle gefilterten“ verwendet eine
+Pagination. Filter-/Sortierzustand, UUID-Auswahl und Sammelaktionen sind
-explizit aufgelöste Auswahl zur bekannten Revision; keine Mutation anhand
+unabhängig vom DOM. „Alle gefilterten“ wird vor einer Mutation zu einer
-eines inzwischen veränderten Filters. Große Auswahlmengen werden nicht in
+expliziten ID-Auswahl an der aktuellen Revision aufgelöst. Große Auswahlmengen
-getrennte Undo-Schritte aufgeteilt. Kein vollständiges Batch-Blob im DTO.
+werden nicht in getrennte Undo-Schritte aufgeteilt. Kein vollständiges
 Batch-Blob im DTO.
 Einstellungen verwenden Musterdatei-Erkennung mit editierbaren Positionen,
 Feld-Dropdowns/freier Eingabe und Kommentar-Typ-/Einheitenanzeige. Regeln
@ -430,10 +437,10 @@ gegen den **zuletzt importierten**, nicht den zuletzt exportierten Stand.
 Umfang: alle im letzten Batch vorhandenen Objekte / abweichende / explizite
 Auswahl. Fehlende Objekte haben keine aktuelle Originalzeile und werden
 nicht künstlich wieder eingefügt. Alle Spalten bleiben, nicht ausgegebene
-Parameter behalten importierte Werte. Fehlende benötigte Zielspalten bzw.
+Parameter behalten importierte Werte. Fehlende optionale Spalten für
-Linear-Bindungen blockieren die betreffende Exportkonfiguration mit Hinweis
+Bezeichnung, Leistung, Spannung und Strom werden mit Hinweis übersprungen.
-auf einen neuen vollständigen Linear-Export. Dateiname gemäß Auftrag mit
+Nur fehlende Stromkreisspalten des gewählten Modus blockieren. Dateiname gemäß
-bereinigtem Projektnamen und Tagesdatum.
+Auftrag mit bereinigtem Projektnamen und Tagesdatum.
 Folgeimport matcht ausschließlich Worksharing-ID. Ein neuer Batch speichert
 immer den vollständigen letzten Quellstand. Unveränderte Objekte werden
@ -457,12 +464,12 @@ nach Freigabe; keine Fortschreibung der alten 14.0–14.6-Liste.
 | Paket | Arbeit und entscheidende Abnahme |
 | --- | --- |
 | R1 | Neue Excel-Anforderungen und R0–R10-Plan; alte Dokumente archivieren/auf Verweise kürzen; AGENTS, Architektur, History-Doku, Phase-14-Abschnitt, LLM-Kontext und alle Links nachziehen. Referenzdatei gezielt ignorieren. |
-| R2 | XLSX-Adapter und lokaler Referenzprüfer mit Pfadargument. Synthetischer Roundtrip für Kommentare, Blattname, Spaltenbreiten, Typen, Header-/Startpositionen, unbekannte Spalten, Auswahl und Summenausschluss; ZIP-/Formelgrenzen. Keine DB-Änderung. |
+| R2 | XLSX-Adapter und lokaler Referenzprüfer mit Pfadargument. Synthetischer Roundtrip für Kommentare, Blattname, Spaltenbreiten, Typen, Header-/Startpositionen, unbekannte Spalten, Auswahl und Summenausschluss. Aus der lokalen Musterdatei entsteht eine Rückgabedatei mit geänderten Werten. Danach Nutzerabnahme in Linear; R3 bleibt bis zum Erfolg gesperrt. Bei Fehlschlag vor R3 OOXML-Direktänderung als Alternative vorlegen. Keine DB-Änderung. |
 | R3 | Neue Konfiguration/Identität, additive Migration, Snapshot 10, Transfer und History-Ablehnungen; Backend-CSV entfernen. Parser-Vorbereitung von synchroner Transaktion trennen. |
 | R4 | Revit-Seite, Navigation, Einstellungen; Projektseitenmodal und dessen CSV-Frontend-Verträge entfernen. |
 | R5 | Erstimport mit atomaren Regeln, Geräten, Raum-/Board- und Objektentscheidungen; ProjectDevice-Vorbelegung nach Priorität; ein Import-Undo-Schritt. |
-| R6 | Objekt-Reads, Paging/Filter, Sammel-Commands und Overrides; verwandte Lösch-/Referenzguards vollständig absichern. |
+| R6 | Kompakte Objekt-Reads, clientseitige Filter/Sortierung, Virtualisierung, Sammel-Commands und Overrides. |
-| R7 | Gruppierung, Drag-and-drop, Row-Indikatoren und Lösen inklusive aktueller Row-Werte; drei Drop-Ziele und Reload/Undo/Redo. |
+| R7 | Gruppierung, Drag-and-drop, Row-Indikatoren und Lösen inklusive aktueller Row-Werte; drei Drop-Ziele, atomare Objektlösung beim Row-/Circuit-/Gruppen-Löschen und Reload/Undo/Redo. |
 | R8 | Drei Exportumfänge, gemeinsame Abweichungsprojektion, typisierte Rückgabe, append-only Nachweis und Linear-Strukturabnahme. |
 | R9 | Kontrollierter Folgeimport, fehlende Objekte, explizites Löschen, mengenwirksame Entscheidungen und atomare Inverse. |
 | R10 | Vollständige synthetische Ende-zu-Ende-Kette einschließlich Neustart, Snapshot/Restore und Duplikat; mehrere Tausend Objekte; Doku auf ausgelieferten Stand. |
@ -492,19 +499,19 @@ Zusätzlich erforderliche neue Prüfungen:
 - Migration mit externen Row-Anteilen; keine Phantomlast und unveränderte BMKs.
 - v1–9 ohne CSV verlustfrei, mit CSV klare Ablehnung; alte Command-Inversen
  und alte Restore-Payloads ebenfalls ohne Teilwrites ablehnen.
- Config-Änderung/Undo/Neuzweig invalidiert alte Pläne; Apply mit anderem
+- Config-Änderung/Undo/Neuzweig invalidiert alte Pläne über `expectedRevision`; Apply mit anderem
  Dateiinhalt, fehlenden Entscheidungen oder fremden UUIDs rollt vollständig
  zurück. Später Historyfehler rollt auch Regeln, Links und Mengen zurück.
 - Gebundene Row ändern → Export → Lösen → Undo/Redo behält fachliche Werte.
 - Mehrfachsteckdosen: unterschiedliche effektive Mengen, identische
  Einzelwerte, richtige Gruppierung und objektweise Rückgabeleistung.
- Löschen über alle Unterbaum-/History-Pfade kann externe FKs nicht still
+- Row-/Circuit-/Gruppen-Löschen löst externe Links im Command und stellt sie
-  nullen. Fremde Verteilungen/Räume/Kategorien und Gerätearten blockieren.
+  per Undo wieder her. Raum-/Verteilerlöschen mit Referenzen blockiert.
 - Export-Audit scheitert: keine fachliche Revision; SHA-256 entspricht exakt
  den gelieferten Bytes. Snapshot/Restore entfernt keine Exportnachweise.
 - 5.000/10.000 synthetische Objekte: Parserzeit, Peak-Speicher, Payloadgröße,
-  Command-/Snapshot-Dauer und UI-Reaktionszeit messen; höchstens eine
+  Command-/Snapshot-Dauer und UI-Reaktionszeit messen; nur sichtbare Zeilen im
-  paginierte Seite im DOM, stabile Auswahl über Seitenwechsel.
+  DOM, stabile Auswahl über virtuelle Bereiche.
 Wesentliche Restrisiken: Linear-Kommentarbindung ist nur anhand des
 Exports beobachtet; ExcelJS-Releasepflege und Roundtrip sind in R2 zu
@ -515,7 +522,7 @@ externen Zustand begrenzt und nur nach verifiziertem Backup zulässig.
 Fehlende Zielparameter im Muster verlangen einen neuen vollständigen
 Linear-Export, keine geratenen GUID-Kommentare.
-**Freigabepunkt:** Der Nutzerauftrag verlangt wörtlich
+**Freigabepunkt:** R0 wurde am 29.09.2026 mit den in R1 dokumentierten
-„R0. Audit (danach stoppen und Freigabe abwarten)“.
+Korrekturen freigegeben. R2 besitzt einen neuen verbindlichen Freigabepunkt:
-Mit Freigabe dieses Vorschlags beginnt R1; R0 selbst autorisiert keine
+Vor Beginn von R3 muss der Nutzer die in R2 erzeugte Rückgabedatei erfolgreich
-Installation, Migration oder Implementierung von R1–R10.
+in Linear getestet haben.