Repository navigation
Assess command palette mode transitions #10254
Description
Activity
Independent Astra-medium verdict: reject an added palette mode transition.
At base
eee05575ebd514db36f61d7eb05d2258a10c96bd,CommandPalette.tsx:538–570preserves one Base UI dialog popup and immediately replaces command/file/content search tasks, updating its accessible label and mode.:439–448intercepts Escape from file/content to return to commands;:550–553returns final focus to the composer.ui/command.tsx:58–89already uses the existing local popup andui/dialog-styles.ts:1–5supplies the opening/closing transition.A content crossfade would either retain two interactive search trees during overlap, require extra inert/focus handling, or fade in an already-focused input and results. A wait-for-exit transition delays repeated keyboard use. A tiny nonblocking entrance-only fade avoids those problems but adds decoration without explaining a demonstrated relationship; the stable popup already supplies continuity. No measured or reproduced continuity defect supports implementing it.
Overlap checked: sidebar PRs #9431/#9424/#9967 do not own this dialog; dirty design-quality-motion-policy overlay is limited to toast/spinner/status animation and does not add palette mode transitions. Current shadcn Command and Motion layout were inspected; preserve the local Base UI composition. Human Interface Craft p10 §14/15, p11 §16, p13 §23 favor immediate repeated use and focus continuity here. No code, worktree, PR, or runtime proof claimed for this rejected suggestion.
Triage
Motion-audit assessment ticket (not a user bug): should command / file / content search crossfade or otherwise animate inside the existing dialog, without changing query/selection, focus return, Escape hierarchy, keyboard speed, or reduced motion?
Verdict: reject an added palette mode transition. The requester already recorded an independent Astra-medium reject (comment). I checked the same
main(eee05575e) and agree. No code or PR.What already exists
One reducer owns open + mode so the three surfaces cannot stack. The same Base UI popup stays mounted and immediately replaces the task, updating its accessible name and
data-palette-mode:CommandPalette.logic.ts—SearchOverlayModeis"command" | "files" | "content";ToggleModeswitches while open, or closes if the same mode is hit againCommandPalette.logic.test.ts— covers switching modes without closingCommandPalette.tsx— oneCommandDialogPopup; children are a ternary (ProjectFilePicker/ProjectContentSearchDialog/ command view), not overlapping treesui/command.tsx— local Base UI dialog popup (not a second overlay)ui/dialog-styles.ts— existing 200 ms open/close scale/opacity/translate. Height is not in that list, so the content-modeh-105snap is instant
Escape, focus, and query behavior are already the constraints this ticket asked to preserve:
- Capture-phase Escape from file/content returns to commands (
CommandPalette.tsx);onOpenChangealso cancels a dialog-level escape-close when not in command mode (:503) - File and content chrome label Escape as Back (
ProjectFilePicker.tsx,ProjectContentSearchDialog.tsx) - Each remounted mode focuses its input immediately (
CommandPaletteContent.tsx); closing returns focus to the composer (CommandPalette.tsx) - Query/selection live in each mode’s own state and remount on switch. That is the current contract; a wait-for-exit or overlapping crossfade would change it
A content crossfade would keep two interactive search trees during overlap, need extra inert/focus handling, or fade in an already-focused input. A wait-for-exit transition delays repeated ⌘K / ⌘P / ⇧⌘F use. A tiny entrance-only fade avoids those problems but adds decoration without a demonstrated continuity defect — the stable popup already supplies the relationship.
Related work (not this ticket)
Adjacent only: #7495 keeps dialog payload mounted through the close animation (including leaving content-search mode in place until the next open). It does not add mode-to-mode motion.
Sidebar PRs #9431 / #9424 / #9967 do not own this dialog. Current shadcn Command is a single dialog + list composition; preserve the local Base UI Autocomplete popup rather than introducing a Motion layout handoff.
Siblings #10248–#10255 are separate motion-audit scopes, not duplicates of this one.
Next step
Close as wontfix. Do not implement. Remaining acceptance items (implementation, cross-provider review, before/after captures) do not apply to a rejected addition.
Assess and, if useful, implement restrained transitions between command/file/content search modes within the existing dialog. Preserve query/selection behavior, focus return, Escape hierarchy, keyboard speed, and reduced motion.
Requested by Alex after the T3 UI motion audit. First record an independent Astra-medium accept/revise/reject verdict with source evidence. Accepted changes should end in small focused PRs; do not implement a rejected suggestion.
Use the installed shadcn-motion-ui skill and Human Interface Craft guidelines (feedback, relationship, continuity, accessibility, signature moments). Consult current official docs, reuse local primitives, verify installed API compatibility and add exact source references. Respect native platforms, reduced motion, interruptions, responsiveness, focus, and performance. No continuous repaint loops or framework rewrites.
Acceptance:
Do not change live user data, the dirty primary checkout, existing Stash worktree, or unrelated work. No merge or deployment is requested.