Niltra/web-qa-visual

QA-visuell mit Playwright CLI

Goldene Regel: Ohne frische Kommandoausgabe gibt es kein Urteil. Kein "sollte gut aussehen".

Minimales Setup

• Playwright als devDependency des Projekts; playwright.config.ts mit explizitem Viewport von 375px (nicht devices['Pixel 7'], die 412px sind) und Projekten desktop-chrome und mobile-chrome.
• Capture-Skripte in scripts/shot.mjs (MCP nicht dafür verwenden: CLI ist schneller und reproduzierbarer).
• Für axe: @axe-core/playwright.
• Produktions-Build ausliefern (npm run build && npm run start), um echte Leistung zu messen; Dev nur zum Debuggen verwenden.

Checks pro Seite und pro Locale

1. Konsole und Netzwerk: page.on('console'), page.on('pageerror'), page.on('requestfailed') und Antworten ≥400. Fehler = rot.
2. Overflow: In jedem Viewport prüfen, ob document.documentElement.scrollWidth <= clientWidth + 1; bei Überlauf die verantwortlichen Elemente auflisten (getBoundingClientRect().right > innerWidth).
3. Accessibility: Keine critical/serious-Violations von axe; nur ein h1; vollständige img[alt]; sichtbarer Fokus bei allen interaktiven Elementen (mit echtem Tastatur-:focus-visible prüfen, nicht nur CSS); logische Tab-Reihenfolge.
4. Reduced Motion: page.emulateMedia({ reducedMotion: 'reduce' }); keine Pins, kein Autoplay, keine Animation länger als 200ms.
5. Links: Alle href extrahieren, interne (200) validieren, externe als informativ markieren; 0 href="#" ohne Event-Handler.
6. SEO: title, meta description, canonical, OG, hreflang pro Locale, parsebares JSON-LD, sitemap.xml und robots.txt mit Status 200.
7. Leistung: LCP/CLS mit PerformanceObserver nach dem Laden messen; Ziel LCP < 2.5s und CLS < 0.1 auf Desktop; Scroll-Jank durch Zählen langer Frames (>50ms) mit rAF während 5s automatisiertem Scrollen messen.
8. Canvas/Scroll: Da das Canvas im Headless-Modus schwarz erscheinen kann, über DOM prüfen: Elemente mit erwarteter Opazität/Transformation, Texte der Beats vorhanden und sichtbar in den richtigen Bereichen, und Status in window exponiert, falls vorhanden.

Loop

• Nach jeder Ausführung: Bericht mit Tabelle Gate/Befehl/Ergebnis/Status und Liste der Blocker mit Beweis (Selector, Log oder Capture).
• Wenn ein Gate fehlschlägt: Korrigieren (eigene Tests/Skripte) oder konkreten Fix in src/ mit Beweisen vorschlagen; gesamten Zyklus wiederholen.
• Datierte Captures in docs/qa/ speichern (Desktop + Mobile pro Haupt-Locale) und Baseline für Regressionsvergleiche.
• Nicht FERTIG erklären, wenn ein Gate rot ist oder nicht ausgeführt wurde.

Ehrliche Grenzen

• Eine Sequenz von Frames auf echtem iOS kann von Headless aus nicht validiert werden: Im Bericht vermerken.
• Lighthouse via npx lighthouse ist optional, aber für den Produktions-Build empfehlenswert; wenn es nicht ausgeführt werden kann, dies angeben statt zu schätzen.