Public Access
codex
7b2bcd3631
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.
34 lines
2.8 KiB
Markdown
34 lines
2.8 KiB
Markdown
## 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.
|