diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index 9d9f640..a2f4827 100644 --- a/.claude-plugin/marketplace.json +++ b/.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": [ { diff --git a/CHANGELOG.md b/CHANGELOG.md index 5bdf1f8..4f6b3bc 100644 --- a/CHANGELOG.md +++ b/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 + `\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 diff --git a/skills/dw-demo-swift/SKILL.md b/skills/dw-demo-swift/SKILL.md index 4d6bdc5..5126595 100644 --- a/skills/dw-demo-swift/SKILL.md +++ b/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. diff --git a/skills/dw-demo-swift/references/deserialize-flow.md b/skills/dw-demo-swift/references/deserialize-flow.md index 9498104..5749be1 100644 --- a/skills/dw-demo-swift/references/deserialize-flow.md +++ b/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.\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//`** (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//`** (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\\` 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 "-base" baselines live alongside it under baselines\