Implement correctly
Build Alert dialog without breaking its behavior
# Implement Alert dialog in your agent ## Objective Implement Alert dialog for this verified behavior: A modal dialog that interrupts a consequential action and requires an explicit confirm or cancel decision. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Alert dialog matches the need before writing code. ## Required behavior - While modal, keyboard focus stays inside the surface until it closes. - The surface remains until the user deliberately confirms or cancels the consequential action. ## States to cover - Decision closed with workspace intact - Initial deletion decision open - Decision closed after cancellation - Deletion decision reopened after cancellation - Deletion submitting - Decision closed after confirmed deletion - Deletion decision reopened after confirmation ## Accessibility - ARIA role: alertdialog[aria-modal=true] - The primary control or named region for Alert dialog has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - Initial focus lands on the least destructive useful action unless reading long consequences first is safer. - Only an explicit decision or a documented safe cancellation closes the alert; no timer or accidental outside press dismisses it. - The alert dialog role, title, consequence, and both action names are announced when focus enters. - Tab moves only between decision controls - Escape cancels when cancellation remains safe - Enter activates the explicitly focused action ## When not to use - The action can be safely undone - The message only reports a result and needs no decision ## Acceptance criteria - The message names the exact consequence - Confirm and Cancel are explicit and visually distinct - Initial focus avoids accidental destructive confirmation - The alert cannot disappear before a decision ## 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-alert-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 Alert dialog on a real journey
# Verify Alert dialog after implementation ## Objective Audit the Alert dialog 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:72fafc4dd706b0871459fcbba55cb7472d5f47e970d2bdeb16a4747999dd2db4