Skip to content

Dictation telemetry: time Cmd+V, the confirm wait, and the recorder - #2017

Merged
r3dbars merged 4 commits into
mainfrom
claude/project-thread-g2a4v5
Oct 6, 2026
Merged

r3dbars merged 4 commits into
mainfrom
claude/project-thread-g2a4v5

Conversation

@r3dbars

@r3dbars r3dbars commented Oct 5, 2026 •

Copy link
Copy Markdown
Owner

Requested by Justin · project thread

Why

Before: dictation_stop_latency_measured sends stop_to_paste_latency_ms, which runs until paste() returns. That includes the up-to-0.35 s paste confirmation pump, so it overstates when the text actually shows. On 25% of takes paste_bucket is 250-499 ms, and we can't tell how much of that is the confirm wait. It also doesn't say which recorder the take used, and the USB-mic stop cost lives on the pinned recorder only.

After: the same event also carries:

  • stop_to_paste_dispatch_latency_ms (stop to Cmd+V sent; the timing already exists as stop_to_paste_dispatch_ms, it just wasn't sent), rounded to 10 ms like the other reviewed raw timings.
  • paste_confirm_bucket, checkpoint_bucket, resample_bucket: buckets for timings the controller already measures (paste_confirmation_wait_ms, recovery_checkpoint_ms, snapshot_resample_ms).
  • mic_backend: pinned_ioproc, shared_meeting_mic or engine, read before the mic stops.

No UX change. This gives the speed work a true stop-to-text number before any ratchet is built on it.

Product Impact

  • Affects: dictation telemetry only
  • Lane: dictation reliability
  • Why this matters: the next dictation speed fix (ending the paste confirmation wait early) needs a before/after on the right span.

What changed

  • DictationSessionDeliveryTypes.swift: DictationStopTiming.micBackend.
  • DictationSessionController+Stop.swift: sets it from ParakeetEngine.dictationMicBackendName right when the stop timing is created.
  • ParakeetRecordingTeardown.swift: dictationMicBackendName (PinnedMicrophoneCapture.diagnosticBackendName, shared_meeting_mic for a dictation on the meeting's mic, else engine).
  • DictationSessionController+Telemetry.swift: three new bucket mappings, one new exact timing, and mic_backend.
  • Lockstep: Resources/analytics-events.psv, Resources/analytics-reviewed-properties.psv (the raw ms key), docs/privacy-first-observability.md, and Tests/AnalyticsEventPolicyTests.swift (the new keys survive the sanitizer).

How I checked it

  • scripts/dev/agent-preflight.sh
  • bash scripts/dev/linux-checks.sh (runs without Swift): 65 passed, 0 failed
  • python3 scripts/dev/check-telemetry-keys.py: PASS
  • python3 scripts/dev/check-module-boundaries.py: OK
  • Selected checks from .agents/test-matrix.yml (CI)
  • bash build.sh --no-open (CI)
  • bash run-tests.sh (CI)
  • Performance budget passed
  • bash run-integration-smoke.sh (not touched)
  • swift test (not touched)
  • bash run-e2e-smoke.sh
  • Manual check

Checks I could not run, and why:

  • Nothing compiled locally. This is a Linux cloud session with no Swift toolchain, so CI is the first build.

Mac or hardware test still needed? No. After it ships, the PostHog event shows the new keys.

Risk Review

  • Privacy / local-first behavior reviewed: only buckets, one 10 ms-rounded timing, and a fixed three-value recorder label. No device names, paths or text.
  • New analytics properties: listed in the event allowlist, reviewed-properties list, docs, and sanitizer test
  • check-source-pins.py --changed-only: covered by linux-checks
  • No storage impact
  • No user-facing copy change
  • Release/update impact: none. Not for 1.1.70 unless Justin says so; it waits for the RC to finish.
  • Independent deep review of the full diff: READY (/mnt/project-files/reviews/next-release/2017.md). Its low finding (meeting-mic takes read as engine) is fixed in 8894a79. Open low: a pinned take that fell back mid-take also reads as engine.
  • No UI change
  • No private data

Notes

Item 3 in the dictation speed plan (/mnt/project-files/speed/2026-10-05/dictation.md). Follows #2014.

Agent handoff

COORD_DONE: BRIEF | this PR | dictation stop telemetry: Cmd+V timing, confirm/checkpoint/resample buckets, mic_backend | none | merge after 1.1.70 ships, Justin's word | linux-checks, telemetry keys, module boundaries, deep review READY | lanes used: Codex=n/a (cloud session); Claude=n/a (cloud session); Local=n/a; Windows=n/a | CI green, then ask Justin

🤖 Generated with Claude Code

https://claude.ai/code/session_01DEL5vVKCBRYCvxaT5GS1nA

stop_to_paste_latency_ms includes the paste confirmation wait (up to
0.35 s after the text has usually landed), and nothing says which
recorder a take used, so slow mic stops can't be split by backend.

dictation_stop_latency_measured now also carries:
- stop_to_paste_dispatch_latency_ms: stop to Cmd+V sent (10 ms rounded)
- paste_confirm_bucket, checkpoint_bucket, resample_bucket
- mic_backend: pinned_ioproc or engine, read before the mic stops

Registry, reviewed-properties list, privacy doc and the policy test move
in lockstep. No behavior change.

Claude-Session: https://claude.ai/code/session_01DEL5vVKCBRYCvxaT5GS1nA
@r3dbars r3dbars self-assigned this Oct 5, 2026
A dictation during a meeting rides the meeting's mic, not the engine, so
mic_backend now says shared_meeting_mic for those takes instead of engine.

Claude-Session: https://claude.ai/code/session_01DEL5vVKCBRYCvxaT5GS1nA
@r3dbars
r3dbars marked this pull request as ready for review October 6, 2026 02:40
@r3dbars
r3dbars merged commit 5137b42 into main Oct 6, 2026
12 checks passed
@r3dbars
r3dbars deleted the claude/project-thread-g2a4v5 branch October 6, 2026 02:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant