Lovable.dev GPT Latent Space

lovable-knowledge.md

Lovable.dev Latent Space

One of the important parts of working with GPTs is establishing latent space knowledge which creates a foundation for how the GPT will respond. Here are some of the points I'm using in my lovable "Manage Knowledge" project settings:

For background, here is the documentation on that page:

Manage Knowledge

Add custom context and instructions for your project. Lovable will use it in every edit. Use it to: Define project-specific rules or guidelines Set coding style preferences (e.g., indentation, naming conventions) Include external documentation or style guides

Also worth mentioning are the concepts of Latent Space and Hallucination:

https://en.wikipedia.org/wiki/Latent_space

https://en.wikipedia.org/wiki/Hallucination_(artificial_intelligence)

Individual Latent Space Items

System Directive (Copy/Paste follows):

1. Modularity & Structure:

• When generating code, always decompose large components into smaller, reusable, and portable modules.
• Organize these modules in nested subfolders to maintain a clear, scalable file structure.

2. Task Identification & Execution Sequence:

• Upon receiving an instruction, first parse and enumerate all required tasks.
• Execute tasks in the specified order.
• After execution, perform an internal verification step to confirm completion.
• Report each verified completed task individually.

3. DOM Verification & Tangible Feedback:

• After implementing a feature, simulate a render and verify it appears correctly in the DOM.
• If the feature does not render as expected, iterate internally until it does.
• Provide an exact DOM snippet to confirm its presence and correctness.

4. Qualifying Queries:

• Before executing, ask clarifying questions until there is at least a 99% confidence level in understanding the requirements.

5. Error Handling & Logging:

• Implement robust, verbose error handling in all code.
• Insert detailed console logging statements for debugging.
• Maintain a global switch to disable all debugging and testing tools in a production environment.
• Never remove console logs; logs will be manually removed before deployment.

6. Aggressive Debugging & Breakpoints:

• Insert breakpoints or conditional checks designed to aggressively fail upon encountering GPT-generated logical errors.

7. Third-Party & Existing Resource Utilization:

• Before writing new code, evaluate existing packages or previously implemented utilities to avoid redundant solutions.
• Leverage existing architecture, components, and tools whenever possible.

8. Full Code Audits Before Editing:

• If instructed to perform a full audit, do not modify any code until the audit is complete.
• During the audit, analyze all relevant files and logic. Identify all obstacles and propose comprehensive solutions.
• After the audit and roadmap are finalized, proceed to implement changes.

9. Floating Debug Toolbar Implementation:

• On every page, implement a floating debug toolbar that displays current context.
• Include UI elements to minimize or expand the toolbar.
• As components evolve, extend the toolbar’s capabilities accordingly.

10. Best Practices & Permanent Solutions:

• Follow established best practices for UI, code structure, and development patterns.
• Address the root cause of each problem to ensure permanent, comprehensive fixes.

1. Modularity & Structure:
 * When generating code, always decompose large components into smaller, reusable, and portable modules.
 * Organize these modules in nested subfolders to maintain a clear, scalable file structure.
2. Task Identification & Execution Sequence:
 * Upon receiving an instruction, first parse and enumerate all required tasks.
 * Execute tasks in the specified order.
 * After execution, perform an internal verification step to confirm completion.
 * Report each verified completed task individually.
3. DOM Verification & Tangible Feedback:
 * After implementing a feature, simulate a render and verify it appears correctly in the DOM.
 * If the feature does not render as expected, iterate internally until it does.
 * Provide an exact DOM snippet to confirm its presence and correctness.
4. Qualifying Queries:
 * Before executing, ask clarifying questions until there is at least a 99% confidence level in understanding the requirements.
5. Error Handling & Logging:
 * Implement robust, verbose error handling in all code.
 * Insert detailed console logging statements for debugging.
 * Maintain a global switch to disable all debugging and testing tools in a production environment.
 * Never remove console logs; logs will be manually removed before deployment.
6. Aggressive Debugging & Breakpoints:
 * Insert breakpoints or conditional checks designed to aggressively fail upon encountering GPT-generated logical errors.
7. Third-Party & Existing Resource Utilization:
 * Before writing new code, evaluate existing packages or previously implemented utilities to avoid redundant solutions.
 * Leverage existing architecture, components, and tools whenever possible.
8. Full Code Audits Before Editing:
 * If instructed to perform a full audit, do not modify any code until the audit is complete.
 * During the audit, analyze all relevant files and logic. Identify all obstacles and propose comprehensive solutions.
 * After the audit and roadmap are finalized, proceed to implement changes.
9. Floating Debug Toolbar Implementation:
 * On every page, implement a floating debug toolbar that displays current context.
 * Include UI elements to minimize or expand the toolbar.
 * As components evolve, extend the toolbar’s capabilities accordingly.
10. Best Practices & Permanent Solutions:
 * Follow established best practices for UI, code structure, and development patterns.
 * Address the root cause of each problem to ensure permanent, comprehensive fixes.

following 'best practices' even when user is not requesting them. something that directs it to always follow best practices.

@Godfrethree define best practices - if you have a resource for this share it as linking to a known data source is essential otherwise it becomes subjective and ephemeral

@rjmoggach good point. not sure to be totally honest. it seems that when i tell lovable to use "best practices" it tends to know what they are with something like Stripe for example

Here is another one:

Asking Lovable if the solution it is proposing fixes the "source" of an issue.

This tends to make broader changes that fix errors permanently