@rebasepro/agent-skills 0.8.0 → 0.9.0

package/skills/rebase-security/SKILL.md

@@ -17,7 +17,7 @@ Rebase implements a **multi-layered, defense-in-depth** security architecture. S
 - [Layer 2: API Key Permission Guard](#layer-2-api-key-permission-guard)
 - [Layer 3: DataHooks (API Boundary)](#layer-3-datahooks-api-boundary)
 - [Layer 4: Scoped DataDriver](#layer-4-scoped-datadriver)
-- [Layer 5: Entity Callbacks](#layer-5-entity-callbacks)
+- [Layer 5: Collection Callbacks](#layer-5-collection-callbacks)
 - [Fail-Closed Design](#fail-closed-design)
 - [Securing Without Database RLS](#securing-without-database-rls)
 - [Common Security Patterns](#common-security-patterns)
@@ -61,7 +61,7 @@ Every request — REST, GraphQL, and WebSocket — passes through **5 security l
 └──────────────┬───────────────────────────────────────┘
                │
 ┌──────────────▼───────────────────────────────────────┐
-│  Layer 5: Entity Callbacks (Per-Collection)          │
+│  Layer 5: Collection Callbacks (Per-Collection)      │
 │  beforeSave / afterRead / beforeDelete               │
 │  Per-collection hooks inside the DataDriver          │
 └──────────────────────────────────────────────────────┘
@@ -77,12 +77,12 @@ All three protocols share the same security middleware stack:
 
 ### REST
 ```
-HTTP Request → Auth Middleware → API Key Guard → DataHooks → Scoped Driver → Entity Callbacks → Response
+HTTP Request → Auth Middleware → API Key Guard → DataHooks → Scoped Driver → Collection Callbacks → Response
 ```
 
 ### GraphQL
 ```
-GraphQL Request → Auth Middleware → API Key Guard → Scoped Driver → Entity Callbacks → Response
+GraphQL Request → Auth Middleware → API Key Guard → Scoped Driver → Collection Callbacks → Response
 ```
 GraphQL shares the same Hono middleware chain as REST. Resolvers extract the scoped driver from context and throw if unavailable.
 
@@ -136,13 +136,13 @@ export async function scopeDataDriver(
 | Anonymous (`requireAuth: false`) | `"anon"` | `["anon"]` | RLS with anonymous identity |
 | No token + `requireAuth: true` | — | — | **Rejected (401)** |
 
-> **IMPORTANT FOR AGENTS:** These are **reserved system identity values** that the middleware injects automatically. When writing DataHooks or Entity Callbacks, developers should use these identities to gate behavior:
+> **IMPORTANT FOR AGENTS:** These are **reserved system identity values** that the middleware injects automatically. When writing DataHooks or Collection Callbacks, developers should use these identities to gate behavior:
 > - `uid: "service"` + `roles: ["admin"]` — Server-side `rebase.data` calls (cron jobs, custom functions using `rebase.data`, webhooks). These go through the full middleware pipeline authenticated with the service key.
-> - `uid: "anon"` + `roles: ["anon"]` — Unauthenticated requests when `requireAuth: false`. **Note:** for anonymous REST requests, `context.user` in Entity Callbacks may be `undefined`; only the DataDriver is scoped with the anon identity. For WebSocket connections, a full `User` object with `uid: "anon"` is provided.
+> - `uid: "anon"` + `roles: ["anon"]` — Unauthenticated requests when `requireAuth: false`. **Note:** for anonymous REST requests, `context.user` in Collection Callbacks may be `undefined`; only the DataDriver is scoped with the anon identity. For WebSocket connections, a full `User` object with `uid: "anon"` is provided.
 > - `uid: "api-key:{id}"` + `roles: ["service"]` (or `["admin", "service"]`) — API key requests.
 > - Real user IDs and roles for JWT-authenticated requests.
 >
-> **Key insight:** `rebase.data` (the server-side singleton) is NOT a raw admin driver — it round-trips through the REST API using the service key, so all DataHooks and Entity Callbacks fire with `uid: "service"`, `roles: ["admin"]`. This means callbacks can distinguish server-internal reads from end-user reads by checking `context.user?.roles?.includes("admin")`.
+> **Key insight:** `rebase.data` (the server-side singleton) is NOT a raw admin driver — it round-trips through the REST API using the service key, so all DataHooks and Collection Callbacks fire with `uid: "service"`, `roles: ["admin"]`. This means callbacks can distinguish server-internal reads from end-user reads by checking `context.user?.roles?.includes("admin")`.
 
 ---
 
@@ -247,9 +247,9 @@ interface BackendHookContext {
 
 ### Execution Order
 
-DataHooks run **after** per-collection `EntityCallbacks` (which execute inside the DataDriver, closer to the database) and **before** the API response is sent to the client. This gives you two opportunities to enforce security:
+DataHooks run **after** per-collection `CollectionCallbacks` (which execute inside the DataDriver, closer to the database) and **before** the API response is sent to the client. This gives you two opportunities to enforce security:
 
-1. **EntityCallbacks** — per-collection, inside the driver
+1. **CollectionCallbacks** — per-collection, inside the driver
 2. **DataHooks** — cross-cutting, at the API boundary
 
 ---
@@ -271,12 +271,12 @@ PostgreSQL RLS policies use `auth.uid()`, `auth.roles()`, and `auth.jwt()` to re
 
 ---
 
-## Layer 5: Entity Callbacks
+## Layer 5: Collection Callbacks
 
-Entity callbacks are per-collection lifecycle hooks that run **inside** the DataDriver, close to the database. They provide collection-specific security enforcement:
+Collection callbacks are per-collection lifecycle hooks that run **inside** the DataDriver, close to the database. They provide collection-specific security enforcement:
 
 ```typescript
-const ordersCollection: PostgresCollection = {
+const ordersCollection: PostgresCollectionConfig = {
     name: "Orders",
     slug: "orders",
     table: "orders",
@@ -289,9 +289,9 @@ const ordersCollection: PostgresCollection = {
             }
             return values;
         },
-        beforeDelete: async ({ entity, context }) => {
+        beforeDelete: async ({ row, context }) => {
             // Prevent deletion of fulfilled orders
-            if (entity.values.status === "fulfilled") {
+            if (row.status === "fulfilled") {
                 throw new Error("Cannot delete fulfilled orders");
             }
         },
@@ -300,7 +300,7 @@ const ordersCollection: PostgresCollection = {
 };
 ```
 
-For full documentation on entity callbacks, see the `rebase-collections` skill.
+For full documentation on collection callbacks, see the `rebase-collections` skill.
 
 ---
 
@@ -327,7 +327,7 @@ Rebase follows a **fail-closed** security model throughout the stack:
 
 ## Securing Without Database RLS
 
-If you cannot modify database-level RLS policies — or your database doesn't support them — use **DataHooks** and **Entity Callbacks** to enforce security entirely at the application level.
+If you cannot modify database-level RLS policies — or your database doesn't support them — use **DataHooks** and **Collection Callbacks** to enforce security entirely at the application level.
 
 ### Strategy: DataHooks as Your Security Layer
 
@@ -384,7 +384,7 @@ const hooks: BackendHooks = {
 
             if (!user.roles.includes("admin")) {
                 // For non-admins, you may need to fetch the entity first
-                // to verify ownership. Use Entity Callbacks for this pattern
+                // to verify ownership. Use Collection Callbacks for this pattern
                 // since they receive the full entity.
                 throw ApiError.forbidden("Only admins can delete records");
             }
@@ -393,40 +393,40 @@ const hooks: BackendHooks = {
 };
 ```
 
-### Strategy: Entity Callbacks for Ownership Checks
+### Strategy: Collection Callbacks for Ownership Checks
 
-Entity Callbacks receive the full entity data, making them ideal for ownership verification on deletes and updates:
+Collection Callbacks receive the full entity data, making them ideal for ownership verification on deletes and updates:
 
 ```typescript
-const ordersCollection: PostgresCollection = {
+const ordersCollection: PostgresCollectionConfig = {
     name: "Orders",
     slug: "orders",
     table: "orders",
     callbacks: {
-        beforeSave: async ({ values, entityId, context, previousValues }) => {
+        beforeSave: async ({ values, id, context, previousValues }) => {
             const user = context.user;
             if (!user) throw new Error("Unauthorized");
 
             // On update, verify the current user owns this order
-            if (entityId && previousValues) {
+            if (id && previousValues) {
                 if (previousValues.user_id !== user.uid && !user.roles?.includes("admin")) {
                     throw new Error("You can only edit your own orders");
                 }
             }
 
             // On create, stamp ownership
-            if (!entityId) {
+            if (!id) {
                 values.user_id = user.uid;
             }
 
             return values;
         },
 
-        beforeDelete: async ({ entity, context }) => {
+        beforeDelete: async ({ row, context }) => {
             const user = context.user;
             if (!user) throw new Error("Unauthorized");
 
-            if (entity.values.user_id !== user.uid && !user.roles?.includes("admin")) {
+            if (row.user_id !== user.uid && !user.roles?.includes("admin")) {
                 throw new Error("You can only delete your own orders");
             }
         },
@@ -437,15 +437,15 @@ const ordersCollection: PostgresCollection = {
 
 ### Combining Both Layers
 
-For maximum security, use both DataHooks and Entity Callbacks together:
+For maximum security, use both DataHooks and Collection Callbacks together:
 
 | Concern | Best Layer | Why |
 |---|---|---|
 | Cross-cutting read filtering | DataHooks `afterRead` | Applies to ALL collections in one place |
 | Cross-cutting write validation | DataHooks `beforeSave` | Single enforcement point for all writes |
 | PII masking / field redaction | DataHooks `afterRead` | Cross-cutting, role-based |
-| Ownership checks on writes/deletes | Entity Callbacks | Has access to the full entity for comparison |
-| Business rule validation | Entity Callbacks | Collection-specific, typed values |
+| Ownership checks on writes/deletes | Collection Callbacks | Has access to the full entity for comparison |
+| Business rule validation | Collection Callbacks | Collection-specific, typed values |
 | Audit logging | DataHooks `afterSave` / `afterDelete` | Cross-cutting, fire-and-forget |
 
 ---
@@ -503,13 +503,44 @@ const hooks: BackendHooks = {
         },
 
         beforeDelete(slug, entityId, ctx) {
-            // Tenant isolation on deletes is best handled in Entity Callbacks
+            // Tenant isolation on deletes is best handled in Collection Callbacks
             // where you have access to the entity's tenant_id
         },
     },
 };
 ```
 
+### Membership-Scoped Access (RLS, no N+1)
+
+When membership lives in a **join collection** (e.g. `team_members`), prefer the
+first-class `policy.existsIn` predicate over a per-row `afterRead` lookup. It is
+enforced by Postgres RLS in a single correlated `EXISTS` subquery — no N+1, and
+it cannot be bypassed by a client that skips the SDK.
+
+```typescript
+import { policy } from "@rebasepro/types";
+
+// config/collections/documents.ts — only members of the doc's team can read it:
+securityRules: [
+    {
+        operation: "select",
+        condition: policy.existsIn({
+            collection: "team_members",
+            where: policy.and(
+                policy.compare(policy.field("team_id"), "eq", policy.outerField("team_id")),
+                policy.compare(policy.field("user_id"), "eq", policy.authUid()),
+            ),
+        }),
+    },
+]
+```
+
+Inside `where`: `policy.field(...)` = a column of the joined collection
+(`team_members`); `policy.outerField(...)` = a column of the row being checked
+(`documents`); `policy.authUid()` = the caller. Reach for the `afterRead`
+approach above only when access depends on data RLS can't see (e.g. an external
+service). Run `rebase db push` after editing the collection to apply the policy.
+
 ### Role-Based Collection Access
 
 ```typescript
@@ -593,7 +624,7 @@ Use this checklist when setting up security for a Rebase project:
 - [ ] **Default role is NOT admin** — `auth.defaultRole` must never be `"admin"` (startup error)
 - [ ] **DataHooks enforce access control** — If not using database RLS, `hooks.data` enforces read/write/delete permissions
 - [ ] **Sensitive fields are masked** — `afterRead` masks PII for non-admin users
-- [ ] **Ownership is enforced** — `beforeSave` stamps `user_id` on creation; Entity Callbacks verify ownership on update/delete
+- [ ] **Ownership is enforced** — `beforeSave` stamps `user_id` on creation; Collection Callbacks verify ownership on update/delete
 - [ ] **API keys are scoped** — API keys have minimal permissions (specific collections + operations)
 - [ ] **API keys are never client-side** — API keys bypass RLS; only use server-side
 - [ ] **CORS is configured** — Restrict origins in production
@@ -611,5 +642,5 @@ Use this checklist when setting up security for a Rebase project:
 - **Backend Hooks Types**: `packages/types/src/types/backend_hooks.ts` — `DataHooks`, `BackendHooks` interfaces
 - **Backend Init**: `packages/server-core/src/init.ts` — `hooks` config property
 - **Reserved Identity Values**: See Identity Types table above — `"service"`, `"anon"`, `"api-key:{id}"` are system-assigned identities in `context.user` / `ctx.requestUser`
-- **Entity Callbacks**: See `rebase-collections` skill → Entity Callbacks section
+- **Collection Callbacks**: See `rebase-collections` skill → Collection Callbacks section
 - **Auth Configuration**: See `rebase-auth` skill → Server-Side Configuration section

package/skills/rebase-storage/SKILL.md

@@ -672,12 +672,15 @@ const config = await client.storage.getSignedUrl(
 if (config.fileNotFound) {
     console.log("File does not exist");
 } else {
-    console.log(config.url);       // Full URL with auth token appended
+    console.log(config.url);       // Private: short-lived scoped token appended. Public: clean permanent URL.
     console.log(config.metadata);  // { bucket, fullPath, name, size, contentType, customMetadata }
 }
 ```
 
-The URL is constructed as `{baseUrl}/api/storage/file/{path}?token={accessToken}`.
+**URL model — never contains the access token:**
+
+- **Private files** → `{baseUrl}/api/storage/file/{path}?token={scopedDownloadToken}`. The token is a **short-lived, path-scoped** download token (default 5 min), signed by the server and valid only for that object — never the caller's full access JWT. Because it expires, **do not persist a private URL**: store the file **path** and call `getSignedUrl()` again at render time.
+- **Public files** → `{baseUrl}/api/storage/file/{path}` with **no token**. A file is public when it lives under the `public/` prefix — set `storage: { public: true }` on the property, or pass `public: true` to `putObject`. Public URLs are **stable, permanent, and CDN-cacheable**, so they are safe to store in a database and hotlink. For public paths, `getSignedUrl()` returns the URL immediately with no server round-trip.
 
 Protocol prefixes (`local://`, `s3://`) are automatically stripped from the key.
 
@@ -733,9 +736,9 @@ console.log(result.nextPageToken); // for next page, or undefined
 Define file upload fields in your collections using the `storage` option on string properties:
 
 ```typescript
-import { PostgresCollection } from "@rebasepro/types";
+import { PostgresCollectionConfig } from "@rebasepro/types";
 
-const productsCollection: PostgresCollection = {
+const productsCollection: PostgresCollectionConfig = {
     name: "Products",
     table: "products",
     properties: {
@@ -775,6 +778,7 @@ The `storageSource` field maps to a named backend registered in the `StorageRegi
 | `storagePath` | `string` | Path template for uploaded files. Supports `{entityId}` placeholder |
 | `acceptedFiles` | `string[]` | Accepted MIME types or globs (e.g., `["image/*"]`) |
 | `maxSize` | `number` | Maximum file size in bytes |
+| `public` | `boolean` | Store files under the `public/` prefix and serve them via stable, token-less, permanent, CDN-cacheable URLs (safe to persist/hotlink). Defaults to `false` (private, short-lived signed URLs). |
 
 ## Frontend Storage Sources
 

package/skills/rebase-studio/SKILL.md

@@ -256,8 +256,8 @@ These components can be overridden globally on `<Rebase>` (which acts as a fallb
 `<RebaseCMS>` accepts the full `RebaseCMSConfig`:
 
 ```typescript
-interface RebaseCMSConfig<EC extends EntityCollection = EntityCollection> {
-    collections?: EC[] | EntityCollectionsBuilder<EC>;
+interface RebaseCMSConfig<EC extends CollectionConfig = CollectionConfig> {
+    collections?: EC[] | CollectionConfigsBuilder<EC>;
     views?: AppView[] | AppViewsBuilder;
     homePage?: ReactNode;
     entityViews?: EntityCustomView[];
@@ -464,7 +464,7 @@ type CollectionPanelProps = {
     updateUrl?: boolean;                    // Sync filter/sort with URL (default: false)
     openEntityMode?: "side_panel" | "full_screen" | "split" | "dialog";
     className?: string;                     // Container CSS class
-    collectionOverrides?: Partial<EntityCollection>; // Additional overrides
+    collectionOverrides?: Partial<CollectionConfig>; // Additional overrides
 };
 ```
 
@@ -512,7 +512,7 @@ The Studio Bridge provides CMS capabilities to Studio components. When CMS is pr
 ```typescript
 interface StudioBridge {
     collectionRegistry: CollectionRegistryController;
-    sideEntityController: SideEntityController;
+    sideEntityController: SidePanelController;
     urlController: UrlController;
     navigationState: NavigationStateController;
     breadcrumbs: BreadcrumbsController;
@@ -524,7 +524,7 @@ interface StudioBridge {
 | Hook | Return Type | Description |
 |------|-------------|-------------|
 | `useStudioCollectionRegistry()` | `CollectionRegistryController` | Access registered collections from Studio |
-| `useStudioSideEntityController()` | `SideEntityController` | Open/close entity side panels from Studio |
+| `useStudioSidePanelController()` | `SidePanelController` | Open/close entity side panels from Studio |
 | `useStudioUrlController()` | `UrlController` | Build URLs and navigate from Studio |
 | `useStudioNavigationState()` | `NavigationStateController` | Access navigation state from Studio |
 | `useStudioBreadcrumbs()` | `BreadcrumbsController` | Set breadcrumbs from Studio tools |
@@ -534,7 +534,7 @@ All bridge hooks are exported from `@rebasepro/studio` (re-exported from `@rebas
 ```typescript
 import {
     useStudioCollectionRegistry,
-    useStudioSideEntityController,
+    useStudioSidePanelController,
     useStudioUrlController,
     useStudioNavigationState,
     useStudioBreadcrumbs
@@ -567,7 +567,7 @@ import { StudioBridgeProvider } from "@rebasepro/studio";
 
 <StudioBridgeProvider value={{
     collectionRegistry: useCollectionRegistryController(),
-    sideEntityController: useSideEntityController(),
+    sideEntityController: useSidePanel(),
     urlController: useUrlController(),
     navigationState: useNavigationStateController(),
     breadcrumbs: useBreadcrumbsController(),
@@ -610,7 +610,7 @@ These hooks are exported from `@rebasepro/core` and available inside any `<Rebas
 
 | Hook | Package | Description |
 |------|---------|-------------|
-| `useSideEntityController()` | `@rebasepro/admin` | Open/close entity side panels |
+| `useSidePanel()` | `@rebasepro/admin` | Open/close entity side panels |
 | `useNavigationStateController()` | `@rebasepro/admin` | Navigate between views |
 | `useUrlController()` | `@rebasepro/admin` | Build URLs and navigate |
 | `useBreadcrumbsController()` | `@rebasepro/admin` | Set breadcrumbs |

package/skills/rebase-webhooks/SKILL.md

@@ -5,7 +5,7 @@ description: Guide for sending outbound HTTP webhooks on entity changes in a Reb
 
 # Rebase Webhooks
 
-> **IMPORTANT FOR AGENTS**: The `WebhookDispatcher` is a **standalone service class** exported from `@rebasepro/server-core`. It is **not** auto-wired into the backend init pipeline — you must instantiate it yourself and call `onEntityChange()` from your application code (e.g. entity callbacks, custom functions, or cron jobs). Do NOT look for a `webhooks` key in `RebaseBackendConfig`.
+> **IMPORTANT FOR AGENTS**: The `WebhookDispatcher` is a **standalone service class** exported from `@rebasepro/server-core`. It is **not** auto-wired into the backend init pipeline — you must instantiate it yourself and call `onEntityChange()` from your application code (e.g. collection callbacks, custom functions, or cron jobs). Do NOT look for a `webhooks` key in `RebaseBackendConfig`.
 
 > **IMPORTANT FOR AGENTS**: Webhooks are **outbound** HTTP POST requests sent by your Rebase backend to external URLs. They are NOT inbound endpoints. To receive webhooks FROM external services, use Rebase custom functions instead (see `rebase-custom-functions` skill).
 
@@ -71,7 +71,7 @@ dispatcher.setWebhooks([
 
 ### Dispatch on Entity Changes
 
-Call `onEntityChange()` whenever an entity is created, updated, or deleted. The dispatcher checks all registered webhooks and fires matching ones.
+Call `onEntityChange()` whenever a entity is created, updated, or deleted. The dispatcher checks all registered webhooks and fires matching ones.
 
 ```typescript
 const results = await dispatcher.onEntityChange(
@@ -355,13 +355,13 @@ If the receiver does not respond within 10 seconds, the request is aborted and t
 
 ## Integration Patterns
 
-### With Entity Callbacks
+### With Collection Callbacks
 
-The most common pattern is to wire the dispatcher into Rebase entity callbacks so webhooks fire automatically on CRUD operations:
+The most common pattern is to wire the dispatcher into Rebase collection callbacks so webhooks fire automatically on CRUD operations:
 
 ```typescript
 // backend/collections/orders.ts
-import type { EntityCollection, EntityCallbacks } from "@rebasepro/types";
+import type { CollectionConfig, CollectionCallbacks } from "@rebasepro/types";
 import { WebhookDispatcher } from "@rebasepro/server-core/services/webhook-service";
 
 const dispatcher = new WebhookDispatcher();
@@ -376,35 +376,28 @@ dispatcher.setWebhooks([
     },
 ]);
 
-const callbacks: EntityCallbacks = {
-    afterCreate: async ({ entity, collection }) => {
+const callbacks: CollectionCallbacks = {
+    afterSave: async ({ id, values, previousValues, status, collection }) => {
+        const event = status === "new" ? "INSERT" : "UPDATE";
         await dispatcher.onEntityChange(
             collection.path,
-            "INSERT",
-            entity.id,
-            entity
-        );
-    },
-    afterUpdate: async ({ entity, previousEntity, collection }) => {
-        await dispatcher.onEntityChange(
-            collection.path,
-            "UPDATE",
-            entity.id,
-            entity,
-            previousEntity
+            event,
+            String(id),
+            values,
+            status === "new" ? undefined : previousValues
         );
     },
-    afterDelete: async ({ entityId, collection }) => {
+    afterDelete: async ({ id, collection }) => {
         await dispatcher.onEntityChange(
             collection.path,
             "DELETE",
-            entityId,
+            String(id),
             null
         );
     },
 };
 
-const ordersCollection: EntityCollection = {
+const ordersCollection: CollectionConfig = {
     name: "Orders",
     path: "orders",
     callbacks,
@@ -519,9 +512,11 @@ Then import it from any callback or function:
 ```typescript
 import { dispatcher } from "../lib/webhooks";
 
-// In an entity callback:
-afterCreate: async ({ entity, collection }) => {
-    await dispatcher.onEntityChange(collection.path, "INSERT", entity.id, entity);
+// In a collection callback:
+afterSave: async ({ id, values, status, collection }) => {
+    if (status === "new") {
+        await dispatcher.onEntityChange(collection.path, "INSERT", String(id), values);
+    }
 },
 ```
 
@@ -535,7 +530,7 @@ Registers the list of webhooks to watch. Filters out any with `enabled: false`.
 |-----------|------|-------------|
 | `webhooks` | `WebhookConfig[]` | Array of webhook configurations. |
 
-### `onEntityChange(table, event, entityId, entity, previousEntity?): Promise<WebhookDeliveryResult[]>`
+### `onEntityChange(table, event, id, entity, previousEntity?): Promise<WebhookDeliveryResult[]>`
 
 Checks all registered webhooks for matching `table` + `event`, and dispatches to each match.
 
@@ -543,7 +538,7 @@ Checks all registered webhooks for matching `table` + `event`, and dispatches to
 |-----------|------|-------------|
 | `table` | `string` | The database table name (e.g. `"orders"`). |
 | `event` | `"INSERT" \| "UPDATE" \| "DELETE"` | The type of entity change. |
-| `entityId` | `string` | The unique ID of the changed entity. |
+| `id` | `string` | The unique ID of the changed entity. |
 | `entity` | `Record<string, unknown> \| null` | The current entity data. May be `null` for deletes. |
 | `previousEntity` | `Record<string, unknown> \| null` | *(Optional)* The previous entity state. Only relevant for `UPDATE` events — included as `old_record` in the payload. |
 
@@ -557,7 +552,7 @@ The dispatcher supports three event types, passed as the `event` parameter to `o
 |-------|-------------|--------------------|-----------------------|
 | `INSERT` | A new entity was created | The new entity | `undefined` |
 | `UPDATE` | An existing entity was modified | The updated entity | The entity before update |
-| `DELETE` | An entity was removed | The deleted entity (or `null`) | `undefined` |
+| `DELETE` | a entity was removed | The deleted entity (or `null`) | `undefined` |
 
 ## Error Handling
 
@@ -592,9 +587,9 @@ for (const result of results) {
 If you don't want webhook delivery to block your API response, use fire-and-forget:
 
 ```typescript
-afterCreate: async ({ entity, collection }) => {
+afterSave: async ({ id, values, collection }) => {
     // Fire-and-forget — don't await
-    dispatcher.onEntityChange(collection.path, "INSERT", entity.id, entity)
+    dispatcher.onEntityChange(collection.path, "INSERT", String(id), values)
         .catch(err => console.error("Webhook dispatch error:", err));
 },
 ```