{"version":3,"file":"a2ui-prompts.cjs","names":[],"sources":["../src/a2ui-prompts.ts"],"sourcesContent":["/**\n * Default A2UI generation and design guideline prompts.\n *\n * These are the canonical prompt fragments that instruct an LLM how to call\n * the render_a2ui tool, how to bind data, and how to style surfaces.\n */\n\n/**\n * Generation guidelines — protocol rules, tool arguments, path rules,\n * data model format, and form/two-way-binding instructions.\n */\nexport const A2UI_DEFAULT_GENERATION_GUIDELINES = `\\\nGenerate A2UI v0.9 JSON.\n\n## A2UI Protocol Instructions\n\nA2UI (Agent to UI) is a protocol for rendering rich UI surfaces from agent responses.\n\nCRITICAL: You MUST call the render_a2ui tool with ALL of these arguments:\n- surfaceId: A unique ID for the surface (e.g. \"product-comparison\")\n- components: REQUIRED — the A2UI component array. NEVER omit this. Only use\n  components listed in the Available Components schema provided as context.\n- data: OPTIONAL — a JSON object written to the root of the surface data model.\n  Use for pre-filling form values or providing data for path-bound components.\n- every component must have the \"component\" field specifying the component type.\n  ONLY use component names from the Available Components schema — do NOT invent\n  component names or use names not in the schema.\n\nCOMPONENT ID RULES:\n- Every component ID must be unique within the surface.\n- A component MUST NOT reference itself as child/children. This causes a\n  circular dependency error. For example, if a component has id=\"avatar\",\n  its child must be a DIFFERENT id (e.g. \"avatar-img\"), never \"avatar\".\n- The child/children tree must be a DAG — no cycles allowed.\n\nREPEATING CONTENT (TEMPLATES):\nTo repeat a component for each item in an array, use the structural children format:\n  children: { componentId: \"card-id\", path: \"/items\" }\nThis tells the renderer to create one instance of \"card-id\" per item in the \"/items\" array.\n\nPATH RULES FOR TEMPLATES:\nComponents inside a repeating template use RELATIVE paths (no leading slash).\nThe path is resolved relative to each array item automatically.\nIf a container has children: { componentId: \"card\", path: \"/items\" } and each item\nhas a key \"name\", use { \"path\": \"name\" } (NO leading slash — relative to item).\nCRITICAL: Do NOT use \"/name\" (absolute) inside templates — use \"name\" (relative).\nThe container's path (\"/items\") uses a leading slash (absolute), but all\ncomponents INSIDE the template use paths WITHOUT leading slash.\n\nDATA MODEL:\nThe \"data\" key in the tool args is a plain JSON object that initializes the surface\ndata model. Components bound to paths (e.g. \"value\": { \"path\": \"/form/name\" })\nread from and write to this data model. Examples:\n  For forms:  \"data\": { \"form\": { \"name\": \"Alice\", \"email\": \"\" } }\n  For lists:  \"data\": { \"items\": [{\"name\": \"Product A\"}, {\"name\": \"Product B\"}] }\n  For mixed:  \"data\": { \"form\": { \"query\": \"\" }, \"results\": [...] }\n\nFORMS AND TWO-WAY DATA BINDING:\nTo create editable forms, bind input components to data model paths using { \"path\": \"...\" }.\nThe client automatically writes user input back to the data model at the bound path.\nCRITICAL: Using a literal value (e.g. \"value\": \"\") makes the field READ-ONLY.\nYou MUST use { \"path\": \"...\" } to make inputs editable.\n\nInput components use \"value\" as the binding property:\n  \"value\": { \"path\": \"/form/fieldName\" }\n\nTo retrieve form values when a button is clicked, include \"context\" with path references\nin the button's action. Paths are resolved to their current values at click time:\n  \"action\": { \"event\": { \"name\": \"submit\", \"context\": { \"userName\": { \"path\": \"/form/name\" } } } }\n\nTo pre-fill form values, pass initial data via the \"data\" tool argument:\n  \"data\": { \"form\": { \"name\": \"Markus\" } }`;\n\n/**\n * Design guidelines — visual design rules, component hierarchy tips,\n * and action handler patterns.\n */\nexport const A2UI_DEFAULT_DESIGN_GUIDELINES = `\\\nCreate polished, visually appealing interfaces. ONLY use components listed in the\nAvailable Components schema — do NOT use component names that are not in the schema.\n\nDesign principles:\n- Create clear visual hierarchy within cards and layouts.\n- Keep cards clean — avoid clutter. Whitespace is good.\n- Use consistent surfaceIds (lowercase, hyphenated).\n- NEVER use the same ID for a component and its child — this creates a\n  circular dependency. E.g. if id=\"avatar\", child must NOT be \"avatar\".\n- For side-by-side comparisons, use a container with structural children\n  (children: { componentId, path }) to repeat a card template per data item.\n- Include images when relevant (logos, icons, product photos):\n  - Prefer company logos via Google favicons: https://www.google.com/s2/favicons?domain=example.com&sz=128\n  - Do NOT invent Unsplash photo-IDs — they will 404. Only use real, known URLs.\n- For buttons: action MUST use this exact nested format:\n    \"action\": { \"event\": { \"name\": \"myAction\", \"context\": { \"key\": \"value\" } } }\n  The \"event\" key holds an OBJECT with \"name\" (required) and \"context\" (optional).\n  Do NOT use a flat format like {\"event\": \"name\"} — \"event\" must be an object.\n- For forms: every input MUST use path binding on the \"value\" property\n  (e.g. \"value\": { \"path\": \"/form/name\" }) to be editable. The submit button's\n  action context MUST reference the same paths to capture the user's input.\n\nUse the SAME surfaceId as the main surface. Match action names to button action event names.`;\n"],"mappings":";;;;;;;;;;;;AAWA,MAAa,qCAAqC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAkElD,MAAa,iCAAiC"}