@spree/docs 0.1.240 → 0.1.242

package/dist/developer/customization/permissions.md

@@ -11,15 +11,17 @@ Every grantable capability is a flat key of the form `read_<resource>` or `write
 
 Keys are per resource, not per action. The money-adjacent areas (`payments`, `refunds`, `gift_cards`, `store_credits`) are separate resources from `orders`, so "view orders but don't refund" needs no special casing.
 
-Roles as code is plain ActiveRecord:
-
-```ruby
-# db/seeds.rb
-Spree::Role.find_or_create_by!(name: 'support')
-  .update!(permissions: %w[read_orders read_customers], description: 'Read-only support')
+Roles are data, so create them where you manage the rest of your store's data: **Settings → Staff → Roles** in the dashboard, or the Admin API when you want it scripted.
+
+```bash
+spree api post roles --data '{
+  "name": "Support",
+  "description": "Read-only support",
+  "permissions": ["read_orders", "read_customers"]
+}'
 ```
 
-A role with `mutable: false` (set from seeds or the console) renders read-only in the dashboard — for roles the application does not want store staff to edit. The `admin` role is always protected.
+A role marked immutable renders read-only in the dashboard, for roles the application does not want store staff editing. The `admin` role is always protected.
 
 ## Registering extension permissions
 
@@ -56,30 +58,13 @@ Naming another audience exposes the scope to a principal outside the store's own
 
 A key never decides *which rows* its holder reaches. That is the controller's job, through scope fetching — a seller holding `write_products` manages their own products because the seller API reads through `current_seller`, not because the key says so.
 
-## Beyond the catalog
+## What the catalog does not cover
 
-The catalog is deliberately flat: it answers "may this role touch this kind of record", and that is the whole grant vocabulary. Two rules that do *not* belong in it:
+The catalog is deliberately flat: it answers "may this role touch this kind of record", and that is the whole grant vocabulary.
 
-- **Record-state rules** ("a completed order cannot be deleted") live on models and workflows, so they bind every caller — including secret API keys, which never consult CanCanCan.
-- **Row-level restrictions** (a support agent limited to one market) are not expressible as keys. Replace the ability class outright:
+**Record-state rules** — "a completed order cannot be deleted" — belong on models and workflows, not on roles. Put them there and they bind every caller, including secret API keys, which never consult the role system at all. A rule enforced only in the permission layer is a rule the API can walk straight past.
 
-```ruby
-# config/initializers/spree.rb
-Spree::Dependencies.ability_class = 'MyApp::Ability'
-```
-
-```ruby
-# app/models/my_app/ability.rb
-class MyApp::Ability < Spree::Ability
-  def initialize(user, options = {})
-    super
-    return unless user.respond_to?(:market_id) && user.market_id
-
-    cannot :manage, Spree::Order
-    can [:read, :admin], Spree::Order, market_id: user.market_id
-  end
-end
-```
+**Row-level restrictions**, such as a support agent limited to one market, are not expressible as permission keys. Scope them where the records are read: a controller reaching through `current_store.orders` rather than `Spree::Order` already restricts by tenant, and the same technique narrows by market or seller. See [extending the API](api.md).
 
 ## How enforcement works
 

package/dist/developer/customization/validations.md

@@ -52,27 +52,6 @@ Both cart keys appear above because adding to a cart and setting a quantity are
 different flows. See [Services & Workflows](workflows.md)
 for the full hook list.
 
-## Adding a rule to a model
-
-For rules about the shape of a record, a decorator is the supported route:
-
-```ruby
-# app/models/spree/product_decorator.rb
-module MyStore
-  module ProductDecorator
-    def self.prepended(base)
-      base.validates :external_id, presence: true, uniqueness: true
-    end
-  end
-end
-
-Spree::Product.prepend(MyStore::ProductDecorator)
-```
-
-Decorators couple you to Spree internals, so prefer a hook when the rule is
-really about an operation. See
-[Decorators](decorators.md).
-
 ## Relaxing a rule Spree ships
 
 Never call `clear_validators!` — it wipes every validation on the model,
@@ -81,7 +60,8 @@ cause. Use one of these instead.
 
 ### Store preferences
 
-Some rules are already switchable, per store, from the dashboard or a console:
+Some rules are switchable per store, with no code at all. Change them in the
+dashboard under **Settings → Store**, or through the Admin API:
 
 | Preference | Effect |
 |---|---|
@@ -90,30 +70,23 @@ Some rules are already switchable, per store, from the dashboard or a console:
 | `address_requires_company` | Requires it — only meaningful with the field shown |
 | `disable_sku_validation` | Turns off SKU uniqueness |
 
-```ruby
-store.update!(preferred_address_requires_company: true)
-```
-
-### Overriding the gating predicate
 
-Most conditional validations in `Spree::Address` are gated on a predicate you
-can override, which is far safer than removing the validation:
-
-```ruby
-module MyStore
-  module AddressDecorator
-    # Business addresses only in this store.
-    def require_company?
-      !quick_checkout
-    end
-  end
-end
+```typescript Admin SDK
+await adminClient.store.update({
+  preferred_address_requires_phone: false,
+})
+```
 
-Spree::Address.prepend(MyStore::AddressDecorator)
+```bash cURL
+curl -X PATCH 'https://api.mystore.com/api/v3/admin/store' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{ "preferred_address_requires_phone": false }'
 ```
 
-`require_name?`, `require_street?`, `require_postal_code?`, `require_phone?` and
-`require_company?` all work this way.
+
+> **NOTE:** All four are editable in the dashboard except `address_requires_company`, which
+>   is API-only for now.
 
 ### The address validator registry
 
@@ -121,7 +94,7 @@ Address rules are regional and business-specific, so addresses carry a registry
 of extra validator classes you can add to and remove from:
 
 ```ruby
-# config/initializers/spree.rb — or config.to_prepare for your own classes
+# server/config/initializers/spree.rb — or config.to_prepare for your own classes
 Spree.validators.addresses.register(MyStore::PostBoxValidator)
 
 # Drop a rule Spree ships

package/dist/developer/getting-started/quickstart.md

@@ -6,35 +6,39 @@ description: "Install Spree Commerce locally, run your first store, and deploy i
 
 ## Using `create-spree-app`
 
-  The quickest way to get started. Scaffolds a full Spree project with Next.js Storefront (optional).
+  The quickest way to get started. Scaffolds a full Spree project with React admin dashboard and Next.js Storefront (optional).
 
-  **Requirements:** [Node.js](https://nodejs.org/) 20+ and [Docker](https://docs.docker.com/get-docker/) running.
+  **Requirements:** [Node.js](https://nodejs.org/) 24+ and [Docker](https://docs.docker.com/get-docker/) running.
 
   ```bash
   npx create-spree-app@latest my-store
   ```
 
-  The CLI walks you through an interactive setup:
+  The CLI walks you through an interactive setup where you choose the project name and whether to include the Next.js Storefront. It then builds a Docker stack with Postgres, and Spree API.
 
-  1. Choose **Full-stack** (Backend + Next.js Storefront) or **Backend only**
-  2. Optionally load **sample data** (products, categories, images)
+  Once complete it will open a browser window so you can finalize the store setup (pick name, currency, your email/password).
 
-  Once complete, your store should be running at [http://localhost:3000/admin](http://localhost:3000/admin). The port can be different if `3000` is already used on your system.
+  <video autoPlay muted loop playsInline controls className="block w-auto max-w-full h-auto rounded-xl" src="/videos/store-setup.mp4"></video>
 
-  See the full [create-spree-app documentation](../create-spree-app/quickstart.md) for all CLI flags and options.
+## Project structure and overview
 
-## Accessing Admin Panel
+`create-spree-app` creates a project folder like this:
 
-Navigate to [http://localhost:3000/admin](http://localhost:3000/admin) and log in with the default credentials:
-
-| | |
-|---|---|
-| **Email** | `spree@example.com` |
-| **Password** | `spree123` |
-
-Upon successful authentication, you should see the admin screen:
-
-<img src="/images/spree_admin_dashboard.png" />
+```
+my-store/
+├── server/                 # The Spree API
+├── apps/
+│   ├── dashboard/          # Admin dashboard (Vite/React)
+│   ├── seller-dashboard/   # Seller panel, for marketplaces (Vite/React)
+│   └── storefront/         # Next.js storefront (if selected)
+├── .env                    # Ports, secrets and service URLs
+├── .spree/                 # CLI credentials — gitignored, created on first run
+├── docker-compose.yml      # The local stack
+├── package.json            # Scripts and the pinned @spree/cli
+├── AGENTS.md               # Instructions for coding agents
+├── CLAUDE.md               # Project layout and conventions
+└── README.md               # How to run everything
+```
 
 ## Using the Spree CLI
 
@@ -58,18 +62,15 @@ See the [Spree CLI guide](../cli/quickstart.md) for all commands and the [Admin
 
 ## Next Steps
 
+- [How Spree fits together](../core-concepts/architecture.md) — The catalog, the cart, the order and fulfillment — what each one is for, and the two APIs you build against. Twenty minutes here saves a lot of guessing later, and it ends by pointing you at whichever path suits you.
 
-  - [Build with AI Agents](../agentic/overview.md) — Install the Spree agent skills and connect the docs MCP server — Claude Code, Cursor, Copilot, and 60+ other tools learn Spree's conventions and build features with you.
-  - [Customization Tutorial](../tutorial/introduction.md) — Build a complete custom feature — model, admin UI, API, and TypeScript SDK — step by step.
-  - [Core Concepts](../core-concepts/architecture.md) — Understand how Spree models commerce — stores, products, orders, payments.
-  - [Next.js Storefront](../storefront/nextjs/quickstart.md) — Customize and extend the headless storefront.
-
+In a hurry? Jump straight to the [tutorial](../tutorial/introduction.md) to build a feature end to end, the [Next.js Storefront](../storefront/nextjs/quickstart.md) to put a storefront in front of it, or the [API reference](../../api-reference/admin-api/introduction.md) to see what you can do with the Admin API.
 
 > **TIP:** Using an AI coding agent? Run `npx skills add spree/agent-skills` in your new project — it teaches your agent the customization patterns before you write a line of code. See [Agentic Development](../agentic/overview.md).
 
 ---
 
-Congrats! You've set up your Spree Commerce and it's looking amazing!
+Congrats! You've set up your Spree application and it's looking amazing!
 
 Give Spree a [GitHub Star](https://github.com/spree/spree), why don't ya? Thank you for supporting Spree open-source! 
 

package/dist/developer/how-to/custom-promotion.md

@@ -150,7 +150,7 @@ module Spree
         private
 
         def matches_brand?(line_item)
-          brand = line_item.product.get_metafield('details.brand')&.value
+          brand = line_item.product.get_custom_field('details.brand')&.value
           preferred_brand_names.include?(brand)
         end
       end

package/dist/developer/how-to/custom-search-provider.md

@@ -224,9 +224,9 @@ Background jobs (`IndexJob`, `RemoveJob`) fire on `after_commit` when `indexing_
 
 Always use prefixed IDs (`ctg_abc`, `prod_xyz`, `optval_abc`) when indexing. Never use raw database IDs — Spree supports UUID primary keys.
 
-### Metafield search schema
+### Custom Field search schema
 
-Product metafields marked `searchable` / `sortable` on `MetafieldDefinition` are projected through `Spree::SearchProvider::MetafieldSchema` — shared by providers and `ProductPresenter`. Toggle participation with definition flags; run `rake spree:search:reindex` after changes when using Meilisearch.
+Product custom fields marked `searchable` / `sortable` on `CustomFieldDefinition` are projected through `Spree::SearchProvider::CustomFieldSchema` — shared by providers and `ProductPresenter`. Toggle participation with definition flags; run `rake spree:search:reindex` after changes when using Meilisearch.
 
 Document shaping for `cf_*` fields stays on `search_product_presenter` — the only search-related dependency.
 

package/dist/developer/how-to/custom-stock-splitter.md

@@ -170,12 +170,12 @@ end
 
 ### Step 4 (optional): Add a Variant-side Predicate
 
-The example above relies on `variant.refrigerated?`. In a real plugin you'd back that with a [Custom Field](../core-concepts/metafields.md) on `Spree::Variant` — say a boolean metafield with key `refrigerated` — and define the predicate as a thin reader:
+The example above relies on `variant.refrigerated?`. In a real plugin you'd back that with a [Custom Field](../core-concepts/metafields.md) on `Spree::Variant` — say a boolean custom field with key `refrigerated` — and define the predicate as a thin reader:
 
 ```ruby app/models/spree/variant_decorator.rb
 Spree::Variant.class_eval do
   def refrigerated?
-    metafields.find_by(namespace: 'logistics', key: 'refrigerated')&.value == 'true'
+    custom_fields.find_by(namespace: 'logistics', key: 'refrigerated')&.value == 'true'
   end
 end
 ```

package/dist/developer/sdk/admin/extending.md

@@ -66,5 +66,5 @@ The SDK transforms `filter`/`sort` into the Ransack-flavored query string the Ad
 ## See also
 
 - The [Store SDK extending guide](../extending.md) covers the same pattern for storefront endpoints — the API is identical, only the base path (`/api/v3/store`) and auth header differ.
-- The [API](../../tutorial/admin-api.md) and [SDK](../../tutorial/storefront.md) tutorials walk through creating new Spree endpoints end-to-end (Rails controller, serializer, TypeScript types). Everything they show for the Store API applies equivalently for the Admin API.
+- The [API](../../tutorial/model-and-api.md) and [SDK](../../tutorial/storefront.md) tutorials walk through creating new Spree endpoints end-to-end (Rails controller, serializer, TypeScript types). Everything they show for the Store API applies equivalently for the Admin API.
 - For building dashboard UI on top of your custom endpoint, see the [Dashboard](../../dashboard/overview.md) section — start with [Customization Quickstart](../../dashboard/customization/quickstart.md) for in-app changes or [Plugin Overview](../../dashboard/plugins/overview.md) for redistributable packages.

package/dist/developer/sdk/admin/quickstart.md

@@ -66,4 +66,4 @@ const page: PaginatedResponse<Order> = await client.orders.list()
   - [Admin API Reference](../../../api-reference/admin-api/introduction.md) — The underlying REST API the SDK wraps — every endpoint, parameter, and response shape.
 
 
-> **TIP:** Adding your own resources? The [`spree generate api_resource`](../../tutorial/admin-api.md) generator scaffolds Admin API endpoints (model, serializers, controllers, specs) in one command, and the [extending guide](../extending.md) shows how to call custom endpoints from the SDK.
+> **TIP:** Adding your own resources? The [`spree generate api_resource`](../../tutorial/model-and-api.md) generator scaffolds Admin API endpoints (model, serializers, controllers, specs) in one command, and the [extending guide](../extending.md) shows how to call custom endpoints from the SDK.

package/dist/developer/sdk/admin/resources.md

@@ -127,4 +127,4 @@ await client.customFields('Spree::Product', 'prod_xxx').list()
 
 ## Adding your own resources
 
-The resource map grows with your store. The [`spree generate api_resource`](../../tutorial/admin-api.md) generator scaffolds new Admin API endpoints (model, serializers, controllers, routes, specs) in one command — then call them from the SDK with a [custom fetch or raw request](../extending.md), or generate a typed client for them.
+The resource map grows with your store. The [`spree generate api_resource`](../../tutorial/model-and-api.md) generator scaffolds new Admin API endpoints (model, serializers, controllers, routes, specs) in one command — then call them from the SDK with a [custom fetch or raw request](../extending.md), or generate a typed client for them.

package/dist/developer/sdk/configuration.md

@@ -162,7 +162,7 @@ All types are exported as unprefixed names (e.g., `Product`, `Order`). Legacy `S
 - `OptionType` - Option type (e.g., Size, Color)
 - `OptionValue` - Option value (e.g., Small, Red)
 - `DigitalLink` - Digital download link
-- `Metafield` - Custom metafield data
+- `CustomField` - Custom field data
 
 ### Wishlist Types
 - `Wishlist` - Wishlist

package/dist/developer/sdk/extending.md

@@ -30,4 +30,4 @@ const nike = await client.request<Brand>('GET', '/brands/nike')
 
 `client.request` uses the same auth headers, retry logic, and locale/currency defaults as `client.products.list()` or any other built-in resource.
 
-For a complete walkthrough — creating the API endpoints on the backend, defining TypeScript types, filtering, and expanding associations — see the [API](../tutorial/admin-api.md) and [SDK](../tutorial/storefront.md) tutorials.
+For a complete walkthrough — creating the API endpoints on the backend, defining TypeScript types, filtering, and expanding associations — see the [API](../tutorial/model-and-api.md) and [SDK](../tutorial/storefront.md) tutorials.

package/dist/developer/tutorial/testing.md

@@ -1,129 +1,83 @@
 ---
 title: Testing
-description: Test the Brands feature at every layer — model and API specs with RSpec, dashboard tests with Vitest, and one end-to-end Playwright pass.
+description: Test the Brands feature — running the generated backend specs, unit-testing the dashboard logic you wrote, and one Playwright pass through the browser.
 ---
 
-Each layer gets the test that suits it: fast backend specs for the model and both APIs, component tests for the dashboard, and one end-to-end pass proving the whole path works.
+Most of the backend is generated, so most of the testing worth doing is on the code you wrote yourself — which is mostly in the dashboard. This chapter covers the backend briefly, spends longer on the dashboard, and ends with one browser pass proving the layers are actually connected.
 
-Your project arrives with testing already configured — RSpec, FactoryBot, and Spree's own test helpers, including every factory core ships. You can write a spec against `create(:product)` without setting anything up.
+## The backend
 
-## Step 1: Run what the generator wrote
-
-The generator in step 1 already wrote a factory and a controller spec per API side, so this step is mostly filling in rather than starting over:
+Your project arrives with a fully configured testing environment for backend testing. The generator wrote all the files needed for running API tests:
 
 ```text
-server/spec/factories/spree/brand_factory.rb
 server/spec/controllers/spree/api/v3/store/brands_controller_spec.rb
 server/spec/controllers/spree/api/v3/admin/brands_controller_spec.rb
 ```
 
-Run them:
+You can now run them, a directory or a single file at a time:
 
 ```bash
 spree rspec spec/controllers/spree/api/v3/
+spree rspec spec/models/spree/brand_spec.rb
 ```
 
-The generated factory is the starting point for every other spec — always build records through factories rather than creating them directly, so a change to the model does not mean editing fifty specs.
-
-## Step 2: Model specs
+## The dashboard
 
-Test what you wrote, not what the framework already guarantees. A presence validation on a required column needs no spec; the association behavior you chose does:
+This is where most of your own code lives, so it is where most of your tests belong. Vitest and Playwright come configured, so there is nothing to set up:
 
-```ruby server/spec/models/spree/brand_spec.rb
-RSpec.describe Spree::Brand, type: :model do
-  it 'nullifies the reference instead of deleting products' do
-    brand = create(:brand)
-    product = create(:product, brand: brand)
-
-    brand.destroy
-
-    expect(product.reload.brand_id).to be_nil
-    expect(product).to be_persisted
-  end
-end
+```bash
+cd apps/dashboard && pnpm test
 ```
 
-Prefer `build` over `create` when a record does not need to hit the database — it is markedly faster across a suite.
-
-## Step 3: Controller specs
-
-Controller specs are where edge cases belong: authorization, scoping, filtering, error shapes. Always `render_views`, so a broken serializer fails the spec rather than passing silently:
+### What is worth a unit test
 
-```ruby server/spec/controllers/spree/api/v3/store/brands_controller_spec.rb
-RSpec.describe Spree::Api::V3::Store::BrandsController, type: :controller do
-  render_views
+Not components. Rendering a card to assert it shows a brand name tests React, not your feature, and breaks every time the markup moves. Test the **logic between the UI and the API** — the parts with decisions in them.
 
-  it 'exposes public fields only' do
-    create(:brand, name: 'Wilson')
+Query keys are the clearest example. Every key must be scoped to the current store, or one store's rows leak into another after a switch. That is a rule a test can hold you to:
 
-    get :index, params: { format: :json }
+```ts apps/dashboard/src/brands/client.test.ts
+import { withStoreScope } from '@spree/dashboard'
+import { QueryClient } from '@tanstack/react-query'
+import { describe, expect, it } from 'vitest'
+import { brandInvalidations } from './client'
 
-    record = json_response['data'].first
-    expect(record['id']).to start_with('brand_')
-    expect(record).not_to have_key('created_at')
-  end
+const STORE = 'store_abc123'
 
-  it 'filters by name' do
-    create(:brand, name: 'Wilson')
-    create(:brand, name: 'Penn')
+describe('brand cache invalidation', () => {
+  it('refreshes the brand list without touching another store', () => {
+    const client = new QueryClient()
+    client.setQueryData(withStoreScope(['brands'], STORE), [])
+    client.setQueryData(withStoreScope(['brands'], 'store_other'), [])
 
-    get :index, params: { q: { name_cont: 'wil' }, format: :json }
+    for (const key of brandInvalidations()) {
+      client.invalidateQueries({ queryKey: withStoreScope(key, STORE) })
+    }
 
-    expect(json_response['data'].map { |b| b['name'] }).to eq(['Wilson'])
-  end
-end
+    const stale = client.getQueryCache().getAll().filter((q) => q.state.isInvalidated)
+    expect(stale).toHaveLength(1)
+  })
+})
 ```
 
-That second example is worth keeping: it proves the Ransack allowlist from step 1 actually permits `name_cont`. Remove `name` from `whitelisted_ransackable_attributes` and this spec fails, which is exactly what you want.
+Driving a real `QueryClient` means the assertion goes through TanStack's own prefix matching rather than a hand-rolled key comparison — so it stays true if the matching rules change.
 
-> **NOTE:** Specs run against a store the suite sets up for you, available as `@default_store`. Use it rather than creating another store marked as the default — two of them in one run produce failures that surface far from their cause.
+The same applies to anything else with a decision in it: a function mapping form values to an API payload, a permission predicate deciding whether a nav entry shows, a filter translating table state into Ransack params. Each is a pure function, each is a two-line test.
 
-## Step 4: Dashboard tests
+### What is not worth a unit test
 
-The dashboard is a TypeScript app, so its code tests with Vitest:
+- **Components.** Asserting a card renders text is testing React.
+- **`BrandsClient.list` itself.** It is a one-line wrapper around `adminClient.request`. A test would mock the thing it wraps and assert the mock was called — proving nothing about whether the endpoint exists.
+- **Anything the compiler already catches.** A wrong prop type is a build failure, not a test case.
 
-```bash
-cd apps/dashboard && pnpm test
-```
-
-Test the client wrappers and any logic in your pages. Mock the HTTP layer rather than the client module, so the test exercises the real request path:
-
-```ts apps/dashboard/src/brands/client.test.ts
-import { http, HttpResponse } from 'msw'
-import { setupServer } from 'msw/node'
-import { afterAll, afterEach, beforeAll, describe, expect, it } from 'vitest'
-import { BrandsClient } from './client'
-
-const server = setupServer(
-  http.get('*/api/v3/admin/brands', () =>
-    HttpResponse.json({ data: [{ id: 'brand_k5nR8xLq', name: 'Wilson' }] }),
-  ),
-)
-
-beforeAll(() => server.listen())
-afterEach(() => server.resetHandlers())
-afterAll(() => server.close())
-
-describe('BrandsClient', () => {
-  it('lists brands from the admin endpoint', async () => {
-    const result = await BrandsClient.list({ per_page: 10 })
-
-    expect(result.data).toHaveLength(1)
-    expect(result.data[0].name).toBe('Wilson')
-  })
-})
-```
+That second one is worth dwelling on: the question "does `/brands` actually return brands" cannot be answered by a unit test at all. It needs the real API, which is the next section.
 
-Mocking the HTTP layer rather than the client module means the test exercises the real request path — the URL, the params and the response shape — so a wrong endpoint fails here instead of in the browser.
-
-## Step 5: One end-to-end pass
+## End to end, through the browser
 
 Everything above tests a layer in isolation. One Playwright spec proves the layers are actually connected — a brand created through the Admin API reaches the dashboard screen you built:
 
 ```ts apps/dashboard/e2e/brands.spec.ts
 import { expect, test } from '@playwright/test'
-import { createBrand } from './helpers/api'
-import { login } from './helpers/login'
+import { createBrand, login } from './helpers'
 
 test('a brand appears on the brands screen', async ({ page }) => {
   const name = `Wilson ${Date.now()}`
@@ -147,21 +101,21 @@ Two conventions matter here:
 
 ## What to run before you push
 
-Run the specs for what you changed rather than the whole suite:
+Run what you changed, not everything:
 
 ```bash
-spree rspec spec/models/spree/brand_spec.rb
-spree rspec spec/controllers/spree/api/v3/
+spree rspec spec/models/spree/brand_spec.rb   # the backend
+cd apps/dashboard && pnpm test                # the dashboard
 ```
 
-Pass a file, a directory, or a single example with a line number (`spec/models/spree/brand_spec.rb:12`). Keep the full run for continuous integration, where waiting costs you nothing.
+Keep the full suite and the end-to-end pass for continuous integration, where waiting costs you nothing.
 
 ## You're done
 
 You have built one feature through every layer of Spree:
 
 - A model with a Store API and an Admin API, generated in one command
-- A dashboard plugin giving staff a place to manage it
+- A dashboard screen giving staff a place to manage it
 - Storefront pages rendering it through typed SDK calls
 - Lifecycle events other systems react to
 - Tests at each layer, plus one pass across all of them

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@spree/docs",
-  "version": "0.1.240",
+  "version": "0.1.242",
   "description": "Spree Commerce developer documentation for AI agents and local reference",
   "type": "module",
   "license": "CC-BY-4.0",