ac-framework 2.2.0 → 2.4.0

package/framework/mobile_development/.gemini/commands/opsx/ac.md

@@ -67,6 +67,12 @@ If you attempt to proceed without completing a required step, you MUST STOP and
 | `sync-index` | Keep project index and generated guidance synchronized with implementation. | Documentation sync | `openspec-apply-change` |
 | `changelog-generator` | Create user-facing release notes from implementation changes. | Release communication | `openspec-archive-change` |
 
+### Security Validation Skills
+
+| Skill | Description | Primary Use | Required Before |
+|-------|-------------|-------------|-----------------|
+| `vibe-security` | Final security audit for AI-generated/vibe-coded risks (exposed keys, broken access control, auth/payment/data validation gaps). | Final security validation before closure | `openspec-archive-change` |
+
 ---
 
 ## Persistent Memory Protocol (Mandatory)
@@ -97,81 +103,74 @@ The AC Framework includes a persistent memory system that agents must use proact
 
 If SynapseGrid is enabled in `acfm init`, AC Framework installs the collaborative MCP server automatically for detected assistants.
 
+**When to delegate to SynapseGrid:**
+- Multi-step features with architecture + implementation + review work
+- Tasks requiring critical analysis before coding (security, API contracts, refactors)
+- Long-running work where transcript, artifacts, and resumability are important
+- Situations where one assistant would benefit from role-based challenge/review
+
+**Role delegation model (what each agent does best):**
+- `planner`: breaks down scope, constraints, approach, acceptance criteria
+- `critic`: challenges assumptions, finds risks/blind spots, proposes safer alternatives
+- `coder`: implements code and applies concrete changes
+- `reviewer`: validates quality, consistency with spec/tasks, and production readiness
+
 **Session-start requirement when collaboration is enabled:**
-1. Prefer the available SynapseGrid MCP tools for collaborative session control before falling back to direct CLI.
-2. Use shared session state and transcript as the source of truth for role-by-role collaboration.
-3. If collaborative MCP is unavailable, use CLI fallback commands and keep behavior equivalent.
-
-**How to use SynapseGrid collaboration:**
-```text
-Preferred: use SynapseGrid MCP tools (ac-framework-collab) for start/status/step/resume/stop.
-Fallback: use AC Framework agents CLI commands directly.
-```
+1. Prefer SynapseGrid MCP tools for start/wait/result/cancel/status flows.
+2. Use transcript + meeting summary + artifacts as source of truth.
+3. If collaborative MCP is unavailable, use equivalent CLI commands.
+
+**Preferred MCP flow (recommended):**
+1. `collab_start_session`
+2. `collab_invoke_team`
+3. `collab_wait_run`
+4. `collab_get_result`
+5. Optional diagnostics: `collab_get_transcript`, `collab_get_meeting_log`, `collab_status`
+
+**CLI fallback and operations:**
 ```bash
-# Install/update collaborative MCP server integrations
-acfm agents install-mcps
-
-# Start collaborative runtime with visible 4-pane tmux war-room
-acfm agents start --task "design and implement feature X" --attach --model-coder provider/model
+# Setup/runtime
+acfm agents setup
+acfm agents runtime install-zellij
+acfm agents runtime set auto
+acfm agents doctor --verbose
 
-# If already running in background, attach to panes and inspect logs
+# Start/run
+acfm agents start --task "design and implement feature X" --mux auto
 acfm agents live
-acfm agents logs --role all --lines 120
+acfm agents status
 
-# Resume/list/export operations
-acfm agents resume
-acfm agents list
+# Visibility and artifacts
+acfm agents transcript --role all --limit 80
+acfm agents summary
+acfm agents artifacts --watch --interval 1200
 acfm agents export --format md --out synapse-session.md
 
-# Fast diagnostics for OpenCode resolution errors
-acfm agents setup
-```
-
-**Troubleshooting notes:**
-- If transcript shows `Agent failed: spawn opencode ENOENT`, run `acfm agents setup` and restart/resume session.
-- If session exists but panes are not visible, use `acfm agents live` (or `acfm agents attach`) or `tmux attach -t <session-name>`.
-- For MCP-first flows, ensure session start enables worker spawning so tmux panes are created.
-- Per-role models can be set at start (`--model-planner`, `--model-critic`, `--model-coder`, `--model-reviewer`) or persisted via `acfm agents model set`.
+# Model management
+acfm agents model list
+acfm agents model choose
+acfm agents model set --role coder provider/model
 
-## SynapseGrid Collaborative MCP Protocol (Optional)
-
-If SynapseGrid is enabled in `acfm init`, AC Framework installs the collaborative MCP server automatically for detected assistants.
-
-**Session-start requirement when collaboration is enabled:**
-1. Prefer the available SynapseGrid MCP tools for collaborative session control before falling back to direct CLI.
-2. Use shared session state and transcript as the source of truth for role-by-role collaboration.
-3. If collaborative MCP is unavailable, use CLI fallback commands and keep behavior equivalent.
-
-**How to use SynapseGrid collaboration:**
-```text
-Preferred: use SynapseGrid MCP tools (ac-framework-collab) for start/status/step/resume/stop.
-Fallback: use AC Framework agents CLI commands directly.
+# Lifecycle
+acfm agents resume
+acfm agents stop
 ```
-```bash
-# Install/update collaborative MCP server integrations
-acfm agents install-mcps
 
-# Start collaborative runtime with visible 4-pane tmux war-room
-acfm agents start --task "design and implement feature X" --attach --model-coder provider/model
+**Collaboration artifacts (deterministic, not prompt-dependent):**
+- `~/.acfm/synapsegrid/<sessionId>/transcript.jsonl`
+- `~/.acfm/synapsegrid/<sessionId>/meeting-log.md`
+- `~/.acfm/synapsegrid/<sessionId>/meeting-summary.md`
+- `~/.acfm/synapsegrid/<sessionId>/turns/*.json`
+- `~/.acfm/synapsegrid/<sessionId>/turns/raw/*.ndjson`
+- `~/.acfm/synapsegrid/<sessionId>/turns/raw/*.stderr.log`
+- `~/.acfm/synapsegrid/<sessionId>/diagnostics.json`
 
-# If already running in background, attach to panes and inspect logs
-acfm agents live
-acfm agents logs --role all --lines 120
-
-# Resume/list/export operations
-acfm agents resume
-acfm agents list
-acfm agents export --format md --out synapse-session.md
-
-# Fast diagnostics for OpenCode resolution errors
-acfm agents setup
-```
+**Troubleshooting and robust behavior:**
+- Use `acfm agents doctor --verbose` for capability probe diagnostics.
+- In `--mux auto`, runtime prefers zellij and falls back to tmux when zellij startup fails.
+- If model/provider errors appear, validate with `opencode auth list` and `opencode models`.
+- If workers are running but unclear, inspect `logs`, `transcript`, and `artifacts` before restarting.
 
-**Troubleshooting notes:**
-- If transcript shows `Agent failed: spawn opencode ENOENT`, run `acfm agents setup` and restart/resume session.
-- If session exists but panes are not visible, use `acfm agents live` (or `acfm agents attach`) or `tmux attach -t <session-name>`.
-- For MCP-first flows, ensure session start enables worker spawning so tmux panes are created.
-- Per-role models can be set at start (`--model-planner`, `--model-critic`, `--model-coder`, `--model-reviewer`) or persisted via `acfm agents model set`.
 
 ---
 
@@ -205,7 +204,7 @@ Before proceeding to next phase, verify outputs exist:
 | Phase 2 | exploration notes + platform/stack decision recorded | [ ] |
 | Phase 3 | `proposal.md`, `specs/`, `design.md`, `tasks.md` + `spec-analysis` review | [ ] |
 | Phase 4 | implementation done + tasks updated + issues debugged | [ ] |
-| Phase 5 | verification passed + docs/index synced + archive/sync complete | [ ] |
+| Phase 5 | verification passed + `vibe-security` audit complete + docs/index synced + archive/sync complete | [ ] |
 
 **Rule 4: Pre-Implementation Safety Check**
 Before `openspec-apply-change`, ALL must be TRUE:
@@ -285,11 +284,12 @@ When starting a mobile project **from scratch**, follow this **MANDATORY** workf
     v
   PHASE 5 - VALIDATION AND CLOSURE
     19) openspec-verify-change
-    20) documentation
-    21) sync-index
-    22) openspec-sync-specs [IF syncing specs without archive]
-    23) openspec-archive-change OR openspec-bulk-archive-change
-    24) changelog-generator
+    20) vibe-security (final security audit)
+    21) documentation
+    22) sync-index
+    23) openspec-sync-specs [IF syncing specs without archive]
+    24) openspec-archive-change OR openspec-bulk-archive-change
+    25) changelog-generator
 ```
 
 **Conditional Skill Notes:**
@@ -338,11 +338,12 @@ When working on an **existing mobile codebase** (feature, bugfix, refactor):
 
   PHASE 5 - VALIDATION AND CLOSURE
     16) openspec-verify-change
-    17) documentation
-    18) sync-index
-    19) openspec-sync-specs [if needed]
-    20) openspec-archive-change / openspec-bulk-archive-change
-    21) changelog-generator
+    17) vibe-security (final security audit)
+    18) documentation
+    19) sync-index
+    20) openspec-sync-specs [if needed]
+    21) openspec-archive-change / openspec-bulk-archive-change
+    22) changelog-generator
 ```
 
 ---

package/framework/mobile_development/.gemini/skills/sync-index/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: sync-index
-description: Keep project documentation (.agents/project-index.md and sub-skills) in sync with codebase changes.
+description: Keep project documentation (.agentss/project-index.md and sub-skills) in sync with codebase changes.
 ---
 
 # Documentation Sync

package/framework/mobile_development/.gemini/skills/vibe-security/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: vibe-security
+description: Audits codebases for common security vulnerabilities that AI coding assistants introduce in "vibe-coded" applications. Checks for exposed API keys, broken access control (Supabase RLS, Firebase rules), missing auth validation, client-side trust issues, insecure payment flows, and more. Use this skill whenever the user asks about security, wants a code review, mentions "vibe coding", or when you're writing or reviewing code that handles authentication, payments, database access, API keys, secrets, or user data — even if they don't explicitly mention security. Also trigger when the user says things like "is this safe?", "check my code", "audit this", "review for vulnerabilities", or "can someone hack this?".
+license: MIT
+metadata:
+  author: Chris Raroque
+  version: "1.0"
+---
+
+Audit code for security vulnerabilities commonly introduced by AI code generation. These issues are prevalent in "vibe-coded" apps — projects built rapidly with AI assistance where security fundamentals get skipped.
+
+AI assistants consistently get these patterns wrong, leading to real breaches, stolen API keys, and drained billing accounts. This skill exists to catch those mistakes before they ship.
+
+
+## The Core Principle
+
+Never trust the client. Every price, user ID, role, subscription status, feature flag, and rate limit counter must be validated or enforced server-side. If it exists only in the browser, mobile bundle, or request body, an attacker controls it.
+
+
+## Audit Process
+
+Examine the codebase systematically. For each step, load the relevant reference file only if the codebase uses that technology or pattern. Skip steps that aren't relevant.
+
+1. **Secrets & Environment Variables** — Scan for hardcoded API keys, tokens, or credentials. Check for secrets exposed via client-side env var prefixes (`NEXT_PUBLIC_`, `VITE_`, `EXPO_PUBLIC_`). Verify `.env` is in `.gitignore`. See `references/secrets-and-env.md`.
+
+2. **Database Access Control** — Check Supabase RLS policies, Firebase Security Rules, or Convex auth guards. This is the #1 source of critical vulnerabilities in vibe-coded apps. See `references/database-security.md`.
+
+3. **Authentication & Authorization** — Validate JWT handling, middleware auth, Server Action protection, and session management. See `references/authentication.md`.
+
+4. **Rate Limiting & Abuse Prevention** — Ensure auth endpoints, AI calls, and expensive operations have rate limits. Verify rate limit counters can't be tampered with. See `references/rate-limiting.md`.
+
+5. **Payment Security** — Check for client-side price manipulation, webhook signature verification, and subscription status validation. See `references/payments.md`.
+
+6. **Mobile Security** — Verify secure token storage, API key protection via backend proxy, and deep link validation. See `references/mobile.md`.
+
+7. **AI / LLM Integration** — Check for exposed AI API keys, missing usage caps, prompt injection vectors, and unsafe output rendering. See `references/ai-integration.md`.
+
+8. **Deployment Configuration** — Verify production settings, security headers, source map exposure, and environment separation. See `references/deployment.md`.
+
+9. **Data Access & Input Validation** — Check for SQL injection, ORM misuse, and missing input validation. See `references/data-access.md`.
+
+If doing a partial review or generating code in a specific area, load only the relevant reference files.
+
+
+## Core Instructions
+
+- Report only genuine security issues. Do not nitpick style or non-security concerns.
+- When multiple issues exist, prioritize by exploitability and real-world impact.
+- If the codebase doesn't use a particular technology (e.g., no Supabase), skip that section entirely.
+- When generating new code, consult the relevant reference files proactively to avoid introducing vulnerabilities in the first place.
+- If you find a critical issue (exposed secrets, disabled RLS, auth bypass), flag it immediately at the top of your response — don't bury it in a long list.
+
+
+## Output Format
+
+Organize findings by severity: **Critical** → **High** → **Medium** → **Low**.
+
+For each issue:
+1. State the file and relevant line(s).
+2. Name the vulnerability.
+3. Explain what an attacker could do (concrete impact, not abstract risk).
+4. Show a before/after code fix.
+
+Skip areas with no issues. End with a prioritized summary.
+
+### Example Output
+
+#### Critical
+
+**`lib/supabase.ts:3` — Supabase `service_role` key exposed in client bundle**
+
+The `service_role` key bypasses all Row-Level Security. Anyone can extract it from the browser bundle and read, modify, or delete every row in your database.
+
+```typescript
+// Before
+const supabase = createClient(url, process.env.NEXT_PUBLIC_SUPABASE_SERVICE_KEY!)
+
+// After — use the anon key client-side; service_role belongs only in server-side code
+const supabase = createClient(url, process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!)
+```
+
+#### High
+
+**`app/api/checkout/route.ts:15` — Price taken from client request body**
+
+An attacker can set any price (including $0.01) by modifying the request. Prices must be looked up server-side.
+
+```typescript
+// Before
+const session = await stripe.checkout.sessions.create({
+  line_items: [{ price_data: { unit_amount: req.body.price } }]
+})
+
+// After — look up the price server-side
+const product = await db.products.findUnique({ where: { id: req.body.productId } })
+const session = await stripe.checkout.sessions.create({
+  line_items: [{ price: product.stripePriceId }]
+})
+```
+
+### Summary
+
+1. **Service role key exposed (Critical):** Anyone can bypass all database security. Rotate the key immediately and move it to server-side only.
+2. **Client-controlled pricing (High):** Attackers can purchase at any price. Use server-side price lookup.
+
+
+## When Generating Code
+
+These rules also apply proactively. Before writing code that touches auth, payments, database access, API keys, or user data, consult the relevant reference file to avoid introducing the vulnerability in the first place. Prevention is better than detection.
+
+
+## References
+
+- `references/secrets-and-env.md` — API keys, tokens, environment variable configuration, and `.gitignore` rules.
+- `references/database-security.md` — Supabase RLS, Firebase Security Rules, and Convex auth patterns.
+- `references/authentication.md` — JWT verification, middleware, Server Actions, and session management.
+- `references/rate-limiting.md` — Rate limiting strategies and abuse prevention.
+- `references/payments.md` — Stripe security, webhook verification, and price validation.
+- `references/mobile.md` — React Native and Expo security: secure storage, API proxy, deep links.
+- `references/ai-integration.md` — LLM API key protection, usage caps, prompt injection, and output sanitization.
+- `references/deployment.md` — Production configuration, security headers, and environment separation.
+- `references/data-access.md` — SQL injection prevention, ORM safety, and input validation.

package/framework/mobile_development/.gemini/skills/vibe-security/agents/openai.yaml

@@ -0,0 +1,8 @@
+interface:
+  display_name: "Vibe Security"
+  short_description: "Audits vibe-coded apps for common security vulnerabilities."
+  brand_color: "#DC2626"
+  default_prompt: "Use $vibe-security to audit my project for security issues."
+
+policy:
+  allow_implicit_invocation: true

package/framework/mobile_development/.gemini/skills/vibe-security/references/ai-integration.md

@@ -0,0 +1,61 @@
+# AI / LLM Integration Security
+
+## API Keys Are Server-Side Only
+
+AI API keys (OpenAI, Anthropic, Google, etc.) must never appear in client-side code. They allow unlimited API usage at your expense. A leaked key can drain thousands of dollars in minutes.
+
+- No `NEXT_PUBLIC_OPENAI_API_KEY`
+- No API keys in React Native / Expo bundles
+- No API keys in client-side JavaScript
+
+All AI API calls go through your backend. The client sends the user's message to your server; your server calls the AI API.
+
+## Spending Caps
+
+Set hard spending caps on every AI API provider:
+- OpenAI: Usage limits in dashboard
+- Anthropic: Spending limits in console
+- Google: Budget alerts in Cloud Console
+
+Also implement **per-user usage limits** in your application:
+- Track token usage per user in your database
+- Set daily/monthly caps per user or per tier
+- Return a clear error when limits are exceeded
+- Don't rely on the AI provider's caps alone — they may have lag
+
+## Prompt Injection
+
+User input must be sanitized before inclusion in prompts. Never concatenate raw user input into system prompts:
+
+```typescript
+// BAD: user can override system instructions
+const prompt = `You are a helpful assistant. User says: ${userInput}`;
+
+// BETTER: separate system and user messages
+const messages = [
+  { role: 'system', content: 'You are a helpful assistant.' },
+  { role: 'user', content: userInput },
+];
+```
+
+Even with separate messages, be aware that sophisticated prompt injection can still occur. For high-stakes applications, consider:
+- Input validation and filtering
+- Output validation before acting on LLM responses
+- Limiting the LLM's capabilities (no tool access for user-facing chat)
+
+## LLM Output Is Untrusted
+
+LLM responses should be treated as untrusted user input:
+
+- **Sanitize before rendering as HTML** — LLM output can contain script tags or event handlers
+- **Never execute LLM output as code** without sandboxing
+- **Validate tool/function call parameters** — if using function calling, validate all returned parameters against an allowlist and schema before executing
+
+## Tool / Function Calling
+
+If your application gives an LLM access to tools (database queries, API calls, file operations):
+- Restrict operations to a safe allowlist
+- Validate all parameters from the LLM against a schema
+- Use least-privilege access (read-only where possible)
+- Log all tool invocations for audit
+- Never let the LLM construct raw SQL or shell commands from user input

package/framework/mobile_development/.gemini/skills/vibe-security/references/authentication.md

@@ -0,0 +1,90 @@
+# Authentication & Authorization
+
+## JWT Handling
+
+- **Use `jwt.verify()`, never `jwt.decode()` alone.** `decode` reads the payload without checking the signature — an attacker can forge any payload.
+- **Explicitly reject `"alg": "none"`.** Some JWT libraries accept unsigned tokens if the algorithm is set to `"none"`. Your verification must reject this.
+- **Validate issuer, audience, and expiration** — not just the signature.
+
+```typescript
+// BAD: reads token without verifying signature
+const payload = jwt.decode(token);
+
+// GOOD: verifies signature, rejects tampered tokens
+const payload = jwt.verify(token, secret, {
+  algorithms: ['HS256'],
+  issuer: 'your-app',
+});
+```
+
+## Next.js Middleware Is Not Enough
+
+Next.js middleware runs at the edge and is convenient for auth checks, but it is **not a reliable sole auth layer**. CVE-2025-29927 demonstrated that middleware could be completely bypassed via a spoofed `x-middleware-subrequest` header.
+
+Always verify auth again in:
+- Server Actions
+- Route Handlers (`app/api/`)
+- Data access functions / database queries
+
+Middleware should be a convenience layer, not the only wall between an attacker and your data.
+
+## Server Actions Are Public Endpoints
+
+Server Actions compile into public POST endpoints. Anyone can call them with `curl`. AI assistants frequently generate Server Actions that assume they're only called by the UI:
+
+```typescript
+// BAD: no auth check, no input validation
+'use server';
+export async function deleteItem(id: string) {
+  await db.items.delete({ where: { id } });
+}
+
+// GOOD: validates input, authenticates, and authorizes
+'use server';
+export async function deleteItem(input: unknown) {
+  const parsed = schema.safeParse(input);
+  if (!parsed.success) return { error: 'Invalid input' };
+
+  const session = await auth();
+  if (!session?.user) redirect('/login');
+
+  // Authorize: verify ownership, not just login
+  await db.items.deleteMany({
+    where: { id: parsed.data.id, userId: session.user.id }
+  });
+}
+```
+
+Every Server Action needs three things at the top:
+1. **Input validation** (Zod or similar runtime schema)
+2. **Authentication** (verify the user is logged in)
+3. **Authorization** (verify the user owns the resource)
+
+## API Route Handlers
+
+Same rules apply to `app/api/` route handlers. Every route handler is a public endpoint. Authenticate and authorize at the top of every handler.
+
+## Data Leakage to Client Components
+
+Never pass entire database objects to Client Components. They may contain sensitive fields (hashed passwords, internal IDs, admin flags). Select only the fields the client needs:
+
+```typescript
+// BAD: leaks all fields to the client
+const user = await db.users.findUnique({ where: { id } });
+return <UserProfile user={user} />;
+
+// GOOD: select only needed fields
+const user = await db.users.findUnique({
+  where: { id },
+  select: { name: true, avatarUrl: true }
+});
+return <UserProfile user={user} />;
+```
+
+Use `import 'server-only'` at the top of data access modules to prevent them from being accidentally imported into Client Components.
+
+## Session & Token Storage
+
+- Store tokens in `HttpOnly + Secure + SameSite=Lax` cookies, **not localStorage**.
+- localStorage is accessible to any JavaScript on the page — a single XSS vulnerability exposes all tokens.
+- `HttpOnly` cookies are invisible to JavaScript and sent automatically by the browser.

package/framework/mobile_development/.gemini/skills/vibe-security/references/data-access.md

@@ -0,0 +1,79 @@
+# Data Access & Input Validation
+
+## SQL Injection
+
+Always use parameterized queries or ORM methods. Never concatenate user input into SQL strings:
+
+```typescript
+// BAD: SQL injection via string concatenation
+const result = await db.query(`SELECT * FROM users WHERE id = '${userId}'`);
+
+// GOOD: parameterized query
+const result = await db.query('SELECT * FROM users WHERE id = $1', [userId]);
+```
+
+## ORM Safety (Prisma)
+
+Even with an ORM, injection is possible:
+
+- **Validate input types with Zod before passing to Prisma.** `findFirst` and similar methods are vulnerable to operator injection if unvalidated objects are passed as filter values. An attacker can send `{ "email": { "contains": "" } }` to match all records.
+
+```typescript
+// BAD: raw request body passed directly to Prisma
+const user = await prisma.user.findFirst({ where: req.body });
+
+// GOOD: validate with Zod first
+const schema = z.object({ email: z.string().email() });
+const parsed = schema.parse(req.body);
+const user = await prisma.user.findFirst({ where: { email: parsed.email } });
+```
+
+- **Never use `$queryRawUnsafe` or `$executeRawUnsafe` with user-supplied input.** These bypass Prisma's parameterization entirely.
+
+```typescript
+// BAD: raw SQL with user input
+const results = await prisma.$queryRawUnsafe(
+  `SELECT * FROM users WHERE name = '${name}'`
+);
+
+// GOOD: use the safe raw query with parameters
+const results = await prisma.$queryRaw`
+  SELECT * FROM users WHERE name = ${name}
+`;
+```
+
+## Input Validation
+
+Validate all external input at system boundaries using a runtime schema validator (Zod, Yup, Joi, etc.):
+
+- API route handlers
+- Server Actions
+- Webhook handlers
+- Form submissions
+- URL parameters and query strings
+
+Don't rely on TypeScript types alone — they're compile-time only and don't exist at runtime. An attacker sending a malformed request bypasses all TypeScript checks.
+
+```typescript
+// TypeScript type provides NO runtime protection
+type CreateUserInput = { name: string; email: string };
+
+// Zod schema provides ACTUAL runtime validation
+const CreateUserSchema = z.object({
+  name: z.string().min(1).max(100),
+  email: z.string().email(),
+});
+```
+
+## Mass Assignment
+
+Don't spread request bodies directly into database operations. An attacker can add unexpected fields:
+
+```typescript
+// BAD: attacker can add { isAdmin: true, credits: 99999 }
+await db.users.update({ where: { id }, data: req.body });
+
+// GOOD: pick only allowed fields
+const { name, email } = validated.data;
+await db.users.update({ where: { id }, data: { name, email } });
+```