@wix/agent-skills 1.6.0 → 1.7.0

package/skills/wix-app/references/DASHBOARD_PLUGIN.md

@@ -1,20 +1,11 @@
 
 # Wix Dashboard Plugin Builder
 
-Creates dashboard plugin extensions for Wix CLI applications. Dashboard plugins are interactive widgets that embed into predefined **slots** on dashboard pages managed by Wix first-party business apps (Wix Stores, Wix Bookings, Wix Blog, Wix eCommerce, etc.).
+Dashboard plugins are interactive widgets that embed into predefined **slots** on dashboard pages managed by Wix first-party business apps (Wix Stores, Wix Bookings, Wix Blog, Wix eCommerce, etc.). They occupy the full width of their slot and maintain dynamic height based on content.
 
-Dashboard plugins occupy the full width of their slot and maintain dynamic height based on content.
+## Scaffold
 
-
-## Quick Start Checklist
-
-Follow these steps in order when creating a dashboard plugin:
-
-1. [ ] Identify the target slot ID — see [Slots Reference](dashboard-plugin/SLOTS.md)
-2. [ ] Create plugin folder: `src/extensions/dashboard/plugins/<plugin-name>/`
-3. [ ] Create `<plugin-name>.extension.ts` with `extensions.dashboardPlugin()` and unique UUID
-4. [ ] Create `<plugin-name>.tsx` with React component wrapped in `WixDesignSystemProvider`
-5. [ ] Update `src/extensions.ts` to import and use the new extension
+Use `wix generate --params` with `extensionType: DASHBOARD_PLUGIN`. `extendsSlotId` is the back-office extension container component ID from the host Wix app — see [Slots Reference](dashboard-plugin/SLOTS.md). The CLI generates the folder, the React component, the builder file, the UUID, and the `src/extensions.ts` registration.
 
 ## Architecture
 
@@ -23,84 +14,15 @@ Dashboard plugins operate through two mechanisms:
 1. **Visual Integration** — Embedding plugin UI inside a supported dashboard page slot
 2. **Logical Integration** — Implementing communication between the plugin and the host page's data via `observeState()`
 
-## Files and Code Structure
-
-Dashboard plugins live under `src/extensions/dashboard/plugins/`. Each plugin has its own folder.
-
-```
-src/extensions/dashboard/plugins/
-└── <plugin-name>/
-    ├── <plugin-name>.extension.ts   # Builder configuration
-    └── <plugin-name>.tsx            # React component
-```
-
-> **Note:** This is the default folder structure created by the CLI. You can move these files to any location within the `src/` folder and update the references in your `extension.ts` file.
-
-## Plugin Builder Configuration
+## The `extendsSlotId` field
 
-### File: `<plugin-name>.extension.ts`
-
-```typescript
-import { extensions } from "@wix/astro/builders";
-
-export const dashboardpluginMyPlugin = extensions.dashboardPlugin({
-  id: "{{GENERATE_UUID}}",
-  title: "My Dashboard Plugin",
-  extends: "<SLOT_ID>",
-  component: "./extensions/dashboard/plugins/my-plugin/my-plugin.tsx",
-});
-```
-
-**CRITICAL: UUID Generation**
-
-The `id` must be a unique, static UUID v4 string. Generate a fresh UUID for each extension — do NOT use `randomUUID()` or copy UUIDs from examples. Replace `{{GENERATE_UUID}}` with a freshly generated UUID like `"a1b2c3d4-e5f6-7890-abcd-ef1234567890"`.
-
-### Builder Fields
-
-| Field | Type | Description |
-|-------|------|-------------|
-| `id` | string | Unique plugin ID (GUID). Must be unique across all extensions in the project. |
-| `title` | string | Plugin title. Used to refer to the plugin in the project dashboard. |
-| `extends` | string | Slot ID of the dashboard page hosting the plugin. See [Slots Reference](dashboard-plugin/SLOTS.md). |
-| `component` | string | Relative path to the plugin content component (`.tsx` file). |
-
-### The `extends` Field
-
-The `extends` field specifies which dashboard page slot hosts your plugin. Each Wix business app exposes slots on its dashboard pages. You must provide the exact slot ID.
+Specifies which dashboard page slot hosts your plugin. Each Wix business app exposes slots on its dashboard pages. You must provide the exact slot ID.
 
 **Important:** Some slots with the same ID appear on different pages within the dashboard. If you create a plugin for a slot that exists on multiple pages, the plugin is displayed on all of those pages.
 
 For the complete list of available slot IDs, see [Slots Reference](dashboard-plugin/SLOTS.md).
 
-## Plugin Component
-
-### File: `<plugin-name>.tsx`
-
-The plugin component is a React component that renders within the dashboard page slot.
-
-```typescript
-import type { FC } from "react";
-import { WixDesignSystemProvider, Card, Text } from "@wix/design-system";
-import "@wix/design-system/styles.global.css";
-
-const Plugin: FC = () => {
-  return (
-    <WixDesignSystemProvider features={{ newColorsBranding: true }}>
-      <Card>
-        <Card.Header title="My Plugin" />
-        <Card.Divider />
-        <Card.Content size="medium">
-          <Text>Plugin content goes here.</Text>
-        </Card.Content>
-      </Card>
-    </WixDesignSystemProvider>
-  );
-};
-
-export default Plugin;
-```
-
-### Available Resources in Plugin Components
+## Available Resources in Plugin Components
 
 - **React** — Component logic and state management
 - **Wix SDK** — Access Wix business solutions and site data
@@ -152,36 +74,12 @@ const Plugin: FC<Props> = (props) => {
 
 > **Note:** Typed props availability varies by Wix app. Consult the specific app's SDK documentation. Not all slots provide typed parameter interfaces.
 
-## Extension Registration
-
-**Extension registration is MANDATORY and has TWO required steps.**
-
-### Step 1: Create Plugin-Specific Extension File
-
-Each dashboard plugin requires an `<plugin-name>.extension.ts` file in its folder. See [Plugin Builder Configuration](#plugin-builder-configuration) above.
-
-### Step 2: Register in Main Extensions File
-
-**CRITICAL:** After creating the plugin-specific extension file, you MUST read [Extension Registration reference](EXTENSION_REGISTRATION.md) and follow the "App Registration" section to update `src/extensions.ts`.
-
-**Without completing Step 2, the dashboard plugin will not appear on the dashboard page.**
-
 ## Sizing Behavior
 
 - Dashboard plugins take the **full width** of their slot
 - **Height** adjusts dynamically based on content within slot boundaries
 - When using Dashboard SDK or dashboard-react SDK, dimensions change dynamically based on contents
 
-## Troubleshooting
-
-| Symptom | Cause | Fix |
-|---------|-------|-----|
-| Plugin not appearing on dashboard page | Missing registration | Import and `.use()` in `src/extensions.ts` |
-| Plugin not appearing on dashboard page | Wrong slot ID | Verify `extends` field matches a valid slot ID from [Slots Reference](dashboard-plugin/SLOTS.md) |
-
-## Dashboard-Plugin-specific Conventions
-
-- The `extends` field MUST contain a valid slot ID from a Wix business app — do NOT invent slot IDs.
 
 ## Examples
 

package/skills/wix-app/references/DATA_COLLECTION.md

@@ -5,6 +5,11 @@ Creates CMS data collections for Wix CLI apps. The data collections extension al
 
 **Important:** This extension automatically enables the site's code editor, which is required for the Wix Data APIs to work. Without this extension, apps using Data APIs would need the Wix user to manually enable the code editor on their site, which isn't guaranteed. With the data collections extension, your app can reliably use Data APIs to read and write data in the collections.
 
+## Scaffold
+
+Use `wix generate --params` with `extensionType: DATA_COLLECTION`. The only other param is `collectionName` (1-36 chars: letters, numbers, underscores, hyphens) — fields, permissions, displayName overrides, etc. are all edited after scaffolding in the generated file.
+
+The CLI manages a shared aggregator file (`data-collections.extension.ts`) that imports every collection file and registers them in one `extensions.dataCollections({...})` builder. The aggregator and `src/extensions.ts` are updated automatically — don't edit them manually.
 
 ## App Namespace Handling
 
@@ -21,48 +26,31 @@ Creates CMS data collections for Wix CLI apps. The data collections extension al
 
 ### Collection ID Format
 
-- **In extension definition (`idSuffix`):** Use just the suffix, e.g., `"products"`
+- **In extension definition (`idSuffix`):** Use just the suffix, e.g., `"products"`. The CLI uses `collectionName` from the scaffold params as the `idSuffix` for the generated entry.
 - **In API calls:** Use the full scoped ID: `"<app-namespace>/products"` — MUST match `idSuffix` exactly (case-sensitive, no camelCase/PascalCase transformation)
 - **In `referencedCollectionId`:** Use the `idSuffix` only (not the full scoped ID) — the system resolves it automatically
 - Example: If `idSuffix` is `"product-recommendations"`, API calls use `"<app-namespace>/product-recommendations"` NOT `"<app-namespace>/productRecommendations"`
 
+## Collection File Shape
 
-## File Structure
-
-In Wix CLI apps, all CMS collections are defined in a single file:
-
-**File:** `src/extensions/data/extensions.ts`
-
-This file uses the `extensions.genericExtension()` pattern from `@wix/astro/builders` to register all collections:
+The CLI scaffolds `<CollectionName>.ts` as a `satisfies DataCollection` default export. The scaffolded `fields` and `dataPermissions` are placeholders — replace them with your real schema, and set permissions per the [Context-Based Permission Rules](#context-based-permission-rules) before shipping.
 
 ```typescript
-import { extensions } from "@wix/astro/builders";
-
-export const dataExtension = extensions.genericExtension({
-  compId: "{{GENERATE_UUID}}",
-  compName: "data-extension",
-  compType: "DATA_COMPONENT",
-  compData: {
-    dataComponent: {
-      collections: [
-        // All collections defined here
-      ],
-    },
-  },
-});
+import type { DataCollection } from '@wix/astro/builders';
+
+export const collectionIdSuffix = '<CollectionName>';
+
+export default {
+  idSuffix: collectionIdSuffix,
+  displayName: '<CollectionName>',
+  displayField: 'title',            // Field shown when referencing items
+  fields: [ /* field definitions */ ],
+  dataPermissions: { /* itemRead, itemInsert, itemUpdate, itemRemove */ },
+  indexes: [],
+  initialData: [],
+} satisfies DataCollection;
 ```
 
-**CRITICAL:** The `compId` must be a unique, static UUID string. Generate a fresh UUID v4 for each app - do NOT use `randomUUID()` or copy UUIDs from examples. After creating or modifying this file, follow [Extension Registration reference](EXTENSION_REGISTRATION.md) for UUID generation and to register the extension in `src/extensions.ts` (required for collections to work).
-
-**Key points:**
-
-- Single file contains all collections
-- Uses `extensions.genericExtension()` from `@wix/astro/builders`
-- Each collection includes: `idSuffix`, `displayName`, `displayField`, `fields`, `dataPermissions`, and optionally `initialData`
-- `displayField` specifies which field the CMS displays when referencing items in this collection from other collections
-- Collections are generated by merging operations (INSERT, UPDATE, DELETE) with existing collections
-- See [extension template](data-collection/extension-template.ts) for complete structure
-
 ## Field Types
 
 | Type              | Description                      | Use Case               |
@@ -126,27 +114,59 @@ For structured objects, define nested fields inside `objectOptions.fields`:
 
 ## Field Properties
 
-```json
+```ts
 {
-  "key": "email",
-  "displayName": "Email Address",
-  "type": "TEXT",
-  "required": true,
-  "unique": true,
-  "defaultValue": null,
-  "description": "User's primary email"
+  key: 'email',                         // required, lowerCamelCase ASCII
+  type: 'TEXT',                         // required, see Field Types above
+  displayName: 'Email Address',         // optional, CMS label
+  description: "User's primary email",  // optional, help text
+  encrypted: false,                     // optional, encrypt value at rest
+  // arrayOptions / objectOptions / referenceOptions / multiReferenceOptions
+  // only when type is ARRAY / OBJECT / REFERENCE / MULTI_REFERENCE
 }
 ```
 
-| Property       | Description                  |
-| -------------- | ---------------------------- |
-| `key`          | Field identifier (camelCase) |
-| `displayName`  | Label shown in CMS           |
-| `type`         | Field data type              |
-| `required`     | Must have value              |
-| `unique`       | No duplicates allowed        |
-| `defaultValue` | Initial value                |
-| `description`  | Help text                    |
+| Property      | Required | Description                          |
+| ------------- | -------- | ------------------------------------ |
+| `key`         | yes      | Field identifier (lowerCamelCase)    |
+| `type`        | yes      | Field data type (see Field Types)    |
+| `displayName` | no       | Label shown in CMS                   |
+| `description` | no       | Help text                            |
+| `encrypted`   | no       | Encrypt value at rest                |
+
+**There is no field-level `required`, `defaultValue`, or `unique`.** The `DevCenterDataCollectionField` type does not accept them and TypeScript will reject the build. Use these alternatives instead:
+
+- **Required values:** Validate in the dashboard form and/or service-plugin handler before inserting. Do not rely on the collection schema to enforce presence.
+- **Defaults:** Set defaults in the insert path (dashboard handler, service plugin) or via the collection's `initialData` for seeded rows.
+- **Uniqueness:** Declare a unique index in the collection's `indexes` array (see [Indexes](#indexes)). Uniqueness is an index-level concern, not a field-level one.
+
+## Indexes
+
+The `indexes` array on the collection accepts entries shaped like:
+
+```ts
+indexes: [
+  {
+    fields: [{ path: 'email', order: 'ASC' }],  // order is optional: 'ASC' | 'DESC'
+    unique: true,                                // optional, enforces uniqueness across items
+  },
+  {
+    fields: [
+      { path: 'category' },
+      { path: '_createdDate', order: 'DESC' },
+    ],
+  },
+],
+```
+
+| Property        | Required | Description                                            |
+| --------------- | -------- | ------------------------------------------------------ |
+| `fields`        | yes      | One or more `{ path, order? }` entries (composite index when more than one) |
+| `fields[].path` | yes      | Field key to index                                     |
+| `fields[].order`| no       | `'ASC'` (default) or `'DESC'`                          |
+| `unique`        | no       | Enforce uniqueness on the indexed field(s)             |
+
+Leave `indexes: []` when no custom indexing is needed; the `_id` index is created automatically.
 
 ## Naming Conventions
 
@@ -194,21 +214,14 @@ Access levels control who can read, create, update, and delete items in collecti
 | **Backend code (site-side)** | Runs in visitor context | If called from page code or site-side modules, the caller has visitor-level permissions — data must be readable/writable at the appropriate public level. |
 | **Backend code (elevated)** | Runs with `auth.elevate()` from `@wix/essentials` | Can bypass permissions, but the collection still needs correct defaults for any non-elevated callers. |
 
+Use `SITE_MEMBER_AUTHOR` on `itemUpdate` / `itemRemove` when members should only modify their **own** items (e.g., a member can edit only their own reviews).
+
 **How to apply this:**
 
 1. **Identify every place the collection is read or written** — custom element widgets, dashboard pages, embedded scripts, backend APIs.
 2. **Use the least restrictive context as the floor.** If a custom element widget reads the data AND a dashboard page also reads it, `itemRead` must be `ANYONE` (because the widget is public).
 3. **Apply per-operation.** A collection can have `itemRead: ANYONE` (widget displays it) but `itemInsert: CMS_EDITOR` (only dashboard users add items). Each operation is independent.
 
-**Examples by blueprint type:**
-
-- **Dashboard manages data, custom element widget displays it:** `itemRead: ANYONE`, `itemInsert: CMS_EDITOR`, `itemUpdate: CMS_EDITOR`, `itemRemove: CMS_EDITOR`
-- **Custom element widget collects user submissions (e.g., reviews), dashboard moderates:** `itemRead: ANYONE`, `itemInsert: ANYONE`, `itemUpdate: CMS_EDITOR`, `itemRemove: CMS_EDITOR`
-- **Members-only widget reads data, members can submit:** `itemRead: SITE_MEMBER`, `itemInsert: SITE_MEMBER`, `itemUpdate: SITE_MEMBER_AUTHOR`, `itemRemove: CMS_EDITOR`
-- **Dashboard-only (no public surface):** `itemRead: CMS_EDITOR`, `itemInsert: CMS_EDITOR`, `itemUpdate: CMS_EDITOR`, `itemRemove: CMS_EDITOR`
-
-**Anti-pattern:** Setting `itemRead: PRIVILEGED` on a collection that a custom element widget queries — the widget will return empty results for all visitors because they lack privileged access.
-
 ## Relationships
 
 **One-to-One / Many-to-One (REFERENCE):**
@@ -244,40 +257,6 @@ Access levels control who can read, create, update, and delete items in collecti
 - **NEVER use REFERENCE fields to link to Wix business entities** (Products, Orders, Contacts, Members, etc.)
 - Use Wix SDK APIs to access Wix business entities instead
 
-## Collection Operations
-
-Collections support three operation types for modifying collections:
-
-### INSERT
-
-Creates a new collection or replaces an existing one with the same `idSuffix`.
-
-**Use when:** Creating a new collection or completely replacing an existing collection.
-
-### UPDATE
-
-Modifies an existing collection by merging new data with existing fields.
-
-**Use when:** Adding fields, updating permissions, or modifying collection properties.
-
-**Behavior:**
-
-- If collection exists: Merges new data with existing collection
-- If collection doesn't exist: Treats update as insert (creates new collection)
-
-### DELETE
-
-Removes a collection from the app.
-
-**Use when:** Removing a collection that is no longer needed.
-
-**Behavior:**
-
-- Removes the collection from `src/extensions/data/extensions.ts`
-- If all collections are deleted, the entire file is deleted
-
-**Merge logic:** Operations are applied using a Map keyed by `idSuffix`. Existing collections are loaded into the Map first, then each operation modifies it: INSERT sets/replaces, UPDATE merges with existing (or creates if missing), DELETE removes. The final Map values become the output collections.
-
 ## App Version Updates
 
 Changes to your data collections extension require releasing a new major version of your app. When a user updates to the new major version, their collections are updated as follows:
@@ -294,73 +273,18 @@ Changes to your data collections extension require releasing a new major version
 
 ## Wix CLI-Specific Constraints
 
-### Embedded Script Parameters vs Collections
-
-**CRITICAL: NEVER create CMS collections to store configuration for embedded scripts.**
-
-All embedded script configuration must go through embedded script parameters (`embeddedScriptParameters`), not CMS collections.
-
-**DO NOT create collections for:**
-
-- Colors, messages, headlines, text content
-- Coupon codes, display settings
-- UI customization (positions, sizes, styles)
-- Timing settings, feature toggles
-- Display frequencies, thresholds
-- Minimums/maximums
-- **ANY configuration that controls how an embedded script behaves or appears**
-
-**Examples of configuration (use parameters, NOT collections):**
-
-- Popup headline → embedded script parameter
-- Coupon code → embedded script parameter
-- Background color → embedded script parameter
-- Display position → embedded script parameter
-- Show/hide toggles → embedded script parameter
-
-**CMS collections should ONLY be created for:**
-
-- Business data (products, orders, inventory, etc.)
-- User-generated content (reviews, comments, submissions)
-- Event logs (if explicitly requested for analytics/tracking)
-- Multi-record relational data that is NOT configuration
+### When NOT to use a Collection
 
-**Decision Rule:**
+Collections are for **data**, not configuration:
 
-- If it controls HOW the embedded script works or looks → it's configuration → use embedded script parameters
-- If it's business data or user-generated content → it's data → use CMS collections
+- **Embedded script settings** → use `embeddedScriptParameters` instead.
+- **Custom element widget settings** → use the widget's `panel.tsx` (settings panel) instead. A widget-only blueprint usually needs **zero** collections.
+- **Single-value config** (theme, mode, threshold) → put it in the host extension's settings, not a one-field collection.
+- **Computed / aggregated values** (averages, counts) → calculate dynamically, don't store.
 
-### Custom Element Widget Settings vs Collections
+Common values that do **not** belong in a collection: colors, fonts, sizes, headlines, labels, messages, dates/times, coupon codes, display positions, feature toggles, frequencies, numeric thresholds.
 
-**CRITICAL: custom element widgets have a built-in settings panel (`panel.tsx`) that handles ALL widget configuration.**
-
-**For CUSTOM_ELEMENT_WIDGET-only blueprints (no DASHBOARD_PAGE or other extensions):**
-
-- **ALWAYS return `collections: []` (empty array)**
-- The widget panel handles everything
-- **NEVER create collections to store widget configuration data**
-
-**Configuration handled by widget panel (NOT collections):**
-
-- Target date/time for countdown → widget panel
-- Display colors, fonts, sizes → widget panel
-- Headlines, labels, messages → widget panel
-- Feature toggles, show/hide options → widget panel
-- Numeric settings (delays, intervals, thresholds) → widget panel
-
-**Only create collections for CUSTOM_ELEMENT_WIDGET when ALL of these conditions are met:**
-
-1. The blueprint ALSO includes a DASHBOARD_PAGE extension that needs to manage data the widget displays
-2. OR the widget explicitly needs to display MULTIPLE records of user-generated/business data (not configuration)
-3. AND the data is NOT configuration (dates, colors, settings, display options are ALWAYS configuration)
-
-### Anti-Patterns
-
-**Don't create aggregated fields.** If you have individual `rating` fields, calculate averages dynamically — don't store computed values like `averageRating`.
-
-**Don't duplicate configuration.** If embedded script parameters already hold `{ headline, color }`, don't also create a CMS collection with the same data.
-
-**Don't create single-value collections.** A collection with one field like `{ theme: "dark" }` should be an embedded script parameter or widget setting instead.
+Collections are for: business data (products, orders, inventory), user-generated content (reviews, comments, submissions), event logs, and multi-record relational data.
 
 ### Initial Data Rules
 
@@ -378,62 +302,54 @@ Each item in `initialData` must match the collection schema exactly:
 
 **Request:** "Create a collection for handling fees with example data"
 
-**Generated file:** `src/extensions/data/extensions.ts`
+Scaffold:
+
+```bash
+wix generate --params '{"extensionType":"DATA_COLLECTION","collectionName":"additional-fees"}'
+```
+
+Edit the generated `src/extensions/backend/data-collections/additional-fees.ts`:
 
 ```typescript
-import { extensions } from "@wix/astro/builders";
-
-export const dataExtension = extensions.genericExtension({
-  compId: "{{GENERATE_UUID}}",
-  compName: "data-extension",
-  compType: "DATA_COMPONENT",
-  compData: {
-    dataComponent: {
-      collections: [
-        {
-          schemaUrl: "https://www.wix.com/",
-          idSuffix: "additional-fees",
-          displayName: "Additional Fees",
-          displayField: "title",
-          fields: [
-            { key: "title", displayName: "Fee Title", type: "TEXT" },
-            { key: "amount", displayName: "Fee Amount", type: "NUMBER" },
-          ],
-          dataPermissions: {
-            itemRead: "ANYONE",
-            itemInsert: "PRIVILEGED",
-            itemUpdate: "PRIVILEGED",
-            itemRemove: "PRIVILEGED",
-          },
-          initialData: [
-            { title: "Handling Fee", amount: 5 },
-            { title: "Gift Wrapping", amount: 3.5 },
-          ],
-        },
-      ],
-    },
+import type { DataCollection } from '@wix/astro/builders';
+
+export const collectionIdSuffix = 'additional-fees';
+
+export default {
+  idSuffix: collectionIdSuffix,
+  displayName: 'Additional Fees',
+  displayField: 'title',
+  fields: [
+    { key: 'title', displayName: 'Fee Title', type: 'TEXT' },
+    { key: 'amount', displayName: 'Fee Amount', type: 'NUMBER' },
+  ],
+  dataPermissions: {
+    itemRead: 'ANYONE',
+    itemInsert: 'PRIVILEGED',
+    itemUpdate: 'PRIVILEGED',
+    itemRemove: 'PRIVILEGED',
   },
-});
+  indexes: [],
+  initialData: [
+    { title: 'Handling Fee', amount: 5 },
+    { title: 'Gift Wrapping', amount: 3.5 },
+  ],
+} satisfies DataCollection;
 ```
 
 ### Collection with Reference Relationship
 
 **Request:** "Create collections for products and categories with relationships"
 
-**Collections:**
-
-- `categories` - Category definitions
-- `products` - Products that reference categories
-
-Both collections are defined in the same `src/extensions/data/extensions.ts` file, with the `products` collection using a REFERENCE field to link to `categories`. See the [extension template](data-collection/extension-template.ts) for a complete multi-collection example.
+Run `wix generate --params` twice — once with `collectionName: "categories"` and once with `collectionName: "products"`. Then edit `src/extensions/backend/data-collections/products.ts` to add a `REFERENCE` field pointing at `categories` (`referenceOptions: { referencedCollectionId: "categories" }`). The aggregator `data-collections.extension.ts` is updated by the CLI automatically.
 
 ## Common Patterns
 
-**Soft Delete:** Add `isDeleted` (BOOLEAN, default: false)
+**Soft Delete:** Add `isDeleted` (BOOLEAN), defaulted at the insert path
 
 **Status/Workflow:** Add `status` (TEXT) with values like draft/pending/published
 
-**URL Slug:** Add `slug` (TEXT, unique) for SEO-friendly URLs
+**URL Slug:** Add `slug` (TEXT) plus a `{ fields: [{ path: 'slug' }], unique: true }` entry in `indexes` for SEO-friendly URLs
 
 **Owner Tracking:** Add `createdBy` (REFERENCE → custom collection, not Members)
 
@@ -442,7 +358,6 @@ Both collections are defined in the same `src/extensions/data/extensions.ts` fil
 ## Reference Documentation
 
 - [Wix Data SDK Reference](data-collection/WIX_DATA.md) - Complete reference for reading and writing data using `@wix/data`
-- [extension-template.ts](data-collection/extension-template.ts) - Template for `src/extensions/data/extensions.ts`
 
 ### Public Documentation