docs(openspec): archive phase3c gateway contracts

2026-07-30 07:38:39 +07:00
parent 534bb1031b
commit 2e92fae27f
12 changed files with 63 additions and 0 deletions
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-07-29
@@ -0,0 +1,38 @@
+## Context
+
+The Data Plane already collects process-wide atomic counters and gauges. Only active connections and egress Kbps cross the authenticated heartbeat boundary.
+
+## Goals / Non-Goals
+
+**Goals:**
+
+- Carry the existing low-cardinality observations with explicit units.
+- Bound every numeric field and enumerate provider state.
+- Keep registration capacity distinct from measured traffic.
+
+**Non-Goals:**
+
+- Add session, route, endpoint, credential, label, or payload fields.
+- Define a new telemetry transport.
+- Publish a Protocol version.
+
+## Decisions
+
+- Nest the values in required `GatewayTelemetry` so heartbeat telemetry is one strict atomic contract.
+- Use cumulative counters and microsecond delay totals plus one processing sample per complete provider media unit; consumers can derive rates/averages without losing raw observations.
+- Define queue delay as residence in the bounded provider queue, processing as active recovery/framing/QUIC work excluding queue and scheduler waits, and pacing as scheduler wait only.
+- Derive measured egress from transmitted-byte deltas over monotonic elapsed time; configured capacity remains registration data.
+- Keep loss as parts per million and provider state as a bounded enum.
+
+## Risks / Trade-offs
+
+- [Cumulative counters approach signed integer limits] → Bound at signed 64-bit and saturate consumer conversions.
+- [New required object breaks RC6] → Test locally and publish only under separate immutable-version authorization.
+
+## Migration Plan
+
+Regenerate all bindings locally, update both consumers through the temporary workspace, and stop at the immutable publication boundary.
+
+## Open Questions
+
+None.
@@ -0,0 +1,23 @@
+## Why
+
+Gateway heartbeat currently carries active sessions and one egress rate but cannot transport the required observed process and provider-path telemetry.
+
+## What Changes
+
+- Add one required bounded low-cardinality telemetry object to authenticated gateway heartbeat.
+- Cover counters, delay totals/samples, control RTT/loss/jitter, pending reliability, reconnects, and provider state.
+- Keep configured capacity exclusively in registration and measured egress in heartbeat.
+
+## Capabilities
+
+### New Capabilities
+
+- `gateway-heartbeat-telemetry`: Authenticated heartbeats carry bounded observed gateway telemetry without routes, sessions, credentials, or payload data.
+
+### Modified Capabilities
+
+None.
+
+## Impact
+
+The control-v1 schema, generated Go/Rust/Swift bindings, conformance checks, and both unpublished consumers require coordinated local updates. RC6 remains unchanged.
@@ -0,0 +1,22 @@
+## ADDED Requirements
+
+### Requirement: Heartbeat carries observed gateway telemetry
+Every authenticated `GatewayHeartbeat` SHALL carry the bounded process-level counters, delay totals and samples, control RTT/loss/jitter, pending reliable work, reconnect count, and provider state defined by `GatewayTelemetry`.
+
+#### Scenario: Valid telemetry heartbeat
+- **WHEN** a gateway reports its current observed snapshot
+- **THEN** Go, Rust, and Swift bindings accept the same bounded low-cardinality values and units
+
+### Requirement: Heartbeat telemetry excludes sensitive dimensions
+Heartbeat telemetry MUST reject unknown fields and MUST NOT include session, route, endpoint, credential, label, or payload values.
+
+#### Scenario: Secret or high-cardinality field is attempted
+- **WHEN** a heartbeat contains an unregistered session, route, endpoint, credential, or payload field
+- **THEN** strict contract validation rejects it before authenticated transport
+
+### Requirement: Delay and egress observations have one canonical meaning
+Queue delay SHALL measure provider-queue residence, processing delay SHALL measure active gateway recovery/framing/QUIC work excluding queue and pacing, and pacing delay SHALL measure scheduler waiting only. Processing samples SHALL count complete provider media units rather than Verse fragments. Measured egress SHALL derive from transmitted-byte deltas over monotonic elapsed time and MUST NOT be copied from configured capacity.
+
+#### Scenario: One provider unit becomes multiple Verse frames
+- **WHEN** one complete provider unit waits in the queue, traverses gateway processing, waits for pacing, and fragments into multiple Verse frames
+- **THEN** each delay total includes only its defined interval and the heartbeat advances processing samples exactly once
@@ -0,0 +1,12 @@
+## 1. Contract
+
+- [x] 1.1 Add bounded GatewayTelemetry to every heartbeat
+- [x] 1.2 Add Go, Rust, and Swift strict conformance checks
+- [x] 1.3 Regenerate bindings and prove deterministic output
+- [x] 1.4 Specify queue, processing, pacing, sample, and measured-egress semantics
+
+## 2. Consumer Boundary
+
+- [x] 2.1 Verify local Data Plane and Server consumers through a temporary workspace
+- [x] 2.2 Publish one new never-reused immutable Protocol version under separate authorization
+- [x] 2.3 Resolve from empty caches and pin exact checksums in both consumers
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-07-29
@@ -0,0 +1,42 @@
+## 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.
+- Express client decode support as an ordered set of existing registered profiles.
+- Generate the same ordered registered-profile intersection for every consumer.
+- 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 a provider-specific token grammar or generic capability framework.
+- 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.
+- Change `client_decode` from one opaque string to a non-empty ordered unique array of registered profile identifiers. Preference belongs to the first peer's order.
+- Generate `IntersectCapabilityProfiles` from the canonical schema so Protocol, Server, and Data Plane do not maintain separate interpretations.
+
+## 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.
+- [Peers advertise no common registered profile] → Reject admission instead of inventing a combined token or silently downgrading.
+
+## 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,24 @@
+## 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.
+- Represent decode support as an ordered set of registered profiles and generate one canonical intersection operation for consumers.
+- 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, and registered peers negotiate that policy through the shared ordered profile intersection.
+
+### 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,33 @@
+## 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
@@ -0,0 +1,13 @@
+## 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
+- [x] 1.4 Replace the opaque decode token with an ordered unique set of registered profiles
+- [x] 1.5 Generate and cross-check canonical ordered registered-profile intersection behavior
+
+## 2. Consumer Boundary
+
+- [x] 2.1 Verify local Server and Data Plane consumers through a temporary workspace
+- [x] 2.2 Publish one new never-reused immutable Protocol version under separate authorization
+- [x] 2.3 Resolve from empty caches and pin exact checksums in both consumers