Files
VerseVDI-Data-Plane/openspec/changes/phase-3d-macos-native-mvp/specs/session-display-mode/spec.md
T

2.2 KiB

ADDED Requirements

Requirement: P3D-033 requested and effective display mode

The client SHALL offer global and desktop/pool overrides for Automatic, detected/common preset, Custom, and Full Native width/height/FPS. A display-aware request SHALL be feature-gated; the Server SHALL validate, include it in idempotency identity, resolve immutable policy, proportionally clamp to even dimensions and maximum FPS, persist requested/effective values atomically, and disclose both without provider details.

Scenario: Oversized custom request

  • WHEN a requested mode exceeds either policy dimension or FPS
  • THEN the Server applies one proportional scale, floors both dimensions to even pixels, caps FPS, persists the result, and returns the requested and accepted modes

Scenario: Legacy request

  • WHEN a client omits the feature and requested display object
  • THEN the Server preserves the legacy response shape and provider work uses the existing exact policy mode

Scenario: Same idempotency key with different mode

  • WHEN two requests reuse an idempotency key but contain different requested display modes
  • THEN the Server rejects the mismatch rather than returning or mutating the earlier session

Requirement: P3D-034 native detection and reconnect semantics

Automatic mode SHALL derive physical pixels and maximum FPS from the screen where the session window opens, prefer a defensible notch-safe built-in mode, otherwise disclose Full Native, and SHALL NOT mutate an active mode after a display move. Reconnect to match the new display SHALL end the prior session and use a new request/idempotency key. Owner E2E SHALL prove accepted values on Apollo/SudoMaker IDD through the gateway-only route.

Scenario: Move active session to another display

  • WHEN an Automatic session window moves to a display with different native capability
  • THEN the active mode remains unchanged and the user may explicitly reconnect with a newly detected request

Scenario: Exact owner virtual-display acceptance

  • WHEN the owner runs the frozen client, Server, gateway, and Apollo candidate
  • THEN retained evidence binds requested and accepted width/height/FPS to the actual SudoMaker virtual display without a direct client-provider route