7.6 KiB
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