Full-codebase review turned up five real correctness/security bugs and
a dozen smaller inconsistencies; all are fixed here with matching test
coverage:
- BMK uniqueness silently allowed German-umlaut duplicates ("Ä1" vs
"ä1") because the DB's normalized index only folds ASCII case. Added
a shared Unicode-aware pre-check used by every circuit/component
insert and rename path (one of which had no pre-check at all).
- CircuitDeviceRow.simultaneityFactor had no upper bound at the row
level (command model and snapshot/restore schema), unlike every
sibling entity, letting a bad value silently corrupt power totals.
- Grid cell editing silently misread German thousands-separator input
("1.500" parsed as 1.5); "." is now rejected outright with a clear
message instead of guessing.
- The editor's shared command runner (runCommand/applyHistory) had no
re-entrancy guard, so a double click/drop could fire the same
command twice and race a BMK collision or revision conflict. Added a
synchronous ref guard plus isSaving on the buttons that lacked it.
- GET .../next-identifier leaked circuit-numbering state for sections
in other projects (no ownership check, 400 instead of 404). Moved
under /projects/:projectId and scoped it.
Also: added the missing circuits.section_id / circuit_device_rows.
circuit_id indexes (migration 0006), gave FormModal a focus trap /
Escape-to-close / focus restore and rebuilt ProjectSettingsModal on
top of it instead of duplicated markup, removed dead code (3 orphaned
domain model files, an unused persistence helper, a wrapper only used
by its own test), pointed the project page at GET /projects/:id
instead of listing+filtering client-side, closed the gap between the
documented 18 MB CSV limit and the ~17.17 MiB actually enforced, added
missing upper bounds on several free-text fields, filled in nine
missing German labels in the revision timeline, replaced a
key-order-fragile JSON.stringify equality check with a real field
comparison, made an implicit sort-order assumption in three
renumbering helpers explicit, cleared the sidebar's target selection
when it no longer resolves after a tree reload, and fixed
updateGlobalDevice to check-then-write instead of write-then-check.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|---|---|---|
| docs | ||
| scripts | ||
| src | ||
| tests | ||
| .dockerignore | ||
| .gitignore | ||
| AGENTS.md | ||
| compose.yaml | ||
| Dockerfile | ||
| drizzle.config.js | ||
| drizzle.config.ts | ||
| index.html | ||
| next-env.d.ts | ||
| next.config.mjs | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| styles.css | ||
| tsconfig.json | ||
| tsconfig.next.json | ||
| tsconfig.scripts.json | ||
Leistungsbilanz
Leistungsbilanz ist eine Webanwendung für die elektrische Ausführungsplanung. Im Mittelpunkt steht ein tabellenähnlicher Stromkreislisten-Editor, der Stromkreise, Gerätezeilen und wiederverwendbare Projektgeräte fachlich getrennt behandelt.
Das Projekt befindet sich in aktiver Entwicklung. Der lokale Entwicklungsbetrieb mit SQLite und Docker Compose ist unterstützt. Ein Produktionsdeployment, Mehrbenutzerbetrieb und der Revit-/IFCGUID-Datenaustausch sind noch nicht implementiert.
Unterstützter Arbeitsablauf
- Projekte, Verteilungen, Etagen und Räume verwalten
- pro Verteilung geschützte Stromkreisgruppen für Beleuchtung, 1-phasige und 3-phasige Stromkreise verwalten
- Hauptschalter, Überspannungsableiter, Gruppenschutz und zusätzliche Verteilergeräte in der Stromkreisliste abbilden
- Schutzgeräte je Stromkreis und optional je Gruppe konfigurieren
- leere, einzeilige und mehrzeilige Stromkreise abbilden
- Stromkreise und Gerätezeilen per Drag-and-drop umstrukturieren
- Projektgeräte einfügen, verknüpfen und kontrolliert synchronisieren
- komplette Stromkreisblöcke filtern und sortieren
- BMKs stabil halten und nur auf ausdrücklichen Befehl neu nummerieren
- Änderungen projektweit und auch nach einem Reload rückgängig machen und wiederholen
- benannte Sicherungspunkte anlegen, wiederherstellen und Revisionen einsehen
- automatische Sicherungspunkte mit begrenzter Aufbewahrung nutzen
Technik
- Next.js 16, React 19 und TypeScript für das Frontend
- Express 5 und Zod für die API
- SQLite,
better-sqlite3und Drizzle ORM für die Persistenz - eigener Spreadsheet-Grid statt eines Bootstrap-Tabellenframeworks
- Node.js-Test-Runner für Domain-, Grid- und SQLite-Integrationstests
Schnellstart mit Docker
Voraussetzungen:
- Git
- Docker Desktop mit Docker Compose
git clone <repository-url>
Set-Location leistungsbilanz-ts
docker compose up --build --detach
Danach:
- Frontend: http://localhost:3001
- API-Healthcheck: http://localhost:3000/health
Der API-Container führt ausstehende Migrationen und die Schemaprüfung beim Start
automatisch aus. Die SQLite-Datei liegt auf dem Host unter
data/leistungsbilanz.db und bleibt beim Stoppen erhalten.
docker compose ps
docker compose logs --follow
docker compose down
Der Compose-Stack startet Entwicklungsserver mit Quellcode-Mounts. Er ist kein Produktionsdeployment. Details stehen in Deployment und Betrieb.
Direkte lokale Entwicklung
Voraussetzungen:
- Node.js 22
- npm
npm ci
npm run db:migrate
npm run db:verify:circuit-schema
npm run dev:api
In einem zweiten Terminal:
npm run dev:web
Frontend und API laufen anschließend auf denselben Ports wie im Docker-Setup.
Qualitätssicherung
npm test
npm run build:api
npm run build:web
npm run typecheck:scripts
npx tsc --noEmit -p tsconfig.next.json
Wichtige Datenbankbefehle:
npm run db:backup
npm run db:migrate
npm run db:verify:circuit-schema
npm run db:generate
db:backup verwendet die SQLite-Online-Backup-API und prüft das Ergebnis auf
Integrität und Fremdschlüsselverletzungen. Migration 0000 ist die
Release-Baseline für eine leere Datenbank; nachfolgende nummerierte Migrationen
entwickeln diese Baseline additiv weiter. Datenbanken aus Entwicklungsständen
vor der Baseline werden nicht unterstützt.
Dokumentation
- Dokumentationsübersicht
- Aktuelle Architektur
- Editor-Interaktionen
- API des Stromkreislisten-Editors
- Entwicklungs- und Contributor-Workflow
- Bekannte Einschränkungen
- Roadmap
Für LLM-gestützte Änderungen enthält AGENTS.md die verbindlichen Domänenregeln, unterstützten Einstiegspunkte und Architekturgrenzen.