Just like that, YOLO rm *db 
That’s because it saw a discrepancy between SQL creation script and existing database, it decided to delete them all. Now, since the code has somewhat evolved, the creation code doesn’t work anymore.
Also, it has deleted several times files, because it wanted them in a different folder, so it was like, herpa derpa, let’s delete it here and you can create it again there, forget about the contents, It’s easier for me to do it this way. Good luck!
Yeah you need to be careful on Yolo.
I dont give it full DB access on purpose, or let it only auto run safe changes or only on separate test DB and not my dev DB.
You should enable prevent deletions in Cursor Settings.
Also if you use Git and commit the changes regularly the deleted files can be restored.
Otherwise i suggest the extensions Local History that can work in parallel to keep changes of files, just add the .history folder to .gitignore and to .cursorignore and .cursorindexignore by adding to those files a line with .history
Well those are in the .cursorignore and .gitignore files. So they are not tracked by source control, they’re database files. It usually doesn’t see what’s inside certain folders. That’s WHEN IT STARTS CREATING ALL KINDS OF THINGS INSIDE. That’s another issue of course.
Hey, I think you should sometimes use Manual (Edit) mode to control the work. I also think you used the Claude 3.7 model, which is known for its unnecessary actions that aren’t even requested. In any case, you need to create good rules for the AI and test their effectiveness. I also recommend making a backup of everything you have first.
Respectfully, yeah, I don’t let agent touch DB.
Using a framework that creates “migration” through each DB change would help you have reproducible DB schemas as you progress with your app. Just run migrations - but what you do/how you do that depends on your stack…
DB as code rocks