docs(openspec): define phase 3d native macos client

2026-08-10 22:52:39 +07:00
parent 6264e9c2dc
commit 57c5310e67
10 changed files with 609 additions and 0 deletions
@@ -0,0 +1,27 @@
+## 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