diff --git a/typo3-t3bootstrap-live-design-parity/SKILL.md b/typo3-t3bootstrap-live-design-parity/SKILL.md
index 133740d..cb5bdee 100644
--- a/typo3-t3bootstrap-live-design-parity/SKILL.md
+++ b/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.7"
+  version: "1.8"
 ---
 
 # TYPO3 v14 t3bootstrap — live-design parity
@@ -205,6 +205,22 @@ rewrite parts of it, and whatever was never expressible in the backend gets norm
   huge. **Fix at the source:** give those selects an empty first item (a `selectSingleWithTypoScriptPlaceholder`
   renderType is *designed* for that empty state — it then shows the TypoScript default as placeholder).
   Then clean the affected records; the schema fix alone does not repair stored data.
+- **⚠ The same fix creates a SECOND, quieter failure when a FlexForm declares one setting in TWO
+  sheets.** Giving the selects an empty first item stops the "everything becomes yes" flood, but a save
+  still MATERIALISES every sheet — now with empty values. If a "quick settings" sheet (`sDEF`) and a
+  per-topic sheet both carry the same `<field index="settings.x">`, `convertFlexFormContentToArray()`
+  flattens all sheets into one array and the **later sheet wins**, so the empty duplicate wipes the
+  value the editor set in `sDEF`. It is then dropped by the `mergeRecursiveWithOverrule(…,
+  includeEmptyValues: false)` against TypoScript and the record silently falls back to the extension
+  defaults. Measured on a ws_slider element: `settings.loop = 1` and `autoplay.delay = 5000` stored in
+  `sDEF`, rendered as `loop:false` and `delay:3000` (the constants) — every one of the six configured
+  options neutralised, and the record's `tstamp` was the save minutes earlier.
+  **Diagnose with one command** — duplicates are visible in the raw XML:
+  `grep -o 'index="settings\.[^"]*"' <flexform> | sort | uniq -c | awk '$1>1'`.
+  **Do not "fix" it by re-cleaning the record** (that is what the previous round did — the next save
+  undoes it). Put the value where a save cannot reach: a **site setting / TypoScript constant**, which
+  the empty flexform value then falls back to, so the element is save-proof. Report the duplicate
+  declaration upstream as the actual defect.
 - **Your own CSS outranking an editor-facing field** — see the spacing section above.
 
 **Two rules that follow:**