Implement correctly
Build Bottom sheet without breaking its behavior
# Implement Bottom sheet in your agent ## Objective Implement Bottom sheet for this verified behavior: A mobile-oriented surface attached to the bottom edge that can open to stable heights and may support dragging. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Bottom sheet matches the need before writing code. ## Required behavior - Touch dragging moves the sheet between stable heights while controls remain keyboard operable. - 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 - Sheet closed - Sheet at half height - Sheet at full height ## Accessibility - ARIA role: dialog[aria-modal=true] - The primary control or named region for Bottom sheet has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - Focus enters the modal sheet, remains inside, and returns to the Filters opener after closing. - Close control, Escape, and a downward gesture past the documented threshold dismiss; accidental small drags snap back. - The sheet title, current modal state, expanded state, and loading changes are available without relying on motion. - Tab reaches all controls - Buttons provide expand and collapse alternatives - Escape closes the modal sheet ## When not to use - Desktop side placement is the defining behavior - Dragging is the only way to reach content or close ## Acceptance criteria - The surface is visibly anchored to the bottom - Every drag action has a button or keyboard equivalent - Snap points reveal meaningful stable states - Keyboard alternatives and focus restoration are verified ## 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.
- vaul
- 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 Bottom sheet on a real journey
# Verify Bottom sheet after implementation ## Objective Audit the Bottom sheet 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:e3fcddd7f60ab0511a667cc45879e149c6e7dcf397c40d464934047eedc9563a