Add component structure commands

docs/current-architecture.md

@@ -285,6 +285,16 @@ nachträgliche Bearbeitung prüfen die Projektzugehörigkeit der Etage und die
 Freigabe der Netzart in den Projekteinstellungen.
 Gespeicherte Anlage-Commands der Schemas 1 und 2 bleiben mit ihren vier
 Legacy-Abschnitten und ohne nachträglich erfundene Komponenten ausführbar.
+`distribution-board-component.insert` und
+`distribution-board-component.delete` versionieren die Anlage und Entfernung
+veränderlicher Gruppen-Schutzgeräte und zusätzlicher Verteilergeräte. Der
+vollständige Snapshot enthält die stabile Komponenten-UUID und, für
+Gruppen-Schutzgeräte, die getrennte 1:1-Schutzgerätekonfiguration. Eigentum an
+Projekt, Stromkreisliste und Gruppe sowie der unveränderte Löschzustand werden
+innerhalb derselben Transaktion geprüft. Die festen Kopfkomponenten
+Hauptschalter und Überspannungsableiter sind von diesen allgemeinen Commands
+ausgeschlossen. API- und Editorintegration folgen in den nächsten
+Arbeitspaketen.
 `distribution-board.update` versioniert Etage, Netzart und den
 verteilerweiten Gleichzeitigkeitsfaktor gemeinsam und stellt alle Werte über
 dauerhaftes Undo/Redo wieder her. Der Faktor liegt zwischen `0` und `1` und
@@ -355,8 +365,9 @@ Kopieren in ein Projekt erzeugt ein eigenständiges Projektgerät.
   Ein triggergeführtes Register erzwingt bereits eine normalisierte,
   stromkreislistenweite BMK-Eindeutigkeit über Stromkreise und
   Verteilerkomponenten. Snapshot- und Transfer-Integration verwenden
-  Snapshot-Schema 7; Command- und UI-Integration folgen in den nächsten
-  abgegrenzten Arbeitspaketen.
+  Snapshot-Schema 7. Persistente Insert/Delete-Commands für veränderliche
+  Verteilerkomponenten sind integriert; weitere Command- und UI-Schritte
+  folgen in abgegrenzten Arbeitspaketen.
 
 PostgreSQL ist bewusst nicht implementiert. Die Domainregeln und
 Transaktionsgrenzen sollen portabel bleiben; Schema und Betriebsmodell benötigen

docs/spec/08-current-product-backlog.md

@@ -20,7 +20,10 @@ requirements and intended sequencing, not proof of implementation.
   mapping.
 - [x] Phase C1: versioned new-board command with three groups and fixed header
   components.
-- [ ] Phase C2: component and group CRUD/reorder commands.
+- [x] Phase C2a1: persistent insert/delete commands for mutable group
+  protection and auxiliary components.
+- [ ] Phase C2a2: component update and reorder commands.
+- [ ] Phase C2b: group CRUD and reorder commands.
 - [ ] Phase D: group numbering, moves and destructive operations.
 - [ ] Phase E: editor projection and editing.
 - [ ] Phase F: documentation and full GUI verification.

docs/spec/09-distribution-board-components-and-protection-groups.md

@@ -593,8 +593,9 @@ Acceptance:
 
 ### C. Persistent Commands and Board Defaults
 
-Status: In progress. New-board defaults C1 are complete; component and group
-management commands C2 are pending.
+Status: In progress. New-board defaults C1 and component insert/delete commands
+C2a1 are complete. Component update/reorder and group management remain
+pending.
 
 - extend `distribution-board.insert` with fixed components and three groups
 - implement component and group CRUD commands
@@ -612,6 +613,19 @@ Implemented in C1:
 - stored schema versions 1 and 2 retain four legacy sections and receive no
   invented components
 
+Implemented in C2a1:
+
+- `distribution-board-component.insert` and
+  `distribution-board-component.delete` persist complete component snapshots
+  with their optional one-to-one protection-device configuration
+- mutable group protection components validate their group ownership and
+  protection-device combination before writing
+- auxiliary components remain footer entries without protection-device data
+- fixed header roles are excluded from these general CRUD commands
+- deletion requires an exact unchanged snapshot; Undo/Redo restores the same
+  component UUID and a late revision/history failure rolls back the complete
+  write
+
 Acceptance:
 
 - new boards contain the agreed fixed structure