Fix shortcut detection and floating bar memory usage

[kodjima33]

Summary

• Fix shortcut detection in onboarding: ⌘-key combos (⌘O, ⌘J, ⌘Return) were consumed by NSMenu's performKeyEquivalent before the event monitor could detect them. Temporarily strip the main menu during the shortcut test steps, restore on leave.
• Fix floating bar not using memories: Updated system prompt to always check user memories before answering, give direct personalized answers, and never ask follow-up questions.

Test plan

• On shortcut step, press ⌘O / ⌘J / ⌘Return — buttons should light up
• On voice shortcut step, press and hold Option — button should light up
• Ask floating bar "which computer should I buy?" — should give personalized answer using memories

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

Fixes ⌘-key shortcut detection during onboarding by temporarily setting NSApp.mainMenu = nil, preventing NSMenu's performKeyEquivalent from consuming key events before the local NSEvent monitor sees them. The DispatchQueue.main.async deferral is intentional and correct — it ensures the save runs after both onAppear and onDisappear complete within the same run-loop cycle during SwiftUI's Group-based view swap. Also updates floatingBarSystemPromptPrefix in ChatProvider to direct the model to always check memories and respond without follow-up questions.

Confidence Score: 5/5

Safe to merge — fix is correct for the normal onboarding flow and all remaining findings are P2

The DispatchQueue.main.async pattern correctly handles SwiftUI Group navigation ordering. The only concern is a window-close edge case (P2) that doesn't affect the primary onboarding path. No P0/P1 issues found.

OnboardingFloatingBarShortcutStepView.swift and OnboardingVoiceShortcutStepView.swift share a window-close edge case worth hardening

Important Files Changed

Filename	Overview
desktop/Desktop/Sources/OnboardingFloatingBarShortcutStepView.swift	Adds static savedMenu + NSApp.mainMenu nil pattern to fix ⌘-key detection; deferred via DispatchQueue.main.async; missing window-close safety net
desktop/Desktop/Sources/OnboardingVoiceShortcutStepView.swift	Mirrors menu save/restore from FloatingBar step; savedMenu lacks doc comment; shares the same window-close edge case
desktop/Desktop/Sources/Providers/ChatProvider.swift	Prompt-only change to floatingBarSystemPromptPrefix instructing always-check-memories and no follow-up questions

Sequence Diagram

sequenceDiagram
    participant U as User
    participant SW as SwiftUI
    participant KM as installKeyMonitor
    participant M as NSApp.mainMenu

    U->>SW: navigate to shortcut step
    SW->>KM: onAppear()
    KM->>KM: addLocalMonitor
    KM->>KM: addGlobalMonitor
    KM-->>M: DispatchQueue.main.async (next run-loop)
    M->>M: savedMenu = mainMenu
    M->>M: mainMenu = nil
    U->>SW: press ⌘ key
    SW->>SW: localMonitor fires (not swallowed by NSMenu)
    SW->>SW: shortcutDetected = true
    U->>SW: click Continue
    SW->>KM: onDisappear()
    KM->>KM: removeMonitor(local + global)
    KM->>M: mainMenu = savedMenu
    M->>M: savedMenu = nil
    Note over U,M: ⚠️ P2: if window closes via red-X,
onDisappear is skipped → mainMenu stays nil

Loading

_{Reviews (1): Last reviewed commit: "Fix floating bar to use memories and nev..." | Re-trigger Greptile}

[greptile-apps]

No safety net if onDisappear is skipped

NSApp.mainMenu is set to nil here and only restored in removeKeyMonitors(), which is called from onDisappear. If the onboarding window is closed via the red-X button (or any code path that doesn't trigger onDisappear), the menu is never restored — permanently removing Quit, Preferences, Edit, and all menu-bar actions for the session. Consider adding a NSWindow.willCloseNotification observer as a fallback when the menu is nil'd, and removing it when removeKeyMonitors() runs normally. The same gap exists in OnboardingVoiceShortcutStepView lines 274–277.