Add component persistence foundation

docs/spec/08-current-product-backlog.md

@@ -14,7 +14,10 @@ requirements and intended sequencing, not proof of implementation.
   component model in phased work packages.
 - [x] Phase A: central protection catalog, validation, defaults and pure grouped
   BMK rules.
-- [ ] Phase B: persistence and snapshot/transfer compatibility model.
+- [x] Phase B1: additive relational schema, group backfill, component/protection
+  tables and shared BMK uniqueness.
+- [ ] Phase B2: snapshot/transfer schema upgrade and deterministic compatibility
+  mapping.
 - [ ] Phase C: persistent commands and new-board defaults.
 - [ ] Phase D: group numbering, moves and destructive operations.
 - [ ] Phase E: editor projection and editing.

docs/spec/09-distribution-board-components-and-protection-groups.md

@@ -3,8 +3,9 @@
 ## Status
 
 This document defines the agreed target behavior for distribution-board
-components, protected circuit groups and circuit protection devices. It is a
-future specification, not proof of implementation.
+components, protected circuit groups and circuit protection devices. Phase A
+and the relational Phase-B1 foundation are implemented; later sections remain
+requirements and are not proof of runtime or editor support.
 
 Full rule-based protection and cable sizing is deliberately deferred. This
 phase establishes the structure and manually selected technical values that a
@@ -544,6 +545,9 @@ Acceptance:
 
 ### B. Persistence and Compatibility Model
 
+Status: In progress. Relational foundation B1 is complete; logical
+snapshot/transfer integration B2 is pending.
+
 - add group category and group number
 - add distribution-board component persistence
 - add one-to-one circuit protection persistence
@@ -552,6 +556,20 @@ Acceptance:
 - add snapshot/transfer schema upgrade
 - preserve existing identifiers and protection values
 
+Implemented in B1:
+
+- additive migration `0024` adds group identity to circuit sections and maps
+  the three established sections to group 1 without changing UUIDs
+- separate component and circuit/component protection tables preserve the
+  one-to-one ownership boundaries
+- a trigger-maintained circuit-list registry rejects normalized BMK collisions
+  across circuits and distribution-board components
+- the existing flat circuit protection fields remain untouched until their
+  deterministic snapshot/runtime transition is implemented
+- clean and populated pre-migration databases are covered by migration tests
+- newly created legacy-compatible board structures receive the same initial
+  group identity while their persisted command format remains unchanged
+
 Acceptance:
 
 - a current database migrates without data loss