CMS-Site prüfen und veröffentlichen

Führen Sie eine CMS-Site in getrennten Schritten vom Quellstand bis zur Live-Auslieferung. Eine grüne Developer-Readiness bestätigt Bearbeitung und Vorschau. Sie sagt nicht aus, dass bereits ein Release gebaut oder veröffentlicht wurde.

Richten Sie die lokale Domain bei Bedarf zuerst mit Lokale Storefront-Domain einrichten ein. Dieser Quickstart ist abgeschlossen, wenn die Live-Domain den bewusst veröffentlichten Release ausliefert und die Operations-Readiness keine Blocker meldet.

Zustände unterscheiden

Zustand	Bedeutung	Nächster Schritt
Kein Build	Die Site kann bearbeitet und in der Vorschau geprüft werden, besitzt aber noch keinen Release.	Vorschau fachlich prüfen und Build starten.
Build läuft	Workspace erzeugt einen unveränderlichen Release.	Abschluss abwarten.
Build fehlgeschlagen	Der Release wurde nicht zuverlässig erzeugt. Der Status nennt einen redigierten Fehlercode, `retryable` und eine Attempt-ID.	Recovery-Klasse prüfen; nicht automatisch erneut bauen oder veröffentlichen.
Release unveröffentlicht	Ein Build ist vorhanden, aber noch nicht live.	Release prüfen und bewusst veröffentlichen.
Release veröffentlicht	Der gewählte Release ist live.	Live-Domain und Operations-Readiness prüfen.
Live-Release unvollständig	Der aktive Release besitzt keinen vollständigen Runtime-Katalog und wird deshalb sicherheitshalber vollständig mit HTTP `503` gesperrt.	Einen neuen Release bauen, prüfen und bewusst veröffentlichen.

Wenn Site-Domain-Bindung, DNS und TLS bereit sind, liefert Workspace vor der ersten Veröffentlichung erwartbar HTTP 404 statt Live-Inhalten. Ordnen Sie 404 nur in diesem Fall als fehlenden Live-Release ein. Blockierte Domain-, DNS-, TLS- oder Bindungschecks weisen auf ein Infrastrukturproblem hin.

Von der Vorschau zur Live-Site

Öffnen Sie CMS > Sites und wählen Sie die Site.
Initialisieren Sie eine leere Site einmal mit dem Default-Kit.
Starten Sie eine Dev-Session und bearbeiten Sie die Dateien im Tab Editor.
Erzeugen Sie einen Vorschau-Link und prüfen Sie den Stand fachlich.
Öffnen Sie den Tab Releases und starten Sie den Build.
Warten Sie, bis der neue Release in der Liste erscheint.
Prüfen Sie den Release und bestätigen Sie Publish für genau diesen Stand.
Prüfen Sie anschließend die Live-Domain und die Operations-Readiness.

Ein Build veröffentlicht nichts automatisch. Auch ein neuer erfolgreicher Build verändert einen bereits live geschalteten Release erst nach einer ausdrücklichen Veröffentlichung.

Buildfehler sicher behandeln

Bewahren Sie die vom Build zurückgegebene attemptId auf. nucli sites build <site-id> --wait wartet nur auf den Status dieses Versuchs. Geben Sie bei einer Eskalation die Attempt-ID, failure.code und failure.retryable an, aber keine internen Logs, Dateipfade oder Rohfehler.

Fehlercodes	Bedeutung	Recovery
`SITE_BUILD_AUTHORING_REFRESH_FAILED`, `SITE_BUILD_REDIRECTS_FAILED`, `SITE_BUILD_ASSETS_FAILED`, `SITE_BUILD_RENDER_FAILED`, `SITE_BUILD_PUBLIC_FILES_FAILED`, `SITE_BUILD_ROUTING_FAILED`, `SITE_BUILD_DYNAMIC_ROUTES_FAILED`, `SITE_BUILD_SITEMAP_FAILED`, `SITE_BUILD_SEARCH_MANIFEST_FAILED`, `SITE_BUILD_IMAGES_FAILED`	Eine autorenabhängige Buildstufe konnte die validierten Quellen nicht verarbeiten.	Betroffene Quellen erneut validieren und erst danach einen neuen Build bewusst starten.
`SITE_BUILD_CAPACITY_UNAVAILABLE`, `SITE_BUILD_STORAGE_PREPARE_FAILED`, `SITE_BUILD_SOURCE_SNAPSHOT_FAILED`, `SITE_BUILD_STAGING_FAILED`, `SITE_BUILD_RELEASE_FINALIZE_FAILED`	Eine externe Buildvoraussetzung war nicht verfügbar. Diese Codes sind als `retryable` markiert.	Dokumentierte Kapazitäts-, Storage-, Snapshot-, Staging- oder Release-Voraussetzung durch den Betrieb wiederherstellen lassen. Erst danach einen neuen Build bewusst starten.
`SITE_BUILD_RUNTIME_SNAPSHOT_FAILED`, `SITE_BUILD_RUNTIME_CATALOG_FAILED`, `SITE_BUILD_PRECOMPRESSION_FAILED`, `SITE_BUILD_PUBLISH_FAILED`, `SITE_BUILD_INTERNAL`	Der Fehler benötigt Produktdiagnose oder ist keiner öffentlichen Recovery sicher zuzuordnen.	Mit Attempt-ID an das Produktteam eskalieren. Keinen automatischen Retry oder Publish ausführen.

retryable: true bedeutet ausschließlich, dass ein neuer Versuch nach einer nachweislich behobenen externen Voraussetzung sinnvoll sein kann. Der aktuelle Live-Release bleibt bei einem fehlgeschlagenen Build unverändert.

Navigation, Seitenauflösung und Page-Feed gehören zum unveränderlichen Release. Änderungen im Editor erscheinen deshalb nur in Dev und Vorschau. Sie verändern die Live-Site erst nach einem neuen Build und einer ausdrücklichen Veröffentlichung.

Nach einem Produktupdate kann ein älterer Release ohne vollständigen Runtime- Katalog mit HTTP 503 und dem Code ERR_SITE_RELEASE_RUNTIME_UNAVAILABLE gesperrt sein. Das ist kein normaler Seitenfehler und kein Anlass, Authoring-Dateien zurückzusetzen. Erzeugen Sie einen neuen Release, prüfen Sie im Publish-Plan die Prüfung release_runtime_ready und veröffentlichen Sie genau diesen Stand. Der Publish-Vorgang lehnt einen unvollständigen Zielrelease ab, ohne den aktiven Live-Release umzuschalten.

Vorschau-Link sicher verwenden

Der Vorschau-Link läuft mit dem gewählten Review-Zeitfenster ab. Er wird einmalig im vorgesehenen Browser eingelöst und setzt dort den Vorschauzugang. Öffnen Sie den Link nicht probeweise und lassen Sie ihn nicht automatisiert aufrufen. Das würde die Übergabe verbrauchen.

Speichern Sie konkrete Vorschau-Tokens weder in Logs noch in Tickets, Screenshots oder Dokumentation. Erzeugen oder kopieren Sie einen Link nur für den vorgesehenen Reviewer. Ein Vorschau-Link veröffentlicht die Site nicht.

Mit `nucli` prüfen

bash

nucli --tenant <tenant> sites readiness <site-id>
nucli --tenant <tenant> web readiness <site-id>
nucli --tenant <tenant> sites build <site-id> --wait
nucli --tenant <tenant> sites build-status <site-id>
nucli --tenant <tenant> sites releases list <site-id>
nucli --tenant <tenant> sites inspect <site-id> --strict
nucli --tenant <tenant> sites publish plan <site-id> --release <release-id>
nucli --tenant <tenant> sites publish <site-id> --release <release-id>

sites readiness bewertet Authoring und Vorschau. Verwenden Sie inspect --strict erst als Launch-Gate. web readiness bewertet Domain, DNS, TLS, Build und Live-Release. Der Publish-Plan ist read-only: Er darf einen unveröffentlichten Release und den Wechsel von einem gesperrten alten Live-Release akzeptieren, wenn der ausgewählte Zielrelease runtime-bereit ist. Liefert der alte Release HTTP 503, gilt diese Ausnahme nur, wenn Workspace die Antwort eindeutig der gerade geprüften Site und ihrem aktiven Site-Release zuordnet. Diagnose-Header oder HTTP 503 allein genügen nicht. Andere HTTP-Fehler sowie Infrastruktur-, Release-Lese- und Buildfehler bleiben blockierend.

Mutierende MCP-Aufrufe freigeben

Wenn ein MCP-Agent den Ablauf übernimmt, verlangen genau diese 13 Site- und Domain-Tools den erforderlichen JSON-Boolean approved: true:

nucleus_site_files_apply
nucleus_site_backup_save
nucleus_site_restore_apply
nucleus_site_dev_start
nucleus_site_preview_link_request
nucleus_site_dependencies_add
nucleus_site_dependencies_sync
nucleus_site_build
nucleus_site_publish
nucleus_tenant_domain_create
nucleus_tenant_domain_start_verification
nucleus_tenant_domain_verify_dns
nucleus_site_domain_bind

Geben Sie nur den konkreten Tool-Aufruf mit seinem vollständigen Payload frei. Fehlt approved, ist der Wert false, null oder kein Boolean, stoppt nucli vor Datei-, Secret-, Netzwerk- und Serverzugriff. Das Feld bleibt lokal und ersetzt weder Anmeldung, Berechtigungen, Tenantbindung noch die Prüfungen von Workspace. Read-only-Tools sowie nucleus_site_validate und nucleus_site_restore_preview bleiben unverändert.

Ergebnis prüfen

Die Veröffentlichung ist abgeschlossen, wenn der ausgewählte Release als live markiert ist, web readiness keine Blocker meldet und die Live-Domain den geprüften Inhalt statt des erwarteten Vorab-404 ausliefert.