@rebasepro/agent-skills 0.7.0 → 0.8.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Rebase
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/package.json

@@ -1,9 +1,14 @@
 {
   "name": "@rebasepro/agent-skills",
-  "version": "0.7.0",
+  "version": "0.8.0",
   "private": false,
   "description": "Bundled AI agent skills for Rebase",
   "type": "module",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/rebasepro/rebase.git",
+    "directory": "rebase-agent-skills"
+  },
   "files": [
     "skills/"
   ],
@@ -11,5 +16,6 @@
     ".": "./package.json",
     "./package.json": "./package.json",
     "./skills": "./skills/"
-  }
-}
+  },
+  "scripts": {}
+}

package/skills/rebase-auth/SKILL.md

@@ -5,7 +5,7 @@ description: Guide for setting up and using Rebase Authentication, roles, Row-Le
 
 # Rebase Authentication
 
-Rebase ships a complete, built-in authentication system with JWT sessions, OAuth, MFA/TOTP, API keys, Row-Level Security, and lifecycle hooks — or you can plug in an external provider (Clerk, Auth0, Firebase Auth) via the `AuthAdapter` interface.
+Rebase ships a complete, built-in authentication system with JWT sessions, OAuth, MFA/TOTP, API keys, Row-Level Security, and lifecycle hooks — or you can plug in an external auth system (e.g., Clerk, Auth0, or custom identity providers) via the `AuthAdapter` interface.
 
 > **IMPORTANT FOR AGENTS:** Always read the `rebase-basics` skill first. The auth system is configured inside `initializeRebaseBackend()` which is covered there.
 
@@ -33,7 +33,7 @@ Rebase ships a complete, built-in authentication system with JWT sessions, OAuth
 
 Authentication is configured via the `auth` property of `initializeRebaseBackend()`. It accepts **either** a `RebaseAuthConfig` object (built-in auth) or an `AuthAdapter` (external auth).
 
-> **Auth & multiple data sources.** The built-in auth system (users, sessions, API keys) is bootstrapped on the **default** data source — the auth collection must live there (the backend warns at boot otherwise). **RLS only protects Postgres**: server collections on engines without row-level security (e.g. MongoDB) still require authentication but enforce authorization at the app layer (the backend warns for these). **Direct data sources (e.g. Firestore) bypass Rebase auth entirely** — they're governed by the external backend's own rules/token; use an `AuthAdapter` (e.g. Firebase Auth) to unify identity. See the **rebase-collections** skill for the data-source model.
+> **Auth & multiple data sources.** The built-in auth system (users, sessions, API keys) is bootstrapped on the **default** data source — the auth collection must live there (the backend warns at boot otherwise). **RLS only protects Postgres**: server collections on engines without row-level security (e.g. MongoDB) still require authentication but enforce authorization at the app layer (the backend warns for these). **Direct data sources (e.g. Firestore) bypass Rebase auth entirely** — they're governed by the external backend's own rules/token; use an `AuthAdapter` to unify identity. See the **rebase-collections** skill for the data-source model.
 
 ### RebaseAuthConfig
 
@@ -47,7 +47,7 @@ Authentication is configured via the `auth` property of `initializeRebaseBackend
 | `allowRegistration` | `boolean` | `false` | Enable self-service registration via `POST /auth/register`. |
 | `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<any>[]` | `[]` | Custom OAuth providers (use alongside the shorthand configs below). |
+| `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. |
 | `hooks` | `AuthHooks` | — | [Lifecycle hooks](#auth-lifecycle-hooks) to customize passwords, credentials, and auth events. |
 | `email` | `EmailConfig` | — | [Email configuration](#email-configuration) for password resets, verification, and welcome emails. |
 | `google` | `{ clientId, clientSecret? }` | — | Google OAuth shorthand. |
@@ -351,14 +351,14 @@ hooks: {
 }
 ```
 
-### Example: Firebase Custom Token Bridge
+### Example: External Token Bridge (e.g. custom auth system)
 
 ```typescript
 import admin from "firebase-admin";
 
 hooks: {
   transformAuthResponse: async (response, context) => {
-    // Generate a Firebase Custom Token for the authenticated user
+    // Generate a custom provider token for the authenticated user
     const firebaseToken = await admin.auth().createCustomToken(context.userId);
     return {
       ...response,
@@ -371,7 +371,7 @@ hooks: {
 }
 ```
 
-The frontend can then call `signInWithCustomToken(firebaseToken)` immediately after login.
+The frontend can then call `signInWithCustomToken(providerToken)` immediately after login.
 
 ---
 
@@ -664,7 +664,7 @@ All login/register/OAuth endpoints return:
 }
 ```
 
-> **TIP:** Use the `transformAuthResponse` hook to inject additional tokens (e.g., Firebase Custom Tokens) or metadata into this response. See [Auth Lifecycle Hooks](#auth-lifecycle-hooks).
+> **TIP:** Use the `transformAuthResponse` hook to inject additional tokens (e.g., external system tokens) or metadata into this response. See [Auth Lifecycle Hooks](#auth-lifecycle-hooks).
 
 ### Error Response Format
 
@@ -857,6 +857,21 @@ Requests with the `serviceKey` bypass RLS — they receive admin-level access wi
 
 API keys use a service identity for RLS scoping: `uid: "api-key:{id}"`, `roles: ["service"]` (or `["admin", "service"]` when `admin: true`). They do not inherit the `created_by` user's identity.
 
+### 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):
+
+| Auth Method | `userId` | `roles` | When It Occurs |
+|---|---|---|---|
+| JWT (end-user) | Real user ID (e.g. `"abc123"`) | User's assigned roles (e.g. `["viewer"]`) | Normal authenticated requests |
+| Service Key | `"service"` | `["admin"]` | Server-side `rebase.data` calls, cron jobs, or any request with `Authorization: Bearer <serviceKey>` |
+| API Key (default) | `"api-key:{id}"` | `["service"]` | Machine-to-machine API key requests |
+| API Key (admin) | `"api-key:{id}"` | `["admin", "service"]` | Admin API key requests |
+| 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.
+
 ---
 
 ## Rate Limiting
@@ -917,7 +932,7 @@ const myLimiter = createRateLimiter({
 
 ## Custom Auth Adapters
 
-For external auth systems (Clerk, Auth0, Firebase Auth, or custom JWT), use the `AuthAdapter` interface or the `createCustomAuthAdapter()` helper.
+For external auth systems (Clerk, Auth0, custom providers, or custom JWT), use the `AuthAdapter` interface or the `createCustomAuthAdapter()` helper.
 
 ### AuthAdapter Interface
 
@@ -1241,6 +1256,8 @@ 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.
+
 ### Token Rotation
 
 Refresh tokens are rotated on every use:
@@ -1281,3 +1298,4 @@ All auth endpoints validate input with Zod schemas:
 - 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
+- **Reserved Identities**: `"service"` / `"anon"` / `"api-key:{id}"` — see [Row-Level Security > Reserved System Identities](#reserved-system-identities)

package/skills/rebase-basics/SKILL.md

@@ -388,7 +388,7 @@ When `extend` is provided, the base `rebaseEnvSchema` is merged (`.merge()`) wit
 | `DB_POOL_MAX` | `string` → `number` | `"20"` | No | Max database pool connections |
 | `DB_POOL_IDLE_TIMEOUT` | `string` → `number` | `"30000"` | No | Pool idle timeout (ms) |
 | `DB_POOL_CONNECT_TIMEOUT` | `string` → `number` | `"10000"` | No | Pool connect timeout (ms) |
-| `STORAGE_TYPE` | `"local" \| "s3"` | `"local"` | No | File storage backend type |
+| `STORAGE_TYPE` | `"local" \| "s3" \| "gcs"` | `"local"` | No | File storage backend type |
 | `STORAGE_PATH` | `string` | — | No | Local storage directory path |
 | `FORCE_LOCAL_STORAGE` | `"true" \| "false"` | — | No | Force local storage even in production |
 | `S3_BUCKET` | `string` | — | When S3 | S3 bucket name |
@@ -397,6 +397,9 @@ When `extend` is provided, the base `rebaseEnvSchema` is merged (`.merge()`) wit
 | `S3_SECRET_ACCESS_KEY` | `string` | — | When S3 | S3 secret key |
 | `S3_ENDPOINT` | `string` (URL) | — | No | Custom S3 endpoint (MinIO, R2, etc.) |
 | `S3_FORCE_PATH_STYLE` | `"true" \| "false"` | — | No | Use path-style S3 URLs |
+| `GCS_BUCKET` | `string` | — | When GCS | GCS/Firebase Storage bucket name |
+| `GCS_PROJECT_ID` | `string` | — | When GCS | GCP project ID |
+| `GOOGLE_APPLICATION_CREDENTIALS` | `string` (path) | — | When GCS | Path to GCP service account JSON |
 
 ### Production Validations
 
@@ -438,7 +441,7 @@ import { initializeRebaseBackend, RebaseBackendConfig } from "@rebasepro/server-
 | `bootstrappers` | `BackendBootstrapper[]` | `[]` | Database bootstrappers. Use one per engine for multiple engines in a single instance (e.g. Postgres + MongoDB); mark one `isDefault` |
 | `dataSources` | `DataSourceDefinition[]` | `[]` | Declared data sources (`key`, `engine`, `transport`). Drives capabilities and the server-vs-direct distinction. Collections on a `direct`/`custom` transport are client-only — the backend skips data routes for them. Server engines need no entry |
 | `auth` | `RebaseAuthConfig \| AuthAdapter` | — | Authentication config or pluggable adapter |
-| `storage` | `BackendStorageConfig \| StorageController \| Record<string, ...>` | — | File storage configuration |
+| `storage` | `BackendStorageConfig \| StorageController \| Record<string, ...>` | — | File storage configuration. Supports `"local"`, `"s3"`, and `"gcs"` (GCS/Firebase Storage) backends. Use `Record<string, StorageController>` for multi-backend setups with named sources |
 | `history` | `unknown` | — | Entity history/audit-log configuration |
 | `defaultSecurityRules` | `SecurityRule[]` | — | Default RLS rules for collections without their own |
 | `enableSwagger` | `boolean` | `true` | Enable OpenAPI spec at `/api/docs` and Swagger UI at `/api/swagger` (dev only) |
@@ -546,6 +549,8 @@ await initializeRebaseBackend({
             ? { clientId: env.GOOGLE_CLIENT_ID }
             : undefined,
     },
+    // Single backend: { type: "local" | "s3" | "gcs" }
+    // Multi-backend: Record<string, StorageController> with named sources
     storage: { type: env.STORAGE_TYPE },
     defaultSecurityRules: [
         { operation: "select", access: "public" },

package/skills/rebase-collections/SKILL.md

@@ -367,6 +367,23 @@ avatar: {
 | `postProcess` | `(pathOrUrl) => Promise<string>` | — | Transform saved path/URL after upload |
 | `includeBucketUrl` | `boolean` | `false` | Include bucket URL in saved path |
 | `storeUrl` | `boolean` | `false` | Save download URL instead of storage path |
+| `storageSource` | `string` | `undefined` (default backend) | Named storage source key — routes uploads to a specific backend registered in the backend `storage` map or in `storageSources` on `<Rebase>`. Must match a `StorageSourceDefinition.key`. |
+
+#### Per-Property Backend Binding
+
+When using multiple storage backends, use `storageSource` to route a specific property's uploads to a named backend:
+
+```typescript
+// Route this property's uploads to Firebase Storage
+image: {
+    type: "string",
+    storage: {
+        storageSource: "firebase",
+        storagePath: "products/{entityId}",
+        acceptedFiles: ["image/*"],
+    }
+}
+```
 
 ### ImageResize Options
 
@@ -892,6 +909,30 @@ All callbacks receive a `context` property of type `RebaseCallContext<USER>`. Th
 | `context.storageSource` | `StorageSource` | File storage operations |
 | `context.user` | `USER \| undefined` | Authenticated user (set by backend in server-side callbacks) |
 
+### Reserved `context.user` Values
+
+The `context.user` object is populated by the auth middleware. In server-side callbacks, it contains one of these reserved identities:
+
+| Caller | `context.user.uid` | `context.user.roles` |
+|---|---|---|
+| JWT-authenticated end-user | Real user ID (e.g. `"abc123"`) | Their assigned roles (e.g. `["viewer"]`) |
+| Server-side `rebase.data` (cron jobs, custom functions) | `"service"` | `["admin"]` |
+| API key (default) | `"api-key:{id}"` | `["service"]` |
+| API key (admin) | `"api-key:{id}"` | `["admin", "service"]` |
+| Anonymous (no auth, `requireAuth: false`) | `"anon"` | `["anon"]` |
+| Anonymous REST (no token) | `undefined` | N/A — `context.user` is not set; only the DataDriver is scoped |
+
+> **IMPORTANT FOR AGENTS:** `rebase.data` calls (used in cron jobs, afterSave side-effects, custom functions) go through the full middleware pipeline with the service key, so callbacks see `uid: "service"`, `roles: ["admin"]`. Use this to gate behavior — e.g., skip PII masking for admin/service reads:
+>
+> ```typescript
+> afterRead: async ({ entity, context }) => {
+>     // Server-side reads (cron jobs, admin) see real values
+>     if (context.user?.roles?.includes("admin")) return entity;
+>     // End-user reads get masked values
+>     return { ...entity, values: { ...entity.values, email: "***@***.***" } };
+> }
+> ```
+
 > **WARNING FOR AGENTS:** Do NOT confuse `RebaseCallContext` (available in callbacks, both client & server) with `RebaseContext` (full context available only on the frontend, includes `authController`, `snackbarController`, `sideEntityController`, etc.). Entity callbacks always receive `RebaseCallContext`.
 
 ### Callback Example

package/skills/rebase-cron-jobs/SKILL.md

@@ -230,6 +230,11 @@ interface CronJobContext {
 | `log` | `(...args: unknown[]) => void` | Logger whose output is captured in `CronJobLogEntry.logs`. Use like `console.log`. |
 | `client` | `RebaseClient` | Admin-level client for CRUD, auth, storage, and any SDK operation. |
 
+> **IMPORTANT FOR AGENTS:** `ctx.client` authenticates as the **service identity** (`userId: "service"`, `roles: ["admin"]`). All data operations through `ctx.client` go through the full REST middleware pipeline (including DataHooks and Entity Callbacks). This means:
+> - Entity Callbacks will see `context.user.uid === "service"` and `context.user.roles` containing `"admin"`
+> - If your callbacks implement PII masking or role-based filtering, they should check for admin/service roles and skip masking for server-internal reads
+> - The service identity bypasses RLS policies
+
 ### Using `ctx.client`
 
 `ctx.client` is the same `RebaseClient` returned by `createRebaseClient()`. It supports all SDK operations:

package/skills/rebase-custom-functions/SKILL.md

@@ -118,6 +118,27 @@ app.get("/", async (c) => {
 export default app;
 ```
 
+### Reserved Identity Values in `c.get("user")`
+
+The `user` object set by the auth middleware uses reserved values for system identities:
+
+| Auth Method | `user.userId` | `user.roles` |
+|---|---|---|
+| JWT (end-user) | Real user ID | User's assigned roles |
+| Service Key | `"service"` | `["admin"]` |
+| API Key (default) | `"api-key:{id}"` | `["service"]` |
+| API Key (admin) | `"api-key:{id}"` | `["admin", "service"]` |
+| Anonymous | `"anon"` | `["anon"]` |
+
+> **TIP:** Use these to differentiate internal vs. external callers in your custom functions:
+> ```typescript
+> app.get("/sensitive-data", async (c) => {
+>     const user = c.get("user");
+>     const isInternal = user?.userId === "service" || user?.roles?.includes("admin");
+>     // Return full or masked data based on identity
+> });
+> ```
+
 ## Invoking Functions from the Frontend
 
 > **CRITICAL FOR AGENTS**: When calling custom backend functions from the frontend, **ALWAYS** use `client.functions.invoke()`. **NEVER** use raw `fetch()`, manually construct URLs, or manually extract auth tokens from `localStorage`. The SDK handles all of this automatically.

package/skills/rebase-deployment/SKILL.md

@@ -367,7 +367,7 @@ All variables recognized by the base `rebaseEnvSchema`:
 | `DB_POOL_CONNECT_TIMEOUT` | `string` → `number` | No | `"10000"` → `10000` | Connection timeout (ms) |
 | `DATABASE_DIRECT_URL` | `string` (URL) | No | — | Direct database URL (bypasses pooler) |
 | `DATABASE_READ_URL` | `string` (URL) | No | — | Read replica database URL |
-| `STORAGE_TYPE` | `enum` | No | `"local"` | `"local"` or `"s3"` |
+| `STORAGE_TYPE` | `enum` | No | `"local"` | `"local"`, `"s3"`, or `"gcs"` |
 | `STORAGE_PATH` | `string` | No | — | Local file storage directory |
 | `FORCE_LOCAL_STORAGE` | `optionalBoolString` | No | `undefined` → `false` | Suppress local-storage-in-production warning |
 | `S3_BUCKET` | `string` | If S3 | — | S3 bucket name |
@@ -376,6 +376,9 @@ All variables recognized by the base `rebaseEnvSchema`:
 | `S3_SECRET_ACCESS_KEY` | `string` | If S3 | — | S3 secret key |
 | `S3_ENDPOINT` | `string` (URL) | No | — | Custom S3 endpoint (MinIO, R2) |
 | `S3_FORCE_PATH_STYLE` | `optionalBoolString` | No | `undefined` → `false` | Use path-style S3 URLs (required for MinIO) |
+| `GCS_BUCKET` | `string` | If GCS | — | Google Cloud Storage bucket name |
+| `GCS_PROJECT_ID` | `string` | If GCS | — | GCP project ID for GCS |
+| `GOOGLE_APPLICATION_CREDENTIALS` | `string` | If GCS (non-GCP) | — | Path to GCP service account JSON key file (not needed on GCP with default credentials) |
 
 ### Zod Type Helpers
 
@@ -573,7 +576,13 @@ Internet → Cloud Run (HTTPS, auto-scaling) → Cloud SQL PostgreSQL
      --allow-unauthenticated
    ```
 4. **Custom Domain** — Map a custom domain in Cloud Run settings. Cloud Run provides HTTPS automatically.
-5. **File Storage** — Use `STORAGE_TYPE=s3` with a GCS bucket via the S3-compatible interop endpoint, or use a dedicated S3 provider like Cloudflare R2.
+5. **File Storage** — Use native GCS support with `STORAGE_TYPE=gcs`:
+   ```bash
+   STORAGE_TYPE=gcs
+   GCS_BUCKET=your-rebase-uploads
+   GCS_PROJECT_ID=your-gcp-project-id
+   ```
+   On Cloud Run, the default service account credentials are used automatically — no key file needed. Alternatively, you can fall back to `STORAGE_TYPE=s3` with the GCS S3-compatible interop endpoint.
 
 ### Cloud SQL Auth Proxy (Connection String)
 

package/skills/rebase-sdk/SKILL.md

@@ -437,6 +437,29 @@ const { items, nextPageToken } = await rebase.storage.listObjects('prefix/', {
 });
 ```
 
+### Multi-Backend Storage
+
+`rebase.storage` accesses the **default** storage source. For multi-backend setups (e.g. S3 + GCS/Firebase), collection properties can specify `storage.storageSource` in their schema to route uploads to a named backend.
+
+On the frontend, register direct storage sources via the `storageSources` prop on `<Rebase>`:
+
+```tsx
+import { getStorage } from "firebase/storage";
+
+const firebaseStorageSource = getStorage(firebaseApp);
+
+<Rebase
+    client={rebaseClient}
+    storageSources={[
+        { key: "firebase", engine: "firebase", transport: "direct", source: firebaseStorageSource }
+    ]}
+>
+    {children}
+</Rebase>
+```
+
+The system resolves the correct source per-property via `StorageSourcesContext` (mirroring `DataSourcesContext`). Properties bound to a `direct` storage source bypass the Rebase backend and upload/download directly to the provider (e.g. Firebase Storage), while `server` sources route through the Rebase API with a `?storageId` query parameter for backend routing.
+
 ## Custom Functions
 
 Invoke custom server-side functions defined in the backend:

package/skills/rebase-security/SKILL.md

@@ -136,6 +136,14 @@ 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:
+> - `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: "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")`.
+
 ---
 
 ## Layer 2: API Key Permission Guard
@@ -602,5 +610,6 @@ Use this checklist when setting up security for a Rebase project:
 - **REST API Generator**: `packages/server-core/src/api/rest/api-generator.ts` — DataHooks integration
 - **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
 - **Auth Configuration**: See `rebase-auth` skill → Server-Side Configuration section

package/skills/rebase-storage/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: rebase-storage
-description: Guide for setting up and using file storage in Rebase. Use this skill when the user needs to configure S3 or local file storage, handle file uploads, TUS resumable uploads, image transformations, or integrate the media manager.
+description: Guide for setting up and using file storage in Rebase. Use this skill when the user needs to configure S3, Google Cloud Storage (GCS), or local file storage, handle file uploads, TUS resumable uploads, image transformations, multi-backend frontend storage sources, or integrate the media manager.
 ---
 
 # Rebase Storage
 
-Rebase provides built-in file storage with support for local filesystem and S3-compatible services, TUS v1.0.0 resumable uploads, on-the-fly image transformation, and a multi-backend registry.
+Rebase provides built-in file storage with support for local filesystem, S3-compatible services, and Google Cloud Storage (GCS), TUS v1.0.0 resumable uploads, on-the-fly image transformation, a multi-backend registry, and frontend storage sources.
 
 > **IMPORTANT FOR AGENTS:** Always read the `rebase-basics` skill first before using this skill. Storage requires a running Rebase backend with `initializeRebaseBackend()`.
 
@@ -15,7 +15,7 @@ The `storage` option in `initializeRebaseBackend()` accepts three forms:
 
 | Form | Type | Description |
 |------|------|-------------|
-| Single config | `BackendStorageConfig` | `{ type: 'local' | 's3', ... }` — creates a single `(default)` backend |
+| Single config | `BackendStorageConfig` | `{ type: 'local' | 's3' | 'gcs', ... }` — creates a single `(default)` backend |
 | Single controller | `StorageController` | A custom controller instance — registered as `(default)` |
 | Multi-backend map | `Record<string, BackendStorageConfig \| StorageController>` | Named backends, first becomes `(default)` if no `(default)` key |
 
@@ -44,6 +44,19 @@ The `storage` option in `initializeRebaseBackend()` accepts three forms:
 | `allowedMimeTypes` | `string[]` | `undefined` (all allowed) | Restrict uploads to these MIME types |
 | `signedUrlExpiration` | `number` | `3600` | Signed URL expiry in seconds |
 
+### GCSStorageConfig
+
+| Property | Type | Default | Description |
+|----------|------|---------|-------------|
+| `type` | `"gcs"` | — | **Required.** Must be `"gcs"` |
+| `bucket` | `string` | — | **Required.** GCS bucket name |
+| `projectId` | `string` | `undefined` | Google Cloud project ID (auto-detected from credentials if omitted) |
+| `maxFileSize` | `number` | `52428800` (50 MB) | Maximum file size in bytes |
+| `allowedMimeTypes` | `string[]` | `undefined` (all allowed) | Restrict uploads to these MIME types |
+| `signedUrlExpiration` | `number` | `3600` | Signed URL expiry in seconds |
+
+> **IMPORTANT FOR AGENTS:** GCS requires `@google-cloud/storage` as a peer dependency. Install it: `pnpm add @google-cloud/storage`. Authentication uses Application Default Credentials — set the `GOOGLE_APPLICATION_CREDENTIALS` environment variable to point to a service account key file, or rely on the default credentials when running on GCP.
+
 ### StorageRoutesConfig
 
 These options are set internally when mounting routes but are derived from the backend config:
@@ -93,7 +106,7 @@ Local storage includes **path traversal protection** — any resolved path that
 
 ### S3-Compatible Storage
 
-Works with AWS S3, MinIO, DigitalOcean Spaces, Cloudflare R2, Hetzner Object Storage, Backblaze B2, and any S3-compatible service. GCS also works via its S3-compatible interoperability API.
+Works with AWS S3, MinIO, DigitalOcean Spaces, Cloudflare R2, Hetzner Object Storage, Backblaze B2, and any S3-compatible service.
 
 ```typescript
 const backend = await initializeRebaseBackend({
@@ -118,6 +131,28 @@ The S3 controller:
 - Supports `s3://` and `gs://` URL schemes in key parameters for backward compatibility
 - Flattens nested metadata to string values (S3 requirement)
 
+### Google Cloud Storage (GCS)
+Native Google Cloud Storage support via the `@google-cloud/storage` SDK. This is the preferred approach for GCS — no S3 interop layer needed. (Also works with Firebase Storage buckets, which are GCS buckets under the hood).
+
+```typescript
+const backend = await initializeRebaseBackend({
+    server, app,
+    bootstrappers: [/* ... */],
+    storage: {
+        type: "gcs",
+        bucket: process.env.GCS_BUCKET!,
+        projectId: process.env.GCS_PROJECT_ID, // optional, auto-detected on GCP
+    },
+});
+```
+
+The GCS controller:
+- Uses `@google-cloud/storage` natively (no S3 interop overhead)
+- Authenticates via Application Default Credentials (`GOOGLE_APPLICATION_CREDENTIALS`)
+- Maps the logical bucket name `"default"` to the configured GCS bucket
+- Supports `gs://` URL scheme in key parameters
+- Generates signed URLs using GCS's native signed URL mechanism
+
 ### Multiple Storage Backends
 
 Rebase supports multiple storage backends simultaneously via the `StorageRegistry`:
@@ -138,7 +173,7 @@ const backend = await initializeRebaseBackend({
 });
 ```
 
-> **IMPORTANT FOR AGENTS:** If no `"(default)"` key is provided, the first entry is automatically registered as the default (with a console warning). The REST API routes always use the default controller. Use `storageRegistry.get("media")` or `storageRegistry.getOrDefault("media")` to access named backends programmatically.
+> **IMPORTANT FOR AGENTS:** If no `"(default)"` key is provided, the first entry is automatically registered as the default (with a console warning). The REST API routes use the default controller unless a `?storageId=<key>` query parameter is provided (see [REST API Endpoints](#rest-api-endpoints)). Use `storageRegistry.get("media")` or `storageRegistry.getOrDefault("media")` to access named backends programmatically.
 
 ### StorageRegistry API
 
@@ -156,7 +191,7 @@ The `StorageRegistry` interface:
 
 ### Custom Storage Providers
 
-Implement the `StorageController` interface for unsupported providers (Azure Blob, native GCS SDK, etc.):
+GCS is now built-in (see [Google Cloud Storage (GCS)](#google-cloud-storage-gcs)). Implement the `StorageController` interface for other unsupported providers (Azure Blob, etc.):
 
 ```typescript
 interface StorageController {
@@ -185,7 +220,7 @@ The backend validates storage-related environment variables via a Zod schema:
 
 | Variable | Type | Default | Description |
 |----------|------|---------|-------------|
-| `STORAGE_TYPE` | `"local" \| "s3"` | `"local"` | Storage provider type |
+| `STORAGE_TYPE` | `"local" \| "s3" \| "gcs"` | `"local"` | Storage provider type |
 | `STORAGE_PATH` | `string` | `"./uploads"` | Base path for local storage / TUS temp directory |
 | `FORCE_LOCAL_STORAGE` | `"true" \| "false"` | `false` | Suppress the production warning for local storage |
 | `S3_BUCKET` | `string` | — | S3 bucket name |
@@ -194,8 +229,12 @@ The backend validates storage-related environment variables via a Zod schema:
 | `S3_SECRET_ACCESS_KEY` | `string` | — | S3 secret access key |
 | `S3_ENDPOINT` | `string` (URL) | — | Custom S3-compatible endpoint |
 | `S3_FORCE_PATH_STYLE` | `"true" \| "false"` | — | Enable path-style URLs |
+| `GCS_BUCKET` | `string` | — | GCS bucket name |
+| `GCS_PROJECT_ID` | `string` | — | Google Cloud project ID (auto-detected on GCP) |
+| `GOOGLE_APPLICATION_CREDENTIALS` | `string` (path) | — | Path to GCP service account key JSON file |
 
 ```env
+# S3 example
 STORAGE_TYPE=s3
 S3_BUCKET=my-bucket
 S3_REGION=us-east-1
@@ -203,12 +242,35 @@ S3_ACCESS_KEY_ID=AKIA...
 S3_SECRET_ACCESS_KEY=...
 S3_ENDPOINT=https://minio.example.com    # Optional: for MinIO, R2, etc.
 S3_FORCE_PATH_STYLE=true                 # Optional: for MinIO
+
+# GCS example
+STORAGE_TYPE=gcs
+GCS_BUCKET=my-gcs-bucket
+GCS_PROJECT_ID=my-gcp-project             # Optional: auto-detected on GCP
+GOOGLE_APPLICATION_CREDENTIALS=/path/to/service-account.json
 ```
 
 ## REST API Endpoints
 
 All storage routes are mounted at `/api/storage` by default. Write operations require authentication when `requireAuth` is `true` (the default). Read operations also require authentication unless `publicRead` is `true`.
 
+### Multi-Backend Routing (`storageId`)
+
+All storage endpoints accept a `?storageId=<key>` query parameter that routes the request to a specific named backend in the `StorageRegistry`. For multipart uploads (`POST /api/storage/upload`), the `storageId` can also be sent as a form field.
+
+If `storageId` is omitted, the request is routed to the `(default)` backend.
+
+```
+# Upload to the "media" backend
+POST /api/storage/upload?storageId=media
+
+# Download from the "media" backend
+GET /api/storage/file/images/photo.jpg?storageId=media
+
+# List files in the "media" backend
+GET /api/storage/list?prefix=images/&storageId=media
+```
+
 ### Standard Endpoints
 
 | Method | Endpoint | Auth | Description |
@@ -241,6 +303,7 @@ Upload a file via `multipart/form-data`.
 | `file` | `File` | Yes | The file to upload |
 | `key` | `string` | No | Storage key/path. Falls back to original filename, then `"unnamed"` |
 | `bucket` | `string` | No | Target bucket name |
+| `storageId` | `string` | No | Route to a named backend (alternative to `?storageId` query param) |
 | `metadata_*` | `string` | No | Custom metadata keys prefixed with `metadata_` |
 
 **Response** (201):
@@ -562,6 +625,24 @@ Transformed responses include `Cache-Control: public, max-age=31536000, immutabl
 
 The `@rebasepro/client` package provides a `StorageSource` interface via `createStorage(transport)`. These methods are available on `client.storage` (or through the React/Studio hooks).
 
+All SDK methods accept an optional `storageId` parameter (passed as a query parameter) to route the request to a specific named backend:
+
+```typescript
+// Upload to a specific backend
+const result = await client.storage.putObject({
+    file: myFile,
+    key: "products/images/photo.jpg",
+    storageId: "media",   // routes to the "media" backend
+});
+
+// Get signed URL from a specific backend
+const config = await client.storage.getSignedUrl(
+    "products/images/photo.jpg",
+    "default",     // bucket
+    { storageId: "media" }
+);
+```
+
 ### putObject
 
 Upload a file.
@@ -662,7 +743,8 @@ const productsCollection: PostgresCollection = {
             name: "Product Image",
             type: "string",
             storage: {
-                storagePath: "products/images",
+                storageSource: "external-source",
+                storagePath: "products/{entityId}",
                 acceptedFiles: ["image/*"],
                 maxSize: 5 * 1024 * 1024, // 5MB
             }
@@ -673,6 +755,7 @@ const productsCollection: PostgresCollection = {
             of: {
                 type: "string",
                 storage: {
+                    storageSource: "media",              // routes to the "media" backend
                     storagePath: "products/documents",
                     acceptedFiles: ["application/pdf", "application/msword"],
                 }
@@ -682,6 +765,87 @@ const productsCollection: PostgresCollection = {
 };
 ```
 
+The `storageSource` field maps to a named backend registered in the `StorageRegistry` (server-side) or in the `storageSources` prop (client-side). When omitted, the `(default)` backend is used.
+
+### StorageConfig Properties
+
+| Property | Type | Description |
+|----------|------|-------------|
+| `storageSource` | `string` | Named backend to route uploads to (optional, defaults to `(default)`) |
+| `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 |
+
+## Frontend Storage Sources
+
+The `<Rebase>` component accepts a `storageSources` prop to register client-side storage sources, following the same pattern as `dataSources` for databases. This enables **direct** (client-to-provider) file operations, bypassing the Rebase backend.
+
+### Registering Storage Sources
+
+```tsx
+import type { RebaseStorageSource } from "@rebasepro/core";
+import { myExternalStorageSource } from "./my-external-storage";
+
+<Rebase
+    client={rebaseClient}
+    storageSources={[
+        {
+            key: "external",
+            engine: "external",
+            transport: "direct",
+            source: myExternalStorageSource,
+        },
+        {
+            key: "media",
+            engine: "s3",
+            transport: "server",   // proxied through the Rebase backend
+            label: "Media Storage",
+        },
+    ]}
+>
+    {children}
+</Rebase>
+```
+
+### StorageSourceDefinition
+
+| Property | Type | Description |
+|----------|------|-------------|
+| `key` | `string` | **Required.** Unique identifier for this storage source |
+| `engine` | `string` | **Required.** Storage engine type (e.g., `"firebase"`, `"s3"`, `"gcs"`, `"local"`) |
+| `transport` | `"server" \| "direct"` | **Required.** `"server"` routes through the backend; `"direct"` talks to the provider from the client |
+| `source` | `StorageSource` | The client-side `StorageSource` implementation (required when `transport` is `"direct"`) |
+| `label` | `string` | Optional human-readable label for the UI |
+
+### StorageSourcesContext
+
+Registered storage sources are exposed to the component tree via `StorageSourcesContext`, mirroring the `DataSourcesContext` pattern:
+
+```typescript
+import { useStorageSources } from "@rebasepro/core";
+
+function MyUploadComponent() {
+    const storageSources = useStorageSources();
+
+    // Get a specific source
+    const externalSource = storageSources.find(s => s.key === "external");
+
+    // Use it for direct uploads
+    if (externalSource?.source) {
+        await externalSource.source.putObject({ file, key: "photos/image.jpg" });
+    }
+}
+```
+
+### Direct vs Server Transport
+
+| Transport | Description | Use Case |
+|-----------|-------------|----------|
+| `"server"` | File operations are proxied through the Rebase backend REST API | S3, GCS, or local backends managed by the server |
+| `"direct"` | File operations go directly from the client to the storage provider | External cloud storage, or any provider with client-side SDKs |
+
+> **IMPORTANT FOR AGENTS:** Direct transport sources must provide a `source` property implementing the `StorageSource` interface. Server transport sources use the built-in SDK transport and only need `key` and `engine`.
+
 ## Storage Browser (Studio)
 
 The `@rebasepro/studio` package includes a built-in `StorageView` component:

package/skills/rebase-ui-components/SKILL.md

@@ -848,6 +848,97 @@ Key props: `data`, `columns` (array of `VirtualTableColumn`), `cellRenderer`, `o
 
 See `VirtualTableProps` and `VirtualTableColumn` types for full API.
 
+#### Generic Editable Tables & Cell Selection
+
+`@rebasepro/ui` includes a generic, high-performance selection engine and primitive cell inputs that allow you to construct keyboard-navigable editable grid tables without any Rebase database dependencies.
+
+**Selection Hooks & Context:**
+* `createVirtualTableSelectionStore()` — Instantiates a selection store tracking active selection by `rowId` and `columnKey`. It uses `useSyncExternalStore` so that selection changes only trigger re-renders on the active cell (preventing whole-table lag).
+* `VirtualTableSelectionProvider` — React context provider to pass down the selection store.
+* `useVirtualTableSelection()` — Hook to access the selection store and triggers inside custom cells.
+* `useVirtualTableCellSelected(store, columnKey, rowId)` — Returns `boolean` indicating if this cell is currently focused.
+
+**Generic Cell Inputs:**
+* `VirtualTableInput` — Auto-growing, debounced multiline/single text input.
+* `VirtualTableNumberInput` — Constrained numeric input.
+* `VirtualTableSwitch` — Small boolean switch toggle.
+* `VirtualTableDateField` — Decoupled Date/DateTime picker (accepts `locale`, `timezone`, `mode`).
+* `VirtualTableSelect` — Option-based single/multi dropdown list using chips. Takes `options: { value, label, color? }[]`.
+
+**Example Custom Editable Table:**
+```tsx
+import React, { useMemo, useState, useCallback } from "react";
+import { 
+    VirtualTable, 
+    createVirtualTableSelectionStore, 
+    VirtualTableSelectionProvider, 
+    useVirtualTableCellSelected, 
+    useVirtualTableSelection,
+    VirtualTableInput 
+} from "@rebasepro/ui";
+
+function EditableCell({ rowId, columnKey, value, onUpdate }) {
+    const { selectionStore } = useVirtualTableSelection();
+    const selected = useVirtualTableCellSelected(selectionStore, columnKey, rowId);
+
+    return (
+        <div 
+            className="w-full h-full flex items-center px-2 cursor-text"
+            onClick={(e) => selectionStore.select({ 
+                rowId, 
+                columnKey, 
+                cellRect: e.currentTarget.getBoundingClientRect(),
+                width: e.currentTarget.offsetWidth,
+                height: e.currentTarget.offsetHeight
+            })}
+        >
+            <VirtualTableInput
+                value={value}
+                updateValue={onUpdate}
+                focused={selected}
+                disabled={false}
+                multiline={false}
+            />
+        </div>
+    );
+}
+
+export function MyEditableGrid() {
+    const [data, setData] = useState([
+        { id: "row-1", name: "Project Alpha" },
+        { id: "row-2", name: "Project Beta" }
+    ]);
+
+    const selectionStore = useMemo(() => createVirtualTableSelectionStore(), []);
+
+    const updateCell = useCallback((rowId: string, value: string) => {
+        setData(prev => prev.map(row => row.id === rowId ? { ...row, name: value } : row));
+    }, []);
+
+    const columns = [
+        { key: "name", title: "Name", width: 300 }
+    ];
+
+    return (
+        <VirtualTableSelectionProvider store={selectionStore}>
+            <VirtualTable
+                data={data}
+                columns={columns}
+                rowHeight={52}
+                cellRenderer={({ rowData, column }) => (
+                    <EditableCell
+                        rowId={rowData.id}
+                        columnKey={column.key}
+                        value={rowData.name}
+                        onUpdate={(val) => updateCell(rowData.id, val || "")}
+                    />
+                )}
+            />
+        </VirtualTableSelectionProvider>
+    );
+}
+```
+
 ### ToggleButtonGroup
 
 Single-select button group for toggling between options.