Implement correctly
Build Sidebar without breaking its behavior
# Implement Sidebar in your agent ## Objective Implement Sidebar for this verified behavior: A persistent region beside primary content that participates in page layout and usually contains navigation or supporting tools. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Sidebar matches the need before writing code. ## Required behavior - The region occupies page layout space instead of temporarily covering primary content. - If the product replaces the persistent region when space is insufficient, the replacement is a separately named temporary navigation control. ## States to cover - Sidebar expanded - Sidebar compact ## Accessibility - ARIA role: aside > nav[aria-label] - The primary control or named region for Sidebar has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - Focus moves normally between the sidebar and main content; collapse preserves a logical focused control. - A persistent sidebar is collapsed, not dismissed; any temporary mobile counterpart follows its own Drawer dismissal contract. - The navigation region has a unique name and the current destination uses aria-current when appropriate. - Tab follows normal document order - Enter activates links and collapse controls - No focus trap is created ## When not to use - The surface is needed only briefly - The remaining content becomes too narrow or horizontally scrolls ## Acceptance criteria - The sidebar occupies layout space rather than overlaying content - Its navigation region has a unique name - Current location and collapsed state are exposed - The narrow-screen replacement is an explicit separate pattern ## 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 Sidebar on a real journey
# Verify Sidebar after implementation ## Objective Audit the Sidebar 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:e79bcf73c9929f2f62cc2d5531a2d89325301e5e6c0bdc17b57fad53dff0dc30