Use the canvas to author a design, Preview to exercise its runtime interpreter, and generated output plus a consumer build to verify what will ship. A good test covers structure, visible state, interaction, responsive behavior, dependencies, and failure paths.
Coverage: UI + MCP. MCP adds structured runtime inspection and debugging; the desktop host is required for host-assisted operations.
The editor canvas shows authored design structure and direct manipulation.
Runtime Preview executes Component/Page behavior, responsive selection, variants, themes, logic, data, and animation.
Generated output shows the React/SCSS and related modules produced from the model.
A real consumer build proves destination-specific compatibility.
Do not accept one of these as proof of all the others.
Before opening Preview, list the meaningful combinations:
base and boundary responsive widths;
default and public variants;
each theme that changes semantic values;
stored test cases and important property combinations;
signed-out and documentation-safe Preview identities;
pointer, keyboard, focus, input, and navigation paths;
loading, empty, error, allowed, and denied data states;
animation trigger and resting states.
Test cases supply stored property values to a Preview session. Component states still begin from their declared defaults.
Open a Page or visual Component and launch Preview from its file header.
Select the intended Test Case, Variant, Theme, and Preview as identity where available.
Resize or choose the relevant responsive context.
Perform the real interaction sequence.
Observe loading, state transitions, navigation, focus, validation, and animation.
When an open dependency changes, review and apply the Preview Update flow deliberately.
Close/reopen or reset the session when the next scenario requires clean runtime state.
Mockups have no runtime Preview. Review them on the editor canvas or capture view: "editor" through MCP.
In the
Websiteproject, inspect<design-file reference>without editing it. Build a test matrix for<screens, variants, themes, test cases, interactions, data states>. For each bounded case, capture the relevant Preview screenshot and report DOM, computed style, geometry, interpreter state, and Context change as needed. Click/focus inputs before typing. Show mismatches and failures without fixing them. Finish with generated TSX/SCSS and diagnostics, clearly stating what still needs a real consumer build.
MCP runtime operations can capture screenshots, read DOM and computed style, measure nodes, perform interactions, inspect action/state history, step the interpreter, evaluate expressions, control Code Component breakpoints, and reset the Preview host.
Work from the observed failure back to the source:
Record the exact project, file, screen width, variant, theme, test case, identity, and actions.
Read the stored node style/logic/timeline and the current Preview state.
Compare authored values with computed values and the rendered DOM.
Inspect console/action history and the smallest relevant generated-code fragment.
Use locate-source when a generated identifier or snippet must be traced to design nodes.
Propose one cause and one bounded correction.
Rerun the same reproduction before exploring other hypotheses.
For Code Components, use the breakpoint debugger only after the Preview reproduction reaches the relevant source path.
Use export-code to inspect TSX structure/logic and SCSS styles separately when useful. Scan for unresolved dependencies, unintended seeded styles, wrong width behavior, missing bindings, and generated public-contract changes.
Run diagnostics, but remember that the checker is lossy: an empty result is not proof that the output compiles. Build and test the intended React, Next.js, or boilerplate consumer.
Preview reads and screenshots do not edit the Component definition, but interactions can call authored APIs, change browser Storage, navigate, focus, or run database actions. Use safe endpoints and fake data.
Interpreter stepping changes runtime Preview state, not project history. Return to Design, Animate, Logic, or a bounded MCP write to fix the definition, then use design-file undo if needed.
Host-assisted Preview requires the running desktop app and a healthy host connection.
Typing and key events go to the currently focused Preview element.
Screenshots cover one moment; animation and multi-step logic need sequences.
Computed values or measurements can be stale when the Preview has not refreshed.
Diagnostics do not replace a consumer build.
Preview authentication is not proof of the current generated authentication client/backend.