Conversation
There was a problem hiding this comment.
Code Review
This pull request updates the A2UI documentation to clarify the distinction between Agent-side Events and Renderer-side Functions, while also refining terminology and updating schema links. The review feedback suggests improving conciseness by removing redundant execution notes and correcting the "Function Validation" header to "Action Validation" to better reflect its scope. Additionally, it is recommended to restore the GitHub-specific alert syntax for critical security warnings and important notes to ensure they remain visually prominent for developers.
| 1. **Events**: Dispatched to the Agent for processing (executed on Agent, e.g., clicking "Submit"). | ||
| 2. **Functions**: Executed entirely on the renderer using [`FunctionCall`](../../specification/v0_9/json/common_types.json#L200-L242) (executed on Renderer, e.g., opening a URL). |
There was a problem hiding this comment.
The parenthetical notes "(executed on Agent...)" and "(executed on Renderer...)" are redundant because the start of each definition already specifies the execution location. Removing these repetitions makes the list more concise.
| 1. **Events**: Dispatched to the Agent for processing (executed on Agent, e.g., clicking "Submit"). | |
| 2. **Functions**: Executed entirely on the renderer using [`FunctionCall`](../../specification/v0_9/json/common_types.json#L200-L242) (executed on Renderer, e.g., opening a URL). | |
| 1. **Events**: Dispatched to the Agent for processing (e.g., clicking "Submit"). | |
| 2. **Functions**: Executed entirely on the renderer using [`FunctionCall`](../../specification/v0_9/json/common_types.json#L200-L242) (e.g., opening a URL). |
| - **Formatting**: Using `formatString` to format a local display value. | ||
|
|
||
| ### Basic Catalog Action Validation (Checks) | ||
| ### Basic Catalog Function Validation (Checks) |
There was a problem hiding this comment.
The header "Function Validation" is misleading. In A2UI, "Functions" refers specifically to local renderer-side actions (functionCall). However, "Checks" are a general mechanism that applies to any component's action, including those that trigger an event (Agent-side). "Action Validation" or simply "Validation" would be more accurate.
| ### Basic Catalog Function Validation (Checks) | |
| ### Basic Catalog Action Validation (Checks) |
|
|
||
| > [!CAUTION] | ||
| > **Security Risk: State Scraping**: If an Orchestrator fails to strip the `a2uiClientDataModel`, a malicious or compromised sub-agent could potentially "scrape" the state of other active surfaces. For example, a weather sub-agent could read sensitive data from a banking surface if the orchestrator leaks the entire multi-surface data model. Stripping is a mandatory security requirement in multi-agent systems. | ||
| CAUTION: **Security Risk: State Scraping**: If an Orchestrator fails to strip the `a2uiClientDataModel`, a malicious or compromised sub-agent could potentially "scrape" the state of other active surfaces. For example, a weather sub-agent could read sensitive data from a banking surface if the orchestrator leaks the entire multi-surface data model. Stripping is a mandatory security requirement in multi-agent systems. |
There was a problem hiding this comment.
The removal of the GitHub-specific alert syntax (> [!CAUTION]) and the blockquote formatting reduces the visual prominence of this critical security warning. It is recommended to retain the alert syntax to ensure that mandatory security requirements like metadata stripping are easily noticed by developers. This applies to other notes and important callouts in the document as well (lines 60, 98, 138, 265).
| CAUTION: **Security Risk: State Scraping**: If an Orchestrator fails to strip the `a2uiClientDataModel`, a malicious or compromised sub-agent could potentially "scrape" the state of other active surfaces. For example, a weather sub-agent could read sensitive data from a banking surface if the orchestrator leaks the entire multi-surface data model. Stripping is a mandatory security requirement in multi-agent systems. | |
| > [!CAUTION] | |
| > **Security Risk: State Scraping**: If an Orchestrator fails to strip the `a2uiClientDataModel`, a malicious or compromised sub-agent could potentially "scrape" the state of other active surfaces. For example, a weather sub-agent could read sensitive data from a banking surface if the orchestrator leaks the entire multi-surface data model. Stripping is a mandatory security requirement in multi-agent systems. |
| The basic catalog defines a limited set of checks that can be performed on the renderer. Interactive components can define a list of `checks` (using the [`Checkable`](../../specification/v0_9/json/common_types.json#L258-L270) schema in `common_types.json`). For a `Button`, if any check fails, the button is **automatically disabled** on the renderer. | ||
|
|
||
| - **UX Focus**: Action checks are designed to manage **UI State (User Experience)** by preventing invalid interactions before they happen. They are not a replacement for **Data Integrity** checks, which must still be performed on the agent. | ||
| - **UX Focus**: Validation checks are designed to manage **UI State (User Experience)** by preventing invalid interactions before they happen. They are not a replacement for **Data Integrity** checks, which must still be performed on the agent. |
There was a problem hiding this comment.
I am lost between all kinds of validations. They appear gradually in the text and it is hard to track what kinds of validation are there.
It seems we are missing them in glossary.
There was a problem hiding this comment.
they are a concept in the basic catalog, other catalogs don't use them, its why its confusing since its not a core part of a2ui, just something we added in basic catalog
Co-authored-by: Polina Cherkasova <polina.c@live.com>
No description provided.