cli templates

optional starter files only — not the core product. the product path is briven setup for a new cloud project, or briven connect p_… for an existing one. pass --template on setup when you want a sample schema/functions layout.

# new cloud project + sample files
briven setup --name my-app --template=todo-app
briven deploy

# existing project — attach first, templates are optional later
briven connect p_…
# or local files only: briven init --template=todo-app

pass briven init --list-templates to print available names without scaffolding. full connect flow: connect.

`blank`

kick the tyres

one table (notes), one reactive query. the smallest valid briven project — useful when you just want to see the deploy / invoke loop work end-to-end before you commit to a real model.

1 table
1 reactive query
0 mutations

briven/
├── schema.ts               # 1 table: notes
└── functions/
    └── listNotes.ts        # 1 reactive query

mkdir my-app && cd my-app
briven setup --name my-app --template=blank
briven deploy

`todo-app`

canonical hello-world

classic todo list. 4 mutations covering create / toggle / rename / delete, 1 reactive query with a filter argument (open / done / all). matches the live demo at briven.tech/demo (when phase 4 lands).

1 table
1 query (with args)
4 mutations
input validation

briven/
├── schema.ts               # 1 table: todos
└── functions/
    ├── listTodos.ts        # reactive query with ?filter=open|done|all
    ├── createTodo.ts       # mutation: validates body length, ulid id
    ├── toggleTodo.ts       # mutation: flips done + sets completedAt
    ├── renameTodo.ts       # mutation: body replace
    └── deleteTodo.ts       # mutation: hard delete by id

mkdir my-app && cd my-app
briven setup --name my-app --template=todo-app
briven deploy

`chat`

real-time multi-room

rooms + messages with a per-room reactive query. shows how to use a foreign key + leading-column index to scope realtime fan-out to one room per subscriber. ulid ids, server-side timestamps.

2 tables with FK
per-room realtime
2 queries
2 mutations

briven/
├── schema.ts               # 2 tables: rooms, messages (FK)
└── functions/
    ├── listRooms.ts        # reactive query
    ├── createRoom.ts       # mutation
    ├── listMessages.ts     # reactive query, args: { roomId }
    └── postMessage.ts      # mutation, args: { roomId, body }

mkdir my-app && cd my-app
briven setup --name my-app --template=chat
briven deploy

`convex-notes`

familiar to convex users

multi-user notes with per-owner reactive listing + optional tag filter — mirrors the canonical convex notes-app shape. ownership is enforced inside each mutation as an explicit guard, not via row-level policy. comes pre-wired so a convex user sees their mental model land 1:1.

multi-user
per-owner realtime
ownership guards
tag filter

briven/
├── schema.ts               # 1 table: notes (owner-scoped)
└── functions/
    ├── listNotes.ts        # reactive query, args: { ownerId, tag? }
    ├── createNote.ts       # mutation
    ├── updateNote.ts       # mutation with ownership guard
    └── deleteNote.ts       # mutation with ownership guard

mkdir my-app && cd my-app
briven setup --name my-app --template=convex-notes
briven deploy

`supabase-auth-todos`

familiar to supabase users

auth-scoped todo list. every function reads ctx.session.userId and applies the same scoping supabase would do via row-level security — except the predicate lives in code, where you can read it and debug it. paste this to translate `auth.uid() = user_id` into briven's model.

auth-aware
RLS → guards
1 query
3 mutations

briven/
├── schema.ts               # 1 table: todos (user_id-scoped)
└── functions/
    ├── myTodos.ts          # reactive query, uses ctx.session.userId
    ├── createTodo.ts       # mutation, inserts with userId
    ├── toggleTodo.ts       # mutation with ownership guard
    └── deleteTodo.ts       # mutation with ownership guard

mkdir my-app && cd my-app
briven setup --name my-app --template=supabase-auth-todos
briven deploy