Preserve recovery transcripts and add user-approved agent requests
PR and Push Build/Test / build-and-test (push) Successful in 12m0s

Append successful offline recovery with a duplicate-warning marker and retain failed replay sources. Offer newly available microphones through confirmation notifications.

Add project discovery metadata and blocking association approval, plus nonblocking workflow requests that start a separate settings-agent conversation. Include regression tests, OpenSpec changes, and verified local Release startup.
This commit is contained in:
2026-09-25 11:58:34 +02:00
parent e011e36ef7
commit 7b2bcd3631
50 changed files with 2188 additions and 113 deletions
@@ -0,0 +1,41 @@
## ADDED Requirements
### Requirement: Newly available microphones can be selected during a meeting
While microphone capture for a meeting is active, including while transcription is paused, Meeting Assistant SHALL monitor newly available microphone endpoints and show a native Windows notification naming each newly discovered microphone and offering affirmative and negative actions.
Devices already available when capture starts SHALL NOT trigger a notification. Each device ID SHALL be offered at most once per meeting. Discovery and unanswered prompts SHALL NOT block audio capture.
An affirmative response SHALL select the named microphone and replace only the active microphone capture source. The meeting, transcript session, artifacts, transcription pause state, and system-audio capture SHALL remain active. The selection SHALL also be used by later recording starts until another runtime selection or application exit.
A negative response or expiration SHALL leave microphone selection and capture unchanged. Prompts SHALL expire after one minute and SHALL become invalid when the originating capture ends or the target device disappears. A stale response SHALL NOT change a later meeting's microphone selection.
#### Scenario: Newly connected microphone is offered
- **GIVEN** a meeting is recording from an existing microphone
- **WHEN** another microphone becomes available
- **THEN** a notification names that microphone and offers Yes and No
- **AND** audio continues while the notification is unanswered
- **AND** repeated observations of the same device do not produce more notifications
#### Scenario: User accepts the new microphone
- **GIVEN** the notification refers to a still-available microphone in the active meeting
- **WHEN** the user chooses Yes
- **THEN** subsequent microphone audio comes from that microphone
- **AND** the existing meeting, system audio, and transcription session continue
#### Scenario: User declines or ignores the new microphone
- **WHEN** the user chooses No or the prompt expires
- **THEN** capture and selection remain on the existing microphone
#### Scenario: Device disappears or meeting ends before acceptance
- **GIVEN** a new-microphone prompt is pending
- **WHEN** its device disappears or its meeting capture ends
- **THEN** the prompt is canceled and later activation cannot switch the microphone
#### Scenario: Existing devices do not prompt on start
- **WHEN** a meeting starts with multiple available microphones
- **THEN** the initial device list becomes the discovery baseline without showing notifications
#### Scenario: Paused transcription still offers a new microphone
- **GIVEN** a meeting's transcription is paused while audio capture remains active
- **WHEN** a microphone becomes available and the user accepts its notification
- **THEN** the microphone source changes while transcription remains paused