@voltro/cli 0.30.0 → 0.30.2

package/dist/startEntry.js

@@ -1,3 +1,3 @@
-import { et as e } from "./inspectMetrics-BeJdP_3b.js";
-import { t } from "./start-ocqB1seX.js";
+import { tt as e } from "./inspectMetrics-BM1vrsga.js";
+import { t } from "./start-CTnNvKlk.js";
 export { e as loadDotEnv, t as runStartCommand };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@voltro/cli",
-  "version": "0.30.0",
+  "version": "0.30.2",
   "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.30.0",
-    "@voltro/cache": "0.30.0",
-    "@voltro/data-transfer": "0.30.0",
-    "@voltro/database": "0.30.0",
-    "@voltro/env": "0.30.0",
-    "@voltro/kv": "0.30.0",
-    "@voltro/logger": "0.30.0",
-    "@voltro/plugin-auth": "0.30.0",
-    "@voltro/plugin-broadcast": "0.30.0",
-    "@voltro/plugin-mail": "0.30.0",
-    "@voltro/plugin-storage": "0.30.0",
-    "@voltro/plugin-webhooks": "0.30.0",
-    "@voltro/protocol": "0.30.0",
-    "@voltro/runtime": "0.30.0",
-    "@voltro/serverless": "0.30.0",
-    "@voltro/workflow": "0.30.0",
+    "@voltro/ai": "0.30.2",
+    "@voltro/cache": "0.30.2",
+    "@voltro/data-transfer": "0.30.2",
+    "@voltro/database": "0.30.2",
+    "@voltro/env": "0.30.2",
+    "@voltro/kv": "0.30.2",
+    "@voltro/logger": "0.30.2",
+    "@voltro/plugin-auth": "0.30.2",
+    "@voltro/plugin-broadcast": "0.30.2",
+    "@voltro/plugin-mail": "0.30.2",
+    "@voltro/plugin-storage": "0.30.2",
+    "@voltro/plugin-webhooks": "0.30.2",
+    "@voltro/protocol": "0.30.2",
+    "@voltro/runtime": "0.30.2",
+    "@voltro/serverless": "0.30.2",
+    "@voltro/workflow": "0.30.2",
     "chokidar": "^5.0.0",
     "ioredis": "^5.11.1",
     "tinyglobby": "^0.2.17",

package/templates/AGENTS.md

@@ -652,7 +652,7 @@ each plugin's own README.
 
 | Topic | Open | Summary |
 |---|---|---|
-| **What's new in 0.30.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.30.2** | `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.30.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.30.2** | `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/cli.md

@@ -1181,6 +1181,35 @@ re-open a hole nor hide one, and it is consulted **last**: an executor that gain
 a real guard is reported as guarded whether or not its line is still there. The
 list can only shrink unless someone adds to it deliberately.
 
+**Two kinds of line, because "debt" and "reviewed" are different claims.** A bare
+tag is debt. A tag with `reviewed=<why>` says a human read the executor and found
+it genuinely open — constrained by something the scanner cannot see:
+
+```txt
+teams.deleteSubTeam
+inquiries.publicFeed  reviewed=public by design; returns only published rows
+```
+
+The reason is required: `reviewed=` with no why is the claim without the
+evidence, and doctor refuses it. A bare tag is always available and is the honest
+alternative. The two are counted and printed apart, and
+`--write-authz-allowlist` is **additive**: it keeps the existing file verbatim —
+entries, comments, grouping, order — and appends only tags it does not already
+contain. It cannot remove a line. Removing one is your edit, or it happens on its
+own when an executor gains a guard and its line stops mattering.
+
+#### Reading the whole list
+
+The human view prints the 20 most severe unchecked executors. The complete scan
+— every finding, the counts, the inferred guard vocabulary, and the debt/reviewed
+split — is in `voltro doctor --json` under `authz`:
+
+```bash
+voltro doctor --json | jq '.authz.unchecked[] | {tag, why, path}'
+```
+
+Nothing is truncated there. If you are triaging, work from the JSON.
+
 #### Before you hand-roll another check
 
 If your checks are imperative because a scope cannot express "may this subject

package/templates/agent-docs/internationalization.md

@@ -29,8 +29,8 @@ export default {
   type:  'web' as const,
   name:  'myApp',
   port:  5191,
-  // Codes the app SHIPS catalogs for. Every code listed here MUST
-  // have a corresponding `src/locales/<code>.ts` file or boot fails.
+  // The languages this app serves. Drives `<html lang>`, the resolved
+  // locale, and the `locale` your page `meta` receives.
   locales: ['en', 'de'] as const,
   // Fallback locale when no cookie / Accept-Language matches a
   // supported one. MUST be in `locales`. Pick your source-of-truth
@@ -39,7 +39,29 @@ export default {
 }
 ```
 
-The framework's generated `.framework/app.tsx` wraps the Router in `<I18nProvider>` automatically. You don't write the provider yourself; you don't import `@voltro/i18n` in your layout. Each code in `locales` must have a matching `src/locales/<code>.ts` catalog file — a missing file fails boot, not silently at runtime.
+The framework's generated `.framework/app.tsx` wraps the Router in `<I18nProvider>` automatically when your app **ships catalogs**. You don't write the provider yourself; you don't import `@voltro/i18n` in your layout.
+
+### Declaring languages is not the same as adopting the catalogs
+
+`locales:` states which languages the app serves. Whether `@voltro/i18n` gets
+wired is decided separately, by whether `src/locales/<code>.ts` exists for every
+listed code:
+
+| `locales:` | `src/locales/*` | what you get |
+|---|---|---|
+| declared | present | `<I18nProvider>` wired, `useT()` works, plus the language facts |
+| declared | absent | the language facts ONLY — `<html lang>`, the resolved locale, `meta.locale`. Bring your own i18n stack. |
+| absent | — | everything falls back to `'en'` |
+
+The second row exists because the two used to be one switch, and that made
+`locales:` unusable for an app with its own i18n: declaring it demanded catalog
+files and failed the boot, so the option got left out — and then `<html lang>`
+was `"en"` and every page's `meta` received `locale: 'en'`, for every visitor, in
+an app that is not English. That is worse than useless: a page that trusted the
+value would have rendered the wrong language.
+
+`voltro dev` prints which mode it is in, so a declared-but-unwired app is never a
+silent surprise.
 
 ## Locale resolution order
 

package/templates/agent-docs/routing.md

@@ -556,6 +556,20 @@ Use SSR for:
 - **Personalised content** — recommendations, "your" anything.
 - **Search result pages** — the query string changes per request.
 
+### What the server render sees
+
+An SSR render is given the request, not a guess at it: the matched `pathname`
+and `params`, the request's cookies and headers (`useServerRequest()`), and the
+**query string**. `useSearchParams()` is the supported reader and works on both
+sides — on the server it reads the request URL, on the client
+`window.location.search` — so a page keyed off `?tab=…` renders the same markup
+in both places.
+
+That last part is worth stating because it is the thing a mismatch is made of.
+Anything the server renders from a value the client computes differently
+hydrates with a warning, even when the DOM happens to agree; reach for the hook
+rather than reading the router context directly.
+
 Cost: every request triggers a fresh render. For very high-traffic pages, prefer ISR.
 
 ### Streaming SSR