Open the code and edit it yourself
This is the code that runs, not a simplified view of it. Editing by hand costs no credits.
What it is
If you ever hand the project to a developer, they need real files. These are those files.
The write rules that keep the model in bounds apply to you too. Three areas are writable: the app source, static files, and database change files.
Every save writes a restore point. While a new build runs, the last working preview stays up.
How to use it
Step 1. Open the code editor
Pick a file from the tree on the left.
Step 2. Edit and save
Saving rebuilds the preview. If something does not compile, the errors are shown as they are — the save itself still lands.
Step 3. Roll back if you want
Each save leaves a restore point, so an experiment is never one-way.
What we measured
The writable areas are the app source, static files, and database change files. Generated files are blocked inside them. These are the same rules the model runs under.
What it does not do
Writes stay inside three areas
Everything else is refused, including generated files. The rule exists to stop a bad write from breaking the project, and it is not relaxed for people.
New libraries cannot be added
The dependency set is fixed. You build with what the project already carries.
Concurrent changes are flagged, not merged
If a model run or a restore touched the same files while your editor was open, the save is refused with a conflict rather than overwriting quietly.
You can still break it
Hand edits can break a build. That is why the restore point is automatic and the last working preview is kept.