feat: dictate from any app, with a widget that sends to a session (core 0.43.0)

[Maxaubert]

Stacked on #244 (the orchestrator): merges after it; retarget to main before #244 merges with its branch deleted.

Owner, 2026-10-16: "you can start the dictation while not having the app in focus ... you should still see like a sort of widget ... if you don't have an orchestrator ... the widget will show like a list of sessions and you essentially just click or pick the session ... if you have the orchestrator the widget will just show something like completed with a check mark and sent ... only if the orchestrator is actually active"; "one dictation key ... control plus the windows key"; number keys in the list: "an excellent idea". Spec and plan (approved): docs/superpowers/specs/2026-10-16-dictate-anywhere.md.

What the owner gets

• One dictation key, Ctrl+Win by default (right Alt is AltGr on a Norwegian keyboard). A saved key is kept. Inside the app nothing changes.
• With another app in front the key starts dictation and a widget shows on the screen the pointer is on: never takes focus, above every window, sized for 225% zoom, in the theme's inks.
• Then: an active orchestrator (switched on, promoted, its Claude running per Windows, not asking) gets the words, the widget says Sent to with a check mark; otherwise the widget lists the Claude sessions numbered 1 to 9 (click or press the number; Esc keeps it unsent; 30 s and it lapses). A tab that is asking is listed but disabled.
• Settings > Dictation > Dictate from any app, on by default when dictation is on.

Core (Prism gets the key default)

• DEFAULT_HOTKEY Ctrl+Win; a chord of modifiers follows the solo rules (either key first; Ctrl+Win+Left is no dictation; the settings field binds it).
• dictationOutside / setDictationRoute: a host starts a recording that belongs to no tab and takes what was heard (or why not: no model, nothing heard, cancelled).
• DictationPage takes after rows.

App

• src/main/hook/globalKeyHook.ps1 + globalDictKey.ts: a WH_KEYBOARD_LL hook in a long-lived Windows PowerShell (like the DWM helper). MEASURED spike: 0.3 to 1.2 ms key to event, ~0.35 s to start, no CPU at rest, no Defender detection. Reads only the binding's keys, "another key" (never which), and digits/Esc only while the list is open (swallowed then). Masks the Start menu after Ctrl+Win (VK 0xE8). Never runs under --e2e.
• dictateAnywhere.ts: the widget window (sandboxed, never navigates) and the routing, through the same checked send path as the orchestrator (sessionsWire.sendInto: Windows' process check, decided again before typing and before Enter). The rule 2 exception's entry now names it.
• src/renderer/overlay.html, src/preload/overlay.ts: the widget page (impeccable) and its bridge.

Tests: unit 2288 pass (key chord 4, the hook helper on a real F24, the feed, the route and the rows). e2e dictateAnywhere 9/9: no orchestrator lists the session and "1" sends and enters it; an active orchestrator gets it with no list; the widget is unfocusable and on top; Ctrl+Win from another app opens it. Screenshots: .e2e-shots/dictation-widget-pick.png, -sent.png. Full e2e: every scenario passed but the two existing Right Alt dictation scenarios, which assumed the old default; they now set their key and pass (dictation 21/21, dictationParakeet 11/11). "The real clipboard: untouched by the run".

Owner's hands-on list (needs a real keyboard): Ctrl+Win hold from another app; the Start menu staying shut after it; Ctrl+Win+arrows still switching desktops; picking with a number key.

Since the owner tried it (2026-10-17)

• Two copies both took every press (MEASURED in both diag logs: Stable and the installed app each ran the hook; the second failed in 8 ms with "No microphone found" and its widget covered the first's). One copy now holds the key (a lock file; a named Mutex hung the waiting helper, MEASURED), and a saved mic that is gone falls back to the system default.
• One dictation (owner: "they should be the same thing ... one dictation engine for both"; spec docs/superpowers/specs/2026-10-17-one-dictation.md, approved): the hook reads the key with the app in front too, one widget everywhere, and the copy holding the key runs the dictation for every copy over a local pipe (dictationLink). Words for a copy whose window was in front are pasted at its cursor, never Enter; otherwise the orchestrator or the list, which holds every copy's sessions. e2e dictateTwoCopies.
• The link is authenticated (security review): both ends prove they hold a per-user key (PrismDictation\link.key, HMAC over fresh nonces); the pipe is named by the key's hash.
• Performance, startup first (owner: "it's mainly startup performance"; report research/prism-terminal/2026-10-17-dictation-performance.md):
  • Parakeet stays loaded in a resident host (core/dictation-host/parakeetHost.ps1, P/Invoke into the engine's own parakeet.dll): 24 to 170 ms a pass against parakeet-cli's 0.72 to 0.86 s on the owner's RTX 5090, the text identical; ready 0.8 s after launch.
  • One helper process at launch (src/main/hook/appHelper.ps1) for the DWM attributes and the key hook, where there were two; compiled C# cached (up 320 -> 220 ms).
• The resume skeleton is no longer drawn over by xterm's link decorations (the owner's "thin blue lines"): the terminal region is isolate. e2e launchSkeleton fails without it.

Full e2e: every scenario passed; updateWindow was re-run alone after a version file changed under the run, and passes. Unit 2302.

Core 0.42.0 -> 0.43.0, app 0.56.0 -> 0.57.0.

🤖 Generated with Claude Code

https://claude.ai/code/session_017XYVRPzvhLpPCr75uB6uaA