Add editable project floors and rooms

docs/circuit-list-editor-api.md

@@ -253,16 +253,27 @@ returns HTTP `409` with `PROJECT_HISTORY_OPERATION_UNAVAILABLE`.
   - body: `{ "name": "EG", "expectedRevision": 13 }`
   - executes `project-floor.insert` with a stable floor id
   - response: `{ "floor": { ... }, "revision": { ... }, "history": { ... } }`
+- `PUT /projects/:projectId/floors/:floorId`
+  - body: `{ "name": "1. OG", "expectedRevision": 14 }`
+  - executes an exact persistent floor update
+- `DELETE /projects/:projectId/floors/:floorId`
+  - body: `{ "expectedRevision": 15 }`
+  - rejects floors with assigned rooms or distribution boards
 - `POST /projects/:projectId/rooms`
   - body:
     `{ "floorId": "floor_1", "roomNumber": "001", "roomName": "Technik", "expectedRevision": 14 }`
   - executes `project-room.insert` with a stable room id; `floorId` is optional
     and must belong to the project when present
   - response: `{ "room": { ... }, "revision": { ... }, "history": { ... } }`
-- Persistent Undo removes only unchanged, unreferenced records. A floor with
-  assigned rooms or distribution boards and a room referenced by device rows
-  or retained upgrade data are rejected instead of silently clearing foreign
-  keys.
+- `PUT /projects/:projectId/rooms/:roomId`
+  - body:
+    `{ "floorId": null, "roomNumber": "101", "roomName": "Büro", "expectedRevision": 16 }`
+  - updates number, name and optional floor as one persistent command
+- `DELETE /projects/:projectId/rooms/:roomId`
+  - body: `{ "expectedRevision": 17 }`
+  - rejects rooms referenced by device rows
+- Persistent Undo/Redo restores exact previous and target records without
+  silently clearing foreign keys.
 - Stale revisions return `409 PROJECT_REVISION_CONFLICT`.
 
 ### Tree Endpoint

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