Vibe coding
What business rules belong in Lovable project knowledge?
Keep the rules an app must remember concise, current and specific enough to prevent repeated misunderstandings.
Zocri · 2 min read · Sources checked
Record the business meanings
Lovable distinguishes workspace knowledge for shared instructions from project knowledge for the context of a particular app. For a repair shop, useful project context explains what an estimate, an approval and a completed job mean. These definitions matter every time the app changes. A temporary request to move a button belongs in the current conversation instead.
Start with a small rulebook: customers approve an estimate before work begins; only a manager changes an approved price; completed jobs keep their history. Include who owns each decision. Avoid copying months of chat into the knowledge field, where conflicting instructions become difficult to spot.
Separate shared standards from local rules
A business operating several apps might share its writing style and standard date display. A particular workshop may require approval for replacement parts above an internally chosen amount. Put the shared convention and the workshop exception at their appropriate levels.
Name exceptions explicitly. If emergency repairs follow a different approval process, describe the condition and authorized role. Do not write both 'always require approval' and 'allow urgent work' without resolving the conflict. The builder needs a decision it can translate into observable behavior.
Keep examples beside ambiguous terms
Add a short example when a phrase could mean two things. 'Completed' might mean the technician finished, the customer collected the item or the invoice was paid. Choose one meaning and use separate fields for the others rather than overloading a single status.
Give realistic boundaries without customer details. Explain whether a quote can expire, whether a rejected estimate can be reopened and whether an archived job appears in search. Use invented names and sample amounts. Credentials, private records and confidential attachments do not belong in this rulebook.
Review knowledge when the business changes
After a policy change, update the rulebook and note which existing records should retain their original treatment. Ask the builder to identify places affected by the change, then inspect those journeys. A knowledge edit alone is not proof that the app now follows it.
Schedule a practical review when a new employee takes over the app. Have them explain the core rules back using a sample job. If they cannot tell whether an approved price is editable, rewrite that section. Good project context doubles as an understandable operating agreement.