Use a visual Component as the entry point, then follow how its element tree connects to typed data structures, events, state, APIs, storage, content, and runtime inspection.
You do not need to begin by exporting code. First prove that the component structure and behavior are correct inside the project; then choose an output boundary deliberately.
Tour the project interface, focusing on the file-sensitive center workspace and the Logic inspector.
Create your first component so later data and behavior have a concrete target.
Preview your work and distinguish the static editor canvas from the running interpreter preview.
Use the UI, an agent, or both before delegating a multi-step mutation.
A visual Component can declare properties, states, events, validators, variants, variant combinations, and test cases. Those structures make the Component reusable and give logic, preview, and generated output an explicit contract.
Selected elements can participate in conditions, repetition, bindings, component prop/event mapping, listeners, API requests, state changes, mounted data sources, mounted views, and validators where their node and file context allow it.
APIs, storage, CMS/content, database tables, scripts, documents, design-system files, and environment settings have specialized editors and MCP operations. Treat each as a separate contract instead of assuming every file behaves like a Component.
Preview is not only a screenshot. MCP can read runtime DOM, computed styles, measurements, node metadata, interpreter state and actions, and can drive supported preview interactions. This is useful for verifying that behavior happened rather than only that a mutation was accepted.
Coverage: UI + MCP, with MCP-only structured runtime inspection.
Select my project and inspect the target Component without changing it. Return its properties, states, events, variants, test cases, mounted data, element logic, and timelines. Identify unresolved references or diagnostics, then stop.
After reviewing the read, make one bounded request:
Add one Boolean state named
isOpento the target Component and connect only the named trigger element to toggle it on click. Read the resulting state and event action back, run the preview interaction, and report the before/after interpreter state. Do not change styles or other logic.
The second prompt is intentionally specific about ownership and proof. The agent should resolve actual file and node references before writing and should report any schema or availability mismatch instead of improvising another behavior.
Selecting tabs, opening panels, expanding rows, and changing zoom are editor-session concerns.
Component elements, styles, declared data, logic, and timelines are file content.
API, storage, database, account, publishing, Git, and package operations may have project-level or external side effects.
Runtime preview interaction can change interpreter state and can trigger authored effects even when it does not edit the Component definition.
Each detailed guide must state its undo, persistence, synchronization, and external side effects separately.