@salesforce/b2c-dx-mcp 3.2.1 → 3.4.0

package/node_modules/@salesforce/b2c-agent-plugins/storefront-next/skills/sfnext-create-vertical/references/COMPONENT-AUTHORING.md

@@ -1,206 +0,0 @@
-# Component authoring standards
-
-## Vertical extensions — existing components always have priority
-
-When building a vertical extension (`src/extensions/<vertical>/`), check what the **base template already renders** before creating anything new.
-
-**The rule**: if a base component already renders equivalent content at the same location, do NOT create an extension component that duplicates it. Extensions add what is missing — they never recreate what already exists.
-
-### Decision gate (run this before creating any extension component)
-
-1. **Find the base component** — read the relevant route and trace what components it renders.
-2. **Check every rendered section** — does the base already render this content (description, accordion, badge, banner, etc.)?
-3. **If yes** — use a UITarget slot on the existing content, or customise it via token/variant. Do not create a parallel extension component that renders the same thing.
-4. **If no** — the extension is justified. Register it at the correct UITarget.
-
-### Concrete examples
-
-```
-❌ WRONG — base ProductView already renders a description accordion ("Overview").
-           ProductDetailsExtension adds its own "Overview" section → duplicate.
-
-✅ CORRECT — base already renders description + adapter sections (Specifications, Care Instructions…).
-             ProductDetailsExtension only adds the two sections the base does NOT have:
-             Shipping & Returns, Warranty Info.
-```
-
-```
-❌ WRONG — base renders product title in ProductInfo.
-           The vertical extension renders product title again in a brand stamp.
-
-✅ CORRECT — brand stamp adds ONLY the brand line ("<BRAND> · <tagline>")
-             above the existing ProductInfo, not the title.
-```
-
-**Do not create duplicates unless the user explicitly asks for them.**
-The cost of a duplicate is paid on every page load, in every test, in every Figma sync. The correct
-approach is almost always a UITarget slot or a CSS token override.
-
----
-
-## Extend before create — mandatory check before any new component
-
-Before writing a single line of a new component, answer these questions in order:
-
-1. **Does an existing component already do this?** Search `src/components/` and `src/components/ui/` by name and by behaviour.
-2. **Can an existing component cover this with a new CVA variant?** A new `variant` or `size` value is always cheaper than a new file.
-3. **Can composition cover this?** Wrap an existing component in a thin composite rather than duplicating it.
-4. **Only if all three answers are no** — create a new component.
-
-```tsx
-// ❌ WRONG — creating BrandPrimaryButton when Button already exists
-export function BrandPrimaryButton({ children }: Props) {
-  return <button className="bg-[#1e6f3a] text-white ...">{children}</button>
-}
-
-// ✅ CORRECT — new CVA variant on the existing Button primitive
-// In src/components/ui/button.tsx, add to buttonVariants:
-brand: 'bg-primary text-primary-foreground hover:bg-primary/90',
-
-// ✅ CORRECT — thin composite when behaviour differs
-export function AddToCartButton(props: AddToCartButtonProps) {
-  return <Button variant="default" {...props}>Add to Cart</Button>
-}
-```
-
----
-
-## Multi-vertical extension governance
-
-When a vertical needs to extend a component, choose the right maintenance model upfront:
-
-```
-Does the change only affect visual tokens (color, font, spacing)?
-  └─ YES → CVA variant on the existing component. Token system handles most of this via brand.css.
-  └─ NO  → Is this structural change needed by only one vertical?
-              └─ YES → src/extensions/<vertical-name>/ via UITarget injection. Never touch core.
-              └─ NO  → Will another vertical need the same structural pattern?
-                          └─ YES → Add a slot/renderProp to the BASE component.
-                                   Each vertical provides its own implementation of that slot.
-                          └─ UNSURE → Build vertical-specific first (extensions/).
-                                      Promote to base when a second vertical needs the same pattern.
-```
-
-**Never add vertical-specific logic (if brandA / if brandB) to a shared component.** If you find yourself writing that, the slot/render-prop pattern is missing from the base component.
-
----
-
-## Layer model — know which layer you are in before writing a line
-
-| Layer | Where | What lives here |
-|-------|-------|----------------|
-| **Primitive** | `src/components/ui/` | Shadcn-sourced, Radix-backed primitives. Pure rendering, no business logic, no SCAPI. |
-| **Composite** | `src/components/` | Assembled from primitives. May accept loaders/data props. No direct SCAPI calls. |
-| **Page / Route** | `src/routes/` | Loader, action, error boundary, page layout. Fetches data, passes to composites. |
-| **Extension** | `src/extensions/<name>/` | Opt-in additions via UITarget. Self-contained. Never modify core from inside an extension. |
-
-Do not skip layers. A page component should not build raw `<button>` elements. A primitive should not call `useFetcher`.
-
----
-
-## Primitives (`src/components/ui/`)
-
-These files come from Shadcn and must be treated as infrastructure, not business components.
-
-**When extending a primitive:**
-- Do not edit the primitive file directly (it may be refreshed from Shadcn upstream).
-- Create a wrapper component in `src/components/` instead.
-- Re-export from the wrapper so imports stay consistent.
-
-**Allowed changes to primitive files:**
-- Adding a new CVA variant that maps to an existing semantic token — that's it.
-
----
-
-## CVA — class-variance-authority
-
-All styled components with more than one visual state use CVA.
-
-```tsx
-import { cva, type VariantProps } from 'class-variance-authority'
-import { cn } from '@/lib/utils'
-
-const badgeVariants = cva(
-  'inline-flex items-center rounded-full border px-2.5 py-0.5 text-xs font-semibold transition-colors',
-  {
-    variants: {
-      variant: {
-        default: 'border-transparent bg-primary text-primary-foreground',
-        secondary: 'border-transparent bg-secondary text-secondary-foreground',
-        destructive: 'border-transparent bg-destructive text-white',
-        outline: 'text-foreground',
-      },
-    },
-    defaultVariants: { variant: 'default' },
-  }
-)
-```
-
-Rules:
-- Every variant value must use semantic token classes only. No raw hex.
-- `cn()` from `@/lib/utils` is always the last call — enables external className overrides.
-- Export the `*Variants` function alongside the component so it can be reused in related components.
-
----
-
-## data-slot attributes
-
-Every presentational element in a component tree must carry a `data-slot` attribute for testing and Figma tracing.
-
-```tsx
-// ✅
-<div data-slot="product-tile">
-  <div data-slot="product-tile-image">…</div>
-  <div data-slot="product-tile-body">…</div>
-</div>
-```
-
-The slot name should be kebab-case and match the component name.
-
----
-
-## TypeScript requirements
-
-- All props are explicitly typed. No `any`.
-- Use `React.ComponentProps<'element'>` to extend native element props.
-- Discriminated unions for components with mutually exclusive prop shapes.
-- `asChild` pattern (via Radix `Slot`) for polymorphic rendering — never accept an `as` prop.
-
----
-
-## Copyright header
-
-Every `.ts` / `.tsx` file must begin with the Apache 2.0 header. ESLint enforces this.
-
----
-
-## Naming conventions
-
-| Thing | Convention | Example |
-|-------|-----------|---------|
-| Component files | kebab-case | `product-tile.tsx` |
-| Component exports | PascalCase | `ProductTile` |
-| Variant objects (CVA) | camelCase + "Variants" suffix | `productTileVariants` |
-| data-slot values | kebab-case matching component | `product-tile` |
-| Hook files | kebab-case prefixed with "use-" | `use-cart.ts` |
-
----
-
-## Storybook requirement
-
-Every new component in `src/components/` must have a `.stories.tsx` file.
-- One story per CVA variant.
-- Default export: `{ title: 'Components/ComponentName', component: ComponentName }`.
-- Include a snapshot story (`name: 'Snapshot'`) so CI can diff it.
-
----
-
-## Accessibility checklist
-
-Before marking a component complete, verify:
-
-- [ ] Interactive elements are native `<button>` or `<a>`, not `<div onClick>`.
-- [ ] All inputs have an associated `<Label>` using `htmlFor` (or Radix `Label` with `asChild`).
-- [ ] Focus ring uses `focus-visible:ring-ring focus-visible:ring-[3px]` — matches the button primitive.
-- [ ] Color information is not communicated by color alone (pair with icon or text).
-- [ ] Motion: wrap animations in `prefers-reduced-motion` if not handled by Tailwind's `motion-safe:` prefix.

package/node_modules/@salesforce/b2c-agent-plugins/storefront-next/skills/sfnext-create-vertical/references/PROJECT-STRUCTURE.md

@@ -1,43 +0,0 @@
-# Project Structure Reference
-
-Storefront Next is a pnpm monorepo with a React Router v7 retail application.
-
-## Key architecture
-
-- **Monorepo:** pnpm workspaces, packages under `packages/`
-- **Main app:** `packages/template-retail-rsc-app/` — React Router v7 retail application
-- **Build tool:** Vite with SSR
-- **Routing:** React Router v7 file-based routing
-- **Styling:** Tailwind CSS v4, utility-first, token-driven
-- **Commerce:** Salesforce Commerce Cloud (SCAPI) integration
-
-## Theme file layout (the vertical surface)
-
-```
-src/theme/
-├── tailwind.css            # CSS variable → Tailwind utility bridge
-└── tokens/
-    ├── brand.css           # ← the ONLY file that changes per vertical
-    ├── core.css            # semantic roles (bg, fg, card, primary, …)
-    ├── header.css          # header / footer surfaces
-    ├── status.css          # destructive / warning / success / info
-    ├── swatch.css          # variant-selector swatch UI
-    └── components.css       # payment + cart-specific tokens
-```
-
-## App file organization
-
-- **Routes:** `src/routes/` (file-based, mapped in `src/routes.ts`)
-- **Components (composite):** `src/components/`
-- **Components (Shadcn primitives):** `src/components/ui/`
-- **Extensions:** `src/extensions/<name>/`
-- **Providers:** `src/providers/`
-- **Config / fixtures:** `src/config/`
-
-## Common commands
-
-- `pnpm dev` — start the dev server
-- `pnpm build` — production build
-- `pnpm typecheck` — TypeScript checking
-- `pnpm lint` — ESLint (runs with `--max-warnings 0`)
-- `pnpm test-storybook:snapshot:agent` — Storybook snapshot diff

package/node_modules/@salesforce/b2c-agent-plugins/storefront-next/skills/sfnext-create-vertical/references/TOKEN-SYSTEM.md

@@ -1,130 +0,0 @@
-# Token System Reference
-
-## The one rule that overrides everything else
-
-**Never use a raw hex value, RGB value, or hardcoded color in any component or CSS file.**
-Always use a semantic Tailwind utility that maps to a CSS variable. The variables are defined in
-`src/theme/tokens/` and bridged to Tailwind utilities in `src/theme/tailwind.css`.
-
-```tsx
-// ✅ correct
-<div className="bg-primary text-primary-foreground" />
-
-// ❌ wrong — breaks dark mode, breaks vertical theming, breaks Figma sync
-<div style={{ background: '#000000', color: '#ffffff' }} />
-<div className="bg-black text-white" />
-```
-
-## Token files and what they own
-
-| File | Owns |
-|------|------|
-| `src/theme/tokens/core.css` | Background, foreground, card, popover, primary, secondary, muted, accent, border, input, ring, separator, rating, charts, sidebar, focus helpers |
-| `src/theme/tokens/brand.css` | Brand palette (`--brand-black`, `--brand-white`, `--brand-gray-*`, `--brand-primary`). **This is the only file that changes per vertical.** |
-| `src/theme/tokens/header.css` | Header background/foreground, header menu surfaces, footer. Dark header = black bg / white text. |
-| `src/theme/tokens/status.css` | Destructive, warning, success, info, status-positive/warning/critical, active-bg |
-| `src/theme/tokens/swatch.css` | Swatch color, labeled, pill — variant selector UI only |
-| `src/theme/tokens/components.css` | Payment provider colors, cart-specific tokens |
-
-## Semantic token meanings — use the right one
-
-### Text colors
-| Token class | When to use |
-|-------------|-------------|
-| `text-foreground` | Default body text, headings |
-| `text-muted-foreground` | Secondary labels, helper text, placeholder, metadata |
-| `text-primary-foreground` | Text on a `bg-primary` surface (e.g. button label) |
-| `text-secondary-foreground` | Text on a `bg-secondary` surface |
-| `text-accent-foreground` | Text on a `bg-accent` surface (hover chips, tags) |
-| `text-destructive` | Error text, destructive action labels |
-| `text-card-foreground` | Text inside card surfaces |
-
-### Background colors
-| Token class | When to use |
-|-------------|-------------|
-| `bg-background` | Page/app background |
-| `bg-primary` | CTAs, filled buttons, strong actions |
-| `bg-secondary` | Secondary button fill, subtle section bg |
-| `bg-muted` | Skeleton, disabled surfaces, subtle fills |
-| `bg-accent` | Hover state, selected chip, tag bg |
-| `bg-card` | Card and tile surfaces |
-| `bg-popover` | Dropdown, tooltip, modal backgrounds |
-
-### Borders
-| Token class | When to use |
-|-------------|-------------|
-| `border-border` | Standard dividers, list separators — uses alpha so it renders correctly on ANY surface color |
-| `border-border-subtle` | Form inputs, card edges — slightly more visible |
-| `border-input` | Input field border specifically |
-| `ring-ring` | Focus ring on interactive elements |
-
-**Never use `border-black`, `border-gray-*`, or `divide-gray-*`.** Use `border-border` or `border-border-subtle`.
-
-### Header/navigation surfaces
-| Token class | When to use |
-|-------------|-------------|
-| `bg-[--header-background]` | Header band background |
-| `text-[--header-foreground]` | Header text and icons |
-| `bg-[--header-menu-background]` | Mega/dropdown menu panel |
-| `bg-[--footer-background]` | Footer background |
-
-### Status and feedback
-| Token class | When to use |
-|-------------|-------------|
-| `text-destructive` / `bg-destructive` | Delete, remove, error state |
-| `bg-warning-bg` / `text-warning-foreground` | Caution messages |
-| `text-status-positive` | In-stock, success indicator |
-| `text-status-critical` | Out of stock, error badge |
-| `bg-active-bg` / `text-active-foreground` | Active/authorized badge |
-
-## Dark mode rules
-
-**Do not write `dark:bg-black` or any dark: hardcoded color.**
-Dark mode is fully handled by `.dark` overrides in `src/theme/tokens/core.css` and other token files.
-Using semantic classes automatically gets the correct dark value.
-
-```tsx
-// ✅ correct — dark mode is automatic
-<div className="bg-card text-card-foreground" />
-
-// ❌ wrong
-<div className="bg-white dark:bg-gray-900 text-black dark:text-white" />
-```
-
-The only valid `dark:` usage is for classes that reference another semantic token:
-
-```tsx
-// ✅ valid dark: override pattern
-className="dark:bg-input/30 dark:border-input"
-```
-
-## What changes per vertical — and what does not
-
-### Changes (vertical-specific, lives in `src/theme/tokens/brand.css`)
-- Brand palette values (`--brand-black`, `--brand-primary`, `--brand-gray-*`)
-- Logo treatment (`--header-logo-filter`)
-- Brand-specific component tokens
-
-### Does NOT change (shared, lives in core/header/status/swatch/components)
-- Semantic token names and their Tailwind utility names
-- Dark mode pairing rules
-- Component variant logic (CVA)
-- Border alpha values
-- Status and feedback colors
-
-**Never override core.css, header.css, status.css, swatch.css, or components.css to create a vertical.**
-Only `brand.css` changes between verticals.
-
-## Tailwind utility bridge
-
-All token → Tailwind utility mappings are defined in `src/theme/tailwind.css`.
-If a CSS variable exists in a token file but has no Tailwind utility in `tailwind.css`, add it there
-before using it in a component. Do not use arbitrary `[--variable-name]` syntax for variables that
-should be in the bridge.
-
-```css
-/* src/theme/tailwind.css — add new token bridge entries here */
---color-my-new-token: var(--my-new-token);
-```
-
-Then use `bg-my-new-token` in components.

package/node_modules/@salesforce/b2c-agent-plugins/storefront-next/skills/sfnext-create-vertical/references/TROUBLESHOOTING.md

@@ -1,34 +0,0 @@
-# Troubleshooting Reference
-
-## Token not found in Tailwind utilities
-If a CSS variable exists in a token file but has no Tailwind utility in `tailwind.css`:
-- Open `src/theme/tailwind.css`.
-- Add a bridge entry: `--color-my-new-token: var(--my-new-token);`.
-- Then use `bg-my-new-token` in components — never the `bg-[--my-new-token]` arbitrary syntax.
-
-## Colors look wrong in dark mode
-- You probably hardcoded a color (`bg-white`, `text-black`, raw hex) instead of using a semantic token.
-- Replace with the semantic utility (`bg-background`, `text-foreground`, etc.). Dark mode is handled by `.dark` overrides in the token files automatically.
-
-## Vertical changes leak into other verticals
-- You edited a shared token file (`core.css`, `header.css`, `status.css`, `swatch.css`, `components.css`). Move the change into `brand.css`.
-- Or you added `if (vertical)` logic to a shared component. Replace it with a CVA variant, a slot/render-prop on the base, or an extension.
-
-## Component already exists
-If a scan finds an existing component that covers the need:
-- Add a new CVA variant instead of creating a new component.
-- Wrap in a thin composite if behaviour differs.
-- Never duplicate.
-
-## Local pages won't render without SCAPI
-- Use fixtures: create `src/config/<vertical>-fixtures.ts` and short-circuit the `_app.tsx` and `_app.product.$productId.tsx` loaders during vertical development.
-- Restore the real SCAPI calls once credentials are available.
-
-## Linter errors after changes
-Run `pnpm lint:fix` first. If errors remain, check:
-- Missing copyright header (required on every `.ts`/`.tsx` file).
-- Raw hex value or hardcoded Tailwind color — replace with a semantic token class.
-- Missing `data-slot` attribute on a component root.
-
-## Snapshot tests fail after visual changes
-Run `pnpm test-storybook:snapshot:agent -- --updateSnapshot` to update baselines after intentional visual changes.

package/node_modules/@salesforce/b2c-agent-plugins/storefront-next/skills/sfnext-custom-apis/SKILL.md

@@ -1,221 +0,0 @@
----
-name: sfnext-custom-apis
-description: End-to-end workflow for consuming custom SCAPI endpoints from a Storefront Next project — adding them as typed clients via `b2c sfnext scapi add custom`, discovering their schema, and calling them from loaders/actions/useScapiFetcher. Use this skill whenever the user wants to call a custom API from their Storefront Next app, gets a 404 or 401 when calling a custom endpoint from their sfnext loader, needs to add a custom API as a typed client in their storefront, asks about the full workflow from custom API cartridge to sfnext consumption, or says 'custom API in storefront next'. Also use when they ask how createApiClients exposes custom API methods or how to use useScapiFetcher with a custom endpoint. NOT for writing the custom API cartridge files (schema.yaml/script.js) from scratch — see b2c:b2c-custom-api-development. NOT for just checking registration status — see b2c-cli:b2c-scapi-custom.
----
-
-# Custom APIs in Storefront Next
-
-This skill covers the end-to-end workflow for implementing and consuming custom SCAPI endpoints from a Storefront Next project.
-
-## Overview
-
-Custom APIs let you define your own REST endpoints on B2C Commerce. In a Storefront Next project, you call these from loaders and actions just like standard SCAPI clients — with full type safety.
-
-### End-to-End Workflow
-
-```
-Create custom API    →  Deploy & register  →  Add typed client  →  Discover schema  →  Call from loader
-(cartridge)             (b2c code deploy)     (sfnext scapi add)   (scapi schemas)     (createApiClients)
-```
-
-## Step 1: Create the Custom API
-
-A custom API consists of three files in a cartridge:
-
-```
-my-cartridge/cartridge/rest-apis/my-loyalty-api/
-├── schema.yaml     # OpenAPI 3.0 schema (endpoints, params, responses)
-├── api.json        # API metadata (version, security scheme)
-└── script.js       # Implementation (controller script)
-```
-
-For full details on writing these files, see the `b2c:b2c-custom-api-development` skill.
-
-**Key choices that affect the client:**
-
-| Choice | Impact |
-|--------|--------|
-| Directory name (`my-loyalty-api`) | Becomes the API name for `scapi add` |
-| `type` in api.json (`shopper` or `admin`) | Determines auth scheme and whether `siteId` is required |
-| Paths in schema.yaml | Become the methods on the typed client |
-
-## Step 2: Deploy and Register
-
-Deploy the cartridge and verify the custom API is registered:
-
-```bash
-# deploy the cartridge
-b2c code deploy ./my-cartridge --activate
-
-# verify registration
-b2c scapi custom status
-```
-
-A successful registration shows `status: active` for your endpoints. If you see `not_registered`, debug with:
-
-```bash
-b2c scapi custom status --status not_registered --columns type,apiName,endpointPath,errorReason
-```
-
-See `b2c-cli:b2c-scapi-custom` for full diagnostics.
-
-## Step 3: Add as Typed Client
-
-Once registered, add the custom API to your Storefront Next project:
-
-```bash
-b2c sfnext scapi add custom my-loyalty-api v1
-```
-
-This generates typed client code. The client becomes available as:
-
-```typescript
-const clients = createApiClients(context);
-clients.myLoyaltyApi.getPoints({...});
-```
-
-## Step 4: Discover the API Shape
-
-Use schema browsing to understand your custom API's endpoints and response types:
-
-```bash
-# list endpoints
-b2c scapi schemas get custom my-loyalty-api v1 --list-paths
-
-# expand a specific endpoint
-b2c scapi schemas get custom my-loyalty-api v1 \
-  --expand-paths /loyalty/points/{customerId}
-```
-
-This shows you the exact parameter names and response shape to use in your loader.
-
-## Step 5: Call from Loaders and Actions
-
-### Calling from a Loader (Shopper API)
-
-```typescript
-import { createApiClients } from '@/lib/api-clients';
-
-export function loader({ params, context }: LoaderFunctionArgs) {
-    const clients = createApiClients(context);
-    return {
-        loyaltyPoints: clients.myLoyaltyApi.getPoints({
-            params: {
-                path: { customerId: params.customerId },
-                query: { siteId: context.siteId }
-            }
-        }).then(({ data }) => data),
-    };
-}
-```
-
-### Calling from an Action (Mutation)
-
-```typescript
-import { data } from 'react-router';
-import { createApiClients } from '@/lib/api-clients';
-
-export async function action({ request, context }: ActionFunctionArgs) {
-    const formData = await request.formData();
-    const clients = createApiClients(context);
-
-    try {
-        await clients.myLoyaltyApi.redeemPoints({
-            params: {
-                path: { customerId: formData.get('customerId') as string },
-                query: { siteId: context.siteId },
-                body: { points: Number(formData.get('points')) }
-            }
-        });
-        return data({ success: true });
-    } catch (error) {
-        return data({ success: false, error: error.message }, { status: 400 });
-    }
-}
-```
-
-### Using useScapiFetcher (Interactive)
-
-For on-demand fetching triggered by user interactions:
-
-```typescript
-import { useScapiFetcher } from '@/hooks/use-scapi-fetcher';
-
-export function useLoyaltyPoints(customerId: string) {
-    const parameters = useMemo(
-        () => ({
-            params: {
-                path: { customerId },
-                query: { siteId: getSiteId() }
-            }
-        }),
-        [customerId]
-    );
-
-    const fetcher = useScapiFetcher(
-        'myLoyaltyApi',
-        'getPoints',
-        parameters
-    );
-
-    return {
-        points: fetcher.data,
-        isLoading: fetcher.state === 'loading',
-        refresh: () => fetcher.load(),
-    };
-}
-```
-
-## Step 6: Debug Issues
-
-| Issue | Cause | Solution |
-|-------|-------|----------|
-| Client property not available | Forgot `sfnext scapi add` | Run `b2c sfnext scapi add custom <name> <version>` |
-| 404 from custom endpoint | API not registered | Check `b2c scapi custom status`; redeploy with `--activate` |
-| 401 Unauthorized | Wrong security scheme | Shopper APIs use ShopperToken; Admin APIs use BearerToken |
-| Missing `siteId` error | Shopper custom APIs require siteId | Always include `siteId` in query params for Shopper APIs |
-| Schema returns empty | API not yet registered | Deploy and activate the cartridge first, then browse schemas |
-| Types outdated after schema change | Stale generated types | Re-run `b2c sfnext scapi add custom <name> <version> --force` |
-
-## Custom API Client Naming
-
-The API directory name maps to a camelCase property on `createApiClients()`:
-
-| Directory Name | Client Property | Example Call |
-|---------------|-----------------|-------------|
-| `my-loyalty-api` | `clients.myLoyaltyApi` | `clients.myLoyaltyApi.getPoints({...})` |
-| `order-status` | `clients.orderStatus` | `clients.orderStatus.getStatus({...})` |
-| `inventory-check` | `clients.inventoryCheck` | `clients.inventoryCheck.checkStock({...})` |
-
-## Shopper vs Admin Custom APIs
-
-| Aspect | Shopper API | Admin API |
-|--------|-------------|-----------|
-| Auth scheme | ShopperToken (SLAS) | BearerToken (Account Manager) |
-| Requires `siteId` | Yes | No |
-| Called from | Storefront loaders/actions | Admin tools, batch jobs |
-| Typical use | Customer-facing features | Back-office operations |
-
-Most Storefront Next custom APIs are **Shopper** type since they serve storefront pages.
-
-## Common Pitfalls
-
-| Pitfall | Problem | Solution |
-|---------|---------|----------|
-| Using admin auth for a shopper endpoint | 401 errors in storefront context | Set `type: "shopper"` in api.json |
-| Forgetting to redeploy after schema changes | Stale endpoints | Redeploy cartridge and re-add client with `--force` |
-| Not including `siteId` for shopper APIs | Request rejected | Always pass `siteId` in query params |
-| Calling custom API before registration completes | Intermittent 404s | Wait for `status: active` in `b2c scapi custom status` |
-
-## Related Skills
-
-- `storefront-next:sfnext-scapi-management` - Managing typed clients (add/remove/list)
-- `storefront-next:sfnext-data-fetching` - Loader/action/useScapiFetcher patterns
-- `b2c:b2c-custom-api-development` - Creating the custom API cartridge (schema + script + mapping)
-- `b2c-cli:b2c-scapi-custom` - Checking custom API registration status
-- `b2c-cli:b2c-scapi-schemas` - Schema discovery commands
-- `b2c-cli:b2c-code` - Deploying and activating code versions
-
-## Reference Documentation
-
-- [Workflow Examples](references/WORKFLOW-EXAMPLES.md) - Complete end-to-end worked examples

package/node_modules/@salesforce/b2c-agent-plugins/storefront-next/skills/sfnext-custom-apis/evals/trigger-evals.json

@@ -1,12 +0,0 @@
-[
-  {"query": "My custom API endpoint returns 404 when I try to call it from my storefront next app using createApiClients. The cartridge is deployed but something isn't connecting. How do I debug this end-to-end?", "should_trigger": true},
-  {"query": "I deployed a custom loyalty-points API and now I need to add it to my storefront next project with b2c sfnext scapi add custom and then call it from my account page loader. Walk me through the full workflow.", "should_trigger": true},
-  {"query": "I have a custom shopper API that I can call from Postman but when I call it through createApiClients in my storefront next loader I get a 401 unauthorized. How do I fix the auth scheme mismatch between my api.json and the sfnext context?", "should_trigger": true},
-  {"query": "What's the complete end-to-end workflow for making a custom SCAPI endpoint callable as a typed client from my storefront next loaders? I have the cartridge registered and want to know the sfnext-specific steps.", "should_trigger": true},
-  {"query": "After running b2c sfnext scapi add custom my-inventory-api v1, how do I use the generated typed client in my storefront next route loader to call the checkStock endpoint?", "should_trigger": true},
-  {"query": "I need to write the schema.yaml OpenAPI spec and script.js controller for a new custom API that returns product recommendations based on browsing history.", "should_trigger": false},
-  {"query": "How do I check whether my custom API endpoints are registered and active on my sandbox instance? I just want to see the registration status.", "should_trigger": false},
-  {"query": "I need to call the standard shopperProducts.getProduct API from my product detail page loader. What's the pattern for using createApiClients with the built-in clients?", "should_trigger": false},
-  {"query": "I want to add the shopper-search standard SCAPI to my storefront next project so I can build a search page.", "should_trigger": false},
-  {"query": "How do I deploy my custom API cartridge code version to the sandbox and activate it using the b2c CLI?", "should_trigger": false}
-]