Thanks for the quick reply,
the rules are stored in .cursor/rules/
one file around 350 lines
Ignored rules included:
1. **NO HARDCODING** - Do NOT hardcode values unless specifically approved
2. **ALWAYS READ THE CODE** - Before making ANY change, read the actual code first. No assumptions, no guessing.
MANDATORY: Read Before ANY Implementation
Before writing ANY code, you MUST:
1. **Read `ARCHITECTURE.md`** in the project root - it contains ALL architectural rules
2. **Search the codebase** for existing systems that do what you’re about to implement
3. **Reuse existing patterns** - do NOT reinvent systems that already exist
- **Compile after each change** - Don’t accumulate errors
2. **Test critical logic immediately** - Write unit tests for:
-
New operations (test `evaluate()` and `generateGLSL()`)
-
Graph compilation (verify GLSL output is valid)
-
Serialization (round-trip test: save → load → compare)
3. **Run the application** - Visual verification catches what tests miss
4. **Check logs for errors** - Many failures show in console before visual symptoms
NO SHORTCUTS - Implement It Properly
**When asked to implement a feature, IMPLEMENT IT FULLY. Do not:**
1. **Revert to simpler behavior** - If the user asks for X, don’t give them “simple X” or “X without the hard parts”
2. **Leave it for “later”** - Don’t say “when your shader is ready” or “in the future” - implement it NOW
3. **Give up at the first obstacle** - If something breaks, FIX IT, don’t remove the feature
4. **Offer partial solutions** - Complete the entire task, including all necessary changes across all files
5. **Punt to the user** - Don’t tell them to “add this code to your shader” - add it yourself
**When something breaks after your change:**
- Debug and fix it properly
- Trace through the entire system to understand why
- Make changes in ALL necessary files (shaders, C++, graphs, etc.)
- Test mentally that the solution is complete
DEBUGGING - Read The Code, Don’t Spam Logs
**When debugging an issue:**
1. **READ THE CODE FIRST** - Trace through the logic by actually reading the source files
2. **Understand the full flow** - Map out the entire call chain before making changes
3. **NO ENDLESS CONSOLE OUTPUT** - Don’t add `std::cout` or debug prints as your first approach
4. **Find the root cause** - Don’t just treat symptoms, find WHY it’s broken
5. **ONE FIX AT A TIME** - Make a fix, verify it works, then move on