Betrieb und Veröffentlichung

Wiki-Anwendung und Inhalte besitzen getrennte Releases. Erst ein vollständig validierter Build schaltet den jeweiligen current-Symlink atomar um.

Release-Regeln

• keine Geheimnisse im Git-Repository;
• keine Symlinks oder Pfade außerhalb des Content-Roots;
• CommonMark muss gegen den festen Klassenvertrag bestehen;
• aktive HTML-/JS-Änderungen werden wie Anwendungscode geprüft;
• Index, Snapshot, API, CLI und MCP müssen dieselbe Inhaltsversion melden;
• statische HTML-Version und ZIP müssen aus demselben Content-Hash erzeugt sein;
• der kanonische Codex-Dispatcher muss unmittelbar vor einem risikobehafteten Wechsel --preflight bestehen;
• ein Release-Lint muss App und Content auf direkte account-spezifische Codex-Pfade sowie hartcodierte CODEX_ACCOUNT_PROFILE-E-Mailwerte prüfen, ohne beanstandete Identitäten auszugeben;
• die Supervisor-Konfiguration muss den literalen Dispatcherpfad /home/wpmcp/.local/bin/codex-current enthalten, nie dessen aufgelöstes Accountziel;
• ein Rollback setzt ausschließlich die geprüften current-Symlinks zurück und rendert Supervisor mit dem aktuell geprüften Rollback-Werkzeug.

Der öffentliche Wiki-Inhalt ist lesbar. LLM-Abfragen, CLI und MCP sind authentifiziert.

Freigabe eines LLM-relevanten Stands

1. App und Content jeweils aus einem sauberen Worktree und einem exakten, auf aktuellem main basierenden Commit bauen.
2. Unit-, Job-Lifecycle-, Adapter-/Worker-Integrations- und Redaction-Tests ausführen; Queue-, Lauf- und Ablaufgrenzen einschließen.
3. Content-Build, Navigation-SHA, Links, Suche, statisches HTML und ZIP gemeinsam prüfen.
4. Live-Header und Assistent in relevanter Desktop- und Mobilbreite prüfen.
5. Dispatcher-Preflight ausführen, vorherige App-/Content-Zeiger notieren und über scripts/deploy-release.sh atomar aktivieren.
6. Supervisor ausschließlich über den dokumentierten Install-/Restartpfad aktualisieren und den literalen Dispatcher in der gerenderten Konfiguration verifizieren.
7. Mit einer neuen harmlosen synthetischen Frage mindestens zwei vollständige Jobs bis completed prüfen; jede Antwort muss validierte Wiki-Quellen enthalten.
8. Den Rückweg zu den vorherigen unveränderlichen Releases technisch prüfen und anschließend den freigegebenen Stand erneut aktivieren.

Aktueller Blocker: Release-Lint geprüft, aber App-Commit nicht publizierbar

Der lokale App-Kandidat 4433c1b führt scripts/lint-codex-account-paths.php vor Build und Maintenance über die exakten App- und Content-Checkouts aus; 115 Tests sind grün. Der konfigurierte lokale Bare-Origin wird jedoch vom Forgejo-Hook ohne verwalteten Schlüssel abgelehnt. Deshalb ist dieser Lint noch nicht produktiv und der zugehörige Content-Stand wurde nicht über einen manuellen Publish-Sonderweg aktiviert.

Ein Rollback darf weder Runtime-Tabellen noch Sessions, Jobs, OAuth-Zustand, API-Tokens oder Secrets ersetzen. Beim Rückweg zu einer älteren App wird die Supervisor-Datei bewusst durch das aktuelle sichere Rollback-Werkzeug gerendert; sonst könnte eine historische Renderer-Version erneut einen accountgebundenen Symlink festschreiben. Dasselbe Werkzeug synchronisiert nach dem atomaren App-Zeigerwechsel die verwalteten CSS-/JavaScript-Dateien im Projects-Webroot mit dem Zielrelease und bewahrt dabei den getrennten Session-Inventar-Rewriteblock.

Getrennter interner Session-Dienst

Die Route /documentation/internal/sessions/ wird vor dem Wiki-Catch-all auf einen separaten minimalen Controller umgeschrieben. Dieser Block gehört zum Session-Inventar, nicht zum Wiki-App-Release. Vor einem Wiki-Webroot-Bootstrap ist deshalb zu prüfen, dass der markierte codex-session-inventory-Block unverändert vor documentation-wiki und dem finalen 404-Catch-all erhalten bleibt.

Das private Backup der ursprünglichen .htaccess, der App-Release und der Supervisor-Dienst des Inventars werden unabhängig vom Wiki-Content-Rollback verwaltet. Ein Wiki-Rollback darf identitätsbehaftete Inventardaten weder kopieren noch zurücksetzen.