@rebasepro/agent-skills 0.8.0 → 0.9.1-canary.09aaf62

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rebasepro/agent-skills",
-  "version": "0.8.0",
+  "version": "0.9.1-canary.09aaf62",
   "private": false,
   "description": "Bundled AI agent skills for Rebase",
   "type": "module",

package/skills/rebase-admin/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: rebase-admin
-description: Guide for navigating the Rebase admin CMS, opening entities in side drawers, building URLs, embedding collection panels, using the collection registry, and programmatic navigation. Use this skill when an agent or user needs to navigate to a collection view, open an entity in the side panel/drawer, build admin URLs, embed a collection inside a custom page, use the entity selection dialog, or access CMS-specific controllers.
+description: Guide for navigating the Rebase admin CMS, opening entities in side drawers, building URLs, embedding collection panels, using the collection registry, and programmatic navigation. Use this skill when an agent or user needs to navigate to a collection view, open a entity in the side panel/drawer, build admin URLs, embed a collection inside a custom page, use the entity selection dialog, or access CMS-specific controllers.
 ---
 
 # Rebase Admin (`@rebasepro/admin`)
@@ -13,12 +13,12 @@ The `@rebasepro/admin` package provides the CMS layer for Rebase. It handles col
 
 | Task | Hook / Component | Package |
 |------|-----------------|---------|
-| Open entity in side drawer | `useSideEntityController()` | `@rebasepro/admin` |
+| Open entity in side drawer | `useSidePanel()` | `@rebasepro/admin` |
 | Navigate to a collection view | `useUrlController()` | `@rebasepro/admin` |
 | Look up a collection by slug | `useCollectionRegistryController()` | `@rebasepro/admin` |
 | Embed a collection in a custom page | `<CollectionPanel>` | `@rebasepro/admin` |
-| Add custom top-level views | `<RebaseCMS views={[...]}>` | `@rebasepro/admin` |
-| Open an entity selection dialog | `useEntitySelectionDialog()` | `@rebasepro/admin` |
+| Add custom top-level views | `<RebaseAdmin views={[...]}>` | `@rebasepro/admin` |
+| Open a entity selection dialog | `useSelectionDialog()` | `@rebasepro/admin` |
 | Open a custom side dialog | `useSideDialogsController()` | `@rebasepro/admin` |
 | Set breadcrumbs | `useBreadcrumbsController()` | `@rebasepro/admin` |
 | Access full CMS context | `useCMSContext()` | `@rebasepro/admin` |
@@ -28,16 +28,16 @@ The `@rebasepro/admin` package provides the CMS layer for Rebase. It handles col
 
 ## 1. Opening Entities in the Side Drawer
 
-Use `useSideEntityController()` to open, replace, or close entity side panels (the sliding drawer that shows entity forms).
+Use `useSidePanel()` to open, replace, or close entity side panels (the sliding drawer that shows entity forms).
 
 ```typescript
-import { useSideEntityController } from "@rebasepro/admin";
+import { useSidePanel } from "@rebasepro/admin";
 ```
 
-### SideEntityController Interface
+### SidePanelController Interface
 
 ```typescript
-interface SideEntityController {
+interface SidePanelController {
     /** Close the last (topmost) panel */
     close: () => void;
 
@@ -69,7 +69,7 @@ interface EntitySidePanelProps<M extends Record<string, unknown> = Record<string
     width?: number | string;
 
     /** Explicit collection config (auto-resolved from navigation if omitted) */
-    collection?: EntityCollection<M>;
+    collection?: CollectionConfig<M>;
 
     /** Whether to update the browser URL when opening (default: true) */
     updateUrl?: boolean;
@@ -98,7 +98,7 @@ interface EntitySidePanelProps<M extends Record<string, unknown> = Record<string
 
 **Open an existing entity for editing:**
 ```tsx
-const sideEntityController = useSideEntityController();
+const sideEntityController = useSidePanel();
 
 // Open the product with ID "abc123" in the side drawer
 sideEntityController.open({
@@ -236,10 +236,10 @@ import { useCollectionRegistryController } from "@rebasepro/admin";
 ```typescript
 type CollectionRegistryController<
     DB = Record<string, unknown>,
-    EC extends EntityCollection = EntityCollection
+    EC extends CollectionConfig = CollectionConfig
 > = {
     /** All registered collections */
-    collections?: EntityCollection[];
+    collections?: CollectionConfig[];
 
     /** Whether the registry is ready */
     initialised: boolean;
@@ -321,7 +321,7 @@ type CollectionPanelProps = {
     className?: string;
 
     /** Additional collection-level overrides */
-    collectionOverrides?: Partial<EntityCollection>;
+    collectionOverrides?: Partial<CollectionConfig>;
 };
 ```
 
@@ -356,17 +356,17 @@ type CollectionPanelProps = {
 
 ## 5. Entity Selection Dialog
 
-Use `useEntitySelectionDialog()` to open a side dialog for selecting entities (same mechanism used by reference fields).
+Use `useSelectionDialog()` to open a side dialog for selecting entities (same mechanism used by reference fields).
 
 ```typescript
-import { useEntitySelectionDialog } from "@rebasepro/admin";
+import { useSelectionDialog } from "@rebasepro/admin";
 ```
 
 ### Usage
 
 ```tsx
 function MyComponent() {
-    const { open, close } = useEntitySelectionDialog<Product>({
+    const { open, close } = useSelectionDialog<Product>({
         path: "products",
         onSingleEntitySelected: (entity) => {
             console.log("Selected:", entity.id);
@@ -378,7 +378,7 @@ function MyComponent() {
 }
 ```
 
-The hook accepts all `EntitySelectionProps` except `path` (which you pass separately), plus an `onClose` callback.
+The hook accepts all `SelectionProps` except `path` (which you pass separately), plus an `onClose` callback.
 
 ---
 
@@ -545,7 +545,7 @@ import { useCMSContext } from "@rebasepro/admin";
 
 ```typescript
 type CMSContext = RebaseContext & {
-    sideEntityController: SideEntityController;
+    sideEntityController: SidePanelController;
     sideDialogsController: SideDialogsController;
     urlController: UrlController;
     navigationStateController: NavigationStateController;
@@ -566,20 +566,20 @@ context.authController; // from RebaseContext
 context.data;           // DataSource from RebaseContext
 ```
 
-> **TIP:** Use `useCMSContext()` instead of `useRebaseContext()` when you need CMS controllers (side panels, navigation, URL). Use `useRebaseContext()` from `@rebasepro/core` when you only need core context (auth, data, storage).
+> **TIP:** Use `useCMSContext()` instead of `useRebaseContext()` when you need CMS controllers (side panels, navigation, URL). Use `useRebaseContext()` from `@rebasepro/app` when you only need core context (auth, data, storage).
 
 ---
 
 ## 10. Common Patterns
 
-### Navigate to a collection and open an entity
+### Navigate to a collection and open a entity
 
 ```tsx
-import { useUrlController, useSideEntityController } from "@rebasepro/admin";
+import { useUrlController, useSidePanel } from "@rebasepro/admin";
 
 function navigateAndOpen() {
     const urlController = useUrlController();
-    const sideEntityController = useSideEntityController();
+    const sideEntityController = useSidePanel();
 
     // First navigate to the collection
     urlController.navigate(urlController.buildUrlCollectionPath("products"));
@@ -595,10 +595,10 @@ function navigateAndOpen() {
 ### Open entity from a custom view without navigating
 
 ```tsx
-import { useSideEntityController } from "@rebasepro/admin";
+import { useSidePanel } from "@rebasepro/admin";
 
 function MyCustomView() {
-    const sideEntityController = useSideEntityController();
+    const sideEntityController = useSidePanel();
 
     return (
         <button onClick={() => sideEntityController.open({
@@ -615,10 +615,10 @@ function MyCustomView() {
 ### Programmatic entity creation from a custom view
 
 ```tsx
-import { useSideEntityController } from "@rebasepro/admin";
+import { useSidePanel } from "@rebasepro/admin";
 
 function CreateButton() {
-    const sideEntity = useSideEntityController();
+    const sideEntity = useSidePanel();
 
     return (
         <button onClick={() => sideEntity.open({
@@ -642,7 +642,7 @@ function CreateButton() {
 
 ## 10. Custom Top-Level Views
 
-Add custom pages to the main CMS navigation using the `views` prop on `<RebaseCMS>`. Views appear alongside collections in the sidebar and home page.
+Add custom pages to the main CMS navigation using the `views` prop on `<RebaseAdmin>`. Views appear alongside collections in the sidebar and home page.
 
 ### AppView Interface
 
@@ -663,7 +663,7 @@ interface AppView {
 ### Static Views
 
 ```tsx
-<RebaseCMS
+<RebaseAdmin
     collections={collections}
     views={[
         { slug: "dashboard", name: "Dashboard", icon: "LayoutDashboard", view: <Dashboard /> },
@@ -678,7 +678,7 @@ interface AppView {
 Pass a function instead of an array to dynamically resolve views based on the current user:
 
 ```tsx
-<RebaseCMS
+<RebaseAdmin
     collections={collections}
     views={({ user, authController, data }) => [
         { slug: "dashboard", name: "Dashboard", icon: "LayoutDashboard", view: <Dashboard /> },
@@ -703,7 +703,7 @@ const myPlugin: RebasePlugin = {
     ]
 };
 
-<RebaseCMS plugins={[myPlugin]} />
+<RebaseAdmin plugins={[myPlugin]} />
 ```
 
 All views (CMS, builder, plugin) are merged in order: **CMS views → Studio dev views → Plugin views**.
@@ -730,7 +730,7 @@ The `roles` field provides declarative access control. When set, the view is exc
 Views participate in the same navigation group system as collections. Use the `group` property on the view, or control grouping centrally via `navigationGroupMappings`:
 
 ```tsx
-<RebaseCMS
+<RebaseAdmin
     collections={collections}
     views={[
         { slug: "dashboard", name: "Dashboard", view: <Dashboard />, group: "Analytics" },
@@ -745,19 +745,49 @@ Views participate in the same navigation group system as collections. Use the `g
 
 ---
 
+## 11. Where the Admin Lives — Mounting Under a URL Prefix
+
+In the default scaffold the frontend **is** the admin panel: `App.tsx` renders `<RebaseAuth>` + `<RebaseAdmin>` + `<RebaseShell>` at the root, so the deployed URL shows the admin directly. There is no separate admin URL — in production one server serves both the API (`/api/*`) and this SPA.
+
+When a project ships its **own product app** as the frontend, the admin is mounted under a prefix (commonly `/admin`) instead. Split the Vite entry by URL so each app is lazy-loaded and product visitors never download the admin bundle:
+
+```tsx
+// frontend/src/main.tsx
+const isAdmin = window.location.pathname.startsWith("/admin");
+const ProductApp = lazy(() => import("./App"));
+const AdminApp = lazy(() => import("./AdminApp"));
+
+if (isAdmin) {
+    // The admin uses useBlocker → needs a DATA router
+    const router = createBrowserRouter([{ path: "/admin/*", element: <AdminApp /> }]);
+    root.render(<RouterProvider router={router} />);
+} else {
+    root.render(<BrowserRouter><ProductApp /></BrowserRouter>);
+}
+```
+
+```tsx
+// frontend/src/AdminApp.tsx — tell the CMS about the prefix
+<RebaseAdmin collections={collections} basePath="/admin" />
+```
+
+> **IMPORTANT FOR AGENTS:** Choose **either** a router `basename="/admin"` **or** `<RebaseAdmin basePath="/admin">` — never both, or the prefix is applied twice. Without either, collection views hang on a spinner because URL⇄collection resolution never matches. `<RebaseAdmin>` requires a **data router** (`createBrowserRouter`) because it uses `useBlocker`.
+
+---
+
 ## Exported Components
 
 The admin package exports the following components (from `@rebasepro/admin`):
 
 | Component | Description |
 |-----------|-------------|
-| `RebaseCMS` | Declarative CMS config (collections, views, editor) — renders nothing |
+| `RebaseAdmin` | Declarative CMS config (collections, views, editor) — renders nothing |
 | `RebaseShell` | App shell (drawer, nav, routes, layout) — renders the actual UI |
 | `CollectionPanel` | Embed a collection view inside custom pages |
-| `EntityCollectionView` | The collection view component |
-| `EntityView` | Entity detail/edit view |
+| `DataCollectionView` | The collection view component |
+| `EntityCustomView` | Entity detail/edit view |
 | `EntityPreview` | Reference/relation preview chip |
-| `EntityCard` | Card representation of an entity |
+| `EntityCard` | Card representation of a entity |
 | `SideDialogs` | Side dialog container |
 | `SideEntityProvider` | Context provider for side entity controller |
 | `EntitySelectionTable` | Table for selecting entities |
@@ -773,16 +803,16 @@ The admin package exports the following components (from `@rebasepro/admin`):
 
 | Hook | Description |
 |------|-------------|
-| `useSideEntityController()` | Open/close entity side panels |
+| `useSidePanel()` | Open/close entity side panels |
 | `useSideDialogsController()` | Open/close generic side dialogs |
 | `useUrlController()` | Build URLs and navigate |
 | `useNavigationStateController()` | Access navigation state |
 | `useCollectionRegistryController()` | Look up collections by slug |
 | `useBreadcrumbsController()` | Read/set breadcrumbs |
 | `useCMSContext()` | Full CMS context (core + CMS controllers) |
-| `useEntitySelectionDialog()` | Open entity selection dialog |
+| `useSelectionDialog()` | Open entity selection dialog |
 | `useSelectionController()` | Multi-select controller |
-| `useEntityHistory()` | Entity version history |
+| `useHistory()` | Entity version history |
 | `useApp()` | App-level utilities |
 
 ## Exported Utilities
@@ -796,8 +826,8 @@ The admin package exports the following components (from `@rebasepro/admin`):
 | `getLastSegment(path)` | Get last path segment |
 | `getCollectionBySlugWithin(collections, slug)` | Find collection in array |
 | `mergeEntityActions(...)` | Merge entity action arrays |
-| `resolveEntityAction(...)` | Resolve an entity action |
-| `resolveEntityView(...)` | Resolve an entity view |
+| `resolveEntityAction(...)` | Resolve a entity action |
+| `resolveEntityView(...)` | Resolve a entity view |
 | `isReferenceProperty(prop)` | Check if property is a reference |
 | `isRelationProperty(prop)` | Check if property is a relation |
 | `getIconForProperty(prop)` | Get icon for a property type |

package/skills/rebase-api/SKILL.md

@@ -5,7 +5,7 @@ description: Guide for working with Rebase auto-generated REST and GraphQL APIs.
 
 # Rebase Auto-Generated APIs
 
-> **WARNING FOR AGENTS**: If you are writing a script or data task, **default to using the Rebase SDK** (`@rebasepro/client` or `@rebasepro/server-core`) instead of making raw REST or GraphQL API calls (`fetch` / `curl`). For custom backend functions, use `client.functions.invoke('function-name', payload)` — **NEVER** manually construct `/api/functions/` URLs or extract tokens from localStorage. Only use raw API calls if specifically instructed to do so or if you are demonstrating HTTP usage to the user.
+> **WARNING FOR AGENTS**: If you are writing a script or data task, **default to using the Rebase SDK** (`@rebasepro/client` or `@rebasepro/server`) instead of making raw REST or GraphQL API calls (`fetch` / `curl`). For custom backend functions, use `client.functions.invoke('function-name', payload)` — **NEVER** manually construct `/api/functions/` URLs or extract tokens from localStorage. Only use raw API calls if specifically instructed to do so or if you are demonstrating HTTP usage to the user.
 
 Every collection defined in Rebase automatically gets full REST CRUD and GraphQL endpoints. No manual route creation needed.
 
@@ -43,8 +43,8 @@ All data routes are mounted under `/api/data/`. Other route categories:
 | `GET` | `/api/data/{slug}/count` | Count matching entities (with optional filters) | `200` |
 | `GET` | `/api/data/{slug}/:id` | Get a single entity by ID | `200` |
 | `POST` | `/api/data/{slug}` | Create a new entity | `201` |
-| `PUT` | `/api/data/{slug}/:id` | Update an entity | `200` |
-| `DELETE` | `/api/data/{slug}/:id` | Delete an entity | `204` |
+| `PUT` | `/api/data/{slug}/:id` | Update a entity | `200` |
+| `DELETE` | `/api/data/{slug}/:id` | Delete a entity | `204` |
 
 ### Subcollection Routes
 
@@ -337,11 +337,17 @@ Authorization: Bearer rk_live_abc123...
 
 If an API key lacks the required permission for an operation, a `403 API_KEY_FORBIDDEN` error is returned.
 
-**Admin API keys** — set `"admin": true` when creating a key to grant it the `admin` role. This gives access to all `/api/admin/*` routes (schema, users, other API keys, etc.). Use this for agents, MCP servers, and CI pipelines:
+Beyond collections, the permission list also covers custom functions
+(`"functions"` for all, `"functions/<name>"` for one) and file storage
+(`"storage"`); the global `"*"` wildcard grants all three. API keys do NOT
+bypass RLS: admin keys pass via the built-in admin policies, while non-admin
+keys only see rows a security rule grants to the `service` role or the public.
+
+**Admin API keys** — set `"admin": true` when creating a key to grant it the `admin` role. This gives access to all `/api/admin/*` routes (schema, users, other API keys, etc.) plus cron, backups, and logs. Use this for agents, MCP servers, and CI pipelines:
 
 ```bash
-# CLI
-rebase api-keys create --name "My Agent" --admin
+# CLI (an explicit scope is required: --permissions '<json>' or --full-access)
+rebase api-keys create --name "My Agent" --admin --full-access
 
 # REST
 POST /api/admin/api-keys
@@ -405,7 +411,7 @@ curl -H "Authorization: Bearer $TOKEN" \
   "https://example.com/api/data/products?status=eq.active&price=gte.50&orderBy=created_at:desc&limit=10&offset=0&include=category"
 ```
 
-### Create an entity
+### Create a entity
 
 ```bash
 curl -X POST \
@@ -415,7 +421,7 @@ curl -X POST \
   "https://example.com/api/data/products"
 ```
 
-### Update an entity
+### Update a entity
 
 ```bash
 curl -X PUT \
@@ -425,7 +431,7 @@ curl -X PUT \
   "https://example.com/api/data/products/uuid-123"
 ```
 
-### Delete an entity
+### Delete a entity
 
 ```bash
 curl -X DELETE \
@@ -655,19 +661,19 @@ GET /api/collections
 | `pagination.maxLimit` | `number` | `100` | Maximum allowed page size |
 | `cors.origin` | `string \| string[] \| boolean` | — | CORS origin configuration |
 | `cors.credentials` | `boolean` | `false` | Allow credentials in CORS |
-| `collections` | `EntityCollection[]` | `[]` | Collections to generate APIs for |
+| `collections` | `CollectionConfig[]` | `[]` | Collections to generate APIs for |
 | `collectionsDir` | `string` | — | Directory to auto-discover collections |
 
 ## References
 
 - **Documentation:** [rebase.pro/docs](https://rebase.pro/docs)
 - **GitHub:** [github.com/rebasepro/rebase](https://github.com/rebasepro/rebase)
-- **REST API Generator:** `packages/server-core/src/api/rest/api-generator.ts`
-- **Query Parser:** `packages/server-core/src/api/rest/query-parser.ts`
-- **GraphQL Generator:** `packages/server-core/src/api/graphql/graphql-schema-generator.ts`
-- **OpenAPI Generator:** `packages/server-core/src/api/openapi-generator.ts`
-- **Error Handling:** `packages/server-core/src/api/errors.ts`
-- **Server Setup:** `packages/server-core/src/api/server.ts`
-- **API Types:** `packages/server-core/src/api/types.ts`
-- **Auth Middleware:** `packages/server-core/src/auth/middleware.ts`
+- **REST API Generator:** `packages/server/src/api/rest/api-generator.ts`
+- **Query Parser:** `packages/server/src/api/rest/query-parser.ts`
+- **GraphQL Generator:** `packages/server/src/api/graphql/graphql-schema-generator.ts`
+- **OpenAPI Generator:** `packages/server/src/api/openapi-generator.ts`
+- **Error Handling:** `packages/server/src/api/errors.ts`
+- **Server Setup:** `packages/server/src/api/server.ts`
+- **API Types:** `packages/server/src/api/types.ts`
+- **Auth Middleware:** `packages/server/src/auth/middleware.ts`
 - **DataHooks Types:** `packages/types/src/types/backend_hooks.ts`

package/skills/rebase-auth/SKILL.md

@@ -39,12 +39,13 @@ Authentication is configured via the `auth` property of `initializeRebaseBackend
 
 | Property | Type | Default | Description |
 |---|---|---|---|
-| `collection` | `EntityCollection` | Built-in users collection | The collection used for auth user storage. Import `defaultUsersCollection` from `@rebasepro/common` or pass a custom collection with required auth fields. |
+| `collection` | `CollectionConfig` | Built-in users collection | The collection used for auth user storage. Import `defaultUsersCollection` from `@rebasepro/common` or pass a custom collection with required auth fields. |
 | `jwtSecret` | `string` | — | **Required.** Secret for signing JWT access tokens. |
 | `accessExpiresIn` | `string` | `"1h"` | Access token lifetime (e.g. `"15m"`, `"2h"`). |
 | `refreshExpiresIn` | `string` | `"30d"` | Refresh token lifetime. |
 | `requireAuth` | `boolean` | `true` | When `true`, data routes return 401 for unauthenticated requests. Set to `false` to rely entirely on Postgres RLS. |
 | `allowRegistration` | `boolean` | `false` | Enable self-service registration via `POST /auth/register`. |
+| `allowUserLookup` | `boolean` | `false` | Expose `POST /auth/find-user` — an authenticated email→minimal-profile lookup (`uid`/`displayName`/`photoURL` only) for invite flows. Enables user enumeration by signed-in users, so it's off by default. See [Inviting by email](#inviting-teammates-by-email). |
 | `serviceKey` | `string` | — | Static secret for server-to-server auth. Must be ≥ 32 characters. Requests with `Authorization: Bearer <serviceKey>` get admin access. |
 | `defaultRole` | `string` | — | Role ID assigned to new users (except the first user, who always gets `"admin"`). **Must NOT be `"admin"`** — throws a security error at startup. |
 | `providers` | `OAuthProvider<unknown>[]` | `[]` | **Canonical** OAuth provider array. Use `create*Provider` factories or pass custom providers. Named shorthand fields below are merged into this array at startup. |
@@ -66,8 +67,8 @@ Authentication is configured via the `auth` property of `initializeRebaseBackend
 ### Minimal Example
 
 ```typescript
-import { initializeRebaseBackend } from "@rebasepro/server-core";
-import { createPostgresAdapter } from "@rebasepro/server-postgresql";
+import { initializeRebaseBackend } from "@rebasepro/server";
+import { createPostgresAdapter } from "@rebasepro/server-postgres";
 
 await initializeRebaseBackend({
   server,
@@ -107,9 +108,9 @@ await initializeRebaseBackend({
 Instead of relying solely on the default database auth rules, you can mark any Postgres collection (such as `users.ts` or a custom `members.ts` collection) as the authentication collection. This is configured via the `auth` property on the collection itself:
 
 ```typescript
-import { PostgresCollection } from "@rebasepro/types";
+import { PostgresCollectionConfig } from "@rebasepro/types";
 
-const membersCollection: PostgresCollection = {
+const membersCollection: PostgresCollectionConfig = {
   name: "Members",
   slug: "members",
   table: "members",
@@ -154,6 +155,27 @@ When custom hooks (`onCreateUser`, `onResetPassword`) are called, they receive a
 
 > **IMPORTANT FOR AGENTS:** The very first user registered (via `POST /auth/register` or OAuth) is automatically promoted to `"admin"`. This prevents the chicken-and-egg problem. All subsequent users receive the `defaultRole`.
 
+### Inviting teammates by email
+
+Invite flows must turn an email into a user id, but the `users` collection is
+RLS-protected from the client. **Do not** hand-roll an admin server function for
+this — enable `allowUserLookup` and use the built-in primitive:
+
+```typescript
+// backend: initializeRebaseBackend({ auth: { allowUserLookup: true } })
+
+// client:
+const profile = await rebase.auth.findUserByEmail("teammate@example.com");
+// → { uid, displayName, photoURL } | null   (never email/roles/metadata)
+if (profile) {
+    await rebase.data.team_members.create({ team_id, user_id: profile.uid });
+}
+```
+
+The `find-user` endpoint is authenticated-only and returns just the minimal
+public profile. It is off by default because it enables user enumeration by any
+signed-in user.
+
 ---
 
 ## OAuth Providers
@@ -208,7 +230,7 @@ You can register any OAuth provider by implementing the `OAuthProvider<T>` inter
 
 ```typescript
 import { z } from "zod";
-import type { OAuthProvider, OAuthProviderProfile } from "@rebasepro/server-core";
+import type { OAuthProvider, OAuthProviderProfile } from "@rebasepro/server";
 
 const myProvider: OAuthProvider<{ token: string }> = {
   id: "my-provider",
@@ -446,7 +468,7 @@ By default API keys get the `service` role (data access only). Set `"admin": tru
 
 ```bash
 # CLI — create an admin API key
-rebase api-keys create --name "My Agent" --admin
+rebase api-keys create --name "My Agent" --admin --full-access
 
 # REST
 curl -X POST http://localhost:3000/api/admin/api-keys \
@@ -602,7 +624,7 @@ rebase api-keys list
 rebase api-keys create --name "Read Only" --permissions '[{"collection":"orders","operations":["read"]}]'
 
 # Create an admin key (for agents / MCP / CI)
-rebase api-keys create --name "My Agent" --admin
+rebase api-keys create --name "My Agent" --admin --full-access
 
 # Revoke a key
 rebase api-keys revoke <key-id>
@@ -859,7 +881,7 @@ API keys use a service identity for RLS scoping: `uid: "api-key:{id}"`, `roles:
 
 ### Reserved System Identities
 
-The auth middleware assigns these reserved identities automatically. They are visible in `context.user` (Entity Callbacks / DataHooks) and `c.get("user")` (custom functions):
+The auth middleware assigns these reserved identities automatically. They are visible in `context.user` (Collection Callbacks / DataHooks) and `c.get("user")` (custom functions):
 
 | Auth Method | `userId` | `roles` | When It Occurs |
 |---|---|---|---|
@@ -870,7 +892,7 @@ The auth middleware assigns these reserved identities automatically. They are vi
 | Anonymous | `"anon"` | `["anon"]` | Unauthenticated when `requireAuth: false` |
 | No token + `requireAuth: true` | — | — | **Rejected (401)** |
 
-> **IMPORTANT FOR AGENTS:** Server-side `rebase.data` (the singleton used in cron jobs, custom functions, and webhooks) is built with `createRebaseClient({ token: serviceKey })`. It round-trips through the REST API, so all middleware, DataHooks, and Entity Callbacks fire with `userId: "service"`, `roles: ["admin"]`. This lets developers distinguish server-internal reads from end-user reads in callbacks.
+> **IMPORTANT FOR AGENTS:** Server-side `rebase.data` (the singleton used in cron jobs, custom functions, and webhooks) is built with `createRebaseClient({ token: serviceKey })`. It round-trips through the REST API, so all middleware, DataHooks, and Collection Callbacks fire with `userId: "service"`, `roles: ["admin"]`. This lets developers distinguish server-internal reads from end-user reads in callbacks.
 
 ---
 
@@ -914,7 +936,7 @@ API keys have their own per-key rate limiter. The `rate_limit` on each key speci
 ### Custom Rate Limiter
 
 ```typescript
-import { createRateLimiter } from "@rebasepro/server-core";
+import { createRateLimiter } from "@rebasepro/server";
 
 const myLimiter = createRateLimiter({
   windowMs: 60 * 1000,         // 1 minute
@@ -968,7 +990,7 @@ interface AuthenticatedUser {
 The simplest way to plug an existing auth system into Rebase. Only `verifyRequest` is required:
 
 ```typescript
-import { createCustomAuthAdapter } from "@rebasepro/server-core";
+import { createCustomAuthAdapter } from "@rebasepro/server";
 import jwt from "jsonwebtoken";
 
 const auth = createCustomAuthAdapter({
@@ -1092,7 +1114,7 @@ Admin user and role management is handled via dedicated admin routes (mounted un
 
 ## Backend Hooks
 
-Backend hooks intercept data at the **API boundary** (after DB operations, before API responses). They are separate from auth hooks and collection-level `EntityCallbacks`.
+Backend hooks intercept data at the **API boundary** (after DB operations, before API responses). They are separate from auth hooks and collection-level `CollectionCallbacks`.
 
 ### BackendHooks Interface
 
@@ -1256,7 +1278,7 @@ When a request includes `Authorization: Bearer <serviceKey>`:
 - Comparison is done with constant-time comparison to prevent timing attacks.
 - Must be ≥ 32 characters (validated at startup).
 
-> **TIP:** In Entity Callbacks and DataHooks, server-side `rebase.data` calls appear as `userId: "service"`, `roles: ["admin"]`. Use this to skip masking, bypass rate limits, or grant elevated access in your callback logic.
+> **TIP:** In Collection Callbacks and DataHooks, server-side `rebase.data` calls appear as `userId: "service"`, `roles: ["admin"]`. Use this to skip masking, bypass rate limits, or grant elevated access in your callback logic.
 
 ### Token Rotation
 
@@ -1288,14 +1310,14 @@ All auth endpoints validate input with Zod schemas:
 
 ## References
 
-- Source: `packages/server-core/src/auth/` — All auth implementation
-- Source: `packages/server-core/src/auth/routes.ts` — REST auth endpoints
-- Source: `packages/server-core/src/auth/auth-hooks.ts` — Lifecycle hooks
-- Source: `packages/server-core/src/auth/api-keys/` — API key system
-- Source: `packages/server-core/src/auth/rate-limiter.ts` — Rate limiting
-- Source: `packages/server-core/src/init.ts` — `RebaseAuthConfig` and backend init
+- Source: `packages/server/src/auth/` — All auth implementation
+- Source: `packages/server/src/auth/routes.ts` — REST auth endpoints
+- Source: `packages/server/src/auth/auth-hooks.ts` — Lifecycle hooks
+- Source: `packages/server/src/auth/api-keys/` — API key system
+- Source: `packages/server/src/auth/rate-limiter.ts` — Rate limiting
+- Source: `packages/server/src/init.ts` — `RebaseAuthConfig` and backend init
 - Source: `packages/client/src/auth.ts` — Client SDK auth module
 - Source: `packages/types/src/types/auth_adapter.ts` — `AuthAdapter` interface
-- Source: `packages/server-core/src/auth/rls-scope.ts` — RLS scoping
-- Source: `packages/server-core/src/email/types.ts` — Email configuration
+- Source: `packages/server/src/auth/rls-scope.ts` — RLS scoping
+- Source: `packages/server/src/email/types.ts` — Email configuration
 - **Reserved Identities**: `"service"` / `"anon"` / `"api-key:{id}"` — see [Row-Level Security > Reserved System Identities](#reserved-system-identities)