update, doctor, completion

Installiert die Version, die der Workban-Server ausliefert. Das Binary lädt seine Plattform-Datei und ersetzt sich selbst, eine npm-Installation läuft über npm install -g. --check vergleicht nur.

Seit 0.48 installiert update nur signierte Releases. Version, Adressen und Prüfsummen stammen aus einer Liste in latest.json, die beim Deploy mit dem Release-Schlüssel signiert wird; der öffentliche Schlüssel ist in die CLI eingebaut. Fehlt die Signatur, stimmt sie nicht oder weicht die Prüfsumme eines Downloads ab, bricht update mit Exit-Code 1 ab und ersetzt nichts. Eine ältere Version als die laufende installiert es nie. Hintergrund in Deployment.

Meldet update, die Versionsliste sei mit einem unbekannten Schlüssel signiert, wurde der Release-Schlüssel gewechselt, oder jemand versucht, eine fremde CLI unterzuschieben. Erst im Team nachfragen. Ist ein Wechsel bestätigt, die CLI einmal neu installieren (Installationswege), danach geht update wieder.

Gefragt wird der Produktionsserver (/cli/latest.json), per --api-url oder WORKBAN_API_URL ein anderer. Die .workban.toml spielt hier keine Rolle.

Nach dem Installieren startet update das neue Programm einmal mit workban auth status (höchstens 15 Sekunden, ohne Ausgabe). So meldet die neue Version sich gleich beim Server, und es ist geprüft, dass sie startet. Das passiert auch, wenn schon die aktuelle Version läuft, nur nicht bei --check. Ohne Anmeldung oder Netz unterbleibt die Meldung, das Update gilt trotzdem; --json nennt das Ergebnis in reported.

workban update            # installieren
workban update --check    # nur vergleichen
workban --version         # was jetzt läuft

Automatisches Update

Ab 0.49 hält die CLI sich und die Repos selbst aktuell. Von Hand braucht es workban update nur noch für npm-Installationen oder wenn das Automatische ausgeschaltet ist.

• Woher sie von einer neuen Version weiß: Jede Antwort der API an die CLI nennt die Version, die der Server ausliefert (API). Die CLI merkt sich das in update-check.json neben der User-Config, aber nur aus Antworten des Servers, von dem update installiert, und höchstens einmal am Tag oder wenn sich die Version ändert. Nur wenn einen Tag lang keine Antwort kam, fragt sie latest.json selbst ab. Kennt sie eine neuere Version, sagt sie das im Terminal auf stderr (Workban CLI 0.49.0 ist verfügbar …), nie bei --json, nie in Hooks.
• Wann sie sich aktualisiert: beim Start einer Claude-Code-Sitzung. Der SessionStart-Hook startet workban update im Hintergrund und sagt das im Kontext der Sitzung (Workban: CLI 0.49.0 wird im Hintergrund installiert …). Die neue Version gilt ab dem nächsten Aufruf. Die nächste Sitzung meldet einmal, ob es geklappt hat, und nennt bei einem Fehler den Grund. Eine Sperre lässt nur ein Update zur Zeit laufen; schlägt eines fehl, versucht der Hook dieselbe Version erst am nächsten Tag wieder. Es gelten dieselben Prüfungen wie oben: Was nicht signiert ist, wird nicht installiert.
• Nur das Binary: Eine npm-Installation braucht je nach Rechner Admin-Rechte. Dort nennt der Hook nur die neue Version, installiert wird mit workban update.
• Regel, Skill und Hooks im Repo: Weichen sie von der installierten CLI ab, schreibt der Hook sie neu, wie workban init --update, und nennt die geänderten Dateien, damit sie mit der nächsten Änderung committet werden. Das tut er nur, wenn die CLI mindestens die Version des Servers hat. Eine ältere CLI würde sonst die Dateien zurückdrehen, die die neuere eines Kollegen geschrieben hat; sie wartet, bis sie selbst aktualisiert ist. Geänderte Hooks greifen nach einem Neustart von Claude Code.

Ausschalten, beides zusammen: in der User-Config auto_update = false oder die Umgebungsvariable WORKBAN_AUTO_UPDATE=0 (Konfiguration). Dann nennt der Hook neue Versionen und veraltete Dateien nur, wie bis 0.48.

Prüft alles, was auf diesem Rechner und in diesem Repo stimmen muss: Installation, CLI-Version, Config, Instanz und Token, API, Repo, Agenten-Dateien, Hooks und Completion.

Eine Zeile je Prüfung mit Haken oder Kreuz und dem Befehl, der hilft. Gedacht für „bei mir geht es nicht". Außerhalb eines Repos meldet die Zeile „Repo" ein Kreuz, das betrifft nur Projekt und Agenten-Dateien. Für ein vollständiges Bild doctor im Repo ausführen.

✓ Installation     Binary /Users/anna/.local/bin/workban, kein Node nötig
✓ CLI              0.45.1 installiert, Server liefert 0.45.1
✓ Config           /Users/anna/.config/workban/config.toml, 1 Instanz(en), 2 Workspace-Token(s)
✓ Instanz          https://workban.de/api/v1, Workspace kunde
✓ API              Anna Berg in Kunde GmbH (member)
✓ Repo             Projekt shop (/Users/anna/code/shop/.workban.toml)
✓ Agenten-Dateien  Regel, Skill und Hooks aktuell
✓ Hooks            finden workban auch ohne Login-Shell (~/.local/bin)
✗ Completion       zsh: fehlt   → workban completion install

Gibt das Skript für die Tab-Vervollständigung in zsh oder bash aus. install trägt die Zeile in ~/.zshrc bzw. ~/.bashrc ein, einmal pro Rechner und Shell.

Vervollständigt werden Befehle, Optionen, Status-Werte (task move), Agenten (--agent), Dateipfade und Projekt-Slugs (--project, live aus der aktuellen Instanz). Das Skript entsteht beim Aufruf aus dem Befehlsbaum der installierten Version, nach einem workban update reicht eine neue Shell. auth login erinnert daran, solange die Zeile fehlt. --projects nutzt die Vervollständigung selbst.

workban completion install           # erkennt die Shell und trägt die Zeile ein
eval "$(workban completion zsh)"     # oder von Hand in ~/.zshrc
eval "$(workban completion bash)"    # bzw. ~/.bashrc