Implement correctly
Build Popover without breaking its behavior
# Implement Popover in your agent ## Objective Implement Popover for this verified behavior: A small contextual surface opened deliberately to show supporting content or controls without making the whole page modal. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Popover matches the need before writing code. ## Required behavior - Activating the trigger opens the surface, and activating it again can close it. - A pointer press outside the noncritical surface dismisses it without committing an action. - Escape closes the temporary surface and returns focus to a sensible control. ## States to cover - Popover closed - Popover open ## Accessibility - ARIA role: dialog - The primary control or named region for Popover has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - Focus either remains on the trigger for simple content or moves predictably to the first meaningful control. - Escape, the explicit close control, or a safe outside press closes it and restores focus to the trigger. - The trigger exposes expanded state and references the popup; a named dialog is announced when that pattern is used. - Enter or Space opens from the trigger - Tab moves through interactive content - Escape closes the popover ## When not to use - The task needs a large or modal workflow - The surface is only a short passive hint ## Acceptance criteria - The panel opens only after deliberate activation - Interactive content has a logical focus order - Escape and the close control restore focus - The background remains usable because the panel is nonmodal ## 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-popover
- 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 Popover on a real journey
# Verify Popover after implementation ## Objective Audit the Popover 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:f85f45220d4288035b36bc34b96ce6f32e859aa2329b9f39444809c1ec592928