Implement correctly
Build Stepper without breaking its behavior
# Implement Stepper in your agent ## Objective Implement Stepper for this verified behavior: A progress summary that distinguishes completed, current, and upcoming stages in a meaningful linear process. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Stepper matches the need before writing code. ## Required behavior - The workflow marks earlier stages complete, one stage current, and later stages upcoming. - Pointer, Enter, or Space activation runs one named action exactly once. ## States to cover - Details current - Documents current - Review current - Process complete ## Accessibility - ARIA role: ol > li[aria-current=true] + heading - The primary control or named region for Stepper has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - After an in-place stage change, focus the new step heading or use one documented equivalent; never focus a decorative segment. - The indicator is persistent workflow context and is not dismissible. - Expose Step N of M and the current heading, include completed and upcoming text, and mark only the current labeled step. - The indicator adds no tab stops by default - Separate Back and Next buttons use Tab and Enter or Space - Decorative segments do not intercept keys ## When not to use - Steps can occur in any order or change conditionally - The process has fewer than three meaningful sections ## Acceptance criteria - Exactly one stage is current - Status never depends on color alone - Navigation controls remain separate - The screen has a real heading - Current and total step counts stay correct ## 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 Stepper on a real journey
# Verify Stepper after implementation ## Objective Audit the Stepper 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:198c281be9e76b5e75ac002fc602222090af1ee3471296cf69fd230368cae7d7