Module protocol_version 

AcpProtocolVersion — the wire-level protocol version.

Why a separate type from AcpVersion

The ACP meta.json file and the schema’s MANIFEST.toml entry pin a release (schema-v1.25.0). The wire’s protocolVersion field on InitializeRequest and InitializeResponse is a u16 that increments on breaking changes (per the schema’s own docstring on ProtocolVersion: https://github.com/agentclientprotocol/agent-client-protocol/blob/schema-v1.25.0/schema/v1/schema.json#LProtocolVersion).

The two coexist: a build pinned to AcpVersion::V1_25_0 always sends AcpProtocolVersion(1) on the wire. A future build pinned to a v2 release sends 2. A peer that does not understand the offered version answers with the same u16 value the build knows, and the negotiation result is “the lower of the two”.

Why Copy and a u16 newtype

The wire form is a u16; the dispatcher’s API boundary hands out the typed value by value, not by reference. A bare u16 would type-collide with every other u16 in the codebase; the newtype is the boundary marker the type checker reads.

Structs

AcpProtocolVersion

The wire-level protocol version. The current pin is V1, which is what every schema-v1.x.y release advertises. A future breaking change moves the pin to V2 and the build knows.

AcpProtocolVersionParseError

The error returned by AcpProtocolVersion::from_str when the input is not a well-formed decimal integer in 0..=u16::MAX.