Add semantic live transcript triggers with ntfy notifications

[nmittal1999]

Problem

TalkTrack only transcribes after a recording stops. Users need near-real-time ntfy alerts when meeting context satisfies natural-language rules, such as work becoming ready for validation.

Proposed design

• Non-blocking system-audio tap at DualAudioCapture, compatible with both per-app and legacy capture.
• Sliding live Faster-Whisper windows, resampled to 16 kHz when needed.
• Rolling transcript context with a local embedding prefilter.
• Final semantic decision by TalkTrack's selected AI provider using strict structured output.
• Per-rule cooldown/rearming and duplicate suppression.
• ntfy publishing with server/topic and optional Bearer token.
• Settings UI for enablement, rules, model, cooldown, ntfy connection, and test notification.
• Clean pause/stop/shutdown behavior; recording callbacks must remain non-blocking.

Privacy

Audio remains local. Only shortlisted rolling-transcript excerpts are sent to the configured AI provider. The local provider keeps evaluation entirely local.

Acceptance criteria

• Natural-language rules recognize paraphrases and reject negated/non-matching context.
• Notification delivery never blocks or interrupts recording.
• Duplicate transcript windows do not produce notification spam.
• Both Windows 11 per-app capture and legacy loopback are supported.
• Failures are surfaced without exposing tokens in logs.
• Pure logic and lifecycle paths have focused automated tests.

[ObscureAintSecure]

Parking this one under needs-design rather than picking it up. Not a no, and not a comment on the write-up, which is more thought-through than most feature requests get. It needs a scope decision before any code, and I'd rather make that deliberately than drift into it.

What gives me pause, so it's on the record for whenever we come back to it:

It's several features, not one. Live windowed transcription, a rolling context buffer, an embedding prefilter, AI rule evaluation with structured output, per-rule cooldown and rearming, and an ntfy client with its own settings UI. Each is independently reasonable. Together they're a large surface, and the failure modes compound — a duplicate-suppression bug and a cooldown bug look identical from the outside.

The capture tap is the risky part. TalkTrack's audio callbacks have a hard non-blocking invariant (.claude/rules/audio-pipeline.md): the callback copies, processes, hands off to a queue, and returns. Anything that can stall — an embedding, an HTTP call, a model inference — cannot live on that path. A "non-blocking tap" is the right instinct, but it's the part that has to be got exactly right, and it's where a subtle regression would show up as dropped audio in recordings that have nothing to do with notifications.

Today's pipeline is batch by design. Transcription runs after stop, serially, one job at a time, with the session bound at start (.claude/rules/transcription-pipeline.md). Live transcription isn't an addition to that, it's a second pipeline running concurrently with capture, competing for the same model and the same GPU. That's the architectural question, and it's worth answering before anything gets built.

If this does move forward, the split I'd want is: land live transcription on its own first, with no rules and no notifications, and see how it behaves during real calls. The semantic triggers and ntfy delivery are comparatively easy once there's a live transcript that's proven not to disturb recording. Doing it in that order also means the risky part gets evaluated on its own merits instead of arriving bundled with five other things.

Leaving it open and labelled. Thanks for the detailed proposal, including the privacy section — that's the right thing to have thought about upfront for a feature that ships transcript excerpts to a provider.