Add staged MCP release imports

2026-08-25 10:03:44 +02:00
parent 662913f8ab
commit f4faf27db4
8 changed files with 182 additions and 15 deletions
@@ -358,11 +358,14 @@ sind serverseitig blockiert.
 Ein separater allgemeiner Shell-MCP wird nicht benötigt; die breite Fähigkeit
 ist portabel im Athena Operator auf VPN-Port 8202 enthalten.

-Seit Operator 2.2 werden kleine Änderungen als SHA-geschützte Unified Diffs
+Seit Operator 2.3 werden kleine Änderungen als SHA-geschützte Unified Diffs
 über `patch_update` übertragen. `mcp_release` fasst den üblichen vollständigen
 MCP-Ablauf in einem bestätigten Auftrag zusammen: Patch, Tests, benannter
-Deploy, OpenWebUI-Sync, selektiver Git-Publish und Recovery. Damit muss das
-Modell keine kompletten Compose- oder Installationsdateien rekonstruieren.
+Deploy, OpenWebUI-/Hermes-Sync, selektiver Git-Publish und Recovery. Geprüfte
+Staging-Dateien werden per Pfad und SHA importiert. Damit muss das Modell weder
+lange MCP-Quellen noch komplette Compose- oder Installationsdateien
+rekonstruieren. Die Quellensuche besitzt einen Python-Fallback, falls `rg` im
+Executor-Image fehlt.

 ## Bekannte Probleme des alten Hosts

@@ -98,6 +98,11 @@ Der verbindliche Ablauf für dauerhafte Änderungen lautet:
   vorbereiten und nach separater Benutzerfreigabe ausführen. Es bündelt
   Prüfungen, benannten Compose-Deploy, OpenWebUI-Sync, selektiven Git-Publish
   und Recovery.
+   Bereits geprüfte lange Quelldateien werden mit `imports` plus exakter
+   SHA-256-Prüfsumme aus einem freigegebenen Staging-Verzeichnis übernommen;
+   sie werden nicht als Chattext oder Full-File-Payload nachgebaut. Änderungen
+   an `platform/hermes/config.yaml` verwenden `hermes_sync: true`. Für rein
+   interne MCPs wird WireGuard nicht geändert.
 3. Einzeloperationen `run_checks`, `compose_deploy`, `git_publish` und
   `recovery` nur für Diagnose oder bewusst partielle Wartung verwenden.
   Fremde Dirty-Worktree-Dateien bleiben unberührt.
@@ -171,5 +171,12 @@ Dateiersatz. Ein normaler MCP-Release erfolgt über `mcp_release`, das den
 versionierten Gesamtweg von Patch und Tests bis Deploy, Client-Sync, selektivem
 Git-Publish und Recovery kapselt.

+Seit Operator 2.3 übernimmt `mcp_release.imports` bereits geprüfte UTF-8-Dateien
+aus freigegebenen Staging-Verzeichnissen anhand ihrer SHA-256-Prüfsumme. Das
+Modell muss lange vorbereitete MCP-Quellen weder erneut lesen noch im Chat
+rekonstruieren. `hermes_sync: true` verteilt eine geänderte verwaltete
+Hermes-Konfiguration ohne Containerneustart. Ein interner MCP benötigt keinen
+neuen VPN-Port: Hermes und OpenWebUI erreichen ihn per Docker-DNS im Toolnetz.
+
 Secrets unter `/etc/mike-ai` werden ausschließlich verschlüsselt gesichert und
 gehören nie in Git, ein Wissensdokument oder einen Modellkontext.
@@ -107,8 +107,12 @@ Arbeitsweg vorgesehen: `patch_update` ändert kleine Stellen als SHA-geschützte
 Unified Diff im kanonischen Working Tree und in der ausgerollten Kopie;
 `file_update` ist neuen oder vollständig ersetzten Dateien vorbehalten. Für
 einen vollständigen MCP-Lifecycle bündelt `mcp_release` Patch, Tests, benannten
-Deploy, OpenWebUI-Sync, selektiven Git-Publish und Recovery in einem bestätigten
-Ablauf. Vollständige Compose-Dateien oder Base64-Kopien sind dafür unnötig.
+Deploy, OpenWebUI-/Hermes-Sync, selektiven Git-Publish und Recovery in einem
+bestätigten Ablauf. Bereits geprüfte Staging-Dateien müssen über `imports` mit
+exakter SHA-256-Prüfsumme übernommen werden; ihr Inhalt wird nicht erneut
+erzeugt. Vollständige Compose-Dateien oder Base64-Kopien sind unnötig. Interne
+MCPs verwenden Docker-DNS und benötigen ohne ausdrücklichen Auftrag weder einen
+VPN-Port noch eine WireGuard-Änderung.
 `run_checks` prüft, `compose_deploy`
 rollt nur benannte Dienste aus, `git_publish` veröffentlicht nur ausdrücklich
 ausgewählte Pfade und `recovery` erneuert den Recovery-Koffer. Lege niemals