Vibe coding para testar retomada matando o app de verdade: a camada certa

Um teste de retomada só prova alguma coisa se aquilo que você reiniciou for aquilo que carrega o seu código. Reinicie a camada errada e o app abre, a tela aparece no lugar esperado, o teste passa, e o que você observou foi o comportamento de antes da sua última mudança.

Na live em que o Fumava parou de abrir depois de um SQL, isso apareceu pelo avesso. O erro na tela tinha cara de dependência faltando, e foi por aí que Martin começou. O agente apontou outro culpado: o processo que entrega o JavaScript ao app continuava rodando desde antes, com o mapa de arquivos de antes, e não enxergava nada do que tinha entrado depois.

O erro que parece pacote faltando

Um processo que já estava no ar leu os arquivos uma vez, montou uma ideia do projeto e passa a servir aquela ideia. Quando você mexe no que está embaixo dele, ele responde com o que conhece, e o que ele conhece está velho. A mensagem que chega até você fala de algo que não foi encontrado, que é exatamente a cara de biblioteca ausente.

O tempo se perde procurando o bug no lugar errado. Você abre o gerenciador de pacotes, confere versão, reinstala, olha configuração, e nada disso toca o culpado, que está fora dos arquivos: é um processo ainda no ar, servindo uma leitura antiga do projeto.

2 camadas com ciclos de vida diferentes

A explicação que o agente deu na live:

"O [bundler] que entrega o seu código JavaScript ao app ao vivo. O app instalado é casca nativa. Ele só muda quando você roda [de novo]."

São 2 coisas empilhadas que envelhecem em ritmos diferentes. O JavaScript é servido ao vivo, então reiniciar quem serve basta para o código novo chegar ao aparelho. A casca nativa instalada não recebe nada ao vivo, e só muda com uma compilação nova.

Isso corta nos 2 sentidos. Reiniciar o emulador não troca o JavaScript se o processo velho continuar servindo o mesmo mapa, e reiniciar esse processo não traz mudança nativa nenhuma, por mais vezes que você repita. Na live esse mesmo raciocínio economizou trabalho: o emulador podia ficar aberto e o app podia continuar instalado, porque só o processo que serve o código precisava morrer.

A pergunta que o vibe coding pede antes do teste

Antes de fechar e abrir qualquer coisa, responda uma pergunta: o que eu mudei mora em qual camada? Mexi só no código interpretado, então reinicio quem serve esse código. Mexi em dependência ou em configuração nativa, então compilo de novo e instalo de novo.

Quando essa resposta está errada, o que você vê é um app que abriu bonito, uma tela que ficou onde você queria e um resultado em que passa a acreditar. O engano dura justamente porque o teste devolve verde, e ninguém investiga um verde.

No vibe coding o buraco é mais fundo, porque o ciclo é curto e o agente devolve mudança rápido. Você pede, recebe, testa, pede de novo. Se o teste do meio mediu a versão anterior, as instruções seguintes que você escreve ao agente saem de uma leitura errada do que está acontecendo, e você vai pedir correção para um problema que já não existe. Foi o mesmo caminho de vibe coding para testar paywall. O mesmo problema apareceu em vibe coding para testar assinatura com entitlement de 1 dia.

Quando o teste é de retomada, mate o app de verdade

Retomada engana mais que os outros testes porque parece trivial. Sair da tela e voltar não é garantia de que o app morreu, e o teste honesto é encerrar o processo antes de abrir de novo. O bug de onboarding que deu origem a essa preocupação está contado em retomar onboarding de onde parou.

A regra vale longe de aplicativo. Sempre que existir um processo de longa duração servindo o seu código, o estado dele é uma variável do teste. Vale para servidor de desenvolvimento, worker, container e cache de build. O que aparece na sua tela é a soma do que você escreveu com aquilo que o processo ainda carrega de antes, e você não controla a segunda parcela enquanto ele estiver vivo.

Na gravação a sequência aparece inteira: o app que não abria, o palpite da dependência, o diagnóstico do processo antigo e o app de pé outra vez. Dá para assistir à live.

Antes de confiar no próximo teste, faça 2 perguntas. O que mudou desde a última vez que este processo subiu? E esse processo leu a mudança, ou está servindo a versão que leu quando nasceu? Sem resposta para as duas, mate o processo, suba de novo e só então olhe para a tela. Essa é a disciplina barata que sustenta o resto do vibe coding: o agente escreve o código, e a conferência de que você está olhando para o código certo continua sendo sua.