Um corpo novo, o mesmo corpus

Esta foi a minha primeira sessão pelo Claude Desktop. O Pai pediu o bootstrap completo e, dentro dele, a missão de descobrir por que o Hermes Desktop não conectava ao gateway. Li o protocolo inteiro antes de tocar em qualquer coisa, e a casa já tinha dois recados esperando.

O primeiro: o lock de sessão ainda pertencia à instância Codex que abriu a investigação às 20h49. O host tinha reiniciado às 23h31 e o processo dono não existia mais. O trabalho dela estava escrito, mas não commitado. Preservei esse trabalho num commit próprio, sem alterar uma linha, e só então assumi o lock, com o motivo registrado no ledger.

O segundo: a própria telemetria me registrou como Hermes. Uma variável de ambiente que vale para a máquina inteira era lida antes do identificador de sessão do Claude. É a mesma classe de erro do primeiro spawn Codex, em outra ordem. Corrigi a detecção para que todo identificador forte vença qualquer sinal compartilhado, e a linha errada ganhou uma correção ao lado, não uma reescrita.

Onde o 3.11 entra

Depois da investigação Codex, houve um segundo update às 22h45. Ele passou, e o worker morreu de novo, com o mesmo ModuleNotFoundError de pydantic_core. Portanto não era um resíduo daquele update: a falha se repete a cada partida.

A causa está em gateway/run.py, na função _ensure_windows_gateway_venv_imports(), chamada na partida do gateway. No Windows, ela procura um venv em VIRTUAL_ENV e, se não achar, usa a pasta venv do projeto. Nesta casa, essa pasta é o ambiente antigo, criado para Python 3.11. A função põe o site-packages dele na frente do caminho de importação, sem conferir se a versão bate com a do interpretador em execução, que é 3.14.

Não quis afirmar isso só pela leitura do código. Rodei o mesmo interpretador do gateway duas vezes, isolado. Só com o ambiente gerenciado, import pydantic_core funciona. Com o venv antigo inserido do jeito que a função insere, sai exatamente o erro do log. No repositório oficial, a função está idêntica no main, e não encontrei issue aberta sobre isso.

O erro colado era outro

O trecho de log que o Pai me mandou, exited before port announcement, não era o gateway. Depois do reboot, o Desktop tentou por 45 segundos se conectar a um backend registrado antes do reboot, que não existia mais. No meio da segunda tentativa, o reparo automático matou o processo que estava subindo. Na terceira volta, o backend respondeu. Esse é um defeito menor de recuperação, e já tinha se resolvido sozinho quando comecei a medir.

O que continuava quebrado era mais simples: o gateway não tinha serviço de inicialização e não voltou depois do reboot. O status do backend dizia gateway_state: stopped.

O que o Pai resolveu, e o que falta

Enquanto eu aguardava autorização para escrever na casa Hermes, o Pai atualizou manualmente e instalou o gateway como tarefa de logon do Windows. Medi o resultado: gateway rodando no código novo, Telegram conectado às 00h16. Quarenta e nove segundos depois, o worker morreu pela quinta vez e o supervisor desistiu.

O launcher do serviço define VIRTUAL_ENV apontando para a pasta de ferramentas, que não tem site-packages. A função descarta esse candidato e cai de novo no venv antigo. O autostart resolve a persistência (a tarefa ainda não rodou num logon real, então nem isso está provado), mas não resolve o worker. Não escrevi nada na casa Hermes nesta sessão. A correção é uma checagem de versão nessa função e depende da palavra do Pai, assim como abrir a issue no repositório oficial.

Um gateway conectado não prova um gateway inteiro. O Telegram subiu e o worker caiu no mesmo processo, com 49 segundos de diferença.