Das Ebenen-Modell
Eine Standard-Bibliothek, aus der alle Ausgabekanäle gebaut werden — jede Ebene zeigt nur auf die Ebenen unter sich.
Hierarchie
Foundations Design-Tokens (Werte + Bedeutung + Themes)
└── Layouts layout.* Anordnung ohne eigene Optik
└── UI Elements ui.* atomare Bausteine ohne Slots
└── Components component.* Verhalten, Slots, Events
└── Blocks section.* fertige Inhalts-Kompositionen
└── Templates template.* Seitengerüste (Slot-Regeln)
└── Surfaces Konsumenten-Ebene: konkrete Seiten (JSON)
Aktueller Bestand (live aus der Registry): 5 Layouts, 39 Elements, 88 Components, 26 Blocks, 8 Templates — plus Actions und Apps als nicht-visuelle Definitionen. Die Richtung ist Teil des Vertrags und verhindert Zyklen.
Entscheidungsbaum: Wo gehört mein Baustein hin?
- Nur Anordnung (Raster, Stapel, Spalten)? → Layout
- Klein, keine Slots, ein Zweck (Button, Badge, Input)? → Element
- Fachliches Verhalten, Slots, lokaler Zustand, Events (Tabs, Modal, Table)? → Component
- Große Inhalts-Komposition ohne komplexe eigene Runtime (Hero, Pricing, FAQ)? → Block (technisch
section.*) - Regeln für den Seitenaufbau (Navigation Pflicht oben, Footer Pflicht unten)? → Template
Faustregel: primär fachliches Verhalten → Component; primär Layout-/Inhaltskomposition → Block.
Komposition über Slots, Wiederverwendung über Dependencies
- Slots = offene Steckplätze der Instanz-Ebene. Die Card weiß nicht, was in ihr steckt — sie definiert nur Regeln (
accepts,required,max). - Dependencies = feste Definition-zu-Definition-Nutzung.
section.faqrendert interncomponent.accordion;component.tricoma-buttonkomponiertui.button. Das steht im Manifest, der Build prüft Existenz und Zyklenfreiheit, der Asset-Manager lädt die Kette automatisch mit.