Teknium 514dd59cad fix(wake): detect dead-mic streams, stop the ear freezing during first-use install ... Internal testing (macOS): clicking the ear froze the button for ~30s, then it went blue but 'hey hermes' never fired even though STT worked. Two distinct bugs: 1. Frozen-then-timeout button: first-use wake.start lazy-installs the detection engine (onnxruntime is a large wheel), which blows the desktop's default 30s WS request timeout — the RPC 'failed' client- side while the backend kept installing and armed later on its own. wake.start now gets a 180s budget and the pending state says 'arming — first use may take a minute while the engine installs' instead of a silent disabled button. 2. Armed but deaf: macOS grants mic permission per PROCESS. The renderer having mic access (STT working) does not grant the Python backend anything — CoreAudio hands an unentitled process a 'working' stream that delivers zeros forever, so the listener looks healthy and can never hear the phrase. The detector now tracks frame peaks: 10s of consecutive near-zero frames sets audio_silent, logged with the exact macOS Settings path, cleared automatically when audio appears. Surfaced everywhere: wake.status (audio_silent + hint), desktop ear tooltip (kept visible while listening), /wake status on TUI (⚠ line) and classic CLI, plus a docs troubleshooting section. Tests: detector silent-flag set/recover cycle (fake silent/loud streams), desktop tooltip keeps the dead-mic hint while listening. 44 wake Python tests, 22 desktop + 14 TUI vitest green.		2026-07-28 07:59:34 -07:00
..
bootstrap-installer	fix(installer): stamp the bootstrap-complete marker from the Rust installer	2026-07-26 16:02:13 -05:00
desktop	fix(wake): detect dead-mic streams, stop the ear freezing during first-use install	2026-07-28 07:59:34 -07:00
shared	refactor: drop the shared subpath export, keeping package.json untouched	2026-07-28 03:54:49 -05:00