Programmatic file-write API for app runtime → project source tree (admin-scoped, sandboxed)

Problem:

Base44 apps run in a sandboxed runtime with no write access to the project source tree. Frontend code, backend Deno functions, AppSettings, entities, and file uploads can all read/write within their own scopes — but none can modify files in the project source. The only subsystem with project-filesystem write access is the builder AI chat session, via write_file. That tool is invoked manually when a user posts a message in chat. There is no programmatic way to wake it from inside the running app. This forces a two-phase pattern for any flow that produces files needing to ship in the next build: 1. App runtime computes the data, stores it in AppSettings or an entity. 2. User pastes a trigger phrase in chat so the builder AI can read step 1 and write the files. It works, but it permanently blocks any automation a builder might want — scheduled rebuilds, CI/CD, headless triggers, post-deploy hooks, batch content generation.

Proposed API:

base44.builder.writeProjectFile(path, contents, options) base44.builder.syncFromAppSettings(mapping)

Callable from backend Deno functions only (not frontend — frontend never gets project filesystem access).

Security considerations — flagging these explicitly because they’re the obvious objection:

1. Path scoping. API only accepts writes inside an allowlisted set of directories, project-configurable but defaults closed. Never src/, never config files, never package.json, never anything that could escalate code execution.

2. Admin-only. The API checks the caller’s session for admin-role membership on the project. Non-admin users invoking it from a backend function get a 403, not a silent write. For unattended/scheduled invocations, a project-scoped API key with explicit “filesystem-write” capability that admins create and rotate.

3. Path traversal hardening. Standard checks: reject .., absolute paths, symlinks, anything resolving outside the allowlisted directory after normalization.

4. Content validation per file type. Optional but valuable — JSON files must parse, JS/TS files must lint, image uploads must match declared MIME, etc. Reject on validation failure.

5. Atomic writes + rollback. Each writeProjectFile call is a single transaction. syncFromAppSettings writes all-or-nothing: if any file fails validation, none are committed.

6. Audit log. Every successful write logged with caller identity, timestamp, path, content hash. Visible to project admins. Catches both abuse and accidental overwrites.

7. Rate limit + size cap. Per-project rate limit and per-file size cap. Prevents runaway loops and intentional abuse.

8. Build-trigger separation. writeProjectFile writes to source but does not trigger a rebuild or republish. Builders explicitly call publish/rebuild as a separate step. A misbehaving function can dirty the working tree but cannot ship to production users without an admin clicking publish.

With all of these, the API has roughly the same blast radius as the builder AI chat — which already exists and which admins already trust to write project files. The difference is that an admin can authorize a backend function to do the same thing programmatically, instead of being the manual relay.

Why this matters

Today the chat AI is being used as a deferred file-write executor for any flow that needs to update bundled files. That’s clever as a workaround but architecturally fragile — it requires a human in the loop forever, prevents scheduled/automated workflows, and creates a manual-handoff seam in every release.

The capability already exists in Base44; this request is just to expose it through an admin-controlled, sandboxed, audited API surface.