Wiki-Architektur

Das Dokumentations-Wiki ist ein eigenständiger Uberspace-Dienst außerhalb von WordPress, Stage, Active und Fallback.

Getrennte Werkstatt-Instanz auf wpmcp00

Unter mcp-lab.christian-igel.tech/dashboard/ entsteht eine eigenständige Koordinationsoberfläche mit Wiki. Ihr Serverroot ist /home/wpmcp00/codex-projects/wiki. Die kanonischen Inhalte liegen in documentation-content/instances/wpmcp00-wiki/; content-source zeigt auf diesen Git-Unterbaum. Der Startbestand erklärt die Bedienung, ohne die umfangreiche Werkstattplanung vorwegzunehmen.

Die Instanz übernimmt Original-CommonMark-Renderer, Metadatenparser und Klassenvertrag als Build-Werkzeuge. Zur Laufzeit liest Python vorbereitete Generationen mit Index, statischem HTML und ZIP. Normale Dokument- und Suchabrufe warten nicht auf den Modellkatalog. Eigenständiges HTML wird separat geöffnet. Die aktive Navigationserweiterung des WPMCP-Wikis wird nicht ausgeführt.

Dashboard, Wiki und API verwenden extern ein gemeinsames Passwort ohne Benutzernamen. Es steht ausschließlich im privaten config.json-Feld password; externe API-Clients verwenden X-Wiki-Password. Änderungen gelten beim nächsten Zugriff. Eine Erinnerung nach Anmeldung wird dynamisch erzeugt und ist kein Git-, Export- oder LLM-Quelleninhalt.

Aufgaben bleiben im Koordinationsboard, Ausführung im vorhandenen Responses-Adapter auf Loopback 8177 und interne Nachrichten im Channel-Manager-Datenmodell. Es wird keine zweite Ausführungsqueue eingeführt. Der übrige Abschnitt dieser Seite beschreibt weiterhin das bestehende Wiki auf wpmcp; dessen Laufzeit und Zugang werden dadurch nicht geändert. Details stehen im Instanzaufbau.

Das Uberspace-Webfrontend benötigt die Dashboard-Bindung 0.0.0.0:8188; die reine Loopback-Bindung auf Port 8188 führte zu HTTP 502. Dies betrifft nur den Dashboard-HTTP-Dienst. Der Responses-Adapter bleibt auf Loopback-Port 8177.

Interne Agenten verwenden ohne Passwort oder Token http://127.0.0.1:8189/dashboard/api/ oder bin/werkstatt. internal_port ist standardmäßig 8189. Dieser getrennte Loopback-Listener teilt dieselbe Application und Dispatch-Sperre mit dem externen Dashboard auf Port 8188. Eine Client-IP oder ein Proxy-Header kann den externen Passwortzugang nicht zum internen Zugang erklären. Matrix und externe Benutzeranmeldung je Channel/MCP bleiben spätere Optionen; sie sind nicht implementiert und keine Voraussetzung für interne Zusammenarbeit.

Die serverseitigen Git-Arbeitsbäume unter wiki/source/ verwenden Forgejo-SSH auf Port 46240 mit einem eigenen, nur für documentation-content und documentation-wiki schreibberechtigten Deploy-Key. Private Schlüsseldatei und geprüfte Hostschlüssel liegen unter wiki/private/; repositorylokales core.sshCommand legt Schlüssel und strikte Hostschlüsselprüfung fest. Schlüsselwerte werden nicht dokumentiert. Die Codex-Accountauswahl und die Laufzeit des ursprünglichen Wikis bleiben davon getrennt.

Fester autonomer Wiki-Master

Die Instanz besitzt die feste Wiki-Rolle und Postfachkennung wiki-master. Der eigene Supervisor-Dienst wiki-master-timer prüft alle 60 Sekunden das vorhandene Channel-Manager-Postfach. Ohne Anfrage startet kein LLM. Ein Arbeitslauf bearbeitet höchstens 20 eingefrorene Anfragen und kann klar begrenzte Wiki-Unteraufträge mit Elternverknüpfung delegieren. Die gemeinsame Kapazität bleibt ein Master und zwei Worker; es läuft höchstens ein Wiki-Batch gleichzeitig.

Standard sind 300 Sekunden Ruhezeit, maximal 1.800 Sekunden Sammelzeit und 900 Sekunden Abkühlzeit ab der tatsächlich beobachteten Beendigung des vorherigen Laufs. Neue reguläre Nachrichten bleiben dem nächsten Batch vorbehalten. Ausdrücklich vom Nutzer verlangte dringende Hinweise können an den aktiven Job weitergegeben werden, während die Anfrage dauerhaft im Postfach bleibt. Deaktivieren pausiert den Timer und beendet keinen aktiven Job.

shared/wiki-master/state.json, history.jsonl und worklog.md protokollieren Zustand und Verlauf. Der Timer bestätigt keine Nachrichten. Ein Wiki-Agent setzt ACK erst nach Lesen, dokumentierter Disposition und Antwort an den Absender. Plan, Fortschritt und Ergebnis gehören in die zugehörigen Dashboard-Aufgaben. Die feste Rolle darf Wiki-Arbeit übernehmen, keine allgemeine Projektimplementierung oder einen Neustart des fehlgeschlagenen ursprünglichen Projekt-Masters.

Ein gemeinsames Register ordnet Aufgaben, Jobs, Nachrichten und Sitzungen sprechende, unveränderliche Namen zu. Die normale Bedienung verwendet diese Namen; technische IDs bleiben intern als Zuordnung erhalten. APIs und CLI akzeptieren die Namen als Aliase. Der Master liest pro Batch die Kommunikationsmetriken; gemessene Alarme können einmal täglich eine zusammengefasste Verbesserungsanfrage auslösen. Die vollständigen Verträge stehen im Wiki-Master-Handbuch.

Das authentifizierte Codex-Session-Inventar nutzt lediglich die bestehende Wiki-Websession als Zugangsschranke. App, Daten, Refreshdienst und Rollback liegen in einem getrennten owner-only Projekt; seine identitätsbehafteten Datensätze werden weder in den Content-Build noch in wiki-context/v1, Volltextindex, HTML-Export oder ZIP aufgenommen.

Datenfluss

1. Inhalte werden im privaten Forgejo-Repository documentation-content versioniert.
2. Der Release-Build prüft Pfade, CommonMark-Attribute und aktive HTML-Dateien.
3. Manifest, Volltextindex und wiki-context/v1 werden atomar erzeugt.
4. Browser, CLI und MCP greifen auf denselben lesenden Query- und LLM-Dienst zu.
5. Das obere Browser-Fragefeld und der Assistent starten denselben geschützten, asynchronen answer-jobs-Ablauf mit der aktuellen Modell- und Reasoning-Auswahl.
6. Der Worker terminalisiert Zeitüberschreitungen und ordnet Adapterfehler einer festen redigierten Fehlerklasse mit sicherer Referenz zu.
7. Eine neue LLM-Sitzung erhält den vollständigen Rohkontext; Fortsetzungen verwenden den bestehenden Response-Thread innerhalb desselben zentralen Auswahl-Snapshots.

Jeder Content-Build erzeugt außerdem eine statische HTML-Fassung und ein deterministisches ZIP aus genau demselben Build-Artefakt.

Das mobile Live-Wiki ordnet Marke und Aktionen in der ersten, das globale Fragefeld in einer eigenen zweiten Headerzeile an. Diese Anordnung gehört zum geprüften Anwendungsvertrag und verhindert, dass Freischaltung, HTML-Link, Theme-Steuerung oder Fragefeld bei schmalen Viewports einander überdecken. Im statischen HTML-/ZIP-Export umbrechen lange Topic-Bezeichnungen innerhalb ihrer Karte und lange Dokumentüberschriften innerhalb des Inhaltsbereichs, statt den mobilen Viewport zu überlaufen.

Markdown wird für den Modellkontext niemals aus der Browserdarstellung zurückgewonnen. Eingebettet wird ausschließlich die unveränderte Markdown-Quelle.

Hauptpfade

/home/wpmcp/codex-projects/documentation/
├── app/releases
├── app/current
├── content/releases
├── content/current
└── shared
    ├── cache
    ├── db
    ├── logs
    └── secrets