@cursor/july 0.1.1

package/docs/reference/tools.md

@@ -0,0 +1,203 @@
+---
+title: "Tools"
+description: "Define typed actions the model can call, gate the sensitive ones on approval, and call any server tool without a model turn."
+---
+
+# Tools
+
+A tool is a typed action the model can call: hit an API, run a query,
+write a file. Each file in `agent/tools/` defines one tool, and the
+filename becomes the tool name the model sees. Tools come in two
+execution flavors: server tools run in-process on the serve host, and
+agent tools run as scripts where the agent runs. Every server tool can
+also be called directly, with no model turn.
+
+## Define a server tool
+
+By default, `execute` runs in-process on the serving host with full
+access to `process.env` and your `agent/lib/` code. Server tools require
+the `local` runtime.
+
+```ts
+// agent/tools/inspect_pr.ts
+import { defineTool } from "@cursor/july/tools";
+import { z } from "zod";
+
+export default defineTool({
+  description: "Inspect a pull request before approval.",
+  // execution: "server" is the default
+  inputSchema: z.object({ prUrl: z.string().url() }),
+  async execute({ prUrl }, ctx) {
+    return { prUrl, checks: ["unit", "lint"], ready: true };
+  },
+});
+```
+
+A tool definition needs a filename slug (the model-facing name), a
+`description` written for the model, an optional `inputSchema`, and the
+code that runs it. With a Zod `inputSchema`, the input is validated before
+`execute` runs and the input type is inferred. A plain JSON Schema
+object is forwarded as-is and the input arrives as raw JSON.
+
+### The `ctx` parameter
+
+`execute` receives a `ctx` with the runtime accessors:
+
+| Member | What it is |
+| --- | --- |
+| `ctx.toolCallId` | The call id, matching the `actions.requested` / `action.result` stream events |
+| `ctx.session` | Read-only session info: id, channel, mode, auth |
+| `ctx.workspaceDir` | The session's workspace directory |
+| `ctx.host.mcp` | Authored MCP connections: `names()`, `listTools(name)`, `callTool(name, tool, args)` |
+| `ctx.host.github` / `ctx.host.slack` | Shared host clients when those packs are configured |
+
+### Return values
+
+`execute` may return a string (passed to the model verbatim), a
+JSON-shaped value (serialized), or the envelope
+`{ content: [...], isError? }` for rich results. Returns must be
+JSON-shaped: use object literals or `type` aliases. An `interface` type
+fails assignability (no index signature), and tsx won't catch it. Your
+typecheck will.
+
+Throwing inside `execute` reports an error result to the model
+(`isError: true`). The turn and the server keep running.
+
+## Define an agent tool
+
+Set `execution: "agent"` and the tool materializes as a shell script
+that runs where the Cursor agent runs: the local harness workspace or
+the cloud VM. The script receives JSON arguments on stdin and prints its
+result on stdout. This is the only tool flavor available to
+`runtime: "cloud"` agents.
+
+```ts
+import { defineTool } from "@cursor/july/tools";
+import { z } from "zod";
+
+export default defineTool({
+  description: "Echo a message from the agent workspace.",
+  execution: "agent",
+  inputSchema: z.object({ message: z.string() }),
+  script: `#!/usr/bin/env bash
+set -euo pipefail
+message=$(python3 -c 'import json,sys; print(json.load(sys.stdin)["message"])')
+printf '%s\\n' "$message"
+`,
+});
+```
+
+On the local runtime, scripts land under `.agentkit/tools/` in the
+session workspace with a catalog in `AGENTS.md`. On cloud, the catalog
+and script bodies travel on the first prompt.
+
+## Gate a tool on human approval
+
+A server tool can require a person to sign off before it runs. Set
+`needsApproval` to `true`, or to a predicate over the validated input:
+
+```ts
+export default defineTool({
+  description: "Promote a verified build to an environment.",
+  needsApproval: true, // or: (input) => input.environment === "production"
+  inputSchema: z.object({
+    service: z.string(),
+    buildId: z.string(),
+    environment: z.string(),
+  }),
+  async execute({ service, buildId, environment }) {
+    return { promoted: true, service, buildId, environment };
+  },
+});
+```
+
+The call parks, the turn stays running, and the stream emits
+`action.approval_requested` until someone resolves it from the
+playground, `POST /v1/session/:id/approvals/:callId`, or Slack
+Approve/Deny cards. Approvals exist for server tools on the local
+runtime only, and parked calls don't survive a host restart. The full
+lifecycle is in [Human-in-the-loop](../guides/human-in-the-loop.md).
+
+## Call a tool without a model turn
+
+Server tools can be called deterministically. You pick the tool and the
+input. Validation and execution behave exactly as they would for a
+model-initiated call, and no Cursor API key is needed.
+
+Over HTTP, with the same auth chain as the session API:
+
+```bash
+curl -X POST http://127.0.0.1:3000/<slug>/v1/tools/inspect_pr \
+  -H 'content-type: application/json' \
+  -d '{"input":{"prUrl":"https://github.com/acme/checkout/pull/42"}}'
+# {"ok":true,"toolName":"inspect_pr","callId":"tool_inspect_pr_…",
+#  "isError":false,"result":{…},"durationMs":12}
+```
+
+From the CLI, which starts an ephemeral server unless `--url` targets
+a running one:
+
+```bash
+agentkit call inspect_pr --dir . \
+  --input '{"prUrl":"https://github.com/acme/checkout/pull/42"}'
+agentkit call inspect_pr \
+  --url http://127.0.0.1:3000/<slug> \
+  --input '{"prUrl":"https://github.com/acme/checkout/pull/42"}'
+```
+
+Programmatically, `callTool(toolName, input, options?)` is available on
+the serve handle, on channel route handlers and `onStart` args, and on
+schedule `run` handlers, so a channel can mix deterministic calls with
+model turns, fetching PR metadata deterministically and then `send()`ing
+the review prompt:
+
+```ts
+const outcome = await handle.callTool("inspect_pr", {
+  prUrl: "https://github.com/acme/checkout/pull/42",
+});
+// { toolName, callId, isError, result, durationMs }
+```
+
+By default the call runs against an ephemeral scratch workspace under
+`<stateRoot>/tool-calls/<callId>`, materialized like a session workspace
+and removed when the call returns. Pass a `sessionId` (a body field over
+HTTP, `--session` on the CLI, `options.sessionId` programmatically) to
+run inside an existing session instead: the tool sees that session's
+workspace, and the call is recorded on the session's event stream under
+a per-call `turnId`, visible in the playground and trajectories like
+any model-initiated call. Session-bound calls serialize with model
+turns and return `409 session_busy` while a turn runs.
+
+The error semantics match the model path. Unknown tools are rejected
+with the available names, agent-execution tools cannot be called on the
+host (`400`), schema-invalid input is a `400` before the tool body runs
+(Zod validates; plain JSON Schema passes through unvalidated), and a
+tool body that throws reports `isError: true` in the same envelope the
+model would see.
+
+## Design habits
+
+Keep one decision per tool. Small tools with crisp descriptions beat
+multi-purpose tools with mode flags. The model chooses better and evals
+gate cleaner.
+
+Put deterministic policy in tool code, not model judgment. A PR-approval
+tool should re-read the live PR inside the tool before acting, so a
+spoofed payload can't steer it.
+
+Test tools with `call` before blaming prompts. If the tool's output is
+wrong, no instruction change fixes it.
+
+And gate side effects: `needsApproval` for the calls that need a
+person's sign-off, and dry-run defaults flipped by an env var for
+anything destructive.
+
+## What's next
+
+Continue with these pages:
+
+- [Human-in-the-loop](../guides/human-in-the-loop.md): the approval
+  lifecycle in full
+- [MCP connections](./connections.md): tools that come from MCP servers
+  instead
+- [Evals](../evals.md): gating tool decisions with `calledTool`

package/docs/scaffolding-agents.md

@@ -0,0 +1,113 @@
+---
+title: "Scaffold an agent with Cursor"
+description: "Use the bundled create-agent skill to plan, build, and verify a new agent."
+---
+
+# Scaffold an agent with Cursor
+
+Turn an idea into a verified agent while Cursor guides you through each
+decision.
+
+## What does the create-agent skill do?
+
+The bundled
+[`create-agent` skill](../skills/create-agent/SKILL.md) turns your goal
+into a small working project. Have Cursor read that file and follow it
+(monorepo path: `packages/agent-serve/skills/create-agent/SKILL.md`).
+
+Cursor will:
+
+- Ask only for choices missing from your prompt
+- Recommend defaults based on what you want to build
+- Show you the plan and file tree before writing files
+- Create the agent after you confirm the plan
+- Run structural checks, a real turn, and a smoke eval
+
+Use this skill for a new agent. Use
+[`hillclimb`](./hillclimbing.md) (`skills/hillclimb/SKILL.md`) when an
+existing agent works but needs better results.
+
+## How do I start a guided scaffold?
+
+Describe the outcome and any constraints you already know:
+
+> Build a local weather agent for the playground. Give it one tool for
+> current conditions and add a smoke eval. Guide me through the remaining
+> decisions.
+
+More detail means fewer questions. Include a channel, runtime, model, or
+required integration when those choices are fixed.
+
+## Which choices will Cursor ask me to make?
+
+Cursor fills gaps in two short rounds:
+
+- **Identity:** purpose, project name, and location
+- **Runtime:** local or cloud
+- **Model:** the default model or another Cursor model
+- **Channels:** playground and HTTP, Slack, GitHub, a webhook, or a
+  schedule
+- **MCP connections:** remote or local MCP servers
+- **Capabilities:** tools, skills, subagents, hooks, seed files,
+  approvals, and evals
+
+Questions adapt to your goal. A playground chat agent won't get
+cloud-repository questions. A local agent won't get cloud setup
+questions.
+
+## What happens before Cursor writes files?
+
+Cursor shows one plan with the choices it made and the folders it will
+create. Choose **Scaffold it** to continue or **Adjust something** to
+change the plan.
+
+No files change before you approve this step.
+
+## What will Cursor create?
+
+A first version usually includes:
+
+- `agent/agent.ts` for the model and runtime
+- `agent/instructions.md` for the always-on prompt
+- One or two tools under `agent/tools/`
+- Any channels or MCP connections you selected
+- `evals/evals.config.ts` and one smoke eval
+
+Cursor keeps the first version small. Side-effecting server tools use
+`needsApproval`. Deterministic setup, such as fetching a pull request,
+stays in host code instead of model instructions.
+
+See [Project layout](./reference/project-layout.md) for every supported
+folder.
+
+## How does Cursor verify the scaffold?
+
+Cursor checks the project in this order:
+
+1. Run `agentkit validate` and fix every error
+2. Inspect the discovered surface with `info --json`
+3. Call each server tool directly with validated sample input
+4. Run one end-to-end model turn
+5. Run the smoke eval
+6. Run the project's TypeScript check
+
+Validation, discovery, direct server-tool calls, and server startup work
+without a Cursor credential. Model turns and evals need
+`CURSOR_API_KEY` or a saved `agentkit login`.
+
+## What happens after the first agent works?
+
+Choose one to three fixed inputs, define what should improve, and name
+what must stay unchanged. Then have Cursor follow
+[`skills/hillclimb/SKILL.md`](../skills/hillclimb/SKILL.md).
+
+The hillclimb skill measures a baseline, changes one lever, runs the same
+inputs again, and adds an eval for each improvement you keep.
+
+## Related
+
+- [Build your first weather agent](./quickstart.md)
+- [Building agents with agents](./building-with-agents.md)
+- [Evals](./evals.md)
+- [Hillclimbing](./hillclimbing.md)
+- [Project layout](./reference/project-layout.md)

package/docs/troubleshooting.md

@@ -0,0 +1,95 @@
+---
+title: "Fix common agent problems"
+description: "Match what you see to a cause, then read a session trace when you need more detail."
+---
+
+# Fix common agent problems
+
+Start with four checks, in order:
+
+1. Project discovery: `agentkit validate --dir .`
+2. Whether the serve process is running
+3. What the playground or HTTP API shows
+4. The session event stream (trace)
+
+Match your symptom below. Keep the commands as `agentkit`; see
+[Run the CLI](./README.md#run-the-cli) if you still need an alias.
+
+## What if serve or the playground looks wrong?
+
+| What you see | What to do |
+| --- | --- |
+| `serve` won't start | Run `agentkit validate --dir .` and fix the reported errors. |
+| Playground is blank or says there are no agents | The UI needs a running `serve` process. Building the playground assets alone is not enough. |
+| Edits to the playground don't show up | Use `serve --dev` and open the printed playground HMR URL (often port `5273`), not only the static `:3000` URL. |
+| Sessions exist on disk but the playground list is empty | The list shows sessions for the authenticated caller. In `--dev` on loopback the list is wider. Otherwise open `/<slug>/playground?sessionId=ses_…` or inspect `sessions/` under your state root. |
+| Port 3000 or 5273 is already in use | Find and stop the listener (`lsof -iTCP:3000 -sTCP:LISTEN` on macOS/Linux), and any leftover Vite or webhook-forwarder processes. |
+
+## What if a model turn goes wrong?
+
+| What you see | What to do |
+| --- | --- |
+| Built-in file reads and greps fail; the turn retries for a long time | Run under Node 22.13+ (or `tsx`), never Bun. Look for `NGHTTP2_FRAME_SIZE_ERROR` in logs. |
+| The turn fails immediately with an API-key error | Sign in with `agentkit login`, or set `CURSOR_API_KEY`. Discovery, `info`, `call`, and serve bring-up work without a key; model turns need one. |
+| Replies quote rules or `AGENTS.md` from outside your agent project | The session workspace inherited parent-folder config. Point `defineAgent({ local: { cwd } })` outside that tree, or set `--state-root` to a clean directory (for example under `/tmp`). |
+| Server tools, skills, or workspace seed files never appear | The agent runtime is `cloud`. Those features apply on the local runtime. `validate` warns when this combination is present. |
+| `validate` and `run` succeed, but typecheck fails in CI | The CLI runs TypeScript with type-stripping only. Keep tool `execute` return types as object literals or `type` aliases, not `interface` types. |
+| Login works, but turns are rejected when using custom API hosts | Point login and model traffic at the same host (`CURSOR_API_BASE_URL` and `CURSOR_BACKEND_URL`). A key from one host is rejected by the other. |
+
+## What if the HTTP API returns an error?
+
+| What you see | What to do |
+| --- | --- |
+| `409` on a follow-up message | Refresh the `continuationToken` (it rotates on each accepted follow-up), wait if the session is busy, or confirm the session is a chat session (task and schedule sessions are not followable). |
+| `409 session_busy` on `call --session` | Wait for the model turn to finish, or omit `--session` for a one-off call. |
+| `403` on stream or follow-up | Use the same auth identity that created the session. Off localhost, pass `--bearer-token` and send it on every request. |
+| Works on localhost; blocked through a tunnel or LAN | Default auth allows only direct loopback callers. Share the host with `--bearer-token <secret>` (or authored `bearerAuth`). Use `--allow-anonymous` only on a trusted private network. |
+| A channel route fails to compile with a schema type error | `GET` routes need a Zod `querySchema`. `POST` / `PUT` / `PATCH` need a Zod `bodySchema`. Use `z.object({})` or `z.unknown()` for open shapes. |
+
+## What if GitHub webhooks misbehave?
+
+| What you see | What to do |
+| --- | --- |
+| `github forward` returns 401 on every delivery, but the hook was created | Clear `GITHUB_TOKEN` and `GH_TOKEN` for that command. The forwarder uses your `gh` CLI login: `GITHUB_TOKEN= GH_TOKEN= agentkit github forward …` |
+| `Hook already exists` when starting a forwarder | GitHub allows one forwarder per repo. Run a single `github forward --dir <parent>` and stop stale forwarders. |
+| Deliveries rejected outside `--dev` | Set `GITHUB_WEBHOOK_SECRET` on the server and on the signer. Without a secret, the channel stays loopback-only. |
+| You lack repo admin and can't forward | Use `agentkit github replay <pr-url>`. It needs pull access only and posts signed test payloads. |
+
+## What if Slack stays quiet?
+
+| What you see | What to do |
+| --- | --- |
+| Logs show `channel idle … missing credentials` | Expected when tokens are missing. Set `<PREFIX>_SLACK_BOT_TOKEN` and `<PREFIX>_SLACK_APP_TOKEN` per agent, then run `agentkit slack doctor --prefix <PREFIX>`. |
+| The bot ignores ordinary channel posts | Default engagement is mentions and DMs only. Enable `engagement.channelPosts` with an allowlist, and subscribe the app to `message.channels` / `message.groups`. |
+| Approve / Deny buttons do nothing | Re-import a Slack app manifest with interactivity enabled. Channels that post approval cards need `toolApprovals: true` (and `interactivity: true` when you compose events by hand). |
+
+## What if schedules, reminders, or approvals stall?
+
+| What you see | What to do |
+| --- | --- |
+| A schedule or reminder never fires under `--dev` | Dev mode does not auto-fire. Trigger with `POST /<slug>/v1/dev/schedules/<id>` or `POST /<slug>/v1/dev/reminders/<id>` (list reminders at `GET /v1/dev/reminders`). |
+| A pending tool approval disappeared after restart | Parked approvals do not survive host restart. They resolve as interrupted. Run the turn again. |
+| A reminder is disarmed after restart (`handler_lost_on_restart`) | Handler-form reminders live in memory. Re-arm them from the code that created them, or use prompt-form reminders. |
+
+## How do I read a session trace?
+
+Look at `actions.requested` / `action.result` pairs for the tool
+trajectory. Count calls by tool name before blaming latency. Separate
+host-side work (channel `callTool`, preparation) from tools the model
+chose.
+
+`turn.failed` with `"turn interrupted"` means a follow-up or stop ended
+the turn on purpose.
+
+If the model reads outside the session workspace, the prepared files
+don't match what the instructions expect. Fix the layout. See
+[Hillclimbing](./hillclimbing.md).
+
+`agentkit trajectory --events <file>` summarizes any saved NDJSON
+stream. The playground **Open trace** control does the same visually.
+
+## What's next
+
+- [Concepts](./concepts.md): the model behind these symptoms
+- [Hillclimbing](./hillclimbing.md): when the agent runs but underperforms
+- [Deployment](./deployment.md): auth and state on shared hosts

package/package.json

@@ -0,0 +1,185 @@
+{
+  "name": "@cursor/july",
+  "version": "0.1.1",
+  "description": "(early alpha) Filesystem-first framework for defining Cursor agents as markdown and TypeScript and serving them over channels with the Cursor SDK.",
+  "license": "SEE LICENSE IN LICENSE.md",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/cursor/cursor"
+  },
+  "homepage": "https://cursor.com",
+  "type": "module",
+  "main": "dist/index.js",
+  "module": "dist/index.js",
+  "types": "./dist/index.d.ts",
+  "bin": {
+    "agentkit": "./dist/bin/agent-serve.js",
+    "agent-serve": "./dist/bin/agent-serve.js"
+  },
+  "publishConfig": {
+    "access": "public"
+  },
+  "files": [
+    "dist/**/*",
+    "src/**/*",
+    "!src/**/*.test.ts",
+    "skills/**/*",
+    "!skills/operate/**",
+    "docs/**/*.md",
+    "!docs/.cursor/**",
+    "package.json",
+    "LICENSE.md",
+    "README.md",
+    "AGENTS.md"
+  ],
+  "exports": {
+    ".": {
+      "anysphere-source": "./src/index.ts",
+      "bun": "./src/index.ts",
+      "types": "./dist/index.d.ts",
+      "import": "./dist/index.js",
+      "default": "./dist/index.js"
+    },
+    "./tools": {
+      "anysphere-source": "./src/tools.ts",
+      "bun": "./src/tools.ts",
+      "types": "./dist/tools.d.ts",
+      "import": "./dist/tools.js",
+      "default": "./dist/tools.js"
+    },
+    "./channels": {
+      "anysphere-source": "./src/channels.ts",
+      "bun": "./src/channels.ts",
+      "types": "./dist/channels.d.ts",
+      "import": "./dist/channels.js",
+      "default": "./dist/channels.js"
+    },
+    "./channels/slack": {
+      "anysphere-source": "./src/channels/slack/index.ts",
+      "bun": "./src/channels/slack/index.ts",
+      "types": "./dist/channels/slack/index.d.ts",
+      "import": "./dist/channels/slack/index.js",
+      "default": "./dist/channels/slack/index.js"
+    },
+    "./channels/github": {
+      "anysphere-source": "./src/channels/github/index.ts",
+      "bun": "./src/channels/github/index.ts",
+      "types": "./dist/channels/github/index.d.ts",
+      "import": "./dist/channels/github/index.js",
+      "default": "./dist/channels/github/index.js"
+    },
+    "./skills": {
+      "anysphere-source": "./src/skills.ts",
+      "bun": "./src/skills.ts",
+      "types": "./dist/skills.d.ts",
+      "import": "./dist/skills.js",
+      "default": "./dist/skills.js"
+    },
+    "./schedules": {
+      "anysphere-source": "./src/schedules.ts",
+      "bun": "./src/schedules.ts",
+      "types": "./dist/schedules.d.ts",
+      "import": "./dist/schedules.js",
+      "default": "./dist/schedules.js"
+    },
+    "./reminders": {
+      "anysphere-source": "./src/reminders.ts",
+      "bun": "./src/reminders.ts",
+      "types": "./dist/reminders.d.ts",
+      "import": "./dist/reminders.js",
+      "default": "./dist/reminders.js"
+    },
+    "./connections": {
+      "anysphere-source": "./src/connections.ts",
+      "bun": "./src/connections.ts",
+      "types": "./dist/connections.d.ts",
+      "import": "./dist/connections.js",
+      "default": "./dist/connections.js"
+    },
+    "./hooks": {
+      "anysphere-source": "./src/hooks.ts",
+      "bun": "./src/hooks.ts",
+      "types": "./dist/hooks.d.ts",
+      "import": "./dist/hooks.js",
+      "default": "./dist/hooks.js"
+    },
+    "./evals": {
+      "anysphere-source": "./src/evals.ts",
+      "bun": "./src/evals.ts",
+      "types": "./dist/evals.d.ts",
+      "import": "./dist/evals.js",
+      "default": "./dist/evals.js"
+    },
+    "./ab": {
+      "anysphere-source": "./src/ab.ts",
+      "bun": "./src/ab.ts",
+      "types": "./dist/ab.d.ts",
+      "import": "./dist/ab.js",
+      "default": "./dist/ab.js"
+    },
+    "./package.json": {
+      "anysphere-source": "./package.json",
+      "bun": "./package.json",
+      "types": "./package.json",
+      "import": "./package.json",
+      "default": "./package.json"
+    }
+  },
+  "scripts": {
+    "build": "tsgo -p tsconfig.build.json && pnpm run build:playground && pnpm run docs:build",
+    "build:playground": "vite build --config playground/vite.config.ts",
+    "dev:playground": "vite --config playground/vite.config.ts",
+    "check": "biome check src && tsgo --noEmit && tsgo --noEmit -p playground/tsconfig.json",
+    "docs:dev": "vitepress dev docs",
+    "docs:build": "vitepress build docs",
+    "docs:preview": "vitepress preview docs",
+    "fix": "biome check --write --unsafe src",
+    "test": "vitest run --passWithNoTests",
+    "type-check": "tsgo --noEmit && tsgo --noEmit -p playground/tsconfig.json",
+    "build-dev": "echo noop",
+    "build-types": "tsgo -p tsconfig.build.json --emitDeclarationOnly",
+    "verify-publish": "node scripts/verify-publish-artifacts.mjs",
+    "smoke-publish": "node scripts/smoke-publish-artifact.mjs",
+    "publish-check": "pnpm run build && pnpm run verify-publish && pnpm run smoke-publish"
+  },
+  "engines": {
+    "node": ">=22.13"
+  },
+  "dependencies": {
+    "@cursor/sdk": "1.0.23",
+    "@modelcontextprotocol/sdk": "1.25.1",
+    "@octokit/auth-app": "^7.2.0",
+    "@octokit/rest": "^21.1.1",
+    "@slack/socket-mode": "^2.0.7",
+    "@slack/web-api": "^7.18.0",
+    "croner": "^8.0.1",
+    "javascript-time-ago": "^2.6.4",
+    "ms": "^2.1.3",
+    "tsx": "^4.0.0",
+    "zod": "^3.25.0",
+    "zod-to-json-schema": "^3.24.5"
+  },
+  "devDependencies": {
+    "@anysphere/ui": "workspace:*",
+    "@base-ui/react": "1.4.0",
+    "@stylexjs/stylex": "0.18.3",
+    "@stylexswc/rs-compiler": "^0.16.4",
+    "@tanstack/react-virtual": "3.13.23",
+    "@types/ms": "^2.1.0",
+    "@types/node": "catalog:",
+    "@types/react": "^19.0.0",
+    "@types/react-dom": "^19.0.0",
+    "@typescript/native-preview": "7.0.0-dev.20260701.1",
+    "@vitejs/plugin-react": "^5.1.2",
+    "pretty-ms": "^9.2.0",
+    "react": "^19.2.1",
+    "react-dom": "^19.2.1",
+    "react-markdown": "^10.1.0",
+    "remark-gfm": "^4.0.1",
+    "typescript": "catalog:",
+    "vite": "^7.3.0",
+    "vitepress": "1.6.4",
+    "vitest": "^4.0.18",
+    "zustand": "^5.0.9"
+  }
+}