VerseVDI-Protocol/openspec/changes/phase3c-provider-stream-policy/specs/provider-stream-policy/spec.md

ADDED Requirements

Requirement: Provider work carries the effective stream policy

Authenticated ProviderSessionWork SHALL carry the immutable policy version and its effective resolution, frame rate, codec, target bitrate, and audio-enabled decision.

Scenario: Gateway receives an effective policy

• WHEN the Server issues provider work for an admitted session
• THEN the work identifies the policy version and includes the effective bounded stream-policy values

Requirement: Stream-policy bindings share one strict contract

Generated Go, Rust, and Swift bindings MUST reject missing, unknown, out-of-range, or unsupported stream-policy wire values according to the canonical schema.

Scenario: Invalid policy is rejected consistently

• WHEN provider work contains an unknown codec or a value outside the canonical bounds
• THEN every generated binding rejects the work before it can reach provider setup

Requirement: Decode capabilities use registered ordered profiles

CapabilityProfile.client_decode SHALL be a non-empty ordered unique set containing only registered h264-opus and hevc-opus profile identifiers. It MUST NOT encode multiple capabilities in an opaque private token.

Scenario: Independent peer advertises one registered profile

• WHEN an independent peer advertises one registered decode profile
• THEN canonical validation accepts that profile without requiring a combined private token

Requirement: Consumers share one ordered registered-profile intersection

Generated Protocol behavior SHALL select common registered profiles in the first peer's preference order. Provider consumers SHALL separately reject the resulting intersection when it cannot honor the immutable stream policy.

Scenario: Policy-compatible profile overlaps

• WHEN the gateway advertises HEVC then H.264 and the client advertises only H.264
• THEN the shared intersection selects h264-opus

Scenario: No policy-compatible profile overlaps

• WHEN peers have no registered common profile
• THEN the shared intersection rejects admission without inventing a private combined token