@c15t/nextjs 2.2.0 → 3.0.0-alpha.0

package/docs/frameworks/next/components/consent-widget.md

@@ -1,138 +1,196 @@
 ---
 title: ConsentWidget
-description: An inline consent management widget for embedding in settings or
-  privacy pages. Shows category toggles with accordion layout.
+description: Render ConsentWidget on a Next.js privacy page inside ConsentRoot
+  as an inline preference center, server-rendered when the route resolves
+  consent.
 group: frameworks
 ---
-`ConsentWidget` is a standalone, inline consent management widget. Unlike `ConsentDialog` (which is a modal), the widget embeds directly in your page layout - ideal for privacy settings pages, account preferences, or any page where users should be able to manage consent without a modal overlay.
 
-## Basic Usage
+## Embed the preference center inline
 
-```tsx
-import { ConsentWidget } from '@c15t/nextjs';
+`ConsentWidget` renders the preference center in the page flow instead of in
+a modal: the category switches and the Reject all, Accept all and Save
+actions, without a title, backdrop or portal. Use it on a privacy or
+settings route where the visitor expects the controls to be part of the
+content. It is a Client Component; render it from any route under the
+layout that mounts the `ConsentRoot` from your
+[App Router](../app-router.md) or
+[Pages Router](../pages-router.md) setup. Keep
+`ConsentDialog` mounted in that root as well so the banner's Customize
+button and preference links still have a dialog to open.
+
+```tsx title="app/privacy/page.tsx"
+import { CookiePreferences } from '../../components/cookie-preferences';
 
-export function PrivacySettingsPage() {
+export default function PrivacyPage() {
   return (
-    <>
-      <h1>Privacy Settings</h1>
-      <p>Manage your cookie preferences below.</p>
-      <ConsentWidget />
-    </>
+    <main>
+      <h1>Privacy</h1>
+      <p>Choose which optional categories this site may use.</p>
+      <section aria-labelledby="cookie-preferences">
+        <h2 id="cookie-preferences">Cookie preferences</h2>
+        <CookiePreferences />
+      </section>
+    </main>
   );
 }
 ```
 
-## Configuration
-
-```tsx
-<ConsentWidget
-  hideBranding
-  legalLinks={['privacyPolicy', 'cookiePolicy']}
-  noStyle={false}
-  disableAnimation={false}
-/>
-```
-
-## Accordion Behavior
-
-Each consent category is rendered as an expandable accordion item. Clicking the category header expands it to show a description and any associated services. Users can toggle individual categories on or off using the switch control. The `necessary` category is always enabled and cannot be toggled.
+```tsx title="components/cookie-preferences.tsx"
+'use client';
 
-## Styling First
+import { ConsentWidget } from 'c15t/next';
 
-> ℹ️ **Info:**
-> Most widget customization should stay in the stock component. Use theme tokens and slots such as consentWidgetAccordion, consentWidgetFooter, consentWidgetFooterSubGroup, and toggle before reaching for compound components. See Styling Overview.
-
-```tsx
-<ConsentManagerProvider
-  options={{
-    theme: {
-      colors: {
-        surface: '#fffdf8',
-        surfaceHover: '#f6f3ee',
-      },
-      slots: {
-        consentWidgetAccordion: 'rounded-3xl border border-black/10',
-        consentWidgetFooter: 'border-t border-black/10 px-6',
-        consentWidgetFooterSubGroup: 'gap-3',
-        toggle: 'shadow-sm',
-      },
-    },
-  }}
->
-  <ConsentWidget />
-</ConsentManagerProvider>
+export function CookiePreferences() {
+  return <ConsentWidget />;
+}
 ```
 
-Use `consentWidgetFooter` for styling the whole action area, such as border and padding. Use `consentWidgetFooterSubGroup` for spacing or alignment inside nested button groups.
-
-Widget copy should be changed through `ConsentManagerProvider.options.i18n` so the inline UI stays aligned with the rest of the consent experience.
+The page stays a Server Component; only the widget file needs
+`'use client'`. On routes where `ConsentRoot` receives the visitor's resolved
+state from an awaited `resolveConsent` (the App Router layout, or a
+Pages Router page with `getServerSideProps`), the widget is part of the server
+HTML with the visitor's recorded choices applied, unlike `ConsentDialog`,
+which mounts after hydration. On a static or otherwise non-prefetched route the
+widget renders after the browser resolves policy. The widget uses the
+boundary's policy, translations and transport; it does not need a second
+provider, and it does not open or close the banner or dialog by itself.
 
-## Advanced: Compound Components
-
-Use compound components only when you need to rearrange the widget's existing primitives while keeping policy-aware action grouping:
-
-```tsx
-<ConsentWidget.Root>
-  <ConsentWidget.Accordion type="multiple">
-    <ConsentWidget.AccordionItems />
-  </ConsentWidget.Accordion>
-  <ConsentWidget.PolicyActions />
-</ConsentWidget.Root>
-```
+## Props
 
-* `ConsentWidget.Root` — Theme context provider
-* `ConsentWidget.Accordion` — Radix-based accordion root
-* `ConsentWidget.AccordionItems` — Auto-generates toggle items from consent config
-* `ConsentWidget.AccordionItem` — Individual category item
-* `ConsentWidget.AccordionTrigger` — Clickable header for each item
-* `ConsentWidget.AccordionContent` — Collapsible content area
-* `ConsentWidget.AccordionArrow` — Expand/collapse indicator
-* `ConsentWidget.Switch` — Category toggle switch
-* `ConsentWidget.PolicyActions` — Renders grouped policy-aware actions
-* `ConsentWidget.Footer` — Footer container
-* `ConsentWidget.FooterSubGroup` — Groups related buttons
-* `ConsentWidget.AcceptAllButton` — Accepts all consent
-* `ConsentWidget.RejectButton` — Rejects all consent
-* `ConsentWidget.SaveButton` — Saves custom selections
-
-## Using `renderAction` with c15t Defaults
-
-`ConsentWidget.PolicyActions` renders stock c15t buttons and translations by default.
+| Prop               | Type      | Default    | Description                                                                                                 |
+| ------------------ | --------- | ---------- | ----------------------------------------------------------------------------------------------------------- |
+| `hideBranding`     | `boolean` | `true`     | A standalone widget hides the "Secured by" tag. Pass `false` to show it.                                    |
+| `uiSource`         | `string`  | `'widget'` | Source identifier recorded with saves made from this widget. Inside `ConsentDialog` it inherits `'dialog'`. |
+| `disableAnimation` | `boolean` | `false`    | Skips animations in the widget's parts.                                                                     |
+| `noStyle`          | `boolean` | `false`    | Removes the built-in styling from every part.                                                               |
+
+## Behavior
+
+The widget is the preference center without the modal around it: an
+accordion with one row per category, each with a switch, followed by the
+Reject all, Accept all and Save actions. `ConsentDialog` renders this same
+widget inside its card. Standalone, the widget renders in place, takes part
+in server rendering, and does not touch the active surface, so it suits a
+privacy page or an account settings screen.
+
+The rows are `necessary` plus the categories in the active policy's scope,
+narrowed to the provider `options.consentCategories` when that list is non-empty.
+The `necessary` switch is on and disabled. Row titles and descriptions come
+from `consentTypes.<category>.title` and `.description`; the action labels
+from `common.rejectAll`, `common.acceptAll` and `common.save`. One row is
+expanded at a time.
+
+### Draft and save
+
+Switches edit a draft, not the visitor's permissions. Nothing is recorded
+until Save. The draft seeds each category from the recorded choice; without
+one it uses `presentation.preferences.defaults` from the provider options,
+and without that it is on under an opt-out rule and on only for the rule's
+preselected categories under an opt-in rule. Save records the displayed
+categories, then reseeds the draft from the new record. Accept all and
+Reject all record immediately without a separate Save. A save answers a
+choice prompt, so an open choice banner closes; it does not dismiss a
+`notice` prompt, which keeps its own acknowledgement record. Unsaved toggles
+are lost when the widget unmounts.
+
+When the policy changes in a way that affects the choice while the draft has
+unsaved toggles, the widget shows an alert, "The privacy policy changed.
+Review the current choices before saving.", with a Review choices button
+that resets the draft. Save is refused until then. A draft without unsaved
+toggles reseeds silently.
+
+A saved grant that the current policy or a privacy signal such as Global
+Privacy Control overrides shows a note under its row: "Your saved choice is
+restricted by the current privacy settings." The switch still reflects the
+saved value; the effective permission is off.
+
+### Actions
+
+The preference center always renders Reject all, Accept all and Save, with
+Save as the primary action. `presentation.preferences.layout`,
+`primaryActions`, `direction` and `uiProfile` in the provider options
+reorder and restyle them; a layout that omits one of the three has it
+restored. Customize and dismiss actions never render here.
+
+### When consent is not owed
+
+Without a resolved policy rule the widget renders nothing and appears as
+soon as a rule resolves, without a remount. A rule with `model: 'none'` and
+an empty `rights` list renders nothing; a `none` rule that lists any right,
+such as `['disclosure']`, renders the widget and Save completes without
+writing a consent record.
+
+For a fully custom preference center, `useConsentDraft()` returns the same
+draft: `values`, `displayedCategories`, `isDirty`, `isStale`, `set`,
+`update`, `acceptAll`, `rejectAll`, `save` and `reset`.
+
+The `useConsentDraft` hook and `ConsentDraftProvider` component import from
+`c15t/next`. Use them in Client Components.
+
+## Accessibility
+
+Each row is a disclosure: a button that expands the category description
+and a switch beside it, so a visitor can read the description without
+changing the choice. Each switch has the category title as its accessible
+name. The policy-change alert uses `role="alert"`, and a restriction note is
+an `output` element linked to its switch through `aria-describedby`. The
+root's `dir` attribute follows the active language.
+
+## Composition
+
+Every part is available as `ConsentWidget.<Part>`. `Root` provides the
+draft and accepts `noStyle`, `disableAnimation` and `uiSource`. `Accordion`
+and `AccordionItems` render the stock rows; `AccordionItem`,
+`AccordionTrigger`, `AccordionTriggerInner`, `AccordionContent`,
+`AccordionArrow` and `Switch` build your own. `PolicyActions` renders the
+resolved actions in `Footer` and `FooterSubGroup` and accepts `renderAction`
+to replace one button; `AcceptAllButton`, `RejectButton`, `SaveButton` and
+`CustomizeButton` are the individual buttons.
+
+`Accordion` is controlled: pass `value` and `onValueChange`, or no
+category description ever opens. The stock `ConsentWidget` holds that state
+for you. In this component, `ConsentWidget` comes from the same import as
+the example at the top of the page:
 
 ```tsx
-<ConsentWidget.PolicyActions />
-```
+import { useState } from 'react';
 
-`renderAction` is optional. Return the stock button compounds when you want custom mapping while preserving built-in c15t behavior and copy:
+export function PreferenceCenter() {
+  const [open, setOpen] = useState<string[]>([]);
 
-```tsx
-<ConsentWidget.PolicyActions
-renderAction={(action, props) => {
-  const { key, ...buttonProps } = props
-
-  switch (action) {
-    case 'accept':
-        return <ConsentWidget.AcceptAllButton key={key} {...buttonProps} />
-    case 'reject':
-        return <ConsentWidget.RejectButton key={key} {...buttonProps} />
-    case 'customize':
-        return <ConsentWidget.SaveButton key={key} {...buttonProps} />
-  }
-}}
-/>
+  return (
+    <ConsentWidget.Root>
+      <ConsentWidget.Accordion
+        value={open}
+        onValueChange={(next) => setOpen(Array.isArray(next) ? next : [next])}
+      >
+        <ConsentWidget.AccordionItems />
+      </ConsentWidget.Accordion>
+      <ConsentWidget.PolicyActions />
+    </ConsentWidget.Root>
+  );
+}
 ```
 
-`renderAction` is still meant for stock button compounds. If you want completely custom button elements and handlers, use `useHeadlessConsentUI()` and render `dialog.actionGroups` manually instead of `ConsentWidget.PolicyActions`.
-
-For a fixed footer layout, render `ConsentWidget.Footer` and `ConsentWidget.FooterSubGroup` manually instead of using `ConsentWidget.PolicyActions`.
-
-If the stock widget structure is already correct, stay with tokens and slots instead of rebuilding the layout.
-
-## Props
-
-|Property|Value|
-|:--|:--|
-|Type Name|\`ConsentWidgetProps\`|
-|Source Path|\`./packages/react/src/components/consent-widget/types.ts\`|
-
-\*ExtractedTypeTable: Could not extract "ConsentWidgetProps" from "./packages/react/src/components/consent-widget/types.ts" using base path "/home/runner/work/c15t/c15t". Verify the path/name and that the file is included by your tsconfig.\*
+Provider component slots for the stock structure are `manager.root`,
+`manager.footer`, `manager.actionGroup`, `accordion.root`,
+`accordion.triggerRow`, `accordion.title`, `accordion.control`,
+`accordion-item.root`, `accordion-item.trigger`, `accordion-item.content`
+and `tag.manager`.
+
+The compound parts import from `c15t/next` as properties of `ConsentWidget`.
+Server Components cannot render them: keep the composition in a file with
+`'use client'`. See [Styling](../styling/overview.md) for slots and tokens.
+
+## Verify
+
+Visit the page with the widget. Use a displayed optional category whose permission is
+not restricted by policy or privacy signals such as GPC. One row per displayed
+category appears, with `necessary` on and disabled. Turn that category on:
+`useConsent('<category>')`
+elsewhere on the page still reports the old value. Choose Save: it now
+reports `true`. An open choice banner closes when the save answers its
+prompt; a notice banner stays open until acknowledged. Reload the page: the
+switch keeps the saved value. Without a saved choice or configured draft
+defaults, optional switches start on under an opt-out rule.

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

@@ -1,64 +1,224 @@
 ---
 title: DevTools
-description: A development tool for inspecting consent state, geolocation,
-  loaded scripts, and consent events in real time.
+description: Load the c15t DevTools panel only in Next.js development builds to
+  inspect consent state, scripts, policy and events inside ConsentRoot.
 group: frameworks
 ---
-`DevTools` is a floating panel that shows the internal state of the consent manager. Use it during development to inspect consent values, geolocation results, loaded scripts, and debug consent flows. Also exported as `C15TDevTools` if you need to avoid naming conflicts with other devtools.
+
+`DevTools` is a floating panel for the c15t v3 kernel. Use it during development to inspect consent values, scripts, location, the resolved policy, IAB state, events, and consent actions. The framework adapter reads the kernel from the nearest v3 provider. It never discovers a store through a window global.
 
 > ⚠️ **Warning:**
-> DevTools should only be included in development builds. The component renders nothing to the React tree - it injects directly into document.body.
+> Load DevTools only in development. A conditional JSX expression stops it from mounting in production, but a static import can still add DevTools to the production bundle. Use a development-only dynamic import as shown below. The component renders nothing into the React tree and mounts its panel in document.body.
 
 ## Installation
 
-DevTools lives in a separate package to keep it out of production bundles:
-
-```bash
-bun add -D @c15t/dev-tools
-```
+No extra package is required for a framework adapter. The adapter and its
+engine are included with the `c15t` package and the dedicated
+`@c15t/svelte` adapter. Install `@c15t/dev-tools` directly only
+when you need the imperative `createDevTools({ kernel })` API.
 
 ## Usage
 
-```tsx
-import { type ReactNode } from 'react';
-import { ConsentManagerProvider } from '@c15t/nextjs';
-import { DevTools } from '@c15t/dev-tools/react';
+Keep the `ConsentRoot` from your router setup. Add this client component as
+one of its children, alongside the banner and dialog. It uses the existing
+runtime, including its prefetch result and configured transport.
 
-export function ConsentManager({ children }: { children: ReactNode }) {
-  return (
-    <ConsentManagerProvider options={{ mode: 'hosted', backendURL: '/api/c15t' }}>
-      {children}
-      {process.env.NODE_ENV === 'development' && <DevTools />}
-    </ConsentManagerProvider>
-  );
+```tsx title="components/consent-dev-tools.tsx"
+'use client';
+
+import dynamic from 'next/dynamic';
+
+const DevTools =
+  process.env.NODE_ENV === 'development'
+    ? dynamic(() => import('c15t/next/devtools').then(({ DevTools }) => DevTools), {
+        ssr: false,
+      })
+    : () => null;
+
+export function ConsentDevTools() {
+  return <DevTools />;
 }
 ```
 
+Import `ConsentDevTools` into your existing consent wrapper or App Router layout
+and render `<ConsentDevTools />` inside `ConsentRoot`. Keep its `state`,
+`config` and other props unchanged. A setup that uses `ConsentProvider`
+directly can place the same component inside that provider.
+
+The umbrella import is `c15t/next/devtools`. When installing the dedicated
+Next.js package, use `@c15t/nextjs/devtools`.
+
 ## Configuration
 
 ```tsx
 <DevTools
-  position="bottom-right"  // 'top-left' | 'top-right' | 'bottom-left' | 'bottom-right'
-  defaultOpen={false}       // Start with panel open
-  namespace="c15tStore"     // Store namespace to connect to
-  disabled={false}          // Disable without removing from tree
+  position="bottom-right"
+  defaultOpen={false}
+  defaultTab="consents"
+  maxEvents={100}
+  disabled={false}
 />
 ```
 
+`position` accepts any corner: `top-left`, `top-right`, `bottom-left`, or
+`bottom-right`. Set `defaultOpen` to open the initial panel and `defaultTab`
+to choose that panel. `maxEvents` limits captured kernel and script events.
+Set `disabled` to prevent mounting without removing the component.
+
 ## Panels
 
-|Panel|What it shows|
-|--|--|
-|**Consents**|Current consent state for all categories|
-|**Location**|Detected jurisdiction, country, region, and consent model|
-|**Scripts**|Configured scripts and their load status|
-|**IAB**|IAB TCF state (when enabled) - TC string, vendor consents, purposes|
-|**Events**|Timeline of consent events and state changes|
-|**Actions**|Buttons to trigger consent actions (accept all, reject all, reset)|
+Accept and reject apply only to categories displayed by the provider, leaving
+hidden consent values unchanged. `necessary` always remains enabled. Svelte
+and Vue adapters use their provider's displayed categories; the kernel and
+React adapter use the current policy categories by default.
+
+For an imperative integration with a narrower UI, pass
+`getConsentCategories: () => ['necessary', 'measurement']` to
+`createDevTools`. The getter is read again when an action runs. Headless UI
+actions can use `kernel.commands.save('all', { categories: displayed })` or
+`kernel.commands.save('none', { categories: displayed })`. These scoped bulk
+saves use a `custom` transport action when they cover only part of the policy.
+Actions covering the whole policy retain `all` or `necessary`. Without an
+explicit scope or policy categories, bulk saves cover all known categories.
+
+| Panel        | What it shows                                                                                |
+| ------------ | -------------------------------------------------------------------------------------------- |
+| **Consents** | Inspect and save categories, accept all, or reject optional categories                       |
+| **Scripts**  | Configured scripts, loading status, search, and external page resources                      |
+| **Location** | Detected jurisdiction, country, region, and consent model                                    |
+| **Policy**   | Resolved policy and UI configuration                                                         |
+| **IAB**      | Edit vendors, purposes, legitimate interests, and special features; save and copy TC strings |
+| **Events**   | Timeline of consent changes, kernel events, and script lifecycle events                      |
+| **Actions**  | Show the banner, open preferences, hide consent UI, or refresh consent data                  |
+
+### Script inspection
+
+Set `defaultTab="scripts"` to open script inspection first. It reads all script
+loaders attached to the current provider's kernel, including loaders created
+before DevTools mounts. Search by script ID, category, URL, or status, then
+expand a script to inspect its configuration and latest lifecycle event.
+
+`loading` means an external script was inserted; `loaded` means its browser
+load event fired, or an inline script or callback-only integration mounted.
+`error` reports a loader error. `blocked` means consent requirements were not
+met, and `pending` means an eligible script has not mounted. `present` means
+the loader reused an element without a confirmed load result. `retained`
+means consent was revoked but `persistAfterConsentRevoked` kept the element.
+Retained scripts still receive `onConsentChange` with `hasConsent: false`, so
+their integrations can send the vendor's consent-revocation command.
+`alwaysLoad` bypasses the loading gate, not consent: callbacks receive the
+actual consent state and updates across categories for integrations such as
+Google Consent Mode.
+
+Script details distinguish `allowedToLoad` from `consentGranted`. An
+`alwaysLoad` integration can be allowed to load while its consent is denied.
+Diagnostics expose these as `eligible` and `hasConsent`, respectively.
+
+Lifecycle diagnostics work even when legacy debug forwarding is disabled.
+The page scan lists external scripts and iframes present in the
+DOM; it does not prove that they loaded successfully or were consent-gated.
+
+For custom inspection tools, import `getScriptDiagnostics(kernel)` and
+`subscribeScriptDiagnostics(kernel, listener)` from
+`c15t/modules/script-loader`. The subscription reports loader
+registration, updates, disposal, and lifecycle events. Read a fresh snapshot
+after changes and call the returned unsubscribe function during cleanup.
+
+### IAB editing
+
+Under an IAB policy, the Consents tab is read-only. Edit and save vendors
+and purposes in the IAB tab so the derived categories and TC string stay
+consistent.
+
+The IAB panel connects to the existing `@c15t/iab` module attached to the
+provider's kernel. It does not create a second CMP or replace `__tcfapi`.
+Controls become available after initialization, when the current policy uses
+IAB and the vendor list is loaded.
+
+Choose Vendors, Purposes, or Special features, then search by name or ID.
+Vendors include the provider's custom vendors. Long lists show 20 entries per
+page. Legitimate-interest controls appear for declared legitimate interests.
+Search only filters the view; Accept all IAB and Reject all IAB apply to the
+configured choices, including custom vendors.
+
+Toggles update live IAB state and script gating immediately. Use Save IAB
+consent to generate a fresh TC string and run the configured save transport.
+The panel displays the last generated string; unsaved edits are not represented
+in it. Copy TC string confirms success or reports clipboard failures. Raw IAB
+data remains available in an expandable section.
+
+IAB saves normally write the TC string to its standard cookie and localStorage.
+For an in-memory playground, set `persistence: false` in the IAB module options
+as well as disabling the provider's core persistence. The IAB option prevents
+TC-string storage writes; it does not disable the configured save transport
+or remove previously stored values.
+
+Save and refresh actions show pending, success, and failure feedback. Controls
+are disabled while a request is pending. A failed save does not roll back the
+live choices; retry to record them.
+
+For custom inspection tools, `getIABControls(kernel)` and
+`subscribeIABControls(kernel, listener)` are exported from `c15t`.
+The getter returns undefined before module initialization and after disposal.
+A snapshot without an attached IAB module is read-only in DevTools.
+
+## Vue and Svelte
+
+Vue imports `ConsentDevTools` from `c15t/vue/devtools`.
+Render it in the app where the c15t plugin provides
+the kernel. In Nuxt, the configured c15t module provides that context.
+
+```vue
+<script setup lang="ts">
+import { defineAsyncComponent } from 'vue';
+
+const DevTools = import.meta.env.DEV
+  ? defineAsyncComponent(() => import('c15t/vue/devtools'))
+  : null;
+</script>
+
+<template>
+  <DevTools v-if="DevTools" position="bottom-right" />
+</template>
+```
+
+In Nuxt, use `import.meta.dev` instead of `import.meta.env.DEV`.
+Svelte imports the adapter from `@c15t/svelte/devtools` and renders it
+inside `ConsentManagerProvider`.
+
+```svelte
+<script lang="ts">
+  import { ConsentManagerProvider, offline } from '@c15t/svelte';
+
+  const devTools = import.meta.env.DEV
+    ? import('@c15t/svelte/devtools')
+    : null;
+</script>
+
+<ConsentManagerProvider options={{ mode: offline() }}>
+  {#if devTools}
+    {#await devTools then { ConsentDevTools }}
+      <ConsentDevTools position="bottom-right" />
+    {/await}
+  {/if}
+</ConsentManagerProvider>
+```
+
+Both adapters accept `position`, `defaultOpen`, `defaultTab`, `maxEvents`,
+`shadow` (`false` renders into the page instead of a shadow root),
+and `getConsentCategories`. Changing these presentation options recreates
+the panel and clears its event history. They do not accept React's `disabled`
+prop; conditionally render them instead. Unmounting removes the panel and
+subscriptions without changing consent.
 
 ## TanStack Devtools
 
-`@c15t/dev-tools/tanstack` exposes a panel component and plugin factory that match TanStack Devtools' plugin API, so c15t can sit beside Query and Router without a custom mount adapter:
+Each embedded panel owns its event history and subscriptions. Unmounting it
+destroys the instance; remounting starts a new history. If you need to capture
+events while switching plugins, keep the c15t panel mounted. This differs from
+the old globally shared DevTools store.
+
+The React v3 DevTools adapter exports a panel component and plugin factory that match TanStack Devtools' plugin API:
 
 ```tsx
 import * as React from 'react';
@@ -66,7 +226,7 @@ import { useRouter } from '@tanstack/react-router';
 import { TanStackDevtools } from '@tanstack/react-devtools';
 import { ReactQueryDevtoolsPanel } from '@tanstack/react-query-devtools';
 import { TanStackRouterDevtoolsPanel } from '@tanstack/react-router-devtools';
-import { c15tDevtools } from '@c15t/dev-tools/tanstack';
+import { c15tDevtools } from 'c15t/react/devtools';
 
 export function AppDevtools() {
   const router = useRouter();
@@ -89,11 +249,10 @@ export function AppDevtools() {
 }
 ```
 
-## Props
+In a Next.js app, import `c15tDevtools` from `c15t/next/devtools` instead. Scoped installs use `@c15t/react/devtools` and `@c15t/nextjs/devtools`.
 
-|Property|Value|
-|:--|:--|
-|Type Name|\`C15TDevToolsProps\`|
-|Source Path|\`./packages/dev-tools/src/react.ts\`|
+## Props
 
-\*ExtractedTypeTable: Could not extract "C15TDevToolsProps" from "./packages/dev-tools/src/react.ts" using base path "/home/runner/work/c15t/c15t". Verify the path/name and that the file is included by your tsconfig.\*
+| Property | Type                | Description                                 | Default | Required |
+| :------- | :------------------ | :------------------------------------------ | :------ | :------: |
+| disabled | boolean \|undefined | Prevents the DevTools engine from mounting. | false   | Optional |