Preserve recovery transcripts and add user-approved agent requests

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.

openspec/changes/prompt-for-new-microphone/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-09-25

openspec/changes/prompt-for-new-microphone/design.md

@@ -0,0 +1,33 @@
+## Context
+
+MicrophoneAudioSource already retries failed capture sources without ending the composite microphone/system-audio stream. WindowsMicrophoneDeviceProvider enumerates active endpoints on demand. Native actionable Windows notifications already use CommunityToolkit.WinUI.Notifications.
+
+## Goals / Non-Goals
+
+**Goals:** Discover newly available microphones during active capture, ask before switching, and replace only the microphone capture lifetime when accepted. Preserve the recording, paused state, transcription session, and system audio.
+
+**Non-Goals:** Change tray selection semantics, automatically prefer newly connected hardware, introduce a new notification framework, or restart the service.
+
+## Decisions
+
+- Poll active endpoints once per second within each microphone capture session. This reuses existing enumeration and works independently of incoming audio chunks. An OS-specific device-event subscription would add another platform lifecycle without improving the current requirement materially.
+- Establish the initial endpoint IDs as the baseline and offer each newly seen ID at most once per meeting. Declining or ignoring a prompt does not interrupt audio and does not cause repeated prompts.
+- Keep discovery/prompt handling in a separate monitor with a narrow prompt-service boundary. The microphone source owns replacement of its current capture token; the shared runtime selection is updated only on a still-valid affirmative response.
+- Bind monitoring and prompt cancellation to the originating capture session. Cancel prompts when their device disappears or the session ends. Prompts expire after one minute and stale actions cannot alter another meeting.
+- Use the existing native toast toolkit and a neutral no-op prompt implementation. Display the device name with explicit Yes/No actions.
+- Recheck prompt cancellation after device lookup and at the selection update. Capture sources that own native resources are disposed even when a switch cancels their stream before enumeration starts.
+
+## Risks / Trade-offs
+
+- Device discovery can lag by one polling interval. Capture continues during discovery and while waiting for a response.
+- Hardware can disappear after acceptance. The existing capture-recovery loop handles creation or capture failures and keeps system audio running.
+- Switching has an unavoidable short microphone gap. Only microphone capture is canceled; the enclosing recording and transcription are retained.
+- Windows controls actual notification display duration. One-minute expiration controls action validity; it does not guarantee on-screen persistence.
+
+## Migration Plan
+
+No data migration or new configuration is needed. Verify through deterministic capture sources and a Windows build, with native UI/device verification only when it can avoid interrupting a real meeting.
+
+## Open Questions
+
+None.

openspec/changes/prompt-for-new-microphone/proposal.md

@@ -0,0 +1,24 @@
+## Why
+
+A microphone connected during a healthy recording is currently only discovered on later device enumeration or capture recovery. Users need an explicit choice to use a newly connected headset without ending the meeting.
+
+## What Changes
+
+- Watch active microphone endpoints while microphone capture is running, including paused transcription.
+- Offer a native Windows notification naming each newly available microphone with Yes/No actions.
+- Switch only the microphone capture source when accepted, preserving system audio, transcription, and meeting artifacts.
+- Ignore declined, expired, disconnected-device, and ended-meeting prompts.
+
+## Capabilities
+
+### New Capabilities
+
+None.
+
+### Modified Capabilities
+
+- `meeting-recording`: prompt for newly available microphones and safely switch the active microphone on acceptance.
+
+## Impact
+
+Microphone capture orchestration, Windows notifications, dependency registration, recording documentation, and deterministic capture/notification tests. Reuses the existing Windows notification toolkit; no new UI framework or configuration migration.

openspec/changes/prompt-for-new-microphone/specs/meeting-recording/spec.md

@@ -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

openspec/changes/prompt-for-new-microphone/tasks.md

@@ -0,0 +1,22 @@
+## 1. Discovery and prompt lifetime
+
+- [x] 1.1 Add behavior tests and a monitor that offers newly available endpoints once per capture session without blocking capture.
+- [x] 1.2 Test and handle rejection, expiration, disappearance, and ended-session responses safely.
+
+## 2. Capture switching and native UI
+
+- [x] 2.1 Test and implement accepted microphone switches within the existing capture stream, retaining disconnect recovery.
+- [x] 2.2 Add native Windows Yes/No notifications and register the monitor and prompt service.
+- [x] 2.3 Cover cancellation during confirmation lookup and switching or ending the meeting during capture creation; reject stale confirmation and dispose abandoned capture resources.
+
+## 3. Verification and documentation
+
+- [x] 3.1 Document discovery, prompt validity, and active switching.
+- [x] 3.2 Review the implementation, run focused and full solution tests, build Windows, and validate this change strictly.
+- [x] 3.3 Verify through the safest available operational surface and record any native hardware/UI verification limits.
+
+Verification: all 11 focused microphone tests and all 534 solution tests pass. The solution build includes the Windows target and succeeds with the four existing NAudio obsolete-API warnings. Strict OpenSpec validation passes. Independent review identified confirmation-cancellation and capture-ownership races; regression tests reproduced them before the fixes, and the follow-up review confirmed both are resolved.
+
+The capture behavior tests exercise the public audio stream and shared selection with controlled devices and prompts: acceptance replaces samples in the same stream, while decline, expiry, removal, and ended sessions prevent a switch. The running application's recording-status endpoint was checked read-only and reported idle. A physical microphone connection and native toast activation were not tested: no controllable hardware hotplug was available in this session, and the running service was not updated or restarted. Native hardware/UI verification remains a follow-up before operational acceptance or archival.
+
+Authorized local start (2026-09-25): the current Release build was subsequently published and started using the documented restart helper after another idle check. Health, idle status, tray creation, and model warm-up are successful. The complete solution now has 552 passing tests. Physical microphone hotplug and toast activation remain unverified.