LLM-Sitzungen und Wiki-Kontext

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.