Implement correctly
Build Spinner without breaking its behavior
# Implement Spinner in your agent ## Objective Implement Spinner for this verified behavior: A compact animated indicator for work whose completion amount is unknown, paired with a meaningful busy status. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Spinner matches the need before writing code. ## Required behavior - The content region exposes its busy state while a separate visual indicator remains redundant. - A live region announces new status only when the update is important and not already focused. ## States to cover - Task idle - Task loading - Task taking longer than expected - Task cancelled - Task done ## Accessibility - ARIA role: status + [aria-busy=true] - The primary control or named region for Spinner has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - Focus remains on the initiating control unless a documented transition replaces the whole view. - The indicator ends when work resolves or is cancelled; it is never a manually dismissible message by itself. - A concise status announces the start and final result, while the spinner graphic remains hidden from assistive technology. - Tab reaches the initiating control - The pending control blocks duplicate activation - Cancel remains keyboard reachable when offered ## When not to use - A known percentage can be reported - The wait is long enough to require progress detail or cancellation ## Acceptance criteria - The wait is truly indeterminate - A textual busy state accompanies the visual - Duplicate actions are prevented - The long-wait state offers explanation and recovery ## 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 Spinner on a real journey
# Verify Spinner after implementation ## Objective Audit the Spinner 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:976326a7e39cbcd784577b390266b74f076a09a55e3331d0fd96eb8e6fc3488d