Implement correctly
Build Dropdown menu without breaking its behavior
# Implement Dropdown menu in your agent ## Objective Implement Dropdown menu for this verified behavior: A compact list of actions that opens from a button and supports menu-style keyboard navigation. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Dropdown menu matches the need before writing code. ## Required behavior - Activating the trigger opens the surface, and activating it again can close it. - Arrow keys move through available actions while Enter or Space activates one. - Escape closes the temporary surface and returns focus to a sensible control. ## States to cover - Menu closed - Menu open ## Accessibility - ARIA role: menu > menuitem - The primary control or named region for Dropdown menu has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - Opening places menu focus on an enabled item; closing restores focus to the trigger. - Selecting an action, pressing Escape, or safely pressing outside closes the menu. - The trigger exposes that it opens a menu, and item names, disabled states, and checked states are announced. - Enter, Space, or Arrow Down opens the menu - Arrow keys move between items - Enter or Space activates the active item - Escape closes the menu ## When not to use - The user is selecting a value for a form field - The content contains explanatory paragraphs or a form ## Acceptance criteria - Every item is an action rather than a form value - Arrow-key navigation follows the menu pattern - Disabled items expose their state and cannot be activated - Closing restores focus to the trigger ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
- @radix-ui/react-dropdown-menu
- Requires · Access to the repository, design system, and tests
Why it works
- The need is tied to canonical behavior before any technical choice.
- States, accessibility, and non-goals prevent a merely visual implementation.
- Acceptance criteria and the output format make verification observable.
Try next
Verify Dropdown menu on a real journey
# Verify Dropdown menu after implementation ## Objective Audit the Dropdown menu implementation against its behavior, states, and accessibility requirements without changing it automatically. ## Checks - Replay the smallest representative journey. - Check keyboard behavior, focus, accessible name, and announcements. - Tie each gap to a specific acceptance criterion. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
sha256:a4759625ed0017bb741be0656bd0eb5fc09ff02389153f5a0a2bc48f7866db49