@salesforce/b2c-dx-mcp 2.1.2 → 3.0.1

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

@@ -0,0 +1,315 @@
+---
+name: b2c-metrics
+description: Query observability metrics from SCAPI Metrics API (CLOSED BETA). Use this skill whenever the user needs request volume, latency distributions, error rates, cache performance, or technical health indicators for SCAPI, OCAPI, MRT, SFRA controllers, or overall system performance. Also use when they want to monitor third-party integrations, sales metrics, or eCDN performance -- even if they just say 'show me SCAPI metrics', 'what is my error rate', or 'check API performance'.
+---
+
+# B2C Metrics Skill
+
+::: danger CLOSED BETA
+The Metrics API is a closed beta feature. It must be enabled for your organization, and its behavior, output, and OAuth scopes may change without notice.
+:::
+
+Use the `b2c metrics` commands to query observability metrics from the SCAPI Metrics API (`observability/metrics/v1`). This provides time-series metrics data for monitoring and analyzing Commerce Cloud technical performance.
+
+> **Tip:** If `b2c` is not installed globally, use `npx @salesforce/b2c-cli`.
+
+## Command Structure
+
+```text
+metrics
+├── list                          - list available metric categories
+├── overall                       - system-wide aggregate metrics
+├── sales                         - sales transaction metrics
+├── ecdn                          - edge CDN performance
+├── third-party                   - third-party service integrations
+│   └── Flags:
+│       └── --third-party-service-id  - filter by service ID
+├── scapi                         - SCAPI request volume/latency/errors/cache
+│   └── Flags:
+│       ├── --api-family          - filter by API family
+│       └── --api-name            - filter by API name
+├── scapi-hooks                   - SCAPI hook execution metrics
+├── mrt                           - Managed Runtime (PWA Kit) metrics
+├── controller                    - SFRA controller performance
+└── ocapi                         - OCAPI request metrics
+    └── Flags:
+        ├── --ocapi-category      - filter by OCAPI category
+        └── --ocapi-api           - filter by OCAPI API
+
+Common Flags (all category commands):
+├── --from / --to / --window      - time window (relative "1h"/"7d" or ISO 8601)
+└── --tags / --no-tags            - enrich series with structured tags (default: true)
+```
+
+## 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.
+
+Relevant overrides:
+
+- `--tenant-id` (alias `--tenant`) / `SFCC_TENANT_ID` / `tenantId`
+- `--short-code` / `SFCC_SHORTCODE` / `shortCode`
+- `--client-id` / `SFCC_CLIENT_ID` / `clientId`
+- `--client-secret` / `SFCC_CLIENT_SECRET` / `clientSecret`
+
+## Requirements
+
+- OAuth client credentials (Metrics API uses client credentials only; `--user-auth` is not supported)
+- API client has `Salesforce Commerce API` role with tenant filter for your instance
+- OAuth scope `sfcc.metrics` (automatically requested by the CLI)
+
+::: danger CLOSED BETA
+The Metrics API is a closed beta feature. It must be enabled for your organization before use.
+:::
+
+## Quick Workflow
+
+1. List available categories (`b2c metrics list`)
+2. Fetch metrics using the category command (e.g., `b2c metrics overall`, `b2c metrics scapi`)
+3. Filter by time window (`--from`/`--to`/`--window` — relative like `1h`/`7d` or ISO 8601) or category-specific filters
+
+## Metric Categories and Commands
+
+| Command                   | Description                               | Category-Specific Filters         |
+| ------------------------- | ----------------------------------------- | --------------------------------- |
+| `b2c metrics overall`     | System-wide aggregate metrics             | None                              |
+| `b2c metrics sales`       | Sales transaction metrics                 | None                              |
+| `b2c metrics ecdn`        | Edge CDN performance                      | None                              |
+| `b2c metrics third-party` | Third-party service integrations          | `--third-party-service-id`        |
+| `b2c metrics scapi`       | SCAPI request volume/latency/errors/cache | `--api-family`, `--api-name`      |
+| `b2c metrics scapi-hooks` | SCAPI hook execution metrics              | None                              |
+| `b2c metrics mrt`         | Managed Runtime (PWA Kit) metrics         | None                              |
+| `b2c metrics controller`  | SFRA controller performance               | None                              |
+| `b2c metrics ocapi`       | OCAPI request metrics                     | `--ocapi-category`, `--ocapi-api` |
+
+::: warning Filter Validation
+Category-specific filters are only accepted by the command they apply to. For example, `--api-family` is only valid for `b2c metrics scapi`. Passing a filter to a different command results in a "Nonexistent flag" error.
+:::
+
+## Discovery Examples
+
+```bash
+# List all categories (uses configured tenant)
+b2c metrics list
+
+# List as JSON
+b2c metrics list --json
+
+# Target a different tenant than the active config
+b2c metrics list --tenant-id zzxy_prd
+```
+
+## Fetch Metrics Examples
+
+```bash
+# Get overall metrics (last 24 hours by default)
+b2c metrics overall
+
+# Get metrics for the last hour
+b2c metrics overall --window 1h
+
+# Get a 1-hour window from 7 days ago
+b2c metrics scapi --from 7d --window 1h
+
+# Get metrics for a specific ISO 8601 time range
+b2c metrics scapi --from "2026-01-25T10:00:00" --to "2026-01-25T11:00:00"
+
+# Get SCAPI metrics filtered by API family
+b2c metrics scapi --api-family products
+
+# Get SCAPI metrics for a specific API
+b2c metrics scapi --api-family products --api-name shopper-products
+
+# Get third-party metrics for a specific service
+b2c metrics third-party --third-party-service-id my-integration
+
+# Get OCAPI metrics filtered by category and API
+b2c metrics ocapi --ocapi-category shop --ocapi-api baskets
+
+# Get controller metrics for the last 6 hours
+b2c metrics controller --window 6h
+
+# Output as JSON
+b2c metrics overall --json
+```
+
+## Time Windows
+
+Metrics commands accept flexible time-window specifications via three flags:
+
+- `--from` — Start bound: relative duration (`1h`, `7d` = that long ago) or ISO 8601 timestamp
+- `--to` — End bound: relative duration or ISO 8601 timestamp
+- `--window` (alias `--for`) — Window duration (`1h`, `30m`, `2d`)
+
+The commands always send an explicit `from`+`to` range, defaulting to a **24-hour window**. The Metrics API pairs a request that omits `to` with its own "now" and enforces a **24-hour maximum window**, so an open-ended `--from` older than a day would always be rejected; filling the window client-side makes the behavior predictable.
+
+**Resolution rules:**
+
+- `--from` + `--to` → used as given (a range wider than 24h is sent as-is; the API returns its own error)
+- `--from` + `--window` → end = start + window (e.g., `--from 7d --window 1h` = a 1-hour window, 7 days ago)
+- `--to` + `--window` → start = end − window
+- `--window` alone → the last `<window>` (end = now, start = now − window)
+- `--from` alone → a 24-hour window forward from it: end = min(start + 24h, now)
+- `--to` alone → a 24-hour window back from it: start = end − 24h
+- Nothing → the last 24 hours (end = now, start = now − 24h)
+
+You can specify at most two of the three flags.
+
+**Examples:**
+
+```bash
+# Last hour
+b2c metrics overall --window 1h
+
+# Last 7 days
+b2c metrics sales --window 7d
+
+# 1-hour window starting 7 days ago
+b2c metrics scapi --from 7d --window 1h
+
+# Specific ISO 8601 range
+b2c metrics scapi --from "2026-01-25T10:00:00" --to "2026-01-25T11:00:00"
+
+# From 24 hours ago until now (--from alone → default 24h window, capped at now)
+b2c metrics overall --from 24h
+```
+
+**Data retention:** The Metrics API retains 30 days of data. If `--from` lands at or beyond the retention edge, the CLI adjusts it forward by a small safety margin (5 minutes) and emits a warning.
+
+**Wire units:** Request bounds are sent to the API as epoch **seconds**; response timestamps come back as epoch **milliseconds** (JS-native)
+
+## Series Tags
+
+By default, the CLI enriches each data series with a structured `tags` object to make filtering and grouping easier. The Metrics API returns series identifiers that pack multiple dimensions into a single string (e.g., `bdpx.product`, `bdpx.product HIT`, `2xx bdpx.host`). The `tags` object unpacks these into discrete key-value pairs.
+
+**Tag contents (three tiers):**
+
+1. **Realm and environment** — always present, derived from the requested tenant/org ID (`f_ecom_bdpx_prd` → `realm=bdpx`, `environment=prd`).
+2. **Per-series dimensions** — parsed from the packed series ID: `apiFamily`, `apiName`, `host`, `cacheStatus`, `statusClass`, `ocapiCategory`, `controller`, `exceptionType`, `aggregation`.
+3. **Applied filters** — any category-specific filter you passed (`--api-family`, etc.) is folded in authoritatively, overriding heuristic guesses.
+
+**Example:**
+
+- `scapi cacheHitRate` series `bdpx.product HIT` → `{"realm":"bdpx","environment":"prd","apiFamily":"product","cacheStatus":"HIT"}`
+
+**Disabling tags:**
+
+Pass `--no-tags` to disable enrichment and return the raw API shape (no `tags` key on series).
+
+**Important framing:**
+
+Tag parsing is a **client-side, best-effort bridge** over the API's current packed-string format. The `realm`/`environment` and applied-filter tiers are always reliable; the string-parsed dimensions are heuristic.
+
+## Response Format
+
+Metrics responses contain an array of metrics. Each metric includes:
+
+- **metricId**: Unique identifier (e.g., `requests_total`)
+- **title**: Human-readable title
+- **description**: What the metric measures
+- **unit**: Unit of measurement (e.g., `requests`, `ms`, `%`); may be empty
+- **dataSeries**: Array of data series, each containing:
+  - **id**: Series identifier
+  - **name**: Series name (e.g., `2xx`, `4xx`, `5xx` for HTTP status codes)
+  - **tags**: Structured dimension tags (enabled by default)
+  - **data**: Array of timestamped values:
+    - **timestamp**: Epoch milliseconds (the CLI normalizes from the API's epoch-seconds wire format)
+    - **value**: Numeric value
+
+With `--json`, the response is wrapped as `{query, data}` where `query` echoes the resolved time bounds and filters:
+
+```json
+{
+  "query": {
+    "category": "overall",
+    "from": "2026-01-25T10:00:00.000Z",
+    "to": "2026-01-25T11:00:00.000Z",
+    "fromEpochSeconds": 1737802800,
+    "toEpochSeconds": 1737806400
+  },
+  "data": [
+    {
+      "metricId": "requests_total",
+      "title": "Total Requests",
+      "description": "Total number of requests",
+      "unit": "requests",
+      "dataSeries": [
+        {
+          "id": "2xx",
+          "name": "2xx",
+          "tags": {
+            "realm": "bdpx",
+            "environment": "prd",
+            "statusClass": "2xx"
+          },
+          "data": [
+            {"timestamp": 1737802800000, "value": 1500},
+            {"timestamp": 1737803400000, "value": 1620}
+          ]
+        }
+      ]
+    }
+  ]
+}
+```
+
+The `query` object always includes both `from`/`to` (and `fromEpochSeconds`/`toEpochSeconds`). When a bound was derived from the 24-hour default window (e.g. `--from` alone, or no time flags), `query.defaultedWindow` is `true`; when `--from` was clamped forward off the retention edge, `query.clampedFrom` is `true`.
+
+## SDK Usage
+
+The Metrics API is also available via the SDK:
+
+```typescript
+import {createMetricsClient} from '@salesforce/b2c-tooling-sdk/clients';
+import {getScapiMetrics, getOverallMetrics, resolveMetricsWindow} from '@salesforce/b2c-tooling-sdk';
+
+// Create client
+const client = createMetricsClient(
+  {
+    shortCode: 'kv7kzm78',
+    tenantId: 'zzxy_prd',
+  },
+  {clientId: 'xxx', clientSecret: 'xxx'},
+);
+
+// Get overall metrics
+// `from`/`to` accept a Date or epoch milliseconds; the SDK converts to
+// the API's epoch-seconds wire format.
+const overallMetrics = await getOverallMetrics(client, 'zzxy_prd', {
+  from: new Date(Date.now() - 7 * 24 * 60 * 60 * 1000), // 7 days ago
+  to: new Date(),
+});
+
+// Get SCAPI metrics with filters
+const scapiMetrics = await getScapiMetrics(client, 'zzxy_prd', {
+  from: new Date(Date.now() - 24 * 60 * 60 * 1000), // 24 hours ago
+  apiFamily: 'product',
+  apiName: 'shopper-products',
+});
+
+// Use resolveMetricsWindow to handle from/to/window resolution
+const window = resolveMetricsWindow({from: '7d', window: '1h'});
+const historicalMetrics = await getScapiMetrics(client, 'zzxy_prd', {
+  from: window.from,
+  to: window.to,
+  apiFamily: 'product',
+});
+```
+
+Available operations: `getOverallMetrics`, `getSalesMetrics`, `getEcdnMetrics`, `getThirdPartyMetrics`, `getScapiMetrics`, `getScapiHooksMetrics`, `getMrtMetrics`, `getControllerMetrics`, `getOcapiMetrics`, `getMetricsByCategory`.
+
+Available helpers: `resolveMetricsWindow({from, to, window})`, `parseMetricsBound(value)`, `enrichMetricsTags(response, category, context)`, `parseSeriesTags({category, metricId, seriesId, context})`.
+
+All operations accept `(client, tenantId, options?)` and return `Promise<MetricsDataResponse>`. Time-window `from`/`to` accept a `Date` or epoch **milliseconds** (converted to the API's epoch-seconds wire format); response data-point timestamps come back in epoch **milliseconds**. The tenant ID may be bare (e.g., `zzxy_prd`) or prefixed (e.g., `f_ecom_zzxy_prd`) — the SDK normalizes it automatically.
+
+## Troubleshooting
+
+- **`tenant-id is required`**: set `--tenant-id` (or `SFCC_TENANT_ID`)
+- **Auth method error**: Metrics API supports client credentials only; remove `--user-auth`
+- **403/unauthorized**: verify API client role and tenant filter include target instance
+- **404/category not enabled**: the category may not be enabled for your organization (closed beta)
+- **503/temporarily unavailable**: metrics service may be temporarily unavailable
+
+For full command reference, use `b2c metrics --help` and see [CLI docs](/cli/metrics) and [Metrics Guide](/guide/metrics).

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

@@ -0,0 +1,206 @@
+---
+name: b2c-mrt
+description: Deploy and manage Managed Runtime (MRT) storefronts using the b2c CLI. Use this skill whenever the user needs to deploy a PWA Kit bundle, manage MRT environments and projects, set environment variables, configure URL redirects, or manage organization connections — even if they just say "deploy my PWA" or "set up a staging environment".
+---
+
+# B2C MRT Skill
+
+Use the `b2c` CLI to manage Managed Runtime (MRT) projects, environments, bundles, and deployments for PWA Kit storefronts.
+
+> **Tip:** If `b2c` is not installed globally, use `npx @salesforce/b2c-cli` instead (e.g., `npx @salesforce/b2c-cli mrt bundle deploy`).
+
+## Configuration & Authentication
+
+The CLI resolves the MRT API key from `MRT_API_KEY` (or `SFCC_MRT_API_KEY`), `dw.json`, `~/.mobify`, or configuration plugins. Project and environment defaults can also come from `package.json` under `b2c` (`mrtProject`, `mrtEnvironment`) or environment variables. `package.json` cannot supply API keys or other secrets. **Flags like `--api-key`, `-p`, and `-e` are usually unnecessary** when defaults are configured — only pass them to override.
+
+Run `b2c setup inspect` to see the resolved configuration and which source provided each value (use `--json` for scripting; keep secrets masked unless the user explicitly requests their values). For precedence rules and troubleshooting, see the `b2c-cli:b2c-config` skill.
+
+### 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`):
+
+- `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.
+- `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).
+
+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.
+- 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.
+
+## Command Structure
+
+```
+mrt
+├── org                          - Organizations and B2C connections
+│   ├── member                   - Organization-level member management
+│   └── cert                     - Custom domain certificates
+├── project                      - Project management
+│   ├── member                   - Team member management
+│   └── notification             - Deployment notifications
+├── env                          - Environment management (incl. clone)
+│   ├── var                      - Environment variables
+│   ├── redirect                 - URL redirects
+│   └── access-control           - Access control headers
+├── bundle                       - Bundle and deployment management (incl. delete)
+└── user                         - User profile and settings
+```
+
+## Quick Examples
+
+### Deploy a Bundle
+
+```bash
+# Push local build to staging
+b2c mrt bundle deploy -p my-storefront -e staging
+
+# Push to production with release message
+b2c mrt bundle deploy -p my-storefront -e production -m "Release v1.0.0"
+
+# Deploy existing bundle by ID
+b2c mrt bundle deploy 12345 -p my-storefront -e production
+
+# Build and upload a v2-format bundle (upload only; deploy the returned ID separately)
+b2c mrt bundle upload-v2 -p my-storefront
+```
+
+### Manage Environments
+
+```bash
+# List environments
+b2c mrt env list -p my-storefront
+
+# Create a new environment
+b2c mrt env create qa -p my-storefront --name "QA Environment"
+
+# Clone an existing environment (-e is the source; positional arg is the new slug)
+b2c mrt env clone qa -p my-storefront -e staging --clone-redirects --clone-env-vars
+
+# Get environment details
+b2c mrt env get -p my-storefront -e production
+
+# Invalidate CDN cache
+b2c mrt env invalidate -p my-storefront -e production
+```
+
+### Environment Variables
+
+```bash
+# List variables
+b2c mrt env var list -p my-storefront -e production
+
+# Set variables
+b2c mrt env var set API_KEY=secret DEBUG=true -p my-storefront -e staging
+
+# Delete a variable
+b2c mrt env var delete OLD_VAR -p my-storefront -e production
+```
+
+### View Deployment History
+
+```bash
+# List bundles in project
+b2c mrt bundle list -p my-storefront
+
+# View deployment history for environment
+b2c mrt bundle history -p my-storefront -e production
+
+# Download a bundle artifact
+b2c mrt bundle download 12345 -p my-storefront
+
+# Delete one or more bundles (uses bulk-delete for >1)
+b2c mrt bundle delete 12345 -p my-storefront
+b2c mrt bundle delete 12345 12346 12347 -p my-storefront --force
+```
+
+### Organization Members and Certificates
+
+Organization members are distinct from project members; they hold a role at the organization level. Custom-domain certificates are organization-scoped and referenced by `b2c mrt env create`/`update`/`clone` via `--certificate-id`.
+
+```bash
+# List, add, update, remove organization members
+b2c mrt org member list --org my-org
+b2c mrt org member add alice@example.com --org my-org --role member --view-all-projects
+b2c mrt org member update alice@example.com --org my-org --no-cert-permission
+b2c mrt org member remove alice@example.com --org my-org
+
+# Manage custom domain certificates
+b2c mrt org cert list --org my-org
+b2c mrt org cert create shop.example.com --org my-org   # output includes the DNS validation record
+b2c mrt org cert get 123 --org my-org
+b2c mrt org cert restart-validation 123 --org my-org
+b2c mrt org cert delete 123 --org my-org
+```
+
+### Project Management
+
+```bash
+# List projects
+b2c mrt project list
+
+# Get project details
+b2c mrt project get -p my-storefront
+
+# List project members
+b2c mrt project member list -p my-storefront
+
+# Add a member
+b2c mrt project member add user@example.com -p my-storefront --role developer
+```
+
+### URL Redirects
+
+```bash
+# List redirects
+b2c mrt env redirect list -p my-storefront -e production
+
+# Create a redirect
+b2c mrt env redirect create -p my-storefront -e production \
+  --from "/old-path" --to "/new-path"
+
+# Clone redirects between environments
+b2c mrt env redirect clone -p my-storefront --source staging --target production
+```
+
+## Configuration
+
+### dw.json
+
+Configure MRT settings in your project's `dw.json`:
+
+```json
+{
+  "mrtProject": "my-storefront",
+  "mrtEnvironment": "staging"
+}
+```
+
+### Environment Variables
+
+```bash
+export MRT_API_KEY=your-api-key
+export MRT_PROJECT=my-storefront
+export MRT_ENVIRONMENT=staging
+export MRT_BACKEND=auto        # auto (default) | legacy | scapi
+```
+
+### ~/.mobify Config
+
+Store your API key in `~/.mobify`:
+
+```json
+{
+  "api_key": "your-mrt-api-key"
+}
+```
+
+## Detailed References
+
+- [Project Commands](references/PROJECT-COMMANDS.md) - Projects, members, and notifications
+- [Environment Commands](references/ENVIRONMENT-COMMANDS.md) - Environments, variables, redirects
+- [Bundle Commands](references/BUNDLE-COMMANDS.md) - Deployments, history, downloads
+
+### More Commands
+
+See `b2c mrt --help` for a full list of available commands and options.

package/node_modules/@salesforce/b2c-agent-plugins/b2c-cli/skills/b2c-mrt/evals/trigger-evals.json

@@ -0,0 +1,12 @@
+[
+  {"query": "I've built my PWA Kit app locally and I need to deploy the bundle to our staging environment. What's the process for getting it up there?", "should_trigger": true},
+  {"query": "I need to set API_KEY and FEATURE_FLAGS environment variables on our production MRT environment for the my-storefront project. How do I do that?", "should_trigger": true},
+  {"query": "We're setting up our project for the first time and need to create a QA environment, connect it to our B2C instance, and configure some URL redirects. Walk me through the setup.", "should_trigger": true},
+  {"query": "I need to push a new build of our headless storefront to the staging target and then promote it to production once QA signs off. What's the workflow for managing bundles across environments?", "should_trigger": true},
+  {"query": "We're onboarding a new team and they need their own project and organization set up for their PWA storefront. I also need to create dev and staging environments under that project. How do I set all that up?", "should_trigger": true},
+  {"query": "Our production storefront needs a set of URL redirects — about 50 of them — for an SEO migration. I have the list in a file. What's the best way to push those redirect rules to the environment and verify they're active?", "should_trigger": true},
+  {"query": "How do I set up the local development proxy for my PWA Kit app so API requests go to the right sandbox?", "should_trigger": false},
+  {"query": "I need to upload my SFRA cartridge code to a sandbox instance. What command do I use for that?", "should_trigger": false},
+  {"query": "I'm trying to configure my Storefront Next composable app to connect to a B2C instance. Where do I put the API credentials and site ID in the project config?", "should_trigger": false},
+  {"query": "My local PWA dev server is throwing CORS errors when calling the Shopper API. How do I fix the proxy configuration in my ssr.js file?", "should_trigger": false}
+]