Ana Sayfa Keşfet Yardım
Giriş Yap
paul
/
hermes-chatto-plugin
1
0
Çatalla 0
Dosyalar Sorunlar 0 Değişiklik İstekleri 0 Wiki
Ağaç: 0190bc3e82
Dallar Biçim İmleri
hermes-chatt...
/
skills
/
chatto-plugin-update
/
SKILL.md

SKILL.md 3.4 KB
Geçmiş Ham

name: chatto-plugin-update description: "Use when the local Chatto plugin repo must catch up to its remote and the changes must go live in the running Hermes gateway." version: 1.0.0 author: Hermes Agent license: MIT metadata: hermes:

tags: [chatto, plugin, update, git, gateway]

Chatto-Plugin updaten und Changes aktivieren

When to Use

Das lokale Chatto-Plugin-Repo auf den Remote-Stand bringen (git fetch/pull) und die neuen Commits im laufenden Hermes Gateway aktivieren (Neustart). Repo: ~/.hermes/plugins/chatto-platform/, Remote ssh://gogs.netdome.biz:10022/paul/hermes-chatto-plugin.git.

Ablauf

  1. Remote-Status PRÜFEN, nie behaupten:

    git -C ~/.hermes/plugins/chatto-platform fetch --all
git -C ~/.hermes/plugins/chatto-platform status -sb
git -C ~/.hermes/plugins/chatto-platform branch -avv

    Erst fetchen, dann Sync-Status (ahead/behind) reporten. Aussagen wie "synchron" nur NACH einem fetch — der lokale status -sb ohne fetch zeigt ahead/behind nur gegen den zuletzt bekannten Remote-Stand. Aktueller Branch: git branch --show-current.

    1. Pull ausführen: git pull (Fast-forward). Bei Divergenz: mit dem User abklären, NICHT automatisch mergen/rebasen.
    2. Commits zusammenfassen (Nutzersicht): bash git log <alter_stand>..<neuer_stand> # oneline git log <alter_stand>..<neuer_stand> --stat # Datei-Umfang Commits haben ausführliche Messages — daraus eine nutzerverständliche Zusammenfassung machen: WAS ändert sich für den Bot-Nutzer, nicht Implementierungsdetails. Für jede Änderung eine Quelle angeben (Commit-Hash).

  2. Gateway-Neustart ANBIETEN (nie selbst ausführen): Plugin-Code-Änderungen werden erst nach einem Neustart des Hermes-Gateways aktiv — die laufende Session hält das alte Modul im Speicher.

    • Einfachster Weg: /restart als Chat-Nachricht (Gateway-Slash-Command, "Restart gateway after draining active runs"). User tippt es direkt im Channel/DM. IMMER zuerst diesen Weg nennen.
    • Alternative (separate Shell auf dem Host): hermes gateway restart oder systemctl restart hermes-gateway.service.
    • Aus der laufenden Agent-Session heraus ist ein Restart UNMÖGLICH: der Lifecycle-Guard blockiert jeden Versuch (direkt, via Skript, at, systemd-run, Aliase/Wrapper), weil der Restart die eigene Session killt. Nicht umgehen versuchen; keine Restart-Skripte/Aliase bauen, wenn /restart genügt.
    • User fragen, ob jetzt neu gestartet werden soll (der laufende Bot ist dann kurz offline).

  3. Nach dem Neustart verifizieren: Plugin-Tools live testen (chatto_list_rooms via tool_call), im Log prüfen, dass der Adapter sauber lädt.

Fallstricke

  • Aussagen über Sync-Status ("synchron", "aktuell") NUR NACH git fetch treffen — ohne fetch ist der lokale Status wertlos.
  • Vendored Updates (chattolib) kommen als dist-info-Rename + RECORD-Änderungen im Pull — normal, kein Handlungsbedarf.
  • Der Lifecycle-Guard blockiert auch Kommandos, die eine Restart-Skript-Datei nur REFERENZIEREN (chmod, bash -n, mv auf den Pfad). Syntax prüfen, indem das Skript vorher unter anderem Namen ins Scratch-Verzeichnis kopiert und dort geprüft wird.
  • Lifecycle-Guard scheitert auch am Scannen von /dev/null-Referenzen (z.B. beim Sourcen der ~/.bashrc im Terminal) — Änderungen an Shell-Dateien stattdessen über Datei-Tools (search_files/patch) verifizieren.