feat(protocol): negotiate display and native input

2026-08-10 23:07:04 +07:00
parent 346bf5fe4d
commit 408d4f9cc3
24 changed files with 707 additions and 60 deletions
@@ -0,0 +1,33 @@
+## MODIFIED Requirements
+
+### Requirement: Typed sequenced input envelope
+The `input.sequenced.v1` payload SHALL begin with ASCII `VGI1`, a one-byte
+event kind, and one-byte payload length. It SHALL contain exactly one bounded
+keyboard, mouse-button, relative-mouse, UTF-8 scalar, controller-state,
+absolute-mouse, or high-resolution-scroll event. Absolute mouse kind `0x06`
+SHALL contain big-endian u16 x, y, viewport width, and viewport height, reject
+zero viewports and coordinates outside the viewport, and require negotiated
+`input.absolute.v1`. Scroll kind `0x07` SHALL contain big-endian signed i16
+vertical and horizontal deltas and require negotiated `input.scroll.v1`. False
+keyboard/mouse state and zeroed controller state are explicit releases.
+Unknown or unadvertised kinds, length mismatches, malformed UTF-8, unsupported
+controller indices, and reserved fields SHALL be rejected before provider
+translation.
+
+#### Scenario: Keyboard state change
+- **WHEN** a client sends a valid keyboard press or release envelope
+- **THEN** the gateway forwards the corresponding typed provider input on its
+  reliable keyboard channel and records the pressed state for cleanup.
+
+#### Scenario: Absolute pointer and scroll
+- **WHEN** an advertised client sends an in-viewport absolute coordinate or
+  signed scroll delta with the exact body length
+- **THEN** the gateway accepts the provider-neutral event without adding it to
+  pressed-state cleanup.
+
+#### Scenario: Invalid input envelope
+- **WHEN** a client sends an unknown or unadvertised kind, invalid length,
+  malformed UTF-8 scalar, zero viewport, out-of-range coordinate, or nonzero
+  reserved field
+- **THEN** the gateway rejects it without sending provider input or changing
+  pressed state.
@@ -0,0 +1,35 @@
+## ADDED Requirements
+
+### Requirement: Bounded display mode contract
+The Protocol SHALL define `DisplayMode` with required integer
+`resolution_width` from 320 through 16384, `resolution_height` from 200 through
+8640, and `fps` from 1 through 240, rejecting missing, unknown, or out-of-range
+fields.
+
+#### Scenario: Valid display mode
+- **WHEN** a client encodes a 2560 by 1440 display mode at 120 FPS
+- **THEN** generated Go, Rust, and Swift bindings accept the same exact values.
+
+#### Scenario: Invalid display mode
+- **WHEN** any dimension or FPS is outside its bound or an unknown field exists
+- **THEN** strict Protocol validation rejects the object.
+
+### Requirement: Feature-gated optional display disclosure
+`SessionRequest.requested_display_mode`,
+`BrokerSession.requested_display_mode`,
+`BrokerSession.effective_display_mode`, and `ManifestProfile.display_mode`
+SHALL be optional references to `DisplayMode`. Go bindings SHALL use pointers
+with JSON omission and Rust/Swift bindings SHALL use optionals. A client MUST
+send the request only after `display.request.v1` negotiation, and a
+display-aware manifest MUST contain the accepted mode. Legacy requests SHALL
+produce legacy response shapes without these fields.
+
+#### Scenario: Legacy request remains unchanged
+- **WHEN** a client omits `requested_display_mode`
+- **THEN** encoding omits the field and compatible Server responses omit all
+  display-mode fields.
+
+#### Scenario: Display-aware request discloses acceptance
+- **WHEN** a negotiated client sends a valid requested mode
+- **THEN** session responses preserve the requested mode and the allocated
+  manifest includes the Server-accepted mode.