Feature Request: Voice/speech-to-text input for the Web GUI composer

[LYL534]

Summary

Add a speech-to-text (voice input) option to the Web GUI chat composer so users can dictate long instructions instead of typing, with privacy-first local handling.

Motivation

• Typing long, complex instructions is slow and error-prone; voice dictation makes describing multi-step tasks much more natural.
• Tablet / touchscreen and remote-access scenarios often lack a physical keyboard.
• Accessibility: voice input helps users who have difficulty typing.
• Peer products (Codex client dictation, Claude mobile apps, etc.) already ship voice input; adding it helps Harness reach more users.

Proposed behavior

1. A mic button next to the chat composer input box.
2. Click to start continuous dictation; click again (or auto-stop after a pause) to stop.
3. Recognized text is inserted at the cursor in the composer; the user edits it before sending (never auto-send).
4. Support Chinese, English, and mixed-language dictation, with auto-punctuation.
5. Show interim recognition results when the underlying API supports them.

Privacy (important)

• Privacy-first: prefer local/system speech recognition by default; do not upload audio to third-party services without explicit user consent.
• If cloud STT is offered, it must be an opt-in setting with a clear notice, consistent with the "local-first, data stays on the machine" philosophy of Harness.

Suggested implementation

• v1: browser Web Speech API (SpeechRecognition) - zero dependencies, works in Chrome/Edge, audio stays in the browser.
• v2 (optional): local Whisper (e.g. faster-whisper) for higher-quality offline dictation.
• Cloud STT only as an opt-in.
• Graceful fallback: when unsupported, disable the button and hint at OS-level dictation (Windows Win+H, macOS dictation).

Acceptance criteria

• Mic button starts/stops dictation in current Chrome/Edge.
• Long Chinese dictation (200+ chars) is usable with reasonable accuracy and punctuation.
• Inserted text is editable before manual send.
• No audio leaves the machine without explicit user consent.

Environment

• Windows 11, Chrome/Edge, local DeepSeek Harness Web GUI.

[Jstn-1g]

I built a guarded implementation reference for this composer-dictation seam:

• draft v0.3 PR: feat: launch DSH Live Voice manual-turn preview Jstn-1g/dsh-live-voice#4
• exact verified head: Jstn-1g/dsh-live-voice@4c784d7

The current milestone uses an explicit opt-in Qwen realtime-audio destination rather than claiming that browser speech recognition is necessarily local. No microphone request occurs before the separate Start recording gesture; disclosure exports no DSH history, files, instructions, arbitrary text, tools, or execution authority.

After one bounded turn, only a completed, final user transcript can be handed to the editable composer. The click re-reads the live voice lifecycle, requires the unchanged draft revision and the stable per-Session composer-action identity captured at consent, consumes that binding once, preserves transcript bytes, and calls only setDraft—never submit. A same-text-ID Session replacement regression was reproduced, fixed, and independently reverified.

Exact-head evidence: 191/191 tests plus strict types/build/package checks; a packed official-Harness + controlled fake-Qwen composition completed real workspace/session binding, disclosure, 4-byte input/output, both final transcripts, and provider teardown. The unchanged raw-pagehide path also has controlled-Chromium proof for track/AudioContext/socket cleanup with no post-teardown audio frames.

This is still a development reference, not a parity or release claim: credentialed Qwen, physical microphone/speaker and OS indicator behavior, packaged Desktop, BFCache restoration, continuous turns, and barge-in remain open gates in Jstn-1g/dsh-live-voice#5.

[Jstn-1g]

A concrete update to my earlier development-reference comment: the renamed project now has an immutable DSH Live Voice Preview.5 with a zero-credential synthetic-demo first-run path.

Because your stated environment is Windows 11 with Chrome/Edge, one narrow result from you would be directly useful: install Preview.5 in a disposable DSH Web profile, run disclosure → fixed local synthetic turn → explicit draft handoff, and report the last stage that worked in founding-tester issue #58.

dsh plugin --profile web add github:Jstn-1g/dsh-live-voice#v0.3.0-preview.5

This does not test or claim the microphone/STT, Chinese recognition, Web Speech privacy, or physical-audio acceptance criteria in this request. It tests only installation, control visibility, disclosure, fixed local transcripts/chime, explicit draft placement, and no automatic submission. Please do not share recordings, credentials, real transcripts, Session IDs, tokens, cookies, workspace content, personal data, or identifying logs; a stopping-point report is as useful as a pass.

dsh plugin --profile web remove dsh-live-voice