# Review and verify a DASH interface

Use this reference for a requested review or the handoff of an implementation. Review the changed task and the components it depends on. Scale the scope to the change, and separate observed failures from concerns that still need a check.

## Match the installed system

Confirm imports, props, and token names against the installed exports and types. Check that the application generates and loads the required CSS. Inspect the computed theme and fonts when appearance differs from the design. Identify proposed or unavailable APIs explicitly.

For a review-only request, report findings with file or interaction references and their practical effect. Prioritize broken tasks, data loss, misleading states, and keyboard or focus failures before cosmetic differences.

## Exercise the changed flow

| Area                     | Evidence to collect when relevant                                                                                                                                                                  |
| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Outcome and state        | Complete the intended action. Check empty data, pending work, success, errors, validation, and retry where the change affects them. Verify that errors preserve entered values.                    |
| Keyboard and focus       | Reach every action, use the component's documented keys, see the focus indicator, and verify overlay dismissal and focus return.                                                                   |
| Labels and announcements | Inspect accessible names and input/error associations. Check that meaningful asynchronous results are announced without repeated or distracting updates.                                           |
| Theme and contrast       | Review supported light and dark states against actual backgrounds. Required text and status must remain readable. Color alone cannot carry a state.                                                |
| Reflow and input         | Check narrow and wide layouts, intermediate widths, long content, zoom, and touch targets. Ordinary content should reflow at 320 CSS pixels; contain data tables or other two-dimensional content. |
| Motion                   | Check reduced motion, interruption, repeated activation, and the still state. Verify pause behavior for looping demonstrations.                                                                    |

Use the [Accessibility guidance](https://hash.design/foundations/accessibility.mdx) for criteria and exceptions, and [Responsiveness](https://hash.design/foundations/responsiveness.mdx) for layout choices. Passing automated checks or using an accessible primitive alone does not establish accessibility conformance for a composed screen.

## Run the project's checks

Use the repository's configured type, lint, build, and relevant interaction tests. Add tests for changed behavior when they can catch a meaningful regression; do not add tests that only restate a style value or implementation detail. Distinguish a failure introduced by the change from a pre-existing failure, and report both accurately.

If a browser or assistive technology is unavailable, complete the checks that are possible and name the missing verification. Do not describe an unobserved interaction as tested.

## Handoff

State what changed or what needs fixing, why it matters for the task, and the evidence supporting the conclusion. Include the checks actually run, the states exercised, and any unresolved package or documentation mismatch. Cite relevant documentation or code when it explains a decision. Keep research proposals and unverified assumptions separate from implemented behavior.