@salesforce/b2c-dx-mcp 2.1.2 → 3.0.1

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

@@ -0,0 +1,112 @@
+---
+name: b2c-sites
+description: List storefront sites, check site status, and manage cartridge paths on B2C Commerce instances using the b2c CLI. Use this skill whenever the user needs to discover site IDs, check which storefronts are online or offline, get site configuration as JSON, or view/modify the ordered cartridge path for a site or Business Manager. Also use when the user needs site information for scripting, CI/CD pipelines, or as input to other commands — even if they just say "what sites do I have" or "add this cartridge to my site".
+---
+
+# B2C Sites Skill
+
+Use the `b2c` CLI plugin to list and manage storefront sites on Salesforce B2C Commerce instances.
+
+> **Tip:** If `b2c` is not installed globally, use `npx @salesforce/b2c-cli` instead (e.g., `npx @salesforce/b2c-cli sites list`).
+
+## Configuration & Authentication
+
+The CLI auto-discovers the target instance and 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 `--server`, `--client-id`, and `--client-secret` are usually unnecessary** — only pass them to override what's auto-detected.
+
+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.
+
+## Commands
+
+### `b2c sites list`
+
+Lists all sites on a B2C Commerce instance, showing site ID, display name, and storefront status.
+
+```bash
+# list all sites on the configured instance
+b2c sites list
+
+# list sites on a specific server
+b2c sites list --server my-sandbox.demandware.net
+
+# list sites with JSON output (useful for parsing/automation)
+b2c sites list --json
+
+# use a specific instance from config
+b2c sites list --instance production
+
+# enable debug logging
+b2c sites list --debug
+```
+
+### Cartridge Path Management
+
+Manage the ordered list of active cartridges on a site. The singular alias `sites cartridge` also works.
+
+```bash
+# list the cartridge path for a storefront site
+b2c sites cartridges list --site-id RefArch
+
+# list the Business Manager cartridge path
+b2c sites cartridges list --bm
+
+# add a cartridge to the beginning of a site's path (default)
+b2c sites cartridges add plugin_applepay --site-id RefArch
+
+# add a cartridge to the end
+b2c sites cartridges add plugin_applepay --site-id RefArch --position last
+
+# add a cartridge after a specific cartridge
+b2c sites cartridges add plugin_applepay --site-id RefArch --position after --target app_storefront_base
+
+# add a cartridge to Business Manager
+b2c sites cartridges add bm_extension --bm --position first
+
+# remove a cartridge from a site
+b2c sites cartridges remove old_cartridge --site-id RefArch
+
+# replace the entire cartridge path
+b2c sites cartridges set "app_storefront_base:plugin_applepay:plugin_wishlists" --site-id RefArch
+
+# JSON output for automation
+b2c sites cartridges list --site-id RefArch --json
+```
+
+When OCAPI direct permissions for `/sites/*/cartridges` are unavailable, cartridge commands automatically fall back to site archive import/export. Business Manager (`--bm`) updates always use site archive import.
+
+**Key flags (inherited from InstanceCommand):**
+
+| Flag         | Short | Description                                |
+| ------------ | ----- | ------------------------------------------ |
+| `--server`   | `-s`  | B2C instance hostname (env: `SFCC_SERVER`) |
+| `--json`     |       | Output full site data as JSON              |
+| `--instance` |       | Named instance from config                 |
+| `--debug`    |       | Enable debug logging                       |
+
+**Output columns:** ID, Display Name, Status (storefront_status).
+
+**JSON output** returns the full site objects including all properties (useful for extracting channel IDs, custom preferences, and other site metadata not shown in the table).
+
+Site reads and cartridge-path writes run over SCAPI (the `site/sites` API) when `shortCode`, `tenantId`, and the `sfcc.sites` / `sfcc.sites.rw` scopes are configured. `auto` temporarily falls back to deprecated OCAPI on safe SCAPI rejections, and writes can fall back again to site archive import when direct APIs are unavailable.
+
+## Common Use Cases
+
+**Finding site IDs for other commands:** Many commands (e.g., site import/export) require a site ID. Use `sites list` to discover valid IDs:
+
+```bash
+b2c sites list
+# then use the ID in other commands
+b2c site-import upload --site RefArch ...
+```
+
+**Checking site status:** The status column shows the storefront status (online/offline) for each site, useful for verifying deployment state.
+
+**Scripting and automation:** Use `--json` to get machine-readable output for CI/CD pipelines:
+
+```bash
+b2c sites list --json | jq '.data[].id'
+```
+
+## Related Skills
+
+- **b2c-config** -- configure instances, credentials, and debug connection issues
+- **b2c-site-import-export** -- import/export site archives and metadata XML

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

@@ -0,0 +1,182 @@
+---
+name: b2c-slas
+description: Create, update, and manage SLAS (Shopper Login and API Access Service) clients using the b2c CLI. Use this skill whenever the user needs to provision a SLAS client, update OAuth scopes, rotate client secrets, get a shopper access token, or configure shopper authentication for headless, PWA, or Storefront Next (SFNext) storefronts — even if they just say "I need a shopper token" or "set up auth for my storefront".
+---
+
+# B2C SLAS Skill
+
+Use the `b2c` CLI plugin to manage SLAS (Shopper Login and API Access Service) API clients and credentials.
+
+> **Important:** SLAS is for **shopper** (customer) authentication used by storefronts and headless commerce. For **admin** tokens (OCAPI, Admin APIs), use `b2c auth token` - see [b2c-config skill](../b2c-config/SKILL.md).
+
+> **Tip:** If `b2c` is not installed globally, use `npx @salesforce/b2c-cli` instead (e.g., `npx @salesforce/b2c-cli slas client list`).
+
+## Configuration
+
+Values like `tenantId`, `shortCode`, `slasClientId`, and `slasClientSecret` 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 these as flags 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.
+
+Relevant overrides:
+
+- `--tenant-id` / `SFCC_TENANT_ID` / `tenantId`
+- `--short-code` / `SFCC_SHORTCODE` / `shortCode`
+- `--slas-client-id` / `SFCC_SLAS_CLIENT_ID` / `slasClientId`
+- `--slas-client-secret` / `SFCC_SLAS_CLIENT_SECRET` / `slasClientSecret`
+
+Commands that target an existing client (`get`, `update`, `delete`, and `open`) use the configured `slasClientId` when their positional client ID is omitted. A positional client ID takes precedence over configuration.
+
+## When to Use
+
+Common scenarios requiring SLAS client management:
+
+- **Testing Custom APIs**: Create a client with custom scopes (e.g., `c_loyalty`) to test your Custom API endpoints
+- **PWA/Headless Development**: Configure clients for composable storefronts
+- **Integration Testing**: Create dedicated test clients with specific scope sets
+
+## Examples
+
+### List SLAS Clients
+
+```bash
+# list all SLAS clients for the configured tenant
+b2c slas client list
+
+# JSON output
+b2c slas client list --json
+
+# target a different tenant than the active config
+b2c slas client list --tenant-id abcd_123
+```
+
+### Get SLAS Client Details
+
+```bash
+# get details for the configured SLAS client
+b2c slas client get
+
+# override the configured client ID
+b2c slas client get my-client-id
+```
+
+### Create SLAS Client
+
+```bash
+# create a new SLAS client with default scopes (auto-generates UUID client ID)
+b2c slas client create --channels RefArch --default-scopes --redirect-uri http://localhost:3000/callback
+
+# create with a specific client ID and custom scopes
+b2c slas client create my-client-id --channels RefArch --scopes sfcc.shopper-products,sfcc.shopper-search --redirect-uri http://localhost:3000/callback
+
+# create a public client
+b2c slas client create --channels RefArch --default-scopes --redirect-uri http://localhost:3000/callback --public
+
+# create client without auto-creating tenant (if you manage tenants separately)
+b2c slas client create --channels RefArch --default-scopes --redirect-uri http://localhost:3000/callback --no-create-tenant
+
+# output as JSON (useful for capturing the generated secret)
+b2c slas client create --channels RefArch --default-scopes --redirect-uri http://localhost:3000/callback --json
+```
+
+Note: By default, the tenant is automatically created if it doesn't exist.
+
+**Warning:** Use `--scopes` (plural) for client scopes, NOT `--auth-scope` (singular). The `--auth-scope` flag is a global authentication option for OAuth scopes.
+
+### Create Client for Custom API Testing
+
+When testing a Custom API that requires custom scopes:
+
+```bash
+# Create a private client with custom scope for testing
+# Replace c_my_scope with your API's custom scope from schema.yaml
+b2c slas client create \
+  --channels RefArch \
+  --default-scopes \
+  --scopes "c_my_scope" \
+  --redirect-uri http://localhost:3000/callback \
+  --json
+
+# Output includes client_id and client_secret - save these for token requests
+```
+
+**Important:** The custom scope in your SLAS client must match the scope defined in your Custom API's `schema.yaml` security section.
+
+### Get a Shopper Token
+
+Use `b2c slas token` to obtain a shopper access token for API testing. The `--site-id` is specific to the request and must be provided per call.
+
+The command applies shared HTTP middleware, including headers from `SFCC_EXTRA_HEADERS`
+(a JSON object) or `--extra-headers`, to authorization, login, and token requests.
+JSON output nests token fields under `response` (for example, `.response.accessToken`).
+For authentication failures, use `--log-level debug` to capture HTTP status and the SLAS response correlation ID.
+
+```bash
+# Guest token with auto-discovery (finds first public SLAS client)
+b2c slas token --site-id RefArch
+
+# Registered customer token
+b2c slas token --site-id RefArch --shopper-login user@example.com --shopper-password secret
+
+# JSON output (includes refresh token, expiry, usid, etc.)
+b2c slas token --site-id RefArch --json
+
+# Use token in a subsequent API call
+TOKEN=$(b2c slas token --site-id RefArch)
+curl -H "Authorization: Bearer $TOKEN" "https://$SHORTCODE.api.commercecloud.salesforce.com/..."
+
+# Override the SLAS client explicitly (e.g., targeting a private client for client_credentials flow)
+b2c slas token --site-id RefArch --slas-client-id my-client --slas-client-secret sk_xxx
+
+# Registered customer token against a private client (registered login is always PKCE-protected;
+# the client secret is sent as Basic auth in addition to the PKCE code_verifier)
+b2c slas token --site-id RefArch --slas-client-id my-client --slas-client-secret sk_xxx \
+  --shopper-login user@example.com --shopper-password secret
+```
+
+### Update SLAS Client
+
+```bash
+# update the configured client's display name
+b2c slas client update --name "New Name"
+
+# override the configured client ID and rotate its secret
+b2c slas client update my-client-id --secret new-secret-value
+
+# add scopes (appends to existing by default)
+b2c slas client update my-client-id --scopes sfcc.shopper-baskets
+
+# replace scopes instead of appending
+b2c slas client update my-client-id --scopes sfcc.shopper-baskets --replace
+
+# replace channels
+b2c slas client update my-client-id --channels RefArch,SiteGenesis --replace
+```
+
+### Delete SLAS Client
+
+```bash
+# delete the configured SLAS client
+b2c slas client delete
+
+# override the configured client ID
+b2c slas client delete my-client-id
+```
+
+### Open SLAS Client
+
+```bash
+# open the configured SLAS client in the Admin UI
+b2c slas client open
+
+# override the configured client ID
+b2c slas client open my-client-id
+```
+
+### More Commands
+
+See `b2c slas --help` for a full list of available commands and options in the `slas` topic.
+
+## Related Skills
+
+- `b2c:b2c-custom-api-development` - Creating Custom APIs that require SLAS authentication
+- `b2c-cli:b2c-scapi-custom` - Checking Custom API registration status

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

@@ -0,0 +1,169 @@
+---
+name: b2c-webdav
+description: List, upload, download, and manage files on B2C Commerce instances via WebDAV. Use this skill whenever the user needs to upload files to IMPEX directories, download exports from an instance, list remote files, create or delete directories, zip or unzip files on the server, manage file transfers to sandboxes, or browse instance file systems — even if they just say "upload a file to the instance" or "check what's in the IMPEX folder".
+---
+
+# B2C WebDAV Skill
+
+Use the `b2c` CLI plugin to perform WebDAV file operations on Salesforce B2C Commerce instances. This includes listing files, uploading, downloading, and managing files across different WebDAV roots.
+
+> **Tip:** If `b2c` is not installed globally, use `npx @salesforce/b2c-cli` instead (e.g., `npx @salesforce/b2c-cli webdav ls`).
+
+## MCP equivalent
+
+Prefer `webdav_list`, `webdav_get`, and `webdav_put` when available for one-directory
+listings, exact text reads, and single-file transfers. `webdav_get` uses HTTP byte
+ranges (`offset`, `maxBytes`, returned `size`/`nextOffset`); `outputPath` downloads a
+whole file. `webdav_put` accepts `content` or `sourcePath`; parent must exist,
+replacement needs `overwrite: true`. Local paths are on the MCP host, relative to
+`projectDirectory`. Transfers cap at 64 MiB; no prerequisite skill read.
+Use `cartridge_deploy` for local cartridge selection/mapping. Keep the CLI for
+recursive transfers, mkdir, delete, ZIP/UNZIP, or extra flags not exposed by MCP.
+
+## Configuration & Authentication
+
+The CLI auto-discovers the target instance and 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 `--server`, `--client-id`, `--client-secret`, `--username`, and `--password` are usually unnecessary** — only pass them to override what's auto-detected.
+
+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.
+
+## WebDAV Roots
+
+The `--root` flag specifies the WebDAV directory:
+
+- `impex` (default) - Import/Export directory
+- `temp` - Temporary files
+- `cartridges` - Code cartridges
+- `realmdata` - Realm data
+- `catalogs` - Product catalogs
+- `libraries` - Content libraries
+- `static` - Static resources
+- `logs` - Application logs
+- `securitylogs` - Security logs
+
+## Examples
+
+### List Files
+
+```bash
+# list files in the default IMPEX root
+b2c webdav ls
+
+# list files in a specific path
+b2c webdav ls src/instance
+
+# list files in the cartridges root
+b2c webdav ls --root=cartridges
+
+# list files with JSON output
+b2c webdav ls --root=impex --json
+```
+
+### Download Files
+
+```bash
+# download a file from IMPEX (default root)
+b2c webdav get src/instance/export.zip
+
+# download to a specific local path
+b2c webdav get src/instance/export.zip -o ./downloads/export.zip
+
+# download from a specific root
+b2c webdav get customerror.log --root=logs
+
+# output file content to stdout
+b2c webdav get src/instance/data.xml -o -
+```
+
+### Upload Files
+
+```bash
+# upload a file to IMPEX
+b2c webdav put ./local-file.zip src/instance/
+
+# upload to a specific root
+b2c webdav put ./my-cartridge.zip --root=cartridges
+```
+
+### Create Directories
+
+```bash
+# create a directory in IMPEX
+b2c webdav mkdir src/instance/my-folder
+
+# create a directory in a specific root
+b2c webdav mkdir my-folder --root=temp
+```
+
+### Delete Files
+
+```bash
+# delete a file
+b2c webdav rm src/instance/old-export.zip
+
+# delete from a specific root
+b2c webdav rm old-file.txt --root=temp
+```
+
+### Delete Cartridges
+
+To delete cartridges from a code version, use the `cartridges` root with the path format `{code-version}/{cartridge-name}`:
+
+```bash
+# delete a cartridge from a code version
+b2c webdav rm v25_1_0/app_mysite --root=cartridges
+
+# delete multiple cartridges
+b2c webdav rm v25_1_0/app_mysite --root=cartridges
+b2c webdav rm v25_1_0/int_myintegration --root=cartridges
+
+# list cartridges in a code version first
+b2c webdav ls v25_1_0 --root=cartridges
+```
+
+**Important:** The path is `{code-version}/{cartridge-name}`, not `/cartridges/{code-version}/...`. The `--root=cartridges` (or `-r cartridges`) flag sets the WebDAV root.
+
+### Zip/Unzip Remote Files
+
+```bash
+# create a zip archive of a remote directory
+b2c webdav zip src/instance/my-folder
+
+# extract a remote zip archive
+b2c webdav unzip src/instance/archive.zip
+```
+
+### Import-Set Managed State
+
+Do not manually script marker files when the goal is to apply a local set of site import/export archives once. Use the higher-level command:
+
+```bash
+b2c job import-set
+```
+
+To start over without deleting the previous history, use a new set ID and keep using it on subsequent runs:
+
+```bash
+b2c job import-set --set-id migrations-reset-20260818
+```
+
+To reset the default history in place, remove it and rerun the import set:
+
+```bash
+b2c webdav rm --root=impex b2c-cli/import-sets/migrations
+b2c job import-set
+```
+
+For a custom set ID, replace the final `migrations` path segment with that ID. Resetting in place permanently forgets which archives succeeded and makes every current archive pending again, so only use it when every archive is safe to reapply. `--break-lock` is for recovery and does not reset history.
+
+For the canonical workflow, naming convention, retry behavior, and recovery rules, use the `b2c-cli:b2c-site-import-export` skill's **Apply an Ordered, Idempotent Import Set** section.
+
+### More Commands
+
+See `b2c webdav --help` for a full list of available commands and options in the `webdav` topic.
+
+## Related Skills
+
+- `b2c-cli:b2c-logs` - Filtered log retrieval, search, and real-time tailing (preferred for log exploration)
+- `b2c-cli:b2c-code` - Higher-level code deployment (preferred for cartridge upload)
+- `b2c-cli:b2c-site-import-export` - Canonical site archive and idempotent import-set guidance
+- `b2c-cli:b2c-job` - Run and monitor jobs

package/content/guidance/b2c-ops/b2c-checkout-triage/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: b2c-checkout-triage
+description: Investigate B2C Commerce checkout or payment failures, increased failed orders, or falling order volume. Compare bounded order evidence, integration logs and affected data; separate payment failures from traffic and reporting gaps.
+---
+
+# Checkout and payment triage
+
+Outcome: quantify the observed symptom, localize a likely subsystem, and produce
+an actionable handoff. Do not create test orders, charge/refund payments, change
+order status, or modify production data as part of inspection.
+
+## Scope and impact
+
+Use `config_inspect` (CLI: `b2c setup inspect`) and confirm site, UTC time window,
+reported symptom, and comparison period. Ask for missing values. Preserve the
+same target/window in all calls. No cartridge source is required.
+
+"Orders down" can mean less traffic, checkout errors, abandoned baskets, payment
+declines, or delayed reporting. Failed order records alone do not measure all
+checkout attempts or conversion. Do not force every incident into a payment cause.
+Record breadth, duration, workaround, and owner. Follow the team's severity and
+update process for live customer impact; do not wait for exact counts to escalate.
+
+## Access and tools
+
+| Signal                       | Preferred path                                                   | Limit / fallback                                                                                                                                                               |
+| ---------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Payment/custom logs          | `logs_list_files`, then `logs_get_recent` on discovered prefixes | Start with 20 relevant entries; samples are not full-window counts. CLI: `b2c logs list` / `b2c logs get`.                                                                     |
+| Order records                | Discover Admin Orders contracts via code mode                    | A response enum does not establish supported status filters. See [failed-order triage](skill://b2c-ops/b2c-order-failure-triage/SKILL.md) for the demonstrated OCAPI fallback. |
+| Affected products/attributes | SCAPI Admin product reads; live schemas for tenant custom fields | Compare known IDs and selected fields. Shopper contracts are reference-only in this runtime.                                                                                   |
+| Suspected import/integration | [b2c-job-health](skill://b2c-ops/b2c-job-health/SKILL.md)        | Read the chosen job's log and check its actual data effects.                                                                                                                   |
+| Traffic/latency context      | Code mode Metrics where enabled; CLI `b2c metrics`               | Feature access and scopes vary. CIP/CCAC trends: `cip_discover` / `cip_query` after [CIP guidance](skill://mcp/cip/SKILL.md), with freshness/coverage limits. CLI fallback: `b2c cip`.                                                          |
+
+Read `skill://mcp/scapi/SKILL.md` before code mode; prefer dedicated tools when
+available. Discover operations/required fields before requests, compose bounded
+reads, and return selected evidence with errors and continuation. Read only the
+conditional reference needed; native assistants can use installed skill names.
+
+## Checks and decisions
+
+1. Quantify with comparable windows and explicit denominators. Label unavailable
+   counts unknown, a zero-denominator ratio undefined, and sampled products as
+   sample frequencies. Preserve query errors; never convert them to zero failures.
+2. Find recurring integration errors, timestamps, and safe correlation IDs. Avoid
+   customer/payment data in output. A gateway response may point to upstream data,
+   configuration, provider availability, or input validation; test the alternatives.
+3. Compare a failing and healthy input. Discover relevant custom attributes if
+   needed; do not dump whole product/order payloads into context.
+4. Identify the writer of a suspect field, if evidence warrants it. Review job
+   execution/logs and real change records. Coincident modification timestamps
+   alone do not identify a regressing deployment.
+
+## Mitigation and recovery
+
+Reproduction, reruns, deployments, or data changes require explicit authorization
+and a suitable environment. After an intervention, compare the same signals over
+a fresh equivalent interval; verify business behavior and distinguish observation
+delay from confirmed recovery. Operator handoff can be complete without a code fix.
+
+## Escalation and handoff
+
+Report impact/site/window, counts and sample limits, safe correlation IDs, log
+excerpts, affected input, hypotheses, access gaps, and next owner/update. Continue
+with logs if order access is blocked. Route provider evidence to the integration
+owner, custom defects to the developer, and suspected platform failures to
+Salesforce Support. Use native `b2c-production-triage` or the MCP
+[case template](skill://b2c-ops/b2c-production-triage/references/escalation.md).
+Prepare a draft; submitting a case/message requires authorization.

package/content/guidance/b2c-ops/b2c-job-health/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: b2c-job-health
+description: Review B2C Commerce scheduled jobs during routine operations or investigate failed jobs, missing runs, stale imports, and green executions with incomplete results. Check logs and business data before proposing a rerun.
+---
+
+# Job health
+
+Outcome: identify which scheduled work completed its business purpose, what is
+late/failed/partial, and whether intervention or a developer handoff is needed.
+
+## Scope and impact
+
+Resolve instance/site and a fixed UTC interval with `config_inspect` (CLI:
+`b2c setup inspect`). Obtain the expected jobs, schedule/timezone, and intended
+updates from the user or available configuration. No matching execution is
+"missing" only when a run was actually expected.
+Record the business deadline, affected data/sites, and owner. For material impact,
+use the team's incident severity/update process; a routine review need not declare
+an incident. Do not invent impact from a red status alone.
+
+## Access and tools
+
+| Evidence                     | Preferred MCP path                                               | CLI fallback                                                 |
+| ---------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------ |
+| Execution history and steps  | `builtin/job-execution-review` / `builtin/job-execution-inspect` in code mode                                     | `b2c job search`; check `--help` for filters                 |
+| Known execution log          | `webdav_get` with the returned `logFilePath` | `b2c job log JOB_ID EXECUTION_ID`                            |
+| Expected product/data change | Discover the relevant Admin operation and select affected fields | Relevant CLI/data workflow if supported                      |
+| Code-version clues           | `builtin/code-version-inspect` in code mode                  | `b2c code list`; modification time is not activation history |
+
+Read `skill://mcp/scapi/SKILL.md` before code mode. Use its search/discovery
+contract; project/instance context belongs on tool calls. Authentication is
+managed. Do not export tokens or use ambient fetch inside code mode.
+
+## Checks and decisions
+
+1. Describe/run `builtin/job-execution-review` for a small page in the interval. For routine review, include
+   successful and unfinished runs, not only failures. Compare against the expected
+   schedule; inspect relevant steps/duration and time zone before calling a run late.
+2. For failure-only review, reuse `builtin/failed-job-triage`: inspect with
+   `codemode.describe`, then `codemode.run` with fixed `from`, `to`, and `limit`
+   (maximum 3). Continue using its returned offset/window only as needed. Keep
+   errors and partial results. The snippet returns selected execution fields,
+   not `stepExecutions`; use `builtin/job-execution-inspect` if steps matter.
+   A POST search can be blocked by Safety Mode;
+   explain the denied read operation rather than weakening policy.
+3. Read the selected execution's `logFilePath` with `webdav_get`; it accepts
+   `/Sites/LOGS/...` paths. Inspect size via `webdav_list`; read a bounded range
+   and continue via byte `nextOffset` only as needed. Download to `outputPath`
+   for local analysis. Use recent-log tools for filtering and watches, not an
+   exact raw-file read. [Job-log details](references/job-logs.md).
+4. Identify the first relevant fault, processed/skipped records, and which steps
+   actually ran. Job transitions can continue after errors; do not assume every
+   later step was skipped. Green status can also hide skipped or incomplete work.
+5. Verify a small sample of the expected data and one healthy comparison. Correlate
+   changes without claiming causation from matching timestamps alone.
+
+## Mitigation and recovery
+
+Before an authorized rerun, check for an active execution, partial writes,
+idempotency, duplicate exports/messages, and rollback limits. Inspect uncertain
+outcomes before retrying; never replay a whole code-mode program after writes.
+Verify business data as well as terminal job status after intervention.
+
+## Escalation and handoff
+
+Summarize job/execution/step IDs, impact/window, status, affected inputs, log
+evidence, observed data, unknowns, and next owner/action. Use the administrator
+for custom schedule/access issues, developer for custom-step defects, and
+Salesforce Support for suspected platform/system-job problems. Native skill:
+`b2c-production-triage`; MCP [case template](skill://b2c-ops/b2c-production-triage/references/escalation.md).
+No source access is required; case submission needs authorization.
+
+CLI-specific detail when needed: native `b2c-job`, MCP
+`skill://b2c-cli/b2c-job/SKILL.md`, or the
+[Jobs reference](https://salesforcecommercecloud.github.io/b2c-developer-tooling/cli/jobs).

package/content/guidance/b2c-ops/b2c-job-health/references/job-logs.md

@@ -0,0 +1,21 @@
+# Job execution logs
+
+Use `logFilePath` from the selected execution, not a guessed file or only its
+status. `builtin/job-execution-inspect` returns the exact path and step details.
+`webdav_get` accepts Sites-relative paths and returned `/Sites/LOGS/...` paths.
+Use `webdav_list` on the parent directory for sizes when needed.
+
+Read a bounded byte range; reuse `nextOffset` to preserve UTF-8 boundaries.
+`size` is total bytes, not characters. Null continuation means end; a few pages
+do not establish whole-file or interval coverage. Files may grow/rotate between
+reads. Download to a new `outputPath` for local analysis of a large file.
+
+For recent parsed entries or ongoing watches, use `logs_get_recent` / `logs_watch`.
+These tools parse and filter; an empty result does not prove an empty raw log.
+Use `webdav_get` when parsing loses useful context. CLI alternative when needed:
+`b2c job log JOB_ID EXECUTION_ID`, preserving the selected instance.
+
+Never run the job just to obtain its previous log. A deleted/expired log, missing
+path, permission failure, and no matching recent parsed entries are different
+outcomes. Preserve the error and suggest the smallest next check. If no file is
+available, request the selected execution's log from Business Manager.