How it works

Download the file and drop it into your Lovable project. Write “Read the file and follow it” in the chat. Lovable then shows you a plan of what will happen before anything is created. Review the plan and approve it. That is the whole installation, and the approval is your safety gate: nothing is written until you say yes.

Lovable asks ten basic questions about what you're building, who for, what must work end to end, what information is stored, who may do what, and what must never happen. They are about the product, not the technology.

“I don't know” is a valid answer. Lovable then proposes a reasonable assumption, records it as an open assumption and moves on. The interview should take minutes, not hours.

From here you work the way you already do. You describe what you want, Lovable builds it. The difference is what happens around it.

Before a change, Lovable reads the short list of documents that applies to that kind of change and always the decision register. Afterwards, the current state and the affected documents are rewritten. Every decision is recorded with the options that were rejected, why and the conditions under which it may be reconsidered.

Documented intent is never rewritten after the fact to match the code. If the implementation diverges from the intent, that is a discrepancy to raise, not something to quietly absorb.

Done does not mean “the code is written”. It means what was supposed to work has been exercised, the rules that must not break still hold, and the consequences elsewhere have been walked through. Changes to the data model, authentication, authorization or payments require an impact analysis before anything is touched.

Before a release there is a short list to check: what is included, what has been verified, what could go wrong and how you get back. If something breaks in production, an incident flow gives you order instead of panic.