2D-Plan-Renderer auf WebGL2 (GPU) + akkumulierter Funktionsstand

Neuer GPU-Renderer fuer den Grundriss (src/plan/glPlan/): Earcut-Tessellierung (konkav-faehig), gehrte Linienzuege (Miter), echte Papier-mm-Strichbreiten im Massstab (repliziert den SVG-printStrokeVb-Pfad), Hybrid mit scharfem SVG-Text- Overlay. GPU ist der Standardpfad; der SVG-Renderer bleibt automatischer Fallback, falls WebGL2/Shader nicht verfuegbar sind. Imperativer Pan (rAF + CSS-transform) fuer fluessige Interaktion ohne React-Re-Render je Frame. Enthaelt zudem den bisher nicht committeten Arbeitsstand des Browser-BIM (Oeffnungen, Treppen, Raeume, Decken, DXF-Export, Materialbibliothek, Kontext- Import, Tauri-Compute-Boundary-PoC).
2026-07-02 00:12:39 +02:00
parent 7b3b597abc
commit 8fd8987b70
184 changed files with 29421 additions and 669 deletions
@@ -0,0 +1,175 @@
+# HAUPTINSTANZ-BRIEFING: Tauri + wgpu (Korrigiert)
+
+**Stand:** 2026-07-01 — **KORREKTUR** (vorherige Dokumente waren unvollständig)
+
+---
+
+## Die Entscheidung (FINAL)
+
+**Browser-CAD (alt) → Desktop Tauri-App mit Rust-Backend + wgpu-Rendering (neu)**
+
+| Aspekt | Alt | Neu |
+|---|---|---|
+| **App-Form** | Browser-Tab | Desktop Tauri-Window |
+| **Frontend** | React/Vite (TS) | React/Vite (TS) — UNVERÄNDERT |
+| **2D-Rendering** | SVG-Plan | SVG-Plan — UNVERÄNDERT |
+| **3D-Rendering** | three.js/WebGL | **wgpu** (Vulkan/Metal/DX12) |
+| **Rechenintensive Ops** | TS in Browser | **Rust im Backend** |
+| **Betriebssystem** | cross-platform browser | Windows/macOS/Linux Desktop App |
+
+---
+
+## Warum dieser Umstieg?
+
+**Problem mit three.js/WebGL:**
+- komplexe Möbel = 100k+ Polygone
+- mehrere parallele Ops (kernel2d, bool-Ops, DXF-Parser, SIA-Raumerkennung)
+- WebGL hat harte Limits (GPU VRAM, draw calls, single-threaded)
+- → Laggy, nicht skalierbar für Professional CAD
+
+**Lösung: Tauri + wgpu + Rust**
+- **wgpu** = low-level GPU API (direkt zu Vulkan/Metal/DX12, nicht WebGL)
+- **Rust** = rechenintensive Ops parallelisiert + native performance
+- **Desktop** = native App, nicht Browser (bessere Kontrolle, bessere Perf)
+- **React-Frontend bleibt** = UI/Sketching/Panels unverändert (wgpu nur für 3D-Display)
+
+---
+
+## Der neue Stack (FINAL)
+
+```
+┌─────────────────────────────────────────────────────┐
+│ Desktop Tauri-Window                                │
+├─────────────────────────────────────────────────────┤
+│                                                     │
+│  React/Vite (UI-Shell, State, Panels)              │
+│  ├─ SVG 2D-Plan (Grundriss)                        │
+│  └─ wgpu 3D-Viewport (3D-Ansicht + Rendering)      │
+│                                                     │
+│              ↓ invoke (IPC) ↓                       │
+│                                                     │
+│  Rust-Backend (src-tauri/)                         │
+│  ├─ computeJoins() — Wand-Eckverbindungen          │
+│  ├─ kernel2d() — Offset/Trim/Extend/…             │
+│  ├─ parseShapeFromDwg() — Geometrie-Import         │
+│  ├─ detectRooms() — SIA-Raumerkennung              │
+│  └─ booleanOps() — Union/Differenz/Schnitt         │
+│                                                     │
+└─────────────────────────────────────────────────────┘
+```
+
+**Nicht verändert:**
+- App.tsx, state/, commands/, panels/, model/types.ts
+- UI-Logik, Befehlssystem, Sketching-Tools
+
+**Neu/geändert:**
+- `src-tauri/` — Rust-Crate für Backend
+- `src/compute/index.ts` — Boundary (invoke + TS-Fallback)
+- Rendering-Engine: **three.js → wgpu**
+- Build: `npm run tauri:build` statt `npm run build`
+
+---
+
+## Die Aufgabe (vier Agents)
+
+**Siehe: `docs/design/tauri-migration-plan.md`**
+
+Vier parallele Agents:
+
+1. **Agent: Tauri-Shell Setup** → `src-tauri/` + Cargo.toml + main.rs (Tauri window registrieren)
+2. **Agent: Compute-Boundary (TS)** → `src/compute/index.ts` (invoke-Wrapper + TS-Fallbacks)
+3. **Agent: Rust compute_joins Impl** → `src-tauri/src/geometry.rs` (erste Op, Proof-of-Concept)
+4. **Agent: Vite/Package-Integration** → vite.config.ts + package.json (Tauri-Plugins, scripts)
+
+**Deliverable:** lauffähige Desktop-App, wand-Edit triggert Rust-Op, Output identisch TS-Version.
+
+---
+
+## Dev-Workflow (post-Tauri)
+
+```bash
+# Dev: Terminal 1 (Vite)
+npm run dev  # localhost:5173
+
+# Dev: Terminal 2 (Tauri)
+npm run tauri:dev  # öffnet Desktop-Window, zeigt auf localhost:5173
+
+# Build
+npm run tauri:build  # → Windows .exe / macOS .app / Linux .deb
+```
+
+---
+
+## Rendering: three.js → wgpu (Wichtig!)
+
+**3D-Viewport wird NEU implementiert in wgpu:**
+- Nicht: "drei.js mit Rust-Fallback"
+- **Ja:** wgpu als native GPU-Renderer (skaliert auf 100k+ Polygone)
+
+**2D-Plan bleibt SVG** (keine Änderung).
+
+**Timeline für wgpu-Impl:**
+- Milestone 1 (jetzt): Tauri-Shell + Rust-Compute-Ops
+- Milestone 2 (nächst): wgpu 3D-Viewport-Impl (ersetzt drei.js/WebGL)
+- Milestone 3: Live clipping/sectioning in wgpu
+
+---
+
+## Migration-Reihenfolge
+
+**Phase 1 (Tauri-Shell + Proof-of-Concept):**
+- [ ] `computeJoins` (Wand-Ecken) → Rust
+
+**Phase 2 (Rendering-Umbau):**
+- [ ] wgpu Viewport-Impl (ersetzt drei.js)
+- [ ] Instancing/LOD für Möbel-Geometrie
+
+**Phase 3 (weitere Ops):**
+- [ ] `kernel2d` (Offset/Trim) → Rust
+- [ ] DXF/DWG-Parser → Rust
+- [ ] detectRooms → Rust
+- [ ] booleanOps → Rust
+
+---
+
+## Was sich NICHT ändert
+
+- `src/App.tsx`, `src/state/`, `src/commands/`
+- UI-Panels, Zeichenwerkzeuge, Befehlssystem
+- Semantisches Modell (types.ts)
+- i18n, Styling
+
+## Was ändert sich
+
+- **Engine:** three.js/WebGL → wgpu
+- **Backend:** TS-Only → Tauri + Rust
+- **Distribution:** Browser → Desktop App
+- **Build-Prozess:** `npm run build` → `npm run tauri:build`
+
+---
+
+## Fehlerquellen (zur Klarheit)
+
+❌ **FALSCH:** "Wir bleiben bei three.js"  
+✅ **RICHTIG:** "three.js → wgpu, Rust-Compute + Desktop Tauri"
+
+❌ **FALSCH:** "Tauri + three.js als Frontend-Engine"  
+✅ **RICHTIG:** "Tauri-Shell + React UI + wgpu 3D-Rendering + Rust-Compute"
+
+---
+
+## Nächste Schritte (für Hauptinstanz)
+
+1. **Lesen:** `docs/design/tauri-migration-plan.md` (technisch, konkret)
+2. **Spawn:** vier Agents (parallel, unabhängig)
+3. **Verifizieren:** `npm run tauri:dev` → App läuft, erste Op in Rust funktioniert
+4. **Aktualisieren:** HANDOVER.md mit Milestone-1-Status
+
+---
+
+## Fragen?
+
+- **"Warum Desktop statt Browser?"** → Skalierbarkeit (native GPU + Rust-Compute)
+- **"Warum wgpu statt drei.js?"** → wgpu skaliert auf 100k+ Polygone, three.js/WebGL hat Limits
+- **"Bleibt React?"** → Ja, React/Vite UI bleibt, nur 3D-Engine wechselt
+- **"Wann ist wgpu-Impl fertig?"** → Milestone 2 (nach Tauri-Shell)
@@ -0,0 +1,306 @@
+# Architektur-Pivot: Tauri + Rust-Backend (2026-07-01)
+
+## Entscheidung
+
+**Alte Welt:** Browser-CAD (React/Vite + WebGL/three.js)  
+**Neue Welt:** Desktop Tauri-App (React/Vite Frontend + Rust-Backend + **wgpu 3D-Rendering**)
+
+**Grund:** Komplexe Möbel mit vielen Polygonen (100k+) + mehrere parallele rechenintensive Ops → WebGL/three.js wird zum Bottleneck. **wgpu** (low-level GPU-API auf Vulkan/Metal/DX12) + Rust-Compute skaliert native.
+
+**Scope:** Desktop-only Release (Milestone 1). WASM-Fallback für Browser später wenn gebraucht.
+
+---
+
+## Post-Migration Stack
+
+### Frontend (React/Vite — Komponenten + State, unverändert)
+
+```
+src/
+  App.tsx                    ← Shell-Komponente
+  compute/index.ts           ← Compute-Boundary (neu)
+  model/types.ts             ← Semantisches Modell
+  commands/                  ← Befehlssystem
+  panels/                    ← UI-Panels
+  plan/PlanView.tsx          ← 2D-SVG-Rendering
+  viewport/Viewport3D.tsx    ← three.js 3D-Display
+  ui/                        ← Topbar, Dialogs, etc.
+  state/                     ← Redux-Slices (project, selection, view, layout)
+  ...
+```
+
+**Rolle:** User-Input-Handling, 2D/3D-Darstellung (Display-Layer), State-Management.
+
+### Backend (Rust/Tauri — neu)
+
+```
+src-tauri/
+  src/
+    main.rs                  ← Tauri window + invoke-handler registration
+    geometry.rs              ← compute_joins(), kernel2d(), etc.
+    parsers/
+      dwg.rs                 ← DXF/DWG-Geometrie-Parsing
+      dxf.rs
+    sia/
+      room_detection.rs      ← detectRooms() (SIA-416)
+    ...
+  Cargo.toml                 ← Dependencies (serde, tauri, …)
+```
+
+**Rolle:** Rechenintensive Ops, Geometrie-Kernel, Parsing, SIA-Raumerkennung.
+
+### IPC: Tauri invoke (async, serde)
+
+```typescript
+// Frontend ruft Rust auf
+const result = await invoke<JoinInfo[]>('compute_joins', { walls, joints });
+
+// Rust bearbeitet + serialisiert Ergebnis
+#[tauri::command]
+async fn compute_joins(input: JoinInput) -> Result<JoinOutput, String> {
+  geometry::compute_joins(input).map_err(|e| e.to_string())
+}
+```
+
+---
+
+## Compute-Boundary (Key Design)
+
+**Neue Datei:** `src/compute/index.ts` — einziger Eingang für rechenintensive Ops.
+
+```typescript
+// Beispiel-Schnittstellen
+export async function computeJoins(walls: Wall[], joints: Array<[number, number]>): Promise<JoinInfo[]> { … }
+export async function computeKernel2D(op: 'offset'|'trim', geom: Polyline, …): Promise<Polyline[]> { … }
+export async function detectRooms(…): Promise<Room[]> { … }
+export async function parseShapeFromDwg(…): Promise<DwgGeometry> { … }
+```
+
+**Hinter der Boundary:**
+1. Versuche Tauri invoke zu Rust (`#[tauri::command]`)
+2. Fallback auf lokale TS-Impl wenn Rust nicht verfügbar (während Migration)
+
+**Effekt:** Aufrufort im Code bleibt stabil; Caller sieht nicht, ob Op schon in Rust ist oder noch TS.
+
+**Migrationsfluss:**
+```
+1. TS-Impl existiert (z.B. src/model/joins.ts)
+2. Neue Op in Compute-Boundary mit Invoke+Fallback
+3. Parallel: Rust-Impl in src-tauri/src/geometry.rs
+4. Tests: Rust-Output == TS-Output (Parität)
+5. TS-Impl bleibt (Fallback, wird nicht entfernt bis Rust stable)
+6. Eventuell: TS-Impl löschen wenn Rust bewährt
+```
+
+---
+
+## Dev-Workflow (post-Tauri)
+
+### Development
+
+```bash
+# Terminal 1: Vite dev-server
+npm run dev  # localhost:5173
+
+# Terminal 2: Tauri dev
+npm run tauri:dev  # öffnet Tauri-Fenster, zeigt auf localhost:5173
+                    # Rust hot-reload + TS hot-reload gleichzeitig
+```
+
+**Voraussetzungen:**
+- Node.js + npm (wie heute)
+- Rust + Cargo (neu)
+- Tauri CLI: `npm install -D @tauri-apps/cli`
+
+### Build
+
+```bash
+# Single command
+npm run tauri:build
+
+# Erzeugt: 
+# - Windows: src-tauri/target/release/cad.exe
+# - macOS: src-tauri/target/release/bundle/macos/cad.app
+# - Linux: src-tauri/target/release/bundle/deb/cad_*.deb (oder Flatpak)
+```
+
+### Testing
+
+```bash
+# Rust-Unit-Tests
+cargo test  # in src-tauri/
+
+# TS-Tests (unverändert)
+npm run test
+
+# Integration-Test: App starten + Aktion prüfen
+npm run tauri:dev  # manuell testen oder Puppeteer-Probe erweitern
+```
+
+---
+
+## GPU-Strategy (für später)
+
+**Milestone 1 (jetzt):** CPU-Ops in Rust (kernel2d, joins, parsing, SIA).
+
+**Milestone 2 (später):** GPU-Compute via wgpu
+- Tauri + wgpu Renderer (optional, nicht erforderlich)
+- ODER drei.js bleibt, Rust handelt CPU-Ops, three.js handelt Display
+- GPU-Heavy-Ops (z.B. große Boolean-Operationen) können in wgpu laufen, aber MVP braucht das nicht
+
+**Aktueller Plan:** three.js bleibt für 3D-Display (skaliert ausreichend für Möbel-Geometrie mit Instancing + LOD).
+
+---
+
+## Migration Strategy: Ops nach Priorisierung
+
+**Phase 1 (aktuell — Tauri-Shell + Proof-of-Concept):**
+- [ ] `computeJoins` (Wand-Eckverbindungen) → Rust
+  - Gründe: klein, häufig, zeigt invoke-Flow
+
+**Phase 2 (nächst):**
+- [ ] `kernel2d` (Offset/Trim/Extend/Fillet) → Rust
+  - Gründe: Rechenlast ⭐⭐, Frequenz hoch
+- [ ] DXF/DWG-Parser → Rust (Geometrie-Extraktion)
+  - Gründe: Rechenlast ⭐⭐, Frequenz mittel (Import-Dialog)
+
+**Phase 3 (später):**
+- [ ] `detectRooms` (SIA-416 Raumerkennung) → Rust
+  - Gründe: Rechenlast ⭐, async-freundlich
+- [ ] `booleanOps` (Union/Differenz/Schnitt) → Rust
+  - Gründe: Rechenlast ⭐⭐, Frequenz gering (ad-hoc)
+
+---
+
+## Folgen für bestehenden Code
+
+### Was ändert sich NICHT
+
+- `src/model/types.ts` — semantisches Modell bleibt in TS (Frontend kennt es)
+- `src/state/` — Redux-Store unverändert
+- `src/ui/` — Komponenten unverändert
+- `src/plan/PlanView.tsx` — SVG-Rendering unverändert
+- `src/viewport/Viewport3D.tsx` — three.js-Rendering unverändert
+- `src/commands/` — Befehlssystem unverändert
+
+### Was ändert sich
+
+- **Neue `src/compute/index.ts`** — alle rechenintensiven Ops laufen durch hier
+- **Neue `src-tauri/`** — Rust-Backend
+- **Vite-Config:** Tauri plugin hinzufügen
+- **Package.json:** tauri scripts hinzufügen
+- **Build-Prozess:** `npm run tauri:build` statt `npm run build`
+
+### Was wird migriert (schrittweise)
+
+- `src/model/joins.ts` → `src-tauri/src/geometry.rs` (Phase 1)
+- `src/geometry/kernel2d.ts` → `src-tauri/src/geometry.rs` (Phase 2)
+- `src/io/{dxfParser, dwgParser}.ts` → `src-tauri/src/parsers/` (Phase 2)
+- `src/geometry/{roomArea, roomBoundary}.ts` → `src-tauri/src/sia/room_detection.rs` (Phase 3)
+- `src/editors/booleanOps.ts` → `src-tauri/src/geometry.rs` (Phase 3)
+
+**Wichtig:** TS-Versionen bleiben als Fallback (nicht gelöscht).
+
+---
+
+## Distribution (später)
+
+### Desktop Binaries (post-Tauri)
+
+- **Windows:** `.exe` (standalone executable)
+- **macOS:** `.app` bundle (code-signed)
+- **Linux:** `.deb` package ODER **Flatpak** (preferred)
+  - Flatpak = moderne WebKitGTK6 immer dabei, unabhängig von Distro-Alter
+
+### Browser (wenn gebraucht)
+
+- **WASM-Fallback** für `src/compute/` Ops (Rust → WASM via wasm-bindgen)
+- Later-phase feature, nicht Milestone 1
+
+---
+
+## Technische Details
+
+### Serialisierung (TS ↔ Rust)
+
+**serde + serde_json** für Geometrie-Typen:
+
+```rust
+// Rust
+#[derive(Serialize, Deserialize)]
+pub struct Vec2 { pub x: f64, pub y: f64 }
+
+#[derive(Serialize, Deserialize)]
+pub struct Wall {
+    pub id: String,
+    pub start: Vec2,
+    pub end: Vec2,
+    // …
+}
+```
+
+```typescript
+// TS (type-safe invoke)
+interface Vec2 { x: number; y: number }
+interface Wall { id: string; start: Vec2; end: Vec2; /* … */ }
+
+await invoke<JoinInfo[]>('compute_joins', { walls: Wall[] })
+```
+
+### Tauri Security (default)
+
+- Invoke-Handler sind Rust-side validiert
+- Whitelist-Makro (`#[tauri::command]`) registered nur explizit erlaubte Functions
+- CORS/CSP Policy default secure
+- Keine arbitrary-Script-Execution (native app)
+
+---
+
+## Abhängigkeiten (neu post-Tauri)
+
+### Frontend (npm)
+- Bestehende: react, vite, three.js, redux, etc.
+- Neu: `@tauri-apps/api` (JS-SDK für invoke)
+- Optional später: `@tauri-apps/cli` dev-dependency (bereits in package.json)
+
+### Backend (Cargo)
+```toml
+[dependencies]
+tauri = { version = "2", features = ["webkit2gtk-6.0"] }  # GTK4
+serde = { version = "1.0", features = ["derive"] }
+serde_json = "1.0"
+# später: wgpu, delaunator, opencascade-sys, etc.
+```
+
+### System
+- Rust 1.70+
+- GTK4 dev libraries (Linux only, auto-handled by Tauri)
+- Xcode Command Line Tools (macOS, auto-checked)
+
+---
+
+## Next Steps (Koordination)
+
+**Aufgabe für nächste Phase:**
+→ Siehe `docs/design/tauri-migration-plan.md` (Schritt-für-Schritt, vier parallele Agents)
+
+**HANDOVER.md:** wird aktualisiert nach Tauri-Shell stabil.
+
+---
+
+## FAQ
+
+**Q: Läuft die App noch im Browser?**  
+A: Nein (Milestone 1). Desktop-only. WASM-Fallback für Browser später wenn gebraucht.
+
+**Q: Was passiert mit dem existing TS-Code?**  
+A: Bleibt unverändert (außer neue Compute-Boundary). TS-Implementierungen = Fallback bis Rust stabil.
+
+**Q: Muss ich Rust können um das Projekt zu verstehen?**  
+A: Nein. Frontend bleibt React/TS. Rust ist "blackbox" hinter invoke. Aber bei Rust-Bugs muss man rein.
+
+**Q: Wann ist Tauri-Shell fertig?**  
+A: Nach den vier Agents (Schritt 1–4 in tauri-migration-plan.md), ~1–2 Wochen.
+
+**Q: Kann ich lokal testen?**  
+A: Ja, `npm run tauri:dev` öffnet lokale App. Alles wie heute, nur Rust hinten dran.
@@ -0,0 +1,243 @@
+# Tauri-Migration + Compute-Boundary — Aufgabe für nächste Instanz
+
+**Entscheidung (fix, 2026-07-01):** Browser-CAD → **Desktop Tauri-App mit Rust-Backend + wgpu-Rendering.**
+
+**Grund:** komplexe Möbel mit vielen Polygonen (100k+) + mehrere parallele rechenintensive Ops → WebGL/three.js wird zum Blocker. **wgpu** (low-level GPU-API) + Rust-Compute skaliert native.
+
+**Scope:** Desktop-only Release (Milestone 1). WASM-Fallback für Browser später wenn gebraucht.
+
+**Rendering-Engine:** three.js → **wgpu** (Milestone 2)
+
+---
+
+## Aufgabe: Shell aufsetzen + Compute-Boundary + erste Op migrieren
+
+### Schritt 0 — Compute-Boundary (TS-Kontrakt)
+
+**Neu:** `src/compute/index.ts` — die einzige Stelle, durch die alle rechenintensiven Ops laufen.
+
+```typescript
+// src/compute/index.ts — einheitliche Schnittstelle
+export async function computeKernel2D(op: 'offset'|'trim', …): Promise<Polyline[]> { … }
+export async function detectRooms(…): Promise<Room[]> { … }
+export async function computeJoins(…): Promise<JoinInfo[]> { … }  // ← erste Op
+export async function parseShapeFromDwg(…): Promise<DwgGeometry> { … }
+```
+
+**Hinter der Boundary:**
+- Erst Tauri-invoke zu Rust `#[tauri::command]`
+- Fallback auf lokale TS-Impl (bleibt unberührt, bis Rust stabil)
+- `catch(err) → console.warn('Rust failed, using TS fallback'); return tsImpl(…)`
+
+**Effekt:** Aufrufort im Code bleibt stabil; Caller sieht nicht, ob Op schon in Rust ist oder noch TS.
+
+---
+
+### Schritt 1 — Tauri-Shell aufsetzen
+
+**Struktur:**
+```
+repo/
+  src-tauri/              ← neue Rust-Seite (Tauri-Konvention)
+    src/
+      main.rs             ← Tauri window + invoke handlers
+      geometry.rs         ← compute_joins() + weitere Ops später
+      ...
+    Cargo.toml
+  src/                    ← React/TS (unverändert)
+    compute/
+      index.ts            ← Compute-Boundary
+    ...
+  vite.config.ts          ← Tauri plugin integrieren
+  package.json            ← tauri scripts
+```
+
+**Setup:**
+1. `cargo init --name cad-tauri src-tauri` (oder `src-tauri` manuell anlegen)
+2. `Cargo.toml`: Tauri v2 einbinden mit Feature `webkit2gtk-6.0` (GTK4)
+   ```toml
+   [dependencies]
+   tauri = { version = "2", features = ["webkit2gtk-6.0"] }
+   serde = { version = "1.0", features = ["derive"] }
+   serde_json = "1.0"
+   ```
+3. `src-tauri/src/main.rs`: Minimal-Fenster, invoke-Handler registrieren
+   ```rust
+   #[tauri::command]
+   async fn compute_joins(input: JoinInput) -> Result<JoinOutput, String> {
+       // Rust-Impl
+       geometry::compute_joins(input).map_err(|e| e.to_string())
+   }
+
+   #[cfg_attr(mobile, tauri::mobile_entry_point)]
+   pub fn run() {
+       tauri::Builder::default()
+           .invoke_handler(tauri::generate_handler![compute_joins])
+           .run(tauri::generate_context!())
+           .expect("error while running tauri application");
+   }
+   ```
+4. `vite.config.ts`: Tauri plugin + dev-server-Integration
+   ```typescript
+   import { defineConfig } from 'vite'
+   import react from '@vitejs/plugin-react'
+   export default defineConfig({
+     plugins: [react()],
+     server: { port: 5173 }  // Tauri dev zeigt hier drauf
+   })
+   ```
+5. `package.json`: Tauri scripts hinzufügen
+   ```json
+   "scripts": {
+     "tauri": "tauri",
+     "tauri:dev": "tauri dev",
+     "tauri:build": "tauri build"
+   }
+   ```
+
+---
+
+### Schritt 2 — Erste Op migrieren: `computeJoins` (Wand-Eckverbindungen)
+
+**Warum `computeJoins` zuerst?**
+- Läuft häufig (bei jedem Wall-Edit)
+- Klein und fokussiert (~50 Zeilen Kernlogik)
+- Proof-of-Concept für Tauri-invoke-Flow
+- Danach `kernel2d` parallel hochfahren
+
+**Rust-Impl:** `src-tauri/src/geometry.rs`
+
+```rust
+use serde::{Deserialize, Serialize};
+
+#[derive(Serialize, Deserialize)]
+pub struct Vec2 { pub x: f64, pub y: f64 }
+
+#[derive(Serialize, Deserialize)]
+pub struct WallJoinInput {
+    pub walls: Vec<Wall>,
+    pub joints: Vec<(usize, usize)>,  // wall indices
+}
+
+#[derive(Serialize, Deserialize)]
+pub struct JoinInfo { /* … */ }
+
+pub fn compute_joins(input: WallJoinInput) -> Result<Vec<JoinInfo>, Box<dyn std::error::Error>> {
+    // Port der Logik aus src/model/joins.ts
+    // L-Ecken, T-Stösse, +-Kreuzungen
+    Ok(vec![])  // Placeholder
+}
+```
+
+**TS-Fallback bleibt:** `src/model/joins.ts` (LS vor Rust-Port)
+
+**Compute-Boundary:** `src/compute/index.ts`
+```typescript
+export async function computeJoins(walls: Wall[], joints: Array<[number, number]>): Promise<JoinInfo[]> {
+  try {
+    return await invoke<JoinInfo[]>('compute_joins', { walls, joints });
+  } catch (err) {
+    console.warn('Rust compute_joins failed, using TS fallback:', err);
+    return joinsTS(walls, joints);  // Fallback
+  }
+}
+```
+
+---
+
+### Schritt 3 — Migrations-Parität testen
+
+**Test-Fixtures:**
+- Aus `src/model/sampleProject.ts` exportieren: Wand-Arrays mit bekannten L/T/±-Konfigurationen
+- Rust-Unit-Tests: gleiche Fixtures → gleiche JoinInfo-Outputs
+- Vergleich: `actual == expected`
+
+**Beispiel (Rust):**
+```rust
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn test_l_corner() {
+        let input = WallJoinInput { /* L-shaped walls */ };
+        let result = compute_joins(input).unwrap();
+        assert_eq!(result[0].kind, JoinKind::LCorner);
+    }
+}
+```
+
+---
+
+### Schritt 4 — Vite/Tauri-Integration
+
+**Dev-Workflow:**
+```bash
+npm run tauri:dev
+# → Vite dev-server (localhost:5173) lädt React-App
+# → Tauri-window zeigt auf :5173
+# → invoke() ruft Rust-Commands auf
+```
+
+**Build-Workflow:**
+```bash
+npm run build  # Vite → dist/
+npm run tauri:build  # Tauri packt dist/ + Rust-Binary
+```
+
+---
+
+## Deliverable (Proof-of-Concept)
+
+**Git-Stand nach dieser Aufgabe:**
+
+- [ ] `src-tauri/` Verzeichnis mit `Cargo.toml` + `src/main.rs` + `src/geometry.rs`
+- [ ] `Cargo.toml` buildet sauber (`cargo check` 0 Fehler)
+- [ ] `src/compute/index.ts` mit `computeJoins()` Schnittstelle (invoke + TS-fallback)
+- [ ] Rust `compute_joins()` implementiert, Tests pass (`cargo test`)
+- [ ] `package.json` `tauri` scripts hinzugefügt
+- [ ] **App läuft:** `npm run tauri:dev` → Tauri-Fenster öffnet, Wand-Edit triggert Rust-Op, Output identisch TS-Version
+- [ ] **Trace-Scan sauber** (kein TS/Rust-Code übrig, beide Impl. aktiv)
+- [ ] HANDOVER.md aktualisiert: `computeJoins` migriert, nächste Ops in Queue
+
+**Verification:**
+```bash
+# Build-Check
+cargo check  # 0 Fehler
+
+# Rust-Tests
+cargo test
+
+# App end-to-end
+npm run tauri:dev
+# → Wand zeichnen + editieren → computeJoins() über Rust aufgerufen
+# → Plan + 3D aktualisiert wie vorher
+```
+
+---
+
+## Nächste Ops (Priorisierung)
+
+Nach `computeJoins` stabil:
+
+1. **`kernel2d`** (Offset/Trim/Extend) — großer Hebel, läuft häufig
+2. **DXF/DWG-Parser** (Geometrie) — heavy, aber niedrige Frequenz
+3. **`detectRooms`** (SIA-Raumerkennung) — async, kann auf Hintergrund ziehen
+4. **`booleanOps`** (Union/Differenz/Schnitt) — Kandidat für später
+
+---
+
+## Offene Punkte (NICHT jetzt)
+
+- **GPU-Compute (wgpu):** Erst nach CPU-Ops stabil (kernel2d, joins, parsing)
+- **WASM-Fallback:** Nur wenn Browser-Support nötig wird
+- **Flatpak-Distribution:** Nach Tauri-Shell stable + erste Ops migriert
+
+---
+
+## Referenzen
+
+- Tauri v2 Docs: https://tauri.app/v1/guides/getting-started/prerequisites
+- Serde: https://serde.rs/
+- CONVENTIONS.md: Identifiers englisch, UI-Text via `t()`, …
+- Commit-Regel: kein AI-Attribution im Repo
@@ -0,0 +1,151 @@
+# Oberleiste – Angleichung an DOSSIER (Umsetzungs-Spezifikation)
+
+Verbindliche Vorlage für den Umbau der Top-Bar (`src/ui/TopBar.tsx`,
+`src/styles.css`, Verdrahtung in `src/App.tsx`). Quelle: das DOSSIER-Rhino-
+Plugin (`ToolbarApp.jsx`, `components/BarControls.jsx`, `TextEditorApp.jsx`).
+Bezeichner englisch, UI-Text/Kommentare deutsch (CONVENTIONS.md).
+
+## 0. Grundprimitive (neu, DOSSIER-konform)
+
+Alle Leisten-Controls teilen dieselbe Höhe und Pillenform.
+
+- `BAR_H = 22px` Basis-Höhe. Segmentierte Pillen `BAR_H + 2 = 24px`
+  (`box-sizing:border-box`, 1px Rand inbegriffen).
+- Pille: `border:1px solid var(--border)`, `border-radius:999px`,
+  `background:var(--input)`. Hover (interaktiv): `border-color:var(--accent-border)`,
+  `background:var(--accent-dim)`.
+- Aktiver Zustand (Toggle AN / aktive Segmentzelle): `background:var(--accent)`,
+  `color:#fff`.
+
+### BarCombo (Pillen-Dropdown)
+Wir haben bereits `src/ui/Dropdown.tsx`. Der Dropdown-Trigger MUSS optisch der
+Pille entsprechen (Höhe 24, radius 999, obige Farben). Ein optionales Icon sitzt
+LINKS **ausserhalb** der Pille (18px breit, `var(--muted)`), ein optionaler
+Zahnrad-Knopf („settings") sitzt rechts **innerhalb** der Pille. Prüfen, ob
+`Dropdown` bereits so aussieht; falls nicht → Trigger-CSS angleichen (Klasse
+`tb-dd-trigger`). KEINE zweite Dropdown-Implementierung bauen.
+
+### Segmentpille (3er/4er)
+Aussencontainer `display:inline-flex; height:24px; border:1px solid var(--border);
+border-radius:999px; overflow:hidden`. Zellen ohne eigenen Radius; interne Trenner
+über `border-left:1px solid var(--border)` (erste Zelle ohne). Aktive Zelle
+`var(--accent)`/#fff, inaktiv `var(--input)`/`var(--ink)`, Hover
+`var(--accent-dim)`/`var(--accent)`. Genutzt für: Ansichts-Icons, Zoom (%/fit/center),
+**B/I/U**, **L/C/R**.
+
+### BarButton (quadratischer Icon-Knopf)
+22×22, `border-radius:999px`, sonst wie Pille. Aktiv = Akzentfüllung, Icon #fff.
+
+## 1. Reihenfolge der Gruppen (links → rechts)
+
+1. Marke (bestehend, unverändert).
+2. Ansichts-Gruppe (bestehend `view-grid`; Zellen auf Segmentpillen-Look bringen).
+3. Sichtbarkeits-Kombinationen (bestehend, `BarCombo`-Look).
+4. Detailgrad + Massstab (gestapelt, `BarCombo`-Look).
+5. **Massstab/Zoom-Cluster NEU** (siehe §2) — ersetzt die heutige Gruppe mit der
+   DOPPELTEN Zoom-Anzeige.
+6. Darstellungsart (bestehend, `BarCombo`).
+7. **Text-Gruppe NEU** (siehe §3) — die zentrale neue Leiste.
+8. Referenzlinien / Linien-Modus (bestehend).
+9. Rechts: Layout · Ressourcen · Projektname.
+
+## 2. Massstab/Zoom-Cluster (ersetzt Doppel-Zoom-Bug)
+
+HEUTE FALSCH: In `TopBar.tsx` wird `tb-zoom` (Zoom %) ZWEIMAL gerendert
+(einmal im `tb-zoomstack`, einmal darunter als eigener `<span>`). Die zweite,
+lose `<span className="tb-zoom">…%</span>` ersatzlos ENTFERNEN.
+
+NEUES Layout — 2×2-Raster (`display:grid; grid-template-columns:auto auto;
+gap:4px 6px; align-items:center`):
+
+- **Spalte 1, beide Zeilen** (`grid-row:1 / span 2`): EINE kombinierte Stat-Pille,
+  `width:70px`, Höhe `BAR_H*2+6 = 50px`, `border-radius:14px` (NICHT 999),
+  `border:1px solid var(--border)`, `background:var(--input)`, Innen zwei Zeilen
+  mittig, getrennt durch 1px-Linie (`var(--border)`):
+  - oben: Live-Massstab `1:N` (Akzentfarbe, `var(--font-mono)`, 11px, 700)
+  - unten: Zoom `NN%` (`var(--ink-2)`, mono, 11px)
+  - „am Massstab" (Zoom==gewählter Massstab): Pille `background:var(--accent-dim)`,
+    `border-color:var(--accent)`, Text `var(--accent)`.
+  - Nicht-Plan-Ansicht: beide Werte „—".
+- **Spalte 2, Zeile 1**: Massstab-Dropdown (`BarCombo`, ~140px, mono) + Print/PDF
+  bleibt separat. (Massstab-Dropdown ist der bestehende `scaleOptions`-Dropdown.)
+- **Spalte 2, Zeile 2**: Zoom-Segmentpille mit 3 Zellen — `%` (=`onZoom100`,
+  Label „1:1"/100 %), `fit_screen` (=`onFit`), `center_focus_strong`
+  (=`onFitSelection`). Material-Icons. Daneben ggf. Referenzlinien-BarButton.
+
+Export-Knöpfe (PDF/DXF) wandern in eine eigene kleine BarButton-Reihe rechts vom
+Cluster (Icons `picture_as_pdf` / `download`) ODER bleiben Pillen — Hauptsache
+NICHT mehr Teil des Zoom-Blocks, damit der Cluster ruhig bleibt.
+
+## 3. Text-Gruppe in der Oberleiste (NEU – Kern dieser Aufgabe)
+
+Immer sichtbar. 3×2-Raster (`grid-template-columns:110px 130px 80px; gap:4px 6px`).
+Setzt Defaults für neuen Text UND formatiert die aktuelle Auswahl live.
+
+Zeile 1:
+- **Stil-Preset** `BarCombo` (110px): Optionen aus `DEFAULT_PRESETS`
+  (Titel/Untertitel/Label/Notiz) + „— Stil —".
+- **Font** `BarCombo` (130px): Systemfont-Liste (mind. Helvetica, Arial, Inter,
+  Times New Roman, Georgia, Courier New). `applyMark(doc,range,'font',v)`.
+- **Grösse** `BarCombo` (80px): Presets in pt `[8,9,10,11,12,14,18,24,36,48]`
+  + „Eigene…" → Zahl-Input-Pille. `applyMark(...,'sizePt',n)`.
+
+Zeile 2:
+- **B/I/U** Segmentpille (110px, Icons `format_bold`/`format_italic`/
+  `format_underlined`): `toggleMark(doc,range,'bold'|'italic'|'underline')`.
+  Aktiv-Zustand aus `isMarkActive(doc,range,mark)`.
+- **L/C/R** Segmentpille (130px, Icons `format_align_left`/`_center`/`_right`):
+  setzt `paragraph.align` im Bereich.
+- **„+"-Text-Button** (80px, BarButton/Pille, Icon `add`, Label „Text"): startet
+  das Text-Werkzeug (neues Textobjekt platzieren). Falls das Text-Annotation-
+  Werkzeug noch nicht existiert, Button vorerst `disabled` mit Tooltip
+  (kein stiller No-Op) — aber Verdrahtung vorbereiten.
+
+**Auswahl-Bewusstsein (WICHTIG):** Prop `textTarget` (oder aus App-State): entweder
+`null` (nichts Text-artiges selektiert → Controls setzen nur Defaults, Ränder
+normal) ODER `{ doc: RichTextDoc, range: TextRange|null, apply: (doc)=>void }`
+für den aktuell selektierten Raumstempel/Text. Ist `textTarget != null`, tragen
+die Zeile-2-Pillen `border-color:var(--accent)` (Akzent-Glow), und alle Aktionen
+wirken auf `textTarget.doc` via `textTarget.apply(newDoc)`. Ohne aktive Range
+(nur Objekt selektiert, kein Editor offen) wirkt Formatierung auf das GANZE Doc.
+
+Quelle der `textTarget`-Daten: der Raum-Agent exponiert Stempel-Doc + Setter
+(`setRoomStampDoc(roomId, doc)`) im App-State (siehe Peer-Absprache). App leitet
+für den selektierten Raum `{doc: room.stampDoc, range: activeStampRange,
+apply: d => setRoomStampDoc(room.id, d)}` an die Text-Gruppe.
+
+## 4. Text-Inhalt bearbeiten: kleines Fenster (kein Footer)
+
+Doppelklick auf einen Raumstempel/ein Textobjekt öffnet ein **schwebendes
+Dialog-Fenster** (nicht den Footer, kein Panel-Aufklappen). Umsetzung: neue
+Komponente `src/ui/TextEditorDialog.tsx` — ein zentriertes/абgesetztes Fenster
+(~560×420, `--shadow-3`, `border-radius:8px`, Titel „Text bearbeiten",
+Kopf mit Schliessen-✕), Body = der bestehende `src/text/RichTextEditor.tsx`
+(er bringt seine eigene Mini-Toolbar mit — das ist hier ok, weil es ein eigenes
+Fenster ist), Fuss = „Abbrechen" / „Übernehmen". „Übernehmen" ruft
+`setRoomStampDoc(roomId, editedDoc)`.
+
+Der Doppelklick-Handler lebt in App (Plan-View/Viewport → onDoubleClick auf
+Stempel-Hit → `openTextEditor(roomId)`), NICHT im Footer. Falls der Raum-Agent
+den Footer benutzt hat: diesen Pfad entfernen und durch den Dialog ersetzen.
+
+## 5. Farb-/Stil-Tokens
+
+Bestehende CSS-Variablen weiterverwenden (`--panel`,`--input`,`--border`,
+`--accent`,`--accent-dim`,`--accent-border`,`--ink`,`--ink-2`,`--muted`,
+`--font-mono`,`--shadow-1..3`). KEINE neuen Farbwerte hart kodieren. Falls ein
+Token fehlt (z. B. `--accent-border`), prüfen und ggf. aus bestehenden ableiten.
+
+## 6. i18n
+
+Neue Keys in de.ts UND en.ts: `text.style`, `text.font`, `text.size`,
+`text.size.custom`, `text.bold/italic/underline`, `text.align.left/center/right`,
+`text.add`, `text.add.hint`, `text.editTitle`, `text.apply`, `text.cancel`,
+`text.selectedHint`. Presets-Namen über bestehende `rt.*`/Preset-Keys, sofern da.
+
+## 7. Gate (Pflicht)
+
+`rm -f tsconfig.tsbuildinfo && npx tsc -b` grün, `npm run build` grün, keine
+AI-Spuren (grep auf Claude/Anthropic/AI/Generated/Co-Authored), Boot-Probe
+(`node scripts/probe.mjs`) ohne Konsolenfehler, Screenshot der Oberleiste.
+KEIN Commit.
@@ -0,0 +1,581 @@
+# WebGL2 GPU-Accelerated 2D Plan Renderer — Architecture
+
+## Executive Summary
+
+A WebGL2 canvas renderer for PlanView's heavy geometry (polygons, lines, hatches) with CPU fallback. Geometry tessellates once per plan and caches; pan/zoom only updates a transform-matrix uniform. Screen-space stroke width via vertex shader normal expansion. Thin SVG overlay handles text, grips, snap markers, tool preview.
+
+**No npm dependencies** — raw WebGL2 + TypeScript.
+
+---
+
+## Current State (SVG Bottleneck)
+
+**PlanView.tsx** renders `Primitive[]` (polygon/line/arc/text) → SVG DOM:
+- ~2500 LOC: pan/zoom via viewBox, toScreen() scaling (1 meter = 90 viewBox units)
+- `Primitive` types (generatePlan.ts:133):
+  - **polygon**: `pts: Vec2[]`, fill/stroke/strokeWidthMm, hatch (solid/insulation/diagonal/crosshatch)
+  - **line**: a/b endpoints, className, weightMm, dash[], optional color
+  - **arc**: center, from/to points, r, className, weightMm, dash[]
+  - **text**: anchor, RichTextDoc, roomStamp metadata
+- Bottleneck: **pan/zoom re-renders entire SVG DOM** → Cairo rasterizes geometry at 144 Hz
+
+**Key constants:**
+- `PX_PER_M = 90` (viewBox units per meter; Modell-Y up → SVG-Y down via negation)
+- `PAD = 60` (margin in viewBox units)
+- `mmToPx(mm) = (mm / 25.4) * dpi()` (stroke width: constant screen-px via non-scaling-stroke)
+- `ZOOM_MAX/MIN = 50/0.2` (pan/zoom bounds)
+
+---
+
+## Architecture: PlanRenderer (WebGL2 + Fallback SVG)
+
+### Module Structure
+
+```
+src/plan/
+├── PlanRenderer.ts          (Main GPU/CPU dispatcher)
+├── glPlan/
+│   ├── glPlanCompile.ts     (Tessellation & buffer upload)
+│   ├── glPlanShaders.ts     (Vertex/fragment sources + compilation)
+│   ├── glPlanRender.ts      (Draw loop: matrix uniform, state mgmt)
+│   └── glPlanTypes.ts       (TypeScript interfaces for GPU data)
+└── PlanView.tsx             (React wrapper, unchanged API)
+```
+
+### High-Level Flow
+
+```
+PlanView.tsx
+  ↓ [receives plan: Plan]
+  ↓
+PlanRenderer (new abstraction)
+  ↓
+  ├─→ GPU path [if WebGL2 available && flag=true]
+  │    ├─ glPlanCompile() → upload tessellated geometry to VRAM
+  │    ├─ glPlanRender() → draw with pan/zoom matrix uniform
+  │    └─ [fast pan/zoom via matrix only]
+  │
+  └─→ Fallback: SVG [if WebGL fails || flag=false]
+       └─ existing PlanView render path (toScreen + DOM)
+```
+
+---
+
+## GPU Path: Tessellation & Shaders
+
+### 1. Tessellation Strategy
+
+#### **Polygon** → Fans + Ear Clipping
+- **Input**: Primitive.polygon = { pts: Vec2[], fill, stroke, strokeWidthMm, hatch }
+- **Output**: Indexed triangle mesh
+- **Algorithm**: Earcut2D (existing JS library logic, inlined to avoid npm)
+  - Convert polygon pts to 2D float32 array in **world space** (meters)
+  - Earcut → triangle indices
+  - Store: `{ vertices: Float32Array, indices: Uint32Array, color: vec4, hasHatch: bool }`
+  - **Hatch rendering**: Bake hatch as texture or re-implement in fragment shader (MVP: solid fill only; hatch deferred)
+
+#### **Line** → Quad Expansion (Screen-Space Width)
+- **Input**: Primitive.line = { a, b, weightMm, cls, dash?, color }
+- **Output**: Degenerate quad (2 triangles) with screen-space normal offset
+- **Strategy**:
+  1. Vertex shader receives `{ pos: vec2, side: float }` (side = ±1 for left/right edge)
+  2. Transform pos to clip space via matrix uniform
+  3. Compute screen-space perpendicular via `dFdx/dFdy` or pre-compute normal in CPU
+  4. Expand by `(weightMm / 25.4) * dpi * (screenPixelsPerClipUnit)` in clip space
+  5. Fragment shader: solid color (no dash MVP; dashing deferred or CPU pre-tessellation)
+
+#### **Arc** → Line Segments (Polyline → Quads)
+- **Input**: Primitive.arc = { center, from, to, r, weightMm, cls, dash }
+- **Output**: Tessellate arc to ~30 line segments (adaptive based on radius/zoom), expand each as quad
+- Fallback: SVG arc for MVP
+
+#### **Text, Grips, Snap-Markers, Tool-Preview**
+- **Stays in SVG overlay** (thin, non-bottleneck)
+- Render above WebGL canvas at z-order 1
+
+---
+
+### 2. Shader Sources (GLSL 3.00 ES)
+
+#### **Vertex Shader: Solid Fill (polygon)**
+```glsl
+#version 300 es
+precision highp float;
+
+uniform mat4 viewProjection; // pan/zoom as 2×3 affine (expand to mat4)
+
+layout(location=0) in vec2 position;      // world-space (meters)
+layout(location=1) in vec4 color;         // fill color
+
+out VS_OUT {
+  flat vec4 vertexColor;
+} vs_out;
+
+void main() {
+  vec4 clipPos = viewProjection * vec4(position, 0.0, 1.0);
+  gl_Position = clipPos;
+  vs_out.vertexColor = color;
+}
+```
+
+#### **Vertex Shader: Screen-Space Stroked Line**
+```glsl
+#version 300 es
+precision highp float;
+
+uniform mat4 viewProjection;    // world → clip space
+uniform vec2 screenSize;        // canvas (width, height) in pixels
+uniform float strokeWidthMm;    // millimeters
+uniform float dpi;              // 96 * devicePixelRatio
+
+layout(location=0) in vec2 position;      // world-space endpoint
+layout(location=1) in float sideFlag;     // ±1.0 (left/right edge)
+layout(location=2) in vec4 lineColor;     // stroke color
+
+out VS_OUT {
+  flat vec4 vertexColor;
+} vs_out;
+
+void main() {
+  vec4 clipPos = viewProjection * vec4(position, 0.0, 1.0);
+  
+  // Convert stroke width (mm) → screen pixels
+  float strokePx = (strokeWidthMm / 25.4) * dpi;
+  // Convert screen pixels → normalized device coords (NDC)
+  // NDC ∈ [-1,1]²; screen (0,screenSize) → NDC [-1,1]
+  float strokeNdc = (strokePx / screenSize.x) * 2.0;
+  
+  // Expand in clip space (simple; assumes aspect ≈ 1)
+  vec4 expanded = clipPos + vec4(sideFlag * strokeNdc, 0.0, 0.0, 0.0);
+  
+  gl_Position = expanded;
+  vs_out.vertexColor = lineColor;
+}
+```
+
+#### **Fragment Shader (both)**
+```glsl
+#version 300 es
+precision highp float;
+
+in VS_OUT {
+  flat vec4 vertexColor;
+} fs_in;
+
+out vec4 fragColor;
+
+void main() {
+  fragColor = fs_in.vertexColor;
+}
+```
+
+---
+
+### 3. GPU Data Structures (TypeScript)
+
+**glPlanTypes.ts:**
+```typescript
+export interface GLGeometryBatch {
+  /** Vertex buffer: interleaved (x, y, [z if 3D], ...) in world space. */
+  vertexBuffer: WebGLBuffer;
+  vertexCount: number;
+
+  /** Index buffer (triangles for fill, degenerate quads for strokes). */
+  indexBuffer: WebGLBuffer;
+  indexCount: number;
+
+  /** Vertex Array Object (VAO) binds VBO + IBO. */
+  vao: WebGLVertexArrayObject;
+
+  /** Per-batch metadata. */
+  batches: Array<{
+    kind: "polygon" | "line" | "arc";
+    indexStart: number;
+    indexCount: number;
+    color: [r: number, g: number, b: number, a: number]; // RGBA [0,1]
+    hasHatch: boolean;
+    hatchPattern?: "solid" | "insulation" | "diagonal" | "crosshatch";
+    strokeWidthMm?: number;
+  }>;
+}
+
+export interface GLPlanRenderState {
+  // Pan/zoom transform: world (meters) → clip space
+  viewMatrix: Matrix3 | Matrix4;  // 2×3 affine
+  projMatrix: Matrix4;            // orthographic
+
+  // Viewport size & DPI for screen-space stroke width
+  screenWidth: number;
+  screenHeight: number;
+  dpi: number;
+
+  // Compiled shaders
+  solidFillProgram: WebGLProgram;
+  strokeProgram: WebGLProgram;
+
+  // Geometry cache (tessellated once per plan)
+  geometryBatch: GLGeometryBatch | null;
+}
+```
+
+---
+
+## MVP API: PlanRenderer Class
+
+### Interface
+
+```typescript
+export class PlanRenderer {
+  /**
+   * Create renderer with WebGL2 context + fallback config.
+   */
+  constructor(
+    canvas: HTMLCanvasElement,
+    options?: {
+      enableGpu?: boolean;      // default: true
+      enableGpuFallback?: boolean; // SVG fallback if GL fails
+    }
+  );
+
+  /**
+   * Compile and cache geometry from primitives.
+   * Call once per plan change.
+   */
+  compilePlan(plan: Plan): Promise<void>;
+
+  /**
+   * Set pan/zoom transform matrix.
+   * Call on every view change (pan, zoom, fit).
+   */
+  setViewMatrix(viewBox: { x, y, w, h }, canvasSize: { w, h }): void;
+
+  /**
+   * Render one frame: clear, draw batches, composite.
+   * Called from requestAnimationFrame loop.
+   */
+  render(): void;
+
+  /**
+   * Release WebGL resources.
+   */
+  dispose(): void;
+
+  /**
+   * Query GPU availability / fallback state.
+   */
+  isGpuReady(): boolean;
+  isFallbackActive(): boolean;
+}
+```
+
+### Usage in PlanView
+
+**Before** (SVG only):
+```tsx
+function PlanView({ plan, ... }) {
+  return (
+    <svg ref={svgRef}>
+      <defs>{hatches}</defs>
+      {plan.primitives.map((p, i) => <PrimitiveShape ... />)}
+    </svg>
+  );
+}
+```
+
+**After** (GPU + SVG fallback):
+```tsx
+function PlanView({ plan, ... }) {
+  const rendererRef = useRef<PlanRenderer | null>(null);
+
+  useEffect(() => {
+    const canvas = canvasRef.current;
+    if (!canvas) return;
+    rendererRef.current = new PlanRenderer(canvas, { enableGpu: true });
+    rendererRef.current.compilePlan(plan);
+  }, [plan]);
+
+  useEffect(() => {
+    rendererRef.current?.setViewMatrix(view, { w: canvasWidth, h: canvasHeight });
+  }, [view, canvasWidth, canvasHeight]);
+
+  useEffect(() => {
+    const frame = () => {
+      rendererRef.current?.render();
+      rafId = requestAnimationFrame(frame);
+    };
+    rafId = requestAnimationFrame(frame);
+    return () => cancelAnimationFrame(rafId);
+  }, []);
+
+  return (
+    <div style={{ position: "relative" }}>
+      {/* GPU canvas (or SVG fallback if GL unavailable) */}
+      <canvas ref={canvasRef} style={{ position: "absolute" }} />
+      {/* Thin SVG overlay: text, grips, snap-markers, tool preview */}
+      <svg ref={svgRef} style={{ position: "absolute", zIndex: 1 }}>
+        {/* text, grips, snaps only; geometry stays in WebGL */}
+      </svg>
+    </div>
+  );
+}
+```
+
+---
+
+## Data Flow: From Primitives → GPU
+
+### 1. **Compile Phase** (glPlanCompile.ts)
+
+```typescript
+export function compilePlan(gl: WebGL2RenderingContext, plan: Plan): GLGeometryBatch {
+  const batches: BatchInfo[] = [];
+  const vertices: number[] = [];
+  const indices: number[] = [];
+  let indexOffset = 0;
+
+  for (const prim of plan.primitives) {
+    if (prim.kind === "polygon") {
+      const { verts, inds } = tessellatePolygon(prim.pts);
+      const color = parseColor(prim.fill);
+      batches.push({
+        kind: "polygon",
+        indexStart: indexOffset,
+        indexCount: inds.length,
+        color,
+        hasHatch: prim.hatch.pattern !== "none",
+        hatchPattern: prim.hatch.pattern,
+      });
+      vertices.push(...verts);
+      indices.push(...inds.map((i) => i + indexOffset));
+      indexOffset += verts.length / 2;
+    } else if (prim.kind === "line") {
+      const { verts, inds } = tessellateLineQuad(prim.a, prim.b);
+      const color = parseColor(prim.color || "black");
+      batches.push({
+        kind: "line",
+        indexStart: indexOffset,
+        indexCount: inds.length,
+        color,
+        strokeWidthMm: prim.weightMm,
+      });
+      vertices.push(...verts);
+      indices.push(...inds.map((i) => i + indexOffset));
+      indexOffset += verts.length / 2;
+    }
+    // arc → polyline → quads (deferred for MVP)
+  }
+
+  const vbo = gl.createBuffer()!;
+  gl.bindBuffer(gl.ARRAY_BUFFER, vbo);
+  gl.bufferData(gl.ARRAY_BUFFER, new Float32Array(vertices), gl.STATIC_DRAW);
+
+  const ibo = gl.createBuffer()!;
+  gl.bindBuffer(gl.ELEMENT_ARRAY_BUFFER, ibo);
+  gl.bufferData(gl.ELEMENT_ARRAY_BUFFER, new Uint32Array(indices), gl.STATIC_DRAW);
+
+  const vao = gl.createVertexArray()!;
+  gl.bindVertexArray(vao);
+  gl.bindBuffer(gl.ARRAY_BUFFER, vbo);
+  gl.vertexAttribPointer(0, 2, gl.FLOAT, false, 8, 0); // position
+  gl.enableVertexAttribArray(0);
+  gl.bindBuffer(gl.ELEMENT_ARRAY_BUFFER, ibo);
+
+  return { vertexBuffer: vbo, indexBuffer: ibo, vao, batches, vertexCount: vertices.length, indexCount: indices.length };
+}
+```
+
+### 2. **Render Phase** (glPlanRender.ts)
+
+```typescript
+export function renderPlan(
+  gl: WebGL2RenderingContext,
+  state: GLPlanRenderState,
+  batch: GLGeometryBatch
+): void {
+  gl.clearColor(1, 1, 1, 1); // white background
+  gl.clear(gl.COLOR_BUFFER_BIT);
+
+  gl.useProgram(state.solidFillProgram);
+  const mvpLoc = gl.getUniformLocation(state.solidFillProgram, "viewProjection");
+  const mvp = mat4.multiply(state.projMatrix, state.viewMatrix);
+  gl.uniformMatrix4fv(mvpLoc, false, mvp);
+
+  gl.bindVertexArray(batch.vao);
+
+  for (const b of batch.batches) {
+    const colorLoc = gl.getUniformLocation(state.solidFillProgram, "vertexColor");
+    gl.uniform4f(colorLoc, b.color[0], b.color[1], b.color[2], b.color[3]);
+
+    gl.drawElements(gl.TRIANGLES, b.indexCount, gl.UNSIGNED_INT, b.indexStart * 4);
+  }
+}
+```
+
+---
+
+## Tessellation Details
+
+### Earcut (Polygon Triangulation)
+
+**Inlined earcut logic (no npm):**
+```typescript
+function tessellatePolygon(pts: Vec2[]): { verts: number[]; inds: number[] } {
+  // Convert Vec2[] → flat float array
+  const coords = pts.flatMap((p) => [p.x, p.y]);
+
+  // Earcut2D: robust polygon triangulation
+  // → Returns index array (triplets = triangles)
+  const triangles = earcut(coords);
+
+  // Vertex buffer: just positions (x, y) in world space (meters)
+  const verts = coords;
+
+  return { verts, inds: triangles };
+}
+
+// Simplified earcut (full version ~200 LOC; reference libtess2 or earcut.js)
+function earcut(data: number[], hole?: number[], dim?: number): number[] {
+  // ... iterative ear clipping, complexity O(n²) worst-case
+  // Returns Uint32Array of triangle indices
+}
+```
+
+### Line Quad Expansion
+
+```typescript
+function tessellateLineQuad(
+  a: Vec2, b: Vec2,
+  widthMm: number = 0.5
+): { verts: number[]; inds: number[] } {
+  // World-space endpoints; width (mm) will be expanded in vertex shader
+
+  // Create a degenerate quad: 2 triangles
+  // Vertices: [a_left, a_right, b_left, b_right]
+  // (normal expansion happens in VS)
+
+  const verts = [
+    a.x, a.y, 0.0, // vertex 0: a, left flag
+    a.x, a.y, 1.0, // vertex 1: a, right flag
+    b.x, b.y, 0.0, // vertex 2: b, left flag
+    b.x, b.y, 1.0, // vertex 3: b, right flag
+  ];
+
+  // Two triangles: (0, 1, 2) and (1, 3, 2)
+  const inds = [0, 1, 2, 1, 3, 2];
+
+  return { verts, inds };
+}
+```
+
+---
+
+## Pan/Zoom Matrix Transform
+
+### View Box → Clip Space
+
+```typescript
+function buildViewMatrix(
+  viewBox: { x, y, w, h },
+  canvasSize: { w, h }
+): Matrix4 {
+  // 1. World space (meters, origin at model 0,0) → viewBox units (PX_PER_M=90)
+  const scale = PX_PER_M; // 1 meter → 90 viewBox units
+
+  // 2. ViewBox viewport: x,y,w,h in viewBox units → NDC [-1,+1]²
+  // Orthographic projection (no perspective).
+  const ortho = mat4.ortho(
+    viewBox.x,
+    viewBox.x + viewBox.w,
+    viewBox.y,
+    viewBox.y + viewBox.h,
+    -1, 1
+  );
+
+  // 3. Scale from viewBox units → world (invert PX_PER_M)
+  const scaleMatrix = mat4.scale(mat4.identity(), [1/scale, 1/scale, 1]);
+
+  return mat4.multiply(ortho, scaleMatrix);
+}
+```
+
+Whenever PlanView calls `setView(viewBox)` or `onWheel()` → call `setViewMatrix()` → GPU re-renders with new matrix uniform (no tessellation).
+
+---
+
+## Fallback Strategy: SVG Renderer Flag
+
+**Global flag** in PlanView or app state:
+```typescript
+const [useGpuRenderer, setUseGpuRenderer] = useState(true);
+```
+
+**Render path branching:**
+```typescript
+return useGpuRenderer && rendererRef.current?.isGpuReady()
+  ? <canvas ref={canvasRef} />
+  : <svg ref={svgRef}>{/* existing SVG rendering */}</svg>;
+```
+
+**When GL fails** (e.g., no WebGL2 support, Out-Of-Memory):
+1. Renderer catches error in `compilePlan()`
+2. Sets internal `fallbackActive = true`
+3. Returns gracefully (app renders SVG path instead)
+4. User sees same plan, slower but functional
+
+---
+
+## Implementation Order (MVP → Iteration)
+
+### Phase 1: Core (Week 1)
+1. **glPlanTypes.ts** — TypeScript interfaces for GPU state
+2. **glPlanShaders.ts** — Compile vertex/fragment shaders, handle GL errors
+3. **glPlanCompile.ts** — Tessellation (earcut inlined), buffer upload
+4. **glPlanRender.ts** — Draw loop, matrix uniform, clear/present
+5. **PlanRenderer.ts** — Main class, dispatcher (GPU vs SVG fallback)
+6. **PlanView.tsx** — Wire renderer, canvas overlay, canvas lifecycle
+
+### Phase 2: Hatches & Lines (Week 2)
+- Improve line tessellation: proper screen-space width (dFdx/dFdy or pre-computed normals)
+- Hatch patterns: texture-based or procedural fragment shader (diagonal/insulation)
+- Arc tessellation: polyline → quads
+
+### Phase 3: Polish (Week 3)
+- Stroke dashing via geometry or fragment shader
+- Greyed opacity blending
+- Hit testing integration (point-in-triangle for GPU)
+- Performance profiling, batch merging
+
+---
+
+## Performance Targets
+
+| Operation | SVG (Current) | GPU (Target) | Notes |
+|-----------|---------------|--------------|-------|
+| **Tessellation** | — | 10–50 ms | Once per plan |
+| **Pan/Zoom 60 Hz** | 16 ms (re-render SVG) | <1 ms (matrix uniform) | Matrix upload negligible |
+| **Pan/Zoom 144 Hz** | 7 ms (bottleneck) | <0.5 ms | 28× speedup expected |
+| **Geometry: 1000 polygons** | 50–100 ms SVG render | 1–5 ms GPU draw | CPU tessellation pipelined |
+
+User: AMD RX 7800 XT → easily capable of 4K+ geometry at 144 Hz.
+
+---
+
+## Known Deferred Items (Post-MVP)
+
+- **Hatches**: Solid fill only MVP; insulation/diagonal/crosshatch in Phase 2 via texture or procedural shader
+- **Dashing**: Not in MVP (complex with screen-space strokes); either CPU pre-tessellation or fragment shader alpha-discard
+- **Arcs**: Fallback to SVG for MVP; GPU polyline expansion in Phase 2
+- **Text, Grips, Snaps**: Stay in SVG overlay indefinitely (no GPU benefit; text rendering nontrivial)
+- **Hit Testing**: Keep in CPU/SVG for MVP; GPU pick-buffer deferred
+- **Color/Opacity Blending**: Basic for MVP; advanced (multiply, screen, dodge) deferred
+
+---
+
+## References
+
+- **Earcut.js**: https://github.com/mapbox/earcut — polygon triangulation (logic to inline)
+- **three.js line expansion**: https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLGeometries.js
+- **OpenGL Perspective Division**: https://en.wikibooks.org/wiki/OpenGL_Programming/Modern_OpenGL_Tutorial_Polygon_offset
+- **Screen-Space Stroke Width**: https://forum.libcinder.org/topic/smooth-line-rendering-using-geometry-shaders
+- PlanView source: `/home/karim/cad/src/plan/PlanView.tsx` (2500 LOC)
+- Primitive types: `/home/karim/cad/src/plan/generatePlan.ts:133`
@@ -0,0 +1,81 @@
+# Briefing — Nativer wgpu-2D-Renderer (parallele Instanz)
+
+> 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 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
+ist das 144-Hz-flüssig, aber **Tauris Linux-Webview = WebKitGTK bremst** (langsamer
+Compositor, vermutlich 60-Hz-rAF-Cap). Bewiesen: dieselbe App im `chromium --app`-
+Fenster = butterweich, im Tauri-Fenster = zäh — trotz imperativem Pan, CSS-transform-
+Overlay, DMABUF-Tweaks. Siehe Memo `webkitgtk-bottleneck`.
+
+**Lösung:** die schwere Grafik **nativ mit wgpu** rendern (Rust), die Webview macht
+nur noch UI-Chrome (Panels/Buttons). So bleibt Tauri (natives Rust-Backend, winziges
+Bundle) UND wir umgehen den Webview-Compositor komplett.
+
+## Referenz-Implementierung (NICHT wegwerfen — 1:1 portierbar)
+Der WebGL-Renderer unter `src/plan/glPlan/` ist die **arbeitende Referenz**. Die
+harte Arbeit ist dort schon gelöst und portiert konzeptuell direkt nach wgpu:
+- `glPlanCompile.ts` — **Earcut-Triangulierung** (konkav-fähig), Linien→Quads mit
+  Normale+Seiten-Flag, Batch-Merging, Farb-Parsing. Unit-Tests: `glPlanCompile.test.ts`.
+- `glPlanShaders.ts` — Vertex/Fragment (GLSL 300 es). **WGSL ≈ GLSL** — direkt übersetzbar.
+  - Füll-VS: Bildschirm-Position → Clip via `viewProj`-Matrix.
+  - Linien-VS: bildschirmkonstante bzw. papier-mm-Breite via Normalen-Offset im Clip
+    (siehe `strokeScale`/`strokePx`-Logik — Papier-mm × Massstab N × meet-Skala).
+- `glPlanRender.ts` — Ortho-Matrix (aspekt-korrekt = SVG `xMidYMid meet`), Fill-/Line-
+  Pass, `computeOrthoMatrix`.
+- Koordinaten-Konvention: BILDSCHIRM-Raum `sx = mx·PX_PER_M, sy = -my·PX_PER_M`
+  (`PX_PER_M=90`), Modell-Y hoch → Bildschirm-Y runter.
+- Strichbreite = **echte Papier-mm im Massstab**: `Breite_px = mm · N/1000 · PX_PER_M ·
+  meetSkala` (repliziert SVG `printStrokeVb`). Am Beispiel 0.35 mm @ 1:100 = 0.35 mm.
+
+Die **Daten** kommen aus `src/plan/generatePlan.ts` → `Plan.primitives` (Union-Typ
+`Primitive`: polygon/line/arc/text). Text bleibt Overlay (nicht wgpu).
+
+## Die EINE harte Frage (zuerst spiken/recherchieren)
+**Wie rendert wgpu in das Tauri-Fenster neben der Webview?** Optionen recherchieren:
+1. Natives Child-Surface unter der Webview (raw-window-handle), Webview transparent
+   drüber für UI-Chrome. Vermutlich der Zielweg.
+2. Eigenes wgpu-Fenster (entkoppelt) — nur für den Spike, um Rendering von der
+   Fenster-Integration zu trennen.
+3. wgpu→Textur→Webview — verwirft den Zweck (Copy-Overhead), nur Notnagel.
+
+**Empfehlung:** Rendering-Spike ZUERST entkoppelt (Option 2, standalone `winit`+wgpu-
+Fenster), das die `Primitive` als gefüllte Polygone + Striche zeichnet und Pan/Zoom
+per Matrix-Uniform macht. Fenster-Integration in Tauri ist der zweite, separate Schritt.
+
+## Meilensteine
+- **M0 (Research):** kurzer Bericht `docs/design/wgpu-integration-findings.md` — wie
+  wgpu-Surface + Tauri/webview koexistieren (raw-window-handle, Transparenz, Z-Order,
+  Input-Routing). Quellen verlinken.
+- **M1 (Rendering-Spike, standalone):** neue Crate `src-tauri/render2d/` (serde-Input
+  = geflachte Primitive), wgpu + WGSL:
+  - Earcut-Port (oder `lyon`/`earcutr` Crate evaluieren) → Dreiecke.
+  - Füll-Pipeline (gefüllte Polygone, Ortho-Matrix-Uniform).
+  - Linien-Pipeline (Quad-Expansion, echte Papier-mm-Breite).
+  - `cargo test` für die Tessellierung (Muster: `src-tauri/geometry` hat 4/4 Tests —
+    z. B. konkaves L flächentreu, wie `glPlanCompile.test.ts`).
+  - `cargo build` grün. (Visuelle Fenster-Verifikation braucht Display → an Mensch/
+    Display-Session übergeben; im Bericht vermerken.)
+- **M2 (Tauri-Integration):** Surface unter die Webview, Pan/Zoom-Input aus der
+  Webview an den Renderer, Parität mit dem WebGL-Pfad messen (144 Hz).
+- **M3:** Schraffur, Bögen, Auswahl-Highlight; danach 3D (three.js→wgpu).
+
+## Koordination (WICHTIG)
+- **Eigener Branch** (z. B. `feature/wgpu-renderer`), NICHT auf `master`/
+  `feature/parametric-walls` committen. Isolierter Worktree.
+- **Nur** `src-tauri/` + neue Rust-Module + `docs/`. **NICHT** `src/App.tsx`,
+  `src/plan/*`, `types.ts` anfassen (die Hauptinstanz arbeitet dort an Features).
+- Der Web-WebGL-Renderer bleibt bestehen (Browser-Lauffähigkeit + Referenz).
+- 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).
+`npx tsc -b` + `npm run build` müssen unberührt grün bleiben (keine Web-Änderungen).
@@ -0,0 +1,124 @@
+# Welle C — HLR-Spike: Feasibility-Report
+
+> 2D-Vektor-Schnitte/-Ansichten aus dem 3D-Modell via Hidden-Line-Removal (HLR)
+> mit opencascade.js (OCCT-WASM). Isolierter De-Risking-Spike, NICHT in die App
+> verdrahtet. Einheiten: Meter.
+
+## Ergebnis (kurz)
+
+**HLR funktioniert in diesem Browser-Projekt.** opencascade.js initialisiert im
+Vite-Build, und der HLR-Lauf liefert korrekte, getrennte sichtbare/verdeckte
+2D-Kanten. Verifiziert im echten Browser (Chromium via Vite-Dev-Server) an einer
+L-Wand + Bodenplatte, Front-Ansicht:
+
+| Messwert | Wert |
+|---|---|
+| Sichtbare Kanten (sharp) | **9** |
+| Verdeckte Kanten | **16** |
+| Reine HLR-Rechenzeit | **~21 ms** |
+| WASM-Größe (unkomprimiert) | **62.8 MB** (65 864 037 Bytes) |
+| WASM-Größe (gzip) | **~19.6 MB** |
+| WASM-Fetch (lokal, Dev) | ~113 ms |
+| Modul-Init (Emscripten instanziieren) | ~450 ms (Browser) / ~680 ms (Node) |
+
+Beweis-Artefakte: `hlr-elevation-proof.svg` / `.png` in diesem Ordner — sichtbare
+Kanten durchgezogen, verdeckte gestrichelt. Die Zeichnung liest sich als korrekte
+Hidden-Line-Ansicht (Silhouette + sichtbare Front-Kanten voll, verdeckte hinten
+gestrichelt).
+
+## Der genutzte API-Pfad (wichtig!)
+
+Der geplante klassische Pfad (`HLRBRep_Algo`/`HLRBRep_PolyAlgo` +
+`HLRBRep_HLRToShape`/`HLRBRep_PolyHLRToShape`) ist im **prebuilt Vollbuild
+1.1.1 NICHT verfügbar**: diese Klassen sind nur als `Handle_…`-Smart-Pointer
+gebunden, ohne konstruierbare Roh-Klasse und ohne den `HLRToShape`-Extraktor.
+Ein direkter Aufbau darüber ist damit nicht möglich.
+
+**Verwendeter, funktionierender Pfad:** `HLRAppli_ReflectLines` — der High-Level-
+OCCT-Wrapper, der intern GENAU den exakten HLR-Algorithmus (`HLRBRep_Algo`)
+fährt. Er ist als Klasse gebunden und liefert getrennt sichtbare/verdeckte
+Kanten nach Kanten-Typ:
+
+```
+const rl = new oc.HLRAppli_ReflectLines(shape);
+rl.SetAxes(dirX, dirY, dirZ, atX, atY, atZ, upX, upY, upZ); // Ortho-Projektion
+rl.Perform();
+const T = oc.HLRBRep_TypeOfResultingEdge;
+// (typ, visible, in3d) → in3d=false liefert 2D-projizierte Kanten (Z≈0)
+const visSharp   = rl.GetCompoundOf3dEdges(T.HLRBRep_Sharp,   true,  false);
+const visOutline = rl.GetCompoundOf3dEdges(T.HLRBRep_OutLine, true,  false);
+const hidSharp   = rl.GetCompoundOf3dEdges(T.HLRBRep_Sharp,   false, false);
+```
+
+Kanten-Extraktion: `TopExp_Explorer_2(compound, TopAbs_EDGE, TopAbs_SHAPE)` →
+`TopoDS.Edge_1(current)` → `new BRepAdaptor_Curve_2(edge)` →
+`FirstParameter/LastParameter/Value(u)` (`gp_Pnt` mit `.X() .Y() .Z()`).
+
+**embind-Überladungen sind versioniert** (`_1`, `_2`, …) und die Nummerierung im
+Vollbuild folgt NICHT der Argumentzahl. Empirisch verifiziert:
+`BRepPrimAPI_MakeBox_1(dx,dy,dz)`, `BRepPrimAPI_MakeBox_3(gp_Pnt, gp_Pnt)`,
+`BRepAlgoAPI_Fuse_3(a, b)`, `gp_Pnt_3(x,y,z)`. Bei einem Versionswechsel des
+Pakets müssen diese Suffixe neu geprüft werden (Fehlermeldung nennt die
+erwartete Parameterzahl).
+
+## Vite-/package.json-Änderungen (genau)
+
+- `package.json`: Dependency `opencascade.js@^1.1.1` (Vollbuild).
+- `vite.config.ts` (additiv, analog zum bestehenden LibreDWG-Muster):
+  - Zwei Aliase → virtuelle Module auf die echten Paket-Dateien:
+    `virtual:occt-glue` → `dist/opencascade.wasm.js`,
+    `virtual:occt-wasm-url` → `dist/opencascade.wasm.wasm?url`.
+  - `optimizeDeps.exclude: ["opencascade.js"]` (esbuild kommt mit dem
+    UMD-Wrapper + Node-Shims der Glue nicht klar → Vor-Bündeln ausschließen).
+- `src/section/occt-wasm.d.ts`: Ambient-Stubs für die zwei virtuellen Module.
+- Geladen wird per **dynamischem Import** in `src/section/occt.ts` → die 62-MB-
+  WASM landet NICHT im Haupt-Bundle, sondern als separater Lazy-Chunk + Asset.
+
+Verifiziert: `vite build` der App bleibt grün und unverändert groß (kein
+OCCT-Chunk, da der Spike nicht verdrahtet ist). Ein Lib-Build, der `hlr.ts`
+referenziert, splittet OCCT sauber in einen eigenen Glue-Chunk + WASM-Asset ab.
+`tsc` ist für die neuen Dateien grün. (`npm run build` schlägt aktuell in
+`tsc -b` fehl — ausschließlich wegen fehlender i18n-Keys in den parallel
+bearbeiteten Dateien `commands/cmds/stair.ts` / `state/*`, NICHT wegen dieses
+Spikes.)
+
+## Dateien dieses Spikes
+
+- `src/section/hlr.ts` — Kernmodul: Box-Specs → Fuse → HLR → 2D-Polylinien
+  (`hlrFromBoxes`, `hlrShape`, `VIEWS`, `hlrToSvg`).
+- `src/section/occt.ts` — Lazy-Loader + schmale Typ-Fassade + Lade-Metriken.
+- `src/section/occt-wasm.d.ts` — Ambient-Deklarationen der virtuellen Module.
+- `docs/welle-c-hlr-spike/` — dieser Report + Proof-SVG/-PNG.
+
+## Bewertung für Welle C
+
+**Viabel.** Der exakte HLR liefert saubere, normgerechte Vektor-Kanten mit
+korrekter Sichtbarkeit — genau das, was Schnitt/Ansicht brauchen und was reines
+three.js-Kanten-Projizieren nicht robust liefert (dort fehlt echte
+Flächen-Verdeckung). Die 2D-Polylinien passen direkt in die bestehende
+SVG-Plan-Pipeline (`Pt2`/`Vec2`-kompatibel).
+
+**Der Kostenpunkt ist die WASM-Größe (62.8 MB / ~19.6 MB gzip).** Für einen
+Spike akzeptabel; für Produktion zu groß, um sie eager zu laden.
+
+### Empfohlener Integrations- + Größenreduktions-Plan
+
+1. **Lazy laden** (bereits so gebaut): OCCT erst bei erster Schnitt-/Ansichts-
+   Erzeugung dynamisch importieren; Ladezustand in der UI anzeigen. Der
+   Grundriss läuft weiter ohne OCCT (parametrisch, wie bisher).
+2. **Web-Worker**: HLR im Worker fahren, damit der UI-Thread frei bleibt (die
+   WASM ist groß, aber der HLR-Lauf selbst ist mit ~20 ms günstig).
+3. **Größe reduzieren — lohnt sich klar**: ein **Custom-Build** von
+   opencascade.js (das Paket unterstützt `make.py`/Docker-Build mit einer
+   Symbol-Whitelist). Für Welle C reicht ein minimaler Satz:
+   `BRepPrimAPI_*` (bzw. der spätere Solid-Erzeuger), `BRepAlgoAPI_Fuse/Common`,
+   `HLRAppli_ReflectLines` + `HLRBRep_TypeOfResultingEdge`, `TopExp_Explorer`,
+   `TopoDS`, `BRepAdaptor_Curve`, `gp_*`. Erfahrungswerte solcher Minimal-Builds
+   liegen bei **~5–15 MB WASM** statt 62 MB — Aufwand: ein reproduzierbarer
+   Docker-Build in CI, der die `.wasm`/`.js` als Projekt-Asset eincheckt.
+   Alternativ die **beta 2.0** prüfen (moderneres Build-System, evtl. bereits
+   schlankere Module + die klassischen HLR-Klassen konstruierbar).
+4. **Fallback, falls die Größe untragbar bleibt**: three.js-basierte
+   Kanten-Extraktion (`EdgesGeometry`) + eigene Sichtbarkeit via Depth-Peeling /
+   GPU-Occlusion. Deutlich mehr Eigenaufwand, weniger robust bei Verschneidungen
+   — daher nur zweite Wahl; OCCT-HLR bleibt der empfohlene Weg.
@@ -0,0 +1,28 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="-0.8 -0.8 5.6 3.9000000000000004" width="800">
+  <rect x="-0.8" y="-0.8" width="5.6" height="3.9000000000000004" fill="#fff"/>
+  <path d="M -0.3 2.6 L -0.3 2.3" fill="none" stroke="#111" stroke-width="0.02"/>
+  <path d="M -0.3 2.6 L 4.3 2.6" fill="none" stroke="#111" stroke-width="0.02"/>
+  <path d="M 4.3 2.6 L 4.3 2.3" fill="none" stroke="#111" stroke-width="0.02"/>
+  <path d="M -0.3 2.3 L 4.3 2.3" fill="none" stroke="#111" stroke-width="0.02"/>
+  <path d="M 0.2 2.3 L 0.2 -0.30000000000000027" fill="none" stroke="#111" stroke-width="0.02"/>
+  <path d="M 0 -0.30000000000000027 L 0.2 -0.30000000000000027" fill="none" stroke="#111" stroke-width="0.02"/>
+  <path d="M 0 2.3 L 0 -0.30000000000000027" fill="none" stroke="#111" stroke-width="0.02"/>
+  <path d="M 4 2.3 L 4 -0.30000000000000027" fill="none" stroke="#111" stroke-width="0.02"/>
+  <path d="M 0.2 -0.30000000000000027 L 4 -0.30000000000000027" fill="none" stroke="#111" stroke-width="0.02"/>
+  <path d="M -0.3 2.6 L -0.3 2.3" fill="none" stroke="#999" stroke-width="0.02" stroke-dasharray="0.1 0.1"/>
+  <path d="M -0.3 2.3 L 4.3 2.3" fill="none" stroke="#999" stroke-width="0.02" stroke-dasharray="0.1 0.1"/>
+  <path d="M 0 2.3 L 0.2 2.3" fill="none" stroke="#999" stroke-width="0.02" stroke-dasharray="0.1 0.1"/>
+  <path d="M 0.2 2.3 L 4 2.3" fill="none" stroke="#999" stroke-width="0.02" stroke-dasharray="0.1 0.1"/>
+  <path d="M 0.2 2.3 L 4 2.3" fill="none" stroke="#999" stroke-width="0.02" stroke-dasharray="0.1 0.1"/>
+  <path d="M 0 2.3 L 0.2 2.3" fill="none" stroke="#999" stroke-width="0.02" stroke-dasharray="0.1 0.1"/>
+  <path d="M -0.3 2.6 L 4.3 2.6" fill="none" stroke="#999" stroke-width="0.02" stroke-dasharray="0.1 0.1"/>
+  <path d="M 4.3 2.6 L 4.3 2.3" fill="none" stroke="#999" stroke-width="0.02" stroke-dasharray="0.1 0.1"/>
+  <path d="M 4 2.3 L 4 -0.30000000000000027" fill="none" stroke="#999" stroke-width="0.02" stroke-dasharray="0.1 0.1"/>
+  <path d="M 0.2 -0.30000000000000027 L 4 -0.30000000000000027" fill="none" stroke="#999" stroke-width="0.02" stroke-dasharray="0.1 0.1"/>
+  <path d="M 0.2 -0.30000000000000027 L 0.2 2.3" fill="none" stroke="#999" stroke-width="0.02" stroke-dasharray="0.1 0.1"/>
+  <path d="M 0.2 2.3 L 0.2 -0.30000000000000027" fill="none" stroke="#999" stroke-width="0.02" stroke-dasharray="0.1 0.1"/>
+  <path d="M 0 -0.30000000000000027 L 0.2 -0.30000000000000027" fill="none" stroke="#999" stroke-width="0.02" stroke-dasharray="0.1 0.1"/>
+  <path d="M 0 2.3 L 0 -0.30000000000000027" fill="none" stroke="#999" stroke-width="0.02" stroke-dasharray="0.1 0.1"/>
+  <path d="M 0 2.3 L 0 -0.30000000000000027" fill="none" stroke="#999" stroke-width="0.02" stroke-dasharray="0.1 0.1"/>
+  <path d="M 0 -0.30000000000000027 L 0.2 -0.30000000000000027" fill="none" stroke="#999" stroke-width="0.02" stroke-dasharray="0.1 0.1"/>
+</svg>