Verallgemeinerte Erkenntnisse aus einem Ticketdurchlauf einarbeiten

Design-Paritaet 1.5 -> 1.6:
- Site-Set-page.tsconfig erreicht keine Datensaetze in Ordnern neben dem
  Site-Root; solche Konfiguration gehoert in die globale page.tsconfig
  der Extension. Symptom ist, dass eine TCEFORM-Aenderung genau fuer
  einen Datensatztyp wirkungslos bleibt.
- Angebotene und gerenderte Crop-Variante koennen auseinanderlaufen,
  dann beschneidet die Redaktion ins Leere.
- Feste Bildhoehe laesst das Seitenverhaeltnis ueber die Breakpoints
  wandern, sodass kein Zuschnitt mehr ueberall passt; aspect-ratio statt
  fester Hoehe.
- Umbrechende Labels brauchen eine reservierte Zeilenhoehe, sonst
  springt der Rhythmus des Rasters; dabei die Untermarge des Absatzes
  neutralisieren und die schmalste Geraetebreite pruefen, nicht nur 360.
- :has() laesst sich nicht in :has() verschachteln, die Regel wird
  komplett verworfen - ohne jede Fehlermeldung.
- Neuer Abschnitt zu Meldungen, die Rasterartefakte statt Fehler sind:
  gegen die Referenzseite pruefen, ueber mehrere Zoomstufen UND
  Subpixel-Versaetze messen, das Ganze per Canvas in einem Durchgang -
  und rechtzeitig sagen, dass Geometrie es nicht loest.

v11->v14 1.1 -> 1.2:
- Ein "verlorenes" Feld ist oft ein umgebautes Feld; zwei Spalten werden
  gern zu einem Feld plus Schalter. Erst das neue Modell pruefen, bevor
  man eine fremde Extension patcht - dann ist es eine Datenmigration.
  Dazu die abgesicherte UPDATE-Bedingung und der Hinweis, dass Fluid
  keinen !-Operator kennt.
- Vor "Regression" gegen die Referenzseite pruefen: zwei Tickets zum
  selben fehlenden Element koennen Verlust und Neuwunsch sein.

Cutover 1.1 -> 1.2:
- Eingebettete Fremddienste sperren sich per frame-ancestors oft gegen
  Staging. Solche Tests sind dort in keinem Browser moeglich; frueh
  klaeren, den eigenen Anteil trotzdem pruefen.

Redmine 1.3 -> 1.4:
- Textile beendet den Durchstrich am ersten Bindestrich im Text, ein
  Pfeil laesst also die Handlungsaufforderung ungestrichen stehen; HTML
  hilft nicht, Redmine escapt es. Und das Ergebnis nachsehen, die API
  bestaetigt nur die Speicherung.

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

typo3-v11-to-v14-ddev-upgrade/SKILL.md

@@ -3,7 +3,7 @@ name: typo3-v11-to-v14-ddev-upgrade
 description: "Bring an existing TYPO3 v11 site up and booting on TYPO3 v14 LTS (v14.3) locally under DDEV, starting from a v11 SQL dump + the old sitepackage. Use when upgrading/migrating a TYPO3 v11 (or v12/13) project to v14 for local dev, when a v11 database dump must be made to boot on v14, when a t3bootstrap-based v11 site needs its composer/config/schema/upgrade-wizards/site-sets brought to v14, or when after such an upgrade a non-admin editor can't edit content (no edit icons / missing Media tab). Covers: composer.json rework to ^14 + private git repos & composer registry auth, config/system/settings.php, the v14 .htaccess, database:updateschema, backend admin, upgrade wizards (incl. confirmable + one-way ones), language packs, wiring t3bootstrap TypoScript via site sets, fixing non-admin editor permissions (be_groups explicit_allowdeny :ALLOW-format conversion, v14 CType allow-list, non_exclude_fields), and the recurring v11->v14 traps. NOT for fresh installs and NOT for server deployment (see the konsoleH staging-deploy skill for that)."
 metadata:
   author: Wappler
-  version: "1.1"
+  version: "1.2"
 ---
 
 # TYPO3 v11 → v14 upgrade (local, DDEV)
@@ -174,5 +174,24 @@ found" is usually a false alarm from curling `localhost`** instead of `<SITE_BAS
   Bootstrap::init + the record API).
 - **TYPO3 Console** (`helhum/typo3-console` ^8.3) works with v14 — `vendor/bin/typo3` is the console
   binary.
+- **⚠ A "lost" field is often a REMODELLED field — check the new data model before patching anything.**
+  Editors report that something they used to maintain has disappeared, you find the old column still
+  sitting in the DB with data and no v14 code referencing it, and the obvious conclusion is that the
+  extension dropped the feature and needs an upstream fix. Look for the v14 equivalent first: two v11
+  columns are frequently folded into **one field plus a switch** (real case: separate columns for a
+  pre- and post-nominal academic title became one title field plus an "append" boolean). Then it is a
+  data migration, not a code change — and no release of a shared extension is needed.
+  - Guard the migration so it cannot destroy the other use of the surviving field:
+    `SET <new> = <old>, <flag> = 1 WHERE <old> <> '' AND (<new> = '' OR <new> IS NULL)`, and verify
+    afterwards that no row was touched which should not have been.
+  - **Then check whether anything RENDERS the switch.** A flag that no template evaluates — not even
+    the owning extension's own templates — is exactly why the data looked lost. Grep the templates for
+    the property before assuming the display side works.
+  - Fluid has **no `!` operator**: write `{x} && {flag} == 0` / `== 1`, not `!{flag}`.
+- **⚠ Verify against the reference site before calling something a regression.** Two tickets can
+  describe the same missing element and be different things: on one page the old site really did show
+  it (a migration loss), on another it never did (a new wish). Fetch the live page and count the
+  occurrences. It changes what you promise, and it saves the "why does it look different from before"
+  conversation later.
 
 Each step verified + a snapshot before wizards = a reversible, debuggable upgrade.