WordPress-Umgebungen

Diese Seite dokumentiert den am 28. August 2026 rein lesend verifizierten Dateisystembestand des eigenen MCP-, Codex- und Support-Codes auf stage.webdevmedia.de, active.webdevmedia.de und fallback.webdevmedia.de. Der eng autorisierte Stage-Rollout vom 3. September aktualisierte ausschließlich MCP Adapter und Session Compatibility; Active und Fallback blieben unverändert.

Der Stage-Eintrag wurde anschließend durch die autorisierten, getesteten Rollouts auf Codex CLI 1.10.1, Telegram-Support 1.2.0 und die dynamische Basis-/Supervisor-Generation 379fa9c1faed-4f1a9c0659c2 fortgeschrieben. Die historischen Inventurzahlen wurden dabei nicht neu berechnet. Der aktuelle Stage-Stand ergänzt außerdem den LLM-first Site Locator, Basis 0.16.1, Codex CLI 1.10.1 und den stabilisierten MCP-Fehlervertrag. Active, Fallback und Stage1 erhielten keine Datei-, Datenbank-, Options-, Plugin- oder Routenänderung.

Wichtige Abgrenzung: Dateisystembestand ist keine WordPress-Aktivierung

Ein vorhandenes Pluginverzeichnis und ein internes runtime/active-release.json belegen allein weder die Aktivierung des Plugins in WordPress noch dessen aktuelle Nutzung. Für den Stage-Bundle-Rollout wurden nur das aktive Basis-/Supervisor-Paar und seine engen Optionswerte gelesen und vor/nach der Migration nachgewiesen. Andere Pluginaktivierungen, redaktionelle Inhalte, Uploads, Nutzer, Themes, Fremdplugins und geschützte Konfigurationswerte wurden nicht untersucht.

Umgebungen und Umfang

Die Rollenbezeichnungen folgen den drei Hostnamen. Aus dem Namen Active oder Fallback wird keine darüber hinausgehende Betriebszusage abgeleitet.

Die Dateisystemwurzeln folgen jeweils /var/www/virtual/wpmcp/<host>. Die Zahlen beziehen sich auf die inventarisierten Pluginverzeichnisse einschließlich des Migration Installers. Der gemeinsame MU-Guardian und ein verdeckter historischer Stage-Checkout sind gesondert dokumentiert und nicht eingerechnet.

Vollständiger Versionsbestand

Git-genau bedeutet, dass Pfade und Datei-Blobs eines vollständigen Pluginbaums einem Forgejo-Commit entsprechen. Release-genau bezeichnet die bytegleiche Übereinstimmung mit einem lokalen Release-Artefakt. Drift bedeutet, dass die Projektlinie belegt sein kann, aber kein vollständiger Commit- oder Release-Match für den beobachteten Baum vorliegt.

Provenienz und nachweisbarer Drift

Active und Fallback

Die 13 gemeinsamen mcp*-Pluginbäume von Active und Fallback sind byteidentisch. Sämtliche 17 mcp*-Bäume auf Active und sämtliche 13 auf Fallback entsprechen jeweils vollständig einem Forgejo-Unterbaum.

Active enthält gegenüber Fallback zusätzlich Event, Specials, Teacher und Google Photos. Der Migration Installer gehört nicht zur byteidentischen Kernmenge: Stage und Active führen 1.0.0, Fallback führt einen größeren 2.0.0-Baum mit MCP-Featuremanifest.

Stage

Warnsignal: Sieben Stage-Bäume besitzen keinen vollständigen Git- oder Release-Match

Betroffen sind Course Admin 1.3.0, Event Admin 1.1.0, Room Gallery 1.0.0, Teacher Admin 1.1.0, Anandayoga 0.6.2, Git Command Run 0.2.0 und Higgsfield 0.2.0. Bei mehreren Komponenten belegen Manifeste oder einzelne Git-Blobs die Projektlinie; der exakt beobachtete Gesamtbaum bleibt dennoch unaufgelöst. Unbekannter Drift wird nicht als Commitstand ausgegeben.

Metadaten-Widersprüche und Nebenartefakte

• Telegram Support meldet im Plugin-Header und Featuremanifest 1.2.0, im Update- sowie internen Releasemanifest weiterhin 0.1.0.
• Die Higgsfield- und Basisplugin-Deploymarker auf Active/Fallback nennen einen älteren mcp_zentral-Stand, während die vollständigen beobachteten Bäume anderen Forgejo-Commits entsprechen.
• Die Stage-Deploymarker von Higgsfield und Anandayoga nennen Commits, deren Loader nicht mit dem beobachteten Loader übereinstimmen.
• Der Fallback-Migration-Installer 2.0.0 bezeichnet sich als development und implemented_pending_integration; dies ist kein betrieblicher Freigabestatus.
• Stage enthält zusätzlich den nicht eingerechneten, verdeckten und sauberen Git-Checkout .mcp_wordpress_php-pre-0.13.0- 20260819T162059Z, Version 0.12.1, HEAD 69e8af6d6610.
• Der MU-Guardian unter wp-content/mu-plugins/ mit Datei 000-mcp-guardian.php ist auf allen drei Sites byteidentisch und besitzt den SHA-256 2aeba9b9e17c…f5a69761.
• Die zugehörigen mcp-update-config.json-Dateien sind mit Modus 0600 geschützt. Ihre Werte wurden nicht gelesen.

Technische Routen

Die historische Inventur verwendete ausschließlich körperlose HEAD- und OPTIONS-Anfragen. Der Stage-Bundle-Rollout ergänzte einen vollständigen Streamable-HTTP-MCP-Lauf mit getrennten Transportsitzungen; die Aussagen zu Active und Fallback bleiben reine Erreichbarkeitsprüfung.

Im verifizierten Basiscode sind außerdem OAuth-Routen für Authorisierung, Registrierung, Token, Revocation, Introspection und Principal-Verifikation sowie tokenisierte Screenshot-Downloads deklariert. Stage besitzt zusätzlich eine Screenshot-Preview-Route. Diese Routen wurden nicht operativ aufgerufen. Für Codex CLI, Codex Reauth, Codex-CLI-Bridge und Telegram Support wurden keine getrennten REST-Routen gefunden; sie stellen ihre Fähigkeiten über den Basis-MCP bereit.

Die Stage-Kurzroute https://stage.webdevmedia.de/mcp ist der offizielle ChatGPT-Connector mit No Auth. Initialize, vollständig paginiertes tools/list und Collaboration-Aufrufe wurden dort und über den Central-Proxy https://mcp.webdevmedia.de/stage mit jeweils zwei getrennten MCP-Transport-Sitzungen geprüft. Customer und der exakt gefencete Stage-Gast sehen acht Swarm-Werkzeuge; der Default-Gast sieht null. Bedienung und Sicherheitsgrenzen stehen unter ChatGPT-Swarm-MCP auf Stage.

MCP-Fehlervertrag und Session Compatibility

MCP Adapter 0.6.1 liefert Fehler aus Permission-, Pre-Call-, Provider- und Post-Call-Pfaden als normale Toolresultate mit HTTP 200. isError ist dabei true; structuredContent enthält ok: false, einen normalisierten error_code und eine begrenzte Nachricht. Der Textblock enthält dieselben Daten als kompaktes JSON. Fachliche WP_Error-Codes bleiben erhalten; Exceptions und von der WordPress-Abilities-Schicht verpackte ability_callback_exception werden als mcp_tool_execution_failed ausgegeben. Bearer-Werte, Basic-Authorization und bekannte signierte URL-Parameter werden vor Antwort und Log redigiert. Ungültige JSON-RPC- Requests und unbekannte Werkzeuge bleiben Protokollfehler.

Der Standardaufruf tools/list liefert höchstens 25 Werkzeuge pro Seite und einen kataloggebundenen Cursor. Die Erweiterung tools/list/all liefert den vollständigen, rollenbereinigten Katalog. Der Filter mcp_adapter_tools_list erhält als dritten Parameter die aufrufende Methode, damit Standard- und Vollkatalog gezielt unterschieden werden können. Ein fehlgeschlagener Toolcall verändert weder die registrierten Werkzeuge noch die Adapter-Session.

Session Compatibility 0.1.2 greift erst nach der Transportberechtigung ein. Ein fehlender oder veralteter Mcp-Session-Id-Header wird für die kanonische MCP-Route aus dem gültigen gebundenen Zustand wiederhergestellt; ein anderer, bereits gültiger Header gewinnt. initialize verwirft eine alte Bindung und liefert eine neue Session, DELETE entfernt nur die passende Bindung. Kann die Schicht nicht sicher wiederherstellen, antwortet sie explizit mit 503, statt den Request still abzubrechen.

Bestandener Stage-Smoke

Der Stage-Smoke verwendete ausschließlich ein kurzzeitig aktiviertes synthetisches Testplugin. Kontrollierte Provider-WP_Error, Exception, Permission-, Pre-Call- und Post-Call-Fehler bestanden jeweils den strukturierten Fehlervertrag; unmittelbar danach funktionierten tools/list, tools/list/all und ein erfolgreicher Toolcall weiter. Der kanonische Vollkatalog enthielt 309 Werkzeuge, darunter 27 anandayoga__-Werkzeuge; anandayoga__site_status war read-only aufrufbar, und der Yoga-Katalog blieb nach einem Reconnect vorhanden. Fehlende, veraltete und gewechselte Session-Header wurden ebenfalls geprüft. Der Smoke rief keinen Medienimport auf. Attachment-Zahl, Startseitenoption und die gezielt beobachteten Collaboration-Artefakte waren vor und nach dem Test identisch. Das Testplugin wurde danach deaktiviert und aus dem Live- Pluginverzeichnis entfernt.

Der Site Locator ist in Basis 0.16.1 standardmäßig LLM-first. Ein parameterloser authentifizierter Stage-Smoke lieferte resolution_mode: remote_llm, dispatch_state: accepted, search_mode: llm_preferred, Profil quick und Umfang low. Spark wurde zuerst versucht; der vollständige Snapshot wechselte nach einem technischen Primärfehler kontrolliert auf Luna. Erzwungene deterministische Suche kontaktierte den Adapter nicht, und ein simulierter vollständiger LLM-Ausfall aktivierte den lokalen Fallback.

Releases, Rollback und Wiederherstellung

• In den inventarisierten Pluginbäumen existieren keine aktiven Symlinks. Featureplugins wählen interne Releases teilweise über runtime/active-release.json; das ist weder ein WordPress-Aktivierungs- noch ein Live-Healthnachweis.
• MCP Adapter 0.6.1 und Session Compatibility 0.1.2 wurden aus Forgejo-main 647fc5bc1e69910d324dda6b4946a55cfde462c2 gemeinsam per atomarem Verzeichnistausch aktiviert. Der unmittelbar vorherige Stage-Stand bleibt unter /home/wpmcp/.deployments/yoga-mcp-stabilization-20260903/647fc5bc1e69910d324dda6b4946a55cfde462c2/backups/ getrennt erhalten. Release und Live-Bäume waren nach dem Smoke bytegleich.
• Das Stage-Bundle aktiviert Basis 0.16.1 exakt vor Supervisor 0.3.0 als dynamisches Paar in Generation 379fa9c1faed-4f1a9c0659c2; der direkte Vorgänger bleibt als Rollbackgeneration vorhanden. State-Schema 4, Generation-Fence und Provenienz sind konsistent.
• Die Stage-only Generation-0-Modusmigration lief versioniert als Dry-run, bestätigtes Apply und belegtes No-op. Sie normalisierte 27 von 217 geprüften owner-eigenen Pfaden von 0775/0664 auf 0755/0644, ohne Bytes, Owner, Aktivierungen oder Optionen zu ändern. Deployment-, Request-Lock und dauerhafter Fence machen den monotonen Mischzustand nach einem Abbruch sicher retrybar; ein Prozessende hinterlässt kein Gate.
• bundle-health war strikt read-only, bundle-smoke operational grün. Direkt und Central bestanden jeweils Initialize, vollständig paginiertes tools/list, exakt acht identische Swarm-Schemas und einen terminalen Zwei-Sitzungs-Ablauf.
• Der direkte Transport prüfte leeres Timeout, frühen Wakeup, mehrere Nachrichten, At-least-once-Replay, Cursorfortschritt/-Reset mit Sync, Run-/Quota-Resume, echte stale-Master-Lease samt manueller Resume-Anweisung, Handoff, Fencing und terminalen Abschluss.
• Central prüfte getrennte Master-/Worker-Transporte, Join-Pending, Approval/Finalize, sofortigen Wait mit mehreren Nachrichten, Handoff und terminalen Wait.
• Aktives Central-Release ist mcp-central-20260901T100309Z-ff1617807767 aus ff1617807767; der zuvor aktivierte mcp-central-20260901T094913Z-911d4b4cf5ef bleibt unmittelbarer Rückweg.
• Unter /home/wpmcp/.mcp-central/deploy/rollbacks/ im Unterordner stage/ liegen ältere Stage-Snapshots für Basisplugin, Anandayoga, Higgsfield und Codex CLI.
• Unter /home/wpmcp/plugin-backups/ liegen weitere Basis- und Codex-Snapshots, deren eindeutige Zuordnung zu Active oder Fallback nicht belegt ist.
• Codex CLI 1.10.1 wurde auf Stage als Release mcp-codex-cli-1.10.1-282b52b2 über den versionierten RENAME_EXCHANGE-Publisher atomar aktiviert. 1.10.0 bleibt unmittelbarer Austauschpartner; ältere geprüfte Rückwege bleiben getrennt erhalten. Telegram Support 1.2.0 blieb unverändert.
• Für Active und Fallback wurde kein eigener, eindeutig benannter Rollbackpfad gefunden. Die Git-genauen Pluginbäume sind rekonstruierbar, ersetzen aber keinen geprüften atomaren Rollbackablauf.
• Active und Fallback blieben während der gesamten Inventur strikt read-only; es wurde kein Deployment, Rollback oder Reparaturversuch ausgeführt.

Warnsignal: Kein belegter atomarer Rollback für Active und Fallback

Vor einer späteren Änderung muss ein eigener, getesteter und eindeutig der jeweiligen Umgebung zugeordneter Rollbackweg festgelegt werden. Die vorhandenen Stage- und Alt-Snapshots dürfen nicht ohne neue Prüfung übertragen werden.

Bewusst unbekannte Punkte

• Aktivierungszustand und Konfiguration anderer WordPress-Plugins; das verwaltete Stage-Basis-/Supervisor-Paar ist dagegen aktiviert und nachgewiesen;
• Inhalt der geschützten MCP-Konfigurationen und aller Zugangsdaten;
• authentifizierte MCP-Rollen außerhalb des separat geprüften Stage-Codex-Plugins und des exakt freigegebenen Stage-Collaboration-Gast-/Customer-Kontexts;
• Ursprung des nicht eingecheckten Stage-Drifts und des Fallback-Migration-Installers 2.0.0;
• betriebliche Umschalt- und Wiederherstellungslogik zwischen Active und Fallback.

Diese Punkte bleiben unbekannt, bis sie in einem gesondert autorisierten, datenschutzkonformen Auftrag verifiziert werden.