Create clean release database baseline

AGENTS.md

@@ -33,17 +33,12 @@ It must support circuits, device rows, project devices, drag-and-drop restructur
 - General application repositories also require an explicit `AppDatabase`;
   `src/server/composition/application-repositories.ts` owns their runtime
   instances, and controllers never import the global SQLite client.
-- The upgrade-only legacy migration service follows the same dependency rule;
-  its concrete repositories are instantiated only in
-  `scripts/db-migrate-legacy-consumers.ts`.
 - General Circuit, CircuitDeviceRow, CircuitList and DistributionBoard
   repositories expose only active reads. Runtime writes belong in typed command
   repositories; direct integration fixtures belong under `tests/support`.
 
-The supported runtime model is Circuit-First. The former Consumer UI and API are
-removed. Retained `consumers` rows, migration mappings and reports are upgrade-only
-data accessed by `npm run db:migrate:legacy-consumers`; do not build application
-features on them.
+The supported runtime model is Circuit-First. The former Consumer UI, API,
+tables and upgrade tooling are removed; do not reintroduce them.
 
 See `docs/current-architecture.md` for the complete module and request flow.
 
@@ -255,9 +250,9 @@ not change the project revision or undo/redo stacks. Restoring a server-stored
 snapshot verifies its checksum and the current-state hash, replaces supported
 project data atomically and records a new `restore` revision with a complete
 inverse command. Restore can therefore be undone and redone after a restart.
-Snapshot schema version 7 also contains circuit-group identity,
+Baseline snapshot schema version 1 contains circuit-group identity,
 distribution-board components and the separate circuit/component protection
-records. Versions 1 through 6 remain readable. Portable duplicate imports
+records. Pre-baseline snapshots are unsupported. Portable duplicate imports
 remap component ids and protection-owner references together with the existing
 project graph.
 The central revision boundary creates an automatic logical snapshot after each
@@ -294,13 +289,11 @@ change in one revision and Undo/Redo restores them together; the project PUT
 route requires `expectedRevision`. The system catalog is `AV`, `SV`, `EV`,
 `USV`, `MSR`, `SiBe`; at least one must be enabled and a type used by a board
 cannot be disabled.
-Distribution-board setup uses `distribution-board.insert` schema version 3
+Distribution-board setup uses `distribution-board.insert` schema version 1
 with a complete stable snapshot of the board, circuit list, three default
 groups, main switch `-Q0` and surge protective device `-FA`. Its
 inverse removes only the same unchanged and still-empty structure; the POST
 route requires `expectedRevision` and returns the updated history state.
-Stored schema-version 1 and 2 setup commands remain executable with their four
-legacy sections and without invented components.
 Complete populated distribution-board copying and deletion use
 `distribution-board.insert-subtree` and `distribution-board.delete-subtree`.
 Their exact snapshots include the board, circuit list, groups, circuits,
@@ -389,7 +382,10 @@ Users must be able to override sizing suggestions.
 ## Persistence and Migration Rules
 
 - SQLite is the currently supported database.
-- Never edit an already applied migration.
+- Migration `0000` is the clean release baseline for empty databases.
+- Pre-baseline development databases, snapshots and stored commands are not
+  supported.
+- After the first release, never edit an already applied migration.
 - Back up an existing database before applying a new migration.
 - Inspect generated SQL; it must contain only the intended schema change.
 - Keep database backups separate from logical project snapshots.