Correct framework-row mode semantics + staging wording from the post-merge review of #39

.claude-plugin/marketplace.json

@@ -6,7 +6,7 @@
   },
   "metadata": {
     "description": "Claude skills for Dynamicweb 10 — organized by task domain, bundled by role.",
-    "version": "3.8.5"
+    "version": "3.8.6"
   },
   "plugins": [
     {

CHANGELOG.md

@@ -3,6 +3,25 @@
 All notable changes to the Dynamicweb Skills plugin are recorded here. The
 `version` field in `.claude-plugin/marketplace.json` tracks these entries.
 
+## [3.8.6]
+
+### Fixed
+- **Framework-preservation claim corrected to the mode that actually governs framework rows.**
+  `dw-demo-swift` SKILL.md Step 0 and `deserialize-flow.md` §3 claimed a PIM-set-up host's
+  SHOP1/DE/EUR/LANG1 rows were preserved because "`seed` mode is destination-wins" — but framework
+  `_sql/` travels in the **deploy** tree, and `deploy` is **source-wins**: the baseline's framework
+  rows UPDATE matching curated rows. Both spots now warn to review/trim `deploy/_sql/` before
+  deserializing into a host with hand-curated framework data; only the `seed` (catalog) pass is
+  destination-wins.
+- **`baselines\` staging wording de-contradicted.** `deserialize-flow.md` §3 both designated
+  `<demo-root>\baselines\` as the canonical download/staging location and kept the legacy warning
+  that a `baselines/` copy is "invisible". Reworded: `baselines\` is the staging copy the snippet
+  copies FROM; `SerializeRoot/` remains the only path the deserialize endpoint reads.
+- **Icon set added to the design-package copy list.** `Files/Images/Icons/` (~80 SVGs incl.
+  `Flags/` and `LoginProviders/`) is verified present in the Swift clone and is the set
+  `integrity-sweep.md` Check 6 verifies — it is now an explicit copy-list entry instead of only a
+  recovery path.
+
 ## [3.8.5]
 
 ### Changed

skills/dw-demo-swift/SKILL.md

@@ -24,9 +24,9 @@ orchestrator abstraction (GSD primary, native command set, and the standalone ha
 
 Before any frontend work (templates, paragraphs, re-skin), load the Swift content baseline into the host's project DB. Swift demos depend on `Swift-v2_*` item types, Swift paragraph wiring, and the **content rows** (Area, Pages, grid-rows, paragraphs) that the baseline ships. `dynamicweb-demo-base` deliberately does NOT deserialize — that step lives here.
 
-**Baseline shape — full deploy + seed.** The `swift-2.3` baseline is a `config/deploy/seed` tree: `deploy/` ships framework `_sql/` (currencies, countries, languages, shops, payments, shippings, VAT) plus content, and `seed/` ships catalog `_sql/` (products, prices, groups, variants) plus content — so a `swift-2.3` deserialize no longer needs the framework pre-seeded, unlike the retired content-only `Swift2.2` baselines. The area YAML uses string FKs (`AreaEcomShopId: "SHOP1"`, `AreaEcomCountryCode: "DE"`) that resolve against the framework rows the deploy pass lands; a PIM-set-up host that already holds SHOP1/DE/EUR/LANG1 stays a clean target (seed mode preserves existing rows). See [`references/deserialize-flow.md`](references/deserialize-flow.md) §3 for the full shape contract.
+**Baseline shape — full deploy + seed.** The `swift-2.3` baseline is a `config/deploy/seed` tree: `deploy/` ships framework `_sql/` (currencies, countries, languages, shops, payments, shippings, VAT) plus content, and `seed/` ships catalog `_sql/` (products, prices, groups, variants) plus content — so a `swift-2.3` deserialize no longer needs the framework pre-seeded, unlike the retired content-only `Swift2.2` baselines. The area YAML uses string FKs (`AreaEcomShopId: "SHOP1"`, `AreaEcomCountryCode: "DE"`) that resolve against the framework rows the deploy pass lands. Caution: framework rows travel in `deploy`, which is **source-wins** — on a host with hand-curated SHOP1/DE/EUR/LANG1 rows the baseline UPDATES those rows; only `seed` (catalog) is destination-wins. See [`references/deserialize-flow.md`](references/deserialize-flow.md) §3 for the full shape contract and the PIM-curated-host warning.
 
-1. **Framework prerequisites in target DB** — the `swift-2.3` baseline's `deploy/_sql/` ships the framework (currencies, countries, languages, shops, payments, shippings, VAT), so a fresh DB no longer needs it pre-seeded. When you WANT a PIM-curated framework instead, set up `SHOP1` (or whichever ShopId the area's YAML references), `DE` country (or whichever AreaEcomCountryCode), `LANG1` with shop language relation, and EUR currency first — PIM-skill `canonical-setup-order.md` Steps 1-4 covers this, and `seed` mode preserves those existing rows.
+1. **Framework prerequisites in target DB** — the `swift-2.3` baseline's `deploy/_sql/` ships the framework (currencies, countries, languages, shops, payments, shippings, VAT), so a fresh DB no longer needs it pre-seeded. When you WANT a PIM-curated framework instead, set up `SHOP1` (or whichever ShopId the area's YAML references), `DE` country (or whichever AreaEcomCountryCode), `LANG1` with shop language relation, and EUR currency first (PIM-skill `canonical-setup-order.md` Steps 1-4) — and then TRIM the matching rows from the baseline's `deploy/_sql/` before deserializing: `deploy` is source-wins, so untrimmed baseline framework rows would overwrite your curated ones (`seed` only preserves existing catalog rows).
 2. **Verify Serializer is installed** in the host per [`../dw-demo-base/references/serializer-reference.md`](../dw-demo-base/references/serializer-reference.md) "Installation".
 3. **Deploy the Swift design package** — npm build, Items XMLs + Designs + Styles copy, the ProductsBackend/ProductsFrontend skip rule, catalog-paragraph path rewrite, and the slider card-template fix all live in [`references/deserialize-flow.md`](references/deserialize-flow.md) §"Design-package deploy (before any deserialize)".
 4. **Run the deserialize flow** -> [`references/deserialize-flow.md`](references/deserialize-flow.md). HTTP POST `/Admin/Api/SerializerDeserialize` with strict mode on. Surfaces FK orphans / missing templates / schema drift as `CumulativeStrictModeException` HTTP 4xx.

skills/dw-demo-swift/references/deserialize-flow.md

@@ -43,6 +43,7 @@ The baseline's content predicates reference `Swift-v2_*` item types whose XML de
 - `Files/System/Items/*.xml` (the item-type definitions the content predicates need)
 - `Files/Templates/Designs/Swift-v2/`
 - `Files/System/Styles/`
+- `Files/Images/Icons/` (~80 SVGs incl. `Flags/` and `LoginProviders/` — the set integrity-sweep Check 6 verifies; verified present in the Swift clone)
 
 **Repositories skip rule.** For `Files/System/Repositories/`, copy **everything EXCEPT `ProductsBackend/` and `ProductsFrontend/`** — those two index Swift's bike-demo custom fields (`PlantHardiness`, `BikeFrameSize`, plant/bike-specific facets, etc.). Copying them into a host whose products use a different data-model causes `BuildIndex` Full to fail with "field not found in products" — the index builder validates every field reference against the live `EcomProductCategoryField` table. The other Swift-shipped indexes (`Content/`, `Files/`, `Post/`, `Secondary users/`) are demo-data-agnostic — they index Pages/Files/blog Posts/Users via standard fields plus item-type fields that DO resolve cleanly; copy those alongside. Hand-write a per-demo Products index targeting the demo's actual data-model fields instead — see [`../../dw-demo-pim/references/canonical-setup-order.md`](../../dw-demo-pim/references/canonical-setup-order.md) Step 16. (For PIM-data + Swift-frontend hybrid demos with N categories × M custom fields each, pick 5-10 demo-relevant fields per category for the index — not the full set; index size is rarely the constraint, but maintenance and admin-UI clarity are.)
 
@@ -90,9 +91,9 @@ Captured via `AskUserQuestion` in the current conversation. Format: `CLAUDE.<hex
 
 Baseline path resolution: every baseline path resolves under the demo's own `<demo-root>\baselines\` folder — the per-demo copy downloaded from the baseline distribution repo your team designates. No hardcoded machine-wide literals.
 
-**The Serializer reads from `Dynamicweb.Host.Suite/wwwroot/Files/System/Serializer/SerializeRoot/<deploy|seed>/`** (joined from `outputDirectory: "Serializer"` in `Files/Serializer.config.json` + `outputSubfolder` per mode). It does NOT read from a project-root `baselines/` folder. A `baselines/` copy is invisible to the deserialize endpoint and any "121 updated" you see comes from whatever else is already in `SerializeRoot/deploy/` (typically a previous serialize roundtripping itself). Verified during a Swift2 baseline import — the original recipe pointed at `baselines/` and silently no-op'd.
+**The Serializer reads from `Dynamicweb.Host.Suite/wwwroot/Files/System/Serializer/SerializeRoot/<deploy|seed>/`** (joined from `outputDirectory: "Serializer"` in `Files/Serializer.config.json` + `outputSubfolder` per mode). The demo's `baselines/` folder is the **download/staging copy only** — the deserialize endpoint never reads it. The snippet below copies `baselines\<name>\` INTO `SerializeRoot/`; that copy step is what makes the content visible. Skipping the copy (or pointing the flow at `baselines/` directly) silently no-ops — any "121 updated" you then see comes from whatever else is already in `SerializeRoot/deploy/` (typically a previous serialize roundtripping itself). Verified during a Swift2 baseline import — the original recipe pointed at `baselines/` and silently no-op'd.
 
-**Baseline shape — full deploy + seed (swift/2.3).** The canonical `swift-2.3` baseline release is a full `config/deploy/seed` tree, NOT the content-only shape the older `Swift2.2` baselines used. `deploy/` ships framework `_sql/` (EcomCountries, EcomCurrencies, EcomLanguages, EcomShops, EcomPayments, EcomShippings, EcomVatGroups, AccessUser, UrlPath, order flow/states) alongside `_content/` (the `Swift 2` + `Swift 2 Nederlands` areas); `seed/` ships catalog `_sql/` (EcomGroups, EcomProducts, EcomPrices, EcomGroupProductRelation, variant + discount tables) alongside its own `_content/`; `config/swift-2.3.json` carries the predicate config. Because the framework rows now ship WITH the baseline (deploy `_sql/`), a `swift-2.3` deserialize no longer requires the target DB to be pre-seeded with shops/currencies/countries the way the content-only `Swift2.2` baselines did. The area YAML still hardcodes `"AreaEcomShopId": "SHOP1"` and `"AreaEcomCountryCode": "DE"` as **string FKs**; with swift/2.3 those FKs resolve against the framework rows the deploy pass lands. A PIM-set-up host that already holds SHOP1/DE/EUR/LANG1 stays a clean target — `seed` mode is destination-wins, so existing framework rows are preserved. **Verify the two-pass (deploy then seed) deserialize against a running host before relying on it — this repoint was prepared without a host run; confirm counts against the baseline's `deploy-manifest.json` / `seed-manifest.json`.**
+**Baseline shape — full deploy + seed (swift/2.3).** The canonical `swift-2.3` baseline release is a full `config/deploy/seed` tree, NOT the content-only shape the older `Swift2.2` baselines used. `deploy/` ships framework `_sql/` (EcomCountries, EcomCurrencies, EcomLanguages, EcomShops, EcomPayments, EcomShippings, EcomVatGroups, AccessUser, UrlPath, order flow/states) alongside `_content/` (the `Swift 2` + `Swift 2 Nederlands` areas); `seed/` ships catalog `_sql/` (EcomGroups, EcomProducts, EcomPrices, EcomGroupProductRelation, variant + discount tables) alongside its own `_content/`; `config/swift-2.3.json` carries the predicate config. Because the framework rows now ship WITH the baseline (deploy `_sql/`), a `swift-2.3` deserialize no longer requires the target DB to be pre-seeded with shops/currencies/countries the way the content-only `Swift2.2` baselines did. The area YAML still hardcodes `"AreaEcomShopId": "SHOP1"` and `"AreaEcomCountryCode": "DE"` as **string FKs**; with swift/2.3 those FKs resolve against the framework rows the deploy pass lands. **Mode-semantics warning for PIM-curated hosts:** framework rows travel in `deploy`, and `deploy` is **source-wins** — the baseline's SHOP1/DE/EUR/LANG1 rows UPDATE matching rows already in the target. Only the `seed` pass (catalog) is destination-wins. A host with hand-curated framework rows is therefore NOT automatically preserved: review (and if needed trim) `deploy/_sql/` against the target's curated framework data before deserializing. **Verify the two-pass (deploy then seed) deserialize against a running host before relying on it — this repoint was prepared without a host run; confirm counts against the baseline's `deploy-manifest.json` / `seed-manifest.json`.**
 
 ```powershell
 $baseline = "swift-2.3"  # the canonical swift/2.3 baseline; per-demo "<demo>-base" baselines live alongside it under baselines\