@venizia/ignis-docs 0.2.1-0 → 0.2.1-1

package/content/guides/core-concepts/persistent/datasources.md

@@ -3,7 +3,7 @@
 A DataSource manages database connections and supports **schema auto-discovery** from repositories.
 
 > [!NOTE] Connectors
-> This guide covers the **PostgreSQL connector** (`BasePostgresDataSource`, aliased as `BaseDataSource` for backward compatibility) - the primary relational engine and the one used by most applications. IGNIS also ships a **typesense connector** for full-text/vector search (see [Search & Typesense](./search-typesense)). Both implement the same engine-neutral `AbstractDataSource` contract - see [Connectors](/references/base/connectors) for the architecture.
+> This guide covers the **PostgreSQL connector** (`BasePostgresDataSource`, aliased as `BaseDataSource` for backward compatibility). It's the primary relational engine and the one used by most applications. IGNIS also ships a **SQLite connector** (`BaseSqliteDataSource`, see [SQLite](./sqlite)) and a **typesense connector** for full-text/vector search (see [Search & Typesense](./search-typesense)). All three implement the same engine-neutral `AbstractDataSource` contract - see [Connectors](/references/base/connectors) for the architecture.
 
 ## Creating a DataSource
 
@@ -57,7 +57,7 @@ export class PostgresDataSource extends BasePostgresDataSource<IDSConfigs> {
 ```
 
 > [!NOTE] Driver seam: the raw client goes on `this.client`
-> `this.client = new Pool(...)` is the short path: `configure()` builds only the client, and `getConnector()`/`beginTransaction()` lazily instantiate the class named in `@datasource({ driver })` over it - `NodePostgresDriver` here. There is no `pool` field - the raw-client slot is `client`, whatever the client happens to be. Naming the driver class (rather than a driver-name string) is what carries `pg` into the app's bundle - a bundler only packages a real value reference, never text. The alternative is to wire a driver yourself for a custom or third-party driver: `configure()` calls `this.useDriver({ driver, schema? })`, which assigns `this.driver` **and** builds `this.connector` in one step (so the half-wired state cannot exist), bypassing `@datasource({ driver })` entirely. See [Postgres Drivers & Supabase](./postgres-drivers) for `postgres-js` and Supabase.
+> `this.client = new Pool(...)` is the short path: `configure()` builds only the client. `getConnector()`/`beginTransaction()` lazily instantiate the class named in `@datasource({ driver })` over it - `NodePostgresDriver` here. There is no `pool` field - the raw-client slot is `client`, whatever the client happens to be. Naming the driver class (rather than a driver-name string) is what carries `pg` into the app's bundle. A bundler only packages a real value reference, never text. The alternative is to wire a driver yourself for a custom or third-party driver: `configure()` calls `this.useDriver({ driver, schema? })`. That assigns `this.driver` **and** builds `this.connector` in one step (so the half-wired state cannot exist), bypassing `@datasource({ driver })` entirely. See [Postgres Drivers & Supabase](./postgres-drivers) for `postgres-js` and Supabase.
 
 **How auto-discovery works:**
 

package/content/guides/core-concepts/persistent/index.md

@@ -3,7 +3,7 @@
 The persistent layer manages data using [Drizzle ORM](https://orm.drizzle.team/) for type-safe database access and the Repository pattern for data abstraction.
 
 > [!NOTE] Connectors
-> This page and the ones below it focus on the **PostgreSQL connector** (Drizzle + relational tables), the default and most common engine. The persistence layer also ships a **typesense connector** for search (see [Search & Typesense](./search-typesense)). Both share the same engine-neutral `AbstractRepository`/`AbstractDataSource`/`AbstractEntity` contracts - see [Connectors](/references/base/connectors) for the architecture.
+> This page and the ones below it focus on the **PostgreSQL connector** (Drizzle + relational tables), the default and most common engine. The persistence layer also ships a **SQLite connector** (see [SQLite](./sqlite)) and a **typesense connector** for search (see [Search & Typesense](./search-typesense)). All three share the same engine-neutral `AbstractRepository`/`AbstractDataSource`/`AbstractEntity` contracts - see [Connectors](/references/base/connectors) for the architecture.
 
 ## Architecture Overview
 
@@ -32,6 +32,8 @@ The persistent layer manages data using [Drizzle ORM](https://orm.drizzle.team/)
 | **Repositories** | Provide type-safe CRUD operations | [Repositories Guide](./repositories.md) |
 | **Transactions** | Handle atomic multi-step operations (PostgreSQL connector only) | [Transactions Guide](./transactions.md) |
 | **Search & Typesense** | Full-text/faceted search over documents | [Search & Typesense Guide](./search-typesense.md) |
+| **PGlite** | Postgres compiled to WebAssembly, running in-process | [PGlite Guide](./pglite.md) |
+| **SQLite** | The second SQL engine, via libsql | [SQLite Guide](./sqlite.md) |
 
 ## Quick Example
 
@@ -107,6 +109,8 @@ export class Application extends BaseApplication {
   - [DataSources](./datasources) - Database connections
   - [Repositories](./repositories) - Data access layer
   - [Transactions](./transactions) - Atomic operations
+  - [PGlite](./pglite) - Postgres in-process, for tests and embedded deployment
+  - [SQLite](./sqlite) - The second SQL engine, and what it refuses
   - [Search & Typesense](./search-typesense) - The typesense connector
 
 - **Related Concepts:**

package/content/guides/core-concepts/persistent/pglite.md

@@ -0,0 +1,218 @@
+# PGlite - Postgres In Your Process
+
+PGlite is PostgreSQL compiled to WebAssembly. It runs inside your Node or Bun process, with no server, no port and no container. IGNIS reaches it through `PGliteDriver`, a third driver on the unchanged Postgres connector.
+
+```typescript
+import { PGlite } from '@electric-sql/pglite';
+import { datasource } from '@venizia/ignis';
+import type { TAnyDataSourceSchema, ValueOrPromise } from '@venizia/ignis';
+import { BasePostgresDataSource } from '@venizia/ignis/postgres';
+import { PGliteDriver } from '@venizia/ignis/postgres/pglite';
+
+@datasource({ driver: PGliteDriver })
+export class TestDataSource extends BasePostgresDataSource<{}, TAnyDataSourceSchema, {}, PGlite> {
+  constructor() {
+    super({ name: TestDataSource.name, config: {} });
+  }
+
+  override configure(): ValueOrPromise<void> {
+    this.client = new PGlite();
+  }
+
+  override getConnectionString(): ValueOrPromise<string> {
+    return 'memory://';
+  }
+}
+```
+
+Your models, repositories and filters do not change. PGlite reports `PostgreSQL 18.3`, so every statement the filter builder emits works unchanged - `#>>` JSON paths, `ILIKE`, regex operators, arrays, `SELECT ... FOR UPDATE`.
+
+> [!IMPORTANT] Optional peer dependency
+> `@electric-sql/pglite` is an optional peer. Only the driver class you import and name in `@datasource({ driver })` reaches your bundle.
+>
+> ```bash
+> bun add @electric-sql/pglite
+> ```
+
+## What PGlite is good for
+
+Two cases, and they are the only two worth the constraints below.
+
+**An honest test database.** Your suite gets real Postgres semantics in-process - no Docker, no fixture server, no port collisions between parallel CI jobs. A SQLite test database would answer differently from production. PGlite answers the same. IGNIS runs its own relational conformance suite this way.
+
+**Embedded deployment.** A CLI, a desktop app or an edge worker ships one data directory instead of a database service. `new PGlite('./pgdata')` creates and opens it. PGlite is a directory rather than a single file - `dumpDataDir()` is what packs it into one artifact.
+
+Anything with concurrent writers belongs on a real Postgres server. Read [the constraints](#the-constraints) before you pick PGlite for a running service.
+
+## Wiring a persistent instance
+
+Point PGlite at a directory and it persists there:
+
+```typescript
+import { PGlite } from '@electric-sql/pglite';
+import { datasource } from '@venizia/ignis';
+import type { TAnyDataSourceSchema, ValueOrPromise } from '@venizia/ignis';
+import { BasePostgresDataSource } from '@venizia/ignis/postgres';
+import { PGliteDriver } from '@venizia/ignis/postgres/pglite';
+
+interface IDataSourceConfigs {
+  dataDir: string;
+}
+
+@datasource({ driver: PGliteDriver })
+export class EmbeddedDataSource extends BasePostgresDataSource<
+  IDataSourceConfigs,
+  TAnyDataSourceSchema,
+  {},
+  PGlite
+> {
+  constructor() {
+    super({
+      name: EmbeddedDataSource.name,
+      config: { dataDir: process.env.APP_ENV_PGLITE_DATA_DIR ?? './pgdata' },
+    });
+  }
+
+  override configure(): ValueOrPromise<void> {
+    this.client = new PGlite(this.settings.dataDir);
+  }
+
+  override getConnectionString(): ValueOrPromise<string> {
+    return this.settings.dataDir;
+  }
+}
+```
+
+`configure()` builds only the client. Naming `PGliteDriver` in the decorator is what wires the driver and the connector, lazily, on the first `getConnector()` or `beginTransaction()`.
+
+The fourth type parameter pins `getClient()` to `PGlite`. Declare it whenever you reach for the raw client - `waitReady`, `exec()`, `dumpDataDir()`.
+
+> [!NOTE] `getConnectionString()` returns a data directory, not a URL
+> There is no host, port or user to spell. IGNIS never calls this method itself - it exists for your own tooling, so return whatever identifies the database. A directory path for a persistent instance, `memory://` for an ephemeral one.
+
+## The constraints
+
+These matter more than the setup. PGlite is a single embedded Postgres instance, and it has **exactly one session**.
+
+### Transactions serialise
+
+`beginTransaction()` borrows the one session from a 1-slot pool. A second caller waits for the first transaction to commit or roll back. There is no parallelism to lose - one session cannot run two transactions anyway.
+
+A second `BEGIN` on that session would not nest and would not error. It joins the open transaction silently, and the outer `COMMIT` commits the inner writer's rows. The pool is what stops that.
+
+### A write during an open transaction is swallowed by it
+
+This is the trap. Repositories run through the pooled connector that `createConnector()` builds. On one session, that connector is inside whatever transaction happens to be open:
+
+```typescript
+const transaction = await dataSource.beginTransaction();
+
+// Runs INSIDE the transaction above, because there is only one session.
+await this.productRepository.create({ data: { name: 'widget' } });
+
+await transaction.rollback(); // The product is gone.
+```
+
+Measured, not theorised: the row does not survive the rollback.
+
+Pass the transaction explicitly, and the write is deliberate rather than accidental:
+
+```typescript
+await this.productRepository.create({
+  data: { name: 'widget' },
+  options: { transaction },
+});
+```
+
+That is PGlite, not the IGNIS driver. On a server-backed Postgres each caller gets its own connection and the problem does not exist. Under concurrency, route every write through a transaction.
+
+### The acquire timeout
+
+A transaction that never commits holds the one slot forever. Without a bound, every later `acquire()` in the process hangs silently. So the wait is bounded:
+
+| Option | Type | Default | Meaning |
+| :--- | :--- | :--- | :--- |
+| `acquireTimeoutMs` | `number` | `PGliteDriver.DEFAULT_ACQUIRE_TIMEOUT_MS` (30000) | Max ms to wait for the session before rejecting |
+| `maxWaitingClients` | `number` | unlimited | Max queued waiters; over the limit, `acquire()` rejects immediately |
+| `scope` | `string` | `'PGliteDriver'` | Logger scope |
+| `client` | `PGlite` | required | The instance the driver borrows |
+
+The timeout bounds the **wait for the slot**, never the transaction itself. It fires only under contention, so a migration or a bulk seed running alone never trips it. When it does fire you get a named error, not a dead process:
+
+```
+[PGliteDriver][acquire] Could not borrow the single PGlite session
+| [acquire] Acquire timed out after 30000ms.
+| An unreleased transaction still holds it - commit/rollback it, or raise `acquireTimeoutMs`
+```
+
+To change any of these, construct the driver yourself with `useDriver()`. That assigns the driver and builds the connector in one step, and bypasses `@datasource({ driver })`:
+
+```typescript
+override configure(): ValueOrPromise<void> {
+  const client = new PGlite(this.settings.dataDir);
+
+  this.useDriver({
+    driver: new PGliteDriver({ client, acquireTimeoutMs: 120_000 }),
+    schema: this.getSchema(),
+  });
+}
+```
+
+`size` is not an option. One slot **is** the mutual exclusion PGlite lacks, so it is pinned at 1.
+
+## Schema and migrations
+
+drizzle-kit works here - `driver: 'pglite'` means it opens the data directory itself - but that is the catch: PGlite allows one writer on the directory at a time, so `drizzle-kit migrate` cannot reach a database your app has already opened. Generate the SQL offline, and let your own process apply it at boot.
+
+Point `dbCredentials.url` at a folder path where a server config would carry a URL:
+
+```typescript
+// drizzle.config.ts
+import { defineConfig } from 'drizzle-kit';
+
+export default defineConfig({
+  dialect: 'postgresql',
+  driver: 'pglite',
+  schema: './src/models/**/*.model.ts',
+  out: './migrations',
+  dbCredentials: { url: './pgdata' },
+});
+```
+
+```bash
+bun run drizzle-kit generate
+```
+
+Apply them in-process, at boot, before the first repository call:
+
+```typescript
+import { drizzle } from 'drizzle-orm/pglite';
+import { migrate } from 'drizzle-orm/pglite/migrator';
+
+export const applyMigrations = async (opts: { dataSource: EmbeddedDataSource }): Promise<void> => {
+  const client = opts.dataSource.getClient();
+  await client.waitReady;
+
+  await migrate(drizzle({ client }), { migrationsFolder: './migrations' });
+};
+```
+
+`migrate()` wants drizzle's own `PgliteDatabase`, which is narrower than the `getConnector()` return type. Build one over the same client - PGlite has a single session, so both handles talk to the same database.
+
+## Runnable example
+
+`examples/pglite-quickstart/` is this page as an app: a `pgTable` model with `uuid`, `jsonb` and `timestamptz`, a one-line repository, the standard CRUD controller, and a datasource that is the only file aware of PGlite.
+
+```bash
+cd examples/pglite-quickstart
+bun install
+bun run start        # http://localhost:3000/api/notes
+```
+
+## See Also
+
+- [Postgres Drivers & Supabase](./postgres-drivers) - the driver seam, `node-postgres` and `postgres-js`
+- [SQLite](./sqlite) - the other embedded engine, and what it refuses
+- [DataSources](./datasources) - schema auto-discovery and `configure()`
+- [Transactions](./transactions) - commit, rollback and connection safety
+- [Connectors](/references/base/connectors) - the engine-neutral contract

package/content/guides/core-concepts/persistent/postgres-drivers.md

@@ -1,9 +1,10 @@
 # Postgres Drivers & Supabase
 
-IGNIS talks to PostgreSQL through a **driver seam**: `IRelationalDriver` owns connection acquisition and the raw transaction control statements, and everything above it - repositories, transactions, the Casbin adapters - is driver-agnostic. Two drivers ship today:
+IGNIS talks to PostgreSQL through a **driver seam**. `IRelationalDriver` owns connection acquisition and the raw transaction control statements, and everything above it - repositories, transactions, the Casbin adapters - is driver-agnostic. Three drivers ship today:
 
 - **node-postgres** (`pg`) - the default IGNIS has always used
 - **postgres-js** (`postgres`) - required for Supabase's transaction pooler, and a faster option anywhere else
+- **PGlite** (`@electric-sql/pglite`) - Postgres compiled to WebAssembly, running in your own process. It has one session and its own constraints, so it gets [its own page](./pglite)
 
 Supabase is unmodified PostgreSQL, so it is not a separate connector: it varies the **driver**, not the SQL dialect. The `@venizia/ignis/postgres/supabase` submodule adds the two things Supabase deployments actually need - pooler presets and an RLS auth-context helper.
 
@@ -11,8 +12,9 @@ Supabase is unmodified PostgreSQL, so it is not a separate connector: it varies
 > `pg` and `postgres` are both **optional peer dependencies**. The `@venizia/ignis/postgres` module pulls in neither - only the driver class you import and name in `@datasource({ driver })` reaches your bundle. Install the one your app uses:
 >
 > ```bash
-> bun add pg          # node-postgres
-> bun add postgres    # postgres-js (>= 3.4.0)
+> bun add pg                      # node-postgres
+> bun add postgres                # postgres-js (>= 3.4.0)
+> bun add @electric-sql/pglite    # PGlite
 > ```
 
 ## Import Paths
@@ -22,6 +24,7 @@ Supabase is unmodified PostgreSQL, so it is not a separate connector: it varies
 | `@venizia/ignis/postgres` | `BasePostgresDataSource`, `IRelationalDriver`, repository hierarchy | no client library |
 | `@venizia/ignis/postgres/node-postgres` | `NodePostgresDriver` | `pg` |
 | `@venizia/ignis/postgres/postgres-js` | `PostgresJsDriver` | `postgres` |
+| `@venizia/ignis/postgres/pglite` | `PGliteDriver` | `@electric-sql/pglite` |
 | `@venizia/ignis/postgres/supabase` | `PoolerModes`, `buildPostgresJsOptions`, `withAuthContext`, Supabase role re-exports | `drizzle-orm/supabase` |
 
 ## Naming the Driver Class
@@ -42,12 +45,14 @@ export class PostgresDataSource extends BasePostgresDataSource<IDataSourceConfig
 }
 ```
 
-`configure()` only builds `this.client` - the raw `pg.Pool` (or postgres-js `Sql`) your app's connection settings produce. The base class wires the driver **and** the connector lazily, on first call to `getConnector()` or `beginTransaction()`: it reads the class named in `@datasource({ driver })`, instantiates it over `this.client`, and builds the pooled Drizzle connector from that. `getClient()` hands `this.client` back as the raw-client escape hatch. A datasource that sets neither `this.client` nor a driver (via `useDriver()`, below) throws `No driver and no client` on first use.
+`configure()` only builds `this.client` - the raw `pg.Pool` (or postgres-js `Sql`) your app's connection settings produce. The base class wires the driver **and** the connector lazily, on first call to `getConnector()` or `beginTransaction()`. It reads the class named in `@datasource({ driver })`, instantiates it over `this.client`, and builds the pooled Drizzle connector from that.
+
+`getClient()` hands `this.client` back as the raw-client escape hatch. A datasource that sets neither `this.client` nor a driver (via `useDriver()`, below) throws `No driver and no client` on first use.
 
 > [!IMPORTANT] Why a class, not a name
-> A driver-name string cannot carry `pg` or `postgres` into your bundle - it is just text. A dynamic `import('./node-postgres.js')` keyed off that string would defer *execution*, not *packaging*: every bundler statically resolves a literal specifier and packages whatever it points to, so a build that only used node-postgres would still fail with `Could not resolve: "postgres"` the moment postgres-js's import appeared anywhere in the module graph reachable at build time. Naming the class instead makes the driver module a real value reference - the one thing a bundler is forced to keep - which is what lets `pg` and `postgres` stay genuinely optional peers. A bare side-effect import (`import '@venizia/ignis/postgres/node-postgres'`) would not work either: `@venizia/ignis` declares `sideEffects: false`, so a bundler is free to drop an import whose exports go unused.
+> A driver-name string cannot carry `pg` or `postgres` into your bundle - it is just text. A dynamic `import('./node-postgres.js')` keyed off that string would defer *execution*, not *packaging*. Every bundler statically resolves a literal specifier and packages whatever it points to. A build that only used node-postgres would still fail with `Could not resolve: "postgres"`. The failure fires the moment postgres-js's import appears anywhere in the module graph reachable at build time. Naming the class instead makes the driver module a real value reference - the one thing a bundler is forced to keep. That's what lets `pg` and `postgres` stay genuinely optional peers. A bare side-effect import (`import '@venizia/ignis/postgres/node-postgres'`) would not work either. `@venizia/ignis` declares `sideEffects: false`, so a bundler is free to drop an import whose exports go unused.
 >
-> Two tests pin this from different angles: `packages/core/src/__tests__/connectors/postgres/no-eager-driver-import.test.ts` proves no barrel **loads** a driver package in a fresh process (the runtime module graph), and `packages/core/src/__tests__/connectors/postgres/bundle/optional-peers.test.ts` proves no barrel gets a driver package **packaged** by a real bundler.
+> Two tests pin this from different angles. `packages/core-server/src/__tests__/connectors/postgres/no-eager-driver-import.test.ts` proves no barrel **loads** a driver package in a fresh process (the runtime module graph). `packages/core-server/src/__tests__/connectors/postgres/bundle/optional-peers.test.ts` proves no barrel gets a driver package **packaged** by a real bundler.
 
 ## Using postgres-js
 
@@ -84,11 +89,11 @@ new NodePostgresDriver({ client: pool }); // client must expose connect() AND to
 new PostgresJsDriver({ client: sql });    // client must expose reserve() AND unsafe()
 ```
 
-`NodePostgresDriver` rejects a bare `pg.Client` - it exposes `connect()` too, but has no pool accounting and cannot hand out a dedicated connection per transaction. `PostgresJsDriver` rejects a `pg.Pool` the same way. You will not normally construct these yourself: `wireDriverFromMetadata()` does it for you from `this.client`, so this validation fires the first time a datasource wired the wrong client behind the wrong `@datasource({ driver })` class.
+`NodePostgresDriver` rejects a bare `pg.Client` - it exposes `connect()` too, but has no pool accounting and cannot hand out a dedicated connection per transaction. `PostgresJsDriver` rejects a `pg.Pool` the same way. You will not normally construct these yourself: `wireDriverFromMetadata()` does it for you from `this.client`. This validation fires the first time a datasource wired the wrong client behind the wrong `@datasource({ driver })` class.
 
 ## Custom or Third-Party Drivers: `useDriver()`
 
-For a driver IGNIS does not ship, wire it explicitly with `useDriver()` - it assigns the driver **and** builds the pooled connector in one step, so the half-wired state (driver set, connector forgotten) cannot exist:
+For a driver IGNIS does not ship, wire it explicitly with `useDriver()`. It assigns the driver **and** builds the pooled connector in one step, so the half-wired state (driver set, connector forgotten) cannot exist:
 
 ```typescript
 export class PostgresDataSource extends BasePostgresDataSource<IDataSourceConfigs> {
@@ -101,10 +106,10 @@ export class PostgresDataSource extends BasePostgresDataSource<IDataSourceConfig
 }
 ```
 
-`useDriver()` bypasses `@datasource({ driver })` entirely - you never need to name a class in the decorator when you wire the driver yourself in `configure()`.
+`useDriver()` bypasses `@datasource({ driver })` entirely. You never need to name a class in the decorator when you wire the driver yourself in `configure()`.
 
 > [!WARNING] postgres-js cannot destroy a poisoned connection
-> After a failed `COMMIT` or `ROLLBACK`, node-postgres **destroys** the connection instead of pooling it - the session may still hold an open transaction that the next borrower would inherit. postgres-js has no destroy semantics (`ReservedSql.release()` takes no argument), so the connection is returned to the pool anyway. This asymmetry is real and IGNIS does not paper over it; it is pinned by the driver's own tests.
+> After a failed `COMMIT` or `ROLLBACK`, node-postgres **destroys** the connection instead of pooling it. The session may still hold an open transaction that the next borrower would inherit. postgres-js has no destroy semantics (`ReservedSql.release()` takes no argument), so the connection is returned to the pool anyway. This asymmetry is real and IGNIS does not paper over it; it is pinned by the driver's own tests.
 
 ## The Driver Contract
 
@@ -125,9 +130,9 @@ interface IRelationalConnection<Schema> {
 }
 ```
 
-`acquire()` matters for transactions: `BEGIN` and `COMMIT` must land on the same backend, so each explicit transaction gets a dedicated connection (`pool.connect()` for pg, `sql.reserve()` for postgres-js - the reason for the `>= 3.4.0` floor).
+`acquire()` matters for transactions: `BEGIN` and `COMMIT` must land on the same backend. Each explicit transaction therefore gets a dedicated connection (`pool.connect()` for pg, `sql.reserve()` for postgres-js) - that's the reason for the `>= 3.4.0` floor.
 
-The connection is checked out of the pool before Drizzle is constructed on top of it. If that constructor throws - a malformed discovered schema, a drizzle mismatch - both drivers catch the error, release the connection back to the pool first, and rethrow. Without this, every failed `acquire()` would strand a connection, and the pool would exhaust after enough of them.
+The connection is checked out of the pool before Drizzle is constructed on top of it. If that constructor throws - a malformed discovered schema, a drizzle mismatch - both drivers catch the error. They release the connection back to the pool first, and rethrow. Without this, every failed `acquire()` would strand a connection, and the pool would exhaust after enough of them.
 
 `execute()` resolves to the neutral `IStatementResult` (`{ count }` - the same `count` the repository verbs speak). Each driver maps its native result shape at its own boundary; nothing above the seam ever inspects a driver-specific type.
 
@@ -143,7 +148,7 @@ Supabase exposes three ways in, and one of them silently breaks prepared stateme
 | `PoolerModes.SESSION` | 5432 (pooler) | yes | pooled, one backend per client session |
 | `PoolerModes.TRANSACTION` | 6543 | **no** | serverless / many short-lived connections |
 
-The transaction pooler (Supavisor) rebinds the backend per transaction, so a server-side prepared statement created on one backend simply is not there next time. `buildPostgresJsOptions` encodes this so you cannot forget it:
+The transaction pooler (Supavisor) rebinds the backend per transaction, so a server-side prepared statement created on one backend is not there next time. `buildPostgresJsOptions` encodes this so you cannot forget it:
 
 ```typescript
 import { datasource } from '@venizia/ignis';
@@ -191,11 +196,12 @@ try {
 Three properties make this safe under a transaction-mode pooler:
 
 - `claims` is **bound as a query parameter**, never interpolated into SQL text.
-- `role` must be a bare identifier (`/^[a-z_][a-z0-9_]*$/`) because `set local role $1` is not valid SQL - a role taken from a JWT and interpolated unvalidated would be a privilege-escalation vector. Validation runs **before** any statement, so a rejected call leaves the session untouched.
+- `role` must be a bare identifier (`/^[a-z_][a-z0-9_]*$/`) because `set local role $1` is not valid SQL. A role taken from a JWT and interpolated unvalidated would be a privilege-escalation vector.
+- Validation runs **before** any statement, so a rejected call leaves the session untouched.
 - Everything is `SET LOCAL` / `set_config(..., true)` - transaction-scoped. A plain `SET` would leak the caller's identity to the next borrower of the pooled connection, and is deliberately not offered.
 
 The submodule also re-exports Drizzle's Supabase helpers (`anonRole`, `authenticatedRole`, `serviceRole`, `authUid`, `authUsers`, ...) so RLS-aware schema files need one import.
 
 ## Adding a Driver
 
-One file under `src/connectors/postgres/drivers/`, implementing the four verbs above, plus a fake client and a test that runs the shared conformance suite (`run({ driver, buildDriverProbe })` in `src/__tests__/connectors/postgres/drivers/conformance/`). Register a sub-path export and an optional peer dependency; never re-export the driver from the drivers barrel - that is what would make its package load eagerly for everyone.
+One file under `src/connectors/postgres/drivers/`, implementing the four verbs above. Add a fake client and a test that runs the shared conformance suite (`run({ driver, buildDriverProbe })` in `src/__tests__/connectors/postgres/drivers/conformance/`). Register a sub-path export and an optional peer dependency. Never re-export the driver from the drivers barrel - that is what would make its package load eagerly for everyone.

package/content/guides/core-concepts/persistent/search-meilisearch.md

@@ -1,6 +1,6 @@
 # Search & Meilisearch
 
-IGNIS ships a **meilisearch connector** under `@venizia/ignis/meilisearch`. It shares the entire search paradigm with the Typesense connector - the same `@model`/`@repository`/`@datasource` decorators, the same `defineSearchCollection` field DSL, the same repository tiers and controller factory - all of which live in the engine-neutral `@venizia/ignis/search` module.
+IGNIS ships a **meilisearch connector** under `@venizia/ignis/meilisearch`. It shares the entire search paradigm with the Typesense connector: the same `@model`/`@repository`/`@datasource` decorators and the same `defineSearchCollection` field DSL. It also shares the same repository tiers and controller factory. All of that lives in the engine-neutral `@venizia/ignis/search` module.
 
 What it does **not** share is the pretence that the two engines are the same. Where Meilisearch differs from Typesense, IGNIS surfaces the difference rather than papering over it.
 
@@ -53,7 +53,7 @@ Meilisearch is **schemaless**: it has no field schema at all. A collection there
 | `synonyms` | a flat `synonyms` dictionary |
 | `engineOverrides.meilisearch` | merged last onto settings |
 
-The `searchable` and `filterable` flags are **load-bearing here** and are silently dropped by the Typesense compiler, which indexes every field by default. If no field declares `searchable`, IGNIS leaves `searchableAttributes` at Meilisearch's own `['*']` default rather than emitting an empty array, which would disable search entirely.
+The `searchable` and `filterable` flags are **load-bearing here** and are silently dropped by the Typesense compiler, which indexes every field by default. If no field declares `searchable`, IGNIS leaves `searchableAttributes` at Meilisearch's own `['*']` default. Emitting an empty array instead would disable search entirely.
 
 ## The DataSource
 
@@ -93,7 +93,7 @@ await repository.create({ data: article });
 // The document is retrievable here. No sleep, no retry loop.
 ```
 
-The cost is real and worth knowing: each write polls until its task completes. The client SDK's own `waitForTask` defaults to a 5-second timeout, which is far too short for a bulk import, so IGNIS never relies on it - configure `taskTimeoutMs` instead. A task that fails raises the standard sanitized dependency error; one that never terminates raises a `core.search_engine.task_timeout`.
+The cost is real and worth knowing: each write polls until its task completes. The client SDK's own `waitForTask` defaults to a 5-second timeout, which is far too short for a bulk import. IGNIS never relies on it - configure `taskTimeoutMs` instead. A task that fails raises the standard sanitized dependency error; one that never terminates raises a `core.search_engine.task_timeout`.
 
 If you want fire-and-forget writes, reach the raw client:
 
@@ -108,7 +108,7 @@ Meilisearch's search route reports `estimatedTotalHits`, and its exhaustive `tot
 
 IGNIS never counts through the search route. `count()` calls `POST /documents/fetch` with `limit: 0` and reads the exact `total`, which the engine's own documentation states is unaffected by `maxTotalHits`. A filtered count over 50,000 matching documents returns 50,000.
 
-`ISearchResult.isFoundExact` reports the truth for the **search** route: always `true` on Typesense, and on Meilisearch `true` only in the exhaustive page mode. It travels all the way out through the generated REST response, so an API consumer paginating your endpoint can tell an estimate from an exhaustive count.
+`ISearchResult.isFoundExact` reports the truth for the **search** route: always `true` on Typesense, and on Meilisearch `true` only in the exhaustive page mode. It travels all the way out through the generated REST response. An API consumer paginating your endpoint can tell an estimate from an exhaustive count.
 
 ## Capability differences are compile-time, not runtime
 
@@ -141,25 +141,35 @@ class PortableRepository extends DefaultSearchRepository<TDocument> {
 
 ## Behaviours to know before you commit
 
-**`create()` rejects duplicates, but the check is not atomic.** Meilisearch's `addDocuments` is add-or-replace; it has no conditional insert. To honour the neutral contract (Typesense's `create()` returns 409 on a duplicate id), IGNIS reads the id first and throws `409 core.search_engine.already_exists` if it exists. Two concurrent creates of the same id can both pass that check, and the second write wins. If you want last-write-wins, call `upsert()` and say so.
+**`create()` rejects duplicates, but the check is not atomic.** Meilisearch's `addDocuments` is add-or-replace; it has no conditional insert. The neutral contract says `create()` returns 409 on a duplicate id, matching Typesense.
+
+To honour it, IGNIS reads the id first and throws `409 core.search_engine.already_exists` if it exists. Two concurrent creates of the same id can both pass that check, and the second write wins. If you want last-write-wins, call `upsert()` and say so.
 
 **`updateById` on a missing id throws `404`, it does not upsert.** Meilisearch's `updateDocuments` is add-or-update, so a missing id would silently fabricate a record. IGNIS checks existence before any write and throws `404 core.search_engine.not_found` instead - matching Typesense and the neutral contract. (This is the deliberate search-family divergence from the PostgreSQL connector, where a missing-id `updateById` is a silent `{ count: 0 }`.)
 
-**`updateBy` is emulated and is not atomic.** Meilisearch has no update-by-filter endpoint. IGNIS pages primary keys out of `documents/fetch`, then issues merge-`PUT` batches. A concurrent write to a matched document may be overwritten. The experimental `documents/edit` route would do this server-side, but it is gated behind a feature flag, is documented as breaking between minor versions, and has an open correctness bug - so IGNIS does not use it.
+**`updateBy` is emulated and is not atomic.** Meilisearch has no update-by-filter endpoint. IGNIS pages primary keys out of `documents/fetch`, then issues merge-`PUT` batches. A concurrent write to a matched document may be overwritten.
+
+The experimental `documents/edit` route would do this server-side, but it is gated behind a feature flag and documented as breaking between minor versions. It also has an open correctness bug, so IGNIS does not use it.
+
+**`import`/`createAll` is batch-atomic.** Documents are added in batches, each batch's task awaited before the next starts. A batch either lands whole or throws, so `count.fail` is structurally always `0`.
 
-**`import`/`createAll` is batch-atomic.** Documents are added in batches, each batch's task awaited before the next starts. A batch either lands whole or throws, so `count.fail` is structurally always `0`. When a batch fails, the batches after the failure point did not land and the thrown error's `details` carry `{ totalCount, processedCount }` so a caller can resume from `processedCount` rather than replaying the whole import.
+When a batch fails, the batches after the failure point did not land. The thrown error's `details` carry `{ totalCount, processedCount }`, so a caller can resume from `processedCount` rather than replaying the whole import.
 
-**Meilisearch error classification reads the real SDK error shape.** A thrown `MeilisearchApiError` carries its body under `error.cause.code` and its HTTP status under `error.response.status`, not top-level `code`/`httpStatus`. Reading only the flat shape misclassifies a legitimate 404 (for example the existence probe inside `create()`) as an unrelated 503 dependency failure; the classifier checks both the flat shape (task-error responses) and the nested `cause`/`response` shape (thrown SDK errors).
+**Meilisearch error classification reads the real SDK error shape.** A thrown `MeilisearchApiError` carries its body under `error.cause.code` and its HTTP status under `error.response.status`, not top-level `code`/`httpStatus`. Reading only the flat shape misclassifies a legitimate 404 (for example the existence probe inside `create()`) as an unrelated 503 dependency failure. The classifier checks both the flat shape (task-error responses) and the nested `cause`/`response` shape (thrown SDK errors).
 
-**`createCollection`/`ensureCollection` are idempotent.** An `index_already_exists` failure is tolerated and logged rather than thrown, so boot-time provisioning against an already-provisioned collection (a restart, a second app instance) succeeds instead of crashing.
+**`createCollection`/`ensureCollection` are idempotent.** An `index_already_exists` failure is tolerated and logged rather than thrown. Boot-time provisioning against an already-provisioned collection (a restart, a second app instance) succeeds instead of crashing.
 
-**`hiddenProperties` is supported on Meilisearch via JS-side stripping, not engine-side exclusion.** Meilisearch has no per-query field-exclusion param (only the index-level `displayedAttributes` setting), so the dialect does not attempt to translate `hiddenFields` - it deliberately passes them through untranslated. The guarantee is upheld one layer up: `SearchBaseRepository` strips hidden fields from every document `find()`/`findOne()`/`search()` returns before it reaches the caller, so a model with `hiddenProperties` works identically to Typesense from the caller's point of view - no throw, no leak.
+**`hiddenProperties` is supported on Meilisearch via JS-side stripping, not engine-side exclusion.** Meilisearch has no per-query field-exclusion param (only the index-level `displayedAttributes` setting), so the dialect does not attempt to translate `hiddenFields`. It deliberately passes them through untranslated.
+
+The guarantee is upheld one layer up: `SearchBaseRepository` strips hidden fields from every document `find()`/`findOne()`/`search()` returns before it reaches the caller. A model with `hiddenProperties` works identically to Typesense from the caller's point of view - no throw, no leak.
 
 **A geopoint field must be named `_geo`.** Meilisearch supports exactly one geo field, shaped `{ lat, lng }`, under that reserved name. The compiler throws on any other name, and on a second geo field.
 
 **Vector distance is cosine only.** `field.vector(..., { distance: 'l2' })` throws.
 
-**Engine-specific knobs never reach the neutral schema.** The neutral search input carries only fields every engine supports; Typesense-only tuning (`num_typos`, `pinned_hits`, `preset`, ...) travels through `engineParams` with wire names and is passed verbatim to the engine - so sending Typesense knobs to a Meilisearch datasource is a caller error, and the dialect still raises a named error for known-foreign knobs arriving via untyped input. Use `engineParams` (or `mode: 'raw'`) for Meilisearch-native tuning such as `rankingScoreThreshold`.
+**Engine-specific knobs never reach the neutral schema.** The neutral search input carries only fields every engine supports. Typesense-only tuning (`num_typos`, `pinned_hits`, `preset`, ...) travels through `engineParams` with wire names and is passed verbatim to the engine. Sending it to a Meilisearch datasource is a caller error.
+
+The dialect still raises a named error for known-foreign knobs arriving via untyped input. Use `engineParams` (or `mode: 'raw'`) for Meilisearch-native tuning such as `rankingScoreThreshold`.
 
 **`multiSearch` batches but does not merge.** `union: true` throws. Meilisearch merges results through its `federation` option, which this connector does not model, so `getCapabilities()` honestly reports `union: false`.
 
@@ -169,7 +179,7 @@ class PortableRepository extends DefaultSearchRepository<TDocument> {
 
 Vector fields compile to `embedders`, and `mode: 'semantic'` / `mode: 'hybrid'` translate to Meilisearch's `hybrid: { semanticRatio, embedder }` plus an optional `vector`. The neutral `alpha` maps to `semanticRatio`; `mode: 'semantic'` pins it to `1.0`, and an omitted `alpha` on `hybrid` defaults to `0.5`.
 
-This path is compiled and translated but is **not exercised end to end** by the framework's test suite, and Meilisearch has moved its vector store in and out of `/experimental-features` across server versions. Verify against your target server version before depending on it.
+This path is compiled and translated but is **not exercised end to end** by the framework's test suite. Meilisearch has also moved its vector store in and out of `/experimental-features` across server versions. Verify against your target server version before depending on it.
 
 ## Adding another search engine
 

package/content/guides/core-concepts/persistent/search-typesense.md

@@ -1,9 +1,9 @@
 # Search & Typesense
 
-IGNIS ships a **typesense connector** under `@venizia/ignis/typesense` for full-text and faceted search. It plugs into the same `@model`/`@repository`/`@datasource` decorators as the PostgreSQL connector, but documents replace Drizzle tables and the query surface is intentionally narrower - search engines are not relational databases.
+IGNIS ships a **typesense connector** under `@venizia/ignis/typesense` for full-text and faceted search. It plugs into the same `@model`/`@repository`/`@datasource` decorators as the PostgreSQL connector. Documents replace Drizzle tables, and the query surface is intentionally narrower - search engines are not relational databases.
 
 > [!IMPORTANT] Subpath-only import
-> `typesense` is an **optional peer dependency** - the typesense connector is not re-exported from the `@venizia/ignis` root barrel (unlike `postgres`), so apps that don't use search never pull in the `typesense` client. Always import from `@venizia/ignis/typesense`:
+> `typesense` is an **optional peer dependency**. Unlike `postgres`, the typesense connector is not re-exported from the `@venizia/ignis` root barrel, so apps that don't use search never pull in the `typesense` client. Always import from `@venizia/ignis/typesense`:
 >
 > ```typescript
 > import {
@@ -77,7 +77,7 @@ The same `@model` settings you use with Drizzle entities - `hiddenProperties`, `
 | `field.geopoint(name, flags?)` | `geopoint` (`[number, number]`) |                                                                                                                                                                                       |
 | `field.vector(name, opts)`     | `float[]`                       | Embedding vector for semantic/hybrid search. Its `opts` carry `dimensions`/`distance`/`embed` rather than the shared flags - see [Vector Fields](#vector-fields-for-semantic-search). |
 
-Each `flags` object may set `searchable`, `filterable`, `facet`, `sortable`, `optional` (all `boolean`). Note: `searchable`/`filterable` have no direct Typesense wire equivalent (Typesense indexes every field by default) and are dropped at compile time - only `facet`, `optional`, and `sortable` (mapped to Typesense's `sort`) actually reach the compiled collection schema. They're still worth setting for documentation/intent and for future engines that do distinguish them.
+Each `flags` object may set `searchable`, `filterable`, `facet`, `sortable`, `optional` (all `boolean`). Note: `searchable`/`filterable` have no direct Typesense wire equivalent - Typesense indexes every field by default - so they're dropped at compile time. Only `facet`, `optional`, and `sortable` (mapped to Typesense's `sort`) actually reach the compiled collection schema. They're still worth setting for documentation/intent and for future engines that do distinguish them.
 
 `defineSearchCollection` validates at call time: throws on an empty `name`, empty `fields`, duplicate field names, a non-`string` `id` field, or an unknown `defaultSort` field reference.
 
@@ -128,7 +128,7 @@ field.vector('embedding', {
 });
 ```
 
-The `model` config is camelCase and maps to Typesense's snake_case `model_config` at compile time (`name` becomes `model_name`, `apiKey` becomes `api_key`, `accessToken` becomes `access_token`, and so on); any provider field not modeled is passed through unchanged. Never hardcode `apiKey` into a committed schema - source it from an environment variable.
+The `model` config is camelCase and maps to Typesense's snake_case `model_config` at compile time (`name` becomes `model_name`, `apiKey` becomes `api_key`, `accessToken` becomes `access_token`, and so on). Any provider field not modeled is passed through unchanged. Never hardcode `apiKey` into a committed schema - source it from an environment variable.
 
 **Client-provided vectors** - you compute the embedding yourself and send it with each document. Declare `dimensions` and a distance metric instead of `embed`:
 
@@ -160,7 +160,7 @@ static override schema = defineSearchCollection({
 });
 ```
 
-Declarative `synonyms` are provisioned as one **synonym set** per collection (named `<collection>_synonyms`) and linked to it - matching Typesense v30+'s global synonym-sets model (the pre-v30 per-collection synonyms API was removed). For runtime management outside the declarative schema, the connector exposes the synonym-set verbs through the raw client escape hatch:
+Declarative `synonyms` are provisioned as one **synonym set** per collection (named `<collection>_synonyms`) and linked to it. That matches Typesense v30+'s global synonym-sets model - the pre-v30 per-collection synonyms API was removed. For runtime management outside the declarative schema, the connector exposes the synonym-set verbs through the raw client escape hatch:
 
 ```typescript
 const connector = repository.dataSource.getConnector();
@@ -241,26 +241,38 @@ export class ArticleRepository extends DefaultSearchRepository<TArticleDocument>
 }
 ```
 
-`find()`/`findOne()`/`findById()`/`count()`/`existsWith()` accept the same `TFilter`/`TWhere` shape as PostgreSQL repositories - the `TypesenseQueryDialect` translates `where` into Typesense's `filter_by` syntax, `order` into `sort_by` (max 3 fields - a Typesense limit), `limit`/`skip` into `per_page`/`page`, and `fields` into `include_fields`. `filter.include` is **not supported** and throws - there is no relation model for documents.
+`find()`/`findOne()`/`findById()`/`count()`/`existsWith()` accept the same `TFilter`/`TWhere` shape as PostgreSQL repositories. The `TypesenseQueryDialect` translates `where` into Typesense's `filter_by` syntax, `order` into `sort_by` (max 3 fields - a Typesense limit), `limit`/`skip` into `per_page`/`page`, and `fields` into `include_fields`. `filter.include` is **not supported** and throws - there is no relation model for documents.
+
+Search engines index asynchronously, so a document can be missing right after a write. `find()`/`findOne()`/`findById()` accept the same `options.retry` as PostgreSQL - re-read until the document shows up:
+
+```typescript
+const article = await articleRepository.findById({
+  id,
+  options: { retry: { maxAttempts: 4 } },
+});
+```
+
+Same options, same rules as PostgreSQL - see [Read Retry](/references/base/repositories/advanced#read-retry-replica-lag). The only difference is moot: retry skips inside a transaction, and search has no transactions to begin with.
 
 ### Envelope differences vs. PostgreSQL
 
 |                                            | PostgreSQL repositories                             | Search repositories                                                                                                                            |
 | ------------------------------------------ | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
 | Range queries                              | Extra `COUNT(*)` query for `shouldQueryRange: true` | Single search call already returns `found` - no second query needed                                                                            |
-| `updateAll`/`deleteAll` with empty `where` | Requires `force: true`                              | `updateAll` **refuses** an unfiltered bulk update outright (throws, no override); `deleteAll` with no effective filter (no `where` and no `@model defaultFilter`) also throws unless `options.force: true` is passed - only then does it truncate the whole collection |
+| `updateAll`/`deleteAll` with empty `where` | Requires `force: true`                              | `updateAll` **refuses** an unfiltered bulk update outright (throws, no override). `deleteAll` with no effective filter (no `where` and no `@model defaultFilter`) also throws. Passing `options.force: true` truncates the whole collection instead |
 | Returning updated/deleted rows             | Native SQL `RETURNING`                              | No `RETURNING` equivalent - `updateAll`/`deleteAll` are **count-only**: `data` is always `null` and `shouldReturn` is rejected at the type level (no hidden engine read is bolted on). Read the affected documents explicitly before the write when you need them |
 | `createAll`                                | Native bulk insert, returns each row                | Delegates to Typesense's bulk import; "created" rows are the input rows whose per-row response didn't report `success: false`                  |
 
 ### Write error semantics (shared by both search engines)
 
-- **`create()` with a duplicate id throws `409` (`normalized.code: 'core.search_engine.already_exists'`)** on both Typesense and Meilisearch - a duplicate is a conflict, never a silent overwrite. If you want last-write-wins, call `upsert()` explicitly. (On Meilisearch the pre-check is not atomic - see the [Meilisearch guide](./search-meilisearch); use `upsert()` when concurrent same-id creates are possible.)
+- **`create()` with a duplicate id throws `409`** (`normalized.code: 'core.search_engine.already_exists'`) on both Typesense and Meilisearch. A duplicate is a conflict, never a silent overwrite - call `upsert()` explicitly for last-write-wins.
+- On Meilisearch, the duplicate pre-check is not atomic, so two concurrent creates of the same id can both pass it. See the [Meilisearch guide](./search-meilisearch) and use `upsert()` when that's possible.
 - **`updateById()` against a missing id throws `404` (`normalized.code: 'core.search_engine.not_found'`)** on both engines. This is the deliberate divergence from the PostgreSQL connector, where a missing-id `updateById` is a silent `{ count: 0 }`.
 - **`deleteById()` against a missing id is silent** (`{ count: 0, data: null }`), matching the relational connectors.
 
 ## Searching with `search({ mode })`
 
-Beyond the `find()` tier (filter-only reads that return documents), `search()` is the search-engine entry point. It is one method whose shape is selected by `mode`, so TypeScript narrows the options to just that mode's fields - you never juggle every parameter at once. `mode` defaults to `keyword`.
+Beyond the `find()` tier (filter-only reads that return documents), `search()` is the search-engine entry point. It is one method whose shape is selected by `mode`, so TypeScript narrows the options to just that mode's fields. You never juggle every parameter at once. `mode` defaults to `keyword`.
 
 The `keyword`/`semantic`/`hybrid` modes reuse the same filter translation as `find()` (`@model defaultFilter`, `hiddenProperties`, `where`/`order`/`limit`), then layer the search term or vector on top. The `raw` mode is a full passthrough with no translation.
 
@@ -299,7 +311,7 @@ await repository.search({
 ```
 
 > [!NOTE]
-> `semantic` and `hybrid` default `prefix=false`: prefix matching is meaningless for vector search, and remote embedders (OpenAI/Google/...) reject it (`Prefix search is not supported for remote embedders`). Pass `engineParams: { prefix: true }` to override.
+> `semantic` and `hybrid` default `prefix=false`: prefix matching is meaningless for vector search. Remote embedders (OpenAI/Google/...) reject it too (`Prefix search is not supported for remote embedders`). Pass `engineParams: { prefix: true }` to override.
 
 **`raw`** - native Typesense params, no `TFilter`/`defaultFilter`/`hiddenProperties` translation. Use it for any engine feature the modes above do not model:
 
@@ -313,9 +325,9 @@ await repository.search({
 > [!NOTE]
 > `raw` skips `@model defaultFilter`, so it can surface documents the `find()`/`keyword` tiers would hide (for example non-`published` articles). Apply any tenant or visibility filtering explicitly in `params.filter_by` when exposing raw search over HTTP.
 
-All non-`raw` modes accept the same optional camelCase tuning fields, mapped to Typesense's snake_case at the dialect boundary: faceting (`facetBy`, `facetQuery`, `maxFacetValues`), highlighting (`highlightFields`, `highlightFullFields`, `highlightStartTag`/`highlightEndTag`, `snippetThreshold`), grouping (`groupBy`, `groupLimit`, `groupMissingValues`), and `queryByWeights`. These are the ENGINE-NEUTRAL fields - every search engine supports them.
+All non-`raw` modes accept the same optional camelCase tuning fields, mapped to Typesense's snake_case at the dialect boundary. That covers faceting (`facetBy`, `facetQuery`, `maxFacetValues`), highlighting (`highlightFields`, `highlightFullFields`, `highlightStartTag`/`highlightEndTag`, `snippetThreshold`), grouping (`groupBy`, `groupLimit`, `groupMissingValues`), and `queryByWeights`. These are the ENGINE-NEUTRAL fields - every search engine supports them.
 
-Typesense-specific tuning (`num_typos`, `prefix`, `infix`, `use_cache`, `cache_ttl`, `exhaustive_search`, `pinned_hits`, `hidden_hits`, `prioritize_exact_match`, `drop_tokens_threshold`, `preset`) goes through `engineParams`, passed verbatim to the engine with WIRE names - the neutral input schema no longer carries knobs only one engine understands:
+Typesense-specific tuning (`num_typos`, `prefix`, `infix`, `use_cache`, `cache_ttl`, `exhaustive_search`, `pinned_hits`, `hidden_hits`, `prioritize_exact_match`, `drop_tokens_threshold`, `preset`) goes through `engineParams`, passed verbatim to the engine with WIRE names. The neutral input schema no longer carries knobs only one engine understands:
 
 ```typescript
 await repository.search({
@@ -381,7 +393,7 @@ await repository.dataSource.multiSearch({
 Both `searches` entries and `commonParams` are camelCase (`filterBy`, `queryBy`, `perPage`); the datasource maps them to Typesense's snake_case wire format the same way single-collection `search()` does. For native snake_case access, `getConnector().multiSearch(...)` takes the engine's own params.
 
 > [!NOTE]
-> `multiSearch` injects each collection's `@model hiddenProperties` into that entry's `excludeFields` automatically - hidden fields never leak on the multi-search route, just as they don't on single-collection `search()`. An entry naming a collection IGNIS did not discover (not a bound `@repository` model) passes through untouched: the **caller owns exclusion** for unknown collections. The raw `getConnector().multiSearch(...)` escape hatch performs no injection at all.
+> `multiSearch` injects each collection's `@model hiddenProperties` into that entry's `excludeFields` automatically. Hidden fields never leak on the multi-search route, just as they don't on single-collection `search()`. An entry naming a collection IGNIS did not discover (not a bound `@repository` model) passes through untouched: the **caller owns exclusion** for unknown collections. The raw `getConnector().multiSearch(...)` escape hatch performs no injection at all.
 
 ## Search Controller Factory
 
@@ -403,7 +415,7 @@ const _SearchController = SearchControllerFactory.defineSearchController({
 export const ArticleSearchController = _SearchController;
 ```
 
-It registers `POST /search` (request body is the mode-discriminated schema, so validation and OpenAPI come for free and the handler dispatches to `repository.search`) and `POST /multi-search` (dispatches to `dataSource.multiSearch`). For anything the factory does not cover, write a custom `BaseRestController` calling `repository.search()` or `getClient()` directly.
+It registers `POST /search` (request body is the mode-discriminated schema, so validation and OpenAPI come for free, and the handler dispatches to `repository.search`). It also registers `POST /multi-search`, which dispatches to `dataSource.multiSearch`. For anything the factory does not cover, write a custom `BaseRestController` calling `repository.search()` or `getClient()` directly.
 
 ## Transactions and Locking