Really appreciate this — you put your finger on the exact thing I cared about while building it: the action boundary.

A few design choices that tackle it head-on:

• Every mutation goes through Defold's own editor.transact API — changes are atomic and land in the editor's normal undo stack. A bad edit is just Ctrl+Z, nothing exotic.
• Nothing touches disk until an explicit editor.save() — the AI stages changes in the live editor, but the developer decides when they get persisted.
• Read and write are split across tools (editor_state, *_get_*, *_find are read-only; mutations are separate calls), so inspecting state never has side effects.

So it's exactly the "fast assistant, developer keeps final control" model you describe — not "Claude controls everything." The editor stays the source of truth and the human stays in the loop.

Thanks for the thoughtful read — this is exactly the kind of feedback that shapes where it goes next.

— Esteban. On a tangent, since you're clearly into AI + game tooling: I also maintain estebanrfp/gdb on github (a real-time graph DB) and a Godot integration, godot-genosdb — different engine, but the same itch of keeping live state predictable. Might be up your alley.