[Docs]: Fix nested list indentation in docs

.prettierrc

@@ -19,6 +19,13 @@
       "options": {
         "singleQuote": false
       }
+    },
+    {
+      "files": "docs/**/*.md",
+      "options": {
+        "embeddedLanguageFormatting": "off",
+        "tabWidth": 4
+      }
     }
   ]
 }

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
 

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}
+    ```

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
 

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,60 +61,60 @@ 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
 
 Functionality of A2UI renderer consists of layers that can be developed separately and reused:
 
 - **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**:<a id="fw-adapter"></a>
 
-  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
 

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
 

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.*