Gérer et mettre à jour

Les installations Herdr n'ont pas de collie dans le PATH ; utilisez les identifiants d'action Herdr (Actions Herdr). Les installations autonomes placent le binaire dans ~/.local/share/collie/current/bin/collie ou <checkout>/bin/collie :

# 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

Exécutez bin/collie link pour créer un lien symbolique vers le binaire dans ~/.local/bin (Ajoutez collie à votre PATH).

La configuration et l'état se trouvent hors du checkout et persistent lors des mises à jour (bridge/solo-baseline.test.ts). .env et l'enregistrement tailscale serve se trouvent dans le répertoire de configuration, ~/.config/collie sur une installation binaire ou le répertoire de configuration des plugins de Herdr sur une installation Herdr ; les appareils associés et stt.json sont dans le répertoire d'état, ~/.local/state/collie sauf si COLLIE_STATE_DIR le déplace.

Une installation par paquet

Si votre gestionnaire de paquets a installé Collie, il met à jour Collie, et rien en dessous de cette section ne s'applique :

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

Collie reconnaît cette installation à sa disposition sur le disque : pas de .git, pas de structure versions/, le manifeste transporté par la release, et une racine en lecture seule, hors de votre répertoire personnel ou appartenant à root. L'un quelconque des trois derniers critères suffit. Il refuse alors la mise à jour sur place et indique la commande s'il identifie le gestionnaire auquel appartient le dossier :

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

Si le préfixe n'indique aucun gestionnaire connu de Collie, il affiche les deux premières lignes et s'arrête plutôt que de deviner une commande impossible à exécuter.

collie doctor signale la même installation comme saine, et la carte de mise à jour sur le téléphone montre toujours qu'une version plus récente existe, avec la commande du paquet à la place du bouton de mise à jour.

Remarque. Il ne s'agit pas d'une limitation à contourner. Le dossier appartient à votre gestionnaire de paquets, et remplacer ses fichiers sans passer par lui fausserait sa base de données quant à ce qui est installé. sudo collie update refuse de la même façon.

Pour adopter une nouvelle version, exécutez votre gestionnaire de paquets puis redémarrez le service :

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

Une installation via mise fait exception : Collie ne la considère pas comme empaquetée, car l'arborescence réside dans votre répertoire personnel sans structure .git ni versions/ ; collie update refuse donc avec cannot tell how this Collie was installed et n'indique aucun gestionnaire. mise la gère toujours. Consultez Installer.

Le redémarrage est l'étape que Collie ne peut pas effectuer à votre place, et il n'est pas facultatif. Votre gestionnaire de paquets remplace les fichiers sous le bridge en cours d'exécution ; ce processus continue donc d'exécuter l'ancien code alors qu'il signale déjà la nouvelle version. Collie détecte cette incohérence et le signale : collie doctor émet restart-pending, et le téléphone affiche une bannière « Bridge restart needed » indiquant « Collie was replaced on disk. Restart it. » Les deux disparaissent dès que collie restart a été exécuté.

Dans un crew, un membre empaqueté n'adopte jamais de mise à jour depuis le téléphone. Le crew l'affiche sous l'état « waits for the package manager » et considère l'exécution comme terminée sans lui ; ce sont donc les deux commandes ci-dessus qui le mettent à niveau.

Un lead empaqueté ne refuse que sa propre mise à jour. Le téléphone met tout de même à niveau chaque membre vers la version exécutée par le lead, et une seule confirmation suffit pour l'ensemble. Une fois que les deux commandes ci-dessus ont mis à niveau le lead, rien ne se met à niveau tout seul : appuyez à nouveau sur la page Updates et les membres suivront vers la nouvelle version du lead.

Mettre à jour, depuis le téléphone ou le terminal

Deux voies de mise à jour existent, et toutes deux exécutent les mêmes étapes sur chaque hôte : préparer la nouvelle version à côté de celle active, basculer le lien symbolique, redémarrer et vérifier que le service répond. Sur un lead de crew, les deux voies couvrent l'ensemble du crew. Le téléphone représente la voie rapide. Le terminal sert de solution de repli pour une machine que le téléphone ne peut pas mettre à niveau.

Depuis le téléphone

Ouvrez Paramètres et sélectionnez Updates. La carte affiche la version en cours d'exécution, la version la plus récente et les versions intermédiaires incluses dans la mise à jour. Si l'hôte utilise déjà la version la plus récente, la carte l'indique et ne propose rien.

En dessous se trouve la vérification préalable, à raison d'une ligne par contrôle : doctor, disk, bun, tree, upstream et service. Sur un lead, chaque membre du crew est également vérifié.

• —
  Vert est valide.
• —
  Orange est bon à savoir et ne bloque jamais : écart de version au sein d'un crew, type d'installation inhabituel, version majeure disponible mais non adoptée. Les fichiers temporaires non suivis dans un checkout restent au vert.
• —
  Rouge bloque la mise à jour. La ligne indique la raison, telle qu'un collie doctor rouge, moins de 1 Go d'espace libre pour la version préparée, l'absence de bun sur l'hôte, ou un dépôt distant inaccessible. Lorsqu'une commande permet de résoudre le problème, la carte affiche cette commande sous la forme Fix: <command>.

Appuyer sur Mettre à jour vers <version> demande confirmation une seule fois, et le texte de confirmation est littéral : votre session de terminal reste active, et la vue sur le téléphone s'interrompt jusqu'à 30 secondes. Le redémarrage arrête le bridge, pas votre multiplexeur ; les agents continuent donc de s'exécuter et le téléphone se reconnecte sur la nouvelle version. Une mise à jour majeure n'est jamais appliquée lors d'une mise à jour de routine : son passage requiert sa propre confirmation, indique explicitement qu'il s'agit d'une nouvelle version majeure et vous invite à lire d'abord les notes de version.

Pendant son exécution, un volet s'affiche à l'écran. Voir Ce que le téléphone affiche pendant une mise à jour ci-dessous. La carte sur la page Mises à jour présente les mêmes états de manière plus détaillée :

Les quatre premiers indiquent une progression ; la fiche le précise et vous demande de laisser l'écran ouvert. rolled-back indique la version sur laquelle vous êtes encore, affiche la fin du journal du service et propose Réessayer. stuck affiche l'unique commande à exécuter dans un terminal. interrupted propose également Réessayer.

Me le rappeler au prochain récapitulatif masque le rappel de la fiche. Ce n'est pas une mise en sourdine : la prochaine notification attend à la fois une version plus récente et un nouveau créneau.

Fréquence des notifications. Les envois de mises à jour sont regroupés en un récapitulatif, au maximum un par jour, et jamais avant 09:00 heure locale de la machine hôte. Un delta constitué uniquement de versions de correctifs attend plutôt un créneau hebdomadaire, pour qu'un train de correctifs arrive en un seul envoi au lieu de quatre ; une version mineure ou majeure conserve la cadence quotidienne et embarque les correctifs en attente. Les versions retenues sont fusionnées, jamais abandonnées. Un correctif peut aussi demander la cadence quotidienne : un correctif que vous devez appliquer aujourd'hui est marqué comme urgent lors de sa création, et la carte de mise à jour affiche alors une étiquette Urgent avec une phrase expliquant la raison. Vous êtes averti lors de la publication, ou au créneau de 09:00 qui suit. Une seule version urgente fait passer tout le train en attente à la cadence quotidienne, et la version reste un correctif ordinaire. Une installation antérieure à cette fonctionnalité conserve le créneau hebdomadaire pour un correctif urgent jusqu'à ce qu'elle ait été mise à jour une fois. La carte affiche toujours l'état actuel quel que soit le créneau. La préférence de notification updates, sous Paramètres → notifications (Web Push), sert de bouton d'arrêt unique.

Sur un lead de crew, le bouton affiche Mettre à jour le crew vers <version>, et une seule confirmation s'applique à chaque machine. Le lead se met à jour en premier, selon son propre contrôle d'intégrité. Chaque pair se met ensuite au niveau de la même version, un par un, en utilisant son propre preflight, son propre contrôle d'intégrité et son propre rollback. Il n'y a aucun bouton par pair et aucune deuxième demande de confirmation. Pour les détails, les deux voies de récupération et le seul cas que le téléphone ne peut pas corriger, consultez Mise à jour du reste du crew.

Un bandeau en haut de chaque écran affiche ce qui est en attente plutôt que ce qui est en cours : la version proposée, un pair n'ayant pas pu se mettre à jour, et New version — tap to update lorsque l'application en main est en retard par rapport au bridge. Une mise à jour en cours concerne le volet, pas le bandeau.

Ce que le téléphone affiche pendant une mise à jour

Un volet occupe l'écran sur l'appareil ayant appuyé sur la confirmation, et tous les autres appareils reçoivent un badge.

Le volet comporte une ligne par machine, la machine principale en premier, chacune avec sa version et son état actuel. En dessous se trouve la ligne propre à cet appareil, qui concerne l'application en main et non une machine : dès que le bridge sert la nouvelle version, le téléphone télécharge cette application en arrière-plan et la ligne compte les fichiers au fur et à mesure de leur arrivée. Le volet indique également une fois, en petits caractères, que la mise à jour s'exécute sur les machines et que fermer l'application ne l'interrompt pas.

L'appareil qui a lancé l'exécution ne peut pas utiliser l'application derrière le volet. Rien d'autre n'est bloqué : un second téléphone ou une tablette affiche une seule ligne sur laquelle appuyer pour ouvrir, puis se referme.

Lorsque chaque machine a terminé et que le téléphone exécute la nouvelle application, le volet se ferme de lui-même et un court message indique la version. Sur un crew, il indique Crew updated to <version> ; sur une seule machine, il indique le nom de cette machine à la place.

Une exécution ne mettant à jour que les membres, comme Réessayer la mise à jour de la crew, s'approprie l'écran de la même manière. La ligne du lead indique already up to date, car le lead ne fait pas partie de cette exécution et ne redémarre pas. La fin indique Members updated to <version>, et un membre qui n'a pas pu se mettre à jour laisse la fiche ouverte sur le téléphone ayant lancé l'exécution, avec sa raison.

Trois états peuvent se bloquer, et chacun dispose d'une issue. Aucun d'eux n'annule la mise à jour, et aucun d'eux ne recharge l'application.

Remarque. « Téléchargement toujours en cours, continuez à utiliser l'application » concerne l'application sur votre téléphone et jamais la machine. Les machines ont terminé ; seule la nouvelle application n'est pas encore arrivée. L'application que vous utilisez continue de fonctionner, et elle bascule d'elle-même dès que le téléchargement se termine.

Depuis le 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 affiche l'utilisation et ne démarre rien. Chaque commande collie répond à -h et --help de la même manière, avant d'effectuer le moindre travail.

Sur une installation gérée par Herdr, les mêmes verbes sont des actions Herdr :

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

collie update --check ne modifie rien. Elle exécute collie doctor, lit l'espace libre, la version de bun, le working tree, la liste des versions amont et l'unité de service, et sur un lead, elle pose la même question à chaque membre du crew via votre propre SSH. Elle quitte avec le code 0 sauf si un élément est au rouge, et --json affiche un rapport versionné. Ajoutez --local pour vérifier uniquement cette instance et ignorer les membres du crew. Le téléphone exécute cette vérification locale sur son propre hôte et lit la ligne de chaque pair via le lien du crew, son preflight n'a donc pas besoin de SSH.

collie update récupère la version la plus récente de votre version majeure actuelle et la prépare. La commande délègue ensuite le basculement à un outil de mise à jour distinct et quitte, car le redémarrage coupe le pont ayant demandé la mise à jour. Cet outil fait pointer current vers la nouvelle version, redémarre avec le nouveau binaire et interroge GET /api/health pendant 30 secondes au maximum pour obtenir une réponse contenant la version qu'il vient d'installer. Si la réponse n'arrive pas, ou provient de l'ancienne version, il rebascule current en arrière, redémarre encore une fois, et enregistre rolled-back avec la fin du journal du service. Si cela ne démarre pas non plus, il enregistre stuck avec la commande à exécuter manuellement, et plus rien ne redémarre. Il effectue un rollback une fois, jamais deux.

Définissez COLLIE_UPDATE_HEALTH_TIMEOUT_MS si 30 secondes ne suffisent pas sur votre machine. Un démarrage à froid lent qui dépasse ce délai est interprété comme un échec de mise à jour et déclenche un rollback.

collie update --status affiche l'enregistrement conservé par l'outil de mise à jour, et le téléphone lit le même enregistrement. Une issue de secours du deputy le sert sur /standby/update pendant que le port principal est inaccessible.

Si un nouvel événement de hook de balise est disponible, update affiche une notification pour réexécuter hooks install claude.

Après chaque mise à jour, rollback ou basculement réussi, le nouveau build exécute collie skill sync. Il installe le skill walky talky dans chaque harness d'agent sur cette machine et met à jour une copie en retard, pour que vos agents connaissent le build actuellement exécuté. Il affiche une ligne par fichier modifié et ne fait jamais échouer la mise à jour : s'il ne peut pas s'exécuter, update affiche une note et vous lancez collie skill sync manuellement. Il ignore un harness où vous avez exécuté collie skill uninstall. Définissez COLLIE_SKILL_SYNC=off pour conserver vos fichiers d'instructions en l'état ; la mise à jour affiche alors seulement une note lorsque le skill est en retard (Installer le skill).

Emplacement des versions

Une installation binaire et un clone lié partagent la même disposition sous la racine d'installation (~/.local/share/collie ou $COLLIE_DIR pour une installation binaire, le clone lui-même pour un checkout) :

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

Sur un checkout, chaque versions/vX.Y.Z est un worktree git du tag de version, partageant l'unique .git, de sorte qu'une version coûte un arbre et non un second magasin d'objets. La compilation s'exécute dans le nouveau répertoire et écrit un marqueur de complétion en dernier ; le basculement refuse d'opérer sans ce marqueur, garantissant qu'une compilation interrompue ne modifie pas la version active. Le passage en production consiste en un simple renommage du lien symbolique current. La rétention conserve current ainsi que les deux versions précédentes les plus récentes, et seul un cycle réussi purge les anciennes, évitant ainsi qu'une exécution ayant potentiellement besoin de sa cible de rollback ne la supprime.

Un checkout Géré par Herdr fait exception et continue d'avancer sur place (ADR 0006, modifié le 2026-09-03). Il est détaché et superficiel, et il réside dans un répertoire appartenant à Herdr, il n'y a donc pas de structure versions/ à côté, rien à déléguer et aucun état antérieur vers lequel basculer. --rollback y est refusé ; la procédure de récupération consiste en une réinstallation d'un tag désigné (herdr plugin install AltanS/collie --ref vX.Y.Z --yes).

Rétrograder de la version 1.8.0 à la version 1.7.0 nécessite deux modifications manuelles dans le répertoire d'état. 1.8.0 renomme les trois fichiers d'état lors de son premier démarrage : ~/.local/state/collie/ contient désormais crew-trust.json, crew-ops.json et crew-runtime.json, et un build 1.7.0 ne lit que les anciens noms. Renommez tous les trois avec leurs anciens noms avant de lancer le build 1.7.0 :

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

Modifiez ensuite deux noms de clés dans pack-trust.json. La version 1.8.0 lit le bloc crew sous l'une ou l'autre des graphies et le réécrit sous le nom "crew", avec "crewId" à l'intérieur, là où la version 1.7.0 écrivait "pack" et "packId". Une version 1.7.0 ne lit que sa propre graphie ; par conséquent, dès que la version 1.8.0 a écrit dans le magasin (ce qu'elle fait lors de toute adhésion, rotation, actualisation de warrant ou suppression), renommez ce bloc en "pack" et son champ id en "packId". Rien d'autre n'a changé dans les trois fichiers, et crew-ops.json ainsi que crew-runtime.json ne nécessitent aucune modification. Si vous préférez ne pas toucher au fichier, restaurez une copie de pack-trust.json effectuée avant la mise à jour, ou restez sur la version 1.8.0 : une version 1.7.0 incapable de lire le magasin de confiance démarre en solo et n'applique aucun tableau des membres.

Faire l'inverse pour passer à la 1.9.0 nécessite les deux mêmes modifications, à la main. La version 1.8.x a renommé les trois fichiers pour vous lors de son premier démarrage ; la version 1.9.0 ne renomme rien. Un répertoire d'état qui n'a jamais vu la 1.8.x conserve donc les noms de la 1.7.0, et une version 1.9.0 lit uniquement les noms crew. Elle l'indique au démarrage, mentionne les deux modifications et reste solo plutôt que d'adopter le répertoire. Effectuez-les avant de la démarrer :

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

Renommez ensuite deux noms de clés dans crew-trust.json : le bloc "pack" devient "crew", et chaque "packId" qu'il contient devient "crewId". Rien d'autre ne change dans les trois fichiers. Laisser un fichier sous l'ancien nom n'entraîne aucune perte de données, seulement celle de la crew : ce collie démarre en solo jusqu'au renommage.

Vérifier

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

Attendez-vous au tag le plus récent.

Le bundle propre au téléphone est indépendant. La PWA vérifie seule l'existence d'une nouvelle version et recharge dans un délai d'environ une minute, puis suspend ce rechargement pendant toute la durée d'une mise à jour. Si vous êtes au milieu d'une tâche, elle affiche un bandeau "appuyer pour mettre à jour" et attend votre validation.

Sous Windows

Une version issue des sources ne se met jamais à jour automatiquement sous Windows ; une installation par zip le fait. collie update et le bouton de mise à jour du téléphone l'indiquent en une phrase sur une version issue des sources et ne modifient rien. Le passage à l'installation par zip est une étape manuelle unique :

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

Après cela, collie update fonctionne depuis le terminal et depuis le téléphone. Cette chaîne a été testée sur une machine virtuelle Windows 11 avec une copie locale des fichiers de version, mais le déplacement lui-même ne l'a pas été. Les versions jusqu'à la v1.15.0 incluse ne pouvaient pas non plus remplacer un collie.exe en cours d'exécution. Consultez Collie sur Windows.

Si la version n'a pas changé

collie update interroge directement GitHub à chaque exécution, via git ls-remote pour une copie de travail ou via l'API des tags GitHub pour une installation binaire. Elle ne met pas en cache la liste des versions. Une version publiée il y a quelques secondes peut mettre une minute à apparaître, car GitHub doit lui-même se synchroniser. Exécutez ensuite collie doctor. Si cela n'explique pas la situation, consultez Si collie ne s'exécute pas.

Si GitHub applique une limite de débit à la vérification des versions

collie update sur une installation binaire liste les releases via l'API de GitHub, tout comme la bannière de mise à jour du téléphone et install.sh. GitHub autorise 60 appels d'API par heure pour un appelant anonyme, comptabilisés par adresse réseau ; chaque machine située derrière un même routeur partage donc ce quota. Lorsqu'il est épuisé, la vérification échoue en mode verrouillé et ne modifie rien :

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.

Un jeton vous applique votre propre limite. Collie lit celui présent dans l'environnement et n'en demande jamais :

La première variable définie l'emporte. La liste des tags est publique, le jeton nécessite donc aucune permission du tout : un jeton d'accès personnel fin avec un accès au dépôt réglé sur Public repositories (read-only) et aucune permission sélectionnée, ou un jeton classique sans aucune case cochée. N'utilisez pas de jeton disposant de droits d'écriture.

Pour une exécution unique dans un terminal, empruntez l'identifiant du CLI gh. La valeur n'apparaît jamais sur la ligne de commande ni dans l'historique du shell :

GH_TOKEN=$(gh auth token) collie update

Pour le service, placez-le dans le .env de l'instance, que Collie conserve avec les permissions 600, ou dans config.toml sous [update], puis redémarrez : le bridge lit le jeton à son démarrage, le bandeau du téléphone n'utilise donc un jeton nouveau ou modifié qu'après collie restart. collie config l'affiche sous la forme set ou unset et n'affiche jamais sa valeur. Le jeton est uniquement envoyé à api.github.com : le téléchargement de la release provient de github.com, qui n'a pas cette limite, et ne le transmet jamais. Tout message mentionnant le jeton indique le nom de la variable d'origine, jamais la valeur. Un jeton refusé par GitHub échoue à la vérification avec HTTP 401 et ce nom, de sorte qu'un mauvais jeton n'est pas confondu avec une limite de requêtes. Le bridge consigne ce résultat une seule fois dans ses journaux et conserve la dernière release vue ; un bandeau qui cesse d'évoluer après l'expiration d'un jeton correspond à cette ligne de journal ; collie update --check l'indique dès que vous le demandez.

collie update --check signale les trois mêmes cas sous upstream. Un checkout liste les tags avec git ls-remote à la place, ce qui n'est pas comptabilisé dans la limite d'API. Dans un crew, chaque machine lit son propre jeton : un membre se met à jour en exécutant son propre collie update, depuis son propre .env.

Changer de version majeure

update ne passe jamais automatiquement à une version majeure supérieure.

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

Cette commande avance d'une version majeure vers sa version finale la plus récente. Elle ne cible pas les préversions (ADR 0020). Voir aussi : Passer de la version 0.x à la version 1.0.

Si cela échoue avec "You are not currently on a branch"

Les installations depuis GitHub antérieures à la version 0.23.1 ne disposent pas d'une référence de suivi de branche (#63). Réinstallez pour rétablir la fonctionnalité de mise à jour :

# 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

Votre configuration dans le répertoire de configuration des plugins de Herdr, ~/.config/herdr/plugins/config/herdr.collie par convention, est conservée.

Mise à jour du reste du crew

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

C'est le chemin par le terminal, pour un pair que le téléphone ne peut pas mettre à niveau. Depuis le téléphone, mettez à jour toute la crew d'un seul geste et avec une seule confirmation : ouvrez Paramètres → Système → Mises à jour sur le lead et sélectionnez Mettre à jour le crew vers <version>. La vérification préalable au-dessus du bouton couvre tous les membres, pas seulement le lead. Si un contrôle est rouge quelque part, le bouton est désactivé et indique la machine en échec ainsi que la raison.

Le lead se met à jour en premier, selon son propre contrôle de santé. Le premier pair ne démarre qu'une fois le lead stabilisé. À partir de la version 1.7.0, cet ordre compte aussi pour les messages : un lead antérieur à la version 1.7.0 lit le statut d'un membre à sa première ligne affichée, et un membre en version 1.7.0 affiche crew … là où une version 1.6.0 affichait pack …, de sorte qu'un lead non mis à jour ne peut pas le lire. Un lead en version 1.7.0 lit les deux. Chaque pair s'aligne ensuite lui-même : il lit la version exécutée par son lead, récupère ce tag exact sur GitHub et exécute sa propre vérification préalable, son propre contrôle de santé et son propre retour arrière. Les pairs avancent un par un. La page Mises à jour conserve une ligne par membre : waiting, checking, staging, restarting, verifying, updated, rolled back ou unreachable.

Un membre se met à jour au maximum une fois par heure. Un membre qui s'est mis à jour au cours de l'heure écoulée, par exemple manuellement, attend avec rate-limited, retries in about N min sous sa ligne, et l'exécution se poursuit une fois ce délai passé. Si la propre mise à jour du lead fait l'objet d'un rollback, les membres ne sont pas modifiés, et leurs lignes l'indiquent. Une nouvelle mise à jour attend que l'exécution de la crew soit terminée, pendant 2 heures au maximum.

1.7.0 vers 1.8.0. Le lead d'abord, pour une seconde raison : la version 1.8.0 renomme en crew les chemins réseau, les deux clés d'environnement, les trois fichiers d'état et le préfixe du journal. Un lead 1.8.0 répond aux anciens chemins /pack/v1/* pendant une version, afin qu'un membre encore en 1.7.0 suive la mise à niveau via le lien existant. Les deux anciennes graphies disparaissent en 1.9.0. Les noms et le rôle de chacun sur votre machine sont décrits dans Mise à jour vers la 1.9.0 depuis la 1.7.0 ou la 1.8.x. Mettez à niveau chaque membre vers la version 1.8.x avant de passer le lead en 1.9.0 : la version 1.9.0 ne répond plus aux anciens chemins, et un membre resté en 1.7.0 apparaît alors en rouge dans le preflight du lead, avec l'indication des deux versions et la commande à exécuter sur cette machine. L'asset collie-release.json publié par la version alimente le texte de cet avertissement sur le bandeau, sur la carte Mises à jour et dans la notification quotidienne ; il ne modifie jamais le comportement d'une mise à jour. Il signale également au système de vérification qu'une version est disponible : un tag dont l'asset renvoie encore une erreur 404 n'est pas proposé, et la vérification suivante réessaie.

Deux conditions déterminent si un pair peut suivre ou non :

• —
  Un pair nécessite un accès HTTPS sortant vers github.com. C'est de là que provient son code. Sans cet accès, le pair est signalé comme en retard et doit être mis à niveau depuis le terminal, à l'aide de la commande ci-dessus.
• —
  Une version -dev+ ne suit jamais. Une machine sur une version de développement y reste, quelle que soit la version exécutée par son lead.

Un pair qui effectue un retour arrière l'indique sur la page Mises à jour et ne réessaie pas de lui-même. Deux méthodes permettent une nouvelle tentative :

• —
  Depuis le téléphone. Dès que le lead est à jour et qu'un peer est en retard, le bouton indique Réessayer la mise à jour de la crew. Il lance une nouvelle exécution dont les seules étapes concernent les peers, et c'est cette nouvelle exécution qui accorde à chacun d'eux une tentative supplémentaire.
• —
  Depuis le terminal, sur le lead. Utilisez ceci pour un peer que le téléphone ne peut pas du tout mettre à niveau. La commande reste inchangée :

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

L'exécuter sur le lead correspond à une séquence via votre propre connexion SSH. La commande vérifie d'abord chaque machine, puis affiche le rapport de chaque pair en vis-à-vis de la réponse obtenue via SSH, rendant tout désaccord explicite au lieu d'une moyenne. Elle demande une confirmation unique. Elle met ensuite à jour le lead lui-même, s'il n'exécute pas encore le build qu'il distribue. Ensuite, elle traite chaque pair tour à tour : le commit du lead est envoyé au pair sous forme de bundle git, puis le pair est recompilé, redémarré et interrogé jusqu'à ce qu'il réponde avec le nouveau build dans la même limite de 30 secondes. Un lead sans checkout git, issu d'une installation autonome ou d'un paquet, n'a aucun commit à pousser ; il installe donc sur chaque pair la release qu'il exécute lui-même, via la même session ssh et verrouillée sur ce tag ; un pair tournant depuis un checkout git est alors ignoré, avec collie update --to-tag v<version> indiqué sur sa ligne.

Le premier échec interrompt l'exécution. Chaque membre suivant est laissé intact et signalé comme "non tenté", et le récapitulatif indique la commande unique qui résout l'échec. Un lead qui ne peut pas appliquer sa propre mise à jour ne touche aucun peer. S'arrêter là est sûr, car une crew tolère les écarts de version (CREW_PROTOCOL.md §7.1) ; une crew partiellement mise à jour est donc un état pris en charge, alors que continuer ne l'est pas.

Un cas que le téléphone ne peut pas résoudre. Si vous annulez manuellement la version du lead, avec git ou en copiant des fichiers, après l'alignement de ses pairs, ces derniers restent sur une version plus récente que celle du lead. Collie ne détecte pas ce rollback ; aucun membre ne rétrograde donc sa version. Un rollback effectué depuis le téléphone avec Revenir en arrière ou avec collie update --rollback, ainsi qu'un retour sur Stable, rétrogradent bien les membres. Voir « L'équipage suit le lead » sous Branches de version. Ces deux opérations sont les seules qui installent une version inférieure sur un membre, car un lead capable de rétrograder un pair arbitrairement pourrait lui appliquer n'importe quelle version. L'écart issu d'un rollback manuel est sans danger, et la solution consiste à exécuter collie crew update <member> sur le lead.

Le code parvient à un peer via votre SSH et jamais par la liaison de crew (ADR 0016, addendum du 04/09/2026). Lorsqu'un peer se met à niveau lui-même, son code provient de GitHub via HTTPS anonyme et le peer décide de manière autonome. Le lead indique seulement la version qu'il exécute et quel peer peut continuer.

Si l'updater plante lui-même

Rien de ce qui précède n'est utile lorsque l'updater a disparu. C'est la démarche qui suppose seulement un accès terminal.

L'updater écrit un enregistrement, <state dir>/update.json (par défaut ~/.local/state/collie/update.json, ou sous $COLLIE_STATE_DIR). Lisez-le d'abord : il indique l'état, la version d'origine de l'exécution, la version cible, le pid de l'updater et, en cas d'échec, la fin du journal du service ainsi que la commande de récupération.

Une mise à jour lancée par le téléphone ne s'affiche pas du tout dans votre terminal. Sur Linux avec un gestionnaire d'utilisateurs systemd, elle s'exécute dans sa propre unité transitoire, nommée collie-api-update-<stamp>, et --collect supprime cette unité dès qu'elle se termine, de sorte que sa transcription se trouve uniquement dans le journal :

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

Partout ailleurs, macOS compris, la sortie propre du programme de mise à jour est envoyée dans un fichier du répertoire d'état :

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

Chaque mise à jour lancée par le téléphone vide ce fichier et conserve l'exécution précédente sous le nom update-runner.log.1. Sur le niveau systemd, le fichier ne contient que l'unique ligne affichée par systemd-run, et le journal ci-dessus contient le reste.

Un membre de l'équipe peut rester sur l'ancienne version après une mise à jour d'équipe. Son checkout affiche alors le nouveau tag, mais /standby/health ou le pied de page indique toujours l'ancien build. Vérifiez qu'aucun processus de mise à jour ne tourne avec systemctl --user list-units 'collie-api-update-*'. Si aucun ne s'exécute, lancez collie update sur cette machine. Cette commande reconstruit un checkout dont le build ne s'est pas terminé.

Une exécution qui abandonne avant la bascule, par exemple une nouvelle version qui ne démarre pas sur cette machine, ne modifie rien sur le disque. Le téléphone qui l'a lancée indique que la mise à jour a échoué sur cette machine et en donne la raison, et cette même raison correspond au champ reason de update.json.

C'est là qu'il faut regarder lorsque le téléphone a signalé un succès mais qu'une étape en aval ne s'est pas produite ; par exemple, un avertissement indiquant que l'enregistrement d'exécution n'a pas pu être écrit, ce qui correspond à un lead mis à jour mais qui ne mettra pas à niveau sa crew. Le journal propre du bridge contient l'autre moitié : une ligne [crew] update <run id>: levelling peers to <version> par exécution, lorsque le lead récupère l'enregistrement. Avant la version 1.8.0, ce préfixe était [pack]. En l'absence d'une telle ligne, les tours n'ont jamais démarré.

Une mise à jour antérieure à 1.5.4 bloquée sur bunx

Avant la version 1.5.4, les mises à jour lancées depuis un téléphone s'exécutent dans une unité utilisateur systemd transitoire dépourvue de votre PATH. Lorsque Bun se trouve uniquement dans ~/.bun/bin sur une installation par checkout, le checkout avance, mais la reconstruction échoue avec bunx: command not found. Corrigez cela en exécutant collie update une fois depuis un terminal où Bun est dans le PATH, ou lancez l'action Herdr, dont le shim localise Bun lui-même. L'une ou l'autre méthode reconstruit le checkout mis à jour. À partir de la version 1.5.4, l'updater trouve Bun de manière autonome.

À côté se trouve <state dir>/update.lock, qui conserve un pid et un horodatage. Une seule exécution à la fois. Un enregistrement qui indique toujours preflight, staging, restarting ou verifying, n'a pas bougé depuis 10 minutes et dont le pid ne figure plus dans la table des processus, est terminé : il est considéré comme interrupted, et une nouvelle exécution peut acquérir le verrou.

Pour rétablir manuellement la version précédente, pointez current dessus et redémarrez :

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

Ou laissez la version précédente effectuer la même opération pour vous, ce qui correspond à la commande contenue dans un enregistrement stuck :

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

Utilisez le chemin complet, pas collie : le nom présent dans votre PATH est résolu via current, et current est précisément l'élément qui peut être incorrect.

Ce que la vérification d'état ne détecte pas

La vérification prouve une seule chose : le service est revenu et a répondu à /api/health avec la version qui a été installée. Il s'agit d'une garantie limitée, pas d'une promesse de zéro panne définitive. Quatre éléments peuvent être défaillants alors que la vérification signale un succès :

• —
  Un bundle web obsolète sur le téléphone. L'hôte est sur la nouvelle version et le téléphone exécute toujours l'ancien JavaScript depuis son service worker. La PWA remplace son propre bundle selon son propre calendrier ; la vérification d'état n'a aucune visibilité dessus.
• —
  Migrations de configuration ou de schéma. Collie n'en fournit aucune à ce rythme, et l'updater n'en applique aucune. Le contrôle vérifie que le service répond, pas que ses données ont la bonne structure.
• —
  Un pilote mux qui ne plante que lors de l'interaction. Le bridge démarre et répond au health check alors que l'adaptateur échoue lors du premier attachement ou envoi réel. Health est une sonde de liveness, pas un test de conformité.
• —
  L'updater qui exécute le code de l'ancienne version. L'updater détaché est lancé depuis la version en cours de remplacement. Il reste léger et stable et son enregistrement est versionné, de sorte qu'un ancien updater et un nouveau bridge continuent de se comprendre, mais il s'agit d'une atténuation et non d'une garantie.

Résoudre la version la plus récente depuis un script

Interrogez les tags git et triez par semver. Évitez GET /repos/AltanS/collie/releases/latest, qui exclut les préversions.

# 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

Branches de version

Chaque machine suit l'une des deux branches de version. La branche par défaut est Stable.

• —
  Stable accepte uniquement les versions finales, par exemple 1.23.0.
• —
  Edge accepte également les builds Edge, par exemple 1.23.0-edge.2. Un build Edge est une préversion GitHub, générée depuis la même branche quelques jours avant la version finale. Les volontaires la reçoivent en premier, ce qui permet d'identifier les régressions avant la diffusion globale.

Définissez la branche sur le téléphone : Paramètres → Mises à jour → Branche de version. Ce changement n'installe rien. Il enregistre la branche et affiche une confirmation. La carte Mises à jour propose ensuite les versions de la nouvelle branche, via l'écran habituel de mise à jour.

• —
  Sur Edge, la version proposée est le build le plus récent supérieur à celui en cours d'exécution, builds Edge et versions finales confondus, au sein de la même version majeure. Une version finale remplace ses propres builds Edge sur les deux branches.
• —
  Un build ayant fait l'objet d'un rollback sur cette machine n'est plus jamais proposé, sur aucune des deux branches.
• —
  Sur Edge, la notification concernant un nouveau build est envoyée dès la vérification suivante, et non dans le récapitulatif périodique. Elle attend néanmoins 09:00, heure locale. Stable conserve les créneaux de récapitulatif.

Rythme prévu sur Edge. Comptez environ un build Edge par jour au maximum, chacun apportant un changement visible. Le bridge vérifie la présence de nouveaux builds toutes les six heures. Vous recevez une notification par build, jamais avant 09:00, heure locale de l'hôte. Lorsqu'une vérification détecte plusieurs builds récents, ils sont regroupés dans une seule notification. Le bandeau de mise à jour demande confirmation une fois par build, et vous pouvez ignorer un build : la mise à jour suivante prendra le plus récent. Masquer le bandeau ne s'applique qu'à cette version précise : le build suivant redemandera confirmation.

Retour à Stable. Passez sur Stable depuis une machine exécutant un build Edge ; la page présente alors l'un des trois cas suivants :

1. 01
   Une version finale égale ou supérieure à votre build est disponible. La carte Mises à jour la propose comme une mise à jour standard.
2. 02
   Votre build Edge est plus récent que toutes les versions finales disponibles. La page offre deux options : - Revenir en arrière maintenant installe la version finale la plus récente inférieure à votre build, après confirmation. Elle utilise le build Stable conservé par la machine s'il existe, ou le télécharge dans le cas contraire. Si un fichier d'état de votre build ne peut pas être lu par cette version, la page indique le nom du fichier avant le bouton. - Attendre la version Stable conserve votre build actuel. Aucun autre build Edge n'est proposé, et la prochaine version finale vous sera proposée le jour de sa sortie.
3. 03
   Vous utilisez déjà une version finale. Aucune action n'est requise.

Builds conservés. Tant qu'une machine est sur Edge, elle conserve le build actif, le build précédent et le dernier build Stable. Le dernier build Stable n'est nettoyé que lorsque la machine repasse sur Stable ; « Revenir en arrière maintenant » effectue donc un basculement immédiat, sans téléchargement.

Rollback. Un rollback depuis un build Edge bascule la machine sur Stable et marque ce build comme ayant été annulé. Cela s'applique à Revenir en arrière sur le téléphone ainsi qu'à collie update --rollback. Un build Edge qui échoue à son propre test de santé est automatiquement annulé par l'outil de mise à jour et marqué de la même manière, afin de ne plus être proposé. La branche reste configurée sur Edge, et le prochain build Edge est proposé normalement.

L'équipage suit le lead. La branche du lead détermine celle de l'équipage. Un membre adopte un build Edge dès que son lead est sur Edge, et s'aligne sur la branche du lead. Un membre ne rétrograde de version que si le lead effectue un rollback ou repasse sur Stable. Ce sont les deux seuls cas où un membre installe une version inférieure. La page Équipage indique la branche suivie par les membres.

Depuis le terminal. La branche se configure sur le téléphone. Deux options permettent d'intervenir ponctuellement pour une seule exécution :

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 n'accepte jamais un tag inférieur sans --downgrade. Il n'accepte un tag Edge supérieur que sur une machine configurée sur Edge. Sur une installation gérée par Herdr, les deux branches ainsi que le retour en arrière passent par la même mise à jour sur place : le programme de mise à jour extrait le tag et inscrit lui-même le suffixe Edge dans les fichiers de version.

Préversions

Les installations stables ne reçoivent pas de préversions. Les versions Edge constituent l'exception, sur la branche Edge (voir Branches de version). Choisir une préversion suit les préversions de cette version majeure jusqu'à la publication finale (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

Résolvez <tag> avec Résoudre la version la plus récente depuis un script.

Pour revenir aux versions stables :

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

Mise à niveau vers la version 1.24.0

La version 1.24.0 ajoute des indicateurs d'utilisation, un bouton Stop et une disposition pour grand écran. Si vous venez de la version 1.23.4, aucune action n'est requise le jour de la mise à niveau. Ce que vous remarquerez :

• —
  Collie ne modifie pas votre statusLine. L'encapsulation est facultative avec collie hooks install claude --statusline. Si vous avez activé l'encapsulation depuis une version Edge et souhaitez la supprimer, exécutez collie hooks uninstall claude, puis collie hooks install claude (Collie écrit les hooks dans les paramètres de Claude).
• —
  L'indicateur de contexte ne nécessite aucun nouveau hook. Les hooks installés par la version 1.23.4 incluent déjà SessionStart, et ils exécutent la même commande. Le nouveau Collie lit le fichier de session avec ces derniers. Si vous n'avez jamais exécuté collie hooks install claude, lancez-le une fois. Une session Claude déjà en cours d'exécution n'affiche aucun indicateur tant qu'elle n'a pas redémarré, repris, été effacée ou compactée, car la taille de la fenêtre provient du démarrage de la session.
• —
  Les indicateurs 5 heures et 7 jours lisent vos propres connexions. Pour Claude, Collie lit le fichier de connexion sur cette machine et interroge api.anthropic.com. Pour Codex, il lit les fichiers de session de Codex et n'interroge personne. Les deux sont activés par défaut. Définissez COLLIE_ACCOUNT_WINDOWS=0 dans votre .env, ou account_windows = false sous [bridge], pour les désactiver. OpenCode Go et Grok restent désactivés tant que vous ne les avez pas configurés (Fenêtres d'utilisation).
• —
  Un bouton Stop, un bouton Clear et Steer. Stop nécessite deux appuis et envoie la touche d'arrêt propre à l'agent (Arrêter un tour). Clear vide la zone de saisie, et Restore réécrit le texte pendant deux minutes (Vider le champ). Maintenez Send enfoncé pour orienter un tour en cours sur pi, Codex et OMP (Injecter ou mettre en file d'attente).
• —
  Un thème qui définit pane-active est en version 3. Une version de Collie antérieure à la 1.24.0 refuse ce fichier avec un message précisant la version. Les autres thèmes conservent leur version (Versions).
• —
  Un écran large affiche une barre latérale. À partir de 600 px de large et 480 px de haut, l'écran des volets affiche plusieurs volets côte à côte. Pour conserver la disposition pour téléphone sur un appareil, désactivez Disposition grand écran dans Settings.

Mise à jour vers la version 1.19.0

La version 1.19.0 regroupe les lancements sur une page unique et permet à chaque téléphone d'organiser ses propres touches et lanceurs. Aucune action n'est requise le jour de la mise à jour. Ce qui change :

• —
  Le volet Nouveau devient une page. + Nouveau sur le tableau de bord ouvre /new, qui contient la machine, un sélecteur Agent ou Commande, le dossier et un commutateur Nouveau worktree. Le volet de nouvel espace, son libellé d'espace et sa liste de worktrees existants ont disparu. Ouvrez un worktree existant avec herdr worktree open sur la machine (Démarrer un agent ou un shell depuis le téléphone).
• —
  Un membre de l'équipe doit être mis à jour pour lancer des agents par leur nom. La page liste les membres exécutant une version plus ancienne de Collie, avec leurs options désactivées. Mettez d'abord à jour le lead ; les membres suivront (Démarrer un élément sur une machine).
• —
  Les téléphones peuvent ajouter des lanceurs. Avec l'option par défaut [phone] adds = true, un téléphone appairé peut ajouter jusqu'à 20 entrées sur une machine, conservées dans launchers-added.json. Définissez adds = false dans launchers.toml pour désactiver ce comportement (Lanceurs ajoutés depuis un téléphone).
• —
  Le pavé des touches devient un tableau. Il reprend la disposition de votre pavé existant, et chaque navigateur conserve son propre agencement (Votre propre pavé de touches). Les préréglages dans keys.toml restent inchangés.
• —
  Un simple nom de dossier désigne un dossier sous le répertoire personnel. La valeur projects dans le champ Dossier correspond désormais à ~/projects, et un dossier inexistant est refusé avec un message d'avertissement.

Mise à niveau vers la version 1.18.0

La version 1.18.0 rend l'association obligatoire pour les lectures comme pour les écritures (ADR 0086). Ce qui change le jour de la mise à niveau :

• —
  Les téléphones associés continuent de fonctionner. Leur token stocké respecte déjà la nouvelle règle. Rien à faire.
• —
  Les navigateurs non associés voient l'écran d'association. Un navigateur de bureau jamais associé, qui pouvait lire auparavant, reçoit désormais 403 device not paired. Exécutez collie pair sur l'hôte, puis saisissez le code dans les Paramètres de ce navigateur (Associer un appareil).
• —
  Une application installée peut conserver les anciens écrans pendant un chargement de plus. Une application installée peut encore afficher les écrans de la version précédente jusqu'à ce qu'elle se charge une fois de plus. Si elle affiche « Sign in » après la mise à jour vers la version 1.18 ou ultérieure, rechargez l'application, ou fermez-la et rouvrez-la. Associez-la ensuite comme indiqué ci-dessus.
• —
  Les scripts doivent s'associer une fois. Un script qui lisait l'API sans token reçoit désormais 403. Exécutez collie pair --expires 30d, puis validez le code avec un POST vers /api/pair qui transmet {"code": "...", "label": "script"} et un en-tête Origin de même origine. Le token est renvoyé une seule fois, dans cette réponse. Envoyez-le sous forme de Authorization: Bearer <token> à chaque appel ultérieur. Conservez-le comme un mot de passe.
• —
  Les CLI hôtes n'ont besoin de rien. collie doctor, collie history et le balayage de mise à jour de l'équipe lisent leur propre bridge avec un identifiant local que le bridge écrit dans le répertoire d'état.
• —
  Revenir en arrière avant la 1.18.0 ignore les expirations de tokens. Un bridge plus ancien ne connaît pas le champ expiresAt, donc un appareil expiré fonctionne à nouveau jusqu'à ce que le bridge soit mis à jour. Révoquez-le avec collie devices revoke <label> si nécessaire (Définir une expiration pour un appareil).
• —
  Les anciens fichiers d'audit peuvent contenir des caractères saisis. Les fichiers écrits avant la 1.18.0 peuvent lister les caractères saisis sur le téléphone. Faites tourner ou supprimez les fichiers audit.log antérieurs à la mise à jour.
• —
  Le masquage peut être gênant. Le contenu des fichiers dans Fichiers et les diffs dans Modifications passent désormais par le même masque de secrets que le texte du panneau. S'il masque un élément dont vous avez besoin, définissez COLLIE_REDACT=off dans votre .env et redémarrez (configurer).
• —
  Un lead en 1.18.0 masque aussi le texte de ses membres. Un membre toujours en 1.17.x n'applique pas de masque, donc le lead masque le texte de ce membre avant que votre téléphone ne le reçoive. Pour voir le texte d'un membre non masqué, définissez COLLIE_REDACT=off sur le lead ainsi que sur le membre.

Passer de la version 0.x à la version 1.0

Si BUN_INSTALL est défini uniquement dans .env, exportez-le plutôt dans votre profil de shell ou dans l'environnement du service. Exécutez ensuite :

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

# Linked clone
bin/collie update --major

Vérifiez avec bin/collie version ou herdr plugin action invoke version --plugin herdr.collie.

Pour les configurations crew : Mettez d'abord à jour le lead, puis exécutez collie crew update <member>… (Mise à jour du reste du crew). Remarque :

• —
  join requiert --insecure pour les leads http:// simples.
• —
  Les jetons d'invitation antérieurs à la 1.0 doivent être régénérés avec crew invite.
• —
  Les anciens enregistrements de membres requièrent reconnect.
• —
  Les pairs non mis à niveau s'affichent sous la forme warn: dans crew status (CREW_PROTOCOL §7.1).

Ce que la version 1.0 change pour vous

Les identifiants d'action Herdr et les routes scripts/collie-ctl.sh restent inchangés (ADR 0006).

Les verbes du CLI sont compilés dans <checkout>/bin/collie (Commandes). Utilisez bin/collie link pour ajouter collie au PATH (Ajoutez collie à votre PATH, ADR 0021).

Nouvelles fonctionnalités :

• —
  pair / devices : Identifiants d'écriture par appareil (Associer un appareil).
• —
  crew … / join / promote : Clustering multi-hôtes (Commandes crew).
• —
  doctor : Diagnostics de configuration.
• —
  stt setup : Configuration du composeur vocal (Entrée vocale).
• —
  hooks install claude / beacon emit : Balises d'activité des agents (Balises d'agent).
• —
  COLLIE_MUX : sélectionnez herdr (par défaut), tmux ou zellij (tmux et zellij).

Côte à côte, si le herd existe

La configuration des instances secondaires est documentée dans Plusieurs instances de Collie sur un même hôte.

Revenir en arrière

Extrayez le dernier tag 0.x et recompilez :

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

Recompilez avec bash scripts/collie-ctl.sh build et exécutez l'action restart de Herdr. Les fichiers d'état (crew-trust.json, crew-runtime.json, paired-devices.json, pairing-pending.json) peuvent être conservés. Le retour en arrière supprime l'obligation d'appairage des appareils ; configurez COLLIE_DEVICE_HEADER si la protection en écriture est requise.

Vérifier le fonctionnement

Vérifiez que version renvoie 1.0.0 ou une version supérieure. Une installation mise à niveau n'appaire aucun appareil automatiquement : exécutez pair pour attribuer son identifiant d'écriture à un téléphone, et devices revoke si ce téléphone est perdu (Associer un appareil).

Arrêter ou désinstaller

Mettre le service en pause :

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

Supprimez la définition du service et les mappages de ports (.env et les checkouts sont conservés) :

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

Pour supprimer le programme ainsi que vos propres fichiers, suivez les trois étapes décrites dans Installation → Désinstallation, détaillées par type d'installation, paquets inclus.

Si collie ne s'exécute pas

Pour les installations par binaire (~/.local/share/collie ou $COLLIE_DIR), exécutez directement un binaire plus ancien :

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

Pour installer directement une version spécifique :

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

Pour les checkouts ou les installations Herdr, exécutez git checkout <tag> ou herdr plugin install AltanS/collie --ref vX.Y.Z --yes.

Vous utilisez un fork

collie update compare origin à COLLIE_UPDATE_REPO (valeur par défaut AltanS/collie) et s'arrête en cas de différence. Définissez COLLIE_UPDATE_REPO=you/collie si votre fork publie ses propres tags.

Pour fusionner manuellement les mises à jour amont dans votre fork :

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

N'utilisez pas update --major sur un fork ; fusionnez manuellement le tag v1.*. Exécutez collie doctor pour vérifier le COLLIE_UPDATE_REPO actif.

Persistance aux redémarrages

Sur Linux, activez le lingering pour les services utilisateur sans session :

loginctl enable-linger $USER

Vérifiez l'état avec systemctl --user status collie.

Sur macOS, start gère ~/Library/LaunchAgents/herdr.collie.plist automatiquement. Il s'exécute à la connexion de l'utilisateur. Vérifiez l'état avec launchctl print gui/$(id -u)/herdr.collie.