fix(settings): clear orphaned per-prompt shortcuts on legacy retirement

[shivanshsen7]

Description

Retiring the legacy secondary-prompt-mode hotkey (retireLegacySecondaryPromptShortcutIfNeeded()) clears PromptModeHotkeyShortcut / PromptModeSelectedPromptID, but never touches DictationPromptConfigurations — a separate, still-active data store used by the current "Custom shortcut per AI Prompt profile" feature.

dictationPromptShortcutAssignments() turns every stored .shortcut in DictationPromptConfigurations into a live global hotkey unconditionally, with no dependency on PromptModeShortcutEnabled or either retirement flag. Any residual .shortcut left over from before the legacy hotkey was retired — most commonly a bare Command keypress under the __default__ entry — keeps firing forever, even though nothing in Settings shows or lets you clear it.

This matches the two independent reports on #675: both show the exact same orphaned keyCode: 55 (Command) under __default__, despite having different Primary Dictation shortcuts configured (Right Option / Right Control). That consistency across unrelated users is why I'm confident this is leftover legacy state rather than an intentional per-profile shortcut.

This PR clears any stale .shortcut bindings once, at the same retirement boundary that already governs PromptModeHotkeyShortcut, while preserving any real providerID/modelName overrides a user may have set on a prompt configuration.

Type of Change

• 🐞 Bug fix
• ✨ New feature
• 💥 Breaking change
• 🧹 Chore
• 📝 Documentation update

Related Issue or Discussion

Fixes #675

Testing

• Tested on Intel Mac
• Tested on Apple Silicon Mac
• Tested on macOS version: 26.5.2
• Ran linter locally: swiftlint --strict --config .swiftlint.yml Sources (SourceKit crashes on this machine — only Command Line Tools installed, no full Xcode; see note below)
• Ran formatter locally: swiftformat --config .swiftformat Sources — diffed --lint output against unmodified main for both touched files; this change introduces zero new formatting findings (45 pre-existing findings unrelated to this change, unchanged before/after)
• Ran tests locally (blocked — see note below)

Note on local verification: this machine only has Command Line Tools, not full Xcode, so xcodebuild test isn't available and swiftlint crashes on a missing sourcekitdInProc framework. I verified both changed files parse cleanly with xcrun swiftc -parse, and confirmed with swiftformat --lint that this diff adds no new style issues. I also manually reproduced the exact preference-file shape from #675 on my own affected install (DictationPromptConfigurations.__default__.shortcut = {keyCode: 55, modifierKeyCodes: [55]}, PromptModeShortcutEnabled = false) and applied the equivalent of this fix via defaults delete as a live workaround, which stopped Command from triggering dictation without disturbing the configured Primary Dictation shortcut. The new regression test reproduces that same data shape and asserts dictationPromptShortcutAssignments() — the source GlobalHotkeyManager reads for these hotkeys — ends up empty after cleanup. CI (build.yml, macos-latest with full Xcode) should be able to run the full suite including this test.

Screenshots / Video

• No UI/visual changes; screenshots/video are not applicable.

Notes

clearOrphanedDictationPromptShortcuts() clears .shortcut on every entry in DictationPromptConfigurations, not just __default__, since the legacy single-shortcut system could plausibly have left residue under __privateAI__ or a profile:* key too. The tradeoff: if anyone genuinely used the current "Custom shortcut" editor (Advanced AI Settings → prompt editor → "Custom shortcut") to bind a shortcut before updating past this migration, that binding would also be cleared. Given both #675 reports show the identical keyCode: 55 artifact regardless of their actual configured Primary Dictation shortcut, I believe this is safe, but happy to narrow the scope (e.g. only __default__, or only shortcuts matching the known legacy default) if you'd prefer — you have visibility I don't into how many users use per-profile custom shortcuts today.

[postoso]

Had a close look at this against current main after #815 landed. The diagnosis and the plist evidence in #675 are useful. I found two coupled blockers in the implementation:

The cleanup cannot run on the installs it targets. retireLegacySecondaryPromptShortcutIfNeeded() returns when LegacySecondaryPromptShortcutRetired is already true. That flag has been set once on first launch since 1.6.3, and it is already true in the affected plist shared in #675. The new cleanup needs its own one-shot version key rather than reusing the retirement flag.

Giving it a fresh key makes the current cleanup too broad. DictationPromptConfigurations is the live store behind Advanced AI Settings > prompt profiles > Custom shortcut. Clearing .shortcut from every __default__, __privateAI__, and profile:* entry would erase legitimate user-created bindings. The migration should be restricted to an independently confirmed orphan signature and preserve every other prompt shortcut.

I would also pin down the writer before choosing that signature. The retirement commit does not write to DictationPromptConfigurations, that store arrived with the current per-prompt editor, and the old PromptModeHotkeyShortcut default was Right Shift (key code 60), not Command (55). If a live recorder path can still commit bare Command, a one-shot cleanup will not hold.

One smaller workflow note: because this is still a draft, the main build/lint/test workflow has not run yet. The branch conflict is limited to HotkeyShortcutTests.swift next to #815's new tests; SettingsStore.swift merges cleanly.

Happy to help with the rebase and run the full lint/build/test gate once the migration signature is narrowed, if that would be useful.

[shivanshsen7]

I just added as draft coz i felt that it will be burden as its full ai generated and i thought it could help as i loved the app.
If its for me to work on it, i'd love to contribute back, or if its better that you take ownership feel free to.
Regardless i will rebase and work on ur feedback so changes are visible to you.

[postoso]

whatever you want. I also use this app all the time and so I've started contributing too.