@spree/docs 0.1.229 → 0.1.231

package/dist/developer/core-concepts/sellers.md

@@ -52,12 +52,62 @@ stateDiagram-v2
 
 Only an **approved** seller can sell, and even then not while they're on holiday — sellers can pause their own listings without the marketplace suspending them.
 
+## What a seller owns
+
+A seller is a tenant inside the marketplace: their own catalogue, their own
+stock, their own shipping setup and their own money trail. Delivery profiles and
+zones stay with the operator — a seller picks from them rather than defining
+them.
+
+```mermaid
+erDiagram
+    Store ||--o{ Seller : "hosts"
+    Seller ||--o{ Product : "lists"
+    Seller ||--o{ StockLocation : "ships from"
+    Seller ||--o{ DeliveryMethod : "own rates"
+    Seller ||--o{ PackageType : "own packaging"
+    Seller ||--o{ Order : "fulfils"
+    Seller ||--o{ CommissionLine : "charged"
+    Seller ||--o{ SellerTransfer : "earns"
+    Seller ||--o{ SellerPayout : "paid out"
+    Seller ||--o{ SellerRequirementSubmission : "onboarding"
+    Seller ||--o{ Policy : "publishes"
+
+    Seller {
+        string name
+        string slug
+        string status
+        string contact_email
+    }
+```
+
+A seller's delivery methods are their own — internal rates and manual
+fulfillment, since carrier accounts stay with the operator. Their package types
+sit alongside the marketplace's shared ones, so they can pack into the
+operator's standard cartons or record their own.
+
+
 ```typescript Admin SDK
 await adminClient.sellers.invite('sel_xxx')
 await adminClient.sellers.approve('sel_xxx')
 await adminClient.sellers.suspend('sel_xxx', { reason: 'Unresolved delivery complaints' })
 ```
 
+```bash cURL
+# Invite, approve, suspend
+curl -X POST 'https://api.mystore.com/api/v3/admin/sellers/sel_xxx/invite' \
+  -H 'X-Spree-API-Key: sk_xxx'
+
+curl -X POST 'https://api.mystore.com/api/v3/admin/sellers/sel_xxx/approve' \
+  -H 'X-Spree-API-Key: sk_xxx'
+
+curl -X POST 'https://api.mystore.com/api/v3/admin/sellers/sel_xxx/suspend' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{ "reason": "Unresolved delivery complaints" }'
+```
+
+
 Status is never set by writing to the field — each move is its own action, so approving a seller can run the checks that belong to approving.
 
 ## Onboarding requirements
@@ -66,17 +116,35 @@ What a vendor must do before selling differs by marketplace. A hardware marketpl
 
 So the checklist is **configured, not hardcoded**. Each store defines its own:
 
+
 ```typescript Admin SDK
 const { data: types } = await adminClient.sellerRequirements.types()
 
 await adminClient.sellerRequirements.create({
-  type: 'Spree::SellerRequirements::MinimumProducts',
+  type: 'minimum_products',
   name: 'List at least three products',
   required: true,
   preferences: { minimum_count: 3 },
 })
 ```
 
+```bash cURL
+# Requirement kinds this marketplace offers
+curl 'https://api.mystore.com/api/v3/admin/seller_requirements/types' \
+  -H 'X-Spree-API-Key: sk_xxx'
+
+# Add one to the checklist
+curl -X POST 'https://api.mystore.com/api/v3/admin/seller_requirements' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{
+    "type": "minimum_products",
+    "name": "List at least three products",
+    "required": true
+  }'
+```
+
+
 Requirements come in three flavours, which is what lets one mechanism cover very different demands:
 
 | Kind | How it's satisfied |
@@ -89,6 +157,7 @@ Shipped out of the box: accepting terms, completing the profile, a billing addre
 
 A seller sees their checklist and its progress:
 
+
 ```typescript Seller SDK
 const onboarding = await sellerClient.onboarding.get()
 
@@ -102,6 +171,13 @@ onboarding.requirements.forEach((r) => {
 await sellerClient.onboarding.submitForReview()
 ```
 
+```bash cURL
+curl 'https://marketplace.example.com/api/v3/seller/onboarding' \
+  -H 'Authorization: Bearer $SELLER_JWT' \
+  -H 'X-Spree-Seller-Id: sel_xxx'
+```
+
+
 The checklist is **worked out when read**, never stored on the seller. So a requirement added next month applies immediately to everyone, and nothing has to be backfilled.
 
 > **NOTE:** The checklist is enforced at exactly two moments — submitting for review, and approval. Approval refuses while a required item is outstanding, unless an operator deliberately overrides it.
@@ -114,11 +190,26 @@ A product can name a seller. No seller means it's the marketplace's own stock
 
 Sellers don't publish; they **submit**, and the marketplace decides. That review flow, and the statuses behind it, are covered in [Products](products.md#seller-submissions).
 
+
 ```typescript Seller SDK
 const product = await sellerClient.products.create({ name: 'Handmade Vase' })
 await sellerClient.products.submit(product.id)
 ```
 
+```bash cURL
+# Create a product, then submit it for review
+curl -X POST 'https://marketplace.example.com/api/v3/seller/products' \
+  -H 'Authorization: Bearer $SELLER_JWT' \
+  -H 'X-Spree-Seller-Id: sel_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{ "name": "Handmade Vase" }'
+
+curl -X POST 'https://marketplace.example.com/api/v3/seller/products/prod_xxx/submit' \
+  -H 'Authorization: Bearer $SELLER_JWT' \
+  -H 'X-Spree-Seller-Id: sel_xxx'
+```
+
+
 Stores that trust their vendors can turn auto-approval on and skip the queue.
 
 ## One checkout, several sellers
@@ -156,12 +247,19 @@ Two details worth knowing:
 
 Commission is what the marketplace charges for the sale — configured as **rates**, and recorded per sale as immutable **commission lines**.
 
+
 ```typescript Admin SDK
 const { data: lines } = await adminClient.commissionLines.list({
-  filter: { seller_id_eq: 'sel_xxx' },
+  seller_id_eq: 'sel_xxx',
 })
 ```
 
+```bash cURL
+curl 'https://api.mystore.com/api/v3/admin/commission_lines?q[seller_id_eq]=sel_xxx' \
+  -H 'X-Spree-API-Key: sk_xxx'
+```
+
+
 Three things are worth knowing here; the rest is on its own page.
 
 - **Rates are tried in list order**, and the first whose rules match wins. A rate with no rules matches everything, so the marketplace default belongs at the bottom.
@@ -184,6 +282,7 @@ Sellers get their own application — not access to the marketplace's dashboard.
 
 That last point is the security property worth relying on: a seller cannot ask for another seller's data, because there's nowhere in the request to name one.
 
+
 ```typescript Seller SDK
 import { createSellerClient } from '@spree/seller-sdk'
 
@@ -197,6 +296,14 @@ await sellerClient.orders.fulfillments.fulfill(orderId, fulfillmentId, {
 })
 ```
 
+```bash cURL
+# Sign in, then use the returned JWT on every seller call
+curl -X POST 'https://marketplace.example.com/api/v3/seller/auth/login' \
+  -H 'Content-Type: application/json' \
+  -d '{ "email": "vendor@example.com", "password": "…" }'
+```
+
+
 Sellers can manage their profile, invite their own team, list and submit products, see and fulfil their orders, manage their stock locations, delivery methods and packaging, and work through onboarding. They cannot see other sellers, the marketplace's own catalog, or anything belonging to the store at large.
 
 What a seller's staff may do is governed by [roles](staff-roles.md) owned by the seller — the same permission system as the back office, with a narrower set of keys, so a seller role can never reach store settings.

package/dist/developer/core-concepts/slugs.md

@@ -59,7 +59,7 @@ If a slug already exists, Spree appends the SKU or a unique identifier to ensure
 
 Category slugs include the full parent path, making them hierarchical:
 
-```
+```text
 clothing                       → "clothing"
 clothing/shirts                → "clothing/shirts"
 clothing/shirts/t-shirts       → "clothing/shirts/t-shirts"

package/dist/developer/core-concepts/staff-roles.md

@@ -44,6 +44,7 @@ Because roles are scoped to their owner, two stores can each define a "Manager"
 
 A permission key is a verb and a resource — `read_orders`, `write_products`. Roles hold a list of them:
 
+
 ```typescript Admin SDK
 const role = await adminClient.roles.create({
   name: 'Fulfillment staff',
@@ -52,12 +53,31 @@ const role = await adminClient.roles.create({
 })
 ```
 
+```bash cURL
+curl -X POST 'https://api.mystore.com/api/v3/admin/roles' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{
+    "name": "Fulfillment staff",
+    "description": "Can see orders and ship them, nothing else",
+    "permissions": ["read_orders", "write_fulfillments", "read_products"]
+  }'
+```
+
+
 Every grantable key is discoverable, so a permission picker never needs a hardcoded list:
 
+
 ```typescript Admin SDK
 const { data: permissions } = await adminClient.permissions.list()
 ```
 
+```bash cURL
+curl 'https://api.mystore.com/api/v3/admin/permissions' \
+  -H 'X-Spree-API-Key: sk_xxx'
+```
+
+
 Keys are grouped so they can be presented sensibly — orders, catalog, marketing, customers, settings, access and analytics.
 
 | Group | Covers |
@@ -84,13 +104,13 @@ A role is deletable only when nothing depends on it: staff assignments and pendi
 
 Use the Spree CLI to create admin users:
 
-```bash
+```bash Spree CLI
 spree user create
 ```
 
 The CLI will prompt you for the email and password. You can also pass them directly:
 
-```bash
+```bash Spree CLI
 spree user create --email admin@example.com --password secret123
 ```
 
@@ -140,7 +160,7 @@ You can invite new admins through the Admin Panel or programmatically.
 
 Using the [Admin SDK](../sdk/admin/quickstart.md), call `client.invitations.create`:
 
-```typescript
+```typescript Admin SDK
 import { createAdminClient } from '@spree/admin-sdk'
 
 const client = createAdminClient({

package/dist/developer/core-concepts/stores.md

@@ -7,6 +7,27 @@ description: Understand Spree Stores — the top-level tenant boundary that scop
 
 The Store is the top-level tenant in Spree. Every resource — products, orders, channels, markets, taxonomies — belongs to exactly one store. A store owns its [channels](channels.md) (online, POS, wholesale, …), its [markets](markets.md) (region/currency/locale), and its [product catalog](products.md).
 
+```mermaid
+erDiagram
+    Store ||--o{ Channel : "sells through"
+    Store ||--o{ Market : "trades in"
+    Store ||--o{ Product : "catalogs"
+    Store ||--o{ Order : "records"
+    Store ||--o{ PaymentMethod : "accepts"
+    Store ||--o{ StockLocation : "ships from"
+    Store ||--o{ Policy : "publishes"
+    Store ||--o{ Seller : "hosts"
+
+    Store {
+        string name
+        string code
+        string url
+        string default_currency
+        string default_locale
+        boolean default
+    }
+```
+
 ## Store Attributes
 
 | Attribute | Description |

package/dist/developer/core-concepts/taxes.md

@@ -36,6 +36,7 @@ Every product carries one. If you don't choose, the default is used.
 | `is_default` | Used by products that don't pick one | `true` |
 | `tax_code` | The code your tax service knows it by | `1257L` |
 
+
 ```typescript Admin SDK
 const reduced = await adminClient.taxCategories.create({
   name: 'Reduced rate',
@@ -43,6 +44,14 @@ const reduced = await adminClient.taxCategories.create({
 })
 ```
 
+```bash cURL
+curl -X POST 'https://api.mystore.com/api/v3/admin/tax_categories' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{ "name": "Reduced rate", "tax_code": "1257L" }'
+```
+
+
 `tax_code` matters once you connect an external service — it is how you tell that service what kind of thing this is, in the vocabulary it already uses.
 
 ## Tax rates
@@ -57,6 +66,7 @@ A tax rate is the number itself, plus where it applies and whether it's already
 | `country_code` / `state_code` | Where it applies | `DE`, or `US` + `CA` |
 | `tax_category` | What it applies to | `Standard` |
 
+
 ```typescript Admin SDK
 const { data: rates } = await adminClient.taxRates.list()
 
@@ -69,6 +79,25 @@ await adminClient.taxRates.create({
 })
 ```
 
+```bash cURL
+# List tax rates
+curl 'https://api.mystore.com/api/v3/admin/tax_rates' \
+  -H 'X-Spree-API-Key: sk_xxx'
+
+# Create one
+curl -X POST 'https://api.mystore.com/api/v3/admin/tax_rates' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{
+    "name": "VAT 20%",
+    "amount": "0.2",
+    "included_in_price": true,
+    "country_code": "GB",
+    "tax_category_id": "taxcat_xxx"
+  }'
+```
+
+
 Rates name their country and state by **ISO code**, not by an ID — `DE`, `US` + `CA`. There's no separate region record to create first.
 
 ## Included or added on
@@ -120,10 +149,17 @@ Whatever works out the tax, the record is the same: a tax line per charge, sayin
 | `amount` / `display_amount` | The tax charged |
 | `line_item_id` / `fulfillment_id` / `fee_id` | What was taxed — exactly one is set |
 
+
 ```typescript Admin SDK
 const { data: taxLines } = await adminClient.orders.taxLines.list('or_xxx')
 ```
 
+```bash cURL
+curl 'https://api.mystore.com/api/v3/admin/orders/or_xxx/tax_lines' \
+  -H 'X-Spree-API-Key: sk_xxx'
+```
+
+
 Tax lines attach to a line item, a [fulfillment](fulfillments.md), or a [fee](fees.md) — so tax on goods and tax on delivery stay separately visible, which is what a tax return needs.
 
 Each line also keeps its own copy of the rate and label. If someone edits that tax rate next year, the order still says what the customer was actually charged.
@@ -153,10 +189,17 @@ Spree's built-in rate tables are fine when the rules are simple — one country,
 
 For those, connect a real tax service. **The provider is chosen per [Market](markets.md)**, which means one store can use its own rates in a simple market and an external service in a complicated one.
 
+
 ```typescript Admin SDK
 const { data: providers } = await adminClient.taxProviders.list()
 ```
 
+```bash cURL
+curl 'https://api.mystore.com/api/v3/admin/tax_providers' \
+  -H 'X-Spree-API-Key: sk_xxx'
+```
+
+
 A provider declares up front what it cannot do — no US local tax, no reverse charge — so the dashboard can warn a merchant who pairs it with a market that needs it, rather than quietly under-collecting.
 
 Whichever provider is in use, the result is the same: tax lines on the order, in the same shape. Your storefront code doesn't change.

package/dist/developer/core-concepts/translations.md

@@ -87,6 +87,7 @@ Merchants translate in the dashboard, switching locale on the record they're edi
 
 Translations can also be written through the Admin API, which is what you'd use to sync from an external translation service:
 
+
 ```typescript Admin SDK
 await adminClient.products.update('prod_xxx', {
   translations: {
@@ -99,6 +100,14 @@ await adminClient.products.update('prod_xxx', {
 const { data: resources } = await adminClient.translatableResources.list()
 ```
 
+```bash cURL
+curl -X PATCH 'https://api.mystore.com/api/v3/admin/products/prod_xxx' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{ "translations": { "de": { "name": "Baumwolltasche" } } }'
+```
+
+
 Asking the API which resources are translatable means a translation tool doesn't need a hardcoded list that goes stale.
 
 ## Translating the interface

package/dist/developer/core-concepts/webhooks.md

@@ -83,6 +83,17 @@ spree api post /webhook_endpoints -d '{
 }'
 ```
 
+```bash cURL
+curl -X POST 'https://api.mystore.com/api/v3/admin/webhook_endpoints' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{
+    "url": "https://example.com/webhooks/spree",
+    "subscriptions": ["order.*", "product.created"],
+    "active": true
+  }'
+```
+
 
 > **WARNING:** The `secret_key` is returned **only once**, in the create response. Save it immediately — it can't be retrieved later and is required to verify webhook signatures.
 
@@ -113,6 +124,13 @@ spree api patch /webhook_endpoints/whe_xxx \
   -d '{"subscriptions": ["order.placed", "order.canceled"]}'
 ```
 
+```bash cURL
+curl -X PATCH 'https://api.mystore.com/api/v3/admin/webhook_endpoints/whe_xxx' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{ "subscriptions": ["order.placed", "order.canceled"] }'
+```
+
 
 The `subscriptions` array accepts exact event names and wildcard patterns:
 
@@ -128,7 +146,7 @@ The `subscriptions` array accepts exact event names and wildcard patterns:
 
 Each webhook delivery sends a JSON payload with the following structure. The `data` object uses the same [Store API V3 serializers](../../api-reference/introduction.md) as the REST API, so webhook payloads and API responses share the same schema:
 
-```json
+```json Payload
 {
   "id": "550e8400-e29b-41d4-a716-446655440000",
   "name": "order.placed",
@@ -188,7 +206,7 @@ The [Spree Storefront](https://github.com/spree/storefront) includes a ready-mad
 
 Use `@spree/sdk/webhooks` for framework-agnostic verification:
 
-```typescript
+```typescript Store SDK
 import { verifyWebhookSignature } from '@spree/sdk/webhooks'
 import type { WebhookEvent } from '@spree/sdk/webhooks'
 import type { Order } from '@spree/sdk'
@@ -211,7 +229,7 @@ app.post('/webhooks/spree', async (req, res) => {
 
 #### Ruby
 
-```ruby
+```ruby server/app/controllers/webhooks_controller.rb
 class WebhooksController < ApplicationController
   skip_before_action :verify_authenticity_token
 
@@ -272,6 +290,14 @@ spree api get /webhook_endpoints/whe_xxx/deliveries -q event_name_eq=order.place
 spree api post /webhook_endpoints/whe_xxx/deliveries/whd_xxx/redeliver
 ```
 
+```bash cURL
+curl 'https://api.mystore.com/api/v3/admin/webhook_endpoints/whe_xxx/deliveries?q[event_name_eq]=order.placed' \
+  -H 'X-Spree-API-Key: sk_xxx'
+
+curl -X POST 'https://api.mystore.com/api/v3/admin/webhook_endpoints/whe_xxx/deliveries/whd_xxx/redeliver' \
+  -H 'X-Spree-API-Key: sk_xxx'
+```
+
 
 ### Delivery Attributes
 
@@ -339,6 +365,17 @@ spree api post /webhook_endpoints -d '{
 spree api post /webhook_endpoints/whe_xxx/send_test
 ```
 
+```bash cURL
+curl -X POST 'https://api.mystore.com/api/v3/admin/webhook_endpoints' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{
+    "url": "https://your-ngrok-url.ngrok.io/webhooks",
+    "subscriptions": ["order.*"],
+    "active": true
+  }'
+```
+
 
 `send_test` delivers a synthetic `webhook.test` event so you can verify the endpoint is reachable and your signature-verification code works, without having to trigger a real order.
 
@@ -386,6 +423,11 @@ const failed = deliveries[0]
 spree api get /webhook_endpoints/whe_xxx/deliveries -q success_eq=false
 ```
 
+```bash cURL
+curl 'https://api.mystore.com/api/v3/admin/webhook_endpoints/whe_xxx/deliveries?q[success_eq]=false' \
+  -H 'X-Spree-API-Key: sk_xxx'
+```
+
 
 ## Related Documentation
 

package/dist/developer/create-spree-app/quickstart.md

@@ -53,14 +53,14 @@ npx create-spree-app@latest my-store --no-storefront --no-sample-data --no-start
 ```text
 my-store/
 ├── docker-compose.yml        # Spree backend (prebuilt image) + Postgres + Meilisearch
-├── docker-compose.dev.yml    # Alternative: build from local backend/
+├── docker-compose.dev.yml    # Alternative: build from local server/
 ├── render.yaml               # Render Blueprint — one Docker service built from this repo
 ├── .env                      # SECRET_KEY_BASE, SPREE_PORT, SPREE_VERSION_TAG, SPREE_SAMPLE_DATA
 ├── .dockerignore             # Keeps the production build context to sources
 ├── .gitignore
 ├── package.json              # Convenience scripts
 ├── README.md
-├── backend/                  # Full Rails app — the Spree API (from spree/spree-starter)
+├── server/                  # Full Rails app — the Spree API (from spree/spree-starter)
 │   ├── Gemfile
 │   ├── Dockerfile            # Also builds the production image (API + dashboard)
 │   ├── config/
@@ -84,18 +84,18 @@ my-store/
 
 ## Customizing the Spree API
 
-The `backend/` directory is the Spree API — a full Rails application with Spree installed (cloned from [spree-starter](https://github.com/spree/spree-starter)) serving the Store and Admin APIs your storefront and dashboard talk to, plus background jobs and transactional emails. By default, the project runs it from a prebuilt Docker image. To switch to building from your local copy:
+The `server/` directory is the Spree API — a full Rails application with Spree installed (cloned from [spree-starter](https://github.com/spree/spree-starter)) serving the Store and Admin APIs your storefront and dashboard talk to, plus background jobs and transactional emails. By default, the project runs it from a prebuilt Docker image. To switch to building from your local copy:
 
 ```bash
 npx spree eject
 ```
 
-This replaces `docker-compose.yml` with a version that builds from `backend/`, rebuilds the image, and restarts services. You can then:
+This replaces `docker-compose.yml` with a version that builds from `server/`, rebuilds the image, and restarts services. You can then:
 
-- **Add gems** to `backend/Gemfile`
-- **Override models** with decorators in `backend/app/models/`
-- **Add controllers** in `backend/app/controllers/`
-- **Configure Spree** in `backend/config/initializers/spree.rb`
+- **Add gems** to `server/Gemfile`
+- **Override models** with decorators in `server/app/models/`
+- **Add controllers** in `server/app/controllers/`
+- **Configure Spree** in `server/config/initializers/spree.rb`
 - **Add migrations** with `spree generate migration AddFooToSpreeBars foo:string` (runs inside the container)
 
 See the [Customization Guide](../customization.md) for more details.
@@ -109,7 +109,7 @@ The project includes [@spree/cli](../cli/quickstart.md) for managing your Spree
 | `spree dev` | Run the app in the foreground — streams logs, Ctrl+C stops it. First run completes setup automatically; co-runs the React Dashboard dev server when `apps/dashboard` exists |
 | `spree stop` | Stop backend services |
 | `spree update` | Pull latest Spree image and restart (runs migrations automatically) |
-| `spree eject` | Switch from prebuilt image to building from `backend/` |
+| `spree eject` | Switch from prebuilt image to building from `server/` |
 | `spree add dashboard` | Add the React Dashboard to an existing project |
 | `spree build --production` | Build the production image — the Spree API plus your dashboard, in one |
 | `spree logs` | View backend logs |
@@ -162,7 +162,7 @@ SPREE_VERSION_TAG=5.4
 
 ## Deployment
 
-The project deploys as **one image**: `backend/Dockerfile` builds the Spree API together with your React Dashboard (when `apps/dashboard` exists), served same-origin at `/dashboard` — no CORS, no cookie configuration, no second service.
+The project deploys as **one image**: `server/Dockerfile` builds the Spree API together with your React Dashboard (when `apps/dashboard` exists), served same-origin at `/dashboard` — no CORS, no cookie configuration, no second service.
 
 - **Render** — the `render.yaml` at the project root is a ready Blueprint: one Docker service built straight from your repo, migrations run on boot.
 - **Anywhere else** — `spree build --production` builds the same image locally; push it to a registry and run it on any Docker host.

package/dist/developer/dashboard/deployment.md

@@ -22,13 +22,13 @@ The official image contains the *stock* dashboard. Once you've customized yours
 spree build --production            # optionally --tag registry/repo:tag
 ```
 
-The Dockerfile normalizes its own build context: built from the project root it detects the layout (`backend/` = the Rails app, `apps/dashboard/` = your dashboard) and builds *your* dashboard into the image — no flags, no named contexts. Without the CLI, the equivalent is:
+The Dockerfile normalizes its own build context: built from the project root it detects the layout (`server/` = the Rails app, `apps/dashboard/` = your dashboard) and builds *your* dashboard into the image — no flags, no named contexts. Without the CLI, the equivalent is:
 
 ```bash
-docker build . -f backend/Dockerfile -t my-shop-spree:latest
+docker build . -f server/Dockerfile -t my-shop-spree:latest
 ```
 
-Inside the dashboard stage the build runs with `VITE_BASE_PATH=/dashboard/` (asset URLs resolve under the mount) and `VITE_SPREE_API_URL` unset (API calls stay origin-relative); the Node toolchain lives only in that throw-away stage. Projects **without** `apps/dashboard/` get the stock dashboard baked instead — and if your `backend/Dockerfile` predates this layout support, the command warns instead of silently shipping the stock dashboard over your customized one (update it from the spree-starter template).
+Inside the dashboard stage the build runs with `VITE_BASE_PATH=/dashboard/` (asset URLs resolve under the mount) and `VITE_SPREE_API_URL` unset (API calls stay origin-relative); the Node toolchain lives only in that throw-away stage. Projects **without** `apps/dashboard/` get the stock dashboard baked instead — and if your `server/Dockerfile` predates this layout support, the command warns instead of silently shipping the stock dashboard over your customized one (update it from the spree-starter template).
 
 ## Static host / CDN — the alternative
 
@@ -53,7 +53,7 @@ The Blueprint that `create-spree-app` places at the project root deploys the bac
 
 ```yaml
 runtime: docker
-dockerfilePath: ./backend/Dockerfile
+dockerfilePath: ./server/Dockerfile
 dockerContext: .
 ```
 

package/dist/developer/dashboard/recipes/attribute-end-to-end.md

@@ -28,7 +28,7 @@ Lead time is a column because its whole point is the query: *"show me everything
 
 ## 1. Backend
 
-Four small pieces — each one unlocks a specific frontend capability. In a host app these live in `backend/` (or `api/`); in a distributed plugin, in the Rails engine half.
+Four small pieces — each one unlocks a specific frontend capability. In a host app these live in `server/` (or `api/`); in a distributed plugin, in the Rails engine half.
 
 **The column** (with an index — you're adding it *because* it will be queried):
 

package/dist/developer/deployment/docker.md

@@ -13,7 +13,7 @@ If you haven't ejected yet, do that first:
 spree eject
 ```
 
-This generates the app source — including its production `Dockerfile` — in `backend/`. Make your customizations, then build:
+This generates the app source — including its production `Dockerfile` — in `server/`. Make your customizations, then build:
 
 ```bash
 spree build --production                                  # → <project>-spree:latest
@@ -23,7 +23,7 @@ spree build --production --tag registry.example.com/my-store:v42
 Or with plain Docker, from the project root:
 
 ```bash
-docker build . -f backend/Dockerfile -t my-store
+docker build . -f server/Dockerfile -t my-store
 ```
 
 Both produce the same image — and it's exactly what Render and Railway build from your repository. Migrations run automatically on boot.