Add project revision foundation

docs/circuit-list-editor-api.md

@@ -5,6 +5,10 @@
 The circuit-first editor uses tree, circuit, row and project-device endpoints.
 All paths below are mounted below `/api`. There is no Consumer application API.
 
+Project responses from `GET /projects` and `GET /projects/:projectId` include
+`currentRevision`. It currently exposes the persisted revision foundation only;
+no public history, undo or redo endpoint exists yet.
+
 ## Circuit-First Endpoints
 
 ### Distribution Board Setup

docs/current-architecture.md

@@ -62,9 +62,12 @@ liegt über einen Host-Mount außerhalb des Containers.
 6. Das Frontend lädt den Circuit-Tree neu und stellt Auswahl beziehungsweise
    Viewport soweit möglich wieder her.
 
-Die React-Historie ist derzeit sitzungslokal. Persistente Projektrevisionen,
-optimistische Revisionsprüfungen und serverseitiges Undo/Redo sind die nächste
-Architekturphase.
+Die React-Historie ist derzeit sitzungslokal. Das Datenmodell besitzt bereits
+einen projektbezogenen Revisionszähler sowie getrennte Revision-/Change-Set-
+Tabellen. Ein getestetes Repository kann diese Historienmetadaten optimistisch
+und atomar fortschreiben. Bestehende Fachoperationen sind aber noch nicht an
+diese Grenze angeschlossen; serverseitiges Undo/Redo ist daher noch nicht
+verfügbar.
 
 ## Projektgeräte
 

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

@@ -137,11 +137,23 @@ Completed foundation:
 - database backup and independent restore verification are automated
 - the Consumer application path is removed and stable domain IDs are preserved
 - editor grid projection and safety rules are separated from React rendering
+- projects carry a monotonic `currentRevision` counter starting at zero
+- project revision metadata and versioned forward/inverse change-set payloads
+  have separate persistence entities
+- the SQLite revision repository advances the project counter and stores both
+  history records atomically
+- revision appends use an expected-revision compare-and-set and reject stale
+  callers without writing partial history
 
 Remaining constraints before implementing history:
 
 - model project-scoped command descriptions independently from React callbacks
-- route all future history-enabled mutations through one project revision boundary
+- route domain writes and revision recording through one shared project
+  transaction boundary; the current revision repository only commits history
+  records and the counter together
+- expose revision state and history eligibility through the application API
+- replace the session-local frontend command stack only after server-side
+  command execution and inverse application are complete
 - do not model IFCGUID as an overloaded circuit equipment identifier
 - keep database backup/restore checks separate from project history tests
 

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

@@ -354,14 +354,31 @@ Persist project-wide change history and restore points across reloads and applic
 
 Tasks:
 
-- add project-scoped monotonic revisions
-- record immutable server-side change sets with before/after state
-- add optimistic revision checks for stale commands
+- [x] add project-scoped monotonic revision storage
+- [x] add immutable append-only server-side change-set storage with versioned
+  forward/inverse payloads
+- [x] add optimistic checks when appending a revision
+- route domain writes and history records through one shared transaction
+- model serializable domain command descriptions outside React
 - persist undo/redo eligibility on the server
 - add named and periodic logical project snapshots
 - restore a historical snapshot as a new revision
 - keep database backups separate from logical history
 
+Implemented foundation:
+
+- projects start at revision zero and advance monotonically
+- each revision has one separately stored logical change set
+- revision metadata, change-set payloads and the project counter are committed
+  in one SQLite transaction
+- a stale expected revision produces no history writes
+- integration coverage verifies sequential revisions, stale-command rejection
+  and rollback after a forced late persistence failure
+
+The current editor operations are not connected to this history boundary yet.
+Undo/redo therefore remains session-local until the remaining tasks are
+implemented.
+
 Acceptance criteria:
 
 - undo/redo remains available after a page reload