@rebasepro/cli 0.11.1-canary.gfd39654 → 0.12.0

package/dist/manifest.d.ts

@@ -1,4 +1,4 @@
-import type { ManagedCompatibility, RebaseAppConfig, RebaseBackendAppConfig, RebaseProjectManifest } from "@rebasepro/types";
+import { type ManagedCompatibility, type RebaseAppConfig, type RebaseBackendAppConfig, type RebaseProjectManifest } from "@rebasepro/types";
 /** Runtime range written into new manifests. */
 export declare const CURRENT_RUNTIME_RANGE = "^1";
 /** Conventional locations, matching what `rebase init` scaffolds. */
@@ -36,10 +36,12 @@ export declare function validateManifest(raw: unknown): {
  * the manifest a no-op for existing projects: the synthesized result is what
  * they would have written by hand.
  *
- * An ejected backend — one with its own `src/index.ts` entrypoint — is reported
- * as a `custom` app rather than a `backend` app. That is not a downgrade; it is
- * an accurate description, and it is what keeps such a project deploying exactly
- * as it does today.
+ * The backend's `runtime` is inferred from whether the repository declares a
+ * **Dockerfile** — the thing that actually builds an image — and from nothing
+ * else. It used to be inferred from the presence of `backend/src/index.ts`,
+ * which every scaffolded project had whether or not it wanted its own server, so
+ * projects predating the manifest silently landed on the custom runtime and paid
+ * for it (see `docs/cloud-deploy-workspace-vendoring.md`).
  */
 export declare function synthesizeManifest(projectRoot: string): RebaseProjectManifest;
 export declare function manifestPath(projectRoot: string): string;
@@ -72,12 +74,29 @@ export declare function buildableApps(manifest: RebaseProjectManifest): {
  * verdict.
  */
 export declare function assessManagedCompatibility(manifest: RebaseProjectManifest): ManagedCompatibility;
-/** Resolve a backend app's directories against the conventions it omits. */
-export declare function resolveBackendPaths(app: RebaseBackendAppConfig): {
+/**
+ * Resolve a backend app's directories against the conventions it omits.
+ *
+ * `hasCollections` replaces the old `mode: "cms" | "baas"` field. Where the
+ * collections come from was never an independent choice: either they are
+ * declared in code and the bundle ships them, or they are not and the runtime
+ * introspects the live database at boot. Declaring it separately only created
+ * the contradictory state — code-first declared, no collections anywhere.
+ *
+ * `hasConfig` is deliberately a **separate** question. A headless project has no
+ * `config/collections`, but it may still ship a config package — that is where
+ * the `storageAuthorize` hook lives, and storage is not under row-level
+ * security, so without one the server refuses to boot with storage enabled.
+ * Collapsing the two would leave a headless project nowhere to put it.
+ */
+export declare function resolveBackendPaths(app: RebaseBackendAppConfig, projectRoot: string): {
     config: string;
     functions: string;
     crons: string;
     schema: string;
     usersCollection: string;
-    mode: "cms" | "baas";
+    /** Whether a config package exists — hooks, storage authorization. */
+    hasConfig: boolean;
+    /** Whether collections are declared in code, under `<config>/collections`. */
+    hasCollections: boolean;
 };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rebasepro/cli",
-  "version": "0.11.1-canary.gfd39654",
+  "version": "0.12.0",
   "description": "Developer tools for Rebase projects",
   "main": "./dist/index.es.js",
   "module": "./dist/index.es.js",
@@ -31,12 +31,12 @@
     "execa": "^9.6.1",
     "inquirer": "14.0.2",
     "jiti": "^2.7.0",
-    "@rebasepro/agent-skills": "0.11.1-canary.gfd39654",
-    "@rebasepro/client": "0.11.1-canary.gfd39654",
-    "@rebasepro/codegen": "0.11.1-canary.gfd39654",
-    "@rebasepro/server": "0.11.1-canary.gfd39654",
-    "@rebasepro/server-postgres": "0.11.1-canary.gfd39654",
-    "@rebasepro/types": "0.11.1-canary.gfd39654"
+    "@rebasepro/codegen": "0.12.0",
+    "@rebasepro/agent-skills": "0.12.0",
+    "@rebasepro/server": "0.12.0",
+    "@rebasepro/types": "0.12.0",
+    "@rebasepro/client": "0.12.0",
+    "@rebasepro/server-postgres": "0.12.0"
   },
   "devDependencies": {
     "@types/node": "^25.9.3",

package/runtime/dev-server.mjs

@@ -31,7 +31,6 @@ const bundle = createSourceBundle({
     functions: optional(process.env.REBASE_DEV_FUNCTIONS),
     crons: optional(process.env.REBASE_DEV_CRONS),
     schema: optional(process.env.REBASE_DEV_SCHEMA),
-    mode: process.env.REBASE_DEV_MODE === "baas" ? "baas" : "cms",
     app: optional(process.env.REBASE_DEV_APP)
 });
 

package/templates/{template/backend → eject}/Dockerfile

@@ -1,10 +1,22 @@
-# ─── Multi-stage production Dockerfile for the Rebase backend ─────────
-# Produces a minimal image (~150MB) with only the runtime needed.
+# ─── Your image ───────────────────────────────────────────────────────
+#
+# `rebase eject` wrote this file, and it is yours now — nothing regenerates or
+# updates it. The platform runtime is no longer involved: this image compiles
+# and runs backend/src/index.ts, so CORS, auth wiring, storage and shutdown are
+# configured there rather than by the runtime, and Rebase runtime upgrades do
+# not reach this project.
+#
+# Assumes pnpm, which is what `rebase init` scaffolds a workspace for. On npm,
+# swap the three pnpm lines below for `npm ci` and `npm run build --workspace`.
 #
 # Build context: the project root (where pnpm-workspace.yaml lives)
 # Usage:
-#   docker build -t my-app-backend -f backend/Dockerfile .
-#   docker run -p 3001:3001 --env-file .env my-app-backend
+#   docker build -t my-app .
+#   docker compose -f docker-compose.custom.yml up
+#
+# The managed alternative — no image to build, your project mounted into the
+# published runtime — is docker-compose.yml, which is still here and still
+# works if you change `runtime` back to "managed" in rebase.json.
 
 # ── Stage 1: Install + Build ─────────────────────────────────────────
 FROM node:22-alpine AS builder

package/templates/{template → eject}/backend/src/env.ts

@@ -19,7 +19,6 @@ const __dirname = path.dirname(__filename);
  */
 function findEnvFile(startDir: string): string | undefined {
     let dir = startDir;
-    // eslint-disable-next-line no-constant-condition
     while (true) {
         const candidate = path.join(dir, ".env");
         if (fs.existsSync(candidate)) return candidate;

package/templates/{template → eject}/backend/src/index.ts

@@ -12,6 +12,8 @@ import {
     HonoEnv,
     listenWithPortRetry,
     cleanupDevPortFile,
+    loadDeclaredStorageSources,
+    resolveStorageSources,
     logger
 } from "@rebasepro/server";
 import { createPostgresDatabaseConnection, createPostgresAdapter } from "@rebasepro/server-postgres";
@@ -23,6 +25,13 @@ import usersCollection from "../../config/collections/users.js";
 const __filename = fileURLToPath(import.meta.url);
 const __dirname = path.dirname(__filename);
 
+// Which buckets this project has, read from the `storage` block of its own
+// `rebase.json`. Declared there rather than here so the platform, the console
+// and this process all read one list — a custom image ships the repository, so
+// the file it already contains is the natural place for it. Absent means one
+// default source, configured from the plain S3_*/GCS_* variables.
+const storageSources = loadDeclaredStorageSources(__dirname);
+
 // ─── App ─────────────────────────────────────────────────────────────
 const app: Hono<HonoEnv> = new Hono<HonoEnv>();
 
@@ -128,33 +137,21 @@ pass: env.SMTP_PASS! }
         // production — the upload routes answer 501 STORAGE_NOT_CONFIGURED —
         // rather than writing to the container filesystem, which is erased on
         // every restart and redeploy. Uploads that fail loudly are recoverable;
-        // uploads that succeed into a disk about to be wiped are not.
-        // Local disk stays the default in development, where it is what you want.
-        storage: env.STORAGE_TYPE === "s3"
-            ? {
-                type: "s3",
-                bucket: env.S3_BUCKET!,
-                region: env.S3_REGION || "auto",
-                accessKeyId: env.S3_ACCESS_KEY_ID || "",
-                secretAccessKey: env.S3_SECRET_ACCESS_KEY || "",
-                endpoint: env.S3_ENDPOINT,
-                forcePathStyle: env.S3_FORCE_PATH_STYLE
-            }
-            : env.STORAGE_TYPE === "gcs"
-                ? {
-                    type: "gcs",
-                    bucket: env.GCS_BUCKET!,
-                    projectId: env.GCS_PROJECT_ID,
-                    keyFilename: env.GCS_KEY_FILENAME
-                }
-                // Set FORCE_LOCAL_STORAGE=true only if this deployment really
-                // does have a durable volume mounted at STORAGE_PATH.
-                : isProduction && !env.FORCE_LOCAL_STORAGE
-                    ? undefined
-                    : {
-                        type: "local",
-                        basePath: env.STORAGE_PATH || path.resolve(__dirname, "../../uploads")
-                    },
+        // uploads that succeed into a disk about to be wiped are not. That rule
+        // lives in the runtime, which drops a `local` backend in production
+        // unless FORCE_LOCAL_STORAGE says a durable volume really is mounted.
+        //
+        // One resolver, shared with the managed runtime, so this entrypoint
+        // cannot drift from it: every source declared in `rebase.json` is read
+        // from `<BASE>__<KEY>` (S3_BUCKET__MEDIA for a source keyed "media"),
+        // and a project that declared nothing gets one default source from the
+        // plain, unsuffixed variables — exactly as before.
+        storage: resolveStorageSources(
+            process.env,
+            storageSources,
+            path.resolve(__dirname, "../../uploads")
+        ),
+        storageSources,
         // Storage is not under row-level security, so this hook IS its access
         // model — the server refuses to boot in production without one, because
         // "signed in" would otherwise be the only thing between a visitor and
@@ -164,7 +161,24 @@ pass: env.SMTP_PASS! }
         history: true
     });
 
+    // ─── Your own routes ──────────────────────────────────────────
+    // This is a plain Hono app and everything you add to it is yours — which
+    // also means it is outside Rebase's auth. `initializeRebaseBackend` guards
+    // the routers it mounts (`/api/data`, `/api/auth`, …); it does not guard
+    // this `app`. A route added here is reachable by anyone on the internet
+    // until you put a guard in its middleware slot:
+    //
+    //   import { requireAuth, requireAdmin } from "@rebasepro/server";
+    //   app.get("/admin/report", requireAuth, requireAdmin, handler);
+    //
+    // `requireAuth` answers 401 without a valid token; `requireAdmin` answers
+    // 403 without the `admin` role and must follow `requireAuth`. Note that
+    // `c.get("driver")` — the RLS-scoped driver — is only set inside the Rebase
+    // routers, so out here reach for `rebase.dataAsAdmin`, which **bypasses
+    // RLS** and therefore belongs behind one of those guards.
+
     // ─── Health check ─────────────────────────────────────────────
+    // Deliberately public: an orchestrator's probe has no token to send.
     app.get("/health", async (c) => {
         const result = await backend.healthCheck();
         const status = result.healthy ? 200 : 503;

package/templates/eject/docker-compose.custom.yml

@@ -0,0 +1,71 @@
+# ─── Self-hosting an ejected project ─────────────────────────────────
+#
+# `rebase eject` wrote this. It builds the image described by ./Dockerfile and
+# runs YOUR backend/src/index.ts, rather than mounting a bundle into the
+# published Rebase runtime.
+#
+#   docker compose -f docker-compose.custom.yml up -d db
+#   rebase db push                                    # once
+#   docker compose -f docker-compose.custom.yml up --build
+#
+# What you gave up by ejecting: the platform no longer upgrades the server
+# underneath you, and CORS, auth wiring, storage and shutdown are configured in
+# your entrypoint rather than by the runtime. What you gained: it is your
+# process, and you can put anything you like in it.
+#
+# `docker-compose.yml` is still here and still runs the managed shape. Nothing
+# stops you going back — set `runtime: "managed"` in rebase.json, `rebase build`,
+# and use that file instead.
+# ─────────────────────────────────────────────────────────────────────
+
+name: {{PROJECT_NAME}}
+
+services:
+  db:
+    image: postgres:18-alpine
+    restart: unless-stopped
+    environment:
+      POSTGRES_USER: rebase
+      POSTGRES_PASSWORD: ${DATABASE_PASSWORD:-changeme}
+      POSTGRES_DB: rebase
+    ports:
+      - "5432:5432"
+    volumes:
+      - postgres_data:/var/lib/postgresql
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U rebase -d rebase"]
+      interval: 5s
+      timeout: 5s
+      retries: 10
+      start_period: 10s
+
+  backend:
+    build:
+      context: .
+      dockerfile: Dockerfile
+    restart: unless-stopped
+    ports:
+      - "${PORT:-3001}:3001"
+    env_file: .env
+    environment:
+      DATABASE_URL: postgresql://rebase:${DATABASE_PASSWORD:-changeme}@db:5432/rebase?options=-c%20search_path=public
+      ADMIN_CONNECTION_STRING: postgresql://rebase:${DATABASE_PASSWORD:-changeme}@db:5432/rebase?options=-c%20search_path=public
+      NODE_ENV: production
+      PORT: "3001"
+      # Your entrypoint serves the built frontend itself (see the `serveSPA`
+      # call in backend/src/index.ts), so this is one container, same origin.
+      CORS_ORIGINS: ${CORS_ORIGINS:?set CORS_ORIGINS to the origin you browse to}
+      # A durable named volume, which is the case this flag acknowledges.
+      STORAGE_PATH: /uploads
+      FORCE_LOCAL_STORAGE: "true"
+    depends_on:
+      db:
+        condition: service_healthy
+    volumes:
+      - uploads:/uploads
+
+volumes:
+  postgres_data:
+    driver: local
+  uploads:
+    driver: local

package/templates/overlays/baas/backend/package.json

@@ -2,12 +2,9 @@
     "name": "{{PROJECT_NAME}}-backend",
     "version": "1.0.0",
     "description": "Rebase BaaS — headless PostgreSQL API",
-    "main": "src/index.ts",
     "type": "module",
     "scripts": {
-        "dev": "tsx watch --include=\"./functions/**/*\" src/index.ts",
-        "build": "tsc",
-        "start": "node dist/index.js"
+        "build": "tsc"
     },
     "dependencies": {
         "@rebasepro/server": "workspace:*",

package/templates/overlays/baas/backend/tsconfig.json

@@ -5,7 +5,6 @@
     "moduleResolution": "node",
     "lib": ["ES2022"],
     "outDir": "./dist",
-    "rootDir": "./src",
     "strict": true,
     "esModuleInterop": true,
     "allowSyntheticDefaultImports": true,
@@ -15,5 +14,12 @@
     "declaration": true,
     "sourceMap": true
   },
-  "include": ["src/**/*"]
+  // `functions/` as well as `src/`, because this flavour has nothing in src:
+  // it declares no collections, so there is no generated schema, and the server
+  // entrypoint lives behind `rebase eject`. An include matching only an empty
+  // directory is TS18003 — tsc reports "no inputs" as an error, not a no-op.
+  //
+  // No `rootDir`: it would have to be `.` for both, and letting tsc infer the
+  // common root gets there without a second place to keep in sync.
+  "include": ["src/**/*", "functions/**/*"]
 }

package/templates/overlays/baas/config/index.ts

@@ -0,0 +1,15 @@
+/**
+ * The config package for a headless project.
+ *
+ * There are no collections here: this flavour introspects them from the live
+ * database at boot, which is exactly what "no `config/collections` directory"
+ * means to `rebase build`.
+ *
+ * The package still exists because storage does not run under row-level
+ * security and its keys share one flat namespace — so without an access model,
+ * a deployment with file storage enabled serves every user's files to every
+ * signed-in user. The server refuses to boot in that state, and this is the
+ * export it looks for.
+ */
+
+export { storageAuthorize } from "./storage.js";

package/templates/overlays/baas/config/package.json

@@ -0,0 +1,28 @@
+{
+  "name": "{{PROJECT_NAME}}-config",
+  "version": "1.0.0",
+  "description": "Storage access control for a headless Rebase project",
+  "main": "dist/index.js",
+  "types": "dist/index.d.ts",
+  "type": "module",
+  "private": true,
+  "scripts": {
+    "build": "tsc",
+    "dev": "tsc --watch",
+    "clean": "rm -rf dist"
+  },
+  "dependencies": {
+    "@rebasepro/types": "workspace:*"
+  },
+  "devDependencies": {
+    "typescript": "^5.9.2"
+  },
+  "exports": {
+    ".": {
+      "import": "./dist/index.js",
+      "types": "./dist/index.d.ts",
+      "default": "./dist/index.js"
+    },
+    "./package.json": "./package.json"
+  }
+}

package/templates/overlays/baas/package.json

@@ -5,7 +5,8 @@
     "private": true,
     "type": "module",
     "workspaces": [
-        "backend"
+        "backend",
+        "config"
     ],
     "scripts": {
         "dev": "rebase dev",

package/templates/overlays/baas/pnpm-workspace.yaml

@@ -1,5 +1,6 @@
 packages:
   - "backend"
+  - "config"
 linkWorkspacePackages: true
 blockExoticSubdeps: false
 minimumReleaseAge: 0

package/templates/overlays/baas/rebase.json

@@ -1,14 +1,10 @@
 {
     "$schema": "https://rebase.pro/schemas/rebase.json",
-    "runtime": "^1",
+    "rebase": "^1",
     "apps": {
         "backend": {
             "type": "backend",
-            "mode": "baas"
-        },
-        "admin": {
-            "type": "admin",
-            "mode": "hosted"
+            "runtime": "managed"
         }
     }
 }

package/templates/template/.env.example

@@ -125,6 +125,21 @@ VITE_API_URL=http://localhost:3001
 # For other providers (Azure Blob, etc.), implement the StorageController
 # interface and pass it directly in your backend config.
 
+# --- Several buckets ------------------------------------------------------
+# Declare them in rebase.json, then configure each from the SAME variable names
+# carrying its own suffix. The default source takes no suffix, so everything
+# above keeps working and a single-bucket project declares nothing.
+#
+#   rebase.json:  "storage": { "media": { "engine": "s3" } }
+#
+# STORAGE_TYPE__MEDIA=s3
+# S3_BUCKET__MEDIA=my-app-media
+# S3_ACCESS_KEY_ID__MEDIA=
+# S3_SECRET_ACCESS_KEY__MEDIA=
+#
+# The separator is a DOUBLE underscore: a single one would collide with real
+# variable names (S3_BUCKET_NAME would parse as bucket "name").
+
 # ── Backups (optional) ────────────────────────────────────────────────────────
 # Manual backups: `rebase db backup --out ./backups` (or an s3://… URL).
 # Scheduled backups: set BACKUP_SCHEDULE and add a cron file in backend/crons

package/templates/template/README.md

@@ -60,37 +60,60 @@ server). Pin a port with `rebase dev --port 3001` if you need a stable one.
 ## Project Structure
 
 ```
-├── frontend/           # React frontend (Vite)
-│   ├── Dockerfile      # Production build → nginx
-│   └── nginx.conf      # SPA routing + compression
-├── backend/            # Hono backend with PostgreSQL
-│   ├── Dockerfile      # Multi-stage production build
+├── frontend/           # Your admin panel (React + Vite)
+├── backend/            # Server code
 │   ├── functions/      # Custom API endpoints (auto-discovered)
-│   └── src/
+│   └── src/            # Generated database schema
 ├── config/             # Shared collection definitions
 │   └── collections/    # Schema-as-Code TypeScript files
-├── docker-compose.yml  # Production stack (Postgres + Backend + Frontend)
+├── rebase.json         # Which apps this repository contains
+├── docker-compose.yml  # Self-hosting stack (Postgres + the Rebase runtime)
 ├── .env.example        # Environment variable reference
 └── package.json        # Root workspace config
 ```
 
+There is no Dockerfile, and that is deliberate: `rebase build` produces a
+**bundle** — your compiled collections, functions, crons and admin assets — and
+the published `rebasepro/server` image boots it. The artifact you self-host is
+the artifact Rebase Cloud runs, so moving between them changes nothing in this
+repository.
+
+If you would rather run your own server process, `rebase eject` writes the
+entrypoint, a Dockerfile and a compose file that builds them.
+
 ### Custom Functions
 
 Drop a Hono app in `backend/functions/` and it's auto-mounted at `/api/functions/<name>`:
 
 ```typescript
 // backend/functions/hello.ts
-import { Hono } from "hono";
-const app = new Hono();
-app.post("/", async (c) => {
-    const body = await c.req.json();
-    return c.json({ message: `Hello, ${body.name}!` });
+import { defineFunction, requireAuth, requireAdmin } from "@rebasepro/server";
+
+export default defineFunction((app) => {
+    // Deliberately public — anyone can call this.
+    app.get("/", (c) => c.json({ status: "ok" }));
+
+    // 401 without a valid token.
+    app.post("/", requireAuth, async (c) => {
+        const body = await c.req.json();
+        return c.json({ message: `Hello, ${body.name}!` });
+    });
+
+    // 401 anonymous, 403 without the `admin` role. Order matters.
+    app.get("/stats", requireAuth, requireAdmin, (c) => c.json({ ok: true }));
 });
-export default app;
 ```
 
 Call from the client SDK: `client.call("functions/hello", { name: "World" })`
 
+**Functions are not authenticated for you.** The functions router parses the
+caller's token into the request context but does not reject anonymous requests —
+webhook receivers have no token to send. So every route here is public until a
+guard says otherwise, and reading `c.get("user")` is not a guard: an anonymous
+caller simply gets `undefined` and the handler runs. Put `requireAuth` /
+`requireAdmin` in the route's own middleware slot rather than in `app.use()`,
+which only covers routes declared below it.
+
 ### Shared Collections
 
 Collections are defined once in `config/collections/` and used by both the frontend and backend. This ensures your schema stays in sync across the stack.
@@ -105,23 +128,28 @@ All configuration is managed through a single `.env` file in the project root. B
 
 `init` already generated your `.env`. See the comments in `.env.example` for details on each variable, and edit `.env` directly to change any of them.
 
-## Production Deployment
+## Self-hosting
+
+Two containers: PostgreSQL, and the Rebase runtime with your built project
+mounted into it. There is no application image to build.
 
-The full stack — PostgreSQL, backend, and frontend — runs from
-`docker compose`. The backend image builds and boots, but it does **not**
-create your collection tables on its own, so push the schema once the
-database is up before (or right after) starting the rest of the stack.
+The runtime creates its auth tables at boot but **not** your collection tables —
+a container restart must not be able to change a schema as a side effect — so
+push the schema once, while the database is up.
 
 ```bash
-# 1. Start the database and create the tables from your collections
+# 1. Build your project into ./dist-bundle
+pnpm run build          # or: npm run build
+
+# 2. Start the database and create the tables from your collections
 docker compose up -d db
 pnpm run db:push        # or: npm run db:push
 
-# 2. Build and start the backend + frontend
-docker compose up -d --build
+# 3. Start the runtime
+docker compose up -d
 
 # View logs
-docker compose logs -f backend
+docker compose logs -f api
 
 # Stop
 docker compose down
@@ -130,6 +158,12 @@ docker compose down
 docker compose down -v
 ```
 
+One container now serves the API at `/api` and the admin at `/` — same origin,
+so there is no CORS between them and no second web server to run.
+
+To upgrade Rebase, set `REBASE_VERSION` in `.env` and restart. Your bundle is
+untouched.
+
 > `docker compose` reads the generated `.env` as-is. Set production values
 > (a strong `DATABASE_PASSWORD`, `JWT_SECRET`, storage credentials, …) by
 > editing `.env` directly — see `.env.example` for the full list. Do not

package/templates/template/ai-instructions.md

@@ -15,3 +15,4 @@ rebase skills install
    - Step 1: Run `rebase schema generate` to compile collections to the Drizzle schema.
    - Step 2: Run `rebase db push` (development) or `rebase db generate && rebase db migrate` (production) to apply schema changes to the database.
 3. **Use the SDK**: Always use the Rebase SDK (`rebase.data.<slug>`) to fetch or modify data. Bypassing it with raw SQL or direct Drizzle/PG queries circumvents model validations, lifecycle hooks, and Row-Level Security (RLS).
+4. **Guard every custom route**: routes in `backend/functions/` are mounted **without** an auth requirement — webhook receivers need that — so each one is public until you guard it. Import `requireAuth` / `requireAdmin` from `@rebasepro/server` and pass them in the route's own middleware slot (`app.post("/", requireAuth, handler)`), not via `app.use()`, which only covers routes declared below it. Reading `c.get("user")` is not a guard: an anonymous caller gets `undefined` and the handler still runs. See `backend/functions/hello.ts` for all three tiers.