@voltro/cli 0.34.0 → 0.35.0

package/dist/serveEntry.js

@@ -1,5 +1,5 @@
 import { t as e } from "./loadEnv-D9nEOClM.js";
 import { r as t } from "./appModuleLoader-C9r9mxZt.js";
 import { i as n } from "./dialectDriver-CgXnDfec.js";
-import { t as r } from "./serveCommand-B_isw7q4.js";
+import { t as r } from "./serveCommand-iwlUBNS1.js";
 export { e as loadDotEnv, t as registerAppModules, n as registerDriver, r as runServe };

package/dist/{start-B-9Nsp-S.js → start-BgN62boB.js}

@@ -1,3 +1,3 @@
 import "./renderModeScan-D7J1B7Kw.js";
-import { t as e } from "./start-9LiUOfES.js";
+import { t as e } from "./start-T4VesWiM.js";
 export { e as runStartCommand };

package/dist/{start-9LiUOfES.js → start-T4VesWiM.js}

@@ -1,8 +1,8 @@
 import { i as e, t } from "./nodeEnvironment-cGFAj1J8.js";
 import { r as n } from "./appPort-B_HpJ_ck.js";
-import { A as r, B as i, C as a, D as o, E as s, H as c, I as l, J as u, N as d, O as f, P as p, S as m, T as ee, U as h, V as g, a as _, b as v, d as y, f as b, i as x, j as S, k as te, n as ne, q as C, s as re, st as ie, ut as w, w as T, x as E, y as ae, z as D } from "./webDev-CBYvPqQr.js";
+import { A as r, B as i, C as a, D as o, E as s, H as c, I as l, J as u, N as d, O as f, P as p, S as m, T as ee, U as h, V as g, a as _, b as v, d as y, f as b, i as x, j as S, k as te, n as ne, q as C, s as re, st as ie, ut as w, w as T, x as E, y as ae, z as D } from "./webDev-Dybxew86.js";
 import { o as O, t as k } from "./connectionConfig-UFlIEiys.js";
-import { A, D as j, a as M, h as oe, j as N, k as se } from "./inspect-CBqFtAKA.js";
+import { A, D as j, a as M, h as oe, j as N, k as se } from "./inspect-CjTYzAs_.js";
 import { a as ce, c as P, d as le, f as ue, l as F, p as I, u as de } from "./renderModeScan-D7J1B7Kw.js";
 import { i as fe, n as pe, r as me, t as he } from "./runtimeRegistry-DMeKfTHP.js";
 import { n as ge } from "./logFileSink-C_D2wRN1.js";

package/dist/startEntry.js

@@ -1,3 +1,3 @@
 import { t as e } from "./loadEnv-D9nEOClM.js";
-import { t } from "./start-9LiUOfES.js";
+import { t } from "./start-T4VesWiM.js";
 export { e as loadDotEnv, t as runStartCommand };

package/dist/{tracesCmd-CkEZQrtt.js → tracesCmd-DStmCJPi.js}

@@ -1,6 +1,6 @@
 import { n as e } from "./runtimeRegistry-DMeKfTHP.js";
 import { n as t } from "./cliOutput-D1tSBoRM.js";
-import { a as n, i as r } from "./inspectFetch-Cm8_wVvp.js";
+import { a as n, i as r } from "./inspectFetch-EMuhTG_9.js";
 import { ansi as i } from "@voltro/logger";
 //#region src/tracesCmd.ts
 var a = (e) => {

package/dist/updateCommand-BlMZhWgO.js

@@ -0,0 +1,2 @@
+import { f as e, p as t } from "./updateCommand-x0pI_x-B.js";
+export { e as runApplyCodemods, t as runUpdateCommand };

package/dist/{updateCommand-Bkptutss.js → updateCommand-x0pI_x-B.js}

@@ -1,4 +1,4 @@
-import { n as e, r as t, t as n } from "./codemodRunner-DRRqXR74.js";
+import { n as e, r as t, t as n } from "./codemodRunner-BnFq3Fgu.js";
 import { basename as r, dirname as i, join as a, relative as o, resolve as s } from "node:path";
 import { existsSync as c, readFileSync as l, readdirSync as u, statSync as d, writeFileSync as f } from "node:fs";
 import { totalmem as p } from "node:os";

package/dist/webDev-BcykISYQ2.js

@@ -0,0 +1,2 @@
+import { _ as e } from "./webDev-Dybxew86.js";
+export { e as tryRunWebServe };

package/dist/{webDev-CBYvPqQr.js → webDev-Dybxew86.js}

@@ -2,7 +2,7 @@ import { t as e } from "./nodeEnvironment-cGFAj1J8.js";
 import { n as t } from "./loadEnv-D9nEOClM.js";
 import { r as n } from "./appPort-B_HpJ_ck.js";
 import { h as r, m as i } from "./fileConventions-Cof68_BL.js";
-import { A as a, D as o, a as s, h as c, j as l, k as u } from "./inspect-CBqFtAKA.js";
+import { A as a, D as o, a as s, h as c, j as l, k as u } from "./inspect-CjTYzAs_.js";
 import { n as d } from "./agentsMd-mhQMF1bx.js";
 import { c as f, p, t as m } from "./renderModeScan-D7J1B7Kw.js";
 import { t as h } from "./pageConvention-cEiRxdab.js";
@@ -1854,7 +1854,19 @@ import {
 		if (!o.ok) throw Error(`[loader.query] ${r}: HTTP ${o.status} ${await o.text()}`);
 		let s = await o.json();
 		if (!Array.isArray(s)) throw Error(`[loader.query] ${r}: unexpected non-array rpc response`);
-		let c = (e) => e && typeof e == "object" && "_tag" in e && "data" in e && e._tag === "snapshot" ? e.data : e, l, u = !1;
+		let c = (e) => {
+			if (!e || typeof e != "object" || !("_tag" in e)) return e;
+			let t = e;
+			switch (t._tag) {
+				case "snapshot": return t.data;
+				case "error": {
+					let e = t.error;
+					throw Object.assign(Error(`[loader.query] ${r}: ${e?._tag ?? "error"}${e?.message ? ` — ${e.message}` : ""}`, { cause: t.error }), { voltroError: t.error });
+				}
+				case "delta": throw Error(`[loader.query] ${r}: received a 'delta' as the first event, which should be impossible — a subscription always opens with a snapshot. This is a framework bug.`);
+				default: return e;
+			}
+		}, l, u = !1;
 		for (let e of s) {
 			if (e._tag === "ClientProtocolError") throw Error(`[loader.query] ${r}: protocol error ${JSON.stringify(e.error)}`);
 			if (!(e.requestId !== void 0 && String(e.requestId) !== "0")) {

package/dist/{webhooksCommand-CID96Rga.js → webhooksCommand-DlAgS2Iw.js}

@@ -222,7 +222,7 @@ createVerifier({ secret: [process.env.WEBHOOK_SECRET, process.env.WEBHOOK_SECRET
 		...t === void 0 ? {} : { payload: t }
 	};
 }, S = u({ scope: "voltro:webhooks" }), C = ["--out", "--name"], w = async (e) => {
-	let { walk: t, loadDiscovered: n } = await import("./dev-CoG-ZPx8.js"), { outgoingFromEvents: r } = await import("./webhookDiscovery-CrGAfhIG.js");
+	let { walk: t, loadDiscovered: n } = await import("./dev-D2BikO7a.js"), { outgoingFromEvents: r } = await import("./webhookDiscovery-CrGAfhIG.js");
 	return r((await n(await t(e))).events.map((e) => ({
 		file: e.file,
 		descriptor: e.descriptor

package/dist/{workflowsCmd-D1VTmLMY.js → workflowsCmd-BGF-mRZ5.js}

@@ -1,5 +1,5 @@
 import { n as e } from "./cliOutput-D1tSBoRM.js";
-import { n as t, o as n, r, t as i } from "./inspectFetch-Cm8_wVvp.js";
+import { n as t, o as n, r, t as i } from "./inspectFetch-EMuhTG_9.js";
 import { ansi as a } from "@voltro/logger";
 //#region src/workflowsCmd.ts
 var o = [

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@voltro/cli",
-  "version": "0.34.0",
+  "version": "0.35.0",
   "description": "The `voltro` CLI — dev server, codegen, migrations, project scaffolding, agent-docs seeding, and production serve.",
   "keywords": [
     "voltro",
@@ -538,6 +538,36 @@
         "title": "`routeHttp` returns a Promise",
         "kind": "manual"
       },
+      {
+        "version": "0.35.0",
+        "id": "0.35.0/01_event-access-decision",
+        "title": "Every declared event decides who may listen (`guards:` or `openAccess:`)",
+        "kind": "manual"
+      },
+      {
+        "version": "0.35.0",
+        "id": "0.35.0/02_plugin-procedures-carry-access-decisions",
+        "title": "First-party plugin procedures carry access decisions; twelve now require a scope",
+        "kind": "manual"
+      },
+      {
+        "version": "0.35.0",
+        "id": "0.35.0/03_analytics-mirror-max-version",
+        "title": "Custom analytics mirror sinks answer `maxVersion` (fleet-scope seed read)",
+        "kind": "manual"
+      },
+      {
+        "version": "0.35.0",
+        "id": "0.35.0/04_flow-run-step-skipped",
+        "title": "A flow run step can now be 'skipped' — handle it where you render a run timeline",
+        "kind": "manual"
+      },
+      {
+        "version": "0.35.0",
+        "id": "0.35.0/05_declared-schema-drops-runtime-flags",
+        "title": "The declared schema no longer reads `CDC` / `VOLTRO_UNDO` / `VOLTRO_TRACING_PERSIST`",
+        "kind": "manual"
+      },
       {
         "version": "0.4.0",
         "id": "0.4.0/01_rbac-forbidden-to-scopeerror",
@@ -637,22 +667,22 @@
     "@effect/platform-node": "^0.108.0",
     "@effect/sql": "^0.52.0",
     "@effect/workflow": "^0.19.0",
-    "@voltro/ai": "0.34.0",
-    "@voltro/cache": "0.34.0",
-    "@voltro/data-transfer": "0.34.0",
-    "@voltro/database": "0.34.0",
-    "@voltro/env": "0.34.0",
-    "@voltro/kv": "0.34.0",
-    "@voltro/logger": "0.34.0",
-    "@voltro/plugin-auth": "0.34.0",
-    "@voltro/plugin-broadcast": "0.34.0",
-    "@voltro/plugin-mail": "0.34.0",
-    "@voltro/plugin-storage": "0.34.0",
-    "@voltro/plugin-webhooks": "0.34.0",
-    "@voltro/protocol": "0.34.0",
-    "@voltro/runtime": "0.34.0",
-    "@voltro/serverless": "0.34.0",
-    "@voltro/workflow": "0.34.0",
+    "@voltro/ai": "0.35.0",
+    "@voltro/cache": "0.35.0",
+    "@voltro/data-transfer": "0.35.0",
+    "@voltro/database": "0.35.0",
+    "@voltro/env": "0.35.0",
+    "@voltro/kv": "0.35.0",
+    "@voltro/logger": "0.35.0",
+    "@voltro/plugin-auth": "0.35.0",
+    "@voltro/plugin-broadcast": "0.35.0",
+    "@voltro/plugin-mail": "0.35.0",
+    "@voltro/plugin-storage": "0.35.0",
+    "@voltro/plugin-webhooks": "0.35.0",
+    "@voltro/protocol": "0.35.0",
+    "@voltro/runtime": "0.35.0",
+    "@voltro/serverless": "0.35.0",
+    "@voltro/workflow": "0.35.0",
     "chokidar": "^5.0.0",
     "ioredis": "^5.11.1",
     "tinyglobby": "^0.2.17",

package/templates/AGENTS.md

@@ -707,7 +707,7 @@ each plugin's own README.
 
 | Topic | Open | Summary |
 |---|---|---|
-| **What's new in 0.34.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.35.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.34.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.35.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

@@ -161,7 +161,7 @@
       "group": null,
       "description": "Voltro Cloud (coming soon) — the managed runtime for your Voltro project. Today the Free control plane registers + observes your self-hosted apps.",
       "path": "agent-docs/deployment.md",
-      "files": 7
+      "files": 8
     },
     {
       "id": "internationalization",

package/templates/agent-docs/authentication.md

@@ -2167,6 +2167,11 @@ default to "allowed", so a discovered `*.query.ts` / `*.mutation.ts` /
 `*.action.ts` / `*.stream.ts` with no guard was callable by **any authenticated
 session** — the door defaulted open, and nothing said so.
 
+The same rule covers **events**: a `*.event.ts` declaration is a wire surface
+too, and one that declares neither `guards:` nor `openAccess:` was silently
+subscribable by anyone who could open the socket. `defineEvent` takes the same
+two answers — see [Events](/docs/data/events).
+
 There are exactly two answers, and they are not the same claim:
 
 ```ts
@@ -2204,8 +2209,8 @@ refusal names **every** offending procedure with its file, because the fix is on
 pass over the whole list:
 
 ```
-[access] 3 wire-exposed procedures declare no access decision, and this app runs
-with `security.defaultDeny`:
+[access] 3 wire-exposed procedures or events declare no access decision, and
+this app runs with `security.defaultDeny`:
 
     invoices.list  (query)
       src/api/invoices.query.ts
@@ -2229,11 +2234,24 @@ anyone reaches for is off, and an env var is how a security default becomes
 permanently off in one CI job with no diff to review. `voltro doctor` keeps
 listing the undecided procedures while it is off, marked advisory.
 
-### What it does NOT cover
-
-The gate reads **your app's own** discovered procedures. The procedures a plugin
-declares are the plugin author's decision and are not checked here — adopting
-this does not turn into a bug report against a plugin you installed.
+### What it does NOT cover — and what covers the rest
+
+The **boot** gate reads **your app's own** discovered procedures and events. The
+procedures a plugin declares are the plugin author's decision and are not judged
+at boot — adopting this does not turn into a bug report against a plugin you
+installed.
+
+They are not unpoliced, though: the same `security.defaultDeny` is also enforced
+**per request in the dispatch spine**, as defense in depth. A descriptor that
+reaches the wire with no access decision — a plugin route, a hand-bound
+descriptor — is refused with the same typed `ScopeError` before the transaction
+opens or any external I/O runs. Every first-party plugin route declares its own
+decision (a scope where a real authority exists — e.g. `billing:manage`,
+`storage:browse` — or `openAccess` with the reason on the routes that are
+self-scoped or anonymous-capable by design; each plugin's page lists them). A
+third-party plugin that declares neither on a route will see that route refused
+per-request under default-deny — the fix is one field on the route, exactly as
+for your own procedures.
 
 ## Decide — `can` / `assertCan`
 
@@ -2486,6 +2504,36 @@ error frame, rather than delivering an empty snapshot — an empty snapshot on a
 live subscription reads to a client as "every row you could see was just
 deleted". Make sure your subscription error handling surfaces it.
 
+## A path that cannot apply the filter refuses, rather than serving rows
+
+If a filter is registered and a scoped store is built without a resolved scope,
+the store **throws**. It does not fall back to unfiltered reads.
+
+That fallback used to exist, and it is the reason this section does. A team
+measured four read paths returning every row of the tenant to every employee,
+on both transports, with `row filter registered` in the boot log and a green
+test suite. The registration lived in a module-local variable, so an app's
+`*.startup.tsx` and the framework's request pipeline could hold two different
+copies of it — the serve bundle inlines the framework while app modules stay
+external, and a strict pnpm tree can resolve one version into two directories.
+The pipeline read "no filter registered", which was indistinguishable from an
+app that has none, and served everything.
+
+The registration is process-global for real now (`globalThis`, so every copy
+shares one cell), and the ambiguity that made the failure silent is gone: those
+two readings are different claims and only one of them is a decision.
+
+If a code path is deliberately unfiltered — a system sweep, a migration, a
+seeding helper in a test — say so:
+
+```ts
+wrapStoreWithMixinBehaviour(store, { subject, schemaRegistry, rowFilter: NO_ROW_FILTER })
+```
+
+`runAsSystem`, change-stream subscribers and the webhook trigger context already
+do this; a system subject bypasses row filters by design, and it is now written
+down rather than inferred from an absence.
+
 ## What does *not* bypass it
 
 | | Bypasses the row filter? |

package/templates/agent-docs/cli.md

@@ -2107,6 +2107,45 @@ voltro check             --url https://api.example.com
 
 `--token` (or `VOLTRO_INSPECT_TOKEN`) supplies the bearer; `VOLTRO_INSPECT_URL` sets a default target so you can drop the flag. Works for `inspect`, `logs`, `traces`, `workflows`, `cluster` and `check`.
 
+## `voltro probe access` — is a declared guard actually enforced?
+
+`voltro check` reads an app's manifest and reports a procedure with **no access
+decision**. It cannot tell you whether the decisions that ARE declared are
+enforced. `voltro probe access` asks the running app:
+
+```bash
+voltro probe access                 # every live api
+voltro probe access --url https://api.example.com --strict
+```
+
+It calls every procedure that declares a guard with **no credentials at all**
+and reports any that answer anyway:
+
+```
+api: probed 14 guarded procedure(s) with NO credentials
+  ✗ orders.export — ANSWERED an unauthenticated call
+  ? billing.invoice — answered 'ParseError' — not an access refusal, so the guard was not reached
+  ✓ 12 refused · 1 inconclusive · 1 admitted
+```
+
+Three verdicts, and the third is what keeps the command honest:
+
+| Verdict | Meaning |
+|---|---|
+| `refused` | The call came back as an access refusal. The declaration is enforced. |
+| `admitted` | The call SUCCEEDED without credentials. **This is the finding.** |
+| `inconclusive` | The call failed for a reason that is not an access refusal — usually payload validation running before the guard. **Not a pass.** |
+
+Exit code is non-zero on any `admitted`. `--strict` also fails on
+`inconclusive`, which is what you want in CI: "I could not tell" should block.
+
+**What it deliberately does not do.** It probes ANONYMOUSLY, so it cannot tell
+`orders:read` from `orders:write` — it answers exactly one question, and the
+alternative (minting a subject per guard) would put credential minting into a
+command that can be pointed at production. Procedures declared `openAccess:` are
+skipped; probing them would report every deliberately-public route as a finding
+and bury the real ones.
+
 ## Securing the local surface
 
 `voltro dev` mints a per-project `VOLTRO_INSPECT_TOKEN` into `.env.local`, so the inspect surface is authenticated from the first boot — the dev server listens on every interface, and without a token anyone on the same network could read your rows, schema and logs. You don't have to wire it anywhere: the CLI picks the token up from the runtime registry (so the commands work from any directory), and the dashboard's server-side proxy supplies it for same-machine targets. Setting `VOLTRO_INSPECT_TOKEN` yourself always wins.
@@ -2564,6 +2603,26 @@ voltro data import ./out --force             # import despite schema drift AND c
 
 Import is **integrity-checked** (each table's checksum + row count verified as it decodes; each asset re-hashed against its content address), applies tables in **FK-parent-first order**, and a resumed run skips already-applied tables via the ledger.
 
+### Postgres targets bulk-load via COPY
+
+On a **postgres** target, the direct import switches to `COPY … FROM STDIN`
+wherever plain-INSERT semantics provably hold: `--mode replace` (the tables were
+just truncated) and the default `upsert` into a table that is **empty** at
+import time — the fresh-target shape every cross-dialect migration
+(mysql → postgres, sqlite → postgres, …) lands in. Measured on a 7-column table
+(text/int/bool/jsonb/timestamptz) with 50 000 rows against a local postgres:
+row-by-row **12.8 s (~3.9 k rows/s)** vs COPY **0.59 s (~84.6 k rows/s)** —
+**21.7× faster**. Your factor depends on row width and network latency;
+COPY's advantage grows with per-row round-trip cost.
+
+Everything else keeps the per-row `DataStore` writes: `upsert` into a non-empty
+table (COPY cannot upsert), `append` (per-row conflict handling), `--atomic`
+(the COPY connection would sit outside the transaction), and every other
+dialect. A refused COPY batch (an FK the deferred pass repairs later, a value
+COPY text can't carry) is atomic — nothing landed — so the importer replays
+exactly that batch through the per-row path and continues; semantics are
+identical, only the speed differs.
+
 ### Schema-drift pre-flight
 
 Every bundle records the **schema fingerprint** of the source it was exported from (a stable hash of the schema shape — the same fingerprint prod boot uses to detect drift). Before touching the target, `import` **recomputes the target app's fingerprint the same way** and compares it to the bundle's. On a mismatch it **refuses, fail-closed, before any row lands** — a drifted target (a missing column, a renamed table) would otherwise fail mid-load with a raw database error after some rows already committed:

package/templates/agent-docs/data.md

@@ -1606,6 +1606,37 @@ Names are lowercase kebab segments separated by dots — `presence`, `job-queue`
 uppercase letter (a key that differs only by case reads as one channel and
 routes as two). Declaring the same name twice returns the same channel.
 
+### A publish is LOCAL news, and says so
+
+The change event a publish emits carries `origin: 'inline'` — the same stamp a
+write made in this process carries. An event that arrives from another replica
+carries `origin: 'injected'`. So a listener can tell the two apart:
+
+```ts
+store.onChange((event) => {
+  if (event.table !== jobQueue.key) return
+  if (event.origin === 'injected') {
+    // a PEER published — mirror it into local state, then publish onward if
+    // this node has anything of its own to add
+  }
+})
+```
+
+That distinction is what makes a fan-out pattern writable. Without it, a
+replica's own publish and a peer's are indistinguishable, and the only way to
+avoid an echo is a boolean per channel.
+
+Two consequences worth knowing:
+
+- **Re-publishing from inside a change listener works, synchronously.** A
+  channel published while handling a peer's event reaches the other replicas
+  like any other publish. (This is worth stating because it did not use to:
+  `plugin-broadcast` suppressed every emission made while it was injecting, so
+  such a publish woke the local node and silently never left it.)
+- **`origin` never crosses the wire.** It describes how an event reached *this*
+  process, so the receiving replica always stamps its own. A publish that says
+  `'inline'` here arrives as `'injected'` there, which is the truth on both ends.
+
 ### What a channel is not
 
 - **Not an event.** [`defineEvent`](/docs/data/subscriptions#streams-are-different)
@@ -1881,7 +1912,16 @@ So deliveries run **concurrently, up to a bound**. The default is 8 in flight.
 Measured with 50 subscribers behind a 5 ms guard: 517 ms to serve all of them
 serially, 72 ms at 8 lanes.
 
-Set it with `VOLTRO_REACTIVE_DELIVERY_CONCURRENCY`:
+Declare it in `app.config.ts`, or override per deployment with the env var —
+the env wins, because an operator acting on a running system outranks what the
+project declared:
+
+```ts
+export default {
+  type: 'api' as const, name: 'api',
+  reactive: { deliveryConcurrency: 16, rawReadTrackingLimit: 64 },
+}
+```
 
 ```bash
 VOLTRO_REACTIVE_DELIVERY_CONCURRENCY=16 voltro serve
@@ -2120,6 +2160,17 @@ A `*.event.ts` file is **browser-safe** and may hold several declarations — a
 
 **`guards` decide who may listen**, in the same vocabulary a query uses, and they are checked *before* the subscription is registered — a refused client never holds one. The routing key is the guard input, so a resource-scoped guard (`{ scope: 'arena:read', from: 'arenaId' }`) sees which arena was asked for. A refusal reaches the client as the `ScopeError` the rpc declares.
 
+**`openAccess: '<reason>'` is the other answer to the same question**, exactly as on a procedure. Under `security.defaultDeny` (the default) an event that declares *neither* `guards:` nor `openAccess:` refuses the boot, by name — an access decision nobody made is a hole, not a default. For an event that really is open — a public scoreboard, a status pulse — declare it and say why; the reason is what a reviewer reads and what `voltro doctor` prints beside the tag. Do not reach for a scope every caller already holds just to satisfy the gate: that guard reads as protection and enforces nothing.
+
+```ts
+export const scoreboardTick = defineEvent({
+  name: 'scoreboard.tick',
+  key: Schema.Struct({ arenaId: Schema.String }),
+  payload: Schema.Struct({ score: Schema.Number }),
+  openAccess: 'public scoreboard — carries no caller data',
+})
+```
+
 **The tenant is not part of the key and must never be added.** It comes from the subject on both sides, so a cross-tenant delivery is impossible by construction rather than by remembering to filter.
 
 The name shares the rpc tag space. Two declarations answering to one name fail the **boot**, not the first delivery.
@@ -2548,6 +2599,8 @@ Migrating is mechanical: declare the event, replace the insert with `ctx.events.
 ```ts
 defineEvent({ name: 'orders paid', … })              // ✗ whitespace — see below
 defineEvent({ name: 'orders.paid', guards: [], … })  // ✗ enforces nothing
+defineEvent({ name: 'x', openAccess: '', … })        // ✗ the reason is the point
+defineEvent({ name: 'x', openAccess: 'why', guards: [{ scope: 's' }], … })  // ✗ two decisions
 defineEvent({ name: 'x', webhook: { rateLimit: { perMinute: 0 } } })  // ✗ never delivers
 ```
 
@@ -2559,7 +2612,11 @@ production only. Use a dot to namespace: `orders.paid`.
 
 **`guards: []` is refused** because it reads at the call site as if the event
 were protected and enforces nothing — the empty list never reaches the check.
-Omit the field for an unguarded event.
+An event with no decision at all does not boot under `security.defaultDeny`;
+declare `openAccess: '<why>'` for a deliberately open one. **An empty
+`openAccess` reason is refused** — the reason is the reviewable half of the
+decision — and **`openAccess` + `guards` together are refused**: two decisions
+say the event is protected AND open.
 
 **`rateLimit: { perMinute: 0 }`** defers every delivery forever. There is no
 "unlimited" spelling — omit `rateLimit` for no ceiling. **`version: 0`** would

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

@@ -887,6 +887,10 @@ A multi-step plan runs inside one `BEGIN ... COMMIT`. Mid-flight failure rolls E
 
 The advisory-lock variants serialise concurrent applies — two operators running `voltro db apply` against the same DB at the same time go through serially.
 
+**The lock is scoped to your configured schema.** With `DB_SCHEMA` set, the lock key (Postgres) / lock name (MySQL, MSSQL) is derived from the schema, so two apps sharing one database in different schemas do not serialise — or defer — each other's migrations and trigger repairs. Without `DB_SCHEMA` (or with `DB_SCHEMA=public`) every instance takes one stable framework-wide key, which is what makes a rolling deploy safe: old and new replicas contend on the same lock. On MySQL/MariaDB `GET_LOCK` is server-wide; setting `DB_SCHEMA` to your database name un-shares the lock between two apps on one server.
+
+**Transient DDL failures are retried, per the dialect's own predicate.** A `CREATE TABLE IF NOT EXISTS` that meets SQLite/Turso's schema lock (`database is locked` / `SQLITE_BUSY`), a MySQL lock-wait timeout, or a Postgres/MSSQL deadlock victim during the boot auto-migrate is retried with bounded attempts and exponential backoff instead of failing the boot on the first attempt — only statements that are safe to re-run, and on Postgres/MSSQL as a fresh transaction (their deadlock classes roll the whole transaction back). `VOLTRO_MIGRATION_DDL_RETRIES` moves the retry count (default 4; `0` disables).
+
 ## MySQL / MariaDB / SQLite / Turso — the resume ledger
 
 Every DDL statement implicitly commits. A 5-op plan on MySQL is effectively 5 separate "atomic statements" with the prior ones already committed when a later one fails. If op 5 of 5 fails, ops 1–4 stay applied:
@@ -3154,6 +3158,48 @@ you would review is the one you just wrote.
 
 If the cause is drift (someone DDL'd prod manually), see [drift.md](./drift.md) for reconciliation paths.
 
+### If the two processes are the same image: compare their `env:` blocks
+
+A fingerprint mismatch does not always mean the schema changed. The declared
+table set is what gets hashed, and until 0.35.0 three RUNTIME flags could move
+it — so a pre-deploy migrate Job and the pods it feeds could disagree while
+running identical code against one database.
+
+That was reported as a green migrate job followed by every pod in
+CrashLoopBackOff. The chart gave the Job its own `env:` list (`NODE_ENV`,
+`DB_*`) while `CDC: "0"` lived in the pods' block, because change data capture
+reads as a runtime concern. Measured on mariadb at `NODE_ENV=production`, each
+flag flipped alone:
+
+| flag | effect on the DECLARED set |
+| --- | --- |
+| `CDC=0` | removes `_voltro_cdc_offsets` |
+| `VOLTRO_UNDO=on` | adds `_voltro_undo_log` |
+| `VOLTRO_TRACING_PERSIST=all` | adds `_voltro_traces` |
+
+**From 0.35.0 none of them does.** `_voltro_cdc_offsets` follows the DIALECT, so
+a mariadb/mssql app declares it either way; the other two are declared in
+`app.config.ts` and the env vars only choose what a process captures:
+
+```ts
+export default {
+  // Both default to on outside production. Declare them when you want the
+  // table in a production schema — `VOLTRO_UNDO` / `VOLTRO_TRACING_PERSIST`
+  // alone is no longer enough, because your migrate job does not carry them.
+  schema: { undo: true, traces: true },
+}
+```
+
+Setting a capture flag ON without the declaration now refuses the boot and names
+the field, rather than writing to a table nobody created.
+
+The refusal also prints which of the three tables this process decided and from
+which input, so the comparison is a glance rather than a hash diff. Do compare
+the two `env:` blocks anyway if you use plugins: a plugin's `extendSchema.tables`
+is your code and may read anything, which is the one part the framework cannot
+guarantee for you.
+
+
 ## "duplicate column name in plan" (logically invalid plan)
 
 ```
@@ -3493,7 +3539,10 @@ Three things about it are worth knowing before you deploy a fleet:
   `pg_try_advisory_lock` and SKIPS if anything holds it, so N replicas booting
   together produce one repairing and N-1 logging `another instance … is
   converging it`. A concurrent `voltro db apply` holds the same lock, so the two
-  can never run each other's DDL.
+  can never run each other's DDL. The lock is scoped to your configured
+  `DB_SCHEMA`, so `another instance` really means an instance of YOUR
+  deployment — a second app sharing the database in a different schema takes a
+  different key and neither defers the other.
 - **It never fails a boot.** A check that cannot run warns and the process
   continues; reactivity may be degraded, and that is still better than a
   diagnostic taking the app down.