# Vorschau vor Wirkung URL: https://www.mikebild.dev/de/blog/vorschau-vor-wirkung/ Wenn eine Aktualisierung auf Seite 63 von 80 scheitert, darf keine der ersten 62 Seiten öffentlich sein. Diese Forderung klingt selbstverständlich. Einzelspeicherung mit sofortiger Sichtbarkeit erzeugt jedoch ohne Release-Grenze genau solche Teilstände. ContentKit behandelt eine Veröffentlichung deshalb als vollständigen Stand und nicht als Folge einzelner Seitenänderungen. *Teil 5 der Serie „ContentKit – Publishing für Maschinen“.* Für KI-Agenten ist diese Eigenschaft besonders wichtig. Ein Agent kann in kurzer Zeit mehr Dateien verändern, als eine Person währenddessen einzeln nachvollziehen kann. Der richtige Umgang damit ist nicht, die Maschine künstlich langsam zu machen. Zwischen Erzeugung und Wirkung braucht es eine verbindliche Release-Grenze: unveränderliche Revisionen, einen vollständig gebauten Kandidaten und eine Aktivierung, die exakt diesen Kandidaten meint – nicht eine später ähnlich aussehende Neuberechnung. ## Zustände mit verschiedenen Verantwortlichkeiten Ein Markdown-Upload erzeugt eine unveränderliche Revision: den angenommenen Inhalt in genau dieser Form. Eine Vorschau legt ausgewählte Revisionen über den aktuell veröffentlichten Stand und baut daraus einen vollständig gerenderten Website-Kandidaten; sie hält fest, worauf dieser Kandidat aufsetzt und woraus er besteht. Im Cockpit kann ein Mensch genau diesen Kandidaten bestätigen; seine fachliche Richtigkeit muss die Prüfung davor klären. Bei der Aktivierung durch Preview-Promotion werden die gerenderten Bytes des Kandidaten öffentlich – ohne weiteren Verarbeitungsschritt dazwischen. Ein Rollback aktiviert einen bereits bekannten, unveränderlichen Release erneut. Diese Zustände dürfen nicht zusammenfallen, weil an jedem eine andere Verantwortung hängt. Wenn bereits der Upload veröffentlicht, fehlt der Raum für technische Prüfungen und fachliche Freigabe. Wenn die Freigabe sich nur auf eine Vorschau-URL bezieht, statt auf die konkreten Revisionen und das gerenderte Ergebnis, bestätigt sie etwas Unbestimmtes. Und wenn ein Rollback erneut baut, hängt die Schadensbegrenzung von denselben Komponenten ab, die gerade einen Fehler erzeugt haben könnten. ```mermaid flowchart TD M["Markdown-Änderung"] --> U["Upload
neue unveränderliche Revision"] U --> P["Vorschau
vollständigen Kandidaten bauen
Epoche + Manifest binden"] P --> T{"Prüfungen
erfolgreich?"} T -- nein --> F["Revision korrigieren
öffentlicher Stand bleibt"] F --> U T -- ja --> H["Freigabe im Cockpit
exakt gebundener Kandidat"] H --> A["Promotion aktiviert
genau diese Bytes"] A --> O["Öffentlicher Stand"] O --> B["Rollback: bekannten Release
wieder aktivieren"] ``` ## Revisionen werden nicht überschrieben Jeder Upload erzeugt eine neue, unveränderliche Revision. Ein Korrekturversuch verändert also nicht den vorherigen Versuch, sondern tritt neben ihn. Das erlaubt einen genauen Vergleich und verhindert, dass ein fehlgeschlagener Lauf seinen Ausgangspunkt verwischt. Die Revisions-ID ist ein konkreter Kandidatenbestandteil. Ein Agent kann sie zusammen mit weiteren IDs in eine Vorschau aufnehmen und muss nicht auf einen veränderlichen Namen wie „letzter Entwurf“ vertrauen. Diese Unveränderlichkeit verbessert auch den Nachweis. Wurde eine Betriebsanleitung freigegeben, lässt sich später bestimmen, welche Revisionen zu diesem Release gehörten. Eine nachträgliche Korrektur erzeugt eine neue Revision und deutet den alten Stand nicht um. ## Die Vorschau bindet, was geprüft wird Bei einer Änderung müssen unveränderte Seiten nicht erneut hochgeladen werden. Eine Vorschau nimmt die ausgewählten Revisionen und legt sie über die aktuell veröffentlichten Revisionen; ContentKit rendert daraus einen vollständigen Website-Kandidaten mit allen Einträgen. Entscheidend ist, was die Vorschau dabei festhält. Stand August 2026 bindet sie drei Dinge: die Veröffentlichungs-Epoche, auf der sie aufgebaut wurde, die genauen Hinzufügungen und Entfernungen gegenüber diesem Stand sowie eine kanonische SHA-256-Prüfsumme über alle gerenderten Einträge. Diese Bindung ist wichtiger als die Vorschau-URL. Eine URL zeigt nur, wo etwas betrachtet werden kann. Epoche, Revisionsliste und Manifest sagen, *was* geprüft wurde. Daraus folgt eine harte Konsequenz: Die Vorschau verliert ihre Gültigkeit als Freigabegrundlage, sobald sich das Manifest oder der zugrunde liegende Veröffentlichungsstand ändert. Wird während des Reviews ein anderer Release aktiviert, stimmt die Veröffentlichungs-Epoche nicht mehr, auf der der Kandidat aufsetzt. Weicht das Manifest ab, sind es nicht mehr dieselben Bytes. In beiden Fällen verweigert ContentKit die Aktivierung. Eine Freigabe bezieht sich nicht auf „die Website ungefähr zu diesem Zeitpunkt“, sondern auf einen bestimmten Satz gerenderter Dateien mit bekannter Prüfsumme. Eine Vorschau eignet sich deshalb sowohl für einen menschlichen Review als auch für maschinelle Prüfungen gegen den vollständigen Kandidaten – nicht gegen eine lose Sammlung gerenderter Fragmente. ## Promotion ohne Neubau Die Promotion einer Vorschau baut nichts neu. Sie aktiviert exakt die Bytes, die beim Bau der Vorschau erzeugt und über das Manifest festgeschrieben wurden. Gegenüber einem Ablauf, in dem nach der Prüfung erneut gerendert wird, ist das der wesentliche Unterschied: Zwischen dem geprüften Ergebnis und dem öffentlichen Ergebnis liegt kein weiterer Verarbeitungsschritt, der stillschweigend andere Eingaben verwenden könnte. Vor der Aktivierung prüft ContentKit die Bindung. Stimmt die Manifest-Prüfsumme nicht mit dem Kandidaten überein oder hat sich der Veröffentlichungsstand seit dem Bau der Vorschau verändert, schlägt die Promotion fehl und der öffentliche Stand bleibt unverändert. Ein abgelehnter Kandidat ist kein Betriebsunfall, sondern das gewünschte Verhalten: Die neue Ausgangslage braucht eine neue Vorschau und eine neue Prüfung. Ein menschlicher Bestätigungsweg für diese Wirkung ist das ContentKit-Cockpit. Dort sieht die angemeldete Person den exakt gebundenen Kandidaten und bestätigt genau diese Promotion. Freigegeben wird damit die konkrete, geprüfte Vorschau – nicht eine Berechtigung, „etwas Ähnliches“ später zu veröffentlichen. Die Bindung sichert allerdings nur die Identität des Kandidaten, nicht seine fachliche Richtigkeit. Ob eine Migrationsanleitung inhaltlich stimmt, muss die Prüfung davor klären. ## Beispielablauf: achtzig Seiten auf Version 3.1 Der folgende Ablauf ist konstruiert, zeigt aber, wie die Grenze im Alltag wirkt. Eine Produktversion ändert Befehlsnamen, Konfigurationsfelder und Screenshots; ein Agent aktualisiert achtzig Seiten. Beim ersten Kandidaten findet die eigene Strukturprüfung des Teams gegen die Vorschau eine verschobene Seite, die weiterhin auf ihren alten Elternknoten verweist. Der öffentliche Stand bleibt unberührt; Kunden sehen weiterhin die vollständige Dokumentation für Version 3.0. Der Agent korrigiert den `parent`-Wert, lädt nur diese Seite als neue Revision hoch und baut eine neue Vorschau. Beim zweiten Kandidaten meldet der Linktest des Teams drei Verweise auf entfernte Anker. Wieder ändert sich öffentlich nichts. Erst der dritte Kandidat besteht Strukturprüfung, Linktest und den fachlichen Review. Genau dieser Kandidat – mit seiner Revisionsliste, seiner Manifest-Prüfsumme und der Veröffentlichungs-Epoche, auf der er aufsetzt – wird im Cockpit bestätigt und aktiviert. Hätte in der Zwischenzeit jemand anderes veröffentlicht, hätte ContentKit die Promotion abgelehnt, und der Agent hätte eine vierte Vorschau auf dem neuen Stand gebaut. Für Endanwender ist das Ergebnis unauffällig. Sie erleben keinen Zeitraum mit gemischten Befehlsnamen, keine halbe Navigation und keine Seite, die bereits auf eine noch nicht veröffentlichte Anleitung zeigt. ## Rollback ohne erneutes Rendern Wird nach der Veröffentlichung ein fachlicher Fehler entdeckt, kann ContentKit einen bekannten, unveränderlichen Release wieder aktivieren, ohne Inhalte neu zu rendern. Das ist im Störungsfall entscheidend: Ein erneuter Build könnte an einer ausgefallenen Abhängigkeit scheitern oder inzwischen andere Eingaben verwenden. Der bekannte Release ist bereits gebaut und wird ohne erneutes Rendern wieder aktiviert. Ein Rollback stellt Wirkung zurück, ohne die Vergangenheit zu löschen: Die seither entstandenen Revisionen bleiben erhalten und können später in einem korrigierten Kandidaten verwendet werden. ## Was Agenten gegen den Kandidaten prüfen Eine gute Vorschau ermöglicht Prüfungen, die bei einem einzelnen Markdown-Dokument nicht möglich wären: Sind alle erwarteten Routen vorhanden und nur diese? Bleiben kanonische Links, Sprachalternativen und Versionen konsistent? Verweisen Navigation und verwandte Artikel nur auf erreichbare Seiten? Ein bloßes „Preview gebaut“ ist noch kein Qualitätsnachweis. Die Prüfungen sollten aus den Risiken des jeweiligen Angebots entstehen. Als illustrative Empfehlung für eine öffentliche, mehrsprachige Dokumentation mit geschütztem Bereich könnte eine Matrix so aussehen; die Sollzustände stammen dabei aus den eigenen Deklarationen des Teams – der Routenliste im Repository, der Sprachkonfiguration und der OpenAPI-Spezifikation: ```yaml checks: - name: public-routes expected: all declared public pages return 200 - name: protected-discovery expected: protected titles are absent from public indexes - name: locale-links expected: every declared alternate route exists - name: source-contract expected: documented endpoints exist in OpenAPI - name: rollback-target expected: previous active release remains available ``` Der Agent führt diese Prüfungen gegen die Vorschau aus und speichert Resultat, Zeit und betroffene Revisions-IDs. Befunde über die manifestgebundenen Artefakte gelten damit für dieselben Bytes, die öffentlich werden; zeitabhängige und externe Prüfungen – etwa gegen erreichbare Links oder eine veränderliche OpenAPI-Quelle – benötigen eigene Gültigkeitsgrenzen. Ein Fehlerbericht sollte die verletzte Erwartung und einen reproduzierbaren Aufruf enthalten. „Navigation sieht komisch aus“ hilft einem Folgeagenten wenig; „`/de/docs/v3/install/` verweist auf fehlenden Elternknoten `getting-started`“ ist bearbeitbar. Nicht jede Prüfung muss mit jedem Kandidaten laufen. Ein Textfehler braucht keinen vollständigen Lasttest; eine Änderung an Vorlagen oder Zugriffsregeln rechtfertigt dagegen eine breitere Prüfung. Die Vorschau hält die genauen Hinzufügungen und Entfernungen gegenüber dem Veröffentlichungsstand fest; aus diesem Diff kann eine Policy den Prüfumfang ableiten. ## Auch das Entfernen ist ein Release-Vorgang Eine veröffentlichte Seite verschwindet nicht dadurch, dass ihre lokale Datei gelöscht wird. Im hier beschriebenen Workflow gehört die Entfernung als Bestandteil eines neuen Standes in denselben Weg aus Vorschau, Prüfung und Freigabe; die Vorschau hält Entfernungen gegenüber dem Veröffentlichungsstand genauso fest wie Hinzufügungen. Das schützt vor einem verbreiteten Agentenfehler: Eine Datei wird im Repository umbenannt, und die alte URL bleibt unbemerkt aktiv. Ein guter Lauf vergleicht den beabsichtigten Bestand mit dem tatsächlich veröffentlichten Bestand und führt entfernte Inhalte ausdrücklich auf. Die Vorschau zeigt anschließend, ob alte Routen den vorgesehenen Status liefern und neue Links stimmen. Eine versehentliche Entfernung lässt sich korrigieren, indem eine vorhandene Revision in einen neuen Kandidaten aufgenommen wird. ## Fehlschläge ohne Änderung des öffentlichen Stands Der größte Zeitgewinn entsteht nicht, wenn jeder Agentenlauf im ersten Versuch gelingt. Er entsteht, wenn ein Fehlschlag billig bleibt. Eine ungültige Revision kann korrigiert werden. Eine fehlerhafte Vorschau berührt die Öffentlichkeit nicht. Eine wegen Drift abgelehnte Promotion kostet einen neuen Vorschau-Bau, aber keinen öffentlichen Zwischenzustand. Ein fachlich falscher Release lässt sich ohne Neubau zurücksetzen. Dadurch kann ein Team Automatisierung schrittweise erweitern. Anfangs beurteilt ein Mensch jede Vorschau im Cockpit. Später übernehmen Agenten Link-, Struktur- und Sichtbarkeitsprüfungen und legen dem Menschen nur noch den gebundenen Kandidaten mit Befunden vor. Bei der Preview-Promotion wird nur der exakte Kandidat öffentlich, der gebaut, geprüft und bestätigt wurde. ## Fazit „Vorschau vor Wirkung“ ist bei ContentKit keine redaktionelle Gewohnheit, sondern Architektur: Die Vorschau bindet Veröffentlichungs-Epoche, Revisionsauswahl und die SHA-256-Prüfsumme der gerenderten Einträge, und die Promotion aktiviert exakt diese Bytes oder scheitert. Für Teams, die automatisierte Änderungswerkzeuge einsetzen, folgt daraus eine klare Regel. Die Maschine darf viele Änderungen erzeugen und mehrmals scheitern. Der Mensch im Cockpit bestätigt einen eindeutig identifizierten Kandidaten statt eines zwischen Prüfung und Aktivierung veränderten Kandidaten. Eine Freigabe darf deshalb nur angenommen werden, wenn Revisionen, Veröffentlichungs-Epoche und Manifest-Prüfsumme unverändert gebunden sind – alles andere ist keine Freigabe, sondern eine Vermutung. ## Weiterführende Quellen - [ContentKit Architektur und Inhaltslebenszyklus (Commit f6b0f41)](https://github.com/MikeBild/contentkit/blob/f6b0f4191bfbc3bcf51a991e1026434e8c35f6b1/docs/ARCHITECTURE.md) - [ContentKit MCP-Vertrag: Bestätigung und Promotion (Commit f6b0f41)](https://github.com/MikeBild/contentkit/blob/f6b0f4191bfbc3bcf51a991e1026434e8c35f6b1/MCP.md) - [ContentKit README (Commit f6b0f41)](https://github.com/MikeBild/contentkit/blob/f6b0f4191bfbc3bcf51a991e1026434e8c35f6b1/README.md)