Virtual Keys Inspector silently falls back from TCP and mislabels the source

[malpern]

Tier: 2 (rough edge)

From the pre-release feature-gap audit.

Problem

The Virtual Keys Inspector tries to load live keys from Kanata over TCP and silently falls back to static config parsing on failure/timeout, with no feedback about which path is in use. The TCP result is also labeled as a fakekeys source even when the config source is virtualkeys, creating a UI/data mismatch.

Evidence

• Sources/KeyPathAppKit/UI/Settings/VirtualKeysInspectorView.swift:249-261 — loadVirtualKeysFromTCP() silent fallback; source label hardcoded to fakekeys.

Suggested fix

Indicate the data source/loading state, bound the TCP timeout with feedback, and label the source correctly.

[malpern]

Validated with a reframe — the .fakekeys label is a documented TCP limitation, not a careless mislabel.

The live-TCP path can only return fake-key names (loadVirtualKeysFromTCP() → client.requestFakeKeyNames(), VirtualKeysInspectorView.swift:249-261); Kanata's TCP API doesn't distinguish defvirtualkeys from deffakekeys, so the code tags everything from TCP as .fakekeys (:231). The static-config fallback (VirtualKeyParser.parse) does label sources correctly. So when TCP succeeds, virtualkeys may be shown under the "fakekeys" section header — a real but understandable mismatch.

The silent fallback half is confirmed: loadVirtualKeys() (:224-247) tries TCP (3s timeout) then silently falls back to file parsing with no indication of which path produced the results.

Recommended scope: (1) show which source/loading path is in use (e.g. a "live" vs "from config file" badge), and (2) if the TCP API can't disambiguate source, either don't group by source for the TCP path or label the section generically (e.g. "Virtual keys (live)"). Keeping open at Tier 2 with reframed scope.

---

Generated by Claude Code