feat(conformance): add error_responses and adapter suites and run adapter and accessibility conformance in all renderers

Package.swift

@@ -129,6 +129,7 @@ let package = Package(
         "A2UICore",
         "BasicCatalog",
         "BasicCatalogSwiftUI",
+        .product(name: "Yams", package: "Yams"),
       ],
       path: "swift/swiftui/Tests/A2UISwiftUITests"
     ),

conformance/README.md

@@ -11,11 +11,14 @@ Test suites are organized by functional domain:
 - `core/catalog.yaml`: Covers the catalog API, grouped by entry point. (1) `from_json` cases load a catalog with `Catalog.fromJson`, from an inline `catalog` or a repository-relative `catalogPath`, and check `expect` (`FromJsonExpect` in `conformance_schema.json`). `components` and `functions` list exactly the entries the loaded catalog defines, so a case can check that entries the `anyComponent` and `anyFunction` unions leave out are not loaded. The basic cases set `matchesBuiltinCatalog: true`: the published basic catalog loaded from JSON must be equivalent to the SDK's own basic catalog implementation (same id, version, component and function names, per-component property and required names, and per-function return type, callers and activation). Custom cases cover parsing rules and identifiers. `selfContained: true` requires every `$ref` in the resolved catalog schema to be a local reference that resolves within that document, and `validComponents` / `invalidComponents` list instances that must pass or fail validation. Every published catalog under `specification/<version>/catalogs/` and `catalogs/<name>/<version>/` has a `selfContained` case, and the Python suite fails if one is missing. (2) `to_json` cases compare the whole unbundled document `toJson()` returns with `expectFile`. Each case sets `builtinCatalog: basic` to serialize the SDK's own basic catalog for the case's protocol version and expects the published catalog file. (3) `round_trip` cases load `catalog` or `catalogPath` with `fromJson` (never the SDK's own implementation) and require `toJson()` to equal the input and `fromJson(out).toJson()` to equal `out`. (4) `validation_schema` cases load a published basic catalog, or a small inline catalog that exercises flattening, with `fromJson` and compare `validationSchema`, the successor of `catalogSchema`, with a golden artifact named by `expectFile` under `test_data/validation_schema/`. The goldens use the flattened shape: `allOf` envelopes are flattened, each component gets the `id` envelope, and the common types it references are inlined into `$defs`. An SDK whose output has a different shape lists the case as a known divergence. (5) `derive` cases (`DeriveTest`) load `catalog` or `catalogPath` with `fromJson`, derive a catalog from it with `args`, and check `expect` (`DeriveExpect`): the derived catalog's ID, protocol version, entries, theme and instructions, and the top-level keys its `toJson()` document leaves out. In `args.components` and `args.functions`, a name keeps the source's entry and a map with one key is a new entry. A harness fails a case whose `expect` block uses a key its definition does not list. All comparisons ignore object key order and the order of `enum` and `required` values.
 - `core/common_types.yaml`: Compares the common types schema that an SDK generates from its own models (`action: common_types_schema`) with the published `specification/<version>/json/common_types.json`. Both documents are compared as canonical JSON with sorted keys and must be identical. It also checks the rules those types enforce (`action: validate_common_type`): each step's `value` is validated as the named `definition` with the SDK's own model. A step with `expectError` must be rejected, and any other step must be accepted and serialize back to the same JSON.
 - `core/agent_to_renderer.yaml`: Compares the `agent_to_renderer` (`server_to_client`) message schema that an SDK generates from its own models (`action: agent_to_renderer_schema`) with the published `specification/<version>/json/server_to_client.json` or `specification/<version>/json/agent_to_renderer.json`. Both documents are compared as canonical JSON with sorted keys and must be identical.
-- `core/accessibility.yaml`: Contains test cases for accessibility attributes and checks.
+- `core/accessibility.yaml`: Covers 6 v1.0 accessibility attribute and data binding cases (`action: accessibility_check`). Each case checks static and data-bound `label`, `description`, `live`, and `hidden` attributes across Core SDKs and UI renderers.
+- `core/adapter_conformance.yaml`: Covers 13 v1.0 UI framework adapter cases (`action: render_surface`). Each case steps through message processing, data updates, user interactions, and surface disposal. It checks rendered view hierarchies, accessibility attributes, validation states, and outbound actions across `@a2ui/lit`, `@a2ui/react`, `@a2ui/angular`, `a2ui_flutter`, and `A2UISwiftUI`.
+- `core/error_responses.yaml`: Covers 23 renderer-to-agent `error` cases and 1 non-strict buffered streaming case across v0.9 and v1.0 (`action: validate`). Error cases check the error category, `expectError.rendererError` payload (`code`, `message`, and applicable `surfaceId`, `functionCallId`, or JSON Pointer `path`), and outbound schemas `client_to_server.json` (v0.9) and `renderer_to_agent.json` (v1.0).
+- `core/rpc_functions.yaml`: Covers 23 `callRendererFunction` and `rendererFunctionResponse` lifecycle, timeout, cancellation, and error cases (`action: handle_rpc`).
 - `core/validator_v0_8.yaml`, `core/validator_v0_9.yaml`, `core/validator_v1_0.yaml`: Contain test cases for schema and structural validation, one suite per protocol version. They cover envelope and component schema checks, duplicate IDs, missing roots, dangling references, cycles, reachability (including list templates and custom v0.8 roots), nesting depth limits, invalid paths, multiple surfaces, and incremental updates. Every case uses `action: validate` in strict mode. The messages in a step are processed in order, so a later message is checked against the components that earlier messages in the same step created. These three suites replace the former `core/validator.yaml`.
 - `core/data_model.yaml`: Contains test cases for the reactive data model, verifying JSON Pointer reads and writes, container creation, deletion, and observer notification.
 - `core/message_processor_v0_8.yaml`, `core/message_processor_v0_9.yaml`, `core/message_processor_v1_0.yaml`: Contain test cases for the message processor's state machine, one suite per protocol version. A step of a `process_messages` case may set `validationConfig`, the validation rules for that call only (`ExecutionContext.validationConfig`), in place of the rules the processor was created with. A rule the step leaves out is strict. These steps belong to the optional `agent_renderer_app` feature (`blueprints/features/agent_renderer_app.blueprint.md`), and an SDK that does not implement it skips their cases.
-- `core/node_resolution.yaml`: Contains node-tree, scoped-binding, notification, identity, action, and destruction scenarios. See [the case format](core/node_resolution.md).
+- `core/node_resolution.yaml`: Covers 16 reactive `NodeResolver` and `ComponentNode` cases (`action: resolve_nodes`) executed across TypeScript (`@a2ui/web_core`), Python (`a2ui_core`), Dart (`a2ui_core`), and Swift (`A2UICore`). Scenarios check node tree materialization, scoped template bindings, incremental message streams (`op: process_messages`), cycle and orphan recovery, rule evaluation, action dispatch, and disposal. See [the case format](core/node_resolution.md).
 - `core/expressions.yaml`: Contains test cases for the client-side expression parser behind `formatString`, covering literals, data bindings, function calls, nested interpolation, escaped markers and parse errors.
 - `core/functions.yaml`: Contains test cases for the basic catalog functions, and for the catalog a function call runs in on a surface. See [Writing cases for `evaluate_function`](#writing-cases-for-evaluate_function).
 - `core/message_processor_scaling.yaml`: Timing cases for `processMessages`, with a validation config and without one, which check that a surface arriving in many small messages takes time in proportion to its size. See [Timing cases](#timing-cases).
@@ -82,11 +85,14 @@ Each language SDK implements test harnesses that:
 2. Feed the inputs to the language's specific implementation of the parser/validator/compiler.
 3. Assert that the output matches the expected results defined in the YAML.
 
-Refer to the test harnesses across SDKs for worked examples of running conformance suites:
+Refer to the test harnesses across Core SDKs and UI framework renderers for worked examples of running conformance suites:
 
-- Python: `python/a2ui_agent/tests/conformance/test_conformance.py`
-- Dart: `dart/a2ui_core/test/conformance/expressions_conformance_test.dart`
-- TypeScript: `typescript/core/web_core/src/expressions/expression_parser.conformance.test.ts`
+- Python Core: `python/a2ui_core/tests/test_conformance.py` and `python/a2ui_core/tests/node_resolution_runner.py`
+- Python Agent: `python/a2ui_agent/tests/conformance/test_conformance.py`
+- TypeScript Web Core: `typescript/core/web_core/tests/conformance/conformance_test.mjs`, `typescript/core/web_core/tests/conformance/node-resolution.ts`, and `typescript/core/web_core/tests/conformance/accessibility_conformance.test.ts`
+- Web Renderers (`@a2ui/lit`, `@a2ui/react`, `@a2ui/angular`): `typescript/renderers/lit/src/tests/adapter_conformance.test.ts`, `typescript/renderers/react/tests/adapter_conformance.test.tsx`, and `typescript/renderers/angular/src/adapter_conformance.spec.ts`
+- Dart Core and Flutter Renderer: `dart/a2ui_core/test/conformance/validator_conformance_test.dart`, `dart/a2ui_core/test/conformance/node_resolution_conformance_test.dart`, and `dart/a2ui_flutter/test/adapter_conformance_test.dart`
+- Swift Core and SwiftUI Renderer: `swift/core/Tests/A2UIConformanceTests/ValidatorConformanceTests.swift`, `swift/core/Tests/A2UIConformanceTests/NodeResolutionConformanceTests.swift`, and `swift/swiftui/Tests/A2UISwiftUITests/AdapterConformanceTests.swift`
 
 Both Dart and TypeScript locate the suite by walking up from the test file, so they need no configured path. When implementing conformance harnesses for a new language or platform, across the Core SDK, Inference SDK, and framework adapter tiers, see [Implementing conformance harnesses](conformance_harness_implementation_guide.md).