@c15t/react 3.0.0-alpha.5 → 3.0.0-alpha.6

package/docs/concepts/consent-state.md

@@ -27,6 +27,42 @@ itself stays refused: its `effectivePermissions` entry is `false`, and targets
 that name only the category, or that also declare a consent purpose or special
 feature, stay blocked.
 
+## Categories under an IAB policy
+
+Under an IAB policy the visitor chooses TCF purposes, and c15t derives each
+category from them when the choice is saved. A category is granted when the
+visitor consented to every purpose in it that a listed vendor processes on
+consent:
+
+| Category        | TCF purposes |
+| --------------- | ------------ |
+| `marketing`     | 2, 3, 4      |
+| `measurement`   | 7, 8, 9      |
+| `experience`    | 5, 6         |
+| `functionality` | 10, 11       |
+
+`necessary` is always granted. Purpose 1, device storage, decides no category.
+
+Accept All consents only to the purposes and special features that the vendors
+in your list declare, because the TCF Policies allow no consent signal for a
+purpose the visitor was not shown. A category whose purposes no listed vendor
+processes on consent therefore stays denied after Accept All, and so does every
+script, iframe or network rule gated on it. With a vendor list whose vendors
+declare only purposes 1 to 4 and 7, for example, `experience` and
+`functionality` stay denied.
+
+If your own scripts depend on such a category, do one of these:
+
+* Declare the processing. Add a custom vendor for it, with the purposes it
+  uses, through the `customVendors` option of your IAB setup. The preference
+  centre then lists those purposes, and Accept All and the purpose switches
+  can grant the category.
+* Gate the script on a category that your listed vendors' purposes cover, or on
+  `necessary` if it needs no consent.
+
+Check `effectivePermissions` after Accept All on a fresh visit to see which
+categories your vendor list leaves denied.
+
 ## When a choice is saved
 
 A save records the choice in the browser first and sends it to the backend
@@ -76,6 +112,11 @@ unchanged selection, closes the surface when it resolves successfully. Opening
 or closing a surface, or starting another save, before then leaves the surface
 as the visitor set it.
 
+Closing the dialog without saving, with Escape or the adapter's close call,
+leaves the same surface a save would. A visitor who opens preferences from the
+banner and backs out still owes a choice, so the banner comes back. Once a
+choice is recorded, closing the dialog leaves nothing open.
+
 ## Preserve records during hydration
 
 Server helpers return records with policy information and evaluation time.

package/docs/concepts/data-fetching.md

@@ -1,7 +1,8 @@
 ---
 title: Data fetching
-description: How c15t gets policy data through a cached manifest, backend /init,
-  the browser or offline rules, and where consent choices are saved.
+description: Choose the recommended build-time policy snapshot or runtime
+  manifest fetching, backend /init, browser resolution or offline rules, and
+  understand where consent choices are saved.
 group: concepts
 ---
 
@@ -13,13 +14,14 @@ the same protocol, so every path below works with either. Only `offline()`
 removes backend requests. For a recommendation by framework, start with
 [choose your setup](./choose-your-setup.md).
 
-| Fetching path                  | Where policy resolves                                                                 | Where choices are submitted | Choose it when                                                                                         |
-| ------------------------------ | ------------------------------------------------------------------------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------ |
-| Cached manifest on your server | Your application resolves public policy data with each request's location and signals | Inth or your c15t backend   | Your host has a runtime server and you want to reuse policy data across requests                       |
-| Regular backend `/init`        | The consent backend                                                                   | The same backend            | You want the fewest moving parts, need backend-owned request resolution, or have no application server |
-| Manifest in the browser        | The browser, using supplied or unknown location                                       | Inth or your c15t backend   | You deliberately want client resolution and have planned geography, bundle size and policy refresh     |
-| Offline                        | The browser or local runtime, using bundled rules                                     | No backend submission       | Local development and tests. Not recommended for production environments.                              |
-| Custom transport               | Your implementation                                                                   | Your implementation         | An existing service cannot use the c15t backend protocol                                               |
+| Fetching path                    | Where policy resolves                                                                 | Where choices are submitted | Choose it when                                                                                         |
+| -------------------------------- | ------------------------------------------------------------------------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------ |
+| Build-time manifest, recommended | Your server or browser resolves a bundled policy snapshot with each visitor's inputs  | Inth or your c15t backend   | Your framework supports a build integration and policy changes can ship with a rebuild                 |
+| Cached manifest on your server   | Your application resolves public policy data with each request's location and signals | Inth or your c15t backend   | Policy changes must reach the app without rebuilding, or builds cannot access the backend              |
+| Regular backend `/init`          | The consent backend                                                                   | The same backend            | You want the fewest moving parts, need backend-owned request resolution, or have no application server |
+| Manifest in the browser          | The browser, using supplied or unknown location                                       | Inth or your c15t backend   | You deliberately want client resolution and have planned geography, bundle size and policy refresh     |
+| Offline                          | The browser or local runtime, using bundled rules                                     | No backend submission       | Local development and tests. Not recommended for production environments.                              |
+| Custom transport                 | Your implementation                                                                   | Your implementation         | An existing service cannot use the c15t backend protocol                                               |
 
 ## What is a consent manifest?
 
@@ -38,6 +40,24 @@ Do not put secrets, visitor identifiers or consent records into a manifest.
 Keep personalized init responses out of shared caches. Changing a policy also
 requires a refresh strategy for cached or build-time manifests.
 
+## Use a build-time manifest by default
+
+The build fetches your public policy once and bundles it, so the server never
+fetches it at runtime.
+
+The framework quickstarts include the build integration for supported
+deployments. Server resolution uses the snapshot without an upstream manifest
+request. Browser resolution includes the policy and resolver in the client
+bundle, and may still request location for regional policies. Static Nuxt and
+Astro sites and script-tag sites keep the runtime setup from their guides.
+
+The snapshot is fixed at build time:
+
+* Rebuild after changing policies, translations or vendors. If your CI caches
+  build output, force a fresh build.
+* The build must reach the backend. A failed fetch fails the build.
+* Consent choices still go to the backend.
+
 ## How manifest mode counts visitors
 
 The backend counts visitors from `/init` requests, and manifest resolution
@@ -156,10 +176,13 @@ the kernel contract. Prefer a built-in transport when your backend supports it.
 ## Verify the selected path
 
 Inspect browser and server requests separately. A server manifest fetch will
-not appear in the browser's Network panel. On a warm manifest path, check that
+not appear in the browser's Network panel. With a build-time snapshot, start a
+fresh production server and confirm it makes no upstream `/manifest` request.
+After a policy edit, rebuild and confirm the new policy appears. On a runtime
+manifest path, check that
 page requests do not call the backend `/init`, a visitor's choice still reaches
 the backend's `/subjects`, and policy changes become visible after the configured
-refresh. In the recommended Next.js setup, the browser should call only
+refresh. With a same-origin consent proxy, the browser should call only
 `/api/c15t` paths for consent HTTP traffic; inspect server logs to verify their
 upstream destinations.
 

package/docs/customization/recipes.md

@@ -517,8 +517,7 @@ from your Inth project, and put the block before `</body>`.
 
 ```html title="index.html"
 <script
-	src="https://cdn.jsdelivr.net/npm/@c15t/browser@alpha/dist/c15t.headless.js"
-	data-backend-url="https://your-project.inth.app"
+	src="https://your-project.inth.app/c15t.headless.js"
 	defer
 ></script>
 
@@ -622,8 +621,8 @@ from your Inth project, and put the block before `</body>`.
 	hidden
 >
 	<p class="cookie-bar__text">
-		We use cookies to measure traffic and improve this site. Choose which ones
-		can run.
+		We use cookies to measure traffic and improve this site. Choose which
+		ones can run.
 	</p>
 	<fieldset
 		class="cookie-bar__prefs"
@@ -867,5 +866,5 @@ The source repository renders each design in its Storybook under
 `Docs / Banner designs`: `apps/storybook-react`, `apps/storybook-vue`,
 `apps/storybook-svelte` and `apps/storybook-astro`. Each story uses an
 in-memory policy and loads no analytics. The HTML headless bar runs at
-`/consent-example/headless` in `examples/script-tag`, which the example
+`/consent-example/headless` in `internals/fixtures/script-tag`, which the example
 acceptance tests cover.

package/docs/customization/slots.md

@@ -129,8 +129,9 @@ The widget is the list of categories inside the dialog. React and Vue call it
 | Label                        | `trigger.text`                                                  | None                                                                                                |
 | Toolbar, its items and icons | `trigger.toolbar`, `trigger.toolbarItem`, `trigger.toolbarIcon` | `consentDialogTriggerToolbar`, `consentDialogTriggerToolbarItem`, `consentDialogTriggerToolbarIcon` |
 
-Only React renders the toolbar. Vue has no toolbar, and the toolbar slots only
-reach Astro's React dialog.
+React renders the toolbar from `ConsentDialogTriggerToolbar`, and while
+`ConsentDevTools` is mounted. Vue renders it only while `ConsentDevTools` is
+mounted. In Astro, the toolbar slots reach the React dialog.
 
 ## Legal links and IAB TCF parts
 

package/docs/customization/stylesheets.md

@@ -1,8 +1,8 @@
 ---
 title: Stylesheets and CSS layers
-description: Load the right c15t stylesheet for your framework, see when the
-  dialog's CSS loads, order c15t's cascade layer against your own, and run c15t
-  without its styles.
+description: Load the right c15t stylesheet for your framework, see which file
+  holds the dialog's rules, order c15t's cascade layer against your own, and run
+  c15t without its styles.
 group: customization
 ---
 
@@ -26,32 +26,25 @@ when the integration sets `iab`. Tailwind 3 uses the same files and adds a
 PostCSS plugin; [Tailwind CSS](./tailwind.md#set-up-tailwind-css-3)
 shows the setup.
 
-## What loads with the first paint
-
-A stylesheet that blocks rendering should hold only what the first paint can
-show. c15t's main stylesheet holds the default tokens, every c15t CSS variable,
-and the rules for the banner, the floating trigger and the `ConsentGate`
-placeholder. The preference dialog's rules load separately in most frameworks:
-
-| Framework                      | The preference dialog's rules                                                                                                                                                        |
-| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| Next.js, TanStack Start, React | The dialog's code imports `@c15t/ui/styles/dialog.css`. Your bundler emits it with the dialog's lazy chunk and loads it before that chunk runs, so the dialog never renders unstyled |
-| Nuxt, Vue                      | The dialog component imports its stylesheet, so the rules load with the dialog's code, not the banner's                                                                              |
-| Astro                          | c15t links the dialog's stylesheets when a visitor first points at, focuses or opens a control that opens the dialog, and keeps them across `ClientRouter` navigation                |
-| Svelte, SvelteKit              | Part of `@c15t/svelte/styles.css`, so they load up front                                                                                                                             |
-| HTML, JavaScript               | Part of the stylesheet in the shadow root, which holds only the rules the stock surfaces use                                                                                         |
-
-In React, Next.js and TanStack Start, do not import `dialog.css` yourself. The
-`@c15t/react/components/consent-dialog`, `/components/consent-widget`,
-`/primitives`, `/primitives/*` and `/iab` entry points import it as soon as
-you import them, because they render dialog parts outside the lazy chunk.
-
-These modules import the stylesheet through `@c15t/ui/styles/dialog`. Under
-the `node` export condition that module imports nothing, so server code that
-loads `@c15t/react` with plain Node, such as the Pages Router or an SSR build
-that keeps dependencies external, does not fail on the `.css` file. In your own
-components, import `@c15t/ui/styles/dialog` rather than the `.css` file if the
-module can run on the server.
+## Where the dialog's rules come from
+
+`styles.css` holds the default tokens, every c15t CSS variable and the rules
+for every stock surface: the banner, the floating trigger, the `ConsentGate`
+placeholder, the preference dialog and the preference widget. Only the IAB TCF
+surfaces need a second file, `iab/styles.css`.
+
+| Framework                      | The preference dialog's rules                                                                                                                                                                                                                        |
+| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Next.js, TanStack Start, React | In `styles.css`. No `@c15t/react` or `@c15t/ui` module imports CSS, so a Next.js app that uses only the Pages Router builds without `transpilePackages`                                                                                              |
+| Nuxt, Vue                      | The dialog component imports its stylesheet, so the rules load with the dialog's code, not the banner's                                                                                                                                              |
+| Astro                          | In `c15t/astro/styles.css`. The Svelte dialog, the default `ui`, also needs the primitives stylesheet, which c15t links when a visitor first points at, focuses or opens a control that opens the dialog, and keeps across `ClientRouter` navigation |
+| Svelte, SvelteKit              | In `@c15t/svelte/styles.css`                                                                                                                                                                                                                         |
+| HTML, JavaScript               | Part of the stylesheet in the shadow root, which holds only the rules the stock surfaces use                                                                                                                                                         |
+
+Earlier 3.0 alphas shipped the dialog's rules in `@c15t/ui/styles/dialog.css`,
+which the dialog's code imported. That file, the `@c15t/ui/styles/dialog`
+module and `c15t/astro/dialog.css` are now empty and stay only so existing
+imports keep resolving. Remove those imports.
 
 ## Order c15t's layer against your CSS
 
@@ -78,11 +71,9 @@ What this means for your overrides:
   [theme tokens](./tokens.md).
 
 If your CSS declares its own layer order, load that statement before c15t's
-stylesheet. If you import c15t's stylesheet into a named layer, such as
-`@import 'c15t/react/styles.css' layer(c15t)`, the dialog's lazy rules still
-join the top-level `components` layer. List `components` in your statement,
-for example `@layer c15t, components, app;`, so it does not land after your
-own layers.
+stylesheet. You can import c15t's stylesheet into a named layer, such as
+`@import 'c15t/react/styles.css' layer(c15t)`. Its component rules then sit
+in `c15t.components`, so order `c15t` against your own layers.
 
 ## Load Astro's stylesheets yourself
 
@@ -90,12 +81,11 @@ The Astro integration adds `c15t/astro/styles.css` to every page ahead of your
 own CSS. To control the order yourself, for example from a global stylesheet
 that names its own layers, set `styles: false` in the `c15t()` options and
 import the files after your layer order statement. With `styles: false`, c15t
-links no dialog stylesheet either, so import the dialog's rules too. The
-Svelte dialog, the default `ui`, also needs the primitives stylesheet:
+links no stylesheet when the dialog opens either. The Svelte dialog, the
+default `ui`, needs the primitives stylesheet next to `styles.css`:
 
 ```css title="src/styles/global.css"
 @import 'c15t/astro/styles.css';
-@import 'c15t/astro/dialog.css';
 /* Only with ui: 'svelte'. */
 @import 'c15t/astro/primitives.css';
 /* Only when the integration sets iab. */
@@ -141,7 +131,7 @@ selector before you reach for `noStyle`.
 
 1. Open DevTools Network, clear site data and reload. Your framework's c15t
    stylesheet loads once, and no second copy appears.
-2. Open the preference dialog. It is styled on its first frame, with no flash
-   of unstyled content.
+2. Open the preference dialog. It is styled on its first frame, and in React,
+   Next.js and TanStack Start no new stylesheet request appears.
 3. Select a banner part and read the Styles panel. c15t's rules appear under
    `@layer components`, and your unlayered rules for the same property win.

package/docs/customization/tailwind.md

@@ -282,8 +282,8 @@ Make three changes:
 3. Set `darkMode: 'class'` so Tailwind's `dark:` variant follows the same
    `dark` class c15t reads.
 
-The plugin also processes the stylesheets c15t loads for you, such as the
-dialog's lazy stylesheet and Astro's injected one. Without it, Tailwind 3 stops
+The plugin also processes the stylesheets c15t loads for you, such as Astro's
+injected one. Without it, Tailwind 3 stops
 the build with "`@layer components` is used but no matching
 `@tailwind components` directive is present", or purges c15t's rules, because
 c15t's class names never appear in your source.
@@ -300,7 +300,7 @@ cannot edit your PostCSS config, it prints the step to do by hand. See
 [setup](https://c15t.com/docs/cli/commands/setup#set-up-styles-and-tailwind-css).
 
 Create React App ignores PostCSS config files, so Tailwind 3 cannot run the
-plugin and the build fails on c15t's dialog stylesheet. `c15t setup` warns
+plugin and the build fails on c15t's stylesheet. `c15t setup` warns
 about this. Add the plugin before `tailwindcss` through CRACO, eject, or move
 the app to Vite.
 
@@ -771,7 +771,7 @@ stylesheet, and the layer order keeps it above preflight:
 
 ```html title="light-dom.html"
 <script
-	src="/c15t.js"
+	src="/c15t.offline.js"
 	data-mode="offline"
 	data-country="DE"
 	data-shadow="false"
@@ -793,7 +793,7 @@ instead:
 	window.c15t = [['config', { ui: { shadow: false, styles: false } }]];
 </script>
 <script
-	src="/c15t.js"
+	src="/c15t.offline.js"
 	data-mode="offline"
 	data-country="DE"
 	defer

package/docs/customization/tokens.md

@@ -101,7 +101,7 @@ easing tokens.
 | `--c15t-text-on-primary`      | `colors.textOnPrimary`           | auto-derived from `colors.primary` when omitted |
 | `--c15t-overlay`              | `colors.overlay`                 | `hsla(0, 0%, 0%, 0.5)`                          |
 | `--c15t-switch-track`         | `colors.switchTrack`             | `hsl(0, 0%, 85%)`                               |
-| `--c15t-switch-track-active`  | `colors.switchTrackActive`       | `hsl(228, 100%, 60%)`                           |
+| `--c15t-switch-track-active`  | `colors.switchTrackActive`       | `colors.primary`                                |
 | `--c15t-switch-thumb`         | `colors.switchThumb`             | `hsl(0, 0%, 100%)`                              |
 | `--c15t-font-family`          | `typography.fontFamily`          | `system-ui, -apple-system, sans-serif`          |
 | `--c15t-font-size-sm`         | `typography.fontSize.sm`         | `0.875rem`                                      |

package/docs/customization/translations.md

@@ -31,6 +31,33 @@ site-wide change. Astro's serializable integration options have their own
 types, so verify that shape before copying a React object. The Vue plugin and
 Nuxt module have no `i18n` option; their copy comes from the backend.
 
+## Load only the languages you use
+
+c15t bundles English. Every other language it ships is a separate entry point
+in `@c15t/translations`, named by its language code. Importing one registers
+c15t's built-in copy for that language. Offline mode can then switch to it,
+and your messages that repeat its wording don't hide backend edits. Import
+them in the file that configures the provider, so they load in the browser:
+
+```ts
+import '@c15t/translations/de';
+import '@c15t/translations/fr';
+```
+
+Each entry also exports that copy as `translations`, if you want to read a
+string or build your messages from it:
+
+```ts
+import { translations as de } from '@c15t/translations/de';
+```
+
+The entries are `bg`, `cs`, `cy`, `da`, `de`, `el`, `es`, `et`, `fi`, `fr`,
+`ga`, `gu`, `he`, `hi`, `hr`, `hu`, `id`, `is`, `it`, `lb`, `lt`, `lv`, `mt`,
+`nb`, `nl`, `nn`, `pl`, `pt`, `rm`, `ro`, `sk`, `sl`, `sv` and `zh`.
+`@c15t/translations/all` still loads every language at once. The `c15t`
+package doesn't re-export these entries, so add `@c15t/translations` to your
+dependencies.
+
 ## Combine messages with backend copy
 
 With a backend or a manifest, the copy it sends for the visitor's language is
@@ -41,11 +68,11 @@ its primary language, so `de-AT` uses your `de` messages when there is no
 `de-AT` entry. Messages for other languages are not applied.
 
 A key only overrides the backend when your text differs from c15t's built-in
-wording for that language. So passing the stock bundles from
-`@c15t/translations/all` to enable languages keeps backend edits visible,
-while a key you actually reworded stays pinned in code. Core bundles only
-English; for other languages, import `@c15t/translations/all` so c15t can
-recognize its stock wording.
+wording for that language. So passing a stock bundle to enable a language
+keeps backend edits visible, while a key you actually reworded stays pinned
+in code. c15t only recognizes the built-in wording of English and of the
+languages you [import](#load-only-the-languages-you-use), such as
+`@c15t/translations/de` or `@c15t/translations/all`.
 
 ## Write labels that describe the action
 

package/docs/frameworks/react/components/consent-dialog-trigger.md

@@ -112,6 +112,11 @@ nothing only when it has no visible item.
 | `ariaLabel`       | `string`                                 | `'Privacy controls'` | Accessible name for the toolbar group.                                                                                                                           |
 | `noStyle`         | `boolean`                                | `false`              | Remove the default styling.                                                                                                                                      |
 
+While `<ConsentDevTools>` is mounted, the toolbar adds a DevTools button at
+the end farthest from its corner and opens the DevTools panel beside itself.
+The ready-made `ConsentDialogTrigger` switches to this toolbar layout for as
+long as DevTools is mounted.
+
 ### Toolbar styling
 
 The toolbar follows the standard precedence: bundled styles, then provider slots, then direct `className` and `style` on the toolbar or on one action. Use `noStyle` for a fully custom implementation.

package/docs/frameworks/react/components/consent-dialog.md

@@ -132,7 +132,8 @@ cached: the next hover, focus or open tries the download again.
 The dialog's CSS travels in the same chunk and is applied before the dialog
 renders, so your app's `styles.css` import stays small.
 
-Without an `open` prop, Escape closes the dialog. Save Settings, Accept All and
+Without an `open` prop, Escape closes the dialog without saving. If the
+policy still owes a choice, the banner comes back. Save Settings, Accept All and
 Reject All close it as soon as the choice is recorded in the browser, in
 the same task as the click; the exit animation still plays. The request to
 the backend runs afterwards and never reopens the dialog: a failed request

package/docs/frameworks/react/components/dev-tools.md

@@ -76,6 +76,29 @@ panel renders inside a shadow root by default, so page CSS does not reach
 it. `shadow={false}` mounts it in the light DOM with its stylesheet in
 `<head>`.
 
+## Open DevTools from the consent trigger
+
+While `ConsentDialogTriggerToolbar` or the ready-made `ConsentDialogTrigger`
+is visible, the trigger shows a DevTools button and DevTools hides its own
+floating launcher, so one control occupies the corner. The button sits at the
+end of the toolbar farthest from its corner. The panel opens just past the
+toolbar, aligned with its outer edge, and follows it when a visitor drags the
+toolbar to another corner. `position` applies again once no trigger is
+visible.
+
+`ConsentDialogTrigger` becomes a two-button toolbar while DevTools is
+mounted. A trigger composed from `ConsentDialogTrigger.Root` keeps its own
+markup, and DevTools keeps its floating launcher beside it.
+
+DevTools brings its launcher back whenever no trigger is visible, for example
+while `showWhen="after-prompt"` waits for a choice. A production build that
+loads DevTools only in development shows no DevTools button in the trigger.
+
+With the imperative engine, call `devTools.dock({ position, inline, block })`
+to hide the launcher and anchor the panel `inline` and `block` pixels from the
+viewport edges of `position`'s corner. Call `devTools.dock(null)` to restore
+the launcher.
+
 ## Panels
 
 Accept and reject apply only to categories displayed by the provider, leaving

package/docs/frameworks/react/headless.md

@@ -34,13 +34,13 @@ import { useHeadlessConsentUI, useTranslations } from 'c15t/react/headless';
 
 const ACTION_LABELS = {
 	accept: 'acceptAll',
-	reject: 'rejectAll',
 	customize: 'customize',
 	dismiss: 'acknowledge',
+	reject: 'rejectAll',
 	save: 'save',
 } as const;
 
-export function Banner() {
+export const Banner = () => {
 	const { banner, performAction, openDialog } = useHeadlessConsentUI();
 	const { common, rights } = useTranslations();
 
@@ -49,7 +49,7 @@ export function Banner() {
 	}
 
 	return (
-		<section role="region" aria-label="Privacy">
+		<section aria-label="Privacy">
 			{banner.preferenceControls.map((right) => (
 				<button key={right} type="button" onClick={openDialog}>
 					{right === 'opt-out' ? rights?.optOut : rights?.preferences}
@@ -71,7 +71,7 @@ export function Banner() {
 			))}
 		</section>
 	);
-}
+};
 ```
 
 `banner.actionGroups` is the resolved layout: reject and accept share a group

package/docs/frameworks/react/hooks.md

@@ -14,10 +14,10 @@ from components rendered inside that provider and import them from
 ```tsx title="src/optional-feature.tsx"
 import { useConsent } from 'c15t/react';
 
-export function OptionalFeature() {
+export const OptionalFeature = () => {
 	const allowed = useConsent('marketing');
 	return allowed ? <div>Optional marketing content</div> : null;
-}
+};
 ```
 
 Call hooks inside the consent provider. `useConsent` reads effective permission,
@@ -42,14 +42,19 @@ Render this component inside your existing `ConsentProvider`.
 ```tsx title="src/reject-button.tsx"
 import { useSaveConsents } from 'c15t/react';
 
-export function RejectButton() {
+export const RejectButton = () => {
 	const save = useSaveConsents();
 	return (
-		<button type="button" onClick={() => void save('none')}>
+		<button
+			type="button"
+			onClick={() => {
+				void save('none');
+			}}
+		>
 			Reject optional
 		</button>
 	);
-}
+};
 ```
 
 This is an isolated action example, not a complete policy-aware banner. Use the

package/docs/frameworks/react/iab.md

@@ -33,14 +33,12 @@ import {
 	IABConsentDialog,
 } from 'c15t/react/iab';
 
-export function IABConsent({ cmpId }: { cmpId: number }) {
-	return (
-		<IABProvider cmpId={cmpId}>
-			<IABConsentBanner />
-			<IABConsentDialog />
-		</IABProvider>
-	);
-}
+export const IABConsent = ({ cmpId }: { cmpId: number }) => (
+	<IABProvider cmpId={cmpId}>
+		<IABConsentBanner />
+		<IABConsentDialog />
+	</IABProvider>
+);
 ```
 
 Supply the CMP ID from your deployment's IAB configuration. Keep a persistent
@@ -85,14 +83,12 @@ const publisherRestrictions = [
 	{ purposeId: 7, restrictionType: 2 as const, vendorIds: [755] },
 ];
 
-export function IABConsent({ cmpId }: { cmpId: number }) {
-	return (
-		<IABProvider cmpId={cmpId} publisherRestrictions={publisherRestrictions}>
-			<IABConsentBanner />
-			<IABConsentDialog />
-		</IABProvider>
-	);
-}
+export const IABConsent = ({ cmpId }: { cmpId: number }) => (
+	<IABProvider cmpId={cmpId} publisherRestrictions={publisherRestrictions}>
+		<IABConsentBanner />
+		<IABConsentDialog />
+	</IABProvider>
+);
 ```
 
 Each restriction type has a requirement that depends on the vendor list:
@@ -154,8 +150,10 @@ because turning one off would change nothing the vendors rely on; its
 objection control is the opt-out. Such a purpose does not decide its c15t
 category: the category follows the purposes in it that the visitor can
 consent to. Legitimate interest never grants a category on its own. If none of
-a category's purposes has a consent basis, the category needs all of them
-consented, which only Accept All does. Stack switches
+a category's purposes has a consent basis, nothing can consent to them, Accept
+All included, so the category stays denied. See
+[categories under an IAB policy](../../concepts/consent-state.md#categories-under-an-iab-policy).
+Stack switches
 cover only the purposes some vendor processes on consent. Display-model rows
 expose this as `hasConsentBasis`. Custom preference UIs can call
 `applyPublisherRestrictionsToGVL` from `@c15t/iab/headless`, or pass
@@ -209,6 +207,14 @@ the special purposes only. `featureRows` holds the features, with
 `featuresStandardText` is the standard text, or `null` when you should use the
 translation.
 
+Each vendor's privacy policy and legitimate interest links come from its
+`urls[]` entry in the Global Vendor List. The stock preference centres pick
+the entry for the language the banner shows, then English. A custom UI gets
+the same links from `resolveIABVendorUrls(vendor, language)` in
+`@c15t/iab/headless`, or from `policyUrl` and `legitimateInterestUrl` on the
+vendors `processGVLForDialog` returns when you pass it `language`. Vendor lists
+older than GVL v3 have a single `policyUrl` field, which c15t still reads.
+
 ## Consent scope
 
 c15t stores TCF choices per site and browser, which the TCF calls