component-canvas

Component canvas

Build a canvas that shows the project's existing components as they really behave. The canvas wraps components. It never changes them.

Ground rules

• Do not modify component source, exports, styles, hooks, or behavior to make the canvas work. Components must not import or depend on canvas code.
• Do not patch libraries, browser APIs, rendered component DOM, or portal roots.
• Show only the components the user asked for. Adding components, installing dependencies, changing a component's design, or making the canvas public requires permission first.
• Keep existing access controls.
• Leave unrelated work alone. If removing an earlier canvas integration, undo only its changes to components.
• Follow any restrictions on commands, browser access, dependencies, and edits.

Before building

Read the repository conventions, routes, component public APIs, design tokens, and test setup. Use the existing framework and libraries.

Ask the user only when the answer changes what gets built or touches shared code: which components are in scope, whether a new dependency is acceptable, or whether a live service may be previewed. For everything else, choose a sensible default, state it in the report, and proceed.

Build order

1. Add a minimal canvas route or entry point with one group and one component. Confirm it works.
2. Add the remaining groups with sample data.
3. Add variant comparisons, then advanced gestures and persistence, one feature at a time.

Keep canvas code in one place. Check imports and package exports when moving files. Follow the project's language, validation, and test conventions. Do not add architectural layers or directory names the project does not already use.

Keep layout and camera logic separate from sample data and component source.

Layout

• Fill the viewport with a plain background.
• If the project already supports light and dark themes, add an accessible toggle using its existing theme API. Apply the selected theme to the canvas and native portals. If theme support is absent, omit the toggle. Do not invent themes or change component styles.
• Give every group the same padding, radius, and thin dashed border, subtle but visible in both themes. Use an existing muted color at roughly 25% opacity for borders. Place its plain title 8px above the border, using the muted text color without opacity.
• Use wide groups with equal-width example slots filling each row. Wrap when needed and keep generous horizontal and vertical gaps within and between groups. Spread the layout without enlarging components.
• Groups cannot be dragged. Their positions need not be hard-coded. Measure their actual bounds, including title, border, and padding. Ignore rendering-containment placeholders (empty boxes that reserve space before content renders), since they do not reflect real content size.
• Omit background dots, decorative cards, page menus, instruction banners, selection tools, and block editing. Component cards and menus may appear as examples.