Add compact Athena MCP release workflow

2026-08-25 08:51:46 +02:00
parent ac725416b8
commit 662913f8ab
9 changed files with 311 additions and 74 deletions
@@ -358,6 +358,12 @@ 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
+ü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.
+
 ## Bekannte Probleme des alten Hosts

 - Systempartition vollständig gefüllt
@@ -91,16 +91,16 @@ anfordern oder kopieren.

 Der verbindliche Ablauf für dauerhafte Änderungen lautet:

-1. `athena_operator_prepare` und nach separater Benutzerfreigabe
-   `athena_operator_execute` mit `file_update`; dies schreibt dieselben
-   ausgewählten Dateien driftgeschützt in den kanonischen Working Tree und die
-   ausgerollte Kopie.
-2. Prüfungen über die Operation `run_checks` ausführen.
-3. Nur betroffene Dienste über `compose_deploy` ausrollen.
-4. Ausschließlich die ausdrücklich angegebenen geänderten Pfade mit
-   `git_publish` committen und pushen. Fremde Dirty-Worktree-Dateien bleiben
-   unberührt.
-5. Mit `recovery` einen neuen Recovery-Koffer erzeugen und prüfen.
+1. Kleine Änderungen mit `patch_update` als SHA-geschützten Unified Diff
+   vorbereiten. `file_update` ist neuen oder vollständig ersetzten Dateien
+   vorbehalten.
+2. Für einen normalen MCP-Lifecycle bevorzugt ein einziges `mcp_release`
+   vorbereiten und nach separater Benutzerfreigabe ausführen. Es bündelt
+   Prüfungen, benannten Compose-Deploy, OpenWebUI-Sync, selektiven Git-Publish
+   und Recovery.
+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.

 Das allgemeine Terminal ist weder Ersatz für diesen Ablauf noch ein Weg zu
 Git-Schlüsseln. `/data/mike-ai-operator/repository` muss aus der
@@ -166,5 +166,10 @@ geändert. Die Abweichung wird benannt und zuerst geklärt.
 /var/lib/docker/volumes            Docker-Volumes, darunter OpenWebUI-Daten
 ```

+Kleine Quelländerungen erfolgen über `patch_update` statt als vollständiger
+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.
+
 Secrets unter `/etc/mike-ai` werden ausschließlich verschlüsselt gesichert und
 gehören nie in Git, ein Wissensdokument oder einen Modellkontext.
@@ -103,8 +103,13 @@ Operator verwaltete Working Tree liegt unter
 Tree; `.mike-ai-source-commit` bezeichnet den ausgerollten Stand. Der
 offizielle GitHub-MCP ist strikt read-only und kann Gitea nicht pflegen. Für
 dauerhafte Änderungen ist ausschließlich der strukturierte Athena-Operator-
-Arbeitsweg vorgesehen: `file_update` ändert driftgeschützt den kanonischen
-Working Tree und die ausgerollte Kopie, `run_checks` prüft, `compose_deploy`
+Arbeitsweg vorgesehen: `patch_update` ändert kleine Stellen als SHA-geschützten
+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.
+`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
 einen zweiten Clone in der Sandbox an und fordere oder kopiere keinen