86 lines
4.7 KiB
Markdown
86 lines
4.7 KiB
Markdown
# Entscheidungen (ADR-Kurzform)
|
|
|
|
Festgehaltene Design-Entscheidungen samt Begründung. Bei Änderungen: Eintrag
|
|
ergänzen, nicht löschen.
|
|
|
|
## D1 — `|` für Oder-Zerlegung, `-` für Und-Zerlegung
|
|
`|` bedeutet in Regex und BNF-Grammatiken bereits „oder“ und ist damit
|
|
selbsterklärend. `-` ist das gewohnte Markdown-Listenzeichen für „normale“
|
|
Teilpakete. Das Gate steckt im Aufzählungszeichen der Kinder, nicht in einer
|
|
Annotation am Parent — lokal lesbar, trivial parsebar.
|
|
|
|
## D2 — Status als erweiterte Markdown-Task-Checkbox
|
|
GitHub-Markdown kennt `[ ]`/`[x]`; die Erweiterung auf `[?] [~] [/] [^] [-]`
|
|
wirkt sofort vertraut. Mnemonik: `?` vage, leeres Kästchen = todo, `~` gängige
|
|
In-progress-Konvention, `/` = halbes `x`, `x` = erledigt, `^` = „nach oben
|
|
deployed“, `-` = durchgestrichen.
|
|
|
|
## D3 — Begriff „Durchstich“ für den Zwischenstatus
|
|
Zustand zwischen „in Arbeit“ und „fertig“: durchgängig funktionsfähig und
|
|
vorführbar, Feinarbeiten offen. „Durchstich“ ist als Fachbegriff (Tunnelbau,
|
|
End-to-End-Slice in der Softwarearchitektur) etabliert. Verworfene
|
|
Alternativen: „Feinschliff“, „Richtfest“, „vorführbereit“, „Beta“.
|
|
|
|
## D4 — Begriff „verworfen“ statt „gestrichen“
|
|
Beschreibt die bewusste Entscheidung gegen eine Option — besonders passend
|
|
für Any-of-Alternativen. Default ausgeblendet, Toggle „verworfene einblenden“.
|
|
|
|
## D5 — Farb-Logik folgt dem Risiko, nicht dem Fortschritt
|
|
Rosé = Kosten investiert, Risiko hoch (in Arbeit). Pastellgelb = läuft,
|
|
Restrisiko klein (Durchstich). Flieder = geplant (Absicht, nichts investiert,
|
|
zwischen Grau der Idee und Rosé der Arbeit). Ergebnis-Skala:
|
|
grau → flieder → rosé → gelb → grün → blau.
|
|
|
|
## D6 — Größe in Klammern, URL nackt, Personen mit `@`
|
|
`(M)` liest sich wie ein Kleidungsetikett. URLs werden ohne Link-Syntax
|
|
erkannt (einfach einfügbar); die URL wird **vor** den `@`-Tags extrahiert,
|
|
damit `https://user@host/…` nicht kollidiert. `@` ist die universelle
|
|
Mention-Konvention (GitHub, Slack, Jira).
|
|
|
|
## D7 — `%%` als Kommentarzeichen
|
|
Mermaid-Konvention; hält den Weg zum Mermaid-Plugin frei. `//` scheidet wegen
|
|
URLs aus, `#` bleibt für Referenzen/Tags reserviert, `<!-- -->` ist zu sperrig.
|
|
|
|
## D8 — Untergliederungspflicht ab M sichtbar machen
|
|
Fehlende Zerlegung wird nicht nur gemeldet, sondern **gezeigt**: Geister-Knoten
|
|
„Untergliederung fehlt“ hängt genau dort, wo der Ast weitergehen müsste.
|
|
Verworfene Elemente sind ausgenommen. Werden alle Kinder eines M+-Elements
|
|
verworfen und ausgeblendet, erscheint der Platzhalter wieder (es braucht eine
|
|
neue Zerlegung) — gewollt.
|
|
|
|
## D9 — Transponierte Darstellung mit unterschiedlichen Austrittsseiten
|
|
Im vertikalen Modus tritt all of **rechts** aus dem Parent aus (LR-Baum),
|
|
any of **unten links**. Austrittsseite + Linienstil (durchgezogen/gestrichelt)
|
|
codieren das Gate doppelt; Beschriftungen werden nie rotiert.
|
|
|
|
## D10 — Abzweige zielen auf Knotenmitte, nicht Teilbaummitte
|
|
Feste Knoten-Zeilenhöhe macht die Anschlusshöhe deterministisch (23 px).
|
|
Behebt „ins Leere laufende“ Linien bei eingerückten Unterbäumen.
|
|
|
|
## D11 — Technologie: Vanilla HTML/CSS/JS, eine Datei als Prototyp
|
|
Keine Frameworks, kein Build-Zwang. Parser ~30 Zeilen, Renderer erzeugt
|
|
verschachtelte `ul.and`/`ul.or`; Linien via CSS-Pseudo-Elemente. Modularisierung
|
|
(Parser/Renderer/UI getrennt + Tests) ist der geplante nächste Schritt.
|
|
|
|
## D12 — Name „Werkbaum" und Marke aus der Notation
|
|
Name: „Werk" + „Baum" = wörtlich der WBS-Baum; funktioniert als npm-Paket,
|
|
CLI-Befehl und Mermaid-Schlüsselwort (`werkbaum`, kleingeschrieben in
|
|
Code-Kontexten). Verworfene Kandidaten: Astrein, undoder, Aufriss, Gabelung.
|
|
Marke: Miniatur des Diagramms (K2) in zwei Orientierungen analog zu den
|
|
Darstellungsmodi — Hochformat als Primärzeichen, transponiert als
|
|
Sekundärzeichen. Nur Tinte + Petrol; durchgezogen = und, gestrichelt = oder;
|
|
Pastelltöne bleiben Statusfarben. Details: brand/BRAND.md.
|
|
|
|
## D13 — Backend in Kotlin/Spring Boot, Monorepo-Struktur
|
|
Backend als Kotlin/Spring-Boot-Anwendung (Gradle Kotlin DSL, JDK 21),
|
|
entwickelt in IntelliJ IDEA Ultimate. Monorepo mit `frontend/` und `backend/`;
|
|
CLAUDE.md dreistufig: Wurzel für Querschnitt, je eine pro Teilprojekt
|
|
(wird von Claude Code pfadbezogen geladen). Kein Node- oder Python-Backend.
|
|
|
|
## D14 — Parser-Hoheit liegt beim Frontend, SPEC ist normativ
|
|
Der Notationstext ist das führende Datenformat. Das Backend parst die
|
|
Notation nicht; es speichert den Text als Ganzes und bedient Integrationen
|
|
über explizite Metadaten. Wird Backend-Parsen später doch erforderlich,
|
|
gilt: docs/SPEC.md ist normativ, beide Parser testen gegen dieselben
|
|
Fixtures (SPEC §10) — es darf keine zweite, abweichende Grammatik entstehen.
|