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 pack übernimmt ein paketiertes Mitglied niemals eine Aktualisierung vom Telefon. Das Pack listet es als "wartet auf die Paketverwaltung" und wertet den Durchlauf ohne es als abgeschlossen, sodass die beiden obigen Befehle das sind, was es angleicht.

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 Aktualisierungspfade, und beide führen auf jedem Host dieselben Schritte aus: die neue Version neben der aktiven bereitstellen, den Symlink umschalten, neu starten und prüfen, ob der Dienst antwortet. Auf einem pack-Lead decken beide Pfade das gesamte pack ab. Das Telefon ist der kurze Pfad. Das Terminal ist die Rückfallebene für eine Maschine, die das Telefon nicht angleichen 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 die Vorabprüfung, eine Zeile pro Prüfung: doctor, disk, bun, tree, upstream und service. Auf einem Lead wird auch jedes Pack-Mitglied geprüft.

• —
  Grün ist in Ordnung.
• —
  Gelb ist ein relevanter Hinweis und blockiert nie: Versionsabweichungen innerhalb eines Packs, ein ungewöhnlicher Installationstyp oder eine verfügbare Major-Version, die nicht übernommen wird. Nicht nachverfolgte 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 der Ausführung zeigt die Karte den aktuellen Status an:

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 Zusammenfassung, höchstens einmal täglich und nie vor 09:00 Uhr lokaler Host-Zeit. Ein Versionsunterschied, der nur aus Patch-Releases besteht, wartet stattdessen auf ein wöchentliches Zeitfenster, sodass eine Reihe von Patches in einer einzigen Benachrichtigung statt in vieren gebündelt wird; ein Minor- oder Major-Release behält den täglichen Rhythmus bei und übernimmt die ausstehenden Patches. Zurückgehaltene Releases werden zusammengefasst, niemals verworfen. Die Karte zeigt unabhängig vom Zeitfenster immer den aktuellen Status. Die Benachrichtigungseinstellung updates unter Einstellungen → Benachrichtigungen (Web Push) dient als einziger Ausschalter.

Auf einem pack-Lead zeigt die Schaltfläche pack auf <version> aktualisieren, und eine einzige Bestätigung gilt für jede Maschine. Der Lead aktualisiert sich zuerst unter seinem eigenen Zustandstest. Jeder Peer gleicht sich anschließend nacheinander auf dieselbe Version an, unter Verwendung der eigenen Vorprüfung, des eigenen Zustandstests und des eigenen Rollbacks. Es gibt keine Schaltfläche pro Peer und keine zweite Bestätigungsaufforderung. Details, die beiden Wiederherstellungspfade und den einen Fall, den das Telefon nicht beheben kann, finden Sie unter Den Rest des Packs aktualisieren.

Ein Banner am oberen Rand jedes Bildschirms zeigt den Ablauf: das angebotene Release, dann Starting update…, Updating to <version>, Updated to <version>. Tap to reload. und schließlich Updating <n> peers: <names>, während die Peers folgen. Ein Peer, der zurückgesetzt wurde, wird dort ebenfalls genannt, mit Siehe Aktualisierungen. als Weg zurück zur Seite. Das Banner erscheint in dieser Reihenfolge:

Über das Terminal

collie update --check            # read-only preflight, --json for a script
collie update --check --local    # the same, this instance only, no pack 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

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. Der Befehl führt collie doctor aus, liest den freien Speicherplatz, die Version von bun, den Arbeitsbaum, die Upstream-Versionsliste sowie die Systemd-Diensteinheit aus, und auf einem Lead stellt er jedem pack-Mitglied über Ihr eigenes SSH dieselbe Frage. Er beendet mit 0, 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 pack-Mitglieder zu überspringen. Das Telefon führt diese lokale Prüfung auf seinem eigenen Host aus und liest die Zeile jedes Peers über die pack-Verbindung, sodass dessen Vorprü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.

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).

Ü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.

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.

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 des Packs aktualisieren

Aktualisieren Sie ein pack vom Telefon aus mit einem Fingertipp und einer Bestätigung. Öffnen Sie Einstellungen → Aktualisierungen auf dem Lead und wählen Sie pack auf <version> aktualisieren. Die Vorprü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 die fehlschlagende Maschine samt Grund.

Der Lead aktualisiert sich zuerst unter seinem eigenen Zustandstest. Erst wenn er sich stabilisiert hat, beginnt der erste Peer. Jeder Peer gleicht sich dann selbst an: Er liest die Version aus, die sein Lead ausführt, ruft genau dieses Tag von GitHub ab und führt seine eigene Vorprüfung, seinen eigenen Zustandstest und sein eigenes Rollback aus. Peers aktualisieren sich nacheinander. Die Seite „Aktualisierungen“ führt eine Zeile pro Mitglied: waiting, checking, staging, restarting, verifying, updated, rolled back oder unreachable.

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

• —
  Ein Peer benötigt ausgehendes HTTPS zu github.com. Von dort stammt sein Quellcode. Ohne diesen Zugriff wird der Peer als im Rückstand gemeldet und stattdessen wie unten beschrieben über das Terminal 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 pack-Aktualisierung 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 pack update <member>…      # on the lead
collie pack update --all

Der Vorgang läuft als eine Sequenz über Ihr eigenes SSH ab. Er führt zuerst auf jeder Maschine eine Vorprüfung durch und gibt den eigenen Bericht jedes Peers neben der über SSH erhaltenen Antwort aus, sodass Abweichungen explizit sichtbar sind statt gemittelt zu werden. Er erfordert eine einzige Zustimmung. Danach aktualisiert er den Lead selbst, falls dieser den weitergegebenen Build noch nicht ausführt. Als Nächstes bearbeitet er nacheinander jeden Peer: Der Commit des Leads wird als Git-Bundle an den Peer übertragen, neu gebaut, neu gestartet und abgefragt, bis er innerhalb desselben Zeitbudgets von 30 Sekunden mit dem neuen Build antwortet.

Der erste Fehler bricht den Durchlauf ab. Jedes nachfolgende Mitglied bleibt unberührt und wird als „nicht versucht“ gemeldet, und die Zusammenfassung nennt den Befehl, der den Fehler behebt. Ein Lead, der seine eigene Aktualisierung nicht anwenden kann, fasst keinen einzigen Peer an. Dort anzuhalten ist sicher, da ein pack Versionsunterschiede toleriert (PACK_PROTOCOL.md §7.1); ein halb aktualisiertes pack ist somit ein unterstützter Zustand, ein Fortfahren hingegen nicht.

Ein Fall, den das Telefon nicht beheben kann. Wenn Sie auf dem Lead manuell ein Rollback durchführen, nachdem sich seine Peers angeglichen haben, sind die Peers ihrem Lead voraus. Nichts stuft einen Peer herab: Ein Lead, der einen Peer zurücksetzen könnte, könnte ihn beliebig verändern. Die Versionsabweichung ist unbedenklich, und die Abhilfe ist collie pack update <member> auf dem Lead.

Code gelangt über Ihr SSH auf einen Peer und niemals über die pack-Verbindung (ADR 0016, Nachtrag 2026-09-04). Wenn sich ein Peer selbst angleicht, stammt sein Code über anonymes HTTPS von GitHub, und der Peer entscheidet selbst. Der Lead gibt lediglich die Version an, die er ausführt, 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 wird überhaupt nicht in Ihrem Terminal ausgegeben. Es läuft unter einer eigenen flüchtigen systemd-Unit namens collie-api-update-<stamp>, und --collect entfernt diese Unit, sobald sie beendet ist, sodass ihr Protokoll nur im Journal liegt:

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

Dort müssen Sie suchen, wenn das Telefon Erfolg gemeldet hat und ein nachgelagerter Schritt ausblieb – zum Beispiel eine Warnung, dass der Ausführungsdatensatz nicht geschrieben werden konnte, was bedeutet, dass ein Lead sich selbst aktualisiert hat und seinen pack nicht angleichen wird. Das eigene Journal der Bridge enthält die andere Hälfte: eine [pack] update <run id>: levelling peers to <version>-Zeile pro Durchlauf, wenn der Lead den Datensatz übernimmt. Fehlt eine solche Zeile, wurden die Turns 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

Vorabversionen

Stabile Installationen erhalten keine Vorabversionen. Die Entscheidung für eine Vorabversion verfolgt die Vorabversionen dieser Hauptversion, bis das finale Release erscheint (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

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 pack-Setups: Aktualisieren Sie zuerst den Lead und führen Sie dann collie pack update <member>… aus (Den Rest des Packs aktualisieren). Hinweis:

• —
  join erfordert --insecure für einfache http://-Leads.
• —
  Einladungstoken aus Versionen vor 1.0 müssen mit pack invite neu generiert werden.
• —
  Ältere Mitgliedsdatensätze erfordern reconnect.
• —
  Nicht aktualisierte Peers werden in pack status als warn: angezeigt (PACK_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).
• —
  pack … / join / promote: Multi-Host-Clustering (pack-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 (pack-trust.json, pack-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 verbleibende Dateien zu löschen: Führen Sie herdr plugin uninstall herdr.collie aus (von Herdr verwaltet) oder führen Sie bin/collie unlink aus und löschen Sie ~/.local/share/collie / $COLLIE_DIR (Standalone).

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.