diff --git a/.gitignore b/.gitignore index acbb157..b237969 100644 --- a/.gitignore +++ b/.gitignore @@ -9,5 +9,3 @@ dist/ data/*.db data/backups/*.db .codex/*.log -/docs/spec/kbp-Stromkreis.xlsx -/data/revit-reference/*.xlsx diff --git a/AGENTS.md b/AGENTS.md index e8d4bff..b01e6b5 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -295,10 +295,7 @@ not change the project revision or undo/redo stacks. Restoring a server-stored snapshot verifies its checksum and the current-state hash, replaces supported project data atomically and records a new `restore` revision with a complete inverse command. Restore can therefore be undone and redone after a restart. -Current snapshot schema version 10 stores the Linear-XLSX configuration and -external state with Worksharing-ID identity. Empty versions 1 to 9 are upgraded; -versions containing legacy CSV configuration or external CSV state are rejected -with a German migration error. Version 9 additionally stores +Current snapshot schema version 9 additionally stores `feedingDistributionBoardId` and `feedingCircuitId` on distribution boards; versions 1 to 8 are upgraded with both references set to `null`. Version 8 stores the optional net room area `rooms[].areaM2` (see @@ -310,8 +307,8 @@ distribution-board info fields `boardNumber`, `location`, `fedFrom` and `remark` and the project cover fields `siteAddress`, `workStage`, `projectLead` and `projectEditor`; all older supported versions are upgraded with `null` for these fields. -Stored named and automatic snapshots of versions 1 to 9 remain restorable when -they contain no legacy CSV state; they are upgraded while parsing. Version 5 stores +Stored named and automatic snapshots of every supported version (1 to 9) +remain restorable; they are upgraded while parsing. Version 5 stores the manual quantity share of every CircuitDeviceRow. Version 4 snapshots are upgraded with `manualQuantity = quantity`; they already contain the complete confirmed external-model source, import batches, room mappings and objects. Version 3 @@ -323,21 +320,29 @@ 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. -R3 replaced the runtime configuration and persistence foundation with Linear -XLSX and exact case-sensitive Worksharing-ID identity. Migration `0014` drops -the old development-only external CSV data after resetting linked row totals to -their manual share. Snapshot schema 10, restore and project transfer use the -new state; non-empty legacy CSV snapshots and legacy CSV history entries are -rejected with a German error. The backend CSV parser and routes are removed. -R4 adds `/projects/:projectId/revit`, its revisioned XLSX settings and -server-side sample detection, and removes the old project-page CSV modal. See -`docs/spec/revit-excel-integration-requirements.md` and -`docs/spec/revit-excel-phase-14-plan.md`. - -The target configuration has no independent version counter; `expectedRevision` -invalidates stale plans, and each import batch stores a configuration copy. -Only the newest import batch retains workbook bytes and the full matrix; older -batches retain date, filename, SHA-256 and object count. +Project-wide Revit CSV configuration uses +`external-csv-configuration.update`. Its complete expected/target snapshot is +persisted through the shared project-command transaction, so create, update, +delete, Undo and Redo are revision-safe. Snapshot schema 5-9, restore and portable +project duplication preserve the configuration; duplication remaps its internal +id and project link. +The project page exposes the Revit CSV modal. It edits the complete +transport/column/family-rule configuration through the revision-safe endpoint, +requests a stateless preview and then shows the Phase 14.2 initial-import +decisions. Preview responses include all mapped objects, while the UI renders +only the first 25. No preview or plan creates external objects, rows, revisions +or server-side drafts. +Phase 14.2 migration `0003` provides one implicit Revit CSV source per project, +immutable import batches with original bytes plus the classified cell matrix, +normalized source-room mappings and external objects unique by +`(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. @@ -358,12 +363,37 @@ 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 current read-only +The read-only `GET /api/projects/:projectId/circuit-lists/:circuitListId/external-objects` -projection resolves the board through the owned CircuitList and returns compact -legacy external objects. The target Revit page will load one compact project -list and filter/sort it client-side in a virtualized table, without server -pagination or batch blobs in the DTO. +projection resolves the board through the owned CircuitList and returns only +that board's compact external objects, unassigned first. It exposes no original +CSV bytes or command payloads and returns an empty list before optional import. +Confirmed initial state is written only through +`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. @@ -545,57 +575,70 @@ 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 / Linear Excel External Model Work +## Revit / CSV External Model Work -Phase 14 is active and follows -`docs/spec/revit-excel-integration-requirements.md` plus -`docs/spec/revit-excel-phase-14-plan.md`. The old CSV requirements and phases -14.0–14.6 are superseded. Dynamo, Revit API and JSON transport remain excluded. +Status: further Revit work (editor assignment UI, follow-up import, return +export) is deferred and will be tackled later. When it resumes, the exchange +stays CSV-based and uses the CSV export/import of the Linear plugin in Revit. +The internal Revit/CAD steering committee prefers this over manipulating the +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`. -Critical target rules: +When explicitly working on Phase 14, use +`docs/spec/revit-csv-integration-requirements.md` as the detailed source of +truth together with the current architecture documents. -- 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. -- The corrected R2 return workbook was successfully imported into Linear on - 2026-09-30; R3 and R4 are complete and R5 is the next package. -- 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. +Critical rules: -The real sample `docs/spec/kbp-Stromkreis.xlsx` contains project data. It is -gitignored and must never be embedded in tests or committed. Use synthetic -workbooks for automated tests and accept the real file only as an explicit -local path in the reference checker. +- Revit integration is optional. Do not make imported external data mandatory + for projects, rooms, project devices, circuits or device rows. +- Parse imports into staging first. Never write CSV rows directly into circuits + or device rows. +- 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 @@ -690,6 +733,9 @@ 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 diff --git a/README.md b/README.md index b70a145..f64ae04 100644 --- a/README.md +++ b/README.md @@ -9,11 +9,11 @@ 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. Die Backend- und Persistenzgrundlage der bisherigen -Revit-CSV-/IfcGUID-Anbindung ist durch den XLSX-Austausch des Linear-Plugins mit -Worksharing-ID als externem Schlüssel ersetzt. R0 bis R4 sind abgeschlossen; -die eigene Revit-Seite mit XLSX-Einstellungen ist vorhanden. Erstimport, -Editorzuordnung, Rückgabe und Folgeimport folgen in R5 bis R10. +vorhanden. Revit-CSV-Konfiguration, Vorschau +und bestätigter Erstimport sind implementiert; die Editoroberfläche zur +Objektzuordnung, Folgeimporte und Rückexport stehen noch aus. Die weitere +Revit-Arbeit ist zurückgestellt und erfolgt später über den CSV-Export/-Import +des Linear-Plugins in Revit. ## Unterstützter Arbeitsablauf @@ -40,9 +40,9 @@ Editorzuordnung, Rückgabe und Folgeimport folgen in R5 bis R10. - grobe Leistungsbilanzen für LPH 2/3 nach Kostengruppen führen, mit der detaillierten Bilanz vergleichen und einzelne Zeilen als Projektgerät übernehmen -- Linear-XLSX-Dateien verlustarm lesen und schreiben; Revit-Seite, - Erstimport, Editorzuordnung, Rückgabe und Folgeimport werden gemäß - Phase-14-Plan in den nächsten Paketen angebunden +- Revit-CSV-Dateien konfigurieren, prüfen und nach expliziter Zuordnung von + Räumen, Verteilungen und Projektgeräten erstmals importieren; dabei entstehen + noch keine Stromkreise oder Gerätezeilen ## Technik @@ -177,8 +177,6 @@ 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 diff --git a/docs/README.md b/docs/README.md index 90c5fc3..3569b42 100644 --- a/docs/README.md +++ b/docs/README.md @@ -31,18 +31,13 @@ ausdrücklich getrennt und dürfen nicht als bereits implementiert verstanden we - [Entwicklungs- und Contributor-Workflow](development-workflow.md) - [Deployment und Betrieb](deployment.md) -## Aktive Revit-Umstellung - -- [Projektversionen und externer Modellaustausch](project-history-and-external-model-architecture.md) -- [Revit-Integration über Linear-Excel](spec/revit-excel-integration-requirements.md) – - verbindliche Anforderungen für XLSX und Worksharing-ID -- [Phase-14-Plan R0–R10](spec/revit-excel-phase-14-plan.md) – Status, - Paketgrenzen und Linear-Freigabepunkt nach R2 -- [R0-Bestandsaudit](spec/revit-excel-r0-audit.md) -- [LLM-Kontext für Phase 14](revit-requirements-llm-context.md) - ## Zukunftsarchitektur +- [Projektversionen und externer Modellaustausch](project-history-and-external-model-architecture.md) +- [LLM-Kontext für die Revit-Anforderungsplanung](revit-requirements-llm-context.md) +- [Revit-CSV-Anforderungen](spec/revit-csv-integration-requirements.md) – + zurückgestellt; später über den CSV-Export/-Import des Linear-Plugins +- [Phase-14-Audit und Implementierungsplan](spec/revit-csv-phase-14-audit-and-plan.md) - [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) diff --git a/docs/building-structure.md b/docs/building-structure.md index 9db2c91..21059b4 100644 --- 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 - aktive Phase 14 verwendet Linear-XLSX; das Modell steht der expliziten - Raumzuordnung im Importwizard nicht im Weg. + Revit-Arbeit ist insgesamt zurückgestellt und läuft später über die + Linear-CSV; das Modell steht einer späteren CSV-Zuordnung 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. diff --git a/docs/circuit-list-editor-known-limitations.md b/docs/circuit-list-editor-known-limitations.md index ee2d470..fdc463a 100644 --- a/docs/circuit-list-editor-known-limitations.md +++ b/docs/circuit-list-editor-known-limitations.md @@ -9,10 +9,9 @@ - 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. -- The current Revit/CSV foundation and confirmed initial import are a legacy - starting point. The active Phase-14 plan replaces them with the Linear XLSX - exchange and exact Worksharing-ID identity. - R2 must pass a real Linear return-import check before database cutover in R3. +- Further Revit work is deferred; it will later use the CSV export/import of + the Linear plugin in Revit, not Dynamo. +- The Revit/CSV foundation and confirmed initial import are implemented. 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 diff --git a/docs/current-architecture.md b/docs/current-architecture.md index 846debb..20c7ccd 100644 --- a/docs/current-architecture.md +++ b/docs/current-architecture.md @@ -510,9 +510,6 @@ Die projektweite Circuit-Tree-Projektion berechnet rekursiv die Lasten aller Verteilungen. Die Leistung einer Unterverteilung nach ihrem eigenen Verteiler-GZF wird als virtuelle, schreibgeschützte Zeile genau dem gewählten Abgang zugerechnet. Eine Verknüpfung ohne Stromkreis bildet nur die Hierarchie. -Snapshot-Schema 10 enthält zusätzlich die Linear-XLSX-Konfiguration und den -externen Zustand mit Worksharing-ID-Identität. Leere Versionen 1–9 werden -hochgestuft; Versionen mit tatsächlichem Legacy-CSV-Zustand werden abgelehnt. Snapshot-Schema 9 enthält die beiden Einspeisungsverweise; Versionen 1–8 werden mit `null` hochgestuft. Restore und Projektduplizierung erhalten beziehungsweise remappen die Verweise. Snapshot-Schema 8 enthält zusätzlich die optionale Netto-Raumfläche @@ -523,9 +520,9 @@ Snapshot-Schema 6 enthält diese Felder und die Deckblattangaben des Projekts; ältere Versionen werden mit `null` hochgestuft. Snapshot-Schema 5 enthält zusätzlich den manuellen Mengenanteil jeder Gerätezeile. Version 4 wird mit `manualQuantity = quantity` hochgestuft und -enthielt bereits den damaligen externen CSV-Modellzustand -aus Quelle, Batches, Raum-Mappings und Objekten. Es enthielt außerdem die -damalige projektweite Revit-CSV-Konfiguration, die Gebäudekennzeichnung sowie den Gleichzeitigkeitsfaktor, +enthält bereits den vollständigen externen Modellzustand +aus Quelle, Batches, Raum-Mappings und Objekten. Es enthält außerdem die +projektweite Revit-CSV-Konfiguration, die Gebäudekennzeichnung sowie den Gleichzeitigkeitsfaktor, Gruppenkategorie und -nummer, Verteilerkomponenten sowie die getrennten 1:1-Schutzgerätedaten. Capture, benannte und automatische Snapshots, Wiederherstellung, Undo/Redo und beide @@ -643,42 +640,11 @@ PostgreSQL ist bewusst nicht implementiert. Die Domainregeln und Transaktionsgrenzen sollen portabel bleiben; Schema und Betriebsmodell benötigen bei einem späteren Wechsel trotzdem einen eigenen PostgreSQL-Adapter. -## Revit-Anbindung: Linear-XLSX-Grundlage nach R3 +## Revit-CSV-Grundlage -R3 hat den Backend- und Persistenz-Cutover abgeschlossen. Migration `0014` -entfernt die alten externen CSV-Entwicklungsdaten, nachdem verknüpfte -Gerätezeilen auf `manualQuantity` zurückgesetzt wurden. Die neue -`external_model_configurations`-Tabelle besitzt keinen eigenen Versionszähler; -Änderungen laufen als Projekt-Commands über `expectedRevision`. - -Externe Objekte werden je Quelle durch `worksharing_id` exakt und -case-sensitiv identifiziert. `ifc_guid` ist nullable und nicht eindeutig. -Importbatches speichern eine Konfigurationskopie; nur der neueste Batch darf -Originalbytes und die vollständige XLSX-Matrix enthalten, ältere Batches nur -Datum, Dateiname, SHA-256 und Objektzahl. Snapshot-Schema 10, Restore und -Projekttransfer verwenden diesen Zustand und remappen alle internen -Konfigurations-, Gerätearten-, Regel- und Objekt-UUIDs. Leere Snapshots 1–9 -werden hochgestuft; alte Snapshots mit CSV-Konfiguration oder externem -CSV-Zustand sowie alte CSV-History-Commands werden mit einer deutschen Meldung -abgelehnt. - -Der XLSX-Adapter liegt unter `src/external-model/xlsx`. Der Backend-CSV-Parser, -seine Endpunkte und Laufzeitverträge sind entfernt. Die noch sichtbare alte -Projektseiten-Oberfläche ist bis R4 ohne Backend-Anbindung und wird dort durch -die Route `/projects/:projectId/revit` ersetzt. - -### Historische Ausgangslage vor R3 - -Der folgende Text beschreibt den Stand nach R1 und ist keine aktuelle -Laufzeitdokumentation mehr. - -Der nachfolgende Abschnitt beschreibt den am Ende von R1 noch vorhandenen -Legacy-Laufzeitpfad. Er verwendet CSV und IfcGUID und ist die geprüfte -Ausgangslage für den schrittweisen Cutover; er darf nicht erweitert werden. -Das verbindliche Ziel ist der XLSX-Austausch des Linear-Plugins mit exakter, -case-sensitiver Worksharing-ID. Details: -[Excel-Anforderungen](spec/revit-excel-integration-requirements.md) und -[R0–R10-Plan](spec/revit-excel-phase-14-plan.md). +**Zurückgestellt:** Die weitere Revit-Arbeit wird später angegangen, dann +über den CSV-Export/-Import des Linear-Plugins in Revit statt über Dynamo. +Details: [Revit-CSV-Anforderungen, Abschnitt 1](spec/revit-csv-integration-requirements.md). Der reine Adapter unter `src/external-model/csv` validiert die projektweite Transport- und Mappingkonfiguration und parst UTF-8-CSV verlustarm in eine @@ -808,33 +774,11 @@ 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 -- Linear-XLSX-Transport, eigene Revit-Seite, Editor-Oberfläche für die - Zuordnungslogik, Folgeimport und strukturtreuer Revit-Rückexport; Umsetzung - folgt dem R0–R10-Plan +- Editor-Oberfläche für die vorhandene Zuordnungslogik, Folgeimport und + strukturtreuer Revit-Rückexport - vollständige elektrische Dimensionierung - Produktionsdeployment diff --git a/docs/project-history-and-external-model-architecture.md b/docs/project-history-and-external-model-architecture.md index 91b82ca..f8ed263 100644 --- a/docs/project-history-and-external-model-architecture.md +++ b/docs/project-history-and-external-model-architecture.md @@ -9,8 +9,7 @@ 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 the Revit/Linear-XLSX round-trip using stable, exact - Worksharing-ID-based external identity +- support future Revit/CSV round-trips using stable IFCGUID-based links - keep the persistence boundary replaceable so PostgreSQL can be adopted later ## Separate Concerns @@ -112,12 +111,11 @@ Implemented automatic-snapshot policy: - automatic capture and retention run inside the same transaction as the triggering project revision -## Revit / Linear Excel Round-Trip Direction +## Revit / CSV / IFCGUID Round-Trip Direction -Phase 14 is active and follows the -[Linear-Excel requirements](spec/revit-excel-integration-requirements.md) and -[R0–R10 plan](spec/revit-excel-phase-14-plan.md). The existing CSV/IFCGUID -runtime is a legacy starting point for the cutover, not the target model. +**Deferred:** further Revit work will be tackled later, then through the +CSV export/import of the Linear plugin in Revit instead of Dynamo. Details: +[Revit-CSV requirements, section 1](spec/revit-csv-integration-requirements.md). External model exchange should use explicit staging and link entities instead of writing imported rows directly into circuits. @@ -126,12 +124,9 @@ Conceptual entities: - `ExternalModelSource` - identifies a Revit/IFC model or another external source within a project - `ExternalImportBatch` - - 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 + - file name, checksum, import time, format/version and processing status - `ExternalModelObject` - - exact case-sensitive Worksharing-ID as external identity - - optional IfcGUID as non-unique source redundancy + - stable IFCGUID and optional Revit element identifiers - source attributes and last-seen import batch - `ExternalObjectLink` - explicit relationship to a project device, circuit device row or another future domain entity @@ -142,27 +137,13 @@ Conceptual entities: Required behavior: -- Worksharing-ID uniqueness is scoped to the external source and uses exact, - case-sensitive comparison. IfcGUID is not a matching key. +- IFCGUID uniqueness is scoped to project and external model source. - 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 Worksharing-ID so Linear can match rows deterministically. -- 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. +- Export retains IFCGUID and source identifiers so Revit parameters can be matched deterministically. +- Missing objects and duplicate/conflicting identifiers are reported, never silently reassigned. ## SQLite and PostgreSQL Direction @@ -311,8 +292,7 @@ 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 Worksharing-ID or IfcGUID as an overloaded circuit equipment - identifier or an internal relation id +- do not model IFCGUID as an overloaded circuit equipment identifier - keep database backup/restore checks separate from project history tests ## Deferred Decisions @@ -320,6 +300,5 @@ 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 -- Linear-XLSX compatibility beyond the observed sample and any future - project-independent mapping profiles +- supported Revit CSV dialects and parameter mapping UI - PostgreSQL deployment topology and migration date diff --git a/docs/revit-requirements-llm-context.md b/docs/revit-requirements-llm-context.md index 3782150..cf10324 100644 --- a/docs/revit-requirements-llm-context.md +++ b/docs/revit-requirements-llm-context.md @@ -1,15 +1,273 @@ -# LLM-Kontext für die Revit-Integration +# Kontext für die Revit-Anforderungsplanung -Die frühere offene Revit-/CSV-Anforderungsplanung ist abgeschlossen und -abgelöst. Für Arbeiten an Phase 14 sind vollständig zu lesen: +**Zurückgestellt:** Die weitere Revit-Arbeit wird später angegangen, dann +über den CSV-Export/-Import des Linear-Plugins in Revit statt über Dynamo. +Details: [Revit-CSV-Anforderungen, Abschnitt 1](spec/revit-csv-integration-requirements.md). -- [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) +## Zweck dieser Datei -Bei Widersprüchen gilt das Anforderungsdokument. CSV, IfcGUID als Schlüssel, -Dynamo, Revit-API und JSON-Transport sind keine Zielpfade. Der derzeit noch im -Code vorhandene CSV-Stand ist ausschließlich die in R1 dokumentierte -Legacy-Ausgangslage für den schrittweisen Cutover. +Diese Datei ist eine kompakte Übergabe an ein anderes LLM. Sie soll dabei +helfen, gemeinsam mit dem Anwender die fachlichen und technischen Anforderungen +für einen zukünftigen Revit-Datenaustausch zu klären. + +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 diff --git a/docs/spec/07-implementation-phases-todo.md b/docs/spec/07-implementation-phases-todo.md index 0043ef2..f36d60d 100644 --- a/docs/spec/07-implementation-phases-todo.md +++ b/docs/spec/07-implementation-phases-todo.md @@ -532,34 +532,36 @@ Acceptance criteria: ## Phase 14: External Model Round-Trip -Status: R0 ist mit Korrekturen freigegeben; R1 stellt die Dokumentation auf -Linear-XLSX und Worksharing-ID um. Die frühere CSV-Planung 14.0–14.6 ist -abgelöst und wird nicht fortgeschrieben. +**Zurückgestellt:** Die weitere Revit-Arbeit wird später angegangen, dann +über den CSV-Export/-Import des Linear-Plugins in Revit statt über Dynamo. +Details: [Revit-CSV-Anforderungen, Abschnitt 1](revit-csv-integration-requirements.md). -Verbindliche Quellen: +Status: Phase 14.2 (persistente externe Objekte und bestätigter Erstimport) ist +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). -- [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) +Goal: -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. +Exchange model objects and planning parameters with Revit through CSV (Linear plugin export/import). -Kernabnahme der Phase: +Tasks: -- Worksharing-ID ist der exakte, case-sensitive externe Schlüssel; -- XLSX-Kopfkommentare, Struktur, Formate und unbekannte Spalten bleiben beim - Rückexport erhalten; -- Import erzeugt keine Rows und überschreibt keine lokale Planung still; -- Zuordnung, Löschung, Folgeimport und Undo/Redo sind atomar und nach Neustart - reproduzierbar; -- Undo/Redo liest keine Excel-Datei; -- nur der letzte Importbatch enthält Workbook und Matrix vollständig; -- mehrere Tausend Objekte bleiben über eine clientseitig gefilterte, - virtualisierte Liste bedienbar. +- model external sources, import batches and stable IFCGUID objects +- stage and validate imports before applying them +- show additions, changes, missing objects and conflicts +- link external objects explicitly to project-domain entities +- apply an import as one auditable project revision +- configure inbound and outbound parameter mappings +- export against a known project revision while preserving IFCGUID + +Acceptance criteria: + +- 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. diff --git a/docs/spec/08-current-product-backlog.md b/docs/spec/08-current-product-backlog.md index 6d1eae4..c0a2720 100644 --- 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/Linear-XLSX round-trip is now the separately planned active Phase 14. -It uses exact Worksharing-ID identity and must not be inferred from these -unrelated backlog tasks. See -[the R0–R10 plan](revit-excel-phase-14-plan.md). +The Revit/CSV/IFCGUID round-trip follows the distribution-board component +foundation as a separate jointly planned phase and must not be inferred from +these tasks. It is currently deferred and will later use the CSV +export/import of the Linear plugin in Revit, not Dynamo. diff --git a/docs/spec/revit-csv-integration-requirements.md b/docs/spec/revit-csv-integration-requirements.md index 7889566..4ce65ee 100644 --- a/docs/spec/revit-csv-integration-requirements.md +++ b/docs/spec/revit-csv-integration-requirements.md @@ -1,8 +1,1386 @@ -# Abgelöst: Revit-CSV-Anforderungen +# Revit-CSV-Integration – Anforderungen und Implementierungsanweisung -Diese CSV-/IfcGUID-Spezifikation ist seit 29.09.2026 abgelöst. Die verbindliche -Quelle ist [Revit-Integration über Linear-Excel](revit-excel-integration-requirements.md). +## 1. Status und Verbindlichkeit -Der historische Inhalt bleibt im Git-Verlauf bis einschließlich Commit -`ae318a5` erhalten. Er darf nicht mehr als Implementierungsanweisung oder -Statusquelle verwendet werden. +> **Zurückgestellt (September 2026).** Die weitere Revit-Arbeit +> (Editor-Oberfläche zur Objektzuordnung, Folgeimport, Rückexport) wird später +> angegangen. Wenn sie wieder aufgenommen wird, bleibt der Austausch +> CSV-basiert: Export und Import laufen über das Linear-Plugin in Revit. Das +> entspricht der Vorgabe des internen Revit/CAD-Lenkungskreises, weil dabei +> nicht direkt per Dynamo im Modell gearbeitet wird. Eine Dynamo- oder +> API-Anbindung ist nicht vorgesehen; die früheren Vorüberlegungen liegen unter +> [docs/archive](../archive/revit-dynamo-leistungsbilanz-integration-konzept.md). +> Der Aufbau der Linear-CSV ist noch offen. Vor der Wiederaufnahme wird ein +> Musterexport gegen die bestehende projektweite CSV-Konfiguration und den +> Parser geprüft; erst danach wird entschieden, was anzupassen ist. Die bereits +> umgesetzten Schritte bleiben unverändert nutzbar. + +Dieses Dokument ist die verbindliche fachliche und technische Arbeitsgrundlage für **Phase 14: External Model Round-Trip**. + +Es unterscheidet ausdrücklich zwischen: + +- **Bestätigte Anforderung:** vom Anwender festgelegtes Verhalten. +- **Bestehende Architekturvorgabe:** bereits geltende Regel des Projekts. +- **Implementierungsvorschlag:** empfohlene technische Aufteilung, noch kein unveränderliches Datenbankschema. +- **Offene Entscheidung:** darf erst in der jeweils genannten Phase konkretisiert werden. + +Codex darf aus diesem Dokument kein vollständiges Event-Sourcing, keine PostgreSQL-Migration, keine automatische Stromkreisplanung und keine direkte Dynamo-Anbindung ableiten. + +Vor Implementierungsbeginn sind insbesondere zu lesen: + +- `AGENTS.md` +- `docs/current-architecture.md` +- `docs/spec/03-data-model-concept.md` +- `docs/spec/05-linked-devices-and-sync.md` +- `docs/project-history-and-external-model-architecture.md` +- `docs/spec/07-implementation-phases-todo.md` +- `docs/circuit-list-editor-known-limitations.md` + +## 2. Ziel + +Die Anwendung soll Revit-Objekte der Kategorie **Elektroinstallation** über eine CSV-Datei einlesen, dauerhaft anhand ihrer `IfcGUID` erkennen und mit der manuellen Elektroplanung in Leistungsbilanz verbinden. + +Der Workflow soll insbesondere vermeiden, dass Stromkreiskennzeichnungen und Leistungen für jedes Revit-Objekt händisch nachgetragen werden müssen. + +Der Nutzer soll: + +1. Revit-Objekte importieren, +2. Räume aus dem Import anlegen oder vorhandenen Räumen zuordnen, +3. Räume und einzelne Objekte Verteilungen zuordnen, +4. Objekte klassifizieren und optional mit `ProjectDevice`-Vorlagen verknüpfen, +5. noch nicht verschaltete Objekte im Stromkreislisteneditor manuell Stromkreisen und Gerätezeilen zuweisen, +6. Stromkreiskennzeichnung und Leistung in eine strukturgleiche Rückgabe-CSV schreiben, +7. denselben vollständigen Modellstand später erneut importieren und Änderungen kontrolliert abgleichen. + +## 3. Grundlegende Produktgrenzen + +### 3.1 Revit bleibt optional + +**Bestätigte Anforderung** + +Leistungsbilanz muss vollständig ohne Revit-Integration nutzbar bleiben. + +- Projekte, Ebenen, Räume, Verteilungen, Projektgeräte, Stromkreise und Gerätezeilen bleiben manuell anlegbar. +- Ein Projekt darf ausschließlich manuelle Daten, ausschließlich verknüpfte Revit-Daten oder eine Mischung enthalten. +- Revit ist nur für die Existenz und die Quellattribute der tatsächlich verknüpften Modellobjekte führend. +- Revit ist nicht die alleinige Quelle des gesamten Leistungsbilanzprojekts. + +### 3.2 Circuit-First-Modell bleibt unverändert + +**Bestehende Architekturvorgabe** + +```text +Project +├── Floor +│ └── Room +├── ProjectDevice +└── DistributionBoard + └── CircuitList + └── CircuitSection + └── Circuit + └── CircuitDeviceRow +``` + +- Ein `Circuit` ist nicht dasselbe wie eine `CircuitDeviceRow`. +- BMK, Schutz- und Kabeldaten gehören zum Stromkreis. +- Menge, Leistung, Gleichzeitigkeitsfaktor, cosPhi, Raum, Kostengruppe und Kategorie gehören zur Gerätezeile. +- Ein importiertes Revit-Objekt darf vor seiner Stromkreiszuordnung eigenständig existieren. +- Der Import legt nicht automatisch Stromkreise oder Gerätezeilen an. + +### 3.3 Stable IDs und BMK + +**Bestehende Architekturvorgabe** + +- `IfcGUID` ersetzt niemals eine interne UUID. +- `IfcGUID` wird niemals als Stromkreis-BMK verwendet. +- Bestehende interne UUIDs und BMKs dürfen nicht automatisch geändert werden. +- Neunummerierung bleibt eine ausdrückliche Benutzeraktion. +- Import, Sortierung, Verschieben und Folgeabgleich führen nicht automatisch zu einer Neunummerierung. + +## 4. Umfang der ersten Ausbaustufe + +### 4.1 Enthalten + +**Bestätigte Anforderungen** + +- projektweite CSV- und Mappingkonfiguration; +- Import vollständiger CSV-Dateien; +- Import von Revit-Objekten der Kategorie `Elektroinstallation`; +- deterministische Identifikation über `IfcGUID`; +- Import beziehungsweise Verknüpfung von Räumen; +- manuelle Verknüpfung von Räumen mit Ebenen; +- manuelle Anlage der Verteilungen; +- Standardverteilung je Raum und abweichende Verteilung je Objekt; +- exakte Klassifizierung über den CSV-Wert `Familie und Typ`; +- konfigurierbare Behandlung von Einzel- und Mehrfachsteckdosen; +- optionale Verknüpfung importierter Objekte mit vorhandenen `ProjectDevice`-Vorlagen; +- Erstellen neuer `ProjectDevice`-Vorlagen aus ausgewählten Importobjekten; +- lokale Planungswerte und Abweichungen bereits vor der Stromkreiszuordnung; +- projektweites Import-, Staging- und Abgleichs-UI; +- Bereich für unzugeordnete externe Objekte im Stromkreislisteneditor; +- manuelle Zuordnung zu bestehenden Gerätezeilen, bestehenden Stromkreisen oder neuen Stromkreisen; +- Rückexport von vollständiger Stromkreiskennzeichnung und elektrischer Leistung; +- Erhaltung der ursprünglichen CSV-Struktur; +- kontrollierter Folgeimport mit Einzel- und Sammelentscheidungen; +- atomare, revisionierte und rückgängig machbare Übernahmen. + +### 4.2 Ausdrücklich nicht enthalten + +**Bestätigte Anforderungen** + +- automatische Stromkreisbildung in der ersten Ausbaustufe; +- automatische Übernahme späterer Stromkreisvorschläge; +- Import von Verteilungen aus Revit; +- Import einer separaten MEP-Raumliste; +- Teilimporte einzelner Ansichten oder Geschosse; +- Verwaltung mehrerer sichtbarer Modellquellen; +- direkte Dynamo- oder API-Synchronisation; +- PostgreSQL- oder Mehrbenutzerbetrieb; +- automatische Reservekreisbildung; +- automatische elektrische Dimensionierung; +- automatische Konfliktentscheidung; +- automatische Freigabe oder Wiederverwendung leer gewordener Stromkreisnummern; +- Platzhalter, Teiltextsuche oder reguläre Ausdrücke in der ersten Familie-und-Typ-Klassifizierung. + +## 5. Begriffe + +### 5.1 Externes Modellobjekt + +Ein importiertes Revit-Exemplar mit eigener `IfcGUID`. + +Es ist weder automatisch ein `ProjectDevice` noch automatisch eine `CircuitDeviceRow`. + +### 5.2 Quellwert + +Ein Wert, der aus der zuletzt akzeptierten Revit-CSV stammt. + +Beispiele: + +- Revit-Raumnummer; +- Revit-Raumname; +- Familie und Typ; +- CAx-Auswahlkenner; +- vorhandene Stromkreiskennzeichnung; +- vorhandene elektrische Leistung. + +### 5.3 Lokaler Planungswert + +Ein in Leistungsbilanz bestätigter beziehungsweise bearbeiteter Wert. + +Lokale Planungswerte dürfen durch Importe niemals still überschrieben werden. + +### 5.4 Wirksame Menge + +Die fachliche Menge, die für Gerätezeile, Leistungsberechnung und Steckdosenbegrenzung zählt. + +Beispiel: + +```text +2 Doppelsteckdosen + 2 Einzelsteckdosen += 4 Revit-Objekte += 6 physische Steckdosen += wirksame Menge 6 +``` + +## 6. Revit-CSV-Vertrag + +### 6.1 Konfigurierbare Transporteigenschaften + +**Bestätigte Anforderung** + +Die Konfiguration gilt projektweit und muss über eine GUI bearbeitbar sein. + +Mindestens konfigurierbar: + +- Encoding; +- Trennzeichen; +- Dezimaltrennzeichen; +- Zahlenformat; +- Einheit und Umrechnungsregel für Leistung; +- Spaltenname für `IfcGUID`; +- Spaltenname für Raumnummer; +- Spaltenname für Raumname; +- Spaltenname für `Familie und Typ`; +- Spaltenname für `CAx_Auswahlkenner`; +- Spaltenname für Stromkreiskennzeichnung; +- Spaltenname für elektrische Leistung; +- Spaltenname für den Mengenparameter einer Mehrfachsteckdose; +- weitere Quellspalten-zu-internen-Feld-Mappings. + +Erste Standardwerte: + +```text +Encoding: UTF-8 +Trennzeichen: ; +Leistung in Revit: W +``` + +### 6.2 Tatsächlich beobachtetes CSV-Profil + +Die bereitgestellte Referenzdatei besitzt: + +```text +Encoding: UTF-8 mit BOM +Zeilenende: CRLF +Trennzeichen: Semikolon +Quotierung: alle Felder in doppelten Anführungszeichen +Zeile 1: Titel-/Metadatenzeile +Zeile 2: Kopfzeile mit 12 Spalten +Zeile 3: vollständig leere Zeile +Objektzeilen mit IfcGUID: 897 +Summen-/Gruppierungszeilen ohne IfcGUID: 211 +Nichtleere doppelte IfcGUIDs: keine +``` + +Beispiel einer nicht als Objekt zu importierenden Summenzeile: + +```text +"UV_AV_DG_01-1F1: 8";"";"";"";"";"";"";"";"";"";"";"" +``` + +Die Implementierung darf daher nicht annehmen, dass: + +- die Kopfzeile immer die erste Dateizeile ist; +- jede Zeile nach der Kopfzeile ein Objekt ist; +- jede fehlende `IfcGUID` automatisch ein fehlerhaftes Objekt darstellt. + +### 6.3 Erkennen der Kopfzeile + +**Implementierungsvorschlag** + +Die Kopfzeile wird anhand der projektweit konfigurierten erforderlichen Spaltennamen gesucht. + +- Genau eine passende Kopfzeile: verwenden. +- Keine passende Kopfzeile: Import blockieren. +- Mehrere passende Kopfzeilen: Import blockieren und Auswahl beziehungsweise Konfiguration verlangen. +- Zeilen vor und nach der Kopfzeile bleiben als Transportbestandteil erhalten. + +### 6.4 Zeilenklassen + +**Implementierungsvorschlag** + +Jede CSV-Zeile wird genau einer Klasse zugeordnet: + +1. `metadata` + Zeile vor der Kopfzeile oder sonstige nicht tabellarische Metadaten. + +2. `header` + Erkannte Kopfzeile. + +3. `passthrough` + Leer-, Summen-, Gruppierungs- oder sonstige Zeile ohne externe Objektidentität, die nicht wie ein unvollständiges Objekt wirkt. + +4. `object` + Zeile mit nichtleerer, syntaktisch akzeptierter `IfcGUID`. + +5. `suspect-object` + Zeile ohne `IfcGUID`, aber mit befüllten objekttragenden Feldern wie Raum, Familie und Typ oder Auswahlkenner. + +`passthrough`-Zeilen werden unverändert erhalten und erzeugen keine externen Objekte. + +`suspect-object`-Zeilen werden als Konflikt angezeigt und nicht automatisch verworfen. + +### 6.5 Strukturtreuer Rückexport + +**Bestätigte Anforderung** + +Der Rückexport basiert auf der zuletzt akzeptierten vollständigen CSV und muss erhalten: + +- identische Anzahl und Reihenfolge der Zeilen; +- identische Anzahl und Reihenfolge der Spalten; +- Titel-, Leer-, Summen- und sonstige Passthrough-Zeilen; +- unbekannte beziehungsweise nicht gemappte Spalten; +- unveränderte Werte in nicht zu schreibenden Zellen; +- `IfcGUID` jeder Objektzeile; +- vorhandene Transportmerkmale, soweit technisch zuverlässig erkennbar. + +Mindestens zu erhalten sind: + +```text +BOM-Status +Encoding +Zeilenende +Trennzeichen +Spaltenreihenfolge +Zeilenreihenfolge +Titelzeilen +Leerzeilen +Summenzeilen +``` + +Nur explizit als Ausgangsparameter gemappte Zellen von erkannten Objektzeilen dürfen ergänzt oder überschrieben werden. + +Eine vollständig neu zusammengestellte Tabelle mit nur den fachlich verwendeten Spalten ist unzulässig. + +### 6.6 Anonymisiertes Beispiel + +```csv +"Projekt-Export";"";"";"";"" +"Stromkreis";"Raumnummer";"Raumname";"Familie und Typ";"Auswahlkenner";"Leistung";"IfcGUID" +"";"";"";"";"";"";"" +"UV_AV_01-2F1";"01/101";"Technik";"Steckdose: Doppelsteckdose";"Arbeitsplatz";"";"0AbCdEfGhIjKlMnOpQrStu" +"UV_AV_01-2F1: 2";"";"";"";"";"";"" +``` + +Die letzte Zeile ist eine Passthrough-Summenzeile, kein externes Modellobjekt. + +## 7. Identität und Matching + +### 7.1 Externe Identität + +**Bestätigte Anforderung** + +- `IfcGUID` ist der stabile Schlüssel für ein Revit-Objekt. +- Ein Objekt bleibt auch bei geänderten Quellwerten über seine `IfcGUID` bekannt. +- Doppelte nichtleere `IfcGUIDs` innerhalb eines Imports sind ein blockierender Konflikt. +- Eine fehlende `IfcGUID` in einer echten Objektzeile verhindert die automatische Verknüpfung. + +### 7.2 Quellmodell + +**Bestätigte Anforderung plus Architekturfolgerung** + +Für die erste Ausbaustufe gibt es pro Leistungsbilanzprojekt genau einen vollständigen Revit-Modellstrom. + +Die technische Architektur darf trotzdem eine implizite externe Quelle vorsehen, damit `IfcGUID` nicht global oder projektübergreifend eindeutig sein muss. + +Empfohlene Semantik: + +```text +Project +└── implicit ExternalModelSource + └── ExternalModelObject identified by IfcGUID +``` + +Es gibt in der ersten Ausbaustufe keine sichtbare Verwaltung von Hauptmodellen, Teilmodellen oder verknüpften Modellen. + +### 7.3 Interne Identität + +Jedes externe Objekt erhält zusätzlich eine stabile interne UUID. + +Diese UUID wird für interne Relationen, Commands, Snapshots und Undo/Redo verwendet. + +## 8. Datenhoheit + +### 8.1 Revit-geführt + +Revit ist zunächst führend für: + +- Existenz des externen Objekts; +- `IfcGUID`; +- Familie und Typ; +- Revit-Raumnummer und Revit-Raumname als Quellwerte; +- CAx-Auswahlkenner als Quellwert; +- sonstige ausschließlich aus Revit importierte Attribute. + +### 8.2 Leistungsbilanz-geführt + +Leistungsbilanz ist nach Bestätigung führend für: + +- interne Raum- und Ebenenverknüpfung; +- Standard- und Objektverteilung; +- Klassifizierung; +- `ProjectDevice`-Verknüpfung; +- lokale Planungswerte; +- Stromkreiszuordnung; +- `CircuitDeviceRow`-Zuordnung; +- Stromkreis-BMK; +- elektrische Planungsleistung; +- GZF, cosPhi, Kostengruppe, Kategorie und weitere lokale Gerätewerte. + +### 8.3 Konfliktregel + +Kein Folgeimport darf lokale Planungswerte automatisch überschreiben. + +Der Nutzer entscheidet je Konflikt oder per Sammelaktion zwischen: + +- Revit-Änderung übernehmen; +- lokalen Wert beibehalten; +- manuell einen dritten Wert festlegen. + +## 9. Projektweite Revit-Konfiguration + +### 9.1 Mapping + +Die Projektkonfiguration muss die CSV-Spalten auf interne Bedeutungen abbilden. + +Der CAx-Auswahlkenner muss mindestens als sichtbarer, filterbarer und gruppierbarer Wert verfügbar sein. Er kann als Vorschlag für einen Anzeigenamen verwendet werden. + +### 9.2 Familie-und-Typ-Regeln + +**Bestätigte Anforderung** + +In der ersten Ausbaustufe gilt ausschließlich exakter Textvergleich. + +Eine Regel kann mindestens festlegen: + +- exakter CSV-Wert `Familie und Typ`; +- interner Gerätetyp beziehungsweise fachliche Kategorie; +- Anschlussart; +- ProjectDevice-Kategorie `lighting`, `single_phase` oder `three_phase`; +- Mengenregel: + - feste Menge `1`; + - Menge aus gemappter CSV-Spalte; +- optional vorgeschlagener Anzeigename beziehungsweise Mappingquelle. + +Mehrere unterschiedliche Revit-Familien und -Typen dürfen demselben internen Gerätetyp zugeordnet werden. + +Beispiele: + +```text +_E_CAx Steckdose_AP: Steckdose Aufputz +→ interner Gerätetyp Steckdose +→ single_phase +→ Menge 1 +``` + +```text +_E_CAx Mehrfachsteckdose: Doppelsteckdose +→ interner Gerätetyp Steckdose +→ single_phase +→ Menge aus konfigurierter Anzahl-Spalte +``` + +### 9.3 Zugriff + +Der Konfigurationsbereich ist zunächst für alle Nutzer zugänglich, da noch kein Rollen- oder Rechtesystem existiert. + +## 10. Externes Objekt und Planungszustand + +### 10.1 Notwendige fachliche Informationen + +**Implementierungsvorschlag, kein finales Schema** + +Ein persistiertes externes Objekt benötigt mindestens: + +- interne UUID; +- Projekt- und implizite Quellenzugehörigkeit; +- `IfcGUID`; +- Referenz auf die aktuelle beziehungsweise zuletzt akzeptierte Quellzeile; +- importierte Quellwerte; +- zuletzt akzeptierte Quellwerte für den Folgeabgleich; +- verknüpften internen Raum, optional; +- Standardverteilung des Raums; +- abweichende Objektverteilung, optional; +- Klassifizierung; +- wirksame Menge; +- lokale Planungswerte; +- lokale Override-Metadaten; +- optionales `linkedProjectDeviceId`; +- optionalen Link zu einer `CircuitDeviceRow`; +- letzten Sichtbarkeits-/Importstatus; +- letzten gesehenen Importbatch; +- Konfliktstatus. + +### 10.2 Kein automatischer Row-Lebenszyklus + +Folgende Aktionen erzeugen keine `CircuitDeviceRow`: + +- CSV einlesen; +- Raum zuordnen; +- Verteilung zuordnen; +- klassifizieren; +- ProjectDevice verknüpfen; +- lokale Planungswerte bearbeiten. + +Eine Gerätezeile entsteht ausschließlich durch ausdrückliche Zuordnung im Stromkreislisteneditor. + +## 11. ProjectDevice-Verknüpfung + +### 11.1 Vorhandenes ProjectDevice + +Importierte Objekte dürfen mit einem vorhandenen `ProjectDevice` verknüpft werden. + +Das vorhandene `ProjectDevice` wird durch Revit-Werte niemals automatisch verändert. + +Die bestehende Regel bleibt verbindlich: + +- `ProjectDevice` ist die kanonische Projektvorlage; +- lokale Werte und Overrides bleiben möglich; +- Änderungen am ProjectDevice werden nie still synchronisiert; +- Synchronisierung benötigt Vorschau und Auswahl. + +### 11.2 Neues ProjectDevice aus Importobjekten + +**Bestätigte Anforderung** + +Der Nutzer darf im Importwizard ein neues `ProjectDevice` erstellen. + +Das Erstellformular darf anhand der gemappten Werte der ausgewählten Revit-Objekte vorausgefüllt werden. + +Mögliche Vorbelegungen: + +- `name`; +- `displayName`; +- Kategorie; +- Anschlussart; +- Kostengruppe; +- Einzelleistung; +- Gleichzeitigkeitsfaktor; +- cosPhi; +- Bemerkung. + +Die Kategorie des ProjectDevices bestimmt gemäß bestehendem Modell die Phasenart. Es darf kein paralleles, widersprüchliches Phasenmodell eingeführt werden. + +Bei einer Mehrfachauswahl mit unterschiedlichen Quellwerten muss die UI Abweichungen anzeigen. Sie darf nicht willkürlich einen Wert wählen. + +### 11.3 Lokale Werte vor der Stromkreiszuordnung + +Importierte Objekte dürfen bereits vor der Stromkreiszuordnung lokale Planungswerte und lokale Abweichungen vom verknüpften ProjectDevice besitzen. + +Beim späteren Erzeugen einer Gerätezeile werden diese bestätigten Objektplanungswerte als Ausgangswerte verwendet. + +## 12. Erstimport-Workflow + +### 12.1 Öffnen und Konfiguration + +1. Nutzer öffnet die projektweite Revit-Integration. +2. Falls keine gültige Mappingkonfiguration existiert, wird zuerst die Konfiguration geöffnet. +3. Nutzer lädt eine vollständige CSV hoch. +4. Parser erkennt Transportparameter und Kopfzeile. +5. Datei wird ohne fachliche Projektschreibvorgänge geparst und validiert. + +### 12.2 Vorschau + +Die Vorschau zeigt mindestens: + +- Anzahl erkannter Objektzeilen; +- Anzahl Passthrough-Zeilen; +- Anzahl verdächtiger Objektzeilen; +- fehlende und doppelte `IfcGUIDs`; +- unbekannte Familie-und-Typ-Werte; +- neue und bereits bekannte Räume; +- vorhandene Stromkreiswerte; +- nicht parsebare Leistungen oder Mengen. + +### 12.3 Raumwizard + +Räume werden aus den importierten Objektzeilen abgeleitet. + +Der Nutzer kann: + +- einen neuen internen Raum anlegen; +- einen importierten Raum mit einem vorhandenen internen Raum verknüpfen; +- mehrere Räume sortiert nach Raumnummer bearbeiten; +- Räume einer Ebene zuordnen. + +Die Raumnummer ist zunächst das primäre Matchingmerkmal. + +Eine eigene Revit-Raum-GUID ist nicht erforderlich. + +### 12.4 Verteilungen + +Verteilungen werden manuell angelegt. + +Der Nutzer kann: + +- einem Raum eine Standardverteilung zuweisen; +- mehrere Räume gesammelt einer Verteilung zuweisen; +- einzelne Objekte abweichend einer anderen Verteilung zuweisen; +- Objekte ohne MEP-Raum manuell einer Verteilung zuweisen. + +Neue Objekte eines bereits bekannten Raums erhalten die bestehende Standardverteilung als Vorschlag. + +### 12.5 Klassifizierung und ProjectDevices + +Der Nutzer kann: + +- Objekte nach Raum, Familie und Typ, CAx-Auswahlkenner und Status filtern; +- Familie-und-Typ-Werte klassifizieren; +- mehrere Objekte mit einem vorhandenen ProjectDevice verknüpfen; +- unmittelbar ein neues ProjectDevice erstellen; +- lokale Werte bearbeiten. + +### 12.6 Bereits gefüllte Stromkreiskennzeichnung + +Enthält eine Objektzeile bereits eine Stromkreiskennzeichnung, muss der Wizard fragen, wie sie behandelt wird. + +Möglichkeiten: + +- vorhandenen Wert nur als Quellwert behalten; +- vorhandene Zuordnung übernehmen; +- vorhandenen Wert ignorieren. + +Eine Übernahme ist nur zulässig, wenn: + +- die Präfix-Verteilung eindeutig vorhanden ist; +- die Zuordnung zur Raum- beziehungsweise Objektverteilung passt oder ausdrücklich bestätigt wird; +- der Stromkreis eindeutig vorhanden oder bewusst anzulegen ist; +- keine widersprüchliche Zuordnung entsteht. + +Keine Variante darf still gewählt werden. + +### 12.7 Übernahme + +Die bestätigte Erstübernahme schreibt mindestens: + +- Importbatch; +- vollständige Transportgrundlage für den Rückexport; +- externe Objekte; +- Quellwerte; +- Raum- und Verteilungslinks; +- Klassifizierungen; +- ProjectDevice-Links; +- lokale Planungswerte; +- Konfliktentscheidungen. + +Die Übernahme ist ein atomarer Projekt-Command mit `expectedRevision`. + +Sie erzeugt genau eine Projektrevision und einen Undo-Schritt. + +Nach erfolgreicher Übernahme erscheinen ausreichend klassifizierte, einer Verteilung zugeordnete und noch nicht verschaltete Objekte im Stromkreislisteneditor. + +## 13. UI 1 – Import-, Staging- und Abgleichswizard + +### 13.1 Pflichtfunktionen + +- sortierbare tabellarische Darstellung für mehrere Tausend Objekte; +- Volltextsuche; +- Filter nach Raum, Raumname, Familie und Typ, CAx-Auswahlkenner, Verteilung, ProjectDevice, Stromkreis und Status; +- Mehrfachauswahl; +- Shift-Bereichsauswahl; +- Auswahl aller gefilterten Treffer; +- Auswahl vollständiger Räume oder Gruppen; +- Sammelzuordnung zu Raum, Ebene, Verteilung, Klassifizierung und ProjectDevice; +- Erstellen eines ProjectDevices; +- Bearbeiten lokaler Planungswerte; +- Vergleich Quellwert gegen lokalen Wert; +- Konfliktentscheidungen einzeln und gesammelt; +- Vorschau des Änderungssatzes vor Übernahme. + +### 13.2 Sichtbare Objektinformationen + +Mindestens: + +- `IfcGUID`; +- Familie und Typ; +- CAx-Auswahlkenner; +- Revit-Raumnummer und Raumname; +- interner Raum und Ebene; +- Standardverteilung; +- tatsächliche Objektverteilung; +- Klassifizierung; +- wirksame Menge; +- verknüpftes ProjectDevice; +- lokaler Anzeigename; +- lokale Leistung; +- zugeordneter Stromkreis; +- zugeordnete CircuitDeviceRow; +- Import- und Konfliktstatus. + +### 13.3 Statusfilter + +Mindestens: + +- neu; +- bekannt und unverändert; +- geändert; +- Raum geändert; +- im vollständigen Folgeimport nicht enthalten; +- ohne Raum; +- ohne Verteilung; +- ohne Klassifizierung; +- ohne ProjectDevice; +- ohne Stromkreis; +- vollständig zugeordnet; +- konfliktbehaftet. + +`Ohne ProjectDevice` ist kein Fehler. + +## 14. UI 2 – Unzugeordnete Objekte im Stromkreislisteneditor + +### 14.1 Sichtbarkeit + +Der Editor zeigt einen separaten Bereich beziehungsweise Drawer mit Objekten, die: + +- der aktuellen Verteilung zugeordnet sind; +- noch mit keiner `CircuitDeviceRow` verknüpft sind; +- ausreichend klassifiziert sind; +- keinen blockierenden Konflikt besitzen. + +### 14.2 Darstellung und Filter + +Mindestens sichtbar: + +- Raum; +- Familie und Typ; +- CAx-Auswahlkenner; +- interner Gerätetyp; +- ProjectDevice; +- wirksame Menge; +- Einzelleistung; +- Objektgesamtleistung; +- Kategorie beziehungsweise Phasenart; +- Anschlussart; +- Status. + +Filter und Mehrfachauswahl müssen auch hier für große Mengen geeignet sein. + +### 14.3 Drag-and-drop-Semantik + +**Bestätigte Anforderung** + +Der Drop-Zielbereich bestimmt die fachliche Aktion. + +#### Drop auf bestehende CircuitDeviceRow + +- ausgewählte externe Objekte werden mit genau dieser Zeile verknüpft; +- Menge und Gesamtleistung werden neu berechnet; +- die Anwendung wählt niemals selbst eine andere passende Zeile. + +#### Drop auf bestehenden Circuit + +- in diesem Stromkreis wird eine neue CircuitDeviceRow angelegt; +- dies gilt auch, wenn bereits eine ähnliche Zeile vorhanden ist. + +#### Drop auf freien Zielbereich für neuen Circuit + +- ein neuer Circuit wird über den bestehenden Circuit-Insert-/Move-Mechanismus angelegt; +- mindestens eine neue CircuitDeviceRow wird erzeugt; +- BMK-Erzeugung folgt den bestehenden expliziten Regeln des Editors; +- keine Nachbarstromkreise werden neu nummeriert. + +Die gesamte jeweilige Aktion einschließlich externer Links, Mengenänderung, Circuit-/Row-Erzeugung, Revision und History-Transition ist atomar. + +### 14.4 Keine automatische Zusammenführung + +Gleiche Eigenschaften dürfen Hinweise und Vorschläge erzeugen. + +Die Anwendung darf externe Objekte aber nicht ohne Benutzeraktion automatisch: + +- zusammenführen; +- einer bestehenden Gerätezeile hinzufügen; +- in einen Stromkreis verschieben; +- auf mehrere Gerätezeilen verteilen. + +## 15. Gerätezeilen, Aggregation und Mehrfachsteckdosen + +### 15.1 Einzelobjekte bleiben erhalten + +Jedes Revit-Objekt bleibt intern separat anhand seiner `IfcGUID` nachvollziehbar, auch wenn mehrere Objekte in einer Gerätezeile aggregiert dargestellt werden. + +### 15.2 Mehrfachsteckdose + +**Bestätigte Anforderungen** + +- Eine Mehrfachsteckdose ist ein Revit-Objekt. +- Ihr Mengenparameter enthält die Anzahl physischer Schukosteckdosen. +- Eine Doppelsteckdose zählt als zwei Steckdosen. +- Das Objekt ist unteilbar und darf nicht auf mehrere Stromkreise verteilt werden. +- Die Leistung wird je physischer Steckdose angesetzt. +- Die Objektgesamtleistung ist `wirksame Menge × powerPerUnit`. + +### 15.3 Gerätezeilenmenge + +Die Menge einer CircuitDeviceRow ist die Summe der wirksamen Mengen aller mit ihr verknüpften externen Objekte plus gegebenenfalls manuell geführter Anteile, sofern das vorhandene Datenmodell dies eindeutig unterscheiden kann. + +Beispiel: + +```text +2 Doppelsteckdosen + 2 Einzelsteckdosen +→ 4 ExternalModelObjects +→ CircuitDeviceRow.quantity = 6 +``` + +### 15.4 Getrennte Gerätezeilen + +**Bestätigte Anforderungen** + +Unterschiedliche Räume werden in getrennten Gerätezeilen dargestellt. + +Unterschiedliche CAx-Auswahlkenner werden in getrennten Gerätezeilen dargestellt. + +Beispiel: + +```text +Circuit UV_AV_01-2F1 +- Raum 01/101: 4 × Arbeitsplatzsteckdose +- Raum 01/101: 2 × Mediensteckdose +- Raum 01/102: 1 × Arbeitsplatzsteckdose +``` + +Der Nutzer darf trotz gleicher Werte bewusst mehrere getrennte Gerätezeilen erzeugen. + +### 15.5 Raumübergreifende Stromkreise + +Raumübergreifende Stromkreise bleiben manuell zulässig und werden über mehrere Gerätezeilen übersichtlich dargestellt. + +Die spätere automatische Stromkreisvorschlagsfunktion darf nur raumbezogene Vorschläge erzeugen. + +## 16. Folgeimport + +### 16.1 Annahme + +Jeder Folgeimport enthält erneut den vollständigen relevanten Modellstand der Kategorie `Elektroinstallation`. + +Teilimporte sind in der ersten Ausbaustufe nicht zulässig beziehungsweise werden nicht als Löschgrundlage verwendet. + +### 16.2 Vergleichszustände + +Mindestens zu erkennen: + +- bekannte `IfcGUID`, unveränderte Quellwerte; +- neue `IfcGUID`; +- bekannte `IfcGUID` mit geänderten Quellwerten; +- geänderter Revit-Raum; +- geänderte Stromkreiskennzeichnung; +- geänderte Leistung; +- zuvor bekannte `IfcGUID` fehlt; +- doppelte `IfcGUID`; +- verdächtige Objektzeile ohne `IfcGUID`. + +### 16.3 Fehlende Objekte + +Fehlt eine bekannte `IfcGUID`, wird das Objekt nur als `nicht mehr im aktuellen vollständigen Export enthalten` markiert. + +Es wird nicht automatisch: + +- gelöscht; +- aus seiner Gerätezeile entfernt; +- aus seinem Stromkreis entfernt; +- von seinem ProjectDevice getrennt. + +Erst nach ausdrücklicher Bestätigung wird das externe Objekt entfernt beziehungsweise als gelöscht übernommen. + +Danach: + +- wird sein Link zur CircuitDeviceRow entfernt; +- werden Menge und Leistung der Zeile neu berechnet; +- bleibt ein dadurch leer gewordener Circuit bestehen; +- wird seine BMK nicht automatisch freigegeben oder neu vergeben. + +### 16.4 Raumänderung + +Eine Raumänderung wird anhand derselben `IfcGUID` erkannt und als Konflikt angezeigt. + +Sie wird nicht automatisch übernommen. + +### 16.5 Alle Änderungen sind nutzergesteuert + +Der Nutzer kann Konflikte: + +- einzeln behandeln; +- gruppiert behandeln; +- Revit-Werte übernehmen; +- lokale Werte behalten; +- manuell überschreiben. + +Die bestätigte Übernahme eines Folgeimports ist ein atomarer Projekt-Command und eine Projektrevision. + +## 17. Rückexport + +### 17.1 Grundlage + +Der Export verwendet den zuletzt akzeptierten vollständigen Importbatch und eine bekannte aktuelle Projektrevision. + +Ein Export verändert die Projektrevision nicht. + +### 17.2 Stromkreiskennzeichnung + +Für jedes einem Stromkreis zugeordnete externe Objekt wird geschrieben: + +```text + +``` + +Beispiel: + +```text +UV_AV_DG_01-2F1 +``` + +Die genaue Trennlogik folgt dem tatsächlich im Projekt verwendeten Verteilerpräfix und Stromkreis-BMK; es darf kein zweites unabhängiges Nummerierungssystem eingeführt werden. + +### 17.3 Leistung + +Die Rückgabe erfolgt in Watt. + +Für eine Mehrfachsteckdose wird die objektbezogene Gesamtleistung geschrieben: + +```text +Objektleistung = wirksame Menge des Revit-Objekts × powerPerUnit +``` + +Bei normalen Einzelobjekten ist die wirksame Menge `1`. + +### 17.4 Objektbezogene Ausgabe + +Sind mehrere Revit-Objekte mit einer gemeinsamen CircuitDeviceRow verknüpft: + +- erhält jedes Objekt seine eigene ursprüngliche CSV-Zeile; +- erhält jedes Objekt dieselbe Stromkreiskennzeichnung; +- erhält jedes Objekt seine eigene Objektgesamtleistung; +- bleibt seine `IfcGUID` unverändert. + +### 17.5 Exportnachweis + +**Implementierungsvorschlag** + +Ein Exportbatch speichert mindestens: + +- Projekt-ID; +- Projektrevision; +- zugrunde liegenden Importbatch; +- Zeitstempel; +- Dateiname; +- Prüfsumme; +- verwendete Mappingkonfiguration beziehungsweise deren Version. + +Dies ist Auditmetadaten und kein Ersatz für die Projekt-Revisionshistorie. + +## 18. Validierungen + +### 18.1 Blockierende Fehler + +Mindestens: + +- CSV kann mit der Konfiguration nicht geparst werden; +- erforderliche Kopfzeile ist nicht eindeutig; +- erforderliche Spalte fehlt; +- doppelte nichtleere `IfcGUID` unter Objektzeilen; +- ungültige oder nicht serialisierbare Projektwerte; +- stale `expectedRevision`; +- Verknüpfung zu einem anderen Projekt; +- Drop-Ziel gehört nicht zur zugeordneten Verteilung beziehungsweise Liste; +- Mehrfachsteckdose würde intern auf mehrere Stromkreise aufgeteilt; +- atomare Command-Vorbedingungen stimmen nicht mehr. + +### 18.2 Warnungen beziehungsweise aufzulösende Konflikte + +Mindestens: + +- unbekannter Familie-und-Typ-Wert; +- Objekt ohne Raum; +- Raumänderung; +- bestehende abweichende Stromkreiskennzeichnung; +- abweichende Revit-Leistung; +- Objekt im Folgeimport nicht enthalten; +- ausgewählte Objekte besitzen unterschiedliche lokale Planungswerte; +- vorhandene Stromkreiszuordnung passt nicht zur Verteilung; +- verdächtige Objektzeile ohne `IfcGUID`. + +## 19. Revision, Undo/Redo und Audit + +### 19.1 Gemeinsame Transaktionsgrenze + +**Bestehende Architekturvorgabe** + +Alle bestätigten projektbezogenen Änderungen laufen über: + +```text +domain mutation ++ inverse command ++ project revision ++ undo/redo transition +``` + +Sie werden gemeinsam über die bestehende Projekt-Command-Transaktionsgrenze committed oder vollständig zurückgerollt. + +Neue Revit-Fachlogik darf nicht direkt von React, `better-sqlite3`, globalen Datenbankinstanzen oder konkreten SQLite-Repositories abhängen. + +### 19.2 Neue logische Commands + +**Implementierungsvorschlag** + +Mindestens getrennte Command-Verantwortlichkeiten: + +- Revit-Projektkonfiguration ändern; +- akzeptierten Erstimport anwenden; +- akzeptierten Folgeimport anwenden; +- externe Objektplanungswerte ändern; +- externe Objekte mit ProjectDevices verknüpfen oder trennen; +- externe Objekte einer bestehenden CircuitDeviceRow zuweisen; +- externe Objekte als neue CircuitDeviceRow einem Circuit zuweisen; +- externe Objekte mit neuem Circuit und neuer Row zuweisen; +- externe Objektzuordnung aus einer Row lösen; +- externes Objekt nach bestätigtem Fehlen löschen. + +Die konkreten Command-Namen und Payloads sind beim Implementierungsaudit festzulegen. + +### 19.3 Undo + +Undo muss insbesondere wiederherstellen: + +- externe Objekte und Quellstände; +- Raum-, Verteilungs- und ProjectDevice-Links; +- lokale Planungswerte und Overrides; +- CircuitDeviceRow-Verknüpfungen; +- Mengen und Leistungen; +- erzeugte Row- und Circuit-UUIDs; +- Importstatus. + +Undo darf keine BMKs neu berechnen. + +## 20. Snapshots und portabler Projekttransfer + +**Bestehende Architekturfolgerung** + +Sobald die Revit-Integration unterstützt wird, gehört ihr bestätigter Projektzustand zum vollständigen logischen Projektzustand. + +Snapshot- und JSON-Transfer-Schema müssen deshalb nach einem bewussten Schema-Versionswechsel mindestens erhalten: + +- projektweite Revit-Konfiguration; +- Mappingregeln; +- Familie-und-Typ-Regeln; +- externe Objekte; +- Quell- und Planungswerte; +- Raum-, Verteilungs-, ProjectDevice- und CircuitDeviceRow-Links; +- relevante Importbatch-Grundlagen für den Rückexport; +- Konflikt- und Sichtbarkeitsstatus. + +Beim Duplizieren eines Projekts: + +- werden alle internen UUIDs remapped; +- bleiben externe `IfcGUIDs` als Quellidentitäten erhalten; +- werden interne Links auf die remappten Projektobjekte aktualisiert. + +Vorhandene Snapshot-Migrationen dürfen nicht still verändert werden. Es ist eine additive neue Schema-Version erforderlich. + +## 21. Modul- und Persistenzgrenzen + +### 21.1 Verbindliche Grenzen + +- Parsing und Serialisierung sind keine React-Aufgabe. +- CSV-Dialektlogik ist kein Bestandteil von Circuit-Domain-Services. +- Domain-Services kennen keine konkreten SQLite-Repositories. +- Controller importieren keinen globalen Datenbankclient. +- Writes erfolgen ausschließlich über typisierte Commands. +- Reads verwenden schmale, fachlich benannte Repositories. +- Server-Komposition erzeugt und injiziert konkrete Adapter. +- SQLite bleibt der unterstützte Adapter. +- PostgreSQL wird nicht in dieser Phase eingeführt. + +### 21.2 Empfohlene Verantwortlichkeiten + +**Implementierungsvorschlag** + +```text +CSV transport adapter +- dialect detection +- header and row classification +- lossless-enough matrix preservation +- mapped value parsing +- return serialization + +External model domain +- identity and matching +- source versus planning values +- conflict calculation +- object lifecycle +- aggregation invariants + +Application services / commands +- import preview +- first import apply +- follow import apply +- link and unlink operations +- export projection + +Persistence adapters +- project configuration +- import/export batches +- external objects +- links and accepted source state + +Frontend +- project configuration UI +- staging wizard +- unassigned-object editor drawer +``` + +Die Namen sind Verantwortlichkeiten, keine vorab beschlossenen Tabellen- oder Ordnernamen. + +## 22. Performanceanforderungen + +**Bestätigte Anforderung** + +Das UI muss mehrere Tausend Objektzeilen praktisch bearbeitbar machen. + +Mindestens: + +- keine vollständige DOM-Darstellung aller Zeilen, falls dies die Bedienbarkeit beeinträchtigt; +- server- oder clientseitige effiziente Sortierung und Filterung; +- stabile Mehrfachauswahl; +- Sammelaktionen auf gefilterte Treffer; +- keine fachliche Änderung beim bloßen Filtern und Sortieren; +- keine automatische Neunummerierung; +- Import und Export dürfen zunächst synchron laufen, solange reale Projektdateien zuverlässig verarbeitet werden. + +Die Referenzdatei mit rund 900 Objektzeilen und über 1.100 Gesamtzeilen ist als Mindest-Integrationstest zu verwenden. + +## 23. Implementierungsphasen + +### Phase 14.0 – Audit und Verträge + +Ziel: + +- aktuelle ProjectDevice-, Row-, Command-, Snapshot- und Editorpfade prüfen; +- konkretes Datenmodell und Command-Schnittstellen vorschlagen; +- keine Implementierung vor Freigabe des Auditberichts. + +Lieferung: + +- Keep/Refactor/Add-Liste; +- vorgeschlagene Domainobjekte; +- vorgeschlagene Commands; +- Snapshot-/Transfer-Auswirkungen; +- Risiken bei Row-Mengen und lokalen Objektwerten. + +Abnahme: + +- keine bestehende Architekturregel wird umgangen; +- offene Punkte sind klar als solche markiert. + +### Phase 14.1 – CSV-Konfiguration und Parser + +Ziel: + +- projektweite Mappingkonfiguration; +- Parser und Serializer für das beobachtete CSV-Profil; +- reine Vorschau ohne Projektschreibvorgang. + +Abnahme: + +- Referenzdatei wird mit 897 Objektzeilen und 211 Passthrough-Summenzeilen erkannt; +- Titel-, Leer- und Summenzeilen bleiben erhalten; +- nichtleere `IfcGUIDs` sind eindeutig; +- Rückserialisierung ohne fachliche Änderungen erhält Struktur und Zellenwerte; +- Parser besitzt fokussierte Tests für BOM, CRLF, Semikolon, Quotierung und Kopfzeile in Zeile 2. + +### Phase 14.2 – Externe Objekte und Erstimport + +Ziel: + +- persistente externe Objekte; +- Raum-, Ebenen-, Verteilungs-, Klassifizierungs- und ProjectDevice-Verknüpfung; +- atomare Importübernahme. + +Abnahme: + +- Import erzeugt keine CircuitDeviceRow; +- Raum- und Verteilungszuordnung kann gespeichert werden; +- neues ProjectDevice kann vorausgefüllt erstellt werden; +- vorhandenes ProjectDevice wird nicht durch Revit-Werte verändert; +- Import ist ein Undo-Schritt; +- Undo entfernt den vollständigen bestätigten Importzustand. + +### Phase 14.3 – Stromkreislisteneditor + +Ziel: + +- unzugeordnete externe Objekte je Verteilung; +- Drag-and-drop zu Row, Circuit oder neuem Circuit; +- Aggregation und Mehrfachsteckdosen. + +Abnahme: + +- Drop auf Row ergänzt genau diese Row; +- Drop auf Circuit erzeugt eine neue Row; +- Drop auf neuen Zielbereich erzeugt Circuit und Row atomar; +- 2 Doppel- plus 2 Einzelsteckdosen ergeben Menge 6; +- keine Mehrfachsteckdose kann geteilt werden; +- verschiedene Räume und Auswahlkenner bleiben in getrennten Rows; +- Undo stellt externe Links, Mengen, Row-/Circuit-UUIDs und BMKs exakt wieder her. + +### Phase 14.4 – Rückexport + +Ziel: + +- strukturtreue Revit-Rückgabe-CSV. + +Abnahme: + +- Zeilen- und Spaltenzahl sowie Reihenfolge entsprechen der Ausgangsdatei; +- unbekannte Spalten und Passthrough-Zeilen bleiben erhalten; +- Stromkreis und Leistung werden ausschließlich in gemappte Objektzellen geschrieben; +- jedes Objekt behält seine `IfcGUID`; +- Mehrfachsteckdosen erhalten ihre Objektgesamtleistung in Watt; +- Export referenziert eine bekannte Projektrevision. + +### Phase 14.5 – Folgeimport und Konflikte + +Ziel: + +- additions, changes, missing objects and conflicts; +- Einzel- und Sammelentscheidungen. + +Abnahme: + +- neue Objekte werden erkannt; +- Raumänderungen werden konfliktbehaftet angezeigt; +- fehlende Objekte werden nicht automatisch entfernt; +- lokale Werte werden nicht automatisch überschrieben; +- bestätigte Änderungen sind ein atomarer Undo-Schritt; +- unveränderte Objekte erzeugen keine unnötigen Domainänderungen. + +### Phase 14.6 – Snapshot, Transfer und Härtung + +Ziel: + +- vollständige Projektportabilität; +- Performance und End-to-End-Tests. + +Abnahme: + +- Snapshot/Restore erhält sämtliche externe Links und Exportgrundlagen; +- Projektduplikat remapped interne UUIDs und behält `IfcGUIDs`; +- Undo/Redo funktioniert nach Reload; +- Referenz-CSV durchläuft Erstimport, Row-Zuordnung, Export, Folgeimport und Restore; +- vollständige Test- und Build-Suite läuft erfolgreich. + +## 24. End-to-End-Abnahmeszenarien + +### Szenario A – Gemischte Steckdosen + +Aus Revit: + +```text +Raum 01/101 +- 2 Doppelsteckdosen, jeweils Menge 2 +- 2 Einzelsteckdosen, jeweils Menge 1 +- gleicher CAx-Auswahlkenner +``` + +Erwartung: + +- 4 externe Objekte; +- wirksame Menge 6; +- Nutzer zieht alle Objekte auf eine neue Row; +- Row zeigt `6 × Steckdose`; +- alle vier CSV-Zeilen erhalten denselben Stromkreis; +- Doppelsteckdosen erhalten jeweils `2 × powerPerUnit` als Objektleistung; +- Einzelsteckdosen erhalten jeweils `1 × powerPerUnit`. + +### Szenario B – Gleiches ProjectDevice in mehreren Räumen + +Aus Revit: + +- gleicher Leuchtentyp in drei Technikräumen. + +Erwartung: + +- Nutzer wählt alle Leuchten raumübergreifend; +- erstellt ein neues, aus Revit-Werten vorausgefülltes ProjectDevice; +- alle Objekte werden damit verknüpft; +- es wird noch keine CircuitDeviceRow erzeugt; +- später entstehen je Raum getrennte Rows, sofern die Objekte verschiedenen Räumen zugeordnet werden. + +### Szenario C – Raumübergreifender Putzsteckdosenstromkreis + +- mehrere Räume mit jeweils wenigen Putzsteckdosen; +- Nutzer ordnet sie manuell demselben Circuit zu; +- pro Raum entsteht eine getrennte Row; +- alle Objekte erhalten dieselbe Stromkreiskennzeichnung. + +### Szenario D – Folgeimport mit Raumänderung + +- bekannte `IfcGUID`; +- Revit-Raumnummer ist geändert. + +Erwartung: + +- Objekt wird nicht neu angelegt; +- Raumänderung wird als Konflikt angezeigt; +- bestehende interne Raum-, Verteilungs- und Stromkreiszuordnung bleibt unverändert; +- Nutzer kann die Änderung einzeln oder gesammelt übernehmen. + +### Szenario E – Fehlendes Objekt + +- eine zuvor bekannte `IfcGUID` fehlt im vollständigen Folgeimport. + +Erwartung: + +- Objekt wird als fehlend markiert; +- Row-Menge und Leistung bleiben zunächst unverändert; +- erst bestätigte Löschung entfernt Link und Mengenanteil; +- Circuit bleibt auch bei leerer Row beziehungsweise nach Row-Entfernung bestehen; +- BMK wird nicht automatisch wiederverwendet. + +### Szenario F – Bestehende Stromkreiskennzeichnung beim Erstimport + +- Revit-Zeile enthält bereits `UV_AV_01-2F3`. + +Erwartung: + +- Wizard zeigt den Wert; +- Nutzer kann Quellwert behalten, Zuordnung übernehmen oder ignorieren; +- keine Option wird automatisch gewählt; +- unpassende Verteilung oder fehlender Circuit erzeugt Konflikt beziehungsweise bewusste Anlageentscheidung. + +### Szenario G – CSV-Passthrough + +- Titelzeile; +- Kopfzeile in Zeile 2; +- Leerzeile; +- Objektzeilen; +- Summenzeile ohne `IfcGUID`. + +Erwartung: + +- nur Objektzeilen erzeugen externe Objekte; +- Summenzeile erzeugt keine Fehlermeldung; +- Rückexport enthält alle Zeilen an derselben Position. + +## 25. Noch offene, phasengebundene Entscheidungen + +Diese Punkte blockieren die Erstellung dieser Spezifikation nicht. + +### Vor Phase 14.2 zu entscheiden + +- konkrete Benennung der neuen Domainobjekte und Tabellen; +- ob Importentwürfe vor der endgültigen Übernahme serverseitig gespeichert werden; +- genaue Versionierung der Mappingkonfiguration; +- genaue Speicherung der Original-CSV: vollständige Rohdatei, logische Zellmatrix oder Kombination. + +### Vor Phase 14.3 zu entscheiden + +- visuelle Position des Objekt-Drawers; +- Verhalten einer Mehrfachauswahl mit widersprüchlichen Planungswerten; +- Warnungsdialog bei fachlich unpassender Row; +- Verhalten, wenn eine Row manuelle Mengenanteile und externe Objekte kombiniert; +- genaue UI für das Lösen einer einzelnen externen Objektverknüpfung aus einer aggregierten Row. + +### Vor Phase 14.4 zu entscheiden + +- exaktes Revit-Zahlenformat für Dezimalwerte; +- genaue Formatierung von Wattwerten, zum Beispiel `1000 W` oder `1000`; +- Umgang mit Objekten ohne Stromkreis beim Rückexport: leeres Feld oder unveränderter Quellwert; +- Dateinamenschema der Rückgabe. + +### Spätere Ausbaustufen + +- automatische raumbezogene Stromkreisvorschläge; +- projektübergreifend wiederverwendbare Mappingprofile; +- Teilmodelle und mehrere externe Quellen; +- Dynamo/API/JSON-Transportadapter (nicht vorgesehen, siehe Abschnitt 1); +- Rollen und Berechtigungen; +- Hintergrundjobs; +- PostgreSQL. + +## 26. Arbeitsweise für Codex + +Vor jeder Phase: + +1. relevante bestehende Module auditieren; +2. angeben, was erhalten, erweitert oder ersetzt wird; +3. betroffene Commands, Snapshots und Transferformate nennen; +4. Migration und Rückwärtsverträglichkeit erläutern; +5. fokussierte Tests festlegen. + +Während der Implementierung: + +- kleine reviewbare Arbeitspakete; +- keine fachlichen Writes außerhalb der Command-Grenze; +- keine automatische BMK-Änderung; +- keine stillen Revit- oder ProjectDevice-Synchronisationen; +- keine ungefragte PostgreSQL- oder Dynamo-Implementierung; +- keine Kopplung von Domainlogik an CSV, React oder SQLite. + +Nach jedem Arbeitspaket: + +- fokussierte Tests; +- `npm test`; +- `npm run build:api`; +- `npm run build:web`; +- `npm run typecheck:scripts`; +- `npx tsc --noEmit -p tsconfig.next.json`; +- Dokumentation des neuen unterstützten Laufzeitpfads aktualisieren. diff --git a/docs/spec/revit-csv-phase-14-audit-and-plan.md b/docs/spec/revit-csv-phase-14-audit-and-plan.md index 2d116b2..a4c21e4 100644 --- a/docs/spec/revit-csv-phase-14-audit-and-plan.md +++ b/docs/spec/revit-csv-phase-14-audit-and-plan.md @@ -1,8 +1,406 @@ -# Abgelöst: alter Phase-14-CSV-Plan +# Phase 14: Audit- und Implementierungsplan für die Revit-CSV-Anbindung -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). +## Status -Der historische Inhalt bleibt im Git-Verlauf bis einschließlich Commit -`ae318a5` erhalten und darf nicht fortgeschrieben werden. +**Zurückgestellt:** Die weitere Revit-Arbeit wird später angegangen, dann +über den CSV-Export/-Import des Linear-Plugins in Revit statt über Dynamo. +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. diff --git a/docs/spec/revit-excel-integration-requirements.md b/docs/spec/revit-excel-integration-requirements.md deleted file mode 100644 index 29a4aaf..0000000 --- a/docs/spec/revit-excel-integration-requirements.md +++ /dev/null @@ -1,466 +0,0 @@ -# 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 `-<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: -`_Revit-Rueckgabe_.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. - -Die korrigierte R2-Rückgabedatei wurde am 30.09.2026 erfolgreich in Linear -eingelesen. Damit ist diese Abnahme erfüllt und R3 freigegeben. - -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). diff --git a/docs/spec/revit-excel-phase-14-plan.md b/docs/spec/revit-excel-phase-14-plan.md deleted file mode 100644 index 0b1b71a..0000000 --- a/docs/spec/revit-excel-phase-14-plan.md +++ /dev/null @@ -1,191 +0,0 @@ -# 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 | abgeschlossen und freigegeben | XLSX-Adapter, Parser, synthetische Fixtures, lokaler Referenzprüfer und reale Rückgabedatei sind erstellt; der korrigierte Rückimport wurde am 30.09.2026 erfolgreich in Linear getestet. | -| R3 | abgeschlossen | Konfiguration ohne eigene Revision, Worksharing-ID-Datenmodell, Migration 0014, Snapshot 10, Transfer und Backend-CSV-Entfernung sind umgesetzt und geprüft. | -| R4 | abgeschlossen | Revit-Seite, Navigation und revisionierte XLSX-Einstellungen mit Musterdateiprüfung sind umgesetzt; das alte Projektseitenmodal ist entfernt. | -| 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. - -Implementierungsstand vom 30.09.2026: Der Adapter liegt unter -`src/external-model/xlsx`, der Referenzprüfer unter -`scripts/verify-revit-reference-xlsx.ts`. Er hat aus der lokalen Musterdatei -die ignorierte Datei -`data/revit-reference/kbp-Stromkreis-R2-Rueckgabe.xlsx` erzeugt. Die Datei -enthält 487 Objektzeilen in Originalreihenfolge, keine Summenzeile und gezielte -Änderungen an den ersten drei Objekten. Synthetische Tests decken Zelltypen, -Zahlenformate, Formelergebnisse, Kommentare, Breiten, Auswahl, exakte -ID-Vergleiche und Grenzen ab. - -Für den Adapter ist `exceljs@4.4.0` als direkte Abhängigkeit aufgenommen. Der -Produktionsaudit meldet dafür ausschließlich `uuid@8.3.2`: Die gemeldete -Schwachstelle betrifft die UUID-Funktionen v3/v5 mit übergebenem Puffer; -ExcelJS verwendet die Abhängigkeit nur für UUID v4 bei erweiterten bedingten -Formatierungen. Dieser Adapter ruft keine UUID-Funktion auf. Weitere gemeldete -Auditbefunde gehören zu bereits vorhandenen Abhängigkeiten und werden nicht im -fachlich begrenzten R2-Paket aktualisiert. - -## 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. diff --git a/docs/spec/revit-excel-r0-audit.md b/docs/spec/revit-excel-r0-audit.md deleted file mode 100644 index 84acc5a..0000000 --- a/docs/spec/revit-excel-r0-audit.md +++ /dev/null @@ -1,528 +0,0 @@ -# R0 – Audit der Linear-Excel-Anbindung - -Stand: 29.09.2026. Geprüfter Code: `cf022b2`. - -**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`, -`docs/project-history-and-external-model-architecture.md`, -`docs/spec/revit-csv-integration-requirements.md` und -`docs/spec/revit-csv-phase-14-audit-and-plan.md`. Der alte Plan widerspricht -sich bereits intern: Sein Status nennt die Erstübernahme noch nicht vorhanden, -während Implementierung und Tests sie nachweisen. Alte Erledigt-Markierungen -werden deshalb nicht übernommen. - -| Bereich / Codebeleg | Entscheidung | Begründung und Änderung | -| --- | --- | --- | -| `src/db/repositories/project-command-transaction.persistence.ts` | Keep | Eine Grenze für Fachänderung, Inverse, Revision und History; auch automatische Snapshots bleiben darin. | -| `src/db/repositories/external-model-state.repository.ts`, `src/db/schema/external-*.ts` | Change | Quelle, Batches, Raum-Mappings und Objekte wiederverwenden; neue Identität, Konfiguration und typisierte Matrix. Schlanke Objekt-Reads von großen Batch-Blobs trennen. | -| `src/domain/models/external-initial-import-project-command.model.ts`, zugehöriger Store | Change | Vollständiger erwarteter/Zielzustand und Row-freier Import bleiben; Worksharing-ID, Gerätearten und atomare Regelübernahme ergänzen. | -| `src/external-model/application/external-initial-import-plan.ts`, `external-initial-import-target.ts` | Change | Raumvorschläge, Kataloge, vollständige Entscheidungen und stabile UUIDs behalten. Objektentscheidungen und Gerätearten ergänzen. | -| `src/db/repositories/external-object-assignment.persistence.ts` und drei Zuordnungs-Stores | Change | Mengeninvariante und exakte Inversen behalten; Geräteart, effektiven Verteiler, Anwesenheit und Übernahme der Row-Werte beim Lösen ergänzen. | -| `CircuitDeviceRow.manualQuantity`, bestehende Mengenprüfungen | Keep | `quantity = manualQuantity + Summe(externer effektiver Mengen)`; Mehrfachsteckdosen bleiben unteilbar. | -| `src/external-model/application/external-circuit-list-objects.ts` | Change | Listen-/Projektprüfung behalten; vollständige Planungswerte, Geräteart, effektiver Verteiler, Status und Row-Anzahlen liefern. | -| `src/domain/models/project-state-snapshot.model.ts`, Snapshot-Persistenz und Transfer | Change | Schema 10; historische CSV-Zustände ausdrücklich ablehnen; alle neuen internen Referenzen remappen. | -| `src/external-model/csv/*`, CSV-Preview, CSV-Validierungen und Controller | Remove/replace | XLSX ersetzt CSV vollständig; kein zweiter aktiver Transportpfad. | -| `src/frontend/components/revit-csv-modal.tsx`, Einbindung auf Projektseite | Remove/replace | Eigene Revit-Seite; Einstellungen nur im Modal, Import in eigenem Wizard. | -| `src/frontend/components/Sidebar.tsx`, `src/frontend/utils/api.ts`, `src/frontend/types.ts` | Change | Route `revit`, neue DTOs und Endpunkte, CSV-Imports entfernen. | -| `src/frontend/components/circuit-tree-editor.tsx`, Grid-Drop-/Projektionsmodule | Change | Separater externer Drag-Payload; Row-, Circuit- und Freiplatz-Ziele bewusst unterscheiden. Bestehende Grid-Bedienung behalten. | -| Raum-/ProjectDevice-Formulare und Commands | Keep | Sichtbar vorbelegte, ausdrücklich bestätigte Anlage als eigener Undo-Schritt. | -| `scripts/verify-revit-reference-csv.ts`, Transporttests | Replace | Pfadargument für lokalen XLSX-Prüfer; ausschließlich synthetische Workbooks in Tests. | - -### Konkrete Lücken gegenüber dem Auftrag - -- `external-model-contracts.ts` importiert heute CSV-Verträge. Die neutralen - Konfigurations-/Matrixverträge gehören künftig in `external-model/domain`; - nur `external-model/xlsx` darf ExcelJS kennen. -- `ifc_guid` ist derzeit NOT NULL und je Quelle eindeutig; Matching, - Snapshots, DTOs und Commands setzen diese Identität voraus. -- `internalDeviceType` ist derzeit ein freier String in Planungswerten. - Es gibt keinen Geräteart-Katalog mit stabilen IDs und Standardwerten. -- Der Erstimport setzt den ProjectDevice-Link, verwendet im Target aber - weiterhin `suggestedPlanningValues`. Die neue Priorität ProjectDevice vor - Geräteart muss ausdrücklich implementiert werden; ein Link allein genügt - nicht. Revit-Leistung wird künftig nicht automatisch zum Planungswert. -- Der Import-Target setzt `distributionBoardId = null`; die Raumvorgabe liegt - separat im Mapping. Projektion und Zuordnungsprüfung vergleichen heute - direkt das Objektfeld. Eine zentrale Auflösung des effektiven Verteilers - fehlt und ist vor der Editor-Nutzung erforderlich. -- Die bisherige Row-Zuordnung darf laut Validator am Objekt ausschließlich - `circuitDeviceRowId` ändern; der Store schreibt auch nur dieses Feld. - Lösen mit aktuellen Row-Planungswerten benötigt eine neue Command-Version. -- Die Kompatibilitätsprüfung vergleicht Raum, Kategorie, Auswahlkenner und - Planungswerte, aber keine stabile Geräteart. Unterschiedliche Gerätearten - dürfen nicht versehentlich in dieselbe Row aggregiert werden. -- Rows speichern `powerPerUnit` in **kW**, externe Planung - `powerPerUnitW` in **W**. Eine zentrale bidirektionale Konvertierung ist - nötig; Exportleistung darf nicht um Faktor 1000 falsch sein. -- Externe FKs auf Row, ProjectDevice, Raum-Mapping und Verteiler verwenden - teilweise `ON DELETE SET NULL`. Bestehende allgemeine Löschpfade sichern - externe Objektübergänge nicht durchgängig in ihren Inversen. Auch - Unterbaum-/History-Löschungen müssen abgesichert werden. -- Ein Editor-Drawer, projektweite Objekttabelle, Exportnachweis und - ausführbarer Folgeimport fehlen. `follow_up` als vorhandener Enumwert ist - kein implementierter Folgeimport. -- Konfigurationsversionen steigen heute nur bei normalen Updates gegenüber - dem aktuellen Wert; Undo setzt alte Versionen zurück. Für eine tatsächlich - monotone Generation muss diese Semantik korrigiert werden. -- XLSX-Parsing ist asynchron. Das heutige erneute synchrone CSV-Parsing - innerhalb der SQLite-Transaktion darf nicht einfach durch `await` ersetzt - werden. - -## 2. Prüfung der lokalen Musterdatei - -`docs/spec/kbp-Stromkreis.xlsx` wurde ausschließlich lesend auf ZIP-/OOXML- -Ebene untersucht; keine Inhalte wurden hochgeladen oder in Fixtures kopiert. -Die Datei ist unversioniert und darf nicht committed werden. - -| Befund | Ergebnis | -| --- | --- | -| Dateigröße / entpackte ZIP-Einträge | 56.765 / 337.740 Bytes | -| Arbeitsblätter / Blattnamenlänge | 1 / 31 Zeichen | -| Zellbereich | A1:O490 | -| Kopfzeile / Leerzeile / Objekte / Abschluss | 1 / 2 / 3–489 / 490 | -| 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 | Keine bei exaktem, case-sensitivem Vergleich | -| Formeln | Keine; synthetische Tests dafür erforderlich | -| Spaltendefinitionen | 16, obwohl nur 15 Datenspalten vorhanden sind | - -Das beobachtete Profil aus dem Auftrag wird damit bestätigt. Zusätzliche -Spaltenformatdefinitionen dürfen beim Export nicht auf die gemappten Spalten -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 endet -deshalb mit einer aus der Musterdatei erzeugten Rückgabedatei und einem -verbindlichen Linear-Test durch den Nutzer vor R3. - -## 3. Bibliothek, Adapter und Uploadgrenzen - -**Vorschlag: genau eine neue direkte Abhängigkeit `exceljs`.** Seine -öffentliche API unterstützt XLSX, Zellnotizen, Formate, Spaltenbreiten und -typisierte Werte. Das passt zum beobachteten klassischen Kommentarformat. -Version und transitive Abhängigkeiten werden in R2 festgeschrieben und -geprüft. Die veröffentlichte Version ist laut Paketregister 4.4.0; eine -aktuelle Releasepflege ist damit nicht bewiesen. Dies ist ein ausdrückliches -Wartungsrisiko, kein als erfüllt abgehakter Bibliotheksnachweis. - -Quellen, am 29.09.2026 geprüft: -[ExcelJS-Projekt](https://github.com/exceljs/exceljs), -[offizielle Paketdokumentation](https://www.npmjs.com/package/exceljs). -Keine Bibliothek wird in R0 installiert. R2 muss vor Integration Kommentar- -Roundtrip, Node-24-Verträglichkeit und Abhängigkeitsrisiken prüfen; bei einem -Blocker wird die Bibliotheksentscheidung neu vorgelegt. - -Vorgeschlagene Grenzen, zentral konfiguriert und synthetisch getestet: - -- ausschließlich `.xlsx`, kein `.xls` oder `.xlsm`; -- maximal 10 MiB Upload; -- genau ein Arbeitsblatt und keine Formelausführung; -- feste Zeilen-, Spalten- und Zellgrenzen nach dem Einlesen. - -Es gibt keinen eigenen ZIP-Prüfer und keinen Parser-Worker. - -Neutrale Matrix: Blattname, Kopfzeilen-/Startpositionen, Spaltenmetadaten -(Index, Name, Kommentartext, erkannter Parametertyp/Einheit), geordnete -Zeilen mit Originalzeilennummer und Klasse sowie Zellen als diskriminierte -Union `string | number | boolean | empty`. Formeltext und Cache-Status sind -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. - -Eine Zeile ohne Worksharing-ID ist nur verdächtig, wenn `Familie und Typ` -gefüllt ist. Sie erzeugt einen Hinweis und wird übersprungen, ohne zu -blockieren. Andere ID-lose Zeilen, auch die Summenzeile mit Inhalt in B, -werden still übersprungen. Nicht passende nichtleere IDs blockieren. -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. - -Rückgabe lädt eine Kopie der Originalbytes, bewahrt den Bereich oberhalb der -ersten Datenzeile samt Kommentaren, Formatierung und Spaltenbreiten und -ersetzt den Datenbereich durch gewählte Objektzeilen in Originalreihenfolge. -Alle Spalten bleiben enthalten; Summenzeilen entfallen. Unveränderte Zellen -behalten ihre importierten Werte und Typen. Formeln in Objektzeilen werden -als gecachte Werte ausgegeben, damit Zeilenauswahl keine falschen relativen -Bezüge erzeugt; dies wird vor Export als Hinweis ausgewiesen. Keine Formeln -werden berechnet. Roundtrip bedeutet strukturelle/semantische Gleichheit, -nicht identische ZIP-Bytes. - -## 4. Konfigurationsschema - -Neuer neutraler Vertrag `ExternalModelConfiguration`, Schema-Version 1: - -```ts -{ - schemaVersion: 1, - layout: { - headerRow: 1, firstDataRow: 3, firstDataColumn: 1 - }, - circuitMode: "combined" | "separate", - columns: { - worksharingId: string, familyAndType: string, - ifcGuid: string | null, roomNumber: string | null, - roomName: string | null, 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: [{ - id: UUID, name: string, - category: "lighting" | "single_phase" | "three_phase", - defaults: { - powerPerUnitW: number | null, simultaneityFactor: number | null, - cosPhi: number | null, costGroup: string | null - } - }], - familyTypeRules: [{ - id: UUID, exactFamilyAndType: string, deviceTypeId: UUID, - quantityRule: "one" | "socketCount" - }] -} -``` - -Zeilen/Spalten sind intern 1-basiert; UI stellt Spalten als A, B, … dar. -Es gibt nur `columns.worksharingId` und kein separates `layout.idColumn`. -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 -Auftrag. Unbekannte Spalten bleiben ohne Mapping erhalten. - -Geräteart-IDs sind interne UUIDs, keine Namen als Relationsschlüssel. Regeln -sind exakt und je Familien-/Typtext eindeutig; jede importierte Familie muss -eine Geräteart haben. Gerätearten und Regeln werden als ein versioniertes -Konfigurationsaggregat gespeichert. Keine zusätzliche Gerätearttabelle ist -für diesen Umfang nötig; Validatoren erzwingen referenzielle Integrität. -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 wird sichtbar mit `1` vorbelegt, ohne zusätzliche Bestätigung. -Geräteart- -Änderungen schreiben keine vorhandenen Objekt-Overrides oder Rows um. - -## 5. Konkretes Persistenzschema - -Bestehende UUID-/Projekt-FKs und Eigentumsprüfungen werden beibehalten. -`JSON` bezeichnet validierten JSON-Text in SQLite, nicht ExcelJS-Objekte. - -| Tabelle | Zielspalten / Constraints | -| --- | --- | -| `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` | 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_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. 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`, -`linked_project_device_id`, Export `(project_id, exported_at_iso)`. -Cross-Project-Links und Geräteart-Verweise prüft jeder Command in der -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. Eine Änderung des -Raum-Standardverteilers betrifft nur unzugeordnete Objekte; verknüpfte Objekte -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 -verwenden die Row. Beim Lösen werden aktuelle Row-Werte einschließlich -Einheitenkonvertierung in die Objektplanung übernommen und als explizite -Overrides markiert. Effektive Objektmenge wird nicht durch die Row-Gesamtmenge -ersetzt. Die Row und ihr manueller Anteil bleiben erhalten. - -## 6. Commands und Transaktionsgrenze - -Alle öffentlichen Fach-Writes verlangen `expectedRevision`, Anmeldung und -`X-Leistungsbilanz-Request: 1`. `expectedRevision` gehört wie bisher zum -Ausführungsumschlag. Jede Transition enthält vollständige erwartete/Ziel- -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 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. | -| `external-model-object.update-distribution-board` v1 | `{ objects: transitions }`; explizite Objektabweichung, Projekt-/Row-Konsistenz. | -| `external-model-room-mapping.update` v1 | `{ mappings: transitions }`; interner Raum/Standardverteiler; betroffene Objekt-/Row-Konsistenz mitprüfen. | -| `external-model-object.update-project-device-link` v1 | `{ objects: transitions, confirmedPlanningFields }`; keine Vorlagenänderung; neue Startwerte nur für ausdrücklich bestätigte Felder. Gebundene Objekte werden über ihre Row bearbeitet. | -| `external-object.update-row-assignment` v2 | `{ rows: transitions, objects: transitions, confirmedConflictObjectIds }`; Linkwechsel, materialisierte Mengen, beim Lösen aktuelle Row-Planungswerte; vollständige Inverse. | -| `external-object.assign-to-new-row` v2 | Bestehender vollständiger Row-/Objekt-/Reserveplan mit neuen Objektverträgen; history-only Inverse entfernt nur exakt unveränderte Erzeugnisse. | -| `external-object.assign-to-new-circuit` v2 | Bestehender Circuit-/Protection-/Row-/Objektplan; BMK einmal planen und festschreiben, gleiche UUIDs bei Redo. | -| `external-model-object.delete-missing` v1 | `{ objects: transitionsToNull, rows: quantityTransitions }`; ausschließlich ausdrücklich bestätigte weiterhin fehlende Objekte, kein Row-/Circuit-Löschen; Inverse stellt IDs, Links und Mengen wieder her. | - -Bestehende `project-device.insert`, Room-/Floor-Commands bleiben eigenständige -Undo-Schritte. Familien-/Geräteartentscheidungen im Wizard sind lokale -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. - -Die Konfiguration hat keine eigene Versionszählung. Vorschau und Apply binden -sich an `expectedRevision`; weil auch Undo/Redo neue, strikt steigende -Projektrevisionen erzeugen, wird ein veralteter Plan eindeutig ungültig. -Importbatches speichern eine vollständige Konfigurationskopie. Prüfen: -Änderung → Undo → anderer Zweig darf niemals denselben Plan 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, 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 lesen und -parsen keine Excel-Datei; sie wenden ausschließlich die gespeicherten -Vorher-/Nachher-Zustände an. Keine asynchronen Callbacks in -`better-sqlite3`-Transaktionen. - -Row-/Circuit-/Gruppen-Löschcommands erfassen verknüpfte Objekte vollständig. -Nach der Warnung `X Revit-Objekte werden wieder unzugeordnet` lösen sie die -Links im selben Command; ihre Inverse stellt sie exakt wieder her. Sperren -bleiben nur für das Löschen referenzierter Verteiler und Räume und gelten auch -in Unterbaum- und History-only-Pfaden. - -## 7. Migration, Snapshot 10, History und Transfer - -Neue additive Migration nach `0013_users` (voraussichtlich `0014`, Nummer -beim Beginn von R3 erneut prüfen). Bestehende SQL-/Metadateien unverändert. - -1. Vor R3-Anwendung API-Schreibzugriffe stoppen und `npm run db:backup` - ausführen; verifiziertes Backup samt Wiederherstellungsmöglichkeit sichern. - R0 verändert keine DB und benötigt daher kein Migrationsbackup. -2. Vorhandene externe CSV-Entwicklungsdaten dürfen gemäß Auftrag verworfen - werden. Zuerst je verknüpfter Row `quantity = manual_quantity` setzen; - sonst bliebe nach Entfernen der externen Objekte eine Phantomlast. - Rows, Circuits, manuelle Anteile, UUIDs und BMKs bleiben bestehen. -3. Externe Objekte → Mappings → Batches → Quellen → CSV-Konfiguration in - FK-sicherer Reihenfolge entfernen. Tabellen gezielt neu aufbauen, wo - SQLite NOT-NULL-/Unique-Änderungen dies erfordern. Neue Zieltabellen und - Indices erstellen. Keine leeren Worksharing-IDs als Backfill erfinden. -4. Generiertes SQL und Drizzle-Metadaten prüfen; saubere und bestehende - Test-DBs migrieren; FK-/Integritätsprüfung und Mengenabgleich ausführen. - Der Reset ist eine dokumentierte einmalige Entwicklungsmigration, - kein stiller Laufzeit-Import. -5. Alte Revisionsdaten nicht umschreiben, keine CSV-History heimlich - überspringen. An der Ausführungsgrenze alte CSV-Konfigurationscommands, - Initial-/Zuordnungscommands v1 einschließlich ihrer History-Inversen und - Restores mit CSV-Inhalt vor jedem Write ablehnen. - -Fehlermeldung für History: -„Dieser Verlaufsschritt verwendet die frühere CSV-/IfcGUID-Anbindung und -kann mit der Excel-Anbindung nicht ausgeführt werden.“ -Der History-Status sollte den blockierten obersten Schritt samt Grund zeigen; -keine automatisch geleerten Stacks und keine Änderung bei Ablehnung. Frühere -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, -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 -allein zählt als nicht leerer CSV-Zustand und wird nicht still verworfen. -Snapshot-Checksumme am gespeicherten Original vor Upgrade prüfen. - -Fehlermeldung: -„Dieser Projektstand enthält Daten der früheren CSV-/IfcGUID-Anbindung. -Eine automatische Übernahme in die Excel-Anbindung ist nicht möglich. -Bitte verwenden Sie einen Projektstand ohne CSV-Daten.“ - -Der aktuelle portable Transfer ist bereits **Format 2** (Grobbilanzen), -nicht Format 1 wie im alten Audit. Envelope 2 und dessen Format-1-Lesepfad -bleiben; enthaltenes Projektzustandsschema wird 10. Duplizieren remappt -Projekt-, Konfigurations-, Geräteart-, Regel-, Quellen-, Batch-, Mapping-, -Objekt-UUIDs und alle internen Links, auch in Konfigurationssnapshots der -Batches. Worksharing-IDs, optionale IfcGUIDs und Originalbytes bleiben -unverändert. Grobbilanzen und globale Office-/Auth-Daten behalten ihre -bisherige Abgrenzung. Exportnachweise werden nicht als neue Projektexporte -dupliziert. - -## 8. Read-Modelle, Oberfläche und Rückgabe - -Vorgeschlagene API-Basis `/api/projects/:projectId/revit`: -`configuration` (GET/PUT), `profile/preview` (POST, zustandslos), -`initial-import/plan|apply`, `follow-up-import/plan|apply` (POST), -`status` und `objects` (GET), `return-workbook` (POST mit Export-Audit). -Der bestehende listenbezogene External-Objects-GET bleibt erhalten. -Objektmutationen verwenden den vorhandenen Project-Command-Endpunkt mit -neuen typisierten Verträgen. CSV-Endpunkte werden entfernt, keine Aliasse. - -Export verwendet `expectedRevision` für einen konsistent gelesenen Stand; -die Datei-Erzeugung erfolgt außerhalb des kurzen Read-Snapshots. Danach -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 lädt einmal eine kompakte Objektliste. Filterung und Sortierung -laufen im Client; die Tabelle wird virtualisiert und verwendet keine Server- -Pagination. Filter-/Sortierzustand, UUID-Auswahl und Sammelaktionen sind -unabhängig vom DOM. „Alle gefilterten“ wird vor einer Mutation zu einer -expliziten ID-Auswahl an der aktuellen Revision aufgelöst. Große Auswahlmengen -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 -entstehen im Wizard und sind auf der Seite einklappbar nachbearbeitbar. -Fehlende Raumangaben bleiben zulässig, Board-Zuordnung ist auch ohne Raum -möglich. ProjectDevice-Zuordnung bleibt optional. - -Rechter Editor-Drawer: nur vorhandene, ungebundene konfliktfreie Objekte des -effektiven Verteilers. Gruppierung nach internem Raum, Auswahlkenner, -Geräteart-ID, Kategorie und identischen Planungswerten; unterschiedliche -ProjectDevice-Links bleiben ebenfalls getrennt, da eine Row nur einen Link -haben kann. Effektive Einzelmengen sind kein Gleichheitsfeld: Einfach- und -Mehrfachsteckdosen sollen gemeinsam gruppierbar sein. Anzeige enthält -Mengensumme und Objektanzahl. Fachlich heterogene Auswahl darf nicht -willkürlich auf eine einzelne Row zusammenfallen; Konfliktanzeige verlangt -eine kompatible Auswahl. Row-Indikator öffnet Objekte und explizites Lösen. - -Eine Funktion `getRevitBoardName(board)` liefert ausschließlich `board.name`. -Gemeinsam: Name + unverändertes `equipmentIdentifier`, ohne Separator. -Getrennt: Name und BMK in eigene Parameter. Ohne Circuit bleiben beide -Stromkreiswerte leer, auch wenn ein Planungsverteiler bekannt ist. - -Exportprojektion und Abweichungsanzeige teilen dieselbe reine Funktion: -Row-Anzeigename/-Leistung bei Link, sonst Objektplanung; Objektleistung in W -= effektive Menge × Einzelleistung (Row-kW vorher × 1000), ohne GZF. -Spannung vom Circuit, sonst Projektstandard passend zur Kategorie. -Strom aus Objektleistung, U, cosPhi und Phasenart; Drehstrom mit Faktor √3, -auf 0,01 A. Fehlende/ungültige Werte ergeben leer plus Hinweis. Nullleistung -bleibt bei gültigem Nenner numerisch 0. Kein still angenommenes cosPhi. -Abweichungsvergleich normalisiert Zahlpräzision, Leere und skalare Typen -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 optionale Spalten für -Bezeichnung, Leistung, Spannung und Strom werden mit Hinweis übersprungen. -Nur fehlende Stromkreisspalten des gewählten Modus blockieren. Dateiname gemäß -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 -nicht allein zum Fortschreiben von `lastSeenImportBatchId` neu geschrieben; -aktuelle Sichtbarkeit/Quellwerte kommen aus Batch/Matrix. Akzeptierte -Planungsgrundlage und letzte importierte Beobachtung sind getrennt. -Raum-/Familien-/Marker-/Mengenänderungen brauchen Entscheidungen. Bei -unvereinbarer Row-Zuordnung blockiert die Übernahme bis zum ausdrücklichen -Lösen/Umordnen, statt Rows automatisch zu erzeugen. Übernommene Mengen -ändern alle betroffenen Row-Summen im selben Importcommand. Fehlend setzt -nur den Status, erhält vorerst Link und Menge. Rückgabefeld-Abweichungen -sind Hinweise, keine Übernahmeentscheidungen. Ein völlig unveränderter -Folgeimport erzeugt einen nachvollziehbaren Batch, aber keine unnötigen -Objekt-/Row-Updates. - -## 9. Pakete, Verifikation und Risiken - -R0 liefert nur diesen Bericht und einen eigenen Commit. R1–R10 starten erst -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. 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 | 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, 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. | - -Die temporäre Grenze zwischen R3 und R4 wird ausdrücklich behandelt: -Buildfähige, nicht aktive Kompatibilitätstypen für das alte Modal dürfen bis -R4 bestehen, aber kein aktiver CSV-Backendpfad. Veraltete Projektaktion bis -zur neuen Seite deaktivieren/entfernen, keinen funktionslosen Upload anbieten. -Die Dokumentation darf Zwischenstände nicht als fertigen Workflow ausweisen. - -Pflicht je R1–R10: fokussierte Tests, `npm test`, `npm run build:api`, -`npm run build:web`, `npm run typecheck:scripts`, -`npx tsc --noEmit -p tsconfig.next.json`, je ein knapper imperativer Commit. -R0: 31 vorhandene Tests aus sechs Dateien erfolgreich ausgeführt: -`external-model-foundation`, `external-initial-import-plan`, -`external-initial-import-project-command.repository`, -`external-object-row-assignment-project-command.repository`, -`external-circuit-list-objects`, -`external-csv-configuration-project-command.repository` (je `.test.ts`). -Diese decken vorhandene Commit-/Rollback-, Undo-/Redo-, Snapshot-/Transfer- -Grundlagen ab, nicht die neue Excel-Funktion. Der erste Start scheiterte an -Sandbox-`spawn EPERM`; derselbe Lauf außerhalb der Sandbox bestand. -Vollständige Builds/Tests sind für diesen reinen R0-Bericht nicht ausgeführt. - -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 ü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. -- Row-/Circuit-/Gruppen-Löschen löst externe Links im Command und stellt sie - 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; nur sichtbare Zeilen im - DOM, stabile Auswahl über virtuelle Bereiche. - -Wesentliche Restrisiken: Linear-Kommentarbindung ist nur anhand des -Exports beobachtet; ExcelJS-Releasepflege und Roundtrip sind in R2 zu -belegen. Große Originaldateien vervielfachen sich in History/Snapshots; -Limits und Messungen müssen reale Speichergrößen berücksichtigen. Die -CSV-Entwicklungsbereinigung ist absichtlich verlustbehaftet, aber auf den -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:** R0 wurde am 29.09.2026 mit den in R1 dokumentierten -Korrekturen freigegeben. R2 besitzt einen neuen verbindlichen Freigabepunkt: -Vor Beginn von R3 muss der Nutzer die in R2 erzeugte Rückgabedatei erfolgreich -in Linear getestet haben. diff --git a/package-lock.json b/package-lock.json index 9d27840..417421b 100644 --- a/package-lock.json +++ b/package-lock.json @@ -12,7 +12,6 @@ "better-sqlite3": "^12.9.0", "bootstrap": "^5.3.8", "drizzle-orm": "^0.45.2", - "exceljs": "^4.4.0", "express": "^5.2.1", "lucide-react": "^1.14.0", "next": "^16.2.4", @@ -876,47 +875,6 @@ "node": ">=18" } }, - "node_modules/@fast-csv/format": { - "version": "4.3.5", - "resolved": "https://registry.npmjs.org/@fast-csv/format/-/format-4.3.5.tgz", - "integrity": "sha512-8iRn6QF3I8Ak78lNAa+Gdl5MJJBM5vRHivFtMRUWINdevNo00K7OXxS2PshawLKTejVwieIlPmK5YlLu6w4u8A==", - "license": "MIT", - "dependencies": { - "@types/node": "^14.0.1", - "lodash.escaperegexp": "^4.1.2", - "lodash.isboolean": "^3.0.3", - "lodash.isequal": "^4.5.0", - "lodash.isfunction": "^3.0.9", - "lodash.isnil": "^4.0.0" - } - }, - "node_modules/@fast-csv/format/node_modules/@types/node": { - "version": "14.18.63", - "resolved": "https://registry.npmjs.org/@types/node/-/node-14.18.63.tgz", - "integrity": "sha512-fAtCfv4jJg+ExtXhvCkCqUKZ+4ok/JQk01qDKhL5BDDoS3AxKXhV5/MAVUZyQnSEd2GT92fkgZl0pz0Q0AzcIQ==", - "license": "MIT" - }, - "node_modules/@fast-csv/parse": { - "version": "4.3.6", - "resolved": "https://registry.npmjs.org/@fast-csv/parse/-/parse-4.3.6.tgz", - "integrity": "sha512-uRsLYksqpbDmWaSmzvJcuApSEe38+6NQZBUsuAyMZKqHxH0g1wcJgsKUvN3WC8tewaqFjBMMGrkHmC+T7k8LvA==", - "license": "MIT", - "dependencies": { - "@types/node": "^14.0.1", - "lodash.escaperegexp": "^4.1.2", - "lodash.groupby": "^4.6.0", - "lodash.isfunction": "^3.0.9", - "lodash.isnil": "^4.0.0", - "lodash.isundefined": "^3.0.1", - "lodash.uniq": "^4.5.0" - } - }, - "node_modules/@fast-csv/parse/node_modules/@types/node": { - "version": "14.18.63", - "resolved": "https://registry.npmjs.org/@types/node/-/node-14.18.63.tgz", - "integrity": "sha512-fAtCfv4jJg+ExtXhvCkCqUKZ+4ok/JQk01qDKhL5BDDoS3AxKXhV5/MAVUZyQnSEd2GT92fkgZl0pz0Q0AzcIQ==", - "license": "MIT" - }, "node_modules/@img/colour": { "version": "1.1.0", "resolved": "https://registry.npmjs.org/@img/colour/-/colour-1.1.0.tgz", @@ -1629,87 +1587,6 @@ "node": ">= 0.6" } }, - "node_modules/archiver": { - "version": "5.3.2", - "resolved": "https://registry.npmjs.org/archiver/-/archiver-5.3.2.tgz", - "integrity": "sha512-+25nxyyznAXF7Nef3y0EbBeqmGZgeN/BxHX29Rs39djAfaFalmQ89SE6CWyDCHzGL0yt/ycBtNOmGTW0FyGWNw==", - "license": "MIT", - "dependencies": { - "archiver-utils": "^2.1.0", - "async": "^3.2.4", - "buffer-crc32": "^0.2.1", - "readable-stream": "^3.6.0", - "readdir-glob": "^1.1.2", - "tar-stream": "^2.2.0", - "zip-stream": "^4.1.0" - }, - "engines": { - "node": ">= 10" - } - }, - "node_modules/archiver-utils": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/archiver-utils/-/archiver-utils-2.1.0.tgz", - "integrity": "sha512-bEL/yUb/fNNiNTuUz979Z0Yg5L+LzLxGJz8x79lYmR54fmTIb6ob/hNQgkQnIUDWIFjZVQwl9Xs356I6BAMHfw==", - "license": "MIT", - "dependencies": { - "glob": "^7.1.4", - "graceful-fs": "^4.2.0", - "lazystream": "^1.0.0", - "lodash.defaults": "^4.2.0", - "lodash.difference": "^4.5.0", - "lodash.flatten": "^4.4.0", - "lodash.isplainobject": "^4.0.6", - "lodash.union": "^4.6.0", - "normalize-path": "^3.0.0", - "readable-stream": "^2.0.0" - }, - "engines": { - "node": ">= 6" - } - }, - "node_modules/archiver-utils/node_modules/readable-stream": { - "version": "2.3.8", - "resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-2.3.8.tgz", - "integrity": "sha512-8p0AUk4XODgIewSi0l8Epjs+EVnWiK7NoDIEGU0HhE7+ZyY8D1IMY7odu5lRrFXGg71L15KG8QrPmum45RTtdA==", - "license": "MIT", - "dependencies": { - "core-util-is": "~1.0.0", - "inherits": "~2.0.3", - "isarray": "~1.0.0", - "process-nextick-args": "~2.0.0", - "safe-buffer": "~5.1.1", - "string_decoder": "~1.1.1", - "util-deprecate": "~1.0.1" - } - }, - "node_modules/archiver-utils/node_modules/safe-buffer": { - "version": "5.1.2", - "resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.1.2.tgz", - "integrity": "sha512-Gd2UZBJDkXlY7GbJxfsE8/nvKkUEU1G38c1siN6QP6a9PT9MmHB8GnpscSmMJSoF8LOIrt8ud/wPtojys4G6+g==", - "license": "MIT" - }, - "node_modules/archiver-utils/node_modules/string_decoder": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/string_decoder/-/string_decoder-1.1.1.tgz", - "integrity": "sha512-n/ShnvDi6FHbbVfviro+WojiFzv+s8MPMHBczVePfUpDJLwoLT0ht1l4YwBCbi8pJAveEEdnkHyPyTP/mzRfwg==", - "license": "MIT", - "dependencies": { - "safe-buffer": "~5.1.0" - } - }, - "node_modules/async": { - "version": "3.2.6", - "resolved": "https://registry.npmjs.org/async/-/async-3.2.6.tgz", - "integrity": "sha512-htCUDlxyyCLMgaM3xXg0C0LW2xqfuQ6p05pCEIsXuyQ+a1koYKTuBMzRNwmybfLgvJDMd0r1LTn4+E0Ti6C2AA==", - "license": "MIT" - }, - "node_modules/balanced-match": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-1.0.2.tgz", - "integrity": "sha512-3oSeUO0TMV67hN1AmbXsK4yaqU7tjiHlbxRDZOpH0KW9+CeX4bRAaX0Anxt0tx2MrpRpWwQaPwIlISEJhYU5Pw==", - "license": "MIT" - }, "node_modules/base64-js": { "version": "1.5.1", "resolved": "https://registry.npmjs.org/base64-js/-/base64-js-1.5.1.tgz", @@ -1753,28 +1630,6 @@ "node": "20.x || 22.x || 23.x || 24.x || 25.x" } }, - "node_modules/big-integer": { - "version": "1.6.52", - "resolved": "https://registry.npmjs.org/big-integer/-/big-integer-1.6.52.tgz", - "integrity": "sha512-QxD8cf2eVqJOOz63z6JIN9BzvVs/dlySa5HGSBH5xtR8dPteIRQnBxxKqkNTiT6jbDTF6jAfrd4oMcND9RGbQg==", - "license": "Unlicense", - "engines": { - "node": ">=0.6" - } - }, - "node_modules/binary": { - "version": "0.3.0", - "resolved": "https://registry.npmjs.org/binary/-/binary-0.3.0.tgz", - "integrity": "sha512-D4H1y5KYwpJgK8wk1Cue5LLPgmwHKYSChkbspQg5JtVuR5ulGckxfR62H3AE9UDkdMC8yyXlqYihuz3Aqg2XZg==", - "license": "MIT", - "dependencies": { - "buffers": "~0.1.1", - "chainsaw": "~0.1.0" - }, - "engines": { - "node": "*" - } - }, "node_modules/bindings": { "version": "1.5.0", "resolved": "https://registry.npmjs.org/bindings/-/bindings-1.5.0.tgz", @@ -1793,12 +1648,6 @@ "readable-stream": "^3.4.0" } }, - "node_modules/bluebird": { - "version": "3.4.7", - "resolved": "https://registry.npmjs.org/bluebird/-/bluebird-3.4.7.tgz", - "integrity": "sha512-iD3898SR7sWVRHbiQv+sHUtHnMvC1o3nW5rAcqnq3uOn07DSAppZYUkIGslDz6gXC7HfunPe7YVBgoEJASPcHA==", - "license": "MIT" - }, "node_modules/body-parser": { "version": "2.2.2", "resolved": "https://registry.npmjs.org/body-parser/-/body-parser-2.2.2.tgz", @@ -1840,16 +1689,6 @@ "@popperjs/core": "^2.11.8" } }, - "node_modules/brace-expansion": { - "version": "1.1.21", - "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.21.tgz", - "integrity": "sha512-9zeA+KLZNNzglF2TPKRQEDyx6Yby7daAkuy8MiPzpXPsYDWi/DRM8jmwUDxokQjYqBpv5DgPiwD4h4ZZSy1Ujw==", - "license": "MIT", - "dependencies": { - "balanced-match": "^1.0.0", - "concat-map": "0.0.1" - } - }, "node_modules/buffer": { "version": "5.7.1", "resolved": "https://registry.npmjs.org/buffer/-/buffer-5.7.1.tgz", @@ -1873,38 +1712,12 @@ "ieee754": "^1.1.13" } }, - "node_modules/buffer-crc32": { - "version": "0.2.13", - "resolved": "https://registry.npmjs.org/buffer-crc32/-/buffer-crc32-0.2.13.tgz", - "integrity": "sha512-VO9Ht/+p3SN7SKWqcrgEzjGbRSJYTx+Q1pTQC0wrWqHx0vpJraQ6GtHx8tvcg1rlK1byhU5gccxgOgj7B0TDkQ==", - "license": "MIT", - "engines": { - "node": "*" - } - }, "node_modules/buffer-from": { "version": "1.1.2", "resolved": "https://registry.npmjs.org/buffer-from/-/buffer-from-1.1.2.tgz", "integrity": "sha512-E+XQCRwSbaaiChtv6k6Dwgc+bx+Bs6vuKJHHl5kox/BaKbhiXzqQOwK4cO22yElGp2OCmjwVhT3HmxgyPGnJfQ==", "dev": true }, - "node_modules/buffer-indexof-polyfill": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/buffer-indexof-polyfill/-/buffer-indexof-polyfill-1.0.2.tgz", - "integrity": "sha512-I7wzHwA3t1/lwXQh+A5PbNvJxgfo5r3xulgpYDB5zckTu/Z9oUK9biouBKQUjEqzaz3HnAT6TYoovmE+GqSf7A==", - "license": "MIT", - "engines": { - "node": ">=0.10" - } - }, - "node_modules/buffers": { - "version": "0.1.1", - "resolved": "https://registry.npmjs.org/buffers/-/buffers-0.1.1.tgz", - "integrity": "sha512-9q/rDEGSb/Qsvv2qvzIzdluL5k7AaJOTrw23z9reQthrbF7is4CtlT0DXyO1oei2DCp4uojjzQ7igaSHp1kAEQ==", - "engines": { - "node": ">=0.2.0" - } - }, "node_modules/bytes": { "version": "3.1.2", "resolved": "https://registry.npmjs.org/bytes/-/bytes-3.1.2.tgz", @@ -1959,18 +1772,6 @@ } ] }, - "node_modules/chainsaw": { - "version": "0.1.0", - "resolved": "https://registry.npmjs.org/chainsaw/-/chainsaw-0.1.0.tgz", - "integrity": "sha512-75kWfWt6MEKNC8xYXIdRpDehRYY/tNSgwKaJq+dbbDcxORuVrrQ+SEHoWsniVn9XPYfP4gmdWIeDk/4YNp1rNQ==", - "license": "MIT/X11", - "dependencies": { - "traverse": ">=0.3.0 <0.4" - }, - "engines": { - "node": "*" - } - }, "node_modules/chownr": { "version": "1.1.4", "resolved": "https://registry.npmjs.org/chownr/-/chownr-1.1.4.tgz", @@ -1981,27 +1782,6 @@ "resolved": "https://registry.npmjs.org/client-only/-/client-only-0.0.1.tgz", "integrity": "sha512-IV3Ou0jSMzZrd3pZ48nLkT9DA7Ag1pnPzaiQhpW7c3RbcqqzvzzVu+L8gfqMp/8IM2MQtSiqaCxrrcfu8I8rMA==" }, - "node_modules/compress-commons": { - "version": "4.1.2", - "resolved": "https://registry.npmjs.org/compress-commons/-/compress-commons-4.1.2.tgz", - "integrity": "sha512-D3uMHtGc/fcO1Gt1/L7i1e33VOvD4A9hfQLP+6ewd+BvG/gQ84Yh4oftEhAdjSMgBgwGL+jsppT7JYNpo6MHHg==", - "license": "MIT", - "dependencies": { - "buffer-crc32": "^0.2.13", - "crc32-stream": "^4.0.2", - "normalize-path": "^3.0.0", - "readable-stream": "^3.6.0" - }, - "engines": { - "node": ">= 10" - } - }, - "node_modules/concat-map": { - "version": "0.0.1", - "resolved": "https://registry.npmjs.org/concat-map/-/concat-map-0.0.1.tgz", - "integrity": "sha512-/Srv4dswyQNBfohGpz9o6Yb3Gz3SrUDqBH5rTuhGR7ahtlbYKnVxw2bCFMRljaA7EXHaXZ8wsHdodFvbkhKmqg==", - "license": "MIT" - }, "node_modules/content-disposition": { "version": "1.1.0", "resolved": "https://registry.npmjs.org/content-disposition/-/content-disposition-1.1.0.tgz", @@ -2038,49 +1818,12 @@ "node": ">=6.6.0" } }, - "node_modules/core-util-is": { - "version": "1.0.3", - "resolved": "https://registry.npmjs.org/core-util-is/-/core-util-is-1.0.3.tgz", - "integrity": "sha512-ZQBvi1DcpJ4GDqanjucZ2Hj3wEO5pZDS89BWbkcrvdxksJorwUDDZamX9ldFkp9aw2lmBDLgkObEA4DWNJ9FYQ==", - "license": "MIT" - }, - "node_modules/crc-32": { - "version": "1.2.2", - "resolved": "https://registry.npmjs.org/crc-32/-/crc-32-1.2.2.tgz", - "integrity": "sha512-ROmzCKrTnOwybPcJApAA6WBWij23HVfGVNKqqrZpuyZOHqK2CwHSvpGuyt/UNNvaIjEd8X5IFGp4Mh+Ie1IHJQ==", - "license": "Apache-2.0", - "bin": { - "crc32": "bin/crc32.njs" - }, - "engines": { - "node": ">=0.8" - } - }, - "node_modules/crc32-stream": { - "version": "4.0.3", - "resolved": "https://registry.npmjs.org/crc32-stream/-/crc32-stream-4.0.3.tgz", - "integrity": "sha512-NT7w2JVU7DFroFdYkeq8cywxrgjPHWkdX1wjpRQXPX5Asews3tA+Ght6lddQO5Mkumffp3X7GEqku3epj2toIw==", - "license": "MIT", - "dependencies": { - "crc-32": "^1.2.0", - "readable-stream": "^3.4.0" - }, - "engines": { - "node": ">= 10" - } - }, "node_modules/csstype": { "version": "3.2.3", "resolved": "https://registry.npmjs.org/csstype/-/csstype-3.2.3.tgz", "integrity": "sha512-z1HGKcYy2xA8AGQfwrn0PAy+PB7X/GSj3UVJW9qKyn43xWa+gl5nXmU4qqLMRzWVLFC8KusUX8T/0kCiOYpAIQ==", "dev": true }, - "node_modules/dayjs": { - "version": "1.11.23", - "resolved": "https://registry.npmjs.org/dayjs/-/dayjs-1.11.23.tgz", - "integrity": "sha512-QDTCU0M0MxR3hQfnlDJfwekQiaanm1ubOD231u73WBckQ/fsamwRLiE2GBz6D3a/xF1NgfiDLJjXBa1hYOYTtQ==", - "license": "MIT" - }, "node_modules/debug": { "version": "4.4.3", "resolved": "https://registry.npmjs.org/debug/-/debug-4.4.3.tgz", @@ -2287,45 +2030,6 @@ "node": ">= 0.4" } }, - "node_modules/duplexer2": { - "version": "0.1.4", - "resolved": "https://registry.npmjs.org/duplexer2/-/duplexer2-0.1.4.tgz", - "integrity": "sha512-asLFVfWWtJ90ZyOUHMqk7/S2w2guQKxUI2itj3d92ADHhxUSbCMGi1f1cBcJ7xM1To+pE/Khbwo1yuNbMEPKeA==", - "license": "BSD-3-Clause", - "dependencies": { - "readable-stream": "^2.0.2" - } - }, - "node_modules/duplexer2/node_modules/readable-stream": { - "version": "2.3.8", - "resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-2.3.8.tgz", - "integrity": "sha512-8p0AUk4XODgIewSi0l8Epjs+EVnWiK7NoDIEGU0HhE7+ZyY8D1IMY7odu5lRrFXGg71L15KG8QrPmum45RTtdA==", - "license": "MIT", - "dependencies": { - "core-util-is": "~1.0.0", - "inherits": "~2.0.3", - "isarray": "~1.0.0", - "process-nextick-args": "~2.0.0", - "safe-buffer": "~5.1.1", - "string_decoder": "~1.1.1", - "util-deprecate": "~1.0.1" - } - }, - "node_modules/duplexer2/node_modules/safe-buffer": { - "version": "5.1.2", - "resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.1.2.tgz", - "integrity": "sha512-Gd2UZBJDkXlY7GbJxfsE8/nvKkUEU1G38c1siN6QP6a9PT9MmHB8GnpscSmMJSoF8LOIrt8ud/wPtojys4G6+g==", - "license": "MIT" - }, - "node_modules/duplexer2/node_modules/string_decoder": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/string_decoder/-/string_decoder-1.1.1.tgz", - "integrity": "sha512-n/ShnvDi6FHbbVfviro+WojiFzv+s8MPMHBczVePfUpDJLwoLT0ht1l4YwBCbi8pJAveEEdnkHyPyTP/mzRfwg==", - "license": "MIT", - "dependencies": { - "safe-buffer": "~5.1.0" - } - }, "node_modules/ee-first": { "version": "1.1.1", "resolved": "https://registry.npmjs.org/ee-first/-/ee-first-1.1.1.tgz", @@ -2428,26 +2132,6 @@ "node": ">= 0.6" } }, - "node_modules/exceljs": { - "version": "4.4.0", - "resolved": "https://registry.npmjs.org/exceljs/-/exceljs-4.4.0.tgz", - "integrity": "sha512-XctvKaEMaj1Ii9oDOqbW/6e1gXknSY4g/aLCDicOXqBE4M0nRWkUu0PTp++UPNzoFY12BNHMfs/VadKIS6llvg==", - "license": "MIT", - "dependencies": { - "archiver": "^5.0.0", - "dayjs": "^1.8.34", - "fast-csv": "^4.3.1", - "jszip": "^3.10.1", - "readable-stream": "^3.6.0", - "saxes": "^5.0.1", - "tmp": "^0.2.0", - "unzipper": "^0.10.11", - "uuid": "^8.3.0" - }, - "engines": { - "node": ">=8.3.0" - } - }, "node_modules/expand-template": { "version": "2.0.3", "resolved": "https://registry.npmjs.org/expand-template/-/expand-template-2.0.3.tgz", @@ -2498,19 +2182,6 @@ "url": "https://opencollective.com/express" } }, - "node_modules/fast-csv": { - "version": "4.3.6", - "resolved": "https://registry.npmjs.org/fast-csv/-/fast-csv-4.3.6.tgz", - "integrity": "sha512-2RNSpuwwsJGP0frGsOmTb9oUF+VkFSM4SyLTDgwf2ciHWTarN0lQTC+F2f/t5J9QjW+c65VFIAAu85GsvMIusw==", - "license": "MIT", - "dependencies": { - "@fast-csv/format": "4.3.5", - "@fast-csv/parse": "4.3.6" - }, - "engines": { - "node": ">=10.0.0" - } - }, "node_modules/file-uri-to-path": { "version": "1.0.0", "resolved": "https://registry.npmjs.org/file-uri-to-path/-/file-uri-to-path-1.0.0.tgz", @@ -2557,12 +2228,6 @@ "resolved": "https://registry.npmjs.org/fs-constants/-/fs-constants-1.0.0.tgz", "integrity": "sha512-y6OAwoSIf7FyjMIv94u+b5rdheZEjzR63GTyZJm5qh4Bi+2YgwLCcI/fPFZkL5PSixOt6ZNKm+w+Hfp/Bciwow==" }, - "node_modules/fs.realpath": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/fs.realpath/-/fs.realpath-1.0.0.tgz", - "integrity": "sha512-OO0pH2lK6a0hZnAdau5ItzHPI6pUlvI7jMVnxUQRtw4owF2wk8lOSabtGDCTP4Ggrg2MbGnWO9X8K1t4+fGMDw==", - "license": "ISC" - }, "node_modules/fsevents": { "version": "2.3.3", "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-2.3.3.tgz", @@ -2577,22 +2242,6 @@ "node": "^8.16.0 || ^10.6.0 || >=11.0.0" } }, - "node_modules/fstream": { - "version": "1.0.12", - "resolved": "https://registry.npmjs.org/fstream/-/fstream-1.0.12.tgz", - "integrity": "sha512-WvJ193OHa0GHPEL+AycEJgxvBEwyfRkN1vhjca23OaPVMCaLCXTd5qAu82AjTcgP1UJmytkOKb63Ypde7raDIg==", - "deprecated": "This package is no longer supported.", - "license": "ISC", - "dependencies": { - "graceful-fs": "^4.1.2", - "inherits": "~2.0.0", - "mkdirp": ">=0.5 0", - "rimraf": "2" - }, - "engines": { - "node": ">=0.6" - } - }, "node_modules/function-bind": { "version": "1.1.2", "resolved": "https://registry.npmjs.org/function-bind/-/function-bind-1.1.2.tgz", @@ -2653,27 +2302,6 @@ "resolved": "https://registry.npmjs.org/github-from-package/-/github-from-package-0.0.0.tgz", "integrity": "sha512-SyHy3T1v2NUXn29OsWdxmK6RwHD+vkj3v8en8AOBZ1wBQ/hCAQ5bAQTD02kW4W9tUp/3Qh6J8r9EvntiyCmOOw==" }, - "node_modules/glob": { - "version": "7.2.3", - "resolved": "https://registry.npmjs.org/glob/-/glob-7.2.3.tgz", - "integrity": "sha512-nFR0zLpU2YCaRxwoCJvL6UvCH2JFyFVIvwTLsIf21AuHlMskA1hhTdk+LlYJtOlYt9v6dvszD2BGRqBL+iQK9Q==", - "deprecated": "Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me", - "license": "ISC", - "dependencies": { - "fs.realpath": "^1.0.0", - "inflight": "^1.0.4", - "inherits": "2", - "minimatch": "^3.1.1", - "once": "^1.3.0", - "path-is-absolute": "^1.0.0" - }, - "engines": { - "node": "*" - }, - "funding": { - "url": "https://github.com/sponsors/isaacs" - } - }, "node_modules/gopd": { "version": "1.2.0", "resolved": "https://registry.npmjs.org/gopd/-/gopd-1.2.0.tgz", @@ -2685,12 +2313,6 @@ "url": "https://github.com/sponsors/ljharb" } }, - "node_modules/graceful-fs": { - "version": "4.2.11", - "resolved": "https://registry.npmjs.org/graceful-fs/-/graceful-fs-4.2.11.tgz", - "integrity": "sha512-RbJ5/jmFcNNCcDV5o9eTnBLJ/HszWV0P73bc+Ff4nS/rJj+YaS6IGyiOL0VoBYX+l1Wrl3k63h/KrH+nhJ0XvQ==", - "license": "ISC" - }, "node_modules/has-symbols": { "version": "1.1.0", "resolved": "https://registry.npmjs.org/has-symbols/-/has-symbols-1.1.0.tgz", @@ -2766,23 +2388,6 @@ } ] }, - "node_modules/immediate": { - "version": "3.0.6", - "resolved": "https://registry.npmjs.org/immediate/-/immediate-3.0.6.tgz", - "integrity": "sha512-XXOFtyqDjNDAQxVfYxuF7g9Il/IbWmmlQg2MYKOH8ExIT1qg6xc4zyS3HaEEATgs1btfzxq15ciUiY7gjSXRGQ==", - "license": "MIT" - }, - "node_modules/inflight": { - "version": "1.0.6", - "resolved": "https://registry.npmjs.org/inflight/-/inflight-1.0.6.tgz", - "integrity": "sha512-k92I/b08q4wvFscXCLvqfsHCrjrF7yiXsQuIVvVE7N82W3+aqpzuUdBbfhWcy/FZR3/4IgflMgKLOsvPDrGCJA==", - "deprecated": "This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.", - "license": "ISC", - "dependencies": { - "once": "^1.3.0", - "wrappy": "1" - } - }, "node_modules/inherits": { "version": "2.0.4", "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.4.tgz", @@ -2806,190 +2411,6 @@ "resolved": "https://registry.npmjs.org/is-promise/-/is-promise-4.0.0.tgz", "integrity": "sha512-hvpoI6korhJMnej285dSg6nu1+e6uxs7zG3BYAm5byqDsgJNWwxzM6z6iZiAgQR4TJ30JmBTOwqZUw3WlyH3AQ==" }, - "node_modules/isarray": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/isarray/-/isarray-1.0.0.tgz", - "integrity": "sha512-VLghIWNM6ELQzo7zwmcg0NmTVyWKYjvIeM83yjp0wRDTmUnrM678fQbcKBo6n2CJEF0szoG//ytg+TKla89ALQ==", - "license": "MIT" - }, - "node_modules/jszip": { - "version": "3.10.2", - "resolved": "https://registry.npmjs.org/jszip/-/jszip-3.10.2.tgz", - "integrity": "sha512-3l+rb15IOWtUhU0H5MFqES/T6Kh7abYwjosBey/vD6hDt8zoEffkSC5Ws5SGtgVw3gBx2NEbhTeSW1+kWkpyTQ==", - "license": "(MIT OR GPL-3.0-or-later)", - "dependencies": { - "lie": "~3.3.0", - "pako": "~1.0.2", - "readable-stream": "~2.3.6", - "setimmediate": "^1.0.5" - } - }, - "node_modules/jszip/node_modules/readable-stream": { - "version": "2.3.8", - "resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-2.3.8.tgz", - "integrity": "sha512-8p0AUk4XODgIewSi0l8Epjs+EVnWiK7NoDIEGU0HhE7+ZyY8D1IMY7odu5lRrFXGg71L15KG8QrPmum45RTtdA==", - "license": "MIT", - "dependencies": { - "core-util-is": "~1.0.0", - "inherits": "~2.0.3", - "isarray": "~1.0.0", - "process-nextick-args": "~2.0.0", - "safe-buffer": "~5.1.1", - "string_decoder": "~1.1.1", - "util-deprecate": "~1.0.1" - } - }, - "node_modules/jszip/node_modules/safe-buffer": { - "version": "5.1.2", - "resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.1.2.tgz", - "integrity": "sha512-Gd2UZBJDkXlY7GbJxfsE8/nvKkUEU1G38c1siN6QP6a9PT9MmHB8GnpscSmMJSoF8LOIrt8ud/wPtojys4G6+g==", - "license": "MIT" - }, - "node_modules/jszip/node_modules/string_decoder": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/string_decoder/-/string_decoder-1.1.1.tgz", - "integrity": "sha512-n/ShnvDi6FHbbVfviro+WojiFzv+s8MPMHBczVePfUpDJLwoLT0ht1l4YwBCbi8pJAveEEdnkHyPyTP/mzRfwg==", - "license": "MIT", - "dependencies": { - "safe-buffer": "~5.1.0" - } - }, - "node_modules/lazystream": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/lazystream/-/lazystream-1.0.1.tgz", - "integrity": "sha512-b94GiNHQNy6JNTrt5w6zNyffMrNkXZb3KTkCZJb2V1xaEGCk093vkZ2jk3tpaeP33/OiXC+WvK9AxUebnf5nbw==", - "license": "MIT", - "dependencies": { - "readable-stream": "^2.0.5" - }, - "engines": { - "node": ">= 0.6.3" - } - }, - "node_modules/lazystream/node_modules/readable-stream": { - "version": "2.3.8", - "resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-2.3.8.tgz", - "integrity": "sha512-8p0AUk4XODgIewSi0l8Epjs+EVnWiK7NoDIEGU0HhE7+ZyY8D1IMY7odu5lRrFXGg71L15KG8QrPmum45RTtdA==", - "license": "MIT", - "dependencies": { - "core-util-is": "~1.0.0", - "inherits": "~2.0.3", - "isarray": "~1.0.0", - "process-nextick-args": "~2.0.0", - "safe-buffer": "~5.1.1", - "string_decoder": "~1.1.1", - "util-deprecate": "~1.0.1" - } - }, - "node_modules/lazystream/node_modules/safe-buffer": { - "version": "5.1.2", - "resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.1.2.tgz", - "integrity": "sha512-Gd2UZBJDkXlY7GbJxfsE8/nvKkUEU1G38c1siN6QP6a9PT9MmHB8GnpscSmMJSoF8LOIrt8ud/wPtojys4G6+g==", - "license": "MIT" - }, - "node_modules/lazystream/node_modules/string_decoder": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/string_decoder/-/string_decoder-1.1.1.tgz", - "integrity": "sha512-n/ShnvDi6FHbbVfviro+WojiFzv+s8MPMHBczVePfUpDJLwoLT0ht1l4YwBCbi8pJAveEEdnkHyPyTP/mzRfwg==", - "license": "MIT", - "dependencies": { - "safe-buffer": "~5.1.0" - } - }, - "node_modules/lie": { - "version": "3.3.0", - "resolved": "https://registry.npmjs.org/lie/-/lie-3.3.0.tgz", - "integrity": "sha512-UaiMJzeWRlEujzAuw5LokY1L5ecNQYZKfmyZ9L7wDHb/p5etKaxXhohBcrw0EYby+G/NA52vRSN4N39dxHAIwQ==", - "license": "MIT", - "dependencies": { - "immediate": "~3.0.5" - } - }, - "node_modules/listenercount": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/listenercount/-/listenercount-1.0.1.tgz", - "integrity": "sha512-3mk/Zag0+IJxeDrxSgaDPy4zZ3w05PRZeJNnlWhzFz5OkX49J4krc+A8X2d2M69vGMBEX0uyl8M+W+8gH+kBqQ==", - "license": "ISC" - }, - "node_modules/lodash.defaults": { - "version": "4.2.0", - "resolved": "https://registry.npmjs.org/lodash.defaults/-/lodash.defaults-4.2.0.tgz", - "integrity": "sha512-qjxPLHd3r5DnsdGacqOMU6pb/avJzdh9tFX2ymgoZE27BmjXrNy/y4LoaiTeAb+O3gL8AfpJGtqfX/ae2leYYQ==", - "license": "MIT" - }, - "node_modules/lodash.difference": { - "version": "4.5.0", - "resolved": "https://registry.npmjs.org/lodash.difference/-/lodash.difference-4.5.0.tgz", - "integrity": "sha512-dS2j+W26TQ7taQBGN8Lbbq04ssV3emRw4NY58WErlTO29pIqS0HmoT5aJ9+TUQ1N3G+JOZSji4eugsWwGp9yPA==", - "license": "MIT" - }, - "node_modules/lodash.escaperegexp": { - "version": "4.1.2", - "resolved": "https://registry.npmjs.org/lodash.escaperegexp/-/lodash.escaperegexp-4.1.2.tgz", - "integrity": "sha512-TM9YBvyC84ZxE3rgfefxUWiQKLilstD6k7PTGt6wfbtXF8ixIJLOL3VYyV/z+ZiPLsVxAsKAFVwWlWeb2Y8Yyw==", - "license": "MIT" - }, - "node_modules/lodash.flatten": { - "version": "4.4.0", - "resolved": "https://registry.npmjs.org/lodash.flatten/-/lodash.flatten-4.4.0.tgz", - "integrity": "sha512-C5N2Z3DgnnKr0LOpv/hKCgKdb7ZZwafIrsesve6lmzvZIRZRGaZ/l6Q8+2W7NaT+ZwO3fFlSCzCzrDCFdJfZ4g==", - "license": "MIT" - }, - "node_modules/lodash.groupby": { - "version": "4.6.0", - "resolved": "https://registry.npmjs.org/lodash.groupby/-/lodash.groupby-4.6.0.tgz", - "integrity": "sha512-5dcWxm23+VAoz+awKmBaiBvzox8+RqMgFhi7UvX9DHZr2HdxHXM/Wrf8cfKpsW37RNrvtPn6hSwNqurSILbmJw==", - "license": "MIT" - }, - "node_modules/lodash.isboolean": { - "version": "3.0.3", - "resolved": "https://registry.npmjs.org/lodash.isboolean/-/lodash.isboolean-3.0.3.tgz", - "integrity": "sha512-Bz5mupy2SVbPHURB98VAcw+aHh4vRV5IPNhILUCsOzRmsTmSQ17jIuqopAentWoehktxGd9e/hbIXq980/1QJg==", - "license": "MIT" - }, - "node_modules/lodash.isequal": { - "version": "4.5.0", - "resolved": "https://registry.npmjs.org/lodash.isequal/-/lodash.isequal-4.5.0.tgz", - "integrity": "sha512-pDo3lu8Jhfjqls6GkMgpahsF9kCyayhgykjyLMNFTKWrpVdAQtYyB4muAMWozBB4ig/dtWAmsMxLEI8wuz+DYQ==", - "deprecated": "This package is deprecated. Use require('node:util').isDeepStrictEqual instead.", - "license": "MIT" - }, - "node_modules/lodash.isfunction": { - "version": "3.0.9", - "resolved": "https://registry.npmjs.org/lodash.isfunction/-/lodash.isfunction-3.0.9.tgz", - "integrity": "sha512-AirXNj15uRIMMPihnkInB4i3NHeb4iBtNg9WRWuK2o31S+ePwwNmDPaTL3o7dTJ+VXNZim7rFs4rxN4YU1oUJw==", - "license": "MIT" - }, - "node_modules/lodash.isnil": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/lodash.isnil/-/lodash.isnil-4.0.0.tgz", - "integrity": "sha512-up2Mzq3545mwVnMhTDMdfoG1OurpA/s5t88JmQX809eH3C8491iu2sfKhTfhQtKY78oPNhiaHJUpT/dUDAAtng==", - "license": "MIT" - }, - "node_modules/lodash.isplainobject": { - "version": "4.0.6", - "resolved": "https://registry.npmjs.org/lodash.isplainobject/-/lodash.isplainobject-4.0.6.tgz", - "integrity": "sha512-oSXzaWypCMHkPC3NvBEaPHf0KsA5mvPrOPgQWDsbg8n7orZ290M0BmC/jgRZ4vcJ6DTAhjrsSYgdsW/F+MFOBA==", - "license": "MIT" - }, - "node_modules/lodash.isundefined": { - "version": "3.0.1", - "resolved": "https://registry.npmjs.org/lodash.isundefined/-/lodash.isundefined-3.0.1.tgz", - "integrity": "sha512-MXB1is3s899/cD8jheYYE2V9qTHwKvt+npCwpD+1Sxm3Q3cECXCiYHjeHWXNwr6Q0SOBPrYUDxendrO6goVTEA==", - "license": "MIT" - }, - "node_modules/lodash.union": { - "version": "4.6.0", - "resolved": "https://registry.npmjs.org/lodash.union/-/lodash.union-4.6.0.tgz", - "integrity": "sha512-c4pB2CdGrGdjMKYLA+XiRDO7Y0PRQbm/Gzg8qMj+QH+pFVAoTp5sBpO0odL3FjoPCGjK96p6qsP+yQoiLoOBcw==", - "license": "MIT" - }, - "node_modules/lodash.uniq": { - "version": "4.5.0", - "resolved": "https://registry.npmjs.org/lodash.uniq/-/lodash.uniq-4.5.0.tgz", - "integrity": "sha512-xfBaXQd9ryd9dlSDvnvI0lvxfLJlYAZzXomUYzLKtUeOQvOP5piqAWuGtrhWeqaXK9hhoM/iyJc5AV+XfsX3HQ==", - "license": "MIT" - }, "node_modules/lucide-react": { "version": "1.14.0", "resolved": "https://registry.npmjs.org/lucide-react/-/lucide-react-1.14.0.tgz", @@ -3059,18 +2480,6 @@ "url": "https://github.com/sponsors/sindresorhus" } }, - "node_modules/minimatch": { - "version": "3.1.5", - "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-3.1.5.tgz", - "integrity": "sha512-VgjWUsnnT6n+NUk6eZq77zeFdpW2LWDzP6zFGrCbHXiYNul5Dzqk2HHQ5uFH2DNW5Xbp8+jVzaeNt94ssEEl4w==", - "license": "ISC", - "dependencies": { - "brace-expansion": "^1.1.7" - }, - "engines": { - "node": "*" - } - }, "node_modules/minimist": { "version": "1.2.8", "resolved": "https://registry.npmjs.org/minimist/-/minimist-1.2.8.tgz", @@ -3079,18 +2488,6 @@ "url": "https://github.com/sponsors/ljharb" } }, - "node_modules/mkdirp": { - "version": "0.5.6", - "resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-0.5.6.tgz", - "integrity": "sha512-FP+p8RB8OWpF3YZBCrP5gtADmtXApB5AMLn+vdyA+PyxCjrCs00mjyUozssO33cwDeT3wNGdLxJ5M//YqtHAJw==", - "license": "MIT", - "dependencies": { - "minimist": "^1.2.6" - }, - "bin": { - "mkdirp": "bin/cmd.js" - } - }, "node_modules/mkdirp-classic": { "version": "0.5.3", "resolved": "https://registry.npmjs.org/mkdirp-classic/-/mkdirp-classic-0.5.3.tgz", @@ -3194,15 +2591,6 @@ "node": ">=10" } }, - "node_modules/normalize-path": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz", - "integrity": "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==", - "license": "MIT", - "engines": { - "node": ">=0.10.0" - } - }, "node_modules/object-inspect": { "version": "1.13.4", "resolved": "https://registry.npmjs.org/object-inspect/-/object-inspect-1.13.4.tgz", @@ -3233,12 +2621,6 @@ "wrappy": "1" } }, - "node_modules/pako": { - "version": "1.0.11", - "resolved": "https://registry.npmjs.org/pako/-/pako-1.0.11.tgz", - "integrity": "sha512-4hLB8Py4zZce5s4yd9XzopqwVv/yGNhV1Bl8NTmCq1763HeK2+EwVTv+leGeL13Dnh2wfbqowVPXCIO0z4taYw==", - "license": "(MIT AND Zlib)" - }, "node_modules/parseurl": { "version": "1.3.3", "resolved": "https://registry.npmjs.org/parseurl/-/parseurl-1.3.3.tgz", @@ -3247,15 +2629,6 @@ "node": ">= 0.8" } }, - "node_modules/path-is-absolute": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/path-is-absolute/-/path-is-absolute-1.0.1.tgz", - "integrity": "sha512-AVbw3UJ2e9bq64vSaS9Am0fje1Pa8pbGqTTsmXfaIiMpnr5DlDhfJOuLj9Sf95ZPVDAUerDfEk88MPmPe7UCQg==", - "license": "MIT", - "engines": { - "node": ">=0.10.0" - } - }, "node_modules/path-to-regexp": { "version": "8.4.2", "resolved": "https://registry.npmjs.org/path-to-regexp/-/path-to-regexp-8.4.2.tgz", @@ -3323,12 +2696,6 @@ "node": ">=10" } }, - "node_modules/process-nextick-args": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/process-nextick-args/-/process-nextick-args-2.0.1.tgz", - "integrity": "sha512-3ouUOpQhtgrbOa17J7+uxOTpITYWaGP7/AhoR3+A+/1e9skrzelGi/dXzEYyvbxubEF6Wn2ypscTKiKJFFn1ag==", - "license": "MIT" - }, "node_modules/proxy-addr": { "version": "2.0.7", "resolved": "https://registry.npmjs.org/proxy-addr/-/proxy-addr-2.0.7.tgz", @@ -3432,36 +2799,6 @@ "node": ">= 6" } }, - "node_modules/readdir-glob": { - "version": "1.1.3", - "resolved": "https://registry.npmjs.org/readdir-glob/-/readdir-glob-1.1.3.tgz", - "integrity": "sha512-v05I2k7xN8zXvPD9N+z/uhXPaj0sUFCe2rcWZIpBsqxfP7xXFQ0tipAd/wjj1YxWyWtUS5IDJpOG82JKt2EAVA==", - "license": "Apache-2.0", - "dependencies": { - "minimatch": "^5.1.0" - } - }, - "node_modules/readdir-glob/node_modules/brace-expansion": { - "version": "2.1.7", - "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.1.7.tgz", - "integrity": "sha512-uZbew1NqdmPDTMJ8ah1y+b+9QEJrfkXFk3RcTQw3X0jW/xRUvFKsg1CfQdSYGdTbXZWExtU3J3ccxtnfw1Fi0g==", - "license": "MIT", - "dependencies": { - "balanced-match": "^1.0.0" - } - }, - "node_modules/readdir-glob/node_modules/minimatch": { - "version": "5.1.9", - "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-5.1.9.tgz", - "integrity": "sha512-7o1wEA2RyMP7Iu7GNba9vc0RWWGACJOCZBJX2GJWip0ikV+wcOsgVuY9uE8CPiyQhkGFSlhuSkZPavN7u1c2Fw==", - "license": "ISC", - "dependencies": { - "brace-expansion": "^2.0.1" - }, - "engines": { - "node": ">=10" - } - }, "node_modules/resolve-pkg-maps": { "version": "1.0.0", "resolved": "https://registry.npmjs.org/resolve-pkg-maps/-/resolve-pkg-maps-1.0.0.tgz", @@ -3471,19 +2808,6 @@ "url": "https://github.com/privatenumber/resolve-pkg-maps?sponsor=1" } }, - "node_modules/rimraf": { - "version": "2.7.1", - "resolved": "https://registry.npmjs.org/rimraf/-/rimraf-2.7.1.tgz", - "integrity": "sha512-uWjbaKIK3T1OSVptzX7Nl6PvQ3qAGtKEtVRjRuazjfL3Bx5eI409VZSqgND+4UNnmzLVdPj9FqFJNPqBZFve4w==", - "deprecated": "Rimraf versions prior to v4 are no longer supported", - "license": "ISC", - "dependencies": { - "glob": "^7.1.3" - }, - "bin": { - "rimraf": "bin.js" - } - }, "node_modules/router": { "version": "2.2.0", "resolved": "https://registry.npmjs.org/router/-/router-2.2.0.tgz", @@ -3523,18 +2847,6 @@ "resolved": "https://registry.npmjs.org/safer-buffer/-/safer-buffer-2.1.2.tgz", "integrity": "sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg==" }, - "node_modules/saxes": { - "version": "5.0.1", - "resolved": "https://registry.npmjs.org/saxes/-/saxes-5.0.1.tgz", - "integrity": "sha512-5LBh1Tls8c9xgGjw3QrMwETmTMVk0oFgvrFSvWx62llR2hcEInrKNZ2GZCCuuy2lvWrdl5jhbpeqc5hRYKFOcw==", - "license": "ISC", - "dependencies": { - "xmlchars": "^2.2.0" - }, - "engines": { - "node": ">=10" - } - }, "node_modules/scheduler": { "version": "0.27.0", "resolved": "https://registry.npmjs.org/scheduler/-/scheduler-0.27.0.tgz", @@ -3594,12 +2906,6 @@ "url": "https://opencollective.com/express" } }, - "node_modules/setimmediate": { - "version": "1.0.5", - "resolved": "https://registry.npmjs.org/setimmediate/-/setimmediate-1.0.5.tgz", - "integrity": "sha512-MATJdZp8sLqDl/68LfQmbP8zKPLQNV6BIZoIgrscFDQ+RsvK/BxeDQOgyxKKoh0y/8h3BqVFnCqQ/gd+reiIXA==", - "license": "MIT" - }, "node_modules/setprototypeof": { "version": "1.2.0", "resolved": "https://registry.npmjs.org/setprototypeof/-/setprototypeof-1.2.0.tgz", @@ -3859,15 +3165,6 @@ "node": ">=6" } }, - "node_modules/tmp": { - "version": "0.2.7", - "resolved": "https://registry.npmjs.org/tmp/-/tmp-0.2.7.tgz", - "integrity": "sha512-e0votIpp4Uo2AJYSzVHV6xCcawuiez3DzqDAbrTc3YxBkplN6e+dM13ZeIcZnDg/QpSuU2zfZ3rzwY8ukEnaXw==", - "license": "MIT", - "engines": { - "node": ">=14.14" - } - }, "node_modules/toidentifier": { "version": "1.0.1", "resolved": "https://registry.npmjs.org/toidentifier/-/toidentifier-1.0.1.tgz", @@ -3876,15 +3173,6 @@ "node": ">=0.6" } }, - "node_modules/traverse": { - "version": "0.3.9", - "resolved": "https://registry.npmjs.org/traverse/-/traverse-0.3.9.tgz", - "integrity": "sha512-iawgk0hLP3SxGKDfnDJf8wTz4p2qImnyihM5Hh/sGvQ3K37dPi/w8sRhdNIxYA1TwFwc5mDhIJq+O0RsvXBKdQ==", - "license": "MIT/X11", - "engines": { - "node": "*" - } - }, "node_modules/tslib": { "version": "2.8.1", "resolved": "https://registry.npmjs.org/tslib/-/tslib-2.8.1.tgz", @@ -4418,69 +3706,11 @@ "node": ">= 0.8" } }, - "node_modules/unzipper": { - "version": "0.10.14", - "resolved": "https://registry.npmjs.org/unzipper/-/unzipper-0.10.14.tgz", - "integrity": "sha512-ti4wZj+0bQTiX2KmKWuwj7lhV+2n//uXEotUmGuQqrbVZSEGFMbI68+c6JCQ8aAmUWYvtHEz2A8K6wXvueR/6g==", - "license": "MIT", - "dependencies": { - "big-integer": "^1.6.17", - "binary": "~0.3.0", - "bluebird": "~3.4.1", - "buffer-indexof-polyfill": "~1.0.0", - "duplexer2": "~0.1.4", - "fstream": "^1.0.12", - "graceful-fs": "^4.2.2", - "listenercount": "~1.0.1", - "readable-stream": "~2.3.6", - "setimmediate": "~1.0.4" - } - }, - "node_modules/unzipper/node_modules/readable-stream": { - "version": "2.3.8", - "resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-2.3.8.tgz", - "integrity": "sha512-8p0AUk4XODgIewSi0l8Epjs+EVnWiK7NoDIEGU0HhE7+ZyY8D1IMY7odu5lRrFXGg71L15KG8QrPmum45RTtdA==", - "license": "MIT", - "dependencies": { - "core-util-is": "~1.0.0", - "inherits": "~2.0.3", - "isarray": "~1.0.0", - "process-nextick-args": "~2.0.0", - "safe-buffer": "~5.1.1", - "string_decoder": "~1.1.1", - "util-deprecate": "~1.0.1" - } - }, - "node_modules/unzipper/node_modules/safe-buffer": { - "version": "5.1.2", - "resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.1.2.tgz", - "integrity": "sha512-Gd2UZBJDkXlY7GbJxfsE8/nvKkUEU1G38c1siN6QP6a9PT9MmHB8GnpscSmMJSoF8LOIrt8ud/wPtojys4G6+g==", - "license": "MIT" - }, - "node_modules/unzipper/node_modules/string_decoder": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/string_decoder/-/string_decoder-1.1.1.tgz", - "integrity": "sha512-n/ShnvDi6FHbbVfviro+WojiFzv+s8MPMHBczVePfUpDJLwoLT0ht1l4YwBCbi8pJAveEEdnkHyPyTP/mzRfwg==", - "license": "MIT", - "dependencies": { - "safe-buffer": "~5.1.0" - } - }, "node_modules/util-deprecate": { "version": "1.0.2", "resolved": "https://registry.npmjs.org/util-deprecate/-/util-deprecate-1.0.2.tgz", "integrity": "sha512-EPD5q1uXyFxJpCrLnCc1nHnq3gOa6DZBocAIiI2TaSCA7VCJ1UJDMagCzIkXNsUYfD1daK//LTEQ8xiIbrHtcw==" }, - "node_modules/uuid": { - "version": "8.3.2", - "resolved": "https://registry.npmjs.org/uuid/-/uuid-8.3.2.tgz", - "integrity": "sha512-+NYs2QeMWy+GWFOEm9xnn6HCDp0l7QBD7ml8zLUmJ+93Q5NF0NocErnwkTkXVFNiX3/fpC6afS8Dhb/gz7R7eg==", - "deprecated": "uuid@10 and below is no longer supported. For ESM codebases, update to uuid@latest. For CommonJS codebases, use uuid@11 (but be aware this version will likely be deprecated in 2028).", - "license": "MIT", - "bin": { - "uuid": "dist/bin/uuid" - } - }, "node_modules/vary": { "version": "1.1.2", "resolved": "https://registry.npmjs.org/vary/-/vary-1.1.2.tgz", @@ -4494,47 +3724,6 @@ "resolved": "https://registry.npmjs.org/wrappy/-/wrappy-1.0.2.tgz", "integrity": "sha512-l4Sp/DRseor9wL6EvV2+TuQn63dMkPjZ/sp9XkghTEbV9KlPS1xUsZ3u7/IQO4wxtcFB4bgpQPRcR3QCvezPcQ==" }, - "node_modules/xmlchars": { - "version": "2.2.0", - "resolved": "https://registry.npmjs.org/xmlchars/-/xmlchars-2.2.0.tgz", - "integrity": "sha512-JZnDKK8B0RCDw84FNdDAIpZK+JuJw+s7Lz8nksI7SIuU3UXJJslUthsi+uWBUYOwPFwW7W7PRLRfUKpxjtjFCw==", - "license": "MIT" - }, - "node_modules/zip-stream": { - "version": "4.1.1", - "resolved": "https://registry.npmjs.org/zip-stream/-/zip-stream-4.1.1.tgz", - "integrity": "sha512-9qv4rlDiopXg4E69k+vMHjNN63YFMe9sZMrdlvKnCjlCRWeCBswPPMPUfx+ipsAWq1LXHe70RcbaHdJJpS6hyQ==", - "license": "MIT", - "dependencies": { - "archiver-utils": "^3.0.4", - "compress-commons": "^4.1.2", - "readable-stream": "^3.6.0" - }, - "engines": { - "node": ">= 10" - } - }, - "node_modules/zip-stream/node_modules/archiver-utils": { - "version": "3.0.4", - "resolved": "https://registry.npmjs.org/archiver-utils/-/archiver-utils-3.0.4.tgz", - "integrity": "sha512-KVgf4XQVrTjhyWmx6cte4RxonPLR9onExufI1jhvw/MQ4BB6IsZD5gT8Lq+u/+pRkWna/6JoHpiQioaqFP5Rzw==", - "license": "MIT", - "dependencies": { - "glob": "^7.2.3", - "graceful-fs": "^4.2.0", - "lazystream": "^1.0.0", - "lodash.defaults": "^4.2.0", - "lodash.difference": "^4.5.0", - "lodash.flatten": "^4.4.0", - "lodash.isplainobject": "^4.0.6", - "lodash.union": "^4.6.0", - "normalize-path": "^3.0.0", - "readable-stream": "^3.6.0" - }, - "engines": { - "node": ">= 10" - } - }, "node_modules/zod": { "version": "4.4.1", "resolved": "https://registry.npmjs.org/zod/-/zod-4.4.1.tgz", diff --git a/package.json b/package.json index 17837f1..414eb53 100644 --- a/package.json +++ b/package.json @@ -24,10 +24,10 @@ "test": "node scripts/run-tests.mjs", "test:watch": "node scripts/run-tests.mjs --watch", "db:generate": "drizzle-kit generate", - "db:migrate": "node scripts/run-migrations.js", + "db:migrate": "drizzle-kit migrate", "db:backup": "tsx scripts/db-backup.ts", "db:verify:circuit-schema": "node scripts/db-verify-circuit-schema.js", - "revit:verify-reference": "tsx scripts/verify-revit-reference-xlsx.ts" + "revit:verify-reference": "tsx scripts/verify-revit-reference-csv.ts" }, "keywords": [], "author": "", @@ -36,7 +36,6 @@ "better-sqlite3": "^12.9.0", "bootstrap": "^5.3.8", "drizzle-orm": "^0.45.2", - "exceljs": "^4.4.0", "express": "^5.2.1", "lucide-react": "^1.14.0", "next": "^16.2.4", diff --git a/scripts/run-migrations.js b/scripts/run-migrations.js index 3a6fc84..ebbed8a 100644 --- a/scripts/run-migrations.js +++ b/scripts/run-migrations.js @@ -4,65 +4,13 @@ const Database = require('better-sqlite3'); const fs = require('node:fs'); const path = require('node:path'); -const dataDir = path.resolve( - process.env.LEISTUNGSBILANZ_DATA_DIR || 'data' -); +const dataDir = path.resolve('data'); if (!fs.existsSync(dataDir)) fs.mkdirSync(dataDir, { recursive: true }); -const databasePath = path.join(dataDir, 'leistungsbilanz.db'); +const sqlite = new Database(path.join(dataDir, 'leistungsbilanz.db')); +const db = drizzle(sqlite); -async function run() { - const sqlite = new Database(databasePath); - try { - if (requiresLinearXlsxBackup(sqlite)) { - const backupDir = path.join(dataDir, 'backups'); - fs.mkdirSync(backupDir, { recursive: true }); - const timestamp = new Date().toISOString().replace(/[:.]/g, '-'); - const backupPath = path.join( - backupDir, - `leistungsbilanz-before-linear-xlsx-${timestamp}.db` - ); - await sqlite.backup(backupPath); - verifyBackup(backupPath); - console.log(`Verified pre-migration backup created: ${backupPath}`); - } +migrate(db, { migrationsFolder: path.resolve('src/db/migrations') }); +sqlite.close(); - migrate(drizzle(sqlite), { - migrationsFolder: path.resolve('src/db/migrations'), - }); - } finally { - sqlite.close(); - } - console.log('Migrations applied'); -} - -function requiresLinearXlsxBackup(sqlite) { - const tables = new Set( - sqlite.prepare("SELECT name FROM sqlite_master WHERE type = 'table'") - .all() - .map((row) => row.name) - ); - return tables.has('external_csv_configurations') && - !tables.has('external_model_configurations'); -} - -function verifyBackup(backupPath) { - const backup = new Database(backupPath, { readonly: true, fileMustExist: true }); - try { - const integrity = backup.pragma('integrity_check', { simple: true }); - const foreignKeyViolations = backup.pragma('foreign_key_check'); - if (integrity !== 'ok' || foreignKeyViolations.length > 0) { - throw new Error( - `Pre-migration backup verification failed: integrity=${integrity}, ` + - `foreign-key violations=${foreignKeyViolations.length}` - ); - } - } finally { - backup.close(); - } -} - -run().catch((error) => { - console.error('Migration failed:', error instanceof Error ? error.message : error); - process.exit(1); -}); +console.log('Migrations applied'); diff --git a/scripts/verify-revit-reference-csv.ts b/scripts/verify-revit-reference-csv.ts new file mode 100644 index 0000000..07d605b --- /dev/null +++ b/scripts/verify-revit-reference-csv.ts @@ -0,0 +1,81 @@ +import assert from "node:assert/strict"; +import { readFileSync } from "node:fs"; +import { resolve } from "node:path"; +import { createHash } from "node:crypto"; +import { createDefaultExternalCsvConfiguration } from "../src/external-model/csv/external-csv-contracts.js"; +import { + parseExternalCsv, + serializeExternalCsv, +} from "../src/external-model/csv/external-csv-transport.js"; +import { createExternalCsvPreview } from "../src/external-model/application/external-csv-preview.js"; + +const filePath = resolve( + process.argv[2] ?? "docs/spec/ELT Stromkreisnummernvergabe-Check_DIV.csv" +); +const source = readFileSync(filePath); +const configuration = createDefaultExternalCsvConfiguration({ + ifcGuid: "IfcGUID", + roomNumber: "MEP-Raum: Nummer", + roomName: "MEP-Raum: Name", + familyAndType: "Familie und Typ", + selectionMarker: "CAx_Auswahlkenner", + circuitIdentifier: "kbp_Stromkreisnummer", + power: "kbp-E-Elektrische Leistung", + quantity: null, +}); +configuration.additionalSourceMappings = [ + { sourceColumn: "CAx_Anmerkung", targetField: "sourceRemark" }, + { sourceColumn: "kbp-E-Spannung", targetField: "sourceVoltage" }, + { sourceColumn: "kbp-E-Stromstärke", targetField: "sourceCurrent" }, + { sourceColumn: "kbp-E-Versorgung von ELT", targetField: "sourceElectricalSupply" }, + { sourceColumn: "kbp-E-Versorgung von MSR/GLT", targetField: "sourceControlSupply" }, +]; + +const document = parseExternalCsv(source, configuration); +const counts = Object.fromEntries( + ["metadata", "header", "passthrough", "object", "suspect-object"].map( + (classification) => [ + classification, + document.rows.filter((row) => row.classification === classification).length, + ] + ) +); +const nonEmptyPassthroughRows = document.rows.filter( + (row) => + row.classification === "passthrough" && + row.cells.some((cell) => cell.value !== "") +).length; +const serialized = serializeExternalCsv(document); +const preview = createExternalCsvPreview({ + fileName: filePath, + bytes: source, + configuration, +}); + +assert.equal(counts.object, 897, "Expected 897 object rows."); +assert.equal(preview.objectCount, 897, "Expected 897 preview objects."); +assert.equal(nonEmptyPassthroughRows, 211, "Expected 211 non-empty passthrough rows."); +assert.equal(counts["suspect-object"], 0, "Expected no suspect object rows."); +assert.equal( + Buffer.compare(Buffer.from(serialized), source), + 0, + "Expected a byte-identical CSV round-trip." +); + +const sha256 = createHash("sha256").update(source).digest("hex"); +process.stdout.write( + `${JSON.stringify( + { + file: filePath, + bytes: source.length, + sha256, + dialect: document.dialect, + rows: counts, + nonEmptyPassthroughRows, + roundTripByteIdentical: true, + previewObjectCount: preview.objectCount, + }, + null, + 2 + )}\n` +); diff --git a/scripts/verify-revit-reference-xlsx.ts b/scripts/verify-revit-reference-xlsx.ts deleted file mode 100644 index ed568d4..0000000 --- a/scripts/verify-revit-reference-xlsx.ts +++ /dev/null @@ -1,162 +0,0 @@ -import assert from "node:assert/strict"; -import { createHash } from "node:crypto"; -import { mkdirSync, readFileSync, writeFileSync } from "node:fs"; -import { dirname, resolve } from "node:path"; -import ExcelJS from "exceljs"; -import { - createDefaultExternalXlsxTransportConfiguration, - type ExternalXlsxScalar, -} from "../src/external-model/xlsx/external-xlsx-contracts.js"; -import { - createExternalXlsxReturn, - parseExternalXlsx, -} from "../src/external-model/xlsx/external-xlsx-transport.js"; - -async function main() { -const inputPath = resolve( - process.argv[2] ?? "docs/spec/kbp-Stromkreis.xlsx" -); -const outputPath = resolve( - process.argv[3] ?? "data/revit-reference/kbp-Stromkreis-R2-Rueckgabe.xlsx" -); -assert.notEqual( - inputPath, - outputPath, - "Eingabe- und Ausgabedatei müssen verschieden sein." -); - -const source = readFileSync(inputPath); -const configuration = createDefaultExternalXlsxTransportConfiguration(); -const document = await parseExternalXlsx({ - fileName: inputPath, - bytes: source, - configuration, -}); -const objectRows = document.rows.filter((row) => row.classification === "object"); -const suspectRows = document.rows.filter( - (row) => row.classification === "suspect-object" -); -const worksharingIdColumn = document.columns.find( - (column) => column.header === configuration.columns.worksharingId -)?.columnNumber; -assert.ok(worksharingIdColumn, "Worksharing-ID-Spalte wurde nicht aufgelöst."); - -assert.equal(objectRows.length, 487, "Es werden 487 Objektzeilen erwartet."); -assert.equal(suspectRows.length, 0, "Es werden keine verdächtigen Zeilen erwartet."); -assert.equal( - document.columns.filter((column) => column.comment !== null).length, - 14, - "Es werden 14 Kopfzeilenkommentare erwartet." -); -assert.equal( - document.issues.filter((issue) => issue.code === "duplicate-ifc-guid").length, - 0, - "Die Musterdatei darf keine exakten IfcGUID-Duplikate enthalten." -); - -const testValues = [ - { - circuitCombined: "UV_R2_TEST-2F1", - electricalPowerW: 111, - voltageV: 230, - currentA: 0.48, - }, - { - circuitCombined: "UV_R2_TEST-2F2", - electricalPowerW: 222, - voltageV: 230, - currentA: 0.97, - }, - { - circuitCombined: "UV_R2_TEST-3F1", - electricalPowerW: 333, - voltageV: 400, - currentA: 0.48, - }, -] satisfies Record[]; - -const updates = testValues.map((values, index) => { - const value = objectRows[index]?.cells[worksharingIdColumn - 1]?.value; - if (typeof value !== "string") { - throw new Error("Worksharing-ID muss Text sein."); - } - return { worksharingId: value, values }; -}); -const result = await createExternalXlsxReturn({ - fileName: inputPath, - bytes: source, - configuration, - updates, -}); -assert.equal(result.exportedObjectCount, 487); -mkdirSync(dirname(outputPath), { recursive: true }); -writeFileSync(outputPath, result.bytes); - -const outputDocument = await parseExternalXlsx({ - fileName: outputPath, - bytes: result.bytes, - configuration, -}); -assert.equal( - outputDocument.rows.filter((row) => row.classification === "object").length, - 487 -); -assert.equal( - outputDocument.rows.some((row) => row.classification !== "object"), - false, - "Die Rückgabedatei darf keine Summen- oder Hinweiszeilen enthalten." -); -assert.equal(outputDocument.sheetName, document.sheetName); -assert.deepEqual( - outputDocument.columns, - document.columns, - "Kopfzeilen, Kommentare und Spaltenbreiten müssen erhalten bleiben." -); -assert.deepEqual( - outputDocument.rows.slice(updates.length).map((row) => row.cells), - objectRows.slice(updates.length).map((row) => row.cells), - "Nicht geänderte Objektzellen müssen Wert, Typ und Zahlenformat behalten." -); -const outputWorkbook = new ExcelJS.Workbook(); -await outputWorkbook.xlsx.load(result.bytes as never); -const commentedCells: string[] = []; -outputWorkbook.worksheets[0].eachRow({ includeEmpty: true }, (row) => { - row.eachCell({ includeEmpty: true }, (cell) => { - if (cell.note !== undefined) commentedCells.push(cell.address); - }); -}); -assert.equal( - commentedCells.length, - 14, - "Nur die 14 Kopfzellen dürfen Kommentare enthalten." -); -assert.equal( - commentedCells.every((address) => address.endsWith("1")), - true, - "Datenzellen dürfen keine Kommentare enthalten." -); - -process.stdout.write( - `${JSON.stringify( - { - input: inputPath, - output: outputPath, - inputBytes: source.length, - outputBytes: result.bytes.length, - inputSha256: createHash("sha256").update(source).digest("hex"), - outputSha256: createHash("sha256").update(result.bytes).digest("hex"), - sheetName: document.sheetName, - objectCount: objectRows.length, - headerCommentCount: document.columns.filter( - (column) => column.comment !== null - ).length, - exactDuplicateIfcGuidCount: 0, - changedObjectCount: updates.length, - }, - null, - 2 - )}\n` -); -} - -void main(); diff --git a/src/app/projects/[projectId]/page.tsx b/src/app/projects/[projectId]/page.tsx index 5eb864e..ec99d54 100644 --- a/src/app/projects/[projectId]/page.tsx +++ b/src/app/projects/[projectId]/page.tsx @@ -5,7 +5,7 @@ import { useParams } from "next/navigation"; import { FormEvent, useEffect, useMemo, useState } from "react"; import { ArrowLeft, - FileSpreadsheet, + FileUp, Library, Link2, ListTree, @@ -51,6 +51,7 @@ import { copyProjectDeviceToGlobal, createDistributionBoard, createProjectDevice, + createRoom, deleteProjectDevice, deleteDistributionBoard, disconnectProjectDeviceRows, @@ -82,6 +83,7 @@ import type { BuildingDto, CircuitListDto, CircuitTreeResponseDto, + CreateRoomInput, CreateProjectDeviceInput, DistributionBoardDto, FloorDto, @@ -113,6 +115,7 @@ import { } from "../../../frontend/components/project-settings-modal"; import { FormModal } from "../../../frontend/components/form-modal"; import { ProjectDeviceModal } from "../../../frontend/components/project-device-modal"; +import { RevitCsvModal } from "../../../frontend/components/revit-csv-modal"; import { FloorSelectOptions } from "../../../frontend/components/floor-select-options"; const projectDeviceSyncFieldLabels: Record = { @@ -197,6 +200,7 @@ export default function ProjectDetailPage() { }) ); const [isProjectSettingsOpen, setIsProjectSettingsOpen] = useState(false); + const [isRevitCsvOpen, setIsRevitCsvOpen] = useState(false); const [structureModal, setStructureModal] = useState<"board" | null>(null); const [isProjectDeviceModalOpen, setIsProjectDeviceModalOpen] = useState(false); @@ -675,6 +679,22 @@ export default function ProjectDetailPage() { } } + async function handleCreateRevitRoom(input: CreateRoomInput) { + if (!projectId || !project) throw new Error("Projekt ist nicht geladen."); + const result = await createRoom(projectId, input, project.currentRevision); + setRooms((current) => [...current, result.room]); + applyProjectRevision(result.history.currentRevision); + return result; + } + + async function handleCreateRevitProjectDevice(input: CreateProjectDeviceInput) { + if (!projectId || !project) throw new Error("Projekt ist nicht geladen."); + const result = await createProjectDevice(projectId, input, project.currentRevision); + setProjectDevices((current) => [...current, result.projectDevice]); + applyProjectRevision(result.history.currentRevision); + return result; + } + async function handleCopyBoard() { if ( !projectId || @@ -977,13 +997,15 @@ export default function ProjectDetailPage() {