Create clean release database baseline

docs/current-architecture.md

@@ -9,10 +9,8 @@ Der unterstützte Editor ist Circuit-First:
 Ein Stromkreis ist nicht dasselbe wie eine Gerätezeile. BMK, Schutz- und Kabeldaten
 gehören zum Stromkreis; Last-, Raum- und Kategoriedaten gehören zur Gerätezeile.
 
-Die frühere Consumer-Oberfläche und ihre API sind entfernt. Die Tabelle
-`consumers` sowie Mappings und Reports bleiben ausschließlich erhalten, damit
-ältere Datenbanken über den expliziten Upgrade-Befehl migriert und geprüft werden
-können.
+Die frühere Consumer-Oberfläche, ihre API, Tabellen und Upgrade-Werkzeuge sind
+entfernt. Neue Funktionen bauen ausschließlich auf dem Circuit-First-Modell auf.
 
 ## Laufzeit
 
@@ -130,8 +128,8 @@ Datenbank-Backups gespeichert. `POST /api/projects/:projectId/snapshots`
 erzeugt bei passender erwarteter Revision transaktional einen vollständigen,
 schema-versionierten Projektzustand mit SHA-256-Prüfwert. Enthalten sind
 Projekteinstellungen, Verteiler, Stromkreislisten, Bereiche, Stromkreise und
-Gerätezeilen sowie Projektgeräte, Geschosse und Räume. Globale Geräte,
-Legacy-Consumer und Migrationsberichte sind nicht Teil des Projekt-Snapshots.
+Gerätezeilen sowie Projektgeräte, Geschosse und Räume. Globale Geräte sind nicht
+Teil des Projekt-Snapshots.
 Create/List verändern weder Projektrevision noch Undo-/Redo-Stapel.
 `kind` unterscheidet benannte und automatische Stände. Die zentrale
 Revisionspersistenz erzeugt nach jeweils 25 weiteren Projektänderungen
@@ -144,9 +142,7 @@ Prüfsumme, erwartete Revision und den unmittelbar zuvor gelesenen
 Projektzustand. Der Restore ersetzt alle unterstützten Projektdaten in einer
 Transaktion und schreibt dabei eine neue Revision mit Quelle `restore` sowie
 ein vollständiges inverses Kommando. Undo und Redo können deshalb auch einen
-Restore nach einem Neustart exakt zurücknehmen oder wiederholen. Kompatible
-Upgrade-only-Verknüpfungen und Migrationsnachweise bleiben erhalten, obwohl sie
-nicht Bestandteil des logischen Snapshots sind.
+Restore nach einem Neustart exakt zurücknehmen oder wiederholen.
 Die Projektseite bindet diese APIs in einem einklappbaren Bereich
 „Versionen und Sicherungspunkte“ ein. Dort können Benutzer Sicherungspunkte
 benennen, jeden aufgeführten benannten oder automatischen Stand nach
@@ -246,8 +242,7 @@ Store leitet das inverse Kommando aus dem gespeicherten Projekt ab und schreibt
 Werte, Revision und Historienstapel gemeinsam. `PUT /api/projects/:projectId`
 verlangt deshalb `expectedRevision`, liefert Projekt plus aktualisierten
 Historienstand und besitzt keinen separaten direkten Settings-Schreibweg mehr.
-Kommando- und Snapshot-Versionen vor dieser Erweiterung bleiben les- und
-ausführbar; fehlende Metadaten werden dabei als `null` behandelt.
+Kommando- und Snapshot-Payloads müssen dem aktuellen Baseline-Schema entsprechen.
 Die Projektseite zeigt Verteilungen, Etagen und Räume als kompakte
 Bestandsübersichten; ihre versionierten Erstellwege öffnen beschriftete Modals
 statt dauerhafter Eingabezeilen. Projektgeräte werden als durchsuchbare,
@@ -264,8 +259,8 @@ rückgängig machbare Projektrevision. Der Modus `duplicate` ordnet Projekt-,
 Struktur-, Gruppen-, Verteilerkomponenten-, Raum-, Stromkreis- und
 Gerätezeilen-UUIDs sowie Schutzgeräte-Referenzen vollständig neu zu und legt
 die Kopie mit Revision `0` in einer Transaktion an. Upgrade-only-
-Consumer-Verweise werden nicht in die Kopie übernommen; fachliche Verknüpfungen
-innerhalb des unterstützten Laufzeitmodells bleiben erhalten. Die
+Fachliche Verknüpfungen innerhalb des unterstützten Laufzeitmodells bleiben
+erhalten. Die
 Projektübersicht verwendet dafür den separaten Collection-Endpunkt
 `POST /api/projects/import`, der ausschließlich eine neue Kopie anlegt und
 deshalb weder eine bestehende Projekt-ID noch `expectedRevision` annimmt. Das
@@ -283,8 +278,6 @@ Controller-Schreibweg ist entfernt. Verteilungen besitzen eine optionale
 Etagenreferenz sowie eine Netzart aus dem Projektkatalog. Anlage und
 nachträgliche Bearbeitung prüfen die Projektzugehörigkeit der Etage und die
 Freigabe der Netzart in den Projekteinstellungen.
-Gespeicherte Anlage-Commands der Schemas 1 und 2 bleiben mit ihren vier
-Legacy-Abschnitten und ohne nachträglich erfundene Komponenten ausführbar.
 Bereits befüllte Verteilungen werden über
 `distribution-board.insert-subtree` und `distribution-board.delete-subtree`
 als vollständiger Unterbaum kopiert beziehungsweise gelöscht. Der Snapshot
@@ -462,32 +455,30 @@ Kopieren in ein Projekt erzeugt ein eigenständiges Projektgerät.
 
 - SQLite ist die aktuell unterstützte Datenbank.
 - Fremdschlüssel werden für jeden Datenbankkontext aktiviert.
-- `npm run db:migrate` wendet Drizzle-Migrationen an.
+- `npm run db:migrate` richtet mit der einzelnen Migration `0000` das komplette
+  aktuelle Schema einer leeren Datenbank ein.
 - `npm run db:verify:circuit-schema` prüft erforderliche und entfernte Spalten.
 - `npm run db:backup` erzeugt ein konsistentes und verifiziertes Online-Backup.
-- `npm run typecheck:scripts` prüft alle TypeScript-Wartungs- und
-  Upgrade-Skripte mit ihren Anwendungspfaden, ohne Code zu erzeugen.
-- Angewendete Migrationen werden niemals nachträglich verändert.
-- `db:migrate:legacy-consumers` ist Upgrade-Werkzeug, kein Anwendungspfad.
-  Der fachliche Migrationsdienst kennt nur schmale Reader-/Store-Ports unter
-  `src/domain/ports`; konkrete SQLite-Repositories werden ausschließlich im
-  CLI-Skript zusammengesetzt.
+- `npm run typecheck:scripts` prüft die TypeScript-Wartungsskripte, ohne Code zu
+  erzeugen.
+- Die Baseline ersetzt alle vorigen Entwicklungsmigrationen. Datenbanken,
+  Snapshots und persistierte Commands aus Vor-Baseline-Ständen werden bewusst
+  nicht unterstützt. Ab der ersten veröffentlichten Version sind angewendete
+  Migrationen unveränderlich und Änderungen erfolgen additiv.
 - Allgemeine Circuit-, Gerätezeilen-, CircuitList- und DistributionBoard-
   Repositories stellen im Anwendungspfad nur noch benötigte Leseabfragen bereit.
-  Fachliche Schreibvorgänge liegen in den typisierten Command-Repositories;
-  Upgrade-Schreibvorgänge bleiben in expliziten Migrationsadaptern.
+  Fachliche Schreibvorgänge liegen in den typisierten Command-Repositories.
 - Die vollständige Verteilungs-Testfixture liegt unter
   `tests/support/distribution-board-fixture.ts` und ist kein exportierter
   Produktions-Schreibweg.
-- Migration `0024` bildet die additive relationale Grundlage für geschützte
-  Stromkreisgruppen und Verteilerkomponenten. Die drei bestehenden
-  Stromkreisabschnitte erhalten Kategorie und Gruppennummer 1. Separate
-  1:1-Tabellen halten künftig Stromkreis- und Komponenten-Schutzgeräte; die
-  bisherigen flachen Schutzfelder bleiben in dieser Übergangsphase unverändert.
+- Die Baseline bildet die relationale Grundlage für geschützte Stromkreisgruppen
+  und Verteilerkomponenten. Separate
+  1:1-Tabellen halten Stromkreis- und Komponenten-Schutzgeräte. Die früheren
+  flachen Stromkreis-Schutzfelder sind aus der Baseline entfernt.
   Ein triggergeführtes Register erzwingt bereits eine normalisierte,
   stromkreislistenweite BMK-Eindeutigkeit über Stromkreise und
   Verteilerkomponenten. Snapshot- und Transfer-Integration verwenden
-  Snapshot-Schema 7. Persistente Insert/Delete/Update-Commands für
+  Snapshot-Schema 1 der Baseline. Persistente Insert/Delete/Update-Commands für
   veränderliche Verteilerkomponenten, Gruppen einschließlich befüllter
   Unterbäume sowie vollständige Gruppensortierung sind integriert. Der Editor
   zeigt die geschützte Struktur an und bearbeitet veränderliche Gruppen- und