[rudycelekli]

The batch dictation client stops its MediaRecorder but never stops the microphone MediaStream tracks. Recording completion therefore leaves capture active, including while a slow or failed transcription upload is pending.

Release all tracks in the dedicated recording stream when onstop runs, before any network await. Explicitly document ownership so an app adapting the example does not shut down a shared voice capture graph. Recorded Blob contents are preserved.

Validation: Node 24 executes the actual TypeScript client snippet with deterministic MediaRecorder/track stand-ins. Unchanged base: two resource-lifetime failures and one successful-transcription control passes. Fixed: all three pass, including pending-upload teardown and network rejection. git diff --check passes. No microphone, vendor account, or live API calls were used.

The success fixture uses a native HTTP Response so the regression suite also composes with #674's response-status handling.

---

Note

Low Risk
Documentation and test-only changes to the dictation skill example; no production runtime paths modified.

Overview
Fixes a microphone leak in the batch dictation client example in add-dictation/SKILL.md: on MediaRecorder stop, the sample now stops every track on the recording stream immediately, before the /api/dictation upload, because MediaRecorder.stop() alone does not release capture.

The comment clarifies that stream should be a dedicated mic stream for that recording so integrators do not tear down a shared voice graph.

Adds dictation-capture.test.cjs, which runs the documented TypeScript snippet in Node with mocked MediaRecorder/tracks and asserts tracks are released on success, on pending upload, and on failed fetch, while the recorded blob and transcription insert still work.

^{Reviewed by Cursor Bugbot for commit 677c893. Bugbot is set up for automated code reviews on this repo. Configure here.}