Persist section renumbering

docs/circuit-list-editor-api.md

@@ -37,9 +37,8 @@ snapshots contain zero, one or multiple complete device rows. Move commands
 contain each row's expected and target circuit plus its exact expected and
 target sort order. This makes deletion and moves undoable without generating
 replacement identities or renumbering circuits. Existing Circuit and
-CircuitDeviceRow cell edits, standalone insert/delete actions and device-row
-moves and reorders in the editor consume these endpoints. The renumber UI path
-is still being migrated.
+CircuitDeviceRow cell edits, standalone insert/delete actions, device-row
+moves, reorders and explicit renumbering in the editor consume these endpoints.
 
 `circuit-device-row.move` targets existing circuits in the same circuit list.
 `circuit-device-row.move-with-new-circuit` atomically creates exactly one
@@ -176,32 +175,11 @@ Response sketch:
   - preview next identifier for section (`prefix + maxSuffix + 1`)
 
 Circuit and device-row field updates, standalone insertions/deletions, single
-or bulk device-row moves and circuit reorders are available only as the
-corresponding versioned commands through
+or bulk device-row moves, circuit reorders and explicit renumbering are
+available only as the corresponding versioned commands through
 `POST /projects/:projectId/commands`. There are no direct field-update PATCH,
-structure POST, move, reorder, Circuit DELETE or CircuitDeviceRow DELETE
-routes.
-
-### Renumber Section
-
-- `POST /circuit-sections/:sectionId/renumber`
-- Purpose: explicit renumbering by section prefix; never implicit on move/sort.
-
-### Safe Equipment Identifier Update
-
-- `PATCH /circuit-sections/:sectionId/equipment-identifiers`
-- Purpose: apply explicit per-circuit identifiers safely even with unique constraints.
-
-Request sketch:
-
-```json
-{
-  "identifiers": [
-    { "circuitId": "cir_1", "equipmentIdentifier": "-2F1" },
-    { "circuitId": "cir_2", "equipmentIdentifier": "-2F2" }
-  ]
-}
-```
+structure POST, move, reorder, renumber, identifier-restore, Circuit DELETE or
+CircuitDeviceRow DELETE routes.
 
 ## Removed Legacy Endpoints
 

docs/circuit-list-editor-interactions.md

@@ -129,8 +129,8 @@ undo/redo calls the project-wide server history. New entities receive stable
 UUIDs before insertion, and deletion undo restores those same ids. Device-row
 moves and circuit reorders also use persistent project commands. Applying a
 sorted view across multiple sections is atomic and occupies one history step.
-Renumbering still uses its direct API write and session-local inverse callback
-during the cutover.
+Explicit renumbering uses a collision-safe persistent project command and one
+project-history step.
 
 Covered operations include:
 
@@ -144,5 +144,3 @@ Covered operations include:
 Current limitations:
 
 - the visible editor stack is still session-local and is empty after reload
-- renumber editor actions are not connected to the persistent command boundary
-  yet

docs/circuit-list-editor-known-limitations.md

@@ -1,14 +1,12 @@
 # Circuit List Editor Known Limitations
 
-- Existing Circuit and CircuitDeviceRow cell edits plus standalone
-  insert/delete actions and CircuitDeviceRow moves use persistent project
-  commands and project-wide toolbar undo/redo. The editor's visible stack is
-  still session-local, is empty after reload and still contains the direct
-  renumber operation during the cutover. Circuit reorder is already persistent,
-  including atomic multi-section sorted-order application.
+- All currently supported Circuit and CircuitDeviceRow editor writes use
+  persistent project commands and project-wide toolbar undo/redo, including
+  moves, atomic multi-section reorders and explicit renumbering. The editor's
+  visible stack is still session-local and empty after reload.
 - Server-side project revisions and persistent undo/redo eligibility exist for
-  the command types documented in `circuit-list-editor-api.md`; complete editor
-  command coverage and history reconstruction are not complete.
+  the command types documented in `circuit-list-editor-api.md`; visible history
+  reconstruction is not complete.
 - Named logical project snapshots and restore are not implemented yet.
 - No Revit/CSV/IFCGUID import and export workflow is implemented yet.
 - Persistence currently targets local SQLite; PostgreSQL is an architectural option, not an implemented runtime.

docs/current-architecture.md

@@ -92,10 +92,10 @@ sowie eigenständiges Einfügen und Löschen verwendet das Grid bereits über di
 UUID vor dem Command; Löschen und Undo bewahren diese Identität. Der Tree liefert
 dazu `currentRevision`; Undo/Redo für diese Aktionen läuft über die projektweite
 Serverhistorie. Direkte Feld-PATCH-, Struktur-POST-, Move-, Circuit- und
-Gerätezeilen-DELETE-Endpunkte sind entfernt. Gerätezeilen-Moves und
-Stromkreis-Reorders im Grid verwenden die persistenten Kommandos bereits. Nur
-der Renumber-UI-Pfad verbleibt vorerst im sichtbaren sitzungslokalen Stack;
-nach einem Reload wird dieser noch nicht aus der Serverhistorie rekonstruiert.
+Gerätezeilen-DELETE-Endpunkte sind entfernt. Gerätezeilen-Moves,
+Stromkreis-Reorders und die explizite Neunummerierung im Grid verwenden die
+persistenten Kommandos. Der sichtbare Undo-/Redo-Stack wird nach einem Reload
+noch nicht aus der Serverhistorie rekonstruiert.
 `circuit-device-row.move` verschiebt oder sortiert eine oder mehrere Zeilen
 zwischen vorhandenen Stromkreisen derselben Liste. Erwartete und neue
 Stromkreis-/Sortierpositionen machen Forward und Inverse deterministisch;
@@ -115,6 +115,11 @@ bleiben unverändert. `circuit.renumber-section` bildet die getrennte,
 ausdrücklich ausgelöste Neunummerierung ab. Es speichert alle erwarteten und
 neuen BMKs des Abschnitts, löst Tauschkollisionen über temporäre Werte und
 ändert weder Sortierung noch Gerätezeilen.
+Die Bereichsaktion erzeugt die vollständigen erwarteten und neuen BMKs aus
+Präfix und aktueller Stromkreisreihenfolge und verwendet das persistente
+Kommando für Toolbar-Undo/Redo. Die früheren direkten Renumber- und
+Identifier-Restore-Endpunkte sowie ihr separater Transaktionsadapter sind
+entfernt.
 Drag-and-drop verwendet `circuit.reorder-section`. Die explizite Übernahme
 einer sortierten Ansicht verwendet `circuit.reorder-sections`, damit alle
 betroffenen Bereiche in einer Transaktion und als ein Undo-Schritt gespeichert

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

@@ -207,6 +207,9 @@ Completed foundation:
 - `circuit.renumber-section` is the separate explicit renumber operation; it
   stores every expected/target equipment identifier, uses collision-safe
   temporary values and restores the exact prior identifiers on undo
+- the editor's explicit renumber action uses this command; obsolete direct
+  renumber and identifier-restore routes plus their transaction adapter are
+  removed
 - `project-device.sync-rows` records synchronization, disconnect and reconnect
   as one atomic multi-row operation; complete expected/target sync snapshots
   protect local values, links and override metadata against silent stale writes
@@ -218,11 +221,9 @@ Completed foundation:
 
 Remaining constraints before completing persistent history:
 
-- route the remaining renumber editor writes through its existing typed
-  persistent command and remove the final direct mutation routes
 - reconstruct the visible frontend history state after reload; Circuit and
-  CircuitDeviceRow field/insert/delete actions plus ProjectDevice operations
-  already use persistent commands and project-wide undo
+  CircuitDeviceRow operations plus ProjectDevice operations already use
+  persistent commands and project-wide undo
 - extend project-scoped commands only when further project mutations are
   deliberately added to history; the generic versioned envelope is complete
 - do not model IFCGUID as an overloaded circuit equipment identifier

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

@@ -335,7 +335,7 @@ Implemented foundation:
 - a new circuit and all of its initial device rows use the same transaction store
 - device-row moves, reserve-state updates and optional target creation share one transaction
 - project-device synchronization, disconnect and reconnect use a separate injected transaction store
-- section renumbering and circuit reordering use a separate injected transaction store
+- section renumbering and circuit reordering use persistent command stores
 - circuit-device-row transaction tests cover both successful commits and forced SQLite rollbacks
 - project-device row synchronization has real multi-row SQLite commit and rollback coverage
 - BMK swaps and section reorder have real SQLite commit and rollback coverage
@@ -434,8 +434,9 @@ ProjectDevice CRUD, synchronization and disconnect on the project page and
 Circuit/CircuitDeviceRow field/insert/delete actions, device-row moves and
 circuit reorders in the circuit-list editor are connected to this history
 boundary. Applying sorted order across multiple sections is one atomic command.
-The renumber UI path is not yet connected; the editor's visible undo/redo stack
-therefore remains session-local and is not reconstructed after reload.
+Explicit renumbering is connected to the same persistent boundary. The
+editor's visible undo/redo stack remains session-local and is not reconstructed
+after reload.
 
 Acceptance criteria: