Einfach steuern.
Verlässlich zusammen­arbeiten.

Stand: 5. September 2026. Die Umsetzung beginnt mit den Grundlagen. Die folgenden Ausbaustufen sind keine Behauptung bereits verfügbarer Funktionen.

Bereits erreicht

Diese Arbeitsübersicht ist online. Die zentrale JSON-Konfiguration liegt privat auf wpmcp00 und ist über eine gemeinsame Bibliothek und CLI prüfbar. Auf Linux bestehen 134 Tests für Konfiguration, CLI und den PHP/Python-Abgleich. Die PHP-MCP-Basis besteht ihre Tests für lokale Aufrufe über HTTP und STDIO, getrennte Sitzungen und parallele Prozesse. Ein echter ausgehender STDIO-Aufruf funktioniert ebenfalls.

Der echte HTTPS-Test besteht ebenfalls: Anmeldung am Test-MCP, Werkzeugkatalog, Sitzungsregistrierung und Toolaufruf funktionieren. Dabei wurden ein doppelter Host-Header und eine irreführende Wartezeit nach HTTP-Fehlern gefunden und mit 15 zusätzlichen Prüfungen korrigiert. Der vorgesehene ChatGPT-Zugang und die interaktive Agentensteuerung sind noch nicht freigegeben. Die Codex-Anmeldung ist vorbereitet; der Eigentümer muss sie noch über die offizielle Anmeldung abschließen, bevor der Server-Master starten kann.

Ziel und Arbeitsorte

Auf wpmcp00 entsteht eine wiederverwendbare Plattform, die mehrere Codex- und ChatGPT-Sitzungen verbindet. Der Mensch sieht Aufträge, Fortschritt, Modelle und Fehler und kann eingreifen. Das Arbeitszentrum wird unter https://mcp-lab.christian-igel.tech bereitgestellt; der vorgesehene ChatGPT-Endpunkt ist /mcp. Die Ananda-Testwebsite erhält https://anandayoga-zwickau.christian-igel.tech. Stage und Active bleiben erhalten.

Erst die Bausteine, dann die Fachplugins

1. Arbeitsübersicht, zentrale JSON-Konfiguration und belastbares Protokoll anlegen.
2. PHP-MCP Basic unabhängig von WordPress umsetzen und prüfen. Lokale Tools gehen direkt zum Handler. Nur fremde Tools benötigen einen Gateway-Adapter. STDIO und HTTPS verwenden dieselben Handler.
3. Python-MCP Basic mit demselben Vertrag und gemeinsamen Testfällen anbinden. PHP wird intern direkt als STDIO-Prozess aufgerufen, ohne HTTP-Umweg. Der Prozess wird pro Verbindung wiederverwendet und kontrolliert beendet.
4. Channel Manager auf wpmcp00 mit eigenem Zustand betreiben. Den bestehenden Responses Codex Adapter verwenden und seine nachgewiesenen Fehler im gemeinsamen Repository korrigieren.
5. Erst nach bestandenen Basistests WordPress-Anbindung und Fachplugins schrittweise migrieren.
6. Ananda als echten MCP-Anwendungsfall bauen, mit verschiedenen Rollen und auch einem tatsächlichen Luna-low-Client testen.

Einstellungen, die man versteht

Die zentrale Datei liegt außerhalb der Releases unter ~/mcp-lab/config/platform.json. Unter config/projects/<projekt>.json stehen gezielte Projektabweichungen. Paketvorgaben werden von der zentralen Datei und anschließend vom Projekt überschrieben. Das Arbeitszentrum zeigt für jeden wirksamen Wert seine Herkunft.

Wahlwerte sind Arrays: Bei "timeout_seconds": [30, 60, 120] sind 30 Sekunden aktiv. Umstellen bedeutet den gewünschten Wert nach vorn zu schieben. Die übrigen Werte sind Alternativen, keine Retry- oder Fallback-Reihenfolge. Mehrere gleichzeitig angebundene MCPs werden als Objekt mit benannten Einträgen erfasst. Einheiten stehen im Schlüsselnamen.

Konfigurierbar werden Modelle, Reasoning, Rechercheumfang, Eingabe- und Ausgabebudgets, Antwort- und Job-Timeouts, Workerzahl, Cache-Laufzeiten und Speichergrenzen. Modellgrenzen werden vor Jobstart geprüft. Ein Konfigurationswert kann keine zusätzliche Kapazität beim Modellanbieter erzeugen.

Dateieditor, CLI, Dashboard und MCP verwenden denselben validierenden Änderungspfad. Änderungen sind atomar und revisionsgebunden, damit parallele Sitzungen einander nicht überschreiben. Laufende Jobs behalten ihren Start-Snapshot. Ungültige Änderungen werden angezeigt und ersetzen keinen funktionierenden Stand. Neue Prozesse starten nicht mit ungültiger Konfiguration. Zugangsdaten bleiben separat und werden nicht in Auswahllisten oder Logs veröffentlicht.

Eine Basis in zwei Sprachen

PHP Basic und Python Basic haben einen gemeinsamen Funktionsvertrag, aber idiomatische kleine Implementierungen. Offizielle MCP-SDKs übernehmen das Protokoll, unsere Pakete Konfiguration, Sessions, Beobachtbarkeit und Routing. Versionen werden festgeschrieben. Eine experimentelle SDK-Version wird nicht ungeprüft als stabil erklärt.

Ohne externe MCPs gibt es keinen Gateway-Aufbau, keine Netzwerkprobe und keinen vollständigen Upstream-Katalogscan. Auch bei aktivem Gateway bleibt ein lokaler Toolaufruf lokal. Externe Kataloge werden getrennt und bei Bedarf aktualisiert. Connect, Disconnect und Fehler eines Upstreams dürfen die lokalen Tools nicht lahmlegen.

STDIO auf dem vertrauenswürdigen Server benötigt keine Tokens. Externe HTTPS-Zugriffe benötigen Anmeldung. PHP-only-Hosting ohne SSH, Python oder Prozessstart bleibt über HTTPS vollständig nutzbar. STDIO-Fähigkeiten werden nur angeboten, wenn das Hosting sie tatsächlich erlaubt. WordPress-Rollen gelten unabhängig vom Transport.

Sitzungen und externe MCPs

MCP Basic vergibt kurze lesbare Anwendungs-IDs, beispielsweise ws-garten-7k2m. ChatGPT darf eine eigene ID vorschlagen. Collaboration und Channel Manager referenzieren diese ID, statt nochmals IDs für denselben Chat zu vergeben. Provider-Thread- und Job-IDs bleiben technische Referenzen. Ein sichtbarer Chatname oder Chatlink kann nicht aus einer technischen MCP-Sitzung erfunden werden.

Eine Sitzung kann mehrere externe HTTPS-MCPs hinzufügen und entfernen. Interne Serveragenten können zusätzlich STDIO-MCPs verbinden. Dynamische Verbindungen gehören zur Sitzung; das Entfernen einer Verbindung widerruft nicht fremde Sitzungen. Anmeldungen bei Dropbox oder Maildiensten erfolgen über deren tatsächliche Unterstützung und Berechtigungen.

Nutzungsdaten verbinden Sitzung, Tool, Zeitpunkt, Laufzeit, Fehler und Job. Zuordenbare Aufrufe bleiben 90 Tage; anonyme Aggregate ein Jahr. Prompts, Tokens und vollständige Toolargumente gehören nicht in diese Statistik.

Site Locator

Eine interne Engine erhält Modell, Reasoning, Kontextauswahl und Budgets. Öffentliche Presets setzen nur Konfiguration: Fast mit Spark low, Quick mit Luna medium, Balanced mit Terra medium, Heavy mit Sol high, Ultra mit Astra low. Spark wird nur bei bestätigter Verfügbarkeit verwendet; ein Ersatz wird ausdrücklich ausgewiesen. Zusätzlich gibt es fast-local ohne LLM, llm-only und mixed mit sofortigem lokalem Ergebnis und optionalem Recherchejob.

Die Startbudgets für Quellen/Kontext/Laufzeit sind: Fast 8k/16k/20s, Quick 16k/32k/45s, Balanced 32k/64k/90s, Heavy 64k/96k/180s und Ultra 96k/128k/240s. Das sind konfigurierbare Projektbudgets, keine garantierten Antwortzeiten oder Modellgrenzen. Ein stabiler Snapshot wird einmal aufgebaut und für die Auswertung wiederverwendet.

Kommunikation und Arbeitsteilung

Channel Manager ist der zentrale Nachrichtenkern. Lokale Codex-Sitzungen können über SSH dieselben Nachrichten direkt einstellen; interne Agenten nutzen STDIO-MCP, ChatGPT HTTPS-MCP. Das Dashboard erhält Ereignisse über SSE. Telegram informiert den Eigentümer über prüfbare Releases; dessen Rückmeldungen werden dem passenden Auftrag zugeordnet.

Eingegangen, zugestellt und umgesetzt werden getrennt angezeigt. Der Mensch kann Aufträge ergänzen, priorisieren, pausieren, beenden und mit einem neuen Versuch fortsetzen. Ein angehaltener Agent startet nicht allein wegen einer neuen Nachricht wieder.

Der Master verwendet Astra für Architektur und Prüfung. Sol bearbeitet MCP- und Kommunikationskern, Terra begrenzte WordPress-Aufgaben. Luna low prüft die Benutzbarkeit aus Sicht eines einfachen Clients. Tatsächlich eingesetzte Modelle werden erst nach bestätigtem Lauf als solche angezeigt. Anfangs laufen höchstens Master und zwei Worker; schwere Builds, Scans und Medienkonvertierungen werden einzeln ausgeführt.

Bei etwa 70 Prozent Kontextbelegung wird die Übergabe vorbereitet, bei etwa 80 Prozent ein sicherer Wechsel organisiert. Agent- und Aufgabenidentität bleiben erhalten, der neue Thread erhält eine kurze überprüfbare Übergabe. Ein Server-Master ist ein neuer übergebener Codex-Thread; die lokale Unterhaltung wird nicht technisch auf den Server verschoben.

WordPress und Ananda

Die Website bleibt eine reguläre WordPress-Installation mit dem vorhandenen Child-Theme als Ausgangspunkt. Inhalte, Kurse und Verwaltungsfunktionen gehören in Fachplugins; das Theme gestaltet. Synthetische Seitenobjekte und manipulierte globale Queries werden durch echte WordPress-Seiten, Templates und Hooks ersetzt. MCP-Ausfälle dürfen das normale Backend nicht lahmlegen.

Die Startseite wird ein vertikaler Themenfeed mit horizontalen Galerien. Ein ausgewähltes Bild geht sichtbar in seinen Detailbereich über. Oben stehen Zur Übersicht und Weiter: <Thema>. Schließen stellt Position und Fokus wieder her. Sanftes Einrasten unterstützt den Themenwechsel; lange Details lassen sich frei lesen. Tastatur, Zurück-Navigation, tiefe Links und reduzierte Bewegung werden geprüft.

Sichtbare Bilder erhalten sofort passende responsive Quellen. Varianten entstehen beim Import oder Upload, nicht während eines Seitenaufrufs. Versteckte Medien laden erst bei Bedarf. Videos beginnen mit einem Poster. Die warme Ananda-Farbwelt bleibt erhalten.

Unter Ananda Yoga → Dokumentation stehen Architektur, Datenzuständigkeiten, Updates, Diagnose, Hooks, MCP-Einstieg und ein begründetes Register aller Sonderlösungen. Dieselben versionierten Informationen sind lokal und für eine nächste LLM lesbar. PHP-only-Hosting und die Installation weiterer regulärer Plugins werden getestet; pauschale Kompatibilität mit jedem unbekannten Plugin wird nicht behauptet.

Speicher, Logs und Nachweis

Das Ziel sind höchstens 5 GB Gesamtbelegung; ab 4,5 GB starten keine neuen großen Artefakte. Nicht-Git-Backups und inaktive Rollbacks erhalten 750 MB, Erstellung/Wiederherstellung 250 MB Reserve, temporäre Builds 500 MB und Diagnostik 250 MB. Vor Erstellung wird Platz reserviert. Der letzte geprüfte Rollback bleibt geschützt. Git-Repositories und laufende oder pausierte Sessions sind keine Backup-Abfälle.

Logs werden rotiert statt beim Start gelöscht. Ausgaben und Ereignisse sind begrenzt; Fehler bleiben gezielt abfragbar. Detaildiagnosen bleiben sieben Tage, kompakte Fehler 30 Tage. Das Arbeitsjournal verknüpft Entscheidung, Test, Commit und Release. Wiederholte Reparaturschleifen ohne neue Ursache werden vermieden.

Vor jedem Basisteil-Release laufen Transport- und Vertragstests, gleichzeitige Sessions, fehlerhafte Konfigurationen, Upstream-Ausfälle und Wiederaufnahme nach Abbruch. Kalter Start, warme Aufrufe, Median/p95 und Speicher werden getrennt gemessen. Reale Browserprüfung und Screenshots ergänzen Tests, ersetzen sie aber nicht.

Versionierung und Übergabe

Die übertragbare Plattform, PHP Basic und Python Basic erhalten eigene Forgejo-Repositories. Channel Manager und Responses Codex Adapter werden in ihren bestehenden gemeinsamen Repositories gepflegt. Wiki-Inhalte bleiben im Repository documentation-content. Versionsstände, Konfiguration, Testergebnisse und offene Punkte begleiten jedes Release. Die Projekt-AGENTS.md führt neue lokale Codex-Sitzungen zur aktuellen Arbeit und verhindert einen zweiten Master.