Verwaltung und Aktualisierung

Herdr-Installationen haben kein collie im PATH; verwenden Sie Herdr-Aktions-IDs (Herdr-Aktionen). Eigenständige Installationen legen die Binärdatei in ~/.local/share/collie/current/bin/collie oder <checkout>/bin/collie ab:

# the install script's layout
cd ~/.local/share/collie/current && bin/collie version
# a source build or a linked clone
cd ~/my/collie-checkout && bin/collie version

Führen Sie bin/collie link aus, um die Binärdatei nach ~/.local/bin zu verknüpfen (collie zu Ihrem PATH hinzufügen).

Konfiguration und Zustand befinden sich außerhalb des Checkouts und bleiben über Aktualisierungen hinweg erhalten (bridge/solo-baseline.test.ts). .env und der tailscale serve-Datensatz liegen im Konfigurationsverzeichnis, ~/.config/collie bei einer Binärinstallation oder im Plugin-Konfigurationsverzeichnis von Herdr bei einer Herdr-Installation; gekoppelte Geräte und stt.json befinden sich im Zustandsverzeichnis, ~/.local/state/collie, sofern es nicht durch COLLIE_STATE_DIR verschoben wird.

Eine paketierte Installation

Wurde Collie über Ihren Paketmanager installiert, übernimmt dieser auch die Aktualisierungen; alles nach diesem Abschnitt trifft nicht zu:

sudo pacman -Syu collie-bin    # or `nix profile upgrade collie`, or `brew upgrade collie`

Collie erkennt diese Installation an Mustern auf dem Datenträger: kein .git, kein versions/-Layout, das Manifest aus dem Release-Payload und ein Root-Verzeichnis, das schreibgeschützt ist, außerhalb Ihres Home-Verzeichnisses liegt oder root gehört. Jedes der letzten drei Kriterien reicht aus. Collie verweigert dann die direkte Aktualisierung und nennt den Befehl, sofern der zuständige Paketmanager erkannt wird:

error: /opt/collie is a packaged install — updates come from your package manager.
       `collie update` will not replace its files.
       Take the new version with: sudo pacman -Syu collie-bin

Verweist das Präfix auf keinen Collie bekannten Paketmanager, gibt das Programm die ersten beiden Zeilen aus und stoppt, anstatt einen nicht ausführbaren Befehl zu erraten.

collie doctor meldet dieselbe Installation als fehlerfrei, und die Update-Karte des Telefons zeigt weiterhin an, dass eine neuere Version existiert – mit dem Paketbefehl anstelle der Update-Schaltfläche.

Hinweis. Dies ist keine Einschränkung, die Sie umgehen sollten. Der Ordner gehört Ihrer Paketverwaltung, und das Ersetzen von Dateien an ihr vorbei würde dazu führen, dass ihre Datenbank falsche Angaben über den Installationsbestand enthält. sudo collie update verweigert dies auf dieselbe Weise.

Um eine neue Version zu übernehmen, führen Sie Ihre Paketverwaltung aus und starten Sie anschließend den Dienst neu:

paru -Syu collie-bin                              # Arch, or your AUR helper of choice
nix profile upgrade collie                        # Nix
mise upgrade --bump github:AltanS/collie          # mise
collie restart

Eine mise-Installation tanzt aus der Reihe: Collie stuft sie nicht als paketiert ein, da sich der Verzeichnisbaum ohne .git und ohne versions/-Layout in Ihrem Benutzerverzeichnis befindet. Daher lehnt collie update mit cannot tell how this Collie was installed ab und nennt keinen Manager. mise verwaltet sie weiterhin. Siehe Installation.

Der Neustart ist der Teil, den Collie nicht für Sie erledigen kann, und er ist nicht optional. Ihre Paketverwaltung tauscht die Dateien unter der laufenden Bridge aus, sodass dieser Prozess weiterhin den alten Code ausführt, während er bereits die neue Version meldet. Collie erkennt diese Diskrepanz und meldet sie: collie doctor löst restart-pending aus, und das Telefon zeigt ein Banner "Bridge-Neustart erforderlich" mit dem Text "Collie wurde auf der Festplatte ersetzt. Starten Sie es neu." an. Beide verschwinden in dem Moment, in dem collie restart ausgeführt wurde.

In einem Crew übernimmt ein paketiertes Mitglied niemals ein Update vom Telefon. Die Crew listet es als "wartet auf die Paketverwaltung" auf und wertet den Durchlauf ohne es als abgeschlossen, sodass die beiden obigen Befehle es auf den aktuellen Stand bringen.

Ein paketiertes lead lehnt nur seine eigene Verschiebung ab. Das Smartphone gleicht weiterhin jedes Mitglied an die Version an, die die Lead-Instanz ausführt, und eine einzige Bestätigung deckt sie ab. Nachdem die beiden obigen Befehle die Lead-Instanz verschoben haben, gleicht sich nichts von selbst an: Tippen Sie noch einmal auf die Updates-Seite, und die Mitglieder folgen auf die neue Version der Lead-Instanz.

Aktualisieren über das Smartphone oder das Terminal

Es gibt zwei Update-Pfade, und beide führen auf jedem Host dieselben Schritte aus: das neue Release neben dem aktiven bereitstellen, den Symlink umschalten, neu starten und prüfen, ob der Dienst antwortet. Auf einem Crew-Lead decken beide Pfade die gesamte Crew ab. Das Telefon ist der kurze Pfad. Das Terminal ist der Ausweichpfad für eine Maschine, die das Telefon nicht aktualisieren kann.

Über das Smartphone

Öffnen Sie Einstellungen und wählen Sie Aktualisierungen. Die Karte zeigt die laufende Version, die neueste Version und die in der Aktualisierung enthaltenen Zwischenversionen an. Wenn sich der Host auf der neuesten Version befindet, meldet die Karte dies und bietet nichts an.

Darunter befindet sich der Preflight-Check, eine Zeile pro Prüfung: doctor, disk, bun, tree, upstream und service. Auf einem Lead wird auch jedes Crew-Mitglied geprüft.

• —
  Grün ist in Ordnung.
• —
  Gelb ist wissenswert und blockiert niemals: Versionsabweichungen innerhalb einer Crew, eine ungewöhnliche Installationsart, ein neues Major-Release, das verfügbar ist, aber nicht übernommen wird. Nicht verfolgte temporäre Dateien in einem Checkout bleiben grün.
• —
  Rot blockiert das Update. Die Zeile nennt den Grund, wie etwa ein rotes collie doctor, weniger als 1 GB freier Speicherplatz für den bereitgestellten Build, fehlendes bun auf dem Host oder ein nicht erreichbares Upstream-Repository. Wenn ein einzelner Befehl das Problem behebt, gibt die Karte diesen Befehl als Fix: <command> aus.

Das Antippen von Auf <version> aktualisieren erfordert eine einmalige Bestätigung, und der Bestätigungstext gilt wörtlich: Ihre Terminalsitzung bleibt aktiv, und die Smartphone-Ansicht wird für bis zu 30 Sekunden getrennt. Der Neustart beendet die Bridge, nicht Ihren Multiplexer, sodass die Agenten weiterlaufen und das Smartphone mit der neuen Version wieder verbunden wird. Ein Major-Upgrade erfolgt nie über ein Routine-Update: Der Wechsel erfordert eine eigene Bestätigung, weist die Version als neues Major-Release aus und fordert Sie auf, zuerst die Versionshinweise zu lesen.

Während des Vorgangs überlagert ein Sheet den Bildschirm. Siehe Anzeige auf dem Telefon während einer Aktualisierung unten. Die Karte auf der Seite „Aktualisierungen“ zeigt dieselben Zustände detaillierter:

Die ersten vier Zustände zeigen Fortschritt an; die Karte weist darauf hin und bittet darum, den Bildschirm geöffnet zu lassen. rolled-back nennt die aktuell verbleibende Version, zeigt das Ende des Dienstprotokolls und bietet Wiederholen an. stuck gibt den einzelnen Befehl zur Ausführung im Terminal aus. interrupted bietet zusätzlich Wiederholen an.

Bei der nächsten Zusammenfassung erinnern blendet den Hinweis der Karte aus. Dies ist keine Stummschaltung: Die nächste Benachrichtigung wartet sowohl auf eine neuere Version als auch auf ein neues Zeitfenster.

Benachrichtigungshäufigkeit. Aktualisierungsbenachrichtigungen erfolgen als Übersicht, maximal einmal pro Tag und nie vor 09:00 Uhr lokaler Hostzeit. Ein Delta, das ausschließlich Patch-Releases enthält, wartet stattdessen auf ein wöchentliches Zeitfenster, sodass eine Patch-Reihe als eine Benachrichtigung statt als vier ankommt; ein Minor- oder Major-Release behält den täglichen Rhythmus bei und nimmt die wartenden Patches mit. Zurückgehaltene Releases werden zusammengefasst, nie verworfen. Ein Patch kann ebenfalls den täglichen Rhythmus anfordern: Eine Fehlerbehebung, die Sie noch heute einspielen müssen, wird bei der Erstellung als dringend markiert, und die Aktualisierungskarte zeigt dann eine Dringend-Kennzeichnung mit dem einen Satz, der den Grund nennt. Sie werden direkt bei der Veröffentlichung oder um 09:00 Uhr danach benachrichtigt. Ein einziges dringendes Release stellt die gesamte wartende Reihe auf den täglichen Rhythmus um, und die Version bleibt dennoch ein gewöhnlicher Patch. Eine Installation, die vor dieser Funktion eingerichtet wurde, behält für einen dringenden Patch das wöchentliche Zeitfenster bei, bis sie einmal aktualisiert wurde. Die Karte zeigt unabhängig vom Zeitfenster immer den aktuellen Status an. Die updates-Benachrichtigungseinstellung unter Einstellungen → Benachrichtigungen (Web Push) ist der zentrale Ausschalter.

Auf einem Crew-Lead zeigt die Schaltfläche Crew auf <version> aktualisieren, und eine einzige Bestätigung gilt für jede Maschine. Der Lead aktualisiert sich zuerst unter seinem eigenen Health-Gate. Jeder Peer bringt sich anschließend nacheinander auf dasselbe Release, unter Verwendung seines eigenen Preflight-Checks, seines eigenen Health-Gates und seines eigenen Rollbacks. Es gibt keine Schaltfläche pro Peer und keine zweite Bestätigungsabfrage. Details, die beiden Wiederherstellungspfade und den einzigen Fall, den das Telefon nicht beheben kann, finden Sie unter Den Rest der Crew aktualisieren.

Ein Banner am oberen Rand jedes Bildschirms zeigt statische Zustände statt laufender Vorgänge: die angebotene Version, einen Peer, der nicht aktualisiert werden konnte, sowie New version — tap to update, wenn die App auf Ihrem Gerät hinter der Bridge zurückliegt. Eine laufende Aktualisierung gehört zum Sheet, nicht zum Banner.

Anzeige auf dem Telefon während einer Aktualisierung

Auf dem Gerät, das die Bestätigung angetippt hat, überlagert ein Sheet den Bildschirm; jedes andere Gerät erhält ein Badge.

Das Sheet enthält eine Zeile pro Rechner, die Führung zuerst, jeweils mit der Version und dem aktuellen Zustand. Darunter befindet sich die Zeile dieses Geräts selbst, die sich auf die App auf Ihrem Gerät bezieht und nicht auf einen Rechner: Sobald die Bridge die neue Version bereitstellt, lädt das Telefon diese App im Hintergrund herunter, und die Zeile zählt die eintreffenden Dateien. Das Sheet weist zudem einmal in kleiner Schrift darauf hin, dass die Aktualisierung auf den Rechnern läuft und das Schließen der App sie nicht abbricht.

Das Gerät, das den Vorgang gestartet hat, kann die App hinter dem Sheet nicht bedienen. Sonst ist nichts blockiert: Ein zweites Telefon oder ein Tablet zeigt eine Zeile, die angetippt werden kann, um sie zu öffnen, und schließt sich wieder.

Wenn jeder Rechner fertig ist und auf dem Telefon die neue App läuft, schließt sich das Sheet von selbst und eine kurze Meldung nennt die Version. Bei einer Crew lautet sie Crew updated to <version>; bei einem einzelnen Rechner wird stattdessen dieser Rechner genannt.

Ein Durchlauf, der nur die Mitglieder aktualisiert, wie etwa Crew-Update wiederholen, übernimmt den Bildschirm auf dieselbe Weise. In der Zeile des Leads steht already up to date, da der Lead nicht Teil dieses Durchlaufs ist und nicht neu startet. Am Ende steht Members updated to <version>, und ein Mitglied, das nicht aktualisiert werden konnte, lässt das Blatt auf dem Telefon geöffnet, das den Durchlauf gestartet hat, zusammen mit der Begründung.

Drei Zustände können stocken, und für jeden gibt es einen Ausweg. Keiner davon bricht die Aktualisierung ab, und keiner lädt die App neu.

Hinweis. „Wird noch heruntergeladen, nutzen Sie die App weiter“ bezieht sich auf die App auf Ihrem Telefon und nie auf den Rechner. Die Rechner sind fertig; lediglich die neue App ist noch nicht eingetroffen. Die geöffnete App funktioniert weiterhin und stellt sich selbstständig um, sobald der Download abgeschlossen ist.

Über das Terminal

collie update --check            # read-only preflight, --json for a script
collie update --check --local    # the same, this instance only, no crew members
collie update                    # stage, flip, restart, verify
collie update --status           # what the updater did, or is doing, --json for a script
collie update --rollback         # put the previous version back
collie update --major            # cross one major, see below

collie update --help gibt die Verwendung aus und startet nichts. Jeder Befehl collie beantwortet -h und --help auf die gleiche Weise, bevor er Vorgänge ausführt.

Bei einer über Herdr verwalteten Installation entsprechen dieselben Aktionen Herdr-Befehlen:

herdr plugin action invoke update --plugin herdr.collie      # Herdr-managed
bin/collie update                                            # Standalone

collie update --check ändert nichts. Es führt collie doctor aus, liest den freien Speicherplatz, die bun-Version, den Arbeitsbaum, die Upstream-Release-Liste sowie die Service-Unit aus und stellt auf einem Lead jedem Crew-Mitglied über Ihr eigenes SSH dieselbe Frage. Es wird mit 0 beendet, sofern nichts rot ist, und --json gibt einen versionierten Bericht aus. Fügen Sie --local hinzu, um nur diese Instanz zu prüfen und die Crew-Mitglieder zu überspringen. Das Smartphone führt diese lokale Prüfung auf seinem eigenen Host aus und liest die Zeile jedes Peers über die Crew-Verbindung, sodass dessen Vorabprüfung kein SSH benötigt.

collie update ruft das neueste Release Ihrer aktuellen Hauptversion ab und bereitet es vor. Der Befehl übergibt den Wechsel anschließend an ein separates Aktualisierungsprogramm und beendet sich, da der Neustart die Bridge trennt, die das Update angefordert hat. Dieses Aktualisierungsprogramm setzt current auf die neue Version, startet über die neue Binärdatei neu und fragt GET /api/health bis zu 30 Sekunden lang ab, um eine Antwort mit der neu installierten Version zu erhalten. Bleibt die Antwort aus oder stammt sie von der alten Version, setzt es current zurück, führt einen erneuten Neustart durch und protokolliert rolled-back mit dem Ende des Dienstprotokolls. Startet der Dienst auch dann nicht, protokolliert es stuck samt dem manuell auszuführenden Befehl, und es erfolgt kein weiterer Neustart. Ein Rollback wird genau einmal ausgeführt, niemals zweimal.

Setzen Sie COLLIE_UPDATE_HEALTH_TIMEOUT_MS, falls 30 Sekunden auf Ihrem Rechner nicht ausreichen. Ein langsamer Kaltstart, der das Zeitlimit überschreitet, wird als fehlgeschlagene Aktualisierung gewertet und zurückgerollt.

collie update --status gibt das Protokoll des Aktualisierungsprogramms aus; das Telefon liest dasselbe Protokoll. Der Standby-Port eines deputy stellt dieses unter /standby/update bereit, während der Hauptport nicht erreichbar ist.

Wenn ein neues Beacon-Hook-Ereignis verfügbar ist, gibt update einen Hinweis aus, hooks install claude erneut auszuführen.

Nach jedem erfolgreichen Update, Rollback oder Wechsel führt das neue Build collie skill sync aus. Es installiert den Walky-Talky-Skill in jedem Agenten-Harness auf dieser Maschine und aktualisiert eine veraltete Kopie, damit Ihre Agenten das aktuell ausgeführte Build kennen. Es gibt eine Zeile pro geänderter Datei aus und lässt das Update niemals fehlschlagen: Wenn es nicht ausgeführt werden kann, gibt update einen Hinweis aus und Sie führen collie skill sync manuell aus. Es lässt ein Harness aus, in dem Sie collie skill uninstall ausgeführt haben. Setzen Sie COLLIE_SKILL_SYNC=off, um Ihre Anweisungsdateien unverändert zu lassen; das Update gibt dann nur einen Hinweis aus, wenn der Skill veraltet ist (Den Skill installieren).

Speicherorte der Versionen

Eine Binärinstallation und ein verknüpfter Klon nutzen dieselbe Verzeichnisstruktur unter dem Installationsverzeichnis (~/.local/share/collie oder $COLLIE_DIR bei einer Binärinstallation, der Klon selbst bei einem Checkout):

current -> versions/v1.3.0
versions/v1.3.0/
versions/v1.2.0/

Bei einem Checkout ist jedes versions/vX.Y.Z ein Git-Worktree des Release-Tags und teilt sich dasselbe .git; eine Version belegt somit lediglich einen Arbeitsbaum und keinen zweiten Objektspeicher. Der Build-Vorgang läuft im neuen Verzeichnis und schreibt zuletzt eine Abschlussmarkierung; ohne diese Markierung wird der Wechsel verweigert, sodass ein abgebrochener Build-Vorgang die aktive Version unberührt lässt. Die Aktivierung erfolgt über ein einmaliges Umbenennen des Symlinks current. Die Aufbewahrung behält current sowie die zwei neuesten Vorgängerversionen bei; Bereinigungen erfolgen ausschließlich nach einem erfolgreichen Durchlauf, sodass ein Durchlauf, der sein Rollback-Ziel eventuell benötigt, dieses niemals entfernt.

Ein Von Herdr verwaltet-Checkout bildet die Ausnahme und wird direkt im bestehenden Verzeichnis aktualisiert (ADR 0006, geändert am 03.09.2026). Er ist detached und shallow und liegt in einem Verzeichnis, das Herdr gehört; daher existiert daneben keine versions/-Struktur, keine Übergabe und keine Rückkehrmöglichkeit. --rollback wird dort verweigert; die Wiederherstellung erfolgt über die Neuinstallation eines benannten Tags (herdr plugin install AltanS/collie --ref vX.Y.Z --yes).

Ein Rollback von 1.8.0 auf 1.7.0 erfordert zwei manuelle Bearbeitungen im Statusverzeichnis. 1.8.0 benennt die drei Statusdateien beim ersten Start um, sodass ~/.local/state/collie/ nun crew-trust.json, crew-ops.json und crew-runtime.json enthält, und ein 1.7.0-Build liest nur die alten Namen. Benennen Sie alle drei zurück, bevor Sie den 1.7.0-Build starten:

cd ~/.local/state/collie
mv crew-trust.json pack-trust.json
mv crew-ops.json pack-ops.json
mv crew-runtime.json pack-runtime.json

Bearbeiten Sie dann zwei Schlüsselnamen in pack-trust.json. 1.8.0 liest den Crew-Block unter beiden Schreibweisen und schreibt ihn als "crew" mit "crewId" darin zurück, wo 1.7.0 "pack" und "packId" schrieb. Ein 1.7.0-Build liest nur seine eigene Schreibweise. Sobald 1.8.0 den Speicher geschrieben hat – was bei jedem Beitritt, jeder Rotation, jeder warrant-Aktualisierung oder jeder Entfernung geschieht –, benennen Sie diesen Block wieder in "pack" und sein ID-Feld wieder in "packId" um. Sonst hat sich in den drei Dateien nichts geändert, und crew-ops.json sowie crew-runtime.json müssen überhaupt nicht bearbeitet werden. Wenn Sie die Datei lieber nicht anrühren möchten, stellen Sie eine vor der Aktualisierung erstellte Kopie von pack-trust.json wieder her oder bleiben Sie auf 1.8.0: Ein 1.7.0-Build, der den Trust-Store nicht lesen kann, startet solo und erzwingt keine Roster-Prüfung.

Der umgekehrte Weg nach 1.9.0 erfordert dieselben zwei manuellen Änderungen. Version 1.8.x hat die drei Dateien beim ersten Start automatisch umbenannt; 1.9.0 benennt nichts um. Ein Zustandsverzeichnis, das nie unter 1.8.x lief, enthält daher noch die Namen aus 1.7.0, und ein 1.9.0-Build liest ausschließlich die Crew-Namen. Das Programm meldet dies beim Start, nennt beide Änderungen und bleibt im Einzelbetrieb, statt das Verzeichnis zu übernehmen. Führen Sie die Änderungen vor dem Start durch:

cd ~/.local/state/collie
mv pack-trust.json crew-trust.json
mv pack-ops.json crew-ops.json
mv pack-runtime.json crew-runtime.json

Benennen Sie dann zwei Schlüsselnamen in crew-trust.json um: Der Block "pack" wird zu "crew", und jedes "packId" darin wird zu "crewId". Ansonsten ändert sich in den drei Dateien nichts. Eine Datei unter dem alten Namen führt zu keinem Datenverlust, sondern betrifft nur die Crew: Dieses Collie startet bis zur Umbenennung im Einzelbetrieb.

Überprüfen

bin/collie update --status
herdr plugin action invoke version --plugin herdr.collie
bin/collie version

Erwarten Sie das neueste Tag.

Das Bundle des Telefons ist unabhängig davon. Die PWA prüft selbstständig auf einen neuen Build und lädt innerhalb von etwa einer Minute neu; diesen Neustart hält sie für die Dauer eines Aktualisierungsdurchlaufs zurück. Falls Sie sich mitten in einer Aufgabe befinden, zeigt sie das Banner „Zum Aktualisieren tippen“ an und wartet auf Ihre Eingabe.

Unter Windows

Ein Quelltext-Checkout aktualisiert sich unter Windows nie selbst; eine ZIP-Installation schon. collie update und die Schaltfläche "Aktualisieren" des Telefons teilen dies bei einem Quelltext-Checkout in einem Satz mit und ändern nichts. Der Wechsel zur ZIP-Installation ist ein einmaliger manueller Schritt:

collie uninstall
powershell -ExecutionPolicy Bypass -File .\install.ps1

Danach funktioniert collie update über das Terminal und über das Smartphone. Diese Kette wurde auf einer Windows-11-VM mit einer lokalen Kopie der Release-Dateien geprobt, der Umzug selbst jedoch nicht. Versionen bis einschließlich v1.15.0 konnten zudem ein laufendes collie.exe nicht austauschen. Siehe Collie unter Windows.

Wenn sich die Version nicht geändert hat

collie update fragt GitHub bei jeder Ausführung direkt ab: git ls-remote bei einem Checkout, die GitHub-Tags-API bei einer Binärinstallation. Die Release-Liste wird nicht zwischengespeichert. Es kann dennoch eine Minute dauern, bis ein vor wenigen Sekunden veröffentlichtes Release angezeigt wird, da GitHub selbst einen Moment zur Aktualisierung benötigt. Führen Sie als Nächstes collie doctor aus. Wenn das keine Erklärung liefert, siehe Wenn collie nicht startet.

Wenn GitHub die Release-Prüfung drosselt

collie update bei einer Binärinstallation listet die Releases über die GitHub-API auf, ebenso wie das Update-Banner des Telefons und install.sh. GitHub gewährt einem anonymen Aufrufer 60 API-Aufrufe pro Stunde, gezählt pro Netzwerkadresse; alle Maschinen hinter einem Router teilen sich dieses Kontingent. Ist es aufgebraucht, bricht die Prüfung sicher ab und ändert nichts:

error: GitHub rate-limited the release check (HTTP 403). Wait an hour, or set GH_TOKEN
       to a GitHub token with no scopes, so the limit is yours (docs/upgrading.md).
       Nothing was changed.

Ein Token weist Ihnen Ihr eigenes Kontingent zu. Collie liest ein Token aus der Umgebung ein und fragt nie danach:

Der erste gesetzte Wert entscheidet. Die Tag-Liste ist öffentlich, daher benötigt das Token überhaupt keine Berechtigungen: ein feingranulares persönliches Zugriffstoken (personal access token), bei dem der Repository-Zugriff auf Öffentliche Repositories (schreibgeschützt) steht und keine Berechtigung ausgewählt ist, oder ein klassisches Token, bei dem kein Scope angekreuzt ist. Verwenden Sie kein Token, das Schreibrechte besitzt.

Für einen einzelnen Lauf in einem Terminal borgen Sie die Zugangsdaten der gh-CLI. Der Wert landet nie auf der Befehlszeile oder im Shell-Verlauf:

GH_TOKEN=$(gh auth token) collie update

Für den Dienst tragen Sie es in die Instanz-.env ein, die Collie mit den Zugriffsrechten 600 schützt, oder in config.toml unter [update], und starten Sie neu: Die Bridge liest das Token beim Start ein, sodass das Banner auf dem Smartphone ein neues oder geändertes Token erst nach collie restart verwendet. collie config zeigt es als set oder unset an und gibt den Wert niemals aus. Das Token wird ausschließlich an api.github.com gesendet: Der Download des Releases erfolgt von github.com, wofür kein solches Limit gilt, und überträgt das Token nie. Eine Meldung, die das Token erwähnt, nennt den Namen der Ursprungsvariablen, niemals den Wert. Wird ein Token von GitHub abgelehnt, schlägt die Prüfung mit HTTP 401 und diesem Namen fehl; so wird ein falsches Token nicht mit einem Ratengehemmt-Zustand verwechselt. Die Bridge gibt dies einmal in ihrem Protokoll aus und behält das zuletzt gesehene Release bei. Ein Banner, das nach Ablauf eines Tokens stehen bleibt, geht also auf diese Protokollzeile zurück; collie update --check nennt sie bei jeder Abfrage.

collie update --check meldet dieselben drei Fälle unter upstream. Ein Checkout listet die Tags stattdessen mit git ls-remote auf, was das API-Limit nicht belastet. In einer Crew liest jeder Rechner sein eigenes Token: Ein Mitglied führt die Aktualisierung über sein eigenes collie update aus seinem eigenen .env aus.

Hauptversionswechsel durchführen

update wechselt niemals automatisch die Hauptversion.

herdr plugin action invoke update-major --plugin herdr.collie     # Herdr-managed
bin/collie update --major                                         # Standalone

Dies wechselt um eine Hauptversion auf deren neuestes striktes Release. Es zielt nicht auf Vorabversionen ab (ADR 0020). Siehe auch: Upgrade von 0.x auf 1.0.

Falls dies mit "You are not currently on a branch" fehlschlägt

Installationen von GitHub vor Version 0.23.1 besitzen keine Branch-Tracking-Referenz (#63). Installieren Sie neu, um die Update-Funktion wiederherzustellen:

# replaces the checkout, rebuilds the UI
herdr plugin install AltanS/collie --yes
# reinstall doesn't restart the service
herdr plugin action invoke restart --plugin herdr.collie
# expect 0.23.1 or newer
herdr plugin action invoke version --plugin herdr.collie

Ihre Konfiguration im Plugin-Konfigurationsverzeichnis von Herdr, laut Konvention ~/.config/herdr/plugins/config/herdr.collie, bleibt erhalten.

Den Rest der Crew aktualisieren

collie crew update <member>…      # on the lead
collie crew update --all

Das ist der Terminalpfad für einen Peer, den das Telefon nicht angleichen kann. Aktualisieren Sie vom Telefon aus die gesamte Gruppe mit einem Fingertipp und einer Bestätigung: Öffnen Sie Einstellungen → System → Aktualisierungen auf dem Lead und wählen Sie Crew auf <version> aktualisieren. Die Vorabprüfung über der Schaltfläche deckt jedes Mitglied ab, nicht nur den Lead. Wenn eine Prüfung irgendwo fehlschlägt, ist die Schaltfläche deaktiviert und nennt den fehlerhaften Rechner sowie die Ursache.

Der Lead aktualisiert sich zuerst unter seinem eigenen Health-Gate. Erst wenn er stabil läuft, startet der erste Peer. Ab 1.7.0 ist diese Reihenfolge auch für die Begriffe wichtig: Ein Lead vor Version 1.7.0 liest den Status eines Mitglieds anhand seiner ersten ausgegebenen Zeile, und ein 1.7.0-Mitglied gibt crew … aus, wo ein 1.6.0-Mitglied pack … ausgegeben hat, sodass ein nicht aktualisierter Lead dies nicht lesen kann. Ein 1.7.0-Lead liest beides. Jeder Peer gleicht sich dann an selbst an: Er liest das Release aus, das sein Lead ausführt, ruft genau dieses Tag von GitHub ab und führt seinen eigenen Preflight-Check, sein eigenes Health-Gate und sein eigenes Rollback aus. Peers werden nacheinander aktualisiert. Die Updates-Seite führt eine Zeile pro Mitglied: waiting, checking, staging, restarting, verifying, updated, rolled back oder unreachable.

Ein Member aktualisiert sich höchstens einmal pro Stunde. Ein Member, das innerhalb der letzten Stunde aktualisiert wurde, beispielsweise manuell, wartet mit rate-limited, retries in about N min unter seiner Zeile, und der Durchlauf wird fortgesetzt, sobald diese Zeit verstrichen ist. Wenn das eigene Update des Leads zurückgesetzt wird, bleiben die Member unberührt, was in ihren Zeilen auch so angegeben wird. Ein neues Update wartet, bis der Durchlauf der Crew abgeschlossen ist, höchstens 2 Stunden.

1.7.0 bis 1.8.0. Aktualisieren Sie die Lead-Instanz erneut zuerst, aus einem zweiten Grund: 1.8.0 benennt die Wire-Pfade, die beiden Umgebungsschlüssel, die drei Statusdateien und das Journal-Präfix in crew um. Eine 1.8.0-Lead-Instanz beantwortet die alten /pack/v1/*-Pfade für ein Release lang, sodass ein Member, das noch auf 1.7.0 ist, dem Rollout über die bestehende Verbindung folgt. Beide alten Schreibweisen entfallen in 1.9.0. Die Namen und deren jeweilige Funktion auf Ihrer Maschine finden Sie in Aktualisierung auf 1.9.0 von 1.7.0 oder 1.8.x. Bringen Sie jedes Member auf 1.8.x, bevor Sie die Lead-Instanz auf 1.9.0 aktualisieren: 1.9.0 beantwortet die alten Pfade mit nichts, und ein Member, das noch auf 1.7.0 ist, wird im Preflight der Lead-Instanz rot markiert, zusammen mit beiden Versionen und dem Befehl, den Sie auf dieser Maschine ausführen müssen. Das vom Release veröffentlichte Asset collie-release.json speist den Text dieses Hinweises im Banner, auf der Updates-Karte und im täglichen Push; es ändert nie das Verhalten eines Updates. Es teilt der Prüfung außerdem mit, dass ein Release verfügbar ist: Ein Tag, dessen Asset noch 404 zurückgibt, wird nicht angeboten, und die nächste Prüfung fragt erneut an.

Zwei Voraussetzungen entscheiden darüber, ob ein Peer überhaupt folgen kann:

• —
  Ein Peer benötigt ausgehendes HTTPS zu github.com. Von dort stammt dessen Code. Ohne diesen Zugriff wird der Peer als veraltet gemeldet und stattdessen über das Terminal mit dem obigen Befehl angeglichen.
• —
  Ein -dev+-Build folgt niemals. Eine Maschine mit einem Entwicklungs-Build bleibt darauf, unabhängig davon, was ihr Lead ausführt.

Ein Peer, der ein Rollback ausführt, zeigt dies auf der Seite „Aktualisierungen“ an und unternimmt von sich aus keinen weiteren Versuch. Zwei Pfade ermöglichen einen erneuten Versuch:

• —
  Vom Telefon aus. Sobald der Lead aktuell ist und ein Peer im Rückstand liegt, lautet die Schaltfläche Crew-Update wiederholen. Sie startet einen neuen Durchlauf, dessen einzige Schritte die Peers sind, und genau dieser neue Durchlauf gewährt jedem von ihnen einen weiteren Versuch.
• —
  Über das Terminal, auf dem Lead. Verwenden Sie dies für einen Peer, den das Telefon überhaupt nicht angleichen kann. Der Befehl bleibt unverändert:

collie crew update <member>…      # on the lead
collie crew update --all

Die Ausführung auf dem Lead entspricht einer Sequenz über Ihre eigene SSH-Verbindung. Zuerst führt er auf jedem Rechner eine Vorabprüfung durch und gibt den eigenen Bericht jedes Peers neben der über SSH empfangenen Antwort aus; Unstimmigkeiten werden so explizit ausgewiesen statt gemittelt. Er bittet um eine einmalige Zustimmung. Danach aktualisiert er den Lead selbst, falls dieser noch nicht den Build ausführt, den er verteilt. Anschließend verarbeitet er nacheinander jeden Peer: Dem Peer wird der Commit des Leads als Git-Bundle übermittelt, er wird neu gebaut, neu gestartet und abgefragt, bis er innerhalb derselben 30-Sekunden-Frist mit dem neuen Build antwortet. Ein Lead ohne Git-Checkout aus einer eigenständigen Installation oder aus einem Paket besitzt keinen Commit zum Übertragen; er installiert stattdessen auf jedem Peer über dieselbe SSH-Verbindung das Release, das er selbst ausführt, fest auf diesen Tag fixiert. Ein Peer, der aus einem Git-Checkout ausgeführt wird, wird dann übersprungen und in seiner Zeile als collie update --to-tag v<version> ausgewiesen.

Der erste Fehler stoppt den Durchlauf. Jedes nachfolgende Mitglied bleibt unberührt und wird als "nicht versucht" gemeldet, und die Zusammenfassung nennt den einen Befehl, der den Fehler behebt. Ein Lead, der sein eigenes Update nicht anwenden kann, fasst keinen Peer an. Dort anzuhalten ist sicher, da eine Crew Versionsabweichungen toleriert (CREW_PROTOCOL.md §7.1), sodass eine halb aktualisierte Crew ein unterstützter Zustand ist, das Fortfahren jedoch nicht.

Ein Fall, den das Telefon nicht beheben kann. Wenn Sie die Lead-Instanz manuell per git oder durch Kopieren von Dateien zurücksetzen, nachdem deren Peers angeglichen wurden, bleiben die Peers ihrer Lead-Instanz voraus. Collie hat das Rollback nicht registriert, daher stuft sich kein Member zurück. Ein Rollback über das Rollback durchführen des Telefons oder mit collie update --rollback sowie ein Wechsel zurück zu Stable stufen die Member zurück. Siehe „Die Crew folgt der Lead-Instanz“ unter Release-Linien. Nur diese beiden Vorgänge setzen ein Member auf eine niedrigere Version zurück, denn eine Lead-Instanz, die einen Peer beliebig zurücksetzen könnte, könnte ihn auf jeden beliebigen Stand setzen. Die Abweichung durch ein manuelles Rollback ist harmlos; die Abhilfe ist collie crew update <member> auf der Lead-Instanz.

Code erreicht einen Peer über Ihr SSH und niemals über die Crew-Verbindung (ADR 0016, Nachtrag 2026-09-04). Wenn ein Peer sich selbst angleicht, stammt sein Code über anonymes HTTPS von GitHub, und der Peer entscheidet selbst. Der Lead gibt nur die von ihm ausgeführte Version an und welcher Peer fortfahren darf.

Wenn das Aktualisierungsprogramm selbst abstürzt

Nichts davon hilft, wenn das Aktualisierungsprogramm nicht mehr existiert. Dies ist der Pfad, der lediglich ein Terminal voraussetzt.

Das Aktualisierungsprogramm schreibt einen Datensatz: <state dir>/update.json (standardmäßig ~/.local/state/collie/update.json oder unter $COLLIE_STATE_DIR). Lesen Sie diesen zuerst: Er enthält den Status, die Ausgangsversion des Durchlaufs, die Zielversion, die PID des Aktualisierungsprogramms sowie bei einem Fehler das Ende des Dienstprotokolls und den Wiederherstellungsbefehl.

Ein vom Telefon gestartetes Update gibt überhaupt nichts in Ihrem Terminal aus. Unter Linux mit einem systemd-Benutzermanager läuft es unter einer eigenen flüchtigen Unit namens collie-api-update-<stamp>, und --collect entfernt diese Unit, sobald sie beendet wird, sodass ihr Protokoll nur im Journal liegt:

journalctl --user -u 'collie-api-update-*' --since '30 min ago'

Überall sonst, einschließlich macOS, wird die Ausgabe des Updaters in eine Datei im Zustandsverzeichnis geschrieben:

cat ~/.local/state/collie/update-runner.log

Jedes vom Telefon gestartete Update leert diese Datei und behält den vorherigen Durchlauf als update-runner.log.1. Auf der systemd-Ebene enthält die Datei nur die eine Zeile, die systemd-run ausgibt; den Rest enthält das obige Journal.

Ein Crew-Mitglied kann nach einem Crew-Update auf der alten Version verbleiben. Dessen Checkout zeigt dann das neue Tag an, /standby/health oder die Fußzeile zeigt jedoch weiterhin den alten Build. Prüfen Sie mit systemctl --user list-units 'collie-api-update-*', dass kein Updater läuft. Falls keiner läuft, führen Sie collie update auf diesem Rechner aus. Dies erstellt einen Checkout neu, dessen Build nicht abgeschlossen wurde.

Ein Durchlauf, der vor der Umstellung abbricht, zum Beispiel eine neue Version, die auf diesem Rechner nicht startet, ändert nichts auf der Festplatte. Das Telefon, das ihn gestartet hat, meldet, dass das Update auf diesem Rechner fehlgeschlagen ist, und nennt den Grund. Derselbe Grund steht im Feld reason von update.json.

Dort müssen Sie nachsehen, wenn das Telefon Erfolg gemeldet hat und nachgelagert etwas nicht ausgeführt wurde: zum Beispiel eine Warnung, dass der Ausführungsdatensatz nicht geschrieben werden konnte; dies ist ein Lead, der sich selbst aktualisiert hat und seine Crew nicht angleichen wird. Das eigene Journal der Bridge enthält die andere Hälfte: eine [crew] update <run id>: levelling peers to <version>-Zeile pro Durchlauf, wenn der Lead den Datensatz übernimmt. Vor Version 1.8.0 lautete dieses Präfix [pack]. Fehlt eine solche Zeile, wurden die Spielzüge nie gestartet.

Ein Update vor Version 1.5.4 hängt bei bunx fest

Vor Version 1.5.4 laufen vom Telefon gestartete Updates in einer flüchtigen systemd-Benutzer-Unit, der Ihr PATH fehlt. Wenn Bun bei einer Checkout-Installation nur in ~/.bun/bin liegt, rückt der Checkout vor, aber der Neubau schlägt mit bunx: command not found fehl. Beheben Sie dies, indem Sie collie update einmal in einem Terminal ausführen, in dem Bun im PATH liegt, oder führen Sie die Herdr-Aktion aus, deren Shim Bun selbst lokalisiert. Beide Methoden bauen den vorgerückten Checkout neu. Ab Version 1.5.4 findet der Updater Bun von selbst.

Daneben liegt <state dir>/update.lock, das eine PID und einen Zeitstempel enthält. Es findet jeweils nur ein Durchlauf statt. Ein Datensatz, der noch immer preflight, staging, restarting oder verifying anzeigt, sich seit 10 Minuten nicht geändert hat und dessen PID nicht mehr in der Prozesstabelle steht, ist beendet: Er gilt als interrupted, und ein neuer Durchlauf darf die Sperre übernehmen.

Um die vorherige Version manuell wiederherzustellen, verweisen Sie mit current darauf und starten neu:

cd ~/.local/share/collie        # or $COLLIE_DIR, or the checkout root
ls versions/
ln -sfn versions/<previous> current
collie restart

Oder überlassen Sie diesen Vorgang der vorherigen Version; dies entspricht dem Befehl, den ein Datensatz vom Typ stuck enthält:

~/.local/share/collie/versions/<previous>/bin/collie update --rollback

Verwenden Sie den vollständigen Pfad, nicht collie: Der Name in Ihrem PATH wird über current aufgelöst, und current ist die Komponente, die fehlerhaft sein könnte.

Was das Health-Gate nicht erfasst

Das Gate belegt eine einzige Sache: Der Dienst wurde neu gestartet und hat /api/health mit der Version beantwortet, die installiert wurde. Das ist eine begrenzte Zusicherung, keine Garantie gegen Ausfälle. Vier Fehlerquellen können vorliegen, obwohl das Gate Erfolg meldet:

• —
  Ein veraltetes Web-Bundle auf dem Telefon. Der Host verwendet die neue Version und das Telefon führt weiterhin altes JavaScript aus seinem Service-Worker aus. Die PWA ersetzt ihr eigenes Bundle nach ihrem eigenen Zeitplan; das Health-Gate hat darauf keinen Einblick.
• —
  Konfigurations- oder Schemamigrationen. Collie liefert in diesem Rhythmus keine aus, und das Aktualisierungsprogramm führt keine aus. Das Gate prüft, ob der Dienst antwortet, nicht, ob seine Daten korrekt strukturiert sind.
• —
  Ein Mux-Treiber, der erst bei Interaktion fehlschlägt. Die Bridge startet und beantwortet Health-Checks, während der Adapter beim ersten echten Anhängen oder Senden fehlschlägt. Health ist eine Liveness-Prüfung, kein Konformitätstest.
• —
  Das Aktualisierungsprogramm, das den Code der alten Version ausführt. Das abgetrennte Aktualisierungsprogramm wird aus der zu ersetzenden Version gestartet. Es wird schlank und stabil gehalten, und sein Datensatz ist versioniert, sodass ein altes Aktualisierungsprogramm und eine neue Bridge sich weiterhin verstehen. Dies ist jedoch eine Schadensbegrenzung und keine Garantie.

Das neueste Release per Skript ermitteln

Git-Tags abfragen und nach SemVer sortieren. Vermeiden Sie GET /repos/AltanS/collie/releases/latest, da dies Vorabversionen ausschließt.

# newest stable release
git ls-remote --tags --refs https://github.com/AltanS/collie | \
  sed 's#.*refs/tags/##' | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' | sort -V | tail -1

Release-Linien

Jede Maschine befindet sich auf einer von zwei Release-Linien. Der Standardwert ist Stable.

• —
  Stable akzeptiert nur finale Releases, beispielsweise 1.23.0.
• —
  Edge akzeptiert auch Edge-Builds, beispielsweise 1.23.0-edge.2. Ein Edge-Build ist ein Vorab-Release auf GitHub, das wenige Tage vor dem finalen Release aus demselben Quellbaum erstellt wird. Es erreicht zuerst freiwillige Tester, damit Regressionen erkannt werden, bevor alle Nutzer betroffen sind.

Legen Sie die Release-Linie auf dem Telefon fest: Einstellungen → Updates → Release-Linie. Das Umschalten installiert nichts. Es speichert die Linie und zeigt eine Bestätigung an. Die Updates-Karte bietet anschließend über den regulären Update-Bildschirm das an, was die neue Linie bereitstellt.

• —
  Auf Edge ist das Angebot der neueste Build oberhalb Ihrer aktuellen Version, Edge-Builds und finale Releases zusammen, innerhalb derselben Hauptversion. Ein finales Release ersetzt seine eigenen Edge-Builds auf beiden Linien.
• —
  Ein Build, von dem auf dieser Maschine ein Rollback durchgeführt wurde, wird auf keiner Linie mehr angeboten.
• —
  Auf Edge wird die Push-Benachrichtigung über einen neuen Build bei der nächsten Prüfung gesendet, nicht erst in der nächsten Zusammenfassung. Sie wartet dennoch bis 09:00 Uhr Ortszeit. Stable behält die festen Zeitfenster für Zusammenfassungen bei.

Taktung auf Edge. Rechnen Sie mit höchstens etwa einem Edge-Build pro Tag, und jeder enthält sichtbare Änderungen. Die Bridge prüft alle sechs Stunden auf neue Builds. Sie erhalten eine Benachrichtigung pro Build und nie vor 09:00 Uhr lokaler Hostzeit. Findet eine Prüfung mehrere neue Builds, werden diese in einer Nachricht zusammengefasst. Die Update-Leiste fragt einmal pro Build nach, und Sie können einen Build überspringen: Das nächste Update wählt den neuesten. Das Schließen der Leiste gilt nur für diese Version, sodass beim nächsten Build erneut gefragt wird.

Zurück zu Stable. Wechseln Sie auf einer Maschine mit einem Edge-Build zu Stable, zeigt die Seite einen von drei Fällen an:

1. 01
   Ein finales Release auf oder über Ihrem Build ist verfügbar. Die Updates-Karte bietet es als normales Update an.
2. 02
   Ihr Edge-Build ist jedem finalen Release voraus. Die Seite bietet zwei Optionen: - Jetzt zurückkehren installiert nach Bestätigung das neueste finale Release unterhalb Ihres Builds. Es verwendet den Stable-Build, den diese Maschine behalten hat, sofern vorhanden, und lädt ihn andernfalls herunter. Kann eine Statusdatei Ihres Builds von diesem Release nicht gelesen werden, nennt die Seite die Datei vor der Schaltfläche. - Auf Stable warten behält Ihren Build bei. Es werden keine weiteren Edge-Builds angeboten, und das nächste finale Release wird am Tag des Erscheinens angeboten.
3. 03
   Sie führen bereits ein finales Release aus. Es ist nichts zu tun.

Behaltene Builds. Solange eine Maschine auf Edge ist, behält sie den aktiven Build, den vorherigen Build und den letzten Stable-Build. Der letzte Stable-Build wird erst bereinigt, wenn die Maschine wieder auf Stable ist; daher ist „Jetzt zurückkehren“ ein Umschaltvorgang und kein Download.

Rollback. Ein Rollback von einem Edge-Build setzt die Maschine auf Stable und markiert diesen Build als zurückgesetzt. Dies gilt für Rollback durchführen auf dem Telefon und für collie update --rollback. Ein Edge-Build, dessen eigene Funktionsprüfung fehlschlägt, wird vom Updater zurückgesetzt und ebenso markiert, sodass er nicht erneut angeboten wird. Die Linie bleibt Edge, und der nächste Edge-Build wird wie gewohnt angeboten.

Die Crew folgt der Lead-Instanz. Die Linie der Lead-Instanz ist die Linie der Crew. Ein Member folgt seiner Lead-Instanz auf einen Edge-Build, wenn die Lead-Instanz auf Edge ist, und übernimmt deren Linie als eigene. Ein Member stuft sich nur zurück, wenn die Lead-Instanz ein Rollback ausgeführt hat oder zu Stable zurückgekehrt ist. Dies sind die einzigen zwei Fälle, in denen ein Member eine niedrigere Version installiert. Die Seite „Crew“ zeigt die Linie an, der die Member folgen.

Aus dem Terminal. Die Linie wird auf dem Telefon festgelegt. Für jeweils einen einzelnen Durchlauf existieren zwei Flags:

collie update --line edge                     # resolve this one run on Edge; the saved line stays
collie update --to-tag v1.22.6 --downgrade    # go down to a lower final release

--to-tag übernimmt ohne --downgrade nie ein niedrigeres Tag. Ein höheres Edge-Tag übernimmt es nur auf einem Rechner mit Edge. Bei einer von Herdr verwalteten Installation laufen beide Zweige sowie der Weg zurück über dasselbe In-Place-Update: Das Aktualisierungsprogramm checkt das Tag aus und schreibt das Edge-Suffix selbst in die Versionsdateien.

Vorabversionen

Stabile Installationen erhalten keine Vorabversionen. Edge-Builds sind die Ausnahme im Edge-Zweig (siehe Release-Linien). Die Aktivierung von Vorabversionen verfolgt die Vorabversionen dieser Hauptversion bis zur finalen Veröffentlichung (ADR 0020):

# Standalone — the install script's opt-in flag takes the newest prerelease
curl -fsSL https://colliepwa.dev/install.sh | sh -s -- --beta

# Herdr-managed — install the tag; that is the whole opt-in
herdr plugin install AltanS/collie --ref <tag> --yes
# a reinstall does not restart the service
herdr plugin action invoke restart --plugin herdr.collie

Lösen Sie <tag> mit Das neueste Release per Skript ermitteln auf.

So kehren Sie zu stabilen Releases zurück:

herdr plugin install AltanS/collie --yes
herdr plugin action invoke restart --plugin herdr.collie

Aktualisierung auf 1.24.0

Version 1.24.0 ergänzt Nutzungspunkte, eine Stopp-Schaltfläche und ein Layout für große Bildschirme. Wenn Sie von 1.23.4 kommen, ist am Tag der Aktualisierung nichts zu tun. Was Ihnen auffallen wird:

• —
  Collie lässt Ihre statusLine unverändert. Der Zeilenumbruch ist über collie hooks install claude --statusline optional. Wenn Sie den Zeilenumbruch aus einem Edge-Build übernommen haben und ihn entfernen möchten, führen Sie collie hooks uninstall claude und danach collie hooks install claude aus (Collie schreibt Hooks in Claudes eigene Einstellungen).
• —
  Der Kontextpunkt erfordert keinen neuen Hook. Die von 1.23.4 installierten Hooks enthalten bereits SessionStart und führen denselben Befehl aus. Das neue Collie liest die Sitzungsdatei damit ein. Wenn Sie collie hooks install claude noch nie ausgeführt haben, führen Sie es einmal aus. Eine bereits laufende Claude-Sitzung zeigt keinen Punkt an, bis sie neu gestartet, fortgesetzt, geleert oder verdichtet wird, da die Fenstergröße vom Sitzungsstart stammt.
• —
  Die 5-Stunden- und 7-Tage-Punkte lesen Ihre eigenen Anmeldungen. Für Claude liest Collie die Anmeldedatei auf diesem Rechner und fragt api.anthropic.com ab. Für Codex liest es die Sitzungsdateien von Codex und fragt niemanden ab. Beide sind standardmäßig aktiviert. Setzen Sie COLLIE_ACCOUNT_WINDOWS=0 in Ihrer .env oder account_windows = false unter [bridge], um sie zu deaktivieren. OpenCode Go und Grok bleiben deaktiviert, bis Sie sie angeben (Nutzungsfenster).
• —
  Eine Stopp-Schaltfläche, eine Leeren-Schaltfläche und Steuern. Stopp erfordert zwei Fingertipps und betätigt die eigene Stopptaste des Agenten (Einen Durchlauf anhalten). Leeren leert das Eingabefeld, und Wiederherstellen tippt den Text für zwei Minuten wieder ein (Feld leeren). Halten Sie Senden gedrückt, um einen laufenden Zug auf pi, Codex und OMP zu steuern (Steuern oder einreihen).
• —
  Ein Design, das pane-active setzt, ist Version 3. Ein Collie älter als 1.24.0 lehnt diese Datei mit einer Meldung ab, die die Version nennt. Die anderen Designs behalten ihre Version (Versionen).
• —
  Ein breiter Bildschirm zeigt eine Seitenleiste. Ab 600 px Breite und 480 px Höhe zeigt der Bereichsbildschirm mehrere Bereiche nebeneinander an. Um das Telefon-Layout auf einem Gerät beizubehalten, setzen Sie Layout für große Bildschirme in den Einstellungen auf Aus.

Upgrade auf 1.19.0

Version 1.19.0 fasst das Starten von Vorgängen auf einer Seite zusammen und lässt jedes Telefon eigene Tasten und Starter verwalten. Am Tag des Upgrades ist kein Eingriff erforderlich. Was Ihnen auffallen wird:

• —
  Das Dialogfenster „Neu“ ist nun eine Seite. + Neu auf dem Dashboard öffnet /new, mit der Maschine, einer Auswahl für Agent oder Befehl, dem Ordner und einem Neuer Worktree-Schalter. Das Dialogfenster für neue Spaces, dessen Space-Bezeichnung und die Liste vorhandener Worktrees entfallen. Öffnen Sie ein vorhandenes Worktree mit herdr worktree open auf der Maschine (Einen Agenten oder eine Shell vom Smartphone starten).
• —
  Ein Crew-Mitglied muss aktualisiert werden, um Agenten namentlich zu starten. Die Seite listet ein Mitglied auf, auf dem ein älteres Collie läuft, wobei dessen Optionen deaktiviert sind. Aktualisieren Sie zuerst den Lead; die Mitglieder folgen danach (Etwas auf einer Maschine starten).
• —
  Telefone dürfen Starter hinzufügen. Mit dem Standardwert [phone] adds = true kann ein gekoppeltes Telefon bis zu 20 Zeilen zu einer Maschine hinzufügen, gespeichert in launchers-added.json. Setzen Sie adds = false in launchers.toml, um das zu deaktivieren (Vom Telefon hinzugefügte Starter).
• —
  Das Tastenfeld ist nun ein Board. Die Ansicht beginnt als das bisherige Tastenfeld, und jeder Browser behält sein eigenes Layout (Eigenes Tastenfeld). Voreinstellungen in keys.toml bleiben unverändert.
• —
  Ein reiner Ordnername ist ein Ordner unterhalb des Home-Verzeichnisses. projects im Feld „Folder“ bedeutet nun ~/projects, und ein Ordner, der dort nicht existiert, wird mit einem Hinweis abgewiesen.

Upgrade auf 1.18.0

Version 1.18.0 macht das Koppeln sowohl für Lese- als auch für Schreibzugriffe verpflichtend (ADR 0086). Was sich am Tag des Upgrades ändert:

• —
  Gekoppelte Telefone funktionieren weiterhin. Der gespeicherte Token erfüllt die neue Regel bereits. Nichts zu tun.
• —
  Ungekoppelte Browser sehen den Kopplungsbildschirm. Ein Desktop-Browser, der nie gekoppelt war und zuvor lesen konnte, erhält nun 403 device not paired. Führen Sie collie pair auf dem Host aus und geben Sie den Code dann in den Einstellungen dieses Browsers ein (Ein Gerät koppeln).
• —
  Eine installierte App kann die alten Bildschirme noch für einen weiteren Ladevorgang beibehalten. Eine installierte App zeigt möglicherweise noch die Bildschirme der vorherigen Version an, bis sie ein weiteres Mal lädt. Wenn sie nach der Aktualisierung auf Version 1.18 oder neuer „Sign in“ anzeigt, laden Sie die App neu oder schließen und öffnen Sie sie wieder. Koppeln Sie sie anschließend wie oben beschrieben.
• —
  Skripte müssen sich einmalig koppeln. Ein Skript, das die API ohne Token gelesen hat, erhält nun 403. Führen Sie collie pair --expires 30d aus und fordern Sie den Code dann mit einem POST an /api/pair an, der {"code": "...", "label": "script"} und einen Same-Origin-Header Origin enthält. Der Token wird einmalig in dieser Antwort zurückgegeben. Senden Sie ihn bei jedem späteren Aufruf als Authorization: Bearer <token> mit. Speichern Sie ihn wie ein Passwort.
• —
  Host-CLIs benötigen nichts. collie doctor, collie history und der Durchlauf zur Aktualisierung der Crew lesen ihre eigene Bridge mit lokalen Anmeldedaten, die die Bridge in das Statusverzeichnis schreibt.
• —
  Ein Rollback unter 1.18.0 ignoriert Token-Abläufe. Eine ältere Bridge kennt das Feld expiresAt nicht, sodass ein abgelaufenes Gerät wieder funktioniert, bis die Bridge aktualisiert wird. Widerrufen Sie es mit collie devices revoke <label>, falls das relevant ist (Einem Gerät ein Ablaufdatum geben).
• —
  Alte Audit-Dateien enthalten möglicherweise eingegebene Zeichen. Dateien, die vor 1.18.0 geschrieben wurden, können auf dem Telefon eingegebene Zeichen enthalten. Rotieren oder löschen Sie audit.log-Dateien von vor dem Update.
• —
  Maskierung kann im Weg sein. Dateiinhalte in „Dateien“ und Diffs in „Änderungen“ durchlaufen nun dieselbe Maskierung für Geheimnisse wie Pane-Text. Wenn dadurch etwas verborgen wird, das Sie benötigen, setzen Sie COLLIE_REDACT=off in Ihrer .env und starten Sie neu (konfigurieren).
• —
  Ein Lead-Element unter 1.18.0 maskiert auch den Text seiner Mitglieder. Ein Mitglied, das noch auf 1.17.x ist, maskiert nicht, daher maskiert das Lead-Element den Text dieses Mitglieds, bevor Ihr Telefon ihn empfängt. Um den Text eines Mitglieds unmaskiert zu sehen, setzen Sie COLLIE_REDACT=off sowohl auf dem Lead-Element als auch auf dem Mitglied.

Upgrade von 0.x auf 1.0

Wenn BUN_INSTALL nur in .env definiert ist, exportieren Sie es stattdessen in Ihrem Shell-Profil oder Ihrer Dienstumgebung. Führen Sie danach Folgendes aus:

# Herdr-managed
herdr plugin action invoke update-major --plugin herdr.collie

# Linked clone
bin/collie update --major

Überprüfen Sie dies mit bin/collie version oder herdr plugin action invoke version --plugin herdr.collie.

Für Crew-Konfigurationen: Aktualisieren Sie zuerst den Lead und führen Sie dann collie crew update <member>… aus (Den Rest der Crew aktualisieren). Hinweis:

• —
  join erfordert --insecure für einfache http://-Leads.
• —
  Einladungstoken aus Versionen vor 1.0 müssen mit crew invite neu generiert werden.
• —
  Ältere Mitgliedsdatensätze erfordern reconnect.
• —
  Nicht aktualisierte Peers werden in crew status als warn: angezeigt (CREW_PROTOCOL §7.1).

Was sich mit 1.0 für Sie ändert

Herdr-Aktions-IDs und scripts/collie-ctl.sh-Routen bleiben unverändert (ADR 0006).

CLI-Verben sind in <checkout>/bin/collie kompiliert (Befehle). Verwenden Sie bin/collie link, um collie zu PATH hinzuzufügen (collie zu Ihrem PATH hinzufügen, ADR 0021).

Neue Funktionen:

• —
  pair / devices: Schreibberechtigungen pro Gerät (Ein Gerät koppeln).
• —
  crew … / join / promote: Multi-Host-Clustering (Crew-Befehle).
• —
  doctor: Konfigurationsdiagnose.
• —
  stt setup: Konfiguration des Sprach-Composers (Spracheingabe).
• —
  hooks install claude / beacon emit: Agenten-Aktivitäts-Beacons (Agent-Beacons).
• —
  COLLIE_MUX: Wählen Sie herdr (Standard), tmux oder zellij (tmux und zellij).

Nebeneinander, wenn die Herde real ist

Die Konfiguration sekundärer Instanzen ist in Mehrere Collie-Instanzen auf einem Host dokumentiert.

Zurücksetzen

Checken Sie das letzte 0.x-Tag aus und bauen Sie neu:

last0x=$(git ls-remote --tags --refs origin | sed 's#.*refs/tags/##' | \
  grep -E '^v0\.[0-9]+\.[0-9]+$' | sort -V | tail -1)
git fetch --depth 1 origin tag "$last0x"
git checkout --detach --force "$last0x"
rm -f bin/collie    # 1.0's binary otherwise survives the rollback

Bauen Sie mit bash scripts/collie-ctl.sh build neu und rufen Sie die Herdr-Aktion restart auf. Statusdateien (crew-trust.json, crew-runtime.json, paired-devices.json, pairing-pending.json) können verbleiben. Ein Rollback hebt die erzwungene Gerätekopplung auf; konfigurieren Sie COLLIE_DEVICE_HEADER, falls Schreibschutz erforderlich ist.

Funktion überprüfen

Prüfen Sie, ob version mindestens 1.0.0 meldet. Eine aktualisierte Installation koppelt keine Geräte automatisch: Führen Sie pair aus, um einem Telefon seine Schreibberechtigung zu erteilen, und devices revoke, falls dieses Telefon verloren geht (Ein Gerät koppeln).

Stoppen oder deinstallieren

Dienst anhalten:

herdr plugin action invoke stop --plugin herdr.collie     # Herdr-managed
bin/collie stop                                           # standalone

Dienstdefinition und Port-Zuweisungen entfernen (.env und Checkouts bleiben erhalten):

herdr plugin action invoke uninstall --plugin herdr.collie   # Herdr-managed
bin/collie uninstall                                         # standalone

Um das Programm und auch Ihre eigenen Dateien zu löschen, befolgen Sie die drei Schritte unter Installation → Deinstallation, die nach Installationsart aufgeschlüsselt sind, Pakete eingeschlossen.

Wenn collie nicht startet

Führen Sie bei Binärinstallationen (~/.local/share/collie oder $COLLIE_DIR) direkt eine ältere Binärdatei aus:

ls ~/.local/share/collie/versions/
~/.local/share/collie/versions/<previous>/bin/collie update --rollback

So installieren Sie eine bestimmte Version direkt:

curl -fsSL https://colliepwa.dev/install.sh | COLLIE_TAG=v1.0.0 sh

Führen Sie bei Checkouts oder Herdr-Installationen git checkout <tag> oder herdr plugin install AltanS/collie --ref vX.Y.Z --yes aus.

Sie verwenden einen Fork

collie update gleicht origin mit COLLIE_UPDATE_REPO ab (Standard: AltanS/collie) und bricht bei Abweichungen ab. Setzen Sie COLLIE_UPDATE_REPO=you/collie, wenn Ihr Fork eigene Tags veröffentlicht.

So führen Sie Upstream-Updates manuell in Ihren Fork zusammen:

git remote add upstream https://github.com/AltanS/collie.git
git fetch upstream --tags
git merge v1.0.0                                            # the tag you decided to take
# resolve the conflicts, commit the merge, then rebuild and restart:
bash scripts/collie-ctl.sh build
# Herdr-managed: invoke the `restart` action instead
bin/collie restart

Verwenden Sie update --major nicht auf einem Fork; führen Sie das Tag v1.* manuell zusammen. Führen Sie collie doctor aus, um das aktive COLLIE_UPDATE_REPO zu prüfen.

Neustarts überstehen

Aktivieren Sie unter Linux Lingering für unbeaufsichtigte Benutzerdienste:

loginctl enable-linger $USER

Status mit systemctl --user status collie überprüfen.

Unter macOS verwaltet start ~/Library/LaunchAgents/herdr.collie.plist automatisch. Es wird bei der Benutzeranmeldung ausgeführt. Prüfen Sie den Status mit launchctl print gui/$(id -u)/herdr.collie.