LLM-Sitzungen und Wiki-Kontext

Getrennte Dashboard-Auskunft auf wpmcp00

Die Werkstatt-Auskunft auf mcp-lab.christian-igel.tech/dashboard/ verwendet beobachteten Status, Aufgaben und relevante Quellen des eigenen Instanz-Wikis. Sie überträgt standardmäßig höchstens sechs Quellenausschnitte mit insgesamt 18.000 Zeichen. Markdown bleibt dabei Quelltext; aus eigenständigem HTML wird sichtbarer Text ohne Script-, Style- und Template-Inhalt verwendet.

POST /dashboard/api/answers legt einen asynchronen Auskunftsauftrag an; GET /dashboard/api/answers/<id> liefert seinen Status und das Ergebnis. Beide Aufrufe benötigen den Passwortzugang beziehungsweise X-Wiki-Password. Ein stabiler Request-Schlüssel verhindert doppelte Aufträge. Ausführung und tatsächlicher Jobzustand liegen im vorhandenen Responses-Adapter auf Loopback 8177. Knowledge selbst startet weder Modelle noch eine zusätzliche Jobqueue.

Die Auskunft beschreibt den beigefügten Beobachtungsstand und soll keine Arbeiten ausführen. Das aktuelle Dashboard-Passwort und dessen dynamische Erinnerung gehören nicht zum Wiki-Quellenindex oder zum LLM-Kontext. Die vollständige Corpus- und Fortsetzungslogik in den folgenden Abschnitten gilt weiterhin für das bestehende WPMCP-Wiki; sie wird nicht auf die neue Instanz übertragen. Siehe Aufbau des Instanz-Wikis.

Arbeitende Wiki-Master-Rolle

Der feste wiki-master erfüllt eine andere Aufgabe als die reine Dashboard-Auskunft: Er darf begrenzte Wiki-Änderungen ausführen und passende Wiki-Unteraufträge delegieren. Jeder Lauf startet über den bestehenden Responses-Adapter mit einem eingefrorenen Batch vollständiger Channel-Manager-Nachrichten. Normale spätere Anfragen gehören zum nächsten Batch. Ausdrücklich verlangte dringende Hinweise können einen aktiven Lauf zusätzlich erreichen; sie bleiben zugleich dauerhaft im Postfach.

Die Identität ist dauerhaft, die LLM-Laufzeit dagegen bedarfsabhängig. Der Timer arbeitet ohne Modellaufruf, solange keine Anfrage vorliegt. Es läuft höchstens ein Wiki-Batch gleichzeitig und die gemeinsame Grenze von einem Master und zwei Workern bleibt bestehen. Deaktivieren pausiert nur den Timer; ein aktiver Job wird über die bestehende Jobsteuerung behandelt.

Plan, Fortschritt, Ergebnisse und Rückmeldungen werden in Aufgaben, Postfächern und der dauerhaften Historie festgehalten. Die Rolle verwendet das feste Postfach wiki-master, auch wenn ihr ausführender Auftrag einen eigenen sprechenden Namen trägt. Ein ACK stammt ausschließlich vom Agenten nach Lesen, dokumentierter Disposition und Antwort an den Absender. Der ursprüngliche fehlgeschlagene Projekt-Master wird nicht wieder gestartet. Die Kommunikationsmetriken werden pro Batch als messbare Ausgangslage für Verbesserungen gelesen; sie ersetzen keinen fachlichen Erfolgsnachweis. Details stehen im Wiki-Master-Handbuch.

Zwei getrennte Sitzungsbegriffe

Diese Architektur beschreibt Folgeturns des Wiki-Assistenten. Das interne Codex-Session-Inventar katalogisiert dagegen vorhandene Codex-CLI-Threads accountübergreifend aus Metadatenindizes. Es liest keine Chattexte und ist kein Teil des Wiki-LLM-Kontexts.

Wiki-Assistent und Site Locator verwenden beide opake, principalgebundene Folgesitzungen. Der Wiki-Assistent lädt seinen unveränderlichen Corpus beim Start. Der Site Locator übermittelt dagegen in jedem Turn erneut den vollständigen frischen WordPress-Snapshot und setzt nur die LLM-Response über previous_response_id fort.

Das obere Fragefeld des Live-Wikis verwendet denselben geschützten answer-jobs-Ablauf wie das Eingabefeld im Assistenten. Es ist keine Stichwortsuche: Nach der Anmeldung wird die natürliche Frage mit dem aktuell gewählten Modell und Reasoning-Effort an den Wiki-LLM-Dienst übergeben. Die Antwort erscheint mit validierten Quellen im Assistentenbereich.

Der Loopback-Adapter erhält ausschließlich den kanonischen Dispatcher /home/wpmcp/.local/bin/codex-current. Der Supervisor-Renderer bewahrt diesen letzten Symlink absichtlich als Literal und prüft ihn vor dem Start mit --preflight; ein aufgelöstes accountgebundenes Ziel ist in der Produktionskonfiguration unzulässig. Dadurch bestimmt der zentral und bewusst gewählte Registry-Eintrag jeden neu gestarteten Codex-Prozess. Der Dispatcher friert Auswahl, Wrapper und Laufzeit für genau diesen Prozess ein. Einen zufälligen oder stillen Account-Fallback gibt es nicht.

Ein bereits gestarteter Auftrag läuft mit seinem unveränderlichen Prozess-Snapshot weiter. Nach einer geplanten zentralen Auswahländerung werden deshalb zunächst aktive Wiki-Aufträge beendet oder kontrolliert abgebrochen; anschließend beginnt die nächste Frage als neue Wiki-LLM-Sitzung. Eine previous_response_id wird nicht über eine Auswahländerung hinweg fortgesetzt. Accountpfade, Accountidentitäten und Zugangsdaten gelangen weder an den Browser noch in öffentliche Dokumentation oder allgemeine Logs.

Die HTTP-Abfragen eines laufenden Jobs verwenden die gemeinsame SQLite-WAL-Datenbank. Neue Verbindungen übernehmen einen bereits gesetzten WAL-Modus, statt ihn während eines Worker-Turns erneut zu schalten. Dadurch bleibt das Polling fertiger Antworten auch bei paralleler Worker-Aktivität zuverlässig. Der vollständige Datenbank-Migrationsblock läuft nur, wenn die gespeicherte Schemaversion von der Anwendungsversion abweicht, und nicht bei jeder Statusabfrage.

Start einer Sitzung

1. Der Dienst lädt wiki-context/v1 und prüft content_sha256, snapshot_sha256, Quellenindex und Statistik.
2. Jede validierte UTF-8-Textquelle wird genau einmal in den Startprompt eingebettet.
3. Markdown bleibt bytegetreu Markdown; die gerenderte HTML-Fassung wird nicht zusätzlich übertragen.
4. Wiki-Inhalte sind als nicht vertrauenswürdige Daten markiert und können keine System- oder Developer-Anweisungen ersetzen.
5. Die abgeschlossene Adapter-Antwort liefert eine response_id für den nächsten Turn.

Fortsetzung und Ablauf

• Folgefragen senden nur die neue Frage und previous_response_id.
• Modell-, Reasoning-, Corpus- oder zentrale Auswahländerung startet zwingend eine neue Sitzung.
• Eine Sitzung endet nach 24 Stunden Inaktivität und spätestens nach sieben Tagen.
• Turns derselben Sitzung werden serialisiert.
• Mehr als 900.000 geschätzte Starttoken oder 1.000.000 kumulierte Sitzungstoken führen zu einem klaren Fehler; Version 1 kürzt nicht still und besitzt keinen Retrieval-Fallback.

Job-Lebenszyklus und sichere Fehler

Ein Auftrag durchläuft queued, running und anschließend deterministisch completed, failed oder cancelled; cancelling ist ein vorübergehender Zustand. Die Queue-Frist beträgt 300 Sekunden, die Laufzeitfrist 960 Sekunden und die Aufbewahrung eines terminalen Auftrags 24 Stunden. Beim Polling werden verwaiste oder zu alte Aufträge lokal terminalisiert und eine Upstream- Stornierung nur idempotent und best effort versucht. Eine unbekannte Job-ID liefert HTTP 404, eine abgelaufene bekannte Job-ID HTTP 410. Der Browser pollt alle 900 Millisekunden und beendet seinen eigenen Wartepfad spätestens nach 1.020 Sekunden.

Fehler bleiben intern als authentication, account_selection, quota, rate_limit, model, worker, timeout, upstream oder internal unterscheidbar. API und Oberfläche geben nur eine feste redigierte Meldung, das Retry-Merkmal und eine sichere Referenz im Format ref_ plus 16 Hexadezimalstellen aus. Rohmeldungen, Exit-Ausgaben, Accountidentitäten, Prompt- oder Antwortinhalte werden nicht durchgereicht. Nur rate_limit, worker, timeout und upstream gelten als transient; automatische Retries sind nicht Teil des Wiki-Jobvertrags.

Der Modellkatalog im Status- oder Health-Endpunkt belegt nur, dass der Adapter erreichbar ist. Die Freigabe erfordert zusätzlich einen neuen, synthetischen Ende-zu-Ende-Auftrag bis completed mit validierten Quellen.

Modelle

Zulässige Reasoning-Stufen sind none, low, medium, high, xhigh und max. Die Laufzeit schneidet diese feste Allowlist mit dem live gemeldeten Modellkatalog des Adapters.

Site Locator: LLM-Routing und Umfang

Der Site Locator besitzt einen getrennten, am 1. September 2026 auf Stage verifizierten Vertrag. Ohne search_mode wird das LLM zuerst aufgerufen. Eine hochkonfidente deterministische Fundstelle ist nur dann ein Fallback, wenn der LLM-Pfad technisch nicht verfügbar ist. search_mode: llm erzwingt den LLM-Pfad ohne deterministischen Fallback; search_mode: deterministic überspringt das LLM vollständig.

quick bleibt Spark-first. Bei einem technischen Spark-Fehler darf genau ein neuer LLM-Versuch innerhalb derselben Deadline auf Luna wechseln. Erst wenn der LLM-Pfad danach weiterhin nicht verfügbar ist, greift der WordPress-seitige deterministische Fallback. Metadaten nennen dann das tatsächliche Modell und gegebenenfalls model_fallback: quick_spark_to_fast_luna.

reasoning_effort und der unabhängige Ergebnisumfang detail akzeptieren low, medium, high, xhigh und ultra. Fehlt detail, folgt es dem wirksamen Reasoning-Wert. Nicht jedes Modell unterstützt jede Stufe; die reale Adapterfähigkeit bleibt maßgeblich. Das veraltete search_depth bildet 1, 2 und 3 auf low, medium und high ab und darf nicht zusammen mit detail gesendet werden.

Profil, tatsächlich gewähltes Modell, Reasoning und Umfang werden beim ersten erfolgreichen Turn in der Sitzung festgehalten. Fortsetzungen dürfen diese Werte nicht wechseln und lassen nicht ausdrücklich erneut gesetzte Standardparameter weg.

Modellzitate werden serverseitig gegen den Quellenindex geprüft. Unbekannte oder doppelte source_id-Werte gelangen nicht in die Antwort.