feat(protocol): carry stream policy and gateway telemetry

This commit is contained in:
sechmachine
2026-07-30 01:45:48 +07:00
parent 59741761ce
commit d26f8b60f8
17 changed files with 991 additions and 42 deletions
@@ -0,0 +1,2 @@
schema: spec-driven
created: 2026-07-29
@@ -0,0 +1,37 @@
## Context
The Server resolves an immutable stream-policy version, but RC6 provider work carries only its identifier. The Data Plane consequently cannot distinguish the authorized settings from local defaults.
## Goals / Non-Goals
**Goals:**
- Carry only the effective launch settings required by the provider boundary.
- Generate identical validation from the canonical schema for all bindings.
- Preserve the policy-version identifier for audit correlation.
**Non-Goals:**
- Publish or mutate RC6.
- Add provider-specific capability negotiation to Protocol.
- Expose provider work or policy internals to Verse clients.
## Decisions
- Use one required nested `ProviderStreamPolicy` value in `ProviderSessionWork`; this keeps the policy settings atomic and avoids repeating validation.
- Carry the Server-selected target bitrate rather than all policy bounds because Apollo ANNOUNCE consumes one configured bitrate.
- Permit canonical `H264`, `HEVC`, and `AV1` values in the contract. A provider implementation must reject values it cannot honor rather than silently downgrade them.
- Carry `audio_enabled` even though the current Apollo path cannot truthfully disable audio; the Data Plane must fail closed for that combination.
## Risks / Trade-offs
- [New required field breaks RC6 consumers] → Publish only under a separately authorized new immutable version and pin both consumers after empty-cache resolution.
- [Provider capabilities differ] → Validate the effective policy against the selected provider before readiness.
## Migration Plan
Regenerate and verify bindings locally, update both consumers through a temporary workspace only, then stop at the publication boundary. RC6 remains unchanged.
## Open Questions
None.
@@ -0,0 +1,23 @@
## Why
Provider work identifies an immutable stream-policy version but omits the effective settings, allowing a gateway to launch Apollo with unrelated hard-coded media parameters.
## What Changes
- Add the effective resolution, frame rate, codec, selected bitrate, and audio policy to authenticated provider work.
- Require generated Go, Rust, and Swift bindings to validate the same bounded stream-policy contract.
- Keep the new contract unpublished until a new immutable Protocol version is separately authorized.
## Capabilities
### New Capabilities
- `provider-stream-policy`: Authenticated provider work carries the exact effective stream policy consumed by the provider launch.
### Modified Capabilities
None.
## Impact
The control-v1 schema, generated bindings, conformance fixtures, and downstream Server and Data Plane consumers require coordinated local updates. RC6 remains immutable and unchanged.
@@ -0,0 +1,15 @@
## 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
@@ -0,0 +1,11 @@
## 1. Contract
- [x] 1.1 Add bounded effective stream policy to ProviderSessionWork
- [x] 1.2 Add Go, Rust, and Swift conformance coverage
- [x] 1.3 Regenerate bindings and prove deterministic output
## 2. Consumer Boundary
- [x] 2.1 Verify local Server and Data Plane consumers through a temporary workspace
- [ ] 2.2 Publish one new never-reused immutable Protocol version under separate authorization
- [ ] 2.3 Resolve from empty caches and pin exact checksums in both consumers