hmgr 0.0.6 → 0.0.12

package/dist/cli/hilfe.js

@@ -22,6 +22,10 @@ hmgr <kommando> [schalter]
   plugin add <name>         Plugin in ein Ziel legen (installieren oder Skills verlinken)
   plugin remove <name>      Plugin aus einem Ziel entfernen
   plugin list               Plugins der Marketplaces aller Quellen
+  bundle add <name>         Bundle als Ganzes in ein Ziel installieren
+  bundle remove <name>      Bundle als Ganzes aus einem Ziel entfernen
+  bundle sync [name]        Installierte Bundles gegen ihre Definition ziehen
+  bundle list               Bundles der bekannten Quellen
   mcp add <name>            MCP-Server aus dem Katalog in ein Ziel einhängen
   mcp remove <name>         MCP-Server aus einem Ziel aushängen
   mcp migrate <name>        MCP-Server aus der geteilten .mcp.json in den privaten Scope übernehmen
@@ -29,10 +33,13 @@ hmgr <kommando> [schalter]
   sync [pfad]               Ziel auf den Stand seines Zeigers bringen
   update                    Alle Checkouts aktualisieren
   status                    Ist-Zustand der Ziele
+  log                       Verlauf der letzten Läufe (Changelog)
   harness list              Harness-Typen mit Stand aktiv/inaktiv und vorhanden
   harness enable <name>     Harness-Typ aktivieren, hmgr richtet ihn künftig ein
   harness disable <name>    Harness-Typ deaktivieren, mit Angebot zum Säubern
+  harness home <name>       Homedirs zeigen, umstellen oder ein zusätzliches eintragen
   harness skills-dir <name> Verwalteten Skill-Ordner zeigen, festlegen oder entfernen
+  --version                 Versionsnummer von hmgr ausgeben
 
 hmgr help <kommando> zeigt Schalter, Beispiele und Zusammenhänge.`;
 const SOURCE = `hmgr source add <url|pfad> [--name <name>]
@@ -123,7 +130,8 @@ Arbeitsverzeichnis mit Zeiger bricht link ohne --local ab, der Link wird nicht g
 
 Schalter:
   --harness <name>    claude-code, hermes oder agents, Standard claude-code
-  --ort <ort>         home, dir:<pfad> oder profil:<name>, Standard home. profil kennt nur hermes
+  --ort <ort>         home, wsl:<distro>, dir:<pfad> oder profil:<name>, Standard home. profil
+                      kennt nur hermes, wsl:<distro> nur claude-code unter Windows (E78)
   --quelle <teil>     Teilstring der Quelle, wenn der Skill-Name in mehreren Quellen vorkommt
   --version <spanne>  Versionseinschränkung nach Composer-Regeln (etwa ^1.2) oder ein Tag- oder
                       Branchname. Nur mit Zeiger, also dir:<pfad> ohne --local (E33)
@@ -141,8 +149,10 @@ Häufige Fälle:
   „liegt bereits ein fremder Eintrag": --ersetzen setzen oder vorher hmgr adopt <name>.
   „gibt es keinen Zeiger": --version braucht ein Arbeitsverzeichnis mit composer.json und kein
   --local. Ohne Zeiger den Link ohne --version legen.
+  „ist deaktiviert, hmgr legt dort keine Links an": erst hmgr harness enable <name>, dann erneut
+  link. Bestehende Links im deaktivierten Harness bleiben liegen (E76).
 
-Siehe auch: hmgr help unlink, hmgr help sync, hmgr help adopt`;
+Siehe auch: hmgr help unlink, hmgr help sync, hmgr help adopt, hmgr help harness`;
 const UNLINK = `hmgr unlink <skill> [schalter]
 
 Entfernt den Link aus dem Ziel und, wenn das Ziel an einen Zeiger gebunden ist, den Skill aus dem
@@ -153,7 +163,8 @@ Arbeitsverzeichnis mit Zeiger bricht unlink ohne --local ab, der Link bleibt lie
 
 Schalter:
   --harness <name>    claude-code, hermes oder agents, Standard claude-code
-  --ort <ort>         home, dir:<pfad> oder profil:<name>, Standard home. profil kennt nur hermes
+  --ort <ort>         home, wsl:<distro>, dir:<pfad> oder profil:<name>, Standard home. profil
+                      kennt nur hermes, wsl:<distro> nur claude-code unter Windows (E78)
   --composer <pfad>   composer.json des Arbeitsverzeichnisses, wenn mehrere in Frage kommen
   --local             nur den Link entfernen, den Eintrag im Zeiger stehen lassen
 
@@ -179,7 +190,8 @@ Probelauf bleibt frei, er schreibt ohnehin nichts.
 
 Schalter:
   --harness <name>    claude-code, hermes oder agents, Standard claude-code
-  --ort <ort>         home, dir:<pfad> oder profil:<name>, Standard home. profil kennt nur hermes
+  --ort <ort>         home, wsl:<distro>, dir:<pfad> oder profil:<name>, Standard home. profil
+                      kennt nur hermes, wsl:<distro> nur claude-code unter Windows (E78)
   --composer <pfad>   composer.json des Arbeitsverzeichnisses, wenn mehrere in Frage kommen
   --local             Übernahme nicht in den Zeiger schreiben
   --probelauf         nur melden, nichts schreiben
@@ -212,7 +224,9 @@ verlinkt oder entfernt.
 
 Schalter (add und remove):
   --harness <name>    claude-code, hermes oder agents, Standard claude-code
-  --ort <ort>         home, dir:<pfad> oder profil:<name>, Standard home. profil kennt nur hermes
+  --ort <ort>         home, dir:<pfad> oder profil:<name>, Standard home. profil kennt nur hermes.
+                      Ein zusätzliches Homedir (wsl:<distro>) kennt die claude-CLI nicht, dort
+                      gibt es keine Plugins (E78)
   --composer <pfad>   composer.json des Arbeitsverzeichnisses, wenn mehrere in Frage kommen
   --local             Plugin nicht in den Zeiger schreiben
   --quelle <teil>     nur bei add: Quelle eingrenzen, wenn der Name in mehreren Marketplaces steht
@@ -230,6 +244,90 @@ Häufige Fälle:
   kann nur die Quelle beheben.
 
 Siehe auch: hmgr help source, hmgr help sync`;
+const BUNDLE = `hmgr bundle add <name> [schalter]
+hmgr bundle remove <name> [schalter]
+hmgr bundle sync [name] [schalter]
+hmgr bundle list
+
+Ein Bundle ist eine benannte Zusammenstellung von Skills über Quellen hinweg: was für ein Vorhaben
+zusammengehört, liegt selten in einem Repo. Anders als ein Plugin (das lebt in einem Marketplace und
+löst Abhängigkeiten nur dort auf) darf ein Bundle Skills aus beliebig vielen Quellen nennen.
+
+Definiert wird es von Hand, als YAML-Datei in einer Quelle, Konvention bundles/<name>.yaml. hmgr
+liest und validiert sie, schreibt sie nie — über die Quelle kommt sie versioniert auf alle
+Maschinen. Es gibt keinen eigenen Katalog und keinen Pflegebefehl: bundle list zeigt, was beim
+Quellen-Scan gefunden wurde.
+
+Format der Datei:
+
+  name          optional, sonst gilt der Dateiname ohne Endung
+  description   Pflicht, kurzer Text
+  skills        Pflicht, nicht leere Liste; je Eintrag source (URL oder Pfad der Quelle)
+                und path (Pfad des Skill-Ordners in dieser Quelle)
+
+Beispiel bundles/wordpress.yaml:
+
+  name: wordpress
+  description: Alles für die WordPress-Arbeit
+  skills:
+    - source: git@gitea.example.com:tim/skills.git
+      path: skills/wp-core
+    - source: https://github.com/taquiri/skills
+      path: skills/tq-mailform
+
+Ein Ref je Mitglied kennt die Definition nicht: der Link folgt dem Ref, mit dem die Quelle
+eingerichtet ist. Angesprochen wird der Skill über seinen Pfad, nicht über seinen Namen — der Name
+steht im Frontmatter und wird erst beim Lesen der Quelle bekannt.
+
+Je Ziel ist das Bundle eine Einheit: add legt alle seine Links, remove nimmt alle wieder weg, sync
+zieht Änderungen an der Definition nach. Nennt die Definition eine Quelle, die hmgr noch nicht
+kennt, legt add sie an und sagt, welche neu sind. Lässt sich auch nur ein Mitglied nicht auflösen
+oder liegt am Ziel ein Namenskonflikt, bricht add ab, bevor irgendetwas verlinkt oder eine Quelle
+angelegt ist — ein halbes Bundle wäre stilles Fehlen von Skills. Wer nur einen Teil braucht,
+verlinkt die erreichbaren Skills einzeln mit hmgr link.
+
+Liegt am Ziel schon derselbe Skill aus derselben Quelle als hmgr-Link, wird er als Mitglied
+übernommen: aus Bestand wird ein Bundle, ohne erst Links von Hand zu entfernen. Alles andere unter
+demselben Namen ist ein Konflikt und wird genannt.
+
+hmgr unlink <skill> auf ein einzelnes Mitglied zerbricht das Bundle in diesem Ziel: die übrigen
+Links bleiben als einzelne Links liegen, der Bundle-Verweis fällt weg. Das ist kein Fehler, hmgr
+sagt es nur.
+
+Den Abgleich macht schon hmgr update für alle installierten Bundles mit, es ist derselbe Vorgang
+und dieselbe Ausgabe (E69): eine geänderte Definition kommt also mit dem gewöhnlichen
+Aktualisieren an, ohne dass man von der Änderung wissen müsste. bundle sync ist der gezielte Weg
+daneben, wenn nur ein Bundle oder nur ein Ziel gemeint ist; ohne Namen und ohne Ziel-Schalter geht
+es denselben Bestand durch wie update. Was sich nicht vollständig nachziehen lässt, bleibt in
+seinem Ziel auf dem alten Stand und wird als fehlgeschlagen gemeldet.
+
+Der Zeiger bleibt außen vor: die Zugehörigkeit der Links führt hmgr in seinem Zustand, nicht in der
+composer.json. --local gibt es deshalb nicht, und die Sperre aus E57 trifft bundle nie.
+
+Schalter (add, remove und sync):
+  --harness <name>    claude-code, hermes oder agents, Standard claude-code
+  --ort <ort>         home, wsl:<distro>, dir:<pfad> oder profil:<name>, Standard home. profil
+                      kennt nur hermes, wsl:<distro> nur claude-code unter Windows (E78)
+  --composer <pfad>   composer.json des Arbeitsverzeichnisses, wenn mehrere in Frage kommen
+  --quelle <teil>     nur bei add: Quelle eingrenzen, wenn den Namen mehrere Quellen führen
+
+Beispiele:
+  hmgr bundle list
+  hmgr bundle add wordpress --ort dir:.
+  hmgr bundle sync
+  hmgr bundle remove wordpress --ort dir:.
+
+Häufige Fälle:
+  „steht in keiner Quelle": hmgr bundle list zeigt die bekannten Namen, sonst erst hmgr source add.
+  „liegt in mehreren Quellen": mit --quelle <teilstring> entscheiden.
+  „ist auf dieser Maschine nicht vollständig herstellbar": die Meldung nennt je Mitglied den Grund,
+  meist eine Quelle ohne Zugriff oder ein Pfad, an dem kein Skill (mehr) liegt.
+  „lässt sich in … nicht anlegen": die Meldung listet alle Namen, die am Ziel schon belegt sind.
+  „kein Bundle … installiert": hmgr status zeigt je Ziel seine Bundles.
+  „ist deaktiviert, hmgr legt dort keine Links an": bundle add braucht einen aktiven Harness, erst
+  hmgr harness enable <name>. bundle sync und bundle remove trifft die Sperre nicht (E76).
+
+Siehe auch: hmgr help link, hmgr help plugin, hmgr help status, hmgr help harness`;
 const MCP = `hmgr mcp add <name> [schalter]
 hmgr mcp remove <name> [schalter]
 hmgr mcp migrate <name> [schalter]
@@ -353,6 +451,18 @@ Plugin-Fähigkeit deren Plugins nach (E14). Die Links zeigen weiter auf dieselbe
 nicht erneuert werden. Ein Checkout mit lokaler Änderung wird übersprungen und gemeldet (E15),
 damit nichts verloren geht. Lokale Quellen haben keinen Checkout und bleiben unberührt.
 
+Unter jeder „aktualisiert"-Zeile steht, welche Skills der neue Stand geändert hat (E70): die Namen
+kommen aus dem Vergleich von altem und neuem Commit, gezählt werden nur Skills, die in diesem
+Checkout auch ausgecheckt sind. Berührt ein Commit nur Dateien daneben (README, CI), bleibt die
+Zeile weg.
+
+Im selben Lauf gleicht update die installierten Bundles gegen ihre Definitionen ab (E69): eine
+Definition, die inzwischen ein Mitglied mehr oder weniger nennt, wird in jedem Ziel nachgezogen, in
+dem das Bundle hängt. Das ist der Weg, auf dem eine Bundle-Änderung aus einer Quelle ankommt — ohne
+ihn müsste man von seinen eigenen Änderungen wissen, um sie zu holen. Was sich nicht vollständig
+nachziehen lässt, bleibt in seinem Ziel auf dem alten Stand und wird als fehlgeschlagen gemeldet,
+ohne den übrigen Lauf aufzuhalten. hmgr bundle sync macht dasselbe für ein einzelnes Bundle.
+
 Danach räumt update verwaiste Ref-Verzeichnisse auf: Checkouts, in die kein Link mehr zeigt, weil
 ein Link inzwischen auf einen anderen Ref umgelegt wurde. Vor dem Löschen fragt hmgr einmal für
 alle Kandidaten. Ohne Bestätigung, also auch ohne Terminal, bleibt alles liegen und wird nur
@@ -361,6 +471,16 @@ gemeldet. Ein verwaister Checkout mit lokaler Änderung wird nie gelöscht (E15)
 So wird eine Änderung an einem Skill überall wirksam: in der Quelle committen und pushen, dann
 hmgr update.
 
+Zum Schluss vergleicht update die eigene Version mit der auf npm veröffentlichten (E77). Ist dort
+eine neuere, nennt eine letzte Zeile sie und den Befehl dazu (npm install -g hmgr@latest);
+installiert wird nichts von selbst. Ohne Netz oder ohne neuere Version bleibt die Zeile weg.
+
+Ergibt der Lauf mindestens ein Ereignis (aktualisierter Checkout, nachgezogenes Bundle,
+aufgeräumter Checkout, ein Fehler), schreibt update denselben Eintrag auch in ~/.hmgr/verlauf.json
+(E80) — dieselbe Datei, in die auch die GUI schreibt. hmgr log zeigt das Changelog. Plugins stehen
+nicht im Verlauf: „claude plugin marketplace update" liefert keine Auskunft, ob sich etwas geändert
+hat, eine Zeile dazu wäre geschönt.
+
 Schalter: keine.
 
 Beispiel:
@@ -373,10 +493,35 @@ Häufige Fälle:
   „liegen lassen … ohne Bestätigung nicht gelöscht": die Frage kam ohne Ja zurück, etwa in einer
   Pipe oder einem Composer-Script. In einem Terminal erneut hmgr update aufrufen.
 
-Siehe auch: hmgr help sync, hmgr help status`;
+Siehe auch: hmgr help sync, hmgr help status, hmgr help log`;
+const LOG = `hmgr log
+
+Zeigt den Verlauf der letzten Läufe aus ~/.hmgr/verlauf.json (E80), neueste zuerst: dieselbe Datei,
+die hmgr update schreibt und die GUI bei jedem automatischen und angestoßenen Lauf schreibt und
+liest. Ein Lauf ohne Ereignis (nichts Neues) steht nicht drin, die Datei ist ein Changelog, keine
+vollständige Historie — sie hält die letzten 20 Einträge.
+
+Je Eintrag steht eine Kopfzeile mit Datum und Uhrzeit, darunter je Ereignis eine Zeile: ein
+aktualisierter Checkout mit Quelle, Ref und Commit-Stand samt geänderten Skills (E70), ein
+nachgezogenes Bundle mit gelegten und entfernten Links, ein aufgeräumter (gelöschter) Checkout, ein
+Fehler zu einer Quelle oder einem Bundle, dazu hmgr-Ereignisse: ein Versionssprung von hmgr selbst
+(GUI oder CLI, erkannt beim Start bzw. bei jedem CLI-Aufruf) oder ein gefundenes Update, das noch
+nicht installiert ist. Plugins stehen nicht im Verlauf (siehe hmgr help update).
+
+Der Verlauf ist je Rechner: mehrere Maschinen führen ihre eigene Datei, es gibt kein Zusammenführen.
+
+Schalter: keine.
+
+Beispiel:
+  hmgr log
+
+Häufige Fälle:
+  „Noch keine Ereignisse": entweder frisch installiert, oder jeder bisherige Lauf war ohne Fund.
+
+Siehe auch: hmgr help update, hmgr help status`;
 const STATUS = `hmgr status
 
-Liest den Ist-Zustand vom Dateisystem: je Ziel eines vorhandenen Harness die Einträge mit Quelle
+Liest den Ist-Zustand vom Dateisystem: je Ziel eines vorhandenen, aktiven Harness die Einträge mit Quelle
 und Ref, davor die Versionseinschränkung, falls der Zeiger eine nennt. Dahinter steht der
 abgeleitete Grund des Links: das Plugin, zu dem er gehört, oder „über Zeiger", von Hand gelegte
 Links bleiben ohne Zusatz. Fremde Einträge und Links ohne bekannte Quelle sind eigens
@@ -394,11 +539,18 @@ Häufige Fälle:
   Zustand steht. Mit hmgr source add <url> die Quelle wieder eintragen.
   „Nicht vorhanden": der Harness hat sein Verzeichnis auf diesem Rechner nicht angelegt, hmgr
   überspringt seine Ziele.
+  Ein Ziel fehlt: Ziele inaktiver Harness-Typen zeigt status nicht, auch wenn dort noch Links
+  liegen. hmgr harness list zeigt den Stand, hmgr harness enable <name> holt die Ziele zurück.
 
 Siehe auch: hmgr help adopt, hmgr help sync`;
 const HARNESS = `hmgr harness list
 hmgr harness enable <name>
 hmgr harness disable <name>
+hmgr harness home <name>
+hmgr harness home <name> set <pfad>
+hmgr harness home <name> reset
+hmgr harness home <name> add wsl:<distro>
+hmgr harness home <name> remove wsl:<distro>
 hmgr harness skills-dir <name> [--profil <name>]
 hmgr harness skills-dir <name> add <pfad> [--profil <name>]
 hmgr harness skills-dir <name> remove [--profil <name>]
@@ -411,9 +563,27 @@ alle bekannten Harness-Typen mit ihrem Stand: aktiv oder inaktiv, dazu vorhanden
 
 disable säubert nicht von selbst: liegen noch eigene Links oder eine harness-eigene Konfiguration wie
 Hermes' external_dirs-Eintrag, fragt hmgr, ob sie entfernt werden sollen. Ohne Terminal, etwa in einem
-Script, gilt Nein und die Konfiguration bleibt liegen. Ein Link mit ausdrücklich genanntem --harness
-(hmgr link, hmgr plugin add) legt weiterhin an jedem vorhandenen Harness an, aktiv oder nicht, das ist
-Sache des Nutzers.
+Script, gilt Nein und die Konfiguration bleibt liegen. In ein Ziel eines inaktiven Harness legt hmgr
+keine Links mehr an (E76): hmgr link und hmgr bundle add brechen ab und nennen hmgr harness enable
+<name> als Weg, auch mit ausdrücklich genanntem --harness. Bestehende Links bleiben liegen, hmgr sync
+und hmgr unlink trifft die Sperre nicht.
+
+home zeigt die Homedirs eines Harness (E78). set stellt das primäre um: hmgr merkt sich nur den neuen
+Pfad und zeigt ab dann ihn, was am alten Ort liegt, bleibt unberührt liegen — wer umziehen will,
+verlinkt am neuen Ort neu, einen Umzugsassistenten gibt es nicht. reset nimmt die Umstellung zurück,
+ebenfalls ohne etwas zu verschieben.
+
+add trägt ein zusätzliches Homedir ein, heute nur eines in einer WSL-Distro: Adresse wsl:<distro>,
+ohne Benutzer-Option, denn wsl.exe startet als Standardbenutzer der Distro — derselbe, der Claude Code
+dort nutzt. Das Home wird einmal ermittelt (wsl -d <distro> /bin/sh -c 'echo $HOME'), angezeigt und
+gespeichert. Jedes Homedir ist danach ein eigenständiges Ziel: es steht als eigene Zeile im status und
+wird mit --ort wsl:<distro> angesprochen. Gespiegelt wird nichts, jedes Ziel wird einzeln verlinkt.
+Links dort legt hmgr über wsl.exe an; das Linkziel bleibt der vorhandene Windows-Checkout, übersetzt
+nach /mnt/c. MCP-Server und Plugins gibt es dort nicht: die claude-CLI dieses Rechners bedient nur das
+primäre Homedir. remove lässt hmgr das Homedir vergessen, die Links dort bleiben liegen.
+
+Zusätzliche Homedirs kennt bisher nur claude-code, und nur unter Windows. Steht eines im Zustand,
+etwa weil er von einem Windows-Rechner kommt, zeigt hmgr sein Ziel auf anderen Plattformen nicht.
 
 skills-dir zeigt, legt fest oder entfernt den Ordner, aus dem Hermes externe Skills liest
 (skills.external_dirs in seiner config.yaml, E13, E56). hmgr verwaltet je Ziel (Home oder ein Profil
@@ -433,14 +603,28 @@ Beispiele:
   hmgr harness list
   hmgr harness enable hermes
   hmgr harness disable hermes
+  hmgr harness home claude-code
+  hmgr harness home claude-code set D:\\Profile\\tim
+  hmgr harness home claude-code add wsl:Ubuntu
+  hmgr link netzwerk --harness claude-code --ort wsl:Ubuntu
+  hmgr harness home claude-code remove wsl:Ubuntu
   hmgr harness skills-dir hermes
   hmgr harness skills-dir hermes add ~/.hermes/external-skills
   hmgr harness skills-dir hermes remove --profil researcher
 
 Häufige Fälle:
   „ist kein bekannter Harness-Typ": hmgr harness list zeigt die bekannten Namen.
+  „ist deaktiviert, hmgr legt dort keine Links an": hmgr harness enable <name>, dann erneut link
+  bzw. bundle add (E76).
   Konfiguration bleibt nach disable liegen, wenn die Rückfrage mit Nein oder ohne Terminal beantwortet
-  wird. Ein erneutes hmgr harness disable <name> bietet das Säubern wieder an.
+  wird. hmgr status zeigt die Ziele des Typs dann nicht mehr (E74), sie erscheinen nach hmgr harness
+  enable <name> wieder. Ein erneutes hmgr harness disable <name> bietet das Säubern wieder an.
+  „ist keine Adresse für ein zusätzliches Homedir": add nimmt wsl:<distro>. Ein abweichender
+  normaler Pfad gehört an set, nicht an add.
+  „kennt keine zusätzlichen Homedirs": add und remove kennen heute nur claude-code.
+  „gibt es nur unter Windows": das WSL-Homedir wird auf dem Windows-Rechner eingetragen, auf dem
+  die Distro läuft.
+  „wsl.exe -d <distro> ließ sich nicht ausführen": wsl -l -q zeigt die installierten Distros.
   „kennt keinen verwalteten Skill-Ordner": skills-dir kennt heute nur hermes.
   „ist schon ein Skill-Ordner verwaltet": erst hmgr harness skills-dir <name> remove, dann add.
   „ist kein Skill-Ordner verwaltet": remove kennt nur einen vorhandenen Eintrag, add legt ihn fest.
@@ -456,10 +640,12 @@ const THEMEN = new Map([
     ['unlink', UNLINK],
     ['adopt', ADOPT],
     ['plugin', PLUGIN],
+    ['bundle', BUNDLE],
     ['mcp', MCP],
     ['sync', SYNC],
     ['update', UPDATE],
     ['status', STATUS],
+    ['log', LOG],
     ['harness', HARNESS],
     ['help', HILFE],
 ]);