App.tsx: Hell/Dunkel-State nach theme/useThemeMode.ts

Reiner Umzug von useState + Setter-Wrapper (persistiert in localStorage via themeMode.ts) in einen eigenen Hook. Verhaltensgleich.
App.tsx: Dialog-Sichtbarkeits-State nach state/useDialogState.ts
2026-07-21 16:24:33 +02:00 · 2026-07-21 16:15:59 +02:00 · 2026-07-21 14:47:40 +02:00 · 2026-07-21 13:35:58 +02:00 · 2026-07-21 13:35:44 +02:00 · 2026-07-20 11:05:08 +02:00
275 changed files with 66821 additions and 4628 deletions
@@ -11,3 +11,7 @@ scripts/*.png
 # Editor / OS
 .DS_Store
 *.log
 # Generierte native-Viewport-Szenen (aus sampleProject via scripts/dump-native-scene.mjs)
 src-tauri/assets/native2d_scene.json
 src-tauri/assets/native3d_walls.json
@@ -1,452 +1,390 @@
-# Architektur — Standalone Browser-BIM (cad)
+# Architektur — Dossier (Desktop-CAAD)
-> Stand: 2026-06-29
+> Stand: 2026-07-21 (grundlegend überarbeitet — siehe [STATUS.md](STATUS.md) für
-> Vision, Phasen und Backlog: [ROADMAP.md](ROADMAP.md). Konventionen: [CONVENTIONS.md](CONVENTIONS.md).
+> die volle Bestandsaufnahme inkl. Mist-Liste, die diese Überarbeitung begründet).
-> Detail-Designs: [docs/design/elements.md](docs/design/elements.md) ·
+> Vision/Phasen (historisch, Tag-1-Stand): [ROADMAP.md](ROADMAP.md). Konventionen:
-> [docs/design/plans-output.md](docs/design/plans-output.md) ·
+> [CONVENTIONS.md](CONVENTIONS.md). Detail-Designs (teils ebenfalls veraltet,
-> [docs/design/resources-graphics.md](docs/design/resources-graphics.md).
+> siehe Hinweis in [docs/README.md](docs/README.md)): [docs/design/](docs/design/).
-Dieses Dokument beschreibt, **wie** die Standalone-Browser-App gebaut wird und
+Dieses Dokument beschreibt, **wie** Dossier tatsächlich gebaut ist — nicht wie
-wie sie die Konzepte des DOSSIER-Rhino-Plugins in Browser-Äquivalente übersetzt.
+es am ersten Tag geplant war. Dossier ist die eigenständige Neuimplementierung
-DOSSIER ist ein Rhino-8-Plugin (Python + React-WebView); `cad` ist die *eigen
+des Rhino-Plugins [DOSSIER](https://git.openbureau.ch/karim/dossier): dieselbe
-ständige* Browser-Variante: kein Rhino-Document, kein `doc.Strings`, kein
+Denkweise (Geschosse, Kategorie-Ebenen, mehrschichtige Bauteile,
-IronPython — stattdessen ein **eigenes typisiertes Datenmodell in TypeScript**,
+Prioritäts-Verschneidung), aber als **native Desktop-App** mit einem **eigenen
-gerendert über **Three.js** (3D) und **SVG** (Plan), gespeichert als **JSON-Datei**.
+typisierten Datenmodell in TypeScript** und **zwei eigenen Rust/WASM-Rendering-
 Engines** („Nordstern") statt Rhino-Dokument/IronPython.
-Alle Bezeichner im Code sind **englisch** (Vectorworks-Terminologie); Prosa und
+**Desktop-Rahmen (plattformabhängig, wegen WebGPU):** auf **macOS Tauri**
-UI-Texte sind deutsch. Einheiten intern in **Metern**.
+(WKWebView unterstützt WebGPU), auf **Linux Electron/Chromium** (Tauris
 Linux-Webview WebKitGTK unterstützt WebGPU nicht zuverlässig — die
 render2d/render3d-Engines brauchen es). Beide teilen dieselbe React-App und
 randlose Titelleiste; Laufzeit-Erkennung über `window.__TAURI__` bzw.
 `window.dossierWindow` (Electron-`contextBridge`). Details: STATUS.md §2.7.
 Alle Bezeichner im Code sind **englisch**; Prosa und UI-Texte sind deutsch.
 Einheiten intern in **Metern**.
 ---
 ## 0. Leitprinzip — ein Modell, viele Darstellungen
-Das semantische Gebäudemodell ist die **einzige Wahrheit**. Jede Sicht (3D,
+Das semantische Gebäudemodell (`Project`) ist die **einzige Wahrheit**. Jede
-Grundriss, Schnitt, Ansicht) ist eine **reine Ableitung** (`derive`) daraus.
+Sicht (3D, Grundriss, Schnitt, Ansicht) ist eine **reine Ableitung** daraus.
 Darstellung (Detailgrad, Stile, Schraffuren, Overrides) wird **beim Rendern**
-angewandt, nie in die Geometrie eingebacken.
+angewandt, nie in die Geometrie eingebacken. Dieses Prinzip hat sich über drei
 Wochen und ~125.000 Zeilen Code bewährt und wird strikt gehalten — es ist der
 einzige Teil der ursprünglichen Architektur-Vision, der **unverändert** Bestand
 hat. Alle konkreten Technologie-Entscheidungen darunter (Rendering-Engine,
 State-Store, Schnitt-Mechanismus) sind anders gelaufen als am Tag 1 geplant;
 Details dazu in [STATUS.md](STATUS.md) §5.
 ```
                 ┌──────────────────────────────────────────┐
                 │   Project  (semantisches Modell, JSON)    │   ← einzige Wahrheit
-                 │   resources · types · designLevels ·      │
+                 │   resources · types · drawingLevels ·     │
-                 │   layers · elements                       │
+                 │   layers · walls/doors/openings/stairs/…  │
                 └──────────────┬───────────────────────────┘
                                │  pure derive()
-        ┌───────────────────────┼────────────────────────────┐
+        ┌───────────────────────┼────────────────────────────┬───────────────┐
-        ▼                       ▼                             ▼
+        ▼                       ▼                             ▼               ▼
-   Scene3D (Three.js)     PlanModel → SVG            SectionModel → SVG
+   3D-Viewport            2D-Plan (generatePlan)        3D-Live-Schnitt   Export
-   buildScene()           generatePlan()             generateSection() (HLR)
+   Viewport3D (three.js)  PlanView (SVG) · glPlan (GL2)  render3d/section  IFC/DXF/
-        │                       │                             │
+   ODER Wasm3DViewport    ODER render2d (Rust/WGSL)      (Rust, analytisch)PDF/STL
-        └────────── beide lesen dieselben joins/components/styles ──────────┘
+   (Rust/wgpu, Default)
        │                       │                             │               │
        └────────── alle lesen dieselben joins/components/styles ─────────────┘
 ```
 Das steht im Spike bereits: `generatePlan.ts` und `Viewport3D.tsx` extrudieren
 **dasselbe** gehrte Band-Polygon (`clippedBand`). Diese Symmetrie ist der Kern
 und wird beim Ausbau strikt gehalten.
 ---
-## 1. Repo-Struktur (Ziel)
+## 1. Repo-Struktur (IST-Zustand)
 Wächst aus dem heutigen `src/` (model/plan/viewport/ui). Module sind **klein und
 fachlich geschnitten** — wir vermeiden bewusst den `elemente.py`-Monolithen
 (7244 LOC) aus DOSSIER (dort als Schwachstelle #4.1 dokumentiert).
 ```
 src/
-  model/
+  model/       Project-Schema (types.ts, ~2500 LOC), joins.ts (Wand-Gehrung/
-    types.ts            // Project, DesignLevel, LayerCategory, Element-Union  (existiert)
+               -Prio-Stösse), parametricWalls.ts, roomStamp.ts, terrain.ts,
-    geometry.ts         // 2D/3D-Mathe ohne Kernel                            (existiert)
+               geoRebase.ts, sampleProject.ts
-    joins.ts            // Wand-Verschneidung (Gehrung; später Prio-T/X)      (existiert)
+  geometry/    2D-Kernel (kernel2d.ts: offset/trim/fillet/split — LIVE, siehe
-    sampleProject.ts    // Demo-Haus                                          (existiert)
+               §3), ceiling/opening/roomArea/roomBoundary/stair/roof/column.ts,
-    project.ts          // Factory, Defaults, Migrationen
+               polygonHoles.ts
-    selectors.ts        // abgeleitete Reads (visibleCodes, elementsOnLevel…)
+  commands/    Rhino-artiges Kommandosystem: types/registry/engine/parseInput.ts
-    ids.ts              // newId(prefix) — UUID-Erzeugung
+               + cmds/ (ein Modul je Kommando: wall, opening, stair, roof,
-    elements/           // pro Bauteil ein Modul (Daten + Generierung)
+               column, room, line/rect/circle/arc, move/mirror/copy/offset/
-      wall.ts  opening.ts  slab.ts  stair.ts  roof.ts  structure.ts  space.ts
+               trim/join, extrude, import, terrain, measure, georef, …)
-  resources/
+  tools/       Interaktive Zeichenwerkzeuge, snapping.ts, transform.ts (Grips)
-    componentManager.ts hatchManager.ts lineManager.ts symbolLibrary.ts
+  compute/     Compute-Boundary: leitet Ops (aktuell nur computeJoins) unter
-    overrides.ts        // regelbasierte Engine (Condition → Action)
+               Tauri via `invoke` an Rust weiter, sonst TS-Fallback
-  store/
+  plan/        generatePlan.ts (2D-Ableitung), PlanView.tsx (SVG + Pan/Zoom/
-    store.ts            // Zustand-Store: { project, ui }, Aktionen, Undo/Redo
+               Grips), glPlan/ (eigener WebGL2-Renderer), toSection.ts/
-    persistence.ts      // Datei save/load (JSON), Autosave (IndexedDB)
+               toElevation.ts (Schnitt/Ansicht-Ableitung), toWalls3d.ts,
-    history.ts          // Undo/Redo-Ring
+               toRenderScene.ts (Szene für Rust-render2d), wallMeshCut.ts
-  plan/
+  viewport/    Viewport3D.tsx (three.js, „Free") UND Wasm3DViewport.tsx
-    generatePlan.ts     // Grundriss aus Footprint + Symbolik (existiert)
+               (Rust/wgpu „Nordstern", Default/editierbar), raycast3d.ts
-    generateSection.ts  // Schnitt/Ansicht aus 3D-Projektion (HLR-Worker)
+  section/     TOTER Code (OCCT-WASM-HLR-Spike, keine Aufrufer mehr) — Schnitt
-    PlanView.tsx        // SVG-Renderer + Pan/Zoom/Grips (existiert)
+               läuft über render3d/section.rs, siehe §4.3
-    primitives.ts       // Primitive-Union, SVG-Serializer, DXF/PDF-Export
+  export/      exportIfc.ts (IFC4), exportDxf.ts/dxfWriter.ts, exportPdf.ts,
-  viewport/
+               layoutPdf.ts (Mehrseiten-PDF pro Ordner), exportMesh.ts (STL/OBJ),
-    Viewport3D.tsx      // Three.js-Szene aus dem Modell (existiert)
+               exportSchedule.ts (CSV-Bauteilliste), sceneToPrintSvg.ts
-    scene.ts            // buildScene(project) → THREE.Group (Layer-Spiegel)
+  materials/   ambientcg.ts (Live-Suche ambientCG-API), library.ts (13
-    clip.ts             // Plan-/Schnitt-Clipping über THREE.Plane
+               gebündelte Starter-Materialien), runtime.ts (PBR-Material aus
-    camera.ts           // Kamera-Presets, Norden-Rotation
+               ComponentMaterial via three.js TextureLoader)
-  sheets/
+  io/          DXF/DWG-Import, Swisstopo (swissBUILDINGS3D/-ALTI3D/SWISSIMAGE,
-    layout.ts           // Sheet/Viewport-Datenmodell
+               LV95↔WGS84), OSM-Overpass, .lin/.pat-Parser, projectFile.ts
-    SheetEditor.tsx     // Plansatz-Editor
+               (.obp Speichern/Laden, Tauri-Lock)
-    exportPdf.ts        // Vektor-PDF (svg → pdf-lib / jsPDF)
+  overrides/   Regelbasierte Override-Engine (Bedingung → Aktion)
-  workers/
+  state/       Eigener Store auf `useSyncExternalStore` (KEIN Zustand/Redux):
-    geometry.worker.ts  // Booleans (Öffnungen) + HLR via Comlink
+               store.ts + Slices (project/history/selection/view/layout/site/
-  ui/
+               notify), appStore.ts komponiert sie
-    App.tsx Navigator panels…    // React-Oberfläche (heute in App.tsx, wird gesplittet)
+  panels/      Dock-/Floating-Panel-System (Dock/FloatingPanel/TabStrip/
               registry/layout) + Panels (Tools, Attributes, ObjectInfo, Layers,
               DrawingLevels, Site, RoomBalance, Elements, ViewSnapshots, Layouts)
  ui/          App.tsx (Shell, **7.130 LOC — noch nicht auf dünne Shell
               reduziert**, siehe STATUS.md §4.3), TopBar, ResourceManager.tsx
               (Material-/Hatch-/Line-/Typ-Editoren, natives Fenster),
               ContextMenu, CommandLine.tsx, LayoutSheet/-Menu, ribbon/
  native/      NUR Tauri: native Fenster (Resources/Settings/DrawingLevels/
               LayerSettings/ContextImport), macOS-Menüleiste, Fenster-Chrome —
               jede Funktion no-opt via `isTauriRuntime()` im Browser
  editors/     booleanOps.ts (2D-Boolean via polygon-clipping), splitJoin.ts
  text/        Rich-Text (richText.ts, RichTextEditor.tsx, renderHtml.ts)
  theme/       Hell/Dunkel, Akzentfarben
  i18n/        de.ts/en.ts Wörterbücher, eigener t()-Mechanismus
  engine/      Reine WASM-Lade-Glue: engine3d.ts (pkg3d), truckSolid.ts
               (pkgTruck), plan/useWasmPlanRenderer.ts (pkg) — pkgGeometry und
               pkgDwgImport sind gebaut, aber unbenutzt (siehe STATUS.md §4.1)
 src-tauri/
  src/            Tauri-Host (Fenster, native Dialoge, fs4-Exklusiv-Lock)
  render2d/       2D-Plan-GPU-Renderer (wgpu/WGSL, + glyphon-Text), auch → WASM
  render3d/       „Nordstern" 3D-Engine (wgpu/WGSL): Wandextrusion + Schicht-
                  bänder + Gehrung, LIVE 2D=3D-Schnitt (section*.rs, analytisch,
                  kein HLR), Kanten-Extraktion, Materialtextur-Arrays,
                  Aerial-Drape, Render-Styles (Shaded/White/Textured/Wireframe/
                  Hidden/ShadedEdges) — auch → WASM
  kernel2d/       Rust-Port von geometry/kernel2d.ts — NUR Paritätstest, nicht
                  produktiv (WASM war < 100 Wänden langsamer als TS)
  geometry/       Wand-Join-Mathe — Rust-Port, UNBENUTZT (kein Aufrufer)
  trucksolid/     CSG/Extrusion (`truck`-Crate + `csgrs`-Booleans) → WASM,
                  genutzt vom Extrude-Kommando; Boolean NICHT an Wände/
                  Öffnungen angeschlossen
  dwgimport/      DXF-Parser-Spike (`acadrust`) → WASM, UNBENUTZT (DWG-Import
                  läuft über npm `@mlightcad/libredwg-web`)
 ```
 Jedes Crate unter `src-tauri/` ausser dem Host ist ein **eigenständiges
 Cargo-Package** (kein gemeinsamer Workspace), das sowohl headless
 (`cargo test`) als auch per `wasm-pack --features web` baut und dann via
 `src/engine/pkg*/` von der TS-Seite geladen wird (`npm run build:engine{,3d,
 Geometry,Kernel2d,DwgImport}`/`build:truck`).
 ---
 ## 2. Datenmodell
-### 2.1 Zwei unabhängige Achsen (DOSSIER-Modell, im Spike umgesetzt)
+### 2.1 Zwei unabhängige Achsen (unverändert gegenüber der Vision)
-DOSSIER trennt zwei orthogonale Konzepte, persistiert als zwei getrennte
+1. **Zeichnungsebenen** (`DrawingLevel`) — Geschoss (`kind:"floor"`,
-JSON-Bäume (`dossier_zeichnungsebenen`, `dossier_ebenen`). Wir übernehmen das
+   `floorHeight`/`cutHeight`/`baseElevation`), Schnitt/Ansicht
-1:1 in `types.ts` (existiert bereits als `drawingLevels` + `layers`):
+   (`kind:"section"|"elevation"`), oder freie Zeichnung (`kind:"drawing"`).
 2. **Ebenen** (`LayerCategory`) — das Grafik-Kategorie-Schema (Baum,
   `{code, name, color, lw, visible, locked, hatch?, children}`), in jedem
   Geschoss gültig. Codes 1:1 aus DOSSIER (`00 Raster · 01 Vermessung ·
   20 Wände (└21 Türen/Fenster, 25 Stützen) · 30 Decken · 31 Dächer ·
   40 Treppen · 50 Text · 60 Räume · 80 Plangrafik …`).
-1. **Zeichnungsebenen** (`DesignLevel` / `DrawingLevel`) — die obersten
+### 2.2 Elemente — typisierte Arrays statt `Element[]`-Union
   Dokument-Abschnitte. Zwei produktive Arten:
   - **Geschoss** (`kind:"floor"`): `floorHeight`, `cutHeight`,
     `baseElevation` (akkumuliert via `recomputeFloorElevations`), `visible`/`locked`.
   - **Schnitt/Ansicht** (`kind:"section"|"elevation"`): `linePoints`,
     `directionSign`, Höhenbereich, Tiefe.
   - **Zeichnung** (`kind:"drawing"`): freie 2D-Ebene ohne Geschossbezug.
 2. **Ebenen** (`LayerCategory`) — das **Grafik-Kategorie-Schema**, das in *jedem*
   Geschoss gilt. Baum mit `{code, name, color, lw, visible, locked, hatch?, children}`.
   Codes 1:1 wie DOSSIER (`DEFAULT_LAYER_SCHEMA` aus `launcher/src/App.jsx`):
   `00 Raster · 01 Vermessung · 20 Wände (└21 Türen/Fenster, 22 Möbel, 25 Stützen) ·
   30 Decken · 31 Dächer · 35 Träger · 50 Text · 60 Plangrafik …`
-Ein **Element** kennt sein **Geschoss** (`floorId`) *und* seine **Ebene**
+Anders als ursprünglich geplant hält `Project` (`src/model/types.ts:2095`)
-(`categoryCode`). Sichtbarkeit ergibt sich aus dem Schnitt (Geschoss `geschoss × code`
+**pro Bauteiltyp ein eigenes (meist optionales) Array**:
 Matrix), genau wie DOSSIERs `apply_visibility(z_mode, e_mode)` in `layer_builder.py`.
 > **Begriffsnotiz:** Heute heißt der Typ im Code `DrawingLevel`. ROADMAP §5 nennt
 > die Modell-Eingabe (Geschosse) Vectorworks-konform **Design Layer** und die
 > abgeleitete Ausgabe **Drawing Layer / Sheet**. Wir behalten `DrawingLevel` als
 > Union (kind=floor ≙ Design Layer, kind=section/elevation/drawing ≙ Drawing
 > Layer) und führen `Sheet` erst separat ein (§2.5, plans-output.md). Kein Rename
 > ohne expliziten Auftrag.
 ### 2.2 Ressourcen-Bibliotheken (Vectorworks-Stil)
 Neuer Block `Project.resources` (heute provisorisch als flache `materials[]`).
 Alles verweist **per id** — zentral änderbar. Details: resources-graphics.md.
 ```ts
-interface Resources {
+interface Project {
-  lineStyles: LineStyle[];   // Line Manager:  { id, name, weight(mm), color, dash:number[] }
+  walls: Wall[];
-  hatches:    Hatch[];       // Hatch Manager: { id, name, pattern, scale, angle, lineStyleId }
+  ceilings?: Ceiling[];
-  components: Component[];    // Component Manager (= DOSSIER-Material erweitert):
+  roofs?: Roof[];
-                             //   { id, name, hatchId, color3d, texture3d?, joinPriority }
+  doors: Door[];              // ÄLTER — siehe openings; bewusste Doppelspur
  openings?: Opening[];       // NEUER, allgemeiner: kind:"window"|"door"
  stairs?: Stair[];
  rooms?: Room[];
  columns?: Column[];
  extrudedSolids?: ExtrudedSolid[];
  drawings2d: Drawing2D[];
  context?: ContextObject[];  // Terrain/Importe — NICHT semantisch
  parametricWalls?: ParametricWall[];
  overrideRules?: OverrideRule[];
  viewSnapshots?: ViewSnapshot[];
  viewSnapshotFolders?: ViewSnapshotFolder[];
  layouts?: Layout[];
  masterLayouts?: MasterLayout[];
  layoutFolders?: LayoutFolder[];
  // + Bibliotheken: lineStyles, hatches, components, wallTypes, roofTypes?,
  //   doorTypes?, windowTypes?, stairTypes?, ceilingTypes?
  // + drawingLevels, layers, geoAnchor?, referenceElevationMasl?
 }
 ```
-`joinPriority` ist DOSSIERs `_MATERIAL_PRIO` (Beton 800 … Putz 100) als
+Ein `Element`-Typalias existiert noch (`kind:"door"|"window"` etc.), wird aber
-**Daten** statt Hardcode — steuert die Prioritäts-T-Verschneidung (Risiko #1).
+nirgends im Code referenziert — Selektion/Element-Baum arbeiten direkt auf den
 typisierten Arrays. `doors`/`openings` sind eine **bekannte, noch nicht
 konsolidierte Doppelspur** (PENDENZEN.md).
-### 2.3 Aufbauten (mehrschichtige Typen)
+### 2.3 Ressourcen & Aufbauten (unverändert gegenüber der Vision)
 ```ts
 interface Resources { lineStyles: LineStyle[]; hatches: Hatch[]; components: Component[]; }
 interface WallType { id; name; layers: { componentId; thickness }[]; }
 interface SlabType { id; name; layers: { componentId; thickness }[]; }
 ```
-Schichtdicke liegt am Layer, **Priorität am Component** (so muss man Prio nur
+`joinPriority` sitzt am `Component` (Daten statt Hardcode) und steuert die
-einmal pflegen). 3D und Plan lesen dieselben `layers[]`.
+Prioritäts-T-/X-Verschneidung — **fertig implementiert**, inklusive Rust-Port
 für den 3D-Live-Schnitt (`section_boolean.rs` = Port von
 `toSection.ts::subtractDominantBands`).
-### 2.4 Elemente
+### 2.4 Layouts / Ausschnitte
-Diskriminierte Union `Element` (heute `Wall | Door`), erweitert um
+`ViewSnapshot` (Kamera/Massstab/Detailgrad/Sichtbarkeiten/Override-Preset) in
-`Window | Slab | Stair | Roof | Column | Beam | Space | Draw2d`. Jedes Element:
+`ViewSnapshotFolder`-Bäumen; `Layout` (Papierformat, mehrere
-`{ id, type, floorId, categoryCode, ... }`. Gehostete Elemente (Tür/Fenster)
+`LayoutViewport`s, freie `LayoutAnnotation`s, optionale `MasterLayout`-Vererbung)
-tragen `hostWallId` statt `floorId` (Geschoss ergibt sich aus der Wand). Volle
+in `LayoutFolder`-Bäumen. Beide gehören ins Dokument (nicht LocalStorage).
 Felder: elements.md.
 ### 2.5 Pläne / Output (eigene Achse)
 ```ts
 interface Sheet {              // Plansatz-Blatt (≙ DOSSIER Layout/PageView)
  id; name; paper: "A0".."A4"|"Letter"; landscape: boolean;
  viewports: SheetViewport[];  // platzierte Ableitungen + Titelblock
  folder?: string;
 }
 interface SheetViewport {      // ≙ DOSSIER Detail + gebundener Ausschnitt
  id; rect: Rect; sourceViewId: string;  // referenziert DrawingLevel oder ViewSnapshot
  scale: number;               // 1:N
 }
 interface ViewSnapshot {       // ≙ DOSSIER Ausschnitt (View-Snapshot)
  id; name; folder?;
  camera: CameraState; scale: number; detailLevel: DetailLevel;
  visibility: VisibilityState;          // pro Geschoss/Ebene
  overrides?: { presetId?; enabled };
 }
 ```
 ---
 ## 3. State, Persistenz, Undo/Redo
-### 3.1 Store — Zustand
+### 3.1 Store — eigener `useSyncExternalStore`, nicht Zustand
-Heute: `useState<Project>` in `App.tsx`, immutabel via `setProject`. Das skaliert
+Entgegen der ursprünglichen Empfehlung (Zustand-Library) wurde ein
-nicht für Werkzeuge + Undo. Migration auf **Zustand** (ROADMAP §4):
+**abhängigkeitsfreier Store** gebaut (`src/state/store.ts`, gleiches Muster wie
 `src/i18n`): `createStore()` komponiert Slice-Fabriken über eine gemeinsame
 `RootState`. `appStore.ts` fügt zusammen: `projectSlice` (Projekt + Undo/Redo,
 `setProject` als einziger Mutations-Einstiegspunkt), `historySlice`,
 `selectionSlice`, `viewSlice`, `layoutSlice`, `siteSlice`, `notifySlice`
 (Toast/Confirm-Ersatz für `window.alert`, in Tauris WKWebView deaktiviert).
 Komponenten lesen über `useStore(selector)`.
-```ts
+**Nicht umgesetzt** (geplant in `docs/design/state-architecture.md`): die
-interface AppState {
+Extraktion von View-Routing nach `src/views/` und Kontextmenü-Aufbau nach
-  project: Project;          // das Dokument
+`src/menus/` — beide Ordner existieren nicht, diese Logik liegt weiterhin
-  ui: {                      // flüchtig, NICHT persistiert/undobar
+inline in `App.tsx` (7.130 Zeilen). Siehe STATUS.md §4.3.
    activeLevelId; activeViewType; selection: string[];
    activeTool: ToolId; hover; cameraByView; planTransform;
  };
  // Aktionen mutieren via Immer-Producer; jede Modell-Mutation pusht History.
  apply(mutator: (p: Project) => void): void;
  undo(): void; redo(): void;
 }
 ```
-**Trennung Modell ↔ UI** ist hart: nur `project` ist undobar und wird gespeichert.
+### 3.2 Persistenz
 `ui` (Auswahl, Kamera, aktives Werkzeug) lebt separat. Das ersetzt DOSSIERs
 `sc.sticky`-Bus — wo DOSSIER cross-modul über Sticky-Keys kommuniziert, lesen bei
 uns einfach alle Komponenten denselben Store (reaktiv). **Kein Sticky, kein
 Bridge-Polling, keine `is not None`-Lücken** (DOSSIER-Schwachstelle #4.4).
-### 3.2 Persistenz — JSON-Datei statt `doc.Strings`
+- **Datei:** eigenes `.obp`-Format (`src/io/projectFile.ts`), unter Tauri über
-
+  native Speichern/Öffnen-Dialoge (`plugin-fs`/`plugin-dialog`), im Browser
-DOSSIER speichert *alles* in `doc.Strings` (Key-Value am Rhino-Document) +
+  Blob-Fallback. Ältere `.json`-Projekte bleiben ladbar.
-globale Presets als JSON-Dateien im User-Home. Browser-Äquivalent:
+  OS-Level-Exklusiv-Lock (`fs4`-Crate, `src-tauri/src/lock.rs`) verhindert
-
+  Doppelöffnen desselben Projekts.
-| DOSSIER | Browser (cad) |
+- **Compute-Boundary:** `src/compute/index.ts` leitet einzelne Operationen
-|---|---|
+  (aktuell nur `computeJoins`) unter Tauri via `invoke` an eine native Rust-
-| `doc.Strings.SetString(key, json)` | Feld im `Project`-Objekt (ein JSON-Baum) |
+  Implementierung weiter; im Browser bzw. für nicht migrierte Ops (Room-
-| `.3dm`-Datei mit eingebetteten Strings | **`.cad.json`-Datei** via File System Access API |
+  Detection, DWG-Parsing) läuft die TS-Implementierung.
 | Globale Presets (`~/Library/.../*.json`) | **LocalStorage** (`cad.presets.*`) + Export/Import |
 | Launcher schreibt Settings-Datei | **IndexedDB** Autosave (Phase 5) |
 ```ts
 // persistence.ts
 const FORMAT_VERSION = 1;
 function serialize(p: Project): string            // JSON.stringify({ version, project })
 function deserialize(text: string): Project        // + migrate(version) bis aktuell
 async function saveToFile(p: Project): Promise<void>   // showSaveFilePicker → .cad.json
 async function loadFromFile(): Promise<Project>        // showOpenFilePicker; Fallback <input type=file>
 async function autosave(p: Project)                    // IndexedDB, debounced 2 s
 ```
 - **Save/Load:** [File System Access API](https://developer.mozilla.org/docs/Web/API/File_System_Access_API)
  (`showSaveFilePicker`/`showOpenFilePicker`); Fallback Download-Blob + `<input type=file>`
  für Firefox/Safari.
 - **Autosave/Recovery:** IndexedDB (via `idb`), entkoppelt vom expliziten Speichern.
 - **Cross-Projekt-Presets:** LocalStorage mit Namespacing (`cad.presets.overrides`,
  `cad.presets.wallTypes`, …) + JSON-Export/Import — ersetzt DOSSIERs
  `~/Library/.../override_presets.json` (overrides.py).
 - **Migrationen:** `migrate(data, fromVersion)`-Kette, additiv. DOSSIER macht das
  per Sticky-Prefix (`traite_`→`pause_`→`dossier_`); wir machen es versioniert im
  Datei-Schema.
 ### 3.3 Undo/Redo
-DOSSIER überlässt Undo Rhino (und hat dadurch Cache-Stale-Bugs, Schwachstelle
+Eigener History-Ring im `projectSlice` (kein DOSSIER-Sticky-Bus, kein
-#4.3). Wir besitzen das Dokument selbst → **eigener History-Ring**:
+Cache-Stale-Problem, da alle Sichten pure Ableitungen sind).
 ```ts
 // history.ts — Snapshots des project-Teilbaums (strukturelles Sharing via Immer-Patches)
 interface History { undo: Patch[][]; redo: Patch[][]; }
 ```
 Jede `apply()`-Mutation erzeugt Immer-Patches → Push auf `undo`. Da abgeleitete
 Sichten **pure** sind, ist nach `undo()` kein Cache zu invalidieren — der
 ganze Cache-Stale-Komplex aus DOSSIER (`_JOINTS_CACHE_KEY`, Material-Cache)
 entfällt strukturell.
 ---
 ## 4. Rendering
-### 4.1 Three.js-Szene spiegelt den Ebenen-Baum
+### 4.1 Zwei 3D-Viewports
-DOSSIER baut in Rhino eine **Layer-Hierarchie** `Zeichnungsebene → CODE_Name-Sublayer`
+- **`Viewport3D.tsx`** — three.js, die „Free"-Stufe.
-(`layer_builder.build_layers`) und hängt jedes Objekt an den passenden Sublayer.
+- **`Wasm3DViewport.tsx`** — Rust/wgpu, „Nordstern", editierbar, **Default**.
-Browser-Spiegel: ein **`THREE.Group`-Baum** mit identischer Struktur, gebaut aus
+  Ein Settings-Schalter wählt die Engine; WebGL2/three.js nur noch als
-dem Modell (nicht persistiert — reine Ableitung):
+  explizite Wahl oder Fallback.
 `render3d` (10.246 LOC) baut Wandextrusion inkl. Schichtbändern und
 Prioritäts-Gehrung (`compute_wall_miters`), Materialtextur-Arrays (pro
 Wandschicht) + separate Aerial-Drape-Textur, Render-Styles (Shaded/White/
 Textured/Wireframe/Hidden/ShadedEdges via Kanten-Extraktion mit
 Crease-Erkennung). **Dächer/Treppen/Stützen haben KEINE eigene Rust-Geometrie**
 — sie werden vollständig in TypeScript erzeugt (`geometry/roof.ts`,
 `emitRoofs`/`emitColumns`) und Rust nur als vorberechnetes Dreiecks-Mesh
 (`MeshInput`/`append_context_mesh`, derselbe generische Importpfad wie für
 swissBUILDINGS3D/DXF) übergeben.
 ### 4.2 Grundriss = drei koexistierende Renderer
 1. **`PlanView.tsx`** (SVG) — bleibt immer im DOM (Hit-Testing/Grips),
   unabhängig vom aktiven Zeichenpfad.
 2. **`plan/glPlan/`** — eigener TypeScript-WebGL2-Renderer.
 3. **`useWasmPlanRenderer.ts`** → Rust-`render2d` (WGSL, wgpu nativ,
   WebGPU/WebGL2-Fallback im Web, echtes Text-Rendering via `glyphon`).
 Beide GPU-Pfade fallen bei Init-Fehler still auf SVG zurück.
 ### 4.3 Schnitt/Ansicht — analytische Rust-Pipeline, KEIN HLR
 Der ursprünglich geplante OCCT-WASM-HLR-Pfad (`src/section/hlr.ts`/`occt.ts`)
 ist **toter Code** (keine Aufrufer mehr). Der tatsächlich funktionierende
 Live-Schnitt nutzt aus, dass jedes Bauteil ein Prisma mit konstantem
 Querschnitt ist — eine Schnittebene liefert dadurch **immer** ein
 achsparalleles Rechteck, nie ein Trapez, wodurch HLR unnötig wird:
 ```
-scene
+App.tsx (section3dCutId/section3dPlane)
-└─ levelGroup[floorId]                 (y-Offset = baseElevation)   ← Geschoss
+  → Wasm3DViewport.tsx (section3d-Prop → setSectionPlane)
-   └─ categoryGroup[categoryCode]      (userData.code)              ← Ebene
+  → src-tauri/render3d/src/{section.rs, section_boolean.rs, section_fill.rs}
      └─ element meshes                (userData.elementId)
 ```
-```ts
+`section_boolean.rs` ist ein 1:1-Port von `toSection.ts::subtractDominantBands`
-// scene.ts
+— 2D-Plan-Schnitt und 3D-Live-Schnitt nutzen dieselbe Prioritäts-Logik und
-function buildScene(project: Project, vis: VisibilityState): THREE.Group
+stimmen dadurch exakt überein. Kein Worker, kein Comlink (beides war geplant,
-function syncScene(root: THREE.Group, project, vis)   // diff statt full rebuild (Perf)
+existiert nirgends im Projekt) — läuft synchron GPU-seitig.
 ```
- **Sichtbarkeit:** `categoryGroup.visible = vis.codes.has(code)` und
+### 4.4 Öffnungen als Löcher (kein Mesh-Boolean)
  `levelGroup.visible = vis.floors.has(floorId)` — entspricht DOSSIERs
  `apply_visibility`, aber als simples `.visible`-Toggle statt Layer-Table-Modify.
 - **Farbe/Material:** Component → `MeshStandardMaterial` (PBR später), per
  `componentId` gecacht (wie heute `layerMaterial`-Cache, aber projektweit).
 - **„Grau/gesperrt"-Modi** (DOSSIER `grey`/`grey_locked`): graues Override-Material
  auf der Gruppe statt Layer-Color-Tausch.
-### 4.2 Grundriss = Clipping-Ebene + symbolische Generierung
+Fenster/Türen schneiden echte achsparallele Rechteck-Löcher aus dem Wandkörper
 (`plan/toWalls3d.ts` `subtractSpans`, gespiegelt in `render3d::mesh.rs`).
 Ein generisches Mesh-CSG-Boolean existiert bereits (`trucksolid::boolean_mesh`,
 `csgrs`, für das Extrude-Kommando genutzt), ist aber nicht an die
 Wand/Öffnungs-Pipeline angeschlossen.
-DOSSIER zeigt den Grundriss eines Geschosses, indem es eine **Clipping-Plane** auf
+### 4.5 Materialien
 `okff + schnitthöhe` legt, Normale −Z (`layer_builder.update_clipping_plane`).
 Zwei Browser-Pfade — **beide nötig** (ROADMAP §3):
-1. **3D-Viewport im Plan-Modus:** `THREE.Plane(normal=(0,0,-1), constant=cutZ)` über
+`materials/library.ts` (13 gebündelte PBR-Starter, ambientCG CC0) +
-   `renderer.clippingPlanes` + `material.clippingPlanes`. `clip.ts` setzt die Ebene
+`materials/ambientcg.ts` (Live-Suche der kompletten ambientCG-Bibliothek,
-   pro aktivem Geschoss (`cutZ = baseElevation + cutHeight`), Kamera orthografisch
+1K/2K/4K-Auflösungswahl, On-Demand-Download via `jszip`, Proxy wegen CORS) →
-   von oben. So sieht man den **echten geschnittenen Volumenkörper**.
+`materials/runtime.ts` baut daraus gecachte `THREE.MeshStandardMaterial`s mit
-2. **Symbolischer SVG-Grundriss** (der Hauptweg, schnell + sauber): `generatePlan.ts`
+physisch korrekter Kachelgrösse (UV in Weltmetern).
   erzeugt Vektor-Primitive **direkt aus Parametern** — Wand-Schnittbänder,
   Öffnungs-Aussparungen, Tür-Schwenkbögen — *ohne* Mesh zu schneiden. Steht im
   Spike. Ausbau: Schraffuren, Lauflinien, Bemaßung, LoD (plans-output.md).
 ### 4.3 Schnitt/Ansicht = Kamera + Schnittebenen + HLR
 DOSSIER setzt 1–2 Clipping-Planes (Cut + Back), Parallel-Projektion senkrecht zur
 Linie, zoomt auf die BBox (`schnitte.activate_schnitt`). Browser:
 - **3D-Vorschau:** zwei `THREE.Plane` (Cut auf der Linie, Back in `directionSign`-
  Richtung um `depthBack` versetzt) + orthografische Kamera senkrecht zur Linie.
 - **Vektor-Ergebnis (Risiko #4):** Hidden-Line-Removal durch das zusammengebaute
  Gebäude → saubere Linien als SVG. Via **OpenCascade.js** (`HLRBRep`) im
  **Web Worker** (Comlink), Ergebnis gecacht pro (Schnitt, sichtbare Ebenen,
  Modell-Hash). Geschnittene Bauteile bekommen Component-Schraffur (Section-Style,
  resources-graphics.md). Details: plans-output.md.
 ### 4.4 SVG-Renderer + Geometrie-Booleans
 - **Plan-Output:** SVG (`PlanView.tsx`). `Primitive`-Union (polygon/line/arc/text/
  hatch) → SVG-Elemente; derselbe Serializer speist DXF- und PDF-Export.
 - **Öffnungs-Booleans (Risiko #2):** Tür/Fenster schneidet Loch in Wand. Für 3D
  reicht heute das Aussparen per Segment-Extrusion (im Spike). Für exakte B-Rep-
  Verschneidung (und IFC) **OpenCascade.js** *oder* **Manifold** im Worker —
  Entscheidung in Phase 0 (ROADMAP §8): OCC = exakt/B-Rep, Manifold = schnell/Mesh.
 ---
 ## 5. React-Panel-Struktur
-DOSSIER ist eine Sammlung **getrennter WebView-Panels** (EBENEN, ELEMENTE,
+Dock-/Floating-Panel-System (`src/panels/`: Dock, FloatingPanel, TabStrip,
-GESTALTUNG, OBERLEISTE, MASSSTAB, AUSSCHNITTE, DIMENSIONEN, LAYOUTS, OVERRIDES),
+Registry) mit eingebauten Panels: Tools, Attributes, ObjectInfo,
-die über die Python-Bridge + `sc.sticky` kommunizieren. Im Browser ist alles
+DrawingLevels, Layers, Site (Kontext/Terrain-Import), RoomBalance
-**eine SPA** mit einem geteilten Store — die Panels werden zu Docking-Bereichen.
+(SIA-416-CSV), Elements (Bauteilbaum), ViewSnapshots, Layouts.
-```
+Der **Resource Manager läuft bewusst NICHT als Dock-Panel**, sondern als
-┌─────────────────────────────────────────────────────────────────────┐
+eigenständiges (unter Tauri natives) Fenster — ebenso Settings,
-│ TopBar      Werkzeuge · Ansichtstyp · Massstab · Snaps · Save/Load   │  ≙ OBERLEISTE+MASSSTAB
+DrawingLevels-Detaileditor, LayerSettings und ContextImport
-├──────────────┬──────────────────────────────────────┬───────────────┤
+(`src/native/*Window.ts` + `*WindowApp.tsx`), jeweils mit
-│ Navigator    │  Viewport (Three.js  oder  SVG-Plan)  │ Inspector     │
+`isTauriRuntime()`-Gate und ohne separate Browser-Variante (im Browser bleibt
-│ ┌──────────┐ │  ┌────────────────────────────────┐  │ ┌───────────┐ │
+die entsprechende In-App-Overlay-Variante aktiv, wo vorhanden).
 │ │Zeichnungs│ │  │  3D / Grundriss / Schnitt /    │  │ │ aktives   │ │  ≙ ELEMENTE/
 │ │-ebenen   │ │  │  Ansicht — abgeleitet aus dem  │  │ │ Element + │ │    GESTALTUNG-
 │ ├──────────┤ │  │  Modell                        │  │ │ Stil      │ │    Properties
 │ │ Ebenen   │ │  └────────────────────────────────┘  │ └───────────┘ │
 │ │ (Baum)   │ │                                       │ Manager-Tabs: │
 │ │          │ │                                       │ Components ·  │  ≙ Resource-
 │ └──────────┘ │                                       │ Hatch · Line  │    Manager
 ├──────────────┴──────────────────────────────────────┴───────────────┤
 │ BottomBar    Koordinaten · Snaps · Statusmeldungen                   │
 └─────────────────────────────────────────────────────────────────────┘
   Modal/Drawer:  Ausschnitte · Sheets/Layouts · Overrides · Kamera-Presets · SIA-Bilanz
 ```
-**Komponenten-Map** (heute alles in `App.tsx`; wird gesplittet):
+**Werkzeug-System:** `Tool`-Interface (`src/tools/types.ts`) für Zeichenwerkzeuge
-
+mit Snap-Engine; daneben das umfangreichere **Kommandosystem** (`src/commands/`)
-| Bereich | DOSSIER-Panel | cad-Komponente |
+für Rhino-artige getippte Eingabe (`5,3`/`r5,3`/`5<45`, Tab-Feld-Zyklus in
-|---|---|---|
+`CommandLine.tsx`) — beide koexistieren, decken unterschiedliche
-| Zeichnungsebenen-Liste | EBENEN (oben) | `Navigator/DrawingLevels.tsx` |
+Interaktionsstile ab.
 | Ebenen-Baum | EBENEN (Baum) | `Navigator/LayerTree.tsx` (Spike: `CategoryRow`) |
 | Top-Bar (View/Snaps/Massstab) | OBERLEISTE, MASSSTAB | `TopBar.tsx` |
 | Element-Eigenschaften | ELEMENTE, ELEMENT-PROPERTIES | `Inspector/ElementProps.tsx` |
 | Stil/Attribute der Auswahl | GESTALTUNG | `Inspector/StylePanel.tsx` |
 | Component/Hatch/Line | (Project-Settings, mass_style) | `managers/*Manager.tsx` |
 | View-Snapshots | AUSSCHNITTE | `panels/Snapshots.tsx` |
 | Plansätze | LAYOUTS | `sheets/SheetEditor.tsx` |
 | Regelbasierte Overrides | OVERRIDES | `panels/Overrides.tsx` |
 | Bemaßung | DIMENSIONEN | `panels/Dimensions.tsx` |
 | Element-Übersicht (BIM-Tree) | ELEMENTE-ÜBERSICHT | `panels/ElementTree.tsx` |
 | Kamera-Presets | KAMERA | `panels/CameraPresets.tsx` |
 **Werkzeug-System** (ersetzt DOSSIERs Rhino-Command-Aliases `cmd/wand.py` etc.):
 ein `Tool`-Interface mit `onPointerDown/Move/Up`, das Vorschau-Primitive
 zurückgibt und beim Bestätigen `store.apply()` ruft. Pointer-Events auf Canvas/SVG
 mit Snap-Engine (Endpunkt/Mitte/Schnitt/Ortho/Raster). Tabelle der Tools:
 elements.md §8.
 ---
-## 6. Rhino → Browser — Mapping-Tabelle
+## 6. Rhino → Dossier — Mapping-Tabelle (Kernkonzepte)
-| DOSSIER (Rhino-Plugin) | cad (Standalone-Browser) | Anmerkung |
+| DOSSIER (Rhino-Plugin) | Dossier (Tauri) | Anmerkung |
 |---|---|---|
-| **Rhino `RhinoDoc`** | `Project` (TS-Objekt im Store) | einzige Wahrheit |
+| Rhino `RhinoDoc` | `Project` (TS-Objekt im eigenen Store) | einzige Wahrheit |
-| **`doc.Strings[key]=json`** | Feld im `Project`-JSON | persistiert in `.cad.json` |
+| `doc.Strings[key]=json` | Feld im `Project`-JSON | persistiert in `.obp` |
-| **`.3dm`-Datei** | **`.cad.json`** via File System Access API | + IndexedDB-Autosave |
+| `.3dm`-Datei | **`.obp`**-Datei (Tauri `plugin-fs`) | + Blob-Fallback im Browser |
-| **Globale Presets (~/Library/*.json)** | **LocalStorage** + Export/Import | cross-Projekt |
+| `sc.sticky` (cross-modul Bus) | eigener `useSyncExternalStore`-Store | kein Polling |
-| **`sc.sticky` (cross-modul Bus)** | **Zustand-Store** (reaktiv) | kein Polling, kein None-Bug |
+| Rhino Layer-Tabelle | `LayerCategory[]`-Baum, Sichtbarkeit als `.visible`-Flag | pro Renderer umgesetzt |
-| **`panel_base.BaseBridge` / WebView-IPC** | direkte React-Props/Store | keine `document.title`-Hacks |
+| Clipping-Plane (`AddClippingPlane`) | `render3d::section.rs` (analytisch, Rechteck-Subtraktion) | KEIN HLR |
-| **`document.title="RHINOMSG::"` Polling** | entfällt | SPA, kein WebView |
+| `HLRBRep` | — (ungenutzt; OCCT-Spike ist toter Code) | ersetzt durch obiges |
-| **Eto.Forms Satelliten-Fenster** | React-Modal/Drawer | z.B. Ausschnitt-Settings |
+| `Rhino.Geometry.Brep`-Booleans | `trucksolid::boolean_mesh` (csgrs) | existiert, nicht an Wände angeschlossen |
-| **Rhino Layer-Tabelle (Sublayer-Baum)** | `LayerCategory[]`-Baum + `THREE.Group`-Spiegel | `scene.ts` |
+| Rhino-Grips + DisplayConduit | Pointer-Events + Grip-Overlay (2D vollständig, 3D nur Basis, kein Snap) | siehe STATUS.md §4.7 |
-| **`layer_builder.build_layers`** | `buildScene` (Ableitung) | Gruppen statt Layer |
+| Swisstopo via .NET HttpClient | `fetch()` (CORS-offen) | radiusgenau zugeschnitten (nicht ganze STAC-Kachel) |
-| **`layer.PlotWeight`** | `LineStyle.weight` (mm) → SVG `stroke-width` | massstabsabh. (§plans) |
+| IronPython-Laufzeit-Risiken | entfällt | TS/Rust |
 | **`SectionStyle` (Layer)** | Component-Schraffur beim Schnitt-Rendern | resources-graphics.md |
 | **Clipping-Plane (`AddClippingPlane`)** | `THREE.Plane` + `renderer.clippingPlanes` | `clip.ts` |
 | **`vp.ChangeToParallelProjection`** | `THREE.OrthographicCamera` | `camera.ts` |
 | **`vp.GetFrustum()` → Massstab** | Frustum-Breite (ortho) → 1:N | gleiche Mathe (§plans) |
 | **CoreGraphics DPI-Auto-Detect** | `window.devicePixelRatio` + CSS-px | Browser kennt DPI nativ |
 | **`Rhino.Geometry.Brep`-Booleans** | OpenCascade.js / Manifold (Worker) | Öffnungen, HLR |
 | **`HLRBRep` (über Rhino-Display)** | OpenCascade.js `HLRBRep` (Worker) | Schnitt/Ansicht-Linien |
 | **Rhino-Grips + DisplayConduit** | Pointer-Events auf SVG/Canvas + Overlay | grip-editing (elements.md) |
 | **`Rhino.Input.Custom.GetPoint`** | `Tool`-Pointer-Handler + Snap | Werkzeug-System |
 | **`MouseCallback` (Doppelklick Schnitt)** | `onDoubleClick` auf SVG-Symbol | plans-output.md |
 | **Rhino Undo/Redo** | eigener History-Ring (Immer-Patches) | kein Cache-Stale |
 | **`HatchPattern`-Tabelle** | `Hatch`-Ressourcen + SVG `<pattern>` | resources-graphics.md |
 | **`Linetype`-Tabelle** | `LineStyle.dash[]` → SVG `stroke-dasharray` | resources-graphics.md |
 | **`TextEntity` / Rich-Text** | SVG `<text>` / HTML-Annotation | plans-output.md |
 | **`RhinoPageView` (Layout)** | `Sheet` + `SheetEditor` | plans-output.md |
 | **`FilePdf` Multi-Page-Export** | svg → `pdf-lib`/`jsPDF` (Vektor) | plans-output.md |
 | **Swisstopo/OSM via .NET HttpClient** | `fetch()` (CORS-fähige STAC/Overpass-APIs) | Phase 4 |
 | **LV95↔WGS84 (Python-Formeln)** | dieselben Formeln in TS portiert | Phase 4 |
 | **IronPython 2.7/3 Runtime-Risiken** | entfällt (TS/Browser) | — |
 ---
-## 7. Was wir von DOSSIER übernehmen — und was nicht
+## 7. Was übernommen wurde — und was bewusst anders lief
-**Übernehmen (bewährte Konzepte):**
+**Übernommen (Prinzipien, bewährt):**
- Zwei-Achsen-Dokumentmodell (Zeichnungsebenen × Ebenen).
+- Zwei-Achsen-Dokumentmodell, Layer-Codes 1:1, Component/Hatch/Line-Manager
- Layer-Codes/Farben/lw 1:1 (`DEFAULT_LAYER_SCHEMA`).
+  mit `joinPriority`, LoD (grob/mittel/fein), regelbasierte Overrides,
- Component/Hatch/Line-Manager mit id-Verweisen + `joinPriority`.
+  Ausschnitte, SIA-416-Räume, Norden-Rotation.
- Ansichtstypen = Kamera + optionaler Schnitt (vereinheitlicht).
+- Pure-Ableitungs-Architektur (kein Cache-Stale, kein Sticky-Bus).
 - LoD (`darstellung`: einfach/standard/detail) mit Dokument-Override.
 - Regelbasierte Overrides (Condition → Action, additive Priorität, reversibel).
 - Ausschnitte (View-Snapshots), Layer-Kombinationen, Massstab-pro-Viewport.
 - SIA-416-Räume, Norden-Rotation, Stil-Kataloge.
-**Bewusst anders (Browser-nativ, Schwachstellen vermeiden):**
+**Anders gelaufen als geplant (siehe STATUS.md §5 für die volle Tabelle):**
- **Kein Sticky-Bus** → ein reaktiver Store (vermeidet DOSSIER #4.4/#4.5/#4.6).
+- Eigene Rust/WASM-Rendering-Engines statt Three.js/OpenCascade.js/web-ifc.
- **Kein Monolith** → Bauteil-Module statt 7244-LOC-`elemente.py` (#4.1).
+- Typisierte Arrays pro Bauteiltyp statt `Element[]`-Union.
- **Pure Ableitungen** statt mutierter Doc-Objekte → kein Cache-Stale (#4.3),
+- Eigener Store statt Zustand-Library.
-  kein Undo/Redo-Loch.
+- Analytische Rust-Schnitt-Pipeline statt HLR/Worker/Comlink.
- **Versioniertes Datei-Schema** statt UserString-Sticky-Migration.
+- App.tsx wurde **nicht** wie geplant auf eine dünne Shell reduziert
- **Persistenz im Project-JSON** statt verteilt über `doc.Strings`.
+  (`src/views/`/`src/menus/` wurden nie angelegt) — bekannter, unbereinigter
  Punkt, siehe STATUS.md §4.3.
-**Anti-Over-Engineering (aus DOSSIER-CONVENTIONS.md übernommen):** keine Abstraktion
+**Anti-Over-Engineering (weiterhin gültig):** keine Abstraktion ohne konkretes
-ohne konkretes Problem; kein `try/catch: {}` als Bug-Versteck; erst grep/lesen,
+Problem; erst lesen, dann editieren; Geometrie nie „nebenbei" refactoren.
 dann editieren; Wand-Geometrie nie „nebenbei" refactoren.
 ---
 ## 8. Reihenfolge bei Code-Arbeit
-1. **Dieses Dokument + das relevante Detail-Design** (elements/plans-output/
+1. **STATUS.md** (aktueller Ist-Zustand) + dieses Dokument lesen.
-   resources-graphics) lesen.
+2. **Das betroffene Modul** lesen (nicht raten) — bei Zweifel: welcher der
-2. **Dann das betroffene Modul** lesen (nicht raten).
+   mehreren Renderer/Pfade ist gerade aktiv (§4.1/§4.2)?
-3. **Erst danach editieren**; `Project` immer immutabel via `store.apply()` ändern.
+3. **Erst danach editieren**; `Project` immer immutabel via den Store ändern.
-4. **Verifizieren:** `npx tsc -b`, `npm run build`, Screenshot via
+4. **Verifizieren:** `npx tsc -b`, `npm test` (Vitest), `cargo test` in den
-   `node scripts/probe.mjs` — Geometrie visuell prüfen.
+   betroffenen Crates, bei Rust-Änderungen `npm run build:engine{,3d}` (WASM
-5. **Dieses Dokument aktuell halten**, wenn sich Patterns/Mapping ändern.
+   neu bauen, nur `.rs` committen — `src/engine/pkg*/` ist gitignored). Bei
   render3d/Wasm3DViewport-Änderungen testet der Nutzer selbst in der
   Tauri-Dev-App (nicht per Puppeteer/Browser verifizierbar).
 5. **Dieses Dokument aktuell halten**, wenn sich Patterns ändern — insbesondere
   nicht wieder in „Ziel-Struktur"-Beschreibungen abdriften, die Monate lang
   niemand nachführt.
@@ -1,6 +1,8 @@
-# Projekt-Konventionen — Browser-BIM (cad)
+# Projekt-Konventionen — Dossier
-Siehe [ROADMAP.md](ROADMAP.md) für Vision, Architektur und Phasen.
+Siehe [ARCHITECTURE.md](ARCHITECTURE.md) für die aktuelle Architektur,
 [STATUS.md](STATUS.md) für den vollständigen Ist-Zustand und
 [ROADMAP.md](ROADMAP.md) für die ursprüngliche (historische) Produktvision.
 ## Code-Konventionen (verbindlich)
@@ -15,16 +17,26 @@ Siehe [ROADMAP.md](ROADMAP.md) für Vision, Architektur und Phasen.
  CCW-Wicklung zeigt `+n` nach innen. Schichten werden außen (−T/2) → innen (+T/2)
  gestapelt.
-## Code-Struktur (kein God-Component)
+## Code-Struktur (kein God-Component — bisher nur teilweise erreicht)
- **`App.tsx` bleibt ein dünner Shell** (Store-Provider, Oberleiste, Docks+View-Router,
+- **Ziel:** `App.tsx` bleibt ein dünner Shell (Store-Provider, Oberleiste,
-  Statusleiste, Floating-Panels, Ressourcen-Overlay) — keine Geschäftslogik darin.
+  Docks+View-Router, Statusleiste, Floating-Panels, Ressourcen-Overlay) — keine
- **Globaler Zustand in einem Store** (`src/state/`, Slices: project/selection/view/layout).
+  Geschäftslogik darin. **Realität (Stand 2026-07-21):** `App.tsx` ist mit
-  Komponenten lesen Zustand über Store-Hooks statt Prop-Drilling.
+  ~7.100 Zeilen die grösste Datei des Projekts und enthält weiterhin
- **Features als eigene Module:** `src/views/` (View-Router-Teile), `src/editors/`
+  View-Umschaltung und Kontextmenü-Aufbau inline — die geplante Auslagerung
-  (Inline-Editoren), `src/menus/` (Kontextmenü-Builder), `src/panels/`, `src/ui/`.
+  nach `src/views/`/`src/menus/` (unten) ist **nie passiert**, siehe
  [STATUS.md](STATUS.md) §4.3. Neue, grössere Features sollten trotzdem nicht
  weiter in `App.tsx` wachsen; wo möglich in `src/panels/`, `src/editors/`
  oder ein neues Modul auslagern statt die Datei weiter zu vergrössern.
 - **Globaler Zustand in einem Store** (`src/state/`, eigener Store auf
  `useSyncExternalStore` — **kein** Zustand/Redux/Immer — mit Slices:
  project/history/selection/view/layout/site/notify). Komponenten lesen
  Zustand über `useStore(selector)` statt Prop-Drilling.
 - **Features als eigene Module:** `src/editors/` (Inline-Editoren),
  `src/panels/`, `src/ui/`. `src/views/` und `src/menus/` waren geplant, wurden
  aber nie angelegt — bei Bedarf gilt das als offener Aufräum-Punkt, nicht als
  bestehende Struktur.
 - Ziel: modular + parallel bearbeitbar (verschiedene Features ≠ dieselbe Datei).
  Siehe `docs/design/state-architecture.md`.
 ## UI-Konventionen
@@ -57,8 +69,10 @@ Rendern angewandt, nie in die Geometrie eingebacken.
 ## Arbeitsweise (für Beiträge)
- Substanzielle, mehrstufige Arbeit an **Subagenten** delegieren, wo möglich.
+- Substanzielle, mehrstufige Arbeit schrittweise in isolierten Schritten angehen.
 - Änderungen verifizieren: `npx tsc -b`, `npm run build`, und Screenshot via
  `node scripts/probe.mjs` (schreibt `scripts/probe.png`) bzw. `probe-ff*.mjs` für
  Firefox-Fälle. Screenshot ansehen und Geometrie visuell prüfen.
- Dev-Server läuft via `npm run dev` (Vite, Port 5173).
+- Dev-Server läuft via `npm run dev` (Vite, Port 5187). Nativer Rahmen
  plattformabhängig: `npm run tauri:dev` auf macOS, `npm run electron` auf Linux
  (WebKitGTK kann kein zuverlässiges WebGPU → dort Chromium/Electron).
@@ -1,7 +1,200 @@
 > **Hinweis (2026-07-21):** Dieser Block (Stand 07-09) ist nicht mehr der
 > neueste Stand — `git log`/[PENDENZEN.md](PENDENZEN.md) reichen bis 07-20/17.
 > Für den aktuellen Ist-Zustand siehe [STATUS.md](STATUS.md). HANDOVER.md bleibt
 > ein Append-Log (ältere Sessions unten); es wird nicht rückwirkend aktualisiert
 > — bei neuen Übergaben oben einen neuen Block ergänzen, nicht diesen editieren.
 # HANDOVER — Stand 2026-07-09 (autonome Session, ALLES committet)
 Lange autonome Session (Nutzer-Auftrag: „arbeite die Pendenzen/Funktionen durch,
 selbstständig committen, nicht mehr nachfragen"). **Abweichung vom bisherigen
 Protokoll: in dieser Session wurde committet** (ausdrücklich beauftragt). Keine
 KI-Spuren, deutsche Commits, keine Co-Authored-By-Trailer.
 ## Verifikations-Baseline (zuletzt grün)
 `npx tsc --noEmit` sauber · `npx vitest run` **620**. (Rust/WASM unverändert →
 kein Neubau nötig.) Der akkumulierte, über frühere Sessions gewachsene grüne
 Stand wurde zuerst als EIN Basis-Commit `3529930` gelandet, danach jedes Feature
 einzeln.
 ## In dieser Session gebaut + committet (neueste zuerst)
 - **Dächer** (`1195d2a` Modell+Geometrie, `31f2d63` Werkzeug+2D+3D): neues
  Roof-Element + `geometry/roof.ts` (roofGeometry für Flach/Pult/Sattel/Walm/
  Mansarde/Zelt, auf der Umriss-BBox, First entlang X/Y). Befehl „Dach" (BIM-
  Ribbon, Alias dach/rf): Rechteck aufziehen, Dachform als Inline-Option wählbar.
  2D-Plan (Traufe/First/Grat/Knick, generatePlan) + 3D-Flächen (emitRoofs,
  terrakotta). Demo-Satteldach RF1 im Seed. +19 Tests. **OFFEN (Folge-Increment):
  Auswahl/Attribut-Editieren/Löschen platzierter Dächer** (Form/Neigung/Überstand
  im Panel ändern, Klick-Auswahl, Delete) — mirror des Decken-Selektionspfads
  über ~12 App.tsx-Stellen + PlanView-Pick + selectionInfo + host + Panel.
 - **Fenster/Tür-Feedback** (`4beae72`, `89e737b`): (a) Fenster wirkten im 3D
  flach → Rahmen füllt jetzt die VOLLE Wanddicke (tiefe Laibung), Scheibe dünn
  mittig; Ursache war frameThickness (Profilbreite) fälschlich als Einbautiefe.
  (b) Detailgrad grob/mittel/fein wirkt jetzt auch im 3D (grob=Loch+Scheibe,
  mittel=Rahmen, fein=+Sprossen), durchgereicht bis projectToModel3d({detail}).
  (c) Fenster↔Tür-Umschalter im Objekt-Info entfernt (nur noch Anzeige).
  (d) **Kernursache „sieht im 3D gar nicht so aus": platzierte Öffnungen bekamen
  keinen typeId** → resolveOpeningFrame lieferte null → keine Rahmen. appendOpening
  weist jetzt den ersten Fenster-/Türtyp zu.
 - **Öffnung ⚙-Knopf** (`586c1c9`): springt in den Tür-/Fenstertyp-Editor.
 - **Decken-Griffe im 3D** (`973ac6d`): gewählte Decken haben im wgpu-Viewport
  Eckpunkt- + Kanten-Mittelpunkt-Griffe (rautenförmig) + Verschiebe-Griff →
  moveCeilingGrip/Edge/By. Prop-Kette Wasm3DViewport←Viewport3D←App. three.js-
  Sicht unverändert (Default wgpu). **Visuell noch NICHT in Tauri abgenommen.**
 - **Text-Styling-Leiste** (`d0b9d22`): selektierter Freitext/Textspalte ist jetzt
  Formatier-Ziel der Oberleiste (Schrift/fett/kursiv/Farbe via Drawing2D-Text.marks;
  Grösse bleibt über Modell-Höhe, nicht pt). generatePlan/PlanView rendern die Marks.
 - **Schichttrennlinie als Wand-Referenzlinie** (`938d642`): Wall.referenceOffset
  (freier Achsversatz) übersteuert left/center/right; Object-Info-Dropdown listet
  je interne Fuge einen Eintrag. wallReferenceOffset bleibt EINE Quelle (2D/Schnitt/3D).
 - **Mess-Werkzeug** (`492e1f8`): Polygonzug mit Länge + FLÄCHE (ab 3 Ecken),
  Live-Werte dauerhaft im Objekt-Info-Panel (ToolDraft.measure→PanelHost.measurement),
  Rechtsklick beendet Pfad + armiert neuen (mehrere nacheinander).
 - **Tür/Fenster tief** (`fa40429` Modell/Seeds/RM-Editor, `142ba7e` 2D, `9a65900` 3D):
  DoorType/WindowType um frameKind (Zarge/Blockrahmen), frameWidth, insetFromFace/
  insetFace (Schichteinzug), transomHeight (Oberlicht), mullionRows (Kämpfer)
  erweitert. 2D: opening-frame/-transom-Primitive. 3D: emitOpeningFrames (Rahmen/
  Sprossen/Kämpfer) + einzugs-/oberlicht-bewusste Scheiben. **3D visuell noch NICHT
  in Tauri abgenommen.**
 - **LICENSE** (`dbe7d37`): offizieller AGPL-3.0-Text von gnu.org.
 - **CSV-Element-Set (D2)** war bereits im Baseline-Stand vorhanden (verifiziert).
 - **window.prompt/confirm-Sweep**: keine offenen Vorkommen mehr (bereits sauber).
 ## Offene Fäden / bewusst NICHT gemacht
 1. **Tauri-Visualabnahme** der 3D-Änderungen (Tür/Fenster-Rahmen, Decken-Griffe)
   steht aus — Nutzer testet selbst (render3d/Viewport nicht browserverifizierbar).
 2. **Rechtsklick=Abbruch generell**: bewusst NICHT global von confirm→cancel
   umgestellt (würde Polylinien-Abschluss brechen); fürs Mess-Werkzeug via onConfirm
   gelöst (commit-frei → confirm≙abbruch).
 3. **Bauteil-Einstellungs-Button** (Discoverability: von der gewählten Öffnung in
   den RM-Typeditor springen) noch offen — Typeditor selbst ist über das
   Ressourcen-Fenster (Tür-/Fenstertypen-Tabs) erreichbar.
 4. Grosse Deferred-Items unverändert: 2D-Schnitt editierbar, Schnitt-Verschneidung
   (wartet auf `.obp`), Feld-Controller 3D, Schnitt/Ansicht Phase 3, truck-Live-Wiring.
 5. **Konventionen bleiben:** ab jetzt wieder Standard = NICHT committen, ausser der
   Nutzer beauftragt es erneut. Keine KI-Spuren.
 ---
 # HANDOVER — Stand 2026-07-08 spät (Schnitt-Parität + Projektdatei, ALLES uncommittet)
 Fortsetzungs-Session (nach dem älteren 2026-07-08-Handover weiter unten). **Alles uncommittet.** Schwerpunkt: 3D-Live-Schnitt = 2D-Schnitt + eigene Projektdatei.
 ## Verifikations-Baseline (zuletzt grün)
 `npx tsc --noEmit` sauber · `npx vitest run` **588** · `cargo test -p render3d --features render` **76** · `cargo check --features native3d` grün · WASM `npm run build:engine3d` neu gebaut (nötig nach Rust/WGSL-Änderungen). **Vor Weiterarbeit einmal `tsc`+`vitest` neu fahren.**
 ## Was diese Session gebaut wurde
 - **3D-Live-Schnitt = 2D-Schnitt (Kernfunktion):** (a) 45°-Schraffur-Verdrehung gefixt (Shader auf 2D-`parallelLines`-Konvention kalibriert, angle 0 = horizontal); (b) geschichteter Bodenaufbau (Decke per-Schicht statt Einkörper, `emitSlabs`); (c) **Prioritäts-Verschneidung** von 2D nach Rust portiert (`section_boolean.rs` = Port von `subtractDominantBands`/`subtractRect`; Bänder tragen `join_priority` via `CutBandMeta`); (d) `collectCeilingCutters` emittiert per-Schicht-Cutter → Backstein (50) schneidet Estrich/Dämmung (30/20) korrekt weg, nur Beton (100) kappt ihn; (e) **einstellbare Schichttrennlinien** aus `jointLineStyleId`; (f) **Schraffur-Strichstärke pro Hatch** aus deren `lineStyleId` (`hatch-hair` 0.02 / `thin` 0.13); (g) `relativeToWall`-Orientierung: Boden-Dämmung vertikal, Wand horizontal (via `resolveHatch(axisAngle)` wie 2D). Betrifft `src-tauri/render3d/src/{shaders,gpu,section,section_fill,section_boolean,types}.rs` + `src/plan/toWalls3d.ts`. `native.rs` `WallInput`-Literal um die additiven Felder ergänzt.
 - **Projekt als Einzeldatei `.obp`** („openbureau project"): `src/io/projectFile.ts` (`PROJECT_EXT`, nativer Öffnen/Speichern-Dialog, alte `.json` weiter ladbar) + **OS-Lock gegen Doppelöffnung** (`src-tauri/src/lock.rs`, `fs4` exklusiver flock über gehaltenes Handle → Auto-Freigabe bei Absturz/Exit; `LockConflictDialog`). QA: Lock-Logik korrekt, einzige Lücke: „schreibgeschützt" == „erzwingen" auf Datenebene (kein app-weiter Read-only-Modus).
 - **Identität:** Open-Source-CAAD statt „BIM für Wohnbau"; `about.desc` (de/en) + README + `package.json` (`license: AGPL-3.0-or-later`, `author`). **LICENSE-File fehlt noch** (README verlinkt darauf) — offizieller AGPL-Text muss rein (nicht fabrizieren; `curl gnu.org/licenses/agpl-3.0.txt`). About-Dialog-Umbruch gefixt (`.about-dialog { white-space: normal }` — er erbt `nowrap` von `.topbar`).
 - **2D:** Text-Platzierungswerkzeug als 2D-Element (`text`-Command + Freitext-Eingabe in der Command-Engine); 2D-Zeichenwerkzeuge auf `"drawing"`-Ebenen freigegeben (ToolsPanel-Gating = `floorOnly`, Parität mit Ribbon).
 - **Teil B — 2D-Annotationen auf Layout-Blättern:** `LayoutAnnotation` (line/rect/text in mm) + CRUD (`layoutModel.ts`) + Editor in `LayoutSheet.tsx` (zeichnen/selektieren/verschieben/löschen, `PromptDialog` für Text) + `layoutSheetMath.ts` (Hit-Tests). Bewusst ohne: Resize-Griffe, Text-Rotation, Snapping.
 ## Offene Fäden
 1. **Idee 1 — per-Wand „an Decke enden"** (Terminierung ≠ Priorität): AGENT LÄUFT gerade (per-Wand `sliceTermination`, Default off). Details/Design im Memory `design-schicht-verschneidung-3d-schnitt.md`. **Idee 2 (Schichteinzüge, per-Schicht Endversätze)** = größeres Folge-Feature, noch nicht gebaut.
 2. **Ressourcen-Fenster als eigenes OS-Fenster** (Nutzer-Wunsch): machbar (Tauri `WebviewWindow` + BroadcastChannel-Sync, „Ausklappen"-Button, Browser bleibt intern). Noch NICHT gebaut — braucht Store-Sync-Architektur-Entscheidung.
 3. **Visuelle Tauri-Abnahme** aller 3D-Schnitt-Änderungen steht aus (render3d nur naga-validiert + WASM gebaut; Nutzer testet selbst). Der Backstein hat prioritäts-korrekt noch ein Stück oberhalb des Betons — das ist Idee 1 (Option), nicht ein Bug.
 4. **Konventionen:** wie immer — keine KI-Spuren, nicht committen, disjunkte Agent-Lanes, echte Eigenschaft prüfen (nicht nur grüne Tests).
 ---
 # HANDOVER — Stand 2026-07-08 (Account-/Instanzwechsel, ALLES uncommittet)
 Übergabe an eine frische Instanz (Nutzer wechselt Account, Budget aufgebraucht). **Alles unten ist UNCOMMITTET** (Bearbeiter committet nie selbst). Zuerst `PENDENZEN.md` lesen (Single Source of Truth, ✅-Erledigt-Liste + offene Items ganz konkret). Diese Session war eine sehr lange Feature-/Fix-Serie mit vielen Sub-Agents.
 ## Verifikations-Baseline (zuletzt grün)
 `npx tsc --noEmit` sauber · `npx vitest run` **491/491** · `cargo check --manifest-path src-tauri/Cargo.toml` grün · `vite build` OK. (Der letzte Layout-Viewport-Agent meldete 491; nach dem interaktiven Ausschnitte-Fix waren es 465 → 491 ist der aktuelle Stand nach dem Layout-2b-Agenten.) **Vor Weiterarbeit einmal `tsc`+`vitest` neu fahren**, da alles uncommittet nebeneinander liegt.
 ## Was diese Session gebaut wurde (alles in PENDENZEN ✅ dokumentiert)
 - **Interop-Export:** IFC4 (`exportIfc.ts`, jetzt `IfcTriangulatedFaceSet` mit ausgeschnittenen Fenster/Tür-Löchern + SOLIDE Wände — Winding-Fix), STL+OBJ (`exportMesh.ts`), gemeinsamer Loch-Ausschnitt `src/plan/wallMeshCut.ts` (Port von render3d `extrude_layer_segment_with_holes`, `isWatertight` via Gauss/Volumen). Schnellexport-Dialog (`ExportSaveDialog`, Format+Name).
 - **Nativer Speichern-Dialog:** Tauri `plugin-dialog`+`plugin-fs` (Cargo/lib.rs/capabilities), `src/io/saveFile.ts` (`saveTextFile`: nativ unter Tauri, Blob-Fallback im Browser). App.tsx `downloadTextFile`→`saveTextFile`.
 - **Ausschnitte (View-Snapshots) Phase 1:** `Project.viewSnapshots`, `state/viewSnapshots.ts`, `ViewSnapshotsPanel` (Speicher-Fix: Inline-Input statt window.prompt).
 - **Layout-Blätter Phase 2a+2b:** Modell `Layout`/`LayoutViewport`/`MasterLayout` (`Project.layouts`/`masterLayouts`), In-Viewport-Editor (`activeLayoutId` in App.tsx → `LayoutSheetView`/`LayoutSheet.tsx`, Maus-Editing, `layoutSheetMath.ts`), `LayoutsPanel`. Floating `LayoutEditor` wurde ersetzt.
 - **Tragwerk-Stützen:** `Column`/`ColumnProfile`, `geometry/column.ts`, Platzieren/2D/3D/Selektion/Attribute/move.
 - **Weiteres:** A1 Override-Regel-Engine, kernel2d Phase 5 komplett, Bauteil-CSV volles Element-Set, SIA-416 AGF, Kamera-Presets Kardinal+Iso, Decken-UK/OK, BIM-Tree-Panel, ObjectInfo-Volumen, Basis-Material-Texturen, OSM 7 Kat., IndexedDB-Kern, Rich-Text super/sub, Auto-Zoom-Geo, Raumstempel Personen/Rundung, diverse TopBar-Feinschliffe (Export-Sammelmenü, Über-Dialog, Petrol-Punkt, Detailgrad+Darstellung gestapelt, Arbeitsumgebung in Settings).
 ## ⚠️ WICHTIG / offene Fäden (Details in PENDENZEN, Abschnitt „In Arbeit"/oben)
 1. **NOCH NICHTS VISUELL IN TAURI ABGENOMMEN:** IFC/OBJ/STL-Geometrie, nativer Speichern-Dialog, Layout-im-Viewport, Ausschnitte — alle agent-/testverifiziert, aber der Nutzer hat sie im laufenden Fenster noch NICHT gesehen. **Tauri-Dev NEU STARTEN** (`npm run tauri:dev`, ggf. Vite separat auf Port 5187 — es gibt KEIN `beforeDevCommand`) wegen der neuen Rust-Plugins.
 2. **`window.prompt`/`confirm`-SWEEP:** in Tauri-WKWebView DEAKTIVIERT (→ null). Gefixt: ViewSnapshotsPanel, LayoutsPanel. NOCH betroffen: `ComboMenu` (Kombinationen speichern), TopBar Massstab „frei" (`topbar.scale.prompt`), evtl. weitere. Grep `window.prompt|window.confirm` über `src/`, alle auf Inline-Eingaben umstellen.
 3. **NÄCHSTES GROSSES ITEM (fertig gescoped, war startbereit als Opus-Agent):** „Layouts als Ordner-/Baumstruktur" — voller Auftrag steht in PENDENZEN (Ordner-Baum, ein „＋" für Ordner/Layout/Masterlayout, Inline-Rename, Layout-Erstell-Dialog mit Master-Vorlage/freie Grösse, Masterlayout mit Grössenwahl, Ordner→Mehrseiten-PDF). Direkt umsetzbar.
 4. **Konventionen:** keine Fremd-Tool-Spuren/Co-Authored-By im Repo; Sub-Agents in disjunkte Datei-Lanes schicken (i18n de.ts/en.ts + App.tsx sind Hotspots → exklusiv EINEM Agent pro Welle, sonst NUL-Byte-Kollision); grüne Tests NICHT als alleinigen Beweis nehmen (echte Eigenschaft prüfen — z. B. beim IFC-Solidity-Fix war der naive Manifold-Test falsch, Gauss/Volumen war richtig).
 ---
 # HANDOVER — Stand 2026-07-07 abends (Instanzwechsel, alles uncommittet)
 Übergabe an eine frische Instanz (Nutzer wechselt bewusst die Instanz). **Alles unten Gelistete ist NOCH UNCOMMITTET** — Bearbeiter committet laut Arbeitsprotokoll nicht selbst. Zuerst `CONVENTIONS.md` + `PENDENZEN.md` lesen (dort steht die volle, aktuelle Aufgaben-Historie inkl. aller Details der truck-Integration/Deep-Review-Fixes unten — hier nur die Kurzfassung + der offene Faden).
 ## Sofort-Kontext für die neue Instanz
 **Environment:** macOS-Gerät, Toolchain vollständig (node/npm/cargo/wasm-pack), `npm run tauri:build` läuft. Kein Blocker.
 **Verifikations-Baseline (zuletzt geprüft, alles grün):** `npx tsc --noEmit` sauber · `npx vitest run` 341/341 · `cargo test` in `src-tauri/trucksolid` 15/15 · `cargo test --manifest-path src-tauri/Cargo.toml -p render3d` 58/58.
 **Was in dieser Session geschah (chronologisch, Details je in PENDENZEN.md „truck-Integration" Phase 5 / Backlog):**
 1. Vorherige Session ist wegen RAM-Absturz des Geräts abgebrochen (lief eine LOKALE LLM auf dem Laptop, nicht diese Instanz) — Stand war: truck-Integration Phasen 1–4 fertig (Extrusion + Verjüngung/Taper + Boolean-CSG via `csgrs`), aber noch uncommittet.
 2. Diese Instanz hat den übernommenen Stand **deep-reviewt** (8-Winkel-Review: Korrektheit/Reuse/Simplify/Efficiency/Altitude/Conventions) und mehrere echte Bugs gefunden + gefixt — volle Liste in PENDENZEN.md unter „truck-Integration" → „Deep-Review + Fixes (2026-07-07)": konkave Profil-Triangulierung (Fächer→Ohr-Clipping), 6 fehlende Selektions-Resets für Extrusionen, Mirror/Copy ignorierten Extrusions-Auswahl, DXF-Export verlor den Layer, `truckMeshCache`-Leak + Flacker-Bug, unnötige `fitTargetDist`-Neuberechnung, fehlende i18n (Schnittebene-Button + Farbwähler-Tooltip).
 3. Danach auf Nutzer-Wunsch **eigenständig durch PENDENZEN.md** gearbeitet (nur unblockierte Items, keine Design-Entscheidungen geraten): **Ortho-Ray-Picking gefixt** (`cameraRay` in `src/viewport/raycast3d.ts` konnte nur perspektivisch — jetzt echte parallele Strahlen bei `perspective:false`, rückwärtskompatibel; +2 Tests). Siehe PENDENZEN.md „3D-REST" Abschnitt.
 ## ✅ ERLEDIGT 2026-07-07 (Folge-Instanz) — Bauteil-CSV volles Element-Set (D2, vertieft A6), umgesetzt exakt nach dem Scope unten; Treppen-Fläche = null (leer), Aggregat-Zellen leer statt 0.00. Details/Status in PENDENZEN.md „✅ Erledigt".
 `src/export/exportSchedule.ts` deckt aktuell nur **Wand + Decke** ab (Muster: `evalWall`/`evalCeiling` → `ScheduleRow`, siehe Datei). PENDENZEN-Backlog-Item „AUDIT (DOSSIER-Studie)" nennt D2 = „Bauteil-CSV mit vollem Element-Set". Ich habe das untersucht und **bewusst gescoped, aber NICHT umgesetzt** (Instanzwechsel kam dazwischen) — der Datei-Zustand ist unverändert/clean (ein Testballon-Import wurde wieder entfernt, `tsc` ist grün). Damit die nächste Instanz nicht neu recherchieren muss, hier die bereits getroffenen, gut begründeten Scope-Entscheidungen:
 - **Aufnehmen:** `Door` (Tür), `Opening` (kind="window"→Fenster, kind="door"→Öffnung), `Stair` (Treppe), `ExtrudedSolid` (Extrusion, aus der truck-Integration).
 - **NICHT aufnehmen: `Room`** — Räume haben bereits einen eigenen, dedizierten CSV-Export (`roomsToCsv` in `src/geometry/roomArea.ts`, SIA-Flächenbilanz-Spalten). Eine zweite Raum-Zeile in der allgemeinen Bauteilliste wäre Duplikation.
 - **Spalten-Mapping** (bestehende feste Header „Länge/Höhe/Dicke/Fläche" — nur dort füllen, wo eine Ableitung wirklich verlässlich ist, sonst leer lassen wie es `evalCeiling` heute schon für Decken macht):
  - Door/Opening: `length = width` (lichte Breite), `heightM = height`, `thickness = null` (keine sinnvolle Entsprechung), `area = width * height`. Geschoss auflösen über `hostWallId` → `project.walls.find(w => w.id === hostWallId)?.floorId` (neuer kleiner Helper nötig, Wand evtl. verwaist behandeln wie bei `evalWall`/`evalCeiling`).
  - Stair: `length = runLength + (run2Length ?? 0)` (Näherung, bei Wendel evtl. wenig aussagekräftig — akzeptabel, da nur „verlässlich Ableitbares" Anspruch gilt), `heightM = stair.totalRise ?? null` (KEINE Geschosshöhen-Fallback-Auflösung nachbauen — Kopplung/Risiko vermeiden), `thickness = null`, `area`: **noch nicht entschieden** — eine echte Footprint-Fläche bräuchte `geometry/stair.ts`s `stairGeometry()` (Kopplung an Geschoss-Höhen-Fallback) → einfachster sicherer Weg ist vermutlich `area = null` lassen (ehrlich statt erfunden), aber nochmal gegen die bestehenden Tests/Konventionen prüfen, bevor final entschieden wird.
  - ExtrudedSolid: `typeName = "Extrusion"`, Geschoss über `levelId`, `length = null`, `heightM = solid.height`, `thickness = null`, `area = polygonArea(solid.points)` (Import aus `geometry/roomArea.ts`, bereits im File importiert).
  - Neue `kind`-Werte in `ScheduleRow`/`TypeAggregate`: `"Tür" | "Fenster" | "Öffnung" | "Treppe" | "Extrusion"` zusätzlich zu `"Wand" | "Decke"`.
 - **Aggregat-Zeile (`aggregateByType`/Summary-Block):** die bestehende Zeile `fmtNum(agg.kind === "Wand" ? agg.totalLength : null)` sollte verallgemeinert werden zu `agg.totalLength > 0 ? fmtNum(agg.totalLength) : ""` — dann zeigen Tür/Fenster/Öffnung/Treppe (die jetzt auch eine `length`-Spalte befüllen) automatisch korrekt eine Summe, während Decke/Extrusion (deren `length` immer `null`→0 bleibt) weiterhin korrekt leer bleiben. Kein Sonderfall pro Kind nötig.
 - **Tests:** `src/export/exportSchedule.test.ts` folgt einem klaren `fixtureProject()`-Muster (2 Wände + 1 Decke) — beim Erweitern eine Tür/ein Fenster/eine Treppe/eine Extrusion in die Fixture aufnehmen und je einen Zeilen-Assert wie bei den bestehenden Wand-/Decken-Zeilen ergänzen.
 - Warum nicht in dieser Session fertig: Instanzwechsel kam mitten in der Umsetzung. **Kein Blocker, keine Nutzer-Entscheidung nötig** — reine Fleissarbeit nach obigem Schema, dann `tsc`/`vitest` grün prüfen und in PENDENZEN.md abhaken.
 ## Aus dieser Session bewusst NICHT angefasst (recherchiert, aber zu unsicher/blockiert)
 - **Treppe Pfeil-Style „filled" + Tür `swing_invert`/`aussenseite`** (PENDENZEN „BAUTEILE… Gruppe B"): die Referenzquelle (`/tmp/dossier-ref/rhino/*.py`) existiert auf **diesem** Gerät/dieser Session NICHT (geprüft, `find` liefert nichts) — ohne das exakte Rhino-Verhalten zu kennen, wäre die visuelle Ausgestaltung geraten. Nicht angefasst, um nicht falsch zu raten.
 - **E2b Schraffur-Kachel-Motiv:** `MotifEditor` (`src/ui/MotifEditor.tsx`) wird schon für Linienstil-Motive wiederverwendet (1D, entlang einer Linie) — ein Flächen-Kachel-Motiv für `HatchStyle` wäre ein NEUES Datenmodell (2D-Tile-Grid), kein reines Wiederverwenden. Braucht eigentlich einen Scope-Entscheid.
 - Alles, was in PENDENZEN.md explizit „Mit Nutzer klären"/„Nutzer-Entscheid nötig" trägt (Ribbon 3D-Tab, kernel2d Phase 6, Feld-Controller, Schnitt/Ansicht Phase 3, Teamwork-Granularität, Geo-Block-Priorität, Textur-Pipeline-Scope, STRATEGIE-Priorisierung, Bildschraffur-Freigabe) — bewusst übersprungen, nicht neu bewertet.
 ## Wichtige Memory-Notiz (persistiert, gilt für zukünftige Instanzen dieses Repos)
 Der Nutzer lässt teils eine **lokale LLM auf seinem Laptop autonom** an diesem Projekt arbeiten (kann abstürzen, z. B. RAM). Deren Output sah in dieser Session strukturell sauber + gut getestet aus, enthielt aber einen echten geometrischen Bug (Fächer-Triangulierung bricht bei konkaven Profilen), den die eigene Testsuite NICHT gefangen hatte (Tests prüften nur Form/Anzahl, nicht geometrische Korrektheit). **Bei Übernahme von Arbeit aus solchen Sessions: grüne Tests allein NICHT als Beweis nehmen, gezielt nachprüfen ob die Tests die richtige Eigenschaft testen.**
 ---
 # HANDOVER — Stand 2026-07-04 (Schraffur/Linien-Epic + Folgethemen)
 Übergabe an eine frische Instanz. Alles unten Gelistete ist committet, sofern nicht anders vermerkt. Ältere Handover-Stände (< 2026-07-04) siehe git-Historie. Zuerst `CONVENTIONS.md` lesen.
 > **➡️ Aufgaben-Queue steht in `PENDENZEN.md`** (Single Source of Truth, priorisierte Checkliste + Arbeitsprotokoll). HANDOVER = nur noch Kontext/Konventionen/Environment/Zielmodelle, KEIN Backlog mehr. Neue Pendenzen/Rückfragen dort eintragen, nicht hier.
 ## ⚠️ NACHTRAG 2026-07-04 abends — Unterbruch, 3 Slices verloren
 > **STAND-UPDATE (Session 4, neues Gerät):** **Environment behoben** — Toolchain vorhanden (`node`/`npm`/`cargo` unter `/usr/bin`, `wasm-pack` via `npx` 0.15.0; es war die Flatpak-Sandbox); fehlendes Rust-Target per `sudo dnf install rust-std-static-wasm32-unknown-unknown` (+ lld) nachinstalliert; beide WASM-Engines gebaut → App läuft. **Slice 1 (Locked-Iso `cb8fae5`) + Slice 2 (Joins Phase 1c `c5a344d`) committet.** **Slice 3 (Öffnungen als Boolean-Löcher + Deckentrim-nur-3D) ✅ committet `1407c68`:** Fenster/Türen = 1 Wandkörper pro Schicht-Band mit rechteckigen `holes` (render3d stanzt sie per achsparalleler Rechteck-Gitter-Zerlegung + 4 Laibungsquads/Loch), Segment-Boxen weg; `holes`/`openings` schliessen sich im Emitter aus; Schnitt-Pfad (layered=false) segmentiert unverändert weiter. Deckentrim `trimWallTopForCeilings` gilt nur noch im 3D-Pfad, Schnitt-Pfad bekommt volle Wandhöhe. Alle Datei-Edits waren gelandet — unabhängig verifiziert: cargo test 56 (inkl. beider Pflicht-Tests versetzt-überlappende Fenster + Tür-Loch-bis-Boden), vitest 230, build:engine3d + tsc sauber, Trace clean. **Damit sind alle drei verlorenen 3b-Slices rekonstruiert.** **Memory-Direktiven `priority-based-joins.md` + `openings-as-booleans.md` wiederhergestellt.**
 >
 > **⚠️ PUSH BLOCKIERT:** keine Git-Credentials auf diesem Gerät (kein Helper, keine `~/.git-credentials`, kein SSH-Key; Remote HTTPS `git.openbureau.ch/karim/DOSSIER-STANDALONE`). `cb8fae5` + `c5a344d` (+ folgender Öffnungen-Commit) sind **lokal committet, NICHT gepusht** (`ahead of origin/master`). Sobald Gitea-PAT (repo-write) oder SSH-Key da ist: `git push origin master`. Bis dahin holt das andere Gerät die Arbeit nicht.
 >
 > Der folgende Block bleibt als historischer Kontext/Vorlage für den offenen Slice 3 stehen.
 Die Arbeit wurde unerwartet unterbrochen — mehrere Tasks liefen parallel. Diese Übergabe wurde nachträglich rekonstruiert. **Der tatsächliche HEAD-Commit ist `03f0c40`** (Nordstern-3D Live-Schnittebene) — alles danach existierte nur im Arbeitsbaum der alten Maschine und ist auf **diesem** Checkout (neues Gerät, `git status` sauber bis auf `package-lock.json`) **nicht vorhanden**. Diese drei Slices waren in echter Arbeit (nicht nur geplant) und gelten als verloren — neu beauftragen, nicht nur „prüfen ob gelandet":
 1. **Locked-Iso-Fix** (`src/viewport/Wasm3DViewport.tsx`, `OrbitState` um `ortho: boolean` + `orthoHalfHeight: number` erweitern, `orbitCamera()`/Preset-Effect/Pan/Zoom entsprechend anpassen) — Bug: Iso-Ansicht kippt bei der ersten Kamerabewegung sofort in Perspektive statt orthografisch (parallel) zu bleiben. War fertig gebaut und quantitativ verifiziert (Parallelogramm-Kantenvergleich vor/nach Orbit, 225/225 Tests grün), aber **nicht mehr committet**, bevor der Unterbruch kam. Kleinster, unabhängigster der drei Fixes — zuerst neu machen.
 2. **Joins Phase 1c — Durchgangswand echt aufbrechen** (`spanCutouts` in `src/model/joins.ts` + `src/plan/generatePlan.ts` + Rust-Parität `src-tauri/geometry/src/lib.rs`): Nutzer-Befund nach Phase 1b war, dass der Innenputz der DURCHGANGSWAND am T-Stoss nur überdeckt wird (Zeichenreihenfolge), nicht geometrisch ausgeschnitten — Fugen-/Nahflächenlinien laufen noch durch den Backstein-Durchstoss, es „liest" noch nicht wie ein einziger Join. Das war die **explizite Priorität des Nutzers** für diese Session. Die Umsetzung war weit fortgeschritten (schrieb bereits in `joins.ts`), dann abgebrochen. **Nicht committet, nicht im Baum.** Vollständige Aufgabenbeschreibung mit allen Datei:Zeile-Ankern steht im Transkript bei „Agent:Phase 1c: Durchgangswand aufbrechen" — 1:1 als Vorlage für den Neu-Auftrag wiederverwenden.
 3. **Öffnungen als echte Boolean-Löcher** (`RWall.holes`, `src/plan/toWalls3d.ts`, `src-tauri/render3d/src/mesh.rs`, additiv `types.rs`): EIN Wandkörper mit rechteckigen Löchern statt der heutigen Pfeiler/Brüstung/Sturz-Ersatzkörper (sichtbare Segment-Nähte, keine echten Löcher). Pflicht-Testfall (Nutzer-Direktive, Kernmotivation des Slices): zwei Fenster in derselben Wand mit überlappendem Achsen-Intervall, aber unterschiedlicher Höhe (z. B. u=[1.0,2.0]/z=[0.9,2.1] und u=[1.5,2.5]/z=[0.3,0.7]) — die alte Segment-Zerlegung kann das nicht abbilden, echte Löcher schon. Zusatz-Auftrag im selben Slice: `trimWallTopForCeilings` (Phase-3-Deckentrim, Commit `e4b8df6`) darf **nur** im 3D-Viewer-Pfad (`layeredWalls:true`) gelten, **nicht** im Schnitt-Pfad (`layeredWalls:false`) — der Schnitt braucht die volle, ungetrimmte Wandhöhe für seine eigene schichtweise Prioritäts-Subtraktion (`subtractDominantBands`), sonst zeigt der Schnitt die Wände fälschlich abgeschnitten. Fortschritt bei Abbruch **unklar** (letztes Status-Update deutete auf „noch in der Kartierungsphase" hin) — vermutlich am wenigsten weit von den dreien; komplett neu beauftragen. Vollständiger Auftragstext im Transkript bei „Agent:Oeffnungen als Boolean-Loecher" + die zwei Zusatz-Direktiven (Decken-Trim-Fix, Pflicht-Testfall versetzte Fenster) kurz danach.
 **Zwei Engine-Direktiven vom alten Stand fehlen** (`priority-based-joins.md`, `openings-as-booleans.md`): die in Punkt 2/3 beschriebenen Zielverhalten waren gesichert (u. a. „Trennlinien an Merge-Kontakten verschwinden immer", „Öffnungen dürfen nie wieder zu Segmenten vereinfacht werden"). Beim Neu-Beauftragen diese Direktiven wieder explizit festhalten.
 **Environment-Lücke auf diesem Gerät:** `node`/`npm`/`cargo`/`wasm-pack` waren zum Zeitpunkt dieser Übergabe **nicht auf dem PATH** (geprüft: kein Treffer, auch nicht unter der VSCodium-Flatpak-Datenlage). **Vermutliche Ursache: VSCodium lief als Flatpak** — Flatpak-Sandboxing blendet system-installierte Toolchains (Node/Rust unter `/usr/...` oder `~/.cargo`) typischerweise aus, auch wenn sie auf dem Host tatsächlich installiert sind. Der Nutzer wechselt gerade auf **natives VSCodium** (kein Flatpak mehr) — das könnte die Lücke von selbst beheben, MUSS aber nach dem Wechsel neu geprüft werden (`which node npm cargo wasm-pack`), bevor man von "Toolchain fehlt" auf "Toolchain neu installieren" schließt. Erst wenn nach dem Wechsel auf natives VSCodium immer noch nichts gefunden wird, wirklich neu installieren (Node LTS + Rust via rustup + `wasm-pack`, `npm install`, einmal `cargo build --manifest-path src-tauri/render3d/Cargo.toml` durchlaufen lassen). Ohne Toolchain ist die in `CONVENTIONS.md` vorgeschriebene Verifikation (`tsc`/`vitest`/`cargo test`/`wasm-pack`) nicht möglich — das zuerst klären, bevor einer der drei Slices neu beauftragt wird, sonst baut ein Agent blind ohne Verifikation.
 **Aufräum-Hinweis:** `Edit MEMORY md Added 1.txt` (lag unversioniert im Repo-Root) und die lokale `package-lock.json`-Änderung waren dirty/untracked. Die txt-Datei gehört nicht ins Repo — außerhalb verschieben oder löschen. `package-lock.json` prüfen (`git diff package-lock.json`) und nur committen, falls die Dependency-Änderung beabsichtigt ist.
 ### Empfohlene Reihenfolge zum Wiederaufsetzen
 1. Nach dem Wechsel auf natives VSCodium zuerst `which node npm cargo wasm-pack` prüfen — evtl. war es nur die Flatpak-Sandbox, die die Toolchain versteckt hat. Nur falls immer noch nichts gefunden wird: Node + Rust + wasm-pack installieren + `npm install`. Blocker für alles Weitere.
 2. Locked-Iso-Fix neu bauen (klein, unabhängig, Spezifikation im Transkript vollständig vorhanden).
 3. Joins Phase 1c (Nutzer-Priorität dieser Session) — Direktive zuerst wieder ins Memory schreiben, dann Agent mit dem Auftragstext aus dem Transkript beauftragen.
 4. Öffnungen als Boolean-Löcher + Deckentrim-nur-3D-Zusatz (dieselbe Rust-Crate wie Phase 1c — nacheinander, nicht parallel, wegen Datei-Overlap in `mesh.rs`/`toWalls3d.ts`).
 5. Repo aufräumen (txt-Datei raus, `package-lock.json` klären), danach diesen Abschnitt auf „erledigt" aktualisieren.
 ## NACHTRAG Session 3 (2026-07-04 mittags) — Prioritaets-Joins + Schnitt-Sanierung
 **Prioritäts-Join-Epic (Kern-Direktive, siehe unten „Verschneidungs-Zielmodell"):** Joins werden nach `Component.joinPriority` materialbewusst aufgelöst — konsistent in Grundriss, Schnitt UND 3D. Gelandet:
@@ -46,44 +239,17 @@
 WASM-Workflow: `src/engine/pkg3d/` ist gitignore't → nach Rust-Änderung `npm run build:engine3d`, nur die `.rs` committen. DOSSIER-Audit-Details jetzt in `docs/design/dossier-feature-audit.md` (A1–A6/B1–B4/C/D/E) + `ROADMAP.md` §11.
 ## Konventionen (ZWINGEND — zuerst lesen)
- **Keine KI-/Assistant-Spuren** im Repo: vor jedem Commit `git diff | grep -iE "claude|anthropic|opus|sonnet|generated with|co-authored|gpt|openai|assistant"` → muss leer sein. Commits deutsch, sachlich, KEINE Co-Authored-By-Trailer.
+- **Keine Fremd-Tool-Spuren** im Repo: vor jedem Commit Trace-Scan (`git diff | grep -iE "co-authored|generated with"`) → muss leer sein. Commits deutsch, sachlich, KEINE Co-Authored-By-Trailer.
 - **NICHT ANFASSEN (fremde WIP):** `.gitignore`, `public/assets/materials/manifest.json`, `src/materials/library.ts`, `scripts/fetch-materials.mjs` — bleiben dauerhaft dirty, nie stagen.
- **Agenten-Regeln:** Subagenten default **Sonnet** (Nutzer-Wunsch 2026-07-04); Opus nur bei intricater Geometrie. Agenten dürfen NICHT weiterdelegieren (Agent/Task-Tool verbieten — sonst Spawn-Schleifen), NICHT committen, keine Memory. Hauptinstanz verifiziert (`tsc --noEmit` clean + `vitest run`) + trace-scan, committet dann selbst, staged nur die Task-Dateien (Kollisionen: parallelen Agenten disjunkte Datei-Lanes geben; i18n exklusiv einem Agenten).
+- **Verifikation:** `tsc --noEmit` clean + `vitest run` + trace-scan vor jedem Commit. Nur Task-Dateien stagen (Kollisionen: parallele Tasks disjunkte Datei-Lanes geben; i18n exklusiv einem Task).
 - **Budget:** Session-Ende bei 98% — Sparflamme.
 - **Engine = „Nordstern"** (render2d/render3d/WASM). Referenz DOSSIER-Rhino: `https://git.openbureau.ch/karim/dossier` (Alias git.kgva.ch), geklont `/tmp/dossier-ref`.
 ## In dieser Session gelandet (Auswahl Commits)
 Schraffur/Linien-Epic komplett: Typmodell (vector/image Hatch, dash/zigzag/custom Line, Component Vordergrund/Hintergrund), ResourceManager **Master-Detail** (Schraffuren/Linien/Wandstile/Deckenstile, `9695748`), Rendering neuer Typen (Bild-`<pattern>`, random modellraum-verankert, Zickzack, Custom-Motiv-Editor `src/ui/MotifEditor.tsx`), modulares Linien-Segment-System (Strich/Punkt/Lücke), Attribut Vordergrund/Hintergrund + **By-Layer/By-Object-Quellen** (Nach Ebene/Bauteil/eigener Wert für Vordergrund/Hintergrund/Strichstärke/Schraffur, `d02781e`).
 Weiter: Gehrung spitze Winkel (2D+Schnitt+Rust), TopBar/Footer-Reorg, Zoom-% am Massstab, Tool-Shortcuts 1..0, Verschiebe-Dreieck flacher + Snap, Statusleiste „Nordstern", ResourceManager als **floating nicht-modales Fenster**, **swisstopo** Gebäude(extrudiert)+Terrain-Mesh in 3D (`f22970f`), Schnitt-Wandschicht-Orientierung (`7569524`), **Schnitt-Boolean-Dominanz** nach joinPriority (`23d81be`).
-## IN FLIGHT bei Session-Ende (PRÜFEN!)
+## Backlog & Rückfragen → `PENDENZEN.md`
- **Snap an Wand-Schichttrennlinien** (Agent Sonnet): sollte `src/tools/snapping.ts` (+ ggf. `src/model/geometry.ts` + Test) geändert haben. `git status` prüfen — falls dirty: `tsc`+`vitest`+trace, committen. Falls nicht gelandet: neu beauftragen (Schicht-Offsetlinien aus `addWallPoche`-Logik in generatePlan spiegeln [nur LESEN], als Snap-Targets in snapping.ts einspeisen).
+Der frühere „Offener Backlog"/„Offene Rückfragen"/„IN FLIGHT"-Abschnitt ist vollständig nach `PENDENZEN.md` migriert (Single Source of Truth). Dort steht auch das Arbeitsprotokoll.
 ## Offener Backlog (Priorität grob absteigend)
 1. **Zu verifizieren/klären**: 
   - Isometrie — „echte" orthographische Isometrie? (nicht perspektivisch; alle Längen gleich dargestellt?) — Status unklar.
   - TopBar Detailgrad — zoom% + zoom/scale komplett aus Footer? Details der Reorg prüfen.
   - DOSSIER Audit — welche Features konkret übernommen (über AUDIT Punkt 9 hinaus)?
 2. **Ebene-Schraffur editierbar**: „Nach Ebene"-Schraffur ist in der Resolve fertig, aber `LayerCategory.hatch` ist im Kategorie-Dialog (App.tsx ~3350, editiert nur name/color/lw) noch nicht editierbar. Kleine Folge-Arbeit.
 2. **GEO-BLOCK** (gemeinsame Dateien io/geoContext/swissTopo/terrain/ContextImportDialog/Viewport3D/siteSlice):
   - Reale Höhen + **Projekt-MüM**: Gebäude/Terrain sind auf z=0 (Terrain zentriert, Gebäude-Basis z=0). Nutzer will Projekt-Setting für MüM (EG-Referenzhöhe), Terrain georeferenziert bei realem z relativ dazu, Gebäude auf Terrain drapiert.
   - **Luftbild/SWISSIMAGE**-Orthofoto als Textur aufs Terrain-Mesh.
   - Importierte Geo-Elemente auf **aktives Geschoss** (`viewSlice.activeLevelId`) + eine **Gelände-Ebene**; Kontext liegt in `project.context` (siteSlice) ohne floorId/categoryCode.
   - **Nordstern-Geo-Rendering**: importierte Meshes (heute nur three.js `importedMesh`/`terrainMesh` in Viewport3D) auch in `projectToModel3d` einspeisen — Nordstern zeigt sie sonst nicht.
   - **3D-Mesh-DXF/DWG-Import** für präzise Gebäude (heute DXF nur 2D); Building-Draping; höhere DTM-Auflösung.
 3. **ResourceManager Bauteile-Tab** auf Master-Detail (wie Wandstile) — BEVOR Bauteil-Logik angefasst wird.
 4. **Einstellungs-Fenster**: Auswahlrahmen Default **Yuyake #CEB188**; Snap/Endpunkt Default = RÜCKFRAGE **„aki"** (nicht in Accents: Ajisai/Sakura/Suna/Ichigo/Yuyake/Sora/Kusa/Kori/Amagumo/Yuki); freier Picker + Accents-Presets; verdrahten in PlanView (Selektionsrahmen + Snap-Marker). Dazu Projekt-MüM-Feld.
 5. **Bildschraffur**: ambientCG/CGI-Colorfiles als Quelle (Material-Lib WIP — erst nach Freigabe); Bild-Filter Sättigung/Helligkeit/Kontrast/SW (`image.filters`).
 6. **E2b Schraffur-Kachel-Motiv** (MotifEditor für HatchStyle-Tile wiederverwenden).
 7. **Linienstile aufräumen** (Weight-only-Stile → „Volllinie", lineStyleId-Referenzen remappen).
 8. 2D-Plan z-Anordnen (Kombo-Schraffuren); Bild-Schraffur GL/DXF (heute Fallback).
 9. **AUDIT (DOSSIER-Studie)**: A1 Override-Regel-Engine; A2→A3 View-Snapshots → Print-Layout-Blätter (PDF pro Blatt); A5 reichere Öffnungen; B1 Text-Werkzeug (+ Kreis-Tool → Shortcuts 1&3); A4 Tragwerk; B2 Object-Info numerisch; A6 Bauteil-Schedule-CSV. Belege in `/tmp/dossier-ref/rhino/*.py`.
 10. Elemente im Schnitt anwählbar; render3d 2D-Schraffur auf 3D-Flächen.
 ## Offene Rückfragen
 - **„aki"** = welcher Accent für Snap/Endpunkt-Farbe.
 - Floating-ResourceManager „headless" = ganz ohne Titelleiste? (aktuell MIT).
 - Geo-Block: Projekt-MüM zuerst oder Nordstern-Geo-Rendering.
 ## Verifikation
 `npx tsc --noEmit` + `npx vitest run` (zuletzt 152 grün) + trace-scan vor jedem Commit.
@@ -0,0 +1,661 @@
                    GNU AFFERO GENERAL PUBLIC LICENSE
                       Version 3, 19 November 2007
 Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.
                            Preamble
  The GNU Affero General Public License is a free, copyleft license for
 software and other kinds of works, specifically designed to ensure
 cooperation with the community in the case of network server software.
  The licenses for most software and other practical works are designed
 to take away your freedom to share and change the works.  By contrast,
 our General Public Licenses are intended to guarantee your freedom to
 share and change all versions of a program--to make sure it remains free
 software for all its users.
  When we speak of free software, we are referring to freedom, not
 price.  Our General Public Licenses are designed to make sure that you
 have the freedom to distribute copies of free software (and charge for
 them if you wish), that you receive source code or can get it if you
 want it, that you can change the software or use pieces of it in new
 free programs, and that you know you can do these things.
  Developers that use our General Public Licenses protect your rights
 with two steps: (1) assert copyright on the software, and (2) offer
 you this License which gives you legal permission to copy, distribute
 and/or modify the software.
  A secondary benefit of defending all users' freedom is that
 improvements made in alternate versions of the program, if they
 receive widespread use, become available for other developers to
 incorporate.  Many developers of free software are heartened and
 encouraged by the resulting cooperation.  However, in the case of
 software used on network servers, this result may fail to come about.
 The GNU General Public License permits making a modified version and
 letting the public access it on a server without ever releasing its
 source code to the public.
  The GNU Affero General Public License is designed specifically to
 ensure that, in such cases, the modified source code becomes available
 to the community.  It requires the operator of a network server to
 provide the source code of the modified version running there to the
 users of that server.  Therefore, public use of a modified version, on
 a publicly accessible server, gives the public access to the source
 code of the modified version.
  An older license, called the Affero General Public License and
 published by Affero, was designed to accomplish similar goals.  This is
 a different license, not a version of the Affero GPL, but Affero has
 released a new version of the Affero GPL which permits relicensing under
 this license.
  The precise terms and conditions for copying, distribution and
 modification follow.
                       TERMS AND CONDITIONS
  0. Definitions.
  "This License" refers to version 3 of the GNU Affero General Public License.
  "Copyright" also means copyright-like laws that apply to other kinds of
 works, such as semiconductor masks.
  "The Program" refers to any copyrightable work licensed under this
 License.  Each licensee is addressed as "you".  "Licensees" and
 "recipients" may be individuals or organizations.
  To "modify" a work means to copy from or adapt all or part of the work
 in a fashion requiring copyright permission, other than the making of an
 exact copy.  The resulting work is called a "modified version" of the
 earlier work or a work "based on" the earlier work.
  A "covered work" means either the unmodified Program or a work based
 on the Program.
  To "propagate" a work means to do anything with it that, without
 permission, would make you directly or secondarily liable for
 infringement under applicable copyright law, except executing it on a
 computer or modifying a private copy.  Propagation includes copying,
 distribution (with or without modification), making available to the
 public, and in some countries other activities as well.
  To "convey" a work means any kind of propagation that enables other
 parties to make or receive copies.  Mere interaction with a user through
 a computer network, with no transfer of a copy, is not conveying.
  An interactive user interface displays "Appropriate Legal Notices"
 to the extent that it includes a convenient and prominently visible
 feature that (1) displays an appropriate copyright notice, and (2)
 tells the user that there is no warranty for the work (except to the
 extent that warranties are provided), that licensees may convey the
 work under this License, and how to view a copy of this License.  If
 the interface presents a list of user commands or options, such as a
 menu, a prominent item in the list meets this criterion.
  1. Source Code.
  The "source code" for a work means the preferred form of the work
 for making modifications to it.  "Object code" means any non-source
 form of a work.
  A "Standard Interface" means an interface that either is an official
 standard defined by a recognized standards body, or, in the case of
 interfaces specified for a particular programming language, one that
 is widely used among developers working in that language.
  The "System Libraries" of an executable work include anything, other
 than the work as a whole, that (a) is included in the normal form of
 packaging a Major Component, but which is not part of that Major
 Component, and (b) serves only to enable use of the work with that
 Major Component, or to implement a Standard Interface for which an
 implementation is available to the public in source code form.  A
 "Major Component", in this context, means a major essential component
 (kernel, window system, and so on) of the specific operating system
 (if any) on which the executable work runs, or a compiler used to
 produce the work, or an object code interpreter used to run it.
  The "Corresponding Source" for a work in object code form means all
 the source code needed to generate, install, and (for an executable
 work) run the object code and to modify the work, including scripts to
 control those activities.  However, it does not include the work's
 System Libraries, or general-purpose tools or generally available free
 programs which are used unmodified in performing those activities but
 which are not part of the work.  For example, Corresponding Source
 includes interface definition files associated with source files for
 the work, and the source code for shared libraries and dynamically
 linked subprograms that the work is specifically designed to require,
 such as by intimate data communication or control flow between those
 subprograms and other parts of the work.
  The Corresponding Source need not include anything that users
 can regenerate automatically from other parts of the Corresponding
 Source.
  The Corresponding Source for a work in source code form is that
 same work.
  2. Basic Permissions.
  All rights granted under this License are granted for the term of
 copyright on the Program, and are irrevocable provided the stated
 conditions are met.  This License explicitly affirms your unlimited
 permission to run the unmodified Program.  The output from running a
 covered work is covered by this License only if the output, given its
 content, constitutes a covered work.  This License acknowledges your
 rights of fair use or other equivalent, as provided by copyright law.
  You may make, run and propagate covered works that you do not
 convey, without conditions so long as your license otherwise remains
 in force.  You may convey covered works to others for the sole purpose
 of having them make modifications exclusively for you, or provide you
 with facilities for running those works, provided that you comply with
 the terms of this License in conveying all material for which you do
 not control copyright.  Those thus making or running the covered works
 for you must do so exclusively on your behalf, under your direction
 and control, on terms that prohibit them from making any copies of
 your copyrighted material outside their relationship with you.
  Conveying under any other circumstances is permitted solely under
 the conditions stated below.  Sublicensing is not allowed; section 10
 makes it unnecessary.
  3. Protecting Users' Legal Rights From Anti-Circumvention Law.
  No covered work shall be deemed part of an effective technological
 measure under any applicable law fulfilling obligations under article
 11 of the WIPO copyright treaty adopted on 20 December 1996, or
 similar laws prohibiting or restricting circumvention of such
 measures.
  When you convey a covered work, you waive any legal power to forbid
 circumvention of technological measures to the extent such circumvention
 is effected by exercising rights under this License with respect to
 the covered work, and you disclaim any intention to limit operation or
 modification of the work as a means of enforcing, against the work's
 users, your or third parties' legal rights to forbid circumvention of
 technological measures.
  4. Conveying Verbatim Copies.
  You may convey verbatim copies of the Program's source code as you
 receive it, in any medium, provided that you conspicuously and
 appropriately publish on each copy an appropriate copyright notice;
 keep intact all notices stating that this License and any
 non-permissive terms added in accord with section 7 apply to the code;
 keep intact all notices of the absence of any warranty; and give all
 recipients a copy of this License along with the Program.
  You may charge any price or no price for each copy that you convey,
 and you may offer support or warranty protection for a fee.
  5. Conveying Modified Source Versions.
  You may convey a work based on the Program, or the modifications to
 produce it from the Program, in the form of source code under the
 terms of section 4, provided that you also meet all of these conditions:
    a) The work must carry prominent notices stating that you modified
    it, and giving a relevant date.
    b) The work must carry prominent notices stating that it is
    released under this License and any conditions added under section
    7.  This requirement modifies the requirement in section 4 to
    "keep intact all notices".
    c) You must license the entire work, as a whole, under this
    License to anyone who comes into possession of a copy.  This
    License will therefore apply, along with any applicable section 7
    additional terms, to the whole of the work, and all its parts,
    regardless of how they are packaged.  This License gives no
    permission to license the work in any other way, but it does not
    invalidate such permission if you have separately received it.
    d) If the work has interactive user interfaces, each must display
    Appropriate Legal Notices; however, if the Program has interactive
    interfaces that do not display Appropriate Legal Notices, your
    work need not make them do so.
  A compilation of a covered work with other separate and independent
 works, which are not by their nature extensions of the covered work,
 and which are not combined with it such as to form a larger program,
 in or on a volume of a storage or distribution medium, is called an
 "aggregate" if the compilation and its resulting copyright are not
 used to limit the access or legal rights of the compilation's users
 beyond what the individual works permit.  Inclusion of a covered work
 in an aggregate does not cause this License to apply to the other
 parts of the aggregate.
  6. Conveying Non-Source Forms.
  You may convey a covered work in object code form under the terms
 of sections 4 and 5, provided that you also convey the
 machine-readable Corresponding Source under the terms of this License,
 in one of these ways:
    a) Convey the object code in, or embodied in, a physical product
    (including a physical distribution medium), accompanied by the
    Corresponding Source fixed on a durable physical medium
    customarily used for software interchange.
    b) Convey the object code in, or embodied in, a physical product
    (including a physical distribution medium), accompanied by a
    written offer, valid for at least three years and valid for as
    long as you offer spare parts or customer support for that product
    model, to give anyone who possesses the object code either (1) a
    copy of the Corresponding Source for all the software in the
    product that is covered by this License, on a durable physical
    medium customarily used for software interchange, for a price no
    more than your reasonable cost of physically performing this
    conveying of source, or (2) access to copy the
    Corresponding Source from a network server at no charge.
    c) Convey individual copies of the object code with a copy of the
    written offer to provide the Corresponding Source.  This
    alternative is allowed only occasionally and noncommercially, and
    only if you received the object code with such an offer, in accord
    with subsection 6b.
    d) Convey the object code by offering access from a designated
    place (gratis or for a charge), and offer equivalent access to the
    Corresponding Source in the same way through the same place at no
    further charge.  You need not require recipients to copy the
    Corresponding Source along with the object code.  If the place to
    copy the object code is a network server, the Corresponding Source
    may be on a different server (operated by you or a third party)
    that supports equivalent copying facilities, provided you maintain
    clear directions next to the object code saying where to find the
    Corresponding Source.  Regardless of what server hosts the
    Corresponding Source, you remain obligated to ensure that it is
    available for as long as needed to satisfy these requirements.
    e) Convey the object code using peer-to-peer transmission, provided
    you inform other peers where the object code and Corresponding
    Source of the work are being offered to the general public at no
    charge under subsection 6d.
  A separable portion of the object code, whose source code is excluded
 from the Corresponding Source as a System Library, need not be
 included in conveying the object code work.
  A "User Product" is either (1) a "consumer product", which means any
 tangible personal property which is normally used for personal, family,
 or household purposes, or (2) anything designed or sold for incorporation
 into a dwelling.  In determining whether a product is a consumer product,
 doubtful cases shall be resolved in favor of coverage.  For a particular
 product received by a particular user, "normally used" refers to a
 typical or common use of that class of product, regardless of the status
 of the particular user or of the way in which the particular user
 actually uses, or expects or is expected to use, the product.  A product
 is a consumer product regardless of whether the product has substantial
 commercial, industrial or non-consumer uses, unless such uses represent
 the only significant mode of use of the product.
  "Installation Information" for a User Product means any methods,
 procedures, authorization keys, or other information required to install
 and execute modified versions of a covered work in that User Product from
 a modified version of its Corresponding Source.  The information must
 suffice to ensure that the continued functioning of the modified object
 code is in no case prevented or interfered with solely because
 modification has been made.
  If you convey an object code work under this section in, or with, or
 specifically for use in, a User Product, and the conveying occurs as
 part of a transaction in which the right of possession and use of the
 User Product is transferred to the recipient in perpetuity or for a
 fixed term (regardless of how the transaction is characterized), the
 Corresponding Source conveyed under this section must be accompanied
 by the Installation Information.  But this requirement does not apply
 if neither you nor any third party retains the ability to install
 modified object code on the User Product (for example, the work has
 been installed in ROM).
  The requirement to provide Installation Information does not include a
 requirement to continue to provide support service, warranty, or updates
 for a work that has been modified or installed by the recipient, or for
 the User Product in which it has been modified or installed.  Access to a
 network may be denied when the modification itself materially and
 adversely affects the operation of the network or violates the rules and
 protocols for communication across the network.
  Corresponding Source conveyed, and Installation Information provided,
 in accord with this section must be in a format that is publicly
 documented (and with an implementation available to the public in
 source code form), and must require no special password or key for
 unpacking, reading or copying.
  7. Additional Terms.
  "Additional permissions" are terms that supplement the terms of this
 License by making exceptions from one or more of its conditions.
 Additional permissions that are applicable to the entire Program shall
 be treated as though they were included in this License, to the extent
 that they are valid under applicable law.  If additional permissions
 apply only to part of the Program, that part may be used separately
 under those permissions, but the entire Program remains governed by
 this License without regard to the additional permissions.
  When you convey a copy of a covered work, you may at your option
 remove any additional permissions from that copy, or from any part of
 it.  (Additional permissions may be written to require their own
 removal in certain cases when you modify the work.)  You may place
 additional permissions on material, added by you to a covered work,
 for which you have or can give appropriate copyright permission.
  Notwithstanding any other provision of this License, for material you
 add to a covered work, you may (if authorized by the copyright holders of
 that material) supplement the terms of this License with terms:
    a) Disclaiming warranty or limiting liability differently from the
    terms of sections 15 and 16 of this License; or
    b) Requiring preservation of specified reasonable legal notices or
    author attributions in that material or in the Appropriate Legal
    Notices displayed by works containing it; or
    c) Prohibiting misrepresentation of the origin of that material, or
    requiring that modified versions of such material be marked in
    reasonable ways as different from the original version; or
    d) Limiting the use for publicity purposes of names of licensors or
    authors of the material; or
    e) Declining to grant rights under trademark law for use of some
    trade names, trademarks, or service marks; or
    f) Requiring indemnification of licensors and authors of that
    material by anyone who conveys the material (or modified versions of
    it) with contractual assumptions of liability to the recipient, for
    any liability that these contractual assumptions directly impose on
    those licensors and authors.
  All other non-permissive additional terms are considered "further
 restrictions" within the meaning of section 10.  If the Program as you
 received it, or any part of it, contains a notice stating that it is
 governed by this License along with a term that is a further
 restriction, you may remove that term.  If a license document contains
 a further restriction but permits relicensing or conveying under this
 License, you may add to a covered work material governed by the terms
 of that license document, provided that the further restriction does
 not survive such relicensing or conveying.
  If you add terms to a covered work in accord with this section, you
 must place, in the relevant source files, a statement of the
 additional terms that apply to those files, or a notice indicating
 where to find the applicable terms.
  Additional terms, permissive or non-permissive, may be stated in the
 form of a separately written license, or stated as exceptions;
 the above requirements apply either way.
  8. Termination.
  You may not propagate or modify a covered work except as expressly
 provided under this License.  Any attempt otherwise to propagate or
 modify it is void, and will automatically terminate your rights under
 this License (including any patent licenses granted under the third
 paragraph of section 11).
  However, if you cease all violation of this License, then your
 license from a particular copyright holder is reinstated (a)
 provisionally, unless and until the copyright holder explicitly and
 finally terminates your license, and (b) permanently, if the copyright
 holder fails to notify you of the violation by some reasonable means
 prior to 60 days after the cessation.
  Moreover, your license from a particular copyright holder is
 reinstated permanently if the copyright holder notifies you of the
 violation by some reasonable means, this is the first time you have
 received notice of violation of this License (for any work) from that
 copyright holder, and you cure the violation prior to 30 days after
 your receipt of the notice.
  Termination of your rights under this section does not terminate the
 licenses of parties who have received copies or rights from you under
 this License.  If your rights have been terminated and not permanently
 reinstated, you do not qualify to receive new licenses for the same
 material under section 10.
  9. Acceptance Not Required for Having Copies.
  You are not required to accept this License in order to receive or
 run a copy of the Program.  Ancillary propagation of a covered work
 occurring solely as a consequence of using peer-to-peer transmission
 to receive a copy likewise does not require acceptance.  However,
 nothing other than this License grants you permission to propagate or
 modify any covered work.  These actions infringe copyright if you do
 not accept this License.  Therefore, by modifying or propagating a
 covered work, you indicate your acceptance of this License to do so.
  10. Automatic Licensing of Downstream Recipients.
  Each time you convey a covered work, the recipient automatically
 receives a license from the original licensors, to run, modify and
 propagate that work, subject to this License.  You are not responsible
 for enforcing compliance by third parties with this License.
  An "entity transaction" is a transaction transferring control of an
 organization, or substantially all assets of one, or subdividing an
 organization, or merging organizations.  If propagation of a covered
 work results from an entity transaction, each party to that
 transaction who receives a copy of the work also receives whatever
 licenses to the work the party's predecessor in interest had or could
 give under the previous paragraph, plus a right to possession of the
 Corresponding Source of the work from the predecessor in interest, if
 the predecessor has it or can get it with reasonable efforts.
  You may not impose any further restrictions on the exercise of the
 rights granted or affirmed under this License.  For example, you may
 not impose a license fee, royalty, or other charge for exercise of
 rights granted under this License, and you may not initiate litigation
 (including a cross-claim or counterclaim in a lawsuit) alleging that
 any patent claim is infringed by making, using, selling, offering for
 sale, or importing the Program or any portion of it.
  11. Patents.
  A "contributor" is a copyright holder who authorizes use under this
 License of the Program or a work on which the Program is based.  The
 work thus licensed is called the contributor's "contributor version".
  A contributor's "essential patent claims" are all patent claims
 owned or controlled by the contributor, whether already acquired or
 hereafter acquired, that would be infringed by some manner, permitted
 by this License, of making, using, or selling its contributor version,
 but do not include claims that would be infringed only as a
 consequence of further modification of the contributor version.  For
 purposes of this definition, "control" includes the right to grant
 patent sublicenses in a manner consistent with the requirements of
 this License.
  Each contributor grants you a non-exclusive, worldwide, royalty-free
 patent license under the contributor's essential patent claims, to
 make, use, sell, offer for sale, import and otherwise run, modify and
 propagate the contents of its contributor version.
  In the following three paragraphs, a "patent license" is any express
 agreement or commitment, however denominated, not to enforce a patent
 (such as an express permission to practice a patent or covenant not to
 sue for patent infringement).  To "grant" such a patent license to a
 party means to make such an agreement or commitment not to enforce a
 patent against the party.
  If you convey a covered work, knowingly relying on a patent license,
 and the Corresponding Source of the work is not available for anyone
 to copy, free of charge and under the terms of this License, through a
 publicly available network server or other readily accessible means,
 then you must either (1) cause the Corresponding Source to be so
 available, or (2) arrange to deprive yourself of the benefit of the
 patent license for this particular work, or (3) arrange, in a manner
 consistent with the requirements of this License, to extend the patent
 license to downstream recipients.  "Knowingly relying" means you have
 actual knowledge that, but for the patent license, your conveying the
 covered work in a country, or your recipient's use of the covered work
 in a country, would infringe one or more identifiable patents in that
 country that you have reason to believe are valid.
  If, pursuant to or in connection with a single transaction or
 arrangement, you convey, or propagate by procuring conveyance of, a
 covered work, and grant a patent license to some of the parties
 receiving the covered work authorizing them to use, propagate, modify
 or convey a specific copy of the covered work, then the patent license
 you grant is automatically extended to all recipients of the covered
 work and works based on it.
  A patent license is "discriminatory" if it does not include within
 the scope of its coverage, prohibits the exercise of, or is
 conditioned on the non-exercise of one or more of the rights that are
 specifically granted under this License.  You may not convey a covered
 work if you are a party to an arrangement with a third party that is
 in the business of distributing software, under which you make payment
 to the third party based on the extent of your activity of conveying
 the work, and under which the third party grants, to any of the
 parties who would receive the covered work from you, a discriminatory
 patent license (a) in connection with copies of the covered work
 conveyed by you (or copies made from those copies), or (b) primarily
 for and in connection with specific products or compilations that
 contain the covered work, unless you entered into that arrangement,
 or that patent license was granted, prior to 28 March 2007.
  Nothing in this License shall be construed as excluding or limiting
 any implied license or other defenses to infringement that may
 otherwise be available to you under applicable patent law.
  12. No Surrender of Others' Freedom.
  If conditions are imposed on you (whether by court order, agreement or
 otherwise) that contradict the conditions of this License, they do not
 excuse you from the conditions of this License.  If you cannot convey a
 covered work so as to satisfy simultaneously your obligations under this
 License and any other pertinent obligations, then as a consequence you may
 not convey it at all.  For example, if you agree to terms that obligate you
 to collect a royalty for further conveying from those to whom you convey
 the Program, the only way you could satisfy both those terms and this
 License would be to refrain entirely from conveying the Program.
  13. Remote Network Interaction; Use with the GNU General Public License.
  Notwithstanding any other provision of this License, if you modify the
 Program, your modified version must prominently offer all users
 interacting with it remotely through a computer network (if your version
 supports such interaction) an opportunity to receive the Corresponding
 Source of your version by providing access to the Corresponding Source
 from a network server at no charge, through some standard or customary
 means of facilitating copying of software.  This Corresponding Source
 shall include the Corresponding Source for any work covered by version 3
 of the GNU General Public License that is incorporated pursuant to the
 following paragraph.
  Notwithstanding any other provision of this License, you have
 permission to link or combine any covered work with a work licensed
 under version 3 of the GNU General Public License into a single
 combined work, and to convey the resulting work.  The terms of this
 License will continue to apply to the part which is the covered work,
 but the work with which it is combined will remain governed by version
 3 of the GNU General Public License.
  14. Revised Versions of this License.
  The Free Software Foundation may publish revised and/or new versions of
 the GNU Affero General Public License from time to time.  Such new versions
 will be similar in spirit to the present version, but may differ in detail to
 address new problems or concerns.
  Each version is given a distinguishing version number.  If the
 Program specifies that a certain numbered version of the GNU Affero General
 Public License "or any later version" applies to it, you have the
 option of following the terms and conditions either of that numbered
 version or of any later version published by the Free Software
 Foundation.  If the Program does not specify a version number of the
 GNU Affero General Public License, you may choose any version ever published
 by the Free Software Foundation.
  If the Program specifies that a proxy can decide which future
 versions of the GNU Affero General Public License can be used, that proxy's
 public statement of acceptance of a version permanently authorizes you
 to choose that version for the Program.
  Later license versions may give you additional or different
 permissions.  However, no additional obligations are imposed on any
 author or copyright holder as a result of your choosing to follow a
 later version.
  15. Disclaimer of Warranty.
  THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
 APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
 HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
 OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
 THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
 IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
 ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
  16. Limitation of Liability.
  IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
 WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
 THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
 GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
 USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
 DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
 PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
 EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
 SUCH DAMAGES.
  17. Interpretation of Sections 15 and 16.
  If the disclaimer of warranty and limitation of liability provided
 above cannot be given local legal effect according to their terms,
 reviewing courts shall apply local law that most closely approximates
 an absolute waiver of all civil liability in connection with the
 Program, unless a warranty or assumption of liability accompanies a
 copy of the Program in return for a fee.
                     END OF TERMS AND CONDITIONS
            How to Apply These Terms to Your New Programs
  If you develop a new program, and you want it to be of the greatest
 possible use to the public, the best way to achieve this is to make it
 free software which everyone can redistribute and change under these terms.
  To do so, attach the following notices to the program.  It is safest
 to attach them to the start of each source file to most effectively
 state the exclusion of warranty; and each file should have at least
 the "copyright" line and a pointer to where the full notice is found.
    <one line to give the program's name and a brief idea of what it does.>
    Copyright (C) <year>  <name of author>
    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU Affero General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.
    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU Affero General Public License for more details.
    You should have received a copy of the GNU Affero General Public License
    along with this program.  If not, see <https://www.gnu.org/licenses/>.
 Also add information on how to contact you by electronic and paper mail.
  If your software can interact with users remotely through a computer
 network, you should also make sure that it provides a way for users to
 get its source.  For example, if your program is a web application, its
 interface could display a "Source" link that leads users to an archive
 of the code.  There are many ways you could offer source, and different
 solutions will be better for different programs; see section 13 for the
 specific requirements.
  You should also get your employer (if you work as a programmer) or school,
 if any, to sign a "copyright disclaimer" for the program, if necessary.
 For more information on this, and how to apply and follow the GNU AGPL, see
 <https://www.gnu.org/licenses/>.
@@ -0,0 +1,300 @@
 # PENDENZEN — Aufgaben-Queue (Single Source of Truth)
 > **Diese Datei ist die einzige verbindliche Aufgabenliste.** HANDOVER.md enthält nur
 > noch Kontext/Konventionen/Environment/Zielmodelle — keinen Backlog mehr.
 ## Arbeitsprotokoll (ZWINGEND)
 **Bearbeiter:**
 1. **Zuerst diese Datei lesen**, dann `CONVENTIONS.md` + verlinkte Detailquellen des Items.
 2. Oberstes nicht-blockiertes Item aus **🔧 In Arbeit** bzw. sonst **⏭️ Als Nächstes** nehmen, **fertig** machen, verifizieren (`npx tsc --noEmit` + `npx vitest run` + trace-scan), abhaken, eine Ergebniszeile nach **✅ Erledigt** schreiben (mit Commit-Hash, sobald committet).
 3. **Rückfrage-Recht:** Bei Unklarheit/Design-Entscheid NICHT raten — Item mit `❓` markieren, kurze Frage darunter notieren, nächstes freies Item nehmen. Fragen sammeln sich unter **❓ Offene Rückfragen**.
 4. **Kein Arbeitsschritt endet ohne aktualisierte Liste.** Status hier ist immer aktuell, sonst driftet es wieder.
 5. Bearbeiter **committet nicht selbst** und delegiert Unteraufgaben nicht weiter.
 **Planer** (mit dem Nutzer, kuratiert):
 - Nimmt Nutzer-Feedback, pflegt daraus die Liste (rein/umpriorisieren/aufspalten). Führt selbst keine Queue-Items aus.
 - Prüft **❓**-Zeilen mit dem Nutzer, wandelt sie in konkrete Items.
 ---
 ## ⛔ Blocker (zuerst klären)
 - [x] ~~**Toolchain prüfen**~~ — **ERLEDIGT 2026-07-04 (macOS-Gerät):** `node`/`npm`/`cargo` (1.96.0)/`wasm-pack` (0.15.0) alle vorhanden. `npm install` + `npm approve-scripts esbuild wasm-pack …` (npm gated Install-Scripts → `allowScripts`-Block in `package.json`, ungetrackt gelassen), `rustup target add wasm32-unknown-unknown`, beide WASM-Engines gebaut, Frontend gebaut, **`npm run tauri:build` → Mac-App (`cad.app` + `cad_0.1.0_aarch64.dmg`, arm64) läuft.** Verifikations-Baseline grün: `tsc --noEmit` sauber, `vitest run` 230/230, `cargo test render3d` 56/56. **Kein Blocker mehr für Engine-Slices auf diesem Gerät.**
 ## 🔧 In Arbeit
 - [ ] **GEO-BLOCK Folgepunkte (2026-07-12, nach dem swissBUILDINGS3D-DXF-Fix)** — Nutzer-Report, noch NICHT umgesetzt:
  - ✅ **Georeferenzierung (`ae47b4f` + `e61634c`):** `Project.geoAnchor` (persistenter Modell↔LV95-Referenzpunkt) ergänzt — der ERSTE Import in einem Projekt setzt ihn, ALLE folgenden Importe verwenden denselben Anker statt je eigenständig `makeOrigin(center)` neu zu berechnen. Zusätzlich neuer Befehl **„georef"** (Button „Neuer Bezugspunkt" in SitePanel): verschiebt per Klick das GESAMTE Projekt (`model/geoRebase.ts::translateProject`, reine Translation über alle Bauteile/2D-Geometrie/Kontext-Schicht/Schnittlinien) so, dass der geklickte Punkt zum neuen Modell-Ursprung wird — `geoAnchor` wandert automatisch mit, der LV95-Bezug bleibt exakt erhalten (rekonstruierbar, auch für einen künftigen georeferenzierten Export). Löst das vom Nutzer beschriebene Workflow: Kataster/3D zuerst importieren (landet ggf. weit vom Ursprung), dann selbst einen praktischen Bezugspunkt am Modell wählen. **Bewusst NUR Translation, keine Rotation:** `Roof.ridgeAxis` ist hart auf `"x"|"y"` beschränkt (keine frei gedrehten Dächer im Datenmodell) und mehrere Winkel-Felder (`Column.rotation`, Text-/Bild-Rotation, Türschwenk) müssten bei einer Drehung mitgeführt werden — eine Rotation, damit „orthogonal zur Parzellengrenze" gezeichnet werden kann, ist ein eigener, grösserer und riskanterer Schritt (Datenmodell-Erweiterung nötig), bewusst nicht mitgemacht. +17 Tests (`geoRebase.test.ts`, `georef.test.ts`), Suite 820 grün.
  - ✅ **Importierte Gebäude/Terrain sind jetzt anwählbare Meshes im 3D-Viewport (`e6a7738`):** Klick im WASM-3D-Viewport pickt Kontext-Meshes per Raycast (`raycast3d.ts`/`pickGeometry` in `toWalls3d.ts`), Auswahl bekommt einen eigenen Kanal (`selectedContextObjectIds`), Bounding-Box-Umriss als Highlight (volles Dreiecks-Wireframe wäre bei grossen Importen zu dicht), Entf-Taste löscht, `SitePanel`-Liste hebt die Auswahl hervor. **Bewusst NICHT umgesetzt:** die „auf einer Ebene"-Zuordnung (kein `categoryCode`/Layer-Feld an `ImportedMesh`/`TerrainMesh`, keine Sichtbarkeits-Kopplung an die Ebenen-Verwaltung) und keine volle Attribut-Bearbeitung (nur Name-Anzeige/Löschen, keine `deriveSelection()`-Integration ins Attribute-Panel — als zu gross für diesen Schritt eingeschätzt). **Ebenen-Zuordnung bleibt offen, ggf. eigener Design-Entscheid nötig** (eine feste „Import"-Ebene vs. frei zuweisbar).
  - ✅ **Zwei echte Bugs im swissBUILDINGS3D-Pfad behoben (`35a6834`+`9705890`):** (1) Absturz bei riesigen Kacheln (JSZip „Invalid string length" — DXF komprimiert stark, eine Kachel unter dem 150-MB-Limit kann entpackt trotzdem >700 MB Text ergeben; nur `asset.size` aus der STAC-API zu prüfen reichte nicht, jetzt zusätzlich die JSZip-interne Grössenschätzung + genereller Try/Catch, übersprungene Kacheln landen sichtbar in `skippedTiles`/UI-Meldung statt stumm 0 Gebäude). (2) **Der eigentliche „Import funktioniert nicht"-Bug:** die installierte `dxf-parser`-Version liefert Polyface-Mesh-Face-Indizes als vier einzelne Felder (`faceA`/`faceB`/`faceC`/`faceD`, Gruppencodes 71–74) statt als `faces`-Array — unser Code prüfte auf das Array, das nie existierte, jede swissBUILDINGS3D-DXF-Kachel ergab dadurch 0 Dreiecke. Live gegen echte Kacheln verifiziert: jetzt tausende Dreiecke mit realistischen Höhenwerten. **Damit ist der Gebäude-Import technisch lauffähig — die beiden Design-Punkte oben (Georeferenzierung, Ebenen-Zuordnung) bleiben offen.**
 - [ ] **3D-Kanten-Folgepunkte ("Schattiert mit Kanten", 2026-07-12)** — nach dem Fix der falschen Flächendiagonalen (`7dc8f0d`) zeigte der Nutzer drei weitere Beobachtungen, NOCH NICHT behoben:
  - **Fenster-Rahmenecken überlappen statt sauber zu stossen** (Screenshot: doppelte/kreuzende Linien an den Blendrahmen-Ecken bei „fein"). Vermutlich KEIN Kanten-Rendering-Bug, sondern echte überlappende Geometrie — die Rahmen-/Sprossen-Riegel (`openingAxisBox` in `toWalls3d.ts`) sind separate Boxen ohne Gehrung/Union an den Stössen. **Nutzer-Folgewunsch dazu:** bei „fein" einstellbar machen, ob die Ecke vertikal-dominant, horizontal-dominant oder auf Gehrung gelöst wird.
  - **Dach ebenfalls kein sauberer Verschnitt am First/Grat** (Screenshot: kleines Störtriangle exakt am First-Apex). Gleiche Kategorie — mehrere Dachflächen (`emitRoofs`) sind separate, nicht verschnittene Meshes.
  - **Im OG viele vertikale Striche auf den Wandflächen** — noch NICHT diagnostiziert (nicht als Textur-Pipeline-Artefakt bestätigt, evtl. eine mehrschichtige Wandtyp-Verkleidung mit vielen dünnen Einzelelementen). **Braucht weitere Untersuchung**, idealerweise mit Angabe welcher Wandtyp/welche Schicht im betroffenen Projekt verwendet wird.
  - Alle drei sind vermutlich Fälle für eine echte Boolean-Verschneidung (Kandidat: `csgrs`/`boolean_mesh`, bereits als WASM-Export vorhanden aus der truck-Integration, s. u.) statt nur Kanten-Heuristik — grösserer, eigener Task.
 - [ ] **Warteschlange „für danach" (Nutzer 2026-07-12, noch nicht begonnen):**
  - Luftbild/SWISSIMAGE wahlweise als Drapierung auf das Terrain-Mesh ODER als eigenständiges „Dokument" einfügbar (Bild/PDF generell als einfügbares Dokument-Objekt — noch keine Anforderungen präzisiert).
  - Import-Mesh (swissBUILDINGS3D u. Ä.) wahlweise geglättet („gerundet") oder kantig/eckig belassen, wählbar beim Import oder am Objekt.
 - [ ] **truck-Integration (Profil-Extrusion / B-Rep)** (Plan: [docs/design/truck-plan.md](docs/design/truck-plan.md)). Ziel: Nutzer zeichnet 2D-Querschnitt → truck-Extrusion → 3D-Körper + später Boolean gegen Wand/Decke. Umfang gesamt: ~4–6 Wochen. Fortschritt:
  - [x] Phase 1: Geometrie-Schicht — Crate `src-tauri/trucksolid` (`extrude_polygon_core`/`extrude_circle_core`, `truck_modeling` nur zur B-Rep-Validierung/`try_attach_plane`/`tsweep`, Tessellierung manuell aus den Ring-Koordinaten — truck-rendimesh-Tessellierung für Solids in 0.3 nicht verfügbar, daher Abweichung vom Übergabe-Dokument), WASM-Bindings (Feature `web`) + `build:truck`-Script + `exclude`-Eintrag, TS-Wrapper `src/engine/truckSolid.ts` (`extrudePolygon`/`extrudeCircle`), `RMeshKind` um `"extrusion"` erweitert (`toWalls3d.ts`). Verifiziert: `cargo test` 5/5 grün, `npm run build:truck` sauber, `tsc --noEmit` 0 Fehler, `vitest run` 339/339 grün.
  - [x] Phase 2 (MVP, Nutzer-Entscheid 2026-07-06: **"Nur Viewer-Wiring"**, kein Werkzeug/Store) — Ende-zu-Ende-Beweis, dass die Pipeline bis ins Bild funktioniert: ein fest verdrahtetes L-Profil (`emitTruckFixture` in `toWalls3d.ts`, 2 m abseits vom Ursprung) wird bei Bedarf per `trucksolid`-WASM extrudiert und erscheint im 3D-Viewport. **Zwei echte Lücken dabei gefunden und geschlossen:** (1) `render3d::types::MeshKind` kannte nur `Terrain`/`Imported` — ein `kind:"extrusion"` ohne passende Rust-Variante hätte die serde-Deserialisierung des GESAMTEN Modell-Pushes zum Absturz gebracht (nicht nur die Fixture); `Extrusion`-Variante + warmes Orange als Default-Farbe ergänzt (`cargo test` render3d 58/58 weiterhin grün). (2) `updateModel(project)` läuft nur bei Projektänderung (`useEffect`-Dep `project`) — die asynchron ladende Fixture hätte trotz Erfolg NIE einen Re-Push ausgelöst; Fix via Browser-Event `TRUCK_FIXTURE_READY_EVENT` (`toWalls3d.ts` dispatcht, `Wasm3DViewport.tsx` hört + stösst `updateModel` erneut an). **Visuell verifiziert** (Playwright, `?engine=wasm`, Chromium mit `--use-angle=metal` für echten WebGPU-Adapter headed): orangene Extrusion sichtbar neben dem Demo-Haus im Viewport. `tsc --noEmit` + `vitest run` 339/339 + `cargo test` render3d 58/58 grün. **Noch uncommittet** (Bearbeiter committet nicht selbst).
  - [x] Phase 3: UI-Werkzeug + Store-Integration — **erledigt 2026-07-06:** `extrude`-Befehl (`src/commands/cmds/extrude.ts`, Alias „ex") nimmt Polylinie/Rechteck/Kreis als Profil (vorselektiert ODER Klick), Höhe tippen oder Enter für Default; Quell-Zeichnung wird beim Commit ENTFERNT (nicht dupliziert) — der Grundriss zeigt die Extrusions-Footprint-Kontur (`generatePlan.ts`, warmes Orange `#d98c40`) statt der alten Linie. `project.extrudedSolids`-Array statt Fixture. **Volle Auswahl-Parität mit Wand/Decke/Raum** (Nutzer-Entscheid „Voll: wie Wand/Decke/Raum"): eigener Selektionskanal, Klick-Priorität in `PlanView.tsx`, Attribute-Panel-Sektion (Höhe editierbar → löst Re-Extrusion aus, Grundfläche, Geschoss), Löschen, Ctrl+A, `move`-Befehl (`src/tools/transform.ts`). Kreis-Profil nutzt die echte `extrudeCircle`-WASM-Rundextrusion (kein N-Eck-Fallback) über eine 48-Eck-Tessellierung für 2D/Auswahl. Verifiziert: `tsc`/`vitest` 339/339 grün, Playwright-Durchlauf (zeichnen→extrudieren→auswählen→Höhe ändern→löschen) ohne Konsolenfehler. **Bewusst NICHT gebaut** (Konsistenz mit Raum/Decke/Treppe/Öffnung, die das auch nicht haben): Marquee-Auswahl, Klick-Drag-Verschieben. **Noch uncommittet.**
  - [x] Phase 4: Boolean gegen Wand/Decke — Mesh-CSG statt B-Rep-Boolean. **Spike 1, 2026-07-06 (Monstertruck-Fork getestet, nicht nur Recherche):** eigenes Rust-Testprogramm gegen `monstertruck-solid` 0.3.2 (Fork von `ricosjp/truck`, wirbt mit gehärteten Booleans) — der Crate-eigene Smoke-Test (echter Überlapp, versetzt in allen 3 Achsen) läuft sauber (`or`/`and` liefern exakte Volumina). Aber: **jede Konstellation mit deckungsgleichen/berührenden Seitenflächen schlägt fehl** — exakt der Praxisfall „Extrusion flächenbündig an Wand" oder „Extrusion mit gleichem Wandquerschnitt eingebunden" (gleiche y/z-Ausdehnung wie die Wand, nur in x versetzt): 0 Überlapp → `Internal{operation:"or"/"and"}`-Fehler; 1e-4 UND sogar 0.1 m sichtbarer Überlapp bei deckungsgleichen Seitenflächen → derselbe interne Fehler; 1e-9 Gleitkomma-Rauschen (winziger Spalt statt exakt 0) → **kein Fehler, aber STILL FALSCHES Ergebnis** (2 unverschmolzene Shells, Volumen = Summe statt Vereinigung). Sobald y/z zusätzlich leicht versetzt sind (keine deckungsgleichen Seiten mehr), funktioniert derselbe x-Überlapp einwandfrei. **Schluss: B-Rep-Booleans (truck/monstertruck) sind für diesen Projekt-Praxisfall (Extrusion mit Wandbreite/-höhe eingebunden) grundsätzlich ungeeignet** — teils Absturz, teils stiller Falsch-Wert.
    **Spike 2, 2026-07-06 (`csgrs`, Mesh-Ebenen-CSG/BSP-Baum statt B-Rep):** strukturell anderer Ansatz — rechnet auf Dreiecks-Ebene statt über analytische Kurven/Flächen-Schnitte, damit unempfindlich gegen genau die koinzidenten-Flächen-Fälle, an denen truck/monstertruck scheiterten. Gegen dieselben Testfälle geprüft: generischer Überlapp exakt korrekt (`or`/`and`); flächenbündig (0 Überlapp) → `or` exakt 2.0 (korrekt verschmolzen, kein doppeltes Volumen), `and` liefert korrekt LEER (als Trimesh-Fehler statt sauberem `None` — muss beim Aufrufer als "leer" interpretiert werden); 1e-9-Rauschen → weiterhin exakt korrekt (kein falsches Doppel-Volumen wie bei monstertruck); 1e-4 winziger Überlapp → exakt korrekt; **der kritische Praxisfall (0.1 m Einbindetiefe, deckungsgleicher Wandquerschnitt)** → `or`/`difference` beide exakt korrekt. Jedes Ergebnis analytisch exakt (nicht nur "nah dran").
    - Packungs-Caveat: alle crates.io-Releases (0.16.0–0.20.1) sind wegen einer harten, zurückgezogenen `core2`-Abhängigkeit nicht installierbar — auf dem unveröffentlichten `main`-Branch bereits behoben. **Nutzerautorisiert** ("Git-Fetch für den Spike erlauben", danach "alles klar mach das" zur Umsetzung als echte Abhängigkeit): `trucksolid/Cargo.toml` pinnt `csgrs` auf Commit `5e7a37a8803d4e56617734687edc9b98f4ebeed7` (Git-Dependency, kein crates.io-Release — Risiko: kein durchnummeriertes/geprüftes Release, sollte bei Gelegenheit auf ein echtes `0.21.0`-Release umgestellt werden, sobald verfügbar).
    - **Umgesetzt:** `src-tauri/trucksolid/src/boolean.rs` — `boolean_mesh_core(a, b, op)` baut aus flachen Positions-/Indices-Arrays `csgrs::mesh::Mesh`-Polygone (`Polygon::new`/`Vertex::new`, Normale je Dreieck aus dem Kreuzprodukt, NICHT aus den Eingabe-Normalen — die Ebenen-Orientierung fürs BSP kommt aus der Vertex-REIHENFOLGE/Winding, nicht aus einem mitgelieferten Normalenfeld), ruft `union`/`difference`/`intersection` (Trait `csgrs::csg::CSG`) auf, tesselliert das Ergebnis zurück über `Triangulated3D::visit_triangles`. `empty: bool` im Output normalisiert den "Trimesh-Fehler bei leerem Schnitt"-Fall. WASM-Export `boolean_mesh` (Feature `web`, JSON-Schnittstelle wie `extrude_polygon`) + TS-Wrapper `booleanMesh()` in `src/engine/truckSolid.ts`. **Wichtige Voraussetzung für Aufrufer:** beide Eingabe-Meshes müssen konsistent nach AUSSEN gewundene Dreiecke haben (Rechte-Hand-Regel) — falsches Winding liefert ein falsches Ergebnis, OHNE Fehler zu werfen (im eigenen Test zunächst selbst hineingetappt: alle 6 Quader-Seiten der Test-Fixture waren invertiert, dadurch schlugen 3 von 4 Boolean-Tests fehl, bis das Winding korrigiert wurde — reiner Test-Fixture-Bug, nicht im Produktivcode).
    - Verifiziert: `cargo test` in `trucksolid` 11/11 grün (inkl. `wall_minus_embedded_extrusion_matching_cross_section`, `flush_touching_union_is_exact`), `cargo build --target wasm32-unknown-unknown --features web` sauber (csgrs + truck-modeling gemeinsam im selben WASM-Modul, keine Konflikte), `npm run build:truck` (echter `wasm-pack`-Build) sauber — `boolean_mesh` ist reell im generierten `.d.ts` exportiert.
    - **Noch offen (bewusst NICHT gebaut, eigene Scope-Entscheidung nötig):** die eigentliche Verdrahtung in die Live-3D-Szene (WANN soll eine Wand automatisch um eine eingebundene Extrusion gekürzt werden? Bei jeder geometrischen Überlappung? Nur bei explizit markierten Fällen?) ist eine UX/Scope-Frage, keine technische — analog zum Feld-Controller-Rückstand unten nicht blind entschieden, sondern auf Nutzer-Entscheid wartend. Aktuell bleibt eine Extrusion weiterhin ein unabhängiges, nicht mit der Wand verschmolzenes Solid im 3D (wie seit Phase 2/3).
  - [x] Phase 5: Verjüngung (Taper) — `taper` 0 (Prisma) … 1 (Spitze/Kegel-Pyramide), linear zum Profil-Schwerpunkt skaliert. Rust-Kern (`extrude_polygon_core`/`extrude_circle_core` in `lib.rs`), WASM/TS-Wrapper, dritte Befehls-Phase in `extrude.ts` (Höhe → Verjüngung, Enter für persistenten Default), `ExtrudedSolid.taper?`, Attribute-Panel-Feld (editierbar → Re-Extrusion). Tests: Kegel-Volumen (Divergenzsatz gg. analytisch), Pyramidenstumpf-Schwerpunkt-Skalierung, Range-Check.
  - [x] **Deep-Review + Fixes (2026-07-07, nach Geräte-Absturz der vorherigen Session):** 8-Winkel-Review (Korrektheit/Reuse/Simplify/Efficiency/Altitude/Conventions) über den gesamten uncommitteten Stand ergab mehrere echte Bugs, alle gefixt:
    - **Konkave Profile falsch trianguliert** (`trucksolid/src/lib.rs`): Deckel/Boden nutzten eine Fächer-Triangulierung ab Vertex 0 — korrekt nur für konvexe/von Vertex 0 aus sternförmige Polygone. Bei einem T-Träger (genau das im Plan genannte Zielprofil) erzeugte das nachweislich Phantom-Dreiecke quer durch die konkave Kerbe (nachgerechnet: 2 von 6 Deckel-Dreiecken lagen mit Schwerpunkt ausserhalb). Fix: Ohr-Clipping-Triangulierung (portiert von der bereits vorhandenen, robusten `render3d::mesh::triangulate`) ersetzt den Fächer; Schwerpunkt-Berechnung für die Verjüngung ebenfalls auf die korrekte flächen-gewichtete Formel umgestellt (vorher reiner Vertex-Mittelwert, bei asymmetrischen Profilen verzerrt). Neuer Regressionstest `t_beam_caps_stay_inside_polygon` (prüft, dass jeder Deckel-/Boden-Dreieck-Schwerpunkt im wahren Polygon liegt). `cargo test` trucksolid 15/15 grün.
    - **Auswahl-Zustand (`selectedExtrudedSolidIds`) an 6 Stellen in `App.tsx` nicht zurückgesetzt**, wo alle anderen Auswahl-Arten es bereits werden: Geschosswechsel-Effekt, `onOpenStampEditor`, die vier alten three.js-Viewport-Pick-Handler (Wand/Treppe/Decke/Öffnung), `onViewport3dPick`. Ohne Fix: Extrusion bleibt nach Geschosswechsel/anderer Auswahl "geisterhaft" mit-selektiert (falsches Panel, Löschen träfe das falsche Objekt).
    - **Mirror/Copy ignorierten eine reine Extrusions-Auswahl** (`hasSelection`/`toTransformSel` in `mirror.ts`/`copy.ts` kannten `extrudedSolidId` nicht, obwohl `transform.ts`/`move.ts` es längst unterstützen) → stiller No-op statt Spiegeln/Kopieren.
    - **DXF-Export verlor den Layer von Extrusions-Footprints**: da `extrude` die Quell-Zeichnung (mit `categoryCode`) entfernt, fiel `layerFor()` in `exportDxf.ts` auf `LAYER_DEFAULT` zurück. Fix: eigener `EXTRUSION`-Layer (gleiches Orange wie 2D/3D-Darstellung).
    - **`truckMeshCache` (toWalls3d.ts) ohne Eviction** — wuchs unbegrenzt über eine Session (Extrudieren→Kopieren→Löschen in Serie liess Mesh-Daten toter Körper im Speicher). Fix: gelöschte Ids werden bei jedem `emitExtrudedSolids`-Lauf aus dem Cache entfernt. **Gleichzeitig behoben:** sichtbares Flackern beim Tippen von Höhe/Verjüngung im Attribute-Panel (jeder Tastendruck = neue Signatur = Cache-Eintrag wurde sofort auf `mesh:null` gesetzt, bevor die neue Extrusion geladen war) — die alte Mesh bleibt jetzt sichtbar, bis die neue fertig ist.
    - **`fitTargetDist` im 3D-Viewport** (Wasm3DViewport.tsx) rief bei JEDER Projekt-Änderung (auch während eines laufenden Griff-Drags) unnötig die komplette Wand-/Öffnungs-/Decken-Flatten-Pipeline auf, nur um eine Bounding-Box für die Schnittebene zu ziehen — die aber nur bei aktiver Schnittebene gebraucht wird. Fix: Aufruf hinter `sectionActive` gegated.
    - **Nutzer-Report währenddessen:** Schnittebene-Umschalter (Wasm3DViewport.tsx) hatte `title`/`aria-label` hart auf Deutsch verdrahtet statt über `t()` — einzige Stelle im 3D-Viewport, die das i18n-System umging. Fix + Audit der ganzen App auf dasselbe Muster (title/aria-label/placeholder ausserhalb `t()`): genau eine weitere Stelle gefunden (`ColorHexField.tsx` Swatch-Tooltip „Farbe wählen"), beide jetzt über neue i18n-Keys (`viewport3d.section.*`, `attr.pickColor`).
    - Verifiziert nach jedem Schritt: `tsc --noEmit` sauber, `cargo test` trucksolid grün. `vitest run`/`cargo test render3d` am Ende der ganzen Fix-Reihe erneut komplett gegengeprüft (339/339, 58/58, 15/15).
 - [ ] **kernel2d-Port nach Rust/WASM** (Plan: [PORT_PLAN.md](PORT_PLAN.md), Crate `src-tauri/kernel2d`, TS-Referenz bleibt `kernel2d.ts`, Differential-Harness `src/geometry/kernel2d.parity.test.ts`). Fortschritt:
  - [x] Phase 1: Crate-Skelett + WASM-Fassade + `build:kernel2d` — `a78e7c7`
  - [x] Phase 2: Primitive/Schnitt/Fläche/Kreis + Batch-Fassaden + Diff-Harness (Zufall+Golden) — `9e2c521`
  - [x] Phase 3: Offset (Miter + 1e-9-Fallback) + Fillet — `c8ea2bf`
  - [x] Phase 4: Trim/Split/Join (`trimPolyline`, `splitAtIntersections`, `joinChains` — Löwenanteil) — `28471c1`
  - [x] Phase 5: `roomArea`-Flächen/`ceiling`/`stair`/`roomBoundary` portiert (vitest 263, 33 Parity) — `a608a59`. ✅ **Phase 5 komplett (2026-07-07):** `opening` portiert (`wall_axis_length`/`opening_interval`/`wall_axis_frame`/`opening_jambs`/`opening_gap_quad`/`opening_center`/`door_symbol`/`window_symbol` + `along`-Helper, geflachte Signaturen nach PORT_PLAN; `openingVerticalExtent` bleibt bewusst TS — echte Modell-Kopplung an drawingLevels). +7 Parity-Tests (Suite 40 Parity). `cargo test` kernel2d 18/18, `build:kernel2d` sauber, vitest 348/348. Produktive Aufrufer unverändert (Phase 6 weiter offen/Nutzer-Entscheid). **Noch uncommittet.**
  - [ ] Phase 6: TS-Fassade umstellen (alt → `kernel2d.legacy.ts`), Suite grün, `npm run build` + WASM sauber. **Achtung Laufzeit-Entscheid:** macht die Live-App synchron WASM-abhängig (Init + Per-Call-Marshalling) — heute nutzt die App KEINE WASM-Geometrie zur Laufzeit; vor Umstellung mit Nutzer klären.
    - **Join-Durchstich verworfen (2026-07-05, gemessen):** `computeJoins` live auf WASM zu legen lohnt NICHT. Benchmark TS vs. WASM inkl. JSON-Marshalling (Median ms/Aufruf, 200 Iter): 6 W → TS 0.018/WASM 0.022 · 20 → 0.027/0.043 · 50 → 0.082/0.102 · 120 → 0.331/0.246 · 300 → 1.68/0.67. Crossover erst ~100+ Wände; realistische Plan-/Geschossmengen liegen darunter → TS schneller, und selbst 300 Wände sind mit TS 1,7 ms (nicht wahrnehmbar). Marshalling frisst den Rust-Vorteil, plus dauerhafte Rust↔TS-Paritätspflicht. **Fazit:** reines TS behalten; WASM für Joins nicht weiterverfolgen. WASM lohnt erst bei echten Rechen-Hotspots (Booleans/Tessellierung).
 ## ⚠️ Zu prüfen (evtl. schon erledigt / Status unklar)
 - [x] ~~**Snap an Wand-Schichttrennlinien**~~ — **gelandet `339202b`** (`wallLayerBoundarySegments` in `src/tools/snapping.ts`), verifiziert vorhanden.
 ## ⏭️ Als Nächstes
 - [ ] **BIM-Elemente „wirklich 1:1" (Tür/Fenster/Dach/Decke)** — volle Studie + Priorisierung: **[docs/design/bim-elements-depth-study.md](docs/design/bim-elements-depth-study.md)** (623 Zeilen, Referenzmatrix VW/ArchiCAD/Revit/Allplan gegen IST). ✅ **Bereits erledigt 2026-07-10:** Fenster-Schachtelung Blendrahmen→Flügelrahmen→Glas + fest/öffenbar + Einbaulage 2D (`9a38636`); Mansard-Untertypen Giebel/Walm/Zelt + Knick (`bfb80b3`); Dach-Dicke 3D (`e99bb24`) + **Dach-Schichtlogik RoofType/Layer[]** (`3a986ec`); zweiflügelige Türen leafCount 2D+3D (`4319e12`); getrennter Traufe/Ortgang-Überstand (`c9baff5`); Glas/glazingPanes 2D+3D + Rollladenkasten (`2e13ec3`/`d131683`). **Offen (nach Doc-Priorität):**
  - [x] ~~**Decken-Aussparungen**~~ — **erledigt 2026-07-10 (`37f4fe8`+`cdbef99`+`aee8846`+`83dcdd0`):** `Ceiling.openings?: Vec2[][]` + **Brücken-Trick** (`mergeHoles` in `src/geometry/polygonHoles.ts`: Löcher über schmale Brücken in den Aussenring → EIN einfacher Ring, paritätskorrekt für SVG/Hatch/Ear-Clipping/Pick — KEIN Loch-Support in den Primitiven nötig, kein Rust-Change). 2D-Poché-Loch (Brückenkanten via noStrokeEdges) + 3D-Slab-Loch; Befehl „Deckenloch" (Aliase deckenloch/aussparung, BIM-Ribbon); Panel listet Aussparungen mit Entfernen. +11 Tests.
  - [x] ~~**Dach in 2D-Aufsicht + Vertikalschnitt**~~ — **erledigt 2026-07-10 (`9a00c8e`+`f248e2a`):** Grundriss-Aufsicht trägt die Ansichts-Schraffur (viewHatchId) der Eindeckungs-Schicht; Vertikalschnitt via `appendRoofSections` (analytischer TS-Schnitt: Cyrus–Beck gegen die Aufsichts-Polygone, lineare Oberkante, Dicke/cos(Neigung), Schicht-Bänder aussen→innen mit Bauteil-Schraffur). **Offen:** Ansichts-/Silhouettenkanten des Dachs in Elevationen (nur Schnitt-Polygone bisher).
  - [x] ~~**RoofType-ResourceManager-Tab**~~ — **erledigt `83abc1d`** (RoofStylesTab auf LayeredStylesTab-Rumpf; anlegen/editieren/löschen, Löschen geschützt bei Verwendung).
  - [ ] **Decken-Randschicht-Override** (`Ceiling.edgeOverride`, Ringzone anderer Aufbau, Tropfkante/Randdämmung) — P1; **Deckentrenn-Werkzeug** für thermisch getrennte Auskragung (Isokorb, UI-only) — P1.
  - [ ] **Tür 1:1 Rest:** `glazingRatio` (Teilverglasung), Kassettentür-Geometrie, `frameKind` im 3D (Zarge vs. Blockrahmen), echtes Schwellenprofil; Alt-`Door[]`-Pfad in `Opening` konsolidieren (technische Schuld, zwei Datenwege).
  - [ ] **Fenster 1:1 Rest:** asymmetrische Rahmenbreiten, Bank/Nische, Laibungsverkleidung, Form (Rund/Spitz/Schräg). ~~echtes Sprossengitter~~ ✅ **erledigt 2026-07-12 (`00bff27`):** `mullionCols` (vertikale Sprossen-Spalten) spiegelbildlich zu `mullionRows` — 3D-Rahmen-Riegel, Ansichts-Trennlinien + Glasscheiben als echtes rows×cols-Raster, Eingabefelder in `OpeningEditorDialog`/`ResourceManager`.
  - [ ] **Dach 1:1 Rest:** Kniestock/Drempel, Krüppelwalm, Kehlen bei L-Grundriss (Straight-Skeleton), Gauben/Dachfenster, Aufschieblinge. ~~Dach im Vertikalschnitt~~ ✅ `f248e2a`.
  - [ ] **Geneigte Decke** (Rampe/Gefälle), Deckenspiegel (zweite abgehängte Fläche) — P2/P3.
  - **Nicht bauen** (Doc §6): VW-Massketten-Apparat, volle Sichtbarkeitsmatrix, Eck-Fenster/-Dach generisch, Beschlags-Produktbibliothek, IFC-Void-Semantik nachrüsten.
 - [ ] **`make2D`-Befehl (Sicht → 2D-Zeichnung mit Füllungen)** (Nutzer-Wunsch 2026-07-10). Aus der AKTUELLEN Sicht — egal ob Grundriss, Schnitt oder 3D — eine flache 2D-Zeichnung aus reinen 2D-Geometrien erzeugen (Linien + Füllungen/Schraffuren, „mit allem"). Zwei Ausgaben: (a) als neue `Drawing2D`-Elemente ins Modell einfügen (auf einer Ziel-Ebene), ODER (b) in die Zwischenablage kopieren (SVG/DXF-Fragment) zum Einfügen anderswo. Vorbild: Vectorworks „2D-Darstellung erzeugen" / Rhino `Make2D`. **Bausteine vorhanden:** Grundriss/Schnitt laufen bereits über `generatePlan()`/`generateSectionPlan()` → RScene → SVG (`sceneToPrintSvg`); für 3D braucht es eine Projektion (HLR/Silhouette) der `projectToModel3d`-Meshes auf die Bildebene (neuer Teil). MVP: Grundriss/Schnitt → Drawing2D + Clipboard; 3D-Projektion als zweite Phase. Scope/Format (SVG vs. DXF vs. native Drawing2D) mit Nutzer schärfen.
 - [x] ~~**Dächer: Auswahl + Attribut-Editieren + Löschen**~~ — **erledigt (`80121a3` + Folge-Commits `7cfdf59`/`eaf57e2`/`64f6179`/`826685c`):** Klick-Auswahl (Traufe-Pick-Polygon + pickRoof), `selectedRoofIds`/`updateRoof`/`RoofInfo`/`roofSelection`; RoofSection-Panel voll editierbar (Form, Firstrichtung X/Y, Neigung(en), **Breite/Tiefe**, Überstand, Dicke, **Traufhöhe**) + Firsthöhe/Fläche read-only; **Auswahl-Hervorhebung im 2D UND 3D** (Draht-Umriss); Löschen; Abwählen an ALLEN Reset-Stellen. **Optional Folge:** ~~3D-Griffe zum Ziehen (Traufe/First)~~ ✅ **erledigt `4ef40a0`** (Eckpunkt-Resize + Verschieben + First-Griff für Neigung). **Noch offen:** Dachfenster, Kehlen bei nicht-rechteckigem Grundriss (Straight-Skeleton).
 - [ ] **Ribbon-UI + modulare Bars** (Nutzer-Vision 2026-07-05, bestätigt: Tab-Schema **2D·3D·BIM·Ansichten**). Voller Plan + datengetriebene Architektur: **[docs/design/ribbon-ui-plan.md](docs/design/ribbon-ui-plan.md)**. Ribbon-Oberleiste mit Tabs ersetzt die Werkzeug-Sidebar; datengetriebene Registry (RibbonItem = tool|command|action) ermöglicht auch eine **modulare Custom-Bar** (gleiche Items, vom Nutzer gewählt). Attribute bekommen volle Höhe, Objektinfo darunter gemergt; XYZ-Box oben rechts bleibt. **Phasen:** ~~(1) Gerüst + 2D/BIM-Tab~~ ✅ (`9d6e86d`), ~~(2) TopBar → Ansichten-Tab mergen~~ ✅ (`85011cb`), ~~(2b) Tabs in die TopBar-Zeile~~ ✅ (`456ebc8`), ~~(2c) OCS-Chrome (kleine Wortmarke + Quick-Access-Icons statt Burger, Zeile 26px)~~ ✅ (`4e3b074`), ~~(2d) Text + Ansichten auf eine Leiste, „Ansichten" als Standard-Tab zuerst~~ ✅ (`fe22cbf`), (3) **teilweise** ✅: Werkzeug-Sidebar aus Default-Layout raus + Attribute volle linke Höhe + Wandtyp-/Deckentyp-Picker ins Attribute-Panel verschoben (Nutzer-Entscheid), `LAYOUT_VERSION`→8; ~~**offen:** Objektinfo unter Attribute mergen~~ ✅ (`3a2cef3`): element-spezifische Abschnitte (Wand/Decke/Öffnung/Treppe/Raum) + Wand-Referenzlinie ins Attribute-Panel verschoben; ObjectInfo trägt nur noch Bezugspunkt + Masse (Nutzer-Wunsch). ~~(4) modulare Custom-Bar~~ ✅ (Tab „Eigene" + ＋-Picker, localStorage-persistiert). **Offen:** 3D-Tab füllen (aktuell leer; ggf. 3D-spezifisch statt Doppelung mit Ansichten), Band-Höhe/Abstände + 26px-Zeile visuell im Tauri abnehmen, Dauer-Zoom-Anzeige (Statusleiste?) klären. ✅ Vorarbeit: Eigenschaften-Grid im OCS-Stil (`00733d8`), Kreis+Bogen-Werkzeuge (`e454eab`/`bd2b12b`). **Nächster Schritt: im Tauri visuell prüfen (Band-Höhe, Icons, Aktiv-Highlight), dann Phase 2/3.**
 - [x] ~~**SPIKE — Bild-Texturen in `render3d`**~~ — **erledigt `0ca3b1d`** (verifiziert 2026-07-05): `RenderStyle::Textured` real, prozedurales 256×256-Schachbrett (kein Asset/`image`-Crate), UVs planar in Metern, Textur-Bind-Group group 1, `MESH_TEXTURED_WGSL` (gleiche Beleuchtung, Albedo aus `textureSample`), `spike3d` per `T` umschaltbar. Alt-Vertexpfad `[pos,normal,color]` bitgleich (Regressionstest). `cargo test` 58 grün (59 mit `--features render`, inkl. naga-Test); `spike3d`-Build sauber; keine neuen Deps, Default-Build unverändert. Auftrag: [SPIKE_TEXTUR_render3d.md](SPIKE_TEXTUR_render3d.md). **Lücken bis „richtig gutes" Texturing → siehe 3D-REST unten.**
 ## 📋 Backlog (Priorität grob absteigend)
 - [x] ~~**Shift-Ortho beim Körper-Verschieben (2D) fehlte**~~ — **erledigt 2026-07-06:** Nutzer-Report — Shift zum H/V-Einrasten wirkte beim Ziehen eines Vertex-Griffs (`onGripMove`) und beim freien Kanten-Zug (`onEdgeMove`), aber NICHT beim Verschieben eines ganzen Elements per Körper-Griff (`onMoveBody` — Wand/2D-Element/Decke/Treppe/Raum als Ganzes): `PlanView.tsx` reichte `mods` an dieser einen Stelle schlicht nicht durch. Fix: `GripHandlers.onMoveBody` bekommt optionales drittes Argument `mods: ToolMods`, `App.tsx` zwingt bei `mods.shift` das Delta auf die dominante Achse (H/V) — dieselbe Regel wie beim freien Kanten-Zug. `tsc`/`vitest` 339/339 grün.
 - [ ] **Feld-Controller (getippte Länge/Winkel relativ zum Ausgangspunkt) fehlt beim Körper-Verschieben + im 3D.** Nutzer-Wunsch 2026-07-06: „allgemein brauchen wir ein System bei 2D- und 3D-Elementen, dass wenn man einen Punkt anwählt, man ihn verschiebt — mit der Option, Länge und Winkel relativ zur alten Position zu wählen." Bestandsaufnahme: **existiert bereits** für den 2D-Vertex-Griff-Drag (`gripEditRef`/„Feld-Controller", Tab öffnet/zykelt Länge↔Winkel-Sperre, `gripEditPoint` in `App.tsx`) — fehlt aber (a) beim 2D-Körper-Verschieben (`onMoveBody`, ganzes Element ziehen) und (b) komplett im neuen 3D-Griffsystem (`Wasm3DViewport.tsx`, s. „3D-Griffe/Editieren" oben — weder Vertex- noch Verschiebe-Griff haben dort eine Locks/HUD-Eingabe). Für (b) zusätzlich zu klären: wie eine getippte Zahl im 3D-Viewport erfasst wird, ohne mit der freien Maus-Navigation (Orbit/Pan) zu kollidieren — eigenes UI-Element (z. B. ein kleines Eingabefeld neben dem gezogenen Griff-Button) naheliegend, aber nicht mit dem 2D-HUD-Muster identisch übertragbar. Mit Nutzer Scope/Reihenfolge klären (2D-Körper zuerst, da mechanische Erweiterung des bestehenden Feld-Controllers; 3D danach als grössere UI-Frage).
 - [x] ~~**Zeichenwerkzeuge ergänzen: Kreis + Bogen.**~~ — **komplett erledigt (2026-07-05):** beide Werkzeuge + Center-/Quadrant-Snaps + WebGL-Sichtbarkeitsfix (`2c8ad8f`). Details in den Unterpunkten:
  - [x] ~~**Kreis-Toolbar** (trivial)~~ — **erledigt `e454eab` (2026-07-05):** `ToolId`+`"circle"`, Platzhalter `circleTool` (nicht floorOnly), `TOOL_COMMAND`+`TOOL_ORDER`, Kreis-Icon in `ToolsPanel`, i18n `tool.circle`/`tool.circle.hint`. tsc + Suite 331 grün. (Kreise rendern seit `4ac99d3` glatt als `<circle>`.)
  - [x] ~~**Bogen-Werkzeug** (mittel)~~ — **erledigt (2026-07-05):** `arcCommand` in `src/commands/cmds/arc.ts` (3-Klick: Mittelpunkt → Start/Radius → Endwinkel, CCW; Vorschau via `arcPts`/`circlePts`), registriert in `registry.ts` (Alias `a`/`bogen`), `"arc"` als ToolId + Toolbar-Eintrag (Bogen-Icon) + i18n. tsc + Suite 331 grün. ✅ **Center-/Quadrant-Snaps ergänzt (2026-07-05):** `collectCircles` + Snap-Block in `snapping.ts` — Mittelpunkt + Quadranten (Kreis: alle 4; Bogen: nur im Spannbereich) unter der `center`-Einstellung, Bogen-Endpunkte unter `endpoint`; +3 Tests (Suite 334).
 - [ ] **BAUTEILE aufs Rhino-Niveau heben (Treppe/Fenster/Tür).** Vergleich Rhino-Plugin ↔ TS + priorisierte Ansätze: **[RESEARCH_BAUTEILE_RHINO.md](RESEARCH_BAUTEILE_RHINO.md)**. ✅ **Gruppe A (2D, Items 1–6) komplett — verifiziert 2026-07-05:** (1) Treppe-Outline (`stairOutline`, gerade/L/Wendel, `generatePlan.ts:2186`), (2) Fenster-Brüstungslinie (`window-sill`, gepunktet, `sillHeight>0`, `:1810`), (3) Tür-Sturzlinien (`door-lintel` + `lintelLines` keine/innen/aussen/beide, gestrichelt, `:1711`), (4) Treppe-Referenz links/mitte/rechts, (5) Fenster-Flügel-Mittelpfosten, (6) Tür `wandoeffnung`. **Offen:** Gruppe B (2D mittel: Tür-Schwung am Rahmen, Fenster/Tür-Presets) — Feinpolish. ✅ **`swing_invert` gilt als abgedeckt** (2026-07-17): die Aufschlagseite ist über `Opening.swing` (links/rechts) UND der Scharnier-Pfosten über `Opening.hinge` (start/ende) bereits voll im Objekt-Info wählbar (4 Kombinationen = jede Schwenklage), ein separater Invert-Flag wäre redundant. ✅ **Treppen-Pfeil-Style `filled` erledigt 2026-07-17** (uncommittet): `Stair.arrowStyle?:"line"|"filled"` (additiv), gefülltes Dreieck-Polygon statt zwei offener Linien in `addStairSymbol` (`generatePlan.ts`), Segment-Umschalter im Objekt-Info (`onSetStairArrowStyle`), `StairInfo.arrowStyle`, +2 Tests (`generatePlan.stairArrow.test.ts`). tsc/vitest 869 grün. ✅ **Fenster-Anschlag-Striche erledigt** (`8d688b9`, Laibungsstriche quer zur Wand bei „fein", analog Tür; +2 Tests). Gruppe C (3D: Rahmen/Blatt/Glas/Sims als Mesh — wartet auf Mesh-/B-Rep-Pipeline). **Der große Rest ist „Schnitt- vs. Ansichts-Darstellung" (eigenes Item unten).**
 - [ ] **DWG/DXF-Import via `acadrust` (weiterbauen).** ✅ Spike `763a558`: `acadrust` 0.4 (MPL-2.0, pure Rust) **baut zu wasm32** (Crate `src-tauri/dwgimport`, 839 KB), parst DXF aus Byte-Buffer (`DxfReader::from_reader`+`Cursor`), headless getestet. **Offen:** (1) Entity→DOSSIER-Modell-Mapping (LINE/ARC/… → Wand/Öffnung — die eigentliche Domainarbeit, Wochen), (2) Datei-Upload-Glue im Browser (`<input type=file>`→Uint8Array→`parse_dxf_summary_json`, trivial), (3) DWG-binär (`DwgReader::from_reader` analog, aber R13–R2018-Korrektheit unverifiziert), (4) WASM-Größe (nalgebra Haupttreiber). **Klarstellung:** der TS-DXF/DWG-Import (`parseDxf`/`parseDwg`/`dxfToDrawings`) + Upload-UI (`App.tsx`, `ImportDialog.tsx`) existieren längst und funktionieren — der acadrust-Weg wäre eine Rust-Neuimplementierung des Lesens (nur DWG-**Schreiben** ist eine echte Lücke). ✅ **2887794 (2026-07-05): Kurven-Abdeckungslücke geschlossen** — `parseDxf` deckt jetzt ARC/CIRCLE/ELLIPSE (tesselliert zu Konturen, Winkel Radiant, voller Umlauf geschlossen) zusätzlich zu LINE/LWPOLYLINE/POLYLINE/MESH ab; 5 Tests, volle Suite 307 grün. ✅ **c481373 (2026-07-05): SPLINE + INSERT ergänzt** — `parseDxf` wertet SPLINE als echte B-Spline (De Boor, Grad/Knoten; Fallback fitPoints/Kontrollpolygon) aus und expandiert INSERT-Block-Referenzen (2D-Transform Scale/Rotation/Basispunkt + MINSERT-Array + verschachtelte Blöcke, Tiefe ≤8) zu transformierten Konturen; Kontur-Dispatch in gemeinsamen `collectContours` refaktoriert; +7 Tests, volle Suite 314 grün. **Bekannte Grenzen:** rationale SPLINE-Gewichte ignoriert (dxf-parser liefert sie nicht); Block-interne MESH/3DFACE-Entities werden im 2D-Import nicht expandiert. ✅ **c29f27e (2026-07-05): HATCH ergänzt** — dxf-parser hat KEINEN HATCH-Handler (verwarf HATCH stumm); Lösung via `registerEntityHandler` + eigenem `HatchHandler` (sammelt rohe Gruppencodes) + testbarer `hatchContours`-Auswertung: Randpfade (Polyline-Pfade + Linien-/Bogen-Kanten, Bögen über vorhandene Tessellierung) → geschlossene Konturen mit `Contour.filled`; `contoursToDrawings` macht daraus gefüllte `polyline`-Drawing2D (fillColor-Default, restylebar). +6 Tests, Suite 320 grün. ✅ **05bc5aa (2026-07-05): HATCH-Ellipse/Spline-Kanten** ergänzt (Kantentyp 3/4 tesselliert; B-Spline-Sampling in `sampleBSpline` extrahiert). ✅ **4b93ac9 (2026-07-05): TEXT/MTEXT** — `parseDxf` liefert `DxfImportResult.texts` (`ImportedText`: Position/Höhe-in-Metern/Winkel-Radiant; MTEXT-Formatcodes grob gesäubert); `textsToDrawings` → `{shape:"text"}`-Drawing2D; **Darstellung neu**: `addDrawing2D` emittiert ein schlankes `kind:"drawingText"`-Primitiv, PlanView rendert es rein per SVG (modellverankert, Rotation; GPU-Guard so, dass es in ALLEN Renderer-Modi im SVG bleibt); `toRenderScene` überspringt es; ImportDialog zählt/importiert Texte. +5 Tests, Suite 327 grün. **Bekannte Grenzen HATCH:** Bulges an Polyline-Rändern als Sehne; Insel-Loops = eigene Ringe (keine echten Löcher). **Bekannte Grenzen TEXT:** importierte Texte (pointerEvents:none) noch nicht per Canvas-Klick selektierbar; MTEXT-Feinformatierung flachgeklopft; Block-interne TEXT/MTEXT nicht expandiert. **Text im Tauri visuell abgenommen (Nutzer 2026-07-05)** — auch gedreht korrekt. ✅ **4ac99d3: CIRCLE/ARC als echte glatte Formen** — `Contour.curve` trägt die wahre Kreis-/Bogen-Geometrie (pts bleiben für Kontext/3D); `contoursToDrawings` baut `{shape:"circle"|"arc"}`; neue Primitive `drawingCircle` (SVG `<circle>`) + `drawingArc` (SVG-Bogenpfad), `toRenderScene` tesselliert sie für den nativen Pfad; +4 Tests, Suite 331. Ellipse bleibt tesselliert (kein Ellipsen-Primitiv). **Weiter offen:** Entity→Wand-Semantik (die dicke Domainarbeit); DWG-Schreiben (einzige echte Export-Lücke).
 - [ ] **STRATEGIE — „von BIM-Tool zu echtem CAD".** Direkt am Quellcode studierte Referenzen (OpenCADStudio/truck/acadrust) + Web-Import-Landkarte → konkrete, priorisierte Ansätze in **[RESEARCH_CAD_APPROACHES.md](RESEARCH_CAD_APPROACHES.md)**. Kern: (1) generisches Entity-Modell + Trait-Dispatch, (2) modeless Command-System (`StepInput`-Funnel + Kommandozeile), (3) DWG/DXF-Round-Trip via `acadrust` (MPL-2.0, pure Rust, WASM-tauglich), (4) volle Object-Snap-Schicht, (5) 3D-B-Rep später selektiv via `truck` (Apache-2.0, Geometrie-Crates WASM-fähig, Booleans/Fillets noch instabil). Der `kernel2d`-Rust/WASM-Kurs ist damit bestätigt. **Mit Nutzer priorisieren, welcher Ansatz zuerst.**
 - [ ] **Schnitt- vs. Ansichts-Darstellung nach Schnitthöhe (BIM-Standard).** ✅ **Phase 1 (Wand unter Schnittebene) erledigt (2026-07-05):** `generatePlan.addWallPoche` hat einen `viewOnly`-Zweig — erreicht eine Wand die Grundriss-Schnitthöhe nicht (`wall.height < floor.cutHeight`, z. B. 0.3-m-Brüstung bei 1 m), wird sie nur als Ansichts-Umriss (Haarlinie, `fill:"none"`, keine Schraffur) gezeichnet statt als Schnitt-Poché; normale Wände (≥ Schnitthöhe) unberührt. Segment-/Gehrungs-/Öffnungs-Logik geteilt. +2 Tests (`generatePlan.viewwall.test.ts`, Suite 336). ✅ **Phase 2 (Decke über Ebene = gestrichelte Überkopf-Linie) erledigt (2026-07-05, `39ddd9b`):** der freie Decken-Umriss (Überstände/Balkone, wo keine Wand verdeckt) ist jetzt gestrichelte Haarlinie (`OVERHEAD_DASH`) statt kräftiger Volllinie — BIM-Konvention „Aufsicht auf Bauteil über einem". Decken-FLÄCHE war schon Ansicht (viewHatchId, weiß). +1 Test. **Offen (Phase 3):** per-Component View-/Cut-Weight + eigene View-Schraffur (Slot-Trennung); cut/Aufsicht/Untersicht (Deckenspiegel/Reflected Ceiling Plan); Unterzüge; Feinheiten. Kern-Idee (Nutzer): jedes Bauteil bekommt getrennt eine **Schnittlinie** (kräftig, z. B. 0.25–0.35 mm, + Schnitt-Poché) und eine **Ansichtslinie** (Haarlinie); WELCHE gilt, entscheidet die z-Ausdehnung des Bauteils vs. die **Schnitthöhe** des Grundrisses (Default ~1 m):
  - Bauteil wird von der Schnittebene GESCHNITTEN → Schnittlinie + Schnitt-Poché (heutiges Wandverhalten).
  - Bauteil liegt ganz UNTER der Ebene (z. B. 30-cm-Wand bei 1 m Schnitthöhe, Brüstung, Podest) → nur „von oben gesehen" = **Ansichtslinie/Haarlinie, KEINE Schnitt-Poché**. ← genau der vom Nutzer genannte Fall.
  - Bauteil liegt ganz ÜBER der Ebene (Decke/Slab, Unterzug) → Ansicht, üblicherweise **gestrichelte** Überkopf-Haarlinie.
  - **Passt konsistent zum bereits existierenden `viewHatchId` (Ansichts-Schraffur) vs. Schnitt-Schraffur** — die Linienstärke-Dualität (View-/Cut-Weight je Component) ist die natürliche Erweiterung derselben Logik.
  - **Nicht nur cut/view, sondern cut / AUFSICHT / UNTERSICHT (Nutzer):** ein Bauteil sieht von oben anders aus als von unten. Der Grundriss (Blick nach unten) zeigt Bauteile UNTER der Ebene in **Aufsicht** (Oberseite); ein **Deckenspiegel/Reflected Ceiling Plan** (Blick nach oben) zeigt Bauteile ÜBER der Ebene in **Untersicht** (Unterseite — z. B. Kassettendecke, Leuchten). Also je Component potenziell **drei** Darstellungs-Slots (Schnitt / Aufsicht / Untersicht) × {Schraffur + Linienstärke}. Das heutige `viewHatchId` ist faktisch EIN View-Slot und vermischt Auf-/Untersicht; sauber wäre die Trennung. WELCHER Slot gilt, entscheidet die **Blickrichtung der Sicht** (Grundriss ↓ / Deckenspiegel ↑) UND die z-Lage relativ zur Schnittebene.
  - **Verallgemeinert den Decken-Footprint-Clip** (`a2f6923`): „Decke unter Wand verdeckt" ist ein Spezialfall von „Ansichtsbauteil vs. schneidende/überdeckende Bauteile".
  - Aufwand: mittel–groß, phasenweise machbar (1: z-Extent-vs-Schnitthöhe-Klassifikation cut/above/below; 2: Ansichtslinie-Weight je Component + Haarlinie/gestrichelt; 3: 30-cm-Wände & Slabs verdrahten). Nicht zu komplex im Konzept — es ist der reguläre CAD/BIM-Weg (ArchiCAD/Vectorworks/Revit). Mit Nutzer Detailgrade/Defaults festlegen.
 - [x] ~~**Ebene-Schraffur editierbar**~~ — **gelandet `dcb6ed5`**: Kategorie-Dialog (`App.tsx`, `editor.hatch`-Feld) hat `<select>` auf `cat.hatch` + `HatchSwatch`-Vorschau. Verifiziert vorhanden.
 - [ ] **GEO-BLOCK** (gemeinsame Dateien io/geoContext/swissTopo/terrain/ContextImportDialog/Viewport3D/siteSlice):
  - ✅ **swissBUILDINGS3D 1:1 + swissALTI3D-Terrain erledigt 2026-07-12 (`ed724be`):** Root Cause war `swissTopo.ts::fetchBuildings` (generalisierter 1:25'000-Kartografie-Layer, nur Grundriss, `DEFAULT_BUILDING_HEIGHT=9`-Pauschalkiste) + grobe `profile.json`-Terrain-Näherung. Fix: neues `stacApi.ts` (gemeinsamer STAC-Client) + `swissBuildings3d.ts` (echte Wände/Dach-Meshes aus swissBUILDINGS3D-DXF-Kacheln, Generation **2.0 (stabil) UND 3.0 (Beta)** wählbar, über den bestehenden `dxfParser.ts` eingelesen — kein neuer Parser nötig) + `swissAlti3d.ts` (echtes swissALTI3D-Höhenraster, **0.5 m/2 m** wählbare Punktdichte statt Näherung). `ContextImportDialog.tsx` entsprechend erweitert (Gebäude-Modus aus/vereinfacht/2.0/3.0, Terrain-Auflösung). Referenz war das Rhino-Vorgänger-Plugin (`git.kgva.ch/karim/DOSSIER`, `rhino/swisstopo.py`). Pipeline nutzt **render3d** (nicht Three.js, Nutzer-Entscheid 2026-07-12 „scheiss auf three.js darstellung render3d ist fokus").
  - ~~**Nordstern-Geo-Rendering**~~ — **war bereits erledigt** (`35299307d`, 2026-07-09, stand hier fälschlich noch als offen): `emitMeshes` in `toWalls3d.ts` liest `project.context` (`importedMesh`/`terrainMesh`) bereits und speist sie in `projectToModel3d` ein — keine weitere Verdrahtung nötig, war Voraussetzung für den swissBUILDINGS3D-Fix oben und stand schon.
  - Reale Höhen + **Projekt-MüM** (EG-Referenzhöhe): Terrain georeferenziert bei realem z relativ dazu, Gebäude auf Terrain drapiert (heute alles z=0).
  - **Luftbild/SWISSIMAGE**-Orthofoto als Textur aufs Terrain-Mesh.
  - Importierte Geo-Elemente auf **aktives Geschoss** (`viewSlice.activeLevelId`) + Gelände-Ebene.
  - **3D-Mesh-DXF/DWG-Import** (heute DXF nur 2D bei manuellem Import — der Mesh-Pfad selbst ist über `dxfParser.ts` schon 3D-fähig, s. o.); Building-Draping; höhere DTM-Auflösung.
 - [x] ~~**ResourceManager Bauteile-Tab** auf Master-Detail~~ — **bereits Master-Detail** (`ComponentsTab`/`ComponentDetail` in `src/ui/ResourceManager.tsx`, Liste links `res-md-list` / Detail rechts). Verifiziert vorhanden.
 - [x] ~~**Einstellungs-Fenster (Rest)**~~ — **erledigt:** Verdrahtung war schon **da** (`viewSlice.snapColor`/`marqueeColor` → PlanView `SnapMarker`/Marquee, Defaults aus `theme/accents.ts`, Projekt-MüM-Feld `referenceElevationMasl`); der einzig offene Punkt (Snap/Endpunkt-Default „aki") ist längst entschieden (2026-07-04: Sora #5FA1C9, s. „❓ Offene Rückfragen"). Zeile war stehen geblieben, obwohl die Frage schon geschlossen war.
 - [ ] **Bildschraffur:** ambientCG/CGI-Colorfiles als Quelle (Material-Lib WIP — erst nach Freigabe); Bild-Filter Sättigung/Helligkeit/Kontrast/SW (`image.filters`).
 - [x] ~~**Tragwerk-Start: Stützen (Column) — MVP end-to-end**~~ (DOSSIER-Audit A4) — **erledigt 2026-07-07:** `Column`/`ColumnProfile` (rect/round) als platzierte Profil-Extrusion, `Project.columns`, `columnFootprint()` (gemeinsame Geometrie 2D/3D/Selektion/Transform), `columnVerticalExtent` (UK/OK-Anker wie Wand). Platzieren via BIM-Ribbon-Befehl (`column`, Alias stütze; Default Rect 0.3×0.3, Höhe=Geschosshöhe, Rechteck/Rund-Toggle + Live-Vorschau), 2D-Poché auf Kat. 50 (`addColumnPoche`, Component/Hatch-Auflösung), 3D-Prisma (`emitColumns`, synchron, Rust unberührt), eigener Selektionskanal (ALLE Reset-Stellen gespiegelt), `ColumnSection` (Profil/Masse/Höhe/Drehung editierbar), Löschen/move/copy/mirror, DXF-Layer, i18n. +8 Tests (2D-Position/Rotation, 3D-Box/Prisma, vertikale Lage). tsc/vitest 422. **Bewusst ausgelassen:** 3D-Pick (wie ExtrudedSolid), Marquee, Schedule-Zeile, eigene ToolId (Extrude-Muster gefolgt). **Noch uncommittet. Nutzer prüft 3D/2D visuell.**
 - [x] ~~**Schnellexport-Dialog (Format + Dateiname) für Topbar-Export**~~ (Nutzer-Wunsch) — **erledigt 2026-07-07:** Klick auf CSV/IFC/OBJ/STL im Topbar-Export-Menü öffnet jetzt `ExportSaveDialog` (Format-Dropdown + Dateiname-Feld, Endung folgt dem Format, Enter/Speichern), statt sofort mit Default-Namen zu laden. PDF/DXF behalten ihre eigenen Options-Dialoge. `runExport(format, filename)` in App.tsx erzeugt+lädt. +i18n `exportSave.*`. tsc/vitest 434. **Offen (bewusst, Nutzer nannte es selbst als Folge):** echter Speicherort-Picker („wo") braucht den nativen Tauri-Save-Dialog (plugin-dialog/fs, Rust) — aktuell Download-Ordner + frei wählbarer Dateiname; die späteren „Ausschnitte" bekommen vordefinierten Namen+Ort. **Noch uncommittet.**
 - [x] ~~**Nativer Tauri-Speichern-Dialog für Exporte**~~ (Nutzer „ausnahmsweise JA") — **erledigt 2026-07-07:** `@tauri-apps/plugin-dialog`+`plugin-fs` eingebunden (Cargo/lib.rs/capabilities `dialog:allow-save`+`fs:allow-write-text-file`, `cargo check` grün), Util `src/io/saveFile.ts` (`saveTextFile`: unter Tauri nativer „Speichern unter"-Dialog `save()`+`writeTextFile`, sonst Blob-Fallback mit octet-stream + verzögertem revoke; +2 Tests). App.tsx-`downloadTextFile` ruft jetzt `saveTextFile` (Import ergänzt). **Nutzer testet den nativen Dialog in Tauri.** **Scope-Hinweis:** falls fs-Scope-Fehler, `fs:scope` `$HOME/**` nachrüsten. **Noch uncommittet.**
 - [x] ~~**Ausschnitte liessen sich nicht speichern (Tauri)**~~ — **erledigt 2026-07-08:** Ursache `window.prompt` ist im Tauri-WKWebView DEAKTIVIERT (→ null, kein Name, nichts gespeichert). `ViewSnapshotsPanel` nutzt jetzt In-App-Inline-Eingaben statt prompt/confirm (Speichern + Umbenennen inline, Löschen ohne confirm). tsc/vitest 465.
 - [x] ~~**Layouts als Ordner-/Baumstruktur**~~ — **erledigt 2026-07-08:** Modell additiv `LayoutFolder{id,name,parentId?}` + `Layout.folderId?` + `Project.layoutFolders?`; freie Grösse `customWidthMm?`/`customHeightMm?` an Layout UND MasterLayout (übersteuert paper/orientation), zentraler Helfer `effectiveSheetSizeMm()`. Pure Logik `layoutModel.ts`: `buildLayoutTree`, `collectFolderLayouts`, `deleteFolder` (Kinder reparent auf Elternebene), `folderPdfPages`. `LayoutsPanel.tsx` als Baum (auf/zuklappbare Ordner, Master als eigener Vorlagen-Abschnitt), EIN „＋"-Dropdown {Ordner·Layout·Masterlayout}, neues Element landet SOFORT im Inline-Rename (ViewSnapshotsPanel-Muster, kein window.prompt). Zwei Erstell-Dialoge (`LayoutCreateDialogs.tsx`): Layout mit Master-Vorlage-Dropdown ODER freie Grösse (A4/A3/Custom-mm); Masterlayout mit Format/freie Grösse+Ausrichtung. **Ordner→Mehrseiten-PDF funktioniert:** `src/export/layoutPdf.ts` (`buildFolderPdf`/`saveFolderPdf`, jsPDF, `addPage` je Layout mit eigener Grösse, Viewports via generatePlan→planToPrintSvg, Master-Titelblock als Vektor), neuer `saveBinaryFile` in `saveFile.ts` (nativer Speichern-Dialog für PDF-Bytes). +14 Tests (Custom-Grösse, Ordner-CRUD, Baumaufbau inkl. verwaister Refs, Reparenting, PDF-Seitenplan). **Nachtrag (Orchestrator):** `LayoutSheet.tsx` (In-Viewport-Editor, vom Agent bewusst nicht angefasst) nutzte noch `sheetSizeMm(layout.paper,...)` ohne Custom-Grösse zu respektieren — auf `effectiveSheetSizeMm(master ?? layout)` umgestellt (identische Regel wie der PDF-Export), damit Blätter mit freier Grösse auch im Viewport korrekt dargestellt werden. tsc/vitest 505. **Noch uncommittet. Nutzer prüft visuell in Tauri** (＋-Menü, Ordner-Zuordnung, Dialoge, Mehrseiten-PDF-Reihenfolge/Grössen).
 - [x] ~~**Icons/A0-A6+B0-B6/aktiver Ordner/Drag&Drop im Layouts-Baum**~~ — **erledigt 2026-07-08:** eigene inline-SVG-Icons (`FolderIcon` auf/zu, `LayoutSheetIcon`, `MasterSheetIcon` mit Stern-Akzent), Muster wie die bestehenden Tab-Icons. `LayoutPaperFormat` volle ISO-216-Reihe A0–A6+B0–B6 (`PAGE_MM`/`PAPER_FORMATS`/`PAPER_FORMAT_GROUPS`), Dropdowns gruppiert A-/B-Reihe. „Aktiver Ordner" war schon korrekt (verifiziert, keine Änderung nötig). HTML5-Drag&Drop (Layout/Ordner zwischen Ordnern, Root-Drop, Ziel-Highlight) mit Zyklus-Schutz (`isDescendant`, `moveFolderToFolder` verwirft Selbst-Verschachtelung als No-op). `layoutPdf.ts`/`LayoutSheet.tsx` bekommen die neuen Formate automatisch (laufen über `effectiveSheetSizeMm`/`PAGE_MM`, kein Hardcoding). +14 Tests. tsc/vitest 519. **Noch uncommittet. Nutzer prüft visuell.**
 - [x] ~~**Ausschnitte-Panel: Footer-Bar + Anwahl-Persistenz**~~ — **erledigt 2026-07-08 (Agent starb erst beim Schluss-Testlauf, aber vollständig verdrahtet + grün):** Footer im ViewSnapshotsPanel zeigt bei angewähltem Ausschnitt Massstab, passende Ebenen-/Zeichnungskombi (Deep-Equal `boolMapEqual`/`matchingComboName` gegen gespeicherte Combos), aktive Override-Namen, + Inline-Rename in der Footer-Bar. Anwahl bleibt markiert bis Abweichung: `selectedViewSnapshotId`-State + `snapshotMatchesLiveState`-Vergleich in App.tsx (bei Änderung eines erfassten Feldes → Auswahl weg). host.ts um `selectedViewSnapshotId`/`listLayerCombos`/`loadLayerCombo`/`listDrawingCombos`/`loadDrawingCombo` erweitert. tsc sauber, vitest 532 (+13). **Noch uncommittet. Nutzer prüft visuell.**
 - [x] ~~**Ausschnitte-Panel: Ordner wie bei Layouts**~~ — **erledigt 2026-07-08:** echte Ordner-/Baumstruktur (spiegelbildlich zu Layouts). Modell additiv `ViewSnapshotFolder{id,name,parentId?}` + `ViewSnapshot.folderId?` (altes `folder?`-Namensfeld bleibt LEGACY-kompatibel), `Project.viewSnapshotFolders?`. Pure Baum-Logik `src/state/viewSnapshotFolders.ts` (`buildViewSnapshotTree`/`moveSnapshotToFolder`/`moveFolder` mit Zyklus-Schutz/`deleteFolder`-Reparent, +20 Tests). Panel: auf/zuklappbare Ordner, zwei Header-Buttons (FolderPlus/Plus), aktiver-Ordner-State, Inline-Rename, Löschen, Drag&Drop. **Footer-Bar + Anwahl-Persistenz UNVERÄNDERT erhalten** (unter dem Baum). +i18n. tsc/vitest 558. **Noch uncommittet. Nutzer prüft visuell.**
 - [x] **2D-Zeichnen auf „Zeichnung"-Ebenen UND auf Layout-Blättern freigeben; 3D/BIM dort sperren (Nutzer-Wunsch 2026-07-08):** ✅ **ALLE drei Teile erledigt 2026-07-08.** **TEIL B erledigt 2026-07-08:** 2D-Annotationen (Linie/Rechteck/Text in mm-Papier) direkt auf Layout-Blättern — `LayoutAnnotation` an `Layout` (additiv) + CRUD (`layoutModel.ts`: create/add/remove/patchAnnotation) + Editor in `LayoutSheet.tsx` (Tool-Buttons, zeichnen/Vorschau/commit, `pickAnnotation`/`translateAnnotation` in `layoutSheetMath.ts`, Selektion+Verschieben+Löschen, HUD mit Farbe/Stärke, `PromptDialog` für Text — kein window.prompt) + Handler in App.tsx. Tests: `layoutModel.test.ts` + `layoutSheetMath.test.ts`, Suite 588 grün. Bewusst ohne: Resize-Griffe, Text-Rotation, Snapping, Sheet-Clamping beim Verschieben. **TEIL A erledigt 2026-07-08** — die 2D-Zeichenwerkzeuge (select/line/polyline/rect/circle/arc/text) sind bereits nicht `floorOnly`, die zugehörigen Commands (line/rect/polyline/circle/arc/text) auch nicht → die Command-Engine erlaubt das Zeichnen auf jeder Ebene, und eine `"drawing"`-Ebene rendert schon die volle interaktive `LevelPlanView` (App.tsx:5515). Der einzige echte Blocker war das UI-Gating: die **ToolsPanel-Sidebar** sperrte ALLE Werkzeuge ausser „select", sobald `!toolsEnabled` (App.tsx `activeLevel.kind === "floor"`). Fix: `ToolsPanel.tsx` gatet jetzt per `tool.floorOnly && !toolsEnabled` — **Parität mit dem Ribbon** (`RibbonBar.tsx`, das schon so gatete). Damit sind auf „drawing"-Ebenen die 2D-Tools nutzbar, BIM/3D-Tools (wall/ceiling/window/door/stair/room/column, alle `floorOnly`) bleiben grau. `AttributesPanel.tsx:78` bleibt unverändert (gatet nur den Wandtyp/Deckentyp-Picker, der ohnehin nur bei floorOnly-Tools erscheint). Verifiziert: `tsc` sauber, `vitest` 558/558. TEIL B (grösser, OFFEN): **auf Layout-Blättern 2D zeichnen** — der `LayoutSheet`-Viewport-Editor kann bisher nur Viewports platzieren; für Annotationen (Linien/Text/Rechtecke direkt aufs Blatt) fehlt ein Annotations-Datenmodell am `Layout` + das Zeichnen/Rendern auf dem Blatt (mm-Koordinaten). Scope Teil B mit Nutzer/als eigene Phase. **TEIL C erledigt 2026-07-08 („endlich"): Text-Platzierungswerkzeug als 2D-Element.** Das `{shape:"text"}`-Drawing2D-Modell + Rendering (`generatePlan` → `drawingText`) + Transform (`transform.ts` `at`) existierten schon (DXF-Import-Weg); es fehlte nur das PLATZIER-Werkzeug. Umgesetzt: neues `text`-Command (`src/commands/cmds/text.ts`: Ankerpunkt klicken → Freitext in der Command-Line eingeben → commit `Drawing2D {shape:"text", height:0.25m, angle:0}`), Placeholder-Tool `text` (nicht floorOnly) gekoppelt via `TOOL_COMMAND`, in Registry + Aliase (tx/txt/beschriftung) + `ToolId` + `TOOL_ORDER` + Ribbon-2D-Gruppe + ToolIcon (Serifen-A) + i18n (de/en). Neu: die Command-Engine routet jetzt Freitext-Eingabe (`AcceptKind` um `"text"` erweitert, `engine.ts` `routeTypedInput` reicht bei `accepts:["text"]` die getippte Zeile 1:1 durch — vor der numerischen Auflösung, damit auch Zahlen/Kommas als Label ankommen). Nutzer-Test: Text-Tool wählen → in den Plan klicken → Label tippen → Enter. **Noch uncommittet, WASM-unabhängig (rein TS).**
 - [ ] **Masterlayout im Viewport ansehen + Elemente darauf platzieren (Nutzer-Wunsch 2026-07-08) — NACH Rollback+Footer-Agenten (gleiche Dateien LayoutsPanel/LayoutSheet):** ein Masterlayout soll wie ein Layout im `LayoutSheet`-In-Viewport-Editor geöffnet werden können, um Plankopf-Elemente/Rahmen VISUELL darauf zu platzieren (statt nur über ein Formular mit festen Titelblock-Textfeldern). `LayoutSheet.tsx` arbeitet aktuell nur mit `Layout` (hat `viewports: LayoutViewport[]`); für Master fehlt sowohl das Öffnen im Viewport als auch ein Datenmodell für frei platzierbare Grafik-/Text-Elemente (Plankopf-Felder, Rahmen-Linien) auf dem Master. Scope/Umfang mit Nutzer klären, bevor gebaut wird: welche Elementarten (Text-Feld mit Platzhalter-Variable wie {ProjectName}/{Scale}/{Date}, Linie/Rechteck als Rahmen, Logo/Bild?), wie sie sich von den normalen `LayoutViewport`s unterscheiden (kein Ausschnitt-Bezug, rein grafisch), Doppelklick-Navigation vom `LayoutsPanel` aus zum Öffnen eines Masters im Viewport (analog `onOpenLayout`).
 - [x] ~~**LayoutsPanel: Doppel-Name + zwei Buttons je Abschnitt + Master in Ordnern**~~ — **erledigt 2026-07-08:** Doppel-„LAYOUTS" behoben durch Umbenennung des ÄUSSEREN Panel-Titels auf „Mappe" (DE) / „Portfolio" (EN, neuer Key `layouts.panelTitle`); innere Abschnitte bleiben „Layouts"/„Masterlayouts". Kombiniertes „＋"-Dropdown ersetzt durch zwei Icon-Buttons je Abschnitt: `FolderPlusIcon` (Ordner) + `PlusIcon` (Layout bzw. Masterlayout). Masterlayouts jetzt in eigenen Ordnern: `MasterLayout.folderId?` + `LayoutFolder.kind?:"layout"|"master"` (fehlt=layout, rückwärtskompatibel), getrennte Bäume (`buildMasterTree`, kind-Filter), eigener `activeMasterFolderId`. Bug gefixt: `deleteFolder`/`moveFolderToFolder` verloren `kind` beim Reparent → `stripParentId`. +6 Tests. PanelFrame unangetastet. tsc/vitest 538. **Bewusst offen:** Drag&Drop im Master-Baum (bestehende Master nur beim Anlegen in Ordner). **Noch uncommittet. Nutzer prüft visuell.**
 - [x] ~~**Fixer, unlöschbarer „Masterlayout"-Ordner**~~ — **VERWORFEN 2026-07-08 (Nutzer-Kurskorrektur):** gebaut, dann sofort zurückgebaut — Nutzer sah die bestehende Lösung (Masterlayouts als separate Kategorie/Abschnitt ausserhalb der Ordnerstruktur, aus dem vorherigen Layouts-Agenten) live und wollte sie explizit BEHALTEN, keinen Ordner. Vollständig zurückgerollt (`layoutModel.ts`/`LayoutsPanel.tsx`/`App.tsx`/i18n), verifiziert tsc sauber + vitest exakt Baseline 519 (keine Regression). Masterlayouts bleiben separater Abschnitt.
 - [x] ~~**`window.prompt`/`confirm` überall ersetzen (Tauri-WKWebView deaktiviert sie) — SWEEP**~~ — **erledigt 2026-07-08:** neue generische `src/ui/PromptDialog.tsx` (Muster ExportSaveDialog: Overlay+Dialog, Enter bestätigt, Esc schliesst) ersetzt ALLE verbliebenen `window.prompt`-Aufrufe: `ComboMenu` (TopBar, Ebenen-/Zeichnungskombination speichern), `LayoutMenu` (Arbeitsumgebung speichern), Text-Grösse „frei" (`TextGroup`), Massstab „frei" (`ViewRibbonTab`), sowie die Tastatur-Flows O/P (Array-Kopien/Verteilen-Anzahl, `App.tsx`: `promptCount()` entfernt, ersetzt durch `pendingCopyMode`-State + Dialog). `window.confirm` war bereits an allen Fundstellen vorher entfernt (ViewSnapshots/LayoutsPanel). Verifiziert: `grep -rn 'window\.prompt(\|window\.confirm('` über src/ liefert NICHTS mehr. tsc sauber, vitest 491/491. **Noch uncommittet.**
 - [x] ~~**Layout im Viewport editierbar (wie ArchiCAD/VW/OpenCADStudio) — Phase 2b**~~ — **erledigt 2026-07-08 (Agent-verifiziert, NICHT visuell abgenommen):** Blatt jetzt erstklassiger Ansichtsmodus im Haupt-Viewport (`activeLayoutId` in App.tsx → `LayoutSheetView` statt Content), schwebendes `LayoutEditor`-Fenster ENTFERNT. Maus-Editing (`LayoutSheet.tsx`): Viewport aufziehen→Ausschnitt-Bindung (Inline-Dropdown, kein prompt), auswählen/verschieben/8-Griff-Resize (Commit bei Pointer-Up, Live-Ghost), löschen (Entf), Massstab-HUD; Pan (Mitte/Space)/Zoom-to-Cursor/Einpassen. Pure Transform+Hit-Test `layoutSheetMath.ts` (+26 Tests). `LayoutsPanel` window.prompt/confirm ebenfalls auf Inline umgestellt. +i18n `layouts.*`, CSS `.layout-sheet-*`. tsc/vitest 491, vite build OK. **NOCH VISUELL IN TAURI ZU PRÜFEN.** Offen: Einrasten an Kanten/Nachbarn, Ribbon-Massstab wirkt im Layout-Modus nicht (nicht deaktiviert). **Noch uncommittet.**
 - [x] ~~**Layout-Blätter mit Masterlayout — Phase 2a**~~ (A3, setzt auf Ausschnitte auf) — **erledigt 2026-07-08:** Modell `Layout`/`LayoutViewport`/`MasterLayout` + `Project.layouts`/`masterLayouts` (im Dokument). `LayoutsPanel` (Layouts+Master anlegen/umbenennen/löschen, im Rechts-Dock, `LAYOUT_VERSION` 10→11). `LayoutEditor` (schwebendes Fenster wie ResourceManager): Blatt im mm-Seitenverhältnis (Zoom/Einpassen), Titelblock (Master-Vererbung via `resolveTitleBlock`, leere Felder → Defaults Projektname/Blattname/Massstab/Datum), und jeder Viewport rendert ECHT den Plan seines gebundenen Ausschnitts via `generatePlan`→`planToPrintSvg` (viewBox-mm = Viewport-mm, 100%-Einpassung + Clipping). Viewport hinzufügen (Ausschnitt-Picker)/entfernen, Position/Grösse/Massstab numerisch; Papier/Ausrichtung/Master pro Blatt. +16 Tests (Blatt-Geometrie, immutables CRUD, Master-Vererbung, mm-Geometrie). +i18n `layouts.*`. **Ehrliche Grenzen:** Live-Viewport-Render nur per Code korrekt, NICHT im Browser abgenommen (Nutzer prüft); Ausschnitte auf Schnitt/Ansicht (activeLevelId≠Geschoss) → leerer Plan (nur Grundriss-Ausschnitte füllen den Viewport); Titelblock-Font ≠ PDF-Helvetica (Phase-2b-PDF baut es separat). **Bewusst Phase 2b:** Multi-Page-PDF-Export, Maus-Drag/Resize der Viewports, „Alle aktualisieren", erweiterte Kamera-POV (Augen-/Zielhöhe). tsc/vitest 465. **Noch uncommittet.**
 - [x] ~~**Ausschnitte / View-Snapshots — Phase 1**~~ (A2, Fundament) — **erledigt 2026-07-07:** `ViewSnapshot` (name/folder + viewType/view3d/fov/scaleDenominator/detail/activeLevelId + Ebenen-/Zeichnungs-Sichtbarkeit + aktive Override-Ids) am `Project.viewSnapshots` (im Dokument). Pure Capture/Apply-Logik `src/state/viewSnapshots.ts` (+8 Tests: Roundtrip, defensives Auffüllen, Override-Menge). App.tsx: Capture sammelt View-State + `snapshotLayer/DrawingVisibility` + aktive Overrides; Apply Reihenfolge Geschoss→View→Sichtbarkeit→Overrides, Massstab-Zoom per 1 rAF. Neues `ViewSnapshotsPanel` (Liste/Ordner, Speichern/Umbenennen/Löschen), registriert im Default-Rechts-Dock (`LAYOUT_VERSION` 9→10). +i18n `viewsnap.*`. **Bewusst offen Phase 2:** Layout-Blätter+Masterlayout (A3), Viewport-Platzierung + Ausschnitt-Bindung, „Alle aktualisieren", Multi-Page-PDF, erweiterte Kamera-POV (Augen-/Zielhöhe getrennt), Ordner-Drag&Drop; Apply erzeugt mehrere Undo-Schritte (bekannt). **Noch uncommittet.**
 - [x] ~~**IFC-Wände nicht solid (oben/unten offen)**~~ — **erledigt 2026-07-07:** ECHTE Ursache war eine invertierte Wicklung, NICHT eine fehlende Fläche — der Y-up→Z-up-Achsen-Swap im IFC-Export (`(mx,my,mz)→(mx,mz,my−base)`) ist eine Reflexion (Determinante −1) und kehrte jedes Dreieck um → Normalen nach innen → Viewer cullt Vorderseiten → hohl. Fix: beim Swap Dreieck umdrehen (`i0,i2,i1`). `Closed=.T.` gesetzt, verifiziert über `isWatertight` (`wallMeshCut.ts`): NICHT der naive „jede Kante von 2 Dreiecken"-Test (der meldet die legitimen T-Stösse aus vollen Deckel/Boden-Streifen fälschlich als offen), sondern das T-Stoss-robuste Gauss-/Divergenz-Kriterium `∮n dA=0` + signiertes Volumen >0. STL/OBJ waren korrekt (kein Swap). +15 Tests (Wasserdicht/Winding, inkl. IFC-Face-Set-Volumen aus dem geparsten SPF). tsc/vitest 449, cargo check grün. **Noch uncommittet. Nutzer prüft im Viewer.**
 - [x] ~~**Exporte an 3D angleichen: Öffnungen ausschneiden + Joins (STL/OBJ/IFC)**~~ (Nutzer: „es sollte so raus wie es im 3d ist") — **erledigt 2026-07-07:** neuer TS-Helfer `src/plan/wallMeshCut.ts` portiert `render3d/mesh.rs::extrude_layer_segment_with_holes` 1:1 (Koordinaten-Kompression `solidSubrects`, Langseiten/Deckel/Boden/Stirnkappen minus Loch-Intervalle, bis zu 4 Laibungsquads pro Loch, konsistentes Winding). STL/OBJ: Wände mit `holes` → ausgeschnittenes Mesh (sonst klassische Box); Joins kommen aus `pickGeometry`. IFC: Wände als `IfcTriangulatedFaceSet` (IFC4, gespeist aus demselben Loch-Mesh) → sichtbar wie 3D in JEDEM Viewer (behebt „Void nicht subtrahiert"); Tür/Fenster bleiben eigene `IfcDoor`/`IfcWindow`-Objekte, die das Loch füllen; IfcOpeningElement/Void/Fill entfallen (Loch steckt im Mesh). +12 Geometrie-Tests (Loch-Region hat keine Voll-Wand-Dreiecke, Laibungen vorhanden, dangling-refs grün). tsc/vitest 434. **Ehrliche Rest-Lücken:** echte Miter-Gehrungsflächen (Export nutzt die achsparallele pickGeometry-Näherung), Schicht-Farben (IFC-FaceSet ohne per-Vertex-Farbe/IfcStyledItem), Fensterglas/Rahmendetail. **Noch uncommittet. Nutzer prüft im Viewer.**
 - [x] ~~**Layout-Auswahl in die Einstellungen, umbenannt „Arbeitsumgebung"**~~ — **erledigt 2026-07-07:** `LayoutMenu` (Fenster-/Dock-Layouts) aus der TopBar-Zeile in `SettingsDialog` verschoben (neue erste Sektion), `layoutMenu`-Prop von TopBar → SettingsDialog umgehängt (ReactNode-Import in TopBar entfernt, da sonst ungenutzt). i18n `layout.*` umbenannt (DE „Arbeitsumgebung", EN „Workspace") + neue `settings.section.workspace`. tsc/vitest 423. **Noch uncommittet.**
 - [x] ~~**Export-Sammelmenü + Über-Dialog + Petrol-Punkt (TopBar-Feinschliff)**~~ — **erledigt 2026-07-07:** (1) Die 6 einzeln aufgereihten Export-Icons (PDF/DXF/CSV/IFC/OBJ/STL) zu EINEM „Export"-Knopf (`ExportMenu`, `ios_share`) mit Dropdown-Popover zusammengefasst — entschlackt die Chrome-Zeile; Import bleibt separat. (2) Klick auf die Wortmarke „dossier" öffnet einen In-App-„Über"-Dialog (`AboutDialog`: Marke, Version 0.1.0, Kurzbeschreibung, OSS-Lizenzen; Esc/Klick-ausserhalb schliesst). Wortmarke ist jetzt `<button>` (Chrome zurückgesetzt, Optik identisch). +i18n `file.export`/`about.*`, CSS (`tb-menu`/`about-*`). tsc/vitest 422. **Fix (Nutzer-Report „IFC nicht anwählbar"):** Popover per `createPortal` nach body (entkommt dem Topbar-Stacking-Context, der die unteren Einträge unter dem Ribbon verdeckte) + zweiter `popRef` im Outside-Click-Handler (sonst schloss der mousedown das Menü vor dem Klick) — Muster wie `ContextMenu`/`Dropdown`. **Hinweis:** In-App-Dialog statt nativem macOS-About-Panel (das bräuchte ein Rust-Command in src-tauri) — falls der native Panel gewünscht ist, Folge-Item. **Noch uncommittet.**
 - [x] ~~**Brand-Punkt petrolgrün**~~ — **erledigt 2026-07-07:** `.brand-dot` fix `#0f766e` (petrolgrün wie DOSSIER-Rhino-Plugin) statt `var(--accent)`. Feinton per Nutzer justierbar.
 - [x] ~~**OSM-Import auf 7 Kategorien**~~ — **erledigt 2026-07-07:** 3 neue Kontext-Kategorien im Overpass-Import — `parking` (amenity=parking, Fläche), `railway` (railway~rail|tram, Linie), `forest` (landuse=forest + natural=wood, aus `green` herausgelöst; `green` jetzt nur Parks/Wiesen). `OsmSelection`/`buildQuery`/`categorize`/`isClosedCategory` (osm.ts), `GeoCategory`/Labels/Layer (geoContext.ts), 3 Checkboxen (ContextImportDialog.tsx), i18n `ctxImport.src.*`. tsc/vitest 414. **Noch uncommittet.**
 - [x] ~~**IndexedDB-Persistenz-Kern**~~ — **erledigt 2026-07-07:** `src/state/projectStore.ts` — async CRUD `saveProject`/`loadProject`/`listProjects`/`deleteProject` über IndexedDB (DB „dossier"/Store „projects", keyPath name, `{name,savedAt,project}`), guard-sicher (fehlt `indexedDB` → degradiert: load→null/list→[]/save+delete no-op, 1× warn) — läuft daher auch in vitest/node. +7 Guard-Tests (414). **UI-Wiring (Speichern/Öffnen-Menü, Recent-Liste, Auto-Save) NOCH OFFEN — Folge-Item.** **Noch uncommittet.**
 - [x] ~~**ObjectInfo Wand: UK/OK-Reihenfolge vertauscht**~~ — **erledigt 2026-07-07:** im Wand-Abschnitt steht jetzt OK (Oberkante) oben, UK (Unterkante) darunter — räumlich passend (Nutzer-Report „stimmt visuell nicht überein"); Decken-Abschnitt hatte die Reihenfolge schon → jetzt konsistent. Reiner JSX-Reorder. tsc/vitest 414. **Noch uncommittet.**
 - [x] ~~**STL- + OBJ-Export (3D-Mesh, Interop)**~~ — **erledigt 2026-07-07:** pures Modul `src/export/exportMesh.ts` (`exportObj`/`exportStl`, ASCII-STL) aus `pickGeometry(project)` (echte 3D-Geometrie inkl. Joins/Decken-Dominanz): Wand-Bänder als 12-Dreieck-Boxen, Decken/Extrusionen als triangulierte Prismen (bestehender `triangulate()` aus glPlanCompile, kein WASM), y-up rechtshändig. Voll verdrahtet: Quick-Access-Buttons (`view_in_ar`/`landscape`) + `onExportObj`/`onExportStl` in App.tsx (Blob-Download) + i18n `file.exportObj`/`file.exportStl`. 8 Kern-Tests (Index-Bounds, facet/vertex-Konsistenz, Tri-Zahl-Plausibilität). tsc/vitest 407. **Bewusste v1-Limitation:** Öffnungslöcher NICHT ausgeschnitten (Wände volle Boxen) — ladbar in Blender/MeshLab, aber nicht öffnungsgenau; öffnungsgenaue Variante = Folge-Item. Extrusionen nutzen Prisma-Triangulierung statt async truckSolid-WASM (bewusst, wegen synchronem pure-Kern). **Noch uncommittet.** (IFC-Import + DWG-Schreiben bleiben offen.)
 - [x] ~~**Raumstempel: Personenzahl + Flächen-Rundung**~~ — **erledigt 2026-07-07:** `RoomStamp.occupancy?`/`roundingStep?` (additiv, optional). `formatStampArea(area, step?)` in `roomStamp.ts` rundet auf Vielfache von `step` (0.01/0.1/0.5/1 m²), sonst 2 Nachkommastellen wie bisher; Personenzahl als „{n} Pers."-Zeile im Stempel. Editor-Zeilen (Dropdown Rundung + Zahlfeld Personen). Drag&Drop-Builder bleibt out of scope. +6 Tests, +i18n. tsc/vitest 399. **Noch uncommittet.**
 - [x] ~~**Auto-Zoom nach Geo-Import**~~ — **erledigt 2026-07-07:** nach swisstopo/OSM/Terrain-Import (`onAddContextObjects`) passt die Plan-Ansicht automatisch auf die neuen Objekte ein. `PlanViewHandle.fitBounds(pts)` (dünner Wrapper um `fitBoxFor`), `contextObjectsBounds()` bildet die Gesamt-BBox über alle neuen ContextObjects (contourSet-Punkte + Mesh-/Terrain-Positions, Z ignoriert), `addContextObjectsAndFit` in App.tsx verdrahtet. DXF-Import-Pfad (eigene viewCenter-Logik) bewusst unberührt. Kein i18n, host.ts unverändert. tsc/vitest 393. **Noch uncommittet.**
 - [x] ~~**Rich-Text Hoch-/Tiefstellung (super/sub)**~~ — **erledigt 2026-07-07:** zwei Toolbar-Buttons in `RichTextEditor.tsx` (Muster der bestehenden B/I/U/S-Buttons; super/sub-Exklusivität war im Modell `richText.ts::applyMark` schon gelöst); +i18n `rt.super`/`rt.sub`. Teil des ROADMAP-Items „Rich-Text-Annotationen" (Maskierung/Rahmen bleiben offen/blockiert). tsc/vitest 393. **Noch uncommittet.**
 - [x] ~~**B2 — Objekt-Info numerisch erweitern**~~ — **erledigt 2026-07-07:** im ObjectInfo-Panel sind X/Y jetzt editierbar (Commit verschiebt die Selektion so, dass der gewählte Bezugspunkt auf die Koordinate wandert, via neuem Host-Callback `onMoveSelectionBy`), dazu ein Dreh-Feld (`RotateField`, Delta-Grad um den Anker, `onRotateSelectionAround`) und für einzelne Drawing2D-`line`/`circle` ein Längen- bzw. Radius-Feld (`onSetDrawingLineLength`/`onSetDrawingCircleRadius`). Move/Rotate nutzen die bestehende `commitTransform`-Maschinerie (transform.ts unverändert), wirken für wall/drawing2d/extrudedSolid; für ceiling/opening/stair/room ist der Aufruf No-op (Feld rendert, revertiert — gleiches Muster wie das bestehende Breite/Höhe-Resize). +i18n. tsc/vitest 393. **Noch uncommittet.**
 - [x] ~~**Komponenten-Thumbnail: PBR-Kugel-Vorschau (D3-Rest)**~~ — **erledigt 2026-07-07:** ComponentsTab-Listeneintrag + Detail-Preview in `ResourceManager.tsx` zeigen jetzt bei gesetztem `component.material` die live gerenderte PBR-Kugel (`ComponentMaterialSphere`, lazy via IntersectionObserver + `requestMaterialPreview`, Muster von `MaterialLibraryTile`); `materialAssetOf` löst `libraryId` gegen `MATERIAL_LIBRARY` auf, sonst Ad-hoc-Asset aus den eigenen Map-URLs. Fallback-Kette Material→Hatch→Color unverändert. Nur `ResourceManager.tsx`, kein i18n. tsc/vitest 393. **Noch uncommittet.**
 - [ ] **E2b Schraffur-Kachel-Motiv** (MotifEditor für HatchStyle-Tile wiederverwenden).
 - [x] ~~**Linienstile aufräumen**~~ — **erledigt (2026-07-05):** die drei funktional identischen 0.13-Volllinien (`thin`/`hatch-line`/`joint-massive` — alle weight 0.13, `dash:null`, gleiche Farbe) auf EINE kanonische „Volllinie 0.13" (`thin`) zusammengeführt; alle weight-only-Stile klar als „Volllinie X.XX" benannt; Schraffur-Referenzen (`hatch-line`→`thin`, inkl. `ResourceManager.patToHatches`) + Schichtfugen (`joint-massive`→`thin`) remappt; `hatch-dash` (einzige gestrichelte) bleibt. Ids stabil gelassen (geladene Projekte + interne Refs bleiben heil; Rendering-Gewichte unverändert). 7→5 Stile. tsc + Suite 331 grün.
 - [ ] 2D-Plan z-Anordnen (Kombo-Schraffuren); Bild-Schraffur GL/DXF (heute Fallback).
 - [ ] **AUSSCHNITTE- + LAYOUT-SYSTEM (Nutzer-Vision 2026-07-07, grosser Hebel).** Zwei zusammenhängende Systeme (DOSSIER A2→A3, ROADMAP §7 Phase 3 + §11 Pläne):
  - **Ausschnitte / View-Snapshots (A2):** benannte, gespeicherte Ansichten, die einen kompletten Darstellungszustand einfangen und wiederherstellen. **Kern-Einsicht des Nutzers: das muss NICHT neu erfunden werden — die Bausteine existieren schon und werden nur KOMPONIERT:** ein Ausschnitt = Referenz/Snapshot auf {**Ebenenkombination** (`src/state/visibilitySets.ts` `LayerCombo`) + **Zeichnungsebenen-Kombination/-Einstellungen** (`DrawingCombo` ebd.) + aktive **Overrides**-Regelmenge (`Project.overrideRules`, A1) + Kamera/Ansichtstyp/View3d + **Massstab** + **Detailgrad**}. Also im Wesentlichen ein Container, der diese bereits vorhandenen Zustände bündelt, benennt (Ordner/Presets) und per Klick wiederherstellt. Speicherort: Projekt (nicht localStorage — Ausschnitte gehören zum Dokument). Voraussetzung für die halbe Pläne-Tabelle (Layouts, Multi-Page-PDF, Detail-Bindung, Massstab-pro-Viewport).
  - **Layout-System mit Masterlayout + Layouts (A3):** Druck-/Plan-Blätter (A4/A3-Papierformate), auf denen mehrere **Details/Viewports** platziert werden, jedes an einen Ausschnitt-Snapshot gebunden (bei „Alle aktualisieren" ziehen sie nach). Ein **Masterlayout** (gemeinsame Elemente: Titelblock/Planrahmen/Logo/Plankopf, wie Vorlagen-Master in InDesign/ArchiCAD) wird von den einzelnen **Layouts** geerbt/überlagert — Änderung am Master schlägt auf alle Layouts durch. Pro Layout eigener Massstab pro Viewport (Auto-DPI, Plotweight-/Schraffur-Skalierung, `sceneToPrintSvg.ts` als Basis), PDF-Export pro Blatt bzw. Multi-Page.
  - **Erweiterte Kamera-Settings als Teil des Ausschnitts (Nutzer 2026-07-07):** mehr einstellbare Kamera-Parameter, die der Ausschnitt MIT speichert — u. a. **Zielhöhe** und **Augenhöhe** (Eye/Target-Z getrennt), FOV, Blickrichtung/Distanz; die Parameter dürfen **pro Projektionsart unterschiedlich** sein (Perspektive vs. Isometrie/Ortho haben je eigene sinnvolle Sets — Iso braucht z. B. orthoHalfHeight statt FOV/Augenhöhe). Heutiger Zustand: nur FOV global (`fov` in App-State, CameraMenu) + Orbit-State intern im `Wasm3DViewport` (`OrbitState` yaw/pitch/dist/target, `orthoHalfHeight`) — nicht als benannte, persistierbare Kamera-Definition nach aussen geführt. Schritt dazu: Kamera-Zustand als serialisierbares Objekt exponieren (get/set am Viewport), UI-Felder (Augenhöhe/Zielhöhe/Distanz) im Kamera-Popover, dann im Ausschnitt-Modell mitführen.
  - **Phasen-Vorschlag:** (1) Ausschnitt-Datenmodell + Speichern/Wiederherstellen (komponiert die bestehenden Combos/Overrides/View-State) + Ausschnitte-Panel (Liste/Ordner, wie `visibilitySets`-Muster). (2) Masterlayout + Layout-Blatt-Modell + Viewport-Platzierung, Viewport→Ausschnitt-Bindung. (3) Master-Vererbung + „Alle aktualisieren" + Multi-Page-PDF@DPI. Mit Nutzer Detailgrade/Papier-Defaults/Ordnerstruktur festlegen.
 - [ ] **SCHNITTEBENEN als editierbare, gekoppelte Objekte (2D↔3D) — Nutzer-Vision 2026-07-07 „ein richtig ausgereiftes Tool".** Schnittebenen sollen sichtbare, im Grundriss platzier- und editierbare Objekte sein, die 2D-Schnitt und 3D-Live-Schnitt verbinden. Bausteine der Vision (verbindlich festhalten):
  - ✅ **Phase 1 erledigt 2026-07-17 (Kopplung + Navigation, KEIN Rust — plan: `.claude/plans/cozy-bubbling-goose.md`):** der 3D-Live-Schnitt (`Wasm3DViewport`) folgt jetzt der gewählten Schnittlinie statt einer fest verdrahteten horizontalen Ebene — die Engine kann beliebige Ebenen längst (`set_section_plane(point,normal)`), es fehlte nur die Bindung. App-State `section3dCutId` + abgeleitete `section3dPlane` via `sectionPlaneFromLevel` (world point+normal aus `linePoints`/`directionSign`, `plan/toSection.ts`) → durch `Viewport3D`→`Wasm3DViewport` (neue Props `section3d`/`onClearSection3d`). Schalter „Im 3D schneiden" in der Schnittlinien-Sektion des Objekt-Info-Panels (`host.section3dCutActive`/`onToggleSection3dCut`); der Viewport-Overlay-Knopf ist an die aktive Linie gebunden und hebt sie auf. **Doppelklick auf die Schnittlinie im Grundriss → springt in die 2D-Schnittansicht** (`PlanView.onOpenSectionLevel` → `onSelectLevel`). 2D-Editieren (Endpunkte/Blickrichtung/Tiefe) existierte schon im Objekt-Info. `tsc` + `vitest` 866 grün. **Nutzer prüft visuell in Tauri** (render3d-Pfad).
  - ✅ **Phase 2 Teil „eigene Ebene / Sichtbarkeit" erledigt 2026-07-17:** eine unsichtbare Schnitt-/Ansichtsebene (`visible===false`) zeigt ihre Führungslinie im Grundriss nicht mehr (`addSectionLines` in `generatePlan.ts`, +1 Test). Ein-/ausblendbar wie andere Ebenen (Zeichnungsebenen-Panel).
  - **Offen Phase 2 (engine-schwer, mit Nutzer im Tauri-Loop):** Farbe der 3D-Schnittebene + **Cut-away-Schleier/Schraffur auf der weggeschnittenen Seite** (wgpu-Shader/`section_fill.rs`/`section.rs`) — blind über Nacht bewusst NICHT gebaut (unverifizierbar ohne Tauri-Sicht, s. Arbeitsstil „Nutzer prüft render3d visuell").
  - **Offen Phase 3 (engine-schwer):** 3D-POV je Schnitt (Augen-/Zielhöhe/Winkel getrennt, pro Projektionsart) im Datenmodell + eigenes 3D-Schnittfenster (Doppelklick 3D-Symbol → Clip+Kamera); koppelt an das Ausschnitte-/Kamera-System. Kamera-Kopplung an `Wasm3DViewport`-Orbit → Tauri-Verifikation nötig.
  - Restliche Vision-Bausteine (unverändert offen):
  - **Eigene Zeichnungs-/Grafik-Ebene „Schnittebenen":** die Schnittlinie des 2D-Schnitts liegt auf einer eigenen Ebene (ein-/ausblendbar wie andere Layer). Auch die 3D-Schnittebene wird im GRUNDRISS als Objekt dargestellt (Linie/Symbol) — vor allem, um die 3D-Schnittebene dort PRÄZISE zu setzen (im 2D positionieren statt im 3D fummeln).
  - **3D-Schnittebene über Topbar ein/aus** (existiert teilweise: Viewport-Toggle) + **Farbe**; alles HINTER der Ebene (die weggeschnittene Seite) wird mit einer **Misch-/Andeutungsschraffur umhüllt**, damit visuell klar ist, dass dieser Teil abgeschnitten wird — sowohl im 3D als auch als Vorschau im 2D.
  - **Doppelklick auf eine Schnittebene → springt in die zugehörige Schnitt-Ansicht:** 2D-Schnittebene-Symbol → 2D-Schnittfenster; 3D-Schnittebene-Symbol → 3D-Schnittfenster (Perspektive/Ansicht mit gesetzter Clip-Ebene). Zwei Objektarten, zwei Zielansichten, gleiche Interaktion.
  - **3D-Schnitt-POV-Parameter:** die 3D-Schnittebene definiert zusätzlich Blickpunkt (POV), **Augenhöhe** + **Zielhöhe** (getrennt) und **Blickwinkel** — dieselben erweiterten Kamera-Settings wie im [Ausschnitte-System oben] (dort pro Projektionsart mitgespeichert). Ein Schnitt ist damit ein Ausschnitt mit Clip-Ebene + Kamera-Definition.
  - Verknüpfung: baut auf dem bestehenden 2D-Schnitt (`DrawingLevel kind:"section"`, `linePoints`/`directionSign`) + der 3D-Live-Schnittebene (`03f0c40`, Clip-Uniform) auf; koppelt eng mit dem Ausschnitte-/Layout-System (View-Snapshots) und den erweiterten Kamera-Settings. Grosses, phasenweises Feature — mit Nutzer Reihenfolge/Scope festlegen (zuerst: 3D-Schnittebene als 2D-Grundriss-Objekt platzier-/editierbar + Doppelklick-Navigation).
 - [ ] **AUDIT (DOSSIER-Studie):** ~~A1 Override-Regel-Engine~~ ✅ (2026-07-07, s. Erledigt); A2→A3 View-Snapshots → Print-Layout-Blätter (PDF pro Blatt); A5 reichere Öffnungen; B1 Text-Werkzeug (+ Kreis-Tool → Shortcuts 1&3); A4 Tragwerk; B2 Object-Info numerisch. (A6 Bauteil-Schedule-CSV erledigt; D2 volles Element-Set erledigt 2026-07-07.) Belege in `/tmp/dossier-ref/rhino/*.py`.
 - [ ] Elemente im Schnitt anwählbar; render3d 2D-Schraffur auf 3D-Flächen.
 - [ ] **TEAMWORK — kollaboratives Bearbeiten (Supabase self-hosted).** Projekte auf einem self-hosted Supabase-Stack speichern; mehrere Nutzer bearbeiten dasselbe Projekt gleichzeitig. Kernkonzept: **pessimistisches Object-Locking** (wie Revit Worksharing / ArchiCAD Teamwork) — alle Objekte sind zunächst gesperrt; ein Nutzer *reserviert* die Elemente, die er bearbeiten möchte (exklusiver Schreibzugriff), und *gibt sie frei*, sobald er fertig ist. Freigabe → sofort für alle anderen sichtbar via Supabase Realtime (WebSocket-Kanal). Kein Merge-Konflikt nötig, weil niemals zwei Nutzer dasselbe Objekt gleichzeitig schreiben. Grobe Schichten:
  - **Auth + Projekt-Liste:** Supabase Auth (Email/Magic-Link), Projektübersicht, Öffnen/Schliessen.
  - **Lock-Service:** Tabelle `object_locks (project_id, object_id, user_id, locked_at)` mit Row-Level Security; `reserveObjects(ids[])` / `releaseObjects(ids[])` als Supabase-RPC; Optimistisches Check-in via DB-Constraint (doppelte Reserve → Fehler → UI-Feedback).
  - **Realtime-Sync:** Supabase Realtime-Channel pro Projekt; bei Freigabe werden die veränderten Objekte (JSON-Patch oder ganzes Objekt-Payload, TBD) gepusht; lokaler Store merged incoming changes sofort.
  - **Presence:** Wer ist online, wer hat welche Objekte reserviert (farbige User-Badges an reservierten Elementen im Plan).
  - **Offline-Guard:** Beim Verbindungsabbruch Locks automatisch nach Timeout freigeben (DB-seitig: `locked_at + interval` prüfen).
  - **Umfang/Granularität TBD mit Nutzer:** Object = Wand/Raum/Drawing2D-Element? Geschoss? Layer? Feinere Granularität = mehr Parallelarbeit, aber komplexeres UI.
  - **Aufwand:** gross (2–4 Wochen echte Arbeit). Erst sinnvoll, wenn Kern-CAD-Features stabil. Mit Nutzer Granularität + Hosting-Setup klären bevor Implementierung startet.
 - [x] ~~**2D-Zeichnungen (`drawings2d`) fehlen im nativen render3d/WASM-Pfad bei z=0.**~~ — **erledigt 2026-07-06:** Nutzer-Report — früher wurden 2D-Plan-Elemente auch im 3D als flache Referenz bei z=0 gezeigt, das gab es nur noch im alten three.js-Fallback (`addDrawing2DLines`), nicht im nativen `render3d`/wgpu-Pfad (heute Standard-Renderer). Fix OHNE Rust-Änderungen: neuer Emitter `emitDrawingLines` (`src/plan/toWalls3d.ts`) baut je 2D-Zeichnung (line/polyline/rect — Parität zu `drawing2DSegments` im three.js-Fallback, Kreis/Bogen/Text bewusst aussen vor) ein dünnes Ribbon-Mesh (2 Dreiecke je Segment, `DRAWING_LINE_HALF_WIDTH` 0.008 m) knapp über der Geschossebene (`DRAWING_LINE_ELEVATION_EPS` 0.01 m), Farbe via `drawingColor3d` (color→LineStyle→Kategorie, wie `drawing2DColor`) → hexToRgb. Läuft über den bereits bestehenden generischen `RMesh`/`MeshInput`-Kanal (`kind:"imported"`, `append_context_mesh` rendert ohnehin doppelseitig) — kein neuer Rust-Typ nötig. `tsc`/`vitest` 339/339 grün. **Nutzer-bestätigt** (2026-07-06, Tauri-Dev-App selbst getestet): Linien aus dem 2D-Grundriss sichtbar in der Perspektive. **Noch uncommittet.**
 ### 3D-REST (engine-schwer, bewusst NICHT blind — mit Nutzer angehen)
 - [x] ~~**Wand-Joins in 3D**~~ — **erledigt 2026-07-07:** `toWalls3d.ts` wendet jetzt die per-Schicht-Cuts aus `computeJoins` (pro Geschoss, `computeJoinsByFloor`) auf den layered-3D-Pfad an — dieselben Zahlen wie generatePlan im 2D: End-Cuts/Merge an L-/T-Stössen (Band-Mittellinie geschnitten, Kern läuft bis zur Rückgrat-Nahfläche durch, Putz trimmt), Durchgangswand-Span-Cutouts (Band zerfällt in Achsen-Teilstücke). **Decken-Dominanz per Schicht** (Scope-Erweiterung): `trimWallTopForCeilings` (kappte die ganze Wand) ersetzt durch per-Schicht-z-Subtraktion analog `subtractDominantBands` — Wand behält volle Höhe, nur Bänder mit strikt niedrigerer joinPriority verlieren das Decken-z-Intervall (Kern läuft durch; dominiertes Band spaltet vertikal in unter/über). Öffnungs-Löcher je Teilstück korrekt rebased. Rust unverändert (Boxen parametrisch). Pick/Highlight jetzt konsistent verschnitten. vitest 383 (25 in toWalls3d.test). **Auslassung ehrlich:** Achsenbox bildet gekippte Miter-Stirnfläche nicht exakt ab (Band-Länge = Mittellinien-Schnitt) — passgenau bei rechten/stumpfen Winkeln, kleine Rest-Approximation an sehr spitzen. **Noch uncommittet.** **Nutzer prüft visuell in der Tauri-App.**
 - [x] ~~**Decken-Schnitt in 3D schneidet zu viele Schichten („Kranz durch die Dämmung")**~~ — **erledigt 2026-07-07:** `collectCeilingCutters`/`emitWall` in `toWalls3d.ts` prüft jetzt PER BAND, ob die Decken-Outline die Band-Mittellinie (`wall.start + u·t + n·offset`) im Grundriss überdeckt — via vorhandenem `pointInOutline` (`geometry/ceiling.ts`), Achse in ~5-cm-Schritten gerastert + Bisektion an den Überdeckungsgrenzen (neue Helfer `bandCoverageIntervals`/`bisectBoundary`); nur überdeckte Achs-Teilstücke bekommen den Decken-z-Schnitt, unbedeckte behalten volle Höhe. Repliziert `subtractDominantBands` (echter geometrischer Überlapp statt wandweiter BBox). Am Sample: Backstein/Innenputz (innen) geschnitten, Dämmung/Aussenputz (aussen) laufen voll durch — kein Kranz. Die 3 falschen Alt-Tests des Vorgängers korrigiert (kodierten „alle Schichten geschnitten"), +2 neue (Voll-Überdeckung schneidet weiterhin alle; Teil-Längen-Überdeckung splittet entlang der Achse). Schnitt-Pfad/L-T-Joins/holes/Rust unberührt. tsc sauber, vitest 393. **Noch uncommittet. Nutzer prüft visuell.**
 - [~] **3D-Live-Schnitt: echte Bauteil-Schraffuren statt prozeduralem 45°-Muster (Nutzer-Wunsch 2026-07-07).** — **implementiert 2026-07-08 (wartet auf visuelle Nutzer-Verifikation nach WASM-Rebuild).** Der ganze Weg von der 2D-Hatch-Definition bis in den wgpu-Cap-Pass ist gelegt: `toWalls3d.ts` bildet je Materiallage/Decke via neuem `hatchPatternId()`/`resolveComponentHatch()` (aus `getHatch(comp.hatchId)`) ein `Hatch{pattern,angle,scale}` → `WallInput.hatch`/`SlabInput.hatch` (additiv, `#[serde(default)]`) → `section.rs` reicht es über `Prism`→`CutPolygon.hatch` → `section_fill.rs` schreibt es je Cap-Vertex (`CAP_FLOATS_PER_VERTEX` 5→8: `[pos,u,v,pattern,angle_rad,scale]`) → `gpu.rs` Cap-Pipeline-Vertexlayout erweitert → `shaders.rs` `CAP_WGSL` wählt prozedural das Muster: `0 none`→weiss, `1 solid`→Vollton (Beton-Poché), `2 diagonal`→45° (bitgleich zum alten Muster bei angle=0/scale=1 → rückwärtskompatibel), `3 crosshatch`→Kreuz, `4 insulation`→Zickzack. Monochrom (Tinte auf Papier, nur MUSTER variiert — bewusst keine Farbe). Da der 3D-Viewer je Schicht EINE Box emittiert (`layeredWalls:true`), trägt jede geschnittene Schicht ihr eigenes Muster; ohne aufgelöste Schraffur → Fallback-Diagonale. `cargo test -p render3d --features render` 63 grün (+2 section_fill-Tests, WGSL-Validierung inkl. Cap-Shader). **WASM (`npm run build:engine3d`) noch NICHT gebaut (brauchte Netz) — Nutzer muss rebuilden + Tauri-Dev neu starten, sonst greift nichts.** `cargo check --target wasm32 --features web` grün. **Noch uncommittet.**
 - [ ] **3D-Snapping beim Ziehen (Nutzer-Wunsch 2026-07-07): alle Elemente sollen im 3D auf andere Punkte einrasten.** Heute rastet das 3D-Griff-Ziehen NICHT ein — es projiziert die Maus nur frei auf eine Ebene (`rayPlaneY`/`rayPlane` in `src/viewport/Wasm3DViewport.tsx:576-582`); Snap wurde beim 3D-Griffsystem bewusst weggelassen (three.js-Snap blieb 2D-exklusiv). Nutzer nennt konkret: **Wände** beim Verschieben auf andere Punkte snappen, **Decken** ebenso, „eigentlich alle Elemente". Gewünscht ist also eine gemeinsame 3D-Snap-Schicht (Kandidatenpunkte: Wand-Endpunkte/Ecken, Decken-Eckpunkte, Extrusions-/Öffnungs-Anker, evtl. Rasterpunkte), gegen die der gezogene Griff/Körper im Weltraum einrastet — analog zur 2D-Snap-Infrastruktur (`computeSnap` in `src/tools/snapping.ts`). Zu klären mit Nutzer/Scope: welche Snap-Ziele in 3D (nur Endpunkte oder auch Kanten/Flächen/Raster?), Snap-Radius im Bildschirm- vs. Weltraum, visuelles Feedback (3D-Snap-Marker), und ob die 2D-`computeSnap`-Kandidatenlogik wiederverwendbar ist oder eine eigene 3D-Variante braucht. Betrifft `Wasm3DViewport.tsx` (Drag-Pfad) + neue 3D-Snap-Hilfsschicht; die Store-Callbacks (`onEdit3dVertex`/`onEdit3dBody`/`onEdit3dWallTop`) bleiben.
 - [~] **Textur-/PBR-Pipeline** (Sampler/Bindings/UV in wgpu; dann `textured`-Style + `Component.texture3d`/Material echt rendern). ✅ **Erster Durchstich** (`0ca3b1d`, Schachbrett). ✅ **Farb-Textur-Array implementiert 2026-07-08 (wartet auf visuelle Nutzer-Verifikation nach WASM-Rebuild):** Statt Schachbrett zeigt eine Wand mit zugewiesenem Material jetzt dessen Farb-Map. Voller Weg: `WallInput.materialIndex: Option<u32>` (1-basiert; 0 = Schachbrett-Fallback) → `mesh.rs` `build_scene_mesh_textured()` füllt je Vertex die Material-Ebene (dieselben Extrusionsfns → Geometrie-Parität) → `gpu.rs`: Schachbrett-Textur zu `texture_2d_array` erweitert, `set_material_textures()` baut `[Schachbrett, Mat0, Mat1, …]`, zweiter Vertex-Buffer für die Ebene → `shaders.rs` `MESH_TEXTURED_WGSL` samplt die Array-Ebene je Band (`layer<0`→Schachbrett) → `web.rs` WASM-Export `set_material_textures(rgba, layer_count)` → TS: `wallMaterialColorMaps()`/`resolveComponentMaterialLayer()` (deterministische Array-Ordnung), neuer `src/viewport/materialTextures.ts` dekodiert die Farb-Maps im Browser (ImageBitmap→Canvas→getImageData 256²), `useWasm3dRenderer.updateModel` lädt sie asynchron hoch (Signatur-Cache, Fallback auf Schachbrett bis geladen). **Ehrlich als Rest:** nur Farb-Map (keine Normal-/Roughness-/Metalness → Beleuchtung wie Shaded); der native Tauri-Push (`nativeSync.ts`) lädt keine Texturen → dort Schachbrett-Fallback (das WASM/Nordstern-Viewport im „Texturiert"-Modus hat den vollen Weg). `cargo check --target wasm32 --features web` grün, `cargo test` 63 grün. **WASM noch NICHT gebaut (Netz) — Nutzer: `npm run build:engine3d` + Tauri-Neustart.** **Verbleibende PBR-Lücken (~15–25 PT):** Normal-/Roughness-/Metallic-Maps + Cook-Torrance-BRDF + Tangentenraum ~5–8 · Mipmaps (Blit-Pass) + anisotropes Filtern ~1–2 · Bild-Datei-Laden serverseitig statt Browser-Dekodierung ~1–2 · nativer Tauri-Textur-Push ~2–3 · UI/Persistenz-Feinschliff ~5–8. **Noch uncommittet.**
 - [x] ~~**Wand-Schicht-Bänder in 3D** Option B~~ — **bereits umgesetzt** in `resolveWallBands(layered=true)` (`src/plan/toWalls3d.ts:236-241`): 3D-Viewer-Pfad liefert je Materiallage ein eigenes `WallBand` (Dicke + Component-Albedo + Normalen-Versatz), `pushSegment` emittiert jede Lage als eigene Voll-Box. `dominantLayerColor` ist nur noch Fallback für den Schnitt-Einkörper-Pfad (`layered=false`). Verifiziert per Code-Lesung.
 - [x] ~~**Ortho-Ray-Picking**~~ — **erledigt 2026-07-07:** `cameraRay` (`src/viewport/raycast3d.ts`) war IMMER ein perspektivischer Pinhole-Strahl (ein Ursprung `eye`, Richtung variiert je Pixel) — für Front/Top/Side/Iso-Presets (die render3d orthografisch zeichnet) nur eine Näherung. Fix: `cameraRay` nimmt jetzt optional `perspective`/`orthoHalfHeight` (neue optionale Felder auf `RayCamera`, rückwärtskompatibel — fehlt `perspective`, bleibt das Verhalten exakt wie vorher) und baut bei `perspective:false` echte PARALLELE Strahlen (Ursprung wandert lateral mit dem Pixel, Richtung immer `f` — exakte Umkehrung von `worldToScreen`s bereits vorhandenem Ortho-Zweig). Beide Aufrufer in `Wasm3DViewport.tsx` (Klick-Pick + Griff-Drag) reichten schon das volle `orbitCamera(o)`-Objekt (inkl. `perspective`/`orthoHalfHeight`) durch — der Bug sass rein in `cameraRay`, keine Änderung an den Aufrufstellen nötig. +2 Tests (`raycast3d.test.ts`: parallele Strahlen, Rückwärtskompatibilität ohne `perspective`-Feld). `tsc`/`vitest` 341/341 grün.
 - [x] ~~**3D-Griffe/Editieren im nativen render3d/wasm-Pfad**~~ — **erledigt 2026-07-06:** existierte bereits vollständig im three.js-Fallback (`Viewport3D.tsx`/`drawGrips`), fehlte aber im nativen wasm-Pfad (`Wasm3DViewport.tsx`, seit `WASM_ENGINE_ACTIVE` der Standard-Renderer) — genau wie beim drawings2d-z0-Fund oben eine „existiert, aber auf dem falschen Pfad"-Lücke. Feasibility-Spike (Nutzer-Entscheid „Spike jetzt starten") zuerst nur Wand-Endpunkte, dann auf volle Parität ausgebaut: Wand-Endpunkt-/Höhen-/Verschiebe-Griff + 2D-Zeichnungs-Vertex-/Verschiebe-Griff, dieselben App.tsx-Callbacks (`onEdit3dVertex`/`onEdit3dBody`/`onEdit3dWallTop`) wie die three.js-Sicht. **Wichtige Design-Korrektur unterwegs:** erster Versuch zeichnete Griff-Marker als In-Szene-Geometrie (3-Achsen-Kreuz, dann Drahtgitter-Kugel) über den bestehenden `setHighlightLines`-Kanal — Nutzer-Feedback zweimal `"immernoch kein GUI button sondern geometrie"`: nicht klar genug als klickbarer Punkt erkennbar UND farblich identisch mit dem Auswahl-Umriss auf derselben Ecke. Gelöst durch Umstieg auf ECHTE DOM-Buttons (`position:absolute`-Kreise über dem Canvas, Farben wie drei.js: Vertex orange/Höhe blau/Verschieben grün), deren Bildschirmposition ein `requestAnimationFrame`-Loop aus der aktuellen Kamera nachführt (`worldToScreen`, neue Umkehrfunktion zu `cameraRay` in `raycast3d.ts`) — kein WASM/GPU-Push nötig, nur 2D-Projektionsmathe. Ziehen läuft über `rayPlaneY`/`rayPlane` (neu in `raycast3d.ts`) + dieselben Store-Callbacks. `drawingGripVertices`/`drawingMoveAnchor` nach `src/viewport/drawingGrips.ts` ausgelagert (gemeinsam von beiden Renderern genutzt, sonst zyklischer Import). **Bewusst NICHT gebaut:** Snap/Koinzidenz-Mitführen beim 3D-Ziehen (bleibt three.js-exklusiv). `tsc`/`vitest` 339/339 grün. **Nutzer-bestätigt** (Wand-Endpunkt-Drag funktional in der Tauri-App getestet, dann Marker-Sichtbarkeit korrigiert). **Noch uncommittet.**
 ## ❓ Offene Rückfragen (an den Nutzer)
 - [x] ~~**„aki"** Snap/Endpunkt-Farbe~~ — **entschieden 2026-07-04: Sora #5FA1C9** als endgültiger Default festgeschrieben (`src/theme/accents.ts` `DEFAULT_SNAP_COLOR`, Doc aktualisiert). Frage geschlossen.
 - [ ] Floating-ResourceManager „headless" = ganz ohne Titelleiste? (aktuell MIT)
 - [ ] Geo-Block: Projekt-MüM zuerst oder Nordstern-Geo-Rendering?
 - [ ] Verifizieren/klären: Isometrie „echte" orthographische Iso (teilw. durch Locked-Iso `cb8fae5` adressiert)? · TopBar-Detailgrad (zoom% ganz aus Footer)? · DOSSIER-Audit welche Features konkret übernommen?
 ---
 ## ✅ Erledigt (Verlauf, neueste oben)
 _Nur jüngste Session; ältere Historie siehe `git log` und HANDOVER-Narrative._
 - [x] 2026-07-17 **Schnittebenen 2D↔3D — Phase 1 (Kopplung + Navigation) + Phase-2-Sichtbarkeit** (uncommittet) — der 3D-Live-Schnitt folgt jetzt der gewählten Grundriss-Schnittlinie statt einer fest verdrahteten horizontalen Ebene (`Wasm3DViewport`/`Viewport3D` neue Props `section3d`/`onClearSection3d`; App-State `section3dCutId` → `sectionPlaneFromLevel`). „Im 3D schneiden"-Schalter im Objekt-Info (`host.section3dCutActive`/`onToggleSection3dCut`), Viewport-Knopf an die Linie gebunden. Doppelklick auf die Schnittlinie → 2D-Schnittansicht (`PlanView.onOpenSectionLevel`). Unsichtbare Schnitt-/Ansichtsebene blendet ihre Grundriss-Linie aus (`addSectionLines`). `tsc` + `vitest` 867 grün (+1). Cut-away-Schleier/Farbe (Phase 2) + POV/3D-Schnittfenster (Phase 3) bewusst offen (engine-schwer, Tauri-Verifikation nötig — s. Backlog-Eintrag). Nutzer prüft Phase 1 visuell in Tauri. UI-Nebenarbeit derselben Session (uncommittet): Werkzeug-Panel (Symbole/Liste-Umschalter, neue SIA-Icons, helle Auswahl), Topbar-Quick-Access-Icons entfernt (dupliziert das native Menü), Zahnrad→Einstellungen in Zeichnungsebenen/Ebenen-Köpfen, Footerbar + Snap-Marker + Maß-HUD auf die helle Pillen-Sprache umgestellt.
 - [x] 2026-07-12 **swissBUILDINGS3D-Import auf Suchradius zugeschnitten** (`31b76a2`) — Nutzer-Frage „importiert es wirklich georeferenziert, oder landet alles am 0-Punkt?" Live gegen die echte STAC-API geprüft: Georeferenzierung selbst war KORREKT (`geocode`/`makeOrigin`/`shiftMeshToOrigin` liefern echte, nicht-triviale LV95-Koordinaten). Echter Bug daneben gefunden: eine STAC-Kachel liefert ALLE Gebäude der Kachel als EIN Mesh (`parseDxf` sammelt alles in denselben Puffer) — ohne Zuschnitt landete bei jedem Import die KOMPLETTE Kachel im Modell, bis zu mehreren km über den Suchradius hinaus (verifiziert: zwei 1.4 km auseinanderliegende Adressen derselben Kachel lieferten VORHER identische, ungeschnittene 62'532-Dreiecke-Geometrie). Neues `clipMeshToBbox` (`swissBuildings3d.ts`) schneidet + kompaktiert auf den gesuchten Radius. +4 Tests, Suite 827 grün.
 - [x] 2026-07-12 **Fenster/Tür: 2D+3D setzen "aussen" jetzt auf dieselbe Wandfläche** (`a631dda`) — Nutzer-Report „im 2D innen bündig und im 3D aussen bündig". Root Cause: das 2D-Vorzeichen für `insetFace:"aussen"` (`windowSymbol` in `geometry/opening.ts`) war gegenüber der ECHTEN Aussenschicht der Wand (erste Wandtyp-Schicht, kleinster Achs-Offset in `addWallPoche`/`pushSegment`) invertiert — landete am inneren statt äusseren Wandputz. Dieselbe Verwechslung steckte auch in `addOpeningFrameBand` (Tür-Rahmenband), den Sturzlinien und dem Rollladenkasten (alle in `generatePlan.ts`) — alle vier gefixt. Die 3D-Seite (`openingAxisBox`/`resolveFrameNormalRange` in `toWalls3d.ts`) war bereits korrekt (zwei kompensierende Vorzeichen ergaben zufällig das richtige Ergebnis) und blieb unverändert. +1 Regressionstest, der 2D- und 3D-Rahmenposition direkt gegen die bekannte Aussenschicht der Wand prüft (statt nur relative Deltas). Suite 823 grün.
 - [x] 2026-07-12 **Georeferenzierung: persistenter Standort-Bezug statt Neuberechnung je Import (Teil-Fix)** (`ae47b4f`) — erster Design-Punkt aus dem GEO-BLOCK-Report umgesetzt. Neues `Project.geoAnchor` (`{lv95, model, label?}`) verbindet einmalig „dieser LV95-Punkt = dieser Modellpunkt"; der ERSTE Import in einem Projekt setzt ihn automatisch, alle folgenden Importe (`ContextImportDialog`) verwenden denselben Anker statt je unabhängig `makeOrigin(center)` neu zu berechnen — behebt die Lage-Inkonsistenz zwischen mehreren Importen in einem Projekt. `tsc` sauber, Suite 794 grün. **Bewusst Teil-Fix:** Anker sitzt immer bei Modell-(0,0), es gibt noch kein Werkzeug, um ihn auf einen beliebigen, vom Nutzer gewählten Modellpunkt zu legen — bleibt offen.
 - [x] 2026-07-12 **Kontext-Meshes (importierte Gebäude/Terrain) im 3D-Viewport anwählbar** (`e6a7738`) — zweiter Design-Punkt aus dem GEO-BLOCK-Report umgesetzt. Raycast/`pickGeometry` (`raycast3d.ts`/`toWalls3d.ts`) um Kontext-Meshes erweitert (rohe Dreiecke aus `project.context`, kaputte Indizes robust übersprungen), neuer Auswahl-Kanal `selectedContextObjectIds` (Store-Slice + `onViewport3dPick`-Zweig, konsistent in ALLE bestehenden Auswahl-Reset-Stellen eingehängt), Highlight als achsenparallele Bounding-Box (volles Dreiecks-Wireframe wäre bei importierten Gebäuden mit tausenden Dreiecken unbrauchbar dicht), Entf-Taste löscht die Auswahl (reused `project.context`-Filter im bestehenden Lösch-Handler), `SitePanel`-Liste hebt die im 3D gewählte Zeile hervor (`host.selectedContextObjectIds`). +9 Tests (`raycast3d.test.ts`, `toWalls3d.test.ts`), Suite 803 grün, `tsc` sauber. **Bewusst nicht umgesetzt:** Ebenen-/Layer-Zuordnung (`categoryCode` an `ImportedMesh`/`TerrainMesh`), volle Attribut-Panel-Integration (`deriveSelection()`) — als eigener, grösserer Schritt eingeschätzt, s. „🔧 In Arbeit" oben.
 - [x] 2026-07-12 **3D-Ansicht: „Schattiert mit Kanten" (BIM-Look) + Fix falscher Flächendiagonalen** (`a84dc7a`+`7dc8f0d`) — neuer `RenderStyle::ShadedEdges` (render3d): Bauteilfarben + dunkle Modell-Kanten obenauf, wie Revit/ArchiCAD. Direkt danach Nutzer-Report: sichtbare Dreiecks-Diagonalen auf Dach/Fensterglas im neuen Modus. Root Cause: Kontext-Meshes (Dach/Glas/Rahmen, auch swissBUILDINGS3D-Import) werden wegen aktivem Backface-Culling IMMER doppelseitig aufgebaut (`mesh.rs::push_ctx_tri`, Dreieck + gespiegelte Rückseite) — jede Kante bekam dadurch ein exakt entgegengesetztes Normalen-Paar, das die Knick-Erkennung fälschlich als Kante wertete. Fix in `edges.rs::should_draw`: Rückseiten-Duplikate (dot≈-1) werden vor der Rand-/Knick-Entscheidung zusammengeführt. +11 Rust-Tests, 88/88 grün (`--features render`). **Drei Folgepunkte dabei entdeckt, noch offen** (s. „🔧 In Arbeit" oben): Fenster-Rahmenecken/Dach-First ohne sauberen Verschnitt (vermutlich fehlende Boolean-Union, kein Kanten-Bug), OG-Wandflächen mit vielen vertikalen Strichen (nicht diagnostiziert).
 - [x] 2026-07-12 **swissBUILDINGS3D-Import repariert: Absturz + eigentlicher „funktioniert nicht"-Bug** (`35a6834`+`9705890`) — zwei getrennte, echte Bugs gefunden und behoben. (1) Harter Absturz (JSZip „Invalid string length") bei Kacheln, deren ENTPACKTE Grösse (DXF komprimiert stark) die max. JS-String-Länge sprengt, obwohl die ZIP-Grösse selbst unter dem Limit lag — `downloadAssetText` prüft jetzt zusätzlich die JSZip-interne Grössenschätzung und fängt alle Fehler sicher ab; übersprungene Kacheln landen sichtbar in `skippedTiles`/einer UI-Meldung statt eines stummen Leer-Ergebnisses. (2) **Der eigentliche Grund, warum der Import nie Gebäude lieferte:** die installierte `dxf-parser`-Version liefert Polyface-Mesh-Face-Indizes als vier einzelne Felder (`faceA..faceD`, Gruppencodes 71–74) statt als erwartetes `faces`-Array — `addPolyfaceMesh` prüfte auf ein Array, das nie existierte, jede swissBUILDINGS3D-DXF-Kachel (exakt dieses Format) ergab dadurch 0 Dreiecke. Live gegen echte Kacheln verifiziert (vorher 0 Meshes, jetzt tausende Dreiecke mit realistischen Höhenwerten). +3 Tests mit rohem DXF-Text (deckt auch die zugrundeliegende Bibliothek ab), Suite 794 grün. **Georeferenzierung und „anwählbares Mesh auf Ebene statt Geo-Panel-Eintrag" bleiben als eigene, ungelöste Design-Fragen offen** (s. „🔧 In Arbeit" oben).
 - [x] 2026-07-12 **Fenster-Grundriss komplett überarbeitet** (`e65a6b7`..`d2758ef`, iterativ über mehrere Live-Prüfungsrunden in Tauri) — Nutzer-Report mit SIA-Referenzbildern deckte mehrere übereinanderliegende Probleme auf, alle einzeln gefixt + verifiziert:
  - Sims/Anschlag-Kerben nutzten pauschal die volle Wandfläche statt der tatsächlichen (ggf. per `insetFromFace` eingezogenen) Rahmen-Aussenkante.
  - Stulp-Marken waren kleine, von der Rahmentiefe unabhängige Quadrate statt Profilquerschnitte über die GANZE Rahmentiefe; die Blendrahmen-Querschnittsblöcke an den Laibungs-Enden fehlten komplett — beide jetzt als `meetingMarks` in `windowSymbol` berechnet (inkl. Laibungs-Enden), `generatePlan.ts` nutzt sie direkt statt einer zweiten, abweichenden Neuberechnung.
  - Zusätzliche `window-mullion`-Trennlinie lag redundant NEBEN dem neuen Rahmenblock (entfernt, für typisierte Fenster reicht der Block; Alt-Pfad ohne Typ behält die Linie).
  - Glaslinie(n) im Feld (mittel: 1, fein: Doppellinie) komplett entfernt — Nutzer wollte dort keine Haarlinie, unabhängig von Detailgrad/Position.
  - Pauschale Brüstungslinie (Wandachse, unabhängig von Rahmenposition) UND die „Oberlicht-Andeutung" (gestrichelt bei `transomHeight>0`, ebenfalls immer auf der Wandachse unabhängig davon ob die Schnittebene den Kämpfer trifft) beide entfernt — architektonisch nicht aussagekräftig für einen horizontalen Grundriss-Schnitt.
  - **Ersatz:** `WindowType.sillLine` — konfigurierbare Auf-/Untersicht-Andeutung (Fläche aussen/innen/beide, Blickrichtung Auf-/Untersicht), an der echten Rahmenkante statt der Wandachse.
  - **Neu:** `Opening.frameLine`/`sashLine`/`sillLineStyle` — Farbe/Strichstärke je Linien-Kategorie (Blendrahmen+Stulp / Flügelrahmen+Sprossen / Sims) im Objekt-Info-Panel einstellbar, Default = bisheriges Verhalten.
  - +~30 Tests über mehrere Dateien, Suite 790 grün.
 - [x] 2026-07-12 **Dach-Wand-Verschneidung (Z-Fighting im 3D behoben)** (`a584911`) — Nutzer-Report mit Screenshot (flackerndes Rausch-Muster wo Wand-Oberkante die Dachschräge kreuzt). Root Cause: Wände bekamen ihre Höhe unabhängig vom Dach, `collectCeilingCutters` kappte nur gegen `project.ceilings`, nie gegen `project.roofs` — wo die geneigte Dachfläche den flachen Wand-Top kreuzte, überlappten sich beide Volumen. Fix: `roofUndersideAt` (`geometry/roof.ts`, Ebenengleichung je Dachfläche + Punkt-in-Polygon) liefert die Dach-Unterkante an einem Grundriss-Punkt; `clipPieceToRoofs` (`toWalls3d.ts`) zerlegt betroffene Wand-Achsenstücke in feine ~15-cm-Schritte und klemmt jeden auf die dort gemessene Unterkante — Treppenstufen-Annäherung an eine echte geneigte Giebelwand-Stirnfläche (render3d-Wandkörper haben nur einen flachen Top; eine echte Schrägfläche bräuchte einen neuen Mesh-Pfad, bewusst nicht gebaut). Ohne Dach im selben Geschoss unverändertes Verhalten. +9 Tests (5 `roofUndersideAt`, 3 Integration inkl. Regressionsfund einer legitim gekappten Putz-Gehrungsspitze im Sample-Projekt), Suite 781 grün. Verwandt: [[design-schicht-verschneidung-3d-schnitt]] (gleiche Kategorie wie „Wand endet an Decke", hier für geneigte statt horizontale Cutter).
 - [x] 2026-07-12 **Fenster-Grundriss grob/mittel/fein nach SIA 400 klar unterschieden** (`13cc6a0`) — Nutzer-Report „mittel und fein sind genau gleich, grob ist viel zu grob" behoben: `windowSymbol` (`geometry/opening.ts`) staffelt jetzt nach SIA 400 Anhang B.9.1 Fig. 36–38 statt DIN — grob (1:100) nur eine Glaslinie, mittel (1:50) Blendrahmen + Flügel-Trennlinien + 1 Stulp-Quadrat je Flügelstoss, fein (1:20) zusätzlich verschachtelte Flügelrahmen + Glas-Doppellinie (Isolierverglasung) + 2 Stulp-Quadrate. `generatePlan.ts` reicht `detail` durch, rendert die neuen Stulp-Marken (`window-stulp`) nur im typisierten Pfad (kein Fake-Stoss bei reinem `wingCount`-Altfall). Referenzdoku `docs/research/sia400-fenster-tueren.md` (Fig.-Transkription aus der SIA-400-PDF, lokal excluded). +9 Tests, Suite 753 grün. Visuell per Puppeteer verifiziert. ✅ **Folge-Fix `e309e54`:** Öffnungssymbol-Kommentare in `toElevation.ts`/`toWalls3d.ts` waren fälschlich „DIN" benannt (Grundlage ist SIA 400 B.9.1.3) — reine Doku-Korrektur, Symbol-Geometrie selbst war bereits korrekt (SIA-PDF zeigt nur Sinnbild-Namen, keine Pfeilgrafiken, daher keine Geometrieänderung). ✅ **Wand-Poché bei „grob" jetzt immer vollschwarz** (`0240a23`, 2026-07-12) — war zuvor nur schwarz, wenn das dominante Bauteil selbst `pattern:"solid"` hatte (bei mehrschichtigen Wandtypen mit Backstein/Dämmung/Verputz blieb es weiss). Fix (unconditional `HATCH_INK` bei grob) von Hermes/Qwen3 geliefert (zweiter Versuch, erster war die o. g. Fehleinschätzung), von mir verifiziert + um fehlenden Regressionstest + Aufräumen der toten `backbonePocheFill`-Hilfsfunktion ergänzt. +2 Tests, Suite 755 grün.
 - [x] 2026-07-11 **Schnitt/Ansicht auf VW-Niveau (grosser Block)** — Schnitt ENTSPIEGELT (`983d061`, u-Achse = Betrachter-Rechts, Rust+TS koordiniert, Engine neu gebaut); Kanten geschnittener Bauteile gefiltert + verdeckte Kanten opt-in (`4c4c990`); Wand-Terminierung wirkt im Schnitt auch bei Decken-ANSCHLUSS ±5 cm (`a612ae5`); Dämmschraffur-Orientierung Wand/Decke korrekt (Sprossen quer zur Schicht, empirisch verifiziert, `a612ae5`+`38a4d8c`). Ansicht als LINIENZEICHNUNG (`c02a02c`): weisse Flächen + XOR-Silhouette (xorOutlineEdges — Teilbox-Innenkanten heben sich auf), Fenster mit Blendrahmen→Flügelprofil→Glas, Sims mit Tropfkante, DIN-Symbole exakt auf den Glasfeld-Ecken (`ee9aeda`). **3D-Öffnungen VW-fein** (Merge `31d7aef`): vorstehende Flügelrahmen, DIN-Symbole auf dem Glas (openingPlaneBox-Prismen), 3D-Fensterbank + Tropfkante, Zargen-Umgriff; Staffelung grob/mittel/fein. Display/Print-Umschalter in allen 2D-Darstellungen. **Offen:** Tauri-Visualabnahme 3D; Schnitt-Auswahl-UX (Treffer nur auf der Poché).
 - [x] 2026-07-11 **Lineale + VW-Zeichen-Feedback komplett** (`1945fec`, `8f85e13`, `7898a0d`, `242b850`) — Lineale oben/links in allen 2D-Ansichten (Meter-Ticks, Cursor-Marker); Cursor-HUD im Programm-Look mit Live-Echo getippter Werte (oben+unten synchron), Tab-Feldwechsel, Direkt-Tippen; Δx/Δy beim Rechteck; lange Führungslinien + Winkelbogen mit 0°-Referenz.
 - [x] 2026-07-11 **Schnitt ausgebaut** (`b86fca2`) — Befehl `sectionline`/`viewline` (Aliase schnittlinie/ansichtslinie, BIM-Ribbon „Schnitte"): zwei Klicks setzen die Schnitt-/Ansichtslinie (neue Ebene bei Bedarf). Schnittführungs-Symbol im Grundriss (Strichpunkt, Endmarken, Richtungspfeile, Label) + Pick-Band; Schnittlinie selektierbar mit Attribut-Sektion (Name, Blickrichtung umkehren, Endpunkte, Tiefe, Löschen/Entf). **Editieren IM Schnitt**: Cut-Polygone tragen die Quell-Element-Id (sourceId, durch Schicht-Zerlegung/Terminierung/Dominanz propagiert) → Klick im Schnitt wählt das Bauteil, Panels editieren, Schnitt rechnet neu. Schnitt-Tiefe `DrawingLevel.depth` (Owner-Distanz-Näherung, TODO exakte Kanten-Tiefe bräuchte section.rs). **Offen:** Endpunkt-Drag-Griffe der Schnittlinie im Grundriss.
 - [x] 2026-07-11 **Ansicht (Elevation) als echte 2D-Darstellung** (`456ecc5`+`a6db682`) — `toElevation.ts`: Painter-Projektion (Fassaden/Decken fern→nah, Rückseiten-Culling, Tiefen-Graustaffelung), Fenster/Türen als Rahmen+Glas, Bodenlinie, **Dächer** (Flächen + Giebel aus roofGeometry) und **Schatten ein/aus** (45°-Schlagschatten auskragender Decken UND Dachflächen, Sutherland–Hodgman-geclippt; Toggle in der Ansichts-Leiste, `DrawingLevel.shadows`). Rein TS/synchron ohne WASM. **Offen:** exakter Hidden-Line statt Painter (dokumentierte Näherung), Material-/viewHatch-Füllungen je Fassade.
 - [x] 2026-07-11 **VW-Zeichengefühl: Cursor-HUD + Winkelraster** (`975ce3f`) — beim Zeichnen L/W-Kästchen am Cursor (`L: 3.118m W: 60.000°`, VW-Stil), weiches Einrasten auf 15°-Vielfache (±2.5°, konfigurierbar) mit Winkel-Badge + gestrichelter Führungslinie; Vorrang Objekt-Snap > Shift/Ortho > Winkelraster > Raster; Toggle in der Fang-Leiste. Das bis dahin nie gerenderte `ToolDraft.hud` lebt jetzt (line/polyline/wall/rect/circle/arc).
 - [x] 2026-07-11 **Dach im 3D anwählbar** (`355c1d4`) + **2D-Schnitt = 3D Wand-Terminierung** (`0e02c2b`) — Ray-Dreieck-Pick über Dachflächen/Giebel; applyWallTermination spiegelt terminateOrSubtractSpans im (u,v)-Schnittraum (below/above kappen an der Decken-UK/OK).
 - [x] 2026-07-10 **Fenster-/Tür-Einstellungsdialog + reiche Öffnungs-Parameter** (`1bbe814`+`c734802`+`2e13ec3`, Studie [docs/design/window-editor-vectorworks-study.md](docs/design/window-editor-vectorworks-study.md)) — Nutzer-Feedback „Fenster/Türen mega mager". Das ⚙ der Öffnungs-Sektion öffnet neu einen dedizierten Dialog (`OpeningEditorDialog.tsx`): Kategorie-Sidebar (Basis/Grösse/Rahmen/Flügel/Sonnenschutz bzw. Türblatt), Flügeltabelle (Flügel/Pfosten + Öffnungsart + Anschlag je Flügel), Live-2D-Frontalansicht, Stil-Leiste mit „Als Stil speichern" (klont Typ → neuer benannter WindowType/DoorType). Modell additiv: `SashDef[]`/`shading`/`glazingPanes` + Helfer `sashesOfWindowType`/`glazingPanesOf`. Renderer konsumiert sie: 2D-Flügeltrennlinien aus Flügelbreiten + Öffnungsandeutung, glazingPanes-Glaslinien, gestrichelte Rollladenkasten-Kontur; 3D mehrscheibige Verglasung. +26 Tests, 659/659 grün. **Offen (P1+, Studie §4):** asymmetrische Rahmenbreiten, Oberlicht/Unterlicht als eigene Felder, Sprossengitter, Bank/Nische, Form (Rund/Spitz), echte wgpu-3D-Vorschau im Dialog, 3D-Rollladenkasten-Box.
 - [x] 2026-07-10 **Dach-3D-Ziehgriffe** (`4ef40a0`) — gewählte Dächer haben im wgpu-Viewport Eckpunkt-Griffe (achsparalleles Resize, Gegenecke fix), einen Verschiebe-Griff und einen First-Griff (vertikal ziehen → Dachneigung, Firstlage bleibt). Store `moveRoofGrip`/`moveRoofBy` (coalescing) + `onEdit3dRoofPitch` (Höhe→Neigung). +3 Tests. Schliesst die „optionale Folge" des Dach-Features (s. u.). **Tauri-Visualabnahme offen.**
 - [x] 2026-07-10 **Messwert im Objekt-Info** (`9b6dd80`) — Live-Messwerte erschienen nicht im Panel; Ursache war ein eingefrorenes Memo (`baseHost`-Deps ohne `draft`). Fix: `measurement` pro Render live in `hostWithMode` injiziert.
 - [x] 2026-07-09 **Dächer (Grundfeature)** (`1195d2a`+`31f2d63`) — Roof-Element + `geometry/roof.ts` (Flach/Pult/Sattel/Walm/Mansarde/Zelt, BBox-basiert, First X/Y). Befehl „Dach" (BIM-Ribbon, Rechteck aufziehen, Form als Inline-Option), 2D-Plan (Traufe/First/Grat/Knick), 3D (emitRoofs, terrakotta), Demo-Dach RF1. +19 Tests. **Offen:** Auswahl/Attribut-Editieren/Löschen (s. „Als Nächstes").
 - [x] 2026-07-09 **Fenster/Tür-Feedback** (`4beae72`+`89e737b`) — Fenster im 3D tiefer (Rahmen füllt Wanddicke, dünne Scheibe mittig); Detailgrad grob/mittel/fein wirkt im 3D; Fenster↔Tür-Umschalter entfernt; platzierte Öffnungen bekommen Standard-Typ (sonst kein Rahmen). Kernursache „sieht im 3D nicht so aus" = fehlender typeId behoben.
 - [x] 2026-07-09 **Decken-Griffe im 3D** (`973ac6d`) — gewählte Decken haben im wgpu-Viewport Eckpunkt- + Kanten-Mittelpunkt-Griffe (rautenförmig, eigene Farbe) + Verschiebe-Griff → moveCeilingGrip/moveCeilingEdge/moveCeilingBy (Store-Actions existierten schon fürs 2D). Neu: 3D-Griffgeometrie (computeGrips), Kanten-Drag (GripDrag „edge"), Prop-Kette Wasm3DViewport←Viewport3D←App (editCeilings/onEditEdge, Ziel um ceilingId). three.js-Sicht unverändert. **Tauri-Visualabnahme offen.**
 - [x] 2026-07-09 **Text-Styling-Leiste wirkt auf Freitext** (`d0b9d22`) — selektierter Freitext/Textspalte (Drawing2D shape „text") ist Formatier-Ziel der Oberleiste: Drawing2D-Text.marks (Schrift/fett/kursiv/Farbe); Grösse bleibt über Modell-Höhe (Meter, nicht pt). App.textTarget adaptiert via docFromText/plainText; generatePlan/PlanView rendern die Marks. +3 Tests.
 - [x] 2026-07-09 **Schichttrennlinie als Wand-Referenzlinie** (`938d642`) — Wall.referenceOffset (freier Achsversatz) übersteuert left/center/right; Object-Info-Dropdown listet je interne Fuge einen Eintrag (kumulierte Schichtdicken in selectionInfo). wallReferenceOffset bleibt EINE Quelle → 2D/Schnitt/3D erben es. +3 Tests.
 - [x] 2026-07-09 **Mess-Werkzeug: Polygonzug + Fläche + Objekt-Info** (`492e1f8`) — Länge je Segment + aufsummiert + FLÄCHE (ab 3 Ecken, Gauss); Live-Werte dauerhaft im Objekt-Info-Panel (ToolDraft.measure→PanelHost.measurement→ObjectInfoPanel); Rechtsklick beendet Pfad + armiert neuen (mehrere nacheinander). +4 Tests.
 - [x] 2026-07-09 **Tür/Fenster tief ausgearbeitet** (`fa40429`/`142ba7e`/`9a65900`) — DoorType/WindowType um frameKind (Zarge/Blockrahmen), frameWidth, insetFromFace/insetFace (Schichteinzug), transomHeight (Oberlicht), mullionRows (Kämpfer). ResourceManager-Typeditor + Seeds (Haustür Blockrahmen/Oberlicht, Fenster 2-flügl.+Oberlicht). 2D: opening-frame/-transom-Primitive. 3D: emitOpeningFrames (Rahmen/Sprossen/Kämpfer) + einzugs-/oberlicht-bewusste Scheiben. +13 Tests. **3D-Visualabnahme offen.**
 - [x] 2026-07-09 **LICENSE** (`dbe7d37`) — offizieller AGPL-3.0-Text (gnu.org).
 - [x] 2026-07-07 **IFC4-Export (erste Scheibe)** — reiner Kern `src/export/exportIfc.ts` (`exportIfcSpf(project)→string`, kein WASM/Dependency, direkt IFC-SPF-Text, Muster wie exportDxf). Räumliche Hierarchie IfcProject→IfcSite→IfcBuilding→IfcBuildingStorey (je `kind:"floor"`), Elemente via IfcRelContainedInSpatialStructure. Geometrie durchgängig IfcExtrudedAreaSolid: Wand→IfcWall, Decke→IfcSlab, Öffnung→IfcOpeningElement+IfcRelVoidsElement + Tür/Fenster-Füllung+IfcRelFillsElement, Extrusion→IfcBuildingElementProxy, Treppe→IfcStair (vereinfachter Hüllkörper, keine Stufengeometrie). IFC-22-Zeichen-GUIDs deterministisch aus Element-id (FNV→128bit→IFC-Base64, gegen IfcOpenShell-Referenz verifiziert). SI-Einheiten, OwnerHistory. Quick-Access-Button (`deployed_code`) + `onExportIfc` in App.tsx (Blob `model/ifc`, `<name>.ifc`) + i18n `file.exportIfc`. 8 Tests (wichtigster: KEINE dangling refs — jede `#N`-Referenz definiert + eindeutig). vitest 391. **Bewusst offen/vereinfacht:** IfcMaterialLayerSet (DirectionSense/Offset-Semantik ohne Viewer zu riskant — Folge-Item), Treppen-Stufengeometrie, Tür/Fenster nutzt dieselbe Box wie die Öffnung (kein Rahmen/Blatt). `host.ts` bewusst NICHT angefasst (Export-Callbacks leben in TopBarProps, nicht PanelHostValue — konsistent mit DXF/Schedule). **⚠️ Unit-Tests beweisen nur STRUKTURELLE STEP-Validität — Nutzer muss die .ifc in echtem Viewer (BIMcollab Zoom / IFC.js / Revit) gegenprüfen.** **Noch uncommittet.** (STL/OBJ-Export + IFC-Import + DWG-Schreiben bleiben offen — s. Interop-Befund.)
 - [x] 2026-07-07 **ObjectInfo: Volumen/Länge bei Wand + Volumen bei Decke** (Nutzer-Wunsch) — `selectionInfo.ts`: WallInfo um `length`/`grossVolume`/`openingVolume`/`netVolume` (Netto = Länge×Dicke×Höhe − Σ Öffnungen[Breite×Höhe×Dicke]), CeilingInfo um `volume` (Fläche×Dicke). Panel zeigt bei Wand Länge + Netto-Volumen (Tooltip Brutto−Öffnungen), bei Decke Fläche + Volumen. +i18n `objinfo.volume`/`objinfo.wall.length`/`objinfo.wall.volumeGross`. tsc/vitest 391. **Noch uncommittet.**
 - [x] 2026-07-07 **UI-Feinschliff-Runde (Nutzer-Session, Tauri live abgenommen):** (1) Kamera-Settings (FOV-Popover) ZUSÄTZLICH oben in der TopBar-Chrome neben CSV, dafür UNTEN aus beiden Ribbon-Tabs entfernt → unten saubere 2×4 View-Icons (Nutzer-Korrektur: erst waren fälschlich alle Presets mit oben). (2) ObjectInfo: Bezugspunkt-Würfel fix quadratisch (64px, skaliert nicht mehr mit Panelbreite), X/Y/Z als Spalte rechts daneben (`objinfo-refrow`/`objinfo-xyzcol`). (3) Wand/Decken-UK/OK-Unterzeile in normale Label/Wert-Struktur: „Referenzgeschoss" + Dropdown in der Wertspalte, bei Eigene „Eigene Höhe" linksbündig (+2 i18n-Keys `objinfo.anchor.*`). (4) Ansichten-Ribbon: Detailgrad + Darstellung übereinander gestapelt (eine `tb-stack`-Gruppe), alte separate Darstellungs-Gruppe entfernt. tsc sauber, vitest 377/377. **Noch uncommittet.**
 - [x] 2026-07-07 **Basis-Materialien mit Default-Textur** (Nutzer-Wunsch „nicht dass ich sie zuweisen muss und jeder Reset zerstört es") — Seed-Components in `src/model/sampleProject.ts` tragen ab Werk `material` (via `materialFromAsset`, exakt der ResourceManager-Zuweisungsweg): Aussen-/Innenputz→Plaster001, Backstein→Bricks104, Beton→Concrete048. Bewusst OHNE: Dämmung + Estrich (kein passendes Asset in der 12er-Bibliothek — nicht geraten). Alt-Projekte unberührt (Feld optional). three.js-Viewport rendert automatisch texturiert; nativer Renderer weiterhin ohne Texturen (bekannter 3D-REST). tsc sauber, vitest 377/377. **Noch uncommittet.**
 - [x] 2026-07-07 **Element-Übersicht / BIM-Tree-Panel** (ROADMAP §11, Phase-1) — neues `src/panels/ElementTreePanel.tsx`: dreistufiger Baum Geschoss→Bauteilklasse→Element aus `scheduleRows()` (Textfilter mit Auto-Aufklappen; Klick = selektieren, Shift/Doppelklick = selektieren+zoomen). `ScheduleRow.floorId` additiv (CSV unverändert), Host-Callback `onSelectScheduleRow` (App.tsx setzt korrekten Selektionskanal, wechselt bei Bedarf Geschoss + defert 1 rAF gegen den Geschosswechsel-Reset). Registriert in `builtinPanels.tsx` + Default-Rechts-Dock (`LAYOUT_VERSION` 8→9). Legacy `project.doors` bewusst ausgefiltert (tot; echte Türen sind `Opening kind=door`). +i18n `elements.*`. vitest 377/377, tsc sauber. **Bekannte Grobheit:** Zoom nutzt `fit()` (ganzer Plan) statt `fitSelection()`, weil letzteres nur lokal geklickte Indizes kennt und `PlanView.tsx` gesperrt war — Element wird per Auswahl-Outline sichtbar. **Nebenbei:** NUL-Byte in `exportSchedule.ts` (Kollision paralleler Schreibzugriffe) repariert. **Noch uncommittet.**
 - [x] 2026-07-07 **Decken-UK-Verdrahtung nachgezogen** (Orchestrator) — `onSetCeilingBottom`-Handler in App.tsx ergänzt (Muster `onSetCeilingTop`); das UI-Feld aus dem Decken-UK/OK-Item ist damit funktional statt inert. tsc sauber, vitest 377/377.
 - [x] 2026-07-07 **Kamera-Presets: Kardinal + Iso-Oktanten** (Milestone B3-Teil, OHNE Nord-Rotation — die bleibt Nutzer-Entscheid) — `View3d` jetzt front/back/side(=Rechts)/left/top/iso + 3 weitere obere Iso-Oktanten (vorne-links/hinten-rechts/hinten-links; untere 4 bewusst weggelassen) + perspective. Rust `CameraPreset`/`preset_camera`/`web.rs` synchron erweitert (+2 Tests, cargo render3d 60/60), three.js-Pfad (`Viewport3D.tsx`) in Parität, `VIEW3D_ORBIT`-Seeds analytisch. UI: 4 Kardinal-Buttons + Iso-Split-Button mit Oktanten-Popover (ViewRibbonTab + Ribbon3dTab). WASM-Rebuild sauber, tsc sauber, vitest 372/372. **Visuelle Abnahme im Tauri offen.** **Noch uncommittet.**
 - [x] 2026-07-07 **Decken UK/OK-Override** (ROADMAP §11, Phase-1-Item) — `Ceiling.bottom?: VerticalAnchor` (additiv), `ceilingVerticalExtent` löst bottom-Anchor vor `zTop−thickness` auf (exakt das Wand-Muster); wirkt automatisch in 3D (`toWalls3d`) UND Schnitt (`toSection`), da beide denselben Resolver konsumieren. ObjectInfo: UK-Zeile jetzt editierbare `VerticalAnchorRow` (i18n-Key existierte). Neue Tests `model/wall.test.ts` (5). vitest 377/377, tsc sauber. **⚠️ Folge-Zeile:** `onSetCeilingBottom`-Handler in App.tsx (~5 Zeilen, Muster onSetCeilingTop) war ausserhalb der Agent-Lane — wird vom Orchestrator nachverdrahtet, bis dahin ist das UI-Feld inert. **Noch uncommittet.**
 - [x] 2026-07-07 **A1 Override-Regel-Engine** (Top-Item des DOSSIER-Audits) — `OverrideRule` (condition: layer_name|object_name × equals|contains|starts_with|not_equals → actions: color/lineweight/linetypeId) additiv an `Project.overrideRules`; pure Engine `src/overrides/engine.ts` (`effectiveOverrides`: additiv, oberste aktive Regel gewinnt pro Feld, case-insensitiv, layer_name matcht Name ODER Code); Einhängung als Render-Dekoration in `generatePlan.ts` NACH der By-Layer/By-Object-Kette (Wände/Decken/Räume/Öffnungen/Treppen/Drawing2D; Projektdaten unverändert, jederzeit reversibel); ResourceManager-Tab „Overrides" (Master-Detail, Prioritätsliste ▲/▼, Aktiv-Checkbox). +18 Tests (engine 12, generatePlan-Integration 6). vitest 372/372, tsc sauber. **Bewusst offen:** user_string-Bedingung (kein Tag-Feld am Element), 3D-/Schnitt-Pfad, Presets/Templates (C2), Drag-Reorder; Overrides-Tab im ANGEDOCKTEN ResourcesPanel-Adapter vorerst nur lesend (Handler optional gehalten — Mini-Folge-Item). **Noch uncommittet.**
 - [x] 2026-07-07 **SIA-416: AGF-Kategorie ergänzt** (Lücken-Schluss aus dem Milestone-Abgleich) — `SiaCategory`+`AGF` in `geometry/roomArea.ts`, Rollup NUR in GF (nicht NF/NGF): Bilanz-Reihenfolge HNF·NNF·NF(Σ)·VF·FF·NGF(Σ)·KGF·AGF·GF(Σ), GF = NGF+KGF+AGF. Dropdown/Bilanz-Panel/CSV übernehmen generisch ohne Änderung. Neue Testdatei `roomArea.test.ts` (8 Tests). vitest 366/366 grün. **Noch uncommittet.**
 - [x] 2026-07-07 **D2 Bauteil-CSV volles Element-Set** — `exportSchedule.ts` deckt jetzt Tür/Fenster/Öffnung/Treppe/Extrusion zusätzlich zu Wand/Decke ab, exakt nach dem in HANDOVER.md hinterlegten Scope (Tür/Öffnung: Breite/Höhe/Fläche, Geschoss via Wirtswand; Treppe: Lauflänge + totalRise, Fläche bewusst leer; Extrusion: Höhe + polygonArea, Geschoss via levelId; Räume weiterhin im eigenen Raum-CSV). Aggregat-Zeile generalisiert (`totalLength`/`totalArea` > 0 ? Wert : leer — kein irreführendes 0.00 bei Treppe). Tests erweitert (Fixture + Zeilen-Asserts je neuem Element). `tsc` sauber, `vitest` 341/341 grün. **Noch uncommittet.**
 - [x] 2026-07-06 **`extrude`-Befehl im 3D-Ribbon-Tab** — `Ribbon3dTab` (`src/ui/TopBar.tsx`) kannte nur Kamera/Darstellungsart, nicht den seit Phase 3 existierenden `extrude`-Befehl; neue Gruppe mit Befehls-Button (gleiches Muster wie `RibbonButton`s Befehls-Zweig: `CommandIcon` + Label aus der Registry, deaktiviert ohne aktives Geschoss, aktiv-Highlight bei laufendem Befehl). `onRunCommand`/`activeCommand` neu durchgereicht (App.tsx). tsc sauber.
 - [x] 2026-07-06 **truck-Integration Phase 4 (Boolean) — Mesh-CSG via `csgrs` umgesetzt, technisch bewiesen** (Details s. oben bei „Phase 4"): zweiter Spike (`csgrs`, Mesh-Ebenen-BSP statt B-Rep) löst exakt den Fall, an dem `monstertruck-solid` scheiterte; nutzerautorisiert als echte (Git-gepinnte) Abhängigkeit in `trucksolid` eingebaut (`boolean.rs`, WASM-Export `boolean_mesh`, TS-Wrapper `booleanMesh()`). `cargo test` 11/11, `wasm32-unknown-unknown`-Build + echter `wasm-pack`-Build sauber. UI-Verdrahtung (wann automatisch subtrahieren) bewusst offen gelassen — Scope-Entscheidung, kein Technik-Risiko mehr.
 - [x] 2026-07-05 **Schnitt/Ansicht Phase 2: Decke über Schnittebene = gestrichelte Überkopf-Linie** (`39ddd9b`) — freier Decken-Umriss (Balkon-/Vordach-Überstände) jetzt gestrichelte Haarlinie (`OVERHEAD_DASH` in `generatePlan.ts`, `addCeilingPoche`) statt Volllinie; Decken-Fläche war schon Ansicht (viewHatchId). `lwMm`-Param entfernt (feste Haarlinie). +1 Test, Suite 337.
 - [x] 2026-07-05 **Schnitt/Ansicht Phase 1: Wand unter Schnittebene = Ansichtslinie** — `addWallPoche(viewOnly)` in `generatePlan.ts`: `wall.height < floor.cutHeight` (Brüstung/Podestrand) → Umriss-Haarlinie (`fill:"none"`, NO_HATCH) statt Schnitt-Poché; normale Wände unberührt (Segment-/Gehrungs-/Öffnungslogik geteilt). +2 Tests (`generatePlan.viewwall.test.ts`), Suite 336. Erster Baustein des BIM-Standard-Items „Schnitt vs. Ansicht nach Schnitthöhe".
 - [x] 2026-07-05 **Ribbon Phase 4: modulare Custom-Bar** (Tab „Eigene") — datengetrieben auf der bestehenden Registry: neuer `custom`-Tab, `CustomBar` in `RibbonBar.tsx` rendert die vom Nutzer gewählten Items + einen „＋ Hinzufügen"-Picker (Dropdown mit Häkchen, listet ALLE Werkzeuge/Befehle aus `ALL_RIBBON_ITEMS`, Klick = an/abwählen). `itemKey`/`itemFromKey` für stabile Persistenz; State in App (`customItems`) via localStorage (`dossier.ribbon.customItems`). Gleiche `RibbonButton`-Aktivierung wie normale Tabs (kein Sonderweg). tsc + Suite 334 grün.
 - [x] 2026-07-05 **Ribbon Phase 3 (Teil): Werkzeug-Sidebar raus** — `DEFAULT_LEFT_GROUPS` nur noch `attributes` (volle linke Höhe), `LAYOUT_VERSION` 7→8 (gespeicherte Layouts fallen auf neuen Default zurück → sichtbar). Wandtyp-/Deckentyp-Picker von `ToolsPanel` ins `AttributesPanel` verschoben (Nutzer-Entscheid „ins Attribute-Panel") — erscheint bei aktivem Wand-/Decken-Werkzeug (Sektion „Neues Bauteil", auch ohne Auswahl), Host-State unverändert. `ToolsPanel` bleibt registriert (per Fenster-Menü andockbar), `Dropdown`-Import dort entfernt. tsc + Suite 334 grün. **Offen:** Objektinfo unter Attribute mergen.
 - [x] 2026-07-05 **Fix: gezeichnete/importierte Kreise+Bögen im WebGL unsichtbar** — der WebGL-Compiler (`glPlan/glPlanCompile.ts`, Default-Renderer) dispatchte `polygon`/`line`/`arc`, aber NICHT `drawingCircle`/`drawingArc` → seit `4ac99d3` (Kreise als echtes `drawingCircle`-Primitiv statt 64-Eck-Polygon) fielen sie im GL still raus (SVG-/WASM-Pfad hatten sie, GL nicht). Zweig ergänzt: bildschirm-adaptive Tessellierung wie beim `arc`-Primitiv (Kreis geschlossen + optionale Vollton-Füllung, Bogen a0..a1 offen). tsc + Suite 334 grün. **Nutzer-Report** („zeichne Kreis, bleibt nicht sichtbar").
 - [x] 2026-07-05 **Textur-Spike verifiziert erledigt** (`0ca3b1d`) — bei der Backlog-Abarbeitung festgestellt, dass die render3d-Textur-Spike (`RenderStyle::Textured`, Schachbrett, planare Meter-UVs, `MESH_TEXTURED_WGSL` group 1, `spike3d`-`T`-Toggle) bereits vollständig umgesetzt + committet war; `cargo test` 58/59 grün, keine neuen Deps, Alt-Pfad bitgleich. „Als Nächstes"-Eintrag war veraltet → abgehakt; PBR-Restlückenliste (~18–29 PT) in 3D-REST übernommen.
 - [x] 2026-07-05 **Ribbon-Feinschliff (OCS-Zeile)** — Tabs in die TopBar-Zeile verlegt (`456ebc8`, eine Leiste Chrome+Tabs, Inhalt darunter; Tab-State in App); OCS-Chrome: kleine Wortmarke „dossier." + Quick-Access-Icons für ALLE Datei-/Export-Aktionen statt Burger-Menü, Zeile auf 26px (`4e3b074`); Text-/Font-Formatierung mit der Ansichts-/Zoom-Steuerung auf EINE Leiste gelegt, „Ansichten" als Standard-Tab zuerst + initial aktiv (`fe22cbf`). Alle tsc + 331 Tests grün. Visuelle Abnahme (26px, Icon-Sitz) noch offen.
 - [x] 2026-07-05 **Ribbon Phase 2: TopBar → „Ansichten"-Tab gemergt** (`85011cb`, Nutzer-Entscheid „voll mergen") — die Ansichts-/Zoom-/Darstellungs-Cluster der TopBar (View-Grid+Kamera, Ebenen-/Zeichnungs-Kombis, Detailgrad, Massstab/Zoom, Darstellungsart) als `ViewRibbonTab` (in `TopBar.tsx`) in den Ansichten-Tab verschoben; App reicht sie als `viewsContent`-Node an `RibbonBar` (analog Layout-Menü). TopBar ist jetzt schmale globale Leiste (Marke/Ressourcen · Text · Datei/Export/Einstellungen · Fensterknöpfe). `TopBarProps` entsprechend verschlankt. Visuelle Feinabstimmung offen.
 - [x] 2026-07-05 **Ribbon-UI Phase 1** (`9d6e86d`) — datengetriebene Tab-Leiste (`src/ui/ribbon/`: `ribbonItems.ts` Registry, `RibbonBar.tsx`, `CommandIcon.tsx`) unter der TopBar, additiv (Sidebar bleibt). Tabs 2D·3D·BIM·Ansichten; 2D=Zeichnen(select/line/polyline/rect/circle/arc)+Ändern(move/copy/mirror/offset/trim/join), BIM=Bauteile(wall/window/door/stair/ceiling/room); 3D/Ansichten noch leer. Ein Aktivierungs-Pfad: tool→`onSelectTool`, command→`onRunCommand`(engine.start); Aktiv-Highlight über `activeTool`/`engineView.commandName`. `ToolIcon` aus ToolsPanel exportiert (wiederverwendet).
 - [x] 2026-07-05 **Attribut-Panel: ein Grid, volle Breite** (`ace0dc6`) — drei getrennte Grids zu EINEM durchgehenden Zwei-Spalten-Grid gemerged (Wertspalte über alle Sektionen bündig), Dropdown-Pills füllen die Wertspalte (fixe Breiten raus), doppeltes Eigen-Padding + zweiter „Attribute"-Titel entfernt. **Nutzer-Report.**
 - [x] 2026-07-05 **Eigenschaften-Grid OCS-Stil** (`00733d8`) — `.attr-*` als klares Grid: Sektion-Balken, Zeilentrenner, füllende linksbündige Wertfelder (Texte/Zahlen/Dropdowns einheitlich). Erste Stufe der Ribbon-UI-Vision.
 - [x] 2026-07-05 **Zoom-Scroll-Fix** (`077e774`) — Dokument-Overscroll/Rubberband gesperrt (`html,body,#root { overflow:hidden; overscroll-behavior:none }`); Viewport-Zoom zieht die UI nicht mehr mit (macOS). **Nutzer-Report.**
 - [x] 2026-07-05 **Kreis- + Bogen-Werkzeug** (`e454eab`, `bd2b12b`) — Kreis-Toolbar (circleCommand gekoppelt) + neues `arcCommand` (3-Klick CCW), beide mit Toolbar-Icon/i18n; rendern glatt via `drawingCircle`/`drawingArc`.
 - [x] 2026-07-05 **DXF-Import: Platzierungsoption** (`dd76ec8`) — ImportDialog fragt „relativ zum Nullpunkt" ODER „in die Mitte der aktuellen Ansicht"; `PlanViewHandle.viewCenterModel()` neu; `runImport` verschiebt den Gesamt-Umriss (bbox-Mitte → Ansichtsmitte). tsc + Suite 331 grün.
 - [x] 2026-07-05 **Zeichnungen Copy/Paste über Geschosse** (`376aa67`) — Ctrl/Cmd+C kopiert gewählte Drawing2D tief; Ctrl/Cmd+V fügt Klone (neue IDs) auf dem AKTIVEN Geschoss ein und wählt sie. Für z. B. importiertes Mobiliar. Textfeld-Fokus bleibt natives Copy/Paste.
 - [x] 2026-07-05 **Tauri Drag&Drop + Import-Dialog-Fix** (`c5b5ca6`, `45e19b7`) — `import`-Befehl als `autoRun` (Datei-Dialog öffnet synchron in der Geste, HMR-Falle via Config-Relaunch behoben); `dragDropEnabled:false` (Tauris natives Drag-Drop fing HTML-Drops ab). **Nutzer-bestätigt: Dialog + Text gehen.**
 - [x] 2026-07-05 **Layout: Befehlszeile in Mitte-Spalte** (`c794fee`) — nur Viewport-breit, Docks gewinnen Höhe. **Nutzer-bestätigt „sieht clean aus".**
 - [x] 2026-07-05 **Textur-Spike render3d** (`RenderStyle::Textured` real) — zweiter Vertex-Pfad `[pos,normal,uv]` aus dem Mesh abgeleitet (Alt-Pfad bitgleich, per Test belegt), prozedurales 256×256-Schachbrett (kein Asset/`image`-Crate), Textur-Bind-Group group 1, `MESH_TEXTURED_WGSL` (gleiche Beleuchtung, Albedo aus Sampler), Pipeline bitidentisch zur Haupt-Pipeline, `spike3d` per `T` umschaltbar. Verifiziert: cargo test 58/59 (inkl. naga-Test) grün, alle 4 Builds sauber. **Visuelle Fenster-Abnahme durch Nutzer bestanden 2026-07-05** (Schachbrett korrekt, `T`-Umschaltung ok). Erster Durchstich der Textur-/PBR-Pipeline; ehrliche Lückenliste im Bericht — `8556037`
 - [x] 2026-07-04 **Grundriss: Decke drückt nicht mehr durch die Wände** — Decken-Umriss an Wand-Footprints (OBB) geclippt; Füllfläche strokelos, Umriss nur über unverdeckte Teilstücke (Überstände). Deckungsgleiche Decke ⇒ Umriss entfällt. vitest 230, tsc sauber — `a2f6923`
 - [x] 2026-07-04 **T-Stoss-Putznaht entfernt** — L-Seitenlinie nur noch bei materialFREMDEM Nah-Putz; materialgleicher Putz verschmilzt nahtlos (Nutzer-Direktive „Naht entfernen"). TS+Rust synchron, 3 Tests gezogen, cargo 8/8 — `a5ebfa7`
 - [x] 2026-07-04 **Snap-Farbe entschieden: Sora #5FA1C9** als endgültiger Default festgeschrieben (`DEFAULT_SNAP_COLOR`, Doc), „aki"-❓ geschlossen.
 - [x] 2026-07-04 **Mac-Build via Tauri + Queue-Abgleich** — Toolchain auf macOS-Gerät verifiziert, `cad.app`/`cad_0.1.0_aarch64.dmg` gebaut & gestartet. Verifikations-Baseline grün (tsc/vitest 230/cargo 56). Queue-Reconciliation: Toolchain-Blocker, Snap-Slice (`339202b`), Ebene-Schraffur (`dcb6ed5`), Bauteile-Tab-Master-Detail, Einstellungs-Verdrahtung UND Wand-Schicht-Bänder 3D (Option B, `toWalls3d.ts`) waren allesamt **bereits gelandet**, aber in PENDENZEN noch als offen gelistet → abgehakt. (kein Code-Commit)
 - [x] 2026-07-04 **Öffnungen als echte Boolean-Löcher** (+ Deckentrim-nur-3D) — Fenster/Türen = 1 Wandkörper mit rechteckigen `holes` (Rechteck-Gitter-Zerlegung + Laibungsquads), Segment-Boxen weg; Deckentrim nur noch im 3D-Pfad, Schnitt volle Höhe. Pflicht-Testfall versetzt-überlappende Fenster grün. cargo test 56, vitest 230, build:engine3d + tsc sauber — `1407c68`
 - [x] 2026-07-04 **Joins Phase 1c** Durchgangswand am T-Stoss echt aufbrechen (spanCutouts) — `c5a344d`
 - [x] 2026-07-04 **Locked-Iso-Fix** freie Kamera bleibt nach Ortho-Preset orthografisch — `cb8fae5`
 - [x] 2026-07-04 **3D-Live-Schnittebene** mit schraffierten Schnittflächen — `03f0c40`
 - [x] 2026-07-04 **Joins Phase 2** Merge-Regel im Schnitt (gleiche Komponente verschmilzt) — `82d354f`
@@ -0,0 +1,124 @@
 # PORT_PLAN — kernel2d nach Rust/WASM (hinter identischem TS-Interface)
 Stand: 2026-07-04. **Dieser Plan ist der geforderte erste Schritt — noch kein Code.**
 Ziel: `src/geometry/kernel2d.ts` (+ reine Geometrie aus room/ceiling/opening/stair) in
 ein Rust-Crate portieren, zu WASM bauen, hinter einer TS-Fassade mit *exakt gleichen*
 Signaturen einhängen. TS-Kernel bleibt als Referenz (`kernel2d.legacy.ts`).
 Differential-Test: Rust-WASM == TS-Legacy auf identischen Eingaben (epsilon je Funktion).
 ---
 ## 1. Scope-Inventar (was wirklich portiert wird)
 **Externe JS-Geometrie-Libs: KEINE.** Der Kernel ist handgeschriebene f64-Mathematik,
 einzige Abhängigkeit sind die Vektor-Helfer aus `src/model/geometry.ts`
 (`add/sub/scale/len/normalize/leftNormal/cross/dot/lineIntersect`) — trivial mit zu
 portieren. `polygon-clipping`/`delaunator` werden im Kernel **nicht** genutzt.
 ### Voll im Scope (reine Geometrie)
 - **`kernel2d.ts`** — komplett: Primitive, Schnitt, Offset, Trim/Split/Join, Kreis, Fläche/Orientierung, Fillet.
 - **`roomBoundary.ts`** — komplett: `detectRooms`, `roomFromPointInside(Faces)`, `pointInPolygon`, `WallSegment`/`WallFace`/`DetectRoomsOptions` (generische Geometrie-Typen, `thickness: number`).
 - **`ceiling.ts`** — komplett: `normalizeOutline`, `isValidOutline`, `ceilingArea`, `outlineBBox`, `outlineCentroid`, `pointInOutline` (generische Polygon-Utilities; Name irreführend, keine Decken-Semantik).
 ### Teilweise im Scope
 - **`roomArea.ts`** — NUR `signedArea`, `polygonArea`, `perimeter`, `centroid`. Alles ab `SiaCategory` (`siaLabel`, `evaluateRoom`, `balance`, `roomsToCsv`) ist SIA-416-Domänenlogik/CSV → **bleibt TS**.
 - **`stair.ts`** — portierbar, aber `stairGeometry` nimmt `Stair`. „Scheinkopplung": es werden nur geometrische Felder gelesen (`shape/start/dir/runLength/width/stepCount/…`), `totalRise` kommt bereits aufgelöst vom Aufrufer. Port via Rust-Struct `StairParams` (strukturgleich, null Model-Semantik).
 ### ⚠️ Scope-Spannung: `opening.ts` (im Auftrag genannt, aber stark model-gekoppelt)
 7 von 9 Exporten binden `Wall`/`Opening` direkt ein; `getWallType`/`wallTypeThickness`/`wallReferenceOffset`/`wallVerticalExtent` lösen gegen `Project` auf.
 - **Portierbar mit abgeflachter Signatur** (Vec2/number statt Wall/Opening): `wallAxisLength`, `openingInterval`, `wallAxisFrame`, `openingJambs`, `openingCenter`, `doorSymbol`, `openingGapQuad`/`windowSymbol` (letztere brauchen `thickness`/`refOff` als `number`-Parameter).
 - **Bleibt TS** (braucht `Project`/Geschoss-Auflösung): `openingVerticalExtent` (via `wallVerticalExtent` → `Project.drawingLevels`).
 - **→ Entscheidung nötig** (siehe §7): Der Auftrag verbietet Änderungen an Aufrufstellen außer dem Import-Pfad. Ein Port von `opening` würde die *Signaturen* ändern (Wall→Vec2/number) und damit die Aufrufstellen brechen — das widerspricht „keine Änderung an Aufrufstellen". Empfehlung: **opening in Phase 1 ausklammern**, nur den echt reinen Kern (kernel2d/roomBoundary/ceiling/roomArea-Flächen/stair) portieren.
 ---
 ## 2. Crate-vs-Portieren — pro Operation
 Akzeptanzkriterium ist **Differential-Parität gegen die naive TS-Routine**, nicht „geometrisch besser". Jedes Fremd-Crate mit anderem Algorithmus bricht die Parität per Konstruktion → Default = **PORTIEREN** (TS-Routinen sind 5–40 Zeilen f64, 1:1 übersetzbar).
 | Operation | geprüftes Crate | Entscheidung | Grund |
 |---|---|---|---|
 | `offsetPolyline`/`offsetSegment` | cavalier_contours 0.6 | **PORTIEREN** | Crate liefert **Arcs (bulge)** statt `Vec2[]`, **heilt Selbstschnitte**, gibt mehrere Polylinien — TS heilt bewusst NICHT. Semantik nicht angleichbar. |
 | Segment/Line-Schnitt | geo / robust | **PORTIEREN** | Cramer-Formel; jede andere denom-/Epsilon-Politik driftet in Parallel-Grenzfällen. |
 | Trim/Split/`segmentPolylineHits` | geo `Relate` | **PORTIEREN** | Projektspezifisch (t-Dedup `1e-6`, Pick-nächster-Bogen, Wrap-Logik). |
 | Kreis-Schnitte | — | **PORTIEREN** | Quadratik mit projekt-EPS-Disc-Klemmung. |
 | `signedArea`/`isCCW` | geo `Area` | **PORTIEREN** | Shoelace-Summierung in **identischer Vertex-Reihenfolge** (f64 nicht assoziativ). |
 | `filletCorner` | — | **PORTIEREN** | `acos/atan2/tan(θ/2)`-Kette + projekt-Cutoffs; liefert projekt-spezifische `Fillet`-Struktur. |
 | `detectRooms` / `joinChains` | geo / i_overlay | **PORTIEREN** | Topologie-/reihenfolgeabhängig; andere Kantendurchlauf-Reihenfolge → andere (gleich gültige) Ringe → Parität bricht. |
 | point-in-polygon | robust | **PORTIEREN** (robust nur intern, optional) | Siehe §3. |
 Fremd-Crates (cavalier_contours/geo/i_overlay) wären für einen späteren *Tier-2-Rewrite* (echter Arc-Offset, Boolean-Ops) wertvoll — das ist ein **anderes Produkt**, nicht dieser paritätserhaltende Port.
 ---
 ## 3. `robust`-Prädikate vs. Differential-Parität (Spannung auflösen)
 TS testet Orientierung überall via naives `cross()` gegen `EPS`. `robust::orient2d` liefert das **exakte** Vorzeichen — weicht von naiv **nur in der nahe-degenerierten Zone** ab (fast-parallele Segmente, Null-Fläche-Polygone, Punkt-auf-Kante). Genau dort schlägt der Diff-Test am ehesten an. Man kann nicht gleichzeitig „bit-Parität gegen naiv" und „robuste Prädikate" im *selben* Vergleich haben.
 **Entscheidung:**
 1. **v1 portiert die naiven `cross`-Vergleiche 1:1** (KEIN `robust`) → Zufalls-Diff-Test wird bit-nah grün. Robustheit kommt aus denselben f64-Formeln + demselben `EPS` wie TS.
 2. **Additiv, getrennt:** `robust` nur *intern* in `detectRooms`/point-in-polygon hinter optionalem Feature `robust-predicates`, flankiert von **Golden-Cases, die die KORREKTE (robuste) Antwort asserten** (nicht TS-Parität). Diese Fälle sind aus dem Zufalls-Diff-Test ausgenommen.
 3. Zwei Testklassen, nie gemischt: **Zufalls-Parität = naiv**, **Golden-Korrektheit = robust**.
 ---
 ## 4. Crate-Setup & Vite (exakter Klon von `src-tauri/geometry`)
 Ort: **`src-tauri/kernel2d`** (analog render2d/render3d/geometry; das gesamte Tooling ist auf `src-tauri/<crate>` + `../../src/engine/pkg<X>` verdrahtet). *Namens-Hinweis:* Auftrag sagt `crates/kernel2d` — siehe §7.
 - `Cargo.toml`: `crate-type = ["cdylib","rlib"]`; Features `default=[]`, `web=[wasm-bindgen, serde_json, console_error_panic_hook]`, `robust-predicates=[robust]` (additiv, nicht in web-Default).
 - `src-tauri/Cargo.toml`: `exclude = [..., "kernel2d"]` erweitern (sonst „multiple workspace roots").
 - `src/lib.rs`: reiner f64-Rechenkern feature-frei (`cargo test`-bar, headless) + `#[cfg(feature="web")]` JSON-**Batch**-Fassade pro Operation (`offset_polylines_json`, `intersect_batch_json`, `fillet_batch_json`, `circle_intersect_batch_json`, `detect_rooms_json`), Muster `compute_joins_json`.
 - `examples/parity.rs`: Klon von `geometry/examples/parity.rs` (Batch-JSON stdin→stdout) — nativer Diff-Kanal.
 - `package.json`: `"build:kernel2d": "wasm-pack build src-tauri/kernel2d --release --target web --out-dir ../../src/engine/pkgKernel2d --out-name kernel2d --no-default-features --features web"`.
 - **Vite: kein Config-Eintrag nötig** — `--target web`-Pakete werden als normales ES-Modul importiert, Vite bündelt `kernel2d_bg.wasm` automatisch (`new URL(..., import.meta.url)`). `pkgKernel2d/` ist git-ignoriert (self-`.gitignore = *`) → vor `vitest`/`build` muss `build:kernel2d` laufen (CI-Schritt).
 - **TS-Fassade** `src/geometry/kernel2d.ts` wird dünner Wrapper (init-WASM, JSON-Marshalling, gleiche Exports); Alt-Impl → `src/geometry/kernel2d.legacy.ts` (nicht löschen, ist die Diff-Referenz).
 ---
 ## 5. Differential-Test-Harness
 - **Grobkörnige WASM-Grenze:** eine Batch-Funktion je Operation (N Polylinien rein, N Ergebnisse raus). Keine Per-Punkt-Calls (jeder Call marshallt einen String = O(n)-Kopie).
 - **Diff-Kanal:** Der Auftrag verlangt **Rust-WASM** vs. TS-Legacy → primär WASM (via `initSync`). Zusätzlich `cargo run --example parity` (nativ) als schneller Sekundär-Kanal (bit-identisch zu WASM für `+ - * / sqrt`; **Ausnahme** `atan2/acos/tan` in Fillet: libm nativ ≠ wasm um letzte ULP → Winkel-Epsilon).
 - **vitest-Init synchron:** `initSync({ module: readFileSync(pkgKernel2d/kernel2d_bg.wasm) })` (kein `fetch`), einmal in `beforeAll`.
 - **Zufallsgeneratoren:** seed-basiert (Seed im Testnamen), Polylinien 3–20 Vertices, Koordinaten `[-100,100] m`, `closed`/`d` zufällig; zusätzlich Cluster nahe `0` und `1e-6..1e-3`, um Toleranzschwellen zu treffen.
 - **Vergleichsreihenfolge:** zuerst **Struktur exakt** (Array-Längen, closed-Flags, Punktzahl, null/nicht-null), dann Werte mit op-Epsilon. Struktur ist der schärfste Paritäts-Wächter.
 ### Epsilon pro Funktion
 | Größe | Toleranz | Grund |
 |---|---|---|
 | Punktkoordinaten (Offset/Trim/Split/Kreis) | `abs 1e-9` | Bestehender Paritätstest nutzt `1e-9` und besteht bit-nah. |
 | Fläche (`signedArea`) | `rel 1e-9·max(1,\|A\|)` | Shoelace ∝ coord² → absolute ULP wächst mit Flächengröße; relativ skaliert korrekt. |
 | Winkel (`filletCorner`) | `abs 1e-7 rad` | `atan2/acos` libm-abhängig (nativ↔wasm ULP-Drift); 1e-7 rad ≈ 5.7e-6°, weit unter Zeichenrelevanz. |
 | Parameter t/s | `abs 1e-9` | TS dedupliziert erst ab `1e-6` → kleinere Diffs ändern nie die Struktur. |
 | Struktur | **exakt** | Kein Epsilon. Hier bricht ein Fremd-Crate. |
 ### Golden-Cases (explizit, aus Zufallstest teils ausgenommen)
 kollineare Tripel · Null-Länge-Segmente (Dublett-Vertex) · Offset-Selbstschnitt (enges U, großes d — hier bräche cavalier_contours) · spitze Fillet-Winkel (θ→0) · fast-paralleler Schnitt (denom knapp <>EPS → **Korrektheits-Golden/robust**) · konzentrische/tangentiale Kreise · Punkt exakt auf Polygonkante (**Korrektheits-Golden**).
 ---
 ## 6. Kritische Paritäts-Details (MÜSSEN exakt repliziert werden)
 - `len` = `Math.hypot` → **`f64::hypot`** (nicht `(x²+y²).sqrt()`).
 - `normalize` Null-Guard: `len || 1` → `if l==0.0 {1.0} else {l}` (Ergebnis `{0,0}`, kein NaN).
 - **Zwei Epsilons:** `EPS=1e-7` (kernel2d) UND hartkodiert **`1e-9`** in `lineIntersect` (Offset-Miter-Fallback hängt daran — geometrischer Sprung, nicht epsilon).
 - Dedup-Schwelle `1e-6`, Fillet-Kollinearität `1e-4` (nicht EPS).
 - **Stabile Sortierung** (JS `Array.sort` ist stabil): Rust `sort_by`, nicht `sort_unstable_by`.
 - Term-Reihenfolge in `cross`, `signedArea`-Summierung, Kreis-Diskriminante `B*B−4*A*C` exakt beibehalten (f64 nicht assoziativ; kein Kahan/Reorder).
 - Modulo-Indizierung `(i+len-1)%len` (usize-Unterlauf vermeiden).
 - `joinChains`: greedy `i<j`-erster-Treffer-dann-Neustart exakt nachbilden (reihenfolgeabhängiges Ergebnis).
 ---
 ## 7. Offene Entscheidungen (vor Coding klären)
 1. **`opening` im Scope?** Portieren würde Signaturen (Wall→Vec2/number) und damit Aufrufstellen ändern — widerspricht „keine Änderung an Aufrufstellen außer Import-Pfad". **Empfehlung: opening in Phase 1 ausklammern.**
 2. **Crate-Ort:** Auftrag `crates/kernel2d` vs. Repo-Konvention `src-tauri/kernel2d` (analog render2d/render3d). **Empfehlung: `src-tauri/kernel2d`** (Tooling passt out-of-the-box).
 3. **Diff-Kanal:** Auftrag verlangt Rust-**WASM**; nativer `parity`-Kanal ist schneller (kein wasm-pack in CI) und bit-identisch außer Fillet-Transzendente. **Empfehlung: WASM primär (Auftragskonform) + nativ sekundär.**
 ## 8. Phasen (Reihenfolge)
 1. Crate-Skelett `src-tauri/kernel2d` + Build-Script + Workspace-exclude + leere WASM-Fassade → `build:kernel2d` grün.
 2. Primitive + Schnitt + Fläche + Kreis portieren (trivial–mittel) + Batch-Fassade + Diff-Test-Harness (Zufall+Golden) → grün.
 3. Offset (Miter+1e-9-Fallback) + Fillet portieren → Golden für Selbstschnitt/spitze Winkel grün.
 4. Trim/Split/Join (`trimPolyline`, `splitAtIntersections`, `joinChains` — der Löwenanteil) → Struktur-Golden grün.
 5. `roomBoundary` (`detectRooms`) + `ceiling` + `roomArea`-Flächen + `stair` (StairParams).
 6. TS-Fassade umstellen (Alt → `.legacy.ts`), Import-Pfade der Aufrufstellen unverändert lassen, bestehende Suite grün, `npm run build` + WASM-Build sauber.
@@ -1,16 +1,17 @@
-# DOSSIER Standalone
+# Dossier
-Eigenständiges BIM-Werkzeug für Wohnbau. Modelliert ein Wohnhaus aus
+Open-Source-CAAD (Computer Aided Architecture Design). Modelliert ein Gebäude
-semantischen Bauteilen und zieht daraus saubere, normgerechte 2D-Pläne —
+aus semantischen Bauteilen und zieht daraus saubere, normgerechte 2D-Pläne —
-ohne Revit.
+ohne Revit. **Desktop-App** — auf macOS über **Tauri**, auf Linux über eine
 **Electron**-Shell (weil Tauris Linux-Webview WebKitGTK kein zuverlässiges
 WebGPU bietet, das die Rendering-Engines brauchen); dieselbe Codebasis läuft
 auch im Browser (eingeschränkt, ohne native Fenster/Dateisystem-Integration).
-Das ist die eigenständige Standalone-Variante des Rhino-Plugins
+Das ist die eigenständige Neuimplementierung des Rhino-Plugins
-[DOSSIER](https://git.kgva.ch/karim/DOSSIER): dieselbe Denkweise (Geschosse,
+[DOSSIER](https://git.openbureau.ch/karim/dossier): dieselbe Denkweise
-Kategorie-Ebenen, mehrschichtige Bauteile, Prioritäts-Verschneidung), aber als
+(Geschosse, Kategorie-Ebenen, mehrschichtige Bauteile, Prioritäts-
-React/Three.js-App in einer Electron-Desktop-Shell statt als Rhino-Aufsatz.
+Verschneidung), aber mit eigenem Datenmodell + eigener Rendering-Engine
-Kein Browser-Tab-Produkt: eigenes Fenster, eigene Rendering-Engine
+(Rust/WASM/WebGPU, intern „Nordstern" genannt) statt Rhino-Aufsatz.
 (Rust/WASM/WebGPU), gebaut für flüssiges CAD-Arbeiten statt für den Webview
 kleinster gemeinsamer Nenner.
 ## Grundgedanke
@@ -22,117 +23,124 @@ in die Geometrie eingebacken. Wer eine Wand verschiebt, verschiebt sie überall.
 Konkret heißt das auch: Der Grundriss entsteht nicht aus einem zerschnittenen
 3D-Mesh, sondern **analytisch aus den Bauteil-Parametern** (Wandachsen + Dicken →
 Linien, Öffnungen → Lücken + Symbol). PDF-Export ist derselbe Plan, nur mit
-echten mm-Stiftstärken statt Bildschirm-Hairlines — kein zweites Rendering.
+echten mm-Stiftstärken statt Bildschirm-Hairlines. Schnitte und Ansichten laufen
-Schnitte und Ansichten brauchen den zweiten Weg — echte 3D-Projektion mit
+über eine eigene, analytische Rust-Pipeline (kein Hidden-Line-Removal nötig,
-verdeckten Kanten (HLR) —, dessen Machbarkeit per Spike bewiesen, aber noch
+siehe [ARCHITECTURE.md](ARCHITECTURE.md) §4.3) und sind seit Juli live im
-nicht ans UI angebunden ist.
+3D-Viewport verdrahtet, nicht nur ein Spike.
 ## Stand heute
-Ehrlich eingeordnet: aus dem Risiko-Spike ist ein **benutzbares 2D-CAD mit
+Aus dem ursprünglichen Risiko-Spike ist binnen weniger Wochen ein
-abgeleiteter 3D-Sicht, Vektor-PDF/DXF-Export und einer parametrischen
+**funktionsreiches Desktop-BIM-Tool** geworden: eigenes semantisches
-Wand-Engine** geworden. Der einfachere Teil steht und ist per Screenshot/Probe
+Gebäudemodell, zwei eigene Rust/WASM-Rendering-Engines, IFC/DXF/PDF/STL/OBJ-
-verifiziert; die schwierigen BIM-Kernrisiken sind bewusst noch offen.
+Export, Swisstopo-Import, SIA-416-Flächen, Materialbibliothek, Layouts/
 Plansätze, native Tauri-Fenster. Eine vollständige, ehrliche Bestandsaufnahme
 (inklusive offener Punkte und bekannter technischer Schulden) steht in
 **[STATUS.md](STATUS.md)**.
-**Funktioniert:**
+**Funktioniert (Auszug — volle Liste in STATUS.md §3):**
- Semantisches Modell mit **mehrschichtigen Wänden** und automatischer
+- Semantisches Modell mit **mehrschichtigen Wänden**, L-Eck-Gehrung **und**
-  **L-Ecken-Gehrung** (`computeJoins`); dieselbe Logik speist Plan *und* 3D.
+  Prioritäts-T-/X-Stössen (`joinPriority` am Component) — konsistent in
- **Parametrische Wände** (`ParametricWall`-Regelwerke: Grid/Modul/Sequenz/
+  Grundriss, 3D-Viewport und 3D-Live-Schnitt.
-  Referenzlinie/bedingte Dicke) lösen sich zu konkreten `Wall`-Objekten auf,
+- **Parametrische Wände**, Decken, Treppen (gerade/L/Wendel), Dächer
-  statt jede Wand einzeln von Hand zu ziehen.
+  (Flach/Pult/Sattel/Walm/Mansarde/Zelt), Stützen, SIA-416-Räume mit
- **Dokumentmodell wie in DOSSIER:** Zeichnungsebenen (Geschosse + Schnitte/
+  automatischer Bilanz + CSV-Export.
-  Ansichten/Zeichnungen) × Kategorie-Ebenen (Code-Baum 1:1, `20 Wände`, `30 Decken` …).
+- **Türen & Fenster** gehostet in Wänden, mit Rahmen/Zarge/Kämpfer/Oberlicht,
- **Zeichnen & Editieren** im Grundriss: Wand, Linie, Polylinie, Rechteck, Kreis,
+  Detailgrad grob/mittel/fein, echte Rechteck-Löcher im 3D-Wandkörper.
-  Öffnungen, Treppen, Decken, Raumstempel; Snapping (Endpunkt/Mittelpunkt/
+- Rhino-artiges **Kommandosystem** mit getippten Koordinaten (`5,3` · `r5,3` ·
-  Schnittpunkt/Lot/Raster/Ortho), Grips, Move/Copy/Offset, Spiegeln/Drehen/Array,
+  `5<45`) und Tab-Feld-Zyklus; Snapping, Grips, Trim/Split/Join, 2D-Booleans.
-  Trim/Split/Join.
+- **Live 2D↔3D-Schnitt**: eine Schnittebene im 3D-Viewport folgt derselben
- **Rhino-artiges Befehlssystem** mit getippten Koordinaten (`5,3` · `r5,3` ·
+  Prioritäts-Logik wie der 2D-Plan-Schnitt (Rust-Port, keine Diskrepanz).
-  `5<45`) und Tab-Feld-Zyklus (Länge → Winkel …).
+- **Vektor-Export:** PDF (Einzel- **und Mehrseiten-Layouts**), DXF, **IFC4**
- **Vektor-Export:** PDF (A4/A3, Titelblock, echte mm-Stiftstärken nach ISO-Pen-
+  (mit echten Fenster-/Tür-Löchern), STL/OBJ, CSV-Bauteilliste.
-  Steps, keine Rasterbilder) und DXF — beide aus derselben `Plan`-Struktur wie
+- **Materialbibliothek**: 13 gebündelte PBR-Starter **plus** Live-Suche der
-  der Bildschirm.
+  kompletten ambientCG-Bibliothek (1K/2K/4K, On-Demand-Download).
- **PBR-Material-Bibliothek** (ambientCG-Import, `manifest.json`) für die
+- **Layouts/Plansätze** mit mehreren Viewports pro Blatt, Ausschnitte
-  3D-Ansicht.
+  (View-Snapshots), Kamera-Presets, Norden-Rotation.
- **Resource Manager** (Component / Hatch / Line) — alles per id referenziert,
+- **Import:** DXF/DWG, Swisstopo (swissBUILDINGS3D/-ALTI3D/SWISSIMAGE,
-  zentral änderbar.
+  radiusgenau zugeschnitten), OSM-Kontextimport, `.lin`/`.pat`.
- **Panel-System** (dockbar, stapelbar, floatend), Top-Bar + Statusleiste
+- **Native Desktop-Integration** (Tauri): eigene randlose Fenster, native
-  (echter Maßstab 1:N, Cursor X/Y), eigenes Kontextmenü, **i18n** (de/en).
+  Speichern/Öffnen-Dialoge, eigenes `.obp`-Dateiformat mit OS-Level-Lock gegen
- **Import:** DXF/DWG (Konturen/Mesh) → Terrain-TIN, Swisstopo/LV95-Geokontext,
+  Doppelöffnen, mehrere native Zusatzfenster (Resources, Settings, …).
-  OSM-Kontextimport; `.lin`/`.pat` für Linien/Schraffuren.
+- **Resource Manager** (Component/Hatch/Line/Typ-Editoren), regelbasierte
  Overrides, Panel-System (dockbar/floatend), i18n (de/en).
-**Bewusst noch offen** (die eigentlich harten Teile):
+**Bewusst noch offen** (Details + volle Liste: STATUS.md §4.7):
- Echte **3D-Booleans** für Öffnungen — Türen/Fenster sind im Plan eine Lücke,
+- **Echtes Mesh-Boolean für Öffnungen** — funktioniert heute über achsparallele
-  noch kein geschnittenes Volumen.
+  Rechteck-Löcher; ein generisches CSG-Boolean existiert bereits
- **HLR** (verdeckte Kanten) für Schnitte und Ansichten: Machbarkeit per
+  (`trucksolid`/`csgrs`), ist aber nicht an die Wand-Pipeline angeschlossen.
-  OCCT-WASM-Spike bewiesen (`docs/welle-c-hlr-spike/`, `src/section/hlr.ts`),
+- **3D-Griffsystem**: Feld-Controller (Tab-Zyklus) und Snapping fehlen für
-  aber noch nicht ans UI/Dokumentmodell verdrahtet — Views sind noch Stubs.
+  3D-Grip-Drag (im 2D vollständig vorhanden).
- **Prioritäts-T-/X-Stöße** mehrschichtiger Wände (Beton läuft durch, Putz
+- **DWG/DXF-Domänenimport** (Entitäten → echte Wände/Öffnungen) — Lesen
-  verbindet seitlich) — das berüchtigte Risiko #1.
+  funktioniert, das Mapping auf das Modell ist unbegonnen; DWG-Schreiben fehlt.
- **Multi-Page-Layouts/Ausschnitte** (mehrere Viewports pro Blatt) — PDF-Export
+- **`make2D`**-Kommando (3D-Ansicht → flacher 2D-Plan mit Füllungen).
-  ist noch single-sheet.
+- Bekannte, noch nicht bereinigte Doppelspur `Door[]`/`Opening[]` im Modell.
 Details und die Begründungen stehen im
 [HANDOVER](HANDOVER.md) (laufendes Arbeitsprotokoll) und in der
 [ROADMAP](ROADMAP.md) (Vision, Phasen, Backlog).
 ## Stack
 Bewusst leichtgewichtig — Three.js ist reiner Display-Layer, kein schwerer
 Geometrie-Kernel verfrüht eingezogen.
 | | |
 |---|---|
-| Shell | Electron (eigenes randloses App-Fenster, kein Browser-Tab) |
+| Shell | **Tauri** auf macOS (WKWebView+WebGPU) · **Electron/Chromium** auf Linux (WebKitGTK kann kein WebGPU) — beide randlos, eigene Titelleiste, gemeinsame React-App |
 | Frontend | React + TypeScript + Vite |
-| 3D | Three.js, plus eigener nativer Rust/WASM/WebGPU-Renderer (`render3d`) |
+| 3D | eigener Rust/WASM/WebGPU-Renderer „Nordstern" (`render3d`, Default), Three.js als leichtgewichtiger Zweitpfad |
-| 2D-Plan | eigener SVG-Renderer, plus eigener nativer Rust/WASM/WebGPU-Renderer (`render2d`) |
+| 2D-Plan | eigener Rust/WASM/WebGPU-Renderer (`render2d`), plus ein TS/WebGL2-Renderer (`plan/glPlan`), plus SVG (`PlanView.tsx`, immer als Interaktions-/Fallback-Ebene aktiv) |
-| Geometrie | eigener 2D-Kernel (`src/geometry/kernel2d.ts`), `delaunator` fürs Terrain |
+| Geometrie | eigener 2D-Kernel (`src/geometry/kernel2d.ts`); ein Rust-Port (`src-tauri/kernel2d`) existiert nur als Paritätstest, läuft nicht produktiv |
-| Export | `jspdf`/`svg2pdf.js` (Vektor-PDF), eigener DXF-Writer |
+| CSG/Extrusion | `trucksolid`-Crate (`truck` + `csgrs`), fürs Extrude-Kommando |
 | Export | eigener IFC4-Writer, `jspdf`/`svg2pdf.js` (Vektor-PDF), eigener DXF-Writer, STL/OBJ |
 | Import | `dxf-parser`, `@mlightcad/libredwg-web` (DWG), eigene `.lin`/`.pat`-Parser |
-| Schnitt/HLR-Spike | `opencascade.js` (OCCT-WASM) — isoliert, noch nicht verdrahtet |
+| Materialien | `jszip` (ambientCG-Zip-Entpacken), `three.js` `TextureLoader` |
-Geplant, aber noch nicht eingezogen: `rhino3dm` (NURBS / `.3dm`), web-ifc (IFC),
+`opencascade.js` steht noch als Dependency in `package.json`, wird aber nur
-Manifold (exakte 3D-Booleans). OCCT-WASM ist für HLR bereits als Spike da (s.o.),
+noch von totem Code (`src/section/hlr.ts`, superseded durch die Rust-
-aber noch nicht an Dokumentmodell/UI angebunden. Siehe ROADMAP §4.
+Schnitt-Pipeline) importiert. Details zu allen Rust-Crates (inkl. zwei
 aktuell unbenutzten WASM-Builds) in [ARCHITECTURE.md](ARCHITECTURE.md) §1
 und [STATUS.md](STATUS.md) §4.1.
 ## Entwicklung
 ```bash
 npm install
-npm run dev      # Vite, http://localhost:5187
+npm run dev        # Vite, http://localhost:5187
-npm run electron # Electron-Fenster (Dev-Server + randlose App-Shell)
+npm run tauri:dev  # Tauri-Fenster (macOS — nativer Zielrahmen dort)
-npx tsc -b       # Typecheck
+npm run electron   # Electron-Fenster (Linux — WebGPU über Chromium statt WebKitGTK)
-npm run build    # tsc -b && vite build
+npx tsc -b         # Typecheck
-npm test         # vitest run
+npm run build      # tsc -b && vite build
 npm test           # vitest run
 ```
-Verifiziert wird visuell: `node scripts/probe.mjs` rendert die App headless und
+WASM-Engines nach Rust-Änderungen neu bauen (nur `.rs` committen,
-schreibt `scripts/probe.png` — Screenshot ansehen, Geometrie prüfen. Weitere
+`src/engine/pkg*/` ist gitignored):
-`scripts/probe-*.mjs` decken einzelne Features ab (PDF, Trim, Materialien,
+
-Theme, Boolean-Ops …); für Firefox-Fälle gibt es `scripts/probe-ff*.mjs`
+```bash
-(Playwright).
+npm run build:engine     # render2d
 npm run build:engine3d   # render3d
 npm run build:truck      # trucksolid
 ```
 render3d/Wasm3DViewport-Änderungen sind nicht per Puppeteer/Browser
 verifizierbar — im laufenden `tauri:dev`-Fenster selbst testen.
 ## Aufbau
 ```
 src/
-  model/       semantisches Modell + Ableitungen (types, parametricWalls, roomStamp, joins, terrain)
+  model/       semantisches Modell (types, joins, parametricWalls, roomStamp, terrain)
-  geometry/    2D-Kernel (offset/trim/fillet/intersect, ceiling, opening, roomArea/-Boundary, stair)
+  geometry/    2D-Kernel (offset/trim/fillet/intersect, ceiling/opening/roomArea/stair/roof/column)
  commands/    Rhino-artiges Befehlssystem (engine, parser, registry, cmds/)
  tools/       interaktive Zeichenwerkzeuge + Snapping + Transformationen
-  plan/        Grundriss-Ableitung (generatePlan) + PlanView (SVG) + glPlan (WebGL2-Renderer)
+  plan/        Grundriss-Ableitung (generatePlan) + PlanView (SVG) + glPlan (WebGL2) + Rust-Bindings
-  viewport/    Viewport3D (Three.js)
+  viewport/    Viewport3D (Three.js) + Wasm3DViewport (Rust/wgpu „Nordstern", Default)
-  section/     HLR-Spike (OCCT-WASM) — Schnitte/Ansichten, noch nicht verdrahtet
+  section/     TOTER Code (OCCT-HLR-Spike) — Schnitt läuft über render3d, siehe ARCHITECTURE.md §4.3
-  export/      PDF- und DXF-Export aus derselben Plan-Struktur wie der Bildschirm
+  export/      IFC4-, PDF-, DXF-, STL/OBJ-, CSV-Export aus derselben Plan-/Modell-Struktur
-  materials/   PBR-Material-Bibliothek (ambientCG-Import, Runtime)
+  materials/   ambientCG-Live-Suche + gebündelte Starter-Bibliothek + PBR-Runtime
  text/        Rich-Text (Beschriftungen, Textobjekte)
  panels/      dockbares Panel-System + die einzelnen Paletten
-  state/       Store + Slices (project/selection/view/layout)
+  state/       eigener Store (useSyncExternalStore) + Slices (project/selection/view/layout/…)
-  ui/          Top-Bar, Statusleiste, Kontextmenü, Resource Manager, Command-Line
+  native/      Tauri-only: native Fenster, macOS-Menüleiste, Fenster-Chrome
  ui/          App.tsx-Shell, Top-Bar, Resource Manager, Kontextmenü, Kommandozeile, Ribbon
  io/          Import/Export (DXF, DWG, .lin, .pat), Swisstopo/LV95, OSM-Kontext
  i18n/        Wörterbücher de/en
-src-tauri/     Rust-Crates (render2d/render3d) — headless per wasm-pack zu WASM
+src-tauri/     6 Rust-Crates (render2d/render3d/geometry/kernel2d/trucksolid/dwgimport,
-               gebaut (npm run build:engine), Tauri-Host selbst ist ausrangiert
+               je headless UND per wasm-pack baubar) + der Tauri-Host selbst
 ```
 ## Konventionen
@@ -141,17 +149,30 @@ src-tauri/     Rust-Crates (render2d/render3d) — headless per wasm-pack zu WAS
  (Design Layer, Component, Hatch, Wall Style). **UI-Texte sind deutsch**, immer
  über `t('key')` — keine hartcodierten Strings im JSX.
 - Intern alles in **Metern**; Anzeige via `formatM`.
- `App.tsx` bleibt dünner Shell, Zustand lebt im Store. Verbindliches in
+- Verbindliches in [CONVENTIONS.md](CONVENTIONS.md).
  [CONVENTIONS.md](CONVENTIONS.md).
 ## Weiterlesen
- [ROADMAP.md](ROADMAP.md) — Produktvision, Architektur-Entscheidungen, Phasen 0–7, DOSSIER-Backlog
+- [STATUS.md](STATUS.md) — **vollständige, ehrliche Bestandsaufnahme**: Zahlen,
- [ARCHITECTURE.md](ARCHITECTURE.md) — Technische Architektur im Detail
+  Feature-Inventar, Mist-Liste, Doku-Widersprüche, Tag-1-Vision vs. heute
- [HANDOVER.md](HANDOVER.md) — aktueller Arbeitsstand, Befunde, nächste Schritte
+- [ARCHITECTURE.md](ARCHITECTURE.md) — technische Architektur im Detail (Ist-Zustand)
- [docs/](docs/) — Design-Specs (Befehlssystem, Zeichenwerkzeuge, Wand-Joins, Backend …)
+- [ROADMAP.md](ROADMAP.md) — ursprüngliche Produktvision (Tag-1-Stand, historisch)
 - [HANDOVER.md](HANDOVER.md) / [PENDENZEN.md](PENDENZEN.md) — laufendes
  Arbeitsprotokoll bzw. Backlog (Single Source of Truth für offene Punkte)
 - [docs/](docs/) — Design-Specs (teils ebenfalls Tag-1-Vision, siehe Hinweis
  in `docs/README.md`)
 ## Lizenz
 Copyright © 2026 Karim Gabriele Varano. Veröffentlicht unter der
 **GNU Affero General Public License v3.0 or later (AGPL-3.0-or-later)** —
 siehe [LICENSE](LICENSE). Dossier ist Teil der **openbureau**-Suite.
 Die AGPL verlangt, dass auch bei Betrieb als Netzwerk-/Webdienst der (ggf.
 geänderte) Quellcode für die Nutzer verfügbar gemacht wird. Drittkomponenten
 behalten ihre jeweiligen Lizenzen (siehe „Über"-Dialog in der App).
 ---
-Privates Projekt. Die UI ist deutsch; Schweizer Spezifika (SIA-416-Flächen,
+Die UI ist deutsch; Schweizer Spezifika (SIA-416-Flächen, Swisstopo-Geodaten)
-Swisstopo-Geodaten) sind als Differenzierer eingeplant.
+sind ein bewusster Differenzierer.
@@ -0,0 +1,43 @@
 # RESEARCH — Bauteile Treppe/Fenster/Tür: Rhino-Plugin als Vorbild
 Stand: 2026-07-05. Vergleich der authoritativen Rhino-Plugin-Implementierung
 (`/Users/karim/PROJECTS/DOSSIER/rhino/`, C#/Python + RhinoCommon-B-Rep) mit
 DOSSIER-STANDALONEs vereinfachter TS-Umsetzung. Ziel: Bauteile aufs Rhino-Niveau
 heben. Belege = Rhino-Funktionsnamen.
 **Grundsatz:** Rhino hat echten B-Rep-Kernel (3D). DOSSIER hat extrudierte Meshes +
 `kernel2d` (2D). Darum getrennt: **2D-Symbol-Logik** (leicht in TS/kernel2d
 übernehmbar) vs. **3D** (braucht Mesh-Pipeline bzw. später truck).
 ## Treppe (Rhino `treppe.py`, 1784 Z. — massiv reicher als `stair.ts`)
 - **Typen:** gerade / L (3- und 4-Punkt mit Podest) / Wendel (inkl. Spindel-Cone bei r_in<0.05). TS hat alle drei, aber simpler.
 - **3D-Querschnitt-Modi** `massiv`/`flach`/`plattenrand` (`_treppe_profile_2d`) — TS: nur Stufenboxen. **fehlt.**
 - **2D-Plansymbol** (`_make_treppe_2d_symbol`): Tritte, Lauflinie (4 Pfeil-Styles: klassisch/filled/breit/voll, visuell zentriert via `mid_off`), **Aussenlinie/Outline** (alle 3 Typen), Bruchlinie, Podest-Hexagon. TS: Tritte+Bruch+Lauflinie(1 Style) da; **Aussenlinie fehlt komplett**, Referenz links/mitte/rechts fehlt.
 - **Soll-Schrittmass** (2S+A, Lock), Show-Flags, Grips — fehlen in TS.
 ## Fenster (Rhino `elements.py` `_make_oeffnung_pieces`)
 - **3D:** Rahmen (BooleanDiff), Mittelpfosten je Flügel (1–4), Glas (einfach 12mm / Doppel 2×6+16), Sims aussen (4 Styles), Rahmen-Offset innen/mitte/aussen. TS: nur 2D-Rahmen+Glaslinien, Wand-Boolean-Loch (`1407c68`); kein Rahmen-3D.
 - **2D:** TS hat Rahmen + 1–2 Glaslinien (grob/mittel/fein). **Fehlt:** Brüstungslinie im Plan, Flügel-Mittelpfosten, Anschlag-Striche (nur Tür hat sie), Flügelanzahl.
 ## Tür (Rhino `elements.py`)
 - **Typen:** `normal` / `wandoeffnung` (reiner Durchbruch, kein Blatt). **Rahmen:** `zarge` (3-seitig, im Wandquerschnitt) / `block` (+5cm Überhang).
 - **2D-Schwung** (`_make_tuer_swing_curves`): Blatt+Arc, hinge_side/open_angle/aussenseite/swing_invert; Bogen-Anlage am Rahmen (standard/detail). **2D-Sturzlinien** (`_make_tuer_sturz_curves`, gestrichelt, Modi keine/innen/aussen/beide — SIA: Sturz über Schnittebene → gestrichelt). TS: Blatt+Arc+Anschlag (fein) da; **Sturzlinien fehlen komplett**, `wandoeffnung`-Typ + swing_invert fehlen.
 ---
 ## Gesamtreihenfolge „was zuerst" (Agenten-Empfehlung)
 **Gruppe A — 2D-leicht, hoher Plan-Wert, kernel2d-kompatibel:**
 1. **Treppe Aussenlinie/Outline** (alle 3 Typen; gerade=4 Linien, L via Linienschnitt `_line_intersect_xy`, Wendel=2 Bögen+radiale). Ohne sie wirkt der Plan unfertig.
 2. **Fenster Brüstungslinie** im Plan (1 gepunktete Linie bei sillHeight>0). XS.
 3. **Tür Sturzlinien** (gestrichelt, SIA) — Schulfall der geplanten Schnitt/Ansichts-Logik.
 4. **Treppe Referenz links/mitte/rechts** + Lauflinie visuell zentriert.
 5. **Fenster Flügel-Mittelpfosten** (2D, `wingCount` ins Modell).
 6. **Tür `wandoeffnung`-Typ** (reine Öffnung ohne Blatt/Symbol).
 7. Treppe Show-Flags + `obere_dashed`; 8. Fenster Anschlag-Striche.
 **Gruppe B — 2D mittel:** Tür-Schwung am Rahmen; Treppe Pfeil-Style `filled`; Fenster/Tür Styles/Presets; swing_invert.
 **Gruppe C — 3D (nach Mesh-/B-Rep-Pipeline):** Treppe `flach`-Querschnitt; Rahmen als Mesh (Fenster/Tür); Türblatt+Glas; Sims; L-Podest-Hexagon; Wendel helikoidale Unterseite (truck).
 **Bezug PENDENZEN:** Gruppe-A-Items 1–3 (Aussenlinie/Brüstung/Sturz) fallen in das Backlog-Item „Schnitt- vs. Ansichts-Darstellung nach Schnitthöhe" — Sturzlinie = Bauteil unter Schnittebene → gestrichelte Überkopf-Projektion. Gruppe C wartet auf den Textur-/Mesh-Pipeline-Nachfolger bzw. truck.
@@ -0,0 +1,162 @@
 # RESEARCH — Von BIM-Tool zu „echtem CAD": Ansätze aus fortgeschrittenen Programmen
 Stand: 2026-07-05. Direkt am Quellcode studiert (Repos nach `/tmp/cad-study` geklont,
 liegen NICHT im Projekt). Ziel: konkrete, verfolgbare Ansätze, um DOSSIER von einem
 spezialisierten BIM/Architektur-Werkzeug zu einem allgemeineren CAD zu erweitern.
 ## Studierte Programme
 | Repo | Was | Lizenz | Stack | Für uns |
 |---|---|---|---|---|
 | [OpenCADStudio](https://github.com/HakanSeven12/OpenCADStudio) | Eigenständige 2D/3D-CAD-App, ~200k LOC Rust | GPL-3.0 | Iced (GUI) + wgpu + WASM-Web-Build | **App-Architektur-Blaupause** (Entity-Modell, Command-System, Snap, Grips). Fast unser Stack. |
 | [truck](https://github.com/ricosjp/truck) | Reiner Rust-CAD-**Kernel** (NURBS/B-Rep/Mesh/Boolean/STEP) | Apache-2.0 | 16 Crates, wgpu-Rendering + `truck-js` (WASM) | **3D-Kernel-Blaupause**. OpenCADStudio nutzt ihn als 3D-Backend. |
 | [acadrust](https://github.com/HakanSeven12/acadrust) | Pure-Rust **DWG+DXF** R13–R2018 read+write, 41 Entity-Typen | **MPL-2.0** | nom/byteorder/flate2/nalgebra/encoding_rs (alles pure Rust) | **DWG/DXF-Rückgrat**, MPL-2.0 nutzbar, sehr wahrscheinlich WASM-baubar. |
 **Lizenz-Klarstellung:** `acadrust` ist **MPL-2.0** (file-level copyleft — für uns nutzbar,
 keine GPL-Ansteckung), NICHT GPL. `truck` ist Apache-2.0 (frei nutzbar). Nur OpenCADStudio
 selbst ist GPL-3.0 — wir lesen es als **Architektur-Referenz**, kopieren keinen Code.
 ---
 ## Die zentrale Lektion: was ein „echtes CAD" architektonisch ausmacht
 DOSSIER ist heute **domänenzentriert** (Wand/Öffnung/Component/Plan-Pipeline, TS-Modell).
 Ein echtes CAD (Rhino/AutoCAD-artig) hat stattdessen einen **generischen Kern**. Aus
 OpenCADStudios `src/` destilliert:
 ### 1. Generisches Entity-Modell mit Traits (statt Wand-Spezialfall)
 `src/entities/` = 41 Entity-Typen (line, arc, circle, lwpolyline, spline, ellipse, hatch,
 text, mtext, dimension, leader, insert/block, table, viewport, mesh, solid3d, …). Jeder
 Typ implementiert ein **Trait-Set** statt einer Sonderbehandlung:
 - `TruckConvertible` → 3D-Kernel-Geometrie
 - `FallbackTess` → Display-Geometrie (Punkte/Snap-Vertices)
 - `Grippable` → editierbare Griffe + Hover-Menü (Add Vertex / Convert to Arc / Reverse / Lengthen…)
 - `PropertyEditable` → Eigenschaften-Panel
 - `Transformable` → Move/Rotate/Scale/Mirror
 - `MassProps` → Fläche/Umfang für Abfragen
 → **DOSSIER-Lehre:** ein generisches `Entity`-Modell mit Trait-Dispatch neben das BIM-Modell
 stellen. Wir haben Ansätze (`Drawing2D`, splitJoin-Editoren, kernel2d), aber keine einheitliche
 Entity-Taxonomie mit Traits.
 ### 2. Modeless Command-System — der eine `StepInput`-Step-Machine
 `src/command.rs`: EIN Enum `StepInput { Point / Text / EntityPick / StructurePick /
 SelectionComplete }`. **Jede** Eingabequelle (Kommandozeile, Viewport-Klick, Pick, Selektion,
 Dynamic Input, Plugin-API, Headless-Script) übersetzt in `StepInput` und läuft durch **eine**
 `feed_command`-Funktion → treibt die aktive `CadCommand`-Step-Machine, egal woher der Schritt kam.
 → **DOSSIER-Lehre:** Das ist der größte UX-Unterschied. Echtes CAD = „Befehl tippen → Punkte
 picken → Optionen". DOSSIER ist heute Tool-Button + Direktmanipulation. Ein `StepInput`-Funnel +
 Kommandozeile wäre der Hebel, um beliebige Werkzeuge einheitlich, scriptbar und headless-testbar
 zu machen.
 ### 3. Object-Snap-Engine (eigenständig, groß)
 `src/snap.rs` = 70 KB nur für OSNAP (endpoint/midpoint/center/intersection/tangent/
 perpendicular/…). Wir haben Teil-Snapping; ein echtes CAD hat eine dedizierte, vollständige
 Snap-Schicht.
 ### 4. Universelle Grip-Editierung
 Jede Entity liefert Griffe + kontextuelle Griff-Menüs mit teils numerischem Follow-up
 („Lengthen" fragt Wert an der Kommandozeile ab). Einheitlich über das `Grippable`-Trait.
 ### 5. `CadDocument` als Dokumentmodell = das DWG/DXF-Objektmodell
 OpenCADStudio nutzt `acadrust::CadDocument` DIREKT als sein Datenmodell (Entities + Objects +
 Tables: Layer/Linetype/Style/Blocks + XData). D. h. das native CAD-Austauschformat IST das
 interne Modell → verlustfreier Round-Trip „for free".
 ---
 ## truck — 3D-Kernel-Blaupause (+ harte WASM-Realität)
 Saubere Schichtung (Ship-of-Theseus, kleine ersetzbare Crates):
 ```
 truck-base      Basistraits/Toleranz (cgmath)
 truck-geotrait  ParametricCurve / ParametricSurface Traits
 truck-geometry  Knot-Vektor, B-Spline, NURBS            ← Kurven/Flächen
 truck-topology  vertex/edge/wire/face/shell/solid       ← B-Rep-Topologie
 truck-modeling  Geometrie + Topologie integriert         ← Solids bauen
 truck-polymesh  Polygon-Datenstruktur + Meshing
 truck-meshalgo  Tessellation der Shapes
 truck-shapeops  Boolean-Ops auf Solids (v0.4 — früh)
 truck-stepio    STEP read/write (v0.3)
 truck-platform  wgpu-Grafik-Utility   ┐ Rendering — brauchen wir NICHT
 truck-rendimpl  Shape/Mesh-Visualisierung ┘ (wir haben eigenen wgpu-Renderer „Nordstern")
 truck-js        WASM-Wrapper (v0.2)
 ```
 **WASM-Realität (zwei Befunde abgeglichen):**
 - OpenCADStudio pinnt `truck-meshalgo` 0.4 und schaltet den `solid3d`-Feature **im WASM-Build ab**,
  weil dessen ACIS-/vtkio-Pfad über `xz2 → lzma-sys` (C-Bibliothek) nicht nach wasm32 kommt →
  **im Web ist OpenCADStudio nur 2D.**
 - Neuere `truck-meshalgo` (0.6) gated `rayon`/`vtkio` selbst per `cfg(not(target_arch="wasm32"))`
  aus → **baut zu wasm32, aber single-threaded**. Der reine Geometrie-Stack
  (base → geotrait → geometry → topology → polymesh → meshalgo → modeling → shapeops) hat keine
  native-only-Deps und ist **sauber vom wgpu-Rendering trennbar** (truck-platform/-rendimpl weglassen).
 **Reifegrad (Apache-2.0, aktiv, ~1 Hauptentwickler; ausdrücklich KEIN Produktionskern):**
 - NURBS/B-Spline + B-Rep-Topologie: **stabil** (v0.5/0.6).
 - Booleans (`truck-shapeops`): `and`/`or` vorhanden, aber **instabil bei coincident geometry**
  (Issue #114); **`difference` fehlt** (#85); **Fillets fehlen komplett**. Der Fork
  [`monstertruck`](https://github.com/virtualritz/monstertruck) hat difference + rolling-ball-Fillet.
  → Für unsere Wandöffnungen (boolean holes) haben wir das ohnehin schon selbst gelöst (`spanCutouts`).
 - `truck-stepio`: STEP **schreiben** (aber NICHT für boolean-operierte Shapes) + **lesen** (v0.6 beta,
  neues `truck_stepio::in`).
 - `truck-js`: fertiger wasm-bindgen-Wrapper (kein npm-Paket → selbst per `wasm-pack` bauen), bündelt
  modeling/shapeops/meshalgo/stepio; `IntoWasm`-Muster.
 ---
 ## acadrust — DWG/DXF-Rückgrat
 Pure Rust, **MPL-2.0**, `CadDocument`-Objektmodell (entities/objects/tables/xdata/classes),
 41 Entity-Typen, DWG „208/208 roundtrip-perfect", serde optional, failsafe-Parsing, ~40 Codepages.
 **Alle Deps pure Rust** (nom/byteorder/flate2-miniz/nalgebra/indexmap/ahash/encoding_rs) → sehr
 wahrscheinlich zu wasm32 baubar (Datei-I/O-API müsste auf Bytes/Reader statt `std::fs` umgestellt
 werden — vermutlich schon vorhanden). Heute nutzen wir JS `dxf-parser` (nur 2D) + `libredwg-web`.
 ---
 ## Web-Import-Landkarte (für den GEO-BLOCK / Import-Backlog)
 Pro Format die aktive, web-/WASM-taugliche Lib (Stand Mitte 2026):
 | Format | Empfohlene Lib | Lizenz | Anmerkung |
 |---|---|---|---|
 | DWG/DXF (browser) | `@mlightcad/cad-viewer` / `libredwg-web` (nutzen wir) **oder** `acadrust` (Rust) | MIT / GPL-3.0 / **MPL-2.0** | acadrust = Rust-Weg, MPL-2.0 |
 | STEP/IGES/BREP | `occt-wasm` (OCCT V8, ~4.5 MB) oder unser `opencascade.js` | LGPL-2.1 | occt-wasm = moderne TS-API |
 | **IFC** (BIM!) | `web-ifc` (ThatOpen) | MPL-2.0 | De-facto-Standard, read+write, sehr aktiv |
 | SHP/GIS | `shpjs` + `proj4` | MIT | direkt für GEO-BLOCK (SWISSIMAGE/Terrain) |
 | Punktwolken LAS/LAZ | `@loaders.gl/las` (+ `laz-perf`) | MIT/Apache | Rendering: `potree-core` oder deck.gl |
 | E57 | `e57-js` (Emscripten/libE57Format) | MIT | neu, funktional, sehr obskur |
 | glTF/OBJ/STL | three.js-Loader (haben wir via `three`) | MIT | |
 | 3MF | `lib3mf` (WASM) oder `THREE.3MFLoader` | BSD-2 / MIT | |
 | PDF-Vektor | `pdfjs-dist` `getOperatorList()` | Apache-2.0 | kein fertiges PDF→DXF; roher Pfad-Stream |
 ---
 ## Priorisierte Ansätze für DOSSIER (die eigentliche Antwort)
 Reihenfolge = Nutzen × Machbarkeit, ohne die BIM-Stärke zu opfern.
 1. **Generisches Entity-Modell + Trait-Dispatch** (Fundament). Neben das BIM-Modell eine
   generische Entity-Schicht (line/arc/circle/polyline/spline/text/dimension/hatch/block) mit
   Traits à la OpenCADStudio (Display/Grips/Props/Transform). Unser `kernel2d` liefert schon die
   Geometrie-Operationen dafür. **Größter struktureller Hebel.**
 2. **Modeless Command-System** (`StepInput`-Funnel + Kommandozeile). Ein Eingabe-Enum, eine
   `feed_command`-Schleife, `CadCommand`-Step-Machines. Macht Werkzeuge einheitlich, scriptbar,
   headless-testbar. **Größter UX-Hebel Richtung „echtes CAD".**
 3. **DWG/DXF-Round-Trip über `acadrust`** (Rust/WASM). MPL-2.0, pure Rust → passt in unseren
   neuen `src-tauri`-Kern. Ersetzt langfristig die JS-Parser, bringt echten Import/Export.
   Erst: WASM-Baubarkeit + Bytes-API verifizieren (Spike wie beim Textur-Spike).
 4. **Vollständige Object-Snap-Schicht** als eigenes Modul (endpoint/mid/center/intersection/
   tangent/perp/…), aufbauend auf `kernel2d`.
 5. **3D-B-Rep später, selektiv** (truck-geometry/-topology/-modeling als reine Crates, OHNE
   truck-Rendering — wir haben Nordstern). NUR wenn wir echte NURBS/Solids/Booleans brauchen; der
   Meshing-/Boolean-Pfad ist WASM-problematisch (native C-Deps) und Booleans sind noch früh.
   Bis dahin: truck als **Referenz** lesen, nicht einbinden.
 **Kernaussage:** DOSSIERs Rust-nach-WASM-Kurs (den wir mit `kernel2d` gerade gehen) ist genau
 richtig — OpenCADStudio bestätigt ihn. Der Weg zu „echtem CAD" führt über (1) generisches
 Entity-Modell und (2) modeless Command-System; (3) `acadrust` bringt echten DWG/DXF-Austausch.
 3D-B-Rep (truck) ist ein späterer, selektiver Schritt mit klaren WASM-Vorbehalten.
@@ -1,6 +1,16 @@
 # Browser-BIM für Wohnbau — Architektur & Produkt-Roadmap
-> Arbeitstitel: **cad** (Name später)
+> **Historisches Dokument (Tag-1-Vision, Stand 2026-06-28).** Vieles hier als
 > „Phase 2–5"/„Backlog" gelistete ist inzwischen längst gebaut (Treppen, Dächer,
 > Stützen, SIA-416, Swisstopo, OSM, Layouts, Ausschnitte, Kamera-Presets …), und
 > mehrere Technologie-Entscheidungen liefen anders (eigene Rust/WASM-Engines
 > statt Three.js/OpenCascade.js/web-ifc, siehe unten §4/§8). Für den aktuellen
 > Ist-Zustand: **[STATUS.md](STATUS.md)** (Bestandsaufnahme + Mist-Liste) und
 > **[ARCHITECTURE.md](ARCHITECTURE.md)** (aktuelle Architektur). Dieses Dokument
 > bleibt als ursprüngliche Produktvision/Phasenplan stehen, wird aber nicht mehr
 > laufend nachgeführt.
 >
 > Arbeitstitel: **cad** (Name später: **Dossier**)
 > Ausrichtung: **BIM-first** · Nische: **Wohnbau / Einfamilienhäuser**
 > Stand: 2026-06-28
@@ -0,0 +1,137 @@
 # SPIKE — Bild-Texturen in `render3d` (`RenderStyle::Textured` real machen)
 Stand: 2026-07-05. **Auftrag/Übergabe für einen Agenten. Kleinster ehrlicher
 Durchstich — kein Produktfeature, keine Integration.**
 Ziel: Beweisen, dass der bestehende wgpu-3D-Renderer echte **Bild-Texturen** auf
 Wandflächen darstellen kann, sichtbar im `spike3d`-Fenster. Am Ende steht eine
 belastbare Aussage, wie viel Arbeit „richtig gutes texturiertes 3D" wirklich ist —
 statt Spekulation.
 ---
 ## 0. Ausgangslage (verifiziert am 2026-07-05)
 - `render3d` ist **kein** Three.js-Wrapper, sondern ein eigenständiger wgpu-Renderer
  (~6400 LOC): echte GPU-Pipeline (wgpu 29), Tiefenpuffer, MSAA, WGSL-Shader.
  Läuft nativ (winit-Spike), headless (naga-validiert) und im Browser (WebGPU).
 - **`RenderStyle::Textured` existiert bereits als Stub** (`gpu.rs:34` Enum-Variante,
  `gpu.rs:47` Parse aus `"textured"`) — es gibt aber **kein echtes Texturing**:
  kein Sampler, keine Textur-Bind-Group, keine Bilddaten.
 - Die `cap_pipeline` mit Layout `[pos vec3, uv vec2]` + `CAP_WGSL` ist **nicht** für
  Bildtexturen, sondern für die **Schnittflächen-Kappen** (prozedurale Schraffur);
  die UVs steuern dort den Schraffur-Abstand. **Nicht damit verwechseln.**
 - **Günstig für uns:** Die Muster, die der Spike braucht, existieren schon —
  ein UV-tragendes Vertex-Layout und eine zweite/dritte Pipeline, die sich die
  `Globals`-Bind-Group teilt (`grid`, `cap`). Der texturierte Mesh-Pfad reiht sich
  1:1 in dieses Muster ein.
 ---
 ## 1. Echte Symbole — vor dem Coding lesen
 | Was | Ort |
 |---|---|
 | Vertex heute interleaved `[pos.xyz, normal.xyz, color.rgb]`, `FLOATS_PER_VERTEX`, `Mesh`-Struct | `src-tauri/render3d/src/types.rs:322` ff. |
 | Quad-Emitter (Normale + Farbe je Vertex, Reihenfolge `(0,1,2)+(0,2,3)`) | `src-tauri/render3d/src/mesh.rs:886` |
 | Wand-Extrusion / Mesh-Bau | `src-tauri/render3d/src/mesh.rs` — `extrude_wall` (`:91`), `build_walls_mesh` (`:911`) |
 | Haupt-Pipeline + `Globals`-Bind-Group (group 0) | `src-tauri/render3d/src/gpu.rs:232`–`:320` |
 | Vorlage „zweite Pipeline teilt sich Globals" — Grid | `src-tauri/render3d/src/gpu.rs:329` |
 | Vorlage „Pipeline mit UV-Layout `[pos vec3, uv vec2]`" — Cap | `src-tauri/render3d/src/gpu.rs:408` |
 | `RenderStyle`-Enum + Stub `Textured` | `src-tauri/render3d/src/gpu.rs:34`, `:47` |
 | Pipeline-Bindung im Render-Pass (Muster für Stil-Umschaltung) | `src-tauri/render3d/src/gpu.rs:847` |
 | Shader als WGSL-Konstanten (`MESH_WGSL`, `CAP_WGSL`) | `src-tauri/render3d/src/shaders.rs` |
 | Beleuchtungsmodell (hemisphärisch + Directional + Fill) — Doku | `src-tauri/render3d/src/shaders.rs:1`–`40` |
 | naga-WGSL-Validierung headless (Test-Vorlage) | `src-tauri/render3d/src/lib.rs:924` (`cap_module`) |
 | Fenster-Spike mit Orbit-Kamera | `src-tauri/render3d/src/bin/spike3d.rs` |
 ---
 ## 2. Umfang — exakt das, nicht mehr
 ### 2.1 UVs auf Wandflächen
 - In der Quad-Emitter-Funktion (`mesh.rs:886`) je Vertex eine **UV** berechnen:
  planare Projektion in **Metern** — `u` = Distanz entlang der Wandachse,
  `v` = Höhe (z). Textur-Raster damit weltmassstäblich (z. B. 1 Kachel = 1 m).
 - Den bestehenden `[pos, normal, color]`-Pfad **bitgleich unangetastet** lassen.
  Zwei zulässige Wege (Agent wählt begründet):
  1. **Separates additives UV-Array** in `Mesh` (Default leer/None), oder
  2. **Paralleler `build_walls_mesh_textured`** → interleaved
     `[pos.xyz, normal.xyz, uv.xy]`.
 - Regressionstests für den Alt-Pfad müssen grün bleiben (siehe §4).
 ### 2.2 Test-Textur prozedural (kein Asset, keine `image`-Crate)
 - Ein **256×256 RGBA-Schachbrett/Grid im Code** generieren (`Vec<u8>`).
 - `device.create_texture` + `queue.write_texture` + `Sampler`
  (`FilterMode::Linear`, `AddressMode::Repeat`). Mipmaps optional (nice-to-have für
  flache Blickwinkel; kein Muss für den Spike).
 - Selbstständig, damit der Spike ohne Dateipfade/Asset-Pipeline läuft.
 ### 2.3 Textur-Bind-Group (group 1)
 - Neue Bind-Group-Layout mit `texture_view` (`TextureSampleType::Float`) +
  `sampler`. **`Globals` bleibt group 0** und unverändert.
 ### 2.4 Textured-Pipeline + WGSL (`MESH_TEXTURED_WGSL`)
 - Vertex-Layout `[pos vec3, normal vec3, uv vec2]`, `TriangleList`.
 - **Dieselbe Beleuchtung wie `MESH_WGSL`** (hemisphärisches Ambient + Directional +
  Fill) — nur **Albedo = `textureSample(tex, samp, uv)`** statt Vertex-Farbe.
 - Depth-Format, MSAA (`SAMPLE_COUNT`) und Color-Target **identisch** zur
  Haupt-Pipeline (sonst inkompatibler Render-Pass).
 - Pipeline-Layout bindet group 0 (Globals) **und** group 1 (Textur).
 ### 2.5 Verdrahten
 - Bei `RenderStyle::Textured` im Render-Pass die neue Pipeline + beide Bind-Groups
  setzen (Muster: `cap_pipeline`-Bindung bei `gpu.rs:847`).
 ### 2.6 Spike sichtbar machen
 - `spike3d.rs` so erweitern, dass der Stil auf `Textured` schaltbar ist
  (Tastendruck, z. B. `T`, **oder** Startkonstante). Die Demo-Wände sollen
  texturiert im Orbit erscheinen.
 ---
 ## 3. Randbedingungen (hart)
 - **Nur** die `render3d`-Crate. `src/web.rs` und die Tauri-/`native3d`-Oberfläche
  **nicht** anfassen.
 - Feature-gegatet unter dem bestehenden `render`/`window`-Feature.
  **Default-Build und Default-Darstellung bleiben unverändert.**
 - **Keine neuen Dependencies** (insbesondere **kein `image`-Crate**) für den Spike.
 - Term-/Reihenfolge-sensible Geometrie (Parität) wird **nicht** berührt — es kommt
  nur additiv ein UV-Kanal + ein zweiter Render-Pfad dazu.
 - Kommentar-Stil und Sprache (Deutsch, ausführliche Begründungs-Kommentare) wie im
  umgebenden Code beibehalten.
 ---
 ## 4. Akzeptanz / Verifikation
 1. `cargo test` (im Crate-Verzeichnis `src-tauri/render3d`) **grün**, inklusive:
   - bestehende Mesh-Regression (Alt-Pfad `[pos,normal,color]` unverändert),
   - **neuer naga-Validierungstest** für `MESH_TEXTURED_WGSL` (Vorlage:
     `lib.rs:924`).
 2. `cargo run --features window --bin spike3d` zeigt die Demo-Wände mit
   **erkennbarer, korrekt gemappter** Schachbrett-Textur:
   - Raster weltmassstäblich (in Metern), keine Verzerrung an Gehrungen/Ecken,
   - beleuchtet wie im Shaded-Modus (Volumen bleibt ablesbar).
 3. Umschalten Shaded ↔ Textured zur Laufzeit (oder per Startkonstante) funktioniert
   ohne Re-Meshing-Crash.
 ---
 ## 5. Abschlussbericht (vom Agenten am Ende zu liefern)
 - Welche Dateien geändert/hinzugefügt wurden und warum.
 - Wie die UVs projiziert werden (Achswahl, Massstab, Verhalten an Gehrungen).
 - Welcher der beiden UV-Wege (§2.1) gewählt wurde und weshalb.
 - **Ehrliche Lückenliste für „richtig gutes" Texturing:** Asset-/Bild-Datei-Laden,
  Material→Textur-Zuordnung (Wandtyp/Layer → Material), Normal-/Roughness-Maps
  (PBR), anisotropes Filtern + Mipmaps, Web-Pfad (`web.rs`/WebGPU), UI zum
  Zuweisen. Grobschätzung Aufwand je Punkt.
 ---
 ## 6. Nicht im Scope
 Asset-/Bild-Datei-Laden · Material-System · mehrere Texturen gleichzeitig ·
 PBR/Normal-Maps · Web-Pfad (`web.rs`) · jegliche UI · Anbindung unter die Webview.
@@ -0,0 +1,342 @@
 # STATUS — Codebase-Analyse
 > Stand: 2026-07-21 · Vollständige Bestandsaufnahme von Code + Dokumentation.
 > Ersetzt NICHT [ROADMAP.md](ROADMAP.md)/[ARCHITECTURE.md](ARCHITECTURE.md) (die wurden
 > im gleichen Zug überarbeitet), sondern begründet die Überarbeitung mit Zahlen und
 > Befunden. [HANDOVER.md](HANDOVER.md) und [PENDENZEN.md](PENDENZEN.md) bleiben die
 > laufenden Arbeitsprotokolle (nicht rückwirkend umgeschrieben).
 ## 0. TL;DR
 „Dossier" (Arbeitstitel `cad`, Rhino-Vorbild `DOSSIER`) ist in **3 Wochen**
 (erster Commit 2026-06-30, 362 Commits bis 2026-07-20) von einem Risiko-Spike zu
 einem **funktionsreichen Desktop-CAD/BIM-Tool** gewachsen: eigenes semantisches
 Gebäudemodell, zwei eigene Rust/WASM-Rendering-Engines („Nordstern"), ein
 Rhino-artiges Kommandosystem, IFC/DXF/PDF/STL/OBJ-Export, Swisstopo-Import,
 SIA-416-Flächen, Materialbibliothek (statisch + live von ambientCG), Layouts/
 Plansätze, Ausschnitte, native Tauri-Fenster. **~125.000 Zeilen Code** (TS+Rust,
 inkl. Tests), gebaut über viele autonome Agent-Sessions.
 Die drei zentralen Vision-Dokumente (ARCHITECTURE.md, README.md, ROADMAP.md)
 stammen aus der **allerersten Woche** (Stand 28./29.6.) und beschreiben einen
 Plan, der in der Zwischenzeit an vielen Stellen überholt, anders gelöst oder
 längst umgesetzt wurde (z. B. HLR/OCCT→eigene Rust-Schnitt-Pipeline,
 „Booleans noch offen"→teilweise längst gelöst). Diese Doku-Drift war der Auslöser
 für diese Analyse; die Docs sind im gleichen Zug revidiert worden.
 ## 1. Kennzahlen
 ### Code-Umfang
 | Bereich | Dateien | LOC (ohne Tests) | Tests |
 |---|---:|---:|---:|
 | `src/` (TypeScript, gesamt) | ~230 | 87.736 | 869 (Vitest, 71 Dateien) / 16.855 LOC |
 | `src-tauri/render3d` („Nordstern" 3D) | 14 | 10.246 | 97 `#[test]` |
 | `src-tauri/render2d` (2D-WGSL-Renderer) | 11 | 3.530 | 18 `#[test]` |
 | `src-tauri/kernel2d` (Rust-Geometriekern, Paritätstest) | 1 | 3.383 | 18 `#[test]` |
 | `src-tauri/geometry` (Wand-Join-Mathe, **unbenutzt**) | 1 | 1.057 | 8 `#[test]` |
 | `src-tauri/trucksolid` (CSG/Extrusion, `truck`+`csgrs`) | 2 | 758 | 15 `#[test]` |
 | `src-tauri/dwgimport` (DXF-Parser-Spike, **unbenutzt**) | 1 | 284 | 1 `#[test]` |
 | `src-tauri/src` (Tauri-Host: Fenster, Dialoge, Lock) | 4 | 1.044 | — |
 | **Gesamt** | | **~108.000** (ohne Tests) / **~125.000** (mit Tests) | 869 Vitest + 157 Rust-Tests |
 Größte TS-Bereiche: `plan/` (23.626 LOC — Plan-Ableitung + 3 Renderer),
 `ui/` (12.897 LOC — App-Shell, ResourceManager, Ribbon), `panels/` (9.538 LOC),
 `model/` (7.043 LOC inkl. Tests), `commands/` (6.973 LOC), `io/` (5.299 LOC),
 `state/` (5.297 LOC), `geometry/` (5.559 LOC), `viewport/` (5.165 LOC),
 `export/` (4.280 LOC). `src/App.tsx` allein ist **7.130 Zeilen**.
 ### Tempo
 362 Commits in 3 Wochen; Woche 27 (30.6.–6.7.): 233 Commits, Woche 28: 126,
 danach starker Rückgang (Woche 30 bislang 3) — die Session-Dichte hat spürbar
 abgenommen, nicht das Projekt gestoppt (siehe PENDENZEN.md, weiterhin aktiv).
 ## 2. Architektur, wie sie WIRKLICH ist (nicht wie geplant)
 ### 2.1 Datenmodell — kein `Element[]`-Union, sondern typisierte Arrays
 `ARCHITECTURE.md` (alt) plante eine diskriminierte Union `Element = Wall | Door |
 Window | …`. Tatsächlich hält `Project` (`src/model/types.ts:2095`) **pro
 Bauteiltyp ein eigenes optionales Array**: `walls`, `ceilings?`, `roofs?`,
 `doors`, `openings?` (Fenster/Türen gehostet in Wänden, `kind:"window"|"door"`),
 `stairs?`, `rooms?`, `columns?`, `extrudedSolids?`, `drawings2d`, `context?`
 (Importe/Terrain), plus die Bibliotheks-/Typtabellen (`lineStyles`, `hatches`,
 `components`, `wallTypes`, `roofTypes?`, `doorTypes?`, …) und die
 Dokument-Ebene (`viewSnapshots?`, `layouts?`, `masterLayouts?`, …). Der Typ-Alias
 `Element` (types.ts:1601) existiert zwar noch, wird aber **nirgends** verwendet
 (Element-Baum/Selektion arbeiten direkt auf den typisierten Arrays). Praktisch
 funktioniert das gut (jeder Bauteiltyp hat sein eigenes, spezifisches Interface),
 ist aber eine bewusste Abweichung vom ursprünglichen Uniform-Union-Plan.
 ### 2.2 State — kein Zustand/Redux/Immer, sondern ein Eigenbau
 `docs/design/state-architecture.md` empfahl **Zustand**. Gebaut wurde stattdessen
 ein **abhängigkeitsfreier Store auf `useSyncExternalStore`** (`src/state/store.ts`,
 gleiches Muster wie `src/i18n`). `createStore()` komponiert Slice-Fabriken
 (`projectSlice` inkl. Undo/Redo, `historySlice`, `selectionSlice`, `viewSlice`,
 `layoutSlice`, `siteSlice`, `notifySlice`) über eine gemeinsame `RootState`.
 Funktioniert, aber: der geplante Folgeschritt „App.tsx wird dünne Shell,
 View-Routing nach `src/views/`, Kontextmenüs nach `src/menus/`" ist **nicht**
 passiert — `src/views/` und `src/menus/` existieren nicht, View-Umschaltung und
 Kontextmenü-Aufbau liegen weiterhin inline in `App.tsx` (7.130 Zeilen). Das ist
 der deutlichste Doku-vs-Code-Widerspruch im ganzen Repo (CONVENTIONS.md
 verlangt explizit das Gegenteil).
 ### 2.3 Rendering — drei 2D-Pfade, zwei 3D-Viewports
 **2D-Plan:** es gibt tatsächlich **drei** koexistierende Renderer, nicht einen:
 1. `PlanView.tsx` (SVG) — Referenz-/Fallback-Pfad, bleibt IMMER im DOM für
   Hit-Testing/Grips, unabhängig davon was zeichnet.
 2. `plan/glPlan/` — eigener TypeScript-WebGL2-Renderer (`glPlanCompile/-Render/
   -Shaders/-Hatch.ts`).
 3. `useWasmPlanRenderer.ts` → Rust-`render2d`-Crate (WGSL, nativ via wgpu,
   Web via WebGPU/WebGL2-Fallback, inkl. echtem Text-Rendering via `glyphon`).
 Beide GPU-Pfade fallen bei Initialisierungsfehler still auf SVG zurück.
 **3D:** ebenfalls zwei Viewports: `Viewport3D.tsx` (three.js, „Free"-Stufe) und
 `Wasm3DViewport.tsx` (Rust/wgpu „Nordstern", editierbar, **Default**). Ein
 Settings-Schalter wählt die Engine.
 ### 2.4 Schnitt/Section — NICHT über HLR, sondern eigene Rust-Pipeline
 `src/section/hlr.ts` + `occt.ts` (der ursprüngliche OpenCascade.js-HLR-Spike aus
 Phase 0) hat **keinen einzigen Aufrufer mehr** im gesamten `src/` — toter Code.
 Der tatsächliche, funktionierende Live-Schnitt läuft über einen völlig anderen,
 analytischen Mechanismus: `App.tsx` (`section3dCutId`/`section3dPlane`) →
 `Wasm3DViewport.tsx` (`section3d`-Prop → `setSectionPlane`) →
 `src-tauri/render3d/src/{section.rs, section_boolean.rs, section_fill.rs}`.
 Die Rust-Seite nutzt aus, dass jedes Bauteil ein Prisma mit konstantem
 Querschnitt ist — eine Schnittebene liefert dadurch immer ein
 achsparalleles Rechteck, nie ein Trapez; `section_boolean.rs` ist ein 1:1-Port
 von `toSection.ts::subtractDominantBands`, damit 2D-Plan-Schnitt und
 3D-Live-Schnitt exakt übereinstimmen. Kein Worker, kein Comlink (beides war
 geplant, keines existiert) — läuft synchron/GPU-seitig.
 ### 2.5 Öffnungen als Löcher — echt, aber kein Mesh-Boolean
 Fenster/Türen schneiden echte achsparallele Rechteck-Löcher aus dem Wandkörper
 (`plan/toWalls3d.ts` `RHole`/`subtractSpans`, gespiegelt in
 `render3d/{mesh.rs,section.rs}`) — funktioniert, ist aber KEIN generisches
 Mesh-Boolean. Ein echtes CSG-Boolean existiert bereits (`trucksolid::boolean_mesh`,
 `csgrs`-basiert, 15 Rust-Tests) und wird von `src/engine/truckSolid.ts` für das
 Extrusions-Kommando genutzt — ist aber **nicht** an die Wand/Öffnungs-Pipeline
 angeschlossen (bestätigt: `booleanMesh` hat ausserhalb von `truckSolid.ts`
 keinen Aufrufer).
 ### 2.6 Rust-Workspace: sechs unabhängige Crates, nicht ein Workspace
 `src-tauri/Cargo.toml` bindet nur den Tauri-Host (`cad-tauri`) als Workspace-
 Mitglied; `render2d/render3d/geometry/kernel2d/trucksolid/dwgimport` sind
 **eigenständige Cargo-Packages**, die dem Host nur optional (Features
 `native2d`/`native3d`, standardmässig AUS) als Path-Dependency zugespielt
 werden. Jedes Crate muss headless (`cargo test`) UND per `wasm-pack --features
 web` bauen, ohne den Tauri-Toolchain-Zwang zu erben — bewusst so geschnitten.
 Geteilte Abhängigkeiten: `wgpu 29`/`naga 29` (render2d+render3d, versionsgekoppelt
 wegen `glyphon 0.11`), `truck-modeling`+`csgrs`(gepinnter Git-Rev)+`nalgebra`
 nur in `trucksolid`.
 ### 2.7 Zwei Desktop-Rahmen: Tauri (macOS) + Electron (Linux)
 Die App läuft plattformabhängig in **zwei verschiedenen nativen Rahmen** —
 das ist Absicht, kein Wildwuchs, und hängt an **WebGPU**:
 - **macOS → Tauri.** WKWebView unterstützt WebGPU, das die render2d/render3d-
  WASM-Engines brauchen. `src-tauri/tauri.conf.json` (Identifier
  `ch.dossier.cad`, eigene Titelleiste, `trafficLightPosition`) +
  `isTauriRuntime()`-Gates an 6+ Stellen in `App.tsx` + vier eigene native
  Zusatzfenster (`src/native/`: Resources, Settings, DrawingLevels,
  LayerSettings, ContextImport).
 - **Linux → Electron.** Tauris Linux-Webview **WebKitGTK unterstützt WebGPU
  nicht zuverlässig** → dort läuft die App über eine Electron/Chromium-Shell
  (`scripts/electron-main.cjs` + `electron-preload.cjs`, gestartet via
  `npm run electron`). Der Kommentar in `electron-main.cjs` sagt es explizit:
  „Ersetzt WebKitGTK durch Chromium, damit WebGPU zuverlässig läuft."
 Beide teilen sich **dieselbe** React-App und dieselbe randlose eigene
 Titelleiste; die Laufzeit erkennt den Host über `window.__TAURI__` (Tauri)
 bzw. `window.dossierWindow` (Electron, per `contextBridge` injiziert). Die
 Fenstersteuerung (`src/ui/WindowControls.tsx`) ist an beide Wege angebunden.
 Kein Rust-Backend nötig auf dem Electron-Pfad — `computeJoins` hat einen
 TS-Fallback (`src/compute/index.ts`). Electron ist also **kein** totes Gleis,
 sondern der aktive Linux-Zielrahmen.
 ## 3. Feature-Inventar (was tatsächlich funktioniert)
 ### Modell & Bauteile
 - Mehrschichtige Wände (`WallType.layers[]`) mit L-Eck-Gehrung UND
  Prioritäts-T-/X-Stössen (`joinPriority` am Component) — **fertig**, in 2D-Plan,
  3D-Viewport UND 3D-Live-Schnitt konsistent (Rust-Port `section_boolean.rs`).
 - Parametrische Wände (`ParametricWall`: Grid/Modul/Sequenz/Referenzlinie/
  bedingte Dicke) lösen sich zu konkreten `Wall[]` auf.
 - Decken (Slabs, `ceilings?`) mit Aussparungen, eigenem Typkatalog.
 - Türen/Fenster gehostet in Wänden, mit Rahmen/Zarge/Blockrahmen, Kämpfer,
  Oberlicht, Detailgrad grob/mittel/fein (2D UND 3D), Schwenkbogen; daneben
  existiert weiterhin ein **älteres, separates `Door[]`** neben `Opening[]` —
  laut PENDENZEN.md explizit als offene Doppelspur/Aufräum-Punkt vermerkt.
 - Treppen (gerade/L/Wendel), geschossübergreifend, 2D-Symbol mit Lauflinie/Pfeil.
 - Dächer (Flach/Pult/Sattel/Walm/Mansarde/Zelt) über Rechteck-Umriss, First/
  Traufe/Grat im 2D-Plan.
 - Stützen (Column) mit Profilbibliothek (Quadrat/Rechteck/Rund/I/Rohr).
 - Räume (SIA-416: HNF/NNF/VF/FF/GF/AGF) mit automatischer Bilanz + CSV-Export,
  Raumstempel-Editor (Drag&Drop-Felder).
 - Extrudierte Volumenkörper (truck-Integration: konkave Profile, Verjüngung).
 - Kontext-Layer (Terrain-TIN, importierte Meshes, Konturen) — semantisch getrennt.
 ### Zeichnen & Bedienung
 - Rhino-artiges Kommandosystem (`commands/`): getippte Koordinaten
  (`5,3`/`r5,3`/`5<45`), Tab-Feld-Zyklus für Präzisionseingabe
  (`src/ui/CommandLine.tsx`), Alias/Autocomplete, ~25 Kommandos (wall, ceiling,
  opening, stair, column, roof, room, line/polyline/rect/circle/arc, text,
  move/mirror/copy/offset/trim/join, extrude, import, terrain, measure,
  Schnittlinie, Georef).
 - Snapping (Endpunkt/Mitte/Schnittpunkt/Lot/Raster/Ortho), Grips, Array,
  Trim/Split/Join, 2D-Booleans (Union/Subtract/Intersect via `polygon-clipping`).
 - Messwerkzeug (Polygonzug, Länge + Fläche).
 - Rich-Text-Annotationen (Bold/Kursiv/Hoch-/Tiefstellung).
 ### Darstellung / Ressourcen
 - Resource Manager: Line/Hatch/Component-Manager, Wand-/Decken-/Tür-/Fenster-/
  Treppen-/Dach-Typeditoren — als eigenständiges natives Fenster (nicht als
  Dock-Panel).
 - Materialbibliothek: 13 fest gebündelte PBR-Starter (ambientCG, lokale
  Texturen) **plus** Live-Suche der kompletten ambientCG-Bibliothek (Auflösung
  1K/2K/4K, on-demand Download+Entpacken via `jszip`, Proxy wegen CORS) — heute
  bereinigt (siehe Commit-Historie dieser Session).
 - Regelbasierte Overrides (Bedingung → Farbe/Strichstärke/Schraffur/Sichtbarkeit).
 - Detailgrad grob/mittel/fein je Bauteil + Dokument-Override.
 - Hell-/Dunkel-Theme, Akzentfarben.
 ### Pläne / Output
 - Ausschnitte (View-Snapshots: Kamera, Massstab, Detailgrad, Sichtbarkeiten,
  Override-Preset) in Ordnerstruktur.
 - Layout-Blätter (Plansätze): Papierformat/-grösse, mehrere Viewports pro
  Blatt, Masterlayout-Vererbung (Titelblock), Ordnerstruktur, freie 2D-Annotationen.
 - Vektor-Export: PDF (Einzelblatt UND **Mehrseiten pro Ordner**,
  `layoutPdf.ts::buildFolderPdf`), DXF, IFC4 (mit echten Fenster-/Tür-Löchern,
  deterministischen GUIDs), STL, OBJ, CSV-Bauteil-Schedule (volles Element-Set).
 - Kamera-Presets (Kardinal + Iso), Norden-Rotation.
 ### Import / Kontext
 - DXF (Konturen), DWG (`@mlightcad/libredwg-web`, WASM), `.lin`/`.pat`.
 - Swisstopo: swissBUILDINGS3D (radiusgenau zugeschnitten, nicht die ganze
  STAC-Kachel), swissALTI3D, SWISSIMAGE-Orthofoto-Draping, LV95↔WGS84,
  Georeferenzierung über EINEN Vermessungspunkt (E/N/H, `geoAnchor`).
 - OSM/Overpass-Kontextimport (7 Kategorien).
 - Terrain-Mesh-Generator.
 ### Desktop-Integration (Tauri)
 - Eigene randlose Fenster mit nativer Titelleiste (macOS-Ampel-Position).
 - Native Speichern/Öffnen-Dialoge (`plugin-fs`/`plugin-dialog`), eigenes
  `.obp`-Projektdateiformat.
 - OS-Level-Exklusiv-Lock gegen Doppelöffnen desselben Projekts (`fs4`-Crate).
 - Vier eigenständige native Zusatzfenster (Resources, Settings, DrawingLevels,
  LayerSettings, ContextImport) statt Overlay/Modal.
 - Native macOS-Menüleiste.
 - i18n de/en durchgängig, eigener `t()`-Mechanismus (kein i18next).
 ## 4. Mist-Liste — Befunde, Doku-Widersprüche, offene Fäden
 ### 4.1 Verwaiste WASM-Crates (gebaut, aber nirgends importiert)
 - **`src-tauri/geometry`** (1.057 LOC, 8 Tests) → `pkgGeometry` — **null**
  Importstellen in `src/`. Wand-Join-Mathe existiert redundant als TS
  (`src/model/joins.ts`) UND als Rust-Port, aber nur die TS-Version läuft.
 - **`src-tauri/dwgimport`** (284 LOC) → `pkgDwgImport` — **null** Importstellen;
  DWG-Import läuft stattdessen über `@mlightcad/libredwg-web` (npm-Paket).
 - **`src-tauri/kernel2d`** (3.383 LOC, 18 Tests) → `pkgKernel2d` — wird nur von
  einem Paritätstest (`kernel2d.parity.test.ts`) konsumiert, nicht produktiv.
  Die TS-Version `src/geometry/kernel2d.ts` (886 Zeilen) ist die tatsächlich
  laufende Implementierung. Laut PENDENZEN.md bewusst so belassen: ein
  Join-Benchmark zeigte WASM unter ~100 Wänden **langsamer** als die naive
  TS-Routine. Kein Bug, aber die drei Crates zusammen sind ~4.700 Zeilen Rust
  (+44 Tests), die aktuell nichts zur Laufzeit beitragen ausser einem
  Korrektheits-Cross-Check für kernel2d.
  **Empfehlung:** entweder (a) `geometry`- und `dwgimport`-Crate + ihre
  `build:*`-Scripts entfernen (kein Nutzen, nur Wartungslast), oder (b)
  explizit als „Referenzimplementierung/Zukunftsoption" in ARCHITECTURE.md
  dokumentieren, damit niemand sie für aktiv hält.
 ### 4.2 Toter Code
 - `src/section/hlr.ts` + `occt.ts` + `occt-wasm.d.ts` (473 LOC) — OCCT-WASM-
  HLR-Spike aus Phase 0, **keine Aufrufer mehr**. Ersetzt durch die analytische
  Rust-Schnitt-Pipeline (§2.4). `opencascade.js` bleibt als npm-Dependency
  bestehen, obwohl nur noch dieser tote Code sie importiert.
 - `src/export/planToPrintSvg.ts` — Kommentar im Code selbst sagt „ERSETZT durch
  `sceneToPrintSvg.ts`", ist aber noch im Baum.
 - `Element`-Typalias (`src/model/types.ts:1601`) — definiert, nirgends benutzt.
 ### 4.3 Das grösste Doku-vs-Code-Problem: App.tsx
 CONVENTIONS.md verlangt seit Tag 1 „App.tsx bleibt dünner Shell, keine
 Geschäftslogik". `docs/design/state-architecture.md` plante explizit die
 Extraktion nach `src/views/` (View-Routing) und `src/menus/`
 (Kontextmenü-Aufbau). Beide Ordner **existieren nicht**. `App.tsx` ist mit
 **7.130 Zeilen** die grösste Einzeldatei des Projekts und enthält weiterhin
 View-Umschaltung und Kontextmenü-Konstruktion inline. Das ist der genaue
 „God-Component"-Zustand, den die Doku von Anfang an vermeiden wollte.
 ### 4.4 Bekannte Doppelspur: `Door[]` vs. `Opening[]`
 `Project` führt sowohl ein älteres `doors: Door[]` als auch das neuere,
 allgemeinere `openings?: Opening[]` (`kind:"door"|"window"`). Laut
 PENDENZEN.md ist das erkannt und als Aufräum-Punkt vorgemerkt, aber nicht
 konsolidiert.
 ### 4.5 Doku-Widersprüche (README/ARCHITECTURE/CONVENTIONS vs. Realität)
 | Dokument | Behauptung | Realität |
 |---|---|---|
 | README.md | Shell = Electron, Tauri „ausrangiert" | Falsch andersrum gedacht: **beide** sind aktiv — Tauri auf macOS (WKWebView+WebGPU), Electron auf Linux (WebKitGTK kann kein WebGPU); siehe §2.7 |
 | README.md | „HLR noch nicht ans UI verdrahtet, Views sind Stubs" | Der OCCT-HLR-Pfad stimmt (tot), aber Schnitte/Ansichten funktionieren real über eine andere, eigene Rust-Pipeline |
 | README.md | „Prioritäts-T-/X-Stösse … Risiko #1" unter „bewusst offen" | Seit 7.7. erledigt, inkl. Rust-Port |
 | README.md | „PDF-Export ist noch single-sheet" | `layoutPdf.ts::buildFolderPdf` erzeugt echte Mehrseiten-PDFs pro Ordner |
 | README.md | Engine-Liste nennt nur render2d/render3d | Es gibt 6 Rust-Crates (+kernel2d/geometry/trucksolid/dwgimport) |
 | CONVENTIONS.md | Struktur-Ziel `src/views/`, `src/menus/` | Existieren nicht; Logik liegt in `App.tsx` |
 | CONVENTIONS.md | Dev-Port 5173 | Tatsächlich 5187 (`vite.config.ts`, `tauri.conf.json`) |
 | ARCHITECTURE.md | Ziel-Struktur `store/`, `sheets/`, `workers/geometry.worker.ts` (Comlink) | Tatsächlich `state/`, `panels/layoutModel.ts`; kein Worker/Comlink irgendwo im Projekt |
 | ARCHITECTURE.md | HLR „im Web Worker (Comlink)" | Kein Comlink im Projekt; Schnitt läuft synchron GPU-seitig in Rust |
 | HANDOVER.md | Neuester Block: „Stand 2026-07-09" | Jüngster Commit + PENDENZEN.md sind vom 17.–20.7. — 8+ Tage/mehrere Sessions veraltet |
 ### 4.6 Codequalität — besser als der Tempo vermuten lässt
 Trotz 3 Wochen / 362 Commits über viele autonome Sessions: **keine** FIXME/HACK/
 XXX-Marker im ganzen Projekt; nur 2 TODOs (beide bekannt/harmlos: Geländer in
 `Viewport3D.tsx:2649`, Kanten-Tiefe in `toSection.ts:1093`); `eslint-disable`
 fast ausschliesslich `react-hooks/exhaustive-deps` (bewusst); keine
 `_v2`/`_old`/`_backup`-Dateileichen. Die eigentliche Aufgabenliste lebt
 diszipliniert in PENDENZEN.md statt in Code-Kommentaren verstreut — gesünder
 als der Durchschnitt für dieses Bau-Tempo.
 ### 4.7 Genuine offene Punkte (Auszug aus PENDENZEN.md, Details dort)
 - Geo-Block: Layer-Zuordnung für importierte Gebäude/Terrain, reale Höhen +
  Projekt-müM-Draping, SWISSIMAGE-Draping.
 - 3D-Feinschliff: Fensterrahmen-Ecken bei „fein" überlappen (kein Gehrungs-
  Union), Dach-First/Grat hat unverschmolzene Dreiecke, unerklärte
  Vertikalstreifen auf oberen Wandflächen (undiagnostiziert).
 - truck-Boolean nicht an die Wand/Öffnungs-Pipeline angeschlossen (Scope-
  Entscheid mit Nutzer ausstehend).
 - Feld-Controller (Tab-Zyklus) fehlt für Body-Move und für 3D-Griffe generell
  (nur 2D-Einzelpunkt-Drag hat ihn); 3D-Griff-Drag hat gar kein Snapping.
 - `make2D`-Kommando (3D→flacher 2D-Plan mit Füllungen) ungebaut.
 - Ribbon-3D-Tab leer; einige Punkte visuell noch nicht in Tauri abgenommen
  (u. a. Materialfarben-Textur-Array, Schraffur-Schnittfüllung — laut
  PENDENZEN als „[~] implementiert, aber unverifiziert" markiert).
 - DWG/DXF-Domänen-Mapping (Entitäten → Wände/Öffnungen) unbegonnen; DWG-Schreiben
  fehlt (Lesen über `libredwg-web` vorhanden).
 - Teamwork/Kollaboration (Supabase) bewusst nicht begonnen, gilt als späte Phase.
 ## 5. Vergleich: Tag-1-Vision vs. heute
 | Vision (28./29.6.) | Heute |
 |---|---|
 | Three.js als einziger 3D-Renderer, OpenCascade.js für Booleans/HLR | Eigene Rust/WASM-Engines („Nordstern") für 2D+3D; three.js nur noch „Free"-Fallback; OCCT-Pfad tot |
 | Ein `Element[]`-Union | Typisierte Arrays pro Bauteiltyp auf `Project` |
 | Zustand-Store | Eigener `useSyncExternalStore`-Store |
 | Web Worker + Comlink für HLR | Synchrone, analytische Rust-GPU-Schnitt-Pipeline |
 | „Booleans: Entscheidung in Phase 0" | Trucksolid/csgrs-CSG existiert, ist getestet, aber nicht an Wände angeschlossen |
 | web-ifc für IFC | Eigener IFC4-Writer (`exportIfc.ts`) |
 | Phase 2–5 grösstenteils „Backlog" | Treppen, Dächer, Stützen, SIA-416, Swisstopo, OSM, Kamera-Presets, Layouts, Ausschnitte, Terrain — alles bereits gebaut |
 Kurz: die **Prinzipien** (ein Modell, viele Ableitungen; Darstellung erst beim
 Rendern; keine Cache-Stale-Bugs) haben gehalten und wurden korrekt umgesetzt.
 Die **konkreten Technologie-Entscheidungen** sind fast durchgängig anders
 gelaufen als geplant — meist zugunsten einer eigenen, schnelleren Rust/WASM-
 Lösung statt einer Drittbibliothek.
@@ -1,4 +1,4 @@
-# HAUPTINSTANZ-BRIEFING: Tauri + wgpu (Korrigiert)
+# ARCHITEKTUR-BRIEFING: Tauri + wgpu (Korrigiert)
 **Stand:** 2026-07-01 — **KORREKTUR** (vorherige Dokumente waren unvollständig)
@@ -158,7 +158,7 @@ npm run tauri:build  # → Windows .exe / macOS .app / Linux .deb
 ---
-## Nächste Schritte (für Hauptinstanz)
+## Nächste Schritte
 1. **Lesen:** `docs/design/tauri-migration-plan.md` (technisch, konkret)
 2. **Spawn:** vier Agents (parallel, unabhängig)
@@ -1,6 +1,13 @@
 # Dokumentation — Standalone Browser-BIM (cad)
-> Stand: 2026-06-29 · Übergeordnet: [ROADMAP.md](../ROADMAP.md) (Vision & Phasen) ·
+> Stand: 2026-06-29 · **Historische Recherche-/Design-Dokumente aus der ersten
 > Woche.** Mehrere Kern-Empfehlungen hier (replicad/OCCT als B-Rep-Kernel,
 > Manifold, web-ifc, `three/webgpu`) wurden im tatsächlichen Bau **nicht**
 > umgesetzt — stattdessen entstanden eigene Rust/WASM-Rendering-Engines
 > („Nordstern"). Für den aktuellen Ist-Zustand: **[../STATUS.md](../STATUS.md)**
 > und **[../ARCHITECTURE.md](../ARCHITECTURE.md)**. Die Dokumente unten sind als
 > Recherche-Hintergrund weiterhin lesenswert, aber nicht mehr aktueller Plan.
 > Übergeordnet: [ROADMAP.md](../ROADMAP.md) (Vision & Phasen, ebenfalls historisch) ·
 > [CONVENTIONS.md](../CONVENTIONS.md) (Konventionen) · [ARCHITECTURE.md](../ARCHITECTURE.md).
 Dieses Verzeichnis bündelt die Recherche- und Design-Dokumente für `cad`, die
@@ -0,0 +1,623 @@
 # BIM-Elementtiefe — Tür, Fenster, Dach, Decke ("wirklich 1:1")
 ## 0. Zweck und Abgrenzung
 DOSSIER modelliert Bauteile heute semantisch (kein reines Zeichenprogramm) und
 hat für Wand/Decke bereits eine mehrschichtige Aufbaulogik (`Component[]` via
 `WallType`/`CeilingType`). Türen und Fenster haben seit
 `docs/design/window-editor-vectorworks-study.md` einen dedizierten,
 phasierten Ausbauplan (Flügeltabelle, Verglasung, Sonnenschutz). Was fehlt,
 ist die gleiche Tiefe für **Dach** (keine Schichtlogik, keine Mansard-
 Untertypen, kein Kehl-/Gaubenmodell) und für die **Decken-Randterminierung**
 (Deckenrand als reines Polygon ohne Kantendetail).
 Dieses Dokument nimmt die vier Bauteile Tür, Fenster, Dach, Decke und hält
 sie gegen die reale Tiefe vollständiger BIM-Programme (Vectorworks Architektur,
 ArchiCAD, Revit, Allplan). Ziel ist NICHT, jedes Feature dieser Programme zu
 kopieren, sondern zu benennen, welche Lücken einen echten "1:1-Zuwachs" für
 ein Einfamilienhaus-/Wohnbau-Tool wie DOSSIER bringen — und welche reiner
 Ballast wären (Abschnitt 6).
 Für Fenster/Tür dupliziert dieses Dokument NICHT die Mapping-Tabelle aus
 `window-editor-vectorworks-study.md` — es referenziert sie und ergänzt, was
 dort fehlt (v. a. Tür-Tiefe, die die Studie nur am Rand behandelt, und die
 architektonischen Grenzen des heutigen Öffnungsmodells). Für Wand-Schichtlogik
 siehe `docs/design/parametric-walls.md` (Raster/Modul-Regeln, nicht
 Gegenstand hier) und `docs/design/elements.md` (ältere Gesamtplanung, Stand
 vor der aktuellen `Component`/`Layer`-Implementierung — dort abweichende
 Typnamen wie `Slab`/`ProfileDef`, hier durchgängig der IST-Code zitiert).
 Alle IST-Aussagen sind mit Datei:Zeile belegt (verifiziert per Lesen des
 Codes, Stand dieses Commits). Status-Legende der Lücken-Tabellen: **✓**
 vorhanden und gerendert · **~** Feld existiert, Renderer liest es nicht oder
 nur grob · **✗** fehlt vollständig. Priorität P0 (grösster 1:1-Zuwachs, bald)
 … P3 (Ballast, nur auf Nachfrage). Aufwand grob in Personentagen (PT).
 ---
 ## 1. Gemeinsames Fundament: das Schicht-Muster
 Der zentrale Baustein, den DOSSIER bereits hat und der sich wiederverwenden
 lässt, ist `Component`/`Layer`:
 - `Component` (`src/model/types.ts:196`) — ein Bauteil-Material: Poché-Farbe
  (`color`/`foreground`/`background`), Schnitt-Schraffur (`hatchId`) UND
  Ansichts-Schraffur (`viewHatchId`, für unaufgeschnittene Aufsicht),
  optionales PBR-Material (`material`), Kürzel (`abbrev`) und ein
  Verschneidungs-Rang (`joinPriority`, `types.ts:241`) für die Boolean-
  Dominanz am Stoss.
 - `Layer` (`types.ts:245`) — eine Schicht: `componentId` + `thickness` +
  optionaler Fugen-Linienstil (`jointLineStyleId`).
 - `WallType` (`types.ts:260`) und `CeilingType` (`types.ts:273`) sind BEIDE
  nur `{ id, name, layers: Layer[] }` — bewusst derselbe Typ, "das
  horizontale Gegenstück zum WallType" (Kommentar `types.ts:266-271`).
 Das Muster ist also bereits zweimal (Wand, Decke) verifiziert:
 `ceilingThickness()` (`types.ts:2104`) summiert die Layer-Dicken,
 `emitSlabs()` (`src/plan/toWalls3d.ts:1352-1419`) stapelt sie im 3D als
 einzelne `RSlab`-Scheiben proportional in `[zBottom, zTop]`, `addCeilingPoche`
 (`src/plan/generatePlan.ts:2453`) zeichnet die Aufsicht mit der
 Ansichts-Schraffur der ERSTEN Schicht, und `toSection.ts:633`
 (`splitSlabLayers`) zerlegt die Decke im ECHTEN Schnitt in
 Einzel-Bänder je Schicht (mit `resolveCeilingSectionStyle`,
 `generatePlan.ts:591`, als Schraffur-/Farbquelle).
 **Der Dach-Vorschlag in Abschnitt 4 ist im Kern: dasselbe Muster ein drittes
 Mal anwenden.** Das ist der günstigste Weg zu echter Dach-1:1-Tiefe, weil
 Layer-Resolver, Schraffur-Ketten (`resolveHatch`/`resolveForeground` etc.,
 `generatePlan.ts:409-536`) und die 3D-Stapel-Logik bereits bestehen und nur
 auf einen neuen Aufbau-Typ angewendet werden müssen statt neu erfunden.
 Architektonische Randbemerkung: `Project` führt bereits `wallTypes`,
 `ceilingTypes?`, `doorTypes?`, `windowTypes?`, `stairTypes?`
 (`types.ts:1936-1958`) als eigene Bibliotheken — aber **kein `roofTypes?`**.
 `Roof` (`types.ts:1022`) trägt nur ein einzelnes `thickness: number`
 (`types.ts:1044`), keinen Aufbau-Verweis. Das ist die strukturelle Lücke,
 die Abschnitt 4 schliesst.
 ---
 ## 2. Tür (Door)
 ### 2.1 Was ein vollständiges BIM-Tool bietet
 | Bereich | Typische Parameter (VW/ArchiCAD/Revit/Allplan) |
 |---|---|
 | Bauart | Dreh-, Schiebe- (auf/vor Wand), Falt-, Pendel-, Karusselltür, reiner Durchbruch |
 | Blattzahl/-teilung | 1-/2-flügelig, Gangflügel + Standflügel (unterschiedliche Breite), Seitenteile links/rechts |
 | Blattausführung | glatt, kassettiert, Glasfüllung (Anteil/Sprossenbild), Brandschutz-/Schallschutz-Kennwert |
 | Rahmen/Zarge | Zarge vs. Blockrahmen, Rahmenbreite je Kante, Zargentiefe, Bekleidung/Abdeckleiste, Falz |
 | Schwelle | ohne, Alu-Flachschwelle, Anschlagdichtung, Bodenanschluss/Gefälle bei Aussentüren |
 | Sturz/Oberlicht | festverglastes Oberlicht mit eigenem Rahmen, Kämpfer, Sprossenbild |
 | Seitenteile | fest verglaste Seitenteile links/rechts, eigene Breite |
 | Form | rechteckig, Rundbogen, Segmentbogen, Stichbogen — bei Aussen-/Haustüren verbreitet |
 | Beschlag | Drücker/Knauf-Typ, Schild, Schliesszylinder, Bänder sichtbar/verdeckt |
 | 2D-Darstellung | Blatt + Schwenkbogen (Grundriss), eigene Ansichtssymbolik in Schnitt/Elevation, Sturzlinien |
 | Material/Schichten | Blatt-Kernaufbau (bei Brand-/Schallschutztüren mehrschichtig, analog Wand) |
 | IFC-Rolle | `IfcDoor` mit `IfcDoorType` (PredefinedType), `OverallWidth/Height`, `IfcDoorPanelProperties`, Void in der Wirtswand |
 ### 2.2 IST in DOSSIER
 `Opening` mit `kind: "door"` (`src/model/types.ts:1068`) referenziert
 optional einen `DoorType` (`types.ts:296`). Vorhanden am Typ: `kind`
 ("dreh"/"schiebe"/"wandoeffnung", :303), `leafCount` (1|2, :305), `leafStyle`
 ("glatt"/"kassette"/"glas", :307), `glazingRatio` (:309), `frameThickness`/
 `frameDepth`/`frameKind`("zarge"/"blockrahmen")/`frameWidth`
 (:311-328), `insetFromFace`/`insetFace` (:335-337), `transomHeight` (:343),
 `threshold` (:349). Am Element selbst: `swing`/`hinge`/`swingAngle`/
 `openingDir` (:1104-1108), `lintelLines` (Sturzlinien, :1119) und
 `doorType: "normal"|"wandoeffnung"` (:1100) — ein zweites, mit `DoorType.kind`
 teilweise redundantes Feld.
 Renderer-Konsum, real geprüft:
 - **2D-Blatt ist IMMER einflügelig.** `addOpeningSymbol` (Tür-Zweig,
  `src/plan/generatePlan.ts:2091-2213`) zeichnet genau EINE Blattlinie
  (`sym.hinge → sym.openEnd`) und EINEN Schwenkbogen — `DoorType.leafCount`
  wird an keiner Stelle in `generatePlan.ts` gelesen (kein Treffer für
  `leafCount` im ganzen Plan-Renderer). Eine zweiflügelige Tür sieht im Plan
  aus wie eine einflügelige.
 - **3D genauso**: `resolveOpeningFrame` (`src/plan/toWalls3d.ts:1861-1886`)
  setzt für Türen hart `wingCount: 1`, unabhängig von `leafCount`.
 - `leafStyle` wirkt NUR binär: `"glas"` schaltet eine volle Verglasung frei
  (`glazed: dt.leafStyle === "glas"`, `toWalls3d.ts:1883`) — `glazingRatio`
  (Teilverglasung, z. B. 60 % Glasanteil im oberen Blattbereich) wird an
  keiner Stelle gelesen. "kassette" (Kassettentür) hat keine eigene Geometrie,
  fällt auf dieselbe Quader-Darstellung wie "glatt" zurück.
  `frameKind: "blockrahmen"` wirkt NUR im 2D-Rahmenband
  (`generatePlan.ts:1996`, `isBlock`), im 3D gibt es keinen Unterschied zur
  Zarge (`frameMeshesForOpening`, `toWalls3d.ts:1936`, kennt kein
  `frameKind`).
 - `threshold` steuert `hasSill` im 3D-Rahmen (`toWalls3d.ts:1880`), was einen
  einfachen Schwellen-Riegel zeichnet — kein eigenes Schwellenprofil,
  keine Gefälle-/Dichtungsdarstellung.
 - Es gibt eine ZWEITE, ältere Tür-Repräsentation: `Door`
  (`types.ts:1333`, `project.doors: Door[]`) mit eigenem Symbol-Renderer
  `addDoorSymbol` (`generatePlan.ts:1840-1899`) — strukturell identisch zum
  `Opening`-Pfad, aber ohne jeden Typ-Bezug. Zwei parallele Datenwege für
  dieselbe Bauteilart sind selbst technische Schuld, nicht nur ein
  BIM-Feature-Gap.
 - Form (Rundbogen etc.) existiert nicht: `Opening.width`/`height` sind ein
  reines Rechteck, `wallGaps`/`buildWallFootprints`
  (`generatePlan.ts:1363-1457`) schneiden nur rechteckige Bänder aus der
  Wand-Poché.
 - IFC-Export: `IfcDoor` wird erzeugt (`src/export/exportIfc.ts:30-31`), aber
  als reine Box-Geometrie ohne `IfcDoorType`/`PredefinedType` und ohne
  `IfcOpeningElement`-Void (bewusste Design-Entscheidung, siehe Kommentar
  `exportIfc.ts:18-31`: das Loch steckt bereits im geschnittenen Wand-Mesh).
 ### 2.3 Lücken (Tür)
 | Feature | Status | Priorität | Aufwand |
 |---|---|---|---|
 | Zweiflügelige Tür rendert 2 Blätter (2D+3D) | ✗ (`leafCount` ungelesen) | **P0** | 2 PT |
 | Teilverglasung nach `glazingRatio` (2D-Linie + 3D-Split) | ✗ | P1 | 1.5 PT |
 | Kassettentür eigene Blattgeometrie (Füllungsfelder) | ✗ | P2 | 2 PT |
 | `frameKind` (Blockrahmen) auch im 3D wirksam | ~ | P1 | 1 PT |
 | Seitenteile (feste Verglasung links/rechts der Tür) | ✗ | P1 | 2 PT |
 | Rundbogen-/Segmentbogen-Türform | ✗ | P2 | 4 PT (braucht gekrümmten Wandausschnitt, s. §5.3) |
 | Schwellenprofil (Alu-Flachschwelle, Dichtung) statt Riegel | ✗ | P2 | 1 PT |
 | `Door`/`Opening`-Doppelpfad konsolidieren | technische Schuld | P1 | 3 PT (Migration) |
 | Beschlag (Drücker/Knauf) als Mesh + 2D-Symbol | ✗ | P2 | 1.5 PT |
 | IFC `IfcDoorType`/PredefinedType/OverallWidth-Height-Properties | ~ | P2 | 1 PT |
 ### 2.4 Umsetzungsvorschlag
 **Modell**: `DoorType.leafs?: { width: number; hingeSide: "left"|"right";
 fixed?: boolean }[]` analog `WindowType.sashes` (`SashDef`, `types.ts:367`) —
 bewusst dieselbe Struktur, damit `resolveSashSpans` (`toWalls3d.ts:2019`) UND
 die 2D-Pfostenlinien-Logik direkt wiederverwendet werden können, statt eine
 Tür-eigene Variante zu bauen. Ein `fixed: true`-Leaf ist das Seitenteil.
 `glazingRatio` wandert vom Skalar zu einer klaren Geometrie: Kämpferhöhe
 innerhalb des Blatts, gerendert wie das bestehende Oberlicht
 (`transomHeight`), nur INNERHALB des Blattrahmens statt darüber.
 **2D**: `addOpeningSymbol` (Tür-Zweig) über die Leaf-Liste iterieren statt
 einer festen Blattlinie; pro Leaf ein eigenes `hinge`/`swing` (Default:
 alternierend wie bei Fenstern, `sashesOfWindowType`, `types.ts:2132`).
 **3D**: `resolveOpeningFrame` liefert `wingCount = leafs.length` statt hart 1;
 `frameMeshesForOpening` (bereits generisch über `params.sashes`) übernimmt
 die Mehrflügel-Darstellung ohne Änderung — das ist der Vorteil der
 Struktur-Wiederverwendung.
 **UI**: Im Tür-Editor (sofern nach dem Muster von
 `window-editor-vectorworks-study.md` gebaut) eine Flügeltabelle wie bei
 Fenstern, nur mit Tür-Vokabular (Gangflügel/Standflügel statt Flügel 1/2).
 ---
 ## 3. Fenster (Window)
 Für Fenster existiert bereits eine vollständige Referenzmatrix in
 `docs/design/window-editor-vectorworks-study.md` §2 (Basiseinstellungen,
 Grösse, Brüstung, Rahmen, Flügeltabelle, Laibung/Form/Ober-Unterlicht,
 Sonnenschutz/Beschlag, Attribute/IFC) mit eigener P0–P3-Phasierung. Diese
 Studie ist der massgebliche Bezugspunkt; hier nur die Delta-Punkte, die dort
 fehlen oder seither vom IST abweichen.
 ### 3.1 IST-Ergänzung (was die Studie nicht/knapp behandelt)
 - `WindowType.glazing` (einfach/zweifach/dreifach) ist bis heute NICHT
  renderwirksam — bestätigt weiterhin: `glazingPanesOf()` (`types.ts:2149`)
  wird von `glassPanesForOpening` in `toWalls3d.ts` konsumiert, aber die
  Studie selbst vermerkt (Zeile 61-65 dort), dass der 2D-Pfad die
  Scheibenzahl weiterhin allein aus `DetailLevel` ableitet, nicht aus
  `glazingPanes`. Das ist über ein Jahr nach der Studie noch offen — ein
  Hinweis, dass P0/P1-Posten aus Fenster-Studien real liegen bleiben, wenn
  niemand sie explizit nachzieht.
 - `sillBoard` (Fensterbank keine/innen/aussen/beide, `types.ts:447`) ist
  weiterhin ungenutzt (kein Treffer für `sillBoard` in `toWalls3d.ts` oder
  `generatePlan.ts` ausserhalb der Typ-Definition und des Editors) —
  entspricht dem in der Studie als P1 markierten "Fensterbank erstellen".
 ### 3.2 Architektonische Grenze: gekrümmte Öffnungen
 Sowohl die Fenster-Studie (§2.6, "Form Eckig/Schräg/Spitz/Rund", P2, 4 PT)
 als auch dieser Auftrag nennen Rundbogen-/Spitzbogenfenster. Das ist teurer,
 als die Aufwandschätzung suggeriert, weil das gesamte Öffnungsmodell auf
 GERADEN Bändern basiert: `buildWallFootprints`/`wallGaps`
 (`generatePlan.ts:1363-1457`) schneiden ein rechteckiges Intervall `[from,to]`
 entlang der Wandachse aus der Poché, `openingAxisBox`
 (`toWalls3d.ts:1739`) baut im 3D ebenso einen achsparallelen Quader. Eine
 Bogenform braucht entweder (a) eine gekrümmte Zusatzkontur, die die
 Rechteck-Aussparung oben kappt (2D: zusätzliche Polygon-Boolean gegen die
 Poché; 3D: gekrümmte Deckfläche statt ebenem Sturz) oder (b) ein komplett
 neues, polygonbasiertes Öffnungsmodell. Vorschlag: (a) zuerst — ein
 `headShape: "eckig"|"segment"|"spitz"|"rund"` mit Zusatzparametern
 (Stichhöhe/Radius), das NUR die obere Kante der bestehenden Rechteck-Öffnung
 ersetzt, während Pfosten/Sohlbank rechteckig bleiben. Deckt die reale
 Mehrheit der Fälle (Haustür mit Rundbogen, Dachflächenfenster-Giebel) ohne
 das Kernmodell umzubauen.
 ### 3.3 Lücken (Fenster, Delta zur Studie)
 | Feature | Status | Priorität | Aufwand |
 |---|---|---|---|
 | `glazing`/`glazingPanes` 2D-wirksam (Scheibenzahl statt nur DetailLevel) | ~ (weiter offen seit Studie) | **P0** | 1 PT |
 | `sillBoard` gerendert (2D-Kontur + 3D-Box) | ✗ | P1 | 2 PT |
 | Kopfform (Rundbogen/Spitzbogen/Schräge) über Zusatzkontur | ✗ | P2 | 5 PT (s. §3.2) |
 | Echtes Sprossengitter (Glasteilung UNABHÄNGIG von Flügelrahmen) | ✗ | P1 | 2 PT |
 | Alle übrigen Fenster-Lücken | siehe window-editor-vectorworks-study.md §2/§4 | — | — |
 ---
 ## 4. Dach (Roof)
 ### 4.1 Was ein vollständiges BIM-Tool bietet
 | Bereich | Typische Parameter |
 |---|---|
 | Grundform | Pult, Sattel, Walm, Krüppelwalm, Zeltdach, Mansarde (mit Untertyp Giebel-/Walm-/Zeltmansarde), Flach/Terrassendach, Sheddach, Tonnendach, freie Neigungsflächen je Kante |
 | Grundriss | beliebiges Polygon (nicht nur Rechteck), automatische Kehlen/Grate über Straight-Skeleton bei L-/T-/U-Grundrissen |
 | Neigung | je Dachfläche einzeln editierbar, unterschiedliche Neigungen je Seite |
 | Schichtaufbau | Eindeckung (Ziegel/Blech/Bitumen), Lattung, Konterlattung, Unterdach/-spannbahn, Sparren/Dämmung zwischen Sparren, Dampfbremse, Innenverkleidung — analog Wandaufbau, mit Deckenanschluss |
 | Überstand | Traufe und Ortgang UNABHÄNGIG editierbar (Betrag + Ausbildung), Aufschiebling (Neigungsknick am Traufende), Ortganddetail (Windbrett, Blech) |
 | Kniestock/Drempel | vertikale Wandaufkantung zwischen Deckenoberkante und Dach-Traufpunkt, definiert First-/Trauf-Geometrie mit |
 | Öffnungen im Dach | Dachflächenfenster (schräg, in der Dachebene), Dachgauben (Schlepp-, Sattel-, Walm-, Spitzgaube, Fledermausgaube) als eigenständige Sekundärdächer mit eigenem First |
 | First/Grat/Kehl/Ortgang | eigene Linientypen in 2D-Ansicht (Dachaufsicht) UND im Schnitt sichtbar (Sparrenlage, Dämmstärke) |
 | Material/Poché | Dachfläche in der Aufsicht mit Eindeckungs-Symbol/-Schraffur (Ziegel-Textur o. Ä.), im Schnitt Vollschichten wie eine geneigte Wand |
 | IFC-Rolle | `IfcRoof` (aggregiert `IfcRoofType`), Dachflächen selbst oft als `IfcSlab`-artige Elemente mit `IfcMaterialLayerSetUsage`, Gauben als eigene `IfcRoof`/`IfcBuildingElementProxy`-Unterobjekte |
 ### 4.2 IST in DOSSIER
 `Roof` (`src/model/types.ts:1022-1047`) rechnet ausschliesslich auf der
 **Bounding-Box** des Umrisses (Kommentar `types.ts:1016-1020`: "First entlang
 einer Hauptachse ... die gängige, intuitive Vereinfachung"). Geometrie kommt
 aus `roofGeometry()`/`computeCanonical()` (`src/geometry/roof.ts:80-267`),
 explizit **"ohne Straight-Skeleton"** (Kommentar `roof.ts:5`). Unterstützte
 `RoofShape` (`types.ts:1013`): flach/pult/sattel/walm/mansarde/zelt — je EINE
 feste Berechnung, keine Untertypen. Mansarde hat eine feste, nicht editierbare
 Knick-Geometrie (`d1 = halfD * 0.4`, `roof.ts:181` — 40 % der Tiefe von der
 Traufe, hart codiert, keine Möglichkeit den Umbruchpunkt zu verschieben).
 Konkrete, verifizierte Lücken:
 - **Kein Schichtaufbau.** `Roof.thickness` (`types.ts:1044`) ist ein
  einzelner Skalar. Er wird an KEINER Stelle im Code gelesen (`grep
  "roof.thickness"` über `toWalls3d.ts`/`generatePlan.ts`/`roof.ts` liefert
  null Treffer) — das Feld existiert im Typ, ist aber komplett tot. Die
  3D-Dachfläche ist eine unendlich dünne, einfarbige Fläche
  (`emitRoofs()`, `src/plan/toWalls3d.ts:1670-1684`: nur `plane.pts`/
  `gable`-Fans, EINE Farbe `ROOF_RGB` bzw. `roof.color`, keine Dicke, keine
  Materialschichten).
 - **Kein `RoofType`.** `Project` hat `wallTypes`, `ceilingTypes?`,
  `doorTypes?`, `windowTypes?`, `stairTypes?` (`types.ts:1936-1958`), aber
  kein `roofTypes?`. Es gibt keinen Bauteil-Bibliothekseintrag für Dächer.
 - **2D-Grundriss zeigt keine Poché.** `addRoof()`
  (`src/plan/generatePlan.ts:2549-2605`) zeichnet AUSSCHLIESSLICH Linien
  (Traufe/First/Grat/Knick, je feste Strichstärke `ROOF_EAVES_MM`/
  `ROOF_RIDGE_MM`/`ROOF_HIP_MM`) — keine Fläche, keine Schraffur, keine
  Materialkennzeichnung. Deckungsgleich mit Wand/Decke, die BEIDE eine
  Poché-Füllung mit Schraffur haben (`addWallPoche`, `addCeilingPoche`),
  bleibt das Dach in der Aufsicht ein reines Liniendiagramm.
 - **Kein Schnitt.** `src/plan/toSection.ts` hat KEINE Roof-Behandlung (kein
  Treffer für `roof`/`Roof` im gesamten Datei-Grep). Ein Vertikalschnitt
  durch ein Gebäude mit Satteldach zeigt heute keine Dachlinie, keine
  Sparrenlage, keine Firstprojektion — ein Kernstück der BIM-1:1-Erwartung
  fehlt vollständig.
 - **Kein IFC.** `exportIfc.ts` erzeugt `IfcWall`, `IfcSlab`, `IfcDoor`/
  `IfcWindow`, `IfcStair`, `IfcBuildingElementProxy` (Kommentar
  `exportIfc.ts:18-36`) — `Roof`/`IfcRoof` ist in der Abbildungsliste NICHT
  aufgeführt und wird beim Export komplett übersprungen.
 - **Kein Straight-Skeleton, kein L-Grundriss mit Kehle.** Ein L-förmiger
  Baukörper mit durchgehendem Satteldach (Kehle an der Innenecke) lässt sich
  nicht abbilden — die BBox-Rechnung würde ein Rechteck über die ganze
  L-Ausdehnung legen.
 - **Keine Gauben, keine Dachfenster.** Kein Treffer für Gaube/Dormer im
  gesamten `src`-Baum (verifiziert per Suche).
 - **Kein Kniestock als Bauteilbeziehung.** `baseElevation` (`types.ts:1042`)
  erlaubt zwar, die Traufhöhe manuell über die Geschoss-Oberkante zu heben
  (ein Kommentar in `ObjectInfoPanel.tsx:549` erwähnt das explizit als
  Nutzungsmuster), aber es gibt keine Wand-Dach-Kopplung, die einen
  Drempel/Kniestock als eigenes, vermasstes Bauteil führt — der Nutzer muss
  die Zahl manuell abstimmen.
 - **Traufe/Ortgang nicht unabhängig.** `overhang` (`types.ts:1038`) ist EIN
  Wert "ringsum" — Traufüberstand und Ortgangüberstand (oft unterschiedlich,
  z. B. 0.5 m Traufe / 0.3 m Ortgang) sind nicht trennbar.
 - **UI**: `ObjectInfoPanel.tsx:479-561` bietet volle Instanz-Bearbeitung
  (shape/ridgeAxis/pitch/pitchUpper/width/depth/overhang/thickness/
  baseElevation), aber keine Typ-/Stil-Verwaltung (kein `ResourceManager`-
  Eintrag für Dächer, anders als Wand/Decke/Tür/Fenster/Treppe).
 ### 4.3 Dach-Schichtlogik — konkreter Vorschlag (Kernthema dieses Dokuments)
 Der Vorschlag überträgt exakt das `WallType`/`CeilingType`-Muster:
 ```
 export interface RoofType {
  id: string;
  name: string;
  /** Aussen (Eindeckung) → innen (Verkleidung), analog WallType.layers. */
  layers: Layer[];
 }
 ```
 Kein neuer Layer-Typ nötig — `Layer` (`types.ts:245`) ist bereits
 "Bauteil + Dicke + optionaler Fugen-Linienstil", unabhängig davon ob sie
 horizontal (Decke), vertikal (Wand) oder GENEIGT (Dach) gestapelt wird, weil
 die Stapel-Richtung beim jeweiligen Renderer entschieden wird, nicht im
 Datentyp. Typische Schichtfolge eines Steildachs (Eindeckung → Konterlattung
 → Lattung → Unterdach/Unterdeckbahn → Sparren+Dämmung → Dampfbremse →
 Innenverkleidung/GKB) bildet sich 1:1 auf `Layer[]` ab, jede Schicht bekommt
 ein `Component` mit eigener Schraffur/Farbe/Material wie bei Wand/Decke.
 `Roof.thickness: number` wird zu `Roof.roofTypeId?: string` (Verweis, analog
 `Ceiling.ceilingTypeId`) mit optionaler `thicknessOverride?: number` — exakt
 das Muster aus `Ceiling.thickness?` (`types.ts:952-953`, "Optionale
 Übersteuerung der Gesamtdicke ... sonst Typ-Dicke"). `Project.roofTypes?:
 RoofType[]` ergänzt die Bibliothek.
 **3D-Konsum**: `emitRoofs()` (`toWalls3d.ts:1670`) baut heute EINE
 Dreiecksfläche je Dachfläche+Giebel. Mit Layern wird daraus — analog
 `emitSlabs()` (`toWalls3d.ts:1352-1419`, das bereits genau diese
 Proportional-Stapel-Logik für Decken hat) — ein Stapel PARALLEL versetzter
 Flächen entlang der Flächennormalen (nicht entlang Z wie bei der Decke,
 sondern entlang der Dachflächen-Normalen `n`, siehe `RoofGeometry.planes`
 in `roof.ts:19-21`). Jede Schicht wird zum eigenen `RMesh` mit eigener Farbe/
 Schraffur-Metadaten (`RCutMeta`, wie bei `emitSlabs`). Der Versatz macht
 zugleich die Dachdicke sichtbar (heute unendlich dünn) — ein Nebengewinn ohne
 Mehraufwand.
 **2D-Konsum (Grundriss/Aufsicht)**: `addRoof()` bekommt eine Poché-Fläche
 analog `addCeilingPoche` — Füllung mit der `viewHatchId` der obersten Schicht
 (Eindeckungssymbol), gerahmt von den bestehenden Traufe/First/Grat/Knick-
 Linien (die bleiben unverändert, sie sind flächen-unabhängig).
 **2D-Konsum (Schnitt, der grössere Umbau)**: `toSection.ts` braucht einen
 neuen Roof-Zweig. Ansatz: die Dachebene mit der Schnittebene schneiden
 (Ebene-Ebene-Schnitt, da `RoofPlane` eben ist), daraus ein Liniensegment je
 betroffener Dachfläche gewinnen, dann `Layer[]` senkrecht ZUR
 Dachneigung als Bandsequenz auftragen (wie `resolveWallBands`,
 `toWalls3d.ts:521`, aber gedreht um den Neigungswinkel `pitchDeg`) und mit
 `splitSlabLayers`-Logik (`toSection.ts:633`) füllen. Das ist der aufwendigste
 Einzelposten dieses Dokuments (siehe Prioritätsliste), aber ohne ihn bleibt
 "Dach im Schnitt" eine reine Lücke.
 **UI**: Ein `RoofType`-Eintrag im `ResourceManager`
 (`src/ui/ResourceManager.tsx`), identisch zum bestehenden Ceiling-Typ-Editor
 (Schicht-Liste, Dicke, Bauteil-Zuweisung) — kein neues UI-Paradigma.
 ### 4.4 Dach 1:1 — Formen, Kehlen, Gauben (konkreter Vorschlag)
 Reihenfolge nach Aufwand/Nutzen, NICHT alles auf einmal:
 1. **Traufe/Ortgang trennen**: `overhang` → `{ eaves: number; gable: number
   }`. Kleine, lokale Änderung in `roof.ts` (zwei statt einer Offset-Variable
   je nach Kantentyp), grosser optischer Gewinn (das ist die häufigste
   Rückmeldung "sieht nicht echt aus" bei Steildächern mit gleich langem
   Überstand allseitig).
 2. **Mansard-Untertyp** (`mansardVariant: "walm"|"giebel"|"zelt"`, wie in der
   älteren Planung `elements.md:298` bereits vorgesehen, aber nie gebaut):
   steuert nur, wie die STIRNSEITE der Mansarde behandelt wird (heute IMMER
   `gables` = vertikale Giebelfläche, `roof.ts:200-203`) — bei "walm" wird
   daraus eine geneigte Fläche wie beim Walmdach. Mittlerer Aufwand, da die
   Mansard-Berechnung (`roof.ts:176-206`) bereits alle Eckpunkte hat, nur die
   Gable-Erzeugung muss konditional werden.
 3. **Editierbarer Mansard-Knickpunkt** (`kinkDepthRatio?: number` statt hart
   `0.4`, `roof.ts:181`) — 0.5 PT, reine Parametrisierung einer bestehenden
   Konstante.
 4. **Krüppelwalm** (`hipTruncation?: number`, 0 = voller Walm, 1 = voller
   Giebel/Sattel): der First bleibt voll lang, nur ein kleines Walmstück am
   First-Ende — technisch eine Variation der bestehenden `walm`-Berechnung
   (`roof.ts:147-174`, der First-Verkürzungs-Faktor `halfD` wird
   parametrisiert statt fix).
 5. **Dachflächenfenster** (kein neues Bauteil — ein `Opening`-ähnliches
   Element, das in eine Dachfläche statt eine Wand einschneidet): neuer
   `hostRoofId`-Pfad, eigenständiger Vorschlag; lohnt sich erst NACH der
   Schichtlogik, weil das Fenster sonst nicht "in die Dämmebene" passt.
 6. **Gauben** (Schlepp-/Sattelgaube als eigenständiges Sekundär-`Roof` mit
   eigenem `outline`/`baseElevation`, das in die Hauptdachfläche einschneidet):
   grösster Einzelposten, weil er eine echte Boolean-Verschneidung zwischen
   zwei Dachkörpern braucht (ähnlich der bestehenden Wand-Boolean-Dominanz
   über `joinPriority`, aber räumlich in 3D). Realistisch erst nach einem
   Mesh-Boolean-Werkzeug (die begonnene truck-Integration,
   `src-tauri/trucksolid/`, ist ein Kandidat dafür).
 7. **L-/T-Grundriss mit Kehle (Straight-Skeleton)**: bewusst NICHT vor 6,
   weil es die Bounding-Box-Vereinfachung komplett ersetzt (neue
   Geometrie-Engine, kein inkrementeller Ausbau von `roof.ts`) — separates,
   grosses Vorhaben, siehe Prioritätsliste.
 ### 4.5 Lücken (Dach)
 | Feature | Status | Priorität | Aufwand |
 |---|---|---|---|
 | `RoofType`/`Layer[]`-Schichtaufbau (Modell) | ✗ (`thickness` toter Skalar) | **P0** | 3 PT |
 | 3D-Schichten (gestapelte Flächen entlang Normalen) | ✗ | **P0** | 3 PT |
 | 2D-Aufsicht-Poché (Eindeckungssymbol) | ✗ | P1 | 1.5 PT |
 | Dach im Vertikalschnitt (Ebene-Ebene-Schnitt + Bänder) | ✗ | **P0** | 5 PT |
 | Traufe/Ortgang getrennter Überstand | ✗ | **P0** | 1 PT |
 | Mansard-Untertyp (Walm/Giebel/Zelt-Stirn) | ✗ | P1 | 2 PT |
 | Editierbarer Mansard-Knick | ✗ | P2 | 0.5 PT |
 | Krüppelwalm | ✗ | P2 | 1.5 PT |
 | Dachflächenfenster | ✗ | P2 | 4 PT |
 | Gauben (Boolean-Einschnitt) | ✗ | P3 | 8+ PT |
 | L-/T-Grundriss, Straight-Skeleton-Kehle | ✗ | P3 | 10+ PT |
 | `RoofType`-Ressourcen-UI | ✗ | P1 (folgt aus RoofType) | 1 PT |
 | IFC `IfcRoof`-Export | ✗ | P2 | 1.5 PT |
 ---
 ## 5. Decke (Ceiling / Slab)
 ### 5.1 Was ein vollständiges BIM-Tool bietet
 | Bereich | Typische Parameter |
 |---|---|
 | Grundfläche | beliebiges Polygon inkl. Aussparungen (Treppenauge, Schacht, Kamindurchbruch) |
 | Schichtaufbau | Rohdecke, Trittschalldämmung, Estrich, Bodenbelag — analog Wand, mit Deckenspiegel/Untersicht (abgehängte Decke, Akustikplatten) als eigene Schicht(en) |
 | Randausbildung | gerader Rand, auskragender Balkon-/Vordachrand mit thermischer Trennung (Isokorb/Randdämmstreifen), Randschalung/Abschalungsprofil, Attika-Anschluss, Tropfkante |
 | Deckenspiegel | abgehängte Untersicht mit eigener Höhe/Raster (Akustik-/Gipskarton-Decke), UNABHÄNGIG von der tragenden Rohdecke |
 | Öffnungen | Deckenaussparungen als eigene, editierbare Polygone (nicht nur Gesamtumriss) |
 | Neigung | geneigte Decke (Garagenrampe, Terrasse mit Gefälle) — nicht nur horizontal |
 | 2D-Darstellung | Aufsicht mit Ansichts-Poché (unaufgeschnitten), Schnitt mit Vollschichten je Lage, Deckenspiegel-Plan (reflected ceiling plan) als eigene Zeichnungsart |
 | IFC-Rolle | `IfcSlab` (PredefinedType FLOOR/ROOF/BASESLAB), `IfcMaterialLayerSetUsage` für den Schichtaufbau, `IfcCovering` für abgehängte Decken |
 ### 5.2 IST in DOSSIER
 `Ceiling` (`types.ts:928-1000`) hat bereits die stärkste Tiefe der vier
 Bauteile in diesem Dokument: geschlossenes Umriss-Polygon (`outline`),
 `ceilingTypeId` mit Legacy-Fallback auf `wallTypeId` (`getCeilingType`,
 `types.ts:2089`), volle Attribut-Override-Kette (`foreground`/`background`/
 `strokeWeight`/`hatchId` + `*Source`, wie bei `Wall`) und unabhängige
 vertikale Bindung von OK/UK über `VerticalAnchor` (`top?`/`bottom?`,
 `types.ts:990-999` — "floor"-gebunden oder "custom"-Z, exakt wie bei
 `Wall.top`/`Wall.bottom`, `types.ts:887-893`). 3D-Schichtstapel ist
 implementiert (`emitSlabs`, `toWalls3d.ts:1352-1419`), Schnitt-Schichtsplit
 ebenfalls (`splitSlabLayers`, `toSection.ts:633`).
 Verifizierte Lücken:
 - **Keine Aussparungen.** `Ceiling.outline: Vec2[]` ist EIN geschlossenes
  Polygon (`types.ts:936-939`) — kein `openings?: Vec2[][]` für
  Treppenauge/Schacht/Kamin. Ein Treppenloch in der Decke muss heute über
  die Aussenkontur der Decke "herumgeschnitten" werden (Decke als
  komplexes, nicht-konvexes Polygon), nicht als saubere Innenaussparung.
  (`elements.md:217` sah dieses Feld in der älteren Planung explizit vor,
  es wurde nie in `types.ts` übernommen.)
 - **Kein Randdetail.** Die Decke ist über die gesamte `outline` exakt
  `thickness` dick, EINHEITLICH. Es gibt kein Feld für eine abweichende
  Randausbildung (Aufkantung, Randdämmstreifen, Tropfkante, andere Dicke am
  Balkonrand). Ein auskragender Balkon lässt sich zwar über eine erweiterte
  `outline` modellieren, bekommt aber zwangsläufig denselben Vollschicht-
  Aufbau wie die Innendecke — eine thermisch getrennte Balkonplatte
  (Isokorb) ist nicht abbildbar.
 - **Kein Deckenspiegel.** Abgehängte Untersicht (Akustik-/GKB-Decke mit
  eigener, tieferer Kote) existiert nicht als eigenes Konzept — nur der
  tragende Aufbau über `ceilingTypeId`.
  Ein "Deckenspiegel-Plan" (reflected ceiling plan) fehlt als Zeichnungsart
  komplett (`DrawingLevelKind`, `types.ts:722`, kennt nur "floor"/"section"/
  "elevation"/"drawing").
  (Randbemerkung: Beleuchtungsplanung/Deckenspiegel ist ein Elektro-Thema und
  damit bewusst ausserhalb des DOSSIER-Kernscopes — siehe "nicht bauen",
  Abschnitt 6. Die reine Geometrie einer zweiten, tiefer liegenden Fläche
  bleibt aber ein legitimer BIM-1:1-Punkt.)
 - **Keine Neigung.** `top`/`bottom` sind je EIN `VerticalAnchor` (ein
  Z-Wert), keine Neigungsebene — eine geneigte Garagen-/Terrassendecke ist
  nicht modellierbar, nur über mehrere ebene Teildecken behelfsweise
  annäherbar.
 - **2D-Aufsicht nutzt nur die erste Schicht.** `addCeilingPoche`
  (`generatePlan.ts:2453-2536`) liest `wt.layers[0]` (Kommentar/Code
  `generatePlan.ts:2465`) für die Ansichts-Schraffur — bei einer
  mehrschichtigen Decke (z. B. Beton unten, Dämmung oben) zeigt die Aufsicht
  immer nur die OBERSTE (erste) Schicht, was für eine unaufgeschnittene
  Draufsicht baupraktisch korrekt ist (man sieht von unten die
  Untersicht/erste Lage), aber nicht konfigurierbar ist, welche Lage als
  "sichtbare" gilt, falls der Deckenaufbau umgekehrt sortiert wäre.
 - IFC: `IfcSlab` wird erzeugt (`exportIfc.ts:28`), aber laut Kopfkommentar
  (`exportIfc.ts:38-41`) bewusst OHNE `IfcMaterialLayerSet`/-`Usage` — der
  Export verliert den Schichtaufbau, den DOSSIER intern bereits hat.
 ### 5.3 Deckenrand/Randterminierung — vertieft
 Der Nutzer nennt explizit "Deckenränder, Stirnabschlüsse, Anschluss an Wand/
 Aussenkante, auskragende Ränder, Randabschalung" als Schwerpunkt. IST-Bild:
 keines davon existiert als eigenes Konzept — die Decke ist ein reines
 Extrusions-Polygon. Konkreter Vorschlag, dreistufig nach Aufwand:
 1. **Aussparungen** (`Ceiling.openings?: Vec2[][]`) — niedrigster Aufwand,
   grösster praktischer Nutzen (Treppenauge ist im Wohnbau der Regelfall,
   nicht die Ausnahme). 2D: zusätzliche Ausschnitts-Polygone in
   `addCeilingPoche` (Loch im Fill, zusätzliche Randlinien). 3D: `emitSlabs`
   bekommt Löcher im Extrusions-Profil (analog dem bereits vorhandenen
   Loch-Schnitt bei Wand-Öffnungen, `wallMeshCut.ts`, als Vorlage).
 2. **Randschicht-Override** (`Ceiling.edgeOverride?: { ringOffset: number;
   ceilingTypeId: string }` — ein schmaler Innenring der Decke entlang des
   Randes bekommt einen ANDEREN Layer-Aufbau, z. B. mit zusätzlicher
   Randdämmschicht oder reduzierter Dicke für eine Tropfkante). Technisch:
   `emitSlabs` erzeugt für den Ringbereich einen zweiten Layer-Stapel mit dem
   Override-Typ, geometrisch als Offset-Polygon-Differenz (`outline` minus
   `outline.offset(-ringOffset)`), eine Operation, die für Wandbänder
   bereits ähnlich existiert (`buildWallFootprints`).
 3. **Thermisch getrennte Auskragung (Isokorb-Fall)**: ein eigenes,
   sekundäres `Ceiling`-Objekt für den auskragenden Teil mit eigenem
   `ceilingTypeId` (dünnerer/anderer Aufbau) UND eigener `top`/`bottom`-
   Bindung, das an die Hauptdecke stösst — kein neues Feld nötig, nur eine
   UI-Erleichterung ("Deckenrand abtrennen"-Werkzeug, das die Decke entlang
   einer gewählten Kante in zwei `Ceiling`-Objekte teilt). Niedrigster
   Modell-Aufwand, weil er das bestehende Mehrfach-Decken-Prinzip nutzt statt
   ein neues Konzept einzuführen.
 ### 5.4 Lücken (Decke)
 | Feature | Status | Priorität | Aufwand |
 |---|---|---|---|
 | Aussparungen (`openings?: Vec2[][]`) in 2D+3D | ✗ | **P0** | 3 PT |
 | Randschicht-Override (Ringzone anderer Aufbau) | ✗ | P1 | 3 PT |
 | Deckentrenn-Werkzeug für Isokorb-Fall (UI, kein neues Modellfeld) | ✗ | P1 | 1.5 PT |
 | Geneigte Decke (Rampe/Gefälle) | ✗ | P2 | 3 PT |
 | Deckenspiegel (zweite, abgehängte Fläche) | ✗ | P3 | 2 PT (reine Geometrie) |
 | IFC `IfcMaterialLayerSetUsage` für Decke (UND Wand) | ~ (bewusst ausgelassen) | P2 | 2 PT |
 | Konfigurierbare "oberste Schicht" für Aufsicht-Poché | ✓ implizit (Layer-Reihenfolge = Sortierung) | — | — |
 ---
 ## 6. Konsolidierte Priorisierung (über alle vier Bauteile)
 Sortiert nach "1:1-Zuwachs pro Aufwand", nicht nach Aufwand allein:
 1. **Dach-Schichtaufbau (Modell + 3D-Stapel)** — schliesst die grösste
   strukturelle Lücke (totes `thickness`-Feld, kein `RoofType`) und liefert
   sofort sichtbaren Tiefengewinn im 3D (§4.3, ~6 PT gesamt).
 2. **Traufe/Ortgang getrennter Überstand** — 1 PT, sofortiger optischer
   Sprung bei jedem Steildach-Projekt (§4.4 Punkt 1).
 3. **Zweiflügelige Tür rendert wirklich 2 Blätter** — das `leafCount`-Feld
   existiert seit der Türtyp-Einführung, wird aber komplett ignoriert; sehr
   sichtbarer Bug-artiger Gap (§2.3, 2 PT).
 4. **Deckenaussparungen** — Treppenauge ist der Wohnbau-Regelfall, heute nur
   über Umweg (nicht-konvexes Aussenpolygon) lösbar (§5.3 Punkt 1, 3 PT).
 5. **Fenster-Glazing 2D-wirksam** — seit über einem Jahr als P0 in der
   Fenster-Studie dokumentiert und weiterhin offen; niedriger Aufwand,
   sollte nicht liegen bleiben (§3.1, 1 PT).
 6. **Dach im Vertikalschnitt** — grösster Einzelposten (5 PT), aber ohne ihn
   bleibt jeder Gebäudeschnitt mit Steildach unvollständig; das ist die
   Art Lücke, die bei einer Bemusterung/Baueingabe sofort auffällt.
 7. **Deckenrand-Override / Isokorb-Trennwerkzeug** — folgt danach, weil er
   auf demselben Mehrfach-Decken-Prinzip aufbaut wie Punkt 4.
 8. **Mansard-Untertyp + editierbarer Knick** — mittlere Priorität, weil
   Mansarde in der Schweiz/Süddeutschland baupraktisch häufig ist und die
   heutige starre 40 %-Konstante sichtbar unrealistisch wirkt.
 9. **Tür/Fenster-Rahmentiefe** (asymmetrische Rahmenbreiten, Beschlag,
   Kopfform) — bewusst NACH den strukturellen Lücken, weil sie additive
   Detailverbesserungen an einem bereits funktionierenden Pfad sind, während
   1–7 fehlende oder falsch dargestellte Kernfunktionen betreffen.
 10. **Gauben, L-Grundriss/Kehle, Dachflächenfenster** — grösste Einzel-
    Aufwände (8–10+ PT), architektonisch am voraussetzungsreichsten (Boolean-
    Werkzeug bzw. neue Geometrie-Engine); erst nach 1–9 angehen.
 ### 6.1 NICHT bauen (VW/Revit-Ballast ohne Nutzen für DOSSIER)
 - **Vollständiger Massketten-/Bezugsapparat** (VW B1..B5/H1..H7,
  Roh-/Fertigmass-Umschaltung) — DOSSIER arbeitet mit lichten Massen, das
  genügt für ein Schweizer Wohnbau-/Kleinprojekt-Tool (bereits so in
  `window-editor-vectorworks-study.md` §5 entschieden, hier bestätigt für
  Dach/Decke: keine Dach-Rohmass-/Fertigmass-Unterscheidung).
 - **Sichtbarkeitsmatrix 3D-Objekte × Ansichten** (Augen-Tabelle je
  Kategorie×Ansicht×Detailstufe) — DOSSIERs Layer-Sichtbarkeit +
  `DetailLevel` deckt den praktischen Bedarf; eine volle Matrix ist
  Verwaltungsaufwand ohne Mehrwert für Einzelprojekte.
 - **Eckfenster/Eckdach als generischer Sonderfall über zwei Wirtsbauteile**
  — seltene Geometrie, hoher Modellierungsaufwand (zwei Hosts, ein Element);
  bei Bedarf als manueller Workaround (zwei separate Öffnungen) lösbar.
  Ebenso: freie Neigungsflächen je Dachkante (VW erlaubt jede Kante einzeln
  zu kippen) — für die abgedeckten Standardformen (Pult/Sattel/Walm/
  Mansarde/Zelt/Krüppelwalm) nicht nötig; wer eine Freiform-Dachlandschaft
  braucht, ist besser mit den `ExtrudedSolid`/truck-Werkzeugen bedient.
 - **Vollständige Beschlags-/Baubeschlag-Bibliothek** (Marken-Beschlagsätze,
  Schliessplan) — Beschlag als generisches Griff-Mesh (§2.4) genügt für die
  visuelle 1:1-Wirkung; eine Beschlags-PRODUKTBIBLIOTHEK ist Kataloggeschäft,
  kein CAD-Kernfeature.
 - **Deckenspiegel als vollwertige Beleuchtungsplanung** (Leuchtenraster,
  Lichtberechnung) — reine Geometrie einer zweiten Fläche ist ok (P3), die
  Elektro-/Lichtplanungslogik selbst liegt ausserhalb des Tool-Zwecks.
 - **IFC `IfcOpeningElement`/Void-Semantik nachrüsten** — bewusste
  Design-Entscheidung im bestehenden Export (`exportIfc.ts:22-27`), NICHT
  revidieren: die heutige "Loch steckt im Mesh"-Lösung liefert visuelle
  Parität in jedem Viewer ohne Boolean-Pflicht beim Empfänger; der reine
  IFC4-Purismus (Wand als parametrische Extrusion + Void) würde
  bestehende, bewusst getroffene Trade-offs zunichtemachen.
 - **Straight-Skeleton/Kehlen und Gauben SOFORT** — nicht "nicht bauen", aber
  bewusst zurückgestellt (§6, Punkt 10): ohne die Schichtlogik (Punkt 1)
  vorher zu bauen, würde jede Kehlen-/Gauben-Lösung auf dem unendlich dünnen,
  ungeschichteten Dach aufsetzen und müsste bei Einführung der Schichten
  ohnehin neu gefasst werden.
@@ -1,10 +1,8 @@
 # DOSSIER-Feature-Audit (A1–A6, B1–B4, C1–C3, D1–D3, E)
 Ausführliche Fassung des Audits, auf das HANDOVER.md Backlog-Punkt 9 nur noch mit
-Einzeilern verweist. Ursprünglich von einem Opus-Subagent erarbeitet, der das
+Einzeilern verweist. Abgleich DOSSIER-Rhino-Referenzrepo (`/tmp/dossier-ref`) gegen
-DOSSIER-Rhino-Referenzrepo (`/tmp/dossier-ref`) gegen den aktuellen Browser-Port
+den aktuellen Browser-Port. Belege (Datei:Zeile) beziehen sich auf `/tmp/dossier-ref/rhino/*.py`.
 abgeglichen hat — das Ergebnis lag bisher nur in einem Session-Transkript, nicht
 im Repo. Belege (Datei:Zeile) beziehen sich auf `/tmp/dossier-ref/rhino/*.py`.
 Status-Symbole: ❌ nicht übernommen · 🟡 teilweise übernommen.
@@ -0,0 +1,74 @@
 # Ribbon-UI + modulare Bars — Plan
 Nutzer-Vision (2026-07-05, mit OCS/AutoCAD-Ribbon als Referenz). Ziel: klare,
 einheitliche Werkzeug-/Eigenschaften-Darstellung; Werkzeug-Sidebar entfällt.
 ## Zielbild
 - **Ribbon-Oberleiste mit Tabs: 2D · 3D · BIM · Ansichten.** Jeder Tab zeigt
  gruppierte Werkzeug-/Aktions-Icons (wie OCS Draw/Model/Insert/Annotate/View).
  - **2D**: Zeichnen (Select/Linie/Polylinie/Rechteck/Kreis/Bogen/Text) · Ändern
    (Move/Copy/Mirror/Offset/Trim/Join/Boolean).
  - **3D**: Volumen/Boolean (vorhandene 3D-Aktionen), Kamera-Presets.
  - **BIM**: Wand/Fenster/Tür/Treppe/Decke/Raum (die Bauteile).
  - **Ansichten**: Geschoss/Schnitt/Ansicht-Wechsel, Zoom/Einpassen, Render-Modi.
 - **Werkzeug-Sidebar entfällt** → rechtes Panel (Attribute) bekommt volle Höhe.
 - **Objektinfo unter die Attribute** mergen (Wandstil-Definition etc. zusammen).
 - **XYZ-Referenzpunkt-Box oben rechts bleibt** (vom Nutzer ausdrücklich gewünscht).
 - **Eigenschaften-Grid im OCS-Stil** — ✅ bereits erledigt (`00733d8`): Sektion-
  Balken, Zeilentrenner, füllende linksbündige Wertfelder (`.attr-*`).
 ## Architektur — DATENGETRIEBEN (ermöglicht modulare Custom-Bar)
 Kern: EINE Registry beschreibt alle Ribbon-Elemente; Ribbon-Tabs UND eine
 benutzerdefinierte Custom-Bar sind bloß zwei Ansichten über dieselbe Registry.
 ```
 RibbonItem =
  | { kind: "tool"; id: ToolId }                 // aktiviert ein Werkzeug (onSelectTool)
  | { kind: "command"; name: string }            // startet einen Engine-Befehl (engine.start)
  | { kind: "action"; id: string; run: () => void } // freie App-Aktion (Zoom, Render-Modus …)
 RibbonGroup = { titleKey: string; items: RibbonItem[] }
 RibbonTab   = { id: "2d"|"3d"|"bim"|"views"; labelKey: string; groups: RibbonGroup[] }
 RIBBON: RibbonTab[]
 ```
 - Icons: `ToolIcon` (vorhanden) für `tool`-Items; für `command`/`action` eine
  kleine Icon-Map (SVG) analog `ToolsPanel`.
 - Aktivierung: `tool` → `onSelectTool(id)` · `command` → `engine.start(name)` ·
  `action` → `run()`. Aktiv-Highlight über `activeTool` bzw. laufenden Befehl.
 - **Custom-Bar (modular)**: der Nutzer wählt beliebige `RibbonItem`s in eine
  persistierte Liste (`viewSlice`/Projekt); eine `CustomBar`-Komponente rendert
  genau diese. Gleiche Item-Typen, gleiche Aktivierung — kein Sonderweg.
 ## Phasen
 1. ✅ **Gerüst + 2D/BIM-Tab** (`9d6e86d`). `RibbonBar` unter der TopBar (additiv).
   Datengetriebene Registry (`src/ui/ribbon/ribbonItems.ts`), 2D-Tab (Zeichnen +
   Ändern) und BIM-Tab (Bauteile) gefüllt, Tab-State lokal, Modify-Icons ergänzt.
 2. ✅ **TopBar → „Ansichten"-Tab gemergt** (`85011cb`, Nutzer-Entscheid „voll
   mergen"). Die Ansichts-/Zoom-/Darstellungs-Cluster der TopBar (View-Grid +
   Kamera, Ebenen-/Zeichnungs-Kombis, Detailgrad, Massstab/Zoom, Darstellungsart)
   sind als `ViewRibbonTab` (in `TopBar.tsx`) in den „Ansichten"-Tab gewandert;
   App reicht sie als `viewsContent`-Node an `RibbonBar` (wie das Layout-Menü).
   Die **Tab-Reiter sitzen in der TopBar-Zeile** (`RibbonTabs`, in TopBar
   gerendert; Tab-State in App), der Ribbon-Inhalt (`RibbonBar`) folgt darunter →
   nur ZWEI Bänder. Die TopBar ist eine **schmale Leiste** (Höhe 40px): Marke/
   Ressourcen · Tabs · Datei/Export/Einstellungen · Fensterknöpfe. Die Text-/
   Font-Formatierung (`TextGroup`) liegt im eigenen **„Text"-Tab** (Reihenfolge
   2D·3D·BIM·Text·Ansichten; `RibbonBar.tabContent` trägt „text" + „views").
   - **Offen (visuell iterieren):** ob Zoom/Massstab zusätzlich als Dauer-Anzeige
     (Statusleiste) sichtbar sein soll; Default-Tab (aktuell 2D); 3D-Tab noch
     leer (Kamera-Presets/3D-Aktionen füllen).
 3. **Sidebar raus** (ToolsPanel aus Default-Layout) + rechtes Panel volle Höhe;
   Objektinfo unter Attribute mergen.
 4. **Modulare Custom-Bar**: Item-Picker + persistierte Custom-Bar-Ansicht.
 ## Hinweise / Randbedingungen
 - Additiv bauen: bestehende Kommandozeile + Nummern-Shortcuts + `ToolsPanel`
  bleiben funktionsfähig, bis Phase 3 die Sidebar bewusst entfernt.
 - Werkzeug-Kopplung Tool↔Befehl existiert bereits (`TOOL_COMMAND`) — Ribbon nutzt
  denselben `onSelectTool`/`engine.start`-Pfad (EIN Pfad, keine Duplikate).
 - Empfehlung: Phase 1+ in fokussierter Session mit visueller Iteration im Tauri.
@@ -146,6 +146,6 @@ Neue Keys in de.ts UND en.ts: `text.style`, `text.font`, `text.size`,
 ## 7. Gate (Pflicht)
 `rm -f tsconfig.tsbuildinfo && npx tsc -b` grün, `npm run build` grün, keine
-AI-Spuren (grep auf Claude/Anthropic/AI/Generated/Co-Authored), Boot-Probe
+Trace-Scan (grep auf Co-Authored/Generated), Boot-Probe
 (`node scripts/probe.mjs`) ohne Konsolenfehler, Screenshot der Oberleiste.
 KEIN Commit.
@@ -0,0 +1,403 @@
 # truck-Integration — Profil-Extrusion (B-Rep → 3D-Mesh)
 > Übergabe-Dokument für die Implementierung. Lies zuerst CONVENTIONS.md.
 ## Ziel
 Nutzer zeichnen im Grundriss ein geschlossenes Polygon (z. B. L-Profil einer Stütze)
 und können es als 3D-Körper auf eine Höhe extrudieren. Das Ergebnis erscheint sofort
 im 3D-Viewport neben Wänden und Decken.
 **MVP-Scope (dieser Auftrag):**
 - Neue Rust/WASM-Crate `trucksolid` mit zwei Funktionen: `extrude_polygon` + `extrude_circle`
 - Neue TS-Wrapper-Datei `src/engine/truckSolid.ts` (WASM laden + typisierte API)
 - KEIN neues Werkzeug, KEIN UI — nur die Geometrie-Schicht. UI kommt in einem
  separaten Folgeauftrag.
 ---
 ## Architektur-Kontext
 ```
 src-tauri/
  render3d/          ← bestehend: wgpu-Renderer (wasm-pack → pkg3d/)
  kernel2d/          ← bestehend: 2D-Geometrie-Kern
  trucksolid/        ← NEU (dieser Auftrag)
    Cargo.toml
    src/
      lib.rs
 src/engine/
  pkg3d/             ← render3d WASM-Output
  pkgTruck/          ← NEU: trucksolid WASM-Output (wasm-pack Ziel)
  truckSolid.ts      ← NEU: TS-Wrapper
 src/plan/
  toWalls3d.ts       ← bestehend: baut RenderScene; emitMeshes() muss erweitert werden
 ```
 Das Koordinatensystem in DOSSIER ist **Modell-Meter: X = rechts, Y = oben (Grundriss),
 Z = Höhe**. render3d erwartet `positions` im gleichen System — `mesh.rs` macht intern
 `(x, y, z) → (x, z, y)` für wgpu (Y-up world). Truck arbeitet in 3D; wir bauen
 das Polygon in der XY-Ebene (z=0) und extrudieren nach +Z.
 ---
 ## 1 — Rust-Crate `src-tauri/trucksolid/`
 ### 1.1 Cargo.toml
 Exakt dasselbe Muster wie `src-tauri/kernel2d/Cargo.toml`:
 ```toml
 [workspace]   # entkoppelt vom cad-tauri-Workspace (Pflicht)
 [package]
 name = "trucksolid"
 version = "0.1.0"
 edition = "2021"
 description = "Profil-Extrusion via truck (B-Rep → tesselliertes Mesh für render3d)"
 [lib]
 crate-type = ["cdylib", "rlib"]
 [features]
 default = []
 web = [
    "dep:wasm-bindgen",
    "dep:serde_json",
    "dep:console_error_panic_hook",
 ]
 [dependencies]
 serde = { version = "1", features = ["derive"] }
 serde_json = { version = "1", optional = true }
 wasm-bindgen = { version = "0.2", optional = true }
 console_error_panic_hook = { version = "0.1", optional = true }
 # truck: nur die stabilen Crates (KEIN truck-modeling — Booleans instabil)
 truck-geometry  = "0.3"
 truck-topology  = "0.3"
 truck-rendimesh = "0.3"
 [dev-dependencies]
 serde_json = "1"
 ```
 **Wichtig:** `truck-modeling` (die Crate mit Boolean-Operatoren) wird NICHT eingebunden.
 Nur `truck-geometry`, `truck-topology` und `truck-rendimesh` — die sind stabil.
 ### 1.2 src/lib.rs — Kern-Logik
 #### Eingabe/Ausgabe-Typen
 ```rust
 use serde::{Deserialize, Serialize};
 /// Input: flaches Array [x0,y0, x1,y1, ...] in Modell-Metern (Grundriss-XY).
 /// Muss ≥ 3 Punkte enthalten; Wiederholung des ersten Punkts am Ende optional.
 /// Reihenfolge CCW oder CW — truck normalisiert selbst.
 #[derive(Deserialize)]
 pub struct ExtrudePolyInput {
    pub points: Vec<f64>,  // flat: [x0,y0, x1,y1, ...]
    pub height: f64,       // Extrusionshöhe in Metern (> 0)
 }
 /// Output: trianguliertes Mesh, kompatibel mit render3d::types::MeshInput.
 /// positions: flat [x0,y0,z0, x1,y1,z1, ...] in Modell-Metern
 /// indices:   Dreiecks-Indizes (je 3 = 1 Dreieck), 0-basiert
 #[derive(Serialize)]
 pub struct MeshOutput {
    pub positions: Vec<f32>,
    pub indices:   Vec<u32>,
 }
 ```
 #### Polygon-Extrusion (truck-API)
 ```rust
 use truck_geometry::prelude::*;
 use truck_topology::*;
 pub fn extrude_polygon_core(pts: &[(f64, f64)], height: f64) -> Result<MeshOutput, String> {
    if pts.len() < 3 { return Err("min 3 Punkte".into()); }
    if height <= 0.0  { return Err("height muss > 0 sein".into()); }
    // 1. Punkte in der XY-Ebene (z=0) als truck-Vertices
    let verts: Vec<Vertex<Point3>> = pts.iter()
        .map(|(x, y)| Vertex::new(Point3::new(*x, *y, 0.0)))
        .collect();
    // 2. Kanten: je zwei aufeinanderfolgende Vertices verbinden, Ring schliessen
    let edges: Vec<Edge<_, Line<Point3>>> = verts.windows(2)
        .chain(std::iter::once([verts.last().unwrap(), &verts[0]].as_slice()))
        .map(|w| {
            let p0 = *w[0].point();
            let p1 = *w[1].point();
            Edge::new(&w[0], &w[1], Line(p0, p1))
        })
        .collect();
    // 3. Wire (geschlossener Kantenzug)
    let wire = Wire::from_iter(edges);
    // 4. Planare Face aus dem Wire
    //    truck-topology::Face::new braucht die äussere Boundary + optional Holes
    let face = Face::new(vec![wire]);
    // 5. Lineare Extrusion: tsweep entlang +Z um `height`
    let solid = face.tsweep(&Vector3::new(0.0, 0.0, height));
    // 6. Tessellieren (chord-tolerance in Metern — 0.005 = 5 mm)
    use truck_rendimesh::MeshedShape;
    let mesh = solid.triangulation(0.005).to_polygon();
    // 7. positions + indices extrahieren
    let positions: Vec<f32> = mesh.positions().iter()
        .flat_map(|p| [p.x as f32, p.y as f32, p.z as f32])
        .collect();
    let indices: Vec<u32> = mesh.tri_faces().iter()
        .flat_map(|tri| tri.iter().map(|idx| idx.pos as u32))
        .collect();
    Ok(MeshOutput { positions, indices })
 }
 ```
 > **Achtung:** Die exakte truck-API (Methoden-Namen, Trait-Imports, tsweep-Signatur)
 > kann je nach veröffentlichter Version leicht abweichen. Prüfe die Docs von
 > `truck-topology 0.3` und `truck-rendimesh 0.3` auf docs.rs. Die Struktur oben
 > ist das Ziel-Pattern — passe Methoden-Signaturen an, wenn der Compiler es verlangt.
 > Ändere NICHT die Eingabe/Ausgabe-JSON-Struktur.
 #### Kreis-Extrusion (Zylinder)
 ```rust
 pub fn extrude_circle_core(cx: f64, cy: f64, r: f64, height: f64) -> Result<MeshOutput, String> {
    // Kreis in XY-Ebene tessellieren (N Segmente je nach r),
    // dann wie extrude_polygon_core aufrufen.
    // Alternativ: truck-geometry::Ellipse/Circle direkt nutzen, falls vorhanden.
    let n = (2.0 * std::f64::consts::PI * r / 0.02).ceil().max(16.0) as usize;
    let pts: Vec<(f64, f64)> = (0..n)
        .map(|i| {
            let a = 2.0 * std::f64::consts::PI * i as f64 / n as f64;
            (cx + r * a.cos(), cy + r * a.sin())
        })
        .collect();
    extrude_polygon_core(&pts, height)
 }
 ```
 #### WASM-Bindings (Feature "web")
 ```rust
 #[cfg(feature = "web")]
 mod web {
    use super::*;
    use wasm_bindgen::prelude::*;
    #[wasm_bindgen(start)]
    pub fn init() {
        console_error_panic_hook::set_once();
    }
    /// Extrudiert ein Polygon-Profil.
    /// `input_json`: `{ "points": [x0,y0,…], "height": 2.5 }`
    /// Rückgabe: `{ "positions": […], "indices": […] }` oder throws JsError.
    #[wasm_bindgen]
    pub fn extrude_polygon(input_json: &str) -> Result<String, JsError> {
        let input: ExtrudePolyInput = serde_json::from_str(input_json)
            .map_err(|e| JsError::new(&e.to_string()))?;
        let pts: Vec<(f64, f64)> = input.points.chunks(2)
            .map(|c| (c[0], c[1]))
            .collect();
        let mesh = extrude_polygon_core(&pts, input.height)
            .map_err(|e| JsError::new(&e))?;
        serde_json::to_string(&mesh).map_err(|e| JsError::new(&e.to_string()))
    }
    /// Extrudiert einen Kreis-Querschnitt (Zylinder).
    /// `input_json`: `{ "cx": 0, "cy": 0, "r": 0.15, "height": 3.0 }`
    #[wasm_bindgen]
    pub fn extrude_circle(input_json: &str) -> Result<String, JsError> {
        #[derive(serde::Deserialize)]
        struct In { cx: f64, cy: f64, r: f64, height: f64 }
        let i: In = serde_json::from_str(input_json)
            .map_err(|e| JsError::new(&e.to_string()))?;
        let mesh = extrude_circle_core(i.cx, i.cy, i.r, i.height)
            .map_err(|e| JsError::new(&e))?;
        serde_json::to_string(&mesh).map_err(|e| JsError::new(&e.to_string()))
    }
 }
 ```
 ### 1.3 Tests (headless, ohne Feature "web")
 Mindestens diese drei Tests müssen mit `cargo test` grün sein:
 ```rust
 #[cfg(test)]
 mod tests {
    use super::*;
    #[test]
    fn quad_extrusion_vertex_count() {
        // 1m × 1m Quadrat, 2m hoch → 8 Eckpunkte minimum (6 Flächen × 2 Dreiecke)
        let pts = vec![(0.0,0.0),(1.0,0.0),(1.0,1.0),(0.0,1.0)];
        let m = extrude_polygon_core(&pts, 2.0).unwrap();
        assert!(m.positions.len() >= 8 * 3);       // ≥ 8 Vertices × 3 floats
        assert_eq!(m.indices.len() % 3, 0);         // vollständige Dreiecke
        assert!(m.indices.len() >= 12 * 3);         // ≥ 12 Dreiecke (Quader)
    }
    #[test]
    fn l_profile_extrusion() {
        // L-Profil: 6 Punkte
        let pts = vec![
            (0.0,0.0),(0.3,0.0),(0.3,0.1),(0.1,0.1),(0.1,0.3),(0.0,0.3),
        ];
        let m = extrude_polygon_core(&pts, 3.0).unwrap();
        assert_eq!(m.indices.len() % 3, 0);
        assert!(m.positions.len() > 0);
    }
    #[test]
    fn cylinder_extrusion() {
        let m = extrude_circle_core(0.0, 0.0, 0.15, 3.0).unwrap();
        assert_eq!(m.indices.len() % 3, 0);
        assert!(m.positions.len() > 0);
    }
    #[test]
    fn rejects_too_few_points() {
        assert!(extrude_polygon_core(&[(0.0,0.0),(1.0,0.0)], 1.0).is_err());
    }
    #[test]
    fn rejects_zero_height() {
        let pts = vec![(0.0,0.0),(1.0,0.0),(0.5,1.0)];
        assert!(extrude_polygon_core(&pts, 0.0).is_err());
    }
 }
 ```
 ---
 ## 2 — Build-Script (package.json)
 Füge in `package.json` unter `"scripts"` hinzu:
 ```json
 "build:truck": "wasm-pack build src-tauri/trucksolid --release --target web --out-dir ../../src/engine/pkgTruck --out-name trucksolid --no-default-features --features web"
 ```
 Und in `src-tauri/Cargo.toml` unter `exclude`:
 ```toml
 exclude = ["render2d", "render3d", "geometry", "kernel2d", "dwgimport", "trucksolid"]
 ```
 ---
 ## 3 — TS-Wrapper `src/engine/truckSolid.ts`
 Gleiche Lade-Pattern wie `src/plan/useWasmPlanRenderer.ts` (render2d) und
 `src/viewport/useWasm3dRenderer.ts` (render3d):
 ```typescript
 // Lazy-Singleton: WASM einmalig laden, dann gecacht.
 let modulePromise: Promise<typeof import("../../engine/pkgTruck/trucksolid")> | null = null;
 async function getModule() {
  if (!modulePromise) {
    modulePromise = import("../../engine/pkgTruck/trucksolid").then(async (m) => {
      await m.default(); // WASM-Binary initialisieren
      return m;
    });
  }
  return modulePromise;
 }
 export interface ExtrudedMesh {
  positions: number[];
  indices: number[];
 }
 /** Extrudiert ein geschlossenes Polygon-Profil (Modell-Meter XY) um `height` m. */
 export async function extrudePolygon(
  points: number[],  // flat [x0,y0, x1,y1, ...]
  height: number,
 ): Promise<ExtrudedMesh> {
  const m = await getModule();
  const json = m.extrude_polygon(JSON.stringify({ points, height }));
  return JSON.parse(json) as ExtrudedMesh;
 }
 /** Extrudiert einen Kreis-Querschnitt (Zylinder). */
 export async function extrudeCircle(
  cx: number, cy: number, r: number, height: number,
 ): Promise<ExtrudedMesh> {
  const m = await getModule();
  const json = m.extrude_circle(JSON.stringify({ cx, cy, r, height }));
  return JSON.parse(json) as ExtrudedMesh;
 }
 ```
 ---
 ## 4 — Integration in toWalls3d.ts (Vorbereitung)
 In `src/plan/toWalls3d.ts` ist `RMeshKind` bereits definiert:
 ```typescript
 export type RMeshKind = "terrain" | "imported";
 ```
 Erweitere auf `"extrusion"` (damit der Renderer später eine eigene Farbe/Darstellung
 wählen kann, auch wenn heute noch kein Unterschied besteht):
 ```typescript
 export type RMeshKind = "terrain" | "imported" | "extrusion";
 ```
 Die `emitMeshes()`-Funktion liest bereits `project.drawings2d` und ähnliche Arrays.
 Für extrudierte Körper wird es später ein `project.extrudedSolids`-Array geben
 (oder ähnlich — das ist Teil des UI-Folgeauftrags). Die `emitMeshes()`-Erweiterung
 kommt dann.
 ---
 ## 5 — Verifikations-Checkliste
 Bevor du als fertig meldest, müssen alle Punkte grün sein:
 - [ ] `cd src-tauri/trucksolid && cargo test` → alle 5 Tests grün, keine Warnings
 - [ ] `npm run build:truck` → `src/engine/pkgTruck/trucksolid.js` + `.wasm` erzeugt
 - [ ] `npx tsc --noEmit` (aus Root) → 0 Fehler
 - [ ] `npx vitest run` → alle bestehenden Tests weiterhin grün (keine Regression)
 - [ ] `src-tauri/Cargo.toml` hat `"trucksolid"` im `exclude`-Array
 - [ ] `package.json` hat `"build:truck"` im `"scripts"`-Block
 ---
 ## 6 — Was NICHT in diesem Auftrag
 - Kein neues UI/Werkzeug (kommt später)
 - Kein `truck-modeling` (Boolean-Operationen — instabil upstream)
 - Kein STEP-Export (kommt in Folgeauftrag wenn Basisschicht steht)
 - Kein Eintrag in `project.extrudedSolids` oder Store (UI-Auftrag)
 - Keine Änderungen an render3d, generatePlan, App.tsx
 ---
 ## 7 — Koordinatensystem-Reminder
 | DOSSIER-Modell | truck (im Code) | render3d (wgpu) |
 |---|---|---|
 | X = rechts | X = rechts | X = rechts |
 | Y = oben (Grundriss) | Y = oben (Grundriss) | Z = oben (Y-up swapped) |
 | Z = Höhe | Z = Höhe | Y = Höhe |
 `mesh.rs` in render3d macht bereits `(model.x, model.y, model.z) → (x, z, y)` beim
 Hochladen. Du musst also in truck DOSSIER-Koordinaten verwenden (XY-Ebene = Grundriss,
 Z = Höhe) — das ist konsistent mit der bestehenden `MeshInput.positions`-Konvention.
@@ -1,13 +1,12 @@
 # Briefing — Nativer wgpu-2D-Renderer (parallele Instanz)
-> Für die Instanz/den Agenten, der den nativen GPU-Renderer baut. Isoliert vom
+> Für den Entwickler, der den nativen GPU-Renderer baut. Isoliert vom
 > Web-Renderer; koordiniert über dieses Dokument.
 ## COMMIT-REGEL (verbindlich)
-Dieses Repo darf **keinerlei Hinweise auf KI-Werkzeuge** enthalten — nicht im Code,
+Dieses Repo darf **keinerlei Fremd-Tool-Hinweise** enthalten — nicht im Code,
-in Kommentaren oder in der Git-Historie. Keine `Co-Authored-By`-Trailer, keine
+in Kommentaren oder in der Git-Historie. Kommentare deutsch, Identifier englisch.
-„Generated with"-Zeilen, keine Modell-/Agenten-Namen. Kommentare deutsch,
+**Kein Commit ohne Absprache.**
 Identifier englisch. **Kein Commit ohne Ansage der Hauptinstanz.**
 ## Warum
 Der 2D-Plan wird aktuell in einem WebGL-Canvas gerendert (Web-Stack). In Chromium
@@ -72,9 +71,9 @@ per Matrix-Uniform macht. Fenster-Integration in Tauri ist der zweite, separate
 - **Eigener Branch** (z. B. `feature/wgpu-renderer`), NICHT auf `master`/
  `feature/parametric-walls` committen. Isolierter Worktree.
 - **Nur** `src-tauri/` + neue Rust-Module + `docs/`. **NICHT** `src/App.tsx`,
-  `src/plan/*`, `types.ts` anfassen (die Hauptinstanz arbeitet dort an Features).
+  `src/plan/*`, `types.ts` anfassen (dort laufen parallel Features).
 - Der Web-WebGL-Renderer bleibt bestehen (Browser-Lauffähigkeit + Referenz).
- Ergebnisse/Diffs zurückliefern; die Hauptinstanz committet und pflegt das Memory.
+- Ergebnisse/Diffs zurückliefern; Projektleitung committet.
 ## Gates
 `cargo check`/`cargo test`/`cargo build` grün. Trace-Scan sauber (COMMIT-REGEL).
@@ -6,9 +6,7 @@
 > Port-Plan) und M1 (entkoppelter Standalone-Spike). Noch NICHT die Migration.
 ## Commit-/Spuren-Regel
-Wie im ganzen Repo: keine Hinweise auf KI-Werkzeuge — nicht im Code, in Kommentaren
+Wie im ganzen Repo: keine Fremd-Tool-Hinweise im Code, in Kommentaren oder der Historie. Kommentare deutsch, Identifier englisch. Kein Commit ohne Absprache.
 oder in der Historie. Kommentare deutsch, Identifier englisch. Kein Commit ohne
 Ansage der Hauptinstanz.
 ## Warum
 Der 3D-View laeuft heute als three.js/WebGL im Tauri-Webview (WebKitGTK). Wie beim
@@ -0,0 +1,449 @@
 # Fenster-/Tür-Editor — Studie & Designdokument (Referenz: Vectorworks „Fenster bearbeiten")
 Status: Studie/Entwurf (KEIN Code). Ziel: den heute als „mega mager" empfundenen
 Fenster-/Tür-Editor zu einem eigenständigen, reichen **Einstellungs-Dialog** mit
 Kategorie-Sidebar, Live-Vorschau (2D + 3D) und **„Als Stil speichern"** ausbauen.
 Diese Datei ordnet die Vectorworks-Referenz dem bestehenden DOSSIER-Modell zu und
 schlägt einen realistischen, phasierten Plan vor.
 Konvention: Bezeichner englisch, UI-Text/Kommentare deutsch. Meter als Grundmaß.
 ---
 ## 1. Executive Summary
 **Was ein guter DOSSIER-Fenster-/Tür-Editor sein sollte.** Ein eigener modaler
 Dialog „Fenster-/Tür-Einstellungen" — nicht die heutige, in den Ressourcen-Manager
 eingebettete Formularspalte (`WindowStylesTab`/`DoorStylesTab` in
 `src/ui/ResourceManager.tsx`), die pro Feld nur eine `FieldRow` zeigt und keinerlei
 Vorschau bietet. Der neue Dialog hat drei Zonen (wie Vectorworks):
 1. **Kategorie-Sidebar** links (Basis, Größe/Position, Rahmen, Flügel/Sprossen,
   Oberlicht/Unterlicht, Laibung/Bank, Sonnenschutz/Rollladen, Attribute/Darstellung,
   Detaillierung).
 2. **Parameter-Panel** in der Mitte (die Controls der gewählten Kategorie).
 3. **Live-Vorschau** rechts: eine 2D-Plan-Vorschau (aus `generatePlan()`) und eine
   3D-Ansicht/Elevation (aus `projectToModel3d()`), beide sofort aktualisiert.
 **Die eine wichtigste strukturelle Änderung.** Der Editier-Primärort wandert vom
 Ressourcen-Tab in einen **dedizierten `OpeningEditorDialog`**, der TYP-Parameter
 (wiederverwendbarer Stil = `WindowType`/`DoorType`) und INSTANZ-Parameter (dieses
 `Opening`) im selben Fenster editiert und oben eine Stil-Leiste trägt:
 `Stil: [Dropdown]` · `Fenster speichern…` (aktuelle Konfiguration als neuen
 benannten `WindowType`/`DoorType` ablegen) · `Einstellungen zurücksetzen…`
 (auf den Stil zurückfallen). Das ⚙ in `ObjectInfoPanel.OpeningSection`
 (`src/panels/ObjectInfoPanel.tsx:731`) öffnet künftig DIESEN Dialog statt den
 Ressourcen-Manager-Tab.
 **Begriffsklärung.** Der Nutzer-Ausdruck „als **Wandstil** speichern" ist ein
 Versprecher — gemeint ist „als **Fensterstil/Türstil** (Bauteilstil) speichern",
 also ein neuer Eintrag in `project.windowTypes` bzw. `project.doorTypes`, analog
 `WallType`/`CeilingType`/`StairType`. Es entsteht KEIN neuer Wandtyp.
 **Warum das der Hebel ist.** Alle geplante Tiefe (mehrflügelig, Sprossenraster,
 Rollladen, Bank/Nische, Ober-/Unterlicht, Verglasungsanzahl) braucht (a) mehr
 Felder auf `WindowType`/`DoorType` und (b) eine UI, die sie ohne Formularwust
 zeigt und deren Wirkung sofort sichtbar macht. Ohne Live-Vorschau bleibt ein
 reicher Parametersatz unbenutzbar. Erst der Dialog macht die Tiefe zugänglich; die
 Modellfelder allein (Abschnitt 4) reichen nicht.
 ---
 ## 2. Vollständige Mapping-Tabelle (VW-Referenz → DOSSIER)
 Legende — Status: **✓** vorhanden · **~** teilweise (Feld existiert, Renderer liest
 es nicht ODER nur grob) · **✗** fehlt. Ebene: **T** = Typ (Stil, wiederverwendbar,
 auf `WindowType`/`DoorType`) · **I** = Instanz (auf `Opening`). Priorität P0
 (erste reiche Scheibe) … P3 (VW-Ballast). Aufwand grob in Personentagen (PT).
 Wichtiger Ist-Befund aus dem Code (Renderer-Konsum-Lücken):
 - `WindowType.glazing` (einfach/zweifach/dreifach) ist editierbar, wird aber von
  KEINEM Renderer gelesen. 3D zeichnet stets EINE Scheibe (`glassPanesForOpening`
  in `src/plan/toWalls3d.ts:1965` ignoriert `glazing`); 2D leitet die Glaslinien-
  Anzahl allein aus `DetailLevel` ab (`addOpeningSymbol` in
  `src/plan/generatePlan.ts:2214`, `glassCount = detail==="fein" ? 2 : 1`).
 - `WindowType.kind`/`DoorType.kind` (dreh/kipp/drehkipp/fest/schiebe …) schlagen
  sich NICHT in 2D/3D-Geometrie nieder.
 - `DoorType.leafCount` (1/2), `leafStyle`/`glazingRatio` (außer `leafStyle==="glas"`
  → 3D-Verglasung an) sind ungenutzt.
 - `WindowType.sillBoard` ungenutzt; `DoorType.threshold` → `hasSill` genutzt.
 - 3D-Mittelpfosten/Kämpfer und Sprossen werden nur bei `detail==="fein"` emittiert
  (`frameMeshesForOpening` in `src/plan/toWalls3d.ts:1902`, ab :1938).
 ### 2.1 Basiseinstellungen
 | VW-Control | Status | DOSSIER-Feld (Vorschlag) | 2D-Wirkung | 3D-Wirkung | Ebene | Prio | Aufwand |
 |---|---|---|---|---|---|---|---|
 | Fensterart („Für normale Wand") | ✗ | `WindowType.wallKind?: "normal"\|"eck"` (später) | — | — | T | P3 | 0.5 |
 | Öffnungsart (Dreh/Kipp/…) | ~ | `WindowType.kind` existiert, kein Render | Öffnungssymbol/Öffnungslinien | Öffnungslinien 3D | T | P1 | 2 |
 | Einfügepunkt längs (Mitte/…) | ✓ | `Opening.position` + Bezugspunkt in `ObjectInfoPanel` | Position im Plan | Position | I | — | — |
 | Einfügepunkt quer (Fensterseite außen/…) | ~ | `insetFromFace`/`insetFace` (T) | Band-Lage | Rahmen-Normalenlage (`resolveFrameNormalRange` :1803) | T | P1 | 0.5 |
 | Versatz im Fassadenmodul | ✗ | — (Fassadensystem fehlt in DOSSIER) | — | — | — | P3 | — |
 | Laibung (wählen) | ~ | `insetFromFace` deckt Teil ab | Laibungsstriche (fein) | Laibungstiefe | T | P2 | 1 |
 | Klasse | ~ | `Opening.categoryCode` (LayerCategory) | Farbe/Strich | — | I | — | — |
 | Darstellung höchste Detaillierung | ✓ | `Opening.detailLevel` + Ansichts-DetailLevel | Symbolstufe | Meshstufe | I | — | — |
 | Eigenes Symbol verwenden | ✗ | `WindowType.symbolId?` (Drawing2D-Ref) | Symbol-Override | — | T | P3 | 3 |
 ### 2.2 Fenstergröße & Bemaßung
 | VW-Control | Status | DOSSIER-Feld | 2D | 3D | Ebene | Prio | Aufwand |
 |---|---|---|---|---|---|---|---|
 | Fensterbreite (Wert) | ✓ | `Opening.width` (+ `defaultWidth` T) | ✓ | ✓ | I/T | — | — |
 | Fensterhöhe (Wert) | ✓ | `Opening.height` (+ `defaultHeight` T) | ✓ | ✓ | I/T | — | — |
 | Bezug B1..B5 / H1..H7 (Roh-/Fertigmaß) | ✗ | `WindowType.dimRef?: {...}` | Bemaßungsschema | — | T | P3 | 3+ |
 | „Bemaßung automatisch" (außen/innen) | ✗ | — (DOSSIER hat noch keine parametrische Öffnungs-Bemaßung) | Maßketten | — | T | P3 | 5+ |
 Der ganze VW-Maßketten-/Bezugsapparat (B1..B5, H1..H7, Roh-/Fertigmaß-Umschaltung)
 ist **P3/„nicht bauen"** — siehe Abschnitt 5. DOSSIER trägt lichte Maße
 (`width`/`height`), das genügt.
 ### 2.3 Höhe Brüstung/Sturz
 | VW-Control | Status | DOSSIER-Feld | 2D | 3D | Ebene | Prio | Aufwand |
 |---|---|---|---|---|---|---|---|
 | Position definieren durch (Brüstungshöhe/…) | ✓ | `Opening.sillHeight` (+ `defaultSillHeight` T) | — | vertikale Lage (`openingVerticalExtent`) | I | — | — |
 | Abstand Brüstungshöhe (Wert) | ✓ | `Opening.sillHeight` | — | ✓ | I | — | — |
 | „bezieht sich auf" (Wandaußenseite/…) | ✗ | — (immer Wand-UK-relativ) | — | — | — | P3 | — |
 | „auf Ebenenbasishöhe" | ~ | Wand-UK ergibt sich aus Geschoss (`baseElevation`) | — | ✓ | — | — | — |
 ### 2.4 Rahmenwerte
 | VW-Control | Status | DOSSIER-Feld | 2D | 3D | Ebene | Prio | Aufwand |
 |---|---|---|---|---|---|---|---|
 | Rahmenbreiten (4 Kanten, asymmetrisch) | ~ | heute nur `frameWidth` (eine Zahl) → `WindowType.frameWidths?: {left,right,top,bottom}` | Rahmenkontur (`windowSymbol`/`addOpeningFrameBand`) | Rahmen-Boxen (`frameMeshesForOpening`) | T | P2 | 2 |
 | Symmetrisch-Toggle | ✗ | `WindowType.frameSymmetric?: boolean` | — | — | T | P2 | 0.5 |
 | Flügel mittig / Versatz | ✗ | `WindowType.sashOffset?: number` | Aufschlag-Linie | Flügel-Box-Lage | T | P2 | 1 |
 | Rahmenstärke quer zur Wand | ✓ | `frameThickness` / `frameDepth` (→ `resolveAcrossWallDepth` :1780) | — | Rahmentiefe | T | — | — |
 | Schnitt-/Außenansicht-Rahmenbreiten | ~ | von `frameWidth` mitgezeichnet | Bandbreite | — | T | P2 | 1 |
 ### 2.5 Flügeleinteilung (KERN-Tiefe — höchster Wert)
 | VW-Control | Status | DOSSIER-Feld | 2D | 3D | Ebene | Prio | Aufwand |
 |---|---|---|---|---|---|---|---|
 | Flügeltabelle (Nr/Typ/Breite/Anschlag/…) | ~ | `wingCount` (Zahl) → **neu** `WindowType.sashes: SashDef[]` (siehe §4) | Pfostenlinien (`mullionLines`) heute nur gleichmäßig | Pfosten-Boxen nur gleichmäßig | T | **P0** | 4 |
 | Typ Flügel \| Pfosten | ✗ | `SashDef.kind: "fluegel"\|"pfosten"` | Pfostenlage frei | Pfosten frei | T | P0 | (inkl.) |
 | Aut. Breite / Flügelbreite | ~ | `SashDef.autoWidth`/`width` (heute nur gleichmäßig) | Teilungslage | Teilungslage | T | P1 | 1 |
 | Pfostenbreite / „alle gleich" | ~ | `SashDef.postWidth`, `WindowType.uniformPosts` | Pfostendicke | Pfostenbox-Breite | T | P1 | 1 |
 | Anschlag (Drehbar links/Drehkipp rechts) | ✗ | `SashDef.opening: OpeningKind`, `SashDef.hingeSide: "left"\|"right"` | Öffnungslinien/Pfeil je Flügel | Öffnungslinien 3D | T | **P0** | 2 |
 | Aufschlag (Abstand zu Rahmen) | ✗ | `SashDef.rebate?: number` | Aufschlag-Linie | — | T | P2 | 0.5 |
 | Winkel / 3D-Öffnung | ✗ | `SashDef.openAngle?: number` | — | Flügel gekippt/offen | T | P2 | 1.5 |
 | Griffart | ✗ | `SashDef.handle?: HandleKind` | — | Griff-Mesh (§2.7) | T | P2 | 1 |
 | Kämpfer-Zeilen (horizontale Teilung) | ~ | `mullionRows` existiert | Querlinien | Kämpfer-Boxen (fein) | T | P1 | — |
 Dies ist die **wertvollste Lücke**: VW modelliert je Flügel Typ, Breite,
 Öffnungsrichtung, Anschlag, Griff. DOSSIER hat nur eine gleichmäßige `wingCount`.
 Die `SashDef[]`-Tabelle (§4, Phase P0/P1) ist der zentrale Ausbau.
 ### 2.6 Laibungsverkleidung · Form · Ober-/Unterlicht · Nische/Bank
 | VW-Control | Status | DOSSIER-Feld | 2D | 3D | Ebene | Prio | Aufwand |
 |---|---|---|---|---|---|---|---|
 | Laibungsverkleidung erstellen | ✗ | `WindowType.reveal?: {create, depth, thickness}` | Laibungsband | Laibungs-Boxen | T | P2 | 1.5 |
 | Form (Eckig/Schräg/Spitz/Rund) | ✗ | `WindowType.headShape?: HeadShape` + Eckmaße | Öffnungsumriss-Form | Bogen-/Schräg-Mesh | T | P2 | 4 |
 | Oberlicht erstellen + Höhe/Rahmen/Sprossen | ~ | `transomHeight` existiert (feste Scheibe) → `WindowType.transom?: {height, frame, grid}` | Kämpferlinie + Feld | zweite Scheibe (`glassPanesForOpening` :1988) | T | P1 | 2 |
 | Unterlicht (unteres festes Feld) | ✗ | `WindowType.underlight?: {height, frame, grid}` | Feld | Scheibe unten | T | P2 | 1.5 |
 | Sprossen (horiz./vert. im Feld) | ~ | `mullionRows` grob → `WindowType.muntins?: {rows, cols}` je Feld | Sprossengitter | Sprossen-Boxen (fein) | T | P1 | 2 |
 | Nische aussparen (außen/innen) | ✗ | `WindowType.niche?: {aussen, innen, ...}` | Nischenkontur | Nischen-Aussparung | T | P2 | 2 |
 | Fensterbank erstellen (außen/innen) | ~ | `sillBoard` existiert, ungenutzt → `WindowType.sill?: {aussen, innen, typ, masse}` | Bankkontur | Bank-Box | T | P1 | 2 |
 | Banktyp/Winkel/ΔZ/Endverkröpfung | ✗ | Unterfelder von `sill` | Detail | Detail-Mesh | T | P3 | 2 |
 ### 2.7 Sonnenschutz · Beschlag · Geländer · Heizkörper · Eckfenster
 | VW-Control | Status | DOSSIER-Feld | 2D | 3D | Ebene | Prio | Aufwand |
 |---|---|---|---|---|---|---|---|
 | Sonnenschutz/Rollladen erstellen + Typ | ✗ | `WindowType.shading?: {create, kind: "raffstore"\|"rollladen"\|…, box, projection}` | Kasten-/Kastenlinien im Grundriss | Kastenbox + Auskragung | T | **P0/P1** | 2.5 |
 | Rollladenkasten-Maße | ✗ | `shading.box: {w,h,d}` | Rechteck | Box-Mesh | T | P0 | (inkl.) |
 | „Nische erzeugen"/„Kasten symm."/Lamellenwinkel | ✗ | `shading`-Unterfelder | — | Detail | T | P2 | 1 |
 | Beschlag (Griff/Knauf) Geometrie/Maße | ✗ | `SashDef.handle` + `WindowType.handleGeom?` | — | Griff-/Knauf-Mesh | T | P2 | 2 |
 | Geländer (Position/Höhe/Bauteile) | ✗ | `WindowType.railing?: {...}` | Geländerlinien | Geländer-Mesh | T | P3 | 3 |
 | Heizkörper | ✗ | — (eigenes Bauteil, nicht Fenster) | — | — | — | P3 | — |
 | Eckfenster | ✗ | eigener Sonderfall (zwei Wände) | — | — | T | P3 | 5+ |
 ### 2.8 Attribute · Schnitte/Ansichten · Detaillierung · IFC/Energos
 | VW-Control | Status | DOSSIER-Feld | 2D | 3D | Ebene | Prio | Aufwand |
 |---|---|---|---|---|---|---|---|
 | Attribut-Tabelle je Bestandteil (Klasse/Material/Stift/Linie/…) | ~ | DOSSIER hat By-Layer/By-Object-Attribute (`foreground`/`background`/`hatchId`/`strokeWeight` an Wand/Decke, NICHT an `Opening`) → `Opening.foreground?` etc. + evtl. je Bestandteil | Farbe/Strich der Bestandteile | Material | I/T | P2 | 3 |
 | „Klassenattribute zuweisen/entfernen" | ~ | `AttributeSource` („layer"/„object") existiert für Wand/Decke | — | — | I | P2 | 1 |
 | Automatische 2D-Darstellungen (Horizontal/Ansicht/Querschnitt) | ~ | `generatePlan` erzeugt Grundriss; Schnitt/Ansicht sind Platzhalter (`DrawingLevelKind`) | — | — | — | P3 | — |
 | Sichtbarkeitsmatrix 3D-Objekte × Ansichten (Oben/Unten/…/Querschnitt) | ✗ | **nicht bauen** | — | — | — | P3 | — |
 | Detaillierung: Option × Kategorie × Detailstufe (Augen-Tabelle) | ~ | `DetailLevel` (grob/mittel/fein) fließt in 2D + 3D | Sichtbarkeit je Stufe | Meshstufe | I | P2 | 2 |
 | „Für 3D die Tiefe/Mittlere/Hohe Detaillierung verwenden" | ✓ | `Model3dOptions.detail` (`toWalls3d.ts:2145`) | — | Meshstufe | — | — | — |
 | Beschriftung | ✗ | eigenes Text/Tag-System | Label | — | — | P3 | — |
 | Infos/IFC-Daten/Infopalette/Energos | ✗ | **nicht bauen** | — | — | — | P3 | — |
 | „Mehrere ändern" | ~ | Multi-Selektion patcht bereits gemeinsame Felder | — | — | I | P2 | 1 |
 ---
 ## 3. Der dedizierte Dialog
 ### 3.1 Komponente & Einbettung
 Neue Komponente **`src/ui/OpeningEditorDialog.tsx`** (Muster: die bestehenden
 `*Dialog.tsx` in `src/ui/`, z. B. `SettingsDialog.tsx`, `TextEditorDialog.tsx`,
 und das Overlay-Muster `res-overlay` + `role="dialog"` aus
 `ResourceManager.tsx:371`). Props (über `usePanelHost`/App-State geliefert):
 ```
 open: boolean
 openingId: string            // die editierte Instanz
 kind: "window" | "door"      // steuert Sidebar-Sätze + welche Type-Liste
 project: Project             // read (Typ-Listen, Bauteile, LayerCategories)
 onPatchOpening(patch)        // Instanz-Felder
 onPatchType(typeId, patch)   // Typ-Felder (aktueller Stil)
 onSaveAsStyle(name, snapshot)// „Fenster/Tür speichern…" → neuer WindowType/DoorType
 onResetToStyle()             // „zurücksetzen…"
 onClose()
 ```
 **Öffnen aus dem ⚙.** `ObjectInfoPanel.OpeningSection`
 (`src/panels/ObjectInfoPanel.tsx:731`, `onClick → host.onEditOpeningType(...)`)
 ruft künftig einen neuen Host-Handler `host.onOpenOpeningEditor(openingId)` statt
 `setResourcesTab(...) + setResourcesOpen(true)` (heutige Verdrahtung in
 `src/App.tsx:3130`). App hält `openingEditorId: string | null` als State und
 rendert `<OpeningEditorDialog open={openingEditorId!=null} .../>`. Der bisherige
 Ressourcen-Tab bleibt als Bibliotheks-/Massenpflege bestehen, ist aber nicht mehr
 der Primärort — das ⚙ landet direkt im reichen Dialog.
 ### 3.2 Kategorie-Sidebar (realistischer Teilmenge)
 Reihenfolge und Sichtbarkeit je `kind`:
 1. **Basis** — Öffnungsart (`kind`), Einfügepunkt quer (`insetFace`/`insetFromFace`),
   Klasse (`categoryCode`), Detaillierung (`detailLevel`).
 2. **Größe/Position** — `width`, `height`, `sillHeight`, `position` (I),
   `defaultWidth/Height/SillHeight` (T).
 3. **Rahmen** — `frameThickness`, `frameDepth`, `frameWidth`/`frameWidths`,
   `frameKind` (Tür), `sashOffset`.
 4. **Flügel/Sprossen** — die `SashDef[]`-Tabelle (Flügel/Pfosten einfügen,
   Öffnungsrichtung/Anschlag je Flügel), Kämpfer-Zeilen, Sprossengitter.
 5. **Oberlicht/Unterlicht** — `transom`, `underlight` (je Feld: Höhe, Rahmen, Gitter).
 6. **Laibung/Bank** — `reveal`, `sill` (außen/innen), `niche`.
 7. **Sonnenschutz/Rollladen** — `shading` (Typ, Kastenmaße, Auskragung).
 8. **Attribute/Darstellung** — Bestandteil-Attribute (Farbe/Strich/Material).
 9. **Detaillierung** — welche Bestandteile bei grob/mittel/fein sichtbar sind.
 Sidebar-Sätze: bei `kind==="door"` entfallen Oberlicht/Unterlicht-Gitter-Details,
 Sonnenschutz und Bank; dafür Türblatt (`leafCount`, `leafStyle`, `threshold`,
 `swing`/`hinge`/`openingDir`/`swingAngle`).
 ### 3.3 Live-Vorschau
 **2D (der billige, sofort machbare Teil).** DOSSIER hat den kompletten
 Plan→SVG-Pfad bereits: `generatePlan()` (`src/plan/generatePlan.ts:632`) →
 `toRenderScene.ts` (RScene) → `sceneToPrintSvg()` (`src/export/sceneToPrintSvg.ts:109`)
 bzw. `planToPrintSvg()` (`src/export/planToPrintSvg.ts:155`). Für die Vorschau ein
 **Mini-Projekt** bauen (eine kurze Wand + das editierte `Opening` mit den aktuellen
 Dialog-Werten), durch `generatePlan()` schicken und als SVG in ein Vorschau-`<div>`
 rendern — Grundriss oben, optional eine Elevations-Skizze. Reagiert auf jeden
 Patch reaktiv (React-State → neu generieren; günstig, da nur ein Element).
 **3D/Elevation.** Zwei Optionen, in aufsteigendem Aufwand:
 - **(A) günstig, empfohlen für den ersten Wurf:** eine reine 2D-**Ansicht/Elevation**
  aus denselben Plan-Primitiven — VW's „Vorschau, schattiert" ist für uns nicht
  nötig; eine saubere Frontalansicht (Rahmen/Flügel/Sprossen/Glas als SVG) zeigt
  die Flügeleinteilung am aussagekräftigsten und nutzt exakt die neuen Felder.
 - **(B) echte 3D-Vorschau:** `projectToModel3d()` (`src/plan/toWalls3d.ts:2149`)
  auf das Mini-Projekt anwenden und im wgpu-Viewport (`Wasm3DViewport.tsx`)
  darstellen. Teurer (eigener Render-Kontext im Modal, WASM-Instanz) und laut
  Projekt-Memo NICHT per Browser/Puppeteer verifizierbar — der Nutzer testet 3D
  selbst in der Tauri-Dev-App. Deshalb 3D-Vorschau erst NACH der 2D-Vorschau, als
  eigene Phase.
 Empfehlung: erste Scheibe nur **2D-Grundriss + 2D-Elevation**; echte wgpu-Vorschau
 später.
 ### 3.4 „Als Stil speichern"-Flow
 Drei Aktionen in der Stil-Leiste:
 - **Fenster/Tür speichern… (`onSaveAsStyle`)** — nimmt einen Schnappschuss der
  aktuellen (Typ-relevanten) Dialogwerte, fragt einen Namen ab (`PromptDialog.tsx`)
  und legt einen NEUEN `WindowType`/`DoorType` in `project.windowTypes`/`doorTypes`
  an (CRUD-Factories existieren: `addWindowType`/`addDoorType` in `src/App.tsx`
  ab :2273/:2304). Das editierte `Opening.typeId` zeigt danach auf den neuen Stil.
 - **Update dieses Stils** — `patchWindowType`/`patchDoorType` (App :2319/:2287) auf
  den aktuell referenzierten `typeId` anwenden (wirkt auf alle Instanzen des Stils).
 - **Einstellungen zurücksetzen… (`onResetToStyle`)** — die instanzseitigen
  Overrides verwerfen und wieder die Typ-Defaults ziehen (Instanz-Felder auf
  `undefined` setzen, sodass die Resolver `getWindowType`/`getDoorType`
  (`src/model/types.ts:2060`/:2064) greifen).
 TYP-vs-INSTANZ-Regel im Dialog sichtbar machen: Typ-Felder tragen eine dezente
 „Stil"-Markierung; ein instanzseitig übersteuertes Feld zeigt einen „abweichend
 vom Stil"-Indikator + „zurücksetzen". Das ist genau VW's Stil-/Override-Logik.
 ---
 ## 4. Modell-Erweiterungsplan (phasiert)
 Alle Felder additiv/optional (Alt-Projekte laden unverändert — die bestehende
 Konvention der Datei, vgl. `wingCount?`, `sliceTermination` Default). Neue Felder
 auf `WindowType`/`DoorType` in `src/model/types.ts`.
 ### P0 — die erste reiche Scheibe (Kern-Tiefe)
 ```ts
 // Ein Flügel- oder Pfosten-Eintrag der Flügeleinteilung.
 type OpeningKind = "dreh" | "kipp" | "drehkipp" | "fest" | "schiebe";
 interface SashDef {
  kind: "fluegel" | "pfosten";
  autoWidth?: boolean;      // gleichmäßig aufteilen (Default true)
  width?: number;           // feste Flügelbreite (m), wenn !autoWidth
  postWidth?: number;       // Pfostenbreite (m), nur kind="pfosten"
  opening?: OpeningKind;    // Öffnungsart DIESES Flügels
  hingeSide?: "left" | "right"; // Anschlag
 }
 interface WindowType {
  // … bestehend …
  sashes?: SashDef[];       // ersetzt/erweitert wingCount; fehlt ⇒ aus wingCount abgeleitet
  shading?: {               // Rollladen/Sonnenschutz-Kasten (P0-Minimalfassung)
    create: boolean;
    kind: "rollladen" | "raffstore" | "markise";
    box: { width: number; height: number; depth: number };
  };
  glazingPanes?: 1 | 2 | 3; // Verglasung endlich RENDER-wirksam (heute: glazing unbenutzt)
 }
 ```
 Rationale/Render-Freischaltung:
 - `sashes` — schaltet echte, ungleichmäßige Flügel/Pfosten + Öffnungsrichtung je
  Flügel frei; treibt neue Pfostenlinien in `windowSymbol`/`mullionLines`
  (`src/geometry/opening.ts`) und Pfosten-Boxen in `frameMeshesForOpening`
  (`src/plan/toWalls3d.ts:1938`). Höchster sichtbarer Mehrwert.
 - `shading` — der Rollladenkasten ist ein einzelnes Kästchen: eine 2D-Rechteckkontur
  über der Öffnung (neuer Zeichenzweig in `addOpeningSymbol`) + eine Box in
  `emitOpeningFrames`/eigener Emitter. Wenig Code, große „Reichhaltigkeit".
 - `glazingPanes` — `glassPanesForOpening` (:1965) liest die Scheibenzahl statt
  konstant EINE Scheibe zu zeichnen; 2D-Glaslinien-Anzahl analog. Schließt die
  auffälligste Konsum-Lücke.
 ### P1 — Tiefe der Flügel/Felder
 ```ts
 interface SashDef { /* + */ rebate?: number; openAngle?: number; handle?: "drueck"|"knauf"|"none"; }
 interface WindowType {
  frameWidths?: { left: number; right: number; top: number; bottom: number };
  frameSymmetric?: boolean;
  uniformPosts?: boolean;
  transom?: { height: number; frame?: number; muntins?: { rows: number; cols: number } };
  sill?: { aussen?: SillDef; innen?: SillDef };
  muntins?: { rows: number; cols: number }; // Sprossen im Hauptfeld
 }
 ```
 Rationale: asymmetrische Rahmenbreiten, richtiges Oberlicht (statt nur feste Scheibe
 via `transomHeight`), Fensterbank (heute `sillBoard` ungenutzt), Sprossengitter.
 Alles hängt an vorhandenen Zeichen-/Mesh-Funktionen; nur Parameterausbau.
 ### P2 — Detailbestandteile
 ```ts
 interface WindowType {
  reveal?: { create: boolean; depth: number; thickness: number };   // Laibungsverkleidung
  underlight?: { height: number; frame?: number };                  // Unterlicht
  niche?: { aussen?: boolean; innen?: boolean; depth: number };     // Nische
  headShape?: "eckig" | "schraeg_links" | "schraeg_rechts" | "spitz" | "rund";
  handleGeom?: { kind: "quader" | "rund"; masse: Record<string, number> };
 }
 interface Opening { foreground?: string; background?: string; strokeWeight?: number; } // Bestandteil-Attribute
 ```
 Rationale: Form (Rundbogen/Schräge → neue Öffnungsumriss-Geometrie), Laibung/Nische,
 Beschlag-Geometrie, per-Instanz-Attribute (analog Wand/Decke, die es schon haben).
 ### P3 — VW-Ballast (nur wenn je nachgefragt)
 Bemaßungs-Bezugsschemata (B1..B5/H1..H7), Sichtbarkeitsmatrix 3D×Ansichten,
 IFC/Energos, Geländer, Heizkörper, Eckfenster, eigenes Symbol, Fassadenmodul-Versatz.
 Siehe Abschnitt 5.
 **Höchster-Wert-Reihenfolge (verdichtet):** (1) `sashes` inkl. Öffnungsrichtung je
 Flügel, (2) mehrscheibige Verglasung, (3) Rollladenkasten, (4) Bank/Nische,
 (5) Sprossengitter, (6) Form (Rund/Spitz/Schräg), (7) Ober-/Unterlicht als eigene
 Felder.
 ---
 ## 5. Was NICHT bauen / Risiken
 **Nicht bauen (VW-Komplexität ohne DOSSIER-Nutzen):**
 - **Sichtbarkeitsmatrix „3D-Objekte × 9 Ansichten"** (Oben/Unten/Horizontalschnitt/
  Vorne/Hinten/Frontalschnitt/Links/Rechts/Querschnitt). DOSSIER rendert heute
  primär Grundriss; Schnitt/Ansicht sind `DrawingLevelKind`-Platzhalter. Eine
  Matrix mit ~13×9 An/Aus-Zellen ist Pflegehölle ohne Zielrenderer. `DetailLevel`
  (grob/mittel/fein) genügt als Sichtbarkeitsachse.
 - **Bemaßungs-Bezugssystem (Roh-/Fertigmaß, B1..B5/H1..H7).** DOSSIER trägt lichte
  Maße; eine parametrische Öffnungs-Maßkette existiert nicht. Sehr teuer, geringer
  Nutzen für ein CAAD-Werkzeug dieser Reife.
 - **IFC-Datenmapping-Tiefe, Energos, Infopalette.** Kein IFC-Export-Pfad vorhanden;
  bewusst weglassen (kein Schein-Feature, vgl. die Modell-Doku-Konvention).
 - **Heizkörper, Geländer, Eckfenster** als Fenster-Unterobjekte — das sind eigene
  Bauteile bzw. topologische Sonderfälle (zwei Wände). Nicht ins Fenster packen.
 - **Eigenes Symbol verwenden** (Drawing2D-Override je Stil) — erst wenn ein
  Symbol-/Blocksystem existiert.
 **Risiken:**
 - **3D-Vorschau nicht als „korrekt" verkaufen.** Laut Projekt-Memo werden
  `render3d`/`Wasm3DViewport`-Änderungen NICHT per Puppeteer/Browser verifiziert;
  der Nutzer testet 3D selbst in der Tauri-Dev-App. Der Dialog darf 3D anzeigen,
  aber diese Studie/Implementierung behauptet keine visuelle Korrektheit der
  3D-Vorschau — nur der 2D-Pfad (`generatePlan`→SVG) ist headless prüfbar.
 - **Typ-vs-Instanz-Verwirrung.** Ohne klaren „vom Stil abweichend"-Indikator wird
  unklar, ob eine Änderung den Stil (alle Instanzen) oder nur dieses Fenster trifft.
  Muss im UI explizit sein (§3.4).
 - **`sashes` vs. `wingCount` Migration.** `wingCount` bleibt als Fallback; `sashes`
  hat Vorrang, wenn gesetzt. Resolver in `resolveOpeningFrame`
  (`toWalls3d.ts:1845`) und `windowSymbol` müssen beide Wege beherrschen, sonst
  brechen Alt-Projekte oder die `ObjectInfoPanel`-Flügelanzahl-Eingabe.
 - **Modal-Render-Kosten.** Live-Vorschau bei jedem Tastendruck neu generieren ist
  ok für ein Mini-Projekt, aber Patches sollten (leicht) entprellt werden.
 ---
 ## 6. Empfohlene erste Scheibe (P0, konkret)
 Kleinstes End-to-End-Inkrement, das sich schon „reich" anfühlt:
 **Umfang:** Dialog-Shell + Live-2D-Vorschau + Flügeleinteilung (n Flügel mit
 Öffnungsrichtung je Flügel) + mehrscheibige Verglasung + Rollladenkasten +
 „Als Stil speichern".
 **Build-Reihenfolge:**
 1. **Modell (P0-Felder).** `SashDef`, `WindowType.sashes?`, `WindowType.shading?`,
   `WindowType.glazingPanes?` in `src/model/types.ts` ergänzen (additiv). Resolver
   `getWindowType` bleibt; `wingCount`→`sashes`-Ableitung als Helper.
 2. **Renderer-Konsum (2D zuerst, headless prüfbar).**
   - `windowSymbol`/`mullionLines` (`src/geometry/opening.ts`) auf `sashes` umstellen
     (ungleichmäßige Pfostenlagen + Öffnungsrichtung je Flügel als Öffnungslinien).
   - `glassPanesForOpening`/2D-Glaslinien auf `glazingPanes` (statt konstant 1/detail).
   - neuer Zeichenzweig in `addOpeningSymbol` (`src/plan/generatePlan.ts:2214`) für
     die Rollladenkasten-Kontur; 3D-Box später.
   - Unit-Tests gegen `generatePlan()`-Output (Primitive zählen) — das ist der
     verifizierbare Beweis, nicht nur „grüne Typecheck".
 3. **Dialog-Shell.** `src/ui/OpeningEditorDialog.tsx` (Overlay `res-overlay` +
   `role="dialog"`), Sidebar mit den Kategorien Basis / Größe/Position / Rahmen /
   Flügel-Sprossen / Sonnenschutz. Nur diese fünf für P0.
 4. **Live-2D-Vorschau.** Mini-Projekt (kurze Wand + editiertes `Opening`) →
   `generatePlan()` → `sceneToPrintSvg()`/`planToPrintSvg()` → `<div>`. Grundriss +
   Elevations-SVG. Reaktiv auf Patches (leicht entprellt).
 5. **Flügel-Tabelle.** UI-Tabelle mit „Flügel einfügen / Pfosten einfügen / Löschen"
   und je Zeile Öffnungsart + Anschlag (`SashDef`). Schreibt `WindowType.sashes`.
 6. **„Als Stil speichern".** Stil-Leiste + `onSaveAsStyle` → `addWindowType`
   (`src/App.tsx:2304`) mit `PromptDialog`-Namensabfrage; „zurücksetzen" verwirft
   Instanz-Overrides.
 7. **⚙-Verdrahtung.** `ObjectInfoPanel.OpeningSection` (:731) → neuer Host-Handler
   `onOpenOpeningEditor(openingId)`; App-State `openingEditorId`. Ressourcen-Tab
   bleibt als Bibliothek erhalten.
 **Definition of Done (P0):** Aus dem ⚙ öffnet sich der Dialog; man setzt 3 Flügel,
 davon einer Dreh-links / einer Dreh-rechts / einer fest, wählt Dreifachverglasung
 und einen Rollladenkasten; die 2D-Vorschau zeigt die Pfosten/Öffnungslinien/Kasten
 sofort; „Speichern…" legt einen benannten Fensterstil an, der im Typ-Dropdown der
 `OpeningSection` erscheint. Verifikation über `generatePlan()`-Primitiv-Tests
 (2D) — 3D-Box erst danach, vom Nutzer in der Tauri-App geprüft.
@@ -0,0 +1,82 @@
 # SIA 400 — Fenster-/Türdarstellung (Grundriss, Schnitt, Ansicht)
 > Quelle: SIA 400:2000 „Planbearbeitung im Hochbau", Anhang B.9 (Darstellung von
 > Bauteilen), Figuren 36–42. Das PDF liegt im Projektwurzel (lokal excluded,
 > NICHT committen — urheberrechtlich geschützt). Dies ist die verbindliche
 > Darstellungsnorm (Schweiz) — NICHT DIN. Massstab = Detailgrad:
 > **1:100 = grob, 1:50 = mittel, 1:20 = fein.**
 ## B.9.1.1 Fenster im Grundriss (Figuren 36/37/38)
 Regel (Zitat): „Die Darstellung der Fensterkonstruktionen erfolgt nach denselben
 Regeln, unabhängig davon ob es sich um Holz-, Holz-Metall-, Metall- oder
 Kunststoff-Fenster handelt."
 ### Figur 36 — Massstab 1:100 (= grob)
 - Wand **voll schwarz** (Poché massiv), keine Schraffur.
 - Fenster = **eine dünne Rahmen-/Glasband-Andeutung** über die Öffnung, sehr
  schematisch — im Wesentlichen EIN schmales Rechteck/Band mit wenigen Marken,
  KEINE Flügel-/Anschlagdetails, KEINE Laibungsmarken.
 ### Figur 37 — Massstab 1:50 (= mittel)
 - Wand **materialschraffiert** (Bänder: Hinterlüftung/Dämmung senkrecht
  gestrichelt, Backstein/Struktur diagonal). Drei Wandaufbauten gezeigt
  (Backstein+Aussendämmung hinterlüftet / Holzelementbau / Backstein verputzt).
 - Fenster: **Blendrahmen als schmales Band** nahe der Aussenfläche, dünne
  Kontur; **Glaslinie**; **ein kleines Quadrat mittig** (Stulp/Flügelstoss).
  Laibung/Öffnungstiefe sichtbar. Einfach, aber als Fenster lesbar.
 ### Figur 38 — Massstab 1:20 (= fein)
 - Wand voll schraffiert (Kreuzschraffur Backstein, Diagonalschraffur Dämmung).
 - Fenster: **volles Rahmenprofil** — Blendrahmen + Flügelrahmen als mehrere
  parallele Linien (Profiltiefe); **Glas als Doppellinie** (Isolierverglasung
  IV, zwei enge Parallelen); **zwei Stulp-Quadrate mittig** (Flügelstoss der
  zwei Flügel); **Anschlag/Laibung** mit Rahmen-Wand-Detail (Falz/Rebate),
  gestrichelte Anschlagmarken an den Ecken; Anschlagwinkel an den Laibungen.
 ## B.9.1.2 Fenster im Schnitt (Figuren 39/40, M 1:50)
 - Rahmen im Schnitt mit Brüstung/Sturz, Bemassung (z. B. Brüstung +0.90,
  Sturzhöhe). Fenstertüren (Figur 40): Rahmen bis Boden, Schwelle.
 ## B.9.1.3 Sinnbilder Fenster (Öffnungsart in der ANSICHT)
 Liste der Öffnungsarten (SIA-Benennung):
 - Fest im Rahmen verglast (kein Symbol)
 - Drehflügel einflüglig mit Verschluss, **Band rechts/links** (Dreieck, Spitze zur BANDSEITE)
 - Drehflügel fest mit Band und Plattenverschraubung
 - Zweiflüglig mit **Öffnungsreihenfolge** (1 = erstöffnend, 2 = zweitöffnend)
 - Kippflügel mit Verschluss (Dreieck)
 - Kippflügel fest, für Reinigung bedienbar
 - Klappflügel mit Verschluss
 - Drehkippflügel, Band rechts
 - Schwingflügelfenster
 - Wendeflügelfenster, Achse in der Mitte
 - Vertikales Schiebefenster (nach oben schiebbar, oberer Flügel fest)
 Konvention: Dreieck-/Winkelsinnbild, **Spitze zeigt zur Bandseite (Anschlag)**,
 Basis zur Griffseite. (Genaues Sinnbild-Blatt S. 38 rechts.)
 ## B.9.1.4 Kurzzeichen Fenster/Sonnenschutz
 KL Klappladen · SL Schiebeladen · ROL Rolladen · LAM Lamellenstoren ·
 RAF Rafflamellenstoren · FAL Faltrolladen · K Kurbel · DV Doppelverglasung ·
 IV Isolierverglasung · IV3 Dreifachisolierverglasung · BFB Beton-Fensterbank ·
 MFB Metall-Fensterbank · FFB Faserzement-Fensterbank.
 ## B.9.2 Türen im Grundriss (Figuren 41/42) + Sinnbilder (B.9.2.2)
 - **Türblatt als Linie ab Band + Viertelkreisbogen** (Schwingbahn). Bandseite =
  Bogenmittelpunkt. Zweiflüglig/Doppeltüre = zwei Bögen.
 - Zargenarten: Futterrahmen/Zarge, Blockrahmen/Profil, Blendrahmen — je mit
  Anschlag-/Schwellenmark. Bei Niveaudifferenz Schwellenstrich.
 - Weitere Sinnbilder: Pendeltüre (Bogen beidseitig gestrichelt), Falttüre
  (Zickzack), Faltschiebetor, Drehtüre (Kreis mit X), Kipptor, Schiebetüre
  (ausserhalb/in der Wand, Pfeil), Harmonikatüre.
 ## Umsetzung im Code (Soll)
 - `generatePlan.ts` Fenster-Zweig + `geometry/opening.ts::windowSymbol`:
  drei DEUTLICH getrennte Detailstufen statt heute (mittel≈fein):
  - **grob:** 1 Rahmen-/Glasband (Rechteck), sonst nichts.
  - **mittel:** Blendrahmen-Rechteck + Glaslinie + 1 Stulp-Quadrat mittig +
    Flügel-Trennlinien; keine verschachtelten Flügelrahmen, kein Anschlag.
  - **fein:** verschachtelte Blend-+Flügelrahmen (mehrlinig) + Glas-Doppellinie
    (IV) + Stulp-Quadrate + Anschlag/Laibungsmarken.
 - Öffnungssymbole (Ansicht) auf SIA umstellen (Spitze zur Bandseite), Türbögen
  bleiben (schon SIA-konform).
@@ -15,7 +15,7 @@
      rel="icon"
      href="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16'%3E%3Crect width='16' height='16' rx='3' fill='%232f6df6'/%3E%3Cg fill='white'%3E%3Crect x='3' y='3' width='4' height='4'/%3E%3Crect x='9' y='3' width='4' height='4'/%3E%3Crect x='3' y='9' width='4' height='4'/%3E%3Crect x='9' y='9' width='4' height='4'/%3E%3C/g%3E%3C/svg%3E"
    />
-    <title>cad — Phase 0 Spike</title>
+    <title>Dossier</title>
  </head>
  <body>
    <div id="root"></div>
@@ -10,6 +10,8 @@
      "dependencies": {
        "@mlightcad/libredwg-web": "^0.7.7",
        "@tauri-apps/api": "^2.11.1",
        "@tauri-apps/plugin-dialog": "^2.7.1",
        "@tauri-apps/plugin-fs": "^2.5.1",
        "delaunator": "^5.1.0",
        "dxf-parser": "^1.1.2",
        "jspdf": "^4.2.1",
@@ -1842,6 +1844,24 @@
        "node": ">= 10"
      }
    },
    "node_modules/@tauri-apps/plugin-dialog": {
      "version": "2.7.1",
      "resolved": "https://registry.npmjs.org/@tauri-apps/plugin-dialog/-/plugin-dialog-2.7.1.tgz",
      "integrity": "sha512-OK1UBXYt+ojcmxMktzzuyonYIFta8CmAASpX+CA+DTGK24KlHjhYI6x2iOJ/TjZF4N7/ACK1oFmEOjIY9IhzOQ==",
      "license": "MIT OR Apache-2.0",
      "dependencies": {
        "@tauri-apps/api": "^2.11.0"
      }
    },
    "node_modules/@tauri-apps/plugin-fs": {
      "version": "2.5.1",
      "resolved": "https://registry.npmjs.org/@tauri-apps/plugin-fs/-/plugin-fs-2.5.1.tgz",
      "integrity": "sha512-9Lz+Jopp6QyeEWhlpkMx4R/+P9HgR+AVAI4vOZhlT8Xaymtz8iVI/Ov984/XTqgJz/5gz5NretqPB/XEMS3NhQ==",
      "license": "MIT OR Apache-2.0",
      "dependencies": {
        "@tauri-apps/api": "^2.11.0"
      }
    },
    "node_modules/@tweenjs/tween.js": {
      "version": "23.1.3",
      "resolved": "https://registry.npmjs.org/@tweenjs/tween.js/-/tween.js-23.1.3.tgz",
@@ -1,8 +1,10 @@
 {
-  "name": "cad",
+  "name": "dossier",
  "private": true,
  "version": "0.0.0",
  "type": "module",
  "license": "AGPL-3.0-or-later",
  "author": "Karim Gabriele Varano",
  "scripts": {
    "dev": "vite",
    "build": "tsc -b && vite build",
@@ -16,11 +18,17 @@
    "shell": "scripts/chromium-shell.sh",
    "electron": "scripts/electron-shell.sh",
    "build:engine": "wasm-pack build src-tauri/render2d --release --target web --out-dir ../../src/engine/pkg --out-name render2d --no-default-features --features web",
-    "build:engine3d": "wasm-pack build src-tauri/render3d --release --target web --out-dir ../../src/engine/pkg3d --out-name render3d --no-default-features --features web"
+    "build:engine3d": "wasm-pack build src-tauri/render3d --release --target web --out-dir ../../src/engine/pkg3d --out-name render3d --no-default-features --features web",
    "build:geometry": "wasm-pack build src-tauri/geometry --release --target web --out-dir ../../src/engine/pkgGeometry --out-name geometry --no-default-features --features web",
    "build:kernel2d": "wasm-pack build src-tauri/kernel2d --release --target web --out-dir ../../src/engine/pkgKernel2d --out-name kernel2d --no-default-features --features web",
    "build:dwgimport": "wasm-pack build src-tauri/dwgimport --release --target web --out-dir ../../src/engine/pkgDwgImport --out-name dwgimport --no-default-features --features web",
    "build:truck": "wasm-pack build src-tauri/trucksolid --release --target web --out-dir ../../src/engine/pkgTruck --out-name trucksolid --no-default-features --features web"
  },
  "dependencies": {
    "@mlightcad/libredwg-web": "^0.7.7",
    "@tauri-apps/api": "^2.11.1",
    "@tauri-apps/plugin-dialog": "^2.7.1",
    "@tauri-apps/plugin-fs": "^2.5.1",
    "delaunator": "^5.1.0",
    "dxf-parser": "^1.1.2",
    "jspdf": "^4.2.1",
@@ -45,5 +53,12 @@
    "vite": "^5.4.8",
    "vitest": "^4.1.9",
    "wasm-pack": "^0.15.0"
  },
  "allowScripts": {
    "core-js@3.49.0": true,
    "esbuild@0.21.5": true,
    "fsevents@2.3.3": true,
    "fsevents@2.3.2": true,
    "wasm-pack@0.15.0": true
  }
 }
@@ -1,7 +1,7 @@
 {
  "source": "ambientCG (ambientcg.com)",
  "license": "CC0 1.0 Universal (Public Domain)",
-  "resolution": "1K",
+  "resolution": "2K",
  "materials": [
    {
      "id": "Concrete048",
@@ -61,6 +61,18 @@
        "ao": "/assets/materials/Bricks104/ao.jpg"
      }
    },
    {
      "id": "RoofingTiles013A",
      "name": "Dachziegel",
      "category": "Roofing Tiles",
      "maps": {
        "color": "/assets/materials/RoofingTiles013A/color.jpg",
        "normal": "/assets/materials/RoofingTiles013A/normal.jpg",
        "roughness": "/assets/materials/RoofingTiles013A/roughness.jpg",
        "displacement": "/assets/materials/RoofingTiles013A/displacement.jpg",
        "ao": "/assets/materials/RoofingTiles013A/ao.jpg"
      }
    },
    {
      "id": "Tiles141",
      "name": "Bodenfliesen",
@@ -144,4 +156,4 @@
      }
    }
  ]
-}
+}
@@ -384,6 +384,7 @@ dependencies = [
 name = "cad-tauri"
 version = "0.1.0"
 dependencies = [
 "fs4",
 "geometry",
 "pollster",
 "render2d",
@@ -392,6 +393,8 @@ dependencies = [
 "serde_json",
 "tauri",
 "tauri-build",
 "tauri-plugin-dialog",
 "tauri-plugin-fs",
 "wgpu",
 "winit",
 ]
@@ -982,7 +985,7 @@ version = "0.5.3"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "ab8ecd87370524b461f8557c119c405552c396ed91fc0a8eec68679eab26f94a"
 dependencies = [
- "libloading 0.7.4",
+ "libloading 0.8.9",
 ]
 [[package]]
@@ -1304,6 +1307,16 @@ dependencies = [
 "percent-encoding",
 ]
 [[package]]
 name = "fs4"
 version = "0.9.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "e8c6b3bd49c37d2aa3f3f2220233b29a7cd23f79d1fe70e5337d25fb390793de"
 dependencies = [
 "rustix 0.38.44",
 "windows-sys 0.52.0",
 ]
 [[package]]
 name = "futures-channel"
 version = "0.3.32"
@@ -1488,8 +1501,10 @@ dependencies = [
 name = "geometry"
 version = "0.1.0"
 dependencies = [
 "console_error_panic_hook",
 "serde",
 "serde_json",
 "wasm-bindgen",
 ]
 [[package]]
@@ -1688,7 +1703,7 @@ dependencies = [
 "log",
 "presser",
 "thiserror 2.0.18",
- "windows 0.61.3",
+ "windows 0.62.2",
 ]
 [[package]]
@@ -2890,6 +2905,7 @@ checksum = "e3e0adef53c21f888deb4fa59fc59f7eb17404926ee8a6f59f5df0fd7f9f3272"
 dependencies = [
 "bitflags 2.13.0",
 "block2 0.6.2",
 "libc",
 "objc2 0.6.4",
 "objc2-core-foundation",
 ]
@@ -3703,6 +3719,30 @@ dependencies = [
 "web-sys",
 ]
 [[package]]
 name = "rfd"
 version = "0.16.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "a15ad77d9e70a92437d8f74c35d99b4e4691128df018833e99f90bcd36152672"
 dependencies = [
 "block2 0.6.2",
 "dispatch2",
 "glib-sys",
 "gobject-sys",
 "gtk-sys",
 "js-sys",
 "log",
 "objc2 0.6.4",
 "objc2-app-kit 0.3.2",
 "objc2-core-foundation",
 "objc2-foundation 0.3.2",
 "raw-window-handle",
 "wasm-bindgen",
 "wasm-bindgen-futures",
 "web-sys",
 "windows-sys 0.60.2",
 ]
 [[package]]
 name = "roxmltree"
 version = "0.20.0"
@@ -4536,6 +4576,64 @@ dependencies = [
 "tauri-utils",
 ]
 [[package]]
 name = "tauri-plugin"
 version = "2.6.3"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "74be5dd4bed9afbd145e5716b5fa2ec28cbc29c34ffa61c258c9273d896c8020"
 dependencies = [
 "anyhow",
 "glob",
 "plist",
 "schemars 0.8.22",
 "serde",
 "serde_json",
 "tauri-utils",
 "walkdir",
 ]
 [[package]]
 name = "tauri-plugin-dialog"
 version = "2.7.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "65981abb771e74e571a38196c3baa11c459379164791eba0e67abc1a5fac9884"
 dependencies = [
 "log",
 "raw-window-handle",
 "rfd",
 "serde",
 "serde_json",
 "tauri",
 "tauri-plugin",
 "tauri-plugin-fs",
 "thiserror 2.0.18",
 "url",
 ]
 [[package]]
 name = "tauri-plugin-fs"
 version = "2.5.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "b7ecc274121aca0c036a2b42d1cbe83d368d348f54e0bb8a735c2b1548e8f371"
 dependencies = [
 "anyhow",
 "dunce",
 "glob",
 "log",
 "objc2-foundation 0.3.2",
 "percent-encoding",
 "schemars 0.8.22",
 "serde",
 "serde_json",
 "serde_repr",
 "tauri",
 "tauri-plugin",
 "tauri-utils",
 "thiserror 2.0.18",
 "toml 1.1.2+spec-1.1.0",
 "url",
 ]
 [[package]]
 name = "tauri-runtime"
 version = "2.11.3"
@@ -5944,6 +6042,15 @@ dependencies = [
 "windows-targets 0.52.6",
 ]
 [[package]]
 name = "windows-sys"
 version = "0.60.2"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "f2f500e4d28234f72040990ec9d39e3a6b950f9f22d3dba18416c35882612bcb"
 dependencies = [
 "windows-targets 0.53.5",
 ]
 [[package]]
 name = "windows-sys"
 version = "0.61.2"
@@ -5977,13 +6084,30 @@ dependencies = [
 "windows_aarch64_gnullvm 0.52.6",
 "windows_aarch64_msvc 0.52.6",
 "windows_i686_gnu 0.52.6",
- "windows_i686_gnullvm",
+ "windows_i686_gnullvm 0.52.6",
 "windows_i686_msvc 0.52.6",
 "windows_x86_64_gnu 0.52.6",
 "windows_x86_64_gnullvm 0.52.6",
 "windows_x86_64_msvc 0.52.6",
 ]
 [[package]]
 name = "windows-targets"
 version = "0.53.5"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "4945f9f551b88e0d65f3db0bc25c33b8acea4d9e41163edf90dcd0b19f9069f3"
 dependencies = [
 "windows-link 0.2.1",
 "windows_aarch64_gnullvm 0.53.1",
 "windows_aarch64_msvc 0.53.1",
 "windows_i686_gnu 0.53.1",
 "windows_i686_gnullvm 0.53.1",
 "windows_i686_msvc 0.53.1",
 "windows_x86_64_gnu 0.53.1",
 "windows_x86_64_gnullvm 0.53.1",
 "windows_x86_64_msvc 0.53.1",
 ]
 [[package]]
 name = "windows-threading"
 version = "0.1.0"
@@ -6023,6 +6147,12 @@ version = "0.52.6"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "32a4622180e7a0ec044bb555404c800bc9fd9ec262ec147edd5989ccd0c02cd3"
 [[package]]
 name = "windows_aarch64_gnullvm"
 version = "0.53.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "a9d8416fa8b42f5c947f8482c43e7d89e73a173cead56d044f6a56104a6d1b53"
 [[package]]
 name = "windows_aarch64_msvc"
 version = "0.42.2"
@@ -6035,6 +6165,12 @@ version = "0.52.6"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "09ec2a7bb152e2252b53fa7803150007879548bc709c039df7627cabbd05d469"
 [[package]]
 name = "windows_aarch64_msvc"
 version = "0.53.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "b9d782e804c2f632e395708e99a94275910eb9100b2114651e04744e9b125006"
 [[package]]
 name = "windows_i686_gnu"
 version = "0.42.2"
@@ -6047,12 +6183,24 @@ version = "0.52.6"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "8e9b5ad5ab802e97eb8e295ac6720e509ee4c243f69d781394014ebfe8bbfa0b"
 [[package]]
 name = "windows_i686_gnu"
 version = "0.53.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "960e6da069d81e09becb0ca57a65220ddff016ff2d6af6a223cf372a506593a3"
 [[package]]
 name = "windows_i686_gnullvm"
 version = "0.52.6"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "0eee52d38c090b3caa76c563b86c3a4bd71ef1a819287c19d586d7334ae8ed66"
 [[package]]
 name = "windows_i686_gnullvm"
 version = "0.53.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "fa7359d10048f68ab8b09fa71c3daccfb0e9b559aed648a8f95469c27057180c"
 [[package]]
 name = "windows_i686_msvc"
 version = "0.42.2"
@@ -6065,6 +6213,12 @@ version = "0.52.6"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "240948bc05c5e7c6dabba28bf89d89ffce3e303022809e73deaefe4f6ec56c66"
 [[package]]
 name = "windows_i686_msvc"
 version = "0.53.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "1e7ac75179f18232fe9c285163565a57ef8d3c89254a30685b57d83a38d326c2"
 [[package]]
 name = "windows_x86_64_gnu"
 version = "0.42.2"
@@ -6077,6 +6231,12 @@ version = "0.52.6"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "147a5c80aabfbf0c7d901cb5895d1de30ef2907eb21fbbab29ca94c5b08b1a78"
 [[package]]
 name = "windows_x86_64_gnu"
 version = "0.53.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "9c3842cdd74a865a8066ab39c8a7a473c0778a3f29370b5fd6b4b9aa7df4a499"
 [[package]]
 name = "windows_x86_64_gnullvm"
 version = "0.42.2"
@@ -6089,6 +6249,12 @@ version = "0.52.6"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "24d5b23dc417412679681396f2b49f3de8c1473deb516bd34410872eff51ed0d"
 [[package]]
 name = "windows_x86_64_gnullvm"
 version = "0.53.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "0ffa179e2d07eee8ad8f57493436566c7cc30ac536a3379fdf008f47f6bb7ae1"
 [[package]]
 name = "windows_x86_64_msvc"
 version = "0.42.2"
@@ -6101,6 +6267,12 @@ version = "0.52.6"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "589f6da84c646204747d1270a2a5661ea66ed1cced2631d546fdfb155959f9ec"
 [[package]]
 name = "windows_x86_64_msvc"
 version = "0.53.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "d6bbff5f0aada427a1e5a6da5f1f98158182f26556f345ac9e04d36d0ebed650"
 [[package]]
 name = "winit"
 version = "0.30.13"
@@ -1,10 +1,14 @@
 [workspace]
-members = [".", "geometry"]
+members = ["."]
-# render2d/render3d sind eigenstaendige Crates (jeweils eigener [workspace]), damit
+# render2d/render3d/geometry sind eigenstaendige Crates, damit sie headless ohne
-# sie headless ohne Tauri-Toolchain baubar/testbar bleiben. Sie liegen zwar im
+# Tauri-Toolchain UND per wasm-pack (Feature "web") zu WASM baubar bleiben. Sie
-# src-tauri-Baum, gehoeren aber NICHT zum cad-tauri-Workspace — hier ausschliessen,
+# liegen zwar im src-tauri-Baum, gehoeren aber NICHT zum cad-tauri-Workspace —
-# damit `cad-tauri` sie dennoch per Pfad als (optionale) Abhaengigkeit nutzen kann.
+# hier ausschliessen, damit `cad-tauri` sie dennoch per Pfad als Abhaengigkeit
-exclude = ["render2d", "render3d"]
+# nutzen kann. geometry: neu ausgeschlossen (war Member), seit es zu WASM gebaut
 # wird und das TS-Frontend die Joins direkt per WASM aufruft (statt TS-Duplikat).
 # kernel2d: analog — eigenstaendiger 2D-Geometrie-Kern (Port von kernel2d.ts),
 # per wasm-pack (Feature "web") zu WASM gebaut, ausserhalb des cad-tauri-Workspace.
 exclude = ["render2d", "render3d", "geometry", "kernel2d", "dwgimport", "trucksolid"]
 [package]
 name = "cad-tauri"
@@ -33,9 +37,15 @@ tauri-build = { version = "2", features = [] }
 [dependencies]
 tauri = { version = "2", features = [] }
 tauri-plugin-dialog = "2"
 tauri-plugin-fs = "2"
 serde = { version = "1", features = ["derive"] }
 serde_json = "1"
 geometry = { path = "geometry" }
 # OS-Advisory-Lock (gepflegter fs2-Nachfolger) fuer die Projektdatei-Lock-Datei
 # (src/lock.rs): exklusiver Lock auf einer Sidecar-Datei, faellt automatisch
 # beim Prozessende/Absturz weg (kein manuelles Aufraeumen noetig).
 fs4 = { version = "0.9", default-features = false, features = ["sync"] }
 # --- M2-Spike (nur mit Feature "native2d") -----------------------------------
 # render2d ist eine eigenstaendige Crate (eigener leerer [workspace]); wir binden
@@ -0,0 +1,22 @@
 {
  "$schema": "../gen/schemas/desktop-schema.json",
  "identifier": "default",
  "description": "Basis-Permissions + Fenstersteuerung fuer die randlose (decorations:false) Titelleiste: Minimieren/Maximieren/Schliessen + Ziehen der eigenen Titelleiste (data-tauri-drag-region). Menu: fuer die native macOS-Systemmenueleiste (src/native/appMenu.ts). Webview/Event: fuer die nativen Ressourcen-/Einstellungs-/Zeichnungsebenen-/Ebeneneinstellungs-Fenster + ihre Sync-Bruecken (src/native/*Window.ts) - gilt fuer alle Fensterlabels, da jedes Events senden/empfangen muss.",
  "windows": ["main", "resources", "settings", "drawing-levels", "layer-settings", "context-import"],
  "permissions": [
    "core:default",
    "core:window:allow-minimize",
    "core:window:allow-maximize",
    "core:window:allow-unmaximize",
    "core:window:allow-toggle-maximize",
    "core:window:allow-is-maximized",
    "core:window:allow-close",
    "core:window:allow-start-dragging",
    "core:window:allow-create",
    "core:webview:allow-create-webview-window",
    "core:menu:default",
    "core:event:default",
    "dialog:allow-save",
    "fs:allow-write-text-file"
  ]
 }
@@ -0,0 +1,578 @@
 # This file is automatically @generated by Cargo.
 # It is not intended for manual editing.
 version = 4
 [[package]]
 name = "acadrust"
 version = "0.4.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "153498e7c9b058326ff0fae11bc9fd870cf2ea0aa9111875d03625fa9018c218"
 dependencies = [
 "ahash",
 "anyhow",
 "bitflags",
 "byteorder",
 "encoding_rs",
 "flate2",
 "indexmap",
 "itoa",
 "nalgebra",
 "nom",
 "once_cell",
 "ryu",
 "thiserror",
 ]
 [[package]]
 name = "adler2"
 version = "2.0.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "320119579fcad9c21884f5c4861d16174d0e06250625266f50fe6898340abefa"
 [[package]]
 name = "ahash"
 version = "0.8.12"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "5a15f179cd60c4584b8a8c596927aadc462e27f2ca70c04e0071964a73ba7a75"
 dependencies = [
 "cfg-if",
 "getrandom",
 "once_cell",
 "version_check",
 "zerocopy",
 ]
 [[package]]
 name = "anyhow"
 version = "1.0.103"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "2a4385e2e34eb35d6b3efe798b9eb88096925d87726c0798709bf56d9ed84af3"
 [[package]]
 name = "approx"
 version = "0.5.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "cab112f0a86d568ea0e627cc1d6be74a1e9cd55214684db5561995f6dad897c6"
 dependencies = [
 "num-traits",
 ]
 [[package]]
 name = "autocfg"
 version = "1.5.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "f2032f911046de80f0a198e0901378627c33f59ea0ac00e363d481118bd70a53"
 [[package]]
 name = "bitflags"
 version = "2.13.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "b4388bee8683e3d04af747c73422af53102d2bd24d9eadb6cbc100baef4b43f8"
 [[package]]
 name = "bumpalo"
 version = "3.20.3"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "72f5acc6cb2ba439de613abc23857ec3d78374d8ed5ac84e9d11336e87da8649"
 [[package]]
 name = "bytemuck"
 version = "1.25.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "c8efb64bd706a16a1bdde310ae86b351e4d21550d98d056f22f8a7f7a2183fec"
 [[package]]
 name = "byteorder"
 version = "1.5.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "1fd0f2584146f6f2ef48085050886acf353beff7305ebd1ae69500e27c67f64b"
 [[package]]
 name = "cfg-if"
 version = "1.0.4"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "9330f8b2ff13f34540b44e946ef35111825727b38d33286ef986142615121801"
 [[package]]
 name = "console_error_panic_hook"
 version = "0.1.7"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "a06aeb73f470f66dcdbf7223caeebb85984942f22f1adb2a088cf9668146bbbc"
 dependencies = [
 "cfg-if",
 "wasm-bindgen",
 ]
 [[package]]
 name = "crc32fast"
 version = "1.5.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "9481c1c90cbf2ac953f07c8d4a58aa3945c425b7185c9154d67a65e4230da511"
 dependencies = [
 "cfg-if",
 ]
 [[package]]
 name = "dwgimport"
 version = "0.1.0"
 dependencies = [
 "acadrust",
 "console_error_panic_hook",
 "getrandom",
 "serde",
 "serde_json",
 "wasm-bindgen",
 ]
 [[package]]
 name = "encoding_rs"
 version = "0.8.35"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "75030f3c4f45dafd7586dd6780965a8c7e8e285a5ecb86713e63a79c5b2766f3"
 dependencies = [
 "cfg-if",
 ]
 [[package]]
 name = "equivalent"
 version = "1.0.2"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "877a4ace8713b0bcf2a4e7eec82529c029f1d0619886d18145fea96c3ffe5c0f"
 [[package]]
 name = "flate2"
 version = "1.1.9"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "843fba2746e448b37e26a819579957415c8cef339bf08564fe8b7ddbd959573c"
 dependencies = [
 "crc32fast",
 "miniz_oxide",
 ]
 [[package]]
 name = "getrandom"
 version = "0.3.4"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "899def5c37c4fd7b2664648c28120ecec138e4d395b459e5ca34f9cce2dd77fd"
 dependencies = [
 "cfg-if",
 "js-sys",
 "libc",
 "r-efi",
 "wasip2",
 "wasm-bindgen",
 ]
 [[package]]
 name = "hashbrown"
 version = "0.17.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "ed5909b6e89a2db4456e54cd5f673791d7eca6732202bbf2a9cc504fe2f9b84a"
 [[package]]
 name = "indexmap"
 version = "2.14.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "d466e9454f08e4a911e14806c24e16fba1b4c121d1ea474396f396069cf949d9"
 dependencies = [
 "equivalent",
 "hashbrown",
 ]
 [[package]]
 name = "itoa"
 version = "1.0.18"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "8f42a60cbdf9a97f5d2305f08a87dc4e09308d1276d28c869c684d7777685682"
 [[package]]
 name = "js-sys"
 version = "0.3.103"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "53b44bfcdb3f8d5837a46dae1ca9660a837176eee74a28b229bc626816589102"
 dependencies = [
 "cfg-if",
 "wasm-bindgen",
 ]
 [[package]]
 name = "libc"
 version = "0.2.186"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "68ab91017fe16c622486840e4c83c9a37afeff978bd239b5293d61ece587de66"
 [[package]]
 name = "matrixmultiply"
 version = "0.3.10"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "a06de3016e9fae57a36fd14dba131fccf49f74b40b7fbdb472f96e361ec71a08"
 dependencies = [
 "autocfg",
 "rawpointer",
 ]
 [[package]]
 name = "memchr"
 version = "2.8.2"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "88904434abc2901f197fe8cc55f0445e7ded921dba5911dad2e2b39b48e663c4"
 [[package]]
 name = "minimal-lexical"
 version = "0.2.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "68354c5c6bd36d73ff3feceb05efa59b6acb7626617f4962be322a825e61f79a"
 [[package]]
 name = "miniz_oxide"
 version = "0.8.9"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "1fa76a2c86f704bdb222d66965fb3d63269ce38518b83cb0575fca855ebb6316"
 dependencies = [
 "adler2",
 "simd-adler32",
 ]
 [[package]]
 name = "nalgebra"
 version = "0.32.6"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "7b5c17de023a86f59ed79891b2e5d5a94c705dbe904a5b5c9c952ea6221b03e4"
 dependencies = [
 "approx",
 "matrixmultiply",
 "nalgebra-macros",
 "num-complex",
 "num-rational",
 "num-traits",
 "simba",
 "typenum",
 ]
 [[package]]
 name = "nalgebra-macros"
 version = "0.2.2"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "254a5372af8fc138e36684761d3c0cdb758a4410e938babcff1c860ce14ddbfc"
 dependencies = [
 "proc-macro2",
 "quote",
 "syn",
 ]
 [[package]]
 name = "nom"
 version = "7.1.3"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "d273983c5a657a70a3e8f2a01329822f3b8c8172b73826411a55751e404a0a4a"
 dependencies = [
 "memchr",
 "minimal-lexical",
 ]
 [[package]]
 name = "num-complex"
 version = "0.4.6"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "73f88a1307638156682bada9d7604135552957b7818057dcef22705b4d509495"
 dependencies = [
 "num-traits",
 ]
 [[package]]
 name = "num-integer"
 version = "0.1.46"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "7969661fd2958a5cb096e56c8e1ad0444ac2bbcd0061bd28660485a44879858f"
 dependencies = [
 "num-traits",
 ]
 [[package]]
 name = "num-rational"
 version = "0.4.2"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "f83d14da390562dca69fc84082e73e548e1ad308d24accdedd2720017cb37824"
 dependencies = [
 "num-integer",
 "num-traits",
 ]
 [[package]]
 name = "num-traits"
 version = "0.2.19"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "071dfc062690e90b734c0b2273ce72ad0ffa95f0c74596bc250dcfd960262841"
 dependencies = [
 "autocfg",
 ]
 [[package]]
 name = "once_cell"
 version = "1.21.4"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "9f7c3e4beb33f85d45ae3e3a1792185706c8e16d043238c593331cc7cd313b50"
 [[package]]
 name = "paste"
 version = "1.0.15"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "57c0d7b74b563b49d38dae00a0c37d4d6de9b432382b2892f0574ddcae73fd0a"
 [[package]]
 name = "proc-macro2"
 version = "1.0.106"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "8fd00f0bb2e90d81d1044c2b32617f68fcb9fa3bb7640c23e9c748e53fb30934"
 dependencies = [
 "unicode-ident",
 ]
 [[package]]
 name = "quote"
 version = "1.0.46"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "dfbc457d0c7a0759a614551b11a6409e5951f6c7537be1f1b7682b9ae9230368"
 dependencies = [
 "proc-macro2",
 ]
 [[package]]
 name = "r-efi"
 version = "5.3.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "69cdb34c158ceb288df11e18b4bd39de994f6657d83847bdffdbd7f346754b0f"
 [[package]]
 name = "rawpointer"
 version = "0.2.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "60a357793950651c4ed0f3f52338f53b2f809f32d83a07f72909fa13e4c6c1e3"
 [[package]]
 name = "rustversion"
 version = "1.0.22"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "b39cdef0fa800fc44525c84ccb54a029961a8215f9619753635a9c0d2538d46d"
 [[package]]
 name = "ryu"
 version = "1.0.23"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "9774ba4a74de5f7b1c1451ed6cd5285a32eddb5cccb8cc655a4e50009e06477f"
 [[package]]
 name = "safe_arch"
 version = "0.7.4"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "96b02de82ddbe1b636e6170c21be622223aea188ef2e139be0a5b219ec215323"
 dependencies = [
 "bytemuck",
 ]
 [[package]]
 name = "serde"
 version = "1.0.228"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "9a8e94ea7f378bd32cbbd37198a4a91436180c5bb472411e48b5ec2e2124ae9e"
 dependencies = [
 "serde_core",
 "serde_derive",
 ]
 [[package]]
 name = "serde_core"
 version = "1.0.228"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "41d385c7d4ca58e59fc732af25c3983b67ac852c1a25000afe1175de458b67ad"
 dependencies = [
 "serde_derive",
 ]
 [[package]]
 name = "serde_derive"
 version = "1.0.228"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "d540f220d3187173da220f885ab66608367b6574e925011a9353e4badda91d79"
 dependencies = [
 "proc-macro2",
 "quote",
 "syn",
 ]
 [[package]]
 name = "serde_json"
 version = "1.0.150"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "e8014e44b4736ed0538adeecded0fce2a272f22dc9578a7eb6b2d9993c74cfb9"
 dependencies = [
 "itoa",
 "memchr",
 "serde",
 "serde_core",
 "zmij",
 ]
 [[package]]
 name = "simba"
 version = "0.8.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "061507c94fc6ab4ba1c9a0305018408e312e17c041eb63bef8aa726fa33aceae"
 dependencies = [
 "approx",
 "num-complex",
 "num-traits",
 "paste",
 "wide",
 ]
 [[package]]
 name = "simd-adler32"
 version = "0.3.9"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "703d5c7ef118737c72f1af64ad2f6f8c5e1921f818cdcb97b8fe6fc69bf66214"
 [[package]]
 name = "syn"
 version = "2.0.118"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "1b9ae57f904213ebb649ce6895b8a66c66f0203b9319718f69a5612a065b1422"
 dependencies = [
 "proc-macro2",
 "quote",
 "unicode-ident",
 ]
 [[package]]
 name = "thiserror"
 version = "1.0.69"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "b6aaf5339b578ea85b50e080feb250a3e8ae8cfcdff9a461c9ec2904bc923f52"
 dependencies = [
 "thiserror-impl",
 ]
 [[package]]
 name = "thiserror-impl"
 version = "1.0.69"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "4fee6c4efc90059e10f81e6d42c60a18f76588c3d74cb83a0b242a2b6c7504c1"
 dependencies = [
 "proc-macro2",
 "quote",
 "syn",
 ]
 [[package]]
 name = "typenum"
 version = "1.20.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "b6f5e870be6c3b371b77fe0ee0bafb859fa4964b4404c27de1d380043c4dda20"
 [[package]]
 name = "unicode-ident"
 version = "1.0.24"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "e6e4313cd5fcd3dad5cafa179702e2b244f760991f45397d14d4ebf38247da75"
 [[package]]
 name = "version_check"
 version = "0.9.5"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "0b928f33d975fc6ad9f86c8f283853ad26bdd5b10b7f1542aa2fa15e2289105a"
 [[package]]
 name = "wasip2"
 version = "1.0.4+wasi-0.2.12"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "b67efb37e106e55ce722a510d6b5f9c17f083e5fc79afc2badeb12cc313d9487"
 dependencies = [
 "wit-bindgen",
 ]
 [[package]]
 name = "wasm-bindgen"
 version = "0.2.126"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "4b067c0c11094aef6b7a801c1e34a26affafdf3d051dba08456b868789aaf9a4"
 dependencies = [
 "cfg-if",
 "once_cell",
 "rustversion",
 "wasm-bindgen-macro",
 "wasm-bindgen-shared",
 ]
 [[package]]
 name = "wasm-bindgen-macro"
 version = "0.2.126"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "167ce5e579f6bcf889c4f7175a8a5a585de84e8ff93976ce393efa5f2837aab1"
 dependencies = [
 "quote",
 "wasm-bindgen-macro-support",
 ]
 [[package]]
 name = "wasm-bindgen-macro-support"
 version = "0.2.126"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "f3997c7839262f4ef12cf90b818d6340c18e80f263f1a94bf157d0ec4420380e"
 dependencies = [
 "bumpalo",
 "proc-macro2",
 "quote",
 "syn",
 "wasm-bindgen-shared",
 ]
 [[package]]
 name = "wasm-bindgen-shared"
 version = "0.2.126"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "dc1b4cb0cc549fcf58d7dfc081778139b3d283a081644e833e84682ad71cea24"
 dependencies = [
 "unicode-ident",
 ]
 [[package]]
 name = "wide"
 version = "0.7.33"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "0ce5da8ecb62bcd8ec8b7ea19f69a51275e91299be594ea5cc6ef7819e16cd03"
 dependencies = [
 "bytemuck",
 "safe_arch",
 ]
 [[package]]
 name = "wit-bindgen"
 version = "0.57.1"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "1ebf944e87a7c253233ad6766e082e3cd714b5d03812acc24c318f549614536e"
 [[package]]
 name = "zerocopy"
 version = "0.8.52"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "ce1022995ff5ff5d841ad7d994facc23098cd40152f2c1d11cd607c6f530653f"
 dependencies = [
 "zerocopy-derive",
 ]
 [[package]]
 name = "zerocopy-derive"
 version = "0.8.52"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "1ae7f38b72ec2a254e2b87ef277cf2cd4fb97cbebf944faa6f33354da0867930"
 dependencies = [
 "proc-macro2",
 "quote",
 "syn",
 ]
 [[package]]
 name = "zmij"
 version = "1.0.21"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "b8848ee67ecc8aedbaf3e4122217aff892639231befc6a1b58d29fff4c2cabaa"
@@ -0,0 +1,36 @@
 # Eigener leerer Workspace-Block: entkoppelt dwgimport vollstaendig vom
 # cad-tauri-Workspace (src-tauri/Cargo.toml). Muster: kernel2d/render2d.
 [workspace]
 [package]
 name = "dwgimport"
 version = "0.1.0"
 edition = "2021"
 description = "DXF-Import-Probe: beweist, dass acadrust (MPL-2.0) aus einem Byte-Buffer parst und nach wasm32-unknown-unknown kompiliert."
 # cdylib: fuer wasm-pack (Feature \"web\"). rlib: fuer cargo test + Pfad-Dep.
 [lib]
 crate-type = ["cdylib", "rlib"]
 [features]
 # Standard: headless, kein WASM-Overhead — per `cargo test` pruefbar.
 default = []
 # Browser-Bindings: wasm-bindgen-Fassade; nur fuer wasm32-unknown-unknown.
 web = ["dep:wasm-bindgen", "dep:serde_json", "dep:console_error_panic_hook"]
 [dependencies]
 # DXF/DWG-Parser (MPL-2.0), von crates.io.
 acadrust = "0.4"
 # getrandom wird transitiv via ahash→acadrust gezogen. Fuer wasm32 muss das
 # Feature "wasm_js" explizit aktiviert werden (sonst Compile-Fehler).
 # Direkte Dep mit Feature-Aktivierung unifiziert das Flag fuer alle Abhaengigen.
 getrandom = { version = "0.3", features = ["wasm_js"] }
 # Serialisierung: immer vorhanden (fuer den headless parse_dxf_summary-Kern).
 serde = { version = "1", features = ["derive"] }
 serde_json = { version = "1", optional = true }
 # WASM-Bindings — nur im Feature "web" aktiv.
 wasm-bindgen = { version = "0.2", optional = true }
 console_error_panic_hook = { version = "0.1", optional = true }
@@ -0,0 +1,284 @@
 // dwgimport — SPIKE: beweist, dass acadrust (MPL-2.0) aus einem Byte-Buffer
 // ein DXF parst und nach wasm32-unknown-unknown kompiliert.
 //
 // Aufbau:
 //   - `parse_dxf_summary`: headless, feature-frei testbar.
 //   - `#[cfg(feature="web")]` wasm-bindgen-Fassade darueber.
 //
 // API-Stuetzpunkt acadrust:
 //   `DxfReader::from_reader<R: Read + Seek + 'static>(reader: R)`
 //   → std::io::Cursor<&[u8]> implementiert Read + Seek → WASM-tauglich.
 use std::collections::HashMap;
 use std::io::Cursor;
 use acadrust::DxfReader;
 // serde_json nur bei Feature "web" als optionale Dep, aber serde ist immer da.
 // Fuer den headless-Kern bauen wir das JSON mit einem einfachen Format-String,
 // damit keine Compile-Time-Dep auf serde_json im Default-Feature noetig ist.
 /// Parst ein DXF aus einem Byte-Slice und gibt ein JSON-Summary zurueck.
 ///
 /// Rueckgabe-JSON-Schema:
 /// ```json
 /// {
 ///   "version": "AC1015",
 ///   "entityCount": 5,
 ///   "entityTypeCounts": { "LINE": 3, "CIRCLE": 2 },
 ///   "layerNames": ["0", "Wand"]
 /// }
 /// ```
 ///
 /// Fehler: String mit Fehlerbeschreibung.
 pub fn parse_dxf_summary(bytes: &[u8]) -> Result<String, String> {
    // Cursor<Vec<u8>> implementiert Read + Seek + 'static — kein std::fs noetig.
    // (from_reader verlangt R: 'static; Cursor<&[u8]> wuerde die Lifetime verletzen.)
    let cursor = Cursor::new(bytes.to_vec());
    let reader = DxfReader::from_reader(cursor)
        .map_err(|e| format!("DxfReader::from_reader fehlgeschlagen: {e}"))?;
    let doc = reader
        .read()
        .map_err(|e| format!("DxfReader::read fehlgeschlagen: {e}"))?;
    // Versions-String aus dem Enum (Debug-Format, z. B. "AC1015").
    let version = format!("{:?}", doc.version);
    // Entitaeten zaehlen und nach Typ aufschluesseln.
    let mut type_counts: HashMap<&str, usize> = HashMap::new();
    for entity in doc.entities() {
        let typ = entity.as_entity().entity_type();
        *type_counts.entry(typ).or_insert(0) += 1;
    }
    let entity_count = type_counts.values().sum::<usize>();
    // Layer-Namen aus der Layer-Tabelle.
    let mut layer_names: Vec<String> = doc
        .layers
        .iter()
        .map(|l| l.name.clone())
        .collect();
    layer_names.sort();
    // JSON-Serialisierung ohne optionale serde_json-Dep im Default-Feature.
    // Fuer den headless-Test reicht ein sauberer Format-String.
    let type_counts_json = {
        let mut pairs: Vec<String> = type_counts
            .iter()
            .map(|(k, v)| format!("    \"{k}\": {v}"))
            .collect();
        pairs.sort(); // deterministisch fuer Tests
        format!("{{\n{}\n  }}", pairs.join(",\n"))
    };
    let layer_names_json = {
        let quoted: Vec<String> = layer_names
            .iter()
            .map(|n| format!("\"{}\"", n.replace('"', "\\\"")))
            .collect();
        format!("[{}]", quoted.join(", "))
    };
    Ok(format!(
        "{{\n  \"version\": \"{version}\",\n  \"entityCount\": {entity_count},\n  \"entityTypeCounts\": {type_counts_json},\n  \"layerNames\": {layer_names_json}\n}}"
    ))
 }
 // ---------------------------------------------------------------------------
 // WASM-Fassade (nur bei Feature "web" compiliert)
 // ---------------------------------------------------------------------------
 #[cfg(feature = "web")]
 mod wasm {
    use super::parse_dxf_summary;
    use wasm_bindgen::prelude::*;
    /// Initialisiert den Panic-Hook fuer bessere Fehlermeldungen im Browser.
    #[wasm_bindgen(start)]
    pub fn init_panic_hook() {
        console_error_panic_hook::set_once();
    }
    /// WASM-Fassade: nimmt einen Byte-Buffer (Uint8Array aus JS) und gibt ein
    /// JSON-String zurueck, das das DXF-Summary beschreibt.
    ///
    /// JS-Aufruf:
    /// ```js
    /// import init, { parse_dxf_summary_json } from './pkgDwgImport/dwgimport.js';
    /// await init();
    /// const json = parse_dxf_summary_json(new Uint8Array(buffer));
    /// ```
    #[wasm_bindgen]
    pub fn parse_dxf_summary_json(bytes: &[u8]) -> Result<String, JsValue> {
        parse_dxf_summary(bytes)
            .map_err(|e| JsValue::from_str(&e))
    }
 }
 // ---------------------------------------------------------------------------
 // Tests
 // ---------------------------------------------------------------------------
 #[cfg(test)]
 mod tests {
    use super::*;
    /// Minimales ASCII-DXF mit 3 LINE- und 2 CIRCLE-Entitaeten auf Layer "WAND"
    /// und Layer "0". Wird direkt als Byte-Slice eingebettet — kein Datei-IO.
    const MINI_DXF: &str = r#"  0
 SECTION
  2
 HEADER
  9
 $ACADVER
  1
 AC1015
  0
 ENDSEC
  0
 SECTION
  2
 TABLES
  0
 TABLE
  2
 LAYER
 70
     2
  0
 LAYER
  2
 0
 70
     0
 62
     7
  6
 Continuous
  0
 LAYER
  2
 WAND
 70
     0
 62
     3
  6
 Continuous
  0
 ENDTAB
  0
 ENDSEC
  0
 SECTION
  2
 ENTITIES
  0
 LINE
  8
 WAND
 10
 0.0
 20
 0.0
 30
 0.0
 11
 100.0
 21
 0.0
 31
 0.0
  0
 LINE
  8
 WAND
 10
 100.0
 20
 0.0
 30
 0.0
 11
 100.0
 21
 50.0
 31
 0.0
  0
 LINE
  8
 0
 10
 100.0
 20
 50.0
 30
 0.0
 11
 0.0
 21
 0.0
 31
 0.0
  0
 CIRCLE
  8
 WAND
 10
 50.0
 20
 25.0
 30
 0.0
 40
 10.0
  0
 CIRCLE
  8
 0
 10
 20.0
 20
 10.0
 30
 0.0
 40
 5.0
  0
 ENDSEC
  0
 EOF
 "#;
    #[test]
    fn test_parse_mini_dxf() {
        let result = parse_dxf_summary(MINI_DXF.as_bytes());
        assert!(result.is_ok(), "parse_dxf_summary schlug fehl: {:?}", result);
        let json = result.unwrap();
        println!("DXF-Summary:\n{json}");
        // Version muss AC1015 sein.
        assert!(json.contains("AC1015"), "Version AC1015 nicht im JSON: {json}");
        // Genau 5 Entitaeten: 3 LINE + 2 CIRCLE.
        assert!(
            json.contains("\"entityCount\": 5"),
            "entityCount soll 5 sein: {json}"
        );
        assert!(
            json.contains("\"LINE\": 3"),
            "LINE-Zaehler soll 3 sein: {json}"
        );
        assert!(
            json.contains("\"CIRCLE\": 2"),
            "CIRCLE-Zaehler soll 2 sein: {json}"
        );
        // Layer "WAND" und "0" muessen erscheinen.
        assert!(json.contains("\"WAND\""), "Layer WAND fehlt: {json}");
        assert!(json.contains("\"0\""), "Layer 0 fehlt: {json}");
    }
 }
@@ -2,9 +2,28 @@
 name = "geometry"
 version = "0.1.0"
 edition = "2021"
 description = "Serde-only Geometrie-Kern (Wand-Verschneidungen/Joins) — headless und per wasm-pack (Feature \"web\") zu WASM baubar; Single Source of Truth fuer TS + nativen Host."
 # cdylib: von wasm-pack (Feature "web") fuer das .wasm-Modul benoetigt. rlib:
 # damit die Crate weiterhin als Pfad-Abhaengigkeit (cad-tauri) und im Test-Build
 # nutzbar bleibt. Der cdylib-Artefakt-Build auf nativen Zielen ist harmlos (leere
 # Export-Oberflaeche ohne Feature "web"). Muster: render2d/render3d.
 [lib]
 crate-type = ["cdylib", "rlib"]
 [features]
 # Standard: reine serde-Geometrie, headless per `cargo test` pruefbar.
 default = []
 # Browser-Bindings: dieselbe Geometrie hinter einer wasm-bindgen-Fassade
 # (`compute_joins_json`), aus TS via wasm-pack aufgerufen. Baut nur fuer
 # target wasm32-unknown-unknown sinnvoll. Muster: render3d/Cargo.toml.
 web = ["dep:wasm-bindgen", "dep:serde_json", "dep:console_error_panic_hook"]
 [dependencies]
 serde = { version = "1", features = ["derive"] }
 serde_json = { version = "1", optional = true }
 wasm-bindgen = { version = "0.2", optional = true }
 console_error_panic_hook = { version = "0.1", optional = true }
 # Nur fuers Paritaets-Beispiel (examples/parity.rs) — JSON von stdin lesen.
 [dev-dependencies]
@@ -9,6 +9,20 @@
 use serde::{Deserialize, Serialize};
 /// Browser-Fassade (Feature "web"): JSON rein/raus, damit das TS-Frontend die
 /// EINE Rust-Join-Implementierung per wasm-pack aufrufen kann (Single Source of
 /// Truth statt TS-Duplikat). `input_json` = serialisiertes `JoinInput`, Rueckgabe
 /// = serialisiertes `Vec<WallCuts>`.
 #[cfg(feature = "web")]
 #[wasm_bindgen::prelude::wasm_bindgen]
 pub fn compute_joins_json(input_json: &str) -> Result<String, wasm_bindgen::JsValue> {
    console_error_panic_hook::set_once();
    let input: JoinInput = serde_json::from_str(input_json)
        .map_err(|e| wasm_bindgen::JsValue::from_str(&e.to_string()))?;
    let out = compute_joins(input);
    serde_json::to_string(&out).map_err(|e| wasm_bindgen::JsValue::from_str(&e.to_string()))
 }
 #[derive(Serialize, Deserialize, Clone, Copy)]
 pub struct Vec2 {
    pub x: f64,
@@ -67,6 +81,20 @@ pub struct LayerCuts {
    pub end_side: Vec<Option<Line>>,
 }
 /// Aussparung der DURCHGANGSWAND am materialbewussten T-Stoss -- Rust-Spiegel
 /// von `SpanCutout` aus `model/joins.ts`. `from`/`to` = Achsen-Intervall (Meter
 /// ab `wall.start`), `offA`/`offB` = Quer-Offsetbereich (Nah-Putz-Zone) in der
 /// Offset-Konvention der Schicht-Baender; `offA` ist stets die Nahflaeche.
 #[derive(Serialize, Deserialize, Clone, Copy)]
 pub struct SpanCutout {
    pub from: f64,
    pub to: f64,
    #[serde(rename = "offA")]
    pub off_a: f64,
    #[serde(rename = "offB")]
    pub off_b: f64,
 }
 /// Schnittlinien einer Wand an ihren beiden Achsenden.
 #[derive(Serialize, Deserialize)]
 pub struct WallCuts {
@@ -82,6 +110,11 @@ pub struct WallCuts {
    /// weiterhin `start_cut`/`end_cut` fuer alle Schichten.
    #[serde(rename = "layerCuts", skip_serializing_if = "Option::is_none")]
    pub layer_cuts: Option<LayerCuts>,
    /// ADDITIV (Durchgangswand-Seite): Nah-Putz-Aussparungen, durch die ein
    /// Abzweig-Kern sticht. Leer -> von serde bei Serialisierung weggelassen
    /// (`skip_serializing_if`), Wand wird unveraendert gezeichnet.
    #[serde(rename = "spanCutouts", skip_serializing_if = "Vec::is_empty")]
    pub span_cutouts: Vec<SpanCutout>,
 }
 /// Verschneidungs-Entscheidung zweier Bauteile am Stoss -- Rust-Spiegel von
@@ -135,6 +168,13 @@ fn apply_layer_cuts(
    through_dir: Vec2,
    sign: f64,
    off_t: f64,
    // Durchgangswand-Aussparung (Phase 1c): Index/Start der Durchgangswand,
    // Achsrichtung + Referenzversatz des Abzweigs -- fuer die Projektion der
    // Kernbreite auf die Durchgangsachse.
    through_wall_idx: usize,
    through_start: Vec2,
    branch_dir: Vec2,
    branch_ref_off: f64,
 ) {
    if branch_layers.is_empty() || through_layers.is_empty() {
        return;
@@ -199,17 +239,76 @@ fn apply_layer_cuts(
    let merge_cut = Line { point: merge_point, dir: through_dir };
    // Getrimmte Nachbarschichten schliessen mit ihrer L-Seitenlinie an dieser
-    // Rueckgrat-Nahflaeche ab (nicht an der Wandachse).
+    // Rueckgrat-Nahflaeche ab (nicht an der Wandachse). In einem Block, damit die
-    let side_line = merge_cut;
+    // mutable Ausleihe von `result[branch_wall_idx]` vor dem Zugriff auf die
-    let (face_arr, side_arr) = match branch_end {
+    // Durchgangswand unten endet.
-        WallEndKind::Start => (&mut lc.start, &mut lc.start_side),
+    // Nah-Putz-Komponenten der Durchgangswand (dieselbe sign-Seite wie
-        WallEndKind::End => (&mut lc.end, &mut lc.end_side),
+    // near_plaster oben): ist die getrimmte Abzweig-Schicht materialgleich mit
-    };
+    // einer davon, fuellt der Nah-Putz den Abzweig-Putz an dieser Stelle
-    for i in 0..n {
+    // durchgehend (spanCutout schneidet nur die KERN-Breite aus, nicht die
-        face_arr[i] = if merged[i] { Some(merge_cut) } else { Some(face_cut) };
+    // schmalen Putzflanken) -> Putz-L OHNE Trennnaht, also KEINE L-Seitenlinie.
-        let adj_merged =
+    let near_plaster_comps: Vec<&str> = through_layers
-            !merged[i] && ((i > 0 && merged[i - 1]) || (i + 1 < n && merged[i + 1]));
+        .iter()
-        side_arr[i] = if adj_merged { Some(side_line) } else { None };
+        .enumerate()
        .filter(|(i, _)| if sign > 0.0 { *i > backbone_idx } else { *i < backbone_idx })
        .map(|(_, l)| l.component_id.as_str())
        .collect();
    {
        let side_line = merge_cut;
        let (face_arr, side_arr) = match branch_end {
            WallEndKind::Start => (&mut lc.start, &mut lc.start_side),
            WallEndKind::End => (&mut lc.end, &mut lc.end_side),
        };
        for i in 0..n {
            face_arr[i] = if merged[i] { Some(merge_cut) } else { Some(face_cut) };
            let adj_merged =
                !merged[i] && ((i > 0 && merged[i - 1]) || (i + 1 < n && merged[i + 1]));
            let merges_with_near_plaster =
                near_plaster_comps.contains(&branch_layers[i].component_id.as_str());
            side_arr[i] = if adj_merged && !merges_with_near_plaster {
                Some(side_line)
            } else {
                None
            };
        }
    }
    // Durchgangswand-Aussparung (Phase 1c): den Nah-Putz der Durchgangswand ueber
    // die Breite des durchstechenden Abzweig-Kerns ECHT ausschneiden. Nur noetig,
    // wenn davor Nah-Putz liegt (near_plaster > 0).
    if near_plaster > 1e-9 {
        let total_branch: f64 = branch_layers.iter().map(|l| l.thickness).sum();
        let mut b_off = branch_ref_off - total_branch / 2.0;
        let mut core_lo = f64::INFINITY;
        let mut core_hi = f64::NEG_INFINITY;
        for (i, l) in branch_layers.iter().enumerate() {
            if merged[i] {
                if b_off < core_lo {
                    core_lo = b_off;
                }
                if b_off + l.thickness > core_hi {
                    core_hi = b_off + l.thickness;
                }
            }
            b_off += l.thickness;
        }
        if core_hi > core_lo {
            // Projektion der Kern-Offsethuelle auf die Durchgangsachse.
            let n_branch = left_normal(branch_dir);
            let proj = dot(n_branch, through_dir);
            let axis_at = dot(sub(axis_point, through_start), through_dir);
            let e1 = axis_at + core_lo * proj;
            let e2 = axis_at + core_hi * proj;
            let off_a = off_t + sign * (t_t / 2.0);
            let off_b = off_t + sign * (t_t / 2.0 - near_plaster);
            result[through_wall_idx].span_cutouts.push(SpanCutout {
                from: e1.min(e2),
                to: e1.max(e2),
                off_a,
                off_b,
            });
        }
    }
 }
@@ -305,6 +404,7 @@ pub fn compute_joins(input: JoinInput) -> Vec<WallCuts> {
            start_cut: None,
            end_cut: None,
            layer_cuts: None,
            span_cutouts: Vec::new(),
        })
        .collect();
@@ -485,6 +585,10 @@ fn apply_t_junction(
        u_t,
        sign,
        off_t,
        through_wall_idx,
        through_wall.start,
        dir_of(branch_wall),
        branch_wall.reference_offset,
    );
 }
@@ -575,6 +679,10 @@ fn apply_mid_span_tee(
        u_w,
        sign,
        off_w,
        w_idx,
        w.start,
        dir_of(free_wall),
        free_wall.reference_offset,
    );
 }
@@ -860,8 +968,8 @@ mod tests {
        // Wie t_junction_branch_gets_face_cut, aber alle drei Waende vom
        // W9-artigen Wandtyp: der Backstein-Kern (Index 1) sticht durch den
        // Nah-Putz und stoppt an der Kern-Nahflaeche (y=0.06), die beiden
-        // Innenputz-Schichten (Index 0/2) werden getrimmt und bekommen
+        // Innenputz-Schichten (Index 0/2) werden getrimmt. Da der Nah-Putz der
-        // zusaetzlich die seitliche L-Linie an derselben Flaeche.
+        // Durchgangswand materialgleich ist, entsteht KEINE L-Trennnaht.
        let input = JoinInput {
            walls: vec![
                w_iw("A", 0.0, 0.0, 5.0, 0.0),
@@ -896,18 +1004,54 @@ mod tests {
        let l2 = lc.start[2].expect("Schicht 2 getrimmt");
        assert!((l0.point.y - 0.075).abs() < 1e-9);
        assert!((l2.point.y - 0.075).abs() < 1e-9);
-        // ... UND die seitliche L-Linie an der Rueckgrat-Nahflaeche (y=0.06,
+        // ... aber KEINE seitliche L-Linie: der Innenputz der Durchgangswand ist
-        // parallel zur x-Achse).
+        // materialgleich und fuellt den getrimmten Abzweig-Putz durchgehend
-        let s0 = lc.start_side[0].expect("Schicht 0 hat L-Seitenlinie");
+        // (Putz-L ohne Trennnaht). Nur bei materialFREMDEM Nah-Putz stuende hier
-        let s2 = lc.start_side[2].expect("Schicht 2 hat L-Seitenlinie");
+        // eine L-Linie.
-        assert!(dist(s0, Vec2 { x: 5.0, y: 0.06 }) < 1e-9);
+        assert!(lc.start_side[0].is_none());
-        assert!(dist(s0, Vec2 { x: 0.0, y: 0.06 }) < 1e-9);
+        assert!(lc.start_side[2].is_none());
        assert!(dist(s2, Vec2 { x: 5.0, y: 0.06 }) < 1e-9);
-        // Die kollineare Durchgangswand bleibt unangetastet (kein layerCuts).
+        // Die kollineare Durchgangswand bleibt bei den layerCuts unangetastet.
        let ca = find(&out, "A");
        let cc = find(&out, "C");
        assert!(ca.layer_cuts.is_none());
        assert!(cc.layer_cuts.is_none());
        // ... bekommt aber die Durchgangswand-Aussparung (Phase 1c): die als
        // Durchgang gewaehlte Haelfte A wird ueber die Backstein-Kernbreite (0.12)
        // im Nah-Putz-Bereich (y in [0.06,0.075]) ausgeschnitten. Das Intervall
        // ist die Projektion der Kernbreite auf die Achse, zentriert am Knoten x=5.
        assert_eq!(ca.span_cutouts.len(), 1, "A (Durchgang) hat genau eine Aussparung");
        let sc = ca.span_cutouts[0];
        assert!((sc.from - 4.94).abs() < 1e-9, "from = 5 - 0.06");
        assert!((sc.to - 5.06).abs() < 1e-9, "to = 5 + 0.06");
        assert!(((sc.to - sc.from) - 0.12).abs() < 1e-9, "Intervallbreite = Kernbreite");
        assert!((sc.off_a - 0.075).abs() < 1e-9, "offA = Nahflaeche");
        assert!((sc.off_b - 0.06).abs() < 1e-9, "offB = Rueckgrat-Nahflaeche");
        // Der Abzweig B traegt keine Aussparung (die gehoert der Durchgangswand).
        assert!(cb.span_cutouts.is_empty());
    }
    #[test]
    fn mid_span_tee_through_wall_gets_span_cutout() {
        // Mittelspannen-T-Stoss (wie der reale W9-Fall): Durchgangswand W als EINE
        // Wand (0,0)->(10,0), Abzweig B trifft mit seinem freien Ende (4,0) mittig
        // auf ihre Seite. W bekommt EINE Aussparung um x=4, Breite = Kernbreite.
        let input = JoinInput {
            walls: vec![
                w_iw("W", 0.0, 0.0, 10.0, 0.0),
                w_iw("B", 4.0, 3.0, 4.0, 0.0),
            ],
        };
        let out = compute_joins(input);
        let cw = find(&out, "W");
        assert_eq!(cw.span_cutouts.len(), 1, "W hat genau eine Aussparung");
        let sc = cw.span_cutouts[0];
        assert!((sc.from - 3.94).abs() < 1e-9);
        assert!((sc.to - 4.06).abs() < 1e-9);
        assert!((sc.off_a - 0.075).abs() < 1e-9);
        assert!((sc.off_b - 0.06).abs() < 1e-9);
        // Der Abzweig selbst hat keine Aussparung.
        assert!(find(&out, "B").span_cutouts.is_empty());
    }
 }
@@ -0,0 +1,195 @@
 # This file is automatically @generated by Cargo.
 # It is not intended for manual editing.
 version = 4
 [[package]]
 name = "bumpalo"
 version = "3.20.3"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "72f5acc6cb2ba439de613abc23857ec3d78374d8ed5ac84e9d11336e87da8649"
 [[package]]
 name = "cfg-if"
 version = "1.0.4"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "9330f8b2ff13f34540b44e946ef35111825727b38d33286ef986142615121801"
 [[package]]
 name = "console_error_panic_hook"
 version = "0.1.7"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "a06aeb73f470f66dcdbf7223caeebb85984942f22f1adb2a088cf9668146bbbc"
 dependencies = [
 "cfg-if",
 "wasm-bindgen",
 ]
 [[package]]
 name = "itoa"
 version = "1.0.18"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "8f42a60cbdf9a97f5d2305f08a87dc4e09308d1276d28c869c684d7777685682"
 [[package]]
 name = "kernel2d"
 version = "0.1.0"
 dependencies = [
 "console_error_panic_hook",
 "robust",
 "serde",
 "serde_json",
 "wasm-bindgen",
 ]
 [[package]]
 name = "memchr"
 version = "2.8.2"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "88904434abc2901f197fe8cc55f0445e7ded921dba5911dad2e2b39b48e663c4"
 [[package]]
 name = "once_cell"
 version = "1.21.4"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "9f7c3e4beb33f85d45ae3e3a1792185706c8e16d043238c593331cc7cd313b50"
 [[package]]
 name = "proc-macro2"
 version = "1.0.106"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "8fd00f0bb2e90d81d1044c2b32617f68fcb9fa3bb7640c23e9c748e53fb30934"
 dependencies = [
 "unicode-ident",
 ]
 [[package]]
 name = "quote"
 version = "1.0.46"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "dfbc457d0c7a0759a614551b11a6409e5951f6c7537be1f1b7682b9ae9230368"
 dependencies = [
 "proc-macro2",
 ]
 [[package]]
 name = "robust"
 version = "1.2.0"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "4e27ee8bb91ca0adcf0ecb116293afa12d393f9c2b9b9cd54d33e8078fe19839"
 [[package]]
 name = "rustversion"
 version = "1.0.22"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "b39cdef0fa800fc44525c84ccb54a029961a8215f9619753635a9c0d2538d46d"
 [[package]]
 name = "serde"
 version = "1.0.228"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "9a8e94ea7f378bd32cbbd37198a4a91436180c5bb472411e48b5ec2e2124ae9e"
 dependencies = [
 "serde_core",
 "serde_derive",
 ]
 [[package]]
 name = "serde_core"
 version = "1.0.228"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "41d385c7d4ca58e59fc732af25c3983b67ac852c1a25000afe1175de458b67ad"
 dependencies = [
 "serde_derive",
 ]
 [[package]]
 name = "serde_derive"
 version = "1.0.228"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "d540f220d3187173da220f885ab66608367b6574e925011a9353e4badda91d79"
 dependencies = [
 "proc-macro2",
 "quote",
 "syn",
 ]
 [[package]]
 name = "serde_json"
 version = "1.0.150"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "e8014e44b4736ed0538adeecded0fce2a272f22dc9578a7eb6b2d9993c74cfb9"
 dependencies = [
 "itoa",
 "memchr",
 "serde",
 "serde_core",
 "zmij",
 ]
 [[package]]
 name = "syn"
 version = "2.0.118"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "1b9ae57f904213ebb649ce6895b8a66c66f0203b9319718f69a5612a065b1422"
 dependencies = [
 "proc-macro2",
 "quote",
 "unicode-ident",
 ]
 [[package]]
 name = "unicode-ident"
 version = "1.0.24"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "e6e4313cd5fcd3dad5cafa179702e2b244f760991f45397d14d4ebf38247da75"
 [[package]]
 name = "wasm-bindgen"
 version = "0.2.126"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "4b067c0c11094aef6b7a801c1e34a26affafdf3d051dba08456b868789aaf9a4"
 dependencies = [
 "cfg-if",
 "once_cell",
 "rustversion",
 "wasm-bindgen-macro",
 "wasm-bindgen-shared",
 ]
 [[package]]
 name = "wasm-bindgen-macro"
 version = "0.2.126"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "167ce5e579f6bcf889c4f7175a8a5a585de84e8ff93976ce393efa5f2837aab1"
 dependencies = [
 "quote",
 "wasm-bindgen-macro-support",
 ]
 [[package]]
 name = "wasm-bindgen-macro-support"
 version = "0.2.126"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "f3997c7839262f4ef12cf90b818d6340c18e80f263f1a94bf157d0ec4420380e"
 dependencies = [
 "bumpalo",
 "proc-macro2",
 "quote",
 "syn",
 "wasm-bindgen-shared",
 ]
 [[package]]
 name = "wasm-bindgen-shared"
 version = "0.2.126"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "dc1b4cb0cc549fcf58d7dfc081778139b3d283a081644e833e84682ad71cea24"
 dependencies = [
 "unicode-ident",
 ]
 [[package]]
 name = "zmij"
 version = "1.0.21"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "b8848ee67ecc8aedbaf3e4122217aff892639231befc6a1b58d29fff4c2cabaa"
@@ -0,0 +1,40 @@
 # Eigener leerer Workspace-Block: entkoppelt kernel2d vollstaendig vom
 # cad-tauri-Workspace (src-tauri/Cargo.toml), damit `cargo test`/`wasm-pack`
 # aus diesem Verzeichnis heraus nicht faelschlich dessen Workspace erben.
 # Muster: render2d/render3d. (Parent-`exclude` allein greift beim Bauen aus
 # dem Unterverzeichnis nicht zuverlaessig.)
 [workspace]
 [package]
 name = "kernel2d"
 version = "0.1.0"
 edition = "2021"
 description = "2D-Geometrie-Kern (Port von src/geometry/kernel2d.ts) — handgeschriebene f64-Mathematik, headless per `cargo test` UND per wasm-pack (Feature \"web\") zu WASM baubar. Hinter identischer TS-Fassade; TS-Legacy bleibt Differential-Referenz."
 # cdylib: von wasm-pack (Feature "web") fuer das .wasm-Modul. rlib: als
 # Pfad-Abhaengigkeit und fuer den Test-/Example-Build (parity). Muster:
 # render2d/render3d/geometry.
 [lib]
 crate-type = ["cdylib", "rlib"]
 [features]
 # Standard: reiner f64-Rechenkern, headless per `cargo test` pruefbar.
 default = []
 # Browser-Bindings: dieselbe Geometrie hinter wasm-bindgen-Batch-Fassaden,
 # aus TS via wasm-pack aufgerufen. Nur fuer wasm32-unknown-unknown sinnvoll.
 web = ["dep:wasm-bindgen", "dep:serde_json", "dep:console_error_panic_hook"]
 # ADDITIV, NICHT im web-Default: exakte Orientierungs-Praedikate (robust::orient2d)
 # nur intern fuer Korrektheits-Golden-Cases (detectRooms/point-in-polygon). Der
 # Zufalls-Diff-Test gegen TS-naiv laeuft OHNE dieses Feature (siehe PORT_PLAN §3).
 robust-predicates = ["dep:robust"]
 [dependencies]
 serde = { version = "1", features = ["derive"] }
 serde_json = { version = "1", optional = true }
 wasm-bindgen = { version = "0.2", optional = true }
 console_error_panic_hook = { version = "0.1", optional = true }
 robust = { version = "1", optional = true }
 # Nur fuers Paritaets-Beispiel (examples/parity.rs) — JSON von stdin lesen.
 [dev-dependencies]
 serde_json = "1"
@@ -32,6 +32,10 @@ fn l_wall_scene() -> (Vec<WallInput>, Vec<SlabInput>) {
                height: 1.0,
            }],
            layers: None,
            holes: vec![],
            material_index: None,
            hatch: None,
            cut: None,
        },
        WallInput {
            start: [0.0, 3.0],
@@ -42,6 +46,10 @@ fn l_wall_scene() -> (Vec<WallInput>, Vec<SlabInput>) {
            color,
            openings: vec![],
            layers: None,
            holes: vec![],
            material_index: None,
            hatch: None,
            cut: None,
        },
        // "Spaeh"-Wand: kurzer Stummel HINTER Schenkel A (groesseres Modell-X,
        // also groessere Tiefe von der Betrachter-Ebene aus), genau im
@@ -57,6 +65,10 @@ fn l_wall_scene() -> (Vec<WallInput>, Vec<SlabInput>) {
            color,
            openings: vec![],
            layers: None,
            holes: vec![],
            material_index: None,
            hatch: None,
            cut: None,
        },
    ];
    let slabs = vec![SlabInput {
@@ -64,6 +76,8 @@ fn l_wall_scene() -> (Vec<WallInput>, Vec<SlabInput>) {
        z_bottom: -0.2,
        z_top: 0.0,
        color: [0.86, 0.86, 0.88],
        hatch: None,
        cut: None,
    }];
    (walls, slabs)
 }
@@ -13,13 +13,14 @@
 use std::sync::Arc;
-use render3d::gpu::Renderer;
+use render3d::gpu::{RenderStyle, Renderer};
 use render3d::math::orbit_eye;
 use render3d::types::{Camera, Projection, WallInput};
 use winit::application::ApplicationHandler;
-use winit::event::{ElementState, MouseButton, MouseScrollDelta, WindowEvent};
+use winit::event::{ElementState, KeyEvent, MouseButton, MouseScrollDelta, WindowEvent};
 use winit::event_loop::{ActiveEventLoop, EventLoop};
 use winit::keyboard::{KeyCode, PhysicalKey};
 use winit::window::{Window, WindowId};
 /// Demo-Szene: ein rechteckiger Raum (4 Aussenwaende) plus eine Innenwand. Achsen
@@ -38,6 +39,10 @@ fn demo_walls() -> Vec<WallInput> {
        color: grey,
        openings: vec![],
        layers: None,
        holes: vec![],
        material_index: None,
        hatch: None,
        cut: None,
    };
    // Raum 6 x 4 m.
    vec![
@@ -195,6 +200,9 @@ struct App {
    orbit: Orbit,
    dragging: bool,
    last_cursor: (f64, f64),
    /// Darstellung: false = Shaded (Default, unveraendert), true = Textured
    /// (prozedurales Schachbrett auf den Wandflaechen). Per Taste `T` umschaltbar.
    textured: bool,
 }
 impl ApplicationHandler for App {
@@ -222,6 +230,27 @@ impl ApplicationHandler for App {
                state.resize(size.width, size.height);
                state.window.request_redraw();
            }
            WindowEvent::KeyboardInput {
                event:
                    KeyEvent {
                        physical_key: PhysicalKey::Code(KeyCode::KeyT),
                        state: ElementState::Pressed,
                        repeat: false,
                        ..
                    },
                ..
            } => {
                // `T` schaltet Shaded <-> Textured um (Laufzeit, kein Re-Meshing:
                // der Renderer haelt beide Vertex-Puffer bereit).
                self.textured = !self.textured;
                let style = if self.textured {
                    RenderStyle::Textured
                } else {
                    RenderStyle::Shaded
                };
                state.renderer.set_render_style(style);
                state.window.request_redraw();
            }
            WindowEvent::MouseInput { state: s, button, .. } => {
                if button == MouseButton::Left {
                    self.dragging = s == ElementState::Pressed;
@@ -91,11 +91,21 @@ fn dot(a: [f32; 3], b: [f32; 3]) -> f32 {
    a[0] * b[0] + a[1] * b[1] + a[2] * b[2]
 }
-/// Baut die Feature-Edge-LineList aus dem Mesh (siehe Moduldoc).
+/// Eine Kante samt ihrer deduplizierten Repraesentanten-Normalen (Rueckseiten
-///
+/// bereits gepaart, s. `representatives`). Grundlage BEIDER Kanten-Stile: die
-/// Ausgabe: interleaved `[px,py,pz, r,g,b, ...]`, je 2 Vertices = 1 Segment.
+/// statischen Feature-Edges (`build_mesh_edges`) UND die blickabhaengigen
-/// Leerer Vektor bei leerem/degeneriertem Mesh.
+/// Silhouetten-Konturen (`build_silhouette_edges`).
-pub fn build_mesh_edges(mesh: &Mesh) -> Vec<f32> {
+pub struct EdgeAdj {
    pub p0: [f32; 3],
    pub p1: [f32; 3],
    /// Flaechennormalen der (max. 2) angrenzenden Original-Dreiecke.
    pub reps: Vec<[f32; 3]>,
 }
 /// Baut die Kanten-Adjazenz aus dem Mesh: je eindeutiger Kante die Endpunkte +
 /// die deduplizierten Repraesentanten-Normalen. GPU-frei; einmalig bei `set_model`
 /// berechnet und gecacht (die Silhouette wird daraus je Blickwinkel neu abgeleitet).
 pub fn build_edge_adjacency(mesh: &Mesh) -> Vec<EdgeAdj> {
    if mesh.indices.len() < 3 {
        return Vec::new();
    }
@@ -137,20 +147,83 @@ pub fn build_mesh_edges(mesh: &Mesh) -> Vec<f32> {
        }
    }
-    let mut verts: Vec<f32> = Vec::new();
+    edges
-    let mut push = |p: [f32; 3]| {
+        .into_values()
-        verts.push(p[0]);
+        .map(|rec| EdgeAdj {
-        verts.push(p[1]);
+            p0: rec.p0,
-        verts.push(p[2]);
+            p1: rec.p1,
-        verts.push(EDGE_COLOR[0]);
+            reps: representatives(&rec.normals),
-        verts.push(EDGE_COLOR[1]);
+        })
-        verts.push(EDGE_COLOR[2]);
+        .collect()
-    };
+}
-    for rec in edges.values() {
+fn push_edge(verts: &mut Vec<f32>, p0: [f32; 3], p1: [f32; 3]) {
-        if should_draw(&rec.normals) {
+    for p in [p0, p1] {
-            push(rec.p0);
+        verts.extend_from_slice(&[p[0], p[1], p[2], EDGE_COLOR[0], EDGE_COLOR[1], EDGE_COLOR[2]]);
-            push(rec.p1);
+    }
 }
 /// Baut die Feature-Edge-LineList aus dem Mesh (siehe Moduldoc).
 ///
 /// Ausgabe: interleaved `[px,py,pz, r,g,b, ...]`, je 2 Vertices = 1 Segment.
 /// Leerer Vektor bei leerem/degeneriertem Mesh.
 pub fn build_mesh_edges(mesh: &Mesh) -> Vec<f32> {
    let adj = build_edge_adjacency(mesh);
    let mut verts: Vec<f32> = Vec::new();
    for a in &adj {
        if draws_crease(&a.reps) {
            push_edge(&mut verts, a.p0, a.p1);
        }
    }
    verts
 }
 /// Blickabhaengige Silhouetten-Konturen aus der gecachten Kanten-Adjazenz: gezeichnet
 /// werden Randkanten (nur ein Dreieck) UND echte Silhouetten-Kanten — solche, deren
 /// zwei angrenzende Flaechen aus Sicht der Kamera GEGENSAETZLICH orientiert sind
 /// (eine vorder-, eine rueckseitig). Ergebnis ist der reine Umriss (Gipsmodell-/
 /// Konturen-Look) ohne die inneren Knickkanten (Dachgrate). `eye` = Kameraposition
 /// (world), `forward` = Blickrichtung (world, von der Kamera ins Bild); `perspective`
 /// waehlt die pro-Kante-Blickrichtung (Perspektive) vs. die konstante (ortho).
 pub fn build_silhouette_edges(
    adj: &[EdgeAdj],
    eye: [f32; 3],
    forward: [f32; 3],
    perspective: bool,
 ) -> Vec<f32> {
    let mut verts: Vec<f32> = Vec::new();
    for a in adj {
        let draw = match a.reps.len() {
            0 => false,
            1 => true, // offene Randkante -> immer Teil der Kontur
            _ => {
                let mid = [
                    (a.p0[0] + a.p1[0]) * 0.5,
                    (a.p0[1] + a.p1[1]) * 0.5,
                    (a.p0[2] + a.p1[2]) * 0.5,
                ];
                // Blickvektor von der Flaeche ZUR Kamera. Perspektive: eye - mid;
                // ortho: entgegen der Blickrichtung (konstante Kamera).
                let view = if perspective {
                    sub(eye, mid)
                } else {
                    [-forward[0], -forward[1], -forward[2]]
                };
                let mut front = false;
                let mut back = false;
                for n in &a.reps {
                    let d = dot(*n, view);
                    if d > 0.0 {
                        front = true;
                    } else if d < 0.0 {
                        back = true;
                    }
                }
                front && back // Silhouette: eine Flaeche vorder-, eine rueckseitig
            }
        };
        if draw {
            push_edge(&mut verts, a.p0, a.p1);
        }
    }
    verts
@@ -159,15 +232,54 @@ pub fn build_mesh_edges(mesh: &Mesh) -> Vec<f32> {
 /// Entscheidet, ob eine Kante gezeichnet wird: Randkante (nur ein Dreieck) oder
 /// Knickkante (zwei angrenzende Dreiecke stehen ueber dem Crease-Winkel zuein-
 /// ander). Koplanare geteilte Kanten (Flaechendiagonalen) werden unterdrueckt.
-fn should_draw(normals: &[[f32; 3]]) -> bool {
+///
-    match normals.len() {
+/// DOPPELSEITIGE MESHES (Kontext/Dach/Fenster-Glas, s. `mesh.rs::push_ctx_tri` —
 /// jedes Dreieck wird dort MIT gespiegelter Rueckseite [-Normale] dupliziert,
 /// weil die Mesh-Pipeline Backface-Culling aktiv hat): jedes Original-Dreieck
 /// liefert dadurch IMMER ein exaktes +n/-n-Paar an jeder seiner Kanten. Ohne
 /// Beruecksichtigung wuerde das faelschlich als extremer Knick (dot ≈ -1)
 /// gewertet und JEDE Flaechen-Innendiagonale eines doppelseitigen Meshes
 /// gezeichnet (Nutzer-Report: Dreiecks-Diagonalen sichtbar auf Dach/Glas).
 /// Fix: zuerst Rueckseiten-Partner (dot ≈ -1 zueinander) einander zuordnen und
 /// nur EINEN Vertreter je Original-Dreieck behalten — danach greift dieselbe
 /// Rand-/Knick-Logik wie bei einseitigen Meshes (Waende), unabhaengig davon,
 /// ob doppelseitig gerendert wurde oder nicht.
 /// Dedupliziert die angrenzenden Normalen zu Repraesentanten: paart die von der
 /// doppelseitigen Emission stammenden Rueckseiten (dot ≈ -1) und behaelt je
 /// Original-Dreieck EINEN Vertreter (s. Moduldoc `should_draw`-Historie).
 fn representatives(normals: &[[f32; 3]]) -> Vec<[f32; 3]> {
    let mut reps: Vec<[f32; 3]> = Vec::new();
    let mut used = vec![false; normals.len()];
    for i in 0..normals.len() {
        if used[i] {
            continue;
        }
        used[i] = true;
        reps.push(normals[i]);
        for j in (i + 1)..normals.len() {
            if used[j] {
                continue;
            }
            if dot(normals[i], normals[j]) < -CREASE_COS {
                used[j] = true; // Rueckseiten-Duplikat desselben Dreiecks
                break;
            }
        }
    }
    reps
 }
 /// Entscheidet fuer die STATISCHEN Feature-Edges, ob eine Kante gezeichnet wird:
 /// Randkante (ein Repraesentant) oder Knickkante (zwei stehen ueber dem Crease-
 /// Winkel zueinander). Koplanare geteilte Kanten (Flaechendiagonalen) fallen weg.
 fn draws_crease(reps: &[[f32; 3]]) -> bool {
    match reps.len() {
        0 => false,
-        1 => true, // Silhouette/Rand: gehoert nur einem Dreieck
+        1 => true, // Silhouette/Rand: gehoert nur einem Original-Dreieck
        _ => {
-            // Zeichnen, sobald irgendein Normalen-Paar deutlich abknickt.
+            for i in 0..reps.len() {
-            for i in 0..normals.len() {
+                for j in (i + 1)..reps.len() {
-                for j in (i + 1)..normals.len() {
+                    if dot(reps[i], reps[j]) < CREASE_COS {
                    if dot(normals[i], normals[j]) < CREASE_COS {
                        return true;
                    }
                }
@@ -247,4 +359,186 @@ mod tests {
        let m = Mesh::default();
        assert!(build_mesh_edges(&m).is_empty());
    }
    /// Ein geschlossener Wuerfel: 8 Ecken, 12 Dreiecke (6 Flaechen, aussen).
    fn unit_cube() -> Mesh {
        let c = [
            [0.0, 0.0, 0.0],
            [1.0, 0.0, 0.0],
            [1.0, 1.0, 0.0],
            [0.0, 1.0, 0.0],
            [0.0, 0.0, 1.0],
            [1.0, 0.0, 1.0],
            [1.0, 1.0, 1.0],
            [0.0, 1.0, 1.0],
        ];
        #[rustfmt::skip]
        let idx: Vec<u32> = vec![
            0,3,2, 0,2,1, // -Z
            4,5,6, 4,6,7, // +Z
            0,1,5, 0,5,4, // -Y
            3,7,6, 3,6,2, // +Y
            0,4,7, 0,7,3, // -X
            1,2,6, 1,6,5, // +X
        ];
        mesh(&c, &idx)
    }
    #[test]
    fn cube_feature_edges_are_twelve() {
        // Statische Feature-Edges: die 12 Wuerfelkanten (Flaechendiagonalen weg).
        let e = build_mesh_edges(&unit_cube());
        assert_eq!(segment_count(&e), 12);
    }
    #[test]
    fn cube_silhouette_from_generic_view_is_hexagon() {
        // Aus einer generischen Ecken-Sicht ist die Silhouette eines Wuerfels ein
        // Sechseck = 6 Kanten (nur der Umriss, KEINE inneren Knickkanten).
        let adj = build_edge_adjacency(&unit_cube());
        let eye = [5.0, 6.0, 7.0];
        let fwd = normalize(sub([0.5, 0.5, 0.5], eye)); // Blick auf die Mitte
        let sil = build_silhouette_edges(&adj, eye, fwd, true);
        assert_eq!(segment_count(&sil), 6);
    }
    #[test]
    fn cube_silhouette_ortho_is_hexagon_too() {
        // Auch orthografisch (konstante Blickrichtung) ergibt sich das Sechseck.
        let adj = build_edge_adjacency(&unit_cube());
        let fwd = normalize([-1.0, -1.2, -1.4]);
        let sil = build_silhouette_edges(&adj, [0.0, 0.0, 0.0], fwd, false);
        assert_eq!(segment_count(&sil), 6);
    }
 }
 #[cfg(test)]
 mod double_sided_tests {
    // Deckt den Nutzer-Report ab (Dreiecks-Diagonalen sichtbar auf Dach/Glas):
    // Kontext-Meshes werden von `mesh.rs::push_ctx_tri` IMMER doppelseitig
    // aufgebaut (jedes Dreieck + gespiegelte Rueckseite [-Normale], weil die
    // Mesh-Pipeline Backface-Culling aktiv hat). Diese Tests bauen genau dieses
    // Muster nach (nicht die einfachen einseitigen Test-Meshes oben).
    use super::*;
    fn mesh_single_sided(positions: &[[f32; 3]], indices: &[u32]) -> Mesh {
        let mut verts = Vec::new();
        for p in positions {
            verts.extend_from_slice(&[p[0], p[1], p[2], 0.0, 1.0, 0.0, 0.8, 0.8, 0.8]);
        }
        Mesh { verts, indices: indices.to_vec() }
    }
    /// Baut ein Mesh wie `mesh_single_sided`, aber verdoppelt JEDES Dreieck mit
    /// umgekehrter Wicklung (a,c,b statt a,b,c) — exakt das Muster von
    /// `mesh.rs::push_ctx_tri` (Vorder- + Rueckseite fuer doppelseitiges Rendering).
    fn mesh_double_sided(positions: &[[f32; 3]], indices: &[u32]) -> Mesh {
        let mut verts = Vec::new();
        for p in positions {
            verts.extend_from_slice(&[p[0], p[1], p[2], 0.0, 1.0, 0.0, 0.8, 0.8, 0.8]);
        }
        let mut doubled = Vec::with_capacity(indices.len() * 2);
        for tri in indices.chunks_exact(3) {
            doubled.extend_from_slice(&[tri[0], tri[1], tri[2]]);
            doubled.extend_from_slice(&[tri[0], tri[2], tri[1]]); // gespiegelte Rueckseite
        }
        Mesh { verts, indices: doubled }
    }
    fn segment_count(v: &[f32]) -> usize {
        v.len() / EDGE_FLOATS_PER_VERTEX / 2
    }
    #[test]
    fn doubled_coplanar_quad_still_drops_shared_diagonal() {
        // Dasselbe ebene Quad wie coplanar_quad_drops_shared_diagonal, aber
        // doppelseitig aufgebaut — VOR dem Fix haette dies faelschlich 6 statt
        // 4 Segmente geliefert (Diagonale faelschlich als Knick erkannt).
        let m = mesh_double_sided(
            &[
                [0.0, 0.0, 0.0],
                [1.0, 0.0, 0.0],
                [1.0, 0.0, 1.0],
                [0.0, 0.0, 1.0],
            ],
            &[0, 1, 2, 0, 2, 3],
        );
        let e = build_mesh_edges(&m);
        assert_eq!(segment_count(&e), 4);
    }
    #[test]
    fn doubled_single_triangle_still_has_three_boundary_edges() {
        // Silhouette-Kanten eines EINZELNEN Dreiecks muessen trotz Verdopplung
        // (Vorder-/Rueckseite) weiterhin als Rand erkannt und gezeichnet werden.
        let m = mesh_double_sided(
            &[[0.0, 0.0, 0.0], [1.0, 0.0, 0.0], [0.0, 0.0, 1.0]],
            &[0, 1, 2],
        );
        let e = build_mesh_edges(&m);
        assert_eq!(segment_count(&e), 3);
    }
    #[test]
    fn doubled_folded_quad_still_keeps_crease() {
        // Echter 90°-Knick bleibt auch doppelseitig als Kante erhalten (keine
        // Ueberkompensation, die auch echte Knicke unterdruecken wuerde).
        let m = mesh_double_sided(
            &[
                [0.0, 0.0, 0.0],
                [1.0, 0.0, 0.0],
                [1.0, 0.0, 1.0],
                [1.0, 1.0, 0.0],
            ],
            &[0, 1, 2, 0, 3, 1],
        );
        let e = build_mesh_edges(&m);
        assert_eq!(segment_count(&e), 5);
    }
    #[test]
    fn real_opening_box_topology_suppresses_face_diagonals_doubled() {
        // Exakte Ecken-Reihenfolge/Indizes aus toWalls3d.ts::OPENING_BOX_TRIS,
        // diesmal ECHT doppelseitig wie im tatsaechlichen Render-Pfad (die
        // Fenster-Glas-/Rahmen-Boxen laufen ueber append_context_mesh).
        let from = 0.0f32;
        let to = 1.2f32;
        let z_bottom = 0.9f32;
        let z_top = 2.1f32;
        let n_min = -0.03f32;
        let n_max = 0.03f32;
        let mut positions = Vec::new();
        for i in 0..8u32 {
            let s = if i & 1 != 0 { to } else { from };
            let z = if i & 2 != 0 { z_top } else { z_bottom };
            let t = if i & 4 != 0 { n_max } else { n_min };
            positions.push([s, -t, z]);
        }
        let indices: Vec<u32> = vec![
            0, 1, 3, 0, 3, 2,
            4, 5, 7, 4, 7, 6,
            0, 1, 5, 0, 5, 4,
            2, 3, 7, 2, 7, 6,
            0, 2, 6, 0, 6, 4,
            1, 3, 7, 1, 7, 5,
        ];
        let m = mesh_double_sided(&positions, &indices);
        let e = build_mesh_edges(&m);
        // Ein Quader hat 12 echte Kanten (Silhouette); bei korrekter Diagonalen-
        // Unterdrueckung sollten es GENAU 12 sein (nicht 12+6 Diagonalen=18).
        assert_eq!(segment_count(&e), 12, "erwartet 12 Kanten (Quader-Silhouette), keine Flaechendiagonalen");
    }
    #[test]
    fn single_sided_helper_matches_module_level_mesh_helper() {
        // Absicherung: der lokale mesh_single_sided-Helfer verhaelt sich
        // identisch zum bestehenden `tests::mesh` (keine versehentliche
        // Abweichung beim Kopieren).
        let m = mesh_single_sided(
            &[[0.0, 0.0, 0.0], [1.0, 0.0, 0.0], [0.0, 0.0, 1.0]],
            &[0, 1, 2],
        );
        let e = build_mesh_edges(&m);
        assert_eq!(segment_count(&e), 3);
    }
 }
@@ -20,6 +20,7 @@ pub mod math;
 pub mod mesh;
 pub(crate) mod openings;
 pub mod section;
 pub mod section_boolean;
 pub mod section_fill;
 pub mod shaders;
 pub mod types;
@@ -38,23 +39,30 @@ pub use math::{
    view_matrix, view_projection, Mat4,
 };
 pub use mesh::{
-    append_context_mesh, build_model_mesh, build_scene_mesh, build_walls_mesh, extrude_slab,
+    append_context_mesh, build_model_mesh, build_scene_mesh, build_walls_mesh,
-    extrude_wall, triangulate,
+    build_walls_mesh_textured, extrude_slab, extrude_wall, textured_from_mesh, triangulate,
 };
 pub use section::{
    cut_section, ComponentKind, ComponentRef, CutPolygon, SectionEdge, SectionOutput, SectionPlane,
 };
 pub use types::{
-    Camera, CameraPreset, Mesh, MeshInput, MeshKind, Point2, Projection, Rgb, SlabInput, WallInput,
+    Camera, CameraPreset, Mesh, MeshInput, MeshKind, Point2, Projection, Rgb, SlabInput,
-    FLOATS_PER_VERTEX,
+    TexturedMesh, WallInput, FLOATS_PER_VERTEX, TEXTURED_FLOATS_PER_VERTEX,
 };
 // --- Tests: Mesh-Erzeugung (Muster wie render2d/tessellate) -------------------
 #[cfg(test)]
 mod tests {
-    use super::mesh::{build_walls_mesh, extrude_wall, INDICES_PER_BOX, VERTS_PER_BOX};
+    use super::mesh::{
-    use super::types::{Mesh, Opening, WallInput, WallLayer, FLOATS_PER_VERTEX};
+        build_free_wall_end_caps, build_scene_mesh_textured, build_walls_mesh,
        build_walls_mesh_textured, extrude_wall, INDICES_PER_BOX, VERTS_PER_BOX,
    };
    use super::section_fill::CAP_FLOATS_PER_VERTEX;
    use super::types::{
        Hatch, Hole, Mesh, Opening, WallInput, WallLayer, FLOATS_PER_VERTEX,
        TEXTURED_FLOATS_PER_VERTEX,
    };
    /// Bequemer Bau einer achsparallelen Wand entlang +X.
    fn wall_x(len: f32, thickness: f32, height: f32) -> WallInput {
@@ -67,6 +75,10 @@ mod tests {
            color: [0.8, 0.8, 0.8],
            openings: vec![],
            layers: None,
            holes: vec![],
            material_index: None,
            hatch: None,
            cut: None,
        }
    }
@@ -79,6 +91,67 @@ mod tests {
        )
    }
    #[test]
    fn texturierter_pfad_ist_geometrisch_deckungsgleich_mit_shaded() {
        // Der texturierte Wand-Pfad (`build_walls_mesh_textured`, [pos,normal,uv])
        // muss GEOMETRISCH bitgleich zum Alt-Pfad (`build_walls_mesh`,
        // [pos,normal,color]) sein: gleiche Vertex-/Index-Zahl und -Reihenfolge,
        // identische Positionen und Normalen. Nur der letzte Kanal (Farbe -> UV)
        // unterscheidet sich. So ist belegt, dass der additive UV-Kanal den
        // Alt-Pfad nicht beruehrt.
        let walls = [wall_x(3.0, 0.2, 2.5)];
        let shaded = build_walls_mesh(&walls);
        let tex = build_walls_mesh_textured(&walls);
        assert_eq!(tex.indices, shaded.indices, "Index-Puffer identisch");
        assert_eq!(
            tex.vertex_count(),
            shaded.vertex_count(),
            "gleiche Vertex-Zahl"
        );
        for i in 0..shaded.vertex_count() {
            let sb = i * FLOATS_PER_VERTEX;
            let tb = i * TEXTURED_FLOATS_PER_VERTEX;
            // Position (0..3) und Normale (3..6) bitgleich uebernommen.
            for k in 0..6 {
                assert_eq!(
                    shaded.verts[sb + k],
                    tex.verts[tb + k],
                    "Vertex {i} Kanal {k}: pos/normal muss identisch sein"
                );
            }
        }
    }
    #[test]
    fn texturierte_uv_ist_weltmassstaeblich() {
        // UV-Massstab: `u`/`v` in Metern (1 Kachel = 1 m). Fuer eine Wand entlang +X
        // liegt die +Z-Mantelflaeche bei Normale (0,0,1); dort ist die Tangente
        // t=(-n.z,0,n.x)=(-1,0,0), also u = -x und v = Hoehe. Die Deckflaeche
        // (Normale +Y) projiziert auf u=x, v=z. Wir pruefen, dass es UEBERHAUPT
        // Vertices mit v == Wandhoehe (2.5) bzw. v == 0 gibt (Hoehe wandert als v
        // mit) — belegt den weltmassstaeblichen Hoehen-Kanal.
        let tex = build_walls_mesh_textured(&[wall_x(3.0, 0.2, 2.5)]);
        let n = tex.vertex_count();
        let mut saw_top = false;
        let mut saw_bottom = false;
        for i in 0..n {
            let b = i * TEXTURED_FLOATS_PER_VERTEX;
            let ny = tex.verts[b + 4];
            let v = tex.verts[b + 7];
            // Nur Mantelflaechen (ny ~ 0) tragen die Hoehe als v.
            if ny.abs() < 0.5 {
                if (v - 2.5).abs() < 1e-5 {
                    saw_top = true;
                }
                if v.abs() < 1e-5 {
                    saw_bottom = true;
                }
            }
        }
        assert!(saw_top, "Mantel-Vertex mit v == Wandhoehe (2.5 m) erwartet");
        assert!(saw_bottom, "Mantel-Vertex mit v == 0 (Sockel) erwartet");
    }
    #[test]
    fn eine_wand_hat_quader_zaehlung() {
        // Eine Wand -> ein Quader: 24 Vertices, 36 Indizes (12 Dreiecke).
@@ -91,6 +164,65 @@ mod tests {
        assert!((max_idx as usize) < mesh.vertex_count());
    }
    /// `wall_x` mit gesetzter Bauteil-Schraffur (Voraussetzung fuer die Kappen).
    fn wall_x_hatched(len: f32, thickness: f32, height: f32) -> WallInput {
        WallInput {
            hatch: Some(Hatch { pattern: 3, angle: 45.0, scale: 1.0, line_weight: 0.13 }),
            ..wall_x(len, thickness, height)
        }
    }
    #[test]
    fn isolierte_wand_ohne_hatch_bekommt_keine_kappen() {
        // Bestehende Test-Fixtures (kein `hatch`) bleiben unangetastet: keine
        // Kappen-Geometrie, unabhaengig davon, dass beide Enden frei sind.
        let caps = build_free_wall_end_caps(&[wall_x(3.0, 0.2, 2.5)]);
        assert!(caps.is_empty());
    }
    #[test]
    fn isolierte_wand_mit_hatch_bekommt_kappen_an_beiden_freien_enden() {
        // Eine einzelne Wand hat KEINE Nachbarn -> beide Achsenenden sind frei ->
        // je Ende eine Schraffur-Kappe (1 Schicht x 2 Dreiecke x 3 Vertices = 6
        // Vertices je Ende, 12 insgesamt).
        let caps = build_free_wall_end_caps(&[wall_x_hatched(3.0, 0.2, 2.5)]);
        assert_eq!(caps.len() / CAP_FLOATS_PER_VERTEX, 12);
        // Jeder Kappen-Vertex traegt die Schraffur-Parameter (Muster 3 = crosshatch).
        for v in caps.chunks_exact(CAP_FLOATS_PER_VERTEX) {
            assert_eq!(v[5], 3.0, "pattern");
            assert!((v[6] - 45.0_f32.to_radians()).abs() < 1e-5, "angle_rad");
        }
    }
    #[test]
    fn verbundene_wandenden_bekommen_keine_kappe_dort() {
        // Zwei Waende treffen sich rechtwinklig bei (3,0) -> DIESES Ende ist bei
        // beiden Waenden NICHT frei (Gehrung/Anschluss), die beiden anderen
        // (freien) Enden bekommen weiterhin je eine Kappe -> 2 Kappen gesamt
        // (nicht 4), macht 12 Vertices statt 24.
        let a = wall_x_hatched(3.0, 0.2, 2.5); // (0,0) frei .. (3,0) verbunden
        let b = WallInput {
            start: [3.0, 0.0],
            end: [3.0, 4.0],
            ..wall_x_hatched(4.0, 0.2, 2.5) // (3,0) verbunden .. (3,4) frei
        };
        let caps = build_free_wall_end_caps(&[a, b]);
        assert_eq!(caps.len() / CAP_FLOATS_PER_VERTEX, 12, "nur die 2 freien Enden -> 2 Kappen");
    }
    #[test]
    fn t_stoss_bekommt_ebenfalls_keine_kappe_am_knoten() {
        // Drei Waende treffen sich am selben Punkt (T-Stoss, Gehrung bleibt
        // rechtwinklig, s. compute_wall_miters) -> trotzdem gilt der Knoten als
        // "beruehrt", KEINE der drei dortigen Enden bekommt eine Kappe.
        let a = wall_x_hatched(3.0, 0.2, 2.5); // endet bei (3,0)
        let b = WallInput { start: [3.0, 0.0], end: [3.0, 4.0], ..wall_x_hatched(4.0, 0.2, 2.5) };
        let c = WallInput { start: [3.0, 0.0], end: [6.0, 0.0], ..wall_x_hatched(3.0, 0.2, 2.5) };
        let caps = build_free_wall_end_caps(&[a, b, c]);
        // Freie Enden: a.start(0,0), b.end(3,4), c.end(6,0) -> 3 Kappen (nicht 6).
        assert_eq!(caps.len() / CAP_FLOATS_PER_VERTEX, 18);
    }
    #[test]
    fn mehrere_waende_addieren_sich() {
        let mesh = build_walls_mesh(&[
@@ -104,6 +236,10 @@ mod tests {
                color: [0.8, 0.8, 0.8],
                openings: vec![],
                layers: None,
                holes: vec![],
                material_index: None,
                hatch: None,
                cut: None,
            },
        ]);
        assert_eq!(mesh.vertex_count(), 2 * VERTS_PER_BOX);
@@ -182,6 +318,10 @@ mod tests {
            color: [0.8, 0.8, 0.8],
            openings: vec![],
            layers: None,
            holes: vec![],
            material_index: None,
            hatch: None,
            cut: None,
        };
        let mut mesh = Mesh::default();
        extrude_wall(&mut mesh, &w);
@@ -203,6 +343,10 @@ mod tests {
            color: [0.8, 0.8, 0.8],
            openings: vec![],
            layers: None,
            holes: vec![],
            material_index: None,
            hatch: None,
            cut: None,
        };
        let mesh = build_walls_mesh(&[w]);
        assert_eq!(mesh.vertex_count(), 0);
@@ -306,6 +450,97 @@ mod tests {
        assert_eq!(mesh.indices.len(), INDICES_PER_BOX);
    }
    // --- Echte Loecher in EINEM Wandkoerper (WallInput::holes) -----------------
    #[test]
    fn zwei_versetzte_ueberlappende_loecher_in_einem_koerper() {
        // KERNFALL: EINE Wand (Laenge 4, Hoehe 2.5) mit ZWEI Loechern, deren
        // Achsen-Intervalle sich UEBERLAPPEN, aber auf UNTERSCHIEDLICHER Hoehe
        // liegen — Fenster A u=[1.0,2.0] z=[0.9,2.1], Fenster B u=[1.5,2.5]
        // z=[0.3,0.7]. Das kann die Segment-Zerlegung nicht abbilden; als Loecher
        // in EINEM Koerper muss es sauber zerfallen (keine Geometrie in den
        // Loechern, Aussenmasse erhalten, beide Laibungen vollstaendig).
        let mut w = wall_x(4.0, 0.2, 2.5);
        w.holes = vec![
            Hole { from: 1.0, to: 2.0, z_bottom: 0.9, z_top: 2.1 },
            Hole { from: 1.5, to: 2.5, z_bottom: 0.3, z_top: 0.7 },
        ];
        let mesh = build_walls_mesh(&[w]);
        // Mehr als ein Vollkoerper (Loecher fuegen Teilrechtecke + Laibungen hinzu).
        assert!(mesh.vertex_count() > VERTS_PER_BOX);
        // Index-Integritaet.
        let max_idx = *mesh.indices.iter().max().unwrap();
        assert!((max_idx as usize) < mesh.vertex_count());
        // Aussenmasse unveraendert (die soliden Teilrechtecke decken den Rand ab).
        let (min, max) = mesh.bounds();
        assert!((min[0]).abs() < 1e-5 && (max[0] - 4.0).abs() < 1e-5, "u 0..4");
        assert!((min[1]).abs() < 1e-5 && (max[1] - 2.5).abs() < 1e-5, "z 0..2.5");
        assert!((min[2] + 0.1).abs() < 1e-5 && (max[2] - 0.1).abs() < 1e-5, "Dicke +/-0.1");
        // KEIN Vertex liegt (mit Sicherheitsabstand) im Inneren eines der Loecher.
        let holes = [(1.0f32, 2.0f32, 0.9f32, 2.1f32), (1.5, 2.5, 0.3, 0.7)];
        let m = 0.05;
        let n = mesh.vertex_count();
        for i in 0..n {
            let (p, _) = vert(&mesh, i);
            for (a0, a1, zb, zt) in holes {
                let inside =
                    p[0] > a0 + m && p[0] < a1 - m && p[1] > zb + m && p[1] < zt - m;
                assert!(!inside, "Vertex {i} bei {p:?} liegt im Loch [{a0},{a1}]x[{zb},{zt}]");
            }
        }
        // Beide Loecher besitzen ihre vier inneren Laibungen: fuer jede Loch-Kante
        // muss mindestens ein Vertex GENAU auf der Kante (in u bzw. z) UND im
        // jeweils anderen Loch-Intervall liegen (die Laibungsflaeche).
        let has_vert = |pred: &dyn Fn([f32; 3]) -> bool| (0..n).any(|i| pred(vert(&mesh, i).0));
        for (a0, a1, zb, zt) in holes {
            // linke/rechte Laibung: Vertex bei u==a0 bzw. u==a1, z im Loch.
            assert!(
                has_vert(&|p| (p[0] - a0).abs() < 1e-4 && p[1] > zb - 1e-4 && p[1] < zt + 1e-4),
                "linke Laibung fehlt fuer Loch [{a0},{a1}]"
            );
            assert!(
                has_vert(&|p| (p[0] - a1).abs() < 1e-4 && p[1] > zb - 1e-4 && p[1] < zt + 1e-4),
                "rechte Laibung fehlt fuer Loch [{a0},{a1}]"
            );
            // untere/obere Laibung: Vertex bei z==zb bzw. z==zt, u im Loch.
            assert!(
                has_vert(&|p| (p[1] - zb).abs() < 1e-4 && p[0] > a0 - 1e-4 && p[0] < a1 + 1e-4),
                "untere Laibung fehlt fuer Loch [{a0},{a1}]"
            );
            assert!(
                has_vert(&|p| (p[1] - zt).abs() < 1e-4 && p[0] > a0 - 1e-4 && p[0] < a1 + 1e-4),
                "obere Laibung fehlt fuer Loch [{a0},{a1}]"
            );
        }
    }
    #[test]
    fn tuer_loch_bis_zum_boden_ohne_untere_laibung() {
        // Tuer-Loch reicht bis zum Boden (z_bottom == base_elevation 0): die
        // untere Kante liegt am Wandrand -> KEINE untere Laibung, stattdessen eine
        // Luecke im Boden-Streifen. Unter der Kopfhoehe (z_top 2.1) darf im
        // Tuerbereich keine Geometrie liegen.
        let mut w = wall_x(4.0, 0.2, 2.5);
        w.holes = vec![Hole { from: 1.0, to: 1.8, z_bottom: 0.0, z_top: 2.1 }];
        let mesh = build_walls_mesh(&[w]);
        let n = mesh.vertex_count();
        let m = 0.05;
        for i in 0..n {
            let (p, _) = vert(&mesh, i);
            let in_span = p[0] > 1.0 + m && p[0] < 1.8 - m;
            if in_span {
                assert!(
                    p[1] < m || p[1] > 2.1 - 1e-4,
                    "Vertex {i} bei {p:?} liegt unter der Tuer-Kopfhoehe im Loch"
                );
            }
        }
    }
    // --- Ecken-Verschneidung (Gehrung) -----------------------------------------
    #[test]
@@ -325,6 +560,10 @@ mod tests {
            color: [0.8, 0.8, 0.8],
            openings: vec![],
            layers: None,
            holes: vec![],
            material_index: None,
            hatch: None,
            cut: None,
        };
        let b = WallInput {
            start: [0.0, 0.0],
@@ -335,6 +574,10 @@ mod tests {
            color: [0.8, 0.8, 0.8],
            openings: vec![],
            layers: None,
            holes: vec![],
            material_index: None,
            hatch: None,
            cut: None,
        };
        let mesh = build_walls_mesh(&[a, b]);
        assert_eq!(mesh.vertex_count(), 2 * VERTS_PER_BOX, "weiterhin zwei Quader");
@@ -394,6 +637,10 @@ mod tests {
            color: [0.8, 0.8, 0.8],
            openings: vec![],
            layers: None,
            holes: vec![],
            material_index: None,
            hatch: None,
            cut: None,
        };
        let walls = vec![
            mk([0.0, 0.0], [3.0, 0.0]),
@@ -422,6 +669,10 @@ mod tests {
            color: [0.8, 0.8, 0.8],
            openings: vec![],
            layers: None,
            holes: vec![],
            material_index: None,
            hatch: None,
            cut: None,
        };
        let walls = vec![
            mk([0.0, 0.0], [3.0, 0.0], 0.0),
@@ -510,6 +761,10 @@ mod tests {
            color: [0.8, 0.8, 0.8],
            openings: vec![],
            layers: layers(),
            holes: vec![],
            material_index: None,
            hatch: None,
            cut: None,
        };
        let mut b = a.clone();
        b.end = [0.0, 3.0];
@@ -540,6 +795,8 @@ mod tests {
            z_bottom,
            z_top,
            color: [0.86, 0.86, 0.88],
            hatch: None,
            cut: None,
        }
    }
@@ -596,6 +853,8 @@ mod tests {
            z_bottom: 0.0,
            z_top: 0.3,
            color: [0.8, 0.8, 0.8],
            hatch: None,
            cut: None,
        };
        let mut mesh = Mesh::default();
        extrude_slab(&mut mesh, &slab);
@@ -624,7 +883,7 @@ mod tests {
    fn entarteter_slab_erzeugt_nichts() {
        let mut mesh = Mesh::default();
        // <3 Ecken.
-        extrude_slab(&mut mesh, &SlabInput { outline: vec![[0.0, 0.0], [1.0, 0.0]], z_bottom: 0.0, z_top: 0.2, color: [0.8, 0.8, 0.8] });
+        extrude_slab(&mut mesh, &SlabInput { outline: vec![[0.0, 0.0], [1.0, 0.0]], z_bottom: 0.0, z_top: 0.2, color: [0.8, 0.8, 0.8], hatch: None, cut: None });
        assert_eq!(mesh.vertex_count(), 0);
        // Nullhoehe.
        extrude_slab(&mut mesh, &square_slab(4.0, 2.6, 2.6));
@@ -643,6 +902,8 @@ mod tests {
            indices: vec![0, 1, 2],
            kind,
            color,
            material_index: None,
            vertex_colors: Vec::new(),
        }
    }
@@ -684,6 +945,73 @@ mod tests {
        assert_eq!([mesh2.verts[6], mesh2.verts[7], mesh2.verts[8]], [0.1, 0.2, 0.3]);
    }
    #[test]
    fn context_mesh_pro_vertex_farbe_wird_uebernommen() {
        // Luftbild-Drape: jeder Vertex traegt eine eigene Farbe. Wird 1:1 an die
        // Ausgabe-Vertices durchgereicht (statt der Einzelfarbe).
        let mut mesh = Mesh::default();
        append_context_mesh(
            &mut mesh,
            &MeshInput {
                positions: vec![0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0],
                indices: vec![0, 1, 2],
                kind: MeshKind::Terrain,
                color: None,
                material_index: None,
                vertex_colors: vec![
                    1.0, 0.0, 0.0, // Vertex 0 rot
                    0.0, 1.0, 0.0, // Vertex 1 gruen
                    0.0, 0.0, 1.0, // Vertex 2 blau
                ],
            },
        );
        // Vorderseite = erste 3 Vertices (Winding a,b,c): Farben 0,1,2.
        assert_eq!([mesh.verts[6], mesh.verts[7], mesh.verts[8]], [1.0, 0.0, 0.0]);
        assert_eq!([mesh.verts[15], mesh.verts[16], mesh.verts[17]], [0.0, 1.0, 0.0]);
        assert_eq!([mesh.verts[24], mesh.verts[25], mesh.verts[26]], [0.0, 0.0, 1.0]);
        // Zu kurzes vertex_colors-Array -> Einzelfarbe (kein Panic, kein Teilbezug).
        let mut mesh2 = Mesh::default();
        append_context_mesh(
            &mut mesh2,
            &MeshInput {
                positions: vec![0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0],
                indices: vec![0, 1, 2],
                kind: MeshKind::Terrain,
                color: None,
                material_index: None,
                vertex_colors: vec![1.0, 0.0, 0.0], // nur 1 Vertex -> ignoriert
            },
        );
        assert_eq!(
            [mesh2.verts[6], mesh2.verts[7], mesh2.verts[8]],
            MeshKind::Terrain.default_color()
        );
    }
    #[test]
    fn kontext_mesh_materialindex_wandert_in_die_textured_layer() {
        // Daecher (und potenziell andere Kontext-Meshes) koennen jetzt einen
        // Material-Textur-Index tragen (`MeshInput::material_index`) — vorher
        // war er fuer ALLE Kontext-Meshes hart auf -1 (Schachbrett) gesetzt, der
        // Stil „Textured" konnte also nie eine echte Dachziegel-Textur zeigen.
        let m = MeshInput {
            positions: vec![0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0],
            indices: vec![0, 1, 2],
            kind: MeshKind::Extrusion,
            color: None,
            material_index: Some(2),
            vertex_colors: Vec::new(),
        };
        let tex = build_scene_mesh_textured(&[], &[], std::slice::from_ref(&m));
        assert!(!tex.layers.is_empty());
        assert!(tex.layers.iter().all(|&l| l == 2.0), "alle Vertices Ebene 2");
        // Ohne material_index bleibt der Fallback (-1 -> Schachbrett).
        let m2 = MeshInput { material_index: None, ..m };
        let tex2 = build_scene_mesh_textured(&[], &[], std::slice::from_ref(&m2));
        assert!(tex2.layers.iter().all(|&l| l == -1.0));
    }
    #[test]
    fn context_mesh_ueberspringt_kaputte_indizes_und_entartung() {
        let mut mesh = Mesh::default();
@@ -695,6 +1023,8 @@ mod tests {
                indices: vec![0, 1, 9],
                kind: MeshKind::Imported,
                color: None,
                material_index: None,
                vertex_colors: Vec::new(),
            },
        );
        assert_eq!(mesh.vertex_count(), 0);
@@ -706,6 +1036,8 @@ mod tests {
                indices: vec![0, 1, 2],
                kind: MeshKind::Imported,
                color: None,
                material_index: None,
                vertex_colors: Vec::new(),
            },
        );
        assert_eq!(mesh.vertex_count(), 0);
@@ -797,6 +1129,51 @@ mod tests {
        assert!(top.eye[1] > t[1], "Top-Kamera ueber dem Ziel");
    }
    #[test]
    fn presets_kardinal_back_left_sind_orthografisch_und_gegenrichtung() {
        use super::math::preset_camera;
        use super::types::{CameraPreset, Projection};
        let t = [0.0, 0.0, 0.0];
        let front = preset_camera(CameraPreset::Front, t, 10.0);
        let back = preset_camera(CameraPreset::Back, t, 10.0);
        let side = preset_camera(CameraPreset::Side, t, 10.0);
        let left = preset_camera(CameraPreset::Left, t, 10.0);
        assert_eq!(back.projection, Projection::Orthographic);
        assert_eq!(left.projection, Projection::Orthographic);
        // Back/Left sind exakt die Gegenrichtung von Front/Side (gespiegelte Achse).
        assert!((back.eye[2] - (-front.eye[2])).abs() < 1e-4, "Back == -Front (Z)");
        assert!((left.eye[0] - (-side.eye[0])).abs() < 1e-4, "Left == -Side (X)");
    }
    #[test]
    fn presets_iso_oktanten_sind_orthografisch_gleich_gross() {
        use super::math::preset_camera;
        use super::types::{CameraPreset, Projection};
        let t = [0.0, 0.0, 0.0];
        let dist = 10.0;
        let iso = preset_camera(CameraPreset::Iso, t, dist);
        let fl = preset_camera(CameraPreset::IsoFrontLeft, t, dist);
        let br = preset_camera(CameraPreset::IsoBackRight, t, dist);
        let bl = preset_camera(CameraPreset::IsoBackLeft, t, dist);
        for cam in [&iso, &fl, &br, &bl] {
            assert_eq!(cam.projection, Projection::Orthographic);
            // Alle vier oberen Iso-Oktanten haben denselben eye-target-Abstand
            // (Modell erscheint in jedem Oktanten gleich gross).
            let d = ((cam.eye[0] - t[0]).powi(2)
                + (cam.eye[1] - t[1]).powi(2)
                + (cam.eye[2] - t[2]).powi(2))
            .sqrt();
            assert!((d - dist).abs() < 1e-3, "Iso-Oktant-Abstand == dist");
            // Alle vier blicken von OBEN (Y > 0) — untere Oktanten bleiben ungenutzt.
            assert!(cam.eye[1] > t[1], "Iso-Oktant ueber dem Ziel");
        }
        // Vier unterschiedliche horizontale Vorzeichen-Kombinationen (X,Z).
        assert!(iso.eye[0] > t[0] && iso.eye[2] > t[2]); // vorne-rechts
        assert!(fl.eye[0] < t[0] && fl.eye[2] > t[2]); // vorne-links
        assert!(br.eye[0] > t[0] && br.eye[2] < t[2]); // hinten-rechts
        assert!(bl.eye[0] < t[0] && bl.eye[2] < t[2]); // hinten-links
    }
    /// Validiert die WGSL-Quelle headless ueber naga (Parser + Validator) — faengt
    /// Syntax-/Typfehler ohne GPU/Display ab. Nur mit Feature "render", weil naga
    /// sonst nicht mitgebaut wird (Muster: render2d).
@@ -827,5 +1204,23 @@ mod tests {
        Validator::new(ValidationFlags::all(), Capabilities::all())
            .validate(&cap_module)
            .unwrap_or_else(|e| panic!("cap: WGSL-Validierung fehlgeschlagen: {e:?}"));
        // Texturierter Wand-Shader (RenderStyle::Textured, Bild-Textur in group 1)
        // ebenso headless validieren — faengt Textur-/Sampler-Bindungsfehler ab.
        let tex_src = super::shaders::MESH_TEXTURED_WGSL;
        let tex_module = naga::front::wgsl::parse_str(tex_src)
            .unwrap_or_else(|e| panic!("textured: WGSL-Parse-Fehler: {e:?}"));
        Validator::new(ValidationFlags::all(), Capabilities::all())
            .validate(&tex_module)
            .unwrap_or_else(|e| panic!("textured: WGSL-Validierung fehlgeschlagen: {e:?}"));
        // Luftbild-Drape-Shader (Terrain-Overlay, Bild-Textur + Bbox-Uniform in
        // group 1) ebenso headless validieren.
        let aerial_src = super::shaders::MESH_AERIAL_WGSL;
        let aerial_module = naga::front::wgsl::parse_str(aerial_src)
            .unwrap_or_else(|e| panic!("aerial: WGSL-Parse-Fehler: {e:?}"));
        Validator::new(ValidationFlags::all(), Capabilities::all())
            .validate(&aerial_module)
            .unwrap_or_else(|e| panic!("aerial: WGSL-Validierung fehlgeschlagen: {e:?}"));
    }
 }
@@ -185,15 +185,26 @@ pub fn orbit_eye(target: [f32; 3], yaw: f32, pitch: f32, dist: f32) -> [f32; 3]
    ]
 }
-/// Baut eine `Camera` fuer eines der fuenf Presets der three.js-Sicht. `target`
+/// Baut eine `Camera` fuer eines der Kardinal-/Iso-Presets (ROADMAP §11).
-/// ist das Blickziel (Modell-Mitte), `dist` der Abstand. Front/Top/Side/Iso
+/// `target` ist das Blickziel (Modell-Mitte), `dist` der Abstand. Alle Presets
-/// sind orthografisch (Front/Top/Side achsparallel, Iso diagonal); nur Persp
+/// ausser `Persp` sind orthografisch (Front/Back/Top/Side/Left achsparallel,
-/// ist perspektivisch.
+/// die Iso-Varianten diagonal); nur Persp ist perspektivisch.
 ///
 /// Achs-Konvention (wie die three.js-Sicht, s. `applyView3d` in Viewport3D.tsx):
 /// +Z = vorne (Front blickt von +Z entlang -Z), +X = rechts (Side blickt von
 /// +X entlang -X). Back/Left sind exakt die Gegenrichtungen (-Z/-X); es gibt
 /// noch KEINEN Nordwinkel — die Kardinalrichtungen sind rein modellrelativ
 /// (Vorne/Rechts/Hinten/Links im UI, keine Himmelsrichtungen).
 pub fn preset_camera(preset: CameraPreset, target: [f32; 3], dist: f32) -> Camera {
    let mut cam = Camera {
        target,
        ..Camera::default()
    };
    // Iso-Distanz-Helfer: Augenabstand-Komponente je Achse, sodass der
    // tatsaechliche eye-target-Abstand exakt `dist` bleibt (d*sqrt(3) == dist,
    // wie bei den bisherigen Front/Top/Side-Presets), damit alle Iso-Varianten
    // das Modell gleich gross zeigen.
    let iso_d = dist / 3.0_f32.sqrt();
    match preset {
        // Blick entlang -Z (von vorne), orthografisch.
        CameraPreset::Front => {
@@ -202,6 +213,13 @@ pub fn preset_camera(preset: CameraPreset, target: [f32; 3], dist: f32) -> Camer
            cam.up = [0.0, 1.0, 0.0];
            cam.ortho_half_height = dist * 0.5;
        }
        // Blick entlang +Z (von hinten) — Gegenrichtung von Front.
        CameraPreset::Back => {
            cam.projection = Projection::Orthographic;
            cam.eye = [target[0], target[1], target[2] - dist];
            cam.up = [0.0, 1.0, 0.0];
            cam.ortho_half_height = dist * 0.5;
        }
        // Blick von oben entlang -Y (Grundriss), orthografisch. Up = -Z, damit
        // Modell-Y (world +Z) im Bild nach unten zeigt (wie die 2D-Plan-Sicht).
        CameraPreset::Top => {
@@ -210,24 +228,48 @@ pub fn preset_camera(preset: CameraPreset, target: [f32; 3], dist: f32) -> Camer
            cam.up = [0.0, 0.0, -1.0];
            cam.ortho_half_height = dist * 0.5;
        }
-        // Blick entlang -X (von der Seite), orthografisch.
+        // Blick entlang -X (von der rechten Seite), orthografisch.
        CameraPreset::Side => {
            cam.projection = Projection::Orthographic;
            cam.eye = [target[0] + dist, target[1], target[2]];
            cam.up = [0.0, 1.0, 0.0];
            cam.ortho_half_height = dist * 0.5;
        }
-        // Isometrischer Ueberblick (orthografisch, Blick von schraeg oben).
+        // Blick entlang +X (von der linken Seite) — Gegenrichtung von Side.
        CameraPreset::Left => {
            cam.projection = Projection::Orthographic;
            cam.eye = [target[0] - dist, target[1], target[2]];
            cam.up = [0.0, 1.0, 0.0];
            cam.ortho_half_height = dist * 0.5;
        }
        // Isometrischer Ueberblick von vorne-oben-rechts (Default-Iso).
        // Echte Isometrie ist per Definition parallelprojiziert (keine
        // perspektivische Verzerrung, Kantenlaengen bleiben massstabsgetreu).
        CameraPreset::Iso => {
            cam.projection = Projection::Orthographic;
-            let d = dist / 3.0_f32.sqrt();
+            cam.eye = [target[0] + iso_d, target[1] + iso_d, target[2] + iso_d];
-            cam.eye = [target[0] + d, target[1] + d, target[2] + d];
+            cam.up = [0.0, 1.0, 0.0];
            cam.ortho_half_height = dist * 0.5;
        }
        // Isometrischer Ueberblick von vorne-oben-links.
        CameraPreset::IsoFrontLeft => {
            cam.projection = Projection::Orthographic;
            cam.eye = [target[0] - iso_d, target[1] + iso_d, target[2] + iso_d];
            cam.up = [0.0, 1.0, 0.0];
            cam.ortho_half_height = dist * 0.5;
        }
        // Isometrischer Ueberblick von hinten-oben-rechts.
        CameraPreset::IsoBackRight => {
            cam.projection = Projection::Orthographic;
            cam.eye = [target[0] + iso_d, target[1] + iso_d, target[2] - iso_d];
            cam.up = [0.0, 1.0, 0.0];
            cam.ortho_half_height = dist * 0.5;
        }
        // Isometrischer Ueberblick von hinten-oben-links.
        CameraPreset::IsoBackLeft => {
            cam.projection = Projection::Orthographic;
            cam.eye = [target[0] - iso_d, target[1] + iso_d, target[2] - iso_d];
            cam.up = [0.0, 1.0, 0.0];
            // eye-target-Abstand ist hier (wie bei Front/Top/Side) exakt
            // `dist` (d*sqrt(3) == dist), darum dieselbe Skalierung wie dort,
            // damit das Modell im Bild aehnlich gross erscheint.
            cam.ortho_half_height = dist * 0.5;
        }
        // Freie perspektivische Standard-Ansicht (leicht von vorn-oben-rechts).
@@ -59,7 +59,8 @@ use std::collections::HashMap;
 use crate::openings::{split_range_by_voids, MIN_SPAN};
 use crate::types::{
-    Mesh, MeshInput, Opening, Point2, Rgb, SlabInput, WallInput, WallLayer, FLOATS_PER_VERTEX,
+    Hole, Mesh, MeshInput, Opening, Point2, Rgb, SlabInput, TexturedMesh, WallInput, WallLayer,
    FLOATS_PER_VERTEX, TEXTURED_FLOATS_PER_VERTEX,
 };
 /// Ein Quader-Mesh besteht aus 6 Seiten (Boden, Deckel, 4 Waende) zu je 2
@@ -109,7 +110,16 @@ fn extrude_wall_with_miters(mesh: &mut Mesh, wall: &WallInput, miters: WallMiter
    let z0 = wall.base_elevation;
    let z1 = wall.base_elevation + wall.height;
-    let segments = wall_solid_segments(length, &wall.openings, z0, z1);
+    // Mit echten Loechern (`holes`) wird die Wand NICHT an Oeffnungen segmentiert,
    // sondern als EIN voller Achsen-Abschnitt extrudiert; die Loecher stanzt
    // `extrude_layer_segment_with_holes` in die Langseiten (holes/openings
    // schliessen sich aus, siehe `types::WallInput::holes`).
    let has_holes = !wall.holes.is_empty();
    let segments = if has_holes {
        vec![(0.0, length, z0, z1)]
    } else {
        wall_solid_segments(length, &wall.openings, z0, z1)
    };
    // Schicht-Stapel: ohne `layers` (oder leer) EIN synthetisches Layer aus
    // der Gesamtdicke/-Farbe — bitgenau das bisherige Vollkoerper-Verhalten.
@@ -139,10 +149,20 @@ fn extrude_wall_with_miters(mesh: &mut Mesh, wall: &WallInput, miters: WallMiter
            // Wandende grenzen (innere Laibungs-Teilstuecke bleiben eckig).
            let start_cut = if a0 <= 1e-6 { miters.start } else { None };
            let end_cut = if a1 >= length - 1e-6 { miters.end } else { None };
-            extrude_layer_segment(
+            if has_holes {
-                mesh, wall, n, length, a0, a1, y0, y1, off_a, off_b, start_cut, end_cut,
+                // Voller Achsen-Abschnitt (a0=0, a1=length) mit echten Loechern
-                layer.color,
+                // in den Langseiten — pro Schicht-Band dieselben Loecher (quer
-            );
+                // gestapelt bilden ihre Laibungen die volle Loch-Tiefe).
                extrude_layer_segment_with_holes(
                    mesh, wall, n, length, y0, y1, off_a, off_b, start_cut, end_cut, layer.color,
                    &wall.holes,
                );
            } else {
                extrude_layer_segment(
                    mesh, wall, n, length, a0, a1, y0, y1, off_a, off_b, start_cut, end_cut,
                    layer.color,
                );
            }
        }
        off_a = off_b;
    }
@@ -284,6 +304,328 @@ fn extrude_layer_segment(
    push_quad(mesh, b3, b0, t0, t3, start_normal, color);
 }
 /// Haengt ein Quad (vier Ecken als Ring, beliebige Reihenfolge) als zwei
 /// orientierte Dreiecke an — Winding via `push_tri_oriented` an `want_normal`
 /// ausgerichtet (robust gegen die Eck-Reihenfolge, anders als `push_quad`).
 /// Genutzt fuer die Loch-Zerlegung (Langseiten-Teilrechtecke, Deckel-/Boden-
 /// Streifen, Laibungen), wo die Ecken aus Gitter-Koordinaten kommen.
 fn push_quad_oriented(
    mesh: &mut Mesh,
    a: [f32; 3],
    b: [f32; 3],
    c: [f32; 3],
    d: [f32; 3],
    want_normal: [f32; 3],
    color: Rgb,
 ) {
    push_tri_oriented(mesh, a, b, c, want_normal, color);
    push_tri_oriented(mesh, a, c, d, want_normal, color);
 }
 /// Zerlegt das Rechteck `[u_lo,u_hi] x [z_lo,z_hi]` MINUS der `holes`
 /// (`(u0,u1,z0,z1)`) in achsparallele, paarweise disjunkte Teilrechtecke (die
 /// SOLIDEN Bereiche). Verfahren: Koordinaten-Kompression — alle Loch-Kanten in u
 /// und z bilden ein Gitter; jede Gitterzelle, deren Mittelpunkt in KEINEM Loch
 /// liegt, ist ein solides Teilrechteck. Dadurch koennen sich Loecher in u
 /// ueberlappen und auf unterschiedlicher Hoehe liegen (Kernfall zweier versetzt
 /// uebereinanderliegender Fenster), ohne dass degenerierte oder ueberlappende
 /// Teilrechtecke entstehen.
 fn solid_subrects(
    u_lo: f32,
    u_hi: f32,
    z_lo: f32,
    z_hi: f32,
    holes: &[(f32, f32, f32, f32)],
 ) -> Vec<(f32, f32, f32, f32)> {
    let sort_dedup = |mut v: Vec<f32>| -> Vec<f32> {
        v.sort_by(|a, b| a.partial_cmp(b).unwrap());
        v.dedup_by(|a, b| (*a - *b).abs() <= MIN_SPAN);
        v
    };
    let mut us = vec![u_lo, u_hi];
    let mut zs = vec![z_lo, z_hi];
    for (a0, a1, hb, ht) in holes {
        us.push(*a0);
        us.push(*a1);
        zs.push(*hb);
        zs.push(*ht);
    }
    let us = sort_dedup(us);
    let zs = sort_dedup(zs);
    let mut out = Vec::new();
    for i in 0..us.len().saturating_sub(1) {
        let (ua, ub) = (us[i], us[i + 1]);
        if ub - ua <= MIN_SPAN {
            continue;
        }
        for j in 0..zs.len().saturating_sub(1) {
            let (za, zb) = (zs[j], zs[j + 1]);
            if zb - za <= MIN_SPAN {
                continue;
            }
            let cu = (ua + ub) * 0.5;
            let cz = (za + zb) * 0.5;
            let in_hole = holes
                .iter()
                .any(|(a0, a1, hb, ht)| cu > *a0 && cu < *a1 && cz > *hb && cz < *ht);
            if !in_hole {
                out.push((ua, ub, za, zb));
            }
        }
    }
    out
 }
 /// Zieht die (ggf. ueberlappenden) `gaps` vom Intervall `[lo,hi]` ab und liefert
 /// die verbleibenden Teilintervalle (sortiert, disjunkt). Fuer die Deckel-/
 /// Boden-/Kappen-Flaechen, in denen ein randstaendiges Loch eine Luecke reisst.
 fn subtract_intervals(lo: f32, hi: f32, gaps: &[(f32, f32)]) -> Vec<(f32, f32)> {
    let mut gs: Vec<(f32, f32)> = gaps
        .iter()
        .map(|(a, b)| (a.max(lo), b.min(hi)))
        .filter(|(a, b)| b - a > MIN_SPAN)
        .collect();
    gs.sort_by(|a, b| a.0.partial_cmp(&b.0).unwrap());
    let mut out = Vec::new();
    let mut cursor = lo;
    for (a, b) in gs {
        if a > cursor + MIN_SPAN {
            out.push((cursor, a));
        }
        cursor = cursor.max(b);
    }
    if hi > cursor + MIN_SPAN {
        out.push((cursor, hi));
    }
    out
 }
 /// Extrudiert EIN Schicht-Band (volle Achse `0..length`, Hoehe `[y0,y1]`,
 /// Dicken-Versatz `[off_a,off_b]`) mit ECHTEN rechteckigen LOECHERN (`holes`,
 /// siehe `types::Hole`) statt der Oeffnungs-Segmentierung. Aufbau:
 ///  • Langseiten (+n bei `off_a`, −n bei `off_b`): das Flaechen-Rechteck MINUS
 ///    der Loecher, per `solid_subrects` in Teilrechtecke zerlegt (je 2 Dreiecke).
 ///  • Deckel (`y1`) / Boden (`y0`): voller Streifen minus der u-Intervalle der
 ///    Loecher, die die jeweilige Kante beruehren (z. B. eine Tuer am Boden).
 ///  • End-Kappen (`a=0`/`a=length`, gemitert): volle Hoehe minus der z-Intervalle
 ///    randstaendiger Loecher (Loecher liegen normalerweise im Inneren → volle
 ///    Kappe, unveraendert gegenueber der Gehrung).
 ///  • Laibungen je Loch: vier Quads (links/rechts/unten/oben) — aber nur fuer die
 ///    Seiten, die im Wand-INNEREN liegen (die randstaendige Seite hat stattdessen
 ///    die Luecke in Deckel/Boden/Kappe, keine Laibung).
 /// Winding/Normalen konsistent ueber `push_quad_oriented`/`push_tri_oriented`
 /// (Backface-Culling + Beleuchtung korrekt).
 #[allow(clippy::too_many_arguments)]
 fn extrude_layer_segment_with_holes(
    mesh: &mut Mesh,
    wall: &WallInput,
    n: Point2,
    length: f32,
    y0: f32,
    y1: f32,
    off_a: f32,
    off_b: f32,
    start_cut: Option<MiterLine>,
    end_cut: Option<MiterLine>,
    color: Rgb,
    holes: &[Hole],
 ) {
    let ux = wall.end[0] - wall.start[0];
    let uz = wall.end[1] - wall.start[1];
    let ul = (ux * ux + uz * uz).sqrt().max(1e-9);
    let u: Point2 = [ux / ul, uz / ul];
    let off = |p: Point2, s: f32| -> Point2 { [p[0] + n[0] * s, p[1] + n[1] * s] };
    let clip = |base: Point2, cut: Option<MiterLine>| -> Point2 {
        match cut {
            None => base,
            Some(c) => line_intersect_2(base, u, c.point, c.dir).unwrap_or(base),
        }
    };
    // Plan-Punkt bei Achsen-Position `a`, Dicken-Versatz `offv`; NUR an den echten
    // Wandenden (a≈0 / a≈length) gegen die Gehrungslinie verschnitten — innere
    // Loch-Kanten bleiben rechtwinklig (unabhaengig von der Gehrung).
    let g_at = |a: f32, offv: f32| -> Point2 {
        let base = off(axis_point(wall, length, a), offv);
        if a <= 1e-6 {
            clip(base, start_cut)
        } else if a >= length - 1e-6 {
            clip(base, end_cut)
        } else {
            base
        }
    };
    let w = |g: Point2, y: f32| -> [f32; 3] { [g[0], y, g[1]] };
    // Loecher auf [0,length] x [y0,y1] klemmen, entartete verwerfen.
    let mut hs: Vec<(f32, f32, f32, f32)> = Vec::new();
    for h in holes {
        let a0 = h.from.max(0.0);
        let a1 = h.to.min(length);
        let zb = h.z_bottom.max(y0);
        let zt = h.z_top.min(y1);
        if a1 - a0 > MIN_SPAN && zt - zb > MIN_SPAN {
            hs.push((a0, a1, zb, zt));
        }
    }
    // ── Langseiten (+n / −n): Rechteck-Gitter minus Loecher. ──────────────────
    let np = [n[0], 0.0, n[1]];
    let nn = [-n[0], 0.0, -n[1]];
    for (ua, ub, za, zb) in solid_subrects(0.0, length, y0, y1, &hs) {
        push_quad_oriented(
            mesh,
            w(g_at(ua, off_a), za),
            w(g_at(ub, off_a), za),
            w(g_at(ub, off_a), zb),
            w(g_at(ua, off_a), zb),
            np,
            color,
        );
        push_quad_oriented(
            mesh,
            w(g_at(ua, off_b), za),
            w(g_at(ub, off_b), za),
            w(g_at(ub, off_b), zb),
            w(g_at(ua, off_b), zb),
            nn,
            color,
        );
    }
    // ── Deckel (y1) und Boden (y0): voller Streifen minus randstaendiger Loecher.
    let top_gaps: Vec<(f32, f32)> = hs
        .iter()
        .filter(|(_, _, _, zt)| *zt >= y1 - MIN_SPAN)
        .map(|(a0, a1, _, _)| (*a0, *a1))
        .collect();
    for (ua, ub) in subtract_intervals(0.0, length, &top_gaps) {
        push_quad_oriented(
            mesh,
            w(g_at(ua, off_a), y1),
            w(g_at(ub, off_a), y1),
            w(g_at(ub, off_b), y1),
            w(g_at(ua, off_b), y1),
            [0.0, 1.0, 0.0],
            color,
        );
    }
    let bot_gaps: Vec<(f32, f32)> = hs
        .iter()
        .filter(|(_, _, zb, _)| *zb <= y0 + MIN_SPAN)
        .map(|(a0, a1, _, _)| (*a0, *a1))
        .collect();
    for (ua, ub) in subtract_intervals(0.0, length, &bot_gaps) {
        push_quad_oriented(
            mesh,
            w(g_at(ua, off_a), y0),
            w(g_at(ub, off_a), y0),
            w(g_at(ub, off_b), y0),
            w(g_at(ua, off_b), y0),
            [0.0, -1.0, 0.0],
            color,
        );
    }
    // ── End-Kappen (a=0 / a=length): volle Hoehe minus randstaendiger Loecher. ─
    // Aussen-Normale je Kappe geometrisch aus den vollen Kappen-Ecken (wie im
    // rechtwinkligen/gehrten Fall in `extrude_layer_segment`).
    let start_normal = quad_normal(
        w(g_at(0.0, off_b), y0),
        w(g_at(0.0, off_a), y0),
        w(g_at(0.0, off_b), y1),
    );
    let start_gaps: Vec<(f32, f32)> = hs
        .iter()
        .filter(|(a0, _, _, _)| *a0 <= MIN_SPAN)
        .map(|(_, _, zb, zt)| (*zb, *zt))
        .collect();
    for (za, zb) in subtract_intervals(y0, y1, &start_gaps) {
        push_quad_oriented(
            mesh,
            w(g_at(0.0, off_b), za),
            w(g_at(0.0, off_a), za),
            w(g_at(0.0, off_a), zb),
            w(g_at(0.0, off_b), zb),
            start_normal,
            color,
        );
    }
    let end_normal = quad_normal(
        w(g_at(length, off_a), y0),
        w(g_at(length, off_b), y0),
        w(g_at(length, off_a), y1),
    );
    let end_gaps: Vec<(f32, f32)> = hs
        .iter()
        .filter(|(_, a1, _, _)| *a1 >= length - MIN_SPAN)
        .map(|(_, _, zb, zt)| (*zb, *zt))
        .collect();
    for (za, zb) in subtract_intervals(y0, y1, &end_gaps) {
        push_quad_oriented(
            mesh,
            w(g_at(length, off_a), za),
            w(g_at(length, off_b), za),
            w(g_at(length, off_b), zb),
            w(g_at(length, off_a), zb),
            end_normal,
            color,
        );
    }
    // ── Laibungen je Loch: nur die im Wand-Inneren liegenden Seiten. ──────────
    for &(a0, a1, zb, zt) in &hs {
        // Linke Laibung (bei a0), Normale +u (in die Oeffnung).
        if a0 > MIN_SPAN {
            push_quad_oriented(
                mesh,
                w(g_at(a0, off_a), zb),
                w(g_at(a0, off_b), zb),
                w(g_at(a0, off_b), zt),
                w(g_at(a0, off_a), zt),
                [u[0], 0.0, u[1]],
                color,
            );
        }
        // Rechte Laibung (bei a1), Normale −u.
        if a1 < length - MIN_SPAN {
            push_quad_oriented(
                mesh,
                w(g_at(a1, off_a), zb),
                w(g_at(a1, off_b), zb),
                w(g_at(a1, off_b), zt),
                w(g_at(a1, off_a), zt),
                [-u[0], 0.0, -u[1]],
                color,
            );
        }
        // Untere Laibung (bei zb = Bruestungsoberkante), Normale +Y.
        if zb > y0 + MIN_SPAN {
            push_quad_oriented(
                mesh,
                w(g_at(a0, off_a), zb),
                w(g_at(a1, off_a), zb),
                w(g_at(a1, off_b), zb),
                w(g_at(a0, off_b), zb),
                [0.0, 1.0, 0.0],
                color,
            );
        }
        // Obere Laibung (bei zt = Sturzunterkante), Normale −Y.
        if zt < y1 - MIN_SPAN {
            push_quad_oriented(
                mesh,
                w(g_at(a0, off_a), zt),
                w(g_at(a1, off_a), zt),
                w(g_at(a1, off_b), zt),
                w(g_at(a0, off_b), zt),
                [0.0, -1.0, 0.0],
                color,
            );
        }
    }
 }
 /// Aussen-Normale eines planaren, CCW-von-aussen georderten Quads `(a,b,_,d)`
 /// (nur die drei ersten Ecken werden gebraucht: `d` ist die vierte, ueber `a`
 /// benachbarte Ecke). `cross(b-a, d-a)` — Herleitung/Verifikation siehe
@@ -493,6 +835,160 @@ fn compute_wall_miters(walls: &[WallInput]) -> Vec<WallMiters> {
    out
 }
 /// Ermittelt je Wand, ob ihr Start-/Endpunkt ein FREIES Ende ist — d. h. KEIN
 /// anderes Wandende (auch kein T-/X-Stoss) trifft sich dort im selben
 /// Hoehenbereich. Dieselbe Punkt-Rundung + Hoehen-Ueberlappungs-Clustering wie
 /// `compute_wall_miters`, aber OHNE dessen Zwei-Wandenden-Einschraenkung: jeder
 /// Cluster der Groesse ≥ 2 (Gehrung ODER T-/X-Stoss) gilt als "beruehrt", nur
 /// ein isolierter Cluster der Groesse 1 (nur die Wand selbst) bleibt frei.
 /// Grundlage der Schraffur-Kappen an unverbundenen Wandenden
 /// (`build_free_wall_end_caps`) — ein Wandende "ohne Anschluss" (Nutzer-Begriff)
 /// zeigt dort die Bauteil-Schraffur statt der Flaechenfarbe, wie ein echter
 /// Schnitt.
 fn compute_free_wall_ends(walls: &[WallInput]) -> Vec<(bool, bool)> {
    let mut out = vec![(true, true); walls.len()];
    let mut ends: Vec<EndRef> = Vec::with_capacity(walls.len() * 2);
    for (i, w) in walls.iter().enumerate() {
        let n = left_normal(w.start, w.end);
        if n == [0.0, 0.0] {
            continue; // entartete Wand: weder Ende gilt als "frei" (irrelevant)
        }
        let dir: Point2 = [n[1], -n[0]];
        let z0 = w.base_elevation;
        let z1 = w.base_elevation + w.height;
        ends.push(EndRef { wall: i, is_start: true, point: w.start, dir, z0, z1 });
        ends.push(EndRef { wall: i, is_start: false, point: w.end, dir, z0, z1 });
    }
    let mut groups: HashMap<(i64, i64), Vec<usize>> = HashMap::new();
    for (idx, e) in ends.iter().enumerate() {
        groups.entry(round_key(e.point)).or_default().push(idx);
    }
    for members in groups.into_values() {
        if members.len() < 2 {
            continue; // einziges Ende an diesem Punkt -> bleibt frei (Default)
        }
        for cluster in cluster_by_height_overlap(&ends, &members) {
            if cluster.len() < 2 {
                continue; // eigener, hoehenmaessig isolierter Cluster -> frei
            }
            for &idx in &cluster {
                let e = &ends[idx];
                if e.is_start {
                    out[e.wall].0 = false;
                } else {
                    out[e.wall].1 = false;
                }
            }
        }
    }
    out
 }
 /// Haengt EINE Schraffur-Kappe (alle Schicht-Baender gestapelt) an einem
 /// Wand-Achsenende an `verts` an — Vertex-Format identisch zu
 /// `section_fill::build_cut_caps` (`CAP_FLOATS_PER_VERTEX`), damit dieselbe
 /// `cap_pipeline`/`CAP_WGSL` sie zeichnen kann. `(u,v)` = (Quer-Versatz `s` zur
 /// Wandachse, Welt-Hoehe) — metrisch, an den Schicht-Grenzen stetig.
 #[allow(clippy::too_many_arguments)]
 fn push_wall_end_cap(
    verts: &mut Vec<f32>,
    point: Point2,
    n: Point2,
    layers: &[WallLayer],
    total: f32,
    y0: f32,
    y1: f32,
    pattern: f32,
    angle_rad: f32,
    scale: f32,
    line_weight: f32,
 ) {
    let corner = |s: f32, y: f32| -> [f32; 9] {
        let p = [point[0] + n[0] * s, point[1] + n[1] * s];
        [p[0], y, p[1], s, y, pattern, angle_rad, scale, line_weight]
    };
    let mut off_a = total * 0.5;
    for layer in layers {
        let off_b = off_a - layer.thickness;
        let c0 = corner(off_a, y0);
        let c1 = corner(off_b, y0);
        let c2 = corner(off_b, y1);
        let c3 = corner(off_a, y1);
        // Fan-Triangulierung des Quads (Winding egal, cap_pipeline kennt kein
        // Backface-Culling — siehe section_fill.rs-Moduldoc).
        verts.extend_from_slice(&c0);
        verts.extend_from_slice(&c1);
        verts.extend_from_slice(&c2);
        verts.extend_from_slice(&c0);
        verts.extend_from_slice(&c2);
        verts.extend_from_slice(&c3);
        off_a = off_b;
    }
 }
 /// Schraffur-Kappen an FREIEN Wandenden (kein Anschluss an eine andere Wand,
 /// s. `compute_free_wall_ends`): additive, ZWEITE Geometrie neben der
 /// (unveraendert weiterhin flach eingefaerbten) End-Kappe der normalen
 /// Extrusion — gezeichnet mit Tiefen-Bias VOR der Flaeche (analog dem
 /// Luftbild-Overlay `gpu::aerial_pipeline`), sodass sie diese optisch
 /// ueberdeckt, OHNE `extrude_layer_segment` selbst anzufassen (kein
 /// Regressionsrisiko fuer bestehende Vollkoerper-Tests). Nur Waende MIT
 /// explizit gesetzter `hatch` (Bauteil-Schraffur, `toWalls3d.ts` loest sie je
 /// Materialschicht auf) bekommen eine Kappe — ohne `hatch` (z. B. alle
 /// bestehenden Test-Fixtures) bleibt das Alt-Verhalten unangetastet. Bildet NUR
 /// die echten Achsen-Enden ab (Wandanfang/-ende), keine Oeffnungs-Laibungen —
 /// "Wand endet an Decke" (vertikale Terminierung) ist bewusst NICHT Teil dieser
 /// Kappen (separates, noch offenes Thema).
 pub fn build_free_wall_end_caps(walls: &[WallInput]) -> Vec<f32> {
    let free_ends = compute_free_wall_ends(walls);
    let mut verts: Vec<f32> = Vec::new();
    for (wi, wall) in walls.iter().enumerate() {
        let Some(hatch) = wall.hatch else { continue };
        let (free_start, free_end) = free_ends[wi];
        if !free_start && !free_end {
            continue;
        }
        let n = left_normal(wall.start, wall.end);
        if n == [0.0, 0.0] || wall.height <= 1e-6 {
            continue;
        }
        let y0 = wall.base_elevation;
        let y1 = wall.base_elevation + wall.height;
        let synthetic;
        let layers: &[WallLayer] = match &wall.layers {
            Some(ls) if !ls.is_empty() => ls.as_slice(),
            _ => {
                synthetic = [WallLayer { thickness: wall.thickness, color: wall.color }];
                &synthetic
            }
        };
        let total: f32 = layers.iter().map(|l| l.thickness).sum();
        let pattern = hatch.pattern as f32;
        let angle_rad = hatch.angle.to_radians();
        let scale = hatch.scale.max(0.05);
        let line_weight = hatch.line_weight.max(0.0);
        if free_start {
            push_wall_end_cap(
                &mut verts, wall.start, n, layers, total, y0, y1, pattern, angle_rad, scale,
                line_weight,
            );
        }
        if free_end {
            push_wall_end_cap(
                &mut verts, wall.end, n, layers, total, y0, y1, pattern, angle_rad, scale,
                line_weight,
            );
        }
    }
    verts
 }
 /// Grundriss-Fussabdruck EINER Wand (die vier Band-Eckpunkte g0..g3 in CCW),
 /// an ihren echten Achsenenden ggf. gehrt — bitgenau dieselbe Ecken-Konstruktion
 /// wie `extrude_layer_segment` fuer das Vollstueck (Einzel-Layer, keine
@@ -575,6 +1071,131 @@ pub fn build_walls_mesh(walls: &[WallInput]) -> Mesh {
    mesh
 }
 /// TEXTURIERTER Wand-Pfad (`RenderStyle::Textured`): liefert DIESELBE Geometrie wie
 /// `build_walls_mesh` — Positionen und Normalen bitgleich, gleiche Vertex-/Dreiecks-
 /// Reihenfolge — aber mit einer planaren, WELTMASSSTAEBLICHEN UV je Vertex statt der
 /// Bauteilfarbe. Bewusst ALS ABLEITUNG aus dem fertigen `Mesh` implementiert (nicht
 /// als parallele Re-Extrusion): so bleibt die paritaets-/reihenfolgesensible
 /// Geometrie (Gehrungen, Oeffnungen, Loecher, Schichten) die EINE Quelle der
 /// Wahrheit und der Alt-Pfad `[pos, normal, color]` bleibt bitgleich unangetastet —
 /// wir tauschen nur den color-Kanal gegen den aus Position+Normale abgeleiteten
 /// UV-Kanal aus.
 ///
 /// UV-PROJEKTION (planar, in Metern, damit das Textur-Raster weltmassstaeblich ist,
 /// z. B. 1 Kachel = 1 m; kein Verzug an Gehrungen/Ecken, weil jede Flaeche planar
 /// projiziert wird und benachbarte Waende dieselbe Welt-Projektion fortsetzen —
 /// die Kacheln stossen im Weltraum sauber aneinander):
 ///   - Senkrechte Flaechen (Wand-Mantel, Normale ~ horizontal): `u` = Weglaenge
 ///     entlang der horizontalen Flaechen-Tangente `t = (-n.z, 0, n.x)`
 ///     (`u = dot(pos.xz, t.xz)`), `v` = Hoehe `pos.y`.
 ///   - Waagerechte Flaechen (Deckel/Boden, Normale ~ +/-Y): direkt aus dem
 ///     Grundriss `u = pos.x`, `v = pos.z`.
 /// Die Wahl der Achse allein aus der Flaechen-Normale (statt aus der Wand-Achse)
 /// haelt die Projektion rein lokal je Vertex — das ist genau der Grund, warum sie
 /// sich verlustfrei aus dem fertigen `Mesh` ableiten laesst.
 pub fn build_walls_mesh_textured(walls: &[WallInput]) -> TexturedMesh {
    // Ueber den Szenen-Builder (ohne Decken/Kontext) — so traegt der Puffer auch
    // die Material-Ebenen je Wand (`layers`), waehrend Geometrie/UV bitgleich zu
    // `textured_from_mesh(&build_walls_mesh(walls))` bleiben.
    build_scene_mesh_textured(walls, &[], &[])
 }
 /// Rechnet ein `Mesh` (`[pos, normal, color]`) in einen `TexturedMesh`
 /// (`[pos, normal, uv]`) um: Positionen/Normalen/Indizes werden 1:1 uebernommen,
 /// die Farbe je Vertex wird durch die planare Welt-UV ersetzt (siehe
 /// `build_walls_mesh_textured` fuer die Achswahl). Indizes bleiben unveraendert,
 /// weil sich die Vertex-Anzahl/-Reihenfolge nicht aendert. `pub`, damit die
 /// GPU-Schicht (`gpu.rs`) das texturierte Pendant AUS DEMSELBEN `Mesh` ableiten
 /// kann, das sie ohnehin schon gebaut/hochgeladen hat (eine Geometrie-Quelle).
 pub fn textured_from_mesh(mesh: &Mesh) -> TexturedMesh {
    let n = mesh.vertex_count();
    let mut verts: Vec<f32> = Vec::with_capacity(n * TEXTURED_FLOATS_PER_VERTEX);
    for i in 0..n {
        let b = i * FLOATS_PER_VERTEX;
        let px = mesh.verts[b];
        let py = mesh.verts[b + 1];
        let pz = mesh.verts[b + 2];
        let nx = mesh.verts[b + 3];
        let ny = mesh.verts[b + 4];
        let nz = mesh.verts[b + 5];
        // Waagerecht (Deckel/Boden) vs. senkrecht (Mantel) an der Vertikal-
        // Komponente der Normale unterscheiden. Waende sind vertikal extrudiert,
        // ihre Mantelnormale ist streng horizontal (ny == 0) — die Schwelle 0.5
        // trennt sauber Deckel/Boden (|ny| == 1) von Mantelflaechen (ny == 0).
        let (u, v) = if ny.abs() > 0.5 {
            // Grundriss-Projektion: u = x, v = z (Meter).
            (px, pz)
        } else {
            // Horizontale Flaechen-Tangente t = (-n.z, 0, n.x): u = Weglaenge
            // entlang t, v = Hoehe. `t` ist ein Einheitsvektor, weil (n.x, n.z)
            // fuer Mantelflaechen normiert ist.
            let u = px * (-nz) + pz * nx;
            (u, py)
        };
        verts.extend_from_slice(&[px, py, pz, nx, ny, nz, u, v]);
    }
    TexturedMesh {
        verts,
        indices: mesh.indices.clone(),
        // Ohne Material-Zuordnung: leer -> die GPU-Schicht bindet einen konstanten
        // `-1`-Ebenenpuffer (Fallback-Schachbrett fuer alle Vertices).
        layers: Vec::new(),
    }
 }
 /// TEXTURIERTES Szenen-Mesh MIT Material-Ebenen: baut dieselbe Szene wie
 /// `build_scene_mesh` (Waende -> Decken -> Kontext-Meshes, gleiche Reihenfolge/
 /// Geometrie) und fuellt zusaetzlich den parallelen `layers`-Puffer (ein Eintrag
 /// je Vertex): fuer jede Wand ihre `material_index`-Textur-Ebene (`None` -> `-1`),
 /// fuer Decken und Kontext-Meshes `-1` (Fallback-Schachbrett). Die Vertex-Ranges
 /// werden waehrend des Baus je Bauteil aus `Mesh::vertex_count()` abgegriffen —
 /// dieselben `extrude_*`/`append_*`-Funktionen wie der Shaded-Pfad bleiben die
 /// EINE Geometrie-Quelle (Paritaet garantiert), es kommt nur die Ebenen-Zuordnung
 /// dazu. Genutzt vom `Textured`-Stil (`gpu::upload_*`).
 pub fn build_scene_mesh_textured(
    walls: &[WallInput],
    slabs: &[SlabInput],
    meshes: &[MeshInput],
 ) -> TexturedMesh {
    let mut mesh = Mesh::default();
    let mut layers: Vec<f32> = Vec::new();
    let fill = |mesh: &Mesh, layers: &mut Vec<f32>, before: usize, layer: f32| {
        let added = mesh.vertex_count().saturating_sub(before);
        layers.extend(std::iter::repeat(layer).take(added));
    };
    let miters = compute_wall_miters(walls);
    for (w, m) in walls.iter().zip(miters.iter()) {
        let before = mesh.vertex_count();
        extrude_wall_with_miters(&mut mesh, w, *m);
        // Material-Ebene der Wand (1-basiert; 0 ist das Fallback-Schachbrett).
        let layer = w.material_index.map(|i| i as f32).unwrap_or(-1.0);
        fill(&mesh, &mut layers, before, layer);
    }
    for s in slabs {
        let before = mesh.vertex_count();
        extrude_slab(&mut mesh, s);
        fill(&mesh, &mut layers, before, -1.0);
    }
    for m in meshes {
        let before = mesh.vertex_count();
        append_context_mesh(&mut mesh, m);
        // Material-Ebene des Kontext-Meshes (aktuell nur Daecher setzen sie,
        // s. `MeshInput::material_index`); ohne -> Fallback-Schachbrett.
        let layer = m.material_index.map(|i| i as f32).unwrap_or(-1.0);
        fill(&mesh, &mut layers, before, layer);
    }
    let mut tex = textured_from_mesh(&mesh);
    debug_assert_eq!(
        layers.len(),
        tex.vertex_count(),
        "ein Ebenen-Eintrag je Vertex"
    );
    tex.layers = layers;
    tex
 }
 /// Baut das volle Modell-Mesh: erst die Waende (Quader), dann die Deckenplatten
 /// (extrudierte Polygone) — alles in EINEN Puffer. Die Wand-Reihenfolge bleibt
 /// vorne (deterministische Zaehlung fuer die Wand-Tests).
@@ -599,6 +1220,20 @@ pub fn build_scene_mesh(walls: &[WallInput], slabs: &[SlabInput], meshes: &[Mesh
    mesh
 }
 /// Baut NUR die Gelaende-Dreiecke (`MeshKind::Terrain`) zu EINEM Mesh — Grundlage
 /// des Luftbild-Overlays (`gpu::aerial_pipeline`): dieselbe Geometrie wie im
 /// Hauptpuffer, aber separat, damit sie ein zweites Mal texturiert obenauf
 /// gezeichnet werden kann. Leer, wenn kein Terrain vorliegt.
 pub fn build_terrain_mesh(meshes: &[MeshInput]) -> Mesh {
    let mut mesh = Mesh::default();
    for m in meshes {
        if matches!(m.kind, crate::types::MeshKind::Terrain) {
            append_context_mesh(&mut mesh, m);
        }
    }
    mesh
 }
 // ── Rohe Kontext-Meshes (Terrain / importierte Volumen) ──────────────────────
 /// Haengt EIN rohes Dreiecks-Mesh (Terrain-TIN oder importiertes Volumen, siehe
@@ -621,6 +1256,21 @@ pub fn append_context_mesh(mesh: &mut Mesh, input: &MeshInput) {
    let pos = &input.positions;
    let vcount = pos.len() / 3;
    let color = input.effective_color();
    // Pro-Vertex-Farben nur nutzen, wenn genau ein RGB je Vertex vorliegt
    // (sonst greift die Einzelfarbe fuers ganze Mesh). Beispiel: Luftbild-Drape.
    let per_vertex = input.vertex_colors.len() >= vcount * 3 && vcount > 0;
    let vcol = |i: usize| -> Rgb {
        if per_vertex {
            let b = i * 3;
            [
                input.vertex_colors[b],
                input.vertex_colors[b + 1],
                input.vertex_colors[b + 2],
            ]
        } else {
            color
        }
    };
    // world-Position aus Modell (x, y, z=Hoehe): (x, hoehe, y).
    let vworld = |i: usize| -> [f32; 3] {
        let b = i * 3;
@@ -635,6 +1285,7 @@ pub fn append_context_mesh(mesh: &mut Mesh, input: &MeshInput) {
        let a = vworld(ia);
        let b = vworld(ib);
        let c = vworld(ic);
        let (ca, cb, cc) = (vcol(ia), vcol(ib), vcol(ic));
        // Flaechen-Normale (b-a) x (c-a); entartete Dreiecke ueberspringen.
        let ab = [b[0] - a[0], b[1] - a[1], b[2] - a[2]];
        let ac = [c[0] - a[0], c[1] - a[1], c[2] - a[2]];
@@ -649,8 +1300,8 @@ pub fn append_context_mesh(mesh: &mut Mesh, input: &MeshInput) {
        }
        let n = [gn[0] / len, gn[1] / len, gn[2] / len];
        // Vorderseite + Rueckseite (siehe Moduldoc: doppelseitig).
-        push_ctx_tri(mesh, a, b, c, n, color);
+        push_ctx_tri(mesh, a, b, c, n, [ca, cb, cc]);
-        push_ctx_tri(mesh, a, c, b, [-n[0], -n[1], -n[2]], color);
+        push_ctx_tri(mesh, a, c, b, [-n[0], -n[1], -n[2]], [ca, cc, cb]);
    }
 }
@@ -663,10 +1314,10 @@ fn push_ctx_tri(
    b: [f32; 3],
    c: [f32; 3],
    normal: [f32; 3],
-    color: Rgb,
+    colors: [Rgb; 3],
 ) {
    let base = (mesh.verts.len() / FLOATS_PER_VERTEX) as u32;
-    for p in [a, b, c] {
+    for (p, color) in [a, b, c].iter().zip(colors.iter()) {
        mesh.verts.extend_from_slice(&[
            p[0], p[1], p[2], normal[0], normal[1], normal[2], color[0], color[1], color[2],
        ]);
@@ -24,12 +24,9 @@
 //! - **Ursprung:** `SectionPlane::point`, projiziert.
 //! - **u (horizontal in der Zeichnung):** Strecke entlang der Schnittebene,
 //!   senkrecht zur Blickrichtung, in der Horizontalen. Berechnet als
-//!   `u_axis = normalize(cross(normal, world_up))` — dieselbe rechtshaendige
+//!   `u_axis = normalize(cross(world_up, normal))` — das Blickrichtungs-RECHTS
-//!   Kamera-Konvention wie `math::look_at` (dort `s = cross(f, up)`), damit die
+//!   des Betrachters (wer nach Norden blickt, hat Osten rechts). Die fruehere
-//!   Vorzeichen-Konvention modulübergreifend konsistent bleibt. Bei den
+//!   look_at-Konvention `cross(normal, up)` spiegelte die Zeichnung.
 //!   Standard-Konstruktoren entspricht `u` direkt der jeweils ANDEREN
 //!   Grundriss-Achse (Schnitt entlang X -> u = Modell-Y, Schnitt entlang Y ->
 //!   u = -Modell-X).
 //! - **v (vertikal in der Zeichnung, "Hoehe"):** `v = world.y`, ABSOLUT (nicht
 //!   relativ zur Schnittebene). `world.y` ist in dieser Codebasis durchgaengig
 //!   die Hoehen-Achse (Y-up, siehe `types.rs`/`mesh.rs`/`math.rs`: "world.y =
@@ -133,7 +130,7 @@
 use serde::{Deserialize, Serialize};
 use crate::math;
-use crate::types::{Opening, Point2, Rgb, SlabInput, WallInput};
+use crate::types::{CutBandMeta, Hatch, Opening, Point2, Rgb, SlabInput, WallInput};
 /// Toleranz fuer "naeher an der Ebene" / Grenzwert-Vergleiche (Meter, Tiefe/Hoehe).
 const EPS: f32 = 1e-4;
@@ -189,8 +186,13 @@ impl SectionPlane {
    /// `pub(crate)`, damit `section_fill` die (u,v)->Welt-Ruecktransformation
    /// mit EXAKT derselben Achsdefinition (inkl. Entartungs-Fallback) rechnet.
    pub(crate) fn u_axis(&self) -> [f32; 3] {
        // Blickrichtungs-RECHTS des Betrachters: cross(up, normal). Die alte
        // Formel cross(normal, up) (die `look_at`-right-Konvention fuer Blick
        // entlang -z) SPIEGELTE den Schnitt — wer nach Norden blickt, hat
        // Osten rechts, die Ausgabe zeigte ihn links. Gleiche Entspiegelung
        // wie `elevationFrame` (toElevation.ts) auf der TS-Seite.
        let up = [0.0, 1.0, 0.0];
-        let u = math::cross(self.normal, up);
+        let u = math::cross(up, self.normal);
        if math::length(u) > 1e-6 {
            math::normalize(u)
        } else {
@@ -268,8 +270,19 @@ pub struct ComponentRef {
 pub struct CutPolygon {
    pub component: ComponentRef,
    pub color: Rgb,
    /// Schnitt-Schraffur des Ursprungs-Bauteils (siehe `WallInput::hatch`). `None`
    /// -> der Cap-Shader zeichnet das Fallback-Diagonalmuster (Alt-Verhalten).
    #[serde(default)]
    pub hatch: Option<Hatch>,
    /// Ring-Ecken (u, v); erste != letzte (Ring implizit geschlossen).
    pub pts: Vec<[f32; 2]>,
    /// Schnitt-Verschneidungs-/Linienstil-Metadaten des Ursprungs-Bandes (siehe
    /// `WallInput::cut`). Treibt die Boolean-Dominanz in `section_boolean::
    /// subtract_dominant_bands` (die staerkere Schicht schneidet die schwaechere)
    /// und die Schnitt-Umrisslinien (`section_fill::build_cut_cap_lines`). `None`
    /// -> das Band nimmt an keiner Subtraktion teil (Alt-Verhalten).
    #[serde(default)]
    pub cut: Option<CutBandMeta>,
 }
 /// Ein Liniensegment in Schnittkoordinaten (u, v), Meter.
@@ -314,9 +327,16 @@ struct Prism {
    z0: f32,
    z1: f32,
    color: Rgb,
    /// Schnitt-Schraffur des Bauteils (siehe `WallInput::hatch`). Wandert in die
    /// Cut-Polygone, damit `section_fill`/`CAP_WGSL` das richtige Muster zeichnen.
    hatch: Option<Hatch>,
    /// Nur fuer Waende: Achse + Oeffnungen (siehe `WallAxis`). `None` fuer
    /// Decken (Slabs kennen keine Oeffnungen).
    wall_axis: Option<WallAxis>,
    /// Schnitt-Metadaten (Prioritaet/Identitaet/Linienstil), 1:1 aus der
    /// `WallInput`/`SlabInput`-Eingabe (`cut`) uebernommen und an jedes erzeugte
    /// `CutPolygon` weitergereicht.
    cut: Option<CutBandMeta>,
 }
 /// Wandachse + Oeffnungen, wie sie fuer die Oeffnungs-Zuordnung bei Cut-
@@ -399,12 +419,14 @@ fn wall_prism(index: usize, wall: &WallInput) -> Option<Prism> {
        z0: wall.base_elevation,
        z1: wall.base_elevation + wall.height,
        color: wall.color,
        hatch: wall.hatch,
        wall_axis: Some(WallAxis {
            start: wall.start,
            dir,
            length,
            openings: wall.openings.clone(),
        }),
        cut: wall.cut.clone(),
    })
 }
@@ -425,7 +447,9 @@ fn slab_prism(index: usize, slab: &SlabInput) -> Option<Prism> {
        z0,
        z1,
        color: slab.color,
        hatch: slab.hatch,
        wall_axis: None,
        cut: slab.cut.clone(),
    })
 }
@@ -974,7 +998,9 @@ pub fn cut_section(plane: &SectionPlane, walls: &[WallInput], slabs: &[SlabInput
                        index: prism.index,
                    },
                    color: prism.color,
                    hatch: prism.hatch,
                    pts: vec![[rlo, rz0], [rhi, rz0], [rhi, rz1], [rlo, rz1]],
                    cut: prism.cut.clone(),
                });
            }
        }
@@ -1016,6 +1042,10 @@ mod tests {
                color,
                openings: vec![],
                layers: None,
                holes: vec![],
                material_index: None,
                hatch: None,
                cut: None,
            },
            WallInput {
                start: [0.0, 3.0],
@@ -1026,6 +1056,10 @@ mod tests {
                color,
                openings: vec![],
                layers: None,
                holes: vec![],
                material_index: None,
                hatch: None,
                cut: None,
            },
        ];
        let slabs = vec![SlabInput {
@@ -1033,6 +1067,8 @@ mod tests {
            z_bottom: -0.2,
            z_top: 0.0,
            color: [0.86, 0.86, 0.88],
            hatch: None,
            cut: None,
        }];
        (walls, slabs)
    }
@@ -1065,8 +1101,9 @@ mod tests {
            math::dot(u, plane.normal).abs() < 1e-6,
            "u-Achse orthogonal zur Blickrichtung"
        );
-        // Fuer looking_plus_x ist u = Modell-Y (world +Z).
+        // Fuer looking_plus_x (Blick nach Osten) zeigt das Betrachter-RECHTS
-        assert!((u[2] - 1.0).abs() < 1e-6);
+        // nach Sueden: u = world −Z (Entspiegelung, s. u_axis-Doc).
        assert!((u[2] + 1.0).abs() < 1e-6);
    }
    #[test]
@@ -1106,8 +1143,8 @@ mod tests {
        let vs: Vec<f32> = wall_cut.pts.iter().map(|p| p[1]).collect();
        let (u_lo, u_hi) = (us.iter().cloned().fold(f32::INFINITY, f32::min), us.iter().cloned().fold(f32::NEG_INFINITY, f32::max));
        let (v_lo, v_hi) = (vs.iter().cloned().fold(f32::INFINITY, f32::min), vs.iter().cloned().fold(f32::NEG_INFINITY, f32::max));
-        assert!((u_lo - 2.9).abs() < 1e-4, "u_lo={u_lo}");
+        assert!((u_lo + 3.1).abs() < 1e-4, "u_lo={u_lo}");
-        assert!((u_hi - 3.1).abs() < 1e-4, "u_hi={u_hi}");
+        assert!((u_hi + 2.9).abs() < 1e-4, "u_hi={u_hi}");
        assert!((v_lo - 0.0).abs() < 1e-4, "v_lo={v_lo}");
        assert!((v_hi - 2.5).abs() < 1e-4, "v_hi={v_hi}");
@@ -1120,8 +1157,8 @@ mod tests {
        let vs: Vec<f32> = slab_cut.pts.iter().map(|p| p[1]).collect();
        let (u_lo, u_hi) = (us.iter().cloned().fold(f32::INFINITY, f32::min), us.iter().cloned().fold(f32::NEG_INFINITY, f32::max));
        let (v_lo, v_hi) = (vs.iter().cloned().fold(f32::INFINITY, f32::min), vs.iter().cloned().fold(f32::NEG_INFINITY, f32::max));
-        assert!((u_lo + 0.5).abs() < 1e-4, "u_lo={u_lo}");
+        assert!((u_lo + 3.5).abs() < 1e-4, "u_lo={u_lo}");
-        assert!((u_hi - 3.5).abs() < 1e-4, "u_hi={u_hi}");
+        assert!((u_hi - 0.5).abs() < 1e-4, "u_hi={u_hi}");
        assert!((v_lo + 0.2).abs() < 1e-4, "v_lo={v_lo}");
        assert!((v_hi - 0.0).abs() < 1e-4, "v_hi={v_hi}");
    }
@@ -1177,30 +1214,30 @@ mod tests {
        let embedded_corner_hidden = out.hidden_edges.iter().any(|e| {
            e.component.kind == ComponentKind::Wall
                && e.component.index == 1
-                && (e.a[0] - 2.9).abs() < 1e-3
+                && (e.a[0] + 2.9).abs() < 1e-3
-                && (e.b[0] - 2.9).abs() < 1e-3
+                && (e.b[0] + 2.9).abs() < 1e-3
                && (e.a[1].min(e.b[1]) - 0.0).abs() < 1e-3
                && (e.a[1].max(e.b[1]) - 2.5).abs() < 1e-3
        });
-        assert!(embedded_corner_hidden, "Eckkante von Schenkel B bei u=2.9 muss hidden sein");
+        assert!(embedded_corner_hidden, "Eckkante von Schenkel B bei u=-2.9 muss hidden sein");
        // Die AEUSSERE Eckkante von Schenkel B (u=3.1, ragt ueber Schenkel A
        // hinaus) bleibt dagegen sichtbar.
        let outer_corner_visible = out.visible_edges.iter().any(|e| {
            e.component.kind == ComponentKind::Wall
                && e.component.index == 1
-                && (e.a[0] - 3.1).abs() < 1e-3
+                && (e.a[0] + 3.1).abs() < 1e-3
-                && (e.b[0] - 3.1).abs() < 1e-3
+                && (e.b[0] + 3.1).abs() < 1e-3
        });
        assert!(outer_corner_visible, "Aeussere Eckkante von Schenkel B (u=3.1) bleibt sichtbar");
-        // Die partiell gesplittete Bodenkante (u: 2.9 -> 3.1 bei v=0) zerfaellt
+        // Die partiell gesplittete Bodenkante (u: -3.1 -> -2.9 bei v=0,
-        // in einen sichtbaren Anteil ab u=3.0.
+        // gespiegelte u-Achse) zerfaellt in einen sichtbaren Anteil ab u=-3.0.
        let split_visible_present = out.visible_edges.iter().any(|e| {
            e.component.kind == ComponentKind::Wall
                && e.component.index == 1
                && (e.a[1].abs() < 1e-3 && e.b[1].abs() < 1e-3)
-                && ((e.a[0] - 3.0).abs() < 1e-3 || (e.b[0] - 3.0).abs() < 1e-3)
+                && ((e.a[0] + 3.0).abs() < 1e-3 || (e.b[0] + 3.0).abs() < 1e-3)
        });
        assert!(split_visible_present, "Sichtbarer Teil der gesplitteten Bodenkante ab u=3.0 fehlt");
    }
@@ -1252,14 +1289,14 @@ mod tests {
        };
        let a = wall_cuts.iter().find(|c| c.component.index == 0).expect("Schenkel A");
        let b = wall_cuts.iter().find(|c| c.component.index == 1).expect("Schenkel B");
-        let (_a_lo, a_hi) = u_bounds(a);
+        let (a_lo, _a_hi) = u_bounds(a);
-        let (b_lo, _b_hi) = u_bounds(b);
+        let (_b_lo, b_hi) = u_bounds(b);
-        // Beide enden/beginnen an der Gehrungslinie (u ~ 2.95) statt sich zu
+        // Beide enden/beginnen an der Gehrungslinie (u ~ -2.95, gespiegelte
-        // ueberlappen (Schenkel A reichte ungehrt bis u=3.0, Schenkel B ab 2.9).
+        // u-Achse) statt sich zu ueberlappen.
-        assert!((a_hi - 2.95).abs() < 1e-3, "Schenkel-A-Querschnitt endet an der Gehrung, u_hi={a_hi}");
+        assert!((a_lo + 2.95).abs() < 1e-3, "Schenkel-A-Querschnitt endet an der Gehrung, u_lo={a_lo}");
-        assert!((b_lo - 2.95).abs() < 1e-3, "Schenkel-B-Querschnitt beginnt an der Gehrung, u_lo={b_lo}");
+        assert!((b_hi + 2.95).abs() < 1e-3, "Schenkel-B-Querschnitt beginnt an der Gehrung, u_hi={b_hi}");
-        assert!(a_hi <= b_lo + 1e-4, "keine u-Ueberlappung der beiden Querschnitte");
+        assert!(b_hi <= a_lo + 1e-4, "keine u-Ueberlappung der beiden Querschnitte");
    }
    // --- Oeffnungen (Tueren/Fenster) -----------------------------------------
@@ -1282,6 +1319,10 @@ mod tests {
                height: 1.0,
            }],
            layers: None,
            holes: vec![],
            material_index: None,
            hatch: None,
            cut: None,
        }
    }
@@ -1367,6 +1408,10 @@ mod tests {
            color: [0.8, 0.8, 0.8],
            openings: vec![],
            layers: None,
            holes: vec![],
            material_index: None,
            hatch: None,
            cut: None,
        };
        // Blick von y = -2 nach +Y: beide Waende (y=0 bzw. y=1) liegen dahinter.
        let plane = SectionPlane::looking_plus_y(-2.0);
@@ -1385,8 +1430,8 @@ mod tests {
                    && (e.a[1].max(e.b[1]) - 2.0).abs() < 1e-3
            })
        };
-        assert!(jamb_visible(-1.5), "linke Leibung (u=-1.5) muss sichtbar sein");
+        assert!(jamb_visible(1.5), "linke Leibung (u=1.5) muss sichtbar sein");
-        assert!(jamb_visible(-2.5), "rechte Leibung (u=-2.5) muss sichtbar sein");
+        assert!(jamb_visible(2.5), "rechte Leibung (u=2.5) muss sichtbar sein");
        // Bruestungs- und Sturzkante (horizontale Rahmenkanten bei v=1.0/2.0).
        let horizontal_edge_visible = |v: f32| {
            out.visible_edges.iter().any(|e| {
@@ -1394,8 +1439,8 @@ mod tests {
                    && e.component.index == 0
                    && (e.a[1] - v).abs() < 1e-3
                    && (e.b[1] - v).abs() < 1e-3
-                    && (e.a[0].min(e.b[0]) + 2.5).abs() < 1e-3
+                    && (e.a[0].min(e.b[0]) - 1.5).abs() < 1e-3
-                    && (e.a[0].max(e.b[0]) + 1.5).abs() < 1e-3
+                    && (e.a[0].max(e.b[0]) - 2.5).abs() < 1e-3
            })
        };
        assert!(horizontal_edge_visible(1.0), "Bruestungskante (v=1.0) muss sichtbar sein");
@@ -1405,21 +1450,21 @@ mod tests {
        let frame_hidden = out.hidden_edges.iter().any(|e| {
            e.component.kind == ComponentKind::Wall
                && e.component.index == 0
-                && ((e.a[0] + 1.5).abs() < 1e-3 || (e.a[0] + 2.5).abs() < 1e-3)
+                && ((e.a[0] - 1.5).abs() < 1e-3 || (e.a[0] - 2.5).abs() < 1e-3)
                && e.a[1] >= 1.0 - 1e-3
                && e.a[1] <= 2.0 + 1e-3
        });
        assert!(!frame_hidden, "Fensterrahmen darf nicht (teilweise) hidden sein");
        // -- Durchblick: die (naeherliegende) Vorderkante von Wand 1 bei
-        // u=-2.0 (Wandstart x=2, liegt IM Fenster-u-Bereich -2.5..-1.5) muss
+        // u=2.0 (Wandstart x=2, liegt IM Fenster-u-Bereich 1.5..2.5) muss
        // GENAU im Fensterband (v: 1.0..2.0) sichtbar sein, darueber/darunter
        // (verdeckt durch Bruestung/Sturz der Wand 0) hidden. --
        let w1_visible_window = out.visible_edges.iter().any(|e| {
            e.component.kind == ComponentKind::Wall
                && e.component.index == 1
-                && (e.a[0] + 2.0).abs() < 1e-3
+                && (e.a[0] - 2.0).abs() < 1e-3
-                && (e.b[0] + 2.0).abs() < 1e-3
+                && (e.b[0] - 2.0).abs() < 1e-3
                && (e.a[1].min(e.b[1]) - 1.0).abs() < 1e-3
                && (e.a[1].max(e.b[1]) - 2.0).abs() < 1e-3
        });
@@ -1428,8 +1473,8 @@ mod tests {
        let w1_hidden_below = out.hidden_edges.iter().any(|e| {
            e.component.kind == ComponentKind::Wall
                && e.component.index == 1
-                && (e.a[0] + 2.0).abs() < 1e-3
+                && (e.a[0] - 2.0).abs() < 1e-3
-                && (e.b[0] + 2.0).abs() < 1e-3
+                && (e.b[0] - 2.0).abs() < 1e-3
                && (e.a[1].min(e.b[1]) - 0.0).abs() < 1e-3
                && (e.a[1].max(e.b[1]) - 1.0).abs() < 1e-3
        });
@@ -1438,20 +1483,20 @@ mod tests {
        let w1_hidden_above = out.hidden_edges.iter().any(|e| {
            e.component.kind == ComponentKind::Wall
                && e.component.index == 1
-                && (e.a[0] + 2.0).abs() < 1e-3
+                && (e.a[0] - 2.0).abs() < 1e-3
-                && (e.b[0] + 2.0).abs() < 1e-3
+                && (e.b[0] - 2.0).abs() < 1e-3
                && (e.a[1].min(e.b[1]) - 2.0).abs() < 1e-3
                && (e.a[1].max(e.b[1]) - 2.5).abs() < 1e-3
        });
        assert!(w1_hidden_above, "Wand 1 oberhalb des Sturzes (v 2.0..2.5) muss hidden sein");
-        // Kante hinter der GESCHLOSSENEN Wandflaeche (u=-4.0, ausserhalb des
+        // Kante hinter der GESCHLOSSENEN Wandflaeche (u=4.0, ausserhalb des
        // Fensters, x=4-Ende von Wand 1) bleibt vollstaendig verdeckt.
        let w1_closed_wall_hidden = out.hidden_edges.iter().any(|e| {
            e.component.kind == ComponentKind::Wall
                && e.component.index == 1
-                && (e.a[0] + 4.0).abs() < 1e-3
+                && (e.a[0] - 4.0).abs() < 1e-3
-                && (e.b[0] + 4.0).abs() < 1e-3
+                && (e.b[0] - 4.0).abs() < 1e-3
                && (e.a[1].min(e.b[1]) - 0.0).abs() < 1e-3
                && (e.a[1].max(e.b[1]) - 2.5).abs() < 1e-3
        });
@@ -0,0 +1,516 @@
 //! Schnitt-Boolean-Dominanz fuer den 3D-Live-Schnitt — die 1:1-Portierung von
 //! `src/plan/toSection.ts::subtractDominantBands`/`subtractRect` nach Rust.
 //!
 //! GRUND: der 2D-Schnitt (`toSection.ts`) ist die Referenz-Implementierung. Er
 //! sammelt alle Cut-Baender (Wand- und Deckenschichten) als achsparallele
 //! (u,v)-Rechtecke, taggt jedes mit seiner `Component.joinPriority` und laesst
 //! dann die STAERKERE Schicht die schwaechere per Rechteck-Subtraktion wegschneiden
 //! (elementuebergreifend). Der 3D-Rust-Cut (`section.rs`) produziert bereits genau
 //! dasselbe Format — achsparallele (u,v)-Rechteck-`CutPolygon`s — also laesst sich
 //! die Dominanz-Zerlegung hier identisch nachbauen, damit der 3D-Live-Schnitt fuer
 //! Wand+Decken-Schichten EXAKT wie der 2D-Schnitt aussieht.
 //!
 //! Die Prioritaet/Identitaet je Band kommt aus `CutPolygon::cut` (`CutBandMeta`,
 //! aus der TS-Emission `toWalls3d`). Baender ohne `join_priority` (unaufloesbares
 //! Bauteil) nehmen weder als Basis noch als Cutter teil und bleiben unveraendert.
 use crate::section::CutPolygon;
 /// Toleranz fuer Ueberlappungs-/Rest-Rechtecke (Meter): Null-/Negativflaechen und
 /// Rest-Streifen duenner als EPS werden verworfen (Float-Rauschen der (u,v)-Meter).
 /// Identisch zu `RECT_EPS` in `toSection.ts`.
 const RECT_EPS: f32 = 1e-6;
 /// Achsparalleles Rechteck in (u, v)-Metern — das Rust-Gegenstueck zu `Rect` in
 /// `toSection.ts`.
 #[derive(Debug, Clone, Copy, PartialEq)]
 pub struct Rect {
    pub u_min: f32,
    pub u_max: f32,
    pub v_min: f32,
    pub v_max: f32,
 }
 /// Bounding-Box eines (achsparallelen) Cut-Bands als `Rect`, oder `None` bei <3
 /// Ecken (analog `rectOfBand`).
 pub fn rect_of_poly(poly: &CutPolygon) -> Option<Rect> {
    if poly.pts.len() < 3 {
        return None;
    }
    let mut u_min = f32::INFINITY;
    let mut u_max = f32::NEG_INFINITY;
    let mut v_min = f32::INFINITY;
    let mut v_max = f32::NEG_INFINITY;
    for p in &poly.pts {
        u_min = u_min.min(p[0]);
        u_max = u_max.max(p[0]);
        v_min = v_min.min(p[1]);
        v_max = v_max.max(p[1]);
    }
    Some(Rect {
        u_min,
        u_max,
        v_min,
        v_max,
    })
 }
 /// Rechteck-minus-Rechteck (beide achsparallel): `base` ohne die Ueberlappung mit
 /// `cutter`, zerlegt in 0–4 disjunkte Rest-Rechtecke (links/rechts ueber die volle
 /// Hoehe, dann oben/unten im mittleren u-Streifen — ueberlappungsfrei). Kein echter
 /// Ueberlapp (Flaeche ≤ EPS in u oder v) ⇒ `base` bleibt ganz. Vollstaendige
 /// Ueberdeckung ⇒ leere Liste. Rest-Streifen duenner als EPS werden verworfen.
 /// 1:1 aus `toSection.ts::subtractRect`.
 pub fn subtract_rect(base: Rect, cutter: Rect) -> Vec<Rect> {
    let o_min_u = base.u_min.max(cutter.u_min);
    let o_max_u = base.u_max.min(cutter.u_max);
    let o_min_v = base.v_min.max(cutter.v_min);
    let o_max_v = base.v_max.min(cutter.v_max);
    // Kein (nennenswerter) Ueberlapp — `base` unveraendert.
    if o_max_u - o_min_u <= RECT_EPS || o_max_v - o_min_v <= RECT_EPS {
        return vec![base];
    }
    let mut out = Vec::new();
    let mut push = |r: Rect| {
        if r.u_max - r.u_min > RECT_EPS && r.v_max - r.v_min > RECT_EPS {
            out.push(r);
        }
    };
    // Links / rechts der Ueberlappung, jeweils ueber die volle Basis-Hoehe.
    push(Rect {
        u_min: base.u_min,
        u_max: o_min_u,
        v_min: base.v_min,
        v_max: base.v_max,
    });
    push(Rect {
        u_min: o_max_u,
        u_max: base.u_max,
        v_min: base.v_min,
        v_max: base.v_max,
    });
    // Unten / oben im mittleren u-Streifen (nur der von der Ueberlappung befreite Rest).
    push(Rect {
        u_min: o_min_u,
        u_max: o_max_u,
        v_min: base.v_min,
        v_max: o_min_v,
    });
    push(Rect {
        u_min: o_min_u,
        u_max: o_max_u,
        v_min: o_max_v,
        v_max: base.v_max,
    });
    out
 }
 /// `join_priority` eines Bands (aus `CutBandMeta`), oder `None`.
 fn priority_of(poly: &CutPolygon) -> Option<i32> {
    poly.cut.as_ref().and_then(|c| c.join_priority)
 }
 /// `component_id` eines Bands (aus `CutBandMeta`), oder `None`.
 fn component_of(poly: &CutPolygon) -> Option<&str> {
    poly.cut.as_ref().and_then(|c| c.component_id.as_deref())
 }
 /// Erzeugt aus einem Rest-`Rect` ein Cut-Band, das Stil/Referenz/Metadaten von
 /// `src` erbt (analog `bandFromRect`). Ecken-Reihenfolge wie in `section.rs`
 /// (CCW-analog, hier v_max oben zuerst — fuer die Fan-Triangulierung irrelevant).
 fn poly_from_rect(src: &CutPolygon, r: Rect) -> CutPolygon {
    CutPolygon {
        component: src.component,
        color: src.color,
        hatch: src.hatch,
        cut: src.cut.clone(),
        pts: vec![
            [r.u_min, r.v_max],
            [r.u_max, r.v_max],
            [r.u_max, r.v_min],
            [r.u_min, r.v_min],
        ],
    }
 }
 /// Globale Schnitt-Dominanz: fuer jedes Band wird die Rechteck-Ueberlappung ALLER
 /// Baender mit STRIKT hoeherer `join_priority` subtrahiert (elementuebergreifend —
 /// z. B. schneidet ein Decken-Beton-Band 100 ein ueberlappendes Wand-Putz-Band 10
 /// weg). Gleiche Prioritaet schneidet NICHT (koexistiert → durchgehende Flaeche).
 /// Baender ohne `join_priority` nehmen weder als Basis noch als Cutter teil und
 /// bleiben unveraendert erhalten. 1:1 aus `toSection.ts::subtractDominantBands`
 /// (inklusive der abschliessenden MERGE-Phase).
 pub fn subtract_dominant_bands(bands: Vec<CutPolygon>) -> Vec<CutPolygon> {
    let rects: Vec<Option<Rect>> = bands.iter().map(rect_of_poly).collect();
    let prios: Vec<Option<i32>> = bands.iter().map(priority_of).collect();
    let mut out: Vec<CutPolygon> = Vec::new();
    for i in 0..bands.len() {
        // Nicht-rechteckig oder ohne Prioritaet: unveraendert durchreichen.
        let (base, prio) = match (rects[i], prios[i]) {
            (Some(b), Some(p)) => (b, p),
            _ => {
                out.push(bands[i].clone());
                continue;
            }
        };
        let mut pieces = vec![base];
        for j in 0..bands.len() {
            if pieces.is_empty() {
                break;
            }
            if j == i {
                continue;
            }
            let cutter = match (rects[j], prios[j]) {
                (Some(c), Some(op)) if op > prio => c,
                _ => continue,
            };
            let mut next = Vec::new();
            for p in &pieces {
                next.extend(subtract_rect(*p, cutter));
            }
            pieces = next;
        }
        for p in pieces {
            out.push(poly_from_rect(&bands[i], p));
        }
    }
    merge_same_component_bands(out)
 }
 /// Union zweier achsparalleler Rechtecke, ABER NUR wenn das Ergebnis EXAKT wieder
 /// ein Rechteck ist — sonst `None`. Enthaltensein oder Achs-Deckung + Beruehrung
 /// liefern eine rechteckige Union; Teil-/Eck-Ueberlappungen (L-Form) und Baender
 /// mit Spalt liefern `None`. 1:1 aus `toSection.ts::rectUnionIfRect`.
 fn rect_union_if_rect(a: Rect, b: Rect) -> Option<Rect> {
    const E: f32 = RECT_EPS;
    // Enthaltensein (inkl. Deckungsgleichheit): Union = umschliessendes Rechteck.
    let a_in_b = b.u_min - a.u_min <= E
        && a.u_max - b.u_max <= E
        && b.v_min - a.v_min <= E
        && a.v_max - b.v_max <= E;
    if a_in_b {
        return Some(b);
    }
    let b_in_a = a.u_min - b.u_min <= E
        && b.u_max - a.u_max <= E
        && a.v_min - b.v_min <= E
        && b.v_max - a.v_max <= E;
    if b_in_a {
        return Some(a);
    }
    let u_aligned = (a.u_min - b.u_min).abs() <= E && (a.u_max - b.u_max).abs() <= E;
    let v_aligned = (a.v_min - b.v_min).abs() <= E && (a.v_max - b.v_max).abs() <= E;
    // Beruehrung/Ueberlappung in der jeweils ANDEREN Achse (kein Spalt groesser EPS).
    let v_touch = a.v_max >= b.v_min - E && b.v_max >= a.v_min - E;
    let u_touch = a.u_max >= b.u_min - E && b.u_max >= a.u_min - E;
    if (u_aligned && v_touch) || (v_aligned && u_touch) {
        return Some(Rect {
            u_min: a.u_min.min(b.u_min),
            u_max: a.u_max.max(b.u_max),
            v_min: a.v_min.min(b.v_min),
            v_max: a.v_max.max(b.v_max),
        });
    }
    None
 }
 /// MERGE-Phase der Schnitt-Dominanz: Baender mit GLEICHER `component_id` UND
 /// gleicher `join_priority`, deren achsparallele Rechtecke sich beruehren/ueberlappen
 /// und eine rechteckige Union bilden (`rect_union_if_rect`), werden zu EINEM Band
 /// zusammengefasst — so entsteht an der Beruehrkante keine innere Trennlinie durch
 /// gleichartiges Material. Baender ohne `component_id`/`join_priority` oder ohne
 /// Rechteck-Form nehmen nicht teil. Iterativ bis zum Fixpunkt. 1:1 aus
 /// `toSection.ts::mergeSameComponentBands`.
 fn merge_same_component_bands(bands: Vec<CutPolygon>) -> Vec<CutPolygon> {
    let mut out = bands;
    let mut merged = true;
    while merged {
        merged = false;
        'outer: for i in 0..out.len() {
            let (ci, pi) = match (component_of(&out[i]), priority_of(&out[i])) {
                (Some(c), Some(p)) => (c.to_string(), p),
                _ => continue,
            };
            let ri = match rect_of_poly(&out[i]) {
                Some(r) => r,
                None => continue,
            };
            for j in (i + 1)..out.len() {
                if component_of(&out[j]) != Some(ci.as_str()) || priority_of(&out[j]) != Some(pi) {
                    continue;
                }
                let rj = match rect_of_poly(&out[j]) {
                    Some(r) => r,
                    None => continue,
                };
                if let Some(u) = rect_union_if_rect(ri, rj) {
                    out[i] = poly_from_rect(&out[i], u);
                    out.remove(j);
                    merged = true; // Fixpunkt-Neustart
                    break 'outer;
                }
            }
        }
    }
    out
 }
 #[cfg(test)]
 mod tests {
    use super::*;
    use crate::section::{ComponentKind, ComponentRef, CutPolygon};
    use crate::types::CutBandMeta;
    /// Achsparalleles Cut-Band mit Prioritaet (und optionaler Komponenten-Id) —
    /// Ecken wie `section.rs` (Rechteck).
    fn band(
        u_min: f32,
        u_max: f32,
        v_min: f32,
        v_max: f32,
        join_priority: i32,
        component_id: Option<&str>,
    ) -> CutPolygon {
        CutPolygon {
            component: ComponentRef {
                kind: ComponentKind::Wall,
                index: 0,
            },
            color: [0.5, 0.5, 0.5],
            hatch: None,
            pts: vec![
                [u_min, v_max],
                [u_max, v_max],
                [u_max, v_min],
                [u_min, v_min],
            ],
            cut: Some(CutBandMeta {
                join_priority: Some(join_priority),
                component_id: component_id.map(|s| s.to_string()),
                line_color: None,
                line_weight: None,
            }),
        }
    }
    fn rect_of(p: &CutPolygon) -> Rect {
        rect_of_poly(p).unwrap()
    }
    fn area(bands: &[CutPolygon]) -> f32 {
        bands
            .iter()
            .map(|b| {
                let r = rect_of(b);
                (r.u_max - r.u_min) * (r.v_max - r.v_min)
            })
            .sum()
    }
    fn approx(a: f32, b: f32) -> bool {
        (a - b).abs() < 1e-5
    }
    // --- subtractRect (Referenz: toSection.boolean.test.ts) ------------------
    #[test]
    fn subtract_rect_kein_overlap_base_unveraendert() {
        let base = Rect { u_min: 0.0, u_max: 1.0, v_min: 0.0, v_max: 1.0 };
        let cut = Rect { u_min: 2.0, u_max: 3.0, v_min: 2.0, v_max: 3.0 };
        assert_eq!(subtract_rect(base, cut), vec![base]);
    }
    #[test]
    fn subtract_rect_kantenberuehrung_base_unveraendert() {
        let base = Rect { u_min: 0.0, u_max: 1.0, v_min: 0.0, v_max: 1.0 };
        let cut = Rect { u_min: 1.0, u_max: 2.0, v_min: 0.0, v_max: 1.0 };
        assert_eq!(subtract_rect(base, cut), vec![base]);
    }
    #[test]
    fn subtract_rect_cutter_enthaelt_base_leer() {
        let base = Rect { u_min: 1.0, u_max: 2.0, v_min: 1.0, v_max: 2.0 };
        let cut = Rect { u_min: 0.0, u_max: 3.0, v_min: 0.0, v_max: 3.0 };
        assert!(subtract_rect(base, cut).is_empty());
    }
    #[test]
    fn subtract_rect_cutter_mittig_vier_reste() {
        let base = Rect { u_min: 0.0, u_max: 3.0, v_min: 0.0, v_max: 3.0 };
        let cut = Rect { u_min: 1.0, u_max: 2.0, v_min: 1.0, v_max: 2.0 };
        let rest = subtract_rect(base, cut);
        assert_eq!(rest.len(), 4);
        let a: f32 = rest
            .iter()
            .map(|r| (r.u_max - r.u_min) * (r.v_max - r.v_min))
            .sum();
        assert!(approx(a, 8.0), "9 (base) - 1 (overlap) = 8, ist {a}");
    }
    #[test]
    fn subtract_rect_eck_ueberlappung_zwei_reste() {
        // cutter deckt die obere-rechte Ecke von base: overlap [1,2]x[1,2].
        let base = Rect { u_min: 0.0, u_max: 2.0, v_min: 0.0, v_max: 2.0 };
        let cut = Rect { u_min: 1.0, u_max: 3.0, v_min: 1.0, v_max: 3.0 };
        let rest = subtract_rect(base, cut);
        let a: f32 = rest
            .iter()
            .map(|r| (r.u_max - r.u_min) * (r.v_max - r.v_min))
            .sum();
        assert!(approx(a, 3.0), "4 - 1 = 3, ist {a}");
    }
    // --- subtractDominantBands: die geometrische Kernaussage ------------------
    #[test]
    fn decke_100_schneidet_wand_50_im_ueberlappungs_z_intervall_weg() {
        // Nutzer-Sample-analog: eine Wandschicht (Backstein, Prio 50, u in [0,0.2],
        // volle Hoehe v in [0,3]) und ein Decken-Beton-Band (Prio 100, u in [0,0.2],
        // v in [2.6,2.8]) ueberlappen in (u,v). Nach der Subtraktion darf die Wand
        // im Decken-z-Intervall KEINE Flaeche mehr haben; Beton bleibt voll.
        let brick = band(0.0, 0.2, 0.0, 3.0, 50, Some("brick"));
        let concrete = band(0.0, 0.2, 2.6, 2.8, 100, Some("concrete"));
        let out = subtract_dominant_bands(vec![brick, concrete]);
        // Beton unveraendert (kein staerkeres Band).
        let concrete_out: Vec<&CutPolygon> = out
            .iter()
            .filter(|b| component_of(b) == Some("concrete"))
            .collect();
        assert_eq!(concrete_out.len(), 1);
        assert!(approx(
            (rect_of(concrete_out[0]).v_max - rect_of(concrete_out[0]).v_min) as f32,
            0.2
        ));
        // Backstein: in v in [2.6,2.8] KEINE Flaeche mehr -> zwei Reste [0,2.6] und
        // [2.8,3.0]. Kein Rest-Rechteck ragt ins Beton-Intervall.
        let brick_out: Vec<&CutPolygon> = out
            .iter()
            .filter(|b| component_of(b) == Some("brick"))
            .collect();
        assert!(!brick_out.is_empty());
        for b in &brick_out {
            let r = rect_of(b);
            // Kein Backstein-Rest ueberlappt (2.6, 2.8) echt.
            let overlaps = r.v_min < 2.8 - 1e-4 && r.v_max > 2.6 + 1e-4;
            assert!(!overlaps, "Backstein-Rest {r:?} ragt ins Beton-z-Intervall");
        }
        // Flaechenbilanz: Backstein 0.2*3 = 0.6, minus Overlap 0.2*0.2 = 0.04 -> 0.56.
        assert!(
            approx(area(&out.iter().filter(|b| component_of(b) == Some("brick")).cloned().collect::<Vec<_>>()), 0.56),
            "Backstein-Restflaeche"
        );
    }
    #[test]
    fn wand_50_schneidet_estrich_30() {
        // Estrich (Decke, Prio 30) verliert die Ueberlappung mit der Wand
        // (Backstein, Prio 50). Referenz-Zahlen wie im 2D-Test.
        let screed = band(0.0, 2.0, 0.0, 3.0, 30, Some("screed"));
        let brick = band(0.0, 2.0, 2.0, 4.0, 50, Some("brick")); // Overlap v in [2,3]
        let out = subtract_dominant_bands(vec![screed, brick]);
        // Brick voll.
        assert!(approx(
            area(&out.iter().filter(|b| component_of(b) == Some("brick")).cloned().collect::<Vec<_>>()),
            4.0
        ));
        // Estrich: [0,3] minus Overlap [2,3] = [0,2] -> Rest genau v in [0,2].
        let screed_out: Vec<&CutPolygon> = out
            .iter()
            .filter(|b| component_of(b) == Some("screed"))
            .collect();
        assert_eq!(screed_out.len(), 1);
        let r = rect_of(screed_out[0]);
        assert!(approx(r.v_min, 0.0) && approx(r.v_max, 2.0), "Estrich-Rest {r:?}");
    }
    /// SAMPLE-ANALOG (Nutzer-Bug): der Schnitt durch Aussenwand + Geschossdecke.
    /// Deckenschichten (u-breit, gestapelt in v nahe OK): Estrich (30, [2.54,2.6]),
    /// Dämmung (20, [2.50,2.54]), Beton (100, [2.30,2.50]). Wandschichten (schmal in
    /// u, an ihrer Dicken-Position): Backstein (50) läuft als ZWEI Boxen [0,2.3] +
    /// [2.5,2.6] durch (Beton kappt das Mittelstück — genau die per-Schicht-Decken-
    /// Dominanz aus emitWall). ERWARTUNG: nach der Verschneidung haben Estrich UND
    /// Dämmung im u-Bereich des Backsteins KEINE Fläche mehr (Backstein 50 > 30, 20);
    /// der Beton bleibt voll und läuft durch. Das ist die Richtung, die der Nutzer als
    /// kaputt meldete ("dämmung und zementboden laufen raus").
    #[test]
    fn sample_analog_backstein_schneidet_estrich_und_daemmung() {
        let brick_u = (0.0075_f32, 0.1575_f32); // Backstein-Dickenposition (W4-analog)
        let ceil_u = (0.0_f32, 5.0_f32); // Deckenschichten über die volle Raumbreite
        let bands = vec![
            band(ceil_u.0, ceil_u.1, 2.54, 2.6, 30, Some("screed")),
            band(ceil_u.0, ceil_u.1, 2.50, 2.54, 20, Some("insulation-ceiling")),
            band(ceil_u.0, ceil_u.1, 2.30, 2.50, 100, Some("concrete")),
            band(brick_u.0, brick_u.1, 0.0, 2.3, 50, Some("brick")),
            band(brick_u.0, brick_u.1, 2.5, 2.6, 50, Some("brick")),
        ];
        let out = subtract_dominant_bands(bands);
        // Kein Estrich-/Dämmung-Rest überlappt den Backstein-u-Bereich ECHT.
        for name in ["screed", "insulation-ceiling"] {
            for b in out.iter().filter(|b| component_of(b) == Some(name)) {
                let r = rect_of(b);
                let u_overlap = r.u_min < brick_u.1 - 1e-4 && r.u_max > brick_u.0 + 1e-4;
                assert!(
                    !u_overlap,
                    "{name}-Rest {r:?} ragt noch in den Backstein-u-Bereich (müsste weg sein)"
                );
            }
        }
        // Beton bleibt voll (kein stärkeres Band): Fläche 5*0.2 = 1.0.
        assert!(approx(
            area(&out.iter().filter(|b| component_of(b) == Some("concrete")).cloned().collect::<Vec<_>>()),
            1.0
        ));
        // Backstein bleibt in beiden Boxen erhalten (nichts Stärkeres überlappt).
        assert!(approx(
            area(&out.iter().filter(|b| component_of(b) == Some("brick")).cloned().collect::<Vec<_>>()),
            0.15 * 2.3 + 0.15 * 0.1
        ));
    }
    #[test]
    fn gleiche_prioritaet_koexistiert() {
        // Beton-Wand + Beton-Decke, gleiche Prio 100, VERSCHIEDENE Komponenten:
        // schneiden sich NICHT und verschmelzen NICHT (bleiben beide voll).
        let wand = band(0.0, 1.0, 0.0, 3.0, 100, Some("beton-wand"));
        let decke = band(0.0, 1.0, 2.0, 4.0, 100, Some("beton-decke")); // Overlap v[2,3]
        let out = subtract_dominant_bands(vec![wand, decke]);
        assert_eq!(out.len(), 2);
        assert!(approx(
            area(&out.iter().filter(|b| component_of(b) == Some("beton-wand")).cloned().collect::<Vec<_>>()),
            3.0
        ));
        assert!(approx(
            area(&out.iter().filter(|b| component_of(b) == Some("beton-decke")).cloned().collect::<Vec<_>>()),
            2.0
        ));
    }
    #[test]
    fn ohne_prioritaet_keine_teilnahme() {
        let stark = band(0.0, 2.0, 0.0, 2.0, 100, None);
        let mut ohne = band(0.0, 2.0, 0.0, 2.0, 0, None);
        ohne.cut = None; // keine Prioritaet
        let out = subtract_dominant_bands(vec![stark, ohne]);
        // Beide unveraendert (4 + 4).
        assert_eq!(out.len(), 2);
        assert!(approx(area(&out), 8.0));
    }
    #[test]
    fn merge_gleiche_komponente_und_prioritaet() {
        // Beton-Wand trifft Beton-Decke (u-deckungsgleich), gleiche componentId +
        // Prio -> verschmelzen zu EINEM Rechteck v in [0,4] (keine innere Kante).
        let wand = band(0.0, 1.0, 0.0, 3.0, 100, Some("beton"));
        let decke = band(0.0, 1.0, 2.0, 4.0, 100, Some("beton"));
        let out = subtract_dominant_bands(vec![wand, decke]);
        assert_eq!(out.len(), 1);
        let r = rect_of(&out[0]);
        assert!(approx(r.v_min, 0.0) && approx(r.v_max, 4.0), "verschmolzen {r:?}");
    }
 }
@@ -21,19 +21,68 @@
 //!
 //! ## Ausgabeformat
 //!
-//! Interleaved `[world_x, world_y, world_z, u, v]` je Vertex (5 f32,
+//! Interleaved `[world_x, world_y, world_z, u, v, pattern, angle_rad, scale]` je
-//! `CAP_FLOATS_PER_VERTEX`), Dreiecksliste. `(u,v)` in Modell-Metern wandern als
+//! Vertex (8 f32, `CAP_FLOATS_PER_VERTEX`), Dreiecksliste. `(u,v)` in Modell-Metern
-//! Attribut mit, damit die Schraffur im Fragment-Shader ein durchgaengiges,
+//! wandern als Attribut mit, damit die Schraffur im Fragment-Shader ein
-//! blickwinkel-unabhaengiges Muster IN der Schnittebene zeichnet (nicht im
+//! durchgaengiges, blickwinkel-unabhaengiges Muster IN der Schnittebene zeichnet
-//! Bildschirmraum). Ein Cut-Polygon ist stets ein konvexes Rechteck (4 Ecken,
+//! (nicht im Bildschirmraum). `pattern`/`angle_rad`/`scale` kommen aus der
-//! siehe `section.rs`) — Fan-Triangulierung genuegt.
+//! Bauteil-Schraffur (`CutPolygon::hatch` -> `types::Hatch`) und waehlen im Shader
 //! das MUSTER je geschnittener Schicht (statt eines fixen 45°-Musters). Sie sind je
 //! Cut-Polygon konstant, wandern aber als (redundantes) Vertex-Attribut mit — das
 //! haelt die Cap-Pipeline ohne zusaetzliche per-Draw-Uniform-Verwaltung (die Caps
 //! werden in EINEM `draw` gezeichnet). Ein Cut-Polygon ist stets ein konvexes
 //! Rechteck (4 Ecken, siehe `section.rs`) — Fan-Triangulierung genuegt.
-use crate::section::{cut_section, SectionPlane};
+use crate::section::{cut_section, CutPolygon, SectionPlane};
 use crate::section_boolean::{rect_of_poly, subtract_dominant_bands};
 use crate::types::{SlabInput, WallInput};
-/// f32 pro Cap-Vertex: [pos.x, pos.y, pos.z, u, v]. Spiegel des Vertex-Layouts
+/// f32 pro Cap-Vertex: [pos.x, pos.y, pos.z, u, v, pattern, angle_rad, scale,
-/// der `cap_pipeline` (gpu.rs) und des `VsIn` in `CAP_WGSL` (shaders.rs).
+/// line_weight_mm]. Spiegel des Vertex-Layouts der `cap_pipeline` (gpu.rs) und des
-pub const CAP_FLOATS_PER_VERTEX: usize = 5;
+/// `VsIn` in `CAP_WGSL` (shaders.rs). `line_weight_mm` steuert die Musterlinien-
 /// Breite (mm-Papier -> Welt) je Schraffur.
 pub const CAP_FLOATS_PER_VERTEX: usize = 9;
 /// Default-Musterlinien-Staerke (mm-Papier), wenn ein Cut-Polygon keine `hatch`
 /// traegt (Fallback-Diagonale) — Haarlinie, wie `HatchRender.lineWeight`-Default.
 const FALLBACK_HATCH_LINE_WEIGHT_MM: f32 = 0.13;
 /// f32 pro Cut-Linien-Vertex: [pos.x, pos.y, pos.z, r, g, b] — dasselbe Layout wie
 /// die Grid-/Highlight-LineList (`GRID_WGSL`), damit die Schnitt-Umrisslinien ohne
 /// eigenes Vertex-Format ueber eine (Dreiecks-)Ribbon-Pipeline laufen.
 pub const CUT_LINE_FLOATS_PER_VERTEX: usize = 6;
 /// Default-Schnittkanten-Farbe (dunkle Tinte), wenn ein Band keinen eigenen
 /// `line_color` traegt — passend zur 2D-Schnittkonvention (dunkle Fugenlinie).
 const DEFAULT_CUT_LINE_COLOR: [f32; 3] = [0.10, 0.10, 0.10];
 /// Default-Strichstaerke der Schnitt-Umrisslinie in mm-Papier (Haarlinie), wenn
 /// ein Band keinen eigenen `line_weight` traegt.
 const DEFAULT_CUT_LINE_WEIGHT_MM: f32 = 0.35;
 /// mm-Papier -> Welt-Meter fuer die Ribbon-BREITE der Schnitt-Umrisslinien.
 ///
 /// EHRLICHE EINSCHRAENKUNG: die 2D-Strichstaerke ist in mm-Papier (masstabsabhaengig).
 /// Der 3D-Schnitt kennt keinen Papiermasstab; die Linie wird hier als flaches Ribbon
 /// mit KONSTANTER Welt-Breite in die Schnittebene gelegt (blickwinkel-unabhaengig,
 /// skaliert also mit der Kamera-Distanz wie gemalte Geometrie — NICHT bildschirmfest).
 /// Der Faktor ist bewusst grob gewaehlt (0.35 mm -> ~3.5 mm Welt), damit die Fuge
 /// ueberhaupt lesbar bleibt; eine bildschirmfeste Strichstaerke braeuchte eine
 /// Screen-Space-Expansion in einer eigenen Pipeline (bekannte Luecke, siehe
 /// Schlussbericht/Moduldoc).
 const CUT_LINE_MM_TO_WORLD: f32 = 0.01;
 /// Kleiner Versatz (Meter) der Umrisslinien-Ribbons ZUR KAMERA (entgegen der
 /// Ebenennormale), damit sie (a) nicht durch die Schnittebenen-Kappung von
 /// `GRID_WGSL` (`depth > 0` = hinter der Ebene) weggeschnitten werden und (b)
 /// sichtbar VOR den Cut-Caps liegen (die exakt auf der Ebene sitzen).
 const CUT_LINE_LIFT: f32 = 0.002;
 /// Fallback-Muster-Id, wenn ein Cut-Polygon keine `hatch` traegt: 2 = diagonal
 /// (45°) — reproduziert mit `angle_rad = 0`, `scale = 1` exakt das fruehere fest
 /// verdrahtete 45°-Muster (Rueckwaertskompatibilitaet fuer Waende/Decken ohne
 /// aufgeloeste Bauteil-Schraffur).
 const FALLBACK_PATTERN: f32 = 2.0;
 /// Erzeugt die Schnittflaechen-Geometrie (Cut-Caps) fuer eine vertikale
 /// Schnittebene: ruft `cut_section` und trianguliert jedes (u,v)-Rechteck in die
@@ -44,12 +93,23 @@ pub const CAP_FLOATS_PER_VERTEX: usize = 5;
 /// zeichnet ohne Backface-Culling (`CullMode::None`, siehe gpu.rs), sodass die
 /// flache Schnittflaeche aus beiden Richtungen sichtbar ist. Die Schraffur haengt
 /// nicht von der Normale ab.
 /// Berechnet die (u,v)-Cut-Polygone der Schnittebene MIT angewandter Boolean-
 /// Dominanz (`section_boolean::subtract_dominant_bands`): die staerkere Schicht
 /// schneidet die schwaechere weg — elementuebergreifend, exakt wie der 2D-Schnitt
 /// (`toSection.ts::attachCutStyles` Phase 2). Gemeinsame Basis der Cut-Cap-Flaechen
 /// (`build_cut_caps`) UND der Cut-Umrisslinien (`build_cut_cap_lines`), damit beide
 /// auf DERSELBEN, ueberlappungsfreien Rechteck-Menge arbeiten.
 fn cut_cap_polys(plane: &SectionPlane, walls: &[WallInput], slabs: &[SlabInput]) -> Vec<CutPolygon> {
    let out = cut_section(plane, walls, slabs);
    subtract_dominant_bands(out.cut_polygons)
 }
 pub fn build_cut_caps(
    plane: &SectionPlane,
    walls: &[WallInput],
    slabs: &[SlabInput],
 ) -> Vec<f32> {
-    let out = cut_section(plane, walls, slabs);
+    let polys = cut_cap_polys(plane, walls, slabs);
    let point = plane.point;
    let u_axis = plane.u_axis();
    // (u, v) -> Welt: horizontale Lage aus point + u*u_axis, Hoehe = v.
@@ -62,14 +122,28 @@ pub fn build_cut_caps(
    };
    let mut verts: Vec<f32> = Vec::new();
-    for poly in &out.cut_polygons {
+    for poly in &polys {
        let pts = &poly.pts;
        if pts.len() < 3 {
            continue;
        }
        // Muster/Winkel/Skalierung aus der Bauteil-Schraffur (oder Fallback-
        // Diagonale). Winkel von Grad in Radiant, damit der Shader direkt
        // cos/sin rechnen kann.
        let (pattern, angle_rad, scale, line_weight) = match poly.hatch {
            Some(h) => (
                h.pattern as f32,
                h.angle.to_radians(),
                h.scale.max(0.05),
                h.line_weight.max(0.0),
            ),
            None => (FALLBACK_PATTERN, 0.0, 1.0, FALLBACK_HATCH_LINE_WEIGHT_MM),
        };
        let mut push_vertex = |uv: [f32; 2]| {
            let w = to_world(uv);
-            verts.extend_from_slice(&[w[0], w[1], w[2], uv[0], uv[1]]);
+            verts.extend_from_slice(&[
                w[0], w[1], w[2], uv[0], uv[1], pattern, angle_rad, scale, line_weight,
            ]);
        };
        // Fan-Triangulierung (konvexe Rechtecke): (0, i, i+1).
        for i in 1..pts.len() - 1 {
@@ -80,3 +154,429 @@ pub fn build_cut_caps(
    }
    verts
 }
 /// Erzeugt die Schnitt-UMRISSLINIEN (P2): fuer JEDES ueberlebende Cut-Cap-Rechteck
 /// seine vier Kanten als flache Ribbon-Dreiecke auf der Schnittebene, in Welt-
 /// Koordinaten (dieselbe (u,v)->Welt-Ruecktransformation wie `build_cut_caps`).
 /// Rueckgabe = interleaved `[px,py,pz, r,g,b]` (`CUT_LINE_FLOATS_PER_VERTEX`,
 /// TriangleList), leer wenn die Ebene das Modell nicht schneidet.
 ///
 /// STIL je Kante: Farbe/Strichstaerke aus dem `line_color`/`line_weight` des Bandes
 /// (aus dem `jointLineStyleId`-LineStyle, TS-seitig aufgeloest), sonst der Default-
 /// Schnittkanten-Stil. Die Strichstaerke (mm-Papier) wird ueber `CUT_LINE_MM_TO_WORLD`
 /// in eine konstante Welt-Breite umgesetzt (siehe dortige Doku — bewusste
 /// Vereinfachung, keine bildschirmfeste Strichstaerke). Jede Kante wird als Quad
 /// (2 Dreiecke) um ihre Mittellinie gelegt, mit der Ribbon-Breite senkrecht zur
 /// Kante IN der Ebene; alle Ribbons um `CUT_LINE_LIFT` zur Kamera versetzt, damit
 /// sie nicht an der Ebene weggeclippt werden und vor den Caps liegen.
 pub fn build_cut_cap_lines(
    plane: &SectionPlane,
    walls: &[WallInput],
    slabs: &[SlabInput],
 ) -> Vec<f32> {
    let polys = cut_cap_polys(plane, walls, slabs);
    let point = plane.point;
    let u_axis = plane.u_axis();
    let normal = plane.normal;
    // Kamera-waertiger Lift entlang -normal (normal zeigt vom Betrachter ins Modell).
    let lift = [
        -normal[0] * CUT_LINE_LIFT,
        -normal[1] * CUT_LINE_LIFT,
        -normal[2] * CUT_LINE_LIFT,
    ];
    let to_world = |uv: [f32; 2]| -> [f32; 3] {
        [
            point[0] + uv[0] * u_axis[0] + lift[0],
            uv[1] + lift[1],
            point[2] + uv[0] * u_axis[2] + lift[2],
        ]
    };
    let mut verts: Vec<f32> = Vec::new();
    for poly in &polys {
        let Some(r) = rect_of_poly(poly) else {
            continue;
        };
        // Stil aus den Band-Metadaten (oder Default).
        let (color, weight_mm) = match &poly.cut {
            Some(meta) => (
                meta.line_color.unwrap_or(DEFAULT_CUT_LINE_COLOR),
                meta.line_weight.unwrap_or(DEFAULT_CUT_LINE_WEIGHT_MM),
            ),
            None => (DEFAULT_CUT_LINE_COLOR, DEFAULT_CUT_LINE_WEIGHT_MM),
        };
        let half_w = (weight_mm.max(0.0) * CUT_LINE_MM_TO_WORLD * 0.5).max(1e-4);
        // Die vier Rechteck-Ecken (u,v) im Umlauf; je Kante ein Ribbon.
        let corners = [
            [r.u_min, r.v_min],
            [r.u_max, r.v_min],
            [r.u_max, r.v_max],
            [r.u_min, r.v_max],
        ];
        for k in 0..4 {
            let a = to_world(corners[k]);
            let b = to_world(corners[(k + 1) % 4]);
            push_line_ribbon(&mut verts, a, b, normal, half_w, color);
        }
    }
    verts
 }
 /// Legt ein flaches Ribbon-Quad (2 Dreiecke) der halben Breite `half_w` um die
 /// Kante `a`->`b`, verbreitert IN der Schnittebene (senkrecht zur Kante ueber
 /// `cross(normal, dir)`), und schreibt es als 6 Vertices `[pos, color]` in `out`.
 fn push_line_ribbon(
    out: &mut Vec<f32>,
    a: [f32; 3],
    b: [f32; 3],
    normal: [f32; 3],
    half_w: f32,
    color: [f32; 3],
 ) {
    let dir = [b[0] - a[0], b[1] - a[1], b[2] - a[2]];
    let len = (dir[0] * dir[0] + dir[1] * dir[1] + dir[2] * dir[2]).sqrt();
    if len < 1e-9 {
        return;
    }
    let d = [dir[0] / len, dir[1] / len, dir[2] / len];
    // In-Ebene-Senkrechte zur Kante: cross(normal, dir) liegt in der Ebene und
    // steht senkrecht auf der Kante.
    let mut perp = [
        normal[1] * d[2] - normal[2] * d[1],
        normal[2] * d[0] - normal[0] * d[2],
        normal[0] * d[1] - normal[1] * d[0],
    ];
    let plen = (perp[0] * perp[0] + perp[1] * perp[1] + perp[2] * perp[2]).sqrt();
    if plen < 1e-9 {
        return;
    }
    perp = [perp[0] / plen * half_w, perp[1] / plen * half_w, perp[2] / plen * half_w];
    let p0 = [a[0] - perp[0], a[1] - perp[1], a[2] - perp[2]];
    let p1 = [a[0] + perp[0], a[1] + perp[1], a[2] + perp[2]];
    let p2 = [b[0] + perp[0], b[1] + perp[1], b[2] + perp[2]];
    let p3 = [b[0] - perp[0], b[1] - perp[1], b[2] - perp[2]];
    let mut push = |p: [f32; 3]| {
        out.extend_from_slice(&[p[0], p[1], p[2], color[0], color[1], color[2]]);
    };
    // Zwei Dreiecke: p0,p1,p2 und p0,p2,p3.
    push(p0);
    push(p1);
    push(p2);
    push(p0);
    push(p2);
    push(p3);
 }
 #[cfg(test)]
 mod tests {
    use super::*;
    use crate::types::Hatch;
    /// Eine Wand entlang der X-Achse, senkrecht von einer +X-Ebene geschnitten:
    /// die Muster-Id/Winkel/Skalierung der Bauteil-Schraffur muessen in JEDEM
    /// Cap-Vertex an den Positionen 5/6/7 landen (Vertex-Stride = 8).
    #[test]
    fn hatch_muster_id_landet_in_den_cap_vertices() {
        let wall = WallInput {
            start: [0.0, 0.0],
            end: [3.0, 0.0],
            thickness: 0.3,
            height: 2.5,
            base_elevation: 0.0,
            color: [0.8, 0.8, 0.8],
            openings: vec![],
            layers: None,
            holes: vec![],
            material_index: None,
            hatch: Some(Hatch {
                pattern: 3, // crosshatch
                angle: 90.0,
                scale: 2.0,
                line_weight: 0.5,
            }),
            cut: None,
        };
        let plane = SectionPlane::looking_plus_x(1.5);
        let verts = build_cut_caps(&plane, &[wall], &[]);
        assert!(!verts.is_empty(), "Schnitt liefert Cap-Geometrie");
        assert_eq!(
            verts.len() % CAP_FLOATS_PER_VERTEX,
            0,
            "Vertexpuffer ist ein Vielfaches des Strides ({CAP_FLOATS_PER_VERTEX})"
        );
        let n = verts.len() / CAP_FLOATS_PER_VERTEX;
        for i in 0..n {
            let base = i * CAP_FLOATS_PER_VERTEX;
            assert_eq!(verts[base + 5], 3.0, "pattern-Id je Vertex");
            assert!(
                (verts[base + 6] - 90.0_f32.to_radians()).abs() < 1e-5,
                "angle in Radiant"
            );
            assert_eq!(verts[base + 7], 2.0, "scale je Vertex");
            assert_eq!(verts[base + 8], 0.5, "line_weight (mm) je Vertex");
        }
    }
    /// Ohne `hatch` faellt jedes Cap-Polygon auf das Diagonalmuster (Id 2,
    /// angle 0, scale 1) zurueck — das reproduziert das fruehere fixe 45°-Muster.
    #[test]
    fn ohne_hatch_fallback_auf_diagonale() {
        let wall = WallInput {
            start: [0.0, 0.0],
            end: [3.0, 0.0],
            thickness: 0.3,
            height: 2.5,
            base_elevation: 0.0,
            color: [0.8, 0.8, 0.8],
            openings: vec![],
            layers: None,
            holes: vec![],
            material_index: None,
            hatch: None,
            cut: None,
        };
        let plane = SectionPlane::looking_plus_x(1.5);
        let verts = build_cut_caps(&plane, &[wall], &[]);
        assert!(!verts.is_empty());
        assert_eq!(verts[5], FALLBACK_PATTERN, "Fallback = Diagonale (2)");
        assert_eq!(verts[6], 0.0, "Fallback-Winkel 0");
        assert_eq!(verts[7], 1.0, "Fallback-Skalierung 1");
        assert_eq!(verts[8], FALLBACK_HATCH_LINE_WEIGHT_MM, "Fallback-Musterlinienstaerke 0.13 mm");
    }
    use crate::types::CutBandMeta;
    /// Ein Wand-Band (Prio 50, volle Hoehe) und ein u-deckungsgleiches Decken-Band
    /// (Prio 100) ueberlappen in einem z-Intervall. Nach `build_cut_caps` (das die
    /// Boolean-Dominanz anwendet) darf im Ueberlappungs-z-Intervall KEINE Wand-
    /// Cap-Geometrie mehr liegen — die geometrische Kernaussage von P1, direkt auf
    /// den erzeugten Welt-Vertices geprueft (nicht bloss „laeuft").
    #[test]
    fn build_cut_caps_wendet_dominanz_an_wand_verliert_ueberlappung() {
        // Wand entlang +X bei x in [0,3], Dicke 0.4, volle Hoehe [0,2.5]; Prio 50.
        let wall = WallInput {
            start: [0.0, 0.0],
            end: [3.0, 0.0],
            thickness: 0.4,
            height: 2.5,
            base_elevation: 0.0,
            color: [0.8, 0.8, 0.8],
            openings: vec![],
            layers: None,
            holes: vec![],
            material_index: None,
            hatch: Some(Hatch { pattern: 2, angle: 0.0, scale: 1.0, line_weight: 0.13 }),
            cut: Some(CutBandMeta {
                join_priority: Some(50),
                component_id: Some("brick".into()),
                line_color: None,
                line_weight: None,
            }),
        };
        // Decken-Slab, deren Umriss die Wand an der Schnittstelle (x=1.5) ueberdeckt,
        // z in [2.0, 2.4]; Prio 100 (Beton laeuft durch, schneidet die Wand).
        let slab = SlabInput {
            outline: vec![[-1.0, -1.0], [4.0, -1.0], [4.0, 1.0], [-1.0, 1.0]],
            z_bottom: 2.0,
            z_top: 2.4,
            color: [0.8, 0.8, 0.8],
            hatch: Some(Hatch { pattern: 1, angle: 0.0, scale: 1.0, line_weight: 0.13 }),
            cut: Some(CutBandMeta {
                join_priority: Some(100),
                component_id: Some("concrete".into()),
                line_color: None,
                line_weight: None,
            }),
        };
        let plane = SectionPlane::looking_plus_x(1.5);
        let verts = build_cut_caps(&plane, &[wall], &[slab]);
        assert!(!verts.is_empty());
        // Die Wand-Caps tragen pattern==2 (diagonal), die Beton-Caps pattern==1
        // (solid). Fuer JEDES Wand-Vertex (pattern 2) muss die Hoehe (v = pos.y,
        // Index 1) AUSSERHALB des Beton-Intervalls [2.0,2.4] liegen.
        let n = verts.len() / CAP_FLOATS_PER_VERTEX;
        let mut wall_verts = 0;
        let mut concrete_verts = 0;
        for i in 0..n {
            let base = i * CAP_FLOATS_PER_VERTEX;
            let y = verts[base + 1];
            let pattern = verts[base + 5];
            if (pattern - 2.0).abs() < 0.5 {
                wall_verts += 1;
                assert!(
                    y <= 2.0 + 1e-3 || y >= 2.4 - 1e-3,
                    "Wand-Cap-Vertex bei v={y} liegt im Beton-z-Intervall (muesste weggeschnitten sein)"
                );
            } else if (pattern - 1.0).abs() < 0.5 {
                concrete_verts += 1;
            }
        }
        assert!(wall_verts > 0, "Wand-Caps vorhanden (ober-/unterhalb des Betons)");
        assert!(concrete_verts > 0, "Beton-Caps vorhanden (voll durchlaufend)");
    }
    /// Reziprok zum vorigen Test (Nutzer-Report 2026-07-08): eine Backstein-WAND
    /// (Prio 50) muss die SCHWAECHEREN Decken-Schichten Estrich (30) und Daemmung
    /// (20) in der u/v-Ueberlappung wegschneiden — wie im 2D-Schnitt. Wir bauen die
    /// Wand als EIN Backstein-Band (Prio 50) und den Boden als zwei duenne Slabs
    /// (Estrich oben, Daemmung darunter), deren z-Intervall die Wand ueberlappt.
    /// Nach der Dominanz darf im Wand-u-Intervall KEINE Estrich-/Daemmung-Cap mehr
    /// liegen (die Wand-Cap dagegen bleibt — Backstein ist dort dominant).
    #[test]
    fn wand_schneidet_schwaechere_decken_schichten() {
        // Backstein-Wand entlang +X, x in [0,3], Dicke 0.4 → u (=y) in [-0.2,0.2],
        // volle Hoehe [0,2.5]; Prio 50, Muster 2 (diagonal).
        let wall = WallInput {
            start: [0.0, 0.0],
            end: [3.0, 0.0],
            thickness: 0.4,
            height: 2.5,
            base_elevation: 0.0,
            color: [0.8, 0.8, 0.8],
            openings: vec![],
            layers: None,
            holes: vec![],
            material_index: None,
            hatch: Some(Hatch { pattern: 2, angle: 0.0, scale: 1.0, line_weight: 0.13 }),
            cut: Some(CutBandMeta {
                join_priority: Some(50),
                component_id: Some("brick".into()),
                line_color: None,
                line_weight: None,
            }),
        };
        // Estrich-Slab (Prio 30, Muster 3 crosshatch), z in [1.0,1.06], deckt die
        // Wand in u ab (Umriss ueber y in [-1,1]).
        let screed = SlabInput {
            outline: vec![[-1.0, -1.0], [4.0, -1.0], [4.0, 1.0], [-1.0, 1.0]],
            z_bottom: 1.0,
            z_top: 1.06,
            color: [0.8, 0.8, 0.8],
            hatch: Some(Hatch { pattern: 3, angle: 0.0, scale: 1.0, line_weight: 0.13 }),
            cut: Some(CutBandMeta {
                join_priority: Some(30),
                component_id: Some("screed".into()),
                line_color: None,
                line_weight: None,
            }),
        };
        // Daemmung-Slab (Prio 20, Muster 4), z in [0.96,1.0], gleiche u-Deckung.
        let insulation = SlabInput {
            outline: vec![[-1.0, -1.0], [4.0, -1.0], [4.0, 1.0], [-1.0, 1.0]],
            z_bottom: 0.96,
            z_top: 1.0,
            color: [0.8, 0.8, 0.8],
            hatch: Some(Hatch { pattern: 4, angle: 0.0, scale: 1.0, line_weight: 0.13 }),
            cut: Some(CutBandMeta {
                join_priority: Some(20),
                component_id: Some("insulation".into()),
                line_color: None,
                line_weight: None,
            }),
        };
        let plane = SectionPlane::looking_plus_x(1.5);
        let verts = build_cut_caps(&plane, &[wall], &[screed, insulation]);
        assert!(!verts.is_empty());
        // Wand-u-Intervall (=y) ist [-0.2,0.2]. Fuer JEDES Estrich- (Muster 3) oder
        // Daemmung-Vertex (Muster 4) muss u AUSSERHALB [-0.2,0.2] liegen — sonst hat
        // der Backstein die schwaechere Schicht dort NICHT weggeschnitten.
        let n = verts.len() / CAP_FLOATS_PER_VERTEX;
        let mut weak_verts = 0;
        for i in 0..n {
            let base = i * CAP_FLOATS_PER_VERTEX;
            let u = verts[base]; // pos.x = y-Welt (Schnitt entlang +X)
            let pattern = verts[base + 5];
            if (pattern - 3.0).abs() < 0.5 || (pattern - 4.0).abs() < 0.5 {
                weak_verts += 1;
                assert!(
                    u <= -0.2 + 1e-3 || u >= 0.2 - 1e-3,
                    "Estrich/Daemmung-Vertex bei u={u} liegt im Backstein-u-Intervall \
                     [-0.2,0.2] (muesste weggeschnitten sein)"
                );
            }
        }
        assert!(weak_verts > 0, "Estrich/Daemmung-Caps existieren (ausserhalb der Wand)");
    }
    /// P2: je ueberlebendem Cut-Cap-Rechteck entstehen 4 Umriss-Kanten als Ribbon-
    /// Dreiecke (4 Kanten * 6 Vertices = 24 Vertices je Rechteck), und Farbe +
    /// Strichstaerke kommen aus dem Band-Stil durch (Farbe je Vertex, Staerke ueber
    /// die Ribbon-Breite messbar).
    #[test]
    fn build_cut_cap_lines_kantenzahl_und_stil() {
        let color = [0.2, 0.4, 0.9];
        let wall = WallInput {
            start: [0.0, 0.0],
            end: [3.0, 0.0],
            thickness: 0.4,
            height: 2.5,
            base_elevation: 0.0,
            color: [0.8, 0.8, 0.8],
            openings: vec![],
            layers: None,
            holes: vec![],
            material_index: None,
            hatch: None,
            cut: Some(CutBandMeta {
                join_priority: Some(50),
                component_id: Some("brick".into()),
                line_color: Some(color),
                line_weight: Some(2.0),
            }),
        };
        let plane = SectionPlane::looking_plus_x(1.5);
        let verts = build_cut_cap_lines(&plane, &[wall.clone()], &[]);
        assert!(!verts.is_empty());
        assert_eq!(
            verts.len() % CUT_LINE_FLOATS_PER_VERTEX,
            0,
            "Vielfaches des Cut-Linien-Strides"
        );
        // EIN Rechteck (keine Dominanz-Subtraktion, lone band) -> 4 Kanten * 6 = 24 Vertices.
        assert_eq!(
            verts.len() / CUT_LINE_FLOATS_PER_VERTEX,
            24,
            "4 Kanten * 6 Vertices je Ribbon"
        );
        // Farbe je Vertex aus dem Stil (Index 3/4/5).
        let n = verts.len() / CUT_LINE_FLOATS_PER_VERTEX;
        for i in 0..n {
            let base = i * CUT_LINE_FLOATS_PER_VERTEX;
            assert!((verts[base + 3] - color[0]).abs() < 1e-6);
            assert!((verts[base + 4] - color[1]).abs() < 1e-6);
            assert!((verts[base + 5] - color[2]).abs() < 1e-6);
        }
        // Strichstaerke kommt durch: eine DICKERE Linie erzeugt ein breiteres Ribbon.
        // Messbar an der (u,v)-Ausdehnung senkrecht zur Kante — hier ueber die
        // world-Bounding-Box-Hoehe der beiden horizontalen Kanten (v-Ausdehnung der
        // gesamten Geometrie) im Vergleich duenn vs. dick.
        let bbox_y = |vs: &[f32]| -> f32 {
            let n = vs.len() / CUT_LINE_FLOATS_PER_VERTEX;
            let mut lo = f32::INFINITY;
            let mut hi = f32::NEG_INFINITY;
            for i in 0..n {
                let y = vs[i * CUT_LINE_FLOATS_PER_VERTEX + 1];
                lo = lo.min(y);
                hi = hi.max(y);
            }
            hi - lo
        };
        let mut thin = wall.clone();
        thin.cut = Some(CutBandMeta {
            join_priority: Some(50),
            component_id: Some("brick".into()),
            line_color: Some(color),
            line_weight: Some(0.2),
        });
        let thin_verts = build_cut_cap_lines(&plane, &[thin], &[]);
        assert!(
            bbox_y(&verts) > bbox_y(&thin_verts) + 1e-4,
            "dickere Strichstaerke -> groessere v-Ausdehnung der Ribbons"
        );
    }
 }
@@ -125,6 +125,185 @@ fn fs_main(in : VsOut) -> @location(0) vec4<f32> {
 }
 "#;
 /// WGSL des TEXTURIERTEN Wand-Pfades (`RenderStyle::Textured`, gpu::textured_pipeline).
 /// GLEICHE Beleuchtung wie `MESH_WGSL` (hemisphaerisches Ambient Himmel/Boden +
 /// Lambert-Directional + Gegen-Fuelllicht + Kantenbetonung) — nur die ALBEDO kommt
 /// aus einer Bild-Textur (`textureSample`) statt aus der Vertexfarbe. Vertex-Layout
 /// [pos vec3, normal vec3, uv vec2]; `Globals` bleibt group(0) binding(0) unveraendert,
 /// die Textur haengt in group(1). Die Weiss-/Hidden-Modi (`mode.x`) sind hier nicht
 /// relevant: `Textured` reicht `mode.x == 0` (Material) durch (siehe gpu.rs).
 pub const MESH_TEXTURED_WGSL: &str = r#"
 struct Globals {
    view_proj     : mat4x4<f32>,
    light_dir     : vec4<f32>,
    sky_color     : vec4<f32>,
    ground_color  : vec4<f32>,
    sun_color     : vec4<f32>,
    mode          : vec4<f32>,
    section_plane : vec4<f32>,
 };
@group(0) @binding(0) var<uniform> globals : Globals;
 // Material-Textur-ARRAY + Sampler (group 1). Sampler mit Repeat/Linear (siehe
 // gpu.rs) -> das weltmassstaebliche UV-Raster kachelt sich ueber die Wandflaechen.
 // Ebene 0 = Fallback-Schachbrett; Ebenen 1..N = per `set_material_textures`
 // hochgeladene Material-Farbkarten. Die Ebene je Vertex kommt aus einem ZWEITEN
 // Vertex-Buffer (@location(3)); `mode.z` traegt die Anzahl gueltiger Ebenen.
@group(1) @binding(0) var tex  : texture_2d_array<f32>;
@group(1) @binding(1) var samp : sampler;
 struct VsIn {
    @location(0) position : vec3<f32>,
    @location(1) normal   : vec3<f32>,
    @location(2) uv       : vec2<f32>,
    // Material-Textur-Ebene dieses Vertex (`-1` = kein Material -> Schachbrett).
    @location(3) layer    : f32,
 };
 struct VsOut {
    @builtin(position) clip_pos : vec4<f32>,
    @location(0) world_normal : vec3<f32>,
    @location(1) uv           : vec2<f32>,
    @location(2) world_pos    : vec3<f32>,
    @location(3) @interpolate(flat) layer : f32,
 };
@vertex
 fn vs_main(in : VsIn) -> VsOut {
    var out : VsOut;
    out.clip_pos = globals.view_proj * vec4<f32>(in.position, 1.0);
    out.world_normal = in.normal;
    out.uv = in.uv;
    out.world_pos = in.position;
    out.layer = in.layer;
    return out;
 }
@fragment
 fn fs_main(in : VsOut) -> @location(0) vec4<f32> {
    // Live-Schnitt-Kappung identisch zur Mesh-Pipeline (mode.y > 0.5 = aktiv).
    if (globals.mode.y > 0.5) {
        if (dot(in.world_pos, globals.section_plane.xyz) + globals.section_plane.w > 0.0) {
            discard;
        }
    }
    let n = normalize(in.world_normal);
    let l = normalize(globals.light_dir.xyz);
    // Hemisphaerisches Ambient (identisch zu MESH_WGSL).
    let hemi_t = clamp(n.y * 0.5 + 0.5, 0.0, 1.0);
    let ambient = mix(globals.ground_color.rgb, globals.sky_color.rgb, hemi_t);
    // Gerichteter Lambert-Anteil (Sonne).
    let diffuse = max(dot(n, l), 0.0) * globals.sun_color.rgb;
    // Gegen-Fuelllicht (identisch zu MESH_WGSL).
    let fill_l = normalize(vec3<f32>(-l.x, abs(l.y) * 0.35 + 0.15, -l.z));
    let fill = max(dot(n, fill_l), 0.0) * globals.sun_color.rgb
        * vec3<f32>(0.24, 0.27, 0.30);
    // Albedo aus dem Material-Textur-Array statt Vertexfarbe. Ebene je Vertex:
    // `layer < 0` (kein Material) -> Ebene 0 (Schachbrett). Sonst auf den
    // gueltigen Bereich [0, mode.z-1] geklemmt (Sicherheit gegen ueberzaehlige
    // Indizes, falls die Material-Menge kleiner ist als erwartet).
    let max_layer = max(i32(globals.mode.z) - 1, 0);
    let li = clamp(i32(round(in.layer)), 0, max_layer);
    let albedo = textureSample(tex, samp, in.uv, li).rgb;
    var shaded = albedo * (ambient + diffuse + fill);
    // Sanfte Kantenbetonung (identisch zu MESH_WGSL).
    let edge = 0.90 + 0.10 * abs(n.y);
    shaded = shaded * edge;
    return vec4<f32>(shaded, 1.0);
 }
 "#;
 /// WGSL des LUFTBILD-Drapierens aufs Gelände (`gpu::aerial_pipeline`). Zeichnet die
 /// TERRAIN-Dreiecke ein zweites Mal, texturiert mit EINEM georeferenzierten Luftbild
 /// (SWISSIMAGE). Die UV kommen NICHT aus einem Vertex-Attribut, sondern werden im
 /// Fragment aus der WELT-Lage (world.x = Ost, world.z = Nord) und der Bild-Bounding-
 /// Box (group 1, Uniform `bbox = (min_x, min_y, max_x, max_y)` in Modell-Metern)
 /// berechnet — dadurch ist die Auflösung PIXELSCHARF (unabhängig von der TIN-Dichte,
 /// anders als die Pro-Vertex-Färbung). Beleuchtung identisch zu `MESH_WGSL`. Vertex-
 /// Layout = das Haupt-Mesh-Layout `[pos, normal, color]` (color wird ignoriert), damit
 /// derselbe Vertex-Puffer (Terrain-Overlay) ohne Re-Meshing genutzt werden kann.
 /// Bild-Zeile 0 liegt im NORDEN (+Y) -> die Textur-v-Achse wird gespiegelt (1 - v).
 pub const MESH_AERIAL_WGSL: &str = r#"
 struct Globals {
    view_proj     : mat4x4<f32>,
    light_dir     : vec4<f32>,
    sky_color     : vec4<f32>,
    ground_color  : vec4<f32>,
    sun_color     : vec4<f32>,
    mode          : vec4<f32>,
    section_plane : vec4<f32>,
 };
@group(0) @binding(0) var<uniform> globals : Globals;
 // Luftbild-Textur + Sampler + Bounding-Box (group 1). `bbox = (min_x, min_y,
 // max_x, max_y)` in Modell-Metern (x = Ost/world.x, y = Nord/world.z).
@group(1) @binding(0) var tex  : texture_2d<f32>;
@group(1) @binding(1) var samp : sampler;
 struct Aerial { bbox : vec4<f32>, };
@group(1) @binding(2) var<uniform> aerial : Aerial;
 struct VsIn {
    @location(0) position : vec3<f32>,
    @location(1) normal   : vec3<f32>,
    @location(2) color    : vec3<f32>,
 };
 struct VsOut {
    @builtin(position) clip_pos : vec4<f32>,
    @location(0) world_normal : vec3<f32>,
    @location(1) world_pos    : vec3<f32>,
 };
@vertex
 fn vs_main(in : VsIn) -> VsOut {
    var out : VsOut;
    out.clip_pos = globals.view_proj * vec4<f32>(in.position, 1.0);
    out.world_normal = in.normal;
    out.world_pos = in.position;
    return out;
 }
@fragment
 fn fs_main(in : VsOut) -> @location(0) vec4<f32> {
    // Live-Schnitt-Kappung identisch zur Mesh-Pipeline (mode.y > 0.5 = aktiv).
    if (globals.mode.y > 0.5) {
        if (dot(in.world_pos, globals.section_plane.xyz) + globals.section_plane.w > 0.0) {
            discard;
        }
    }
    let n = normalize(in.world_normal);
    let l = normalize(globals.light_dir.xyz);
    // Hemisphaerisches Ambient (identisch zu MESH_WGSL).
    let hemi_t = clamp(n.y * 0.5 + 0.5, 0.0, 1.0);
    let ambient = mix(globals.ground_color.rgb, globals.sky_color.rgb, hemi_t);
    let diffuse = max(dot(n, l), 0.0) * globals.sun_color.rgb;
    let fill_l = normalize(vec3<f32>(-l.x, abs(l.y) * 0.35 + 0.15, -l.z));
    let fill = max(dot(n, fill_l), 0.0) * globals.sun_color.rgb
        * vec3<f32>(0.24, 0.27, 0.30);
    // UV aus der Welt-Lage + Bild-Bbox. world.x = Ost, world.z = Nord.
    let span = vec2<f32>(aerial.bbox.z - aerial.bbox.x, aerial.bbox.w - aerial.bbox.y);
    let u = (in.world_pos.x - aerial.bbox.x) / span.x;
    let v = (in.world_pos.z - aerial.bbox.y) / span.y;
    // Bild-Zeile 0 = Nord (+Y) -> v spiegeln. Ausserhalb [0,1] -> Randpixel (Clamp
    // uebernimmt der Sampler mit ClampToEdge).
    let albedo = textureSample(tex, samp, vec2<f32>(u, 1.0 - v)).rgb;
    var shaded = albedo * (ambient + diffuse + fill);
    let edge = 0.90 + 0.10 * abs(n.y);
    shaded = shaded * edge;
    return vec4<f32>(shaded, 1.0);
 }
 "#;
 /// WGSL des Referenz-Bodengitters (grid.rs). Eigene, schlanke `LineList`-Pipeline:
 /// KONSTANTE Farbe (unlit — unabhaengig von Normalen/Licht), nur View-Projektion
 /// aus demselben `Globals`-Uniform (group(0) binding(0)) wie die Mesh-Pipeline.
@@ -178,11 +357,16 @@ fn fs_main(in : VsOut) -> @location(0) vec4<f32> {
 "#;
 /// WGSL der Schnittflaechen-Kappen (Cut-Caps, section_fill.rs / gpu::cap_pipeline).
-/// Eigene TriangleList-Pipeline: schlankes Vertex-Layout [pos vec3, uv vec2],
+/// Eigene TriangleList-Pipeline: Vertex-Layout [pos vec3, uv vec2, hatch vec3],
 /// dieselbe `Globals`-Bind-Group (group(0) binding(0)) wie Mesh/Grid. Die Caps
-/// werden NICHT geclippt (sie SIND die Schnittflaeche). Fragment: prozedurale
+/// werden NICHT geclippt (sie SIND die Schnittflaeche). Fragment: PROZEDURALE
-/// 45-Grad-Diagonalschraffur aus den Ebenen-Koordinaten (u,v) in Modell-Metern —
+/// Bauteil-Schraffur je geschnittener Schicht — Muster/Winkel/Skalierung kommen aus
-/// dunkle Tinte auf hellem Papier, passend zur 2D-Schnittkonvention.
+/// dem `hatch`-Vertex-Attribut (pattern, angle_rad, scale; siehe
 /// `section_fill.rs`/`types::Hatch`). MONOCHROM (dunkle Tinte auf hellem Papier,
 /// passend zur 2D-Schnittkonvention `HATCH_INK`): es variiert das MUSTER, nicht die
 /// Farbe. Muster-Ids: 0 = none (leer/weiss), 1 = solid (Vollton),
 /// 2 = diagonal (Linienschar, `angle` steuert die Neigung — 0° = horizontal, wie
 /// im 2D), 3 = crosshatch (Kreuz), 4 = insulation (Zickzack/Daemmung).
 pub const CAP_WGSL: &str = r#"
 struct Globals {
    view_proj     : mat4x4<f32>,
@@ -198,11 +382,18 @@ struct Globals {
 struct VsIn {
    @location(0) position : vec3<f32>,
    @location(1) uv       : vec2<f32>,
    // hatch: x = Muster-Id, y = Winkel (Radiant), z = Skalierung, w = Musterlinien-
    // Staerke (mm-Papier). Je Cut-Polygon konstant (redundant je Vertex, siehe
    // section_fill.rs).
    @location(2) hatch    : vec4<f32>,
 };
 struct VsOut {
    @builtin(position) clip_pos : vec4<f32>,
    @location(0) uv : vec2<f32>,
    // flat: die Muster-Parameter sind je Flaeche konstant und duerfen nicht
    // interpoliert werden (Muster-Id ist eine Ganzzahl-Auswahl).
    @location(1) @interpolate(flat) hatch : vec4<f32>,
 };
@vertex
@@ -210,27 +401,85 @@ fn vs_main(in : VsIn) -> VsOut {
    var out : VsOut;
    out.clip_pos = globals.view_proj * vec4<f32>(in.position, 1.0);
    out.uv = in.uv;
    out.hatch = in.hatch;
    return out;
 }
 // Ein AA-gekantetes Linienband entlang der Koordinate `s` (in Einheiten von
 // `spacing`): 1 auf der Linie, 0 dazwischen. `fwidth` glaettet blickwinkelrichtig.
 fn line_band(s : f32, half_s : f32) -> f32 {
    let frac = fract(s);
    let dist = min(frac, 1.0 - frac);
    let aa = max(fwidth(s), 1e-5);
    return 1.0 - smoothstep(half_s, half_s + aa, dist);
 }
@fragment
 fn fs_main(in : VsOut) -> @location(0) vec4<f32> {
    // 45-Grad-Diagonalschraffur in Modell-Metern: Linien bei ganzzahligen
    // Vielfachen von `spacing` entlang (u + v). `dist` = Abstand (in Einheiten
    // von `spacing`) zur naechsten Linie; `fwidth` liefert eine bildschirm-
    // groessenrichtige Kantenglaettung (kein Aliasing bei flachem Blickwinkel).
    let spacing = 0.08;   // Linienabstand ~8 cm
    let half    = 0.004;  // halbe Linienbreite ~4 mm (Strich ~8 mm)
    let ink   = vec3<f32>(0.06, 0.06, 0.06);
    let paper = vec3<f32>(0.94, 0.94, 0.94);
-    let s = (in.uv.x + in.uv.y) / spacing;
+    let pattern = i32(round(in.hatch.x));
-    let frac = fract(s);
+    let angle   = in.hatch.y;
-    let dist = min(frac, 1.0 - frac);     // 0 auf der Linie
+    let scale   = max(in.hatch.z, 0.05);
-    let half_s = half / spacing;
+
-    let aa = max(fwidth(s), 1e-5);
+    // none (0): leere (weisse) Schnittflaeche — wie „keine Schraffur" im 2D.
-    let line = 1.0 - smoothstep(half_s, half_s + aa, dist);
+    if (pattern == 0) {
-    let color = mix(paper, ink, line);
+        return vec4<f32>(paper, 1.0);
    }
    // solid (1): Vollton (Poché) — z. B. Beton.
    if (pattern == 1) {
        return vec4<f32>(ink, 1.0);
    }
    // Muster-Koordinaten: (u,v) in Modell-Metern, um `angle` gedreht. Konvention
    // wie die 2D-Schraffur (`hatchPreview.parallelLines`): `angle == 0` ergibt
    // HORIZONTALE Linien (Phasen-Achse = dv), `+angle` dreht die Schar gegen den
    // Uhrzeigersinn wie im 2D-Swatch. `du` laeuft ENTLANG der Linienrichtung, `dv`
    // ist die Quer-/Phasen-Achse. (Frueher lag hier ein fixer 45°-Versatz, weil das
    // Diagonalmuster ueber `du+dv` lief — dadurch war alles 45° verdreht.)
    let ca = cos(angle);
    let sa = sin(angle);
    let du =  in.uv.x * ca + in.uv.y * sa;   // entlang der Linienrichtung
    let dv = -in.uv.x * sa + in.uv.y * ca;   // quer (Phase)
    let spacing = 0.08 * scale;   // Grund-Linienabstand ~8 cm * Skalierung
    // Musterlinien-Staerke PRO Schraffur aus `hatch.w` (mm-Papier, aus dem LineStyle
    // des Hatch — wie die 2D-Schnitt-Schraffur: SIA `hatch-hair` 0.02 mm vs. `thin`
    // 0.13 mm). Dieselbe mm→Welt-Kalibrierung wie die Schicht-Trennlinien
    // (`section_fill::CUT_LINE_MM_TO_WORLD` = 0.01, halbe Breite ×0.5 → Faktor 0.005),
    // damit Schraffur- und Trennlinien-Staerke konsistent skalieren. Kleiner Floor,
    // damit eine Haarlinie nicht ganz verschwindet.
    let half    = max(in.hatch.w * 0.005, 0.0001);
    let half_s  = half / spacing;
    var line = 0.0;
    if (pattern == 2) {
        // diagonal: EINE Linienschar quer zur Phasen-Achse (dv). angle==0 →
        // horizontal; `hatch.angle` (z. B. 45° bei Backstein) dreht sie wie im 2D.
        line = line_band(dv / spacing, half_s);
    } else if (pattern == 3) {
        // crosshatch: zwei Scharen ueber Kreuz (Phase dv + Phase du = +90°). Bei
        // angle==0 horizontal+vertikal, bei 45° (Beton) das gekippte Kreuz — wie 2D.
        line = max(
            line_band(dv / spacing, half_s),
            line_band(du / spacing, half_s)
        );
    } else {
        // insulation (4, Daemmung): Zickzack. Die Quer-Position (dv) folgt einer
        // Dreieckswelle entlang der Lauf-Achse (du) — ein durchgehender Zickzack.
        let cell = spacing * 2.0;
        let a = du / cell;
        let b = dv / cell;
        let tri = abs(fract(a) - 0.5) * 2.0;   // 0..1 Dreieckswelle
        let fb = fract(b);
        let d = min(abs(fb - tri), min(abs(fb - tri + 1.0), abs(fb - tri - 1.0)));
        let aa = max(fwidth(fb) + fwidth(tri), 1e-5);
        let hw = half / cell;
        line = 1.0 - smoothstep(hw, hw + aa, d);
    }
    let color = mix(paper, ink, clamp(line, 0.0, 1.0));
    return vec4<f32>(color, 1.0);
 }
 "#;
@@ -20,6 +20,79 @@ pub type Point2 = [f32; 2];
 /// RGB-Farbe/Albedo, Komponenten in [0,1]. Alpha wird (noch) nicht gebraucht.
 pub type Rgb = [f32; 3];
 /// Schnitt-Schraffur eines Bauteils (fuer den 3D-Live-Schnitt). Rust-seitiges
 /// Minimal-Aequivalent zu `HatchStyle` (src/model/types.ts): nur die drei Felder,
 /// die der prozedurale Cap-Shader (`shaders::CAP_WGSL`) auswertet — Muster-Id,
 /// Winkel und Skalierung. Die Muster-Farbe bleibt MONOCHROM (Tinte auf Papier,
 /// siehe 2D-Direktive `HATCH_INK`) und wandert deshalb bewusst NICHT mit.
 ///
 /// `pattern`: 0 = none (leer/weiss), 1 = solid (Vollton), 2 = diagonal (45°),
 /// 3 = crosshatch (Kreuz), 4 = insulation (Zickzack/Daemmung). Die Zuordnung ist
 /// mit der TS-Seite (`toWalls3d::hatchPatternId`) und dem Shader synchron zu halten.
 #[derive(Debug, Clone, Copy, Serialize, Deserialize)]
 pub struct Hatch {
    /// Muster-Id (siehe oben). Default 0 (none).
    #[serde(default)]
    pub pattern: u32,
    /// Musterdrehung in Grad (Bildschirm-/Schnittebenen-Konvention). Default 0.
    #[serde(default)]
    pub angle: f32,
    /// Grundmassstab (1 = Standardteilung). Default 1.
    #[serde(default = "default_hatch_scale")]
    pub scale: f32,
    /// Strichstaerke der Musterlinien in mm-Papier (aus dem LineStyle des Hatch,
    /// `HatchRender.lineWeight`). Der Cap-Shader (`CAP_WGSL`) setzt die Muster-
    /// linienbreite daraus (mm->Welt wie die Trennlinien), sodass die Schraffur-
    /// Staerke pro Schraffur einstellbar ist (z. B. SIA `hatch-hair` 0.02 mm vs.
    /// `thin` 0.13 mm). Default 0.13 (Alt-Verhalten/Haarlinie).
    #[serde(default = "default_hatch_line_weight", rename = "lineWeight")]
    pub line_weight: f32,
 }
 fn default_hatch_scale() -> f32 {
    1.0
 }
 fn default_hatch_line_weight() -> f32 {
    0.13
 }
 /// Verschneidungs-/Stil-Metadaten EINES geschnittenen Bauteil-Bandes fuer den
 /// 3D-Live-Schnitt — das Rust-Gegenstueck zu den Feldern, mit denen `toSection.ts`
 /// die Schnitt-Boolean-Dominanz (`subtractDominantBands`) rechnet. Rein additiv
 /// (`#[serde(default)]` an jedem Feld); fehlt der ganze Block (`WallInput::cut ==
 /// None`), verhaelt sich der Schnitt wie zuvor (Band nimmt an keiner Subtraktion
 /// teil).
 ///
 /// Da der 3D-Viewer-Pfad je Materiallage EINE eigene `WallInput`/`SlabInput`-Box
 /// emittiert (`toWalls3d`, layered), traegt jede geschnittene Schicht hier IHRE
 /// eigene Prioritaet/Identitaet/Linienstil — die Dominanz-Verschneidung
 /// (`section_boolean.rs`) laeuft dann elementuebergreifend auf den erzeugten
 /// (u,v)-Rechtecken, exakt wie im 2D-Schnitt.
 #[derive(Debug, Clone, Serialize, Deserialize)]
 #[serde(rename_all = "camelCase")]
 pub struct CutBandMeta {
    /// `Component.joinPriority` der Schicht: ein Band mit STRIKT hoeherer
    /// Prioritaet schneidet ein ueberlappendes schwaecheres per Rechteck-
    /// Subtraktion weg (elementuebergreifend). `None` -> keine Teilnahme.
    #[serde(default)]
    pub join_priority: Option<i32>,
    /// `Component.id` der Schicht — steuert die MERGE-Regel (gleiche Komponente +
    /// Prioritaet verschmelzen zu einem Koerper, keine innere Trennlinie). `None`
    /// -> keine Verschmelzung.
    #[serde(default)]
    pub component_id: Option<String>,
    /// Farbe (RGB 0..1) der Schnitt-Umrisslinie dieses Bandes (P2, aus dem
    /// `jointLineStyleId`-LineStyle). `None` -> Default-Schnittkanten-Stil.
    #[serde(default)]
    pub line_color: Option<Rgb>,
    /// Strichstaerke der Schnitt-Umrisslinie in mm-Papier (aus dem LineStyle).
    /// `None` -> Default. Siehe `section_fill::build_cut_cap_lines` fuer die (ehrlich
    /// dokumentierte) mm->Welt-Umsetzung.
    #[serde(default)]
    pub line_weight: Option<f32>,
 }
 /// Eine geflachte Wand: Achse (Mittellinie) Start->Ende im Grundriss, plus Dicke,
 /// Hoehe und Basis-Hoehe. Aus diesen Feldern wird ein extrudiertes Quader-Mesh
 /// erzeugt (Band aus Achse+Dicke, hochgezogen auf `height` ab `base_elevation`).
@@ -66,6 +139,70 @@ pub struct WallInput {
    /// Verhalten unveraendert).
    #[serde(default)]
    pub layers: Option<Vec<WallLayer>>,
    /// Rechteckige LOECHER (Fenster/Tueren) als ECHTE Aussparungen in EINEM
    /// Wandkoerper (siehe `Hole` + `mesh::extrude_wall*`). Default leer.
    ///
    /// Anders als `openings` zerlegt das die Wand NICHT in Pfeiler/Bruestung/
    /// Sturz-Teilquader, sondern stanzt die Loecher in die beiden Langseiten
    /// (Rechteck-Gitter-Zerlegung + Laibungsflaechen). So bildet EIN Koerper
    /// beliebig (auch versetzt uebereinander) angeordnete Oeffnungen ab — das
    /// kann die Segment-Zerlegung nicht. Genutzt vom 3D-Viewer-Pfad der
    /// TS-Ableitung (`toWalls3d`, `layeredWalls:true`); der Schnitt-Pfad
    /// (`layeredWalls:false`) bleibt bei `openings`/Segmentierung.
    ///
    /// `holes` und `openings` schliessen sich im TS-Emitter gegenseitig aus; ist
    /// `holes` gesetzt, ueberspringt `mesh.rs` die Oeffnungs-Segmentierung und
    /// extrudiert den vollen Achsen-Abschnitt mit Loechern.
    #[serde(default)]
    pub holes: Vec<Hole>,
    /// Optionaler Material-Textur-Index fuer den Stil `Textured`: verweist auf eine
    /// per `Renderer::set_material_textures` hochgeladene Material-Farbkarte
    /// (Textur-Array-Ebene, 1-basiert; Ebene 0 ist das Fallback-Schachbrett). Da
    /// der 3D-Viewer-Pfad je Materiallage EINE eigene `WallInput`-Box emittiert
    /// (`toWalls3d`, `layeredWalls:true`), traegt jede Schicht so IHRE Material-
    /// Textur. `None` -> Fallback-Schachbrett (bisheriges Verhalten). Vom
    /// Schnitt/Serde-Pfad (`section.rs`) ignoriert.
    #[serde(default, rename = "materialIndex")]
    pub material_index: Option<u32>,
    /// Optionale Schnitt-Schraffur dieses Wand-Bandes (siehe `Hatch`). Nur der
    /// 3D-Live-Schnitt (`section.rs`/`section_fill.rs`) wertet sie aus, um die
    /// Schnittflaeche im MUSTER des Bauteils zu schraffieren (statt eines fixen
    /// 45°-Musters). `None` -> Fallback-Diagonalmuster (Alt-Verhalten). Da der
    /// 3D-Viewer-Pfad je Materiallage EINE eigene `WallInput`-Box emittiert
    /// (`toWalls3d`, `layeredWalls:true`), traegt jede geschnittene Schicht so
    /// ihre eigene Schraffur.
    #[serde(default)]
    pub hatch: Option<Hatch>,
    /// Schnitt-Verschneidungs-/Linienstil-Metadaten dieses Wand-Bandes (siehe
    /// `CutBandMeta`). Nur der 3D-Live-Schnitt (`section_fill`/`section_boolean`)
    /// wertet sie aus; fehlt sie, bleibt das Alt-Verhalten (keine Dominanz-
    /// Subtraktion, Default-Schnittkante).
    #[serde(default)]
    pub cut: Option<CutBandMeta>,
 }
 /// Ein rechteckiges Loch (Fenster/Tuer) in EINEM Wandkoerper. Siehe
 /// `WallInput::holes`.
 ///
 /// KONVENTION: `from`/`to` sind Achsen-Meter ab `WallInput::start` (0..Wandlaenge,
 /// dieselbe Achse wie `Opening::from`/`to`); `z_bottom`/`z_top` sind ABSOLUTE
 /// Weltmeter (NICHT relativ zu `base_elevation` — anders als `Opening::sill`).
 /// Eine Tuer ist der Sonderfall `z_bottom == base_elevation` (Loch bis zur
 /// Wand-Unterkante). Loecher liegen definitionsgemaess im Wand-INNEREN und
 /// beruehren die gemiterten Enden nicht — die Gehrung (`compute_wall_miters`)
 /// bleibt davon unberuehrt (siehe `mesh`-Moduldoc).
 #[derive(Debug, Clone, Copy, Serialize, Deserialize, Default)]
 pub struct Hole {
    /// Start des Loch-Intervalls entlang der Wandachse (Meter ab `start`).
    pub from: f32,
    /// Ende des Loch-Intervalls entlang der Wandachse (Meter ab `start`).
    pub to: f32,
    /// Absolute Unterkante des Lochs (Weltmeter).
    #[serde(default, rename = "zBottom")]
    pub z_bottom: f32,
    /// Absolute Oberkante des Lochs (Weltmeter).
    #[serde(default, rename = "zTop")]
    pub z_top: f32,
 }
 /// Eine Wandschicht: Dicke + eigene Albedo-Farbe. Siehe `WallInput::layers`.
@@ -122,6 +259,13 @@ pub struct SlabInput {
    /// Albedo-Farbe (RGB 0..1). Default heller Deckenton.
    #[serde(default = "default_slab_color")]
    pub color: Rgb,
    /// Optionale Schnitt-Schraffur der Decke (siehe `Hatch`/`WallInput::hatch`).
    #[serde(default)]
    pub hatch: Option<Hatch>,
    /// Schnitt-Verschneidungs-/Linienstil-Metadaten dieser Decken-Schicht (siehe
    /// `CutBandMeta`/`WallInput::cut`).
    #[serde(default)]
    pub cut: Option<CutBandMeta>,
 }
 fn default_slab_color() -> Rgb {
@@ -139,6 +283,9 @@ pub enum MeshKind {
    /// Importiertes Volumen (Gebaeude/DXF) — neutrales Hellgrau.
    #[default]
    Imported,
    /// Per truck (Profil-Extrusion, `src-tauri/trucksolid`) erzeugter Koerper —
    /// warmes Orange, damit er sich klar von Wand/Decke/Kontext abhebt.
    Extrusion,
 }
 impl MeshKind {
@@ -151,6 +298,8 @@ impl MeshKind {
            MeshKind::Terrain => [0.663, 0.690, 0.635],
            // 0x9fa6ae — neutrales Hellgrau fuer importierte Meshes.
            MeshKind::Imported => [0.624, 0.651, 0.682],
            // Warmes Orange fuer truck-Profil-Extrusionen (Phase-1-Viewer-Beweis).
            MeshKind::Extrusion => [0.85, 0.55, 0.25],
        }
    }
 }
@@ -187,6 +336,20 @@ pub struct MeshInput {
    /// Default-Farbe je `kind` (siehe `effective_color`).
    #[serde(default)]
    pub color: Option<Rgb>,
    /// Optionaler Material-Textur-Index fuer den Stil `Textured` (1-basiert,
    /// Ebene 0 = Fallback-Schachbrett) — analog `WallInput::material_index`.
    /// Bislang nutzen das nur Daecher (`toWalls3d.ts::emitRoofs`); andere
    /// Kontext-Meshes (Terrain/Import) bleiben ohne (`None` -> Schachbrett).
    #[serde(default, rename = "materialIndex")]
    pub material_index: Option<u32>,
    /// Optionale PRO-VERTEX-Albedo (flaches `[r,g,b, r,g,b, ...]`, 0..1) — ein
    /// Wert je Positions-Vertex. Wird u. a. genutzt, um ein SWISSIMAGE-Luftbild
    /// auf das Gelaende-TIN zu „drapieren" (jeder Vertex traegt den Bildpunkt an
    /// seiner Lage). Ist das Array leer oder zu kurz, greift die Einzelfarbe
    /// (`effective_color`) fuer das ganze Mesh. Die Farben werden im Shaded-Pfad
    /// pro Vertex interpoliert (kein Textur-Sampler noetig).
    #[serde(default, rename = "vertexColors")]
    pub vertex_colors: Vec<f32>,
 }
 impl MeshInput {
@@ -249,8 +412,15 @@ fn default_ortho_half_height() -> f32 {
 fn default_near() -> f32 {
    0.05
 }
-fn default_far() -> f32 {
+// `pub(crate)`, damit `web::set_camera` denselben Basiswert als Untergrenze fuer
-    1000.0
+// die modellgroessen-abhaengige Far-Ebene nutzen kann (s. Moduldoc dort).
 // War 1000.0 — Nutzer-Report: Teile des Modells (und das Boden-Referenzgitter)
 // verschwanden abhaengig von Kamera-Distanz/-Winkel. Grosszuegig angehoben,
 // damit im ueblichen Gebrauch (auch grosse/georeferenzierte Situationen) nie
 // etwas am Fern-Clipping haengenbleibt; `set_camera` skaliert ohnehin
 // zusaetzlich mit der tatsaechlichen Modell-Bounding-Box nach oben.
 pub(crate) fn default_far() -> f32 {
    50_000.0
 }
 impl Default for Camera {
@@ -268,14 +438,24 @@ impl Default for Camera {
    }
 }
-/// Die fuenf Kamera-Presets der three.js-Sicht. `Iso` und `Persp` sind
+/// Die Kamera-Presets der Kardinal-/Iso-Sicht (ROADMAP §11). `Persp` ist frei
-/// perspektivisch/frei; `Front`/`Top`/`Side` sind achsparallel (orthografisch).
+/// perspektivisch; alle anderen sind achsparallel bzw. diagonal orthografisch.
 /// `Front`/`Back`/`Side`/`Left` sind die vier Kardinalrichtungen (Vorne/Hinten/
 /// Rechts/Links im UI, s. `View3d` in TopBar.tsx — keine Himmelsrichtungen, da
 /// es noch keinen Nordwinkel gibt); `Iso`/`IsoFrontLeft`/`IsoBackRight`/
 /// `IsoBackLeft` sind die vier OBEREN Iso-Oktanten (untere vier bleiben im
 /// Hochbau ungenutzt) — `Iso` (vorne-oben-rechts) ist der bestehende Default.
 #[derive(Debug, Clone, Copy, PartialEq, Eq, Serialize, Deserialize)]
 pub enum CameraPreset {
    Front,
    Back,
    Top,
    Side,
    Left,
    Iso,
    IsoFrontLeft,
    IsoBackRight,
    IsoBackLeft,
    Persp,
 }
@@ -293,6 +473,38 @@ pub struct Mesh {
 /// Anzahl f32 je Vertex im interleaved Puffer: 3 Position + 3 Normale + 3 Farbe.
 pub const FLOATS_PER_VERTEX: usize = 9;
 /// Ausgabe der TEXTURIERTEN Mesh-Erzeugung (`RenderStyle::Textured`): interleaved
 /// [pos.xyz, normal.xyz, uv.xy] je Vertex plus Indexpuffer. Ein ZWEITER, additiver
 /// Vertex-Pfad neben `Mesh` — der bestehende `[pos, normal, color]`-Pfad (`Mesh`)
 /// bleibt dadurch bitgleich unangetastet. Genutzt nur mit den GPU-Features
 /// (`render`/`window`); serde-frei (reine GPU-Zwischenform), damit der Default-Bau
 /// ohne GPU nichts davon zieht.
 #[derive(Debug, Clone, Default)]
 pub struct TexturedMesh {
    /// Interleaved Vertices: je 8 f32 = [px,py,pz, nx,ny,nz, u,v].
    pub verts: Vec<f32>,
    /// Dreiecks-Indizes (0-basiert auf die Vertices).
    pub indices: Vec<u32>,
    /// Optionaler PARALLELER Puffer: EIN f32 je Vertex = die Material-Textur-
    /// Ebene (Textur-Array-Index) dieses Vertex, oder `-1` fuer „kein Material"
    /// (Fallback-Schachbrett, Ebene 0). Leer, wenn ohne Material-Zuordnung gebaut
    /// (`textured_from_mesh`) — dann bindet die GPU-Schicht einen konstanten
    /// `-1`-Puffer. Als ZWEITER Vertex-Buffer gehalten (nicht in `verts`
    /// interleaved), damit das bestehende `[pos,normal,uv]`-Layout (und die
    /// Geometrie-Paritaets-Tests) bitgleich bleiben.
    pub layers: Vec<f32>,
 }
 /// Anzahl f32 je Vertex im texturierten Puffer: 3 Position + 3 Normale + 2 UV.
 pub const TEXTURED_FLOATS_PER_VERTEX: usize = 8;
 impl TexturedMesh {
    /// Anzahl Vertices im Puffer.
    pub fn vertex_count(&self) -> usize {
        self.verts.len() / TEXTURED_FLOATS_PER_VERTEX
    }
 }
 impl Mesh {
    /// Anzahl Vertices im Puffer.
    pub fn vertex_count(&self) -> usize {
@@ -15,12 +15,13 @@
 // (eye/target/up + Projektionsart) entgegen — die freie Orbit/Pan/Zoom-Interaktion
 // (Yaw/Pitch/Distanz) rechnet weiterhin die TS-Seite (`math::orbit_eye`-Konvention),
 // damit die Maus-UX 1:1 der bestehenden three.js-OrbitControls-Bedienung folgt.
-// `set_view_preset` wendet stattdessen eines der fuenf `View3d`-Praesete
+// `set_view_preset` wendet stattdessen eines der `View3d`-Praesete (front/back/
-// (front/top/side/iso/perspective) direkt ueber `math::preset_camera` an — Front/
+// top/side/left/iso/isoFrontLeft/isoBackRight/isoBackLeft/perspective) direkt
-// Top/Side/Iso werden dabei ECHT orthografisch (`preset_camera`; Iso = echte
+// ueber `math::preset_camera` an — alle ausser Perspective werden dabei ECHT
-// Isometrie ohne perspektivische Verzerrung), was eine reine TS-Orbit-Naeherung
+// orthografisch (`preset_camera`; die Iso-Varianten = echte Isometrie ohne
-// nicht leisten kann. Nach einem Praeset-Sprung bleibt die
+// perspektivische Verzerrung), was eine reine TS-Orbit-Naeherung nicht leisten
-// weitere Navigation frei ueber `set_camera` (kein Lock).
+// kann. Nach einem Praeset-Sprung bleibt die weitere Navigation frei ueber
 // `set_camera` (kein Lock).
 //
 // MODELL-FORMAT: JSON-Struct { walls: WallInput[], slabs: SlabInput[] } — identisch
 // zu `RModel3d` (src/plan/toWalls3d.ts) und zum nativen Tauri-Push (nativeSync.ts).
@@ -113,7 +114,11 @@ pub struct WebModelRenderer {
 /// Decken. Mirror der TS-`fitTargetDist`-Grow-Schleife (Wasm3DViewport.tsx):
 /// Wand-Achsenpunkte auf Basis-/Firsthoehe, Decken-Umriss auf Unter-/Oberkante.
 /// `None` bei leerem Modell.
-fn model_bounds(walls: &[WallInput], slabs: &[SlabInput]) -> Option<([f32; 3], [f32; 3])> {
+fn model_bounds(
    walls: &[WallInput],
    slabs: &[SlabInput],
    meshes: &[MeshInput],
 ) -> Option<([f32; 3], [f32; 3])> {
    let mut min = [f32::INFINITY; 3];
    let mut max = [f32::NEG_INFINITY; 3];
    let mut grow = |x: f32, y: f32, z: f32| {
@@ -146,6 +151,17 @@ fn model_bounds(walls: &[WallInput], slabs: &[SlabInput]) -> Option<([f32; 3], [
            grow(p[0], s.z_top, p[1]);
        }
    }
    // Meshes (Daecher, Extrusionen, Stuetzen UND importierte Gebaeude/Terrain):
    // model (x,y,z=Hoehe) -> world (x, z, y). Ohne sie kann ein Praeset/Fit den
    // (evtl. weit entfernten) Import nicht rahmen.
    for m in meshes {
        let p = &m.positions;
        let mut i = 0;
        while i + 2 < p.len() {
            grow(p[i], p[i + 2], p[i + 1]);
            i += 3;
        }
    }
    if !min[0].is_finite() {
        return None;
    }
@@ -246,7 +262,7 @@ impl WebModelRenderer {
    pub fn set_model(&mut self, json: &str) -> Result<(), JsValue> {
        let model: ModelInput = serde_json::from_str(json)
            .map_err(|e| JsValue::from_str(&format!("Modell parsen: {e}")))?;
-        self.bounds = model_bounds(&model.walls, &model.slabs);
+        self.bounds = model_bounds(&model.walls, &model.slabs, &model.meshes);
        self.renderer
            .upload_model(&self.device, &model.walls, &model.slabs, &model.meshes);
        // Wand-/Decken-Eingabe fuer den Live-Schnitt cachen (Klon, da der Renderer
@@ -299,6 +315,15 @@ impl WebModelRenderer {
    /// (`ortho_half_height` = halbe Sichthoehe in Metern). Die TS-Seite berechnet
    /// `eye` aus Orbit-Winkeln/Distanz oder einem Praeset (front/top/side/iso/persp)
    /// — siehe `useWasm3dRenderer`/`Wasm3DViewport`.
    ///
    /// FAR-EBENE: die feste `Camera::default()`-Far-Ebene (1000 m) reicht bei
    /// grossen georeferenzierten Importen (Suchradius bis 2000 m, Bounding-Kugel
    /// entsprechend gross) nicht mehr — Teile des Modells wurden je nach
    /// Blickwinkel/Distanz VOM FERN-CLIPPING abgeschnitten (Nutzer-Report: "Teile
    /// im 3D nicht sichtbar in einem Winkel"). Die Far-Ebene wird deshalb hier je
    /// Aufruf aus der zuletzt hochgeladenen Modell-Bounding-Box abgeleitet: der
    /// weiteste Bbox-Eckpunkt vom Auge aus + Sicherheitsmarge, mindestens der
    /// bisherige Default (kleine Modelle bleiben unveraendert).
    #[allow(clippy::too_many_arguments)]
    pub fn set_camera(
        &mut self,
@@ -315,6 +340,32 @@ impl WebModelRenderer {
        fov_y: f32,
        ortho_half_height: f32,
    ) {
        let far = match self.bounds {
            Some((min, max)) => {
                let corners = [
                    [min[0], min[1], min[2]],
                    [max[0], min[1], min[2]],
                    [min[0], max[1], min[2]],
                    [max[0], max[1], min[2]],
                    [min[0], min[1], max[2]],
                    [max[0], min[1], max[2]],
                    [min[0], max[1], max[2]],
                    [max[0], max[1], max[2]],
                ];
                let mut max_dist = 0.0f32;
                for c in corners {
                    let dx = c[0] - eye_x;
                    let dy = c[1] - eye_y;
                    let dz = c[2] - eye_z;
                    let d = (dx * dx + dy * dy + dz * dz).sqrt();
                    if d > max_dist {
                        max_dist = d;
                    }
                }
                (max_dist * 1.5).max(crate::types::default_far())
            }
            None => crate::types::default_far(),
        };
        self.camera = Camera {
            eye: [eye_x, eye_y, eye_z],
            target: [target_x, target_y, target_z],
@@ -326,23 +377,30 @@ impl WebModelRenderer {
            },
            fov_y,
            ortho_half_height,
            far,
            ..Camera::default()
        };
    }
-    /// Wendet eines der fuenf Kamera-Praesets der three.js-Sicht
+    /// Wendet eines der Kardinal-/Iso-Kamera-Praesets der three.js-Sicht
-    /// (`front`/`top`/`side`/`iso`/`perspective`, s. `View3d` in TopBar.tsx) auf
+    /// (`front`/`back`/`top`/`side`/`left`/`iso`/`isoFrontLeft`/`isoBackRight`/
-    /// das aktuelle Modell an: Ziel = Modell-Mitte, Distanz = formatfuellend
+    /// `isoBackLeft`/`perspective`, s. `View3d` in TopBar.tsx) auf das aktuelle
-    /// (mirror der TS-`fitTargetDist`); Front/Top/Side/Iso werden orthografisch,
+    /// Modell an: Ziel = Modell-Mitte, Distanz = formatfuellend (mirror der
    /// TS-`fitTargetDist`); alle Presets ausser Perspective werden orthografisch,
    /// nur Perspective ist perspektivisch (`math::preset_camera`). Wirkt erst beim
    /// naechsten `render`. „Praeset = hinspringen, kein Lock" — manuelles
    /// Orbit/Pan/Zoom bleibt danach frei ueber `set_camera` (s. Wasm3DViewport.tsx).
    pub fn set_view_preset(&mut self, preset: &str) -> Result<(), JsValue> {
        let preset = match preset {
            "front" => CameraPreset::Front,
            "back" => CameraPreset::Back,
            "top" => CameraPreset::Top,
            "side" => CameraPreset::Side,
            "left" => CameraPreset::Left,
            "iso" => CameraPreset::Iso,
            "isoFrontLeft" => CameraPreset::IsoFrontLeft,
            "isoBackRight" => CameraPreset::IsoBackRight,
            "isoBackLeft" => CameraPreset::IsoBackLeft,
            "perspective" => CameraPreset::Persp,
            other => {
                return Err(JsValue::from_str(&format!(
@@ -377,11 +435,14 @@ impl WebModelRenderer {
    ///  - `"shaded"`   — beleuchtete Bauteilfarben (Default).
    ///  - `"white"`    — Clay-Look: einheitlich helles Material, beleuchtet
    ///    (identisch zum bisherigen `set_render_mode_white(true)`).
-    ///  - `"textured"` — mangels Textur-Pipeline VORERST identisch zu `"shaded"`
+    ///  - `"textured"` — Material-Farbkarten je Wand-Band aus dem Textur-Array
-    ///    behandelt (KEIN Fake-Stub); Platzhalter fuer eine spaetere Textur-Schicht.
+    ///    (`set_material_textures`), Fallback-Schachbrett fuer Baender ohne Material.
    ///  - `"wireframe"`— nur Modell-Kanten (Feature-Edges), keine Flaechen.
    ///  - `"hidden"`   — Hidden-Line: flach-weisse Flaechen fuellen den Depth-
    ///    Buffer, dunkle Kanten liegen tiefengetestet obenauf (nur sichtbare).
    ///  - `"shaded-edges"` — "Schattiert mit Kanten" (typischer BIM-Look): wie
    ///    `"shaded"` (echte Bauteilfarben), ZUSAETZLICH dunkle Modell-Kanten
    ///    obenauf wie bei `"hidden"`.
    /// Unbekannte Werte fallen auf `"shaded"` zurueck. Wirkt erst beim naechsten
    /// `render`. Loest `set_render_mode_white` ab (das bleibt kompatibel).
    pub fn set_render_style(&mut self, style: &str) -> Result<(), JsValue> {
@@ -431,6 +492,53 @@ impl WebModelRenderer {
        Ok(())
    }
    /// Laedt die Material-Farbkarten fuer den Stil `Textured` als Textur-Array hoch
    /// (`Renderer::set_material_textures`). `rgba` = dicht gepackte RGBA8-Bytes von
    /// `layer_count` Ebenen, JEDE exakt 256×256 (der JS-Aufrufer dekodiert/skaliert
    /// die Material-Bilder, siehe `viewport/materialTextures.ts`). Ebene 0 bleibt
    /// intern das Fallback-Schachbrett; die hochgeladenen Karten belegen die Ebenen
    /// 1..N, auf die `WallInput::materialIndex` (1-basiert) zeigt. `layer_count == 0`
    /// oder zu kleine Daten setzen auf das reine Schachbrett zurueck. Wirkt erst beim
    /// naechsten `render`.
    pub fn set_material_textures(&mut self, rgba: &[u8], layer_count: u32) -> Result<(), JsValue> {
        self.renderer
            .set_material_textures(&self.device, &self.queue, rgba, layer_count);
        Ok(())
    }
    /// Setzt/ersetzt das aufs Gelaende drapierte Luftbild (SWISSIMAGE). `rgba` =
    /// dicht gepackte RGBA8-Bytes (`width*height*4`, zeilenweise von OBEN = Nord),
    /// die der JS-Aufrufer aus der Bild-Data-URL dekodiert (siehe
    /// `viewport/aerialTexture.ts`). `min_x/min_y/max_x/max_y` = Modell-Meter-
    /// Bounding-Box (x = Ost, y = Nord). Ungueltige/leere Eingabe loescht das
    /// Luftbild. Wirkt erst beim naechsten `render`.
    #[allow(clippy::too_many_arguments)]
    pub fn set_aerial_texture(
        &mut self,
        rgba: &[u8],
        width: u32,
        height: u32,
        min_x: f32,
        min_y: f32,
        max_x: f32,
        max_y: f32,
    ) -> Result<(), JsValue> {
        self.renderer.set_aerial_texture(
            &self.device,
            &self.queue,
            rgba,
            width,
            height,
            [min_x, min_y, max_x, max_y],
        );
        Ok(())
    }
    /// Loescht das drapierte Luftbild (Gelaende erscheint wieder einfarbig/shaded).
    pub fn clear_aerial(&mut self) {
        self.renderer.clear_aerial();
    }
    /// Surface an eine neue Pixelgroesse anpassen (DPR beachtet der Aufrufer).
    pub fn resize(&mut self, width: u32, height: u32) {
        let (w, h) = (width.max(1), height.max(1));
@@ -6,6 +6,32 @@
 #[cfg(any(feature = "native2d", feature = "native3d"))]
 mod native;
 // Lock-Datei gegen gleichzeitiges Oeffnen derselben Projektdatei aus zwei
 // App-Instanzen (OS-Advisory-Lock via `fs4`, siehe lock.rs).
 mod lock;
 use std::path::PathBuf;
 use tauri::State;
 /// Fordert den exklusiven Lock fuer eine Projektdatei an. `Ok(())` wenn frei
 /// (oder schon von uns gehalten), sonst `Err(Some(LockInfo))` mit Angaben zur
 /// haltenden Instanz (pid/hostname/timestamp), oder `Err(None)` falls die
 /// Sidecar-Datei gesperrt, aber ihr Info-Block nicht lesbar war.
 #[tauri::command]
 fn acquire_project_lock(
    path: String,
    state: State<lock::LockState>,
 ) -> Result<(), Option<lock::LockInfo>> {
    lock::acquire(&state, &PathBuf::from(path))
 }
 /// Gibt einen von dieser Instanz gehaltenen Lock frei. No-op, wenn der Pfad
 /// nicht gelockt war.
 #[tauri::command]
 fn release_project_lock(path: String, state: State<lock::LockState>) {
    lock::release(&state, &PathBuf::from(path));
 }
 /// Berechnet die Wand-Gehrungen im Rust-Kern und liefert sie ans Frontend.
 #[tauri::command]
 async fn compute_joins(
@@ -40,7 +66,15 @@ fn push_native_walls(walls: serde_json::Value) {
 #[cfg_attr(mobile, tauri::mobile_entry_point)]
 pub fn run() {
-    let builder = tauri::Builder::default().setup(|_app| {
+    let builder = tauri::Builder::default()
        // Native „Speichern unter"-Dialog + Datei-Schreiben aus der Webview.
        // Immer aktiv (unabhaengig von native2d/native3d), damit Datei-Exporte
        // im Tauri-Fenster einen echten Save-Dialog zeigen statt still zu laden.
        .plugin(tauri_plugin_dialog::init())
        .plugin(tauri_plugin_fs::init())
        // Haelt die pro Instanz offen gelockten Projektdatei-Handles (lock.rs).
        .manage(lock::LockState::default())
        .setup(|_app| {
        // Native GPU-Fenster (2D und/oder 3D je nach Feature) auf einem eigenen
        // Thread hochfahren, damit der Tauri-/GTK-Hauptthread frei bleibt.
        #[cfg(any(feature = "native2d", feature = "native3d"))]
@@ -52,10 +86,16 @@ pub fn run() {
    let builder = builder.invoke_handler(tauri::generate_handler![
        compute_joins,
        push_native_scene,
-        push_native_walls
+        push_native_walls,
        acquire_project_lock,
        release_project_lock
    ]);
    #[cfg(not(any(feature = "native2d", feature = "native3d")))]
-    let builder = builder.invoke_handler(tauri::generate_handler![compute_joins]);
+    let builder = builder.invoke_handler(tauri::generate_handler![
        compute_joins,
        acquire_project_lock,
        release_project_lock
    ]);
    builder
        .run(tauri::generate_context!())
@@ -0,0 +1,145 @@
 // Lock-Datei gegen gleichzeitiges Öffnen derselben Projektdatei aus zwei
 // App-Instanzen. Prinzip: ein OS-Advisory-Lock (Crate `fs4`, gepflegter
 // `fs2`-Nachfolger) auf einer Sidecar-Datei `<projektdatei>.lock`, gehalten
 // über ein offenes `File`-Handle im Tauri-`State`. Der OS-Lock fällt beim
 // Prozessende AUTOMATISCH weg (auch bei Absturz) — kein manuelles Aufräumen
 // nötig, keine verwaiste Sperre blockiert dauerhaft: ohne aktiven OS-Lock kann
 // die nächste Instanz dieselbe Sidecar-Datei problemlos wieder exklusiv locken,
 // auch wenn die Datei selbst liegen bleibt.
 //
 // Zusätzlich schreiben wir einen kleinen JSON-Info-Block (pid/hostname/
 // timestamp) in die Sidecar-Datei, damit eine zweite Instanz bei einem
 // Konflikt eine freundliche Meldung zeigen kann ("bereits geöffnet auf …").
 use std::collections::HashMap;
 use std::fs::{File, OpenOptions};
 use std::io::{Read, Seek, SeekFrom, Write};
 use std::path::{Path, PathBuf};
 use std::sync::Mutex;
 use std::time::{SystemTime, UNIX_EPOCH};
 use fs4::fs_std::FileExt;
 use serde::{Deserialize, Serialize};
 /// Info-Block in der Lock-Sidecar-Datei — wer hält den Lock gerade.
 #[derive(Debug, Clone, Serialize, Deserialize)]
 pub struct LockInfo {
    pub pid: u32,
    pub hostname: String,
    /// Unix-Zeitstempel (Sekunden) als String — reicht für eine Anzeige,
    /// keine Notwendigkeit für eine Datumsbibliothek.
    pub timestamp: String,
 }
 impl LockInfo {
    fn current() -> Self {
        LockInfo {
            pid: std::process::id(),
            hostname: hostname(),
            timestamp: SystemTime::now()
                .duration_since(UNIX_EPOCH)
                .map(|d| d.as_secs().to_string())
                .unwrap_or_else(|_| "0".to_string()),
        }
    }
 }
 /// Bester-Versuch-Hostname ohne zusätzliche Abhängigkeit: erst Umgebungs-
 /// variablen (Windows/Unix), sonst das `hostname`-Kommando, sonst "unbekannt".
 fn hostname() -> String {
    for var in ["COMPUTERNAME", "HOSTNAME"] {
        if let Ok(h) = std::env::var(var) {
            if !h.is_empty() {
                return h;
            }
        }
    }
    if let Ok(out) = std::process::Command::new("hostname").output() {
        if out.status.success() {
            if let Ok(s) = String::from_utf8(out.stdout) {
                let s = s.trim();
                if !s.is_empty() {
                    return s.to_string();
                }
            }
        }
    }
    "unbekannt".to_string()
 }
 /// Alle von DIESER Instanz gehaltenen Locks: Projektdatei-Pfad → offenes
 /// File-Handle auf die Sidecar-Lock-Datei. Das Handle hält den OS-Lock, solange
 /// es lebt (Drop/Prozessende gibt ihn automatisch frei).
 #[derive(Default)]
 pub struct LockState(pub Mutex<HashMap<PathBuf, File>>);
 fn sidecar_path(project_path: &Path) -> PathBuf {
    let mut s = project_path.as_os_str().to_os_string();
    s.push(".lock");
    PathBuf::from(s)
 }
 /// Fordert den exklusiven Lock für `project_path` an.
 ///
 /// - Bereits von UNS gehalten (dieselbe Datei nochmal geöffnet) → `Ok(())`.
 /// - Frei → OS-Lock holen, eigenen Info-Block reinschreiben, Handle im State
 ///   behalten, `Ok(())`.
 /// - Von einer ANDEREN Instanz gehalten → `Err(Some(info))` mit deren
 ///   Info-Block (falls lesbar), sonst `Err(None)`.
 pub fn acquire(state: &LockState, project_path: &Path) -> Result<(), Option<LockInfo>> {
    let mut held = state.0.lock().expect("lock state poisoned");
    if held.contains_key(project_path) {
        return Ok(());
    }
    let sidecar = sidecar_path(project_path);
    let file = OpenOptions::new()
        .create(true)
        .read(true)
        .write(true)
        .open(&sidecar)
        .map_err(|_| None)?;
    match FileExt::try_lock_exclusive(&file) {
        Ok(()) => {
            write_info(&file);
            held.insert(project_path.to_path_buf(), file);
            Ok(())
        }
        Err(_) => {
            // Gesperrt von einer anderen Instanz -> deren Info-Block lesen (best effort).
            Err(read_info(&sidecar))
        }
    }
 }
 /// Gibt den von uns gehaltenen Lock für `project_path` frei (schliesst das
 /// File-Handle → OS-Lock fällt weg). No-op, wenn wir diesen Pfad nicht halten.
 pub fn release(state: &LockState, project_path: &Path) {
    let mut held = state.0.lock().expect("lock state poisoned");
    held.remove(project_path);
 }
 /// Schreibt den aktuellen Info-Block (pid/hostname/timestamp dieser Instanz)
 /// in die bereits gelockte Sidecar-Datei. Fehler hier sind nicht fatal — der
 /// Lock selbst (das OS-Lock) steht unabhängig davon schon.
 fn write_info(file: &File) {
    let info = LockInfo::current();
    let Ok(json) = serde_json::to_string(&info) else {
        return;
    };
    let mut f = file;
    let _ = f.set_len(0);
    let _ = f.seek(SeekFrom::Start(0));
    let _ = f.write_all(json.as_bytes());
    let _ = f.flush();
 }
 /// Liest den Info-Block aus einer (von einer anderen Instanz gesperrten)
 /// Sidecar-Datei. `None` wenn die Datei fehlt/kein gültiges JSON enthält.
 fn read_info(sidecar: &Path) -> Option<LockInfo> {
    let mut contents = String::new();
    File::open(sidecar).ok()?.read_to_string(&mut contents).ok()?;
    serde_json::from_str(&contents).ok()
 }
@@ -344,6 +344,12 @@ fn demo_walls() -> Vec<WallInput> {
        color: grey,
        openings: vec![],
        layers: None,
        // Additive Felder (Loecher/Material/Schnitt) — die Demo-Waende nutzen sie
        // nicht; Defaults wie im Serde-Pfad.
        holes: vec![],
        material_index: None,
        hatch: None,
        cut: None,
    };
    vec![
        mk([0.0, 0.0], [6.0, 0.0]),
@@ -1,6 +1,6 @@
 {
  "$schema": "https://schema.tauri.app/config/2",
-  "productName": "cad",
+  "productName": "Dossier",
  "version": "0.1.0",
  "identifier": "ch.dossier.cad",
  "build": {
@@ -10,9 +10,14 @@
  "app": {
    "windows": [
      {
-        "title": "cad",
+        "label": "main",
        "title": "Dossier",
        "width": 1400,
-        "height": 900
+        "height": 900,
        "dragDropEnabled": false,
        "titleBarStyle": "Overlay",
        "hiddenTitle": true,
        "trafficLightPosition": { "x": 20, "y": 22 }
      }
    ],
    "security": {
@@ -0,0 +1,42 @@
 [workspace]
 [package]
 name = "trucksolid"
 version = "0.1.0"
 edition = "2021"
 description = "Profil-Extrusion via truck B-Rep → tesselliertes Mesh für render3d"
 [lib]
 crate-type = ["cdylib", "rlib"]
 [features]
 default = []
 web = [
    "dep:wasm-bindgen",
    "dep:serde_json",
    "dep:console_error_panic_hook",
 ]
 [dependencies]
 serde = { version = "1", features = ["derive"] }
 serde_json = { version = "1", optional = true }
 wasm-bindgen = { version = "0.2", optional = true }
 console_error_panic_hook = { version = "0.1", optional = true }
 # truck-modeling bringt truck-geometry/topology/polymesh transitiv mit (alle
 # auf derselben kompatiblen Version). Nur truck-modeling explizit pinnen —
 # keine separaten geometry/topology-Einträge, die einen Versions-Konflikt erzeugen.
 truck-modeling = "0.3"
 # Mesh-Ebenen-CSG (Boolesche Operationen) — bewusst NICHT truck-modeling-Booleans
 # (instabil bei koinzidenten Flächen, siehe PENDENZEN.md truck-Integration Phase 4).
 # csgrs arbeitet auf Dreiecks-Ebene (BSP-Baum), robust genau in diesem Fall.
 # Gepinnt auf einen Git-Commit (crates.io-Veröffentlichungen 0.16–0.20.1 sind alle
 # wegen einer harten, zurückgezogenen core2-Abhängigkeit nicht installierbar; auf
 # dem unveröffentlichten main-Branch bereits behoben). Nutzerautorisiert (Spike).
 csgrs = { git = "https://github.com/timschmidt/csgrs", rev = "5e7a37a8803d4e56617734687edc9b98f4ebeed7", default-features = false, features = ["f64", "bmesh", "mesh", "earcut"] }
 nalgebra = "0.34"
 [dev-dependencies]
 serde_json = "1"
 [package.metadata.wasm-pack.profile.release]
 wasm-opt = false
@@ -0,0 +1,212 @@
 // Boolesche Operationen (Union/Differenz/Schnitt) zwischen zwei Dreiecks-Meshes.
 // Mesh-Ebenen-CSG via csgrs (BSP-Baum) statt truck-modeling-Booleans — letztere
 // sind bei koinzidenten/tangentialen Flächen instabil (siehe PENDENZEN.md,
 // truck-Integration Phase 4, monstertruck-solid-Spike). csgrs erwies sich im
 // Spike an genau diesem Fall (Extrusion bündig/eingebunden in eine Wand,
 // deckungsgleicher Querschnitt) als exakt korrekt.
 use csgrs::csg::CSG;
 use csgrs::mesh::Mesh as CsgMesh;
 use csgrs::polygon::Polygon;
 use csgrs::triangulated::Triangulated3D;
 use csgrs::vertex::Vertex;
 use nalgebra::Point3;
 use serde::{Deserialize, Serialize};
 /// Eingabe-Mesh für eine boolesche Operation: flache f64-Positionen (Modell-
 /// Meter) + Dreiecks-Indizes. Getrennt von `MeshOutput` (dort f32, da Render-
 /// Ausgabe) — hier f64, da Eingabe aus Modelldaten und Präzision für die BSP-
 /// Klassifikation an koinzidenten Flächen zählt.
 #[derive(Deserialize)]
 pub struct BooleanMeshInput {
    pub a_positions: Vec<f64>,
    pub a_indices: Vec<u32>,
    pub b_positions: Vec<f64>,
    pub b_indices: Vec<u32>,
    /// "union" | "difference" | "intersection"
    pub op: String,
 }
 #[derive(Serialize)]
 pub struct BooleanMeshOutput {
    pub positions: Vec<f32>,
    pub indices: Vec<u32>,
    /// Ob das Ergebnis leer ist (z. B. Schnitt zweier sich nur berührender
    /// Körper) — csgrs liefert das als Trimesh-Fehler statt eines leeren
    /// Meshes zurück, hier auf einen sauberen Fall normalisiert.
    pub empty: bool,
 }
 fn mesh_from_triangles(positions: &[f64], indices: &[u32]) -> Result<CsgMesh<()>, String> {
    if indices.len() % 3 != 0 {
        return Err("indices müssen Dreiecke sein (Vielfaches von 3)".into());
    }
    let n_verts = positions.len() / 3;
    let mut polygons = Vec::with_capacity(indices.len() / 3);
    for tri in indices.chunks(3) {
        let mut pts = [Point3::origin(); 3];
        for (k, &i) in tri.iter().enumerate() {
            let idx = i as usize;
            if idx >= n_verts {
                return Err(format!("Index {idx} außerhalb der Positions-Liste"));
            }
            let o = idx * 3;
            pts[k] = Point3::new(positions[o], positions[o + 1], positions[o + 2]);
        }
        let normal = (pts[1] - pts[0]).cross(&(pts[2] - pts[0]));
        let verts = vec![
            Vertex::new(pts[0], normal),
            Vertex::new(pts[1], normal),
            Vertex::new(pts[2], normal),
        ];
        polygons.push(Polygon::new(verts, ()));
    }
    Ok(CsgMesh::from_polygons(&polygons, ()))
 }
 fn triangles_from_mesh(m: &CsgMesh<()>) -> (Vec<f32>, Vec<u32>) {
    let mut positions: Vec<f32> = Vec::new();
    let mut indices: Vec<u32> = Vec::new();
    let mut next = 0u32;
    m.visit_triangles(|tri| {
        for v in &tri {
            positions.push(v.position.x as f32);
            positions.push(v.position.y as f32);
            positions.push(v.position.z as f32);
        }
        indices.push(next);
        indices.push(next + 1);
        indices.push(next + 2);
        next += 3;
    });
    (positions, indices)
 }
 pub fn boolean_mesh_core(
    a_positions: &[f64],
    a_indices: &[u32],
    b_positions: &[f64],
    b_indices: &[u32],
    op: &str,
 ) -> Result<BooleanMeshOutput, String> {
    let a = mesh_from_triangles(a_positions, a_indices)?;
    let b = mesh_from_triangles(b_positions, b_indices)?;
    let result = match op {
        "union" => a.union(&b),
        "difference" => a.difference(&b),
        "intersection" => a.intersection(&b),
        other => return Err(format!("unbekannte boolesche Operation: {other}")),
    };
    let (positions, indices) = triangles_from_mesh(&result);
    Ok(BooleanMeshOutput {
        empty: indices.is_empty(),
        positions,
        indices,
    })
 }
 #[cfg(test)]
 mod tests {
    use super::*;
    fn cuboid(x: f64, y: f64, z: f64, w: f64, l: f64, h: f64) -> (Vec<f64>, Vec<u32>) {
        let corners = [
            (x, y, z),
            (x + w, y, z),
            (x + w, y + l, z),
            (x, y + l, z),
            (x, y, z + h),
            (x + w, y, z + h),
            (x + w, y + l, z + h),
            (x, y + l, z + h),
        ];
        let mut positions = Vec::with_capacity(24);
        for (cx, cy, cz) in corners {
            positions.push(cx);
            positions.push(cy);
            positions.push(cz);
        }
        // 12 Dreiecke, konsistent nach außen orientiert (Rechte-Hand-Regel).
        let indices: Vec<u32> = vec![
            0, 2, 1, 0, 3, 2, // unten (-z)
            4, 5, 6, 4, 6, 7, // oben (+z)
            0, 5, 4, 0, 1, 5, // -y
            1, 6, 5, 1, 2, 6, // +x
            2, 7, 6, 2, 3, 7, // +y
            3, 4, 7, 3, 0, 4, // -x
        ];
        (positions, indices)
    }
    fn volume_of(positions: &[f32], indices: &[u32]) -> f64 {
        // Divergenztheorem (Tetraeder vom Ursprung), robust für beliebige geschlossene Dreiecksmeshes.
        let mut vol = 0.0f64;
        for tri in indices.chunks(3) {
            let mut p = [[0.0f64; 3]; 3];
            for (k, &i) in tri.iter().enumerate() {
                let o = i as usize * 3;
                p[k] = [
                    positions[o] as f64,
                    positions[o + 1] as f64,
                    positions[o + 2] as f64,
                ];
            }
            vol += (p[0][0] * (p[1][1] * p[2][2] - p[2][1] * p[1][2])
                - p[0][1] * (p[1][0] * p[2][2] - p[2][0] * p[1][2])
                + p[0][2] * (p[1][0] * p[2][1] - p[2][0] * p[1][1]))
                / 6.0;
        }
        vol.abs()
    }
    #[test]
    fn union_of_overlapping_cuboids() {
        let (ap, ai) = cuboid(0.0, 0.0, 0.0, 1.0, 1.0, 1.0);
        let (bp, bi) = cuboid(0.5, 0.5, 0.5, 1.0, 1.0, 1.0);
        let r = boolean_mesh_core(&ap, &ai, &bp, &bi, "union").unwrap();
        assert!(!r.empty);
        assert!((volume_of(&r.positions, &r.indices) - 1.875).abs() < 1e-6);
    }
    #[test]
    fn intersection_of_overlapping_cuboids() {
        let (ap, ai) = cuboid(0.0, 0.0, 0.0, 1.0, 1.0, 1.0);
        let (bp, bi) = cuboid(0.5, 0.5, 0.5, 1.0, 1.0, 1.0);
        let r = boolean_mesh_core(&ap, &ai, &bp, &bi, "intersection").unwrap();
        assert!(!r.empty);
        assert!((volume_of(&r.positions, &r.indices) - 0.125).abs() < 1e-6);
    }
    /// Praxisfall: Extrusion 0.1m in eine Wand eingebunden, deckungsgleicher
    /// Querschnitt — genau der Fall, an dem monstertruck-solid scheiterte.
    #[test]
    fn wall_minus_embedded_extrusion_matching_cross_section() {
        let wall = cuboid(0.0, 0.0, 0.0, 1.0, 1.0, 1.0);
        let embedded = cuboid(0.9, 0.0, 0.0, 1.0, 1.0, 1.0);
        let r = boolean_mesh_core(&wall.0, &wall.1, &embedded.0, &embedded.1, "difference").unwrap();
        assert!(!r.empty);
        assert!((volume_of(&r.positions, &r.indices) - 0.9).abs() < 1e-6);
    }
    #[test]
    fn flush_touching_union_is_exact() {
        let a = cuboid(0.0, 0.0, 0.0, 1.0, 1.0, 1.0);
        let b = cuboid(1.0, 0.0, 0.0, 1.0, 1.0, 1.0);
        let r = boolean_mesh_core(&a.0, &a.1, &b.0, &b.1, "union").unwrap();
        assert!(!r.empty);
        assert!((volume_of(&r.positions, &r.indices) - 2.0).abs() < 1e-6);
    }
    #[test]
    fn rejects_non_triangle_indices() {
        let (ap, _) = cuboid(0.0, 0.0, 0.0, 1.0, 1.0, 1.0);
        let bad_indices = vec![0u32, 1, 2, 3];
        assert!(boolean_mesh_core(&ap, &bad_indices, &ap, &bad_indices, "union").is_err());
    }
    #[test]
    fn rejects_unknown_op() {
        let (ap, ai) = cuboid(0.0, 0.0, 0.0, 1.0, 1.0, 1.0);
        assert!(boolean_mesh_core(&ap, &ai, &ap, &ai, "xor").is_err());
    }
 }
@@ -0,0 +1,546 @@
 // Profil-Extrusion via truck B-Rep. Erzeugt ein tesselliertes Mesh aus einem
 // 2D-Polygon-Querschnitt (XY-Ebene, Modell-Meter) durch lineare Extrusion
 // entlang +Z. Ausgabe ist kompatibel mit render3d::types::MeshInput.
 //
 // truck-Architektur:
 //   truck_modeling::builder  — Vertex/Edge/Wire/Face bauen + tsweep (Validierung)
 //   Tessellierung             — direkt aus den Eingangskoordinaten (Prismen-Geometrie)
 // Bewusst NICHT genutzt: truck-modeling Booleans (instabil upstream).
 // truck-polymesh wird nicht benötigt (keine Tess.-API für Solids in 0.3).
 use serde::{Deserialize, Serialize};
 use truck_modeling::*;
 mod boolean;
 pub use boolean::{boolean_mesh_core, BooleanMeshInput, BooleanMeshOutput};
 /// Flaches [x0,y0, x1,y1, …] Array + Höhe → Extrusion.
 #[derive(Deserialize)]
 pub struct ExtrudePolyInput {
    pub points: Vec<f64>,
    pub height: f64,
    /// Verjüngung 0.0 (Prisma, Default) … 1.0 (Spitze/Kegel-Pyramide). Fehlt
    /// das Feld (ältere Aufrufer), greift serde-Default 0.0 — unverändertes
    /// Prisma-Verhalten.
    #[serde(default)]
    pub taper: f64,
 }
 /// Tesselliertes Mesh, kompatibel mit render3d::types::MeshInput.
 /// positions: flat [x,y,z, …] in Modell-Metern; indices: Dreiecks-Indizes.
 #[derive(Serialize)]
 pub struct MeshOutput {
    pub positions: Vec<f32>,
    pub indices: Vec<u32>,
 }
 /// Extrudiert ein geschlossenes Polygon (≥3 Punkte) um `height` Meter nach +Z,
 /// optional verjüngt (`taper` 0.0 Prisma … 1.0 Spitze/Kegel-Pyramide — linear
 /// zum Schwerpunkt skaliert). Nutzt truck::builder zur Validierung der
 /// Grundfläche; tesselliert dann direkt aus den Koordinaten.
 pub fn extrude_polygon_core(
    pts: &[(f64, f64)],
    height: f64,
    taper: f64,
 ) -> std::result::Result<MeshOutput, String> {
    if pts.len() < 3 {
        return Err("min 3 Punkte".into());
    }
    if height <= 0.0 {
        return Err("height muss > 0 sein".into());
    }
    if !(0.0..=1.0).contains(&taper) {
        return Err("taper muss zwischen 0 und 1 liegen".into());
    }
    // Letzten Punkt entfernen falls er den ersten wiederholt (geschlossener Ring).
    let ring: Vec<(f64, f64)> = {
        let mut r = pts.to_vec();
        if r.len() >= 2 {
            let first = r[0];
            let last = *r.last().unwrap();
            if (first.0 - last.0).abs() < 1e-10 && (first.1 - last.1).abs() < 1e-10 {
                r.pop();
            }
        }
        r
    };
    if ring.len() < 3 {
        return Err("min 3 eindeutige Punkte".into());
    }
    let n = ring.len();
    // ── truck B-Rep: try_attach_plane validiert Planarität und Degenerierung ──
    let verts: Vec<Vertex> = ring
        .iter()
        .map(|&(x, y)| builder::vertex(Point3::new(x, y, 0.0)))
        .collect();
    let edges: Vec<Edge> = (0..n)
        .map(|i| builder::line(&verts[i], &verts[(i + 1) % n]))
        .collect();
    let wire = Wire::from_iter(edges);
    // Gibt Err zurück bei degeneriertem / nicht-ebenem Profil.
    let face = builder::try_attach_plane(&[wire]).map_err(|e| format!("{e}"))?;
    // tsweep erzeugt den Solid — wir nutzen ihn zur Vollständigkeit, auch wenn
    // wir ihn für die Tessellierung nicht direkt traversieren (nur fürs
    // ungetaperte Prisma sinnvoll validiert; Verjüngung ist reine Tessellierung).
    let _solid: Solid = builder::tsweep(&face, Vector3::new(0.0, 0.0, height));
    let centroid = polygon_centroid(&ring);
    // Deckel-/Boden-Triangulierung fuer BELIEBIGE (auch konkave) Profile per
    // Ohr-Clipping — NICHT per Fächer-ab-Vertex-0 (der nur fuer konvexe bzw.
    // von Vertex 0 aus sternfoermige Polygone korrekt ist; bei einem T-Traeger
    // o.ae. erzeugt ein Fächer Phantom-Dreiecke quer durch die konkave Kerbe).
    // `cap_tris` ist bereits in der Konvention orientiert, die der bisherige
    // "Fächer ab Vertex 0" fuer KONVEXE Ringe erzeugt hat (a,b,c mit
    // aufsteigendem Index), sodass die Deck-/Boden-Zuordnung unten unveraendert
    // bleibt.
    let cap_tris = ear_triangulate(&ring);
    // Volle Verjüngung (taper ≈ 1): Spitze statt entartetem Deck-Ring — Kegel/
    // Pyramide als n Boden-Vertices + 1 Spitzen-Vertex, sonst gäbe es
    // Nulldreiecke (Deckfläche + halbe Seitenflächen) mit Kreuzprodukt-Normale
    // (0,0,0) am Deck.
    if taper >= 1.0 - 1e-9 {
        let mut positions: Vec<f32> = Vec::with_capacity((n + 1) * 3);
        for &(x, y) in &ring {
            positions.extend_from_slice(&[x as f32, y as f32, 0.0_f32]);
        }
        positions.extend_from_slice(&[centroid.0 as f32, centroid.1 as f32, height as f32]);
        let apex = n as u32;
        let mut indices: Vec<u32> = Vec::with_capacity((cap_tris.len() + n) * 3);
        // Bodenfläche: wie im Prisma-Fall die zu "oben" umgekehrte Wicklung
        // (CCW von unten).
        for &(a, b, c) in &cap_tris {
            indices.extend_from_slice(&[a as u32, c as u32, b as u32]);
        }
        // Seitenflächen: ein Dreieck je Kante zur Spitze.
        for i in 0..n as u32 {
            let j = (i + 1) % n as u32;
            indices.extend_from_slice(&[i, j, apex]);
        }
        return Ok(MeshOutput { positions, indices });
    }
    // ── Tessellierung (Prisma bei taper=0, sonst Pyramidenstumpf) ──
    // Für ein n-Eck ergeben sich:
    //   Bodenfläche: len(cap_tris) Dreiecke (Ohr-Clipping, konkav-sicher)
    //   Deckfläche:  len(cap_tris) Dreiecke
    //   Seitenflächen: n * 2 Dreiecke (je Kante ein Rechteck → 2 Dreiecke)
    let mut positions: Vec<f32> = Vec::with_capacity(2 * n * 3);
    let mut indices: Vec<u32> = Vec::with_capacity((cap_tris.len() * 2 + n * 2) * 3);
    // Vertices: Boden (0..n-1) gefolgt von Dach (n..2n-1) — Dach zum
    // Schwerpunkt hin um (1-taper) skaliert (taper=0 ⇒ Prisma, unveränderte
    // Kontur; 0<taper<1 ⇒ Pyramidenstumpf).
    let scale = 1.0 - taper;
    for &(x, y) in &ring {
        positions.extend_from_slice(&[x as f32, y as f32, 0.0_f32]);
    }
    for &(x, y) in &ring {
        let tx = centroid.0 + (x - centroid.0) * scale;
        let ty = centroid.1 + (y - centroid.1) * scale;
        positions.extend_from_slice(&[tx as f32, ty as f32, height as f32]);
    }
    let base = 0u32;
    let top = n as u32;
    // Bodenfläche: umgekehrte Wicklung relativ zur Deckfläche (CCW von unten).
    for &(a, b, c) in &cap_tris {
        indices.extend_from_slice(&[base + a as u32, base + c as u32, base + b as u32]);
    }
    // Deckfläche: gleiche Wicklung wie `cap_tris` (CCW von oben).
    for &(a, b, c) in &cap_tris {
        indices.extend_from_slice(&[top + a as u32, top + b as u32, top + c as u32]);
    }
    // Seitenflächen: Rechteck pro Kante → 2 Dreiecke
    for i in 0..n as u32 {
        let j = (i + 1) % n as u32;
        // Unteres Dreieck
        indices.extend_from_slice(&[base + i, base + j, top + i]);
        // Oberes Dreieck
        indices.extend_from_slice(&[base + j, top + j, top + i]);
    }
    Ok(MeshOutput { positions, indices })
 }
 /// Signierte Fläche (Shoelace) — positiv bei CCW-Umlauf.
 fn signed_area_f64(ring: &[(f64, f64)]) -> f64 {
    let n = ring.len();
    let mut a = 0.0;
    let mut j = n - 1;
    for i in 0..n {
        a += ring[j].0 * ring[i].1 - ring[i].0 * ring[j].1;
        j = i;
    }
    a * 0.5
 }
 /// Flächen-gewichteter Schwerpunkt eines einfachen Polygons (nicht der reine
 /// Vertex-Mittelwert, der bei asymmetrischen/konkaven Profilen verzerrt ist).
 /// Fallback auf Vertex-Mittelwert bei (nahezu) entarteter Fläche.
 fn polygon_centroid(ring: &[(f64, f64)]) -> (f64, f64) {
    let n = ring.len();
    let a = signed_area_f64(ring);
    if a.abs() < 1e-12 {
        let (sx, sy) = ring.iter().fold((0.0, 0.0), |(sx, sy), &(x, y)| (sx + x, sy + y));
        return (sx / n as f64, sy / n as f64);
    }
    let mut cx = 0.0;
    let mut cy = 0.0;
    for i in 0..n {
        let (x0, y0) = ring[i];
        let (x1, y1) = ring[(i + 1) % n];
        let cross = x0 * y1 - x1 * y0;
        cx += (x0 + x1) * cross;
        cy += (y0 + y1) * cross;
    }
    (cx / (6.0 * a), cy / (6.0 * a))
 }
 /// Kreuzprodukt (b-a) x (c-a) im Grundriss.
 #[inline]
 fn cross2_f64(a: (f64, f64), b: (f64, f64), c: (f64, f64)) -> f64 {
    (b.0 - a.0) * (c.1 - a.1) - (b.1 - a.1) * (c.0 - a.0)
 }
 /// Liegt p im (a,b,c)-Dreieck? (CCW-orientiert).
 fn point_in_tri_f64(a: (f64, f64), b: (f64, f64), c: (f64, f64), p: (f64, f64)) -> bool {
    let d1 = cross2_f64(a, b, p);
    let d2 = cross2_f64(b, c, p);
    let d3 = cross2_f64(c, a, p);
    let has_neg = d1 < 0.0 || d2 < 0.0 || d3 < 0.0;
    let has_pos = d1 > 0.0 || d2 > 0.0 || d3 > 0.0;
    !(has_neg && has_pos)
 }
 /// Ear-Clipping-Triangulierung eines einfachen (lochfreien) Rings — robust fuer
 /// konvexe UND konkave Profile (z. B. T-Traeger, L-Profil, Freiform). Portiert
 /// von `render3d::mesh::triangulate` (dort fuer Decken/Slabs genutzt) auf f64.
 /// O(n^2), fuer Extrusionsprofile mit wenigen Ecken voellig ausreichend.
 /// Liefert Dreiecke als (a,b,c)-Indextripel (0-basiert auf `ring`), in der
 /// Wicklung des (intern auf CCW normalisierten) Rings.
 fn ear_triangulate(ring: &[(f64, f64)]) -> Vec<(usize, usize, usize)> {
    let n = ring.len();
    if n < 3 {
        return Vec::new();
    }
    let mut idx: Vec<usize> = (0..n).collect();
    if signed_area_f64(ring) < 0.0 {
        idx.reverse();
    }
    let mut tris: Vec<(usize, usize, usize)> = Vec::new();
    let mut guard = 0usize;
    let max_guard = n * n + 16;
    while idx.len() > 3 && guard < max_guard {
        guard += 1;
        let mut clipped = false;
        let m = idx.len();
        for i in 0..m {
            let i_prev = idx[(i + m - 1) % m];
            let i_cur = idx[i];
            let i_next = idx[(i + 1) % m];
            let a = ring[i_prev];
            let b = ring[i_cur];
            let c = ring[i_next];
            if cross2_f64(a, b, c) <= 0.0 {
                continue; // konkav/kollinear -> kein Ohr
            }
            let mut contains = false;
            for &vi in &idx {
                if vi == i_prev || vi == i_cur || vi == i_next {
                    continue;
                }
                if point_in_tri_f64(a, b, c, ring[vi]) {
                    contains = true;
                    break;
                }
            }
            if contains {
                continue;
            }
            tris.push((i_prev, i_cur, i_next));
            idx.remove(i);
            clipped = true;
            break;
        }
        if !clipped {
            break;
        }
    }
    if idx.len() == 3 {
        tris.push((idx[0], idx[1], idx[2]));
    }
    tris
 }
 /// Zylinder-Extrusion (Kreis-Querschnitt), optional verjüngt (Kegel bei
 /// `taper=1.0`). Tesselliert den Kreis in N Segmente und ruft
 /// `extrude_polygon_core` auf.
 pub fn extrude_circle_core(
    cx: f64,
    cy: f64,
    r: f64,
    height: f64,
    taper: f64,
 ) -> std::result::Result<MeshOutput, String> {
    if r <= 0.0 {
        return Err("Radius muss > 0 sein".into());
    }
    let n = ((2.0 * std::f64::consts::PI * r / 0.02).ceil() as usize).max(16);
    let pts: Vec<(f64, f64)> = (0..n)
        .map(|i| {
            let a = 2.0 * std::f64::consts::PI * i as f64 / n as f64;
            (cx + r * a.cos(), cy + r * a.sin())
        })
        .collect();
    extrude_polygon_core(&pts, height, taper)
 }
 // ── WASM-Bindings (nur mit Feature "web") ────────────────────────────────────
 #[cfg(feature = "web")]
 mod web {
    use super::*;
    use wasm_bindgen::prelude::*;
    #[wasm_bindgen(start)]
    pub fn init() {
        console_error_panic_hook::set_once();
    }
    /// Extrudiert ein Polygon-Profil.
    /// Input JSON: `{ "points": [x0,y0,…], "height": 2.5 }`
    /// Output JSON: `{ "positions": […], "indices": […] }` oder JsError.
    #[wasm_bindgen]
    pub fn extrude_polygon(input_json: &str) -> std::result::Result<String, JsError> {
        let input: ExtrudePolyInput =
            serde_json::from_str(input_json).map_err(|e| JsError::new(&e.to_string()))?;
        if input.points.len() % 2 != 0 {
            return Err(JsError::new("points muss x/y-Paare enthalten"));
        }
        let pts: Vec<(f64, f64)> = input
            .points
            .chunks(2)
            .map(|c| (c[0], c[1]))
            .collect();
        let mesh = extrude_polygon_core(&pts, input.height, input.taper)
            .map_err(|e| JsError::new(&e.to_string()))?;
        serde_json::to_string(&mesh).map_err(|e| JsError::new(&e.to_string()))
    }
    /// Extrudiert einen Kreis-Querschnitt (Zylinder, oder Kegel bei `taper=1`).
    /// Input JSON: `{ "cx": 0, "cy": 0, "r": 0.15, "height": 3.0, "taper": 0.0 }`
    #[wasm_bindgen]
    pub fn extrude_circle(input_json: &str) -> std::result::Result<String, JsError> {
        #[derive(serde::Deserialize)]
        struct In {
            cx: f64,
            cy: f64,
            r: f64,
            height: f64,
            #[serde(default)]
            taper: f64,
        }
        let i: In =
            serde_json::from_str(input_json).map_err(|e| JsError::new(&e.to_string()))?;
        let mesh = extrude_circle_core(i.cx, i.cy, i.r, i.height, i.taper)
            .map_err(|e| JsError::new(&e.to_string()))?;
        serde_json::to_string(&mesh).map_err(|e| JsError::new(&e.to_string()))
    }
    /// Boolesche Operation zwischen zwei Dreiecks-Meshes (Mesh-Ebenen-CSG via
    /// csgrs). Input JSON: `{ "a_positions": […], "a_indices": […],
    /// "b_positions": […], "b_indices": […], "op": "union"|"difference"|"intersection" }`
    /// Output JSON: `{ "positions": […], "indices": […], "empty": bool }`
    #[wasm_bindgen]
    pub fn boolean_mesh(input_json: &str) -> std::result::Result<String, JsError> {
        let input: BooleanMeshInput =
            serde_json::from_str(input_json).map_err(|e| JsError::new(&e.to_string()))?;
        let mesh = boolean_mesh_core(
            &input.a_positions,
            &input.a_indices,
            &input.b_positions,
            &input.b_indices,
            &input.op,
        )
        .map_err(|e| JsError::new(&e))?;
        serde_json::to_string(&mesh).map_err(|e| JsError::new(&e.to_string()))
    }
 }
 // ── Tests ─────────────────────────────────────────────────────────────────────
 #[cfg(test)]
 mod tests {
    use super::*;
    #[test]
    fn quad_extrusion_vertex_count() {
        let pts = vec![(0.0, 0.0), (1.0, 0.0), (1.0, 1.0), (0.0, 1.0)];
        let m = extrude_polygon_core(&pts, 2.0, 0.0).unwrap();
        // 2 * 4 = 8 Vertices → 24 Floats
        assert_eq!(m.positions.len(), 8 * 3, "Vertex-Anzahl");
        assert_eq!(m.indices.len() % 3, 0, "unvollständige Dreiecke");
        // Quader: 2*(4-2) + 4*2 = 4 + 8 = 12 Dreiecke
        assert_eq!(m.indices.len(), 12 * 3, "Dreieck-Anzahl für Quader");
    }
    #[test]
    fn l_profile_extrusion() {
        let pts = vec![
            (0.0, 0.0),
            (0.3, 0.0),
            (0.3, 0.1),
            (0.1, 0.1),
            (0.1, 0.3),
            (0.0, 0.3),
        ];
        let m = extrude_polygon_core(&pts, 3.0, 0.0).unwrap();
        assert_eq!(m.indices.len() % 3, 0);
        assert!(!m.positions.is_empty());
    }
    #[test]
    fn cylinder_extrusion() {
        let m = extrude_circle_core(0.0, 0.0, 0.15, 3.0, 0.0).unwrap();
        assert_eq!(m.indices.len() % 3, 0);
        assert!(!m.positions.is_empty());
    }
    #[test]
    fn rejects_too_few_points() {
        assert!(extrude_polygon_core(&[(0.0, 0.0), (1.0, 0.0)], 1.0, 0.0).is_err());
    }
    #[test]
    fn rejects_zero_height() {
        let pts = vec![(0.0, 0.0), (1.0, 0.0), (0.5, 1.0)];
        assert!(extrude_polygon_core(&pts, 0.0, 0.0).is_err());
    }
    #[test]
    fn rejects_taper_out_of_range() {
        let pts = vec![(0.0, 0.0), (1.0, 0.0), (0.5, 1.0)];
        assert!(extrude_polygon_core(&pts, 1.0, 1.5).is_err());
        assert!(extrude_polygon_core(&pts, 1.0, -0.1).is_err());
    }
    /// Kegel-Volumen (taper=1, Kreis-Querschnitt) via Divergenzsatz gegen die
    /// analytische Formel V = π·r²·h/3 geprüft.
    #[test]
    fn cone_taper_one_has_correct_volume() {
        let r = 0.5;
        let h = 2.0;
        let m = extrude_circle_core(0.0, 0.0, r, h, 1.0).unwrap();
        // Spitze ist der letzte Vertex — Boden-Vertices sind alle bei z=0, kein
        // separater Deck-Ring mehr (kein Nulldreieck-Risiko).
        assert_eq!(m.positions.len() % 3, 0);
        let n_verts = m.positions.len() / 3;
        // Boden-N-Eck + 1 Spitze.
        let apex_z = m.positions[(n_verts - 1) * 3 + 2];
        assert!((apex_z as f64 - h).abs() < 1e-6, "Spitze muss bei z=height liegen");
        let mut vol = 0.0f64;
        for tri in m.indices.chunks(3) {
            let mut p = [[0.0f64; 3]; 3];
            for (k, &i) in tri.iter().enumerate() {
                let o = i as usize * 3;
                p[k] = [m.positions[o] as f64, m.positions[o + 1] as f64, m.positions[o + 2] as f64];
            }
            vol += (p[0][0] * (p[1][1] * p[2][2] - p[2][1] * p[1][2])
                - p[0][1] * (p[1][0] * p[2][2] - p[2][0] * p[1][2])
                + p[0][2] * (p[1][0] * p[2][1] - p[2][0] * p[1][1]))
                / 6.0;
        }
        let expected = std::f64::consts::PI * r * r * h / 3.0;
        // Kreis ist n-eck-tesselliert (nicht analytisch exakt) → grobe Toleranz.
        assert!((vol.abs() - expected).abs() / expected < 0.01, "Kegel-Volumen: {} vs {}", vol.abs(), expected);
    }
    /// Pyramidenstumpf (taper=0.5, Quadrat-Querschnitt): Deckfläche muss auf
    /// die Hälfte der Kantenlänge geschrumpft sein, zentriert um den
    /// Schwerpunkt der Grundfläche.
    #[test]
    fn frustum_taper_half_shrinks_top_toward_centroid() {
        let pts = vec![(0.0, 0.0), (2.0, 0.0), (2.0, 2.0), (0.0, 2.0)];
        let m = extrude_polygon_core(&pts, 1.0, 0.5).unwrap();
        // Prisma-Topologie bleibt erhalten (2n Vertices, kein Spitzen-Sonderfall).
        assert_eq!(m.positions.len(), 8 * 3);
        // Deck-Ring: Vertices 4..7. Schwerpunkt der Grundfläche ist (1,1).
        // scale=0.5 ⇒ Ecke (0,0)→(1,1)+0.5*((0,0)-(1,1))=(0.5,0.5).
        let top0 = (m.positions[4 * 3] as f64, m.positions[4 * 3 + 1] as f64);
        assert!((top0.0 - 0.5).abs() < 1e-6 && (top0.1 - 0.5).abs() < 1e-6, "Deck-Ecke: {:?}", top0);
    }
    /// Punkt-in-Polygon (Ray-Casting) für die Korrektheits-Prüfung unten.
    fn point_in_polygon(p: (f64, f64), poly: &[(f64, f64)]) -> bool {
        let n = poly.len();
        let mut inside = false;
        let mut j = n - 1;
        for i in 0..n {
            let (xi, yi) = poly[i];
            let (xj, yj) = poly[j];
            if ((yi > p.1) != (yj > p.1)) && (p.0 < (xj - xi) * (p.1 - yi) / (yj - yi) + xi) {
                inside = !inside;
            }
            j = i;
        }
        inside
    }
    /// T-Träger-Querschnitt (konkav, NICHT von Vertex 0 aus sternförmig) —
    /// genau das Zielprofil aus PENDENZEN/truck-plan.md. Eine Fächer-Triangu-
    /// lierung ab Vertex 0 erzeugt hier Phantom-Dreiecke quer durch die
    /// konkave Kerbe (nachgerechnet: 2 von 6 Fächer-Dreiecken liegen mit ihrem
    /// Schwerpunkt ausserhalb des Profils). Regressionstest fürs Ohr-Clipping.
    #[test]
    fn t_beam_caps_stay_inside_polygon() {
        let pts = vec![
            (1.0, 0.0),
            (2.0, 0.0),
            (2.0, 1.0),
            (3.0, 1.0),
            (3.0, 2.0),
            (0.0, 2.0),
            (0.0, 1.0),
            (1.0, 1.0),
        ];
        let m = extrude_polygon_core(&pts, 1.0, 0.0).unwrap();
        let mut checked = 0;
        for tri in m.indices.chunks(3) {
            let p: Vec<[f32; 3]> = tri
                .iter()
                .map(|&i| {
                    let o = i as usize * 3;
                    [m.positions[o], m.positions[o + 1], m.positions[o + 2]]
                })
                .collect();
            // Nur Deckel/Boden (alle 3 Ecken auf derselben Höhe) prüfen, nicht
            // die Seitenwand-Quads (die spannen z zwischen 0 und height).
            if (p[0][2] - p[1][2]).abs() > 1e-6 || (p[1][2] - p[2][2]).abs() > 1e-6 {
                continue;
            }
            let centroid = (
                (p[0][0] + p[1][0] + p[2][0]) as f64 / 3.0,
                (p[0][1] + p[1][1] + p[2][1]) as f64 / 3.0,
            );
            assert!(
                point_in_polygon(centroid, &pts),
                "Deckel-/Boden-Dreieck-Schwerpunkt {:?} liegt ausserhalb des T-Profils",
                centroid
            );
            checked += 1;
        }
        assert!(checked > 0, "kein Deckel-/Boden-Dreieck gefunden");
    }
 }
@@ -0,0 +1,166 @@
 // Arc — Mittelpunkt + Startpunkt + Endpunkt. Schritte:
 //   1) „Mittelpunkt:" → Punkt
 //   2) „Startpunkt:"   → Punkt (setzt Radius r = |P1−Center| UND Startwinkel a0)
 //   3) „Endpunkt:"     → Punkt (setzt Endwinkel a1; Radius bleibt) → commit
 //
 // Der Bogen läuft CCW von a0 nach a1 (wie DXF-ARC und das `{shape:"arc"}`-
 // Rendering in PlanView). Der Endpunkt wird nur für seinen WINKEL genutzt (auf
 // den Kreis mit Radius r projiziert). In generatePlan/PlanView als glatter
 // SVG-Bogen (`drawingArc`) gerendert.
 import type { Drawing2D } from "../../model/types";
 import { uniqueId } from "../../tools/types";
 import type {
  Command,
  CommandContext,
  CommandResult,
  CommandState,
  DraftShape,
  Project,
  ToolDraft,
  Vec2,
 } from "../types";
 const EPS = 1e-6;
 interface ArcCenter extends CommandState {
  phase: "center";
 }
 interface ArcStart extends CommandState {
  phase: "start";
  center: Vec2;
  cursor: Vec2 | null;
 }
 interface ArcEnd extends CommandState {
  phase: "end";
  center: Vec2;
  r: number;
  a0: number;
  cursor: Vec2 | null;
 }
 type ArcState = ArcCenter | ArcStart | ArcEnd;
 const dist = (a: Vec2, b: Vec2): number => Math.hypot(b.x - a.x, b.y - a.y);
 const angle = (c: Vec2, p: Vec2): number => Math.atan2(p.y - c.y, p.x - c.x);
 /** CCW-Spanne von a0 nach a1, normiert auf (0, 2π]. */
 function sweepOf(a0: number, a1: number): number {
  const TAU = Math.PI * 2;
  const s = ((a1 - a0) % TAU + TAU) % TAU;
  return s < EPS ? TAU : s;
 }
 /** Punkte eines Bogens (CCW a0→a1) für die Vorschau. */
 function arcPts(center: Vec2, r: number, a0: number, a1: number): Vec2[] {
  const sweep = sweepOf(a0, a1);
  const N = Math.max(2, Math.ceil(sweep / (Math.PI / 32)));
  const pts: Vec2[] = [];
  for (let i = 0; i <= N; i++) {
    const t = a0 + (sweep * i) / N;
    pts.push({ x: center.x + r * Math.cos(t), y: center.y + r * Math.sin(t) });
  }
  return pts;
 }
 /** Punkte einer vollen Kreis-Approximation (Radius-Vorschau im „start"-Schritt). */
 function circlePts(center: Vec2, r: number): Vec2[] {
  const N = 48;
  const pts: Vec2[] = [];
  for (let i = 0; i < N; i++) {
    const t = (i / N) * Math.PI * 2;
    pts.push({ x: center.x + r * Math.cos(t), y: center.y + r * Math.sin(t) });
  }
  return pts;
 }
 /** Vorschau (offener Bogen) + HUD (Radius als L, Spanne als W — L/W-Kästchen). */
 function arcDraft(center: Vec2, r: number, a0: number, a1: number, at: Vec2 | null): ToolDraft {
  if (r < EPS) return { preview: [], vertices: [center] };
  const preview: DraftShape[] = [{ kind: "poly", pts: arcPts(center, r, a0, a1), closed: false }];
  const draft: ToolDraft = { preview, vertices: [center] };
  if (at) {
    const deg = (sweepOf(a0, a1) * 180) / Math.PI;
    draft.hud = { at, length: r, angleDeg: deg };
  }
  return draft;
 }
 function appendArc(p: Project, center: Vec2, r: number, a0: number, a1: number, ctx: CommandContext): Project {
  if (r < EPS) return p;
  const d: Drawing2D = {
    id: uniqueId("dr2d"),
    type: "drawing2d",
    levelId: ctx.level.id,
    categoryCode: ctx.defaultCategoryCode,
    geom: { shape: "arc", center, r, a0, a1 },
  };
  return { ...p, drawings2d: [...p.drawings2d, d] };
 }
 const idle = (): [CommandState, CommandResult] => [
  { phase: "center", lastPoint: null },
  { draft: null, done: true },
 ];
 export const arcCommand: Command = {
  name: "arc",
  labelKey: "cmd.arc.label",
  prompt: (s) => {
    const phase = (s as ArcState).phase;
    return phase === "start" ? "cmd.arc.start" : phase === "end" ? "cmd.arc.end" : "cmd.arc.center";
  },
  accepts: () => ["point"],
  options: () => [],
  init: (): ArcCenter => ({ phase: "center", lastPoint: null }),
  onInput: (state, input, ctx): [CommandState, CommandResult] => {
    const s = state as ArcState;
    if (input.kind !== "point") return [s, { draft: null }];
    const pt = input.point;
    if (s.phase === "center") {
      const ns: ArcStart = { phase: "start", center: pt, cursor: pt, lastPoint: pt };
      return [ns, { draft: { preview: [], vertices: [pt] } }];
    }
    if (s.phase === "start") {
      const r = dist(s.center, pt);
      if (r < EPS) return [s, { draft: null }];
      const a0 = angle(s.center, pt);
      const ns: ArcEnd = { phase: "end", center: s.center, r, a0, cursor: pt, lastPoint: pt };
      return [ns, { draft: arcDraft(s.center, r, a0, a0, pt) }];
    }
    // Endpunkt: Endwinkel setzen, Bogen committen.
    const a1 = angle(s.center, pt);
    const { center, r, a0 } = s;
    return [
      { phase: "center", lastPoint: null },
      { draft: null, done: true, commit: (p) => appendArc(p, center, r, a0, a1, ctx) },
    ];
  },
  onMove: (state, point): [CommandState, CommandResult] => {
    const s = state as ArcState;
    if (s.phase === "start") {
      const r = dist(s.center, point);
      const ns: ArcStart = { ...s, cursor: point };
      return [
        ns,
        {
          draft: {
            preview: [{ kind: "poly", pts: circlePts(s.center, r), closed: true }],
            vertices: [s.center],
            hud: { at: point, text: `R: ${r.toFixed(3)}m` },
          },
        },
      ];
    }
    if (s.phase === "end") {
      const a1 = angle(s.center, point);
      const ns: ArcEnd = { ...s, cursor: point };
      return [ns, { draft: arcDraft(s.center, s.r, s.a0, a1, point) }];
    }
    return [s, { draft: null }];
  },
  onConfirm: (): [CommandState, CommandResult] => idle(),
  onCancel: (): [CommandState, CommandResult] => idle(),
 };
@@ -0,0 +1,133 @@
 // Deckenloch — Aussparung (Treppenauge/Schacht) als Engine-Befehl: ein RECHTECK
 // wird aufgezogen (zwei Klicks: erste Ecke → Gegenecke) und der Decke des
 // aktiven Geschosses hinzugefügt, die das Rechteck ENTHÄLT (alle vier Ecken
 // innerhalb des Decken-Umrisses). Gerendert wird das Loch in 2D (Poché-Loch +
 // Randlinien) und 3D (Loch im Slab), s. Ceiling.openings/mergeHoles.
 //
 // Schritte:
 //   1) „Erste Ecke der Aussparung:"  → Punkt
 //   2) „Gegenecke:"                  → Live-Rechteck-Vorschau; Klick committet.
 import { pointInOutline } from "../../geometry/ceiling";
 import type {
  Command,
  CommandContext,
  CommandResult,
  CommandState,
  DraftShape,
  Project,
  ToolDraft,
  Vec2,
 } from "../types";
 /** Vier Eckpunkte eines Rechtecks aus zwei Gegenecken (CCW). */
 function rectCorners(a: Vec2, b: Vec2): Vec2[] {
  const x0 = Math.min(a.x, b.x);
  const x1 = Math.max(a.x, b.x);
  const y0 = Math.min(a.y, b.y);
  const y1 = Math.max(a.y, b.y);
  return [
    { x: x0, y: y0 },
    { x: x1, y: y0 },
    { x: x1, y: y1 },
    { x: x0, y: y1 },
  ];
 }
 interface HoleIdle extends CommandState {
  phase: "start";
 }
 interface HoleRect extends CommandState {
  phase: "corner";
  a: Vec2;
  cursor: Vec2 | null;
 }
 type HoleState = HoleIdle | HoleRect;
 /** Vorschau: aufgezogenes Rechteck + Masse im HUD. */
 function holeDraft(a: Vec2, cursor: Vec2 | null): ToolDraft {
  const pts = cursor ? rectCorners(a, cursor) : [a];
  const preview: DraftShape[] = [{ kind: "poly", pts, closed: !!cursor }];
  const draft: ToolDraft = { preview, vertices: [a] };
  if (cursor) {
    draft.hud = {
      at: cursor,
      text: `${Math.abs(cursor.x - a.x).toFixed(2)} × ${Math.abs(cursor.y - a.y).toFixed(2)} m`,
    };
  }
  return draft;
 }
 /**
 * Fügt die Aussparung der ERSTEN Decke des aktiven Geschosses hinzu, die das
 * Rechteck vollständig enthält (alle 4 Ecken im Umriss). Entartete Rechtecke
 * und Rechtecke ausserhalb jeder Decke werden verworfen (Projekt unverändert).
 */
 function appendCeilingOpening(p: Project, a: Vec2, b: Vec2, ctx: CommandContext): Project {
  const w = Math.abs(b.x - a.x);
  const d = Math.abs(b.y - a.y);
  if (w < 0.05 || d < 0.05) return p;
  const corners = rectCorners(a, b);
  const host = (p.ceilings ?? []).find(
    (c) =>
      c.floorId === ctx.level.id &&
      c.outline.length >= 3 &&
      corners.every((pt) => pointInOutline(pt, c.outline)),
  );
  if (!host) return p;
  return {
    ...p,
    ceilings: (p.ceilings ?? []).map((c) =>
      c.id === host.id ? { ...c, openings: [...(c.openings ?? []), corners] } : c,
    ),
  };
 }
 const idle = (): [CommandState, CommandResult] => [
  { phase: "start", lastPoint: null } as HoleIdle,
  { draft: null, done: true },
 ];
 export const ceilingOpeningCommand: Command = {
  name: "ceilingopening",
  labelKey: "cmd.ceilingOpening.label",
  floorOnly: true,
  prompt: (s) =>
    (s as HoleState).phase === "corner" ? "cmd.ceilingOpening.corner" : "cmd.ceilingOpening.start",
  accepts: () => ["point"],
  options: () => [],
  init: (): HoleIdle => ({ phase: "start", lastPoint: null }),
  onInput: (state, input, ctx): [CommandState, CommandResult] => {
    const s = state as HoleState;
    if (input.kind !== "point") {
      return [s, { draft: s.phase === "corner" ? holeDraft(s.a, s.cursor) : null }];
    }
    if (s.phase !== "corner") {
      const ns: HoleRect = {
        phase: "corner",
        a: input.point,
        cursor: input.point,
        lastPoint: input.point,
      };
      return [ns, { draft: holeDraft(input.point, input.point) }];
    }
    // Zweite Ecke → committen.
    const a = s.a;
    const b = input.point;
    return [
      { phase: "start", lastPoint: null } as HoleIdle,
      { draft: null, done: true, commit: (p) => appendCeilingOpening(p, a, b, ctx) },
    ];
  },
  onMove: (state, point): [CommandState, CommandResult] => {
    const s = state as HoleState;
    if (s.phase !== "corner") return [s, { draft: null }];
    const ns: HoleRect = { ...s, cursor: point };
    return [ns, { draft: holeDraft(s.a, point) }];
  },
  onConfirm: (): [CommandState, CommandResult] => idle(),
  onCancel: (): [CommandState, CommandResult] => idle(),
 };
@@ -68,7 +68,7 @@ function circleDraft(center: Vec2, r: number, at: Vec2 | null): ToolDraft {
  if (r < EPS) return { preview: [], vertices: [center] };
  const preview: DraftShape[] = [{ kind: "poly", pts: circlePts(center, r), closed: true }];
  const draft: ToolDraft = { preview, vertices: [center] };
-  if (at) draft.hud = { at, text: `r ${r.toFixed(2)} m` };
+  if (at) draft.hud = { at, text: `R: ${r.toFixed(3)}m` };
  return draft;
 }
@@ -0,0 +1,152 @@
 // Stütze (Column) als Engine-Befehl — DOSSIER-Audit A4 Tragwerk. Ablauf:
 //   1) „Stütze setzen:" → Klick setzt den Einfügepunkt (Profil-Mitte) → commit.
 //
 // Optionen (togglebar, IMMER sichtbar): Profil Rechteck/Rund. Eine getippte Zahl
 // setzt das Leitmass (Rechteck: Seitenlänge → quadratisch; Rund: Durchmesser)
 // PERSISTENT über Aufrufe — analog `offset`/`extrude`, wo der pick-Schritt auch
 // eine Zahl annimmt. Höhe = Geschosshöhe des aktiven Geschosses (Default).
 //
 // Herkunft der Stützen-Felder (CommandContext):
 //   • floorId     ← ctx.level.id (aktives Geschoss)
 //   • categoryCode← "50" (Tragwerk; Fallback ctx.defaultCategoryCode)
 //   • height      ← Geschosshöhe (ctx.level.floorHeight), Fallback DEF_HEIGHT
 //
 // Bezeichner englisch, sichtbarer Text via t() (CONVENTIONS.md).
 import type { Column, ColumnProfile } from "../../model/types";
 import { uniqueId } from "../../tools/types";
 import { columnFootprint } from "../../geometry/column";
 import type {
  Command,
  CommandContext,
  CommandResult,
  CommandState,
  CmdOption,
  Project,
  Vec2,
 } from "../types";
 /** Default-Ebene (Kategorie) für Stützen: „50" Tragwerk (Fallback: aktive). */
 const COLUMN_CATEGORY = "50";
 /** Default-Kantenlänge eines Rechteckprofils (Meter). */
 const DEF_SIZE = 0.3;
 /** Fallback-Höhe, falls das Geschoss keine floorHeight trägt (Meter). */
 const DEF_HEIGHT = 2.6;
 // ── Persistente Defaults (modulweit, leben über Befehls-Instanzen hinweg) ────
 const columnDefaults: { kind: "rect" | "round"; size: number } = {
  kind: "rect",
  size: DEF_SIZE,
 };
 /** Baut das aktuelle Default-Profil aus `columnDefaults`. */
 function currentProfile(): ColumnProfile {
  if (columnDefaults.kind === "round") {
    return { kind: "round", radius: columnDefaults.size / 2 };
  }
  return { kind: "rect", width: columnDefaults.size, depth: columnDefaults.size };
 }
 /** Fügt die Stütze immutabel an `project.columns` an. */
 function appendColumn(
  p: Project,
  position: Vec2,
  ctx: CommandContext,
 ): Project {
  const height =
    ctx.level.floorHeight != null && ctx.level.floorHeight > 0
      ? ctx.level.floorHeight
      : DEF_HEIGHT;
  const column: Column = {
    id: uniqueId("column"),
    type: "column",
    floorId: ctx.level.id,
    categoryCode: COLUMN_CATEGORY,
    position,
    profile: currentProfile(),
    rotation: 0,
    height,
  };
  return { ...p, columns: [...(p.columns ?? []), column] };
 }
 interface ColState extends CommandState {
  phase: "place" | "done";
 }
 const finish = (): [CommandState, CommandResult] => [
  { phase: "done", lastPoint: null } as ColState,
  { draft: null, done: true },
 ];
 /** Footprint-Vorschau des aktuellen Default-Profils am Cursor. */
 function previewAt(pt: Vec2): CommandResult {
  const ghost: Column = {
    id: "_preview",
    type: "column",
    floorId: "",
    categoryCode: COLUMN_CATEGORY,
    position: pt,
    profile: currentProfile(),
    rotation: 0,
    height: 0,
  };
  const size =
    columnDefaults.kind === "round"
      ? `Ø${(columnDefaults.size * 100).toFixed(0)}`
      : `${(columnDefaults.size * 100).toFixed(0)}×${(columnDefaults.size * 100).toFixed(0)}`;
  return {
    draft: {
      preview: [{ kind: "poly", pts: columnFootprint(ghost), closed: true }],
      vertices: [],
      hud: { at: pt, text: size },
    },
  };
 }
 export const columnCommand: Command = {
  name: "column",
  labelKey: "cmd.column.label",
  prompt: () => "cmd.column.place",
  accepts: () => ["point", "number", "option"],
  options: (): CmdOption[] => [
    {
      id: "profile",
      labelKey: "cmd.column.profile",
      value: columnDefaults.kind === "round" ? "round" : "rect",
    },
  ],
  floorOnly: true,
  init: (): ColState => ({ phase: "place", lastPoint: null }),
  onInput: (state, input, ctx): [CommandState, CommandResult] => {
    const s = state as ColState;
    if (s.phase === "done") return finish();
    if (input.kind === "number") {
      const v = Math.abs(input.value);
      if (v > 1e-4) columnDefaults.size = v;
      return [s, { draft: null }];
    }
    if (input.kind === "option" && input.id === "profile") {
      columnDefaults.kind = columnDefaults.kind === "round" ? "rect" : "round";
      return [s, { draft: null }];
    }
    if (input.kind === "point") {
      return [
        { phase: "done", lastPoint: null } as ColState,
        { draft: null, done: true, commit: (p) => appendColumn(p, input.point, ctx) },
      ];
    }
    return [s, { draft: null }];
  },
  onMove: (state, point): [CommandState, CommandResult] => {
    const s = state as ColState;
    if (s.phase !== "place") return [s, { draft: null }];
    return [s, previewAt(point)];
  },
  onConfirm: (): [CommandState, CommandResult] => finish(),
  onCancel: (): [CommandState, CommandResult] => finish(),
 };
@@ -42,10 +42,20 @@ function targetFromFields(base: Vec2, locks: Record<string, number>, cursor: Vec
 }
 function hasSelection(sel: CommandSelection): boolean {
-  return sel.wallIds.length > 0 || sel.drawingId !== null;
+  return (
    sel.wallIds.length > 0 ||
    sel.drawingId !== null ||
    !!sel.extrudedSolidId ||
    !!sel.columnId
  );
 }
 function toTransformSel(sel: CommandSelection): TransformSelection {
-  return { wallIds: sel.wallIds, drawingId: sel.drawingId };
+  return {
    wallIds: sel.wallIds,
    drawingId: sel.drawingId,
    extrudedSolidId: sel.extrudedSolidId,
    columnId: sel.columnId,
  };
 }
 interface CopyBase extends CommandState {
@@ -0,0 +1,287 @@
 // Extrudieren — truck-Integration Phase 3 (docs/design/truck-plan.md, PENDENZEN
 // "truck-Integration"). Erzeugt aus einer geschlossenen 2D-Kurve (Polylinie-Ring,
 // Rechteck oder Kreis) einen 3D-Körper: Schritte:
 //   1) Profil bestimmen: ist genau EIN passendes geschlossenes Drawing2D
 //      selektiert, wird es genommen; sonst „Profil wählen:" → Klick auf einen Ring.
 //   2) „Höhe:" → Zahl tippen (PERSISTENT als Default über Aufrufe) ODER Enter
 //      bestätigt den zuletzt genutzten Default.
 //   3) „Verjüngung:" → Zahl 0..1 tippen (0=Prisma/Default, 1=Spitze — Kegel bei
 //      Kreis-, Pyramide bei Polygon-Profil) ODER Enter für den zuletzt
 //      genutzten Default (persistent, wie Höhe). → commit neues ExtrudedSolid.
 //
 // Die eigentliche Extrusion (truck-WASM) läuft asynchron erst in toWalls3d.ts
 // (emitExtrudedSolids); dieser Befehl legt nur die Rohdaten (Punkte + Höhe +
 // Verjüngung) im Projekt ab.
 import type { Drawing2D, ExtrudedSolid } from "../../model/types";
 import { uniqueId } from "../../tools/types";
 import { polylineEdges, pointSegmentDistance } from "../../geometry/kernel2d";
 import type {
  Command,
  CommandContext,
  CommandResult,
  CommandSelection,
  CommandState,
  Project,
  Vec2,
 } from "../types";
 const HIT_TOL = 0.25; // Modell-Meter: Pick-Toleranz für die Profil-Wahl
 /** Persistente Extrusionshöhe über Aufrufe hinweg (Default: Geschosshöhe). */
 let lastHeight = 2.6;
 /** Persistente Verjüngung über Aufrufe hinweg (Default: Prisma, kein Kegel/Pyramide). */
 let lastTaper = 0;
 // ── Profil-Abstraktion: geschlossene polyline/rect/circle → Punktliste ─────
 /** Kreis-Tessellierung für Footprint/Auswahl/bbox (48-Eck, wie circle.ts). */
 function circlePts(center: Vec2, r: number): Vec2[] {
  const N = 48;
  const pts: Vec2[] = [];
  for (let i = 0; i < N; i++) {
    const t = (i / N) * Math.PI * 2;
    pts.push({ x: center.x + r * Math.cos(t), y: center.y + r * Math.sin(t) });
  }
  return pts;
 }
 /** Ein extrudierfähiges Profil: Tessellierung + optional die echte Kreis-Geometrie. */
 interface Profile {
  pts: Vec2[];
  circle?: { center: Vec2; r: number };
 }
 /** Wandelt ein extrudierfähiges (geschlossenes) Drawing2D in ein Profil. */
 function geomToProfile(d: Drawing2D): Profile | null {
  const g = d.geom;
  if (g.shape === "polyline" && g.closed && g.pts.length >= 3) return { pts: g.pts };
  if (g.shape === "rect") {
    return { pts: [g.min, { x: g.max.x, y: g.min.y }, g.max, { x: g.min.x, y: g.max.y }] };
  }
  if (g.shape === "circle") {
    return { pts: circlePts(g.center, g.r), circle: { center: g.center, r: g.r } };
  }
  return null;
 }
 /** Genau ein passendes Drawing2D vorselektiert? Dann liefere sein Profil. */
 function singleSelectedProfile(
  project: Project,
  sel: CommandSelection,
 ): ({ d: Drawing2D } & Profile) | null {
  if (!sel.drawingId || sel.wallIds.length > 0) return null;
  const d = project.drawings2d.find((x) => x.id === sel.drawingId);
  if (!d) return null;
  const profile = geomToProfile(d);
  return profile ? { d, ...profile } : null;
 }
 /** Nächstes extrudierfähige Drawing2D zum Klickpunkt (innerhalb Toleranz). */
 function pickProfileAt(
  project: Project,
  levelId: string,
  pt: Vec2,
 ): ({ d: Drawing2D } & Profile) | null {
  let best: ({ d: Drawing2D } & Profile) | null = null;
  let bestD = HIT_TOL;
  for (const d of project.drawings2d) {
    if (d.levelId !== levelId) continue;
    const profile = geomToProfile(d);
    if (!profile) continue;
    for (const [a, b] of polylineEdges(profile.pts, true)) {
      const dd = pointSegmentDistance(pt, a, b);
      if (dd < bestD) {
        bestD = dd;
        best = { d, ...profile };
      }
    }
  }
  return best;
 }
 /**
 * Hängt den neuen Körper an UND entfernt das Quell-Profil (`sourceId`) aus
 * `drawings2d` — die Polylinie/das Rechteck WIRD zur Extrusion, sie bleibt
 * nicht als unabhängiges Duplikat liegen (sonst zwei Objekte am selben Ort,
 * eines davon im Grundriss unsichtbar verwaist).
 */
 function appendExtrudedSolid(
  p: Project,
  profile: Profile,
  height: number,
  taper: number,
  sourceId: string,
  ctx: CommandContext,
 ): Project {
  const solid: ExtrudedSolid = {
    id: uniqueId("extrude"),
    type: "extrudedSolid",
    levelId: ctx.level.id,
    points: profile.pts,
    height,
    circle: profile.circle,
    ...(taper > 0 ? { taper } : {}),
  };
  return {
    ...p,
    drawings2d: p.drawings2d.filter((d) => d.id !== sourceId),
    extrudedSolids: [...(p.extrudedSolids ?? []), solid],
  };
 }
 // ── Zustand ───────────────────────────────────────────────────────────────────
 interface ExPick extends CommandState {
  phase: "pick";
 }
 interface ExHeight extends CommandState {
  phase: "height";
  profile: Profile;
  /** Id des Quell-Drawing2D, das beim Commit ersetzt (entfernt) wird. */
  sourceId: string;
  cursor: Vec2 | null;
 }
 interface ExTaper extends CommandState {
  phase: "taper";
  profile: Profile;
  sourceId: string;
  height: number;
  cursor: Vec2 | null;
 }
 interface ExDone extends CommandState {
  phase: "done";
 }
 type ExState = ExPick | ExHeight | ExTaper | ExDone;
 const finish = (): [CommandState, CommandResult] => [
  { phase: "done", lastPoint: null } as ExDone,
  { draft: null, done: true },
 ];
 /** Höhe entgegengenommen → Verjüngungs-Schritt betreten (HUD zeigt Default). */
 const enterTaperPhase = (
  profile: Profile,
  height: number,
  sourceId: string,
 ): [CommandState, CommandResult] => [
  { phase: "taper", profile, sourceId, height, cursor: null } as ExTaper,
  { draft: null },
 ];
 const commitTaper = (
  profile: Profile,
  height: number,
  taper: number,
  sourceId: string,
  ctx: CommandContext,
 ): [CommandState, CommandResult] => [
  { phase: "done", lastPoint: null } as ExDone,
  { draft: null, done: true, commit: (p) => appendExtrudedSolid(p, profile, height, taper, sourceId, ctx) },
 ];
 export const extrudeCommand: Command = {
  name: "extrude",
  labelKey: "cmd.extrude.label",
  prompt: (s) => {
    const phase = (s as ExState).phase;
    if (phase === "height") return "cmd.extrude.height";
    if (phase === "taper") return "cmd.extrude.taper";
    return "cmd.extrude.pick";
  },
  // Auch der „pick"-Schritt nimmt eine Zahl an, damit eine getippte Höhe sofort
  // greift, wenn ein Profil vorselektiert ist (dann wird „pick" live wie
  // „height" behandelt — analog offset.ts).
  accepts: () => ["point", "number"],
  options: () => [],
  floorOnly: true,
  init: (): ExPick => ({ phase: "pick", lastPoint: null }),
  onInput: (state, input, ctx): [CommandState, CommandResult] => {
    const s = state as ExState;
    if (s.phase === "done") return finish();
    if (s.phase === "pick") {
      const pre = singleSelectedProfile(ctx.project, ctx.selection);
      if (pre) {
        if (input.kind === "number") {
          const h = Math.abs(input.value);
          if (h < 1e-6) return [s, { draft: null }];
          lastHeight = h;
          return enterTaperPhase(pre, h, pre.d.id);
        }
        // Punkt im vorselektierten Fall: Höhen-Schritt betreten (HUD zeigt Default).
        const ns: ExHeight = { phase: "height", profile: pre, sourceId: pre.d.id, cursor: null, lastPoint: null };
        return [ns, { draft: null }];
      }
      if (input.kind === "point") {
        const hit = pickProfileAt(ctx.project, ctx.level.id, input.point);
        if (!hit) return [s, { draft: null }];
        const ns: ExHeight = { phase: "height", profile: hit, sourceId: hit.d.id, cursor: null, lastPoint: null };
        return [ns, { draft: null }];
      }
      return [s, { draft: null }];
    }
    if (s.phase === "height") {
      if (input.kind === "number") {
        const h = Math.abs(input.value);
        if (h < 1e-6) return [s, { draft: null }];
        lastHeight = h;
        return enterTaperPhase(s.profile, h, s.sourceId);
      }
      return [s, { draft: null }];
    }
    // phase === "taper"
    const ts = s as ExTaper;
    if (input.kind === "number") {
      const t = Math.min(1, Math.max(0, input.value));
      lastTaper = t;
      return commitTaper(ts.profile, ts.height, t, ts.sourceId, ctx);
    }
    return [ts, { draft: null }];
  },
  onMove: (state, point): [CommandState, CommandResult] => {
    const s = state as ExState;
    if (s.phase === "height") {
      const ns: ExHeight = { ...s, cursor: point };
      return [
        ns,
        {
          draft: {
            preview: [{ kind: "poly", pts: s.profile.pts, closed: true }],
            vertices: [],
            hud: { at: point, text: `${lastHeight.toFixed(2)} m` },
          },
        },
      ];
    }
    if (s.phase === "taper") {
      const ns: ExTaper = { ...s, cursor: point };
      return [
        ns,
        {
          draft: {
            preview: [{ kind: "poly", pts: s.profile.pts, closed: true }],
            vertices: [],
            hud: { at: point, text: lastTaper.toFixed(2) },
          },
        },
      ];
    }
    return [s, { draft: null }];
  },
  // Enter/Rechtsklick: Höhen-Schritt → Default-Höhe übernehmen + Verjüngungs-
  // Schritt betreten; Verjüngungs-Schritt → Default-Verjüngung übernehmen + committen.
  onConfirm: (state, ctx): [CommandState, CommandResult] => {
    const s = state as ExState;
    if (s.phase === "height") return enterTaperPhase(s.profile, lastHeight, s.sourceId);
    if (s.phase === "taper") return commitTaper(s.profile, s.height, lastTaper, s.sourceId, ctx);
    return finish();
  },
  onCancel: (): [CommandState, CommandResult] => finish(),
 };
@@ -0,0 +1,58 @@
 import { describe, it, expect } from "vitest";
 import { georefCommand } from "./georef";
 import type { CommandContext, Project, Vec2 } from "../types";
 const ctx = {} as CommandContext;
 const P = (x: number, y: number): Vec2 => ({ x, y });
 function projectWith(wallStart: Vec2): Project {
  return {
    id: "p",
    name: "T",
    layers: [],
    drawingLevels: [],
    walls: [
      {
        id: "W1",
        type: "wall",
        floorId: "eg",
        categoryCode: "20",
        start: wallStart,
        end: { x: wallStart.x + 5, y: wallStart.y },
        wallTypeId: "aw",
        height: 2.6,
      },
    ],
    drawings2d: [],
  } as unknown as Project;
 }
 describe("georefCommand", () => {
  it("Hover zeigt die resultierende Verschiebung im HUD (negativer Klickpunkt)", () => {
    const s0 = georefCommand.init();
    const [, r] = georefCommand.onMove(s0, P(120, 45), null, ctx);
    expect(r.draft?.hud).toEqual({ at: P(120, 45), dx: -120, dy: -45 });
  });
  it("Klick committet sofort: der geklickte Punkt wird zum neuen Ursprung", () => {
    const s0 = georefCommand.init();
    const [ns, r] = georefCommand.onInput(s0, { kind: "point", point: P(120, 45) }, ctx);
    expect(r.done).toBe(true);
    expect((ns as { phase: string }).phase).toBe("start");
    const p = projectWith({ x: 120, y: 45 });
    const out = r.commit!(p);
    // Die Wand begann exakt am geklickten Punkt -> liegt danach auf (0,0).
    expect(out.walls[0].start).toEqual({ x: 0, y: 0 });
    expect(out.walls[0].end).toEqual({ x: 5, y: 0 });
  });
  it("Esc/Rechtsklick auf leerem Zustand beendet ohne Commit", () => {
    const s0 = georefCommand.init();
    const [, r1] = georefCommand.onCancel(s0);
    expect(r1.done).toBe(true);
    expect(r1.commit).toBeUndefined();
    const [, r2] = georefCommand.onConfirm(s0, ctx);
    expect(r2.done).toBe(true);
    expect(r2.commit).toBeUndefined();
  });
 });
@@ -0,0 +1,64 @@
 // Neuer Bezugspunkt — verschiebt das GESAMTE Projekt (Wände, Decken, Dächer,
 // Treppen, Räume, Stützen, Extrusionen, freie 2D-Geometrie, Kontext-Schicht,
 // Schnittlinien) so, dass der geklickte Punkt zum neuen Modell-Ursprung (0,0)
 // wird. Praktisch nach einem Kataster-/3D-Import (Kontext-Geometrie landet
 // dort, wo der gesuchte Standort war — kann weit vom bisherigen Ursprung
 // liegen, s. `Project.geoAnchor`): man klickt den gewünschten Bezugspunkt
 // (z. B. eine Parzellenecke aus dem Import) und zeichnet danach mit kleinen,
 // bequemen Koordinaten weiter. `geoAnchor` wandert automatisch mit (reine
 // Translation, s. `model/geoRebase.ts`), der reale LV95-Bezug bleibt exakt
 // erhalten — beim Export ist die Verschiebung jederzeit rekonstruierbar.
 //
 // Ein-Klick-Befehl: der erste (einzige) Punkt committet sofort.
 import { translateProject } from "../../model/geoRebase";
 import type {
  Command,
  CommandResult,
  CommandState,
  Project,
  ToolDraft,
  Vec2,
 } from "../types";
 interface GeorefStart extends CommandState {
  phase: "start";
 }
 const IDLE: GeorefStart = { phase: "start", lastPoint: null };
 const idle = (): [CommandState, CommandResult] => [{ ...IDLE }, { draft: null, done: true }];
 /** HUD am Cursor: zeigt die resultierende Verschiebung, bevor geklickt wird. */
 function draft(point: Vec2): ToolDraft {
  return {
    preview: [],
    vertices: [],
    hud: { at: point, dx: -point.x, dy: -point.y },
  };
 }
 export const georefCommand: Command = {
  name: "georef",
  labelKey: "cmd.georef.label",
  prompt: () => "cmd.georef.prompt",
  accepts: () => ["point"],
  options: () => [],
  init: (): GeorefStart => ({ ...IDLE }),
  onInput: (state, input): [CommandState, CommandResult] => {
    if (input.kind !== "point") return [state, { draft: null }];
    const { x, y } = input.point;
    return [
      { ...IDLE },
      {
        draft: null,
        done: true,
        commit: (p: Project) => translateProject(p, -x, -y),
      },
    ];
  },
  onMove: (state, point): [CommandState, CommandResult] => [state, { draft: draft(point) }],
  onConfirm: (): [CommandState, CommandResult] => idle(),
  onCancel: (): [CommandState, CommandResult] => idle(),
 };
@@ -26,6 +26,16 @@ export const importCommand: Command = {
  options: () => [],
  init: () => ({ ...IDLE }),
  // Sofort-Befehl (wie Join/Split): `startCommand` ruft `autoRun` SYNCHRON im
  // selben Aufruf-Stack wie die Enter-/Klick-Geste auf. Genau das braucht der
  // Datei-Dialog — ein `<input type=file>.click()` öffnet den OS-Dialog nur
  // innerhalb einer echten Nutzer-Geste; ein State-Update/async-Hop dazwischen
  // (wie beim reinen onConfirm/onInput-Weg) lässt ihn verzögern oder ausbleiben.
  autoRun: (): CommandResult => {
    openDxfImport();
    return { draft: null, done: true };
  },
  // Der Befehl hat keine Schritte: Start/Enter/Input öffnet den Dialog + endet.
  onInput: () => open(),
  onMove: (state): [CommandState, CommandResult] => [state, { draft: null }],
@@ -0,0 +1,87 @@
 /**
 * Unit-Tests für das Cursor-HUD (Länge/Winkel) des `line`-Befehls: nach dem
 * Startpunkt muss `onMove` im Draft `hud.length`/`hud.angleDeg` mit den
 * korrekten Werten liefern (VW-Stil L/W-Kästchen, PlanView rendert es).
 */
 import { describe, it, expect } from "vitest";
 import { lineCommand } from "./line";
 import type { CommandContext, Project, Vec2 } from "../types";
 /** Minimalprojekt — nur die Felder, die der Befehl/Context anfassen. */
 function project(): Project {
  return {
    id: "t",
    name: "T",
    lineStyles: [],
    hatches: [],
    components: [],
    wallTypes: [],
    drawingLevels: [
      {
        id: "eg",
        name: "EG",
        kind: "floor",
        visible: true,
        locked: false,
        floorHeight: 2.6,
        cutHeight: 1.0,
        baseElevation: 0,
      },
    ],
    layers: [{ code: "20", name: "Zeichnung", color: "#0a0a0a", lw: 0.5, visible: true, locked: false }],
    walls: [],
    doors: [],
    openings: [],
    ceilings: [],
    stairs: [],
    rooms: [],
    drawings2d: [],
    context: [],
  };
 }
 function makeCtx(lastPoint: Vec2 | null): CommandContext {
  const p = project();
  return {
    project: p,
    level: p.drawingLevels[0],
    defaultCategoryCode: "20",
    activeLineStyleId: "solid",
    activeWallTypeId: "aw",
    lastPoint,
    selection: { wallIds: [], drawingId: null },
  };
 }
 describe("lineCommand — Cursor-HUD (Länge/Winkel)", () => {
  it("liefert hud.length/angleDeg im onMove nach dem Startpunkt", () => {
    const start: Vec2 = { x: 0, y: 0 };
    const [afterStart] = lineCommand.onInput(
      lineCommand.init(),
      { kind: "point", point: start },
      makeCtx(null),
    );
    const [, res] = lineCommand.onMove(afterStart, { x: 3, y: 4 }, null, makeCtx(start));
    expect(res.draft?.hud?.length).toBeCloseTo(5, 9);
    expect(res.draft?.hud?.angleDeg).toBeCloseTo((Math.atan2(4, 3) * 180) / Math.PI, 9);
  });
  it("liefert einen negativen Winkel (Bereich (−180,180]) für Segmente nach unten-links", () => {
    const start: Vec2 = { x: 0, y: 0 };
    const [afterStart] = lineCommand.onInput(
      lineCommand.init(),
      { kind: "point", point: start },
      makeCtx(null),
    );
    // Richtung (-1,-1) → -135° (wie im VW-Screenshot).
    const [, res] = lineCommand.onMove(afterStart, { x: -2, y: -2 }, null, makeCtx(start));
    expect(res.draft?.hud?.angleDeg).toBeCloseTo(-135, 9);
    expect(res.draft?.hud?.length).toBeCloseTo(Math.hypot(2, 2), 9);
  });
  it("zeigt KEIN HUD vor dem Startpunkt (phase=start)", () => {
    const [, res] = lineCommand.onMove(lineCommand.init(), { x: 1, y: 1 }, null, makeCtx(null));
    expect(res.draft).toBeNull();
  });
 });
@@ -10,7 +10,7 @@
 // Tool. Live-Vorschau + HUD (Länge/Winkel) wie die bestehenden Tools.
 import type { Drawing2D } from "../../model/types";
-import { uniqueId } from "../../tools/types";
+import { segmentHud, uniqueId } from "../../tools/types";
 import type {
  Command,
  CommandContext,
@@ -61,14 +61,7 @@ function lineDraft(a: Vec2, cursor: Vec2 | null): ToolDraft {
  const preview: DraftShape[] = [];
  if (cursor && segLen(a, cursor) >= EPS) preview.push({ kind: "line", a, b: cursor });
  const draft: ToolDraft = { preview, vertices: [a] };
-  if (cursor && segLen(a, cursor) >= EPS) {
+  if (cursor && segLen(a, cursor) >= EPS) draft.hud = segmentHud(a, cursor);
    draft.hud = {
      at: cursor,
      text: `${segLen(a, cursor).toFixed(2)} m · ${Math.abs(
        (segAngleDeg(a, cursor) + 360) % 360,
      ).toFixed(0)}°`,
    };
  }
  return draft;
 }
@@ -0,0 +1,46 @@
 import { describe, it, expect } from "vitest";
 import { measureCommand } from "./measure";
 import type { CommandContext, Vec2 } from "../types";
 // Der Kontext wird vom Mess-Werkzeug nicht gelesen (rein visuell) — Dummy genügt.
 const ctx = {} as CommandContext;
 const P = (x: number, y: number): Vec2 => ({ x, y });
 describe("measureCommand", () => {
  it("misst Segment + Winkel ab dem ersten Punkt", () => {
    const s0 = measureCommand.init();
    const [s1] = measureCommand.onInput(s0, { kind: "point", point: P(0, 0) }, ctx);
    const [, r] = measureCommand.onMove(s1, P(3, 0), null, ctx);
    expect(r.draft?.measure?.segment).toBeCloseTo(3, 6);
    expect(r.draft?.measure?.angle).toBeCloseTo(0, 6);
    expect(r.draft?.measure?.area).toBeNull();
    expect(r.draft?.measure?.points).toBe(1);
  });
  it("summiert die Pfadlänge und zeigt die Fläche ab 3 Ecken", () => {
    let s = measureCommand.init();
    [s] = measureCommand.onInput(s, { kind: "point", point: P(0, 0) }, ctx);
    [s] = measureCommand.onInput(s, { kind: "point", point: P(4, 0) }, ctx);
    [s] = measureCommand.onInput(s, { kind: "point", point: P(4, 3) }, ctx);
    // Cursor zurück Richtung Ursprung → geschlossenes Dreieck 4×3/2 = 6 m².
    const [, r] = measureCommand.onMove(s, P(0, 0), null, ctx);
    expect(r.draft?.measure?.total).toBeCloseTo(4 + 3 + 5, 6); // 0→4→3→Hypotenuse 5
    expect(r.draft?.measure?.area).toBeCloseTo(6, 6);
    expect(r.draft?.measure?.points).toBe(3);
  });
  it("Rechtsklick beendet den Pfad und armiert einen neuen (kein done)", () => {
    let s = measureCommand.init();
    [s] = measureCommand.onInput(s, { kind: "point", point: P(1, 1) }, ctx);
    const [ns, r] = measureCommand.onConfirm(s, ctx);
    expect(r.done).not.toBe(true);
    expect((ns as { phase: string }).phase).toBe("start");
    expect(r.draft).toBeNull();
  });
  it("Rechtsklick auf leerem Pfad beendet das Werkzeug", () => {
    const s = measureCommand.init();
    const [, r] = measureCommand.onConfirm(s, ctx);
    expect(r.done).toBe(true);
  });
 });
@@ -0,0 +1,133 @@
 // Messen — schnelles, unverbindliches Mess-Werkzeug (kein Element wird erzeugt).
 // Ein Mess-Pfad ist ein Polygonzug: jeder Klick setzt einen weiteren Stützpunkt.
 //   • 1 Punkt gesetzt → Live-Strecke (Länge · Winkel) zum Cursor.
 //   • ≥ 2 Punkte gesetzt → zusätzlich aufsummierte Pfadlänge; sobald der Zug
 //     (inkl. Cursor) ≥ 3 Ecken hat, zeigt er auch die umschlossene FLÄCHE.
 // Rechtsklick/Enter beendet den aktuellen Pfad und armiert einen NEUEN — so misst
 // man mehrere nacheinander. Ein weiterer Rechtsklick auf leerem Pfad (bzw. Esc)
 // beendet das Werkzeug. Rein visuell: `commit` bleibt immer leer.
 import type {
  Command,
  CommandResult,
  CommandState,
  ToolDraft,
  Vec2,
 } from "../types";
 import type { MeasurementReadout } from "../../tools/types";
 const segLen = (a: Vec2, b: Vec2): number => Math.hypot(b.x - a.x, b.y - a.y);
 const segAngleDeg = (a: Vec2, b: Vec2): number =>
  (Math.atan2(b.y - a.y, b.x - a.x) * 180) / Math.PI;
 /** Aufsummierte Länge eines Polygonzugs (offene Kette). */
 function pathLength(pts: Vec2[]): number {
  let sum = 0;
  for (let i = 1; i < pts.length; i++) sum += segLen(pts[i - 1], pts[i]);
  return sum;
 }
 /** Vorzeichenlose Fläche (Gauss/Schuhband), Zug als geschlossen gedacht. */
 function polygonArea(pts: Vec2[]): number {
  if (pts.length < 3) return 0;
  let a = 0;
  for (let i = 0; i < pts.length; i++) {
    const p = pts[i];
    const q = pts[(i + 1) % pts.length];
    a += p.x * q.y - q.x * p.y;
  }
  return Math.abs(a) / 2;
 }
 interface MeasureStart extends CommandState {
  phase: "start";
 }
 interface MeasureDraw extends CommandState {
  phase: "draw";
  /** Bereits gesetzte Stützpunkte (≥ 1). */
  points: Vec2[];
  cursor: Vec2 | null;
 }
 type MeasureState = MeasureStart | MeasureDraw;
 /** Messwerte aus gesetzten Punkten + aktuellem Cursor bilden. */
 function readout(points: Vec2[], cursor: Vec2 | null): MeasurementReadout {
  const chain = cursor ? [...points, cursor] : points;
  const last = points[points.length - 1];
  const segment = cursor && last ? segLen(last, cursor) : 0;
  const angle = cursor && last ? ((segAngleDeg(last, cursor) % 360) + 360) % 360 : 0;
  return {
    segment,
    total: pathLength(chain),
    area: chain.length >= 3 ? polygonArea(chain) : null,
    angle,
    points: points.length,
  };
 }
 /** Vorschau: gesetzter Zug + Live-Segment zum Cursor + HUD + Messwerte. */
 function measureDraft(points: Vec2[], cursor: Vec2 | null): ToolDraft {
  const chain = cursor ? [...points, cursor] : points;
  const r = readout(points, cursor);
  const hudText =
    r.area != null
      ? `${r.segment.toFixed(3)} m · Σ ${r.total.toFixed(3)} m · ${r.area.toFixed(2)} m²`
      : `${r.segment.toFixed(3)} m · ${r.angle.toFixed(1)}°`;
  return {
    preview: [{ kind: "poly", pts: chain, closed: chain.length >= 3 }],
    vertices: points,
    hud: cursor ? { at: cursor, text: hudText } : undefined,
    measure: r,
  };
 }
 const idle = (): [CommandState, CommandResult] => [
  { phase: "start", lastPoint: null } as MeasureStart,
  { draft: null, done: true },
 ];
 export const measureCommand: Command = {
  name: "measure",
  labelKey: "cmd.measure.label",
  prompt: (s) => ((s as MeasureState).phase === "draw" ? "cmd.measure.next" : "cmd.measure.start"),
  accepts: () => ["point"],
  options: () => [],
  init: (): MeasureStart => ({ phase: "start", lastPoint: null }),
  onInput: (state, input): [CommandState, CommandResult] => {
    const s = state as MeasureState;
    if (input.kind !== "point") {
      const draft =
        s.phase === "draw" ? measureDraft(s.points, s.cursor) : null;
      return [s, { draft }];
    }
    // Klick hängt einen Stützpunkt an den Pfad (bzw. beginnt einen neuen).
    const points = s.phase === "draw" ? [...s.points, input.point] : [input.point];
    const ns: MeasureDraw = {
      phase: "draw",
      points,
      cursor: input.point,
      lastPoint: input.point,
    };
    return [ns, { draft: measureDraft(points, input.point) }];
  },
  onMove: (state, point): [CommandState, CommandResult] => {
    const s = state as MeasureState;
    if (s.phase !== "draw") return [s, { draft: null }];
    const ns: MeasureDraw = { ...s, cursor: point };
    return [ns, { draft: measureDraft(s.points, point) }];
  },
  // Rechtsklick/Enter: laufenden Pfad beenden und einen NEUEN armieren (mehrere
  // Messungen nacheinander). Auf leerem Pfad = Werkzeug beenden.
  onConfirm: (state): [CommandState, CommandResult] => {
    const s = state as MeasureState;
    if (s.phase === "draw" && s.points.length > 0) {
      return [{ phase: "start", lastPoint: null } as MeasureStart, { draft: null }];
    }
    return idle();
  },
  // Esc: Werkzeug ganz beenden.
  onCancel: (): [CommandState, CommandResult] => idle(),
 };
@@ -32,12 +32,22 @@ const EPS = 1e-6;
 /** Hat die Auswahl überhaupt etwas Spiegelbares? */
 function hasSelection(sel: CommandSelection): boolean {
-  return sel.wallIds.length > 0 || sel.drawingId !== null;
+  return (
    sel.wallIds.length > 0 ||
    sel.drawingId !== null ||
    !!sel.extrudedSolidId ||
    !!sel.columnId
  );
 }
 /** Auswahl → TransformSelection (gleiche Form). */
 function toTransformSel(sel: CommandSelection): TransformSelection {
-  return { wallIds: sel.wallIds, drawingId: sel.drawingId };
+  return {
    wallIds: sel.wallIds,
    drawingId: sel.drawingId,
    extrudedSolidId: sel.extrudedSolidId,
    columnId: sel.columnId,
  };
 }
 // Zustand: erst ersten Achsenpunkt setzen, dann den zweiten (mit Auswahl-Snapshot).
@@ -49,12 +49,22 @@ function targetFromFields(base: Vec2, locks: Record<string, number>, cursor: Vec
 /** Hat die Auswahl überhaupt etwas Verschiebbares? */
 function hasSelection(sel: CommandSelection): boolean {
-  return sel.wallIds.length > 0 || sel.drawingId !== null;
+  return (
    sel.wallIds.length > 0 ||
    sel.drawingId !== null ||
    !!sel.extrudedSolidId ||
    !!sel.columnId
  );
 }
 /** Auswahl → TransformSelection (gleiche Form). */
 function toTransformSel(sel: CommandSelection): TransformSelection {
-  return { wallIds: sel.wallIds, drawingId: sel.drawingId };
+  return {
    wallIds: sel.wallIds,
    drawingId: sel.drawingId,
    extrudedSolidId: sel.extrudedSolidId,
    columnId: sel.columnId,
  };
 }
 // Zustand: erst Basispunkt setzen, dann Ziel (mit Auswahl-Snapshot vom Start).
@@ -187,6 +187,12 @@ function appendOpening(p: Project, s: OpPos, ctx: CommandContext): Project {
  const len = Math.hypot(s.end.x - s.start.x, s.end.y - s.start.y);
  const width = Math.max(0.1, Math.min(s.width, len));
  const position = Math.max(0, Math.min(s.posAlong, Math.max(0, len - width)));
  // Standard-Bauteiltyp zuweisen (erster Tür-/Fenstertyp der Bibliothek), damit
  // frisch platzierte Öffnungen SOFORT die volle Rahmen-/Laibungs-Darstellung
  // (2D + 3D) bekommen — ohne Typ blieben sie ein blosses Loch mit flacher
  // Scheibe. Fehlt eine Bibliothek, bleibt es beim Inline-Verhalten (kein Typ).
  const typeId =
    s.kind === "door" ? ctx.project.doorTypes?.[0]?.id : ctx.project.windowTypes?.[0]?.id;
  const opening: Opening = {
    id: uniqueId("O"),
    type: "opening",
@@ -197,6 +203,7 @@ function appendOpening(p: Project, s: OpPos, ctx: CommandContext): Project {
    width,
    height: s.height,
    sillHeight: s.kind === "door" ? 0 : s.sill,
    ...(typeId ? { typeId } : {}),
    ...(s.kind === "door"
      ? { hinge: s.hinge, swing: s.side, openingDir: s.dir, swingAngle: s.swingAngle }
      : {}),
@@ -6,7 +6,7 @@
 // Akzeptiert je Punkt Maus-Picks UND getippte Koordinaten (0,0 · r3,0 · 5<45).
 import type { Drawing2D } from "../../model/types";
-import { uniqueId } from "../../tools/types";
+import { segmentHud, uniqueId } from "../../tools/types";
 import type {
  Command,
  CommandContext,
@@ -74,14 +74,7 @@ function polyDraft(points: Vec2[], cursor: Vec2 | null, closed = false): ToolDra
  const preview: DraftShape[] = [{ kind: "poly", pts, closed: showClosed }];
  const draft: ToolDraft = { preview, vertices: points };
  const last = points[points.length - 1];
-  if (cursor && last && segLen(last, cursor) >= EPS) {
+  if (cursor && last && segLen(last, cursor) >= EPS) draft.hud = segmentHud(last, cursor);
    draft.hud = {
      at: cursor,
      text: `${segLen(last, cursor).toFixed(2)} m · ${Math.abs(
        (segAngleDeg(last, cursor) + 360) % 360,
      ).toFixed(0)}°`,
    };
  }
  return draft;
 }
@@ -17,7 +17,7 @@
 // werden (die Engine löst `r…` relativ zu lastPoint auf).
 import type { Drawing2D } from "../../model/types";
-import { uniqueId } from "../../tools/types";
+import { deltaHud, segmentHud, uniqueId } from "../../tools/types";
 import type {
  Command,
  CommandContext,
@@ -196,51 +196,47 @@ function rectGeom(a: Vec2, b: Vec2): { min: Vec2; max: Vec2 } {
 // ── Vorschau ─────────────────────────────────────────────────────────────────
-function corners4Draft(pts: Vec2[], hudAt: Vec2 | null, hudText: string): ToolDraft {
+function corners4Draft(pts: Vec2[], hud: ToolDraft["hud"] | null): ToolDraft {
  const preview: DraftShape[] = [{ kind: "poly", pts, closed: true }];
  const draft: ToolDraft = { preview, vertices: [pts[0]] };
-  if (hudAt) draft.hud = { at: hudAt, text: hudText };
+  if (hud) draft.hud = hud;
  return draft;
 }
-/** Vorschau des 2-Punkt-Rechtecks (achsparallel). */
+/** Vorschau des 2-Punkt-Rechtecks (achsparallel) — HUD zeigt die Diagonale a→cursor. */
 function cornerDraft(a: Vec2, cursor: Vec2 | null): ToolDraft {
  if (!cursor) return { preview: [], vertices: [a] };
  const g = rectGeom(a, cursor);
  const pts: Vec2[] = [g.min, { x: g.max.x, y: g.min.y }, g.max, { x: g.min.x, y: g.max.y }];
-  const w = g.max.x - g.min.x;
+  return corners4Draft(pts, segLen(a, cursor) >= EPS ? deltaHud(a, cursor) : null);
  const h = g.max.y - g.min.y;
  return corners4Draft(pts, cursor, `${w.toFixed(2)} × ${h.toFixed(2)} m`);
 }
-/** Vorschau des Zentrum-Rechtecks (achsparallel). */
+/** Vorschau des Zentrum-Rechtecks (achsparallel) — HUD zeigt die Diagonale center→cursor. */
 function centerDraft(center: Vec2, cursor: Vec2 | null): ToolDraft {
  if (!cursor) return { preview: [], vertices: [center] };
  const g = centerGeom(center, cursor);
  const pts: Vec2[] = [g.min, { x: g.max.x, y: g.min.y }, g.max, { x: g.min.x, y: g.max.y }];
-  const w = g.max.x - g.min.x;
+  return corners4Draft(
-  const h = g.max.y - g.min.y;
+    pts,
-  return corners4Draft(pts, cursor, `${w.toFixed(2)} × ${h.toFixed(2)} m`);
+    segLen(center, cursor) >= EPS
      ? { at: cursor, dx: 2 * (cursor.x - center.x), dy: 2 * (cursor.y - center.y) }
      : null,
  );
 }
 /** Vorschau der Basiskante (3-Punkt, erster Teil). */
 function baseDraft(a: Vec2, cursor: Vec2 | null): ToolDraft {
  if (!cursor || segLen(a, cursor) < EPS) return { preview: [{ kind: "line", a, b: a }], vertices: [a] };
-  const draft: ToolDraft = { preview: [{ kind: "line", a, b: cursor }], vertices: [a] };
+  return { preview: [{ kind: "line", a, b: cursor }], vertices: [a], hud: segmentHud(a, cursor) };
  draft.hud = {
    at: cursor,
    text: `${segLen(a, cursor).toFixed(2)} m · ${Math.abs((segAngleDeg(a, cursor) + 360) % 360).toFixed(0)}°`,
  };
  return draft;
 }
-/** Vorschau des gedrehten Rechtecks (3-Punkt, zweiter Teil). */
+/** Vorschau des gedrehten Rechtecks (3-Punkt, zweiter Teil) — HUD: Basisbreite + Höhe am Cursor. */
 function riseDraft(a: Vec2, b: Vec2, cursor: Vec2 | null): ToolDraft {
  if (!cursor) return { preview: [{ kind: "line", a, b }], vertices: [a] };
  const pts = rotatedCorners(a, b, cursor);
  const w = segLen(a, b);
  const h = Math.abs(riseFrom(a, b, cursor));
-  return corners4Draft(pts, cursor, `${w.toFixed(2)} × ${h.toFixed(2)} m`);
+  return corners4Draft(pts, { at: cursor, text: `B: ${w.toFixed(3)}m    H: ${h.toFixed(3)}m` });
 }
 // ── Commit ───────────────────────────────────────────────────────────────────
@@ -0,0 +1,173 @@
 // Roof — Dach als Engine-Befehl: der Grundriss wird als RECHTECK aufgezogen
 // (zwei Klicks: erste Ecke → Gegenecke), committet ein `Roof`-Bauteil. Die
 // Dachform/Neigung wählt man nach dem Platzieren im Attribut-Panel; Default ist
 // ein Satteldach mit First entlang der LÄNGEREN Rechteckseite.
 //
 // Schritte:
 //   1) „Erste Dachecke:"  → Punkt
 //   2) „Gegenecke:"       → Live-Rechteck-Vorschau; Klick committet das Dach.
 //
 // Herkunft der Dach-Felder (CommandContext):
 //   • floorId     ← ctx.level.id (aktives Geschoss)
 //   • categoryCode← "35" (Ebene „Dächer"; Fallback ctx.defaultCategoryCode)
 import type { Roof, RoofShape } from "../../model/types";
 import { uniqueId } from "../../tools/types";
 import type {
  Command,
  CommandContext,
  CommandResult,
  CommandState,
  CmdOption,
  DraftShape,
  Project,
  ToolDraft,
  Vec2,
 } from "../types";
 /** Default-Ebene (Kategorie) für Dächer („31 Dächer"). */
 const ROOF_CATEGORY = "31";
 /** Wählbare Dachformen (Inline-Optionen der Befehlszeile). */
 const SHAPE_OPTIONS: CmdOption[] = [
  { id: "sattel", labelKey: "cmd.roof.shape.sattel" },
  { id: "walm", labelKey: "cmd.roof.shape.walm" },
  { id: "pult", labelKey: "cmd.roof.shape.pult" },
  { id: "mansarde", labelKey: "cmd.roof.shape.mansarde" },
  { id: "zelt", labelKey: "cmd.roof.shape.zelt" },
  { id: "flach", labelKey: "cmd.roof.shape.flach" },
 ];
 const SHAPE_IDS = new Set(SHAPE_OPTIONS.map((o) => o.id));
 /** Existiert die Dach-Kategorie („35")? Sonst Fallback auf die aktive Kategorie. */
 function roofCategory(ctx: CommandContext): string {
  const flat: string[] = [];
  const walk = (list: { code: string; children?: unknown[] }[]) => {
    for (const c of list) {
      flat.push(c.code);
      if (c.children) walk(c.children as { code: string; children?: unknown[] }[]);
    }
  };
  walk(ctx.project.layers as { code: string; children?: unknown[] }[]);
  return flat.includes(ROOF_CATEGORY) ? ROOF_CATEGORY : ctx.defaultCategoryCode;
 }
 /** Vier Eckpunkte eines Rechtecks aus zwei Gegenecken (CCW). */
 function rectCorners(a: Vec2, b: Vec2): Vec2[] {
  const x0 = Math.min(a.x, b.x);
  const x1 = Math.max(a.x, b.x);
  const y0 = Math.min(a.y, b.y);
  const y1 = Math.max(a.y, b.y);
  return [
    { x: x0, y: y0 },
    { x: x1, y: y0 },
    { x: x1, y: y1 },
    { x: x0, y: y1 },
  ];
 }
 interface RoofIdle extends CommandState {
  phase: "start";
  shape: RoofShape;
 }
 interface RoofRect extends CommandState {
  phase: "corner";
  a: Vec2;
  cursor: Vec2 | null;
  shape: RoofShape;
 }
 type RoofState = RoofIdle | RoofRect;
 /** Vorschau: aufgezogenes Rechteck + Masse im HUD. */
 function roofDraft(a: Vec2, cursor: Vec2 | null): ToolDraft {
  const pts = cursor ? rectCorners(a, cursor) : [a];
  const preview: DraftShape[] = [{ kind: "poly", pts, closed: !!cursor }];
  const draft: ToolDraft = { preview, vertices: [a] };
  if (cursor) {
    draft.hud = {
      at: cursor,
      text: `${Math.abs(cursor.x - a.x).toFixed(2)} × ${Math.abs(cursor.y - a.y).toFixed(2)} m`,
    };
  }
  return draft;
 }
 /** Hängt ein Dach ans Projekt (immutabel). Entartete Rechtecke werden verworfen. */
 function appendRoof(p: Project, a: Vec2, b: Vec2, shape: RoofShape, ctx: CommandContext): Project {
  const w = Math.abs(b.x - a.x);
  const d = Math.abs(b.y - a.y);
  if (w < 0.1 || d < 0.1) return p;
  const roof: Roof = {
    id: uniqueId("RF"),
    type: "roof",
    floorId: ctx.level.id,
    categoryCode: roofCategory(ctx),
    outline: rectCorners(a, b),
    shape,
    // Flach/Pult brauchen keine „Firsthöhe"; Sattel/Walm/Mansarde/Zelt ~30°.
    pitchDeg: shape === "flach" ? 0 : 30,
    overhang: 0.4,
    // First entlang der längeren Seite (Standard).
    ridgeAxis: w >= d ? "x" : "y",
    thickness: 0.2,
  };
  const roofs = p.roofs ? [...p.roofs, roof] : [roof];
  return { ...p, roofs };
 }
 const idle = (shape: RoofShape = "sattel"): [CommandState, CommandResult] => [
  { phase: "start", shape, lastPoint: null } as RoofIdle,
  { draft: null, done: true },
 ];
 export const roofCommand: Command = {
  name: "roof",
  labelKey: "cmd.roof.label",
  floorOnly: true,
  prompt: (s) => ((s as RoofState).phase === "corner" ? "cmd.roof.corner" : "cmd.roof.start"),
  accepts: () => ["point", "option"],
  // Dachform als Inline-Optionen — vor/während des Aufziehens wählbar.
  options: () => SHAPE_OPTIONS,
  init: (): RoofIdle => ({ phase: "start", shape: "sattel", lastPoint: null }),
  onInput: (state, input, ctx): [CommandState, CommandResult] => {
    const s = state as RoofState;
    // Dachform-Option: aktualisiert die Form, Phase/Rechteck bleiben.
    if (input.kind === "option" && SHAPE_IDS.has(input.id)) {
      const ns = { ...s, shape: input.id as RoofShape } as RoofState;
      const draft = ns.phase === "corner" ? roofDraft(ns.a, ns.cursor) : null;
      return [ns, { draft }];
    }
    if (input.kind !== "point") {
      return [s, { draft: s.phase === "corner" ? roofDraft(s.a, s.cursor) : null }];
    }
    if (s.phase !== "corner") {
      const ns: RoofRect = {
        phase: "corner",
        a: input.point,
        cursor: input.point,
        shape: s.shape,
        lastPoint: input.point,
      };
      return [ns, { draft: roofDraft(input.point, input.point) }];
    }
    // Zweite Ecke → committen.
    const a = s.a;
    const b = input.point;
    const shape = s.shape;
    return [
      { phase: "start", shape, lastPoint: null } as RoofIdle,
      { draft: null, done: true, commit: (p) => appendRoof(p, a, b, shape, ctx) },
    ];
  },
  onMove: (state, point): [CommandState, CommandResult] => {
    const s = state as RoofState;
    if (s.phase !== "corner") return [s, { draft: null }];
    const ns: RoofRect = { ...s, cursor: point };
    return [ns, { draft: roofDraft(s.a, point) }];
  },
  onConfirm: (): [CommandState, CommandResult] => idle(),
  onCancel: (): [CommandState, CommandResult] => idle(),
 };
@@ -0,0 +1,100 @@
 // Schnittlinien-Befehl: der reine Datenpfad (commitLine/nextLevelName) — setzt
 // die Grundriss-Schnittlinie auf die richtige Ziel-Ebene bzw. legt eine neue an.
 import { describe, it, expect } from "vitest";
 import { _test } from "./sectionline";
 import type { DrawingLevel, Project } from "../../model/types";
 const { commitLine, nextLevelName } = _test;
 function projectWith(levels: DrawingLevel[]): Project {
  return {
    id: "p",
    name: "T",
    layers: [],
    drawingLevels: levels,
    walls: [],
    drawings2d: [],
  } as unknown as Project;
 }
 const a = { x: 0, y: 0 };
 const b = { x: 5, y: 0 };
 describe("sectionline — commitLine", () => {
  it("belegt die EINE Platzhalter-Schnittebene ohne Linie", () => {
    const p = projectWith([
      { id: "eg", name: "EG", kind: "floor", visible: true, locked: false },
      { id: "s1", name: "Schnitt A", kind: "section", visible: true, locked: false },
    ]);
    const out = commitLine(p, a, b, "section");
    const s = out.drawingLevels.find((z) => z.id === "s1")!;
    expect(s.linePoints).toEqual([a, b]);
    expect(s.directionSign).toBe(1);
    // Keine neue Ebene angelegt.
    expect(out.drawingLevels).toHaveLength(2);
  });
  it("legt eine NEUE Schnittebene an, wenn keine Platzhalter-Ebene existiert", () => {
    const p = projectWith([
      { id: "eg", name: "EG", kind: "floor", visible: true, locked: false },
      {
        id: "s1",
        name: "Schnitt A",
        kind: "section",
        visible: true,
        locked: false,
        linePoints: [{ x: 1, y: 1 }, { x: 2, y: 2 }],
      },
    ]);
    const out = commitLine(p, a, b, "section");
    expect(out.drawingLevels).toHaveLength(3);
    const created = out.drawingLevels[out.drawingLevels.length - 1];
    expect(created.kind).toBe("section");
    expect(created.linePoints).toEqual([a, b]);
    // Zweite Ebene → Buchstabe B.
    expect(created.name).toContain("B");
  });
  it("legt bei ZWEI Platzhaltern (mehrdeutig) eine neue Ebene an", () => {
    const p = projectWith([
      { id: "s1", name: "Schnitt A", kind: "section", visible: true, locked: false },
      { id: "s2", name: "Schnitt B", kind: "section", visible: true, locked: false },
    ]);
    const out = commitLine(p, a, b, "section");
    expect(out.drawingLevels).toHaveLength(3);
    // Die bestehenden Platzhalter bleiben unangetastet.
    expect(out.drawingLevels[0].linePoints).toBeUndefined();
    expect(out.drawingLevels[1].linePoints).toBeUndefined();
  });
  it("verwirft entartete (zu kurze) Linien", () => {
    const p = projectWith([
      { id: "s1", name: "Schnitt A", kind: "section", visible: true, locked: false },
    ]);
    const out = commitLine(p, a, { x: 0.02, y: 0 }, "section");
    expect(out).toBe(p);
  });
  it("trennt Schnitt- und Ansichts-Ebenen (kind)", () => {
    const p = projectWith([
      { id: "s1", name: "Schnitt A", kind: "section", visible: true, locked: false },
    ]);
    // Ansichtslinie darf die Schnitt-Platzhalter-Ebene NICHT belegen.
    const out = commitLine(p, a, b, "elevation");
    expect(out.drawingLevels).toHaveLength(2);
    expect(out.drawingLevels[0].linePoints).toBeUndefined();
    expect(out.drawingLevels[1].kind).toBe("elevation");
  });
 });
 describe("sectionline — nextLevelName", () => {
  it("zählt Buchstaben je Art hoch (A, B, C …)", () => {
    const p0 = projectWith([]);
    expect(nextLevelName(p0, "section")).toContain("A");
    const p1 = projectWith([
      { id: "s1", name: "Schnitt A", kind: "section", visible: true, locked: false },
    ]);
    expect(nextLevelName(p1, "section")).toContain("B");
  });
 });
@@ -0,0 +1,213 @@
 // Schnittlinie — setzt die Grundriss-Schnitt-/Ansichtslinie einer Zeichnungsebene
 // (DrawingLevel, kind "section"/"elevation") per zwei Klicks (Start → Ende). Die
 // Linie steuert `sectionPlaneFromLevel` (plan/toSection.ts): senkrecht auf ihr
 // steht die Blickrichtung (directionSign, Voreinstellung +1).
 //
 // Schritte:
 //   1) „Schnitt-Startpunkt:" → Punkt
 //   2) „Schnitt-Endpunkt:"   → Live-Linie + Richtungspfeil; Klick committet.
 //
 // Ziel-Ebene (im Commit bestimmt): existiert GENAU EINE Ebene der gewählten Art
 // OHNE gesetzte Linie (frisch angelegter Platzhalter), wird deren Linie gesetzt;
 // sonst wird eine NEUE Ebene angelegt (Name „Schnitt B/C…" bzw. „Ansicht …").
 //
 // Die Art (Schnitt/Ansicht) ist als Inline-Option umschaltbar — dieselbe Mechanik
 // für beide, nur `kind` unterscheidet sich (Alias `viewline` startet mit
 // „elevation"). Bezeichner englisch, sichtbarer Text via t().
 import { t } from "../../i18n";
 import type { DrawingLevel, DrawingLevelKind } from "../../model/types";
 import { leftNormal, normalize, sub } from "../../model/geometry";
 import type {
  Command,
  CommandResult,
  CommandState,
  CmdOption,
  DraftShape,
  Project,
  ToolDraft,
  Vec2,
 } from "../types";
 /** Nur Schnitt/Ansicht tragen eine Linie. */
 type LineKind = "section" | "elevation";
 /** Wählbare Art (Inline-Optionen der Befehlszeile). */
 const KIND_OPTIONS: CmdOption[] = [
  { id: "section", labelKey: "cmd.sectionline.kind.section" },
  { id: "elevation", labelKey: "cmd.sectionline.kind.elevation" },
 ];
 const KIND_IDS = new Set(KIND_OPTIONS.map((o) => o.id));
 /**
 * Richtungspfeil-Vorschau: kurze Linie vom Mittelpunkt der Schnittlinie entlang
 * der Blicknormalen (leftNormal der Linie, per directionSign gedreht) plus zwei
 * Flügel-Segmente — zeigt, wohin der Schnitt „blickt".
 */
 function directionArrow(a: Vec2, b: Vec2, sign: 1 | -1): DraftShape[] {
  const dir = sub(b, a);
  const len = Math.hypot(dir.x, dir.y);
  if (len < 1e-6) return [];
  const u = normalize(dir);
  const n = leftNormal(u); // (-uy, ux)
  const nx = n.x * sign;
  const ny = n.y * sign;
  const mid = { x: (a.x + b.x) / 2, y: (a.y + b.y) / 2 };
  // Pfeillänge ~ min(1 m, Viertel der Linienlänge), damit die Vorschau lesbar bleibt.
  const arrowLen = Math.min(1, len / 4);
  const tip = { x: mid.x + nx * arrowLen, y: mid.y + ny * arrowLen };
  const wing = arrowLen * 0.35;
  // Flügel: vom Spitzenpunkt zurück, je halb entlang −u und +u geneigt.
  const back = { x: tip.x - nx * wing * 2, y: tip.y - ny * wing * 2 };
  const w1 = { x: back.x + u.x * wing, y: back.y + u.y * wing };
  const w2 = { x: back.x - u.x * wing, y: back.y - u.y * wing };
  return [
    { kind: "line", a: mid, b: tip },
    { kind: "line", a: tip, b: w1 },
    { kind: "line", a: tip, b: w2 },
  ];
 }
 /** Vorschau: Schnittlinie + Richtungspfeil + Länge im HUD. */
 function lineDraft(a: Vec2, cursor: Vec2 | null, sign: 1 | -1): ToolDraft {
  if (!cursor) return { preview: [{ kind: "poly", pts: [a] }], vertices: [a] };
  const preview: DraftShape[] = [
    { kind: "line", a, b: cursor },
    ...directionArrow(a, cursor, sign),
  ];
  const draft: ToolDraft = { preview, vertices: [a] };
  draft.hud = {
    at: cursor,
    text: `${Math.hypot(cursor.x - a.x, cursor.y - a.y).toFixed(2)} m`,
  };
  return draft;
 }
 /** Nächster freier Ebenen-Name der Art (A, B, C … über die Anzahl bestehender). */
 function nextLevelName(p: Project, kind: LineKind): string {
  const count = p.drawingLevels.filter((z) => z.kind === kind).length;
  // Buchstaben-Suffix (A, B, …, Z, dann AA…) — klassische Schnitt-Benennung.
  let n = count;
  let letters = "";
  do {
    letters = String.fromCharCode(65 + (n % 26)) + letters;
    n = Math.floor(n / 26) - 1;
  } while (n >= 0);
  const key = kind === "section" ? "cmd.sectionline.newSection" : "cmd.sectionline.newElevation";
  return t(key, { letter: letters });
 }
 /**
 * Setzt die Schnittlinie [a, b] auf die Ziel-Ebene (immutabel). Existiert GENAU
 * EINE Ebene der Art ohne Linie, wird sie belegt; sonst wird eine neue angelegt.
 * Entartete (zu kurze) Linien werden verworfen.
 */
 function commitLine(p: Project, a: Vec2, b: Vec2, kind: LineKind): Project {
  if (Math.hypot(b.x - a.x, b.y - a.y) < 0.1) return p;
  const line: [Vec2, Vec2] = [a, b];
  const orphans = p.drawingLevels.filter((z) => z.kind === kind && !z.linePoints);
  if (orphans.length === 1) {
    const targetId = orphans[0].id;
    return {
      ...p,
      drawingLevels: p.drawingLevels.map((z) =>
        z.id === targetId ? { ...z, linePoints: line, directionSign: z.directionSign ?? 1 } : z,
      ),
    };
  }
  const level: DrawingLevel = {
    id: `${kind}-${Date.now()}`,
    name: nextLevelName(p, kind),
    kind: kind as DrawingLevelKind,
    visible: true,
    locked: false,
    linePoints: line,
    directionSign: 1,
  };
  return { ...p, drawingLevels: [...p.drawingLevels, level] };
 }
 interface LineIdle extends CommandState {
  phase: "start";
  kind: LineKind;
 }
 interface LineEnd extends CommandState {
  phase: "end";
  a: Vec2;
  cursor: Vec2 | null;
  kind: LineKind;
 }
 type LineState = LineIdle | LineEnd;
 const DIRECTION_SIGN: 1 = 1;
 function makeCommand(name: string, startKind: LineKind): Command {
  const idle = (kind: LineKind): [CommandState, CommandResult] => [
    { phase: "start", kind, lastPoint: null } as LineIdle,
    { draft: null, done: true },
  ];
  return {
    name,
    labelKey: "cmd.sectionline.label",
    // Nicht floorOnly: eine Schnittlinie zieht man IM Grundriss, wo Bauteile
    // liegen — die aktive Ebene ist dann ein Geschoss. Aber der Befehl soll auch
    // auf freien Zeichnungsebenen nutzbar bleiben; die Prüfung übernimmt der
    // Grundriss-Kontext (keine harte Sperre nötig).
    floorOnly: true,
    prompt: (s) => ((s as LineState).phase === "end" ? "cmd.sectionline.end" : "cmd.sectionline.start"),
    accepts: () => ["point", "option"],
    options: () => KIND_OPTIONS,
    init: (): LineIdle => ({ phase: "start", kind: startKind, lastPoint: null }),
    onInput: (state, input): [CommandState, CommandResult] => {
      const s = state as LineState;
      if (input.kind === "option" && KIND_IDS.has(input.id)) {
        const ns = { ...s, kind: input.id as LineKind } as LineState;
        const draft =
          ns.phase === "end" ? lineDraft(ns.a, ns.cursor, DIRECTION_SIGN) : null;
        return [ns, { draft }];
      }
      if (input.kind !== "point") {
        return [
          s,
          { draft: s.phase === "end" ? lineDraft(s.a, s.cursor, DIRECTION_SIGN) : null },
        ];
      }
      if (s.phase !== "end") {
        const ns: LineEnd = {
          phase: "end",
          a: input.point,
          cursor: input.point,
          kind: s.kind,
          lastPoint: input.point,
        };
        return [ns, { draft: lineDraft(input.point, input.point, DIRECTION_SIGN) }];
      }
      const a = s.a;
      const b = input.point;
      const kind = s.kind;
      return [
        { phase: "start", kind, lastPoint: null } as LineIdle,
        { draft: null, done: true, commit: (p) => commitLine(p, a, b, kind) },
      ];
    },
    onMove: (state, point): [CommandState, CommandResult] => {
      const s = state as LineState;
      if (s.phase !== "end") return [s, { draft: null }];
      const ns: LineEnd = { ...s, cursor: point };
      return [ns, { draft: lineDraft(s.a, point, DIRECTION_SIGN) }];
    },
    onConfirm: (state): [CommandState, CommandResult] => idle((state as LineState).kind),
    onCancel: (state): [CommandState, CommandResult] => idle((state as LineState).kind),
  };
 }
 /** Schnittlinie (startet als „section"). */
 export const sectionLineCommand: Command = makeCommand("sectionline", "section");
 /** Ansichtslinie (startet als „elevation"; identische Mechanik). */
 export const viewLineCommand: Command = makeCommand("viewline", "elevation");
 // Für Tests: die reinen Datenpfad-Helfer.
 export const _test = { commitLine, nextLevelName, directionArrow };
@@ -0,0 +1,85 @@
 /**
 * Unit-Tests für `stepsFromTread` — Stufenzahl-Ableitung aus Soll-Auftritt + Lauflänge.
 *
 * Entspricht dem `target_a`-Modus im Rhino-Plugin (_make_treppe_preview_handler,
 * Variable `target_a` = Soll-Auftritt).
 */
 import { describe, it, expect } from "vitest";
 import { stepsFromTread } from "./stair";
 import { MIN_STEPS, IDEAL_TREAD } from "../../geometry/stair";
 describe("stepsFromTread — Grundfälle", () => {
  it("ergibt das ideale Soll-Trittmass bei exakter Teilbarkeit", () => {
    // 10 × 0.29 m = 2.9 m → 10 Stufen
    const steps = stepsFromTread(IDEAL_TREAD, 10 * IDEAL_TREAD);
    expect(steps).toBe(10);
  });
  it("rundet auf die nächste ganze Stufenzahl", () => {
    // 3.0 / 0.29 ≈ 10.34 → 10
    expect(stepsFromTread(0.29, 3.0)).toBe(10);
    // 3.1 / 0.29 ≈ 10.69 → 11
    expect(stepsFromTread(0.29, 3.1)).toBe(11);
  });
  it("bleibt mindestens bei MIN_STEPS", () => {
    // Sehr kurze Lauflänge → immer MIN_STEPS (2)
    expect(stepsFromTread(0.29, 0.01)).toBe(MIN_STEPS);
  });
  it("klemmt nach oben: Stufenzahl durch 0.24-m-Auftritts-Grenze begrenzt", () => {
    // 10 m Lauflänge, Auftritt 0.01 m → raw = 1000, aber durch Clamp auf
    // floor(10/0.24)+1 = 42 begrenzt. Der resultierende Auftritt (≈ 0.238 m)
    // ist der Grenzwert der floor-Formel aus defaultStepCount — kein echter Bug,
    // sondern die bewusste Clamp-Schwelle (≥ min ~ 0.24 m, off-by-one durch +1).
    const steps = stepsFromTread(0.01, 10.0);
    // Die Stufenzahl muss deutlich kleiner als 1000 sein (Clamp wirkt).
    expect(steps).toBeLessThan(100);
    expect(steps).toBeGreaterThanOrEqual(MIN_STEPS);
    // Auftrittstiefe muss im vernünftigen Bereich liegen (nahe 0.24 m).
    const treadDepth = 10.0 / steps;
    expect(treadDepth).toBeGreaterThanOrEqual(0.23 - 1e-6);
    expect(treadDepth).toBeLessThanOrEqual(0.30);
  });
  it("typische Nutzung: Lauflänge 3 m, Auftritt 0.29 m → ca. 10 Stufen", () => {
    const steps = stepsFromTread(0.29, 3.0);
    expect(steps).toBeGreaterThanOrEqual(MIN_STEPS);
    // Auftrittstiefe nahe am Soll
    const tread = 3.0 / steps;
    expect(tread).toBeGreaterThan(0.20);
    expect(tread).toBeLessThan(0.40);
  });
  it("nullartige Auftritt-Eingabe wird intern auf 0.05 m geklippt", () => {
    // Sollte nicht abstürzen, Ergebnis durch 0.24-m-Clamp begrenzt.
    const steps = stepsFromTread(0, 3.0);
    expect(steps).toBeGreaterThanOrEqual(MIN_STEPS);
  });
  it("negative Lauflänge → MIN_STEPS", () => {
    expect(stepsFromTread(0.29, -1)).toBe(MIN_STEPS);
  });
  it("Auftritt 0.25 m, Lauflänge 2.5 m → 10 Stufen (exakt)", () => {
    expect(stepsFromTread(0.25, 2.5)).toBe(10);
  });
 });
 describe("stepsFromTread — Grenzwerte / Konsistenz", () => {
  it("liefert immer ganze Zahlen", () => {
    for (const run of [1.0, 2.5, 3.14, 5.0, 10.0]) {
      const steps = stepsFromTread(0.29, run);
      expect(Number.isInteger(steps)).toBe(true);
    }
  });
  it("resultierender Auftritt liegt stets im erlaubten Bereich (>= 0.24 m)", () => {
    for (const run of [1.0, 2.0, 3.0, 5.0]) {
      const steps = stepsFromTread(IDEAL_TREAD, run);
      const tread = run / steps;
      expect(tread).toBeGreaterThanOrEqual(0.24 - 1e-6);
    }
  });
 });
@@ -4,9 +4,12 @@
 //      Laufs. Bei L folgt ein zweiter Lauf (Ende des zweiten Laufs); bei Wendel
 //      ist der zweite Punkt der äußere Rand (Radius). Committet die Treppe.
 //
-// Optionen (togglebar): Grundform gerade/L/Wendel (Auf-/Ab-Umschalter). Tab-Felder
+// Optionen (togglebar, IMMER sichtbar): Grundform gerade/L/Wendel, Auf-/Ab-
-// im Laufschritt: Breite / Stufenanzahl / Steighöhe (totalRise). Live-Vorschau
+// Umschalter, Referenz (links/mitte/rechts), Trittmass-Modus (mit/ohne).
-// zeigt die Tritt-Linien + die Lauflinie.
+// Tab-Felder in BEIDEN Phasen: Breite (idle + run). Im Laufschritt zusätzlich:
 //   • Trittmass-Modus „ohne": Stufen + Steighöhe (heutiges Verhalten).
 //   • Trittmass-Modus „mit" : Auftritt (Soll-Trittmass); Stufenzahl wird daraus
 //     abgeleitet: steps = clamp(round(runLength / auftritt), MIN_STEPS, …).
 //
 // Herkunft der Treppen-Felder (CommandContext):
 //   • floorId     ← ctx.level.id (aktives Geschoss)
@@ -17,7 +20,7 @@
 // Bezeichner englisch, sichtbarer Text via t() (CONVENTIONS.md).
 import type { Stair, StairShape, Vec2 as MVec2 } from "../../model/types";
-import { stairGeometry, defaultStepCount } from "../../geometry/stair";
+import { stairGeometry, defaultStepCount, IDEAL_TREAD, MIN_STEPS } from "../../geometry/stair";
 import { uniqueId } from "../../tools/types";
 import type {
  Command,
@@ -38,6 +41,35 @@ const STAIR_CATEGORY = "40";
 const DEF_WIDTH = 1.0;
 const EPS = 1e-6;
 // ── Trittmass-Modus ──────────────────────────────────────────────────────────
 /** Trittmass-Modus: „with" = Soll-Auftritt vorgegeben, Stufen abgeleitet;
 *  „without" = heutiges Verhalten (freies Stufen-Feld). */
 type TreadMode = "with" | "without";
 // ── Persistente Defaults (modulweit, leben über Befehls-Instanzen hinweg) ────
 /** Letzte Nutzer-Einstellungen für Treppen; wird von jeder neuen Instanz gelesen
 *  und nach jedem Commit aktualisiert. */
 const stairDefaults: {
  shape: StairShape;
  up: boolean;
  width: number;
  referenz: "links" | "mitte" | "rechts";
  treadMode: TreadMode;
  auftritt: number; // Soll-Trittmass (Meter)
  steps: number | null;
  rise: number | null;
 } = {
  shape: "straight",
  up: true,
  width: DEF_WIDTH,
  referenz: "mitte",
  treadMode: "without",
  auftritt: IDEAL_TREAD,
  steps: null,
  rise: null,
 };
 // ── Vektor-Helfer ─────────────────────────────────────────────────────────────
 const sub = (a: Vec2, b: Vec2): Vec2 => ({ x: a.x - b.x, y: a.y - b.y });
 const lenOf = (a: Vec2): number => Math.hypot(a.x, a.y);
 const normv = (a: Vec2): Vec2 => {
@@ -65,21 +97,45 @@ function floorRise(ctx: CommandContext): number {
  return ctx.level.floorHeight && ctx.level.floorHeight > 0 ? ctx.level.floorHeight : 2.6;
 }
-/** Tab-Felder im Laufschritt: Breite / Stufenanzahl / Steighöhe. */
+// ── Trittmass-Ableitung ───────────────────────────────────────────────────────
-const RUN_FIELDS: CommandField[] = [
+/**
-  { id: "width", labelKey: "cmd.field.width" },
+ * Leitet die Stufenzahl aus Auftritt (Soll-Trittmass) + Lauflänge ab.
-  { id: "steps", labelKey: "cmd.stair.stepsField" },
+ * Klemmt auf [MIN_STEPS, maxByRun] (mind. 0.24 m Auftrittstiefe).
-  { id: "rise", labelKey: "cmd.stair.riseField" },
+ * Entspricht dem `target_a`-Modus im Rhino-Plugin (_make_treppe_preview_handler).
-];
+ */
 export function stepsFromTread(auftritt: number, runLength: number): number {
  const a = Math.max(0.05, auftritt);
  const raw = Math.round(runLength / a);
  // Auftrittstiefe aus Stufenzahl darf nicht unter 0.24 m sinken.
  const maxByRun = runLength > 0 ? Math.max(MIN_STEPS, Math.floor(runLength / 0.24) + 1) : raw;
  return Math.max(MIN_STEPS, Math.min(raw, maxByRun));
 }
 // ── Felder (Tab-Zyklus) ───────────────────────────────────────────────────────
 /** Tab-Feld: Breite (immer, ab idle). */
 const FIELD_WIDTH: CommandField = { id: "width", labelKey: "cmd.field.width" };
 /** Tab-Feld: Stufenanzahl (run-Phase, nur Trittmass-Modus „ohne"). */
 const FIELD_STEPS: CommandField = { id: "steps", labelKey: "cmd.stair.stepsField" };
 /** Tab-Feld: Steighöhe (run-Phase, nur Trittmass-Modus „ohne"). */
 const FIELD_RISE: CommandField = { id: "rise", labelKey: "cmd.stair.riseField" };
 /** Tab-Feld: Auftritt (run-Phase, nur Trittmass-Modus „mit"). */
 const FIELD_AUFTRITT: CommandField = { id: "auftritt", labelKey: "cmd.stair.auftrittField" };
 // ── Optionen (immer sichtbar) ─────────────────────────────────────────────────
 const SHAPE: CmdOption = { id: "shape", labelKey: "cmd.stair.shape", value: "straight" };
 const UPDOWN: CmdOption = { id: "updown", labelKey: "cmd.stair.updown", value: "up" };
 const REFERENZ: CmdOption = { id: "referenz", labelKey: "cmd.stair.referenz", value: "mitte" };
 const TREAD_MODE: CmdOption = { id: "treadMode", labelKey: "cmd.stair.treadMode", value: "without" };
 // ── Zustands-Typen ────────────────────────────────────────────────────────────
 interface StairIdle extends CommandState {
  phase: "start";
  shape: StairShape;
  up: boolean;
  width: number;
  referenz: "links" | "mitte" | "rechts";
  treadMode: TreadMode;
  auftritt: number;
  steps: number | null; // null = automatisch
  rise: number | null; // null = Geschosshöhe
 }
@@ -88,6 +144,9 @@ interface StairRun extends CommandState {
  shape: StairShape;
  up: boolean;
  width: number;
  referenz: "links" | "mitte" | "rechts";
  treadMode: TreadMode;
  auftritt: number;
  steps: number | null;
  rise: number | null;
  start: Vec2;
@@ -95,14 +154,30 @@ interface StairRun extends CommandState {
 }
 type StairCmdState = StairIdle | StairRun;
-function initState(shape: StairShape = "straight"): StairIdle {
+/** Neuer Ruhezustand aus den modulweiten Defaults (oder überschrieben). */
-  return { phase: "start", lastPoint: null, shape, up: true, width: DEF_WIDTH, steps: null, rise: null };
+function initState(override?: Partial<typeof stairDefaults>): StairIdle {
  const d = { ...stairDefaults, ...override };
  return {
    phase: "start",
    lastPoint: null,
    shape: d.shape,
    up: d.up,
    width: d.width,
    referenz: d.referenz,
    treadMode: d.treadMode,
    auftritt: d.auftritt,
    steps: d.steps,
    rise: d.rise,
  };
 }
 /**
 * Baut aus dem Laufzustand ein konkretes `Stair`-Objekt (aufgelöste Felder). Die
 * Richtung/Länge folgen aus start→cursor; bei L bricht der zweite Lauf um 90°
 * (links) ab, bei Wendel wird der Cursorabstand zum Radius.
 *
 * Im Trittmass-Modus „mit" wird die Stufenzahl aus dem Soll-Auftritt + der
 * aktuellen Lauflänge abgeleitet (stepsFromTread), kein freies steps-Feld.
 */
 function buildStair(s: StairRun, ctx: CommandContext): Stair {
  const rise = s.rise ?? floorRise(ctx);
@@ -110,7 +185,15 @@ function buildStair(s: StairRun, ctx: CommandContext): Stair {
  const dist = Math.max(0.1, lenOf(d));
  const dir = dist > EPS ? normv(d) : ({ x: 1, y: 0 } as MVec2);
  const runLength = s.shape === "spiral" ? Math.max(0.5, dist) : dist;
-  const steps = s.steps ?? defaultStepCount(rise, runLength);
+
  // Stufenzahl je Trittmass-Modus:
  //   „mit Trittmass" → aus Auftritt + Lauflänge ableiten (Soll-Schrittmass).
  //   „ohne Trittmass" → manuell oder defaultStepCount (heutiges Verhalten).
  const steps =
    s.treadMode === "with"
      ? stepsFromTread(s.auftritt, runLength)
      : (s.steps ?? defaultStepCount(rise, runLength));
  const base: Stair = {
    id: uniqueId("ST"),
    type: "stair",
@@ -121,6 +204,7 @@ function buildStair(s: StairRun, ctx: CommandContext): Stair {
    dir,
    runLength,
    width: s.width,
    referenz: s.referenz,
    totalRise: rise,
    stepCount: steps,
    up: s.up,
@@ -156,18 +240,42 @@ function runDraft(s: StairRun, ctx: CommandContext): ToolDraft {
  return draft;
 }
-/** Hängt eine Treppe ans Projekt (immutabel). */
+/** Hängt eine Treppe ans Projekt (immutabel) und aktualisiert die Defaults. */
 function appendStair(p: Project, s: StairRun, ctx: CommandContext): Project {
  const stair = buildStair(s, ctx);
  // Zuletzt genutzte Einstellungen für die nächste Treppe merken.
  stairDefaults.shape = s.shape;
  stairDefaults.up = s.up;
  stairDefaults.width = s.width;
  stairDefaults.referenz = s.referenz;
  stairDefaults.treadMode = s.treadMode;
  stairDefaults.auftritt = s.auftritt;
  stairDefaults.steps = s.steps;
  stairDefaults.rise = s.rise;
  const stairs = p.stairs ? [...p.stairs, stair] : [stair];
  return { ...p, stairs };
 }
 const idle = (from?: StairCmdState): [CommandState, CommandResult] => [
-  initState(from?.shape ?? "straight"),
+  initState(from ? {
    shape: from.shape,
    up: from.up,
    width: from.width,
    referenz: from.referenz,
    treadMode: from.treadMode,
    auftritt: from.auftritt,
    steps: from.steps,
    rise: from.rise,
  } : undefined),
  { draft: null, done: true },
 ];
 // ── Referenz-Toggle-Zyklus ────────────────────────────────────────────────────
 function nextReferenz(r: "links" | "mitte" | "rechts"): "links" | "mitte" | "rechts" {
  return r === "links" ? "mitte" : r === "mitte" ? "rechts" : "links";
 }
 // ── Command-Export ────────────────────────────────────────────────────────────
 export const stairCommand: Command = {
  name: "stair",
  labelKey: "cmd.stair.label",
@@ -177,14 +285,20 @@ export const stairCommand: Command = {
    (s as StairCmdState).phase === "run"
      ? ["point", "number", "option"]
      : ["point", "option"],
  /** Optionen werden IMMER angezeigt (idle + run): Grundform, Auf/Ab, Referenz,
   *  Trittmass-Modus. */
  options: (s): CmdOption[] => {
    const st = s as StairCmdState;
    return [
      { ...SHAPE, value: st.shape },
      { ...UPDOWN, value: st.up ? "up" : "down" },
      { ...REFERENZ, value: st.referenz },
      { ...TREAD_MODE, value: st.treadMode },
    ];
  },
-  init: (): StairIdle => initState("straight"),
+
  init: (): StairIdle => initState(),
  onInput: (state, input, ctx): [CommandState, CommandResult] => {
    const s = state as StairCmdState;
@@ -195,6 +309,12 @@ export const stairCommand: Command = {
        next.shape = s.shape === "straight" ? "L" : s.shape === "L" ? "spiral" : "straight";
      } else if (input.id === "updown") {
        next.up = !s.up;
      } else if (input.id === "referenz") {
        next.referenz = nextReferenz(s.referenz);
      } else if (input.id === "treadMode") {
        next.treadMode = s.treadMode === "with" ? "without" : "with";
        // Im „mit"-Modus freie Stufenzahl zurücksetzen (wird abgeleitet).
        if (next.treadMode === "with") next.steps = null;
      }
      return [next, { draft: next.phase === "run" ? runDraft(next as StairRun, ctx) : null }];
    }
@@ -211,6 +331,9 @@ export const stairCommand: Command = {
        shape: s.shape,
        up: s.up,
        width: s.width,
        referenz: s.referenz,
        treadMode: s.treadMode,
        auftritt: s.auftritt,
        steps: s.steps,
        rise: s.rise,
        start: pt,
@@ -249,20 +372,50 @@ export const stairCommand: Command = {
  },
  onCancel: (state): [CommandState, CommandResult] => idle(state as StairCmdState),
-  fields: (state) => ((state as StairCmdState).phase === "run" ? RUN_FIELDS : []),
+  /**
-  // Getippte Tab-Felder sticky in den State übernehmen; kein Koordinatenpunkt.
+   * Tab-Felder:
   *   • idle-Phase: [Breite] (Konfiguration VOR dem ersten Punkt).
   *   • run-Phase, Trittmass-Modus „ohne": [Breite, Stufen, Steighöhe].
   *   • run-Phase, Trittmass-Modus „mit" : [Breite, Auftritt].
   */
  fields: (state): CommandField[] => {
    const s = state as StairCmdState;
    if (s.phase === "start") {
      return [FIELD_WIDTH];
    }
    // run-Phase
    if (s.treadMode === "with") {
      return [FIELD_WIDTH, FIELD_AUFTRITT];
    }
    return [FIELD_WIDTH, FIELD_STEPS, FIELD_RISE];
  },
  /** Getippte Tab-Felder sticky in den State übernehmen; kein Koordinatenpunkt. */
  pointFromFields: (state, locks) => {
    const s = state as StairCmdState;
    if ("width" in locks && locks.width > 0) s.width = locks.width;
-    if ("steps" in locks && locks.steps >= 2) s.steps = Math.round(locks.steps);
+    if (s.phase === "run") {
-    if ("rise" in locks && locks.rise > 0) s.rise = locks.rise;
+      if ("auftritt" in locks && locks.auftritt > 0) s.auftritt = locks.auftritt;
      // Stufen + Steighöhe nur im „ohne"-Modus als freie Felder.
      if (s.treadMode === "without") {
        if ("steps" in locks && locks.steps >= MIN_STEPS) s.steps = Math.round(locks.steps);
        if ("rise" in locks && locks.rise > 0) s.rise = locks.rise;
      }
    }
    return null;
  },
  fieldValues: (state, _locks, _cursor): Record<string, number> => {
    const s = state as StairCmdState;
    const out: Record<string, number> = { width: s.width };
-    if (s.steps != null) out.steps = s.steps;
+    if (s.phase === "run") {
-    if (s.rise != null) out.rise = s.rise;
+      if (s.treadMode === "with") {
        out.auftritt = s.auftritt;
      } else {
        if (s.steps != null) out.steps = s.steps;
        if (s.rise != null) out.rise = s.rise;
      }
    }
    return out;
  },
 };
@@ -0,0 +1,76 @@
 // Text — modellverankerter Einzeltext als 2D-Element. Schritte:
 //   1) „Ankerpunkt:" → Punkt (Position im Modell)
 //   2) „Text:"        → getippte Zeile (das Label) → commit Drawing2D {shape:"text"}
 //
 // Der Text-Schritt nimmt Freitext an (accepts:["text"]) — die Engine reicht die
 // komplette getippte Zeile 1:1 durch (auch Zahlen/Kommas). Gerendert wird der
 // Text in generatePlan als `drawingText` (SVG), analog zum DXF-Import.
 import type { Drawing2D } from "../../model/types";
 import { uniqueId } from "../../tools/types";
 import type {
  Command,
  CommandContext,
  CommandResult,
  CommandState,
  Project,
  Vec2,
 } from "../types";
 /** Default-Schrifthöhe eines frei platzierten Texts in Modell-Metern. */
 const DEFAULT_TEXT_HEIGHT_M = 0.25;
 interface TextIdle extends CommandState {
  phase: "point";
 }
 interface TextLabel extends CommandState {
  phase: "label";
  at: Vec2;
 }
 type TextState = TextIdle | TextLabel;
 function appendText(p: Project, at: Vec2, text: string, ctx: CommandContext): Project {
  const label = text.trim();
  if (label === "") return p;
  const d: Drawing2D = {
    id: uniqueId("dr2d"),
    type: "drawing2d",
    levelId: ctx.level.id,
    categoryCode: ctx.defaultCategoryCode,
    geom: { shape: "text", at, text: label, height: DEFAULT_TEXT_HEIGHT_M, angle: 0 },
  };
  return { ...p, drawings2d: [...p.drawings2d, d] };
 }
 const idle = (): [CommandState, CommandResult] => [
  { phase: "point", lastPoint: null },
  { draft: null, done: true },
 ];
 export const textCommand: Command = {
  name: "text",
  labelKey: "cmd.text.label",
  prompt: (s) => ((s as TextState).phase === "label" ? "cmd.text.enter" : "cmd.text.point"),
  accepts: (s) => ((s as TextState).phase === "label" ? ["text"] : ["point"]),
  options: () => [],
  init: (): TextIdle => ({ phase: "point", lastPoint: null }),
  onInput: (state, input, ctx): [CommandState, CommandResult] => {
    const s = state as TextState;
    if (s.phase !== "label") {
      if (input.kind !== "point") return [s, { draft: null }];
      const ns: TextLabel = { phase: "label", at: input.point, lastPoint: input.point };
      return [ns, { draft: null }];
    }
    if (input.kind !== "text") return [s, { draft: null }];
    const at = s.at;
    return [
      { phase: "point", lastPoint: null },
      { draft: null, done: true, commit: (p) => appendText(p, at, input.text, ctx) },
    ];
  },
  onMove: (state): [CommandState, CommandResult] => [state, { draft: null }],
  onConfirm: (): [CommandState, CommandResult] => idle(),
  onCancel: (): [CommandState, CommandResult] => idle(),
 };
@@ -0,0 +1,127 @@
 // Textspalte (Absatztext) — wie das Text-Werkzeug, aber mit einer Spaltenbreite:
 // der Text bricht beim Rendern wortweise auf diese Breite um. Schritte:
 //   1) „Ankerpunkt:"     → Punkt (oben-links der Spalte)
 //   2) „Spaltenbreite:"   → Punkt (die horizontale Distanz zum Anker = Breite;
 //                            Live-Vorschau der Breitenlinie)
 //   3) „Text:"            → getippte Zeile → commit Drawing2D {shape:"text", width}
 //
 // Reuse des bestehenden {shape:"text"}-Elements (mit `width`) — so erben Selektion,
 // Verschieben und Griff automatisch vom Einzeltext; nur die Breite kommt hinzu.
 import type { Drawing2D } from "../../model/types";
 import { uniqueId } from "../../tools/types";
 import type {
  Command,
  CommandContext,
  CommandResult,
  CommandState,
  Project,
  ToolDraft,
  Vec2,
 } from "../types";
 /** Default-Schrifthöhe einer Textspalte in Modell-Metern. */
 const DEFAULT_TEXT_HEIGHT_M = 0.25;
 /** Kleinste sinnvolle Spaltenbreite (Meter). */
 const MIN_WIDTH_M = 0.2;
 interface TbPoint extends CommandState {
  phase: "point";
 }
 interface TbWidth extends CommandState {
  phase: "width";
  at: Vec2;
  cursor: Vec2 | null;
 }
 interface TbLabel extends CommandState {
  phase: "label";
  at: Vec2;
  width: number;
 }
 type TbState = TbPoint | TbWidth | TbLabel;
 /** Horizontale Spaltenbreite aus Anker + Cursor (Betrag der x-Differenz, geklemmt). */
 function widthOf(at: Vec2, cursor: Vec2): number {
  return Math.max(MIN_WIDTH_M, Math.abs(cursor.x - at.x));
 }
 /** Vorschau: waagrechte Breitenlinie am Anker (zeigt die Spaltenbreite). */
 function widthDraft(at: Vec2, cursor: Vec2): ToolDraft {
  const w = widthOf(at, cursor);
  const b: Vec2 = { x: at.x + w, y: at.y };
  return {
    preview: [{ kind: "line", a: at, b }],
    vertices: [at, b],
    hud: { at: b, text: `${w.toFixed(2)} m` },
  };
 }
 function appendTextbox(
  p: Project,
  at: Vec2,
  width: number,
  text: string,
  ctx: CommandContext,
 ): Project {
  const label = text.trim();
  if (label === "") return p;
  const d: Drawing2D = {
    id: uniqueId("dr2d"),
    type: "drawing2d",
    levelId: ctx.level.id,
    categoryCode: ctx.defaultCategoryCode,
    geom: { shape: "text", at, text: label, height: DEFAULT_TEXT_HEIGHT_M, angle: 0, width },
  };
  return { ...p, drawings2d: [...p.drawings2d, d] };
 }
 const idle = (): [CommandState, CommandResult] => [
  { phase: "point", lastPoint: null } as TbPoint,
  { draft: null, done: true },
 ];
 export const textboxCommand: Command = {
  name: "textbox",
  labelKey: "cmd.textbox.label",
  prompt: (s) => {
    const ts = s as TbState;
    if (ts.phase === "label") return "cmd.textbox.enter";
    if (ts.phase === "width") return "cmd.textbox.width";
    return "cmd.textbox.point";
  },
  accepts: (s) => ((s as TbState).phase === "label" ? ["text"] : ["point"]),
  options: () => [],
  init: (): TbPoint => ({ phase: "point", lastPoint: null }),
  onInput: (state, input, ctx): [CommandState, CommandResult] => {
    const s = state as TbState;
    if (s.phase === "point") {
      if (input.kind !== "point") return [s, { draft: null }];
      const ns: TbWidth = { phase: "width", at: input.point, cursor: input.point, lastPoint: input.point };
      return [ns, { draft: widthDraft(input.point, input.point) }];
    }
    if (s.phase === "width") {
      if (input.kind !== "point") return [s, { draft: s.cursor ? widthDraft(s.at, s.cursor) : null }];
      const width = widthOf(s.at, input.point);
      const ns: TbLabel = { phase: "label", at: s.at, width, lastPoint: input.point };
      return [ns, { draft: null }];
    }
    // label
    if (input.kind !== "text") return [s, { draft: null }];
    const { at, width } = s;
    return [
      { phase: "point", lastPoint: null } as TbPoint,
      { draft: null, done: true, commit: (p) => appendTextbox(p, at, width, input.text, ctx) },
    ];
  },
  onMove: (state, point): [CommandState, CommandResult] => {
    const s = state as TbState;
    if (s.phase !== "width") return [s, { draft: null }];
    const ns: TbWidth = { ...s, cursor: point };
    return [ns, { draft: widthDraft(s.at, point) }];
  },
  onConfirm: (): [CommandState, CommandResult] => idle(),
  onCancel: (): [CommandState, CommandResult] => idle(),
 };
@@ -0,0 +1,87 @@
 /**
 * Unit-Tests für das Cursor-HUD (Länge/Winkel) des `wall`-Befehls: nach dem
 * Startpunkt muss `onMove` im Draft `hud.length`/`hud.angleDeg` relativ zum
 * ZULETZT gesetzten Achspunkt liefern — auch nach mehreren Segmenten
 * (Chaining), damit ein mehrteiliger Wandzug je Segment ein frisches HUD zeigt.
 */
 import { describe, it, expect } from "vitest";
 import { wallCommand } from "./wall";
 import type { CommandContext, Project, Vec2 } from "../types";
 function project(): Project {
  return {
    id: "t",
    name: "T",
    lineStyles: [],
    hatches: [],
    components: [{ id: "c", name: "C", color: "#ccc", hatchId: "none", joinPriority: 10 }],
    wallTypes: [
      { id: "aw", name: "AW", layers: [{ componentId: "c", thickness: 0.2 }] },
    ],
    drawingLevels: [
      {
        id: "eg",
        name: "EG",
        kind: "floor",
        visible: true,
        locked: false,
        floorHeight: 2.6,
        cutHeight: 1.0,
        baseElevation: 0,
      },
    ],
    layers: [{ code: "20", name: "Wände", color: "#0a0a0a", lw: 0.5, visible: true, locked: false }],
    walls: [],
    doors: [],
    openings: [],
    ceilings: [],
    stairs: [],
    rooms: [],
    drawings2d: [],
    context: [],
  };
 }
 function makeCtx(lastPoint: Vec2 | null): CommandContext {
  const p = project();
  return {
    project: p,
    level: p.drawingLevels[0],
    defaultCategoryCode: "20",
    activeLineStyleId: "solid",
    activeWallTypeId: "aw",
    lastPoint,
    selection: { wallIds: [], drawingId: null },
  };
 }
 describe("wallCommand — Cursor-HUD (Länge/Winkel)", () => {
  it("liefert hud.length/angleDeg relativ zum Startpunkt", () => {
    const start: Vec2 = { x: 0, y: 0 };
    const [afterStart] = wallCommand.onInput(
      wallCommand.init(),
      { kind: "point", point: start },
      makeCtx(null),
    );
    const [, res] = wallCommand.onMove(afterStart, { x: 4, y: 0 }, null, makeCtx(start));
    expect(res.draft?.hud?.length).toBeCloseTo(4, 9);
    expect(res.draft?.hud?.angleDeg).toBeCloseTo(0, 9);
  });
  it("HUD bezieht sich nach dem zweiten Punkt auf das NEUE (letzte) Segment", () => {
    const p0: Vec2 = { x: 0, y: 0 };
    const p1: Vec2 = { x: 4, y: 0 };
    const [s1] = wallCommand.onInput(wallCommand.init(), { kind: "point", point: p0 }, makeCtx(null));
    const [s2] = wallCommand.onInput(s1, { kind: "point", point: p1 }, makeCtx(p0));
    // Nächstes Segment ab p1 nach oben (0,3) → Länge 3, Winkel 90°.
    const [, res] = wallCommand.onMove(s2, { x: 4, y: 3 }, null, makeCtx(p1));
    expect(res.draft?.hud?.length).toBeCloseTo(3, 9);
    expect(res.draft?.hud?.angleDeg).toBeCloseTo(90, 9);
  });
  it("zeigt KEIN HUD vor dem Startpunkt (phase=start)", () => {
    const [, res] = wallCommand.onMove(wallCommand.init(), { x: 1, y: 1 }, null, makeCtx(null));
    expect(res.draft).toBeNull();
  });
 });
@@ -18,7 +18,7 @@
 import type { Wall, WallType } from "../../model/types";
 import { wallTypeThickness } from "../../model/types";
 import { wallCorners } from "../../model/geometry";
-import { uniqueId } from "../../tools/types";
+import { segmentHud, uniqueId } from "../../tools/types";
 import type {
  Command,
  CommandContext,
@@ -164,14 +164,7 @@ function wallDraft(points: Vec2[], cursor: Vec2 | null, thickness: number): Tool
  }
  const draft: ToolDraft = { preview, vertices: points };
  const last = points[points.length - 1];
-  if (cursor && last && segLen(last, cursor) >= EPS) {
+  if (cursor && last && segLen(last, cursor) >= EPS) draft.hud = segmentHud(last, cursor);
    draft.hud = {
      at: cursor,
      text: `${segLen(last, cursor).toFixed(2)} m · ${Math.abs(
        (segAngleDeg(last, cursor) + 360) % 360,
      ).toFixed(0)}°`,
    };
  }
  return draft;
 }
@@ -328,6 +328,14 @@ export class CommandEngine {
      }
    }
    // Freitext-Schritt (z. B. Text-Platzierung): der Schritt nimmt beliebigen
    // Text als Label — die komplette getippte Zeile geht 1:1 durch (auch Zahlen/
    // Kommas), bevor die numerische/Koordinaten-Auflösung greift.
    if (accepts.includes("text")) {
      this.feed({ kind: "text", text });
      return;
    }
    const parsed = parseInput(text);
    // Tab-Feld-Modus (§2.7): eine nackte Zahl LOCKT das aktive Feld (statt als
@@ -10,17 +10,27 @@ import { wallCommand } from "./cmds/wall";
 import { ceilingCommand } from "./cmds/ceiling";
 import { openingCommand, fensterCommand, tuerCommand } from "./cmds/opening";
 import { stairCommand } from "./cmds/stair";
 import { columnCommand } from "./cmds/column";
 import { roofCommand } from "./cmds/roof";
 import { ceilingOpeningCommand } from "./cmds/ceilingOpening";
 import { roomCommand } from "./cmds/room";
 import { rectCommand } from "./cmds/rect";
 import { circleCommand } from "./cmds/circle";
 import { arcCommand } from "./cmds/arc";
 import { textCommand } from "./cmds/text";
 import { textboxCommand } from "./cmds/textbox";
 import { moveCommand } from "./cmds/move";
 import { mirrorCommand } from "./cmds/mirror";
 import { joinCommand } from "./cmds/join";
 import { copyCommand } from "./cmds/copy";
 import { offsetCommand } from "./cmds/offset";
 import { extrudeCommand } from "./cmds/extrude";
 import { trimCommand } from "./cmds/trim";
 import { importCommand } from "./cmds/import";
 import { terrainCommand } from "./cmds/terrain";
 import { measureCommand } from "./cmds/measure";
 import { sectionLineCommand, viewLineCommand } from "./cmds/sectionline";
 import { georefCommand } from "./cmds/georef";
 /** Alle bekannten Befehle, Schlüssel = Befehlsname (lowercase). */
 export const COMMANDS: Record<string, Command> = {
@@ -30,19 +40,30 @@ export const COMMANDS: Record<string, Command> = {
  fenster: fensterCommand,
  tuer: tuerCommand,
  stair: stairCommand,
  column: columnCommand,
  roof: roofCommand,
  ceilingopening: ceilingOpeningCommand,
  room: roomCommand,
  line: lineCommand,
  polyline: polylineCommand,
  rect: rectCommand,
  circle: circleCommand,
  arc: arcCommand,
  text: textCommand,
  textbox: textboxCommand,
  move: moveCommand,
  mirror: mirrorCommand,
  join: joinCommand,
  copy: copyCommand,
  offset: offsetCommand,
  extrude: extrudeCommand,
  trim: trimCommand,
  import: importCommand,
  terrain: terrainCommand,
  measure: measureCommand,
  sectionline: sectionLineCommand,
  viewline: viewLineCommand,
  georef: georefCommand,
 };
 /**
@@ -61,12 +82,23 @@ export const ALIASES: Record<string, string> = {
  oe: "opening",
  treppe: "stair",
  tp: "stair",
  stuetze: "column",
  stütze: "column",
  dach: "roof",
  deckenloch: "ceilingopening",
  aussparung: "ceilingopening",
  rf: "roof",
  raum: "room",
  rm: "room",
  l: "line",
  pl: "polyline",
  rec: "rect",
  c: "circle",
  a: "arc",
  bogen: "arc",
  tx: "text",
  txt: "text",
  beschriftung: "text",
  m: "move",
  s: "mirror",
  spiegeln: "mirror",
@@ -74,9 +106,14 @@ export const ALIASES: Record<string, string> = {
  verbinden: "join",
  cp: "copy",
  o: "offset",
  ex: "extrude",
  tr: "trim",
  imp: "import",
  ter: "terrain",
  schnittlinie: "sectionline",
  ansichtslinie: "viewline",
  bezugspunkt: "georef",
  nullpunkt: "georef",
 };
 /** Liefert den Befehl zu einem exakten Namen (oder undefined). */
@@ -15,11 +15,12 @@ import type { DrawingLevel } from "../model/types";
 import type { SnapResult, ToolDraft } from "../tools/types";
 export type { DraftShape, SnapResult, ToolDraft } from "../tools/types";
 export { segmentHud, angleDegOf } from "../tools/types";
 // ── Eingabe-Arten ────────────────────────────────────────────────────────────
 /** Arten von Eingaben, die ein Schritt annehmen kann. */
-export type AcceptKind = "point" | "number" | "option" | "selection";
+export type AcceptKind = "point" | "number" | "option" | "text" | "selection";
 /**
 * Geparste, noch nicht aufgelöste Roh-Eingabe aus der Command-Line bzw. der
@@ -67,6 +68,10 @@ export interface CommandSelection {
   * `drawingId` (falls gesetzt) als einziges Element.
   */
  drawingIds?: string[];
  /** Gewählter extrudierter Körper (truck-Integration), falls einer selektiert ist. */
  extrudedSolidId?: string | null;
  /** Gewählte Stütze (Tragwerk), falls eine selektiert ist. */
  columnId?: string | null;
 }
 /** Live-Kontext, den ein Befehl bei jedem Schritt erhält (analog ToolContext). */
@@ -0,0 +1,70 @@
 let modulePromise: Promise<any> | null = null;
 async function getModule(): Promise<any> {
  if (!modulePromise) {
    modulePromise = import("./pkgTruck/trucksolid.js").then(async (m: any) => {
      await m.default();
      return m;
    });
  }
  return modulePromise;
 }
 export interface ExtrudedMesh {
  positions: number[];
  indices: number[];
 }
 /** `taper` 0 (Prisma, Default) … 1 (Spitze/Kegel-Pyramide) — linear zum
 *  Profil-Schwerpunkt skaliert. */
 export async function extrudePolygon(
  points: number[],
  height: number,
  taper = 0,
 ): Promise<ExtrudedMesh> {
  const m = await getModule();
  const json = m.extrude_polygon(JSON.stringify({ points, height, taper }));
  return JSON.parse(json) as ExtrudedMesh;
 }
 export async function extrudeCircle(
  cx: number,
  cy: number,
  r: number,
  height: number,
  taper = 0,
 ): Promise<ExtrudedMesh> {
  const m = await getModule();
  const json = m.extrude_circle(JSON.stringify({ cx, cy, r, height, taper }));
  return JSON.parse(json) as ExtrudedMesh;
 }
 export type BooleanOp = "union" | "difference" | "intersection";
 export interface BooleanMeshResult {
  positions: number[];
  indices: number[];
  empty: boolean;
 }
 /** Boolesche Operation zweier Dreiecks-Meshes (Mesh-Ebenen-CSG via csgrs,
 *  truck-Integration Phase 4). Beide Meshes müssen konsistent nach außen
 *  gewundene Dreiecke haben (Rechte-Hand-Regel) — sonst liefert csgrs ein
 *  falsches Ergebnis, ohne das zu erkennen. */
 export async function booleanMesh(
  a: ExtrudedMesh,
  b: ExtrudedMesh,
  op: BooleanOp,
 ): Promise<BooleanMeshResult> {
  const m = await getModule();
  const json = m.boolean_mesh(
    JSON.stringify({
      a_positions: a.positions,
      a_indices: a.indices,
      b_positions: b.positions,
      b_indices: b.indices,
      op,
    }),
  );
  return JSON.parse(json) as BooleanMeshResult;
 }
@@ -28,6 +28,10 @@ const LAYER_HATCH = "HATCH";
 const LAYER_SYMBOLS = "SYMBOLS";
 const LAYER_CONTEXT = "CONTEXT";
 const LAYER_DEFAULT = "PLAN";
 /** Sammel-Layer für Extrusions-Footprints (truck-Integration) — die Quell-
 *  Drawing2D wird beim Extrudieren entfernt, es gibt also keine categoryCode
 *  mehr nachzuschlagen; eigener Layer statt Absturz in LAYER_DEFAULT. */
 const LAYER_EXTRUSION = "EXTRUSION";
 /**
 * Baut aus einem Plan + Projekt einen vollständigen DXF-String (Meter-Modell-Space).
@@ -60,6 +64,8 @@ export function buildPlanDxf(
  dxf.addLayer({ name: LAYER_HATCH, color: 8, trueColor: 0x888888, lineWeight: 13 });
  dxf.addLayer({ name: LAYER_CONTEXT, color: 9, trueColor: 0x9aa3ad, lineWeight: 10 });
  dxf.addLayer({ name: LAYER_DEFAULT, color: 7, trueColor: 0x111111, lineWeight: 18 });
  // Warmes Orange, identisch zum 3D-/Grundriss-Footprint der Extrusionen (EXTRUSION_STROKE/EXTRUSION_RGB).
  dxf.addLayer({ name: LAYER_EXTRUSION, color: aciFromHex("#d98c40"), trueColor: rgbFromHex("#d98c40"), lineWeight: 13 });
  // 2) Rückverweise Primitiv → Kategorie: Wände/2D-Elemente tragen nur ihre ID im
  //    Plan; die Kategorie liegt am Projekt-Objekt. Damit landet jede Wand-/Drawing-
@@ -68,11 +74,15 @@ export function buildPlanDxf(
  for (const w of project.walls) codeByWall.set(w.id, w.categoryCode);
  const codeByDrawing = new Map<string, string>();
  for (const d of project.drawings2d) codeByDrawing.set(d.id, d.categoryCode);
  const codeByColumn = new Map<string, string>();
  for (const c of project.columns ?? []) codeByColumn.set(c.id, c.categoryCode);
  const layerFor = (p: Primitive): string => {
    if (p.kind === "polygon") {
      if (p.wallId) return layerNameByCode.get(codeByWall.get(p.wallId) ?? "") ?? LAYER_DEFAULT;
      if (p.drawingId) return layerNameByCode.get(codeByDrawing.get(p.drawingId) ?? "") ?? LAYER_DEFAULT;
      if (p.columnId) return layerNameByCode.get(codeByColumn.get(p.columnId) ?? "") ?? LAYER_DEFAULT;
      if (p.extrudedSolidId) return LAYER_EXTRUSION;
      return LAYER_DEFAULT;
    }
    if (p.kind === "line") {
@@ -0,0 +1,370 @@
 // Unit-Tests für den IFC4-Export (exportIfcSpf) — erste vollständige Scheibe.
 //   • Strukturelle Validität: KEINE dangling references (jede #N-Referenz ist
 //     definiert), KEINE doppelten Entity-IDs — der wichtigste Test.
 //   • Header/FILE_SCHEMA('IFC4') vorhanden.
 //   • Je "floor"-Geschoss genau ein IfcBuildingStorey.
 //   • Wandanzahl → IfcWall-Anzahl.
 //   • Eine Öffnung ⇒ IfcOpeningElement + IfcRelVoidsElement (+ IfcDoor/
 //     IfcWindow + IfcRelFillsElement).
 //   • GUID-Format (22 Zeichen, gültiger Zeichensatz), deterministisch.
 //   • Leeres Projekt ⇒ valider Minimal-IFC (Project/Site/Building, kein Crash).
 //
 // Fixture-Muster gespiegelt von exportSchedule.test.ts.
 import { describe, it, expect } from "vitest";
 import { exportIfcSpf, ifcGuid } from "./exportIfc";
 import type {
  Ceiling,
  ExtrudedSolid,
  Opening,
  Project,
  Stair,
  Wall,
 } from "../model/types";
 /**
 * Minimalprojekt: 2 Geschosse (EG + OG, EG auch ein "section"-Level, das
 * NICHT zu einem Storey werden darf) + 2 Wände (Wandtyp T=0.4) + 1 Decke
 * (Deckentyp T=0.2) + 1 Tür + 1 Fenster (an W1 gehostet) + 1 Treppe +
 * 1 Extrusion.
 */
 function fixtureProject(): Project {
  const walls: Wall[] = [
    {
      id: "W1",
      type: "wall",
      floorId: "eg",
      categoryCode: "20",
      start: { x: 0, y: 0 },
      end: { x: 5, y: 0 },
      wallTypeId: "aw",
      height: 2.6,
    },
    {
      id: "W2",
      type: "wall",
      floorId: "eg",
      categoryCode: "20",
      start: { x: 5, y: 0 },
      end: { x: 5, y: 4 },
      wallTypeId: "aw",
      height: 2.6,
    },
  ];
  const ceilings: Ceiling[] = [
    {
      id: "D1",
      type: "ceiling",
      floorId: "eg",
      categoryCode: "30",
      outline: [
        { x: 0, y: 0 },
        { x: 5, y: 0 },
        { x: 5, y: 4 },
        { x: 0, y: 4 },
      ],
      wallTypeId: "dt",
      ceilingTypeId: "dt",
    },
  ];
  const openings: Opening[] = [
    {
      id: "T1",
      type: "opening",
      hostWallId: "W1",
      categoryCode: "21",
      kind: "door",
      position: 1,
      width: 0.9,
      height: 2.1,
      sillHeight: 0,
    },
    {
      id: "F1",
      type: "opening",
      hostWallId: "W2",
      categoryCode: "21",
      kind: "window",
      position: 1,
      width: 1.2,
      height: 1.5,
      sillHeight: 0.9,
    },
  ];
  const stairs: Stair[] = [
    {
      id: "S1",
      type: "stair",
      floorId: "eg",
      categoryCode: "40",
      shape: "straight",
      start: { x: 0, y: 0 },
      dir: { x: 1, y: 0 },
      runLength: 3,
      width: 1.2,
      totalRise: 2.6,
      stepCount: 16,
    },
  ];
  const extrudedSolids: ExtrudedSolid[] = [
    {
      id: "E1",
      type: "extrudedSolid",
      levelId: "eg",
      points: [
        { x: 0, y: 0 },
        { x: 2, y: 0 },
        { x: 2, y: 3 },
        { x: 0, y: 3 },
      ],
      height: 2.5,
    },
  ];
  return {
    id: "t",
    name: "Testprojekt",
    lineStyles: [],
    hatches: [],
    components: [{ id: "c", name: "C", color: "#ccc", hatchId: "none", joinPriority: 10 }],
    wallTypes: [{ id: "aw", name: "Aussenwand", layers: [{ componentId: "c", thickness: 0.4 }] }],
    ceilingTypes: [{ id: "dt", name: "Betondecke", layers: [{ componentId: "c", thickness: 0.2 }] }],
    drawingLevels: [
      { id: "eg", name: "EG", kind: "floor", visible: true, locked: false, floorHeight: 2.6, cutHeight: 1.0, baseElevation: 0 },
      { id: "og", name: "OG", kind: "floor", visible: true, locked: false, floorHeight: 2.6, cutHeight: 1.0, baseElevation: 2.6 },
      { id: "schnitt-a", name: "Schnitt A", kind: "section", visible: true, locked: false, linePoints: [{ x: 0, y: 0 }, { x: 1, y: 0 }], directionSign: 1 },
    ],
    layers: [{ code: "20", name: "Wände", color: "#0a0a0a", lw: 0.5, visible: true, locked: false }],
    walls,
    doors: [],
    openings,
    ceilings,
    stairs,
    extrudedSolids,
    rooms: [],
    drawings2d: [],
    context: [],
  } as Project;
 }
 /** Sammelt alle definierten Entity-IDs (`#N=`) und alle referenzierten `#N`. */
 function collectIds(spf: string): { defined: Set<number>; referenced: Set<number>; duplicates: number[] } {
  const defined = new Set<number>();
  const duplicates: number[] = [];
  const referenced = new Set<number>();
  for (const line of spf.split("\n")) {
    const defMatch = /^#(\d+)=/.exec(line);
    if (defMatch) {
      const id = Number(defMatch[1]);
      if (defined.has(id)) duplicates.push(id);
      defined.add(id);
    }
    const refs = line.matchAll(/#(\d+)/g);
    for (const r of refs) {
      // Der erste Treffer je Zeile ist ggf. die Definition selbst — trotzdem
      // harmlos mitgezählt, da sie ja in `defined` steht (Selbstreferenz-Check
      // unten prüft nur: JEDE referenzierte ID muss iRGENDWO definiert sein).
      referenced.add(Number(r[1]));
    }
  }
  return { defined, referenced, duplicates };
 }
 describe("exportIfcSpf — IFC4-Export", () => {
  it("erzeugt keine dangling references und keine doppelten Entity-IDs", () => {
    const spf = exportIfcSpf(fixtureProject());
    const { defined, referenced, duplicates } = collectIds(spf);
    expect(duplicates).toEqual([]);
    const dangling = [...referenced].filter((id) => !defined.has(id));
    expect(dangling).toEqual([]);
    expect(defined.size).toBeGreaterThan(0);
  });
  it("trägt einen gültigen IFC4-Header", () => {
    const spf = exportIfcSpf(fixtureProject());
    expect(spf).toContain("ISO-10303-21;");
    expect(spf).toContain("FILE_SCHEMA(('IFC4'));");
    expect(spf).toContain("END-ISO-10303-21;");
  });
  it("erzeugt je 'floor'-Geschoss genau ein IfcBuildingStorey (Schnitte NICHT)", () => {
    const spf = exportIfcSpf(fixtureProject());
    const storeyLines = spf.split("\n").filter((l) => l.includes("=IFCBUILDINGSTOREY("));
    expect(storeyLines).toHaveLength(2); // EG + OG, NICHT "Schnitt A"
    expect(storeyLines.some((l) => l.includes("'EG'"))).toBe(true);
    expect(storeyLines.some((l) => l.includes("'OG'"))).toBe(true);
  });
  it("bildet jede Wand auf genau ein IfcWall ab", () => {
    const spf = exportIfcSpf(fixtureProject());
    const wallLines = spf.split("\n").filter((l) => l.includes("=IFCWALL("));
    expect(wallLines).toHaveLength(2);
  });
  it("Tür/Fenster bleiben eigene Objekte (IfcDoor/IfcWindow); das Loch steckt im Wand-Mesh (kein IfcOpeningElement/Void/Fill)", () => {
    const spf = exportIfcSpf(fixtureProject());
    const lines = spf.split("\n");
    // Tür + Fenster als eigene Objekte erhalten.
    expect(lines.filter((l) => l.includes("=IFCDOOR("))).toHaveLength(1);
    expect(lines.filter((l) => l.includes("=IFCWINDOW("))).toHaveLength(1);
    // Bewusste Abwägung: Wand ist jetzt ein Face-Set mit ausgeschnittenem Loch —
    // die frühere IfcOpeningElement-Void/Fill-Semantik entfällt (siehe Dateikopf).
    expect(lines.filter((l) => l.includes("=IFCOPENINGELEMENT("))).toHaveLength(0);
    expect(lines.filter((l) => l.includes("=IFCRELVOIDSELEMENT("))).toHaveLength(0);
    expect(lines.filter((l) => l.includes("=IFCRELFILLSELEMENT("))).toHaveLength(0);
  });
  it("bildet Wände als IfcTriangulatedFaceSet (IfcCartesianPointList3D + CoordIndex) statt Profil-Extrusion ab", () => {
    const spf = exportIfcSpf(fixtureProject());
    const lines = spf.split("\n");
    // Genau ein Face-Set + eine Punktliste je Wand (2 Wände).
    expect(lines.filter((l) => l.includes("=IFCTRIANGULATEDFACESET("))).toHaveLength(2);
    expect(lines.filter((l) => l.includes("=IFCCARTESIANPOINTLIST3D("))).toHaveLength(2);
    // Wand-Shape ist als Tessellation deklariert (nicht mehr SweptSolid).
    expect(spf).toContain("'Tessellation'");
    // Face-Set-CoordIndex referenziert 1-basierte Punkt-Indizes (Tripel-Listen).
    const fs = lines.find((l) => l.includes("=IFCTRIANGULATEDFACESET("));
    expect(fs).toMatch(/\(\(\d+,\d+,\d+\)/);
  });
  it("bildet Decke, Treppe und Extrusion auf die erwarteten Entity-Typen ab", () => {
    const spf = exportIfcSpf(fixtureProject());
    const lines = spf.split("\n");
    expect(lines.filter((l) => l.includes("=IFCSLAB("))).toHaveLength(1);
    expect(lines.filter((l) => l.includes("=IFCSTAIR("))).toHaveLength(1);
    expect(lines.filter((l) => l.includes("=IFCBUILDINGELEMENTPROXY("))).toHaveLength(1);
  });
  it("das Wand-Face-Set enthält das ausgeschnittene Fenster-Loch (Loch-Vertices + volle Dreieckszahl, keine dangling refs)", () => {
    // W2 hat das Fenster F1 (position 1, width 1.2, sill 0.9, height 1.5) → das
    // Loch liegt voll im Wand-Inneren; das Face-Set der Wand hat exakt die
    // Rust-Zerlegung: 8 Langseiten-Teilrechtecke ×2×2 + 8 (Deckel/Boden/Kappen)
    // + 8 (4 Laibungen) = 48 Dreiecke, 144 Punkte.
    const spf = exportIfcSpf(fixtureProject());
    const lines = spf.split("\n");
    const faceSets = lines.filter((l) => l.includes("=IFCTRIANGULATEDFACESET("));
    // Das Loch-Face-Set hat 48 CoordIndex-Tripel.
    const triCounts = faceSets.map((l) => (l.match(/\(\d+,\d+,\d+\)/g) ?? []).length);
    expect(triCounts).toContain(48);
    // Zugehörige Punktliste hat 144 Punkte (3er-Koordinaten-Tupel).
    const pointLists = lines.filter((l) => l.includes("=IFCCARTESIANPOINTLIST3D("));
    const ptCounts = pointLists.map((l) => (l.match(/\([^()]*,[^()]*,[^()]*\)/g) ?? []).length);
    expect(ptCounts).toContain(144);
    // Keine dangling refs (der Kern-Invarianten-Check gilt auch mit Face-Sets).
    const { defined, referenced } = collectIds(spf);
    expect([...referenced].filter((id) => !defined.has(id))).toEqual([]);
  });
  it("Wand-Face-Sets sind NACH AUSSEN orientiert (positives Volumen) — Regression gegen die Reflexions-Wicklung, die die Wand hohl machte", () => {
    // Der IFC-Achsen-Swap (x,y,z)→(x,z,y) ist eine Reflexion und kehrte die
    // Dreiecks-Wicklung um → Normalen zeigten nach INNEN → Viewer cullten die
    // Vorderseiten → Wand wirkte oben/unten offen. Nach dem Wicklungs-Ausgleich
    // muss das signierte Volumen jedes Wandkörpers POSITIV sein (aussen orientiert).
    const spf = exportIfcSpf(fixtureProject());
    const lines = spf.split("\n");
    const byId = new Map<number, string>();
    for (const l of lines) {
      const m = /^#(\d+)=/.exec(l);
      if (m) byId.set(Number(m[1]), l);
    }
    const parsePoints = (line: string): number[][] =>
      [...line.matchAll(/\(([-\d.]+),([-\d.]+),([-\d.]+)\)/g)].map((m) => [
        Number(m[1]),
        Number(m[2]),
        Number(m[3]),
      ]);
    const faceSets = lines.filter((l) => l.includes("=IFCTRIANGULATEDFACESET("));
    expect(faceSets.length).toBeGreaterThan(0);
    let closedCount = 0;
    for (const fs of faceSets) {
      const ptListId = Number(/=IFCTRIANGULATEDFACESET\(#(\d+),/.exec(fs)![1]);
      const closed = /=IFCTRIANGULATEDFACESET\(#\d+,\$,([^,]+),/.exec(fs)![1];
      if (closed === ".T.") closedCount++;
      const pts = parsePoints(byId.get(ptListId)!);
      const tris = [...fs.matchAll(/\((\d+),(\d+),(\d+)\)/g)].map((m) => [
        Number(m[1]) - 1,
        Number(m[2]) - 1,
        Number(m[3]) - 1,
      ]);
      // 6× signiertes Volumen Σ v0·(v1×v2): > 0 ⇒ Normalen zeigen nach aussen.
      let vol6 = 0;
      for (const [a, b, c] of tris) {
        const [ax, ay, az] = pts[a];
        const [bx, by, bz] = pts[b];
        const [cx, cy, cz] = pts[c];
        vol6 += ax * (by * cz - bz * cy) + ay * (bz * cx - bx * cz) + az * (bx * cy - by * cx);
      }
      expect(vol6).toBeGreaterThan(0);
    }
    // Beide Wände sind geschlossene Prisma-Körper (Fenster = Durchgangsloch,
    // Tür = umlaufende П-Kerbe) → Closed=.T. bei beiden.
    expect(closedCount).toBe(2);
  });
  it("GUIDs sind 22 Zeichen lang, nutzen den gültigen IFC-Zeichensatz und sind deterministisch", () => {
    const guid = ifcGuid("W1");
    expect(guid).toHaveLength(22);
    expect(guid).toMatch(/^[0-9A-Za-z_$]{22}$/);
    expect(ifcGuid("W1")).toBe(guid); // stabil über Re-Export
    expect(ifcGuid("W2")).not.toBe(guid); // unterschiedliche IDs → unterschiedliche GUIDs
  });
  it("georeferenziert: mit geoAnchor werden die ECHTEN LV95-Koordinaten geschrieben (lokal bearbeitet, weltweit lagerichtig)", () => {
    // Modell lokal nahe (0,0), aber geoAnchor sagt: Modell (0,0) = LV95
    // (2600000,1200000). Der Export muss die Profil-/Punkt-Koordinaten auf die
    // echten Landeskoordinaten (Millionenbereich) verschoben schreiben.
    const local = fixtureProject();
    const withoutAnchor = exportIfcSpf(local);
    // Ohne Bezug: lokale Koordinaten, KEINE Millionenwerte im Text.
    expect(withoutAnchor).not.toMatch(/26000\d\d\./);
    const geo: Project = {
      ...local,
      geoAnchor: { lv95: { e: 2600000, n: 1200000 }, model: { x: 0, y: 0 } },
    };
    const spf = exportIfcSpf(geo);
    // W1.start (0,0) -> LV95 (2600000,1200000); W2.end (5,4) -> (2600005,1200004).
    expect(spf).toContain("2600000.");
    expect(spf).toContain("1200000.");
    expect(spf).toContain("2600005.");
    // Struktur bleibt valide (keine dangling refs / Duplikate).
    const { defined, referenced, duplicates } = collectIds(spf);
    expect(duplicates).toEqual([]);
    expect([...referenced].filter((id) => !defined.has(id))).toEqual([]);
  });
  it("geoAnchor.height wird als IfcSite.RefElevation geschrieben (Vermessungspunkt-Höhe)", () => {
    const local = fixtureProject();
    const geo: Project = {
      ...local,
      geoAnchor: { lv95: { e: 2600000, n: 1200000 }, height: 683.5, model: { x: 0, y: 0 } },
    };
    const spf = exportIfcSpf(geo);
    // Die IFCSITE-Zeile trägt die reale Datumshöhe (RefElevation, 12. Attribut).
    const siteLine = spf.split("\n").find((l) => l.includes("=IFCSITE("));
    expect(siteLine).toBeDefined();
    expect(siteLine).toContain("683.5");
    // Ohne Höhe bleibt RefElevation leer ($) — kein 683.5 irgendwo.
    const noH = exportIfcSpf({
      ...local,
      geoAnchor: { lv95: { e: 2600000, n: 1200000 }, model: { x: 0, y: 0 } },
    });
    expect(noH).not.toContain("683.5");
  });
  it("leeres Projekt ⇒ valider Minimal-IFC (Project/Site/Building, kein Crash)", () => {
    const proj = fixtureProject();
    proj.walls = [];
    proj.ceilings = [];
    proj.openings = [];
    proj.stairs = [];
    proj.extrudedSolids = [];
    proj.drawingLevels = [];
    const spf = exportIfcSpf(proj);
    expect(spf).toContain("=IFCPROJECT(");
    expect(spf).toContain("=IFCSITE(");
    expect(spf).toContain("=IFCBUILDING(");
    const { defined, referenced, duplicates } = collectIds(spf);
    expect(duplicates).toEqual([]);
    expect([...referenced].filter((id) => !defined.has(id))).toEqual([]);
  });
 });
--- a/Show More
+++ b/Show More