@salesforce/b2c-dx-mcp 3.0.1 → 3.1.1

package/node_modules/@salesforce/b2c-agent-plugins/README.md

@@ -15,6 +15,7 @@ These skills follow the open [Agent Skills](https://agentskills.io/home) standar
 | [`b2c-ops`](./b2c-ops) | Administrator and operator runbooks — job health, checkout failures, incident triage, recovery checks, and escalation |
 | [`storefront-next`](./storefront-next) | Storefront Next development — project setup, routing, data fetching, components, design-system component authoring, vertical/theme creation, Page Designer, authentication, hybrid storefronts, i18n, state management, extensions, performance, testing, and Managed Runtime deployment |
 | [`storefront-next-figma`](./storefront-next-figma) | Figma design-kit workflows for Storefront Next verticals — duplicate the kit, sync Brand variables from `brand.css`, edit components at the correct layer, and publish Code Connect. **Requires the [Figma MCP server](https://help.figma.com/hc/en-us/articles/32132100833559-Guide-to-the-Figma-MCP-server).** |
+| [`b2c-python-sdk`](./b2c-python-sdk) | Consuming the `salesforce-b2c-tooling-sdk` Python SDK from scripts and notebooks — install/import, choose an auth mechanism, resolve config from `dw.json`, and call the OCAPI/SCAPI/WebDAV clients and operations (code deploy, jobs, sites, catalogs, sandboxes, metrics, logs, SLAS shopper tokens) |
 
 `b2c-dx-mcp` is also published as a plugin from this repository, but it is an **MCP server plugin**, not a skills plugin — its skills are not in this directory. For installation and configuration, see the [MCP Installation Guide](../docs/mcp/installation.md) and [MCP Overview](../docs/mcp/index.md).
 
@@ -59,7 +60,8 @@ skills/
 ├── b2c-cli/skills/                 # B2C CLI operation skills
 ├── b2c-ops/skills/                 # Administrator/operator runbooks
 ├── storefront-next/skills/         # Storefront Next skills
-└── storefront-next-figma/skills/   # Figma design-kit skill(s)
+├── storefront-next-figma/skills/   # Figma design-kit skill(s)
+└── b2c-python-sdk/skills/          # Python tooling SDK consumer skill(s)
 ```
 
 Plugins listed in [`plugins.json`](./plugins.json) are zipped to `<name>-skills.zip` and attached to the `b2c-agent-plugins` GitHub release; the B2C CLI downloads those artifacts for `b2c setup skills`. Adding a plugin there is all that's needed for the release workflow to package it.
@@ -70,7 +72,7 @@ Plugins listed in [`plugins.json`](./plugins.json) are zipped to `<name>-skills.
 - When changing development patterns, update the relevant `b2c/skills/<topic>/SKILL.md`.
 - Add runbooks under `b2c-ops/skills/` using the shared operational structure in
   `.agents/skills/mcp-development/references/workflows.md`; link shipped outcomes
-  from the Operations guide. Register collections in `guidance/collections.json`
+  from the Operations guide. Register collections in `packages/b2c-dx-mcp/skills/collections.json`
   for MCP bundling and in both marketplaces for native installation.
 - To make a new plugin installable via the B2C CLI, add it to [`plugins.json`](./plugins.json) and register a source in `packages/b2c-tooling-sdk/src/skills/sources.ts` (plus the `SkillSet` type in `types.ts`).
 - Add a changeset targeting `@salesforce/b2c-agent-plugins` for any skill content changes.

package/node_modules/@salesforce/b2c-agent-plugins/b2c/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "b2c",
-  "version": "1.9.0",
+  "version": "1.10.1",
   "description": "B2C Commerce development skills including Custom API development guides.",
   "author": {
     "name": "Salesforce"

package/node_modules/@salesforce/b2c-agent-plugins/b2c/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "b2c",
-  "version": "1.9.0",
+  "version": "1.10.1",
   "description": "B2C Commerce development skills including Custom API development guides.",
   "author": {
     "name": "Salesforce"

package/node_modules/@salesforce/b2c-agent-plugins/b2c-cli/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "b2c-cli",
-  "version": "1.9.0",
+  "version": "1.10.1",
   "description": "B2C CLI Skills for Salesforce Commerce Cloud development.",
   "author": {
     "name": "Salesforce"

package/node_modules/@salesforce/b2c-agent-plugins/b2c-cli/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "b2c-cli",
-  "version": "1.9.0",
+  "version": "1.10.1",
   "description": "B2C CLI Skills for Salesforce Commerce Cloud development.",
   "author": {
     "name": "Salesforce"

package/node_modules/@salesforce/b2c-agent-plugins/b2c-cli/skills/b2c-config/SKILL.md

@@ -31,6 +31,23 @@ Sources, in resolution order (highest priority first):
 
 For unexpected values, inspect resolved configuration and sources with `config_inspect` or `b2c setup inspect`.
 
+### Storefront Next Environment Compatibility
+
+The resolver accepts these Storefront Next variables as fallbacks, so a project
+can reuse its existing B2C Commerce and SLAS configuration:
+
+| Storefront Next variable                     | Resolved field     | Default toolkit variable  |
+| -------------------------------------------- | ------------------ | ------------------------- |
+| `PUBLIC__app__commerce__api__clientId`       | `slasClientId`     | `SFCC_SLAS_CLIENT_ID`     |
+| `PUBLIC__app__commerce__api__organizationId` | `tenantId`         | `SFCC_TENANT_ID`          |
+| `PUBLIC__app__commerce__api__shortCode`      | `shortCode`        | `SFCC_SHORTCODE`          |
+| `COMMERCE_API_SLAS_SECRET`                   | `slasClientSecret` | `SFCC_SLAS_CLIENT_SECRET` |
+| `PUBLIC__app__defaultSiteId`                 | `siteId`           | `SFCC_SITE_ID`            |
+| `MRT_PROJECT`                                | `mrtProject`       | `MRT_PROJECT`             |
+| `MRT_TARGET`                                 | `mrtEnvironment`   | `MRT_ENVIRONMENT`         |
+
+Explicit flags and default toolkit variables win over these fallbacks.
+
 ### Shared Global Default
 
 Use a shared fallback when the same `dw.json`-format file should work across the CLI, MCP server, and B2C DX VS Code extension:
@@ -263,7 +280,7 @@ The `setup inspect` command displays configuration organized by category:
 - **Managed Runtime (MRT)**: mrtProject, mrtEnvironment, mrtApiKey, mrtOrigin (if set)
 - **Project**: configured deployment, content, and documentation defaults
 - **Metadata**: siteId, instanceName, and projectDirectory (only shown when configured)
-- **Safety**: safety configuration (only shown when configured)
+- **Safety**: effective level, level-based confirmation, source column, and rule count after combining instance, global-file, and environment settings (only shown when configured). `SafetyFile` identifies the global file listed in Sources; `SafetyEnv` identifies environment settings. Use `--verbose` for numbered rules in matching order with their sources, or `--json` for the complete effective safety object. Explicit confirmation rules still apply when level confirmation is disabled.
 - **Sources**: List of all configuration sources that were loaded
 
 Each value shows its source in brackets:

package/node_modules/@salesforce/b2c-agent-plugins/b2c-cli/skills/b2c-docs/SKILL.md

@@ -17,7 +17,7 @@ Use the `b2c` CLI to search and read B2C Commerce documentation spanning multipl
 
 - **Multi-corpus search** — Search across Script API, Developer Center guides, Salesforce Help (admin + merchandising), internal tooling docs (guides, CLI reference, MCP, and VS Code extension), job steps, and schemas in a unified index
 - **Workspace-aware search** — Auto-detects project type (cartridges, SFRA, PWA Kit, Storefront Next) and boosts relevant documentation while de-boosting competing storefront frameworks
-- **Category filtering** — Use `--category` to narrow results to a specific corpus (e.g., `commerce-api`, `pwa-kit-managed-runtime`, `sfra`, `script-api`, `help-admin`, `help-merchant`)
+- **Category filtering** — Use `--category` to narrow results to a specific corpus (e.g., `commerce-api`, `pwa-kit-managed-runtime`, `sfra`, `script-api`, `help-admin`, `help-merchant`, `help-kb`)
 - **Triage metadata** — Search results include `category`, `summary`, `keywords`, and `url` to help identify the right match without reading full content
 - **Online content with local cache** — Script API, Developer Center guides, and Salesforce Help are fetched online when you read them and cached locally (memory + on-disk, 7-day TTL) so repeat reads avoid the network; graceful offline fallback shows the summary + headings + both URLs
 - **Content-aware ranking** — BM25-style search indexes titles, section headings, summaries, and keywords for better recall on conceptual questions
@@ -54,6 +54,9 @@ b2c docs search "site import export" --category help-admin
 # Search Salesforce Help — merchandising (catalogs, promotions, search, pricing)
 b2c docs search "price book assignment" --category help-merchant
 
+# Search Salesforce Help Knowledge Articles — troubleshooting, known issues, how-to answers
+b2c docs search "code upload certificate hyperforce" --category help-kb
+
 # Search tooling documentation
 b2c docs search "authentication setup" --category tooling
 b2c docs search "import set" --category tooling
@@ -153,6 +156,7 @@ b2c docs read pwa-kit-managed-runtime/getting-started
 # Read Salesforce Help articles by namespaced ID
 b2c docs read help-admin/b2c_site_import_export
 b2c docs read help-merchant/b2c_creating_price_books
+b2c docs read help-kb/002772125
 
 # Read tooling guides
 b2c docs read guide-authentication
@@ -239,10 +243,11 @@ xmllint --schema "$(b2c docs schema catalog --path)" my-catalog.xml --noout
 | `job-step`                | Standard (system) job step catalog                                                                                               | `ImportCatalog`, `ExportCatalog`, `job-steps`       |
 | `help-admin`              | Salesforce Help — administration/ops (import/export, jobs, replication, security, Account Manager, permissions, logs, inventory) | `help-admin/b2c_site_import_export`                 |
 | `help-merchant`           | Salesforce Help — merchandising (catalogs, products, promotions, search, content, analytics, SEO)                                | `help-merchant/b2c_creating_price_books`            |
+| `help-kb`                 | Salesforce Help Knowledge Articles — troubleshooting, known issues, and how-to answers (keyed by article number)                 | `help-kb/002772125`                                 |
 
-> **URLs:** All categories except `job-step` carry both `url` (human .html page) and `sourceUrl` (machine-readable .md). For `help-admin`/`help-merchant`, `url` is the live help.salesforce.com article and content is read from `sourceUrl`. `job-step` entries have neither (content is bundled inline).
+> **URLs:** All categories except `job-step` carry both `url` (human .html page) and `sourceUrl` (machine-readable .md). For `help-admin`/`help-merchant`/`help-kb`, `url` is the live help.salesforce.com article and content is read from `sourceUrl`. `job-step` entries have neither (content is bundled inline).
 >
-> **Caching:** Content for the online corpora (`script-api`, the guide categories, `help-admin`/`help-merchant`, `tooling`) is fetched on `docs read` and cached locally. Use `b2c docs cache` to inspect it and `b2c docs cache --clear` to purge it (forces a re-fetch).
+> **Caching:** Content for the online corpora (`script-api`, the guide categories, `help-admin`/`help-merchant`/`help-kb`, `tooling`) is fetched on `docs read` and cached locally. Use `b2c docs cache` to inspect it and `b2c docs cache --clear` to purge it (forces a re-fetch).
 
 ## Common Script API Classes
 

package/node_modules/@salesforce/b2c-agent-plugins/b2c-cli/skills/b2c-ecdn/SKILL.md

@@ -60,10 +60,10 @@ b2c ecdn cache purge --zone my-zone --tag product-123 --tag category-456
 b2c ecdn certificates list --zone my-zone
 
 # add a new certificate
-b2c ecdn certificates add --zone my-zone --hostname www.example.com --certificate-file ./cert.pem --private-key-file ./key.pem
+b2c ecdn certificates add --zone my-zone --hostname www.example.com --type custom --certificate-file ./cert.pem --private-key-file ./key.pem
 
 # validate a custom hostname
-b2c ecdn certificates validate --zone my-zone --certificate-id abc123
+b2c ecdn certificates validate --zone my-zone --custom-hostname-id abc123
 ```
 
 ### Manage Rate Limiting Rules
@@ -92,7 +92,7 @@ b2c ecdn rate-limit delete --zone my-zone --rule-id 2c0fc9fa937b11eaa1b71c4d701a
 b2c ecdn security get --zone my-zone
 
 # update security settings
-b2c ecdn security update --zone my-zone --ssl-mode full --min-tls-version 1.2 --always-use-https
+b2c ecdn security update --zone my-zone --security-level medium --always-use-https --tls13
 ```
 
 ### Speed Settings
@@ -102,7 +102,7 @@ b2c ecdn security update --zone my-zone --ssl-mode full --min-tls-version 1.2 --
 b2c ecdn speed get --zone my-zone
 
 # update speed settings
-b2c ecdn speed update --zone my-zone --browser-cache-ttl 14400 --auto-minify-html --auto-minify-css
+b2c ecdn speed update --zone my-zone --brotli on --http3 on --webp on
 ```
 
 ## Additional Topics

package/node_modules/@salesforce/b2c-agent-plugins/b2c-cli/skills/b2c-ecdn/references/ADVANCED.md

@@ -41,17 +41,32 @@ b2c ecdn mrt-rules delete --zone my-zone
 
 ## mTLS Certificates
 
+Code upload certificates enable two-factor (mTLS) code upload to staging instances (`_stg` tenants only). Upload a CA certificate to eCDN, then issue client certificates (`.p12`) signed by that CA for each user or pipeline. The CA private key must be kept secret (treat like a password); the CA certificate bundle must have a maximum validity of 1 year and be renewed before expiry. On Hyperforce, use the `staging-<realm>-<customer>.demandware.net` code upload hostname (not legacy `cert.staging.*`).
+
+For the complete workflow, security guidance, and renewal instructions, see [Deploying to Hyperforce: Code Upload Certificates](https://salesforcecommercecloud.github.io/b2c-developer-tooling/guide/hyperforce#code-upload-certificates).
+
 ```bash
-# list mTLS certificates (organization level)
-b2c ecdn mtls list
+# interactive wizard: generate CA, upload, issue your client cert, update dw.json
+b2c ecdn mtls setup
+
+# non-interactive: generate CA + upload + issue first client cert
+b2c ecdn mtls create --name code-upload --generate
+b2c ecdn mtls create --name code-upload --generate --out-dir ./certs --client-name jsmith
 
-# create mTLS certificate for code upload authentication
-b2c ecdn mtls create --name "Build Server" --ca-certificate-file ./ca.pem --leaf-certificate-file ./leaf.pem
+# upload an existing CA
+b2c ecdn mtls create --name code-upload --certificate-file ./ca.pem --private-key-file ./ca.key
+
+# issue additional client certificates (local-only, no API call)
+b2c ecdn mtls issue --ca-cert-file ./certs/ca.pem --ca-key-file ./certs/ca.key --name jane.doe
+b2c ecdn mtls issue --ca-cert-file ca.pem --ca-key-file ca.key --name ci --output ci.p12 --days 90
+
+# list uploaded CA certificates
+b2c ecdn mtls list
 
-# get mTLS certificate details
+# get certificate details
 b2c ecdn mtls get --certificate-id abc123
 
-# delete mTLS certificate
+# delete a CA certificate (uploaded CA stops accepting client certs)
 b2c ecdn mtls delete --certificate-id abc123
 ```
 

package/node_modules/@salesforce/b2c-agent-plugins/b2c-cli/skills/b2c-ecdn/references/SECURITY.md

@@ -33,10 +33,10 @@ b2c ecdn waf migrate --zone my-zone
 b2c ecdn firewall list --zone my-zone
 
 # create a firewall rule
-b2c ecdn firewall create --zone my-zone --description "Block bad bots" --action block --filter '(cf.client.bot)'
+b2c ecdn firewall create --zone my-zone --description "Block bad bots" --expression '(cf.client.bot)' --actions block
 
 # update a firewall rule
-b2c ecdn firewall update --zone my-zone --rule-id abc123 --action challenge
+b2c ecdn firewall update --zone my-zone --rule-id abc123 --actions managed_challenge
 
 # reorder firewall rules
 b2c ecdn firewall reorder --zone my-zone --rule-ids id1,id2,id3
@@ -49,7 +49,7 @@ b2c ecdn firewall reorder --zone my-zone --rule-ids id1,id2,id3
 b2c ecdn rate-limit list --zone my-zone
 
 # create a rate limiting rule
-b2c ecdn rate-limit create --zone my-zone --description "API rate limit" --threshold 100 --period 60 --action block --match-url '/api/*'
+b2c ecdn rate-limit create --zone my-zone --description "API rate limit" --expression '(http.request.uri.path matches "^/api/")' --characteristics cf.unique_visitor_id --action block --period 60 --requests-per-period 100 --mitigation-timeout 600
 
 # delete a rate limiting rule
 b2c ecdn rate-limit delete --zone my-zone --rule-id abc123
@@ -62,7 +62,7 @@ b2c ecdn rate-limit delete --zone my-zone --rule-id abc123
 b2c ecdn page-shield notifications list
 
 # create a notification webhook
-b2c ecdn page-shield notifications create --url https://example.com/webhook --secret my-secret --zones zone1,zone2
+b2c ecdn page-shield notifications create --webhook-url https://example.com/webhook --secret my-secret --zones zone1,zone2
 
 # list Page Shield policies (zone level)
 b2c ecdn page-shield policies list --zone my-zone

package/node_modules/@salesforce/b2c-agent-plugins/b2c-cli/skills/b2c-job/SKILL.md

@@ -39,7 +39,9 @@ Deletion removes completed execution records; it does not cancel jobs.
 
 ```bash
 b2c job import ./archive --show-log
+b2c job import ./storefront-export.zip --wait-for-storefront
 b2c job export --site MySite --site-data campaigns_and_promotions --output ./export
+b2c job export --storefront my-storefront --output ./export
 ```
 
 Import/export wait by default and transfer files over WebDAV. Jobs prefer SCAPI

package/node_modules/@salesforce/b2c-agent-plugins/b2c-cli/skills/b2c-job/references/EXPORT.md

@@ -39,6 +39,9 @@ b2c job export --site RefArch
 # export a site with specific site data units
 b2c job export --site RefArch --site-data content,site_preferences
 
+# export one composable storefront by storefront name
+b2c job export --storefront my-storefront
+
 # export multiple sites
 b2c job export --site RefArch --site SiteGenesis --site-data campaigns_and_promotions
 
@@ -98,6 +101,7 @@ Do not require a temporary directory and copy step for export-based migrations.
 | Flag               | Description                                                                    |
 | ------------------ | ------------------------------------------------------------------------------ |
 | `--site`           | Site IDs to export (use `--site-data` to pick specific units, defaults to all) |
+| `--storefront`     | One composable storefront name                                                 |
 | `--catalog`        | Catalog IDs                                                                    |
 | `--library`        | Library IDs                                                                    |
 | `--inventory-list` | Inventory list IDs                                                             |
@@ -106,10 +110,12 @@ Do not require a temporary directory and copy step for export-based migrations.
 
 **Site data units** (use with `--site-data`):
 
-`ab_tests`, `active_data_feeds`, `all`, `cache_settings`, `campaigns_and_promotions`, `content`, `coupons`, `custom_objects`, `customer_cdn_settings`, `customer_groups`, `distributed_commerce_extensions`, `dynamic_file_resources`, `gift_certificates`, `ocapi_settings`, `payment_methods`, `payment_processors`, `redirect_urls`, `search_settings`, `shipping`, `site_descriptor`, `site_preferences`, `sitemap_settings`, `slots`, `sorting_rules`, `source_codes`, `static_dynamic_alias_mappings`, `stores`, `tax`, `url_rules`
+`ab_tests`, `active_data_feeds`, `all`, `cache_settings`, `campaigns_and_promotions`, `channels`, `commerce_feature_states`, `content`, `coupons`, `custom_objects`, `customer_cdn_settings`, `customer_groups`, `distributed_commerce_extensions`, `dynamic_file_resources`, `gift_certificates`, `ocapi_settings`, `payment_methods`, `payment_processors`, `point_of_sale_channels`, `redirect_urls`, `search_settings`, `shipping`, `site_descriptor`, `site_preferences`, `sitemap_settings`, `slots`, `sorting_rules`, `source_codes`, `static_dynamic_alias_mappings`, `stores`, `tax`, `url_rules`
 
 **Global data units** (use with `--global-data`):
 
-`access_roles`, `all`, `csc_settings`, `csrf_whitelists`, `custom_preference_groups`, `custom_quota_settings`, `custom_types`, `geolocations`, `global_custom_objects`, `job_schedules`, `job_schedules_deprecated`, `locales`, `meta_data`, `oauth_providers`, `ocapi_settings`, `page_meta_tags`, `preferences`, `price_adjustment_limits`, `services`, `sorting_rules`, `static_resources`, `system_type_definitions`, `users`, `webdav_client_permissions`
+`access_roles`, `all`, `csc_settings`, `csrf_whitelists`, `custom_preference_groups`, `custom_quota_settings`, `custom_types`, `event_routing`, `geolocations`, `global_custom_objects`, `job_schedules`, `job_schedules_deprecated`, `locales`, `meta_data`, `oauth_providers`, `ocapi_settings`, `page_meta_tags`, `preferences`, `price_adjustment_limits`, `services`, `sorting_rules`, `static_resources`, `system_type_definitions`, `users`, `webdav_client_permissions`
+
+For full control over the export configuration (including `assignments`, `catalog_static_resources`, `library_static_resources`, and `customer_lists`), use `--data-units` with a JSON string matching the `ExportDataUnitsConfiguration` shape. The `storefronts` object is keyed by storefront name and may select only one storefront.
 
-For full control over the export configuration (including `catalog_static_resources`, `library_static_resources`, and `customer_lists`), use `--data-units` with a JSON string matching the `ExportDataUnitsConfiguration` shape.
+The `storefronts` export data unit requires B2C Commerce 26.10 or later. Failed storefront exports include a version note alongside the original error; check the instance version when the server rejects this data unit.

package/node_modules/@salesforce/b2c-agent-plugins/b2c-cli/skills/b2c-job/references/IMPORT.md

@@ -23,12 +23,24 @@ b2c job import existing-archive.zip --remote
 # show job log on failure
 b2c job import ./my-site-data --show-log
 
+# wait for Storefront Next post-import setup after the archive import succeeds
+b2c job import ./storefront-export.zip --wait-for-storefront
+
 # import only a subset of a directory (extra positionals are paths/globs
 # resolved against the directory; preserves layout inside the archive)
 b2c job import ./my-site-data sites/RefArch libraries/mylib
 b2c job import ./my-site-data 'libraries/**'
 ```
 
+`--wait-for-storefront` snapshots existing setup-job executions before import,
+waits for the archive import to succeed, and then polls briefly for the newly
+triggered `sfcc-post-import-setup-storefront` execution before waiting for it to
+finish. It cannot be combined with `--no-wait`. If no new setup execution appears
+within 60 seconds, the CLI checks available import logs and includes `[DATAERROR]`
+entries in the timeout error. Logs are downloaded for this diagnostic only on
+discovery timeout. Resolve any reported data errors before retrying; if logs are
+unavailable or contain no data errors, inspect the import contents and recent job executions.
+
 ### Import Sets
 
 `job import-set` first applies site import/export archives from discovered cartridge `metadata/` sources, then applies archives in `./migrations`, and skips archives already recorded on the target instance:

package/node_modules/@salesforce/b2c-agent-plugins/b2c-cli/skills/b2c-mrt/SKILL.md

@@ -17,15 +17,16 @@ Run `b2c setup inspect` to see the resolved configuration and which source provi
 
 ### MRT Backends (legacy vs SCAPI)
 
-Most MRT commands run against the legacy MRT Cloud API (API key). Two commands — `mrt bundle history` and `mrt bundle deploy <bundleId>` — can also run over the SCAPI MRT backend. Choose with `--mrt-backend` (`MRT_BACKEND` / `SFCC_MRT_BACKEND`, or `mrtBackend` in `dw.json`):
+Most MRT commands run against the legacy MRT Cloud API (API key). Several commands can also run over the SCAPI MRT backend: `mrt bundle history`, `mrt bundle list`, `mrt bundle deploy` (both the local-build push and deploying an existing `<bundleId>`), and the `mrt env var` family (`list` / `set` / `push` / `delete`). Choose with `--mrt-backend` (`MRT_BACKEND` / `SFCC_MRT_BACKEND`, or `mrtBackend` in `dw.json`):
 
-- `auto` (default) — use SCAPI when it's configured (`--short-code` + `--tenant-id` + client-credentials or JWT Bearer auth; scopes `sfcc.storefront.deployments[.rw]`), otherwise legacy. Falls back to legacy on safe pre-execution errors.
+- `auto` (default) — use SCAPI when it's configured (`--short-code` + `--tenant-id` + client-credentials or JWT Bearer auth), otherwise legacy. Falls back to legacy on safe pre-execution errors. Each command requests its own scopes: bundle commands use `sfcc.storefront.deployments[.rw]`; env var commands use `sfcc.storefront.environments[.rw]` (reads accept either tier, writes require `.rw`).
 - `legacy` — always the MRT Cloud API.
-- `scapi` — always SCAPI, with no fallback; errors if prerequisites are missing. Also errors on unsupported commands and on the local-build push path (`deploy` with no bundle ID).
+- `scapi` — always SCAPI, with no fallback; errors if prerequisites are missing. Also errors on unsupported commands (every MRT command except the bundle and env var commands above).
 
 Notes:
 
-- Under `--json`, these commands emit the **serving backend's native shape** (legacy `{count, next, previous, deployments}` vs SCAPI `{limit, offset, total, data}`). The human table is normalized; `--json` is not. Pin `legacy` or `scapi` when a script needs a stable shape.
+- Under `--json`, these commands emit the **serving backend's native shape** (e.g. `bundle history` is legacy `{count, next, previous, deployments}` vs SCAPI `{limit, offset, total, data}`; `env var list` is legacy `{count, variables}` vs the SCAPI native environment-variables map). The human table is normalized; `--json` is not. Pin `legacy` or `scapi` when a script needs a stable shape.
+- Env vars over SCAPI use the Storefront Environments API. `set` and `delete` apply a merge-PATCH (only the keys you pass change; `delete` sends the key with a `null` value); values are always masked by both backends. `push` resolves the backend once from its initial read and pins every write to it, so a single `push` never crosses backends.
 - Legacy-only flags (`--api-key`, `--cloud-origin` / `-u`, `--credentials-file` / `-c`) are ignored — with a warning — when SCAPI serves the request.
 - `--storefront` (long) and `-s` (short) are aliases of `--project` / `-p` — the SCAPI storefront ID is the project slug, so all four are interchangeable on every `mrt` command. On `mrt project create` this flag sets the new project's slug (auto-generated from the name if omitted); `mrt bundle save` uses `-d` for `--save-dir`, keeping `-s` free for the storefront alias.
 

package/node_modules/@salesforce/b2c-agent-plugins/b2c-cli/skills/b2c-mrt/references/BUNDLE-COMMANDS.md

@@ -31,11 +31,22 @@ b2c mrt bundle deploy -p my-storefront --ssr-param SSRProxyPath=/api
 b2c mrt bundle deploy -p my-storefront \
   --ssr-param SSRProxyPath=/api \
   --ssr-param SSRTimeout=30000
+
+# Push a local build and deploy it via the SCAPI backend
+b2c mrt bundle deploy -p my-storefront -e staging --mrt-backend scapi
+
+# Push via SCAPI with a custom v2 archive layout
+b2c mrt bundle deploy -p my-storefront --mrt-backend scapi --root-dir bld --match-mode ignore_missing
+
+# Push via the legacy v2 endpoint (opt in with --v2)
+b2c mrt bundle deploy -p my-storefront --mrt-backend legacy --v2 --match-mode ignore_missing
 ```
 
+**Bundle format:** SCAPI always uploads the v2 format. The legacy backend defaults to v1; pass `--v2` to upload through the legacy v2 endpoint (upload, plus a separate deploy when `-e` is given). `--root-dir`, `--config-path`, and `--match-mode` control the v2 archive layout and only take effect on a v2 upload — on a legacy v1 push they are ignored and the command warns (pass `--v2` to enable them). `b2c mrt bundle deploy --v2` performs the same v2 upload as `b2c mrt bundle upload-v2` and can also deploy in one step.
+
 ### Deploy Existing Bundle
 
-Deploying an existing bundle (with a bundle ID) is backend-aware — it honors `--mrt-backend` (`auto` / `legacy` / `scapi`). Pushing a local build is legacy-pinned. See the "MRT Backends" section in the skill overview.
+Both the local-build push and deploying an existing bundle (with a bundle ID) are backend-aware — they honor `--mrt-backend` (`auto` / `legacy` / `scapi`). For a local-build push under `auto`, a safe SCAPI upload failure falls back to legacy, but once the bundle is uploaded a later deploy failure is not retried on legacy (so a bundle is never uploaded twice). See the "MRT Backends" section in the skill overview.
 
 ```bash
 # Deploy existing bundle by ID
@@ -55,6 +66,10 @@ b2c mrt bundle deploy 12345 -p my-storefront -e production --mrt-backend scapi -
 | `--build-dir`, `-b` | Path to build directory | `build` |
 | `--ssr-only` | Server-only file patterns | `ssr.js,ssr.mjs,server/**/*` |
 | `--ssr-shared` | Shared file patterns | `static/**/*,client/**/*` |
+| `--v2` | Use the v2 bundle format/endpoint (SCAPI always uses v2; opt in on legacy) | `false` |
+| `--root-dir` | Archive path prefix for built files and the config file (v2 uploads only) | `bld` |
+| `--config-path` | In-archive config file path, relative to `--root-dir` (v2 uploads only) | `.mrt/config.json` |
+| `--match-mode` | Handling of SSR patterns matching no files — `strict` or `ignore_missing` (v2 uploads only) | `strict` |
 | `--node-version`, `-n` | Node.js version for SSR | `24.x` |
 | `--ssr-param` | SSR parameters (key=value, can repeat) | |
 
@@ -102,16 +117,19 @@ b2c mrt bundle upload-v2 -p my-storefront --dependencies @./deps.json --cc-overr
 
 ## Bundle List
 
-List bundles in a project.
+List bundles in a project. Backend-aware (`--mrt-backend`); under `--json` it returns the serving backend's native response verbatim (legacy vs SCAPI shapes differ).
 
 ```bash
 b2c mrt bundle list --project my-storefront
 b2c mrt bundle list -p my-storefront --limit 10
 b2c mrt bundle list -p my-storefront --offset 20
 b2c mrt bundle list -p my-storefront --json
+
+# Force the SCAPI backend
+b2c mrt bundle list -p my-storefront --mrt-backend scapi
 ```
 
-**Output columns:** Bundle ID, Message, Status, Created
+**Output columns:** Bundle ID, Message, Status, User, Created
 
 ## Bundle History
 

package/node_modules/@salesforce/b2c-agent-plugins/b2c-cli/skills/b2c-mrt/references/ENVIRONMENT-COMMANDS.md

@@ -110,11 +110,16 @@ b2c mrt env b2c -p my-storefront -e production --clear-sites
 
 ## Environment Variables
 
+The `mrt env var` commands (`list` / `set` / `push` / `delete`) are backend-aware: they honor `--mrt-backend` (`auto` / `legacy` / `scapi`) and, over SCAPI, use the Storefront Environments API (scopes `sfcc.storefront.environments` for reads, `sfcc.storefront.environments.rw` for writes). See the [MRT Backends](../SKILL.md#mrt-backends-legacy-vs-scapi) section for backend selection. Values are always masked by both backends. `set` and `delete` apply a merge-PATCH — only the keys you pass change (`delete` sends the key with a `null` value); other variables are preserved. Under `--json`, each command returns the serving backend's native shape.
+
 ### List Variables
 
 ```bash
 b2c mrt env var list --project my-storefront --environment production
 b2c mrt env var list -p my-storefront -e staging --json
+
+# Force the SCAPI backend
+b2c mrt env var list -p my-storefront -e staging --mrt-backend scapi
 ```
 
 ### Set Variables
@@ -130,6 +135,9 @@ b2c mrt env var set API_KEY=secret DEBUG=true FEATURE_FLAG=enabled \
 # Value with spaces (use quotes)
 b2c mrt env var set "MESSAGE=hello world" -p my-storefront -e production
 
+# Force the SCAPI backend
+b2c mrt env var set API_KEY=secret -p my-storefront -e staging --mrt-backend scapi
+
 # Using environment variables for auth
 export MRT_API_KEY=your-api-key
 export MRT_PROJECT=my-storefront
@@ -137,10 +145,25 @@ export MRT_ENVIRONMENT=staging
 b2c mrt env var set MY_VAR=value
 ```
 
+### Push Variables from a .env File
+
+Diff a local `.env` file against the remote environment and apply the additions/updates (remote-only variables are not deleted). `push` resolves the backend once from its initial read and pins every write to it; over SCAPI the changes are applied as a single merge-PATCH.
+
+```bash
+# Push ./.env, with confirmation prompt
+b2c mrt env var push -p my-storefront -e production
+
+# Push a custom file, skipping confirmation, over SCAPI
+b2c mrt env var push -p my-storefront -e staging --file config/.env --yes --mrt-backend scapi
+```
+
 ### Delete Variable
 
 ```bash
 b2c mrt env var delete MY_VAR -p my-storefront -e production
+
+# Force the SCAPI backend
+b2c mrt env var delete MY_VAR -p my-storefront -e production --mrt-backend scapi
 ```
 
 ## URL Redirects

package/node_modules/@salesforce/b2c-agent-plugins/b2c-cli/skills/b2c-webdav/SKILL.md

@@ -37,11 +37,28 @@ The `--root` flag specifies the WebDAV directory:
 - `catalogs` - Product catalogs
 - `libraries` - Content libraries
 - `static` - Static resources
+- `dynamic` - Site-specific files, including Velocity templates
 - `logs` - Application logs
 - `securitylogs` - Security logs
 
 ## Examples
 
+### Dynamic Site Files
+
+Use `--root=dynamic` with the site ID as the first remote path segment. For example,
+`MySite/mockData/mock.vm` resolves to `Sites/Dynamic/MySite/mockData/mock.vm`.
+This location holds site-specific files independently of code versions, including
+Velocity templates used by `dw.template.Velocity.renderTemplate()`.
+
+```bash
+b2c webdav ls --root=dynamic MySite/
+b2c webdav mkdir --root=dynamic MySite/mockData
+b2c webdav put --root=dynamic ./mock.vm MySite/mockData/
+b2c webdav get --root=dynamic MySite/mockData/mock.vm -o ./mock.vm
+```
+
+The same root and site-prefixed paths work with `rm`, `zip`, and `unzip`.
+
 ### List Files
 
 ```bash

package/node_modules/@salesforce/b2c-agent-plugins/b2c-ops/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "b2c-ops",
-  "version": "1.9.0",
+  "version": "1.10.1",
   "description": "B2C Commerce operator and administrator runbooks for job health, checkout and failed orders, and incident triage.",
   "author": {
     "name": "Salesforce"

package/node_modules/@salesforce/b2c-agent-plugins/b2c-ops/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "b2c-ops",
-  "version": "1.9.0",
+  "version": "1.10.1",
   "description": "B2C Commerce operator and administrator runbooks for job health, checkout and failed orders, and incident triage.",
   "author": {
     "name": "Salesforce"

package/node_modules/@salesforce/b2c-agent-plugins/b2c-python-sdk/.codex-plugin/plugin.json

@@ -0,0 +1,41 @@
+{
+  "name": "b2c-python-sdk",
+  "version": "0.1.0",
+  "description": "Consuming the salesforce-b2c-tooling-sdk Python SDK — authenticate to B2C Commerce, resolve dw.json config, and call OCAPI/SCAPI/WebDAV clients and operations from scripts or notebooks.",
+  "author": {
+    "name": "Salesforce"
+  },
+  "homepage": "https://salesforcecommercecloud.github.io/b2c-developer-tooling/",
+  "repository": "https://github.com/SalesforceCommerceCloud/b2c-developer-tooling",
+  "license": "Apache-2.0",
+  "keywords": [
+    "salesforce",
+    "b2c-commerce",
+    "commerce-cloud",
+    "python",
+    "sdk",
+    "scapi",
+    "ocapi"
+  ],
+  "skills": "./skills/",
+  "interface": {
+    "displayName": "B2C Python SDK",
+    "shortDescription": "Use the Salesforce B2C Commerce Python tooling SDK from your AI assistant.",
+    "longDescription": "Skills for consuming the salesforce-b2c-tooling-sdk Python SDK from scripts and Jupyter notebooks — install and import it, choose an authentication mechanism, resolve config from dw.json, and call the OCAPI/SCAPI/WebDAV clients and higher-level operations (code deploy, jobs, sites, catalogs, sandboxes, metrics, logs, SLAS shopper tokens).",
+    "developerName": "Salesforce",
+    "category": "Productivity",
+    "capabilities": [
+      "Read"
+    ],
+    "logo": "./assets/logo.svg",
+    "composerIcon": "./assets/logo.svg",
+    "brandColor": "#0D9DDA",
+    "websiteURL": "https://salesforcecommercecloud.github.io/b2c-developer-tooling/",
+    "defaultPrompt": [
+      "Write a Python script that deploys the cartridges in ./cartridges using the B2C tooling SDK",
+      "Use the Python SDK to authenticate from my dw.json and run a job",
+      "Show me how to mint a SLAS guest shopper token with the Python SDK",
+      "Read the latest error logs from my instance with the Python tooling SDK"
+    ]
+  }
+}

package/node_modules/@salesforce/b2c-agent-plugins/b2c-python-sdk/README.md

@@ -0,0 +1,35 @@
+# b2c-python-sdk
+
+Agent skills for **consuming** the [`salesforce-b2c-tooling-sdk`](https://github.com/SalesforceCommerceCloud/b2c-developer-tooling/tree/main/python/b2c-tooling-sdk) Python SDK — authenticate to a Salesforce B2C Commerce instance, resolve config from `dw.json`, and call the OCAPI/SCAPI/WebDAV clients and higher-level operations from Python scripts and Jupyter notebooks.
+
+> This plugin is for developers **writing Python code against the SDK**. To *develop the SDK itself*, see the SDK's own `python/b2c-tooling-sdk/CLAUDE.md`. To drive the B2C **CLI**, use the `b2c-cli` plugin instead.
+
+Part of the [B2C Developer Tooling](https://github.com/SalesforceCommerceCloud/b2c-developer-tooling) marketplace.
+
+## Installation
+
+```bash
+# Claude Code
+claude plugin marketplace add SalesforceCommerceCloud/b2c-developer-tooling
+claude plugin install b2c-python-sdk@b2c-developer-tooling
+
+# GitHub Copilot CLI
+copilot plugin marketplace add SalesforceCommerceCloud/b2c-developer-tooling
+copilot plugin install b2c-python-sdk@b2c-developer-tooling
+```
+
+**VS Code (GitHub Copilot):** Command Palette → **Chat: Install Plugin From Source** → enter the repo `SalesforceCommerceCloud/b2c-developer-tooling`.
+
+**Codex:** open the repo as a workspace, restart Codex, then install from the **B2C Developer Tooling** marketplace in the plugin directory.
+
+For file-copy install to any supported IDE, use `b2c setup skills b2c-python-sdk`. See the [install guide](https://salesforcecommercecloud.github.io/b2c-developer-tooling/guide/agent-skills) for details.
+
+## What's included
+
+- **`using-b2c-tooling-sdk`** — installing and importing the SDK, choosing between the async and sync facades, picking an authentication mechanism, resolving config from `dw.json`, the operations-vs-clients error contract, and minting SLAS shopper tokens. Includes a full symbol catalog in [`references/api-catalog.md`](./skills/using-b2c-tooling-sdk/references/api-catalog.md).
+
+See [`skills/`](./skills/) for the full list.
+
+## License
+
+Apache-2.0. See the [repo LICENSE](https://github.com/SalesforceCommerceCloud/b2c-developer-tooling/blob/main/LICENSE.txt).