hmgr 0.0.7 → 0.0.14

package/dist/adapter/wsl.js

@@ -0,0 +1,212 @@
+// Die Bridge in eine WSL-Distro (E78): `wsl.exe -d <distro> <linux-kommando>`. Über `\\wsl$` geht
+// nichts davon — Windows legt dort keine Links an und liest durch Linux-Symlinks nicht hindurch
+// (gemessen, HARNESS-FAKTEN „Links zwischen Windows und WSL").
+import spawn from 'cross-spawn';
+import path from 'node:path';
+import { WslBrueckeFehlgeschlagen } from "../kern/modell.js";
+/**
+ * Standard-Ausführer: `wsl.exe` vom PATH, über cross-spawn wie die claude-CLI (E65/B7). stdin ist
+ * zu, sonst hängt eine Distro, die auf Eingabe wartet; der Timeout fängt alles Übrige. Ein
+ * Fehlschlag wird zum Code, nicht zur Ausnahme.
+ */
+export const wslAusfuehrer = (args) => new Promise((aufloesen) => {
+    const kind = spawn('wsl.exe', args, { stdio: ['ignore', 'pipe', 'pipe'], timeout: 60_000, killSignal: 'SIGKILL' });
+    const teile = [];
+    const fehlerTeile = [];
+    kind.stdout.on('data', (d) => teile.push(d));
+    kind.stderr.on('data', (d) => fehlerTeile.push(d));
+    kind.on('error', (fehler) => aufloesen({ ausgabe: Buffer.from(fehler.message, 'utf8'), code: 1 }));
+    kind.on('close', (code) => aufloesen({ ausgabe: Buffer.concat(code === 0 ? teile : [...teile, ...fehlerTeile]), code: code ?? 1 }));
+});
+/**
+ * Eine wsl.exe-eigene Ausgabe als Text (E78, gemessen): UTF-16LE, mit BOM. Node kennt die Kodierung
+ * als „utf16le"; die BOM bleibt beim Dekodieren als `\uFEFF` stehen und wird hier entfernt. Ein
+ * ungerades Byte am Ende (abgeschnittene Ausgabe) fällt weg statt ein Ersatzzeichen zu ergeben.
+ */
+export function utf16Text(ausgabe) {
+    const gerade = ausgabe.length % 2 === 0 ? ausgabe : ausgabe.subarray(0, ausgabe.length - 1);
+    return gerade.toString('utf16le').replace(/^\uFEFF/, '');
+}
+/**
+ * Die Distronamen aus `wsl -l -q` (E78): eine je Zeile, UTF-16LE. Leerzeilen und Reste des
+ * Zeilenumbruchs fallen weg. Der Standard-Distro hängt in anderen Listenformen ein „(Standard)" an,
+ * `-q` liefert nur die nackten Namen.
+ */
+export function distroListeLesen(ausgabe) {
+    return utf16Text(ausgabe)
+        .split(/\r?\n/)
+        .map((zeile) => zeile.trim())
+        .filter((zeile) => zeile.length > 0);
+}
+/**
+ * Ein Wert für die einfach zitierte Form der Shell: alles bleibt wörtlich, ein enthaltenes
+ * Apostroph wird ausgeklammert. Ohne das zerfiele ein Pfad mit Leerzeichen in mehrere Argumente,
+ * sobald wsl.exe die Kommandozeile wieder zusammensetzt.
+ */
+export function shZitat(text) {
+    return `'${text.replace(/'/g, `'\\''`)}'`;
+}
+/**
+ * Ein POSIX-Pfad in die Windows-Schreibweise (E78): `/mnt/c/work/quelle` wird `C:\work\quelle`.
+ * `wurzel` ist die Automount-Wurzel der Distro, üblich `/mnt`, aber über `[automount] root`
+ * einstellbar — deshalb wird sie einmal per `wslpath` ermittelt statt geraten. Ein Pfad außerhalb
+ * (im Linux-Dateisystem) hat keine Windows-Entsprechung: `undefined`.
+ */
+export function wslNachWindows(pfad, wurzel) {
+    const basis = wurzel.endsWith('/') ? wurzel.slice(0, -1) : wurzel;
+    const treffer = new RegExp(`^${basis.replace(/[.*+?^${}()|[\]\\]/g, '\\$&')}/([a-zA-Z])(/.*)?$`).exec(pfad);
+    if (treffer === null)
+        return undefined;
+    const rest = (treffer[2] ?? '').replace(/\//g, '\\');
+    return `${treffer[1].toUpperCase()}:${rest.length === 0 ? '\\' : rest}`;
+}
+/**
+ * Die Gegenrichtung: `C:\work\quelle` wird `/mnt/c/work/quelle`. Ein Pfad ohne Laufwerksbuchstaben
+ * (UNC, relativ) hat keine Entsprechung unter der Automount-Wurzel: `undefined`.
+ */
+export function windowsNachWsl(pfad, wurzel) {
+    const treffer = /^([a-zA-Z]):[\\/](.*)$/.exec(pfad);
+    if (treffer === null)
+        return undefined;
+    const basis = wurzel.endsWith('/') ? wurzel.slice(0, -1) : wurzel;
+    const rest = treffer[2].replace(/\\/g, '/').replace(/\/+$/, '');
+    return `${basis}/${treffer[1].toLowerCase()}${rest.length === 0 ? '' : `/${rest}`}`;
+}
+/**
+ * Eine WSL-Distro über die Bridge. Jede Dateisystem-Operation läuft als `/bin/sh -c "<skript>"` in
+ * der Distro; Pfade gehen einfach zitiert hinein (`shZitat`), weil wsl.exe die Kommandozeile wieder
+ * zusammensetzt und ein Leerzeichen sonst trennte.
+ */
+export class WslBruecke {
+    distro;
+    ausfuehren;
+    /** Automount-Wurzel, einmal je Lauf ermittelt: ein `wslpath`-Aufruf statt einem je Linkziel. */
+    wurzelVersprechen;
+    constructor(distro, ausfuehren = wslAusfuehrer) {
+        this.distro = distro;
+        this.ausfuehren = ausfuehren;
+    }
+    /** Ein Linux-Kommando in der Distro, Ausgabe als UTF-8. Wirft, wenn die Bridge selbst scheitert. */
+    async sh(skript) {
+        const { ausgabe, code } = await this.ausfuehren(['-d', this.distro, '/bin/sh', '-c', skript]);
+        const text = ausgabe.toString('utf8');
+        if (code !== 0)
+            throw new WslBrueckeFehlgeschlagen(this.distro, text);
+        return text;
+    }
+    /** Dasselbe, aber ein Fehlschlag ist kein Fehler: `undefined`. Für lesende Abfragen. */
+    async shWeich(skript) {
+        const { ausgabe, code } = await this.ausfuehren(['-d', this.distro, '/bin/sh', '-c', skript]);
+        return code === 0 ? ausgabe.toString('utf8') : undefined;
+    }
+    /**
+     * Das Home des Standardbenutzers der Distro (F87). wsl.exe startet als dieser Benutzer — derselbe,
+     * der Claude Code dort interaktiv nutzt; eine Benutzer-Option gibt es deshalb nicht.
+     */
+    async home() {
+        const text = (await this.sh('echo $HOME')).trim();
+        if (text.length === 0)
+            throw new WslBrueckeFehlgeschlagen(this.distro, 'kein $HOME in der Distro');
+        return text;
+    }
+    /**
+     * Die Automount-Wurzel, aus `wslpath -u 'C:\'`. wslpath kommt von WSL selbst und liegt auch in
+     * einer Minimal-Distro (gemessen). Schlägt der Aufruf fehl, gilt der Standard `/mnt`: eine
+     * Übersetzung mit der üblichen Wurzel ist besser als gar keine.
+     */
+    async wurzel() {
+        this.wurzelVersprechen ??= (async () => {
+            const text = await this.shWeich(`wslpath -u ${shZitat('C:\\')}`);
+            const pfad = text?.trim() ?? '';
+            const treffer = /^(.*)\/[a-zA-Z]\/?$/.exec(pfad);
+            return treffer?.[1] !== undefined && treffer[1].length > 0 ? treffer[1] : '/mnt';
+        })();
+        return this.wurzelVersprechen;
+    }
+    /** Einen Pfad der Distro in die Schreibweise des Windows-Rechners. Ohne Entsprechung: unverändert. */
+    async nachHost(pfad) {
+        return wslNachWindows(pfad, await this.wurzel()) ?? pfad;
+    }
+    /** Die Gegenrichtung. Ohne Entsprechung: unverändert — der Link zeigt dann eben ins Leere. */
+    async vomHost(pfad) {
+        return windowsNachWsl(pfad, await this.wurzel()) ?? pfad;
+    }
+}
+/** Die installierten Distros (`wsl -l -q`). Ohne wsl.exe oder ohne Distro: leere Liste. */
+export async function wslDistros(ausfuehren = wslAusfuehrer) {
+    const { ausgabe, code } = await ausfuehren(['-l', '-q']);
+    if (code !== 0)
+        return [];
+    return distroListeLesen(ausgabe);
+}
+/**
+ * Zugriff auf ein Zielverzeichnis in einer WSL-Distro (E78). Jede Operation ist ein Aufruf über die
+ * Bridge; Pfade sind POSIX-Pfade der Distro, Linkziele übersetzt der Zugriff selbst nach `/mnt/c`
+ * und zurück. Ein Symlink im WSL-Home darf auf `/mnt/c/…` zeigen — die Distro liest selbst
+ * hindurch, also bleiben die vorhandenen Windows-Checkouts die Linkziele (gemessen).
+ */
+export class WslZugriff {
+    trenner = '/';
+    bruecke;
+    constructor(bruecke) {
+        this.bruecke = bruecke;
+    }
+    verbinden(verzeichnis, name) {
+        return path.posix.join(verzeichnis, name);
+    }
+    /**
+     * `ls -1A` statt `find -printf`: letzteres ist eine GNU-Erweiterung und fehlt in einer
+     * Busybox-Distro. Ein Name mit Zeilenumbruch zerfiele dabei — bei Skill-Ordnern kommt das nicht
+     * vor, und der Preis wäre ein Sonderformat für einen Fall, den es nicht gibt.
+     */
+    async namen(verzeichnis) {
+        const text = await this.weich(`ls -1A ${shZitat(verzeichnis)} 2>/dev/null`);
+        if (text === undefined)
+            return [];
+        return text
+            .split('\n')
+            .map((zeile) => zeile.replace(/\r$/, ''))
+            .filter((zeile) => zeile.length > 0);
+    }
+    /**
+     * Drei Ja/Nein-Fragen in einem Aufruf: gibt es den Eintrag (auch als toten Link), ist er ein Link,
+     * zeigt er auf ein Verzeichnis. `-d` folgt dem Link, `-L` nicht — genau die Aufteilung, die der
+     * lokale Zugriff mit lstat und stat trifft.
+     */
+    async info(pfad) {
+        const p = shZitat(pfad);
+        const text = await this.weich(`if [ -e ${p} ] || [ -L ${p} ]; then printf e; fi; if [ -L ${p} ]; then printf l; fi; if [ -d ${p} ]; then printf d; fi`);
+        if (text === undefined || !text.includes('e'))
+            return undefined;
+        return { istLink: text.includes('l'), istVerzeichnis: text.includes('d') };
+    }
+    async linkZiel(pfad) {
+        const text = await this.weich(`readlink ${shZitat(pfad)}`);
+        if (text === undefined)
+            return undefined;
+        const ziel = text.trim();
+        if (ziel.length === 0)
+            return undefined;
+        // Ein relatives Linkziel gibt es bei hmgr-Links nicht, aber ein von Hand gelegter Link könnte
+        // eines haben: erst gegen das Verzeichnis auflösen, dann übersetzen.
+        const absolut = ziel.startsWith('/') ? ziel : path.posix.resolve(path.posix.dirname(pfad), ziel);
+        return await this.bruecke.nachHost(absolut);
+    }
+    async verzeichnisAnlegen(pfad) {
+        await this.bruecke.sh(`mkdir -p ${shZitat(pfad)}`);
+    }
+    async linkAnlegen(pfad, hostZiel) {
+        const ziel = await this.bruecke.vomHost(hostZiel);
+        await this.bruecke.sh(`ln -sfn ${shZitat(ziel)} ${shZitat(pfad)}`);
+    }
+    async linkEntfernen(pfad) {
+        await this.bruecke.sh(`rm -f ${shZitat(pfad)}`);
+    }
+    async loeschen(pfad) {
+        await this.bruecke.sh(`rm -rf ${shZitat(pfad)}`);
+    }
+    /** Lesende Abfragen brechen nicht ab, wenn die Distro schweigt: sie ergeben dann „nichts da". */
+    async weich(skript) {
+        return await this.bruecke.sh(skript).catch(() => undefined);
+    }
+}

package/dist/adapter/zustand-json.js

@@ -1,8 +1,29 @@
 // Lokaler Zustand als eine JSON-Datei, Standard ~/.hmgr/state.json (E29).
+import { readFileSync } from 'node:fs';
 import { mkdir, readFile, writeFile } from 'node:fs/promises';
 import path from 'node:path';
 import { ZUSTAND_FASSUNG, leererZustand, } from "../ports/zustand.js";
 import { ohneBom } from "./datei-text.js";
+/** Der gelesene Text als Zustand. Fehlende Felder bekommen den Wert, der dem Bestand entspricht. */
+function deuten(roh) {
+    const daten = JSON.parse(ohneBom(roh));
+    return {
+        // Fehlt das Feld (state.json vor E69), ist es die erste Fassung: alles ohne Bundles.
+        // Geschrieben wird danach in der aktuellen Fassung, ein Rückweg ist nicht vorgesehen.
+        fassung: typeof daten.fassung === 'number' ? daten.fassung : 1,
+        quellen: (daten.quellen ?? []),
+        arbeitsverzeichnisse: (daten.arbeitsverzeichnisse ?? []),
+        bindungen: (daten.bindungen ?? []),
+        // Fehlt das Feld (state.json vor E38), gilt der bisherige Ist-Zustand: nur claude-code aktiv.
+        aktiveHarnesses: (daten.aktiveHarnesses ?? ['claude-code']),
+        // Fehlt das Feld (state.json vor E43), gilt: nichts ignoriert.
+        ignorierteEintraege: (daten.ignorierteEintraege ?? []),
+        // Fehlt das Feld (state.json vor E69), gilt: kein Bundle installiert.
+        bundleInstallationen: (daten.bundleInstallationen ?? []),
+        // Fehlt das Feld (state.json vor E78), gilt: jeder Harness hat nur sein Standard-Homedir.
+        harnessHeime: (daten.harnessHeime ?? []),
+    };
+}
 export class ZustandJson {
     pfad;
     constructor(pfad) {
@@ -12,21 +33,21 @@ export class ZustandJson {
         const roh = await readFile(this.pfad, 'utf8').catch(() => undefined);
         if (roh === undefined)
             return leererZustand();
-        const daten = JSON.parse(ohneBom(roh));
-        return {
-            // Fehlt das Feld (state.json vor E69), ist es die erste Fassung: alles ohne Bundles.
-            // Geschrieben wird danach in der aktuellen Fassung, ein Rückweg ist nicht vorgesehen.
-            fassung: typeof daten.fassung === 'number' ? daten.fassung : 1,
-            quellen: (daten.quellen ?? []),
-            arbeitsverzeichnisse: (daten.arbeitsverzeichnisse ?? []),
-            bindungen: (daten.bindungen ?? []),
-            // Fehlt das Feld (state.json vor E38), gilt der bisherige Ist-Zustand: nur claude-code aktiv.
-            aktiveHarnesses: (daten.aktiveHarnesses ?? ['claude-code']),
-            // Fehlt das Feld (state.json vor E43), gilt: nichts ignoriert.
-            ignorierteEintraege: (daten.ignorierteEintraege ?? []),
-            // Fehlt das Feld (state.json vor E69), gilt: kein Bundle installiert.
-            bundleInstallationen: (daten.bundleInstallationen ?? []),
-        };
+        return deuten(roh);
+    }
+    /**
+     * Derselbe Zustand, synchron gelesen (E78). Nötig für die Auflösung der Homedirs: sie hängt an
+     * `HarnessTyp.zielVerzeichnis`, und das ist synchron. Ein kaputter oder fehlender Zustand ergibt
+     * hier den leeren — die Homedir-Auflösung darf keine Ansicht abbrechen, sie fällt dann auf das
+     * Home des Nutzers zurück. Nicht Teil von `ZustandPort`: dort bleibt alles asynchron.
+     */
+    lesenSync() {
+        try {
+            return deuten(readFileSync(this.pfad, 'utf8'));
+        }
+        catch {
+            return leererZustand();
+        }
     }
     async schreiben(zustand) {
         await mkdir(path.dirname(this.pfad), { recursive: true });

package/dist/cli/hilfe.js

@@ -33,9 +33,11 @@ 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
 
@@ -128,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)
@@ -146,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
@@ -158,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
 
@@ -184,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
@@ -217,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
@@ -297,7 +306,8 @@ composer.json. --local gibt es deshalb nicht, und die Sperre aus E57 trifft bund
 
 Schalter (add, remove und sync):
   --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
   --quelle <teil>     nur bei add: Quelle eingrenzen, wenn den Namen mehrere Quellen führen
 
@@ -314,8 +324,10 @@ Häufige Fälle:
   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`;
+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]
@@ -459,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:
@@ -471,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
@@ -492,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>]
@@ -509,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
@@ -531,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.
@@ -559,6 +645,7 @@ const THEMEN = new Map([
     ['sync', SYNC],
     ['update', UPDATE],
     ['status', STATUS],
+    ['log', LOG],
     ['harness', HARNESS],
     ['help', HILFE],
 ]);