@botbotgo/agent-harness 0.0.307 → 0.0.309

package/README.md

@@ -469,9 +469,9 @@ import { AgentHarnessRuntime, createAgentHarness } from "@botbotgo/agent-harness
 const runtime: AgentHarnessRuntime = await createAgentHarness("/absolute/path/to/workspace");
 ```
 
-`createAgentHarness(...)` loads the workspace, resolves `resources/`, initializes persistence under `runtimeRoot`, and starts runtime maintenance.
+`createAgentHarness(...)` loads the workspace, resolves workspace sources, initializes persistence under `runtimeRoot`, and starts runtime maintenance.
 
-`runtime.spec.resources` may attach multiple extra resource packages. Each entry may point either to a package root that contains `resources/`, or directly to a resource folder that contains its own `package.json`.
+`runtime.spec.sources` is the primary public discovery surface for local tools, package tools, and skill packages.
 
 ```yaml
 apiVersion: agent-harness/v1alpha1
@@ -479,11 +479,29 @@ kind: Runtime
 metadata:
   name: default
 spec:
-  resources:
-    - ../shared-tools
-    - file:../shared-skills
+  sources:
+    tools:
+      - file://./resources/tools
+      - file://../shared-tools
+      - npm://@acme/agent-tools
+    skills:
+      - file://./resources/skills
+      - https://example.com/skills/review/SKILL.md
 ```
 
+Tool-source rules:
+
+- `file://...` scans only the configured folder
+- `npm://...` resolves one package, auto-installs it when missing, and discovers exported `tool({...})` definitions from the package entry
+- tool discovery never traverses `node_modules/**`
+
+Skill-source rules:
+
+- `file://...` accepts a skill collection folder, a single skill root, or a direct `SKILL.md` path
+- `http://...` and `https://...` currently accept a single remote `SKILL.md`
+
+`runtime.spec.resources` remains supported as a compatibility path for attached resource packages.
+
 `createAgentHarness(..., { load })` accepts workspace loading controls.
 
 Merge order is deterministic:
@@ -739,8 +757,10 @@ Discovery rules:
 
 - every YAML document under `config/**` is discovered recursively; filenames and subfolders are organizational only
 - YAML object semantics come from `kind`, `metadata.name` or `id`, and object content rather than the file path
-- local tools are auto-discovered from `resources/tools/**/*.js|*.mjs|*.cjs` when they export `tool({...})`
-- skills are auto-discovered from `resources/skills/**/SKILL.md`
+- `Runtime.spec.sources.tools` defaults to `file://./resources/tools`
+- `Runtime.spec.sources.skills` defaults to `file://./resources/skills`
+- local file-based tools are auto-discovered from each configured tool folder when modules export `tool({...})`
+- file-based skills are auto-discovered from each configured skill source
 - a minimal workspace can start with only `config/models.yaml`; the repository defaults provide the `Runtime`, the default `orchestra` host, and runtime-managed durable memory with `enabled: true`
 - when you do not override runtime placement, harness-owned generated state is written under `./.botbotgo/`
 
@@ -768,7 +788,9 @@ For DeepAgents-backed agents, the runtime still keeps an internal compatibility
 
 Default wiring guidance:
 
-- let workspace startup scan local and attached `resources` packages into one registry
+- let `Runtime.spec.sources` declare the tool and skill roots the workspace owns
+- let workspace startup scan only those declared sources into one registry
+- let workspace startup scan local and attached `resources` packages into one registry when compatibility paths are still in use
 - let agents whitelist tools and skills by name
 - keep `config/catalogs/tools.yaml` for reusable shared tools
 - keep `config/catalogs/mcp.yaml` for shared MCP server definitions
@@ -810,6 +832,8 @@ Important fields:
 
 - `runtimeRoot`
 - `concurrency.maxConcurrentRequests`
+- `sources.tools`
+- `sources.skills`
 - `routing.defaultAgentId`
 - `routing.rules`
 - `toolModuleDiscovery.scope`
@@ -826,7 +850,17 @@ Important fields:
 - `maintenance.checkpoints` trims backend checkpoint state used for resume/recovery
 - `maintenance.records` trims harness-owned terminal session/request records stored in `runtime.sqlite`
 
-`toolModuleDiscovery.scope` controls how local `resources/tools/`-style module discovery walks tool directories:
+`sources.tools` controls which tool roots or packages participate in workspace discovery:
+
+- `file://...` for folder scanning
+- `npm://...` for package-entry discovery and auto-install when missing
+
+`sources.skills` controls which skill folders or skill documents participate in workspace discovery:
+
+- `file://...` for local folders, skill roots, or direct `SKILL.md`
+- `http://...` / `https://...` for one remote `SKILL.md`
+
+`toolModuleDiscovery.scope` controls how local `resources/tools/`-style file discovery walks tool directories:
 
 - `recursive` is the default and keeps scanning nested folders
 - `top-level` limits module discovery to files directly under each tool root while leaving YAML catalogs recursive
@@ -1144,6 +1178,7 @@ ACP transport notes:
 - ACP transport validation now covers the reference-client core flow: capability discovery, request submit, session lookup, request lookup, invalid-JSON handling, notification calls without response ids, stdio JSON-RPC, and HTTP plus SSE runtime notifications.
 - Cross-protocol conformance now has an explicit regression gate as well: ACP submission, A2A task lookup and continuation, and runtime MCP inspection must all project the same persisted `sessionId` / `requestId` runtime records instead of drifting into surface-specific identifiers or side stores.
 - For the thinnest editor or CLI starter, begin with `agent-harness acp serve --workspace . --transport stdio` and mirror the `examples/03_protocol-surfaces/app/acp-stdio/main.mjs` wire shape. Applications that want an in-process reference client can use `createAcpStdioClient(...)` to issue JSON-RPC requests and route runtime notifications without hand-rolling line parsing.
+- When a local ACP HTTP endpoint should stay up beyond one foreground shell, use `botbotgo acp start --workspace . --host 127.0.0.1 --port 8787` and later `botbotgo acp stop --workspace .`. The CLI records the managed process under `.botbotgo/services/` so local operators can start and stop it without a second process manager.
 - `botbotgo` is the shortest local terminal entrypoint for a published install. It defaults the workspace to the current directory, so teams can `cd` into their own runtime workspace and run `botbotgo` or `botbotgo "..."` directly. `agent-harness` keeps the same implicit-chat behavior, and `-w/--workspace` still lets one shell point at another workspace when needed.
 - `agent-harness chat --workspace .` still acts as a local terminal shell over the shared `HarnessClient` contract when you want the explicit subcommand form: the default `stdio` path runs directly in-process against the workspace runtime, while `--transport http --host <host> --port <port>` can still target an already-running ACP HTTP endpoint. One-shot use can pass `--message`, while interactive mode supports `/context`, `/new`, `/agent <agentId>`, `/sessions`, `/requests`, `/resume <sessionId>`, `/approvals`, `/approve`, `/reject`, `/cancel`, `/events`, `/trace`, `/health`, `/overview`, `/session`, `/request [requestId]`, and `/exit`. `/resume` now validates the target session, restores its latest request id, and rehydrates the active agent context; `/request <requestId>` can switch the active request context to a persisted request; `/new` clears the current session/request context without leaving the shell. Terminal chat now keeps one operator-facing flow: it streams tool and progress events as they happen and still prints the full final answer, instead of switching to a separate request-tree-only mode.
 - Local repo usage differs from the published binary on purpose. After cloning the repo, use `npm run chat -- --workspace ./config` or `npm run agent-harness -- chat --workspace ./config`. The extra `--` matters: without it, npm treats `--workspace` as npm's own workspace flag. The standalone `agent-harness ...` command only works after the package has been installed or linked so the `bin` entry is on your `PATH`.
@@ -1152,8 +1187,9 @@ ACP transport notes:
 - Chat startup now also performs a lightweight workspace-model preflight for the local Ollama path. If the configured endpoint is unreachable or responds with `404 page not found`, the shell prints that warning before the first prompt so endpoint mismatches show up immediately instead of only after the first failed message.
 - The interactive prompt now carries the live `agent`, `session`, and short `request` identifier together, so after each reply and during shell-history navigation the user stays anchored to the current runtime turn instead of dropping back to a bare input prompt.
 - `serveA2aHttp(runtime)` exposes an A2A-compatible HTTP JSON-RPC bridge plus agent card discovery, mapping both existing methods such as `message/send` and A2A v1.0 PascalCase methods such as `SendMessage`, `SendStreamingMessage`, `GetTask`, `ListTasks`, `CancelTask`, `SubscribeToTask`, `GetAgentCard`, `GetExtendedAgentCard`, and task push-notification config methods onto the existing session/request runtime surface. The bridge now advertises both `1.0` and `0.3` JSON-RPC interfaces, answers `HEAD` / `OPTIONS` discovery on the agent-card path, sets supported-version discovery headers, can optionally expose registry URLs plus detached signed-card metadata for surrounding discovery systems, validates `A2A-Version`, records `A2A-Extensions` into runtime invocation metadata, publishes `TASK_STATE_*` statuses plus the `{ task }` `SendMessage` wrapper, streams an initial `{ task }` snapshot plus later `{ statusUpdate }` payloads over SSE for v1 streaming methods, and can send best-effort webhook task snapshots for configured push notification receivers.
+- For a managed local bridge, use `botbotgo a2a start --workspace . --host 127.0.0.1 --port 8080` and later `botbotgo a2a stop --workspace .`. This uses the same `.botbotgo/services/` state directory as ACP so both local protocol bridges follow one terminal-first workflow.
 - `serveAgUiHttp(runtime)` exposes an AG-UI-compatible HTTP SSE bridge that projects runtime lifecycle, safe progress commentary, text output, upstream thinking, step progress, and tool calls onto `RUN_*`, `STATUS_UPDATE`, `TEXT_MESSAGE_*`, `THINKING_TEXT_MESSAGE_*`, `STEP_*`, and `TOOL_CALL_*` events for UI clients.
-- `createRuntimeMcpServer(runtime)` and `serveRuntimeMcpOverStdio(runtime)` expose the persisted runtime control surface itself as MCP tools, including sessions, requests, approvals, artifacts, events, and package export helpers.
+- `createRuntimeMcpServer(runtime)`, `serveRuntimeMcpOverStdio(runtime)`, and `serveRuntimeMcpOverStreamableHttp(runtime)` expose the persisted runtime control surface itself as MCP tools, including sessions, requests, approvals, artifacts, events, and package export helpers. `botbotgo mcp serve --transport streamable-http --host 127.0.0.1 --port 8090` serves the same tool surface over Streamable HTTP, and `botbotgo mcp start|stop` manages that background endpoint for one workspace.
 - `listRequestEvents(...)`, `listRequestTraceItems(...)`, and `exportRequestPackage(...)` are the request-first inspection helpers.
 - `exportRequestPackage(...)` and `exportSessionPackage(...)` package stable runtime records, transcript, approvals, events, artifacts, and governance evidence for operator tooling without reaching into persistence internals.
 - `runtime/default.governance.remoteMcp` can now deny or allow specific MCP servers, raise approval requirements by transport, and stamp transport-based risk tiers into runtime governance bundles. MCP server catalogs can also declare trust tier, access mode, tenant scope, approval policy, prompt-injection risk, and OAuth scope metadata so governance bundles capture why one remote tool is treated as high-risk. Tool policy overrides can also set `decisionMode: manual | auto-approve | auto-reject | deny-and-continue` so operator evidence and execution behavior stay aligned.

package/README.zh.md

@@ -464,9 +464,9 @@ import { AgentHarnessRuntime, createAgentHarness } from "@botbotgo/agent-harness
 const runtime: AgentHarnessRuntime = await createAgentHarness("/absolute/path/to/workspace");
 ```
 
-`createAgentHarness(...)` 会加载工作区、解析 `resources/`、在 `runtimeRoot` 下初始化持久化，并启动运行时维护任务。
+`createAgentHarness(...)` 会加载工作区、解析工作区 source、在 `runtimeRoot` 下初始化持久化，并启动运行时维护任务。
 
-`runtime.spec.resources` 可以挂载多个额外资源包。每个条目既可以指向“包根目录下带有 `resources/` 的目录”，也可以直接指向“自身带有 `package.json` 的资源目录”。
+`runtime.spec.sources` 现在是本地工具、npm 工具包与 skill package 的主公开发现入口。
 
 ```yaml
 apiVersion: agent-harness/v1alpha1
@@ -474,11 +474,29 @@ kind: Runtime
 metadata:
   name: default
 spec:
-  resources:
-    - ../shared-tools
-    - file:../shared-skills
+  sources:
+    tools:
+      - file://./resources/tools
+      - file://../shared-tools
+      - npm://@acme/agent-tools
+    skills:
+      - file://./resources/skills
+      - https://example.com/skills/review/SKILL.md
 ```
 
+tool source 规则：
+
+- `file://...` 只扫描显式配置的目录
+- `npm://...` 只解析单个包；本地缺失时会自动安装，再从包入口发现导出的 `tool({...})`
+- tool 发现永远不会遍历 `node_modules/**`
+
+skill source 规则：
+
+- `file://...` 可以指向 skill 集合目录、单个 skill root，或直接指向 `SKILL.md`
+- `http://...` 与 `https://...` 当前只支持一个远程 `SKILL.md`
+
+`runtime.spec.resources` 仍保留为兼容旧 attached resource package 的路径。
+
 `createAgentHarness(..., { load })` 支持工作区加载控制。
 
 合并顺序是确定性的：
@@ -710,8 +728,10 @@ await stop(runtime);
 
 - `config/**` 下的所有 YAML 文档都会被递归发现；文件名与子目录只用于组织，不参与语义
 - YAML 对象语义由 `kind`、`metadata.name` 或 `id` 以及对象内容决定，而不是由文件路径决定
-- 本地工具会从 `resources/tools/**/*.js|*.mjs|*.cjs` 中自动发现，前提是模块导出 `tool({...})`
-- skills 会从 `resources/skills/**/SKILL.md` 自动发现
+- `Runtime.spec.sources.tools` 默认值是 `file://./resources/tools`
+- `Runtime.spec.sources.skills` 默认值是 `file://./resources/skills`
+- file-based 工具会从每个声明的 tool source 自动发现，前提是模块导出 `tool({...})`
+- file-based skills 会从每个声明的 skill source 自动发现
 - 一个最小工作区只放 `config/models.yaml` 也可以启动；仓库默认值会补上 `Runtime`、默认 `orchestra` host，以及默认开启的 runtime-managed durable memory
 - 如果不显式覆盖 runtime 放置位置，harness 生成的数据默认写到 `./.botbotgo/`
 
@@ -740,7 +760,9 @@ await stop(runtime);
 
 配置大致分这几层（由下至上叠加）：
 
-- workspace 启动时扫描本地与附加的 `resources` 包，建立统一 registry
+- 先由 `Runtime.spec.sources` 声明工作区实际拥有的 tool / skill 来源
+- workspace 启动时只扫描这些显式声明的 source，并建立统一 registry
+- workspace 启动时扫描本地与附加的 `resources` 包，建立统一 registry；这条兼容路径仍可继续工作
 - 各 agent 再按名称白名单选用 tools 与 skills
 - `config/runtime/workspace.yaml` 承载运行时策略
 - `config/catalogs/*.yaml` 承载可复用对象目录
@@ -776,6 +798,8 @@ await stop(runtime);
 
 - `runtimeRoot`
 - `concurrency.maxConcurrentRequests`
+- `sources.tools`
+- `sources.skills`
 - `routing.defaultAgentId`
 - `routing.rules`
 - `routing.systemPrompt`
@@ -793,7 +817,17 @@ await stop(runtime);
 - `maintenance.checkpoints` 清理后端用于 resume/recovery 的 checkpoint 状态
 - `maintenance.records` 清理 harness 自己保存在 `runtime.sqlite` 中、已结束的 session/request 记录
 
-`toolModuleDiscovery.scope` 用来控制本地 `resources/tools/` 这类 tool module 目录的发现范围：
+`sources.tools` 用来声明哪些 tool root 或 package 参与工作区发现：
+
+- `file://...` 用于目录扫描
+- `npm://...` 用于包入口发现；本地缺失时自动安装
+
+`sources.skills` 用来声明哪些 skill 目录或 skill 文档参与工作区发现：
+
+- `file://...` 用于本地目录、skill root 或直接 `SKILL.md`
+- `http://...` / `https://...` 用于单个远程 `SKILL.md`
+
+`toolModuleDiscovery.scope` 用来控制本地 `resources/tools/` 风格 file source 的发现范围：
 
 - `recursive` 是默认值，会继续扫描嵌套目录
 - `top-level` 只发现每个工具根目录下一层文件，同时保留 YAML catalog 的递归发现
@@ -1110,6 +1144,7 @@ ACP transport 说明：
 - ACP transport 现已覆盖核心参考客户端流程验证：capability discovery、request submit、session lookup、request lookup、invalid JSON 处理、无 id notification 不返回响应，以及 stdio JSON-RPC 与 HTTP + SSE runtime notifications。
 - 现在还额外有一条跨协议一致性回归门：ACP 发起的 request、A2A 读取或继续的 task，以及 runtime MCP 暴露的检查结果，必须始终指向同一组持久化 `sessionId` / `requestId` 运行时记录，不能漂移成各协议各自维护的标识体系。
 - 如果要从最薄的一层 editor / CLI starter 开始，优先用 `agent-harness acp serve --workspace . --transport stdio`，并直接参考 `examples/03_protocol-surfaces/app/acp-stdio/main.mjs` 的 wire shape。需要在应用内使用 reference client 时，可直接用 `createAcpStdioClient(...)` 发起 JSON-RPC 请求并分流 runtime notifications，避免每个 sidecar 自己重写 line parsing。
+- 如果本地 ACP HTTP endpoint 需要在前台 shell 之外持续运行，可使用 `botbotgo acp start --workspace . --host 127.0.0.1 --port 8787`，之后再用 `botbotgo acp stop --workspace .` 停止。CLI 会把受管进程记录到 `.botbotgo/services/` 下，因此本地运维不必再额外引入第二套进程管理器。
 - 对发布后的安装包来说，`botbotgo` 是最短的本地终端入口。它会默认把当前目录当作 workspace，所以团队只需要 `cd` 到自己的 runtime workspace，然后直接运行 `botbotgo` 或 `botbotgo "..."`。`agent-harness` 也保留同样的隐式 chat 行为；如果要从同一个 shell 指向别的 workspace，继续用 `-w/--workspace` 即可。
 - `agent-harness chat --workspace .` 则继续保留为显式子命令形式的本地终端壳：默认 `stdio` 路径会直接在当前进程里连接 workspace runtime，而 `--transport http --host <host> --port <port>` 仍然可以直连已运行的 ACP HTTP endpoint。一次性调用可用 `--message`，交互模式则支持 `/context`、`/new`、`/agent <agentId>`、`/sessions`、`/requests`、`/resume <sessionId>`、`/approvals`、`/approve`、`/reject`、`/cancel`、`/events`、`/trace`、`/health`、`/overview`、`/session`、`/request [requestId]` 与 `/exit`。`/resume` 现在会先校验目标 session，恢复它的 latest request id，并同步 active agent context；`/request <requestId>` 可以把当前上下文切到某个已持久化 request；`/new` 则会在不退出 shell 的情况下清空当前 session/request context。终端 chat 现在统一走一条面向 operator 的输出路径：tool 和进度事件会实时打印，最终完整答复也会继续输出，而不再切到单独的 request-tree-only 模式。
 - 如果是在仓库源码目录里直接运行，请使用 `npm run chat -- --workspace ./config`，或者 `npm run agent-harness -- chat --workspace ./config`。这里额外的 `--` 不能省略，否则 npm 会把 `--workspace` 当成它自己的 workspace 参数。只有在包已经被安装或 `npm link` 到系统环境后，`agent-harness ...` 这个独立命令才会出现在 `PATH` 里。
@@ -1118,8 +1153,9 @@ ACP transport 说明：
 - chat 启动时现在还会对本地 Ollama 路径做一次轻量 preflight。如果当前 endpoint 不可达，或者直接返回 `404 page not found`，shell 会在第一条 prompt 之前先打印这条告警，这样 endpoint 配错的问题会在启动时立即暴露，而不必等第一条消息失败后才知道。
 - 交互式 prompt 现在会同时显示当前 `agent`、`session` 和短 `request` 标识，因此每轮回复之后以及使用 shell 历史记录时，用户都还能清楚地看到自己正处在哪个 runtime turn 上，而不会掉回一个没有上下文的裸输入提示。
 - `serveA2aHttp(runtime)` 提供 A2A HTTP JSON-RPC bridge 与 agent card discovery，同时兼容 `message/send` 这类旧方法，以及 `SendMessage`、`SendStreamingMessage`、`GetTask`、`ListTasks`、`CancelTask`、`SubscribeToTask`、`GetAgentCard`、`GetExtendedAgentCard` 与 task push-notification config 这类 A2A v1.0 方法，并统一映射到现有 session/request 运行记录。bridge 现在会同时声明 `1.0` 与 `0.3` 两个 JSON-RPC interface、在 agent card 路径上响应 `HEAD` / `OPTIONS` discovery、写出支持版本的 discovery headers、可选暴露 registry URL 与 detached signed-card metadata 供外围发现系统使用、校验 `A2A-Version`、把 `A2A-Extensions` 记录进 runtime invocation metadata、发布 `TASK_STATE_*` 状态与 `SendMessage` 的 `{ task }` wrapper、在 v1 streaming 方法上先通过 SSE 输出 `{ task }` 初始快照，再输出 `{ statusUpdate }` 增量状态，并可向已配置的 webhook receiver 发送 best-effort task push notifications。
+- 如果要把本地 A2A bridge 作为受管后台服务运行，可使用 `botbotgo a2a start --workspace . --host 127.0.0.1 --port 8080`，之后再用 `botbotgo a2a stop --workspace .` 停止。它与 ACP 共用 `.botbotgo/services/` 状态目录，因此两个本地协议桥都可以沿用同一套终端优先运维流程。
 - `serveAgUiHttp(runtime)` 提供 AG-UI HTTP SSE bridge，把 runtime 生命周期、安全进度播报、文本输出、upstream thinking、step 进度与 tool call 投影成 `RUN_*`、`STATUS_UPDATE`、`TEXT_MESSAGE_*`、`THINKING_TEXT_MESSAGE_*`、`STEP_*` 与 `TOOL_CALL_*` 事件，便于 UI 客户端直接接入。
-- `createRuntimeMcpServer(runtime)` 与 `serveRuntimeMcpOverStdio(runtime)` 会把持久化 runtime 控制面本身暴露成 MCP tools，包括 sessions、requests、approvals、artifacts、events 与 package export helpers。
+- `createRuntimeMcpServer(runtime)`、`serveRuntimeMcpOverStdio(runtime)` 与 `serveRuntimeMcpOverStreamableHttp(runtime)` 会把持久化 runtime 控制面本身暴露成 MCP tools，包括 sessions、requests、approvals、artifacts、events 与 package export helpers。`botbotgo mcp serve --transport streamable-http --host 127.0.0.1 --port 8090` 会把同一套控制面作为 Streamable HTTP 暴露出去，而 `botbotgo mcp start|stop` 可直接托管该后台 endpoint。
 - `listRequestEvents(...)`、`listRequestTraceItems(...)` 与 `exportRequestPackage(...)` 是 request-first 的检查 helper。
 - `exportRequestPackage(...)` 与 `exportSessionPackage(...)` 可把稳定 runtime 记录、transcript、approvals、events、artifacts 与 governance evidence 一起打包给管理工具，而不必直接访问 persistence 内部实现。
 - `runtime/default.governance.remoteMcp` 现在可以按 MCP server 或 transport 做 allow/deny、审批升级，并把 transport 风险等级写进 runtime governance bundles。MCP server catalog 也可以声明 trust tier、access mode、tenant scope、approval policy、prompt-injection risk 与 OAuth scope 元数据，让治理快照能解释为什么某个远端工具被视为高风险。tool policy override 也可以声明 `decisionMode: manual | auto-approve | auto-reject | deny-and-continue`，让治理快照与实际执行路径保持一致。

package/dist/api.d.ts

@@ -2,9 +2,10 @@ import type { ArtifactListing, CancelOptions, InvocationEnvelope, ListMemoriesIn
 import { AgentHarnessRuntime } from "./runtime/harness.js";
 import type { InventoryAgentRecord, InventorySkillRecord } from "./runtime/harness/system/inventory.js";
 import type { RequirementAssessmentOptions } from "./runtime/harness/system/skill-requirements.js";
-import type { RuntimeMcpServerOptions, ToolMcpServerOptions } from "./mcp.js";
+import type { RuntimeMcpServerOptions, RuntimeMcpStreamableHttpServerOptions, ToolMcpServerOptions } from "./mcp.js";
 export { AgentHarnessAcpServer, createAcpServer } from "./acp.js";
 export { createAcpStdioClient } from "./protocol/acp/client.js";
+export type { RuntimeMcpStreamableHttpServer, RuntimeMcpStreamableHttpServerOptions } from "./mcp.js";
 export type { AcpApproval, AcpArtifact, AcpEventNotification, AcpNotification, AcpJsonRpcError, AcpJsonRpcRequest, AcpJsonRpcResponse, AcpJsonRpcSuccess, AcpRequestRecord, AcpRequestParams, AcpServerCapabilities, AcpSessionRecord, AcpStreamNotification, } from "./acp.js";
 export { AgentHarnessRuntime } from "./runtime/harness.js";
 export { createUpstreamTimelineReducer } from "./upstream-events.js";
@@ -208,3 +209,4 @@ export declare function createToolMcpServer(runtime: AgentHarnessRuntime, option
 export declare function serveToolsOverStdio(runtime: AgentHarnessRuntime, options: ToolMcpServerOptions): Promise<import("@modelcontextprotocol/sdk/server/mcp").McpServer>;
 export declare function createRuntimeMcpServer(runtime: AgentHarnessRuntime, options?: RuntimeMcpServerOptions): Promise<import("@modelcontextprotocol/sdk/server/mcp").McpServer>;
 export declare function serveRuntimeMcpOverStdio(runtime: AgentHarnessRuntime, options?: RuntimeMcpServerOptions): Promise<import("@modelcontextprotocol/sdk/server/mcp").McpServer>;
+export declare function serveRuntimeMcpOverStreamableHttp(runtime: AgentHarnessRuntime, options?: RuntimeMcpStreamableHttpServerOptions): Promise<import("./mcp.js").RuntimeMcpStreamableHttpServer>;

package/dist/api.js

@@ -387,6 +387,9 @@ export async function createRuntimeMcpServer(runtime, options) {
 export async function serveRuntimeMcpOverStdio(runtime, options) {
     return runtime.serveRuntimeMcpOverStdio(options);
 }
+export async function serveRuntimeMcpOverStreamableHttp(runtime, options) {
+    return runtime.serveRuntimeMcpOverStreamableHttp(options);
+}
 function normalizeUserChatMessage(message) {
     if (message.role !== "user") {
         throw new Error("normalizeUserChatInput only accepts user-role chat messages.");

package/dist/cli.d.ts

@@ -8,7 +8,7 @@ import { serveA2aOverHttp } from "./protocol/a2a/http.js";
 import { serveAgUiOverHttp } from "./protocol/ag-ui/http.js";
 import { serveAcpOverHttp } from "./protocol/acp/http.js";
 import { serveAcpOverStdio } from "./protocol/acp/stdio.js";
-import { serveRuntimeMcpOverStdio } from "./mcp.js";
+import { serveRuntimeMcpOverStdio, serveRuntimeMcpOverStreamableHttp } from "./mcp.js";
 type CliIo = {
     cwd?: string;
     stdin?: Readable;
@@ -34,6 +34,17 @@ type CliDeps = {
     serveAcpOverHttp?: typeof serveAcpOverHttp;
     serveAcpOverStdio?: typeof serveAcpOverStdio;
     serveRuntimeMcpOverStdio?: typeof serveRuntimeMcpOverStdio;
+    serveRuntimeMcpOverStreamableHttp?: typeof serveRuntimeMcpOverStreamableHttp;
+    spawnManagedCliProcess?: (input: {
+        args: string[];
+        cwd: string;
+        stdoutPath: string;
+        stderrPath: string;
+    }) => Promise<{
+        pid?: number;
+    }>;
+    isManagedProcessRunning?: (pid: number) => boolean;
+    signalManagedProcess?: (pid: number, signal?: NodeJS.Signals) => void;
 };
 export declare function renderChatPromptLine(input: {
     agentId?: string;