Verify agent work

Accept an agent change only after checking evidence that matches the result. A successful MCP response proves that the server handled a request; it does not by itself prove the stored structure, rendered appearance, interaction, generated code, or external destination.

Choose proof for the change

• Change: Project file or folder · Primary proof: get-project-details · Useful second check: File Explorer review

• Change: Element hierarchy · Primary proof: get-file-tree or a targeted node read · Useful second check: Element Explorer review

• Change: Text, metadata, or style · Primary proof: read the exact resolved value · Useful second check: Preview screenshot or computed style

• Change: Responsive design · Primary proof: read screen overrides · Useful second check: screenshots at each affected screen

• Change: Variant or state · Primary proof: read the definition and selected values · Useful second check: Preview the relevant combination

• Change: Logic or event behavior · Primary proof: read logic, then preview-interact · Useful second check: interpreter state, variables, or DOM state

• Change: Animation · Primary proof: read timeline and keyframes · Useful second check: Preview playback/scrub and visual result

• Change: Generated component output · Primary proof: export-code · Useful second check: diagnostics plus a real consumer build

• Change: Local/Git/package/publish operation · Primary proof: inspect that destination independently · Useful second check: build, diff, deployed route, or registry result

Use at least one structural check and one outcome check for meaningful changes. For example, a screenshot can look correct while the wrong element received the style; a node read can be correct while responsive rendering still fails.

Read back the stored result

Ask for the smallest read that proves the requested fields without hiding unexpected changes:

In the selected Website project, read <target reference> after the change. Report the current parent, children, base style, screen overrides, variants, logic, and timelines that could have been affected. Do not make another change.

For large builds, compare the new tree with the pre-change structure rather than accepting a summary from memory. Re-discover node IDs after replacement or deletion.

Verify visible output

Use Preview for rendered and behavioral evidence. Depending on the task, the agent can inspect screenshots, the preview DOM, computed styles, dimensions, current state, variables, console messages, or a recorded interaction.

Host-assisted Preview operations require the desktop application to be running and connected. Some interactions also have realistic browser prerequisites: for example, typing needs a focusable field to be clicked or focused first.

Computed style and measurement are observations of the current rendered state. If they conflict with a screenshot or Preview behavior, treat the result as unresolved, refresh or rerender the target, and inspect again.

Verify interactions

State the action and expected transition before running it:

Preview <component reference> at the base screen with its default variant. Click the existing Open control once. Show the relevant Preview state and DOM before and after, and confirm that isOpen becomes true and the panel becomes visible. Do not edit the component while testing it.

Test the negative or alternate branch when it matters. One successful path does not prove responsive variants, validation, repeated content, database conditions, or error handling.

Verify generated output

Generated-code inspection and diagnostics answer different questions:

• export-code shows the current generated output for supported design files.

• diagnostics can identify known structural or generated-output issues.

• a real build in the intended React/Next.js/boilerplate consumer proves dependency, TypeScript, framework, and integration compatibility.

An empty diagnostics result is not a guarantee that the consumer application builds. Treat diagnostics as one check, not a substitute for compiling or exercising the actual destination.

Mockups do not use the ordinary Component code-export route. Verify their visual role rather than expecting a generated runtime component.

Verify external effects at the destination

For local export, Git, package publication, website publication, or a runtime database action, inspect the affected destination directly. Project reads cannot prove that an external operation reached the intended folder, repository, registry, site, or service.

Before accepting the action, record:

• the exact destination;

• the files, rows, commit, package version, or route expected to change;

• the observed diff or remote result;

• a build or runtime check where applicable.

These effects are outside design-file undo.

After a warning or failure

Do not assume a failed write made no change. The server catches handler errors so the connection can continue, but the operation is not guaranteed to roll back. Unknown top-level fields can also produce a warning while recognized fields are applied.

Read the current target before retrying. Then perform only the missing correction with the connected schema and repeat the appropriate verification.

A verification prompt

Verify the last bounded change in the selected Website project without editing it. Read the exact target and report the stored values that changed. Then use Preview to prove the visible or interactive result, and inspect generated output if the change affects export. Show warnings, failures, and any mismatch instead of fixing them automatically. Do not export, publish, push, or mutate an external service.

Current limits

• Activity indicators show recent work, not correctness.

• A screenshot proves one captured state and viewport, not every screen, variant, or interaction path.

• Machine measurements can be stale or incomplete when Preview has not refreshed; resolve contradictions before approval.

• Diagnostics do not replace a real consumer build.

• Website/project publication needs separate route, link, responsive, and deployment verification.