docs: fix inaccuracies in extras module documentation

docs/content/extras/http-clients.md

@@ -53,7 +53,7 @@ For non-Quarkus environments, also add `vertx-web-client`:
 
 ### 2. Automatic Discovery (No Code Changes)
 
-The `VertxA2AHttpClientProvider` has **priority 100** (vs. 50 for the JDK client). The SDK's `A2AHttpClientFactory` uses `ServiceLoader` to discover and select the highest-priority provider available:
+The `VertxA2AHttpClientProvider` has **priority 100** (vs. 0 for the JDK client). The SDK's `A2AHttpClientFactory` uses `ServiceLoader` to discover and select the highest-priority provider available:
 
 ```java
 // No changes needed — A2A SDK automatically uses VertxA2AHttpClient

docs/content/extras/opentelemetry.md

@@ -20,7 +20,7 @@ Adds distributed tracing, metrics, and context propagation to A2A servers and cl
 | Module | Artifact ID | Description |
 |--------|-------------|-------------|
 | Common | `a2a-java-sdk-opentelemetry-common` | Shared utilities and constants |
-| Server | `a2a-java-sdk-opentelemetry-server` | Server-side tracing and context-aware executor |
+| Server | `a2a-java-sdk-opentelemetry-server` | Server-side tracing |
 | Client | `a2a-java-sdk-opentelemetry-client` | Client-side instrumentation |
 | Client Propagation | `a2a-java-sdk-opentelemetry-client-propagation` | Context propagation for async client operations |
 
@@ -67,30 +67,13 @@ Response (with trace headers)
 
 ### Context-Aware Async Executor
 
-The module automatically replaces the default `AsyncExecutorProducer` with `AsyncManagedExecutorProducer`:
+> **Note:** The `AsyncManagedExecutorProducer` is provided by the **Quarkus reference server** (`reference/common`), not the OpenTelemetry module. It is documented here because it enables context propagation (including trace context) across async boundaries.
+
+The reference server replaces the default `AsyncExecutorProducer` with `AsyncManagedExecutorProducer`:
 
 - **Priority 20**: takes precedence over the default executor (priority 10)
-- **Automatic activation**: no configuration needed — just include the module
-- **Context propagation**: uses MicroProfile Context Propagation to maintain trace context across async boundaries
-
-```java
-@ApplicationScoped
-public class MyAgent implements Agent {
-
-    @Inject
-    @Internal
-    Executor executor;  // Automatically uses ManagedExecutor with context propagation
-
-    @Override
-    public void execute(RequestContext context, AgentEmitter emitter) {
-        executor.execute(() -> {
-            // Runs in a different thread but maintains the trace context
-            Span currentSpan = Span.current();
-            currentSpan.addEvent("Processing in async task");
-        });
-    }
-}
-```
+- **Automatic activation**: no configuration needed — included automatically in the Quarkus reference server
+- **Context propagation**: uses MicroProfile Context Propagation to maintain trace context and CDI request context across async boundaries
 
 > **Note:** Unlike the default `AsyncExecutorProducer`, the `AsyncManagedExecutorProducer` does not use the `a2a.executor.*` configuration properties. Pool sizing is controlled by the container's `ManagedExecutor` configuration.
 
@@ -110,20 +93,20 @@ The following attributes are automatically added to spans:
 
 | Attribute | Description |
 |-----------|-------------|
-| `genai.request` | Request parameters (if extraction enabled) |
-| `genai.response` | Response data (if extraction enabled) |
+| `gen_ai.agent.a2a.request` | Request parameters (if extraction enabled) |
+| `gen_ai.agent.a2a.response` | Response data (if extraction enabled) |
 | `error.type` | Error message (on failures) |
 
 ### Request/Response Extraction
 
-Enable request and response data extraction in spans:
+Enable request and response data extraction in spans using JVM system properties:
 
-```properties
+```
 # Extract request parameters into span attributes (disabled by default)
-a2a.opentelemetry.extract-request=true
+-Dorg.a2aproject.sdk.server.extract.request=true
 
 # Extract response data into span attributes (disabled by default)
-a2a.opentelemetry.extract-response=true
+-Dorg.a2aproject.sdk.server.extract.response=true
 ```
 
 > **Warning:** Extracting request/response data may expose sensitive information in traces. Use with caution in production environments.
@@ -161,7 +144,7 @@ For trace context propagation across async client boundaries:
 **Solution:** Ensure the OpenTelemetry server module is included and check logs for:
 
 ```
-Initializing OpenTelemetry-aware ManagedExecutor for async operations
+Initializing ManagedExecutor for async operations with CDI context propagation
 ```
 
 ### ManagedExecutor Not Available

docs/content/extras/replicated-queue-manager.md

@@ -33,7 +33,7 @@ The system replicates these event types while preserving their specific types:
 - `TaskArtifactUpdateEvent` — task artifact changes
 - `Message` — chat messages and responses
 - `Task` — complete task objects
-- `JSONRPCError` — error events
+- `A2AError` — error events
 
 Events are serialized using Jackson with polymorphic type information:
 
@@ -179,8 +179,8 @@ The mechanism uses **transaction-aware CDI events**: the poison pill is only sen
 
 ```java
 // JpaDatabaseTaskStore fires CDI event after persist
-if (task.getStatus().state().isFinal()) {
-    taskFinalizedEvent.fire(new TaskFinalizedEvent(task.getId()));
+if (task.status().state().isFinal()) {
+    taskFinalizedEvent.fire(new TaskFinalizedEvent(task.id(), task));
 }
 
 // ReplicatedQueueManager observes it after transaction commit
@@ -281,8 +281,8 @@ You can monitor replicated events by observing CDI events:
 @ApplicationScoped
 public class ReplicationMonitor {
 
-    public void onReplicatedEvent(@Observes ReplicatedEvent event) {
-        LOGGER.info("Received replicated event for task: " + event.getTaskId());
+    public void onReplicatedEvent(@Observes ReplicatedEventQueueItem replicatedEvent) {
+        LOGGER.info("Received replicated event for task: " + replicatedEvent.getTaskId());
     }
 }
 ```

docs/content/extras/storage.md

@@ -67,7 +67,11 @@ The module automatically creates the required table:
 ```sql
 CREATE TABLE a2a_tasks (
     task_id VARCHAR(255) PRIMARY KEY,
-    task_data TEXT NOT NULL
+    context_id VARCHAR(255),
+    state VARCHAR(255),
+    status_timestamp TIMESTAMP,
+    task_data TEXT NOT NULL,
+    finalized_at TIMESTAMP
 );
 ```
 
@@ -126,6 +130,8 @@ CREATE TABLE a2a_push_notification_configs (
     task_id VARCHAR(255) NOT NULL,
     config_id VARCHAR(255) NOT NULL,
     task_data TEXT NOT NULL,
+    protocol_version VARCHAR(255),
+    created_at TIMESTAMP,
     PRIMARY KEY (task_id, config_id)
 );
 ```

docs/content/sitemap.xml

@@ -1 +1 @@
-{#include fm/sitemap.xml /}
+{#include fm/sitemap.xml /}