From c96ba1cbaf9493221bef5a3e22cb8b7f97bcb675 Mon Sep 17 00:00:00 2001 From: Julian Appel Date: Sun, 2 Aug 2026 15:38:02 +0200 Subject: [PATCH] Added revit specs --- AGENTS.md | 57 +- .../revit-csv-integration-requirements.md | 1373 +++++++++++++++++ 2 files changed, 1429 insertions(+), 1 deletion(-) create mode 100644 docs/spec/revit-csv-integration-requirements.md diff --git a/AGENTS.md b/AGENTS.md index 8499827..c79c56c 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -363,6 +363,60 @@ Required operations: - edit equipment identifier - synchronization changes + +## Revit / CSV External Model Work + +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. + +Critical rules: + +- 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. + ## Future Sizing Do not implement full cable/protection sizing unless explicitly requested. @@ -400,7 +454,8 @@ Users must be able to override sizing suggestions. ## Current Deferred Work -- Revit/CSV/IFCGUID round-trip +- Revit/CSV/IFCGUID round-trip, 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/docs/spec/revit-csv-integration-requirements.md b/docs/spec/revit-csv-integration-requirements.md new file mode 100644 index 0000000..973c1a6 --- /dev/null +++ b/docs/spec/revit-csv-integration-requirements.md @@ -0,0 +1,1373 @@ +# Revit-CSV-Integration – Anforderungen und Implementierungsanweisung + +## 1. Status und Verbindlichkeit + +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; +- 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.