Implement correctly
Build Select without breaking its behavior
# Implement Select in your agent ## Objective Implement Select for this verified behavior: A form control for choosing one or more values from predefined options without arbitrary text entry; a single-select commonly appears as a closed picker, while a multiple select may expose a list. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Select matches the need before writing code. ## Required behavior - The control exposes whether one or multiple values can be selected and updates every selected state consistently. - Arrow keys navigate according to the declared control model; focus and selection states are exposed consistently, including when selection follows focus. ## States to cover - Single-select specimen collapsed - Single-select specimen expanded ## Accessibility - ARIA role: select - The primary control or named region for Select has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - The native control delegates focus and option navigation to the platform for its declared single or multiple presentation. - For a collapsed single-select, the platform picker closes using its standard commit or cancellation behavior; a list presentation does not imply a dismissible popup. - Label, required state, selected value or values, disabled state, selection mode, and validation message are exposed by native semantics. - Tab focuses the select - Platform keys navigate the current single- or multiple-selection presentation - The platform selection command updates the value or selected values ## When not to use - Users need to search a long list - Several options must remain visible for comparison ## Acceptance criteria - A visible label names the value or values being chosen - Only predefined values can be committed - The single or multiple selection mode is explicit - Required and error states are associated with the control ## 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.
- Web platform
- 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 Select on a real journey
# Verify Select after implementation ## Objective Audit the Select 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:7f5ec94a1eff0fe4b54de25282c803d69dfd581c234a043ee7e714dc6c0870c4