Nordstern-3D: Live-Schnittebene mit schraffierten Schnittflaechen

Der 3D-Viewport kann das Modell jetzt live an einer vertikalen Ebene
aufschneiden (Overlay-Button 'Schnittebene', MVP: Ebene durch die
Modellmitte, Blick +Y):
- Globals um section_plane vec4 erweitert (xyz=Normale, w=-n*p; Enable
  in mode.y); MESH_/GRID_WGSL discarden Fragmente vor der Ebene
  (world_pos als neuer Varying) - Flaechen, Kanten, Grid, Highlight.
- section_fill.rs (neu): build_cut_caps ruft cut_section und trianguliert
  jedes (u,v)-Rechteck zurueck in Weltkoordinaten ([x,y,z,u,v]).
- CAP_WGSL: prozedurale 45-Grad-Diagonalschraffur aus (u,v) in Modell-
  Metern (fwidth-AA), Tinte auf Papier wie die 2D-Konvention; eigene
  cap_pipeline (CullMode::None, Depth-Bias Richtung Kamera gegen
  Z-Fighting), gezeichnet nach den Flaechen, nicht geclippt.
- web.rs cached walls/slabs; set_section_plane(active, p, n) aktualisiert
  Uniform + Caps; set_model baut Caps bei aktivem Schnitt neu.
- useWasm3dRenderer.setSectionPlane + Toggle in Wasm3DViewport.

Bekannte Luecken (dokumentiert): Oeffnungen im 3D-Solid nicht ausgespart
(cut_section spart aus -> Mismatch bei Schnitt durchs Fenster; wird mit
dem Boolean-Loecher-Slice geloest), nur vertikale Ebenen, ein globales
Muster (per-Bauteil = Stufe 2). cargo 56 Tests + naga-WGSL-Validierung,
222 vitest gruen, WASM neu gebaut (pkg3d gitignored).

.gitignore

@@ -11,7 +11,3 @@ 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

ARCHITECTURE.md

@@ -1,390 +1,452 @@
-# Architektur — Dossier (Desktop-CAAD)
+# Architektur — Standalone Browser-BIM (cad)
 
-> Stand: 2026-07-21 (grundlegend überarbeitet — siehe [STATUS.md](STATUS.md) für
-> die volle Bestandsaufnahme inkl. Mist-Liste, die diese Überarbeitung begründet).
-> Vision/Phasen (historisch, Tag-1-Stand): [ROADMAP.md](ROADMAP.md). Konventionen:
-> [CONVENTIONS.md](CONVENTIONS.md). Detail-Designs (teils ebenfalls veraltet,
-> siehe Hinweis in [docs/README.md](docs/README.md)): [docs/design/](docs/design/).
+> Stand: 2026-06-29
+> Vision, Phasen und Backlog: [ROADMAP.md](ROADMAP.md). Konventionen: [CONVENTIONS.md](CONVENTIONS.md).
+> Detail-Designs: [docs/design/elements.md](docs/design/elements.md) ·
+> [docs/design/plans-output.md](docs/design/plans-output.md) ·
+> [docs/design/resources-graphics.md](docs/design/resources-graphics.md).
 
-Dieses Dokument beschreibt, **wie** Dossier tatsächlich gebaut ist — nicht wie
-es am ersten Tag geplant war. Dossier ist die eigenständige Neuimplementierung
-des Rhino-Plugins [DOSSIER](https://git.openbureau.ch/karim/dossier): dieselbe
-Denkweise (Geschosse, Kategorie-Ebenen, mehrschichtige Bauteile,
-Prioritäts-Verschneidung), aber als **native Desktop-App** mit einem **eigenen
-typisierten Datenmodell in TypeScript** und **zwei eigenen Rust/WASM-Rendering-
-Engines** („Nordstern") statt Rhino-Dokument/IronPython.
+Dieses Dokument beschreibt, **wie** die Standalone-Browser-App gebaut wird und
+wie sie die Konzepte des DOSSIER-Rhino-Plugins in Browser-Äquivalente übersetzt.
+DOSSIER ist ein Rhino-8-Plugin (Python + React-WebView); `cad` ist die *eigen­
+ständige* Browser-Variante: kein Rhino-Document, kein `doc.Strings`, kein
+IronPython — stattdessen ein **eigenes typisiertes Datenmodell in TypeScript**,
+gerendert über **Three.js** (3D) und **SVG** (Plan), gespeichert als **JSON-Datei**.
 
-**Desktop-Rahmen (plattformabhängig, wegen WebGPU):** auf **macOS Tauri**
-(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**.
+Alle Bezeichner im Code sind **englisch** (Vectorworks-Terminologie); Prosa und
+UI-Texte sind deutsch. Einheiten intern in **Metern**.
 
 ---
 
 ## 0. Leitprinzip — ein Modell, viele Darstellungen
 
-Das semantische Gebäudemodell (`Project`) ist die **einzige Wahrheit**. Jede
-Sicht (3D, Grundriss, Schnitt, Ansicht) ist eine **reine Ableitung** daraus.
+Das semantische Gebäudemodell ist die **einzige Wahrheit**. Jede Sicht (3D,
+Grundriss, Schnitt, Ansicht) ist eine **reine Ableitung** (`derive`) daraus.
 Darstellung (Detailgrad, Stile, Schraffuren, Overrides) wird **beim Rendern**
-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.
+angewandt, nie in die Geometrie eingebacken.
 
 ```
                  ┌──────────────────────────────────────────┐
                  │   Project  (semantisches Modell, JSON)    │   ← einzige Wahrheit
-                 │   resources · types · drawingLevels ·     │
-                 │   layers · walls/doors/openings/stairs/…  │
+                 │   resources · types · designLevels ·      │
+                 │   layers · elements                       │
                  └──────────────┬───────────────────────────┘
                                 │  pure derive()
-        ┌───────────────────────┼────────────────────────────┬───────────────┐
-        ▼                       ▼                             ▼               ▼
-   3D-Viewport            2D-Plan (generatePlan)        3D-Live-Schnitt   Export
-   Viewport3D (three.js)  PlanView (SVG) · glPlan (GL2)  render3d/section  IFC/DXF/
-   ODER Wasm3DViewport    ODER render2d (Rust/WGSL)      (Rust, analytisch)PDF/STL
-   (Rust/wgpu, Default)
-        │                       │                             │               │
-        └────────── alle lesen dieselben joins/components/styles ─────────────┘
+        ┌───────────────────────┼────────────────────────────┐
+        ▼                       ▼                             ▼
+   Scene3D (Three.js)     PlanModel → SVG            SectionModel → SVG
+   buildScene()           generatePlan()             generateSection() (HLR)
+        │                       │                             │
+        └────────── beide 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 (IST-Zustand)
+## 1. Repo-Struktur (Ziel)
+
+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/       Project-Schema (types.ts, ~2500 LOC), joins.ts (Wand-Gehrung/
-               -Prio-Stösse), parametricWalls.ts, roomStamp.ts, terrain.ts,
-               geoRebase.ts, sampleProject.ts
-  geometry/    2D-Kernel (kernel2d.ts: offset/trim/fillet/split — LIVE, siehe
-               §3), ceiling/opening/roomArea/roomBoundary/stair/roof/column.ts,
-               polygonHoles.ts
-  commands/    Rhino-artiges Kommandosystem: types/registry/engine/parseInput.ts
-               + cmds/ (ein Modul je Kommando: wall, opening, stair, roof,
-               column, room, line/rect/circle/arc, move/mirror/copy/offset/
-               trim/join, extrude, import, terrain, measure, georef, …)
-  tools/       Interaktive Zeichenwerkzeuge, snapping.ts, transform.ts (Grips)
-  compute/     Compute-Boundary: leitet Ops (aktuell nur computeJoins) unter
-               Tauri via `invoke` an Rust weiter, sonst TS-Fallback
-  plan/        generatePlan.ts (2D-Ableitung), PlanView.tsx (SVG + Pan/Zoom/
-               Grips), glPlan/ (eigener WebGL2-Renderer), toSection.ts/
-               toElevation.ts (Schnitt/Ansicht-Ableitung), toWalls3d.ts,
-               toRenderScene.ts (Szene für Rust-render2d), wallMeshCut.ts
-  viewport/    Viewport3D.tsx (three.js, „Free") UND Wasm3DViewport.tsx
-               (Rust/wgpu „Nordstern", Default/editierbar), raycast3d.ts
-  section/     TOTER Code (OCCT-WASM-HLR-Spike, keine Aufrufer mehr) — Schnitt
-               läuft über render3d/section.rs, siehe §4.3
-  export/      exportIfc.ts (IFC4), exportDxf.ts/dxfWriter.ts, exportPdf.ts,
-               layoutPdf.ts (Mehrseiten-PDF pro Ordner), exportMesh.ts (STL/OBJ),
-               exportSchedule.ts (CSV-Bauteilliste), sceneToPrintSvg.ts
-  materials/   ambientcg.ts (Live-Suche ambientCG-API), library.ts (13
-               gebündelte Starter-Materialien), runtime.ts (PBR-Material aus
-               ComponentMaterial via three.js TextureLoader)
-  io/          DXF/DWG-Import, Swisstopo (swissBUILDINGS3D/-ALTI3D/SWISSIMAGE,
-               LV95↔WGS84), OSM-Overpass, .lin/.pat-Parser, projectFile.ts
-               (.obp Speichern/Laden, Tauri-Lock)
-  overrides/   Regelbasierte Override-Engine (Bedingung → Aktion)
-  state/       Eigener Store auf `useSyncExternalStore` (KEIN Zustand/Redux):
-               store.ts + Slices (project/history/selection/view/layout/site/
-               notify), appStore.ts komponiert sie
-  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`)
+  model/
+    types.ts            // Project, DesignLevel, LayerCategory, Element-Union  (existiert)
+    geometry.ts         // 2D/3D-Mathe ohne Kernel                            (existiert)
+    joins.ts            // Wand-Verschneidung (Gehrung; später Prio-T/X)      (existiert)
+    sampleProject.ts    // Demo-Haus                                          (existiert)
+    project.ts          // Factory, Defaults, Migrationen
+    selectors.ts        // abgeleitete Reads (visibleCodes, elementsOnLevel…)
+    ids.ts              // newId(prefix) — UUID-Erzeugung
+    elements/           // pro Bauteil ein Modul (Daten + Generierung)
+      wall.ts  opening.ts  slab.ts  stair.ts  roof.ts  structure.ts  space.ts
+  resources/
+    componentManager.ts hatchManager.ts lineManager.ts symbolLibrary.ts
+    overrides.ts        // regelbasierte Engine (Condition → Action)
+  store/
+    store.ts            // Zustand-Store: { project, ui }, Aktionen, Undo/Redo
+    persistence.ts      // Datei save/load (JSON), Autosave (IndexedDB)
+    history.ts          // Undo/Redo-Ring
+  plan/
+    generatePlan.ts     // Grundriss aus Footprint + Symbolik (existiert)
+    generateSection.ts  // Schnitt/Ansicht aus 3D-Projektion (HLR-Worker)
+    PlanView.tsx        // SVG-Renderer + Pan/Zoom/Grips (existiert)
+    primitives.ts       // Primitive-Union, SVG-Serializer, DXF/PDF-Export
+  viewport/
+    Viewport3D.tsx      // Three.js-Szene aus dem Modell (existiert)
+    scene.ts            // buildScene(project) → THREE.Group (Layer-Spiegel)
+    clip.ts             // Plan-/Schnitt-Clipping über THREE.Plane
+    camera.ts           // Kamera-Presets, Norden-Rotation
+  sheets/
+    layout.ts           // Sheet/Viewport-Datenmodell
+    SheetEditor.tsx     // Plansatz-Editor
+    exportPdf.ts        // Vektor-PDF (svg → pdf-lib / jsPDF)
+  workers/
+    geometry.worker.ts  // Booleans (Öffnungen) + HLR via Comlink
+  ui/
+    App.tsx Navigator panels…    // React-Oberfläche (heute in App.tsx, wird gesplittet)
 ```
 
-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 (unverändert gegenüber der Vision)
+### 2.1 Zwei unabhängige Achsen (DOSSIER-Modell, im Spike umgesetzt)
 
-1. **Zeichnungsebenen** (`DrawingLevel`) — Geschoss (`kind:"floor"`,
-   `floorHeight`/`cutHeight`/`baseElevation`), Schnitt/Ansicht
-   (`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 …`).
+DOSSIER trennt zwei orthogonale Konzepte, persistiert als zwei getrennte
+JSON-Bäume (`dossier_zeichnungsebenen`, `dossier_ebenen`). Wir übernehmen das
+1:1 in `types.ts` (existiert bereits als `drawingLevels` + `layers`):
 
-### 2.2 Elemente — typisierte Arrays statt `Element[]`-Union
+1. **Zeichnungsebenen** (`DesignLevel` / `DrawingLevel`) — die obersten
+   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 …`
 
-Anders als ursprünglich geplant hält `Project` (`src/model/types.ts:2095`)
-**pro Bauteiltyp ein eigenes (meist optionales) Array**:
+Ein **Element** kennt sein **Geschoss** (`floorId`) *und* seine **Ebene**
+(`categoryCode`). Sichtbarkeit ergibt sich aus dem Schnitt (Geschoss `geschoss × code`
+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 Project {
-  walls: Wall[];
-  ceilings?: Ceiling[];
-  roofs?: Roof[];
-  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?
+interface Resources {
+  lineStyles: LineStyle[];   // Line Manager:  { id, name, weight(mm), color, dash:number[] }
+  hatches:    Hatch[];       // Hatch Manager: { id, name, pattern, scale, angle, lineStyleId }
+  components: Component[];    // Component Manager (= DOSSIER-Material erweitert):
+                             //   { id, name, hatchId, color3d, texture3d?, joinPriority }
 }
 ```
 
-Ein `Element`-Typalias existiert noch (`kind:"door"|"window"` etc.), wird aber
-nirgends im Code referenziert — Selektion/Element-Baum arbeiten direkt auf den
-typisierten Arrays. `doors`/`openings` sind eine **bekannte, noch nicht
-konsolidierte Doppelspur** (PENDENZEN.md).
+`joinPriority` ist DOSSIERs `_MATERIAL_PRIO` (Beton 800 … Putz 100) als
+**Daten** statt Hardcode — steuert die Prioritäts-T-Verschneidung (Risiko #1).
 
-### 2.3 Ressourcen & Aufbauten (unverändert gegenüber der Vision)
+### 2.3 Aufbauten (mehrschichtige Typen)
 
 ```ts
-interface Resources { lineStyles: LineStyle[]; hatches: Hatch[]; components: Component[]; }
 interface WallType { id; name; layers: { componentId; thickness }[]; }
+interface SlabType { id; name; layers: { componentId; thickness }[]; }
 ```
 
-`joinPriority` sitzt am `Component` (Daten statt Hardcode) und steuert die
-Prioritäts-T-/X-Verschneidung — **fertig implementiert**, inklusive Rust-Port
-für den 3D-Live-Schnitt (`section_boolean.rs` = Port von
-`toSection.ts::subtractDominantBands`).
+Schichtdicke liegt am Layer, **Priorität am Component** (so muss man Prio nur
+einmal pflegen). 3D und Plan lesen dieselben `layers[]`.
 
-### 2.4 Layouts / Ausschnitte
+### 2.4 Elemente
 
-`ViewSnapshot` (Kamera/Massstab/Detailgrad/Sichtbarkeiten/Override-Preset) in
-`ViewSnapshotFolder`-Bäumen; `Layout` (Papierformat, mehrere
-`LayoutViewport`s, freie `LayoutAnnotation`s, optionale `MasterLayout`-Vererbung)
-in `LayoutFolder`-Bäumen. Beide gehören ins Dokument (nicht LocalStorage).
+Diskriminierte Union `Element` (heute `Wall | Door`), erweitert um
+`Window | Slab | Stair | Roof | Column | Beam | Space | Draw2d`. Jedes Element:
+`{ id, type, floorId, categoryCode, ... }`. Gehostete Elemente (Tür/Fenster)
+tragen `hostWallId` statt `floorId` (Geschoss ergibt sich aus der Wand). Volle
+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 — eigener `useSyncExternalStore`, nicht Zustand
+### 3.1 Store — Zustand
 
-Entgegen der ursprünglichen Empfehlung (Zustand-Library) wurde ein
-**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)`.
+Heute: `useState<Project>` in `App.tsx`, immutabel via `setProject`. Das skaliert
+nicht für Werkzeuge + Undo. Migration auf **Zustand** (ROADMAP §4):
 
-**Nicht umgesetzt** (geplant in `docs/design/state-architecture.md`): die
-Extraktion von View-Routing nach `src/views/` und Kontextmenü-Aufbau nach
-`src/menus/` — beide Ordner existieren nicht, diese Logik liegt weiterhin
-inline in `App.tsx` (7.130 Zeilen). Siehe STATUS.md §4.3.
+```ts
+interface AppState {
+  project: Project;          // das Dokument
+  ui: {                      // flüchtig, NICHT persistiert/undobar
+    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;
+}
+```
 
-### 3.2 Persistenz
+**Trennung Modell ↔ UI** ist hart: nur `project` ist undobar und wird gespeichert.
+`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).
 
-- **Datei:** eigenes `.obp`-Format (`src/io/projectFile.ts`), unter Tauri über
-  native Speichern/Öffnen-Dialoge (`plugin-fs`/`plugin-dialog`), im Browser
-  Blob-Fallback. Ältere `.json`-Projekte bleiben ladbar.
-  OS-Level-Exklusiv-Lock (`fs4`-Crate, `src-tauri/src/lock.rs`) verhindert
-  Doppelöffnen desselben Projekts.
-- **Compute-Boundary:** `src/compute/index.ts` leitet einzelne Operationen
-  (aktuell nur `computeJoins`) unter Tauri via `invoke` an eine native Rust-
-  Implementierung weiter; im Browser bzw. für nicht migrierte Ops (Room-
-  Detection, DWG-Parsing) läuft die TS-Implementierung.
+### 3.2 Persistenz — JSON-Datei statt `doc.Strings`
+
+DOSSIER speichert *alles* in `doc.Strings` (Key-Value am Rhino-Document) +
+globale Presets als JSON-Dateien im User-Home. Browser-Äquivalent:
+
+| DOSSIER | Browser (cad) |
+|---|---|
+| `doc.Strings.SetString(key, json)` | Feld im `Project`-Objekt (ein JSON-Baum) |
+| `.3dm`-Datei mit eingebetteten Strings | **`.cad.json`-Datei** via File System Access API |
+| 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
 
-Eigener History-Ring im `projectSlice` (kein DOSSIER-Sticky-Bus, kein
-Cache-Stale-Problem, da alle Sichten pure Ableitungen sind).
+DOSSIER überlässt Undo Rhino (und hat dadurch Cache-Stale-Bugs, Schwachstelle
+#4.3). Wir besitzen das Dokument selbst → **eigener History-Ring**:
+
+```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 Zwei 3D-Viewports
+### 4.1 Three.js-Szene spiegelt den Ebenen-Baum
 
-- **`Viewport3D.tsx`** — three.js, die „Free"-Stufe.
-- **`Wasm3DViewport.tsx`** — Rust/wgpu, „Nordstern", editierbar, **Default**.
-  Ein Settings-Schalter wählt die Engine; WebGL2/three.js nur noch als
-  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:
+DOSSIER baut in Rhino eine **Layer-Hierarchie** `Zeichnungsebene → CODE_Name-Sublayer`
+(`layer_builder.build_layers`) und hängt jedes Objekt an den passenden Sublayer.
+Browser-Spiegel: ein **`THREE.Group`-Baum** mit identischer Struktur, gebaut aus
+dem Modell (nicht persistiert — reine Ableitung):
 
 ```
-App.tsx (section3dCutId/section3dPlane)
-  → Wasm3DViewport.tsx (section3d-Prop → setSectionPlane)
-  → src-tauri/render3d/src/{section.rs, section_boolean.rs, section_fill.rs}
+scene
+└─ levelGroup[floorId]                 (y-Offset = baseElevation)   ← Geschoss
+   └─ categoryGroup[categoryCode]      (userData.code)              ← Ebene
+      └─ element meshes                (userData.elementId)
 ```
 
-`section_boolean.rs` ist ein 1:1-Port von `toSection.ts::subtractDominantBands`
-— 2D-Plan-Schnitt und 3D-Live-Schnitt nutzen dieselbe Prioritäts-Logik und
-stimmen dadurch exakt überein. Kein Worker, kein Comlink (beides war geplant,
-existiert nirgends im Projekt) — läuft synchron GPU-seitig.
+```ts
+// scene.ts
+function buildScene(project: Project, vis: VisibilityState): THREE.Group
+function syncScene(root: THREE.Group, project, vis)   // diff statt full rebuild (Perf)
+```
 
-### 4.4 Öffnungen als Löcher (kein Mesh-Boolean)
+- **Sichtbarkeit:** `categoryGroup.visible = vis.codes.has(code)` und
+  `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.
 
-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.
+### 4.2 Grundriss = Clipping-Ebene + symbolische Generierung
 
-### 4.5 Materialien
+DOSSIER zeigt den Grundriss eines Geschosses, indem es eine **Clipping-Plane** auf
+`okff + schnitthöhe` legt, Normale −Z (`layer_builder.update_clipping_plane`).
+Zwei Browser-Pfade — **beide nötig** (ROADMAP §3):
 
-`materials/library.ts` (13 gebündelte PBR-Starter, ambientCG CC0) +
-`materials/ambientcg.ts` (Live-Suche der kompletten ambientCG-Bibliothek,
-1K/2K/4K-Auflösungswahl, On-Demand-Download via `jszip`, Proxy wegen CORS) →
-`materials/runtime.ts` baut daraus gecachte `THREE.MeshStandardMaterial`s mit
-physisch korrekter Kachelgrösse (UV in Weltmetern).
+1. **3D-Viewport im Plan-Modus:** `THREE.Plane(normal=(0,0,-1), constant=cutZ)` über
+   `renderer.clippingPlanes` + `material.clippingPlanes`. `clip.ts` setzt die Ebene
+   pro aktivem Geschoss (`cutZ = baseElevation + cutHeight`), Kamera orthografisch
+   von oben. So sieht man den **echten geschnittenen Volumenkörper**.
+2. **Symbolischer SVG-Grundriss** (der Hauptweg, schnell + sauber): `generatePlan.ts`
+   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
 
-Dock-/Floating-Panel-System (`src/panels/`: Dock, FloatingPanel, TabStrip,
-Registry) mit eingebauten Panels: Tools, Attributes, ObjectInfo,
-DrawingLevels, Layers, Site (Kontext/Terrain-Import), RoomBalance
-(SIA-416-CSV), Elements (Bauteilbaum), ViewSnapshots, Layouts.
+DOSSIER ist eine Sammlung **getrennter WebView-Panels** (EBENEN, ELEMENTE,
+GESTALTUNG, OBERLEISTE, MASSSTAB, AUSSCHNITTE, DIMENSIONEN, LAYOUTS, OVERRIDES),
+die über die Python-Bridge + `sc.sticky` kommunizieren. Im Browser ist alles
+**eine SPA** mit einem geteilten Store — die Panels werden zu Docking-Bereichen.
 
-Der **Resource Manager läuft bewusst NICHT als Dock-Panel**, sondern als
-eigenständiges (unter Tauri natives) Fenster — ebenso Settings,
-DrawingLevels-Detaileditor, LayerSettings und ContextImport
-(`src/native/*Window.ts` + `*WindowApp.tsx`), jeweils mit
-`isTauriRuntime()`-Gate und ohne separate Browser-Variante (im Browser bleibt
-die entsprechende In-App-Overlay-Variante aktiv, wo vorhanden).
+```
+┌─────────────────────────────────────────────────────────────────────┐
+│ TopBar      Werkzeuge · Ansichtstyp · Massstab · Snaps · Save/Load   │  ≙ OBERLEISTE+MASSSTAB
+├──────────────┬──────────────────────────────────────┬───────────────┤
+│ Navigator    │  Viewport (Three.js  oder  SVG-Plan)  │ Inspector     │
+│ ┌──────────┐ │  ┌────────────────────────────────┐  │ ┌───────────┐ │
+│ │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
+```
 
-**Werkzeug-System:** `Tool`-Interface (`src/tools/types.ts`) für Zeichenwerkzeuge
-mit Snap-Engine; daneben das umfangreichere **Kommandosystem** (`src/commands/`)
-für Rhino-artige getippte Eingabe (`5,3`/`r5,3`/`5<45`, Tab-Feld-Zyklus in
-`CommandLine.tsx`) — beide koexistieren, decken unterschiedliche
-Interaktionsstile ab.
+**Komponenten-Map** (heute alles in `App.tsx`; wird gesplittet):
 
----
-
-## 6. Rhino → Dossier — Mapping-Tabelle (Kernkonzepte)
-
-| DOSSIER (Rhino-Plugin) | Dossier (Tauri) | Anmerkung |
+| Bereich | DOSSIER-Panel | cad-Komponente |
 |---|---|---|
-| Rhino `RhinoDoc` | `Project` (TS-Objekt im eigenen Store) | einzige Wahrheit |
-| `doc.Strings[key]=json` | Feld im `Project`-JSON | persistiert in `.obp` |
-| `.3dm`-Datei | **`.obp`**-Datei (Tauri `plugin-fs`) | + Blob-Fallback im Browser |
-| `sc.sticky` (cross-modul Bus) | eigener `useSyncExternalStore`-Store | kein Polling |
-| Rhino Layer-Tabelle | `LayerCategory[]`-Baum, Sichtbarkeit als `.visible`-Flag | pro Renderer umgesetzt |
-| Clipping-Plane (`AddClippingPlane`) | `render3d::section.rs` (analytisch, Rechteck-Subtraktion) | KEIN HLR |
-| `HLRBRep` | — (ungenutzt; OCCT-Spike ist toter Code) | ersetzt durch obiges |
-| `Rhino.Geometry.Brep`-Booleans | `trucksolid::boolean_mesh` (csgrs) | existiert, nicht an Wände angeschlossen |
-| Rhino-Grips + DisplayConduit | Pointer-Events + Grip-Overlay (2D vollständig, 3D nur Basis, kein Snap) | siehe STATUS.md §4.7 |
-| Swisstopo via .NET HttpClient | `fetch()` (CORS-offen) | radiusgenau zugeschnitten (nicht ganze STAC-Kachel) |
-| IronPython-Laufzeit-Risiken | entfällt | TS/Rust |
+| Zeichnungsebenen-Liste | EBENEN (oben) | `Navigator/DrawingLevels.tsx` |
+| 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.
 
 ---
 
-## 7. Was übernommen wurde — und was bewusst anders lief
+## 6. Rhino → Browser — Mapping-Tabelle
 
-**Übernommen (Prinzipien, bewährt):**
-- Zwei-Achsen-Dokumentmodell, Layer-Codes 1:1, Component/Hatch/Line-Manager
-  mit `joinPriority`, LoD (grob/mittel/fein), regelbasierte Overrides,
-  Ausschnitte, SIA-416-Räume, Norden-Rotation.
-- Pure-Ableitungs-Architektur (kein Cache-Stale, kein Sticky-Bus).
+| DOSSIER (Rhino-Plugin) | cad (Standalone-Browser) | Anmerkung |
+|---|---|---|
+| **Rhino `RhinoDoc`** | `Project` (TS-Objekt im Store) | einzige Wahrheit |
+| **`doc.Strings[key]=json`** | Feld im `Project`-JSON | persistiert in `.cad.json` |
+| **`.3dm`-Datei** | **`.cad.json`** via File System Access API | + IndexedDB-Autosave |
+| **Globale Presets (~/Library/*.json)** | **LocalStorage** + Export/Import | cross-Projekt |
+| **`sc.sticky` (cross-modul Bus)** | **Zustand-Store** (reaktiv) | kein Polling, kein None-Bug |
+| **`panel_base.BaseBridge` / WebView-IPC** | direkte React-Props/Store | keine `document.title`-Hacks |
+| **`document.title="RHINOMSG::"` Polling** | entfällt | SPA, kein WebView |
+| **Eto.Forms Satelliten-Fenster** | React-Modal/Drawer | z.B. Ausschnitt-Settings |
+| **Rhino Layer-Tabelle (Sublayer-Baum)** | `LayerCategory[]`-Baum + `THREE.Group`-Spiegel | `scene.ts` |
+| **`layer_builder.build_layers`** | `buildScene` (Ableitung) | Gruppen statt Layer |
+| **`layer.PlotWeight`** | `LineStyle.weight` (mm) → SVG `stroke-width` | massstabsabh. (§plans) |
+| **`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) | — |
 
-**Anders gelaufen als geplant (siehe STATUS.md §5 für die volle Tabelle):**
-- Eigene Rust/WASM-Rendering-Engines statt Three.js/OpenCascade.js/web-ifc.
-- Typisierte Arrays pro Bauteiltyp statt `Element[]`-Union.
-- Eigener Store statt Zustand-Library.
-- Analytische Rust-Schnitt-Pipeline statt HLR/Worker/Comlink.
-- App.tsx wurde **nicht** wie geplant auf eine dünne Shell reduziert
-  (`src/views/`/`src/menus/` wurden nie angelegt) — bekannter, unbereinigter
-  Punkt, siehe STATUS.md §4.3.
+---
 
-**Anti-Over-Engineering (weiterhin gültig):** keine Abstraktion ohne konkretes
-Problem; erst lesen, dann editieren; Geometrie nie „nebenbei" refactoren.
+## 7. Was wir von DOSSIER übernehmen — und was nicht
+
+**Übernehmen (bewährte Konzepte):**
+- Zwei-Achsen-Dokumentmodell (Zeichnungsebenen × Ebenen).
+- Layer-Codes/Farben/lw 1:1 (`DEFAULT_LAYER_SCHEMA`).
+- Component/Hatch/Line-Manager mit id-Verweisen + `joinPriority`.
+- Ansichtstypen = Kamera + optionaler Schnitt (vereinheitlicht).
+- 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):**
+- **Kein Sticky-Bus** → ein reaktiver Store (vermeidet DOSSIER #4.4/#4.5/#4.6).
+- **Kein Monolith** → Bauteil-Module statt 7244-LOC-`elemente.py` (#4.1).
+- **Pure Ableitungen** statt mutierter Doc-Objekte → kein Cache-Stale (#4.3),
+  kein Undo/Redo-Loch.
+- **Versioniertes Datei-Schema** statt UserString-Sticky-Migration.
+- **Persistenz im Project-JSON** statt verteilt über `doc.Strings`.
+
+**Anti-Over-Engineering (aus DOSSIER-CONVENTIONS.md übernommen):** keine Abstraktion
+ohne konkretes Problem; kein `try/catch: {}` als Bug-Versteck; erst grep/lesen,
+dann editieren; Wand-Geometrie nie „nebenbei" refactoren.
 
 ---
 
 ## 8. Reihenfolge bei Code-Arbeit
 
-1. **STATUS.md** (aktueller Ist-Zustand) + dieses Dokument lesen.
-2. **Das betroffene Modul** lesen (nicht raten) — bei Zweifel: welcher der
-   mehreren Renderer/Pfade ist gerade aktiv (§4.1/§4.2)?
-3. **Erst danach editieren**; `Project` immer immutabel via den Store ändern.
-4. **Verifizieren:** `npx tsc -b`, `npm test` (Vitest), `cargo test` in den
-   betroffenen Crates, bei Rust-Änderungen `npm run build:engine{,3d}` (WASM
-   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. **Dieses Dokument + das relevante Detail-Design** (elements/plans-output/
+   resources-graphics) lesen.
+2. **Dann das betroffene Modul** lesen (nicht raten).
+3. **Erst danach editieren**; `Project` immer immutabel via `store.apply()` ändern.
+4. **Verifizieren:** `npx tsc -b`, `npm run build`, Screenshot via
+   `node scripts/probe.mjs` — Geometrie visuell prüfen.
+5. **Dieses Dokument aktuell halten**, wenn sich Patterns/Mapping ändern.

CONVENTIONS.md

@@ -1,8 +1,6 @@
-# Projekt-Konventionen — Dossier
+# Projekt-Konventionen — Browser-BIM (cad)
 
-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.
+Siehe [ROADMAP.md](ROADMAP.md) für Vision, Architektur und Phasen.
 
 ## Code-Konventionen (verbindlich)
 
@@ -17,26 +15,16 @@ Siehe [ARCHITECTURE.md](ARCHITECTURE.md) für die aktuelle Architektur,
   CCW-Wicklung zeigt `+n` nach innen. Schichten werden außen (−T/2) → innen (+T/2)
   gestapelt.
 
-## Code-Struktur (kein God-Component — bisher nur teilweise erreicht)
+## Code-Struktur (kein God-Component)
 
-- **Ziel:** `App.tsx` bleibt ein dünner Shell (Store-Provider, Oberleiste,
-  Docks+View-Router, Statusleiste, Floating-Panels, Ressourcen-Overlay) — keine
-  Geschäftslogik darin. **Realität (Stand 2026-07-21):** `App.tsx` ist mit
-  ~7.100 Zeilen die grösste Datei des Projekts und enthält weiterhin
-  View-Umschaltung und Kontextmenü-Aufbau inline — die geplante Auslagerung
-  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.
+- **`App.tsx` bleibt ein dünner Shell** (Store-Provider, Oberleiste, Docks+View-Router,
+  Statusleiste, Floating-Panels, Ressourcen-Overlay) — keine Geschäftslogik darin.
+- **Globaler Zustand in einem Store** (`src/state/`, Slices: project/selection/view/layout).
+  Komponenten lesen Zustand über Store-Hooks statt Prop-Drilling.
+- **Features als eigene Module:** `src/views/` (View-Router-Teile), `src/editors/`
+  (Inline-Editoren), `src/menus/` (Kontextmenü-Builder), `src/panels/`, `src/ui/`.
 - Ziel: modular + parallel bearbeitbar (verschiedene Features ≠ dieselbe Datei).
+  Siehe `docs/design/state-architecture.md`.
 
 ## UI-Konventionen
 
@@ -69,10 +57,8 @@ Rendern angewandt, nie in die Geometrie eingebacken.
 
 ## Arbeitsweise (für Beiträge)
 
-- Substanzielle, mehrstufige Arbeit schrittweise in isolierten Schritten angehen.
+- Substanzielle, mehrstufige Arbeit an **Subagenten** delegieren, wo möglich.
 - Ä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 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).
+- Dev-Server läuft via `npm run dev` (Vite, Port 5173).

HANDOVER.md

@@ -1,200 +1,7 @@
-> **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:
@@ -239,17 +46,44 @@ Die Arbeit wurde unerwartet unterbrochen — mehrere Tasks liefen parallel. Dies
 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 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.
+- **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.
 - **NICHT ANFASSEN (fremde WIP):** `.gitignore`, `public/assets/materials/manifest.json`, `src/materials/library.ts`, `scripts/fetch-materials.mjs` — bleiben dauerhaft dirty, nie stagen.
-- **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).
+- **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).
+- **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`).
 
-## Backlog & Rückfragen → `PENDENZEN.md`
-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.
+## IN FLIGHT bei Session-Ende (PRÜFEN!)
+- **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).
+
+## 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.

LICENSE

@@ -1,661 +0,0 @@
-                    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/>.

PENDENZEN.md

@@ -1,300 +0,0 @@
-# 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`

PORT_PLAN.md

@@ -1,124 +0,0 @@
-# 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.

README.md

@@ -1,17 +1,16 @@
-# Dossier
+# DOSSIER Standalone
 
-Open-Source-CAAD (Computer Aided Architecture Design). Modelliert ein Gebäude
-aus semantischen Bauteilen und zieht daraus saubere, normgerechte 2D-Pläne —
-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).
+Eigenständiges BIM-Werkzeug für Wohnbau. Modelliert ein Wohnhaus aus
+semantischen Bauteilen und zieht daraus saubere, normgerechte 2D-Pläne —
+ohne Revit.
 
-Das ist die eigenständige Neuimplementierung des Rhino-Plugins
-[DOSSIER](https://git.openbureau.ch/karim/dossier): dieselbe Denkweise
-(Geschosse, Kategorie-Ebenen, mehrschichtige Bauteile, Prioritäts-
-Verschneidung), aber mit eigenem Datenmodell + eigener Rendering-Engine
-(Rust/WASM/WebGPU, intern „Nordstern" genannt) statt Rhino-Aufsatz.
+Das ist die eigenständige Standalone-Variante des Rhino-Plugins
+[DOSSIER](https://git.kgva.ch/karim/DOSSIER): dieselbe Denkweise (Geschosse,
+Kategorie-Ebenen, mehrschichtige Bauteile, Prioritäts-Verschneidung), aber als
+React/Three.js-App in einer Electron-Desktop-Shell statt als Rhino-Aufsatz.
+Kein Browser-Tab-Produkt: eigenes Fenster, eigene Rendering-Engine
+(Rust/WASM/WebGPU), gebaut für flüssiges CAD-Arbeiten statt für den Webview
+kleinster gemeinsamer Nenner.
 
 ## Grundgedanke
 
@@ -23,124 +22,117 @@ 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. Schnitte und Ansichten laufen
-über eine eigene, analytische Rust-Pipeline (kein Hidden-Line-Removal nötig,
-siehe [ARCHITECTURE.md](ARCHITECTURE.md) §4.3) und sind seit Juli live im
-3D-Viewport verdrahtet, nicht nur ein Spike.
+echten mm-Stiftstärken statt Bildschirm-Hairlines — kein zweites Rendering.
+Schnitte und Ansichten brauchen den zweiten Weg — echte 3D-Projektion mit
+verdeckten Kanten (HLR) —, dessen Machbarkeit per Spike bewiesen, aber noch
+nicht ans UI angebunden ist.
 
 ## Stand heute
 
-Aus dem ursprünglichen Risiko-Spike ist binnen weniger Wochen ein
-**funktionsreiches Desktop-BIM-Tool** geworden: eigenes semantisches
-Gebäudemodell, zwei eigene Rust/WASM-Rendering-Engines, IFC/DXF/PDF/STL/OBJ-
-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)**.
+Ehrlich eingeordnet: aus dem Risiko-Spike ist ein **benutzbares 2D-CAD mit
+abgeleiteter 3D-Sicht, Vektor-PDF/DXF-Export und einer parametrischen
+Wand-Engine** geworden. Der einfachere Teil steht und ist per Screenshot/Probe
+verifiziert; die schwierigen BIM-Kernrisiken sind bewusst noch offen.
 
-**Funktioniert (Auszug — volle Liste in STATUS.md §3):**
-- Semantisches Modell mit **mehrschichtigen Wänden**, L-Eck-Gehrung **und**
-  Prioritäts-T-/X-Stössen (`joinPriority` am Component) — konsistent in
-  Grundriss, 3D-Viewport und 3D-Live-Schnitt.
-- **Parametrische Wände**, Decken, Treppen (gerade/L/Wendel), Dächer
-  (Flach/Pult/Sattel/Walm/Mansarde/Zelt), Stützen, SIA-416-Räume mit
-  automatischer Bilanz + CSV-Export.
-- **Türen & Fenster** gehostet in Wänden, mit Rahmen/Zarge/Kämpfer/Oberlicht,
-  Detailgrad grob/mittel/fein, echte Rechteck-Löcher im 3D-Wandkörper.
-- Rhino-artiges **Kommandosystem** mit getippten Koordinaten (`5,3` · `r5,3` ·
-  `5<45`) und Tab-Feld-Zyklus; Snapping, Grips, Trim/Split/Join, 2D-Booleans.
-- **Live 2D↔3D-Schnitt**: eine Schnittebene im 3D-Viewport folgt derselben
-  Prioritäts-Logik wie der 2D-Plan-Schnitt (Rust-Port, keine Diskrepanz).
-- **Vektor-Export:** PDF (Einzel- **und Mehrseiten-Layouts**), DXF, **IFC4**
-  (mit echten Fenster-/Tür-Löchern), STL/OBJ, CSV-Bauteilliste.
-- **Materialbibliothek**: 13 gebündelte PBR-Starter **plus** Live-Suche der
-  kompletten ambientCG-Bibliothek (1K/2K/4K, On-Demand-Download).
-- **Layouts/Plansätze** mit mehreren Viewports pro Blatt, Ausschnitte
-  (View-Snapshots), Kamera-Presets, Norden-Rotation.
-- **Import:** DXF/DWG, Swisstopo (swissBUILDINGS3D/-ALTI3D/SWISSIMAGE,
-  radiusgenau zugeschnitten), OSM-Kontextimport, `.lin`/`.pat`.
-- **Native Desktop-Integration** (Tauri): eigene randlose Fenster, native
-  Speichern/Öffnen-Dialoge, eigenes `.obp`-Dateiformat mit OS-Level-Lock gegen
-  Doppelöffnen, mehrere native Zusatzfenster (Resources, Settings, …).
-- **Resource Manager** (Component/Hatch/Line/Typ-Editoren), regelbasierte
-  Overrides, Panel-System (dockbar/floatend), i18n (de/en).
+**Funktioniert:**
+- Semantisches Modell mit **mehrschichtigen Wänden** und automatischer
+  **L-Ecken-Gehrung** (`computeJoins`); dieselbe Logik speist Plan *und* 3D.
+- **Parametrische Wände** (`ParametricWall`-Regelwerke: Grid/Modul/Sequenz/
+  Referenzlinie/bedingte Dicke) lösen sich zu konkreten `Wall`-Objekten auf,
+  statt jede Wand einzeln von Hand zu ziehen.
+- **Dokumentmodell wie in DOSSIER:** Zeichnungsebenen (Geschosse + Schnitte/
+  Ansichten/Zeichnungen) × Kategorie-Ebenen (Code-Baum 1:1, `20 Wände`, `30 Decken` …).
+- **Zeichnen & Editieren** im Grundriss: Wand, Linie, Polylinie, Rechteck, Kreis,
+  Öffnungen, Treppen, Decken, Raumstempel; Snapping (Endpunkt/Mittelpunkt/
+  Schnittpunkt/Lot/Raster/Ortho), Grips, Move/Copy/Offset, Spiegeln/Drehen/Array,
+  Trim/Split/Join.
+- **Rhino-artiges Befehlssystem** mit getippten Koordinaten (`5,3` · `r5,3` ·
+  `5<45`) und Tab-Feld-Zyklus (Länge → Winkel …).
+- **Vektor-Export:** PDF (A4/A3, Titelblock, echte mm-Stiftstärken nach ISO-Pen-
+  Steps, keine Rasterbilder) und DXF — beide aus derselben `Plan`-Struktur wie
+  der Bildschirm.
+- **PBR-Material-Bibliothek** (ambientCG-Import, `manifest.json`) für die
+  3D-Ansicht.
+- **Resource Manager** (Component / Hatch / Line) — alles per id referenziert,
+  zentral änderbar.
+- **Panel-System** (dockbar, stapelbar, floatend), Top-Bar + Statusleiste
+  (echter Maßstab 1:N, Cursor X/Y), eigenes Kontextmenü, **i18n** (de/en).
+- **Import:** DXF/DWG (Konturen/Mesh) → Terrain-TIN, Swisstopo/LV95-Geokontext,
+  OSM-Kontextimport; `.lin`/`.pat` für Linien/Schraffuren.
 
-**Bewusst noch offen** (Details + volle Liste: STATUS.md §4.7):
-- **Echtes Mesh-Boolean für Öffnungen** — funktioniert heute über achsparallele
-  Rechteck-Löcher; ein generisches CSG-Boolean existiert bereits
-  (`trucksolid`/`csgrs`), ist aber nicht an die Wand-Pipeline angeschlossen.
-- **3D-Griffsystem**: Feld-Controller (Tab-Zyklus) und Snapping fehlen für
-  3D-Grip-Drag (im 2D vollständig vorhanden).
-- **DWG/DXF-Domänenimport** (Entitäten → echte Wände/Öffnungen) — Lesen
-  funktioniert, das Mapping auf das Modell ist unbegonnen; DWG-Schreiben fehlt.
-- **`make2D`**-Kommando (3D-Ansicht → flacher 2D-Plan mit Füllungen).
-- Bekannte, noch nicht bereinigte Doppelspur `Door[]`/`Opening[]` im Modell.
+**Bewusst noch offen** (die eigentlich harten Teile):
+- Echte **3D-Booleans** für Öffnungen — Türen/Fenster sind im Plan eine Lücke,
+  noch kein geschnittenes Volumen.
+- **HLR** (verdeckte Kanten) für Schnitte und Ansichten: Machbarkeit per
+  OCCT-WASM-Spike bewiesen (`docs/welle-c-hlr-spike/`, `src/section/hlr.ts`),
+  aber noch nicht ans UI/Dokumentmodell verdrahtet — Views sind noch Stubs.
+- **Prioritäts-T-/X-Stöße** mehrschichtiger Wände (Beton läuft durch, Putz
+  verbindet seitlich) — das berüchtigte Risiko #1.
+- **Multi-Page-Layouts/Ausschnitte** (mehrere Viewports pro Blatt) — PDF-Export
+  ist noch single-sheet.
+
+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 | **Tauri** auf macOS (WKWebView+WebGPU) · **Electron/Chromium** auf Linux (WebKitGTK kann kein WebGPU) — beide randlos, eigene Titelleiste, gemeinsame React-App |
+| Shell | Electron (eigenes randloses App-Fenster, kein Browser-Tab) |
 | Frontend | React + TypeScript + Vite |
-| 3D | eigener Rust/WASM/WebGPU-Renderer „Nordstern" (`render3d`, Default), Three.js als leichtgewichtiger Zweitpfad |
-| 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`); ein Rust-Port (`src-tauri/kernel2d`) existiert nur als Paritätstest, läuft nicht produktiv |
-| CSG/Extrusion | `trucksolid`-Crate (`truck` + `csgrs`), fürs Extrude-Kommando |
-| Export | eigener IFC4-Writer, `jspdf`/`svg2pdf.js` (Vektor-PDF), eigener DXF-Writer, STL/OBJ |
+| 3D | Three.js, plus eigener nativer Rust/WASM/WebGPU-Renderer (`render3d`) |
+| 2D-Plan | eigener SVG-Renderer, plus eigener nativer Rust/WASM/WebGPU-Renderer (`render2d`) |
+| Geometrie | eigener 2D-Kernel (`src/geometry/kernel2d.ts`), `delaunator` fürs Terrain |
+| Export | `jspdf`/`svg2pdf.js` (Vektor-PDF), eigener DXF-Writer |
 | Import | `dxf-parser`, `@mlightcad/libredwg-web` (DWG), eigene `.lin`/`.pat`-Parser |
-| Materialien | `jszip` (ambientCG-Zip-Entpacken), `three.js` `TextureLoader` |
+| Schnitt/HLR-Spike | `opencascade.js` (OCCT-WASM) — isoliert, noch nicht verdrahtet |
 
-`opencascade.js` steht noch als Dependency in `package.json`, wird aber nur
-noch von totem Code (`src/section/hlr.ts`, superseded durch die Rust-
-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.
+Geplant, aber noch nicht eingezogen: `rhino3dm` (NURBS / `.3dm`), web-ifc (IFC),
+Manifold (exakte 3D-Booleans). OCCT-WASM ist für HLR bereits als Spike da (s.o.),
+aber noch nicht an Dokumentmodell/UI angebunden. Siehe ROADMAP §4.
 
 ## Entwicklung
 
 ```bash
 npm install
-npm run dev        # Vite, http://localhost:5187
-npm run tauri:dev  # Tauri-Fenster (macOS — nativer Zielrahmen dort)
-npm run electron   # Electron-Fenster (Linux — WebGPU über Chromium statt WebKitGTK)
-npx tsc -b         # Typecheck
-npm run build      # tsc -b && vite build
-npm test           # vitest run
+npm run dev      # Vite, http://localhost:5187
+npm run electron # Electron-Fenster (Dev-Server + randlose App-Shell)
+npx tsc -b       # Typecheck
+npm run build    # tsc -b && vite build
+npm test         # vitest run
 ```
 
-WASM-Engines nach Rust-Änderungen neu bauen (nur `.rs` committen,
-`src/engine/pkg*/` ist gitignored):
-
-```bash
-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.
+Verifiziert wird visuell: `node scripts/probe.mjs` rendert die App headless und
+schreibt `scripts/probe.png` — Screenshot ansehen, Geometrie prüfen. Weitere
+`scripts/probe-*.mjs` decken einzelne Features ab (PDF, Trim, Materialien,
+Theme, Boolean-Ops …); für Firefox-Fälle gibt es `scripts/probe-ff*.mjs`
+(Playwright).
 
 ## Aufbau
 
 ```
 src/
-  model/       semantisches Modell (types, joins, parametricWalls, roomStamp, terrain)
-  geometry/    2D-Kernel (offset/trim/fillet/intersect, ceiling/opening/roomArea/stair/roof/column)
+  model/       semantisches Modell + Ableitungen (types, parametricWalls, roomStamp, joins, terrain)
+  geometry/    2D-Kernel (offset/trim/fillet/intersect, ceiling, opening, roomArea/-Boundary, stair)
   commands/    Rhino-artiges Befehlssystem (engine, parser, registry, cmds/)
   tools/       interaktive Zeichenwerkzeuge + Snapping + Transformationen
-  plan/        Grundriss-Ableitung (generatePlan) + PlanView (SVG) + glPlan (WebGL2) + Rust-Bindings
-  viewport/    Viewport3D (Three.js) + Wasm3DViewport (Rust/wgpu „Nordstern", Default)
-  section/     TOTER Code (OCCT-HLR-Spike) — Schnitt läuft über render3d, siehe ARCHITECTURE.md §4.3
-  export/      IFC4-, PDF-, DXF-, STL/OBJ-, CSV-Export aus derselben Plan-/Modell-Struktur
-  materials/   ambientCG-Live-Suche + gebündelte Starter-Bibliothek + PBR-Runtime
+  plan/        Grundriss-Ableitung (generatePlan) + PlanView (SVG) + glPlan (WebGL2-Renderer)
+  viewport/    Viewport3D (Three.js)
+  section/     HLR-Spike (OCCT-WASM) — Schnitte/Ansichten, noch nicht verdrahtet
+  export/      PDF- und DXF-Export aus derselben Plan-Struktur wie der Bildschirm
+  materials/   PBR-Material-Bibliothek (ambientCG-Import, Runtime)
+  text/        Rich-Text (Beschriftungen, Textobjekte)
   panels/      dockbares Panel-System + die einzelnen Paletten
-  state/       eigener Store (useSyncExternalStore) + Slices (project/selection/view/layout/…)
-  native/      Tauri-only: native Fenster, macOS-Menüleiste, Fenster-Chrome
-  ui/          App.tsx-Shell, Top-Bar, Resource Manager, Kontextmenü, Kommandozeile, Ribbon
+  state/       Store + Slices (project/selection/view/layout)
+  ui/          Top-Bar, Statusleiste, Kontextmenü, Resource Manager, Command-Line
   io/          Import/Export (DXF, DWG, .lin, .pat), Swisstopo/LV95, OSM-Kontext
   i18n/        Wörterbücher de/en
-src-tauri/     6 Rust-Crates (render2d/render3d/geometry/kernel2d/trucksolid/dwgimport,
-               je headless UND per wasm-pack baubar) + der Tauri-Host selbst
+src-tauri/     Rust-Crates (render2d/render3d) — headless per wasm-pack zu WASM
+               gebaut (npm run build:engine), Tauri-Host selbst ist ausrangiert
 ```
 
 ## Konventionen
@@ -149,30 +141,17 @@ src-tauri/     6 Rust-Crates (render2d/render3d/geometry/kernel2d/trucksolid/dwg
   (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`.
-- Verbindliches in [CONVENTIONS.md](CONVENTIONS.md).
+- `App.tsx` bleibt dünner Shell, Zustand lebt im Store. Verbindliches in
+  [CONVENTIONS.md](CONVENTIONS.md).
 
 ## Weiterlesen
 
-- [STATUS.md](STATUS.md) — **vollständige, ehrliche Bestandsaufnahme**: Zahlen,
-  Feature-Inventar, Mist-Liste, Doku-Widersprüche, Tag-1-Vision vs. heute
-- [ARCHITECTURE.md](ARCHITECTURE.md) — technische Architektur im Detail (Ist-Zustand)
-- [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).
+- [ROADMAP.md](ROADMAP.md) — Produktvision, Architektur-Entscheidungen, Phasen 0–7, DOSSIER-Backlog
+- [ARCHITECTURE.md](ARCHITECTURE.md) — Technische Architektur im Detail
+- [HANDOVER.md](HANDOVER.md) — aktueller Arbeitsstand, Befunde, nächste Schritte
+- [docs/](docs/) — Design-Specs (Befehlssystem, Zeichenwerkzeuge, Wand-Joins, Backend …)
 
 ---
 
-Die UI ist deutsch; Schweizer Spezifika (SIA-416-Flächen, Swisstopo-Geodaten)
-sind ein bewusster Differenzierer.
+Privates Projekt. Die UI ist deutsch; Schweizer Spezifika (SIA-416-Flächen,
+Swisstopo-Geodaten) sind als Differenzierer eingeplant.

RESEARCH_BAUTEILE_RHINO.md

@@ -1,43 +0,0 @@
-# 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.

RESEARCH_CAD_APPROACHES.md

@@ -1,162 +0,0 @@
-# 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.

ROADMAP.md

@@ -1,16 +1,6 @@
 # Browser-BIM für Wohnbau — Architektur & Produkt-Roadmap
 
-> **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**)
+> Arbeitstitel: **cad** (Name später)
 > Ausrichtung: **BIM-first** · Nische: **Wohnbau / Einfamilienhäuser**
 > Stand: 2026-06-28
 

SPIKE_TEXTUR_render3d.md

@@ -1,137 +0,0 @@
-# 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.

STATUS.md

@@ -1,342 +0,0 @@
-# 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.

docs/HAUPTINSTANZ-BRIEFING.md

@@ -1,4 +1,4 @@
-# ARCHITEKTUR-BRIEFING: Tauri + wgpu (Korrigiert)
+# HAUPTINSTANZ-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
+## Nächste Schritte (für Hauptinstanz)
 
 1. **Lesen:** `docs/design/tauri-migration-plan.md` (technisch, konkret)
 2. **Spawn:** vier Agents (parallel, unabhängig)

docs/README.md

@@ -1,13 +1,6 @@
 # Dokumentation — Standalone Browser-BIM (cad)
 
-> 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) ·
+> Stand: 2026-06-29 · Übergeordnet: [ROADMAP.md](../ROADMAP.md) (Vision & Phasen) ·
 > [CONVENTIONS.md](../CONVENTIONS.md) (Konventionen) · [ARCHITECTURE.md](../ARCHITECTURE.md).
 
 Dieses Verzeichnis bündelt die Recherche- und Design-Dokumente für `cad`, die

docs/design/bim-elements-depth-study.md

@@ -1,623 +0,0 @@
-# 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.

docs/design/dossier-feature-audit.md

@@ -1,8 +1,10 @@
 # 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. Abgleich DOSSIER-Rhino-Referenzrepo (`/tmp/dossier-ref`) gegen
-den aktuellen Browser-Port. Belege (Datei:Zeile) beziehen sich auf `/tmp/dossier-ref/rhino/*.py`.
+Einzeilern verweist. Ursprünglich von einem Opus-Subagent erarbeitet, der das
+DOSSIER-Rhino-Referenzrepo (`/tmp/dossier-ref`) gegen den aktuellen Browser-Port
+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.
 

docs/design/ribbon-ui-plan.md

@@ -1,74 +0,0 @@
-# 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.

docs/design/topbar-dossier.md

@@ -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
-Trace-Scan (grep auf Co-Authored/Generated), Boot-Probe
+AI-Spuren (grep auf Claude/Anthropic/AI/Generated/Co-Authored), Boot-Probe
 (`node scripts/probe.mjs`) ohne Konsolenfehler, Screenshot der Oberleiste.
 KEIN Commit.

docs/design/truck-plan.md

@@ -1,403 +0,0 @@
-# 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.

docs/design/wgpu-2d-renderer-briefing.md

@@ -1,12 +1,13 @@
 # Briefing — Nativer wgpu-2D-Renderer (parallele Instanz)
 
-> Für den Entwickler, der den nativen GPU-Renderer baut. Isoliert vom
+> Für die Instanz/den Agenten, der den nativen GPU-Renderer baut. Isoliert vom
 > Web-Renderer; koordiniert über dieses Dokument.
 
 ## COMMIT-REGEL (verbindlich)
-Dieses Repo darf **keinerlei Fremd-Tool-Hinweise** enthalten — nicht im Code,
-in Kommentaren oder in der Git-Historie. Kommentare deutsch, Identifier englisch.
-**Kein Commit ohne Absprache.**
+Dieses Repo darf **keinerlei Hinweise auf KI-Werkzeuge** enthalten — nicht im Code,
+in Kommentaren oder in der Git-Historie. Keine `Co-Authored-By`-Trailer, keine
+„Generated with"-Zeilen, keine Modell-/Agenten-Namen. Kommentare deutsch,
+Identifier englisch. **Kein Commit ohne Ansage der Hauptinstanz.**
 
 ## Warum
 Der 2D-Plan wird aktuell in einem WebGL-Canvas gerendert (Web-Stack). In Chromium
@@ -71,9 +72,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 (dort laufen parallel Features).
+  `src/plan/*`, `types.ts` anfassen (die Hauptinstanz arbeitet dort an Features).
 - Der Web-WebGL-Renderer bleibt bestehen (Browser-Lauffähigkeit + Referenz).
-- Ergebnisse/Diffs zurückliefern; Projektleitung committet.
+- Ergebnisse/Diffs zurückliefern; die Hauptinstanz committet und pflegt das Memory.
 
 ## Gates
 `cargo check`/`cargo test`/`cargo build` grün. Trace-Scan sauber (COMMIT-REGEL).

docs/design/wgpu-3d-renderer-briefing.md

@@ -6,7 +6,9 @@
 > Port-Plan) und M1 (entkoppelter Standalone-Spike). Noch NICHT die Migration.
 
 ## Commit-/Spuren-Regel
-Wie im ganzen Repo: keine Fremd-Tool-Hinweise im Code, in Kommentaren oder der Historie. Kommentare deutsch, Identifier englisch. Kein Commit ohne Absprache.
+Wie im ganzen Repo: keine Hinweise auf KI-Werkzeuge — nicht im Code, in Kommentaren
+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

docs/design/window-editor-vectorworks-study.md

@@ -1,449 +0,0 @@
-# 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.

docs/research/sia400-fenster-tueren.md

@@ -1,82 +0,0 @@
-# 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).

index.html

@@ -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>Dossier</title>
+    <title>cad — Phase 0 Spike</title>
   </head>
   <body>
     <div id="root"></div>

package-lock.json

@@ -10,8 +10,6 @@
       "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",
@@ -1844,24 +1842,6 @@
         "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",

package.json

@@ -1,10 +1,8 @@
 {
-  "name": "dossier",
+  "name": "cad",
   "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",
@@ -18,17 +16,11 @@
     "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: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"
+    "build:engine3d": "wasm-pack build src-tauri/render3d --release --target web --out-dir ../../src/engine/pkg3d --out-name render3d --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",
@@ -53,12 +45,5 @@
     "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
   }
 }

public/assets/materials/manifest.json

@@ -1,7 +1,7 @@
 {
   "source": "ambientCG (ambientcg.com)",
   "license": "CC0 1.0 Universal (Public Domain)",
-  "resolution": "2K",
+  "resolution": "1K",
   "materials": [
     {
       "id": "Concrete048",
@@ -61,18 +61,6 @@
         "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",
@@ -156,4 +144,4 @@
       }
     }
   ]
-}
+}

src-tauri/Cargo.lock

@@ -384,7 +384,6 @@ dependencies = [
 name = "cad-tauri"
 version = "0.1.0"
 dependencies = [
- "fs4",
  "geometry",
  "pollster",
  "render2d",
@@ -393,8 +392,6 @@ dependencies = [
  "serde_json",
  "tauri",
  "tauri-build",
- "tauri-plugin-dialog",
- "tauri-plugin-fs",
  "wgpu",
  "winit",
 ]
@@ -985,7 +982,7 @@ version = "0.5.3"
 source = "registry+https://github.com/rust-lang/crates.io-index"
 checksum = "ab8ecd87370524b461f8557c119c405552c396ed91fc0a8eec68679eab26f94a"
 dependencies = [
- "libloading 0.8.9",
+ "libloading 0.7.4",
 ]
 
 [[package]]
@@ -1307,16 +1304,6 @@ 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"
@@ -1501,10 +1488,8 @@ dependencies = [
 name = "geometry"
 version = "0.1.0"
 dependencies = [
- "console_error_panic_hook",
  "serde",
  "serde_json",
- "wasm-bindgen",
 ]
 
 [[package]]
@@ -1703,7 +1688,7 @@ dependencies = [
  "log",
  "presser",
  "thiserror 2.0.18",
- "windows 0.62.2",
+ "windows 0.61.3",
 ]
 
 [[package]]
@@ -2905,7 +2890,6 @@ checksum = "e3e0adef53c21f888deb4fa59fc59f7eb17404926ee8a6f59f5df0fd7f9f3272"
 dependencies = [
  "bitflags 2.13.0",
  "block2 0.6.2",
- "libc",
  "objc2 0.6.4",
  "objc2-core-foundation",
 ]
@@ -3719,30 +3703,6 @@ 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"
@@ -4576,64 +4536,6 @@ 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"
@@ -6042,15 +5944,6 @@ 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"
@@ -6084,30 +5977,13 @@ dependencies = [
  "windows_aarch64_gnullvm 0.52.6",
  "windows_aarch64_msvc 0.52.6",
  "windows_i686_gnu 0.52.6",
- "windows_i686_gnullvm 0.52.6",
+ "windows_i686_gnullvm",
  "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"
@@ -6147,12 +6023,6 @@ 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"
@@ -6165,12 +6035,6 @@ 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"
@@ -6183,24 +6047,12 @@ 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"
@@ -6213,12 +6065,6 @@ 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"
@@ -6231,12 +6077,6 @@ 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"
@@ -6249,12 +6089,6 @@ 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"
@@ -6267,12 +6101,6 @@ 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"

src-tauri/Cargo.toml

@@ -1,14 +1,10 @@
 [workspace]
-members = ["."]
-# render2d/render3d/geometry sind eigenstaendige Crates, damit sie headless ohne
-# Tauri-Toolchain UND per wasm-pack (Feature "web") zu WASM baubar bleiben. Sie
-# liegen zwar im src-tauri-Baum, gehoeren aber NICHT zum cad-tauri-Workspace —
-# hier ausschliessen, damit `cad-tauri` sie dennoch per Pfad als Abhaengigkeit
-# 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"]
+members = [".", "geometry"]
+# render2d/render3d sind eigenstaendige Crates (jeweils eigener [workspace]), damit
+# sie headless ohne Tauri-Toolchain baubar/testbar bleiben. Sie liegen zwar im
+# src-tauri-Baum, gehoeren aber NICHT zum cad-tauri-Workspace — hier ausschliessen,
+# damit `cad-tauri` sie dennoch per Pfad als (optionale) Abhaengigkeit nutzen kann.
+exclude = ["render2d", "render3d"]
 
 [package]
 name = "cad-tauri"
@@ -37,15 +33,9 @@ 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

src-tauri/capabilities/default.json

@@ -1,22 +0,0 @@
-{
-  "$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"
-  ]
-}

src-tauri/dwgimport/Cargo.lock

@@ -1,578 +0,0 @@
-# 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"

src-tauri/dwgimport/Cargo.toml

@@ -1,36 +0,0 @@
-# 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 }

src-tauri/dwgimport/src/lib.rs

@@ -1,284 +0,0 @@
-// 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}");
-    }
-}

src-tauri/geometry/Cargo.toml

@@ -2,28 +2,9 @@
 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]

src-tauri/geometry/src/lib.rs

@@ -9,20 +9,6 @@
 
 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,
@@ -81,20 +67,6 @@ 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 {
@@ -110,11 +82,6 @@ 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
@@ -168,13 +135,6 @@ 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;
@@ -239,76 +199,17 @@ 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). In einem Block, damit die
-    // mutable Ausleihe von `result[branch_wall_idx]` vor dem Zugriff auf die
-    // Durchgangswand unten endet.
-    // Nah-Putz-Komponenten der Durchgangswand (dieselbe sign-Seite wie
-    // near_plaster oben): ist die getrimmte Abzweig-Schicht materialgleich mit
-    // einer davon, fuellt der Nah-Putz den Abzweig-Putz an dieser Stelle
-    // durchgehend (spanCutout schneidet nur die KERN-Breite aus, nicht die
-    // schmalen Putzflanken) -> Putz-L OHNE Trennnaht, also KEINE L-Seitenlinie.
-    let near_plaster_comps: Vec<&str> = through_layers
-        .iter()
-        .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,
-            });
-        }
+    // Rueckgrat-Nahflaeche ab (nicht an der Wandachse).
+    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]));
+        side_arr[i] = if adj_merged { Some(side_line) } else { None };
     }
 }
 
@@ -404,7 +305,6 @@ pub fn compute_joins(input: JoinInput) -> Vec<WallCuts> {
             start_cut: None,
             end_cut: None,
             layer_cuts: None,
-            span_cutouts: Vec::new(),
         })
         .collect();
 
@@ -585,10 +485,6 @@ fn apply_t_junction(
         u_t,
         sign,
         off_t,
-        through_wall_idx,
-        through_wall.start,
-        dir_of(branch_wall),
-        branch_wall.reference_offset,
     );
 }
 
@@ -679,10 +575,6 @@ fn apply_mid_span_tee(
         u_w,
         sign,
         off_w,
-        w_idx,
-        w.start,
-        dir_of(free_wall),
-        free_wall.reference_offset,
     );
 }
 
@@ -968,8 +860,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. Da der Nah-Putz der
-        // Durchgangswand materialgleich ist, entsteht KEINE L-Trennnaht.
+        // Innenputz-Schichten (Index 0/2) werden getrimmt und bekommen
+        // zusaetzlich die seitliche L-Linie an derselben Flaeche.
         let input = JoinInput {
             walls: vec![
                 w_iw("A", 0.0, 0.0, 5.0, 0.0),
@@ -1004,54 +896,18 @@ 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);
-        // ... aber KEINE seitliche L-Linie: der Innenputz der Durchgangswand ist
-        // materialgleich und fuellt den getrimmten Abzweig-Putz durchgehend
-        // (Putz-L ohne Trennnaht). Nur bei materialFREMDEM Nah-Putz stuende hier
-        // eine L-Linie.
-        assert!(lc.start_side[0].is_none());
-        assert!(lc.start_side[2].is_none());
+        // ... UND die seitliche L-Linie an der Rueckgrat-Nahflaeche (y=0.06,
+        // parallel zur x-Achse).
+        let s0 = lc.start_side[0].expect("Schicht 0 hat L-Seitenlinie");
+        let s2 = lc.start_side[2].expect("Schicht 2 hat L-Seitenlinie");
+        assert!(dist(s0, Vec2 { x: 5.0, y: 0.06 }) < 1e-9);
+        assert!(dist(s0, Vec2 { x: 0.0, y: 0.06 }) < 1e-9);
+        assert!(dist(s2, Vec2 { x: 5.0, y: 0.06 }) < 1e-9);
 
-        // Die kollineare Durchgangswand bleibt bei den layerCuts unangetastet.
+        // Die kollineare Durchgangswand bleibt unangetastet (kein layerCuts).
         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());
     }
 }

src-tauri/kernel2d/Cargo.lock

@@ -1,195 +0,0 @@
-# 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"

src-tauri/kernel2d/Cargo.toml

@@ -1,40 +0,0 @@
-# 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"

src-tauri/render3d/examples/section_svg.rs

@@ -32,10 +32,6 @@ 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],
@@ -46,10 +42,6 @@ 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
@@ -65,10 +57,6 @@ 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 {
@@ -76,8 +64,6 @@ 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)
 }

src-tauri/render3d/src/bin/spike3d.rs

@@ -13,14 +13,13 @@
 
 use std::sync::Arc;
 
-use render3d::gpu::{RenderStyle, Renderer};
+use render3d::gpu::Renderer;
 use render3d::math::orbit_eye;
 use render3d::types::{Camera, Projection, WallInput};
 
 use winit::application::ApplicationHandler;
-use winit::event::{ElementState, KeyEvent, MouseButton, MouseScrollDelta, WindowEvent};
+use winit::event::{ElementState, 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
@@ -39,10 +38,6 @@ 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![
@@ -200,9 +195,6 @@ 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 {
@@ -230,27 +222,6 @@ 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;

src-tauri/render3d/src/edges.rs

@@ -91,21 +91,11 @@ fn dot(a: [f32; 3], b: [f32; 3]) -> f32 {
     a[0] * b[0] + a[1] * b[1] + a[2] * b[2]
 }
 
-/// Eine Kante samt ihrer deduplizierten Repraesentanten-Normalen (Rueckseiten
-/// bereits gepaart, s. `representatives`). Grundlage BEIDER Kanten-Stile: die
-/// statischen Feature-Edges (`build_mesh_edges`) UND die blickabhaengigen
-/// Silhouetten-Konturen (`build_silhouette_edges`).
-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> {
+/// 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> {
     if mesh.indices.len() < 3 {
         return Vec::new();
     }
@@ -147,83 +137,20 @@ pub fn build_edge_adjacency(mesh: &Mesh) -> Vec<EdgeAdj> {
         }
     }
 
-    edges
-        .into_values()
-        .map(|rec| EdgeAdj {
-            p0: rec.p0,
-            p1: rec.p1,
-            reps: representatives(&rec.normals),
-        })
-        .collect()
-}
-
-fn push_edge(verts: &mut Vec<f32>, p0: [f32; 3], p1: [f32; 3]) {
-    for p in [p0, p1] {
-        verts.extend_from_slice(&[p[0], p[1], p[2], EDGE_COLOR[0], EDGE_COLOR[1], EDGE_COLOR[2]]);
-    }
-}
-
-/// 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
-}
+    let mut push = |p: [f32; 3]| {
+        verts.push(p[0]);
+        verts.push(p[1]);
+        verts.push(p[2]);
+        verts.push(EDGE_COLOR[0]);
+        verts.push(EDGE_COLOR[1]);
+        verts.push(EDGE_COLOR[2]);
+    };
 
-/// 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);
+    for rec in edges.values() {
+        if should_draw(&rec.normals) {
+            push(rec.p0);
+            push(rec.p1);
         }
     }
     verts
@@ -232,54 +159,15 @@ pub fn build_silhouette_edges(
 /// 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.
-///
-/// 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() {
+fn should_draw(normals: &[[f32; 3]]) -> bool {
+    match normals.len() {
         0 => false,
-        1 => true, // Silhouette/Rand: gehoert nur einem Original-Dreieck
+        1 => true, // Silhouette/Rand: gehoert nur einem Dreieck
         _ => {
-            for i in 0..reps.len() {
-                for j in (i + 1)..reps.len() {
-                    if dot(reps[i], reps[j]) < CREASE_COS {
+            // Zeichnen, sobald irgendein Normalen-Paar deutlich abknickt.
+            for i in 0..normals.len() {
+                for j in (i + 1)..normals.len() {
+                    if dot(normals[i], normals[j]) < CREASE_COS {
                         return true;
                     }
                 }
@@ -359,186 +247,4 @@ 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);
-    }
 }

src-tauri/render3d/src/lib.rs

@@ -20,7 +20,6 @@ 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;
@@ -39,30 +38,23 @@ pub use math::{
     view_matrix, view_projection, Mat4,
 };
 pub use mesh::{
-    append_context_mesh, build_model_mesh, build_scene_mesh, build_walls_mesh,
-    build_walls_mesh_textured, extrude_slab, extrude_wall, textured_from_mesh, triangulate,
+    append_context_mesh, build_model_mesh, build_scene_mesh, build_walls_mesh, extrude_slab,
+    extrude_wall, triangulate,
 };
 pub use section::{
     cut_section, ComponentKind, ComponentRef, CutPolygon, SectionEdge, SectionOutput, SectionPlane,
 };
 pub use types::{
-    Camera, CameraPreset, Mesh, MeshInput, MeshKind, Point2, Projection, Rgb, SlabInput,
-    TexturedMesh, WallInput, FLOATS_PER_VERTEX, TEXTURED_FLOATS_PER_VERTEX,
+    Camera, CameraPreset, Mesh, MeshInput, MeshKind, Point2, Projection, Rgb, SlabInput, WallInput,
+    FLOATS_PER_VERTEX,
 };
 
 // --- Tests: Mesh-Erzeugung (Muster wie render2d/tessellate) -------------------
 
 #[cfg(test)]
 mod tests {
-    use super::mesh::{
-        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,
-    };
+    use super::mesh::{build_walls_mesh, extrude_wall, INDICES_PER_BOX, VERTS_PER_BOX};
+    use super::types::{Mesh, Opening, WallInput, WallLayer, FLOATS_PER_VERTEX};
 
     /// Bequemer Bau einer achsparallelen Wand entlang +X.
     fn wall_x(len: f32, thickness: f32, height: f32) -> WallInput {
@@ -75,10 +67,6 @@ mod tests {
             color: [0.8, 0.8, 0.8],
             openings: vec![],
             layers: None,
-            holes: vec![],
-            material_index: None,
-            hatch: None,
-            cut: None,
         }
     }
 
@@ -91,67 +79,6 @@ 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).
@@ -164,65 +91,6 @@ 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(&[
@@ -236,10 +104,6 @@ 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);
@@ -318,10 +182,6 @@ 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);
@@ -343,10 +203,6 @@ 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);
@@ -450,97 +306,6 @@ 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]
@@ -560,10 +325,6 @@ 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],
@@ -574,10 +335,6 @@ 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");
@@ -637,10 +394,6 @@ 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]),
@@ -669,10 +422,6 @@ 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),
@@ -761,10 +510,6 @@ 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];
@@ -795,8 +540,6 @@ mod tests {
             z_bottom,
             z_top,
             color: [0.86, 0.86, 0.88],
-            hatch: None,
-            cut: None,
         }
     }
 
@@ -853,8 +596,6 @@ 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);
@@ -883,7 +624,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], hatch: None, cut: None });
+        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] });
         assert_eq!(mesh.vertex_count(), 0);
         // Nullhoehe.
         extrude_slab(&mut mesh, &square_slab(4.0, 2.6, 2.6));
@@ -902,8 +643,6 @@ mod tests {
             indices: vec![0, 1, 2],
             kind,
             color,
-            material_index: None,
-            vertex_colors: Vec::new(),
         }
     }
 
@@ -945,73 +684,6 @@ 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();
@@ -1023,8 +695,6 @@ 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);
@@ -1036,8 +706,6 @@ 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);
@@ -1129,51 +797,6 @@ 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).
@@ -1204,23 +827,5 @@ 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:?}"));
     }
 }

src-tauri/render3d/src/math.rs

@@ -185,26 +185,15 @@ pub fn orbit_eye(target: [f32; 3], yaw: f32, pitch: f32, dist: f32) -> [f32; 3]
     ]
 }
 
-/// Baut eine `Camera` fuer eines der Kardinal-/Iso-Presets (ROADMAP §11).
-/// `target` ist das Blickziel (Modell-Mitte), `dist` der Abstand. Alle Presets
-/// ausser `Persp` sind orthografisch (Front/Back/Top/Side/Left achsparallel,
-/// 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).
+/// Baut eine `Camera` fuer eines der fuenf Presets der three.js-Sicht. `target`
+/// ist das Blickziel (Modell-Mitte), `dist` der Abstand. Front/Top/Side/Iso
+/// sind orthografisch (Front/Top/Side achsparallel, Iso diagonal); nur Persp
+/// ist perspektivisch.
 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 => {
@@ -213,13 +202,6 @@ 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 => {
@@ -228,48 +210,24 @@ 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 rechten Seite), orthografisch.
+        // Blick entlang -X (von der 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;
         }
-        // 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).
+        // Isometrischer Ueberblick (orthografisch, Blick von schraeg oben).
         // Echte Isometrie ist per Definition parallelprojiziert (keine
         // perspektivische Verzerrung, Kantenlaengen bleiben massstabsgetreu).
         CameraPreset::Iso => {
             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 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];
+            let d = dist / 3.0_f32.sqrt();
+            cam.eye = [target[0] + d, target[1] + d, target[2] + 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).

src-tauri/render3d/src/mesh.rs

@@ -59,8 +59,7 @@ use std::collections::HashMap;
 
 use crate::openings::{split_range_by_voids, MIN_SPAN};
 use crate::types::{
-    Hole, Mesh, MeshInput, Opening, Point2, Rgb, SlabInput, TexturedMesh, WallInput, WallLayer,
-    FLOATS_PER_VERTEX, TEXTURED_FLOATS_PER_VERTEX,
+    Mesh, MeshInput, Opening, Point2, Rgb, SlabInput, WallInput, WallLayer, FLOATS_PER_VERTEX,
 };
 
 /// Ein Quader-Mesh besteht aus 6 Seiten (Boden, Deckel, 4 Waende) zu je 2
@@ -110,16 +109,7 @@ fn extrude_wall_with_miters(mesh: &mut Mesh, wall: &WallInput, miters: WallMiter
 
     let z0 = wall.base_elevation;
     let z1 = wall.base_elevation + wall.height;
-    // 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)
-    };
+    let segments = 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.
@@ -149,20 +139,10 @@ 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 };
-            if has_holes {
-                // Voller Achsen-Abschnitt (a0=0, a1=length) mit echten Loechern
-                // 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,
-                );
-            }
+            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;
     }
@@ -304,328 +284,6 @@ 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
@@ -835,160 +493,6 @@ 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
@@ -1071,131 +575,6 @@ 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).
@@ -1220,20 +599,6 @@ 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
@@ -1256,21 +621,6 @@ 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;
@@ -1285,7 +635,6 @@ 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]];
@@ -1300,8 +649,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, [ca, cb, cc]);
-        push_ctx_tri(mesh, a, c, b, [-n[0], -n[1], -n[2]], [ca, cc, cb]);
+        push_ctx_tri(mesh, a, b, c, n, color);
+        push_ctx_tri(mesh, a, c, b, [-n[0], -n[1], -n[2]], color);
     }
 }
 
@@ -1314,10 +663,10 @@ fn push_ctx_tri(
     b: [f32; 3],
     c: [f32; 3],
     normal: [f32; 3],
-    colors: [Rgb; 3],
+    color: Rgb,
 ) {
     let base = (mesh.verts.len() / FLOATS_PER_VERTEX) as u32;
-    for (p, color) in [a, b, c].iter().zip(colors.iter()) {
+    for p in [a, b, c] {
         mesh.verts.extend_from_slice(&[
             p[0], p[1], p[2], normal[0], normal[1], normal[2], color[0], color[1], color[2],
         ]);

src-tauri/render3d/src/section.rs

@@ -24,9 +24,12 @@
 //! - **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(world_up, normal))` — das Blickrichtungs-RECHTS
-//!   des Betrachters (wer nach Norden blickt, hat Osten rechts). Die fruehere
-//!   look_at-Konvention `cross(normal, up)` spiegelte die Zeichnung.
+//!   `u_axis = normalize(cross(normal, world_up))` — dieselbe rechtshaendige
+//!   Kamera-Konvention wie `math::look_at` (dort `s = cross(f, up)`), damit die
+//!   Vorzeichen-Konvention modulübergreifend konsistent bleibt. Bei den
+//!   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 =
@@ -130,7 +133,7 @@
 use serde::{Deserialize, Serialize};
 
 use crate::math;
-use crate::types::{CutBandMeta, Hatch, Opening, Point2, Rgb, SlabInput, WallInput};
+use crate::types::{Opening, Point2, Rgb, SlabInput, WallInput};
 
 /// Toleranz fuer "naeher an der Ebene" / Grenzwert-Vergleiche (Meter, Tiefe/Hoehe).
 const EPS: f32 = 1e-4;
@@ -186,13 +189,8 @@ 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(up, self.normal);
+        let u = math::cross(self.normal, up);
         if math::length(u) > 1e-6 {
             math::normalize(u)
         } else {
@@ -270,19 +268,8 @@ 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.
@@ -327,16 +314,9 @@ 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-
@@ -419,14 +399,12 @@ 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(),
     })
 }
 
@@ -447,9 +425,7 @@ fn slab_prism(index: usize, slab: &SlabInput) -> Option<Prism> {
         z0,
         z1,
         color: slab.color,
-        hatch: slab.hatch,
         wall_axis: None,
-        cut: slab.cut.clone(),
     })
 }
 
@@ -998,9 +974,7 @@ 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(),
                 });
             }
         }
@@ -1042,10 +1016,6 @@ mod tests {
                 color,
                 openings: vec![],
                 layers: None,
-                holes: vec![],
-                material_index: None,
-                hatch: None,
-                cut: None,
             },
             WallInput {
                 start: [0.0, 3.0],
@@ -1056,10 +1026,6 @@ mod tests {
                 color,
                 openings: vec![],
                 layers: None,
-                holes: vec![],
-                material_index: None,
-                hatch: None,
-                cut: None,
             },
         ];
         let slabs = vec![SlabInput {
@@ -1067,8 +1033,6 @@ mod tests {
             z_bottom: -0.2,
             z_top: 0.0,
             color: [0.86, 0.86, 0.88],
-            hatch: None,
-            cut: None,
         }];
         (walls, slabs)
     }
@@ -1101,9 +1065,8 @@ mod tests {
             math::dot(u, plane.normal).abs() < 1e-6,
             "u-Achse orthogonal zur Blickrichtung"
         );
-        // Fuer looking_plus_x (Blick nach Osten) zeigt das Betrachter-RECHTS
-        // nach Sueden: u = world −Z (Entspiegelung, s. u_axis-Doc).
-        assert!((u[2] + 1.0).abs() < 1e-6);
+        // Fuer looking_plus_x ist u = Modell-Y (world +Z).
+        assert!((u[2] - 1.0).abs() < 1e-6);
     }
 
     #[test]
@@ -1143,8 +1106,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 + 3.1).abs() < 1e-4, "u_lo={u_lo}");
-        assert!((u_hi + 2.9).abs() < 1e-4, "u_hi={u_hi}");
+        assert!((u_lo - 2.9).abs() < 1e-4, "u_lo={u_lo}");
+        assert!((u_hi - 3.1).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}");
 
@@ -1157,8 +1120,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 + 3.5).abs() < 1e-4, "u_lo={u_lo}");
-        assert!((u_hi - 0.5).abs() < 1e-4, "u_hi={u_hi}");
+        assert!((u_lo + 0.5).abs() < 1e-4, "u_lo={u_lo}");
+        assert!((u_hi - 3.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}");
     }
@@ -1214,30 +1177,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.b[0] + 2.9).abs() < 1e-3
+                && (e.a[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.b[0] + 3.1).abs() < 1e-3
+                && (e.a[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: -3.1 -> -2.9 bei v=0,
-        // gespiegelte u-Achse) zerfaellt in einen sichtbaren Anteil ab u=-3.0.
+        // Die partiell gesplittete Bodenkante (u: 2.9 -> 3.1 bei v=0) 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");
     }
@@ -1289,14 +1252,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 (_b_lo, b_hi) = u_bounds(b);
+        let (_a_lo, a_hi) = u_bounds(a);
+        let (b_lo, _b_hi) = u_bounds(b);
 
-        // Beide enden/beginnen an der Gehrungslinie (u ~ -2.95, gespiegelte
-        // u-Achse) statt sich zu ueberlappen.
-        assert!((a_lo + 2.95).abs() < 1e-3, "Schenkel-A-Querschnitt endet an der Gehrung, u_lo={a_lo}");
-        assert!((b_hi + 2.95).abs() < 1e-3, "Schenkel-B-Querschnitt beginnt an der Gehrung, u_hi={b_hi}");
-        assert!(b_hi <= a_lo + 1e-4, "keine u-Ueberlappung der beiden Querschnitte");
+        // Beide enden/beginnen an der Gehrungslinie (u ~ 2.95) statt sich zu
+        // ueberlappen (Schenkel A reichte ungehrt bis u=3.0, Schenkel B ab 2.9).
+        assert!((a_hi - 2.95).abs() < 1e-3, "Schenkel-A-Querschnitt endet an der Gehrung, u_hi={a_hi}");
+        assert!((b_lo - 2.95).abs() < 1e-3, "Schenkel-B-Querschnitt beginnt an der Gehrung, u_lo={b_lo}");
+        assert!(a_hi <= b_lo + 1e-4, "keine u-Ueberlappung der beiden Querschnitte");
     }
 
     // --- Oeffnungen (Tueren/Fenster) -----------------------------------------
@@ -1319,10 +1282,6 @@ mod tests {
                 height: 1.0,
             }],
             layers: None,
-            holes: vec![],
-            material_index: None,
-            hatch: None,
-            cut: None,
         }
     }
 
@@ -1408,10 +1367,6 @@ 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);
@@ -1430,8 +1385,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(2.5), "rechte Leibung (u=2.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");
         // Bruestungs- und Sturzkante (horizontale Rahmenkanten bei v=1.0/2.0).
         let horizontal_edge_visible = |v: f32| {
             out.visible_edges.iter().any(|e| {
@@ -1439,8 +1394,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]) - 1.5).abs() < 1e-3
-                    && (e.a[0].max(e.b[0]) - 2.5).abs() < 1e-3
+                    && (e.a[0].min(e.b[0]) + 2.5).abs() < 1e-3
+                    && (e.a[0].max(e.b[0]) + 1.5).abs() < 1e-3
             })
         };
         assert!(horizontal_edge_visible(1.0), "Bruestungskante (v=1.0) muss sichtbar sein");
@@ -1450,21 +1405,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 1.5..2.5) muss
+        // u=-2.0 (Wandstart x=2, liegt IM Fenster-u-Bereich -2.5..-1.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.b[0] - 2.0).abs() < 1e-3
+                && (e.a[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
         });
@@ -1473,8 +1428,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.b[0] - 2.0).abs() < 1e-3
+                && (e.a[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
         });
@@ -1483,20 +1438,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.b[0] - 2.0).abs() < 1e-3
+                && (e.a[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.b[0] - 4.0).abs() < 1e-3
+                && (e.a[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
         });

src-tauri/render3d/src/section_boolean.rs

@@ -1,516 +0,0 @@
-//! 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:?}");
-    }
-}

src-tauri/render3d/src/section_fill.rs

@@ -21,68 +21,19 @@
 //!
 //! ## Ausgabeformat
 //!
-//! Interleaved `[world_x, world_y, world_z, u, v, pattern, angle_rad, scale]` je
-//! Vertex (8 f32, `CAP_FLOATS_PER_VERTEX`), Dreiecksliste. `(u,v)` in Modell-Metern
-//! wandern als Attribut mit, damit die Schraffur im Fragment-Shader ein
-//! durchgaengiges, blickwinkel-unabhaengiges Muster IN der Schnittebene zeichnet
-//! (nicht im Bildschirmraum). `pattern`/`angle_rad`/`scale` kommen aus der
-//! 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.
+//! Interleaved `[world_x, world_y, world_z, u, v]` je Vertex (5 f32,
+//! `CAP_FLOATS_PER_VERTEX`), Dreiecksliste. `(u,v)` in Modell-Metern wandern als
+//! Attribut mit, damit die Schraffur im Fragment-Shader ein durchgaengiges,
+//! blickwinkel-unabhaengiges Muster IN der Schnittebene zeichnet (nicht im
+//! Bildschirmraum). Ein Cut-Polygon ist stets ein konvexes Rechteck (4 Ecken,
+//! siehe `section.rs`) — Fan-Triangulierung genuegt.
 
-use crate::section::{cut_section, CutPolygon, SectionPlane};
-use crate::section_boolean::{rect_of_poly, subtract_dominant_bands};
+use crate::section::{cut_section, SectionPlane};
 use crate::types::{SlabInput, WallInput};
 
-/// f32 pro Cap-Vertex: [pos.x, pos.y, pos.z, u, v, pattern, angle_rad, scale,
-/// line_weight_mm]. Spiegel des Vertex-Layouts der `cap_pipeline` (gpu.rs) und des
-/// `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;
+/// f32 pro Cap-Vertex: [pos.x, pos.y, pos.z, u, v]. Spiegel des Vertex-Layouts
+/// der `cap_pipeline` (gpu.rs) und des `VsIn` in `CAP_WGSL` (shaders.rs).
+pub const CAP_FLOATS_PER_VERTEX: usize = 5;
 
 /// Erzeugt die Schnittflaechen-Geometrie (Cut-Caps) fuer eine vertikale
 /// Schnittebene: ruft `cut_section` und trianguliert jedes (u,v)-Rechteck in die
@@ -93,23 +44,12 @@ const FALLBACK_PATTERN: f32 = 2.0;
 /// 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 polys = cut_cap_polys(plane, walls, slabs);
+    let out = cut_section(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.
@@ -122,28 +62,14 @@ pub fn build_cut_caps(
     };
 
     let mut verts: Vec<f32> = Vec::new();
-    for poly in &polys {
+    for poly in &out.cut_polygons {
         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], pattern, angle_rad, scale, line_weight,
-            ]);
+            verts.extend_from_slice(&[w[0], w[1], w[2], uv[0], uv[1]]);
         };
         // Fan-Triangulierung (konvexe Rechtecke): (0, i, i+1).
         for i in 1..pts.len() - 1 {
@@ -154,429 +80,3 @@ 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"
-        );
-    }
-}

src-tauri/render3d/src/shaders.rs

@@ -125,185 +125,6 @@ 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.
@@ -357,16 +178,11 @@ fn fs_main(in : VsOut) -> @location(0) vec4<f32> {
 "#;
 
 /// WGSL der Schnittflaechen-Kappen (Cut-Caps, section_fill.rs / gpu::cap_pipeline).
-/// Eigene TriangleList-Pipeline: Vertex-Layout [pos vec3, uv vec2, hatch vec3],
+/// Eigene TriangleList-Pipeline: schlankes Vertex-Layout [pos vec3, uv vec2],
 /// dieselbe `Globals`-Bind-Group (group(0) binding(0)) wie Mesh/Grid. Die Caps
-/// werden NICHT geclippt (sie SIND die Schnittflaeche). Fragment: PROZEDURALE
-/// Bauteil-Schraffur je geschnittener Schicht — Muster/Winkel/Skalierung kommen aus
-/// 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).
+/// werden NICHT geclippt (sie SIND die Schnittflaeche). Fragment: prozedurale
+/// 45-Grad-Diagonalschraffur aus den Ebenen-Koordinaten (u,v) in Modell-Metern —
+/// dunkle Tinte auf hellem Papier, passend zur 2D-Schnittkonvention.
 pub const CAP_WGSL: &str = r#"
 struct Globals {
     view_proj     : mat4x4<f32>,
@@ -382,18 +198,11 @@ 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
@@ -401,85 +210,27 @@ 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 pattern = i32(round(in.hatch.x));
-    let angle   = in.hatch.y;
-    let scale   = max(in.hatch.z, 0.05);
-
-    // none (0): leere (weisse) Schnittflaeche — wie „keine Schraffur" im 2D.
-    if (pattern == 0) {
-        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));
+    let s = (in.uv.x + in.uv.y) / spacing;
+    let frac = fract(s);
+    let dist = min(frac, 1.0 - frac);     // 0 auf der Linie
+    let half_s = half / spacing;
+    let aa = max(fwidth(s), 1e-5);
+    let line = 1.0 - smoothstep(half_s, half_s + aa, dist);
+    let color = mix(paper, ink, line);
     return vec4<f32>(color, 1.0);
 }
 "#;

src-tauri/render3d/src/types.rs

@@ -20,79 +20,6 @@ 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`).
@@ -139,70 +66,6 @@ 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`.
@@ -259,13 +122,6 @@ 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 {
@@ -283,9 +139,6 @@ 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 {
@@ -298,8 +151,6 @@ 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],
         }
     }
 }
@@ -336,20 +187,6 @@ 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 {
@@ -412,15 +249,8 @@ fn default_ortho_half_height() -> f32 {
 fn default_near() -> f32 {
     0.05
 }
-// `pub(crate)`, damit `web::set_camera` denselben Basiswert als Untergrenze fuer
-// 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
+fn default_far() -> f32 {
+    1000.0
 }
 
 impl Default for Camera {
@@ -438,24 +268,14 @@ impl Default for Camera {
     }
 }
 
-/// Die Kamera-Presets der Kardinal-/Iso-Sicht (ROADMAP §11). `Persp` ist frei
-/// 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.
+/// Die fuenf Kamera-Presets der three.js-Sicht. `Iso` und `Persp` sind
+/// perspektivisch/frei; `Front`/`Top`/`Side` sind achsparallel (orthografisch).
 #[derive(Debug, Clone, Copy, PartialEq, Eq, Serialize, Deserialize)]
 pub enum CameraPreset {
     Front,
-    Back,
     Top,
     Side,
-    Left,
     Iso,
-    IsoFrontLeft,
-    IsoBackRight,
-    IsoBackLeft,
     Persp,
 }
 
@@ -473,38 +293,6 @@ 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 {

src-tauri/render3d/src/web.rs

@@ -15,13 +15,12 @@
 // (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 `View3d`-Praesete (front/back/
-// top/side/left/iso/isoFrontLeft/isoBackRight/isoBackLeft/perspective) direkt
-// ueber `math::preset_camera` an — alle ausser Perspective werden dabei ECHT
-// orthografisch (`preset_camera`; die Iso-Varianten = echte Isometrie ohne
-// perspektivische Verzerrung), was eine reine TS-Orbit-Naeherung nicht leisten
-// kann. Nach einem Praeset-Sprung bleibt die weitere Navigation frei ueber
-// `set_camera` (kein Lock).
+// `set_view_preset` wendet stattdessen eines der fuenf `View3d`-Praesete
+// (front/top/side/iso/perspective) direkt ueber `math::preset_camera` an — Front/
+// Top/Side/Iso werden dabei ECHT orthografisch (`preset_camera`; Iso = echte
+// Isometrie ohne perspektivische Verzerrung), was eine reine TS-Orbit-Naeherung
+// nicht leisten 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).
@@ -114,11 +113,7 @@ 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],
-    meshes: &[MeshInput],
-) -> Option<([f32; 3], [f32; 3])> {
+fn model_bounds(walls: &[WallInput], slabs: &[SlabInput]) -> 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| {
@@ -151,17 +146,6 @@ fn model_bounds(
             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;
     }
@@ -262,7 +246,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, &model.meshes);
+        self.bounds = model_bounds(&model.walls, &model.slabs);
         self.renderer
             .upload_model(&self.device, &model.walls, &model.slabs, &model.meshes);
         // Wand-/Decken-Eingabe fuer den Live-Schnitt cachen (Klon, da der Renderer
@@ -315,15 +299,6 @@ 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,
@@ -340,32 +315,6 @@ 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],
@@ -377,30 +326,23 @@ impl WebModelRenderer {
             },
             fov_y,
             ortho_half_height,
-            far,
             ..Camera::default()
         };
     }
 
-    /// Wendet eines der Kardinal-/Iso-Kamera-Praesets der three.js-Sicht
-    /// (`front`/`back`/`top`/`side`/`left`/`iso`/`isoFrontLeft`/`isoBackRight`/
-    /// `isoBackLeft`/`perspective`, s. `View3d` in TopBar.tsx) auf das aktuelle
-    /// Modell an: Ziel = Modell-Mitte, Distanz = formatfuellend (mirror der
-    /// TS-`fitTargetDist`); alle Presets ausser Perspective werden orthografisch,
+    /// Wendet eines der fuenf Kamera-Praesets der three.js-Sicht
+    /// (`front`/`top`/`side`/`iso`/`perspective`, s. `View3d` in TopBar.tsx) auf
+    /// das aktuelle Modell an: Ziel = Modell-Mitte, Distanz = formatfuellend
+    /// (mirror der TS-`fitTargetDist`); Front/Top/Side/Iso 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!(
@@ -435,14 +377,11 @@ impl WebModelRenderer {
     ///  - `"shaded"`   — beleuchtete Bauteilfarben (Default).
     ///  - `"white"`    — Clay-Look: einheitlich helles Material, beleuchtet
     ///    (identisch zum bisherigen `set_render_mode_white(true)`).
-    ///  - `"textured"` — Material-Farbkarten je Wand-Band aus dem Textur-Array
-    ///    (`set_material_textures`), Fallback-Schachbrett fuer Baender ohne Material.
+    ///  - `"textured"` — mangels Textur-Pipeline VORERST identisch zu `"shaded"`
+    ///    behandelt (KEIN Fake-Stub); Platzhalter fuer eine spaetere Textur-Schicht.
     ///  - `"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> {
@@ -492,53 +431,6 @@ 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));

src-tauri/src/lib.rs

@@ -6,32 +6,6 @@
 #[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(
@@ -66,15 +40,7 @@ fn push_native_walls(walls: serde_json::Value) {
 
 #[cfg_attr(mobile, tauri::mobile_entry_point)]
 pub fn run() {
-    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| {
+    let builder = tauri::Builder::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"))]
@@ -86,16 +52,10 @@ pub fn run() {
     let builder = builder.invoke_handler(tauri::generate_handler![
         compute_joins,
         push_native_scene,
-        push_native_walls,
-        acquire_project_lock,
-        release_project_lock
+        push_native_walls
     ]);
     #[cfg(not(any(feature = "native2d", feature = "native3d")))]
-    let builder = builder.invoke_handler(tauri::generate_handler![
-        compute_joins,
-        acquire_project_lock,
-        release_project_lock
-    ]);
+    let builder = builder.invoke_handler(tauri::generate_handler![compute_joins]);
 
     builder
         .run(tauri::generate_context!())

src-tauri/src/lock.rs

@@ -1,145 +0,0 @@
-// 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()
-}

src-tauri/src/native.rs

@@ -344,12 +344,6 @@ 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]),

src-tauri/tauri.conf.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://schema.tauri.app/config/2",
-  "productName": "Dossier",
+  "productName": "cad",
   "version": "0.1.0",
   "identifier": "ch.dossier.cad",
   "build": {
@@ -10,14 +10,9 @@
   "app": {
     "windows": [
       {
-        "label": "main",
-        "title": "Dossier",
+        "title": "cad",
         "width": 1400,
-        "height": 900,
-        "dragDropEnabled": false,
-        "titleBarStyle": "Overlay",
-        "hiddenTitle": true,
-        "trafficLightPosition": { "x": 20, "y": 22 }
+        "height": 900
       }
     ],
     "security": {

src-tauri/trucksolid/Cargo.toml

@@ -1,42 +0,0 @@
-[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

src-tauri/trucksolid/src/boolean.rs

@@ -1,212 +0,0 @@
-// 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());
-    }
-}

src-tauri/trucksolid/src/lib.rs

@@ -1,546 +0,0 @@
-// 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");
-    }
-}

src/commands/cmds/arc.ts

@@ -1,166 +0,0 @@
-// 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(),
-};

src/commands/cmds/ceilingOpening.ts

@@ -1,133 +0,0 @@
-// 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(),
-};

src/commands/cmds/circle.ts

@@ -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(3)}m` };
+  if (at) draft.hud = { at, text: `r ${r.toFixed(2)} m` };
   return draft;
 }
 

src/commands/cmds/column.ts

@@ -1,152 +0,0 @@
-// 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(),
-};

src/commands/cmds/copy.ts

@@ -42,20 +42,10 @@ function targetFromFields(base: Vec2, locks: Record<string, number>, cursor: Vec
 }
 
 function hasSelection(sel: CommandSelection): boolean {
-  return (
-    sel.wallIds.length > 0 ||
-    sel.drawingId !== null ||
-    !!sel.extrudedSolidId ||
-    !!sel.columnId
-  );
+  return sel.wallIds.length > 0 || sel.drawingId !== null;
 }
 function toTransformSel(sel: CommandSelection): TransformSelection {
-  return {
-    wallIds: sel.wallIds,
-    drawingId: sel.drawingId,
-    extrudedSolidId: sel.extrudedSolidId,
-    columnId: sel.columnId,
-  };
+  return { wallIds: sel.wallIds, drawingId: sel.drawingId };
 }
 
 interface CopyBase extends CommandState {

src/commands/cmds/extrude.ts

@@ -1,287 +0,0 @@
-// 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(),
-};

src/commands/cmds/georef.test.ts

@@ -1,58 +0,0 @@
-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();
-  });
-});

src/commands/cmds/georef.ts

@@ -1,64 +0,0 @@
-// 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(),
-};

src/commands/cmds/import.ts

@@ -26,16 +26,6 @@ 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 }],

src/commands/cmds/line.test.ts

@@ -1,87 +0,0 @@
-/**
- * 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();
-  });
-});

src/commands/cmds/line.ts

@@ -10,7 +10,7 @@
 // Tool. Live-Vorschau + HUD (Länge/Winkel) wie die bestehenden Tools.
 
 import type { Drawing2D } from "../../model/types";
-import { segmentHud, uniqueId } from "../../tools/types";
+import { uniqueId } from "../../tools/types";
 import type {
   Command,
   CommandContext,
@@ -61,7 +61,14 @@ 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) draft.hud = segmentHud(a, cursor);
+  if (cursor && segLen(a, cursor) >= EPS) {
+    draft.hud = {
+      at: cursor,
+      text: `${segLen(a, cursor).toFixed(2)} m · ${Math.abs(
+        (segAngleDeg(a, cursor) + 360) % 360,
+      ).toFixed(0)}°`,
+    };
+  }
   return draft;
 }
 

src/commands/cmds/measure.test.ts

@@ -1,46 +0,0 @@
-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);
-  });
-});

src/commands/cmds/measure.ts

@@ -1,133 +0,0 @@
-// 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(),
-};

src/commands/cmds/mirror.ts

@@ -32,22 +32,12 @@ const EPS = 1e-6;
 
 /** Hat die Auswahl überhaupt etwas Spiegelbares? */
 function hasSelection(sel: CommandSelection): boolean {
-  return (
-    sel.wallIds.length > 0 ||
-    sel.drawingId !== null ||
-    !!sel.extrudedSolidId ||
-    !!sel.columnId
-  );
+  return sel.wallIds.length > 0 || sel.drawingId !== null;
 }
 
 /** Auswahl → TransformSelection (gleiche Form). */
 function toTransformSel(sel: CommandSelection): TransformSelection {
-  return {
-    wallIds: sel.wallIds,
-    drawingId: sel.drawingId,
-    extrudedSolidId: sel.extrudedSolidId,
-    columnId: sel.columnId,
-  };
+  return { wallIds: sel.wallIds, drawingId: sel.drawingId };
 }
 
 // Zustand: erst ersten Achsenpunkt setzen, dann den zweiten (mit Auswahl-Snapshot).

src/commands/cmds/move.ts

@@ -49,22 +49,12 @@ 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 ||
-    !!sel.extrudedSolidId ||
-    !!sel.columnId
-  );
+  return sel.wallIds.length > 0 || sel.drawingId !== null;
 }
 
 /** Auswahl → TransformSelection (gleiche Form). */
 function toTransformSel(sel: CommandSelection): TransformSelection {
-  return {
-    wallIds: sel.wallIds,
-    drawingId: sel.drawingId,
-    extrudedSolidId: sel.extrudedSolidId,
-    columnId: sel.columnId,
-  };
+  return { wallIds: sel.wallIds, drawingId: sel.drawingId };
 }
 
 // Zustand: erst Basispunkt setzen, dann Ziel (mit Auswahl-Snapshot vom Start).

src/commands/cmds/opening.ts

@@ -187,12 +187,6 @@ 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",
@@ -203,7 +197,6 @@ 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 }
       : {}),

src/commands/cmds/polyline.ts

@@ -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 { segmentHud, uniqueId } from "../../tools/types";
+import { uniqueId } from "../../tools/types";
 import type {
   Command,
   CommandContext,
@@ -74,7 +74,14 @@ 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) draft.hud = segmentHud(last, cursor);
+  if (cursor && last && segLen(last, cursor) >= EPS) {
+    draft.hud = {
+      at: cursor,
+      text: `${segLen(last, cursor).toFixed(2)} m · ${Math.abs(
+        (segAngleDeg(last, cursor) + 360) % 360,
+      ).toFixed(0)}°`,
+    };
+  }
   return draft;
 }
 

src/commands/cmds/rect.ts

@@ -17,7 +17,7 @@
 // werden (die Engine löst `r…` relativ zu lastPoint auf).
 
 import type { Drawing2D } from "../../model/types";
-import { deltaHud, segmentHud, uniqueId } from "../../tools/types";
+import { uniqueId } from "../../tools/types";
 import type {
   Command,
   CommandContext,
@@ -196,47 +196,51 @@ function rectGeom(a: Vec2, b: Vec2): { min: Vec2; max: Vec2 } {
 
 // ── Vorschau ─────────────────────────────────────────────────────────────────
 
-function corners4Draft(pts: Vec2[], hud: ToolDraft["hud"] | null): ToolDraft {
+function corners4Draft(pts: Vec2[], hudAt: Vec2 | null, hudText: string): ToolDraft {
   const preview: DraftShape[] = [{ kind: "poly", pts, closed: true }];
   const draft: ToolDraft = { preview, vertices: [pts[0]] };
-  if (hud) draft.hud = hud;
+  if (hudAt) draft.hud = { at: hudAt, text: hudText };
   return draft;
 }
 
-/** Vorschau des 2-Punkt-Rechtecks (achsparallel) — HUD zeigt die Diagonale a→cursor. */
+/** Vorschau des 2-Punkt-Rechtecks (achsparallel). */
 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 }];
-  return corners4Draft(pts, segLen(a, cursor) >= EPS ? deltaHud(a, cursor) : null);
+  const w = g.max.x - g.min.x;
+  const h = g.max.y - g.min.y;
+  return corners4Draft(pts, cursor, `${w.toFixed(2)} × ${h.toFixed(2)} m`);
 }
 
-/** Vorschau des Zentrum-Rechtecks (achsparallel) — HUD zeigt die Diagonale center→cursor. */
+/** Vorschau des Zentrum-Rechtecks (achsparallel). */
 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 }];
-  return corners4Draft(
-    pts,
-    segLen(center, cursor) >= EPS
-      ? { at: cursor, dx: 2 * (cursor.x - center.x), dy: 2 * (cursor.y - center.y) }
-      : null,
-  );
+  const w = g.max.x - g.min.x;
+  const h = g.max.y - g.min.y;
+  return corners4Draft(pts, cursor, `${w.toFixed(2)} × ${h.toFixed(2)} m`);
 }
 
 /** 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] };
-  return { preview: [{ kind: "line", a, b: cursor }], vertices: [a], hud: segmentHud(a, cursor) };
+  const draft: ToolDraft = { preview: [{ kind: "line", a, b: cursor }], vertices: [a] };
+  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) — HUD: Basisbreite + Höhe am Cursor. */
+/** Vorschau des gedrehten Rechtecks (3-Punkt, zweiter Teil). */
 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, { at: cursor, text: `B: ${w.toFixed(3)}m    H: ${h.toFixed(3)}m` });
+  return corners4Draft(pts, cursor, `${w.toFixed(2)} × ${h.toFixed(2)} m`);
 }
 
 // ── Commit ───────────────────────────────────────────────────────────────────

src/commands/cmds/roof.ts

@@ -1,173 +0,0 @@
-// 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(),
-};

src/commands/cmds/sectionline.test.ts

@@ -1,100 +0,0 @@
-// 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");
-  });
-});

src/commands/cmds/sectionline.ts

@@ -1,213 +0,0 @@
-// 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 };

src/commands/cmds/stair.tread.test.ts

@@ -1,85 +0,0 @@
-/**
- * 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);
-    }
-  });
-});

src/commands/cmds/stair.ts

@@ -4,12 +4,9 @@
 //      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, IMMER sichtbar): Grundform gerade/L/Wendel, Auf-/Ab-
-// Umschalter, Referenz (links/mitte/rechts), Trittmass-Modus (mit/ohne).
-// 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, …).
+// Optionen (togglebar): Grundform gerade/L/Wendel (Auf-/Ab-Umschalter). Tab-Felder
+// im Laufschritt: Breite / Stufenanzahl / Steighöhe (totalRise). Live-Vorschau
+// zeigt die Tritt-Linien + die Lauflinie.
 //
 // Herkunft der Treppen-Felder (CommandContext):
 //   • floorId     ← ctx.level.id (aktives Geschoss)
@@ -20,7 +17,7 @@
 // Bezeichner englisch, sichtbarer Text via t() (CONVENTIONS.md).
 
 import type { Stair, StairShape, Vec2 as MVec2 } from "../../model/types";
-import { stairGeometry, defaultStepCount, IDEAL_TREAD, MIN_STEPS } from "../../geometry/stair";
+import { stairGeometry, defaultStepCount } from "../../geometry/stair";
 import { uniqueId } from "../../tools/types";
 import type {
   Command,
@@ -41,35 +38,6 @@ 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 => {
@@ -97,45 +65,21 @@ function floorRise(ctx: CommandContext): number {
   return ctx.level.floorHeight && ctx.level.floorHeight > 0 ? ctx.level.floorHeight : 2.6;
 }
 
-// ── Trittmass-Ableitung ───────────────────────────────────────────────────────
-/**
- * Leitet die Stufenzahl aus Auftritt (Soll-Trittmass) + Lauflänge ab.
- * Klemmt auf [MIN_STEPS, maxByRun] (mind. 0.24 m Auftrittstiefe).
- * 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));
-}
+/** Tab-Felder im Laufschritt: Breite / Stufenanzahl / Steighöhe. */
+const RUN_FIELDS: CommandField[] = [
+  { id: "width", labelKey: "cmd.field.width" },
+  { id: "steps", labelKey: "cmd.stair.stepsField" },
+  { id: "rise", labelKey: "cmd.stair.riseField" },
+];
 
-// ── 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
 }
@@ -144,9 +88,6 @@ 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;
@@ -154,30 +95,14 @@ interface StairRun extends CommandState {
 }
 type StairCmdState = StairIdle | StairRun;
 
-/** Neuer Ruhezustand aus den modulweiten Defaults (oder überschrieben). */
-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,
-  };
+function initState(shape: StairShape = "straight"): StairIdle {
+  return { phase: "start", lastPoint: null, shape, up: true, width: DEF_WIDTH, steps: null, rise: null };
 }
 
 /**
  * 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);
@@ -185,15 +110,7 @@ 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;
-
-  // 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 steps = s.steps ?? defaultStepCount(rise, runLength);
   const base: Stair = {
     id: uniqueId("ST"),
     type: "stair",
@@ -204,7 +121,6 @@ function buildStair(s: StairRun, ctx: CommandContext): Stair {
     dir,
     runLength,
     width: s.width,
-    referenz: s.referenz,
     totalRise: rise,
     stepCount: steps,
     up: s.up,
@@ -240,42 +156,18 @@ function runDraft(s: StairRun, ctx: CommandContext): ToolDraft {
   return draft;
 }
 
-/** Hängt eine Treppe ans Projekt (immutabel) und aktualisiert die Defaults. */
+/** Hängt eine Treppe ans Projekt (immutabel). */
 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: from.shape,
-    up: from.up,
-    width: from.width,
-    referenz: from.referenz,
-    treadMode: from.treadMode,
-    auftritt: from.auftritt,
-    steps: from.steps,
-    rise: from.rise,
-  } : undefined),
+  initState(from?.shape ?? "straight"),
   { 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",
@@ -285,20 +177,14 @@ 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(),
+  init: (): StairIdle => initState("straight"),
 
   onInput: (state, input, ctx): [CommandState, CommandResult] => {
     const s = state as StairCmdState;
@@ -309,12 +195,6 @@ 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 }];
     }
@@ -331,9 +211,6 @@ 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,
@@ -372,50 +249,20 @@ export const stairCommand: Command = {
   },
   onCancel: (state): [CommandState, CommandResult] => idle(state as StairCmdState),
 
-  /**
-   * 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. */
+  fields: (state) => ((state as StairCmdState).phase === "run" ? RUN_FIELDS : []),
+  // 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 (s.phase === "run") {
-      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;
-      }
-    }
+    if ("steps" in locks && locks.steps >= 2) 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.phase === "run") {
-      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;
-      }
-    }
+    if (s.steps != null) out.steps = s.steps;
+    if (s.rise != null) out.rise = s.rise;
     return out;
   },
 };

src/commands/cmds/text.ts

@@ -1,76 +0,0 @@
-// 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(),
-};

src/commands/cmds/textbox.ts

@@ -1,127 +0,0 @@
-// 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(),
-};

src/commands/cmds/wall.test.ts

@@ -1,87 +0,0 @@
-/**
- * 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();
-  });
-});

src/commands/cmds/wall.ts

@@ -18,7 +18,7 @@
 import type { Wall, WallType } from "../../model/types";
 import { wallTypeThickness } from "../../model/types";
 import { wallCorners } from "../../model/geometry";
-import { segmentHud, uniqueId } from "../../tools/types";
+import { uniqueId } from "../../tools/types";
 import type {
   Command,
   CommandContext,
@@ -164,7 +164,14 @@ 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) draft.hud = segmentHud(last, cursor);
+  if (cursor && last && segLen(last, cursor) >= EPS) {
+    draft.hud = {
+      at: cursor,
+      text: `${segLen(last, cursor).toFixed(2)} m · ${Math.abs(
+        (segAngleDeg(last, cursor) + 360) % 360,
+      ).toFixed(0)}°`,
+    };
+  }
   return draft;
 }
 

src/commands/engine.ts

@@ -328,14 +328,6 @@ 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

src/commands/registry.ts

@@ -10,27 +10,17 @@ 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> = {
@@ -40,30 +30,19 @@ 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,
 };
 
 /**
@@ -82,23 +61,12 @@ 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",
@@ -106,14 +74,9 @@ 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). */

src/commands/types.ts

@@ -15,12 +15,11 @@ 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" | "text" | "selection";
+export type AcceptKind = "point" | "number" | "option" | "selection";
 
 /**
  * Geparste, noch nicht aufgelöste Roh-Eingabe aus der Command-Line bzw. der
@@ -68,10 +67,6 @@ 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). */

src/engine/truckSolid.ts

@@ -1,70 +0,0 @@
-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;
-}

src/export/exportDxf.ts

@@ -28,10 +28,6 @@ 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).
@@ -64,8 +60,6 @@ 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-
@@ -74,15 +68,11 @@ 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") {

src/export/exportIfc.test.ts

@@ -1,370 +0,0 @@
-// 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([]);
-  });
-});