Formulário do Lovable não salva dados? Prompts para resolver

Se o seu formulário no Lovable não estiver salvando dados, verifique primeiro se o envio é disparado, se o banco de dados aceita a gravação e se a aplicação consegue ler a linha salva de volta. Entregue essas evidências ao Lovable antes de pedir qualquer correção, porque uma mensagem verde de sucesso não prova nada. Este guia traz prompts prontos para copiar e colar, uma tabela de diagnóstico e um checklist de regressão para consertar a camada com defeito sem precisar reconstruir o formulário do zero.

Os exemplos específicos de banco de dados abaixo assumem que o projeto usa Supabase. Caso use outro backend, mantenha o fluxo de trabalho e apenas substitua as requisições, permissões e logs pelo serviço correspondente. O objetivo é confirmar o salvamento na prática, não se prender a uma integração específica.

Descubra onde o salvamento quebra

O salvamento percorre várias etapas: validação no navegador, manipulador de envio, montagem da requisição, autenticação, permissões no banco e a consulta que atualiza a tela. Uma falha em qualquer uma dessas etapas pode parecer o mesmo botão quebrado.

Comece com um único caso reproduzível. Use uma conta de teste e um valor inconfundível, como `SAVE-TEST-1028-A`. Evite dados reais de clientes. Anote a URL da página, se você está autenticado e se a falha acontece no preview, no app publicado ou em ambos.

Antes de alterar qualquer linha, registre uma versão recuperável do código usando o histórico de versões ou o fluxo de Git do seu projeto. Se a correção sugerida mexer no banco de dados, planeje separadamente como reverter essa alteração. Restaurar o código do frontend não restaura registros nem políticas do banco.

Passe de 5 a 10 minutos reunindo evidências antes de pedir alterações no código.

1. Abra as ferramentas de desenvolvedor do navegador e selecione a aba Network.
2. Limpe a lista de requisições e envie o formulário uma vez.
3. Procure a chamada fetch ou XHR correspondente. Algumas aplicações chamam uma backend function em vez de falar direto com o banco.
4. Inspecione o status da resposta e o corpo sanitizado.
5. Verifique o Console em busca de erros de validação ou de JavaScript.
6. No projeto e na tabela corretos do banco de dados, procure o marcador de teste.

Não cole um log de rede inteiro no chat. Ele pode conter tokens de sessão, cookies ou dados pessoais. Em vez disso, compartilhe o método HTTP, o caminho sanitizado do endpoint, o status, o erro relevante e os nomes dos campos enviados no payload.

| O que você observa | Camada provável da falha | Próxima checagem | |---|---|---| | Nenhuma requisição de gravação aparece | Validação, manipulador de evento ou erro anterior de JavaScript | Confira erros de campo, o Console e o manipulador de submit | | A requisição retorna 401 ou 403 | Autenticação ou autorização | Inspecione a resposta, o estado da sessão e as políticas ativas | | A resposta aponta coluna ou restrição ausente | Incompatibilidade entre payload e schema | Compare os campos enviados com a definição real da tabela | | A requisição tem sucesso e a linha existe, mas a lista não muda | Consulta de leitura, filtros ou atualização de cache | Inspecione a query usada na tela de destino | | Duas linhas aparecem após uma única ação | Envio duplicado ou comportamento de retry | Verifique a contagem de requisições e a amarração do manipulador | | Funciona no preview, mas falha no app publicado | Ambiente, deploy ou comportamento dependente de origem | Compare os endpoints de backend e as respostas sanitizadas |

Esses pontos servem como ponto de partida, não como veredito. Códigos de status HTTP sozinhos quase nunca contam a história inteira. Um problema de autorização no Supabase pode vir acompanhado de um código de erro interno do banco na resposta, então guarde essa mensagem.

Uma resposta vazia também não significa inserção com falha. Certas operações de escrita não retornam as linhas inseridas a menos que isso seja solicitado explicitamente. Olhe no banco de dados antes de pedir para o Lovable reescrever a camada de persistência.

Peça um diagnóstico antes do patch

O prompt mais caro costuma ser o mais curto: 'O formulário não funciona. Conserte.'

Ele força o assistente a adivinhar o sintoma, localizar o formulário, deduzir o schema e chutar uma solução. O resultado pode alterar vários arquivos quando apenas um detalhe precisava de ajuste.

Comece exigindo apenas o diagnóstico. Isso serve como uma restrição direta no prompt, sem presumir que inspeções sejam gratuitas ou que o Lovable impeça edições por conta própria. Analise o retorno e qualquer sugestão antes de aplicar.

```text Diagnostique esta falha de salvamento de formulário. Não edite arquivos, não rode migrações e não altere configurações ainda.

Página e formulário: [rota e nome do formulário] Comportamento esperado: [uma frase] Comportamento real: [uma frase] Ambiente: [preview / publicado / ambos] Estado da conta: [conectado / desconectado; sem credenciais] Passos para reproduzir: [passos numerados] Evidência sanitizada: [status da requisição, erro na resposta, erro no console e se a linha de teste existe no banco]

Rastreie o caminho desde o manipulador de envio até a gravação no backend, e da gravação bem-sucedida até o resultado exibido na tela.

Retorne:

1. A camada com falha e as evidências que sustentam isso.
2. Arquivos, funções e objetos de backend relevantes.
3. A menor correção proposta possível.
4. O que continua desconhecido e a checagem exata necessária.
5. Testes de aceitação para a correção sugerida.

Separe observações reais de hipóteses. Se não puder inspecionar o backend, informe. Não invente o schema. Não sugira desativar RLS, expor secrets, trocar a integração ou reconstruir o formulário. ```

Um diagnóstico útil aponta o fluxo exato de execução: o manipulador de submit envia um campo que a tabela não possui, ou o insert roda com sucesso mas a query da lista nunca recarrega. Dizer que 'pode haver um problema no Supabase' não ajuda em nada.

Se faltarem dados ao assistente, faça a checagem pedida antes de autorizar qualquer patch. Uma observação precisa no navegador poupa três tentativas cegas de edição.

Para consultar outros padrões de instrução reaproveitáveis, acesse nossa biblioteca de prompts. Aqui, mantenha o foco estreito: um formulário, uma falha reproduzível e um critério claro de sucesso.

Use o prompt certo para a sua falha

Siga o caminho indicado pelas suas evidências. Não junte todos os templates em uma única mensagem. Pedir validação de frontend, permissões no banco, comportamento de cache e ajustes visuais ao mesmo tempo só infla o escopo sem necessidade.

Nenhuma requisição sai do navegador

A validação nativa do navegador pode travar o envio antes mesmo do manipulador entrar em ação. Um botão também pode estar com o tipo incorreto, ou uma exceção pode estourar antes da chamada de escrita.

Peça um ajuste no fluxo de envio, não uma reescrita do backend:

```text O formulário em [rota] não gera nenhuma requisição de gravação. Evidência: [erro sanitizado do console ou comportamento de validação].

Inspecione a validação nativa do navegador, a validação da biblioteca de formulários, o tipo do botão, os eventos associados e exceções lançadas antes da chamada ao backend. Identifique o bloqueio real.

Corrija apenas o defeito confirmado no fluxo de envio. Mantenha as regras atuais dos campos e o layout. Não altere o banco de dados, auth, dependências ou formulários não relacionados.

Deixe as falhas de validação visíveis na interface. Garanta que um envio válido gere apenas uma requisição. Informe os arquivos alterados e separe os testes executados daqueles apenas sugeridos. ```

Não desative a validação só para fazer o botão responder. Se um campo opcional estiver marcado como obrigatório por engano, corrija a regra. Se um campo obrigatório estiver oculto, conserte a visibilidade ou a navegação entre as etapas.

O banco de dados rejeita a gravação

Aqui você precisa do erro exato e do schema. Um campo obrigatório ausente, um valor de enum inválido, uma quebra de chave estrangeira e um bloqueio por políticas de segurança pedem correções completamente distintas.

No Supabase, o RLS (Row Level Security) define quais linhas uma requisição pode manipular. Uma inserção autenticada pode exigir um campo de propriedade condizente com o usuário atual e uma política de insert compatível. Preencher o ID do dono apenas no frontend não cria uma barreira de segurança; o próprio banco precisa validar essa autorização.

```text A gravação do formulário foi rejeitada pelo backend. Tabela ou função: [nome] Erro sanitizado: [mensagem e código exatos] Nomes dos campos no payload: [apenas os nomes] Schema e políticas conhecidas: [detalhes confirmados ou desconhecido] Acesso pretendido: [quem pode criar quais registros]

Compare o payload, as restrições do schema, a identidade autenticada e as políticas aplicáveis. Corrija somente a divergência confirmada. Não deduza detalhes ausentes do schema.

Preserve o RLS e o princípio do menor privilégio. Nunca coloque uma chave service-role ou outro secret no código do frontend. Não libere acesso público de escrita como atalho.

Se uma alteração no banco for necessária, proponha separadamente explicando o impacto no acesso, as queries de verificação e os limites de rollback. Aguarde aprovação antes de aplicar. Caso contrário, faça a menor alteração de código possível. ```

Um formulário público de captura de leads pede uma estrutura de permissões diferente de um painel financeiro restrito. Defina essa regra com clareza. Envios anônimos também exigem proteção contra abusos; liberar inserção para qualquer pessoa não resolve uma arquitetura de produção.

Jamais aprove uma migração que remove uma restrição só porque o payload falhou ao tentar gravar. Essa regra pode ser o que garante a consistência dos dados do seu sistema.

O registro existe, mas a tela não atualiza

Pare de caçar problemas no insert. Você já tem provas de que ele funcionou.

A query de leitura pode estar filtrando o novo item para fora, a ordenação pode tê-lo jogado para outra página, ou a interface pode estar presa em cache desatualizado. Também acontece de o usuário ter permissão para inserir a linha, mas a política de leitura bloquear a exibição logo em seguida.

```text A gravação foi bem-sucedida e a linha de teste existe em [tabela]. A interface em [rota] não exibe o registro. Evidência: [marcador de teste, filtros ativos, resposta sanitizada].

Não mexa no fluxo de insert nem no schema do banco de dados. Inspecione a consulta de leitura, permissões, filtros, ordenação, paginação e atualização de cache usados por esta tela. Identifique o motivo confirmado antes de propor correções.

Mantenha o padrão de busca de dados já usado no projeto. Não adicione uma nova biblioteca de estado nem use recarregamento de página inteira como solução padrão. Mostre o estado correto após o salvamento sem burlar filtros ou regras de acesso.

Valide a visibilidade esperada do registro após salvar, após navegar para outra tela e após um refresh forçado. ```

Quando o novo registro fica de fora por causa de um filtro ativo, a melhor saída pode ser apenas um feedback claro: 'Salvo. Este item não aparece no filtro atual.' Forçar a exibição dele na lista à força quebraria o comportamento esperado da tela.

Valide a correção e controle os gastos de créditos

Separe o tempo e os créditos entre diagnóstico, correção e conferência. A tabela a seguir serve como estimativa para um defeito pontual, simples e reproduzível em um único formulário, sem funcionar como garantia de prazo.

| Etapa | Estimativa de tempo | Interações planejadas com IA | |---|---|---| | Reproduzir e coletar evidências | 5-10 minutos | 0 | | Diagnosticar a camada com falha | 5-10 minutos | 1 | | Aplicar correção pontual | 10-20 minutos | 1 | | Testar e revisar o diff | 10-15 minutos | 1 | | Ajuste opcional baseado em novas evidências | 5-10 minutos | 0-1 |

Isso soma cerca de 30 a 55 minutos antes de qualquer ajuste extra, exigindo três interações planejadas com a IA. Uma interação não corresponde a um consumo fixo de créditos. O gasto real depende das regras de cobrança do Lovable e do volume de arquivos processados.

Tome como base o consumo indicado no painel da sua conta para acompanhar seus custos reais, em vez de assumir que o uso de um template garante economia fixa. Consulte nosso guia de preços do Lovable para entender os conceitos de faturamento da plataforma.

Se o saldo de créditos e o plano do backend já cobrirem a demanda, o desembolso direto pode ser zero. Isso não significa que o conserto saia de graça: ele consome créditos e tempo de desenvolvimento. Antes de começar, estabeleça uma regra como não gastar mais de US$ 5 em compras adicionais sem reavaliar o diagnóstico. Trata-se de controle orçamentário, não de orçamento fechado para o serviço.

Após duas tentativas sem sucesso, pare de pedir variações genéricas de 'tente consertar de novo'. Reproduza o cenário e junte evidências atualizadas. Caso uma tentativa gere novos problemas, volte para a versão estável anterior do código antes de prosseguir, mantendo o controle sobre qualquer mudança feita no banco.

Use este checklist de aceitação:

• [ ] Um envio válido cria exatamente um registro esperado no banco.
• [ ] Erros em campos obrigatórios aparecem na tela e barram o envio.
• [ ] Gravações rejeitadas mostram mensagem de erro, nunca de sucesso.
• [ ] Apertar Enter ou clicar duas vezes rápido no botão não gera duplicatas.
• [ ] Indicadores de carregamento voltam ao normal tanto em caso de sucesso quanto de falha.
• [ ] O registro continua visível após um refresh forçado na página.
• [ ] Filtros e permissões de leitura continuam operando normalmente.
• [ ] Uma segunda conta de testes não consegue enxergar dados privados de outro usuário.
• [ ] O comportamento é idêntico no preview e na versão publicada.
• [ ] O diff do código não traz alterações soltas de autenticação, pagamentos ou layout.

Desativar o botão de envio no clique previne duplicidades acidentais na interface, mas ações críticas também exigem travas de idempotência no servidor ou restrições no banco de dados. Um bloqueio puramente visual não garante segurança total.

Revise tudo o que foi modificado, e não apenas o resumo fornecido pelo assistente. Peça que ele aponte quais checagens automáticas realmente rodou e quais testes manuais ficaram para você fazer. Nossos guias práticos de desenvolvimento trazem fluxos de trabalho completos para publicação; este reparo deve se manter muito mais cirúrgico e direto.

Por que meu formulário no Lovable avisa que salvou, mas não salva nada?

A mensagem de confirmação pode estar disparando antes da conclusão da requisição, ou o código simplesmente ignora o erro devolvido pelo backend. Analise a chamada de rede e o registro no banco, garantindo que o alerta de sucesso só apareça depois que o servidor confirmar a gravação.

Devo desativar o RLS do Supabase para fazer o formulário funcionar?

Não, isso não deve ser feito em produção. Inspecione o usuário logado, o payload enviado e as políticas de segurança ativas. Ajuste a regra específica de autorização mantendo as permissões necessárias e valide o resultado com contas de teste diferentes.

Quantos créditos do Lovable custa o conserto de um formulário?

Não existe um valor fixo. Reserve créditos para o diagnóstico, um patch contido e a fase de testes, monitorando o painel da sua conta. Fornecer evidências claras desde o início corta o número de tentativas cegas, mas não garante um gasto específico de créditos.