Add atomic circuit update commands

docs/current-architecture.md

@@ -68,8 +68,12 @@ Tabellen. Ein getestetes Repository kann diese Historienmetadaten optimistisch
 und atomar fortschreiben. Vorwärts- und Rückwärtskommandos besitzen einen
 versionierten, JSON-sicheren Umschlag; Typ und Payload können dadurch nach
 einem Neustart verlustfrei rekonstruiert werden. Konkrete Fachkommandos und
-bestehende Fachoperationen sind aber noch nicht an diese Grenze angeschlossen;
-serverseitiges Undo/Redo ist daher noch nicht verfügbar.
+bestehende Fachoperationen sind aber noch nicht allgemein an diese Grenze
+angeschlossen. Für Circuit-Feldänderungen existiert ein erster interner
+Command-Store, der Fachänderung, automatisch erzeugtes inverses Kommando und
+Revision gemeinsam committen beziehungsweise zurückrollen kann. Er ist noch
+nicht über die API oder das Grid aktiviert; serverseitiges Undo/Redo ist daher
+noch nicht verfügbar.
 
 ## Projektgeräte
 

docs/project-history-and-external-model-architecture.md

@@ -149,11 +149,18 @@ Completed foundation:
   history records atomically
 - revision appends use an expected-revision compare-and-set and reject stale
   callers without writing partial history
+- a first internal `circuit.update` command validates project/list/section
+  ownership and equipment-identifier uniqueness inside its transaction
+- circuit updates derive their inverse from the persisted pre-command row and
+  commit the domain update, inverse command, change set and revision together
+- integration tests apply the generated inverse as a new `undo` revision and
+  verify rollback for stale revisions and late history failures
 
 Remaining constraints before implementing history:
 
-- define concrete project-scoped command unions and executors independently
-  from React callbacks; the generic versioned command envelope is complete
+- extend the concrete project-scoped command union and executors beyond the
+  internal `circuit.update` slice; the generic versioned command envelope is
+  complete
 - route domain writes and revision recording through one shared project
   transaction boundary; the current revision repository only commits history
   records and the counter together

docs/spec/07-implementation-phases-todo.md

@@ -372,6 +372,10 @@ Implemented foundation:
 - each revision has one separately stored logical change set
 - forward and inverse changes use complete, versioned JSON command envelopes
 - invalid or lossy command payloads are rejected before persistence
+- an internal typed `circuit.update` command generates its inverse from the
+  persisted pre-command state
+- circuit update, inverse command, change set and revision share one SQLite
+  transaction with stale-command and late-failure rollback coverage
 - revision metadata, change-set payloads and the project counter are committed
   in one SQLite transaction
 - a stale expected revision produces no history writes