Canvas — overview

What this accomplishes

Use Canvas as the front-end view of the selected worktree. It maps the project, previews supported UI, keeps source files canonical and marks code it cannot safely rewrite instead of creating a second, drifting layout.

Greenfield Miton projects begin with the App Kit design floor. Imported projects keep their own design; Miton runs a read-only alignment check and offers Realign with App Kit or Keep my design. It never silently applies the kit to an existing front end.

This page is the overview. Task guides below cover each tool in detail. See also /for-makers.

Current availability

This page documents behaviour verified in Miton development builds. Miton is still pre-release and is not publicly downloadable; invited beta users will receive a signed desktop build with automatic updates.

Before you start

• A Miton development build, an active project and Canvas open.
• A connected model and permission to write project files when the task changes the app.

What Canvas does

Canvas is for visual work on a real front end. You can:

• Follow the branch or worktree selected for the project.
• Inspect the Architecture Map across front end, back end, data and infrastructure.
• Preview and directly manipulate UI within Canvas’s supported representation.
• Ask the shared project Chat to make source changes and inspect the resulting Code diff.
• See code-owned regions without pretending Canvas can rewrite them losslessly.
• Compare the worktree with main before accepting a change.
• Apply the App Kit design floor to new projects or explicitly realign an imported front end.

How Canvas fits with the other lenses

Miton shares one agent engine across Chat, Writer, Canvas, Code, and Automation. Each lens defaults to different tools:

• Code — code editor, search, sub-agents, per-turn rewind.
• Writer — rich-text editor, citations, export, tracked changes.
• Automation — visual workflow graph, scheduler, webhooks, run inspector.

They share one project conversation, Plan, Goals, knowledge and revisioned artefact state. Canvas and Code already belong to the same project; no manual transfer or promotion step is required.

Default tools

Canvas exposes three agent tools:

• canvas_read — read the current page’s component tree.
• canvas_edit — apply one edit: add or remove a component, set a prop, style, or class list, wire or clear a data source, or replace the whole design token set.
• canvas_improve — ask the agent for improvement suggestions on the current page.

Adding a page, wiring a data source and publishing are UI actions you take directly in Canvas rather than agent tool calls.

Pages in this section

• Canvas builder — component library, live preview, multi-page and responsive preview.
• Design tokens — the token system and generated design directions.
• Form builder — field types, validation, and data binding.
• Local data — local SQLite and hosted data sources.
• One-click publish — publish flow, subdomain, versioning, rollback.
• Marketplace — themes, skills, sub-agents, workflows, and templates.

Shared topics (models, memory, permissions, cost) live in the Docs index. Engineering detail lives in ../../architecture/.

What success looks like

Canvas shows the front end from the selected worktree, the Architecture Map explains the project shape and Code exposes the same changes. Imported designs remain untouched unless you explicitly choose realignment.

Common failures and recovery

• Confirm Canvas is editing the intended project and page.
• Check the selected breakpoint, project permissions and model connection.
• Use Compare with main when the selected worktree is not the state you expected.
• If Canvas marks a region as code-owned, continue in Code rather than forcing a lossy visual edit.

Related next action

Start with the Canvas builder to turn a project brief into a working interface.