feat(detection): auto-detect meetings via microphone activity (macOS)

[AzimovS]

Summary

Adds meeting auto-detection via microphone activity on macOS. When a non-Meetily app holds the default input device past a sustain threshold, a "Meeting detected — " banner fires. When the mic is released during an active Meetily recording, a "Meeting ended — tap to stop recording" banner fires.

Matches the approach used by char (fastrepl/char) and Granola — no browser URL reading, no window title parsing, no new permissions.

Scope & rationale

macOS only. Windows (WASAPI) and Linux (PulseAudio) samplers are deferred to follow-up PRs. The App enum and stub-sampler factory shape make adding those platforms a matter of slotting in platform files, not rearchitecting.

Why not all three platforms in one PR (see #34 history and the phase2-draft tag for the record):

• macOS is the only platform the author has validated end-to-end
• Shipping untested Win/Linux code conflates confidence levels — users of those platforms today have no in-app way to disable detection if something goes wrong, because show_meeting_detected / show_meeting_ended prefs only suppress the banner (the poll loop keeps running)
• Phase 2 is uncertain; carrying dead platform code in the tree costs review friction and maintenance drag
• The phase2-draft tag (git show phase2-draft) preserves the Win/Linux work for when / if it picks up

Detection thresholds

Signal	Known apps (Zoom / Teams / browsers / FaceTime / Discord / Slack)	Unknown apps
Meeting detected	10s sustain	30s sustain
Meeting ended	30s silence (any)	30s silence (any)

After natural meeting-end the state machine returns cleanly to Idle — no automatic 10-min dismissal. Dismissal exists as an internal API for a future "ignore this app" banner action.

Implementation

• state.rs — pure state machine (Idle → Sustaining → Detected → Ending → Idle) parameterized over Instant; 23 unit tests cover priority upgrades, flicker, reacquire debouncing, dismissal cooldowns, and the "not recording" suppression path.
• matcher.rs — hybrid allowlist + blocklist. Blocklist filters Meetily itself (incl. .dev and .debug variants), Apple dictation / voice-memos, third-party Whisper apps (superwhisper, macwhisper, Wispr Flow), and screen recorders (OBS, Loom, ScreenFlow). Allowlist maps bundle IDs to a cross-platform App enum preserved for future enablement.
• signals/mic_activity/macos.rs — CoreAudio via cidre. kAudioDevicePropertyDeviceIsRunningSomewhere as a cheap gate; per-process kAudioProcessPropertyIsRunningInput enumeration only when hot. Bundle IDs from kAudioProcessPropertyBundleID (macOS 14.2+).
• signals/mic_activity/stub.rs — no-op fallback used on non-macOS targets. Detection task still runs but never sees mic activity, so the state machine stays idle and nothing user-visible happens. Zero platform-specific code on Win/Linux means zero new crash surface.
• service.rs — 1s poll loop; DetectionService registered in Tauri state; shutdown() gated on RunEvent::Exit so the poll task exits before state drop.
• audio::recording_commands — pushes recording state into the service via try_state so detection knows whether to fire meeting-ended banners without depending on audio internals.

Tauri surface

• Commands: dismiss_detected_meeting(bundle_id), get_detection_state()
• Events: meeting-detected, meeting-ended (payload: { display_name, bundle_id })
• Debug dropdown in About includes "Meeting detected (auto)" / "Meeting ended (auto)" entries that fire the banners through the real production notification path

Testing

• 23 unit tests pass locally (macOS). State machine + matcher tests are platform-agnostic; matcher tests cover bundle-ID case-insensitivity, blocklist hits, priority ordering, and all public helpers.
• End-to-end validated on the author's machine:
  • Zoom native in-call → banner within ~11s ✅
  • Meetily recording itself → no banner (self-filter) ✅
  • Built-in dictation → no banner (blocklist) ✅
  • Meeting ended during active recording → banner within ~32s ✅
  • Zoom in dock / no call → no banner ✅

Post-deploy monitoring

• Log queries to watch (all at info level):
  • detection: Idle → Sustaining( — candidate crossed observation threshold
  • detection: Sustaining(...) → Detected — banner fired
  • detection: Ending(...) → Idle — natural meeting-end (with / without banner based on recording state)
  • mic-activity snapshot failed — CoreAudio sampler error
  • Meeting detection disabled — failed to init mic-activity sampler — fallback to stub
• Expected healthy behaviour: idle CPU <0.1%; no "snapshot failed" logs during normal operation
• Rollback trigger: user reports of phantom banners for non-meeting apps (>1 report per 24h in first 72h). Rollback is safe — revert this PR; detection simply stops working, no data impact.
• Validation window: 72h post-release on macOS
• Owner: @AzimovS

Follow-up work

Phase 2a: Windows enablement (deferred to a later PR)

• Add settings-level detection_enabled kill switch (settings-file gate checked before spawn)
• Validate end-to-end on real Windows hardware
• Add a WASAPI IAudioSessionManager2-based sampler (draft available in phase2-draft tag)

Phase 2b: Linux enablement (deferred)

• Same kill switch prerequisite
• Validate on PipeWire pulse-compat AND real PulseAudio (application.process.binary key semantics differ)
• Validate reconnect against a PulseAudio daemon restart
• Add a libpulse-binding-based sampler (draft available in phase2-draft tag)

Kill switch design (blocker for Phase 2)

• Add detection_enabled: bool to NotificationSettings (default true on mac, false on Win/Linux until validated per-user)
• Read the setting in detection::spawn and short-circuit if disabled
• Surface toggle in Settings UI
• Support doc: "if the app misbehaves after enabling detection, edit notifications.json, set detection_enabled: false, relaunch"

Supersedes

Closes #34 — this PR is a clean-cut of the macOS-only subset. The Win/Linux work from that PR is preserved in the phase2-draft tag.

Plan documents

• docs/plans/2026-04-20-feat-detect-meeting-start-and-end-plan.md — overall plan (Phase 1 + scoping decisions)
• docs/plans/2026-04-20-feat-meeting-detection-phase-2-windows-linux-plan.md — detailed Phase 2 plan (roadmap for follow-up PRs)
• docs/brainstorms/2026-04-20-meeting-auto-detect-brainstorm.md — origin discussion

🤖 Generated with Claude Code