a6c2c04736
Vollständige Bestandsaufnahme der Codebasis als neue STATUS.md (Kennzahlen, Feature-Inventar, Mist-Liste: toter Code, verwaiste WASM-Crates, Doku-Widersprüche). ARCHITECTURE.md/README.md/CONVENTIONS.md waren noch auf dem Tag-1-Planungsstand (Electron/Three.js/OpenCascade/Zustand/HLR-Worker) und beschrieben nicht mehr, was tatsächlich gebaut wurde (eigene Rust/WASM-Engines, eigener Store, analytische Rust-Schnitt-Pipeline, Tauri auf macOS + Electron auf Linux). ROADMAP.md und HANDOVER.md als historisch markiert (Hinweis-Box), Inhalt unverändert.
4.5 KiB
4.5 KiB
Projekt-Konventionen — Dossier
Siehe ARCHITECTURE.md für die aktuelle Architektur, STATUS.md für den vollständigen Ist-Zustand und ROADMAP.md für die ursprüngliche (historische) Produktvision.
Code-Konventionen (verbindlich)
- Alle Bezeichner im Code sind ENGLISCH — Funktionen, Variablen, Typen, Felder,
Datei-/Modulnamen. Keine deutschen Bezeichner. (Beispiel:
computeJoins, nichtverschneidungBerechnen.) - UI-Texte und Kommentare dürfen Deutsch sein (Nutzeroberfläche ist deutsch).
- Domänen-Begriffe möglichst nach Vectorworks-Terminologie benennen (englisch): Design Layer, Sheet/Drawing Layer, Component, Class, Hatch, Wall Style, Viewport.
- Einheiten: intern alles in Metern (number). Anzeige via
formatM. - Geometrie-Konventionen: Wand-Normale
n = leftNormal(u) = (-u.y, u.x); bei CCW-Wicklung zeigt+nnach innen. Schichten werden außen (−T/2) → innen (+T/2) gestapelt.
Code-Struktur (kein God-Component — bisher nur teilweise erreicht)
- Ziel:
App.tsxbleibt ein dünner Shell (Store-Provider, Oberleiste, Docks+View-Router, Statusleiste, Floating-Panels, Ressourcen-Overlay) — keine Geschäftslogik darin. Realität (Stand 2026-07-21):App.tsxist mit ~7.100 Zeilen die grösste Datei des Projekts und enthält weiterhin View-Umschaltung und Kontextmenü-Aufbau inline — die geplante Auslagerung nachsrc/views//src/menus/(unten) ist nie passiert, siehe STATUS.md §4.3. Neue, grössere Features sollten trotzdem nicht weiter inApp.tsxwachsen; wo möglich insrc/panels/,src/editors/oder ein neues Modul auslagern statt die Datei weiter zu vergrössern. - Globaler Zustand in einem Store (
src/state/, eigener Store aufuseSyncExternalStore— kein Zustand/Redux/Immer — mit Slices: project/history/selection/view/layout/site/notify). Komponenten lesen Zustand überuseStore(selector)statt Prop-Drilling. - Features als eigene Module:
src/editors/(Inline-Editoren),src/panels/,src/ui/.src/views/undsrc/menus/waren geplant, wurden aber nie angelegt — bei Bedarf gilt das als offener Aufräum-Punkt, nicht als bestehende Struktur. - Ziel: modular + parallel bearbeitbar (verschiedene Features ≠ dieselbe Datei).
UI-Konventionen
- Listen-/Manager-Ansichten als saubere Tabellen: eine Kopfzeile mit Spaltentiteln (sticky), darunter kompakte Datenzeilen mit Inline-Edit pro Zelle. KEINE wiederholten Feld-Beschriftungen pro Zeile. Gilt für Component-/Hatch-/ Line-Manager und ähnliche Listen.
- Dunkler DOSSIER-Stil; kompakt, ruhig, viel Inhalt pro Fläche.
- UI-Text immer übersetzbar (i18n): KEINE hartcodierten sichtbaren Strings im
JSX. Alle Texte über eine Übersetzungsfunktion
t('key')aus einem Wörterbuch (Default-Sprache Deutsch). Keys wie bei DOSSIER (common.delete,layers.settings,topbar.resources). Neue Komponenten gleich mitt(...)schreiben. Identifier/Keys bleiben englisch; nur die Wörterbuch-Werte sind die übersetzbaren Texte.
Native-App-Verhalten (kein Browser-Standard)
Die App soll sich wie ein natives Programm anfühlen, nicht wie eine Webseite:
- Browser-Kontextmenü global unterdrücken (
documentcontextmenu→preventDefault). Nur unser eigenesContextMenuerscheint; auf Flächen ohne eigenes Menü passiert nichts. - Keine Textauswahl / „Alles markieren":
user-select: noneglobal;user-select: textNUR in echten Eingaben (input,textarea,[contenteditable]). Ctrl+A außerhalb von Eingaben unterbinden. - Bild-/Element-Drag aus (
draggable=falsewo nötig); keine Browser-Drag-Gesten.
Architektur-Prinzip
Ein semantisches Modell ist die einzige Wahrheit; jede Ansicht (3D, Grundriss, Schnitt) wird abgeleitet. Darstellung (Detailgrad, Stile, Schraffuren) wird beim Rendern angewandt, nie in die Geometrie eingebacken.
Arbeitsweise (für Beiträge)
- Substanzielle, mehrstufige Arbeit schrittweise in isolierten Schritten angehen.
- Änderungen verifizieren:
npx tsc -b,npm run build, und Screenshot vianode scripts/probe.mjs(schreibtscripts/probe.png) bzw.probe-ff*.mjsfür Firefox-Fälle. Screenshot ansehen und Geometrie visuell prüfen. - Dev-Server läuft via
npm run dev(Vite, Port 5187). Nativer Rahmen plattformabhängig:npm run tauri:devauf macOS,npm run electronauf Linux (WebKitGTK kann kein zuverlässiges WebGPU → dort Chromium/Electron).