> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fluid.app/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> For new direct REST integrations, use the v2026-04 surfaces. The @fluid-app FairShare SDK continues to use its own published public-v2025-06 contract.
> Authenticate with the header Authorization: Bearer <token>; public storefront read endpoints require no auth.
> Lists use cursor pagination via the page[cursor] and page[limit] query params; follow meta.pagination.next_cursor until it is null.
> When the same operation exists on more than one surface, use the newest: dated API versions are newer than unversioned ones, and later dates win (v2026-04 > v2025-06 > unversioned v0/v1.1). Fall back to a legacy or unversioned operation only when no newer versioned equivalent exists — the company-v0 notes below list the known superseded operations. /api/company/v1 and /api/v1/... paths are documented in no spec here and must never be used (/api/v1.1/... is distinct and documented in company-v0). Use page/per_page offset pagination only where a spec documents it — in practice the unversioned company-v0 admin surface; every versioned surface uses cursor pagination.
> The OpenAPI specs under api-reference/ are the authoritative contracts; prefer them over prose when in doubt. api-reference/storefront-v2026-04.yaml covers the v2026-04 storefront surface (/api/v202604/... paths); api-reference/auth-v0.yaml covers the unversioned auth surface (/api/... paths — authentication, MFA, social auth, and token exchange); api-reference/checkout-v2026-04.yaml covers the v2026-04 checkout surface (/api/checkout/v2026-04/... paths — carts, cart auth, discounts, items, subscriptions, orders, enrollments, and store config); api-reference/public-v2025-06.yaml covers the Public SDK surface used by the @fluid-app FairShare SDK, including its parallel cart lifecycle, browser integrations, versioned payment callbacks, unversioned public utilities, and the cart price-override operation; api-reference/payment-v2026-04.yaml covers the v2026-04 payment gateway admin surface (/api/payment/v2026-04/... paths, bearer-authenticated — gateway CRUD, gateway purchase/authorize/$0-verify, transaction list/show and capture/void/credit, and merchant payment configuration); api-reference/payments-v2026-04.yaml covers the v2026-04 cart payment surface (/api/payments/v2026-04/carts/{cart_token}/... paths, authenticated by the cart token in the path with no bearer — payment-method selection, VGS card tokenization, 3D Secure verification, and PayPal/Braintree/Klarna/Apple Pay flows); api-reference/commerce-v2026-04.yaml covers the v2026-04 commerce order-editing surface (/api/v202604/orders/{order_id}/edits paths, bearer-authenticated — post-checkout order edits that atomically insert items and add adjustments/discounts, with an optional dry-run preview); api-reference/webhooks-v0.yaml covers the unversioned webhooks surface (/api/... paths — webhook registration, delivery payloads, callback registrations, company events, and webhook/callback schemas); api-reference/company-v0.yaml covers the legacy unversioned company admin surface (/api/... paths, bearer-authenticated — company settings and management, customers, users, roles, subscription plans, subscription bundles, subscriptions, media, pages, catch-ups, inventory levels, domains, agreements, and admin order actions). company-v0 caveats: it is the legacy v0 admin contract and its lists use flat page/per_page offset pagination, which is expected there despite the general cursor-pagination rule; where an operation exists in both company-v0 and a versioned spec, prefer the versioned spec — the subscriptions lifecycle (list/create/show/update, cancel, pause, reactivate, resume, retry, skip, failed-cycle-waiver, discounts) and subscription bundles are superseded by checkout-v2026-04, and company pages/media CRUD plus the public pages, categories, products, and media list endpoints are superseded by storefront-v2026-04. Subscription plan management (/api/subscription_plans, resource-wrapped {"subscription_plan": {...}} bodies) exists only in company-v0. api-reference/analytics-v2026-04.yaml covers the v2026-04 Home dashboard analytics surface (/api/v202604/analytics/dashboard/... paths, bearer-authenticated — read-only endpoints for the Home > Overview, Home > Live, and Home > Field tabs, each accepting an optional country ISO alpha-2 query param that scopes aggregations to a single country).
> api-reference/analytics-v0.yaml covers the unversioned analytics surface that backs the fluid-admin Traffic tab (/api/analytics/... and /api/analytics/traffic/... paths, bearer-authenticated — the legacy shares/views/visitors summary plus traffic overview, ranked campaigns, sources, geographies, flows, and per-rep breakdown, all sharing one reporting-period contract).
> Successful responses wrap the resource payload alongside a top-level integer status and a meta object.
> Portal Definition authoring edits and synchronizes the portal JSON resource graph. Widget Package authoring builds either a company-owned or Droplet-owned Remote DOM package. These are separate contracts; do not imply that one defines the other.
> For Widget Package worker code, use only @fluid-app/portal-sdk/widgets/worker. Use only the Portal Definition and Widget Package workflows and public entry points documented here; do not infer support for undocumented surfaces.
> Every portal function and declarative capability used by a widget must appear in that widget's uses array. Use the same typed function value in uses; do not invent capability-name strings.
> Widget styling must use the portal's semantic theme variables for colors, typography, spacing, radii, borders, focus, and charts whenever a token represents the visual decision. Do not create a separate light or dark palette or duplicate theme controls as widget properties.
> Prefer worker-safe Fluid UI components exported by @fluid-app/portal-sdk/widgets/worker when they fit the interaction. When no exported component fits, use semantic HTML, accessible behavior, and the portal theme variables.
> A Portal Definition push updates the remote working definition. A portal version is an immutable snapshot, and activation is a separate live release operation.

# Runtime, styling, and accessibility

> Build Remote DOM widgets that remain resilient, theme-aware, accessible, and safe.

Widget workers render through host-owned Remote DOM elements. Use only elements exported by the installed Widget Worker SDK, and use [`DeclarativeCapabilityUse`](/portal-widgets/reference/widget-worker-sdk/interfaces/DeclarativeCapabilityUse) for non-callable capabilities.

## Design for worker constraints

* Keep worker-boundary values JSON-serializable.
* Do not assume browser or host application APIs are available.
* Declare every portal function and capability in `uses`.
* Reuse runtime resources across prop updates and clean them up on unmount.
* Handle missing and malformed inputs without crashing.

Review every package before publication.

## Prefer Fluid-provided UI

Use worker-safe Fluid components when they match the interaction. They preserve familiar portal behavior, accessibility, spacing, and theme usage across Widget Packages.

Import them only from `@fluid-app/portal-sdk/widgets/worker`:

```tsx theme={null}
import { SearchSort } from "@fluid-app/portal-sdk/widgets/worker";

<SearchSort
  searchValue={query}
  placeholder="Search products"
  sortOptions={[
    { label: "Newest", value: "newest" },
    { label: "Name", value: "name" },
  ]}
  sortValue={sort}
  onSearchChange={setQuery}
  onSortChange={setSort}
/>;
```

The public worker UI includes:

* [`SearchSort`](/portal-widgets/reference/widget-worker-sdk/functions/SearchSort) for a combined search and sort control;
* [`FluidSpacerWidget`](/portal-widgets/reference/widget-worker-sdk/functions/FluidSpacerWidget) for portal-consistent spacer behavior.

Do not recreate a Fluid-provided control only to change its appearance. Use its public props and place it within a themed widget layout. If no Fluid component fits, use semantic HTML, accessible interaction patterns, and the portal theme variables below.

## Use portal theme semantics

Theme compliance is a widget requirement. Widgets share a portal with built-in and third-party content, so each widget must use the active portal theme wherever the theme represents the visual decision. Do not ship a separate light or dark palette.

Keep styles in the generated project's root `styles.css`. Scope selectors to the widget. Do not depend on global `body` styles.

The portal supplies semantic CSS variables to the widget. Use the variable that describes the role, not the current rendered color.

| Purpose                            | Variables                                                                                                       |
| ---------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| Page and card surfaces             | `--background`, `--foreground`, `--card`, `--card-foreground`, `--popover`, `--popover-foreground`              |
| Primary actions                    | `--primary`, `--primary-foreground`                                                                             |
| Secondary and highlighted content  | `--secondary`, `--secondary-foreground`, `--accent`, `--accent-foreground`                                      |
| Supporting and destructive content | `--muted`, `--muted-foreground`, `--destructive`, `--destructive-foreground`                                    |
| Borders, controls, and focus       | `--border`, `--input`, `--ring`                                                                                 |
| Typography                         | `--font-body`, `--font-header`, `--text-xs`, `--text-sm`, `--text-base`, `--text-lg`, `--text-xl`, `--text-2xl` |
| Layout shape                       | `--spacing`, `--radius-sm`, `--radius-md`, `--radius-lg`, `--radius-xl`                                         |
| Charts                             | `--chart-1`, `--chart-2`, `--chart-3`, `--chart-4`, `--chart-5`                                                 |

Use paired foreground variables with their surfaces. For example, text on `--primary` uses `--primary-foreground`, and text on `--card` uses `--card-foreground`.

```css theme={null}
.team-status {
  display: grid;
  gap: calc(var(--spacing) * 4);
  padding: calc(var(--spacing) * 6);
  color: var(--card-foreground);
  font-family: var(--font-body);
  background: var(--card);
  border: 1px solid var(--border);
  border-radius: var(--radius-lg);
}

.team-status__title {
  margin: 0;
  font-family: var(--font-header);
  font-size: var(--text-xl);
}

.team-status__button {
  color: var(--primary-foreground);
  background: var(--primary);
  border: 1px solid var(--primary);
  border-radius: var(--radius-md);
}

.team-status__button:hover {
  background: color-mix(in oklch, var(--primary) 90%, var(--foreground));
}

.team-status__button:focus-visible {
  outline: 2px solid var(--ring);
  outline-offset: 2px;
}
```

Do not redefine these variables in widget CSS. Do not add a hardcoded fallback color, font, spacing value, or radius when a semantic variable represents the same intent. A widget-owned visual value is appropriate only when it carries product meaning that the portal theme cannot represent, such as colors intrinsic to supplied content.

Use a `colorSelect` property only when an author must choose among semantic color roles. Avoid literal color fields, font controls, and spacing or radius controls that duplicate the portal theme.

Test the widget with each supported portal theme and color mode. Check surface and text pairs, borders, focus indicators, disabled states, charts, and interactive states. The widget should remain visually consistent with surrounding widgets when the active theme changes.

## Build accessible behavior

Use semantic elements, accessible names, keyboard operation, visible focus, useful alternative text, and logical heading order. Respect reduced-motion preferences.

Test:

* keyboard-only operation;
* focus entry, order, and restoration;
* text and control contrast in each theme mode;
* empty and error states;
* narrow layouts and content zoom;
* motion with reduced motion enabled.

## Inspect through a host

A successful build proves neither visual compatibility nor accessibility. Render the widget in a portal or builder host and inspect the resulting host-owned elements.