@cursor/july 0.1.92 → 0.1.94

package/docs/evals.md

@@ -16,12 +16,6 @@ targets) a real agent server, drives sessions over the public API, and
 grades what comes back. A passing eval means the agent started,
 accepted a message, and did what you asserted.
 
-> [!NOTE]
-> Import paths here use `@cursor/july/evals`. On projects still
-> using `@anysphere/agent-serve`, swap the import and run
-> `agent-serve eval`. See
-> [Run the CLI](/#run-the-cli) for the full rename table.
-
 ## Define evals with `defineEval`
 
 The Agent SDK discovers evals under the project-root `evals/` directory,
@@ -125,7 +119,7 @@ export default defineEvalConfig({
   // timeoutMs: 180_000, // optional project-wide default
   // judge: { model: "..." }, // default judge model for t.judge.*
   // reporters: [], // destinations that observe every case
-  // maxPlaygroundRuns: 50, // playground /v1/dev/evals history only (default 20)
+  // maxPlaygroundRuns: 50, // playground history only (default 20)
 });
 ```
 
@@ -139,7 +133,7 @@ The optional fields:
 | `timeoutMs` | `180_000` | Project-wide per-case timeout |
 | `judge` | unset | Default judge model for `t.judge.*`; see [Judge free-form output](#judge-free-form-output) |
 | `reporters` | unset | Destinations that observe every case; `--skip-report` suppresses them |
-| `maxPlaygroundRuns` | `20` | Max batches in the playground / `/v1/dev/evals*` history (not CLI `eval`) |
+| `maxPlaygroundRuns` | `20` | Max batches in the playground / `/v1/dev/evals*` history (not CLI `eval`). Hard-capped at 500. |
 
 Reporters come from `@cursor/july/evals/reporters`: `JUnit` writes a
 JUnit XML file for CI, `Artifacts` writes per-case files, and
@@ -151,7 +145,7 @@ Playground batches survive restarts whenever `agent/storage.ts` exists
 with an `evals` table or a KV core providing `delete` and `list` (the
 table is derived over the core); see
 [Storage](./storage.md#eval-and-a-b-tables). Without storage they live
-in process memory and disappear when `serve` exits — navigating away
+in process memory and disappear when `serve` exits. Navigating away
 and back still works while the process is up.
 
 ## Drive and assert with `t`
@@ -171,9 +165,9 @@ intermediate turn before the next send overwrites `t.reply`.
 depend on it.
 
 Read the full case state with `t.reply` (the last assistant text),
-`t.events` (every captured session event across turns), `t.turns`
-(settled turns, oldest first), and `t.sessionId`. `t.signal` aborts
-when the case hits its timeout; pass it to your own async work.
+`t.events` (session events captured so far), `t.turns` (settled
+turns, oldest first), and `t.sessionId`. `t.signal` aborts when the
+case hits its timeout; pass it to your own async work.
 
 Assert with the gates:
 
@@ -229,10 +223,10 @@ the CLI and playground result.
 
 Three `t.send` options apply on session create (first `t.send` only):
 
-- `workspaceFiles` — `{ path: contents }`, seeded into the local session
+- `workspaceFiles`: `{ path: contents }`, seeded into the local session
   workspace. Prefer this over machine-local paths.
-- `workspaceDir` — absolute harness cwd (local runtime).
-- `cloud` — per-session cloud options merged over the agent's static
+- `workspaceDir`: absolute harness cwd (local runtime).
+- `cloud`: per-session cloud options merged over the agent's static
   `cloud` config (repos / env / …). Use a pinned `repos` override to
   attach a fixture repo for cloud evals without putting it on the
   agent's default `cloud.repos`. Cloud ignores `workspaceFiles` seeds.
@@ -294,7 +288,7 @@ match both groups.
 
 `eval` boots an ephemeral server on port 0 with a temp state root
 outside the project, so cases don't inherit ambient monorepo rules and
-don't pollute `.agent-serve/`. Point `--url` at a running server to eval
+don't write into the project state directory. Point `--url` at a running server to eval
 a live agent instead:
 
 ```bash
@@ -348,29 +342,18 @@ failed assertion without parsing terminal text.
 
 ## Run evals in the playground
 
-Start the server with `--dev`, open the playground, and choose
-**Evals**. You can run every case or one case, watch progress, and open
-the resulting session trace.
+Start the server, open the playground, and choose **Evals**. You can run
+every case or one case, watch progress, and open the resulting session
+trace. The Evals tab works on a normal `serve`.
 
 ```bash
-agent-sdk serve --dir . --dev
+agent-sdk serve --dir .
 ```
 
 Playground runs target the live server instead of an ephemeral one.
 Their sessions appear in the session list. One eval batch can run at a
-time. Batches persist across restarts whenever `agent/storage.ts`
-provides an `evals` table or a KV core with `delete` and `list` (the
-table is derived over the core); without storage they are **in-memory
-only** (capped by `maxPlaygroundRuns`) — see
-[Storage](./storage.md#eval-and-a-b-tables).
-
-The UI uses the playground eval routes (available without `--dev`):
-`GET /v1/dev/evals` lists datapoints and config (includes `maxPlaygroundRuns` /
-`durableRuns`),
-`GET /v1/dev/evals/runs` rehydrates recent batches after navigation,
-`POST /v1/dev/evals/runs` starts a batch (returns an **Eval ID** / `runId`),
-`GET /v1/dev/evals/runs/:runId` polls it, and
-`POST /v1/dev/evals/runs/:runId/cancel` cancels a running batch. See
+time. Persistence follows the rule under
+[Configure eval runs](#configure-eval-runs). See
 [Playground eval routes](./reference/http-api.md#playground-eval-routes).
 The start request returns `202` while cases run in the background.
 Poll until the snapshot status becomes `completed`, `failed`, or `cancelled`.
@@ -389,10 +372,6 @@ agent-sdk eval cancel evalrun_… --prod --slug vulnerability-scanner
 agent-sdk eval status evalrun_… --prod --slug vulnerability-scanner
 ```
 
-The Evals tab prefers the server’s in-flight batch (`activeRunId`) over a
-stale tab-local remembered id, so CLI / Slack kicks show up without an
-incognito window.
-
 ## What good cases assert
 
 Gate decisions and shape, not prose. Model wording varies run to run.

package/docs/guides/agent-to-agent.md

@@ -14,7 +14,7 @@ same. A peer MCP connection makes the wiring one line.
 This guide wires a `concierge` agent that delegates weather questions
 to a `weather-agent` peer mounted on the same host.
 
-## The MCP endpoint
+## MCP endpoint
 
 Each agent serves the Model Context Protocol over streamable HTTP at
 `/<slug>/v1/mcp` (or `/v1/mcp` in single mode). The surface is stateless
@@ -104,8 +104,8 @@ Peer MCP connections are ordinary MCP connections, so deterministic host code
 can use them too. A channel handler or server tool can call
 `host.mcp.callTool("weather", "ask", { message: "…" })` without any
 model turn deciding to. See
-[MCP connections](../reference/connections.md#every-mcp-connection-is-available-in-three-places)
-for the three places every MCP connection is available.
+[MCP connections](../reference/connections.md#every-model-visible-mcp-connection-is-available-in-three-places)
+for the three places every model-visible MCP connection is available.
 
 ## What's next
 

package/docs/guides/cloud-runtime.md

@@ -64,34 +64,22 @@ mapping shifts:
 | `instructions.*` | `AGENTS.md` in the session workspace | prepended to the first prompt |
 | Server tools (`execution: "server"`) | in-process SDK custom tools | authenticated HTTP MCP back to the AgentSDK host, when `--public-url` or `--cloud-tools-url` is set |
 | Agent tools (`execution: "agent"`) | scripts in the session workspace | catalog + script bodies on the first prompt |
-| `skills/*` | `.cursor/skills/` in the workspace | native discovery from the Agent Store (`skills/` on hosted deployments; `agent-serve/<agent>/skills/` on the USER store for local serve/run) |
+| `skills/*` | `.cursor/skills/` in the workspace | native discovery after the first turn, from the hosted store or the signed-in account |
 | `mcp-connections/*.ts` | SDK `mcpServers` | SDK `mcpServers` (peers need `--public-url`) |
+| `host-connections/*.ts` | `ctx.host.mcp` only | `ctx.host.mcp` only |
 | `sandbox/workspace/**` | seeded into the session workspace | ignored |
 | Tool approvals (`needsApproval`) | supported | not supported; keep approval-gated tools on local turns |
 
-Authored skills copy onto an Agent Store on the first cloud turn so the
-VM discovers them natively. Hosted deployments write the deployment
-store's `skills/` directory; local `serve`/`run` with a personal API
-key writes `agent-serve/<agent>/skills/` on the USER store.
-
-Hosted deployments configure the server-tool MCP URL automatically
-(`cloudToolsUrl`, authenticated with the resolved Cursor API key). A
-self-hosted public server needs `--public-url` (and `--bearer-token` when the
-host is not behind another trusted authentication boundary) so cloud turns
-can reach those tools. Without either, the server warns at startup and
-cloud turns omit the server tools.
+Authored skills are discovered natively after the first cloud turn,
+using the hosted store or the signed-in account.
 
 Approvals are a local-runtime contract. On cloud, a `needsApproval` tool
 call rides one HTTP MCP request from the VM, and a parked call would
 hold that request open until it times out; there is no durable approval
 flow for cloud turns.
 
-Two more behaviors are cloud-specific. Sessions persist a separate SDK
-agent id (`bc-…`), emitted on the stream as `agent.bound` with a URL to
-the cloud conversation. Cloud ids are minted during the first send. And
-peer MCP connections resolve to `--public-url` for cloud turns, because a VM
-cannot reach the host's loopback; without one, peers are omitted from
-cloud turns and the server warns at startup.
+Peer MCP connections need `--public-url` for cloud turns. Without one,
+peers are omitted and the server warns at startup.
 
 ## Hybrid: local agent, cloud sessions
 
@@ -106,12 +94,8 @@ base that per-session options merge over.
 
 These come from running a PR driver against real PR traffic:
 
-- One cloud agent per unit of work (per PR, say). Store the `bc-…` id
-  keyed by the work unit (an affinity store written from an
-  `agent.bound` hook) so webhook wakes resume the same conversation
-  instead of booting a fresh VM per event.
-- Stable continuation keys (`pr:owner/repo#N`) so every wake lands on
-  the same session within a channel.
+- One cloud session per unit of work, keyed with a stable continuation
+  token (`pr:owner/repo#N`) so every wake lands on the same conversation.
 - Keep the host deterministic: fetch briefs and metadata on the host,
   send the VM a compact prompt, and let the VM re-read source of truth
   with its own `gh` and `git` instead of trusting payload snapshots.
@@ -131,6 +115,6 @@ driving channels directly.
 Continue with these pages:
 
 - [Agent config](../reference/agent-config.md): the `runtime` and
-  `cloud` fields precisely
+  `cloud` fields
 - [GitHub guide](./github.md): the webhook patterns that pair with
   cloud triage

package/docs/guides/convert-automation.md

@@ -42,9 +42,9 @@ cd nightly-triage
 ```
 
 The command fetches the Automation before writing files. A 404 means it
-was not found, you do not have access, or the `agent_serve_mvp` feature
-gate is off for your team. A 422 means it is Cursor-managed. The command
-writes nothing after either error.
+was not found, you do not have access, or convert is not enabled for
+your team. A 422 means it is Cursor-managed. The command writes nothing
+after either error.
 
 The command runs `npm install` after writing the project. If the install
 fails, the files remain. Run `npm install` in the output directory
@@ -78,7 +78,7 @@ or run lifecycle scripts from an existing `package.json`.
 | Prompt model | Pins the model on `defineAgent` in `agent/agent.ts`. `git_config` and `agent_options` remain comments. |
 | Cron trigger | Creates `agent/schedules/<slug>.ts` with `defineSchedule` in UTC. |
 | GitHub trigger | Creates `agent/channels/github.ts`. It converts pull-request action, push branch, issue action, and user allowlist filters. |
-| Slack trigger | Creates `agent/channels/slack.ts`. Mention-only uses `cursorAccount`; watches, reactions, and channel-created triggers use Socket Mode. Watches add `engagement.channelPosts`. |
+| Slack trigger | Creates `agent/channels/slack.ts` as Socket Mode with `envPrefix` from the automation name (same names `slack create` writes). Watches add `engagement.channelPosts`. Run `agent-sdk slack create` for the bot. |
 | Linear, PagerDuty, Sentry, Teams, or generic webhook | Creates a boilerplate `agent/channels/<slug>.ts`. |
 | HTTP or SSE MCP server | Creates a name-based Cursor-account connection under `agent/mcp-connections/`. The project contains no server URL or credentials. |
 | Stdio MCP server | Writes `agent/mcp-connections/<slug>.todo.md`. |

package/docs/guides/github.md

@@ -49,8 +49,9 @@ Choose `permissions` by what the agent needs:
 `contents-write` is an explicit opt-up. `progress.commitStatus` posts a
 GitHub check run (`checks:write`). Hosted `cursorAccount` mints that
 permission on `"contents-write"` tokens. Enabling `commitStatus` opts a
-`"pr-write"` channel up to that tier so github-proxy can post the check.
-`"pr-write"` without `commitStatus` is enough for comments and banners.
+`"pr-write"` channel up to that tier because it needs check-write
+permission. `"pr-write"` without `commitStatus` is enough for comments
+and banners.
 Prefer `"pr-write"` unless the agent must push or post a merge-box check.
 
 Set `checks: true` when channel code posts its own Checks API runs through
@@ -70,10 +71,9 @@ Repeat `--repo` for each repository. The stream and credential are
 resolved as the signed-in Cursor principal. `serve` refuses to start
 signed out.
 
-Offset and consumer id live under `<state-root>/cursor-events/`.
-`CURSOR_API_BASE_URL` overrides the backend. The stream carries event
-metadata, not full webhook bodies, so your agent should re-read the PR
-or checks from GitHub instead of trusting a snapshot in the wake.
+The stream carries event metadata, not full webhook bodies, so your
+agent should re-read the PR or checks from GitHub instead of trusting a
+snapshot in the wake.
 
 This is the preferred production path: no public URL, no repo admin
 webhook, and no inbound network for GitHub deliveries.
@@ -111,7 +111,7 @@ things:
 | `{ task }` | Host-side work. The delivery is 202-ACKed immediately and the task runs past GitHub's ~10-second timeout. No chat session. |
 | `null` | Skip this delivery. |
 
-`{ auth }` may also carry `workspaceFiles` — the same session seed Slack
+`{ auth }` may also carry `workspaceFiles`, the same session seed Slack
 and `send()` use. Pass a function to fetch after a 202 so I/O can miss
 GitHub's ~10s window.
 
@@ -198,9 +198,7 @@ These patterns come from running a PR agent against real traffic:
 - Persist the buffer in `host.kv` before you acknowledge a wake, and
   restore it on channel start. A restart must not drop buffered wakes.
 - Key sessions with a stable continuation token (`pr:owner/repo#N`) so
-  every wake resumes the PR's conversation. Cross-channel resume needs
-  an affinity store mapping PR → SDK agent id; write it from an
-  `agent.bound` hook with `ctx.host.kv`.
+  every wake resumes the PR's conversation.
 - Keep payload details out of wake prompts. Send a generic "re-check
   the PR" and let the agent re-read source of truth instead of trusting a
   stale snapshot.
@@ -262,24 +260,14 @@ behavior. Reactions still default on; set `reactions: false` when the
 eyes emoji is noise. Descriptions are optional; defaults derive from
 `botName` or the check `context`.
 
-The check run posts to `channel.state.headSha`. PR and CI wakes seed and
-refresh it (`refreshState` on continuation). A first wake that is only an
-`issue_comment` has no head SHA in the payload, so the check is skipped until
-a PR/CI wake stores one; the banner still posts. Review-comment wakes
-carry `pull_request.head.sha` when GitHub includes it.
-
-The sticky comment id and latest check-run id live on durable
-`GitHubChannelState` (session record). Each wake also passes `refreshState`
-so `headSha` / refs update on continuation without wiping those ids. A later
-turn on the same SHA creates a new check run — GitHub cannot reopen a
-completed run. Persist other derived state
-with `ctx.host.kv` or `ctx.host.files`. `stateRoot` resets on hosted
-replace.
-
-Override `events` when the mapping is custom. [Approval Buddy](../example-agents/approval-buddy.md)
-posts commit status from `turn.started` / `action.result` / `turn.failed`
-and stays never-red; that pattern still wins when you replace a default
-handler key. Handlers you author replace the matching defaults (same as
+A comment-only first wake has no head SHA, so the check waits for a
+PR or CI event. The banner still posts. A later turn on the same SHA
+creates a new check run; GitHub cannot reopen a completed run.
+
+Override `events` when the mapping is custom. A handler can post commit
+status from `turn.started` / `action.result` / `turn.failed` and stay
+never-red; that pattern still wins when you replace a default handler
+key. Handlers you author replace the matching defaults (same as
 `progress.reactions` composition today).
 
 ## Related

package/docs/guides/mcp-oauth.md

@@ -18,14 +18,12 @@ The companion skill is
 
 - Authorize `defineConnection({ url, oauth: true })` with a browser PKCE
   flow (`agent-sdk mcp oauth <connection>`)
-- Keep tokens in `~/.config/agent-serve/mcp-auth.json`, bound to that
-  connection's resource URL
+- Keep tokens in `mcp-auth.json` under the CLI config directory, bound
+  to that connection's resource URL
 - Upsert deployment secrets with `--store` so hosted engines seed the
   same tokens from env
-- Keep privileged servers off the model with `hostOnly: true` while
-  tools still call them through `ctx.host.mcp`. Do not set `hostOnly` on
-  connectors the playground or local chat should call. Use
-  `advertiseTools: true` for those.
+- Use `advertiseTools: true` when local turns should call the server by
+  name. Host tools can still call it through `ctx.host.mcp`.
 
 Prefer a Cursor account MCP connection when the connector already lives
 in the signed-in account dashboard:
@@ -40,7 +38,8 @@ and the host must hold tokens.
 
 ## How do I declare a host-OAuth connection?
 
-Add one file under `agent/mcp-connections/`. The filename is the
+Add one file under `agent/mcp-connections/` (model + host) or
+`agent/host-connections/` (host + `mcp oauth` only). The filename is the
 connection name you pass to the CLI and to `host.mcp`.
 
 ```ts
@@ -50,17 +49,14 @@ import { defineConnection } from "@cursor/july/connections";
 export default defineConnection({
   url: "https://mcp.example.com/inventory",
   oauth: true,
-  hostOnly: true,
-  description:
-    "Inventory MCP (privileged). Call only from host tools, not the model.",
+  description: "Inventory MCP.",
 });
 ```
 
 Rules of the road:
 
 - `oauth: true` is required for `agent-sdk mcp oauth`
-- `hostOnly: true` hides the server from the model; `ctx.host.mcp` and
-  channel handlers still see it
+- A file under `mcp-connections/` is visible to the model and to `ctx.host.mcp`. A file under `host-connections/` stays on the host.
 - Declare expected secret names on the agent when you plan to `--store`:
 
 ```ts
@@ -93,12 +89,11 @@ agent-sdk mcp oauth inventory
 
 What happens:
 
-1. The Agent SDK loads `agent/mcp-connections/inventory.ts` and checks
-   `oauth: true`
+1. The Agent SDK loads the connection file and checks `oauth: true`
 2. It opens the authorization URL in your browser
 3. The callback lands on `http://localhost:8787/callback`
-4. Tokens land in `~/.config/agent-serve/mcp-auth.json` (override the
-   config dir with `AGENT_SERVE_CONFIG_DIR`)
+4. Tokens land in `mcp-auth.json` under the CLI config directory
+  (override with `AGENT_SERVE_CONFIG_DIR`)
 
 If you're already authorized, the command prints that and exits. Re-run
 it after rotating tokens on the MCP server, or after you change the
@@ -133,8 +128,6 @@ on the pod.
 
 ## How do host tools call the server?
 
-Keep privileged calls on the host:
-
 ```ts
 const result = await ctx.host.mcp.callTool(
   "inventory",
@@ -143,9 +136,8 @@ const result = await ctx.host.mcp.callTool(
 );
 ```
 
-The model never sees `hostOnly` tools in its MCP namespace list. If the
-agent asks to "check IDE MCP" or run `mcp_auth`, point it at your host
-tool instead.
+The model can call the same server. Use a host tool when the write needs
+an allowlist or other deterministic gate.
 
 ## What if authorization fails?
 
@@ -158,7 +150,7 @@ tool instead.
 
 ## What's next
 
-- [MCP connections](../reference/connections.md): transports, `hostOnly`, account MCP
+- [MCP connections](../reference/connections.md): transports, account MCP
 - [CLI](../reference/cli.md#mcp-oauth): full flag list for `mcp oauth`
 - [Deployment](../deployment.md): secrets, egress, and hosted engines
 - [Fix common agent problems](../troubleshooting.md): more symptom → fix tables

package/docs/guides/slack.md

@@ -1,14 +1,14 @@
 ---
 title: "Slack"
-description: "Put the agent in Slack: Cursor-hosted connection, a dedicated Socket Mode app via the dashboard wizard, or a manual manifest import."
+description: "Put the agent in Slack: a dedicated Socket Mode app via the dashboard wizard, or a manual manifest import."
 ---
 
 # Slack agents
 
-The Slack channel puts your agent in Slack. Two products: the Cursor-hosted
-connection (`cursorAccount: true`), or a dedicated Socket Mode app created
-in the dashboard wizard (`agent-sdk slack create`). To own the Slack app
-yourself, run `agent-sdk slack init --manual` and paste the manifests at
+The Slack channel puts your agent in Slack as its own Socket Mode bot.
+`agent-sdk slack create` opens the dashboard wizard and writes tokens
+to `.env.local`. To own the Slack app yourself, run
+`agent-sdk slack init --manual` and paste the manifests at
 [api.slack.com](https://api.slack.com/apps). Socket Mode has no
 public Request URL. Replies stream in threads, with tool "thinking" steps,
 suggested prompts, and opt-in approval buttons.
@@ -47,41 +47,12 @@ Missing tokens leave the channel idle (`channel idle … missing
 credentials`) rather than failing `serve`. That's useful when you mount
 many agents and only some have Slack apps.
 
-## Use the Cursor Slack connection
-
-If the Cursor Slack app is already installed in your workspace and linked
-to your Cursor account, skip the dedicated Slack app:
-
-```ts
-import { slackChannel } from "@cursor/july/channels/slack";
-
-export default slackChannel({
-  cursorAccount: true,
-  agentName: "Weatherbot", // single token — no spaces; defaults from mount slug (PascalCase)
-  agentIcon: { emoji: ":robot_face:" },
-});
-```
-
-Sign the host in (`agent-sdk login` or `CURSOR_API_KEY`), then mention the
-agent in Slack as `@Cursor Weatherbot …`. Thread replies and DMs keep going to
-the same agent. Messages appear as the Cursor app under that agent's name
-and icon. Slack shows its working status, then posts one final reply.
-
-Use a dedicated Socket Mode Slack app when you need your own bot user,
-channel watching (`engagement.channelPosts`), or approval buttons. On
-`cursorAccount`, agents must be explicitly addressed (@mention, DM, or
-claimed-thread reply). Channel watching and `toolApprovals` /
-`interactivity` are Socket Mode only; the Cursor connection does not relay
-Block Kit clicks. Agent names must be unique on the host; an unmatched
-`@Cursor <name>` stays on Cursor's normal Slack agent.
-
 ## Control who can message the agent
 
 External senders are blocked by default. Slack Connect users, guests, and
 people whose home workspace is not the install team never reach the
-handler. That applies to Socket Mode and `cursorAccount: true`. Set
-`blockExternals: false` only when the agent should serve people outside
-your org:
+handler. Set `blockExternals: false` only when the agent should serve
+people outside your org:
 
 ```ts
 export default slackChannel({
@@ -127,7 +98,7 @@ writes `<PREFIX>_SLACK_BOT_TOKEN` and `<PREFIX>_SLACK_APP_TOKEN` into
 [below](#wire-the-env-and-verify).
 
 If Slack needs a workspace admin to approve the app, keep the CLI
-running. Managed install does not file the request — open Slack's
+running. Managed install does not file the request. Open Slack's
 **Request approval** page (the CLI prints the link; the same URL is
 **Send a reminder** after you submit). After an admin approves, click
 **Retry** in the wizard.
@@ -190,9 +161,9 @@ option.
 agent-sdk slack init --manual --dir . --name "My Agent"
 ```
 
-That writes `agent/channels/slack.ts`, importable manifests at
-`.agent-serve/slack/manifest.{dev,prod}.json`, `env.example`, and
-`setup-status.json`. `--no-prefix` uses shared `SLACK_*` variables on
+That writes `agent/channels/slack.ts`, Slack manifests under the
+project state directory, `env.example`, and `setup-status.json`.
+`--no-prefix` uses shared `SLACK_*` variables on
 a single-agent host. `--prefix CUSTOM` overrides the directory-derived
 prefix. `--channel-posts` subscribes the manifests to channel-post
 events.
@@ -244,8 +215,7 @@ export default slackChannel({
 ```
 
 Channel watching needs the `message.channels` / `message.groups` events
-on the Slack app (Socket Mode only; not available with
-`cursorAccount: true`). Pass `--channel-posts` on `slack create` or
+on the Slack app. Pass `--channel-posts` on `slack create` or
 `slack init --manual`. The bot must also be a member of each watched
 channel.
 
@@ -255,9 +225,7 @@ Set `includeBotPosts: true` when the posts worth watching come from bots:
 alert feeds, webhook integrations, or other agents posting notes. The
 watching app's own posts stay dropped either way, matched by the `bot_id`
 and bot user id from `auth.test`, so an agent can never dispatch on its
-own replies. The
-[alert investigator example](../example-agents/oncall.md) watches a
-bot-fed alerts channel this way.
+own replies. Use this for a bot-fed alerts channel.
 
 ## Prepare work on the host
 
@@ -286,11 +254,6 @@ Approval cards need interactivity on the Slack app. Recreate with
 `buildToolApprovalEvents({ credentials })` into `events` and set
 `interactivity: true` on the channel so Socket Mode routes the clicks.
 
-Approval buttons need Socket Mode. `slackChannel({ cursorAccount: true })`
-rejects `toolApprovals` and `interactivity` at construction, since the
-Cursor Slack connection does not relay Block Kit clicks. Use a dedicated
-Slack app to run approvals for a cursor-account agent.
-
 Cards show redacted, truncated arguments (Block Kit size limits);
 execution still uses the full validated input, so review sensitive tools
 in the playground when the arguments may exceed the card. Approvals
@@ -322,7 +285,7 @@ Two habits matter most.
 The `slack` subcommands cover setup end to end.
 
 ```bash
-agent-sdk slack setup                     # two-product chooser plus manual phases
+agent-sdk slack setup                     # printed setup guide
 agent-sdk slack create --dir .            # dashboard wizard (dev app)
 agent-sdk slack create --dir . --prod     # prod app
 agent-sdk slack destroy --dir .           # delete the provisioned app

package/docs/guides/webhooks.md

@@ -16,8 +16,8 @@ mechanism. This page is the mechanism itself.
 The built-in HTTP channel is always mounted (under `/<slug>` in the
 default multi-agent layout). `POST /v1/session` starts a conversation,
 `POST /v1/session/:id` follows up, and `GET /v1/session/:id/stream`
-streams NDJSON events, plus sessions, approvals, and tool routes. The
-full list is in the [HTTP API reference](../reference/http-api.md).
+streams NDJSON events, plus sessions, approvals, and tool routes. See
+the [HTTP API reference](../reference/http-api.md).
 
 Write a custom channel when that shape doesn't fit: a webhook with its
 own payload contract, a surface that keys sessions by a domain id, or a
@@ -451,7 +451,7 @@ Start with curl and saved payloads under `fixtures/`. The playground's
 endpoint, has Copy curl, and opens the created session on a successful
 Try. For regression coverage, drive the same behavior through an eval,
 or keep channel logic deterministic in `agent/lib/` and unit-test it
-there. When something looks wrong, read the session's `events.ndjson`.
+there. When something looks wrong, inspect the session event stream.
 The stream is the record of what happened.
 
 For GitHub specifically, don't hand-roll fixtures.

package/docs/hillclimbing.md

@@ -56,7 +56,7 @@ Pin the input first. A moving fixture is noise. For GitHub agents, use `agent-sd
 
 ## How do I run one hillclimb round?
 
-**Measure.** Hit the agent the way a user would: playground, channel HTTP, or Slack in `--dev`. Or ask the hillclimb skill to do it. `agent-sdk run` returns a JSON trajectory and writes a trace under `.agent-serve/traces/`.
+**Measure.** Hit the agent the way a user would: playground, channel HTTP, or Slack in `--dev`. Or ask the hillclimb skill to do it. `agent-sdk run` returns a JSON trajectory and writes a trace under the project state directory.
 
 **Reflect.** Score the trajectory, not impressions. Was the answer right? Did the model thrash (too many tools, fat evidence, grep loops)? Did it invent work the host should have prepared? Name the single dominant problem for this round in one sentence. Example: "Full-file dumps trigger grep loops."
 

package/docs/quickstart.md

@@ -21,7 +21,7 @@ review. Add GitHub event handling so pull requests can trigger reviews.
 - Node 22.13 or newer. Bun isn't supported.
 - Run commands as `agent-sdk <command>`, or use
   `npx @cursor/july <command>` when the CLI isn't on `PATH`. See
-  [Run the CLI](/#run-the-cli) for monorepo checkouts and other setups.
+  [Run the CLI](/#run-the-cli) if `agent-sdk` is not on `PATH`.
 - A Cursor credential for model turns. Sign in once:
 
 ```bash
@@ -356,9 +356,8 @@ See [GitHub](./guides/github.md) for local event delivery and
 
 ## Where to go next
 
-- [`examples/approval-buddy`](../examples/approval-buddy/): an example
-  with commit statuses, review subagents, and a deterministic stamp
-  policy
+- [PR autofixer template](./templates/pr-autofixer.md): drive a PR on a
+  Cursor cloud VM
 - [Evals](./evals.md): freeze these two PRs as regression checks so
   prompt changes can't flip a verdict
 - [Tools](./reference/tools.md): more on typed tools, approvals, and