@agent-native/core 0.4.5 → 0.6.1

package/dist/templates/templates/default/.agents/skills/real-time-collab/SKILL.md

@@ -0,0 +1,183 @@
+---
+name: real-time-collab
+description: >-
+  How to enable multi-user collaborative editing with Yjs CRDT, TipTap
+  Collaboration extension, live cursors, and agent-driven edits.
+---
+
+# Real-Time Collaboration
+
+The framework provides a Yjs-based collaborative editing system in `@agent-native/core/collab`. Multiple users can edit the same document simultaneously with live cursor positions, and the AI agent can make surgical edits that appear in real-time.
+
+## Architecture
+
+```
+User A (TipTap + Collaboration ext)  ←→  Y.XmlFragment  ←→  Server (_collab_docs table)
+User B (TipTap + Collaboration ext)  ←→  Y.XmlFragment  ←→       ↑
+Agent (edit-document action)         ←→  search-replace endpoint ─┘
+```
+
+- **Yjs Y.Doc** stores the document as a `Y.XmlFragment` (ProseMirror node tree)
+- **TipTap's Collaboration extension** binds the editor to the Y.XmlFragment via `ySyncPlugin`
+- **CollaborationCaret extension** renders remote users' cursors with names and colors
+- **Polling** (every 2s) syncs Y.Doc updates and awareness state between clients and server
+- **SQL `_collab_docs` table** persists Yjs state (base64-encoded binary)
+
+## Enabling Collaboration in a Template
+
+### 1. Install dependencies
+
+```bash
+pnpm add @tiptap/extension-collaboration @tiptap/extension-collaboration-caret @tiptap/y-tiptap --filter your-template
+```
+
+### 2. Add Vite optimizeDeps
+
+In `vite.config.ts`:
+```ts
+export default defineConfig({
+  plugins: [reactRouter()],
+  optimizeDeps: {
+    include: [
+      "yjs",
+      "y-protocols/awareness",
+      "@tiptap/extension-collaboration",
+      "@tiptap/extension-collaboration-caret",
+      "@tiptap/y-tiptap",
+    ],
+  },
+});
+```
+
+This prevents Vite from re-bundling TipTap in incompatible ways during dev.
+
+### 3. Add the collab server plugin
+
+Create `server/plugins/collab.ts`:
+```ts
+import { createCollabPlugin } from "@agent-native/core/server";
+export default createCollabPlugin({
+  table: "your_table",
+  contentColumn: "content",
+  idColumn: "id",
+  autoSeed: false, // Client-side seeding on first load
+});
+```
+
+This mounts routes under `/_agent-native/collab/`:
+- `GET /:docId/state` — fetch Y.Doc state
+- `POST /:docId/update` — apply client update
+- `POST /:docId/text` — apply full text (diff-based)
+- `POST /:docId/search-replace` — surgical text find/replace in Y.XmlFragment
+- `POST /:docId/awareness` — sync cursor/presence state
+
+### 4. Use the `useCollaborativeDoc` hook
+
+```ts
+import { useCollaborativeDoc, generateTabId } from "@agent-native/core/client";
+
+const TAB_ID = generateTabId();
+
+const { ydoc, awareness, isLoading, activeUsers } = useCollaborativeDoc({
+  docId: documentId,
+  requestSource: TAB_ID,
+  user: { name: "Steve", email: "steve@example.com", color: "#60a5fa" },
+});
+```
+
+The hook:
+- Creates a stable `Y.Doc` per docId (never changes identity)
+- Fetches server state and applies it
+- Sends local updates to server
+- Polls for remote updates (every 2s)
+- Tracks active users via awareness
+
+### 5. Add Collaboration extension to TipTap
+
+```ts
+import Collaboration from "@tiptap/extension-collaboration";
+import CollaborationCaret from "@tiptap/extension-collaboration-caret";
+import { Awareness } from "y-protocols/awareness";
+
+// Create awareness locally (must use same y-protocols as the caret extension)
+const awareness = new Awareness(ydoc);
+awareness.setLocalStateField("user", { name, color });
+
+const editor = useEditor({
+  extensions: [
+    StarterKit.configure({ history: false }), // Disable history — Yjs handles undo
+    Collaboration.configure({ document: ydoc }),
+    CollaborationCaret.configure({
+      provider: { awareness },
+      user: { name, color },
+    }),
+    // ... other extensions
+  ],
+  content: initialContent, // Seeds Y.XmlFragment on first load
+});
+```
+
+**Important:** Disable `history` in StarterKit when using Collaboration — Yjs handles undo/redo.
+
+### 6. Seed the Y.XmlFragment
+
+The Collaboration extension does NOT auto-seed from the `content` prop. You must seed manually:
+
+```ts
+useEffect(() => {
+  if (!editor || !ydoc || !content) return;
+  const fragment = ydoc.getXmlFragment("default");
+  if (fragment.length === 0) {
+    editor.commands.setContent(parseContent(content));
+  }
+}, [editor, ydoc, content]);
+```
+
+**Critical:** Guard against saving empty content back to SQL when the editor is in collab mode but hasn't been seeded yet:
+
+```ts
+onUpdate: ({ editor }) => {
+  const md = editor.storage.markdown.getMarkdown();
+  if (!md.trim() && ydoc) return; // Don't save empty during seeding
+  onChange(md);
+}
+```
+
+## Agent Edits via `edit-document`
+
+The `edit-document` action uses search-and-replace:
+```bash
+pnpm action edit-document --id <docId> --find "old text" --replace "new text"
+```
+
+When collab state exists, the action calls the server's `search-replace` endpoint which:
+1. Walks the Y.XmlFragment tree
+2. Finds the text in Y.XmlText nodes
+3. Applies minimal delete/insert operations
+4. Emits a Yjs update via the poll system
+5. Client receives the update → ySyncPlugin applies a targeted ProseMirror transaction → cursor preserved
+
+**Important:** Actions run in a separate process, so they must use the HTTP endpoint (not the collab module directly) to emit updates to the server's poll system.
+
+## Key Modules
+
+| Module | Path | Purpose |
+|--------|------|---------|
+| `@agent-native/core/collab` | `packages/core/src/collab/` | Server-side Yjs management |
+| `useCollaborativeDoc` | `packages/core/src/collab/client.ts` | Client hook |
+| `createCollabPlugin` | `packages/core/src/server/collab-plugin.ts` | Route mounting |
+| `searchAndReplace` | `packages/core/src/collab/ydoc-manager.ts` | Y.XmlFragment text mutation |
+
+## Common Pitfalls
+
+1. **TipTap version mismatch** — All `@tiptap/*` packages must be the same version. The Collaboration extension requires `editor.utils` which was added in v3.22.2.
+
+2. **Empty editor on first load** — The Collaboration extension uses Y.XmlFragment as the source of truth. If the fragment is empty, the editor shows empty. Seed manually (see above).
+
+3. **Data loss from empty saves** — The `onUpdate` handler fires when the editor initializes with an empty Y.XmlFragment. If this empty content is saved to SQL, it overwrites the real content. Always guard against saving empty content in collab mode.
+
+4. **Stale content on document switch** — Use `key={documentId}` on the editor component to force a full remount when switching documents. This ensures the Y.Doc, seeding, and editor state are all fresh.
+
+5. **Separate process for actions** — Actions run via `pnpm action` in a new Node.js process. The in-memory EventEmitter in the action process doesn't reach the dev server's poll system. Use HTTP endpoints for collab operations from actions.
+
+6. **Vite dep optimization** — Adding Yjs-related packages to a template changes Vite's dependency bundling, which can break TipTap's React integration. Always add them to `optimizeDeps.include`.

package/dist/templates/templates/default/.agents/skills/real-time-sync/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: real-time-sync
+description: >-
+  How to keep the UI in sync with agent changes via polling. Use when wiring
+  query invalidation for new data models, debugging UI not updating, or
+  understanding jitter prevention.
+---
+
+# Real-Time Sync (Polling)
+
+## Rule
+
+The UI stays in sync with agent/script changes through database polling. When the agent writes to the database, the UI detects the change and updates automatically — no manual refresh needed.
+
+## Why
+
+The agent modifies data in SQL, but the UI runs in the browser. Polling bridges this gap: every database write increments a version counter, the `useDbSync()` hook polls for version changes, and React Query invalidates the relevant caches. This is what makes database writes feel real-time.
+
+## How It Works
+
+1. **Server** increments a version counter on every database write. The `/_agent-native/poll` endpoint returns the current version and any events since the last poll.
+
+2. **Client** polls for changes and invalidates React Query caches:
+
+   ```ts
+   import { useDbSync } from "@agent-native/core";
+   useDbSync({ queryClient, queryKeys: ["items", "settings"] });
+   ```
+
+3. When the agent writes to the database, the version increments, polling detects it, and React Query refetches the affected queries.
+
+## Don't
+
+- Don't create manual polling loops — `useDbSync()` handles it (polls every 2 seconds by default)
+- Don't create your own fetch-based polling alongside `useDbSync` — use the `onEvent` callback for custom handling
+
+## Query Key Mapping
+
+By default, `useDbSync` invalidates all listed query keys on every change. For apps with multiple data models, this causes unnecessary refetches. Use event-based filtering via the `onEvent` callback:
+
+```ts
+useDbSync({
+  queryClient,
+  queryKeys: [], // don't auto-invalidate everything
+  onEvent: (data) => {
+    if (data.source === "settings") {
+      queryClient.invalidateQueries({ queryKey: ["settings"] });
+    } else if (data.source === "app-state") {
+      queryClient.invalidateQueries({ queryKey: ["navigate-command"] });
+    } else {
+      queryClient.invalidateQueries({ queryKey: ["items"] });
+    }
+  },
+});
+```
+
+To prevent cache thrashing during rapid agent writes, set `staleTime` on your queries:
+
+```ts
+useQuery({
+  queryKey: ["items"],
+  queryFn: fetchItems,
+  staleTime: 2000, // don't refetch within 2 seconds
+});
+```
+
+## Troubleshooting
+
+| Symptom                            | Check                                                                                                          |
+| ---------------------------------- | -------------------------------------------------------------------------------------------------------------- |
+| UI not updating after agent writes | Is `useDbSync` called with the correct `queryClient`? Are the `queryKeys` matching your `useQuery` keys?       |
+| Poll endpoint not responding       | Is `/_agent-native/poll` accessible? Is the server running?                                                    |
+| High CPU / event storms            | The agent is writing rapidly. Add `staleTime` to queries and use event-based filtering.                        |
+
+## Jitter Prevention
+
+When the agent writes to application-state via script helpers (`writeAppState`, `deleteAppState`), the write is automatically tagged with `requestSource: "agent"`. This prevents the UI from overwriting active user edits when it receives the change event.
+
+### How it works
+
+1. **Agent writes** are tagged: the script helpers in `@agent-native/core/application-state` pass `{ requestSource: "agent" }` to the store.
+2. **UI writes** are tagged: templates send a per-tab ID via the `X-Request-Source` header on PUT/DELETE requests to application-state endpoints.
+3. **Polling filters**: `useDbSync()` accepts an `ignoreSource` option. The UI passes its own tab ID so it ignores events from its own writes — but still picks up events from agents, other tabs, and scripts.
+
+### Template setup
+
+```ts
+// app/lib/tab-id.ts
+export const TAB_ID = `tab-${Math.random().toString(36).slice(2, 8)}`;
+
+// app/root.tsx
+import { TAB_ID } from "@/lib/tab-id";
+
+useDbSync({
+  queryClient,
+  queryKeys: ["app-state", "settings"],
+  ignoreSource: TAB_ID,
+});
+```
+
+The `use-navigation-state.ts` hook sends the same `TAB_ID` in the `X-Request-Source` header when writing navigation state, so the tab that wrote the state does not refetch it.
+
+### Why this matters
+
+Without jitter prevention, a cycle occurs: the UI writes state, polling detects the change, the UI refetches and re-renders, potentially overwriting what the user is actively editing. With `ignoreSource`, the UI only reacts to changes from other sources (agent scripts, other browser tabs, other users).
+
+## Related Skills
+
+- **storing-data** — Application-state and settings are the data stores that sync via polling
+- **context-awareness** — Navigation state writes use jitter prevention to avoid overwriting active edits
+- **scripts** — Script outputs written to the database trigger poll events
+- **self-modifying-code** — Agent code edits trigger poll events; rapid edits can cause event storms

package/dist/templates/templates/default/.agents/skills/security/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: security
+description: >-
+  Data security model, user/org scoping, and auth patterns. Use when adding
+  tables with user data, implementing multi-user features, setting up A2A
+  cross-app calls, or reviewing data access patterns.
+---
+
+# Security & Data Scoping
+
+## How Data Isolation Works
+
+In production, the framework enforces data isolation at the SQL level. Agents and users can only see and modify data they own. This is automatic — you don't write WHERE clauses yourself.
+
+### Per-User Scoping (`owner_email`)
+
+Every table with user-specific data **must** have an `owner_email` text column.
+
+```ts
+import { table, text, integer } from "@agent-native/core/db/schema";
+
+export const notes = table("notes", {
+  id: text("id").primaryKey(),
+  title: text("title").notNull(),
+  content: text("content"),
+  owner_email: text("owner_email").notNull(), // REQUIRED for user data
+});
+```
+
+**What happens automatically:**
+- `db-query` creates temporary views with `WHERE owner_email = <current user>`
+- `db-exec` INSERT statements get `owner_email` auto-injected
+- `db-exec` UPDATE/DELETE statements are scoped to the current user's rows
+- The current user comes from `AGENT_USER_EMAIL` (set from the auth session)
+
+### Per-Org Scoping (`org_id`)
+
+For multi-user apps where teams share data, add an `org_id` column:
+
+```ts
+export const projects = table("projects", {
+  id: text("id").primaryKey(),
+  name: text("name").notNull(),
+  owner_email: text("owner_email").notNull(), // who created it
+  org_id: text("org_id").notNull(),           // which org it belongs to
+});
+```
+
+When both columns are present, queries are scoped by **both**: `WHERE owner_email = ? AND org_id = ?`.
+
+The `org_id` comes from `AGENT_ORG_ID` which is automatically set from the user's active organization in Better Auth.
+
+### Validation
+
+Run `pnpm action db-check-scoping` to verify all tables have proper ownership columns. Use `--require-org` for multi-org apps.
+
+## Auth Model
+
+### Better Auth (Default)
+
+The framework uses Better Auth for authentication. It's always on by default — users create an account on first visit.
+
+**Environment variables:**
+- `BETTER_AUTH_SECRET` — signing key (auto-generated if not set)
+- `GOOGLE_CLIENT_ID` + `GOOGLE_CLIENT_SECRET` — enable Google OAuth
+- `GITHUB_CLIENT_ID` + `GITHUB_CLIENT_SECRET` — enable GitHub OAuth
+- `AUTH_MODE=local` — disable auth for solo local dev (escape hatch)
+
+### Organizations
+
+Better Auth's organization plugin is built-in. Every app supports:
+- Creating organizations
+- Inviting members (owner/admin/member roles)
+- Switching active organization
+- Per-org data scoping via `org_id`
+
+The active organization ID flows from `session.orgId` → `AGENT_ORG_ID` → SQL scoping automatically.
+
+### ACCESS_TOKEN (Legacy)
+
+For simple deployments, set `ACCESS_TOKEN` or `ACCESS_TOKENS` (comma-separated) as environment variables. This provides a shared token for all users — no per-user identity.
+
+## A2A Security
+
+### Cross-App Identity
+
+When apps call each other via A2A, they need to verify identity. Set the same `A2A_SECRET` on all apps that need to trust each other:
+
+```bash
+# On both apps
+A2A_SECRET=your-shared-secret-at-least-32-chars
+```
+
+**How it works:**
+1. App A signs a JWT with `A2A_SECRET` containing `sub: "steve@builder.io"`
+2. App B receives the call, verifies the JWT signature
+3. App B sets `AGENT_USER_EMAIL` from the verified `sub` claim
+4. Data scoping applies — App B only shows steve's data
+
+Without `A2A_SECRET`, A2A calls are unauthenticated (fine for local dev, not production).
+
+## Rules for Agents
+
+1. **Every new table with user data must have `owner_email`.** No exceptions.
+2. **Never bypass scoping** — don't raw-query tables without going through `db-query`/`db-exec`.
+3. **Don't expose user data in application state** — application state is per-session, not per-user. Use SQL tables with `owner_email` for persistent user data.
+4. **Don't hardcode emails** — use `AGENT_USER_EMAIL` environment variable.
+5. **Test with multiple users** — create two accounts and verify data isolation.

package/dist/templates/templates/default/.agents/skills/self-modifying-code/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: self-modifying-code
+description: >-
+  How the agent can modify the app's own source code. Use when the agent needs
+  to edit components, routes, styles, or scripts, when designing UI for agent
+  editability, or when deciding what the agent should and shouldn't modify.
+---
+
+# Self-Modifying Code
+
+## Rule
+
+The agent can edit the app's own source code — components, routes, styles, scripts. This is a feature, not a bug. Design your app expecting this.
+
+## Why
+
+An agent-native app isn't just an app the agent can _use_ — it's an app the agent can _change_. The agent can fix bugs, add features, adjust styles, and restructure code. This makes the agent a true collaborator, not just an operator.
+
+## Modification Taxonomy
+
+Not all modifications are equal. Use this to decide what level of care is needed:
+
+| Tier          | What                  | Examples                                         | After modifying                   |
+| ------------- | --------------------- | ------------------------------------------------ | --------------------------------- |
+| 1: Data       | Files in `data/`      | JSON state, generated content, markdown          | Nothing — these are routine       |
+| 2: Source     | App code              | Components, routes, styles, scripts              | Run `pnpm typecheck && pnpm lint` |
+| 3: Config     | Project config        | `package.json`, `tsconfig.json`, `vite.config.*` | Ask for explicit approval first   |
+| 4: Off limits | Secrets and framework | `.env`, `@agent-native/core` internals           | Never modify these                |
+
+## Git Checkpoint Pattern
+
+Before modifying source code (Tier 2+), create a rollback point:
+
+1. Commit or stash current state
+2. Make the edit
+3. Run `pnpm typecheck && pnpm lint`
+4. If verification fails → revert with `git checkout -- <file>`
+5. If verification passes → continue
+
+This ensures the agent can experiment without breaking the app.
+
+## Designing for Agent Editability
+
+Make your app easy for the agent to understand and modify:
+
+**Expose UI state via `data-*` attributes** so the agent knows what's selected:
+
+```ts
+const el = document.documentElement;
+el.dataset.currentView = view;
+el.dataset.selectedId = selectedItem?.id || "";
+```
+
+**Expose richer context via `window.__appState`** for complex state:
+
+```ts
+(window as any).__appState = {
+  selectedId: id,
+  currentLayout: layout,
+  itemCount: items.length,
+};
+```
+
+**Use configuration-driven rendering** — Extract visual decisions (colors, layouts, sizes) into JSON config files in `data/`. The agent can modify the config (Tier 1) instead of the component source (Tier 2).
+
+## Don't
+
+- Don't modify `.env` files or files containing secrets
+- Don't modify `@agent-native/core` package internals
+- Don't modify `.agents/skills/` or `AGENTS.md` unless explicitly requested
+- Don't skip the typecheck/lint step after editing source code
+- Don't make source changes without a git checkpoint to roll back to
+
+## Related Skills
+
+- **storing-data** — Tier 1 modifications (database writes) are the safest and most common
+- **scripts** — The agent can create or modify scripts to add new capabilities
+- **delegate-to-agent** — Self-modification requests come through the agent chat
+- **real-time-sync** — Source edits and database writes trigger SSE events to update the UI

package/dist/templates/templates/default/.agents/skills/storing-data/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: storing-data
+description: >-
+  How and where to store application data. Use when adding new data models,
+  deciding between settings vs Drizzle tables, reading/writing app config,
+  or working with application state.
+---
+
+# Storing Data
+
+## Where Data Goes
+
+All data lives in one SQLite database (`data/app.db`). In production, set `DATABASE_URL` to point to Turso, Neon, Supabase, or D1 — same code, no changes needed.
+
+There are three storage layers, each for a different kind of data:
+
+### 1. Settings — app configuration
+
+Key-value store for persistent config that the user or agent can change. Theme, preferences, integration API keys, availability schedules.
+
+```ts
+import { getSetting, putSetting } from "@agent-native/core/settings";
+
+// Read (returns null if not set)
+const prefs = await getSetting("user-preferences");
+
+// Write (creates or replaces)
+await putSetting("user-preferences", { theme: "dark", density: "comfortable" });
+```
+
+From scripts:
+```ts
+import { readSetting, writeSetting } from "@agent-native/core/settings";
+const prefs = await readSetting("user-preferences");
+```
+
+SSE: writes automatically notify the UI via `{ source: "settings", type: "change", key }`.
+
+### 2. Application State — ephemeral UI state
+
+For state the agent and UI share in real-time: what the user is looking at, compose drafts, navigation commands. Scoped by session — cleared between sessions.
+
+```ts
+import { readAppState, writeAppState, deleteAppState, listAppState } from "@agent-native/core/application-state";
+
+// Write state (UI updates instantly via SSE)
+await writeAppState("navigate", { view: "inbox", threadId: "t-123" });
+
+// Read state
+const nav = await readAppState("navigation");
+
+// List by prefix (e.g., all compose drafts)
+const drafts = await listAppState("compose-");
+
+// Delete (one-shot commands: UI reads, then agent or UI deletes)
+await deleteAppState("navigate");
+```
+
+SSE: writes automatically notify the UI via `{ source: "app-state", type: "change", key }`.
+
+### 3. Drizzle Tables — structured domain data
+
+For data with schemas, relationships, and queries: forms, bookings, emails, compositions. Define tables in `server/db/schema.ts` using Drizzle ORM.
+
+```ts
+import { table, text, integer } from "@agent-native/core/db/schema";
+
+export const bookings = table("bookings", {
+  id: text("id").primaryKey(),
+  name: text("name").notNull(),
+  email: text("email").notNull(),
+  startTime: integer("start_time").notNull(),
+  endTime: integer("end_time").notNull(),
+});
+```
+
+Query via `getDb()` singleton from `server/db/index.ts`.
+
+### 4. OAuth Tokens — credentials
+
+For OAuth tokens acquired at runtime (Google, etc.). Never store these in settings — use the dedicated encrypted store.
+
+```ts
+import { saveOAuthTokens, getOAuthTokens, listOAuthAccounts } from "@agent-native/core/oauth-tokens";
+
+await saveOAuthTokens("google", "user@gmail.com", { access_token: "...", refresh_token: "..." });
+const tokens = await getOAuthTokens("google", "user@gmail.com");
+const accounts = await listOAuthAccounts("google");
+```
+
+## Which Layer to Use
+
+| Data | Layer | Why |
+|------|-------|-----|
+| User preferences, theme, config | Settings | Persistent KV, SSE notifications, simple read/write |
+| What the user sees on screen | Application State | Ephemeral, real-time sync, agent ↔ UI bridge |
+| Compose drafts, wizard steps | Application State | Temporary, deleted when done |
+| Domain records (forms, bookings) | Drizzle table | Needs schema, queries, relationships |
+| OAuth refresh tokens | OAuth Tokens | Secure, per-provider, per-account |
+
+## Environment Variables
+
+Infrastructure config stays in `.env` — these differ per deployment:
+
+- `DATABASE_URL` — database connection (default: `file:./data/app.db`)
+- `DATABASE_AUTH_TOKEN` — for remote databases
+- `GOOGLE_CLIENT_ID`, `GOOGLE_CLIENT_SECRET` — OAuth app credentials
+- `ACCESS_TOKEN` — production auth token
+
+Everything else (user settings, tokens, app state) goes in SQL.

package/dist/templates/templates/default/.claude/settings.json

@@ -0,0 +1,100 @@
+{
+  "hooks": {
+    "UserPromptSubmit": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "pnpm action view-screen 2>/dev/null || echo '{\"view\": \"unknown\"}'",
+            "timeout": 10
+          }
+        ]
+      }
+    ]
+  },
+  "permissions": {
+    "allow": [
+      "Read",
+      "Edit",
+      "Write",
+      "Glob",
+      "Grep",
+      "NotebookEdit",
+      "WebFetch",
+      "WebSearch",
+      "Bash(ls *)",
+      "Bash(pwd)",
+      "Bash(echo *)",
+      "Bash(cat *)",
+      "Bash(head *)",
+      "Bash(tail *)",
+      "Bash(find *)",
+      "Bash(wc *)",
+      "Bash(sort *)",
+      "Bash(uniq *)",
+      "Bash(diff *)",
+      "Bash(which *)",
+      "Bash(env)",
+      "Bash(mkdir *)",
+      "Bash(cp *)",
+      "Bash(mv *)",
+      "Bash(touch *)",
+      "Bash(chmod *)",
+      "Bash(cd *)",
+      "Bash(node *)",
+      "Bash(npx *)",
+      "Bash(npm *)",
+      "Bash(pnpm *)",
+      "Bash(yarn *)",
+      "Bash(tsx *)",
+      "Bash(tsc *)",
+      "Bash(vitest *)",
+      "Bash(jest *)",
+      "Bash(eslint *)",
+      "Bash(prettier *)",
+      "Bash(git status*)",
+      "Bash(git log *)",
+      "Bash(git diff *)",
+      "Bash(git show *)",
+      "Bash(git branch*)",
+      "Bash(git add *)",
+      "Bash(git commit *)",
+      "Bash(git checkout *)",
+      "Bash(git switch *)",
+      "Bash(git stash *)",
+      "Bash(git merge *)",
+      "Bash(git rebase *)",
+      "Bash(git pull *)",
+      "Bash(git blame *)",
+      "Bash(git rev-parse *)",
+      "Bash(git worktree *)",
+      "Bash(git remote -v)",
+      "Bash(gh *)",
+      "Bash(curl *)",
+      "Bash(grep *)",
+      "Bash(rg *)",
+      "Bash(sed *)",
+      "Bash(awk *)",
+      "Bash(jq *)",
+      "Bash(rm *)"
+    ],
+    "deny": [
+      "Bash(rm -rf /)",
+      "Bash(rm -rf /*)",
+      "Bash(rm -rf ~)",
+      "Bash(rm -rf ~/*)",
+      "Bash(sudo *)",
+      "Bash(git push --force *)",
+      "Bash(git push -f *)",
+      "Bash(git reset --hard *)",
+      "Bash(git clean -f *)",
+      "Bash(dd *)",
+      "Bash(mkfs *)",
+      "Bash(kill -9 *)",
+      "Bash(killall *)",
+      "Bash(pkill *)",
+      "Bash(shutdown *)",
+      "Bash(reboot *)"
+    ]
+  }
+}