Xuda Studio

A Xuda app is a set of typed documents, and one interpreter runs them.

Studio does not generate a codebase for you to maintain. A project is a flat set of documents, every one of them stamped docType studio, in twelve node types: components, tables, data units, routes, agents and the rest. The tree in the left panel is derived from those documents at load time, from one parent pointer on each, and is never stored as a tree of its own. The same documents are what a preview asks for by id, what a build walks, and what the runtime executes when someone opens the app. Nothing in between compiles them into a different thing.

Twelve node types, one document shape

No tree document anywhere

Any node is a shareable URL

A Xuda app is a set of typed documents, and one interpreter runs them.

Node types a project is built from

Event types a component can react to

Deployment types the same project can ship as

First party plugins, across six categories

The shape of a project

Five separate trees, and no tree document anywhere.

The left panel does not hold one tree. It holds five, and a five way icon segment above it decides which one is mounted, so tables, screens, shared state, URLs and agents are five separate address spaces rather than five branches of the same one. None of the five is stored as a tree either. Every node is a document carrying a single parentId pointer and an order_ts sort key, and a web worker rebuilds the whole structure on load by scanning for children level by level, admitting only documents whose stat is 3. Moving a node up or down is not a file move: it saves exactly two documents with their order_ts values swapped. Deleting a subtree writes stat 4 onto every document in it and leaves them all in storage, which is why the tree stops showing them and the search index stops indexing them at the same moment. Open a component and switch to its UI tab and a second tree appears below the first, the element tree of that one component, with a draggable handle between them whose position is remembered.

One studio document

docType studio, a parentId, an order_ts, stat 3

Programs

The default parent. A new node with no parent named lands here unless its type says otherwise.

eight creatable types

Components, the five function types, API units and folders

Database

Labelled Tables in the segment control, and the only section that holds data definitions.

two creatable types

Tables and folders, and Create greys out once you are on a table

Globals

The one root that refuses children outright: it carries disable_add, so Create is greyed out on it.

shared state for the project

Globals units, which open Fields and Events and nothing else

Routes

One type only. Each document here is itself a nested menu with one item starred as the default.

one creatable type

Route documents, each holding a menu tree of its own

AI Agents

One type only, and the last of the five sections in the segment control.

one creatable type

Agent units, each opening a single tab of their own

Never constructed

Seven more root ids

The constant that lists root ids still names twelve, functions, patterns, menus and modules among them. Only these five are ever constructed, and the other seven never render.

One limit worth stating. The rebuild scans every document once per level, which is exactly why it runs in a worker and not on the main thread.

A correction

Four tabs is true of a component. Every other type opens something else.

The version of this page you may have read said that screens, background jobs and API endpoints are the same kind of object with the same four tabs. The first half is true, the second is not. The editor builds its tab strip by switching on the node type, and the envelope shrinks and grows: a component gets four tabs, a batch or a data unit gets three and has no UI at all, an API unit gets four but the fourth is Output rather than UI, and five of the twelve types open a single tab or none: alert, javascript, route and ai_agent each open one editor, and a folder opens nothing at all. The strip is only rendered when a node has more than one tab, so those five arrive with no strip above them. Which tab is open is a query parameter on the editor URL, and the last tab you had on a given node is remembered per node, so coming back to it puts you where you left. The second column is the other half of the same grammar. The Create panel offers a different set of types depending on which node you right clicked, and a folder simply inherits the set of the section it sits in.

	What it opens	Where it can be created
Component	Datasource, Fields, Events, UI	Under Programs, or inside another component
API	Datasource, Fields, Events, Output	Under Programs or any other unit, never inside a component
Batch	Datasource, Fields, Events. No UI tab	Programs, inside a component, or inside any other unit
Get data (get_data)	Datasource, Fields, Events. No UI tab	Programs, inside a component, or inside any other unit
Set data (set_data)	Datasource, Fields, Events. No UI tab	Programs, inside a component, or inside any other unit
Alert	One tab, Alert	Under Programs or inside a component, nowhere else
JavaScript	One tab, Editor	Under Programs or inside a component, nowhere else
Table	Data, Fields, Indexes	Under Database, where Create then greys out on the table itself
Globals	Fields, Events	Not from the tree: the Globals root refuses new children
Route	One tab, Route	Under Routes, the only type that section offers
AI agent (ai_agent)	One tab, AI Agent	Under AI Agents, the only type that section offers
Folder	Nothing at all. Opening a folder returns early	Under Programs or Database, or inside a component or any other unit

AI app builder

The assistant writes into the same tree you edit by hand, and one mode writes nothing at all.

Describe what you want in the AI panel of an open project and the builder proposes tables, components, fields and events as ordinary documents in the ordinary tree, which is why you can open the result afterwards and change one field. The two switches on the panel are not the same switch: scope decides what the conversation is about, mode decides whether the turn is allowed to write. Inside Studio the composer also hides the model picker and the agent picker that the rest of the dashboard shows, so there is no model to choose and no agent to choose.

Plan mode writes nothing. The panel describes Auto as running end to end without interruptions and Plan as researching and proposing an approach without making changes. The choice rides on the request as plan_mode, and the server turns it into a different method with saving switched off for the whole turn.
Scope decides what the turn is bound to. In general scope the conversation references the app; in node scope it references the node you have open, as a studio_node rather than as an app. Switching scope starts a new chat and reloads the chat list, because past chats are fetched by what they reference.
The context chips are toggles, not labels. Up to three appear: the program open in the editor, a different node selected in the tree, and the UI element selected while the UI tab is open. Click one off and it is dropped from the request. Switch all three off and the turn is sent with no context at all.
The builder is one npm package with named methods, and two of those methods write plugins. app_builder saves studio documents, app_planner does not, and create_plugin_via_ai and modify_plugin_via_ai are exported from the same package. What that package does inside itself is not in the platform source, so this page describes the call site and stops there.

One turn

You describe it
In the AI panel of an open project, in general scope or bound to one node
The chips bind the context
Open program, a node selected elsewhere in the tree, the selected UI element
The last 12 messages ride along
Each one truncated to 2000 characters before it is sent
app_builder saves, app_planner does not
Accepting a plan re-sends it with an instruction to execute it end to end

What comes back

A build turn hands back a receipt naming what it changed.

The reply is not the model narrating what it did. A formatter in the platform reads the structured result and writes the message: it counts the documents, groups them by their menu type, lists up to twelve of them by name with the document id in brackets, and states whether they were saved. A plan turn renders different fields entirely, an overview, up to twelve proposed units, eight build-order steps and eight acceptance checks, and always states that it kept the turn in planning mode. When the assistant is blocked on something it needs from you it does not ask in prose either: it emits a structured question block that the panel renders as a stepper, two or three options per question, with a free-text Other row the interface appends itself. While the turn runs, the status text rotates through a fixed list of three messages, one list per mode, changing every 1800 milliseconds.

assistant reply · studio_method: app_builder

Generated 2 component, 1 table

then the created units, up to 12 of them:

component: <menuName> [<_id>]

table: <menuName> [<_id>]

and one line stating whether they were saved

Live-preview browser smoke test passed for 2 components.

that line appears only when the turn ran the test

a plan turn states this instead, having created nothing:

Kept this turn in planning mode, so no studio docs were saved.

The labels in grey are ours. What the formatter pins is the count line, one line per created unit with its id, the smoke-test line and the planning-mode line. The caps are real too: past twelve units the list stops, so a very large turn is counted in full and listed in part.

Datasource

Two engines sit behind one segmented control.

On a table datasource the filter mode is Index or Query, and when the setting is absent the runtime infers Index if an index is selected and Query if none is. These are not two skins over one planner. Index mode reads a compound key the table already wrote onto every record. Query mode reads a selector assembled at request time. What you can express, and what you are guaranteed, changes with the position of that control.

Filter mode

index or query, one control

declared on the table, named index_1, index_2

An index is a list of fields, in order

Index mode

a grid with a Key column and a Range From and Range To beside it, and those cells take expressions

startkey and endkey from your two range cells

A range scan over the view db_index

get_index_json computes it on the way in

Every save, not a background pass

The key itself

the sort direction is the scan direction, so the key order is the order you get back

the view emits table id, index id, key value

One ordered list of keys

check_unique reads that same key first

A colliding save is refused with code -22

Unique

a new index defaults to unique, and this is the only uniqueness guarantee anywhere on the data path

three views, one filter model, kept in sync

The Builder, Mongo and SQL tabs

Query mode

no range is built at all: the read is opened wide and the selecting happens down in the driver

every field name rewritten to udfData.data

A Mango find, pinned to this table

The index you did not declare

so the product has two kinds of index: the one you write down, and the one the driver writes for you

no matching index found, create it, retry

The driver builds a Mango index on first use

added to the same and clause as yours

A grid column filter the reader typed

What comes back

a count over a Mango filtered read is counted through Mango, and it stops at a scan cap of 100,000 documents

the rows, then the count

The component that asked

The honest limit is on the index side, and it is quiet. If the selected index is no longer on the table, or if the index has keys but every range cell was left empty, the filter build gives up and the read widens to a scan of the whole table. The same catch swallows anything thrown while the filter is assembled, logged as a warning and nothing more. A misconfigured index reads as slow, not as broken.

The UI tab

There is no property record. Every property is an attribute.

Select an element in the tree and the properties panel fills with rows. Those rows are not writing into a private property blob attached to the node. An element is an id, a tag name, an attributes map, children and text content, and every setting in the panel is literally one attribute in the xu- namespace. Set Bind and the markup gains xu-bind. Type whatever you like into Add Attribute and it sits beside the others as an ordinary attribute. That is why a class you wrote by hand, an attribute you invented and a control in the panel all end up in the same place, and why Edit HTML shows you the whole truth about an element rather than a rendering of it.

The panel opens with three rows, xu-show, xu-bind and xu-ref, and grows as you use the accordions below them. A further fifteen names are kept out of the free-form attribute list because each already has its own dedicated control, so no attribute is editable in two places at once.
Show and Render are not two words for hiding, and the runtime says so in its own comment. xu-show is a display toggle and the element stays mounted. A render gate flips one subtree in or out of the document, so the element is simply absent from the DOM.
Any attribute has a computed twin: write xu-exp: in front of the name, or press the fx button beside the field, and the value becomes an expression that recomputes when its dependencies change. It is generic rather than a curated list of bindable properties, so it works on src, on an attribute you typed a minute ago, and on fields a plugin declared. A value and its computed twin are the same slot rather than a default plus an override, so Studio flags an element carrying both and offers to remove the static one. One documented exception: xu-exp:class replaces the static class attribute instead of merging with it.
The limit, plainly: there is no styling UI. No spacing controls, no typography controls, no colour picker, no box model editor. Styling is a row of class chips plus a raw CSS editor, so a padding value is a Tailwind or Ionic class string you type or paste, and a conditional class is a class name mapped to an expression inside xu-class.

One namespace, and all of it ships

xu-ref, the name the element registers under

xu-bind, the field it reads and writes

xu-show, a display toggle that leaves it mounted

xu-if, xu-else-if, xu-else, one branch chain

xu-for, with xu-for-val and xu-for-key naming the loop variables

xu-class, class names mapped to expressions, stored as JSON

xu-script, xu-style and xu-cdn, attached to a single element

xu-exp: in front of any of the above, computed instead of literal

Canvas and runtime

The canvas is a layout surface. The runtime is one toggle away.

Both surfaces read the same element tree, and they do different amounts with it. The design canvas renders your markup so you can lay out and select, but it does not run your app: nested components and widgets draw as labelled placeholders, and conditions are matched as text rather than evaluated. The toolbar toggle swaps the canvas for the live preview, which is the real runtime with a Props popover for feeding test values in. Knowing which surface you are standing on explains most of the moments where a screen looks right in one place and behaves differently in the other.

The same element tree

One set of nodes and one set of xu- attributes. The toggle changes what reads them, not what they are.

The design canvas

Renders markup. Approximates the rest.

xu-panel

A nested component draws as a fixed 120 pixel dashed box whose text reads "Preview available in live preview". Its contents never render here.

xu-widget

The same dashed box. The widget plugin is not executed, so a calendar or a grid is a labelled rectangle at design time.

A condition

Approximated by one CSS rule that matches the attribute text. The expression itself is never evaluated on this surface.

A click

Resolves through the nearest ancestor carrying an internal_tree_id back to the exact node, so selection is never the wrong wrapper.

The frame

A width and a height, from 24 device presets or dragged by any of eight handles. Dark, Light and Auto add or remove one class on the preview document.

Live preview

The runtime, in an iframe, behind the toolbar toggle.

The component renders

The nested component runs, and a Props popover feeds test values into the parameters that component declares as inputs.

The widget runs

The plugin executes the method you picked in the panel, with the fields that method declares in its own schema.

The expression runs

Render decides whether the subtree is mounted at all. Show only flips display, and the element stays mounted either way.

A click is a click

The canvas has been swapped for the live preview URL, so a click does whatever your app does with it. Nothing is selected by clicking here.

The page decides

Whatever your classes resolve to in the browser it is open in. Auto in the canvas follows the theme Studio itself is in, not a viewer system preference.

Both surfaces are honest once you know which is which. In the design canvas, xu-panel and xu-widget never render their contents, and the condition attributes are matched as text rather than evaluated. Everything that actually runs, runs on the other side of the toggle.

Execution

A workflow is a job queue, not a list of awaits.

An event does not run its actions one after another. It walks the workflow once and pushes one job for every enabled step onto a single array held on the session, and a separate drain loop running every millisecond takes the first job that is not already marked busy and executes it. Order is array order, top to bottom. The thing that starts the next step is not the previous step finishing, it is the previous step deleting its own job. The async flag is one line inside that loop.

An event fires

The event condition is read first, before any job exists.

Exit

Event condition false

Nothing is queued at all. Put a watch on that event and the skipped run still writes a trace line marked not executed, so you see the step that did not happen and the condition value that skipped it.

Every enabled step is queued

One job object per action, pushed onto a single array held on the session.

Exit

The step checkbox is off

An action with enabled unticked is skipped inside the queueing loop and never becomes a job, which is why switching one step off to test the rest is safe.

The drain loop picks one

A one millisecond interval takes the first job that is not already marked busy.

Execute reads the async flag

The only place the flag is read, and it is read before the handler, not after it.

Exit

Async is on

The job is deleted here, before its own handler runs, so the queue advances immediately while the step is still in flight. That is the entire effect of the flag, and it is set per action rather than per workflow.

The action condition is read

Evaluated at the head of the queue, not when the job was queued, so step four can test what step two just did.

Exit

Action condition false

Only this job is dropped and the workflow carries on. An expression that throws is treated exactly like false, so the step is skipped silently rather than failing loudly.

The handler runs

A screen blocker is up for the duration, which is why a slow step freezes the screen on purpose.

The job deletes itself

delete_job splices it out and clears the busy flag, and that is the signal that starts the next step.

What is not in this picture: no branch, no loop and no parallel block. Repetition comes from a client interval event or from calling another program, and the only concurrency primitive on the page is that per action async flag. Nesting is a splice rather than a stack: a step that calls another program has that program jobs inserted directly behind its own, so they run before the next step of the caller. No upper bound on concurrent async actions appears anywhere in the source.

The action catalogue

Twenty-four actions in nine groups, and the argument each one reads.

The Add Action picker is built from one catalogue file, and outside the AI entries every action agrees three ways: the catalogue, the handler map in the runtime, and the validator registry that records the payload key each action reads. That registry is the right hand column. Two things before the table. Invoke Action offers eleven values in its dropdown and nine of them work, because act_close and act_back are commented out of both the runtime and the validator allowlist. And seven older UI element actions are hard rejected as deprecated rather than quietly tolerated. You can also make an action without the picker: drag a node from the tree onto the workflow and the node type decides the action, so a get data node becomes Get Data and a component becomes Call Page. Drop it onto a row that already exists and it retargets that row instead of appending a new one.

	The actions in the group	What the action reads
Navigation, 3	Call Page, Call Modal, Call Popover	Each one names the component to open, and that is the whole payload.
Database, 3	Get Data, Set Data, Batch	The datasource unit to run. Set Data and Batch also name the field their result lands in.
JavaScript, 4	Call Native JS, Call Evaluate JS, Execute Native JS, Execute Evaluate JS	The two Call actions name a JavaScript program unit in the tree. The two Execute actions carry the code itself, typed into the action.
Event handlers, 4	Raise Event, Emit Event, Invoke Action, Delay	Raise Event names an event plus its parameters, each one a literal value or an expression. Invoke Action reads one of the nine allowed values. Delay reads a number of milliseconds.
UI utilities, 4	Call Alert, Alert, Loader On, Loader Off	Call Alert names an alert unit. Alert carries its own display mode, type, title and body. The two loader actions read nothing.
API, 3	Call Project API, Call System API, Call External API	A project API names a unit in your own tree, a system API names a method, an external API takes a URL and an HTTP method.
Dataset, 1	Update	One value, written as "@field: expression; @other: expression", or as a JSON5 object.
Plugins, 1	Call Library	The plugin name and the method on it, so a purchased library reads like every other action in this table.
Comment, 1	Comment	Nothing. The registry describes it as documentation only, and the runtime handler does nothing but delete its own job.

Down to real code

The escape hatch is a path, not a text box.

Seven places let you stop configuring and start writing, and the deepest of them is not an action at all: a JavaScript program is its own unit in the tree, with its own build output and a documented set of things handed to it. Two limits belong in the same breath. The validator does not parse a JavaScript body, so a syntax error surfaces from the build as a failed compile rather than from the checker, which only warns when the script is empty. And an inline script or style attribute on an element must not contain a quote character at all.

A program body is handed ten named arguments: params, xu, SESSION_ID, SESSION_OBJ, jobNoP, $container, func, glb, APP_OBJ and evt. With no top level import or export it is wrapped in an async function, so top level await works.
Write an import or an export and it becomes a real ES module instead. Relative specifiers are rewritten against the scripts folder for that program, so a unit can import its own sibling files.
Saving a JavaScript unit fires a Vite build without blocking the save. At run time the engine prefers the built module, cache busted per build, loads a stylesheet only if the module exports one, and falls back to running the source with warning code RUN_MSG_JS_010.
The xu object a script receives is a fifteen method API: read and write a field, invoke an event, four database calls, call another script, three kinds of API call, alert, log, and read or write the drive. Inline code is a different shape again, wrapped as an async function and called with the element and the browser event.

Every door, all of them shipping

An expression slot, including both condition slots

A JavaScript program unit, built on save

Call JavaScript, running that unit from a workflow

Execute JavaScript, inline code handed the element and the event

xu-script on one element, run when it first becomes visible

xu-style and xu-style-global, scoped or not, on one element

xu-cdn, an external CSS or JS URL loaded before the node renders

Live preview

The preview is a peer of your editor, and it is allowed to give up on you.

A preview session opens on a channel named after your session token and asks your open tab for documents one id at a time. Studio answers out of memory with a copy of the document on your screen, so there is no bundler anywhere in that path and a saved change is in the running session immediately. There is also a deadline. If your tab has not answered within five seconds, that session switches to the built copy on the server and never asks you again for the rest of its life.

Your open Studio tab

holds every open document in memory

the session asks

get_doc_obj, with the document id

Documents, by id

one ask per document, and Studio simply stays quiet for a document it is not holding

answered from memory

A deep copy of the document open on your screen

The five second latch

a slow tab and a missing document look identical from the preview side, so the fallback is driven by the clock

no answer in five seconds

The session reads the built copy from the server, and stops asking your tab for the rest of the session

You save a document

the whole document travels, to your other Studio tabs and to every connected preview

a code change

studio_doc_saved, after which only the rendered panels bound to that document re-render in place

relayed from the server socket

document_changed

A record changes

a different channel doing a different job, and the payload carries a table id rather than a document

a data change

Only datasources with realtime switched on and a matching table id refetch

A preview in your canvas

an iframe carrying ten fixed query parameters, plus any test props you typed into the params popover

no network hop at all

A broadcast channel named for your session token

A preview anywhere else

pinged every eight seconds and dropped when nothing comes back within four

admitted one by one

A tester on their own phone, over a data channel you approve by hand and can close

drives one session at a time

Get session, screenshot, inspect, hard reload, run a command

The console

nine services, one envelope, whichever session you have selected

One correction to what this diagram used to say. The nudge on save is not document_changed. A saved code change travels as studio_doc_saved and carries the whole document, which is why the preview re-renders the panels bound to that document rather than reloading the page. document_changed is the other channel entirely, relayed from the server socket room, and all it does is refetch realtime datasources whose table id matches. The five second latch is the honest cost of the whole arrangement, and it is why Hard Reload is a first class button rather than a debug afterthought.

The console

The command box is eval, running inside the page you are previewing.

There is no command vocabulary to learn, because there is no command set. What you type is sent to the preview as one string, evaluated there, and the result is sent back and rendered as a tree two levels deep. Anything the running page can see, you can see: the session object, the datasources, the runtime helpers. A throw comes back with an error flag and renders red. Inspect is the other half: switch it on, every element carrying a ui id outlines under the cursor, and clicking one sends back the component that owns it and the node inside it, with a button that opens that component on its UI tab and selects the node in the tree. That is a pixel to a node in two clicks.

... connecting to the session

$ new URLSearchParams(location.search).get("engine_mode")

"live_preview"

$ typeof func.index.delete_pouch

"function"

$ SESSION_OB.root_element

SESSION_OB is not defined error: true

inspect on . every element with a ui id outlines under the cursor

click a pixel in the preview

live_preview_element_reference_result { prog_id, node } [ Open ]

Open . the owning component opens on its UI tab, and that node is selected in the tree

get session . live_preview_session_result

{ __type: "Element", tagName, id, className } "[Circular]" "[Function name]"

root_element, WORKER_OBJ and DS_UI_EVENTS_GLB are stripped before it is sent

The prompt is a dollar sign once the session reports ready, and three dots while it is still connecting. Arrow up walks the commands you typed, in memory only, so a reload starts you with an empty history.

Saving

A save is a local write. The version is written by something else, afterwards.

There is no autosave. Pressing save hands the document to a worker, which stamps it and writes it into a database inside your browser, and that is the whole of what your keystroke does. Everything after it is other machinery: a broadcast to your other tabs, replication out to the app database, and a server process watching that database which is the thing that actually mints a version. The order matters, because it tells you what survives a dropped network and what does not.

You press save

one document, or Save All for every tab holding unsaved changes

Exit

Version preview active

If the history popover is previewing an older version of this document, the save is refused before anything is written. A preview cannot be committed by accident.

A worker writes it locally

the document is stamped with a timestamp and your user id, then put into a database inside your own browser named after the app

Exit

Conflict on the local write

The worker does not merge. It fetches the server document under a ten second deadline, copies the server revision onto yours and retries the write straight through. Last writer wins, and the loser is not asked.

Your other tabs hear it

a broadcast on a channel named for your token, carrying the id, the revision, the timestamp and which tab sent it, so a tab can skip its own echo

Replication carries the revision

the same write leaves the browser and lands in the app database on the server

A change reader picks it up

a server process watching that database, not your editor, sees a studio document arrive and calls the capture

Exit

Content unchanged, no version minted

Before inserting, the capture strips fifteen fields plus the script dependencies and compares a signature that ignores key order against the newest snapshot. If they match it skips, which is how build worker metadata writes avoid minting versions nobody made.

A snapshot is inserted

the id is the document id, the timestamp padded to fifteen digits and the revision, so a replay of the same capture lands on the same id

Exit

That id already exists

Because the snapshot id is derived rather than generated, a second capture of the same revision collides with itself and is treated as already recorded rather than as an error.

History is trimmed

the newest fifty snapshots per document are kept and the older ones are bulk deleted

The consequence is the honest part. Your work is safe from a dropped network because the first write is local, but the version is not yours to time: the pill can read v and an ellipsis for a moment while the capture lands, and the popover re-polls on a fixed backoff of 1200, 3000, 6000, 12000 and 24000 milliseconds until it resolves. The same shape has a payoff. Because the capture watches the database rather than your editor, an edit written by a plugin or by a server process is versioned in exactly the same way as an edit you typed.

History

The pill has four states, and one of them says your tab is out of date.

The label next to the editor is derived, not stored: it compares the revision you have saved against the newest snapshot on the server. Current means an exact snapshot for your revision exists, or that the difference is only build metadata. Recording means your revision is ahead and the capture has not landed yet. Behind means your saved revision is older than the newest snapshot, so this browser session slept through revisions, and the popover says so in a banner instead of claiming you are current. Unknown means same generation, different content, which the source calls a divergent branch. Selecting an older row previews it in place with your working copy held by reference, and while a preview is up both save paths refuse the document outright. Restore is the only action that writes: it re-reads the live revision from the server first, asks before overwriting a change that arrived while you were looking, asks again before discarding your unsaved edits, then chains onto the freshest known revision so the restore lands cleanly at the head.

Working copy in your editor

unsaved changes live here

first save

the one you want back

current

what restore creates

Preview

preview in place, saving is blocked, escape puts your working copy back

Restore

restore saves forward, so the restore is reversible too

save, captured on the server a moment later

What is not here, in full: no branches, no compare or diff view, no merge, no commit messages. History is per program rather than per project. The version numbers are positional, so v3 today is not v3 next week. Fifty snapshots are kept per document and the rest are deleted rather than archived. The capture is asynchronous and server side, so a fresh save reads as recording until it lands. And undo is a different system that shares nothing with this one: fifty steps per document, collapsed at four hundred milliseconds so a drag or a burst of typing is one step, scoped to the node you have selected, held in browser memory only, and gone the moment you reload. After a reload, this rail is the only way back.

Two editors

There is a lock. There is no merge.

The lock is a check-in, and it is per node. Saving is gated on it: a node checked in by someone else refuses with the name of whoever holds it, and a node nobody has checked in refuses with Please check-in after walking up the parent chain to see whether anything above it is held. Drafts are exempt, and so is an app that has never been saved. What is not locked is the outcome once a revision from someone else does reach a document you have open. Studio decides between exactly three, and it computes whether you have unsaved edits before it updates its baseline, which is the ordering that makes the answer trustworthy.

01
Your copy is clean, so you take theirs whole
Nothing of yours is at stake, so Studio fast forwards the open document to their revision wholesale and refreshes the tab flag immediately rather than waiting for the throttled watcher. You find out because the content changed under you, not because a dialog asked.
02
You have edits, and their write was the compiler
Studio compares the two documents with the revision list, the studio metadata, the build result, the build error, the three timestamps and the script dependencies stripped out. When what is left is identical, the arriving revision is the build worker saving its own output. Your edits stay exactly where they are, only the revision and the build fields are adopted, and you are not told, because nothing happened to you.
03
You have edits, and their content really differs
Every edit of yours is kept and only the revision is bumped, so your next save chains onto theirs instead of colliding. Then you are warned for twelve seconds: a collaborator saved this document, and your unsaved edits will overwrite their changes when you save. The warning has exactly one action, discard mine and use theirs, which replaces your working copy with the server document. Ignore it and save, and your version is the one that survives. There is no field level merge, no diff, no presence and no shared cursors.

Validation

One checker file, run in your browser or on the server depending on where you are.

Validation is not a service somewhere else. It is a single file, runtime/js/modules/xuda-studio-checker.mjs, 4,714 lines, imported directly by the Studio front end and imported by path on the server by the app module. Studio decides at call time which host runs it. Online, on a project that is not a draft, it fires run_programs_checker as a background job. Offline, or inside a draft, it runs the same check over every program in the browser and commits a result of the same shape. Findings split into errors and warnings on nothing more than a type field of E or W. Then the honest part: it does not stop a build. build_app takes ignore_errors with a default of true, no caller in the product ever sends false, and the error total is written into the release itself, so every version on record carries the number of errors it shipped with.

Eighteen check functions dispatch across eleven program types: globals, table, component, javascript, get_data, set_data, batch, api, alert, route and ai_agent. A folder is a deliberate no-op, and anything unrecognised raises CHK_MSG_GEN_050.
A server run writes one check document per program, keyed on that program revision, so a program nobody has touched since the last pass is skipped outright rather than rechecked.
Every code in the generated catalog carries the same fields: title, severity, domain, category, summary, causes, resolution steps, a help slug, legacy patterns and related codes. It is generated from the error registry, not written by hand.
The two hosts do not produce identical output. The server run is initialised with the deployment list and can mark a program as used by a deployment. The browser run is not, so the not-in-use verdict differs between them.

Largest checker code families, by references in the checker source

CHK_MSG_OBJ_GEN

81 references

General object rules, by a wide margin the family you meet first

CHK_MSG_PRG_TRG

48 references

Workflow triggers, the second heaviest surface in the tree

CHK_MSG_PRG_FLD

17 references

Fields, including what a field is allowed to be computed from

CHK_MSG_PRG_AGN

17 references

Agents, tied with fields for third across seventeen families

Shipping

A build and a deployment are different objects, and a release sits between them.

Building writes a numbered snapshot. Deploying points a machine at one. The number on the badge, #37, is app_build_id, a per project counter that steps up by one every time build_app runs. The 1.4.0 next to it is a separate string you type, validated by a plain major, minor, patch pattern in the badge itself. They move independently, and both are stamped onto the deployment document so a deployment always records exactly which snapshot it is serving.

Your project tree

Every program document in the project database at stat 3, which is the only state a build reads

build_app

Seven named job steps: checking app, setting build information, getting app assets, saving build data, saving release note, creating build folder, publishing release notifications

Release #37

A release document with the note and version, one deployed_app document per program tagged with this build, and a build folder on disk with nine directories created and ten platform paths copied in

Exit

No release, no deployment

Called without a release id, deploy_app returns code -2 with the message that release_doc_id is a mandatory field. A project that has never been built cannot be deployed. The single exception is an account project, and that path quietly runs a build first and uses the release it just made.

deploy_app, given a release id

Writes the deployment document, optionally a datacenter document, asks the host for a machine asynchronously, and returns

Exit

Two configuration gates before a machine is requested

A type outside the allowed list comes back as a deploy type error. A type on the beta list comes back as a deploy type in beta. Both lists are environment configuration rather than product code, so the picker offering a type is not the same promise as the API accepting it.

A deployment running #37

Its own machine, its own status code, its own build number, and its own set of programs and tables

When build #38 lands, every deployment of the project under status code 4 gets update_required set to true and a new_version_available notification carrying the new build id. Nothing is copied to any machine by that, and this deployment keeps serving #37 until someone moves it. Moving one deployment onto a new build is update_app_version, a separate ten step job at admin clearance. It reconnects over SSH with up to ten attempts at ten second intervals, rsyncs the drive, recomputes which programs and tables this deployment may reach, deletes and re-copies both the program directory and the runtime directory, reinstalls the plugins package, runs pm2 delete all, restarts the websocket router and the ecosystem, purges the CDN and writes a fresh startup bundle. The processes go down and come back. Two deployments of the same project can sit on different build numbers indefinitely, and nothing reconciles them for you.

Provisioning

Pressing deploy does not install anything.

The deploy call is the first half of a handshake. It creates records, requests a machine and returns while the machine is still being made. The install starts when the machine itself calls the platform back, which is why the progress bar can sit still for a while in the middle and why the status ladder has a waiting rung on it at all: 1 created, 2 installing or waiting, 3 active, 4 failed or terminated.

01
The form returns before anything exists
deploy_app writes the deployment document, optionally a datacenter document, asks the host to create a machine asynchronously, and returns to you. Nothing has been installed and nothing has been copied. The deployment sits at status code 2 under the description farm server waiting to install, and there is genuinely nothing further to show until the next step happens on its own.
02
The machine calls the platform back
First boot on the new machine curls a webhook at the platform carrying the app id. That handler reopens the same job you are already watching, replaces its step list with the twenty four entry install list, and runs install_hosting_resources. The job you started for phase one is the job that reports phase two, which is why the step names change under you partway through.
03
The install runs, retries if it has to, and lands at status 3
The install is wrapped in four attempts with a thirty second delay, because a machine that has just been created may still be rebooting when the first SSH connection arrives. It writes the pm2 ecosystem file, runs pm2 delete and then pm2 start against it, and finishes at status code 3, server ready. This page does not quote a duration for any of it, because nothing in the source records one and we did not measure it.

Deployment types

Sixteen deployment types, and what each one actually runs.

The same project ships as sixteen declared deployment types in four groups: six web, five server, three desktop and two mobile. Each type also declares its own tab set off a fourteen tab base list, so a cron deployment drops launch, domain, firewall, analytics and user assist and resolves to nine tabs, while an MPA keeps all fourteen and the five artifact types insert a publish tab instead. Grouped by what the install actually writes into the pm2 ecosystem file, fifteen of them collapse into five shapes. The sixteenth, mcp, is declared alongside the rest and has no ecosystem entry of its own that we could trace.

	What runs on the machine	What it launches
Web: spa, mpa, pwa, embed	One pm2 app named webserver, exec mode cluster with instances set to max, plus a systemd unit for the websocket router	The build stamped runtime bundle over HTTPS on port 443, bound on a dual stack socket
Web: preview	The same webserver app, and a second pm2 app named preview	A Nuxt server output on port 3023 alongside the app itself
Web: user group	The same webserver app, and a second pm2 app named user_group	A Nuxt server output on port 3022 for the group surface
Server: cron, api, node, emitter	A single pm2 app in exec mode fork, running that type entry file, xuda-cron.mjs or xuda-api.mjs and so on	The server bundle for this build. A cron fire forks a child, waits for it to report ready, sends it the run, and logs what comes back
Artifacts: ios, android, macos, windows, linux	Nothing. The macOS path deliberately bypasses the deploy call and writes a deployment document with no hosting machine behind it	A publish tab, and a dispatch to an external build service. We traced enough to know this is a different pipeline, not enough to describe it here

The runtime

One interpreter, two sides, one call.

What a deployment actually ships is not generated source and not a compiled blob. It is an interpreter bundle plus your program tree as JSON, and the same interpreter runs on both sides of the wire. In the browser that is one script tag and one constructor. On the server it is one dynamic import of the sibling bundle and one flag. When a page is rendered server side, the server asks the worker to run a program to a string, and gets back both markup and a payload. The payload is inlined into the page, and the mount element is marked with the render mode and the client activation the server resolved for it.

Your program tree, as JSON

The same documents the build wrote, one per program, tagged with the build number

In the browser

One script tag and one line of JavaScript

xuda-runtime-bundle.min.37.js

Around 1.18 MB minified in this repo, 1.93 MB unminified. The build number is inside the filename, because every runtime file is renamed to carry it. There is no content hash anywhere in the chain: the build number is the asset address.

new xuda(element, options)

One constructor against the mount element. The options carry app id, app token, build id, version, regional server, the three runtime mode fields, three feature flags and the launch context.

func.datasource.prepare(...)

The runtime prepares a datasource through the same entry point the server uses. Nothing about this call is browser specific.

cache_37_DOCS_OBJ_<prog_id>

Programs live as rows in the browser database, in a key namespace stamped with the build, so a new build simply never reads the old cache. On a miss the runtime does not make an HTTP request: it asks the deployment over its own websocket and waits for the answer.

On the server

One dynamic import and one flag

xuda-server-bundle.min.37.mjs

Around 309 KB. The worker imports it by that exact build stamped name, which is why the two sides can never accidentally run different builds of the interpreter.

glb.IS_WORKER = true

The default export hands back the function root, the globals object and the app, project and session objects. The worker sets one flag on the globals to say it is the server side, and that is the whole difference in setup.

func.datasource.prepare(...)

Identical call, different fourth argument. Server side rendering, the API deployment and the cron deployment are all this same call with a different mode.

/var/xuda/progs/<id>.json

Programs live as one file per program on disk, read straight off the filesystem. A version update deletes that whole directory and copies the new set in, so the files on the machine are exactly the build it is serving.

Two limits worth carrying out of this picture. There is no per app tree shaking: every deployment ships the full bundle for its build and only the program JSON differs, and although slim and mini bundles exist in the runtime directory, the deployment renderers reference the full one. And whether the right lane exists at all is a per deployment setting resolved at every page render: computing mode resolves to main, worker or server, and main and worker both force client rendering with no server activation, which leaves the browser doing all of it.

Plugins

The category in the package name decides where a plugin shows up.

All 62 first party plugins are named the same way, and the category in that name is also on the plugin record. That is the whole routing rule: install one and it turns up in the datasource picker, the insert toolbar, the icon picker or the workflow action list, with nothing to wire up. An install is not a feature flag either. The server writes a record onto the project carrying the version, the type and the file manifest, runs a real npm install into the plugin directory for that project, syncs that directory out to the servers, and copies the whole package file tree into the project database keyed by relative path.

62 first party plugins

named xuda, category, plugin, name

Insert stays disabled until an element is selected

The canvas selection

widget, 27 shipped

grids, calendars, charts, maps, scanners

becomes an element

The UI insert toolbar

run in background is recorded per install

The record on the project

library, 15 shipped

Stripe, Twilio, Firebase, docx, xlsx, and the AI app builder

becomes named methods

Workflow, Add Action

ui, 10 shipped

date pickers, phone parsing, sorting, tooltips

attaches a behaviour

An element you already have

graphics, 5 shipped

Feather, Heroicons, Iconoir, Phosphor, Tabler

becomes a set

The icon picker

any driver but the built in one also asks for an account

Creating a table

dbs, 3 shipped

Xuda, CouchDB and MySQL

becomes a connector

The datasource picker

the menu is the installed ones, plus None

Creating a component

framework, 2 shipped

Ionic and Tailwind

chosen per component

Component creation

a child names one parent, and that parent must list the child

authorized_plugins on the parent

Parent and child

the one relation all six categories share, checked before anything is written

refused before npm ever runs

The install stops with a numbered code

Two of the four refusals are about that pair: minus three when the named parent is not installed in this project, minus four when the parent record does not list this child. The other two are minus one for a plugin that does not exist and minus two when the caller asked for free plugins only. The consent runs deeper than convenience, because a plugin server file merges into the same script object as its parent, so a first party plugin that depends on a third party one is downgraded to third party trust.

Honest limits

Nine things Studio does not do.

The prompt box on the Studio start screen does not build anything: it sends one plain chat request capped at 1024 tokens, and with messages hidden the reply is not even rendered, because the builder lives in the AI panel of a project that is already open.
Choosing Template does not open a gallery inside the editor: it opens the dashboard create wizard in a second browser tab, and the project it forks is a snapshot with nothing linking it back to its source afterwards.
A draft is not on a server: it lives in one browser profile on one device until you press Save, and clearing site data ends it.
The check-in claim that gates saving is not a server lease: it is a field on the document, so a save that never reaches the server never clears it, and nothing merges two edits for you.
Nothing can make a build fail on validation errors: the checker runs first and its error total is written into the release, but no caller asks the build to refuse.
A finished build does not touch anything that is already live, and two deployments of one project can sit on different build numbers for as long as you leave them there.
There is no staged rollout: the build badge can render a staged but not live banner, but a normal build assigns the staged and the live number the same value, so that banner cannot fire.
There is no per app trimming of the runtime, so every deployment ships the same full interpreter bundle for its build and only the program JSON differs.
A scheduled deployment will not run a screen, only batch, get_data and set_data programs, and a server side JavaScript step is stopped at sixty seconds.

Before you commit

The questions you are forming right now

Every one of these seven answers ends on a limit. They are here because you would meet all seven in week one anyway.

Watch

See Studio open a project and fill in the tree.

Open an empty project and watch what gets written.

Two documents, one route, and the editor is open. Nothing reaches a server until you save, and nothing reaches a visitor until you build, and then move a deployment onto that build on purpose.

A Xuda app is a set of typed documents, and one interpreter runs them.

Five separate trees, and no tree document anywhere.

Four tabs is true of a component. Every other type opens something else.

The assistant writes into the same tree you edit by hand, and one mode writes nothing at all.

A build turn hands back a receipt naming what it changed.

Two engines sit behind one segmented control.

There is no property record. Every property is an attribute.

The canvas is a layout surface. The runtime is one toggle away.

A workflow is a job queue, not a list of awaits.

Twenty-four actions in nine groups, and the argument each one reads.

The escape hatch is a path, not a text box.

The preview is a peer of your editor, and it is allowed to give up on you.

The command box is eval, running inside the page you are previewing.

A save is a local write. The version is written by something else, afterwards.

The pill has four states, and one of them says your tab is out of date.

There is a lock. There is no merge.

Your copy is clean, so you take theirs whole

You have edits, and their write was the compiler

You have edits, and their content really differs

One checker file, run in your browser or on the server depending on where you are.

A build and a deployment are different objects, and a release sits between them.

Pressing deploy does not install anything.

The form returns before anything exists

The machine calls the platform back

The install runs, retries if it has to, and lands at status 3

Sixteen deployment types, and what each one actually runs.

One interpreter, two sides, one call.

The category in the package name decides where a plugin shows up.

Nine things Studio does not do.

The questions you are forming right now

Two of us have the same project open. What happens when we both save?

Does the prompt box on the Studio start screen build my app?

Is a draft a real project?

What does a build actually produce, and will it stop me shipping errors?

If I build, does my live app change?

Can Xuda serve a page that is rendered on the server?

What happens when I install something from the marketplace?

See Studio open a project and fill in the tree.

Open an empty project and watch what gets written.