Rewrite frontend, added rooms, voltage selection per project, startet with todos

AGENTS.md

@@ -322,6 +322,20 @@ Document:
 
 Prefer concise Markdown documentation.
 
+## Development Progress Documentation
+
+Document the current implementation status in dedicated Markdown files whenever regular status updates are requested.
+
+- Keep status tracking explicit with `TODO`, `WIP`, and `DONE` sections.
+- For each relevant module or feature area, document:
+  - what it does,
+  - how it works,
+  - which files/functions are involved,
+  - why important design choices were made,
+  - current limitations or open points.
+- Break larger features into small sub-sections so someone new can read through and understand the flow.
+- Update these Markdown status documents incrementally during implementation so progress can be tracked clearly over time.
+- Prefer understandable, step-by-step explanations over overly brief summaries when needed for clarity.
 ## Coding Style
 
 Write clear, explicit TypeScript.
@@ -397,3 +411,55 @@ The first useful milestone should be:
 - Provide basic tests for calculation logic
 
 Do not start with advanced reporting before the core data and calculation workflow works.
+
+## Current UI Workflow Requirements
+
+Implement and preserve the following navigation and workflow structure:
+
+1. A dedicated project page that lists all projects and allows creating new projects.
+2. On the same project page, users can configure global devices/consumers.
+3. Inside a project, users first see all distribution boards and can open a selected board.
+4. Circuit lists are edited in a dedicated view where up to 3 circuit lists can be opened in parallel.
+5. Users must be able to copy circuit entries/consumers between the open circuit lists with minimal clicks.
+6. In the circuit-list view, exactly 1 list is open by default. Users can add/remove list panels dynamically with a minimum of 1 and a maximum of 3 open lists.
+
+When implementing frontend changes, keep this structure as the default interaction model unless the user explicitly requests a different UX.
+
+## Language and Text Rules
+
+Use proper German umlauts (ä, ö, ü, Ä, Ö, Ü, ß) in all new or changed German UI texts and documentation text, unless technical constraints explicitly prevent this.
+
+## Responsiveness Rule
+
+Frontend implementations must remain fully responsive by default across mobile, tablet, laptop, and wide desktop breakpoints.
+Layouts with dynamic panel counts (for example 1-3 parallel circuit-list panels) must adapt so available horizontal space is used appropriately instead of leaving fixed empty columns.
+
+## Language and Text Rules (Enforced)
+
+Use proper German umlauts (�, �, �, �, �, �, �) in all new or changed German UI texts and documentation text, unless technical constraints explicitly prevent this.
+
+
+## Project Voltage and Columns Rules
+
+- Project properties must include default single-phase and three-phase voltages. Use 230 V for single-phase and 400 V for three-phase by default, and allow users to change both values in project settings.
+- In circuit lists, when a consumer is single-phase and has no explicit voltage override, calculations use the project single-phase default voltage. When a consumer is three-phase and has no explicit voltage override, calculations use the project three-phase default voltage.
+- When creating a new consumer/device entry, the standard input fields should be: consumer display name, quantity, unit power, demand factor, and total power.
+- By default, the table should initially hide: power factor (cos phi), phase count, and current.
+- Users must be able to add any available attribute as a table column at any time, and must be able to reorder column positions.
+
+
+## Open TODOs from docs/electrical-load-balance-requirements-context-dump.md
+
+- [x] Extend `CircuitEntry` data model with missing fields from requirements, especially `circuitNumber`, `description`, `deviceType`, `phaseType`, `tradeOrCostGroup`, `group`, `protectionType`, `protectionRatedCurrent`, `protectionCharacteristic`, `cableType`, `cableCrossSection`, `cableLength` and `comment`.
+- [x] Allow multiple entries with the same `circuitNumber` and make this visible/editable in the circuit-list table.
+- [x] Implement project-specific device lists (`ProjectDeviceList`) in backend + UI.
+- [ ] Implement copying devices both directions between global and project-specific device lists.
+- [ ] Add separate device naming model with `Device.name` and `Device.displayName`.
+- [ ] Add explicit entry description field (`CircuitEntry.description`) independent of linked device naming.
+- [ ] Implement device-link lifecycle on entries: link, unlink/detach, and update propagation from device changes to linked entries.
+- [ ] Add `addCount` when adding a device to a circuit list to create multiple entries in one action (`addCount != quantity`).
+- [ ] Relax circuit-entry validation so incomplete entries are possible (currently several fields are required).
+- [ ] Add duplicate-entry action within the same circuit list (separate from copy to another list).
+- [ ] Add sorting/filtering/bulk-edit capabilities for circuit-list tables (beyond current copy-selection flow).
+- [ ] Define and implement fixed selection lists for domain fields (`deviceType`, `phaseType`, `tradeOrCostGroup`, `group`, protection and cable fields).
+- [ ] Extend tests beyond pure power formulas to cover new circuit-entry/device-link behaviors once implemented.