From 5e6fa22ccf76d101fb4ffe10b07076dbbe75a799 Mon Sep 17 00:00:00 2001 From: Justinvolved <64196420+Justinvolved@users.noreply.github.com> Date: Thu, 2 Jul 2026 19:28:35 +0200 Subject: [PATCH 1/4] Fold demo-build learning: repoint dw-demo-swift deserialize-flow to the swift/2.3 baseline slot The vault's canonical Swift baseline moved from the content-only Swift2.2 slot to swift-2.3, which is a full config/deploy/seed tree (framework _sql/ + content in deploy/, catalog _sql/ + content in seed/). deserialize-flow.md still defaulted to $baseline="Swift2.2" and assumed _content/ at the slot root, so a swift/2.3 demo would stage from a stale slot and the content-only "ships no _sql/" schema-drift notes no longer held. Repointed the $baseline default and staging snippet to stage both mode trees from swift-2.3, rewrote the baseline-shape and section-9 notes for the _sql/- shipping baseline, and swept baseline-slot source-of-truth paths across the dw-demo-swift companion references (templates, paragraphs, customer-center, asset-organisation, admin-ui-authoring, re-skin, integrity-sweep) plus dw-demo-pim/access-surfaces and the dw-demo-base INDEX template to swift-2.3\deploy\_content\. Swift-2.2-era mechanics prose left intact (per-hit sweep, not a blanket rename); the two-pass deploy+seed deserialize is flagged for host verification. --- .claude-plugin/marketplace.json | 2 +- CHANGELOG.md | 16 ++++++++ README.md | 2 +- skills/dw-demo-base/assets/INDEX.md.template | 2 +- .../dw-demo-pim/references/access-surfaces.md | 2 +- .../references/admin-ui-authoring.md | 2 +- .../references/asset-organisation.md | 2 +- .../references/customer-center.md | 4 +- .../references/deserialize-flow.md | 38 ++++++++++--------- .../references/integrity-sweep.md | 2 +- skills/dw-demo-swift/references/paragraphs.md | 4 +- skills/dw-demo-swift/references/re-skin.md | 2 +- skills/dw-demo-swift/references/templates.md | 13 ++++--- 13 files changed, 56 insertions(+), 35 deletions(-) diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index f508c36..da874f2 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.2" + "version": "3.8.3" }, "plugins": [ { diff --git a/CHANGELOG.md b/CHANGELOG.md index cd3c10e..3020219 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -3,6 +3,22 @@ All notable changes to the Dynamicweb Skills plugin are recorded here. The `version` field in `.claude-plugin/marketplace.json` tracks these entries. +## [3.8.3] + +### Changed +- **`dw-demo-swift` deserialize-flow repointed off the retired content-only `Swift2.2` slot to the + canonical `swift-2.3` baseline.** The vault's `swift-2.3` slot is a full `config/deploy/seed` + tree (framework `_sql/` + content in `deploy/`, catalog `_sql/` + content in `seed/`), not the + content-only `_content/`-at-root shape the older `Swift2.2` slot used. Repointed the `$baseline` + default and staging snippet in `dw-demo-swift/references/deserialize-flow.md` to stage both mode + trees from `swift-2.3`, rewrote the "baseline shape" and §9 schema-drift notes for the + `_sql/`-shipping baseline, and swept baseline-slot source-of-truth paths in the companion + references (`templates`, `paragraphs`, `customer-center`, `asset-organisation`, + `admin-ui-authoring`, `re-skin`, `integrity-sweep`) plus `dw-demo-pim/access-surfaces` and the + `dw-demo-base` INDEX template to the `swift-2.3\deploy\_content\` location. Swift-2.2-era + mechanics prose left intact (per-hit sweep, not a blanket rename). The two-pass deploy+seed + deserialize is flagged for host verification. + ## [3.8.2] ### Changed diff --git a/README.md b/README.md index 211df30..aa1a048 100644 --- a/README.md +++ b/README.md @@ -142,7 +142,7 @@ Foundation skill for all demos. Scaffolds the dw10-suite host, wires the Backend PIM modelling from a blank DB — product data built from scratch via MCP. Use after `dw-demo-base`. **[dw-demo-swift](skills/dw-demo-swift/SKILL.md)** -Swift frontend — baseline content deserialize, templates, paragraph types, Visual Editor, and the customer-center playbook. Use after `dw-demo-base`. +Swift frontend — swift/2.3 baseline deserialize, templates, paragraph types, Visual Editor, and the customer-center playbook. Use after `dw-demo-base`. **[dw-demo-erp](skills/dw-demo-erp/SKILL.md)** ERP integration demo — DB-staged mock or live BC, Integration Framework rules. Use after `dw-demo-base`. diff --git a/skills/dw-demo-base/assets/INDEX.md.template b/skills/dw-demo-base/assets/INDEX.md.template index 157d9c2..31b1871 100644 --- a/skills/dw-demo-base/assets/INDEX.md.template +++ b/skills/dw-demo-base/assets/INDEX.md.template @@ -9,7 +9,7 @@ | `samples` | `$DW_VAULT\samples\` | Reference admin-UI samples (`dw10adminUI/`) and any future sample bundles | _(applies to dw10adminUI commit hash)_ | _(YYYY-MM-DD)_ | | `databases` | `$DW_VAULT\databases\` | Clean-DB zips / .mdf snapshots for fast restore (the escape-hatch alternative to deserialize). When populated, this slot is the **canonical in-vault fast-restore source** — name the artifact in this row and keep the stamps current; never describe the slot as reserved/empty while an artifact sits in it (`compare-vault.md` drift detection and the setup-checks probe expect it here) | _(version of DW10 the snapshot targets)_ | _(YYYY-MM-DD)_ | | `docs` | `$DW_VAULT\docs\` | Curated DW10 docs (custom admin screens guide, middleware deep-dive) | _(N/A -- version-agnostic)_ | _(YYYY-MM-DD)_ | -| `serialized-data` | `$DW_VAULT\serialized-data\` | YAML baselines for the DW Serializer deserialize. Each subfolder is one baseline (e.g. generic `Swift2.2/`, plus per-demo customer-flavoured baselines named `-base/` by convention once derived). | _(per-baseline; each subfolder lists its target DW10 version in its own README)_ | _(YYYY-MM-DD)_ | +| `serialized-data` | `$DW_VAULT\serialized-data\` | YAML baselines for the DW Serializer deserialize. Each subfolder is one baseline (e.g. generic `swift-2.3/`, plus per-demo customer-flavoured baselines named `-base/` by convention once derived). | _(per-baseline; each subfolder lists its target DW10 version in its own README)_ | _(YYYY-MM-DD)_ | ## Resolution rule diff --git a/skills/dw-demo-pim/references/access-surfaces.md b/skills/dw-demo-pim/references/access-surfaces.md index 72b5d77..e75de6d 100644 --- a/skills/dw-demo-pim/references/access-surfaces.md +++ b/skills/dw-demo-pim/references/access-surfaces.md @@ -24,7 +24,7 @@ Two vault-resolved baselines this demo skill leans on (per-project, discovered v | Ref | How to find it in the current project | |---|---| -| Swift 2.2 baseline (vault) | `$env:DW_VAULT\serialized-data\Swift2.2\` — the canonical Swift 2.2 baseline. Its serialized index XML is the copy-paste source for `Products.index` definitions. | +| Swift baseline (vault) | `$env:DW_VAULT\serialized-data\swift-2.3\` — the canonical swift/2.3 baseline (a `config/deploy/seed` tree). Its serialized index XML is the copy-paste source for `Products.index` definitions. | | DW10 source clone (vault) | `$env:DW_VAULT\dw10source\` — search `src/Features/Ecommerce` for Ecom internals and `Dynamicweb.Products.UI` for admin UI behavior. Otherwise fall back to https://doc.dynamicweb.dev/ | When the user gives you a token, port, or path in chat, treat it as scoped to the project in the current working directory — save it in conversation state, not as a global default. diff --git a/skills/dw-demo-swift/references/admin-ui-authoring.md b/skills/dw-demo-swift/references/admin-ui-authoring.md index b8d314a..98a5df1 100644 --- a/skills/dw-demo-swift/references/admin-ui-authoring.md +++ b/skills/dw-demo-swift/references/admin-ui-authoring.md @@ -1,6 +1,6 @@ # admin-ui-authoring.md -> Swift 2 admin-UI authoring: the configuration-only Day-1 workflow (get 80% of the brand applied via admin Style tools alone, zero CSS / Razor / .cs edits) plus the Visual Editor patterns for editing paragraph properties without touching code. Operates against a deserialized Swift 2.2 baseline (source-of-truth at `$env:DW_VAULT\serialized-data\Swift2.2\`). +> Swift 2 admin-UI authoring: the configuration-only Day-1 workflow (get 80% of the brand applied via admin Style tools alone, zero CSS / Razor / .cs edits) plus the Visual Editor patterns for editing paragraph properties without touching code. Operates against a deserialized swift/2.3 baseline (source-of-truth at `$env:DW_VAULT\serialized-data\swift-2.3\`). > > Swift 2.x guidance — never follow `/swift/swift-1/` URLs (different content model, phased out). diff --git a/skills/dw-demo-swift/references/asset-organisation.md b/skills/dw-demo-swift/references/asset-organisation.md index a0a1dec..0094445 100644 --- a/skills/dw-demo-swift/references/asset-organisation.md +++ b/skills/dw-demo-swift/references/asset-organisation.md @@ -1,6 +1,6 @@ # asset-organisation.md -> `wwwroot/Files/` asset organisation for a Swift 2.2 / Dynamicweb 10 demo. Reference layouts at `$env:DW_VAULT\serialized-data\Swift2.2\` and Swift v2.3.0 at https://github.com/dynamicweb/Swift. +> `wwwroot/Files/` asset organisation for a Swift 2.2 / Dynamicweb 10 demo. Reference layouts at `$env:DW_VAULT\serialized-data\swift-2.3\` and Swift v2.3.0 at https://github.com/dynamicweb/Swift. > > Swift 2.x guidance — never follow `/swift/swift-1/` URLs (different content model, phased out). diff --git a/skills/dw-demo-swift/references/customer-center.md b/skills/dw-demo-swift/references/customer-center.md index 914a3b7..55e0e76 100644 --- a/skills/dw-demo-swift/references/customer-center.md +++ b/skills/dw-demo-swift/references/customer-center.md @@ -26,7 +26,7 @@ Rebuilding is never the right answer. The stock section already supports imperso ## 2. Page-tree map -Source-of-truth: `$env:DW_VAULT\serialized-data\Swift2.2\_content\Swift 2\Customer center\` deserialized into a running host. Backtick-quote any path string when copying into other tools -- folder names contain spaces. +Source-of-truth: `$env:DW_VAULT\serialized-data\swift-2.3\deploy\_content\Swift 2\Customer center\` deserialized into a running host. Backtick-quote any path string when copying into other tools -- folder names contain spaces. ``` Customer center/ @@ -61,7 +61,7 @@ Symptom: CSR Overview page has empty grid rows, or `CSR/Orders/` shows no orders 3. **CSR ↔ customer grants not wired** -- `AccessUserSecondaryRelation` is empty for this CSR, or the column direction is inverted, or the required index-rebuild + cache-clear follow-up was skipped. See [`commerce-orders.md`](../../dw-demo-base/references/foundational/commerce-orders.md) "`AccessUserSecondaryRelation` — the impersonation grant". 4. **Index not built or cache stale after wiring the grant** -- see [`commerce-orders.md`](../../dw-demo-base/references/foundational/commerce-orders.md). For Products-index rebuilds, see [dynamicweb-pim-demo/references/governance.md "Recovery recipe: Rebuild Products index"](../../dw-demo-pim/references/governance.md). -What is NOT the cause: missing paragraphs / broken templates / Swift 2.3 incompatibility. The Swift2.2 baseline is verified working by [`deserialize-flow.md`](deserialize-flow.md); if the page renders at all, the structure is intact and the issue is data-side. +What is NOT the cause: missing paragraphs / broken templates / Swift 2.3 incompatibility. The swift/2.3 baseline is verified working by [`deserialize-flow.md`](deserialize-flow.md); if the page renders at all, the structure is intact and the issue is data-side. ## 5. Persona presentation: avatar + role badge diff --git a/skills/dw-demo-swift/references/deserialize-flow.md b/skills/dw-demo-swift/references/deserialize-flow.md index ef6879e..cd62ce2 100644 --- a/skills/dw-demo-swift/references/deserialize-flow.md +++ b/skills/dw-demo-swift/references/deserialize-flow.md @@ -11,7 +11,7 @@ - [6. Identity model](#6-identity-model) - [7. Post-deserialize host restart guidance](#7-post-deserialize-host-restart-guidance) - [8. Mandatory next step](#8-mandatory-next-step) -- [9. Known schema-drift workaround (Swift 2.2 baseline ↔ DW10)](#9-known-schema-drift-workaround-swift-22-baseline--dw10) +- [9. Known schema-drift workaround (Swift 2.3 baseline ↔ DW10)](#9-known-schema-drift-workaround-swift-23-baseline--dw10) > Deserialize a Swift content baseline from `$env:DW_VAULT\serialized-data\\` into the per-demo project DB. Uses the DW Serializer + Management API. Strict mode is on by default — failures surface as `CumulativeStrictModeException`. Always followed by [`integrity-sweep.md`](integrity-sweep.md). > @@ -91,18 +91,23 @@ Vault path resolution: every baseline path resolves through `$env:DW_VAULT` (bas **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. -**Baseline shape — content-only.** The canonical Swift2.2 vault baseline contains ONLY `_content/` (Area + pages + grid-rows + paragraphs + master items, ~640 YAML files). It does **NOT** ship `_sql/`. Framework data (shops, currencies, countries, languages, manufacturers, payments, shippings, VAT groups) must already exist in the target DB before this deserialize runs. The area's YAML hardcodes `"AreaEcomShopId": "SHOP1"` and `"AreaEcomCountryCode": "DE"` as **string FKs** — they resolve against whatever rows have those surrogate ids in target. A PIM-set-up host (`dynamicweb-pim-demo`'s blank-DB flow that creates SHOP1, DE, EUR, LANG1) is therefore a clean baseline target — the deserialize lands content additively without conflicting with the PIM-curated framework. Hosts missing the framework must run the relevant `dynamicweb-pim-demo` setup steps (`canonical-setup-order.md` Steps 1-4) first. +**Baseline shape — full deploy + seed (swift/2.3).** The canonical `swift-2.3` vault baseline is a full `config/deploy/seed` tree, NOT the content-only shape the older `Swift2.2` slot 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` slot 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 slot's `deploy-manifest.json` / `seed-manifest.json`.** ```powershell -$baseline = "Swift2.2" # or a customer-flavoured "-base" baseline once it has been derived (see $env:DW_VAULT\INDEX.md serialized-data row for available baselines) -if (-not (Test-Path "$env:DW_VAULT\serialized-data\$baseline\_content")) { - throw "Baseline '$baseline' not found (or missing _content/) at `$env:DW_VAULT\serialized-data\$baseline`. Check INDEX.md serialized-data row." +$baseline = "swift-2.3" # the canonical swift/2.3 slot (see $env:DW_VAULT\INDEX.md serialized-data row); per-demo "-base" baselines live alongside it +$slot = "$env:DW_VAULT\serialized-data\$baseline" +if (-not (Test-Path "$slot\deploy\_content")) { + throw "Baseline '$baseline' not found (or missing deploy\_content\) at `$slot. Check INDEX.md serialized-data row." } -$deployRoot = "Dynamicweb.Host.Suite/wwwroot/Files/System/Serializer/SerializeRoot/deploy" -New-Item -ItemType Directory -Path "$deployRoot/_content" -Force | Out-Null -Copy-Item -Recurse "$env:DW_VAULT\serialized-data\$baseline\_content\*" "$deployRoot/_content/" -Force -# Note: no `_sql/` to copy — current baseline is content-only by design. -# If a future baseline reintroduces `_sql/`, add the corresponding copy + framework-conflict reasoning back. +$serializeRoot = "Dynamicweb.Host.Suite/wwwroot/Files/System/Serializer/SerializeRoot" +# swift/2.3 is a full deploy + seed baseline: stage BOTH mode trees (each ships _content/ + _sql/). +foreach ($mode in 'deploy','seed') { + if (Test-Path "$slot\$mode") { + New-Item -ItemType Directory -Path "$serializeRoot/$mode" -Force | Out-Null + Copy-Item -Recurse "$slot\$mode\*" "$serializeRoot/$mode/" -Force + } +} +# Unlike the content-only Swift2.2 slot, swift/2.3 ships framework + catalog `_sql/` in deploy/ and seed/. ``` **Pre-import: re-serialize before merging vault YAML.** If the target host has any pre-existing predicates (e.g. `"Content - "`), POST `/Admin/Api/SerializerSerialize` FIRST so the deploy folder reflects current DB state. Otherwise the deserialize will revert any in-DB changes you made since the last serialize (we hit this in practice: a recent area-rename via API was reverted by re-applying stale YAML for the old area name). After serializing, also delete any folders in `_content/` whose name matches a stale area name — `Serialize` writes the current name's folder but does NOT clean the old one (e.g. `_content//` survives a rename to `_content//`). @@ -128,7 +133,7 @@ Copy-Item -Recurse "$env:DW_VAULT\serialized-data\$baseline\_content\*" "$deploy - **(a)** Copy YAML directly into `Dynamicweb.Host.Suite/wwwroot/Files/System/Serializer/SerializeRoot/deploy/` (this snippet — verified working). - **(b)** Configure `Files/Serializer.config.json` `outputDirectory` to point at `$env:DW_VAULT\serialized-data\\` directly. Faster (no copy), but the running host's serialize would also write back into the vault — destination contamination risk. Not recommended; (a) is the canonical approach. -**Single canonical Swift2.2 path:** `$baseline = "Swift2.2"` resolves to `$env:DW_VAULT\serialized-data\Swift2.2\` — the single canonical generic baseline. Per-demo customer-flavoured baselines (named `-base/` by convention) live alongside `Swift2.2/` in the same `serialized-data/` slot once they have been derived; both share this flow. +**Single canonical swift/2.3 path:** `$baseline = "swift-2.3"` resolves to `$env:DW_VAULT\serialized-data\swift-2.3\` — the single canonical generic baseline (a `config/deploy/seed` tree). Per-demo customer-flavoured baselines (named `-base/` by convention) live alongside `swift-2.3/` in the same `serialized-data/` slot once they have been derived; both share this flow. The retired content-only `Swift2.2/` slot remains in the vault for legacy demos but is no longer the default. ## 4. Step 2 — POST against running host @@ -182,12 +187,11 @@ The sweep is the second line of defence for the failures strict mode does not ca - Defense-in-depth on top of strict mode (Checks 1 and 4). - `BuildIndex` Full + wait for a fresh successful build (Check 5). -## 9. Known schema-drift workaround (Swift 2.2 baseline ↔ DW10) +## 9. Known schema-drift workaround (Swift 2.3 baseline ↔ DW10) -With the **content-only** baseline shape, one drift point remains. +The `swift-2.3` baseline ships framework + catalog `_sql/` in its `deploy/` and `seed/` trees (unlike the content-only `Swift2.2` slot). Re-verify the former `_sql/`-era drift points against a host when adopting swift/2.3 — the two workarounds below were retired under the content-only shape and may re-apply now that `_sql/` ships again. -Superseded: the baseline ships no `_sql/`, so the former `EcomCurrencies.CurrencyUseCurrencyCodeForFormat` column-strip workaround is obsolete — reconstruct from git history if a future baseline reintroduces `_sql/`. -Superseded: same for the former `EcomShopGroupRelation/GROUP253$$SHOP19.yml` orphan-YAML workaround. +Superseded (content-only era): the `EcomCurrencies.CurrencyUseCurrencyCodeForFormat` column-strip and the `EcomShopGroupRelation/GROUP253$$SHOP19.yml` orphan-YAML workarounds were retired when the baseline dropped `_sql/`. With swift/2.3 shipping `_sql/` again, confirm during a host deserialize whether either recurs; reconstruct specifics from git history if needed. ### 9.1 — Content predicates require Swift v2 item-type XMLs @@ -195,13 +199,13 @@ The baseline's `Content - Swift 2 (...)` predicates reference item types like `S Superseded: deploy-design-first is the only viable path — the former Approach A ("strip Content predicates") no longer applies with a content-only baseline, and running with strict mode off remains forbidden per §4. -### 9.2 — Verified clean outcome (content-only) +### 9.2 — Verified clean outcome (legacy content-only Swift2.2 slot) For a content-only baseline against a PIM-set-up host (SHOP1 + DE + EUR + LANG1 already present), the deserialize POST returns **HTTP 200 with 0 failed predicates**. Counts will be in the shape: ~640 content rows created/updated (one Area row "Swift 2", ~50 Pages, ~150 grid-rows, ~440 paragraphs — exact numbers depend on baseline version), 0 framework rows touched. Verify post-deserialize: - `SELECT COUNT(*) FROM Areas` → +1 (the new "Swift 2" area) - `SELECT COUNT(*) FROM Page` → ~+50 - Existing PIM data (products, manufacturers, catalog groups, data models, custom field values, EcomDetails image/asset rows) → **untouched** -If the deserialize reports any `EcomShopGroupRelation` / `EcomCurrencies` / `EcomCountries` predicate touching rows, the baseline has reverted to the legacy `_sql/`-shipping shape — re-read this file's top-of-§3 "Baseline shape" note and reconcile. +Note (swift/2.3): unlike the content-only `Swift2.2` slot described in this §9.2, the `swift-2.3` baseline legitimately touches framework rows (`EcomShops`, `EcomCurrencies`, `EcomCountries`, …) via its `deploy/_sql/` pass and catalog rows via `seed/_sql/` — that is expected, not a reversion. The counts above characterise the legacy content-only outcome; capture the swift/2.3 deploy+seed counts from a host run and record them here once verified. diff --git a/skills/dw-demo-swift/references/integrity-sweep.md b/skills/dw-demo-swift/references/integrity-sweep.md index e80e735..920746b 100644 --- a/skills/dw-demo-swift/references/integrity-sweep.md +++ b/skills/dw-demo-swift/references/integrity-sweep.md @@ -226,7 +226,7 @@ $dst = "Dynamicweb.Host.Suite\wwwroot\Files\Images\Icons" Copy-Item -Path $src -Destination $dst -Recurse -Force ``` -Substitute `` for whatever the vault's `INDEX.md` names as the Swift baseline slot for this project (e.g. `Swift2.2`). No host restart required — `ReadFile` reads on every render. +Substitute `` for whatever the vault's `INDEX.md` names as the Swift baseline slot for this project (e.g. `swift-2.3`). No host restart required — `ReadFile` reads on every render. **Pitfall:** if the deserialize used a non-Swift baseline (e.g. a customer-flavoured baseline with a curated icon subset), do NOT blanket-copy from the generic Swift slot — start from the baseline-flavoured slot and merge in any missing files individually. Audit the result with `git status` so the demo's `CUSTOMISATIONS.md` can record the asset-source provenance. diff --git a/skills/dw-demo-swift/references/paragraphs.md b/skills/dw-demo-swift/references/paragraphs.md index 5826b24..9e49691 100644 --- a/skills/dw-demo-swift/references/paragraphs.md +++ b/skills/dw-demo-swift/references/paragraphs.md @@ -1,6 +1,6 @@ # paragraphs.md -> Swift 2.2 paragraph guardrails for demos. Source-of-truth: paragraphs are exposed in admin UI under each page; backing definitions live in `wwwroot/Files/Templates/Paragraph/` (built-in — read-only) and the page-preset YAML at `$env:DW_VAULT\serialized-data\Swift2.2\_content\Swift 2\\\\paragraph-*.yml`. +> Swift 2.2 paragraph guardrails for demos. Source-of-truth: paragraphs are exposed in admin UI under each page; backing definitions live in `wwwroot/Files/Templates/Paragraph/` (built-in — read-only) and the page-preset YAML at `$env:DW_VAULT\serialized-data\swift-2.3\deploy\_content\Swift 2\\\\paragraph-*.yml`. > > Swift 2.x guidance — never follow `/swift/swift-1/` URLs (different content model, phased out). @@ -20,7 +20,7 @@ here is the demo guardrail: the paragraph types you must NOT replace. To trace what a specific paragraph does on a Swift 2.2 page: note the page in admin (e.g. `Customer center/CSR/Orders`); the corresponding YAML lives at -`$env:DW_VAULT\serialized-data\Swift2.2\_content\Swift 2\Customer center\CSR\Orders\grid-row-1\paragraph-c1-1.yml`; +`$env:DW_VAULT\serialized-data\swift-2.3\deploy\_content\Swift 2\Customer center\CSR\Orders\grid-row-1\paragraph-c1-1.yml`; the YAML's `Type` field names the paragraph definition and the rest carries its configured properties. This is read-only inspection — you don't edit the vault YAML; you edit paragraph properties via the Admin UI Visual Editor on the live host (which writes to the host's project DB, not back to the vault). diff --git a/skills/dw-demo-swift/references/re-skin.md b/skills/dw-demo-swift/references/re-skin.md index 59f9b98..0a2d4d4 100644 --- a/skills/dw-demo-swift/references/re-skin.md +++ b/skills/dw-demo-swift/references/re-skin.md @@ -58,7 +58,7 @@ Fix: define a `_` custom item type — see [`content-modell ## Recipe -Operates on a deserialized Swift2.2 baseline at `$env:DW_VAULT\serialized-data\Swift2.2\` (resolved into a running host via this skill's [`deserialize-flow.md`](deserialize-flow.md)). All steps are admin UI only. Throughout: `` is the demo customer's short slug (lowercase, no spaces). +Operates on a deserialized swift/2.3 baseline at `$env:DW_VAULT\serialized-data\swift-2.3\` (resolved into a running host via this skill's [`deserialize-flow.md`](deserialize-flow.md)). All steps are admin UI only. Throughout: `` is the demo customer's short slug (lowercase, no spaces). ### 1. Logo diff --git a/skills/dw-demo-swift/references/templates.md b/skills/dw-demo-swift/references/templates.md index 6e1c5b3..d5585a9 100644 --- a/skills/dw-demo-swift/references/templates.md +++ b/skills/dw-demo-swift/references/templates.md @@ -1,6 +1,6 @@ # templates.md -> Swift 2.2 template / page-preset routing. Source-of-truth: `$env:DW_VAULT\serialized-data\Swift2.2\_content\Swift 2\` deserialized into a running host. Reference Swift v2.3.0 templates at https://github.com/dynamicweb/Swift (requires DW 10.24.6+). +> Swift template / page-preset routing. Source-of-truth: `$env:DW_VAULT\serialized-data\swift-2.3\deploy\_content\Swift 2\` deserialized into a running host. Reference Swift v2.3.0 templates at https://github.com/dynamicweb/Swift (requires DW 10.24.6+). > > Swift 2.x guidance — never follow `/swift/swift-1/` URLs (different content model, phased out). @@ -15,11 +15,12 @@ live here has been folded up into the foundational candidates; the demo skill po | SQL-direct Page/GridRow/Paragraph required columns (the `PageActiveFrom`/`PageActiveTo` silent-404 vector et al.) | [`sql-direct-seeding.md`](sql-direct-seeding.md) → [`data-access.md`](../../dw-demo-base/references/foundational/data-access.md) | | Paragraph types + the component-first gate | [`paragraphs.md`](paragraphs.md) | -## Swift v2.3.0 vs v2.2 baseline +## Swift v2.3.0 templates + swift/2.3 baseline -Target **Swift v2.3.0 templates** at the GitHub repo while keeping **Swift 2.2 baseline data** at -`$env:DW_VAULT\serialized-data\Swift2.2\`. The 2.3.0 release headlines (language selector + improved -off-canvas nav) don't break 2.2 content; you can pull 2.3.0 template files alongside the 2.2 baseline. -Pin baseline regeneration to a future polish phase. +Target **Swift v2.3.0 templates** at the GitHub repo alongside the **swift/2.3 baseline data** at +`$env:DW_VAULT\serialized-data\swift-2.3\` (a `config/deploy/seed` tree; content lives under +`deploy\_content\` + `seed\_content\`). The 2.3.0 release headlines (language selector + improved +off-canvas nav) match this baseline. The legacy content-only `Swift2.2\` slot remains in the vault +for older demos but is no longer the default. Reference: https://github.com/dynamicweb/Swift/releases/tag/v2.3.0 From a31c08b7c75fcab4352ca00ef97148d5b5e9d2d2 Mon Sep 17 00:00:00 2001 From: Justinvolved <64196420+Justinvolved@users.noreply.github.com> Date: Thu, 2 Jul 2026 19:32:09 +0200 Subject: [PATCH 2/4] Fold demo-build learning: add pack-activation reference for installing a feature pack into a demo host MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Demo builders had no documented path to add a feature pack to a running demo host — the pack install steps only existed inside the harness gate automation. Added dw-demo-swift/references/pack-activation.md: a consumer-facing reference that resolves a pack release from the feature-packs// vault slot, reads pack.json, source-drops the .cs into the host's Packs\\ and rebuilds, copies disk-overlay templates/item types, and deserializes the baseline-fragment mode trees (seed/deploy) strictly after the base baseline. It documents the confirmed pack zip anatomy and the activation model (code compiles into the host; the fragment is additive and never edits base YAML). Added the SKILL.md router row and completed the swift/2.3 baseline-shape supersede in SKILL.md Step 0 (retiring the content-only Swift2.2 framing). --- .claude-plugin/marketplace.json | 2 +- CHANGELOG.md | 13 ++ README.md | 2 +- skills/dw-demo-swift/SKILL.md | 7 +- .../references/pack-activation.md | 199 ++++++++++++++++++ 5 files changed, 218 insertions(+), 5 deletions(-) create mode 100644 skills/dw-demo-swift/references/pack-activation.md diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index da874f2..c72f50b 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.3" + "version": "3.8.4" }, "plugins": [ { diff --git a/CHANGELOG.md b/CHANGELOG.md index 3020219..93fc009 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -3,6 +3,19 @@ All notable changes to the Dynamicweb Skills plugin are recorded here. The `version` field in `.claude-plugin/marketplace.json` tracks these entries. +## [3.8.4] + +### Added +- **`dw-demo-swift/references/pack-activation.md` — install a feature pack into a demo host.** A new + consumer-facing reference documenting the L3→demo-host install path: resolve a pack release from the + `feature-packs//` vault slot, read `pack.json`, source-drop the `.cs` into the host's + `Packs\\` and rebuild, copy disk-overlay templates/item types, and deserialize the + `baseline-fragment` mode trees (seed/deploy) strictly AFTER the base baseline. Documents the confirmed + pack zip anatomy (pack.json, src/*.cs, templates/, itemtypes/, baseline-fragment/{seed,deploy}/) and + the activation model (code compiles into the host; the fragment is additive and never edits base YAML). + Added the router row to `dw-demo-swift/SKILL.md` and completed the swift/2.3 baseline-shape supersede in + SKILL.md Step 0 (retiring the content-only `Swift2.2` framing). + ## [3.8.3] ### Changed diff --git a/README.md b/README.md index aa1a048..55d4257 100644 --- a/README.md +++ b/README.md @@ -142,7 +142,7 @@ Foundation skill for all demos. Scaffolds the dw10-suite host, wires the Backend PIM modelling from a blank DB — product data built from scratch via MCP. Use after `dw-demo-base`. **[dw-demo-swift](skills/dw-demo-swift/SKILL.md)** -Swift frontend — swift/2.3 baseline deserialize, templates, paragraph types, Visual Editor, and the customer-center playbook. Use after `dw-demo-base`. +Swift frontend — swift/2.3 baseline deserialize, feature-pack install, templates, paragraph types, Visual Editor, and the customer-center playbook. Use after `dw-demo-base`. **[dw-demo-erp](skills/dw-demo-erp/SKILL.md)** ERP integration demo — DB-staged mock or live BC, Integration Framework rules. Use after `dw-demo-base`. diff --git a/skills/dw-demo-swift/SKILL.md b/skills/dw-demo-swift/SKILL.md index 352f6a8..d4aaeef 100644 --- a/skills/dw-demo-swift/SKILL.md +++ b/skills/dw-demo-swift/SKILL.md @@ -22,11 +22,11 @@ orchestrator abstraction (GSD primary, native command set, and the standalone ha ## Step 0 — Load the Swift baseline (every Swift demo) -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, `Swift2.2` 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. +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 — content-only.** The Swift2.2 vault baseline ships **only `_content/`** — no framework rows (no currencies, no countries, no languages, no shops). Framework data must already exist in the target DB; the area's YAML uses string FKs (`AreaEcomShopId: "SHOP1"`, `AreaEcomCountryCode: "DE"`) that resolve against existing rows. A PIM-set-up host (per `dynamicweb-pim-demo/references/canonical-setup-order.md` Steps 1-4: currencies, countries, languages, manufacturers, SHOP1 with language relation) is the canonical clean target — the deserialize is **naturally additive** and does not conflict with PIM-curated framework rows or product data. See [`references/deserialize-flow.md`](references/deserialize-flow.md) §3 for the full shape contract. +**Baseline shape — full deploy + seed.** The `swift-2.3` vault 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` slot. 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. -1. **Verify framework prerequisites in target DB** — at minimum: `SHOP1` (or whichever ShopId the area's YAML references), `DE` country (or whichever AreaEcomCountryCode), `LANG1` with shop language relation, EUR currency. PIM-skill `canonical-setup-order.md` Steps 1-4 covers this. If you ran the PIM flow already, you're done. +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. 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. @@ -61,6 +61,7 @@ Each reference is an independent file owned end-to-end by a single topic; cross- |---|---| | **Load the Swift baseline content into the host** (POST `/Admin/Api/SerializerDeserialize`; includes the design-package deploy step) | **references/deserialize-flow.md** | | **Verify post-deserialize integrity** (mandatory) | **references/integrity-sweep.md** | +| **Install a feature pack into a demo host** (resolve from the `feature-packs` vault slot, source-drop the `.cs`, copy disk overlays, deserialize the fragment AFTER the base baseline) | **references/pack-activation.md** | | **Start a new demo's frontend** (configuration-only Day-1 workflow) or use the Visual Editor effectively | **references/admin-ui-authoring.md** | | Understand Swift template / page / paragraph conventions; debug Razor pitfalls in custom layouts (`@Html.Raw`, `ProductFieldValues`, raw Razor source rendering on the PDP, role gates by customer-number suffix) | references/templates.md | | **Component-first gate** — map a rendering requirement to a standard `Swift-v2_*` component (catalogue: category banner, subgroup nav, related/similar, specs, BOM) BEFORE customising; pick the right paragraph type for a section; debug "paragraph renders empty / stale after delete" (`RenderGrid` cache, `SelectedGroups` deserialization, alphabetical template fallback) | references/paragraphs.md | diff --git a/skills/dw-demo-swift/references/pack-activation.md b/skills/dw-demo-swift/references/pack-activation.md new file mode 100644 index 0000000..c91bc5f --- /dev/null +++ b/skills/dw-demo-swift/references/pack-activation.md @@ -0,0 +1,199 @@ +# pack-activation.md + +## Contents + +- [1. What a feature pack is](#1-what-a-feature-pack-is) +- [2. Prerequisites](#2-prerequisites) +- [3. Pack zip anatomy](#3-pack-zip-anatomy) +- [4. Step 1 — Resolve and unzip the pack from the vault](#4-step-1--resolve-and-unzip-the-pack-from-the-vault) +- [5. Step 2 — Read pack.json](#5-step-2--read-packjson) +- [6. Step 3 — Source-drop the .cs and build the host](#6-step-3--source-drop-the-cs-and-build-the-host) +- [7. Step 4 — Copy disk overlays](#7-step-4--copy-disk-overlays) +- [8. Step 5 — Deserialize the baseline fragment AFTER the base baseline](#8-step-5--deserialize-the-baseline-fragment-after-the-base-baseline) +- [9. Step 6 — Restart and verify](#9-step-6--restart-and-verify) +- [10. Activation model (why this order)](#10-activation-model-why-this-order) +- [11. Removing a pack](#11-removing-a-pack) + +> Install a feature pack into a demo host that already has the `swift-2.3` baseline deserialized +> (per [`deserialize-flow.md`](deserialize-flow.md)). A pack layers a self-contained capability — +> source code, disk-overlay templates/item types, and a data fragment — onto the base Swift baseline +> **without editing the base**. This is the consumer-side install path; the harness gate automates +> the same steps for validation, but a demo builder can install a pack by hand with the recipe here. +> +> **Scope: Swift demos only.** Run this AFTER the base baseline deserialize, never before. + +## 1. What a feature pack is + +A pack is a released `.zip` under the vault's `feature-packs///` slot. It carries three +kinds of thing, each landing in a different place on the host: + +- **`.cs` source** — compiles INTO the demo host's own build (source-drop, never a separate DLL). +- **Disk overlays** — Razor templates and item-type XML that live on disk under `wwwroot\Files`. +- **A baseline fragment** — serializer YAML (data only, zero custom code) that deserializes ON TOP + of the base baseline, adding the pack's rows and pages. + +A pack never edits base baseline YAML. If a change would require rewriting base content, it is a +baseline improvement, not a pack. + +## 2. Prerequisites + +- A running demo host (`Dynamicweb.Host.Suite`) with the `swift-2.3` baseline already deserialized + and green per [`deserialize-flow.md`](deserialize-flow.md) — the fragment's FK targets (products, + areas, framework rows) must already exist. +- The Serializer installed in the host (same one-time install the deserialize flow depends on). +- A Management API bearer token captured in the current conversation (format `CLAUDE.`; keep it + in conversation state, never write it to a file). +- The `feature-packs` vault slot synced into `$env:DW_VAULT` (landed by the harness vault-sync; see + the vault `INDEX.md` `feature-packs` row). + +## 3. Pack zip anatomy + +The release `.zip` unpacks with everything at the root (no wrapper folder): + +``` +/ # zip root +├── pack.json # manifest — pack identity, modes, ledger, config rows +├── README.md # human notes +├── src/ # .cs source ONLY (no .csproj, no .dll) +│ └── *.cs +├── templates/ # disk-overlay Razor (e.g. Designs/Swift-v2/...; may be empty) +├── itemtypes/ # disk-overlay item-type definitions (may be empty) +└── baseline-fragment/ # serializer YAML fragment — data only + ├── seed/ # present when pack.json fragmentModes contains "seed" + │ ├── seed-manifest.json + │ ├── _sql//.yml + │ └── _content///page.yml # optional page fragment + └── deploy/ # present when fragmentModes contains "deploy" + ├── deploy-manifest.json + ├── _sql/
/.yml + └── _content///page.yml # optional page fragment +``` + +`baseline-fragment/` ships **only** the mode trees named in `pack.json` `fragmentModes`; each mode +tree carries its own hand-authored manifest. A pack that ships no code has an empty `src/`; a pack +that ships no overlays still keeps the `templates/` and `itemtypes/` folders present. + +## 4. Step 1 — Resolve and unzip the pack from the vault + +Resolve the release from the `feature-packs` slot and expand it into a working directory. No hardcoded +literals — the vault root is `$env:DW_VAULT`. + +```powershell +$packName = "reordering-pricing" # the pack you are installing +$packVer = "1.0.0" +$slot = "$env:DW_VAULT\feature-packs\$packName\$packVer" +if (-not (Test-Path "$slot\pack.json")) { + throw "Pack '$packName/$packVer' not found (missing pack.json) at `$slot. Check INDEX.md feature-packs row." +} +# The vault slot already holds the unpacked pack (pack.json at slot root). If you have a release .zip +# instead, expand it first: Expand-Archive -Path .zip -DestinationPath $slot +``` + +## 5. Step 2 — Read pack.json + +`pack.json` is the manifest that drives the install. Read the fields you need before touching the host: + +```powershell +$pack = Get-Content "$slot\pack.json" -Raw | ConvertFrom-Json +$pack.name; $pack.version; $pack.swiftCompatRange # confirm this host's Swift version is in range +$pack.fragmentModes # which mode trees to deserialize (seed / deploy) +$pack.csLedger # every src/*.cs file + how it registers +$pack.configRows # rows that must exist after install (your verify list) +``` + +Confirm the host's Swift version is listed in `swiftCompatRange` — a pack proves the versions it +claims. If your host's version is not in range, stop; the pack is not certified for it. + +## 6. Step 3 — Source-drop the .cs and build the host + +Packs ship **source only**. The `.cs` files compile into the host's own compilation unit via the +SDK-style implicit `**/*.cs` glob. Copy them to the host's `Packs\\` folder, then build. + +```powershell +$hostRoot = "Dynamicweb.Host.Suite" +$dropDir = "$hostRoot\Packs\$packName" +New-Item -ItemType Directory -Path $dropDir -Force | Out-Null +Copy-Item -Recurse "$slot\src\*" "$dropDir\" -Force +# Stop the host BEFORE building — a running host locks its exe/DLLs on Windows. +dotnet build $hostRoot -c Debug +``` + +Drop `.cs` under `Packs\\`, never under `wwwroot\` — the host csproj excludes `wwwroot\Files` +from compilation, so pack code placed there would never build. A pack ships no `.csproj` and no +`.dll`; if you find either in the zip, the pack is malformed — do not install it. + +## 7. Step 4 — Copy disk overlays + +Templates and item types are disk-overlay files. Copy them into the host's `wwwroot\Files` tree so the +Razor resolver and item-type loader find them. + +```powershell +if (Test-Path "$slot\templates") { + Copy-Item -Recurse "$slot\templates\*" "$hostRoot\wwwroot\Files\Templates\" -Force +} +if (Test-Path "$slot\itemtypes") { + Copy-Item -Recurse "$slot\itemtypes\*" "$hostRoot\wwwroot\Files\System\Items\" -Force +} +``` + +Track exactly what you copy — removing the pack later deletes exactly these files. + +## 8. Step 5 — Deserialize the baseline fragment AFTER the base baseline + +The fragment is serializer YAML that lands the pack's data. Stage each mode tree named in +`fragmentModes` into the host's `SerializeRoot`, then POST the deserialize — one POST per mode. + +```powershell +$serializeRoot = "$hostRoot\wwwroot\Files\System\Serializer\SerializeRoot" +foreach ($mode in $pack.fragmentModes) { # e.g. 'seed', or 'deploy','seed' + $modeSrc = "$slot\baseline-fragment\$mode" + if (Test-Path $modeSrc) { + New-Item -ItemType Directory -Path "$serializeRoot\$mode" -Force | Out-Null + Copy-Item -Recurse "$modeSrc\*" "$serializeRoot\$mode\" -Force + $resp = Invoke-RestMethod ` + -Uri "https://localhost:$port/Admin/Api/SerializerDeserialize?mode=$mode" ` + -Method POST -Headers @{ Authorization = "Bearer $token" } -SkipCertificateCheck + } +} +``` + +Keep strict mode on (the default) — the fragment must land cleanly against the base graph. `seed` +mode is destination-wins (existing rows preserved, new rows inserted — the natural additive fragment +mode); `deploy` mode is source-wins (updates matching keys). The fragment's own manifest defines its +predicates, so a fragment only ever touches the rows and pages it ships. + +## 9. Step 6 — Restart and verify + +If the pack ships a NEW orderable product (a fragment `EcomProducts` row), restart the host after the +fragment deserialize — the product-catalog cache is built at startup, so a late-seeded product is not +orderable until the next start. Then confirm the install: + +- **Config rows exist.** For each `pack.json` `configRows` entry, run its `EXISTS` probe (e.g. + `SELECT 1 FROM
WHERE `) and confirm the row is present. +- **Behavior works.** Exercise the pack's frontend path (an anonymous or signed-in GET of the page it + ships) and confirm the declared behavior — a marker file appears, a body pattern renders, or a cart + line carries the pack's price. + +A pack that compiles and whose fragment lands but whose behavior never fires is the composition-failure +case — verify behavior, not just presence. + +## 10. Activation model (why this order) + +The order — source-drop + build, then overlays, then fragment-after-base — follows from how each piece +loads: + +- **Code compiles into the host.** There is no separate pack assembly; the `.cs` becomes part of the + host build. That is why the host must rebuild before the pack's types can run. +- **The fragment is additive and lands last.** Its FK targets (base products, areas, framework rows) + must already exist, so the base baseline deserializes first and the fragment strictly after. The + fragment never rewrites base YAML — it only adds its own keyed rows and pages. +- **Overlays are disk truth.** Templates and item-type XML resolve from disk per request, so they must + be on disk before the frontend renders the pack's pages. + +## 11. Removing a pack + +Removal is the mirror of install, tracked exactly — delete the `.cs` you dropped under `Packs\\`, +delete the overlay files you copied into `wwwroot\Files`, delete the fragment rows keyed by what the +fragment inserted (its `_sql` filenames are the row keys; its `_content` pages key by page unique id), +rebuild the host, and restart. Because the fragment only ever added its own keyed rows, a keyed delete +returns the host to its pre-pack state without touching base content. From cfe6d73b1e20cfaeb9e3b0cf5796e513d1a0c161 Mon Sep 17 00:00:00 2001 From: Justinvolved <64196420+Justinvolved@users.noreply.github.com> Date: Thu, 2 Jul 2026 19:49:18 +0200 Subject: [PATCH 3/4] Fix pack-activation deserialize snippet: bind and guard $port/$token before the loop --- skills/dw-demo-swift/references/pack-activation.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/skills/dw-demo-swift/references/pack-activation.md b/skills/dw-demo-swift/references/pack-activation.md index c91bc5f..16ea201 100644 --- a/skills/dw-demo-swift/references/pack-activation.md +++ b/skills/dw-demo-swift/references/pack-activation.md @@ -144,6 +144,15 @@ The fragment is serializer YAML that lands the pack's data. Stage each mode tree `fragmentModes` into the host's `SerializeRoot`, then POST the deserialize — one POST per mode. ```powershell +# Bind the running host's HTTPS port and a Management API token BEFORE the loop. +# $token is the CLAUDE.hex captured in the current conversation (see §2); $port is +# the port the host is listening on. Guard both so a copy-paste never POSTs to an +# empty URI (`https://localhost:/...`) or sends a bare `Bearer ` header. +$port = 5001 # the running host's HTTPS port +$token = "" # Management API token captured in §2 +if (-not $token -or $token -like '<*') { throw 'Capture a Management API token (CLAUDE.hex) first' } +if (-not $port) { throw 'Set $port to the running host HTTPS port first' } + $serializeRoot = "$hostRoot\wwwroot\Files\System\Serializer\SerializeRoot" foreach ($mode in $pack.fragmentModes) { # e.g. 'seed', or 'deploy','seed' $modeSrc = "$slot\baseline-fragment\$mode" From 5b5f71ccd3b581fca57eb181d4c340edf929791c Mon Sep 17 00:00:00 2001 From: Justinvolved <64196420+Justinvolved@users.noreply.github.com> Date: Fri, 3 Jul 2026 02:39:52 +0200 Subject: [PATCH 4/4] Repoint baseline and feature-pack distribution from vault slots to per-demo downloads Demo builds now download the baseline release and any feature-pack releases from the distribution repo the team designates into the demo's own baselines folder; the Swift design package resolves from a local clone of dynamicweb/Swift. Swept the read-only inspection paths in the companion references, repointed integrity-sweep Check 6 icon recovery at the same Swift clone the deserialize flow copies assets from, and noted in the INDEX template that the serialized-data vault slot is a legacy/local mirror. --- .claude-plugin/marketplace.json | 2 +- CHANGELOG.md | 29 ++++++++-- skills/dw-demo-base/assets/INDEX.md.template | 5 ++ .../dw-demo-pim/references/access-surfaces.md | 4 +- skills/dw-demo-swift/SKILL.md | 4 +- .../references/admin-ui-authoring.md | 2 +- .../references/asset-organisation.md | 2 +- .../references/customer-center.md | 2 +- .../references/deserialize-flow.md | 49 ++++++++++------- .../references/integrity-sweep.md | 12 ++-- .../references/pack-activation.md | 55 +++++++++++-------- skills/dw-demo-swift/references/paragraphs.md | 10 ++-- skills/dw-demo-swift/references/re-skin.md | 2 +- skills/dw-demo-swift/references/templates.md | 10 ++-- 14 files changed, 116 insertions(+), 72 deletions(-) diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index c72f50b..9d9f640 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.4" + "version": "3.8.5" }, "plugins": [ { diff --git a/CHANGELOG.md b/CHANGELOG.md index 93fc009..5bdf1f8 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -3,12 +3,31 @@ All notable changes to the Dynamicweb Skills plugin are recorded here. The `version` field in `.claude-plugin/marketplace.json` tracks these entries. +## [3.8.5] + +### Changed +- **Baseline and feature-pack distribution repointed from personal vault slots to per-demo + downloads.** The `dw-demo-swift` deserialize and pack-activation flows no longer resolve + baselines, packs, or Swift-repo assets from `$env:DW_VAULT` slots. Instead, a demo build + downloads the baseline release (e.g. tag `swift/2.3`) and any pack releases (tag + `packs//`) from the distribution repo the team designates into the demo's own + `baselines\` folder (`\baselines\swift-2.3\`, + `\baselines\feature-packs\\\`), and the Swift design package comes from + a local clone of `https://github.com/dynamicweb/Swift` (`\dw-swift\`). Swept the + read-only inspection paths in the companion references (`templates`, `paragraphs`, + `customer-center`, `asset-organisation`, `admin-ui-authoring`, `re-skin`), repointed + `integrity-sweep.md` Check 6 icon recovery at the same Swift clone the deserialize flow copies + assets from (reproducibility now recorded as baseline name + release tag in the per-demo + `CUSTOMISATIONS.md`), updated the `dw-demo-pim/access-surfaces` baseline row, and noted in the + `dw-demo-base` INDEX template that the `serialized-data` vault slot is a legacy/local mirror. + ## [3.8.4] ### Added - **`dw-demo-swift/references/pack-activation.md` — install a feature pack into a demo host.** A new - consumer-facing reference documenting the L3→demo-host install path: resolve a pack release from the - `feature-packs//` vault slot, read `pack.json`, source-drop the `.cs` into the host's + consumer-facing reference documenting the L3→demo-host install path: download the pack release + (tag `packs//`) from the feature-pack distribution repo into the demo's + `baselines\feature-packs\` folder, read `pack.json`, source-drop the `.cs` into the host's `Packs\\` and rebuild, copy disk-overlay templates/item types, and deserialize the `baseline-fragment` mode trees (seed/deploy) strictly AFTER the base baseline. Documents the confirmed pack zip anatomy (pack.json, src/*.cs, templates/, itemtypes/, baseline-fragment/{seed,deploy}/) and @@ -19,10 +38,10 @@ All notable changes to the Dynamicweb Skills plugin are recorded here. The ## [3.8.3] ### Changed -- **`dw-demo-swift` deserialize-flow repointed off the retired content-only `Swift2.2` slot to the - canonical `swift-2.3` baseline.** The vault's `swift-2.3` slot is a full `config/deploy/seed` +- **`dw-demo-swift` deserialize-flow repointed off the retired content-only `Swift2.2` baselines to + the canonical `swift-2.3` baseline.** The `swift-2.3` baseline is a full `config/deploy/seed` tree (framework `_sql/` + content in `deploy/`, catalog `_sql/` + content in `seed/`), not the - content-only `_content/`-at-root shape the older `Swift2.2` slot used. Repointed the `$baseline` + content-only `_content/`-at-root shape the older `Swift2.2` baselines used. Repointed the `$baseline` default and staging snippet in `dw-demo-swift/references/deserialize-flow.md` to stage both mode trees from `swift-2.3`, rewrote the "baseline shape" and §9 schema-drift notes for the `_sql/`-shipping baseline, and swept baseline-slot source-of-truth paths in the companion diff --git a/skills/dw-demo-base/assets/INDEX.md.template b/skills/dw-demo-base/assets/INDEX.md.template index 31b1871..67d5e65 100644 --- a/skills/dw-demo-base/assets/INDEX.md.template +++ b/skills/dw-demo-base/assets/INDEX.md.template @@ -11,6 +11,11 @@ | `docs` | `$DW_VAULT\docs\` | Curated DW10 docs (custom admin screens guide, middleware deep-dive) | _(N/A -- version-agnostic)_ | _(YYYY-MM-DD)_ | | `serialized-data` | `$DW_VAULT\serialized-data\` | YAML baselines for the DW Serializer deserialize. Each subfolder is one baseline (e.g. generic `swift-2.3/`, plus per-demo customer-flavoured baselines named `-base/` by convention once derived). | _(per-baseline; each subfolder lists its target DW10 version in its own README)_ | _(YYYY-MM-DD)_ | +> **Note (baselines):** demo builds download baselines per-demo into the demo's own `baselines\` +> folder (see `dw-demo-swift/references/deserialize-flow.md`) from the baseline distribution repo +> the team designates. The `serialized-data` slot above is a legacy/local mirror, not the +> resolution path for new demo builds. + ## Resolution rule Every Dynamicweb skill resolves vault content via `$env:DW_VAULT` joined with a slot name from this table. Hardcoded literal-path fallbacks (e.g., `C:\VibeCode\dw-vault\dw10source\`) are documented as bootstrap-only / emergency-only. See `dynamicweb-demo-base/references/setup-checks.md` for the verify-and-fix walkthrough; see `dynamicweb-demo-base/references/compare-vault.md` for cross-machine drift detection. diff --git a/skills/dw-demo-pim/references/access-surfaces.md b/skills/dw-demo-pim/references/access-surfaces.md index e75de6d..cb44a8f 100644 --- a/skills/dw-demo-pim/references/access-surfaces.md +++ b/skills/dw-demo-pim/references/access-surfaces.md @@ -20,11 +20,11 @@ Surface choice is task-driven, not preference-driven. Common shortcuts: bulk sch The Management API admin-endpoint catalog (BuildIndex, IndexStatus, CacheInformationRefresh, GetServiceCaches, FeatureManagementToggle, CompletionSettingsSourceById), the runtime OpenAPI-discovery probe, and the per-project discovery table (host URL/port, SQL Server, DB name, API token) are vendor-generic platform facts — see [`../../dw-demo-base/references/foundational/data-access.md`](../../dw-demo-base/references/foundational/data-access.md). -Two vault-resolved baselines this demo skill leans on (per-project, discovered via `$env:DW_VAULT`): +Two reference sources this demo skill leans on (per-project): | Ref | How to find it in the current project | |---|---| -| Swift baseline (vault) | `$env:DW_VAULT\serialized-data\swift-2.3\` — the canonical swift/2.3 baseline (a `config/deploy/seed` tree). Its serialized index XML is the copy-paste source for `Products.index` definitions. | +| Swift baseline (per-demo download) | `\baselines\swift-2.3\` — the demo's downloaded copy of the canonical swift/2.3 baseline (a `config/deploy/seed` tree, fetched from the baseline distribution repo your team designates). Its serialized index XML is the copy-paste source for `Products.index` definitions. | | DW10 source clone (vault) | `$env:DW_VAULT\dw10source\` — search `src/Features/Ecommerce` for Ecom internals and `Dynamicweb.Products.UI` for admin UI behavior. Otherwise fall back to https://doc.dynamicweb.dev/ | When the user gives you a token, port, or path in chat, treat it as scoped to the project in the current working directory — save it in conversation state, not as a global default. diff --git a/skills/dw-demo-swift/SKILL.md b/skills/dw-demo-swift/SKILL.md index d4aaeef..4d6bdc5 100644 --- a/skills/dw-demo-swift/SKILL.md +++ b/skills/dw-demo-swift/SKILL.md @@ -24,7 +24,7 @@ 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` vault 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` slot. 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; 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. 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. 2. **Verify Serializer is installed** in the host per [`../dw-demo-base/references/serializer-reference.md`](../dw-demo-base/references/serializer-reference.md) "Installation". @@ -61,7 +61,7 @@ Each reference is an independent file owned end-to-end by a single topic; cross- |---|---| | **Load the Swift baseline content into the host** (POST `/Admin/Api/SerializerDeserialize`; includes the design-package deploy step) | **references/deserialize-flow.md** | | **Verify post-deserialize integrity** (mandatory) | **references/integrity-sweep.md** | -| **Install a feature pack into a demo host** (resolve from the `feature-packs` vault slot, source-drop the `.cs`, copy disk overlays, deserialize the fragment AFTER the base baseline) | **references/pack-activation.md** | +| **Install a feature pack into a demo host** (download the pack release into the demo's `baselines\feature-packs\` folder, source-drop the `.cs`, copy disk overlays, deserialize the fragment AFTER the base baseline) | **references/pack-activation.md** | | **Start a new demo's frontend** (configuration-only Day-1 workflow) or use the Visual Editor effectively | **references/admin-ui-authoring.md** | | Understand Swift template / page / paragraph conventions; debug Razor pitfalls in custom layouts (`@Html.Raw`, `ProductFieldValues`, raw Razor source rendering on the PDP, role gates by customer-number suffix) | references/templates.md | | **Component-first gate** — map a rendering requirement to a standard `Swift-v2_*` component (catalogue: category banner, subgroup nav, related/similar, specs, BOM) BEFORE customising; pick the right paragraph type for a section; debug "paragraph renders empty / stale after delete" (`RenderGrid` cache, `SelectedGroups` deserialization, alphabetical template fallback) | references/paragraphs.md | diff --git a/skills/dw-demo-swift/references/admin-ui-authoring.md b/skills/dw-demo-swift/references/admin-ui-authoring.md index 98a5df1..d67aca7 100644 --- a/skills/dw-demo-swift/references/admin-ui-authoring.md +++ b/skills/dw-demo-swift/references/admin-ui-authoring.md @@ -1,6 +1,6 @@ # admin-ui-authoring.md -> Swift 2 admin-UI authoring: the configuration-only Day-1 workflow (get 80% of the brand applied via admin Style tools alone, zero CSS / Razor / .cs edits) plus the Visual Editor patterns for editing paragraph properties without touching code. Operates against a deserialized swift/2.3 baseline (source-of-truth at `$env:DW_VAULT\serialized-data\swift-2.3\`). +> Swift 2 admin-UI authoring: the configuration-only Day-1 workflow (get 80% of the brand applied via admin Style tools alone, zero CSS / Razor / .cs edits) plus the Visual Editor patterns for editing paragraph properties without touching code. Operates against a deserialized swift/2.3 baseline (source-of-truth at `\baselines\swift-2.3\`). > > Swift 2.x guidance — never follow `/swift/swift-1/` URLs (different content model, phased out). diff --git a/skills/dw-demo-swift/references/asset-organisation.md b/skills/dw-demo-swift/references/asset-organisation.md index 0094445..cf6fff6 100644 --- a/skills/dw-demo-swift/references/asset-organisation.md +++ b/skills/dw-demo-swift/references/asset-organisation.md @@ -1,6 +1,6 @@ # asset-organisation.md -> `wwwroot/Files/` asset organisation for a Swift 2.2 / Dynamicweb 10 demo. Reference layouts at `$env:DW_VAULT\serialized-data\swift-2.3\` and Swift v2.3.0 at https://github.com/dynamicweb/Swift. +> `wwwroot/Files/` asset organisation for a Swift 2.2 / Dynamicweb 10 demo. Reference layouts at `\baselines\swift-2.3\` and Swift v2.3.0 at https://github.com/dynamicweb/Swift. > > Swift 2.x guidance — never follow `/swift/swift-1/` URLs (different content model, phased out). diff --git a/skills/dw-demo-swift/references/customer-center.md b/skills/dw-demo-swift/references/customer-center.md index 55e0e76..f98d716 100644 --- a/skills/dw-demo-swift/references/customer-center.md +++ b/skills/dw-demo-swift/references/customer-center.md @@ -26,7 +26,7 @@ Rebuilding is never the right answer. The stock section already supports imperso ## 2. Page-tree map -Source-of-truth: `$env:DW_VAULT\serialized-data\swift-2.3\deploy\_content\Swift 2\Customer center\` deserialized into a running host. Backtick-quote any path string when copying into other tools -- folder names contain spaces. +Source-of-truth: `\baselines\swift-2.3\deploy\_content\Swift 2\Customer center\` deserialized into a running host. Backtick-quote any path string when copying into other tools -- folder names contain spaces. ``` Customer center/ diff --git a/skills/dw-demo-swift/references/deserialize-flow.md b/skills/dw-demo-swift/references/deserialize-flow.md index cd62ce2..9498104 100644 --- a/skills/dw-demo-swift/references/deserialize-flow.md +++ b/skills/dw-demo-swift/references/deserialize-flow.md @@ -5,7 +5,7 @@ - [1. Prerequisites](#1-prerequisites) - [Design-package deploy (before any deserialize)](#design-package-deploy-before-any-deserialize) - [2. Step 0 — Discover project context](#2-step-0--discover-project-context) -- [3. Step 1 — Stage baseline YAML from vault](#3-step-1--stage-baseline-yaml-from-vault) +- [3. Step 1 — Stage baseline YAML from the demo's baselines folder](#3-step-1--stage-baseline-yaml-from-the-demos-baselines-folder) - [4. Step 2 — POST against running host](#4-step-2--post-against-running-host) - [5. Strict-mode contract](#5-strict-mode-contract) - [6. Identity model](#6-identity-model) @@ -13,7 +13,7 @@ - [8. Mandatory next step](#8-mandatory-next-step) - [9. Known schema-drift workaround (Swift 2.3 baseline ↔ DW10)](#9-known-schema-drift-workaround-swift-23-baseline--dw10) -> Deserialize a Swift content baseline from `$env:DW_VAULT\serialized-data\\` into the per-demo project DB. Uses the DW Serializer + Management API. Strict mode is on by default — failures surface as `CumulativeStrictModeException`. Always followed by [`integrity-sweep.md`](integrity-sweep.md). +> Deserialize a Swift content baseline from the demo's own `\baselines\\` folder into the per-demo project DB. Uses the DW Serializer + Management API. Strict mode is on by default — failures surface as `CumulativeStrictModeException`. Always followed by [`integrity-sweep.md`](integrity-sweep.md). > > **Scope: Swift demos only.** PIM demos start from a blank/fresh DB and skip this flow entirely. This file is owned by `dynamicweb-swift-demo`; the underlying Serializer install + background reference live in `dynamicweb-demo-base/references/serializer-reference.md`. @@ -21,7 +21,8 @@ `dynamicweb-demo-base` setup is complete: -- [`../../dw-demo-base/references/setup-checks.md`](../../dw-demo-base/references/setup-checks.md) is green (DW_VAULT, NODE_TLS_REJECT_UNAUTHORIZED, .NET SDK, ProjectTemplates, SQL Express, vault slot inventory all probed and resolved). +- [`../../dw-demo-base/references/setup-checks.md`](../../dw-demo-base/references/setup-checks.md) is green (NODE_TLS_REJECT_UNAUTHORIZED, .NET SDK, ProjectTemplates, SQL Express all probed and resolved). +- The baseline release has been downloaded from the baseline distribution repo your team designates into the demo's own `baselines\` folder (see §3 — the staging snippet downloads it on first run if a distribution repo is configured). - [`../../dw-demo-base/references/scaffold.md`](../../dw-demo-base/references/scaffold.md) produced a running `Dynamicweb.Host.Suite` (port reachable, host responds at `/admin`). - [`../../dw-demo-base/references/mcp-setup.md`](../../dw-demo-base/references/mcp-setup.md) verification gate passed (`claude mcp list` shows `dynamicweb-commerce-mcp ✓ Connected` AND in-conversation `ToolSearch +dynamicweb` returns >200 tools). - **The DW Serializer is installed in the host** per [`../../dw-demo-base/references/serializer-reference.md`](../../dw-demo-base/references/serializer-reference.md) "Installation" section (DLL built + copied to `bin/Debug/net10.0/`, `Files/Serializer.config.json` staged, host restarted). This is a one-time-per-host step. @@ -33,11 +34,11 @@ If any of those are unmet, return to the relevant reference before attempting a The baseline's content predicates reference `Swift-v2_*` item types whose XML definitions ship with the **Swift design package**, NOT with the data baseline. Deploy the design package BEFORE running the deserialize — without the XMLs on disk every page row fails with `Unable to resolve the item type. The item cannot be saved.` (see §9.1). -**Source.** The `dw-swift` vault slot at `$env:DW_VAULT\dw-swift\` (local clone of `https://github.com/dynamicweb/Swift` v2.3.0+; if missing, clone it there). +**Source.** A local clone of `https://github.com/dynamicweb/Swift` (v2.3.0+). Clone it into `\dw-swift\`, or reuse an existing local clone if one is already on the machine. -**Build first.** The repo ships only source SCSS/JS — `Assets/css/` and `Assets/js/` are gitignored. Run `npm install` then `npm run build` in `$env:DW_VAULT\dw-swift\` BEFORE copying assets (`node_modules/` is per-machine and not vault-transferred — rebuild on each machine). Verify post-build: `Files/Templates/Designs/Swift-v2/Assets/css/swift.css` (~340KB) and `Assets/js/swift.js` (~45KB) plus `Assets/lib/` (Bootstrap/htmx/Alpine vendored deps, 200+ JS files) all exist on disk. Skipping the build leaves the storefront unstyled — pages render text-only with broken layout because every Swift template references `/Files/Templates/Designs/Swift-v2/Assets/css/swift.css` which 404s. +**Build first.** The repo ships only source SCSS/JS — `Assets/css/` and `Assets/js/` are gitignored. Run `npm install` then `npm run build` in the Swift clone BEFORE copying assets (`node_modules/` is per-machine — rebuild on each machine). Verify post-build: `Files/Templates/Designs/Swift-v2/Assets/css/swift.css` (~340KB) and `Assets/js/swift.js` (~45KB) plus `Assets/lib/` (Bootstrap/htmx/Alpine vendored deps, 200+ JS files) all exist on disk. Skipping the build leaves the storefront unstyled — pages render text-only with broken layout because every Swift template references `/Files/Templates/Designs/Swift-v2/Assets/css/swift.css` which 404s. -**Copy list.** From `$env:DW_VAULT\dw-swift\` to the host's `wwwroot/`: +**Copy list.** From the Swift clone (`\dw-swift\`) to the host's `wwwroot/`: - `Files/System/Items/*.xml` (the item-type definitions the content predicates need) - `Files/Templates/Designs/Swift-v2/` @@ -85,19 +86,27 @@ Write-Host "Discovered DB: $db" Captured via `AskUserQuestion` in the current conversation. Format: `CLAUDE.`. Keep in conversation state only; never persist. The token is a credential and must not be committed, logged to a file, or echoed into a transcript that survives the session. -## 3. Step 1 — Stage baseline YAML from vault +## 3. Step 1 — Stage baseline YAML from the demo's baselines folder -Vault path resolution: every baseline path resolves through `$env:DW_VAULT` (base's path-resolution rule). No hardcoded literals. +Baseline path resolution: every baseline path resolves under the demo's own `\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. -**Baseline shape — full deploy + seed (swift/2.3).** The canonical `swift-2.3` vault baseline is a full `config/deploy/seed` tree, NOT the content-only shape the older `Swift2.2` slot 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` slot 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 slot'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. 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`.** ```powershell -$baseline = "swift-2.3" # the canonical swift/2.3 slot (see $env:DW_VAULT\INDEX.md serialized-data row); per-demo "-base" baselines live alongside it -$slot = "$env:DW_VAULT\serialized-data\$baseline" +$baseline = "swift-2.3" # the canonical swift/2.3 baseline; per-demo "-base" baselines live alongside it under baselines\ +$demoRoot = (Get-Location).Path # the demo project root +$slot = "$demoRoot\baselines\$baseline" # the demo's own downloaded copy if (-not (Test-Path "$slot\deploy\_content")) { - throw "Baseline '$baseline' not found (or missing deploy\_content\) at `$slot. Check INDEX.md serialized-data row." + # Download the baseline release (e.g. tag swift/2.3) from the baseline distribution + # repo your team designates, then expand it so config/deploy/seed sit at $slot root. + $repo = $env:DW_BASELINE_REPO # set once per machine to the team's baseline distribution repo (owner/name) + if (-not $repo) { throw "Baseline '$baseline' not present at $slot and no distribution repo configured. Download the baseline release into $slot first." } + New-Item -ItemType Directory -Path $slot -Force | Out-Null + gh release download "swift/2.3" --repo $repo --pattern '*.zip' --dir "$demoRoot\baselines" + Expand-Archive -Path "$demoRoot\baselines\*.zip" -DestinationPath $slot -Force + Remove-Item "$demoRoot\baselines\*.zip" } $serializeRoot = "Dynamicweb.Host.Suite/wwwroot/Files/System/Serializer/SerializeRoot" # swift/2.3 is a full deploy + seed baseline: stage BOTH mode trees (each ships _content/ + _sql/). @@ -107,10 +116,10 @@ foreach ($mode in 'deploy','seed') { Copy-Item -Recurse "$slot\$mode\*" "$serializeRoot/$mode/" -Force } } -# Unlike the content-only Swift2.2 slot, swift/2.3 ships framework + catalog `_sql/` in deploy/ and seed/. +# Unlike the content-only Swift2.2 baselines, swift/2.3 ships framework + catalog `_sql/` in deploy/ and seed/. ``` -**Pre-import: re-serialize before merging vault YAML.** If the target host has any pre-existing predicates (e.g. `"Content - "`), POST `/Admin/Api/SerializerSerialize` FIRST so the deploy folder reflects current DB state. Otherwise the deserialize will revert any in-DB changes you made since the last serialize (we hit this in practice: a recent area-rename via API was reverted by re-applying stale YAML for the old area name). After serializing, also delete any folders in `_content/` whose name matches a stale area name — `Serialize` writes the current name's folder but does NOT clean the old one (e.g. `_content//` survives a rename to `_content//`). +**Pre-import: re-serialize before merging baseline YAML.** If the target host has any pre-existing predicates (e.g. `"Content - "`), POST `/Admin/Api/SerializerSerialize` FIRST so the deploy folder reflects current DB state. Otherwise the deserialize will revert any in-DB changes you made since the last serialize (we hit this in practice: a recent area-rename via API was reverted by re-applying stale YAML for the old area name). After serializing, also delete any folders in `_content/` whose name matches a stale area name — `Serialize` writes the current name's folder but does NOT clean the old one (e.g. `_content//` survives a rename to `_content//`). **Predicate config: each `_content//` folder needs a matching predicate.** Add a content predicate to `Files/Serializer.config.json` per area you want imported: ```json @@ -131,9 +140,9 @@ foreach ($mode in 'deploy','seed') { **Strategy note (verified during a Swift2 baseline import):** Two strategies were considered — - **(a)** Copy YAML directly into `Dynamicweb.Host.Suite/wwwroot/Files/System/Serializer/SerializeRoot/deploy/` (this snippet — verified working). -- **(b)** Configure `Files/Serializer.config.json` `outputDirectory` to point at `$env:DW_VAULT\serialized-data\\` directly. Faster (no copy), but the running host's serialize would also write back into the vault — destination contamination risk. Not recommended; (a) is the canonical approach. +- **(b)** Configure `Files/Serializer.config.json` `outputDirectory` to point at `\baselines\\` directly. Faster (no copy), but the running host's serialize would also write back into the downloaded baseline copy — contaminating your pristine reference of what the release shipped. Not recommended; (a) is the canonical approach. -**Single canonical swift/2.3 path:** `$baseline = "swift-2.3"` resolves to `$env:DW_VAULT\serialized-data\swift-2.3\` — the single canonical generic baseline (a `config/deploy/seed` tree). Per-demo customer-flavoured baselines (named `-base/` by convention) live alongside `swift-2.3/` in the same `serialized-data/` slot once they have been derived; both share this flow. The retired content-only `Swift2.2/` slot remains in the vault for legacy demos but is no longer the default. +**Single canonical swift/2.3 path:** `$baseline = "swift-2.3"` resolves to `\baselines\swift-2.3\` — the single canonical generic baseline (a `config/deploy/seed` tree). Per-demo customer-flavoured baselines (named `-base/` by convention) live alongside `swift-2.3/` under the same `baselines\` folder once they have been derived; both share this flow. Legacy content-only `Swift2.2` baselines predate this model and are no longer the default. ## 4. Step 2 — POST against running host @@ -149,7 +158,7 @@ $resp = Invoke-RestMethod ` **Keep strict mode on; never disable it** by passing a `strictMode` query parameter or body field set to a falsy value. Strict mode is the first line of defence (FK orphans, missing templates, cache failures, schema drift). Disabling it produces a deserialized DB that *looks* succeeded but is silently inconsistent — the deserialize-blind failure mode in its purest form. -If the POST returns 4xx with a `CumulativeStrictModeException` body, the body itself is the diagnostic. Read the listed FK orphans / missing templates / schema drift entries; the fix is almost always upstream (the baseline YAML), not on the host. Cross-check `$env:DW_VAULT\INDEX.md`'s `serialized-data` row version stamp to confirm the baseline version matches the host's DW10 version (the baseline-drift self-diagnosis rule). +If the POST returns 4xx with a `CumulativeStrictModeException` body, the body itself is the diagnostic. Read the listed FK orphans / missing templates / schema drift entries; the fix is almost always upstream (the baseline YAML), not on the host. Cross-check the downloaded baseline's release tag/version against the host's DW10 version (the baseline-drift self-diagnosis rule). ## 5. Strict-mode contract @@ -189,7 +198,7 @@ The sweep is the second line of defence for the failures strict mode does not ca ## 9. Known schema-drift workaround (Swift 2.3 baseline ↔ DW10) -The `swift-2.3` baseline ships framework + catalog `_sql/` in its `deploy/` and `seed/` trees (unlike the content-only `Swift2.2` slot). Re-verify the former `_sql/`-era drift points against a host when adopting swift/2.3 — the two workarounds below were retired under the content-only shape and may re-apply now that `_sql/` ships again. +The `swift-2.3` baseline ships framework + catalog `_sql/` in its `deploy/` and `seed/` trees (unlike the content-only `Swift2.2` baselines). Re-verify the former `_sql/`-era drift points against a host when adopting swift/2.3 — the two workarounds below were retired under the content-only shape and may re-apply now that `_sql/` ships again. Superseded (content-only era): the `EcomCurrencies.CurrencyUseCurrencyCodeForFormat` column-strip and the `EcomShopGroupRelation/GROUP253$$SHOP19.yml` orphan-YAML workarounds were retired when the baseline dropped `_sql/`. With swift/2.3 shipping `_sql/` again, confirm during a host deserialize whether either recurs; reconstruct specifics from git history if needed. @@ -199,13 +208,13 @@ The baseline's `Content - Swift 2 (...)` predicates reference item types like `S Superseded: deploy-design-first is the only viable path — the former Approach A ("strip Content predicates") no longer applies with a content-only baseline, and running with strict mode off remains forbidden per §4. -### 9.2 — Verified clean outcome (legacy content-only Swift2.2 slot) +### 9.2 — Verified clean outcome (legacy content-only Swift2.2 baseline) For a content-only baseline against a PIM-set-up host (SHOP1 + DE + EUR + LANG1 already present), the deserialize POST returns **HTTP 200 with 0 failed predicates**. Counts will be in the shape: ~640 content rows created/updated (one Area row "Swift 2", ~50 Pages, ~150 grid-rows, ~440 paragraphs — exact numbers depend on baseline version), 0 framework rows touched. Verify post-deserialize: - `SELECT COUNT(*) FROM Areas` → +1 (the new "Swift 2" area) - `SELECT COUNT(*) FROM Page` → ~+50 - Existing PIM data (products, manufacturers, catalog groups, data models, custom field values, EcomDetails image/asset rows) → **untouched** -Note (swift/2.3): unlike the content-only `Swift2.2` slot described in this §9.2, the `swift-2.3` baseline legitimately touches framework rows (`EcomShops`, `EcomCurrencies`, `EcomCountries`, …) via its `deploy/_sql/` pass and catalog rows via `seed/_sql/` — that is expected, not a reversion. The counts above characterise the legacy content-only outcome; capture the swift/2.3 deploy+seed counts from a host run and record them here once verified. +Note (swift/2.3): unlike the content-only `Swift2.2` baseline described in this §9.2, the `swift-2.3` baseline legitimately touches framework rows (`EcomShops`, `EcomCurrencies`, `EcomCountries`, …) via its `deploy/_sql/` pass and catalog rows via `seed/_sql/` — that is expected, not a reversion. The counts above characterise the legacy content-only outcome; capture the swift/2.3 deploy+seed counts from a host run and record them here once verified. diff --git a/skills/dw-demo-swift/references/integrity-sweep.md b/skills/dw-demo-swift/references/integrity-sweep.md index 920746b..9f72013 100644 --- a/skills/dw-demo-swift/references/integrity-sweep.md +++ b/skills/dw-demo-swift/references/integrity-sweep.md @@ -214,21 +214,21 @@ $missing = $probe | Where-Object { -not (Test-Path (Join-Path $iconRoot $_)) } if ($missing) { Write-Host "Missing icons under $iconRoot :" $missing | ForEach-Object { Write-Host " $_" } - throw "Icon set incomplete. Copy from $env:DW_VAULT\\Dynamicweb.Host.Suite\wwwroot\Files\Images\Icons\ before declaring deserialize complete." + throw "Icon set incomplete. Copy from the local Swift clone's Files\Images\Icons\ (e.g. \dw-swift\Files\Images\Icons\) before declaring deserialize complete." } ``` -**Recovery if Check 6 fails:** Copy the entire icon directory from a known-good Swift baseline. The vault's Swift baseline carries the canonical set (~80 files including `Flags/` and `LoginProviders/` subdirs): +**Recovery if Check 6 fails:** Copy the entire icon directory from the local Swift repo clone — the SAME clone [`deserialize-flow.md`](deserialize-flow.md) §"Design-package deploy" copies templates and styles from (`\dw-swift\`, a clone of `https://github.com/dynamicweb/Swift`). It carries the canonical set (~80 files including `Flags/` and `LoginProviders/` subdirs): ```powershell -$src = "$env:DW_VAULT\\Dynamicweb.Host.Suite\wwwroot\Files\Images\Icons" +$src = "\dw-swift\Files\Images\Icons" $dst = "Dynamicweb.Host.Suite\wwwroot\Files\Images\Icons" Copy-Item -Path $src -Destination $dst -Recurse -Force ``` -Substitute `` for whatever the vault's `INDEX.md` names as the Swift baseline slot for this project (e.g. `swift-2.3`). No host restart required — `ReadFile` reads on every render. +No host restart required — `ReadFile` reads on every render. -**Pitfall:** if the deserialize used a non-Swift baseline (e.g. a customer-flavoured baseline with a curated icon subset), do NOT blanket-copy from the generic Swift slot — start from the baseline-flavoured slot and merge in any missing files individually. Audit the result with `git status` so the demo's `CUSTOMISATIONS.md` can record the asset-source provenance. +**Pitfall:** if the deserialize used a non-Swift baseline (e.g. a customer-flavoured baseline with a curated icon subset), do NOT blanket-copy the generic Swift icon set — start from the baseline's own asset set and merge in any missing files individually. Audit the result with `git status` so the demo's `CUSTOMISATIONS.md` can record the asset-source provenance. ## Check 7: Raw SQL in paragraph templates (DW10 discipline) @@ -268,6 +268,6 @@ pack covers URL substring scans, hard-coded slugs, category-name branching, mast When all seven checks pass, deserialize is verified complete. The skill may now declare "baseline restored" to the user. -Log the result + baseline name + timestamp in the per-demo `CUSTOMISATIONS.md` as a deserialize event row. This is structural — every deserialize is reproducible by re-running this flow against the same baseline plus the vault commit recorded in `$env:DW_VAULT\INDEX.md`'s `serialized-data` row. +Log the result + baseline name + timestamp in the per-demo `CUSTOMISATIONS.md` as a deserialize event row, and record the baseline's release tag/commit there too. This is structural — every deserialize is reproducible by re-running this flow against the same baseline name + release tag recorded in `CUSTOMISATIONS.md`. diff --git a/skills/dw-demo-swift/references/pack-activation.md b/skills/dw-demo-swift/references/pack-activation.md index 16ea201..80e1a62 100644 --- a/skills/dw-demo-swift/references/pack-activation.md +++ b/skills/dw-demo-swift/references/pack-activation.md @@ -5,7 +5,7 @@ - [1. What a feature pack is](#1-what-a-feature-pack-is) - [2. Prerequisites](#2-prerequisites) - [3. Pack zip anatomy](#3-pack-zip-anatomy) -- [4. Step 1 — Resolve and unzip the pack from the vault](#4-step-1--resolve-and-unzip-the-pack-from-the-vault) +- [4. Step 1 — Download and unzip the pack release](#4-step-1--download-and-unzip-the-pack-release) - [5. Step 2 — Read pack.json](#5-step-2--read-packjson) - [6. Step 3 — Source-drop the .cs and build the host](#6-step-3--source-drop-the-cs-and-build-the-host) - [7. Step 4 — Copy disk overlays](#7-step-4--copy-disk-overlays) @@ -17,15 +17,16 @@ > Install a feature pack into a demo host that already has the `swift-2.3` baseline deserialized > (per [`deserialize-flow.md`](deserialize-flow.md)). A pack layers a self-contained capability — > source code, disk-overlay templates/item types, and a data fragment — onto the base Swift baseline -> **without editing the base**. This is the consumer-side install path; the harness gate automates -> the same steps for validation, but a demo builder can install a pack by hand with the recipe here. +> **without editing the base**. This is the consumer-side install path; the pack publisher's +> automated validation gate runs the same steps before a release ships, but a demo builder can +> install a pack by hand with the recipe here. > > **Scope: Swift demos only.** Run this AFTER the base baseline deserialize, never before. ## 1. What a feature pack is -A pack is a released `.zip` under the vault's `feature-packs///` slot. It carries three -kinds of thing, each landing in a different place on the host: +A pack is a released `.zip` (release tag `packs//`) from the feature-pack distribution +repo your team designates. It carries three kinds of thing, each landing in a different place on the host: - **`.cs` source** — compiles INTO the demo host's own build (source-drop, never a separate DLL). - **Disk overlays** — Razor templates and item-type XML that live on disk under `wwwroot\Files`. @@ -43,8 +44,9 @@ baseline improvement, not a pack. - The Serializer installed in the host (same one-time install the deserialize flow depends on). - A Management API bearer token captured in the current conversation (format `CLAUDE.`; keep it in conversation state, never write it to a file). -- The `feature-packs` vault slot synced into `$env:DW_VAULT` (landed by the harness vault-sync; see - the vault `INDEX.md` `feature-packs` row). +- The pack release downloaded from the feature-pack distribution repo your team designates and + unpacked into the demo's own `baselines\feature-packs\\\` folder, `pack.json` at the + folder root — see §4, which downloads it on first run. ## 3. Pack zip anatomy @@ -73,20 +75,29 @@ The release `.zip` unpacks with everything at the root (no wrapper folder): tree carries its own hand-authored manifest. A pack that ships no code has an empty `src/`; a pack that ships no overlays still keeps the `templates/` and `itemtypes/` folders present. -## 4. Step 1 — Resolve and unzip the pack from the vault +## 4. Step 1 — Download and unzip the pack release -Resolve the release from the `feature-packs` slot and expand it into a working directory. No hardcoded -literals — the vault root is `$env:DW_VAULT`. +Download the pack's release `.zip` from the feature-pack distribution repo your team designates and +expand it into the demo's own `baselines\feature-packs\` folder. No hardcoded machine-wide literals — +everything lands under the demo root. ```powershell $packName = "reordering-pricing" # the pack you are installing $packVer = "1.0.0" -$slot = "$env:DW_VAULT\feature-packs\$packName\$packVer" -if (-not (Test-Path "$slot\pack.json")) { - throw "Pack '$packName/$packVer' not found (missing pack.json) at `$slot. Check INDEX.md feature-packs row." +$demoRoot = (Get-Location).Path # the demo project root +$packDir = "$demoRoot\baselines\feature-packs\$packName\$packVer" +if (-not (Test-Path "$packDir\pack.json")) { + # Download the pack release (tag packs//) from the feature-pack + # distribution repo your team designates, then unzip so pack.json sits at the folder root. + $repo = $env:DW_PACKS_REPO # set once per machine to the team's feature-pack distribution repo (owner/name) + if (-not $repo) { throw "Pack '$packName/$packVer' not present at $packDir and no distribution repo configured. Download the pack release into $packDir first." } + New-Item -ItemType Directory -Path $packDir -Force | Out-Null + gh release download "packs/$packName/$packVer" --repo $repo --pattern '*.zip' --dir $packDir + Expand-Archive -Path "$packDir\*.zip" -DestinationPath $packDir -Force + Remove-Item "$packDir\*.zip" } -# The vault slot already holds the unpacked pack (pack.json at slot root). If you have a release .zip -# instead, expand it first: Expand-Archive -Path .zip -DestinationPath $slot +# If you were handed a release .zip directly instead, expand it the same way: +# Expand-Archive -Path .zip -DestinationPath $packDir ``` ## 5. Step 2 — Read pack.json @@ -94,7 +105,7 @@ if (-not (Test-Path "$slot\pack.json")) { `pack.json` is the manifest that drives the install. Read the fields you need before touching the host: ```powershell -$pack = Get-Content "$slot\pack.json" -Raw | ConvertFrom-Json +$pack = Get-Content "$packDir\pack.json" -Raw | ConvertFrom-Json $pack.name; $pack.version; $pack.swiftCompatRange # confirm this host's Swift version is in range $pack.fragmentModes # which mode trees to deserialize (seed / deploy) $pack.csLedger # every src/*.cs file + how it registers @@ -113,7 +124,7 @@ SDK-style implicit `**/*.cs` glob. Copy them to the host's `Packs\\` folde $hostRoot = "Dynamicweb.Host.Suite" $dropDir = "$hostRoot\Packs\$packName" New-Item -ItemType Directory -Path $dropDir -Force | Out-Null -Copy-Item -Recurse "$slot\src\*" "$dropDir\" -Force +Copy-Item -Recurse "$packDir\src\*" "$dropDir\" -Force # Stop the host BEFORE building — a running host locks its exe/DLLs on Windows. dotnet build $hostRoot -c Debug ``` @@ -128,11 +139,11 @@ Templates and item types are disk-overlay files. Copy them into the host's `wwwr Razor resolver and item-type loader find them. ```powershell -if (Test-Path "$slot\templates") { - Copy-Item -Recurse "$slot\templates\*" "$hostRoot\wwwroot\Files\Templates\" -Force +if (Test-Path "$packDir\templates") { + Copy-Item -Recurse "$packDir\templates\*" "$hostRoot\wwwroot\Files\Templates\" -Force } -if (Test-Path "$slot\itemtypes") { - Copy-Item -Recurse "$slot\itemtypes\*" "$hostRoot\wwwroot\Files\System\Items\" -Force +if (Test-Path "$packDir\itemtypes") { + Copy-Item -Recurse "$packDir\itemtypes\*" "$hostRoot\wwwroot\Files\System\Items\" -Force } ``` @@ -155,7 +166,7 @@ if (-not $port) { throw 'Set $port to the running host HTTPS port first' } $serializeRoot = "$hostRoot\wwwroot\Files\System\Serializer\SerializeRoot" foreach ($mode in $pack.fragmentModes) { # e.g. 'seed', or 'deploy','seed' - $modeSrc = "$slot\baseline-fragment\$mode" + $modeSrc = "$packDir\baseline-fragment\$mode" if (Test-Path $modeSrc) { New-Item -ItemType Directory -Path "$serializeRoot\$mode" -Force | Out-Null Copy-Item -Recurse "$modeSrc\*" "$serializeRoot\$mode\" -Force diff --git a/skills/dw-demo-swift/references/paragraphs.md b/skills/dw-demo-swift/references/paragraphs.md index 9e49691..4125be8 100644 --- a/skills/dw-demo-swift/references/paragraphs.md +++ b/skills/dw-demo-swift/references/paragraphs.md @@ -1,6 +1,6 @@ # paragraphs.md -> Swift 2.2 paragraph guardrails for demos. Source-of-truth: paragraphs are exposed in admin UI under each page; backing definitions live in `wwwroot/Files/Templates/Paragraph/` (built-in — read-only) and the page-preset YAML at `$env:DW_VAULT\serialized-data\swift-2.3\deploy\_content\Swift 2\\\\paragraph-*.yml`. +> Swift 2.2 paragraph guardrails for demos. Source-of-truth: paragraphs are exposed in admin UI under each page; backing definitions live in `wwwroot/Files/Templates/Paragraph/` (built-in — read-only) and the page-preset YAML at `\baselines\swift-2.3\deploy\_content\Swift 2\\\\paragraph-*.yml`. > > Swift 2.x guidance — never follow `/swift/swift-1/` URLs (different content model, phased out). @@ -16,14 +16,14 @@ here is the demo guardrail: the paragraph types you must NOT replace. | ProductHeader **ProductViewModel field inventory** (`ManufacturerName` not `Manufacturer.Name`; what's available vs what only looks like it is) | [`render-viewmodels.md`](../../dw-demo-base/references/foundational/render-viewmodels.md) | | SQL-direct Paragraph INSERT required columns | [`sql-direct-seeding.md`](sql-direct-seeding.md) | -## Where to find a paragraph's wiring (read-only vault inspection) +## Where to find a paragraph's wiring (read-only baseline inspection) To trace what a specific paragraph does on a Swift 2.2 page: note the page in admin (e.g. `Customer center/CSR/Orders`); the corresponding YAML lives at -`$env:DW_VAULT\serialized-data\swift-2.3\deploy\_content\Swift 2\Customer center\CSR\Orders\grid-row-1\paragraph-c1-1.yml`; +`\baselines\swift-2.3\deploy\_content\Swift 2\Customer center\CSR\Orders\grid-row-1\paragraph-c1-1.yml`; the YAML's `Type` field names the paragraph definition and the rest carries its configured properties. -This is read-only inspection — you don't edit the vault YAML; you edit paragraph properties via the -Admin UI Visual Editor on the live host (which writes to the host's project DB, not back to the vault). +This is read-only inspection — you don't edit the downloaded baseline YAML; you edit paragraph properties via the +Admin UI Visual Editor on the live host (which writes to the host's project DB, not back to the baseline copy). ## "Don't customise this paragraph" callouts diff --git a/skills/dw-demo-swift/references/re-skin.md b/skills/dw-demo-swift/references/re-skin.md index 0a2d4d4..bff573a 100644 --- a/skills/dw-demo-swift/references/re-skin.md +++ b/skills/dw-demo-swift/references/re-skin.md @@ -58,7 +58,7 @@ Fix: define a `_` custom item type — see [`content-modell ## Recipe -Operates on a deserialized swift/2.3 baseline at `$env:DW_VAULT\serialized-data\swift-2.3\` (resolved into a running host via this skill's [`deserialize-flow.md`](deserialize-flow.md)). All steps are admin UI only. Throughout: `` is the demo customer's short slug (lowercase, no spaces). +Operates on a deserialized swift/2.3 baseline at `\baselines\swift-2.3\` (resolved into a running host via this skill's [`deserialize-flow.md`](deserialize-flow.md)). All steps are admin UI only. Throughout: `` is the demo customer's short slug (lowercase, no spaces). ### 1. Logo diff --git a/skills/dw-demo-swift/references/templates.md b/skills/dw-demo-swift/references/templates.md index d5585a9..9f24adc 100644 --- a/skills/dw-demo-swift/references/templates.md +++ b/skills/dw-demo-swift/references/templates.md @@ -1,6 +1,6 @@ # templates.md -> Swift template / page-preset routing. Source-of-truth: `$env:DW_VAULT\serialized-data\swift-2.3\deploy\_content\Swift 2\` deserialized into a running host. Reference Swift v2.3.0 templates at https://github.com/dynamicweb/Swift (requires DW 10.24.6+). +> Swift template / page-preset routing. Source-of-truth: `\baselines\swift-2.3\deploy\_content\Swift 2\` deserialized into a running host. Reference Swift v2.3.0 templates at https://github.com/dynamicweb/Swift (requires DW 10.24.6+). > > Swift 2.x guidance — never follow `/swift/swift-1/` URLs (different content model, phased out). @@ -9,7 +9,7 @@ live here has been folded up into the foundational candidates; the demo skill po | If you need… | Read | |---|---| -| Template categories (vault baseline), page presets (the Theme primitive), and the **page-state flags** (`published` / `hidden` / `active` = "Hidden in Menu" semantics; the `publish_pages` both-flags gotcha) | [`swift-building.md`](../../dw-demo-base/references/foundational/swift-building.md) §6 | +| Template categories (baseline), page presets (the Theme primitive), and the **page-state flags** (`published` / `hidden` / `active` = "Hidden in Menu" semantics; the `publish_pages` both-flags gotcha) | [`swift-building.md`](../../dw-demo-base/references/foundational/swift-building.md) §6 | | `ViewModelTemplate<>` Razor pitfalls — `@Html.Raw()` absent, `product.ProductFieldValues` not on `ProductViewModel` (raw-source-renders-on-PDP), `ToggleFavorite.cshtml` no-op at `FavoriteListId=0` | [`render-razor.md`](../../dw-demo-base/references/foundational/render-razor.md) §2 | | Customer-number-suffix-as-role-flag (`CUST-…-BROWSE` read off `Pageview.User.CustomerNumber` to hide price / gate a storefront affordance) | [`users-permissions.md`](../../dw-demo-base/references/foundational/users-permissions.md) §16 | | SQL-direct Page/GridRow/Paragraph required columns (the `PageActiveFrom`/`PageActiveTo` silent-404 vector et al.) | [`sql-direct-seeding.md`](sql-direct-seeding.md) → [`data-access.md`](../../dw-demo-base/references/foundational/data-access.md) | @@ -18,9 +18,9 @@ live here has been folded up into the foundational candidates; the demo skill po ## Swift v2.3.0 templates + swift/2.3 baseline Target **Swift v2.3.0 templates** at the GitHub repo alongside the **swift/2.3 baseline data** at -`$env:DW_VAULT\serialized-data\swift-2.3\` (a `config/deploy/seed` tree; content lives under +`\baselines\swift-2.3\` (a `config/deploy/seed` tree; content lives under `deploy\_content\` + `seed\_content\`). The 2.3.0 release headlines (language selector + improved -off-canvas nav) match this baseline. The legacy content-only `Swift2.2\` slot remains in the vault -for older demos but is no longer the default. +off-canvas nav) match this baseline. Legacy content-only Swift2.2 baselines predate this model and +are no longer the default. Reference: https://github.com/dynamicweb/Swift/releases/tag/v2.3.0