Remove obsolete repository writes

docs/current-architecture.md

@@ -231,6 +231,13 @@ Kopieren in ein Projekt erzeugt ein eigenständiges Projektgerät.
 - `npm run db:backup` erzeugt ein konsistentes und verifiziertes Online-Backup.
 - Angewendete Migrationen werden niemals nachträglich verändert.
 - `db:migrate:legacy-consumers` ist Upgrade-Werkzeug, kein Anwendungspfad.
+- 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.
+- Die vollständige Verteilungs-Testfixture liegt unter
+  `tests/support/distribution-board-fixture.ts` und ist kein exportierter
+  Produktions-Schreibweg.
 
 PostgreSQL ist bewusst nicht implementiert. Die Domainregeln und
 Transaktionsgrenzen sollen portabel bleiben; Schema und Betriebsmodell benötigen

docs/development-workflow.md

@@ -83,6 +83,9 @@ Invoke-WebRequest http://localhost:3000/health
 ```
 
 Bei sichtbaren Editoränderungen ist außerdem ein kurzer GUI-Test erforderlich.
+Testaufbau, der vollständige Projektstrukturen direkt einfügt, gehört nach
+`tests/support`. Produktions-Repositories dürfen nicht nur für Testfixtures
+erneut direkte Schreibmethoden erhalten.
 
 ## Migrationen
 

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

@@ -326,8 +326,9 @@ Implemented foundation:
 
 - database contexts can be created independently from the production singleton
 - SQLite foreign-key enforcement is enabled explicitly for every context
-- the distribution-board repository receives its database dependency explicitly
-- distribution-board setup has real in-memory SQLite commit and rollback coverage using production migrations
+- the read-only distribution-board repository receives its database dependency explicitly
+- distribution-board setup uses its persistent command repository with real
+  in-memory SQLite commit and rollback coverage using production migrations
 - database backups use SQLite's online backup API and include committed WAL data
 - every backup is opened independently and checked for integrity and foreign-key violations
 - an integration test restores the backup into a separate database and verifies its snapshot contents
@@ -342,6 +343,9 @@ Implemented foundation:
 - the legacy consumer migration receives its database dependency at the script entry point
 - legacy circuit, row, mapping and report writes have real late-failure rollback coverage
 - circuit and device-row persistence value mapping is separated from the general repositories
+- obsolete direct Circuit, CircuitDeviceRow, CircuitList, DistributionBoard and
+  Project repository writes are removed; integration fixtures live under
+  `tests/support` instead of production repositories
 - the legacy consumer UI and application read/write endpoints are removed after verified data cutover
 - retained legacy rows are accessible only through explicit database upgrade tooling
 - project devices no longer persist duplicate legacy power, phase, cosPhi or remark fields