@rebasepro/agent-skills 0.9.0 → 0.9.1-canary.0de22e0

package/package.json

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

package/skills/rebase-admin/SKILL.md

@@ -17,7 +17,7 @@ The `@rebasepro/admin` package provides the CMS layer for Rebase. It handles col
 | 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` |
+| 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` |
@@ -566,7 +566,7 @@ 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).
 
 ---
 
@@ -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,13 +745,43 @@ 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 |
 | `DataCollectionView` | The collection view component |

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.
 
@@ -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
@@ -662,12 +668,12 @@ GET /api/collections
 
 - **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

@@ -67,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,
@@ -219,18 +219,55 @@ Twitter uses OAuth 2.0 with PKCE. The client must send `codeVerifier` alongside
 
 ### OAuth Account Linking
 
-When an OAuth user signs in:
-1. If an identity record exists for `(providerId, provider)` → log in that user.
-2. If no identity exists but a user with the same email exists → **link** the provider to the existing account.
+When an OAuth user signs in via `POST /api/auth/{provider}`:
+
+1. If an identity record exists for `(provider, providerId)` → log in that user. The email is not consulted.
+2. If no identity exists but a user with the same email exists:
+   - **The provider asserted `emailVerified: true`** → **link** the provider to the existing account and log in as that user. One account, two sign-in methods.
+   - **The provider did NOT verify the email** → reject with `403 EMAIL_NOT_VERIFIED`. Nothing is created or modified.
 3. If neither exists → create a new user, link the identity, assign `defaultRole`.
 
+> **IMPORTANT FOR AGENTS:** A second account is **never** silently created for
+> an email that already exists. If asked "does signing in with Google create a
+> duplicate user?", the answer is no — it either links (verified) or errors
+> (unverified). This is **not configurable**; there is deliberately no option to
+> auto-link on unverified emails, because that would let anyone who can make a
+> provider emit an address they don't own take over the matching account.
+> Google always asserts `email_verified` for real Google accounts, so linking
+> is the normal path for Google sign-in.
+
+### Linking a Provider to a Signed-In Account
+
+`POST /api/auth/link/{provider}` attaches a provider identity to the **already
+authenticated** account (requires `Authorization: Bearer <token>`). The body is
+the same payload the provider's sign-in route takes, e.g. `{ idToken }`.
+
+This is the escape hatch from an `EMAIL_NOT_VERIFIED` rejection, and the way to
+attach a provider whose email differs from the account's.
+
+Unlike sign-in, linking here does **not** require a verified email and does not
+require the emails to match — on sign-in the provider's email is the only
+evidence tying the identity to an account, whereas here the caller has already
+proven ownership by holding a valid session.
+
+- `409 IDENTITY_ALREADY_LINKED` if that provider identity belongs to another user.
+- Idempotent (`alreadyLinked: true`) if already linked to the caller.
+
+### Adding a Password to a Provider-Only Account
+
+A user who signed up via OAuth has no `passwordHash`:
+
+- `POST /auth/register` with the same email → `409 EMAIL_EXISTS`.
+- `POST /auth/change-password` → `400 INVALID_ACCOUNT` (no existing password to verify).
+- **`forgot-password` → `reset-password` is the supported path.** It re-proves ownership of the address by email, after which the account has both sign-in methods.
+
 ### Custom OAuth Provider
 
 You can register any OAuth provider by implementing the `OAuthProvider<T>` interface:
 
 ```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",
@@ -468,7 +505,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 \
@@ -624,7 +661,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>
@@ -659,6 +696,7 @@ All auth endpoints are mounted under `/api/auth`. Admin endpoints are under `/ap
 | `PATCH` | `/auth/me` | Required | Update profile. Body: `{ displayName?, photoURL? }`. |
 | `POST` | `/auth/change-password` | Required | Change password. Body: `{ oldPassword, newPassword }`. Invalidates all sessions. |
 | `POST` | `/auth/send-verification` | Required | Send email verification link. Requires email service. |
+| `POST` | `/auth/link/{provider}` | Required | Link an OAuth provider to the current account. Body: the provider's sign-in payload (e.g. `{ idToken }`). `409 IDENTITY_ALREADY_LINKED` if it belongs to another user. |
 | `GET` | `/auth/sessions` | Required | List active sessions (refresh tokens). |
 | `DELETE` | `/auth/sessions` | Required | Revoke all sessions (remote logout). |
 | `DELETE` | `/auth/sessions/:id` | Required | Revoke a specific session. |
@@ -936,7 +974,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
@@ -990,7 +1028,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({
@@ -1310,14 +1348,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)

package/skills/rebase-backend-postgres/SKILL.md

@@ -5,7 +5,7 @@ description: Guide for setting up and managing the Rebase PostgreSQL backend wit
 
 # Rebase PostgreSQL Backend
 
-> **WARNING FOR AGENTS**: If you are writing a script or performing data tasks (e.g., seeding, migrating content), **default to using the Rebase SDK** (`@rebasepro/client` or `@rebasepro/server-core`). **NEVER** use `psql` or raw SQL to manipulate data directly unless specifically instructed to do so for low-level debugging. Bypassing the SDK circumvents schema validation, access controls, and lifecycle hooks.
+> **WARNING FOR AGENTS**: If you are writing a script or performing data tasks (e.g., seeding, migrating content), **default to using the Rebase SDK** (`@rebasepro/client` or `@rebasepro/server`). **NEVER** use `psql` or raw SQL to manipulate data directly unless specifically instructed to do so for low-level debugging. Bypassing the SDK circumvents schema validation, access controls, and lifecycle hooks.
 
 Rebase uses PostgreSQL as its primary database, with Drizzle ORM for type-safe schema management and migrations.
 
@@ -67,20 +67,20 @@ rebase db migrate
 
 | Package | Purpose |
 |---------|---------|
-| `@rebasepro/server-core` | Hono server coordinator, API generation, auth, storage, env validation |
-| `@rebasepro/server-postgresql` | PostgreSQL bootstrapper, data driver, connection helpers, realtime (LISTEN/NOTIFY) |
+| `@rebasepro/server` | Hono server coordinator, API generation, auth, storage, env validation |
+| `@rebasepro/server-postgres` | PostgreSQL bootstrapper, data driver, connection helpers, realtime (LISTEN/NOTIFY) |
 | `@rebasepro/types` | Shared TypeScript type definitions (`PostgresCollectionConfig`, etc.) |
 
 ## Connection Functions
 
-All connection functions are exported from `@rebasepro/server-postgresql`.
+All connection functions are exported from `@rebasepro/server-postgres`.
 
 ### createPostgresDatabaseConnection()
 
 The primary connection factory. Creates a Drizzle-backed Postgres connection with a production-grade pool.
 
 ```typescript
-import { createPostgresDatabaseConnection } from "@rebasepro/server-postgresql";
+import { createPostgresDatabaseConnection } from "@rebasepro/server-postgres";
 
 const { db, pool, connectionString } = createPostgresDatabaseConnection(
     process.env.DATABASE_URL!,
@@ -95,7 +95,7 @@ const { db, pool, connectionString } = createPostgresDatabaseConnection(
 
 **Signature:**
 
-```typescript
+```typescript no-verify
 function createPostgresDatabaseConnection(
     connectionString: string,
     schema?: Record<string, unknown>,
@@ -110,7 +110,7 @@ function createPostgresDatabaseConnection(
 Creates a connection to a read replica for distributing read queries. Uses a default pool max of **10**.
 
 ```typescript
-import { createReadReplicaConnection } from "@rebasepro/server-postgresql";
+import { createReadReplicaConnection } from "@rebasepro/server-postgres";
 
 const readResources = createReadReplicaConnection(
     process.env.DATABASE_READ_URL!,
@@ -120,7 +120,7 @@ const readResources = createReadReplicaConnection(
 
 **Signature:**
 
-```typescript
+```typescript no-verify
 function createReadReplicaConnection(
     connectionString: string,
     schema?: Record<string, unknown>,
@@ -135,7 +135,7 @@ function createReadReplicaConnection(
 Creates a direct (non-pooled) connection for session-level features incompatible with PgBouncer transaction mode: **LISTEN/NOTIFY**, prepared statements, advisory locks. Uses a smaller default pool max of **5**.
 
 ```typescript
-import { createDirectDatabaseConnection } from "@rebasepro/server-postgresql";
+import { createDirectDatabaseConnection } from "@rebasepro/server-postgres";
 
 const directResources = createDirectDatabaseConnection(
     process.env.DATABASE_DIRECT_URL!,
@@ -145,7 +145,7 @@ const directResources = createDirectDatabaseConnection(
 
 **Signature:**
 
-```typescript
+```typescript no-verify
 function createDirectDatabaseConnection(
     connectionString: string,
     schema?: Record<string, unknown>,
@@ -173,7 +173,7 @@ All three connection functions accept an optional `PostgresPoolConfig` for progr
 The `DatabasePoolManager` manages multiple database connection pools dynamically. Used internally by the bootstrapper when `adminConnectionString` is configured — enables cross-database operations like branching and SQL execution against arbitrary databases.
 
 ```typescript
-import { DatabasePoolManager } from "@rebasepro/server-postgresql";
+import { DatabasePoolManager } from "@rebasepro/server-postgres";
 
 const poolManager = new DatabasePoolManager(process.env.ADMIN_CONNECTION_STRING!);
 
@@ -223,8 +223,8 @@ import path from "path";
 import {
     initializeRebaseBackend,
     HonoEnv
-} from "@rebasepro/server-core";
-import { createPostgresDatabaseConnection, createPostgresAdapter } from "@rebasepro/server-postgresql";
+} from "@rebasepro/server";
+import { createPostgresDatabaseConnection, createPostgresAdapter } from "@rebasepro/server-postgres";
 import { tables, enums, relations } from "./schema.generated.js";
 
 const app = new Hono<HonoEnv>();
@@ -266,7 +266,7 @@ server.listen(3001);
 The bootstrapper protocol — database-specific logic is encapsulated in bootstrapper objects:
 
 ```typescript
-import { createPostgresDatabaseConnection, createPostgresBootstrapper } from "@rebasepro/server-postgresql";
+import { createPostgresDatabaseConnection, createPostgresBootstrapper } from "@rebasepro/server-postgres";
 import { tables, enums, relations } from "./schema.generated.js";
 
 const { db, pool, connectionString } = createPostgresDatabaseConnection(process.env.DATABASE_URL!);
@@ -327,12 +327,13 @@ The `initializeRebaseBackend()` coordinator calls bootstrapper methods in this o
 | `auth` | `RebaseAuthConfig \| AuthAdapter` | — | Authentication configuration or external adapter |
 | `storage` | `BackendStorageConfig \| StorageController \| Record<string, ...>` | — | File storage configuration |
 | `history` | `true \| { retention?: number }` | — | Enable entity audit trail. Pass `true` or `{ retention: 90 }` for TTL in days |
-| `defaultSecurityRules` | `SecurityRule[]` | — | Default RLS rules for collections without explicit rules |
 | `enableSwagger` | `boolean` | `true` | Enable OpenAPI/Swagger documentation |
 | `cronPersistence` | `boolean` | `true` | Persist cron execution logs to database |
 | `maxBodySize` | `number` | `10485760` (10MB) | Max request body size in bytes. `0` to disable |
 | `csrf` | `{ origin: string \| string[] \| (origin: string) => boolean }` | — | CSRF protection (opt-in, disabled by default) |
-| `hooks` | `BackendHooks` | — | Backend-level hooks for intercepting admin data |
+| `callbacks` | `CollectionCallbacks` | — | Global lifecycle callbacks applied to every collection, on every data path (REST, realtime, server-side `rebase.data`) |
+| `mode` | `"cms" \| "baas"` | `"cms"` | `baas` derives collections from the live database at boot instead of config files, and turns the schema editor off |
+| `baas` | `BaasOptions` | — | `baas` mode only: `{ unprotectedTables?: "exclude" \| "serve" }`. Default `"exclude"` — a table without RLS has no authorization model, so serving it would hand every row to every logged-in user. `"serve"` overrides, for trusted callers only |
 | `logging` | `{ level?: "error" \| "warn" \| "info" \| "debug" }` | — | Log level configuration |
 
 ### Auth Configuration (RebaseAuthConfig)
@@ -369,13 +370,13 @@ The `initializeRebaseBackend()` coordinator calls bootstrapper methods in this o
 
 ### loadEnv()
 
-The `loadEnv()` function validates all environment variables at startup using Zod. It is exported from `@rebasepro/server-core`.
+The `loadEnv()` function validates all environment variables at startup using Zod. It is exported from `@rebasepro/server`.
 
 **Basic usage:**
 
 ```typescript
 import dotenv from "dotenv";
-import { loadEnv } from "@rebasepro/server-core";
+import { loadEnv } from "@rebasepro/server";
 
 dotenv.config({ path: "../../.env" });
 
@@ -386,7 +387,8 @@ export const env = loadEnv();
 
 ```typescript
 import dotenv from "dotenv";
-import { loadEnv, z } from "@rebasepro/server-core";
+import { loadEnv } from "@rebasepro/server";
+import { z } from "zod";
 
 dotenv.config({ path: "../../.env" });
 
@@ -436,9 +438,9 @@ In non-production mode, `loadEnv()` **auto-generates** ephemeral `JWT_SECRET` an
 | `ALLOW_LOCALHOST_IN_PRODUCTION` | No | `false` | Allow localhost URLs in production env vars |
 | `CORS_ORIGINS` | No (⚠ required in prod) | — | Comma-separated allowed origins |
 | `FRONTEND_URL` | No | — | Frontend URL (used for CORS) |
-| `STORAGE_TYPE` | No | `local` | `local` or `s3` |
+| `STORAGE_TYPE` | No | `local` | `local`, `s3`, or `gcs` |
 | `STORAGE_PATH` | No | — | Path for local file storage |
-| `FORCE_LOCAL_STORAGE` | No | `false` | Suppress local storage warning in production |
+| `FORCE_LOCAL_STORAGE` | No | `false` | Allow local storage in production — **the backend refuses to boot without it** |
 | `S3_BUCKET` | No (if s3) | — | S3 bucket name |
 | `S3_REGION` | No | — | S3 region |
 | `S3_ACCESS_KEY_ID` | No (if s3) | — | S3 access key |
@@ -581,11 +583,11 @@ The `shutdown(timeoutMs?: number)` method (default timeout: 15000ms) performs:
 
 > [!WARNING]
 > **JWT Dual-Package Hazard (Monorepos / pnpm)**
-> When running a backend inside a monorepo workspace (especially with `tsx` and `--preserve-symlinks`), you may encounter a `RebaseApiError: JWT secret not configured. Call configureJwt() first` error. This occurs because Node.js resolves two different module instances of `@rebasepro/server-core`.
+> When running a backend inside a monorepo workspace (especially with `tsx` and `--preserve-symlinks`), you may encounter a `RebaseApiError: JWT secret not configured. Call configureJwt() first` error. This occurs because Node.js resolves two different module instances of `@rebasepro/server`.
 >
 > **Fix:** Explicitly call `configureJwt` in your backend's entry point **before** `initializeRebaseBackend`:
 > ```typescript
-> import { initializeRebaseBackend, configureJwt } from "@rebasepro/server-core";
+> import { initializeRebaseBackend, configureJwt } from "@rebasepro/server";
 >
 > configureJwt({
 >     secret: process.env.JWT_SECRET!,