6.1.0

• dw-demo-base gains a scripted local base build: one command scaffolds a running, unbranded Swift 2 base from
  the public release bacpac. scripts/Invoke-DwDemoBaseBuild.ps1, driven by a customer JSON that needs only a slug
  and a name, runs resumable gated steps: preflight (with the template, sqlpackage and dev-certificate cheap fixes),
  Distribution release resolution with the bacpac SHA256 checked against layers/INDEX.json, a net10 Suite-only
  scaffold pinned to the gate-proven platform, restore with first-login credential repair, the verified Swift
  release Files and ordered edition overlays with the public MCP app staged in AddIns (never a PackageReference),
  access keys, start and trial licence, access proof (more than 200 MCP tools before the key is written to
  .mcp.json), index rebuild, acceptance and provenance stamps. Environment SQL authentication and the
  container-host opt-in are supported. Reference: references/scripted-base-build.md.
• The command applies no branding. Palette, typography and button Style pairs, logo and icons, storefront
  copy, persona and catalogue renames are the next agent step on the running base, with dw-demo-swift and its
  brand guidance as they stand. A config carrying a brand, storefront, personas or catalogue block is
  refused with that pointer; the build report, console summary and CUSTOMISATIONS.md stamp say branded: false
  and name the step. Acceptance checks the unbranded base: readiness, critical pages, three persona identities,
  the edition's default Style sheets linked and served, named PLP products and resolving images.
• API and MCP keys are minted over SQL before the first start (New-DwDemoAccessKeys.ps1), because MCP 0.6.3
  never reveals a created key: AccessUserTokenHash is the prefix plus lowercase hex SHA-512 of <secret>DwSecret,
  and a full-access McpConfiguration bound through McpConfigurationCredential must exist at startup.
  references/mcp-setup.md records the version boundary.

6.0.0

• dw-swift-migrate-site replaces dw-swift-migrate-content as the master site migration. One flow moves any
  website or webshop into a Swift 2 site: content pages, and when in scope the product catalog as a PIM data model
  with imported products. It opens with an intake that asks, in one message, only what the request leaves open
  (source URL, new or existing website, content and/or catalog, language, currency and VAT, permission to copy, and
  for a catalog where the API key file is), takes the connected solution, a subset-first scope and six review rounds
  as stated defaults, and starts the survey at once when the request answered everything. Then seven steps, each
  ending at a checkpoint of one of two kinds: a decision the agent waits on (the scope, the data model, the website
  proposal) or a report it posts and continues past, unless the report shows a problem or the user asked to review
  every step: survey, scrape, data model, Data Integration import, content rebuild, catalog tuning,
  and a screenshot-scored critic review loop, with RUN-STATE.md so a run resumes in a new session. The content
  rebuild of the retired skill (extract_site_content, the per-page layout plan, build_pages) lives on as
  references/content-rebuild.md, with two safety rules: the site extraction and media import run only when the
  source's owner accepts their load (both read 6 requests at a time and skip robots.txt), and a product import
  first checks that no existing product shares a source product number, because the Ecom provider would update it.
  Group membership is imported through the product file's Groups/PrimaryGroup columns.
  dw-swift-migrate-site is dynamo: false (it needs a shell, the dw CLI and a browser), so the manifest no longer carries a site migration skill. The skill is self-contained: it links to no
  other skill, carries the page create order, the dw CLI upload rules, the Data Integration activity rules and the
  facet field rule itself, and describes steps in plain language, naming MCP tools only where a call has a trap
  (the restricted migration tool family and the page create order). Registered in dynamicweb-frontend and
  dynamicweb-commerce; routing in dw-swift-migrate-v1, dw-swift-page-design, dw-swift-building,
  dw-demo-swift and dw-demo-base now points at it.

5.8.13

• Variant prices: the master's variant-less row is the conflict, not a lost price. Combine as variants
  moves the absorbed products' price rows onto the master, scoped to each combination; a variant shows the
  master price because a variant-less row applies to every variant and the lowest wins. Priority is not the
  fix: keep no variant-less row below a variant's price. dw-pim-modelling structural-model.md,
  dw-data-access recipes-pim.md.
• Variant rows are writable from MCP 0.6.3-BETA. patch_products_safe with variantId writes fields
  that allow variant editing and refuses the others; the "no API writes a variant row" finding is now
  scoped to older MCP versions. Same files.
• dw-pim-modelling: a sparse variant matrix strands the shopper. Swift's selector crosses out
  missing combinations and cannot jump to an existing one; keep families to options that combine fully.
• dw-search-indexing index-management.md: gate a product build on a moved lastBuildStarted, and
  purge deleted pages before rebuilding the Content index, which otherwise keeps indexing them.
• dw-swift-page-blocks: the site container width is the Master field MediaQueryLimit; SearchField
  on a dark scheme is invisible; ProductComponentSlider has no title and an empty slider strands its heading.
• dw-extend-mcp-tools tool-surface-gaps.md: delete_variant_combinations leaves the combination's
  price rows behind.

5.8.12

• Combine as variants: the empty master number is by design; the completion-rule gap is work item 29782.
  Dynamicweb support (2026-10-14, dynamicweb/DynamicWeb#735): the master's source product is copied onto a
  variant of its own, so the master keeps no number. With Number master-only the variants share the master's
  number, so make Number editable on variants before combining when they need their own. A completion rule
  that lists ProductNumber still cannot pass on a master with variants until work item 29782 ships; keep it
  out. dw-pim-completeness SKILL.md and rules-and-dashboards.md, dw-pim-modelling structural-model.md.

5.8.11

• dw-swift-page-design + dw-swift-page-blocks: on-topic imagery or none. Use only images whose
  subject fits the section; the site's own brand or product photos are off-topic when the page is about
  something else. When nothing fits, leave the slot empty, compose the section from image-free components
  (Feature/icon rows, Text in banded rows), and tell the user which sections need images. Replaces
  "assign a real image to every slot, never leave one blank", which forced unrelated photos onto pages.
• dw-swift-page-design: a per-write approval is the confirmation. When the client gates each write
  behind its own approval step, put the plan in the reply and proceed; do not stop to ask for a go-ahead
  or placement.
• dw-swift-page-design Mode A: "based on page Y" reconstructs. It builds a new page with Y's section
  rhythm and never edits or removes anything on Y; copy_page is only for an explicit duplicate.

5.8.10

• dw-commerce-catalog catalog-publishing.md: three feed Template-provider context traps. The
  Dynamicweb.Ecommerce.Context:LanguageID macro in a feed query resolves the default language while option
  names render in the feed language; a NULL Double custom field reaches the template as 0; the feed
  context currency reads USD for a EUR feed. Take language, emptiness and currency from the product data.
• dw-integration-framework Rules: the full-path source rule covers the CSV provider too, which reads
  nothing with the folder and file split. get_integration_activity_logs answers "No run log found" for an
  activity inside a group, and get_scheduled_tasks lists no sub-tasks.
• dw-extend-scheduled-tasks scheduler-rows-and-runs.md: reading sub-tasks. get_scheduled_tasks
  lists only the parent level; read the whole tree from ScheduledTask on a local install.

5.8.9

• dw-demo-pim screen-authoring.md: one layout, one tab per product type. A tab whose editors the
  product lacks is not rendered, so one ProductEditScreen layout with a tab per category shows each
  product type its own tab. Unplaced editors go to the IsCatchAll group and vanish silently without one;
  group names must be unique across the layout. Saves renumber Order, ScreenLayoutDelete cascades,
  writes apply on the next load.
• dw-demo-pim screen-authoring.md: query list presets render headers but blank cells. Row data comes
  from the user's own default ProductListScreen preset, not the query's ListScreenViewPresetId; give each
  worklist user a default list preset covering every query column (platform defect, DW 10.29.6).
• Translation worklist that opens side by side. Query edit-screen languages plus Open product in edit
  mode open Multi Edit; the hidden ProductQueryListWidget is added by system name and has product-aware
  rows. Recipe in dw-demo-pim localization.md, widget row in dw-pim-completeness rules-and-dashboards.md.

5.8.8

• dw-pim-completeness: per-language completeness works with the "Completeness feature" flag on.
  The "no per-language dimension" claim is scoped to the flag-off path. Measured on DW 10.29.6, the flag-on
  index builder writes CompletionRule|<id> per index document, scored in that document's language, and a
  LanguageID + empty VariantID + CompletionRule|<id> < 100 query lists one language's gaps. Recipe,
  copy-fields-only rule, and the admin per-language badge are in rules-and-dashboards.md; the "buggy beta"
  warning is narrowed to DW 10.28. dw-pim-localization and dw-users-permissions follow.
• dw-pim-completeness: what calculate_product_completeness_for_products returns. A family-aggregate
  value per master, fieldStatuses for the master row only, and languageIds ignored. The default-image
  index fields are empty on every document; only ImageSmall drives a missing-image query.
• Masters with variants and ProductNumber. Combine stores the master number as an empty string and the
  master edit screen has no Number field, so keep ProductNumber out of completion rules (DW 10.29.7,
  dynamicweb/DynamicWeb#735). "Exclude variants" still counts the variants' Number; variant-editable category
  fields are checked per variant. dw-pim-modelling structural-model.md adds the combine side effects and
  two variant-field traps; dw-pim-workflow notes excludeVariants.
• assign_completion_rules_to_shops persists only the last request of a batch (MCP 0.6.0-BETA). Call it
  once per shop and read the assignment back; row added to dw-extend-mcp-tools tool-surface-gaps.md.

5.8.7

• dw-render-viewmodels viewmodel-traps.md: the "no picture" fallback hides a null
  DefaultImage. With Ecom/Picture/NoPicture set, an image-less product renders the fallback image
  and an unguarded template never fails, so a crash reproduction or a sweep proof must blank the
  fallback for the run. The fallback also covers unguarded templates until they are fixed.

5.8.6

• dw-demo-fo Get-FoErrorText is safe under strict mode. A 404 with no response body (no
  ErrorDetails) threw "The property 'Message' cannot be found" inside the caller's catch block, so
  Import-GoldenPackage.ps1 stopped before it created a missing import project. Every error shape now
  falls back to the body text or the exception message. New hermetic suite tests/Fo.Api.Tests.ps1.
• dw-demo-pim canonical-setup-order.md step 8: delete_groups measured. It deletes no
  products, in one group or in two; it leaves the group's product relations and shop relation behind
  as orphans, and a group recreated with the same id picks them up. Step 10: read stockStatus back,
  since the create response echoes neverOutOfStock wrongly.
• dw-demo-swift cheat-sheet.md navigation table. save_pages {showInMenu:false} writes
  PageActive, the same column as set_page_menu, and no MCP tool in the 0.6.0 or 0.6.1 add-in
  source writes PageShowInLegend; PageSave stays the only call that hides a page and keeps it
  published.