@c15t/react 3.0.0-alpha.0 → 3.0.0-alpha.10

package/docs/guides/data-fetching.md

@@ -1,163 +0,0 @@
----
-title: Data fetching and transports
-description: Choose cached manifests, backend init or offline policy resolution,
-  and understand where consent records are saved.
-group: guides
----
-
-## Start with Inth and a cached manifest
-
-Use Inth for managed policy and consent records. For a Next.js application with
-a server, use a cached manifest to resolve policy in your application. Route
-browser consent traffic directly to Inth, or optionally use a Next.js rewrite
-to keep those requests on your app's origin. Follow the
-[Next.js manifest setup](https://c15t.com/docs/frameworks/next/data-fetching).
-
-Backend ownership and data fetching are separate decisions. Inth manages the
-backend for you. A [self-hosted backend](https://c15t.com/docs/self-host/quickstart) uses the same
-protocol while you operate its database, policies and availability. A static
-site can still call Inth. Only `offline()` deliberately removes consent backend
-requests and stores choices locally.
-
-| 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                                               |
-
-## What is a consent manifest?
-
-A manifest is a versioned policy document served by `GET /manifest`. It contains
-policy rules, translation configuration and related consent configuration. It
-is public configuration, not a visitor's saved choices. A resolver combines the
-manifest with country, region, language and privacy signals to produce an init
-result for one visitor.
-
-Reusing the public document avoids asking the consent backend to resolve policy
-for every application request. Cache misses and revalidation still fetch the
-manifest, and consent writes still need the backend. Measure the deployed
-request path before promising a latency improvement.
-
-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.
-
-## What does regular `/init` do?
-
-`hosted({ url })` uses `${url}/init` for initialization and `${url}/subjects` for
-consent submissions. The name `hosted` describes the transport protocol; the URL
-can belong to Inth or your own c15t backend.
-
-```ts title="src/consent-mode.ts"
-import { hosted } from 'c15t';
-
-export function createConsentMode(backendURL: string) {
-  return hosted({ url: backendURL });
-}
-```
-
-Pass the factory to your adapter's `mode` option. For request rendering, use the
-adapter's server helper and forward its prepared result to the browser. For
-static output, initialize in the browser with a reachable external URL.
-
-A regular backend `/init` request lets the backend resolve the visitor context.
-A same-origin URL named `/api/c15t/init` can instead resolve from a cached
-manifest in your application. The URL name alone does not tell you which path
-runs.
-
-## How do transports and proxies differ?
-
-A transport implements initialization, saving and optional record operations.
-A proxy changes where HTTP requests travel. It does not change the policy
-resolver or make personalized responses safe to cache.
-
-For a same-origin init route that resolves a manifest, the hosted transport can
-separate policy reads and record writes. With a backend rewrite mounted at
-`/api/c15t`, a client mode can use:
-
-```ts title="src/consent-mode.ts"
-import { hosted } from 'c15t';
-
-export const mode = hosted({
-  url: '/api/c15t',
-  initURL: '/api/c15t/init',
-  assertDecisionInputs: true,
-});
-```
-
-The route must return the c15t init response contract. `assertDecisionInputs`
-binds saves to the resolved policy when init did not return a signed policy
-snapshot token. The backend can then reject a stale policy decision. Next.js
-sets this option for you when `ConsentRoot` receives a `config` with
-`initURL`.
-
-The init route resolves policy; the backend rewrite forwards `/api/c15t/subjects`
-and other record endpoints. Configure both if you choose this optional proxy
-variant. The
-[Next.js rewrite recipe](https://c15t.com/docs/frameworks/next/optimization#keep-browser-consent-requests-on-your-origin)
-shows the configuration. A direct absolute backend URL works
-without a rewrite.
-
-This optional optimization keeps c15t requests on the app's origin and avoids a separate browser DNS lookup
-and TLS connection to the consent backend. The app server still connects to
-the upstream backend for manifest refreshes and consent writes. Vendor scripts
-and vendor requests keep their own origins.
-
-Set the absolute upstream endpoint through `C15T_BACKEND_URL` in Next.js server
-configuration. The endpoint URL is public connection information, not a secret.
-The browser uses `/api/c15t` without needing the upstream URL. A static export
-cannot serve a Next.js route or rewrite at runtime; use the absolute Inth URL or
-a proxy provided by the static host instead.
-
-## When should I use offline mode?
-
-Not recommended for production environments. Use Inth or a self-hosted backend
-for production policy and consent records.
-
-`offline()` resolves bundled policy rules without an init request and acknowledges
-saves locally. The runtime's persistence module stores the choice in browser
-storage. There is no backend audit history, cross-device record service or IP
-geolocation supplied by this transport.
-
-Use your adapter's offline factory so its translations and provider context are
-included. This React and Next.js example replaces the hosted mode in an existing
-client provider:
-
-```ts title="src/consent-mode.ts"
-import { offline } from 'c15t/react';
-
-export const mode = offline();
-```
-
-With no `policyRules`, the current offline transport uses the recommended rule
-pack. Supplying `policyRules` replaces that pack. Unknown country and region are
-real resolution inputs; offline mode does not discover a visitor's location.
-Use [policy rules](https://c15t.com/docs/frameworks/next/concepts/policy-presets) to understand
-matching and defaults, and test the missing-location case.
-
-Offline mode is an explicit architecture choice, not an automatic fallback for
-a failed Inth request. If hosted initialization fails before a policy resolves,
-optional permissions remain denied and the stock prompt stays hidden. Observe
-initialization failures instead of silently changing policy sources.
-
-## Can I provide my own transport?
-
-`custom(transport)` accepts a `KernelTransport` with the v3 `init` and `save`
-contract. It does not accept v2 endpoint handlers such as `setConsent`. Keep
-policy resolution, record acknowledgments and failure behavior consistent with
-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
-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
-`/api/c15t` paths for consent HTTP traffic; inspect server logs to verify their
-upstream destinations.
-
-Test different locations, missing location headers, GPC, returning choices and
-backend failure. See [verification](./verify-consent.md).

package/docs/guides/deployment-modes.md

@@ -1,63 +0,0 @@
----
-title: Choose a deployment mode
-description: Choose who runs your consent backend, then select manifest, init or
-  offline resolution for your deployment.
-group: guides
----
-
-## Use Inth for managed policy and records
-
-Start with [Inth](https://inth.com) unless you need to operate the consent
-service yourself or deliberately need only local browser records. Configure
-policy rules and trusted origins in the project, then use its exact backend
-endpoint in your framework setup.
-
-| Backend ownership         | Policy source                                          | Record storage                           | Use when                                                                  |
-| ------------------------- | ------------------------------------------------------ | ---------------------------------------- | ------------------------------------------------------------------------- |
-| Inth hosted service       | Centrally managed policy through a manifest or `/init` | Browser records plus backend submissions | You want managed policy and consent records                               |
-| Self-hosted c15t          | Your backend's manifest or `/init`                     | Browser records plus your database       | You need to operate the service and its infrastructure                    |
-| Browser-only offline mode | Bundled `policyRules`                                  | Browser persistence                      | Local development and tests. Not recommended for production environments. |
-
-Hosted and self-hosted c15t use the same transport protocol. Switching who runs
-the backend does not require switching from manifests to `/init`.
-
-## Choose data fetching separately
-
-For Next.js deployments with a runtime server, use the
-[manifest setup](https://c15t.com/docs/frameworks/next/data-fetching). It reuses public policy data
-in your application while consent writes still go to Inth. Regular backend
-`/init` is available when you want backend-owned request resolution or a simpler
-browser setup. See [data fetching and transports](./data-fetching.md) for
-the comparison, including custom transports and offline mode.
-
-## Match initialization to your application output
-
-| Application output | Initial state             | Required setup                                              |
-| ------------------ | ------------------------- | ----------------------------------------------------------- |
-| Request SSR        | Prepared for this visitor | Adapter request helper and matching client configuration    |
-| Static HTML or SPA | Resolved in the browser   | Reachable external URLs or deliberately bundled local rules |
-
-Request SSR can include the visitor's prompt in the initial HTML. Pass the
-prepared records and policy resolution through to hydration. Do not convert
-effective permissions into new stored choices.
-
-Static HTML is shared across visitors. It cannot contain a choice resolved from
-each visitor's cookies or geography at build time. A static site can still use
-Inth through browser requests. A same-origin `/api/c15t` URL only works if a
-service actually serves it; a Next.js static export does not run API routes.
-
-A manifest contains reusable public policy data. A resolved init response and
-personalized consent HTML belong to a request. Do not give them the same shared
-cache treatment.
-
-## Handle initialization and storage failures
-
-While no policy resolves, optional permissions stay denied and the stock
-consent UI stays hidden. No banner can mean pending or failed initialization.
-It does not mean permission to load analytics. Observe errors before changing
-presentation, and do not silently switch to offline policy after a hosted
-request fails.
-
-Browser storage can also be unavailable. A working in-memory interaction does
-not prove the choice survives reload. Use
-[verification](./verify-consent.md) to test the actual deployment.

package/docs/upgrade-v3.md

@@ -1,334 +0,0 @@
----
-title: Upgrade to v3 policies
-description: Migrate policy configuration, consent records, callbacks, and
-  custom transports to the v3 policy system.
-group: reference
----
-
-## Start with a policy rule
-
-```ts
-import { policyRulePresets } from '@c15t/schema';
-import { offline } from '@c15t/react';
-
-const mode = offline({
-	policyRules: [policyRulePresets.europeOptIn()],
-});
-```
-
-Pass `mode` to `ConsentProvider`. For a backend integration, configure
-`policyRules` on the backend and use `hosted({ url })` in the provider. Follow the
-[React quickstart](./frameworks/react/quickstart.md),
-[Next.js quickstart](https://c15t.com/docs/frameworks/next/quickstart), or
-[JavaScript quickstart](https://c15t.com/docs/frameworks/javascript/quickstart) for a complete
-integration.
-
-The CLI no longer offers `offline-add-policy-packs`, which generated v2
-configuration. For offline integrations, configure `offline({ policyRules })`
-as shown above.
-
-Replace legacy `policyPacks` and nested `consent` configuration with rules:
-
-```ts
-import type { PolicyRule } from '@c15t/schema';
-
-const policyRules = [
-	{
-		id: 'default-opt-in',
-		match: { fallback: true },
-		model: 'opt-in',
-		prompt: 'choice',
-		categories: ['measurement', 'marketing'],
-		scopeMode: 'strict',
-	},
-] satisfies PolicyRule[];
-```
-
-`model` controls permission defaults. `prompt` controls whether the visitor must
-make a choice, dismiss a notice, or see no prompt. Opt-in and IAB models require
-`prompt: 'choice'`. Opt-out supports `choice`, `notice`, and `none`. The `none`
-model permits optional categories in scope, allows only `prompt: 'none'`, owes
-no rights, and renders no consent UI. v2's `none` model maps to it directly.
-
-When `categories` selects only some optional categories, you must set
-`scopeMode` explicitly. A strict scope blocks categories outside the rule. A permissive scope allows
-those categories unless another restriction applies. An omitted scope, `['*']`,
-or a list containing only `necessary` expands to the default optional categories.
-`necessary` is always permitted.
-
-`offline()` without `policyRules` resolves `recommendedPolicyRules()`, whose
-Europe rule also matches a visitor with no country. A known US country with a
-missing state uses US opt-out with GPC and persistent preferences; a missing
-Canadian province stays strict opt-in. The last rule is `none` for other known
-unmatched locations. Resolution exposes `matched`, `no-match`,
-`unconfigured`, or `failed`; while nothing has matched, optional categories stay
-denied and no consent surface renders. A missing or malformed policy never grants
-optional permissions by itself.
-
-## Read the state you need
-
-| Purpose                                         | Snapshot field         | React hook                              |
-| ----------------------------------------------- | ---------------------- | --------------------------------------- |
-| Gate scripts and optional features              | `effectivePermissions` | `useConsent(category)`, `useConsents()` |
-| Inspect recorded choices and confirmation times | `explicitChoice`       | `useExplicitChoice()`                   |
-| Decide whether to prompt                        | `promptRequirement`    | `usePromptRequirement()`                |
-| Inspect the resolved rule                       | `policyRule`           | `usePolicyRule()`                       |
-| Inspect matching or failure                     | `resolution`           | `usePolicyResolution()`                 |
-
-An effective permission is not evidence of a grant. Under an opt-out rule it can
-be true before a visitor acts. A notice dismissal updates `noticeDismissal` and
-does not record consent. Global Privacy Control updates privacy signals and
-configured opt-out directives without turning a browser signal into a choice.
-
-## Replace choice callbacks
-
-```tsx
-<ConsentProvider
-	options={{
-		mode,
-		callbacks: {
-			onChoiceRecorded(event) {
-				console.log('Visitor recorded a choice', event);
-			},
-			onPermissionsChanged(event) {
-				console.log('Effective permissions changed', event);
-			},
-		},
-	}}
->
-	{children}
-</ConsentProvider>
-```
-
-Replace `onConsentSet` with `onChoiceRecorded` for explicit accept, reject, or
-save actions. Use `onPermissionsChanged` for permission changes caused by a
-choice, expiry, policy update, or privacy signal. Provider callbacks no longer
-include `onBannerFetched`; use the resolved policy and pending state to render
-loading UI.
-
-Only `kernel.commands.save()` creates an explicit choice. `save('all')` accepts,
-`save('none')` rejects, and `save({ marketing: false })` confirms only marketing.
-A partial save keeps the other categories' confirmation times. Use
-`commands.dismissNotice()` for the notice action and `kernel.hydrate()` to apply
-validated records without recording an action.
-
-## Keep existing storage
-
-The reader accepts valid v2 storage and translates it into per-category receipts.
-It does not rewrite storage on startup. Existing denials continue to restrict
-permissions; expired or incompatible positive receipts cannot restore grants.
-The next explicit action writes the v3 record. Notice dismissal and privacy
-opt-out directives have separate records.
-
-Pass server-prepared `initialRecords`, `initialPolicyResolution`, and `now`
-through the adapter's prefetch configuration. Do not rebuild consent from a
-boolean `hasConsented` or copy effective permissions into explicit choice records.
-Pending prefetch results cannot restore records after a clear or overwrite a
-newer choice.
-
-## Update custom transports and backend clients
-
-Use `KernelTransport` from `@c15t/core/transports`. Init returns a versioned
-`policyResolution` with a matched rule and fingerprints, or an explicit
-non-matched outcome. Use `mapInitOutputToInitResponse` for an HTTP init payload.
-Do not return legacy `policy` or `policyDecision` fields.
-
-Save requests contain the explicit choice and the categories confirmed by this
-action. Return a `SaveResult` with `ok`; optional identity and record methods
-must preserve the same receipt format. Forward the policy contract headers when
-implementing an HTTP proxy. Keep client, schema, backend, and framework adapters
-on compatible v3 versions.
-
-Use the supplied hosted or manifest transports to capture policy evidence for
-saves and retries. They preserve the action's policy, location, language, and
-privacy signal inputs. A stale policy assertion is an error; it must not silently
-save under a different rule. See the
-[backend endpoint reference](https://c15t.com/docs/self-host/api/endpoints) for wire fields.
-
-## Shared runtime ownership
-
-Astro and SvelteKit can create a runtime outside a component tree with
-`createConsentRuntime` from `@c15t/core/runtime`. Pass that runtime to a
-framework provider with its `runtime` prop. The owner calls `start()` after
-mount and `dispose()` when the page no longer needs it. Borrowing providers
-subscribe to the kernel and render UI without initializing or disposing it.
-
-Runtime construction preserves the prepared server snapshot. Storage reads,
-privacy-signal activation and script loading begin on `start()`. Pass server
-records through `prefetch.initialRecords` with their evaluation time to keep
-the first browser render consistent with the server. `runtime.clearRecords()`
-clears both persisted and in-memory records.
-
-Runtime callbacks use `onChoiceRecorded`, `onPermissionsChanged` and
-`onError`. Hydrating records does not report a new visitor choice.
-
-Astro's serializable offline descriptor accepts `policyRules`, just like the
-other adapters' offline factories. Configure a preset or explicit rules;
-omitting them keeps the conservative fallback.
-
-## Presentation corrections
-
-Use `blocking` for backdrop, scroll locking and focus trapping together.
-Choice banners default to non-blocking, choice walls always block, and notices
-never block. A notice configured as a wall falls back to a floating card.
-Preferences remain centered; `variant` and `position` apply only to prompts.
-
-Replace reads of `uncoveredRights` with `preferenceControls`. The latter is a
-list of additional preferences buttons recommended for the stock UI. It does
-not verify disclosure or persistent access to policy rights.
-
-Notice acknowledgement uses `common.acknowledge`, falling back to
-`common.dismiss` for older translation bundles. It does not record a choice.
-
-## Astro notice acknowledgement
-
-```astro
----
-import ConsentBanner from '@c15t/astro/components/consent-banner.astro';
----
-
-<ConsentBanner dismissButtonText="Got it" />
-```
-
-Astro's `ConsentBanner` accepts `dismissButtonText` as an optional string. It
-labels the notice acknowledgement button, which defaults to
-`common.acknowledge` and falls back to `common.dismiss` in older translation
-bundles. Acknowledging a notice preserves the visitor's consent choices.
-
-## IAB blocking behavior
-
-IAB banners and dialogs use the same `presentation.prompt.blocking` and
-`presentation.preferences.blocking` settings as the other consent components.
-A blocking surface shows a backdrop, traps focus and locks page scrolling.
-Explicit `blocking` values take precedence over deprecated `scrollLock` and
-`trapFocus` options. IAB components stay hidden without a matched policy,
-including when a dialog receives `open={true}`.
-
-The React consent dialog still blocks pointer interaction with the page when
-`blocking` is true and you hide its backdrop with `overlay={false}`.
-
-Legacy prompt options now control the whole blocking behavior. For example,
-`scrollLock: true` alone enables a backdrop and focus trapping as well as
-scroll locking. Set `blocking: false` explicitly for a non-modal banner.
-
-Custom dialog backdrops follow the same rule. A dialog resolved as non-blocking
-omits both the default backdrop and a supplied `overlay`. To retain a custom
-backdrop when migrating from `trapFocus: false`, set
-`presentation.preferences.blocking: true` and keep your `overlay` prop.
-
-## Next.js and TanStack Start renames
-
-These names changed without deprecated aliases. `defineConsentConfig`,
-`ConsentConfig` (the URL config) and `ConsentProvider` from `@c15t/react` are
-unchanged.
-
-Next.js (`c15t/next`, `c15t/next/server`, `c15t/next/pages`):
-
-| v2                                                                                            | v3                                                         |
-| --------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
-| `ConsentBoundary`                                                                             | `ConsentRoot`                                              |
-| `ConsentBoundaryProps`                                                                        | `ConsentRootProps`                                         |
-| `config={initialConsent}` (the visitor's resolved state)                                      | `state={...}`                                              |
-| `consent={consentConfig}` (the `defineConsentConfig` result)                                  | `config={consentConfig}`                                   |
-| `prefetchInitialConsent(options)`                                                             | `resolveConsent(options)` with `config` or `backendURL`    |
-| `readInitialConsentConfig(options)`                                                           | `resolveConsent(options)` without `config` or `backendURL` |
-| `InitialConsentConfig`, and `KernelConfig` where it named the returned value                  | `ConsentState`                                             |
-| `PrefetchInitialConsentOptions`                                                               | `ResolveConsentOptions`                                    |
-| `ReadInitialConsentConfigOptions`                                                             | `ConsentRequestOptions`                                    |
-| Pages Router `readInitialConsentConfig(req, opts)` and `prefetchInitialConsent({ req, ... })` | `resolveConsent({ req, ... })`                             |
-
-TanStack Start (`c15t/tanstack-start`, `c15t/tanstack-start/server`):
-
-| v2                                    | v3                                             |
-| ------------------------------------- | ---------------------------------------------- |
-| `ConsentBoundary`                     | `ConsentRoot`                                  |
-| `config={config}`                     | `state={state}`                                |
-| `ConsentConfig` (the returned state)  | `ConsentState`                                 |
-| `prefetchInitialConsent`              | `resolveConsent(options)` with `backendURL`    |
-| `readInitialConsentConfig`            | `resolveConsent(options)` without `backendURL` |
-| `createConsentConfigHandler(options)` | `createConsentStateHandler(options)`           |
-| `mergeInitIntoConsentConfig`          | `mergeInitIntoConsentState`                    |
-
-`consentLoaderOptions`, `backendURL`, `initRoute` and `DEFAULT_INIT_ROUTE` are
-unchanged.
-
-## Next.js RSC banner removal
-
-The `@c15t/nextjs/rsc` entry (`c15t/next/rsc`) and its `RscConsentBanner`,
-`RscBannerGate` and `RscBannerActions` exports are gone. Imports of that
-entry now fail to resolve. Use the regular banner for server rendering.
-The retained benchmark results showed slightly faster banner visibility and
-interaction for the experimental shell, so this removal should not be read
-as a performance improvement.
-
-Replace `<RscConsentBanner config={config} />` with `<ConsentBanner />` inside
-the same `ConsentRoot`, importing it from `c15t/next` when you use the
-umbrella package or from `@c15t/nextjs` when you depend on the scoped package
-directly. With an awaited `resolveConsent` result, the server renders
-the banner into the response, which is what the RSC variant was for. Move
-`presentation` to `options.presentation` on `ConsentRoot`.
-
-Two defaults differ from the removed shell. It rendered no branding link, so
-pass `hideBranding` to keep that. It also styled only its root and action row
-(through the stock `ConsentBanner.Root` and `PolicyActions`) and left the
-card, title, description, footer and buttons without base classes, whereas
-`ConsentBanner` merges the stock styles into every part. If that changes a
-custom layout, do not reach for `noStyle` on the whole banner, which also
-drops the root positioning and action-row layout the old shell kept; compose
-the compound parts instead and pass `noStyle` only to the parts you styled
-yourself.
-
-`ConsentBanner` has no `classNames` or `children` props. Move each legacy
-`classNames` key to the `ConsentRoot` `options.components` slots, which take
-`{ className }`:
-
-| `classNames` key                                                   | Replacement                                                                                                                                                                                                           |
-| ------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `root`, `card`, `title`, `footer`                                  | `components.banner.root`, `.card`, `.title`, `.footer`                                                                                                                                                                |
-| `description`                                                      | `components.description.banner`                                                                                                                                                                                       |
-| `rights`, `rightLink`                                              | `components.banner.rights`, `components.banner.rightLink`                                                                                                                                                             |
-| `acceptButton`, `rejectButton`, `customizeButton`, `dismissButton` | No per-button slot. Use `components.button.primary` / `.secondary` for shared styles, or target `[data-action="accept"]`, `[data-action="reject"]`, `[data-action="customize"]` and `[data-action="dismiss"]` in CSS. |
-
-Custom `children`, and any direct use of `RscBannerGate` or
-`RscBannerActions`, map to the compound parts of `ConsentBanner` in a Client
-Component. `RscBannerGate` becomes `ConsentBanner.Root`, which mounts only
-while the policy owes a prompt and reopens on expiry. Remove the gate
-`prompt` and `model` props; the root derives `data-prompt` and `data-model`
-from the `ConsentRoot` policy. Rename `title` to `aria-label` to preserve its
-accessible label. Keep `children`, `className`, `variant`, `position` and
-`blocking` on the root. Add `disableAnimation` and `trapFocus={false}` to
-retain the old gate defaults.
-
-`RscBannerActions`
-becomes `ConsentBanner.PolicyActions`, which renders the rights links and the
-action row the policy requires; `ConsentBanner.Rights`, `RightLink`, `Footer`,
-`FooterSubGroup` and the four buttons are available for finer control.
-`PolicyActions` takes none of the old `acceptLabel`, `rejectLabel`,
-`customizeLabel`, `dismissLabel`, `rightLabels` or `classNames` props: set
-labels through the provider `i18n` translation overrides (`common.acceptAll`,
-`common.rejectAll`, `common.customize`, `common.acknowledge`, `rights.*`), or
-render `ConsentBanner.AcceptButton` and the other buttons with your own
-children; `renderAction` on `PolicyActions` replaces one button; classes move
-to the `components` slots listed in the table. Place the former `children`
-inside `ConsentBanner.Card`:
-
-```tsx title="components/banner.tsx"
-'use client';
-
-import { ConsentBanner } from 'c15t/next';
-
-export function Banner() {
-  return (
-    <ConsentBanner.Root>
-      <ConsentBanner.Card>
-        <ConsentBanner.Header>
-          <ConsentBanner.Title />
-          <ConsentBanner.Description />
-        </ConsentBanner.Header>
-        <a href="/privacy">Privacy policy</a>
-        <ConsentBanner.PolicyActions />
-      </ConsentBanner.Card>
-    </ConsentBanner.Root>
-  );
-}
-```

package/readme.json

@@ -1,48 +0,0 @@
-{
-	"title": "@c15t/react: React Consent Components",
-	"description": "React cookie banner, consent manager, preference center, and headless CMP components for modern React apps.",
-	"features": [
-		"Works with React 19, 18, 17, and 16.8",
-		"Full 'use client' support for React Server Components",
-		"Prebuilt and fully customizable cookie banner, consent dialog, and preference center UI",
-		"Headless hooks for custom consent flows",
-		"Minimal configuration with TypeScript-first design",
-		"Comprehensive Consent Management Platform (CMP)",
-		"IAB TCF 2.3 UI and hooks through the @c15t/react/iab subpath",
-		"Google Tag Manager, Google Consent Mode v2, Meta Pixel, and analytics integrations through @c15t/scripts",
-		"Built-in internationalization support",
-		"Seamless consent storage and tracking"
-	],
-	"prerequisites": [
-		"React 16.8 or later",
-		"Node.js 20.19 or later",
-		"A hosted [c15t instance](https://inth.com) (free sign-up), [self-hosted deployment](https://c15t.com/docs/self-host/quickstart), or offline mode for local-only storage"
-	],
-	"manualInstallation": [
-		"",
-		"```bash\npnpm add @c15t/react\n```",
-		"",
-		"Then add the prebuilt stylesheet to your app-level CSS entrypoint:",
-		"",
-		"```css\n/* src/index.css */\n@import \"@c15t/react/styles.css\";\n```",
-		"",
-		"If you use the prebuilt IAB TCF UI, also import `@c15t/react/iab/styles.css`. It is published separately so non-IAB apps do not ship those component rules.",
-		"",
-		"To manually install, follow the guide in our [docs – manual setup](https://c15t.com/docs/frameworks/react/quickstart#manual-setup)."
-	],
-	"usage": [
-		"Import `ConsentManagerProvider` in your app's root component",
-		"Add `ConsentBanner` and `ConsentDialog` components",
-		"Customize styling and behavior to fit your app",
-		"For full implementation details, see the [React quickstart docs](https://c15t.com/docs/frameworks/react/quickstart)",
-
-		"```tsx\n// App.tsx\nimport {\n  ConsentManagerProvider,\n  ConsentBanner,\n  ConsentDialog,\n} from '@c15t/react'\n\nfunction App() {\n  return (\n    <ConsentManagerProvider>\n      <YourApp />\n      <ConsentBanner />\n      <ConsentDialog />\n    </ConsentManagerProvider>\n  )\n}\n```"
-	],
-	"docsLink": "https://c15t.com/docs/frameworks/react/quickstart",
-	"quickStartLink": "https://c15t.com/docs/frameworks/react/quickstart",
-	"showCLIGeneration": true,
-	"customSections": {
-		"Deployment Modes": "- **Hosted on inth.com**: Hosted c15t backend for policy storage, audit history, and hosted infrastructure\n- **Self-hosted backend**: Use @c15t/backend when you need full infrastructure control\n- **Offline mode**: Browser-only consent storage for local development, demos, previews, static sites, or fallback scenarios",
-		"Popular Integrations": "- Google Tag Manager with Google Consent Mode v2\n- Google Analytics 4 and Google Ads through gtag.js\n- Meta Pixel, TikTok Pixel, LinkedIn Insights, Microsoft UET, X Pixel, Reddit Pixel, and Snapchat Pixel\n- PostHog, Segment, Mixpanel, Microsoft Clarity, Hotjar, Plausible, Fathom, Matomo, Umami, and Vercel Analytics\n- Intercom and Crisp chat widgets"
-	}
-}

package/src/iab/styles.css

@@ -1,11 +0,0 @@
-/**
- * @c15t/react — IAB TCF component styles.
- *
- * Add this stylesheet to the same global CSS entrypoint as your base c15t styles
- * when using IAB consent components. Do not import either stylesheet from JS/TSX.
- *
- * Usage (src/index.css):
- *   @import "@c15t/react/styles.css";
- *   @import "@c15t/react/iab/styles.css";
- */
-@import '@c15t/ui/iab/styles.css';

package/src/styles.css

@@ -1,10 +0,0 @@
-/**
- * @c15t/react — Non-IAB prebuilt component styles.
- *
- * Import this stylesheet once from your app-level CSS entrypoint
- * when using prebuilt (styled) consent components.
- *
- * Usage (src/index.css):
- *   @import "@c15t/react/styles.css";
- */
-@import '@c15t/ui/styles.css';