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

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

docs/backend.md

@@ -0,0 +1,43 @@
+# Backend & Kollaboration — Architekturentscheidung
+
+> Stand: 2026-06-29 · Ziel: komplett self-hosted, kollaborations-offen
+
+## Grundsatz
+So lange wie möglich **client-only** bleiben; das Backend additiv einführen, ohne
+den Kern umzubauen. Die Pure-Ableitungs-Architektur (ein serialisierbares Modell,
+alle Sichten abgeleitet) ist bereits kollaborations-freundlich.
+
+## Phasen
+| Phase | Persistenz / Backend |
+|---|---|
+| **0–3** (Modellierer) | **Client-only**: IndexedDB + Datei-Export/Import (JSON). Offline-fähig (PWA möglich). Kein Server. |
+| **5** (Konten/Persistenz) | **Supabase self-hosted** (Docker Compose): Postgres + Auth + Storage. Projekte, Versionen, Dateien (IFC/Pläne/Assets). Row-Level-Security pro Nutzer/Projekt. |
+| **6** (Kollaboration) | **Yjs (CRDT)** + **Hocuspocus** Sync-Server (Container), persistiert Snapshots nach Postgres. Presence/Cursors. Optional Supabase-Realtime nur für leichte Broadcasts. |
+
+## Warum Yjs/Hocuspocus statt reinem Supabase-Realtime
+Gleichzeitiges Editieren eines strukturierten Dokuments braucht Konfliktauflösung
+(CRDT). Yjs ist dafür Standard; Hocuspocus ist der self-hostbare Server dazu und
+kann nach Postgres (Supabase) persistieren. Supabase-Realtime allein wäre nur
+Pub/Sub ohne Merge-Semantik.
+
+## Was wir JETZT schon richtig machen (damit Collab nicht blockiert)
+- Dokumentmodell rein **JSON-serialisierbar**, keine Zyklen, stabile IDs.
+- Edits immutable über `setProject` → später leicht auf Yjs-Doc abbildbar
+  (`Y.Map`/`Y.Array` je Sammlung: drawingLevels, layers, components, walls …).
+- Kein Wahrheits-Zustand im Three.js-Scene-Graph oder im DOM — alles ableitbar.
+- Ressourcen (Components/Hatches/Lines) als referenzierte Bibliotheken (IDs) →
+  gut mergebar.
+
+## Self-hosted Stack (Skizze, Phase 5/6)
+```
+docker-compose:
+  supabase (postgres, gotrue auth, storage, kong gateway, studio)
+  hocuspocus (yjs websocket sync, persist -> postgres)
+  web (vite build, statisch via nginx/caddy)
+```
+Alles auf eigener Infrastruktur lauffähig; keine externe Cloud nötig.
+
+## Offene Punkte
+- Granularität der CRDT-Struktur (pro Sammlung vs. pro Element).
+- Datei-Storage (Supabase Storage vs. S3-kompatibel/MinIO im selben Stack).
+- Auth-Modell (E-Mail, OIDC/SSO fürs Büro).