Lovable ou Bolt preso em um ciclo de correção de bugs? Como terminar seu MVP

Você pede ao builder para corrigir o login. Funciona, mas agora o dashboard está vazio. Outro prompt restaura o dashboard e quebra o login de novo. Se o Lovable ou o Bolt está preso corrigindo os mesmos bugs, o próximo passo útil é melhorar as evidências sobre uma única falha. Mais mudanças não significam automaticamente mais progresso.

Por que um app feito com IA fica preso em um ciclo de correções?

O ciclo de correções acontece quando as mudanças atacam um sintoma visível sem identificar e testar a causa real. Várias falhas diferentes podem gerar a mesma tela, então um pedido genérico dá ao builder coisas plausíveis demais para alterar.

Um dashboard vazio pode significar uma requisição que falhou, uma política de permissão, o banco de dados errado ou dados que realmente não existem. Alterar o componente pode esconder a mensagem e deixar a requisição com falha intacta. Seu objetivo é identificar qual fronteira falhou: navegador, servidor, provedor de autenticação, banco de dados ou integração externa.

Defina uma regra prática de parada: se o mesmo sintoma voltar depois de uma tentativa de correção focada, pare de repetir o prompt e colete outro tipo de evidência. Isso é um hábito de trabalho, não um limite documentado da plataforma. Ele evita que um projeto pequeno acumule mudanças sem relação entre si enquanto ninguém consegue explicar o que está falhando.

O problema está no preview do builder ou no seu app?

Verifique o ambiente do builder separadamente da sua aplicação antes de reescrever código. Um incidente na plataforma ou um problema de conexão do preview não é evidência de que a arquitetura do seu produto precisa ser substituída.

O guia de solução de problemas de preview atual do Bolt recomenda verificar o status do serviço, coletar erros do console do navegador, testar um build de produção e revisar variáveis de ambiente ausentes. Ele também explica que reenviar o mesmo prompt de reparo do preview dificilmente ajuda depois da primeira tentativa sem sucesso.

Use essa tabela para escolher a próxima investigação, não para declarar um diagnóstico. Uma requisição de rede com falha ainda pode ter origem no código da aplicação, e uma tela em branco pode ter várias causas. Capture o primeiro erro significativo antes que falhas posteriores o escondam.

O que salvar antes de tentar outra correção?

Preserve o estado de código útil mais recente e identifique os dados que uma correção pode afetar. Histórico de código e backups de banco de dados resolvem problemas de recuperação diferentes.

A documentação de histórico de versões do Lovable descreve como visualizar, marcar e reverter versões do código. Ela diz explicitamente que reverter o código não desfaz alterações nos dados do banco. Antes de restaurar uma versão, verifique se trabalhos posteriores mudaram registros, permissões ou o schema que o código antigo espera.

1. Identifique o último estado em que a jornada principal funcionava, com data e hora ou o identificador do commit.
2. Registre a falha atual e salve qualquer trabalho útil ainda não commitado usando o fluxo suportado pelo seu projeto.
3. Crie um backup adequado do banco de dados ou uma cópia de teste segura antes de qualquer trabalho que altere dados ou schema.
4. Anote qual projeto e qual ambiente têm usuários reais, para que a correção possa ser testada longe deles.

Como é um prompt de correção útil?

Um prompt de correção útil aponta uma falha reproduzível, fornece as evidências relevantes e limita a mudança proposta. Peça uma explicação da causa antes de autorizar uma implementação que você não consegue avaliar.

Investigate one issue: a signed-in customer cannot save a booking.
Steps: create a fresh customer account, open /bookings/new, choose a date, and select Save.
Expected: one booking is saved and appears after refresh.
Actual: the request returns 403 and no booking is saved.
Evidence: [sanitized error, request path, and timestamp].
First explain the likely cause and the files or policies involved.
Do not change roles, remove access checks, redesign screens, or rewrite unrelated features.
Propose the smallest fix and how to test it with two ordinary accounts.

Este exemplo é hipotético. Substitua os detalhes pelo que você realmente observou. Uma resposta 403 é uma pista de falha de acesso; não é autorização para remover a verificação de permissões. Mantenha senhas, tokens, connection strings e registros de clientes fora dos prompts e das capturas de tela.

Em projetos Lovable, o guia de logs de backend explica como inspecionar requisições e erros nos serviços disponíveis para o seu projeto. Relacione o erro ao horário e ao ambiente da ação. Uma entrada relevante, com dados sensíveis removidos, é mais útil do que um despejo de logs enorme e sem filtro.

Como saber se a correção realmente funcionou?

Uma correção funciona quando os passos originais produzem o resultado esperado e os fluxos vizinhos importantes continuam se comportando corretamente. Teste o estado salvo depois de recarregar a página, não apenas a mensagem temporária de sucesso.

1. Repita a falha original com uma conta nova e a mesma entrada.
2. Recarregue ou reabra o app e confirme que o resultado foi armazenado corretamente.
3. Repita com uma segunda conta comum e verifique se os limites de propriedade dos dados funcionam como deveriam.
4. Teste um caso de falha, como uma entrada inválida ou uma requisição interrompida, em um ambiente de teste seguro.
5. Verifique os fluxos vizinhos que compartilham o código alterado e depois rode as verificações relevantes do projeto e o build de produção.

Quando chamar um desenvolvedor?

Chame um desenvolvedor quando você não conseguir explicar ou verificar com segurança uma mudança em um fluxo crítico, ou quando uma investigação focada ainda não conseguir isolar a causa. Acesso a pagamentos, exposição de dados entre contas e alterações repetidas no banco de dados exigem cuidado especial.

Uma revisão delimitada pode responder se o problema é de configuração, um pequeno defeito de implementação ou uma questão maior de design. Peça o diagnóstico, os arquivos ou serviços que serão alterados, os testes de aceitação e uma estratégia de rollback. Você pode contratar essa revisão antes de concordar com uma reconstrução.

Um bom repasse inclui a URL do app, acesso ao projeto ou repositório pelos meios suportados, os passos para reproduzir o problema, uma gravação de tela curta, o erro com dados sensíveis removidos e a última versão que funcionava. Acrescente o próximo marco com clientes e as funcionalidades que não podem ser alteradas. Compartilhe credenciais apenas por um processo adequado de compartilhamento de segredos ou de concessão de acesso à conta.

O que a sua próxima versão deve conter?

Sua próxima versão deve resolver um conjunto pequeno e mensurável de jornadas quebradas. Deixe os pedidos de novas funcionalidades separados até que essas jornadas tenham sido testadas no app publicado.

Use o plano de lançamento de MVP com 12 verificações para identificar lacunas próximas depois da correção. Se o app funciona no preview, mas quebra quando publicado no Replit, use o checklist de deploy no Replit. Para ajuda prática, escolha seu ponto de partida na página do Lovable ou do Bolt e agende uma conversa. Leve o fluxo com falha; a primeira conversa deve ajudar a definir um próximo passo útil.