Implement correctly
Build Drawer without breaking its behavior
# Implement Drawer in your agent ## Objective Implement Drawer for this verified behavior: A temporary panel that slides from a viewport edge, overlays the page, and closes when its focused task is finished. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Drawer matches the need before writing code. ## Required behavior - The temporary panel overlays the page and moves in from a defined viewport edge. - While modal, keyboard focus stays inside the surface until it closes. - Escape closes the temporary surface and returns focus to a sensible control. ## States to cover - Drawer closed - Drawer open ## Accessibility - ARIA role: dialog[aria-modal=true] - The primary control or named region for Drawer has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - Opening places focus on the drawer heading or first useful field, contains it, and closing restores the opener. - The named close control and Escape always work; backdrop dismissal is disabled when it could discard changes. - The accessible title and optional description identify the drawer task as focus enters. - Tab remains inside while open - Escape closes without applying unintended changes - Enter activates only the focused control ## When not to use - The navigation must stay visible across pages - The task needs the full viewport or several steps ## Acceptance criteria - The panel is temporary and overlays the page - Its edge and modal behavior are explicit - Focus is contained and restored - The narrow layout keeps every action reachable ## 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-dialog
- 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 Drawer on a real journey
# Verify Drawer after implementation ## Objective Audit the Drawer 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:0455ba64400a0fc1853e85281090b5ff4a54ac32e06092c6f1fc683c82e4c588