Studio Canvas tab

The Studio's main region has three tabs: Canvas, Code and Automations. The Canvas tab shows the app as boards and pages. Double-click a page chip on a board to open the page in the visual builder: a palette of blocks, an outline of the page, the page itself, and an inspector for the selected block.

Every gesture in the builder is one edit to the app's Yoke source. Switch to the Code tab and the line you changed is there; type a line in the Code tab and it shows up on the canvas. There is one text behind both views, and one undo history.

Pages by drag and drop

Drag a block from the palette onto the page, between two blocks, or into a container at any depth. Drag a block by its handle to move it. The palette offers only the blocks the page kind accepts: a detail page takes fields and sections, a list page takes boards, lists and stats, and any page takes the generic blocks such as headings and paragraphs.

The inspector

The inspector offers exactly the properties the language accepts for the selected block, with the control that fits each one: a field picker for a field, a checklist for a column list, a sort control, an expression editor that checks as you type. A property outside a block's shorthand is under Advanced; setting it rewrites the block in its long form, after asking.

Reveal takes the selected block to its line in the Code tab, and a line in the Code tab can be revealed on the canvas. The breadcrumb above the code names the block the cursor is in.

Design mode

The builder draws the page with the app's own renderers, so a list looks like the list your users will see and a detail page looks like a record. The rows come from the app's seed — the sample records the source declares — not from any workspace: the badge above the frame says how many sample rows the page has and which user the page is rendered as. A detail page has a record picker to choose which seeded record the page shows.

While designing:

• Double-click a heading, a paragraph, or a section, stat or action label to edit its text in place. Enter commits, Escape cancels.
• Drag the dividers in the width bar above a selected columns block to set the column widths.
• sm / md / lg resize the frame to a phone, tablet or desktop width.
• Outline switches to a labelled card per block, useful for a page with little content yet.

Sample data is a preview aid. Services that need a workspace — files, payments, users, sending — are unavailable in the frame and their blocks show a placeholder instead. Queries that join or group show a placeholder too; use Preview against a workspace to see those.

Views

A view is a piece of a page you name once and mount wherever it is needed: a lead card, a row in a list of invoices, a summary strip. Views live under the Views pillar of the explorer, and opening one puts its elements in the builder exactly like a page, with the view's parameters bound to a seeded record so it renders with sample data while you work.

Two gestures move content between pages and views:

• Extract view… in the inspector lifts the selected element, with everything inside it, into a new view declaration and leaves a use in its place. The view's parameters are worked out from what the element reads: the page's record, or the row of an enclosing each.
• Inline view on a use puts the view's elements back in place and removes the declaration, as long as nothing else mounts it.

Inside a view, values are written against its parameters (lead.company), and an each inside it runs its own query through the workspace's data layer with the same permissions as any list.

Components and single-page app pages

Some parts of a page need code: a card reader, a signature pad, a map. The builder keeps them as typed boundaries. Add a component from the command palette ("Add component…"): the builder writes its declaration into the source, creates the file beside it and opens the file in the Code tab. The Components pillar in the explorer lists every component with its file, its props and where it is mounted; selecting one shows the declaration card in the inspector, where you rename it (every mount follows), edit its props, tick the grant words and point it at a different file. Deleting a component that a page still mounts is refused with the list of places to fix first.

Mount a component on a page from the palette ("Mount component: …") when the page can bind its props: an entity prop needs this on a detail page or a matching parameter in a view. The mount's inspector is generated from the declared props, so a text prop gets a text control, an enum its choices, an entity prop the bindings the page offers, and each change rewrites the use line. Once the draft's files build, the mount renders the real component in design mode with the sample record you picked; until then, or when the build fails, the card says why.

A single-page app page ("Add single-page app page…") is a directory of React beside the source. The explorer lists its files under the page, with "create index.tsx" writing the entry that routes on the page's URL contract; the page node on the canvas shows its grant, and the inspector edits the title, the directory (its files follow) and the grant. The page itself runs in the live app after Build.

Asking the assistant

The Ask control in the builder's header offers a few things the tenant's assistant can do for the selected element or the page: describe what you want and it rewrites the body, fix a problem from the Problems panel (each row with a location has a Fix… button), or explain what an element does. A reply never lands as text: the platform applies it to a copy of the source, compiles and checks that copy, and shows you the change as a preview you accept, reject or edit before applying. What you accept is one ordinary edit to the source, so undo works as usual.

On a tenant without an assistant configured, the same ask is handed to you as a pack to give to any assistant you use, and the reply you paste goes through the same check before it is previewed.

The assistant in Studio

The AI Assist tab at the bottom of the Studio is a chat about the draft you have open. It sees the app's source, the files beside it, what you have selected, the Problems list and the file open in the Code tab — and nothing else: no records, no other apps. Ask what a page shows, why a problem is reported, or how a view is used, and the answer cites the source. Each citation is a button: a declaration or an element selects it on the canvas and shows its line in the Code tab, a problem opens the Problems panel, a file opens its tab. An answer that cites nothing Studio can find in the draft is marked so.

When you ask for a change, the assistant does not edit anything. It proposes one of the builder's asks — rewrite this body, fix this problem, make a view from this, write this component — as a card under its answer. Apply… runs that ask the way the Ask control does: the platform applies the result to a copy of the source, compiles and checks it, and shows you a preview to accept, reject or edit. What you accept is one ordinary edit, so undo works as usual, and the conversation notes what landed so the next answer knows. A proposal that no longer matches the source (you edited meanwhile) cannot be applied; ask again.

A few shortcuts skip the chat turn: type /describe, /fix, /view or /component followed by what you want and the matching ask opens on your selection; /handoff opens the hand-off view; /clear starts the conversation over. The command palette's Ask the assistant… opens the tab with your selection in context.

The conversation is saved with the draft, so reopening it shows where you left off (the last forty turns). The hosted assistant needs the Pro tier, an admin role and a model key in the tenant's settings, and each turn counts toward the tenant's daily allowance of assistant calls; when the allowance is used up, or no key is configured, the Hand off view gives you the same context as a pack for any assistant you use, and a reply you paste goes through the same check before it is previewed.