Der Einführungs-Fahrplan

Die Reihenfolge folgt dem Schichtenmodell von unten nach oben — jeder Schritt liefert sofort nutzbaren Wert und baut auf dem vorigen auf. Genau diesen Weg ist der Prototyp bereits gegangen; er ist die Blaupause.

Inventur der Markenwerte des Bestandssystems: Farben, Größen, Radien, Schatten, Typografie → als Referenz-Tokens (rohe Werte) und semantische Tokens (Bedeutung: „das ist unsere Primär-Aktion") anlegen. Themes für Kunden-Brandings, Target-Schicht für Desktop-Dichte.

✔ Ergebnis: tokens.css — jede spätere Schicht erbt automatisch. Ab jetzt gilt: ein Token ändern = überall geändert.

Inventur der Grundbausteine im Bestand (wie viele Button-Varianten gibt es wirklich?), dann pro Baustein EINE Definition mit Props-Enums statt Wildwuchs: ui.button mit variant primary|secondary|ghost — nicht 14 CSS-Klassen. Formular-Familie, Icons (kuratierte Whitelist), Status-Anzeigen.

✔ Ergebnis: der atomare Standard-Baukasten — ab hier wird nichts Doppeltes mehr gebaut.

Raster, Stapel, Spalten, Reihe als reine Anordnungs-Bausteine — responsive über fluide Mechanik und pro Breakpoint wählbare Props. Damit entfallen Spezial-Container in jedem Feature.

✔ Ergebnis: Anordnung ist komponierbar statt pro Seite handgebaut.

Verhalten mit Slots und Events, kategorisiert nach Ziel: Desktop (Window, Table, Tabs, Toolbar), Website (Navigation, Accordion, Card), Shop (Product-Card, Cart-Line), Formular (Combobox, Date-Picker), Overlay (Modal, Drawer, Toast). Jede Component deklariert, welche Targets sie unterstützt.

✔ Ergebnis: interaktive Standard-Bausteine mit einheitlichem Event-Vertrag.

Fertige Kompositionen, mit denen Nicht-Entwickler Seiten bauen: Marketing (Hero, Features, Pricing, FAQ, Testimonials), E-Commerce (Product-Grid, Checkout-Abschnitte), Application (Page-Heading, Stats), Website (Header, Footer). Schlank parametrisiert — Inhalte kommen aus der Instanz.

✔ Ergebnis: die Sprache, in der Marketing denkt und arbeitet.

Seitengerüste als Slot-Regeln: template.page (Nav Pflicht oben, Fuß Pflicht unten), template.app.shell (Seitenleiste), template.email.message (Fuß Pflicht — eine Abmeldung gehört in jede Nachricht). Sie erzwingen Konsistenz über alle Seiten eines Kanals.

Zwei Anbindungswege, die parallel laufen dürfen:

• Ganze Oberflächen: Surface-JSON → Produktionsrenderer → Target-Profil.
• Fragmente in Bestandsseiten: invisible_render_id('component.card', $props, …) rendert einzelne Bausteine mitten in vorhandene Seiten — schrittweise Ablösung statt Big Bang.

Für den Desktop existiert der eingebaute Übergangsmechanismus: component.window kann Inhalte als legacy-iframe (die heutige Seite läuft unverändert im neuen Fenster weiter) ODER als integrated-page (neue Invisible-Surface) anzeigen. Altes und Neues laufen im selben Desktop nebeneinander — migriert wird App für App.

✔ Ergebnis: Bestandssystem und Invisible koexistieren — kein Stichtag, kein Risiko.

Visuelles Seiten-Bauen und der Publish-Workflow sind das Produkt auf dem Framework (Invisible CMS) — kein Framework-Bestandteil. Der Stand von 2026 liegt in archiv/; ob und wie er wiederkommt, entscheidet die Produktwerdung (PRODUKT-KONZEPT.md).

Das ist der eigentliche Hebel der Architektur: Design wird eine Konfigurationsentscheidung, keine Umbau-Aufgabe.