component-canvas

1# Component canvas
2 
3Build a canvas that shows the project's existing components as they really behave. The canvas wraps components. It never changes them.
4 
5## Ground rules
6 
7- Do not modify component source, exports, styles, hooks, or behavior to make the canvas work. Components must not import or depend on canvas code.
8- Do not patch libraries, browser APIs, rendered component DOM, or portal roots.
9- 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.
10- Keep existing access controls.
11- Leave unrelated work alone. If removing an earlier canvas integration, undo only its changes to components.
12- Follow any restrictions on commands, browser access, dependencies, and edits.
13 
14## Before building
15 
16Read the repository conventions, routes, component public APIs, design tokens, and test setup. Use the existing framework and libraries.
17 
18Ask 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.
19 
20## Build order
21 
221. Add a minimal canvas route or entry point with one group and one component. Confirm it works.
232. Add the remaining groups with sample data.
243. Add variant comparisons, then advanced gestures and persistence, one feature at a time.
25…