# Changelog

## v0.34.0 — May 23, 2026

Customizable email-OTP templates and a dedicated admin-create-user hook
— closes a longstanding gap where projects on `email.provider: 'aws-ses'`
had to live with the generic "Your password reset code is ..." copy for
admin-bootstrapped accounts.

### Per-type email-OTP template overrides

Drop a `.ts` file at `quickback/email-templates/<name>.ts` that
default-exports `(input) => ({ subject, html, text })`, then reference
it from the new `plugins.emailOtp.templates` map. Missing keys fall
through to the package defaults from `@quickback-dev/better-auth-aws-ses`
— this is purely additive; existing `emailOtp: true` projects emit the
same code they did before.

```ts title="quickback/quickback.config.ts"
defineAuth("better-auth", {
  plugins: {
    emailOtp: {
      templates: {
        'forget-password': './email-templates/forget-password',
        'welcome':         './email-templates/welcome',
      },
    },
  },
});
```

```ts title="quickback/email-templates/welcome.ts"
export default function welcome({ otp, name, appName, appUrl }) {
  const greeting = name ? `Hi ${name},` : 'Hi,';
  return {
    subject: `Welcome to ${appName} — set your password`,
    html:    `<h1>Welcome to ${appName}</h1><p>${greeting} use this code: <b>${otp}</b></p>`,
    text:    `${greeting}\n\nYour ${appName} code: ${otp}`,
  };
}
```

Recognized keys: `'sign-in' | 'email-verification' | 'forget-password' |
'welcome'`. The first three map 1:1 to Better Auth's emailOTP `type`
enum.

### Synthetic `welcome` routing — credential-row lookup

`'welcome'` has no native Better Auth OTP type. When configured, the
generated `sendVerificationOTP` callback queries the `account` table
for a `credential`-provider row for the recipient *before* rendering;
if the user has none (typical of an admin-plugin-created account
without a password), the send is rerouted through the welcome
template. Without a welcome template, those sends fall through to
`forget-password` — same behavior as before. DB-error path fails open
to the normal forget-password flow so a transient failure can't
deadlock the password-reset surface.

Provider scope: overrides are only honored on `email.provider:
'aws-ses'`. The Cloudflare Email path uses the helper's own template
pipeline and ignores the new config.

### New recognized hook: `after-admin-user-create.ts`

A virtual event that wires into the same Better Auth
`databaseHooks.user.create.after` slot as the generic
`after-user-create.ts`, but the generator gates the call on
`_baCtx?.context?.path` matching `/admin/create-user` so it only fires
when the row came from the admin plugin's create-user endpoint. Use it
for first-time-user provisioning (welcome email, default org
assignment, audit-log writes) without inspecting the BA context by
hand. The generic `after-user-create.ts` still runs for every signup,
including admin-created ones; the two coexist in a single merged
`after:` handler.

```
quickback/hooks/
  after-user-create.ts        # every signup
  after-admin-user-create.ts  # admin-plugin /admin/create-user only
```

### File transport mirrors existing slots

The new `quickback/email-templates/` directory follows the same
pattern as `quickback/plugins/`, `quickback/hooks/`, and
`quickback/lib/`: the CLI walks the folder and uploads each `.ts` file
in a new `projectEmailTemplates` field on the compile request; the
better-auth provider stages referenced files into
`src/email-templates/<name>.ts` and emits default imports in
`src/lib/auth.ts`. Files not referenced by any template entry are
ignored — the CLI uploads the whole directory; the compiler picks only
what's needed. A relative path pointing at a file the CLI never
shipped fails compile fast with a "place the file at … and rerun"
hint.

See [AWS SES Plugin → Per-Type Template Overrides](/stack/auth/plugins/aws-ses#per-type-template-overrides)
and [Account UI → Hooks](/stack/account-ui/hooks#recognized-events).

## v0.33.6 — May 22, 2026

Two compiler-side fixes for the queue-consumer / embedding surface and one
schema-emission bug that blocked `generateId: 'cuid'` projects.

### Schema-emitted `createId()` now ships with a polyfill (no missing import)

When `providers.database.config.generateId` is set to `'cuid'`, the audit-
field injector emits an id column like
`id: text('id').primaryKey().$defaultFn(() => createId())`. Previously the
schema source referenced `createId` but no import landed, so `tsc` on the
generated project failed with `Cannot find name 'createId'`. Recurring
bug — every recompile re-emitted the broken file (the "do not edit"
banner doesn't protect from regeneration).

Fix: the injector now prepends a top-of-file polyfill backed by
`crypto.randomUUID()` — a Workers / Node 19+ / Bun global — instead of
trying to import `@paralleldrive/cuid2`. The package isn't bundled by
Quickback (per the [hooks doc](/stack/account-ui/hooks)'s "stick to
built-ins" guidance) and the schema-gen sandbox can't resolve project
node_modules anyway, so the polyfill is the only path that works
out-of-the-box.

```ts title="Generated schema header (cuid strategy)"
import { sqliteTable, text } from 'drizzle-orm/sqlite-core';

// Polyfill — Quickback compiler does not ship @paralleldrive/cuid2 in
// generated projects, and the schema-gen sandbox can't see node_modules.
// crypto.randomUUID() is a Workers / Node 19+ / Bun global.
const createId = () => crypto.randomUUID();

export const widgets = sqliteTable('widgets', {
  id: text('id').primaryKey().$defaultFn(() => createId()),
  // ...
});
```

If you want real cuid2 strings (collision-resistant, shorter than UUIDs)
you can still install `@paralleldrive/cuid2` and add the import yourself —
the injector honours an existing import and skips the polyfill.

### queue-consumer.ts header reflects what the file actually does

Before v0.33.6 the generated `src/queue-consumer.ts` always carried the
preamble:

```
* Queue Consumer for Embedding Jobs & Custom Queue Handlers
*
* Processes embedding jobs asynchronously using Workers AI and Vectorize.
* Also supports custom queue handlers defined in services/queues/.
```

— even on projects with zero embedding features. Users on
custom-queue-only deployments would search for `EMBEDDINGS_QUEUE` /
Vectorize bindings that wrangler.toml correctly didn't emit, wasting
diagnostic time.

The preamble now reflects the actual surface:

| `hasEmbeddings` | `hasCustomHandlers` | Header |
|---|---|---|
| ✓ | ✓ | "Queue Consumer for Embedding Jobs & Custom Queue Handlers" |
| ✓ | — | "Queue Consumer for Embedding Jobs" |
| — | ✓ | "Queue Consumer for Custom Queue Handlers" + explicit "No embedding bindings (EMBEDDINGS_QUEUE / Vectorize / AI) are referenced" |
| — | — | "Queue Consumer Stub" (additionalQueues with no handler yet) |

### Symmetric embedding detection prevents silent drift

The wrangler.toml emit path (`EMBEDDINGS_QUEUE` producer/consumer
declaration) and the queue-consumer.ts emit path (embedding handler code)
previously used two different functions to detect "this project has
embeddings": `hasEmbeddingsConfig` checked both `feature.resource.
embeddings` and `feature.tables[].resource.embeddings`;
`extractEmbeddingFeatures` only iterated the tables array. A feature
shape with feature-level embeddings sugar but no populated tables would
land in the wrangler binding while NOT landing in the consumer file
— silent drift.

`hasEmbeddingsConfig` is now defined as
`extractEmbeddingFeatures(...).length > 0`. The two stay in lock-step
by construction. `extractEmbeddingFeatures` now reads from both shapes
(tables-level when present, feature-level otherwise).

## v0.33.5 — May 22, 2026

Two structural fixes that resolve recurring classes of bug for projects with
integer primary keys and for projects whose audit columns drift between
schema and database.

### URL `:id` params coerce to Number when the PK column is integer

Per-id CRUD handlers (`GET /:id`, `PATCH /:id`, `DELETE /:id`, `PUT /:id`)
extracted the URL param as a string and passed it straight into
`eq(table.id, id)`. For resources with `integer().primaryKey()` columns —
triggered either by `generateId: 'serial'` on the database config or by
imported legacy schemas — every per-id route raised a downstream tsc
type error (integer ≠ string). One production project reported 249 such
errors across 30+ generated `*.routes.ts` files.

Generated handlers for integer-PK resources now emit:

```ts
const __idRaw = c.req.param('id');
const id = Number(__idRaw);
if (!Number.isInteger(id)) {
  return c.json(ValidationErrors.invalidInput([{
    path: ['id'],
    message: `Expected integer, got "${__idRaw}"`,
    code: 'invalid_type',
  }]), 400);
}
```

Text-PK resources (the default and the recommended path) are unchanged.

A soft-deprecation warning now fires at compile time when
`providers.database.config.generateId === 'serial'` is set, nudging new
projects toward text-PK strategies (`'cuid'`, `'uuid'`, `'prefixed'`, or
the default). Existing serial-PK projects keep working.

### Audit-field injection now runs for every dialect

The compiler auto-injects `created_at`, `modified_at`, `created_by`, and
`modified_by` columns into every feature table, and the scoped-db
runtime auto-fills them on insert. Until v0.33.5, the early injection
step in `parseCompilerInput` was gated on `targetDialect ===
'postgresql'`. SQLite/D1 projects fell back to a later injection inside
`generateFeature`, which only fired when `feature.tables.length > 0` —
features arriving without a populated tables array (raw-drizzle shapes,
certain legacy migration tables) silently skipped audit injection.

Symptom: schemas claimed the columns existed (so the scoped-db proxy
tried to fill them on insert), but the database table didn't have them.
Inserts failed with "column doesn't exist." Users reported this for the
`user_preferences` table and, earlier, for `chat_reads` (the
`0028_chat_reads_id_column.sql` incident).

The early injection now runs for all dialects. `injectAuditFields` is
already idempotent, so the subsequent per-target injections in
`compilePureSQLTarget` and `feature-generator.ts` are no-ops when the
columns are already present. Net: every feature's schema source has
audit columns by the time drizzle-kit reads it, regardless of dialect
or feature shape.

Upgrade path: recompile against v0.33.5, commit the generated migration
that adds the missing audit columns, then `wrangler d1 migrations apply`.

## v0.33.4 — May 21, 2026

Patch fixes covering upgrade-path bugs and OpenAPI spec/route divergence. No
new features or breaking changes.

### OpenAPI emits CRUD endpoints only when the route emitter registers them

The OpenAPI emitter previously advertised `GET /`, `POST /`, `GET /:id`,
`PATCH /:id`, `DELETE /:id`, and the corresponding `/batch` operations on
every resource, regardless of which CRUD verbs were actually declared.
Clients generated from `openapi.json` then issued requests that fell
through to `ROUTE_NOT_FOUND` from the firewall layer — a silent contract
break for anyone whose code path was driven by openapi-typescript or
similar codegen.

Each gate now mirrors the route emitter exactly. A resource that only
declares `read + create + delete` (no `update`) gets no PATCH operations
in the spec. A write-only sink (`create` only, no `read`) gets no GET
operations. Same for batch variants — `POST /batch` only when
`crud.create` is set, `DELETE /batch` only when `crud.delete` is set,
etc.

If your generated client was calling these spurious endpoints, those
calls were already failing at runtime; this just removes them from the
spec.

### Legacy D1 audit-timestamp migrations rewritten in place

Compilers ≤ v0.33.1 emitted
`DEFAULT (strftime('%Y-%m-%dT%H:%M:%fZ', 'now'))` for audit columns
(`created_at`, `modified_at`, etc.). Cloudflare D1 rejects this in
`ALTER TABLE ADD COLUMN` with `SQLITE_ERROR [code: 7500] "Cannot add a
column with non-constant default"`. v0.33.2 stopped emitting the
non-constant form, but pending unapplied legacy migration files on
upgrading projects still poisoned `wrangler d1 migrations apply` and
left the deploy stuck.

The D1 migration safety pass now retrofits these files in place,
replacing the strftime expression with the same `'1970-01-01T00:00:00.000Z'`
constant v0.33.2+ uses. The compile-time warning lists the affected
columns:

```
⚠ D1 helper adjusted features migrations for Cloudflare D1 safety:
  0004_early_dracula.sql [rewrote=applied_at,created_at,modified_at]
```

Upgrade path: recompile against v0.33.4, commit the rewritten SQL, then
`wrangler d1 migrations apply` proceeds.

### D1 helper warning is now actionable

The same migration safety pass auto-prepends `PRAGMA defer_foreign_keys
= on` to every drizzle table-rebuild migration — required on D1
because it doesn't honour `PRAGMA foreign_keys=OFF/ON` mid-migration the
way SQLite does. The pass used to surface this insertion as a warning
on every recompile, training users to ignore the warning entirely.

The PRAGMA is still inserted (it has to be), but no longer fires the
warning. Stripped Better Auth cleanup, reordered child-first DROPs, and
the new `rewrote=…` annotation above still warn — those are cases where
a human should look.

### Reference: `account.appUrl` / `account.tenantPattern`

v0.33's redesigned dashboard org-card uses two new optional fields on
the `account` config to deep-link into the tenant's own app:

```ts
// quickback.config.ts
account: {
  // …existing fields
  appUrl:        'https://app.example.com',
  tenantPattern: '/{slug}',
}
```

Both are typed in the config schema and baked into the Account SPA at
build time as `VITE_QUICKBACK_APP_URL` and `VITE_TENANT_URL_PATTERN`.
Without them, the dashboard falls back to a single-target card that
links to the account org-settings page (legacy v0.32 behaviour). Adding
them enables the two-zone layout with the external deep-link affordance.

(No code change in v0.33.4 — the fields shipped with v0.33.0 but weren't
called out in the changelog.)

## v0.33.0 — May 21, 2026

### Dedicated hostnames for `/auth/v1/*` and `/api/v1/*` (Shape 1)

Two new optional overrides let you carve specific backend surfaces onto dedicated hostnames, served by the same Worker:

```ts
// quickback.config.ts
auth: { domain: 'auth.example.com' },  // /auth/v1/* lives here too
api:  { domain: 'api.example.com'  },  // /api/v1/*  lives here too
```

On the dedicated hostname, the hostname IS the namespace — `/v1/*` is a shortcut that the Worker-entry rewriter prepends with `/auth` or `/api` before route matching. So `https://api.example.com/v1/users` reaches the same handler as `https://quickback.example.com/api/v1/users`. Both forms work; the long form is also accepted on the dedicated host. Non-matching paths return a JSON 404 ("Not found on api.domain — this hostname serves /api/v1/* and the /v1/* shortcut only") — each hostname stays dedicated to its surface. `/health` and `/openapi.json` are explicit exceptions because monitoring/discovery agents expect them everywhere.

Both new domains:
- Get a `{ pattern, custom_domain: true }` route in `wrangler.toml`
- Join `trustedOrigins` (CORS allowlist)
- Join the cross-subdomain cookie inference (auto-enables `crossSubDomainCookies` when ≥2 same-parent subdomains are configured)
- Join CSP `connect-src` so SPAs can fetch from them

**Dual-reach:** all routes remain reachable at the unified backend host (see below) regardless of which dedicated hostnames are configured. The dedicated hostnames are aliases, never replacements.

### `quickback.{baseDomain}` codified as the always-present unified backend

The compiler has always auto-inferred a `quickback.{baseDomain}` hostname when any subdomain is configured. v0.33 promotes this from inferred fallback to **load-bearing contract**:

- The unified backend hostname is GUARANTEED to exist when any custom subdomain (`account.domain`, `cms.domain`, `auth.domain`, `api.domain`, `apps.<n>.domain`) is set.
- Every compiler-emitted backend route (api, auth, storage, health, openapi, realtime, mcp, bundled SPAs, sysadmin endpoints) is reachable at the unified host, always.
- Per-surface domain overrides are additive (Shape 1) — they create more hostnames, never remove routes from the unified host.

This is forward-pointing: the future management layer can rely on a single discovery URL pattern (`https://quickback.{baseDomain}/...`) to find any backend regardless of how the operator split their surfaces onto subdomains.

Inference also extends to consider `auth.domain` and `api.domain` as domain sources, so a project configuring only one of them still derives `quickback.{baseDomain}` automatically. Explicit `config.domain` still wins over inference.

### `compiler.routes` config block (scaffold — partial)

Optional path-prefix overrides for compiler-emitted system routes:

```ts
compiler: {
  routes: {
    storage:   '/files',          // default '/storage'
    broadcast: '/realtime',       // default '/broadcast/v1'
    mcp:       '/agent',          // default '/mcp'
    health:    '/_health',        // default '/health'
    openapi:   '/openapi.yaml',   // default '/openapi.json'
  },
}
```

**Status:** the config is validated and reaches the reserved-prefix registry (so SPA pass-through and compile-time collision detection already honor overrides), but the per-section route emitters still hardcode the defaults. Setting a non-default value today will produce a misconfigured Worker — the registry knows the new path but the actual `app.route('/storage/v1', …)` mount uses the old one. **Don't set these in production yet.** Per-section emit wiring lands in a follow-up.

`/api/v1/` and `/auth/v1/` are NOT configurable here — those are deep contracts touched by feature emitters, OpenAPI generation, generated clients, and BA's own basePath. The Shape 1 hostname overrides above are the supported way to relocate them.

## v0.32.0 — May 21, 2026

### Single-origin path-routed architecture

A modern Quickback project now runs on **one Cloudflare Worker behind one custom domain**, with the bundled Account and CMS SPAs path-mounted at `/account/` and `/cms/`, system routes at `/api/`, `/auth/`, `/storage/`, and the user's own SPAs anywhere else they want. No cross-subdomain cookies, zero CORS preflights, no separate `api.`/`account.`/`cms.` subdomains required:

```ts
// quickback.config.ts
apps: { www: { domain: 'app.example.com' } },  // user's root SPA
account: true,                                  // bundled at /account/
cms: true,                                      // bundled at /cms/
// /api/, /auth/, /storage/, /openapi.json, /health all live here too
```

The bug that previously broke this shape: when a hostname-mounted root SPA was configured (`apps.www.domain`), its middleware swallowed every path that wasn't in a hardcoded list (`/api/`, `/auth/`, `/admin/`, `/storage/`, `/health`). Requests to `/account/profile` got remapped to `/www/account/profile`, 404'd, then SPA-fallback'd to the wrong SPA. v0.32 introduces a **reserved-prefix registry** (`resolveReservedPrefixes` in `apps/compiler/src/generators/core/reserved-prefixes.ts`) as the single source of truth for what every catchall middleware must pass through:

- **System** (always present): `/api/`, `/auth/`, `/storage/`, `/health`, `/openapi.json`
- **Conditional** (only when feature is on): `/account/` (when `account: true`), `/cms/` (when `cms: true`), `/broadcast/v1/` (realtime), `/mcp` (MCP server)
- **User-contributed**: every `apps.<name>.path` for path-mounted apps

Path-mounted apps that collide with a system or bundled-SPA reservation throw a compile-time error naming both owners. `apps.api = { path: '/api' }` errors clearly instead of silently hijacking feature routes at runtime.

### Admin URL namespace migration: `/admin/v1/*` → `/auth/v1/admin/*`

Quickback's legacy admin tier emitted three things under `/admin/v1/*`:

1. A role-admit middleware that admitted both `'admin'` and `'sysadmin'` — contradicting the pseudo-role evaluator's strict-independence model (`ADMIN` admits `'admin'` only; `SYSADMIN` admits `'sysadmin'` only).
2. `GET /admin/v1/organizations` — a thin proxy to Better Auth's own `/auth/v1/organization/list`.
3. `GET /admin/v1/sysadmin/organizations` — cross-tenant org listing, sysadmin-only.

In v0.32, the first two are **removed** and the third **renames** to `GET /auth/v1/admin/list-organizations`. The new path sits under Better Auth's admin URL namespace (sibling of `/auth/v1/admin/list-users`, `/auth/v1/admin/ban-user`, etc.), follows BA's verb-noun convention, and keeps its sysadmin-only gate inside the handler — Quickback-emitted, not BA-mounted.

What this enables: `/admin/*` is no longer a reserved system prefix. Projects can mount their own admin SPA via `apps.admin = { path: '/admin' }` without colliding with anything.

What changes for callers:
- The bundled CMS SPA's sysadmin org switcher is updated in lockstep (no migration needed for projects using the SPA as-is).
- External callers of `/admin/v1/organizations` should migrate to BA's `/auth/v1/organization/list` (same behavior — caller's memberships).
- External callers of `/admin/v1/sysadmin/organizations` should migrate to `/auth/v1/admin/list-organizations`.
- Features that previously relied on the "admit both admin AND sysadmin" middleware should declare `access: { roles: ['ADMIN', 'SYSADMIN'] }` explicitly on each route.

The `ADMIN_ROUTE_FEATURES` carve-out in the compiler is also removed — feature routes always mount at `/api/v1/<feature>`, and admin-only behavior is enforced by per-operation `access: { roles: ['ADMIN'] }` at the resource level.

### Two compiler bug fixes

- **Soft-delete index callback parameter bug.** The auto-index injector emitted hardcoded `t.<col>` references regardless of the existing extras callback's parameter name. When a user (or upstream transform) wrote `(table3) => ({ … })`, the appended composite-index entries referenced `t.organizationId, t.deletedAt` — `t` undefined inside the arrow scope, `ReferenceError` at module load. Fixed in `apps/compiler/src/utils/auto-indexes.ts` by capturing and reusing the callback's parameter name.
- **Reserved-word action filename collision.** Action discovery walks `actions/*.ts` and emits `import <name> from './actions/<name>'`. A user filename of `import.ts`, `delete.ts`, `await.ts`, `export.ts`, etc. produced `import import from './actions/import';` — a SyntaxError on module load. Fixed in `apps/compiler/src/codegen/discovered-actions.ts` by aliasing reserved-word and invalid-identifier filenames to `__action_<sanitized>` bindings while preserving the public action key (route emitters use bracket notation, so reserved-word keys are fine in the lookup map).

## v0.29.0 — May 19, 2026

### Opt-in `id` auto-injection (`compiler.injectId: 'auto'`)

Quickback's generated CRUD routes, FK extractor, relationship resolver, and `/:id` mount points all assume every feature table has an `id` primary key column. Authoring a table without one — common when porting an existing schema, or when a domain genuinely uses a compound or non-`id` PK — produced silent failures: routes that 404, batch operations that targeted the wrong rows, FK lookups that returned empty.

v0.29 adds an opt-in flag that auto-injects an `id` column into every feature table that doesn't already declare one. Same mechanism as the existing `createdAt`/`modifiedAt` injection — early-pass, idempotent, dialect-aware.

```ts
// quickback.config.ts
compiler: {
  injectId: 'auto',   // off by default; opt in per project
}
```

When `'auto'`:
- Tables with no `.primaryKey()` declared get `id: text("id").primaryKey().$defaultFn(() => createId())` (or the matching shape for `dbConfig.generateId` — `serial`, `uuid`, `prefixed`).
- Tables that already declare an `id` column (in any shape) are no-op — the injector is idempotent.
- Tables with a `.primaryKey()` on a non-`id` column raise a clear compile error that names the offending column and points at the v0.30 follow-up which will rewrite custom PKs to unique indexes automatically. v0.29 surfaces the conflict; v0.30 fixes it.

Default stays `false` so existing projects don't get migration churn. Opt in when you want to lean on every-table-has-id semantics across your schema.

### Why this is opt-in (and what v0.30 changes)

The "every table has `id`" assumption is load-bearing across 68+ sites in the compiler — every CRUD emitter, the FK regex (`.references(() => target.id)`), the relationship resolver hydration block, the `/:id` route mounts. v0.29 only injects the column; v0.30 will close the remaining gaps:

- FK extraction migrates from `.id` regex to schema-aware metadata lookup, so tables with non-`id` PKs participate in FK display + relationship resolution.
- The PK→unique-index rewrite lands — tables with explicit non-`id` PKs auto-keep their uniqueness as a constraint while gaining the auto-injected `id`.
- The flag flips to default-on; opting out becomes the rare path.

v0.29 ships the foundation so projects can opt in today without waiting for the full structural pass.

## v0.28.0 — May 19, 2026

### INTERNAL pseudo-role: server-only schemas, unforgeable from HTTP

v0.27 had five pseudo-roles — `PUBLIC`, `AUTHENTICATED`, `USER`, `ADMIN`, `SYSADMIN` — and one structural gap: there was no way to mark a schema as "the server enumerates this; no user-facing route should ever read across tenants." Push subscriptions, personal access tokens, OAuth tokens, broadcast job tables — anywhere the server needs full visibility but users should only see their own row. The workaround was `firewall: { exception: true }` plus an out-of-band convention, which left auth on the schema looking incidental.

v0.28 adds **`INTERNAL`** as the sixth pseudo-role. Schemas with `roles: ['INTERNAL']` are reachable only by `AppContext` values where `ctx.internal === true` — a flag the HTTP auth middleware **never** sets. No session, JWT, header, query parameter, or body field populates it. The flag is reserved for compiler-emitted server-internal entry points (queue consumers, cron workers, server-side helpers that bypass HTTP entirely).

```ts
// features/comms/push-subscriptions.ts
export default defineTable(push_subscriptions, {
  firewall: [{ field: 'ownerId', equals: 'ctx.userId' }],
  // User reads their own subscriptions via the standard CRUD route.
  read: { access: { roles: ['USER'] } },
  // Server enumerates ALL subscriptions for a broadcast — INTERNAL only.
  crud: {
    delete: { access: { roles: ['INTERNAL'] } },
  },
});
```

The split-surface pattern is the recommended shape: a user-facing access node uses `USER` / `AUTHENTICATED` / a real role; a server-only access node uses `INTERNAL`. Mixing INTERNAL with a user-facing pseudo-role on the **same** access node is a compile error — it almost always means the developer is confused about which side of the trust boundary they're on. The error names the cohabiting markers explicitly and points at the fix (split into separate access blocks).

The runtime stamping (queue consumer ctx, cron worker ctx) lands in a follow-up; v0.28 ships the declarative surface so projects can mark schemas accurately today. Until the stamping ships, server-internal code uses `unsafeDb` to enumerate INTERNAL surfaces — the security guarantee is in place because no HTTP-derived context can ever carry `ctx.internal === true`.

### Reserved-name fix: SYSADMIN and INTERNAL added to ALWAYS_RESERVED

`SYSADMIN` was previously omitted from the `ALWAYS_RESERVED` set in `authz-schema.ts`. The runtime validator rejected `roles: ['SYSADMIN']` when `cms.sysadmin: true` wasn't set, but the **shadow-declaration path** — user code writing `authz.roles.SYSADMIN: { roles: [...] }` to silently change the pseudo-role's meaning — wasn't blocked. v0.28 closes that gap by adding both `SYSADMIN` and `INTERNAL` to the unconditionally-reserved set.

### Per-table OWNER_SCOPE_RULES: explicit owner predicates no longer over-scope

When a user declared a non-canonical owner predicate on one table — e.g. `firewall: [{ field: 'linkedUserId', equals: 'ctx.userId' }]` — that column got promoted into the **project-global** `OWNER_SCOPE_RULES` list. Any other table in the project that happened to have a `linkedUserId` column (even as a plain FK reference, not for scoping) had the same `WHERE linkedUserId = ctx.userId` injected on every read, update, and delete. Silent over-scoping that surfaced only when a query returned the wrong rows.

v0.28 narrows the global list to the **canonical owner column** — the one matching `authDefaults.owner.column` (default `ownerId`). Explicit predicates on custom-named columns are honored on their declaring table via that table's own `buildFirewallConditions` helper, but stay per-table. Reads on other tables with the same column name are unaffected.

```ts
// Before v0.28: linkedUserId on `comments` ALSO got the WHERE
// because `event_organizers` declared an explicit owner predicate.
export default defineTable(event_organizers, {
  firewall: [{ field: 'linkedUserId', equals: 'ctx.userId' }],
});
export default defineTable(comments, {
  // comments.linkedUserId is just an FK reference; we don't want it scoped.
  firewall: [{ field: 'eventId', equals: 'ctx.activeOrgId' }],
});
```

In v0.28, `event_organizers` queries get the per-table `linkedUserId = ctx.userId` predicate as before; `comments` queries are no longer mis-scoped.

If you genuinely want the same column to scope multiple tables (rare), declare the explicit firewall predicate on each table. The implicit "every table with this column gets scoped" behavior was the bug — explicit-per-table is the cure.

## v0.27.0 — May 19, 2026

### Narrow `ctx.<exposeAs>` typing for namespace-scoped actions

Since v0.23 the namespace middleware has hydrated `ctx.<exposeAs>` with the loaded resource row before each action runs. The static type of that field stayed `any` — runtime safety was solid, but autocomplete and typo-catching were missed opportunities.

v0.27 ships the second half: one **per-namespace `defineAction` helper** emitted alongside the standard one. Importing from the narrowed helper retypes `ctx.<exposeAs>` inside `execute({ ctx })` to the loaded row's `$inferSelect` shape. Nothing about discovery, routing, or runtime behavior changes — this is purely TypeScript ergonomics.

```ts title="features/feeds/actions/feed-moments.ts"
// Before — ctx.event is `any`
import { defineAction } from '../.quickback/define-action';

// After — ctx.event is `typeof events.$inferSelect`
import { defineAction } from '../.quickback/define-action.event-scope';

export default defineAction({
  path: '/event/:eventId/feed-moments',
  method: 'POST',
  input: z.object({ body: z.string() }),
  access: { roles: ['attendee'] },
  async execute({ ctx, input }) {
    ctx.event.id          // ✓ string, autocomplete works
    ctx.event.startsAt    // ✓ Date
    ctx.event.idd         // ✗ TS2339 — typo caught at compile time
  },
});
```

#### Where the file lives

The compiler emits one narrowed helper per `(feature, namespace)` pair where the feature owns at least one action whose `path:` falls under the namespace prefix. Filename is `define-action.<kebab(namespaceName)>.ts` (`eventScope` → `define-action.event-scope.ts`), sibling to the standard `define-action.ts`:

```text
src/features/feeds/.quickback/
├── define-action.ts              # generic — standard fallback
└── define-action.event-scope.ts  # ctx.event narrowed
```

A feature contributing to multiple namespaces gets one helper per namespace. Each action picks the import that matches its path.

#### Opt-in, no breaking change

Actions that keep their existing `import { defineAction } from '../.quickback/define-action'` continue to compile unchanged. The `AppContext` index signature still admits `ctx.event` at type `any`; runtime hydration is unaffected. Flip imports per action at your own pace.

#### Compile-time advisory

When `quickback compile` sees a namespace-scoped action still importing the generic helper, it logs a one-line `[quickback:typing]` advisory pointing at the narrowed path:

```text
[quickback:typing] action "feedMoments" in feature "feeds" lives under
  namespace "eventScope" — switch its import to
  `../.quickback/define-action.event-scope` for narrow ctx.<exposeAs> typing.
  (Runtime behavior is unchanged; the narrowed helper only refines TS types.)
```

Non-blocking — same family as `[quickback:authz]`.

#### Side fix

Repaired a latent off-by-one in the inlined `AppContext` import path that landed in the v0.26 helper prelude but hadn't been exercised against a recompiled project yet (`"../../lib/types"` → `"../../../lib/types"`). New compiles produce a helper whose `AppContext` import actually resolves.

#### Out of scope

Non-namespace standalone actions with relationship-based access keep their existing `(ctx.event as typeof events.$inferSelect)` body cast. Same per-relationship helper pattern would apply if the demand surfaces — defer until requested.

## v0.26.0 — May 19, 2026

### Bulk-grant namespace lanes: org admins and team members in one line

v0.25 widened `via:` to accept an array of relationship lanes — attendeeOf OR organizerOf, first match wins. That covers per-row authorization paths. v0.26 adds the missing piece: **bulk-grant lanes** for the "you work here, so you see everything in your scope" case. Org admins, team members, and other tenant-scoped staff no longer need a per-event relationship row to be authorized for a namespace.

```ts
authz: {
  namespaces: {
    eventScope: {
      prefix: '/event/:eventId',
      via: [
        'attendeeOf',                       // per-event relationship
        'organizerOf',                      // per-event relationship
        { roles: ['admin', 'owner'] },      // org-role bulk grant
        { team: true },                     // active-team-membership bulk grant
      ],
    },
  },
}
```

Lanes resolve in declaration order, first match wins. Per-row relationships and bulk-grant guards compose freely.

#### What each bulk-grant lane does

- **`{ roles: [...] }`** — passes when the caller's BA org-role for the namespace's loaded resource includes any listed role. The check is in-memory and short-circuits the relationship loop entirely. The loads-table firewall (scoped by `ctx.activeOrgId`) does the tenant isolation; this lane just adds the role precondition on top.
- **`{ team: true }`** — passes when `ctx.activeTeamId` is set. The loads-table firewall (which scopes by team for team-scoped tables) does the actual `events.teamId === ctx.activeTeamId` match during hydration. If the firewall returns no row, the request gets a contextual 404 explaining the row isn't visible to the current session — same ambiguous-by-design phrasing the firewall has always used to prevent cross-tenant ID probing.

#### Why this matters

Until v0.26, the only way to authorize an org admin for a namespace was to write `access.or: [{ via: 'attendeeOf' }, { roles: ['admin', 'owner'] }]` on every individual action under it. That OR-arm shim worked but defeated the purpose of namespaces — the whole point of hoisting the gate was to write the auth rule once. Now you do.

#### Rich deny payloads

The 403 response when every lane misses lists every path the caller could have taken — relationship names, role names, and `"team-membership"` for `{ team: true }` lanes — in the `required` field. A developer hitting an unexpected 403 sees the full set of authorization options they need to satisfy, not a generic "Insufficient permissions" wall.

The 404 from hydration (when the loads-table firewall filters the request out) now includes a hint explaining that the row may exist out of scope, and a `details` field with the resource name and key, so a developer working in their own environment has enough to debug.

#### Compile-time guards

- **Pure bulk-grant namespaces** (no relationship lane at all) are accepted as long as `loads:` + `exposeAs:` are declared directly on the namespace. With at least one relationship lane present, those fields are inherited from the relationship — declare them on the namespace itself only when no relationship lane is available to anchor hydration.
- **Heterogeneous `loads:` between relationship lanes is rejected** — `ctx.<exposeAs>` must always hydrate the same table regardless of which lane matched.
- **`namespace.loads` that disagrees with the inherited value is rejected** with a clear "drop one or align the other" message.

## v0.25.0 — May 19, 2026

### Multi-lane namespace gates: more than one way to be authorized

v0.24 lets you hoist a namespace gate to the project level via `authz.namespaces.<name>.via: 'attendeeOf'` — one relationship-resolver middleware running once per request for every action under `/event/:eventId/*`. That works when there's exactly one way to be authorized for the resource. It breaks the moment you have **two**: an attendee row and a per-event organizer row, say. The shim today is to OR the second check inside every individual action's `access` block, which puts you back to writing the gate over and over.

v0.25 widens `via:` to accept an array of relationship lanes. The middleware tries each in declaration order, and the first one whose subject row matches authorizes the request and hydrates `ctx.<exposeAs>`.

```ts
authz: {
  relationships: {
    attendeeOf: {
      from: 'guests',
      subject: { column: 'linkedUserId', equals: 'ctx.userId' },
      resource: { column: 'eventId' },
      where: { status: 'confirmed' },
      loads: 'events',
      exposeAs: 'event',
    },
    // Per-event named organizers. The subject can be a user OUTSIDE
    // the event's organization — e.g. a freelance event manager.
    organizerOf: {
      from: 'eventOrganizers',
      subject: { column: 'linkedUserId', equals: 'ctx.userId' },
      resource: { column: 'eventId' },
      loads: 'events',
      exposeAs: 'event',
    },
  },
  namespaces: {
    eventScope: {
      prefix: '/event/:eventId',
      via: ['attendeeOf', 'organizerOf'],   // first match wins
    },
  },
}
```

The thing this actually unlocks isn't "two checks instead of one." It's **per-event grants for users outside the owning organization** — external co-organizers, freelance event managers, partner staff. They don't need a `member` row in the event's org; they just need a row in `event_organizers` for that specific event. The horizontal axis (org / team membership) stays for "staff at this company"; the new vertical axis (per-event relationships) handles "specifically connected to this event," regardless of payroll.

#### Backward compatible

The string form keeps working — `via: 'attendeeOf'` is sugar for `via: ['attendeeOf']`. No existing namespaces break; opt into multi-lane by switching to the array form when you actually need it.

#### Compile-time guards

The validator rejects three things at parse time:

- **Undeclared lane names** — every entry in the array must resolve to an `authz.relationships[*]` declaration.
- **Lanes that disagree on `loads:` or `exposeAs:`** — if attendeeOf loads `events` as `ctx.event` and organizerOf loads `agendaItems` as `ctx.agendaItem`, downstream handlers can't predict what's in `ctx.<exposeAs>`. Lanes in one namespace must hydrate the same shape.
- **Empty arrays** — at least one lane is required (otherwise the namespace gate is meaningless).

#### Follow-up: v0.26 bulk-grant lanes (shipped same day — see above)

The full 4-lane shape adds heterogeneous `via:` arrays accepting `{ roles: ['admin', 'owner'] }` and `{ team: true }` entries, so org admins and team members get the gate without writing relationship rows. v0.25 was the foundation; [v0.26](#v0260--may-19-2026) lifted the existing per-action `access.or: [..., { roles: [...] }]` shim into the namespace and landed same-day.

## v0.24.0 — May 19, 2026

### Cross-feature namespaces: one hoisted gate, many features

v0.23 shipped `defineTable({ namespace: { prefix, via } })` — a hoisted relationship-resolver middleware that gates every standalone action in *one feature's* Hono app. That covers the 95% case where a domain concept (events) and the actions under it all live in the same feature directory.

v0.24 lifts the namespace to the project level so it can span multiple features. A new `authz.namespaces` block on `quickback.config.ts` declares a path-prefix gate that any feature's standalone action can participate in by matching the prefix in its `path:`. One synthetic routes file, one resolver mount, one relationship match per request — regardless of how many feature directories contribute actions.

```ts
// quickback.config.ts
authz: {
  relationships: {
    attendeeOf: {
      from: 'guests',
      subject: { column: 'userId', equals: 'ctx.userId' },
      resource: { column: 'eventId' },
      loads: 'events',
      exposeAs: 'event',
    },
  },
  namespaces: {
    eventScope: { prefix: '/event/:eventId', via: 'attendeeOf' },
  },
}

// features/feeds/actions/feed-moments.ts  (cross-feature)
export default defineAction({
  path: '/event/:eventId/feed-moments',
  method: 'POST',
  // No gate boilerplate. ctx.event is typed.
});

// features/rsvp/actions/respond.ts  (different feature, same namespace)
export default defineAction({
  path: '/event/:eventId/respond',
  method: 'POST',
});
```

The compiler emits one `src/routes/__namespace-event-scope.routes.ts` mounted at `/api/v1/event/:eventId/*`. The file imports each contributing feature's `actions` map under a distinct alias (`feedsActions`, `rsvpActions`), runs the `attendeeOf` resolver once per request at the head of the file, and dispatches to the matching action handler.

#### Discovery is path-prefix-only

No new `namespace: 'eventScope'` field on `defineAction`. Actions opt in by matching `path:` against a declared namespace prefix — same model the table-level v0.23 form uses, just lifted to the project level. This means actions move in/out of the namespace based on their path strings, which is the simplest discovery story and matches today's convention (filenames and paths are already the discoverable surface).

#### Source-feature stays the action's home for metadata

OpenAPI tags, MCP tool grouping, and CMS form discovery continue to bucket each action under its source feature. Only the *runtime routes file* moves to the synthetic location — the feed-moments action is still tagged "feeds" in OpenAPI, the response shape doesn't change, and your generated SDK reads identically. The URL conveys the namespace membership without forcing every layer of the compiler to re-anchor the action.

#### Worker-root mount order

Synthetic namespace routes files register at priority `20` — ahead of per-feature mounts (priority `0`/`10`). `sortRoutesBySpecificity` keeps the order stable, and the namespace prefix's path parameter makes it sort more specific than `/api/v1/<feature>` anyway, so the middleware fires first for every request under its prefix.

#### Compile-time guardrails

The same v0.23 invariants apply at the project level, with two additions:

- **`via:` must point at a declared `authz.relationships[*]` entry**, and that relationship must declare `loads + exposeAs` — without `loads` there's nothing for the middleware to hydrate, and a namespace that only gates without hydrating is indistinguishable from a per-action access rule.
- **`prefix:` must contain at least one `:param` segment** — middleware runs before input parsing, so the relationship key comes from `c.req.param()`.
- **Same-name conflict** between `defineTable({ namespace })` and `authz.namespaces.<sameName>` is rejected. Pick one declaration site.
- **Ambiguous prefixes** like `/a/:x` and `/a/:y` (same shape, different `:param` names) error at compile time. Strict super/sub-set relationships (e.g. `/event/:e` and `/event/:e/admin`) are fine — the harvester routes each action to the longest matching prefix.
- **Unused namespace warning** emits `[quickback:authz]` when no standalone action's path matches a declared prefix. Not a hard error — the namespace may be staged ahead of the actions.

#### Picking the right declaration site

The table-level v0.23 form is now the **single-feature shorthand**. The project-level v0.24 form is **canonical for cross-feature**.

- **Use `defineTable({ namespace })`** when every action under the prefix lives in the same feature directory. The namespace travels with the table that owns it; nothing to add to `quickback.config.ts`.
- **Use `authz.namespaces`** when the namespace spans features. The declaration sits next to your `authz.relationships` and `authz.roles` — the canonical home for cross-cutting authz config.

The two forms can't coexist for the same namespace name. If a v0.23 table-level namespace is starting to attract cross-feature actions, lift it to `authz.namespaces` — same shape, just at the project level, and the matching paths in other features will join automatically.

#### Migration

Zero breaking changes. Nothing in v0.23 needs to change for v0.24 to land. The new field is opt-in; existing projects pick it up the moment they declare an `authz.namespaces` entry.

The harvester runs after Zod schema validation but before route generation, so unused or misconfigured namespaces surface immediately as errors or warnings rather than as silently-broken routes.

#### Fixes shipped alongside

The first two were load-bearing for v0.23 namespaces to actually work — projects upgrading from a pre-fix v0.23 will see crashes/compile errors disappear on the v0.24 recompile.

- **No more dual emission of namespace-claimed standalone routes.** Pre-fix, an action with a cross-feature path like `/event/:eventId/agenda/list-my-agenda` emitted into both `src/index.ts` (without the namespace resolver) and the synthetic file (with it). The plain root copy in `src/index.ts` won every URL match and `ctx.<exposeAs>` was never hydrated — every request 500'd with `Cannot read properties of undefined (reading 'id')`. `extractStandaloneActions` now skips namespace-claimed actions; the synthetic namespace file is the sole emission.
- **Stripped-path validator no longer rejects namespace-claimed actions.** The synthetic file mounts at `/api/v1${namespace.prefix}` and strips the prefix from each action's local path. The per-action relationship-resolver was validating the *stripped* path for `:eventId`, finding nothing, and rejecting every namespace-mounted action with "action's surface exposes neither a path parameter ':eventId' nor an input field 'eventId'". `planRelationshipResolver` now receives the namespace's `via` and skips its surface-key check entirely — the hoisted middleware is the single source of truth.
- **Broadcaster DO migration tag consistent across `realtime.mode`.** Inline-mode emission was already going through `qb-do-${className}` + `new_sqlite_classes`. Separate-mode was still hardcoded `tag = "v1"` + `new_classes`, so flipping `realtime: { mode }` produced different migration tags for the same DO class and tripped CF error 10074 ("class already depended on") on cross-mode deploys. Both modes now emit `tag = "qb-do-Broadcaster"` + `new_sqlite_classes`.
- **Batch handler id arrays type-derive from the input parser.** Pre-fix, `validIds`, `recordMap`, and `validEntries` in bulk-delete / bulk-update / bulk-upsert were hardcoded `string[]` / `Map<string, any>` even when the table's PK column was `integer("id")` — 274× TS2769 in projects mixing string and integer PKs. Handlers now declare `type IdT = typeof ids[number]` (or `typeof records[number]['id']`) and use it for the local id types. Strings stay strings, integers stay integers, no emitter knowledge of the PK column type required.
- **`ctx` in action handlers is now `AppContext`, not `any`.** Both `StandaloneExecuteParams.ctx` and `RecordExecuteParams.ctx` in the generated `<feature>/.quickback/define-action.ts` are typed `AppContext`. AppContext keeps its `[key: string]: any` index signature so hydrated namespace keys (`ctx.event`, `ctx.<exposeAs>`) stay accessible without TS2339; named fields (`userId`, `activeOrgId`, `roles`, `authenticated`, `user`) get autocomplete and type-checking. Cleared ~49× TS2339 in generated projects.
- **`c.get('ctx') as AppContext` in every emitted route handler.** Pre-fix, `const ctx = c.get('ctx')` returned `any`, so `ctx.roles?.some(r => …)` left the callback parameter implicitly `any` — 16× TS7006. Now `ctx.roles` is `string[] | undefined`, `r` is `string`, no callback annotation needed.

#### Deferred (tracked, not blocking)

- Per-namespace narrow typing of `ctx.<exposeAs>` (so `ctx.event` resolves to `typeof events.$inferSelect` instead of `any`). The compiler emits a typed cast at the `execute()` call site in the routes file today, which type-checks the call but not the handler body. Full narrow typing requires per-namespace helper emission (one `define-action.<namespace>.ts` per namespace, or a generic param threading through the action config). Tracked separately.

---

## v0.23.0 — May 19, 2026

### Authz relationships: compile-time guarantees, less boilerplate, hoisted middleware

This release closes the gap between what `authz.relationships` *promised* in v0.19 and what it actually enforced. Every documented invariant is now a real compile-time check; every per-action ergonomic friction has a fix. Net effect: relationship-based authorization feels native — declare the relationship once, use the role anywhere, the compiler does the wiring.

#### Compile-time guarantees (the authz `firewall` parity)

The org/owner/team firewall has always been compile-time-checked: a routed resource without a scope fails the compile, full stop. As of this release, `authz.relationships` carries the same guarantees:

- **Bad `via:` names fail at parse time.** A typo in a firewall predicate (`firewall: [{ field: 'eventId', via: 'guestOff' }]`) used to surface deep inside the firewall generator after most validation had passed. It's now caught alongside the `authz.roles` `via:` validation, same layer, same error format.
- **Relationship-from tables can't opt out.** The doc at `define/types/authz.ts:73-74` always said a relationship `from:` table with `firewall: { exception: true }` "refuses to compile" — that's now enforced. Without this check, every `via:` subquery that pivots through an exception-marked table loses tenant isolation and can return rows from other tenants.
- **`allowResourceMigration` is now mandatory** when the relationship's `resource.column` is on a writable update endpoint. A guest doing `PATCH /messages/:id { eventId: <other-event-id> }` to migrate a row out of their access scope used to slip past the runtime — it now fails compile with a three-option remediation (set the flag, mark the column immutable, or drop it from the guards.updatable allowlist).
- **`via: string[]` in firewall predicates.** "Member of attendees OR speakers" no longer requires inventing a composite role just to use it once in a firewall — `firewall: [{ field: 'eventId', via: ['attendeeOf', 'speakerOf'] }]` lowers to an OR-combined subquery.

#### Less boilerplate: auto-derivation + realtime resolver

- **`resource.column` auto-derives from FKs.** Omit it and the compiler scans the relationship's `from:` table for foreign-key columns, drops the `subject.column`, and picks the remaining FK. One match → auto; zero or many → error with the candidate list. Pattern mirrors the existing firewall auto-detection.
- **`realtime.requiredRoles` accepts authz roles.** Previously a relationship-role in `realtime.requiredRoles` fell through with a misleading "unknown role" error. The compiler now flattens declared authz roles into their composing Better Auth roles before the realtime ticket-handshake sees them. Relationship-only roles (no static BA fallback) emit a `[quickback:authz]` warning and fail-close at handshake — the row-stream firewall continues to enforce the relationship dimension on the data side.

#### Record-based actions can finally use relationship-roles

The v0.19 fail-closed hardening had an unintended side effect: a record-based action with `access: { roles: ['attendee'] }` (where `attendee` was a relationship-role) 403'd every caller, including the legitimate ones. The runtime helper couldn't evaluate `relationship:` arms, so it fail-closed correctly — but the inline match expression that *would* evaluate the relationship was never wired up for record-based actions.

This release routes record-based actions with relationship arms through the same inline access generator the resource CRUD path already uses. `roles: ['attendee']` on `/applications/:id/recap` now actually checks whether the caller is an attendee, with the loaded record in scope. Non-relationship access trees keep the runtime path unchanged.

#### Typed `ctx.<exposeAs>` in action handlers

When a relationship declares `loads: 'events', exposeAs: 'event'`, the runtime hydrates `ctx.event` with the loaded row — but the static type was always `any`, so handlers had to write `const event = ctx.event as typeof events.$inferSelect`. As of this release, when an action's access references **exactly one** relationship with `loads + exposeAs`, the compiler emits the cast for you at the execute() call site. Handlers read `ctx.event` with the right shape; no per-handler boilerplate.

Multi-arm OR actions (referencing two relationships with hydration) keep the `any` shape — we can't statically know which arm matched.

#### New: `defineNamespace` — one mount, one resolver, many actions

The marquee Wave 3 change. Today's pattern for "five standalone actions under `/event/:eventId/*` all gated by `attendeeOf`" requires writing the same inline relationship resolver in each action — and pays the resolver cost (one subquery, one row-load) on every request, multiplied by N actions. The new `namespace` field on `defineTable` hoists the resolver into a single Hono middleware mount:

```ts
// features/events/events.ts
export default defineTable(events, {
  firewall: [...],
  crud: { ... },
  namespace: {
    prefix: '/event/:eventId',   // absolute URL path the mount covers
    via: 'attendeeOf',            // relationship gate
  },
});

// features/events/actions/post-announcement.ts
export default defineAction({
  path: '/event/:eventId/announcements',
  method: 'POST',
  // No relationship-gate boilerplate. ctx.event is typed
  // `typeof events.$inferSelect` inside execute().
});
```

The compiler:
1. Emits one `app.use('/:eventId/*', async (c, next) => { /* relationship resolver */; await next(); })` at the head of the feature's standalone-routes file (path-prefix stripping handles the feature mount).
2. Skips the inline relationship resolver in every per-action handler under the prefix — the middleware already ran it.
3. Hydrates `ctx.event` once per request and threads the typed cast into every namespace action's execute() call.

**Validation guardrails:**
- `namespace.via` must point at a declared `authz.relationships[*]` entry.
- The referenced relationship must declare `loads + exposeAs` — without `loads` there's nothing for the middleware to hydrate, and the namespace gate would be indistinguishable from a per-action access rule.
- `namespace.prefix` must contain at least one `:param` segment — the middleware reads the relationship key from `c.req.param()`, not from request body (body parsing hasn't run at middleware time).

**Scope (v1):**
- Namespace lives within a single feature's Hono `app`; cross-feature shared namespaces are deferred to v2.
- One namespace per `defineTable` declaration; multiple namespaces in a feature mount as siblings.
- For namespace actions whose access references additional relationships beyond the namespace's via, the inline resolver still fires for those — namespace handles only its own.

#### Migration

Nothing in v0.20 → v0.23 breaks existing code that compiles cleanly. The new errors fire only against patterns that were already latent bugs:

- A `via:` typo that previously surfaced as a deep codegen error now surfaces at parse time, same message.
- A `firewall: { exception: true }` on a relationship-from table now errors; this configuration was always documented as unsupported.
- A relationship's `resource.column` writable on the resource's UPDATE endpoint now errors unless `allowResourceMigration: true` is set; previously this was a runtime escape hatch.
- Record-based actions with `roles: ['<relationship-role>']` previously 403'd every caller; they now work as the v0.19 docs originally promised.

#### Why this matters

Authz relationships are how Quickback expresses "the caller is allowed to touch this resource because of a row in *that* table" — guest-of-event, member-of-organization, scorer-of-interview. Until now, the feature worked but had sharp edges: typos surfaced late, the documented exception-not-allowed constraint wasn't enforced, and the namespace pattern (which most apps with nested resources end up wanting) required repeating the same gate in every action. This release brings authz to parity with the org/owner/team firewall: declare it once, the compiler enforces it everywhere, the runtime emits exactly one query per request.

---

## v0.22.0 — May 19, 2026

### Quickback Stack is Cloudflare-only: one runtime, two databases, one auth provider

We've focused the platform on the stack we actually believe in: **Cloudflare Workers + Hono + Better Auth**, with **Cloudflare D1** or **Neon** as the database. Providers and modes that targeted non-Cloudflare backends are gone. The result is a smaller concept set, fewer footguns, and clearer docs.

#### What's been removed

- **Runtimes**: `bun` and `supabase-edge` are no longer supported. The only runtime is `cloudflare`. Local development for compiled projects has always used `wrangler dev` — that's unchanged.
- **Databases**: `supabase`, `libsql`, `better-sqlite3`, `bun-sqlite` are removed. Use `cloudflare-d1` for SQLite at the edge or `neon` for PostgreSQL via Hyperdrive.
- **Auth providers**: `supabase-auth` is removed. `better-auth` is the default; `external` (Cloudflare service binding) remains for advanced setups.
- **Template**: `template: 'nextjs'` is removed from the public config type. It was never fully implemented. The only template is `'hono'`. If you need a Next.js frontend, bring it as a separate deploy and call the Quickback API, or drop a static export into the `apps:` mount.
- **Quickback for Supabase RLS** product line is retired. The compiler no longer emits Supabase Row Level Security policies. The `/products/quickback-supabase-rls/` and `/for/supabase-users/` pages have been removed from the marketing site, and the `compiler/targets/supabase-rls/` docs section has been deleted.

#### Account UI: one delivery mode

The standalone `quickback-better-auth-account-ui` npm package has been **deprecated** and the upstream GitHub repo (`Kardoe-com/quickback-better-auth-account-ui`) has been **archived**. Account UI is now exclusively delivered the way 99% of projects already use it: the compiler builds it from source and bundles it into your Worker.

- `account: { domain: 'auth.example.com', ... }` in `quickback.config.ts` — that's the entire integration story.
- The compiler builds the SPA inside Docker with your branding and feature flags baked in, emits hostname-based routing, and wires cross-subdomain cookies automatically.
- The three standalone delivery-mode docs (`stack/account-ui/standalone`, `library-usage`, `worker`) are removed; the remaining pages explain the compiler-bundled flow.

If you previously deployed the standalone Account UI Worker against a Quickback backend, switch to `account: { domain }` in the config — same end result, one less deploy.

#### `VITE_AUTH_ROUTE` hardcoded to Quickback

The `VITE_AUTH_ROUTE` env var (which used to switch between `quickback` and `better-auth` routing dialects) is gone. The auth-client always uses Quickback's namespaced routes (`/auth/v1`, `/api/v1`, `/storage/v1`). Generic Better Auth backends are no longer a supported target. Removing the var also closes a known footgun where setting the wrong value silently 404'd every auth call.

#### New: every config option is now discoverable

When you bootstrap a project, the kitchen-sink marker block in `quickback.config.ts` lists every option Quickback supports — with descriptions and sensible defaults — commented out for you to copy above the marker as needed. Three top-level options were missing from this discovery surface and are now included:

- **`apps`** — mount your own prebuilt SPA on its own hostname (`apps: { www: { domain: 'www.example.com', aliasDomains: ['example.com'] } }`). Drop the build at `quickback/apps/<name>/` and the compiler serves it from your Worker alongside the API. Reserved names: `cms`, `account`, `public`.
- **`security`** — HTTP security headers (CSP, COOP, COEP, HSTS, Referrer-Policy, Permissions-Policy, X-Frame-Options). Set `security: false` to suppress everything; defaults are sensible for the embedded SPAs.
- **`authz`** — relationship-based authorization roles. Declare joins between the caller and a resource column, then bind role names to those joins for use in `access: { roles: [...] }`.

#### Migration

Projects that compile cleanly against v0.21 and use any of these providers will hit a clear error at compile time:

```
Unknown database provider: "supabase". Available: cloudflare-d1, neon
```

To migrate:

1. **From Supabase**: switch `providers.database` to `cloudflare-d1` or `neon`, and `providers.auth` to `better-auth`. Your `defineTable()` definitions transfer as-is; the security DSL (firewall, access, guards, masking) compiles to Better Auth + Drizzle queries instead of RLS policies.
2. **From Bun runtime / `bun-sqlite`**: switch `providers.runtime` to `cloudflare` and `providers.database` to `cloudflare-d1`. Local dev becomes `wrangler dev`.
3. **From libsql / Turso**: switch to `cloudflare-d1` or `neon`. Both run natively from Cloudflare Workers via the right binding.
4. **From `template: 'nextjs'`**: deploy Next.js separately and call the Quickback API, or drop a static export into `apps:`.

#### Why this matters

The Quickback Stack is the Supabase alternative for Cloudflare. Every Quickback project ships a Hono API, an Account SPA, a CMS SPA, optional realtime/storage/queues — all built from one config and bundled into one Worker. Keeping that promise focused is more valuable than supporting deployment targets that don't share the runtime.

---

## v0.21.0 — May 19, 2026

### Auto-firewall column swap: `ownerId` is now canonical on feature tables, `userId` warns

The compiler's default auto-firewall column for feature tables flips from `userId` to `ownerId`. This closes a long-standing footgun where a `userId` column meaning "a user this row references" (a member, a contact, an invitee) got silently clobbered with `ctx.userId` on insert, because the wrapper matched purely on column name across every table in the project.

**What changed in the compiler**

- `BETTER_AUTH_DEFAULTS.owner.column`: `'userId'` → `'ownerId'`. Schemas with an `ownerId` column auto-resolve to `firewall: [{ field: 'ownerId', equals: 'ctx.userId' }]` and have `ownerId` auto-stamped on insert.
- The generated `OWNER_SCOPE_RULES` in `src/lib/scoped-db.ts` is seeded with `ownerId` instead of `userId`. Schemas that don't explicitly name `userId` in a `firewall:` block no longer trigger the global `userId`-stamping rule — the most common collision goes away without renames.
- A new compile-time warning fires when a feature table carries both an auto-resolved isolation column AND a `userId` column. The warning recommends renaming the column to `linkedUserId` (or similar) if it's informational, or declaring `firewall: [{ field: 'userId', equals: 'ctx.userId' }]` if it really is the access boundary on that table.
- The targeted compile-time error for "the only candidate column is `userId`" now points users at `ownerId` and the explicit-firewall escape hatch. The previous error wording (which assumed `ownerId` was business-logic) is removed.

**What stayed the same**

- Better Auth's own internal tables (`session`, `account`, `member`, `passkey`, `subscriptions`) still use `userId` by convention. They aren't feature tables and don't pass through the auto-firewall.
- Explicit `firewall: [{ field: 'userId', equals: 'ctx.userId' }]` declarations continue to work and are still recognized as the "owner" pattern in the generated comment header.
- The `USER` pseudo-role validator behaviour is unchanged; only the error-message wording flips to lead with `ownerId` and list `userId` as the explicit fallback.
- Audit-wrapper (`createdBy` / `modifiedBy`) behavior is untouched.

**Migration**

Projects that auto-firewalled on a `userId` column will see a hard error on next compile telling them which table is affected, with two suggested fixes:

1. **Recommended**: rename the column to `ownerId` in the schema. Cleanest semantics — readers immediately understand the column is access-control.
2. **Explicit firewall**: keep the `userId` column and add `firewall: [{ field: 'userId', equals: 'ctx.userId' }]` to the resource. The auto-stamping and auto-scoping still happen; you've just opted in by name.

Projects that have a `userId` column meaning "a user this row references" no longer need the `linkedUserId` rename workaround — auto-stamping won't touch the column unless you name it in a firewall block. The new warning makes this audit-discoverable.

**Caveat (deferred)**: explicit `firewall: { owner: { column: 'X' } }` declarations still populate the project-global `OWNER_SCOPE_RULES` list, so a hand-named owner column on one resource will still match by name on every other table that happens to have a column called `X`. A future release will make scope-rule resolution per-table rather than project-global. The warning text calls this out so callers know what to expect.

---

## v0.20.0 — May 19, 2026

### CMS + Account SPAs: shadcn base-ui migration, central Tailwind config

Both first-party SPAs are now on the shadcn **base-ui** variants (`@base-ui/react`) instead of the Radix-based primitives, applied via shadcn preset **`bdvxIkMq`** (style `base-mira`, `baseColor: zinc`, `iconLibrary: remixicon`, Inter Variable font). The migration also collapses the previously duplicated per-SPA theme + `components.json` into a single source at `packages/ui/`.

#### Single source of truth in `packages/ui/`

Both SPAs were independently declaring the same `@theme` / `:root` / `.dark` token blocks in their own `app.css`, and each had its own `components.json` pointing at non-existent local component directories. That's gone:

- `packages/ui/styles/theme.css` — the only place tokens live. Includes the base-mira palette, sidebar + chart tokens, and the Inter font import.
- `packages/ui/components.json` — the only shadcn config in the repo. Future `pnpm dlx shadcn@latest add <name>` runs from `packages/ui/`.
- `packages/cms/app/app.css` and `packages/account/app/app.css` reduce to two imports plus SPA-specific layers (CMS keeps its AG Grid + richtext-display overrides). `packages/{cms,account}/components.json` deleted.

#### Components, icons, deps

- All 22 shadcn primitives regenerated against `@base-ui/react` (`@radix-ui/*` removed everywhere). `Drawer` stays on `vaul` — base-ui has no Drawer primitive.
- Icons migrated from `lucide-react` to `@remixicon/react` line variants across ~100 source files (`Plus → RiAddLine`, `ChevronDown → RiArrowDownSLine`, `X → RiCloseLine`, etc.). `lucide-react` removed from all `package.json` + `deps-spa-*` files.
- `pnpm.overrides` pin `@types/react ^19.2.0` workspace-wide to resolve the duplicate-React-types conflict introduced by `@base-ui/react`'s bundled type peer.
- Per-SPA deps and the Docker build mirrors (`apps/compiler/deps-spa-{cms,account}-package.json`) both gain `@base-ui/react`, `@remixicon/react`, `@fontsource-variable/inter`, and bump `shadcn` to `^4.7.0`.

#### Backwards-compat `asChild` shim

Base-ui replaces Radix's `asChild` boolean with a `render={<X />}` prop. To avoid rewriting ~44 caller sites, the shadcn-generated wrappers for `Button`, `DropdownMenuTrigger`, `DropdownMenuItem`, and `PopoverTrigger` carry an `asChild?: boolean` prop that delegates to base-ui's `render` API when set:

```tsx
// Caller code keeps working as-is:
<Button asChild>
  <Link to="/foo">Click</Link>
</Button>
```

`ResponsiveModal` survived the migration unchanged — it composes the higher-level Dialog + Drawer wrappers (preserved public API), not the underlying primitives.

#### Caller-side API changes worth noting

Base-ui ships some real behavioural changes the Radix variants didn't:

- `<Select onValueChange>` now receives `(value: string | null, eventDetails) => void` (was `(value: string) => void`). Existing `Dispatch<SetStateAction<string>>` setters reject `null` — wrap callbacks defensively: `onValueChange={(v) => v != null && setX(v)}`.
- `<DropdownMenuContent forceMount>` removed (base-ui has no `forceMount`). Use base-ui's `keepMounted` on the Popup/Positioner if you need to preserve unmounted state.
- Component sub-names shifted (`Dialog.Content` → `Dialog.Popup`, `Dialog.Overlay` → `Dialog.Backdrop`). Data attributes are now `data-open` / `data-closed` (no more `data-state="open"`).

#### Adding a new primitive after this release

```bash
cd packages/ui
pnpm dlx shadcn@latest add <component> --overwrite --yes
# Sweep generated `@/` imports to relative paths — the SPAs' vite-tsconfig-paths
# plugin doesn't see packages/ui's @/* mapping at bundle time:
sed -i.bak \
  -e 's|"@/lib/utils"|"../lib/utils"|g' \
  -e 's|"@/components/|"./|g' \
  -e 's|"@/hooks/|"../hooks/|g' \
  components/<component>.tsx && rm components/<component>.tsx.bak
```

If the new primitive pulls in fresh deps, mirror them into `apps/compiler/deps-spa-{cms,account}-package.json` per the SPA build pipeline or Docker SPA builds will fail.

---

## v0.18.1 — May 18, 2026

### Account SPA — teams, active-team picker, permission-aware UI

The Account SPA's organization surface is now feature-parity with Better Auth's `organization` plugin for the basic team workflow, and replaces the long-standing hardcoded `role === 'owner' || 'admin'` checks with `checkRolePermission` so projects that ship custom roles get a UI that respects them.

#### Teams (opt-in)

When the BA config enables teams — `organization({ teams: { enabled: true } })` — the compiler emits `VITE_ENABLE_ORG_TEAMS=true` and the Account SPA exposes a Teams tab on each organization:

- **Teams index** (`/$slug/teams`) — splits into "Your teams" (from `listUserTeams`) and "Other teams" so non-admins land on what's relevant. Create / rename / delete from the list, gated on `team:create` / `team:update` / `team:delete`.
- **Team detail** (`/$slug/teams/$teamId`) — member roster with add / remove, joining `listTeamMembers` against the org's full member list for display.
- **Active-team picker** in the org header — calls `setActiveTeam` and exposes the choice via `OrganizationContext.activeTeamId` so downstream routes (and the BA `session.activeTeamId` server-side) stay in sync.
- **Team-aware invites** — `InviteMemberDialog` shows an optional team picker when teams are on and forwards `teamId` to `inviteMember`, so accepting the invite drops the new member straight into the right team.

Teams are loaded once by the `$slug` layout (`listTeams` + `listUserTeams`) and exposed via `OrganizationContext.teams` / `userTeamIds` / `refreshTeams`, so individual team routes don't re-fetch the list.

#### Permission-aware UI via `checkRolePermission`

`OrganizationContext.isOwnerOrAdmin` is gone. Routes now read `can(resource, action)` from context, which delegates to `authClient.organization.checkRolePermission` — synchronous, no roundtrip, and aware of any custom roles registered via the BA `ac` option. Multi-role users (BA stores multiple roles comma-separated) are handled by checking each role; the action is allowed if any role grants it.

Migrated sites:

- `$slug.tsx` tab gates → `can('invitation', 'create')`, `can('organization', 'update')`
- `members.tsx` action menu → `can('member', 'update' | 'delete')`; the owner-hierarchy guard (non-owners can't touch owner-role members) is preserved as a client-side mirror of BA's server enforcement
- `invitations.tsx` → `can('invitation', 'create' | 'cancel')` gates the Invite button, resend, and cancel separately
- `settings.tsx` → `can('organization', 'update')` for the form, `can('organization', 'delete')` for the danger zone (was owner-only)
- `teams.tsx` / `teams.$teamId.tsx` → `can('team', 'create' | 'update' | 'delete')`

Projects on the default three-role hierarchy see no behaviour change; projects that defined `admin`/`member` overrides via BA's access-control API now get a UI that matches what the server will actually authorize.

#### Editable slug + metadata on organization settings

The `$slug/settings.tsx` form now edits two more `organization.update` fields:

- **URL slug** — full debounced `checkSlug` flow (mirroring the create-org form); on rename, the SPA navigates to `/${newSlug}/settings` and the layout re-fetches with the new slug.
- **Metadata** — single `Record<string, any> | null` JSON textarea, parsed on submit with inline error messaging. Empty clears the field.

Slug rename is non-breaking for the SPA itself, but every external link / bookmark that references the old slug becomes a 404 — the form warns about this before saving.

#### Auth client wiring

When `VITE_ENABLE_ORG_TEAMS=true`, the SPA's `organizationClient(...)` is instantiated with `teams: { enabled: true }` so the team APIs are typed end-to-end. When the flag is off, team methods aren't surfaced — and the Teams tab is hidden — keeping the bundle and UI honest about what the server actually supports.

---

## v0.18.0 — May 17, 2026

### `config.apps` — mount user-authored SPAs on dedicated hostnames

The compiler now generates per-hostname Worker middleware for arbitrary user SPAs alongside the built-in CMS and Account UIs. Previously the only way to host a product app next to a Quickback API was a second Worker; `config.apps` brings the full stack — API, account, and product UI — onto one deployment with same-origin auth.

```ts
apps: {
  www: {
    domain: "www.example.com",
    aliasDomains: ["example.com"], // apex serves the same SPA
  },
}
```

Each entry binds one or more hostnames to a directory under `src/apps/<name>/` and inherits the Account-domain pass-through behavior — `/api/`, `/auth/`, `/admin/`, `/storage/`, and `/health` route to Hono so the SPA fetches its API without CORS. The compiler:

- emits a `custom_domain = true` route in `wrangler.toml` for the primary hostname and every alias
- adds each hostname to Better Auth's `TRUSTED_ORIGINS` (when `trustedOrigins` is left unset)
- widens the CSP `connect-src` to cover the SPA-baked origins
- folds the new hostnames into shared-parent detection for `crossSubDomainCookies`

Drop the prebuilt SPA bundle at `quickback/apps/<name>/` — the existing source-apps passthrough copies it byte-for-byte into `src/apps/<name>/`. The compiler doesn't build the SPA; it only emits routing for whatever's already there. The names `cms`, `account`, and `public` are reserved; hostname collisions with `cms.domain` / `account.domain` / `account.adminDomain` or between two `apps[*]` entries fail at compile time.

When `cms` and `account` are both configured, the multi-domain catchall now explicitly skips app hostnames — an API miss on an app host returns the standard 404 JSON via `app.notFound` instead of stray-serving a sibling SPA's HTML shell.

### Cross-subdomain cookie inference handles apex aliases

The shared-parent detection that drives `advanced.crossSubDomainCookies` previously reduced any hostname by stripping the leftmost label — `'example.com'` collapsed to `'com'`, which broke equality against sibling subdomains. Apex hostnames (exactly two dot-segments) are now treated as already being the parent, so apex aliases (`example.com` listed alongside `www.example.com`) coexist cleanly with `auth.example.com` / `cms.example.com` and the compiler still emits `crossSubDomainCookies: { enabled: true, domain: '.example.com' }`.

---

## v0.17.2 — May 15, 2026

### `customPlugins` escape hatch on `defineAuth("better-auth", …)`

The Better Auth provider now accepts `customPlugins` alongside the named-plugin registry — a path to ship third-party plugins (`@better-auth-kit/audit`, …), unregistered built-ins, or one-off project-local plugins without forking the compiler.

Each entry is an explicit import descriptor:

```ts
auth: defineAuth("better-auth", {
  emailAndPassword: { enabled: true },
  plugins: { passkey: true, organization: true },
  customPlugins: [
    // (1) Project-local plugin file at quickback/plugins/long-session.ts
    { from: "./plugins/long-session", export: "longSessionPlugin" },
    // (2) Third-party npm package
    {
      from: "@better-auth-kit/audit",
      export: "auditPlugin",
      args: { events: ["sign-in"] },
      dependencies: { "@better-auth-kit/audit": "^1.0.0" },
    },
  ],
}),
```

`from` is either a relative path under `./plugins/` (the CLI auto-uploads matching files from `quickback/plugins/`; the compiler copies them into `src/plugins/<name>.ts` and rewrites the emitted import) or a bare npm specifier (emitted verbatim; declare `dependencies` so the package lands in the generated `package.json`). Omit `args` to emit the symbol uncalled (plugin instance); provide `args` to emit a JSON-serialized factory call.

The descriptor is validated with Zod — typos in `from`/`export`, paths that escape `./plugins/`, and references to files the CLI didn't ship all fail at compile time with a targeted message.

---

## v0.17.1 — May 14, 2026

### `quickback start` — interactive onboarding

```bash
mkdir my-app && cd my-app
npx @quickback-dev/cli start
```

`start` walks new users through template selection, scaffolds the project on disk, and only prompts for an account when it's ready to compile. Cancelling at the login prompt leaves the scaffold intact — sign in and run `quickback compile` whenever you're ready.

The same deferred-auth flow applies to `quickback create`. Scaffolding and (optional) Cloudflare D1 setup run before authentication, so you can preview the project on disk before committing to an account.

### Named views on the free tier

The `todos` template now ships a `dashboard` named view, exposing a projected response at `GET /api/v1/todos/views/dashboard`. Named views support per-view access rules and per-view field selection while inheriting the table's firewall and masking — the canonical way to ship list-view payloads that are cheaper to fetch and easier to cache than a full collection read.

### `quickback init` removed

Folded into `start` and `create`. The legacy command name prints a deprecation notice pointing at its replacements.

### Minor

- `quickback whoami` reads the stored tier from your credentials.
- Pro upsell copy in `quickback login` is shown only when the server returns an explicit free-tier subscription.
- Bare scaffolds (`cloudflare`, `empty`) report accurately when there are no features to generate migrations for.

---

## v0.16.10 — May 14, 2026

### D1-specific safety pass on generated migrations

The `cloudflare-d1` provider now runs a post-generation pass over every Drizzle migration directory (auth, features, webhooks, audit) before the compile finishes. Better Auth cleanup for retired managed tables is stripped from raw `DROP TABLE` statements. Drop-only cleanup migrations are reordered child-first when foreign-key dependencies require it. Every generated D1 migration directory is replayed against SQLite during compile, so a D1-breaking migration fails at compile time rather than at `wrangler d1 migrations apply`.

---

## v0.16.9 — May 13, 2026

### Resource-scoped realtime tickets

`providers.database.config.realtime` accepts an object form for projects whose WebSocket subscribers aren't org members:

```ts
realtime: {
  wsTicket: {
    role: "attendee",
    requestField: "eventId",
    scopeTable: "events",
  },
}
```

The generated `/broadcast/v1/ws-ticket` route authenticates the caller, evaluates the declared relationship role against the request, and mints a short-lived WebSocket ticket scoped to the resolved resource. `realtime: true` continues to enable the org-scoped broadcaster.

### Unified broadcast targeting

The realtime helper and Broadcaster now route by `scopeKey || organizationId || userId`. String targets remain shorthand for `organizationId`; explicit targets can scope a broadcast to a resource or a single user:

```ts
await realtime.broadcast("event-page-updated", payload, { scopeKey: "events:evt_123" });
await realtime.broadcast("dm", payload, { userId: recipientId });
```

WebSocket tickets are Quickback-minted (signed with `BETTER_AUTH_SECRET`), not Better Auth tokens — Better Auth remains the front-door auth check; Quickback signs the upgrade ticket after authorization succeeds.

---

## v0.16.8 — May 13, 2026

### One auth transport per request

Generated middleware treats `Cookie`, `Authorization: Bearer`, and `x-api-key` as distinct auth methods and rejects mixed requests with `400 AUTH_METHOD_CONFLICT`. Query-string API keys (`?api_key=` / `?key=`) are no longer accepted. Machine-to-machine auth is explicit; precedence rules between transports are gone.

### Cookie-backed CSRF gate

Generated apps now block cross-site `POST` / `PUT` / `PATCH` / `DELETE` requests from cookie-relying callers. The middleware skips explicit `Authorization` clients, requires a trusted `Origin` or `Referer`, and blocks `Sec-Fetch-Site: cross-site`. This matters most for cross-subdomain session setups where `SameSite=None` is intentional.

### First-class Wrangler observability

`providers.runtime.config.observability` now supports nested `logs` / `traces` blocks for `headSamplingRate`, `destinations`, `persist`, and `logs.invocationLogs`, emitting matching `[observability]`, `[observability.logs]`, and `[observability.traces]` TOML.

---

## v0.16.7 — May 12, 2026

### Bearer wins over cookie

A request carrying both `Authorization` and a session `Cookie` resolves entirely from the bearer; the cookie is dropped before `getSession()` runs. All three Bearer flavors (API key, JWT, session-token) now behave consistently — no more silent cookie precedence on session-token bearers.

### Bearer plugin defaults to `requireSignature: true`

Better Auth's `bearer` plugin defaults to unsigned tokens; Quickback now emits `bearer({ requireSignature: true })`. Tokens emitted in the CORS-exposed `set-auth-token` header are server-signed with `BETTER_AUTH_SECRET` and verified on every request. Projects that genuinely need unsigned bearers can override via `providers.auth.config.plugins.bearer`.

See [Authentication Security → Bearer Tokens and Cookie Precedence](/stack/auth/security#bearer-tokens-and-cookie-precedence).

---

## v0.16.5 — May 12, 2026

### Flat write DSL

Resource write operations are now declared at the table level alongside `read`, replacing the nested `crud` block:

```ts
defineTable(customers, {
  read: { ... },
  create: { access: { roles: ["admin"] } },
  update: { access: { roles: ["admin"] } },
  delete: { access: { roles: ["admin"] }, mode: "soft" },
  upsert: { access: { roles: ["admin"] } },
  guards: { ... },
});
```

`crud` and top-level `put` still compile as deprecated compatibility aliases. Mixed usage on the same resource is rejected. `schema-registry.json` emits both shapes during the transition.

### CMS placement for multi-table feature actions

Standalone actions on multi-table features have an explicit placement model:

- `cms.placement: "feature"` shows the action on every table toolbar in the feature
- `cms.placement: "tables"` with `cms.tables` scopes it to specific tables
- `cms.hidden: true` keeps it API-only

Feature-root standalone actions are emitted under a new `featureActions` bucket in `schema-registry.json`. Ambiguous multi-table standalone actions without placement compile with a warning.

### `openapi.types` accepts a string array

One compile can write the generated types file to multiple locations, keeping colocated SPA clients in sync:

```ts
openapi: { types: ['api-types.gen.ts', 'apps/web/src/lib/api-types.gen.ts'] }
```

### Stable artifact ordering

Generated route files and `schema-registry.json` are emitted in a stable order across runs. Identical logical input produces identical artifacts.

---

## v0.16.4 — May 12, 2026

### Drizzle snapshot integrity

Drizzle metadata files (`<n>_snapshot.json`) are no longer stamped with a Quickback warning key. The warning is now journal-only. Projects whose snapshots were corrupted by an earlier release self-heal on the next compile — the stripped header is removed during staging and the rewritten snapshot is clean.

### `account.auth.*` drives the server, not just the SPA

The Account UI's auth flags (`signup`, `password`, `passkey`, `emailOTP`, `emailVerification`) now configure the Better Auth server alongside the SPA bundle. A normalizer maps them into the server config:

- `signup → emailAndPassword.disableSignUp` (inverted)
- `password → emailAndPassword.enabled`
- `emailVerification → emailAndPassword.requireEmailVerification`
- `passkey` / `emailOTP` → plugin additions

The SPA's `VITE_ENABLE_*` flags are derived from the same canonicalized server config, so the bundle and the server cannot drift. Two new flags ride along: `VITE_ENABLE_API_KEYS` and `VITE_ENABLE_MAGIC_LINK`.

**Breaking** for projects that implicitly relied on the SPA-only behaviour: `account.auth.signup: false` now actually disables `POST /auth/v1/sign-up/email` on the server. Set `providers.auth.config.emailAndPassword.disableSignUp: false` explicitly to keep server signup open while hiding the SPA screen.

---

## v0.16.3 — May 9, 2026

### Standalone action mount order

Feature-level standalone action routers now register before sibling CRUD routers when both mount at the exact same prefix. A literal path like `GET /api/v1/records/today-bundle` resolves to the standalone handler instead of falling through to `GET /:id` and treating `"today-bundle"` as a record ID.

---

## v0.16.1 — May 9, 2026

### Cloudflare ASSETS canonicalization

Worker SPA fallbacks now request `/<dir>/` instead of `/<dir>/index.html`. Cloudflare's static-assets binding rewrites `/index.html` requests as 307 redirects to the trailing-slash path under the default `html_handling=auto-trailing-slash`, which previously caused redirect loops in SPA fallback handlers. Affects CMS, Account, admin, and the multi-domain catchall.

### `account.customLogin`

Set `account: { customLogin: true }` to drop a project-branded sign-in page in front of the bundled SPA. Place the page at `quickback/public/account/login/index.html` (as a directory) and the existing public passthrough serves it. The route registers before the `/account/*` SPA catch-all so the static handler wins; everything else under `/account/` continues to route through the bundled SPA.

### Project-level realtime defaults

`providers.database.config.realtime: true` now treats every resource as realtime-enabled by default. Per-resource `realtime: { enabled: false }` still wins.

### Compile-time validators

Two new compile-time errors over silent runtime failures:

- `AUTHENTICATED` + org-scoped firewall is rejected. The combination silently returned empty lists to sign-in-only callers who lacked an active org; the validator names three valid resolutions (drop the org scope, use `USER`, or split the route).
- `createRealtime` imports without `realtime: true` enabled in the config are rejected at compile.

### Drizzle metadata hardening

Drizzle journal files carry a "do not edit" header. The compiler warns when the journal entry count exceeds the snapshot file count (typically the trace of a hand-deleted snapshot).

### Minor

- `SYSADMIN` is now recognised by the standalone-action org gate's pseudo-role matcher.
- Apex `/` and `/account/login` get fallback redirects to `auth.loginUrl` when neither bundled SPA is enabled.
- Record-based action URLs are kebab-case to match the OpenAPI spec (e.g. `/api/v1/widgets/:id/send-invite`).

---

## v0.16.0 — May 9, 2026

### Agent Auth Protocol

Quickback ships a server implementation of the [Agent Auth Protocol](https://agentauthprotocol.com) via `@better-auth/agent-auth`. Enable with `auth.plugins.agentAuth: true` and the compiler emits the full agent-auth surface: discovery at `/.well-known/agent-configuration`, capability projection from the project's OpenAPI spec, a device-authorization approval page in the Account SPA at `/agents/approve`, and the four agent-auth tables added to the auth schema automatically.

**OpenAPI capability projection runs by default.** Every operation with an `operationId` becomes an agent capability. Default `approvalStrength` map: `GET → "session"`, `POST/PUT/PATCH/DELETE → "webauthn"`. The proxy `onExecute` makes a self-fetch with a Better Auth JWT minted for the agent session, so the inner request hits the existing JWT fast-path and runs the full firewall + access + masking pipeline. Opt out of OpenAPI projection with `agentAuth: { fromOpenAPI: false }` and wire `capabilities` + `onExecute` by hand.

### Bearer-only on `/mcp` and the agent-auth surface

`/mcp` forwards only `Authorization: Bearer …` into the inner request. Cookie and `x-api-key` forwarding are removed. Three Bearer flavors land on the same header — Better Auth session token (via the `bearer` plugin), OAuth access token (via OAuth Provider), and agent JWT (via `@better-auth/agent-auth`).

### Auth DSL gains first-class plugin entries

`bearer`, `oauthProvider`, and `agentAuth` are now typed entries in both the array-form union and the `BetterAuthPlugins` interface, with their own options shapes (`OAuthProviderOptions`, `AgentAuthOptions`). Existing `as any` casts can come out.

Auto-enable rule: turning on `agentAuth` force-adds `bearer` + `oauthProvider`. No useful agent-auth deployment ships without those two.

### `queue-consumer.ts` gating

The queue consumer is emitted when any of the following are true: embeddings are configured, queue handlers exist under `services/queues/*`, or `additionalQueues` is declared. Previously the third case left projects with a wrangler binding pointing at a missing handler.

---

## v0.15.0 — May 7, 2026

### Sysadmin tier for the CMS

A new opt-in `cms: { sysadmin: true }` flag turns the CMS into a cross-tenant DB-admin tool gated by `user.role === 'sysadmin'`. Distinct from the Better Auth `'admin'` plugin role, so user-management powers and DB-admin powers stay decoupled. Off by default.

When enabled, the compiler emits a `SYSADMIN` pseudo-role (a fifth marker alongside `PUBLIC` / `AUTHENTICATED` / `USER` / `ADMIN`), a firewall escape hatch that drops tenant scopes for sysadmins while preserving soft-delete, a true cross-tenant `/admin/v1/sysadmin/organizations` endpoint, and a relaxed cross-tenant guard for list routes.

The CMS SPA gains a two-mode design: org admins keep the existing membership-based switcher, sysadmins get an "All organizations" selector that pins tenants via `?organizationId=` on every API call.

### Durable Object `[[migrations]]` order is preserved

Cloudflare's migration list is append-only. The compiler now reads your existing `wrangler.toml` (when present) and emits auto-generated DO `[[migrations]]` blocks in two phases: deployed entries first (preserving order), net-new entries appended last. Reordering DOs in the config array no longer reshuffles deployed migrations.

### `quickback/public/` — static-asset passthrough

Anything dropped under `quickback/public/` is copied verbatim into `src/apps/` on every compile and served by the wrangler `[assets]` binding. Use for favicons, `robots.txt`, OG images, `.well-known/` files, marketing PDFs — anything that needs to ride past the compiler as bytes.

- Optional. Missing folder is a no-op.
- Stale-cleaned. Files removed from `quickback/public/` disappear on the next compile.
- Hidden entries (`.DS_Store`, dotfiles) are skipped.
- Collisions with compiler-emitted manifest paths fail the compile loudly.

### Minor

- Standalone-action wrapper skips the org gate when the access tree references any pseudo-role.
- Queue handler emit no longer drops the `queue` export when there are no embeddings.

---

## v0.14.7 — May 7, 2026

### Codegen fixes for projects with non-`id` primary keys and DO-only features

Four surgical fixes to the generated output:

- Duplicate table imports in relationship-role routes are deduplicated.
- `db` references in single-record and bulk action handlers now resolve correctly during pre-fetch.
- PartyServer auth gates pass the in-scope `db` handle into firewall calls.
- Durable-object-only features keep their `lib/` files in the output.

### `emailOtp` + AWS SES is OTP-only

`auth.emailOtp` with the AWS SES email provider no longer auto-wires the magic-link companion. Mail-client URL prefetching can burn the one-time code before the human sees it; the Account SPA's `/email-otp` route is the single canonical entry point. Projects that explicitly want the magic-link arm can wire `sendVerificationOTP` directly.

---

## v0.14.6 — May 7, 2026

### MCP transport correctness

Four fixes to the MCP-over-HTTP path:

- `tools/call` URLs are no longer double-prefixed for action tools.
- Auth middleware accepts API keys via `Authorization: Bearer` in addition to `x-api-key` and query parameters — the channel MCP clients use exclusively.
- `auth.roleHierarchy` is expanded for runtime role checks across api-key, JWT, and session auth paths. A higher role inherits the privileges of every lower role.
- Team-scoped firewall predicates degrade gracefully when no team is active (org scoping continues to apply; team scoping is optional).

---

## v0.14.5 — May 7, 2026

### MCP environment threading

The generated MCP server's `tools/call` dispatch threads `env` and `executionCtx` into the inner request, so action tools that touch Cloudflare bindings (D1, KV, R2, Queues) no longer crash with `undefined` env access.

---

## v0.14.4 — May 7, 2026

### `via:` firewall predicates pull required imports

The relationship-role generator emits `inArray` and `sql` imports when the firewall has any `via:` predicate, and `buildFirewallConditions` accepts `(ctx, db)` so the relationship subquery has a Drizzle client to evaluate against. Every CRUD and action call site passes `db` through automatically.

---

## v0.14.3 — May 7, 2026

### Relationship-role table re-exports

Generated `<table>.resource.ts` files now re-export their Drizzle table binding. Cross-feature relationship subqueries that import the binding from the resource file (rather than the schema) resolve correctly.

---

## v0.14.2 — May 7, 2026

### Historical DO `[[migrations]]` are preserved

A new `bindings.durableObjectMigrations` config slot carries forward `deleted_classes`, `renamed_classes`, and `transferred_classes` lifecycle entries across recompiles. Cloudflare's migration list is append-only; entries declared here are emitted first in `wrangler.toml`, then auto-generated current-class entries follow:

```ts
bindings: {
  durableObjects: [{ name: 'NOTEPAD', className: 'Notepad', from: 'lib/Notepad' }],
  durableObjectMigrations: [
    { tag: 'qb-do-deleted-legacy-notes-2026-05-05', deletedClasses: ['LegacyNotes'] },
  ],
}
```

All four lifecycle shapes are supported. User-declared entries can override auto-emit by reusing the same tag.

---

## v0.14.1 — May 7, 2026

### Bulk action variants in `openapi.json`

Record-based actions with `bulkVariant: true` are now emitted as sibling operations in the OpenAPI spec, with the documented `{ ids, input, failFast? }` request shape, 200/207/400 responses, and a separate `<Resource><Action>Bulk` `operationId` so typed-client codegen distinguishes single from bulk.

### Cross-tenant "my events" patterns

The access docs now include a worked example for the cross-tenant aggregation pattern (e.g. `GET /my-events` returning resources across all tenants a caller is invited to). See [Access → Cross-tenant dashboards](/compiler/definitions/access#cross-tenant-my-events-dashboards-are-not-this).

---

## v0.14.0 — May 7, 2026

### Relationship-based authorization

Roles can now be bound to a domain-table membership ("user is a confirmed guest of this event") rather than an org membership or a pseudo-role. Declare the relationship once and reference it from `firewall:` or `access.roles:`:

```ts
authz: {
  relationships: {
    guestOf: {
      from: 'event_guests',
      subject: { column: 'userId', equals: 'ctx.userId' },
      resource: { column: 'eventId' },
      where: { status: 'confirmed' },
    },
  },
  roles: {
    guest: { via: 'guestOf' },
    eventStaff: { or: [{ via: 'guestOf' }, { roles: ['admin', 'owner'] }] },
  },
}

// features/sessions/sessions.ts
firewall: [
  { field: 'organizationId', equals: 'ctx.activeOrgId' },
  { field: 'eventId', via: 'guestOf' },
],
read:   { access: { roles: ['admin', 'member', 'guest'] } },
create: { access: { roles: ['admin', 'guest'] } },
update: { access: { roles: ['admin'] } },
```

The compiler emits an inline Drizzle subquery against the relationship table and AND-composes it as the outermost firewall clause. The relationship table's own firewall (tenant scope, soft-delete) is honored inside the subquery; cross-tenant grants are impossible because the resource's tenant filter sits outermost.

Supported surfaces: row-level scoping via `firewall: [{ field, via }]`, role gates on writes and reads, view access. Masking and action access reject relationship-roles at compile time with pointers to the working pattern (gate the row at the firewall layer, gate the role at the access layer).

Cross-tenant aggregation dashboards aren't solved by relationship-roles — the tenant firewall remains the outermost AND. For that pattern, use a user-scoped firewall or function-form access on a dedicated route.

See [Firewall → Relationship-based scoping](/compiler/definitions/firewall#relationship-based-scoping-via) and [Access → Relationship-based authorization](/compiler/definitions/access#relationship-based-authorization).

### Bulk variants on record-based actions

`defineAction({ bulkVariant: true })` emits `POST /:resource/batch/{action}` alongside the per-record route. The bulk handler loops the same access + transition + execute pipeline over a `{ ids, input, failFast? }` body:

```ts
export default defineAction({
  description: "Move an application forward in the pipeline.",
  input: z.object({ nextStatus: z.enum(["screening", "interview", "offer"]) }),
  access: { roles: ["owner", "admin"] },
  bulkVariant: true,
  transition: { field: "status", via: "nextStatus", fromTo: { /* ... */ } },
  async execute({ db, record, input, whereTransition }) {
    // exact same body — runs once per id
  },
});
```

Per-record outcomes return as 207 Multi-Status. `failFast: true` aborts on the first failure and wraps the loop in `db.transaction()` on tx-supporting providers; D1 fails fast without rollback. Max 100 IDs per request. Rejected on standalone actions and `unsafe` actions.

### Aggregations on read views

Read views can declare pre-computed metrics that surface alongside the row payload:

```ts
read: {
  views: {
    pipeline: {
      fields: ["id", "jobId", "candidateId", "status", "appliedAt"],
      aggregations: {
        totalApplications: { fn: "count" },
        byStatus:          { fn: "groupBy", field: "status" },
      },
    },
  },
}
```

Aggregations run over the same firewalled, filtered set as the row query; pagination is intentionally ignored. Supported functions: `sum`, `avg`, `min`, `max`, `count`, `count_distinct`, `groupBy`. See [Views → Aggregations](/compiler/definitions/views#aggregations).

---

## v0.13.5 — May 6, 2026

### Object-form `auth.plugins` config is honored

The documented `plugins: { oauthProvider: {...} }`, `plugins: { organization: { teams: { enabled: true } } }` shapes now flow through the compiler unchanged. Per-plugin options reach the generated `auth.ts` as written.

### `roles: ["PUBLIC"]` allowed on writes and actions

`PUBLIC` is the explicit, uppercase opt-in for unauthenticated access on every access node — reads, writes, views, and actions. The runtime trusts the marker; row-level safety comes from firewall, masking, and the action's own validation. `PUBLIC` actions continue to receive mandatory audit logging.

Common pattern: pair `roles: ["PUBLIC"]` with `firewall: { exception: true }` on the resource so the row predicate doesn't reject every unauthenticated caller.

---

## v0.12.0 — May 5, 2026

### Per-room authorization for PartyServer

`bindings.durableObjects[].access` declares a path-scoped gate that runs the declared resource's firewall and `read.access` pipeline before the WebSocket upgrade:

```ts
durableObjects: [
  // Single-resource: roomId IS the chat row id.
  { name: 'Chat', className: 'Chat', from: 'lib/Chat',
    access: { resource: 'chats' } },

  // Multi-resource: regex dispatches kind → resource.
  { name: 'Notepad', className: 'Notepad', from: 'lib/Notepad',
    access: {
      roomId: { pattern: '^(day-note|interaction|record):([A-Za-z0-9_-]+)$', kindGroup: 1, idGroup: 2 },
      resources: {
        'day-note':    { resource: 'day-notes' },
        'interaction': { resource: 'interactions' },
        'record':      { resource: 'records' },
      },
    } },

  // Anonymous lobbies / public pads: explicit opt-out.
  { name: 'PublicLobby', className: 'PublicLobby', from: 'lib/PublicLobby',
    access: 'public' },
]
```

The gate 401s unauthenticated callers, 403s when the firewall hides the row, 404s when the row is missing. Resource references are validated against feature names at compile time. See [PartyServer Rooms → Per-room authorization](/stack/realtime/partyserver-rooms#per-room-authorization-via-access-v012).

---

## v0.11.1 — May 5, 2026

### PartyServer auto-mount is secure by default

The `/realtime/*` auto-mount now wraps `partyserverMiddleware` in an auth check. Unauthenticated upgrades return 401; the four auth mechanisms (session cookie, JWT bearer, `x-api-key` header, query parameter) all unlock connections. Per-room access remains the `Server` class's responsibility in `onConnect`.

---

## v0.11.0 — May 5, 2026

### OAuth Provider (MCP-ready)

Quickback can act as a standards-compliant OAuth 2.1 + OIDC authorization server via [`@better-auth/oauth-provider`](https://better-auth.com/docs/plugins/oauth-provider). Enable with `plugins: ["oauthProvider"]`. The compiler auto-includes Better Auth's `jwt` plugin and the Account SPA gains a `/consent` page for the standard authorization-code flow.

This replaces Better Auth's deprecated `mcp` plugin and gives every MCP client (Cursor, Claude Desktop, claude.ai connectors, custom tooling) RFC 7591 dynamic client registration plus the discovery documents they need to bootstrap. See [Auth Plugins → OAuth Provider](/stack/auth/plugins#oauth-provider-mcp-ready).

### API keys via query parameter

The auth middleware now accepts API keys as `?api_key=…` or `?key=…` query parameters. The `x-api-key` header takes precedence when both are sent. Prefer the header whenever the client supports it — query parameters land in access logs and `Referer` headers.

### PartyServer rooms + realtime URL split

The realtime URL space is reorganized so names match what each primitive does:

- **`/realtime/v1/*` → `/broadcast/v1/*`** — the org-wide Broadcaster moves to its semantically accurate prefix.
- **`/realtime/<binding>/<room-id>`** — new mount for [PartyServer](/stack/realtime/partyserver-rooms) rooms. Per-room Durable Objects with presence and lifecycle hooks. Auto-mounted whenever a project declares any in-worker DO.

**Breaking** — recompile + redeploy required:

- `REALTIME_URL` env var renamed to `BROADCAST_URL`.
- SPA helpers `getRealtimeWsUrl()` / `getRealtimeTicketUrl()` renamed to `getBroadcastWsUrl()` / `getBroadcastTicketUrl()`.
- `appConfig.routes.api.realtime` renamed to `appConfig.routes.api.broadcast`.

`partyserver`, `partysocket`, and `hono-party` are pre-installed in the compiler image; collab projects compile without an extra `npm install` step.

---

## v0.10.20 — May 4, 2026

### In-worker Durable Objects

`bindings.durableObjects[].from` flips a DO binding into in-worker mode and emits the export, the `[[migrations]]` block, and the `CloudflareBindings` type all together:

```ts
durableObjects: [{
  name: "ITEM_STREAM",
  className: "ItemStream",
  from: "features/loops/lib/ItemStream",
}]
```

DO class files live under `quickback/lib/` or `quickback/features/<feature>/lib/` — both copy verbatim into the generated `src/` tree on every compile. `from` and `scriptName` are mutually exclusive; cross-worker DOs (`scriptName` set) skip the re-export and migration block.

`migrationTag` (default `qb-do-${className}`) is stable across regenerations and must never be removed or renamed once deployed. `useSqlite` defaults to `true`. See [Bindings → Durable Objects](/compiler/config/bindings#durableobjects).

---

## v0.10.18 — May 2, 2026

### `experimentalRemote` — share deployed D1 with `wrangler dev`

Per-binding `experimental_remote = true` lets `wrangler dev` read/write deployed D1 for selected bindings:

```ts
providers: {
  database: defineDatabase("cloudflare-d1", {
    splitDatabases: true,
    experimentalRemote: { auth: true, features: false },
  }),
}
```

Useful for "share prod auth in dev, keep feature writes sandboxed." Off by default.

### Google OAuth + signup ToS

The Account SPA wires Google OAuth end-to-end when configured under `auth.config.socialProviders.google.enabled`. The signup flow gains a Terms-of-Service checkbox gate (configurable via the Account SPA branding).

### CLI compile auth gate

`quickback compile` now requires authentication for cloud-compiler runs. Device-flow `?redirect=` parameters are standardized across the login + signup pages so a user clicking "Create one" no longer loses their return URL.

---

## v0.10.15–v0.10.17 — May 2, 2026

### CSP auto-config

When `security.csp` is set, the compiler widens directives additively based on the project's enabled features:

| Trigger | Auto-added | Directive |
|---|---|---|
| `cms: true` OR `account: true` | `'unsafe-inline'`, `https://fonts.googleapis.com` | `styleSrc` |
| `cms: true` OR `account: true` | `https://fonts.gstatic.com` | `fontSrc` |
| `csp` set (always) | `@trustedOrigins` | `connectSrc` |
| Bundled SPA enabled | SPA-baked API origin (`config.domain`, `quickback.{baseDomain}`, `cms.domain`, `account.domain`) | `connectSrc` |

Anything you already wrote stays — auto-config never removes or overrides. Each applied addition is logged to stderr. Opt out with `security: { cspAutoConfig: false }`.

Most projects can write the minimal:

```ts
security: {
  csp: {
    defaultSrc: ['@self'],
    scriptSrc: ['@self'],
    objectSrc: ['@none'],
    upgradeInsecureRequests: true,
  },
}
```

…and the compiler fills in font hosts, trusted origins, and SPA-baked URLs.

When a target directive is missing, auto-config scaffolds it from `default-src` baseline rather than widening `default-src` itself — CSP3 fall-back semantics would otherwise leak the addition to every directive that falls back to `default-src`.

---

## v0.10.14 — May 1, 2026

### `auth.jwt` config

The bearer-token JWT used by the auth fast-path is configurable. Tune `expiresIn` to bound the post-revocation replay window without affecting browser SPAs (which auto-refresh on every authed call):

```ts
auth: {
  jwt: {
    expiresIn: 30,
    issuer: 'my-api',
    audience: 'partner-svc',
    secretEnv: 'CUSTOM_JWT_SECRET',
  },
}
```

### Admin MCP endpoints filtered

Better Auth admin endpoints (`/admin/list-users`, `/admin/ban-user`, etc.) now carry `x-access: { userRole: ['admin'] }` in the generated OpenAPI spec. The MCP `tools/list` access-filter drops them for non-admin callers.

### Declarative `security` config

Every security response header (`Content-Security-Policy`, COOP, COEP, CORP, HSTS, `X-Frame-Options`, `Referrer-Policy`, `Permissions-Policy`) is configurable from `quickback.config.ts`. `@`-prefixed sentinels (`@self`, `@none`, `@unsafe-inline`, `@trustedOrigins`, etc.) replace awkward `"'self'"` quoting.

The compiler lints the resolved config for known footguns: `@unsafe-inline` in `script-src`, wildcard sources, missing `default-src`, HSTS preload-list misconfiguration.

### HSTS skipped on localhost

Generated middleware skips `Strict-Transport-Security` when the request hostname is `localhost`, `127.0.0.1`, or `*.localhost`. Without this gate, `wrangler dev` would pin a developer's browser to HTTPS across every project on that machine.

---

## v0.10.13 — May 1, 2026

### Clickjacking defence on every Worker

Every Worker emits `Content-Security-Policy: frame-ancestors 'self' <TRUSTED_ORIGINS…>` and `X-Frame-Options: SAMEORIGIN` on every response. The CSP allowlist is sourced from the same `TRUSTED_ORIGINS` constant that gates CORS.

---

## v0.10.11 — May 1, 2026

### MCP `tools/list` is access-filtered

Each MCP tool now carries sanitised access metadata. `tools/list` filters against the caller's `ctx`: unauthenticated callers see only `PUBLIC` tools, authenticated callers see only role-gated tools they pass.

- Wildcard CORS removed from the MCP endpoint.
- Unauthenticated `GET /mcp` no longer enumerates tool names.
- Internal flavor text is removed; `annotations.destructiveHint` and `_unsafe` remain — those are the spec-correct signals for clients.

`tools/call` continues to re-enter the Hono app and run every middleware (auth, firewall, access, guards, masking), so hiding a tool from list never weakens the underlying gate.

---

## v0.10.10 — April 29, 2026

### Reserved keys in `access.record` are rejected

`access.record` is a flat field map evaluated as implicit AND between entries — keys must be column names. The compiler now rejects reserved keys (`and`, `or`, `roles`, `userRole`) inside `record` with migration guidance pointing at the working pattern (top-level siblings with their own `record:` blocks).

---

## v0.10.8 — April 29, 2026

### Audit logging on Postgres targets

`audit_events` previously only existed on `cloudflare-d1`. The audit table now lives in a dedicated `audit` schema (`drizzle.pgSchema('audit')`) on Postgres targets. The `hasSecurityAudit` gate accepts D1 or any PG dialect; `auditDatabaseId` remains a D1-only requirement.

### `auditDatabaseId` is a compile-time requirement

Projects with unsafe or `PUBLIC` actions that previously produced a placeholder `database_id = "local-audit"` in production now fail at compile time with the exact `wrangler d1 create <project>-audit` command and the config key where the returned ID goes.

### Action input → OpenAPI / MCP

`defineAction({ input: z.object({...}) })` schemas flow into the OpenAPI `requestBody` and the MCP tool's `inputSchema.properties`. Simple `z.object` shapes are extracted at compile time; discriminated unions, refinements, recursive schemas, and bare-identifier references run through Zod's native `z.toJSONSchema()` for full-fidelity output.

### OpenAPI fidelity

- Response schemas emit `required[]` for every non-nullable column.
- `text(_, { enum: [...] })` columns emit as closed `{ type: "string", enum: [...] }`.
- `id` claims `format: "uuid"` only when the project's `generateId` actually produces UUIDs. cuid2 / prefixed / nanoid / serial generators emit plain `{ type: "string" }`.

### Minor

- Auto-mask predicate verifies the resolved owner column exists before emitting an `or: 'owner'` clause; falls back to roles-only with a warning otherwise.
- Generated CRUD errors emit canonical `QuickbackErrorCode` enum values (`DB_NOT_NULL_VIOLATION`, `DB_UNIQUE_VIOLATION`, etc.) so generated SDKs can exhaustively switch on `code`. See [API errors](/compiler/targets/hono-api/using-the-api/errors#database).

---

## DSL: one file per action, multi-table per feature

### One file per action

Action authoring is one file per action under `<feature>/actions/<name>.ts`. The filename is the action name and the URL segment:

```typescript
// features/applications/actions/advance.ts
import { z } from "zod";
import { defineAction } from "../.quickback/define-action";
import { applications } from "../applications";

export default defineAction({
  description: "Move an application forward in the pipeline",
  input: z.object({ nextStatus: z.enum(["screening", "interview", "offer"]) }),
  access: { roles: ["owner", "admin"] },
  transition: {
    field: "status",
    via: "nextStatus",
    fromTo: { applied: ["screening"], screening: ["interview"], interview: ["offer"] },
  },
  async execute({ db, record, input, auditFields, whereTransition }) { /* … */ },
});
```

`defineAction` is imported from a generated per-feature helper at `<feature>/.quickback/define-action.ts` — `record`, `input`, and audit fields are typed without manual annotations.

**Discovery rules:**
- `actions/<name>.ts` binds to the feature's primary table.
- `actions/<table>/<name>.ts` binds to the sibling table file.
- Setting `path:` makes the action standalone (custom URL, no record fetch).
- Tableless features require every action to be standalone.

**Retired** (rejected at load time with migration guidance): `actions.ts` (bundled multi-action file), `_feature.ts`, `handlers/` directory + `handler:` string ref, `defineActions(table, {…})`, colocated `defineActions` inside table files, `standalone: true` flag, `*-actions.ts` / `*.actions.ts` filename patterns.

See [Actions docs](/compiler/definitions/actions).

### Multi-table actions per feature

One feature directory can own actions on multiple tables. Three discovery modes:

- **Colocated** (canonical) — `<table>.ts` containing both `defineTable` and `defineActions(<table>, …)`. One file per entity.
- **`actions.ts`** — single primary-table actions file at feature root.
- **`actions/<table>.ts`** — per-table action files for strict schema/behavior separation.

Plus a universal `_feature.ts` slot for non-table-bound feature-level actions and shared Zod schemas.

Action names are unique per `(bindTable, name)` pair. Sibling-bound `actions/episodes/publish.ts` and `actions/shows/publish.ts` mount at `/episodes/:id/publish` and `/shows/:id/publish` and compile cleanly.

---

## Firewall: named-scope shape

The named-scope firewall shape is a co-equal user-facing input alongside the predicate array:

```typescript
firewall: { organization: { column: 'tenant_id' } }     // named-scope (compact)
firewall: { owner: { column: 'account_user_id' } }
firewall: { exception: true }
firewall: [
  { field: 'organizationId', equals: 'ctx.activeOrgId' },
  { field: 'deletedAt', isNull: true },
]                                                       // predicate array (explicit)
```

Pick the form that reads better — named-scope for the common one-line case, predicate array when you need custom `in`-lists or non-scope predicates.

**Auto-detection synonyms.** When `firewall:` is omitted, the compiler scans the schema for an isolation column. The org-scope list accepts `organizationId`, `organisationId`, `orgId`, `organization`, `organisation`, `org` (American + British). User-scope accepts `userId`.

**`ownerId` is a targeted error signal.** When a table carries `ownerId` but no isolation column and no explicit `firewall:`, the compiler raises a specific error — `ownerId` is business-logic ownership, not access control. Use `userId` for access control, declare an explicit `firewall:`, or add a separate isolation column.

---

## v0.10.0 — April 26, 2026

### `q.scope()` — single-declaration tenant scoping

`q.scope(kind)` replaces the three-place pattern (column declaration + firewall predicate + ownership-guard) with one column:

```typescript
columns: {
  organizationId: q.scope('organization'),  // → ctx.activeOrgId
  ownerId:        q.scope('owner'),         // → ctx.userId
  teamId:         q.scope('team'),          // → ctx.activeTeamId
}
```

`q.scope()` columns auto-derive the firewall predicate, register with the guards layer as `systemManaged` (client input rejected), and auto-populate from `ctx` on create / upsert. The systemManaged extension generalises beyond `q.scope()`: any firewall predicate whose `equals` references `ctx.*` registers its `field` automatically.

See [`q.scope()`](/compiler/definitions/schema#qscope--tenant-scope-columns).

### `masking[col].query.roles` — unified filter / sort / search gate

The three legacy per-capability flags (`filterable`, `searchable`, `sortable`) are replaced by a single `query.roles` allowlist:

```typescript
masking: {
  email: {
    type: 'email',
    show:  { roles: ['admin'] },
    query: { roles: ['admin'] },  // defaults to show.roles when omitted
  },
}
```

A view's own `query.{filterable,searchable,sortable}` allowlist is the opt-in for higher-privileged roles; the existing intersection validator gates it at compile time.

**Breaking:** `masking[col].filterable / .searchable / .sortable` is rejected at compile time with a migration hint. Replace with `query.roles` (or delete the flags — `query` defaults to `show.roles`).

---

## v0.9.0 — April 25, 2026

### Unified `read:` pipeline

The read side of every resource has its own block — `read:` — that owns the collection-level `GET /` endpoint, single-record `GET /:id`, and named view projections.

**Breaking changes** (compile-time errors with migration hints):

- `crud.list` → `read.access` (plus `read.pageSize` / `read.maxPageSize`)
- `crud.get` → `read.access` (single-record GET inherits automatically)
- Top-level `views: {...}` → `read.views: {...}`
- `crud.list.fields` / `crud.get.fields` → declare a named view under `read.views` and call `/views/{name}`

### Pre-record access ordering

Handlers on `/:id` run a role-only access check before the firewall query. A caller without a matching role gets 403 before the database is touched. This closes the 404-vs-403 ID-probe channel — an unauthorized caller can no longer distinguish "row exists in another tenant" from "row doesn't exist." See [Access evaluation order](/compiler/definitions/access#evaluation-order).

### Transactional batch operations

Batch endpoints expose `failFast` and a `meta.transactional` response field. On tx-supporting providers (postgres, supabase, neon, libsql, better-sqlite3, bun-sqlite), `failFast: true` wraps the per-record loop in `db.transaction(...)` so any failure rolls back the entire batch. On Cloudflare D1 (no `db.transaction`), `failFast: true` stops on the first error but prior writes stay committed.

Embedding queue messages and realtime broadcasts emit after the transaction commits — rolled-back batches produce no orphan jobs.

See [Batch Operations → Transactional semantics](/compiler/targets/hono-api/using-the-api/batch-operations#transactional-semantics).

---

## v0.8.7 — April 17, 2026

### Hono CVE bump

Hono is bumped to `^4.12.14` across the monorepo, the compiler Docker image's pre-installed deps, and every generator path that emits Hono into compiled projects. Older ranges covered the vulnerable window. Recompile to pick up the fix in your generated project's `package.json`.

### Cloudflare Email Sending in public beta

Quickback defaults to the Workers `send_email` binding for Cloudflare deploys. Cloudflare Email Sending has graduated to public beta — production-ready with zero-config. AWS SES remains a fully supported opt-in (`email.provider: 'aws-ses'`) for non-Cloudflare runtimes. See [Email Configuration](/compiler/config#email-configuration).

### Dependency sweep

`wrangler@^4.83.0`, `drizzle-orm@^0.45.2`, `drizzle-kit@^0.31.10`, `zod@^4.3.6`, `@cloudflare/workers-types@^4.20260417.1`.

---

## v0.8.5 — April 15, 2026

### `userRole` access primitive

A new `userRole?: string[]` field in the declarative `Access` config evaluates against `ctx.userRole` (the Better Auth admin-plugin `user.role` column). Distinct from `roles`, which matches `ctx.roles` (org membership).

```typescript
// Org owner OR platform admin
access: { or: [{ roles: ['owner'] }, { userRole: ['admin'] }] }

// Platform admins see SSNs across every org
masking: { ssn: { type: 'ssn', show: { userRole: ['admin'] } } }
```

`userRole` works everywhere `Access` is accepted — CRUD, actions, views, masking, and inside `or` / `and` combinators. See [Access → userRole vs roles](/compiler/definitions/access#userrole-vs-roles).

### CMS admin gate enforced server-side

`cms: { access: "admin" }` previously only hid the CMS link in Account UI and rendered an "Access Denied" screen inside the SPA. Server-side enforcement now applies at every CMS-facing surface: the SPA shell, `/api/v1/schema`, and `custom_view` CRUD.

### Better Auth 1.5 + `@cloudflare/workers-types` compatibility

Generated API code typechecks against the new versions. The org-member role-change broadcast hook is emitted via `organizationHooks.afterUpdateMemberRole` (the supported shape after the 1.5 deprecation of `databaseHooks.member.update.after`). `REALTIME_URL` and `ACCESS_TOKEN` are always emitted as optional bindings when the organization plugin is active.

---

## v0.8.4 — April 14, 2026

### `generateId: "short"` strategy

A compact ID option for tables where short, shareable codes matter more than collision resistance at scale:

```typescript
providers: {
  database: defineDatabase("cloudflare-d1", { generateId: "short" }),
}
```

Generates 6-character alphanumeric IDs (e.g. `a3F9xK`) using nanoid's `customAlphabet` with the full 62-char alphabet (`0-9A-Za-z`). Requires the `nanoid` package.

**When to use:** room codes, invite links, share URLs, ephemeral records.

**When not to use:** high-volume tables. 62^6 ≈ 56.8B combinations means ~238K rows before a 50% collision probability. For large tables stick with `"uuid"`, `"cuid"`, or `"prefixed"`. See [Providers → ID Generation Options](/compiler/config/providers#id-generation-options).

---

## v0.8.2 — April 11, 2026

### Catch-all `VITE_QUICKBACK_URL`

A single Quickback origin can be set in place of four separate URL env vars:

```bash
VITE_QUICKBACK_URL=https://secure.example.com
```

| Individual var (explicit) | Fallback when unset |
|---|---|
| `VITE_QUICKBACK_API_URL` | `${VITE_QUICKBACK_URL}` |
| `VITE_QUICKBACK_ACCOUNT_URL` | `${VITE_QUICKBACK_URL}/account` |
| `VITE_QUICKBACK_CMS_URL` | `${VITE_QUICKBACK_URL}/cms` |

`VITE_QUICKBACK_APP_URL` stays independent — it points at the tenant's own frontend. Non-breaking; individual vars take precedence when set. Library users can set `__QUICKBACK_URL__` on `globalThis`. See [Environment Variables](/stack/account-ui/environment-variables).

---

## v0.8.1 — April 9, 2026

### Role hierarchy with `+` suffix

Define a hierarchy and use `+` to mean "this role and above":

```typescript
auth: { roleHierarchy: ['member', 'admin', 'owner'] }

crud: {
  list:   { access: { roles: ["member+"] } },  // member, admin, owner
  create: { access: { roles: ["admin+"] } },    // admin, owner
  delete: { access: { roles: ["owner"] } },      // owner only
}
```

Roles are expanded at compile time. No `+` = exact match. See [Access → Role Hierarchy](/compiler/definitions/access#role-hierarchy).

---

## v0.8.0 — April 9, 2026

### Breaking: VITE URL environment variables namespaced

All Quickback-generated URL environment variables are namespaced under `VITE_QUICKBACK_*` to avoid collisions with other Vite projects.

| Old | New |
|-----|-----|
| `VITE_API_URL` | `VITE_QUICKBACK_API_URL` |
| `VITE_ACCOUNT_URL` | `VITE_QUICKBACK_ACCOUNT_URL` |
| `VITE_APP_URL` | `VITE_QUICKBACK_APP_URL` |
| `VITE_CMS_URL` | `VITE_QUICKBACK_CMS_URL` |

Non-URL variables are unchanged (`VITE_ENABLE_*`, branding vars, `VITE_STRIPE_PUBLISHABLE_KEY`).

**Action required:**
- Compiled projects: re-run `quickback compile`.
- Standalone deploys: update `.env`, `.env.production`, and `wrangler.toml` files manually.
- Library users: `__QUICKBACK_API_URL__` / `__QUICKBACK_APP_URL__` globals are unchanged.

### CMS access control

`cms.access: "admin"` enforces access at the CMS level, not just link visibility. Non-admin users (`user.role !== "admin"`) see an "Access Denied" screen with a sign-out button.

---

## v0.5.11 — February 24, 2026

### Mandatory unsafe action audit trail

Structured `unsafe` config (`unsafe: { reason, adminOnly, crossTenant, targetScope }`). Cross-tenant unsafe actions require Better Auth authentication plus platform admin role (`ctx.userRole === "admin"`). Mandatory audit logging on success, denial, and error paths. Cloudflare output includes `AUDIT_DB` wiring, `drizzle.audit.config.ts`, and `db:migrate:audit:*` scripts when unsafe actions are present.

Compile-time raw SQL guard for actions and handlers (`allowRawSql: true` required per action).

### Security contract report artifacts

Generated security contract artifacts: `reports/security-contracts.report.json`, `reports/security-contracts.report.sig.json`. Config-driven signing controls (`compiler.securityContracts.report.signature.*`). Missing required signing keys fail loudly with explicit remediation.

### Headless Drizzle rename hints

`compiler.migrations.renames` configuration for CI/CD environments where Drizzle's interactive rename prompts block compilation. See [Configuration](/compiler/config).

### Minor

- Email OTP magic links work correctly.
- Auth is required for all API routes when running locally.
- Single-file multi-table exports alongside `defineTable()` produce a clear error.

---

## v0.5.8 — February 14, 2026

### Quickback CMS

A schema-driven admin panel that connects to your generated API. The compiler now outputs a JSON schema registry consumed by the CMS at runtime. Firewall error modes (`reveal` for 403 with details, `hide` for opaque 404) are configurable per resource for security-sensitive deployments.

---

## v0.5.7 — February 12, 2026

### Scoped database for actions

Actions receive a security-scoped database instead of a raw Drizzle instance. The compiler generates a proxy wrapper that automatically enforces org isolation, owner filtering, and soft-delete visibility — the same protections that CRUD routes have always had.

Duck-typed column detection at runtime:

| Column Detected | SELECT / UPDATE / DELETE | INSERT |
|---|---|---|
| `organizationId` | Adds `WHERE organizationId = ?` | Auto-injects `organizationId` from context |
| `ownerId` | Adds `WHERE ownerId = ?` | Auto-injects `ownerId` from context |
| `deletedAt` | Adds `WHERE deletedAt IS NULL` | — |

Every action is secure by default — no manual `WHERE` clauses needed.

Actions that intentionally need to bypass security (admin reports, cross-org queries, migrations) can declare `unsafe: true` to receive a raw, unscoped database handle via `rawDb`:

```typescript
defineActions(analytics, {
  globalReport: {
    unsafe: true,
    execute: async ({ db, rawDb, ctx, input }) => {
      // db → still scoped (safety net)
      // rawDb → bypasses all security filters
      const allOrgs = await rawDb.select().from(organizations);
    },
  },
});
```

Without `unsafe: true`, `rawDb` is `undefined`. See [Actions](/compiler/definitions/actions).

### Cascading soft delete

Soft-deleting a parent record automatically cascades to child and junction tables within the same feature. The compiler detects foreign key references at build time and generates cascade `UPDATE` statements.

Rules:
- Applies to soft delete only. Hard delete relies on database-level `ON DELETE CASCADE`.
- Cascades within the same feature only — cross-feature references are not affected.
- Child tables must have `deletedAt` / `deletedBy` columns (auto-added by the compiler).

See [Actions API → Cascading Soft Delete](/compiler/targets/hono-api/using-the-api/actions-api#cascading-soft-delete).

### Advanced query parameters

New capabilities for all list endpoints:

- **Field selection** — `?fields=id,name,status`
- **Multi-sort** — `?sort=status:asc,createdAt:desc`
- **Total count** — `?count=true` returns total matching records in `X-Total-Count`
- **Full-text search** — `?search=keyword` searches across all text columns

See [Query Parameters](/compiler/targets/hono-api/using-the-api/query-params).

---

## v0.5.5 — February 5, 2026

### OpenAPI spec generation

Generated APIs include a full OpenAPI specification at `/openapi.json`. Better Auth endpoints are included in the spec.

### Better Auth plugins

Published `@quickback-dev/better-auth-upgrade-anonymous` (post-passkey email collection flow), `@quickback-dev/better-auth-combo-auth` (combined email + password + OTP), and `@quickback-dev/better-auth-aws-ses` (AWS SES email provider).

### Security headers

Global error handler prevents leaking internal error details. Security headers middleware (CSP, HSTS, X-Frame-Options, X-Content-Type-Options). `BETTER_AUTH_SECRET` properly passed to generated config.

---

## v0.5.4 — January 30, 2026

### Account UI

Pre-built authentication UI deployed as Cloudflare Workers. Sessions, organizations, passkeys, passwordless, admin panel, API keys. Dual-mode: standalone (degit template) or embedded with Quickback projects.

### Webhook system

Inbound webhook endpoints with signature verification. Outbound webhooks via Cloudflare Queues with automatic retries. Configurable per-feature webhook events.

### Realtime & vector search

Durable Objects + WebSocket realtime subscriptions. Vector embeddings via Cloudflare Vectorize. KV and R2 storage integrations.

---

## v0.5.0 — January 2026

### Initial release

- **Quickback Compiler** — TypeScript-first backend compiler.
- **Four security pillars** — Firewall, Access, Guards, Masking.
- **`defineTable()`** — schema + security configuration in a single file.
- **Templates** — Cloudflare Workers, B2B SaaS.
- **Cloud compiler** — remote compilation via `compiler.quickback.dev`.
- **CLI** — `quickback create`, `quickback compile`.
- **Better Auth integration** — organizations, roles, sessions.
- **Drizzle ORM** — schema-first with automatic migrations.
- **Cloudflare D1** — split database support (auth + features).
