Server-, Dienst- und Laufzeitinventar

Diese Seite dokumentiert datierte Nachprüfungen auf wpmcp und wpmcp00 sowie den historischen Infrastrukturstand auf wpmcp. Sie trennt Prozessstatus, HTTP-Health, Git-Provenienz und offene Punkte, damit ein laufender Prozess nicht versehentlich als vollständig funktionsfähiger Dienst gilt.

Ergänzung: MCP-Werkstatt auf wpmcp00, 5. September 2026

Die neue Domain mcp-lab.christian-igel.tech ist registriert und liefert eine statische Projektbeschreibung per HTTPS. Ihr DocumentRoot liegt unter /var/www/virtual/wpmcp00/html/mcp-lab.christian-igel.tech; der gleichnamige äußere Domainlink zeigt dorthin. Die erste Ausgabe benötigt etwa 40 KiB. Der Home-Verzeichnisstand vor dem Aufbau betrug rund 1,2 GB; die Abschlussmessung ergab rund 1,41 GB Gesamtbelegung und rund 41 MB für die MCP-Werkstatt. Ziel der neuen Plattform sind höchstens 5 GB Gesamtbelegung und sparsame Parallelität.

Die Konfigurations-CLI ~/mcp-lab/bin/lab ist aus Plattform-Commit ab9b185 aktiv. Der PHP-Stand 63b9cb9 bestand den externen HTTPS-Test über /test-mcp/ mit privatem Bearer: Initialisierung, Katalog mit zehn Tools, Anwendungssitzung und Echo. Anonyme Aufrufe antworten mit HTTP 401. Eine OAuth-Anbindung für ChatGPT und die reguläre Route /mcp sind noch nicht aktiviert.

Der kanonische Codex-Preflight ist wegen fehlender Anmeldung noch nicht erfolgreich. Daher ist der Server-Master nicht als betriebsbereit zu melden. Bestehende Passwörter und Account-Auswahl bleiben erhalten. Die vorgesehene Ananda-Testdomain ist anandayoga-zwickau.christian-igel.tech; Stage und Active werden durch diesen Aufbau nicht ersetzt. Details siehe MCP-Werkstatt.

Datierte Nachprüfungen und historischer Snapshot auf wpmcp

Eine gezielte autorisierte Nachprüfung am 1. September 2026 ergänzt den LLM-first Site Locator: Catalog LLM läuft sauber aus dem neuen privaten Forgejo-Repository catalog_llm auf Commit a77e1844ddef; MCP Central läuft als Release mcp-central-20260901T100309Z-ff1617807767. Stage verwendet Basis 0.16.1, Codex CLI 1.10.1 und die Plugin-Generation 379fa9c1faed-4f1a9c0659c2. Active und Fallback wurden nicht verändert.

Historischer Snapshot und Read-only-Grenze

Der historische Erhebungszeitpunkt ist 2026-08-28T11:56:29+02:00; aktuellere, ausdrücklich datierte Nachprüfungen überschreiben diesen Stand für die jeweils genannte Komponente. Gelesen wurden Konfigurationen ohne Credential-Werte, Prozess- und Socketmetadaten, Health-Endpunkte, Git-Objekte, Release-Manifeste sowie aggregierte Datenbank- und Dateimetadaten. Nicht gelesen wurden Rohlogs, Environment-Werte, Tokens, Cookies, Schlüssel, Prompts, Modellantworten, Supportnachrichten, Sitzungsinhalte, WordPress-Datenbanken, redaktionelle Inhalte oder Uploads. Alle drei WordPress-Umgebungen blieben strikt read-only.

Als historischer Snapshot bestätigten gezielte Nachprüfungen am 29. August die öffentliche Backendroute auf Port 8769, den damaligen Forgejo-main-Commit 59daed654023 sowie /usr/bin/ffmpeg und /usr/bin/ffprobe in Version 9.0. Der damalige Channel-Manager-Stand lief als Release 59daed654023, Version 0.4.1 und Schema 13.

Der aktuelle, am 30. August verifizierte Channel Manager läuft dagegen aus dem einzigen stabilen Git-Projektroot /home/wpmcp/codex-projects/channel-manager auf Forgejo-main-Commit d02537ca41c0, Paketversion 0.5.1 und Schema 13. Supervisor verwendet direkt diesen Root und dessen .venv/bin/channel-manager; der Prozess-CWD entspricht exakt dem Root. Lokaler und öffentlicher /healthz liefern 200, lokale und öffentliche unautorisierte /v1/messages liefern 401 und PRAGMA integrity_check liefert ok. Im Projektroot gibt es weder einen releases/-Unterbaum noch einen current-Symlink.

Der neue owner-only Supervisorprozess transcription-service läuft aus dem stabilen Git-Root /home/wpmcp/codex-projects/transcription-service auf Forgejo-main d5d85a85307b, Paketversion 0.1.1. Er besitzt weder TCP- Listener noch Webroute, sondern ausschließlich einen Socket 0600 im Stateverzeichnis 0700. Python 3.13, Health, Ready, SQLite-WAL, CLI, stdio-MCP, 30 Diensttests und die erfolgreiche synthetische Verifikationsprobe sind belegt. Providerantworten und eingehende Multipart-Bodies werden vor unbegrenztem Puffern begrenzt; Restart, Cancellation, Retention und Cleanup besitzen terminale, zeitgebundene Verträge.

Kurzstatus

• 12 RUNNING Supervisor-Programme laufen.
• 1 FATAL Der ältere Dokumentations-Inventurjob startet nicht stabil.
• 1 STOPPED Der separate Telegram-Supportdienst ist absichtlich on-demand konfiguriert.
• 3 WARNUNGEN Drei verwaiste PHP-QA-Listener besitzen bereits gelöschte Arbeitsverzeichnisse.

Nach dem Snapshot wurde als autorisierte Änderung der owner-only Dienst codex-session-inventory ergänzt. Der nachgeprüfte Stand vom 2026-08-28T13:41:53+02:00 umfasst deshalb 13 RUNNING, weiterhin ein FATAL- und ein bewusst gestopptes Programm, insgesamt 15 Supervisor-Programme.

Ein späterer autorisierter Rollout am selben Tag stellte MCP Central auf den atomaren service-current-Zeiger und Release mcp-central-20260828T210345Z-d2bef5dd2980 um. Rollback auf den vorherigen Release mcp-central-20260828T122500Z-54df654ed21d und erneute Aktivierung waren erfolgreich; öffentliche und Loopback-Health blieben grün. Der neue optionale codex-master-Upstream ist in der externen Konfiguration registriert, bleibt wegen des unten dokumentierten Master-Pushblockers aber bewusst deaktiviert.

Supervisor-Dienste und Listener

Zum ursprünglichen Snapshot besaßen alle 13 Supervisor-Konfigurationsdateien unter /home/wpmcp/etc/services.d/ Mode 0600; eine Datei definierte zwei Programme. Die autorisierte Session-Inventar-Konfiguration erhöhte den Bestand anschließend auf 14 Dateien und 15 Programme. Der Channel Manager lauscht auf allen Interfaces und wird inzwischen unter dem entfernten Präfix codex-master.webdevmedia.de/channel-manager veröffentlicht. Supervisor startet ihn direkt über /home/wpmcp/codex-projects/channel-manager/.venv/bin/channel-manager mit diesem festen Projektroot als CWD. Loopback- und Public-Health liefern 200; Adminrouten bleiben zusätzlich Bearer-geschützt.

Bestätigtes Problem: öffentliche Responses-Route

Das Uberspace-Backend für codex-master.webdevmedia.de und den Pfad /responses erwartet Port 8787 auf einer erreichbaren Schnittstelle. Der aktive Adapter bindet ausschließlich an 127.0.0.1; die Backendprüfung meldet deshalb NOT OK, wrong interface, und die öffentliche Route liefert 502. Die interne Loopback-Health bleibt davon unabhängig erfolgreich.

Warnsignal: verwaiste QA-Listener

Auf 127.0.0.1:18765, :18766 und :18767 laufen seit dem 27. August drei nicht von Supervisor verwaltete PHP-Testserver. Ihre Arbeitsverzeichnisse sind bereits gelöscht. Sie wurden während der Inventur nicht beendet.

MCP-Center, Umgebungen und öffentliche Routen

Der MCP-Center-Prozess bindet intern auf 127.0.0.1:61357; die Socat-Bridge veröffentlicht ihn über Port 61358. Die öffentliche Basis ist https://mcp.webdevmedia.de. Die Konfiguration erlaubt gemischtes OAuth, WordPress-Introspection und read-only Gastzugriff. Authorization Codes gelten 300 Sekunden, Access Tokens 600 Sekunden, Refresh Tokens 30 Tage und Center-Sessions eine Stunde.

401 belegt hier den geschützten Routenvertrag; 405 belegt, dass der HTTP-Pfad erreicht wird, aber ein gewöhnliches GET keine MCP-Anfrage ist. Beides ersetzt keinen authentifizierten End-to-End-Aufruf.

Der optionale Upstream stage-wordpress zeigt auf https://stage.webdevmedia.de/mcp, unterstützt per-user und Service-OAuth und ist für die Rollen Customer, Developer und Admin freigegeben. Ein unauthentifizierter Health-Snapshot meldete folgerichtig needs_auth statt eines Upstream-Ausfalls. Der zusätzliche Eintrag codex-master pinnt Master-Resource und Stage-Issuer, ist admin-only, optional und derzeit enabled: false; sein Tool-Präfix lautet codex_remote.

PHP-/Python-Bridge und lokales Gateway

Die Bridge unter 127.0.0.1:8791 verlangt Authentifizierung und begrenzt die Laufzeit auf 32 Verbindungen, 128 Sessions, 3.600 Sekunden Session-Idle sowie 40 MiB pro Protokollzeile. Die Standardroute startet vier PHP-CLI-Worker mit 60 Sekunden Timeout.

Das Gateway stellt einen begrenzten Gmail-MCP-/REST-Zugang bereit. Verifiziert wurden ausschließlich Zielhosts, OAuth-Scope, Größenlimits und die freigegebene Werkzeugliste; Absender-, Konto- und Credential-Werte blieben ungelesen.

Codex CLI, Profile und Wrapper

• Das globale Standalone-Bundle ist 0.147.0-x86_64-unknown-linux-musl; codex --version meldet 0.147.0.
• Fünf pseudonymisierte Laufzeitprofile besitzen jeweils ein Codex-Binary, ein Companion-Binary und ein Runtime-Manifest.
• Alle fünf Binärpaare stimmen per SHA-256 mit dem globalen Bundle überein.
• Vier der fünf Profile besitzen zum Snapshot lokale Auth-Metadaten; Identitäten und Werte wurden nicht gelesen.
• Der Account-Root ist 0700; Auth- und Config-Dateien sind 0600.
• Vier Session-Verzeichnisse sind 0700, eines ist 0775, bleibt aber durch den übergeordneten 0700-Root abgeschirmt.
• Der Account-Pool umfasst rund 4,30 GB und 8.499 Dateien.
• Der Wrapper helper-tools/bin/codex ist ein POSIX-Shellskript, select-account ein PHP-Skript; beide sind 0700 und syntaktisch gültig.
• Neue interaktive und automatisierte Prozesse verwenden ausschließlich den fail-closed Dispatcher /home/wpmcp/.local/bin/codex-current; codex-current --status liefert geheimnisfreien Auditstatus und codex-current --preflight prüft den gewählten Stand vor risikobehafteten Starts.
• Status und tiefer Preflight melden Schema 1, Registry-Schema 2, das vollständige 0.147.0-Runtime-Bundle und den Companion-Host als bereit. Neue Consumer dürfen den kompatiblen Helper-Wrapper nicht als zweite Account-Auswahlquelle verwenden.
• Die bewusste Auswahl erfolgt ausschließlich über den zentralen Selektor. Neue Sessions wählen kein Profil, durchsuchen keine Accountliste nach Volumen und verwenden keinen direkten accountgebundenen Wrapper-, Binary- oder Companion-Pfad.
• Der Dispatcher liest Registryposition 0 unter dem gemeinsamen Lock, prüft Wrapper und vollständiges Runtime-Bundle und friert diese Identität für den gestarteten Prozess ein. Ein späterer Auswahlwechsel wirkt erst auf neue Prozesse; Standalone- und Direktwege bleiben Diagnose-/Rollback-Fallbacks.

Öffentlich dokumentiert werden nur diese Aggregate. Accountnamen, Thread-IDs, Titel und Sitzungsbeschreibungen gehören in das authentifizierte interne Inventar.

Der rollen- und workspacegebundene Vertrag des auf Stage eingesetzten Plugins ist auf der Seite Stage-Codex-Plugin: Rollen- und Workspace-Policy dokumentiert.

Master-Relay und Jobmetadaten

Der Relay-Vertrag verwendet Audience codex-master-stage-relay/v1 und den Pfad /codex-mcp/internal/stage-relay/v1. Ein Preflight reserviert eine Operation für 15 Sekunden; anschließend folgen Execute und Status. Der Client-Mappingstore ist 0700, enthält 20 Dateien mit Mode 0600 und umfasst 3.900 Bytes.

Der einzelne Job lief mit gpt-5.6-sol, Reasoning high, Exitcode 0 und dauerte 7 Minuten 4 Sekunden. Prompt-, Antwort-, Thread- und Jobkennungen wurden nicht gelesen oder veröffentlicht.

Der öffentliche Codex-Master lädt derzeit direkt aus einem Helper-Worktree. Dieser besitzt elf modifizierte und zwei untracked Dateien. Der laufzeitrelevante PHP-Code entspricht nach Hash- und Zeilenendenabgleich dem belegten Forgejo-Stand stage_mcp_plugins main c562896c9a61; trotzdem fehlt der atomare Releasepfad.

Der geprüfte REST-/MCP-Kandidat liegt lokal auf 7c7f10a, kann aber nicht produktiv gebaut werden, solange kein für stage_mcp_plugins autorisierter Forgejo-Pushweg verfügbar ist. Ein direkter Bare-Repository-Push wurde vom fail-closed Forgejo-Hook abgelehnt; der SSH-Pfad besitzt keinen passenden Schlüssel. Der dirty Produktions-Worktree blieb unverändert.

Warnsignal: semantisch belegter, aber nicht atomarer Master-Stand

Der Runtime-Code ist auf einen Commit zurückführbar, wird jedoch aus einem dirty Worktree statt aus einem unveränderlichen Release geladen. Ein versehentlicher lokaler Edit könnte damit ohne Symlinkwechsel in Produktion wirksam werden.

Responses-Adapter

Die folgenden Counts stammen ausschließlich aus Tabellen- und Statusaggregaten. Response-Bodies, Inputs und Ausgaben wurden nicht gelesen.

Das aktive Artefakt d51f1b566155 ist bitgleich mit dem privaten Deployment-Tarball. Sein Pfadsatz entspricht Git-Commit ca0f64891d4e; nach Zeilenendennormalisierung stimmen 67 von 71 Dateien, vier weichen inhaltlich ab. Es ist daher rollbackbar, aber kein commitgenauer Release.

Catalog und Site Locator

Der öffentliche, getrackte Webroot-Shim lädt den sauberen Catalog-Worktree auf Forgejo-main-Commit a77e1844ddef. Der private Zustand unter var/ blieb beim Git-genauen Codewechsel unverändert. Der frühere unveröffentlichte Resilienzstand wurde vor dem Wechsel in denselben Forgejo-Verlauf übernommen.

Verifizierte POST-Routen sind:

• /catalog_llm/v1/responses
• /catalog_llm/v1/site-locator
• /catalog_llm/mcp

Der Site Locator erzeugt für jeden Turn einen frischen WordPress-Snapshot, übergibt ihn an Catalog und verwendet anschließend den lokalen Responses-Adapter. Authentifizierte Ende-zu-Ende-Läufe sind belegt:

• ohne optionale Parameter: llm_preferred, quick, Reasoning und Umfang low, remote_llm, Dispatch accepted;
• Quick versucht Spark zuerst und wechselt bei dessen technischem Fehler innerhalb derselben Deadline einmal auf Luna;
• Fast/Luna verarbeitet denselben vollständigen Snapshot direkt;
• kleine strukturierte Adapterproben bestanden für Luna/Low, Terra/Medium und Terra/Ultra sowie Sol/High und Sol/Ultra;
• erzwungene deterministische Suche bleibt not_dispatched; ein simulierter LLM-Ausfall liefert den kontrollierten deterministischen Fallback.

Screenshot-Service

Der Dienst läuft aus dem sauberen Forgejo-main f5b7498e1955, Version 0.1.0. Health meldet Selenium, Firefox, Geckodriver und Sandbox-Smoke als bereit. Die Jobdatenbank ist 0600, 32.768 Bytes groß und enthielt zum Snapshot keine Jobs; Artifact- und Runtime-Verzeichnisse waren leer.

Die Quellcode-Defaults sind 24 Stunden Job-Retention, ein Cleanup-Intervall von 300 Sekunden und 900 Sekunden Signed-URL-TTL. Aktive Environment-Overrides wurden aus Datenschutzgründen nicht gelesen. Die Supervisor-Konfiguration setzt für diesen Dienst keine expliziten Rotationsgrößen oder Backupzahlen; der effektive Default bleibt daher zu verifizieren.

Channel Manager und Support

Der Channel Manager verwendet nach Quellcode und Verbindungsmetadaten eine vorhandene Telegram-User-Session über Telethon. Er ist vom älteren, separat on-demand gestarteten Telegram-Supportdienst getrennt. Der feste Git-Projektroot ist 0700; die versionierte private config.json liegt direkt darin und ist 0600. Datenbank, Session, Registries, Medien und Logs liegen als persistente private Daten außerhalb des Projekts unter geschützten Verzeichnissen. Die private Inbound-Registry trennt Owner, zusätzliche Allowlist, Pending und Banned; sie entscheidet vor Medien, SQLite und LLM und trägt pro freigegebenem Nutzer getrennte Stage-/Serverrechte. Das vollständige redigierte Runbook steht unter Channel Manager, Telegram und Support.

Für den Audiovertrag ab Schema 13 sind /usr/bin/ffmpeg und /usr/bin/ffprobe feste Laufzeitabhängigkeiten. Beide wurden in Version 9.0 verifiziert; Opus-Decoding und die MP3-Normalisierung mit libmp3lame sind vorhanden. Der produktive Installcheck bestätigte Binarys, die direkt am Root liegende versionierte private config.json mit Mode 0600, die dort mit Python 3.13 und gesperrter Abhängigkeitsspezifikation aufgebaute venv sowie das private 0700-Arbeitsverzeichnis. Schema 13 wurde aus einer integritätsgeprüften Schema-12-Sicherung additiv migriert. Ein Code-Rollback behält Schema 13 und setzt ein grünes Audio-rollback-check voraus. Der Voice-/Audio-Vertrag blieb beim Wechsel auf Version 0.4.2 unverändert.

Ein historischer Reparatursnapshot vom 29. August bestätigte eine Dateideskriptor-Erschöpfung durch nicht deterministisch geschlossene SQLite-Verbindungen im Channel-Responses-Adapter. Der reparierte Adapter 193f0c8e1bf4 schließt beide SQLite-Stores in allen Pfaden. Channel Manager 59daed654023 schließt außerdem unvollständig geöffnete Verbindungen und Transaktionen und schützt die dauerhafte Retry- beziehungsweise Terminalmarkierung mit begrenzten SQLite-Retries. Nach kontrolliertem Neustart hat die vorhandene Startup-Recovery die betroffene source-geordnete Queue abgearbeitet; es blieben keine Dispatches queued oder running, die finalen Outbound-Ereignisse waren zugestellt und es traten keine neuen Worker-Task- Ausnahmen auf. Die offenen Dateideskriptoren beider Prozesse blieben im niedrigen zweistelligen Bereich. Diese Prüfung bestätigt zugleich, dass HTTP-Health allein keinen Fortschrittsnachweis für die Queue darstellt.

Diese Aggregate enthalten keine Empfänger, Kontaktdaten, Nachrichten oder Sitzungsbeschreibungen. Ein erfolgreicher Prozess-Health belegt nicht automatisch die erfolgreiche Ausführung jedes Dispatches.

Forgejo-Repositories und Branches

Forgejo läuft in Version 15.0.6 über HTTP-Port 3000 und den integrierten SSH-Port 46240. Die Konfiguration ist 0600; die MySQL-Datenbank bindet auf Loopback. Elf eigene Bare-Repositories wurden verifiziert.

Keines der Bare-Repositories besitzt Git-Tag-Refs. Die unauthentifizierte Forgejo-API antwortet für Repositorydaten mit 403; Forgejo-Release-Objekte konnten deshalb nicht verifiziert werden. Aus „keine Git-Tags“ folgt ausdrücklich nicht „keine Forgejo-Releases“.

Warnsignal: drei veraltete Default-HEADs

documentation-content, documentation-wiki und screenshot_service zeigen symbolisch auf ältere Feature-Branches, obwohl die laufenden beziehungsweise veröffentlichten Stände aus main stammen. Ein Clone ohne explizite Branchwahl kann dadurch auf einem veralteten Stand landen.

Releases, aktive Verweise und Rollback

Der frühere Channel-Manager-Releasebestand ist entfernt. Er wird nicht mehr als aktive oder vorgehaltene Generation gezählt; andere releasebasierte Dienste in dieser Tabelle bleiben davon unberührt.

Der MCP-Center-Deploybaum hält Rollbacks für Stage und den internen stage1-/Fallback-Slot. Der Stage-State verweist auf Commit d93685980b72, der Fallback-State auf fd364ccaa525; Letzterer trägt den zusammengesetzten Marker recovered_after_ + interrupted_health_output=true. Die drei MCP-Center-Checkout-Commits sind im aktuellen Git-Verlauf erreichbar. Zwei historische Ananda-Checkout-Commits sind dagegen in keinem lokalen Forgejo-Bare-Repository vorhanden.

Rollback-Grundregel

Laufzeit- und Releaseverzeichnisse werden nie direkt bearbeitet. Vor einem Rollback werden Ziel-Commit, Artefakt-Hash oder Manifest geprüft. Symlinkbasierte Dienste wechseln atomar auf eine vorhandene Generation; Supervisor-gepinnte Dienste benötigen einen reviewten Pfadwechsel und Health-Prüfung. Das bisherige Ziel bleibt bis zum erfolgreichen Route- und Health-Smoke erhalten. Direkte Worktrees ohne unveränderliche Generation gelten als unvollständiger Rollbackweg.

Der Channel Manager verwendet davon getrennt einen kontrollierten Git- Rollback auf einen verifizierten Commit oder Tag im selben festen Root, gefolgt von venv-Rebuild, check-config, Supervisor- und Health-Prüfungen. Seine persistenten privaten Daten werden dabei nicht zurückgesetzt.

Zustandsgrößen, Modi und Rotation

Mehrere operative Logs besitzen Mode 0644, darunter Supervisor-, Forgejo-, Screenshot-, Channel-Manager-, Telegram- und Adapterlogs. Die aktiven MCP-Center-Logs sind dagegen 0600. Zusätzlich sind die alte Catalog-Exchange-Datenbank sowie zwei leere, nicht aktive MCP-OAuth-Datenbankplatzhalter 0644.

Bestätigte Drifts und offene Punkte

Verifizierte Korrelations- und JSONL-Lücke

Eine redigierte Vorfallsprüfung vom 28. August 2026 bestätigte einen Transportwiderspruch: Central begrenzte einen Stage-Upstreamaufruf auf rund zehn Sekunden, während der Profilstart bis zu 45 Sekunden auf erste Workerereignisse wartete. Der Upstream konnte deshalb abbrechen, obwohl Stage den Job bereits angenommen hatte und dieser später erfolgreich terminal wurde. Die damalige äußere Fehlerhülle reduzierte den Vorgang auf generisches JSON-RPC -32603; erfolgreiche Audits waren sichtbar, der fehlgeschlagene Aufruf dagegen nicht vollständig mit Stage-Request, Job und Pollgrenze verknüpfbar.

Die rein strukturelle Prüfung des owner-only Stage-Jobbestands fand vier Eventdateien mit insgesamt sechs ungültigen physischen JSONL-Zeilen. In einem belegten Fall lagen zwei vollständige Ereignisobjekte ohne Zeilentrenner an genau der gemeldeten Pollgrenze. Der damalige Reader übersprang solche Zeilen still; mehrere Append-Pfade prüften Short Writes nicht vollständig. Prompt, Ergebnis, Konto-, Nutzer- und Empfängerdaten wurden für diese Feststellung nicht gelesen oder übernommen.

Der aktuelle LIVE-Stand führt deshalb für Central, Stage-Plugin und Channel Manager einen gemeinsamen Korrelationsvertrag ein: atomare strukturierte Logs, echte asynchrone Jobannahme, retry-sichere Start- und Zustellungsidempotenz sowie sichtbare redigierte JSONL-Korruption. Central ist auf Commit ff1617807767 als Release mcp-central-20260901T100309Z-ff1617807767 integriert; 171 Tests sowie Loopback- und Public-Health sind grün. Stage verwendet stage_mcp_plugins-Commit 282b52b2a471 und stage_mcp_wordpress_php-Commit 5aa3f5f82b87; Channel Manager läuft aus dem festen Git-Projektroot auf Forgejo-main 9327a6e18fc8, Version 0.4.2 und Schema 13. Die früheren releasebasierten Rückwegproben sind ein historischer Snapshot; der aktuelle Channel-Manager-Rückweg erfolgt kontrolliert über Git im selben Root. Die WordPress-Ziele Active und Fallback bleiben strikt read-only und sind kein Deployziel.

Bestätigte Probleme und Betriebsdrifts

• Die öffentliche Responses-Route liefert wegen des Loopback-Binds 502.
• Drei verwaiste QA-Listener laufen aus gelöschten Arbeitsverzeichnissen.
• Der alte Dokumentations-Inventurjob steht auf FATAL.
• Der Codex-Master lädt direkt aus einem dirty Worktree.
• Der frühere geprüfte Master-Kandidat bleibt unveröffentlicht; er war nicht Teil dieses Rollouts und der Central-Upstream bleibt deaktiviert.
• Der frühere Wiki-App-Kandidat 4433c1b wurde nicht aktiviert. Die Wiki-App bleibt auf dem separat geprüften Release 570ba9597fa8; nur der Content wird in diesem Dokumentationsstand aktualisiert.
• Drei Forgejo-Default-HEADs zeigen auf ältere Feature-Branches.
• Der aktive Catalog-Responses-Adapter besitzt drei vorbestehende getrackte Änderungen auf HEAD 4c2af6f8bc37; sein Remote-main wurde in diesem Auftrag nicht verändert.
• Mehrere operative Log- und einzelne State-Dateien sind 0644.

Warnsignale zu Retention und Provenienz

• Ein abgelaufener Master-Job und abgelaufene Relay-JTIs waren noch vorhanden.
• Für Site-Locator-Sessions wurde kein regelmäßiger Cleanup gefunden.
• Drei aktive Artefakt-Releases sind über Tarballs rollbackbar, aber nicht vollständig auf Git-Commits abbildbar.
• Für Screenshot-Retention und Rotation können ungelesene Environment-Overrides gelten.

Folgende Punkte bleiben bewusst UNBEKANNT:

• Forgejo-Release-Objekte hinter der authentifizierten API;
• Credential-Werte und aktive Environment-Overrides;
• authentifizierte End-to-End-Funktion der übrigen geschützten MCP- und Supportabläufe; der Site Locator ist separat belegt;
• vollständige Retentionregeln für Catalog-, Relay- und Jobzustände;
• WordPress-Aktivierungszustände außerhalb des verwalteten Stage-Paars sowie Datenbankzustände auf Active und Fallback.

Evidenz und Wiederholung

Die Inventur stützt sich auf folgende read-only Prüfbilder:

• supervisorctl status, ss -lntp und uberspace web backend list;
• begrenzte öffentliche und Loopback-Health- beziehungsweise Routen-GETs;
• git status, rev-parse, for-each-ref, ls-remote und Archivvergleiche;
• readlink, stat, find, Größen- und SHA-256-Vergleiche;
• sqlite3 -readonly ausschließlich für Schema-, Count-, Status- und Zeitaggregate;
• explizit ausgewählte, nicht geheime Felder aus MCP-, Bridge- und Deployment-Konfigurationen.

Maßgebliche Evidenzpfade sind /home/wpmcp/etc/services.d/, /home/wpmcp/.mcp-central/, die Unterverzeichnisse php-mcp-python-bridge/ und mcp-gateway-php/ unter /home/wpmcp/.config/, /home/wpmcp/.codex-mcp/, /home/wpmcp/.mcp-codex-cli/, das Unterverzeichnis repositories/ unter /home/wpmcp/forgejo/data/ und die jeweiligen Projekt-Releaseroots unter /home/wpmcp/codex-projects/.

Weiterführend: Uberspace-Übersicht, WordPress-Umgebungen, Stage-Übersicht, Betrieb und Support, Channel Manager, Telegram und Support, Wiki-URLs und Dienste und LLM-Sitzungen.