# Kontrollierte Templates statt Plugins

URL: https://www.mikebild.dev/de/blog/kontrollierte-templates-statt-plugins/

Sobald ein Agent beliebigen Template-Code hochladen darf, wird aus einer Inhaltsänderung eine Softwareauslieferung. Der hochgeladene Template-Code kann dann Skripte ausführen, Daten nachladen oder den DOM-Aufbau umbauen. Contentkit zieht diese Linie bewusst früher: Autoren und Agenten wählen kontrollierte Presets, Layouts und Darstellungsoptionen – sie liefern keinen ausführbaren Programmcode.

*Teil 8 der Serie „Contentkit – Publishing für Maschinen“.*

Contentkit kann unterschiedliche Informationsarchitekturen und Darstellungsformen abbilden. Themes verändern die Darstellung über erlaubte Design-Tokens. Eigenes CSS deckt begrenzte Sonderfälle ab. Deklarative Patterns komponieren strukturierte Informationen, ohne dafür remote geladenen Programmcode einzuführen.

Der Renderer ordnet den deklarierten Presets und Layouts die repository-eigenen Implementierungen zu. Tokens, CSS und Patterns bleiben begrenzte, deklarative Eingaben; hochgeladener Template-Code bleibt außerhalb des Release-Pfads.

## Fünf getrennte Verantwortlichkeiten

Ein Site-Preset legt die allgemeine Informationsarchitektur einer Website fest. Das einzelne Dokument kann innerhalb dieses Rahmens ein erlaubtes Seitenlayout wählen. Das Theme weist Design-Tokens zu und verändert damit vorgesehene visuelle Eigenschaften.

Begrenztes Custom CSS deckt Sonderfälle ab, die nicht in den Token-Satz passen. Deklarative Patterns beschreiben, wie strukturierte Informationen visuell komponiert werden – über Semantik, Slots, Fähigkeiten, Budgets und responsive Rückfälle. Eine Inhaltsänderung kann innerhalb dieser Verträge Werte und Struktur wählen, aber keine neue Layoutimplementierung oder Laufzeit einführen.

```mermaid
flowchart TD
    P["Site-Preset<br/>Informationsarchitektur"] --> L["Seitenlayout<br/>kontrollierte Darstellung"]
    M["Markdown und<br/>Frontmatter"] --> L
    M --> D["Deklaratives Pattern<br/>Semantik und Slots"]
    D --> V["Gerenderte<br/>Komposition"]
    T["Design-Tokens<br/>Farben und Typografie"] --> C["Theme-Vertrag"]
    X["Begrenztes<br/>Custom CSS"] --> C
    L --> H["Gerenderte Seite"]
    V --> H
    C --> H
```

Diese Teilung verhindert, dass ein Theme zugleich Datenmodell, Navigation und Programmcode definiert. Änderungen an der visuellen Gestaltung bleiben vom strukturellen Vertrag der Inhalte getrennt. Ein Layout wiederum kann die Darstellung eines Dokuments bestimmen, ohne das Site-Preset oder den Theme-Vertrag zu ersetzen.

## Presets für wiederkehrende Informationsarchitekturen

Presets sind im Repository versioniert und vom Renderer implementiert. Sie legen die allgemeine Informationsarchitektur einer Website fest, ohne eine hochladbare Template-Datei oder einen austauschbaren Renderer einzuführen.

Konkret wählt eine Site-Konfiguration ein vorhandenes Preset. Ein Dokument kann innerhalb dieses Presets ein zugelassenes Layout angeben. Der Renderer verarbeitet beide deklarativen Angaben mit den im Repository hinterlegten Implementierungen; der Inhalt liefert weder einen gleichnamigen JavaScript-Renderer noch eigenen ausführbaren Template-Code mit.

Neue Presets oder Änderungen an ihrer Implementierung sind deshalb Softwareänderungen. Inhalte können vorhandene Varianten auswählen, aber den Renderer nicht über eine Inhaltsänderung ersetzen.

## Layouts sind ein geschlossener Vertrag

Ein Dokument wählt ein zugelassenes Layout; der Renderer verwendet dafür die im Repository hinterlegte Implementierung. Die Auswahl stammt aus einer dort festgelegten Menge. Ein Dokument kann kein beliebiges Template referenzieren oder dessen Implementierung mitliefern.

Die Trennung vom Preset ist wichtig. Das Preset gilt für die Website als Ganzes. Das Layout betrifft die erlaubte Darstellung eines einzelnen Dokuments. Weder das Preset noch das Layout übernehmen die Aufgabe des Themes, Farben oder andere visuelle Token zu setzen.

Auch Layout-Erweiterungen bleiben Teil des Repository-Vertrags. Neue Darstellungsformen werden damit wie Änderungen am Renderer behandelt und nicht als beiläufiger Bestandteil einer Inhaltsänderung.

## Deklarative Patterns statt Plugin-Code

Visuelle Kompositionen folgen demselben Modell. Autoren beschreiben Bedeutung und Daten; die Darstellung übernimmt ein repository-eigenes Pattern. Der Vertrag eines Patterns kann Semantik, Slots, Fähigkeiten, Inhaltsbudgets und responsive Rückfälle festlegen.

Patterns laden keinen externen Programmcode nach und bringen keine ausführbare Erweiterung in den Release. Ein Agent kann ein vorhandenes Pattern auswählen oder eine Änderung am versionierten Vertrag vorschlagen. Er kann über den Inhalt jedoch keine neue Laufzeit einschleusen.

Deklarative Struktur, erlaubte Werte und vereinbarte Budgets können gegen den Pattern-Vertrag geprüft werden. Diese Prüfung garantiert nicht, dass jede denkbare Laufzeit- oder Darstellungswirkung bereits erkannt ist.

## Themes sind Zuweisungen an Design-Tokens

Ein Theme arbeitet mit einer begrenzten Menge erlaubter Design-Tokens. Solche Tokens können vorgesehene visuelle Eigenschaften beeinflussen, ohne neue Seitenelemente, Layoutlogik oder ausführbaren Programmcode einzuführen.

Das System definiert, welche Tokens existieren und wo sie wirken. Eine Website weist diesen Tokens Werte zu. Sie kann nicht über einen frei gewählten Token-Namen eine neue Renderer-Funktion erzeugen.

Diese Begrenzung hält Theme-Änderungen prüfbar. Syntax und erlaubte Werte lassen sich gegen den Theme-Vertrag kontrollieren. Ob eine konkrete Kombination lesbar, barrierearm und gestalterisch sinnvoll ist, erfordert zusätzlich eine Prüfung der gerenderten Ausgabe.

## Custom CSS bleibt der begrenzte Ausweg

Nicht jede Markenanforderung passt in einen festen Token-Satz. Dafür kann ein Site-Theme begrenztes benutzerdefiniertes CSS enthalten. Dieser Ausweg ist bewusst kleiner als ein frei programmierbares Template-System.

CSS kann die Darstellung verändern, aber keinen serverseitigen Programmcode ausführen. Folgenlos ist es deshalb nicht. Eigene Regeln können Fokusdarstellungen entfernen, Lesbarkeit verschlechtern, Bedienelemente verdecken oder wichtige Inhalte visuell ausblenden. Die Begrenzung des CSS ersetzt daher keine Prüfung der tatsächlichen Ausgabe.

Custom CSS ergänzt den Theme-Vertrag. Es ändert weder das Site-Preset noch das Seitenlayout und kann keine eigene Renderer-Implementierung bereitstellen. Wo eine Anforderung neue Struktur oder Interaktionslogik benötigt, reicht CSS nicht aus.

## Ein Cockpit als menschlicher Zugang

Im vorhandenen ContentKit-Cockpit können Menschen die deklarativen Eingaben bearbeiten. An der Architekturgrenze ändert diese Oberfläche nichts: Änderungen am Renderer oder an Pattern-Verträgen gehören in das Repository und den normalen Software-Lebenszyklus.

Ein freier Template-Editor wäre dagegen eine andere Produkt- und Sicherheitsentscheidung. Sobald eine Oberfläche ausführbaren Programmcode als Inhalt in den Release-Pfad aufnehmen kann, gelten die beschriebenen Grenzen nicht mehr.

## Beispielszenario: drei Ausgaben, ein Veröffentlichungsweg

Angenommen, eine öffentliche Produktseite, eine Dokumentation und ein Hilfeportal liegen in drei getrennten Systemen. Gemeinsame Änderungen an Namen, Farben oder rechtlichen Hinweisen müssen dann über mehrere Veröffentlichungswege koordiniert werden.

Getrennte Websites oder Bereiche können repository-eigene Presets und Layouts sowie abgestimmte Token-Sätze verwenden. Ein Agent kann die jeweiligen Markdown-Inhalte erzeugen und erlaubte Darstellungsoptionen auswählen. Er erhält dadurch keinen Weg, eigene React-, Liquid- oder andere ausführbare Templates hochzuladen.

Die Ausgaben dürfen sich strukturell und visuell unterscheiden. Entscheidend ist nicht, dass jede Seite gleich aussieht, sondern dass Renderer, Theme und Inhalt getrennte Verträge behalten. Preset, Layout, Design-Token, Pattern und CSS bleiben dabei getrennte Eingaben.

Inhalts- und Darstellungsänderungen sollten gemeinsam als Vorschau geprüft werden; Erweiterungen des Renderers bleiben Softwareänderungen.

## Warum Agenten von weniger Freiheit profitieren

Ein LLM kann Code erzeugen, doch hochgeladener Template-Code erweitert die Wirkung einer Inhaltsänderung erheblich. Er bringt zusätzliche Abhängigkeiten, Ausführungspfade und Prüfanforderungen mit. Bei jeder Änderung müsste geklärt werden, ob neben dem Inhalt auch Software ausgeliefert wird.

Kontrollierte Presets und Layouts begrenzen diesen Suchraum. Der Agent wählt aus dokumentierten Varianten und liefert Inhalte gegen bekannte Verträge. Prüfbar sind dabei insbesondere Syntax, erlaubte Werte und deklarative Strukturen. Laufzeitverhalten, Lesbarkeit und die Wirkung einer konkreten Darstellung bleiben davon getrennte Prüffragen.

Auch die Portabilität profitiert von dieser Grenze. Markdown ohne eingebetteten Template-Code lässt sich leichter in einen anderen Darstellungsrahmen übertragen. Vollständig unabhängig ist der Inhalt dennoch nicht: Frontmatter, Direktiven und Pattern-Verträge können weiterhin systemspezifische Abhängigkeiten enthalten.

## Wo ein anderes System besser passt

Contentkit ist keine allgemeine Webanwendungsplattform. Eine interaktive Fachanwendung mit eigenem Zustand, komplexen Formularen und kundenspezifischer Geschäftslogik braucht Code und damit einen normalen Software-Lebenszyklus. Auch ein pixelgenau frei gestaltbares Kampagnenlabor kann mit einem spezialisierten Page Builder besser bedient sein.

Contentkit passt dort, wo Inhalt, nachvollziehbare Veröffentlichung und wiederkehrende Informationsarchitektur im Mittelpunkt stehen. Der kontrollierte Gestaltungsspielraum ist dann eine Betriebsentscheidung: Darstellungsvarianten sind vorgesehen, beliebiger Template-Code als Inhalt dagegen nicht.

## Theme-Änderungen in der Vorschau prüfen

Änderungen an Design-Tokens oder Custom CSS können die veröffentlichte Darstellung verändern. Sie sollten deshalb zusammen mit den betroffenen Inhalten in einer konkreten Vorschau geprüft und über den kontrollierten Release-Prozess freigegeben werden.

Eine Vorschau muss reale Inhalte berücksichtigen: lange Überschriften, Codeblöcke, Navigation, Tabellen und unterschiedliche Bildschirmgrößen. Ein Theme, das auf einer kurzen Startseite funktioniert, kann bei dichten Inhalten Kontrast-, Fokus- oder Lesbarkeitsprobleme verursachen.

Der begrenzte Vertrag erleichtert diese Prüfung, ersetzt sie aber nicht. Er kann unbekannte Tokens oder unzulässige deklarative Strukturen ausschließen. Ob Farben, Typografie und eigenes CSS in der gerenderten Seite funktionieren, bleibt eine Frage der konkreten Ausgabe.

## Wiederverwendung ohne versteckte Vererbung

Contentkit nimmt keine frei installierbaren Theme-Pakete mit eigener Laufzeitlogik in den Darstellungsvertrag auf. Teams können gemeinsame Token-Sätze trotzdem außerhalb von Contentkit als versionierte JSON-Fragmente pflegen und kontrolliert in die Einstellungen ihrer Websites übernehmen.

Das ist eine mögliche Betriebsweise, keine versteckte Vererbung im Renderer. Der tatsächlich verwendete Token-Satz bleibt in der jeweiligen Site-Konfiguration sichtbar, statt sich hinter einer zentral ausgetauschten ausführbaren Plugin-Version zu verbergen.

## Barrierefreiheit nicht an das Theme delegieren

Im Repository festgelegte Layouts schaffen eine begrenzte Menge wiederkehrender Darstellungsformen. Dadurch können zentrale Prüfungen gezielter ansetzen als bei beliebigem hochgeladenem Template-Code. Eine Garantie für Barrierefreiheit folgt daraus nicht.

Design-Tokens und Custom CSS können Kontrast, Schriftgröße, Fokusdarstellung und die Sichtbarkeit von Bedienelementen beeinflussen. Automatisierte Tests können einige dieser Eigenschaften prüfen. Tastaturbedienung, verständliche Linktexte und die Wirkung langer Inhalte benötigen zusätzlich eine Prüfung der tatsächlichen Ausgabe.

Der bekannte Darstellungsvertrag macht den Prüfumfang beherrschbarer. Custom CSS bleibt trotzdem wirksam genug, sichtbare und funktionale Probleme zu verursachen. Sein begrenzter Umfang ist kein Freibrief.

## Fazit

Die Betriebsentscheidung lautet: Betreiber nehmen keinen hochgeladenen ausführbaren Template-Code in den Release-Pfad auf. Unterschiedliche Websites entstehen stattdessen über versionierte Presets und Layouts, erlaubte Design-Tokens, begrenztes CSS und deklarative Patterns.

Benötigt eine Anforderung neue Struktur oder Laufzeitlogik, gehört sie als geprüfte Softwareänderung in das Repository und nicht in den Inhalt.

## Weiterführende Quellen

- [Contentkit Presets und Seitenlayouts](https://github.com/MikeBild/contentkit/blob/ecf27cd8ebb7850b6a48c874898f33fcbba5f615/docs/TEMPLATES.md)
- [Contentkit Visual Compositions und Pattern Packages](https://github.com/MikeBild/contentkit/blob/202f2376a965b292c161e7bdbf1d210176c86b38/docs/VISUAL_COMPOSITIONS.md)
- [Contentkit Information Blocks](https://github.com/MikeBild/contentkit/blob/16c00b82f918b6f3f9db8baaf1ae258791229bed/docs/INFORMATION_BLOCKS.md)
- [Contentkit Architektur: Themes ohne Template-Overrides](https://github.com/MikeBild/contentkit/blob/029d98178536c63cc6e80e766212d6c19ffbb832/docs/ARCHITECTURE.md)