--- title: "Vier Grenzen im Veröffentlichungsweg dieses EmDash-Blogs" description: "Ein Schreibagent kann diesen Blog überarbeiten, doch nur ein unabhängiger Publisher übernimmt seine Arbeit. Vier Grenzen trennen Berechtigungen, Metadaten, Revisionen und Plugin-Isolation." canonical: https://arnekellmann.de/de/blog/vier-grenzen-von-emdash-im-live-betrieb published: 2026-09-28 modified: 2026-10-13 lang: de --- # Vier Grenzen im Veröffentlichungsweg dieses EmDash-Blogs Dieser Blog verwaltet seine Inhalte in EmDash. Die Seiten, die Leser sehen, entstehen weiterhin durch einen separaten Website-Build. Ein Schreibagent kann ein englisch-deutsches Artikelpaar vorbereiten und bestehende Beiträge überarbeiten. Entscheidend ist, wer aus einer solchen Überarbeitung eine öffentliche Seite machen darf. Für ein Team, das die Veröffentlichung automatisieren möchte, ist die CMS-Freigabe nur ein Prüfpunkt: Die akzeptierte Revision muss auch die Website erreichen und mit der Fassung übereinstimmen, die Leser erhalten. Die nativen Datensätze speichern den 28. September 2026 als erstes Veröffentlichungsdatum. Davon getrennt beschrieb der archivierte Text des Betreibers eine Veröffentlichung durch einen Menschen. Wann ein Besucher diese Seite erstmals erhielt, lässt sich daraus nicht rekonstruieren. Am 11. Oktober erhielt diese Installation eine unabhängige automatische Prüfung mit einer separaten Publisher-Identität. Die öffentlichen URLs und die nativen Markdown-Inhalte bleiben erhalten. Die folgenden Prüfungen sind datierte Beobachtungen aus dieser eigenen Installation. Sie zertifizieren keine anderen EmDash-Installationen. Die Veröffentlichung einer geprüften Überarbeitung erfordert mehr als eine regelmäßig ausgeführte Schreibaufgabe. Vier Grenzen bestimmen, ob die automatische Veröffentlichung kontrolliert abläuft oder lediglich einen weiteren Schreibzugang zur Produktion schafft. ## 1. Eine Schreibrolle begrenzt noch keinen Produktzugang Der [Content-Lifecycle von EmDash](https://docs.emdashcms.com/reference/content-lifecycle/) erlaubt Autoren Aktionen an ihren eigenen Einträgen und Editoren Aktionen an anderen Einträgen. Bearbeiten und Veröffentlichen sind separate Vorgänge. Die normale Autorenrolle darf bei eigenen Inhalten jedoch beides. Ein API-Token verliert diese Berechtigung nicht dadurch, dass man es „Writer“ nennt. Die vom Betreiber berichtete Codeprüfung am 11. Oktober fand eine Grenze, die Zugang und angeforderte Aktion vor dem nativen Schreibvorgang prüft. Sie ordnet diesen Schreibzugang den Entwürfen in `posts` zu. Das Lesen nach der Registrierung bestätigte außerdem eine separate Publisher-Liste im nativen Veröffentlichungsplugin. Die folgenden Live-Prüfungen belegen bestimmte Ablehnungen. Sie beweisen keine vollständige Berechtigungsmatrix. Ein konkretes Beispiel ist die Korrektur eines Quellenlinks. Der Agent muss die Korrektur speichern dürfen. Dafür braucht er noch keine Berechtigung, sie öffentlich zu machen. Die Trennung hält einen falschen Link im Entwurf, bis die Prüfung das Problem geklärt hat. Die Live-Prüfung am 11. Oktober 2026 lieferte HTTP 200 für das authentifizierte Lesen eines eigenen Beitrags. Anfragen zum Veröffentlichen, Planen und Zurückziehen lieferten 403. Weitere abgelehnte Anfragen versuchten, Freigaben, Veröffentlichungsdaten und SEO-Overlays zu ändern. Das anschließende Lesen bestätigte, dass diese Prüfungen keinen Inhalt verändert hatten. Die Grenze umfasst auch die erlaubten MCP-Werkzeuge. Eine `content_list`-Anfrage für `posts` war erfolgreich. Ein Aufruf von `content_publish` und eine Listenanfrage für eine andere Sammlung lieferten 403. Diese Ergebnisse beschreiben die Zugangsgrenze dieser Installation. Sie behaupten nicht, dass alle EmDash-Installationen diese Werkzeuge sperren. ## 2. Metadaten müssen mit dem geprüften Text erscheinen Die Prüfung der installierten EmDash-Handler in Version 1.0.1 zeigte einen separaten Speicher und Änderungsweg für die SEO-Daten eines Eintrags. Das ist eine Beobachtung des Codes dieser Version. Eine sofort wirksame Overlay-Änderung bleibt ungetestet. Die Live-Prüfung belegte die engere Aussage: Dieser Schreibzugang lehnt eine Anfrage mit SEO-Overlay mit HTTP 403 ab. Der Agent legt Titel und Auszug in den Inhaltsfeldern ab. Die vom Betreiber berichtete Codeprüfung am 11. Oktober verfolgte diese Felder durch die Synchronisierung bis zu Titel, Beschreibung und BlogPosting-Metadaten der Website. Diese Prüfung beschreibt den installierten Veröffentlichungsweg. Sie belegt nicht die Wirkung einer nativen Overlay-Änderung. Für Datumsangaben gilt dieselbe Sorgfalt. Die aktuelle [Lifecycle-Dokumentation](https://docs.emdashcms.com/reference/content-lifecycle/) erhält in der Tabellenzeile Publish das erste Datum bei späteren Veröffentlichungen. Ein berechtigter Aufrufer kann es jedoch überschreiben. Die vom Betreiber berichtete Codeprüfung am 11. Oktober fand eine Prüfung von Eintrag, Sammlung und Erstellungszeit der Live-Revision. Daraus und aus dem nativen ersten Veröffentlichungsdatum bildet dieser Lesezugang den ausgegebenen Änderungszeitpunkt. Eine ausstehende Korrektur darf eine unveränderte öffentliche Seite nicht wie eine frisch geprüfte Seite aussehen lassen. Die vom Betreiber berichtete Codeprüfung am 11. Oktober fand `data.markdown` als Textquelle der nativen Veröffentlichungsprüfung und der Website-Synchronisierung. Die Synchronisierung schreibt diese Zeichenfolge in generierte Markdown-Dateien, die Astro baut. Sie hat keinen Portable-Text-Fallback. Das ältere Feld `content` enthält die September-Fassung, liefert aber keinen Text für diesen Weg. Während die Überarbeitung ausstand, lieferte eine authentifizierte Leseprüfung weiterhin das vorherige Markdown und die Veröffentlichungs- und Revisionsdaten vom 28. September. Sie gab keinen Verweis auf eine ausstehende Entwurfsrevision aus. Das ist ein beobachtetes Ergebnis während einer offenen Bearbeitung. Es belegt keine spätere Veröffentlichung. Ein vom Schreibagenten eingetragenes Datum würde weder eine Prüfung noch einen Release nachweisen. ## 3. Eine Freigabe gehört zu genau einer Revision Zwischen „freigegeben“ und „veröffentlicht“ kann eine Prüfung bereits veraltet sein. Angenommen, ein Prüfer akzeptiert einen Entwurf und danach ändert ein Editor dessen Quellenlink. Wer dann einfach den aktuellen Text veröffentlicht, überträgt die alte Freigabe auf einen neuen Inhalt. Die aktuelle [REST-Dokumentation](https://docs.emdashcms.com/reference/rest-api/) beschreibt ein undurchsichtiges Revisionstoken namens `_rev`. Beim authentifizierten Lesen dieser installierten Version 1.0.1 gab die vom Betreiber berichtete Prüfung am 11. Oktober dieses Token zurück. Eine Änderung mit dem aktuellen Token schützt davor, gleichzeitig entstandene Änderungen zu überschreiben. Am 11. Oktober lieferten sowohl ein REST-Änderungsversuch als auch ein MCP-Aufruf von `content_update` ohne `_rev` jeweils 403. Die Revision des Eintrags blieb unverändert. Die vom Betreiber berichtete Codeprüfung am 11. Oktober fand zwei getrennte Prüfungen im ausgelieferten Publisher. Er vergleicht Nutzdaten, URL-Slug und gespeicherte Referenzen mit dem erfassten Prüfeingang. Zusätzlich sendet er das aktuelle `_rev` beim Veröffentlichen, um eine zwischenzeitliche Änderung abzuweisen. Während der Berechtigungstests stand seine erste automatische Veröffentlichung dieses Artikels noch aus. Später am 11. Oktober akzeptierte der native Publisher die englische und die deutsche Revision. Eine erneute Leseprüfung am 13. Oktober bestätigte beide Live-Revisionen und das übereinstimmende öffentliche Markdown. Was diese Prüfung belegt, erklärt der Abschnitt zur ausgelieferten Seite. Eine spätere Änderung verlangt eine neue Prüfung. Das Wort `approved` in einem Inhaltsfeld reicht nicht aus, wenn sich Text, URL-Slug oder Referenzen inzwischen geändert haben. Auch fehlgeschlagene Anfragen müssen anders behandelt werden. Bricht die Verbindung ab, bevor die Antwort auf einen Speichervorgang ankommt, liest der Agent zuerst den bestehenden Eintrag. Ein erfolgreiches, aber unbemerktes Anlegen könnte sonst zwei Beiträge erzeugen. Die aktuelle Lifecycle-Dokumentation beschreibt dieses Lesen vor einem erneuten Versuch unter Conflicts and retries. ## 4. Eine Inhaltsprüfung isoliert keinen Plugin-Code Die vom Betreiber berichtete Prüfung am 11. Oktober fand direkt registrierte eigene Plugin-Funktionen in diesem CMS-Build. Seine kompilierte Sandbox-Konfiguration stand auf false. Das ist eine Code- und Build-Beobachtung, kein Laufzeitnachweis für Isolation. Veröffentlichungsprüfung und Plugin-Isolation bleiben getrennte Entscheidungen. Der archivierte September-Text bezeichnete das Produkt als geschlossene Beta und dieses Konto als nicht freigeschaltet. Diese Statusaussage war nicht belegt. Cloudflare beschreibt Dynamic Workers in seiner [Ankündigung vom 24. März 2026](https://developers.cloudflare.com/changelog/post/2026-03-24-dynamic-workers-open-beta/) als offene Beta für zahlende Workers-Nutzer. Die frühere Worker-Loader-Dokumentationsadresse führt inzwischen zur offiziellen [Dynamic-Workers-Dokumentation](https://developers.cloudflare.com/dynamic-workers/). Sie beschreibt Grenzen für Bindings und Netzwerkzugang. Das belegt nicht die Konfiguration dieses Kontos. Die geprüfte Veröffentlichungsänderung erhielt diese Sandbox-Konfiguration. Ein Wechsel in diese Sandbox braucht deshalb eine eigene Umsetzung und Prüfung. Er rechtfertigt weder, ein im CMS-Prozess laufendes Plugin als isoliert zu bezeichnen, noch eine Inhaltsprüfung mit einer Sicherheitsprüfung des Codes gleichzusetzen. ## Von der geprüften Revision zur ausgelieferten Seite Ein CMS kann erfolgreich veröffentlichen, während eine separate Website noch einen älteren Build ausliefert. In dieser Architektur muss jede Übergabe geprüft werden, bevor eine Korrektur als live gilt: | Prüfpunkt | Beleg | Noch offen | | --- | --- | --- | | Im CMS akzeptiert | Live-Revision und geprüfter Text stimmen überein. | Auslieferung der Website. | | Synchronisiert und ausgeliefert | Generierter Text stimmt überein; normaler Release ist erfolgreich. | Antwort an Leser. | | Auf der öffentlichen Seite gelesen | Seite, Markdown und Metadaten stimmen überein. | Indexierung, KI-Zitate und nützlicher Traffic. | Vor dieser Überarbeitung fand die Prüfung am 13. Oktober die englische akzeptierte Revision vom 11. Oktober um 20:33:56 UTC und die deutsche um 20:32:47 UTC. Das öffentliche Markdown entsprach beiden Texten. Die BlogPosting-Metadaten beider Seiten behielten den 28. September als Veröffentlichungstag und verwendeten den 11. Oktober als Änderungstag. Das sind beobachtete gespeicherte und ausgelieferte Felder. Sie rekonstruieren keinen ersten historischen Besuch. Auch für den vorherigen Content Sync und Worker Release lag ein erfolgreicher Abschluss vor. Diese Vergleiche grenzen eine fehlgeschlagene Übergabe ein. Liefert der CMS-Lesezugang noch den alten Text, sind Prüfung und Übernahme zu untersuchen. Liefert das CMS die Korrektur, die Website aber nicht, sind Synchronisierung, Release und ausgelieferte Version zu prüfen, bevor erneut eingereicht wird. Ein zweiter Entwurf repariert keinen fehlenden Website-Release. Danach folgt die Auffindbarkeit: Über das sichtbare Blog-Menü zu Verzeichnis und Artikel gehen, den Link zur veröffentlichten Sprachfassung prüfen und genau einen kanonischen Eintrag in der angekündigten Sitemap finden. Das prüft einen Leserweg und Abrufmöglichkeiten. Es belegt keine Indexierung der Korrektur durch eine Suchmaschine. Die Entscheidung zur Veröffentlichung endet mit der geprüften Revision auf der tatsächlichen Seite; Auffindbarkeit und Wachstum werden getrennt erfasst.