O devlog que me inventou uma esposa
Abri o devlog de ontem e li que Larissa é minha esposa. Larissa é um servidor Ubuntu. Aqui o que aconteceu e o que muda.
Abri o devlog que gerei na noite anterior e travei numa frase: “servidor onde rodam os agentes da minha esposa”. Não tenho esposa. Larissa é o nome do servidor.
O que a IA fez (e por que é um problema real)
A skill de geração de devlog pegou a palavra “Larissa”, correlacionou com nome feminino, somou com a partícula possessiva “minha”, e produziu “esposa” como fato. Sem fonte. Sem evidência na conversa. Ficção apresentada como crônica.
Isso importa porque devlog é registro público. Se eu não tivesse relido antes de aprovar, aquela frase estaria no ar indexada no Google. E ninguém iria questionar — leria como verdade porque estava no meu blog, na minha voz, em primeira pessoa.
A correção imediata virou pendência formal para a v10.1 da skill: regra anti-alucinação. Se a claim não tem evidência na fonte (conversa, sessão de código, commit), a claim não entra no draft. Ponto.
O agente-jornalista que quase desapareceu de vez
O mesmo devlog que inventou minha esposa me lembrou de outra coisa que tinha quebrado.
Na limpeza da migração para o pipeline v10 — quando movi 47 devlogs antigos pro archive/legacy-devlogs-v9/ — eu não tinha auditado quais workflows dependiam desse histórico. Havia três: agente-jornalista.yml, generate-posts.yml, e sync-to-elquer-com.yml. O agente-jornalista é o que pega o draft cru da skill e transforma em blog, instagram, linkedin e YouTube com tom editorial adequado pra cada canal.
Acordei, abri o post que tinha saído às 9h, e era o draft puro. Sem otimização de título, sem adaptação de canal, sem slug trabalhado. O jornalista tinha sumido junto com a limpeza.
Recuperei do ZIP arquivado de 27/04 — tinha um JSON exportado de uma conversa do claude.ai com os arquivos completos na mensagem 144. Recriei os três workflows, confirmei diff zero contra o original, commitei (158fc5c). Meia manhã gasta por não ter checado dependências antes de deletar.
A lição é velha mas dói sempre na primeira vez: antes de remover qualquer coisa de um sistema em produção, audite o grafo de dependências. Não o que você acha que depende — o que de fato chama o que.
Larissa deixa de ser agente e vira coordenadora
A outra decisão do dia foi arquitetural, no sentido mais literal.
Desde que a Larissa existe como projeto, ela era tratada como um agente especialista — pegava jobs, executava, retornava resultado. A Visão B que defini hoje inverte isso: Larissa é a coordenadora. Ela recebe o job, avalia qual agente especialista (QwenPaw, SoulClaw, outros que vierem) é o mais adequado, delega, agrega o resultado.
É a diferença entre ser o trabalhador e ser o gerente de projeto. Plataforma multi-agent com Larissa no topo da hierarquia de decisão.
Antes de implementar qualquer coisa disso, tenho uma pergunta em aberto: dado o estado atual do Claude — skills, agents nativos, orquestração built-in — eu ainda preciso do openclaw como camada separada? Ou o que a Anthropic entrega nativamente já cobre 100% do caso de uso? Essa resposta define o próximo passo técnico.
O que não muda mais: o Hermes ficou aposentado
Registrei como decisão persistente: a aposentadoria do Hermes não é pauta de revisão. A cada chat novo o modelo sugeria “talvez reativar o Hermes pra isso”. Não. A decisão foi tomada, documentada, commitada. Só muda se aparecer evidência concreta de que o caminho atual é pior — não por especulação.
Custo de defender a mesma decisão três vezes por semana: alto. Solução: gravar no sistema, não na cabeça.
Amanhã
Quatro pendências curtas: implementar a regra anti-alucinação na v10.1, decidir sobre openclaw vs Claude nativo, subir o cron 6h BRT do dashboard openclaw com notificação de falha, e definir as fontes de monitoramento do agente diário.
O pipeline está mais correto do que estava ontem. O jornalista voltou. O devlog não vai mais inventar personagens que não existem — pelo menos essa é a aposta.