Publishing mit Claude Code und Codex

Diesen Beitrag anhören (13 Min.)

422 Unprocessable Entity
unknown docs version: v3

Diese Diagnose benennt eine Vertragsverletzung. Der Agent kann die betroffene Datei korrigieren oder mit einem nachvollziehbaren Befund stoppen. Nichts ist öffentlich geworden.

Claude Code und Codex lesen dafür Quellen, ändern Markdown, führen Prüfungen aus und bereiten einen vollständigen Kandidaten vor. Sie spielen keine Klickfolge nach und bekommen nicht still die Verantwortung für die öffentliche Website übertragen.

ContentKit trennt Revision, Vorschau und Promotion: den Vorschlag als unveränderliche Revision, den geprüften Kandidaten als vollständige Vorschau und die Preview-Promotion als eigenen, manifestgebundenen Veröffentlichungsschritt. Ein direkter Release bleibt ein separater Produktweg, besitzt diese Bindung an die vorher geprüfte Vorschau aber nicht automatisch. Die Preview-Promotion bindet den zuvor geprüften Kandidaten an Manifest und Veröffentlichungsstand. Für die Promotion ist zusätzlich eine menschliche Freigabe erforderlich.

Wenn ein direkter Release verwendet wird, muss seine Autorisierung außerhalb des freien Modelltexts liegen. Im hier beschriebenen redaktionellen Ablauf bleibt die menschliche Freigabe Pflicht.

Drei Zugänge, eine Publishing-Domäne

Stand 16. August 2026 arbeiten Menschen im ContentKit-Cockpit. Agenten nutzen den nativen Remote-MCP-Endpunkt unter /mcp. Skripte und feste Dienste sprechen HTTP auf Grundlage der OpenAPI-Beschreibung. Das sind keine drei voneinander unabhängigen Systeme. Cockpit, MCP und REST arbeiten mit denselben unveränderlichen Revisionen, demselben Release Manager und denselben Autorisierungsregeln.

Das Cockpit ist die menschliche Oberfläche dieser Publishing-Domäne und führt kein zweites Inhaltsmodell ein. ContentKit bleibt bewusst ohne WYSIWYG-Editor und ohne frei konfigurierbaren Page-Builder. Menschen können Inhalte, Vorschauen und Releases trotzdem im Web verwalten. Sie verwenden dort dieselben Revisionen, Berechtigungen, Vorschauen und Releases wie MCP und HTTP.

MCP bietet dafür Werkzeuge für Inhalt, Revision, Vorschau, Release und Freigabe an. Die veröffentlichte Liste umfasst Reads, unveränderlichen Markdown-Ingest, semantische Kompositionen, Release- und Preview-Inspektion sowie das Preview- und Veröffentlichungs-Gate.

Für wiederholbare Dienste bleibt HTTP der ausdrückliche Vertrag. Ein festes Skript braucht keine Agentensitzung, um eine geprüfte Datei hochzuladen. Die Protokollwahl ändert den fachlichen Zustand nicht: Keiner der Zugänge erzeugt einen zweiten Persistenzpfad.

Der Agent arbeitet an Quellen und Diffs

Der Auftrag „Aktualisiere die Website“ lässt Quellen, erlaubte Dateien und Veröffentlichungsgrenze offen. Ein konkreter Auftrag nennt Quellen, Änderungen, Prüfung und Freigabe getrennt:

Ermittle die öffentlich sichtbaren Änderungen aus Quellcode, Spezifikation und Tests.
Ändere nur Markdown-Dateien, deren Aussagen sich daraus belegen lassen.
Führe lokale Struktur-, Link- und Vertragsprüfungen aus.
Erzeuge neue Revisionen und baue eine vollständige Vorschau.
Lege den exakt identifizierten Kandidaten einem Menschen vor.

Der Agent bearbeitet damit dieselben Dateien, die auch ein Entwickler im Diff prüfen würde. Ein Git-Diff zeigt die Textänderung. Die Belegliste sollte zu jeder neuen Produktaussage Repository, Commit, Datei und Zeilenbereich nennen. Das Prüfprotokoll hält Testname und Ergebnis fest. Das Modell darf formulieren, aber keine Erfahrung, Messergebnisse oder Produkteigenschaften ergänzen, die in den Quellen nicht vorkommen.

Angenommen, eine neue API-Version entfernt /v1/legacy-orders und benennt den Fehler ORDER_NOT_FOUND um. Dann zeigen Diff und Suche, welche Dokumentationsstellen betroffen sind:

git diff -- docs/api docs/migrations changelog
rg -n "/v1/legacy-orders|ORDER_NOT_FOUND" docs changelog

Vor dem Upload fangen lokale Regeln offensichtliche Fehler ab: ungültiges Frontmatter, fehlende Überschriften, kaputte interne Links oder Verweise auf entfernte Endpunkte. ContentKit prüft anschließend seinen eigenen Vertrag. Eine lokale Prüfung kann diesen Zielvertrag nicht vollständig ersetzen, weil nur das Zielsystem seinen aktuellen Zustand und seine Invarianten kennt.

Der Ablaufvertrag hängt nicht von Claude Code oder Codex ab:

sequenceDiagram
    participant S as Quellen und Spezifikation
    participant A as Claude Code oder Codex
    participant C as ContentKit
    participant M as Mensch
    participant W as öffentliche Website
    A->>S: Änderungen und Belege lesen
    A->>A: Markdown ändern und lokal prüfen
    A->>C: unveränderliche Revision anlegen
    C-->>A: Revisions-ID oder Diagnose
    A->>C: vollständige Vorschau bauen
    C-->>A: Release-ID, Manifest und Veröffentlichungsstand
    A->>M: Vorschau und Prüfergebnisse vorlegen
    M->>C: exakt gebundene Promotion bestätigen
    C->>C: Drift prüfen und Release-Zeiger atomar setzen
    C-->>W: geprüften Stand ausliefern

Der Agent bereitet vor. ContentKit prüft Release-ID, Manifest-Digest und Veröffentlichungsstand. Der Mensch bestätigt die öffentliche Promotion.

Eine Revision ist noch keine Veröffentlichung

Jeder angenommene Markdown-Upload erzeugt eine neue unveränderliche Revision. Eine Korrektur überschreibt die vorherige Fassung nicht, sondern erhält eine eigene ID. Angenommene Fassungen bleiben über ihre Revisions-IDs unterscheidbar; eine abgelehnte Anfrage liefert stattdessen eine Diagnose an den laufenden Agenten. Ein schlecht formulierter Entwurf darf verworfen werden, ohne den öffentlichen Stand zu berühren.

Die Revision bindet den eingelesenen Inhalt. Sie beweist noch nicht, dass Links funktionieren, Navigation vollständig ist oder geschützte Inhalte aus öffentlichen Indizes verschwunden bleiben. Diese Eigenschaften entstehen erst im Zusammenhang des ganzen Veröffentlichungsstands.

ContentKit baut deshalb eine vollständige Vorschau mit stabilem Pfad und ablaufendem Einladungslink. Die ausgewählten Revisionen werden auf den aktiven Stand gelegt und gemeinsam gerendert. Der statische Kandidat umfasst neben HTML auch RSS, Sitemap, Suchindex und gehashte Assets. Eine einzelne Seite kann korrekt aussehen und trotzdem einen falschen Verweis oder einen unerwünschten Eintrag im Suchindex erzeugen.

Gegen die Vorschau lassen sich konkrete Fragen prüfen:

Antworten alle neuen und geänderten URLs mit dem erwarteten Status?
Zeigen interne Links auf vorhandene Ziele?
Bleiben nicht ausgewählte Seiten und archivierte Dokumentationsstände unverändert?
Stimmen Navigation, Suche, Sitemap und maschinenlesbare Ausgaben mit der Sichtbarkeitsregel überein?

Diese Prüfungen beurteilen einen vollständigen Kandidaten. Sie verändern den aktiven Release nicht.

Das Manifest bindet den geprüften Kandidaten

Die Vorschau liefert eine Release-ID, einen Manifest-Digest über die gerenderten Dateien und den Veröffentlichungsstand, auf dem sie aufgebaut wurde. Damit lässt sich der geprüfte Kandidat später exakt wiedererkennen. Eine Freigabe bezieht sich nicht auf „die Website ungefähr zu diesem Zeitpunkt“, sondern auf einen bestimmten Satz gerenderter Bytes.

Diese Bindung beweist die Identität des Kandidaten, nicht seine fachliche Richtigkeit. Ob eine Migrationsanleitung stimmt oder eine Einschränkung fehlt, muss die Redaktion vor der Freigabe prüfen. Die Bindung aus Release-ID, Manifest-Digest und Veröffentlichungsstand verhindert anschließend, dass ein anderer Kandidat promotet wird.

Die Promotion aktiviert die bereits gebaute Vorschau ohne erneutes Rendern. Weicht der Manifest-Digest ab oder hat sich der öffentliche Stand seit dem Preview-Bau verändert, lehnt ContentKit die Promotion ab. Der bisherige Release bleibt aktiv.

Live-Veröffentlichung und andere destruktive MCP-Wirkungen benötigen eine menschliche Entscheidung. Gültig ist die dafür vorgesehene native Bestätigungsform oder die Bestätigung des exakt gebundenen Kandidaten im Cockpit. Wenn ein verschachtelter MCP-Client die native Form nicht darstellen kann, liefert ContentKit für die unveränderliche Preview-Promotion einen nicht mutierenden Cockpit-Link. Der ausgewählte Release ist dabei an Release-ID, Manifest-Digest und den unveränderten Veröffentlichungsstand gebunden. Der Link ist selbst noch keine Freigabe. Erst die angemeldete Person bestätigt im Cockpit die konkrete Wirkung.

Rechte folgen der möglichen Wirkung

Ein Agent benötigt nicht pauschal einen „KI-Schlüssel“. Seine Rechte ergeben sich aus dem Arbeitsschritt. Lesen, Revisionen schreiben, Vorschauen bauen, Releases aktivieren und Sites verwalten sind unterschiedliche Fähigkeiten. Ein Recherchelauf braucht keine Release-Berechtigung. Ein Upload darf eine Revision erzeugen, ohne die Website sichtbar zu verändern.

Über MCP strukturieren mcp:read, mcp:authoring und mcp:admin die angebotenen Werkzeuge. Diese Stufen verleihen keine zusätzlichen Produktrechte. Die angemeldete Identität und ihre Site-Grenzen bleiben maßgeblich. Ein Agent sieht kein Werkzeug für eine Wirkung, die sein Principal nicht ausführen darf.

Getrennte Identitäten sind hier sinnvoll, wenn Laufzeit und Scopes Schreib-, Preview- und Release-Wirkungen technisch isolieren. Eine zusätzliche Identität lohnt sich nicht, wenn sie dieselben Credentials und Produktrechte verwendet und nur einen weiteren Übergabeschritt erzeugt.

Zugangsdaten gehören in den Secret Store der Laufzeit, nicht in den Prompt und nicht ins Repository:

export CONTENTKIT_URL="https://contentkit-api.example.com"
export CONTENTKIT_SITE="product-docs"
export CONTENTKIT_PUBLISH_API_KEY="ck_..."

Auch der Arbeitsbereich bleibt begrenzt. Hochzuladende Dateien werden ausdrücklich benannt. Ein Glob über das ganze Repository könnte Notizen, Rohdaten oder Zugangsdaten aufnehmen, die nie Teil der Revision sein sollten.

Fehler sind unterschiedliche Ergebnisse

Bei den hier beschriebenen Management- und Authoring-Aufrufen führen 401, 403 und 422 zu verschiedenen Folgeschritten. 401 bezeichnet einen nicht anerkannten Zugang, 403 einen anerkannten Principal ohne erforderlichen Scope oder Site-Grant und 422 eine inhaltlich vertragswidrige Anfrage.

Bei 401 stoppt der Agent und meldet die Zugangskonfiguration. Er versucht nicht, einen Schlüssel zu erraten. Bei 403 fehlt eine bewusste Berechtigungsentscheidung; eine Wiederholung ändert daran nichts. Bei 422 kann der Agent die genannte Vertragsverletzung in der Quelldatei korrigieren und eine neue Revision erzeugen.

Ein Client kann diese Antworten lokal etwa so normalisieren:

type AuthoringResult =
  | { status: "accepted"; revisionId: string }
  | { status: "unauthenticated" }
  | { status: "invalid"; details: string[] }
  | { status: "forbidden" }
  | { status: "failed"; requestId: string };

Diese Einordnung verhindert blinde Wiederholungen gegen ein produktives System. Ein fachlich abgelehnter Upload wird durch fünf identische Wiederholungen nicht richtiger.

Semantik vor Geometrie

Auch visuelle Kompositionen trennen semantischen Vorschlag, Validierung und gerenderte Wirkung. Ein Agent beschreibt die Aussage, die Beziehungen und die vorhandenen Daten. ContentKit empfiehlt daraus ein geeignetes Muster, validiert dessen Eingabevertrag und kompiliert die angeforderten Darstellungen.

Ein Prozess braucht eine Richtung. Eine Hierarchie behauptet Ordnung. Ein Funnel behauptet Reduktion. Diese Bedeutungen sind nicht austauschbar, auch wenn zwei Darstellungen auf einem großen Bildschirm ähnlich aufgebaut wirken. Deshalb wählt der Agent keine freien Koordinaten und Farben. Er liefert semantische Direktiven und prüft die begründete Auswahl innerhalb einer geschlossenen Registry.

Die Zahl verfügbarer Muster ist keine Architekturgrenze des redaktionellen Ablaufs. Der Agent muss drei Fragen beantworten: Welche Beziehung soll sichtbar werden? Passt der Inhalt in den gewählten Vertrag? Welche responsive Alternative hat ContentKit tatsächlich kompiliert? Überschreitet etwa eine Prozessdarstellung ihre erlaubte Elementzahl, korrigiert der Agent den Inhalt oder wählt nach der strukturierten Diagnose ein zulässiges Muster. Er wertet das Validierungsergebnis und die kompilierte Darstellung aus, statt allein aus seiner ursprünglichen Präferenz auf das Ergebnis zu schließen.

Agenten wechseln, der Veröffentlichungsvertrag bleibt

Claude Code und Codex unterscheiden sich in Bedienung, Modellen und Einbindung in die Entwicklungsumgebung. ContentKit benötigt deshalb keinen Claude-Code-Modus und keine besondere Codex-Seite. Beide bearbeiten Markdown und Repository-Artefakte und bedienen einen dokumentierten Maschinenzugang. Ein Mensch kann dieselben Änderungen als Diff lesen und dieselbe Vorschau im Cockpit beurteilen.

Ein Agent kann Quellen vergleichen, betroffene Aussagen finden, Dateien ändern, lokale Prüfungen ausführen, Revisionen anlegen und die vollständige Vorschau technisch prüfen. Diff, Prüfergebnis und Vorschau ersetzen dabei einen Teil der Übergaben über Tickets und Copy-and-paste. Die Entscheidung über die Promotion in den öffentlichen Stand bleibt beim Menschen.

Für diese Austauschbarkeit sind andere Artefakte wichtiger als der Modellname:

Markdown und Git-Diff für den Vorschlag,
Revisions-ID für den angenommenen Inhalt,
Release-ID, Manifest und Veröffentlichungsstand für die Vorschau,
protokollierte Freigabeentscheidung für das menschliche Gate,
Readback des veröffentlichten Stands sowie HTTP-Prüfung der öffentlichen URL.

Scheitert die Preview-Promotion an Manifest- oder Veröffentlichungsstand-Drift, bleibt der aktive Release unverändert. Weder eine bestandene Modellprüfung noch der vorbereitende Workflow kann die Freigabe für die Promotion in den öffentlichen Stand ersetzen. Ein Wechsel von Claude Code zu Codex ändert deshalb nur das Werkzeug vor ContentKit, nicht die Revisions-, Vorschau- oder Freigabegrenze.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare