@picked/client 0.0.1-dev.1786675074931 → 0.0.1-dev.1787537193674

package/dist/docs/explanation/feature-flag-allocation.md

@@ -65,6 +65,43 @@ your application in its decision. The value comes from the visitor ID, the featu
 ID, and the weight, and from nothing else. Define the feature flag in SDK code when the
 decision needs a cart, a quote, or a profile.
 
+## More than two groups
+
+A Text feature flag has a table of variants, and each variant is one group. Picked
+allocates a visitor to exactly one of them, and the control group is one of the rows.
+
+The two types decide by different routes, and the difference matters if you compare them:
+
+| Type | Picked compares | Against |
+| --- | --- | --- |
+| Boolean | The stable value of the visitor, out of 100 | The weight |
+| Text | One stable value for each variant | The weight of that variant |
+
+A Text feature flag gives each variant a score. Picked makes the score from the visitor
+ID, the feature flag ID, and the key of the variant. The weight of the variant then scales
+that score. The variant with the best score receives the visitor.
+
+The weight of a variant therefore changes the score of that variant alone. No other
+variant moves because of it.
+
+A Boolean feature flag makes the same comparison it always has. A feature flag that you
+made before variants existed therefore keeps every visitor where it put them.
+
+Picked derives the stable value from the visitor ID and from the ID of the feature flag,
+for both types. The two types are therefore independent of each other in the same way that
+two feature flags are.
+
+**The order of the rows has no effect.** Picked scores each variant from its key, and the
+key of a variant never changes. Move a row in the dashboard and the
+visitors stay where they are. The order that you see is the order that you chose to read
+them in, and nothing more.
+
+Rename a variant and nothing changes. The name travels no further than the dashboard.
+
+Change the string that a variant serves and the visitors stay in the same group, but your
+site and your reports receive the new string. A visitor with a decision in browser storage
+keeps the old string until you increment the version.
+
 ## Each feature flag is independent
 
 Picked builds that value from the visitor ID together with the ID of the feature flag.
@@ -81,7 +118,8 @@ then never sees the mixed groups that tell one result from the other.
 
 ## The allocation ratchets
 
-Inside one feature flag, a larger weight only adds visitors. Everybody allocated at
+The ratchet applies to both types of feature flag. Inside one feature flag, a larger
+weight only adds visitors. Everybody allocated at
 weight 30 is still allocated at weight 50. The allocation is a **ratchet**: it turns one
 way, and a larger weight never moves a visitor back out.
 
@@ -89,6 +127,10 @@ That property is what makes a staged release safe. A visitor who sees the change
 still sees it at 20%. A smaller weight is the reverse turn. It removes visitors from the
 top of the range, and every visitor below the new weight keeps what they had.
 
+A Text feature flag has the same ratchet, one variant at a time. A larger weight on one variant only
+adds visitors to that variant. A smaller weight only removes them. Two variants that you
+do not change never exchange visitors with each other.
+
 ## A disabled feature flag records nothing
 
 A disabled feature flag allocates nobody, and the difference from a weight of 0

package/dist/docs/how-to/analytics/index.md

@@ -311,4 +311,6 @@ WHERE project_id = '{{ your project ID }}'
 - [About PickedQL](/explanation/how-pickedql-works) — what the layer expands for you.
 - [Virtual functions](/reference/pickedql/virtual-functions) — every function.
 - [Dimensions](/reference/pickedql/dimensions) — every dimension column.
+- [Analytics events](/reference/sdk/analytics-events) — every `event_type` value that a
+  filter can use.
 - [Reports](/reference/dashboard/reports) — the same data as an embedded dashboard.

package/dist/docs/how-to/authenticate-the-cli.md

@@ -5,24 +5,24 @@ layout: docs
 
 # How to authenticate the CLI
 
-This guide shows you how to install `@picked/cli` and sign it in. Commands that read your
-organizations, projects, and workspaces then know who you are. It expects a Picked account
-and a project directory to work in.
+This guide shows you how to install the `picked` command and sign it in. Commands that read
+your organizations, projects, and workspaces then know who you are. It expects a Picked
+account and a project directory to work in.
 
 ## 1. Install the CLI
 
 :::code-group
 
 ```bash [npm]
-npm install --save-dev @picked/cli
+npm install picked
 ```
 
 ```bash [pnpm]
-pnpm add -D @picked/cli
+pnpm add picked
 ```
 
 ```bash [yarn]
-yarn add -D @picked/cli
+yarn add picked
 ```
 
 :::
@@ -44,8 +44,7 @@ https://api.picked.app/…/oauth/authorize?…
 Logged in as you@example.com (https://api.picked.app)
 ```
 
-The CLI stores the session in `~/.picked/auth/<origin>.json`, outside any repository, with
-file mode `600`. It refreshes the session as it nears expiry.
+The CLI stores the session in `~/.picked/auth/<origin>.json`. It refreshes the session as it nears expiry.
 
 ## 3. Confirm the session
 
@@ -70,15 +69,18 @@ Logged out of https://api.picked.app.
 
 ## Run the CLI in CI
 
-CI has no browser, so give the CLI a token instead of a session. `PICKED_TOKEN` takes
-precedence over any stored session:
+`picked generate types` reads the workspace schema, not your account, so CI needs no
+session for it. A workspace you read with `source: 'preview'` needs that workspace's token.
+Run `picked workspace use` once on your machine, then give CI the two values it wrote:
 
 ```bash
-PICKED_TOKEN="$PICKED_ACCESS_TOKEN" picked generate types --check
+PICKED_PROJECT_ID=your-project-id \
+PICKED_PREVIEW_TOKEN=$YOUR_CI_SECRET \
+picked generate types --check
 ```
 
-If an API deployment does not offer OAuth client registration, `picked login` fails and
-tells you to set `PICKED_TOKEN`. It falls back to no other flow.
+`picked workspace list` and `picked workspace use` read your organizations and projects, so
+those two do need a session. Run them on your machine, where a browser can sign you in.
 
 :::note
 This is a developer session for local tooling. It is not the same as an

package/dist/docs/how-to/create-and-revoke-an-api-key.md

@@ -5,8 +5,13 @@ layout: docs
 
 # How to create and revoke an API key
 
-This guide shows you how to give your code access to the Picked API. Use a key for a
-server-side integration or for a CI/CD workflow.
+This guide shows you how to give your code access to the Picked API. Use a key where your
+own code calls the API, such as a server-side integration.
+
+An API key does not sign the [CLI](/reference/tools/cli) in. The CLI reads a session, which
+`picked login` writes. See
+[How to authenticate the CLI](/how-to/authenticate-the-cli) for the commands that CI can
+run without one.
 
 ## Create a key
 

package/dist/docs/how-to/debug-with-the-chrome-extension.md

@@ -16,7 +16,7 @@ Install it from the
 ## 2. Add the devtools plugin
 
 ```typescript
-import { createClient } from '@picked/client'
+import { createClient } from 'picked'
 import { svelteDevtoolsPlugin } from '@picked/svelte/plugins/devtools'
 
 const picked = createClient({

package/dist/docs/how-to/install-the-sdk.md

@@ -13,28 +13,41 @@ ID from the dashboard.
 :::code-group
 
 ```bash [React]
-npm install @picked/client @picked/react effector effector-react
+npm install picked @picked/react
 ```
 
 ```bash [Svelte]
-npm install @picked/client @picked/svelte effector
+npm install picked @picked/svelte
 ```
 
 :::
 
-:::note
-`picked` is a shorter name for the same client. `npm install picked` gives you
-`createClient` from `picked` and the `picked.config` helpers from `picked/config`. It also
-gives you the `picked` command. npm adds `@picked/client` with it, which is where the
-generated types attach.
-:::
+`picked` gives you the client, the `picked.config` helpers, and the `picked` command. Your
+package manager adds `@picked/client` with it, which carries the runtime and holds the
+generated types.
+
+## 2. Add `picked.config.ts`
+
+Create this file in the root of your project. The `picked` command and the
+[Vite plugin](/reference/tools/vite-plugin) read your project identity from it:
+
+```typescript
+import { defineConfig } from 'picked/config'
+
+export default defineConfig({
+  projectId: 'your-project-id',
+})
+```
 
-## 2. Create and start the client
+[Type generation](/reference/sdk/type-generation) reads this file, and gives your fields,
+features and steps the types the workspace declares.
+
+## 3. Create and start the client
 
 :::code-group
 
 ```tsx [React]
-import { createClient } from '@picked/client'
+import { createClient } from 'picked'
 import { dynamicExperiencesPlugin } from '@picked/client/plugins/dynamic-experiences'
 import { reactFrameworkPlugin } from '@picked/react/plugins/framework'
 
@@ -47,7 +60,7 @@ picked.start()
 ```
 
 ```ts [Svelte]
-import { createClient } from '@picked/client'
+import { createClient } from 'picked'
 import { dynamicExperiencesPlugin } from '@picked/client/plugins/dynamic-experiences'
 import { svelteFrameworkPlugin } from '@picked/svelte/plugins/framework'
 
@@ -61,9 +74,13 @@ picked.start()
 
 :::
 
+`picked` carries the client's root entry. Each deeper import path, such as
+`@picked/client/plugins/dynamic-experiences` and `@picked/client/server`, keeps its own
+name.
+
 `start()` is idempotent. A second call changes nothing on a client that started already.
 
-## 3. Add the optional plugins
+## 4. Add the optional plugins
 
 - `windowObjectPlugin()` puts the client on `window.Picked`, which helps when you debug.
 - `singlePageAppPlugin()` starts the client again on a history event.
@@ -72,4 +89,5 @@ picked.start()
 
 - [Add Picked to your application](/tutorials/first-experience) — the whole path.
 - [SDK installation](/reference/sdk) — every client option.
+- [Type generation](/reference/sdk/type-generation) — types from your workspace.
 - [How to register a component](/how-to/register-a-component).

package/dist/docs/how-to/install-the-vite-plugin.md

@@ -13,37 +13,49 @@ API request at runtime.
 :::code-group
 
 ```bash [npm]
-npm install @picked/vite-plugin-picked
+npm install @picked/vite-plugin-picked picked
 ```
 
 ```bash [pnpm]
-pnpm add @picked/vite-plugin-picked
+pnpm add @picked/vite-plugin-picked picked
 ```
 
 ```bash [yarn]
-yarn add @picked/vite-plugin-picked
+yarn add @picked/vite-plugin-picked picked
 ```
 
 :::
 
-## 2. Add it to your config
+## 2. Name your project
+
+Create `picked.config.ts` in the root of your project. The plugin reads your project
+identity from this file:
+
+```typescript
+import { defineConfig } from 'picked/config'
+
+export default defineConfig({
+  projectId: 'your-project-id',
+})
+```
+
+## 3. Add the plugin to your Vite config
 
 ```typescript
 import { defineConfig } from 'vite'
 import { picked } from '@picked/vite-plugin-picked'
 
 export default defineConfig({
-  plugins: [
-    picked({
-      projectId: 'your-project-id',
-    }),
-  ],
+  plugins: [picked()],
 })
 ```
 
 When Vite starts, the plugin reads your project configuration and embeds them in your bundle.
 The SDK then reads the embedded configuration and makes no network request.
 
+The plugin also writes `picked-env.d.ts`, which types your fields, features and steps
+against the workspace. See [Type generation](/reference/sdk/type-generation).
+
 :::note
 When a preview token is there at runtime, the SDK ignores the embedded configuration and reads
 fresh data from the API.
@@ -52,5 +64,6 @@ fresh data from the API.
 ## Related
 
 - [Vite plugin](/reference/tools/vite-plugin) — every option.
+- [Type generation](/reference/sdk/type-generation) — the `picked.config.ts` options.
 - [About how Picked works](/explanation/how-picked-works) — where build-time configuration sit
   in the startup order.

package/dist/docs/how-to/read-a-feature-flag.md

@@ -22,8 +22,8 @@ decision.
 | --- | --- | --- |
 | `useFeature` / `getFeature` | `() => Promise<bucket>` | Only when you call the function that it returns |
 | `useFeatureResult` / `getFeatureResult` | `{ id, bucket }`, and `undefined` until it resolves | Yes, as soon as the component renders |
-| `useFeatureEnabled` / `getFeatureEnabled` | `boolean \| undefined`, the dashboard **Enabled** feature flag | No |
-| `client.features.listStore` | Every registered feature flag, each with an `isResolved` feature flag | No |
+| `useFeatureEnabled` / `getFeatureEnabled` | `boolean \| undefined`, the dashboard **Enabled** setting | No |
+| `client.features.listStore` | Every registered feature flag, each with an `isResolved` property | No |
 | `client.features.getById(id)` | A store that holds one feature flag | No |
 
 Some decisions must wait for data that you do not have yet, such as a cart, a quote, or
@@ -32,6 +32,9 @@ function they return after the data arrives.
 
 ## 2. Read the bucket
 
+The bucket is what your site receives. A Boolean feature flag gives `true` or `false`. A
+Text feature flag gives the value of one variant, or `false` for the control group.
+
 :::code-group
 
 ```tsx [React]
@@ -39,12 +42,13 @@ import { useFeatureResult } from '@picked/react/hooks'
 
 function MyComponent() {
   // { id, bucket }, or undefined until the feature flag resolves.
-  const result = useFeatureResult('my-feature')
+  const result = useFeatureResult('hero')
 
   return (
     <div>
-      {result?.bucket === 'control' && <p>Control</p>}
-      {result?.bucket === 'variant-a' && <p>Variant A</p>}
+      {result?.bucket === false && <p>Control</p>}
+      {result?.bucket === 'hero-a' && <p>Hero A</p>}
+      {result?.bucket === 'hero-b' && <p>Hero B</p>}
     </div>
   )
 }
@@ -55,13 +59,15 @@ function MyComponent() {
   import { getFeatureResult } from '@picked/svelte/hooks'
 
   // A store that holds { id, bucket }, or undefined until the feature flag resolves.
-  const result = getFeatureResult('my-feature')
+  const result = getFeatureResult('hero')
 </script>
 
-{#if $result?.bucket === 'control'}
+{#if $result?.bucket === false}
   <p>Control</p>
-{:else if $result?.bucket === 'variant-a'}
-  <p>Variant A</p>
+{:else if $result?.bucket === 'hero-a'}
+  <p>Hero A</p>
+{:else if $result?.bucket === 'hero-b'}
+  <p>Hero B</p>
 {/if}
 ```
 
@@ -72,12 +78,18 @@ function MyComponent() {
 renders, and they commit the visitor to a bucket at that moment.
 :::
 
+:::tip
+Run [type generation](/reference/sdk/type-generation) and `bucket` narrows to the values
+that this Text feature flag declares. Your editor then shows each value, and it reports a
+comparison against a value that the feature flag cannot serve.
+:::
+
 ## 3. Read it without a framework
 
 The event bus works with any framework, and with none:
 
 ```ts
-import { createClient } from '@picked/client'
+import { createClient } from 'picked'
 
 const client = createClient({
   /* Put your client options here. */
@@ -85,7 +97,7 @@ const client = createClient({
 
 client.eventBus.watch((event) => {
   if (event.type === 'feature_decide' && event.feature.id === 'my-feature') {
-    console.log(event.feature) // { id: 'my-feature', key: 'v1', bucket: 'control' }
+    console.log(event.feature) // { id: 'my-feature', key: 'v1', bucket: 'hero-a' }
   }
 })
 ```

package/dist/docs/how-to/read-a-referenced-entry.md

@@ -20,12 +20,11 @@ Pass the raw field value to `useReference()` in React, or to `getReference()` in
 :::code-group
 
 ```tsx [React]
-import { useUnit } from 'effector-react'
-import { useReference, useStepContent } from '@picked/react/hooks'
+import { useReference, useStepContent, useStoreGlobal } from '@picked/react/hooks'
 
 export function ProductCategory() {
   const content = useStepContent()
-  const category = useUnit(useReference(content?.category))
+  const category = useStoreGlobal(useReference(content?.category))
 
   if (!category) return null
 
@@ -58,12 +57,11 @@ Use `useReferences()` or `getReferences()`. They give a list in field order.
 :::code-group
 
 ```tsx [React]
-import { useUnit } from 'effector-react'
-import { useReferences, useStepContent } from '@picked/react/hooks'
+import { useReferences, useStepContent, useStoreGlobal } from '@picked/react/hooks'
 
 export function ProductCategories() {
   const content = useStepContent()
-  const categories = useUnit(useReferences(content?.categories))
+  const categories = useStoreGlobal(useReferences(content?.categories))
 
   return (
     <ul>

package/dist/docs/how-to/register-a-component.md

@@ -17,7 +17,7 @@ the dashboard.
 :::code-group
 
 ```tsx [React]
-import { createClient } from '@picked/client'
+import { createClient } from 'picked'
 import { adaptReactComponent } from '@picked/react'
 import { MyWidget } from './MyWidget'
 
@@ -30,7 +30,7 @@ const picked = createClient({
 ```
 
 ```ts [Svelte]
-import { createClient } from '@picked/client'
+import { createClient } from 'picked'
 import { adaptSvelteComponent } from '@picked/svelte'
 import MyWidget from './MyWidget.svelte'
 

package/dist/docs/how-to/register-an-action-handler.md

@@ -15,7 +15,7 @@ Pass an `actions` object to `createClient()`. Each key must match an action key
 dashboard:
 
 ```ts
-import { createClient } from '@picked/client'
+import { createClient } from 'picked'
 
 const picked = createClient({
   projectId: 'your-project-id',

package/dist/docs/how-to/render-a-step-form.md

@@ -59,13 +59,12 @@ Bind `form.props` to your `<form>` element and map over the fields.
 :::code-group
 
 ```tsx [React]
-import { useStep } from '@picked/react/hooks'
-import { useUnit } from 'effector-react'
+import { useStep, useStoreGlobal } from '@picked/react/hooks'
 
 function StepForm() {
   const { fields, form } = useStep()
-  const currentFields = useUnit(fields)
-  const isSubmitting = useUnit(form.submitting)
+  const currentFields = useStoreGlobal(fields)
+  const isSubmitting = useStoreGlobal(form.submitting)
 
   return (
     <form {...form.props}>

package/dist/docs/how-to/server-render-a-page.md

@@ -13,7 +13,7 @@ browser. You need a published Page and a server that renders React or Svelte.
 Create one client for each request, then call `serialize()`:
 
 ```ts
-import { createClient } from '@picked/client'
+import { createClient } from 'picked'
 import { serialize } from '@picked/client/server'
 
 const client = createClient(options)

package/dist/docs/how-to/switch-workspaces.md

@@ -22,7 +22,7 @@ picked login
 ```
 
 This opens your browser for a one-time OAuth sign-in and stores a session under
-`~/.picked/`. Confirm it with `picked whoami`. For CI, set `PICKED_TOKEN` instead — see
+`~/.picked/`. Confirm it with `picked whoami`. See
 [CLI authentication](/how-to/authenticate-the-cli).
 
 ## 2. Find a workspace
@@ -99,7 +99,6 @@ Active selection: none (using the config default).
 workspace in CI with no selection file, set the environment directly:
 
 ```bash
-PICKED_TOKEN="$TOKEN" \
 PICKED_PROJECT_ID=proj_a1b2 \
 PICKED_PREVIEW_TOKEN="$DRAFT_TOKEN" \
   picked generate types --check

package/dist/docs/how-to/write-a-predicate.md

@@ -13,7 +13,7 @@ such as a cart total or an account level.
 Pass a `predicates` object to `createClient()`:
 
 ```ts
-import { createClient } from '@picked/client'
+import { createClient } from 'picked'
 
 const client = createClient({
   projectId: 'your-project-id',

package/dist/docs/reference/dashboard/api-keys.mdx

@@ -7,8 +7,9 @@ import { Screenshot } from '../../../../components/Screenshot'
 
 # API keys
 
-An API key lets your code reach the Picked API. Use one for a server-side integration
-or for a CI/CD workflow.
+An API key lets your code reach the Picked API. Use one where your own code calls the API,
+such as a server-side integration. It does not sign the
+[CLI](/reference/tools/cli) in.
 
 <Screenshot
   route="/{orgSlug}/api-keys"
@@ -17,11 +18,11 @@ or for a CI/CD workflow.
 
 ## Use an API key
 
-Put your API key in the `Authorization` header of each request to the
+Put your API key in the `x-api-key` header of each request to the
 [Picked API](/tutorials/first-api-call).
 
 ```
-Authorization: Bearer your-api-key
+x-api-key: your-api-key
 ```
 
 ## Scopes

package/dist/docs/reference/dashboard/features.mdx

@@ -21,6 +21,19 @@ Each feature flag has a unique key. Your application uses this key to check whet
 Picked allocates a visitor to the feature flag. You set the key when you create the
 feature flag, and you cannot change it later.
 
+## Types
+
+Each feature flag has a type. You set the type when you create the feature flag, and you
+cannot change it later.
+
+| Type | What your site receives | Groups |
+| --- | --- | --- |
+| **Boolean** | `true` or `false` | Two |
+| **Text** | A string that you write, or `false` for the control group | Two or more |
+
+Choose **Boolean** for one change against no change. Choose **Text** when you must test
+several changes at the same time, and each change needs its own group.
+
 ## Set the allocation
 
 Set the allocation from the detail page of the feature flag:
@@ -28,19 +41,46 @@ Set the allocation from the detail page of the feature flag:
 | Control | What it does |
 | --- | --- |
 | **Enabled** | Whether Picked allocates a visitor to the feature flag. A disabled feature flag allocates nobody, and it records nothing. See [Disable a feature flag](#disable-a-feature-flag). |
-| **Weight** | The percentage of visitors that Picked allocates to the feature flag, from 0 to 100. |
+| **Weight** | The percentage of visitors that Picked allocates to a Boolean feature flag, from 0 to 100. |
+| **Variants** | The groups of a Text feature flag, and the traffic that each one receives. See [Variants](#variants). |
 | **Description** | An internal note about what the feature flag tests. |
 
-A feature flag has one weight. For each visitor it gives one of two outcomes:
+A Boolean feature flag has one weight. For each visitor it gives one of two outcomes:
 allocated, or not allocated. A weight of 30 allocates 30% of your visitors. The other
 70% stay unallocated. A weight of 0 allocates nobody. A weight of 100 allocates
 everybody.
 
+## Variants
+
+A Text feature flag has a table of variants. Each row is one group of visitors:
+
+| Column | What it does |
+| --- | --- |
+| **Name** | A label for the variant. It appears in your reports. You can change it at any time. |
+| **Value** | The string that your site receives for a visitor in this variant. |
+| **Weight** | The share of traffic for this variant, against the other rows. |
+
+The first row is **Control**. Picked always sends `false` to a visitor in the control
+group, and you cannot remove the row, move it, or change its value. It takes a weight like
+any other row.
+
+The weights are shares, and not percentages. Picked reduces them to their smallest whole
+numbers, so `10 : 10 : 20` and `1 : 1 : 2` are the same split. The percentage beside each
+row shows the traffic that the variant receives.
+
+Choose **Even split** to give every variant the same weight.
+
+:::info
+The order of the rows is the order that you read them in. It has no effect on the
+allocation, so you can move a row and no visitor changes group.
+:::
+
 ## How Picked allocates a visitor
 
-The allocation is deterministic. It derives from the visitor ID, the ID of the feature
-flag, and the weight. Each feature flag gets its own value, so tests that run at the
-same time are independent. See
+The allocation is deterministic. It derives from the visitor ID and from the ID of the
+feature flag. A Boolean feature flag then compares that value against the weight, and a
+Text feature flag compares it against the range of each variant. Each feature flag gets its
+own value, so tests that run at the same time are independent. See
 [About feature flag allocation](/explanation/feature-flag-allocation).
 
 ## Disable a feature flag

package/dist/docs/reference/delivery-api/workspace-schema.md

@@ -28,6 +28,7 @@ The response is a [JSON Schema draft 2020-12](https://json-schema.org/draft/2020
 | `x-picked-source` | `"published"` or `"preview"` — mirrors the surface you requested. |
 | `x-picked-version-id` | Published workspace version id, or `null` on preview. |
 | `x-picked-step-content-models` | Map of step key → content model key, which gives each layout its type. |
+| `x-picked-feature-values` | Map of feature key → the values that the feature can serve. Picked adds this field only when the workspace has a Text feature flag. |
 | `$defs.contentModels` | JSON Schema definitions for each content model. |
 | `$defs.contentBlocks` | JSON Schema definitions for reusable content blocks. |
 | `$defs.fields` | Object schema for project field values. |
@@ -41,6 +42,13 @@ On the published surface, the schema reflects your last published workspace. On
 
 When no published schema exists, the published endpoint returns `404` and tells you to publish the workspace.
 
+A Boolean feature flag serves `true` or `false`, and it contributes no entry to
+`x-picked-feature-values`. A workspace of Boolean feature flags therefore omits the field.
+A schema that Picked published before Text feature flags existed also omits it.
+
+Picked sorts the values of each Text feature flag by the key of the variant. The document
+therefore does not change when you rename a variant or move a row.
+
 ## Example
 
 ```bash
@@ -57,11 +65,14 @@ curl https://api.picked.app/api/v1/projects/proj_123/schema
   "x-picked-step-content-models": {
     "intro": "welcome-page"
   },
+  "x-picked-feature-values": {
+    "hero": [false, "hero-a", "hero-b"]
+  },
   "$defs": {
     "contentModels": {},
     "contentBlocks": {},
     "fields": { "type": "object", "additionalProperties": false, "properties": {} },
-    "featureKeys": { "type": "string", "enum": ["default"] },
+    "featureKeys": { "type": "string", "enum": ["default", "hero"] },
     "experienceKeys": { "type": "string", "enum": ["welcome-survey"] },
     "stepKeys": { "type": "string", "enum": ["intro"] }
   }