diff --git a/.prettierrc b/.prettierrc index 5d5516ef2..186d4b19f 100644 --- a/.prettierrc +++ b/.prettierrc @@ -19,6 +19,13 @@ "options": { "singleQuote": false } + }, + { + "files": "docs/**/*.md", + "options": { + "embeddedLanguageFormatting": "off", + "tabWidth": 4 + } } ] } diff --git a/docs/concepts/catalogs.md b/docs/concepts/catalogs.md index c214737ee..607e280ed 100644 --- a/docs/concepts/catalogs.md +++ b/docs/concepts/catalogs.md @@ -366,18 +366,18 @@ While standard JSON parsers ignore unknown fields, dropping a component in a Ser - **Breaking Changes (Major Version Bump Required)** Any change that alters structure in a way that cannot be safely ignored by older clients incrementing the **Major** version in the `catalogId` URI (e.g., `v1` to `v2`). - - **Adding a container component:** e.g., adding a `Grid` or `Accordion` component. If an older client ignores a container, it will drop all of its children, breaking the UI tree. - - **Removing a container component:** e.g., removing a `Grid` or `Accordion` component. If an older agent uses the container it would be ignored by the client, and the client would drop all of its children, breaking the UI tree. - - **Changing field types:** e.g., changing a property from a `string` to an `object`. This will fail JSON Schema validation on older clients. - - **Adding a required property:** without a default value, as older agents won't know to send it. + - **Adding a container component:** e.g., adding a `Grid` or `Accordion` component. If an older client ignores a container, it will drop all of its children, breaking the UI tree. + - **Removing a container component:** e.g., removing a `Grid` or `Accordion` component. If an older agent uses the container it would be ignored by the client, and the client would drop all of its children, breaking the UI tree. + - **Changing field types:** e.g., changing a property from a `string` to an `object`. This will fail JSON Schema validation on older clients. + - **Adding a required property:** without a default value, as older agents won't know to send it. - **Non-Breaking Changes (Allowable under Major Version)** Changes that can be safely ignored or degrade gracefully without breaking the layout or data model can stay at the current version. - - **Adding a leaf component (non-container):** e.g., adding `Badge` or `Tooltip`. If ignored, the layout remains intact. - - **Adding an optional property:** e.g., adding `subtitle` to a Card. - - **Removing a property:** Safe for the client to ignore if the agent stops sending it. - - **Adding new functions or styles:** These can generally be ignored without changing the semantic meaning of the component. - - **Metadata Changes:** Updating `description` fields or fixing typos in docs requires no version bump and has no impact on runtime. + - **Adding a leaf component (non-container):** e.g., adding `Badge` or `Tooltip`. If ignored, the layout remains intact. + - **Adding an optional property:** e.g., adding `subtitle` to a Card. + - **Removing a property:** Safe for the client to ignore if the agent stops sending it. + - **Adding new functions or styles:** These can generally be ignored without changing the semantic meaning of the component. + - **Metadata Changes:** Updating `description` fields or fixing typos in docs requires no version bump and has no impact on runtime. ### Graceful Degradation @@ -388,14 +388,14 @@ While standard JSON parsers ignore unknown fields, dropping a component in a Ser Here is how catalog version mismatches are handled in practice: - **An old iOS client is using an older catalog than the agent** - - The agent sends a new component `Badge` that the old iOS client doesn't know about. The client renders a generic textbox placeholder or safe text description for it, keeping the rest of the interface functional. - - The agent sends a new property `badge` on a `Button` that an old client doesn't know about. The client safely ignores it and renders the basic button. - - The agent no longer sends the `Facepile` component that was removed in a later catalog version. This causes no issues for the client. + - The agent sends a new component `Badge` that the old iOS client doesn't know about. The client renders a generic textbox placeholder or safe text description for it, keeping the rest of the interface functional. + - The agent sends a new property `badge` on a `Button` that an old client doesn't know about. The client safely ignores it and renders the standard button. + - The agent no longer sends the `Facepile` component that was removed in a later catalog version. This causes no issues for the client. - **A web client rolls out a new catalog version ahead of the agent** - - The web client supports the new `Badge` component, but the agent doesn't know about it yet. - - The web client removed the `badge` property on `Button`, so it ignores it if the agent sends it. - - The web client added new styles for `Button` that the agent doesn't know about. Again this causes no issues as the agent doesn't use them. + - The web client supports the new `Badge` component, but the agent doesn't know about it yet. + - The web client removed the `badge` property on `Button`, so it ignores it if the agent sends it. + - The web client added new styles for `Button` that the agent doesn't know about. Again this causes no issues as the agent doesn't use them. ### Versioning with CatalogId @@ -423,11 +423,11 @@ To ensure a stable user experience, A2UI employs a two-phase validation strategy ### Two-Phase Validation 1. **Agent-Side (Pre-Send):** Before transmitting any UI payload, the agent runtime validates the generated JSON against the catalog definition. - - Purpose: To catch hallucinated properties or malformed structures at the source. - - Outcome: If validation fails, the agent can attempt to fix or regenerate the A2UI JSON, or it can do graceful degradation such as falling back to text in a conversational app. + - Purpose: To catch hallucinated properties or malformed structures at the source. + - Outcome: If validation fails, the agent can attempt to fix or regenerate the A2UI JSON, or it can do graceful degradation such as falling back to text in a conversational app. 2. **Client-Side:** Upon receiving the payload, the client library validates the JSON against its local definition of the catalog. - - Purpose: Security and stability. This ensures that the code executing on the user's device strictly conforms to the expected contract, protecting against version mismatches or compromised agent outputs. - - Outcome: Failures here are reported back to the agent using the “error” client message + - Purpose: Security and stability. This ensures that the code executing on the user's device strictly conforms to the expected contract, protecting against version mismatches or compromised agent outputs. + - Outcome: Failures here are reported back to the agent using the “error” client message ### Graceful Degradation diff --git a/docs/concepts/data-binding.md b/docs/concepts/data-binding.md index bc8fd353c..531cd8388 100644 --- a/docs/concepts/data-binding.md +++ b/docs/concepts/data-binding.md @@ -174,32 +174,33 @@ Adding/removing items automatically updates the rendered components. Interactive components update the data model bidirectionally: -| Component | Example | User Action | Data Update | -| ------------------ | ------------------------------------------- | ---------------- | ------------------------ | -| **TextField** | `{"text": {"path": "/form/name"}}` | Types "Alice" | `/form/name` = "Alice" | -| **CheckBox** | `{"value": {"path": "/form/agreed"}}` | Checks box | `/form/agreed` = true | -| **MultipleChoice** | `{"selections": {"path": "/form/country"}}` | Selects "Canada" | `/form/country` = ["ca"] | +| Component | Example | User Action | Data Update | +| ------------------ | ------------------------------------------- | ---------------- | -------------------------- | +| **TextField** | `{"text": {"path": "/form/name"}}` | Types "Alice" | `/form/name` = `"Alice"` | +| **CheckBox** | `{"value": {"path": "/form/agreed"}}` | Checks box | `/form/agreed` = `true` | +| **MultipleChoice** | `{"selections": {"path": "/form/country"}}` | Selects "Canada" | `/form/country` = `["ca"]` | ## Best Practices - **Use granular updates**: Update only changed paths. - ```json - { - "dataModelUpdate": { - "path": "/user", - "contents": [{"key": "name", "valueString": "Alice"}] + ```json + { + "dataModelUpdate": { + "path": "/user", + "contents": [{"key": "name", "valueString": "Alice"}] + } } - } - ``` + ``` - **Organize by domain**: Group related data. - ```json - {"user": {...}, "cart": {...}, "ui": {...}} - ``` + ```json + {"user": {...}, "cart": {...}, "ui": {...}} + ``` - **Pre-compute display values**: Formats data (currency, dates) on the agent before sending. - ```json - {"price": "$19.99"} // Not: {"price": 19.99} - ``` + + ```json + {"price": "$19.99"} // Not: {"price": 19.99} + ``` diff --git a/docs/ecosystem/a2ui-in-the-world.md b/docs/ecosystem/a2ui-in-the-world.md index f860d5da3..234301c47 100644 --- a/docs/ecosystem/a2ui-in-the-world.md +++ b/docs/ecosystem/a2ui-in-the-world.md @@ -166,19 +166,19 @@ The A2UI community is building exciting projects: ### Open Source Examples - **Restaurant Finder** ([samples/agent/adk/restaurant_finder](https://github.com/google/A2UI/tree/main/samples/agent/adk/restaurant_finder)) - - Table reservation with dynamic forms - - Gemini-powered agent - - Full source code available + - Table reservation with dynamic forms + - Gemini-powered agent + - Full source code available - **Contact Lookup** ([samples/agent/adk/contact_lookup](https://github.com/google/A2UI/tree/main/samples/agent/adk/contact_lookup)) - - Search interface with results list - - A2A agent example - - Demonstrates data binding + - Search interface with results list + - A2A agent example + - Demonstrates data binding - **Component Gallery** ([samples/client/angular - gallery mode](https://github.com/google/A2UI/tree/main/samples/client/angular)) - - Interactive showcase of all components - - Live examples with code - - Great for learning + - Interactive showcase of all components + - Live examples with code + - Great for learning ### Third-Party Integrations diff --git a/docs/glossary.md b/docs/glossary.md index 8dba207f2..689d522e3 100644 --- a/docs/glossary.md +++ b/docs/glossary.md @@ -10,9 +10,9 @@ The A2UI protocol enables conversation between **agent** and **renderer**: 1. **Renderer** provides **UI capabilities** in the form of A2UI catalog and **instructions** on how to use it. 2. **Agent** iterates on the loop: - - Provides **UI** and **functions** to call, taking into account the received catalog - - Receives **user input**, communicated by renderer - - Updates **data** to show in UI + - Provides **UI** and **functions** to call, taking into account the received catalog + - Receives **user input**, communicated by renderer + - Updates **data** to show in UI ![agent and renderer](assets/agent-and-renderer.png) @@ -29,20 +29,20 @@ UI component, allowed for use by agent. Examples: date picker, carousel, button, ### Catalog 1. Itemized renderer capabilities: - - List of components that the agent can use to generate UI - - List of functions that can be invoked by renderer - - Styles and themes + - List of components that the agent can use to generate UI + - List of functions that can be invoked by renderer + - Styles and themes 2. Explanation on how the renderer capabilities should be used. It is observed that depending on use case, catalog components may be more or less specific to domain: - **Less specific**: - Basic UI primitives like buttons, labels, rows, columns, option-selectors and so on. + Basic UI primitives like buttons, labels, rows, columns, option-selectors and so on. - **More specific**: - Components like HotelCheckout or FlightSelector. + Components like HotelCheckout or FlightSelector. ### Basic Catalog @@ -61,29 +61,29 @@ There are options for A2UI agent: - **Same-process or server-side**: - Agent and renderer may reside in one process of a client side application. Example: desktop Flutter application. + Agent and renderer may reside in one process of a client side application. Example: desktop Flutter application. - Or, renderer may reside on the box that displays UI, and agent may reside on another box (server). + Or, renderer may reside on the box that displays UI, and agent may reside on another box (server). - **Orchestrator agent**: - The central orchestrator manages interactions between a user and several specialized sub-agents. The orchestrator can be in the same process or on the server. + The central orchestrator manages interactions between a user and several specialized sub-agents. The orchestrator can be in the same process or on the server. - **Pulling / pushing**: - An agent can wait for messages/requests from the renderer, or push messages/requests to it. + An agent can wait for messages/requests from the renderer, or push messages/requests to it. - **Stateful / stateless**: - Agents can preserve state or be stateless. + Agents can preserve state or be stateless. - **Mixed with other protocols**: - A2UI can be used in combination with other protocols. For example, an agent may be an MCP and/or A2A server. + A2UI can be used in combination with other protocols. For example, an agent may be an MCP and/or A2A server. - **Something else**: - In addition to the above options, there is possibility for any custom variation. + In addition to the above options, there is possibility for any custom variation. ### Renderer stack @@ -91,30 +91,30 @@ Functionality of A2UI renderer consists of layers that can be developed separate - **Core Library**: - Set of primitives, needed to describe catalog and to interact with the agent. + Set of primitives, needed to describe catalog and to interact with the agent. - For example, see the [JavaScript web core library](../renderers/web_core/README.md). + For example, see the [JavaScript web core library](../renderers/web_core/README.md). - **Catalog Schema**: - Definition of catalog in the form of JSON. + Definition of catalog in the form of JSON. - For example, see the [basic catalog schema](../specification/v0_10/json/basic_catalog.json). + For example, see the [basic catalog schema](../specification/v0_10/json/basic_catalog.json). - **Framework adapter**: - Code that implements the execution of the agent’s instructions in a concrete framework. For example: - - JavaScript core and catalogs may be adapted to Angular, Electron, React and Lit frameworks. - - Dart core and catalogs may be adapted to Flutter and Jaspr frameworks. + Code that implements the execution of the agent’s instructions in a concrete framework. For example: + - JavaScript core and catalogs may be adapted to Angular, Electron, React and Lit frameworks. + - Dart core and catalogs may be adapted to Flutter and Jaspr frameworks. - See the [Angular adapter](../renderers/angular/README.md). + See the [Angular adapter](../renderers/angular/README.md). - **Catalog Implementation**: - Implementation of the catalog schema for a framework. + Implementation of the catalog schema for a framework. - For example: - - See the [Angular implementation of the basic catalog](../renderers/angular/src/v0_9/catalog/basic) + For example: + - See the [Angular implementation of the basic catalog](../renderers/angular/src/v0_9/catalog/basic) ```mermaid flowchart TD; @@ -185,19 +185,19 @@ Terms, not required by A2UI protocol, but commonly used in the context of genera - **Chat**: - Pieces of generated UI appear one by one, sorted by time, in a vertically scrollable area, mixed with user input. + Pieces of generated UI appear one by one, sorted by time, in a vertically scrollable area, mixed with user input. - **Canvas**: - Space for collaboration with an agent. + Space for collaboration with an agent. - **Dashboard**: - Pieces of generated UI are organized not by time, but by their meaning and stay reliably (a.k.a. pinned) where the user expects to see them. + Pieces of generated UI are organized not by time, but by their meaning and stay reliably (a.k.a. pinned) where the user expects to see them. - **Wizard**: - Pieces of generated UI are shown one by one, with the goal to collect necessary information for a certain task. + Pieces of generated UI are shown one by one, with the goal to collect necessary information for a certain task. ### NoAI information diff --git a/docs/guides/a2ui-in-mcp-apps.md b/docs/guides/a2ui-in-mcp-apps.md index 8ad3607ae..9c798a2b1 100644 --- a/docs/guides/a2ui-in-mcp-apps.md +++ b/docs/guides/a2ui-in-mcp-apps.md @@ -164,21 +164,23 @@ MCP Apps are typically delivered as a single HTML resource from the MCP Server. > **How to use it:** > > 1. **Install the plugin**: -> ```bash -> npm install -D vite-plugin-singlefile -> ``` +> +> ```bash +> npm install -D vite-plugin-singlefile +> ``` +> > 2. **Configure Vite**: Add the plugin to your `vite.config.ts` (or `.js`): > -> ```typescript -> import {defineConfig} from 'vite'; -> import {viteSingleFile} from 'vite-plugin-singlefile'; +> ```typescript +> import {defineConfig} from 'vite'; +> import {viteSingleFile} from 'vite-plugin-singlefile'; > -> export default defineConfig({ -> plugins: [viteSingleFile()], -> }); -> ``` +> export default defineConfig({ +> plugins: [viteSingleFile()], +> }); +> ``` > -> This will ensure that all JS and CSS assets are inlined into the `index.html` file on build, making it ready to be served by your MCP server as a single resource. +> This will ensure that all JS and CSS assets are inlined into the `index.html` file on build, making it ready to be served by your MCP server as a single resource. ### Step 2: Leveraging A2UI-over-MCP diff --git a/docs/guides/defining-your-own-catalog.md b/docs/guides/defining-your-own-catalog.md index cb70fe2fb..86e4ccea3 100644 --- a/docs/guides/defining-your-own-catalog.md +++ b/docs/guides/defining-your-own-catalog.md @@ -31,18 +31,19 @@ It is recommended to create catalogs that directly map to your existing componen === "Web (Lit / Angular / React)" To implement your own catalog on the web: - - Create a JSON Schema containing your component definitions. -- Create your own `Component` objects and `Catalog` object within your chosen web renderer. - - Provide the schema or reference ID to the agent. + - Create a JSON Schema containing your component definitions. + - Create your own `Component` objects and `Catalog` object within your chosen web renderer. + - Provide the schema or reference ID to the agent. - _Detailed guides for each framework coming soon._ + _Detailed guides for each framework coming soon._ === "Flutter" To implement your own catalog in Flutter: - - Define a JSON Schema describing your widget properties. - - Map the schema to Flutter widgets using a custom renderer. + + - Define a JSON Schema describing your widget properties. + - Map the schema to Flutter widgets using a custom renderer. *Detailed Flutter integration guide coming soon.* diff --git a/docs/guides/renderer-development.md b/docs/guides/renderer-development.md index 5e3e7263f..470b9171c 100644 --- a/docs/guides/renderer-development.md +++ b/docs/guides/renderer-development.md @@ -74,47 +74,47 @@ A compliant renderer must implement the following message processing and state m - **JSONL Stream Parsing**: Implement a parser that can read a streaming response line by line, decoding each line as a distinct JSON object. - **Message Dispatcher**: Create a dispatcher to identify the message type (`beginRendering`, `surfaceUpdate`, `dataModelUpdate`, `deleteSurface`) and route it to the correct handler. - **Surface Management**: - - Implement a data structure to manage multiple UI surfaces, each keyed by its `surfaceId`. - - Handle `surfaceUpdate`: Add or update components in the specified surface's component buffer. - - Handle `deleteSurface`: Remove the specified surface and all its associated data and components. + - Implement a data structure to manage multiple UI surfaces, each keyed by its `surfaceId`. + - Handle `surfaceUpdate`: Add or update components in the specified surface's component buffer. + - Handle `deleteSurface`: Remove the specified surface and all its associated data and components. - **Component Buffering (Adjacency List)**: - - For each surface, maintain a component buffer (e.g., a `Map`) to store all component definitions by their `id`. - - Be able to reconstruct the UI tree at render time by resolving `id` references in container components (`children.explicitList`, `child`, `contentChild`, etc.). + - For each surface, maintain a component buffer (e.g., a `Map`) to store all component definitions by their `id`. + - Be able to reconstruct the UI tree at render time by resolving `id` references in container components (`children.explicitList`, `child`, `contentChild`, etc.). - **Data Model Store**: - - For each surface, maintain a separate data model store (e.g., a JSON object or a `Map`). - - Handle `dataModelUpdate`: Update the data model at the specified `path`. The `contents` will be in an adjacency list format (e.g., `[{ "key": "name", "valueString": "Bob" }]`). + - For each surface, maintain a separate data model store (e.g., a JSON object or a `Map`). + - Handle `dataModelUpdate`: Update the data model at the specified `path`. The `contents` will be in an adjacency list format (e.g., `[{ "key": "name", "valueString": "Bob" }]`). ### Rendering Logic Implement the following rendering logic: - **Progressive Rendering Control**: - - Buffer all incoming `surfaceUpdate` and `dataModelUpdate` messages without rendering immediately. - - Handle `beginRendering`: This message acts as the explicit signal to perform the initial render of a surface and set the root component ID. - - Start rendering from the specified `root` component ID. - - If a `catalogId` is provided, ensure the corresponding component catalog is used (defaulting to the basic catalog if omitted). - - Apply any global `styles` (e.g., `font`, `primaryColor`) provided in this message. + - Buffer all incoming `surfaceUpdate` and `dataModelUpdate` messages without rendering immediately. + - Handle `beginRendering`: This message acts as the explicit signal to perform the initial render of a surface and set the root component ID. + - Start rendering from the specified `root` component ID. + - If a `catalogId` is provided, ensure the corresponding component catalog is used (defaulting to the standard catalog if omitted). + - Apply any global `styles` (e.g., `font`, `primaryColor`) provided in this message. - **Data Binding Resolution**: - - Implement a resolver for `BoundValue` objects found in component properties. - - If only a `literal*` value is present (`literalString`, `literalNumber`, etc.), use it directly. - - If only a `path` is present, resolve it against the surface's data model. - - If both `path` and `literal*` are present, first update the data model at `path` with the literal value, then bind the component property to that `path`. + - Implement a resolver for `BoundValue` objects found in component properties. + - If only a `literal*` value is present (`literalString`, `literalNumber`, etc.), use it directly. + - If only a `path` is present, resolve it against the surface's data model. + - If both `path` and `literal*` are present, first update the data model at `path` with the literal value, then bind the component property to that `path`. - **Dynamic List Rendering**: - - For containers with a `children.template`, iterate over the data list found at `template.dataBinding` (which resolves to a list in the data model). - - For each item in the data list, render the component specified by `template.componentId`, making the item's data available for relative data binding within the template. + - For containers with a `children.template`, iterate over the data list found at `template.dataBinding` (which resolves to a list in the data model). + - For each item in the data list, render the component specified by `template.componentId`, making the item's data available for relative data binding within the template. ### Client-to-Server Communication Implement the following communication features: - **Event Handling**: - - When a user interacts with a component that has an `action` defined, construct a `userAction` payload. - - Resolve all data bindings within the `action.context` against the data model. - - Send the complete `userAction` object to the server's event handling endpoint. + - When a user interacts with a component that has an `action` defined, construct a `userAction` payload. + - Resolve all data bindings within the `action.context` against the data model. + - Send the complete `userAction` object to the server's event handling endpoint. - **Client Capabilities Reporting**: - - In **every** A2A message sent to the server (as part of the metadata), include an `a2uiClientCapabilities` object. - - This object should declare the component catalog your client supports via `supportedCatalogIds` (e.g., including the URI for the basic 0.8 catalog). - - Optionally, if the server supports it, provide `inlineCatalogs` for custom, on-the-fly component definitions. + - In **every** A2A message sent to the server (as part of the metadata), include an `a2uiClientCapabilities` object. + - This object should declare the component catalog your client supports via `supportedCatalogIds` (e.g., including the URI for the standard 0.8 catalog). + - Optionally, if the server supports it, provide `inlineCatalogs` for custom, on-the-fly component definitions. - **Error Reporting**: Implement a mechanism to send an `error` message to the server to report any client-side errors (e.g., failed data binding, unknown component type). ## II. Basic Component Catalog Checklist diff --git a/docs/index.md b/docs/index.md index 5cbc94b35..c2fc506f0 100644 --- a/docs/index.md +++ b/docs/index.md @@ -45,27 +45,27 @@ This repository contains: - :material-shield-check: **Secure by Design** - *** + *** - Declarative data format, not executable code. Agents can only use pre-approved components from your catalog—no UI injection attacks. + Declarative data format, not executable code. Agents can only use pre-approved components from your catalog—no UI injection attacks. - :material-rocket-launch: **LLM-Friendly** - *** + *** - Flat, streaming JSON structure designed for easy generation. LLMs can build UIs incrementally without perfect JSON in one shot. + Flat, streaming JSON structure designed for easy generation. LLMs can build UIs incrementally without perfect JSON in one shot. - :material-devices: **Framework-Agnostic** - *** + *** - One agent response works everywhere. Render the same UI on Angular, Flutter, React, or native mobile with your own styled components. + One agent response works everywhere. Render the same UI on Angular, Flutter, React, or native mobile with your own styled components. - :material-chart-timeline: **Progressive Rendering** - *** + *** - Stream UI updates as they're generated. Users see the interface building in real-time instead of waiting for complete responses. + Stream UI updates as they're generated. Users see the interface building in real-time instead of waiting for complete responses. @@ -75,59 +75,59 @@ This repository contains: - :material-clock-fast:{ .lg .middle } **[Quickstart Restaurant Finder Demo](quickstart.md)** - *** + *** - Run the full-stack demo locally with a Gemini powered ADK agent and Lit renderer. Learn A2UI end-to-end and customize to your use case. + Run the full-stack demo locally with a Gemini powered ADK agent and Lit renderer. Learn A2UI end-to-end and customize to your use case. - [:octicons-arrow-right-24: Run the demo](quickstart.md) + [:octicons-arrow-right-24: Run the demo](quickstart.md) - :material-react:{ .lg .middle } **[A2UI + AG-UI (React)](guides/a2ui-with-any-agent-framework.md)** - *** + *** - Scaffold a Next.js app wired to any agent framework via AG-UI. This is a React + A2UI app, ready to ship. + Scaffold a Next.js app wired to any agent framework via AG-UI. This is a React + A2UI app, ready to ship. - [:octicons-arrow-right-24: Use with any agent](guides/a2ui-with-any-agent-framework.md) + [:octicons-arrow-right-24: Use with any agent](guides/a2ui-with-any-agent-framework.md) - :material-palette-outline:{ .lg .middle } **[A2UI Composer](https://a2ui-composer.ag-ui.com/)** - *** + *** - Generate A2UI JSON from a visual editor — no install required. Paste the output into any agent prompt. + Generate A2UI JSON from a visual editor — no install required. Paste the output into any agent prompt. - [:octicons-arrow-right-24: Open the composer](https://a2ui-composer.ag-ui.com/) + [:octicons-arrow-right-24: Open the composer](https://a2ui-composer.ag-ui.com/) - :material-play-circle-outline:{ .lg .middle } **[A2UI Theater](https://a2ui-composer.ag-ui.com/theater)** - *** + *** - Step through pre-built A2UI streaming scenarios across Lit, React, and Angular renderers. See the protocol in motion before writing code. + Step through pre-built A2UI streaming scenarios across Lit, React, and Angular renderers. See the protocol in motion before writing code. - [:octicons-arrow-right-24: Open the playground](https://a2ui-composer.ag-ui.com/theater) + [:octicons-arrow-right-24: Open the playground](https://a2ui-composer.ag-ui.com/theater) - :material-book-open-variant:{ .lg .middle } **[Core Concepts](concepts/overview.md)** - *** + *** - Understand surfaces, components, data binding, and the adjacency list model. + Understand surfaces, components, data binding, and the adjacency list model. - [:octicons-arrow-right-24: Learn concepts](concepts/overview.md) + [:octicons-arrow-right-24: Learn concepts](concepts/overview.md) - :material-code-braces:{ .lg .middle } **[Developer Guides](guides/client-setup.md)** - *** + *** - Integrate A2UI renderers into your app or build agents that generate UIs. + Integrate A2UI renderers into your app or build agents that generate UIs. - [:octicons-arrow-right-24: Start building](guides/client-setup.md) + [:octicons-arrow-right-24: Start building](guides/client-setup.md) - :material-file-document:{ .lg .middle } **Protocol Specifications** - *** + *** - Dive into the complete technical specs: [v0.8 (stable)](specification/v0.8-a2ui.md) · [v0.9 (draft)](specification/v0.9-a2ui.md) + Dive into the complete technical specs: [v0.8 (stable)](specification/v0.8-a2ui.md) · [v0.9 (draft)](specification/v0.9-a2ui.md) - [:octicons-arrow-right-24: Read the v0.8 spec](specification/v0.8-a2ui.md) + [:octicons-arrow-right-24: Read the v0.8 spec](specification/v0.8-a2ui.md) diff --git a/docs/reference/agents.md b/docs/reference/agents.md index 69a22a177..3c753df3e 100644 --- a/docs/reference/agents.md +++ b/docs/reference/agents.md @@ -22,17 +22,17 @@ User interactions from the client can be treated as new user input. The A2UI repository includes sample agents you can learn from: - [Restaurant Finder](https://github.com/google/A2UI/tree/main/samples/agent/adk/restaurant_finder) - - Table reservations with forms. - - Written with the ADK. + - Table reservations with forms. + - Written with the ADK. - [Contact Lookup](https://github.com/google/A2UI/tree/main/samples/agent/adk/contact_lookup) - - Search with result lists. - - Written with the ADK. + - Search with result lists. + - Written with the ADK. - [Rizzcharts](https://github.com/google/A2UI/tree/main/samples/agent/adk/rizzcharts/python) - - A2UI Custom components demo. - - Written with the ADK. + - A2UI Custom components demo. + - Written with the ADK. - [Orchestrator](https://github.com/google/A2UI/tree/main/samples/agent/adk/orchestrator) - - Passes A2UI messages from remote subagents. - - Written with the ADK. + - Passes A2UI messages from remote subagents. + - Written with the ADK. ## Agent Types in A2A diff --git a/docs/scripts/README.md b/docs/scripts/README.md index 33d5ea1dc..e40085755 100644 --- a/docs/scripts/README.md +++ b/docs/scripts/README.md @@ -29,14 +29,15 @@ python docs/scripts/convert_docs.py - **Source (GitHub-flavored Markdown):** - ```markdown - > ⚠️ **Attention** - > - > This is an alert. - ``` + ```markdown + > ⚠️ **Attention** + > + > This is an alert. + ``` - **Target (MkDocs Syntax):** - ```markdown - !!! warning "Attention" - This is an alert. - ``` + + ```markdown + !!! warning "Attention" + This is an alert. + ```