ci: consolidate platform pipelines and test prerequisites on macOS support

openspec/changes/add-macos-user-communication/specs/desktop-user-requests/spec.md

@@ -0,0 +1,96 @@
+## ADDED Requirements
+
+### Requirement: Desktop user requests have one managed lifecycle
+Meeting Assistant SHALL expose pending user requests with an unpredictable ID, kind, title, message, creation time, expiration time and explicitly allowed action IDs and labels. The managed request lifecycle SHALL be independent of native notification presentation. Responses SHALL consume a request at most once. Invalid actions SHALL leave a valid request pending. Expiration, originating cancellation, withdrawal and application shutdown SHALL remove the request and prevent later responses from performing work. Absence of a response SHALL NOT grant approval. Accepted callbacks SHALL use the originating request lifetime, not the lifetime of the responding HTTP connection.
+
+#### Scenario: User answers an offered action once
+- **WHEN** a user submits an allowed action for a pending request
+- **THEN** that decision is delivered once and the request disappears
+- **AND** repeating the response performs no work
+
+#### Scenario: Invalid action preserves the request
+- **WHEN** a response names an action that the request does not offer
+- **THEN** the response is rejected and the request remains pending
+
+#### Scenario: Expired or canceled request cannot perform work
+- **WHEN** a request expires, is canceled, is withdrawn or its application shuts down
+- **THEN** the pending list excludes it
+- **AND** a later response cannot invoke its action
+
+### Requirement: macOS offers native notifications and pending-menu actions
+Meeting Assistant SHALL announce pending user requests through native actionable macOS notifications and SHALL also show their count and offered actions in the menu bar. Both presentations SHALL submit the same managed decision. Denied or hidden notifications SHALL NOT prevent menu decisions. Dismissing a notification SHALL NOT approve the request or remove the independent menu decision. Answered or expired requests SHALL be removed from native delivered and scheduled notifications. Delivery SHALL be asynchronous and SHALL NOT block recording, calendar checks or other requests.
+
+The native notification/menu host SHALL be packaged as a signed application bundle with a stable identifier and SHALL preserve the existing configured controls and numeric recording-status HTTP contract. Cold activation without a valid service/manifest SHALL NOT reconstruct an old request or approve it.
+
+#### Scenario: Native action and menu action have the same effect
+- **WHEN** the user chooses an offered action from either its notification or pending-menu entry
+- **THEN** the application submits the same request ID and action
+- **AND** the other presentation cannot execute the action a second time
+
+#### Scenario: Notification permission is denied
+- **WHEN** notification authorization is denied or a notification is hidden
+- **THEN** the request remains selectable from the menu until its original deadline
+
+#### Scenario: Existing recording status is decoded
+- **WHEN** the service returns recording state as the existing numeric enum
+- **THEN** the macOS helper shows the corresponding recording state and existing stop/abort controls
+
+### Requirement: macOS approvals wait for explicit user decisions
+On macOS, existing project-association and workflow-change approval interfaces SHALL use the desktop request channel. Yes SHALL approve; No, cancellation or ten-minute expiration SHALL decline. The summarizer SHALL receive new project access only after the existing approved-association operation succeeds. Workflow requests SHALL remain nonblocking for the summary and SHALL open their detailed prompt only after valid approval.
+
+#### Scenario: macOS project association is approved
+- **WHEN** a pending project association receives Yes before its deadline
+- **THEN** the existing association operation can proceed and scope expands only through that operation
+
+#### Scenario: macOS approval is declined or expires
+- **WHEN** the user chooses No or an approval expires
+- **THEN** no new project access or workflow conversation is granted
+
+### Requirement: macOS inactivity and calendar prompts are nonblocking
+The macOS inactivity prompt SHALL offer Stop, Continue and Pause through the pending request channel, expire after one minute and use the originating recording cancellation. DismissAllAsync SHALL remove inactivity requests without removing other kinds. The prompt method SHALL return without waiting for a user decision so existing inactivity checks and automatic stop remain operational.
+
+The macOS calendar prompt SHALL offer Record and Skip and SHALL additionally offer Attach metadata to current meeting when the existing request allows it. It SHALL preserve the exact appointment metadata in the existing callback and expire after five minutes or at appointment end, whichever comes first. Its prompt method SHALL return without waiting, so other appointments and calendar synchronization continue.
+
+#### Scenario: Inactivity prompt does not block automatic safeguards
+- **WHEN** the application enqueues an inactivity warning
+- **THEN** the prompt method returns while the request remains unanswered
+- **AND** a valid offered response invokes the existing meeting callback
+
+#### Scenario: An inactive recording withdraws its request
+- **WHEN** the originating recording cancels its inactivity prompt lifetime
+- **THEN** that request disappears and a late action cannot affect a later recording
+
+#### Scenario: Calendar prompt allows attaching exact appointment metadata
+- **WHEN** a calendar request permits attachment and the user selects Attach metadata
+- **THEN** the existing callback receives AttachMetadataToCurrentMeeting for that appointment
+- **AND** recording is not stopped and restarted by that action
+
+#### Scenario: Unanswered calendar prompt does not block other work
+- **WHEN** a calendar prompt remains unanswered
+- **THEN** its show method has already returned
+- **AND** subsequent calendar checks can run
+
+### Requirement: Approved workflow prompts use independent macOS conversations
+After a valid workflow approval, macOS SHALL create a new independent interactive agent conversation and request its own native window. The full detailed prompt SHALL start once server-side. The existing conversation, history and draft SHALL remain intact. Window loading, snapshot polling and page reload SHALL NOT resubmit that prompt. Unknown session IDs SHALL be rejected instead of using another conversation. Background work SHALL observe application shutdown and SHALL NOT be canceled merely because a page load or response connection closes.
+
+#### Scenario: Approved workflow starts once without replacing the current chat
+- **WHEN** a valid workflow request is approved while the normal agent conversation exists
+- **THEN** a separate session receives the full prompt once
+- **AND** the normal session and draft remain intact
+- **AND** requesting snapshots or reloading its page does not start the prompt again
+
+#### Scenario: Two workflow requests remain independent
+- **WHEN** two workflow requests receive valid approval
+- **THEN** each receives its own conversation and window request
+
+#### Scenario: Unknown session is rejected
+- **WHEN** a client sends a chat message for an unknown session ID
+- **THEN** the service returns not found without changing any conversation
+
+### Requirement: Windows user decisions preserve their existing implementation
+Windows builds SHALL retain existing notification services and user-decision semantics. macOS notification helper packaging SHALL NOT be required to build or run the Windows target.
+
+#### Scenario: Windows composition stays isolated
+- **WHEN** the Windows target is built and services are registered
+- **THEN** existing Windows prompt implementations remain selected
+- **AND** no macOS helper is invoked