Eine Wahrheit: Manifest & Registry

Jede Definition hat genau eine maßgebliche Beschreibung: ihre manifest.json. Dort stehen ID, Ebene (kind), Version (Semver), Targets, Entrypoints (Server-Renderer, Styles, Client-Controller), Slots, Events, Dependencies und Builder-Metadaten (Kategorie, Icon).

manifest.jsonjson

{
  "id": "component.card",
  "kind": "component",
  "version": "1.0.0",
  "targets": ["web.document", "desktop.shell", "email.client"],
  "entrypoints": { "server": "render.php", "styles": ["card.css"], "client": [] },
  "slots": {
    "media":   { "accepts": ["ui.*"], "max": 1 },
    "default": { "accepts": ["ui.*", "component.*", "layout.*"], "required": true, "multiple": true },
    "footer":  { "accepts": ["ui.*"], "multiple": true }
  },
  "builder": { "category": "Inhalt", "icon": "layout-grid" }
}

Alles andere wird generiert

npm run build scannt die Definitions-Ordner und erzeugt:

cache/registry.cache.php — die Registry als PHP-Array (Laufzeit liest NIE Verzeichnisse)
cache/assets/* — pro Definition kompiliertes CSS (Tailwind-@apply aufgelöst) und JS-Bundles, content-gehasht
dependencies.json, diagnostics.json — Abhängigkeitsgraph und Build-Diagnostik

Der Build ist ein Gate: Schema-Verstöße, falsche ID-Namensräume, fehlende Dateien, unbekannte Targets, Dependency-Zyklen oder CSS mit unbekannten Token-Variablen blockieren mit Exit ≠ 0. Was die Registry nicht kennt, existiert für das System nicht — der Renderer lehnt unregistrierte Definitionen ab.