agui-cross-sdk-parity

name

agui-cross-sdk-parity

description

Keep the AG-UI .NET SDK at feature and wire-format PARITY with the canonical reference SDKs (TypeScript is the source of truth; Python is types/encoder only). USE FOR: porting a feature/event/behavior that landed in the TS (or Python) SDK into .NET, verifying the .NET wire format (JSON, SSE, protobuf) matches the reference, locating where the reference implementation and compatibility fixtures live, mapping a TS concept to the .NET event/client/encoder model, resolving an upstream protocol fix (e.g. a Microsoft.Extensions.AI / Microsoft Agent Framework issue) that needs a .NET counterpart, deciding which .NET package owns a change. DO NOT USE FOR: the mechanics of writing a specific test (use agui-dotnet-unit-tests for serialization round-trips, agui-dotnet-integration-tests for cross-language / E2E harness mechanics, agui-dotnet-wire-types for JSON/proto type rules, agui-dotnet-transport for SSE/HTTP transport details). This skill is about the PARITY PROCESS and where the reference lives, not test authoring.

AG-UI Cross-SDK Parity

The .NET SDK implements an upstream, multi-language protocol. This skill encodes the parity process: which SDK is authoritative, where its reference and fixtures live, how to map reference concepts onto the .NET model, and how parity is guarded.

Parity Principle

• TypeScript is canonical for wire format AND client run-loop behavior. When two SDKs disagree, match TS.
• Python is types + encoder only. It has core (types/events) and an encoder, but no client run-loop and no protobuf (sdks/python/ag_ui/ has core/ and encoder/ but no client/ or proto/). Use it only as a secondary check on type/JSON shape — never for run-loop or proto questions.
• Upstream protocol or SDK fixes (in the TS client run-loop, or in Microsoft.Extensions.AI / Microsoft Agent Framework) sometimes need a .NET counterpart; treat the TypeScript change as the contract to match.