leistungsbilanz-ts/docs/spec/revit-csv-integration-requirements.md

# 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
<Verteilername beziehungsweise Verteiler-BMK><Stromkreis-BMK>
```

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.