ContentKit: Cockpit und API in einer Domäne

Diesen Beitrag anhören (13 Min.)

Stand 16. August 2026 gilt: Eine gespeicherte Inhaltsänderung im Content-Editor des ContentKit-Cockpits erzeugt eine unveränderliche Revision derselben Art wie ein Upload über die HTTP-API. Das eingebettete Web-Cockpit übernimmt den menschlichen Zugang zu Administration, Inhalten, Vorschauen, Releases und Audit. REST und MCP greifen auf dieselben fachlichen Zustände zu. Entwurf, Vorschau und Veröffentlichung bleiben dabei getrennt.

Teil 1 der Serie „ContentKit – Publishing für Maschinen“.

Die ContentKit-Patternübersicht ordnet Darstellungen nach Kommunikationsaufgabe und veranschaulicht den Weg von Semantik zum Rendering

Cockpit, REST und MCP teilen eine Domäne

Ein zusätzlich ausgeliefertes Cockpit könnte einen zweiten Persistenz- oder Rechtepfad einführen. ContentKit tut das nicht. Das Cockpit ist der menschliche Zugang zur gleichen Veröffentlichungsdomäne, kein zweiter Persistenzpfad und keine Ausnahme von der gemeinsamen Domänenlogik.

Der Content-Editor im Cockpit speichert jede Änderung als neue unveränderliche Revision – dieselbe Revisionsart, die auch ein Upload über die HTTP-API erzeugt. Es gibt kein „Cockpit-Dokument“, das an der Revisionshistorie vorbei verändert wird. Speichern erzeugt eine unveränderliche Revision; eine Vorschau wird separat gebaut und ihre Promotion separat bestätigt. Öffentliche Wirkung entsteht entweder durch einen direkten Release oder durch die Promotion einer geprüften Vorschau; nur die Promotion bindet den vorher geprüften Kandidaten an Manifest und Publish-Epoch. Das Cockpit verwendet dieselben Identitätsgrants und Produkt-Scopes wie andere Zugänge. Zugangstoken bleiben aus dem Browser heraus, Cookie-authentifizierte Mutationen sind mit einem CSRF-Nachweis geschützt. Ohne den erforderlichen Release-Scope darf derselbe Zugang auch über REST oder MCP keinen Release aktivieren.

Das ContentKit-Cockpit gliedert sich unter anderem in Bereiche für Inhalte, veröffentlichte Inhalte, Releases, Zugriff, Audit und System; alle Routen zeigt der verlinkte Router. Der Content-Editor speichert Revisionen und baut getrennt Vorschauen.

Das Cockpit ordnet keine Boxen auf einer Leinwand an und lädt keine Erweiterungen nach. Wer freie Seitenlayouts per Drag-and-drop bearbeiten muss, benötigt eher ein Page-Builder-CMS. ContentKits Cockpit bearbeitet Revisionen, Vorschauen, Releases und Rechte; der Audit-Bereich zeigt die protokollierten Einträge.

Der Vertrag besteht aus Markdown, HTTP und MCP

Die Eingabe ist eine Markdown-Datei mit YAML-Frontmatter. Sie lässt sich in Git versionieren, im Code-Review lesen, mit Standardwerkzeugen vergleichen und von Agenten mit Datei-Zugriff bearbeiten. Die HTTP-API trennt vier Operationen in eigene Endpunkte: POST /v1/sites/{site}/content erzeugt eine unveränderliche Revision, POST /v1/sites/{site}/previews baut eine benannte Vorschau, POST /v1/sites/{site}/releases einen direkten Release und POST /v1/sites/{site}/releases/{release}/promote promotet eine geprüfte Vorschau. Ungültiges Frontmatter oder eine ungültige Locale wird mit 422 abgelehnt, bevor irgendetwas öffentlich wird.

flowchart LR
    Q["Quellsystem<br/>oder Repository"] --> A["Agent oder Mensch<br/>erzeugt Markdown"]
    A --> V["ContentKit<br/>prüft den Vertrag"]
    V --> P["Vorschau<br/>unveränderlicher Kandidat"]
    P --> R["Atomarer Release<br/>statische Website"]
    R --> H["Menschen<br/>lesen und suchen"]
    R --> M["Maschinen<br/>lesen LLM-Ausgaben und Markdown"]

Ein Agent muss keinen Redakteur vor einem Bildschirm nachbilden. Er erzeugt eine Datei und ruft einen dokumentierten Endpunkt auf. POST /content erzeugt eine Revision, ein Preview-Endpunkt baut einen vollständigen Kandidaten, ein Release-Endpunkt erzeugt und aktiviert einen neuen veröffentlichten Stand. Revisions-ID, Release-ID und Statuscode machen diese Operationen protokollierbar und testbar. Ungültiges Frontmatter und ungültige Locales liefern reproduzierbar 422 statt eines UI-abhängigen Dialogs.

Agenten arbeiten deshalb mit Revisionen, Vorschauen und Releases statt mit Klickfolgen. Browser-Automatisierung gegen ein Cockpit wäre technisch möglich, aber ein Notbehelf – die API drückt dieselbe Domäne direkter aus.

Unveränderliche Revisionen und atomare Releases

Jeder Upload erzeugt eine neue unveränderliche Revision; eine bestehende wird nie überschrieben. Ein Release rendert daraus einen vollständigen statischen Stand – HTML, Suchindex, Sitemap, Feeds, Assets – und aktiviert ihn atomar über einen Zeiger. Scheitert eine Prüfung beim Bau, bleibt der aktive Release unberührt. Es gibt keinen Zwischenzustand, in dem nur ein Teil der Seiten aktualisiert ist.

stateDiagram-v2
    [*] --> Draft: Markdown hochladen
    Draft --> Preview: Kandidaten bauen
    Preview --> Active: Promotion nach Bestätigung
    Draft --> Active: direkter Release
    Draft --> Draft: neue Revision
    Active --> KnownRelease: neuer Release
    KnownRelease --> Active: Zeiger zurücksetzen

Der Rollback ist folglich kein erneuter Build und keine Rückwärtsmigration. ContentKit setzt den aktiven Zeiger auf einen bekannten Release zurück, dessen Dateien bereits existieren. Eine fehlerhafte Dokumentationsänderung lässt sich dadurch ohne erneuten Build zurücknehmen; die Ursache kann anschließend untersucht und als neue Revision veröffentlicht werden. Die Dateien des Ziel-Releases bleiben unverändert.

Die Vorschau-Promotion als Veröffentlichungsgrenze

Stand 16. August 2026 bindet die Promotion einer unveränderlichen Vorschau den geprüften Kandidaten an die Release-Aktivierung. Sie verbindet dabei drei Werte: die Release-ID des Kandidaten, den Manifest-Digest der gerenderten Ausgabe und den vorherigen Veröffentlichungsstand. Die Preview-Antwort stellt dafür release_id, manifest_sha256, base_publish_epoch und die beteiligten revision_ids bereit; README und MCP-Vertrag binden diese Felder an Promotion und Audit.

Die Promotion aktiviert dann exakt diese gerenderten Bytes – oder sie scheitert. Weicht das Manifest ab oder hat sich der Veröffentlichungsstand seit dem Bau der Vorschau verändert, schlägt die Publish-Epoch-Prüfung fehl und der öffentliche Stand bleibt, wie er ist. Promotet wird genau der Kandidat, der zur menschlichen Prüfung bereitgestellt und bestätigt wurde. Ein direkter Release-Aufruf ohne Vorschau ist weiterhin möglich und trägt diese Bindung nicht automatisch. Die Bindung aus Release-ID, Manifest-Digest und Publish-Epoch-Schutz sichert die Identität des promoteten Kandidaten, nicht seine fachliche Richtigkeit – ob eine Migrationsanleitung inhaltlich stimmt, muss die Prüfung davor klären.

Für die Promotion einer geprüften Vorschau gehört die menschliche Bestätigung zum Protokoll. Über MCP erfordern Veröffentlichen, Aktivieren und Zurückziehen die passende Release-Berechtigung und eine explizite menschliche Bestätigung per MCP-Elicitation; Abbruch, Ablehnung oder Zeitüberschreitung verändern den öffentlichen Stand nicht. Der MCP-Fallback bindet den Review-Link an Release-ID und Manifest-Digest. Bevor promotet wird, persistiert ContentKit eine Audit-Zeile mit dem bestätigenden Menschen und dem Manifest; die Promotion selbst wird danach separat auditiert. Ein MCP-Autorenworkflow kann diese unabhängige menschliche Freigabe nicht selbst erteilen.

MCP verwendet dieselbe Domänenlogik

ContentKit besitzt eine Remote-MCP-Oberfläche unter /mcp. Sie verwendet dieselbe Repository-, Release-, Berechtigungs- und PostgreSQL-Domainlogik wie REST – sie ist weder ein zweiter Speicherpfad noch eine Eins-zu-eins-Abbildung aller HTTP-Endpunkte. REST adressiert feste Pipelines; MCP stellt Agenten auffindbare, nach Berechtigungen gefilterte Domänenoperationen bereit.

Die Autorenoperationen umfassen Entwürfe, semantische Kompositionen, Deck-Rendering und isolierte Vorschauen. Entwürfe und isolierte Vorschauen benötigen über MCP keinen Bestätigungsdialog. Über MCP liegt die Grenze zur öffentlichen Wirkung bei Release-Rechten und dieser expliziten Bestätigung. Das Cockpit verwendet dieselben Scopes und Release-Zustände.

Für die Korrelation des veröffentlichten Stands sind Revision und aktivierter Release maßgeblich. Bei der Vorschau-Promotion wird zusätzlich der bestätigende Mensch auditiert.

Berechtigungen trennen Rollen, nicht Oberflächen

ContentKit trennt Site-Administration, Content-Schreiben, Preview und Release über eigene Scopes. Ein site:admin-Schlüssel darf Websites und weitere Schlüssel verwalten, besitzt aber nicht automatisch Veröffentlichungsrechte. Ein Publishing-Schlüssel darf Inhalte und Releases bearbeiten, aber nicht automatisch Sites administrieren. Ein Agent, der ausschließlich veröffentlichte Texte recherchiert, sollte nur Lesezugriff erhalten. Das Recht zum Hochladen von Revisionen erlaubt deshalb keine Release-Aktivierung.

Diese Trennung gilt unabhängig vom Zugang. Das Cockpit filtert seine Bereiche nach denselben Grants, MCP filtert seine Operationen danach, REST lehnt außerhalb des Scopes ab. Außerhalb der für MCP-Veröffentlichungen vorgeschriebenen menschlichen Bestätigung entscheidet die Organisation über weitere Freigabeschritte. Die Scopes verhindern, dass fehlende Release-Rechte allein durch den Wechsel zwischen Cockpit, REST und MCP umgangen werden.

Ein Release erzeugt menschliche und maschinenlesbare Ausgaben

Der statische Release enthält Navigation, Suche, RSS, Sitemap und maschinenlesbare LLM-Ausgaben. Ein veröffentlichter Stand kann pro Locale llms.txt, llms-full.txt und Markdown-Zwillinge enthalten. Geschützte Inhalte werden aus diesen öffentlichen Discovery-Ausgaben entfernt und sind nur innerhalb des passenden Reader-Grants sichtbar. Es gibt keinen Zwischenzustand, in dem eine Seite bereits gesperrt ist, ihr Titel aber noch in der öffentlichen Discovery auftaucht – Sichtbarkeit wechselt mit dem Release, nicht dokumentweise.

Agentenketten können auch die veröffentlichte Ausgabe als Quelle verwenden: Ein Agent erzeugt Inhalt, ein anderer liest später die öffentliche Ausgabe oder greift mit passendem Reader-Grant auf geschützte Inhalte zu – ohne HTML aus einer Autorenoberfläche herauslösen zu müssen.

Semantische Direktiven steuern das Rendering

Semantische Direktiven im Markdown werden über Semantic AST, Narrative, Composition und ein repository-eigenes Pattern Package in responsive Darstellungen überführt. Die Dokumentation der visuellen Komposition beschreibt diese Verantwortungsgrenzen. HTML und SVG sind Ausgaben derselben aufgelösten Semantik; PNG entsteht nur auf ausdrückliche Anforderung.

:::process{title="Release path" preferredPattern="connected-process"}
- Validate source
- Build revision
- Verify preview
- Promote release
:::

Ein Agent gibt keine Koordinaten, Schriftgrößen oder SVG-Pfade vor. Er beschreibt einen Prozess, einen Vergleich oder eine Metrik und darf eine Erzählform vorschlagen. Bei einer schmalen Einbettung wird aus einer waagerechten Prozesskette eine senkrechte Folge; die Aussage bleibt gleich, nur die Anordnung ändert sich.

Gemeinsame Bedienmuster ohne geteilte Laufzeit

SubKit, WikiKit, WatchKit, WorkKit, CodeKit und ContentKit liefern jeweils ein eigenes fachliches Cockpit aus. Sie verwenden gemeinsame Begriffe und Interaktionsmuster, importieren aber keine gemeinsame Laufzeit-Oberfläche. Jedes Produkt behält seine eigene Domänennavigation, seine eigenen Rechte und seine eigenen Zustandsmodelle. Die Produktgrenzen sind in den Cockpit-Dokumenten von SubKit, WikiKit, WatchKit, WorkKit, CodeKit und ContentKit dokumentiert. Ein WikiKit-Review ist keine ContentKit-Veröffentlichung, und ein ContentKit-Release entscheidet nicht, welches Wissen wahr ist.

Was im Betrieb beobachtbar bleibt

Revision, Vorschau, Release und auslösender Akteur bleiben korrelierbar. Der Upload liefert die Revisions-ID, die Preview-Antwort nennt Release-ID, Manifest-Digest und Basis-Epoch, die Promotion hinterlässt Audit-Zeilen mit bestätigendem Menschen. Release-Ereignisse werden als signierte Webhooks an nachgelagerte Systeme gemeldet; die Release-Aktivierung ist der Zustandswechsel, der den neuen Stand öffentlich aktiviert.

Ein Supportfall kann eine Release-ID nennen. Von dort lässt sich die Revision und – bei persistierter externer Korrelation – der auslösende Lauf oder Mensch ermitteln. Die Ablaufhistorie kann außerhalb von ContentKit liegen; Revisions-ID, Release-ID und Audit-Einträge müssen korrelierbar bleiben.

Fazit

ContentKit ist für datei- und API-basierte Abläufe ausgelegt: Markdown bleibt als Datei versionierbar und übertragbar, REST dient als Dienstvertrag und MCP als Agentenzugang. Das Cockpit ergänzt diese Zugänge für Menschen. Ein direkter Release bleibt ein eigener Veröffentlichungsweg. Wer dagegen die Bindung zwischen geprüftem Kandidaten und öffentlichem Stand benötigt, verwendet die manifestgebundene Preview-Promotion mit einer menschlichen Bestätigung, die der ausführende Workflow nicht selbst erteilen kann.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare