@salesforce/b2c-dx-mcp 2.1.2 → 3.0.1

package/content/guidance/b2c-cli/b2c-mrt/references/PROJECT-COMMANDS.md

@@ -0,0 +1,154 @@
+# MRT Project Commands Reference
+
+Detailed reference for MRT project, member, and notification commands.
+
+> **`storefront` alias:** `mrt storefront` is an alias for `mrt project` (including `member` and `notification` subtopics), and `--storefront` / `-s` are aliases for `--project` / `-p` on every command that accepts it — all four are interchangeable. The `MRT_STOREFRONT` / `SFCC_MRT_STOREFRONT` environment variables work as fallbacks for `MRT_PROJECT` / `SFCC_MRT_PROJECT`. The alias matches SCAPI MRT API terminology; the `project` forms continue to work unchanged. Examples below use `project`, but `storefront` is interchangeable. On `mrt project create`, this flag sets the new project's slug (auto-generated from the name if omitted).
+
+## Project Management
+
+### List Projects
+
+```bash
+b2c mrt project list
+b2c mrt project list --limit 10 --offset 0
+b2c mrt project list --json
+```
+
+### Create Project
+
+The positional argument is the project **name**; `--organization` / `-o` is required. Choose the new project's slug with `--project` / `--storefront` (`-p` / `-s`); when omitted, MRT auto-generates it from the name.
+
+```bash
+b2c mrt project create "My Storefront" --organization my-org
+b2c mrt project create "My Storefront" -o my-org --storefront my-storefront
+b2c mrt project create "My Storefront" -o my-org -s my-storefront --region us-east-1
+```
+
+> **Slug as positional or flag:** `get`, `update`, and `delete` accept the project slug **either** as a positional argument **or** via `-p` / `-s` / `--project` / `--storefront` (or `MRT_PROJECT` / `dw.json`). An explicit positional wins if both are given; at least one source must resolve.
+
+### Get Project Details
+
+```bash
+b2c mrt project get my-storefront            # positional
+b2c mrt project get --project my-storefront  # flag
+b2c mrt project get -p my-storefront --json
+```
+
+### Update Project
+
+```bash
+b2c mrt project update my-storefront --name "Updated Name"
+b2c mrt project update --project my-storefront --name "Updated Name"
+```
+
+### Delete Project
+
+```bash
+b2c mrt project delete my-storefront
+b2c mrt project delete --project my-storefront
+b2c mrt project delete -p my-storefront --force  # skip confirmation
+```
+
+## Member Management
+
+Members can have one of three roles: `admin`, `developer`, or `viewer`.
+
+### List Members
+
+```bash
+b2c mrt project member list --project my-storefront
+b2c mrt project member list -p my-storefront --json
+```
+
+### Add Member
+
+```bash
+b2c mrt project member add user@example.com --project my-storefront --role admin
+b2c mrt project member add user@example.com -p my-storefront --role developer
+b2c mrt project member add user@example.com -p my-storefront --role viewer
+```
+
+### Get Member Details
+
+```bash
+b2c mrt project member get user@example.com --project my-storefront
+```
+
+### Update Member Role
+
+```bash
+b2c mrt project member update user@example.com --project my-storefront --role viewer
+```
+
+### Remove Member
+
+```bash
+b2c mrt project member remove user@example.com --project my-storefront
+b2c mrt project member remove user@example.com -p my-storefront --force
+```
+
+## Deployment Notifications
+
+Configure email notifications for deployment events (start, success, failure).
+
+### List Notifications
+
+```bash
+b2c mrt project notification list --project my-storefront
+b2c mrt project notification list -p my-storefront --json
+```
+
+### Create Notification
+
+```bash
+# Notify on deployment failures only
+b2c mrt project notification create -p my-storefront \
+  --target staging --target production \
+  --recipient ops@example.com \
+  --on-failed
+
+# Notify on all deployment events
+b2c mrt project notification create -p my-storefront \
+  --target production \
+  --recipient team@example.com \
+  --on-start --on-success --on-failed
+
+# Multiple recipients
+b2c mrt project notification create -p my-storefront \
+  --target production \
+  --recipient dev@example.com --recipient ops@example.com \
+  --on-failed
+```
+
+**Flags:**
+| Flag | Description |
+|------|-------------|
+| `--target`, `-t` | Target environment (can specify multiple). Aliases: `--environment`, `-e`. |
+| `--recipient`, `-r` | Email recipient (can specify multiple) |
+| `--on-start` | Notify when deployment starts |
+| `--on-success` | Notify when deployment succeeds |
+| `--on-failed` | Notify when deployment fails |
+
+### Get Notification Details
+
+```bash
+b2c mrt project notification get abc-123 --project my-storefront
+b2c mrt project notification get abc-123 -p my-storefront --json
+```
+
+### Update Notification
+
+```bash
+# Change notification events
+b2c mrt project notification update abc-123 -p my-storefront --on-start --no-on-failed
+
+# Update recipients
+b2c mrt project notification update abc-123 -p my-storefront --recipient new-team@example.com
+```
+
+### Delete Notification
+
+```bash
+b2c mrt project notification delete abc-123 --project my-storefront
+b2c mrt project notification delete abc-123 -p my-storefront --force
+```

package/content/guidance/b2c-cli/b2c-sandbox/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: b2c-sandbox
+description: Create and manage on-demand sandboxes (ODS) for B2C Commerce using the b2c CLI. Use this skill whenever the user needs to spin up a new development sandbox, list running sandboxes, start/stop/restart an instance, or manage sandbox lifecycle — even if they just say "I need a sandbox" or "restart my instance".
+---
+
+# B2C Sandbox Skill
+
+Only create or delete sandboxes when explicitly requested. Always confirm destructive actions.
+
+Use the `b2c` CLI plugin to manage Salesforce B2C Commerce On-demand sandboxes (ODS). Only create or delete a sandbox if explicitly asked as this may be a billable or destructible action.
+
+> **Tip:** If `b2c` is not installed globally, use `npx @salesforce/b2c-cli` instead (e.g., `npx @salesforce/b2c-cli sandbox list`).
+
+> **Alias:** The `ods` prefix is still supported as a backward-compatible alias (e.g., `b2c ods list` works the same as `b2c sandbox list`).
+
+## Configuration & Authentication
+
+The CLI auto-discovers credentials from `SFCC_*` environment variables (including project `.env`), the selected project-local or shared `dw.json`, and configuration plugins. `package.json` supplies only non-sensitive defaults. **Flags like `--client-id` and `--client-secret` are usually unnecessary** — only pass them to override what's auto-detected. Use `--user-auth` only when you need browser-based login (e.g., no client secret, or interactive use).
+
+Run `b2c setup inspect` to see the resolved configuration and which source provided each value (use `--json` for scripting; secrets stay masked by default). For precedence rules and troubleshooting, see the `b2c-cli:b2c-config` skill.
+
+## Sandbox ID Formats
+
+Commands that operate on a specific sandbox accept two ID formats:
+
+- **UUID**: The full sandbox UUID (e.g., `abc12345-1234-1234-1234-abc123456789`)
+- **Realm-instance**: The realm-instance format (e.g., `zzzv-123` or `zzzv_123`)
+
+The realm-instance format uses the 4-character realm code followed by a dash or underscore and the instance number. When using a realm-instance format, the CLI will automatically look up the corresponding UUID.
+
+## Examples
+
+### List Sandboxes
+
+```bash
+b2c sandbox list
+
+# for realm zzpq with JSON output
+b2c sandbox list --realm zzpq --json
+
+# filter by status and those created by a specific user, only print the columns id,state,hostname
+b2c sandbox list --filter-params 'state=started,creating&createdBy=clavery@salesforce.com' --realm zzpq --columns id,state,hostname
+```
+
+### Create Sandbox
+
+Only create a sandbox if explicitly asked as this may be a billable action.
+
+```bash
+# create in realm zzpq with 4 hour TTL (0 = infinite); json output and wait for completion (this may take 5-10 minutes; timeout is 10 minutes)
+b2c sandbox create --realm zzpq --ttl 4 --json --wait
+
+# create in realm zzpq with large profile (medium is default)
+b2c sandbox create --realm zzpq --profile large
+
+# create without automatic OCAPI/WebDAV permissions
+b2c sandbox create --realm zzpq --no-set-permissions
+
+# use a different client ID for default permissions
+b2c sandbox create --realm zzpq --permissions-client-id my-other-client
+
+# custom OCAPI settings (replaces defaults)
+b2c sandbox create --realm zzpq --ocapi-settings '[{"client_id":"my-client","resources":[{"resource_id":"/code_versions","methods":["get"]}]}]'
+
+# with start/stop scheduler
+b2c sandbox create --realm zzpq --start-scheduler '{"weekdays":["MONDAY","TUESDAY"],"time":"08:00:00Z"}' --stop-scheduler '{"weekdays":["MONDAY","TUESDAY"],"time":"19:00:00Z"}'
+
+# get full log trace output to debug
+b2c sandbox create --realm zzpq --log-level trace
+```
+
+### Get/Start/Stop/Restart/Delete Sandbox
+
+Commands that operate on a specific sandbox support both UUID and realm-instance formats:
+
+```bash
+# Using UUID
+b2c sandbox get abc12345-1234-1234-1234-abc123456789
+b2c sandbox start abc12345-1234-1234-1234-abc123456789
+b2c sandbox stop abc12345-1234-1234-1234-abc123456789
+
+# Using realm-instance format
+b2c sandbox get zzzv-123
+b2c sandbox start zzzv_123
+b2c sandbox stop zzzv-123
+b2c sandbox restart zzzv-123
+b2c sandbox delete zzzv-123 --force
+```
+
+### Clone Sandbox
+
+```bash
+# clone a sandbox (defaults to source profile, 24h TTL)
+b2c sandbox clone create zzzv-123
+
+# clone with a different profile and wait for completion
+b2c sandbox clone create zzzv-123 --target-profile large --wait
+
+# create 3 clones from the same source in one request (1 to many cloning), and wait for all of them
+b2c sandbox clone create zzzv-123 --target-count 3 --wait
+
+# list clones for a sandbox, optionally filtered to a specific 1 to many batch
+b2c sandbox clone list zzzv-123
+b2c sandbox clone list zzzv-123 --batch-id batch-abcd-002-1700000000000-a1b2c3d4
+
+# get details for a specific clone
+b2c sandbox clone get zzzv-123 aaaa-002-1642780893121
+```
+
+### More Commands
+
+See `b2c sandbox --help` for a full list of available commands and options in the `sandbox` topic.

package/content/guidance/b2c-cli/b2c-scapi-custom/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: b2c-scapi-custom
+description: Check custom SCAPI endpoint registration status using the b2c CLI. Use this skill whenever the user needs to verify that their custom API endpoints are registered and working, debug 404 or "endpoint not found" errors on custom APIs, or list custom API endpoints and their deployment status — even if they just say "my custom API returns 404" or "is my endpoint deployed".
+---
+
+# B2C SCAPI Custom APIs Skill
+
+Use the `b2c` CLI plugin to manage SCAPI Custom API endpoints and check their registration status.
+
+When B2C MCP is available, prefer `scapi_custom_apis_get_status` for registration
+and `scapi_schemas_list` for live contracts. For Admin custom API execution, read
+`skill://mcp/scapi/SKILL.md`; fetch the contract through `scapi.request` in the
+program before calling its endpoints. Schema reads need `sfcc.scapi-schemas`;
+execution needs the declared `c_*` scope. Shopper execution is unsupported.
+
+> **Tip:** If `b2c` is not installed globally, use `npx @salesforce/b2c-cli` instead (e.g., `npx @salesforce/b2c-cli scapi custom status`).
+
+## Configuration
+
+Values like `tenantId`, `shortCode`, `clientId`, and `clientSecret` resolve from `dw.json` / `SFCC_*` env vars / the active instance / configuration plugins. Examples below show minimal usage; **add flags only to override configured values** — passing `--client-id`/`--client-secret`/`--tenant-id`/`--short-code` is usually unnecessary. If a required value is missing, the CLI emits an actionable error pointing at the flag, env var, and config key.
+
+Run `b2c setup inspect` to see the resolved configuration and which source provided each value (`--json` for scripting; secrets stay masked by default). For precedence rules and troubleshooting, see the `b2c-cli:b2c-config` skill.
+
+## Tenant ID vs. Organization ID
+
+The tenant ID identifies your B2C Commerce instance. It is **not** the same as the organization ID:
+
+- **Tenant ID**: `zzxy_prd` (the `tenantId` value in dw.json, or `--tenant-id` override)
+- **Organization ID**: `f_ecom_zzxy_prd` (used in SCAPI URLs, has `f_ecom_` prefix)
+
+### Deriving Tenant ID from Hostname
+
+For sandbox instances, derive the tenant ID from the hostname by replacing hyphens with underscores:
+
+| Hostname                                   | Tenant ID  |
+| ------------------------------------------ | ---------- |
+| `zzpq-013.dx.commercecloud.salesforce.com` | `zzpq_013` |
+| `zzxy-001.dx.commercecloud.salesforce.com` | `zzxy_001` |
+| `abcd-dev.dx.commercecloud.salesforce.com` | `abcd_dev` |
+
+For production instances, use your realm and instance identifier (e.g., `zzxy_prd`).
+
+## Examples
+
+### Get Custom API Endpoint Status
+
+```bash
+# list all Custom API endpoints for the configured tenant
+b2c scapi custom status
+
+# list with JSON output
+b2c scapi custom status --json
+
+# target a different tenant than the active config
+b2c scapi custom status --tenant-id zzxy_prd
+```
+
+### Filter by Status
+
+```bash
+# list only active endpoints
+b2c scapi custom status --status active
+
+# list only endpoints that failed to register
+b2c scapi custom status --status not_registered
+```
+
+### Group by Type or Site
+
+```bash
+# group endpoints by API type (Admin vs Shopper)
+b2c scapi custom status --group-by type
+
+# group endpoints by site
+b2c scapi custom status --group-by site
+```
+
+### Customize Output Columns
+
+```bash
+# show extended columns (includes error reasons, sites, etc.)
+b2c scapi custom status --extended
+
+# select specific columns to display
+b2c scapi custom status --columns type,apiName,status,sites
+
+# available columns: type, apiName, apiVersion, cartridgeName, endpointPath, httpMethod, status, sites, securityScheme, operationId, schemaFile, implementationScript, errorReason, id
+```
+
+### Debug Failed Registrations
+
+```bash
+# quickly find and diagnose failed Custom API registrations
+b2c scapi custom status --status not_registered --columns type,apiName,endpointPath,errorReason
+```
+
+### Configuration Overrides
+
+The tenant ID and short code can be overridden via flags or environment variables:
+
+- `--tenant-id` / `SFCC_TENANT_ID` / `tenantId` in dw.json
+- `--short-code` / `SFCC_SHORTCODE` / `shortCode` in dw.json
+
+### More Commands
+
+See `b2c scapi custom --help` for a full list of available commands and options.
+
+## OAuth Scopes (manual token minting)
+
+`b2c scapi custom status` injects the scopes it needs automatically — the domain scope `sfcc.custom-apis` plus the tenant scope `SALESFORCE_COMMERCE_API:<tenant_id>`. You don't pass these for the command itself.
+
+When you mint a token **by hand** (with `b2c auth token` or curl) to call a custom Admin API directly, that injection does **not** happen — you must list both the tenant scope and your scope(s) yourself. `b2c auth token` accepts multiple scopes (repeat `--auth-scope` or comma-separate):
+
+```bash
+# Token for calling a custom Admin API endpoint
+b2c auth token \
+  --auth-scope "SALESFORCE_COMMERCE_API:zzpq_013" \
+  --auth-scope c_my_admin_scope
+```
+
+A token missing the tenant scope returns 403. See `b2c:b2c-custom-api-development` (Testing Reference) for full request examples.
+
+## Related Skills
+
+- `b2c:b2c-custom-api-development` - Creating Custom API endpoints (schema, script, mapping)
+- `b2c-cli:b2c-code` - Deploying and activating code versions (triggers registration)

package/content/guidance/b2c-cli/b2c-scapi-schemas/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: b2c-scapi-schemas
+description: Browse and retrieve SCAPI OpenAPI schema specifications. Use this skill whenever the user needs to list available SCAPI APIs, inspect endpoint paths or request/response shapes, explore data models for products or orders, check which fields an API returns, or understand SCAPI versioning. Also use when looking up API details before building an integration -- even if they just say 'what fields does the product API return' or 'show me the SCAPI endpoints'.
+---
+
+# B2C SCAPI Schemas Skill
+
+Browse standard or tenant-specific SCAPI OpenAPI contracts.
+
+## Tool choice
+
+When B2C MCP is available, prefer offline `scapi_search` for standard Admin and
+Shopper contracts. Read `skill://mcp/scapi/SKILL.md` via resource or `skills_read`
+first; pass `skillRead: true`. Discover method/path/operationId, then selected
+inputs and fields. No credentials or live Schemas API access needed.
+
+Use `scapi_schemas_list` for live schemas, custom attributes, and custom APIs.
+For tenant fields, supply API family/name/version and `includeSchemas: true`.
+Custom-property expansion defaults to true; `expandAll: true` preserves full definitions.
+For large schemas, fetch/filter through code mode as described in the MCP SCAPI skill.
+Use `scapi_custom_apis_get_status` for registration status. Live schema access needs
+`sfcc.scapi-schemas`. Prefer a dedicated task tool for execution, otherwise
+`scapi_execute` supports Admin JSON calls with configured auth/scopes. For custom
+Admin endpoints, fetch the live contract through `scapi.request` in each program
+before calling it; follow the MCP SCAPI skill. Shopper and binary execution are
+unsupported. Use docs tools for semantics
+and limits rather than duplicating contract discovery.
+
+For CLI work, use `b2c scapi schemas list` and
+`b2c scapi schemas get <family> <name> <version>`; both use live access.
+CLI get expands custom properties by default; `--no-expand-custom-properties`
+requests the standard contract. MCP also defaults to expansion; disable it with
+`expandCustomProperties: false`. Known custom fields can be sent through standard
+Admin code-mode requests without a schema read or offline refresh.
+`config_inspect` is the masked MCP equivalent of `b2c setup inspect`.
+Read [CLI examples](references/CLI-EXAMPLES.md) for filters, selective expansion,
+custom properties, and file output. There is no CLI code-mode equivalent.
+
+> **Tip:** If `b2c` is not installed globally, use `npx @salesforce/b2c-cli` instead (e.g., `npx @salesforce/b2c-cli scapi schemas list`).
+
+## Configuration
+
+Values like `tenantId`, `shortCode`, `clientId`, and `clientSecret` resolve from `dw.json` / `SFCC_*` env vars / the active instance / configuration plugins. Examples below show minimal usage; **add flags only to override configured values** — passing `--client-id`/`--client-secret`/`--tenant-id`/`--short-code` is usually unnecessary. If a required value is missing, the CLI emits an actionable error pointing at the flag, env var, and config key.
+
+Run `b2c setup inspect` to see the resolved configuration and which source provided each value (`--json` for scripting; secrets stay masked by default). For precedence rules and troubleshooting, see the `b2c-cli:b2c-config` skill.
+
+## Tenant ID vs. Organization ID
+
+The tenant ID identifies your B2C Commerce instance for SCAPI calls. It is **not** the same as the organization ID:
+
+- **Tenant ID**: `zzxy_prd` (the `tenantId` value in dw.json, or `--tenant-id` override)
+- **Organization ID**: `f_ecom_zzxy_prd` (used in SCAPI URLs, has `f_ecom_` prefix)
+
+### Deriving Tenant ID from Hostname
+
+For sandbox instances, derive the tenant ID from the hostname by replacing hyphens with underscores:
+
+| Hostname                                   | Tenant ID  |
+| ------------------------------------------ | ---------- |
+| `zzpq-013.dx.commercecloud.salesforce.com` | `zzpq_013` |
+| `zzxy-001.dx.commercecloud.salesforce.com` | `zzxy_001` |
+| `abcd-dev.dx.commercecloud.salesforce.com` | `abcd_dev` |
+
+For production instances, use your realm and instance identifier (e.g., `zzxy_prd`).

package/content/guidance/b2c-cli/b2c-scapi-schemas/references/CLI-EXAMPLES.md

@@ -0,0 +1,108 @@
+# SCAPI Schema CLI Examples
+
+
+### List Available Schemas
+
+```bash
+# list all available SCAPI schemas (uses configured tenant)
+b2c scapi schemas list
+
+# list with JSON output
+b2c scapi schemas list --json
+
+# target a different tenant than the active config
+b2c scapi schemas list --tenant-id zzxy_prd
+```
+
+### Filter Schemas
+
+```bash
+# filter by API family (e.g., product, checkout, search)
+b2c scapi schemas list --api-family product
+
+# filter by API name
+b2c scapi schemas list --api-name shopper-products
+
+# filter by status
+b2c scapi schemas list --status current
+```
+
+### Get Schema (Collapsed/Outline - Default)
+
+By default, schemas are output in a collapsed format optimized for context efficiency. This is ideal for agentic use cases and LLM consumption.
+
+```bash
+# get collapsed schema (paths show methods, schemas show names only)
+b2c scapi schemas get product shopper-products v1
+
+# save to file
+b2c scapi schemas get product shopper-products v1 > schema.json
+```
+
+### Get Schema with Selective Expansion
+
+Expand only the parts of the schema you need:
+
+```bash
+# expand specific paths
+b2c scapi schemas get product shopper-products v1 --expand-paths /products,/products/{productId}
+
+# expand specific schemas
+b2c scapi schemas get product shopper-products v1 --expand-schemas Product,ProductResult
+
+# combine expansions
+b2c scapi schemas get product shopper-products v1 --expand-paths /products --expand-schemas Product
+```
+
+### Get Full Schema
+
+```bash
+# get full schema without any collapsing
+b2c scapi schemas get product shopper-products v1 --expand-all
+```
+
+### List Available Paths/Schemas/Examples
+
+Discover what's available in a schema before expanding:
+
+```bash
+# list all paths in the schema
+b2c scapi schemas get product shopper-products v1 --list-paths
+
+# list all schema names
+b2c scapi schemas get product shopper-products v1 --list-schemas
+
+# list all examples
+b2c scapi schemas get product shopper-products v1 --list-examples
+```
+
+### Output Formats
+
+```bash
+# output as YAML
+b2c scapi schemas get product shopper-products v1 --yaml
+
+# output wrapped JSON with metadata (apiFamily, apiName, apiVersion, schema)
+b2c scapi schemas get product shopper-products v1 --json
+```
+
+### Custom Properties
+
+```bash
+# include custom properties (default behavior)
+b2c scapi schemas get product shopper-products v1
+
+# exclude custom properties
+b2c scapi schemas get product shopper-products v1 --no-expand-custom-properties
+```
+
+### Configuration Overrides
+
+The tenant ID and short code can be overridden via flags or environment variables:
+
+- `--tenant-id` / `SFCC_TENANT_ID` / `tenantId` in dw.json
+- `--short-code` / `SFCC_SHORTCODE` / `shortCode` in dw.json
+
+### More Commands
+
+See `b2c scapi schemas --help` for a full list of available commands and options.

package/content/guidance/b2c-cli/b2c-site-import-export/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: b2c-site-import-export
+description: Author, validate, import, and verify B2C Commerce site archives and metadata XML; export selected data for inspection or migration.
+---
+
+# Site Archives
+
+Use `b2c job import` / `b2c job export` to transfer site archives. If `b2c` is
+unavailable, use `npx @salesforce/b2c-cli`.
+
+## Configuration and tool choice
+
+CLI and MCP share resolved configuration: `SFCC_*` variables (including project
+`.env`), project/shared `dw.json`, and plugins. `package.json` provides nonsecret
+defaults. Use `--project-directory` outside the target project. Inspect with
+`b2c setup inspect --json` or MCP `config_inspect`; keep secrets masked. Configured
+values normally make credential flags and manual `dw.json` reads unnecessary.
+For resolution issues, use `b2c-cli:b2c-config`.
+
+No dedicated MCP archive-transfer tool exists. Use the CLI for XML imports and
+exports, including settings absent from SCAPI contracts. MCP `scapi_execute` can
+manage supported Admin fields; a metadata record alone does not prove that
+promotion discounts or targeting rules are configured.
+
+## Import and verify
+
+1. Resolve the target site/catalog and intended change. Include only relevant
+   data in the archive; preserve unrelated settings and requested enabled state.
+2. Author XML in the platform archive layout. Check the relevant XSD with
+   `b2c docs schema <name>` (list names with `--list`), then validate locally.
+3. Import the directory or zip. The command waits by default; `--show-log` shows
+   job logs on failure. Check completion before retrying.
+4. Read back the affected fields. If the API omits them, export the matching data
+   unit and inspect the relevant XML records. A successful job alone is insufficient.
+
+```bash
+b2c job import ./archive --show-log
+b2c job export --site MySite --site-data campaigns_and_promotions --output ./verification
+```
+
+`--site` alone exports all site data; specify `--site-data` for focused work.
+Directory output retains the platform's generated `*_export` root. Do not overwrite
+an existing/applied migration. Exports may contain secrets or unrelated defaults;
+review and trim before committing, preserving XSD-required fields.
+
+## Focused references
+
+- Archive layout and XML workflows: [archive workflows](references/WORKFLOWS.md).
+- Attribute/type XML patterns: [metadata XML](references/METADATA-XML.md).
+- Remote imports, size splitting, and import-set options: [import options](references/IMPORT-OPTIONS.md).
+- Export flags, data units, and compact JSON results: [export reference](../b2c-job/references/EXPORT.md).
+- Ordered migrations, naming, history, and recovery: `b2c-cli:b2c-import-set-migrations`.
+- Service configuration XML: `b2c:b2c-webservices`.
+
+Jobs prefer SCAPI; `--api-backend auto` can fall back to OCAPI on supported
+rejections. Archive transfer uses WebDAV in either case. For job scopes, backend
+selection, and monitoring, use the relevant section of `b2c-cli:b2c-job`.