Open the real files and edit them
These are the files the builder works on, not a copy. Saving rebuilds the preview and uses no credits.
You are looking at the real thing
The file in the editor is the same file the builder reads on your next request. There is no separate copy to keep in sync.
Hand edits and builder edits sit in one place, which is what makes the history usable.
No model is called, so nothing is charged.
What saving does, in order
The restore point is taken before the rebuild, not after. Reverse the order and a broken build leaves you with nowhere to go back to.
- Checks the file is somewhere you are allowed to write
- Applies it to the project
- Leaves a restore point
- Rebuilds the preview
A broken build does not erase your work
If the code you saved does not compile, the preview will not update. Your file stays exactly as you typed it.
You get the errors instead. Quietly reverting what someone just wrote is the worst thing an editor can do.
If it is not worth untangling, restore the point the save left behind a moment earlier.
When someone changed it first
The builder, a teammate, or a restore can change a file after you opened it.
Saving then reports a conflict instead of overwriting. You decide what survives.
Where you can write
The screens folder, the public files folder, and the data design folder — the same range the builder has.
Generated files are refused, because the next build would overwrite your edit anyway.
When opening it beats asking
Some changes are faster to make than to describe.
- One word or one number needs changing
- You want to read what the builder wrote
- A visual edit came back saying it could not change that spot