contentkit

Ein teilweise aktivierter Build lässt keinen eindeutigen öffentlichen Stand erkennen. ContentKit verhindert genau diesen Zustand. Jeder Content-Upload erzeugt eine unveränderliche Revision, jeder Release rendert einen vollständigen statischen Stand, und die Aktivierung verschiebt einen einzigen Zeiger. Entweder ist der neue Stand vollständig öffentlich oder der alte bleibt es. Einen Zwischenzustand gibt es nicht.

Diese Website läuft auf ContentKit.

Stack: Node.js · PostgreSQL · Markdown · statische Ausgabe Code: github.com/MikeBild/contentkit · MIT-Lizenz

Eine Veröffentlichungsdomäne, mehrere Zugänge

ContentKit verbindet portable Markdown-Quellen, ein eingebettetes Web-Cockpit, unveränderliche Revisionen, semantische Darstellungen und atomare Releases in einer Veröffentlichungsdomäne. Inhalt, Rendering, Freigabe, Aktivierung und die Rückkehr zu einem bekannten Stand liegen in dieser Domäne. API, MCP und Cockpit greifen dabei auf dasselbe Inhaltsmodell zu.

Auf dieses Modell führen drei Zugänge. Die HTTP-API ist der Dienstvertrag für Skripte, Pipelines und andere Systeme. Die Remote-MCP-Oberfläche unter /mcp gibt Agenten einen domänenorientierten Zugang; sie arbeitet über dieselben Repositories, Release-Regeln, Berechtigungen und dieselben PostgreSQL-Daten wie REST. Das Cockpit unter /cockpit ist die menschliche Oberfläche derselben Domäne. Es verwendet dieselbe API und dasselbe Inhaltsmodell wie die anderen Zugänge und führt keinen zweiten Persistenzpfad ein. Es gibt kein „Cockpit-Dokument“, das an der Revisionshistorie vorbei verändert würde. Wer im Cockpit speichert, erzeugt exakt die Revisionsart, die auch ein API-Upload erzeugt.

Diese Konstruktion hat eine konkrete Folge für Berechtigungen: API, MCP und Cockpit wenden dieselben Berechtigungen und Release-Regeln an.

Markdown als portable Quelle

Markdown bleibt die portable Inhaltsquelle – als Datei versionierbar, per Diff vergleichbar und übertragbar. Die Quelle bleibt außerhalb des Cockpits lesbar und mit gewöhnlichen Werkzeugen versionierbar. Die semantischen Direktiven für Visualisierungen stehen im selben Markdown; sie sind Teil der Quelle, nicht Zustand einer Editor-Sitzung.

Aus diesem Modell veröffentlicht ContentKit Seiten, Beiträge, Projekte, Dokumentation, Reports und semantische Decks.

Bewusst nicht enthalten ist ein visueller Page-Builder. Der Grund ist nicht Sparsamkeit, sondern die Frage, was die Wahrheitsquelle sein soll. ContentKit hält Markdown als Quelle und behandelt die gerenderte Ausgabe als Ableitung. Damit bleibt der Inhalt zwischen Datei, API, Agent und Cockpit ohne zusätzliches proprietäres Dokumentformat beweglich.

Unveränderliche Revisionen

Jeder Content-Upload erzeugt eine neue unveränderliche Revision; bestehende Revisionen werden durch einen neuen Upload nicht überschrieben. Das gilt für den API-Upload aus einer Pipeline genauso wie für das Speichern im Cockpit.

Korrekturen bleiben nachvollziehbar. Ein veröffentlichter Bericht wird nicht still überschrieben; eine neue Revision trägt die Korrektur, und die alte bleibt als Nachweis erhalten. Ein Rollback aktiviert einen bekannten früheren Release-Stand über den Site-Zeiger – niemand muss rekonstruieren, welche Dateien damals wie aussahen.

Release und atomare Aktivierung

Ein Release rendert aus den ausgewählten Revisionen einen vollständigen statischen Stand. Dieser Stand entsteht unter einem neuen Präfix, getrennt vom aktiven. Erst die Aktivierung setzt den Site-Zeiger atomar auf das neue Präfix um.

Die Trennung verhindert eine teilweise Aktivierung. Scheitert eine Prüfung während des Baus, existiert der Kandidat schlicht nicht als öffentlicher Stand – der aktive Release bleibt unberührt. Es gibt keinen Zustand, in dem ein halber Build ausgeliefert wird, weil die Auslieferung nie aus dem Verzeichnis liest, in das gerade geschrieben wird. Ein Rollback ist die gleiche Operation in die andere Richtung: Der Zeiger zeigt wieder auf ein früheres Präfix.

Vorschau, Manifestbindung, menschliche Promotion

Zwischen Vorbereitung und öffentlicher Wirkung liegt in ContentKit eine ausdrückliche Grenze. Eine unveränderliche Vorschau ist ein vollständig gebauter Kandidat, der noch nicht aktiv ist. Sie liefert vier Werte: die Release-ID des Kandidaten, den Manifest-Digest der gerenderten Ausgabe, den vorherigen Publish-Epoch und die genauen Revisionen, aus denen gebaut wurde.

Die Promotion aktiviert genau diesen Kandidaten – und nur nach unabhängiger menschlicher Bestätigung. Sie rendert nicht erneut, sondern bindet die Aktivierung an die geprüften Werte. Weicht der Manifest-Digest ab oder hat sich der öffentliche Stand seit dem Bau der Vorschau verändert, lehnt ContentKit die Promotion ab und der bisherige Release bleibt aktiv. Was der Mensch freigibt, ist der durch Release-ID und Manifest-Digest gebundene Kandidat, bezogen auf den Ausgangszustand, den die Vorschau ausweist.

Diese Konstruktion ist besonders relevant, wenn Agenten Inhalte vorbereiten. Über MCP greifen sie auf dieselbe Veröffentlichungsdomäne und dieselben Regeln zu; die öffentliche Wirkung bleibt an eine unabhängige menschliche Bestätigung gebunden.

Semantische Komposition mit deterministischer Ausgabe

Diagramme, Kennzahlen und visuelle Kompositionen entstehen in ContentKit nicht durch manuelles Layout, sondern durch eine Kette getrennter Verantwortlichkeiten: Der Semantic AST erfasst, was ein Inhaltsblock aussagt. Das Narrative ordnet Leserfrage, Kernaussage und Evidenz. Ein kontrolliertes Pattern Package entscheidet, welche Darstellungsform zur Datenform passt. Am Ende steht eine deterministische Ausgabe – responsives HTML sowie helle und dunkle SVGs. PNG entsteht ausschließlich auf ausdrückliche Anforderung, nicht als Nebenprodukt.

Für semantische Kompositionen macht diese Trennung die Ausgabe bei gleichen Eingaben reproduzierbar. Kein Autor und kein Modell erfindet Layoutdetails für jede Grafik neu; welche Darstellung entsteht, folgt aus Semantic AST, Narrative und Pattern Package, nicht aus Handarbeit im Einzelfall. Die Anzahl und der Zuschnitt der verfügbaren Patterns sind dabei Implementierungsstand des Repositories, keine Produktkonstante.

Zugriffskontrolle bis in die Suche

ContentKit wendet Zugriffsregeln auch auf die Suche an. Die aktuelle Suchimplementierung sorgt dafür, dass öffentliche Anfragen an eine vollständig private Site keine geschützten Inhalte offenlegen. Angemeldete Leser sehen in Suchergebnissen nur Inhalte innerhalb ihres Grants. Die Berechtigungen sind dabei kein Sonderfall einzelner Zugänge: Die MCP-Oberfläche arbeitet über dieselben Berechtigungen wie REST, und das Cockpit verwendet dieselbe API und dasselbe Inhaltsmodell.

Einsatzformen

Die Architektur unterstützt folgende Einsatzformen:

Website aus dem Repository

Markdown liegt in Git, eine Pipeline lädt Revisionen hoch und baut Vorschauen; die Promotion bleibt eine menschliche Entscheidung. Diese Website selbst läuft auf ContentKit.

Reports als Nachweis statt Dashboard

Ein Bericht hält fest, welcher Stand zu einem Zeitpunkt geprüft oder freigegeben wurde. ContentKit macht daraus eine lesbare Seite mit Kennzahlen und Diagrammen, ohne die versionierte Markdown-Quelle zu ersetzen. Der Release hält Daten, Text und Visualisierung zusammen; ein Rollback aktiviert einen bekannten Stand.

Agentengestütztes Publizieren

MCP gibt Agenten einen domänenorientierten Zugang. Die manifestgebundene Promotion stellt sicher, dass die öffentliche Wirkung an einen exakt identifizierten Kandidaten und eine menschliche Bestätigung gebunden bleibt.

Redaktion im Cockpit

Das Cockpit ist der Zugang für menschliche Arbeit an derselben Domäne – über dieselbe API, dasselbe Inhaltsmodell und ohne zweiten Persistenzpfad. Was hier entsteht, unterliegt denselben Revisionen, Berechtigungen und Releases wie jeder andere Zugang.

Was diese Seite nicht pflegt

Diese Projektseite beschreibt die langlebige Architektur, nicht den Tagesstand des Repositories. Commit-Zähler, Versionsbadges und vollständige Funktionslisten veralten schneller, als eine Projektseite gepflegt werden sollte; der aktuelle Stand steht im Repository selbst, in README, Architektur- und MCP-Dokumentation. Stand August 2026 gilt das hier Beschriebene für den aktuellen Entwicklungsstand; einzelne Verträge der öffentlichen API können sich weiterentwickeln, die beschriebenen Invarianten – unveränderliche Revisionen, vollständige Releases, atomare Aktivierung, manifestgebundene Promotion – sind die tragenden Entscheidungen des Systems.

Konsequenz

Wer die Bindung eines geprüften Kandidaten an den öffentlichen Stand benötigt, verwendet die manifestgebundene Preview-Promotion.