docs(openspec): archive phase 3d display input
This commit is contained in:
+3
-3
@@ -12,6 +12,6 @@
|
|||||||
|
|
||||||
## 3. Freeze
|
## 3. Freeze
|
||||||
|
|
||||||
- [ ] 3.1 Commit the verified source and generated bindings as one unsigned capability-sized change.
|
- [x] 3.1 Commit the verified source and generated bindings as one unsigned capability-sized change.
|
||||||
- [ ] 3.2 Verify the next Phase 3D Protocol RC name is unused locally and remotely, then create one local immutable candidate tag without publishing it.
|
- [x] 3.2 Verify the next Phase 3D Protocol RC name is unused locally and remotely, then create one local immutable candidate tag without publishing it.
|
||||||
- [ ] 3.3 Reconcile and archive this OpenSpec change after the immutable candidate is frozen.
|
- [x] 3.3 Reconcile and archive this OpenSpec change after the immutable candidate is frozen.
|
||||||
@@ -7,20 +7,32 @@ used across the authenticated Verse gateway boundary.
|
|||||||
### Requirement: Typed sequenced input envelope
|
### Requirement: Typed sequenced input envelope
|
||||||
The `input.sequenced.v1` payload SHALL begin with ASCII `VGI1`, a one-byte
|
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
|
event kind, and one-byte payload length. It SHALL contain exactly one bounded
|
||||||
keyboard, mouse-button, relative-mouse, UTF-8 scalar, or controller-state
|
keyboard, mouse-button, relative-mouse, UTF-8 scalar, controller-state,
|
||||||
event. False keyboard/mouse state and zeroed controller state are explicit
|
absolute-mouse, or high-resolution-scroll event. Absolute mouse kind `0x06`
|
||||||
releases. Multibyte integer fields SHALL be big-endian. Unknown kinds,
|
SHALL contain big-endian u16 x, y, viewport width, and viewport height, reject
|
||||||
length mismatches, malformed UTF-8, unsupported controller indices, and
|
zero viewports and coordinates outside the viewport, and require negotiated
|
||||||
reserved fields SHALL be rejected before provider translation.
|
`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
|
#### Scenario: Keyboard state change
|
||||||
- **WHEN** a client sends a valid keyboard press or release envelope
|
- **WHEN** a client sends a valid keyboard press or release envelope
|
||||||
- **THEN** the gateway forwards the corresponding typed provider input on its
|
- **THEN** the gateway forwards the corresponding typed provider input on its
|
||||||
reliable keyboard channel and records the pressed state for cleanup.
|
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
|
#### Scenario: Invalid input envelope
|
||||||
- **WHEN** a client sends an envelope with an unknown event kind, invalid
|
- **WHEN** a client sends an unknown or unadvertised kind, invalid length,
|
||||||
length, malformed UTF-8 scalar, or nonzero reserved field
|
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
|
- **THEN** the gateway rejects it without sending provider input or changing
|
||||||
pressed state.
|
pressed state.
|
||||||
|
|
||||||
|
|||||||
@@ -0,0 +1,38 @@
|
|||||||
|
# session-display-mode Specification
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
TBD - created by archiving change phase-3d-client-display-input. Update Purpose after archive.
|
||||||
|
## 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.
|
||||||
Reference in New Issue
Block a user