Solução de problemas

Sintomas abaixo, em ordem — busque na página pelo seu. Os { NotFound } a partir de herdr plugin · update informa "not currently on a branch" · tailscale serve failed · não responde (o serviço não inicia) · o telefone não consegue abrir a URL · a página carrega mas fica vazia (página em branco, 403) · a solicitação de senha não aceita sua resposta · sem notificações push · desaparece após uma reinicialização · um painel fica travado estreito · Collie recusa abrir uma janela do tmux · tmux list: output did not parse · herdr plugin list mostra a versão antiga · interface desatualizada após uma recompilação · salvei uma máquina no Herdr e ela não aparece no celular · uma atualização iniciada pelo celular fica travada em staging · uma atualização pelo celular no macOS deixa o Collie descarregado · no macOS, collie status informa "loaded, not running" · um painel não mostra o chip prompt-cache · o Histórico de um painel Kiro abre vazio · um painel não tem Chat nem Histórico · um novo painel do Codex diz que ainda não tem histórico · o celular diz que o Collie não consegue ler uma tela que o agente não está exibindo · o envio falhou 3 vezes e o celular oferece um relatório · um agente está esmaecido na página New · Start diz que não há pasta, ou diz que não pôde confirmar · walky talky: o envio é recusado, "run this inside a pane" · walky talky: a mensagem fica na caixa de entrada e não foi digitada · walky talky: "no log record on this machine" · walky talky: a skill está desatualizada · um durable agent não aparece ou indica Unreachable.

herdr plugin … falha com Error: Os { code: 2, kind: NotFound, message: "No such file or directory" } (falha na instalação do plugin, falha na chamada da ação). Isso não é um problema do Collie; significa que o servidor Herdr não está rodando, portanto a CLI dele não consegue alcançar o socket de controle (~/.config/herdr/herdr.sock). O sinal evidente é o erro Os {…} bruto: um servidor alcançável responde a problemas de caminho/manifesto com JSON estruturado (ex.: plugin_manifest_not_found), portanto um Os { NotFound } puro indica falha na conexão do socket, antes de o Collie ou seu caminho serem sequer avaliados. Isso afeta link, install, action invoke (todos os subcomandos que conversam com o servidor), enquanto herdr plugin --help ainda funciona (ele nunca abre o socket). Solução: inicie o Herdr primeiro (herdr server &, ou apenas execute a TUI do Herdr, que inicializa o servidor), confirme que ls ~/.config/herdr/herdr.sock agora existe e tente a instalação novamente. herdr plugin list serve como teste rápido: se lançar o mesmo erro, o servidor está inativo.

update falha com You are not currently on a branch. Uma instalação pelo GitHub feita antes de 0.23.1 (#63): herdr plugin install desacopla em vez de clonar, portanto o update antigo não tinha uma branch para fazer git pull. A correção vem dentro do checkout que ela repara, portanto exige uma reinstalação para ser aplicada: Se falhar com "Você não está atualmente em uma ramificação" traz os três comandos.

start imprime note: tailscale serve failed. O Collie em si está funcionando (continua ativo em 127.0.0.1); apenas a entrada da tailnet não subiu, e o erro do próprio Tailscale aparece no terminal acima do aviso. Causas comuns: seu usuário não é o operador do Tailscale (sudo tailscale set --operator=$USER), o node está desconectado (tailscale up) ou, em domínios de tailnet do Headscale / .internal, certificados HTTPS não estão disponíveis, que é exatamente a finalidade de COLLIE_SERVE_MODE=http: defina essa variável em .env e execute bin/collie restart. Verifique com tailscale serve status.

serve diz HTTPS certificates are not enabled on this tailnet. Nada foi publicado e nada está em espera. Abra o console de administração, ative "Enable HTTPS" e execute collie serve novamente. Em domínios do Headscale / .internal não há certificados para ativar; use COLLIE_SERVE_MODE=http em vez disso.

O banner mostra ⚠ Collie isn't answering on :8787 yet (o serviço não inicia, conexão recusada). O serviço foi iniciado, mas o servidor HTTP não responde ao teste. Verifique a unidade primeiro (systemctl --user status collie) e depois consulte bin/collie logs (ou journalctl --user -u collie -f para monitorar em tempo real) para saber o motivo: na maioria das vezes, a porta já está em uso (defina COLLIE_PORT em .env e execute bin/collie restart, o que também executa tailscale serve novamente na nova porta) ou a primeira compilação falhou (o log indica isso; corrija e execute bin/collie build). A unidade reinicia automaticamente a cada 5 s, portanto, após corrigir a causa, ela geralmente se recupera sozinha.

O celular não consegue abrir a URL da tailnet. Siga a lista em ordem: (1) o celular executa o app do Tailscale e está conectado à mesma tailnet do host; (2) você está abrindo a URL tailnet do banner (bin/collie url), não a local (http://127.0.0.1:8787 só funciona no próprio host); (3) o MagicDNS está habilitado nas configurações de DNS da sua tailnet (a URL é um nome MagicDNS); (4) o host está online: verifique tailscale status no host ou envie um ping para o host pelo app do Tailscale no celular; (5) a política da sua tailnet realmente permite o acesso de um peer a este node (se não permitir, o banner avisa abaixo da linha tailnet, e nada mais vai indicar o erro: a porta de entrada foi publicada corretamente, o certificado é válido e curl a partir do próprio host retorna 200, pois o loopback nunca passa pelo filtro de pacotes). Dois fatores tornam esse caso bem confuso: tailscale ping tem sucesso (pings de descoberta ignoram ACLs) e o tráfego bloqueado é descartado em vez de recusado, fazendo o celular travar na espera e parecer que o servidor caiu. Corrija isso na sua política de ACL (<https://login.tailscale.com/admin/acls> no Tailscale; o arquivo de política no Headscale). A verificação opera em modo de melhor esforço e assume incerteza: ela só avisa se o filtro deste node admitir nada (o que também pode significar que nenhum outro dispositivo entrou na tailnet ainda) e permanece em silêncio quando não consegue determinar.

A página carrega, mas continua vazia (página em branco, tela branca); Chamadas de API falham 403 cross-origin rejected. Você está acessando o Collie por uma origem inesperada: um domínio personalizado ou um proxy que reescreve Host. Permita a origem pública exata com COLLIE_ALLOWED_ORIGINS (consulte Configuração) ou configure o proxy para encaminhar Host sem alterações (o quarto requisito de proxy em docs/deployment.md).

Um prompt de sudo (ou frase secreta SSH, ou gpg) não aceita sua resposta. Use Digitar na linha de ações acima do teclado, não Send. Send verifica o que digitou lendo de volta da tela antes de pressionar Enter (#34), e um prompt de senha desativa o eco, portanto não há nada para ler de volta; Digitar envia suas teclas digitadas direto para o painel, Enter incluído. Nada do que você digita em Digitar é armazenado, ecoado em um rascunho ou restaurado depois, e no momento em que o Collie reconhece um prompt de senha, ele também descarta o rascunho armazenado (#103).

Nenhuma notificação push chegando. Dispare uma manualmente: bin/collie push-test. Três causas, na ordem em que o comando as diferencia: o push informa que está desativado (as chaves nunca chegaram à bridge — execute push-keys e reinicie, consulte Web Push); ele informa que não há dispositivos inscritos (este telefone nunca os ativou em Configurações → Alertas); ou ele relata um envio e nada chega (o telefone está em uma origem HTTP simples, que não é um contexto seguro — Configurações sinaliza isso como insecure).

O Collie sumiu após uma reinicialização. No Linux isso é quase sempre lingering, então execute loginctl enable-linger $USER (Persistindo após reinicializações). No macOS o agente launchd inicia no login, então verifique se você está realmente conectado (não na tela de login) e se o agente está carregado: launchctl print gui/$(id -u)/herdr.collie.

O terminal de um painel está travado estreito, e um app em tela cheia dentro dele está espremido (Copilot CLI, top, qualquer TUI desenhada em uma faixa enquanto o restante do espelho permanece em branco). O terminal do painel é estreito assim, e o Collie o espelha fielmente. A largura de um painel do Herdr vem do seu retângulo na grade de divisão da aba, portanto um painel compartilhando uma aba recebe uma parte das colunas. O Herdr aplica a geometria do painel apenas enquanto um cliente desktop estiver anexado (herdr#1709): com nada anexado, fechar uma divisão deixa o sobrevivente travado na largura estreita antiga, e pane.zoom e pane.resize pelo socket também não o movem. O Collie não pode corrigir isso do lado dele; ele não grava a geometria do painel (ADR 0031: o celular move o terminal do operador apenas no toque de Exibir no terminal). Nada nisso é específico do app: top em um painel de 54 colunas parece idêntico. Para medir, execute tput cols no painel. Essa é a largura real, e ela pode discordar do que o herdr pane layout relata. Para corrigir, anexe um cliente Herdr, depois use o zoom ou redimensione o painel lá (herdr pane zoom <pane-id> --on move o terminal assim que algo estiver anexado), ou feche o painel e abra um novo (#167).

Collie recusa abrir uma janela do tmux (o nova aba do celular retorna recusando, informando window-size). Não é uma falha na requisição: no tmux anterior ao 3.7, criar uma janela enquanto o window-size do servidor for manual trava o servidor inteiro (tmux #4849, corrigido no 3.7), e um servidor travado leva todas as janelas junto. O Collie recusa a ação e informa o tmux encontrado. A correção é a linha que ele exibe — tmux set -g window-size latest nesse servidor — ou o tmux 3.7. Nada mais é afetado: qualquer outra ação nesses painéis continua funcionando (Requisitos traz o mesmo aviso).

O Collie registra tmux list: output did not parse e o painel fica vazio. Não é um travamento: algumas versões do tmux (3.4, não 3.6b) escapam o separador que este adaptador lê na saída de uma listagem -F. O Collie agora lê os dois formatos, portanto uma listagem analisada com zero linhas é reportada como um erro de mux em vez de ser armazenada como uma herd vazia; a linha de erro indica a versão do tmux e quantas linhas encontrou. Uma segunda causa era o locale: iniciado sem um locale UTF-8 (um contêiner mínimo, uma unidade do systemd), o tmux substitui esse separador por _ em vez de escapá-lo. Agora o Collie executa todos os comandos do tmux com -u, portanto a listagem não depende mais de LANG ou LC_ALL. Se ainda encontrar este problema, anote a versão do tmux -V e abra uma issue; a correção deve ser feita no adaptador, não no seu .env.

herdr plugin list mostra a versão antiga após um update. Esperado — o Herdr armazena em cache o manifesto lido na instalação ou vinculação. A autoridade sobre o que está em execução é o carimbo de compilação do rodapé, ou bin/collie version. Para um clone vinculado, update vincula novamente e isso se autocorrige (force com herdr plugin link "$(pwd)"); no Herdr ≥0.8.0 o manifesto é lido novamente do disco de qualquer forma.

O celular mostra uma UI desatualizada após uma recompilação. O cache do service worker de um PWA é por origem, portanto acessar o Collie em duas origens (um domínio personalizado e o host:8787 puro) gera duas instalações, cada uma armazenando seu próprio bundle em cache. O rodapé carimbo de compilação (vX.Y.Z · sha · time) mostra o bundle em execução; o Collie informa o que está servindo pelo cabeçalho X-Collie-Build e /api/config. Em caso de divergência, o rodapé oferece "nova versão — toque para atualizar." Caso contrário, reabra o PWA algumas vezes (o SW atualiza automaticamente) ou limpe os dados do site dessa origem. Prática recomendada: escolha uma origem HTTPS e mantenha ela. (Em HTTP simples o SW não registra — sempre atualizado, mas sem recursos de PWA.)

Salvei uma máquina no Herdr e o celular não mostra ela. Comportamento esperado. As máquinas salvas do Herdr são a lista do seu próprio cliente, e uma crew é a lista própria do Collie; nenhuma das listas alimenta a outra. Para acessar essa máquina pelo celular, registre ela: execute collie crew add <ssh-host> no lead, depois collie restart no lead e collie crew status para verificar a conexão. Adicionar ou remover uma máquina no Herdr não altera nada na crew (Máquinas do Herdr e a crew).

Um painel não mostra o chip prompt-cache. Uma de três coisas, e collie doctor as diferencia. O harness do painel não possui adaptador de journal, o qual suas linhas integration-<agent> e journal-roots informam. O painel nunca relatou uma sessão, a qual sua linha agent-sessions lista por id do painel. Ou o agente ainda não realizou uma ação, o que não é uma falha: nada é exibido antes de ser medido, então o chip aparece na primeira resposta do agente. Um harness cujo fornecedor não publica a duração do cache também não mostra nada, e cache-claims lista todas as regras que este build inclui.

O Histórico de um painel Kiro abre vazio. Verifique se o Kiro do painel mantém um bloqueio de sessão:

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

O Herdr não dá nome de sessão a um painel Kiro, então o Collie o encontra pelo bloqueio mantido pelo Kiro em execução. Isso funciona apenas no Herdr, o único multiplexador que lista os processos em primeiro plano de um painel, e apenas quando exatamente um processo do Kiro está rodando ali. Caso contrário, o Histórico informa que o painel não tem sessão de agente.

O Collie lê sessões Kiro V3, iniciadas com --v3 ou --agent-engine v3, ou com V3 configurado como o motor nas próprias configurações do Kiro; portanto, reinicie o Kiro dessa maneira naquele painel. O Kiro não tem hook do Herdr para instalar. Se as sessões dele ficarem em outro local, defina kiro_root e depois execute collie restart.

Um painel mostra o terminal onde você esperava o Chat. O Chat é o padrão para um painel de agente, portanto uma de duas situações se aplica. Este dispositivo escolheu o terminal anteriormente: abra o menu ⋮ do painel e toque em Visualização de chat. Ou o painel não tem sessão ou log para leitura. Um novo painel exibe o Chat com "Send a message to start" e volta para o terminal quando seu primeiro turno termina sem nada para ler, ou quando ele faz uma pergunta primeiro; a linha do menu informa qual parte está ausente, e a entrada seguinte contém as instruções.

O Chat e o History do Um painel não tem Chat nem History, e o menu ⋮ informa que o painel não indicou nenhuma sessão. leem o log de sessão do agente, e o Collie só encontra o log quando o agente relata sua sessão por meio do multiplexador. No Herdr, esse relatório vem da própria integração do agente; portanto, se ela estiver ausente ou desatualizada, ambos ficam ocultos sem nenhum outro sintoma. collie doctor indica o painel em agent-sessions e a correção em integration-<agent>.

1. 01
   Execute herdr integration status. Se o agente for not installed ou outdated, execute herdr integration install <agent>. Oh My Pi é omp, e pi é pi: cada um precisa do seu próprio.
2. 02
   Reinicie o agente nesse painel. Um agente carrega seu hook ao iniciar, portanto, um que estava em execução durante a instalação continuará sem relatar nada.
3. 03
   Se o hook estiver atualizado e um painel reiniciado ainda não relatar nada, verifique se o agente foi iniciado a partir de uma shell aberta por outro agente. O hook do Oh My Pi permanece silencioso quando OMPCODE=1 é herdado do agente pai. Inicie-o a partir de um terminal novo.

No tmux, zellij e tern, apenas o Claude Code relata uma sessão, por meio dos beacon hooks do Collie. Execute collie hooks install claude (O Collie grava hooks nas próprias configurações do Claude). Os outros agentes não têm Chat nem History lá.

Um novo painel do Codex diz que ainda não tem histórico. Esperado até o primeiro turno. O Codex informa a sessão ao Herdr apenas quando o primeiro prompt é enviado, não quando inicia, portanto um painel recém-criado não tem sessão nem link de History até então. O collie doctor lista esse painel em agent-sessions como ainda não informado e não o considera uma falha. Se o aviso continuar ali depois que o Codex responder, abra /hooks no Codex. Quando seus hooks mudam, o Codex pede para você revisá-los, e "Continue without trusting" desativa o hook do Herdr enquanto herdr integration status ainda diz que ele está atualizado. Confie no hook ali ou execute herdr integration install codex e inicie uma nova sessão.

O celular diz que o Collie não consegue ler um diálogo, ou um envio não chega à caixa de entrada, enquanto o agente no computador mostra o prompt normal. O Collie leu a tela incorretamente, geralmente porque o agente mudou a forma como a desenha. Abra uma issue com o texto bruto da tela, que mostra o que uma captura de tela não consegue mostrar (as cores e o texto esmaecido que o Collie lê). Encontre o id do painel com herdr pane list e execute

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

enquanto o celular ainda mostrar o problema, e anexe pane.txt junto com a versão do agente (claude --version, codex --version e assim por diante). O arquivo contém o texto do terminal, portanto leia-o antes e remova informações privadas.

O envio falhou 3 vezes e o celular oferece um relatório. Três envios seguidos em um painel falharam por um motivo atribuído ao Collie: ele não conseguiu ler ou escrever na caixa de entrada, o texto entrou e o Enter não seguiu, ou o envio se perdeu. Uma recusa de proteção (um rascunho na caixa, um turno em execução, um diálogo aberto) não conta. Toque em Relatório no card. O painel deslizante exibe a issue inteira antes do envio: as versões do Collie e do agente, o multiplexador e os códigos de cada envio com falha. Ele não inclui textos digitados nem telas, a menos que você ative Incluir o que digitei ou Incluir a tela. A tela corresponde às últimas 40 linhas do painel com formatos de segredos conhecidos mascarados; leia mesmo assim, pois a issue é pública. Abrir no GitHub abre o formulário preenchido no seu navegador, na sua própria conta do GitHub, e Copiar relatório copia o mesmo texto. Toque em Já foi relatado? primeiro para buscar uma issue com a mesma linha de assinatura. O menu do painel e Configurações → Sistema abrem o mesmo painel deslizante a qualquer momento. O X fecha o card nesse painel até que um envio funcione novamente. O painel de um crew member ainda não oferece relatório; use as etapas acima.

Uma atualização iniciada pelo celular fica travada em staging. No Collie até a versão 1.6.0, uma atualização acionada no celular podia preparar a nova versão e parar em seguida: o runner que executa a troca nunca era iniciado, o serviço continuava servindo a versão antiga e o registro de execução ficava parado em staging mantendo o lock. O indício é a combinação de três fatos: collie update --status reporta staging (ou, após dez minutos, interrupted — the updater is gone), o diretório da nova versão existe em versions/ e o log do runner em ~/.config/collie/collie.log tem 0 bytes. Executar collie update em um shell na mesma máquina sempre funcionou, sendo o mesmo defeito visto pelo outro lado. Isso foi corrigido a partir da versão seguinte: a transferência agora aguarda o gerenciador de usuários confirmar o runner, e uma transferência recusada é reportada como falha com o motivo informado pelo próprio gerenciador.

Para destravar uma máquina que já está nesse estado, não faça nada por dez minutos: uma execução cujo atualizador sumiu deixa de bloquear uma nova tentativa dez minutos após sua última transição, e o próximo toque prossegue. Para destravar agora, exclua o registro, o lock e o arquivo de progresso de staging, depois verifique o que --status informa:

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"

Não existe um comando para limpar uma execução travada, e esses três arquivos representam todo o estado deixado para trás por um staging interrompido. Uma instância com sufixo mantém eles em ~/.local/state/collie-<name>/. Nunca exclua esses arquivos enquanto uma atualização estiver de fato em execução, e verifique o pid antes: um atualizador ativo cujo lock foi removido vai alterar current sem nada para protegê-lo. Não mexa em versions/. O diretório da versão preparado pela metade é inofensivo, a nova tentativa constrói nele novamente e a rotina de retenção remove o que não for mais necessário.

Uma atualização pelo celular no macOS deixa o Collie descarregado. Execute isto no Mac:

collie restart

No Collie até a versão 1.8.x, uma atualização acionada pelo telefone podia parar o agente do launchd e nunca mais carregá-lo; assim, o telefone perdia o serviço e o launchctl print gui/$(id -u)/herdr.collie não encontrava nada. O executor compartilhava o grupo de processos do agente, e reiniciar o agente o encerrava pelo caminho. O collie restart grava o plist do agente novamente e o carrega. A partir da versão 1.9.0, a ponte inicia o executor em uma sessão de processo própria. Se uma atualização pelo telefone ainda descarregar o agente depois disso, execute o mesmo comando e adicione uma observação em #213.

No macOS, collie start termina, mas collie status diz "loaded, not running". O job do launchd está carregado e nenhum processo está em execução, portanto o log está vazio. Inicie o job manualmente:

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

Uma instância com sufixo tem seu próprio rótulo, por exemplo herdr.collie-next. A partir da versão 1.17.0, collie start e collie restart fazem essa etapa para você e exibem um aviso com este comando quando nenhum processo aparece. Se o job continuar em "loaded, not running" depois disso, leia o log com collie logs e adicione uma observação em #213.

Um agente está esmaecido na página New. O motivo aparece após o nome entre colchetes. "not installed" significa que a máquina não encontrou o comando do agente no PATH que sua shell de login usa. Em uma shell de login nessa máquina, execute bash -lc 'command -v claude' (ou o próprio nome do agente). Se não imprimir nada, instale o agente nela ou corrija a linha no arquivo de login da sua shell que o adiciona ao PATH, e reabra a página. Em uma crew, verifique a máquina que você escolheu: cada membro busca em seu próprio disco. "this machine runs an older Collie" significa atualizar esse membro (Iniciando algo em uma máquina). "needs Herdr" e "only on" o nome de uma máquina pertencem à opção Nova worktree, não a um agente.

Start diz "There is no folder … on this machine", ou "could not confirm the start". O primeiro significa que a pasta não está na máquina que executa a inicialização, portanto nada foi iniciado. Um nome sem / ou ~ no início é uma pasta sob sua home, logo projects significa ~/projects. Crie a pasta ou escolha uma em Recent. O segundo significa que o telefone perdeu a resposta. Olhe no dashboard primeiro, pois o painel pode existir. Tentar novamente envia a mesma requisição e nunca abre um segundo painel (Inicie um agent ou shell pelo telefone).

Walky talky

Seis sintomas do walky talky ocorrem com mais frequência. Cada um tem um comando que mostra a causa (Walky talky).

collie walky send informa "run this inside a pane, or send from the phone". O comando foi executado fora do painel de um agente, por exemplo em um terminal comum. O Collie identifica o remetente a partir do próprio ambiente do painel. Um envio sem painel é recusado. Execute o comando no painel do agente ou envie pelo celular. Em um painel de agente, collie walky who marca seu painel com (you). O erro "no Collie bridge on this machine knows this pane" significa que outro Collie controla o painel. O erro "no running Collie bridge answers" significa que a bridge está fora do ar: execute collie status.

A mensagem indica "held" e ainda não foi digitada. collie walky status <id> exibe "held: draft present" ou "held: turn running". A caixa contém um rascunho, ou o agente está trabalhando. O Collie digita a mensagem quando a caixa for limpa ou o turno terminar, em até 60 minutos. Não a envie novamente. Para liberá-la agora, envie ou limpe o rascunho nesse painel. Sob um lead mais antigo, "queued (outcome known on the lead)" também significa aguardar.

A mensagem permanece na inbox e não foi digitada. collie walky status <id> exibe "waiting in the inbox, not typed" e o motivo. "held past 60 minutes" significa que um rascunho permaneceu na caixa, o painel continuou ocupado ou uma caixa de diálogo permaneceu aberta durante toda a retenção de 60 minutos: o Collie nunca digita dentro de um rascunho ou diálogo. "box not free" significa que o Collie não conseguiu ler uma caixa de entrada livre. "pane busy" significa que uma mensagem anterior ainda estava sendo digitada ali após 2 minutos. "pane replaced" significa que outra sessão assumiu o painel enquanto a mensagem aguardava. "no terminal" e "bridge restarted" são os outros dois motivos. Execute collie walky inbox nesse painel ou abra Messages no menu do painel no celular. O Collie não digita a mensagem novamente.

collie walky send informa "not sent: pane replaced". O endereço termina com um token, como #k3f9, e o painel indicado foi fechado. Outro painel contém esse id de painel agora, portanto o Collie não digita a mensagem lá. Execute collie walky who e envie para o novo endereço. Uma resposta que retorna "not sent: sender gone" tem a mesma causa: o painel que enviou a mensagem foi fechado, ou outro painel agora detém o id dele.

Um cabeçalho em um painel exibe "no log record on this machine". O celular encontrou um cabeçalho de walky talky no texto da tela, e o log desta máquina não contém nenhuma mensagem com esse id. Alguém ou algo digitou a linha, ou o log a descartou após 7 dias ou 2.000 linhas, ou outro Collie a mantém. Execute collie walky status <id>: "no record of <id> on this machine" confirma isso. Para um painel em um membro da crew, execute o comando nesse membro: o log dele é o que o celular leu. Trate a linha como texto simples e pergunte ao remetente se precisar dela.

A skill está desatualizada. collie doctor emite um aviso na linha skill-walky-talky, e o agente segue orientações antigas. O texto em um arquivo de instruções difere desta compilação. Execute collie skill status para ver qual harness está desatualizado. Execute collie skill status --check em um script: ele não exibe nada e sai com o código 3 quando uma cópia está desatualizada. Corrija isso com collie skill install all e reinicie o agente. Um destino marcado como refused é um link simbólico ou tem marcadores danificados, e uma instalação nunca o altera.

Durable agents

Um durable agent conectado por você tem suas próprias verificações, motivos e casos. Comece com collie durable list e collie doctor, depois leia Solução de problemas de um durable agent.