@vellumai/assistant 0.6.5 → 0.7.0

package/docs/skills.md

@@ -14,7 +14,7 @@ Skill-origin tools follow a stricter default permission policy than core tools:
 
 | Scenario                                          | Core tool behavior            | Skill tool behavior |
 | ------------------------------------------------- | ----------------------------- | ------------------- |
-| Low risk, no matching rule                        | Auto-allowed (workspace mode) | **Prompted**        |
+| Low risk, no matching rule                        | Auto-allowed (at default threshold) | **Prompted**        |
 | Medium risk, no matching rule                     | Prompted                      | Prompted            |
 | High risk, no matching rule                       | Prompted                      | Prompted            |
 | Allow rule matches, non-high risk                 | Auto-allowed                  | Auto-allowed        |
@@ -25,7 +25,7 @@ Even if a skill's `TOOLS.json` declares `"risk": "low"` for one of its tools, th
 
 ## Skill Load Approval
 
-The `skill_load` tool activates a skill within the current session. In **strict mode** (`permissions.mode = 'strict'`), loading a skill requires an explicit matching trust rule. In **workspace mode** (default), `skill_load` is prompted unless a matching trust rule exists.
+The `skill_load` tool activates a skill within the current session. When `autoApproveUpTo` is set to `"none"`, loading a skill requires an explicit matching trust rule. At the default threshold (`"low"`), `skill_load` is prompted unless a matching trust rule exists.
 
 When `skill_load` is invoked, the permission checker generates multiple command candidates for rule matching:
 
@@ -87,11 +87,11 @@ The path classifier resolves symlinks before checking paths against skill root d
 
 The `normalizeFilePath()` function walks up the directory tree to find the nearest existing ancestor, resolves it via `realpathSync`, and re-appends the remaining segments.
 
-## Strict Mode
+## Strict Threshold (`autoApproveUpTo: "none"`)
 
-When `permissions.mode` is set to `strict` in the assistant configuration, **all** tool actions require a matching trust rule. There is no implicit auto-allow for any risk level. This means:
+When the gateway threshold is set to `"none"`, **all** tool actions require a matching trust rule or explicit approval. There is no implicit auto-allow for any risk level. This means:
 
-- Low-risk tools that would normally auto-execute in workspace mode (e.g., `file_read`, `web_search`) will prompt unless a trust rule allows them.
+- Low-risk tools that would normally auto-execute at the default threshold (e.g., `file_read`, `web_search`) will prompt unless a trust rule allows them.
 - `skill_load` requires an explicit rule match, even though it is classified as low risk.
 - The **starter bundle** can be accepted to seed common safe rules and reduce prompt noise.
 
@@ -137,15 +137,15 @@ Writing to skill source paths is classified as high risk because it could alter
 
 **Fix**: If you trust the operation, approve it. To permanently allow it, select "Always allow". Note that high-risk file operations will still prompt for each invocation since runtime auto-allow only applies to containerized bash.
 
-### "Why is strict mode prompting for everything?"
+### "Why is everything prompting?"
 
-Strict mode requires an explicit trust rule for every tool action. There is no implicit auto-allow.
+When `autoApproveUpTo` is set to `"none"`, every tool action requires an explicit trust rule or approval. There is no implicit auto-allow for any risk level.
 
-**Fix**: Accept the starter approval bundle to seed common safe rules. Then approve additional tools as needed — each approval creates a persistent trust rule.
+**Fix**: Accept the starter approval bundle to seed common safe rules. Then approve additional tools as needed — each approval creates a persistent trust rule. Alternatively, raise `autoApproveUpTo` to `"low"` to auto-approve low-risk tools.
 
-### "Why does skill_load prompt in strict mode but not in workspace mode?"
+### "Why does skill_load prompt at some thresholds but not others?"
 
-In workspace mode, `skill_load` may be auto-allowed by system default rules (e.g., `skill_load:*` at priority 100). In strict mode, low-risk auto-allow is disabled, so an explicit rule is needed.
+At the default threshold (`"low"`), `skill_load` may be auto-allowed by system default rules (e.g., `skill_load:*` at priority 100). At `"none"`, low-risk auto-allow is disabled, so an explicit rule is needed.
 
 **Fix**: Create a rule for the specific skill (version-specific or any-version) or accept the starter bundle if it covers your needs.
 

package/docs/stt-provider-onboarding.md

@@ -49,66 +49,38 @@ If the new provider introduces a credential-store key that is not already presen
 
 If the new provider **shares** an existing credential name (e.g. reuses `"openai"`), the deduplication logic in `sttApiKeyProviderNames()` handles it — no changes needed.
 
-## 6. Client catalog entry
+## 6. Client display metadata
 
-**File:** `meta/stt-provider-catalog.json`
+All client-facing metadata is part of the daemon's provider catalog entry (`src/providers/speech-to-text/provider-catalog.ts`). When adding a new provider, include these fields in the catalog entry:
 
-Add a new entry to the `providers` array with the following fields:
+| Field              | Description                                                               |
+| ------------------ | ------------------------------------------------------------------------- |
+| `displayName`      | Human-readable name shown in client settings UI.                          |
+| `subtitle`         | Short description displayed below the provider selector.                  |
+| `setupMode`        | `"api-key"` (inline key field) or `"cli"` (instructions-only).            |
+| `setupHint`        | Brief guidance shown during setup.                                        |
+| `credentialsGuide` | Object with `description`, `url`, and `linkLabel` for the key mgmt page.  |
 
-| Field                       | Description                                                                                                                           |
-| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
-| `id`                        | Must match the `SttProviderId` used in step 1.                                                                                        |
-| `displayName`               | Human-readable name shown in client settings UI.                                                                                      |
-| `subtitle`                  | Short description displayed below the provider selector.                                                                              |
-| `setupMode`                 | `"api-key"` (inline key field) or `"cli"` (instructions-only).                                                                        |
-| `setupHint`                 | Brief guidance shown during setup.                                                                                                    |
-| `apiKeyProviderName`        | Must match the `credentialProvider` value from the daemon catalog entry.                                                              |
-| `conversationStreamingMode` | Must match the `conversationStreamingMode` value from the daemon catalog entry (`"realtime-ws"`, `"incremental-batch"`, or `"none"`). |
+Native clients fetch this metadata at launch via `GET /v1/stt/providers`. No separate client-side file updates are needed.
 
 **Naming/mapping examples:**
 
-| Provider ID      | `credentialProvider` / `apiKeyProviderName` | Key ownership |
-| ---------------- | ------------------------------------------- | ------------- |
-| `openai-whisper` | `openai`                                    | shared        |
-| `deepgram`       | `deepgram`                                  | exclusive     |
-| `google-gemini`  | `gemini`                                    | shared        |
-| `xai`            | `xai`                                       | exclusive     |
+| Provider ID      | `credentialProvider` | Key ownership |
+| ---------------- | -------------------- | ------------- |
+| `openai-whisper` | `openai`             | shared        |
+| `deepgram`       | `deepgram`           | exclusive     |
+| `google-gemini`  | `gemini`             | shared        |
+| `xai`            | `xai`                | exclusive     |
 
 When the provider ID differs from the credential provider name (e.g. `google-gemini` maps to `gemini`), the key is **shared** with other services that use the same credential. The `sttKeyIsExclusive` / `sttKeyIsShared` helpers in the macOS settings layer derive this automatically from the catalog.
 
-Insertion order in the JSON array must match the daemon catalog insertion order.
-
-### Client-side code
-
-**File:** `clients/shared/Utilities/STTProviderRegistry.swift`
-
-Add a matching fallback entry in `fallbackRegistry` with the same `id`, `displayName`, `subtitle`, `setupMode`, `setupHint`, `apiKeyProviderName`, and `conversationStreamingMode` as the JSON catalog entry. The fallback keeps client startup resilient when the bundled JSON is missing.
-
 ### macOS settings key behavior
 
 **File:** `clients/macos/vellum-assistant/Features/Settings/SettingsStore.swift`
 
 The `sttKeyIsExclusive(for:)` / `sttKeyIsShared(for:)` helpers derive shared-vs-exclusive key behavior from the catalog automatically: if `apiKeyProviderName == id`, the key is exclusive; otherwise it is shared. No new conditionals are needed unless the provider has a non-standard key-ownership model.
 
-## 7. Parity tests
-
-**File:** `src/__tests__/stt-catalog-parity.test.ts`
-
-The existing parity test suite enforces that:
-
-- Daemon and client catalog provider IDs are identical and in the same order.
-- Each entry's `apiKeyProviderName` matches the daemon's `credentialProvider`.
-- The client catalog has all required fields populated.
-
-Run the test after completing steps 1-6:
-
-```bash
-cd assistant && bun test src/__tests__/stt-catalog-parity.test.ts
-```
-
-If any assertion fails, the error message identifies which side is out of sync and what to fix.
-
-## 8. Verify unified STT architecture
+## 7. Verify unified STT architecture
 
 `services.stt.provider` is the single source of truth for all STT routing, including telephony. There is no separate telephony STT config path.
 

package/examples/plugins/echo/README.md

@@ -0,0 +1,132 @@
+# Echo plugin
+
+Minimal example plugin. Observes every assistant pipeline and logs one JSON
+line per invocation to `stderr`:
+
+```json
+{"plugin":"echo","pipeline":"toolExecute","durationMs":42,"outcome":"success"}
+{"plugin":"echo","pipeline":"llmCall","durationMs":1873,"outcome":"success"}
+```
+
+Use this as a starting point for writing your own plugin, or as a quick way
+to eyeball which pipelines fire during a conversation and how long they
+take.
+
+For the full plugin authoring guide, see
+[`assistant/docs/plugins.md`](../../../docs/plugins.md).
+
+## What it does
+
+- Registers one observer middleware per slot in
+  `PipelineMiddlewareMap` — `turn`, `llmCall`, `toolExecute`,
+  `memoryRetrieval`, `historyRepair`, `tokenEstimate`, `compaction`,
+  `overflowReduce`, `persistence`, `titleGenerate`, `toolResultTruncate`,
+  `emptyResponse`, `toolError`, and `circuitBreaker`.
+- Each middleware calls `next(args)` to pass the request through unchanged,
+  measures wall-clock duration, and emits one line to `stderr` whether the
+  downstream succeeded or threw.
+- Never modifies arguments, never rewrites results, never swallows errors.
+  It is purely observational — safe to stack alongside any other plugin.
+
+## Install locally
+
+The assistant scans `~/.vellum/plugins/*` for subdirectories containing a
+`register.{ts,js}` file and dynamic-imports each one during assistant
+startup. Dropping (or symlinking) this directory in place is enough to
+enable it.
+
+### Option 1 — symlink from the repo (recommended)
+
+From the repo root:
+
+```bash
+mkdir -p ~/.vellum/plugins
+ln -s "$(pwd)/assistant/examples/plugins/echo" ~/.vellum/plugins/echo
+```
+
+Symlinks let you edit the plugin in-place and restart the assistant to
+pick up changes. **This is the only zero-edit install path** — the
+`register.ts` in this directory uses relative imports
+(`../../../src/plugins/registry.js`) that resolve into the in-repo
+assistant sources, so the file must stay reachable at that relative
+location.
+
+### Option 2 — standalone copy (requires edits)
+
+If you want a fully isolated install that does not depend on a local
+vellum-assistant checkout, a plain `cp -R` of this directory into
+`~/.vellum/plugins/echo/` will **not** work as-is: the relative imports
+in `register.ts` resolve to `~/.vellum/src/plugins/...`, which does not
+exist. The assistant does not currently publish the plugin API as an npm
+package, so to copy-and-adapt this template into a standalone plugin you
+must rewrite the imports in `register.ts` to point at an absolute path
+inside a vellum-assistant checkout, for example:
+
+```ts
+// before (repo-local):
+import { registerPlugin } from "../../../src/plugins/registry.js";
+// after (standalone, edit to your checkout path):
+import { registerPlugin } from "/path/to/vellum-assistant/assistant/src/plugins/registry.js";
+```
+
+Apply the same rewrite to the `import type` line that pulls from
+`../../../src/plugins/types.js`. Until a published package exists, the
+symlink recipe above is simpler and more portable for day-to-day
+development.
+
+### Restart the assistant
+
+Plugins register at assistant startup. After installing, restart the
+assistant:
+
+```bash
+vellum restart
+```
+
+## Verify it works
+
+With the plugin installed and the assistant restarted, send any message
+that exercises a pipeline — a conversation turn, a tool call, a title
+generation — and tail the assistant's stderr log:
+
+```bash
+tail -f ~/.vellum/daemon.log
+```
+
+You should see one line per pipeline invocation, similar to:
+
+```json
+{"plugin":"echo","pipeline":"persistence","durationMs":3,"outcome":"success"}
+{"plugin":"echo","pipeline":"tokenEstimate","durationMs":1,"outcome":"success"}
+{"plugin":"echo","pipeline":"memoryRetrieval","durationMs":64,"outcome":"success"}
+{"plugin":"echo","pipeline":"historyRepair","durationMs":0,"outcome":"success"}
+{"plugin":"echo","pipeline":"llmCall","durationMs":1520,"outcome":"success"}
+{"plugin":"echo","pipeline":"turn","durationMs":1590,"outcome":"success"}
+```
+
+If a pipeline throws (for example, a tool that errors out), you'll see a
+line with `"outcome":"error"` — the plugin rethrows after logging so the
+original error still propagates.
+
+## Uninstall
+
+Remove the symlink (or the copied directory) and restart the assistant:
+
+```bash
+rm ~/.vellum/plugins/echo
+vellum restart
+```
+
+## Next steps
+
+- Read [`assistant/docs/plugins.md`](../../../docs/plugins.md) for the full
+  plugin authoring guide: manifest shape, middleware patterns
+  (observe / transform / short-circuit / veto), strict-fail semantics, the
+  per-pipeline timeout table, credential and config access, and
+  troubleshooting.
+- Look at the first-party default plugins under
+  `assistant/src/plugins/defaults/` for examples of non-observational
+  middleware.
+- Build your own plugin by copying this directory, renaming the manifest
+  `name`, and replacing the observer with a middleware that does whatever
+  you need.

package/examples/plugins/echo/bun.lock

@@ -0,0 +1,25 @@
+{
+  "lockfileVersion": 1,
+  "configVersion": 1,
+  "workspaces": {
+    "": {
+      "name": "@vellumai/plugin-echo-example",
+      "devDependencies": {
+        "@types/bun": "1.3.10",
+        "@types/node": "25.5.0",
+        "typescript": "5.9.3",
+      },
+    },
+  },
+  "packages": {
+    "@types/bun": ["@types/bun@1.3.10", "", { "dependencies": { "bun-types": "1.3.10" } }, "sha512-0+rlrUrOrTSskibryHbvQkDOWRJwJZqZlxrUs1u4oOoTln8+WIXBPmAuCF35SWB2z4Zl3E84Nl/D0P7803nigQ=="],
+
+    "@types/node": ["@types/node@25.5.0", "", { "dependencies": { "undici-types": "~7.18.0" } }, "sha512-jp2P3tQMSxWugkCUKLRPVUpGaL5MVFwF8RDuSRztfwgN1wmqJeMSbKlnEtQqU8UrhTmzEmZdu2I6v2dpp7XIxw=="],
+
+    "bun-types": ["bun-types@1.3.10", "", { "dependencies": { "@types/node": "*" } }, "sha512-tcpfCCl6XWo6nCVnpcVrxQ+9AYN1iqMIzgrSKYMB/fjLtV2eyAVEg7AxQJuCq/26R6HpKWykQXuSOq/21RYcbg=="],
+
+    "typescript": ["typescript@5.9.3", "", { "bin": { "tsc": "bin/tsc", "tsserver": "bin/tsserver" } }, "sha512-jl1vZzPDinLr9eUt3J/t7V6FgNEw9QjvBPdysz9KfQDD41fQrC2Y4vKQdiaUpFT4bXlb1RHhLpp8wtm6M5TgSw=="],
+
+    "undici-types": ["undici-types@7.18.2", "", {}, "sha512-AsuCzffGHJybSaRrmr5eHr81mwJU3kjw6M+uprWvCXiNeN9SOGwQ3Jn8jb8m3Z6izVgknn1R0FTCEAP2QrLY/w=="],
+  }
+}

package/examples/plugins/echo/package.json

@@ -0,0 +1,17 @@
+{
+  "name": "@vellumai/plugin-echo-example",
+  "version": "0.1.0",
+  "description": "Example plugin that observes every assistant pipeline and logs one structured line per invocation to stderr. Meant as an authoring reference — not shipped with the assistant runtime.",
+  "private": true,
+  "license": "MIT",
+  "type": "module",
+  "main": "./register.ts",
+  "engines": {
+    "node": ">=20.12.0"
+  },
+  "devDependencies": {
+    "@types/bun": "1.3.10",
+    "@types/node": "25.5.0",
+    "typescript": "5.9.3"
+  }
+}

package/examples/plugins/echo/register.ts

@@ -0,0 +1,187 @@
+/**
+ * Echo plugin — observes every assistant pipeline and logs one structured
+ * line per invocation to stderr.
+ *
+ * This plugin is bundled in the repository as an authoring reference. It is
+ * not shipped with the assistant runtime; to try it locally, symlink this
+ * directory into `~/.vellum/plugins/echo/` and restart the assistant. See
+ * `README.md` in this directory for the full install recipe and
+ * `assistant/docs/plugins.md` for general plugin authoring docs.
+ *
+ * ## IMPORTANT — imports below are REPO-LOCAL
+ *
+ * The relative imports from `../../../src/plugins/...` resolve correctly
+ * only while this file lives inside the vellum-assistant repo at
+ * `assistant/examples/plugins/echo/`. The path walks back to
+ * `assistant/src/plugins/` so the example compiles against the assistant's
+ * in-repo types.
+ *
+ * If you copy (rather than symlink) this directory to
+ * `~/.vellum/plugins/echo/`, these imports will fail because
+ * `~/.vellum/src/plugins/...` does not exist. The assistant does not
+ * currently publish the plugin API as an npm package, so the only
+ * zero-edit install path is the symlink recipe (Option 1 in README.md).
+ *
+ * For a standalone copy that lives outside the repo, you must either:
+ * - Point the imports at an absolute path into a vellum-assistant checkout
+ *   (`/path/to/vellum-assistant/assistant/src/plugins/registry.js`), or
+ * - Rewrite the plugin to consume only the public types you need and drop
+ *   the direct registry import in favor of your own entry-point wiring.
+ *
+ * See README.md "Option 2 — standalone copy" for the recommended
+ * standalone-template adaptation steps.
+ *
+ * ## Design
+ *
+ * - Registers an observer middleware on every slot of `PipelineMiddlewareMap`.
+ * - Each middleware records a start timestamp, calls `next(args)`, and on
+ *   return — whether successful or not — emits one JSON line on `stderr` with
+ *   `{ plugin, pipeline, durationMs, outcome }`. A `try { return await next(); }
+ *   catch { outcome = "error"; rethrow; } finally { log(); }` pattern keeps the
+ *   observation strictly non-interfering: the plugin never swallows errors
+ *   and never rewrites arguments or results.
+ * - Middleware is declared as async functions with stable names so the
+ *   pipeline runner's `chain` log field attributes them correctly.
+ *
+ * The file exports no named symbols at module level — it only runs
+ * `registerPlugin(echoPlugin)` as an import-time side effect, matching the
+ * user-plugin-loader contract (see `assistant/src/plugins/user-loader.ts`).
+ */
+
+import { registerPlugin } from "../../../src/plugins/registry.js";
+import type {
+  CircuitBreakerArgs,
+  CircuitBreakerResult,
+  CompactionArgs,
+  CompactionResult,
+  EmptyResponseArgs,
+  EmptyResponseResult,
+  HistoryRepairArgs,
+  HistoryRepairResult,
+  LLMCallArgs,
+  LLMCallResult,
+  MemoryArgs,
+  MemoryResult,
+  OverflowReduceArgs,
+  OverflowReduceResult,
+  PersistArgs,
+  PersistResult,
+  Plugin,
+  TitleArgs,
+  TitleResult,
+  TokenEstimateArgs,
+  TokenEstimateResult,
+  ToolErrorArgs,
+  ToolErrorResult,
+  ToolExecuteArgs,
+  ToolExecuteResult,
+  ToolResultTruncateArgs,
+  ToolResultTruncateResult,
+  TurnArgs,
+  TurnResult,
+} from "../../../src/plugins/types.js";
+
+const PLUGIN_NAME = "echo";
+
+/**
+ * One line written to stderr per pipeline invocation. Kept intentionally
+ * compact — pino-style JSON so operators can pipe the assistant's stderr
+ * through `jq` without reshaping.
+ */
+function emit(
+  pipelineName: string,
+  startMs: number,
+  outcome: "success" | "error",
+): void {
+  const durationMs = Math.round(performance.now() - startMs);
+  const record = {
+    plugin: PLUGIN_NAME,
+    pipeline: pipelineName,
+    durationMs,
+    outcome,
+  };
+  process.stderr.write(`${JSON.stringify(record)}\n`);
+}
+
+/**
+ * Factory for a pipeline-agnostic observer middleware. The returned function
+ * carries a `name` so `runPipeline`'s `chain` log field attributes this
+ * plugin's frame correctly. Error paths rethrow — the plugin is purely
+ * observational and must never change the turn's outcome.
+ */
+function makeObserver<A, R>(
+  pipelineName: string,
+): (args: A, next: (args: A) => Promise<R>, _ctx: unknown) => Promise<R> {
+  const fn = async function echoObserver(
+    args: A,
+    next: (args: A) => Promise<R>,
+    _ctx: unknown,
+  ): Promise<R> {
+    const start = performance.now();
+    let outcome: "success" | "error" = "success";
+    try {
+      return await next(args);
+    } catch (err) {
+      outcome = "error";
+      throw err;
+    } finally {
+      emit(pipelineName, start, outcome);
+    }
+  };
+  return fn;
+}
+
+/**
+ * The echo plugin. Declares one middleware per slot in
+ * `PipelineMiddlewareMap` — all thin observers produced by `makeObserver`.
+ *
+ * Manifest:
+ * - `requires.pluginRuntime: "v1"` satisfies the registry's mandatory
+ *   capability negotiation.
+ * - `provides: {}` — the plugin exposes no capabilities to other plugins.
+ * - No `requiresCredential` or `requiresFlag` — the plugin needs no external
+ *   state and runs unconditionally.
+ */
+const echoPlugin: Plugin = {
+  manifest: {
+    name: PLUGIN_NAME,
+    version: "0.1.0",
+    provides: {},
+    requires: { pluginRuntime: "v1" },
+  },
+  middleware: {
+    turn: makeObserver<TurnArgs, TurnResult>("turn"),
+    llmCall: makeObserver<LLMCallArgs, LLMCallResult>("llmCall"),
+    toolExecute: makeObserver<ToolExecuteArgs, ToolExecuteResult>(
+      "toolExecute",
+    ),
+    memoryRetrieval: makeObserver<MemoryArgs, MemoryResult>("memoryRetrieval"),
+    historyRepair: makeObserver<HistoryRepairArgs, HistoryRepairResult>(
+      "historyRepair",
+    ),
+    tokenEstimate: makeObserver<TokenEstimateArgs, TokenEstimateResult>(
+      "tokenEstimate",
+    ),
+    compaction: makeObserver<CompactionArgs, CompactionResult>("compaction"),
+    overflowReduce: makeObserver<OverflowReduceArgs, OverflowReduceResult>(
+      "overflowReduce",
+    ),
+    persistence: makeObserver<PersistArgs, PersistResult>("persistence"),
+    titleGenerate: makeObserver<TitleArgs, TitleResult>("titleGenerate"),
+    toolResultTruncate: makeObserver<
+      ToolResultTruncateArgs,
+      ToolResultTruncateResult
+    >("toolResultTruncate"),
+    emptyResponse: makeObserver<EmptyResponseArgs, EmptyResponseResult>(
+      "emptyResponse",
+    ),
+    toolError: makeObserver<ToolErrorArgs, ToolErrorResult>("toolError"),
+    circuitBreaker: makeObserver<CircuitBreakerArgs, CircuitBreakerResult>(
+      "circuitBreaker",
+    ),
+  },
+};
+
+// Side-effect registration — the user-plugin loader dynamic-imports this
+// file and expects the registry to pick up the plugin during that import.
+registerPlugin(echoPlugin);

package/knip.json

@@ -3,32 +3,18 @@
     "src/**/*.test.ts",
     "src/**/__tests__/**/*.ts",
     "scripts/**/*.ts",
-    "src/daemon/main.ts",
-    "src/messaging/providers/*/types.ts",
-    "src/messaging/providers/*/client.ts",
-    "src/memory/graph/inspect.ts",
-    "../skills/meet-join/**/*.test.ts",
-    "../skills/meet-join/**/__tests__/**/*.ts",
-    "!../skills/meet-join/bot/**",
-    "../skills/meet-join/contracts/**/__tests__/**/*.ts",
-    "../skills/meet-join/meet-controller-ext/scripts/build.ts",
-    "../skills/meet-join/meet-controller-ext/src/background.ts",
-    "../skills/meet-join/meet-controller-ext/src/content.ts",
-    "../skills/meet-join/meet-controller-ext/src/avatar/avatar.ts",
-    "../skills/meet-join/meet-controller-ext/src/messaging/content-bridge.ts"
-  ],
-  "project": [
-    "src/**/*.ts",
-    "src/**/*.tsx",
-    "scripts/**/*.ts",
-    "../skills/meet-join/**/*.ts",
-    "!../skills/meet-join/bot/**"
+    "src/daemon/main.ts!"
   ],
+  "project": ["src/**/*.ts!", "src/**/*.tsx!", "scripts/**/*.ts"],
   "ignoreDependencies": [
-    "@vellumai/ces-contracts",
+    "@vellumai/ces-client",
     "@vellumai/credential-storage",
     "@vellumai/egress-proxy",
+    "@vellumai/gateway-client",
+    "@vellumai/service-contracts",
     "@resvg/resvg-js-darwin-arm64",
-    "@resvg/resvg-js-darwin-x64"
+    "@resvg/resvg-js-darwin-x64",
+    "@vellumai/skill-host-contracts",
+    "madge"
   ]
 }

package/node_modules/@vellumai/ces-client/bun.lock

@@ -0,0 +1,33 @@
+{
+  "lockfileVersion": 1,
+  "configVersion": 1,
+  "workspaces": {
+    "": {
+      "name": "@vellumai/ces-client",
+      "dependencies": {
+        "@vellumai/service-contracts": "file:../service-contracts",
+      },
+      "devDependencies": {
+        "@types/bun": "1.2.4",
+        "typescript": "5.7.3",
+      },
+    },
+  },
+  "packages": {
+    "@types/bun": ["@types/bun@1.2.4", "", { "dependencies": { "bun-types": "1.2.4" } }, "sha512-QtuV5OMR8/rdKJs213iwXDpfVvnskPXY/S0ZiFbsTjQZycuqPbMW8Gf/XhLfwE5njW8sxI2WjISURXPlHypMFA=="],
+
+    "@types/node": ["@types/node@25.6.0", "", { "dependencies": { "undici-types": "~7.19.0" } }, "sha512-+qIYRKdNYJwY3vRCZMdJbPLJAtGjQBudzZzdzwQYkEPQd+PJGixUL5QfvCLDaULoLv+RhT3LDkwEfKaAkgSmNQ=="],
+
+    "@types/ws": ["@types/ws@8.5.14", "", { "dependencies": { "@types/node": "*" } }, "sha512-bd/YFLW+URhBzMXurx7lWByOu+xzU9+kb3RboOteXYDfW+tr+JZa99OyNmPINEGB/ahzKrEuc8rcv4gnpJmxTw=="],
+
+    "@vellumai/service-contracts": ["@vellumai/service-contracts@file:../service-contracts", { "dependencies": { "zod": "4.3.6" }, "devDependencies": { "@types/bun": "1.2.4", "typescript": "5.7.3" } }],
+
+    "bun-types": ["bun-types@1.2.4", "", { "dependencies": { "@types/node": "*", "@types/ws": "~8.5.10" } }, "sha512-nDPymR207ZZEoWD4AavvEaa/KZe/qlrbMSchqpQwovPZCKc7pwMoENjEtHgMKaAjJhy+x6vfqSBA1QU3bJgs0Q=="],
+
+    "typescript": ["typescript@5.7.3", "", { "bin": { "tsc": "bin/tsc", "tsserver": "bin/tsserver" } }, "sha512-84MVSjMEHP+FQRPy3pX9sTVV/INIex71s9TL2Gm5FG/WG1SqXeKyZ0k7/blY/4FdOzI12CBy1vGc4og/eus0fw=="],
+
+    "undici-types": ["undici-types@7.19.2", "", {}, "sha512-qYVnV5OEm2AW8cJMCpdV20CDyaN3g0AjDlOGf1OW4iaDEx8MwdtChUp4zu4H0VP3nDRF/8RKWH+IPp9uW0YGZg=="],
+
+    "zod": ["zod@4.3.6", "", {}, "sha512-rftlrkhHZOcjDwkGlnUtZZkvaPHCsDATp4pGpuOOMDaTdDDXF91wuVDJoWoPsKX/3YPQ5fHuF3STjcYyKr+Qhg=="],
+  }
+}

package/node_modules/@vellumai/ces-client/package.json

@@ -0,0 +1,25 @@
+{
+  "name": "@vellumai/ces-client",
+  "version": "0.0.1",
+  "private": true,
+  "license": "MIT",
+  "type": "module",
+  "exports": {
+    ".": "./src/index.ts",
+    "./http-credentials": "./src/http-credentials.ts",
+    "./http-log-export": "./src/http-log-export.ts",
+    "./rpc-client": "./src/rpc-client.ts",
+    "./credential-rpc": "./src/credential-rpc.ts"
+  },
+  "scripts": {
+    "typecheck": "bunx tsc --noEmit",
+    "test": "bun test src/"
+  },
+  "dependencies": {
+    "@vellumai/service-contracts": "file:../service-contracts"
+  },
+  "devDependencies": {
+    "@types/bun": "1.2.4",
+    "typescript": "5.7.3"
+  }
+}