@c15t/react 2.0.0-rc.4 → 2.0.0-rc.6

package/docs/concepts/initialization-flow.md

@@ -0,0 +1,141 @@
+---
+title: Initialization Flow
+description: What happens from provider mount to first render — the full consent lifecycle.
+---
+When the consent provider mounts, it creates a cached consent runtime, reads any stored consent from the browser, fetches the resolved policy from the backend (or uses SSR/offline data), and decides whether to show the banner. This entire sequence completes before the first meaningful consent-aware render.
+
+## Lifecycle Sequence
+
+**Simplified**
+
+1. **Provider mounts** — creates (or retrieves from cache) a consent runtime and store
+2. **Check stored consent** — reads existing consent from cookies / localStorage; if found and the policy fingerprint hasn't changed, the banner stays hidden
+3. **Fetch init data** — calls the backend `GET /init` (or uses SSR/offline data) for the resolved policy, location, and translations
+4. **Apply resolved policy** — the backend resolves the policy from your [policy pack](/docs/frameworks/react/concepts/policy-packs) based on visitor geo (region → country → fallback → default). The response includes the consent model, categories, UI mode, and a material fingerprint. If no policy pack is configured, the legacy jurisdiction-to-model mapping is used instead.
+5. **Decide banner visibility** — shows the banner only if no prior consent exists, the resolved policy requires it (`ui.mode` is `banner` or `dialog`), or the policy fingerprint changed since last consent
+6. **Gating enforced** — scripts, iframes, and network requests tagged with a consent category are blocked until that category is granted
+7. **User interacts** — choices are persisted to storage, synced to the backend (with `policySnapshotToken` if configured), and blocked scripts/iframes load immediately after consent is granted
+
+**Sequence Diagram**
+
+```mermaid
+sequenceDiagram
+    participant Provider as ConsentManagerProvider
+    participant Store as Consent Store
+    participant Storage as localStorage / Cookie
+    participant API as c15t Backend
+    participant UI as Banner / Dialog
+    participant Scripts as Script Loader
+
+    Provider->>Store: getOrCreateConsentRuntime()
+    Store->>Storage: getStoredConsent()
+    alt Stored consent exists
+        Storage-->>Store: consentInfo + consents
+        Store->>Store: activeUI = 'none'
+    else No stored consent
+        Store->>Store: isLoadingConsentInfo = true
+    end
+
+    Store->>Store: initConsentManager()
+    Store->>Storage: Check pending consent sync
+    opt Pending sync from revocation reload
+        Store->>API: Deferred setConsent() (non-blocking)
+    end
+
+    alt SSR data provided
+        Store->>Store: tryUseSSRData()
+    else No SSR data
+        Store->>API: GET /init
+        API-->>Store: policy, policyDecision, location, translations
+    end
+
+    Store->>Store: Apply resolved policy (model, categories, ui.mode)
+    Store->>Store: Check fingerprint change → re-prompt if needed
+    Store->>Store: Set activeUI, auto-grant if opt-out/none
+
+    alt User has no prior consent or policy changed
+        UI->>UI: Banner / Dialog appears (per policy ui.mode)
+        UI->>Store: saveConsents({ type })
+        Store->>Storage: Persist consent + subjectId + fingerprint
+        Store->>Scripts: updateScripts(), updateIframes(), updateNetwork()
+        Store->>API: POST /subjects + policySnapshotToken (non-blocking)
+    end
+```
+
+## How It Works
+
+**Mount** — When the provider renders, it creates (or retrieves from cache) a consent runtime and store. Any existing consent is read from localStorage/cookies immediately. If consent already exists and the policy fingerprint matches, the banner stays hidden and gating rules apply right away. See [Client Modes](/docs/frameworks/react/concepts/client-modes) for how the mode affects runtime creation.
+
+**Init** — The store fetches the resolved policy, location, and translation data. In hosted mode this calls `GET /init` on your backend; in offline mode it resolves from `offlinePolicy.policyPacks` locally. If SSR data was passed to the provider, the network fetch is skipped entirely. See [Server-Side Utilities](/docs/frameworks/react/server-side) for SSR setup.
+
+**Policy resolution** — When [policy packs](/docs/frameworks/react/concepts/policy-packs) are configured, the backend resolves the right policy for the visitor based on their geo-location (region → country → fallback → default). The resolved policy determines the consent model (`opt-in`, `opt-out`, `iab`, or `none`), which categories are in scope, and what UI to show. For `opt-out` and `none` models, all categories are auto-granted — unless the resolved policy has `consent.gpc: true` and the browser sends a Global Privacy Control signal, in which case `marketing` and `measurement` are denied. If no policy pack is configured, the legacy jurisdiction-to-model mapping is used instead. See [Consent Models](/docs/frameworks/react/concepts/consent-models) for details.
+
+**Re-prompting** — If the resolved policy's material fingerprint differs from the fingerprint stored with the user's last consent, the banner is shown again. This happens automatically when you change consent-affecting fields (model, categories, scope mode, allowed actions). Presentation-only changes do not trigger re-prompts. See [Policy Packs — Re-Prompting](/docs/frameworks/react/concepts/policy-packs#re-prompting) for details.
+
+**Save** — When the user interacts with the banner or dialog, their choices are persisted to localStorage/cookies and synced to the backend (along with the `policySnapshotToken` if snapshot signing is configured). Script, iframe, and network gating rules update immediately based on the new consent state. See the [Script Loader](/docs/frameworks/react/script-loader), [Iframe Blocking](/docs/frameworks/react/iframe-blocking), and [Network Blocker](/docs/frameworks/react/network-blocker) guides for gating details.
+
+**Revocation** — If a user revokes a previously granted category, the page reloads by default to ensure a clean execution environment. The API sync is deferred to the fresh page load. See [Cookie Management](/docs/frameworks/react/concepts/cookie-management) for revocation and persistence details.
+
+## When Does the Banner Show?
+
+The banner appears when any of these conditions are true:
+
+1. **No existing consent** — the user has never consented (or their consent was cleared), **and** the resolved policy requires a UI (`ui.mode` is `banner` or `dialog`, or the model is `opt-in` or `iab`)
+2. **Policy changed** — the material policy fingerprint differs from the fingerprint stored with the user's last consent (re-prompting)
+3. **Storage is accessible** — the browser allows localStorage (not blocked in private mode)
+
+If the resolved model is `none` or `opt-out` (and `ui.mode` is `none`), consents are auto-granted and the banner never appears. See [Consent Models](/docs/frameworks/react/concepts/consent-models) and [Policy Packs](/docs/frameworks/react/concepts/policy-packs) for details.
+
+## Debugging the Lifecycle
+
+Use the DevTools panel and callbacks to inspect each step of the initialization flow:
+
+|Step|DevTools Panel|Callback|What to check|
+|--|--|--|--|
+|Init / SSR hydration|Location|`onBannerFetched`|jurisdiction, countryCode, regionCode populated?|
+|Policy resolution|Policy|`onBannerFetched`|`policyId`, `matchedBy`, `fingerprint` in policyDecision|
+|Model resolution|Location|`onBannerFetched`|`model` value matches the resolved policy|
+|Banner visibility|Consents|—|`activeUI` in store state; does policy `ui.mode` require it?|
+|Re-prompting|Policy|—|Fingerprint mismatch between stored and resolved policy?|
+|Consent save|Consents + Events|`onConsentSet`|`preferences` object in callback payload|
+|Script loading|Scripts|`onConsentSet`|Script IDs and their load/blocked status|
+|Reload on revocation|Events|`onBeforeConsentRevocationReload`|Fires before reload; check localStorage for `c15t:pending-consent-sync`|
+|Deferred sync|Events|`onError` (if sync fails)|After reload, check Events panel for successful API call|
+
+Configure callbacks in the provider to log lifecycle events, and add DevTools for a visual inspector:
+
+```tsx
+import { type ReactNode } from 'react';
+import { ConsentManagerProvider, ConsentBanner, ConsentDialog } from '@c15t/react';
+import { DevTools } from '@c15t/dev-tools/react';
+
+export default function ConsentManager({ children }: { children: ReactNode }) {
+  return (
+    <ConsentManagerProvider
+      options={{
+        mode: 'hosted',
+        backendURL: 'https://your-instance.c15t.dev',
+        callbacks: {
+          onBannerFetched: ({ jurisdiction, location }) => {
+            console.log('Init complete:', { jurisdiction, location });
+          },
+          onConsentSet: ({ preferences }) => {
+            console.log('Consent saved:', preferences);
+          },
+          onBeforeConsentRevocationReload: ({ preferences }) => {
+            console.log('Reloading due to revocation:', preferences);
+          },
+          onError: ({ error }) => {
+            console.error('Consent error:', error);
+          },
+        },
+      }}
+    >
+      <ConsentBanner />
+      <ConsentDialog />
+      {process.env.NODE_ENV !== 'production' && <DevTools />}
+      {children}
+    </ConsentManagerProvider>
+  );
+}
+```

package/docs/concepts/policy-packs.md

@@ -0,0 +1,227 @@
+---
+title: Policy Packs
+description: How c15t resolves regional consent policies and what a policy pack controls.
+---
+Different countries need different consent experiences. Policy packs let you define those rules once — c15t picks the right one automatically based on where the visitor is.
+
+A policy pack is an ordered array of policies. Each policy targets a region or country and controls the consent model, which categories are in scope, what UI is shown, and how consent is recorded.
+
+There are three ways to configure policy packs:
+
+1. **consent.io (recommended)** — use [consent.io](https://consent.io) as your hosted backend. Configure packs visually in the dashboard or via API — no code changes required. Works with any frontend, including static sites.
+2. **Self-hosted backend** — define packs in code via `policyPacks` and resolve them from real request geo data. Full control over policy logic and storage.
+3. **Offline fallback** — pass the same policy shapes to the frontend via `offlinePolicy.policyPacks`. Used as a resilience fallback when the backend is unreachable, or for quick local experimentation and demos. If you omit `offlinePolicy.policyPacks`, c15t falls back to a synthetic worldwide opt-in banner instead of no-banner mode.
+
+In both hosted and self-hosted modes, the **backend is always the source of truth**. Offline packs never override a live backend decision.
+
+## Quickstart
+
+The fastest way to get started is with the built-in presets:
+
+```ts
+import { policyPackPresets } from 'c15t';
+
+const policies = [
+  policyPackPresets.europeOptIn(),    // GDPR opt-in banner
+  policyPackPresets.californiaOptOut(), // CCPA opt-out banner
+  policyPackPresets.worldNoBanner(),          // No banner elsewhere
+];
+```
+
+|Preset|Model|UI|Matches|
+|--|--|--|--|
+|`europeOptIn()`|`opt-in`|banner|EEA + UK countries + geo fallback|
+|`europeIab()`|`iab`|banner|EEA + UK countries + geo fallback (TCF 2.3)|
+|`californiaOptOut()`|`opt-out`|none|US-CA region|
+|`quebecOptIn()`|`opt-in`|banner|CA-QC region|
+|`worldNoBanner()`|`none`|none|default fallback|
+
+Most apps only need these presets — pick the ones that match your regions, pass them to your backend config or provider, and you're done. Customize individual fields or write fully custom policies when you need more control.
+
+For banner/dialog actions, policy packs can also control grouped button arrangement:
+
+```ts
+ui: {
+  mode: 'banner',
+  banner: {
+    allowedActions: ['reject', 'accept', 'customize'],
+    layout: [['reject', 'accept'], 'customize'],
+    direction: 'row',
+    primaryActions: ['accept', 'customize'],
+  },
+}
+```
+
+That expresses arrangement only. Button appearance like `stroke`, `filled`, or `ghost` lives in the UI theme.
+
+## What Users See
+
+Each policy combination produces a different consent experience:
+
+|Policy Config|User Experience|
+|--|--|
+|`model: 'opt-in'`, `ui.mode: 'banner'`|Banner appears, nothing loads until the user consents|
+|`model: 'opt-out'`, `ui.mode: 'none'`|No banner, everything loads immediately — user opts out via a "Do Not Sell" link|
+|`model: 'none'`, `ui.mode: 'none'`|No banner, all categories auto-granted silently|
+|`model: 'opt-in'`, `ui.mode: 'dialog'`|Full-screen dialog, nothing loads until the user consents|
+|`model: 'iab'`, `ui.mode: 'banner'`|IAB TCF 2.3 banner with vendor-level controls|
+
+## How Policy Resolution Works
+
+When a visitor arrives, c15t walks the policy pack in priority order:
+
+1. **Match by region** — checks for a policy targeting the specific region (e.g., US-CA, CA-QC)
+2. **Match by country** — if no region match, checks for a country-level policy (e.g., US, DE)
+3. **Fallback (geo failure)** — if geo-location failed (no country detected), uses the policy marked with `match.fallback`
+4. **Fall back to default** — if nothing matches, uses the policy marked as the default
+5. **No match, no default** — resolves to no-banner mode (silent, no consent UI)
+
+Within the same matcher type, the first policy in the array wins. Pack order matters when two policies target the same country or region.
+
+The **fallback** step is distinct from **default**: `isDefault` is a catch-all for known locations that don't match any specific policy ("rest of world"), while `fallback` is a safety net for unknown locations when geo-headers are missing ("assume strictest"). The `europeOptIn()` and `europeIab()` presets include `fallback: true` by default so EU-level consent applies when geo fails.
+
+> ⚠️ **Warning:**
+> Only one default and one fallback policy are allowed. Use inspectPolicies() to surface overlapping matchers and other warnings before deployment.
+
+Inspect the resolved policy at runtime with `useConsentManager()`:
+
+```tsx
+import { useConsentManager } from '@c15t/react';
+
+function PolicyDebug() {
+  const { locationInfo, model, policy, policyDecision } = useConsentManager();
+
+  return (
+    <pre>
+      {JSON.stringify(
+        {
+          country: locationInfo?.countryCode,
+          region: locationInfo?.regionCode,
+          model,
+          policyId: policy?.id,
+          matchedBy: policyDecision?.matchedBy,
+          fingerprint: policyDecision?.fingerprint,
+        },
+        null,
+        2
+      )}
+    </pre>
+  );
+}
+```
+
+## Common Patterns
+
+**The 80% case** — strict in Europe, light in California, silent everywhere else:
+
+```ts
+const policies = [
+  {
+    id: 'eu',
+    match: { countries: ['DE', 'FR', 'IT'] },
+    consent: { model: 'opt-in', categories: ['necessary', 'measurement', 'marketing'] },
+    ui: { mode: 'banner' },
+  },
+  {
+    id: 'ca',
+    match: { regions: [{ country: 'US', region: 'CA' }] },
+    consent: { model: 'opt-out', gpc: true },
+    ui: { mode: 'none' },
+  },
+  {
+    id: 'default',
+    match: { isDefault: true },
+    consent: { model: 'none' },
+    ui: { mode: 'none' },
+  },
+];
+```
+
+**Region overrides country** — stricter rules for California than the rest of the US:
+
+```ts
+const policies = [
+  {
+    id: 'us_ca',
+    match: { regions: [{ country: 'US', region: 'CA' }] },
+    consent: { model: 'opt-in', scopeMode: 'strict' },
+    ui: { mode: 'banner' },
+  },
+  {
+    id: 'us',
+    match: { countries: ['US'] },
+    consent: { model: 'opt-out' },
+    ui: { mode: 'banner' },
+  },
+];
+// US-CA → us_ca (region match wins)
+// US-NY → us (country match)
+```
+
+**Different wording per region** — use `i18n.messageProfile` to vary copy without changing the consent model:
+
+```ts
+const c15t = c15tInstance({
+  i18n: {
+    defaultProfile: 'default',
+    messages: {
+      default: {
+        translations: {
+          en: { cookieBanner: { title: 'Privacy choices' } },
+          es: { cookieBanner: { title: 'Tus opciones de privacidad' } },
+        },
+      },
+      eu: {
+        fallbackLanguage: 'en',
+        translations: {
+          en: { cookieBanner: { title: 'EU GDPR Consent' } },
+          fr: { cookieBanner: { title: 'Consentement RGPD' } },
+          de: { cookieBanner: { title: 'GDPR-Einwilligung' } },
+        },
+      },
+    },
+  },
+  policyPacks: [
+    {
+      id: 'eu',
+      match: { countries: ['DE', 'FR', 'IT'] },
+      i18n: { messageProfile: 'eu' },
+      consent: { model: 'opt-in' },
+      ui: { mode: 'banner' },
+    },
+  ],
+});
+```
+
+In that setup, the `eu` policy uses only the `eu` language set. So Europe can
+resolve to `en`, `fr`, or `de`, but not to `es` or any other locale defined
+only in `default`. If the browser asks for an unsupported locale, c15t falls
+back to the `eu` profile's `fallbackLanguage`.
+
+## Re-Prompting on Policy Change
+
+When you change a policy in a way that affects consent semantics — like adding a category, changing the consent model, or modifying allowed actions — c15t automatically re-prompts returning users.
+
+This works through the **material policy fingerprint**: a hash of only the consent-affecting fields (model, categories, scope, allowed actions, grouped action layout, direction, proof settings). Presentation-only changes like copy, button styling, or scroll lock do not trigger re-prompts.
+
+|Change|Re-prompts?|
+|--|--|
+|Add a consent category|Yes|
+|Change `model` from `opt-out` to `opt-in`|Yes|
+|Remove an `allowedAction`|Yes|
+|Change `uiProfile` or button styling|No|
+|Update translation copy|No|
+|Change `scrollLock`|No|
+
+## Design Guidelines
+
+* **Start from presets.** Use `policyPackPresets` to get running, then customize for your needs.
+* **Keep packs small.** A handful of regional policies is better than dozens of tiny fragments.
+* **Think risk, not geography.** Geography is just a matcher — the real question is what consent behavior each region needs.
+* **Always include a default.** Unless "no banner for unmatched traffic" is intentional.
+* **Set a fallback for geo failures.** Mark your strictest policy with `match.fallback=true` so users in unknown locations still see a consent banner. The `europeOptIn()` and `europeIab()` presets do this automatically.
+* **Keep policy IDs stable.** They appear in debugging output, snapshots, and audit records.
+* **Use `inspectPolicies()` before deploying.** It catches overlapping matchers, missing defaults, and IAB misconfigurations.
+
+> ℹ️ **Info:**
+> For provider setup, see the React policy pack guide. For backend configuration, see the self-host guide.

package/docs/headless.md

@@ -0,0 +1,184 @@
+---
+title: Headless Mode
+description: Build fully custom consent UI using only hooks - no pre-built components required.
+---
+c15t's headless mode means using the hooks (`useConsentManager`, `useTranslations`, etc.) without any pre-built UI components. This gives you complete control over the consent experience.
+
+There are three levels of customization:
+
+1. **Props** - Use pre-built components with custom text and configuration
+2. **noStyle** - Use pre-built components with their structure but strip all styles
+3. **Headless** - Use only hooks and build the entire UI yourself
+
+## When to Go Headless
+
+Go headless when:
+
+* Your design system requires complete control over markup
+* You need a consent flow that doesn't fit the banner/dialog pattern
+* You want to embed consent choices inline rather than as overlays
+
+Use `noStyle` instead when:
+
+* The component structure works but the styling doesn't
+* You want to apply your own CSS/Tailwind without fighting defaults
+
+> ℹ️ **Info:**
+> Need a policy-aware implementation guide? See Building Headless Components.
+
+## Full Example: Custom Consent Banner
+
+```tsx
+import { useConsentManager, useTranslations } from '@c15t/react';
+
+function CustomConsentBanner() {
+  const {
+    activeUI,
+    consents,
+    consentCategories,
+    consentTypes,
+    saveConsents,
+    setSelectedConsent,
+    selectedConsents,
+  } = useConsentManager();
+  const translations = useTranslations();
+
+  if (activeUI !== 'banner') return null;
+
+  const displayedTypes = consentTypes.filter(
+    (t) => consentCategories.includes(t.name) && t.display
+  );
+
+  return (
+    <div className="fixed bottom-0 inset-x-0 bg-white border-t p-6 shadow-lg z-50">
+      <h2 className="text-lg font-semibold">
+        {translations.cookieBanner.title}
+      </h2>
+      <p className="text-sm text-gray-600 mt-1">
+        {translations.cookieBanner.description}
+      </p>
+
+      <div className="mt-4 space-y-3">
+        {displayedTypes.map((type) => (
+          <label key={type.name} className="flex items-center gap-3">
+            <input
+              type="checkbox"
+              checked={selectedConsents[type.name] ?? consents[type.name] ?? false}
+              disabled={type.disabled}
+              onChange={(e) => setSelectedConsent(type.name, e.target.checked)}
+            />
+            <div>
+              <span className="font-medium">
+                {translations.consentTypes[type.name]?.title ?? type.name}
+              </span>
+              <p className="text-xs text-gray-500">{type.description}</p>
+            </div>
+          </label>
+        ))}
+      </div>
+
+      <div className="mt-4 flex gap-3">
+        <button
+          onClick={() => saveConsents('necessary')}
+          className="px-4 py-2 border rounded"
+        >
+          {translations.common.rejectAll}
+        </button>
+        <button
+          onClick={() => saveConsents('custom')}
+          className="px-4 py-2 border rounded"
+        >
+          {translations.common.save}
+        </button>
+        <button
+          onClick={() => saveConsents('all')}
+          className="px-4 py-2 bg-blue-600 text-white rounded"
+        >
+          {translations.common.acceptAll}
+        </button>
+      </div>
+    </div>
+  );
+}
+```
+
+## Usage with Provider
+
+The headless UI still needs a `ConsentManagerProvider`:
+
+```tsx
+import { type ReactNode } from 'react';
+import { ConsentManagerProvider } from '@c15t/react';
+
+export function ConsentManager({ children }: { children: ReactNode }) {
+  return (
+    <ConsentManagerProvider
+      options={{
+        mode: 'hosted',
+        backendURL: 'https://your-instance.c15t.dev',
+        consentCategories: ['necessary', 'measurement', 'marketing'],
+      }}
+    >
+      <CustomConsentBanner />
+      {children}
+    </ConsentManagerProvider>
+  );
+}
+```
+
+## Custom Dialog
+
+Build a custom consent dialog for detailed category management:
+
+```tsx
+import { useConsentManager, useTranslations } from '@c15t/react';
+
+function CustomConsentDialog() {
+  const {
+    activeUI,
+    setActiveUI,
+    consentTypes,
+    consentCategories,
+    selectedConsents,
+    consents,
+    setSelectedConsent,
+    saveConsents,
+    has,
+  } = useConsentManager();
+  const translations = useTranslations();
+
+  if (activeUI !== 'dialog') return null;
+
+  return (
+    <div className="fixed inset-0 z-50 flex items-center justify-center">
+      <div className="absolute inset-0 bg-black/50" onClick={() => setActiveUI('none')} />
+      <div className="relative bg-white rounded-xl p-6 max-w-md w-full">
+        <h2 className="text-lg font-semibold">{translations.consentManagerDialog.title}</h2>
+
+        {consentTypes
+          .filter((t) => consentCategories.includes(t.name))
+          .map((type) => (
+            <div key={type.name} className="flex items-center justify-between py-3 border-b">
+              <div>
+                <p className="font-medium">{translations.consentTypes[type.name]?.title}</p>
+                <p className="text-sm text-gray-500">{type.description}</p>
+              </div>
+              <input
+                type="checkbox"
+                checked={selectedConsents[type.name] ?? consents[type.name] ?? false}
+                disabled={type.disabled}
+                onChange={(e) => setSelectedConsent(type.name, e.target.checked)}
+              />
+            </div>
+          ))}
+
+        <div className="mt-4 flex justify-end gap-2">
+          <button onClick={() => saveConsents('necessary')}>Reject</button>
+          <button onClick={() => saveConsents('custom')}>Save</button>
+          <button onClick={() => saveConsents('all')}>Accept All</button>
+        </div>
+      </div>
+    </div>
+  );
+}
+```

package/docs/hooks/use-color-scheme.md

@@ -0,0 +1,40 @@
+---
+title: useColorScheme
+description: Manage light/dark mode preferences for consent components.
+---
+`useColorScheme()` manages the color scheme preference for c15t components. It sets up the appropriate CSS class and media query listeners.
+
+```tsx
+import { useColorScheme } from '@c15t/react';
+
+function ThemeManager() {
+  useColorScheme('system'); // Follow system preference
+}
+```
+
+## Parameters
+
+|Value|Behavior|
+|--|--|
+|`'light'`|Force light mode|
+|`'dark'`|Force dark mode|
+|`'system'`|Follow `prefers-color-scheme` media query|
+|`null`|Disable - c15t won't manage color scheme|
+|`undefined`|No-op|
+
+## Provider-Level Configuration
+
+You can also set the color scheme on the provider without using this hook:
+
+```tsx
+<ConsentManagerProvider
+  options={{
+    colorScheme: 'system',
+    // ...
+  }}
+>
+```
+
+## System Preference Detection
+
+When set to `'system'`, the hook listens for changes to the `prefers-color-scheme` media query and updates automatically when the user changes their OS theme.

package/docs/hooks/use-consent-manager/checking-consent.md

@@ -0,0 +1,94 @@
+---
+title: Checking Consent
+description: Use has() for flexible consent checks with AND, OR, and NOT logic. Check if any consent exists with hasConsented().
+---
+## has(condition)
+
+The `has()` method evaluates whether the current consent state satisfies a condition. It supports simple category checks and complex logical expressions.
+
+### Simple Check
+
+```tsx
+const { has } = useConsentManager();
+
+if (has('measurement')) {
+  // User has granted measurement consent
+}
+```
+
+### AND Logic
+
+All conditions must be true:
+
+```tsx
+has({ and: ['measurement', 'marketing'] })
+// true only if BOTH measurement AND marketing are granted
+```
+
+### OR Logic
+
+At least one condition must be true:
+
+```tsx
+has({ or: ['measurement', 'marketing'] })
+// true if EITHER measurement OR marketing is granted
+```
+
+### NOT Logic
+
+Negates a condition:
+
+```tsx
+has({ not: 'marketing' })
+// true if marketing consent is NOT granted
+```
+
+### Nested Conditions
+
+Combine operators for complex logic:
+
+```tsx
+has({
+  and: [
+    'necessary',
+    { or: ['measurement', 'marketing'] },
+    { not: 'functionality' },
+  ],
+})
+// true if: necessary AND (measurement OR marketing) AND NOT functionality
+```
+
+### HasCondition Type
+
+```ts
+type HasCondition<CategoryType> =
+  | CategoryType                                    // "measurement"
+  | { and: HasCondition[] | HasCondition }          // { and: ["a", "b"] }
+  | { or: HasCondition[] | HasCondition }           // { or: ["a", "b"] }
+  | { not: HasCondition }                           // { not: "a" }
+```
+
+## hasConsented()
+
+Returns `true` if the user has made any consent choice (accepted, rejected, or customized). Returns `false` if no consent has been recorded yet.
+
+```tsx
+const { hasConsented } = useConsentManager();
+
+if (hasConsented()) {
+  // User has previously made a consent choice
+} else {
+  // First visit — no consent recorded
+}
+```
+
+## getDisplayedConsents()
+
+Returns the consent types that should be displayed in the UI (based on active `consentCategories` and each type's `display` property):
+
+```tsx
+const { getDisplayedConsents } = useConsentManager();
+
+const visibleCategories = getDisplayedConsents();
+// Returns ConsentType[] with name, description, defaultValue, etc.
+```