Implement correctly
Build Link without breaking its behavior
# Implement Link in your agent ## Objective Implement Link for this verified behavior: A named connection to another destination that preserves standard browser navigation behavior. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Link matches the need before writing code. ## Required behavior - Activation changes the URL or moves to a named destination and preserves standard link behavior. - Pointer, touch, or Enter follows the link; Space keeps its native page-scrolling behavior. ## States to cover - Account summary - Billing details ## Accessibility - ARIA role: a[href] - The primary control or named region for Link has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - Every link has a visible focus indicator and its hit area does not overlap adjacent links. - Not applicable: navigation is handled by browser history rather than dismissing the link. - Link text names the destination, while current, external, download, or language changes are exposed when relevant. - Tab focuses the link - Enter follows the destination - Browser modifier keys preserve native new-tab behavior ## When not to use - Running an in-place mutation - Using a click handler without a real destination ## Acceptance criteria - A real href points to the destination - The label makes sense out of context - Keyboard and browser link operations remain native - Current or external state is exposed only when useful ## 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 Link on a real journey
# Verify Link after implementation ## Objective Audit the Link 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:2b3bd3d93de063f12c7e35633b7e8c1fb644a72e57a144703336d977bf8ed633