fastify-auto-sqlapi 0.2.2 → 0.2.4

package/AGENTS.md

@@ -6,7 +6,7 @@ You are configuring a Fastify server that uses `fastify-auto-sqlapi` to auto-gen
 
 The plugin generates REST endpoints (search, get, insert, update, delete, bulk upsert, bulk delete) from database table definitions. No ORM — raw SQL. Supports **PostgreSQL**, **MySQL**, and **MariaDB**. The consumer defines table configurations, and the plugin handles routing, validation, and query execution.
 
-**The database schema is the API contract, on purpose.** The exposed shape follows the stored shape *by default*, and every part of that default is overridable — `readExclude`, `writeExclude`, a trimmed Schema, `schemaOverrides`, `computedFields`, `afterRead`, `operations`, relation `alias`/`fields`, `extraFilters`. Two consequences for how you work:
+**The database schema is the API contract, on purpose.** The exposed shape follows the stored shape *by default*, and every part of that default is overridable — `readExclude`, `writeExclude`, `excludeColumns` (CLI config), `schemaOverrides`, `computedFields`, `afterRead`, `operations`, relation `alias`/`fields`, `extraFilters`. Two consequences for how you work:
 
 - Do not propose a DTO or mapping layer, and do not reshape a response by hand in a route wrapper. Reach for the lever that matches the concern (the table is in [ADR 0017](./docs/adr/0017-the-schema-is-the-contract.md)); when none fits, the operation is not CRUD — write a custom route and call `app.sqlApi.*` inside it, which keeps filters, joins, tenant scoping, hooks and validation.
 - The target surface is internal: back-office and admin tools where the schema *is* the domain model. If the user is building a **public or third-party API** — consumers they cannot redeploy with their schema, a versioned contract — say so, and keep those tables off the auto routes via `operations` rather than generating the surface from the schema.

package/AGENTS_BACKEND.md

@@ -58,13 +58,16 @@ export default {
   dialect: 'postgres',         // 'postgres' | 'mysql' | 'mariadb' (default: 'postgres')
   // envFile: '../../.env',    // path to .env file, relative to cwd (default: '.env')
   // excludeTables: ['knex_*'],// tables invisible to schema generation (see below)
+  // excludeColumns: ['*.password_hash'], // columns invisible to schema generation (see below)
 };
 ```
 
-That's it — only these five fields exist. **No connection string, no migration path.** If the file is missing, defaults are used. The `dialect` can also be passed via CLI flag `--dialect mysql`. The `envFile` is useful in monorepo setups where the `.env` lives at the repo root.
+That's it — only these six fields exist. **No connection string, no migration path.** If the file is missing, defaults are used. The `dialect` can also be passed via CLI flag `--dialect mysql`. The `envFile` is useful in monorepo setups where the `.env` lives at the repo root.
 
 **`excludeTables`** keeps migration bookkeeping, PostGIS internals and the like out of generation: exact table names or `*` globs, matched against the **DB table name** (not the generated schema name), with everything else literal. An excluded table is invisible to the generator — its schema file is not created, and one generated by an earlier run is removed as an orphan on the next full run, exactly like the schema of a dropped table. See [ADR 0009](./docs/adr/0009-schema-exclusion-config-blacklist.md).
 
+**`excludeColumns`** does the same for single columns: `"<table>.<column>"` entries matched against the **DB names** (not the generated field names), with `*` as a wildcard on either side — `'user.password_hash'`, `'*.internal_*'`, `'audit_*.raw_payload'`. An excluded column does not exist for the API at all: it is not in the Schema, so no route reads, writes, filters or orders by it, and the manifest never lists it. This is the lever for *"this column must not exist for the API"*; `readExclude` / `writeExclude` on the table config are for a column that stays in the Schema and loses one side. A primary key column cannot be excluded (every route identifies rows with it), and a pattern that would leave a table with no columns fails the run: that is `excludeTables`' job. Never edit a generated Schema file by hand — it is overwritten on the next run. See [ADR 0019](./docs/adr/0019-column-exclusion-is-generation-time-config.md).
+
 ### 3. Configure database connection (env vars)
 
 The CLI reads DB connection from environment variables (NOT from the config file). `DATABASE_URL` takes priority for all dialects.
@@ -1014,9 +1017,9 @@ output, it is the part that does not depend on anyone opening the generated file
 - **All fields Optional in response**: `RETURNING *` may return any subset. Response schemas use `Type.Partial`.
 - **Nullable columns use `Nullable(T)` (type-array form)**: the generator emits `Type.Optional(Nullable(T))` for nullable columns — `Nullable` (exported by the package) produces `{ type: ['integer', 'null'] }`. Do NOT replace it with `Type.Union([T, Type.Null()])`: under Fastify's default Ajv `coerceTypes` a union corrupts values through its branches (`null` → `0` with the Null branch last, `0`/`""` → `null` with it first), while the type array validates and serializes NULL correctly. A bare `Type.Optional(T)` is also wrong: NULL serializes as `0`/`""`. In `filters`, an explicit `null` on a schema field builds `WHERE col IS NULL`.
 - **`excludeFromCreation`**: **IMPORTANT** — auto-increment PKs (e.g. `id` serial/auto_increment) MUST be listed here, otherwise INSERT will try to send them and fail. The CLI auto-detects this and adds it by default. Also useful for `createdAt`/`updatedAt` columns managed by DB defaults or hooks. It strips **client-supplied** values only: the payload is sanitized before `beforeInsert` runs, so a value the hook assigns to an excluded field (e.g. a server-generated TEXT id) DOES reach the INSERT. Same for the engine's FK auto-fill on secondaries — an excluded FK column does not suppress it. It is an **ergonomics tool for creation, NOT a field-level security mechanism**: it does not apply to updates — every Schema field is updatable by default, by design. Field-level update rules (`isAdmin`, roles, owner/tenant columns, state fields) are product logic: enforce them in `beforeUpdate` (silent strip) or `validate` (loud 400), or move the privileged transition to a dedicated endpoint and keep it off the auto routes via `operations`.
-- **`readExclude`**: fields hidden from every read — not projected by search/get, omitted from read response schemas and from this table's default (`*`) join selection when it is a join target. Referencing one from `filters`, `conditions`, `orderBy`, `joinGroup` aggregations or an explicit join `selection` returns 400: hiding a field from output while allowing it to be filtered would leak its value by bisection. **Writes are unaffected** — insert/update/bulk still accept the field, so a column can be writable but never readable (password hash, access token). Primary keys cannot be excluded. Complementary to trimming the Schema, which removes the column from reads *and* writes. It is **per table and static**: a column hidden here is hidden from every caller, including admins. To keep a column readable on the table's own routes but not through a relation, trim the Schema the *relation* is declared with instead — see the read-grant warning under [buildRelation](#buildrelation-signature).
-- **`writeExclude`**: the write-side counterpart of `readExclude` — fields removed from the insert, update and bulk-upsert bodies (main *and* secondaries) and dropped again inside the engines, which `sqlApi.*` reaches without those schemas. Reads are untouched: the field is still projected, filterable and orderable. It exists for the columns the database refuses to be told about. **A `GENERATED ALWAYS AS (<expr>)` column is already covered without any config**: the CLI records it in the Schema's `generatedFields`, and both engines reject a statement that so much as names such a column, so offering it as writable could only turn a client mistake into a `500`. The `writeExclude` key is for the rest — a column a trigger owns, one a migration is about to drop. It is **static and applies to everyone**, admins included; a rule that depends on *who* is asking is product logic and belongs in `beforeUpdate` (silent strip) or `validate` (loud 400), per [ADR 0004](./docs/adr/0004-updates-always-open.md). Not to be confused with `excludeFromCreation`, which whitelists **client input on insert only** and deliberately lets a hook assign the field afterwards — `writeExclude` runs **after** the hooks, because the column refuses the value whoever assigned it. `defineTable` rejects a field that is not in the schema, the primary key (the update body identifies the row with it) and a field that is also in `readExclude` (neither readable nor writable means: remove it from the Schema). See [ADR 0015](./docs/adr/0015-non-writable-columns.md), which narrows [ADR 0004](./docs/adr/0004-updates-always-open.md).
-- **Database-computed and identity columns are detected by the CLI**: `sqlapi-generate-schema` reads `is_generated` (PostgreSQL) / `EXTRA` (MySQL, `VIRTUAL GENERATED` and `STORED GENERATED`) and prints the columns it found, per table, before writing anything — read that output. Generated columns land in the Schema's `generatedFields` and are named in a comment in the generated `Table*.ts`. Separately, `GENERATED ... AS IDENTITY` (PostgreSQL) has no `column_default` to reveal that the database fills it in: it is now flagged like MySQL's `AUTO_INCREMENT`, so the field is Optional and the CLI lists it under `excludeFromCreation` instead of emitting a mandatory primary key the database then refuses.
+- **`readExclude`**: fields hidden from every read — not projected by search/get, omitted from read response schemas and from this table's default (`*`) join selection when it is a join target. Referencing one from `filters`, `conditions`, `orderBy`, `joinGroup` aggregations or an explicit join `selection` returns 400: hiding a field from output while allowing it to be filtered would leak its value by bisection. **Writes are unaffected** — insert/update/bulk still accept the field, so a column can be writable but never readable (password hash, access token). Primary keys cannot be excluded. Complementary to `excludeColumns` in `sqlapi.config.ts`, which removes the column from the Schema, hence from reads *and* writes. It is **per table and static**: a column hidden here is hidden from every caller, including admins. To keep a column readable on the table's own routes but not through a relation, trim the Schema the *relation* is declared with instead — see the read-grant warning under [buildRelation](#buildrelation-signature).
+- **`writeExclude`**: the write-side counterpart of `readExclude` — fields removed from the insert, update and bulk-upsert bodies (main *and* secondaries) and dropped again inside the engines, which `sqlApi.*` reaches without those schemas. Reads are untouched: the field is still projected, filterable and orderable. It exists for the columns the database refuses to be told about. **A `GENERATED ALWAYS AS (<expr>)` column is already covered without any config**: the CLI records it in the Schema's `generatedFields`, and both engines reject a statement that so much as names such a column, so offering it as writable could only turn a client mistake into a `500`. The `writeExclude` key is for the rest — a column a trigger owns, one a migration is about to drop. It is **static and applies to everyone**, admins included; a rule that depends on *who* is asking is product logic and belongs in `beforeUpdate` (silent strip) or `validate` (loud 400), per [ADR 0004](./docs/adr/0004-updates-always-open.md). Not to be confused with `excludeFromCreation`, which whitelists **client input on insert only** and deliberately lets a hook assign the field afterwards — `writeExclude` runs **after** the hooks, because the column refuses the value whoever assigned it. `defineTable` rejects a field that is not in the schema, the primary key (the update body identifies the row with it) and a field that is also in `readExclude` (neither readable nor writable means: `excludeColumns` in `sqlapi.config.ts`). See [ADR 0015](./docs/adr/0015-non-writable-columns.md), which narrows [ADR 0004](./docs/adr/0004-updates-always-open.md).
+- **Database-computed and identity columns are detected by the CLI**: `sqlapi-generate-schema` reads `is_generated` (PostgreSQL) / `GENERATION_EXPRESSION` (MySQL, non-empty only for a real `GENERATED ALWAYS AS (...)` column; `EXTRA` is a fallback matched on `VIRTUAL GENERATED` / `STORED GENERATED`, never on the word alone — MySQL writes `DEFAULT_GENERATED` there for any default *expression*, `DEFAULT CURRENT_TIMESTAMP` included, and such a column is writable) and prints the columns it found, per table, before writing anything — read that output. Generated columns land in the Schema's `generatedFields` and are named in a comment in the generated `Table*.ts`. Separately, `GENERATED ... AS IDENTITY` (PostgreSQL) has no `column_default` to reveal that the database fills it in: it is now flagged like MySQL's `AUTO_INCREMENT`, so the field is Optional and the CLI lists it under `excludeFromCreation` instead of emitting a mandatory primary key the database then refuses.
 - **`upsertMap`**: when present for a schema, INSERT becomes upsert. PostgreSQL: `ON CONFLICT (...) DO UPDATE`. MySQL/MariaDB: `ON DUPLICATE KEY UPDATE`. Applies to both main and secondary tables.
 - **`schemaOverrides`**: narrow an auto-generated field to a stricter TypeBox type (e.g. `{ email: Type.String({ format: 'email' }) }`) where `information_schema` could only report `text`. **Write bodies only** — insert, update, bulk-upsert. An override rules what the API accepts *from now on*, while the rows already stored predate it: a column narrowed to `format: 'email'` today holds whatever was accepted last year, and one made mandatory today is `NULL` on every pre-existing row. Narrowing the response would publish a promise nobody can retroactively make true, so responses and the `filters` map keep the generated type. (Nothing would break at runtime either way — Fastify does not validate responses, and `fast-json-stringify` ignores `format`/`pattern`/`minLength`/`minimum`/`enum` entirely; it acts only on `type`, by coercion.) The override is taken **verbatim**: no `Type.Optional` makes the field mandatory, no `Nullable` rejects an explicit `null`, whatever the column allows — which is how you make a column the DB had to leave nullable (a new column on a populated table) mandatory going forward. The original Schema file is never modified; the primary key is mandatory in the update body (it identifies the row); overrides appear in Swagger.
 - **`afterRead`**: the read-side counterpart of `beforeInsert`/`beforeUpdate` — the place to decrypt a column, unpack a blob, rescale a stored unit. Called **once per result set** with camelCase rows mutated **in place** (a hook that calls a remote KMS gets one invocation for the page, not one per row), and awaited. Declared on the table that **owns** the column, and it follows a join: the hook runs wherever that table's rows surface, including through a `joinMultiple`/`joinLeft` declared on another table — `ctx.source` (`'get' | 'search' | 'joinMultiple' | 'joinLeft'`) and `ctx.alias` say which. Not called on `joinGroup` (aggregates, not table rows) nor on an empty result. Rows cannot be added or removed — the pagination `COUNT` has already run, so dropping rows would report a `total` that does not match; narrowing what a caller sees is `filters`/`tenantScope`/`readExclude`. On the main table it runs **after** the join side queries, which correlate on the values the database returned: a hook rewriting the column a relation joins on does not break the correlation. Two things it does not reach, by design: `filters`, `orderBy` and `compute*` run in SQL against the **stored** value (searching an encrypted column searches the ciphertext), and it transforms **values, not types** — the response is serialized against the generated schema, so a hook returning an object where the column is `text` yields `"[object Object]"`, and one returning `12.34` on an `integer` column yields `12`. Decrypting `text`→`text` or rescaling `numeric`→`numeric` is what it is for; if the stored and API types genuinely differ, that is a custom route.
@@ -1025,9 +1028,9 @@ output, it is the part that does not depend on anyone opening the generated file
 - **All hooks and validators receive camelCase records**: `validate` and the whole hook matrix (`beforeInsert`/`afterInsert`, `beforeUpdate`/`afterUpdate`, `beforeDelete`/`afterDelete`, `beforeBulkDelete`/`afterBulkDelete`, `afterRead`) get records keyed by schema field names (camelCase). Mutations propagate to the SQL (plugin converts to DB column format via `colMap` after the hook). The engine internally uses `snakecaseRecord(..., schema)` after user mutations to map field names to actual DB columns.
 - **Secondaries run the child table's `beforeInsert`**: a child row written alongside a main record is a write like any other — the child's `excludeFromCreation`, its `tenantScope` and its `beforeInsert` all apply, in that order, before the engine auto-fills the FK to main (which always wins over anything the payload or the hook put there). Its `validate` and `afterInsert` deliberately do **not** run: they change when a rejection or a side effect fires, which belongs to the host's write. See [ADR 0014](./docs/adr/0014-what-follows-a-write-join.md).
 - **Filters validation**: TypeBox schemas use `additionalProperties: false`. By default Fastify strips unknown fields silently. For 400 errors on unknown filters: `Fastify({ ajv: { customOptions: { removeAdditional: false } } })`.
-- **Write-body whitelist**: insert/update/bulk-upsert bodies (`main` + secondaries items) are `additionalProperties: false`. Unknown properties are rejected with 400 — only columns in the generated Schema (as narrowed by `schemaOverrides`/`excludeFromCreation`) can be written, so no mass assignment of unexposed columns. Trim the Schema to keep sensitive columns unwritable.
+- **Write-body whitelist**: insert/update/bulk-upsert bodies (`main` + secondaries items) are `additionalProperties: false`. Unknown properties are rejected with 400 — only columns in the generated Schema (as narrowed by `schemaOverrides`/`excludeFromCreation`) can be written, so no mass assignment of unexposed columns. Exclude a sensitive column at generation time (`excludeColumns`) to keep it out of the Schema, hence unwritable and unreadable.
 - **Error responses**: errors the plugin raises itself are `4xx` with messages written for clients (validation, not found, tenant). Anything else — a driver constraint violation, a hook throwing without a `statusCode` — answers a fixed `{"statusCode":500,"error":"Internal Server Error","message":"Internal Server Error"}`: driver messages name tables, columns and constraints, and they stay on the server. **No status code is remapped** (a unique violation is a `500`, not a `409` — that mapping is product logic). The body carries `requestId` (the `reqId` Fastify logs on every line) so the real error is one grep away in the log, where it is also written via `request.log.error` — and attached as `err.cause`, so a consumer `setErrorHandler` can map `err.cause.code === '23505'` to `409` itself. **`exposeDebugInfo: true` is the only way to get the driver detail on the wire** — set it while developing, where a client building against the API cannot always read your log: the `500` then also carries `debugInfo` (`message`, `code`, `constraint`, `detail`, `stack`), additively, so the four fields above keep their production shape. Nothing else flips it: not `debug` (server-side only, and it belongs to whoever registers the plugin), not `NODE_ENV`. Errors thrown by `onRequests` hooks run before the handler and are unaffected.
-- **Request limits**: `maxItemsPerPage` (default 1000) caps the search page size and is applied as the `LIMIT` even when no paginator is sent (so an empty-body search can't dump a whole table); over-limit `itemsPerPage` → 400. `maxBulkItems` (default 1000) caps the bulk array length via schema `maxItems` → 400. Programmatic `sqlApi.*` calls are uncapped.
+- **Request limits**: `maxItemsPerPage` (default 1000) caps the search page size and is applied as the `LIMIT` even when no paginator is sent (so an empty-body search can't dump a whole table); over-limit `itemsPerPage` → 400. `maxBulkItems` (default 1000) caps the bulk array length via schema `maxItems` → 400. Two further caps are **fixed, not configurable**, and bound how much work one search may ask for: at most **100 `conditions`** and **20 comma-separated `orderBy` parts** — each dotted condition and each 3-part `orderBy` token becomes its own correlated subquery, which `maxItemsPerPage` does not bound. Over either limit → 400; the request schema also caps `orderBy` at 1024 characters. Those two live in the **search engine**, not in the route, so they apply to programmatic `sqlApi.search()` as well, together with the `paginator` integer guard. What `sqlApi.*` does *not* inherit are the two configurable caps, which belong to the routes: pass `maxRows` to `sqlApi.search()` for the same `LIMIT` protection, and bound your own arrays before a bulk call.
 - **Tenant filtering**: when `tenantScope` is set on a table and `getTenantId` is provided in plugin options, all CRUD operations are automatically scoped to the tenant. `getTenantId` returning `null`/`undefined` = admin (no filter). Returning an array = multi-tenant user (IN clause). The tenant belongs to the *request*, not to the table it addresses: a scoped table is filtered even when reached as a join target or written as a secondary of an unscoped host, so `getTenantId` must tolerate a request with no authenticated user (`req.user?.x ?? null`).
 
 ---

package/AGENTS_FRONTEND.md

@@ -77,7 +77,7 @@ Response (each section present only if requested):
 
 `orderBy` forms (comma-separable): `field [ASC|DESC]` | `alias.parentField` (joinLeft-eligible alias, adds LEFT JOIN) | `alias.fn.field` (fn: sum|min|max|avg|count|distinctCount — the joinGroup with that fn+field MUST be in the body; rows without children sort as 0). For 3-part orderBy and HAVING-style conditions: `aggregations.by` is allowed only when it equals the correlation FK (else 400); aggregation orderBy is rejected (400) on tables with distinctResults.
 
-Condition methods (params arity): `isEqual|isNotEqual|isGreater|isGreaterOrEqual|isLess|isLessOrEqual|isNotGreater|isNotGreaterOrEqual|isNotLess|isNotLessOrEqual` → `[v]`; `isLike|isNotLike|isILike|isNotILike` → `["%p%"]`; `isBetween|isNotBetween` → `[from,to]`; `isIn|isNotIn` → `[[v1,v2]]`; `isNull|isNotNull` → `[]`. Unknown field or method → 400.
+Condition methods (params arity): `isEqual|isNotEqual|isGreater|isGreaterOrEqual|isLess|isLessOrEqual|isNotGreater|isNotGreaterOrEqual|isNotLess|isNotLessOrEqual` → `[v]`; `isLike|isNotLike|isILike|isNotILike` → `["%p%"]`; `isBetween|isNotBetween` → `[from,to]`; `isIn|isNotIn` → `[[v1,v2]]`; `isNull|isNotNull` → `[]`. Unknown field or method → 400; so is a `params` that is not an array or is shorter than the arity above (`isNull`/`isNotNull` take none).
 
 ## WRITES
 
@@ -108,4 +108,4 @@ Condition methods (params arity): `isEqual|isNotEqual|isGreater|isGreaterOrEqual
   "fields": [ { "path": "body.main.name", "code": "required", "message": "must have required property 'name'" } ] }
 ```
 
-Other: 404 (get/delete not found), 400 `itemsPerPage exceeds the maximum` (lower it), 500 raw DB errors (constraint violations surface unmapped).
+Other: 404 (get/delete not found), 400 `itemsPerPage exceeds the maximum` (lower it), 500 raw DB errors (constraint violations surface unmapped). Fixed complexity caps, per search: **100 `conditions`** per section (top level and each join family) and **20** comma-separated `orderBy` parts (`orderBy` string ≤ 1024 chars) — over either → 400: collapse a long list of equality conditions into one `isIn`. `paginator.page` and `paginator.itemsPerPage` must be integers ≥ 1 — send numbers, not querystring strings.

package/BREAKING_CHANGES.md

@@ -1,5 +1,7 @@
 # Breaking Changes — Join API redesign
 
+*Landed in **0.1.3**.*
+
 The join API was rewritten to be explicit, alias-based, and to add a real `LEFT JOIN` mode (`joinLeft`) for N:1 relationships. **No backward compatibility** — old names are rejected with 400. Both backend (table configuration) and frontend (request/response shapes) are affected. This document is the single source of truth for migrating either side.
 
 ## Why this changed
@@ -265,6 +267,8 @@ The engine rejects, with `statusCode: 400`, any of:
 
 # Breaking Change — computed field placeholders use `?` markers
 
+*Landed in **0.1.6**.*
+
 `ComputedFieldExpr.expr` must now mark each bound value with `?`. The engine assigns the
 placeholder positions. Writing `$1` (or `db.ph(n)`) inside the expression no longer works and
 is rejected with a descriptive error.
@@ -320,6 +324,8 @@ values in the parameter order.
 
 # Breaking Change — by-single-id operations disabled for composite primary keys
 
+*Landed in **0.1.11**.*
+
 Since **0.1.11**, tables whose `primary` is an array of more than one field no longer expose
 the operations that address a record by a single PK value:
 
@@ -385,6 +391,8 @@ endpoints previously behaved correctly for you — they are now gone and you mus
 
 # Breaking Change — unknown filter keys are rejected
 
+*Landed in **0.1.14**.*
+
 `filters` keys that match nothing are now a `400`, on the main table and on every join family.
 Previously they were dropped without a word.
 
@@ -458,8 +466,103 @@ delegates to the target's own `filters()` and does run `extendedCondition`.
 
 ---
 
+# Breaking Change — request limits, condition arity and tenant scope inside subqueries
+
+*Landed in **0.2.0**.*
+
+## Why this changed
+
+Four ways a single search request could do more than the plugin admitted, and one where the
+declared scope was not the enforced one.
+
+- `maxItemsPerPage` bounds the **rows a search returns**, not the work done to find them. Every
+  dotted `conditions` entry and every 3-part `orderBy` token becomes its own correlated subquery,
+  so an uncapped list turned one request into arbitrarily many.
+- `paginator.page` and `paginator.itemsPerPage` are rendered straight into `LIMIT`/`OFFSET`.
+  `Paginator` is a compile-time type only, and `sqlApi.search()` is a documented public API a
+  consumer may hand an unvalidated querystring — the integer check has to exist at runtime.
+- `key in map` and `map[key]` walk `Object.prototype`, so `constructor`, `toString`, `valueOf`,
+  `hasOwnProperty` and `__proto__` satisfied every "is this a known field" check and reached the
+  SQL builders, where they rendered as `undefined` or as a column that does not exist.
+- A condition method was dispatched with whatever `params` carried. A missing or wrongly shaped
+  one threw a `TypeError` inside the builder, which the error handler can only report as a 500.
+- `tenantScope` was applied to the main query and to the tables a request addressed directly. The
+  subqueries and child writes the same request produced carried no scope, so a scoped table was
+  still readable and writable through its own relations.
+
+## What changed
+
+Every row below answers **400** where it previously did something else.
+
+| Input | Rule now | Before |
+|---|---|---|
+| `conditions` | at most **100** entries, per section (top level and each join family) — schema `maxItems` plus an engine backstop | unbounded |
+| `orderBy` | at most **20** comma-separated parts; the request schema also caps the string at **1024** characters | unbounded |
+| `paginator` | `page` and `itemsPerPage` must both be integers `>= 1`, checked before any query runs | any value, rendered into `LIMIT`/`OFFSET` as-is |
+| condition `params` | must be an array; single-value methods need 1 entry, `isBetween`/`isNotBetween` 2, `isIn`/`isNotIn` an array as the first entry | passed to the builder as-is → `TypeError` → 500 |
+| field names | inherited `Object.prototype` keys are not fields, in `filters`, condition fields, `orderBy` and `selectComputed` | resolved as known fields and reached the SQL |
+
+The two caps are exported as `MAX_CONDITIONS` and `MAX_ORDER_BY_PARTS`. Both checks live in the
+**engine**, not in the route, which is what covers `sqlApi.search()` — no schema validates a
+programmatic caller. `isNull`/`isNotNull` still take no params, and an explicit `undefined` handed
+to `isIn` remains the documented no-op.
+
+And `tenantScope` now follows the request into everything it touches:
+
+- **secondaries** — a child row written alongside a main row is scoped and anchored by the child
+  table's own `tenantScope`;
+- **`joinLeft`** — the predicate lands in the `ON` clause, so `LEFT` semantics survive;
+- **`joinGroup` aggregation subqueries**, and the 3-part aggregation `orderBy` built on them —
+  they counted and summed every tenant's child rows, which disagreed with the scoped
+  `result.joinGroup` for the same alias and leaked the existence of the rest.
+
+## Who is affected
+
+- **A client that sends more than 100 `conditions` or more than 20 `orderBy` parts.** Generated
+  filter UIs are the realistic case: a "select all" that emits one condition per row.
+- **A caller that forwards a raw querystring to `sqlApi.search()`.** `itemsPerPage: '10'` is a
+  string and is now a 400: parse the querystring before you forward it.
+- **Conditions assembled programmatically.** One built with a missing `params` used to reach the
+  builder; it is now refused up front, with the method named.
+- **Any deployment using `tenantScope` with `secondaries`, `joinLeft` or `joinGroup`.**
+  Aggregates that used to count across tenants return smaller numbers, and an ordering built on
+  them changes with it. A secondary write that used to land in another tenant's rows is now
+  refused. This is the fix, not a regression — but a dashboard whose numbers were computed
+  cross-tenant will move.
+
+Not affected: requests within the caps, a well-formed integer `paginator`, and any deployment
+without `tenantScope`.
+
+## Migration
+
+Split an oversized `conditions` list rather than raising anything — the caps are not configurable:
+
+```typescript
+// Before: one request with 400 conditions
+{ conditions: ids.map((id) => ({ field: 'id', method: 'isEqual', params: [id] })) }
+
+// After: one condition, one bound array
+{ conditions: [{ field: 'id', method: 'isIn', params: [ids] }] }
+```
+
+Parse a querystring before it reaches `sqlApi.search()`:
+
+```typescript
+const paginator = {
+  page: Number.parseInt(req.query.page ?? '1', 10),
+  itemsPerPage: Number.parseInt(req.query.itemsPerPage ?? '50', 10),
+};
+```
+
+Then re-read any number your product computes from `joinGroup`: if it was collected under a
+tenant scope, it was counting rows that tenant cannot see, and it changes with this release.
+
+---
+
 # Breaking Change — the tenant follows the request, not the table it addresses
 
+*Landed in **0.2.1**.*
+
 `tenantScope` on a table is now enforced even when the request was addressed to a **different**
 table that reaches it through a relation. Previously the tenant was resolved from the addressed
 table alone: if that table declared no `tenantScope`, no predicate was applied anywhere — not to
@@ -541,6 +644,8 @@ grant, and the scope is only the cap on it.
 
 # Breaking Change — secondaries run the child table's `beforeInsert`
 
+*Landed in **0.2.2**.*
+
 ## Why this changed
 
 `processSecondaries` consulted the child table's configuration for its `excludeFromCreation` and

package/CHANGELOG.md

@@ -7,7 +7,75 @@ All notable changes to this project are documented here. This project follows
 
 Migration instructions for breaking changes live in **[BREAKING_CHANGES.md](./BREAKING_CHANGES.md)**.
 
-## [Unreleased]
+## [0.2.4]
+
+### Added
+
+- **`excludeColumns` config option** — the lever for *"this column must not exist for the API at
+  all"*. [ADR 0017](./docs/adr/0017-the-schema-is-the-contract.md), the README and `AGENTS.md`
+  all pointed at "trim it out of the Schema" for that case, and no such lever existed: Schema
+  files are generated and overwritten on every run, so the only way to drop a column was to
+  re-edit the file after each `sqlapi-generate-schema` — or to pair `readExclude` with
+  `writeExclude`, which `defineTable` refuses. `excludeColumns` in `sqlapi.config.ts` takes
+  `"<table>.<column>"` entries matched against the DB names, with `*` as a wildcard on either
+  side (`'user.password_hash'`, `'*.internal_*'`), and drops the column from the generated Schema
+  — its fields, `colMap` and `generatedFields` — so no route, filter, order or manifest ever
+  sees it. A primary key column is refused (every route identifies rows with it), and so is a
+  pattern that would leave a table with no columns: that is `excludeTables`' job. Applied after
+  `excludeTables`, so a column pattern is never checked against a table the generator does not
+  see. **Regenerate your schemas** after adding entries. See
+  [ADR 0019](./docs/adr/0019-column-exclusion-is-generation-time-config.md).
+
+### Changed
+
+- **The docs no longer say "trim the Schema".** The README lever table, `AGENTS.md`,
+  `AGENTS_BACKEND.md` and the `defineTable` error for a field in both `readExclude` and
+  `writeExclude` now point at `excludeColumns`.
+
+## [0.2.3]
+
+### Fixed
+
+- **MySQL read every default *expression* as a database-computed column.** The generator
+  matched `information_schema.columns.EXTRA` on the substring `generated`, and MySQL writes
+  `DEFAULT_GENERATED` there for **any** column whose default is an expression —
+  `DEFAULT CURRENT_TIMESTAMP` above all, but also `DEFAULT (UUID())`, `DEFAULT (CURRENT_DATE)`,
+  a JSON default. Every one of those columns came out of `sqlapi-generate-schema` listed under
+  `generatedFields`, which the runtime strips from the insert, update and bulk-upsert bodies and
+  again inside the engines: the column stopped being writable, silently, with no error anywhere —
+  a client sending it had the value dropped and read back whatever the default had produced. On a
+  schema that timestamps its tables, that is every table. Only `GENERATION_EXPRESSION` separates
+  the two cases — it is non-empty for a real `GENERATED ALWAYS AS (<expr>)` column and empty for a
+  default expression — and it is now what the flag reads, with the `EXTRA` markers
+  (`VIRTUAL GENERATED`, `STORED GENERATED`, `PERSISTENT GENERATED`) kept as a fallback for a
+  server or driver that does not return it. MySQL and MariaDB only; PostgreSQL was never
+  affected. **Regenerate your schemas** (`sqlapi-generate-schema`) to get the columns back.
+
+- **The agent manifest's markdown never rendered `readOnly`.** The JSON manifest has carried the
+  flag since 0.2.2, but `/agent/manifest.md` — the rendering built to go into a system prompt —
+  dropped it, so the one consumer that reads the markdown, a model, kept putting non-writable
+  columns in write payloads and kept having them dropped. The notation now carries `(readOnly)`
+  alongside `(writeOnly)`, and the legend explains it.
+
+- **`ApiRequest` was documented as exported and was not.** [ADR 0018](./docs/adr/0018-one-seam-to-the-http-framework.md)
+  and the 0.2.2 entry below both say the type is exported from the package; `src/index.ts` never
+  re-exported it, so a consumer typing a hook or a `getTenantId` against it had to import from a
+  `dist/` internal path. It is now part of the public type exports.
+
+- **The upsert conflict guard failed open on a `NULL` owner in single-column tenant scopes.**
+  `col NOT IN (...)` evaluates to `NULL`, not `TRUE`, when the column is `NULL`, so a conflicting
+  row belonging to nobody slipped past the probe and could be claimed and overwritten by any
+  tenant's upsert. The single-column branch now reads `(col IS NULL OR col NOT IN (...))` —
+  an unowned row is foreign — which is what the `anyOf` branch and the read side already did.
+
+- **Documentation corrections.** `AGENTS_BACKEND.md` stated that programmatic `sqlApi.*` calls
+  are uncapped. The two *configurable* caps do belong to the routes (`maxItemsPerPage`,
+  `maxBulkItems` — `sqlApi.search()` takes `maxRows` for the first), but the complexity caps
+  (100 `conditions`, 20 `orderBy` parts) and the `paginator` integer guard live in the engine and
+  have always applied to `sqlApi.search()` too. `AGENTS_BACKEND.md` and `README.md` now say which
+  cap sits where, and the fixed caps are documented at all.
+
+## [0.2.2]
 
 ### Added
 
@@ -50,6 +118,7 @@ Migration instructions for breaking changes live in **[BREAKING_CHANGES.md](./BR
   `Table*.ts` the generator never overwrites. The CLI also prints the columns it found, per
   table, since a generated source file is not always read. See
   [ADR 0015](./docs/adr/0015-non-writable-columns.md).
+
 - **`writeExclude` on `defineTable`** — the write-side counterpart of `readExclude`, for the
   non-writable columns introspection cannot know about (one a trigger owns, one a migration is
   about to drop). Reads are untouched: the field stays projected, filterable and orderable. It
@@ -57,6 +126,7 @@ Migration instructions for breaking changes live in **[BREAKING_CHANGES.md](./BR
   (ADR 0005): a hook cannot put back a value the database will refuse. `defineTable` rejects an
   unknown field, the primary key, and a field that is also `readExclude`d. It is static and
   applies to everyone — a rule that depends on *who* is asking is still product logic (ADR 0004).
+
 - **The agent manifest marks non-writable fields** `readOnly`, alongside the existing
   `writeOnly` for `readExclude`.
 
@@ -74,6 +144,70 @@ Migration instructions for breaking changes live in **[BREAKING_CHANGES.md](./BR
   column a relation joins on cannot break the correlation. `SearchParams`/`GetParams` now carry
   the optional `request`, which `sqlApi.search()`/`sqlApi.get()` forward when given one.
 
+### Changed
+
+- **The update body requires the primary key**, which identifies the row it updates
+  (`PUT /rest/:table` carries it in `main`). The generated PK field is `Optional` — it is
+  absent on insert — and that modifier reached the update body unchanged, so a request omitting
+  `main.id` built its `WHERE` on `undefined` instead of being rejected. The code comment said
+  "PK required" all along.
+
+- **A secondary now runs the child table's `beforeInsert`.** `processSecondaries` already applied
+  the child's `excludeFromCreation` and its `tenantScope` but skipped its `beforeInsert`, so a
+  table whose hook *transformed* a value — encrypting a column, normalising a unit — stored the
+  raw client value whenever its rows arrived as another table's children, and the correct one
+  through its own route. Nothing failed at write time; the row read back as garbage later. The
+  hook runs after the exclusion strip and before the engine's FK auto-fill, which stays
+  authoritative, and receives the transaction connection. The child's `validate` and
+  `afterInsert` deliberately still do not run — see
+  [ADR 0014](./docs/adr/0014-what-follows-a-write-join.md). **Breaking** for a `beforeInsert`
+  written assuming it only ever ran on its own table's route.
+
+- **The get response schema honours `readExclude`**, like the search response already did; it
+  previously advertised fields the engine never selects. It now lives in `lib/schema/get.ts`
+  (`GetTableResponse`) instead of inline in the route, which is how it had drifted.
+  `schemaOverrides` stays where it was — write bodies only: an override rules what the API
+  accepts from now on, while the rows already stored predate it, so narrowing the response
+  would promise something no one can retroactively make true.
+
+### Fixed
+
+- **A `tenantScope` naming a schema field instead of a column now fails at startup.**
+  `tenantScope` names real DB columns — the scope is applied to the SQL, after the payload has
+  been converted, and `through.foreignField` belongs to a parent table that may have no config of
+  its own. Nothing checked it, so writing `organizationId` where the column is `organization_id`
+  passed `defineTable` and surfaced as `column "organizationId" does not exist` on every request
+  to the table: an opaque `500`, failing closed but saying nothing. All four positions are now
+  checked (`column`, each `anyOf` entry, `through.localField`, and `through.foreignField` against
+  the parent schema). The check is narrow by design — it fires only when the name *is* a schema
+  field whose column differs, so a column absent from the schema raises nothing and a camelCase
+  database, where `col()` is the identity, raises nothing either.
+
+- **The `no-static-optional-peer` gate had never been able to fire.** `includeOnly: '^src/'` in
+  `.dependency-cruiser.mjs` dropped every npm edge from the dependency graph, so the rule meant to
+  stop a static import of `pg` / `mysql2` / `@fastify/*` — which breaks installs that use the other
+  dialect — matched nothing, ever. The graph now keeps npm dependencies as leaves, and the rule is
+  qualified to what its name says: static, value-level imports only, since a type-only import is
+  erased at compile time and a dynamic one is what the rule asks for. Both gates were verified by
+  introducing a violation and watching them fail.
+
+- **`defineTable` never validated `primary`.** A primary key naming a field the schema does not
+  have passed startup untouched and became a raw SQL error on the first request — a `500`. It
+  now throws at `defineTable` time, naming the field and the operations that need it. The one
+  exception is exact: a table exposing only `search` and declaring its own `defaultOrder` never
+  reads `primary`, which is the shape generated for a view whose key could not be inferred.
+
+- **PostgreSQL identity columns made a table impossible to insert into.**
+  `GENERATED ... AS IDENTITY` reports no `column_default`, which is what the generator read to
+  decide that the database fills a column in — so the primary key came out **mandatory** in the
+  write body while PostgreSQL rejected any explicit value for it (`Column "id" is an identity
+  column defined as GENERATED ALWAYS`). Identity columns are now flagged like MySQL's
+  `AUTO_INCREMENT`: the field is Optional and the CLI lists it under `excludeFromCreation`.
+
+## [0.2.1]
+
+### Added
+
 - **`tenantScope` over several owner columns — `{ anyOf: [...] }`.** A row that belongs to two
   parties and is visible to either — a message (`sender_id` / `recipient_id`), a transfer
   (`from_account_id` / `to_account_id`), a shift swap — could not be expressed before, leaving
@@ -91,6 +225,7 @@ Migration instructions for breaking changes live in **[BREAKING_CHANGES.md](./BR
   byte-identical SQL. The three forms do not mix — `defineTable` throws at startup on `anyOf`
   combined with `column` or `through`, on an empty or malformed `anyOf`, and on a scope
   declaring no owner column at all.
+
 - `QueryClient.bulkInsertOrUpdate` takes an optional trailing `immutableCols`: columns written
   on insert but left untouched when the statement lands on an existing row. Additive.
 
@@ -111,6 +246,7 @@ Migration instructions for breaking changes live in **[BREAKING_CHANGES.md](./BR
   their own scope emit unchanged SQL. Migration — including the `getTenantId` body that now needs
   to tolerate an unauthenticated request — in
   [BREAKING_CHANGES.md](./BREAKING_CHANGES.md#breaking-change--the-tenant-follows-the-request-not-the-table-it-addresses).
+
 - **Database errors no longer reach clients verbatim.** Any error escaping an auto-generated
   route that the plugin did not raise itself now answers `{"statusCode":500,"error":"Internal
   Server Error","message":"Internal Server Error"}` instead of the driver message, which names
@@ -131,6 +267,93 @@ Migration instructions for breaking changes live in **[BREAKING_CHANGES.md](./BR
   controlled) rather than the response body (not, and these routes are open by default). See
   [ADR 0013](./docs/adr/0013-sanitized-db-errors.md).
 
+## [0.2.0]
+
+### Added
+
+- `QueryClient.update` and `QueryClient.delete` take an optional trailing `extraCondition`
+  (a `ConditionBuilder`) merged into the `WHERE` with its values bound in order — how the tenant
+  row guard reaches a write. Additive.
+
+### Changed
+
+- **BREAKING: `conditions` and `orderBy` are capped.** `maxItemsPerPage` bounds the rows a
+  search returns, not the work done to find them: every dotted `conditions` entry and every
+  3-part `orderBy` token becomes its own correlated subquery, so an uncapped list turned one
+  request into arbitrarily many. `conditions` now takes at most **100** entries per section — the
+  top level and each join family — and `orderBy` at most **20** comma-separated parts; over
+  either, the answer is a **400**. The request schemas carry the same numbers (`maxItems`, plus a
+  1024-character cap on the `orderBy` string), so Swagger advertises exactly what the engine
+  enforces. Both are exported as `MAX_CONDITIONS` and `MAX_ORDER_BY_PARTS`, and both are checked
+  **in the engine**, which is what covers `sqlApi.search()` — no schema validates a programmatic
+  caller. See [BREAKING_CHANGES.md](./BREAKING_CHANGES.md#breaking-change--request-limits-condition-arity-and-tenant-scope-inside-subqueries).
+
+- **BREAKING: `paginator` is validated at runtime.** `page` and `itemsPerPage` are rendered
+  straight into `LIMIT`/`OFFSET`, and `Paginator` is a compile-time type only: nothing stopped a
+  string, a fraction, a zero or a `NaN` — or a SQL fragment, on the documented path where a
+  consumer hands `sqlApi.search()` an unvalidated querystring. Both must now be integers `>= 1`,
+  checked before any query runs; anything else is a **400**. A numeric *string* (`itemsPerPage:
+  '10'`) is rejected too, so a querystring must be parsed before it is forwarded.
+
+- **BREAKING: a malformed condition `params` answers 400 instead of 500.** The method was
+  dispatched with whatever `params` carried, so a missing or wrongly shaped one threw a
+  `TypeError` inside the builder — which the error handler could only report as an
+  `Internal Server Error`. Arity is now checked once, at dispatch, for every call site:
+  `params` must be an array, the single-value methods need one entry, `isBetween`/`isNotBetween`
+  need two, and `isIn`/`isNotIn` need an array as their first entry. `isNull`/`isNotNull` still
+  take none, and an explicit `undefined` to `isIn` stays the documented no-op.
+
+- **BREAKING: inherited `Object.prototype` keys are no longer field names.** `key in map` and
+  `map[key]` walk the prototype chain, so `constructor`, `toString`, `valueOf`, `hasOwnProperty`
+  and `__proto__` satisfied every "is this a known field" check and reached the SQL builders,
+  where they rendered as `undefined` or as a column that does not exist. Every allowlist and every
+  field lookup in the search engine now tests own properties, so an inherited name is simply
+  unknown — a **400** in `filters`, condition fields, `orderBy` and `selectComputed`.
+
+- **BREAKING: `tenantScope` reaches the subqueries and the child writes of a request.** The
+  scope was applied to the main query and to the tables addressed directly, and nowhere else, so
+  the same request could still read and write other tenants' rows through its own joins:
+  **secondaries** were written without the child table's scope, **`joinLeft`** embedded the parent
+  unscoped, and the **`joinGroup` aggregation subqueries** — with the 3-part aggregation
+  `orderBy` built on them — counted and summed every tenant's child rows, disagreeing with the
+  scoped `result.joinGroup` for the same alias and leaking the existence of the rest. All four
+  now carry the scope of the table they touch; on `joinLeft` the predicate lands in the `ON`
+  clause, so `LEFT` semantics survive. Aggregates that used to count across tenants return
+  smaller numbers, and an ordering built on them changes with it.
+
+### Internal
+
+- The quality gates became executable and zero-tolerance (eslint, jscpd, knip,
+  dependency-cruiser, lefthook, CI), `search.ts` was split into seven layered modules with an
+  acyclic graph, and `docs/INDEX.md` plus `npm run find-similar` were added as the anti-duplication
+  surface. No runtime behaviour changes with any of it. See
+  [ADR 0012](./docs/adr/0012-anti-duplication-tooling.md).
+
+## [0.1.14]
+
+### Added
+
+- **`fields` allowlist on `buildRelation`** — restricts which of the target table's fields are
+  reachable through one relation, without hiding them from the table's own routes the way
+  `readExclude` would. The relation is declared against a schema narrowed to the list, so
+  `selection`, `filters`, `conditions`, `orderBy`, aggregations and the generated
+  request/response schemas all reject anything outside it with `400 Unknown field`; the default
+  `'*'` selection is spelled out into the allowed columns instead of emitting a real `SELECT *`;
+  and computed fields on the target resolve against the narrowed schema, so one reading an
+  excluded column is a 400 rather than a way around the list. Declaration-time checks: the list
+  must include the join field, and is rejected on `allowedWriteJoins` (write paths resolve
+  `upsertMap` by schema identity and must write every column the caller sent). Fail-closed by
+  design — see [ADR 0011](./docs/adr/0011-join-fields-allowlist.md) for allowlist vs blocklist.
+
+- **[ADR 0010](./docs/adr/0010-joins-do-not-run-route-guards.md)** — a declared join is a read
+  grant: `onRequests` and `operations` are route-level and do not follow a join, so
+  `allowedReadJoins` grants read access to the target table under the *host* table's
+  authorization. Documents what does cross a join (`readExclude`, `tenantScope`, the relation's
+  schema), the trimmed-schema + explicit-`selection` pattern for column-level narrowing, and
+  the rejected alternatives (`canBeJoined` hook, `selection` as a ceiling).
+
+### Changed
+
 - **Unknown `filters` keys are now rejected with `400 Unknown filter field: <key>`** instead
   of being dropped in silence — on the main table and on every join family. The engine only
   ever visited keys matching a schema field, an `extraFilters` entry or a computed field, so a
@@ -140,64 +363,15 @@ Migration instructions for breaking changes live in **[BREAKING_CHANGES.md](./BR
   covers `sqlApi.search()` as well as the HTTP routes. `undefined` values still mean "filter
   not supplied" and are ignored; an explicit `null` still filters by `IS NULL`. See
   [BREAKING_CHANGES.md](./BREAKING_CHANGES.md#breaking-change--unknown-filter-keys-are-rejected).
+
 - **`joinLeft.<alias>.filters` no longer advertises the parent's `extraFilters`.** They were
   present in the generated body schema and in Swagger, but `buildLeftJoinClauses` never runs
   the target's `extendedCondition` (its column references cannot be qualified with the
   `LEFT JOIN` alias), so the filter applied nothing. They are now rejected with a `400` naming
   the reason and pointing at `joinMustExist` on the same relation.
 
-- **The update body requires the primary key**, which identifies the row it updates
-  (`PUT /rest/:table` carries it in `main`). The generated PK field is `Optional` — it is
-  absent on insert — and that modifier reached the update body unchanged, so a request omitting
-  `main.id` built its `WHERE` on `undefined` instead of being rejected. The code comment said
-  "PK required" all along.
-- **A secondary now runs the child table's `beforeInsert`.** `processSecondaries` already applied
-  the child's `excludeFromCreation` and its `tenantScope` but skipped its `beforeInsert`, so a
-  table whose hook *transformed* a value — encrypting a column, normalising a unit — stored the
-  raw client value whenever its rows arrived as another table's children, and the correct one
-  through its own route. Nothing failed at write time; the row read back as garbage later. The
-  hook runs after the exclusion strip and before the engine's FK auto-fill, which stays
-  authoritative, and receives the transaction connection. The child's `validate` and
-  `afterInsert` deliberately still do not run — see
-  [ADR 0014](./docs/adr/0014-what-follows-a-write-join.md). **Breaking** for a `beforeInsert`
-  written assuming it only ever ran on its own table's route.
-- **The get response schema honours `readExclude`**, like the search response already did; it
-  previously advertised fields the engine never selects. It now lives in `lib/schema/get.ts`
-  (`GetTableResponse`) instead of inline in the route, which is how it had drifted.
-  `schemaOverrides` stays where it was — write bodies only: an override rules what the API
-  accepts from now on, while the rows already stored predate it, so narrowing the response
-  would promise something no one can retroactively make true.
-
 ### Fixed
 
-- **A `tenantScope` naming a schema field instead of a column now fails at startup.**
-  `tenantScope` names real DB columns — the scope is applied to the SQL, after the payload has
-  been converted, and `through.foreignField` belongs to a parent table that may have no config of
-  its own. Nothing checked it, so writing `organizationId` where the column is `organization_id`
-  passed `defineTable` and surfaced as `column "organizationId" does not exist` on every request
-  to the table: an opaque `500`, failing closed but saying nothing. All four positions are now
-  checked (`column`, each `anyOf` entry, `through.localField`, and `through.foreignField` against
-  the parent schema). The check is narrow by design — it fires only when the name *is* a schema
-  field whose column differs, so a column absent from the schema raises nothing and a camelCase
-  database, where `col()` is the identity, raises nothing either.
-- **The `no-static-optional-peer` gate had never been able to fire.** `includeOnly: '^src/'` in
-  `.dependency-cruiser.mjs` dropped every npm edge from the dependency graph, so the rule meant to
-  stop a static import of `pg` / `mysql2` / `@fastify/*` — which breaks installs that use the other
-  dialect — matched nothing, ever. The graph now keeps npm dependencies as leaves, and the rule is
-  qualified to what its name says: static, value-level imports only, since a type-only import is
-  erased at compile time and a dynamic one is what the rule asks for. Both gates were verified by
-  introducing a violation and watching them fail.
-- **`defineTable` never validated `primary`.** A primary key naming a field the schema does not
-  have passed startup untouched and became a raw SQL error on the first request — a `500`. It
-  now throws at `defineTable` time, naming the field and the operations that need it. The one
-  exception is exact: a table exposing only `search` and declaring its own `defaultOrder` never
-  reads `primary`, which is the shape generated for a view whose key could not be inferred.
-- **PostgreSQL identity columns made a table impossible to insert into.**
-  `GENERATED ... AS IDENTITY` reports no `column_default`, which is what the generator read to
-  decide that the database fills a column in — so the primary key came out **mandatory** in the
-  write body while PostgreSQL rejected any explicit value for it (`Column "id" is an identity
-  column defined as GENERATED ALWAYS`). Identity columns are now flagged like MySQL's
-  `AUTO_INCREMENT`: the field is Optional and the CLI lists it under `excludeFromCreation`.
 - **Join validation no longer depends on the main result set.** `joinMultiple` / `joinLeft` /
   `joinGroup` skip their side query entirely when the main query matched no rows, so everything
   validated inside it was skipped with it — the same request answered 400 or 200 depending on
@@ -206,25 +380,9 @@ Migration instructions for breaking changes live in **[BREAKING_CHANGES.md](./BR
   filters are now validated up front, and the selection and aggregation lists are resolved
   before the empty-result bail-out.
 
-### Added
+## [0.1.13]
 
-- **`fields` allowlist on `buildRelation`** — restricts which of the target table's fields are
-  reachable through one relation, without hiding them from the table's own routes the way
-  `readExclude` would. The relation is declared against a schema narrowed to the list, so
-  `selection`, `filters`, `conditions`, `orderBy`, aggregations and the generated
-  request/response schemas all reject anything outside it with `400 Unknown field`; the default
-  `'*'` selection is spelled out into the allowed columns instead of emitting a real `SELECT *`;
-  and computed fields on the target resolve against the narrowed schema, so one reading an
-  excluded column is a 400 rather than a way around the list. Declaration-time checks: the list
-  must include the join field, and is rejected on `allowedWriteJoins` (write paths resolve
-  `upsertMap` by schema identity and must write every column the caller sent). Fail-closed by
-  design — see [ADR 0011](./docs/adr/0011-join-fields-allowlist.md) for allowlist vs blocklist.
-- **[ADR 0010](./docs/adr/0010-joins-do-not-run-route-guards.md)** — a declared join is a read
-  grant: `onRequests` and `operations` are route-level and do not follow a join, so
-  `allowedReadJoins` grants read access to the target table under the *host* table's
-  authorization. Documents what does cross a join (`readExclude`, `tenantScope`, the relation's
-  schema), the trimmed-schema + explicit-`selection` pattern for column-level narrowing, and
-  the rejected alternatives (`canBeJoined` hook, `selection` as a ceiling).
+### Added
 
 - **`excludeTables` config option** — blacklist for `sqlapi-generate-schema`. Tables
   listed in `excludeTables` in `sqlapi.config.ts` (exact names or `*` globs, e.g.