Cache-Lebensdauer: den Ein-Jahres-Default in beide Skills aufnehmen

Design-Paritaet 1.4 -> 1.5: neuer Warnpunkt in der Vergleichsschleife.
Bevor man eine Rueckmeldung "immer noch nicht behoben" fuer bare Muenze
nimmt, gehoeren die Response-Header geprueft. Ohne config.cache_period
liefert TYPO3 seinen Core-Default von einem Jahr als max-age aus, und
config.sendCacheHeaders = 1 (von t3bootstrap gesetzt) reicht ihn an
Browser und Proxys weiter. Eine erteilte Frist ist nicht widerrufbar,
ein serverseitiges cache:flush erreicht solche Clients also nie. Da
Erweiterungen ihre Konfiguration teils als Inline-JS in die Seite
schreiben, reproduziert eine alte Kopie laengst behobene Fehler exakt.

Cutover 1.0 -> 1.1: derselbe Punkt als Go-live-Pruefung in Phase 2.
Dort wiegt er schwerer, weil nach dem Livegang jeder Besucher mit einer
bereits erteilten Jahresfrist festhaengt.

Beides stammt aus einem realen Fall: Rueckmeldungen aus dem Kundennetz
meldeten Fehler weiter, die im Agenturnetz nachweislich behoben waren.

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

typo3-staging-to-live-cutover/SKILL.md

@@ -3,7 +3,7 @@ name: typo3-staging-to-live-cutover
 description: "Promote an approved TYPO3 staging site to production — the go-live step AFTER a staging environment exists. Use when a TYPO3 site is about to go live, when a staging/preview site must become the public site, when asked to clean up a staging server before launch, or when preparing a launch checklist for a shared/managed host. Covers: what must NOT travel to live (DB dumps, one-off SQL/PHP scripts, .bak files, error logs), the environment-specific config that must change (trustedHostsPattern, displayErrors, site base, DB credentials, mail), removing basic-auth/staging locks, indexing and redirects, scheduler and SSL, plus verification and rollback. Assumes the build already runs on staging (see the staging-deploy skill for that)."
 metadata:
   author: Wappler
-  version: "1.0"
+  version: "1.1"
 ---
 
 # TYPO3 — staging → live cutover
@@ -92,6 +92,16 @@ Every one of these is pinned to staging and silently wrong on live.
 - **File permissions** — `settings.php` holds the `encryptionKey` and is often world-readable (644) on
   shared hosting. Tighten what the host allows, and rotate the encryption key if staging was widely
   shared.
+- **⚠ Client-side cache lifetime — check it BEFORE go-live, it cannot be undone afterwards.**
+  `curl -sI https://<HOST>/<any-page> | grep -iE 'cache-control|expires'`. With
+  `config.sendCacheHeaders = 1` (t3bootstrap sets it) and **no `config.cache_period`**, TYPO3 sends its
+  core default of **one year** (`CacheLifetimeCalculator::defaultCacheTimeout = 365 * 86400`) as
+  `max-age`, without `private` — so browsers *and* shared proxies keep the page for a year and stop
+  asking. On a live site that means a visitor who reads a page today may see that exact version for a
+  year: no editorial change, no deploy, no `cache:flush` reaches them, because a lifetime already
+  issued cannot be revoked. Set `config.cache_period` to something sane (3600 or 86400), or
+  `sendCacheHeaders = 0`, and verify the header again. Do this BEFORE the site is public — afterwards
+  every visitor who arrived first is stuck until their copy expires.
 
 ---
 

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.4"
+  version: "1.5"
 ---
 
 # TYPO3 v14 t3bootstrap — live-design parity
@@ -48,6 +48,20 @@ placeholders below from the site you're matching; keep a per-project log of what
      path already returned the new one. Symptom: your fix "doesn't work" in the browser but is provably
      live on the server. Cross-check with an in-page `fetch(location.pathname + '?x=' + Math.random(),
      {cache:'no-store'})` and compare against the DOM before concluding anything about the fix.
+   - **⚠⚠ CHECK THE RESPONSE HEADERS BEFORE BELIEVING ANY "still not fixed" REPORT.**
+     `curl -sI <url> | grep -iE 'cache-control|expires'`. With `config.sendCacheHeaders = 1` (t3bootstrap
+     sets it) and **no `config.cache_period`**, TYPO3 emits its core default lifetime — `CacheLifetime
+     Calculator::defaultCacheTimeout = 365 * 86400`, i.e. **`max-age` of ONE YEAR** — to browsers and,
+     since the response carries no `private`, to shared proxies. A `max-age` already handed out
+     **cannot be revoked**: `cache:flush` clears the SERVER cache only, that client simply stops asking.
+     Deploys and editorial changes then never reach returning visitors, and anything rendered INTO the
+     document comes back stale with it — including inline JS config (e.g. `ws_slider` writes its whole
+     configuration as `let options_slider_<uid> = {...}` in the page), so a long-fixed bug reproduces
+     perfectly. Tell-tale: people on YOUR network see every fix, people on the CUSTOMER's network see
+     none. Fix at the source — `config.cache_period = 3600` (caps the server cache AND the emitted
+     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).
 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.