Browser-BIM (cad): semantisches Modell, abgeleitete 2D/3D-Sichten, Zeichenwerkzeuge

Standalone-Browser-Port von DOSSIER. Enthaelt das semantische Modell mit
Plan-/3D-Ableitung, Zeichen- und Editierwerkzeuge, Rhino-artiges Befehlssystem,
dockbares Panel-System, Resource-Manager, DXF/.lin/.pat-Import, i18n (de/en)
sowie Projektdokumentation und Probe-Harness.

docs/design/state-architecture.md

@@ -0,0 +1,52 @@
+# Zustands-Architektur & Code-Aufteilung (App.tsx entschlacken)
+
+> Ziel: `App.tsx` von „God-Component" zu dünnem Shell. Globaler Zustand in einen
+> Store, Features in eigene Module → **wartbar + parallel bearbeitbar**.
+
+## Problem
+`App.tsx` hält aktuell: Projekt-State, Auswahl, View-State (viewType/detailLevel/
+renderMode/referenceLines/scale/activeLevel), Layout, ALLE Mutations-Handler
+(floors/layers/components/hatches/lineStyles/walls/doors), Kontextmenü-Builder,
+Inline-Editoren, Layout-Menü, View-Routing. → Risiko + Flaschenhals (jedes Feature
+fasst App.tsx an → kein paralleles Arbeiten).
+
+## Zielstruktur
+```
+src/state/
+  store.ts          // Store (Zustand) — kombiniert die Slices, ein useStore-Hook
+  projectSlice.ts   // project + alle Mutationen (floors, layers, components,
+                    //   hatches, lineStyles, walls, doors) inkl. recompute/refs-aware delete
+  selectionSlice.ts // selectedWallIds (+ marquee-Ergebnis)
+  viewSlice.ts      // viewType, detailLevel, renderMode, referenceLines, activeLevelId, scale
+  layoutSlice.ts    // wraps src/panels/layout.ts (docks + floating)
+src/views/          // LevelPlanView, PerspectiveView, SectionStub, DrawingView (+ ViewRouter)
+src/editors/        // FloorSettingsEditor, LayerSettingsEditor, … (heute inline in App)
+src/menus/          // layerContextMenu(), levelContextMenu(), planContextMenu() — bauen ContextMenu-Items
+src/ui/             // TopBar, StatusBar, ResourceManager, ContextMenu (bestehen)
+src/panels/         // Docks/Panels (bestehen)
+App.tsx             // DÜNN: Store-Provider · TopBar · (Docks + ViewRouter) · StatusBar
+                    //       · Floating-Panels · Ressourcen-Overlay
+```
+
+## Store-Wahl: Zustand (empfohlen)
+- Winzige Lib, kein Boilerplate, **Slices** gut teilbar, Selektoren verhindern
+  Re-Render-Sturm, kein Prop-Drilling. Passt zu „verschiedene Features = verschiedene
+  Slice-Dateien" → Parallelität.
+- Alternative ohne Dependency: Context + useReducer oder `useSyncExternalStore`
+  (wie i18n). Mehr Boilerplate; bei der State-Menge ist Zustand ergonomischer.
+- Komponenten: `const walls = useStore(s => s.walls)` / `useStore(s => s.addFloor)`.
+  PanelHostContext entfällt (Panels lesen direkt aus dem Store).
+
+## Vorgehen (reiner Refactor — Verhalten MUSS identisch bleiben)
+1. Store + Slices anlegen, Projekt-State + Mutationen aus App.tsx hierher ziehen
+   (1:1, gleiche Logik inkl. recomputeFloorElevations, refs-aware delete).
+2. View-/Selection-/Layout-State in ihre Slices.
+3. Inline-Editoren, Kontextmenü-Builder, View-Routing in `src/editors/`,`src/menus/`,`src/views/` extrahieren; sie lesen den Store.
+4. App.tsx auf den Shell reduzieren.
+5. Verifizieren: tsc + build + Screenshots — **pixel-/funktionsgleich** zu vorher
+   (Auswahl, Massstab, Kontextmenü, Panels, 3D/Plan, i18n). Reiner Umbau, kein
+   Feature-Wechsel.
+
+## Auszahlung
+- Danach editiert ein Wand-Feature `projectSlice`/`views`, ein Panel-Feature `panels`,
+  ein Editor `editors` — **disjunkte Dateien → mehrere Code-Workflows parallel** möglich.