[Task]: 1.0: Run TCK tests against 1.0 implementation

[ishymko]

Currently some TCK tests are running in CI (run-tck.yaml) for JSON-RPC (see #639).

This should be done as a part for 1.0 migration as well.

It is setup for Java 1.0 RC here against a a2a-tck/spec_1.0 branch TCK merged 1.0 tests to main.

Category	JSON-RPC	REST	gRPC
Mandatory	⬜	⬜	⬜
Capabilities	⬜	⬜	⬜
Quality	⬜	⬜	⬜
Features	⬜	⬜	⬜

[kuangmi-bit]

Hi — I'd like to pick this up. Quick context on why this is a good fit:

• We have 3 merged contributions in a2a-tck (style: format code using ruff fix and format #196 CARD-SIGN-003 protected-header structural tests, feat!: Update A2A types from specification 🤖 #197 transport-layer extension activation, plus the eventqueue conformtest package work in a2a-go), so we're familiar with the 1.0 TCK test structure and how to wire a SUT against it.
• Current state: run-tck.yaml pins TCK_VERSION: 0.3.0.beta3 — still exercising the 0.3 TCK. The 1.0 TCK is available (a2a-tck is at version 1.0.0 on main, tag 1.0.0.alpha2).

Proposed plan (mirroring the Java SDK's run-tck-1.0-wip.yml):

1. Bump TCK_VERSION to a 1.0 build and run the JSON-RPC SUT first (smallest surface, already has 0.3 coverage) — fix any compatibility gaps the 1.0 tests surface.
2. Then enable REST and gRPC rows in the matrix as they go green.
3. Report per-cell status against the checklist in this issue (Mandatory/Capabilities/Quality/Features × JSON-RPC/REST/gRPC).

Two questions before I start:

1. Version pin — use 1.0.0.alpha2, or wait for a final 1.0.0 release? Happy to pin whatever maintainers prefer.
2. Anyone already working this? The issue has no assignee and no comments, but I want to avoid colliding with in-flight work (e.g. if a branch already has TCK-1.0 wiring).

I'll start by standing up the 1.0 TCK locally against the JSON-RPC SUT and report what breaks — the first PR can be just the workflow bump plus fixes for the JSON-RPC row.

[kuangmi-bit]

Progress update — I stood up the 1.0 TCK locally against the JSON-RPC SUT and opened #1165 with the two transport-level blockers fixed:

What was broken (jsonrpc, must level, TCK 1.0.0.alpha2):

• httpx.post("/") normalizes to a trailing slash → POST /a2a/jsonrpc/ 404'd (route was exact-match only). Fixed in create_jsonrpc_routes (both spellings now route).
• SUT emitted TaskStatusUpdateEvent without enqueuing the Task first → SDK raises InvalidAgentResponseError (spec [Feat]: get_data_parts as part of utils #311 ordering). Fixed in tck/sut_agent.py.

Result: 53 failed → 6 failed / 67 passed.

Remaining 6 (all real, none transport-level):

1. DM-ART-001 ×4 — SUT returns no artifacts (SUT feature gap; artifact-echo support needed in the SUT or the tests need a capability gate)
2. TestMessageResponse — SUT replies without artifact/structured payload variants
3. JSONRPC-SSE-002 — ContentTypeNotSupportedError (-32005) reported as ParseError (-32700) — SDK error-code mapping gap

Still to do (proposing as follow-up PRs):

• REST and gRPC rows in the matrix (workflow currently runs jsonrpc only — see run-tck.yaml)
• Bump TCK_VERSION from 0.3.0.beta3 to a 1.0 build + update the run_tck.py CLI invocation (--category/--transports → --level/--transport)

Questions from my earlier comment still stand (version pin, collision check) — happy to take the workflow bump + REST/gRPC rows next once #1165 is reviewed, or to hand off cleanly if anyone else is already on it.

[kuangmi-bit]

Extended the local run to all three transports (TCK 1.0.0.alpha2, must level, same SUT). Two more SUT compatibility fixes were needed and are now pushed to #1165:

• protocolBinding: 'REST' → 'HTTP+JSON' — the 1.0 binding map only recognizes JSONRPC/GRPC/HTTP+JSON; the old name made the REST row untestable
• gRPC interface url http://localhost:50051 → localhost:50051 — grpcio treats the url as a channel target

Current per-transport status (must level):

Transport	Passed	Failed	Remaining failures
jsonrpc	67	6	5× SUT artifacts/MessageResponse gaps + 1× content-type error code
http_json (REST)	61	5	5× SUT artifacts/MessageResponse gaps
grpc	48	7	5× SUT artifacts/MessageResponse gaps + 2× gRPC status codes

So all three transports are wired and exercising the 1.0 TCK; the remaining failures are (a) SUT feature gaps — the SUT never produces artifact-carrying or message-variant responses (DM-ART-001 etc.), and (b) two error/status code mappings. Happy to take the workflow bump (TCK_VERSION → 1.0 build, run_tck.py CLI: --category/--transports → --level/--transport) as the next PR once #1165 is in, or to fix the SUT artifact gaps — whichever maintainers prefer.