Make titles in non-docs markdown files more consistent with style guide

README.md

@@ -9,7 +9,7 @@ to generate or populate rich user interfaces.
 
 *A gallery of A2UI rendered cards, showing a variety of UI compositions that A2UI can achieve.*
 
-## ⚠️ Status: Early Stage Public Preview
+## ⚠️ Status: Early stage public preview
 
 > **Note:** A2UI is currently in **v0.8 (Public Preview)**. The specification and
 implementations are functional but are still evolving. We are opening the project to
@@ -30,7 +30,7 @@ component library (Flutter, Angular, Lit, etc.).
 This approach ensures that agent-generated UIs are
 **safe like data, but expressive like code**.
 
-## High-Level Philosophy
+## High-level philosophy
 
 A2UI was designed to address the specific challenges of interoperable,
 cross-platform, generative or template-based UI responses from agents.
@@ -63,7 +63,7 @@ places security firmly in the developer's hands, enabling them to enforce
 strict sandboxing policies and "trust ladders" directly within their custom
 component logic rather than relying solely on the core system.
 
-## Use Cases
+## Use cases
 
 Some of the use cases include:
 
@@ -98,7 +98,7 @@ A2UI is designed to be a lightweight format, but it fits into a larger ecosystem
 * **Host Frameworks:** Requires a host application built in a supported framework
 (currently: Web or Flutter).
 
-## Getting Started
+## Getting started
 
 The best way to understand A2UI is to run the samples.
 
@@ -108,7 +108,7 @@ The best way to understand A2UI is to run the samples.
 * Python (for agent samples)
 * A valid [Gemini API Key](https://aistudio.google.com/) is required for the samples.
 
-### Running the Restaurant Finder Demo
+### Running the Restaurant Finder demo
 
 1. **Clone the repository:**
 
@@ -117,7 +117,7 @@ The best way to understand A2UI is to run the samples.
     cd A2UI
     ```
 
-2. **Set your API Key:**
+2. **Set your API key:**
 
     ```bash
     export GEMINI_API_KEY="your_gemini_api_key"
@@ -160,10 +160,10 @@ to try out as well.
 
 We hope to work with the community on the following:
 
-* **Spec Stabilization:** Moving towards a v1.0 specification.
-* **More Renderers:** Adding official support for React, Jetpack Compose, iOS (SwiftUI), and more.
-* **Additional Transports:** Support for REST and more.
-* **Additional Agent Frameworks:** Genkit, LangGraph, and more.
+* **Spec stabilization:** Moving towards a v1.0 specification.
+* **More renderers:** Adding official support for React, Jetpack Compose, iOS (SwiftUI), and more.
+* **Additional transports:** Support for REST and more.
+* **Additional Agent frameworks:** Genkit, LangGraph, and more.
 
 ## Contribute
 

a2a_agents/python/a2ui_agent/README.md

@@ -1,16 +1,16 @@
-# A2UI Agent Implementation
+# A2UI Agent implementation
 
 The `a2a_agents/python/a2ui_agent/` is the Python implementation of the a2ui agent library.
 
-### Extension Components (`src/a2ui/extension`)
+### Extension components (`src/a2ui/extension`)
 
 The `src/a2ui/extension` directory contains the core logic for the A2UI agent extension:
 
 *   **`a2ui_extension.py`**: Core utilities for extension management and A2UI part handling.
 *   **`a2ui_schema_utils.py`**: Schema manipulation helpers.
 *   **`send_a2ui_to_client_toolset.py`**: An example implementation of using ADK toolcalls to implement A2UI.
 
-## Running Tests
+## Running tests
 
 1. Navigate to the a2ui_agent dir:
 
@@ -40,4 +40,4 @@ All operational data received from an external agent—including its AgentCard,
 
 Similarly, any UI definition or data stream received must be treated as untrusted. Malicious agents could attempt to spoof legitimate interfaces to deceive users (phishing), inject malicious scripts via property values (XSS), or generate excessive layout complexity to degrade client performance (DoS). If your application supports optional embedded content (such as iframes or web views), additional care must be taken to prevent exposure to malicious external sites.
 
-Developer Responsibility: Failure to properly validate data and strictly sandbox rendered content can introduce severe vulnerabilities. Developers are responsible for implementing appropriate security measures—such as input sanitization, Content Security Policies (CSP), strict isolation for optional embedded content, and secure credential handling—to protect their systems and users.
+Developer Responsibility: Failure to properly validate data and strictly sandbox rendered content can introduce severe vulnerabilities. Developers are responsible for implementing appropriate security measures—such as input sanitization, Content Security Policies (CSP), strict isolation for optional embedded content, and secure credential handling—to protect their systems and users.

samples/agent/adk/contact_lookup/README.md

@@ -1,4 +1,4 @@
-# A2UI Contact Lookup Agent Sample
+# A2UI Contact Lookup Agent sample
 
 This sample uses the Agent Development Kit (ADK) along with the A2A protocol to create a simple "Contact Lookup" agent that is hosted as an A2A server.
 
@@ -8,7 +8,7 @@ This sample uses the Agent Development Kit (ADK) along with the A2A protocol to
 - [UV](https://docs.astral.sh/uv/)
 - Access to an LLM and API Key
 
-## Running the Sample
+## Running the sample
 
 1. Navigate to the samples directory:
 
@@ -38,4 +38,4 @@ All operational data received from an external agent—including its AgentCard,
 
 Similarly, any UI definition or data stream received must be treated as untrusted. Malicious agents could attempt to spoof legitimate interfaces to deceive users (phishing), inject malicious scripts via property values (XSS), or generate excessive layout complexity to degrade client performance (DoS). If your application supports optional embedded content (such as iframes or web views), additional care must be taken to prevent exposure to malicious external sites.
 
-Developer Responsibility: Failure to properly validate data and strictly sandbox rendered content can introduce severe vulnerabilities. Developers are responsible for implementing appropriate security measures—such as input sanitization, Content Security Policies (CSP), strict isolation for optional embedded content, and secure credential handling—to protect their systems and users.
+Developer Responsibility: Failure to properly validate data and strictly sandbox rendered content can introduce severe vulnerabilities. Developers are responsible for implementing appropriate security measures—such as input sanitization, Content Security Policies (CSP), strict isolation for optional embedded content, and secure credential handling—to protect their systems and users.

specification/v0_8/docs/a2ui_extension_specification.md

@@ -1,4 +1,4 @@
-# A2UI (Agent-to-Agent UI) Extension Spec
+# A2UI (Agent-to-Agent UI) Extension spec
 
 ## Overview
 
@@ -10,7 +10,7 @@ The URI of this extension is https://a2ui.org/a2a-extension/a2ui/v0.8
 
 This is the only URI accepted for this extension.
 
-## Core Concepts
+## Core concepts
 
 The A2UI extension is built on the following main concepts:
 
@@ -49,11 +49,11 @@ Example AgentExtension block:
 }
 ```
 
-### Parameter Definitions
+### Parameter definitions
 - `params.supportedCatalogIds`: (OPTIONAL) An array of strings, where each string is a URI pointing to a component Catalog Definition Schema that the agent can generate.
 - `params.acceptsInlineCatalogs`: (OPTIONAL) A boolean indicating if the agent can accept an `inlineCatalogs` array in the client's `a2uiClientCapabilities`. If omitted, this defaults to `false`.
 
-## Extension Activation
+## Extension activation
 Clients indicate their desire to use the A2UI extension by specifying it via the transport-defined A2A extension activation mechanism.
 
 For JSON-RPC and HTTP transports, this is indicated via the X-A2A-Extensions HTTP header.
@@ -62,7 +62,7 @@ For gRPC, this is indicated via the X-A2A-Extensions metadata value.
 
 Activating this extension implies that the server can send A2UI-specific messages (like surfaceUpdate) and the client is expected to send A2UI-specific events (like userAction).
 
-## Data Encoding
+## Data encoding
 
 A2UI messages are encoded as an A2A `DataPart`.
 
@@ -86,4 +86,4 @@ Example A2UI DataPart:
     "mimeType": "application/json+a2ui"
   }
 }
-```
+```

specification/v0_8/docs/a2ui_protocol.md

@@ -12,7 +12,7 @@ A Specification for a JSONL-Based, Streaming UI Protocol
 Created: Sep 19, 2025
 Updated: Nov 12, 2025
 
-## Design Requirements
+## Design requirements
 
 The A2UI (Agent to UI) protocol should be a system where an LLM can stream a platform-agnostic, abstract UI definition to a client, which then renders it progressively using a native widget set. Every major design choice is traced back to the core challenges of LLM generation, perceived performance, and platform independence.
 
@@ -71,19 +71,19 @@ Client-to-server communication for user interactions is handled separately via a
 - `error`: Reports a client-side error.
   This keeps the primary data stream unidirectional.
 
-## Section 1: Foundational Architecture and Data Flow
+## Section 1: Foundational architecture and data flow
 
 This document specifies the architecture and data formats for the A2UI protocol. The design is guided by principles of strict separation of concerns, versioning, and progressive rendering.
 
-### 1.1. Core Philosophy: Decoupling and Contracts
+### 1.1. Core philosophy: decoupling and contracts
 
 The central philosophy of A2UI is the decoupling of three key elements:
 
 1.  **The Component Tree (The Structure):** A server-provided tree of abstract components that describes the UI's structure. This is defined by `surfaceUpdate` messages.
 2.  **The Data Model (The State):** A server-provided JSON object containing the dynamic values that populate the UI, such as text, booleans, or lists. This is managed via `dataModelUpdate` messages.
 3.  **The Widget Registry (The "Catalog"):** A client-defined mapping of component types (e.g., "Row", "Text") to concrete, native widget implementations. This registry is **part of the client application**, not the protocol stream. The server must generate components that the target client's registry understands.
 
-### 1.2. The JSONL Stream: The Unit of Communication
+### 1.2. The JSONL stream: The unit of communication
 
 All UI descriptions are transmitted from the server to the client as a stream of JSON objects, formatted as JSON Lines (JSONL). Each line is a separate, compact JSON object representing a single message. This allows the client to parse and process each part of the UI definition as it arrives, enabling progressive rendering.