Dépannage

Symptômes ci-dessous, dans l'ordre — recherchez le vôtre sur la page. Os { NotFound } depuis herdr plugin · update indique "not currently on a branch" · tailscale serve failed · ne répond pas (le service ne démarre pas) · le téléphone ne peut pas ouvrir l'URL · la page se charge mais reste vide (page blanche, 403) · une invite de mot de passe n'accepte pas votre saisie · aucune notification push · disparu après un redémarrage · un panneau reste étroit · Collie refuse d'ouvrir une fenêtre tmux · tmux list: output did not parse · herdr plugin list affiche l'ancienne version · interface obsolète après une recompilation · j'ai enregistré une machine dans Herdr et le téléphone ne l'affiche pas · une mise à jour lancée depuis le téléphone reste en attente · une mise à jour depuis le téléphone sur macOS laisse Collie non chargé · sur macOS, collie status indique « loaded, not running » · un volet n'affiche aucun badge de prompt-cache · l'historique d'un volet Kiro s'ouvre vide · un panneau n'a ni Chat ni Historique · un nouveau panneau Codex indique qu'il n'a pas encore d'historique · le téléphone indique que Collie ne peut pas lire un écran que l'agent n'affiche pas · l'envoi a échoué 3 fois et le téléphone propose un rapport · un agent est grisé sur la page Nouveau · Start indique que le dossier n'existe pas, ou indique qu'il n'a pas pu confirmer · walky talky : envoi refusé, « run this inside a pane » · walky talky : le message reste dans la boîte de réception et n'a pas été saisi · walky talky : « no log record on this machine » · walky talky : le skill est obsolète · un agent durable n'apparaît pas, ou indique Unreachable.

herdr plugin … échoue avec Error: Os { code: 2, kind: NotFound, message: "No such file or directory" } (échec de l'installation du plugin, échec de l'appel d'action). Ce n'est pas un problème Collie : le serveur Herdr n'est pas lancé, donc son CLI ne peut pas joindre le socket de contrôle (~/.config/herdr/herdr.sock). L'indice est l'erreur brute Os {…} : un serveur joignable répond aux problèmes de chemin ou de manifeste par du JSON structuré (ex. plugin_manifest_not_found), donc un simple Os { NotFound } indique un échec de connexion au socket, avant même que Collie ou votre chemin ne soient examinés. Cela touche link, install, action invoke (toutes les sous-commandes qui communiquent avec le serveur), tandis que herdr plugin --help fonctionne toujours (il n'ouvre jamais le socket). Solution : démarrez d'abord Herdr (herdr server &, ou lancez simplement le TUI Herdr qui initialise le serveur), confirmez que ls ~/.config/herdr/herdr.sock existe, puis réessayez l'installation. herdr plugin list est un test rapide : s'il renvoie la même erreur, le serveur est arrêté.

update échoue avec You are not currently on a branch. Une installation GitHub effectuée avant 0.23.1 (#63) : herdr plugin install détache au lieu de cloner, donc l'ancien update n'avait aucune branche vers laquelle faire git pull. Le correctif est inclus dans le dépôt qu'il répare ; il faut donc une réinstallation pour l'appliquer : Si cela échoue avec "You are not currently on a branch" contient les trois commandes.

start affiche note: tailscale serve failed. Collie fonctionne correctement (toujours actif sur 127.0.0.1) : seul l'accès tailnet ne s'est pas lancé, et l'erreur de tailscale s'affiche sur le terminal au-dessus de la note. Causes courantes : votre utilisateur n'est pas l'opérateur Tailscale (sudo tailscale set --operator=$USER), le nœud est déconnecté (tailscale up), ou, sur les domaines tailnet Headscale / .internal, les certificats HTTPS ne sont pas disponibles. C'est précisément l'objet de COLLIE_SERVE_MODE=http : définissez-le dans .env, puis lancez bin/collie restart. Vérifiez avec tailscale serve status.

serve indique HTTPS certificates are not enabled on this tailnet. Rien n'a été publié et rien n'est en attente. Ouvrez la console d'administration, activez « Enable HTTPS », puis réexécutez collie serve. Sur les domaines Headscale / .internal, aucun certificat ne peut être activé ; utilisez plutôt COLLIE_SERVE_MODE=http.

La bannière affiche ⚠ Collie isn't answering on :8787 yet (le service ne démarre pas, connexion refusée). Le service a démarré mais le serveur HTTP ne répond pas au test. Vérifiez d'abord l'unité (systemctl --user status collie), puis bin/collie logs (ou journalctl --user -u collie -f pour suivre en direct) pour en trouver la cause : le plus souvent, le port est déjà utilisé (définissez COLLIE_PORT dans .env, puis lancez bin/collie restart, qui réexécute aussi tailscale serve sur le nouveau port) ou la première compilation a échoué (indiqué dans les logs ; corrigez et lancez bin/collie build). L'unité redémarre automatiquement toutes les 5 s ; une fois la cause corrigée, elle revient généralement d'elle-même.

Le téléphone ne peut pas ouvrir l'URL du tailnet. Vérifiez les points suivants dans l'ordre : (1) le téléphone exécute l'application Tailscale et est connecté au même tailnet que l'hôte ; (2) vous ouvrez l'URL tailnet de la bannière (bin/collie url), pas celle en local (http://127.0.0.1:8787 ne fonctionne que sur l'hôte lui-même) ; (3) MagicDNS est activé dans les paramètres DNS de votre tailnet (l'URL est un nom MagicDNS) ; (4) l'hôte est en ligne (vérifiez tailscale status sur l'hôte, ou envoyez un ping à l'hôte depuis l'application Tailscale du téléphone) ; (5) votre politique de tailnet autorise effectivement un pair vers ce nœud : si ce n'est pas le cas, la bannière l'indique désormais sous la ligne tailnet, et rien d'autre ne le fera : le point d'entrée est correctement publié, le certificat est valide, et curl depuis l'hôte lui-même renvoie 200, car le trafic local ne traverse jamais le filtre de paquets. Deux éléments rendent ce cas particulièrement trompeur : tailscale ping réussit (les pings disco contournent les ACL), et le trafic bloqué est abandonné plutôt que refusé, de sorte que le téléphone reste en attente et affiche un serveur hors ligne. Corrigez cela dans votre politique d'ACL (<https://login.tailscale.com/admin/acls> sur Tailscale ; votre fichier de politique sur Headscale). Cette vérification relève du meilleur effort et reste prudente : elle n'alerte que si le filtre de ce nœud n'autorise rien (ce qui peut aussi signifier qu'aucun autre appareil n'a encore rejoint le tailnet) et ne signale rien lorsqu'elle ne peut pas déterminer la situation.

La page se charge mais reste vide (page blanche, écran blanc) ; Les appels API échouent 403 cross-origin rejected. Vous accédez à Collie via une origine non prévue : un domaine personnalisé, ou un proxy qui réécrit Host. Autorisez l'origine publique exacte avec COLLIE_ALLOWED_ORIGINS (voir Configurer), ou configurez le proxy pour qu'il transmette Host sans modification (quatrième exigence pour le proxy dans docs/deployment.md).

Une invite sudo (ou phrase secrète SSH, ou gpg) n'accepte pas votre réponse. Utilisez Saisir dans la barre d'actions au-dessus du clavier, et non Send. Send vérifie ce qu'il a saisi en le relisant à l'écran avant d'appuyer sur Entrée (#34), or une invite de mot de passe désactive l'écho, il n'y a donc rien à relire. Saisir envoie directement vos frappes au volet, touche Entrée comprise. Rien de ce que vous saisissez dans Saisir n'est conservé, recopié dans un brouillon ou restauré plus tard, et dès que Collie reconnaît une invite de mot de passe, il supprime également le brouillon enregistré (#103).

Aucune notification push n'arrive. Déclenchez-en un manuellement : bin/collie push-test. Trois causes possibles, dans l'ordre où la commande les distingue : le push indique qu'il est désactivé (les clés n'ont jamais atteint le bridge ; exécutez push-keys et redémarrez, voir Web Push) ; il indique qu'aucun appareil n'est inscrit (ce téléphone ne les a jamais activées dans Paramètres → Alertes) ; ou il confirme un envoi mais rien n'arrive (le téléphone utilise une origine HTTP simple, qui n'est pas un contexte sécurisé ; Paramètres le signale insecure).

Collie a disparu après un redémarrage. Sur Linux, il s'agit presque toujours de lingering : exécutez loginctl enable-linger $USER (Persistance aux redémarrages). Sur macOS, l'agent launchd démarre au login ; vérifiez donc que vous êtes bien connecté (pas sur l'écran d'ouverture de session) et que l'agent est chargé : launchctl print gui/$(id -u)/herdr.collie.

Le terminal d'un panneau reste étroit, et une application plein écran y est écrasée (Copilot CLI, top, toute TUI dessinée dans une bande étroite pendant que le reste de la copie reste vide). Le terminal du panneau est simplement étroit, et Collie le reproduit fidèlement. La largeur d'un panneau Herdr provient de son rectangle dans la grille de découpe de l'onglet ; un panneau partageant un onglet obtient une part des colonnes. Herdr applique la géométrie du panneau uniquement lorsqu'un client desktop est connecté (herdr#1709) : sans client connecté, fermer une découpe laisse le panneau restant bloqué à l'ancienne largeur étroite, et pane.zoom ainsi que pane.resize via le socket ne le modifient pas non plus. Collie ne peut pas corriger cela de son côté ; il n'écrit pas du tout la géométrie du panneau (ADR 0031 : le téléphone ne redimensionne le terminal de l'opérateur qu'au toucher sur Afficher dans le terminal). Rien de tout cela n'est propre à l'application : top dans un panneau de 54 colonnes donne le même résultat. Pour le mesurer, exécutez tput cols dans le panneau. C'est la largeur réelle, qui peut différer de celle signalée par herdr pane layout. Pour corriger cela, connectez un client Herdr, puis zoomez ou redimensionnez le panneau à cet endroit (herdr pane zoom <pane-id> --on déplace le terminal une fois un client connecté), ou fermez le panneau et ouvrez-en un nouveau (#167).

Collie refuse d'ouvrir une fenêtre tmux (le nouvel onglet du téléphone revient avec un refus, indiquant window-size). Il ne s'agit pas d'une erreur dans la requête : sur les versions de tmux inférieures à 3.7, créer une fenêtre pendant que le window-size du serveur est manual fait planter tout le serveur (tmux #4849, corrigé dans la version 3.7), et un serveur planté emporte toutes les fenêtres avec lui. Collie refuse donc l'action et indique la version de tmux rencontrée. La solution est la ligne qu'il affiche (tmux set -g window-size latest sur ce serveur) ou tmux 3.7. Rien d'autre n'est affecté : toutes les autres actions sur ces panneaux continuent de fonctionner (Prérequis comporte la même réserve).

Collie consigne tmux list: output did not parse et le tableau de bord reste vide. Pas un crash : certaines versions de tmux (3.4, pas 3.6b) échappent le séparateur que cet adaptateur lit en sortie d'un listing -F. Collie lit désormais les deux formats, donc un listing qui donne zéro ligne est signalé comme une erreur mux au lieu d'être stocké comme un herd vide ; la ligne d'erreur indique la version de tmux et le nombre de lignes reçues. Une seconde cause venait de la locale : démarré sans locale UTF-8 (un conteneur minimal, une unité systemd), tmux remplace ce séparateur par _ au lieu de l'échapper. Collie exécute désormais chaque commande tmux avec -u, le listing ne dépend donc plus de LANG ni de LC_ALL. Si le problème persiste, notez la version de tmux -V et ouvrez un ticket ; la correction concerne l'adaptateur, pas votre .env.

herdr plugin list affiche l'ancienne version après un update. Comportement attendu : Herdr met en cache le manifeste lu au moment de l'installation ou du lien. La référence sur ce qui s'exécute est l'empreinte de build en bas de page, ou bin/collie version. Pour un clone lié, update recrée le lien et cela se corrige automatiquement (forcez-le avec herdr plugin link "$(pwd)") ; sur Herdr ≥0.8.0, le manifeste est de toute façon relu depuis le disque.

Le téléphone affiche une interface obsolète après une recompilation. Le cache du service worker d'une PWA dépend de l'origine. Accéder à Collie via deux origines différentes (un domaine personnalisé et le host:8787 brut) crée deux installations, chacune mettant en cache son propre bundle. Le tampon de build en bas de page (vX.Y.Z · sha · time) indique le bundle en cours d'exécution ; Collie signale ce qu'il sert via l'en-tête X-Collie-Build et /api/config. En cas de discordance, le bas de page propose « new build — tap to update. » Sinon, rouvrez la PWA à plusieurs reprises (le SW se met à jour automatiquement) ou effacez les données de site pour cette origine. Bonne pratique : choisissez une seule origine HTTPS et conservez-la. (En simple HTTP, le SW ne peut pas s'enregistrer : le contenu est toujours à jour, mais sans les fonctionnalités PWA.)

J'ai enregistré une machine dans Herdr et le téléphone ne l'affiche pas. Comportement attendu. Les machines enregistrées dans Herdr constituent la liste propre à son client, et un crew est propre à Collie ; aucune liste n'alimente l'autre. Pour joindre cette machine depuis le téléphone, enrôlez-la : collie crew add <ssh-host> sur le lead, puis collie restart sur le lead et collie crew status pour vérifier le lien. Ajouter ou supprimer une machine dans Herdr ne modifie rien dans le crew (Machines Herdr et le crew).

Un volet n'affiche aucun badge de prompt-cache. L'une des trois causes suivantes, et collie doctor permet de les distinguer. Le harness du volet n'a pas d'adaptateur de journal, ce que précisent ses lignes integration-<agent> et journal-roots. Le volet n'a jamais signalé de session, ce que sa ligne agent-sessions indique par l'identifiant du volet. Ou bien l'agent n'a pas encore pris son tour, ce qui n'est pas une anomalie : rien ne s'affiche avant d'avoir été mesuré, le badge apparaît donc à la première réponse de l'agent. Un harness dont le fournisseur ne publie aucune durée de vie de cache n'affiche rien non plus, et cache-claims liste chaque règle fournie par cette version.

L'historique d'un volet Kiro s'ouvre vide. Vérifiez que le Kiro du volet détient un verrou de session :

cat ~/.kiro/sessions/*/*/.lock

Herdr n'indique aucune session pour un volet Kiro ; Collie le repère donc via le verrou détenu par le Kiro en cours d'exécution. Cela fonctionne uniquement sur Herdr, le seul multiplexeur qui liste les processus de premier plan d'un volet, et uniquement lorsqu'un seul processus Kiro y est exécuté. Sinon, History indique que le volet ne possède aucune session d'agent.

Collie lit les sessions Kiro V3, démarrées avec --v3 ou --agent-engine v3, ou avec V3 défini comme moteur dans les paramètres de Kiro, relancez donc Kiro de cette manière dans ce volet. Kiro n'a aucun hook Herdr à installer. Si ses sessions se trouvent ailleurs, définissez kiro_root, puis exécutez collie restart.

Un panneau affiche le terminal là où vous attendiez Chat. Le chat est l'option par défaut pour un panneau d'agent, donc deux cas sont possibles. Cet appareil a choisi le terminal plus tôt : ouvrez le menu ⋮ du panneau et appuyez sur Vue Chat. Ou bien le panneau n'a pas de session ou pas de journal à lire. Un nouveau panneau affiche le chat avec « Envoyer un message pour démarrer » et bascule sur le terminal lorsque son premier tour se termine sans rien à lire, ou lorsqu'il pose d'abord une question ; la ligne du menu indique l'élément manquant, et l'entrée suivante contient les étapes.

Un panneau n'a ni Chat ni History, et le menu ⋮ indique que le panneau n'a nommé aucune session. Chat et History lisent le journal de session de l'agent, et Collie ne trouve ce journal que lorsque l'agent signale sa session via le multiplexeur. Sur Herdr, ce signalement provient de l'intégration propre à l'agent ; une intégration manquante ou obsolète masque donc les deux sans autre symptôme. collie doctor indique le panneau sous agent-sessions et le correctif sous integration-<agent>.

1. 01
   Exécutez herdr integration status. Si l'agent est not installed ou outdated, exécutez herdr integration install <agent>. Oh My Pi correspond à omp et pi à pi : chacun nécessite le sien.
2. 02
   Redémarrez l'agent dans ce panneau. Un agent charge son hook au démarrage ; un agent qui tournait pendant l'installation continue donc de ne rien signaler.
3. 03
   Si le hook est à jour et qu'un panneau redémarré ne signale toujours rien, vérifiez si l'agent a été lancé depuis un shell ouvert par un autre agent. Le hook d'Oh My Pi reste silencieux lorsque OMPCODE=1 est hérité de l'agent parent. Lancez-le depuis un terminal vierge.

Sur tmux, zellij et tern, seul Claude Code signale une session, via les hooks beacon de Collie. Exécutez collie hooks install claude (Collie écrit les hooks dans les paramètres de Claude). Les autres agents n'y ont ni Chat ni Historique.

Un nouveau panneau Codex indique qu'il n'a pas encore d'historique. Comportement attendu avant son premier tour. Codex ne signale sa session à Herdr que lors de l'envoi du premier prompt, pas à son démarrage ; un panneau récent n'a donc pas de session, ni de lien History, avant ce moment. collie doctor liste un tel panneau sous agent-sessions comme non encore signalé, et ne le compte pas comme une erreur. Si la note persiste après la réponse de Codex, ouvrez /hooks dans Codex. Quand ses hooks changent, Codex vous demande de les examiner, et « Continue without trusting » désactive le hook Herdr tandis que herdr integration status indique toujours qu'il est à jour. Faites confiance au hook à cet endroit, ou exécutez herdr integration install codex et démarrez une nouvelle session.

Le téléphone indique que Collie ne peut pas lire une boîte de dialogue, ou un envoi n'atteint pas la zone de saisie, alors que l'agent sur le poste affiche son prompt habituel. Collie a mal lu l'écran, en général parce que l'agent a modifié sa façon de l'afficher. Veuillez ouvrir un ticket avec le texte brut de l'écran, qui montre ce qu'une capture d'écran ne peut pas afficher (les couleurs et le texte estompé lus par Collie). Trouvez l'identifiant du panneau avec herdr pane list, puis exécutez

herdr pane read <pane-id> --source recent --lines 200 --format ansi > pane.txt

pendant que le téléphone affiche toujours le problème, puis joignez pane.txt ainsi que la version de l'agent (claude --version, codex --version, etc.). Le fichier correspond au texte du terminal : lisez-le d'abord et supprimez toute information privée.

L'envoi a échoué 3 fois et le téléphone propose un rapport. Trois envois consécutifs sur un volet ont échoué pour une raison imputable à Collie : il n'a pas pu lire ou écrire dans la zone de saisie, le texte a été inséré et Entrée n'a pas suivi, ou il a perdu la trace de l'envoi. Un refus qui vous protège (un brouillon dans la zone, un tour en cours, une boîte de dialogue ouverte) ne compte pas. Appuyez sur Rapport sur la carte. La feuille présente l'intégralité du problème avant que quoi que ce soit ne parte : les versions de Collie et de l'agent, le multiplexeur et les codes de chaque envoi échoué. Elle ne contient aucun texte saisi par vos soins ni aucune capture d'écran, sauf si vous activez Inclure ce que j'ai saisi ou Inclure l'écran. L'écran correspond aux 40 dernières lignes du volet avec les formes de secrets connues masquées ; lisez-le malgré tout, car le ticket est public. Ouvrir sur GitHub ouvre le formulaire prérempli dans votre navigateur, sous votre propre compte GitHub, et Copier le rapport copie le même texte. Appuyez d'abord sur Déjà signalé ? pour trouver un ticket avec la même ligne de signature. Le menu du volet et Paramètres → Système ouvrent la même feuille à tout moment. La croix ferme la carte sur ce volet jusqu'à ce qu'un envoi fonctionne à nouveau. Le volet d'un membre d'équipage ne propose pas encore de rapport ; utilisez les étapes ci-dessus.

Une mise à jour lancée depuis le téléphone reste bloquée à l'étape de staging. Sur Collie jusqu'à la version 1.6.0, une mise à jour déclenchée sur le téléphone pouvait préparer la nouvelle version puis s'arrêter : le runner effectuant le basculement n'était jamais démarré, le service continuait de servir l'ancienne version, et l'enregistrement de l'exécution restait à l'état staging avec le verrou actif. Trois éléments réunis le confirment : collie update --status indique staging (ou, après dix minutes, interrupted — the updater is gone), le répertoire de version de la nouvelle release existe sous versions/, et le journal du runner à ~/.config/collie/collie.log fait 0 octet. Un collie update saisi dans un shell sur la même machine fonctionnait toujours, ce qui correspond au même défaut vu sous un autre angle. Il est corrigé à partir de la release suivante : le passage de relais attend désormais la confirmation du runner par le gestionnaire utilisateur, et un passage de relais refusé est signalé comme un échec avec la raison fournie par le gestionnaire.

Pour débloquer une machine déjà coincée, ne faites rien pendant dix minutes : une exécution dont l'updater a disparu cesse de bloquer une nouvelle tentative dix minutes après sa dernière transition, et l'appui suivant fonctionne. Pour la débloquer immédiatement, supprimez l'enregistrement, le verrou et le fichier de progression du staging, puis vérifiez ce qu'indique --status :

collie update --status            # note the pid it names
ps -p <pid> -o command=           # empty output: the updater really is gone
rm -f ~/.local/state/collie/update.json ~/.local/state/collie/update.lock
rm -f ~/.local/state/collie/update-staging-*.log
collie update --status            # "no update has run on this install yet"

Aucune commande ne nettoie une exécution obsolète, et ces trois fichiers constituent l'intégralité de l'état laissé par un staging bloqué. Une instance avec suffixe les conserve dans ~/.local/state/collie-<name>/ à la place. Ne jamais supprimez ces fichiers pendant qu'une mise à jour est en cours d'exécution, et vérifiez d'abord le pid : un updater actif dont vous avez retiré le verrou modifiera current sans aucune protection. Ne touchez pas à versions/. Le répertoire de version partiellement préparé est inoffensif, la nouvelle tentative réécrit dedans, et le nettoyage de rétention supprime ce dont il n'a plus besoin.

Une mise à jour depuis le téléphone sur macOS laisse Collie non chargé. Exécutez ceci sur le Mac :

collie restart

Sur Collie jusqu'à la version 1.8.x, une mise à jour déclenchée depuis le téléphone pouvait arrêter l'agent launchd sans jamais le recharger ; le téléphone perdait alors le service et launchctl print gui/$(id -u)/herdr.collie ne trouvait rien. Le runner partageait le groupe de processus de l'agent, et redémarrer l'agent l'interrompait en cours d'exécution. collie restart réécrit le fichier plist de l'agent et le recharge. À partir de la version 1.9.0, le bridge démarre le runner dans sa propre session de processus. Si une mise à jour depuis le téléphone décharge encore l'agent après cela, exécutez la même commande et ajoutez une note sur #213.

Sur macOS, collie start se termine mais collie status indique « loaded, not running ». La tâche launchd est chargée et aucun processus ne tourne, le journal est donc vide. Démarrez la tâche manuellement :

launchctl kickstart gui/$(id -u)/herdr.collie
collie status

Une instance avec suffixe a son propre libellé, par exemple herdr.collie-next. À partir de la version 1.17.0, collie start et collie restart effectuent cette étape à votre place et affichent un avertissement contenant cette commande si aucun processus n'apparaît. Si la tâche reste à l'état « loaded, not running » après cela, consultez le journal avec collie logs, puis ajoutez une note sur #213.

Un agent est grisé sur la page Nouveau. La raison figure entre parenthèses après son nom. « not installed » signifie que la machine n'a pas trouvé la commande de l'agent dans le PATH utilisé par votre shell de connexion. Dans un shell de connexion sur cette machine, exécutez bash -lc 'command -v claude' (ou le nom de l'agent). Si rien ne s'affiche, installez l'agent à cet endroit, ou corrigez la ligne de votre fichier de connexion shell qui l'ajoute au PATH, puis rouvrez la page. Dans une équipe, vérifiez la machine sélectionnée : chaque membre regarde sur son propre disque. « this machine runs an older Collie » signifie qu'il faut mettre à jour ce membre (Démarrer un élément sur une machine). « needs Herdr » et « only on » suivi du nom d'une machine s'appliquent au commutateur Nouveau worktree, pas à un agent.

Start indique « There is no folder … on this machine », ou « could not confirm the start ». Le premier cas signifie que le dossier n'existe pas sur la machine effectuant le lancement ; rien n'a donc été lancé. Un nom sans / ni ~ initial désigne un dossier sous votre répertoire personnel, ainsi projects correspond à ~/projects. Créez le dossier, ou sélectionnez-en un dans Récent. Le second cas signifie que le téléphone n'a pas reçu la réponse. Vérifiez d'abord le tableau de bord, car le panneau peut déjà exister. Réessayer renvoie la même requête et n'ouvre jamais de second panneau (Démarrer un agent ou un shell depuis le téléphone).

Walky-talky

Six symptômes de walky talky reviennent le plus souvent. Chacun est associé à une commande qui en indique la cause (Walky-talky).

collie walky send indique « run this inside a pane, or send from the phone ». La commande a été exécutée en dehors du volet d'un agent, par exemple dans un terminal standard. Collie identifie l'expéditeur à partir de l'environnement propre au volet. Tout envoi hors d'un volet est refusé. Exécutez la commande dans le volet de l'agent, ou envoyez le message depuis le téléphone. Dans un volet d'agent, collie walky who associe votre volet à (you). L'erreur « no Collie bridge on this machine knows this pane » signifie qu'un autre Collie contrôle le volet. L'erreur « no running Collie bridge answers » signifie que le bridge est arrêté : exécutez collie status.

Le message indique « held » et n'est pas encore saisi. collie walky status <id> affiche « held: draft present » ou « held: turn running ». La zone de saisie contient un brouillon, ou l'agent travaille. Collie saisit le message lorsque la zone se libère ou que le tour se termine, dans la limite de 60 minutes. Ne le renvoyez pas. Pour le laisser entrer maintenant, envoyez ou effacez le brouillon dans ce panneau. Sous un lead plus ancien, « queued (outcome known on the lead) » signifie également d'attendre.

Le message reste dans la boîte de réception et n'a pas été saisi. collie walky status <id> affiche « waiting in the inbox, not typed » et la raison. « held past 60 minutes » signifie qu'un brouillon est resté dans la zone, que le panneau est resté occupé ou qu'une boîte de dialogue est restée ouverte pendant l'intégralité des 60 minutes de rétention : Collie ne tape jamais dans un brouillon ou un dialogue. « box not free » signifie que Collie n'a pas pu lire de zone de saisie libre. « pane busy » signifie qu'un message précédent était encore en cours de saisie après 2 minutes. « pane replaced » signifie qu'une autre session a pris le panneau pendant que le message attendait. « no terminal » et « bridge restarted » sont les deux autres cas. Exécutez collie walky inbox dans ce panneau, ou ouvrez Messages dans le menu du panneau sur le téléphone. Collie ne saisit pas le message à nouveau.

collie walky send indique « not sent: pane replaced ». L'adresse se termine par un jeton, tel que #k3f9, et le panneau qu'elle désignait est fermé. Un autre panneau détient désormais cet identifiant de panneau, Collie n'y saisit donc pas le message. Exécutez collie walky who et envoyez vers la nouvelle adresse. Une réponse indiquant « not sent: sender gone » a la même cause : le panneau qui a envoyé le message a été fermé, ou un autre panneau détient désormais son identifiant.

Un en-tête dans un panneau indique « no log record on this machine ». Le téléphone a trouvé un en-tête de talkie-walkie dans le texte à l'écran, et le journal de cette machine ne contient aucun message avec cet identifiant. Quelqu'un ou quelque chose a saisi la ligne, ou le journal l'a supprimée après 7 jours ou 2 000 lignes, ou un autre Collie la détient. Exécutez collie walky status <id> : « no record of <id> on this machine » le confirme. Pour un panneau situé sur un membre de l'équipe, exécutez-le sur ce membre : son journal est celui que le téléphone a lu. Traitez la ligne comme du texte brut, et demandez à l'expéditeur si vous en avez besoin.

La compétence est obsolète. collie doctor émet un avertissement sur la ligne skill-walky-talky, et l'agent suit d'anciennes instructions. Le texte d'un fichier d'instructions diffère de cette version. Exécutez collie skill status pour identifier le harnais qui est en retard. Exécutez collie skill status --check dans un script : il n'affiche rien et quitte avec le code 3 lorsqu'une copie est obsolète. Corrigez le problème avec collie skill install all, puis redémarrez l'agent. Une cible marquée refused est un lien symbolique ou possède des marqueurs endommagés, et une installation n'y touche jamais.

Agents durables

Un agent durable que vous avez rattaché possède ses propres vérifications, motifs et cas d'usage. Commencez par collie durable list et collie doctor, puis lisez Dépannage d'un agent durable.