@c15t/react 3.1.0-canary.0 → 3.2.0-canary.0

package/docs/concepts/consent-state.md

@@ -63,6 +63,23 @@ If your own scripts depend on such a category, do one of these:
 Check `effectivePermissions` after Accept All on a fresh visit to see which
 categories your vendor list leaves denied.
 
+## A subject ID from the first page load
+
+Every visitor gets a subject ID (`sub_…`) before they decide anything, so
+you can link activity to the visitor from the first page load and still
+find it when they opt out later. It is in `snapshot.subject.subjectId` from
+the first snapshot.
+
+* A framework server sets the ID in the `c15t-sid` cookie on the first
+  response, where the adapter's server hook runs. Otherwise the browser
+  creates it when c15t starts and stores it in `c15t-sid` at once.
+* The ID stays the same across reloads. The first save records the same ID
+  with the choice.
+* `c15t-sid` is not a choice. A visitor with only an ID still sees the
+  banner.
+* Clearing choices and revoking consent keep the ID. Only setting the subject
+  to `null` starts over with a new one.
+
 ## When a choice is saved
 
 A save records the choice in the browser first and sends it to the backend
@@ -136,6 +153,18 @@ writes the v3 format. The upgrade guides for
 [JavaScript](https://c15t.com/docs/frameworks/javascript/upgrade-v3#keep-visitors-existing-choices)
 cover how v3 treats v2 records.
 
+## Retry interrupted saves
+
+Before sending a recorded choice to the backend, c15t puts it in a localStorage
+queue. If the page closes while the request is in flight, the next initialization
+retries it with the original decision time. A successful response removes the
+queued choice. A permanent rejection, such as a stale policy, removes it too.
+
+Queueing depends on the browser allowing storage. When storage is unavailable,
+c15t still attempts the request, but cannot preserve an interrupted request for
+the next page. A locally remembered choice alone does not prove that the backend
+received it; check the saved consent record in Inth.
+
 ## Keep open tabs in step
 
 Tabs and windows on the same origin (scheme, host and port) share the consent
@@ -192,10 +221,12 @@ Stored records are merged into the ones in memory:
   wins in both tabs.
 * Tabs keep one subject. A stored subject is considered only when the record
   that carries it changed, never on focus alone. It replaces a subject the tab
-  generated on its first save or copied from storage, so a tab that opened
-  before another tab stored a subject joins it. A subject id the server
-  resolved (at init, from a prefetch or in a save response) is replaced only by
-  a strictly newer stored choice, and an identity set with `identify()` is
+  generated at startup or on its first save, or copied from storage, so a tab
+  that opened before another tab stored a subject joins it. When it replaces
+  an ID the tab generated at startup and never used, the kernel emits
+  `subject:resolved` with `previousSubjectId`. A subject id the server
+  resolved (at init, from a prefetch or in a save response) is replaced only
+  by a strictly newer stored choice, and an identity set with `identify()` is
   never replaced.
 * Under an IAB policy, the TC string follows the reconciled choice. See
   [How the TC string is reconciled](#how-the-tc-string-is-reconciled).
@@ -269,11 +300,13 @@ wherever it turns up. A decision stamped in the very millisecond of the clear
 counts only if it comes from a tab that had already seen that clear, so a tab's
 own choice right after its own clear stands while another tab's decision in the
 same millisecond does not. A stored record left with no decisions after the
-clear is void too, subject included.
+clear is void too, subject included. The subject ID itself survives the clear:
+it lives in its own key, `c15t-sid`, which clearing never removes, so a
+withdrawal stays linked to the same visitor.
 
 * A tab that reconciles only after another tab cleared and saved again drops
-  its pre-clear decisions instead of merging them back. Its subject from before
-  the clear is dropped too.
+  its pre-clear decisions instead of merging them back. The external identity
+  linked to its subject before the clear is dropped too; the subject ID stays.
 * A tab that missed the clear writes only decisions it made after it. Its queued
   write of an earlier decision is discarded, so it cannot bring back a cleared
   record.
@@ -336,13 +369,38 @@ When a server render seeded the page from the consent cookie
 localStorage is still applied on top of it when the page mounts, since it can
 only restrict, if it is newer than the seeded decision or from the same
 millisecond as a seeded grant. A stored grant is not.
+`persistence: { skipHydration: false }` reads storage back over the seed
+instead, so an older stored decision replaces it. A server render then starts
+no scripts from the HTML, since it can't tell what that read will return.
 
 The notice dismissal and vendor denials are stored twice as well. A vendor
 list in localStorage at least as new as the cookie's adds its denials but never
 lifts one the cookie holds; a copy confirmed before the last clear is ignored, so its
 denials never come back. The newer notice dismissal applies; it still only hides a
-notice with the fingerprint it names. The consent record follows the rules
-below.
+notice with the fingerprint it names.
+
+Every notice acknowledgement also stores the visitor's subject ID with it,
+including a choice that acknowledges a notice. For a visitor whose only action
+was acknowledging a prompt that offers only necessary categories, this record
+is what keeps the ID. The acknowledgement still grants no optional category. The `<key>-notice` cookie keeps its v1 format, so older
+runtimes still read it. A separate `<key>-notice-subject` cookie binds the
+subject ID to that acknowledgement: readers use it only while its timestamp and
+fingerprint match the notice, so removing or replacing the notice makes a stale
+identity cookie ineffective. When the subject ID changes, through a save
+response or `set.subjectId()`, c15t rewrites the acknowledgement with the new
+ID, so a reload does not bring the old one back. For the same acknowledgement,
+the cookie identity wins unless a failed cookie write left a newer local
+identity or a local identity removal. That exception lasts only while both
+notice cookies match the values observed after the failed write; a later server
+or sibling-subdomain cookie update takes precedence. Category-based data cleanup
+protects these records and `<key>-sid` even when a configured wildcard matches
+their names.
+
+Clearing the stored records removes the acknowledgement and its
+`<key>-notice-subject` cookie. The subject ID stays in `<key>-sid`, as after any
+other clear. External identity fields supplied through `identify()` go with the
+record that carried them. Call `set.subjectId(null)` to give the visitor a new
+ID. The consent record follows the rules below.
 
 The consent record is stored twice: as a cookie, which a server render reads,
 and in localStorage. The cookie is authoritative. A well-formed cookie wins
@@ -373,6 +431,32 @@ render still reads the old consent cookie until the next successful cookie
 write. The same applies to a consent cookie set with a different `domain` than
 the current `storageConfig` uses, which the clear cannot remove.
 
+The subject ID follows the same split. When its cookie writes succeed, the
+server render and the browser use the same ID. When the browser refuses the
+rewrite of a record cookie after the subject ID changed (the consent cookie,
+`c15t-vendors` or `c15t-notice-subject`), that cookie keeps the old ID while
+localStorage holds the new one. A server render then reports the old ID, and
+the browser starts with the new ID from its storage. This happens even when the
+request's `c15t-sid` cookie already holds the new ID. It lasts until a later
+write of that record reaches the cookie, which may never happen while the
+browser keeps refusing it. The server never replaces a `c15t-sid` cookie the
+request already has with the old ID. When this browser's storage holds the
+newer ID, the browser does not store the old one again either.
+
+The vendor record has a separate limit. A local vendor copy at least as new as
+the cookie's keeps its subject ID, and a rekey to a new subject ID keeps the
+original decision time. So with `crossSubdomain`, a visitor whose only record is
+a vendor decision (no consent record) can hold a local copy and a shared cookie
+copy with the same time but different subject IDs, for example after another
+subdomain rekeyed it at any later moment. This origin then starts with the ID
+from its local copy, on server-rendered loads as well as loads that hydrate. It
+does not write that ID over the shared `c15t-sid` cookie when that cookie and
+the record cookies agree on another ID. A later vendor save from this origin
+does store its ID in the shared vendor cookie, where the other subdomains read
+it. Once that cookie carries it, this origin can also write it to the shared
+`c15t-sid` cookie on a later page load. No optional category is granted and no
+denial is lifted.
+
 ### Ordering with pending writes
 
 A tab writes its own choices in a later task, not during the click. Before it

package/docs/concepts/data-fetching.md

@@ -1,7 +1,7 @@
 ---
 title: Data fetching
 description: Choose the recommended build-time policy snapshot or runtime
-  manifest fetching, backend /init, browser resolution or offline rules, and
+  manifest fetching, backend /init, browser resolution or local rules, and
   understand where consent choices are saved.
 group: concepts
 ---
@@ -10,18 +10,18 @@ group: concepts
 
 Where policy resolves and where choices are saved are separate from who runs
 the backend. Inth and a [self-hosted backend](https://c15t.com/docs/self-host/quickstart) speak
-the same protocol, so every path below works with either. Only `offline()`
+the same protocol, so every path below works with either. Only `local()`
 removes backend requests. For a recommendation by framework, start with
 [choose your setup](./choose-your-setup.md).
 
-| Fetching path                                             | Where policy resolves                                                                        | Where choices are submitted | Choose it when                                                                                                                                       |
-| --------------------------------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Build-time manifest, recommended for server-rendered apps | Your server resolves a bundled policy snapshot with each visitor's inputs                    | Inth or your c15t backend   | Your framework renders on the server, supports a build integration, and policy changes can ship with a rebuild                                       |
-| Cached manifest on your server                            | Your application resolves public policy data with each request's location and signals        | Inth or your c15t backend   | Policy changes must reach the app without rebuilding, or builds cannot access the backend                                                            |
-| Regular backend `/init`                                   | The consent backend                                                                          | The same backend            | You have no application server, as in a React, Vue or Svelte single-page app, want the fewest moving parts, or need backend-owned request resolution |
-| Manifest in the browser                                   | The browser, using a supplied location, or `/init` when the policy needs one it doesn't have | Inth or your c15t backend   | The policy has no location rules or the page knows the visitor's location, and you accept about 3 KB more bundle and a rebuild for policy edits      |
-| Offline                                                   | The browser or local runtime, using bundled rules                                            | No backend submission       | Local development and tests. Not recommended for production environments.                                                                            |
-| Custom transport                                          | Your implementation                                                                          | Your implementation         | An existing service cannot use the c15t backend protocol                                                                                             |
+| Fetching path                                             | Where policy resolves                                                                        | Where choices are submitted                                         | Choose it when                                                                                                                                       |
+| --------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Build-time manifest, recommended for server-rendered apps | Your server resolves a bundled policy snapshot with each visitor's inputs                    | Inth or your c15t backend                                           | Your framework renders on the server, supports a build integration, and policy changes can ship with a rebuild                                       |
+| Cached manifest on your server                            | Your application resolves public policy data with each request's location and signals        | Inth or your c15t backend                                           | Policy changes must reach the app without rebuilding, or builds cannot access the backend                                                            |
+| Regular backend `/init`                                   | The consent backend                                                                          | The same backend                                                    | You have no application server, as in a React, Vue or Svelte single-page app, want the fewest moving parts, or need backend-owned request resolution |
+| Manifest in the browser                                   | The browser, using a supplied location, or `/init` when the policy needs one it doesn't have | Inth or your c15t backend                                           | The policy has no location rules or the page knows the visitor's location, and you accept about 3 KB more bundle and a rebuild for policy edits      |
+| Local                                                     | The browser or local runtime, using bundled rules                                            | No backend submission. c15t keeps no server-side record of consent. | 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?
 
@@ -226,36 +226,43 @@ 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?
+## When should I use local 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.
+`local()`, called `offline()` before c15t 3.2, resolves bundled policy rules
+without an init request and acknowledges saves locally. The runtime's
+persistence module stores the choice in browser storage. c15t keeps no
+server-side record of consent, so there is no audit history, no cross-device
+record and no IP geolocation. [What a consent record proves](./modes.md#what-a-consent-record-proves)
+explains what that leaves out.
 
-Use your framework's `offline()` so its translations and provider context are
+Use your framework's `local()` so its translations and provider context are
 included. In a React app it replaces the mode passed to `ConsentProvider`:
 
 ```ts title="src/consent-mode.ts"
-import { offline } from 'c15t/react';
+import { local } from 'c15t/react';
 
-export const mode = offline();
+export const mode = local();
 ```
 
+In development builds, local mode warns once per page that c15t keeps no
+server-side record of consent. Pass `local({ acknowledgeNoRecords: true })` to
+hide the warning once you have decided a browser-only record is enough; see
+[the development warning](./modes.md#the-development-warning).
+
 In Next.js, TanStack Start, Nuxt, Astro and SvelteKit, pass the data
-`offline()` from the framework package where the config takes `mode`; see
+`local()` from the framework package where the config takes `mode`; see
 [consent modes](./modes.md#import-the-factories-from-your-framework-package).
 
-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.
+With no `policyRules`, the local transport uses the recommended rule pack.
+Supplying `policyRules` replaces that pack. Unknown country and region are
+real resolution inputs; local mode does not discover a visitor's location.
 Use [policy rules](./policies.md) to understand
 matching and defaults, and test the missing-location case.
 
-Offline mode is an explicit architecture choice, not an automatic fallback for
+Local 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.

package/docs/concepts/modes.md

@@ -1,6 +1,6 @@
 ---
 title: Consent modes
-description: Reference for manifest(), hosted() and offline() in every c15t
+description: Reference for manifest(), hosted() and local() in every c15t
   framework package, where each one resolves the visitor's policy, what it adds
   to first-load JavaScript, the build-time manifest fetch and its failure
   policy, and the backend URL variable each framework reads.
@@ -11,7 +11,8 @@ group: concepts
 
 A mode decides how c15t finds the policy that applies to a visitor. Every
 framework package exports the same three factories, `manifest()`, `hosted()`
-and `offline()`. Consent choices go to the backend in `manifest()` and
+and `local()`. `local()` was called `offline()` before c15t 3.2, and the old
+name still works until c15t v4. Consent choices go to the backend in `manifest()` and
 `hosted()`, whether that backend is [Inth](https://inth.com) or a
 [self-hosted c15t backend](https://c15t.com/docs/self-host/quickstart).
 
@@ -19,7 +20,7 @@ and `offline()`. Consent choices go to the backend in `manifest()` and
 | ------------------------- | ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `manifest()`, the default | Your server, from the policy the build downloaded. With `resolve: 'browser'`, or in a single-page app, the browser. | None to resolve the policy, unless the browser needs a location it doesn't have. Choices post to `/subjects`. | Server-rendered apps. Rebuild to ship policy changes, or set `source: 'runtime'`.                                                                             |
 | `hosted()`                | The backend's `GET /init`                                                                                           | One `/init` per page that resolves consent.                                                                   | Single-page apps and static hosting without a server, where the backend reads each visitor's location from the request. Policy edits apply without a rebuild. |
-| `offline()`               | The browser, from rules in your bundle                                                                              | None. Choices stay in the browser.                                                                            | Local development, tests and demos. Not recommended for production environments.                                                                              |
+| `local()`                 | The browser, from rules in your bundle                                                                              | None. Choices stay in the browser, and c15t keeps no server-side record of consent.                           | Local development, tests and demos. Not recommended for production environments.                                                                              |
 
 `manifest()` is the default in Next.js, TanStack Start, Nuxt, Astro and
 SvelteKit. React, Vue, Svelte and `@c15t/browser` have no default: pass a
@@ -38,18 +39,18 @@ custom transport and same-origin proxies.
 There are two kinds of factory, and each framework package exports the kind it
 needs under the same three names.
 
-| Framework      | Import from           | Pass the mode to                                                                                                                | Kind      |
-| -------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------- | --------- |
-| Next.js        | `c15t/next`           | `mode` in `c15t.config.ts`                                                                                                      | Data      |
-| TanStack Start | `c15t/tanstack-start` | `createConsentStateHandler({ mode })`                                                                                           | Data      |
-| Nuxt           | `c15t/vue`            | `c15t.mode` in `nuxt.config.ts`                                                                                                 | Data      |
-| Astro          | `c15t/astro`          | `c15t({ mode })` in `astro.config.mjs`                                                                                          | Data      |
-| SvelteKit      | `@c15t/svelte/kit`    | `c15tHandle({ mode })` in `src/hooks.server.ts`                                                                                 | Data      |
-| React          | `c15t/react`          | `ConsentProvider`'s `options.mode`                                                                                              | Transport |
-| Vue            | `c15t/vue/vue-plugin` | `app.use(c15tVue, { mode })`                                                                                                    | Transport |
-| Svelte         | `@c15t/svelte`        | `<ConsentProvider mode={...}>`                                                                                                  | Transport |
-| JavaScript     | `@c15t/browser`       | `init({ mode })`                                                                                                                | Transport |
-| Script tag     | none                  | The bundle file: `c15t.js` is hosted, `c15t.offline.js` offline. The headless and IAB scripts also take `data-mode="manifest"`. | Name      |
+| Framework      | Import from           | Pass the mode to                                                                                                            | Kind      |
+| -------------- | --------------------- | --------------------------------------------------------------------------------------------------------------------------- | --------- |
+| Next.js        | `c15t/next`           | `mode` in `c15t.config.ts`                                                                                                  | Data      |
+| TanStack Start | `c15t/tanstack-start` | `createConsentStateHandler({ mode })`                                                                                       | Data      |
+| Nuxt           | `c15t/vue`            | `c15t.mode` in `nuxt.config.ts`                                                                                             | Data      |
+| Astro          | `c15t/astro`          | `c15t({ mode })` in `astro.config.mjs`                                                                                      | Data      |
+| SvelteKit      | `c15t/svelte/kit`     | `c15tHandle({ mode })` in `src/hooks.server.ts`                                                                             | Data      |
+| React          | `c15t/react`          | `ConsentProvider`'s `options.mode`                                                                                          | Transport |
+| Vue            | `c15t/vue/vue-plugin` | `app.use(c15tVue, { mode })`                                                                                                | Transport |
+| Svelte         | `c15t/svelte`         | `<ConsentProvider mode={...}>`                                                                                              | Transport |
+| JavaScript     | `@c15t/browser`       | `init({ mode })`                                                                                                            | Transport |
+| Script tag     | none                  | The bundle file: `c15t.js` is hosted, `c15t.local.js` local. The headless and IAB scripts also take `data-mode="manifest"`. | Name      |
 
 **Data factories** return a plain object such as `{ type: 'manifest' }`.
 Server-rendered frameworks read their config on the server and in the
@@ -86,7 +87,7 @@ holds your policy rules and copy, and no visitor data.
 | `inputs`      | none       | `{ country, region }` when the page already knows the visitor's location, for example from an edge worker. Browser resolution only.                                                                                                 |
 
 The transport `manifest()` from `c15t/react`, `c15t/vue/vue-plugin`,
-`@c15t/svelte` and `@c15t/browser` always resolves in the browser, so it has
+`c15t/svelte` and `@c15t/browser` always resolve in the browser, so they have
 no `resolve` option. It also takes `backendURL`, `headers`, `credentials`,
 `domain`, `fetch` and `initFallback`. With no options it reads the snapshot
 and the backend URL your build integration downloaded. With `manifestURL`,
@@ -98,7 +99,7 @@ know the country or region, browser resolution asks `geoURL`, then the
 backend's `/init`. Set `initFallback: false` to resolve for an unknown location
 instead. A policy with location rules therefore saves no request in a
 single-page app unless you pass `inputs` or `geoURL`. The `consentManifest()`
-plugins from `c15t/build`, `c15t/vue/vite` and `@c15t/svelte/vite` warn
+plugins from `c15t/build`, `c15t/vue/vite` and `c15t/svelte/vite` warn
 about this when a single-page app build bundles such a policy.
 
 ## hosted()
@@ -122,36 +123,85 @@ against and the backend can reject a save made against a stale policy.
 `backendURL`. The framework exports fill it in from your config or your
 build.
 
-## offline()
+## local()
 
 Not recommended for production environments.
 
-`offline()` resolves policy rules in the browser and stores choices in browser
-storage. Nothing reaches a backend, so there is no consent record, no
-cross-device history and no IP geolocation.
+`local()` resolves policy rules in the browser and stores choices in browser
+storage. Nothing reaches a backend, so c15t keeps no server-side record of
+consent. There is also no cross-device history, and with no IP geolocation
+every visitor gets the policy for an unknown location unless you pass
+`overrides`.
 
-| Option        | Default                   | Behavior                                                    |
-| ------------- | ------------------------- | ----------------------------------------------------------- |
-| `policyRules` | the recommended rule pack | Rules to resolve. Passing rules replaces the pack entirely. |
+| Option                 | Default                   | Behavior                                                                       |
+| ---------------------- | ------------------------- | ------------------------------------------------------------------------------ |
+| `policyRules`          | the recommended rule pack | Rules to resolve. Passing rules replaces the pack entirely.                    |
+| `acknowledgeNoRecords` | `false`                   | `true` hides the development warning described below. It changes nothing else. |
 
 Unknown country and region are real inputs: test the missing-location case
 against your rules. See [policy rules](./policies.md).
 
+### The development warning
+
+In a development build, local mode logs one `console.warn` per page load:
+
+```txt
+[c15t] Local mode keeps consent only in this browser. c15t keeps no
+server-side record of consent. Local mode also has no geolocation, so
+every visitor gets the same policy. Use it for development and tests. For
+production, see https://c15t.com/docs/concepts/modes
+Set acknowledgeNoRecords: true to hide this message.
+```
+
+Production builds never log it, and it never blocks the banner or a save.
+The script-tag files are production builds, so `c15t.local.js`, and
+`c15t.headless.js` or `c15t.iab.js` without a backend URL, log it on
+development hosts instead:
+`localhost`, `127.0.0.1`, `[::1]`, `0.0.0.0` and names ending in
+`.localhost`, `.local` or `.test`. A script tag hides it with
+`data-acknowledge-no-records`.
+
+Set `acknowledgeNoRecords: true` once you have decided a browser-only record is
+enough, such as in tests, or on a site that keeps its own record through
+[callbacks](https://c15t.com/docs/frameworks/javascript/callbacks) or a [`custom()` transport](./data-fetching.md#can-i-provide-my-own-transport):
+
+```ts
+import { local } from 'c15t/react';
+
+const mode = local({ acknowledgeNoRecords: true });
+```
+
+c15t v4 removes the `offline()` name and makes `acknowledgeNoRecords: true`
+required in `local()`'s type.
+
+### What a consent record proves
+
+A consent record is the backend's copy of a choice: which categories the
+visitor granted or denied, when, and against which policy and copy. Under the
+GDPR, the business that relies on consent must be able to show that the
+visitor gave it (Article 7(1)). Browser storage alone cannot do that: the
+visitor can clear it, and it never leaves their device.
+
+`manifest()` and `hosted()` post each choice to the backend, which keeps the
+record. To keep records without Inth, run a
+[self-hosted backend](https://c15t.com/docs/self-host/overview), or send each choice to your
+own API with `custom()`.
+
 ## What each mode adds to first-load JavaScript
 
 In a server-rendered framework, the browser receives the resolved state with
 the page. It only needs the code to save a choice, and loads the rest when it
 runs:
 
-| Mode                               | First-load JavaScript                                  | Loaded with `import()` when it runs                                                                                                           |
-| ---------------------------------- | ------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- |
-| `manifest()`                       | The code that saves choices and builds an init request | The hosted init path, if the browser has to resolve consent again                                                                             |
-| `manifest({ resolve: 'browser' })` | The code that saves choices                            | The browser resolver, English copy and the fetch of `${routePrefix}/manifest` or `${backendURL}/manifest`. Other languages load per language. |
-| `hosted()`                         | The code that saves choices                            | The hosted init path                                                                                                                          |
-| `offline()`                        | Nothing mode-specific                                  | The offline transport, the rule pack and its copy                                                                                             |
+| Mode                               | First-load JavaScript                                  | Loaded with `import()` when it runs                                                                                                                                                             |
+| ---------------------------------- | ------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `manifest()`                       | The code that saves choices and builds an init request | The hosted init path, if the browser has to resolve consent again                                                                                                                               |
+| `manifest({ resolve: 'browser' })` | The code that saves choices                            | The browser resolver, English copy and the fetch of `${routePrefix}/manifest` or `${backendURL}/manifest`, unless the server state already holds the policy. Other languages load per language. |
+| `hosted()`                         | The code that saves choices                            | The hosted init path                                                                                                                                                                            |
+| `local()`                          | Nothing mode-specific                                  | The local transport, the rule pack and its copy                                                                                                                                                 |
 
 With `manifest()` resolved on the server, the manifest snapshot, the resolver,
-the offline rule pack and other languages stay out of the browser bundle.
+the local rule pack and other languages stay out of the browser bundle.
 
 In a single-page app the bundle contains the mode you imported:
 
@@ -159,7 +209,7 @@ In a single-page app the bundle contains the mode you imported:
 | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
 | `manifest()` | The snapshot, when the build downloaded one, and the code that saves choices. The resolver starts loading when `manifest()` runs, unless the policy needs a location the page does not know. English copy is bundled; other languages load the first time a visitor needs one. |
 | `hosted()`   | The hosted transport                                                                                                                                                                                                                                                           |
-| `offline()`  | The offline transport, the recommended rule pack and its copy                                                                                                                                                                                                                  |
+| `local()`    | The local transport, the recommended rule pack and its copy                                                                                                                                                                                                                    |
 
 ## Set the backend URL
 
@@ -204,7 +254,7 @@ build integration downloads from `${backendURL}/manifest`:
 | TanStack Start       | `consentManifest()` from `c15t/tanstack-start/build`                | `@c15t/tanstack-start/build` |
 | React and JavaScript | `consentManifest()` from `c15t/build`                               | `@c15t/core/build`           |
 | Vue                  | `consentManifest()` from `c15t/vue/vite`                            | `@c15t/vue/vite`             |
-| Svelte and SvelteKit | `consentManifest()` from `@c15t/svelte/vite`                        | `@c15t/svelte/vite`          |
+| Svelte and SvelteKit | `consentManifest()` from `c15t/svelte/vite`                         | `@c15t/svelte/vite`          |
 | Nuxt                 | the `c15t/vue` module                                               | `@c15t/vue`                  |
 | Astro                | the `c15t()` integration                                            | `@c15t/astro`                |
 
@@ -266,13 +316,13 @@ snapshot:
 * The backend URL is relative, such as `/api/c15t`. With an explicit
   `onBuildError: 'fail'`, a relative URL stops the build instead.
 * Next.js builds with `output: 'export'`, which has no server.
-* The mode is `hosted()`, `offline()`, `manifest({ snapshot })` or
+* The mode is `hosted()`, `local()`, `manifest({ snapshot })` or
   `manifest({ source: 'runtime' })` in Next.js, Nuxt and Astro. Next.js reads
   the mode from `c15t.config.ts`.
 * A single-page app built with Vite (React, Vue, Svelte, JavaScript) does
   not use `manifest()`. The mode is set in app code, so the plugin downloads
   the manifest only once the bundle turns out to read it, after unused code
-  is dropped. A `hosted()` or `offline()` build never contacts the backend.
+  is dropped. A `hosted()` or `local()` build never contacts the backend.
   SvelteKit and TanStack Start choose the mode on the server at runtime, so
   their builds always download it.
 

package/docs/customization/recipes.md

@@ -86,7 +86,7 @@ Render `CookieBanner` in place of `ConsentBanner`, inside
 
 ```svelte title="src/lib/cookie-banner.svelte"
 <script lang="ts">
-	import { ConsentBanner } from '@c15t/svelte';
+	import { ConsentBanner } from 'c15t/svelte';
 </script>
 
 <!-- The stock banner, drawn as a full-width bar along the bottom edge. -->
@@ -250,7 +250,7 @@ Svelte scopes component styles, so the classes live in a global
 stylesheet.
 
 ```ts title="src/lib/consent-options.ts"
-import type { ConsentManagerOptions } from '@c15t/svelte';
+import type { ConsentManagerOptions } from 'c15t/svelte';
 
 import './slim-bar.css';
 
@@ -456,8 +456,8 @@ opens.
 
 ```svelte title="src/lib/cookie-bar.svelte"
 <script lang="ts">
-	import { getHeadlessConsent } from '@c15t/svelte';
-	import type { PresentationAction } from '@c15t/svelte';
+	import { getHeadlessConsent } from 'c15t/svelte';
+	import type { PresentationAction } from 'c15t/svelte';
 
 	import './cookie-bar.css';
 

package/docs/customization/stylesheets.md

@@ -69,7 +69,7 @@ render. The elements stay after the surface unmounts. The Svelte dialog's
 sheets, its rules and the primitives, load with the dialog's code.
 
 On a server-rendered SvelteKit page, the banner leaves a
-`<meta name="c15t-styles">` marker, and `c15tHandle` from `@c15t/svelte/kit`
+`<meta name="c15t-styles">` marker, and `c15tHandle` from `c15t/svelte/kit`
 writes the sheets into the HTML `<head>` as `<style>` elements. The banner is
 styled before hydration with no stylesheet request. Without `c15tHandle` in
 `src/hooks.server.ts`, a server-rendered banner shows unstyled until
@@ -109,7 +109,7 @@ need control over the file:
 | Next.js           | `options.styles` in `c15t.config.ts` or on `ConsentRoot` | `c15t/next/styles.css`, and `c15t/next/iab/styles.css` for IAB TCF                     |
 | TanStack Start    | `options.styles` on `ConsentRoot`                        | `c15t/tanstack-start/styles.css`, and `c15t/tanstack-start/iab/styles.css` for IAB TCF |
 | React             | `options.styles` on `ConsentProvider`                    | `c15t/react/styles.css`, and `c15t/react/iab/styles.css` for IAB TCF                   |
-| Svelte, SvelteKit | `options.styles` on `ConsentProvider` or `ConsentRoot`   | `@c15t/svelte/styles.css`, and `@c15t/svelte/iab/styles.css` for IAB TCF               |
+| Svelte, SvelteKit | `options.styles` on `ConsentProvider` or `ConsentRoot`   | `c15t/svelte/styles.css`, and `c15t/svelte/iab/styles.css` for IAB TCF                 |
 | Astro             | `styles` in the `c15t()` integration options             | See [load Astro's stylesheets yourself](#load-astros-stylesheets-yourself)             |
 
 ```ts title="c15t.config.ts (Next.js)"
@@ -132,7 +132,7 @@ the first paint. Remove the import, or add `styles: false` if you need it.
 | Next.js, TanStack Start, React | In the dialog sheet that `ConsentDialog` and `ConsentWidget` render. It ships with the dialog's lazily loaded code. With `styles: false`, in `styles.css`. No `@c15t/react` or `@c15t/ui` module imports CSS, so a Next.js app that uses only the Pages Router builds without `transpilePackages`                                                                                                                                           |
 | Nuxt, Vue                      | The dialog component imports its stylesheet, so the rules load with the dialog's code, not the banner's                                                                                                                                                                                                                                                                                                                                     |
 | Astro                          | In `@c15t/ui/styles/sheets/dialog.css`. The Svelte dialog, the default `ui`, also needs the primitives stylesheet. c15t links both when a visitor first points at, focuses or opens a control that opens the dialog, waits for them before it shows the dialog, and keeps them across `ClientRouter` navigation. On a Tailwind CSS 3 site, the dialog's rules are in `c15t/astro/styles.css`, and c15t links only the primitives stylesheet |
-| Svelte, SvelteKit              | In the dialog's sheets, which load with the dialog's code. With `styles: false`, in `@c15t/svelte/styles.css`                                                                                                                                                                                                                                                                                                                               |
+| Svelte, SvelteKit              | In the dialog's sheets, which load with the dialog's code. With `styles: false`, in `c15t/svelte/styles.css`                                                                                                                                                                                                                                                                                                                                |
 | HTML, JavaScript               | Part of the stylesheet in the shadow root, which holds only the rules the stock surfaces use                                                                                                                                                                                                                                                                                                                                                |
 
 `styles.css` still holds every stock surface's rules for apps that set