Fix the update skill's bundled-path handling

skills/chatto-plugin-update/SKILL.md

@@ -24,21 +24,30 @@ Dokument kennen kann.
 
 ## Schritt 1: Wo liegt die Instanz, und welche Art ist sie?
 
-Nicht raten — die drei Fälle haben verschiedene Türen, und zwei davon lassen
-sich nicht mit git bedienen:
+Nicht raten — die Fälle haben verschiedene Türen, und nicht jede lässt sich
+mit git bedienen. **Genau eine Tür pro Fall**; nie beide.
+
+Zuerst feststellen, welche Art die Installation ist:
 
 ```bash
+# 1) User-Install unter ~/.hermes/plugins/ (hermes plugins install)
 ls -d ~/.hermes/plugins/chatto-platform \
       ~/.hermes/plugins/platforms/hermes-chatto-plugin 2>/dev/null
-REPO=<der existierende Pfad>
-[ -d "$REPO/.git" ] && echo "hat git" || echo "kein git"
+
+# 2) Gebündeltes Plugin im Hermes-Agent-Checkout (Source: bundled)
+#    Hermes-Agent legt es als Symlink in plugins/platforms/ ab.
+ls -Ld /home/paul/dev2/chatto-stuff/hermes-agent/plugins/platforms/hermes-chatto-plugin 2>/dev/null
+readlink -f /home/paul/dev2/chatto-stuff/hermes-agent/plugins/platforms/hermes-chatto-plugin 2>/dev/null
 ```
 
-| Befund | Art | Tür |
+Den Befund mit der Liste abgleichen:
+
+| Befund | Art | Tür (genau eine) |
 | --- | --- | --- |
 | `~/.hermes/plugins/chatto-platform/` mit `.git` und Provenance-Zeile | per `hermes plugins install` | `hermes plugins update chatto-platform` |
 | `~/.hermes/plugins/chatto-platform/` mit `.git`, ohne Zeile | selbst geklont | einmalig `hermes plugins adopt chatto-platform`, danach `hermes plugins update chatto-platform` |
 | `~/.hermes/plugins/platforms/hermes-chatto-plugin/` ohne `.git` | Dateien kopiert (README Option B) | **kein Pull möglich** — der User muss neu kopieren oder klonen |
+| Symlink in `hermes-agent/plugins/platforms/hermes-chatto-plugin` → Git-Checkout (Source: bundled) | gebündeltes Plugin / Dev-Checkout | `git pull` im Checkout-Ziel (s.u.) — **kein** `hermes plugins update` |
 
 Im dritten Fall gibt es keinen Remote und kein `git log`: `hermes plugins update`
 verweigert hier ("no .git directory"). Das ist keine Störung, sondern der
@@ -46,23 +55,18 @@ Zustand des Verzeichnisses — es zu umgehen hieße, den Zustand zu erfinden. De
 User sagen, dass er die Dateien neu holen muss, und dann bei Schritt 4
 weitergehen.
 
+Im vierten Fall (gebündelt) ist `hermes plugins update chatto-platform`
+**keine Tür**: das Plugin ist bundled, und `hermes plugins update` verweigert
+bundled Plugins ("This command only works on downloaded plugins; bundled ones
+can only be enabled or disabled"). Hier ist `git pull` im Checkout-Ziel die
+einzige Tür. `git pull` und `hermes plugins update` **nicht mischen** — das
+ist genau der Fehler, den dieser Skill vermeiden soll.
+
 ## Ablauf
 
-2. **Hermes-Tür benutzen, nicht git.** `hermes plugins update` ist der Weg, weil
-   es mehr tut als `git pull`:
-   ```bash
-   hermes plugins update chatto-platform
-   ```
-   Es zieht den Stand, verwirft veralteten Bytecode aus `__pycache__`, schreibt
-   die neue Revision in die Install-Metadaten und fragt nach, wenn der neue Stand
-   Capabilities mitbringt, die noch nicht freigegeben sind (fail closed: ohne
-   Antwort bleiben sie nicht freigegeben). Zwei Fälle lehnt es ab und sagt es:
-   ein **gepinnter** Checkout (dann `hermes plugins install <quelle> --force
-   --ref <40-stelliger SHA>`) und ein Verzeichnis **ohne** `.git`. Ein Katalog-
-   Install wird auf die geprüfte SHA zurückgesetzt, nicht gepullt — deshalb hier
-   ausdrücklich kein `git pull`.
-3. **Statusbericht: erst fetchen, nie behaupten.** Für die Zusammenfassung in
-   Schritt 4 wird der alte Stand gebraucht, also **vor** dem Update abgreifen:
+2. **Statusbericht: erst fetchen, nie behaupten — VOR der Tür.** Für die
+   Zusammenfassung in Schritt 4 wird der alte Stand gebraucht, also **vor**
+   dem Update abgreifen:
    ```bash
    git -C "$REPO" fetch --all
    git -C "$REPO" status -sb
@@ -71,16 +75,34 @@ weitergehen.
    Aussagen wie „synchron" nur NACH einem `fetch` — `status -sb` ohne fetch zeigt
    ahead/behind nur gegen den zuletzt bekannten Remote-Stand. Den alten Commit
    aus `branch -avv` ablesen und festhalten, nicht raten.
+3. **Genau eine Tür benutzen.** Je nach Art aus Schritt 1:
+   - User-Install (Fall 1/2): `hermes plugins update chatto-platform` — es
+     zieht den Stand, verwirft veralteten Bytecode aus `__pycache__`, schreibt
+     die neue Revision in die Install-Metadaten und fragt nach, wenn der neue
+     Stand Capabilities mitbringt, die noch nicht freigegeben sind (fail closed:
+     ohne Antwort bleiben sie nicht freigegeben). Zwei Fälle lehnt es ab und
+     sagt es: ein **gepinnter** Checkout (dann `hermes plugins install <quelle>
+     --force --ref <40-stelliger SHA>`) und ein Verzeichnis **ohne** `.git`.
+     Ein Katalog-Install wird auf die geprüfte SHA zurückgesetzt, nicht
+     gepullt — deshalb hier ausdrücklich kein `git pull`.
+   - Gebündelt (Fall 4): im Checkout-Ziel (das `readlink -f`-Ergebnis aus
+     Schritt 1) `git pull` (bzw. `git pull --ff-only`) auf dem aktuellen
+     Branch — für `main` ist das `main`. Damit werden die Änderungen in den
+     Checkout gezogen, den der laufende Hermes-Gateway über den Symlink liest.
+     Vendored Updates (chattolib) kommen als dist-info-Rename + RECORD-
+     Änderungen mit — normal, und über den Neustart hinaus ohne Handlungsbedarf.
+   - Kopiert (Fall 3): keine Tür — User muss neu kopieren oder klonen, dann
+     weiter bei Schritt 4.
 4. **Commits zusammenfassen (Nutzersicht):**
    ```bash
    git -C "$REPO" log <alter_stand>..<neuer_stand>          # oneline
    git -C "$REPO" log <alter_stand>..<neuer_stand> --stat   # Datei-Umfang
    ```
-   `<alter_stand>` aus Schritt 3, `<neuer_stand>` aus Schritt 2 (der Revision, die
-   Hermes gemeldet hat, oder `HEAD` des Checkouts). 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).
+   `<alter_stand>` aus Schritt 2, `<neuer_stand>` aus Schritt 3 (der Revision,
+   die Hermes gemeldet hat, oder `HEAD` des Checkouts). 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).
 5. **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.
@@ -125,4 +147,4 @@ weitergehen.
 - Das Ausführen von `/dev/null` (oder `/dev/zero`, `/dev/fd/N`) lässt der Guard
   bewusst fehlschlagen. Das ist keine Störung, sondern das gewollte Verhalten.
   Eine Umleitung nach `> /dev/null` in einer Shell-Datei ist davon nicht
-  betroffen — die wird maskiert.
+  betroffen — die wird maskiert.