@dench.com/cli 3.5.8-staging.350 → 3.6.0-staging.356

package/README.md

@@ -169,11 +169,11 @@ Other tool commands:
 dench tool status [toolkit] --json
 dench tool connect <toolkit> --json
 dench tool search "list recent gmail emails" --toolkit gmail
-dench tool run <composio_tool_slug> --args '{"key":"value"}' --json
+dench tool run <tool_slug> --args '{"key":"value"}' --json
 ```
 
-`dench tool connect gmail`, `outlook`, `linkedin`, and `calendar` print Unipile
-hosted-auth links using the same application, scopes, and callback as the web
+`dench tool connect gmail`, `outlook`, `linkedin`, and `calendar` print Dench
+sign-in links using the same application, scopes, and callback as the web
 app. Sign in with `dench signin` or use a member-owned Dench API key, then open
 the returned link to authorize your account. New mailbox and LinkedIn
 connections are private by default. An organization-only key cannot own a
@@ -182,9 +182,11 @@ personal connection.
 Check the result with `dench tool status <toolkit> --json`. `calendar` shows
 both Google and Outlook calendars; `google-calendar` (`googlecalendar`) and
 `outlook-calendar` (`outlookcalendar`, `microsoft-calendar`) select one provider.
-These status checks use Unipile-backed state without requiring Composio.
-Other toolkits keep their existing connection provider. `--callback-url` is
-only supported for Composio connections; Unipile uses Dench's managed callback.
+These status checks use Dench's own connection state and need no gateway key.
+Other toolkits connect as connected apps. `--callback-url` is only supported
+for connected apps; Dench-connected accounts use Dench's managed callback.
+In the JSON, each connection has a `source` of `app` or `dench`, and
+`nativeAvailable: false` means Dench-connected accounts could not be checked.
 
 Start with compact `dench tool search` output. It lists ranked tools with slug,
 toolkit, connection status, and read-only/approval hints. Add `--json` only when
@@ -309,35 +311,62 @@ CRM records. Inspect the actual Lead status options first. Omit `--status`
 to keep the default New; use `--enrichment enriched` for contact-bearing rows.
 Enrichment is optional for explicit imports. Import sets status only, even
 Qualified: it never purchases contacts, sends outreach, or converts records.
-See the [lead-finding workflow](../convex/lib/seedSkills/lead-finding.md)
-and [sales pipeline playbook](../public/references/SALES.md).
+See the `lead-finding` skill and the
+[sales pipeline playbook](https://dench.com/references/SALES.md).
 
 ## Outreach campaigns
 
 `dench campaign` runs email + LinkedIn outreach campaigns (the Outreach →
-Campaigns page) from the terminal: create one, set its send windows, replace
-its steps from a `steps.json`, fill it from a CRM view or explicit record
-ids, launch it once the readiness check passes, and watch it. `<campaign>`
-is an id or an exact, case-insensitive name.
+Campaigns page) from the terminal, from a brief to a launch: search for people
+with filters and exclusions, add them from a search, CSV, saved list, CRM view
+or one at a time, write the steps and AI-written lines, preview the exact
+messages, check readiness, launch, and follow the replies. `<campaign>` is an
+id or an exact, case-insensitive name. Confirm `dench campaign help` lists
+`draft`, `search`, `add`, `steps`, `person` and `preview`. It needs a workspace
+member's credentials (`dench signin`), a paid workspace for searches, and
+connected sender accounts (`dench campaign accounts` lists them).
 
 ```bash
-dench campaign accounts --json        # email + LinkedIn sender ids, availability and capacity
-dench campaign create --name "Founder outreach" --timezone America/Los_Angeles --window "Mon-Fri 9-18" --daily-cap 30 --email-mailboxes <mailboxId1>,<mailboxId2> --linkedin-accounts <linkedinId>
-dench campaign set <campaign> --email-mailboxes <mailboxId> --linkedin-accounts none
+dench campaign accounts --json        # email + LinkedIn sender ids, warm-up, availability and capacity
+dench campaign draft --name "Founder outreach" --request-id founders-q4 --timezone America/Los_Angeles --window "Mon-Fri 9-18" --daily-cap 30 --email-mailboxes <mailboxId1>,<mailboxId2> --linkedin-accounts <linkedinId>
+dench campaign search --filters '{"titles":["Founder"],"locations":["United States"]}' --not-industries "Staffing and Recruiting" --limit 25 --out audience.json
+dench campaign add <campaign> --people-file audience.json
 dench campaign steps set <campaign> --file steps.json
-dench campaign add <campaign> --object lead --view "Q3 targets"
+dench campaign personalize set <campaign> --file lines.json
+dench campaign preview <campaign> --person "Ada Lovelace"
+dench campaign launch <campaign> --check
 dench campaign launch <campaign> --ack-linkedin-risk
 dench campaign get <campaign>          # status, schedule, funnel, Now/Next, holds, people
+dench campaign replies <campaign> --since 7d
 dench campaign people <campaign> --status paused
 dench campaign events <campaign>
 dench campaign pause|resume|archive <campaign>
 dench campaign stop <campaign> --person <enrollmentId>
 ```
 
-`steps set` works on drafts only; after launch, edit a step's text or wait
-time in the Dench app. The schedule, daily cap and stop-on-reply stay
-editable with `dench campaign set`. A campaign
-holds at most 300 people. Every command takes `--json`. The full guide,
+`dench campaign create --name "Founder outreach"` makes the same kind of draft
+as `draft` (which also takes `--request-id`, so a retry returns the same
+draft). A search costs 1 cent per person returned and prints the most it can
+cost before it runs; `add --people-file` adds those people without searching
+again. Other ways to fill a campaign:
+`add <campaign> --csv people.csv`, `--list <artifactId>` (a saved Find list),
+`--search '<filters json>'` (search and add in one billed call),
+`--object lead --view "Q3 targets"`, `--object people --entries <id1>,<id2>`,
+or `--email ada@example.com` for one person. `--not-industries`,
+`--not-titles`, `--not-domains` and the other `--not-<filter>` flags leave
+values out of a search.
+
+A campaign holds at most 300 people; for more, `dench campaign duplicate
+<campaign>` makes a new draft with the same steps, schedule and senders, and no
+people, and the next page of the search goes into the copy. Fix a mistake in a
+draft with `dench campaign remove <campaign> --person <enrollmentId>` or
+`dench campaign person set`; `dench campaign sync` pulls new contact details
+from the CRM records. `steps set` replaces every step and works on drafts only;
+`steps edit --file steps.json` changes a step's text and waits in place, also
+after launch. `launch --check` never launches: it lists each blocker with the
+command that fixes it and exits 1 when blocked. The schedule, daily cap and
+stop-on-reply stay editable with `dench campaign set`. Every command takes
+`--json`. The full guide, from reading a brief to monitoring the launch,
 including the `steps.json` shape and the `--window` spec, is
 `references/CAMPAIGNS.md` (`dench campaign help` for the flag list).
 `dench email multichannel` drives the same campaigns with fewer controls.
@@ -365,8 +394,9 @@ is refused.
 ## Workspace sync
 
 Starting with CLI 2.9.8, `dench fs status` reports cached local daemon
-health, not a live comparison between disk and Convex. The status probe
-does not scan the workspace, contact Convex, or start a mount worker.
+health, not a live comparison between disk and the cloud copy. The status
+probe does not scan the workspace, contact the backend, or start a mount
+worker.
 
 ```bash
 dench fs status --json
@@ -399,20 +429,19 @@ Successful `--wait` means the downloaded original passed its SHA-256 check
 and the write finished before the deadline. Without `--wait`, success
 means only that the request was queued.
 
-See the [daemon isolation and rollout notes](../docs/agent-notes/sandbox-execution.md#workspace-sync-daemon-cli-298)
-for recovery limits and why an existing process does not hot-upgrade.
+A running daemon process does not hot-upgrade: restart it after installing a
+new CLI.
 
 ## Sandbox / API key auth (no `dench signin` required)
 
-Inside a Daytona sandbox the unified Dench API key is baked into envVars
-at create time (see `src/lib/secrets/sandbox-tokens.ts`). When
-`DENCH_API_KEY` and `CONVEX_URL` are both present, the CLI skips the
-`dench signin` flow entirely and uses the API key as a bearer for every
-org-scoped command — `dench crm`, `dench files`, `dench fs sync`, etc.
+Inside a Dench sandbox the Dench API key is set in the environment when the
+sandbox starts. When `DENCH_API_KEY` is present, the CLI skips the
+`dench signin` flow entirely and uses the key as a bearer for every org-scoped
+command — `dench crm`, `dench files`, `dench fs sync`, etc. The key targets
+production.
 
 ```bash
 export DENCH_API_KEY=dench_pk_live_…
-export CONVEX_URL=https://your-convex-deployment.convex.cloud
 # Optional but enables nicer URLs in CLI output:
 export DENCH_API_URL=https://app.dench.com
 export DENCH_ORG_ID=…
@@ -423,32 +452,13 @@ dench crm entries list people
 
 Auth precedence:
 
-1. Explicit `--dev` flag → use the dev workspace env (`NEXT_PUBLIC_CONVEX_URL`,
-   `DENCH_WORKSPACE`, `DENCH_DEV_AGENT_KEY`).
-2. A locally-stored `dench signin` session for the current backend (set via
-   `dench backend`, `--host`, `--prod`, or `--staging`).
-3. `DENCH_API_KEY` + `CONVEX_URL` (sandbox / automation path).
-
-Plain terminal usage does not silently fall back to dev env vars. Without
-`--dev`, a saved session, or `DENCH_API_KEY` + `CONVEX_URL`, live commands
-return `login_required`.
-
-### `.env` auto-load is opt-in
-
-When `dench` runs from inside the `dench.com` repo it does **not**
-auto-load workspace `.env` / `.env.local` files by default — that used
-to silently flip `NEXT_PUBLIC_CONVEX_URL` to the dev Convex deployment
-and made the CLI talk to local Convex even when the user expected
-production.
-
-Auto-load now turns on only when one of:
-
-- `--dev` (also switches the runtime to dev-workspace mode)
-- `--use-dev-env` (load `.env` files but keep the rest of the runtime)
-- `DENCH_USE_DEV_ENV=1` in the shell env (e.g. via `direnv`)
-- `dench backend set local` (a stored local backend implies dev env)
+1. A locally-stored `dench signin` session for the current backend (set via
+   `dench backend`, `--host`, `--prod`, or `--staging`; `DENCH_HOST=<url>`
+   does the same for one command).
+2. `DENCH_API_KEY` (sandbox / automation path).
 
-Explicit shell exports (`GATEWAY_URL=… ./dench …`) always win regardless.
+Plain terminal usage without a saved session or `DENCH_API_KEY` returns
+`login_required`.
 
 Commands that need to impersonate a specific agent (`dench memory`,
 `dench approval request`, etc.) still require an agent session