Recuperar quando uma alteração quebrou um build funcional
Restaurar o último comportamento funcional, manter o trabalho recente de qualidade e os dados dos clientes e, em seguida, reaplicar apenas a alteração desejada.
Quando usar
Quando o aplicativo funcionava, você solicitou uma alteração e agora uma página ou fluxo importante está quebrado, embora você queira manter as partes úteis do trabalho recente.
Antes de começar
- Pare de enviar mais prompts de reparo até identificar a última versão que definitivamente funcionava.
- A alteração recente que acionou o problema, copiada com a maior precisão possível.
- A última data, hora ou descrição da versão conhecida como funcional.
- Uma pequena lista do que ainda funciona, o que quebrou e qual novo trabalho útil você deseja manter.
- Contas de teste seguras e registros de teste para o fluxo afetado.
- Uma exportação ou registro escrito de quaisquer informações reais de clientes adicionadas desde a última versão funcional. Nunca experimente na única cópia existente.
O prompt
Esses prompts funcionam melhor em inglês — cole-os como estão, mesmo em páginas traduzidas.
Recover this app after [RECENT CHANGE OR PROMPT] broke [EXACT BROKEN BEHAVIOR]. Restore the working behavior without discarding [GOOD NEW WORK TO KEEP] or losing customer information added since [LAST KNOWN WORKING VERSION OR TIME]. Do not make another broad change yet. Compare the current version with the last known working version available in this platform's history. List what changed in the affected page, shared elements, login, stored information and external connections. Separate evidence you can see from guesses. Create a recovery plan with three outcomes. Restore [PREVIOUSLY WORKING FLOW]. Preserve [GOOD NEW CONTENT OR FEATURE]. Reapply only [THE INTENDED PART OF THE RECENT CHANGE] after the app is stable. Tell me which outcome can be completed safely and which needs my decision. Treat the app's pages and behavior separately from live customer information. Restoring an earlier visual or app version must not silently erase, replace or expose accounts, bookings, orders, messages, uploads or payments created afterwards. If the platform's restore action may affect stored information, connection settings or permissions, stop and explain the risk before using it. Use the platform's actual version-history, revert or deployment-rollback control when a restore is needed. Do not pretend that writing the word revert in chat has undone the change. Preview the last working version first where the platform allows it. Restore a safe working version or repair the smallest confirmed cause. Then test [BROKEN FLOW] with safe data, plus sign-in, the main navigation, [IMPORTANT FORM OR PAYMENT], the phone layout and one nearby feature that was not broken. Confirm that information added after the last working version is still present. Only after those checks pass, reapply [INTENDED CHANGE] as a narrow change that does not touch [AREAS TO PROTECT]. Test the old working flow and the new change together. If they conflict, keep the stable version and show me the decision instead of forcing both. Do not delete stored information, reset the app, replace the login system, change payment keys or remove access rules. Keep the repair surgical and the explanation calm. Finish with what was restored, what was preserved, what was reapplied and what I should test on the published site.
Já está criando? Cole isto no seu projeto. Começando do zero? Abra uma conta gratuita em um criador compatível abaixo.
Crie em
O que isto cria
- Uma comparação entre a versão quebrada e a última versão funcional
- Um plano de recuperação que separa a restauração, preservação e reaplicação
- Um rollback seguro ou um reparo estritamente direcionado
- Verificações para o fluxo reparado, recursos próximos e informações recentes de clientes
- Uma reaplicação controlada apenas da alteração pretendida
- Um registro de recuperação em linguagem simples para problemas futuros
Confira se funcionou
Cole o prompt, espere a construção terminar e então confirme estes pontos — em linguagem simples, sem verificações técnicas:
- A ação que funcionava antes da alteração volta a funcionar com dados de teste seguros
- O novo texto ou recurso útil que você nomeou ainda está presente ou está claramente salvo para reaplicação
- Contas de clientes, reservas, pedidos, mensagens e uploads adicionados após a versão funcional ainda estão lá
- Login, navegação e o recurso próximo que você testou ainda funcionam
- A nova alteração pontual funciona sem quebrar o fluxo restaurado
- O site publicado mostra a versão funcional aprovada, não apenas a visualização do editor
- Você recebe um relato claro do que foi restaurado e de qualquer coisa que foi deixada deliberadamente sem alterações
Faltou algo? É normal — peça em uma mensagem curta de acompanhamento em vez de rodar o prompt inteiro de novo.
Próximos passos
Reaplique a mudança útil com segurança
Após o comportamento funcional anterior ter sido restaurado e verificado
Reapply only this part of the change: [EXACT DESIRED RESULT]. Protect [WORKING FLOW, DATA AND PAGES] from modification. Show me the smallest planned change first, then implement it and retest both the restored behavior and the new result.
Você saberá que funcionou quando: A melhoria pretendida está presente enquanto o fluxo recuperado ainda passa no mesmo teste.
Adicione uma verificação para o comportamento quebrado
Uma vez que a recuperação esteja estável
Add a repeatable safe test for this rule: [WHAT MUST NEVER BREAK AGAIN]. Use test data only. Run it after the current version and explain in plain language how I can ask for the same check after future changes.
Você saberá que funcionou quando: O teste passa agora e fornece uma falha clara caso o mesmo problema retorne.
Registre a recuperação para a próxima vez
Após a confirmação de que o site está funcionando
Create a short recovery note containing [CHANGE THAT CAUSED THE BREAK], [VISIBLE SYMPTOM], [CONFIRMED CAUSE], [VERSION RESTORED OR FIX APPLIED], [DATA CHECKED] and [FINAL TESTS]. Keep it private to the owner and do not include passwords, payment details or connection keys.
Você saberá que funcionou quando: O proprietário possui um registro privado e legível que torna mais rápido diagnosticar um problema recorrente.
Fique atento a
- Mais prompts de reparo podem enterrar o último bom estado. Pare após a primeira regressão clara e inspecione o histórico antes de pedir outra correção ampla.
- Uma solicitação de chat para reverter pode não realizar um rollback real. Use o controle visível de Reverter, Histórico de Versões ou de implantação da plataforma e confirme qual versão está ativa.
- Restaurar páginas pode não restaurar informações armazenadas da mesma forma. Código, layout, dados e configurações externas podem ter históricos separados. Nunca presuma que um rollback visual reverte com segurança uma alteração de dados.
- Um rollback ao vivo pode restaurar visitantes rapidamente sem corrigir o rascunho. Confirme tanto o que o público vê quanto qual versão você continuará editando.
- O trabalho recente de qualidade precisa de um inventário. Anote o texto, os recursos e os registros que valem a pena preservar antes de retornar a uma versão mais antiga.
- A alteração original pode genuinamente entrar em conflito com o comportamento antigo. Se ambos não puderem coexistir com segurança, mantenha a versão estável e torne a troca explícita.
Notas por plataforma
<ul><li><strong>Base44:</strong> Use o controle de Reverter real ou o Histórico de Versões. O Base44 pode visualizar uma versão mais antiga, restaurá-la no editor ou publicar uma versão mais antiga mantendo o rascunho atual, o que é útil para restaurar o aplicativo ao vivo antes de reparar o rascunho.</li><li><strong>Lovable:</strong> O Lovable permite visualizar e reverter para versões anteriores do projeto. Uma reversão de versão pode não desfazer todas as alterações de dados armazenados, portanto, inspecione os dados e as permissões separadamente antes de presumir que todo o aplicativo retornou ao estado anterior.</li><li><strong>v0:</strong> Um projeto v0 implantado no Vercel pode retornar a produção para uma implantação anterior. Isso restaura o que os visitantes veem, mas a fonte do projeto e quaisquer dados conectados ainda precisam de revisão separada por meio do histórico do projeto ou do backup do GitHub conectado.</li></ul>
Gaste menos créditos
Toda plataforma cobra pelo trabalho que a IA dela faz — então o hábito mais barato é pensar antes de construir. Estas seis regras cortam a maior parte do desperdício, qualquer que seja a plataforma.
- Planeje primeiro em um chat gratuito. Esboce tudo no ChatGPT, Claude ou Gemini — páginas, recursos, o que cada formulário coleta, como deve ficar. Pensar lá é grátis; pensar dentro de um builder é cobrado.
- Comece com um prompt escrito, não com uma frase. "Faça um site para mim" é a frase mais cara na construção com IA. Um primeiro prompt completo — como os deste site — economiza dezenas de rodadas de correção.
- Não tenha preguiça dos detalhes. Cada detalhe omitido volta como uma correção que você paga. Nome do negócio, cores, cada página, cada campo de formulário, o que acontece após o envio — coloque tudo no primeiro prompt.
- Depois, uma mudança por mensagem. "Arrume o cabeçalho, e o formulário, e as cores" gera um emaranhado que custa mais para desfazer do que economizou.
- Travou? Pare de remendar. Se a mesma correção falhar umas três vezes, não mande uma quarta — descreva o estado final desejado da seção inteira em uma mensagem nova.
- Comece grátis. Faça upgrade quando precisar de mais. Use a cota gratuita para criar e explorar sua primeira versão. Faça upgrade quando precisar de mais uso ou de recursos pagos, e confira os custos de serviços conectados antes de lançar.
Os prompts desta página foram escritos para fazer a maior parte desse trabalho por você — é esse o objetivo deles.
Leia o guia completoPlaybooks relacionados
Revisado em: 2026-07-27