# Anforderungs-Abgleich (Dokumentation vs. Code)

Dieses Dokument ergänzt die Hauptdokumentation und listet transparent auf:

1. Was laut Anforderungen noch nicht vollständig umgesetzt ist.
2. Was bereits im Code existiert, aber im ursprünglichen Requirements-Dokument nicht oder nur als offener Punkt erwähnt war.

Basisvergleich:
- Anforderungen: `docs/electrical-load-balance-requirements-context-dump.md`
- Ist-Stand: aktueller Code in `src/`

## A) Anforderungen, die noch nicht vollständig umgesetzt sind

### 1) Bericht/Export/Print für Leistungsbilanzen
- Erwartung: später nutzbarer Report-Export/Print.
- Stand: Noch nicht umgesetzt.
- Wirkung: Der Fokus liegt aktuell auf Erfassung, Bearbeitung und Berechnung im Web-UI.

### 2) „Keine Pflichtfelder“ vollständig im UI-Flow
- Erwartung: Einträge sollen auch ohne zwingende Felder erfassbar sein.
- Stand: Backend-seitig weitgehend erfüllt (optionale Felder + Defaults), UI-Schnellerfassung verlangt derzeit einen Namen.
- Wirkung: Fachlich ist unvollständige Speicherung möglich, aber die Standard-UI bremst diesen speziellen Fall noch.

### 3) Einheitliche Textqualität (Mojibake-frei) im gesamten Frontend
- Erwartung: saubere Umlaute/UTF-8.
- Stand: In mehreren UI-Dateien sind weiterhin fehlerhafte Kodierungsreste vorhanden (z. B. „Gerät“).
- Wirkung: Funktionalität ist gegeben, UX/Textqualität ist noch nachzuziehen.

## B) Bereits umgesetzt, aber im ursprünglichen Requirements-Dokument nicht klar ausformuliert

### 1) Feste Domänen-Auswahllisten sind final definiert
- Im Requirements-Dokument war das als „noch festzulegen“ markiert.
- Im Code jetzt vorhanden:
  - `src/shared/constants/consumer-option-lists.ts`
  - Validierung in `src/shared/validation/consumer.schemas.ts`
  - Select-Felder in `src/app/projects/[projectId]/circuit-lists/page.tsx`

### 2) Sortieren, Filtern und Bulk-Edit sind bereits implementiert
- Im Requirements-Dokument als mögliche Zusatzfunktion erwähnt.
- Im Code umgesetzt in `src/app/projects/[projectId]/circuit-lists/page.tsx`.

### 3) Projekt-Spannungsstandards (1-phasig / 3-phasig) inkl. Berechnungsintegration
- Im Requirements-Dokument nicht so detailliert als Projekt-Feature beschrieben.
- Im Code umgesetzt:
  - Projekteinstellungen im Projekt-Detail
  - Verwendung in Berechnungslogik (effektive Spannung je Verbraucher)

### 4) 1–3 parallele Stromkreislisten mit responsiver Aufteilung
- Im Requirements-Dokument nicht als konkrete UI-Regel spezifiziert.
- Im Code umgesetzt in `src/app/projects/[projectId]/circuit-lists/page.tsx`.

### 5) Gerätekopie global ↔ projektbezogen in beide Richtungen
- Fachlich erwähnt, aber technisch konkretisiert im API-Design:
  - `POST /api/project-devices/projects/:projectId/import-global/:globalDeviceId`
  - `POST /api/global-devices/import-project/:projectId/:projectDeviceId`

## C) Offene fachliche Entscheidungen mit bereits getroffener Code-Interpretation

### 1) Verhalten beim Kopieren von Stromkreiseinträgen zwischen Listen
- Offener Punkt in den Anforderungen: Link beibehalten oder trennen?
- Aktuelle Code-Interpretation: Link-Information wird mitkopiert (`projectDeviceId`, `isLinkedToDevice`).
- Relevanz: Sollte fachlich explizit bestätigt werden, damit spätere Änderungen keine Regression verursachen.

## D) Empfehlung für nächste Dokumentationsrunde

1. Das Requirements-Dokument um die inzwischen finalen Auswahllistenwerte ergänzen.
2. Die Kopierlogik (Link beibehalten/trennen) fachlich eindeutig festschreiben.
3. Einen eigenen Abschnitt für bekannte UX-/Textqualitätspunkte (Kodierung/Umlaute) ergänzen.