@vellumai/assistant 0.8.0 → 0.8.2

package/docs/plugins.md

@@ -94,8 +94,6 @@ time. Its shape (see
 export interface PluginManifest {
   name: string; // kebab-case, unique
   version: string; // semver, informational
-  provides?: Record<string, string>; // reserved; not consumed at runtime today
-  requires: Record<string, string>; // capability → version required from the assistant
   requiresCredential?: string[]; // credential keys resolved before init()
   requiresFlag?: string[]; // feature flag keys that must all be enabled
   config?: unknown; // Zod-like parser for plugins.<name>
@@ -104,25 +102,45 @@ export interface PluginManifest {
 
 | Field                | Required | Purpose                                                                                                                                                                                                                                                                                                        |
 | -------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `name`               | yes      | Unique plugin identifier. Duplicate names fail registration. Used as the directory under `<workspaceDir>/plugins-data/<name>/` and the attribution tag in logs.                                                                                                                                                     |
+| `name`               | yes      | Unique plugin identifier. Duplicate names fail registration. Used as the directory under `<workspaceDir>/plugins-data/<name>/` and the attribution tag in logs.                                                                                                                                                |
 | `version`            | yes      | Plugin's own semver. Informational — the registry does not compare it.                                                                                                                                                                                                                                         |
-| `provides`           | no       | Reserved for future cross-plugin composition and not currently consumed by the assistant. Plugin authors may set this field, but no runtime code reads it yet — it is declared here so future cross-plugin work can land without a manifest version bump. Do not rely on it for any runtime behavior today.    |
-| `requires`           | yes      | Must include `pluginRuntime: "v1"` at minimum. The registry checks every entry against `ASSISTANT_API_VERSIONS` and refuses to register plugins that ask for a capability or version the assistant does not expose.                                                                                            |
 | `requiresCredential` | no       | Credential keys the plugin needs. The bootstrap resolves them via the credential store before `init()` runs and hands the values to the plugin in `ctx.credentials`. A missing credential fails startup with a clear error.                                                                                    |
 | `requiresFlag`       | no       | Assistant feature-flag keys that must all be ON for the plugin to activate. If any listed flag is disabled at bootstrap, the plugin is skipped entirely: `init()` is not invoked and no tools, routes, skills, or shutdown hooks are registered for it. See [Feature-flag gating](#feature-flag-gating) below. |
 | `config`             | no       | A parser-like validator (Zod schema, or any object with a `.parse(input)` method). If supplied, the bootstrap validates `config.plugins.<name>` through it before passing the result into `init()`.                                                                                                            |
 
-The exposed capability table (`ASSISTANT_API_VERSIONS`) lives in
-[`registry.ts`](../src/plugins/registry.ts). It lists:
+### Host-compat: `peerDependencies["@vellumai/plugin-api"]`
 
-- `pluginRuntime` — the base runtime every plugin must negotiate for.
-- `memoryApi`, `compactionApi`, `persistenceApi` — top-level subsystem APIs.
-- One `*Api` entry per pipeline slot (e.g. `llmCallApi`, `toolExecuteApi`,
-  `titleGenerateApi`, …).
+Plugins declare which assistant versions they support via standard
+`peerDependencies` in their `package.json`:
 
-Every entry is currently on `v1`. Removing or changing a version tag is a
-breaking change — plugins relying on it will fail to register until they
-update their `requires` map.
+```json
+{
+  "name": "@me/my-logger",
+  "version": "1.2.3",
+  "peerDependencies": {
+    "@vellumai/plugin-api": "^0.8.0"
+  }
+}
+```
+
+At load time, the external-plugin loader resolves the assistant's running
+version and runs `semver.satisfies(assistantVersion, range)` against the
+declared range. The contract is currently soft while the plugin-installation
+flow is in flux:
+
+- **Range satisfied** — plugin loads.
+- **Range not satisfied** — loader logs an error (`log.error`) and loads
+  the plugin anyway.
+- **Range unparseable** — loader logs an error and loads the plugin anyway.
+- **`@vellumai/plugin-api` peerDep absent** — loader logs a warning and
+  loads the plugin without a host-compat claim.
+
+Once the install flow settles, the two error-logging branches above will
+harden into hard rejections (with per-plugin isolation catching the
+throw so one bad plugin can't brick the rest of the registry).
+
+In-tree default plugins do not declare a peerDep — they ship with the
+assistant binary and are version-locked by construction.
 
 ### Example manifest
 
@@ -130,11 +148,6 @@ update their `requires` map.
 const manifest: PluginManifest = {
   name: "my-logger",
   version: "1.2.3",
-  provides: {},
-  requires: {
-    pluginRuntime: "v1",
-    llmCallApi: "v1",
-  },
   requiresCredential: ["LOGGER_API_KEY"],
   requiresFlag: ["my-logger-enabled"],
   config: z.object({
@@ -179,17 +192,33 @@ Feature Flags" section for the full procedure.
 
 ## Registration
 
-A plugin's `register.ts` calls `registerPlugin()` at module load time:
+A plugin's `register.ts` calls `registerPlugin()` at module load time. The
+function is exposed via the `globalThis.__vellumPluginRuntime` bridge so the
+plugin file does not need to import from the daemon's source tree:
 
 ```typescript
-import { registerPlugin } from "<path-to-assistant>/src/plugins/registry.js";
 import type { Plugin } from "<path-to-assistant>/src/plugins/types.js";
 
+interface VellumPluginRuntime {
+  readonly version: 1;
+  readonly registerPlugin: (plugin: Plugin) => void;
+  readonly assistantEventHub: import("<path-to-assistant>/src/runtime/assistant-event-hub.js").AssistantEventHub;
+  readonly getSecureKeyAsync: (account: string) => Promise<string | undefined>;
+}
+
+const runtime = (globalThis as { __vellumPluginRuntime?: VellumPluginRuntime })
+  .__vellumPluginRuntime;
+if (!runtime || runtime.version !== 1) {
+  throw new Error(
+    "vellum plugin runtime not available — install a recent assistant build",
+  );
+}
+const { registerPlugin } = runtime;
+
 const myPlugin: Plugin = {
   manifest: {
     name: "my-plugin",
     version: "0.1.0",
-    requires: { pluginRuntime: "v1" },
   },
   middleware: {
     /* ... */
@@ -199,6 +228,20 @@ const myPlugin: Plugin = {
 registerPlugin(myPlugin);
 ```
 
+**Why the bridge?** When the daemon is a `bun --compile` binary, its modules
+are bundled into the executable. Plugins that import the daemon's modules by
+absolute path (`/abs/path/to/assistant/src/plugins/registry.js`) reload fresh
+disk copies into a separate module graph, and any `registerPlugin()` call in
+the plugin lands in a registry the daemon never reads. The
+`globalThis.__vellumPluginRuntime` handle is the same instance the daemon's
+bundled code holds onto, so plugin registrations always reach the right
+place — whether the daemon was built with `bun --compile` or is running from
+source.
+
+Type-only imports (`import type { Plugin } from "..."`) remain free to use
+absolute paths to the assistant source — the TypeScript compiler erases them
+and they have no module-identity effect at runtime.
+
 **Rules:**
 
 - Exactly one `registerPlugin()` call per plugin. The registry rejects
@@ -210,6 +253,8 @@ registerPlugin(myPlugin);
   this plugin" — use `requiresFlag` or a guard inside `init()` instead.
 - The file runs before any lifecycle hooks. Keep it fast — heavy work
   belongs in `init()`.
+- The bridge is installed by the daemon before `loadUserPlugins()` runs, so
+  the global is always present when a plugin's module body executes.
 
 ## Middleware patterns
 
@@ -419,7 +464,6 @@ Declare required credential keys in `manifest.requiresCredential`:
 const manifest: PluginManifest = {
   name: "my-plugin",
   version: "1.0.0",
-  requires: { pluginRuntime: "v1" },
   requiresCredential: ["MY_PLUGIN_API_KEY"],
 };
 ```
@@ -458,7 +502,6 @@ const configSchema = z.object({
 const manifest: PluginManifest = {
   name: "my-plugin",
   version: "1.0.0",
-  requires: { pluginRuntime: "v1" },
   config: configSchema,
 };
 ```
@@ -487,8 +530,8 @@ export interface PluginInitContext {
   credentials: Record<string, string>; // resolved credentials from requiresCredential
   logger: unknown; // pino child logger, tagged { plugin: <name> }
   pluginStorageDir: string; // <workspaceDir>/plugins-data/<name>/ (created by bootstrap)
-  assistantVersion: string; // assistant semver
-  apiVersions: Record<string, string[]>; // ASSISTANT_API_VERSIONS, for runtime checks
+  assistantVersion: string; // assistant semver — same value used by the loader
+  //                          against your peerDependencies range
 }
 ```
 
@@ -635,14 +678,6 @@ assistant's module graph.
 Do not add new HTTP endpoints to implement plugin-to-plugin messaging
 inside a single assistant process.
 
-`manifest.provides` is reserved as the hook for a future cross-plugin
-capability-negotiation protocol but is **not currently consumed by any
-runtime code**. Declaring `provides` today has no behavioral effect —
-plugins must not depend on it for capability discovery or any other
-runtime purpose. The field is intentionally retained on the manifest so
-that adding real consumers later does not require bumping
-`pluginRuntime` or any other capability version.
-
 ## Hot reload
 
 **Not supported in v1.** Registering a plugin takes effect at assistant
@@ -661,23 +696,29 @@ loop externally.
 
 ## Troubleshooting
 
-### "plugin X must declare requires.pluginRuntime"
+### `external plugin X: peerDependencies["@vellumai/plugin-api"] requires "<range>" but assistant is <version> — loading anyway`
 
-The manifest's `requires` map is missing the `pluginRuntime` entry. Every
-plugin must negotiate against the base runtime:
+Logged at `error` level. Your plugin's declared
+`peerDependencies["@vellumai/plugin-api"]` range does not include the
+running assistant's version. The plugin still loads while the install
+flow is being shaped, but a future release will turn this into a hard
+rejection. Either widen the range in your `package.json` (typically by
+bumping the major in `^X.Y.Z`) or upgrade the assistant.
 
-```typescript
-requires: { pluginRuntime: "v1" },
-```
+### `external plugin X: peerDependencies["@vellumai/plugin-api"] is not a valid semver range — loading anyway`
+
+Logged at `error` level, same lenient policy as above. The value declared
+under `peerDependencies["@vellumai/plugin-api"]` is not parseable as a
+semver range. Use a standard range expression such as `^0.8.0`,
+`>=0.8.0 <0.10`, or an exact version.
 
-### "plugin X requires Y@vN, assistant exposes (none|v...)"
+### `external plugin X missing plugin-api peerDependency — loading without host-compat claim`
 
-The `requires` map names a capability the assistant does not expose, or
-asks for a version not listed under that capability. See
-`ASSISTANT_API_VERSIONS` in
-[`registry.ts`](../src/plugins/registry.ts) for the currently-exposed
-list. Either downgrade the required version or update your plugin to
-match.
+Warning, not an error. Your plugin's `package.json` does not declare a
+`peerDependencies["@vellumai/plugin-api"]` entry, so the loader has no
+host-compat range to check and loads the plugin without that guard. Add
+the peerDep so future assistant upgrades surface incompatibility before
+the plugin runs.
 
 ### "plugin X is already registered"
 

package/docs/skills.md

@@ -6,20 +6,22 @@ This document describes the security model for the Vellum Assistant skill system
 
 Skills extend the assistant's capabilities by providing instructions (via `SKILL.md`) and optional custom tools (via `TOOLS.json`). Skills can be **bundled** (shipped with the application), **managed** (user-installed via `scaffold_managed_skill`), **workspace** (project-local), or **extra** (additional directories configured by the user).
 
+For managed skills, the installed source of truth is a valid directory at `~/.vellum/workspace/skills/<id>/` containing a top-level `SKILL.md` with standardized frontmatter. The assistant parses that frontmatter at startup and when skill directories change, then seeds Memory V2 skill entries under `skills/<id>` so the assistant can discover available skills from memory. The legacy `SKILLS.md` index is removed by workspace migration and is no longer created by install or scaffold paths.
+
 Because skills can introduce arbitrary tool behavior, they are subject to stricter permission defaults than core tools.
 
 ## Permission Defaults for Skill Tools
 
 Skill-origin tools follow a stricter default permission policy than core tools:
 
-| Scenario                                          | Core tool behavior            | Skill tool behavior |
-| ------------------------------------------------- | ----------------------------- | ------------------- |
+| Scenario                                          | Core tool behavior                  | Skill tool behavior |
+| ------------------------------------------------- | ----------------------------------- | ------------------- |
 | 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        |
-| Allow rule matches, high risk, containerized bash | Auto-allowed (runtime check)  | Auto-allowed        |
-| Allow rule matches, high risk, other              | Prompted                      | 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        |
+| Allow rule matches, high risk, containerized bash | Auto-allowed (runtime check)        | Auto-allowed        |
+| Allow rule matches, high risk, other              | Prompted                            | Prompted            |
 
 Even if a skill's `TOOLS.json` declares `"risk": "low"` for one of its tools, the permission checker will prompt the user unless an explicit trust rule in `~/.vellum/protected/trust.json` allows it. This prevents third-party skill tools from silently auto-executing.
 

package/eslint-rules/__tests__/cli-no-daemon-internals.test.ts

@@ -0,0 +1,420 @@
+import tsParser from "@typescript-eslint/parser";
+import { RuleTester } from "eslint";
+
+import rule from "../cli-no-daemon-internals.js";
+
+const tester = new RuleTester({
+  languageOptions: {
+    ecmaVersion: 2022,
+    sourceType: "module",
+    parser: tsParser,
+  },
+});
+
+tester.run("cli/no-daemon-internals", rule, {
+  valid: [
+    // ipc-tagged file importing only allowed sources
+    {
+      code: `
+        import type { Command } from "commander";
+        import { cliIpcCall } from "../../ipc/cli-client.js";
+        import { log } from "../logger.js";
+        import { printTable } from "../output.js";
+
+        registerCommand(program, {
+          name: "example",
+          transport: "ipc",
+          build: () => {},
+        });
+      `,
+    },
+    // local-tagged file importing allowed sources
+    {
+      code: `
+        import type { Command } from "commander";
+        import { loadRawConfig } from "../../config/loader.js";
+        import { getWorkspaceDir } from "../../util/platform.js";
+
+        registerCommand(program, {
+          name: "local-example",
+          transport: "local",
+          build: () => {},
+        });
+      `,
+    },
+    // bootstrap-tagged file importing allowed sources
+    {
+      code: `
+        import type { Command } from "commander";
+        import { AssistantConfigSchema } from "../../config/schema.js";
+
+        registerCommand(program, {
+          name: "bootstrap-example",
+          transport: "bootstrap",
+          build: () => {},
+        });
+      `,
+    },
+    // ipc-tagged file importing from ../lib/ prefix (shared lib)
+    {
+      code: `
+        import type { Command } from "commander";
+        import { cliIpcCall } from "../../ipc/cli-client.js";
+        import { readFileSync } from "../lib/daemon-credential-client.js";
+
+        registerCommand(program, {
+          name: "lib-example",
+          transport: "ipc",
+          build: () => {},
+        });
+      `,
+    },
+    // File with zero imports and no registerCommand — utility file
+    {
+      code: `
+        function utilHelper() {
+          return 42;
+        }
+        export { utilHelper };
+      `,
+    },
+    // Helper module — has imports but does not call registerCommand directly.
+    // Helper modules under commands/ (e.g. oauth/shared.ts, lib/cache-fs.ts)
+    // are not command entries and the rule must not fire on them, even when
+    // they import from outside the registrar allowlists.
+    {
+      code: `
+        import type { Command } from "commander";
+        import { getProvider } from "../../../oauth/oauth-store.js";
+
+        export function buildAuthFlow(program) {
+          // helper module — no registerCommand call here; the actual
+          // command file imports this and calls registerCommand itself.
+        }
+      `,
+    },
+    // local-tagged file importing ../logger and ../output — both must be on
+    // the local allowlist (regression test for the allowlist gap that
+    // false-positived autonomy/config/completions/keys/credential-execution).
+    {
+      code: `
+        import type { Command } from "commander";
+        import { log } from "../logger.js";
+        import { writeOutput } from "../output.js";
+
+        registerCommand(program, {
+          name: "local-with-output",
+          transport: "local",
+          build: () => {},
+        });
+      `,
+    },
+    // Type-only imports are erased at compile time and must not count as
+    // runtime boundary violations, even when the source path is outside the
+    // allowlist (e.g. `import type` from runtime/routes for response shapes).
+    {
+      code: `
+        import type { Command } from "commander";
+        import { cliIpcCall } from "../../ipc/cli-client.js";
+        import type { MemoryV2Result } from "../../runtime/routes/memory-v2-routes.js";
+
+        registerCommand(program, {
+          name: "ipc-with-type-import",
+          transport: "ipc",
+          build: () => {},
+        });
+      `,
+    },
+    // Inline `import { type X }` form: importKind is set per specifier,
+    // not on the declaration. When every specifier is type-only the import
+    // is erased and must not flag a forbidden-runtime-import violation.
+    {
+      code: `
+        import type { Command } from "commander";
+        import { cliIpcCall } from "../../ipc/cli-client.js";
+        import { type MemoryV2Result, type ScoreBreakdown } from "../../runtime/routes/memory-v2-routes.js";
+
+        registerCommand(program, {
+          name: "ipc-with-inline-type-import",
+          transport: "ipc",
+          build: () => {},
+        });
+      `,
+    },
+    // Chained registerCommand pattern: `registerCommand(...).command(...)`.
+    // The outer call's callee is a MemberExpression whose object is the
+    // inner registerCommand call. The AST walker must follow callee +
+    // MemberExpression.object so findTransport() locates the registerCommand
+    // call and applies the correct transport allowlist.
+    {
+      code: `
+        import type { Command } from "commander";
+        import { cliIpcCall } from "../../ipc/cli-client.js";
+
+        registerCommand(program, {
+          name: "ipc-chained",
+          transport: "ipc",
+          build: () => {},
+        }).command("subcmd").description("desc");
+      `,
+    },
+    // Sibling subcommand composition: an index file (e.g. oauth/index.ts)
+    // imports sibling subcommand files (./connect.js, ./disconnect.js) to
+    // attach them under a parent group. The imported file is itself a
+    // command and the rule checks its imports independently, so this can't
+    // smuggle daemon internals.
+    {
+      code: `
+        import type { Command } from "commander";
+        import { registerCommand } from "../../lib/register-command.js";
+        import { setupConnect } from "./connect.js";
+        import { setupDisconnect } from "./disconnect.js";
+
+        registerCommand(program, {
+          name: "ipc-index-composition",
+          transport: "ipc",
+          build: () => {},
+        });
+      `,
+    },
+    // Nested command file (commands/oauth/foo.ts) needs deeper relative
+    // paths to the IPC client, lib/, logger, and output. Without the
+    // depth-2 entries the rule would false-positive on every nested
+    // command (oauth/*, platform/*).
+    {
+      code: `
+        import type { Command } from "commander";
+        import { cliIpcCall } from "../../../ipc/cli-client.js";
+        import { registerCommand } from "../../lib/register-command.js";
+        import { log } from "../../logger.js";
+        import { writeOutput } from "../../output.js";
+
+        registerCommand(program, {
+          name: "ipc-nested",
+          transport: "ipc",
+          build: () => {},
+        });
+      `,
+    },
+    // Shared CLI utils (src/cli/utils/*) — sibling utility directory used
+    // by task/ui/conversations-defer for ID resolution and parsing. Lives
+    // alongside lib/ but historically wasn't on the allowlist.
+    {
+      code: `
+        import type { Command } from "commander";
+        import { cliIpcCall } from "../../ipc/cli-client.js";
+        import { resolveConversationId } from "../utils/conversation-id.js";
+        import { parseDuration } from "../utils/parse-duration.js";
+
+        registerCommand(program, {
+          name: "ipc-with-utils",
+          transport: "ipc",
+          build: () => {},
+        });
+      `,
+    },
+    // status.ts pattern: when the daemon is unreachable, the command falls
+    // back to a local socket-path probe + platform helpers. Both imports
+    // are part of the documented daemon-down fallback contract (§3.7).
+    {
+      code: `
+        import type { Command } from "commander";
+        import { cliIpcCall } from "../../ipc/cli-client.js";
+        import { getSocketPath } from "../../ipc/socket-path.js";
+        import { getWorkspaceDir } from "../../util/platform.js";
+
+        registerCommand(program, {
+          name: "ipc-status",
+          transport: "ipc",
+          build: () => {},
+        });
+      `,
+    },
+    // local-tagged keys.ts pattern: the secure-key helpers are designed to
+    // run in-process (not over IPC), so direct security/* imports are part
+    // of the contract.
+    {
+      code: `
+        import type { Command } from "commander";
+        import { credentialKey } from "../../security/credential-key.js";
+        import { getSecureKeyAsync } from "../../security/secure-keys.js";
+
+        registerCommand(program, {
+          name: "local-keys",
+          transport: "local",
+          build: () => {},
+        });
+      `,
+    },
+    // local-tagged credential-execution.ts pattern: speaks to the CES
+    // sidecar via service-contracts RPC; the daemon is not involved.
+    {
+      code: `
+        import type { Command } from "commander";
+        import { credentialRpc } from "@vellumai/service-contracts/credential-rpc";
+        import { connect } from "../../credential-execution/client.js";
+
+        registerCommand(program, {
+          name: "local-ces",
+          transport: "local",
+          build: () => {},
+        });
+      `,
+    },
+    // local-tagged config.ts uses zod for schema validation and reaches
+    // across to oauth/shared.ts for the managed-mode platform-connection
+    // check (documented cross-namespace helper).
+    {
+      code: `
+        import type { Command } from "commander";
+        import { z } from "zod";
+        import { loadRawConfig } from "../../config/loader.js";
+        import { requirePlatformConnection } from "./oauth/shared.js";
+
+        registerCommand(program, {
+          name: "local-config",
+          transport: "local",
+          build: () => {},
+        });
+      `,
+    },
+  ],
+
+  invalid: [
+    // registerCommand called without a string transport prop — the actual
+    // missingTransport case (command-entry file forgot to declare its class).
+    {
+      code: `
+        import type { Command } from "commander";
+        import { cliIpcCall } from "../../ipc/cli-client.js";
+
+        registerCommand(program, {
+          name: "no-transport",
+          build: () => {},
+        });
+      `,
+      errors: [
+        {
+          messageId: "missingTransport",
+        },
+      ],
+    },
+    // ipc-tagged file importing a forbidden runtime route
+    {
+      code: `
+        import type { Command } from "commander";
+        import { cliIpcCall } from "../../ipc/cli-client.js";
+        import { healthRoutes } from "../../runtime/routes/health-routes.js";
+
+        registerCommand(program, {
+          name: "bad-ipc",
+          transport: "ipc",
+          build: () => {},
+        });
+      `,
+      errors: [
+        {
+          messageId: "forbiddenImport",
+          data: {
+            transport: "ipc",
+            source: "../../runtime/routes/health-routes.js",
+          },
+        },
+      ],
+    },
+    // ipc-tagged file importing a skills catalog module
+    {
+      code: `
+        import type { Command } from "commander";
+        import { cliIpcCall } from "../../ipc/cli-client.js";
+        import { SkillsCatalog } from "../../skills/catalog.js";
+
+        registerCommand(program, {
+          name: "bad-ipc-skills",
+          transport: "ipc",
+          build: () => {},
+        });
+      `,
+      errors: [
+        {
+          messageId: "forbiddenImport",
+          data: {
+            transport: "ipc",
+            source: "../../skills/catalog.js",
+          },
+        },
+      ],
+    },
+    // local-tagged file importing a forbidden runtime route
+    {
+      code: `
+        import type { Command } from "commander";
+        import { loadRawConfig } from "../../config/loader.js";
+        import { healthRoutes } from "../../runtime/routes/health-routes.js";
+
+        registerCommand(program, {
+          name: "bad-local",
+          transport: "local",
+          build: () => {},
+        });
+      `,
+      errors: [
+        {
+          messageId: "forbiddenImport",
+          data: {
+            transport: "local",
+            source: "../../runtime/routes/health-routes.js",
+          },
+        },
+      ],
+    },
+    // Nested command file (commands/oauth/foo.ts) STILL rejects runtime
+    // route imports. Locking in the boundary so the depth-2 allowlist
+    // additions don't accidentally open daemon-internal namespaces.
+    {
+      code: `
+        import type { Command } from "commander";
+        import { cliIpcCall } from "../../../ipc/cli-client.js";
+        import { healthRoutes } from "../../../runtime/routes/health-routes.js";
+
+        registerCommand(program, {
+          name: "bad-ipc-nested",
+          transport: "ipc",
+          build: () => {},
+        });
+      `,
+      errors: [
+        {
+          messageId: "forbiddenImport",
+          data: {
+            transport: "ipc",
+            source: "../../../runtime/routes/health-routes.js",
+          },
+        },
+      ],
+    },
+    // services/, agents/, llm/ namespaces remain forbidden for ipc commands.
+    {
+      code: `
+        import type { Command } from "commander";
+        import { cliIpcCall } from "../../ipc/cli-client.js";
+        import { dispatchAgent } from "../../agents/dispatcher.js";
+
+        registerCommand(program, {
+          name: "bad-ipc-agents",
+          transport: "ipc",
+          build: () => {},
+        });
+      `,
+      errors: [
+        {
+          messageId: "forbiddenImport",
+          data: {
+            transport: "ipc",
+            source: "../../agents/dispatcher.js",
+          },
+        },
+      ],
+    },
+  ],
+});