VARNI STOREFRONTS · QUALITY AUDIT · 2026-07-12
Live site: https://website-23.varnijewels.com · Design reference: aukerajewellery.com
Audited across three dimensions: launch readiness (functionality, SEO, performance, security, accessibility, analytics, brand), mobile QA (real device emulation, touch), and desktop QA (1920/1440/1366, hover + keyboard). Report-only — no purchase was completed.
Launch-readiness scoring. Infra-only items are marked MANUAL and left unscored.
| Category | Score | Verdict | Defects |
|---|---|---|---|
| Core Functionality | 65 | warn | 8 |
| Performance & Core Web Vitals | 48 | fail | 3 |
| Technical SEO | 35 | fail | 7 |
| Security | 35 | fail | 2 |
| Frontend | 68 | warn | 4 |
| Backend / API (mostly MANUAL) | — | manual | 2 |
| Analytics & Tracking | 78 | warn | 1 |
| Accessibility | 62 | warn | 3 |
| Brand Consistency | 12 | fail | 4 |
| Marketing Readiness | 42 | fail | 3 |
| Monitoring & Maintenance | — | manual | 0 |
Lighthouse CLI, mobile emulation defaults.
| Page | formFactor | performance | accessibility | bestPractices | seo | lcpMs | fcpMs | clsScore | tbtMs | speedIndexMs | ttiMs | serverResponseMs | source | url | unusedJsSavingsKiB | unusedCssSavingsKiB | responsiveImagesSavingsKiB |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| home | mobile | 60 | 90 | 96 | 100 | 6596.3 | 4033.7 | 0.0006 | 3 | 9683.5 | 6704.6 | 803.6 | lh-website-23-home.json | — | — | — | — |
| pdp | mobile | 55 | 91 | 96 | 100 | 17400 | 10500 | 0.002 | 30 | 38400 | 17400 | 5930 | w23-lh-pdp.json | https://website-23.varnijewels.com/products/140-ct-ef-vs-lab-grown-diamond-solitaire-engagement-ring-in-10k-white-gold-_-sz0875-103063 | 91 | 23 | 34 |
37 findings across functionality, SEO, security, performance, accessibility, analytics and brand consistency.
On /checkout/cart, button[aria-label='Increase quantity'] has display:flex/visibility:visible/opacity:1 but getBoundingClientRect() returns width=0, height=0. Playwright's real click times out ('element is not visible'); a raw JS dispatchEvent('click') does successfully increment qty from 1 to 2, proving the app logic works but the button's actual clickable/visible area is collapsed by CSS/layout, so normal pointer users cannot use it.
Fix: Fix the quantity stepper's CSS/layout so the increase/decrease buttons have a real rendered size and are pointer-clickable, not just DOM-present.
Lighthouse mobile audit of the PDP: Performance score 55/100. LCP=17.4s (target <=2.5s), FCP=10.5s, Speed Index=38.4s, TTI=17.4s. Root-document server-response-time alone is 5.93s.
Fix: Profile and fix PDP server-side render/data-fetch latency first (it dominates the timeline before any client JS/CSS optimization matters).
<meta property="og:site_name" content="Jewelwesell"/> present on both home and PDP - the internal reference-brand identity is exposed in Open Graph metadata site-wide (visible in every social-share link preview).
Fix: Set og:site_name from themeContent.brandName, never the reference/API default.
Page title: '1.40 ct EF VS Lab Grown Diamond Solitaire Engagement Ring in 10k White Gold _ Sz0875 103063 | Jewelwesell' - shown in the browser tab, bookmarks, and search-engine result snippets.
Fix: Fix the PDP title template to append the store's own brand, not the reference brand.
The Product JSON-LD block's brand object resolves to {"@type":"Brand","name":"Jewelwesell"} - Google Rich Results / Merchant Center would show the wrong brand for every product.
Fix: Populate brand.name from the store's own theme brand, not an upstream/reference value.
<meta property="og:image" content="https://media.jewelwesell.com/New_JWS/001Rings/103063_WW_JWS.jpg"/> - social-share previews pull an image from a third-party 'jewelwesell.com' domain rather than this store's own asset host.
Fix: Serve product images from this store's own CDN/asset pipeline; remove all jewelwesell.com references.
robots.txt points to Sitemap: https://website-23.varnijewels.com/sitemaps/website-23.varnijewels.com-sitemaps/sitemap_index.xml which returns HTTP 404 with body '<Error><Code>NoSuchBucket</Code>...<BucketName>varnijewels</BucketName>...'. Search engines cannot discover the site's URL list via sitemap.
Fix: Fix the sitemap generation/hosting pipeline (wrong/missing S3 bucket) so the sitemap index actually resolves.
The mobile hamburger sidenav shows the script-style 'JewelWeSell' logo wordmark (not this store's 'WEBSITE-23'/'Aukera' identity) and a 'SUPPORT CONTACT' block listing [email protected] and +(646) 598-7516 - the internal reference-storefront's own support contact, shown to real shoppers of website-23.
Fix: Fix the sidenav's brand/contact source: it must derive brandName and support contact from themeContent, never the reference/API defaults. This is the exact 'wordmark parity' anti-pattern - sidenav should read `themeContent.brandName || storeData?.name`, not the reverse, and support contact must come from this store's own theme content.
See Technical SEO findings: og:site_name, PDP <title> suffix, and Product JSON-LD brand.name all resolve to 'Jewelwesell' on this live store.
Fix: Same root-cause fix as above, applied to the SSR meta/schema templates, not just the client-rendered sidenav.
Console error 'Error fetching menu: {message: Please check your internet connection and try again}' logged on /store-locator, /rings, /earrings, /bracelets, /necklaces, /pendants, /bestsellers, /solitaire, /new-arrivals.
Fix: Investigate the header/megamenu API call for intermittent failures/timeouts server-side; the generic 'check your internet connection' client message masks the real cause.
'Search error: {message: Please check your internet connection and try again}' logged on /rings, /earrings, /bracelets, /necklaces, /bestsellers, /solitaire, /new-arrivals, /store-locator.
Fix: Check the Meilisearch/search API endpoint health and error handling on category-page load.
Lighthouse mobile audit of home: Performance 60/100. LCP=6.6s, FCP=4.0s, Speed Index=9.7s, TTI=6.7s. TBT=3ms and CLS=0.0006 are both good.
Fix: Optimize hero image/critical CSS delivery and reduce root-document response time (803ms TTFB is already borderline).
The Product schema block only contains brand, aggregateRating, and offers.priceValidUntil - it is missing name, image, sku/description, and offers.price/priceCurrency/availability, all required/recommended by Google's Product structured-data spec.
Fix: Populate the full Product schema (name, image, sku, description, offers.price, priceCurrency, availability, url).
JSON-LD BreadcrumbList item URLs are malformed, e.g. "item": "https://https://website-23.varnijewels.comEngagement" - doubled protocol, no path separator, breadcrumb text appended directly onto the domain with no slug.
Fix: Fix breadcrumb URL construction (likely a string-concatenation bug prefixing an already-absolute URL with the origin again).
curl -I on https://website-23.varnijewels.com/ shows no Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, or Strict-Transport-Security (HSTS) headers. Only Cloudflare/NEL/report-to, content-type, cache and cookie headers are present.
Fix: Add CSP, X-Frame-Options (or frame-ancestors in CSP), X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy, and HSTS at the app/edge layer.
See Core Functionality finding - same defect, flagged here as a CSS/layout bug.
Fix: See Core Functionality recommendation.
Lighthouse a11y audit 'target-size' fails on the PDP - some interactive elements do not meet the 24x24px+ spacing guidance for touch.
Fix: Increase hit-area/spacing on small PDP controls (ring-size chips, qty stepper, etc.).
server-response-time audit shows the PDP HTML document itself took 5,930ms to arrive, versus 803ms for home - the SSR/data-fetch path for product-detail is a major bottleneck (see Performance category).
Fix: Ops: profile PDP server-side rendering / backend product+variant API calls for slow queries, N+1 fetches, or missing caching.
See Core Functionality findings - client-visible errors suggest an intermittent/rate-limited backend rather than genuine client network loss.
Fix: Ops: check API logs/error rates for the menu and search endpoints around the audit window.
Lighthouse 'color-contrast' audit fails on both pages (score 0) - some text/background combinations do not meet WCAG AA contrast ratios.
Fix: Run a full contrast pass on theme tokens (especially any light-on-light or muted-gray text).
Header/hero/footer/page-title/copyright all show the generic placeholder 'WEBSITE-23' (e.g. hero headline literally reads 'Website-23', footer copyright '© 2026 Website-23. All Rights Reserved.'); the theme's actual intended brand 'Aukera' only surfaces indirectly (og:image path '/aukera/hero-1.svg', homepage tagline 'Find your Aukera'); and 'Jewelwesell' leaks in via sidenav/meta/schema as above. No single, finished brand name is applied consistently.
Fix: Decide the final brand name for this store and apply it consistently to themeContent.brandName, header, footer, hero, page titles, and meta/schema - do not launch with a placeholder 'Website-NN' name.
Cross-reference Brand Consistency findings - a shopper who opens the mobile menu for help is shown JewelWeSell's contact info, not this store's.
Fix: See Brand Consistency recommendation.
5 social-icon links in the footer resolve to '/#' with no destination - not real Instagram/Facebook/etc. profile links.
Fix: Link to real social profiles or remove the icons until profiles exist.
Set-Cookie: litekart_store_id=store_01JNKD4PGSR8E3QZSGXYEE0PRV; Max-Age=31536000; Path=/ - no Secure, HttpOnly, or SameSite attribute shown.
Fix: Add Secure; HttpOnly (if not needed client-side); SameSite=Lax/Strict to the cookie.
Lighthouse 'aria-prohibited-attr' fails on home - one or more elements use ARIA attributes not allowed for their role.
Fix: Audit ARIA usage against each element's implicit role.
Lighthouse flags 'errors-in-console' on home and PDP - corroborated by the wishlist 422/menu/search errors captured in walkthrough runs.
Fix: Clean up console errors; at minimum silence the expected guest-wishlist 422 from the console.
Footer 'Gifting' links to /products (not a gifting collection); 'About Website-23', 'Our Materials', and 'Boutiques' all link to /contact-us instead of dedicated pages.
Fix: Wire footer links to their intended pages or remove links that have no corresponding page yet.
Five footer link entries resolve to href="https://website-23.varnijewels.com/#" with no text - unwired social icon placeholders.
Fix: Point social icons to real profile URLs or hide them until profiles exist.
Automated text check for 'recently viewed' on the PDP returned false.
Fix: Add a recently-viewed products rail if the design calls for one (checklist item).
unused-javascript: ~91 KiB est. savings; unused-css-rules: ~23 KiB; uses-responsive-images: ~34 KiB savings.
Fix: Secondary optimization once server-response-time is fixed; code-split/tree-shake PDP bundle and serve responsively-sized images.
Lighthouse 'heading-order' audit fails on PDP.
Fix: Audit and correct h1->h2->h3 nesting on the PDP template.
Lighthouse 'image-redundant-alt' fails on home - alt text duplicates adjacent visible text.
Fix: Trim alt text to avoid duplicating visible captions/labels.
Footer shows phone '+91 90000 00000' (obviously fake), email '[email protected]' (reserved .example TLD, not a real deliverable address), and a generic Mumbai/BKC address.
Fix: Replace with real, monitored contact details before launch.
The captured footer text/structure for website-23 shows no email-capture field (a sibling store's footer, by contrast, has a visible 'Enter your email address' + Subscribe block).
Fix: Confirm whether a newsletter capture component exists on this theme/store and is simply below the fold, or is genuinely missing.
GET /api/wishlists/me returns 422 'Invalid credentials' for guest sessions on virtually every route. Per known project status this is expected behavior for guests, not a bug.
Fix: No action required; confirm this is still the intended contract.
The /products filter panel's CATEGORIES facet shows entries like 'Charms Cluster Pendants', 'Charms Emoji And Symboli...' (+64 more) which read as a raw platform category dump rather than a curated list relevant to this store's assortment.
Fix: Review/curate the category facet list shown to shoppers.
GA4 and GTM containers are both loaded, but the on-disk artifacts from the prior (killed) run do not include a captured dataLayer/network trace proving add_to_cart, view_item, begin_checkout, or purchase events actually fire with correct payloads, nor evidence of a cookie-consent banner.
Fix: Follow up with a GTM Preview / dataLayer inspection pass to confirm Enhanced Ecommerce events and consent mode.
Real mobile emulation (iPhone 13 (390x844 CSS, DPR 3, touch, mobile Safari UA, Chromium engine), Pixel 7 (412x915 CSS, DPR 2.625, touch, mobile Chrome UA), 360x780 narrow-Android cross-check, 428px width cross-check, Landscape spot-check: home (844x390 / 839x412) and PDP (844x390)), touch interaction, thumb-driven journey.
Lighthouse mobile audit (w23-lh-pdp.json) scores PDP performance 0.55/1.0 with Largest Contentful Paint 17.4s and Speed Index 38.4s (both score 0/1). Manual Playwright screenshots at +3s/+9s/+18s after domcontentloaded confirm the hero product image is not visually complete until roughly 15-18s post-navigation on a throttled mobile profile. A real thumb-driven shopper on cellular data would stare at a mostly blank/skeleton PDP for the better part of 20 seconds before the product photo they came to see actually renders.
Fix: Investigate what is blocking LCP on this route (likely unoptimized/oversized hero image, render-blocking JS/CSS, or slow client-side data fetch before the gallery paints). Preload/priority-hint the primary product image, serve a properly sized responsive image, and get LCP under ~2.5s and Speed Index under ~5s for mobile.
The mobile hamburger ('Toggle menu') button measures 18x18 CSS px, and the header 'Toggle Cart' icon buttons measure 34x18 CSS px, on both iPhone 13 (390px) and Pixel 7 (412px) profiles -- confirmed independently three separate times in this session. Apple HIG / Material guidance recommend a minimum 44x44pt comfortable touch target; WCAG 2.5.8 requires at least 24x24 CSS px. The hamburger fails both; the cart toggle fails the 44px guidance and is borderline on the WCAG floor. This is the very first tap most mobile visitors make on the site.
Fix: Increase the tappable hit area of the hamburger and header cart icon to at least 44x44px (padding the button, not just the icon glyph), independent of the visual icon size.
With the hamburger drawer open, scrolling the screen scrolls the underlying homepage content behind/along with the drawer (window.scrollY moved from 0 to 600px while the drawer was open). Real users expect an open drawer/modal to lock body scroll; instead the page repositions behind the drawer, which is disorienting and can leave the page scrolled to an unexpected spot once the drawer closes.
Fix: Lock body scroll (e.g. overflow:hidden on <body> or a scroll-lock utility) while the drawer/any modal sheet is open.
Tapping a category link (e.g. 'Rings') inside the mobile drawer closes the drawer instantly, but the client-side route change does not actually complete for roughly 2.5 seconds afterward -- and there is no spinner, skeleton, or any other visual indicator during that gap. Screenshots taken at 0.5s/1s/1.5s/2s post-tap all show the same static homepage. Verified reproducibly across two independent test sessions and multiple runs (navigation consistently lands around t=2.5-2.6s). A real user has no reason to believe their tap registered and is very likely to tap again, tap something else, or leave.
Fix: Show immediate feedback on nav-link tap: close the drawer only after navigation starts, or show a top-of-page progress bar / skeleton PLP shell instantly, so the ~2.5s gap doesn't read as unresponsive.
At 390px width, the Filters sheet renders a left-hand vertical tab rail (CATEGORIES / TAGS / PRICE / CENTER STONE CTW / ... ) so narrow that several labels are cut off before the last letter, e.g. 'CENTER STONE CTW' displays as 'CENTER STONE CTV', 'CENTER STONE SETTING' as 'CENTER STONE SET', 'SIDE STONE SETTING' as 'SIDE STONE SETTIN', 'SIDE STONE SHAPE' as 'SIDE STONE SHAPE' (clipped). This two-panel layout appears to be the same one used on desktop, simply squeezed into the phone viewport rather than converted to a full-width single-column/accordion mobile filter pattern.
Fix: Redesign the mobile filter sheet as a single full-width column (accordion sections) instead of reusing the two-column desktop tab layout, or widen the left rail and wrap/reduce label text so nothing is clipped.
Lighthouse's mobile target-size audit (score 0/1) flags: (1) the 'Lab Grown Diamond' chip (164x36px) has less than 24px of safe clickable space to its neighbor (the Add To Bag button) -- effective safe diameter only 20.8px; (2) 'Check Availability' is only 115x20px, under the 24px minimum height/width floor.
Fix: Add spacing/margin between the material-tag chip row and the Add To Bag button, and enlarge the 'Check Availability' tappable area to at least 24x24px (ideally 44x44).
On the /checkout/cart page, the 'Increase quantity' / 'Decrease quantity' buttons measure 28x28 CSS px inside a cramped 106x38px pill, confirmed consistently at 390px, 412px and 428px real mobile widths this session -- they clear the strict WCAG 24x24 floor but sit well under the 44x44 comfortable-thumb guidance used for commerce controls, with minus/plus/qty-readout packed tightly together (real mis-tap risk). IMPORTANT CORRECTION: the previously-reported '0x0 hit-box, cannot be tapped at all' finding was re-traced this session to scripts that ran the diagnostic at viewport 1440x900 (desktop), not mobile (see w23-supplement.js / w23-qty-retry.js, both `viewport: {width:1440,height:900}`). On real mobile viewports (390/412/428px, touch enabled, both iPhone-class and Android-class UAs), the button is present at 28x28px and a genuine Playwright `.tap()` (not a forced/synthetic click) succeeds without error and increments quantity. The undersized-but-tappable state is what should be tracked as the mobile-specific defect; the '0x0/completely unreachable' severity does not reproduce on any mobile width tested.
Fix: Enlarge the qty stepper buttons to at least 44x44px tappable area (can keep a smaller visual glyph with generous padding) and add more separation from the adjacent button/readout.
At 844x390 landscape, document.documentElement.scrollWidth (852px) exceeds clientWidth (844px) by 8px, producing a very slight horizontal scroll on the PDP in landscape only. Portrait PDP/home/PLP at 360/390/412/428px all show no horizontal scroll.
Fix: Find and constrain the element causing the 8px landscape overflow (likely a fixed-width element or the gallery reaching full-bleed without accounting for scrollbar/safe-area at that breakpoint).
Tapping the sticky 'Add To Bag' button correctly opens an immediate 'Your Cart (1)' drawer with the item, image, price, an inline qty stepper and a Checkout button -- good instant feedback overall -- but it auto-closes within roughly 1-2 seconds, which may not give a user enough time to adjust quantity right there before it vanishes (they can still do so on the full cart page).
Fix: Consider a slightly longer auto-dismiss window or a manual-dismiss-only pattern (X button / tap-outside) for the mini-cart confirmation.
Desktop viewports (1920x1080, 1440x900, 1366x768), hover states, keyboard navigation, layout integrity.
The header's <nav aria-label="Main navigation"> element renders with 0 children (verified via DOM: childElementCount=0, textContent='') at 1920x1080, 1440x900, and 1366x768. Network capture shows the root cause: GET https://website-23.varnijewels.com/api/categories/megamenu returns net::ERR_ABORTED. Category taxonomy clearly exists (PDP breadcrumbs show Home > Pendants > Everyday Pendants > Shapes & Symbols > Cartoon, and homepage tiles link to /bracelets, /necklaces, /pendants, /bestsellers, /9kt-collection) but none of it is exposed via the header nav/megamenu a desktop shopper would normally hover.
Fix: Fix/retry the megamenu category API call (per fleet rule: header nav must come from backend API menu). Add error handling so a transient failure doesn't leave the nav silently empty, and add a retry or fallback to homepage category taxonomy.
Header logo text, hero H1, page <title> ('Website-23 — Fine Lab Grown Diamond Jewelry'), and aria-label='Website-23 home' all show the generic internal site-id placeholder. The homepage subhead itself says 'Find your Aukera' and the theme is literally named 'aukera', implying the intended brand name was never wired in — the site is customer-facing with its internal placeholder name.
Fix: Set the real store/theme brand name (e.g. 'Aukera') in theme content / store settings so it wins over the placeholder everywhere (header, hero, <title>, aria-labels), per brand-wordmark-parity rule.
In the 'The diamond. The craft. The design.' three-card section, each card's large heading text overlaps directly on top of its eyebrow label and caption instead of stacking in sequence, and the heading text is clipped at the card's left edge (e.g. 'Everyday Brilliance' renders as '...ryday Brilliance', 'Statement/Tennis Bracelets' renders as '...nis Bracelets'). Reproduced consistently at 1920x1080 on two separate loads/scroll timings (not a scroll-jump artifact).
Fix: Fix the card's text-layer CSS (likely an absolutely-positioned heading with no clearance from the eyebrow/caption block below it, and container overflow clipping the heading on the left). Verify vertical stacking order and left padding/margin match the source design contract.
Zoomed inspection of the PDP hero image and PLP thumbnails shows a small tiled watermark (stylized diamond icon + 'JewelWeSell' cursive wordmark) baked into the photography itself, visible on essentially every product photo across the catalog (confirmed on PLP grid and PDP main image at 1920x1080).
Fix: Re-source product photography without the competitor watermark, or crop/clean the images before serving. Using another company's watermarked stock photography live on a customer-facing storefront is a trust and originality risk per the reskin no-plagiarism rule.
At 1920x1080, after clicking the '10k Gold' metal-type chip on PDP then clicking 'Add to Bag', the button rendered in a muted/grey state, no toast or status element appeared, and the backend returned 400 on POST /api/carts/{id}/line-items followed by 404 on GET /api/carts/{id}. The cart page then showed 'YOUR BAG IS EMPTY'. On a later isolated retest with the default (unmodified) variant, Add to Bag worked correctly with no errors. On the 1366x768 pass, add-to-bag after the same '10k Gold' click succeeded (cart had 1 item, qty stepper worked). The failure did not reproduce consistently, suggesting either a transient backend issue or a specific variant/SKU combination gap.
Fix: Investigate whether the 10k-Gold/White-Gold/EF-VS/Lab-Grown-Diamond combination has a valid SKU. Regardless of root cause, the UI must surface a visible error toast/message on any add-to-cart failure instead of failing silently with a merely-greyed button.
All 7 category tiles (Rings, Earrings, Bracelets, Necklaces, Pendants, Bestsellers, 9KT Edit) render an identical grey circle with a generic diamond-outline icon rather than distinct product photography per category, at all desktop widths tested.
Fix: Wire real category thumbnail images (from theme content or API category data) into these tiles instead of the shared placeholder icon.
meta[property=og:image] = https://media.jewelwesell.com/New_JWS/003Pendants/232635_WW_JWS.jpg. A network request to a related media.jewelwesell.com asset was observed failing with net::ERR_BLOCKED_BY_ORB. This breaks social-share link previews. Note: the actual on-page PDP hero <img> is NOT broken — it loads fine (naturalWidth 2076px) from static.varnijewels.com, so the customer-visible gallery works; only the meta og:image / share-preview path is affected.
Fix: Point og:image at the store's own static.varnijewels.com asset instead of media.jewelwesell.com.
Computed style: color rgb(156,163,175) (Tailwind gray-400) on white background, 12px text. Measured contrast ratio ≈ 2.54:1, below the WCAG 2 AA minimum of 4.5:1 for normal-size text.
Fix: Darken the inactive step label color (e.g. to gray-600/700) to meet 4.5:1 contrast while keeping the visual 'inactive' distinction from the active step.
The PLP grid uses identical fixed card widths (~353px at 1920 and 1440, ~342px at 1366) via `grid-cols-2 lg:grid-cols-3`, so it stays at 3 columns even at 1920x1080. This is within the acceptable 3–4 column range and the layout is well-filled with no dead whitespace, but a 4th column at ≥1920 would make fuller use of large screens.
Fix: Optional: add an xl:grid-cols-4 breakpoint for ≥1920px viewports. Not a blocker.
At 1366x768, the visible 'Increase quantity' button measured a real 28x28px hit box and a plain mouse click correctly incremented quantity from 1 to 2. At 1920x1080 the cart was empty (see the Add-to-Bag 400 defect above) so the stepper could not be exercised there. The launch-readiness-reported 0x0 hit-box defect could not be confirmed on this pass; recommend re-verification once the add-to-cart issue above is resolved so the stepper can be tested at all three widths with an item actually in the cart.
Fix: Re-test the qty stepper at 1920x1080 and 1440x900 once a cart item can reliably be added, to confirm whether the earlier hit-box defect still exists.
Console shows repeated 'Failed to load resource: 422' / 'While fetching wishlist {message: Invalid credentials.}' on every page. This matches the known fleet baseline: guest 422 on wishlist is expected, not a bug.
Fix: No action needed; documented as expected per fleet knowledge.
The three dimensions were run independently, so some findings were corrected or contradicted by a later pass. Those disagreements are recorded here rather than silently resolved — a claim below is not firm until re-verified.
The diagnostic that produced this ran at a 1440x900 desktop viewport. Mobile QA (390/412/428px) found the button present and a real tap succeeds. Desktop QA at 1366x768 measured a 28x28px box and a real click incremented the quantity. Not reproduced by either QA pass.
Action: None — treat as a false finding. The genuine issue is that 28x28px is under the 44px touch-target minimum.