@agentic-kit/dsh 0.2.0

package/LICENSE

@@ -0,0 +1,23 @@
+The MIT License (MIT)
+
+Copyright (c) 2025 Dan Lynch <pyramation@gmail.com>
+Copyright (c) 2025 Constructive <developers@constructive.io>
+Copyright (c) 2020-present, Interweb, Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,132 @@
+# @agentic-kit/dsh
+
+<p align="center" width="100%">
+  <img height="250" src="https://raw.githubusercontent.com/constructive-io/constructive/refs/heads/main/assets/outline-logo.svg" />
+</p>
+
+<p align="center" width="100%">
+  <a href="https://github.com/constructive-io/constructive/actions/workflows/run-tests.yaml">
+    <img height="20" src="https://github.com/constructive-io/constructive/actions/workflows/run-tests.yaml/badge.svg" />
+  </a>
+   <a href="https://github.com/constructive-io/constructive/blob/main/LICENSE"><img height="20" src="https://img.shields.io/badge/license-MIT-blue.svg"/></a>
+   <a href="https://www.npmjs.com/package/@agentic-kit/dsh"><img height="20" src="https://img.shields.io/github/package-json/v/constructive-io/constructive?filename=agentic%2Fdsh%2Fpackage.json"/></a>
+</p>
+
+The **DeepSeek Harness (dsh)** adapter — the sibling of [`@agentic-kit/pi`](https://www.npmjs.com/package/@agentic-kit/pi), and the reason the harness contracts are neutral. The same 18 [`@agentic-kit/db-tools`](https://www.npmjs.com/package/@agentic-kit/db-tools), the same confirm gate and the same run-log vocabulary, bound to a second harness without any of them changing.
+
+```
+neutral contracts:   HarnessTool     ConfirmGate      TranscriptEvent
+                          │               │                 ▲
+      @agentic-kit/pi ────┼───────────────┼─────────────────┤  pi's ToolDefinition, tool_call, pi session
+      @agentic-kit/dsh ───┴───────────────┴─────────────────┘  dsh's ToolDefinition, tools/pre-execute, dsh events
+```
+
+```bash
+npm install @agentic-kit/dsh
+```
+
+## What's inside
+
+- **`toDshTool` / `toDshTools`** — a neutral `HarnessTool` as dsh's `ToolDefinition`: parameters in dsh's JSON Schema subset, a declared canonical output whose value *is* the neutral `HarnessToolResult` (so dsh's durable log keeps the tool's structured `details`), and the caller's `AbortSignal` threaded to the tool.
+- **`createConstructivePlugin`** — the tools as a dsh plugin, with Constructive's confirm gate on dsh's `tools/pre-execute` waterfall. A gated call asks dsh's approval service; a host with no approval service composed gets a `deny`, never a silent mutation.
+- **`toDshParameters` / `convertDshParameters`** — zod → dsh's subset (`type`, `properties`, `required`, `items`, `oneOf`, `enum`, `const`, boolean `additionalProperties`). Constraints outside it are dropped from the *model-facing* schema and reported in `dropped`; they still hold, because a bound tool parses arguments with its own zod schema before the body runs. Structure that cannot degrade safely — a non-object root, a `$ref` — throws.
+- **`dshTranscriptReader`** — dsh's session-event log as neutral `TranscriptEvent`s, so a Constructive surface renders a dsh run through the same projectors as a pi one. Import it from `@agentic-kit/dsh/transcript` in a browser: that entry point has no node dependency.
+
+## Usage
+
+```ts
+import { configureHost } from '@agentic-kit/db-tools';
+import { createConstructivePlugin } from '@agentic-kit/dsh';
+
+configureHost(host);
+
+export default createConstructivePlugin({ cwd: () => projectDir });
+```
+
+Reading a dsh run back:
+
+```ts
+import { dshTranscriptReader } from '@agentic-kit/dsh/transcript';
+import { TranscriptReaderRegistry } from '@agentic-kit/run-log';
+
+const readers = new TranscriptReaderRegistry([piTranscriptReader, dshTranscriptReader]);
+const events = readers.require(record.transcriptFormat).toEvents(record.entry);
+```
+
+## No dsh dependency
+
+dsh is a developer preview whose packages promise breaking changes, and whose published rc's trail its own source. So this adapter binds to the *shape* dsh asks for — a tool definition, a tool run context, a content block, a plugin's `apply` — declared structurally in `dsh-types.ts`, and has no `@deepseek-ai/*` dependency. A host on any rc registers the plugin; dsh's ESM-only graph never reaches a CJS consumer of this package.
+
+---
+
+## Education and Tutorials
+
+ 1. 🚀 [Quickstart: Getting Up and Running](https://constructive.io/learn/quickstart)
+Get started with modular databases in minutes. Install prerequisites and deploy your first module.
+
+ 2. 📦 [Modular PostgreSQL Development with Database Packages](https://constructive.io/learn/modular-postgres)
+Learn to organize PostgreSQL projects with pgpm workspaces and reusable database modules.
+
+ 3. ✏️ [Authoring Database Changes](https://constructive.io/learn/authoring-database-changes)
+Master the workflow for adding, organizing, and managing database changes with pgpm.
+
+ 4. 🧪 [End-to-End PostgreSQL Testing with TypeScript](https://constructive.io/learn/e2e-postgres-testing)
+Master end-to-end PostgreSQL testing with ephemeral databases, RLS testing, and CI/CD automation.
+
+ 5. ⚡ [Supabase Testing](https://constructive.io/learn/supabase)
+Use TypeScript-first tools to test Supabase projects with realistic RLS, policies, and auth contexts.
+
+ 6. 💧 [Drizzle ORM Testing](https://constructive.io/learn/drizzle-testing)
+Run full-stack tests with Drizzle ORM, including database setup, teardown, and RLS enforcement.
+
+ 7. 🔧 [Troubleshooting](https://constructive.io/learn/troubleshooting)
+Common issues and solutions for pgpm, PostgreSQL, and testing.
+
+## Related Constructive Tooling
+
+### 📦 Package Management
+
+* [pgpm](https://github.com/constructive-io/constructive/tree/main/pgpm/pgpm): **🖥️ PostgreSQL Package Manager** for modular Postgres development. Works with database workspaces, scaffolding, migrations, seeding, and installing database packages.
+
+### 🧪 Testing
+
+* [pgsql-test](https://github.com/constructive-io/constructive/tree/main/postgres/pgsql-test): **📊 Isolated testing environments** with per-test transaction rollbacks—ideal for integration tests, complex migrations, and RLS simulation.
+* [pglite-test](https://github.com/constructive-io/constructive/tree/main/postgres/pglite-test): **🪶 Drop-in pgsql-test replacement backed by PGlite** — in-process Postgres, no server required, instance-per-suite isolation.
+* [pgsql-seed](https://github.com/constructive-io/constructive/tree/main/postgres/pgsql-seed): **🌱 PostgreSQL seeding utilities** for CSV, JSON, SQL data loading, and pgpm deployment.
+* [supabase-test](https://github.com/constructive-io/constructive/tree/main/postgres/supabase-test): **🧪 Supabase-native test harness** preconfigured for the local Supabase stack—per-test rollbacks, JWT/role context helpers, and CI/GitHub Actions ready.
+* [graphile-test](https://github.com/constructive-io/constructive/tree/main/graphile/graphile-test): **🔐 Authentication mocking** for Graphile-focused test helpers and emulating row-level security contexts.
+* [pg-query-context](https://github.com/constructive-io/constructive/tree/main/postgres/pg-query-context): **🔒 Session context injection** to add session-local context (e.g., `SET LOCAL`) into queries—ideal for setting `role`, `jwt.claims`, and other session settings.
+
+### 🧠 Parsing & AST
+
+* [pgsql-parser](https://www.npmjs.com/package/pgsql-parser): **🔄 SQL conversion engine** that interprets and converts PostgreSQL syntax.
+* [libpg-query-node](https://www.npmjs.com/package/libpg-query): **🌉 Node.js bindings** for `libpg_query`, converting SQL into parse trees.
+* [pg-proto-parser](https://www.npmjs.com/package/pg-proto-parser): **📦 Protobuf parser** for parsing PostgreSQL Protocol Buffers definitions to generate TypeScript interfaces, utility functions, and JSON mappings for enums.
+* [@pgsql/enums](https://www.npmjs.com/package/@pgsql/enums): **🏷️ TypeScript enums** for PostgreSQL AST for safe and ergonomic parsing logic.
+* [@pgsql/types](https://www.npmjs.com/package/@pgsql/types): **📝 Type definitions** for PostgreSQL AST nodes in TypeScript.
+* [@pgsql/utils](https://www.npmjs.com/package/@pgsql/utils): **🛠️ AST utilities** for constructing and transforming PostgreSQL syntax trees.
+
+### 📚 Documentation & Skills
+
+* [constructive-skills](https://github.com/constructive-io/constructive-skills): **📖 Platform documentation and AI agent skills** — feature catalog, blueprint reference, SDK guides (i18n, billing, limits, events, uploads, security, entities, search, AI), and deployment guides.
+
+Install skills for AI coding agents:
+
+```bash
+# All platform skills (security, blueprints, codegen, billing, etc.)
+npx skills add constructive-io/constructive-skills
+
+# Individual repo skills (pgpm, testing, CLI, search, etc.)
+npx skills add https://github.com/constructive-io/constructive --skill pgpm
+npx skills add https://github.com/constructive-io/constructive --skill constructive-testing
+```
+
+## Credits
+
+**🛠 Built by the [Constructive](https://constructive.io) team — creators of modular Postgres tooling for secure, composable backends. If you like our work, contribute on [GitHub](https://github.com/constructive-io).**
+
+## Disclaimer
+
+AS DESCRIBED IN THE LICENSES, THE SOFTWARE IS PROVIDED "AS IS", AT YOUR OWN RISK, AND WITHOUT WARRANTIES OF ANY KIND.
+
+No developer or entity involved in creating this software will be liable for any claims or damages whatsoever associated with your use, inability to use, or your interaction with other users of the code, including any direct, indirect, incidental, special, exemplary, punitive or consequential damages, or loss of profits, cryptocurrencies, tokens, or anything else of value.

package/dsh-tool.d.ts

@@ -0,0 +1,32 @@
+import type { AnyHarnessTool, HarnessTool } from '@agentic-kit/harness';
+import type { z } from 'zod';
+import type { DshToolDefinition } from './dsh-types';
+/** What a bound tool needs that a `HarnessTool` does not state. */
+export interface ToDshToolOptions {
+    /**
+     * The working directory a tool resolves project context from. dsh keeps the
+     * directory on the session header and its filesystem service rather than on a
+     * tool's execution context, so the adapter is told once instead of guessing
+     * per call. Defaults to `process.cwd()`.
+     */
+    cwd?: () => string;
+}
+/**
+ * Bind a neutral `HarnessTool` to dsh's `ToolDefinition`.
+ *
+ * The sibling of `toPiTool` — same tools, a second harness's shape. dsh asks
+ * for three things pi does not: parameters in its JSON Schema subset (see
+ * `./schema`), a *declared canonical output* with a pure projection from that
+ * value to model-facing content, and a body that returns the value rather than
+ * the content. So the neutral `HarnessToolResult` becomes the canonical value
+ * verbatim and `output.render` projects its `content` — which means dsh's
+ * durable log keeps the tool's structured `details`, and a Constructive
+ * renderer reads the same detail out of a dsh transcript as out of a pi one.
+ *
+ * Arguments are parsed with the tool's own zod schema before the body runs:
+ * dsh validates against the narrowed subset schema, and this restores every
+ * constraint that narrowing dropped.
+ */
+export declare function toDshTool<TParams extends z.ZodType, TDetails>(tool: HarnessTool<TParams, TDetails>, options?: ToDshToolOptions): DshToolDefinition;
+/** Bind a whole tool set, in registration order. */
+export declare function toDshTools(tools: readonly AnyHarnessTool[], options?: ToDshToolOptions): DshToolDefinition[];

package/dsh-tool.js

@@ -0,0 +1,87 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.toDshTool = toDshTool;
+exports.toDshTools = toDshTools;
+const schema_1 = require("./schema");
+/** The canonical value a bound tool returns: the neutral result, as JSON. */
+const OUTPUT_SCHEMA = {
+    type: 'object',
+    properties: {
+        content: { type: 'array', items: { type: 'object' } },
+        details: {},
+        terminate: { type: 'boolean' }
+    },
+    required: ['content']
+};
+/**
+ * Bind a neutral `HarnessTool` to dsh's `ToolDefinition`.
+ *
+ * The sibling of `toPiTool` — same tools, a second harness's shape. dsh asks
+ * for three things pi does not: parameters in its JSON Schema subset (see
+ * `./schema`), a *declared canonical output* with a pure projection from that
+ * value to model-facing content, and a body that returns the value rather than
+ * the content. So the neutral `HarnessToolResult` becomes the canonical value
+ * verbatim and `output.render` projects its `content` — which means dsh's
+ * durable log keeps the tool's structured `details`, and a Constructive
+ * renderer reads the same detail out of a dsh transcript as out of a pi one.
+ *
+ * Arguments are parsed with the tool's own zod schema before the body runs:
+ * dsh validates against the narrowed subset schema, and this restores every
+ * constraint that narrowing dropped.
+ */
+function toDshTool(tool, options = {}) {
+    const cwd = options.cwd ?? (() => process.cwd());
+    return {
+        name: tool.name,
+        description: describe(tool),
+        parameters: (0, schema_1.toDshParameters)(tool.parameters),
+        output: {
+            schema: OUTPUT_SCHEMA,
+            render: (_args, value) => renderContent(value)
+        },
+        async execute(args, exec) {
+            const params = tool.parameters.parse(args);
+            const result = await tool.execute(params, {
+                cwd: cwd(),
+                signal: exec.signal
+            });
+            return {
+                content: result.content,
+                details: result.details === undefined ? null : result.details,
+                ...(result.terminate === undefined ? {} : { terminate: result.terminate })
+            };
+        }
+    };
+}
+/** Bind a whole tool set, in registration order. */
+function toDshTools(tools, options = {}) {
+    return tools.map((tool) => toDshTool(tool, options));
+}
+/**
+ * dsh has one description field where pi has three, so a tool's prompt snippet
+ * and guidelines — the parts that tell a model *when* to reach for it — are
+ * folded in rather than dropped.
+ */
+function describe(tool) {
+    const parts = [tool.description];
+    if (tool.promptSnippet)
+        parts.push(tool.promptSnippet);
+    if (tool.promptGuidelines?.length) {
+        parts.push(tool.promptGuidelines.map((line) => `- ${line}`).join('\n'));
+    }
+    return parts.join('\n\n');
+}
+/** The neutral result's content blocks, in dsh's block vocabulary. */
+function renderContent(value) {
+    const content = value?.content;
+    if (!Array.isArray(content))
+        return [];
+    return content.map((block) => {
+        const typed = block;
+        if (typed.type === 'text')
+            return { type: 'text', text: String(typed.text ?? '') };
+        // dsh's image block references an attachment the attachment service owns, so
+        // an inline image cannot be handed over as one; its text form is honest.
+        return { type: 'text', text: JSON.stringify(block) };
+    });
+}

package/dsh-types.d.ts

@@ -0,0 +1,119 @@
+/**
+ * The DeepSeek Harness surface this adapter binds to, declared structurally.
+ *
+ * Nothing here imports `@deepseek-ai/dsh-*`, and the package has no dependency
+ * on it. That is deliberate rather than lazy: dsh is a developer preview whose
+ * packages promise breaking changes, and its published rc's trail its own
+ * source. A structural declaration of the four things we actually touch — a
+ * tool definition, a tool's run context, a content block, a plugin's `apply` —
+ * binds to the *shape* dsh asks for, so a host on any rc can register our tools
+ * without this package tracking their release train. It also keeps the adapter
+ * free of dsh's ESM-only graph: a CJS consumer imports it like any other
+ * agentic-kit package.
+ *
+ * Mirrored from dsh `0.1.0-rc.7` (`packages/core/tools`, `packages/core/session`,
+ * `packages/llm/llm`). Where dsh brands a string (`CallId`, `SessionId`) this
+ * uses `string` — a brand is theirs to enforce, and ours to carry.
+ */
+/** dsh's supported JSON Schema subset, as a tool declares its parameters. */
+export interface DshJsonSchema {
+    type?: string;
+    properties?: Record<string, DshJsonSchema>;
+    required?: string[];
+    items?: DshJsonSchema;
+    oneOf?: DshJsonSchema[];
+    enum?: unknown[];
+    const?: unknown;
+    additionalProperties?: boolean;
+    description?: string;
+    title?: string;
+    default?: unknown;
+    examples?: unknown[];
+}
+/** A model-facing content block. dsh names reasoning `reasoning`, not `thinking`. */
+export type DshContentBlock = {
+    type: 'text';
+    text: string;
+} | {
+    type: 'reasoning';
+    text: string;
+} | {
+    type: string;
+    [key: string]: unknown;
+};
+/**
+ * What dsh hands a tool body: call identity, the caller's cancellation, and
+ * the agent the call runs for. Notably *not* a working directory — dsh keeps
+ * that on the session header and its filesystem service — so an adapter has to
+ * supply one (see `ConstructivePluginOptions.cwd`).
+ */
+export interface DshToolRunContext {
+    readonly callId: string;
+    readonly name: string;
+    readonly signal: AbortSignal;
+    readonly agent?: unknown;
+}
+/** A tool's canonical-output contract: a schema for the value, and its rendering. */
+export interface DshToolOutputDefinition {
+    readonly schema: DshJsonSchema;
+    render(args: unknown, value: unknown): DshContentBlock[];
+}
+/** A dsh tool, as `tools.register()` takes it. */
+export interface DshToolDefinition {
+    readonly name: string;
+    readonly description: string;
+    readonly parameters: DshJsonSchema;
+    readonly output: DshToolOutputDefinition;
+    execute(args: unknown, exec: DshToolRunContext): Promise<unknown>;
+}
+/** The pending call a `tools/pre-execute` listener decides on. */
+export interface DshToolExecution {
+    readonly callId: string;
+    readonly name: string;
+    readonly arguments: unknown;
+    readonly agent?: unknown;
+}
+/** dsh's pre-dispatch decision. `ask` defers to its approval answerers. */
+export type DshPreToolDecision = {
+    kind: 'allow';
+} | {
+    kind: 'deny';
+    reason: string;
+} | {
+    kind: 'ask';
+    reason?: string;
+};
+/** dsh's approval outcomes; only `allowed-once` is an approval. */
+export type DshApprovalOutcome = 'allowed-once' | 'rejected' | 'cancelled' | 'unavailable';
+/**
+ * dsh's approval service, as much of it as a gate needs. Present on the plugin
+ * context only when the host composed `@deepseek-ai/dsh-user-approval`.
+ */
+export interface DshApprovalService {
+    request(request: {
+        toolName: string;
+        callId?: string;
+        reason?: string;
+        agent?: unknown;
+    }): Promise<DshApprovalOutcome>;
+}
+/** The tool registry service (`ctx.tools`). */
+export interface DshToolRuntime {
+    register(definition: DshToolDefinition): () => void;
+}
+/**
+ * The plugin context, narrowed to the services this adapter uses. dsh's own
+ * `Context` carries every composed service and a cordis event bus; a plugin
+ * only ever needs the parts it declared.
+ */
+export interface DshPluginContext {
+    tools: DshToolRuntime;
+    approval?: DshApprovalService;
+    on(event: 'tools/pre-execute', listener: (exec: DshToolExecution, next: () => Promise<DshPreToolDecision>) => Promise<DshPreToolDecision>): unknown;
+}
+/** A cordis plugin in its object form, which is how dsh bundles load one. */
+export interface DshPlugin {
+    readonly name: string;
+    readonly inject?: readonly string[];
+    apply(ctx: DshPluginContext): void;
+}

package/dsh-types.js

@@ -0,0 +1,19 @@
+"use strict";
+/**
+ * The DeepSeek Harness surface this adapter binds to, declared structurally.
+ *
+ * Nothing here imports `@deepseek-ai/dsh-*`, and the package has no dependency
+ * on it. That is deliberate rather than lazy: dsh is a developer preview whose
+ * packages promise breaking changes, and its published rc's trail its own
+ * source. A structural declaration of the four things we actually touch — a
+ * tool definition, a tool's run context, a content block, a plugin's `apply` —
+ * binds to the *shape* dsh asks for, so a host on any rc can register our tools
+ * without this package tracking their release train. It also keeps the adapter
+ * free of dsh's ESM-only graph: a CJS consumer imports it like any other
+ * agentic-kit package.
+ *
+ * Mirrored from dsh `0.1.0-rc.7` (`packages/core/tools`, `packages/core/session`,
+ * `packages/llm/llm`). Where dsh brands a string (`CallId`, `SessionId`) this
+ * uses `string` — a brand is theirs to enforce, and ours to carry.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });

package/esm/dsh-tool.d.ts

@@ -0,0 +1,32 @@
+import type { AnyHarnessTool, HarnessTool } from '@agentic-kit/harness';
+import type { z } from 'zod';
+import type { DshToolDefinition } from './dsh-types';
+/** What a bound tool needs that a `HarnessTool` does not state. */
+export interface ToDshToolOptions {
+    /**
+     * The working directory a tool resolves project context from. dsh keeps the
+     * directory on the session header and its filesystem service rather than on a
+     * tool's execution context, so the adapter is told once instead of guessing
+     * per call. Defaults to `process.cwd()`.
+     */
+    cwd?: () => string;
+}
+/**
+ * Bind a neutral `HarnessTool` to dsh's `ToolDefinition`.
+ *
+ * The sibling of `toPiTool` — same tools, a second harness's shape. dsh asks
+ * for three things pi does not: parameters in its JSON Schema subset (see
+ * `./schema`), a *declared canonical output* with a pure projection from that
+ * value to model-facing content, and a body that returns the value rather than
+ * the content. So the neutral `HarnessToolResult` becomes the canonical value
+ * verbatim and `output.render` projects its `content` — which means dsh's
+ * durable log keeps the tool's structured `details`, and a Constructive
+ * renderer reads the same detail out of a dsh transcript as out of a pi one.
+ *
+ * Arguments are parsed with the tool's own zod schema before the body runs:
+ * dsh validates against the narrowed subset schema, and this restores every
+ * constraint that narrowing dropped.
+ */
+export declare function toDshTool<TParams extends z.ZodType, TDetails>(tool: HarnessTool<TParams, TDetails>, options?: ToDshToolOptions): DshToolDefinition;
+/** Bind a whole tool set, in registration order. */
+export declare function toDshTools(tools: readonly AnyHarnessTool[], options?: ToDshToolOptions): DshToolDefinition[];

package/esm/dsh-tool.js

@@ -0,0 +1,83 @@
+import { toDshParameters } from './schema';
+/** The canonical value a bound tool returns: the neutral result, as JSON. */
+const OUTPUT_SCHEMA = {
+    type: 'object',
+    properties: {
+        content: { type: 'array', items: { type: 'object' } },
+        details: {},
+        terminate: { type: 'boolean' }
+    },
+    required: ['content']
+};
+/**
+ * Bind a neutral `HarnessTool` to dsh's `ToolDefinition`.
+ *
+ * The sibling of `toPiTool` — same tools, a second harness's shape. dsh asks
+ * for three things pi does not: parameters in its JSON Schema subset (see
+ * `./schema`), a *declared canonical output* with a pure projection from that
+ * value to model-facing content, and a body that returns the value rather than
+ * the content. So the neutral `HarnessToolResult` becomes the canonical value
+ * verbatim and `output.render` projects its `content` — which means dsh's
+ * durable log keeps the tool's structured `details`, and a Constructive
+ * renderer reads the same detail out of a dsh transcript as out of a pi one.
+ *
+ * Arguments are parsed with the tool's own zod schema before the body runs:
+ * dsh validates against the narrowed subset schema, and this restores every
+ * constraint that narrowing dropped.
+ */
+export function toDshTool(tool, options = {}) {
+    const cwd = options.cwd ?? (() => process.cwd());
+    return {
+        name: tool.name,
+        description: describe(tool),
+        parameters: toDshParameters(tool.parameters),
+        output: {
+            schema: OUTPUT_SCHEMA,
+            render: (_args, value) => renderContent(value)
+        },
+        async execute(args, exec) {
+            const params = tool.parameters.parse(args);
+            const result = await tool.execute(params, {
+                cwd: cwd(),
+                signal: exec.signal
+            });
+            return {
+                content: result.content,
+                details: result.details === undefined ? null : result.details,
+                ...(result.terminate === undefined ? {} : { terminate: result.terminate })
+            };
+        }
+    };
+}
+/** Bind a whole tool set, in registration order. */
+export function toDshTools(tools, options = {}) {
+    return tools.map((tool) => toDshTool(tool, options));
+}
+/**
+ * dsh has one description field where pi has three, so a tool's prompt snippet
+ * and guidelines — the parts that tell a model *when* to reach for it — are
+ * folded in rather than dropped.
+ */
+function describe(tool) {
+    const parts = [tool.description];
+    if (tool.promptSnippet)
+        parts.push(tool.promptSnippet);
+    if (tool.promptGuidelines?.length) {
+        parts.push(tool.promptGuidelines.map((line) => `- ${line}`).join('\n'));
+    }
+    return parts.join('\n\n');
+}
+/** The neutral result's content blocks, in dsh's block vocabulary. */
+function renderContent(value) {
+    const content = value?.content;
+    if (!Array.isArray(content))
+        return [];
+    return content.map((block) => {
+        const typed = block;
+        if (typed.type === 'text')
+            return { type: 'text', text: String(typed.text ?? '') };
+        // dsh's image block references an attachment the attachment service owns, so
+        // an inline image cannot be handed over as one; its text form is honest.
+        return { type: 'text', text: JSON.stringify(block) };
+    });
+}

package/esm/dsh-types.d.ts

@@ -0,0 +1,119 @@
+/**
+ * The DeepSeek Harness surface this adapter binds to, declared structurally.
+ *
+ * Nothing here imports `@deepseek-ai/dsh-*`, and the package has no dependency
+ * on it. That is deliberate rather than lazy: dsh is a developer preview whose
+ * packages promise breaking changes, and its published rc's trail its own
+ * source. A structural declaration of the four things we actually touch — a
+ * tool definition, a tool's run context, a content block, a plugin's `apply` —
+ * binds to the *shape* dsh asks for, so a host on any rc can register our tools
+ * without this package tracking their release train. It also keeps the adapter
+ * free of dsh's ESM-only graph: a CJS consumer imports it like any other
+ * agentic-kit package.
+ *
+ * Mirrored from dsh `0.1.0-rc.7` (`packages/core/tools`, `packages/core/session`,
+ * `packages/llm/llm`). Where dsh brands a string (`CallId`, `SessionId`) this
+ * uses `string` — a brand is theirs to enforce, and ours to carry.
+ */
+/** dsh's supported JSON Schema subset, as a tool declares its parameters. */
+export interface DshJsonSchema {
+    type?: string;
+    properties?: Record<string, DshJsonSchema>;
+    required?: string[];
+    items?: DshJsonSchema;
+    oneOf?: DshJsonSchema[];
+    enum?: unknown[];
+    const?: unknown;
+    additionalProperties?: boolean;
+    description?: string;
+    title?: string;
+    default?: unknown;
+    examples?: unknown[];
+}
+/** A model-facing content block. dsh names reasoning `reasoning`, not `thinking`. */
+export type DshContentBlock = {
+    type: 'text';
+    text: string;
+} | {
+    type: 'reasoning';
+    text: string;
+} | {
+    type: string;
+    [key: string]: unknown;
+};
+/**
+ * What dsh hands a tool body: call identity, the caller's cancellation, and
+ * the agent the call runs for. Notably *not* a working directory — dsh keeps
+ * that on the session header and its filesystem service — so an adapter has to
+ * supply one (see `ConstructivePluginOptions.cwd`).
+ */
+export interface DshToolRunContext {
+    readonly callId: string;
+    readonly name: string;
+    readonly signal: AbortSignal;
+    readonly agent?: unknown;
+}
+/** A tool's canonical-output contract: a schema for the value, and its rendering. */
+export interface DshToolOutputDefinition {
+    readonly schema: DshJsonSchema;
+    render(args: unknown, value: unknown): DshContentBlock[];
+}
+/** A dsh tool, as `tools.register()` takes it. */
+export interface DshToolDefinition {
+    readonly name: string;
+    readonly description: string;
+    readonly parameters: DshJsonSchema;
+    readonly output: DshToolOutputDefinition;
+    execute(args: unknown, exec: DshToolRunContext): Promise<unknown>;
+}
+/** The pending call a `tools/pre-execute` listener decides on. */
+export interface DshToolExecution {
+    readonly callId: string;
+    readonly name: string;
+    readonly arguments: unknown;
+    readonly agent?: unknown;
+}
+/** dsh's pre-dispatch decision. `ask` defers to its approval answerers. */
+export type DshPreToolDecision = {
+    kind: 'allow';
+} | {
+    kind: 'deny';
+    reason: string;
+} | {
+    kind: 'ask';
+    reason?: string;
+};
+/** dsh's approval outcomes; only `allowed-once` is an approval. */
+export type DshApprovalOutcome = 'allowed-once' | 'rejected' | 'cancelled' | 'unavailable';
+/**
+ * dsh's approval service, as much of it as a gate needs. Present on the plugin
+ * context only when the host composed `@deepseek-ai/dsh-user-approval`.
+ */
+export interface DshApprovalService {
+    request(request: {
+        toolName: string;
+        callId?: string;
+        reason?: string;
+        agent?: unknown;
+    }): Promise<DshApprovalOutcome>;
+}
+/** The tool registry service (`ctx.tools`). */
+export interface DshToolRuntime {
+    register(definition: DshToolDefinition): () => void;
+}
+/**
+ * The plugin context, narrowed to the services this adapter uses. dsh's own
+ * `Context` carries every composed service and a cordis event bus; a plugin
+ * only ever needs the parts it declared.
+ */
+export interface DshPluginContext {
+    tools: DshToolRuntime;
+    approval?: DshApprovalService;
+    on(event: 'tools/pre-execute', listener: (exec: DshToolExecution, next: () => Promise<DshPreToolDecision>) => Promise<DshPreToolDecision>): unknown;
+}
+/** A cordis plugin in its object form, which is how dsh bundles load one. */
+export interface DshPlugin {
+    readonly name: string;
+    readonly inject?: readonly string[];
+    apply(ctx: DshPluginContext): void;
+}