Tekton — Architektur gemeinsam über ein einheitliches Modell entwickeln
Was es ist
Ein Substrat für die Architekturpartnerschaft zwischen Mensch und KI-Agent. Der Entwurf lebt in einem YAML-Modell, das wir beide bearbeiten; Git ist der Roundtrip. Du siehst es (HTML-Viewer); ich lese und schreibe das gleiche Modell. Wir denken im selben Kontext.
Der Fehler, den es behebt: Ein handgeschriebenes HTML/SVG-Dokument ist ein terminales Rendering – du kannst es nicht traversieren, abfragen oder zurückbearbeiten, und seine Diagramme tragen keine Bedeutung. Tekton verschiebt das Live-Modell stromaufwärts des Renderings.
Engine
scripts/tekton.py (Python 3, pyyaml). Ontologie in references/ontology.md.
python3 scripts/tekton.py validate <model.arch.yaml> # Integritätsprüfung
python3 scripts/tekton.py lint <model.arch.yaml> # v0.2 — Fitnessfunktionen; Exit 1 bei Verstoß
python3 scripts/tekton.py stats <model.arch.yaml> # Knoten/Kanten/Status/Regel-Zählungen
python3 scripts/tekton.py views # Liste der 6 Sichten
python3 scripts/tekton.py mermaid <model.arch.yaml> <view># Roh-Mermaid (Einbettung/Agent)
python3 scripts/tekton.py render <model.arch.yaml> [-o out.html] # Markenkonformer HTML-Viewer
python3 scripts/tekton.py query <model.arch.yaml> <from> <to> # Sichtübergreifender Pfad
v0.2 Ontologie-Upgrades (aus der Architekturüberprüfung)
- Enthaltenseinsbeziehung —
parent:bei jedem Knoten + Typboundary; Viewer rendert verschachtelte Gruppen, Doppelklick zum Einklappen/Ausklappen (C4-ähnlicher Drill-Down). - Lebenszyklus —
status:an Knoten (current|target|deprecated; target wird gestrichelt dargestellt = Ist/Soll in einem Modell) und vollständige Nygard-ADR-Felder an Entscheidungen (context,consequences,status,supersedes). - Qualitäten —
qualities:-Block; NFRsconstrains-Elemente; dargestellt im Detail-Panel + eigener Sicht. - Fitnessfunktionen —
rules:-Block (forbid-dep,no-cycle,layer-order);tekton lintist CI-gateable (Exit 1). Der unabhängige Verifizierer der Designschleife.
Wie der Agent es in einer Design-Sitzung nutzt
- Modell finden/erstellen:
<project>/docs/design/<name>.arch.yaml(oderexamples/für Spielwiese). - Mutieren während des Denkens — Knoten, Kanten, Entscheidungen direkt im YAML hinzufügen/anpassen, während das Gespräch Komponenten, Flows, Daten, Infrastruktur und ADRs zutage fördert.
validate+lintnach jeder substanziellen Änderung (verwaiste Referenzen, falsche Typen, Fitnessregeln).render, dann – BEVOR der Viewer als korrekt präsentiert wird – die Geometrie-Prüfung ausführen:bash tests/visual-audit.sh <model.arch.yaml>. Es rendert jede Sicht headless und SCHLÄGT FEHL bei Knotenüberlappungen oder leeren Aufnahmen. Zu behaupten, „das Diagramm ist korrekt“, ohne diesen Test, ist genau der Fehler, den das erste Dogfood aufgedeckt hat (nicht verbundene In-Group-Kanten, doppelte Knoten – unsichtbar für DOM-Zählung, erkannt nur durch Geometrie). Deep-Link zu einer Sicht mit#<view>in der URL.query, um Traceability-Fragen zu beantworten („Was berührt das?“), anstatt zu raten.- Steuern → wiederholen. Der Mensch bearbeitet das YAML oder die Viewer-Intention; der Git-Diff ist die Übergabe.
Bekannte kosmetische Reste (keine Prüfungsfehler): Journey-Rückkopplungskanten zwingen ELK, den Zyklus an einem beliebigen Schritt zu brechen (eine Schleife muss irgendwo brechen); benachbarte parallele Kantenbeschriftungen können in dichten Gruppen nah beieinander liegen.
Konventionen
- Modell-Dateien:
*.arch.yaml. Gerenderter Viewer:*.view.html(gitignore oder committen – deine Entscheidung). - Ein Modell pro abgegrenztem System; Systeme mit
external-Knoten +uses-Kanten verknüpfen. - Entscheidungen (ADRs) sind erstklassige Knoten – verknüpfe sie mit dem, was sie
govern. - Category-C HTML-Berichte werden zu einem Downstream-Export eines Modells, nicht zur Quelle der Wahrheit.
Rendering – warum nicht Mermaid
Der primäre Viewer ist ein benutzerdefinierter Renderer, nicht Mermaid. Mermaid theming ceiling kann das Broomva Design System nicht ausdrücken (OKLCH-Blauachse, matte Karten, earned glass, comet-glow) und sein dagre-Layout degradiert auf dichten Graphen. Stattdessen: elkjs berechnet das Layout im Browser (reines JS → die Ausgabe bleibt eine einzige, in sich geschlossene HTML-Datei), und Knoten werden als Broomva-Mattkarten gezeichnet (Glas bleibt dem schwebenden Detail-Panel vorbehalten, gemäß der „Glas wird verdient“-Regel des DS). Design-Tokens sind aus dem Broomva Design System inline eingefügt. tekton mermaid bleibt NUR als Einweg-Einbettungs-/Agent-lesbares Ziel bestehen.
Roadmap (v0 → v2)
- v0.2 (jetzt): YAML-Modell · validate + lint (Fitnessfunktionen) · 6 Sichten · on-brand elkjs-Viewer (Containment einklappen/ausklappen, Ist/Soll, Klick-zu-Trace, Glas-Detail-Panel) · sichtübergreifende Abfrage · Mermaid-Fallback-Einbettung.
- v1: bidirektionaler Roundtrip (ziehen/bearbeiten im Viewer → zurück ins YAML serialisieren); MCP-Server (validierte Mutationen, damit der Agent kein ungültiges Modell ausgeben kann); das vollständige Broomva Design System für eine React-Flow interaktive Leinwand als Anbieter.
- v2: CRDT (loro) Echtzeit-Mensch↔Agent-Co-Editing; Live-Synchronisation in Prosopon als Oberfläche.
Status
v0 Dogfood – internes Design-Werkzeug. Skillify (getestet + registriert), sobald die Design-Schleife auf ≥3 realen Systemen eingesetzt wurde (Drei-Regel).