Captures the 12 items from docs/code-review-2026-04-22.md that must land before v0.1 ships. One markdown file per issue with: severity, path:line, problem description, acceptance criteria, fix scope, and dependency graph. Split by severity: - 3 CRITICAL: live-session race, migration atomicity, transcript- profile FK - 9 MAJOR: monolith refactor, channel-fatality, capture worker join, runtime capabilities, macOS App Nap, decoder error prop, LLM prompt preflight, keystore thread-safety, hotkey device filter README.md indexes them with a fix-order dependency graph and a fish-shell script for bulk-converting to GitHub issues once `gh` CLI is installed and authed. Deferred step by user decision — markdown tracker is authoritative until then.
1.3 KiB
1.3 KiB
RB-12 MAJOR: hotkey device filtering hard-codes KEY_A / KEY_R
Severity: MAJOR
Path: crates/hotkey/src/linux.rs:236-241
Source: 2026-04-22 code review
Labels: release-blocker, major, hotkey, correctness
Problem
try_attach_device claims to check whether an input device supports the configured hotkey's key, but the implementation tests for hard-coded KEY_A or KEY_R instead of consulting the actual HotkeyCombo that was configured. Hotkeys bound to any other key (which is most of them) can be silently skipped even when the device supports them.
This is a correctness bug in a user-facing feature. A user who binds Kon to Ctrl+Shift+D and sees "no hotkey fires" has no obvious path to diagnose it.
Acceptance
- Device attachment consults the actual configured
HotkeyCombo.triggerkey code. - Regression test:
try_attach_devicecalled with a mock device that supportsKEY_Dattaches when the configured hotkey's trigger isD, does not attach when the trigger is a key the device doesn't support. - Manual verification: bind
Ctrl+Shift+Din Settings, confirm it fires in a running Kon.
Fix scope
Small. Replace the hard-coded constants with a lookup from the passed-in HotkeyCombo.
Dependencies
- None — standalone fix.