@agent-native/core 0.115.1 → 0.115.4

package/dist/cli/skills-content/visual-plan-skill.d.ts

@@ -1,2 +1,2 @@
-export declare const VISUAL_PLANS_SKILL_MD = "---\nname: visual-plan\ndescription: >-\n  Turn ordinary text plans into rich interactive visual plans with diagrams,\n  file maps, annotated code, open questions, and UI/prototype review when\n  useful.\nmetadata:\n  visibility: exported\n---\n\n# Agent-Native Plans\n\nAgent-Native Plans is structured visual planning mode for coding agents. Build\nthe plan you would normally write in Markdown, but as a scannable document with\neditable blocks mixed in: inline diagrams, code snippets,\nopen questions, and an optional top visual review area (wireframe canvas, live\nprototype, or both in tabs). Architecture and backend plans stay document-only;\nUI and product plans start with the top canvas/prototype (the Visual Surface\nChoice section owns that rule).\n\n`/visual-plan` is the packaged command and main entry point. Choose the review\nmode from the task: UI-first when the work is primarily product UI and review\nshould start with screens, prototype-first when review should start with a\nfunctional live prototype, design-first when review needs full-fidelity branded\nscreens, or visual-intake when the user explicitly wants a questionnaire before\nplanning. When a Codex, Claude Code, Markdown, or pasted plan already exists,\n`/visual-plan` uses that source plan as the starting point and builds the review\nsurface from it instead of starting over.\n\n## When To Use\n\nCreate or adapt a visual plan whenever the plan would be better as a reviewable\nartifact than a chat paragraph. This includes modest work such as a single UI\nsurface with states, a small workflow, a before/after product change, or a\ncomponent/API/data-shape decision that needs alignment, plus larger multi-file,\nambiguous, long-running, risky, or UI-heavy work. Use it when architecture /\ndata flow / UI direction / options / open questions would benefit from inline\ndiagrams or structured blocks, when the user needs to react to a direction\nbefore you implement, or when an existing text plan needs a richer review\nsurface.\n\n## Plan Discipline\n\n- **Gate thoughtfully.** A visual plan is a richer review surface, not only a\n  tool for giant projects. Use it when the user needs to see, compare, comment\n  on, or approve a direction before code, even for a modest UI/state/workflow\n  change. Skip it for truly trivial, unambiguous work \u2014 typos, one-line fixes, a\n  single well-specified function, anything whose diff you could describe in one\n  sentence \u2014 and just make the change. Never pad a plan with filler and never\n  ship a single-step plan.\n- **Research before you draft.** Read the real files, actions, schema, and\n  patterns first; name actual files, symbols, and data shapes instead of\n  inventing them. Check existing `actions/` before proposing endpoints and prefer\n  named client helpers over raw fetch. Delegate wide exploration to a sub-agent.\n  Lead with reuse: for each step, name what it reuses \u2014 existing actions, schema,\n  components, helpers \u2014 before what it adds, so the plan explains the genuinely new\n  delta instead of redescribing what already exists.\n- **Decide the hard-to-reverse bets first.** For non-trivial backend, data, or API\n  work, sketch where the feature is headed, then call out the decisions that are\n  expensive to undo once data or callers depend on them \u2014 wire format, public ids,\n  data-model shape, auth and ownership boundaries \u2014 and get those right in the plan\n  even if most of the feature ships later. Then scope to the smallest first cut that\n  proves the approach without foreclosing it, stating both what is in and what is\n  explicitly deferred.\n- **Keep examples at the right altitude.** When the user's idea is a broad\n  framework, product, or operating-model change, do not collapse it into the\n  first concrete example, provider, or sync path they mention. Separate the core\n  abstraction from motivating examples and app/provider adapters. Use examples\n  to make the plan legible, but label them as examples unless they are the whole\n  requested scope.\n- **Publish standalone plans.** If the user pasted, referenced, or already has a\n  Codex / Claude Code / Markdown plan, treat it as source material, but rewrite\n  the published plan as a clean standalone proposal. Preserve the source plan's\n  useful intent and codebase facts, label inferred visuals as inferred, and avoid\n  revision language such as \"preserve the prior plan\", \"do not drop the old\n  idea\", \"unlike the previous version\", or \"this revision changes...\". A reader\n  who never saw the chat or earlier drafts should understand the plan.\n- **Make the first read concrete.** If the plan is meant to be shared with\n  someone outside the chat, or if the concept is abstract, lead near the top with\n  one concrete product example before mode tables, architecture, or roadmaps. For\n  UI-capable concepts, that usually means a top-canvas app state that shows the\n  real user workflow in product terms. Do not rely on phrases that only make\n  sense in conversation, and do not frame the plan as \"not the old idea\"; state\n  the positive model directly.\n- **Planning is read-only.** Make no source edits while building or reviewing the\n  plan. Start editing only after the user approves the direction.\n- **Clarify vs. assume.** Do not ask how to build it \u2014 explore and present the\n  approach and options in the plan. Ask a clarifying question only when an\n  ambiguity would change the design and you cannot resolve it from the code; use\n  the host agent's normal ask-user-question flow and batch 2-4 high-leverage\n  questions before finalizing. Do not call `create-visual-questions` for\n  ordinary clarification or preflight; reserve it for the visual-intake mode when\n  the user explicitly asks for a visual intake questionnaire. Otherwise state the\n  assumption explicitly and proceed, and keep anything unresolved in the plan's\n  single bottom `question-form` Open Questions block. For complex plans, do a\n  final open-question pass before handoff: if a decision would affect\n  architecture, scope, UX, data shape, or rollout, either decide it in the plan\n  with rationale or put it in that bottom form with a recommended default.\n- **The plan is the approval gate.** After surfacing it, ask the user to review\n  and approve before you write code, and name which files/areas the work touches.\n  Presenting the plan and requesting sign-off is the approval step \u2014 do not ask a\n  separate \"does this look good?\" question.\n- **The document is the source of truth, not the chat.** When scope shifts,\n  update the plan with `update-visual-plan` rather than only changing course in\n  chat, and make the updated document stand alone. Do not describe the update as\n  a correction to an earlier draft inside the plan itself. Re-read the approved\n  plan before major steps.\n\n## Create A Structured Agent-Native Plan \u2014 Never Inline\n\nThe deliverable is ALWAYS a structured Agent-Native Plan, not a chat-only plan.\nThe hosted Plan MCP connector (`plan` server, or legacy `agent-native-plans`) is\nthe default collaboration and commenting surface; it is not a reason to reject\nthe planning pattern as an external dependency or rented layer. Plans are\nportable source artifacts (`plan.mdx`, optional `canvas.mdx` /\n`prototype.mdx`, JSON, and HTML export), and ownership-sensitive workflows can\nuse local-files mode or a self-hosted/custom Plan app URL without abandoning the\nskill's review discipline. Do not advise the user to skip `/visual-plan` because\nthe default surface is hosted; choose the right Plan mode for the user's\nownership, privacy, sharing, and branding needs.\n\nBy default, create the plan via the Plan MCP connector and NEVER hand it over as\ninline chat content \u2014 no Markdown prose, ASCII sketch, table, or fenced\nwireframe. If the `plan` (or legacy `agent-native-plans`) tools are not visible,\ndiscover them through the host's `tool_search` first; if they are still missing,\nSTOP and give the user the client-specific reconnect step rather than improvising\nan inline plan. Before publishing, or whenever a connector or auth error appears,\nREAD `references/connection.md` in this skill directory \u2014 it is the single source\nof truth for the never-inline rule, connector discovery, and the per-client\nreconnect steps. Local-files privacy mode (after Tool Guidance) is the exception.\n\n## Core Workflow\n\nThis section describes the default hosted Plan MCP workflow. If\n`AGENT_NATIVE_PLANS_MODE=local-files` is set, or the user asks for fully local\nfiles/no hosted Plan writes, use **Local-Files Privacy Mode** instead; carry\nforward only the code-research and plan-composition guidance here.\n\n1. Follow the host agent's normal planning flow: inspect the codebase, delegate\n   wide exploration when useful, gather the info needed, and ask native\n   clarifying questions as needed before generating the plan. If a source plan\n   already exists, gather its exact text from the user's paste, a referenced\n   file, or recent visible agent context; do not invent source text.\n2. Call `get-plan-blocks` for the authoritative block catalog \u2014 do not author\n   from memorized tags. Then call the mode-matched create tool:\n   `create-visual-plan` for document-first plans (architecture, backend, data,\n   refactor, API), `create-ui-plan` for UI-first plans, `create-prototype-plan`\n   for prototype-first plans, `create-plan-design` for design-first plans,\n   `create-visual-questions` only when the user explicitly asks for a visual\n   intake questionnaire. When a source plan already exists,\n   pass it as `planText` and preserve the original plan's useful intent while\n   producing a standalone plan document, not a revision memo.\n3. For UI/product plans, compose the top canvas first with the primary\n   wireframes and annotated states, then write the document with native blocks\n   (see `references/canvas.md` and `references/document-quality.md`). For\n   broad product architecture plans with a user-facing implication, add a\n   concrete \"what this looks like in the app\" visual before the abstract\n   architecture or mode tables. Keep the document close to the standalone\n   Markdown plan the agent would normally output. If an existing plan was\n   provided, carry forward the right facts and decisions without referring to\n   the previous draft or explaining how this version differs. For non-visual\n   plans, skip the top visual surface (Visual Surface Choice below owns the rule)\n   and put `diagram`, `data-model`,\n   `api-endpoint`, `diff`, `file-tree`, `code`, and `annotated-code` blocks\n   directly next to the relevant prose.\n   Wide document layout is renderer-owned and intentionally allowlisted: only\n   literal code-review surfaces (`diff`, `annotated-code`) and `tabs` blocks\n   with vertical orientation or diff-like children break out wider than prose.\n   Keep `api-endpoint`, `openapi-spec`, `data-model`, `json-explorer`,\n   `wireframe`, question, and `custom-html` blocks in normal document flow unless\n   their own renderer says otherwise.\n4. Surface the returned Plans link or inline MCP App and ask the user to review.\n   Always include the actual URL in chat so the next step is a click in CLI or\n   other text-only hosts. When the host exposes an embedded browser/preview panel\n   and a tool can open arbitrary URLs there, open the returned plan URL\n   automatically for convenient review \u2014 a convenience and smoke test, never the\n   only handoff or the access\n   model. Plans should load out of the box for the local agent and local browser\n   session; if a signed-in embedded browser cannot read a local plan that an\n   anonymous/tool check can read, fix the app/action ownership or access path\n   rather than patching one plan by hand. For high-stakes plans (architecture,\n   backend, data, multi-file, or risky), also kick off the self-review pass in\n   **Self-Review Before Handoff** while the user reads, instead of blocking the\n   handoff on it.\n5. For hosted plans, call `get-plan-feedback` before editing, after review,\n   after any long pause,\n   and before the final response. Treat `anchorDetails`, resolver intent, recent\n   review events, and any focused screenshots from browser handoff as the source\n   of truth for exactly what changed and exactly what each comment points at.\n6. For hosted plans, apply changes with `update-visual-plan`, preferring\n   targeted `contentPatches`.\n   Treat the top-level `content` payload as a full replacement, not a merge; do\n   not send a partial `content` object to add a canvas or one block. If a full\n   replacement or `replace-blocks` is unavoidable, call `get-visual-plan`\n   immediately before the write, pass its `plan.updatedAt` as\n   `expectedUpdatedAt`, and carry forward every existing block and visual\n   surface. Never reuse a revision from an earlier read or feedback payload.\n   For source-control friendly edits, use granular `patch-visual-plan-source`\n   operations against the MDX files instead of regenerating the plan;\n   `replace-file` is also destructive and requires the same fresh\n   `expectedUpdatedAt` fence.\n7. After every hosted-plan write, call `get-visual-plan` again and compare the\n   persisted text, block IDs/counts, canvas frames, and prototype with the\n   intended result. A successful mutation response is not proof that unrelated\n   content survived. If the edit addressed agent-targeted feedback, only after\n   this verification call `resolve-plan-comment` for the thread and\n   `consume-plan-feedback` for its comments; do both so addressed feedback is\n   neither visibly open nor returned as pending work.\n8. For hosted plans, export with `export-visual-plan` only when the user wants a\n   shareable receipt or repo-check-in artifacts.\n\n## Self-Review Before Handoff\n\nThis adversarial self-review pass is opt-in, not default: run it only for\nhigh-stakes plans \u2014 irreversible migrations, security-sensitive work, or when\nthe user explicitly asks for extra rigor \u2014 and skip it otherwise. It roughly\ndoubles the cost of plan generation, so the default for small, UI-only,\nsingle-decision, or ordinary plans is to skip it, not to run it. Keep the pass\ncheap and non-blocking when it does run:\n\n- **Surface the plan first, review concurrently.** Post the link and let the user\n  start reading, then run the review in parallel \u2014 never make the user wait on it.\n- **Review the written plan; do not re-research.** Critique the plan text and its\n  own blocks. The grounding was already done while drafting, so the review checks\n  the output instead of re-exploring the repo.\n- **Spawn one skeptical reviewer** whose only job is to find what is weak, missing,\n  or wrong \u2014 not to praise. Point it at: hard-to-reverse decisions made implicitly\n  or not at all (wire format, public ids, data-model shape, auth, ownership); steps\n  not anchored in real files or symbols; a menu of options where the plan should\n  commit to one; obvious missing decisions (\"what happens when X?\", \"why not Y?\");\n  and padding or single-step filler.\n- **Fix vs. ask.** Apply clear-cut fixes yourself with `update-visual-plan`\n  `contentPatches` \u2014 vague non-goals, unanchored claims, an obvious missing\n  decision. Route genuine judgment calls back to the user instead: add them to the\n  bottom `question-form` Open Questions block or batch them into the normal\n  ask-user-question flow. Do not silently decide them.\n- **Do not surprise the user mid-read.** On a large plan, apply the patches before\n  the editor loads; otherwise note briefly that a self-review is running so the\n  plan changing under them is expected. When you next respond, summarize what the\n  review changed and what it surfaced for the user to decide.\n\n## Visual Surface Choice\n\nChoose the surface before creating the plan or after reading the source plan. Do\nnot add visual chrome by default:\n\nFor UI/product plans, the top canvas is usually the primary review surface. Put\nthe first meaningful wireframes there, not buried as document-body blocks. Use\nmultiple canvas artboards when states matter, such as the default view, an\noverflow menu or popover, a side panel, loading, or error. Put short annotations\nbeside frames with `targetId` plus `placement`; keep implementation details,\ntradeoffs, file maps, data contracts, risks, and verification in the document\nbody below the canvas.\n\nWhen the user asks for a flow, storyboard, journey, wireframe, canvas, or \"what\nthis looks like\", treat that as a canvas-first request. Make one artboard per\nuser-visible state, connect only adjacent transitions, and use short canvas\nannotations for the product notes. Do not substitute a document-body `diagram`\nblock for the requested storyboard just because HTML diagrams are faster to\nwrite; diagrams belong below the canvas for backend mechanics, architecture, or\ndata-flow explanation.\n\nKeep product wireframes and explanatory/meta diagrams separate. Start with pure\nscreens that look like the app state under discussion, without callout prose or\narchitecture notes embedded inside the UI. Put arrows, labels, contracts, data\nflow, and mode explanations in separate annotations, separate canvas diagrams,\nor the document body.\n\nWhen the plan touches an existing app, inspect the current shell/components\nbefore drawing. The first artboard should look like the real app at the same\ndensity: existing sidebars, toolbar placement, overflow menus, app chrome, and\nframework agent chrome stay in their real places. Model secondary surfaces as\nseparate states, such as a top-right overflow popover, sheet, panel, loading\nstate, or separate AgentSidebar, rather than inventing a permanent inspector or\nfolding framework chrome into the product UI.\n\n- **No visual surface** for architecture-only, backend-only, data migration,\n  copy-only, or otherwise non-visual plans. Do not use the top canvas for\n  architecture diagrams, dependency maps, file plans, API contracts, or\n  data-flow-only reviews. Use a strong document with local inline diagrams\n  only when relationships need a visual explanation, usually one spatial diagram\n  per recommendation or decision. Prefer grouped regions, layers, quadrants,\n  matrices, or before/after panels over a single-axis chain unless the\n  relationship is truly sequential.\n- **Canvas only** for one static screen, a before/after comparison, a component\n  state, a small popover, or a visual direction that does not require clicking.\n  Put those wireframes in `content.canvas` and omit `content.prototype`.\n- **Canvas + prototype** for multi-step UI flows, onboarding, wizards,\n  review/approval flows, navigation changes, or anything where the reviewer\n  needs to operate the behavior. Keep the static wireframes in\n  `content.canvas`, add the aligned functional prototype in\n  `content.prototype`, and rely on the top visual tabs to switch between them.\n  When both surfaces are present, open the Wireframes tab by default; the\n  prototype remains available as the interactive follow-up view.\n- **Prototype-first** when the user asks to operate the UI or when interaction is\n  the main question. Use `create-prototype-plan`, which still preserves static\n  mocks where useful.\n\nFor mixed canvas + prototype plans, reuse the same real labels, app statuses,\nand screen ids across both surfaces. The canvas is the inspectable static reference;\nthe prototype is the interactive version of that same flow, not a separate\ndesign direction.\n\n## Wireframe quality \u2014 read `references/wireframe.md`\n\nUI recap/plan wireframes must meet a strict quality bar \u2014 full-width chrome,\npinned bottom bars, real product content, before/after comparability, the right\n`surface` preset, `--wf-*` tokens instead of hex, and no `<html>`/`<style>`/font\ntags. Before authoring ANY wireframe / `<Screen>` / `WireframeBlock`, READ\n`references/wireframe.md` in this skill directory \u2014 it is the single source of\ntruth for HTML wireframe quality, shared word for word with `/visual-plan`\nand `/visual-recap`. Do not author wireframes from memory.\n\n## Canvas \u2014 read `references/canvas.md`\n\nThe 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.\nCanvas artboards use the same HTML wireframe path as document-body\n`WireframeBlock` screens: author `<Screen surface=\"...\" html={...} />` with a\nsemantic HTML fragment. Do not author fresh kit-tree children such as\n`<FrameScreen>`, `<Card>`, `<Row>`, or `<Btn>` inside canvas `<Screen>` tags;\nthose are legacy compatibility markup for old plans and produce brittle canvas\nlayouts.\n\n## Document quality \u2014 read `references/document-quality.md`\n\nThe document is a serious technical plan, not marketing: outcome-first,\nprose-first, self-contained, built from the right native blocks, with open\nquestions in a single bottom `question-form` and a pre-handoff visual check.\nBefore authoring the plan document, READ `references/document-quality.md` in this\nskill directory \u2014 it is the single source of truth for the document quality bar.\nDo not write the document from memory.\n\n## Good vs. bad exemplar \u2014 read `references/exemplar.md`\n\nFor a worked example of the bar \u2014 a great UI-first plan and `/visual-plan`, plus\nthe anti-patterns to avoid \u2014 READ `references/exemplar.md` in this skill\ndirectory before authoring a plan.\n\n## Tool Guidance\n\n- `create-visual-plan`: start one structured visual plan per agent task/run, or\n  import an existing text plan by passing `planText`; `content` may include no\n  visual surface, canvas only, or canvas + prototype.\n- `create-ui-plan`: start a UI-first plan when the work is primarily product UI.\n- `create-prototype-plan`: start a prototype-first plan with a functional top\n  review surface.\n- `create-plan-design`: start a full-fidelity branded Design-tab plan with an\n  optional matching Prototype tab.\n- `convert-visual-plan-to-prototype`: convert an existing HTML wireframe canvas\n  into a prototype plan.\n- `create-visual-questions`: use only when the user explicitly asks for a visual\n  intake questionnaire, not as `/visual-plan` preflight.\n- `update-visual-plan`: revise content, status, or comments with targeted\n  `contentPatches` (see Core Workflow steps 6-7). `replace-blocks` and full\n  `content` replacement require `expectedUpdatedAt` from a fresh\n  `get-visual-plan` call.\n- `read-visual-plan-source`: read the normalized plan as `plan.mdx`,\n  optional `canvas.mdx`, optional `.plan-state.json`, and JSON.\n- `patch-visual-plan-source`: apply granular MDX AST patches by stable block,\n  artboard, annotation, component, or wireframe-node id. Prefer those targeted\n  operations; `replace-file` requires `expectedUpdatedAt` from a fresh\n  `get-visual-plan` call.\n- `import-visual-plan-source`: create or replace a plan from an MDX folder.\n- `get-visual-plan`: read the current structured plan, exported HTML,\n  annotations, and `plan.updatedAt`; it also returns the MDX folder for source\n  workflows. Re-read immediately before a destructive write for its concurrency\n  fence and again after every write to verify persisted state.\n- `get-plan-feedback`: read unconsumed human feedback. Use it frequently; it\n  returns grouped threads, exact anchor details, expected resolver, and recent\n  review-event payloads so agents can act only on the comments meant for them.\n- `get-plan-blocks`: resolve block tags before authoring \u2014 do not memorize tags;\n  call this first to get the authoritative tag names, required fields, and prop\n  shapes from the live block registry.\n- `export-visual-plan`: export HTML, Markdown fallback, structured JSON, and MDX\n  files for repo check-in.\n\nWhen the user critiques a plan's look or structure, fix the renderer or this\nskill \u2014 never hand-edit one stored plan. Turn feedback into better guidance.\n\n## Local-Files Privacy Mode \u2014 read `references/local-files.md`\n\nWhen the user wants no hosted Plan database writes \u2014 no DB writes, no Plan MCP\npublish, fully local/offline/private planning, repo-owned source-controlled\nartifacts, or `AGENT_NATIVE_PLANS_MODE=local-files` \u2014 do not call any hosted Plan\ntool except the schema-only `get-plan-blocks` catalog lookup. Author a local MDX\nfolder and\npreview it with `plan local check` / `plan local serve` / `plan local verify`.\nBefore using local-files mode, READ `references/local-files.md` in this skill\ndirectory \u2014 it is the single source of truth for the full contract (catalog\nlookup, MDX folder layout, the local bridge commands, and the hosted tools you\nmust not call). Carry forward only the code-research and plan-composition\nguidance from Core Workflow; everything hosted is replaced by the local bridge.\n\n## Interpreting comment anchors\n\nThis section applies to hosted plans with `get-plan-feedback` /\n`update-visual-plan`. In local-files mode, do not call hosted feedback or update\ntools; interpret file/chat feedback directly, edit the MDX files, rerun the\nlocal bridge check/serve/verify command, and report the new local URL.\n\n`get-plan-feedback` returns rich anchors \u2014 read them before acting on any comment.\n\n- **Coordinate frames.** `targetX`/`targetY` are percentages *within* the\n  element named by `targetSelector`/`targetKind`. Bare `x`/`y` are percentages\n  of the whole plan document. `canvasX`/`canvasY` are raw board-world pixels on\n  the design canvas (board size given when available).\n- **Wireframe pins.** Anchors on wireframes include `targetNodeId` and\n  `targetNodePath` (e.g. `card > list > listItem \"Acme Inc\"`) identifying the\n  exact kit node. Use `targetNodeId` directly with wireframe node patch ops;\n  use `data-design-id` values from design artboards with\n  `update-design-element-style`. Prefer the node id/path over raw coordinates;\n  fall back to coordinates plus the focused screenshot (red ring marks the exact\n  point) only when no node id is present.\n- **Text quotes.** Resolve `textQuote` against current prose using\n  `contextBefore`/`contextAfter` for disambiguation. If `ambiguous: true`, ask\n  the user \u2014 do not guess which occurrence is meant.\n- **Detached comments.** `get-plan-feedback` flags threads whose quoted text no\n  longer exists as `detached` (in `detachedThreads`). Reconcile these against\n  rewritten content \u2014 never silently drop them.\n- **Routing.** `resolutionTarget` is the only routing signal: act on `agent`,\n  treat `human` as context only. `@mentions` are people to notify, never a\n  routing signal.\n- **Two-axis state.** Mark every ingested comment as consumed\n  (`consumedCommentIds` on `update-visual-plan`). Set `status=resolved` only on\n  agent-targeted comments you actually addressed; leave human-targeted comments\n  open. When an edit addresses feedback, first re-read the persisted plan and\n  verify the requested change. Only then call `resolve-plan-comment` for the\n  addressed thread and `consume-plan-feedback` for its comments; never mark\n  addressed feedback along only one axis.\n\n## Visibility & Sharing\n\nUse `set-resource-visibility` to change who can see a plan (e.g. public, login,\nor org-scoped). Use `share-resource` to grant specific users or roles access\nby email or role. Gate visibility before sharing any plan that covers\nunreleased or private work \u2014 default to the narrowest scope that meets the\nreview need.\n\n## Setup & Authentication\n\nThere are two ways into Plans.\n\n**Coding agent (CLI).** Install once with the Agent-Native CLI. The command\ninstalls the Plans skills, registers the hosted Plans MCP connector, and runs\nauth/setup for the selected local client(s) in the same step (a one-time browser\nsign-in at setup \u2014 this is intended), so the first tool call in that client does\nnot hit an OAuth wall:\n\n```bash\nnpx @agent-native/core@latest skills add visual-plans\n```\n\nAfter that, `/visual-plan`, `/visual-recap`, and `/visualize-repo` are the\ninstalled slash commands. If you only need one command, use\n`skills add visual-plan`, `skills add visual-recap`, or\n`skills add visualize-repo` instead. The other planning modes\n(`create-ui-plan`, `create-prototype-plan`, `create-plan-design`,\n`create-visual-questions`) are MCP tools reachable from `/visual-plan`, not\nseparate slash commands. Pass `--no-connect` to register the connector without\nauthenticating, then run\n`npx @agent-native/core@latest connect https://plan.agent-native.com --client all`\nwhenever you are ready, or choose a narrower `--client`. Auth and MCP tool\nloading are per client config/session.\n\n**Browser (people you share with).** Open the Plans editor and create & edit\nwith no sign-up \u2014 you work as a guest. Sign in only when you want to save or\nshare; signing in claims the plans you made as a guest into your account.\n\nSharing and commenting require an account: public/shared plans are viewable by\nanyone with the link, but commenting on them needs an agent-native account.\n\nFor fully offline, no-account use, run the Plans app locally and sync plans to\nyour repo as MDX. This local mode is a separate advanced path, not the default\nhosted flow.\n\nFor repo-wide visual docs, run\n`npx @agent-native/core@latest visualize-repo --open` to create/update\n`agent-native.json`, seed `.agent-native/visual-docs/repo-overview`, and open\nthe local bridge.\n\nIf a Plans tool returns `needs auth`, `Unauthorized`, or `Session terminated`, do\nnot keep retrying it \u2014 stop and give the user the per-client reconnect step from\n`references/connection.md`, then continue once the connector is available.\n\nHosted default: connect `https://plan.agent-native.com/mcp`. Do\nnot put shared secrets in skill files.\n";
+export declare const VISUAL_PLANS_SKILL_MD = "---\nname: visual-plan\ndescription: >-\n  Turn ordinary text plans into rich interactive visual plans with diagrams,\n  file maps, annotated code, open questions, and UI/prototype review when\n  useful.\nmetadata:\n  visibility: exported\n---\n\n# Agent-Native Plans\n\nAgent-Native Plans is structured visual planning mode for coding agents. Build\nthe plan you would normally write in Markdown, but as a scannable document with\neditable blocks mixed in: inline diagrams, code snippets,\nopen questions, and an optional top visual review area (wireframe canvas, live\nprototype, or both in tabs). Architecture and backend plans stay document-only;\nUI and product plans start with the top canvas/prototype (the Visual Surface\nChoice section owns that rule).\n\n`/visual-plan` is the packaged command and main entry point. Choose the review\nmode from the task: UI-first when the work is primarily product UI and review\nshould start with screens, prototype-first when review should start with a\nfunctional live prototype, design-first when review needs full-fidelity branded\nscreens, or visual-intake when the user explicitly wants a questionnaire before\nplanning. When a Codex, Claude Code, Markdown, or pasted plan already exists,\n`/visual-plan` uses that source plan as the starting point and builds the review\nsurface from it instead of starting over.\n\n## When To Use\n\nCreate or adapt a visual plan whenever the plan would be better as a reviewable\nartifact than a chat paragraph. This includes modest work such as a single UI\nsurface with states, a small workflow, a before/after product change, or a\ncomponent/API/data-shape decision that needs alignment, plus larger multi-file,\nambiguous, long-running, risky, or UI-heavy work. Use it when architecture /\ndata flow / UI direction / options / open questions would benefit from inline\ndiagrams or structured blocks, when the user needs to react to a direction\nbefore you implement, or when an existing text plan needs a richer review\nsurface.\n\n## Plan Discipline\n\n- **Gate thoughtfully.** A visual plan is a richer review surface, not only a\n  tool for giant projects. Use it when the user needs to see, compare, comment\n  on, or approve a direction before code, even for a modest UI/state/workflow\n  change. Skip it for truly trivial, unambiguous work \u2014 typos, one-line fixes, a\n  single well-specified function, anything whose diff you could describe in one\n  sentence \u2014 and just make the change. Never pad a plan with filler and never\n  ship a single-step plan.\n- **Research before you draft.** Read the real files, actions, schema, and\n  patterns first; name actual files, symbols, and data shapes instead of\n  inventing them. Check existing `actions/` before proposing endpoints and prefer\n  named client helpers over raw fetch. Delegate wide exploration to a sub-agent.\n  Lead with reuse: for each step, name what it reuses \u2014 existing actions, schema,\n  components, helpers \u2014 before what it adds, so the plan explains the genuinely new\n  delta instead of redescribing what already exists.\n- **Decide the hard-to-reverse bets first.** For non-trivial backend, data, or API\n  work, sketch where the feature is headed, then call out the decisions that are\n  expensive to undo once data or callers depend on them \u2014 wire format, public ids,\n  data-model shape, auth and ownership boundaries \u2014 and get those right in the plan\n  even if most of the feature ships later. Then scope to the smallest first cut that\n  proves the approach without foreclosing it, stating both what is in and what is\n  explicitly deferred.\n- **Keep examples at the right altitude.** When the user's idea is a broad\n  framework, product, or operating-model change, do not collapse it into the\n  first concrete example, provider, or sync path they mention. Separate the core\n  abstraction from motivating examples and app/provider adapters. Use examples\n  to make the plan legible, but label them as examples unless they are the whole\n  requested scope.\n- **Publish standalone plans.** If the user pasted, referenced, or already has a\n  Codex / Claude Code / Markdown plan, treat it as source material, but rewrite\n  the published plan as a clean standalone proposal. Preserve the source plan's\n  useful intent and codebase facts, label inferred visuals as inferred, and avoid\n  revision language such as \"preserve the prior plan\", \"do not drop the old\n  idea\", \"unlike the previous version\", or \"this revision changes...\". A reader\n  who never saw the chat or earlier drafts should understand the plan.\n- **Make the first read concrete.** If the plan is meant to be shared with\n  someone outside the chat, or if the concept is abstract, lead near the top with\n  one concrete product example before mode tables, architecture, or roadmaps. For\n  UI-capable concepts, that usually means a top-canvas app state that shows the\n  real user workflow in product terms. Do not rely on phrases that only make\n  sense in conversation, and do not frame the plan as \"not the old idea\"; state\n  the positive model directly.\n- **Planning is read-only.** Make no source edits while building or reviewing the\n  plan. Start editing only after the user approves the direction.\n- **Clarify vs. assume.** Do not ask how to build it \u2014 explore and present the\n  approach and options in the plan. Ask a clarifying question only when an\n  ambiguity would change the design and you cannot resolve it from the code; use\n  the host agent's normal ask-user-question flow and batch 2-4 high-leverage\n  questions before finalizing. Do not call `create-visual-questions` for\n  ordinary clarification or preflight; reserve it for the visual-intake mode when\n  the user explicitly asks for a visual intake questionnaire. Otherwise state the\n  assumption explicitly and proceed, and keep anything unresolved in the plan's\n  single bottom `question-form` Open Questions block. For complex plans, do a\n  final open-question pass before handoff: if a decision would affect\n  architecture, scope, UX, data shape, or rollout, either decide it in the plan\n  with rationale or put it in that bottom form with a recommended default.\n- **The plan is the approval gate.** After surfacing it, ask the user to review\n  and approve before you write code, and name which files/areas the work touches.\n  Presenting the plan and requesting sign-off is the approval step \u2014 do not ask a\n  separate \"does this look good?\" question.\n- **The document is the source of truth, not the chat.** When scope shifts,\n  update the plan with `update-visual-plan` rather than only changing course in\n  chat, and make the updated document stand alone. Do not describe the update as\n  a correction to an earlier draft inside the plan itself. Re-read the approved\n  plan before major steps.\n\n## Create A Structured Agent-Native Plan \u2014 Never Inline\n\nThe deliverable is ALWAYS a structured Agent-Native Plan, not a chat-only plan.\nThe hosted Plan MCP connector (`plan` server, or legacy `agent-native-plans`) is\nthe default collaboration and commenting surface; it is not a reason to reject\nthe planning pattern as an external dependency or rented layer. Plans are\nportable source artifacts (`plan.mdx`, optional `canvas.mdx` /\n`prototype.mdx`, JSON, and HTML export), and ownership-sensitive workflows can\nuse local-files mode or a self-hosted/custom Plan app URL without abandoning the\nskill's review discipline. Do not advise the user to skip `/visual-plan` because\nthe default surface is hosted; choose the right Plan mode for the user's\nownership, privacy, sharing, and branding needs.\n\nBy default, create the plan via the Plan MCP connector and NEVER hand it over as\ninline chat content \u2014 no Markdown prose, ASCII sketch, table, or fenced\nwireframe. If the `plan` (or legacy `agent-native-plans`) tools are not visible,\ndiscover them through the host's `tool_search` first; if they are still missing,\nSTOP and give the user the client-specific reconnect step rather than improvising\nan inline plan. Before publishing, or whenever a connector or auth error appears,\nREAD `references/connection.md` in this skill directory \u2014 it is the single source\nof truth for the never-inline rule, connector discovery, and the per-client\nreconnect steps. Local-files privacy mode (after Tool Guidance) is the exception.\n\n## Core Workflow\n\nThis section describes the default hosted Plan MCP workflow. If\n`AGENT_NATIVE_PLANS_MODE=local-files` is set, or the user asks for fully local\nfiles/no hosted Plan writes, use **Local-Files Privacy Mode** instead; carry\nforward only the code-research and plan-composition guidance here.\n\n1. Follow the host agent's normal planning flow: inspect the codebase, delegate\n   wide exploration when useful, gather the info needed, and ask native\n   clarifying questions as needed before generating the plan. If a source plan\n   already exists, gather its exact text from the user's paste, a referenced\n   file, or recent visible agent context; do not invent source text.\n2. Call `get-plan-blocks` for the authoritative block catalog \u2014 do not author\n   from memorized tags. Then call the mode-matched create tool:\n   `create-visual-plan` for document-first plans (architecture, backend, data,\n   refactor, API), `create-ui-plan` for UI-first plans, `create-prototype-plan`\n   for prototype-first plans, `create-plan-design` for design-first plans,\n   `create-visual-questions` only when the user explicitly asks for a visual\n   intake questionnaire. When a source plan already exists,\n   pass it as `planText` and preserve the original plan's useful intent while\n   producing a standalone plan document, not a revision memo.\n3. For UI/product plans, compose the top canvas first with the primary\n   wireframes and annotated states, then write the document with native blocks\n   (see `references/canvas.md` and `references/document-quality.md`). For\n   broad product architecture plans with a user-facing implication, add a\n   concrete \"what this looks like in the app\" visual before the abstract\n   architecture or mode tables. Keep the document close to the standalone\n   Markdown plan the agent would normally output. If an existing plan was\n   provided, carry forward the right facts and decisions without referring to\n   the previous draft or explaining how this version differs. For non-visual\n   plans, skip the top visual surface (Visual Surface Choice below owns the rule)\n   and put `diagram`, `data-model`,\n   `api-endpoint`, `diff`, `file-tree`, `code`, and `annotated-code` blocks\n   directly next to the relevant prose.\n   Wide document layout is renderer-owned and intentionally allowlisted: only\n   literal code-review surfaces (`diff`, `annotated-code`) and `tabs` blocks\n   with vertical orientation or diff-like children break out wider than prose.\n   Keep `api-endpoint`, `openapi-spec`, `data-model`, `json-explorer`,\n   `wireframe`, question, and `custom-html` blocks in normal document flow unless\n   their own renderer says otherwise.\n4. Surface the returned Plans link or inline MCP App and ask the user to review.\n   Always include the actual URL in chat so the next step is a click in CLI or\n   other text-only hosts. When the host exposes an embedded browser/preview panel\n   and a tool can open arbitrary URLs there, open the returned plan URL\n   automatically for convenient review \u2014 a convenience and smoke test, never the\n   only handoff or the access\n   model. Plans should load out of the box for the local agent and local browser\n   session; if a signed-in embedded browser cannot read a local plan that an\n   anonymous/tool check can read, fix the app/action ownership or access path\n   rather than patching one plan by hand. For high-stakes plans (architecture,\n   backend, data, multi-file, or risky), also kick off the self-review pass in\n   **Self-Review Before Handoff** while the user reads, instead of blocking the\n   handoff on it.\n5. For hosted plans, call `get-plan-feedback` before editing, after review,\n   after any long pause,\n   and before the final response. Treat `anchorDetails`, resolver intent, recent\n   review events, and any focused screenshots from browser handoff as the source\n   of truth for exactly what changed and exactly what each comment points at.\n6. For hosted plans, apply changes with `update-visual-plan`, preferring\n   targeted `contentPatches`.\n   Treat the top-level `content` payload as a full replacement, not a merge; do\n   not send a partial `content` object to add a canvas or one block. If a full\n   replacement or `replace-blocks` is unavoidable, call `get-visual-plan`\n   immediately before the write, pass its `plan.updatedAt` as\n   `expectedUpdatedAt`, and carry forward every existing block and visual\n   surface. Never reuse a revision from an earlier read or feedback payload.\n   For source-control friendly edits, use granular `patch-visual-plan-source`\n   operations against the MDX files instead of regenerating the plan;\n   `replace-file` is also destructive and requires the same fresh\n   `expectedUpdatedAt` fence.\n7. After every hosted-plan write, call `get-visual-plan` again and compare the\n   persisted text, block IDs/counts, canvas frames, and prototype with the\n   intended result. A successful mutation response is not proof that unrelated\n   content survived. If the edit addressed agent-targeted feedback, only after\n   this verification call `resolve-plan-comment` for the thread and\n   `consume-plan-feedback` for its comments; do both so addressed feedback is\n   neither visibly open nor returned as pending work.\n8. For hosted plans, export with `export-visual-plan` only when the user wants a\n   shareable receipt or repo-check-in artifacts.\n\n## Self-Review Before Handoff\n\nThis adversarial self-review pass is opt-in, not default: run it only for\nhigh-stakes plans \u2014 irreversible migrations, security-sensitive work, or when\nthe user explicitly asks for extra rigor \u2014 and skip it otherwise. It roughly\ndoubles the cost of plan generation, so the default for small, UI-only,\nsingle-decision, or ordinary plans is to skip it, not to run it. Keep the pass\ncheap and non-blocking when it does run:\n\n- **Surface the plan first, review concurrently.** Post the link and let the user\n  start reading, then run the review in parallel \u2014 never make the user wait on it.\n- **Review the written plan; do not re-research.** Critique the plan text and its\n  own blocks. The grounding was already done while drafting, so the review checks\n  the output instead of re-exploring the repo.\n- **Spawn one skeptical reviewer** whose only job is to find what is weak, missing,\n  or wrong \u2014 not to praise. Point it at: hard-to-reverse decisions made implicitly\n  or not at all (wire format, public ids, data-model shape, auth, ownership); steps\n  not anchored in real files or symbols; a menu of options where the plan should\n  commit to one; obvious missing decisions (\"what happens when X?\", \"why not Y?\");\n  and padding or single-step filler.\n- **Fix vs. ask.** Apply clear-cut fixes yourself with `update-visual-plan`\n  `contentPatches` \u2014 vague non-goals, unanchored claims, an obvious missing\n  decision. Route genuine judgment calls back to the user instead: add them to the\n  bottom `question-form` Open Questions block or batch them into the normal\n  ask-user-question flow. Do not silently decide them.\n- **Do not surprise the user mid-read.** On a large plan, apply the patches before\n  the editor loads; otherwise note briefly that a self-review is running so the\n  plan changing under them is expected. When you next respond, summarize what the\n  review changed and what it surfaced for the user to decide.\n\n## Visual Surface Choice\n\nChoose the surface before creating the plan or after reading the source plan. Do\nnot add visual chrome by default:\n\nFor UI/product plans, the top canvas is usually the primary review surface. Put\nthe first meaningful wireframes there, not buried as document-body blocks. Use\nmultiple canvas artboards when states matter, such as the default view, an\noverflow menu or popover, a side panel, loading, or error. Put short annotations\nbeside frames with `targetId` plus `placement`; keep implementation details,\ntradeoffs, file maps, data contracts, risks, and verification in the document\nbody below the canvas.\n\nWhen the user asks for a flow, storyboard, journey, wireframe, canvas, or \"what\nthis looks like\", treat that as a canvas-first request. Make one artboard per\nuser-visible state, connect only adjacent transitions, and use short canvas\nannotations for the product notes. Do not substitute a document-body `diagram`\nblock for the requested storyboard just because HTML diagrams are faster to\nwrite; diagrams belong below the canvas for backend mechanics, architecture, or\ndata-flow explanation.\n\nKeep product wireframes and explanatory/meta diagrams separate. Start with pure\nscreens that look like the app state under discussion, without callout prose or\narchitecture notes embedded inside the UI. Put arrows, labels, contracts, data\nflow, and mode explanations in separate annotations, separate canvas diagrams,\nor the document body.\n\nWhen the plan touches an existing app, inspect the current shell/components\nbefore drawing. The first artboard should look like the real app at the same\ndensity: existing sidebars, toolbar placement, overflow menus, app chrome, and\nframework agent chrome stay in their real places. Model secondary surfaces as\nseparate states, such as a top-right overflow popover, sheet, panel, loading\nstate, or separate AgentSidebar, rather than inventing a permanent inspector or\nfolding framework chrome into the product UI.\n\n- **No visual surface** for architecture-only, backend-only, data migration,\n  copy-only, or otherwise non-visual plans. Do not use the top canvas for\n  architecture diagrams, dependency maps, file plans, API contracts, or\n  data-flow-only reviews. Use a strong document with local inline diagrams\n  only when relationships need a visual explanation, usually one spatial diagram\n  per recommendation or decision. Prefer grouped regions, layers, quadrants,\n  matrices, or before/after panels over a single-axis chain unless the\n  relationship is truly sequential.\n- **Canvas only** for one static screen, a before/after comparison, a component\n  state, a small popover, or a visual direction that does not require clicking.\n  Put those wireframes in `content.canvas` and omit `content.prototype`.\n- **Canvas + prototype** for multi-step UI flows, onboarding, wizards,\n  review/approval flows, navigation changes, or anything where the reviewer\n  needs to operate the behavior. Keep the static wireframes in\n  `content.canvas`, add the aligned functional prototype in\n  `content.prototype`, and rely on the top visual tabs to switch between them.\n  When both surfaces are present, open the Wireframes tab by default; the\n  prototype remains available as the interactive follow-up view.\n- **Prototype-first** when the user asks to operate the UI or when interaction is\n  the main question. Use `create-prototype-plan`, which still preserves static\n  mocks where useful.\n\nFor mixed canvas + prototype plans, reuse the same real labels, app statuses,\nand screen ids across both surfaces. The canvas is the inspectable static reference;\nthe prototype is the interactive version of that same flow, not a separate\ndesign direction.\n\nTreat \u201Chigher fidelity,\u201D \u201Cpixel-accurate,\u201D \u201Cpolished mockup,\u201D \u201Cproduction-like,\u201D\n\u201Creal design,\u201D and \u201Cnot a sketch/wireframe\u201D as design-first language even when\nthe request also says \u201Cmockup.\u201D For a new plan, use `create-plan-design`. For\nan existing plan, keep the same plan id and call `update-visual-plan` with a\n`set-visual-render-mode` patch using `renderMode: \"design\"` plus the upgraded\nscreen HTML/CSS in the same update. Ground the result in the real app shell,\ntokens, typography, spacing, and states, and add stable `data-design-id`\ntargets. Put scoped styles in each screen's `css` field, never in a `<style>`\ntag. The viewer-local Clean toggle only changes one browser's wireframe\npreference; it is not a fidelity upgrade. Do not create a duplicate plan to\nhandle a fidelity follow-up.\n\n## Wireframe quality \u2014 read `references/wireframe.md`\n\nUI recap/plan wireframes must meet a strict quality bar \u2014 full-width chrome,\npinned bottom bars, real product content, before/after comparability, the right\n`surface` preset, `--wf-*` tokens instead of hex, and no `<html>`/`<style>`/font\ntags. Before authoring ANY wireframe / `<Screen>` / `WireframeBlock`, READ\n`references/wireframe.md` in this skill directory \u2014 it is the single source of\ntruth for HTML wireframe quality, shared word for word with `/visual-plan`\nand `/visual-recap`. Do not author wireframes from memory.\n\n## Canvas \u2014 read `references/canvas.md`\n\nThe 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.\nCanvas artboards use the same HTML wireframe path as document-body\n`WireframeBlock` screens: author `<Screen surface=\"...\" html={...} />` with a\nsemantic HTML fragment. Do not author fresh kit-tree children such as\n`<FrameScreen>`, `<Card>`, `<Row>`, or `<Btn>` inside canvas `<Screen>` tags;\nthose are legacy compatibility markup for old plans and produce brittle canvas\nlayouts.\n\n## Document quality \u2014 read `references/document-quality.md`\n\nThe document is a serious technical plan, not marketing: outcome-first,\nprose-first, self-contained, built from the right native blocks, with open\nquestions in a single bottom `question-form` and a pre-handoff visual check.\nBefore authoring the plan document, READ `references/document-quality.md` in this\nskill directory \u2014 it is the single source of truth for the document quality bar.\nDo not write the document from memory.\n\n## Good vs. bad exemplar \u2014 read `references/exemplar.md`\n\nFor a worked example of the bar \u2014 a great UI-first plan and `/visual-plan`, plus\nthe anti-patterns to avoid \u2014 READ `references/exemplar.md` in this skill\ndirectory before authoring a plan.\n\n## Tool Guidance\n\n- `create-visual-plan`: start one structured visual plan per agent task/run, or\n  import an existing text plan by passing `planText`; `content` may include no\n  visual surface, canvas only, or canvas + prototype.\n- `create-ui-plan`: start a UI-first plan when the work is primarily product UI.\n- `create-prototype-plan`: start a prototype-first plan with a functional top\n  review surface. If the interaction itself must also be high fidelity, set each\n  screen's `renderMode` to `design` and pass scoped styles through `css`;\n  otherwise use `create-plan-design` for design-first review.\n- `create-plan-design`: start a full-fidelity branded Design-tab plan with an\n  optional matching Prototype tab.\n- `convert-visual-plan-to-prototype`: convert an existing HTML wireframe canvas\n  into a prototype plan.\n- `create-visual-questions`: use only when the user explicitly asks for a visual\n  intake questionnaire, not as `/visual-plan` preflight.\n- `update-visual-plan`: revise content, status, or comments with targeted\n  `contentPatches` (see Core Workflow steps 6-7). Use\n  `set-visual-render-mode` with `renderMode: \"design\"` when promoting an\n  existing plan to high fidelity, together with deliberate screen HTML/CSS;\n  render mode alone only removes sketch treatment. `replace-blocks` and full\n  `content` replacement require `expectedUpdatedAt` from a fresh\n  `get-visual-plan` call.\n- `read-visual-plan-source`: read the normalized plan as `plan.mdx`,\n  optional `canvas.mdx`, optional `.plan-state.json`, and JSON.\n- `patch-visual-plan-source`: apply granular MDX AST patches by stable block,\n  artboard, annotation, component, or wireframe-node id. Prefer those targeted\n  operations; `replace-file` requires `expectedUpdatedAt` from a fresh\n  `get-visual-plan` call.\n- `import-visual-plan-source`: create or replace a plan from an MDX folder.\n- `get-visual-plan`: read the current structured plan, exported HTML,\n  annotations, and `plan.updatedAt`; it also returns the MDX folder for source\n  workflows. Re-read immediately before a destructive write for its concurrency\n  fence and again after every write to verify persisted state.\n- `get-plan-feedback`: read unconsumed human feedback. Use it frequently; it\n  returns grouped threads, exact anchor details, expected resolver, and recent\n  review-event payloads so agents can act only on the comments meant for them.\n- `get-plan-blocks`: resolve block tags before authoring \u2014 do not memorize tags;\n  call this first to get the authoritative tag names, required fields, and prop\n  shapes from the live block registry.\n- `export-visual-plan`: export HTML, Markdown fallback, structured JSON, and MDX\n  files for repo check-in.\n\nWhen the user critiques a plan's look or structure, fix the renderer or this\nskill \u2014 never hand-edit one stored plan. Turn feedback into better guidance.\n\n## Local-Files Privacy Mode \u2014 read `references/local-files.md`\n\nWhen the user wants no hosted Plan database writes \u2014 no DB writes, no Plan MCP\npublish, fully local/offline/private planning, repo-owned source-controlled\nartifacts, or `AGENT_NATIVE_PLANS_MODE=local-files` \u2014 do not call any hosted Plan\ntool except the schema-only `get-plan-blocks` catalog lookup. Author a local MDX\nfolder and\npreview it with `plan local check` / `plan local serve` / `plan local verify`.\nBefore using local-files mode, READ `references/local-files.md` in this skill\ndirectory \u2014 it is the single source of truth for the full contract (catalog\nlookup, MDX folder layout, the local bridge commands, and the hosted tools you\nmust not call). Carry forward only the code-research and plan-composition\nguidance from Core Workflow; everything hosted is replaced by the local bridge.\n\n## Interpreting comment anchors\n\nThis section applies to hosted plans with `get-plan-feedback` /\n`update-visual-plan`. In local-files mode, do not call hosted feedback or update\ntools; interpret file/chat feedback directly, edit the MDX files, rerun the\nlocal bridge check/serve/verify command, and report the new local URL.\n\n`get-plan-feedback` returns rich anchors \u2014 read them before acting on any comment.\n\n- **Coordinate frames.** `targetX`/`targetY` are percentages *within* the\n  element named by `targetSelector`/`targetKind`. Bare `x`/`y` are percentages\n  of the whole plan document. `canvasX`/`canvasY` are raw board-world pixels on\n  the design canvas (board size given when available).\n- **Wireframe pins.** Anchors on wireframes include `targetNodeId` and\n  `targetNodePath` (e.g. `card > list > listItem \"Acme Inc\"`) identifying the\n  exact kit node. Use `targetNodeId` directly with wireframe node patch ops;\n  use `data-design-id` values from design artboards with\n  `update-design-element-style`. Prefer the node id/path over raw coordinates;\n  fall back to coordinates plus the focused screenshot (red ring marks the exact\n  point) only when no node id is present.\n- **Text quotes.** Resolve `textQuote` against current prose using\n  `contextBefore`/`contextAfter` for disambiguation. If `ambiguous: true`, ask\n  the user \u2014 do not guess which occurrence is meant.\n- **Detached comments.** `get-plan-feedback` flags threads whose quoted text no\n  longer exists as `detached` (in `detachedThreads`). Reconcile these against\n  rewritten content \u2014 never silently drop them.\n- **Routing.** `resolutionTarget` is the only routing signal: act on `agent`,\n  treat `human` as context only. `@mentions` are people to notify, never a\n  routing signal.\n- **Two-axis state.** Mark every ingested comment as consumed\n  (`consumedCommentIds` on `update-visual-plan`). Set `status=resolved` only on\n  agent-targeted comments you actually addressed; leave human-targeted comments\n  open. When an edit addresses feedback, first re-read the persisted plan and\n  verify the requested change. Only then call `resolve-plan-comment` for the\n  addressed thread and `consume-plan-feedback` for its comments; never mark\n  addressed feedback along only one axis.\n\n## Visibility & Sharing\n\nUse `set-resource-visibility` to change who can see a plan (e.g. public, login,\nor org-scoped). Use `share-resource` to grant specific users or roles access\nby email or role. Gate visibility before sharing any plan that covers\nunreleased or private work \u2014 default to the narrowest scope that meets the\nreview need.\n\n## Setup & Authentication\n\nThere are two ways into Plans.\n\n**Coding agent (CLI).** Install once with the Agent-Native CLI. The command\ninstalls the Plans skills, registers the hosted Plans MCP connector, and runs\nauth/setup for the selected local client(s) in the same step (a one-time browser\nsign-in at setup \u2014 this is intended), so the first tool call in that client does\nnot hit an OAuth wall:\n\n```bash\nnpx @agent-native/core@latest skills add visual-plans\n```\n\nAfter that, `/visual-plan`, `/visual-recap`, and `/visualize-repo` are the\ninstalled slash commands. If you only need one command, use\n`skills add visual-plan`, `skills add visual-recap`, or\n`skills add visualize-repo` instead. The other planning modes\n(`create-ui-plan`, `create-prototype-plan`, `create-plan-design`,\n`create-visual-questions`) are MCP tools reachable from `/visual-plan`, not\nseparate slash commands. Pass `--no-connect` to register the connector without\nauthenticating, then run\n`npx @agent-native/core@latest connect https://plan.agent-native.com --client all`\nwhenever you are ready, or choose a narrower `--client`. Auth and MCP tool\nloading are per client config/session.\n\n**Browser (people you share with).** Open the Plans editor and create & edit\nwith no sign-up \u2014 you work as a guest. Sign in only when you want to save or\nshare; signing in claims the plans you made as a guest into your account.\n\nSharing and commenting require an account: public/shared plans are viewable by\nanyone with the link, but commenting on them needs an agent-native account.\n\nFor fully offline, no-account use, run the Plans app locally and sync plans to\nyour repo as MDX. This local mode is a separate advanced path, not the default\nhosted flow.\n\nFor repo-wide visual docs, run\n`npx @agent-native/core@latest visualize-repo --open` to create/update\n`agent-native.json`, seed `.agent-native/visual-docs/repo-overview`, and open\nthe local bridge.\n\nIf a Plans tool returns `needs auth`, `Unauthorized`, or `Session terminated`, do\nnot keep retrying it \u2014 stop and give the user the per-client reconnect step from\n`references/connection.md`, then continue once the connector is available.\n\nHosted default: connect `https://plan.agent-native.com/mcp`. Do\nnot put shared secrets in skill files.\n";
 //# sourceMappingURL=visual-plan-skill.d.ts.map

package/dist/cli/skills-content/visual-plan-skill.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"visual-plan-skill.d.ts","sourceRoot":"","sources":["../../../src/cli/skills-content/visual-plan-skill.ts"],"names":[],"mappings":"AAAA,eAAO,MAAM,qBAAqB,4s7BA4ejC,CAAC"}
+{"version":3,"file":"visual-plan-skill.d.ts","sourceRoot":"","sources":["../../../src/cli/skills-content/visual-plan-skill.ts"],"names":[],"mappings":"AAAA,eAAO,MAAM,qBAAqB,y99BA6fjC,CAAC"}

package/dist/cli/skills-content/visual-plan-skill.js

@@ -301,6 +301,18 @@ and screen ids across both surfaces. The canvas is the inspectable static refere
 the prototype is the interactive version of that same flow, not a separate
 design direction.
 
+Treat “higher fidelity,” “pixel-accurate,” “polished mockup,” “production-like,”
+“real design,” and “not a sketch/wireframe” as design-first language even when
+the request also says “mockup.” For a new plan, use \`create-plan-design\`. For
+an existing plan, keep the same plan id and call \`update-visual-plan\` with a
+\`set-visual-render-mode\` patch using \`renderMode: "design"\` plus the upgraded
+screen HTML/CSS in the same update. Ground the result in the real app shell,
+tokens, typography, spacing, and states, and add stable \`data-design-id\`
+targets. Put scoped styles in each screen's \`css\` field, never in a \`<style>\`
+tag. The viewer-local Clean toggle only changes one browser's wireframe
+preference; it is not a fidelity upgrade. Do not create a duplicate plan to
+handle a fidelity follow-up.
+
 ## Wireframe quality — read \`references/wireframe.md\`
 
 UI recap/plan wireframes must meet a strict quality bar — full-width chrome,
@@ -349,7 +361,9 @@ directory before authoring a plan.
   visual surface, canvas only, or canvas + prototype.
 - \`create-ui-plan\`: start a UI-first plan when the work is primarily product UI.
 - \`create-prototype-plan\`: start a prototype-first plan with a functional top
-  review surface.
+  review surface. If the interaction itself must also be high fidelity, set each
+  screen's \`renderMode\` to \`design\` and pass scoped styles through \`css\`;
+  otherwise use \`create-plan-design\` for design-first review.
 - \`create-plan-design\`: start a full-fidelity branded Design-tab plan with an
   optional matching Prototype tab.
 - \`convert-visual-plan-to-prototype\`: convert an existing HTML wireframe canvas
@@ -357,7 +371,10 @@ directory before authoring a plan.
 - \`create-visual-questions\`: use only when the user explicitly asks for a visual
   intake questionnaire, not as \`/visual-plan\` preflight.
 - \`update-visual-plan\`: revise content, status, or comments with targeted
-  \`contentPatches\` (see Core Workflow steps 6-7). \`replace-blocks\` and full
+  \`contentPatches\` (see Core Workflow steps 6-7). Use
+  \`set-visual-render-mode\` with \`renderMode: "design"\` when promoting an
+  existing plan to high fidelity, together with deliberate screen HTML/CSS;
+  render mode alone only removes sketch treatment. \`replace-blocks\` and full
   \`content\` replacement require \`expectedUpdatedAt\` from a fresh
   \`get-visual-plan\` call.
 - \`read-visual-plan-source\`: read the normalized plan as \`plan.mdx\`,

package/dist/cli/skills-content/visual-plan-skill.js.map

@@ -1 +1 @@
-{"version":3,"file":"visual-plan-skill.js","sourceRoot":"","sources":["../../../src/cli/skills-content/visual-plan-skill.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,qBAAqB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA4epC,CAAC","sourcesContent":["export const VISUAL_PLANS_SKILL_MD = `---\nname: visual-plan\ndescription: >-\n  Turn ordinary text plans into rich interactive visual plans with diagrams,\n  file maps, annotated code, open questions, and UI/prototype review when\n  useful.\nmetadata:\n  visibility: exported\n---\n\n# Agent-Native Plans\n\nAgent-Native Plans is structured visual planning mode for coding agents. Build\nthe plan you would normally write in Markdown, but as a scannable document with\neditable blocks mixed in: inline diagrams, code snippets,\nopen questions, and an optional top visual review area (wireframe canvas, live\nprototype, or both in tabs). Architecture and backend plans stay document-only;\nUI and product plans start with the top canvas/prototype (the Visual Surface\nChoice section owns that rule).\n\n\\`/visual-plan\\` is the packaged command and main entry point. Choose the review\nmode from the task: UI-first when the work is primarily product UI and review\nshould start with screens, prototype-first when review should start with a\nfunctional live prototype, design-first when review needs full-fidelity branded\nscreens, or visual-intake when the user explicitly wants a questionnaire before\nplanning. When a Codex, Claude Code, Markdown, or pasted plan already exists,\n\\`/visual-plan\\` uses that source plan as the starting point and builds the review\nsurface from it instead of starting over.\n\n## When To Use\n\nCreate or adapt a visual plan whenever the plan would be better as a reviewable\nartifact than a chat paragraph. This includes modest work such as a single UI\nsurface with states, a small workflow, a before/after product change, or a\ncomponent/API/data-shape decision that needs alignment, plus larger multi-file,\nambiguous, long-running, risky, or UI-heavy work. Use it when architecture /\ndata flow / UI direction / options / open questions would benefit from inline\ndiagrams or structured blocks, when the user needs to react to a direction\nbefore you implement, or when an existing text plan needs a richer review\nsurface.\n\n## Plan Discipline\n\n- **Gate thoughtfully.** A visual plan is a richer review surface, not only a\n  tool for giant projects. Use it when the user needs to see, compare, comment\n  on, or approve a direction before code, even for a modest UI/state/workflow\n  change. Skip it for truly trivial, unambiguous work — typos, one-line fixes, a\n  single well-specified function, anything whose diff you could describe in one\n  sentence — and just make the change. Never pad a plan with filler and never\n  ship a single-step plan.\n- **Research before you draft.** Read the real files, actions, schema, and\n  patterns first; name actual files, symbols, and data shapes instead of\n  inventing them. Check existing \\`actions/\\` before proposing endpoints and prefer\n  named client helpers over raw fetch. Delegate wide exploration to a sub-agent.\n  Lead with reuse: for each step, name what it reuses — existing actions, schema,\n  components, helpers — before what it adds, so the plan explains the genuinely new\n  delta instead of redescribing what already exists.\n- **Decide the hard-to-reverse bets first.** For non-trivial backend, data, or API\n  work, sketch where the feature is headed, then call out the decisions that are\n  expensive to undo once data or callers depend on them — wire format, public ids,\n  data-model shape, auth and ownership boundaries — and get those right in the plan\n  even if most of the feature ships later. Then scope to the smallest first cut that\n  proves the approach without foreclosing it, stating both what is in and what is\n  explicitly deferred.\n- **Keep examples at the right altitude.** When the user's idea is a broad\n  framework, product, or operating-model change, do not collapse it into the\n  first concrete example, provider, or sync path they mention. Separate the core\n  abstraction from motivating examples and app/provider adapters. Use examples\n  to make the plan legible, but label them as examples unless they are the whole\n  requested scope.\n- **Publish standalone plans.** If the user pasted, referenced, or already has a\n  Codex / Claude Code / Markdown plan, treat it as source material, but rewrite\n  the published plan as a clean standalone proposal. Preserve the source plan's\n  useful intent and codebase facts, label inferred visuals as inferred, and avoid\n  revision language such as \"preserve the prior plan\", \"do not drop the old\n  idea\", \"unlike the previous version\", or \"this revision changes...\". A reader\n  who never saw the chat or earlier drafts should understand the plan.\n- **Make the first read concrete.** If the plan is meant to be shared with\n  someone outside the chat, or if the concept is abstract, lead near the top with\n  one concrete product example before mode tables, architecture, or roadmaps. For\n  UI-capable concepts, that usually means a top-canvas app state that shows the\n  real user workflow in product terms. Do not rely on phrases that only make\n  sense in conversation, and do not frame the plan as \"not the old idea\"; state\n  the positive model directly.\n- **Planning is read-only.** Make no source edits while building or reviewing the\n  plan. Start editing only after the user approves the direction.\n- **Clarify vs. assume.** Do not ask how to build it — explore and present the\n  approach and options in the plan. Ask a clarifying question only when an\n  ambiguity would change the design and you cannot resolve it from the code; use\n  the host agent's normal ask-user-question flow and batch 2-4 high-leverage\n  questions before finalizing. Do not call \\`create-visual-questions\\` for\n  ordinary clarification or preflight; reserve it for the visual-intake mode when\n  the user explicitly asks for a visual intake questionnaire. Otherwise state the\n  assumption explicitly and proceed, and keep anything unresolved in the plan's\n  single bottom \\`question-form\\` Open Questions block. For complex plans, do a\n  final open-question pass before handoff: if a decision would affect\n  architecture, scope, UX, data shape, or rollout, either decide it in the plan\n  with rationale or put it in that bottom form with a recommended default.\n- **The plan is the approval gate.** After surfacing it, ask the user to review\n  and approve before you write code, and name which files/areas the work touches.\n  Presenting the plan and requesting sign-off is the approval step — do not ask a\n  separate \"does this look good?\" question.\n- **The document is the source of truth, not the chat.** When scope shifts,\n  update the plan with \\`update-visual-plan\\` rather than only changing course in\n  chat, and make the updated document stand alone. Do not describe the update as\n  a correction to an earlier draft inside the plan itself. Re-read the approved\n  plan before major steps.\n\n## Create A Structured Agent-Native Plan — Never Inline\n\nThe deliverable is ALWAYS a structured Agent-Native Plan, not a chat-only plan.\nThe hosted Plan MCP connector (\\`plan\\` server, or legacy \\`agent-native-plans\\`) is\nthe default collaboration and commenting surface; it is not a reason to reject\nthe planning pattern as an external dependency or rented layer. Plans are\nportable source artifacts (\\`plan.mdx\\`, optional \\`canvas.mdx\\` /\n\\`prototype.mdx\\`, JSON, and HTML export), and ownership-sensitive workflows can\nuse local-files mode or a self-hosted/custom Plan app URL without abandoning the\nskill's review discipline. Do not advise the user to skip \\`/visual-plan\\` because\nthe default surface is hosted; choose the right Plan mode for the user's\nownership, privacy, sharing, and branding needs.\n\nBy default, create the plan via the Plan MCP connector and NEVER hand it over as\ninline chat content — no Markdown prose, ASCII sketch, table, or fenced\nwireframe. If the \\`plan\\` (or legacy \\`agent-native-plans\\`) tools are not visible,\ndiscover them through the host's \\`tool_search\\` first; if they are still missing,\nSTOP and give the user the client-specific reconnect step rather than improvising\nan inline plan. Before publishing, or whenever a connector or auth error appears,\nREAD \\`references/connection.md\\` in this skill directory — it is the single source\nof truth for the never-inline rule, connector discovery, and the per-client\nreconnect steps. Local-files privacy mode (after Tool Guidance) is the exception.\n\n## Core Workflow\n\nThis section describes the default hosted Plan MCP workflow. If\n\\`AGENT_NATIVE_PLANS_MODE=local-files\\` is set, or the user asks for fully local\nfiles/no hosted Plan writes, use **Local-Files Privacy Mode** instead; carry\nforward only the code-research and plan-composition guidance here.\n\n1. Follow the host agent's normal planning flow: inspect the codebase, delegate\n   wide exploration when useful, gather the info needed, and ask native\n   clarifying questions as needed before generating the plan. If a source plan\n   already exists, gather its exact text from the user's paste, a referenced\n   file, or recent visible agent context; do not invent source text.\n2. Call \\`get-plan-blocks\\` for the authoritative block catalog — do not author\n   from memorized tags. Then call the mode-matched create tool:\n   \\`create-visual-plan\\` for document-first plans (architecture, backend, data,\n   refactor, API), \\`create-ui-plan\\` for UI-first plans, \\`create-prototype-plan\\`\n   for prototype-first plans, \\`create-plan-design\\` for design-first plans,\n   \\`create-visual-questions\\` only when the user explicitly asks for a visual\n   intake questionnaire. When a source plan already exists,\n   pass it as \\`planText\\` and preserve the original plan's useful intent while\n   producing a standalone plan document, not a revision memo.\n3. For UI/product plans, compose the top canvas first with the primary\n   wireframes and annotated states, then write the document with native blocks\n   (see \\`references/canvas.md\\` and \\`references/document-quality.md\\`). For\n   broad product architecture plans with a user-facing implication, add a\n   concrete \"what this looks like in the app\" visual before the abstract\n   architecture or mode tables. Keep the document close to the standalone\n   Markdown plan the agent would normally output. If an existing plan was\n   provided, carry forward the right facts and decisions without referring to\n   the previous draft or explaining how this version differs. For non-visual\n   plans, skip the top visual surface (Visual Surface Choice below owns the rule)\n   and put \\`diagram\\`, \\`data-model\\`,\n   \\`api-endpoint\\`, \\`diff\\`, \\`file-tree\\`, \\`code\\`, and \\`annotated-code\\` blocks\n   directly next to the relevant prose.\n   Wide document layout is renderer-owned and intentionally allowlisted: only\n   literal code-review surfaces (\\`diff\\`, \\`annotated-code\\`) and \\`tabs\\` blocks\n   with vertical orientation or diff-like children break out wider than prose.\n   Keep \\`api-endpoint\\`, \\`openapi-spec\\`, \\`data-model\\`, \\`json-explorer\\`,\n   \\`wireframe\\`, question, and \\`custom-html\\` blocks in normal document flow unless\n   their own renderer says otherwise.\n4. Surface the returned Plans link or inline MCP App and ask the user to review.\n   Always include the actual URL in chat so the next step is a click in CLI or\n   other text-only hosts. When the host exposes an embedded browser/preview panel\n   and a tool can open arbitrary URLs there, open the returned plan URL\n   automatically for convenient review — a convenience and smoke test, never the\n   only handoff or the access\n   model. Plans should load out of the box for the local agent and local browser\n   session; if a signed-in embedded browser cannot read a local plan that an\n   anonymous/tool check can read, fix the app/action ownership or access path\n   rather than patching one plan by hand. For high-stakes plans (architecture,\n   backend, data, multi-file, or risky), also kick off the self-review pass in\n   **Self-Review Before Handoff** while the user reads, instead of blocking the\n   handoff on it.\n5. For hosted plans, call \\`get-plan-feedback\\` before editing, after review,\n   after any long pause,\n   and before the final response. Treat \\`anchorDetails\\`, resolver intent, recent\n   review events, and any focused screenshots from browser handoff as the source\n   of truth for exactly what changed and exactly what each comment points at.\n6. For hosted plans, apply changes with \\`update-visual-plan\\`, preferring\n   targeted \\`contentPatches\\`.\n   Treat the top-level \\`content\\` payload as a full replacement, not a merge; do\n   not send a partial \\`content\\` object to add a canvas or one block. If a full\n   replacement or \\`replace-blocks\\` is unavoidable, call \\`get-visual-plan\\`\n   immediately before the write, pass its \\`plan.updatedAt\\` as\n   \\`expectedUpdatedAt\\`, and carry forward every existing block and visual\n   surface. Never reuse a revision from an earlier read or feedback payload.\n   For source-control friendly edits, use granular \\`patch-visual-plan-source\\`\n   operations against the MDX files instead of regenerating the plan;\n   \\`replace-file\\` is also destructive and requires the same fresh\n   \\`expectedUpdatedAt\\` fence.\n7. After every hosted-plan write, call \\`get-visual-plan\\` again and compare the\n   persisted text, block IDs/counts, canvas frames, and prototype with the\n   intended result. A successful mutation response is not proof that unrelated\n   content survived. If the edit addressed agent-targeted feedback, only after\n   this verification call \\`resolve-plan-comment\\` for the thread and\n   \\`consume-plan-feedback\\` for its comments; do both so addressed feedback is\n   neither visibly open nor returned as pending work.\n8. For hosted plans, export with \\`export-visual-plan\\` only when the user wants a\n   shareable receipt or repo-check-in artifacts.\n\n## Self-Review Before Handoff\n\nThis adversarial self-review pass is opt-in, not default: run it only for\nhigh-stakes plans — irreversible migrations, security-sensitive work, or when\nthe user explicitly asks for extra rigor — and skip it otherwise. It roughly\ndoubles the cost of plan generation, so the default for small, UI-only,\nsingle-decision, or ordinary plans is to skip it, not to run it. Keep the pass\ncheap and non-blocking when it does run:\n\n- **Surface the plan first, review concurrently.** Post the link and let the user\n  start reading, then run the review in parallel — never make the user wait on it.\n- **Review the written plan; do not re-research.** Critique the plan text and its\n  own blocks. The grounding was already done while drafting, so the review checks\n  the output instead of re-exploring the repo.\n- **Spawn one skeptical reviewer** whose only job is to find what is weak, missing,\n  or wrong — not to praise. Point it at: hard-to-reverse decisions made implicitly\n  or not at all (wire format, public ids, data-model shape, auth, ownership); steps\n  not anchored in real files or symbols; a menu of options where the plan should\n  commit to one; obvious missing decisions (\"what happens when X?\", \"why not Y?\");\n  and padding or single-step filler.\n- **Fix vs. ask.** Apply clear-cut fixes yourself with \\`update-visual-plan\\`\n  \\`contentPatches\\` — vague non-goals, unanchored claims, an obvious missing\n  decision. Route genuine judgment calls back to the user instead: add them to the\n  bottom \\`question-form\\` Open Questions block or batch them into the normal\n  ask-user-question flow. Do not silently decide them.\n- **Do not surprise the user mid-read.** On a large plan, apply the patches before\n  the editor loads; otherwise note briefly that a self-review is running so the\n  plan changing under them is expected. When you next respond, summarize what the\n  review changed and what it surfaced for the user to decide.\n\n## Visual Surface Choice\n\nChoose the surface before creating the plan or after reading the source plan. Do\nnot add visual chrome by default:\n\nFor UI/product plans, the top canvas is usually the primary review surface. Put\nthe first meaningful wireframes there, not buried as document-body blocks. Use\nmultiple canvas artboards when states matter, such as the default view, an\noverflow menu or popover, a side panel, loading, or error. Put short annotations\nbeside frames with \\`targetId\\` plus \\`placement\\`; keep implementation details,\ntradeoffs, file maps, data contracts, risks, and verification in the document\nbody below the canvas.\n\nWhen the user asks for a flow, storyboard, journey, wireframe, canvas, or \"what\nthis looks like\", treat that as a canvas-first request. Make one artboard per\nuser-visible state, connect only adjacent transitions, and use short canvas\nannotations for the product notes. Do not substitute a document-body \\`diagram\\`\nblock for the requested storyboard just because HTML diagrams are faster to\nwrite; diagrams belong below the canvas for backend mechanics, architecture, or\ndata-flow explanation.\n\nKeep product wireframes and explanatory/meta diagrams separate. Start with pure\nscreens that look like the app state under discussion, without callout prose or\narchitecture notes embedded inside the UI. Put arrows, labels, contracts, data\nflow, and mode explanations in separate annotations, separate canvas diagrams,\nor the document body.\n\nWhen the plan touches an existing app, inspect the current shell/components\nbefore drawing. The first artboard should look like the real app at the same\ndensity: existing sidebars, toolbar placement, overflow menus, app chrome, and\nframework agent chrome stay in their real places. Model secondary surfaces as\nseparate states, such as a top-right overflow popover, sheet, panel, loading\nstate, or separate AgentSidebar, rather than inventing a permanent inspector or\nfolding framework chrome into the product UI.\n\n- **No visual surface** for architecture-only, backend-only, data migration,\n  copy-only, or otherwise non-visual plans. Do not use the top canvas for\n  architecture diagrams, dependency maps, file plans, API contracts, or\n  data-flow-only reviews. Use a strong document with local inline diagrams\n  only when relationships need a visual explanation, usually one spatial diagram\n  per recommendation or decision. Prefer grouped regions, layers, quadrants,\n  matrices, or before/after panels over a single-axis chain unless the\n  relationship is truly sequential.\n- **Canvas only** for one static screen, a before/after comparison, a component\n  state, a small popover, or a visual direction that does not require clicking.\n  Put those wireframes in \\`content.canvas\\` and omit \\`content.prototype\\`.\n- **Canvas + prototype** for multi-step UI flows, onboarding, wizards,\n  review/approval flows, navigation changes, or anything where the reviewer\n  needs to operate the behavior. Keep the static wireframes in\n  \\`content.canvas\\`, add the aligned functional prototype in\n  \\`content.prototype\\`, and rely on the top visual tabs to switch between them.\n  When both surfaces are present, open the Wireframes tab by default; the\n  prototype remains available as the interactive follow-up view.\n- **Prototype-first** when the user asks to operate the UI or when interaction is\n  the main question. Use \\`create-prototype-plan\\`, which still preserves static\n  mocks where useful.\n\nFor mixed canvas + prototype plans, reuse the same real labels, app statuses,\nand screen ids across both surfaces. The canvas is the inspectable static reference;\nthe prototype is the interactive version of that same flow, not a separate\ndesign direction.\n\n## Wireframe quality — read \\`references/wireframe.md\\`\n\nUI recap/plan wireframes must meet a strict quality bar — full-width chrome,\npinned bottom bars, real product content, before/after comparability, the right\n\\`surface\\` preset, \\`--wf-*\\` tokens instead of hex, and no \\`<html>\\`/\\`<style>\\`/font\ntags. Before authoring ANY wireframe / \\`<Screen>\\` / \\`WireframeBlock\\`, READ\n\\`references/wireframe.md\\` in this skill directory — it is the single source of\ntruth for HTML wireframe quality, shared word for word with \\`/visual-plan\\`\nand \\`/visual-recap\\`. Do not author wireframes from memory.\n\n## Canvas — read \\`references/canvas.md\\`\n\nThe 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 — it is the single source of truth\nfor canvas/artboard mechanics. Do not author canvas layouts from memory.\nCanvas artboards use the same HTML wireframe path as document-body\n\\`WireframeBlock\\` screens: author \\`<Screen surface=\"...\" html={...} />\\` with a\nsemantic HTML fragment. Do not author fresh kit-tree children such as\n\\`<FrameScreen>\\`, \\`<Card>\\`, \\`<Row>\\`, or \\`<Btn>\\` inside canvas \\`<Screen>\\` tags;\nthose are legacy compatibility markup for old plans and produce brittle canvas\nlayouts.\n\n## Document quality — read \\`references/document-quality.md\\`\n\nThe document is a serious technical plan, not marketing: outcome-first,\nprose-first, self-contained, built from the right native blocks, with open\nquestions in a single bottom \\`question-form\\` and a pre-handoff visual check.\nBefore authoring the plan document, READ \\`references/document-quality.md\\` in this\nskill directory — it is the single source of truth for the document quality bar.\nDo not write the document from memory.\n\n## Good vs. bad exemplar — read \\`references/exemplar.md\\`\n\nFor a worked example of the bar — a great UI-first plan and \\`/visual-plan\\`, plus\nthe anti-patterns to avoid — READ \\`references/exemplar.md\\` in this skill\ndirectory before authoring a plan.\n\n## Tool Guidance\n\n- \\`create-visual-plan\\`: start one structured visual plan per agent task/run, or\n  import an existing text plan by passing \\`planText\\`; \\`content\\` may include no\n  visual surface, canvas only, or canvas + prototype.\n- \\`create-ui-plan\\`: start a UI-first plan when the work is primarily product UI.\n- \\`create-prototype-plan\\`: start a prototype-first plan with a functional top\n  review surface.\n- \\`create-plan-design\\`: start a full-fidelity branded Design-tab plan with an\n  optional matching Prototype tab.\n- \\`convert-visual-plan-to-prototype\\`: convert an existing HTML wireframe canvas\n  into a prototype plan.\n- \\`create-visual-questions\\`: use only when the user explicitly asks for a visual\n  intake questionnaire, not as \\`/visual-plan\\` preflight.\n- \\`update-visual-plan\\`: revise content, status, or comments with targeted\n  \\`contentPatches\\` (see Core Workflow steps 6-7). \\`replace-blocks\\` and full\n  \\`content\\` replacement require \\`expectedUpdatedAt\\` from a fresh\n  \\`get-visual-plan\\` call.\n- \\`read-visual-plan-source\\`: read the normalized plan as \\`plan.mdx\\`,\n  optional \\`canvas.mdx\\`, optional \\`.plan-state.json\\`, and JSON.\n- \\`patch-visual-plan-source\\`: apply granular MDX AST patches by stable block,\n  artboard, annotation, component, or wireframe-node id. Prefer those targeted\n  operations; \\`replace-file\\` requires \\`expectedUpdatedAt\\` from a fresh\n  \\`get-visual-plan\\` call.\n- \\`import-visual-plan-source\\`: create or replace a plan from an MDX folder.\n- \\`get-visual-plan\\`: read the current structured plan, exported HTML,\n  annotations, and \\`plan.updatedAt\\`; it also returns the MDX folder for source\n  workflows. Re-read immediately before a destructive write for its concurrency\n  fence and again after every write to verify persisted state.\n- \\`get-plan-feedback\\`: read unconsumed human feedback. Use it frequently; it\n  returns grouped threads, exact anchor details, expected resolver, and recent\n  review-event payloads so agents can act only on the comments meant for them.\n- \\`get-plan-blocks\\`: resolve block tags before authoring — do not memorize tags;\n  call this first to get the authoritative tag names, required fields, and prop\n  shapes from the live block registry.\n- \\`export-visual-plan\\`: export HTML, Markdown fallback, structured JSON, and MDX\n  files for repo check-in.\n\nWhen the user critiques a plan's look or structure, fix the renderer or this\nskill — never hand-edit one stored plan. Turn feedback into better guidance.\n\n## Local-Files Privacy Mode — read \\`references/local-files.md\\`\n\nWhen the user wants no hosted Plan database writes — no DB writes, no Plan MCP\npublish, fully local/offline/private planning, repo-owned source-controlled\nartifacts, or \\`AGENT_NATIVE_PLANS_MODE=local-files\\` — do not call any hosted Plan\ntool except the schema-only \\`get-plan-blocks\\` catalog lookup. Author a local MDX\nfolder and\npreview it with \\`plan local check\\` / \\`plan local serve\\` / \\`plan local verify\\`.\nBefore using local-files mode, READ \\`references/local-files.md\\` in this skill\ndirectory — it is the single source of truth for the full contract (catalog\nlookup, MDX folder layout, the local bridge commands, and the hosted tools you\nmust not call). Carry forward only the code-research and plan-composition\nguidance from Core Workflow; everything hosted is replaced by the local bridge.\n\n## Interpreting comment anchors\n\nThis section applies to hosted plans with \\`get-plan-feedback\\` /\n\\`update-visual-plan\\`. In local-files mode, do not call hosted feedback or update\ntools; interpret file/chat feedback directly, edit the MDX files, rerun the\nlocal bridge check/serve/verify command, and report the new local URL.\n\n\\`get-plan-feedback\\` returns rich anchors — read them before acting on any comment.\n\n- **Coordinate frames.** \\`targetX\\`/\\`targetY\\` are percentages *within* the\n  element named by \\`targetSelector\\`/\\`targetKind\\`. Bare \\`x\\`/\\`y\\` are percentages\n  of the whole plan document. \\`canvasX\\`/\\`canvasY\\` are raw board-world pixels on\n  the design canvas (board size given when available).\n- **Wireframe pins.** Anchors on wireframes include \\`targetNodeId\\` and\n  \\`targetNodePath\\` (e.g. \\`card > list > listItem \"Acme Inc\"\\`) identifying the\n  exact kit node. Use \\`targetNodeId\\` directly with wireframe node patch ops;\n  use \\`data-design-id\\` values from design artboards with\n  \\`update-design-element-style\\`. Prefer the node id/path over raw coordinates;\n  fall back to coordinates plus the focused screenshot (red ring marks the exact\n  point) only when no node id is present.\n- **Text quotes.** Resolve \\`textQuote\\` against current prose using\n  \\`contextBefore\\`/\\`contextAfter\\` for disambiguation. If \\`ambiguous: true\\`, ask\n  the user — do not guess which occurrence is meant.\n- **Detached comments.** \\`get-plan-feedback\\` flags threads whose quoted text no\n  longer exists as \\`detached\\` (in \\`detachedThreads\\`). Reconcile these against\n  rewritten content — never silently drop them.\n- **Routing.** \\`resolutionTarget\\` is the only routing signal: act on \\`agent\\`,\n  treat \\`human\\` as context only. \\`@mentions\\` are people to notify, never a\n  routing signal.\n- **Two-axis state.** Mark every ingested comment as consumed\n  (\\`consumedCommentIds\\` on \\`update-visual-plan\\`). Set \\`status=resolved\\` only on\n  agent-targeted comments you actually addressed; leave human-targeted comments\n  open. When an edit addresses feedback, first re-read the persisted plan and\n  verify the requested change. Only then call \\`resolve-plan-comment\\` for the\n  addressed thread and \\`consume-plan-feedback\\` for its comments; never mark\n  addressed feedback along only one axis.\n\n## Visibility & Sharing\n\nUse \\`set-resource-visibility\\` to change who can see a plan (e.g. public, login,\nor org-scoped). Use \\`share-resource\\` to grant specific users or roles access\nby email or role. Gate visibility before sharing any plan that covers\nunreleased or private work — default to the narrowest scope that meets the\nreview need.\n\n## Setup & Authentication\n\nThere are two ways into Plans.\n\n**Coding agent (CLI).** Install once with the Agent-Native CLI. The command\ninstalls the Plans skills, registers the hosted Plans MCP connector, and runs\nauth/setup for the selected local client(s) in the same step (a one-time browser\nsign-in at setup — this is intended), so the first tool call in that client does\nnot hit an OAuth wall:\n\n\\`\\`\\`bash\nnpx @agent-native/core@latest skills add visual-plans\n\\`\\`\\`\n\nAfter that, \\`/visual-plan\\`, \\`/visual-recap\\`, and \\`/visualize-repo\\` are the\ninstalled slash commands. If you only need one command, use\n\\`skills add visual-plan\\`, \\`skills add visual-recap\\`, or\n\\`skills add visualize-repo\\` instead. The other planning modes\n(\\`create-ui-plan\\`, \\`create-prototype-plan\\`, \\`create-plan-design\\`,\n\\`create-visual-questions\\`) are MCP tools reachable from \\`/visual-plan\\`, not\nseparate slash commands. Pass \\`--no-connect\\` to register the connector without\nauthenticating, then run\n\\`npx @agent-native/core@latest connect https://plan.agent-native.com --client all\\`\nwhenever you are ready, or choose a narrower \\`--client\\`. Auth and MCP tool\nloading are per client config/session.\n\n**Browser (people you share with).** Open the Plans editor and create & edit\nwith no sign-up — you work as a guest. Sign in only when you want to save or\nshare; signing in claims the plans you made as a guest into your account.\n\nSharing and commenting require an account: public/shared plans are viewable by\nanyone with the link, but commenting on them needs an agent-native account.\n\nFor fully offline, no-account use, run the Plans app locally and sync plans to\nyour repo as MDX. This local mode is a separate advanced path, not the default\nhosted flow.\n\nFor repo-wide visual docs, run\n\\`npx @agent-native/core@latest visualize-repo --open\\` to create/update\n\\`agent-native.json\\`, seed \\`.agent-native/visual-docs/repo-overview\\`, and open\nthe local bridge.\n\nIf a Plans tool returns \\`needs auth\\`, \\`Unauthorized\\`, or \\`Session terminated\\`, do\nnot keep retrying it — stop and give the user the per-client reconnect step from\n\\`references/connection.md\\`, then continue once the connector is available.\n\nHosted default: connect \\`https://plan.agent-native.com/mcp\\`. Do\nnot put shared secrets in skill files.\n`;\n"]}
+{"version":3,"file":"visual-plan-skill.js","sourceRoot":"","sources":["../../../src/cli/skills-content/visual-plan-skill.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,qBAAqB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6fpC,CAAC","sourcesContent":["export const VISUAL_PLANS_SKILL_MD = `---\nname: visual-plan\ndescription: >-\n  Turn ordinary text plans into rich interactive visual plans with diagrams,\n  file maps, annotated code, open questions, and UI/prototype review when\n  useful.\nmetadata:\n  visibility: exported\n---\n\n# Agent-Native Plans\n\nAgent-Native Plans is structured visual planning mode for coding agents. Build\nthe plan you would normally write in Markdown, but as a scannable document with\neditable blocks mixed in: inline diagrams, code snippets,\nopen questions, and an optional top visual review area (wireframe canvas, live\nprototype, or both in tabs). Architecture and backend plans stay document-only;\nUI and product plans start with the top canvas/prototype (the Visual Surface\nChoice section owns that rule).\n\n\\`/visual-plan\\` is the packaged command and main entry point. Choose the review\nmode from the task: UI-first when the work is primarily product UI and review\nshould start with screens, prototype-first when review should start with a\nfunctional live prototype, design-first when review needs full-fidelity branded\nscreens, or visual-intake when the user explicitly wants a questionnaire before\nplanning. When a Codex, Claude Code, Markdown, or pasted plan already exists,\n\\`/visual-plan\\` uses that source plan as the starting point and builds the review\nsurface from it instead of starting over.\n\n## When To Use\n\nCreate or adapt a visual plan whenever the plan would be better as a reviewable\nartifact than a chat paragraph. This includes modest work such as a single UI\nsurface with states, a small workflow, a before/after product change, or a\ncomponent/API/data-shape decision that needs alignment, plus larger multi-file,\nambiguous, long-running, risky, or UI-heavy work. Use it when architecture /\ndata flow / UI direction / options / open questions would benefit from inline\ndiagrams or structured blocks, when the user needs to react to a direction\nbefore you implement, or when an existing text plan needs a richer review\nsurface.\n\n## Plan Discipline\n\n- **Gate thoughtfully.** A visual plan is a richer review surface, not only a\n  tool for giant projects. Use it when the user needs to see, compare, comment\n  on, or approve a direction before code, even for a modest UI/state/workflow\n  change. Skip it for truly trivial, unambiguous work — typos, one-line fixes, a\n  single well-specified function, anything whose diff you could describe in one\n  sentence — and just make the change. Never pad a plan with filler and never\n  ship a single-step plan.\n- **Research before you draft.** Read the real files, actions, schema, and\n  patterns first; name actual files, symbols, and data shapes instead of\n  inventing them. Check existing \\`actions/\\` before proposing endpoints and prefer\n  named client helpers over raw fetch. Delegate wide exploration to a sub-agent.\n  Lead with reuse: for each step, name what it reuses — existing actions, schema,\n  components, helpers — before what it adds, so the plan explains the genuinely new\n  delta instead of redescribing what already exists.\n- **Decide the hard-to-reverse bets first.** For non-trivial backend, data, or API\n  work, sketch where the feature is headed, then call out the decisions that are\n  expensive to undo once data or callers depend on them — wire format, public ids,\n  data-model shape, auth and ownership boundaries — and get those right in the plan\n  even if most of the feature ships later. Then scope to the smallest first cut that\n  proves the approach without foreclosing it, stating both what is in and what is\n  explicitly deferred.\n- **Keep examples at the right altitude.** When the user's idea is a broad\n  framework, product, or operating-model change, do not collapse it into the\n  first concrete example, provider, or sync path they mention. Separate the core\n  abstraction from motivating examples and app/provider adapters. Use examples\n  to make the plan legible, but label them as examples unless they are the whole\n  requested scope.\n- **Publish standalone plans.** If the user pasted, referenced, or already has a\n  Codex / Claude Code / Markdown plan, treat it as source material, but rewrite\n  the published plan as a clean standalone proposal. Preserve the source plan's\n  useful intent and codebase facts, label inferred visuals as inferred, and avoid\n  revision language such as \"preserve the prior plan\", \"do not drop the old\n  idea\", \"unlike the previous version\", or \"this revision changes...\". A reader\n  who never saw the chat or earlier drafts should understand the plan.\n- **Make the first read concrete.** If the plan is meant to be shared with\n  someone outside the chat, or if the concept is abstract, lead near the top with\n  one concrete product example before mode tables, architecture, or roadmaps. For\n  UI-capable concepts, that usually means a top-canvas app state that shows the\n  real user workflow in product terms. Do not rely on phrases that only make\n  sense in conversation, and do not frame the plan as \"not the old idea\"; state\n  the positive model directly.\n- **Planning is read-only.** Make no source edits while building or reviewing the\n  plan. Start editing only after the user approves the direction.\n- **Clarify vs. assume.** Do not ask how to build it — explore and present the\n  approach and options in the plan. Ask a clarifying question only when an\n  ambiguity would change the design and you cannot resolve it from the code; use\n  the host agent's normal ask-user-question flow and batch 2-4 high-leverage\n  questions before finalizing. Do not call \\`create-visual-questions\\` for\n  ordinary clarification or preflight; reserve it for the visual-intake mode when\n  the user explicitly asks for a visual intake questionnaire. Otherwise state the\n  assumption explicitly and proceed, and keep anything unresolved in the plan's\n  single bottom \\`question-form\\` Open Questions block. For complex plans, do a\n  final open-question pass before handoff: if a decision would affect\n  architecture, scope, UX, data shape, or rollout, either decide it in the plan\n  with rationale or put it in that bottom form with a recommended default.\n- **The plan is the approval gate.** After surfacing it, ask the user to review\n  and approve before you write code, and name which files/areas the work touches.\n  Presenting the plan and requesting sign-off is the approval step — do not ask a\n  separate \"does this look good?\" question.\n- **The document is the source of truth, not the chat.** When scope shifts,\n  update the plan with \\`update-visual-plan\\` rather than only changing course in\n  chat, and make the updated document stand alone. Do not describe the update as\n  a correction to an earlier draft inside the plan itself. Re-read the approved\n  plan before major steps.\n\n## Create A Structured Agent-Native Plan — Never Inline\n\nThe deliverable is ALWAYS a structured Agent-Native Plan, not a chat-only plan.\nThe hosted Plan MCP connector (\\`plan\\` server, or legacy \\`agent-native-plans\\`) is\nthe default collaboration and commenting surface; it is not a reason to reject\nthe planning pattern as an external dependency or rented layer. Plans are\nportable source artifacts (\\`plan.mdx\\`, optional \\`canvas.mdx\\` /\n\\`prototype.mdx\\`, JSON, and HTML export), and ownership-sensitive workflows can\nuse local-files mode or a self-hosted/custom Plan app URL without abandoning the\nskill's review discipline. Do not advise the user to skip \\`/visual-plan\\` because\nthe default surface is hosted; choose the right Plan mode for the user's\nownership, privacy, sharing, and branding needs.\n\nBy default, create the plan via the Plan MCP connector and NEVER hand it over as\ninline chat content — no Markdown prose, ASCII sketch, table, or fenced\nwireframe. If the \\`plan\\` (or legacy \\`agent-native-plans\\`) tools are not visible,\ndiscover them through the host's \\`tool_search\\` first; if they are still missing,\nSTOP and give the user the client-specific reconnect step rather than improvising\nan inline plan. Before publishing, or whenever a connector or auth error appears,\nREAD \\`references/connection.md\\` in this skill directory — it is the single source\nof truth for the never-inline rule, connector discovery, and the per-client\nreconnect steps. Local-files privacy mode (after Tool Guidance) is the exception.\n\n## Core Workflow\n\nThis section describes the default hosted Plan MCP workflow. If\n\\`AGENT_NATIVE_PLANS_MODE=local-files\\` is set, or the user asks for fully local\nfiles/no hosted Plan writes, use **Local-Files Privacy Mode** instead; carry\nforward only the code-research and plan-composition guidance here.\n\n1. Follow the host agent's normal planning flow: inspect the codebase, delegate\n   wide exploration when useful, gather the info needed, and ask native\n   clarifying questions as needed before generating the plan. If a source plan\n   already exists, gather its exact text from the user's paste, a referenced\n   file, or recent visible agent context; do not invent source text.\n2. Call \\`get-plan-blocks\\` for the authoritative block catalog — do not author\n   from memorized tags. Then call the mode-matched create tool:\n   \\`create-visual-plan\\` for document-first plans (architecture, backend, data,\n   refactor, API), \\`create-ui-plan\\` for UI-first plans, \\`create-prototype-plan\\`\n   for prototype-first plans, \\`create-plan-design\\` for design-first plans,\n   \\`create-visual-questions\\` only when the user explicitly asks for a visual\n   intake questionnaire. When a source plan already exists,\n   pass it as \\`planText\\` and preserve the original plan's useful intent while\n   producing a standalone plan document, not a revision memo.\n3. For UI/product plans, compose the top canvas first with the primary\n   wireframes and annotated states, then write the document with native blocks\n   (see \\`references/canvas.md\\` and \\`references/document-quality.md\\`). For\n   broad product architecture plans with a user-facing implication, add a\n   concrete \"what this looks like in the app\" visual before the abstract\n   architecture or mode tables. Keep the document close to the standalone\n   Markdown plan the agent would normally output. If an existing plan was\n   provided, carry forward the right facts and decisions without referring to\n   the previous draft or explaining how this version differs. For non-visual\n   plans, skip the top visual surface (Visual Surface Choice below owns the rule)\n   and put \\`diagram\\`, \\`data-model\\`,\n   \\`api-endpoint\\`, \\`diff\\`, \\`file-tree\\`, \\`code\\`, and \\`annotated-code\\` blocks\n   directly next to the relevant prose.\n   Wide document layout is renderer-owned and intentionally allowlisted: only\n   literal code-review surfaces (\\`diff\\`, \\`annotated-code\\`) and \\`tabs\\` blocks\n   with vertical orientation or diff-like children break out wider than prose.\n   Keep \\`api-endpoint\\`, \\`openapi-spec\\`, \\`data-model\\`, \\`json-explorer\\`,\n   \\`wireframe\\`, question, and \\`custom-html\\` blocks in normal document flow unless\n   their own renderer says otherwise.\n4. Surface the returned Plans link or inline MCP App and ask the user to review.\n   Always include the actual URL in chat so the next step is a click in CLI or\n   other text-only hosts. When the host exposes an embedded browser/preview panel\n   and a tool can open arbitrary URLs there, open the returned plan URL\n   automatically for convenient review — a convenience and smoke test, never the\n   only handoff or the access\n   model. Plans should load out of the box for the local agent and local browser\n   session; if a signed-in embedded browser cannot read a local plan that an\n   anonymous/tool check can read, fix the app/action ownership or access path\n   rather than patching one plan by hand. For high-stakes plans (architecture,\n   backend, data, multi-file, or risky), also kick off the self-review pass in\n   **Self-Review Before Handoff** while the user reads, instead of blocking the\n   handoff on it.\n5. For hosted plans, call \\`get-plan-feedback\\` before editing, after review,\n   after any long pause,\n   and before the final response. Treat \\`anchorDetails\\`, resolver intent, recent\n   review events, and any focused screenshots from browser handoff as the source\n   of truth for exactly what changed and exactly what each comment points at.\n6. For hosted plans, apply changes with \\`update-visual-plan\\`, preferring\n   targeted \\`contentPatches\\`.\n   Treat the top-level \\`content\\` payload as a full replacement, not a merge; do\n   not send a partial \\`content\\` object to add a canvas or one block. If a full\n   replacement or \\`replace-blocks\\` is unavoidable, call \\`get-visual-plan\\`\n   immediately before the write, pass its \\`plan.updatedAt\\` as\n   \\`expectedUpdatedAt\\`, and carry forward every existing block and visual\n   surface. Never reuse a revision from an earlier read or feedback payload.\n   For source-control friendly edits, use granular \\`patch-visual-plan-source\\`\n   operations against the MDX files instead of regenerating the plan;\n   \\`replace-file\\` is also destructive and requires the same fresh\n   \\`expectedUpdatedAt\\` fence.\n7. After every hosted-plan write, call \\`get-visual-plan\\` again and compare the\n   persisted text, block IDs/counts, canvas frames, and prototype with the\n   intended result. A successful mutation response is not proof that unrelated\n   content survived. If the edit addressed agent-targeted feedback, only after\n   this verification call \\`resolve-plan-comment\\` for the thread and\n   \\`consume-plan-feedback\\` for its comments; do both so addressed feedback is\n   neither visibly open nor returned as pending work.\n8. For hosted plans, export with \\`export-visual-plan\\` only when the user wants a\n   shareable receipt or repo-check-in artifacts.\n\n## Self-Review Before Handoff\n\nThis adversarial self-review pass is opt-in, not default: run it only for\nhigh-stakes plans — irreversible migrations, security-sensitive work, or when\nthe user explicitly asks for extra rigor — and skip it otherwise. It roughly\ndoubles the cost of plan generation, so the default for small, UI-only,\nsingle-decision, or ordinary plans is to skip it, not to run it. Keep the pass\ncheap and non-blocking when it does run:\n\n- **Surface the plan first, review concurrently.** Post the link and let the user\n  start reading, then run the review in parallel — never make the user wait on it.\n- **Review the written plan; do not re-research.** Critique the plan text and its\n  own blocks. The grounding was already done while drafting, so the review checks\n  the output instead of re-exploring the repo.\n- **Spawn one skeptical reviewer** whose only job is to find what is weak, missing,\n  or wrong — not to praise. Point it at: hard-to-reverse decisions made implicitly\n  or not at all (wire format, public ids, data-model shape, auth, ownership); steps\n  not anchored in real files or symbols; a menu of options where the plan should\n  commit to one; obvious missing decisions (\"what happens when X?\", \"why not Y?\");\n  and padding or single-step filler.\n- **Fix vs. ask.** Apply clear-cut fixes yourself with \\`update-visual-plan\\`\n  \\`contentPatches\\` — vague non-goals, unanchored claims, an obvious missing\n  decision. Route genuine judgment calls back to the user instead: add them to the\n  bottom \\`question-form\\` Open Questions block or batch them into the normal\n  ask-user-question flow. Do not silently decide them.\n- **Do not surprise the user mid-read.** On a large plan, apply the patches before\n  the editor loads; otherwise note briefly that a self-review is running so the\n  plan changing under them is expected. When you next respond, summarize what the\n  review changed and what it surfaced for the user to decide.\n\n## Visual Surface Choice\n\nChoose the surface before creating the plan or after reading the source plan. Do\nnot add visual chrome by default:\n\nFor UI/product plans, the top canvas is usually the primary review surface. Put\nthe first meaningful wireframes there, not buried as document-body blocks. Use\nmultiple canvas artboards when states matter, such as the default view, an\noverflow menu or popover, a side panel, loading, or error. Put short annotations\nbeside frames with \\`targetId\\` plus \\`placement\\`; keep implementation details,\ntradeoffs, file maps, data contracts, risks, and verification in the document\nbody below the canvas.\n\nWhen the user asks for a flow, storyboard, journey, wireframe, canvas, or \"what\nthis looks like\", treat that as a canvas-first request. Make one artboard per\nuser-visible state, connect only adjacent transitions, and use short canvas\nannotations for the product notes. Do not substitute a document-body \\`diagram\\`\nblock for the requested storyboard just because HTML diagrams are faster to\nwrite; diagrams belong below the canvas for backend mechanics, architecture, or\ndata-flow explanation.\n\nKeep product wireframes and explanatory/meta diagrams separate. Start with pure\nscreens that look like the app state under discussion, without callout prose or\narchitecture notes embedded inside the UI. Put arrows, labels, contracts, data\nflow, and mode explanations in separate annotations, separate canvas diagrams,\nor the document body.\n\nWhen the plan touches an existing app, inspect the current shell/components\nbefore drawing. The first artboard should look like the real app at the same\ndensity: existing sidebars, toolbar placement, overflow menus, app chrome, and\nframework agent chrome stay in their real places. Model secondary surfaces as\nseparate states, such as a top-right overflow popover, sheet, panel, loading\nstate, or separate AgentSidebar, rather than inventing a permanent inspector or\nfolding framework chrome into the product UI.\n\n- **No visual surface** for architecture-only, backend-only, data migration,\n  copy-only, or otherwise non-visual plans. Do not use the top canvas for\n  architecture diagrams, dependency maps, file plans, API contracts, or\n  data-flow-only reviews. Use a strong document with local inline diagrams\n  only when relationships need a visual explanation, usually one spatial diagram\n  per recommendation or decision. Prefer grouped regions, layers, quadrants,\n  matrices, or before/after panels over a single-axis chain unless the\n  relationship is truly sequential.\n- **Canvas only** for one static screen, a before/after comparison, a component\n  state, a small popover, or a visual direction that does not require clicking.\n  Put those wireframes in \\`content.canvas\\` and omit \\`content.prototype\\`.\n- **Canvas + prototype** for multi-step UI flows, onboarding, wizards,\n  review/approval flows, navigation changes, or anything where the reviewer\n  needs to operate the behavior. Keep the static wireframes in\n  \\`content.canvas\\`, add the aligned functional prototype in\n  \\`content.prototype\\`, and rely on the top visual tabs to switch between them.\n  When both surfaces are present, open the Wireframes tab by default; the\n  prototype remains available as the interactive follow-up view.\n- **Prototype-first** when the user asks to operate the UI or when interaction is\n  the main question. Use \\`create-prototype-plan\\`, which still preserves static\n  mocks where useful.\n\nFor mixed canvas + prototype plans, reuse the same real labels, app statuses,\nand screen ids across both surfaces. The canvas is the inspectable static reference;\nthe prototype is the interactive version of that same flow, not a separate\ndesign direction.\n\nTreat “higher fidelity,” “pixel-accurate,” “polished mockup,” “production-like,”\n“real design,” and “not a sketch/wireframe” as design-first language even when\nthe request also says “mockup.” For a new plan, use \\`create-plan-design\\`. For\nan existing plan, keep the same plan id and call \\`update-visual-plan\\` with a\n\\`set-visual-render-mode\\` patch using \\`renderMode: \"design\"\\` plus the upgraded\nscreen HTML/CSS in the same update. Ground the result in the real app shell,\ntokens, typography, spacing, and states, and add stable \\`data-design-id\\`\ntargets. Put scoped styles in each screen's \\`css\\` field, never in a \\`<style>\\`\ntag. The viewer-local Clean toggle only changes one browser's wireframe\npreference; it is not a fidelity upgrade. Do not create a duplicate plan to\nhandle a fidelity follow-up.\n\n## Wireframe quality — read \\`references/wireframe.md\\`\n\nUI recap/plan wireframes must meet a strict quality bar — full-width chrome,\npinned bottom bars, real product content, before/after comparability, the right\n\\`surface\\` preset, \\`--wf-*\\` tokens instead of hex, and no \\`<html>\\`/\\`<style>\\`/font\ntags. Before authoring ANY wireframe / \\`<Screen>\\` / \\`WireframeBlock\\`, READ\n\\`references/wireframe.md\\` in this skill directory — it is the single source of\ntruth for HTML wireframe quality, shared word for word with \\`/visual-plan\\`\nand \\`/visual-recap\\`. Do not author wireframes from memory.\n\n## Canvas — read \\`references/canvas.md\\`\n\nThe 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 — it is the single source of truth\nfor canvas/artboard mechanics. Do not author canvas layouts from memory.\nCanvas artboards use the same HTML wireframe path as document-body\n\\`WireframeBlock\\` screens: author \\`<Screen surface=\"...\" html={...} />\\` with a\nsemantic HTML fragment. Do not author fresh kit-tree children such as\n\\`<FrameScreen>\\`, \\`<Card>\\`, \\`<Row>\\`, or \\`<Btn>\\` inside canvas \\`<Screen>\\` tags;\nthose are legacy compatibility markup for old plans and produce brittle canvas\nlayouts.\n\n## Document quality — read \\`references/document-quality.md\\`\n\nThe document is a serious technical plan, not marketing: outcome-first,\nprose-first, self-contained, built from the right native blocks, with open\nquestions in a single bottom \\`question-form\\` and a pre-handoff visual check.\nBefore authoring the plan document, READ \\`references/document-quality.md\\` in this\nskill directory — it is the single source of truth for the document quality bar.\nDo not write the document from memory.\n\n## Good vs. bad exemplar — read \\`references/exemplar.md\\`\n\nFor a worked example of the bar — a great UI-first plan and \\`/visual-plan\\`, plus\nthe anti-patterns to avoid — READ \\`references/exemplar.md\\` in this skill\ndirectory before authoring a plan.\n\n## Tool Guidance\n\n- \\`create-visual-plan\\`: start one structured visual plan per agent task/run, or\n  import an existing text plan by passing \\`planText\\`; \\`content\\` may include no\n  visual surface, canvas only, or canvas + prototype.\n- \\`create-ui-plan\\`: start a UI-first plan when the work is primarily product UI.\n- \\`create-prototype-plan\\`: start a prototype-first plan with a functional top\n  review surface. If the interaction itself must also be high fidelity, set each\n  screen's \\`renderMode\\` to \\`design\\` and pass scoped styles through \\`css\\`;\n  otherwise use \\`create-plan-design\\` for design-first review.\n- \\`create-plan-design\\`: start a full-fidelity branded Design-tab plan with an\n  optional matching Prototype tab.\n- \\`convert-visual-plan-to-prototype\\`: convert an existing HTML wireframe canvas\n  into a prototype plan.\n- \\`create-visual-questions\\`: use only when the user explicitly asks for a visual\n  intake questionnaire, not as \\`/visual-plan\\` preflight.\n- \\`update-visual-plan\\`: revise content, status, or comments with targeted\n  \\`contentPatches\\` (see Core Workflow steps 6-7). Use\n  \\`set-visual-render-mode\\` with \\`renderMode: \"design\"\\` when promoting an\n  existing plan to high fidelity, together with deliberate screen HTML/CSS;\n  render mode alone only removes sketch treatment. \\`replace-blocks\\` and full\n  \\`content\\` replacement require \\`expectedUpdatedAt\\` from a fresh\n  \\`get-visual-plan\\` call.\n- \\`read-visual-plan-source\\`: read the normalized plan as \\`plan.mdx\\`,\n  optional \\`canvas.mdx\\`, optional \\`.plan-state.json\\`, and JSON.\n- \\`patch-visual-plan-source\\`: apply granular MDX AST patches by stable block,\n  artboard, annotation, component, or wireframe-node id. Prefer those targeted\n  operations; \\`replace-file\\` requires \\`expectedUpdatedAt\\` from a fresh\n  \\`get-visual-plan\\` call.\n- \\`import-visual-plan-source\\`: create or replace a plan from an MDX folder.\n- \\`get-visual-plan\\`: read the current structured plan, exported HTML,\n  annotations, and \\`plan.updatedAt\\`; it also returns the MDX folder for source\n  workflows. Re-read immediately before a destructive write for its concurrency\n  fence and again after every write to verify persisted state.\n- \\`get-plan-feedback\\`: read unconsumed human feedback. Use it frequently; it\n  returns grouped threads, exact anchor details, expected resolver, and recent\n  review-event payloads so agents can act only on the comments meant for them.\n- \\`get-plan-blocks\\`: resolve block tags before authoring — do not memorize tags;\n  call this first to get the authoritative tag names, required fields, and prop\n  shapes from the live block registry.\n- \\`export-visual-plan\\`: export HTML, Markdown fallback, structured JSON, and MDX\n  files for repo check-in.\n\nWhen the user critiques a plan's look or structure, fix the renderer or this\nskill — never hand-edit one stored plan. Turn feedback into better guidance.\n\n## Local-Files Privacy Mode — read \\`references/local-files.md\\`\n\nWhen the user wants no hosted Plan database writes — no DB writes, no Plan MCP\npublish, fully local/offline/private planning, repo-owned source-controlled\nartifacts, or \\`AGENT_NATIVE_PLANS_MODE=local-files\\` — do not call any hosted Plan\ntool except the schema-only \\`get-plan-blocks\\` catalog lookup. Author a local MDX\nfolder and\npreview it with \\`plan local check\\` / \\`plan local serve\\` / \\`plan local verify\\`.\nBefore using local-files mode, READ \\`references/local-files.md\\` in this skill\ndirectory — it is the single source of truth for the full contract (catalog\nlookup, MDX folder layout, the local bridge commands, and the hosted tools you\nmust not call). Carry forward only the code-research and plan-composition\nguidance from Core Workflow; everything hosted is replaced by the local bridge.\n\n## Interpreting comment anchors\n\nThis section applies to hosted plans with \\`get-plan-feedback\\` /\n\\`update-visual-plan\\`. In local-files mode, do not call hosted feedback or update\ntools; interpret file/chat feedback directly, edit the MDX files, rerun the\nlocal bridge check/serve/verify command, and report the new local URL.\n\n\\`get-plan-feedback\\` returns rich anchors — read them before acting on any comment.\n\n- **Coordinate frames.** \\`targetX\\`/\\`targetY\\` are percentages *within* the\n  element named by \\`targetSelector\\`/\\`targetKind\\`. Bare \\`x\\`/\\`y\\` are percentages\n  of the whole plan document. \\`canvasX\\`/\\`canvasY\\` are raw board-world pixels on\n  the design canvas (board size given when available).\n- **Wireframe pins.** Anchors on wireframes include \\`targetNodeId\\` and\n  \\`targetNodePath\\` (e.g. \\`card > list > listItem \"Acme Inc\"\\`) identifying the\n  exact kit node. Use \\`targetNodeId\\` directly with wireframe node patch ops;\n  use \\`data-design-id\\` values from design artboards with\n  \\`update-design-element-style\\`. Prefer the node id/path over raw coordinates;\n  fall back to coordinates plus the focused screenshot (red ring marks the exact\n  point) only when no node id is present.\n- **Text quotes.** Resolve \\`textQuote\\` against current prose using\n  \\`contextBefore\\`/\\`contextAfter\\` for disambiguation. If \\`ambiguous: true\\`, ask\n  the user — do not guess which occurrence is meant.\n- **Detached comments.** \\`get-plan-feedback\\` flags threads whose quoted text no\n  longer exists as \\`detached\\` (in \\`detachedThreads\\`). Reconcile these against\n  rewritten content — never silently drop them.\n- **Routing.** \\`resolutionTarget\\` is the only routing signal: act on \\`agent\\`,\n  treat \\`human\\` as context only. \\`@mentions\\` are people to notify, never a\n  routing signal.\n- **Two-axis state.** Mark every ingested comment as consumed\n  (\\`consumedCommentIds\\` on \\`update-visual-plan\\`). Set \\`status=resolved\\` only on\n  agent-targeted comments you actually addressed; leave human-targeted comments\n  open. When an edit addresses feedback, first re-read the persisted plan and\n  verify the requested change. Only then call \\`resolve-plan-comment\\` for the\n  addressed thread and \\`consume-plan-feedback\\` for its comments; never mark\n  addressed feedback along only one axis.\n\n## Visibility & Sharing\n\nUse \\`set-resource-visibility\\` to change who can see a plan (e.g. public, login,\nor org-scoped). Use \\`share-resource\\` to grant specific users or roles access\nby email or role. Gate visibility before sharing any plan that covers\nunreleased or private work — default to the narrowest scope that meets the\nreview need.\n\n## Setup & Authentication\n\nThere are two ways into Plans.\n\n**Coding agent (CLI).** Install once with the Agent-Native CLI. The command\ninstalls the Plans skills, registers the hosted Plans MCP connector, and runs\nauth/setup for the selected local client(s) in the same step (a one-time browser\nsign-in at setup — this is intended), so the first tool call in that client does\nnot hit an OAuth wall:\n\n\\`\\`\\`bash\nnpx @agent-native/core@latest skills add visual-plans\n\\`\\`\\`\n\nAfter that, \\`/visual-plan\\`, \\`/visual-recap\\`, and \\`/visualize-repo\\` are the\ninstalled slash commands. If you only need one command, use\n\\`skills add visual-plan\\`, \\`skills add visual-recap\\`, or\n\\`skills add visualize-repo\\` instead. The other planning modes\n(\\`create-ui-plan\\`, \\`create-prototype-plan\\`, \\`create-plan-design\\`,\n\\`create-visual-questions\\`) are MCP tools reachable from \\`/visual-plan\\`, not\nseparate slash commands. Pass \\`--no-connect\\` to register the connector without\nauthenticating, then run\n\\`npx @agent-native/core@latest connect https://plan.agent-native.com --client all\\`\nwhenever you are ready, or choose a narrower \\`--client\\`. Auth and MCP tool\nloading are per client config/session.\n\n**Browser (people you share with).** Open the Plans editor and create & edit\nwith no sign-up — you work as a guest. Sign in only when you want to save or\nshare; signing in claims the plans you made as a guest into your account.\n\nSharing and commenting require an account: public/shared plans are viewable by\nanyone with the link, but commenting on them needs an agent-native account.\n\nFor fully offline, no-account use, run the Plans app locally and sync plans to\nyour repo as MDX. This local mode is a separate advanced path, not the default\nhosted flow.\n\nFor repo-wide visual docs, run\n\\`npx @agent-native/core@latest visualize-repo --open\\` to create/update\n\\`agent-native.json\\`, seed \\`.agent-native/visual-docs/repo-overview\\`, and open\nthe local bridge.\n\nIf a Plans tool returns \\`needs auth\\`, \\`Unauthorized\\`, or \\`Session terminated\\`, do\nnot keep retrying it — stop and give the user the per-client reconnect step from\n\\`references/connection.md\\`, then continue once the connector is available.\n\nHosted default: connect \\`https://plan.agent-native.com/mcp\\`. Do\nnot put shared secrets in skill files.\n`;\n"]}

package/dist/client/blocks/library/wireframe.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"wireframe.d.ts","sourceRoot":"","sources":["../../../../src/client/blocks/library/wireframe.tsx"],"names":[],"mappings":"AAYA,OAAO,KAAK,EACV,cAAc,EACd,cAAc,EAEf,MAAM,aAAa,CAAC;AAkBrB,OAAO,EAGL,KAAK,aAAa,EAEnB,MAAM,uBAAuB,CAAC;AA+b/B,kDAAkD;AAClD,wBAAgB,cAAc,CAAC,EAC7B,IAAI,EACJ,OAAO,EACP,KAAK,EACL,OAAO,EACP,GAAG,EACH,cAAc,GACf,EAAE,cAAc,CAAC,aAAa,CAAC,+BAY/B;AAED;;;;;;GAMG;AACH,wBAAgB,eAAe,CAAC,EAAE,IAAI,EAAE,GAAG,EAAE,EAAE,cAAc,CAAC,aAAa,CAAC,+BAE3E;AAED,oFAAoF;AACpF,eAAO,MAAM,cAAc,gDAczB,CAAC"}
+{"version":3,"file":"wireframe.d.ts","sourceRoot":"","sources":["../../../../src/client/blocks/library/wireframe.tsx"],"names":[],"mappings":"AAYA,OAAO,KAAK,EACV,cAAc,EACd,cAAc,EAEf,MAAM,aAAa,CAAC;AAkBrB,OAAO,EAGL,KAAK,aAAa,EAEnB,MAAM,uBAAuB,CAAC;AAic/B,kDAAkD;AAClD,wBAAgB,cAAc,CAAC,EAC7B,IAAI,EACJ,OAAO,EACP,KAAK,EACL,OAAO,EACP,GAAG,EACH,cAAc,GACf,EAAE,cAAc,CAAC,aAAa,CAAC,+BAY/B;AAED;;;;;;GAMG;AACH,wBAAgB,eAAe,CAAC,EAAE,IAAI,EAAE,GAAG,EAAE,EAAE,cAAc,CAAC,aAAa,CAAC,+BAE3E;AAED,oFAAoF;AACpF,eAAO,MAAM,cAAc,gDAczB,CAAC"}

package/dist/client/blocks/library/wireframe.js

@@ -31,7 +31,7 @@ function ArtboardFrame({ surface, compact, canvasSize, canvasWidth, skeleton, re
     const fitRef = useRef(null);
     const isDark = useIsDark();
     const theme = isDark ? "dark" : "light";
-    const style = useWireframeStyle();
+    const preferredStyle = useWireframeStyle();
     const preset = SURFACE_PRESETS[surface] ?? SURFACE_PRESETS.desktop;
     const width = canvasWidth ?? preset.width;
     // AUTO-HEIGHT: with no explicit `canvasSize` the artboard height is driven by
@@ -51,6 +51,7 @@ function ArtboardFrame({ surface, compact, canvasSize, canvasWidth, skeleton, re
     // with auto-height we measure it.
     const [measuredHeight, setMeasuredHeight] = useState(fixedHeight ?? null);
     const designMode = renderMode === "design";
+    const style = designMode ? "clean" : preferredStyle;
     const sketchy = !designMode && style === "sketchy" && !skeleton;
     const roughEnabled = sketchy && roughOverlay;
     const frameBorder = skeleton
@@ -164,7 +165,7 @@ function HtmlArtboard({ data, ctx: _ctx, showFrame, compact, }) {
 /* Kit artboard — declarative kit tree.                                       */
 /* -------------------------------------------------------------------------- */
 function KitArtboard({ data, showFrame, compact, }) {
-    return (_jsx(ArtboardFrame, { surface: data.surface, compact: compact, skeleton: data.skeleton, showFrame: showFrame, selector: "[data-rough]", caption: data.caption, render: ({ theme, style }) => (_jsx(KitConfigContext.Provider, { value: {
+    return (_jsx(ArtboardFrame, { surface: data.surface, compact: compact, skeleton: data.skeleton, renderMode: data.renderMode, showFrame: showFrame, selector: "[data-rough]", caption: data.caption, render: ({ theme, style }) => (_jsx(KitConfigContext.Provider, { value: {
                 skeleton: data.skeleton,
                 flushFrame: !showFrame,
                 theme,

package/dist/client/blocks/library/wireframe.js.map

@@ -1 +1 @@
-{"version":3,"file":"wireframe.js","sourceRoot":"","sources":["../../../../src/client/blocks/library/wireframe.tsx"],"names":[],"mappings":";AAAA,OAAO,EAAE,UAAU,EAAE,MAAM,qBAAqB,CAAC;AACjD,OAAO,EACL,SAAS,EACT,KAAK,EACL,OAAO,EACP,MAAM,EACN,QAAQ,GAET,MAAM,OAAO,CAAC;AAEf,OAAO,EAAE,iBAAiB,EAAE,MAAM,4BAA4B,CAAC;AAC/D,OAAO,EAAE,WAAW,EAAE,MAAM,aAAa,CAAC;AAM1C,OAAO,EAAE,YAAY,EAAE,MAAM,iBAAiB,CAAC;AAC/C,OAAO,EACL,oBAAoB,EACpB,qBAAqB,EACrB,cAAc,GACf,MAAM,oBAAoB,CAAC;AAC5B,OAAO,EAAE,uBAAuB,EAAE,MAAM,sBAAsB,CAAC;AAC/D,OAAO,EACL,mBAAmB,EACnB,gBAAgB,EAChB,YAAY,EACZ,MAAM,EACN,WAAW,EACX,oBAAoB,EACpB,SAAS,EACT,iBAAiB,GAClB,MAAM,oBAAoB,CAAC;AAC5B,OAAO,EACL,eAAe,EACf,YAAY,GAGb,MAAM,uBAAuB,CAAC;AA+C/B,MAAM,eAAe,GAA4C;IAC/D,6EAA6E;IAC7E,MAAM,EAAE,EAAE,KAAK,EAAE,GAAG,EAAE,SAAS,EAAE,GAAG,EAAE,MAAM,EAAE,EAAE,EAAE;IAClD,OAAO,EAAE,EAAE,KAAK,EAAE,GAAG,EAAE,SAAS,EAAE,GAAG,EAAE,MAAM,EAAE,EAAE,EAAE;IACnD,OAAO,EAAE,EAAE,KAAK,EAAE,GAAG,EAAE,SAAS,EAAE,GAAG,EAAE,MAAM,EAAE,EAAE,EAAE;IACnD,OAAO,EAAE,EAAE,KAAK,EAAE,GAAG,EAAE,SAAS,EAAE,GAAG,EAAE,MAAM,EAAE,EAAE,EAAE;IACnD,KAAK,EAAE,EAAE,KAAK,EAAE,GAAG,EAAE,SAAS,EAAE,GAAG,EAAE,MAAM,EAAE,EAAE,EAAE;CAClD,CAAC;AAEF,SAAS,UAAU,CAAC,IAAmB;IACrC,OAAO,OAAO,IAAI,CAAC,IAAI,KAAK,QAAQ,IAAI,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE,CAAC,MAAM,GAAG,CAAC,CAAC;AACtE,CAAC;AAED,gFAAgF;AAChF,iFAAiF;AACjF,iFAAiF;AACjF,iFAAiF;AACjF,iFAAiF;AACjF,iFAAiF;AACjF,gFAAgF;AAEhF,SAAS,aAAa,CAAC,EACrB,OAAO,EACP,OAAO,EACP,UAAU,EACV,WAAW,EACX,QAAQ,EACR,UAAU,EACV,YAAY,GAAG,IAAI,EACnB,SAAS,GAAG,IAAI,EAChB,QAAQ,EACR,OAAO,EACP,MAAM,GAqBP;IACC,MAAM,GAAG,GAAG,MAAM,CAAiB,IAAI,CAAC,CAAC;IACzC,MAAM,MAAM,GAAG,MAAM,CAAiB,IAAI,CAAC,CAAC;IAC5C,MAAM,MAAM,GAAG,SAAS,EAAE,CAAC;IAC3B,MAAM,KAAK,GAAqB,MAAM,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,OAAO,CAAC;IAC1D,MAAM,KAAK,GAAG,iBAAiB,EAAE,CAAC;IAClC,MAAM,MAAM,GAAG,eAAe,CAAC,OAAO,CAAC,IAAI,eAAe,CAAC,OAAO,CAAC;IACnE,MAAM,KAAK,GAAG,WAAW,IAAI,MAAM,CAAC,KAAK,CAAC;IAC1C,8EAA8E;IAC9E,gFAAgF;IAChF,2EAA2E;IAC3E,2EAA2E;IAC3E,+EAA+E;IAC/E,iCAAiC;IACjC,MAAM,WAAW,GAAG,UAAU,CAAC;IAC/B,MAAM,SAAS,GAAG,WAAW,IAAI,MAAM,CAAC,SAAS,CAAC;IAClD,MAAM,SAAS,GAAG,OAAO,CAAC,CAAC,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,EAAE,GAAG,GAAG,MAAM,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC;IAChE,MAAM,aAAa,GAAG,OAAO,CAAC,CAAC,CAAC,MAAM,CAAC,KAAK,GAAG,SAAS,CAAC,CAAC,CAAC,KAAK,CAAC;IACjE,MAAM,CAAC,QAAQ,EAAE,WAAW,CAAC,GAAG,QAAQ,CAAC,SAAS,CAAC,CAAC;IACpD,4EAA4E;IAC5E,yEAAyE;IACzE,gFAAgF;IAChF,kCAAkC;IAClC,MAAM,CAAC,cAAc,EAAE,iBAAiB,CAAC,GAAG,QAAQ,CAClD,WAAW,IAAI,IAAI,CACpB,CAAC;IACF,MAAM,UAAU,GAAG,UAAU,KAAK,QAAQ,CAAC;IAC3C,MAAM,OAAO,GAAG,CAAC,UAAU,IAAI,KAAK,KAAK,SAAS,IAAI,CAAC,QAAQ,CAAC;IAChE,MAAM,YAAY,GAAG,OAAO,IAAI,YAAY,CAAC;IAC7C,MAAM,WAAW,GAAG,QAAQ;QAC1B,CAAC,CAAC,oEAAoE;QACtE,CAAC,CAAC,sCAAsC,CAAC;IAE3C,SAAS,CAAC,GAAG,EAAE;QACb,MAAM,OAAO,GAAG,MAAM,CAAC,OAAO,CAAC;QAC/B,IAAI,CAAC,OAAO;YAAE,OAAO;QACrB,MAAM,OAAO,GAAG,GAAG,EAAE;YACnB,MAAM,cAAc,GAAG,OAAO,CAAC,WAAW,CAAC;YAC3C,MAAM,SAAS,GACb,cAAc,GAAG,CAAC;gBAChB,CAAC,CAAC,IAAI,CAAC,GAAG,CAAC,SAAS,EAAE,cAAc,GAAG,KAAK,CAAC;gBAC7C,CAAC,CAAC,SAAS,CAAC;YAChB,WAAW,CAAC,CAAC,OAAO,EAAE,EAAE,CACtB,IAAI,CAAC,GAAG,CAAC,OAAO,GAAG,SAAS,CAAC,GAAG,KAAK,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,SAAS,CAC5D,CAAC;QACJ,CAAC,CAAC;QACF,OAAO,EAAE,CAAC;QACV,MAAM,QAAQ,GAAG,IAAI,cAAc,CAAC,OAAO,CAAC,CAAC;QAC7C,QAAQ,CAAC,OAAO,CAAC,OAAO,CAAC,CAAC;QAC1B,OAAO,GAAG,EAAE,CAAC,QAAQ,CAAC,UAAU,EAAE,CAAC;IACrC,CAAC,EAAE,CAAC,SAAS,EAAE,KAAK,CAAC,CAAC,CAAC;IAEvB,2EAA2E;IAC3E,+EAA+E;IAC/E,yDAAyD;IACzD,SAAS,CAAC,GAAG,EAAE;QACb,IAAI,WAAW,IAAI,IAAI;YAAE,OAAO;QAChC,MAAM,OAAO,GAAG,GAAG,CAAC,OAAO,CAAC;QAC5B,IAAI,CAAC,OAAO;YAAE,OAAO;QACrB,MAAM,OAAO,GAAG,GAAG,EAAE;YACnB,MAAM,IAAI,GAAG,OAAO,CAAC,YAAY,CAAC;YAClC,iBAAiB,CAAC,CAAC,OAAO,EAAE,EAAE,CAC5B,OAAO,IAAI,IAAI,IAAI,IAAI,CAAC,GAAG,CAAC,OAAO,GAAG,IAAI,CAAC,GAAG,GAAG,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,IAAI,CACnE,CAAC;QACJ,CAAC,CAAC;QACF,OAAO,EAAE,CAAC;QACV,MAAM,QAAQ,GAAG,IAAI,cAAc,CAAC,OAAO,CAAC,CAAC;QAC7C,QAAQ,CAAC,OAAO,CAAC,OAAO,CAAC,CAAC;QAC1B,OAAO,GAAG,EAAE,CAAC,QAAQ,CAAC,UAAU,EAAE,CAAC;IACrC,CAAC,EAAE,CAAC,WAAW,CAAC,CAAC,CAAC;IAElB,8EAA8E;IAC9E,8EAA8E;IAC9E,uEAAuE;IACvE,MAAM,cAAc,GAAG,CAAC,cAAc,IAAI,SAAS,CAAC,GAAG,QAAQ,CAAC;IAChE,MAAM,mBAAmB,GAAG,WAAW,IAAI,IAAI,IAAI,QAAQ,KAAK,CAAC,CAAC;IAElE,OAAO,CACL,eACE,GAAG,EAAE,MAAM,EACX,SAAS,EAAC,oBAAoB,EAC9B,KAAK,EAAE;YACL,KAAK,EAAE,MAAM;YACb,QAAQ,EAAE,aAAa;SACxB,aAED,eACE,SAAS,EAAC,mCAAmC,EAC7C,KAAK,EAAE;oBACL,KAAK,EAAE,MAAM;oBACb,QAAQ,EAAE,aAAa;oBACvB,GAAG,CAAC,mBAAmB,CAAC,CAAC,CAAC,EAAE,MAAM,EAAE,cAAc,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;oBAC1D,YAAY,EAAE,MAAM;iBACrB,aAED,eACE,GAAG,EAAE,GAAG,EACR,SAAS,EAAC,4BAA4B,sBACrB,WAAW,gBAChB,SAAS,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,MAAM,EACvC,KAAK,EAAE;4BACL,KAAK;4BACL,mEAAmE;4BACnE,8DAA8D;4BAC9D,GAAG,CAAC,WAAW,IAAI,IAAI,CAAC,CAAC,CAAC,EAAE,MAAM,EAAE,WAAW,EAAE,CAAC,CAAC,CAAC,EAAE,SAAS,EAAE,CAAC;4BAClE,YAAY,EAAE,MAAM,CAAC,MAAM;4BAC3B,GAAG,CAAC,QAAQ,KAAK,CAAC;gCAChB,CAAC,CAAC;oCACE,SAAS,EAAE,SAAS,QAAQ,GAAG;oCAC/B,eAAe,EAAE,UAAU;iCAC5B;gCACH,CAAC,CAAC,EAAE,CAAC;yBACR,aAKD,cACE,SAAS,EAAC,iBAAiB,EAC3B,KAAK,EAAE;oCACL,YAAY,EAAE,MAAM,CAAC,MAAM;oCAC3B,GAAG,CAAC,WAAW,IAAI,IAAI;wCACrB,CAAC,CAAC,EAAE,QAAQ,EAAE,UAAU,EAAE,KAAK,EAAE,CAAC,EAAE;wCACpC,CAAC,CAAC,EAAE,SAAS,EAAE,CAAC;iCACnB,YAEA,MAAM,CAAC,EAAE,KAAK,EAAE,KAAK,EAAE,CAAC,GACrB,EACL,CAAC,YAAY,IAAI,SAAS,IAAI,CAC7B,cACE,SAAS,EAAC,sCAAsC,EAChD,KAAK,EAAE;oCACL,YAAY,EAAE,MAAM,CAAC,MAAM;oCAC3B,MAAM,EAAE,eAAe,WAAW,EAAE;iCACrC,GACD,CACH,EACD,KAAC,YAAY,IACX,QAAQ,EAAE,GAAG,EACb,OAAO,EAAE,YAAY,EACrB,SAAS,EAAE,SAAS,EACpB,WAAW,EAAE,MAAM,CAAC,MAAM,EAC1B,QAAQ,EAAE,QAAQ,GAClB,IACE,EACL,CAAC,UAAU,IAAI,CAAC,QAAQ,IAAI,KAAC,0BAA0B,KAAG,IACvD,EACL,OAAO,IAAI,CACV,YAAG,SAAS,EAAC,0CAA0C,YAAE,OAAO,GAAK,CACtE,IACG,CACP,CAAC;AACJ,CAAC;AAED,SAAS,0BAA0B;IACjC,MAAM,KAAK,GAAG,iBAAiB,EAAE,CAAC;IAClC,MAAM,IAAI,GAAG,YAAY,EAAE,CAAC;IAC5B,MAAM,SAAS,GAAG,KAAK,KAAK,SAAS,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,SAAS,CAAC;IAC5D,MAAM,KAAK,GAAG,SAAS,KAAK,OAAO,CAAC,CAAC,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,IAAI,CAAC,OAAO,CAAC;IAChE,MAAM,WAAW,GAAG,IAAI,CAAC,iBAAiB,CAAC,OAAO,CAChD,WAAW,EACX,KAAK,CAAC,iBAAiB,EAAE,CAC1B,CAAC;IAEF,OAAO,CACL,kBACE,IAAI,EAAC,QAAQ,+CAEF,MAAM,qDAEL,WAAW,EACvB,KAAK,EAAE,WAAW,EAClB,OAAO,EAAE,CAAC,KAAK,EAAE,EAAE;YACjB,KAAK,CAAC,eAAe,EAAE,CAAC;YACxB,oBAAoB,EAAE,CAAC;QACzB,CAAC,EACD,SAAS,EAAC,kXAAkX,aAE5X,KAAC,UAAU,IAAC,SAAS,EAAC,UAAU,iBAAa,MAAM,GAAG,EACtD,yBAAO,KAAK,GAAQ,IACb,CACV,CAAC;AACJ,CAAC;AAED,gFAAgF;AAChF,gFAAgF;AAChF,gFAAgF;AAEhF,SAAS,YAAY,CAAC,EACpB,IAAI,EACJ,GAAG,EAAE,IAAI,EACT,SAAS,EACT,OAAO,GAMR;IACC,MAAM,UAAU,GAAG,IAAI,CAAC,UAAU,IAAI,WAAW,CAAC;IAClD,MAAM,UAAU,GAAG,UAAU,KAAK,QAAQ,CAAC;IAC3C,gFAAgF;IAChF,gFAAgF;IAChF,gFAAgF;IAChF,gDAAgD;IAChD,MAAM,QAAQ,GAAG,OAAO,CACtB,GAAG,EAAE,CACH,uBAAuB,CACrB,qBAAqB,CAAC,IAAI,CAAC,IAAI,EAAE;QAC/B,oBAAoB,EAAE,UAAU;KACjC,CAAC,CACH,EACH,CAAC,IAAI,CAAC,IAAI,EAAE,UAAU,CAAC,CACxB,CAAC;IACF,MAAM,OAAO,GAAG,KAAK,EAAE,CAAC,OAAO,CAAC,iBAAiB,EAAE,EAAE,CAAC,CAAC;IACvD,MAAM,SAAS,GAAG,OAAO,CAAC,GAAG,EAAE;QAC7B,MAAM,OAAO,GAAG,oBAAoB,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;QAC/C,uEAAuE;QACvE,0EAA0E;QAC1E,OAAO,OAAO;YACZ,CAAC,CAAC,cAAc,CAAC,OAAO,EAAE,4BAA4B,OAAO,IAAI,CAAC;YAClE,CAAC,CAAC,EAAE,CAAC;IACT,CAAC,EAAE,CAAC,IAAI,CAAC,GAAG,EAAE,OAAO,CAAC,CAAC,CAAC;IAExB,OAAO,CACL,KAAC,aAAa,IACZ,OAAO,EAAE,IAAI,CAAC,OAAO,EACrB,OAAO,EAAE,OAAO,EAChB,QAAQ,EAAE,IAAI,CAAC,QAAQ,EACvB,UAAU,EAAE,UAAU,EACtB,SAAS,EAAE,SAAS,EACpB,QAAQ,EAAE,mBAAmB,EAC7B,OAAO,EAAE,IAAI,CAAC,OAAO,EACrB,MAAM,EAAE,CAAC,EAAE,KAAK,EAAE,KAAK,EAAE,EAAE,EAAE,CAAC,CAC5B,eACE,SAAS,EAAC,iBAAiB,gBACf,KAAK,gBACL,KAAK,gBACL,SAAS,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,MAAM,sBACrB,UAAU,4BACJ,OAAO,mBAChB,IAAI,CAAC,QAAQ,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,SAAS,aAEhD,SAAS,IAAI,0BAAQ,SAAS,GAAS,EACxC,cACE,SAAS,EAAC,yBAAyB,EACnC,uBAAuB,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,GAC7C,IACE,CACP,GACD,CACH,CAAC;AACJ,CAAC;AAED,gFAAgF;AAChF,gFAAgF;AAChF,gFAAgF;AAEhF,SAAS,WAAW,CAAC,EACnB,IAAI,EACJ,SAAS,EACT,OAAO,GAKR;IACC,OAAO,CACL,KAAC,aAAa,IACZ,OAAO,EAAE,IAAI,CAAC,OAAO,EACrB,OAAO,EAAE,OAAO,EAChB,QAAQ,EAAE,IAAI,CAAC,QAAQ,EACvB,SAAS,EAAE,SAAS,EACpB,QAAQ,EAAC,cAAc,EACvB,OAAO,EAAE,IAAI,CAAC,OAAO,EACrB,MAAM,EAAE,CAAC,EAAE,KAAK,EAAE,KAAK,EAAE,EAAE,EAAE,CAAC,CAC5B,KAAC,gBAAgB,CAAC,QAAQ,IACxB,KAAK,EAAE;gBACL,QAAQ,EAAE,IAAI,CAAC,QAAQ;gBACvB,UAAU,EAAE,CAAC,SAAS;gBACtB,KAAK;gBACL,KAAK;aACN,YAEA,eAAe,CAAC,IAAI,CAAC,MAAM,IAAI,EAAE,CAAC,GACT,CAC7B,GACD,CACH,CAAC;AACJ,CAAC;AAED,SAAS,eAAe,CACtB,KAA2C;IAE3C,IAAI,KAAK,CAAC,MAAM,KAAK,CAAC,IAAI,KAAK,CAAC,CAAC,CAAC,EAAE,EAAE,KAAK,QAAQ,EAAE,CAAC;QACpD,OAAO,WAAW,CAAC,KAAK,CAAC,CAAC;IAC5B,CAAC;IACD,gFAAgF;IAChF,6EAA6E;IAC7E,OAAO,CACL,KAAC,MAAM,IAAC,GAAG,EAAC,yBAAyB,EAAC,KAAK,EAAE,EAAE,SAAS,EAAE,MAAM,EAAE,YAC/D,WAAW,CAAC,KAAK,CAAC,GACZ,CACV,CAAC;AACJ,CAAC;AAED;;;;GAIG;AACH,SAAS,oBAAoB,CAAC,EAC5B,IAAI,EACJ,GAAG,EACH,OAAO,GAKR;IACC,MAAM,SAAS,GAAG,kBAAkB,CAAC,IAAI,CAAC,KAAK,EAAE,GAAG,CAAC,CAAC;IACtD,IAAI,UAAU,CAAC,IAAI,CAAC,EAAE,CAAC;QACrB,OAAO,CACL,KAAC,YAAY,IACX,IAAI,EAAE,IAAI,EACV,GAAG,EAAE,GAAG,EACR,SAAS,EAAE,SAAS,EACpB,OAAO,EAAE,OAAO,GAChB,CACH,CAAC;IACJ,CAAC;IACD,OAAO,KAAC,WAAW,IAAC,IAAI,EAAE,IAAI,EAAE,SAAS,EAAE,SAAS,EAAE,OAAO,EAAE,OAAO,GAAI,CAAC;AAC7E,CAAC;AAED,SAAS,kBAAkB,CACzB,KAA6B,EAC7B,GAAuB;IAEvB,MAAM,QAAQ,GACZ,KAAK,IAAI,KAAK,KAAK,MAAM,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,WAAW,IAAI,MAAM,CAAC,CAAC;IAClE,OAAO,QAAQ,KAAK,MAAM,CAAC;AAC7B,CAAC;AAED,gFAAgF;AAChF,gFAAgF;AAChF,gFAAgF;AAEhF,kDAAkD;AAClD,MAAM,UAAU,cAAc,CAAC,EAC7B,IAAI,EACJ,OAAO,EACP,KAAK,EACL,OAAO,EACP,GAAG,EACH,cAAc,GACgB;IAC9B,OAAO,CACL,sBACM,iBAAiB,EACrB,SAAS,EAAC,kCAAkC,mBAC7B,OAAO,aAErB,KAAK,IAAI,cAAK,SAAS,EAAC,iCAAiC,YAAE,KAAK,GAAO,EACxE,KAAC,oBAAoB,IAAC,IAAI,EAAE,IAAI,EAAE,GAAG,EAAE,GAAG,EAAE,OAAO,EAAE,cAAc,GAAI,EACtE,OAAO,IAAI,YAAG,SAAS,EAAC,sBAAsB,YAAE,OAAO,GAAK,IACrD,CACX,CAAC;AACJ,CAAC;AAED;;;;;;GAMG;AACH,MAAM,UAAU,eAAe,CAAC,EAAE,IAAI,EAAE,GAAG,EAAiC;IAC1E,OAAO,KAAC,oBAAoB,IAAC,IAAI,EAAE,IAAI,EAAE,GAAG,EAAE,GAAG,GAAI,CAAC;AACxD,CAAC;AAED,oFAAoF;AACpF,MAAM,CAAC,MAAM,cAAc,GAAG,WAAW,CAAgB;IACvD,IAAI,EAAE,WAAW;IACjB,MAAM,EAAE,eAAe;IACvB,GAAG,EAAE,YAAY;IACjB,IAAI,EAAE,cAAc;IACpB,IAAI,EAAE,eAAe;IACrB,SAAS,EAAE,CAAC,OAAO,CAAC;IACpB,WAAW,EAAE,QAAQ;IACrB,KAAK,EAAE,WAAW;IAClB,WAAW,EACT,4JAA4J;IAC9J,8EAA8E;IAC9E,2EAA2E;IAC3E,KAAK,EAAE,GAAG,EAAE,CAAC,CAAC,EAAE,OAAO,EAAE,SAAS,EAAE,MAAM,EAAE,EAAE,EAAE,CAAC;CAClD,CAAC,CAAC","sourcesContent":["import { IconPencil } from \"@tabler/icons-react\";\nimport {\n  useEffect,\n  useId,\n  useMemo,\n  useRef,\n  useState,\n  type ReactNode,\n} from \"react\";\n\nimport { ltrCodeBlockProps } from \"../code-block-direction.js\";\nimport { defineBlock } from \"../types.js\";\nimport type {\n  BlockReadProps,\n  BlockEditProps,\n  BlockRenderContext,\n} from \"../types.js\";\nimport { useBlockCopy } from \"./block-copy.js\";\nimport {\n  sanitizeWireframeCss,\n  sanitizeWireframeHtml,\n  scopeDesignCss,\n} from \"./sanitize-html.js\";\nimport { renderWireframeIconHtml } from \"./wireframe-icons.js\";\nimport {\n  HTML_ROUGH_SELECTOR,\n  KitConfigContext,\n  RoughOverlay,\n  Screen,\n  renderNodes,\n  toggleWireframeStyle,\n  useIsDark,\n  useWireframeStyle,\n} from \"./wireframe-kit.js\";\nimport {\n  wireframeSchema,\n  wireframeMdx,\n  type WireframeData,\n  type WireframeSurface,\n} from \"./wireframe.config.js\";\n\n/**\n * Shared `wireframe` block — a hand-drawn low-fi mockup of one screen, rendered\n * from either a declarative kit tree (`data.screen`) or a self-contained HTML\n * mockup (`data.html`), inside a surface-locked frame (desktop/mobile/popover/\n * panel/browser) with a rough.js sketch overlay. Lives in core so any app can\n * register it (it originated in the plan template).\n *\n * DECOUPLING from the plan original:\n * - Theme: `useIsDark()` reads `document.documentElement.classList` instead of\n *   `next-themes` (the MermaidBlock precedent), so core stays dependency-light.\n * - HTML sanitize: the HTML path runs `data.html`/`data.css` through the\n *   app-injected `ctx.sanitizeHtml`. If no sanitizer is wired the HTML path is\n *   skipped (kit tree or an empty frame renders) — core never injects unsanitized\n *   author HTML.\n * - The plan-only prototype runtime, design-element selection, and legacy region\n *   fallback are intentionally NOT ported; those are plan-canvas features, not\n *   part of the document-block render. The kit element vocabulary, the `--wf-*`\n *   token contract, and the `.plan-wf` / `.wf-*` / `[data-rough]` classes the\n *   overlay measures are preserved exactly.\n *\n * The section carries the app-neutral `an-block` class plus the legacy\n * `plan-block` class so plan renders byte-identically while any other app gets\n * the theme-token treatment from core's `blocks.css`.\n *\n * The wireframe is canvas / agent-patch edited (node-addressable content patches\n * applied server-side), NOT schema-form edited in the browser — so `Edit` reuses\n * the same static render as `Read`, mirroring the plan `WireframeEditor`.\n */\n\ntype SurfacePreset = {\n  width: number;\n  /**\n   * Floor height for the surface. The frame is AUTO-HEIGHT (content-driven): it\n   * grows past this when content is tall and shrinks toward its content height\n   * when content is short, but never collapses below this floor — so an empty or\n   * near-empty frame still reads as that surface instead of a thin sliver. This\n   * is a `min-height`, not a fixed `height`: it is the lower bound the old fixed\n   * preset height used to also be the UPPER bound, which is what left a big empty\n   * vertical band below short content (e.g. a header + one dropdown padded to a\n   * tall fixed aspect).\n   */\n  minHeight: number;\n  radius: number;\n};\n\nconst SURFACE_PRESETS: Record<WireframeSurface, SurfacePreset> = {\n  // mobile keeps a tall floor: a phone frame reads as a phone even when short.\n  mobile: { width: 300, minHeight: 360, radius: 30 },\n  desktop: { width: 840, minHeight: 200, radius: 14 },\n  browser: { width: 900, minHeight: 200, radius: 14 },\n  popover: { width: 360, minHeight: 120, radius: 16 },\n  panel: { width: 420, minHeight: 200, radius: 16 },\n};\n\nfunction isHtmlData(data: WireframeData): boolean {\n  return typeof data.html === \"string\" && data.html.trim().length > 0;\n}\n\n/* -------------------------------------------------------------------------- */\n/* Shared frame shell: surface-locked WIDTH + auto (content-driven) height +   */\n/* theme + rough overlay. The frame keeps each surface's footprint and chrome  */\n/* but fits its content height instead of padding to a fixed aspect, so short  */\n/* content yields a short frame and tall content grows. Pass `canvasSize` to   */\n/* opt a fixed-aspect canvas artboard back into a hard pixel height.           */\n/* -------------------------------------------------------------------------- */\n\nfunction ArtboardFrame({\n  surface,\n  compact,\n  canvasSize,\n  canvasWidth,\n  skeleton,\n  renderMode,\n  roughOverlay = true,\n  showFrame = true,\n  selector,\n  caption,\n  render,\n}: {\n  surface: WireframeSurface;\n  compact?: boolean;\n  /**\n   * Force a FIXED pixel height instead of the auto-height (content-driven)\n   * default. Reserved for fixed-aspect canvas artboards (pan/zoom). Document-flow\n   * wireframes — what recaps render — leave this unset so the frame fits content.\n   */\n  canvasSize?: number;\n  canvasWidth?: number;\n  skeleton?: boolean;\n  renderMode?: \"wireframe\" | \"design\";\n  roughOverlay?: boolean;\n  showFrame?: boolean;\n  selector: string;\n  caption?: string;\n  render: (ctx: {\n    theme: \"light\" | \"dark\";\n    style: \"sketchy\" | \"clean\";\n  }) => ReactNode;\n}) {\n  const ref = useRef<HTMLDivElement>(null);\n  const fitRef = useRef<HTMLDivElement>(null);\n  const isDark = useIsDark();\n  const theme: \"light\" | \"dark\" = isDark ? \"dark\" : \"light\";\n  const style = useWireframeStyle();\n  const preset = SURFACE_PRESETS[surface] ?? SURFACE_PRESETS.desktop;\n  const width = canvasWidth ?? preset.width;\n  // AUTO-HEIGHT: with no explicit `canvasSize` the artboard height is driven by\n  // its content (`height: auto`), floored at the surface's `minHeight` so a short\n  // screen produces a short frame and a tall screen grows — instead of every\n  // surface being padded to a fixed preset height that left a big empty band\n  // below short content. A `canvasSize` (fixed-aspect canvas artboard) overrides\n  // this with a hard pixel height.\n  const fixedHeight = canvasSize;\n  const minHeight = fixedHeight ?? preset.minHeight;\n  const baseScale = compact ? Math.min(1, 320 / preset.width) : 1;\n  const maxFrameWidth = compact ? preset.width * baseScale : width;\n  const [fitScale, setFitScale] = useState(baseScale);\n  // The scaled artboard is `transform: scale()`-ed, which does not change its\n  // layout box, so the wrapper that reserves vertical space must track the\n  // artboard's ACTUAL rendered height. With a fixed height that's known up front;\n  // with auto-height we measure it.\n  const [measuredHeight, setMeasuredHeight] = useState<number | null>(\n    fixedHeight ?? null,\n  );\n  const designMode = renderMode === \"design\";\n  const sketchy = !designMode && style === \"sketchy\" && !skeleton;\n  const roughEnabled = sketchy && roughOverlay;\n  const frameBorder = skeleton\n    ? \"var(--plan-placeholder-line, var(--plan-line, hsl(var(--border))))\"\n    : \"var(--plan-line, hsl(var(--border)))\";\n\n  useEffect(() => {\n    const element = fitRef.current;\n    if (!element) return;\n    const measure = () => {\n      const availableWidth = element.clientWidth;\n      const nextScale =\n        availableWidth > 0\n          ? Math.min(baseScale, availableWidth / width)\n          : baseScale;\n      setFitScale((current) =>\n        Math.abs(current - nextScale) < 0.001 ? current : nextScale,\n      );\n    };\n    measure();\n    const observer = new ResizeObserver(measure);\n    observer.observe(element);\n    return () => observer.disconnect();\n  }, [baseScale, width]);\n\n  // Track the auto-height artboard's rendered height so the (un-transformed)\n  // wrapper reserves exactly the scaled space the frame occupies. Skipped when a\n  // fixed height is supplied — there's nothing to measure.\n  useEffect(() => {\n    if (fixedHeight != null) return;\n    const element = ref.current;\n    if (!element) return;\n    const measure = () => {\n      const next = element.offsetHeight;\n      setMeasuredHeight((current) =>\n        current != null && Math.abs(current - next) < 0.5 ? current : next,\n      );\n    };\n    measure();\n    const observer = new ResizeObserver(measure);\n    observer.observe(element);\n    return () => observer.disconnect();\n  }, [fixedHeight]);\n\n  // Height the wrapper reserves: the measured (or fixed) artboard height scaled\n  // by the fit factor. Falls back to the surface floor before the first measure\n  // so SSR / first paint reserves a sensible box rather than collapsing.\n  const reservedHeight = (measuredHeight ?? minHeight) * fitScale;\n  const reserveScaledHeight = fixedHeight != null || fitScale !== 1;\n\n  return (\n    <div\n      ref={fitRef}\n      className=\"plan-kit-wireframe\"\n      style={{\n        width: \"100%\",\n        maxWidth: maxFrameWidth,\n      }}\n    >\n      <div\n        className=\"group/wireframe-artboard relative\"\n        style={{\n          width: \"100%\",\n          maxWidth: maxFrameWidth,\n          ...(reserveScaledHeight ? { height: reservedHeight } : {}),\n          marginInline: \"auto\",\n        }}\n      >\n        <div\n          ref={ref}\n          className=\"plan-kit-artboard relative\"\n          data-rough-scope=\"wireframe\"\n          data-frame={showFrame ? \"show\" : \"hide\"}\n          style={{\n            width,\n            // Auto-height by default (content-driven, floored at `minHeight`);\n            // a fixed `canvasSize` locks the height for canvas artboards.\n            ...(fixedHeight != null ? { height: fixedHeight } : { minHeight }),\n            borderRadius: preset.radius,\n            ...(fitScale !== 1\n              ? {\n                  transform: `scale(${fitScale})`,\n                  transformOrigin: \"top left\",\n                }\n              : {}),\n          }}\n        >\n          {/* Content drives the artboard height in flow when auto-height; for a\n              fixed height it's pinned to the box. Rounded corners clip overflow\n              either way. */}\n          <div\n            className=\"overflow-hidden\"\n            style={{\n              borderRadius: preset.radius,\n              ...(fixedHeight != null\n                ? { position: \"absolute\", inset: 0 }\n                : { minHeight }),\n            }}\n          >\n            {render({ theme, style })}\n          </div>\n          {!roughEnabled && showFrame && (\n            <div\n              className=\"pointer-events-none absolute inset-0\"\n              style={{\n                borderRadius: preset.radius,\n                border: `1.5px solid ${frameBorder}`,\n              }}\n            />\n          )}\n          <RoughOverlay\n            scopeRef={ref}\n            enabled={roughEnabled}\n            drawFrame={showFrame}\n            frameRadius={preset.radius}\n            selector={selector}\n          />\n        </div>\n        {!designMode && !skeleton && <WireframeStyleToggleButton />}\n      </div>\n      {caption && (\n        <p className=\"mt-2 text-center text-xs text-plan-muted\">{caption}</p>\n      )}\n    </div>\n  );\n}\n\nfunction WireframeStyleToggleButton() {\n  const style = useWireframeStyle();\n  const copy = useBlockCopy();\n  const nextStyle = style === \"sketchy\" ? \"clean\" : \"sketchy\";\n  const label = nextStyle === \"clean\" ? copy.clean : copy.sketchy;\n  const description = copy.switchVisualStyle.replace(\n    \"{{style}}\",\n    label.toLocaleLowerCase(),\n  );\n\n  return (\n    <button\n      type=\"button\"\n      data-plan-interactive\n      data-rough=\"none\"\n      data-wireframe-style-toggle\n      aria-label={description}\n      title={description}\n      onClick={(event) => {\n        event.stopPropagation();\n        toggleWireframeStyle();\n      }}\n      className=\"absolute right-2 top-2 z-30 inline-flex h-7 items-center gap-1 rounded-md border border-border/60 bg-background px-2 text-xs font-medium text-muted-foreground opacity-0 shadow-sm transition-[color,opacity] hover:text-foreground focus-visible:opacity-100 focus-visible:outline-none focus-visible:ring-1 focus-visible:ring-ring group-hover/wireframe-artboard:opacity-100\"\n    >\n      <IconPencil className=\"size-3.5\" aria-hidden=\"true\" />\n      <span>{label}</span>\n    </button>\n  );\n}\n\n/* -------------------------------------------------------------------------- */\n/* HTML artboard — author HTML, themed + roughened by the renderer.           */\n/* -------------------------------------------------------------------------- */\n\nfunction HtmlArtboard({\n  data,\n  ctx: _ctx,\n  showFrame,\n  compact,\n}: {\n  data: WireframeData;\n  ctx: BlockRenderContext;\n  showFrame: boolean;\n  compact?: boolean;\n}) {\n  const renderMode = data.renderMode ?? \"wireframe\";\n  const designMode = renderMode === \"design\";\n  // Sanitize author HTML/CSS at the render point (defense-in-depth against stored\n  // XSS). Self-contained in core via the shared block sanitizer (DOM-based in the\n  // browser, regex fallback on the server) so the HTML mockup path renders in any\n  // app without the host wiring a sanitizer hook.\n  const safeHtml = useMemo(\n    () =>\n      renderWireframeIconHtml(\n        sanitizeWireframeHtml(data.html, {\n          preserveThemeClasses: designMode,\n        }),\n      ),\n    [data.html, designMode],\n  );\n  const scopeId = useId().replace(/[^a-zA-Z0-9_-]/g, \"\");\n  const scopedCss = useMemo(() => {\n    const safeCss = sanitizeWireframeCss(data.css);\n    // Scope every author selector under this instance's artboard so global\n    // selectors (body, *, .app-shell, :root) can't restyle/hide the host app.\n    return safeCss\n      ? scopeDesignCss(safeCss, `[data-plan-design-scope=\"${scopeId}\"]`)\n      : \"\";\n  }, [data.css, scopeId]);\n\n  return (\n    <ArtboardFrame\n      surface={data.surface}\n      compact={compact}\n      skeleton={data.skeleton}\n      renderMode={renderMode}\n      showFrame={showFrame}\n      selector={HTML_ROUGH_SELECTOR}\n      caption={data.caption}\n      render={({ theme, style }) => (\n        <div\n          className=\"plan-html-frame\"\n          data-theme={theme}\n          data-style={style}\n          data-frame={showFrame ? \"show\" : \"hide\"}\n          data-render-mode={renderMode}\n          data-plan-design-scope={scopeId}\n          data-skeleton={data.skeleton ? \"true\" : undefined}\n        >\n          {scopedCss && <style>{scopedCss}</style>}\n          <div\n            className=\"plan-html-frame-content\"\n            dangerouslySetInnerHTML={{ __html: safeHtml }}\n          />\n        </div>\n      )}\n    />\n  );\n}\n\n/* -------------------------------------------------------------------------- */\n/* Kit artboard — declarative kit tree.                                       */\n/* -------------------------------------------------------------------------- */\n\nfunction KitArtboard({\n  data,\n  showFrame,\n  compact,\n}: {\n  data: WireframeData;\n  showFrame: boolean;\n  compact?: boolean;\n}) {\n  return (\n    <ArtboardFrame\n      surface={data.surface}\n      compact={compact}\n      skeleton={data.skeleton}\n      showFrame={showFrame}\n      selector=\"[data-rough]\"\n      caption={data.caption}\n      render={({ theme, style }) => (\n        <KitConfigContext.Provider\n          value={{\n            skeleton: data.skeleton,\n            flushFrame: !showFrame,\n            theme,\n            style,\n          }}\n        >\n          {renderKitScreen(data.screen ?? [])}\n        </KitConfigContext.Provider>\n      )}\n    />\n  );\n}\n\nfunction renderKitScreen(\n  nodes: NonNullable<WireframeData[\"screen\"]>,\n): ReactNode {\n  if (nodes.length === 1 && nodes[0]?.el === \"screen\") {\n    return renderNodes(nodes);\n  }\n  // `minHeight` (not `height`) so the screen fills the auto-height artboard floor\n  // but grows past it when content is tall, instead of locking to a fixed box.\n  return (\n    <Screen pad=\"calc(var(--pad) * 1.35)\" style={{ minHeight: \"100%\" }}>\n      {renderNodes(nodes)}\n    </Screen>\n  );\n}\n\n/**\n * The bare wireframe surface (no block section / title). Routes to the HTML\n * mockup when `data.html` is present and a sanitizer is wired; otherwise renders\n * the kit tree.\n */\nfunction WireframeSurfaceView({\n  data,\n  ctx,\n  compact,\n}: {\n  data: WireframeData;\n  ctx: BlockRenderContext;\n  compact?: boolean;\n}) {\n  const showFrame = resolveVisualFrame(data.frame, ctx);\n  if (isHtmlData(data)) {\n    return (\n      <HtmlArtboard\n        data={data}\n        ctx={ctx}\n        showFrame={showFrame}\n        compact={compact}\n      />\n    );\n  }\n  return <KitArtboard data={data} showFrame={showFrame} compact={compact} />;\n}\n\nfunction resolveVisualFrame(\n  frame: WireframeData[\"frame\"],\n  ctx: BlockRenderContext,\n): boolean {\n  const resolved =\n    frame && frame !== \"auto\" ? frame : (ctx.visualFrame ?? \"show\");\n  return resolved !== \"hide\";\n}\n\n/* -------------------------------------------------------------------------- */\n/* Block Read / Edit                                                          */\n/* -------------------------------------------------------------------------- */\n\n/** Read-only renderer for a `wireframe` block. */\nexport function WireframeBlock({\n  data,\n  blockId,\n  title,\n  summary,\n  ctx,\n  compactVisuals,\n}: BlockReadProps<WireframeData>) {\n  return (\n    <section\n      {...ltrCodeBlockProps}\n      className=\"an-block plan-block an-wireframe\"\n      data-block-id={blockId}\n    >\n      {title && <div className=\"an-block-label plan-block-label\">{title}</div>}\n      <WireframeSurfaceView data={data} ctx={ctx} compact={compactVisuals} />\n      {summary && <p className=\"mt-5 text-plan-muted\">{summary}</p>}\n    </section>\n  );\n}\n\n/**\n * Editor for the `wireframe` block. The wireframe is canvas / agent-patch edited\n * (it never calls `onChange`), so edit mode reuses the read surface — mirroring\n * the plan `WireframeEditor`. The host document editor already wraps the registry\n * edit path in a titled section, so this renders only the surface to avoid\n * double-nesting.\n */\nexport function WireframeEditor({ data, ctx }: BlockEditProps<WireframeData>) {\n  return <WireframeSurfaceView data={data} ctx={ctx} />;\n}\n\n/** Full client spec for the shared `wireframe` block (schema + MDX + Read/Edit). */\nexport const wireframeBlock = defineBlock<WireframeData>({\n  type: \"wireframe\",\n  schema: wireframeSchema,\n  mdx: wireframeMdx,\n  Read: WireframeBlock,\n  Edit: WireframeEditor,\n  placement: [\"block\"],\n  editSurface: \"inline\",\n  label: \"Wireframe\",\n  description:\n    \"A sketch wireframe of one screen built from kit primitives (or an HTML mockup), rendered in a chosen surface frame (desktop/mobile/popover/panel/browser).\",\n  // `surface` is the only required field; `screen` defaults to []. Start on the\n  // desktop surface with an empty screen so the canvas/agent can fill it in.\n  empty: () => ({ surface: \"desktop\", screen: [] }),\n});\n"]}
+{"version":3,"file":"wireframe.js","sourceRoot":"","sources":["../../../../src/client/blocks/library/wireframe.tsx"],"names":[],"mappings":";AAAA,OAAO,EAAE,UAAU,EAAE,MAAM,qBAAqB,CAAC;AACjD,OAAO,EACL,SAAS,EACT,KAAK,EACL,OAAO,EACP,MAAM,EACN,QAAQ,GAET,MAAM,OAAO,CAAC;AAEf,OAAO,EAAE,iBAAiB,EAAE,MAAM,4BAA4B,CAAC;AAC/D,OAAO,EAAE,WAAW,EAAE,MAAM,aAAa,CAAC;AAM1C,OAAO,EAAE,YAAY,EAAE,MAAM,iBAAiB,CAAC;AAC/C,OAAO,EACL,oBAAoB,EACpB,qBAAqB,EACrB,cAAc,GACf,MAAM,oBAAoB,CAAC;AAC5B,OAAO,EAAE,uBAAuB,EAAE,MAAM,sBAAsB,CAAC;AAC/D,OAAO,EACL,mBAAmB,EACnB,gBAAgB,EAChB,YAAY,EACZ,MAAM,EACN,WAAW,EACX,oBAAoB,EACpB,SAAS,EACT,iBAAiB,GAClB,MAAM,oBAAoB,CAAC;AAC5B,OAAO,EACL,eAAe,EACf,YAAY,GAGb,MAAM,uBAAuB,CAAC;AA+C/B,MAAM,eAAe,GAA4C;IAC/D,6EAA6E;IAC7E,MAAM,EAAE,EAAE,KAAK,EAAE,GAAG,EAAE,SAAS,EAAE,GAAG,EAAE,MAAM,EAAE,EAAE,EAAE;IAClD,OAAO,EAAE,EAAE,KAAK,EAAE,GAAG,EAAE,SAAS,EAAE,GAAG,EAAE,MAAM,EAAE,EAAE,EAAE;IACnD,OAAO,EAAE,EAAE,KAAK,EAAE,GAAG,EAAE,SAAS,EAAE,GAAG,EAAE,MAAM,EAAE,EAAE,EAAE;IACnD,OAAO,EAAE,EAAE,KAAK,EAAE,GAAG,EAAE,SAAS,EAAE,GAAG,EAAE,MAAM,EAAE,EAAE,EAAE;IACnD,KAAK,EAAE,EAAE,KAAK,EAAE,GAAG,EAAE,SAAS,EAAE,GAAG,EAAE,MAAM,EAAE,EAAE,EAAE;CAClD,CAAC;AAEF,SAAS,UAAU,CAAC,IAAmB;IACrC,OAAO,OAAO,IAAI,CAAC,IAAI,KAAK,QAAQ,IAAI,IAAI,CAAC,IAAI,CAAC,IAAI,EAAE,CAAC,MAAM,GAAG,CAAC,CAAC;AACtE,CAAC;AAED,gFAAgF;AAChF,iFAAiF;AACjF,iFAAiF;AACjF,iFAAiF;AACjF,iFAAiF;AACjF,iFAAiF;AACjF,gFAAgF;AAEhF,SAAS,aAAa,CAAC,EACrB,OAAO,EACP,OAAO,EACP,UAAU,EACV,WAAW,EACX,QAAQ,EACR,UAAU,EACV,YAAY,GAAG,IAAI,EACnB,SAAS,GAAG,IAAI,EAChB,QAAQ,EACR,OAAO,EACP,MAAM,GAqBP;IACC,MAAM,GAAG,GAAG,MAAM,CAAiB,IAAI,CAAC,CAAC;IACzC,MAAM,MAAM,GAAG,MAAM,CAAiB,IAAI,CAAC,CAAC;IAC5C,MAAM,MAAM,GAAG,SAAS,EAAE,CAAC;IAC3B,MAAM,KAAK,GAAqB,MAAM,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,OAAO,CAAC;IAC1D,MAAM,cAAc,GAAG,iBAAiB,EAAE,CAAC;IAC3C,MAAM,MAAM,GAAG,eAAe,CAAC,OAAO,CAAC,IAAI,eAAe,CAAC,OAAO,CAAC;IACnE,MAAM,KAAK,GAAG,WAAW,IAAI,MAAM,CAAC,KAAK,CAAC;IAC1C,8EAA8E;IAC9E,gFAAgF;IAChF,2EAA2E;IAC3E,2EAA2E;IAC3E,+EAA+E;IAC/E,iCAAiC;IACjC,MAAM,WAAW,GAAG,UAAU,CAAC;IAC/B,MAAM,SAAS,GAAG,WAAW,IAAI,MAAM,CAAC,SAAS,CAAC;IAClD,MAAM,SAAS,GAAG,OAAO,CAAC,CAAC,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,EAAE,GAAG,GAAG,MAAM,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC;IAChE,MAAM,aAAa,GAAG,OAAO,CAAC,CAAC,CAAC,MAAM,CAAC,KAAK,GAAG,SAAS,CAAC,CAAC,CAAC,KAAK,CAAC;IACjE,MAAM,CAAC,QAAQ,EAAE,WAAW,CAAC,GAAG,QAAQ,CAAC,SAAS,CAAC,CAAC;IACpD,4EAA4E;IAC5E,yEAAyE;IACzE,gFAAgF;IAChF,kCAAkC;IAClC,MAAM,CAAC,cAAc,EAAE,iBAAiB,CAAC,GAAG,QAAQ,CAClD,WAAW,IAAI,IAAI,CACpB,CAAC;IACF,MAAM,UAAU,GAAG,UAAU,KAAK,QAAQ,CAAC;IAC3C,MAAM,KAAK,GAAG,UAAU,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,cAAc,CAAC;IACpD,MAAM,OAAO,GAAG,CAAC,UAAU,IAAI,KAAK,KAAK,SAAS,IAAI,CAAC,QAAQ,CAAC;IAChE,MAAM,YAAY,GAAG,OAAO,IAAI,YAAY,CAAC;IAC7C,MAAM,WAAW,GAAG,QAAQ;QAC1B,CAAC,CAAC,oEAAoE;QACtE,CAAC,CAAC,sCAAsC,CAAC;IAE3C,SAAS,CAAC,GAAG,EAAE;QACb,MAAM,OAAO,GAAG,MAAM,CAAC,OAAO,CAAC;QAC/B,IAAI,CAAC,OAAO;YAAE,OAAO;QACrB,MAAM,OAAO,GAAG,GAAG,EAAE;YACnB,MAAM,cAAc,GAAG,OAAO,CAAC,WAAW,CAAC;YAC3C,MAAM,SAAS,GACb,cAAc,GAAG,CAAC;gBAChB,CAAC,CAAC,IAAI,CAAC,GAAG,CAAC,SAAS,EAAE,cAAc,GAAG,KAAK,CAAC;gBAC7C,CAAC,CAAC,SAAS,CAAC;YAChB,WAAW,CAAC,CAAC,OAAO,EAAE,EAAE,CACtB,IAAI,CAAC,GAAG,CAAC,OAAO,GAAG,SAAS,CAAC,GAAG,KAAK,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,SAAS,CAC5D,CAAC;QACJ,CAAC,CAAC;QACF,OAAO,EAAE,CAAC;QACV,MAAM,QAAQ,GAAG,IAAI,cAAc,CAAC,OAAO,CAAC,CAAC;QAC7C,QAAQ,CAAC,OAAO,CAAC,OAAO,CAAC,CAAC;QAC1B,OAAO,GAAG,EAAE,CAAC,QAAQ,CAAC,UAAU,EAAE,CAAC;IACrC,CAAC,EAAE,CAAC,SAAS,EAAE,KAAK,CAAC,CAAC,CAAC;IAEvB,2EAA2E;IAC3E,+EAA+E;IAC/E,yDAAyD;IACzD,SAAS,CAAC,GAAG,EAAE;QACb,IAAI,WAAW,IAAI,IAAI;YAAE,OAAO;QAChC,MAAM,OAAO,GAAG,GAAG,CAAC,OAAO,CAAC;QAC5B,IAAI,CAAC,OAAO;YAAE,OAAO;QACrB,MAAM,OAAO,GAAG,GAAG,EAAE;YACnB,MAAM,IAAI,GAAG,OAAO,CAAC,YAAY,CAAC;YAClC,iBAAiB,CAAC,CAAC,OAAO,EAAE,EAAE,CAC5B,OAAO,IAAI,IAAI,IAAI,IAAI,CAAC,GAAG,CAAC,OAAO,GAAG,IAAI,CAAC,GAAG,GAAG,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,IAAI,CACnE,CAAC;QACJ,CAAC,CAAC;QACF,OAAO,EAAE,CAAC;QACV,MAAM,QAAQ,GAAG,IAAI,cAAc,CAAC,OAAO,CAAC,CAAC;QAC7C,QAAQ,CAAC,OAAO,CAAC,OAAO,CAAC,CAAC;QAC1B,OAAO,GAAG,EAAE,CAAC,QAAQ,CAAC,UAAU,EAAE,CAAC;IACrC,CAAC,EAAE,CAAC,WAAW,CAAC,CAAC,CAAC;IAElB,8EAA8E;IAC9E,8EAA8E;IAC9E,uEAAuE;IACvE,MAAM,cAAc,GAAG,CAAC,cAAc,IAAI,SAAS,CAAC,GAAG,QAAQ,CAAC;IAChE,MAAM,mBAAmB,GAAG,WAAW,IAAI,IAAI,IAAI,QAAQ,KAAK,CAAC,CAAC;IAElE,OAAO,CACL,eACE,GAAG,EAAE,MAAM,EACX,SAAS,EAAC,oBAAoB,EAC9B,KAAK,EAAE;YACL,KAAK,EAAE,MAAM;YACb,QAAQ,EAAE,aAAa;SACxB,aAED,eACE,SAAS,EAAC,mCAAmC,EAC7C,KAAK,EAAE;oBACL,KAAK,EAAE,MAAM;oBACb,QAAQ,EAAE,aAAa;oBACvB,GAAG,CAAC,mBAAmB,CAAC,CAAC,CAAC,EAAE,MAAM,EAAE,cAAc,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;oBAC1D,YAAY,EAAE,MAAM;iBACrB,aAED,eACE,GAAG,EAAE,GAAG,EACR,SAAS,EAAC,4BAA4B,sBACrB,WAAW,gBAChB,SAAS,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,MAAM,EACvC,KAAK,EAAE;4BACL,KAAK;4BACL,mEAAmE;4BACnE,8DAA8D;4BAC9D,GAAG,CAAC,WAAW,IAAI,IAAI,CAAC,CAAC,CAAC,EAAE,MAAM,EAAE,WAAW,EAAE,CAAC,CAAC,CAAC,EAAE,SAAS,EAAE,CAAC;4BAClE,YAAY,EAAE,MAAM,CAAC,MAAM;4BAC3B,GAAG,CAAC,QAAQ,KAAK,CAAC;gCAChB,CAAC,CAAC;oCACE,SAAS,EAAE,SAAS,QAAQ,GAAG;oCAC/B,eAAe,EAAE,UAAU;iCAC5B;gCACH,CAAC,CAAC,EAAE,CAAC;yBACR,aAKD,cACE,SAAS,EAAC,iBAAiB,EAC3B,KAAK,EAAE;oCACL,YAAY,EAAE,MAAM,CAAC,MAAM;oCAC3B,GAAG,CAAC,WAAW,IAAI,IAAI;wCACrB,CAAC,CAAC,EAAE,QAAQ,EAAE,UAAU,EAAE,KAAK,EAAE,CAAC,EAAE;wCACpC,CAAC,CAAC,EAAE,SAAS,EAAE,CAAC;iCACnB,YAEA,MAAM,CAAC,EAAE,KAAK,EAAE,KAAK,EAAE,CAAC,GACrB,EACL,CAAC,YAAY,IAAI,SAAS,IAAI,CAC7B,cACE,SAAS,EAAC,sCAAsC,EAChD,KAAK,EAAE;oCACL,YAAY,EAAE,MAAM,CAAC,MAAM;oCAC3B,MAAM,EAAE,eAAe,WAAW,EAAE;iCACrC,GACD,CACH,EACD,KAAC,YAAY,IACX,QAAQ,EAAE,GAAG,EACb,OAAO,EAAE,YAAY,EACrB,SAAS,EAAE,SAAS,EACpB,WAAW,EAAE,MAAM,CAAC,MAAM,EAC1B,QAAQ,EAAE,QAAQ,GAClB,IACE,EACL,CAAC,UAAU,IAAI,CAAC,QAAQ,IAAI,KAAC,0BAA0B,KAAG,IACvD,EACL,OAAO,IAAI,CACV,YAAG,SAAS,EAAC,0CAA0C,YAAE,OAAO,GAAK,CACtE,IACG,CACP,CAAC;AACJ,CAAC;AAED,SAAS,0BAA0B;IACjC,MAAM,KAAK,GAAG,iBAAiB,EAAE,CAAC;IAClC,MAAM,IAAI,GAAG,YAAY,EAAE,CAAC;IAC5B,MAAM,SAAS,GAAG,KAAK,KAAK,SAAS,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,SAAS,CAAC;IAC5D,MAAM,KAAK,GAAG,SAAS,KAAK,OAAO,CAAC,CAAC,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,IAAI,CAAC,OAAO,CAAC;IAChE,MAAM,WAAW,GAAG,IAAI,CAAC,iBAAiB,CAAC,OAAO,CAChD,WAAW,EACX,KAAK,CAAC,iBAAiB,EAAE,CAC1B,CAAC;IAEF,OAAO,CACL,kBACE,IAAI,EAAC,QAAQ,+CAEF,MAAM,qDAEL,WAAW,EACvB,KAAK,EAAE,WAAW,EAClB,OAAO,EAAE,CAAC,KAAK,EAAE,EAAE;YACjB,KAAK,CAAC,eAAe,EAAE,CAAC;YACxB,oBAAoB,EAAE,CAAC;QACzB,CAAC,EACD,SAAS,EAAC,kXAAkX,aAE5X,KAAC,UAAU,IAAC,SAAS,EAAC,UAAU,iBAAa,MAAM,GAAG,EACtD,yBAAO,KAAK,GAAQ,IACb,CACV,CAAC;AACJ,CAAC;AAED,gFAAgF;AAChF,gFAAgF;AAChF,gFAAgF;AAEhF,SAAS,YAAY,CAAC,EACpB,IAAI,EACJ,GAAG,EAAE,IAAI,EACT,SAAS,EACT,OAAO,GAMR;IACC,MAAM,UAAU,GAAG,IAAI,CAAC,UAAU,IAAI,WAAW,CAAC;IAClD,MAAM,UAAU,GAAG,UAAU,KAAK,QAAQ,CAAC;IAC3C,gFAAgF;IAChF,gFAAgF;IAChF,gFAAgF;IAChF,gDAAgD;IAChD,MAAM,QAAQ,GAAG,OAAO,CACtB,GAAG,EAAE,CACH,uBAAuB,CACrB,qBAAqB,CAAC,IAAI,CAAC,IAAI,EAAE;QAC/B,oBAAoB,EAAE,UAAU;KACjC,CAAC,CACH,EACH,CAAC,IAAI,CAAC,IAAI,EAAE,UAAU,CAAC,CACxB,CAAC;IACF,MAAM,OAAO,GAAG,KAAK,EAAE,CAAC,OAAO,CAAC,iBAAiB,EAAE,EAAE,CAAC,CAAC;IACvD,MAAM,SAAS,GAAG,OAAO,CAAC,GAAG,EAAE;QAC7B,MAAM,OAAO,GAAG,oBAAoB,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;QAC/C,uEAAuE;QACvE,0EAA0E;QAC1E,OAAO,OAAO;YACZ,CAAC,CAAC,cAAc,CAAC,OAAO,EAAE,4BAA4B,OAAO,IAAI,CAAC;YAClE,CAAC,CAAC,EAAE,CAAC;IACT,CAAC,EAAE,CAAC,IAAI,CAAC,GAAG,EAAE,OAAO,CAAC,CAAC,CAAC;IAExB,OAAO,CACL,KAAC,aAAa,IACZ,OAAO,EAAE,IAAI,CAAC,OAAO,EACrB,OAAO,EAAE,OAAO,EAChB,QAAQ,EAAE,IAAI,CAAC,QAAQ,EACvB,UAAU,EAAE,UAAU,EACtB,SAAS,EAAE,SAAS,EACpB,QAAQ,EAAE,mBAAmB,EAC7B,OAAO,EAAE,IAAI,CAAC,OAAO,EACrB,MAAM,EAAE,CAAC,EAAE,KAAK,EAAE,KAAK,EAAE,EAAE,EAAE,CAAC,CAC5B,eACE,SAAS,EAAC,iBAAiB,gBACf,KAAK,gBACL,KAAK,gBACL,SAAS,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,MAAM,sBACrB,UAAU,4BACJ,OAAO,mBAChB,IAAI,CAAC,QAAQ,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,SAAS,aAEhD,SAAS,IAAI,0BAAQ,SAAS,GAAS,EACxC,cACE,SAAS,EAAC,yBAAyB,EACnC,uBAAuB,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,GAC7C,IACE,CACP,GACD,CACH,CAAC;AACJ,CAAC;AAED,gFAAgF;AAChF,gFAAgF;AAChF,gFAAgF;AAEhF,SAAS,WAAW,CAAC,EACnB,IAAI,EACJ,SAAS,EACT,OAAO,GAKR;IACC,OAAO,CACL,KAAC,aAAa,IACZ,OAAO,EAAE,IAAI,CAAC,OAAO,EACrB,OAAO,EAAE,OAAO,EAChB,QAAQ,EAAE,IAAI,CAAC,QAAQ,EACvB,UAAU,EAAE,IAAI,CAAC,UAAU,EAC3B,SAAS,EAAE,SAAS,EACpB,QAAQ,EAAC,cAAc,EACvB,OAAO,EAAE,IAAI,CAAC,OAAO,EACrB,MAAM,EAAE,CAAC,EAAE,KAAK,EAAE,KAAK,EAAE,EAAE,EAAE,CAAC,CAC5B,KAAC,gBAAgB,CAAC,QAAQ,IACxB,KAAK,EAAE;gBACL,QAAQ,EAAE,IAAI,CAAC,QAAQ;gBACvB,UAAU,EAAE,CAAC,SAAS;gBACtB,KAAK;gBACL,KAAK;aACN,YAEA,eAAe,CAAC,IAAI,CAAC,MAAM,IAAI,EAAE,CAAC,GACT,CAC7B,GACD,CACH,CAAC;AACJ,CAAC;AAED,SAAS,eAAe,CACtB,KAA2C;IAE3C,IAAI,KAAK,CAAC,MAAM,KAAK,CAAC,IAAI,KAAK,CAAC,CAAC,CAAC,EAAE,EAAE,KAAK,QAAQ,EAAE,CAAC;QACpD,OAAO,WAAW,CAAC,KAAK,CAAC,CAAC;IAC5B,CAAC;IACD,gFAAgF;IAChF,6EAA6E;IAC7E,OAAO,CACL,KAAC,MAAM,IAAC,GAAG,EAAC,yBAAyB,EAAC,KAAK,EAAE,EAAE,SAAS,EAAE,MAAM,EAAE,YAC/D,WAAW,CAAC,KAAK,CAAC,GACZ,CACV,CAAC;AACJ,CAAC;AAED;;;;GAIG;AACH,SAAS,oBAAoB,CAAC,EAC5B,IAAI,EACJ,GAAG,EACH,OAAO,GAKR;IACC,MAAM,SAAS,GAAG,kBAAkB,CAAC,IAAI,CAAC,KAAK,EAAE,GAAG,CAAC,CAAC;IACtD,IAAI,UAAU,CAAC,IAAI,CAAC,EAAE,CAAC;QACrB,OAAO,CACL,KAAC,YAAY,IACX,IAAI,EAAE,IAAI,EACV,GAAG,EAAE,GAAG,EACR,SAAS,EAAE,SAAS,EACpB,OAAO,EAAE,OAAO,GAChB,CACH,CAAC;IACJ,CAAC;IACD,OAAO,KAAC,WAAW,IAAC,IAAI,EAAE,IAAI,EAAE,SAAS,EAAE,SAAS,EAAE,OAAO,EAAE,OAAO,GAAI,CAAC;AAC7E,CAAC;AAED,SAAS,kBAAkB,CACzB,KAA6B,EAC7B,GAAuB;IAEvB,MAAM,QAAQ,GACZ,KAAK,IAAI,KAAK,KAAK,MAAM,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,WAAW,IAAI,MAAM,CAAC,CAAC;IAClE,OAAO,QAAQ,KAAK,MAAM,CAAC;AAC7B,CAAC;AAED,gFAAgF;AAChF,gFAAgF;AAChF,gFAAgF;AAEhF,kDAAkD;AAClD,MAAM,UAAU,cAAc,CAAC,EAC7B,IAAI,EACJ,OAAO,EACP,KAAK,EACL,OAAO,EACP,GAAG,EACH,cAAc,GACgB;IAC9B,OAAO,CACL,sBACM,iBAAiB,EACrB,SAAS,EAAC,kCAAkC,mBAC7B,OAAO,aAErB,KAAK,IAAI,cAAK,SAAS,EAAC,iCAAiC,YAAE,KAAK,GAAO,EACxE,KAAC,oBAAoB,IAAC,IAAI,EAAE,IAAI,EAAE,GAAG,EAAE,GAAG,EAAE,OAAO,EAAE,cAAc,GAAI,EACtE,OAAO,IAAI,YAAG,SAAS,EAAC,sBAAsB,YAAE,OAAO,GAAK,IACrD,CACX,CAAC;AACJ,CAAC;AAED;;;;;;GAMG;AACH,MAAM,UAAU,eAAe,CAAC,EAAE,IAAI,EAAE,GAAG,EAAiC;IAC1E,OAAO,KAAC,oBAAoB,IAAC,IAAI,EAAE,IAAI,EAAE,GAAG,EAAE,GAAG,GAAI,CAAC;AACxD,CAAC;AAED,oFAAoF;AACpF,MAAM,CAAC,MAAM,cAAc,GAAG,WAAW,CAAgB;IACvD,IAAI,EAAE,WAAW;IACjB,MAAM,EAAE,eAAe;IACvB,GAAG,EAAE,YAAY;IACjB,IAAI,EAAE,cAAc;IACpB,IAAI,EAAE,eAAe;IACrB,SAAS,EAAE,CAAC,OAAO,CAAC;IACpB,WAAW,EAAE,QAAQ;IACrB,KAAK,EAAE,WAAW;IAClB,WAAW,EACT,4JAA4J;IAC9J,8EAA8E;IAC9E,2EAA2E;IAC3E,KAAK,EAAE,GAAG,EAAE,CAAC,CAAC,EAAE,OAAO,EAAE,SAAS,EAAE,MAAM,EAAE,EAAE,EAAE,CAAC;CAClD,CAAC,CAAC","sourcesContent":["import { IconPencil } from \"@tabler/icons-react\";\nimport {\n  useEffect,\n  useId,\n  useMemo,\n  useRef,\n  useState,\n  type ReactNode,\n} from \"react\";\n\nimport { ltrCodeBlockProps } from \"../code-block-direction.js\";\nimport { defineBlock } from \"../types.js\";\nimport type {\n  BlockReadProps,\n  BlockEditProps,\n  BlockRenderContext,\n} from \"../types.js\";\nimport { useBlockCopy } from \"./block-copy.js\";\nimport {\n  sanitizeWireframeCss,\n  sanitizeWireframeHtml,\n  scopeDesignCss,\n} from \"./sanitize-html.js\";\nimport { renderWireframeIconHtml } from \"./wireframe-icons.js\";\nimport {\n  HTML_ROUGH_SELECTOR,\n  KitConfigContext,\n  RoughOverlay,\n  Screen,\n  renderNodes,\n  toggleWireframeStyle,\n  useIsDark,\n  useWireframeStyle,\n} from \"./wireframe-kit.js\";\nimport {\n  wireframeSchema,\n  wireframeMdx,\n  type WireframeData,\n  type WireframeSurface,\n} from \"./wireframe.config.js\";\n\n/**\n * Shared `wireframe` block — a hand-drawn low-fi mockup of one screen, rendered\n * from either a declarative kit tree (`data.screen`) or a self-contained HTML\n * mockup (`data.html`), inside a surface-locked frame (desktop/mobile/popover/\n * panel/browser) with a rough.js sketch overlay. Lives in core so any app can\n * register it (it originated in the plan template).\n *\n * DECOUPLING from the plan original:\n * - Theme: `useIsDark()` reads `document.documentElement.classList` instead of\n *   `next-themes` (the MermaidBlock precedent), so core stays dependency-light.\n * - HTML sanitize: the HTML path runs `data.html`/`data.css` through the\n *   app-injected `ctx.sanitizeHtml`. If no sanitizer is wired the HTML path is\n *   skipped (kit tree or an empty frame renders) — core never injects unsanitized\n *   author HTML.\n * - The plan-only prototype runtime, design-element selection, and legacy region\n *   fallback are intentionally NOT ported; those are plan-canvas features, not\n *   part of the document-block render. The kit element vocabulary, the `--wf-*`\n *   token contract, and the `.plan-wf` / `.wf-*` / `[data-rough]` classes the\n *   overlay measures are preserved exactly.\n *\n * The section carries the app-neutral `an-block` class plus the legacy\n * `plan-block` class so plan renders byte-identically while any other app gets\n * the theme-token treatment from core's `blocks.css`.\n *\n * The wireframe is canvas / agent-patch edited (node-addressable content patches\n * applied server-side), NOT schema-form edited in the browser — so `Edit` reuses\n * the same static render as `Read`, mirroring the plan `WireframeEditor`.\n */\n\ntype SurfacePreset = {\n  width: number;\n  /**\n   * Floor height for the surface. The frame is AUTO-HEIGHT (content-driven): it\n   * grows past this when content is tall and shrinks toward its content height\n   * when content is short, but never collapses below this floor — so an empty or\n   * near-empty frame still reads as that surface instead of a thin sliver. This\n   * is a `min-height`, not a fixed `height`: it is the lower bound the old fixed\n   * preset height used to also be the UPPER bound, which is what left a big empty\n   * vertical band below short content (e.g. a header + one dropdown padded to a\n   * tall fixed aspect).\n   */\n  minHeight: number;\n  radius: number;\n};\n\nconst SURFACE_PRESETS: Record<WireframeSurface, SurfacePreset> = {\n  // mobile keeps a tall floor: a phone frame reads as a phone even when short.\n  mobile: { width: 300, minHeight: 360, radius: 30 },\n  desktop: { width: 840, minHeight: 200, radius: 14 },\n  browser: { width: 900, minHeight: 200, radius: 14 },\n  popover: { width: 360, minHeight: 120, radius: 16 },\n  panel: { width: 420, minHeight: 200, radius: 16 },\n};\n\nfunction isHtmlData(data: WireframeData): boolean {\n  return typeof data.html === \"string\" && data.html.trim().length > 0;\n}\n\n/* -------------------------------------------------------------------------- */\n/* Shared frame shell: surface-locked WIDTH + auto (content-driven) height +   */\n/* theme + rough overlay. The frame keeps each surface's footprint and chrome  */\n/* but fits its content height instead of padding to a fixed aspect, so short  */\n/* content yields a short frame and tall content grows. Pass `canvasSize` to   */\n/* opt a fixed-aspect canvas artboard back into a hard pixel height.           */\n/* -------------------------------------------------------------------------- */\n\nfunction ArtboardFrame({\n  surface,\n  compact,\n  canvasSize,\n  canvasWidth,\n  skeleton,\n  renderMode,\n  roughOverlay = true,\n  showFrame = true,\n  selector,\n  caption,\n  render,\n}: {\n  surface: WireframeSurface;\n  compact?: boolean;\n  /**\n   * Force a FIXED pixel height instead of the auto-height (content-driven)\n   * default. Reserved for fixed-aspect canvas artboards (pan/zoom). Document-flow\n   * wireframes — what recaps render — leave this unset so the frame fits content.\n   */\n  canvasSize?: number;\n  canvasWidth?: number;\n  skeleton?: boolean;\n  renderMode?: \"wireframe\" | \"design\";\n  roughOverlay?: boolean;\n  showFrame?: boolean;\n  selector: string;\n  caption?: string;\n  render: (ctx: {\n    theme: \"light\" | \"dark\";\n    style: \"sketchy\" | \"clean\";\n  }) => ReactNode;\n}) {\n  const ref = useRef<HTMLDivElement>(null);\n  const fitRef = useRef<HTMLDivElement>(null);\n  const isDark = useIsDark();\n  const theme: \"light\" | \"dark\" = isDark ? \"dark\" : \"light\";\n  const preferredStyle = useWireframeStyle();\n  const preset = SURFACE_PRESETS[surface] ?? SURFACE_PRESETS.desktop;\n  const width = canvasWidth ?? preset.width;\n  // AUTO-HEIGHT: with no explicit `canvasSize` the artboard height is driven by\n  // its content (`height: auto`), floored at the surface's `minHeight` so a short\n  // screen produces a short frame and a tall screen grows — instead of every\n  // surface being padded to a fixed preset height that left a big empty band\n  // below short content. A `canvasSize` (fixed-aspect canvas artboard) overrides\n  // this with a hard pixel height.\n  const fixedHeight = canvasSize;\n  const minHeight = fixedHeight ?? preset.minHeight;\n  const baseScale = compact ? Math.min(1, 320 / preset.width) : 1;\n  const maxFrameWidth = compact ? preset.width * baseScale : width;\n  const [fitScale, setFitScale] = useState(baseScale);\n  // The scaled artboard is `transform: scale()`-ed, which does not change its\n  // layout box, so the wrapper that reserves vertical space must track the\n  // artboard's ACTUAL rendered height. With a fixed height that's known up front;\n  // with auto-height we measure it.\n  const [measuredHeight, setMeasuredHeight] = useState<number | null>(\n    fixedHeight ?? null,\n  );\n  const designMode = renderMode === \"design\";\n  const style = designMode ? \"clean\" : preferredStyle;\n  const sketchy = !designMode && style === \"sketchy\" && !skeleton;\n  const roughEnabled = sketchy && roughOverlay;\n  const frameBorder = skeleton\n    ? \"var(--plan-placeholder-line, var(--plan-line, hsl(var(--border))))\"\n    : \"var(--plan-line, hsl(var(--border)))\";\n\n  useEffect(() => {\n    const element = fitRef.current;\n    if (!element) return;\n    const measure = () => {\n      const availableWidth = element.clientWidth;\n      const nextScale =\n        availableWidth > 0\n          ? Math.min(baseScale, availableWidth / width)\n          : baseScale;\n      setFitScale((current) =>\n        Math.abs(current - nextScale) < 0.001 ? current : nextScale,\n      );\n    };\n    measure();\n    const observer = new ResizeObserver(measure);\n    observer.observe(element);\n    return () => observer.disconnect();\n  }, [baseScale, width]);\n\n  // Track the auto-height artboard's rendered height so the (un-transformed)\n  // wrapper reserves exactly the scaled space the frame occupies. Skipped when a\n  // fixed height is supplied — there's nothing to measure.\n  useEffect(() => {\n    if (fixedHeight != null) return;\n    const element = ref.current;\n    if (!element) return;\n    const measure = () => {\n      const next = element.offsetHeight;\n      setMeasuredHeight((current) =>\n        current != null && Math.abs(current - next) < 0.5 ? current : next,\n      );\n    };\n    measure();\n    const observer = new ResizeObserver(measure);\n    observer.observe(element);\n    return () => observer.disconnect();\n  }, [fixedHeight]);\n\n  // Height the wrapper reserves: the measured (or fixed) artboard height scaled\n  // by the fit factor. Falls back to the surface floor before the first measure\n  // so SSR / first paint reserves a sensible box rather than collapsing.\n  const reservedHeight = (measuredHeight ?? minHeight) * fitScale;\n  const reserveScaledHeight = fixedHeight != null || fitScale !== 1;\n\n  return (\n    <div\n      ref={fitRef}\n      className=\"plan-kit-wireframe\"\n      style={{\n        width: \"100%\",\n        maxWidth: maxFrameWidth,\n      }}\n    >\n      <div\n        className=\"group/wireframe-artboard relative\"\n        style={{\n          width: \"100%\",\n          maxWidth: maxFrameWidth,\n          ...(reserveScaledHeight ? { height: reservedHeight } : {}),\n          marginInline: \"auto\",\n        }}\n      >\n        <div\n          ref={ref}\n          className=\"plan-kit-artboard relative\"\n          data-rough-scope=\"wireframe\"\n          data-frame={showFrame ? \"show\" : \"hide\"}\n          style={{\n            width,\n            // Auto-height by default (content-driven, floored at `minHeight`);\n            // a fixed `canvasSize` locks the height for canvas artboards.\n            ...(fixedHeight != null ? { height: fixedHeight } : { minHeight }),\n            borderRadius: preset.radius,\n            ...(fitScale !== 1\n              ? {\n                  transform: `scale(${fitScale})`,\n                  transformOrigin: \"top left\",\n                }\n              : {}),\n          }}\n        >\n          {/* Content drives the artboard height in flow when auto-height; for a\n              fixed height it's pinned to the box. Rounded corners clip overflow\n              either way. */}\n          <div\n            className=\"overflow-hidden\"\n            style={{\n              borderRadius: preset.radius,\n              ...(fixedHeight != null\n                ? { position: \"absolute\", inset: 0 }\n                : { minHeight }),\n            }}\n          >\n            {render({ theme, style })}\n          </div>\n          {!roughEnabled && showFrame && (\n            <div\n              className=\"pointer-events-none absolute inset-0\"\n              style={{\n                borderRadius: preset.radius,\n                border: `1.5px solid ${frameBorder}`,\n              }}\n            />\n          )}\n          <RoughOverlay\n            scopeRef={ref}\n            enabled={roughEnabled}\n            drawFrame={showFrame}\n            frameRadius={preset.radius}\n            selector={selector}\n          />\n        </div>\n        {!designMode && !skeleton && <WireframeStyleToggleButton />}\n      </div>\n      {caption && (\n        <p className=\"mt-2 text-center text-xs text-plan-muted\">{caption}</p>\n      )}\n    </div>\n  );\n}\n\nfunction WireframeStyleToggleButton() {\n  const style = useWireframeStyle();\n  const copy = useBlockCopy();\n  const nextStyle = style === \"sketchy\" ? \"clean\" : \"sketchy\";\n  const label = nextStyle === \"clean\" ? copy.clean : copy.sketchy;\n  const description = copy.switchVisualStyle.replace(\n    \"{{style}}\",\n    label.toLocaleLowerCase(),\n  );\n\n  return (\n    <button\n      type=\"button\"\n      data-plan-interactive\n      data-rough=\"none\"\n      data-wireframe-style-toggle\n      aria-label={description}\n      title={description}\n      onClick={(event) => {\n        event.stopPropagation();\n        toggleWireframeStyle();\n      }}\n      className=\"absolute right-2 top-2 z-30 inline-flex h-7 items-center gap-1 rounded-md border border-border/60 bg-background px-2 text-xs font-medium text-muted-foreground opacity-0 shadow-sm transition-[color,opacity] hover:text-foreground focus-visible:opacity-100 focus-visible:outline-none focus-visible:ring-1 focus-visible:ring-ring group-hover/wireframe-artboard:opacity-100\"\n    >\n      <IconPencil className=\"size-3.5\" aria-hidden=\"true\" />\n      <span>{label}</span>\n    </button>\n  );\n}\n\n/* -------------------------------------------------------------------------- */\n/* HTML artboard — author HTML, themed + roughened by the renderer.           */\n/* -------------------------------------------------------------------------- */\n\nfunction HtmlArtboard({\n  data,\n  ctx: _ctx,\n  showFrame,\n  compact,\n}: {\n  data: WireframeData;\n  ctx: BlockRenderContext;\n  showFrame: boolean;\n  compact?: boolean;\n}) {\n  const renderMode = data.renderMode ?? \"wireframe\";\n  const designMode = renderMode === \"design\";\n  // Sanitize author HTML/CSS at the render point (defense-in-depth against stored\n  // XSS). Self-contained in core via the shared block sanitizer (DOM-based in the\n  // browser, regex fallback on the server) so the HTML mockup path renders in any\n  // app without the host wiring a sanitizer hook.\n  const safeHtml = useMemo(\n    () =>\n      renderWireframeIconHtml(\n        sanitizeWireframeHtml(data.html, {\n          preserveThemeClasses: designMode,\n        }),\n      ),\n    [data.html, designMode],\n  );\n  const scopeId = useId().replace(/[^a-zA-Z0-9_-]/g, \"\");\n  const scopedCss = useMemo(() => {\n    const safeCss = sanitizeWireframeCss(data.css);\n    // Scope every author selector under this instance's artboard so global\n    // selectors (body, *, .app-shell, :root) can't restyle/hide the host app.\n    return safeCss\n      ? scopeDesignCss(safeCss, `[data-plan-design-scope=\"${scopeId}\"]`)\n      : \"\";\n  }, [data.css, scopeId]);\n\n  return (\n    <ArtboardFrame\n      surface={data.surface}\n      compact={compact}\n      skeleton={data.skeleton}\n      renderMode={renderMode}\n      showFrame={showFrame}\n      selector={HTML_ROUGH_SELECTOR}\n      caption={data.caption}\n      render={({ theme, style }) => (\n        <div\n          className=\"plan-html-frame\"\n          data-theme={theme}\n          data-style={style}\n          data-frame={showFrame ? \"show\" : \"hide\"}\n          data-render-mode={renderMode}\n          data-plan-design-scope={scopeId}\n          data-skeleton={data.skeleton ? \"true\" : undefined}\n        >\n          {scopedCss && <style>{scopedCss}</style>}\n          <div\n            className=\"plan-html-frame-content\"\n            dangerouslySetInnerHTML={{ __html: safeHtml }}\n          />\n        </div>\n      )}\n    />\n  );\n}\n\n/* -------------------------------------------------------------------------- */\n/* Kit artboard — declarative kit tree.                                       */\n/* -------------------------------------------------------------------------- */\n\nfunction KitArtboard({\n  data,\n  showFrame,\n  compact,\n}: {\n  data: WireframeData;\n  showFrame: boolean;\n  compact?: boolean;\n}) {\n  return (\n    <ArtboardFrame\n      surface={data.surface}\n      compact={compact}\n      skeleton={data.skeleton}\n      renderMode={data.renderMode}\n      showFrame={showFrame}\n      selector=\"[data-rough]\"\n      caption={data.caption}\n      render={({ theme, style }) => (\n        <KitConfigContext.Provider\n          value={{\n            skeleton: data.skeleton,\n            flushFrame: !showFrame,\n            theme,\n            style,\n          }}\n        >\n          {renderKitScreen(data.screen ?? [])}\n        </KitConfigContext.Provider>\n      )}\n    />\n  );\n}\n\nfunction renderKitScreen(\n  nodes: NonNullable<WireframeData[\"screen\"]>,\n): ReactNode {\n  if (nodes.length === 1 && nodes[0]?.el === \"screen\") {\n    return renderNodes(nodes);\n  }\n  // `minHeight` (not `height`) so the screen fills the auto-height artboard floor\n  // but grows past it when content is tall, instead of locking to a fixed box.\n  return (\n    <Screen pad=\"calc(var(--pad) * 1.35)\" style={{ minHeight: \"100%\" }}>\n      {renderNodes(nodes)}\n    </Screen>\n  );\n}\n\n/**\n * The bare wireframe surface (no block section / title). Routes to the HTML\n * mockup when `data.html` is present and a sanitizer is wired; otherwise renders\n * the kit tree.\n */\nfunction WireframeSurfaceView({\n  data,\n  ctx,\n  compact,\n}: {\n  data: WireframeData;\n  ctx: BlockRenderContext;\n  compact?: boolean;\n}) {\n  const showFrame = resolveVisualFrame(data.frame, ctx);\n  if (isHtmlData(data)) {\n    return (\n      <HtmlArtboard\n        data={data}\n        ctx={ctx}\n        showFrame={showFrame}\n        compact={compact}\n      />\n    );\n  }\n  return <KitArtboard data={data} showFrame={showFrame} compact={compact} />;\n}\n\nfunction resolveVisualFrame(\n  frame: WireframeData[\"frame\"],\n  ctx: BlockRenderContext,\n): boolean {\n  const resolved =\n    frame && frame !== \"auto\" ? frame : (ctx.visualFrame ?? \"show\");\n  return resolved !== \"hide\";\n}\n\n/* -------------------------------------------------------------------------- */\n/* Block Read / Edit                                                          */\n/* -------------------------------------------------------------------------- */\n\n/** Read-only renderer for a `wireframe` block. */\nexport function WireframeBlock({\n  data,\n  blockId,\n  title,\n  summary,\n  ctx,\n  compactVisuals,\n}: BlockReadProps<WireframeData>) {\n  return (\n    <section\n      {...ltrCodeBlockProps}\n      className=\"an-block plan-block an-wireframe\"\n      data-block-id={blockId}\n    >\n      {title && <div className=\"an-block-label plan-block-label\">{title}</div>}\n      <WireframeSurfaceView data={data} ctx={ctx} compact={compactVisuals} />\n      {summary && <p className=\"mt-5 text-plan-muted\">{summary}</p>}\n    </section>\n  );\n}\n\n/**\n * Editor for the `wireframe` block. The wireframe is canvas / agent-patch edited\n * (it never calls `onChange`), so edit mode reuses the read surface — mirroring\n * the plan `WireframeEditor`. The host document editor already wraps the registry\n * edit path in a titled section, so this renders only the surface to avoid\n * double-nesting.\n */\nexport function WireframeEditor({ data, ctx }: BlockEditProps<WireframeData>) {\n  return <WireframeSurfaceView data={data} ctx={ctx} />;\n}\n\n/** Full client spec for the shared `wireframe` block (schema + MDX + Read/Edit). */\nexport const wireframeBlock = defineBlock<WireframeData>({\n  type: \"wireframe\",\n  schema: wireframeSchema,\n  mdx: wireframeMdx,\n  Read: WireframeBlock,\n  Edit: WireframeEditor,\n  placement: [\"block\"],\n  editSurface: \"inline\",\n  label: \"Wireframe\",\n  description:\n    \"A sketch wireframe of one screen built from kit primitives (or an HTML mockup), rendered in a chosen surface frame (desktop/mobile/popover/panel/browser).\",\n  // `surface` is the only required field; `screen` defaults to []. Start on the\n  // desktop surface with an empty screen so the canvas/agent can fill it in.\n  empty: () => ({ surface: \"desktop\", screen: [] }),\n});\n"]}

package/dist/progress/routes.d.ts

@@ -15,7 +15,7 @@ export declare function createProgressHandler(): import("h3").EventHandlerWithFe
     error: string;
     ok?: undefined;
 } | {
-    ok: boolean;
     error?: undefined;
+    ok: boolean;
 }>>;
 //# sourceMappingURL=routes.d.ts.map

package/dist/server/builder-browser.d.ts

@@ -4,6 +4,7 @@ export declare const BUILDER_RELAY_PATH = "/_agent-native/builder/relay";
 export declare const BUILDER_RELAY_STATE_PARAM = "_an_relay";
 export declare const BUILDER_RELAY_SECRET_ENV = "AGENT_NATIVE_BUILDER_RELAY_SECRET";
 export declare const BUILDER_RELAY_TARGET_ORIGINS_ENV = "AGENT_NATIVE_BUILDER_RELAY_TARGET_ORIGINS";
+export declare const BUILDER_RELAY_TARGET_DOMAIN_SUFFIXES_ENV = "AGENT_NATIVE_BUILDER_RELAY_TARGET_DOMAIN_SUFFIXES";
 export declare const BUILDER_RELAY_TIMESTAMP_HEADER = "x-agent-native-relay-timestamp";
 export declare const BUILDER_RELAY_FLOW_HEADER = "x-agent-native-relay-flow";
 export declare const BUILDER_RELAY_SIGNATURE_HEADER = "x-agent-native-relay-signature";

package/dist/server/builder-browser.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"builder-browser.d.ts","sourceRoot":"","sources":["../../src/server/builder-browser.ts"],"names":[],"mappings":"AAOA,OAAO,KAAK,EAAE,OAAO,EAAE,MAAM,IAAI,CAAC;AAelC,eAAO,MAAM,qBAAqB,oCAAoC,CAAC;AACvE,eAAO,MAAM,kBAAkB,iCAAiC,CAAC;AACjE,eAAO,MAAM,yBAAyB,cAAc,CAAC;AACrD,eAAO,MAAM,wBAAwB,sCAAsC,CAAC;AAC5E,eAAO,MAAM,gCAAgC,8CACA,CAAC;AAC9C,eAAO,MAAM,8BAA8B,mCAAmC,CAAC;AAC/E,eAAO,MAAM,yBAAyB,8BAA8B,CAAC;AACrE,eAAO,MAAM,8BAA8B,mCAAmC,CAAC;AAE/E,QAAA,MAAM,qBAAqB,mCAAmC,CAAC;AAK/D,MAAM,WAAW,wBAAwB;IACvC,CAAC,EAAE,CAAC,CAAC;IACL,OAAO,EAAE,OAAO,qBAAqB,CAAC;IACtC,MAAM,EAAE,MAAM,CAAC;IACf,UAAU,EAAE,MAAM,CAAC;IACnB,YAAY,EAAE,MAAM,CAAC;IACrB,QAAQ,EAAE,MAAM,CAAC;IACjB,GAAG,EAAE,MAAM,CAAC;IACZ,GAAG,EAAE,MAAM,CAAC;CACb;AAED,MAAM,WAAW,uBAAuB;IACtC,UAAU,EAAE,MAAM,CAAC;IACnB,SAAS,EAAE,MAAM,CAAC;IAClB,MAAM,EAAE,MAAM,GAAG,IAAI,CAAC;IACtB,OAAO,EAAE,MAAM,GAAG,IAAI,CAAC;IACvB,OAAO,EAAE,MAAM,GAAG,IAAI,CAAC;IACvB,YAAY,EAAE,MAAM,GAAG,IAAI,CAAC;IAC5B,iBAAiB,EAAE,MAAM,GAAG,IAAI,CAAC;IACjC,gBAAgB,EAAE,MAAM,GAAG,IAAI,CAAC;IAChC,YAAY,EAAE,OAAO,GAAG,IAAI,CAAC;IAC7B,aAAa,EAAE,OAAO,GAAG,IAAI,CAAC;CAC/B;AAED,MAAM,WAAW,uBAAuB;IACtC,UAAU,EAAE,MAAM,CAAC;IACnB,WAAW,EAAE,uBAAuB,CAAC;CACtC;AA4CD,wBAAgB,8BAA8B,CAAC,KAAK,EAAE,MAAM,GAAG,OAAO,CAgCrE;AAED,wBAAgB,iCAAiC,CAAC,KAAK,EAAE,MAAM,GAAG,OAAO,CAkBxE;AAED,wBAAgB,4BAA4B,CAAC,KAAK,EAAE;IAClD,UAAU,EAAE,MAAM,CAAC;IACnB,YAAY,EAAE,MAAM,CAAC;IACrB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,GAAG,CAAC,EAAE,MAAM,CAAC;CACd,GAAG;IAAE,KAAK,EAAE,MAAM,CAAC;IAAC,OAAO,EAAE,wBAAwB,CAAA;CAAE,CAuBvD;AAED,wBAAgB,8BAA8B,CAC5C,KAAK,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,EAChC,OAAO,GAAE;IAAE,GAAG,CAAC,EAAE,MAAM,CAAA;CAAO,GAC7B,wBAAwB,GAAG,IAAI,CAmCjC;AAED;;;GAGG;AACH,wBAAgB,yCAAyC,CACvD,KAAK,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,EAChC,OAAO,GAAE;IAAE,GAAG,CAAC,EAAE,MAAM,CAAA;CAAO,GAC7B,wBAAwB,GAAG,IAAI,CAKjC;AAED,wBAAgB,yBAAyB,CACvC,OAAO,EAAE,wBAAwB,GAChC,MAAM,CAER;AAgBD,wBAAgB,yBAAyB,CACvC,UAAU,EAAE,MAAM,EAClB,WAAW,EAAE,uBAAuB,EACpC,OAAO,GAAE;IAAE,GAAG,CAAC,EAAE,MAAM,CAAA;CAAO,GAC7B;IAAE,IAAI,EAAE,MAAM,CAAC;IAAC,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;IAAC,GAAG,EAAE,MAAM,CAAA;CAAE,CAsBhE;AAED,wBAAgB,yBAAyB,CAAC,KAAK,EAAE;IAC/C,IAAI,EAAE,MAAM,CAAC;IACb,SAAS,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,CAAC;IACrC,MAAM,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,CAAC;IAClC,SAAS,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,CAAC;IACrC,aAAa,EAAE,MAAM,CAAC;IACtB,eAAe,EAAE,MAAM,CAAC;IACxB,GAAG,CAAC,EAAE,MAAM,CAAC;CACd,GAAG;IACF,OAAO,EAAE,wBAAwB,CAAC;IAClC,IAAI,EAAE,uBAAuB,CAAC;CAC/B,GAAG,IAAI,CA2DP;AAmBD;;;;;;;GAOG;AACH,eAAO,MAAM,mBAAmB,cAAc,CAAC;AAC/C,eAAO,MAAM,qBAAqB,gBAAgB,CAAC;AACnD,eAAO,MAAM,4BAA4B,6BAA6B,CAAC;AACvE,eAAO,MAAM,2BAA2B,iBAAiB,CAAC;AAC1D,eAAO,MAAM,+BAA+B,oBAAoB,CAAC;AACjE,eAAO,MAAM,yCAAyC,6BAC1B,CAAC;AAC7B,eAAO,MAAM,8BAA8B,mBAAmB,CAAC;AAC/D,eAAO,MAAM,mCAAmC,wBAAwB,CAAC;AAKzE,MAAM,WAAW,4BAA4B;IAC3C,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,eAAe,CAAC,EAAE,MAAM,CAAC;IACzB,wBAAwB,CAAC,EAAE,MAAM,CAAC;IAClC,cAAc,CAAC,EAAE,MAAM,CAAC;IACxB,mBAAmB,CAAC,EAAE,MAAM,CAAC;CAC9B;AAQD,wBAAgB,+BAA+B,CAC7C,MAAM,EAAE,eAAe,GACtB,4BAA4B,CAkB9B;AAED,wBAAgB,gCAAgC,CAC9C,QAAQ,EAAE,4BAA4B,GACrC,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAgBxB;AAoBD,MAAM,WAAW,oBAAoB;IACnC,UAAU,EAAE,OAAO,CAAC;IACpB,cAAc,EAAE,OAAO,CAAC;IACxB,yBAAyB,EAAE,OAAO,CAAC;IACnC,eAAe,CAAC,EAAE,MAAM,CAAC;IACzB;;;;OAIG;IACH,UAAU,EAAE,OAAO,CAAC;IACpB,gBAAgB,CAAC,EAAE,MAAM,GAAG,KAAK,GAAG,WAAW,GAAG,KAAK,CAAC;IACxD;;;;OAIG;IACH,SAAS,CAAC,EAAE;QAAE,OAAO,EAAE,MAAM,CAAC;QAAC,EAAE,EAAE,MAAM,CAAA;KAAE,CAAC;IAC5C,YAAY,CAAC,EAAE;QAAE,OAAO,EAAE,MAAM,CAAC;QAAC,EAAE,EAAE,MAAM,CAAA;KAAE,CAAC;IAC/C,OAAO,EAAE,MAAM,CAAC;IAChB,OAAO,EAAE,MAAM,CAAC;IAChB;;;;;OAKG;IACH,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,UAAU,EAAE,MAAM,CAAC;IACnB,mBAAmB,EAAE,OAAO,CAAC;IAC7B,oBAAoB,EAAE,OAAO,CAAC;IAC9B,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB;;;;;;OAMG;IACH,MAAM,CAAC,EAAE,KAAK,CAAC;QAAE,EAAE,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;IAC7C,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,iBAAiB,CAAC,EAAE,MAAM,CAAC;IAC3B,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,YAAY,CAAC,EAAE,OAAO,CAAC;IACvB,aAAa,CAAC,EAAE,OAAO,CAAC;CACzB;AAED,MAAM,WAAW,qBAAqB;IACpC,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,kBAAkB,CAAC,EAAE,MAAM,CAAC;IAC5B,gBAAgB,CAAC,EAAE,MAAM,CAAC;CAC3B;AAiED;;;;;;;;;;GAUG;AACH,wBAAgB,wBAAwB,CAAC,YAAY,EAAE,MAAM,GAAG,MAAM,CAErE;AAED;;;GAGG;AACH,wBAAgB,0BAA0B,CACxC,KAAK,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,EAChC,YAAY,EAAE,MAAM,GACnB,OAAO,CAET;AAED,wBAAgB,qCAAqC,CACnD,KAAK,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,GAC/B,MAAM,GAAG,IAAI,CAef;AAED,wBAAgB,uBAAuB,CAAC,UAAU,EAAE,MAAM,GAAG,MAAM,CAElE;AAED,wBAAgB,yBAAyB,CACvC,KAAK,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,EAChC,UAAU,EAAE,MAAM,GACjB,OAAO,CAET;AAED,wBAAgB,oCAAoC,CAClD,KAAK,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,GAC/B,MAAM,GAAG,IAAI,CAef;AAED,wBAAgB,yBAAyB,CACvC,UAAU,EAAE,MAAM,EAClB,UAAU,EAAE,MAAM,GACjB,MAAM,CAOR;AAsCD,wBAAgB,iBAAiB,IAAI,MAAM,CAM1C;AAED,wBAAgB,iBAAiB,IAAI,MAAM,CAO1C;AAUD,wBAAgB,yBAAyB,IAAI,MAAM,CAElD;AAED,wBAAgB,yBAAyB,IAAI,OAAO,CAEnD;AAED,wBAAsB,6BAA6B,IAAI,OAAO,CAAC,MAAM,CAAC,CAmBrE;AAED,wBAAsB,gCAAgC,IAAI,OAAO,CAAC,OAAO,CAAC,CAEzE;AAgDD;;;;;;;;;;GAUG;AACH,eAAO,MAAM,oBAAoB,eAAe,CAAC;AAYjD;;;;;;;;;;;GAWG;AACH,wBAAgB,sBAAsB,CACpC,cAAc,EAAE,MAAM,EACtB,KAAK,GAAE,MAAM,GAAG,IAAW,EAC3B,OAAO,GAAE;IACP,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,QAAQ,CAAC,EAAE,4BAA4B,CAAC;CACpC,GACL,MAAM,CAyDR;AAED;;;;;GAKG;AACH,wBAAgB,2BAA2B,CAAC,MAAM,EAAE,MAAM,GAAG,MAAM,CAElE;AAED,wBAAgB,mCAAmC,CACjD,MAAM,EAAE,MAAM,EACd,UAAU,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,GACpC,MAAM,CAKR;AAqFD;;;;GAIG;AACH,wBAAgB,+BAA+B,CAAC,KAAK,EAAE,OAAO,GAAG,MAAM,CAqBtE;AAED;;;;;;;GAOG;AACH,wBAAgB,uCAAuC,CACrD,KAAK,EAAE,OAAO,GACb,MAAM,CAcR;AAUD,wBAAgB,uBAAuB,CAAC,MAAM,EAAE,MAAM,GAAG,oBAAoB,CA0B5E;AASD,wBAAgB,+BAA+B,CAC7C,KAAK,EAAE,OAAO,GACb,oBAAoB,CAEtB;AAED;;;;;;GAMG;AACH,eAAO,MAAM,gBAAgB,YAC3B,qBAAqB,EACrB,oBAAoB,EACpB,iBAAiB,EACjB,kBAAkB,EAClB,kBAAkB,EAClB,sBAAsB,EACtB,4BAA4B,EAC5B,2BAA2B,EAC3B,uBAAuB,EACvB,yBAAyB,CACjB,CAAC;AAEX,MAAM,MAAM,aAAa,GAAG,CAAC,OAAO,gBAAgB,CAAC,CAAC,MAAM,CAAC,CAAC;AAE9D,wBAAgB,yBAAyB,CAAC,MAAM,EAAE;IAChD,UAAU,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAC3B,SAAS,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAC1B,MAAM,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IACvB,OAAO,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IACxB,OAAO,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IACxB,YAAY,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAC7B,iBAAiB,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAClC,gBAAgB,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IACjC,YAAY,CAAC,EAAE,OAAO,GAAG,IAAI,CAAC;IAC9B,aAAa,CAAC,EAAE,OAAO,GAAG,IAAI,CAAC;CAChC;;;IAoBA;AAED,wBAAgB,qBAAqB,CACnC,UAAU,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,EACrC,KAAK,EAAE,OAAO,GACb,MAAM,CAKR;AAED,wBAAgB,+BAA+B,CAAC,OAAO,EAAE;IACvD,KAAK,EAAE,OAAO,CAAC;IACf,YAAY,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAC7B,UAAU,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;CAC5B,GAAG,MAAM,CAST;AA6JD,wBAAgB,gCAAgC,CAC9C,UAAU,EAAE,MAAM,EAClB,IAAI,GAAE;IAAE,YAAY,CAAC,EAAE,MAAM,CAAA;CAAO,GACnC,MAAM,CAsER;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAgB,qCAAqC,CACnD,OAAO,EAAE,MAAM,EACf,IAAI,GAAE;IACJ,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,YAAY,CAAC,EAAE,MAAM,CAAC;CAClB,GACL,MAAM,CA8DR;AAED,MAAM,WAAW,mBAAmB;IAClC,MAAM,EAAE,MAAM,CAAC;IACf,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,MAAM,CAAC,EAAE,MAAM,CAAC;CACjB;AAED,MAAM,WAAW,qBAAqB;IACpC,UAAU,EAAE,MAAM,CAAC;IACnB,SAAS,EAAE,MAAM,CAAC;IAClB,GAAG,EAAE,MAAM,CAAC;IACZ,MAAM,EAAE,MAAM,CAAC;CAChB;AAiCD;;;;;;GAMG;AACH,wBAAsB,eAAe,CACnC,IAAI,EAAE,mBAAmB,GACxB,OAAO,CAAC,qBAAqB,CAAC,CAkEhC;AAED,wBAAsB,+BAA+B,CACnD,IAAI,EAAE,qBAAqB,GAC1B,OAAO,CAAC,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC,CAgDlC"}
+{"version":3,"file":"builder-browser.d.ts","sourceRoot":"","sources":["../../src/server/builder-browser.ts"],"names":[],"mappings":"AAOA,OAAO,KAAK,EAAE,OAAO,EAAE,MAAM,IAAI,CAAC;AAelC,eAAO,MAAM,qBAAqB,oCAAoC,CAAC;AACvE,eAAO,MAAM,kBAAkB,iCAAiC,CAAC;AACjE,eAAO,MAAM,yBAAyB,cAAc,CAAC;AACrD,eAAO,MAAM,wBAAwB,sCAAsC,CAAC;AAC5E,eAAO,MAAM,gCAAgC,8CACA,CAAC;AAC9C,eAAO,MAAM,wCAAwC,sDACA,CAAC;AACtD,eAAO,MAAM,8BAA8B,mCAAmC,CAAC;AAC/E,eAAO,MAAM,yBAAyB,8BAA8B,CAAC;AACrE,eAAO,MAAM,8BAA8B,mCAAmC,CAAC;AAE/E,QAAA,MAAM,qBAAqB,mCAAmC,CAAC;AAK/D,MAAM,WAAW,wBAAwB;IACvC,CAAC,EAAE,CAAC,CAAC;IACL,OAAO,EAAE,OAAO,qBAAqB,CAAC;IACtC,MAAM,EAAE,MAAM,CAAC;IACf,UAAU,EAAE,MAAM,CAAC;IACnB,YAAY,EAAE,MAAM,CAAC;IACrB,QAAQ,EAAE,MAAM,CAAC;IACjB,GAAG,EAAE,MAAM,CAAC;IACZ,GAAG,EAAE,MAAM,CAAC;CACb;AAED,MAAM,WAAW,uBAAuB;IACtC,UAAU,EAAE,MAAM,CAAC;IACnB,SAAS,EAAE,MAAM,CAAC;IAClB,MAAM,EAAE,MAAM,GAAG,IAAI,CAAC;IACtB,OAAO,EAAE,MAAM,GAAG,IAAI,CAAC;IACvB,OAAO,EAAE,MAAM,GAAG,IAAI,CAAC;IACvB,YAAY,EAAE,MAAM,GAAG,IAAI,CAAC;IAC5B,iBAAiB,EAAE,MAAM,GAAG,IAAI,CAAC;IACjC,gBAAgB,EAAE,MAAM,GAAG,IAAI,CAAC;IAChC,YAAY,EAAE,OAAO,GAAG,IAAI,CAAC;IAC7B,aAAa,EAAE,OAAO,GAAG,IAAI,CAAC;CAC/B;AAED,MAAM,WAAW,uBAAuB;IACtC,UAAU,EAAE,MAAM,CAAC;IACnB,WAAW,EAAE,uBAAuB,CAAC;CACtC;AA4CD,wBAAgB,8BAA8B,CAAC,KAAK,EAAE,MAAM,GAAG,OAAO,CAgCrE;AAED,wBAAgB,iCAAiC,CAAC,KAAK,EAAE,MAAM,GAAG,OAAO,CAsBxE;AACD,wBAAgB,4BAA4B,CAAC,KAAK,EAAE;IAClD,UAAU,EAAE,MAAM,CAAC;IACnB,YAAY,EAAE,MAAM,CAAC;IACrB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,GAAG,CAAC,EAAE,MAAM,CAAC;CACd,GAAG;IAAE,KAAK,EAAE,MAAM,CAAC;IAAC,OAAO,EAAE,wBAAwB,CAAA;CAAE,CAuBvD;AA2BD,wBAAgB,8BAA8B,CAC5C,KAAK,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,EAChC,OAAO,GAAE;IAAE,GAAG,CAAC,EAAE,MAAM,CAAA;CAAO,GAC7B,wBAAwB,GAAG,IAAI,CAmCjC;AAED;;;GAGG;AACH,wBAAgB,yCAAyC,CACvD,KAAK,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,EAChC,OAAO,GAAE;IAAE,GAAG,CAAC,EAAE,MAAM,CAAA;CAAO,GAC7B,wBAAwB,GAAG,IAAI,CAKjC;AAED,wBAAgB,yBAAyB,CACvC,OAAO,EAAE,wBAAwB,GAChC,MAAM,CAER;AAgBD,wBAAgB,yBAAyB,CACvC,UAAU,EAAE,MAAM,EAClB,WAAW,EAAE,uBAAuB,EACpC,OAAO,GAAE;IAAE,GAAG,CAAC,EAAE,MAAM,CAAA;CAAO,GAC7B;IAAE,IAAI,EAAE,MAAM,CAAC;IAAC,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;IAAC,GAAG,EAAE,MAAM,CAAA;CAAE,CAsBhE;AAED,wBAAgB,yBAAyB,CAAC,KAAK,EAAE;IAC/C,IAAI,EAAE,MAAM,CAAC;IACb,SAAS,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,CAAC;IACrC,MAAM,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,CAAC;IAClC,SAAS,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,CAAC;IACrC,aAAa,EAAE,MAAM,CAAC;IACtB,eAAe,EAAE,MAAM,CAAC;IACxB,GAAG,CAAC,EAAE,MAAM,CAAC;CACd,GAAG;IACF,OAAO,EAAE,wBAAwB,CAAC;IAClC,IAAI,EAAE,uBAAuB,CAAC;CAC/B,GAAG,IAAI,CA2DP;AAmBD;;;;;;;GAOG;AACH,eAAO,MAAM,mBAAmB,cAAc,CAAC;AAC/C,eAAO,MAAM,qBAAqB,gBAAgB,CAAC;AACnD,eAAO,MAAM,4BAA4B,6BAA6B,CAAC;AACvE,eAAO,MAAM,2BAA2B,iBAAiB,CAAC;AAC1D,eAAO,MAAM,+BAA+B,oBAAoB,CAAC;AACjE,eAAO,MAAM,yCAAyC,6BAC1B,CAAC;AAC7B,eAAO,MAAM,8BAA8B,mBAAmB,CAAC;AAC/D,eAAO,MAAM,mCAAmC,wBAAwB,CAAC;AAKzE,MAAM,WAAW,4BAA4B;IAC3C,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,eAAe,CAAC,EAAE,MAAM,CAAC;IACzB,wBAAwB,CAAC,EAAE,MAAM,CAAC;IAClC,cAAc,CAAC,EAAE,MAAM,CAAC;IACxB,mBAAmB,CAAC,EAAE,MAAM,CAAC;CAC9B;AAQD,wBAAgB,+BAA+B,CAC7C,MAAM,EAAE,eAAe,GACtB,4BAA4B,CAkB9B;AAED,wBAAgB,gCAAgC,CAC9C,QAAQ,EAAE,4BAA4B,GACrC,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAgBxB;AAoBD,MAAM,WAAW,oBAAoB;IACnC,UAAU,EAAE,OAAO,CAAC;IACpB,cAAc,EAAE,OAAO,CAAC;IACxB,yBAAyB,EAAE,OAAO,CAAC;IACnC,eAAe,CAAC,EAAE,MAAM,CAAC;IACzB;;;;OAIG;IACH,UAAU,EAAE,OAAO,CAAC;IACpB,gBAAgB,CAAC,EAAE,MAAM,GAAG,KAAK,GAAG,WAAW,GAAG,KAAK,CAAC;IACxD;;;;OAIG;IACH,SAAS,CAAC,EAAE;QAAE,OAAO,EAAE,MAAM,CAAC;QAAC,EAAE,EAAE,MAAM,CAAA;KAAE,CAAC;IAC5C,YAAY,CAAC,EAAE;QAAE,OAAO,EAAE,MAAM,CAAC;QAAC,EAAE,EAAE,MAAM,CAAA;KAAE,CAAC;IAC/C,OAAO,EAAE,MAAM,CAAC;IAChB,OAAO,EAAE,MAAM,CAAC;IAChB;;;;;OAKG;IACH,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,UAAU,EAAE,MAAM,CAAC;IACnB,mBAAmB,EAAE,OAAO,CAAC;IAC7B,oBAAoB,EAAE,OAAO,CAAC;IAC9B,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB;;;;;;OAMG;IACH,MAAM,CAAC,EAAE,KAAK,CAAC;QAAE,EAAE,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;IAC7C,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,iBAAiB,CAAC,EAAE,MAAM,CAAC;IAC3B,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,YAAY,CAAC,EAAE,OAAO,CAAC;IACvB,aAAa,CAAC,EAAE,OAAO,CAAC;CACzB;AAED,MAAM,WAAW,qBAAqB;IACpC,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,kBAAkB,CAAC,EAAE,MAAM,CAAC;IAC5B,gBAAgB,CAAC,EAAE,MAAM,CAAC;CAC3B;AAiED;;;;;;;;;;GAUG;AACH,wBAAgB,wBAAwB,CAAC,YAAY,EAAE,MAAM,GAAG,MAAM,CAErE;AAED;;;GAGG;AACH,wBAAgB,0BAA0B,CACxC,KAAK,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,EAChC,YAAY,EAAE,MAAM,GACnB,OAAO,CAET;AAED,wBAAgB,qCAAqC,CACnD,KAAK,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,GAC/B,MAAM,GAAG,IAAI,CAef;AAED,wBAAgB,uBAAuB,CAAC,UAAU,EAAE,MAAM,GAAG,MAAM,CAElE;AAED,wBAAgB,yBAAyB,CACvC,KAAK,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,EAChC,UAAU,EAAE,MAAM,GACjB,OAAO,CAET;AAED,wBAAgB,oCAAoC,CAClD,KAAK,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,GAC/B,MAAM,GAAG,IAAI,CAef;AAED,wBAAgB,yBAAyB,CACvC,UAAU,EAAE,MAAM,EAClB,UAAU,EAAE,MAAM,GACjB,MAAM,CAOR;AAsCD,wBAAgB,iBAAiB,IAAI,MAAM,CAM1C;AAED,wBAAgB,iBAAiB,IAAI,MAAM,CAO1C;AAUD,wBAAgB,yBAAyB,IAAI,MAAM,CAElD;AAED,wBAAgB,yBAAyB,IAAI,OAAO,CAEnD;AAED,wBAAsB,6BAA6B,IAAI,OAAO,CAAC,MAAM,CAAC,CAmBrE;AAED,wBAAsB,gCAAgC,IAAI,OAAO,CAAC,OAAO,CAAC,CAEzE;AAgDD;;;;;;;;;;GAUG;AACH,eAAO,MAAM,oBAAoB,eAAe,CAAC;AAYjD;;;;;;;;;;;GAWG;AACH,wBAAgB,sBAAsB,CACpC,cAAc,EAAE,MAAM,EACtB,KAAK,GAAE,MAAM,GAAG,IAAW,EAC3B,OAAO,GAAE;IACP,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,QAAQ,CAAC,EAAE,4BAA4B,CAAC;CACpC,GACL,MAAM,CAyDR;AAED;;;;;GAKG;AACH,wBAAgB,2BAA2B,CAAC,MAAM,EAAE,MAAM,GAAG,MAAM,CAElE;AAED,wBAAgB,mCAAmC,CACjD,MAAM,EAAE,MAAM,EACd,UAAU,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,GACpC,MAAM,CAKR;AAqFD;;;;GAIG;AACH,wBAAgB,+BAA+B,CAAC,KAAK,EAAE,OAAO,GAAG,MAAM,CAqBtE;AAED;;;;;;;GAOG;AACH,wBAAgB,uCAAuC,CACrD,KAAK,EAAE,OAAO,GACb,MAAM,CAcR;AAUD,wBAAgB,uBAAuB,CAAC,MAAM,EAAE,MAAM,GAAG,oBAAoB,CA0B5E;AASD,wBAAgB,+BAA+B,CAC7C,KAAK,EAAE,OAAO,GACb,oBAAoB,CAEtB;AAED;;;;;;GAMG;AACH,eAAO,MAAM,gBAAgB,YAC3B,qBAAqB,EACrB,oBAAoB,EACpB,iBAAiB,EACjB,kBAAkB,EAClB,kBAAkB,EAClB,sBAAsB,EACtB,4BAA4B,EAC5B,2BAA2B,EAC3B,uBAAuB,EACvB,yBAAyB,CACjB,CAAC;AAEX,MAAM,MAAM,aAAa,GAAG,CAAC,OAAO,gBAAgB,CAAC,CAAC,MAAM,CAAC,CAAC;AAE9D,wBAAgB,yBAAyB,CAAC,MAAM,EAAE;IAChD,UAAU,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAC3B,SAAS,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAC1B,MAAM,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IACvB,OAAO,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IACxB,OAAO,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IACxB,YAAY,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAC7B,iBAAiB,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAClC,gBAAgB,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IACjC,YAAY,CAAC,EAAE,OAAO,GAAG,IAAI,CAAC;IAC9B,aAAa,CAAC,EAAE,OAAO,GAAG,IAAI,CAAC;CAChC;;;IAoBA;AAED,wBAAgB,qBAAqB,CACnC,UAAU,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,EACrC,KAAK,EAAE,OAAO,GACb,MAAM,CAKR;AAED,wBAAgB,+BAA+B,CAAC,OAAO,EAAE;IACvD,KAAK,EAAE,OAAO,CAAC;IACf,YAAY,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAC7B,UAAU,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;CAC5B,GAAG,MAAM,CAST;AA6JD,wBAAgB,gCAAgC,CAC9C,UAAU,EAAE,MAAM,EAClB,IAAI,GAAE;IAAE,YAAY,CAAC,EAAE,MAAM,CAAA;CAAO,GACnC,MAAM,CAsER;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAgB,qCAAqC,CACnD,OAAO,EAAE,MAAM,EACf,IAAI,GAAE;IACJ,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,YAAY,CAAC,EAAE,MAAM,CAAC;CAClB,GACL,MAAM,CA8DR;AAED,MAAM,WAAW,mBAAmB;IAClC,MAAM,EAAE,MAAM,CAAC;IACf,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,MAAM,CAAC,EAAE,MAAM,CAAC;CACjB;AAED,MAAM,WAAW,qBAAqB;IACpC,UAAU,EAAE,MAAM,CAAC;IACnB,SAAS,EAAE,MAAM,CAAC;IAClB,GAAG,EAAE,MAAM,CAAC;IACZ,MAAM,EAAE,MAAM,CAAC;CAChB;AAiCD;;;;;;GAMG;AACH,wBAAsB,eAAe,CACnC,IAAI,EAAE,mBAAmB,GACxB,OAAO,CAAC,qBAAqB,CAAC,CAkEhC;AAED,wBAAsB,+BAA+B,CACnD,IAAI,EAAE,qBAAqB,GAC1B,OAAO,CAAC,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC,CAgDlC"}