`, or `<Btn>` inside a canvas `<Screen>`. A new canvas artboard\nwith kit-tree children is a defect: replace it with\n`<Screen surface=\"...\" html={...} />` using the HTML wireframe rules. The HTML\npath is the one that gets the renderer-owned surface sizing, theme tokens,\nsketch/clean toggle, and safe text layout used by good document-body\nwireframes. Likewise, old or imported plans may carry coordinate-based regions\nor free-float x/y on notes; those are legacy escape hatches the renderer still\nshows but you must never produce. The gutter parks notes by `targetId` +\n`placement`, and the coordinate rule at the top of this file governs all\nnew-plan placement.\n\n"; export declare const CANVAS_REFERENCE_MD = "# Canvas & artboard placement \u2014 single source of truth\n\nThis file is the canonical guide for how the visual-plan canvas works: artboard\nplacement, lane layout, annotations, patching, and the legacy kit tree. Read it\nin full before authoring or editing any canvas/artboard content; do not author\ncanvas layouts from memory or paraphrase these rules per mode.\n\n\n\n**The coordinate rule.** The `surface` locks each artboard's footprint and\naspect \u2014 never set artboard width/height and never use coordinates inside the\nwireframe HTML; board-level artboard `x`/`y` IS allowed when it creates clear\nlanes. Let canvas auto-placement handle simple one-row boards.\n\n**Lay out mixed canvases in lanes.** When a canvas contains broad browser /\ndesktop frames plus compact `mobile`, `popover`, or `panel` surfaces, do not put\neverything in one horizontal strip. Use board-level artboard `x`/`y` to reserve\nlanes with generous empty space: main flow on one row, compact surfaces in their\nown column or row, and loading/error states in a lower row. Keep at least 96px\nbetween rendered artboard rectangles plus room for annotation gutters; when a\nbroad browser/desktop frame sits beside a compact panel/popover, leave at least\n160px so frame borders, labels, and hover controls never touch. Connect only\nneighboring steps; never draw a long connector that skips across unrelated\nframes. Connector labels must sit in open canvas space. If the label would touch\nor cross either artboard, remove the label and explain the transition with a\nnearby annotation instead. Before handoff, inspect the top canvas at default zoom\nand move any frame whose label, connector, or annotation crosses another frame.\n\n**Board-unit spacing defaults.** The canvas coordinate system uses approximately 2 board units per screen pixel. `browser` frames occupy roughly 700 \u00D7 600 board units; `desktop` frames roughly 900 \u00D7 700 board units. Apply these minimum x/y gaps when placing frames explicitly \u2014 any less and frames will touch or overlap:\n\n- x-gap between `browser` frames: **\u2265 1100** (700-unit frame + 400-unit gutter)\n- x-gap between `desktop` frames: **\u2265 1300** (900-unit frame + 400-unit gutter)\n- y-gap between rows of any surface: **\u2265 1400** (includes frame height + section header + buffer)\n\nWhen in doubt, use larger values \u2014 the canvas auto-zooms to fit everything.\n\n**Canvas annotations are designer notes on the artboard.** When a top canvas is\npresent, sprinkle design-review notes near the frames they explain: a short\nheading, supporting text, and bullets \u2014 plain text layers, never bordered or\nshadowed cards, and never a box around a frame. The renderer spaces notes away\nfrom frames, so place each note by the frame it describes. Use an arrow only to\npoint at one specific control or transition; for a broad frame-level note, write\ntext beside the frame with no connector. Connectors are for real sequences only \u2014\nnever fake \"Step 1 \u2192 Step 2\" lines between independent states.\n\n**Do not create overlapping annotations.** Anchor each ordinary note to the\nframe it explains with `targetId` + `placement` (top/right/bottom/left), and\nomit `type` or use `type: \"note\"`. The renderer parks notes in a gutter beside\nthe frame and lays them out automatically. Do not use `type: \"callout\"`,\n`type: \"text\"`, `type: \"arrow\"`, x/y, or points for ordinary notes; those are\nfreeform review-markup layers and must be reserved for intentional markup in\nopen canvas space. Reserve arrows for a note that must point at one specific\ncontrol inside a frame; a note that simply sits beside its frame needs no arrow.\n\n**Patching.** Edit one wireframe, canvas annotation, diagram, or block with targeted `contentPatches`\n(for example `patch-wireframe-html`, `patch-diagram-html`, `update-block`,\n`replace-blocks`, `update-canvas-annotation`) rather\nthan regenerating the whole plan. `contentPatches` are part of the public MCP\naction schema, so Claude Code, Codex, Cursor, and other hosts can make surgical\nedits. If an agent is working from exported source files, use\n`read-visual-plan-source` / `patch-visual-plan-source`: `plan.mdx` holds\nfrontmatter plus markdown/document blocks, `canvas.mdx` holds\n`<DesignBoard>/<Section>/<Artboard>/<Screen>/<Annotation>/<Connector>`, and the\npatch action normalizes the MDX back into the same JSON runtime model. JSON is\nthe canonical runtime shape; MDX is the repo-friendly authoring/export surface.\nIn the browser, humans edit `rich-text` prose inline; agents should still use\n`update-rich-text` content patches or source patches for prose, and use\ncomments/structured patches for canvas, artboard, wireframe, and diagram edits.\nNever send a partial top-level `content` object as a shortcut to add a canvas,\nframe, or block: `content` is a full structured replacement, so omitted blocks\nor surfaces can disappear. If a full replacement is truly unavoidable, read the\ncomplete source/JSON first, include every existing block and surface in the new\npayload, and verify the source/export immediately after the update.\n\n**Never emit a titled artboard with no interior wireframe content.** Every artboard\nyou place on the canvas must carry an `html` wireframe or reference a wireframe\nblock via `blockId`; when using `blockId`, the referenced `wireframe` /\n`legacy-wireframe` block must remain in the plan. If you remove a duplicate\nwireframe from the document body, first move its `data` inline onto the\ncorresponding `content.canvas.frames[*].wireframe` / `legacyWireframe`. A\nlabel-only frame or a frame pointing at a deleted block renders empty and is\nrejected at parse time. If you only have a title, write it as a section header or\nannotation, not an empty artboard.\n\n**UI mockups belong in the top visual review area.** Static UI/product visuals\nlive on the canvas; multi-step UI flows get both canvas wireframes and a\nprototype. When the user asks for a mockup, UI state, loading state, layout,\nscreen, or visual comparison, make the canvas the primary home for that static\nvisual. When the user asks for a prototype or the plan contains a sequence the\nreviewer must feel, keep the canvas artboards and add `content.prototype` so the\ntop surface shows Wireframes / Prototype tabs. Architecture/code diagrams stay\ninline in the document (the SKILL.md Visual Surface Choice section owns that\nrule) unless the user explicitly asks for a spatial board. Document blocks\ncan explain, compare, or map implementation, but they should not host the\nprimary UI mockup or prototype just because `custom-html`, screenshots, or prose\nare easier to produce. If the canvas/prototype surface cannot represent the\nrequested UI fidelity, still keep the closest top-surface representation and\ncall out or extend the needed renderer capability. A skeleton/loading mockup\nalso lives in a canvas artboard \u2014 never move a mockup out of the canvas.\n\n**Storyboards are canvas artifacts, not document diagrams.** When the requested\noutput is a product flow, onboarding journey, \"light storyboard\", or canvas\nwireframe, author the flow as multiple top-canvas artboards with real screen\ncontent and neighboring connectors. Keep document-body `diagram` blocks for\narchitecture and mechanics that are not themselves user-visible screens. A\nstoryboard made from a single inline HTML diagram is the wrong surface.\n\nFor abstract product concepts, use the canvas to create the first \"I get it\"\nmoment: one real app state near the top showing how the concept appears to a\nuser, followed by separate annotations or diagrams for mechanics. Do not make\nthe first artboard a hybrid of app UI and architecture notes; the app screen\nshould be inspectable as product UI on its own.\n\n**Legacy kit tree.** Older plans set a `screen` array of `{ el, ...props }` kit\nnodes instead of `html`; the renderer still accepts and displays it so saved\nplans round-trip, but new plans emit `html`. Do not author fresh kit-tree\nscreens, and do not put nested kit components such as `<FrameScreen>`, `<Card>`,\n`<Row>`, `<Title>`, or `<Btn>` inside a canvas `<Screen>`. A new canvas artboard\nwith kit-tree children is a defect: replace it with\n`<Screen surface=\"...\" html={...} />` using the HTML wireframe rules. The HTML\npath is the one that gets the renderer-owned surface sizing, theme tokens,\nsketch/clean toggle, and safe text layout used by good document-body\nwireframes. Likewise, old or imported plans may carry coordinate-based regions\nor free-float x/y on notes; those are legacy escape hatches the renderer still\nshows but you must never produce. The gutter parks notes by `targetId` +\n`placement`, and the coordinate rule at the top of this file governs all\nnew-plan placement.\n\n\n"; export declare const CANVAS_REFERENCE_POINTER = "The canvas is the single source of truth for static UI mockups: the `surface`\nlocks each artboard's footprint, mixed surfaces lay out\nin lanes, annotations are plain-text designer notes anchored by\n`targetId`/`placement`, and edits are surgical `contentPatches`. Before\nauthoring or editing ANY canvas, artboard, or annotation, READ\n`references/canvas.md` in this skill directory \u2014 it is the single source of truth\nfor canvas/artboard mechanics. Do not author canvas layouts from memory."; //# sourceMappingURL=canvas.d.ts.map

////`, and the\npatch action normalizes the MDX back into the same JSON runtime model. JSON is\nthe canonical runtime shape; MDX is the repo-friendly authoring/export surface.\nIn the browser, humans edit `rich-text` prose inline; agents should still use\n`update-rich-text` content patches or source patches for prose, and use\ncomments/structured patches for canvas, artboard, wireframe, and diagram edits.\nNever send a partial top-level `content` object as a shortcut to add a canvas,\nframe, or block: `content` is a full structured replacement, so omitted blocks\nor surfaces can disappear. If a full replacement is truly unavoidable, read the\ncomplete source/JSON first, include every existing block and surface in the new\npayload, and verify the source/export immediately after the update.\n\n**Never emit a titled artboard with no interior wireframe content.** Every artboard\nyou place on the canvas must carry an `html` wireframe or reference a wireframe\nblock via `blockId`; when using `blockId`, the referenced `wireframe` /\n`legacy-wireframe` block must remain in the plan. If you remove a duplicate\nwireframe from the document body, first move its `data` inline onto the\ncorresponding `content.canvas.frames[*].wireframe` / `legacyWireframe`. A\nlabel-only frame or a frame pointing at a deleted block renders empty and is\nrejected at parse time. If you only have a title, write it as a section header or\nannotation, not an empty artboard.\n\n**UI mockups belong in the top visual review area.** Static UI/product visuals\nlive on the canvas; multi-step UI flows get both canvas wireframes and a\nprototype. When the user asks for a mockup, UI state, loading state, layout,\nscreen, or visual comparison, make the canvas the primary home for that static\nvisual. When the user asks for a prototype or the plan contains a sequence the\nreviewer must feel, keep the canvas artboards and add `content.prototype` so the\ntop surface shows Wireframes / Prototype tabs. Architecture/code diagrams stay\ninline in the document (the SKILL.md Visual Surface Choice section owns that\nrule) unless the user explicitly asks for a spatial board. Document blocks\ncan explain, compare, or map implementation, but they should not host the\nprimary UI mockup or prototype just because `custom-html`, screenshots, or prose\nare easier to produce. If the canvas/prototype surface cannot represent the\nrequested UI fidelity, still keep the closest top-surface representation and\ncall out or extend the needed renderer capability. A skeleton/loading mockup\nalso lives in a canvas artboard \u2014 never move a mockup out of the canvas.\n\n**Storyboards are canvas artifacts, not document diagrams.** When the requested\noutput is a product flow, onboarding journey, \"light storyboard\", or canvas\nwireframe, author the flow as multiple top-canvas artboards with real screen\ncontent and neighboring connectors. Keep document-body `diagram` blocks for\narchitecture and mechanics that are not themselves user-visible screens. A\nstoryboard made from a single inline HTML diagram is the wrong surface.\n\nFor abstract product concepts, use the canvas to create the first \"I get it\"\nmoment: one real app state near the top showing how the concept appears to a\nuser, followed by separate annotations or diagrams for mechanics. Do not make\nthe first artboard a hybrid of app UI and architecture notes; the app screen\nshould be inspectable as product UI on its own.\n\n**Legacy kit tree.** Older plans set a `screen` array of `{ el, ...props }` kit\nnodes instead of `html`; the renderer still accepts and displays it so saved\nplans round-trip, but new plans emit `html`. Do not author fresh kit-tree\nscreens, and do not put nested kit components such as ``, ``,\n``, ``, or `<Btn>` inside a canvas `<Screen>`. A new canvas artboard\nwith kit-tree children is a defect: replace it with\n`<Screen surface=\"...\" html={...} />` using the HTML wireframe rules. The HTML\npath is the one that gets the renderer-owned surface sizing, theme tokens,\nsketch/clean toggle, and safe text layout used by good document-body\nwireframes. Likewise, old or imported plans may carry coordinate-based regions\nor free-float x/y on notes; those are legacy escape hatches the renderer still\nshows but you must never produce. The gutter parks notes by `targetId` +\n`placement`, and the coordinate rule at the top of this file governs all\nnew-plan placement.\n\n"; export declare const CANVAS_REFERENCE_MD = "# Canvas & artboard placement \u2014 single source of truth\n\nThis file is the canonical guide for how the visual-plan canvas works: artboard\nplacement, lane layout, annotations, patching, and the legacy kit tree. Read it\nin full before authoring or editing any canvas/artboard content; do not author\ncanvas layouts from memory or paraphrase these rules per mode.\n\n\n\n**The coordinate rule.** The `surface` locks each artboard's footprint and\naspect \u2014 never set artboard width/height and never use coordinates inside the\nwireframe HTML; board-level artboard `x`/`y` IS allowed when it creates clear\nlanes. Let canvas auto-placement handle simple one-row boards.\n\n**Lay out mixed canvases in lanes.** When a canvas contains broad browser /\ndesktop frames plus compact `mobile`, `popover`, or `panel` surfaces, do not put\neverything in one horizontal strip. Use board-level artboard `x`/`y` to reserve\nlanes with generous empty space: main flow on one row, compact surfaces in their\nown column or row, and loading/error states in a lower row. Keep at least 96px\nbetween rendered artboard rectangles plus room for annotation gutters; when a\nbroad browser/desktop frame sits beside a compact panel/popover, leave at least\n160px so frame borders, labels, and hover controls never touch. Connect only\nneighboring steps; never draw a long connector that skips across unrelated\nframes. Connector labels must sit in open canvas space. If the label would touch\nor cross either artboard, remove the label and explain the transition with a\nnearby annotation instead. Before handoff, inspect the top canvas at default zoom\nand move any frame whose label, connector, or annotation crosses another frame.\n\n**Board-unit spacing defaults.** The canvas coordinate system uses approximately 2 board units per screen pixel. `browser` frames occupy roughly 700 \u00D7 600 board units; `desktop` frames roughly 900 \u00D7 700 board units. Apply these minimum x/y gaps when placing frames explicitly \u2014 any less and frames will touch or overlap:\n\n- x-gap between `browser` frames: **\u2265 1100** (700-unit frame + 400-unit gutter)\n- x-gap between `desktop` frames: **\u2265 1300** (900-unit frame + 400-unit gutter)\n- y-gap between rows of any surface: **\u2265 1400** (includes frame height + section header + buffer)\n\nWhen in doubt, use larger values \u2014 the canvas auto-zooms to fit everything.\n\n**Canvas annotations are designer notes on the artboard.** When a top canvas is\npresent, sprinkle design-review notes near the frames they explain: a short\nheading, supporting text, and bullets \u2014 plain text layers, never bordered or\nshadowed cards, and never a box around a frame. The renderer spaces notes away\nfrom frames, so place each note by the frame it describes. Use an arrow only to\npoint at one specific control or transition; for a broad frame-level note, write\ntext beside the frame with no connector. Connectors are for real sequences only \u2014\nnever fake \"Step 1 \u2192 Step 2\" lines between independent states.\n\n**Do not create overlapping annotations.** Anchor each ordinary note to the\nframe it explains with `targetId` + `placement` (top/right/bottom/left), and\nomit `type` or use `type: \"note\"`. The renderer parks notes in a gutter beside\nthe frame and lays them out automatically. Do not use `type: \"callout\"`,\n`type: \"text\"`, `type: \"arrow\"`, x/y, or points for ordinary notes; those are\nfreeform review-markup layers and must be reserved for intentional markup in\nopen canvas space. Reserve arrows for a note that must point at one specific\ncontrol inside a frame; a note that simply sits beside its frame needs no arrow.\n\n**Patching.** Edit one wireframe, canvas annotation, diagram, or block with targeted `contentPatches`\n(for example `patch-wireframe-html`, `patch-diagram-html`, `update-block`,\n`replace-blocks`, `update-canvas-annotation`) rather\nthan regenerating the whole plan. `contentPatches` are part of the public MCP\naction schema, so Claude Code, Codex, Cursor, and other hosts can make surgical\nedits. If an agent is working from exported source files, use\n`read-visual-plan-source` / `patch-visual-plan-source`: `plan.mdx` holds\nfrontmatter plus markdown/document blocks, `canvas.mdx` holds\n`<DesignBoard>/<Section>/<Artboard>/<Screen>/<Annotation>/<Connector>`, and the\npatch action normalizes the MDX back into the same JSON runtime model. JSON is\nthe canonical runtime shape; MDX is the repo-friendly authoring/export surface.\nIn the browser, humans edit `rich-text` prose inline; agents should still use\n`update-rich-text` content patches or source patches for prose, and use\ncomments/structured patches for canvas, artboard, wireframe, and diagram edits.\nNever send a partial top-level `content` object as a shortcut to add a canvas,\nframe, or block: `content` is a full structured replacement, so omitted blocks\nor surfaces can disappear. If a full replacement is truly unavoidable, read the\ncomplete source/JSON first, include every existing block and surface in the new\npayload, and verify the source/export immediately after the update.\n\n**Never emit a titled artboard with no interior wireframe content.** Every artboard\nyou place on the canvas must carry an `html` wireframe or reference a wireframe\nblock via `blockId`; when using `blockId`, the referenced `wireframe` /\n`legacy-wireframe` block must remain in the plan. If you remove a duplicate\nwireframe from the document body, first move its `data` inline onto the\ncorresponding `content.canvas.frames[*].wireframe` / `legacyWireframe`. A\nlabel-only frame or a frame pointing at a deleted block renders empty and is\nrejected at parse time. If you only have a title, write it as a section header or\nannotation, not an empty artboard.\n\n**UI mockups belong in the top visual review area.** Static UI/product visuals\nlive on the canvas; multi-step UI flows get both canvas wireframes and a\nprototype. When the user asks for a mockup, UI state, loading state, layout,\nscreen, or visual comparison, make the canvas the primary home for that static\nvisual. When the user asks for a prototype or the plan contains a sequence the\nreviewer must feel, keep the canvas artboards and add `content.prototype` so the\ntop surface shows Wireframes / Prototype tabs. Architecture/code diagrams stay\ninline in the document (the SKILL.md Visual Surface Choice section owns that\nrule) unless the user explicitly asks for a spatial board. Document blocks\ncan explain, compare, or map implementation, but they should not host the\nprimary UI mockup or prototype just because `custom-html`, screenshots, or prose\nare easier to produce. If the canvas/prototype surface cannot represent the\nrequested UI fidelity, still keep the closest top-surface representation and\ncall out or extend the needed renderer capability. A skeleton/loading mockup\nalso lives in a canvas artboard \u2014 never move a mockup out of the canvas.\n\n**Storyboards are canvas artifacts, not document diagrams.** When the requested\noutput is a product flow, onboarding journey, \"light storyboard\", or canvas\nwireframe, author the flow as multiple top-canvas artboards with real screen\ncontent and neighboring connectors. Keep document-body `diagram` blocks for\narchitecture and mechanics that are not themselves user-visible screens. A\nstoryboard made from a single inline HTML diagram is the wrong surface.\n\nFor abstract product concepts, use the canvas to create the first \"I get it\"\nmoment: one real app state near the top showing how the concept appears to a\nuser, followed by separate annotations or diagrams for mechanics. Do not make\nthe first artboard a hybrid of app UI and architecture notes; the app screen\nshould be inspectable as product UI on its own.\n\n**Legacy kit tree.** Older plans set a `screen` array of `{ el, ...props }` kit\nnodes instead of `html`; the renderer still accepts and displays it so saved\nplans round-trip, but new plans emit `html`. Do not author fresh kit-tree\nscreens, and do not put nested kit components such as `<FrameScreen>`, `<Card>`,\n`<Row>`, `<Title>`, or `<Btn>` inside a canvas `<Screen>`. A new canvas artboard\nwith kit-tree children is a defect: replace it with\n`<Screen surface=\"...\" html={...} />` using the HTML wireframe rules. The HTML\npath is the one that gets the renderer-owned surface sizing, theme tokens,\nsketch/clean toggle, and safe text layout used by good document-body\nwireframes. Likewise, old or imported plans may carry coordinate-based regions\nor free-float x/y on notes; those are legacy escape hatches the renderer still\nshows but you must never produce. The gutter parks notes by `targetId` +\n`placement`, and the coordinate rule at the top of this file governs all\nnew-plan placement.\n\n\n"; export declare const CANVAS_REFERENCE_POINTER = "The canvas is the single source of truth for static UI mockups: the `surface`\nlocks each artboard's footprint, mixed surfaces lay out\nin lanes, annotations are plain-text designer notes anchored by\n`targetId`/`placement`, and edits are surgical `contentPatches`. Before\nauthoring or editing ANY canvas, artboard, or annotation, READ\n`references/canvas.md` in this skill directory \u2014 it is the single source of truth\nfor canvas/artboard mechanics. Do not author canvas layouts from memory."; //# sourceMappingURL=canvas.d.ts.map