Persist section renumbering
This commit is contained in:
@@ -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:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user