Merge origin/master: Code Mode composed with agent scopes

Master advanced 11 commits mid-merge (the Code Mode registry integration:
mode config, run_code, the tools:sdk section, the ACP run_code cards and
unified demos). The fusion makes Code Mode scope-aware end to end:

- wireSchemas(scope): the mode-aware wire contribution is computed from the
  CALLING SCOPE's visible set (scoped tools join, shadowing and restrictions
  apply) and feeds the {schemas, knownNames} provider protocol.
- knownNames under the mode collapse: a per-scope RESTRICTION is runtime
  state, so the universe stays pre-restriction (a restricted-away tool in
  toolOrder is a normal absence) — but the MODE collapse is deployment
  config, so under mode 'code' the universe is [run_code] and a toolOrder
  naming a native tool fails every assembly loud (master's tested decision,
  kept).
- The tools:sdk section renders per assembly CONTEXT: the SDK declares
  exactly the calling agent's callable set, using the section-text provider
  signature this branch already had.
- run_code bindings enumerate schemas(exec.agent) — a program can bind
  exactly what its prompt promised; sub-dispatches already threaded
  exec.agent through registry.execute, so scoped resolution and carriers
  flow unchanged.
- dsh-tools declares both sides' new deps (dsh-scope + dsh-session);
  lockfile and all generated catalogs/graphs/api-catalog regenerated.

Gates green on the merged tree: typecheck, lint, per-file 100% coverage
(2710 tests), snapshots (41), doc-sync, module graph, build, hygiene, demo
smoke.

scripts/demo-code-mode.mjs

@@ -0,0 +1,29 @@
+/**
+ * Boot the Code Mode demo under the UI named on the command line:
+ * `pnpm run demo:code-mode [repl|acp]`, default `repl`. Code Mode is the
+ * point — the UI is just the surface it happens to wear: each UI boots its
+ * base example through that example's `code-mode.cordis.yml` overlay
+ * (include ./cordis.yml, flip `tools.mode` to `code`, insert the
+ * worker-thread code runtime). Both need DEEPSEEK_API_KEY (repo-root .env
+ * works). Anything else on the command line is a misconfiguration and
+ * fails loud with usage.
+ */
+import { spawn } from 'node:child_process'
+
+// Each UI's node invocation, verbatim what its base demo script runs plus
+// the overlay config (the stdio bin keeps --expose-internals for the cordis
+// Loader's HMR path).
+const UIS = new Map([
+  ['repl', ['--expose-internals', '--import', 'tsx', 'packages/ui/stdio-agent/src/bin.ts', 'examples/coding-agent/code-mode.cordis.yml']],
+  ['acp', ['--import', 'tsx', 'packages/ui/acp-agent/src/bin.ts', 'examples/acp-agent/code-mode.cordis.yml']],
+])
+
+const ui = process.argv[2] ?? 'repl'
+const args = UIS.get(ui)
+if (!args || process.argv.length > 3) {
+  console.error('usage: pnpm run demo:code-mode [repl|acp]')
+  process.exit(2)
+}
+
+const child = spawn(process.execPath, args, { stdio: 'inherit' })
+child.on('exit', (code, signal) => { process.exit(signal !== null ? 1 : code ?? 1) })

scripts/gen-doc-graphs.ts

@@ -165,8 +165,8 @@ const SERVICE_ROLES: ServiceRole[] = [
     title: 'Code-execution seam',
     mode: 'seam',
     implementations: ['code-runtime-worker'],
-    consumers: [],
-    note: 'Runs one model-written program against host-provided async bindings; backends differ by substrate and language (the Code Mode RFC specifies the worker-thread backend and the tool-registry consumer).',
+    consumers: ['tools'],
+    note: 'Runs one model-written program against host-provided async bindings; backends differ by substrate and language (the tool registry consumes it for Code Mode).',
   },
   {
     key: 'fs',
@@ -700,7 +700,7 @@ function renderToolPipeline(): string {
     `  around["${mermaidCode('tools/execute')} waterfall<br/>timeout, retry, metrics (around dispatch)"]`,
     '  toolBody["Registered tool execute() body"]',
     `  fsGate["${mermaidCode('fs/write-intent')} or ${mermaidCode('fs/edit-intent')}<br/>tool-fs mutations only"]`,
-    `  owned["Tool-owned session events<br/>${mermaidCode('todo/write')}, ${mermaidCode('fs/observed')}, ${mermaidCode('hook/invoked')}, ${mermaidCode('hook/result')}"]`,
+    `  owned["Tool-owned session events<br/>${mermaidCode('todo/write')}, ${mermaidCode('fs/observed')}, ${mermaidCode('hook/invoked')}, ${mermaidCode('hook/result')}, ${mermaidCode('tool/code-dispatch')}"]`,
     `  post["${mermaidCode('tools/post-execute')} waterfall<br/>accept, block, replace, add context"]`,
     '  context["Buffered additionalContext<br/>context/message after all tool results"]',
     `  toolResult["Session event: ${mermaidCode('tool/result')}<br/>single model-facing outcome"]`,
@@ -722,7 +722,7 @@ function renderToolPipeline(): string {
     '  toolResult --> presentResult',
     '```',
     '',
-    'Filesystem read-before-edit checks live below `tool-fs` on the `fs/*` event gate; hook bridges and future permission prompts live on the generic pre/post tool waterfalls; and around-dispatch concerns like the tool-call timeout policy (`@deepseek-ai/dsh-timeout-policy`) wrap core dispatch on `tools/execute`. That split lets the same hooks observe bash, fs, web, todo, and subagent calls without coupling those tools to one policy service.',
+    'Filesystem read-before-edit checks live below `tool-fs` on the `fs/*` event gate; hook bridges and future permission prompts live on the generic pre/post tool waterfalls; and around-dispatch concerns like the tool-call timeout policy (`@deepseek-ai/dsh-timeout-policy`) wrap core dispatch on `tools/execute`. That split lets the same hooks observe bash, fs, web, todo, and subagent calls without coupling those tools to one policy service. Code Mode rides the same pipeline twice over: `run_code` is itself a registered tool body, and each tool call its program makes re-enters `ctx.tools.execute()` through BOTH waterfalls — serialized one at a time, logged as a `tool/code-dispatch` session event, with a deny surfacing to the program as a binding rejection (a sub-call\'s `additionalContext` is deliberately dropped — no safe outlet mid-run preserves call/result adjacency).',
     '',
     ...maintenanceFooter(maintenance),
   ].join('\n')

scripts/gen-tool-catalog.ts

@@ -38,7 +38,7 @@ import { basename, resolve } from 'node:path'
 import { Context } from 'cordis'
 import type { ToolSchema } from '@deepseek-ai/dsh-llm'
 import SystemPrompt from '@deepseek-ai/dsh-system-prompt'
-import ToolRegistry from '@deepseek-ai/dsh-tools'
+import ToolRegistry, { type Config as ToolsConfig } from '@deepseek-ai/dsh-tools'
 import LocalBashExecutor from '@deepseek-ai/dsh-bash-local'
 import LocalFileSystem from '@deepseek-ai/dsh-fs-local'
 import UserInteractionService from '@deepseek-ai/dsh-user-interaction'
@@ -87,6 +87,13 @@ interface ToolPackage {
   /** Plug the injected seams + the tool plugin onto a context that already
    * carries `systemPrompt` + `tools`. */
   mount: (ctx: Context) => Promise<void>
+  /**
+   * Config for the caller's `ToolRegistry` mount. The registry itself ships a
+   * model-facing tool (`run_code`, registered under a non-native `mode`), so
+   * ITS catalog entry boots the registry in the mode that surfaces it;
+   * every other entry uses the default (native) registry.
+   */
+  toolsConfig?: ToolsConfig
   /**
    * A deployment note rendered after the package's tools, for a fact that
    * booting the package alone cannot show. The registered tool NAME can be a
@@ -116,6 +123,20 @@ const TOOL_PACKAGES: ToolPackage[] = [
     note:
       'ask_user_question pauses the tool call until the active UI provider returns a human answer.',
   },
+  {
+    pkg: '@deepseek-ai/dsh-tools',
+    dir: 'tools',
+    source: 'packages/core/tools/src/code-mode.ts',
+    requires: ['ctx.tools', 'ctx.codeRuntime (execution time)', 'ctx.systemPrompt'],
+    writes: ['tool/call', 'one tool/code-dispatch per bridged sub-call', 'tool/result'],
+    // The registry's OWN tool: run_code exists only under a non-native mode
+    // (the registry registers it in its constructor; the code runtime is read
+    // at assembly/execution time, so the schema harvest needs none mounted).
+    toolsConfig: { mode: 'code' },
+    async mount() {},
+    note:
+      'Registered by the tool registry itself under `mode: code` / `mode: both` (see the Code Mode RFC). Under `code` it is the ONLY wire tool; the other registered tools are declared to the model as a generated TypeScript SDK prompt section instead, and a program calls them through port-bridged bindings that dispatch through the ordinary tools/pre-execute → tools/post-execute pipeline, one at a time.',
+  },
   {
     pkg: '@deepseek-ai/dsh-tool-bash',
     dir: 'tool-bash',
@@ -259,7 +280,7 @@ export async function collectToolCatalog(packages: ToolPackage[] = TOOL_PACKAGES
     // fiber) — the repo's "dispose must reach quiescence" rule.
     try {
       await ctx.plugin(SystemPrompt)
-      await ctx.plugin(ToolRegistry)
+      await ctx.plugin(ToolRegistry, entry.toolsConfig ?? {})
       await entry.mount(ctx)
       const schemas = ctx.tools.schemas().sort((a, b) => a.name.localeCompare(b.name))
       catalog.push({