Projekt-Status: Welle
welle-3-auswertungaktiv. Meilenstein M2 erreicht — Kern-MVP (Wände, Raumerkennung, OCC-Extrusion, SQLite-Persistenz inkl. Crash-Recovery, Änderungs-Benachrichtigung; welle-1, M1), sichtbarer Qt-6-3D-Viewer (welle-1v, ACC-002) und alle parametrischen Bauteile — Türen/Fenster, Dach, Decken/Fundament, Treppen (welle-2) — sind implementiert. Aktuell: Auswertungen (Flächen/Volumen/Wohnfläche, Material) über einen read-onlyEvaluatePort. Einstieg:harness/README.md.
b-cad ist eine Desktop-Anwendung zur Erstellung, Bearbeitung, Analyse und Visualisierung von Wohngebäuden — Einfamilien- und Mehrfamilienhäuser, Anbauten, Garagen, Nebengebäude. Gebäude werden parametrisch modelliert; 2D- und 3D-Darstellung leiten sich aus einem durchgängigen Datenmodell ab. Zielgruppe: private Bauherren und professionelle Planer.
Wohngebäude-Planung bedient heute zwei getrennte Welten: geführte
Hausplaner für Laien und vollwertige CAD-Systeme für Profis. b-cad
richtet sich an beide Rollen mit einem Werkzeug
(spec/lastenheft.md §2/§3):
- Private Bauherren modellieren ihr Gebäude geführt und ohne CAD-Kenntnisse (OBJ-001) — Räume werden z. B. beim Schließen eines Wandzugs automatisch erkannt (LH-FA-ROM-001).
- Architekten und Planer führen vollständige Planungen durch und tauschen über offene Formate aus — IFC, DXF, STEP, STL (OBJ-005).
- Erweiterbarkeit über ein Plugin-System (OBJ-004) statt Funktions-Monolith.
Ein Modell, viele Sichten. Jedes Bauteil ist parametrisch (OBJ-002); Grundriss, Schnitt und 3D-Darstellung sind abgeleitete Sichten auf dasselbe Gebäudemodell (OBJ-003) — es gibt keine zweite, manuell synchron zu haltende Geometrie. Ändert sich ein Parameter (Wandstärke, Geschosshöhe), folgen alle Sichten in Echtzeit (LH-FA-D3-002).
Die Architektur verkörpert das: ein framework-freier Domain-Kern (hexagonal, ADR-0001) hält das Gebäudemodell; Geometrie-Kern, GUI und Persistenz sind austauschbare Adapter hinter Ports (ADR-0002, ADR-0003).
Das Gebäudemodell ist das Wertobjekt — Datenverlust ist der
Ernstfall. Die Hard Rules des Repos sind genau dort am schärfsten
(harness/conventions.md §Repo-Klasse):
- Atomares Speichern via Temp+Rename — ein abgebrochener Schreibvorgang hinterlässt nie eine halbe Projektdatei (LH-FA-BLD-002, ADR-0003).
- Crash-Recovery ist getestet, nicht behauptet: ein
kill -9-Test (fork+SIGKILL) gehört zur Test-Suite (LH-QA-005). - Definierte Fehler-Codes (
E-IO-001/E-IO-002, …) statt stiller Fehlschläge (spec/spezifikation.md).
Auch der Entstehungsprozess ist abgesichert: Spec führt, Code folgt
— jede Anforderung trägt Akzeptanzkriterien (Happy/Boundary/Negative),
und jede Änderung passiert reale Gates (make gates: Doku-Konsistenz,
Architektur-Regeln, Lint, Tests, Coverage) in einer gepinnten,
reproduzierbaren Toolchain
(ADR-0004).
Dieses Repo ist nach dem AI-Harness-Kurs (Harness Engineering für
Coding Agents) aufgesetzt: Spec führt, Code folgt (Greenfield). Wer hier
— als Mensch oder AI-Agent — etwas ändert, startet bei
harness/README.md und beachtet die Source
Precedence und Hard Rules in AGENTS.md.
| Bereich | Wahl | Entscheidung |
|---|---|---|
| Sprache | C++20 | REQ-TEC-001 |
| Architektur | hexagonal (Ports & Adapters) | ADR-0001 |
| Geometrie-Kern | OpenCascade (hinter Port) | ADR-0002 |
| GUI | Qt 6 (Driving Adapter) | REQ-TEC-002 |
| Persistenz | SQLite (atomar, hinter Port) | ADR-0003, ADR-0006 |
| Build | CMake | REQ-TEC-004, ADR-0004 |
| Tests | GoogleTest | REQ-TEC-005 |
| Observability | OpenTelemetry | REQ-TEC-006 |
| Plugins | Shared Libraries | REQ-TEC-008 |
| Container | Docker DevContainer | REQ-TEC-009 |
b-cad/
├── README.md (diese Datei)
├── AGENTS.md Hard Rules + Source Precedence
├── LICENSE MIT
├── CHANGELOG.md Keep a Changelog (MR-004)
├── Makefile Gate-Targets (make gates / make help; Liste: harness/README §Sensors)
├── CMakeLists.txt hexagonale Target-Trennung (ADR-0001)
├── .devcontainer/ Qt6+OpenCascade+SQLite-Build (make build)
├── harness/
│ ├── README.md Harness-Einstieg: Guides, Sensors, Safety
│ └── conventions.md repo-lokale Strukturregeln (MR-*, Modus pro Sub-Area)
├── spec/
│ ├── lastenheft.md LH-FA-*/LH-QA-*-Anforderungen, Akzeptanzkriterien
│ ├── spezifikation.md Wertebereiche, Fehler-Codes, OTel-Spans
│ └── architecture.md hexagonale Zerlegung, Ports, CMake-Targets
├── src/
│ ├── hexagon/ Kern (model/ ports/ services/) — framework-frei
│ ├── adapters/ Qt/OCC/SQLite (ui/ geometry/ persistence/ io/ plugin/)
│ └── main.cpp Composition Root
├── tests/ GoogleTest (hexagon/ adapters/ e2e/)
├── tools/ Gate-Skripte (arch-check, gate-consistency, suppression-gate) + Dockerfile; docs-check via d-check (MR-007)
└── docs/
├── glossar.md
├── user/releasing.md
└── plan/
├── adr/ ADR-Index + ADR-0001..0012
├── planning/ Slice-Lifecycle (open/next/in-progress/done) + Roadmap
└── carveouts/ dokumentierte Gate-Ausnahmen (derzeit keine)
Stand: welle-3-auswertung aktiv (M3 offen). Umgesetzt: Domain-Kern, Wände, Raumerkennung, OCC-Extrusion, SQLite-Persistenz inkl. Crash-Recovery und Änderungs-Benachrichtigung (welle-1, M1); Qt-6-3D-Viewer (welle-1v, ACC-002); alle parametrischen Bauteile — Türen/Fenster, Dach, Decken/Fundament, Treppen, je inkl. Persistenz (welle-2, M2, ADR-0011); erste Auswertungen —
EvaluatePort+ Flächen/Wohnfläche (slice-017a/b, ADR-0012). Offen: Volumen + Material-/Bauteil-Listen, slice-006 Attribution. Struktur:spec/architecture.md§2.1. Aktueller Stand der Slices:docs/plan/planning/README.md.
harness/README.mdlesen.spec/lastenheft.mdfür das was,docs/plan/adr/README.mdfür das warum so.- Aktuelle Welle:
docs/plan/planning/in-progress/roadmap.md. - Offene Slices:
docs/plan/planning/open/.
MIT — siehe LICENSE. Die Doku-Validierung läuft über
d-check (MIT, digest-gepinntes
Container-Image; Ablösung des vendorten Kurs-Validators:
harness/conventions.md MR-007).