# 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.