Build a design QA checklist specific to what actually broke last time, not a generic pixel-perfect checklist

WHAT CHANGED IN THIS RELEASE
Updated the shared Button component's border-radius token and hover state; redesigned the checkout summary card.

COMPONENTS OR SCREENS TOUCHED
Checkout summary card, primary Button component (used app-wide).

WHAT HAS BROKEN IN PAST RELEASES (regression history)
Focus ring visibility on dark-mode backgrounds has broken twice before after button/token changes; mobile Safari has previously mis-rendered sticky footer CTAs after CSS changes.

DEVICES/BROWSERS THAT MATTER MOST FOR THIS PRODUCT
iOS Safari and Chrome on Android are the top two by traffic share; desktop Chrome and Safari next; Firefox is under 2% of traffic.

Build a QA checklist weighted specifically toward what RELEASE_CHANGES actually touched and what REGRESSION_HISTORY shows has broken before — do not produce a generic full-app pixel-perfect checklist that treats every screen as equally at risk, since a shared component change (a button style, a shared layout wrapper, a design token value) has ripple effects across screens that were never directly edited in this release, and those indirect blast-radius screens deserve specific checklist items even though they don't appear in TOUCHED_COMPONENTS. For each item in RELEASE_CHANGES, name the specific screens or components that could be indirectly affected through shared components or tokens, not just the ones directly edited.

For each item in REGRESSION_HISTORY, write a checklist item that specifically re-tests that exact past failure at the current state of DEVICE_PRIORITY, rather than a generic "check for regressions" — a regression that happened once in a specific component under specific conditions is more likely to recur under the same conditions than a random new part of the app is to fail for the first time, and QA time is better spent verifying known fragile points than uniformly re-checking everything.

Write each checklist item as a specific, checkable pass/fail statement ("the dropdown's focus ring is visible against the dark-mode background at 1x and 2x zoom") rather than a vague reminder ("check dropdown looks okay") — a checklist item that isn't falsifiable doesn't actually get executed consistently, it gets glanced at and marked done. Order the checklist by risk, with items tied to direct changes and known regression history first, and lower-risk general items last, so a QA pass that runs out of time still covers the highest-value checks first.

WHAT NOT TO DO
Do not produce an undifferentiated checklist covering every screen in the app equally regardless of what actually changed — that wastes QA time on low-risk areas and, by trying to cover everything, often results in less actual scrutiny of the areas that matter most. Do not write checklist items as reminders to "look carefully" without a specific, checkable condition attached.

OUTPUT FORMAT
1. Directly changed items: checklist item | why it's at risk | device/browser to check on.
2. Indirect blast-radius items: affected screen | shared component/token causing the risk | checklist item.
3. Regression-history re-checks: past failure | specific re-test | device/browser.
4. The full checklist ordered by risk, highest first.