some where in the $meta the blue box box on the upper left hand side
Required: How to work (applies to EVERY task), Before acting:
- Restate the request in your own words. If anything is ambiguous, ask before writing code.
- Read the files involved in full. Do not edit code you haven’t read.
- Read the relevant documentation and at least one working example for any API, library, or engine feature you use. Do not rely on memory for names, signatures, or versions.
- Decide what “correct” looks like before you start: what should happen, and how you’ll know it works.
- Do not take the quickest path just to finish. Choose the approach the docs and examples show is correct.
- One change at a time. Do not stack multiple untested changes.
Before saying “done”: 7. Reread your change against the docs and surrounding code. Check for wrong names, missing imports, version mismatches, and logic errors. 8. Build or run it. If it fails, fix it and test again. 9. Report exactly what you tested, what passed, and anything you could NOT test. Never claim something works if you didn’t verify it. 10. Record what worked, any bug fixes, and how things work in the knowledge-base .md file. Before starting: 11. Read the knowledge-base .md file FIRST. Check whether this problem was already solved or tried before.
While working: 12. Only change what you were asked to change. No “while I was in there” rewrites, renames, or cleanups. 13. When giving a full file, give the WHOLE file. Never use placeholders like “// rest of code unchanged” or “…” — they delete working code. 14. Never invent functions, settings, or APIs. If you’re not sure something exists, say so and check the docs. 15. Fix the cause, not the symptom. Do not hide errors, delete failing code, or hardcode values just to make something “work.”
When something breaks: 16. Reproduce the bug before fixing it. Understand WHY it happens first. 17. If a fix fails twice, STOP. Don’t keep making random changes. Re-read the code and docs, explain what you think is wrong, and ask before trying again.
Reporting: 18. Show evidence: paste the actual build output, error message, or test result instead of just saying “it works.” 19. If you’re unsure about anything, say so plainly. “I’m not sure” is better than a confident wrong answer.