Add editable project floors and rooms

docs/current-architecture.md

@@ -258,8 +258,8 @@ läuft über `project.restore-state` und ist dadurch eine atomare, dauerhaft
 rückgängig machbare Projektrevision. Der Modus `duplicate` ordnet Projekt-,
 Struktur-, Gruppen-, Verteilerkomponenten-, Raum-, Stromkreis- und
 Gerätezeilen-UUIDs sowie Schutzgeräte-Referenzen vollständig neu zu und legt
-die Kopie mit Revision `0` in einer Transaktion an. Upgrade-only-
-Fachliche Verknüpfungen innerhalb des unterstützten Laufzeitmodells bleiben
+die Kopie mit Revision `0` in einer Transaktion an. Fachliche Verknüpfungen
+innerhalb des unterstützten Laufzeitmodells bleiben
 erhalten. Die
 Projektübersicht verwendet dafür den separaten Collection-Endpunkt
 `POST /api/projects/import`, der ausschließlich eine neue Kopie anlegt und
@@ -414,34 +414,26 @@ wieder her.
 verteilerweiten Gleichzeitigkeitsfaktor gemeinsam und stellt alle Werte über
 dauerhaftes Undo/Redo wieder her. Der Faktor liegt zwischen `0` und `1` und
 ist für bestehende sowie neu angelegte Verteilungen standardmäßig `1`.
-Snapshot-Schema 6 und der portable Projekttransfer enthalten diesen Wert;
-Schema 5 und älter werden mit dem neutralen Faktor `1` hochgestuft.
-Snapshot-Schema 4 enthält bereits Etage und Netzart; Schema 1/2 sowie
-gespeicherte Version-1-Strukturcommands werden ohne erfundene Zuordnung
-hochgestuft. Snapshot-Schema 3 wird mit allen sechs Netzarten als
-Projektauswahl hochgestuft.
-Snapshot-Schema 7 ergänzt Gruppenkategorie und -nummer,
-Verteilerkomponenten sowie die getrennten 1:1-Schutzgerätedaten. Capture,
+Das aktuelle Baseline-Snapshot-Schema enthält den Gleichzeitigkeitsfaktor,
+Gruppenkategorie und -nummer, Verteilerkomponenten sowie die getrennten
+1:1-Schutzgerätedaten. Capture,
 benannte und automatische Snapshots, Wiederherstellung, Undo/Redo und beide
-JSON-Importmodi verwenden denselben vollständigen Zustand. Schema 6 und älter
-bleiben lesbar: Die drei bekannten Abschnittsschlüssel werden deterministisch
-Gruppe 1 zugeordnet, neue Komponenten- und Schutzgerätesammlungen bleiben leer
-und bestehende flache Schutzangaben unverändert erhalten.
-`project-floor.insert` und `project-room.insert` versionieren die Anlage von
-Geschossen und Räumen mit stabilen UUIDs. Die vollständigen Datensätze bilden
-jeweils die persistierte Inverse für Undo/Redo. Ein Geschoss wird durch Undo nur
+JSON-Importmodi verwenden denselben vollständigen Zustand. Vorherige
+Entwicklungsschemas werden nicht mehr eingelesen.
+Persistente Insert-, Update- und Delete-Commands versionieren Anlage,
+Bearbeitung und Löschung von Geschossen und Räumen mit stabilen UUIDs und
+exakten Vorher-/Nachher-Snapshots. Ein Geschoss wird nur
 entfernt, solange ihm weder ein Raum noch eine Verteilung zugeordnet wurde. Ein
-Raum wird nur entfernt,
-solange weder eine CircuitDeviceRow noch ein aufbewahrter Upgrade-Datensatz auf
-ihn verweist. Beide POST-Endpunkte verlangen `expectedRevision`, liefern den
-aktualisierten Historienstand und besitzen keinen direkten Create-Schreibweg
-mehr.
+Raum wird nur entfernt, solange keine CircuitDeviceRow auf ihn verweist. Alle
+Schreibendpunkte verlangen `expectedRevision` und liefern den aktualisierten
+Historienstand.
 
 ## Projektgeräte
 
-`ProjectDevice` verwendet ausschließlich die kanonischen Circuit-First-Felder:
-`phaseType`, `powerPerUnit`, `simultaneityFactor`, `cosPhi`, `remark` sowie
-optionale technische und kategorisierende Felder.
+Die Projektgerätekategorie `lighting`, `single_phase` oder `three_phase` ist die
+fachliche Klassifikation und Zielgruppe. `phaseType` ist keine separate
+Benutzereingabe, sondern wird daraus für Spannung, Verknüpfung und spätere
+Dimensionierung abgeleitet.
 
 Beim Einfügen entsteht eine verknüpfte `CircuitDeviceRow`. Der Anzeigename wird
 kopiert, aber nicht still synchronisiert. Spätere Änderungen am Projektgerät