Three commits from one investigation into a paid user's report: a 40-min meeting "recorded both sides for the first ~5 min, then stopped, detection stayed green the whole time." I pulled his attached engine log to ground each step.

What the log proved (so we stop guessing)

• He is on ScreenCaptureKit (default), not the experimental tap.
• In the ~18 min the log covers (it was truncated to the last 100KB, cutting off the 5-min mark), both sides were captured and transcribed: live Deepgram finals for System Audio and his mic ran continuously to teardown, 90 successful batch transcriptions of System Audio (output), and 494 live segments mirrored into audio_transcriptions.
• So the data exists on three paths. His "stopped recording" is a surfacing problem, not a capture problem.

Commit 3 (the most likely fix for his report): don't drop live transcript segments

The post-call meeting view reads audio_transcriptions, which only gets a live segment if mirror_live_meeting_to_audio_transcriptions copies it in. That mirror silently dropped any segment whose nearest same-device audio chunk fell outside a fixed ±15s window:

live final "captured_at" drifts (provider finalizes a turn seconds late,
long chunks, capture gaps) ──► no chunk within ±15s ──► segment SKIPPED
                                                          (continue;)
   ──► never written to audio_transcriptions
   ──► gone from meeting notes / timeline / search after the call

Fix: fall back to the nearest same-device chunk regardless of window instead of dropping (the row keeps the segment's real timestamp, so search/timeline stay correct; device attribution stays strict). Also aligned a case-sensitive device match in mark_chunks_covered_by_live to the case-insensitive match its sibling mirror already used (a casing difference left meeting chunks pending and inconsistent). Two regression tests added; all coverage/mirror/dedup tests pass.

Commit 2: tap-only aggregate (separate audio-capture improvement)

The CoreAudio Process Tap anchored its aggregate to the system default output, so when call audio routed elsewhere (AirPods/HFP/per-app) it captured zeros. Switched to a tap-only aggregate so capture follows the app's audio. This is NOT his bug (he's on SCK, and the log shows SCK capturing both sides) — it's a real fix for users who opt into the tap, behind the experimental flag, default unchanged. Not hardware-verified (needs a Bluetooth headset on a live call).

Commit 1: doc + PII cleanup

Corrected the stale experimental_coreaudio_system_audio doc and removed real customer names that had leaked into this public repo (comments + test fixtures), generated tauri.ts kept in sync.

Honest status

• Commit 3 is tested (db crate, no hardware) and is the diagnosis-driven fix for the surfacing class his log points to. I could not pin the single dropped row because his log was truncated past the failure and his DB is on his machine — but the mechanism (mirror dropping segments on a window miss) is real and fixed.
• The "froze live during the call" half of his symptom likely also wants a frontend change: the live transcript panel builds only from push events and never reconciles against the persisted segments, so a stalled event stream leaves a gap until reload. Flagging as the companion follow-up; not in this PR.
• These are three distinct concerns on one branch for review convenience. Happy to split commit 3 into its own PR if you'd rather merge it alone.

🤖 Generated with Claude Code