@voltro/cli 0.22.0 → 0.23.0

package/dist/startEntry.js

@@ -1,3 +1,3 @@
-import { X as e } from "./inspectMetrics-4AVPn6IS.js";
-import { t } from "./start-BjGUIIvj.js";
+import { Z as e } from "./inspectMetrics-dcC7gnxu.js";
+import { t } from "./start-C_4VUDT8.js";
 export { e as loadDotEnv, t as runStartCommand };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@voltro/cli",
-  "version": "0.22.0",
+  "version": "0.23.0",
   "description": "The `voltro` CLI — dev server, codegen, migrations, project scaffolding, agent-docs seeding, and production serve.",
   "keywords": [
     "voltro",
@@ -62,22 +62,22 @@
     "@effect/platform-node": "^0.108.0",
     "@effect/sql": "^0.52.0",
     "@effect/workflow": "^0.19.0",
-    "@voltro/ai": "0.22.0",
-    "@voltro/cache": "0.22.0",
-    "@voltro/data-transfer": "0.22.0",
-    "@voltro/database": "0.22.0",
-    "@voltro/env": "0.22.0",
-    "@voltro/kv": "0.22.0",
-    "@voltro/logger": "0.22.0",
-    "@voltro/plugin-auth": "0.22.0",
-    "@voltro/plugin-broadcast": "0.22.0",
-    "@voltro/plugin-mail": "0.22.0",
-    "@voltro/plugin-storage": "0.22.0",
-    "@voltro/plugin-webhooks": "0.22.0",
-    "@voltro/protocol": "0.22.0",
-    "@voltro/runtime": "0.22.0",
-    "@voltro/serverless": "0.22.0",
-    "@voltro/workflow": "0.22.0",
+    "@voltro/ai": "0.23.0",
+    "@voltro/cache": "0.23.0",
+    "@voltro/data-transfer": "0.23.0",
+    "@voltro/database": "0.23.0",
+    "@voltro/env": "0.23.0",
+    "@voltro/kv": "0.23.0",
+    "@voltro/logger": "0.23.0",
+    "@voltro/plugin-auth": "0.23.0",
+    "@voltro/plugin-broadcast": "0.23.0",
+    "@voltro/plugin-mail": "0.23.0",
+    "@voltro/plugin-storage": "0.23.0",
+    "@voltro/plugin-webhooks": "0.23.0",
+    "@voltro/protocol": "0.23.0",
+    "@voltro/runtime": "0.23.0",
+    "@voltro/serverless": "0.23.0",
+    "@voltro/workflow": "0.23.0",
     "chokidar": "^5.0.0",
     "ioredis": "^5.11.1",
     "tinyglobby": "^0.2.17",

package/templates/AGENTS.md

@@ -595,7 +595,7 @@ each plugin's own README.
 
 | Topic | Open | Summary |
 |---|---|---|
-| **What's new in 0.22.0** | `node_modules/@voltro/cli/templates/agent-docs/whats-new.md` | Everything that changed in this version. Read it before hand-rolling something the framework may now ship. |
+| **What's new in 0.23.0** | `node_modules/@voltro/cli/templates/agent-docs/whats-new.md` | Everything that changed in this version. Read it before hand-rolling something the framework may now ship. |
 | AI | `node_modules/@voltro/cli/templates/agent-docs/ai.md` | How Voltro treats AI — agents, tools, streaming, RAG — all primitives over the same WebSocket as the rest of the framework. |
 | Authentication | `node_modules/@voltro/cli/templates/agent-docs/authentication.md` | How @voltro/plugin-auth wires password + session-cookie auth across api + web, plus the pluggable identity-strategy protocol. |
 | Caching | `node_modules/@voltro/cli/templates/agent-docs/caching.md` | Voltro's caching layer (@voltro/cache) — an always-on memory default, swappable Redis-compatible backends, a low-level wrap primitive, and automatic query-result invalidation. |

package/templates/agent-docs/_index.md

@@ -9,7 +9,7 @@ each plugin's own README.
 
 | Topic | Open | Summary |
 |---|---|---|
-| **What's new in 0.22.0** | `node_modules/@voltro/cli/templates/agent-docs/whats-new.md` | Everything that changed in this version. Read it before hand-rolling something the framework may now ship. |
+| **What's new in 0.23.0** | `node_modules/@voltro/cli/templates/agent-docs/whats-new.md` | Everything that changed in this version. Read it before hand-rolling something the framework may now ship. |
 | AI | `node_modules/@voltro/cli/templates/agent-docs/ai.md` | How Voltro treats AI — agents, tools, streaming, RAG — all primitives over the same WebSocket as the rest of the framework. |
 | Authentication | `node_modules/@voltro/cli/templates/agent-docs/authentication.md` | How @voltro/plugin-auth wires password + session-cookie auth across api + web, plus the pluggable identity-strategy protocol. |
 | Caching | `node_modules/@voltro/cli/templates/agent-docs/caching.md` | Voltro's caching layer (@voltro/cache) — an always-on memory default, swappable Redis-compatible backends, a low-level wrap primitive, and automatic query-result invalidation. |

package/templates/agent-docs/_manifest.json

@@ -89,7 +89,7 @@
       "group": "database.migrations",
       "description": "Voltro's planner-based migration system — diff your declared schema against the live DB, classify each change, refuse-to-apply anything risky without explicit intent. Dev auto-applies, prod refuses.",
       "path": "agent-docs/database/migrations.md",
-      "files": 16
+      "files": 17
     },
     {
       "id": "database/misc",

package/templates/agent-docs/caching.md

@@ -286,12 +286,13 @@ The matching `.<primitive>.server.ts` is **unchanged** — caching is a descript
 
 ## `scope` is required — and it's a security decision
 
-`scope` has **no default**, because guessing wrong leaks one user's rows to another. The rubric is one question:
+`scope` has **no default**, because guessing wrong leaks one user's rows to another. The rubric is one question, with **three** answers:
 
-> **Does the resolved query depend on the caller?**
+> **Does the resolved query depend on the caller — and on what about them?**
 
-- **Yes** — tenant-filtered, `where authorId = me`, anything row-scoped → **`scope: 'subject'`**. The cache key includes the caller's subject id, so two subjects can never share an entry.
-- **No** — the same rows for everyone (reference / lookup data) → **`scope: 'global'`**. One entry shared across all callers.
+- **On the PERSON** — `where authorId = me`, anything row-scoped → **`scope: 'subject'`**. The cache key includes the caller's subject id, so two subjects can never share an entry.
+- **On their ORG only** — an org-wide figure every colleague sees identically → **`scope: 'tenant'`**. One entry per `tenantId`, never shared across orgs.
+- **On neither** — the same rows for everyone (reference / lookup data) → **`scope: 'global'`**. One entry shared across all callers.
 
 ```ts
 // reference data — identical for everyone → global
@@ -302,9 +303,24 @@ export const listCountries = defineQuery({
   output: Country,
   cache:  { ttl: '1h', scope: 'global' },
 })
+
+// an org-wide statistic — same for all 18 colleagues, never across orgs
+export const last12Months = defineQuery({
+  name:   'globalStatistics.last12Months',
+  source: ['invoices', 'employees'],
+  input:  Schema.Struct({}),
+  output: Stats,
+  cache:  { ttl: '5m', scope: 'tenant' },
+})
 ```
 
-**Never put `scope: 'global'` on a subject-filtered query.** Tenant tables are auto-scoped per subject by the runtime, so a `global` cache over one would serve tenant A's rows to tenant B. When in doubt, use `subject`.
+`'tenant'` exists because the other two were the only options and neither fit an org-wide figure: `'subject'` recomputes it per person — eighteen identical computations of the same nine-table statistic for an eighteen-person org — and `'global'` shares one entry across tenant boundaries, which for data derived from `subject.tenantId` is not a cache but a leak.
+
+A caller with no `tenantId` (an anonymous or system subject) **bypasses** a `'tenant'` cache rather than sharing a null-keyed entry.
+
+**Never put `scope: 'global'` on a subject- or tenant-filtered query.** Tenant tables are auto-scoped by the runtime, so a `global` cache over one would serve tenant A's rows to tenant B. **The boot audit checks this**: a `'global'` scope over a `tenant()`-scoped table is reported by `voltro dev` and refused under `VOLTRO_SERVER_ONLY=strict`. It stays silent for `'global'` on reference data — the case the option exists for — and for a query with no declared `source`, where it has nothing to reason about.
+
+**`scope: 'tenant'` is not a replacement for modelling.** For a rollup, an aggregate with `tenantId` as an indexed column puts the tenant boundary in the *data* rather than in a cache key, which is better. `'tenant'` is for the other case: a query that must be FRESH and is merely expensive, where an aggregate's refresh interval is the wrong instrument.
 
 ## How auto-invalidation works
 

package/templates/agent-docs/cli.md

@@ -1069,6 +1069,21 @@ source counts as a guard, so `requireTeamAccess()` is recognised without any
 configuration. Without that the scan would report every call site of your own
 guards, which is the failure mode that makes a check ignorable.
 
+It reads your **whole source tree** for those names, not just the
+convention-named files — guards live in `lib/access.ts`, not in `*.mutation.ts`.
+The line above the counts tells you what it found, and it is worth reading before
+you trust the numbers:
+
+```txt
+  guard vocabulary: 17 from your source (requireTeamAccess, assertInquiryAccess, …)
+```
+
+If it instead says `framework names only — no exported require*/assert* found in
+this app` while you know you export some, the counts below it are not meaningful:
+every call site of your own guards is being reported as unguarded. Check that
+they are `export`ed and that the name starts with `require` / `assert` followed
+by a capital.
+
 **An inline ownership check is informational.** `row.userId !== subject.id → new
 AccessDeniedError({})` is correct code — it is listed so you can see where the
 rule lives in a handler rather than on a descriptor, and it never fails the run.
@@ -2606,6 +2621,35 @@ voltro update --codemods-only --from 0.5.0 --to 0.6.0
 
 Every `@voltro/*` entry in `dependencies` and `devDependencies` — in every workspace member, see above — with the range style preserved (`^0.3.0` stays caret, `~0.3.0` stays tilde) unless you pass `--exact`. Non-registry specs (`workspace:*`, `catalog:`, `link:`, …) are left untouched — they're already resolved by your monorepo or catalog.
 
+### And the peer dependencies the framework requires
+
+`@effect/*` are **peer** dependencies, so your app declares them directly. When a
+release moves its peer range, bumping only `@voltro/*` leaves you installed
+against the old ones:
+
+```txt
+Aligning peer dependencies the framework requires:
+  @effect/rpc       ^0.75.1 → ^0.76.0   (apps/api/package.json)
+  @effect/platform  ^0.96.2 → ^0.97.0   (apps/api/package.json)
+```
+
+`update` reads those requirements off the freshly installed `@voltro/*` packages
+and re-installs if anything moved. Without it your package manager only *warns*,
+and the app compiles and boots on a graph the framework was never tested against
+— which is the failure mode with no symptom until there is one.
+
+It is deliberately conservative:
+
+- **Only peers you already declare.** One resolved transitively is not `update`'s
+  to add.
+- **Only when your range is genuinely lower.** Pinned ahead, or pinned exactly at
+  the floor (`0.76.0` vs `^0.76.0`), is left alone — that is a choice.
+- **Only ranges it can judge** (`^`, `~`, `>=`, exact). A union (`^1 || ^2`), a
+  bounded range, `workspace:` / `catalog:` — untouched.
+
+If two framework packages disagree about one peer, it says so and changes
+nothing: that is our bug, not yours to absorb silently.
+
 ## When the install cannot run on this host
 
 Some projects install in a container with their own store, from an offline

package/templates/agent-docs/data.md

@@ -953,7 +953,11 @@ try {
 
 **Trace id for debugging.** An error caught from `useMutation` / `useAction` carries a **non-enumerable `__voltroTraceId`** — the bridge to the server logs for that exact call:
 
+```ts
+const traceId = (err as { __voltroTraceId?: string }).__voltroTraceId
+// → `voltro logs --trace <traceId>` to see the server-side span
 ```
+
 `errorTag` lives in `@voltro/protocol` rather than in the client for a reason
 worth knowing before you decide where your own error handling goes: **`_tag` is a
 wire concept, and protocol owns the wire.** So a shared error handler in a package
@@ -961,10 +965,6 @@ that has no business depending on `@voltro/client` — a UI kit, an i18n layer
 can read a tag without taking that dependency. `instanceof` is the thing that
 does NOT survive the wire: what arrives in the browser was decoded from JSON and
 never constructed, so match on the tag, not on the class.
-ts
-const traceId = (err as { __voltroTraceId?: string }).__voltroTraceId
-// → `voltro logs --trace <traceId>` to see the server-side span
-```
 
 **Exhaustive matching with the generated `matchError`.** Codegen emits a per-app `matchError` (plus `AppError` / `AppErrorTag`) into `rpcGroup.generated.ts`, derived by reference from every descriptor's `error:` schema + your plugins' cross-cutting errors — so there's no hand-maintained tag list to drift out of date (a dead/renamed tag is a compile error):
 
@@ -1009,6 +1009,24 @@ nobody wrote a client call for it, it is on the wire — the same reasoning as
 whatever authority its caller has. This removes the wire surface, not the need to
 check who is asking; `voltro doctor`'s authz scan still covers it.
 
+**It cannot be combined with `publicApi` or `exposeAsTool`.** Those add a REST
+route and an agent tool respectively — opt-ins to a *different* surface — so a
+procedure carrying both would be unreachable from your own client and reachable
+from the internet. That combination throws where it is declared:
+
+```text
+auditLog.createFromAction: `internal: true` cannot be combined with `publicApi`.
+```
+
+Neither silent resolution would be right: dropping the REST route breaks a live
+endpoint invisibly, and keeping it defeats the flag. Drop `internal: true` if the
+wider surface is intended, or remove the annotation if it is not.
+
+The flag also removes the procedure from `voltro dev`'s inspect invoker, so the
+devtools "invoke" panel will not list it. That is deliberate — an internal
+procedure is the one most likely to carry no guard, since "only server code calls
+this" is the reason people write them.
+
 ## When Not To Use A Mutation
 
 - **External I/O.** Use an action or workflow.
@@ -3522,7 +3540,7 @@ plugin's `tables` option, then read a timeline or restore a snapshot:
 import { versioningPlugin, rowHistory, restoreAsOf } from '@voltro/plugin-versioning'
 
 // Register in your app's plugin list:
-versioningPlugin({ tables: ['blogPost_published', 'blogPost_drafts'] })
+versioningPlugin({})
 
 const timeline = await rowHistory(ctx.store, 'blogPost_published', postId, tenantId)
 await restoreAsOf(ctx.store, 'blogPost_published', postId, tenantId, someEarlierDate)

package/templates/agent-docs/database/migrations.md

@@ -4,6 +4,69 @@
 
 
 
+---
+
+<!-- source: en/database/migrations/adopt.md -->
+## Adopting a table into a plugin's
+
+_voltro db adopt — move an app's grown table into a plugin-owned one, with a snapshot, a count verify and the drop last._
+
+An app that did not start on a green field already has a table for half the plugins it installs. `voltro db adopt` is the way **into** the plugin's table, so using the plugin does not mean running a second source of truth beside it.
+
+```bash
+voltro db adopt --from ai_flows --into _voltro_ai_flows --map ./ai-flows.map.ts
+voltro db adopt --from ai_flows --into _voltro_ai_flows --map ./ai-flows.map.ts --apply
+```
+
+**Dry run unless you pass `--apply`.** The interesting failure here is irreversible and the interesting output is the refusal, so nothing is written until you say so. A refused plan prints no steps at all, rather than a preview of something that will not happen.
+
+## The map file is yours
+
+```ts
+// ai-flows.map.ts
+export default {
+  map: {
+    name:         'name',
+    mode:         { expr: `CASE WHEN "allowDeviation" THEN 'agentic' ELSE 'deterministic' END` },
+    costMicroUsd: { expr: '"totalCostCents" * 10000' },
+  },
+  leaveUnset: ['id'],
+}
+```
+
+Read `target: source` — fill the plugin's column FROM this expression of mine, which is the direction the SQL runs. A string is a source column; `{ expr }` is raw SQL against the source row, for the unit conversions and merged fields no tool can infer. Those are domain knowledge, and a tool inventing them silently corrupts data.
+
+`leaveUnset` is how "the target's own default fills this" stops looking like "I forgot it".
+
+## What it refuses
+
+- **a NOT NULL target column nobody maps to** — the alternative is a silent zero that reads as real data forever after;
+- **a target table that already holds rows** — adopt MOVES rows into a table, it does not merge into one somebody else already wrote;
+- **a typo on either side of the map.**
+
+A source column nobody carries across is reported but not fatal: dropping a dead column is deliberate often enough, and "I forgot this" and "I decided" look identical in a map file.
+
+## The order, and why the drop is last
+
+1. **snapshot** — `<table>__adopt_snapshot`, a real table in the same database, so restoring is a statement rather than an operational procedure at 2am. It keeps the columns the adopt left behind.
+2. **copy**
+3. **verify by count** — this catches the one failure that is otherwise invisible: a `WHERE` inside a raw expression silently dropping rows.
+4. **drop the source** — last, and only if the counts match.
+
+On a mismatch **both tables stay** and the command says so. The snapshot is never removed after a failed verify — it exists for exactly the run that goes wrong. `--keep-source` copies and verifies without dropping at all.
+
+## Ids, if the typeid prefixes differ
+
+The dry run says so before anything runs, because discovering it after the copy is discovering it too late: every row gets a new id, so every reference to the old table has to be rewritten — **including ids embedded in JSON columns**.
+
+Rewriting them is **not** automatic. Those ids live in your columns and inside your JSON, and only you know where. The translation table is what the command owes you; the rewrite is what you owe yourself. Doing it automatically is the one place here where being wrong would be silent.
+
+## After the move
+
+Your rows are now in a table whose shape the framework evolves — and nothing special happens to them. They migrate exactly like every other row, through the same declarative differ. A narrowing can fail on your data, loudly, the same way it would on anybody's.
+
+
+
 ---
 
 <!-- source: en/database/migrations/index.md -->
@@ -1556,6 +1619,37 @@ no-ops out.
 
 The cloud dashboard surfaces per-env state with a multi-env tab in the [cloud UI](./cloud-ui.md).
 
+## File-based migrations in this pipeline
+
+`voltro db apply` runs pending `migrations/*.ts` **first**, then diffs — the same order the boot path uses.
+
+`voltro db apply --plan plan.json` does **not** run them. It **refuses** when any are pending:
+
+```txt
+db apply --plan: refusing — 2 pending file-based migration(s).
+  20260714_090000_split_full_name
+  20260721_143000_backfill_slug
+
+  These perform the changes a state diff cannot infer, so they change the shape
+  this plan was computed against. Apply them and regenerate the plan:
+
+    voltro db files .
+    voltro db plan --json > plan.json
+    voltro db apply --plan plan.json
+```
+
+That is not caution for its own sake. A saved plan was computed and reviewed against an earlier state; a file migration performs exactly the kind of change (a table split, a cross-table data move) that makes the plan stale. Running the migrations first would trip the fingerprint guard immediately afterwards and leave a half-applied deploy; running them after would apply a plan reviewed against a state that no longer exists.
+
+**So a pipeline that uses the saved-plan form needs `voltro db files` as its own step**, before the plan is generated:
+
+```bash
+voltro db files .                          # authored data steps
+voltro db plan --json > plan.json          # diff, now against the corrected shape
+voltro db apply --plan plan.json           # reviewed, fingerprint-guarded
+```
+
+If you use plain `voltro db apply` instead, the first step is already included.
+
 
 
 ---

package/templates/agent-docs/plugins.md

@@ -132,6 +132,48 @@ Order matters: the framework composes outer→inner, so the rate-limit intercept
 | `onInstall` / `onActivate` / `onDeactivate` / `onUninstall` | Lifecycle hooks at first-install, boot, shutdown, and removal. |
 | Schema mixins (`defineMixin`) | The OTHER plugin shape — `audit()`, `tenant()`, `softDelete()` — declared in `@voltro/database`, not via the runtime contract. |
 
+## Pointing YOUR table at a plugin's row
+
+Every table-carrying plugin exports its table handles, so a column in your schema
+can reference one exactly like it references your own:
+
+```ts
+import { aiFlowsTable } from '@voltro/plugin-ai-flows'
+import { id, reference, table, text } from '@voltro/database'
+
+export const flowFavourites = table('flow_favourites', {
+  id:       id({ prefix: 'fav' }),
+  employeeId: reference(() => employees, { onDelete: 'cascade' }),
+  // A real foreign key across the plugin boundary. Deleting the flow removes
+  // the favourite; the DATABASE enforces it, so no cleanup subscriber exists to
+  // forget.
+  flowId:   reference(() => aiFlowsTable, { onDelete: 'cascade' }),
+  note:     text().nullable(),
+})
+```
+
+This is not a special primitive — it is `reference()`, with the same
+`onDelete` semantics and the same index defaults. `plugin-storage`'s `assetRef()`
+has always been exactly this under the hood: a `reference(() => _voltroStorageRefsTable,
+{ onDelete: 'setNull' })`.
+
+**Referencing the table as a VALUE rather than its name as a string is what makes
+this safe across a plugin's own migrations.** When ten plugin tables moved into
+the `_voltro_` namespace in 0.22.0, a `reference(() => table)` followed the rename
+(catalog-only, the constraint travels with the table); a hand-written
+`text()` column holding ids would not have told you anything had changed.
+
+**`fk: false`-style decoupling is still available** — declare a plain `text()`
+column instead. Choose it when you deliberately want the app schema independent
+of the plugin's, and accept that nothing then enforces the link. What you should
+NOT do is reach for it by default: an unenforced id column plus a hand-written
+`defineSubscriber` that cleans up on delete is referential integrity re-implemented
+per app, and it is silently wrong the first time somebody forgets it.
+
+**`orphanPolicy` is not part of this.** It is migration metadata — how existing
+orphan rows are cleaned up *before* the FK constraint is added — and has no
+runtime semantics. Runtime behaviour comes from `onDelete`.
+
 ## When NOT to write a plugin
 
 - **One-off side effect** — just call it from the mutation directly.

package/templates/agent-docs/routing.md

@@ -961,6 +961,7 @@ React alone.
 export const loader = async (ctx: {
   readonly params:   Readonly<Record<string, string>>  // URL params from [name] segments
   readonly pathname: string                             // matched path (no query string)
+  readonly search:   string                             // raw query string incl. `?`, or '' — filled on every path
   readonly signal:   AbortSignal                        // Aborts if the client disconnects mid-render
   readonly headers?: Readonly<Record<string, string>>  // Request headers (SSR/ISR only — empty for SSG/client)
   // Call the backend rpc directly — present ONLY when the loader runs
@@ -970,7 +971,28 @@ export const loader = async (ctx: {
 }) => Promise<unknown>
 ```
 
-The loader context carries `pathname`, not a `request` object. For the query string during SSR, read it from `useServerRequest().url` inside the component.
+The loader context carries `pathname` and `search`, not a `request` object.
+
+`pathname` is deliberately query-free — a loader keyed on `?tab=2` would cache badly. `search` carries the raw query string (with its leading `?`, or `''`), filled identically on client navigation, `voltro dev` SSR and `voltro start` SSR. Parse it with `new URLSearchParams(ctx.search)`.
+
+**Reach for `search` when the loader makes a decision, not when it fetches data.** The case it exists for is a redirect target that depends on a parameter:
+
+```ts
+import { RedirectError } from '@voltro/web'
+
+export const loader = async (ctx) => {
+  const player = await ctx.query('players.byCode', { code: ctx.params['playerCode'] })
+  if (!player) {
+    // Preserve kiosk mode across the redirect — otherwise a kiosk terminal
+    // drops back to normal mode after every failed scan.
+    const mode = new URLSearchParams(ctx.search).get('mode')
+    throw new RedirectError(`/?error=${ctx.params['playerCode']}${mode ? `&mode=${mode}` : ''}`)
+  }
+  return { player }
+}
+```
+
+Do not reconstruct this from `window.location.search`: that exists only on the client-navigation path, so a fresh SSR request loses the value — which is the bug the field was added to remove.
 
 Use `signal` for any fetch that could outlive the request — pass it to `fetch(url, { signal })` so cancelled requests don't waste CPU.
 

package/templates/agent-docs/templates/apibackends.md

@@ -2850,7 +2850,7 @@ voltro create-project acme --api=api-versioning
 // app.config.ts
 import { versioningPlugin } from '@voltro/plugin-versioning'
 export default { type: 'api', name: 'AcmeVer', store: 'memory',
-  plugins: [versioningPlugin({ tables: ['documents'] })] }
+  plugins: [versioningPlugin({})] }
 ```
 
 The snapshotting is automatic. The point is to **read history through handlers** — the template ships two actions:
@@ -2898,7 +2898,7 @@ The memory history store is single-process. With a SQL store, history persists i
 
 ## Anti-patterns
 
-- **Listing `versioningPlugin({ tables })` and stopping there.** That records history but never shows it. The value is in the READS — wire `rowHistory` / `rowAsOf` into a handler (or the dashboard) like this template does.
+- **Listing `versioningPlugin()` and stopping there.** That records history but never shows it. The value is in the READS — wire `rowHistory` / `rowAsOf` into a handler (or the dashboard) like this template does.
 - **Versioning every table.** Snapshots cost storage proportional to write volume. Pick the tables whose past values you actually need.