@voltro/cli 0.1.0

package/templates/apps/api-backend-deactivation/README.md

@@ -0,0 +1,49 @@
+# {{projectName}} / {{appName}}
+
+Voltro API scaffold (template: **api-backend-deactivation**) — the
+`deactivation()` schema mixin: lock a user out without hiding their data.
+
+## Boot
+
+```bash
+pnpm install
+pnpm --filter @{{projectName}}/{{appName}} dev
+# → http://localhost:4000  (store: memory — zero infra)
+```
+
+## What this shows
+
+- **`deactivation()` mixin** — `users.with(deactivation())` adds
+  `deactivatedAt` + `deactivatedBy` (→ `actors`) and pulls `audit()`
+  transitively. It's a pure schema mixin — no `plugins[]` entry.
+- **Visible-but-locked-out** — set `deactivatedAt` with a normal
+  `ctx.store.update`. The row STAYS in the table and remains queryable; the
+  convention is that your auth layer refuses to authenticate a subject whose
+  `deactivatedAt` is set. This is the deliberate **opposite of
+  `softDelete()`**, which hides + anonymises the row (its `defaultWhere`
+  filters deleted rows out of every read).
+
+## Try it
+
+```bash
+# create a user, then read it (deactivatedAt is null):
+ID=$(curl -s localhost:4000/_voltro/inspect/invoke -H 'content-type: application/json' \
+  -d '{"tag":"users.create","input":{"email":"ada@acme.com","name":"Ada"}}' | python3 -c 'import sys,json;print(json.load(sys.stdin)["result"]["id"])')
+curl -s localhost:4000/_voltro/inspect/invoke -H 'content-type: application/json' \
+  -d "{\"tag\":\"users.get\",\"input\":{\"id\":\"$ID\"}}"
+# → { ok:true, result:{ …, deactivatedAt:null } }
+
+# deactivate, then read AGAIN — still there, now stamped:
+curl -s localhost:4000/_voltro/inspect/invoke -H 'content-type: application/json' \
+  -d "{\"tag\":\"users.deactivate\",\"input\":{\"id\":\"$ID\"}}" >/dev/null
+curl -s localhost:4000/_voltro/inspect/invoke -H 'content-type: application/json' \
+  -d "{\"tag\":\"users.get\",\"input\":{\"id\":\"$ID\"}}"
+# → { ok:true, result:{ …, deactivatedAt:"2026-…" } }   (NOT null → still visible)
+```
+
+## Full user lifecycle
+
+Compose the lifecycle mixins for the complete column set:
+`users.with(audit(), softDelete(), deactivation())` — who/when (audit),
+hidden+anonymised on delete (softDelete), and visible-but-locked-out
+(deactivation).

package/templates/apps/api-backend-deactivation/actions/users.get.action.server.ts

@@ -0,0 +1,17 @@
+import type { AppContext } from '@voltro/runtime'
+import { eq } from '@voltro/database'
+import { database } from '../database/schema'
+
+const execute = async (input: { id: string }, ctx: AppContext) => {
+  const rows = await ctx.store.query(database.users.where(eq('id', input.id)).descriptor)
+  const u = rows[0]
+  if (!u) return null
+  return {
+    id: u['id'] as string,
+    email: u['email'] as string,
+    name: u['name'] as string,
+    deactivatedAt: (u['deactivatedAt'] as Date | null) ?? null,
+  }
+}
+
+export default execute

package/templates/apps/api-backend-deactivation/actions/users.get.action.ts

@@ -0,0 +1,18 @@
+// Reads one user by id — including a deactivated one. This is the whole point
+// of deactivation() vs softDelete(): after deactivation the row is STILL here
+// and readable, just stamped with `deactivatedAt`. (softDelete() would make
+// this return null.)
+
+import { defineAction } from '@voltro/protocol'
+import { Schema } from 'effect'
+
+export const getUser = defineAction({
+  name: 'users.get',
+  input: Schema.Struct({ id: Schema.String }),
+  output: Schema.NullOr(Schema.Struct({
+    id: Schema.String,
+    email: Schema.String,
+    name: Schema.String,
+    deactivatedAt: Schema.NullOr(Schema.Date),
+  })),
+})

package/templates/apps/api-backend-deactivation/app.config.ts

@@ -0,0 +1,20 @@
+// Backend for the {{projectName}} project demonstrating the `deactivation()`
+// schema mixin.
+//
+// deactivation() is a pure SCHEMA mixin (no plugins[] entry) — it adds
+// `deactivatedAt` + `deactivatedBy` columns. A deactivated subject can't
+// authenticate, but its row stays VISIBLE and queryable: no read-scoping, no
+// delete interception. That's the deliberate opposite of softDelete(), which
+// HIDES + anonymises. Set `deactivatedAt` with a normal `ctx.store.update`.
+import { defineEnv, envVar } from '@voltro/env'
+
+export const env = defineEnv({
+  LOG_LEVEL: envVar.enum(['debug', 'info', 'warn', 'error'], { access: 'public', default: 'info' }),
+})
+
+export default {
+  type:  'api' as const,
+  name:  '{{capProjectName}}{{capAppName}}',
+  store: 'memory' as const,
+  env,
+}

package/templates/apps/api-backend-deactivation/database/schema.ts

@@ -0,0 +1,41 @@
+// Schema for the {{projectName}} backend — a `users` table with the
+// `deactivation()` mixin. `actors` + `tenants` are the framework core tables.
+
+import {
+  databaseHandle,
+  id,
+  table,
+  text,
+  timestamp,
+  type InferRow,
+} from '@voltro/database'
+import { deactivation } from '@voltro/plugin-deactivation'
+
+export const actors = table('actors', {
+  id:          id(),
+  kind:        text().oneOf(['user', 'serviceAccount', 'apiKey', 'system']),
+  displayName: text().nullable(),
+  createdAt:   timestamp().default('now'),
+})
+
+export const tenants = table('tenants', {
+  id:        id(),
+  name:      text(),
+  createdAt: timestamp().default('now'),
+})
+
+export const users = table('users', {
+  id:    id(),
+  email: text().unique(),
+  name:  text(),
+})
+  // deactivation() adds deactivatedAt + deactivatedBy (→ actors) and pulls
+  // audit() transitively (createdAt/updatedAt/createdBy/updatedBy). NOTE: no
+  // defaultWhere — a deactivated user still shows up in queries, unlike
+  // softDelete() which would hide it.
+  .with(deactivation())
+  .reactive()
+
+export type User = InferRow<typeof users>
+
+export const database = databaseHandle({ actors, tenants, users })

package/templates/apps/api-backend-deactivation/mutations/users.create.mutation.server.ts

@@ -0,0 +1,6 @@
+import type { AppContext } from '@voltro/runtime'
+
+const execute = async (input: { email: string; name: string }, ctx: AppContext) =>
+  ctx.store.insert('users', { email: input.email, name: input.name })
+
+export default execute

package/templates/apps/api-backend-deactivation/mutations/users.create.mutation.ts

@@ -0,0 +1,16 @@
+import { defineMutation } from '@voltro/protocol'
+import { Schema } from 'effect'
+
+export const createUser = defineMutation({
+  name: 'users.create',
+  target: { table: 'users', op: 'insert' },
+  input: Schema.Struct({
+    email: Schema.NonEmptyString,
+    name: Schema.String,
+  }),
+  output: Schema.Struct({
+    id: Schema.String,
+    email: Schema.String,
+    name: Schema.String,
+  }),
+})

package/templates/apps/api-backend-deactivation/mutations/users.deactivate.mutation.server.ts

@@ -0,0 +1,10 @@
+import type { AppContext } from '@voltro/runtime'
+
+const execute = async (input: { id: string }, ctx: AppContext) => {
+  // A plain update — set the timestamp. audit() stamps updatedAt/updatedBy.
+  const row = await ctx.store.update('users', input.id, { deactivatedAt: new Date() })
+  if (row === null) throw { status: 404, message: `user ${input.id} not found` }
+  return row
+}
+
+export default execute

package/templates/apps/api-backend-deactivation/mutations/users.deactivate.mutation.ts

@@ -0,0 +1,19 @@
+// Deactivates a user — sets `deactivatedAt` with a normal update. The user's
+// row stays in the table and remains visible to queries; the convention is
+// that your auth layer refuses to authenticate a subject whose `deactivatedAt`
+// is set. (Contrast softDelete(), which hides + anonymises the row.)
+
+import { defineMutation } from '@voltro/protocol'
+import { Schema } from 'effect'
+
+export const deactivateUser = defineMutation({
+  name: 'users.deactivate',
+  target: { table: 'users', op: 'update' },
+  input: Schema.Struct({ id: Schema.String }),
+  output: Schema.Struct({
+    id: Schema.String,
+    email: Schema.String,
+    name: Schema.String,
+    deactivatedAt: Schema.NullOr(Schema.Date),
+  }),
+})

package/templates/apps/api-backend-deactivation/package.json

@@ -0,0 +1,28 @@
+{
+  "name": "@{{projectName}}/{{appName}}",
+  "version": "0.0.0",
+  "private": true,
+  "type": "module",
+  "scripts": {
+    "dev": "voltro dev .",
+    "migrate": "voltro migrate",
+    "test": "voltro test",
+    "typecheck": "tsc --noEmit"
+  },
+  "dependencies": {
+    "@effect/platform": "^0.96.1",
+    "@effect/rpc": "^0.75.1",
+    "@voltro/cli": "0.1.0",
+    "@voltro/database": "0.1.0",
+    "@voltro/env": "0.1.0",
+    "@voltro/plugin-deactivation": "0.1.0",
+    "@voltro/protocol": "0.1.0",
+    "@voltro/runtime": "0.1.0",
+    "effect": "^3.21.2"
+  },
+  "devDependencies": {
+    "@voltro/testing": "0.1.0",
+    "typescript": "^5.7.0",
+    "vitest": "^3.0.0"
+  }
+}

package/templates/apps/api-backend-deactivation/template.json

@@ -0,0 +1,6 @@
+{
+  "id": "api-backend-deactivation",
+  "kind": "api",
+  "summary": "The deactivation() schema mixin — adds deactivatedAt/deactivatedBy so a user can be locked out (your auth refuses a deactivated subject) while its row stays VISIBLE and queryable. The deliberate opposite of softDelete(), which hides + anonymises. Pure schema, zero infra.",
+  "tags": ["api", "deactivation", "user-lifecycle", "schema-mixin", "soft-delete"]
+}

package/templates/apps/api-backend-deactivation/tests/users.deactivate.test.ts

@@ -0,0 +1,47 @@
+// Unit test with `@voltro/testing` — no database, no running server. Importing
+// `../database/schema` registers the `users` / `actors` / `tenants` tables
+// globally, so `makeTestContext` auto-wires them into the in-memory store.
+// `ctx.store` is the SAME mixin-wrapped store the handlers get in production,
+// so the `deactivation()` mixin columns behave exactly as at runtime.
+//
+// The POINT of this template: `deactivation()` is a columns-only mixin (adds
+// `deactivatedAt` / `deactivatedBy`) with NO read scoping — a deactivated row
+// stays fully VISIBLE, the deliberate opposite of `softDelete()`. These tests
+// assert exactly that. Run with `voltro test` (vitest).
+
+import { describe, it, expect } from 'vitest'
+import { makeTestContext, mockStore } from '@voltro/testing'
+import { database } from '../database/schema' // registers users / actors / tenants
+import createUser from '../mutations/users.create.mutation.server'
+import deactivateUser from '../mutations/users.deactivate.mutation.server'
+
+const subject = { type: 'user' as const, id: 'user_1', tenantId: null }
+
+describe('users.create', () => {
+  it('inserts a user with an auto-injected id and no deactivation timestamp', async () => {
+    const ctx = makeTestContext({ subject, store: mockStore({ users: [] }) })
+    const row = await createUser({ email: 'ada@example.com', name: 'Ada' }, ctx)
+
+    expect(row['email']).toBe('ada@example.com')
+    expect(row['name']).toBe('Ada')
+    expect(row['id']).toBeTruthy()          // TypeID auto-injected from id()
+    expect(row['deactivatedAt'] ?? null).toBeNull() // active on creation
+  })
+})
+
+describe('users.deactivate', () => {
+  it('stamps deactivatedAt — and the row STAYS visible (unlike softDelete)', async () => {
+    const ctx = makeTestContext({ subject, store: mockStore({ users: [] }) })
+    const created = await createUser({ email: 'grace@example.com', name: 'Grace' }, ctx)
+
+    const updated = await deactivateUser({ id: String(created['id']) }, ctx)
+    expect(updated['deactivatedAt']).toBeInstanceOf(Date)
+
+    // deactivation() adds no defaultWhere, so a plain query still returns the
+    // deactivated row — this is the mixin's whole contract.
+    const rows = await ctx.store.query(database.users.descriptor)
+    expect(rows).toHaveLength(1)
+    expect(String(rows[0]!['id'])).toBe(String(created['id']))
+    expect(rows[0]!['deactivatedAt']).toBeInstanceOf(Date)
+  })
+})

package/templates/apps/api-backend-deactivation/tsconfig.json

@@ -0,0 +1,5 @@
+{
+  "extends": "../../../tsconfig.base.json",
+  "include": ["**/*.ts", "**/*.tsx"],
+  "exclude": ["node_modules", "dist"]
+}

package/templates/apps/api-backend-mail/README.md

@@ -0,0 +1,39 @@
+# {{projectName}} / {{appName}}
+
+Voltro backend scaffold (template: **api-backend-mail**).
+
+## Boot
+
+```bash
+pnpm install                # at the repo root
+pnpm --filter @{{projectName}}/{{appName}} dev
+# → http://localhost:4000
+# → ws://localhost:4000/ws
+```
+
+## What's in here
+
+| File | Role |
+|---|---|
+| `app.config.ts`                          | App declaration + `mailPlugin` wired (`console` provider). |
+| `database/schema.ts`                     | One example table (`notes`) with the `tenant()` mixin. |
+| `queries/` + `mutations/`                | Streaming subscription + tenant-guarded mutation examples. |
+| `emails/welcome.email.tsx`               | A React-Email welcome template (edit/replace freely). |
+| `actions/sendWelcome.{rpc,handler}.ts`   | `mail.sendWelcome` — sends the welcome template. |
+
+## Mail
+
+Transactional email is wired out of the box via `@voltro/plugin-mail`:
+
+- **Preview** templates in the dashboard's **Mail** tab (props box
+  pre-fills from each template's `preview`).
+- **Send** with the `mail.sendWelcome` action, or `yield* MailService`
+  + `mail.send({ template: 'welcome', props })` from any handler.
+- The default `console` provider just **logs** the mail (zero-config, no
+  API key) and captures it in the dashboard outbox. For real delivery,
+  switch `provider` in `app.config.ts` to `'resend'` / `'postmark'` /
+  `'sendgrid'` / `'smtp'` and set the matching env var (e.g.
+  `RESEND_API_KEY`).
+
+Drop more `*.email.tsx`, `*.query.ts` + `*.query.server.ts`, `*.mutation.ts` + `*.mutation.server.ts`, `*.action.ts` + `*.action.server.ts`, or `*.stream.ts` + `*.stream.server.ts`, or `*.workflow.tsx`
+files anywhere in this tree — discovery is by file convention.

package/templates/apps/api-backend-mail/actions/sendWelcome.action.server.ts

@@ -0,0 +1,15 @@
+import { Effect } from 'effect'
+import { MailService } from '@voltro/plugin-mail'
+
+const execute = (input: { email: string; name: string }) =>
+  Effect.gen(function* () {
+    const mail = yield* MailService
+    const res = yield* mail.send({
+      to: input.email,
+      template: 'welcome',
+      props: { name: input.name },
+    })
+    return { id: res.id, provider: res.provider }
+  })
+
+export default execute

package/templates/apps/api-backend-mail/actions/sendWelcome.action.ts

@@ -0,0 +1,21 @@
+// `mail.sendWelcome` — example action that sends the `welcome` template
+// via @voltro/plugin-mail. With the `console` provider nothing leaves the
+// process — the send is logged + captured in the dev outbox (dashboard
+// Mail panel). Swap the provider in app.config.ts for real delivery.
+//
+// Email is external I/O → an action, not a mutation.
+
+import { Schema } from 'effect'
+import { defineAction } from '@voltro/protocol'
+
+export const sendWelcome = defineAction({
+  name: 'mail.sendWelcome',
+  input: Schema.Struct({
+    email: Schema.String,
+    name: Schema.String,
+  }),
+  output: Schema.Struct({
+    id: Schema.String,
+    provider: Schema.String,
+  }),
+})

package/templates/apps/api-backend-mail/app.config.ts

@@ -0,0 +1,34 @@
+// Backend app for the {{projectName}} project. Read by `voltro dev`.
+//
+// `store: 'memory'` is the dev-friendly default — fast startup, no
+// docker. Switch to `'postgres'` when you wire `docker compose up`
+// from the repo root.
+//
+// This variant ships transactional email out of the box via
+// `@voltro/plugin-mail`. The `console` provider just logs what would be
+// sent (zero-config, no API key) — swap to `'resend'` / `'postmark'` /
+// `'sendgrid'` / `'smtp'` (+ the matching env var, e.g. RESEND_API_KEY)
+// for real delivery. Templates live in `emails/*.email.tsx`; preview +
+// send them from the dashboard's Mail tab.
+import { defineEnv, envVar } from '@voltro/env'
+import { mailPlugin } from '@voltro/plugin-mail'
+
+// Typed environment — declare your env once; it's validated at boot (fail-fast)
+// and read on the server via `serverEnv` / `getSecret` from '@voltro/env/server'.
+// `access` is required: 'public' (browser-safe) or 'secret' (server-only, never
+// bundled). Run `voltro env` to see the manifest. See the Environment docs.
+export const env = defineEnv({
+  LOG_LEVEL: envVar.enum(['debug', 'info', 'warn', 'error'], { access: 'public', default: 'info' }),
+  // Add your own, e.g.:
+  //   STRIPE_KEY: envVar.string({ access: 'secret' }),
+})
+
+export default {
+  type:  'api' as const,
+  name:  '{{projectNamePascal}}{{appNamePascal}}',
+  store: 'memory' as const,
+  env,
+  plugins: [
+    mailPlugin({ provider: 'console', from: '{{projectNamePascal}} <hello@example.com>' }),
+  ],
+}

package/templates/apps/api-backend-mail/database/schema.ts

@@ -0,0 +1,57 @@
+// Schema for the {{projectName}} backend.
+//
+// Tables are auto-discovered: every exported `table(...)` in this file
+// (or any `*.entity.ts` / `*.schema.ts` file) is registered by
+// `voltro dev` — no manual barrel. `actors` + `tenants` are the
+// framework's core tables: the built-in `audit()` / `tenant()` /
+// `softDelete()` mixins reference them, so they must be declared (the
+// CLI wires them into the mixin registry once it finds them).
+//
+// Add the `tenant()` mixin to a table to make it tenant-scoped — the
+// runtime AND-merges `eq('tenantId', subject.tenantId)` into every
+// subscription predicate, so cross-tenant reads can't leak.
+
+import {
+  boolean,
+  databaseHandle,
+  id,
+  table,
+  text,
+  timestamp,
+  type InferRow,
+} from '@voltro/database'
+import { tenant } from '@voltro/plugin-multitenancy'
+
+// ---------- Core tables (required by the audit / tenant mixins) ----------
+
+export const actors = table('actors', {
+  id:          id(),
+  kind:        text().oneOf(['user', 'serviceAccount', 'apiKey', 'system']),
+  displayName: text().nullable(),
+  createdAt:   timestamp().default('now'),
+})
+
+export const tenants = table('tenants', {
+  id:        id(),
+  name:      text(),
+  createdAt: timestamp().default('now'),
+})
+
+// ---------- Application tables — rename / replace with your own ----------
+
+export const notes = table('notes', {
+  id:    id({ prefix: 'note' }),
+  title: text(),
+  body:  text(),
+  done:  boolean().default(false),
+})
+  // tenant() pulls audit() transitively → adds tenantId + createdAt /
+  // updatedAt / createdBy / updatedBy (auto-stamped by the runtime).
+  .with(tenant())
+  // Opt into the matcher engine: subscriptions against `notes` get a
+  // fresh snapshot/delta whenever a mutation writes the table.
+  .reactive()
+
+export type Note = InferRow<typeof notes>
+
+export const database = databaseHandle({ actors, tenants, notes })

package/templates/apps/api-backend-mail/emails/welcome.email.tsx

@@ -0,0 +1,106 @@
+// Default transactional email — a clean, ready-to-send welcome built with
+// @react-email/components. Auto-discovered by `voltro dev` and registered
+// with @voltro/plugin-mail, so `mail.send({ template: 'welcome', props })`
+// works + the dashboard Mail panel previews it.
+//
+// This is a STARTER you replace: swap the copy, colours, and layout for
+// your brand. The component kit (Container / Section / Button / …) handles
+// the email-client quirks so it renders consistently across Gmail/Outlook/
+// Apple Mail. Plain JSX tags also work if you'd rather not use the kit.
+//
+// Light + dark: inline styles are the LIGHT defaults; the <style> block in
+// <Head> overrides colours when the client is in dark mode
+// (`prefers-color-scheme`) — and, for the dashboard preview's Light/Dark
+// switch, when an ancestor carries `[data-theme="dark"]`. `!important`
+// beats the inline light values. Clients that strip <style> (older Outlook)
+// just stay light.
+
+import { defineEmail } from '@voltro/plugin-mail'
+import {
+  Body,
+  Button,
+  Container,
+  Head,
+  Heading,
+  Hr,
+  Html,
+  Preview,
+  Section,
+  Text,
+} from '@react-email/components'
+import { Schema } from 'effect'
+
+// Your product/brand name. Defaults to the project name; edit freely.
+const BRAND = '{{projectNamePascal}}'
+
+const darkCss = `
+.e-body { background-color: #f4f4f5; }
+@media (prefers-color-scheme: dark) {
+  .e-body { background-color: #0a0a0a !important; }
+  .e-card { background-color: #18181b !important; border-color: #27272a !important; }
+  .e-heading { color: #fafafa !important; }
+  .e-text { color: #d4d4d8 !important; }
+  .e-footer { color: #a1a1aa !important; }
+}
+[data-theme="dark"] .e-body { background-color: #0a0a0a !important; }
+[data-theme="dark"] .e-card { background-color: #18181b !important; border-color: #27272a !important; }
+[data-theme="dark"] .e-heading { color: #fafafa !important; }
+[data-theme="dark"] .e-text { color: #d4d4d8 !important; }
+[data-theme="dark"] .e-footer { color: #a1a1aa !important; }
+[data-theme="light"] .e-body { background-color: #f4f4f5 !important; }
+[data-theme="light"] .e-card { background-color: #ffffff !important; border-color: #e4e4e7 !important; }
+[data-theme="light"] .e-heading { color: #18181b !important; }
+[data-theme="light"] .e-text { color: #3f3f46 !important; }
+[data-theme="light"] .e-footer { color: #a1a1aa !important; }
+`
+
+const styles = {
+  // No backgroundColor here on purpose — react-email copies the Body inline
+  // style onto an inner wrapper <td>, which would then keep the light bg even
+  // in dark mode. The body bg lives in the `.e-body` class (light + dark) so
+  // a single rule controls it. (margin/padding/font stay inline.)
+  body: { fontFamily: 'ui-sans-serif, system-ui, -apple-system, Segoe UI, Roboto, sans-serif', margin: 0, padding: '32px 0' },
+  container: { backgroundColor: '#ffffff', borderRadius: '12px', maxWidth: '480px', margin: '0 auto', padding: '40px', border: '1px solid #e4e4e7' },
+  heading: { fontSize: '22px', fontWeight: 700, color: '#18181b', margin: '0 0 16px' },
+  text: { fontSize: '15px', lineHeight: '24px', color: '#3f3f46', margin: '0 0 16px' },
+  button: { backgroundColor: '#6d28d9', color: '#ffffff', borderRadius: '8px', fontSize: '15px', fontWeight: 600, textDecoration: 'none', padding: '12px 20px', display: 'inline-block' },
+  hr: { borderColor: '#e4e4e7', margin: '28px 0' },
+  footer: { fontSize: '13px', lineHeight: '20px', color: '#a1a1aa', margin: 0 },
+} as const
+
+export const welcome = defineEmail({
+  name: 'welcome',
+  props: Schema.Struct({ name: Schema.String }),
+  // Realistic example props — the dashboard preview box pre-fills with this.
+  preview: { name: 'Mario' },
+  subject: (p) => `Welcome to ${BRAND}, ${p.name}!`,
+  render: (p) => (
+    <Html>
+      <Head>
+        <meta name="color-scheme" content="light dark" />
+        <meta name="supported-color-schemes" content="light dark" />
+        <style dangerouslySetInnerHTML={{ __html: darkCss }} />
+      </Head>
+      <Preview>Your {BRAND} account is ready — let's get you started.</Preview>
+      <Body className="e-body" style={styles.body}>
+        <Container className="e-card" style={styles.container}>
+          <Heading className="e-heading" style={styles.heading}>Welcome, {p.name} 👋</Heading>
+          <Text className="e-text" style={styles.text}>
+            Thanks for joining {BRAND}. Your workspace is ready — jump in and
+            create your first project whenever you're set.
+          </Text>
+          <Section>
+            <Button href="https://example.com/dashboard" style={styles.button}>
+              Open your dashboard
+            </Button>
+          </Section>
+          <Hr style={styles.hr} />
+          <Text className="e-footer" style={styles.footer}>
+            You're receiving this because you signed up for {BRAND}. If this
+            wasn't you, just ignore this email.
+          </Text>
+        </Container>
+      </Body>
+    </Html>
+  ),
+})

package/templates/apps/api-backend-mail/mutations/notes.create.mutation.server.ts

@@ -0,0 +1,19 @@
+import { assertOwnTenant } from '@voltro/plugin-multitenancy/guard'
+import type { AppContext } from '@voltro/runtime'
+
+const execute = async (
+  input: { tenantId: string; title: string; body: string },
+  ctx: AppContext,
+) => {
+  assertOwnTenant(input.tenantId, ctx.request.subject)
+  // Framework auto-injects a `note_…` id from the table's id() decl.
+  return ctx.store.insert('notes', {
+    title: input.title,
+    body: input.body,
+    done: false,
+    tenantId: input.tenantId,
+    createdAt: new Date(),
+  })
+}
+
+export default execute

package/templates/apps/api-backend-mail/mutations/notes.create.mutation.ts

@@ -0,0 +1,37 @@
+// Creates a note. The handler's `assertOwnTenant` guard rejects
+// cross-tenant spoofing — input.tenantId MUST match the resolved
+// subject's tenantId, else the rpc layer surfaces a typed
+// `TenantMismatch` error.
+
+import { defineMutation } from '@voltro/protocol'
+import { TenantMismatch } from '@voltro/plugin-multitenancy/guard'
+import { Schema } from 'effect'
+
+export const createNote = defineMutation({
+  name: 'notes.create',
+  target: {
+    table: 'notes',
+    op: 'insert',
+    shape: (input: { tenantId: string; title: string; body: string }) => ({
+      title: input.title,
+      body: input.body,
+      done: false,
+      tenantId: input.tenantId,
+      createdAt: new Date(),
+    }),
+  },
+  input: Schema.Struct({
+    tenantId: Schema.String,
+    title: Schema.NonEmptyString,
+    body: Schema.String,
+  }),
+  output: Schema.Struct({
+    id: Schema.String,
+    title: Schema.String,
+    body: Schema.String,
+    done: Schema.Boolean,
+    tenantId: Schema.String,
+    createdAt: Schema.Date,
+  }),
+  error: TenantMismatch,
+})