Przeglądaj źródła

feat(docs): generate a tool-schema catalog by booting the tool plugins

Add docs/tool-catalog/tools.md, a generated reference of every model-facing
tool a shipped `packages/*/tool-*` plugin contributes (name, description,
JSON-Schema parameters) — the third generated catalog alongside the cordis
events/services and core-data-structures catalogs.

Unlike the cordis catalog (a pure source-AST pass), this generator BOOTS each
tool plugin on a real cordis Context and reads `ctx.tools.schemas()`, because a
tool schema is not statically knowable: `todo_write` builds its enum with a
runtime spread, descriptions are string-concatenated, `subagent`'s name is
config-driven, and MCP tools register raw JSON Schema without `defineTool`. A
completeness guard globs the on-disk `tool-*` packages and fails if any is
absent from the boot manifest, restoring the "nothing silently omitted"
property booting would otherwise lose. `verify-tool-catalog` runs inside
`doc-sync`, so the artifact cannot drift.

The boot-over-AST decision and the discovered-inventory / hand-written-recipe
split are recorded in a process RFC.
Tianyi Cui 2 miesięcy temu
rodzic
commit
df0e7bd5f2

+ 1 - 0
docs/rfc/README.md

@@ -135,6 +135,7 @@ Do NOT write one for a mechanical or local choice (a variable name, a one-file r
 | [Core-data-structures catalog and the `ts type-equiv` drift gate](implemented/process/2026-06-20-core-data-structures-catalog.md) | 2026-06-20 |
 | [Generated cordis events + services catalog](implemented/process/2026-06-20-generated-cordis-catalog.md) | 2026-06-20 |
 | [Classify RFCs by kind via path-encoded subdirectories](implemented/process/2026-06-20-rfc-classification.md) | 2026-06-20 |
+| [Generated tool-schema catalog (boot-and-harvest)](implemented/process/2026-07-02-tool-schema-catalog.md) | 2026-07-02 |
 
 ### Testing
 

+ 45 - 0
docs/rfc/implemented/process/2026-07-02-tool-schema-catalog.md

@@ -0,0 +1,45 @@
+# RFC: Generated tool-schema catalog (boot-and-harvest)
+
+Status: implemented (accepted 2026-07-02)
+
+## Context
+
+A reader — a plugin author, a prompt engineer, someone auditing what the agent can do — has no single place that lists the model-facing tools the harness ships. The `name` / `description` / JSON-Schema `parameters` a tool contributes are what the model actually receives (via `ctx.systemPrompt.tools()` off `ctx.tools.schemas()`), but they are scattered across each `defineTool` call in each `packages/*/tool-*` package, buried in string concatenation and runtime spreads. The [cordis events & services catalog](../../../cordis-catalog/events-and-services.md) ([its RFC](2026-06-20-generated-cordis-catalog.md)) documents the *wiring* a plugin works against and the [core-data-structures catalog](../../../core-data-structures/core.md) documents the *vocabulary* those signatures move — but neither documents the *tools* the agent is offered. This RFC adds that third reference surface, `docs/tool-catalog/tools.md`, and a freshness gate so it cannot drift.
+
+## Decision
+
+Generate the catalog by **booting each tool plugin and reading its registered schemas**, not by parsing source. `scripts/gen-tool-catalog.ts` mounts each shipped tool package on a fresh cordis `Context` (with `SystemPrompt` + `ToolRegistry` and the injected seams the plugin's `apply` reads), calls `ctx.tools.schemas()` — exactly the `ToolSchema[]` the model is sent — disposes the context, and renders one `## <package>` section per package with a ` ```json ` `parameters` block per tool. It mirrors the `gen-cordis-catalog` / `gen-module-graph` CLI shape: default `--write` regenerates, `--check` fails if the committed copy is stale, output is deterministic (manifest-ordered, tools sorted by name). `verify-tool-catalog` (the `--check`) runs inside `doc-sync`, so the freshness gate fires in the same lefthook pre-push and CI paths as every other doc gate.
+
+### Why boot, not parse (the crux)
+
+The cordis catalog is a pure TypeScript-AST pass because every event/service name is a string literal that round-trips to a static declaration — the AST is the whole truth. **Tool schemas are not statically knowable**, so the same technique would produce a doc that lies:
+
+- `tool-todo` writes `enum: [...STATUSES]` — a spread of a runtime `const`. The AST sees the spread expression, not `["pending","in_progress","completed"]`.
+- Every description is built by string **concatenation** (`'…' + '…'`). The AST sees concatenation nodes, not the final prose the model reads.
+- `tool-subagent`'s tool name is `config.toolName ?? 'subagent'` — chosen at load, not a literal.
+- An MCP plugin can register **raw JSON Schema** directly via `ctx.tools.register()` without `defineTool` at all, so enumerating `defineTool(` call sites structurally under-counts.
+
+The only faithful source of truth is the schema the registry actually holds after the plugin loads. Booting is the [unit-test discipline](../../../../AGENTS.md) "verify the world, not a synthetic stand-in" applied to a doc generator: read the shipped artifact, not a re-derivation of it.
+
+### Restoring "nothing silently omitted"
+
+Booting has a cost the AST pass did not: there is no source declaration set to enumerate, so a new tool package could simply be forgotten. A **completeness guard** restores the guarantee — `assertManifestComplete` globs every `tool-*` package under `packages/` and hard-errors if any is absent from the generator's boot manifest. A new tool package fails the generator, and therefore `doc-sync`, until it is registered. This is the same structural property the cordis generator gets for free from enumerating source, re-created for a boot-based generator.
+
+### A hand-maintained boot manifest is the irreducible policy
+
+The boot manifest (`TOOL_PACKAGES`) is a hand-written list — in tension with the proposed [Discover package inventories instead of maintaining static lists](../../proposed/process/2026-06-20-discover-package-inventory.md). The tension is deliberate and resolved as follows: the *inventory* is discovered (the glob guard means no one maintains "the list of tool packages" — the filesystem is the source of truth, and drift fails the gate), but the *boot recipe* per package — which seams to plug (`bash-local` for `ctx.bash`, `subagent` + `subagent-mock` for `ctx.subagents`) and with what config (`{ provider: 'mock' }`) — is genuine policy that no layout fact encodes. Per that RFC's own "what we give up" ("stay boring: read manifests, filter on explicit fields, print the resolved list, and fail loud"), a recipe closure is the boring, explicit form; inferring seam wiring from injects would be the "too clever" path it warns against. So: discovered inventory, hand-written recipe, gate on completeness.
+
+### Scope
+
+Shipped product tools under `packages/*/tool-*` only: `dsh-tool-bash` (`bash`, `bash_output`, `bash_kill`), `dsh-tool-todo` (`todo_write`), `dsh-tool-subagent` (`subagent`). The `examples/` demo tools (`echo`) are excluded, matching the cordis catalog's packages-only scope — a demo tool is not part of the product surface a reader is cataloguing.
+
+### A plain `json` fence
+
+Schema blocks use ` ```json `, not a bespoke `ts`-family fence. `doc-typecheck` only extracts `ts*` fences, so a JSON block is invisible to it — no `BlockKind` wiring is needed (unlike the cordis catalog's `ts cordis-catalog` fence, which had to be allowlisted so a bare signature fragment isn't compiled).
+
+## Consequences
+
+- The catalog cannot drift: a tool schema change the committed file doesn't reflect fails `verify-tool-catalog` in the pre-push hook and CI. A new `tool-*` package not added to the manifest fails the completeness guard outright.
+- Tool description prose has a single home — the `defineTool` `description` at the source — and the generated entry is only as good as it, the same forcing function the cordis catalog applies to event JSDoc.
+- The generator imports and executes workspace packages (the first repo script to do so; the others only read text). It runs under `tsx` via the root `tsconfig` `paths` map, the same unbuilt-source path the demos and tests use, so it needs no build step.
+- A new capability seam behind a future tool means a new manifest recipe entry (which seams to mount). This is the deliberate hand-written cost called out above; it changes only when a tool package is added.

+ 165 - 0
docs/tool-catalog/tools.md

@@ -0,0 +1,165 @@
+<!-- Generated by scripts/gen-tool-catalog.ts — do not edit by hand.
+     Run `pnpm run gen-tool-catalog` to regenerate. -->
+
+# Tool Schema Catalog
+
+Every model-facing tool a shipped plugin contributes to `ctx.tools`: the exact `name`, `description`, and JSON-Schema `parameters` the model receives via the system-prompt assembly. It complements the [cordis events & services catalog](../cordis-catalog/events-and-services.md) (the wiring a plugin listens to and calls) and [core-data-structures/](../core-data-structures/core.md) (the types those signatures move) — this page is the *tools* the agent is offered.
+
+This file is GENERATED and verified fresh by `pnpm run verify-tool-catalog` (part of `doc-sync`) — do not edit it by hand. Unlike the cordis catalog (a pure source-AST pass), this generator BOOTS each tool plugin on a real context and reads `ctx.tools.schemas()`, because a tool schema is not statically knowable (runtime-spread enums, concatenated descriptions, config-driven names, raw-JSON-Schema MCP tools). A completeness guard globs `packages/*/tool-*` and fails if any package is missing from the generator's boot manifest, so a new tool cannot be silently undocumented. See [the tool-schema-catalog RFC](../rfc/implemented/process/2026-07-02-tool-schema-catalog.md).
+
+Scope: shipped product tools under `packages/*/tool-*`. The `examples/` demo tools (e.g. `echo`) are excluded, matching the cordis catalog's packages-only scope.
+
+## `@deepseek-ai/dsh-tool-bash`
+
+### `bash`
+
+Execute a bash command (`bash -c`) and return its stdout/stderr. Each call runs in a fresh shell: no state (cwd, variables, functions) persists between calls — pass `workdir` instead of using `cd`. Non-zero exits are reported as `[exit code: N]`. Long output is truncated to its tail; the full output is saved to a file whose path is reported when available. Set `run_in_background: true` for long-running commands: the call returns a task id immediately; poll it with `bash_output` and stop it with `bash_kill`.
+
+```json
+{
+  "type": "object",
+  "properties": {
+    "command": {
+      "type": "string",
+      "description": "The bash command to execute."
+    },
+    "description": {
+      "type": "string",
+      "description": "Clear, concise description of what this command does in active voice, 5-10 words (shown in the UI). Examples: \"ls\" → \"List files in current directory\"; \"git status\" → \"Show working tree status\"; \"npm install\" → \"Install package dependencies\"."
+    },
+    "timeoutMs": {
+      "type": "number",
+      "description": "Timeout in milliseconds. The executor applies its configured default and cap, and kills the command on expiry."
+    },
+    "workdir": {
+      "type": "string",
+      "description": "Working directory for this command. Defaults to the session workspace; a relative path is resolved against it."
+    },
+    "run_in_background": {
+      "type": "boolean",
+      "description": "Run in the background and return a task id immediately. No timeout applies."
+    }
+  },
+  "required": [
+    "command",
+    "description"
+  ]
+}
+```
+
+Source: [`packages/bash/tool-bash/src/index.ts`](../../packages/bash/tool-bash/src/index.ts)
+
+### `bash_kill`
+
+Ask the executor to kill a running background bash task by task id.
+
+```json
+{
+  "type": "object",
+  "properties": {
+    "task_id": {
+      "type": "string",
+      "description": "Task id returned by the bash tool."
+    }
+  },
+  "required": [
+    "task_id"
+  ]
+}
+```
+
+Source: [`packages/bash/tool-bash/src/index.ts`](../../packages/bash/tool-bash/src/index.ts)
+
+### `bash_output`
+
+Read new output from a background bash task started with `bash` + `run_in_background`. Returns only output produced since the previous bash_output call, plus the task status. Tasks keep running while you do other work; poll again later for more output.
+
+```json
+{
+  "type": "object",
+  "properties": {
+    "task_id": {
+      "type": "string",
+      "description": "Task id returned by the bash tool."
+    }
+  },
+  "required": [
+    "task_id"
+  ]
+}
+```
+
+Source: [`packages/bash/tool-bash/src/index.ts`](../../packages/bash/tool-bash/src/index.ts)
+
+## `@deepseek-ai/dsh-tool-subagent`
+
+### `subagent`
+
+Delegate a self-contained task to a subagent (a separate agent that works in its own context) and return its final result. Use this to offload focused, independent work — research, a scoped implementation, an analysis — so it does not consume this conversation's context. The subagent runs to completion and you receive only its final answer, not its intermediate steps. Give it a complete, standalone prompt: it does not see this conversation.
+
+```json
+{
+  "type": "object",
+  "properties": {
+    "description": {
+      "type": "string",
+      "description": "A short (3-5 word) description of the delegated task, for display."
+    },
+    "prompt": {
+      "type": "string",
+      "description": "The complete, self-contained task for the subagent. It does not share this conversation's context, so include everything it needs."
+    }
+  },
+  "required": [
+    "description",
+    "prompt"
+  ]
+}
+```
+
+Source: [`packages/subagent/tool-subagent/src/index.ts`](../../packages/subagent/tool-subagent/src/index.ts)
+
+## `@deepseek-ai/dsh-tool-todo`
+
+### `todo_write`
+
+Record and update a structured task list for the current work. Send the ENTIRE list every call — it REPLACES the previous list (there are no partial updates, no per-item edits). Use it to plan multi-step work and show progress: add one todo per concrete step before you start. Keep AT MOST ONE todo `in_progress` at a time; while work remains, exactly one active task should be `in_progress`. Mark a todo `completed` the moment it is done (do not batch completions), and allow no `in_progress` item only once all work is complete. Skip the list for trivial single-step tasks. Statuses: `pending` (not started), `in_progress` (being worked on now), `completed` (finished).
+
+```json
+{
+  "type": "object",
+  "properties": {
+    "todos": {
+      "type": "array",
+      "description": "The COMPLETE task list, replacing any previous list.",
+      "items": {
+        "type": "object",
+        "properties": {
+          "content": {
+            "type": "string",
+            "description": "What the task is — a short imperative line."
+          },
+          "status": {
+            "type": "string",
+            "description": "pending (not started) | in_progress (now) | completed (done).",
+            "enum": [
+              "pending",
+              "in_progress",
+              "completed"
+            ]
+          }
+        },
+        "required": [
+          "content",
+          "status"
+        ]
+      }
+    }
+  },
+  "required": [
+    "todos"
+  ]
+}
+```
+
+Source: [`packages/todo/tool-todo/src/index.ts`](../../packages/todo/tool-todo/src/index.ts)

+ 3 - 1
package.json

@@ -34,10 +34,12 @@
     "verify-node-next-types": "tsx scripts/verify-node-next-types.ts",
     "gen-cordis-catalog": "tsx scripts/gen-cordis-catalog.ts",
     "verify-cordis-catalog": "tsx scripts/gen-cordis-catalog.ts --check",
+    "gen-tool-catalog": "tsx scripts/gen-tool-catalog.ts",
+    "verify-tool-catalog": "tsx scripts/gen-tool-catalog.ts --check",
     "gen-module-graph": "tsx scripts/gen-module-graph.ts",
     "verify-module-graph": "tsx scripts/gen-module-graph.ts --check",
     "constraints": "tsx scripts/check-workspace-constraints.ts",
-    "doc-sync": "pnpm run doc-typecheck && pnpm run verify-cordis-catalog && pnpm run verify-md-wrap && pnpm run verify-md-links && pnpm run verify-doc-refs && pnpm run verify-package-paths && pnpm run verify-rfc-classification && pnpm run verify-type-equiv",
+    "doc-sync": "pnpm run doc-typecheck && pnpm run verify-cordis-catalog && pnpm run verify-tool-catalog && pnpm run verify-md-wrap && pnpm run verify-md-links && pnpm run verify-doc-refs && pnpm run verify-package-paths && pnpm run verify-rfc-classification && pnpm run verify-type-equiv",
     "hygiene": "pnpm run knip && pnpm run publint && pnpm run constraints && pnpm run verify-node-next-types",
     "demo:echo": "node --expose-internals --import tsx packages/ui/stdio-agent/src/bin.ts examples/echo-agent/cordis.yml",
     "demo:coding": "node --expose-internals --import tsx packages/ui/stdio-agent/src/bin.ts examples/coding-agent/cordis.yml",

+ 1 - 1
packages/core/tools/README.md

@@ -8,7 +8,7 @@ Tool registry and execution waterfall. Tool plugins register their schemas and e
 
 - `ctx.tools.register(definition: ToolDefinition): () => void` Register a tool. Disposed with the calling fiber.
 - `ctx.tools.get(name: string): ToolDefinition | undefined`
-- `ctx.tools.schemas(): ToolSchema[]` Schemas of all registered tools (without the `execute` functions).
+- `ctx.tools.schemas(): ToolSchema[]` Schemas of all registered tools (without the `execute` functions). The shipped tools' schemas are catalogued in [docs/tool-catalog/tools.md](../../../docs/tool-catalog/tools.md), generated by booting each tool plugin and harvesting this method (see [the tool-schema-catalog RFC](../../../docs/rfc/implemented/process/2026-07-02-tool-schema-catalog.md)).
 - `ctx.tools.execute(exec: ToolExecution): Promise<ToolExecutionResult>` Execute one tool call through the `tools/execute` waterfall.
 
 ### Injected services

+ 105 - 0
packages/core/tools/tests/gen-tool-catalog.spec.ts

@@ -0,0 +1,105 @@
+/**
+ * Guarantee tests for the tool-schema catalog generator
+ * (`scripts/gen-tool-catalog.ts`).
+ *
+ * The generated catalog is frozen by a regenerate-and-diff freshness gate, so
+ * the freshness half is exercised by `pnpm run verify-tool-catalog` in CI. What
+ * a freshness diff CANNOT prove is (a) that BOOTING the tool plugins yields the
+ * shipped schema — the whole reason this generator boots instead of parsing
+ * source (a runtime-spread enum resolves to its literal members) — and (b) that
+ * the completeness guard REJECTS a tool package missing from the boot manifest,
+ * the property that replaces the AST pass's "nothing silently omitted". These
+ * tests drive the exported `collectToolCatalog` / `assertManifestComplete` /
+ * `render` directly, mirroring the negative-path style of the cordis-catalog
+ * generator tests.
+ */
+
+import { describe, expect, it } from 'vitest'
+import {
+  assertManifestComplete,
+  collectToolCatalog,
+  render,
+  type ToolCatalog,
+} from '../../../../scripts/gen-tool-catalog.ts'
+
+/** JSON Schema shape enough to reach the values AST extraction can't. */
+interface JsonSchema {
+  type: string
+  properties?: Record<string, JsonSchema>
+  items?: JsonSchema
+  enum?: string[]
+  required?: string[]
+}
+
+describe('gen-tool-catalog collectToolCatalog', () => {
+  it('boots every shipped tool package and harvests its model-facing schemas', async () => {
+    const catalog = await collectToolCatalog()
+    const names = catalog.flatMap(entry => entry.schemas.map(s => s.name)).sort()
+    expect(names).toEqual(['bash', 'bash_kill', 'bash_output', 'subagent', 'todo_write'])
+    // Every tool carries a JSON-Schema `parameters` object (what the model sees).
+    for (const entry of catalog) {
+      for (const schema of entry.schemas) {
+        expect((schema.parameters as unknown as JsonSchema).type).toBe('object')
+      }
+    }
+  })
+
+  it('resolves a runtime-spread enum to its literal members (the payoff over AST)', async () => {
+    const catalog = await collectToolCatalog()
+    const todo = catalog
+      .flatMap(entry => entry.schemas)
+      .find(s => s.name === 'todo_write')
+    // `todo-todo` writes `enum: [...STATUSES]` — a source AST would see the
+    // spread, not the values. Booting yields the shipped enum literals.
+    const status = (((todo?.parameters as unknown as JsonSchema).properties?.todos)?.items)?.properties?.status
+    expect(status?.enum).toEqual(['pending', 'in_progress', 'completed'])
+  })
+
+  it('attributes each package with a source pointer that names its index', async () => {
+    const catalog = await collectToolCatalog()
+    const bash = catalog.find(entry => entry.pkg === '@deepseek-ai/dsh-tool-bash')
+    expect(bash?.source).toBe('packages/bash/tool-bash/src/index.ts')
+  })
+})
+
+describe('gen-tool-catalog assertManifestComplete', () => {
+  it('passes when the manifest lists every on-disk tool package (the default)', () => {
+    expect(() => { assertManifestComplete() }).not.toThrow()
+  })
+
+  it('throws, naming the omitted package, when a tool package is missing from the manifest', () => {
+    // An empty manifest scanned against the real tree: every `tool-*` package
+    // is unlisted, so the guard must fire and name them.
+    expect(() => { assertManifestComplete([]) }).toThrow(/not in the boot manifest/)
+    expect(() => { assertManifestComplete([]) }).toThrow(/tool-bash/)
+  })
+})
+
+describe('gen-tool-catalog render', () => {
+  it('emits a package heading, a tool heading, and a json schema fence', () => {
+    const catalog: ToolCatalog = [
+      {
+        pkg: '@deepseek-ai/dsh-tool-demo',
+        source: 'packages/demo/tool-demo/src/index.ts',
+        schemas: [{ name: 'demo', description: 'A demo tool.', parameters: { type: 'object', properties: {} } }],
+      },
+    ]
+    const md = render(catalog)
+    expect(md).toContain('## `@deepseek-ai/dsh-tool-demo`')
+    expect(md).toContain('### `demo`')
+    expect(md).toContain('A demo tool.')
+    expect(md).toContain('```json')
+    expect(md).toContain('Source: [`packages/demo/tool-demo/src/index.ts`]')
+  })
+
+  it('renders the strict flag when a schema sets it', () => {
+    const catalog: ToolCatalog = [
+      {
+        pkg: '@deepseek-ai/dsh-tool-demo',
+        source: 'packages/demo/tool-demo/src/index.ts',
+        schemas: [{ name: 'demo', description: '', parameters: { type: 'object', properties: {} }, strict: true }],
+      },
+    ]
+    expect(render(catalog)).toContain('Strict: `true`')
+  })
+})

+ 229 - 0
scripts/gen-tool-catalog.ts

@@ -0,0 +1,229 @@
+/**
+ * Generate (and verify) the tool-schema catalog in docs/tool-catalog/tools.md.
+ *
+ * The catalog is the MODEL-FACING TOOL reference: every tool a shipped plugin
+ * contributes to `ctx.tools`, with the exact `name` / `description` / JSON-Schema
+ * `parameters` the model receives via the system-prompt assembly. It complements
+ * the cordis events/services catalog (the wiring a plugin author works against)
+ * and the core-data-structures catalog (the vocabulary those signatures move):
+ * this page is the TOOLS the agent is offered.
+ *
+ *   `tsx scripts/gen-tool-catalog.ts`          → write the catalog
+ *   `tsx scripts/gen-tool-catalog.ts --check`  → exit 1 if the committed file
+ *                                                 is stale (CI / pre-push gate)
+ *
+ * Why this generator BOOTS PLUGINS instead of parsing source (unlike its AST
+ * sibling `gen-cordis-catalog.ts`): a tool's schema is not statically knowable.
+ * `tool-todo` writes `enum: [...STATUSES]` (a runtime spread), descriptions are
+ * built by string concatenation, `tool-subagent`'s tool name is `config.toolName`,
+ * and an MCP plugin can register RAW JSON Schema without `defineTool` at all. The
+ * faithful source of truth is therefore the SHIPPED schema: mount each tool
+ * plugin on a real cordis Context and read `ctx.tools.schemas()` — exactly the
+ * `ToolSchema[]` the model is sent. See
+ * docs/rfc/implemented/process/2026-07-02-tool-schema-catalog.md.
+ *
+ * Booting sacrifices the AST pass's structural "nothing can be silently omitted"
+ * property (there is no source declaration to enumerate), so a COMPLETENESS GUARD
+ * restores it: the generator globs every `tool-*` package under `packages/` and
+ * hard-errors if any such package is absent from the boot manifest below. A new
+ * tool package fails the generator — and thus the freshness gate — until it is
+ * registered here, mirroring how a new event appears in the cordis regenerate.
+ *
+ * Schema blocks use a plain ` ```json ` fence: doc-typecheck only extracts `ts*`
+ * fences, so no BlockKind wiring is needed there.
+ */
+
+import { globSync, readFileSync, writeFileSync } from 'node:fs'
+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 LocalBashExecutor from '@deepseek-ai/dsh-bash-local'
+import SubagentService from '@deepseek-ai/dsh-subagent'
+import * as SubagentMock from '@deepseek-ai/dsh-subagent-mock'
+import * as ToolBash from '@deepseek-ai/dsh-tool-bash'
+import * as ToolTodo from '@deepseek-ai/dsh-tool-todo'
+import * as ToolSubagent from '@deepseek-ai/dsh-tool-subagent'
+
+const root = resolve(import.meta.dirname, '..')
+const OUT = 'docs/tool-catalog/tools.md'
+
+/**
+ * One tool-plugin package to boot. `mount` is a per-entry recipe (async): it
+ * plugs the injected seams the plugin's `apply` reads (an executor for
+ * `ctx.bash`, a provider for `ctx.subagents`) BEFORE the tool plugin itself.
+ * `SystemPrompt` + `ToolRegistry` are mounted for every entry by the caller
+ * (`ToolRegistry` injects `systemPrompt`), so `mount` only handles the extras.
+ *
+ * The recipe is irreducible policy — WHICH seams a given tool needs and with
+ * WHAT config is not derivable from the package layout — so it stays a hand-
+ * maintained closure. The `dir` field is what the completeness guard matches
+ * against the on-disk `tool-*` package glob, so a NEW tool package cannot be
+ * silently omitted (see the module doc).
+ */
+interface ToolPackage {
+  /** The npm package name, used as the catalog section heading. */
+  pkg: string
+  /** The `packages/<group>/<dir>` leaf name — matched by the completeness guard. */
+  dir: string
+  /** Repo-relative source path linked from the catalog entry. */
+  source: string
+  /** Plug the injected seams + the tool plugin onto a context that already
+   * carries `systemPrompt` + `tools`. */
+  mount: (ctx: Context) => Promise<void>
+}
+
+/**
+ * The boot manifest: every shipped tool package (a `tool-*` leaf under
+ * `packages/`). Ordered by package name (the render order); the completeness
+ * guard proves it is exhaustive against the on-disk glob.
+ */
+const TOOL_PACKAGES: ToolPackage[] = [
+  {
+    pkg: '@deepseek-ai/dsh-tool-bash',
+    dir: 'tool-bash',
+    source: 'packages/bash/tool-bash/src/index.ts',
+    async mount(ctx) {
+      await ctx.plugin(LocalBashExecutor)
+      await ctx.plugin(ToolBash)
+    },
+  },
+  {
+    pkg: '@deepseek-ai/dsh-tool-subagent',
+    dir: 'tool-subagent',
+    source: 'packages/subagent/tool-subagent/src/index.ts',
+    async mount(ctx) {
+      await ctx.plugin(SubagentService)
+      // Register a scripted provider under the name the tool delegates to.
+      await ctx.plugin(SubagentMock, { name: 'mock' })
+      await ctx.plugin(ToolSubagent, { provider: 'mock' })
+    },
+  },
+  {
+    pkg: '@deepseek-ai/dsh-tool-todo',
+    dir: 'tool-todo',
+    source: 'packages/todo/tool-todo/src/index.ts',
+    async mount(ctx) {
+      await ctx.plugin(ToolTodo)
+    },
+  },
+]
+
+/** One package's contribution to the catalog: its schemas plus attribution. */
+interface CatalogPackage {
+  pkg: string
+  source: string
+  schemas: ToolSchema[]
+}
+
+/** The whole catalog: one entry per booted tool package, in manifest order. */
+export type ToolCatalog = CatalogPackage[]
+
+/**
+ * Assert the boot manifest covers every shipped tool package on disk (a
+ * `tool-*` leaf under `packages/`).
+ * Booting has no source declaration to enumerate, so this glob restores the
+ * "a new tool cannot be silently undocumented" guarantee: an unlisted package
+ * fails the generator (and the freshness gate) until it is added to
+ * {@link TOOL_PACKAGES}. Exported for a direct negative test.
+ *
+ * `scanRoot` defaults to the repo root; a test may point it at a fixture tree.
+ */
+export function assertManifestComplete(packages: ToolPackage[] = TOOL_PACKAGES, scanRoot: string = root): void {
+  const onDisk = globSync('packages/*/tool-*', { cwd: scanRoot }).map(p => basename(p)).sort()
+  const listed = new Set(packages.map(p => p.dir))
+  const missing = onDisk.filter(dir => !listed.has(dir))
+  if (missing.length > 0) {
+    throw new Error(
+      `gen-tool-catalog: ${missing.length} tool package(s) not in the boot manifest: ${missing.join(', ')}. `
+      + 'Add each to TOOL_PACKAGES in scripts/gen-tool-catalog.ts so its schema is catalogued.',
+    )
+  }
+}
+
+/**
+ * Boot each tool package on a fresh Context and harvest its model-facing
+ * schemas. A fresh Context per package keeps attribution clean (each entry's
+ * schemas come from exactly that package) and isolates a boot failure to its
+ * own entry. Disposed after harvest so no executor/provider outlives the run.
+ */
+export async function collectToolCatalog(packages: ToolPackage[] = TOOL_PACKAGES): Promise<ToolCatalog> {
+  assertManifestComplete(packages)
+  const catalog: ToolCatalog = []
+  for (const entry of packages) {
+    const ctx = new Context()
+    await ctx.plugin(SystemPrompt)
+    await ctx.plugin(ToolRegistry)
+    await entry.mount(ctx)
+    // Copy the schemas out before the context is torn down.
+    const schemas = ctx.tools.schemas().sort((a, b) => a.name.localeCompare(b.name))
+    await ctx.fiber.dispose()
+    catalog.push({ pkg: entry.pkg, source: entry.source, schemas })
+  }
+  return catalog
+}
+
+/** Render one tool's entry: name, description, JSON-Schema parameters, source. */
+function renderTool(schema: ToolSchema, source: string): string[] {
+  const out = [`### \`${schema.name}\``, '']
+  if (schema.description) out.push(schema.description, '')
+  if (schema.strict !== undefined) out.push(`Strict: \`${String(schema.strict)}\``, '')
+  out.push('```json', JSON.stringify(schema.parameters, null, 2), '```', '')
+  out.push(`Source: [\`${source}\`](../../${source})`, '')
+  return out
+}
+
+/** Render the full catalog (pure, deterministic given the manifest-ordered input). */
+export function render(catalog: ToolCatalog): string {
+  const lines: string[] = [
+    '<!-- Generated by scripts/gen-tool-catalog.ts — do not edit by hand.',
+    '     Run `pnpm run gen-tool-catalog` to regenerate. -->',
+    '',
+    '# Tool Schema Catalog',
+    '',
+    'Every model-facing tool a shipped plugin contributes to `ctx.tools`: the exact `name`, `description`, and JSON-Schema `parameters` the model receives via the system-prompt assembly. It complements the [cordis events & services catalog](../cordis-catalog/events-and-services.md) (the wiring a plugin listens to and calls) and [core-data-structures/](../core-data-structures/core.md) (the types those signatures move) — this page is the *tools* the agent is offered.',
+    '',
+    'This file is GENERATED and verified fresh by `pnpm run verify-tool-catalog` (part of `doc-sync`) — do not edit it by hand. Unlike the cordis catalog (a pure source-AST pass), this generator BOOTS each tool plugin on a real context and reads `ctx.tools.schemas()`, because a tool schema is not statically knowable (runtime-spread enums, concatenated descriptions, config-driven names, raw-JSON-Schema MCP tools). A completeness guard globs `packages/*/tool-*` and fails if any package is missing from the generator\'s boot manifest, so a new tool cannot be silently undocumented. See [the tool-schema-catalog RFC](../rfc/implemented/process/2026-07-02-tool-schema-catalog.md).',
+    '',
+    'Scope: shipped product tools under `packages/*/tool-*`. The `examples/` demo tools (e.g. `echo`) are excluded, matching the cordis catalog\'s packages-only scope.',
+    '',
+  ]
+  for (const entry of catalog) {
+    lines.push(`## \`${entry.pkg}\``, '')
+    for (const schema of entry.schemas) lines.push(...renderTool(schema, entry.source))
+  }
+  return lines.join('\n')
+}
+
+/** CLI entry: default writes the catalog, `--check` fails if the committed copy
+ * is stale. Guarded behind an entry-point check so importing this module for
+ * tests neither regenerates the committed file nor calls process.exit. */
+async function main(): Promise<void> {
+  const content = render(await collectToolCatalog())
+  if (process.argv.includes('--check')) {
+    let committed: string | null = null
+    try {
+      committed = readFileSync(resolve(root, OUT), 'utf8')
+    } catch {
+      // Only ENOENT (not yet generated) is expected; a present-but-unreadable
+      // file is not a state this repo produces. Either way the remedy is the
+      // same — regenerate — so treat a read failure as "stale".
+      committed = null
+    }
+    if (committed === content) {
+      console.log(`gen-tool-catalog: ${OUT} is up to date.`)
+      process.exit(0)
+    }
+    console.error(`gen-tool-catalog: ${OUT} is stale. Run \`pnpm run gen-tool-catalog\` and commit ${OUT}.`)
+    process.exit(1)
+  }
+
+  writeFileSync(resolve(root, OUT), content)
+  console.log(`gen-tool-catalog: wrote ${OUT}.`)
+}
+
+// Run only when invoked as a script, not when imported by a test.
+if (process.argv[1] && import.meta.filename === resolve(process.argv[1])) {
+  await main()
+}