Snapshot the Target First

"By the time you have the words, the cursor may have moved. So remember where it was."

Capture Before the Pause

Insertion's first job happens before a single word is transcribed. The moment the hotkey goes down — before any overlay appears — Firekeeper snapshots the target: the frontmost app's name and bundle id, whether the focused element is a secure field, the selected text if any, a coarse classification of the app (terminal, editor, email, chat, browser, other), and — only when Context Awareness is on and the field is not secure — a bounded slice of nearby text. The overlay is non-activating on purpose, so showing it doesn't steal focus from the field you meant to type into.

Why the Snapshot Matters

Between hotkey-down and insertion, seconds pass — STT runs, cleanup runs. In that window, focus can drift: you glance at another window, an app raises a dialog, a notification steals focus. If insertion just typed into "whatever is frontmost now," your dictation could land in the wrong app entirely — worst case, posted into a chat you didn't mean to. The snapshot is the fixed target: insert into the app you were in when you started talking, not wherever focus wandered to.

hotkey down  -> snapshot { app, bundle id, secure?, selection, category }
  ... STT ... cleanup ...   (focus may drift here!)
insert       -> is frontmost app still snapshot.app?
                 yes -> insert into the captured target
                 no  -> DON'T type into the wrong app; clipboard + notify

The Wrong-App Guard

The guard is a single comparison with a strict consequence. At insertion time, check whether the frontmost app still matches the snapshot. If it changed, Firekeeper refuses to paste — it copies the text to the clipboard and notifies you instead. "Insert into the right app or don't insert" is the rule; typing into the wrong app is worse than not typing at all, because you can always paste manually but you can't un-post a message. This one comparison prevents the single most alarming failure a dictation app can have.

EV v2 · 2026-10-12: A cross-brain review on 2026-09-27 found the hole a guard like this leaves when it guards only one kind of effect. A spoken "press enter" with nothing else to insert left empty text, and the empty-text path pressed Return before the secure-field and changed-app checks ran — so a Terminal Dad had switched to during transcription received the Return. Now one gate, InsertionGate, rules on pasted text and a bare Return alike before any side effect, and whether Return may go out is asked again at the moment it is posted. The same review found the family's own terminal app unclassified, so its shells took a spoken Enter as a command; it is now on the terminal list. Guard every effect, not just the common one.

Bind the action to the target you captured, not the target you find. Any operation with a delay between intent and effect must remember its target at intent-time and verify it at effect-time. The current state of the world at effect-time is not a safe substitute for the state you actually meant — especially when the effect is irreversible, like posting text into a live app.

Never read a secure text field. Part of the snapshot is detecting whether the focused element is a secure/password field. If it is, Firekeeper reads no context from it and treats it as off-limits. A voice tool that inspected password fields would be a catastrophe; the capture step is where that boundary is first enforced.

Capture Before the Pause

Why the Snapshot Matters

The Wrong-App Guard

Code

External links

Exercise

Progress

Comments 0