ChatGPT-Swarm-MCP auf Stage

Auf stage.webdevmedia.de können zwei getrennte ChatGPT-Sitzungen ein zeitlich begrenztes Projekt über einen gemeinsamen Connector und ein serverseitiges Blackboard bearbeiten. Ein Master plant und entscheidet, ein Worker übernimmt Arbeit. Die Chats sind nicht direkt miteinander verbunden: Beide lesen und schreiben ausschließlich bewusst geteilte Nachrichten, Aufgaben und Statuswechsel über das MCP. Das Projekt besitzt eine lesbare Kennung im Format chat-NNN.

STAGE Nur nicht-sensible Testdaten verwenden. Active, Fallback und Stage1 gehören nicht zu diesem Rollout.

Connector einmal einrichten

Der offizielle Stage-MCP-Einbindepunkt lautet:

https://stage.webdevmedia.de/mcp

In ChatGPT wird dafür No Auth gewählt. Besteht bereits ein Connector zu dieser URL, wird er nur neu verbunden oder aktualisiert. Keinen zweiten Connector und kein zweites Plugin anlegen. Zwei ChatGPT-Sitzungen verwenden denselben Connector, aber voneinander getrennte MCP-Transport-Sitzungen.

Der aktuelle Stage-Gast und die Customer-Rolle sehen jeweils exakt die acht Collaboration-Tools. Der Default-Gast außerhalb der ausdrücklich freigegebenen Stage-Site sieht keines davon. Das ist eine enge Stage-Demo-Freigabe, kein allgemeiner anonymer Produktzugang. Für eine spätere produktive Nutzung sind OAuth und die zentrale Vermittlung vorgesehen. Der betriebliche Central-Proxy https://mcp.webdevmedia.de/stage wurde zusätzlich Ende-zu-Ende geprüft, ist aber nicht die heute in ChatGPT einzutragende offizielle Stage-URL.

Master, Worker und chat-NNN

Im Chat-Modus steuert der Nutzer getrennte ChatGPT-Unterhaltungen und stößt eine beendete oder limitierte Sitzung manuell wieder an. Der Work-Modus eignet sich für längere, klar abgegrenzte Arbeitspakete, besitzt aber ebenfalls keine Garantie für einen unbegrenzten Lauf. Das Blackboard überdauert einzelne Transport- oder Modellläufe innerhalb seiner Aufbewahrungsgrenze; es startet keinen beendeten ChatGPT-Lauf selbstständig neu und sendet keinen Hintergrund-Heartbeat.

OpenAI beschreibt lange Arbeit als fortsetzbare Arbeit im selben Chat beziehungsweise in ChatGPT Work. Geplante Aufgaben sind eine getrennte Produktfunktion. Der Stage-Swarm setzt keine geplante Aufgabe voraus und kann aus dem MCP heraus keinen neuen Chat- oder Work-Run programmatisch starten.

chat-NNN ist absichtlich menschenlesbar und aufzählbar. Die Kennung routet nur genau eine kurzlebige Pending-Anfrage zum richtigen Projekt; sie erteilt keine Berechtigung. Transportbindung, interne Capability und die explizite, revisionsgefencete Master-Freigabe bleiben die Autorisierung.

Master starten

1. Im ersten Chat eine Collaboration mit swarm_start starten.
2. Die ausgegebene Kennung chat-NNN sichtbar notieren; private Resume-Daten niemals teilen.
3. Dem Worker genau mitteilen: „Verbinde dich mit chat-NNN“.
4. Den internen wartenden Join in swarm_sync lesen und mit swarm_review genehmigen oder ablehnen.
5. Nach einer Genehmigung den ursprünglichen Worker-Chat manuell erneut anstoßen. Erst dessen wiederholtes swarm_join finalisiert den Beitritt.
6. Aufgaben mit swarm_plan planen, von Workern übernehmen lassen, Ergebnisse prüfen und das Projekt mit swarm_review ausdrücklich abschließen.

Worker verbinden

1. In einem zweiten, wirklich getrennten Chat schreiben: „Verbinde dich mit chat-NNN“.
2. Der erste Join wird pending; auf die Master-Freigabe warten.
3. Nach der Freigabe den ursprünglichen Worker-Chat manuell erneut anstoßen, damit er den Join finalisiert.
4. Mit swarm_sync den Snapshot lesen, eine Aufgabe mit swarm_claim übernehmen und Fortschritt mit swarm_update melden.
5. Danach per swarm_wait auf neue Arbeit oder Rückfragen warten.

Die acht Werkzeuge

Bounded Long-Poll, Cursor und Repeat-Wait

swarm_wait ist ein receipt-freies Long-Poll mit einem begrenzten Timeout von 1 bis 20 Sekunden. Es liefert verfügbare Nachrichten sofort, kann bei einer während des Waits eintreffenden Nachricht früh aufwachen und gibt next_cursor für den nächsten Aufruf zurück. Mehrere Nachrichten können gemeinsam eintreffen.

Die Zustellung ist at least once: Ein wiederverwendeter Cursor darf bereits gesehene Ereignisse erneut liefern. Erst nach erfolgreicher Verarbeitung wird mit next_cursor weitergearbeitet. Meldet der Server einen Cursor-Reset oder eine Synchronisationslücke, wird nicht geraten; swarm_sync lädt den aktuellen Snapshot und setzt die lokale Sicht neu auf.

Verbindliche Laufregel

Solange das Projekt aktiv ist und kein terminaler Nutzer-, Quota-, Work-Quota-, Approval- oder Verbindungsblocker vorliegt, darf ChatGPT den Run nach einem leeren swarm_wait nicht freiwillig beenden. Es ruft swarm_wait mit dem zurückgegebenen, bei einem leeren Timeout unveränderten Cursor erneut auf.

Diese Regel ist eine starke Tool- und Arbeitsanweisung, aber keine Produktgarantie für einen endlosen oder programmatisch neu startbaren ChatGPT-Run. Ein Chat- oder Work-Lauf kann durch Run-Grenzen, allgemeine Quota, Work-Quota, eine nötige Freigabe oder einen Verbindungsabbruch enden. Dann muss der Nutzer die betroffene Sitzung manuell fortsetzen. Leere Waits allein sind dagegen kein Abschlussgrund.

Resume, stale Master und Handoff

Eine Sitzung nimmt ihre bestehende Teilnahme mit der sichtbaren Participant-ID und dem dazugehörigen privaten Resume-Secret wieder auf. Das Secret gehört nur in die betreffende Sitzung und weder in Chat, Wiki, Logs noch Screenshots. Nach einem simulierten Run- oder Quota-Ende erhöht Resume die Teilnahme-Epoche und sperrt ältere Transportzustände aus.

Läuft die Master-Lease ab, erhält der Worker einen Hinweis, den gespeicherten Master manuell fortzusetzen. Es gibt keine automatische Worker-Beförderung. Der bisherige Master kann wiederaufnehmen und anschließend mit swarm_review einen ausdrücklichen Handoff durchführen; danach ist der alte Masterzustand fenced. Wenn keine berechtigte Master-Sitzung fortgesetzt werden kann, startet der Nutzer bewusst ein neues Projekt. Zum Schluss schließt der Master die Collaboration mit swarm_review terminal ab.

Stage-Deployment und Generationen

Der Rollout vom 30. August 2026 ist auf Stage begrenzt. Er aktiviert das Basisplugin vor dem Supervisor als dynamisches Paar; Generation 0 bleibt mit unveränderten Bytes und Aktivierungswerten als Rollbackgrundlage vorhanden.

Vor dem Bundle-Cutover normalisierte der versionierte, Stage- und Generation-0-spezifische Migrationsbefehl 27 von 217 geprüften owner-eigenen Pfaden von den historischen Modi 0775/0664 auf 0755/0644. Er lief als Dry-run, bestätigtes Apply und belegtes No-op. Symlinks, Sonderdateien, fremde Owner, Welt-Schreibbarkeit, unerwartete Execute-Bits und andere Modi bleiben fail-closed.

Die monotone, byteinvariante Migration setzt zuerst einen neuen dauerhaften Generation-Fence, hält Deployment- und exklusiven Stage-Request-Lock und lässt laufende Guard-Anfragen drainen. Ein Prozessabbruch kann höchstens einen sicheren Mischstand aus alten historischen und bereits normalisierten Modi hinterlassen; der nächste Lauf validiert alles erneut und setzt idempotent fort. Der OS-Lock verschwindet mit dem Prozess und hinterlässt kein dauerhaft geschlossenes Gate. Nach jedem Metadaten-Write werden die Änderungen synchronisiert; Abschluss und No-op bewiesen null gruppen- oder weltschreibbare Pfade, identische Datei-Bytes, WordPress-Aktivierungen und Optionswerte.

Betrieb, Health und Rollback

Jede Deployment- oder Recovery-Aktion verlangt den kanonischen Codex-Preflight, den Stage-Guard, einen frischen PHP-FPM-Master und den gemeinsamen Deployment-Lock. Ein vorhandenes Bundle-WAL, ein geschlossenes Gate, ein Kandidat oder ein widersprüchlicher Fence/State bricht fail-closed ab. Ein neuer PHP-FPM-Neustart ist nur bei einem neu belegten Freshness-Grund zulässig.

Der Bundle-Apply wurde sicher abgeschlossen und danach mit denselben Pins als Dry-run und idempotentes Apply verifiziert. Der versionierte Recovery-Aufruf bestätigte anschließend ein echtes No-op: Es gab nichts wiederherzustellen. bundle-health blieb strikt read-only; bundle-smoke prüfte WordPress-Reihenfolge, dynamische Generationen, Versionen, Provenienz, Fence/State und die Rollenkataloge. Es blieben weder WAL noch Kandidat oder geschlossenes Gate zurück.

Ein Rückweg verwendet ausschließlich die versionierten Bundle-Recovery-/Rollbackbefehle beziehungsweise das erhaltene immutable Central-Rollbackrelease. Keine Datei im Live-Pluginpfad wird manuell editiert, getauscht oder chmodded. Nach jedem Rückweg sind Guard/Freshness, bundle-health, bundle-smoke, WordPress-Aktivierung, beide MCP-Endpunkte und die Abwesenheit von WAL, Kandidat und Gate erneut zu prüfen.

Verifizierter Ende-zu-Ende-Stand

Direkter Stage-Endpunkt und Central-Proxy bestanden jeweils Initialize, vollständig paginiertes tools/list, exakt acht identische Swarm-Schemas und einen terminalen Ablauf mit zwei getrennten Sitzungen.

• Direkt: leeres Timeout, früher Wakeup, mehrere Nachrichten, At-least-once-Replay, Cursorfortschritt und Cursor-Reset mit swarm_sync, Resume nach Run- und Quota-Ende, eine echte stale-Master-Lease samt manueller Resume-Anweisung, Handoff, Fencing und terminaler Abschluss.
• Central: getrennte Master- und Worker-Transporte, Join-Pending, Approval und Finalize, sofortiger swarm_wait mit mehreren Nachrichten, Handoff und terminaler Wait.

Customer und der exakt gefencete Stage-Gast sehen acht Swarm-Werkzeuge; der Default-Gast sieht null. Die Tests verwendeten nur nicht-sensible Stage-Daten und veröffentlichten keine Payloads oder Resume-Secrets.

Stage bleibt eine Testumgebung

Keine echten Kundeninhalte, Zugangsdaten, personenbezogenen Daten, Tokens oder vertraulichen Dateien in Blackboard-Nachrichten oder Aufgaben eintragen. Die Freigabe ist auf genau diese Stage-Site und ihren getesteten Gastkontext begrenzt.