Design-Parity-Skill: gecachtes Dokument vor jeder Playwright-Analyse ausschliessen

Der Stale-Document-Fall war bisher nur in einer Richtung notiert ("der Fix
wirkt nicht, obwohl er auf dem Server liegt"). Die umgekehrte Richtung ist
gefaehrlicher: ein gemeldeter Fehler ist NICHT reproduzierbar, weil die
gecachte Kopie eine aeltere, funktionierende Konfiguration mitbringt.

Konkreter Fall: gemeldet war "der Slider blaettert nicht endlos". Das
gecachte HTML enthielt loop:1 und lief unter Pfeilklicks, echten Drags und
Frame-fuer-Frame-Messung des Wrapper-Translate einwandfrei durch - alles
scheinbare Belege dafuer, dass es keinen Fehler gibt. Ein Cache-Bypass-Fetch
derselben URL lieferte loop:false. Mit dem Dokument veralten auch Slide-Zahl
und Reihenfolge der Inhaltselemente, was fast als zweiter Defekt gemeldet
worden waere.

Daher als erste Aktion jeder Untersuchung: fetch(location.href,
{cache:'reload'}) und die berichteten Einstellungen daraus mit dem DOM
vergleichen, erst danach Verhalten testen. Hinter Basic Auth ist curl kein
Ersatz - es bekommt 401, die Credentials liegen im Browserprofil.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

typo3-t3bootstrap-live-design-parity/SKILL.md

@@ -3,7 +3,7 @@ name: typo3-t3bootstrap-live-design-parity
 description: "Match a TYPO3 v14 t3bootstrap-based build (local DDEV) to a reference LIVE site page by page — the frontend/design phase after a v11->v14 upgrade. Use when making an upgraded TYPO3 site look like its old/live counterpart, when doing per-page visual parity against a reference URL, when content that exists in the DB isn't rendering after a v11->v14 migration, or when customizing a t3bootstrap sitepackage's templates/SCSS/settings. Covers: the Playwright compare loop (computed style + CSS rule), the settings-vs-SCSS decision, the t3b_core spacing system (spacing.yaml / tx_t3b_spacing) and why spacing must never be fixed in SCSS, recurring structural fixes (stranded colPos, missing templateLayout partials, template partialRootPaths precedence/shadowing, on-demand component CSS, unregistered CTypes), a full visual-parity checklist (layout/width, typography, colors, links/buttons, equal-sizing, icons, borders, footer, header/nav, hero carousel incl. why Bootstrap autoplay cannot be switched off via the interval), diagnosing regressions caused by an editor's SAVE (CKEditor dropping undeclared classes, FlexForm selects with no empty item flipping to "yes"), and cache-safe techniques (full-bleed bands, image-border restyle, responsive crop variants, client-side randomisation, FAL-via-DataHandler). Assumes the site already boots on v14 (see the v11->v14 upgrade skill)."
 metadata:
   author: Wappler
-  version: "1.6"
+  version: "1.7"
 ---
 
 # TYPO3 v14 t3bootstrap — live-design parity
@@ -62,6 +62,21 @@ placeholders below from the site you're matching; keep a per-project log of what
      max-age), or `sendCacheHeaders = 0` to stop instructing the client at all. Note the lifetimes
      already issued cannot be recalled: those users need one hard reload. Assets are fine either way
      (TYPO3 appends `?<mtime>` to CSS/JS URLs).
+   - **⚠⚠ START EVERY Playwright INVESTIGATION BY PROVING THE DOCUMENT IS FRESH.** The stale copy
+     misleads in BOTH directions, and the false-negative is the dangerous one: a reported bug is
+     **not reproducible** because the cached document carries an OLDER, working configuration. Real
+     case: "the slider doesn't page endlessly" — the browser's cached HTML had `loop:1` (looped fine
+     under arrow clicks, real drags, frame-by-frame translate sampling — all "proof" that there was no
+     bug), while a cache-bypassing fetch of the same URL returned `loop:false`. Everything rendered
+     INTO the document lies with it: inline JS config, slide COUNT, and content ELEMENT ORDER (the
+     stale copy showed the slider above the heading, the current page below it — nearly filed as a
+     second defect).
+     First action, before touching the DOM: `browser_evaluate` →
+     `fetch(location.href, {cache:'reload'})`, then grep the answer for the settings the report is
+     about (`loop:`, `autoplay:`, slide/frame counts) and compare with the DOM. Cheap, one call, and
+     it decides whether anything you measure afterwards means something. `curl` is NOT a substitute
+     behind HTTP basic auth (staging) — it returns 401 while the browser holds the credentials.
+     Test behaviour only after that fetch and the DOM agree.
 2. With `browser_evaluate`, capture the real element's **computed style AND its explicit CSS rule**
    (getComputedStyle + walk `document.styleSheets` for the selector). Don't assume inheritance.
 3. Diff vs DDEV → decide **setting vs SCSS** (below) → apply → flush → re-screenshot → verify.