opencode-idea 0.1.2 → 0.1.4

package/README.md

@@ -9,10 +9,10 @@ OpenCode 插件,面向 JetBrains 项目 (IntelliJ IDEA / PyCharm / WebStorm 等)
 2. **优先使用 IDE 工具** —— IDE 可用时,向模型注入 **逐项目**的引导:在哪个项目里工作,就用哪个项目前缀的工具;IDE 不可用时
    回退原生工具 (正常回退,无需声明)。
 
-> **需要项目环境的命令走 Run Configuration**:跑 `java` / `python` / `npm` 这类依赖项目配好的 JDK / Node / Python 版本的
-> 命令时,引导模型用 `ide_execute_run_configuration`(配置 **由用户**先在 IDE 里建好),而不是原生 shell;不需要项目
-> 环境的命令照常走原生 shell。 **IDE 内置终端 (`ide_execute_terminal_command`) 已被隐藏** —— 实测它并不继承项目环境,
-> 对原生 shell 没有任何优势。详见「Run Configuration 全套」。
+> **需要项目环境的命令走 IDE 终端 / Run Configuration**:跑 `java` / `python` / `npm` 这类依赖项目配好的 JDK / Node / Python 版本的
+> **一次性命令**,用配套插件提供的 `ide_project_sdk_terminal`(它带项目 SDK 环境);**反复发生的流程**仍固化成 Run Configuration。
+> **IDE 内置的 `ide_execute_terminal_command` 继续隐藏** —— 实测它不继承项目环境,已被 `project_sdk_terminal` 取代。
+> 详见「Run Configuration 全套」与「终端全套」。
 
 非 JetBrains 项目完全不受影响。 **手动接入**:插件启动不探测、不连接任何 IDE。三个命令管全部:
 
@@ -142,15 +142,18 @@ IDE MCP 可用时,插件通过 **系统提示注入**告诉模型 **哪些事该
 (只做减法:从 schema 里删掉一个参数),不修改任何工具 (原生或 IDEA) 的定义、描述或可用性:
 
 1. **系统提示注入**:通过 `ctx.session.hook("context", …)` 往每次请求的 system 里追加一段引导。
-   **文本本身在 `src/ide-guidance.template.md`** —— 它是一份要给人 review 的提示词文档,条件直接用 `{{#if …}}`
-   写在那几行外面,所以打开模板就能看到最终渲染成什么样;`src/template.js` 是渲染器(支持 `{{var}}` / `{{#if}}` /
-   `{{else}}`,**不做 HTML 转义** —— 输出是 Markdown,`<jar>!/<entry>` 和反引号必须原样过)。
+   **文本本身在 `src/ide-guidance.template.md`** —— 它是一份要给人 review 的提示词文档,纯 Markdown,只有每条工具后面的
+   命令名(`{{cmd_xxx}}`)由代码填;`src/template.js` 是渲染器(支持 `{{var}}`,`{{#if}}` 仍在实现里但引导模板不再使用;
+   **不做 HTML 转义** —— 输出是 Markdown,`<jar>!/<entry>` 和反引号必须原样过)。
    含工具名(`<项目前缀>_<name>`;root 是 `ide_*`,子项目是 `<目录名>_*`)与关键参数名。
 
+   > **配套插件 `idea-mcp-enhance` 是硬前提**:引导默认它一定装了,所以配套插件的工具 (运行配置启停 / 部署 / 终端)
+   > **不做"有没有装 / 有没有这个工具"的判断**,直接写进引导。
+
    **路由总纲** —— 整个引导的第一条,按「路径在不在项目里」分路:
 
    - **项目内** —— **OpenCode 自带的工具为主**,它们更快。**它们做不了、或者做得很差的,才用 IDE 工具**:
-     符号检索、依赖实现、重构、格式化、校验、运行配置、跨文件补丁。
+     符号检索、依赖实现、重构、格式化、校验、运行配置、项目终端、跨文件补丁。
      **两边都不顺手时,你自己判断用 `shell` 里的命令** —— 那是**第三选择,不是第一选择**。
    - **项目外** —— **只有 OpenCode 自带的工具**,IDE 工具不参与。这不是保守,是硬事实:**请求的路径必须落在某个
      已打开项目的目录树内,IDE 才会去解析它**;项目外的路径(`/tmp`、别的仓库、用户主目录)两个 IDE 都会直接报错。
@@ -165,7 +168,8 @@ IDE MCP 可用时,插件通过 **系统提示注入**告诉模型 **哪些事该
    | 批量改文件 | `ide_apply_patch` |
    | 校验 | `ide_lint_files` / `ide_get_file_problems` / `ide_build_project` |
    | 运行配置 | `ide_get_run_configurations` / `ide_execute_run_configuration`(+ 配套插件的启停工具) |
-   | 部署 | `ide_list_deployment_servers` / `ide_upload_to_deployment` / `ide_download_from_deployment` / `ide_get_deployment_task_status`(**仅配套插件 + Ultimate**) |
+   | 终端 | `ide_project_sdk_terminal` / `ide_terminal_read` / `ide_terminal_interrupt` / `ide_list_terminals` / `ide_execute_in_remote_host`(远程执行还要求 Ultimate + Deployment SFTP) |
+   | 部署 | `ide_list_server_deployments` / `ide_upload_to_deployment` / `ide_download_from_deployment` / `ide_get_deployment_task_status`(要求 Ultimate) |
 
    **读、找文本、找文件、改单个文件一律用 OpenCode 自带的工具**(`read` / `grep` / `glob` / `write` / `edit`):
    这几件事走 IDE 只是多一跳,所以映射表里**不出现** `ide_search_text` / `ide_search_regex` / `ide_search_file`。
@@ -263,7 +267,7 @@ IDE MCP 可用时,插件通过 **系统提示注入**告诉模型 **哪些事该
 ## Run Configuration 全套 (配套插件 `idea-mcp-enhance`)
 
 IDE 内置的 MCP Server 只能 **启动已有**的 run configuration (`execute_run_configuration`), **不能新建、不能停止、不能重启、
-也查不到运行状态**。配套的 IDEA 插件 [`idea-mcp-enhance`](https://github.com/syllr/idea-mcp-enhance)(IDEA 2026.2+,另装)
+也查不到运行状态**。配套的 IDEA 插件 [`idea-mcp-enhance`](https://github.com/syllr/idea-mcp-enhance)(IDEA 2026.2+,必须安装)
 补齐这一族 —— 「定义态 (查 / 建 / 改 / 删)」加「运行态 (看 / 停 / 重启)」:
 
 | 工具 (OpenCode 里叫 `ide_*`)      | 作用                                                                                                                                                                                                             |
@@ -276,34 +280,31 @@ IDE 内置的 MCP Server 只能 **启动已有**的 run configuration (`execute_
 | `ide_stop_run_configuration`      | 停掉该配置的**全部**实例并等它们退出;没在跑也返回成功(幂等)                                                                                                                                                      |
 | `ide_rerun_run_configuration`     | 等同 IDE 的 **Rerun** 按钮:在跑就重启、没在跑就启动,读 `started` 判断是否真起来了                                                                                                                                |
 
-**需要项目环境的命令走 run configuration,不用原生 shell** —— 判据是这条命令 **依赖项目的运行时版本**
-(IDE 里配好的 JDK / Node / Python 等)。是 → run configuration;不是 (看文件、git、临时脚本)→ 原生 shell。
-run configuration 会继承开发时具体配的那套运行时,所以它就是个应用;配置必须 **先在 IDEA 里存在**(由用户建),
-没有就请用户建一个再跑。
+**需要项目环境的命令走 IDE 终端 / run configuration** —— 判据是这条命令 **依赖项目的运行时版本**
+(IDE 里配好的 JDK / Node / Python 等)。是 → **一次性命令**走配套插件的 `ide_project_sdk_terminal`;**会反复发生的流程 / 常驻
+服务**固化成 run configuration;不是 (看文件、git、临时脚本)→ 原生 shell。配置必须 **先在 IDEA 里存在**(由用户建),
+没有就请用户建一个再跑;要不要建、建什么,按 `idea-run-config-manager` skill 的判据走。
 
-> **为什么不再用 IDE 终端**:`ide_execute_terminal_command` 之前被当成"自动继承 IDE 项目环境"的通道而保留暴露,但实测
+> **为什么内置 IDE 终端仍然隐藏**:`ide_execute_terminal_command` 之前被当成"自动继承 IDE 项目环境"的通道而保留暴露,但实测
 > **它拿不到项目配好的 JDK / Node / Python 版本**,和原生 shell 没有区别。既然没有优势,就把它从模型可见的工具表里
-> 隐藏掉 (`HIDDEN_IDE_TOOL_SUFFIXES`),命令执行的路由改由 run configuration 承担。
+> 隐藏掉 (`HIDDEN_IDE_TOOL_SUFFIXES`)。配套插件的 `project_sdk_terminal` 走的是另一条路:**主动把项目 SDK / Maven /
+> Node / Python 的路径注入终端环境**,所以它才是"需要项目环境"的那条路由。
 
 配置名有自己的文法:**`[os@]base[@env]`** —— os 段 (`win` = Windows,缺省 = macOS / Linux)、base 段 (配置本体)、env 段 (环境名,
 缺省 = 默认环境 —— 起一批时逐条解析:有 `@<env>` 用它,没有就用默认)。`win@base` 与 `base@env` 都是同一个 base 的 **变体**,档案里只登记 base。解析 **交给工具**:
 `ide_inspect_run_configuration` 的 `naming` 字段把名字拆成 platform / base / env,规则是从两头往中间收 (末段是环境;首段只有
 恰好是 `win` 才算平台,不是就并进 base),所以 `a@b@c` 会解析成 base=`a@b`、env=`c`,不会丢段。
 
-opencode-idea 对这一组工具做三件事:
+opencode-idea 对这一组工具做两件事:
 
 1. **透传**:IDE MCP server 以 `codemode: false` 注册,工具目录整体转发,所以这七个工具自动以 `ide_*` 出现在模型的
-   工具表里 —— 插件侧不需要单独声明 (也因此 **装不装这个 IDEA 插件,插件侧的代码都不用改**);
-2. **条件引导**:只有这次请求的工具快照里真的有它们,才在「运行配置」节里逐个点名。**没装插件时整节连同标题一起消失**,
-   引导不会提到一个调不到的工具。其中一条值得单独说:**启动 / 重启常驻进程就用 `ide_rerun_run_configuration`,
-   不要用 `pkill` / `kill` / shell** —— 这正是它要解决的问题:外部杀掉的进程 IDE 并不知道,Run 窗口仍显示运行中,
-   下次启动就会撞端口;
-3. **工具名清单**写在 `src/mcp/enhance.js`(与原生 IDE 的 `src/mcp/idea.js` 分开放:原生走原生,插件的走插件的),
-   与该仓库的 `RunLifecycleSchemas.kt` 保持同步。工具按 **存在的子集**逐个点名 (而不是「有就全写」),这样旧版本的配套
-   插件少给一两个工具时,引导也不会提到它们。同理, **每条命令名只列真的提供它的项目**(逐项目核对,见「条件注入」)——
-   一个项目装了配套插件、另一个没装是可能的。
-
-> 没装 `idea-mcp-enhance` 的 IDE 一切照旧:工具不存在,引导也不提,模型继续按原来的方式工作。
+   工具表里 —— 插件侧不需要单独声明,也不需要判断它们在不在;
+2. **无条件引导**:这七个工具**默认都在**(配套插件是硬前提),「运行配置」节直接逐个点名。其中一条值得单独说:
+   **启动 / 重启常驻进程就用 `ide_rerun_run_configuration`,不要用 `pkill` / `kill` / shell** —— 这正是它要解决的问题:
+   外部杀掉的进程 IDE 并不知道,Run 窗口仍显示运行中,下次启动就会撞端口。
+
+> **前提**:配套插件 `idea-mcp-enhance` 必须装在每个接入的 IDE 上。没装时引导仍会点名这些工具、调用会失败 —— 这是
+> 刻意选择的硬前提,不做兼容判断。
 
 ## Run Configuration:文件由工具写,档案由 skill 写
 
@@ -407,39 +408,85 @@ opencode-idea 对这一组工具做三件事:
 ## Deployment 全套 (配套插件 `idea-mcp-enhance`)
 
 IDE 内置的 MCP Server **完全不碰部署** —— 既不报 IDE 里配了哪些 Deployment 服务器,也不能把文件传上去 / 拉下来。
-配套插件 [`idea-mcp-enhance`](https://github.com/syllr/idea-mcp-enhance)(IDEA 2026.2+,另装)补齐这四个:
+配套插件 [`idea-mcp-enhance`](https://github.com/syllr/idea-mcp-enhance)(IDEA 2026.2+,必须安装)补齐这四个:
 
 | 工具 (OpenCode 里叫 `ide_*`)     | 作用                                                                                                                                                       |
 | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `ide_list_deployment_servers`    | 本项目可用的服务器(名称 / 项目级还是应用级 / 协议 / host / port / **本项目里的路径映射**),以及**项目级**的部署选项与危险组合告警。**只读 IDE 配置,不联网** |
-| `ide_upload_to_deployment`       | 把映射到的**本地目录**传到服务器(等同 IDE 的 Upload to …)。`mode` 默认 `mirror` —— **会删掉服务器上多出来的文件**;`upload` 则保留远端多余文件。**破坏性**  |
-| `ide_download_from_deployment`   | 把服务器上映射目录的内容拉回本地(等同 IDE 的 Download from …),**以服务器为准**:两边都有的文件被远端覆盖(相同则不写)。**没有"保留我的版本"这个选项**        |
+| `ide_list_server_deployments`    | 本项目可用的**服务器**,以及每台服务器上的 **deployment(路径映射)**。Server 是连接目标(`servers[].name` → 远程终端的 `serverName`),deployment 是挂在它上面的一条映射(`servers[].deployments[].name` → 上传 / 下载的 `deploymentName`,全局唯一)。server 可以 0 个 deployment,那样只能远程执行。另带 `level` / `accessType` / `host` / `port` / `rootFolder` / `hasCredentials` / `validationIssue` / `isDefault`、项目级 `options` 与 `warnings[]`。**只读 IDE 配置,不联网** |
+| `ide_upload_to_deployment`       | 把**一条 deployment**(本地映射目录)传到服务器(等同 IDE 的 Upload to …)。`deploymentName` 传 `servers[].deployments[].name`,**不是 `serverName`**。`mode` 默认 `mirror` —— **会删掉服务器上多出来的文件**;`upload` 则保留远端多余文件。**破坏性** |
+| `ide_download_from_deployment`   | 把**一条 deployment** 从服务器拉回本地(等同 IDE 的 Download from …),**以服务器为准**:两边都有的文件被远端覆盖(相同则不写)。同样传 `deploymentName`。**没有"保留我的版本"这个选项** |
 | `ide_get_deployment_task_status` | 用 `handle` 查一次传输的状态与计数;**永不启动任何传输**                                                                                                    |
 
-opencode-idea 对它做的是**同一套三件事**(透传 / 条件引导 / 工具名清单),差异只有两处:
+opencode-idea 对它做的是**同一套两件事**(透传 / 无条件引导),不再按工具快照裁剪文本:
 
-- **条件引导更严** —— 部署工具除了配套插件,还要求 `com.jetbrains.plugins.webDeployment`,而它只在 **Ultimate** 里存在,
-  所以 Community IDE 上这一节永远不出现。而且 **这一节整节 (含标题) 都由配套插件提供**,一个工具都没有时它 **完全消失**
-  —— 不能像「运行配置」那样留一个空标题 (那一节还有内置的 `get_run_configurations` / `execute_run_configuration` 撑着)。
-  整节**锚在一个工具上**(模板里 `{{#if canListDeploymentServers}}` 直接包住标题):这四个由同一道前提注册、同进同出,
-  拿其中一个当判据就够,不需要再造一个"四个里任一个"的聚合标志;
-- **工具名清单**在 `src/mcp/enhance.js` 的 `DEPLOYMENT_SUFFIXES` + `deploymentCapabilities`,与该仓库的
-  `DeploymentSchemas.kt` 保持同步。
+- **前提**:部署工具除配套插件外,还要求 `com.jetbrains.plugins.webDeployment`(**仅 Ultimate**)。引导默认它在,
+  所以「服务器文件同步」节始终出现;Community 上调用这些工具会失败 —— 这属于配套环境没装全,不做兼容判断;
+- **契约**:`DeploymentSchemas.kt` 就是这组工具的对外形状(参数名、返回字段),引导按它写,不再单独维护工具名清单。
 
-这节存在的理由是 **一条路由规则**:往服务器传 / 取文件要走这些工具, **不要自己拼 `ssh` / `rsync` / `scp`** ——
-IDE 的连接、路径映射、排除规则都在它后面,自己拼的那份与 IDE 看到、管理的不是同一份。文案里同时点明两件容易读错的事:
+这节存在的理由是 **一条路由规则**:往服务器传 / 取文件要走这些工具 —— IDE 的连接、路径映射、排除规则都在它后面,
+手工拼的那份与 IDE 看到、管理的不是同一份。文案里同时点明两件容易读错的事:
 `mirror` 是 **默认值**且 **会删远端文件**(而 MCP 路径上没有确认步骤),下载 **以远端为准**、没有"保留我的版本"。
 
-还有一个语义必须写明,否则模型会把正常的中间态当失败去重试:上传 / 下载都在 IDE 后台跑,单次调用只等到 `waitMs`
-(默认 10 秒)为止,返回 `state: "in_progress"` 是 **正常**的 —— 拿 `handle` 调 `get_deployment_task_status` 接着看,
-**不要用重复调上传 / 下载来代替**(那样拿不到进度)。
+**同步只是上半段**:每条 deployment 都属于某台 Server,传完之后在那台 Server 上启动刚传上去的二进制、重启服务、看日志,
+走 `execute_in_remote_host`(`serverName` 用服务器名,不是 deployment 名)。**这两步都不要用 `scp` / `rsync` / `ssh`
+手工顶替** —— 手工那条路既没有 IDE 的路径映射,也常常根本没有权限(实测过一次:模型拿到服务器名之后转去读
+`~/.ssh/config`、逐个试用户名,失败后回头找用户要密码,而 `execute_in_remote_host` 一直都在工具表里)。
+
+还有一个语义必须写明,否则模型会把正常的中间态当失败去重试:上传 / 下载默认**同步等结果**,传完立刻返回
+`state: "completed"`;只有超过 300 秒等待窗口还没传完,才返回 `state: "in_progress"` + `handle`,这是 **正常**的
+(它也可能以 **error 结果**回来)—— 拿 `handle` 调 `get_deployment_task_status` 接着看,**不要用重复调上传 / 下载
+来代替**(那样会再起一次传输)。`completed` 之后 `counters` 才可信,而且数的是**操作次数**,不是文件数
+(删掉整个目录也只算 1)。
 
 > **这一组没有 skill,和 run configuration 不同。** run configuration 要 skill 是因为"某种类型怎么写"是一批得逐类型实测的
-> 模板 (`assets/types/`);部署没有这层知识 —— 四个工具的 schema 已经说清 `serverName` / `mode` 怎么填,而"该不该传、传给谁"
-> 是模型当场看 `list_deployment_servers` 的判断。再加一个 skill 只是把同一段话抄第二遍。
+> 模板 (`assets/types/`);部署没有这层知识 —— 四个工具的 schema 已经说清 `serverName` / `deploymentName` / `mode` 怎么填,
+> 而"该不该传、传给谁"是模型当场看 `list_server_deployments` 的判断。再加一个 skill 只是把同一段话抄第二遍。
+
+## 终端全套 (配套插件 `idea-mcp-enhance`)
+
+IDE 内置的 `execute_terminal_command` **不继承项目环境**(实测拿不到项目配好的 JDK / Node / Python),所以它被隐藏。配套插件
+补上的是一个**真正的 IDE 终端**,外加远程 SSH 终端和一套"接着用同一个 tab"的读写工具:
+
+| 工具 (OpenCode 里叫 `ide_*`) | 作用 |
+| --- | --- |
+| `ide_project_sdk_terminal` | 在本项目 SDK 终端里跑**一条**命令,返回输出 + `tab`。**默认复用**本项目的默认 tab(第一次调用创建,`list_terminals` 该组的 `default` 就是它);传 `tab` 指定、传 `newTab: true` 新开(不抢默认)、带 `env` 时强制新开(`env` 只在 shell 启动时生效)。命令跑得久时先返回 `running: true`(同一个 `tab`,命令继续跑),之后用 `ide_terminal_read` 接着看。终端环境由插件注入:项目 JDK(`PATH`)、Maven home、Node runtime / 包管理器、Go 的 `GOROOT` / `GOPATH` / `GOBIN`、Python SDK / venv(`PATH` + `VIRTUAL_ENV`),用户传的 `env` 最后覆盖 |
+| `ide_list_terminals` | 按来源分组列出 MCP tab:`mcp_project_sdk` 一组、每台远程服务器各一组;每组带一个组级 `default`(该来源的默认 tab)和组内 `tabs` 数组。用户手开的 tab 不出现 |
+| `ide_terminal_read` | 读已有 tab,**立即返回、不等待**:默认读上次之后的增量,`tail: N` 读最近 N 个命令段(本地带每段 `exitCode`),`full: true` 读整屏,`running` 表示命令还在不在跑 |
+| `ide_terminal_interrupt` | 往已有 tab 发**一次 Ctrl-C**。只在命令卡住时用 —— 执行工具会等 shell 空闲,卡住的命令会把它们一直挡住;它不接受任何文本,只能打断,不能拿来跑命令 |
+| `ide_execute_in_remote_host` | 通过本项目的一台 Deployment **SFTP** 服务器开真实 SSH 终端。`serverName` 取 `servers[].name`。**默认复用这台服务器的默认 tab**(第一次调用创建,`list_terminals` 该组的 `default` 就是它),传 `tab` 指定 / `newTab: true` 换干净 shell;新 tab 命名 `mcp-<服务器名>-<序号>`(如 `mcp-mbpmiddleware-1`)。`loginShell` 默认 `true`(套 `zsh -lic` / `bash -lc`),`strictHostKey` 默认 `false`(accept-new) |
+
+路由:引导里写的是 **"这条命令在哪台机器上、要不要项目运行时"** 两刀切 —— 远程机器(部署机 / 开发机 / 用户点名的主机)
+走 `ide_execute_in_remote_host`(服务器名不确定先 `ide_list_server_deployments`);本机 + 要运行时(IDE 里配好的
+JDK / Node / Python / Maven / Go)走 `ide_project_sdk_terminal`;本机 + 不要运行时(`git` / `ls` / `curl` / `docker` /
+`ps`)仍走原生 `shell`。**常驻进程**(dev server / watch)有 run configuration 就用它;没有就用终端起在 tab 里,
+跑满等待窗口还没结束会返回 `running: true`,之后用 `ide_terminal_read` 跟日志。
+
+**等太久会转成异步**:命令跑得久,这次调用先返回 `running: true` + 同一个 tab,命令继续跑;之后用 `ide_terminal_read`
+每隔几秒看一眼进度,直到 `running` 变 false —— 不要因为没拿到结果就重跑一遍。超时不是调用方能设的参数,它是工具自身的
+行为(也没有"主动异步"选项)。引导里也明写了**禁止用 `shell` 的 `sleep` 干等**(实测会话里出现过 `sleep 60` /
+`sleep 120` / `sleep 1500`,全是旧版 12 秒上限逼出来的)。
+
+**终端默认复用**:同一台机器上的连续命令落在同一个 tab —— `cd` / `export` / 后台进程都还在,不必每条重贴 `cd ... &&`,
+也不用自己记 tab 号;要干净 shell 传 `newTab: true`,要指定某条传 `tab`。`ide_terminal_read` / `ide_terminal_interrupt`
+管的是"接着看 / 打断",不是"再跑一条"的替代。这条规则在「命令执行」和「终端」两处都写了,因为它最容易被绕成"每条命令一个 tab"。
+
+三条容易读错的语义,引导里都点名了:
+
+- **每种来源一条默认 tab** —— 本地一条、每台服务器各一条,第一次调用自动创建,`list_terminals` 在该组的 `default` 字段里报出它;
+  不传 `tab` 就永远落在它上面(不会随使用历史漂移),默认 tab 被关掉后下次调用重建一条;一条命令要独立环境就传
+  `newTab: true` / `env`。跨服务器复用会被直接拒绝(`tab_server_mismatch`);
+- **远程没有"命令结束"信号** —— `exitCode` 永远 `null`,`running` 也可能 `null`;别等退出码,按输出判断或继续 `ide_terminal_read` 读;
+- **tab 只在这次 IDE 会话里有效** —— 关掉就失效(报 `terminal_closed` / 找不到),这时才重开一个;没有"关闭 tab"的工具,
+  用完不必主动关,用户可以直接在 IDE 里接手。
+
+opencode-idea 对它做的仍是**同一套两件事**(透传 / 无条件引导):本地三个工具(Terminal 插件在就有)和
+`execute_in_remote_host`(还要 `remote-run`,仅 Ultimate)都**默认齐全**,引导直接点名,不再按工具快照裁剪。
+契约以该仓库的 `TerminalSchemas.kt` 为准。
 
 ## 前置条件
 
+- **必须安装配套插件 [`idea-mcp-enhance`](https://github.com/syllr/idea-mcp-enhance)(IDEA 2026.2+)**。引导默认它的工具都在
+  (运行配置启停 / 部署 / 终端),**不做"装没装 / 有没有这个工具"的判断**;部署与远程终端还要求 Ultimate。
 - JetBrains IDE 已开启 MCP 服务 (IDE 设置里的 MCP Server / AI Assistant MCP),版本需 **2026.2+**(提供 Streamable HTTP 端点
   `/stream`);若关闭,`/open-in-ide` 会立即提示如何重新开启。
 - IDE 侧需开启 **Brave Mode**(否则需要确认的 MCP 工具调用会停下来等用户确认);MCP 未就绪时通知会同时提醒开启它。
@@ -573,7 +620,8 @@ export { default } from "/Users/yutao/IdeaProjects/opencode-idea/src/index.js";
   (0.0.6 就是这样丢了 `/open-in-ide`)。完整字段是 `id` / `name` / `description?` / `autoinvoke?` / `path` / `content`。
 - 一批用不到的 IDE MCP 工具被硬编码隐藏(`src/plugin.js` 的 `HIDDEN_IDE_TOOL_SUFFIXES`,**共 48 个后缀**):
   VCS(`git_status` / `get_repositories`)、Router 派发工具(`execute_tool`)、Debugger(全部 `xdebug_*`)、Dev Kit MCP、
-  Inspection KTS MCP、解释器环境 MCP、**IDE 内置终端**(`execute_terminal_command`:实测不继承项目环境)、
+  Inspection KTS MCP、解释器环境 MCP、**IDE 内置终端**(`execute_terminal_command`:实测不继承项目环境,已由配套插件的
+  `project_sdk_terminal` 取代)、
   **整个 Database 组**(数据源由用户在 IDE 里配置)、**有原生对应的文件搜索**(`search_text` / `search_regex` / `search_file`)、
   以及**建文件**(`create_new_file`)。配套插件自带的那个写文件工具同样隐藏。**`apply_patch` 不在隐藏列表里**。
   存的是**后缀**,清洗时按当前每个项目前缀**各删一遍** —— 只处理 `ide_` 会让子项目那几份原样送到模型面前。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-idea",
-  "version": "0.1.2",
+  "version": "0.1.4",
   "description": "OpenCode plugin that connects to JetBrains IDE MCP servers and prefers IDE tools when the current project is open in the IDE",
   "main": "src/index.js",
   "type": "module",
@@ -12,7 +12,6 @@
     "src/ide-guidance.template.md",
     "src/ide-projects.js",
     "src/mcp/idea.js",
-    "src/mcp/enhance.js",
     "src/mcp/idea-tool-defaults.js",
     "src/mcp/idea-tool-output.js",
     "src/project.js",

package/skills/idea-run-config-manager/assets/AGENTS.template.md

@@ -56,7 +56,8 @@ base,变体不另起条目**:`{配置名}` 不带任何 `@` 段 —— 名字文
     - run:ide_execute_run_configuration
     - after run:
         - 产物 `middleware/seatunnel/connectors/connector-fileparse-<ST 版本>.jar`(78M,已 gitignore)
-        - 接着同步到部署机:`ide_upload_to_deployment`,`serverName` 传 `mbpmiddleware`、`mode` 传 `upload`(默认 `mirror`
+        - 接着同步到部署机:`ide_upload_to_deployment`,`deploymentName` 传 `list_server_deployments` 里这条映射的名字
+          (本地映射目录的最后一段,如 `.../mbpmiddleware` → `mbpmiddleware`)、`mode` 传 `upload`(默认 `mirror`
           会删远端多余文件,别用);`in_progress` 就按 handle 轮 `ide_get_deployment_task_status`
         - 同步完在部署机上 `docker compose restart seatunnel`
     - desc:

package/src/ide-guidance.js

@@ -1,8 +1,8 @@
 // IDE MCP routing guidance injected into the model's system prompt.
 //
 // The TEXT lives in `ide-guidance.template.md`, not here. It is a prompt document
-// a human has to review as a document — with the conditionals visible as
-// `{{#if …}}` around the lines they control — and building it by concatenating
+// a human has to review as a document — plain Markdown, with only the per-project
+// command lists (`{{cmd_xxx}}`) generated — and building it by concatenating
 // arrays made the result impossible to read without running the code. The
 // template renders byte-for-byte to what the model receives; see `src/template.js`
 // for why the renderer is 60 lines here rather than an engine dependency.
@@ -55,24 +55,18 @@
 // 这样模型同时拿到"这条功能是什么"和"这个项目里它叫什么",不需要自己拼前缀 —— 少一层
 // 推理,就少一类"拿错项目工具"的失败;而且文本不会随项目数成倍增长。
 //
-// The `{{#if can…}}` blocks gate the companion plugin's tools (`mcp/enhance.js`),
-// which only exist when the user installed it. Nothing in the document says so:
-// which plugin a tool came from is this plugin's plumbing, not the model's
-// business — it either sees the tool or it does not. The deployment section is
-// gated on ONE of those flags (`canListDeploymentServers`) rather than on a flag of
-// its own: the four tools are registered together, so one of them answers for the
-// section — heading included, which is why the gate wraps the `###` line too.
+// The guidance describes the companion plugin's tools (`idea-mcp-enhance`)
+// unconditionally: that plugin is a hard prerequisite, not an optional extra, so
+// there is nothing to detect here. A tool named in the guidance is expected to be
+// in the request; if it is not, the installation is wrong, and hiding the text
+// would only make that harder to notice.
+//
+// The template is therefore plain Markdown with no `{{#if …}}` blocks at all —
+// only the per-project command lists (`{{cmd_xxx}}`) are generated.
 
 import { readFileSync } from 'node:fs';
 
 import { IDE_LABELS } from './ide-projects.js';
-import {
-  DEPLOYMENT_SUFFIXES,
-  RUN_LIFECYCLE_SUFFIXES,
-  deploymentCapabilities,
-  runLifecycleCapabilities,
-  servesTool,
-} from './mcp/enhance.js';
 import { renderTemplate } from './template.js';
 
 /** The prompt document, next to this module so it ships with it. */
@@ -81,17 +75,6 @@ const TEMPLATE_PATH = new URL('ide-guidance.template.md', import.meta.url);
 /** Read once: the file is fixed for the life of the process, and this runs per request. */
 const TEMPLATE = readFileSync(TEMPLATE_PATH, 'utf8');
 
-/**
- * 配套插件那两组工具的后缀全集 —— 判据只有一条:**这张表里的工具按项目分别存在**。
- *
- * 表外(内置 MCP Server 自带的那批)是每个项目都有的,列命令名时不需要看快照;表内的必须
- * 逐项目核对(见 {@link commandVariables})。两组都收进来而不是只收部署那组:它们的
- * 存在性本来就按项目、按 IDE 不同 —— 启停工具取决于装没装配套插件,部署工具还多一道
- * "是不是 Ultimate"。把 run-lifecycle 留在表外,等于默认"一个项目装了、别的项目也装了",
- * 而那只是个默认,不是事实。
- */
-const ENHANCE_SUFFIXES = new Set([...RUN_LIFECYCLE_SUFFIXES, ...DEPLOYMENT_SUFFIXES]);
-
 /**
  * 「本会话有哪些项目、各自用哪个 MCP 工具前缀」的清单。
  *
@@ -125,80 +108,26 @@ function routeTableFor(projects) {
  * `` `根项目 ide_search_symbol` ｜ `modelserver modelserver_search_symbol` ``。
  * 所以模板增删一条工具不需要动这里的代码，也不会出现"模板里写了、代码忘了给值"的空行。
  *
- * **配套插件那条线要逐项目过滤**（见 {@link ENHANCE_SUFFIXES}）：内置工具每个项目都有,列全即可;
- * 而 `idea-mcp-enhance` 的工具是**按项目分别存在**的(装了插件的那个 IDE 有,另一个可能没有;
- * 部署那组还要求 Ultimate)。它常常同进同出,但"通常"不是"总是" —— 一旦不一致,列全就会在
- * 缺工具的那个项目下点名一个模型调不到的命令,而那正是这整个模块要防的失败。
- * 过滤不会产生空行:每条 bullet 的 `{{#if}}` 用的是**并集**判断(任一项目有即渲染),
- * 并集为真 ⇒ 至少一个项目通过过滤。
+ * 每个项目都列:配套插件是硬前提,每个接入的 IDE 都装了它,所以不需要再按工具快照逐项目
+ * 过滤"这个项目有没有这个工具"。
  *
  * @param {ReadonlyArray<{ label: string, server: string, isRoot: boolean }>} projects
- * @param {Record<string, unknown> | undefined} tools 本次请求的工具快照
  */
-function commandVariables(projects, tools) {
+function commandVariables(projects) {
   /** @type {Record<string, string>} */
   const variables = {};
   for (const match of TEMPLATE.matchAll(/\{\{\s*(cmd_[A-Za-z0-9_]+)\s*\}\}/g)) {
     const name = match[1];
     const suffix = name.slice('cmd_'.length);
+    // 每条都写清"哪个项目 → 哪个命令"：根项目直接用它的角色名,子项目用目录名。
+    // 不写 `.`/目录名这种需要回看清单才能解读的代号 —— 模型读每条功能时不必回头查表。
     variables[name] = projects
-      .filter((project) => !ENHANCE_SUFFIXES.has(suffix) || servesTool(tools, `${project.server}_`, suffix))
-      // 每条都写清"哪个项目 → 哪个命令"：根项目直接用它的角色名,子项目用目录名。
-      // 不写 `.`/目录名这种需要回看清单才能解读的代号 —— 模型读每条功能时不必回头查表。
       .map((project) => `${project.isRoot ? '根项目' : project.label} \`${project.server}_${suffix}\``)
       .join(' ｜ ');
   }
   return variables;
 }
 
-/**
- * 本会话里这些 run-lifecycle 能力可不可用。
- *
- * 提示词只有一份，所以这里要回答的是"这套能力在本次会话里存不存在" —— 任一项目提供即算存在。
- * 同一个人的几个 IDE 装不装配套插件通常是一致的；万一不一致，模板里那句"没装就交给用户"兜住。
- *
- * @param {ReadonlyArray<{ server: string }>} projects
- * @param {Record<string, unknown> | undefined} tools
- */
-function mergeRunLifecycle(projects, tools) {
-  const all = projects.map((project) => runLifecycleCapabilities(tools, `${project.server}_`));
-  return {
-    canCreateRunConfiguration: all.some((c) => c.canCreateRunConfiguration),
-    canInspectRunConfiguration: all.some((c) => c.canInspectRunConfiguration),
-    canUpdateRunConfiguration: all.some((c) => c.canUpdateRunConfiguration),
-    canDeleteRunConfiguration: all.some((c) => c.canDeleteRunConfiguration),
-    canListRunningConfigurations: all.some((c) => c.canListRunningConfigurations),
-    canStopRunConfiguration: all.some((c) => c.canStopRunConfiguration),
-    canRerunRunConfiguration: all.some((c) => c.canRerunRunConfiguration),
-  };
-}
-
-/**
- * 部署工具同理(见 `mergeRunLifecycle`):逐项目判断,任一项目提供即算存在。
- *
- * **整节的锚点就是 `canListDeploymentServers`**(模板里 `{{#if canListDeploymentServers}}` 直接包住标题):
- * 配套插件只要装了,IDE 的 MCP 工具表里就多出这一组(它们由同一道前提注册,同进同出),
- * 所以拿其中一个当判据就够了 —— 不需要再造一个"四个里任一个"的聚合标志。
- *
- * 不锚在那些"必须有工具才算"的地方也不成问题:一个都没有时 `canListDeploymentServers` 为 false,
- * 标题与正文一起消失;而这一节和前一组不同 —— run-lifecycle 那节是内置工具
- * (`get_run_configurations` / `execute_run_configuration`)撑起来的**自己的**标题,缺配套插件时标题仍在。
- * 顺带一提,这一组还额外要求 `com.jetbrains.plugins.webDeployment`(**仅 Ultimate 有**),所以
- * "整节不出现"是常态而非边角。
- *
- * @param {ReadonlyArray<{ server: string }>} projects
- * @param {Record<string, unknown> | undefined} tools
- */
-function mergeDeployment(projects, tools) {
-  const all = projects.map((project) => deploymentCapabilities(tools, `${project.server}_`));
-  return {
-    canListDeploymentServers: all.some((c) => c.canListDeploymentServers),
-    canUploadToDeployment: all.some((c) => c.canUploadToDeployment),
-    canDownloadFromDeployment: all.some((c) => c.canDownloadFromDeployment),
-    canGetDeploymentTaskStatus: all.some((c) => c.canGetDeploymentTaskStatus),
-  };
-}
-
 /**
  * 把本会话接入的全部项目渲染成**一份**引导文本。
  *
@@ -206,17 +135,13 @@ function mergeDeployment(projects, tools) {
  * 列出各项目的命令名(`cmd_*` 变量),而不是把整份工具清单按前缀抄 N 遍。
  *
  * @param {ReadonlyArray<{ path: string, server: string, app: string, label: string, isRoot: boolean }>} projects
- * @param {{ tools?: Record<string, unknown> }} [options] `tools` 是本次请求的工具快照
- *   （`event.tools`），用来判断配套插件（run-lifecycle / deployment）的工具在不在。
  * @returns {string}
  */
-export function buildIdeGuidanceText(projects, options = {}) {
+export function buildIdeGuidanceText(projects) {
   return renderTemplate(TEMPLATE, {
     projectCount: projects.length,
     routeTable: routeTableFor(projects),
-    ...mergeRunLifecycle(projects, options.tools),
-    ...mergeDeployment(projects, options.tools),
-    ...commandVariables(projects, options.tools),
+    ...commandVariables(projects),
   });
 }
 
@@ -252,18 +177,16 @@ export const MCP_RECOVERY_GUIDANCE_RECONNECTING = [
  * Push the guidance onto a session `system` array. Called for every primary
  * model request, so it stays idempotent per request.
  *
- * The text depends on which projects are connected and which run-lifecycle tools
- * this request carries, so the idempotence check compares the built text rather
- * than assuming one variant.
+ * The text depends only on which projects are connected, and the idempotence check
+ * compares the built text rather than assuming one variant.
  *
  * @param {unknown} system
  * @param {ReadonlyArray<{ path: string, server: string, app: string, label: string, isRoot: boolean }>} projects
- * @param {{ tools?: Record<string, unknown> }} [options]
  */
-export function appendIdeGuidance(system, projects, options = {}) {
+export function appendIdeGuidance(system, projects) {
   if (!Array.isArray(system)) return;
   if (!Array.isArray(projects) || projects.length === 0) return;
-  const text = buildIdeGuidanceText(projects, options);
+  const text = buildIdeGuidanceText(projects);
   if (system.some((part) => part?.text === text)) return;
   system.push({ type: 'text', text });
 }

package/src/ide-guidance.template.md

@@ -7,11 +7,18 @@
 2. **IDE 工具补自带工具做不到的**：符号与定义用 `<前缀>_search_symbol` + `<前缀>_read_file`；改名用
    `<前缀>_rename_refactoring`；单文件检查用 `<前缀>_lint_files` / `<前缀>_get_file_problems`；跨模块构建用
    `<前缀>_build_project`。
-3. **`shell` 用于必须起进程的命令**：`pnpm` / `git` / `docker` / `curl` / `psql`、迁移与生成。
-4. **校验节奏**：改动过程中对改动的文件用 `lint_files` / `get_file_problems`；全仓 `pnpm typecheck` 在收尾跑一次。
-5. **批量修改**：逐文件用 `edit`，或一次用 `<前缀>_apply_patch`。
-
-本会话接入了 {{projectCount}} 个 JetBrains 项目。**每个功能在所有项目下都各有一份工具**,命令名是
+3. **要项目运行时环境的命令用项目终端**:{{cmd_project_sdk_terminal}};本机上 `git` / `ls` / `curl` / `docker` 这类与项目
+   无关的仍走 `shell`。远程机器不是这条 —— 见第 4 条。细则见「命令执行」与「终端」。
+4. **远程机器上的命令走 `<前缀>_execute_in_remote_host`**：用户说"去 xxx 上执行""部署机上跑一下""连某台机器看看",
+   先 `<前缀>_list_server_deployments` 拿服务器名,再用它在那台机器上跑。凭据、代理、路径映射都在 IDE 的那台
+   Server 后面 —— `serverName` 就是这些连接信息的唯一入口。
+5. **终端是复用的,不是一次性的**:同一来源(本机 / 每台远程服务器)有一条**默认 tab**,不传 `tab` 的命令都落在它上面。
+   细则见「终端」的复用规则。
+6. **校验节奏**：改一处只在收尾跑 `lint_files` (要细节再 `get_file_problems`);改一大片或动了接口 / 依赖就用
+   `build_project`;全仓检查只在收尾。
+7. **批量修改**：逐文件用 `edit`，或一次用 `<前缀>_apply_patch`。
+
+本会话接入了 {{projectCount}} 个 JetBrains 项目。**每个 IDE 功能在所有项目下都各有一份工具**,命令名是
 `<项目前缀>_<工具名>`;下文写 `<前缀>` 就是指这一截。
 
 ## 本会话接入的项目与各自的 MCP 工具
@@ -24,8 +31,8 @@
 **规则:操作哪个目录下的文件/代码,就用那个目录对应的命令。** IDE 按项目解析 —— 用错前缀时,调用要么报错,
 要么作用在另一个项目的代码上。
 
-按需读文件:要了解某个子项目自己的约定,读它的 `<子项目目录>/AGENTS.md`(它不会自动进入本会话的上下文,
-本会话是 root 打开的那一个)。
+按需读文件:要了解某个子项目自己的约定,读它的 `<子项目目录>/AGENTS.md` —— 它不会自动进入本会话的上下文
+(这里加载的是 root 的那一份)。
 
 ## 路由:先看路径在不在项目里
 
@@ -33,22 +40,25 @@
 项目外的路径(`/tmp`、别的仓库、用户主目录)不在 IDE 的解析范围内。
 
 - **项目内** —— **OpenCode 自带的工具为主**,它们更快。**它们做不了、或者做得很差的,才用 IDE 工具**:
-  符号检索、依赖实现、重构、格式化、校验、运行配置、跨文件补丁。
+  符号检索、依赖实现、重构、格式化、校验、运行配置、项目终端、跨文件补丁。
   **两边都不顺手时,你自己判断用 `shell` 里的命令** —— 那是第三选择,不是第一选择。
-- **项目外** —— 用 OpenCode 自带的工具;IDE 工具只对项目内路径生效。
+- **项目外、但还在本机** —— 用 OpenCode 自带的工具;IDE 工具只对项目内路径生效。
+- **远程机器(部署机 / 开发机 / 用户点名的那台主机)** —— 它不属于上面两类,是 IDE 里配好的一台 Deployment Server:
+  跑命令走 `<前缀>_execute_in_remote_host`,传文件走 `<前缀>_upload_to_deployment` / `<前缀>_download_from_deployment`。
+  凭据与路径映射都由这台 Server 提供。
 
 ## 总则 (所有项目通用)
 
 - **OpenCode 自带的工具直接调用** —— 工具列表里直接列出的那些(`read` / `grep` / `glob` / `edit` / `write` / `shell`),
   参数按各自 schema 传。它们就在当前工具表里,直接调用即可。
 - **读文件用 `read` 工具** —— 要读某一段就传 `offset`(从第几行起)+ `limit`(读几行),输出自带行号。
-- **搜文本用 `grep` 工具** —— 它按 `.gitignore` 排除,`node_modules` / `dist` 不进结果,范围用 `path` 收窄。
+- **搜文本用 `grep` 工具** —— 它按 `.gitignore` 排除,依赖目录 / 构建产物不进结果,范围用 `path` 收窄。
   要看命中行前后的大段上下文:先用它拿到**行号**,再用 `read` + `offset` / `limit` 读那一段。
 - **工具输出不够用时,按这个顺序调整**:① 调参数重试 → ② 缩小路径范围重试 → ③ 换工具。
   换用 `shell` 的判断依据是"这个工具确实没有这个能力"。
   典型:`<前缀>_list_directory_tree` 的输出到 `maxDepth` 边界就停 —— 调大 `maxDepth` 再试一次。
 - **改文件**:改一个符号用 `<前缀>_rename_refactoring`;改一段文字用 `edit` / `write` 工具;
-  同一段文字铺到多个文件用 `<前缀>_apply_patch`;跑命令用 `shell` 工具。
+  同一段文字铺到多个文件用 `<前缀>_apply_patch`。跑命令的路由见「命令执行」。
   改代码始终落在具体的那几行上,其余内容保持原样。
 - **改完代码自己先查一遍**:`lint_files` / `build_project`,怎么挑见「校验」。
 - **文档类文件 (Markdown / 文档) 改完之后,用 `<前缀>_reformat_file` 过一遍** —— 表格对齐、换行宽度、缩进交给 IDE
@@ -57,17 +67,30 @@
 
 ## 命令执行 (所有项目通用)
 
-- **跑命令用 `shell` 工具**;要项目环境的(IDE 里配好的 JDK / Node / Python 等)先看有没有现成的 run configuration ——
-  有就跑它 (常驻用 `rerun`,跑完即退用 `execute`);没有、又只是一次性的,用 `shell` 工具并显式指定解释器。
-  一次性的命令留在 `shell` 里,配置留给会反复用到的流程。
+- **按"这条命令在哪台机器上、要不要项目运行时"分流**:
+  - **远程机器**(部署机 / 开发机 / 用户说了"去 xxx 上"的那台)→ {{cmd_execute_in_remote_host}}。服务器名字不确定,
+    就先 {{cmd_list_server_deployments}} —— **它的返回就是"能直接跑命令的机器"清单**,`servers[].name` 直接用。
+  - **本机 + 要项目运行时**(IDE 里配好的 JDK / Node / Python / Maven / Go,以及依赖它们的构建、脚本、生成、迁移)→
+    {{cmd_project_sdk_terminal}}。它开的是 IDE 里真正的终端,自动带上项目 SDK 与 Maven / Node / Python 的路径;
+    `workingDirectory` 默认项目根,`env` 里的值最后覆盖。
+  - **本机 + 不要项目运行时**(`git` / `ls` / `cat` / `curl` / `docker` / `ps`)→ `shell` 工具。
+- **每种来源一条默认 tab,整趟任务复用**:不传 `tab` 的命令永远落在该来源的默认 tab 上(`project_sdk_terminal` 管本机、
+  `execute_in_remote_host` 管每台服务器)—— `cd` / `export` / 后台进程都留在那个 shell 里,不必每条命令重贴
+  `cd ... &&` 前缀。
+- **等太久会转成异步**:命令跑得久,这次调用先返回 `running: true` 和同一个 `tab`,命令还在里面跑 —— 用
+  结果从 {{cmd_terminal_read}} 取,每隔几秒看一眼,直到 `running` 变 false。
+- **卡住的命令用 {{cmd_terminal_interrupt}} 打断**:它在命令还跑着的时候发 Ctrl-C —— 执行工具帮不了这个忙
+  (它们会等 shell 空闲,卡住的命令会把它们一直挡住)。
+- **常驻进程**(dev server / watch / 长时间跑的服务)有 run configuration 就用 `rerun` 起它;
+  没有就用项目终端起在 tab 里;它跑满等待窗口还没结束会返回 `running: true`,之后用 {{cmd_terminal_read}} 跟日志。
+- **一次性的命令就地跑完,反复发生的流程才固化成 run configuration** —— 配置是**项目资产**,不是"跑命令"
+  的手段。判据只有一条: **这件事以后会不会以同样的形态再发生?** 会 (构建 / 生成 / 迁移 / 起服务 / 部署这类)
+  就 **主动提**一次要不要固化成配置,并把配置名 / 类型 / 命令 / 工作目录 / 为什么值得留摊开;
+  不会 (查条数据、看个日志、试一条命令) 就地跑完算。
 - **建 / 改 / 删运行配置,走 `idea-run-config-manager` skill**(服务化应用的配置归 `idea-standalone`):
   它落手用的就是「运行配置」里的那组工具 —— 配置文件由工具写入和删除。
-{{#if canCreateRunConfiguration}}
-{{else}}
-  本会话没有新建工具,"建"这一步它只能讲清配置名、实际执行的命令、工作目录、为什么值得留, **请用户在 IDE 里创建**
-{{/if}}
 
-## 工具 (每条第一行是各项目的命令,接着是它的用法)
+## 工具 (每条先列各项目的命令名,再写用法)
 
 ### 符号 (只有 IDE 的语义索引能给)
 
@@ -79,11 +102,9 @@
   (类 / 接口 / 方法 / 函数 / 字段 / 类型 / 常量这类 **有名字的定义**)的**声明位置**,不是"哪段文本提到过它"(那是
   `grep` 工具的事);带上 `include_external` 才会连依赖库和标准库一起搜 —— 这是 `grep` / `glob` 工具够不着的地方。
     - **查某个库的 API**:代码里 import 的包名就是线索,直接「包名 + 符号名」当 `q` —— Java 用全限定名
-      (`com.nimbusds.jose.util.Base64`)、Go 用 `pkg.Symbol`(`gorm.DeletedAt`)、Python 给全模块路径
-      (`torch.nn.Module`)、Node/TS 用 import 的那层包名(`vue.Teleport`)。**调研一个库有哪些 API**:拿包名当 `q`
-      (`fastapi` → 入口文件就是导出清单),再读它的入口。
-    - **Node/TS 例外**:带 `-` 或 `@scope/` 的包名这么拼是 0 条(`element-plus`);改用 import 的符号名,并用 `paths` 圈到
-      那个 `node_modules`(`paths: ['frontend/user/**']` 就收敛到一处)。
+      (`<包名>.<类名>`)、Go 用 `pkg.Symbol`(`<包名>.<导出符号>`)、Python 给全模块路径
+      (`<模块>.<类>`)、Node/TS 用 import 的那层包名(`<包名>.<导出名>`)。**调研一个库有哪些 API**:拿包名当 `q`
+      (入口文件通常就是导出清单),再读它的入口。
     - **搜不到 = 依赖没进来**:先把它加进依赖,或改用 web 搜索 / GitHub 看源码。
     - **同名符号往往有多处定义**(标准库 / 依赖 / 测试各一份):按调用处的 import 与参数类型来选。
     - **它返回的路径原样交给同一个项目的 `<前缀>_read_file`** —— 那个路径的基准是**它所在的项目**,不是会话工作目录;
@@ -95,11 +116,10 @@
 
 ### 项目与编辑器
 
-- {{cmd_list_directory_tree}} **项目视角的目录树**(尊重内容根与排除项):`maxDepth` 控深度。
-  **它是绝对深度上限,实际只展开到 `maxDepth-1` 层;省略时默认 5(只展开 4 层)。** 要看全就传一个明显够大的值
-  (如 50),不会报错、也没有额外代价。**输出到边界就停,不带任何截断标记** —— 所以"某个目录后面没有子项"有两种
-  可能:真空目录,或者被你截断了。判据:树的深度正好顶到你传的值,或者**包目录 / 源码目录显示为空** —— 那就是被截断了。
-  **把 `maxDepth` 调大重试,或把 `directoryPath` 直接指到那个子目录再看一层。**
+- {{cmd_list_directory_tree}} **项目视角的目录树**(尊重内容根与排除项):`maxDepth` 控深度,是**绝对上限但只展开
+  `maxDepth-1` 层**(省略时默认 5,即 4 层);要看全就传明显够大的值(如 50),没有额外代价。**输出到边界就停,不带截断
+  标记** —— 目录显示为空也可能是被切了;判据是树深度顶到传入值,或**包 / 源码目录显示为空**。调大 `maxDepth`,或把
+  `directoryPath` 指到那个子目录再看一层。
 - {{cmd_get_project_modules}} **项目模块及类型**。
 - {{cmd_get_project_dependencies}} **项目直接声明的依赖**。
 - {{cmd_get_all_open_file_paths}} **用户在 IDE 里打开了哪些文件**(含当前激活的那个)。
@@ -120,74 +140,53 @@
   - 返回里 `with N usages` 的 N 是**真引用数**;比预期少,说明有引用没被解析到(文件没进 IDE 索引),
     这时**先确认索引到那个模块**,再处理剩下的引用。
   - 改的本来就是文字(配置 key、模板占位符、文档、SQL)、**就是要改那句字符串**、或者文件 IDE 没索引(生成物、
-    vendor 目录)时,用 `edit` / `write` / `apply_patch`。动手前先用 `grep` 工具确认命中范围。
+    第三方目录)时,用 `edit` / `write` / `apply_patch`。动手前先用 `grep` 工具确认命中范围。
 - {{cmd_reformat_file}} **按 IDE 的代码风格重排**。
 - {{cmd_apply_patch}} **一次改多个文件**:`input` 传补丁正文,Codex 格式(`*** Begin Patch` / `*** Update File: <路径>`
   / `@@` / `-` 旧行 / `+` 新行)与 unified git diff 都收。`edit` / `write` 工具都只管一个文件。
   - 它**按文本**改,适合同一段文字铺到多个文件;**改符号走上面那条**。
-  - 它**只碰补丁里写明的那几行**,其余内容保持原样。
-  - 上下文对不上时那一个 hunk 失败、**该文件原样不动**,返回里点名是哪个文件(`<路径>: Hunk context not found`)。
-  - 多个文件是**逐个应用**的:返回里 `N out of M operations applied`,失败的那些读一下再改;
-    改完用 `grep` 工具确认落盘。
+  - 只碰补丁里写明的那几行。上下文对不上时该文件**原样不动**(`<路径>: Hunk context not found`);多个文件按返回的
+    `N out of M operations applied` 逐个补,改完用 `grep` 工具确认落盘。
 - {{cmd_lint_files}} **批量检查**:`files` 传数组;只列有问题的文件。
 - {{cmd_get_file_problems}} **单文件检查**:`filePath`;结果在 `errors`。
 - {{cmd_build_project}} **构建校验**:`filesToRebuild` 可只构建指定文件;有问题返回在 `problems`,没返回即没问题。
 
 **改完代码,自己先查一遍再收尾。** 查一次很便宜,而问题一旦漏到用户看见、或留到构建 / 测试炸了才暴露,回头纠正的
-代价就高一个量级。 校验跟着改动范围走 —— 这一轮属于"改一大片"还是"改一处",见下面两条。
-
-- **这次要改一大片**(多文件、跨模块、"顺手把这几处一起对齐")→ 全部改完再 `build_project` 一次,
-  在完整状态上检查。
-- **这次只改一处,或在同一个文件上反复微调** → 告一段落时,把这轮改过的文件一次 `lint_files` 掉;要看单个
-  文件的细节再上 `get_file_problems`。
-- **改了签名 / 接口 / import / 依赖**这类"别处会跟着坏"的地方 → 走 `build_project`;只动了文件内部的实现 →
-  lint 就够。
+代价就高一个量级。 校验跟着改动范围走 —— 这一轮属于"改一大片"还是"改一处",按下面两条判断。
+
+- **改一大片**(多文件、跨模块、"顺手把这几处一起对齐"),或**动了签名 / 接口 / import / 依赖**这类"别处会跟着坏"的
+  地方 → 全部改完再 `build_project` 一次,在完整状态上检查。
+- **只改一处,或只在文件内部微调** → 告一段落时把这轮改过的文件跑一次 `lint_files`;要看单个文件的细节再上
+  `get_file_problems`。
 - 查出来的问题 **改掉,或说清为什么不改**。
-- 校验走上面这些工具;先调用一次,索引没同步或环境不对时它会明说。
-- **全仓类型检查是收尾动作,不是编辑循环**:同一任务只在最后跑一次 `pnpm typecheck`;过程中只对改动文件跑
-  `lint_files` / `get_file_problems`。局部检查用这两个工具,全仓 typecheck 留给收尾。
-- 只有改依赖清单、生成 Prisma Client、跑迁移这类必须执行命令的动作,才额外调用 `pnpm`;一个任务通常不超过两次。
+- 校验就用上面这些工具;索引没同步或环境不对时,第一次调用就会明说。
+- **全仓检查是收尾动作,不是编辑循环**:同一任务只在最后跑一次;过程中只对改动文件跑 `lint_files` /
+  `get_file_problems`。
 
 ### 运行配置
 
 - {{cmd_get_run_configurations}} **项目里有哪些运行配置**:传 `filePath` 可列该文件的运行入口。
   配置由 IDE 自己存储(通常在项目目录之外),用这个工具读。
-- {{cmd_execute_run_configuration}} **跑已有配置**:配置里的 `EXECUTE_IN_TERMINAL` 要是 `false`(共享出去的配置都这样)
-  ;覆盖参数 (`programArguments` / `workingDirectory` / `envs`)需配置支持 `supportsDynamicLaunchOverrides`,否则会直接报错。
-{{#if canCreateRunConfiguration}}
+- {{cmd_execute_run_configuration}} **跑已有配置**:配置里的 `EXECUTE_IN_TERMINAL` 要是 `false`(共享出去的配置都这样);
+  覆盖参数 (`programArguments` / `workingDirectory` / `envs`) 需配置支持 `supportsDynamicLaunchOverrides`,否则会直接报错。
 - {{cmd_create_run_configuration}} **新建任意类型的项目级配置**:内容来源三选一 —— `cloneFrom`(复制一个现成的,最稳;
   字段名不确定时只走它)、`configurationXml`(模板里的 XML 片段)、平台模板 + `options` / `attributes` / `envs` 补丁。
-  它是 **项目资产**,不是"跑命令"的手段 —— 只是要跑一条命令就用 `shell` 工具。
-  **要不要建、建什么、怎么建、档案怎么记,全按上面那个 skill 走。** 判据只有一条: **这件事以后会不会以同样的形态再发生?**
-  会 (改表后同步 DDL、跑迁移、生成代码、打包、起 dev server、往某个环境部署这类)就 **主动提**一次
-  "要不要固化成 run configuration",并把配置名 / 类型 / 命令 / 工作目录 / 为什么值得留摊开;不会 (查条数据、看个日志、
-  试一条命令)就用 `shell` 工具跑完算。
+  **建不建按上面那条判据**;怎么建、档案怎么记,全按 `idea-run-config-manager` skill 走。
   **改完同步档案**:新增 / 删除 / 改名之后按 skill 更新 `AGENTS.md` 里的档案块 —— 档案和项目里的配置对不上,比没有档案更糟。
-{{/if}}
-{{#if canInspectRunConfiguration}}
 - {{cmd_inspect_run_configuration}} **看一个配置的全貌**:定义 (options / envs / before-launch)、命名解析 (`win` /
   mac-linux、base、env)、当前活实例、历史运行及各自的日志文件路径。 **改之前先用它拿当前值**;服务起没起来想看日志,先用
   `list_running_configurations` 的 `logFile`,要翻"上一次为什么挂了"再走这里。
-{{/if}}
-{{#if canUpdateRunConfiguration}}
 - {{cmd_update_run_configuration}} **改字段或改名**:`options` / `envs` / `attributes` 是补丁 (`null` = 删),`newName` 改名并
   **连带更新别人对它的引用**、迁移历史日志。改之前先 `inspect` 拿 `configurationXml` 与当前值。
-{{/if}}
-{{#if canDeleteRunConfiguration}}
 - {{cmd_delete_run_configuration}} **删配置**:在跑或被人引用时拒绝;`force = true` 才会连引用一起清掉。
-{{/if}}
-{{#if canListRunningConfigurations}}
 - {{cmd_list_running_configurations}} **当前真正在跑的配置**(几个实例 / 各自 pid / 退出码,每个实例还带自己的日志文件路径
   `logFile`):停 / 重启前后都先用它看状态。
-{{/if}}
-{{#if canStopRunConfiguration}}
 - {{cmd_stop_run_configuration}} **停掉该配置的全部实例并等它们退出**:没在跑也返回成功。
-{{/if}}
-{{#if canRerunRunConfiguration}}
 - {{cmd_rerun_run_configuration}} **启动 / 重启常驻进程**:在跑就重启、没在跑就启动 —— 改完代码要重启就直接用它,
   有没有热重载都一样;读 `started` 判断新进程是否真的起来了。这次运行的输出在 `output`,完整日志文件路径在
   `fullOutputPath`。启停都走这个工具,IDE 的 Run 窗口状态才会跟着更新。
-{{/if}}
+  **before-launch 很久**(要先构建 / 跑另一个配置)时,调用会一直等到它结束;等不起就传 `waitForStart: false`,
+  提交后自己查 {{cmd_list_running_configurations}}。
 
 **配置名怎么读**:`[os@]base[@env]`,`@` 分割、最多三段 —— `os` = `win`(缺省 macOS / Linux)、`base` = 配置本体(必填)、
 `env` = 环境名(缺省 = 默认环境)。`win@base`(换平台)与 `base@env`(换环境)都是 `base` 的 **变体**,跑哪一个:
@@ -197,27 +196,72 @@
   变体、没有默认版的,就用它自己那个 —— "10 个服务"可以是"3 个 `@dev` + 7 个默认",不必逐条问。
 - 一条配置同时有 `base` 与 `base@<env>`、又没说走哪个环境 → **问一次走哪个环境**,选定后本会话默认走这套。
 - 一个环境怎么接上(启动参数 / 环境变量 / 配置文件)是项目自己的事:照现成的同类变体来,或问用户。
-{{#if canListDeploymentServers}}
+
+### 终端 (本机环境 · 远程主机 · 复用同一个 tab)
+
+- {{cmd_project_sdk_terminal}} **在本项目 SDK 终端里跑一条命令,返回输出与 tab id**。`command` 必填;`workingDirectory`
+  默认项目根;`env` 最后覆盖自动注入的环境;`input` 在命令后写一次(自带换行);`maxChars` 只保留最新输出。
+  **默认复用**:命令打进本项目的默认 tab(第一次调用创建,`list_terminals` 该组的 `default` 就是它),`cd` / `export` /
+  后台进程都还在;`workingDirectory` 会在那个 tab 里 `cd` 过去。`env` 只能在新 shell 生效,传了它就会新开一个(不会抢默认);
+  要指定某条 tab 传 `tab`,要干净 shell 传 `newTab: true`(同样不抢默认)。命令跑得久时先返回 `running: true`,
+  用 {{cmd_terminal_read}} 接着看。
+- {{cmd_list_terminals}} **本项目的终端 tab 清单**:按来源分组 —— `mcp_project_sdk` 一组、每台远程服务器各一组;每组带一个
+  组级 `default`(该来源的默认 tab)和组内 `tabs` 数组(状态、当前目录、最后一条命令)。用户自己开的 tab 不出现;
+  只有 `addressable: true` 的能交给 {{cmd_terminal_read}} / {{cmd_terminal_interrupt}}。
+- {{cmd_terminal_read}} **读已有 tab,立即返回、不等待**:`target` 取 `local`(`project_sdk_terminal` 建的)或 `remote`
+  (`execute_in_remote_host` 建的)。默认读**上次之后的新输出**,`tail: N` 读最近 N 个命令段(本地带每段的 `exitCode`),
+  `full: true` 读整屏。返回里的 `running` 说明命令还在不在跑。
+- {{cmd_terminal_interrupt}} **往已有 tab 发一次 Ctrl-C**:同样传 `target` + `tab`。只在命令卡住时用 —— 执行工具会等
+  shell 空闲,卡住的命令会把它们一直挡住。它不接受任何文本,只能打断,不能拿来跑命令。
+- {{cmd_execute_in_remote_host}} **在远程主机的真实 SSH 终端里跑命令** —— 主机与凭据来自本项目的一台 Deployment
+  SFTP 服务器,名字传 `serverName`(那台**服务器**的名字,不是 deployment 名)。`loginShell` 默认 `true`(套
+  `zsh -lic` / `bash -lc`,PATH 与工具链才会加载);`strictHostKey` 默认 `false`(接受并记录新主机密钥)。
+  **远程命令一律走它** —— 凭据、代理、路径映射都在 IDE 这边。
+  **默认复用这台服务器的默认 tab**(第一次调用创建,`list_terminals` 该组的 `default` 就是它;整趟任务只重连一次 SSH),
+  `cd` / `export` / 后台进程都在原地;传 `tab` 指定某条,传 `newTab: true` 换一个干净 shell。
+  远程没有"命令结束"信号:**`exitCode` 永远为 `null`,`running` 也可能为 `null`** —— 别等 `exitCode`,看输出,或接着用
+  {{cmd_terminal_read}} 读。
+- **`list_server_deployments` 报出来的服务器就是能直接跑命令的机器**:拿到名字立即用 `execute_in_remote_host`。
+  `hasCredentials` / `validationIssue` 有问题时把它报给用户,由用户在 IDE 里处理。
+
+**复用规则 (本地 / 远程一套):每种来源一条默认 tab。**
+
+1. 直接调 `project_sdk_terminal`(本机)或 `execute_in_remote_host`(远程),不传 `tab` 就落在该来源的默认 tab 上。
+   不用先 `list_terminals`,也不用把 tab id 一路记着。
+2. **不必每条命令重贴 `cd ... &&`**:复用同一个 shell,目录、`export` 的变量、后台进程都还在。要换目录就传
+   `workingDirectory`(会在那个 tab 里 `cd` 过去),别再用 `cd` 拼在命令前面。
+3. **什么时候要新 tab**:两条命令会互相干扰、要独立环境的 `env`、或想从头来一遍 —— 传 `newTab: true`。
+   它不会抢走默认身份;默认 tab 被关掉后,下次调用会重建一条。
+4. 要盯输出用 {{cmd_terminal_read}}:`read` 读增量或 `tail: N` 读最近几段。**它不是"再跑一条"的替代**。
+5. 本地 tab 只跑本机命令,远程 tab 只跑那台机器上的命令 —— 别拿本地 tab 敲远程命令(反之亦然);跨服务器同理。
+
+**tab 只在这次 IDE 会话里有效**:tab 一关(报 `terminal_closed` / 找不到 tab)才重新开一个;用完不必主动关 —— 用户能看见,
+也能直接在 IDE 里接手。
 
 ### 服务器文件同步
 
 往服务器传文件 / 从服务器取文件,走这一组 —— IDE 的连接、路径映射、排除规则都在它们后面,传的就是 IDE 在管的那一份。
 
-- {{cmd_list_deployment_servers}} **本项目能用的部署服务器**:名称 (后面几条用它当 `serverName`)
-  、项目级还是应用级、协议、host / port、在本项目里的路径映射,以及 **项目级**的部署选项与危险组合告警。 **只读 IDE
-  配置、不联网**;动手前先看 `warnings[]`。
-{{#if canUploadToDeployment}}
-- {{cmd_upload_to_deployment}} **把映射到的本地目录传到服务器**(等同 IDE 的 Upload to …)。`mode` 默认 `mirror` ——
+- {{cmd_list_server_deployments}} **本项目能用的服务器,以及每台服务器上的 deployment**。先分清两层:
+  **Server 是连接目标,deployment 是挂在它上面的一条路径映射**;一台 Server 可以有 **0 个 deployment** —— 那样它仍能给
+  `execute_in_remote_host` 用,但**上传 / 下载没有目标**。
+  - `servers[].name` → **远程终端**的 `serverName`;`servers[].deployments[].name` → **上传 / 下载**的 `deploymentName`
+    (由本地路径最后一段派生,**全局唯一**)。
+  - 每台 Server 还带 `level`(项目级 / 应用级)、`accessType`、`host` / `port`、`rootFolder`、`hasCredentials`、
+    `validationIssue`、`isDefault`;返回里另有**整个项目共用**的 `options` 与 `warnings[]`(**只读 IDE 配置、不联网**)。
+  - **`hasCredentials: false` 的服务器连不上** —— IDE 会弹模态登录框,MCP 调用会卡死;动手前先看 `warnings[]`。
+- {{cmd_upload_to_deployment}} **把一条 deployment(本地映射目录)传到服务器**(等同 IDE 的 Upload to …)。
+  `deploymentName` 传 `servers[].deployments[].name` —— **不是 `serverName`**。`mode` 默认 `mirror` ——
   **会删掉服务器上多出来的文件**,使两边一致;要留住它们就传 `upload`。 **破坏性操作**。
-{{/if}}
-{{#if canDownloadFromDeployment}}
-- {{cmd_download_from_deployment}} **把服务器上映射目录的内容拉回本地**(等同 IDE 的 Download from …), **以服务器为准**:
-  两边都有的文件会被远端覆盖 (内容相同则不写)。 **没有"保留我的版本"这个选项**。
-{{/if}}
-{{#if canGetDeploymentTaskStatus}}
+- {{cmd_download_from_deployment}} **把一条 deployment 从服务器拉回本地**(等同 IDE 的 Download from …), **以服务器为准**:
+  两边都有的文件会被远端覆盖 (内容相同则不写)。同样传 `deploymentName`。 **没有"保留我的版本"这个选项**。
 - {{cmd_get_deployment_task_status}} **查一次传输的状态**:`handle` 用上传 / 下载返回的那个 —— **它自己不启动任何传输**。
-{{/if}}
 
-上传 / 下载都在 IDE 后台跑,单次调用只等到 `waitMs`(默认 10 秒)为止;返回 `in_progress` 是 **正常**的,不是失败 —— 拿
-`handle` 去查进度;重复调用上传 / 下载会再起一次传输。
-{{/if}}
+上传 / 下载默认**同步等结果**:传完立刻返回 `state: "completed"`。只有超过等待窗口(300 秒)还没传完,才会返回
+`state: "in_progress"` + `handle` —— 这 **正常**,不是失败(它也可能以 error 结果回来);拿 `handle` 调
+`get_deployment_task_status` 接着看 —— 重复调上传 / 下载会再起一次传输。到 `completed` 之后
+`counters` 才可信,而且它数的是**操作次数**,不是文件数(删掉整个目录也只算 1)。
+
+**同步只是上半段**:传完之后在那台 Server 上继续操作(启动刚传上去的二进制、重启服务、看日志)—— 用
+`execute_in_remote_host`,`serverName` 取 `servers[].name`。上传下载与远程执行走的是同一台 Server、同一套凭据和
+路径映射 —— 两条路径连的是同一个地方。

package/src/mcp/idea-tool-defaults.js

@@ -1,11 +1,13 @@
 // Arguments this plugin OWNS on the IDE's own MCP tools.
 //
-// Three files, three different subjects — kept apart on purpose:
+// Two files, two different subjects — kept apart on purpose:
 //
 //   * `idea.js`             the IDE's bundled MCP server: endpoint, transport, probe
 //   * `idea-tool-defaults`  (this file) that server's TOOL CATALOG, and the
 //                           arguments on it that this plugin controls
-//   * `enhance.js`          a companion plugin's tools, which may not be installed
+//
+// The companion plugin's own tools are not managed here at all: they are a hard
+// prerequisite, passed through untouched.
 //
 // ## Why an argument can be owned at all
 //

package/src/mcp/idea.js

@@ -127,7 +127,7 @@ export async function callTool(port, projectPath, name, args = {}, options = {})
       params: {
         protocolVersion: PROTOCOL_VERSION,
         capabilities: {},
-        clientInfo: { name: 'opencode-idea', version: '0.1.2' },
+        clientInfo: { name: 'opencode-idea', version: '0.1.4' },
       },
     });
     // The IDE's Streamable-HTTP endpoint binds follow-up requests to the session

package/src/plugin.js

@@ -1376,10 +1376,8 @@ export default {
                 // Guidance promises tools the model can call, so it only goes out when
                 // they are actually in this request.
                 if (!serving) return;
-                // 逐项目注入：每个项目那一节只写它自己的前缀，模型不需要自己换算。
-                // 配套插件 `idea-mcp-enhance` 的两组工具（run-lifecycle / deployment）也按每个项目分别判断,
-                // 所以一个项目装了 enhance、另一个没装时，各节的内容本来就不一样。
-                appendIdeGuidance(event?.system, currentProjects(), {tools});
+                // 逐项目注入：每条工具后面直接列各项目的命令名，模型不需要自己换算前缀。
+                appendIdeGuidance(event?.system, currentProjects());
             });
 
             // 自愈入口(钩子型)。OpenCode 会 await `prompt`,所以在这里修好的连接会在

package/src/mcp/enhance.js

@@ -1,151 +0,0 @@
-// MCP surface added by the companion IDEA plugin `idea-mcp-enhance`.
-//
-// Kept apart from `idea.js` on purpose. `idea.js` describes ONE thing: the MCP
-// server IntelliJ itself bundles, which every supported IDE has. Everything in
-// this file describes a SECOND, optional source of tools — a plugin the user may
-// or may not have installed. Two different origins, two files:
-//
-//   * native  -> `idea.js`      (always present; the IDE owns the catalog)
-//   * plugin  -> this file      (present only if the user installed the plugin)
-//
-// The companion plugin (https://github.com/syllr/idea-mcp-enhance) fills gaps the
-// bundled server leaves in two places:
-//
-//   * run configuration — the bundled server can only START an existing
-//     configuration; it cannot create one, stop one, restart one, or say what is
-//     currently running;
-//   * deployment — the bundled server has nothing at all for the IDE's
-//     Deployment settings or for moving files to/from a server.
-//
-// The two are kept as separate groups everywhere (here, in the capability
-// functions, and in the guidance), because they are NOT the same precondition:
-// deployment additionally needs `com.jetbrains.plugins.webDeployment`, which
-// exists only in Ultimate. One boolean covering both would let a deployment tool
-// answer "are the run-lifecycle tools here?".
-//
-// Consequence of the split, and the reason it matters: a stock IDE serves a
-// SHORTER catalog than an enhanced one. Nothing here may be assumed — every use
-// has to be gated on the tools really being in the request.
-
-/**
- * The enhance plugin's **run-lifecycle** tool names, as **suffixes**.
- *
- * OpenCode namespaces an MCP server's tools with the server name, and each
- * project is registered under its own prefix (root = `ide`, a subproject = its
- * directory name). So the wire name is `<prefix><suffix>` — for example
- * `ide_rerun_run_configuration` or `modelserver_rerun_run_configuration`.
- *
- * 存后缀而不是完整名字：同一个工具在每个项目前缀下各有一份，写死任何一个前缀都会
- * 让别的项目查不到它。
- *
- * Keep in sync with `RunLifecycleSchemas.kt` in the enhance repository — the
- * suffixes are its contract, and there is no runtime way to discover "which
- * plugin provided this tool": MCP carries no such marker.
- */
-export const CREATE_RUN_CONFIGURATION_SUFFIX = 'create_run_configuration';
-export const INSPECT_RUN_CONFIGURATION_SUFFIX = 'inspect_run_configuration';
-export const UPDATE_RUN_CONFIGURATION_SUFFIX = 'update_run_configuration';
-export const DELETE_RUN_CONFIGURATION_SUFFIX = 'delete_run_configuration';
-export const LIST_RUNNING_CONFIGURATIONS_SUFFIX = 'list_running_configurations';
-export const STOP_RUN_CONFIGURATION_SUFFIX = 'stop_run_configuration';
-export const RERUN_RUN_CONFIGURATION_SUFFIX = 'rerun_run_configuration';
-
-/** All of them, in the order the guidance lists them: create, see, stop, restart. */
-export const RUN_LIFECYCLE_SUFFIXES = [
-  CREATE_RUN_CONFIGURATION_SUFFIX,
-  INSPECT_RUN_CONFIGURATION_SUFFIX,
-  UPDATE_RUN_CONFIGURATION_SUFFIX,
-  DELETE_RUN_CONFIGURATION_SUFFIX,
-  LIST_RUNNING_CONFIGURATIONS_SUFFIX,
-  STOP_RUN_CONFIGURATION_SUFFIX,
-  RERUN_RUN_CONFIGURATION_SUFFIX,
-];
-
-/**
- * The enhance plugin's **deployment** tool names, as suffixes — same contract and
- * same reason for suffixes as {@link RUN_LIFECYCLE_SUFFIXES}.
- *
- * Keep in sync with `DeploymentSchemas.kt` in the enhance repository.
- *
- * The four are gated together on one plugin (`com.jetbrains.plugins.webDeployment`,
- * Ultimate only) rather than on version drift, so they usually appear or vanish as
- * a set — the guidance still names them one by one, because "usually" is not
- * "always" and a named tool the model cannot call is only a failed call.
- */
-export const LIST_DEPLOYMENT_SERVERS_SUFFIX = 'list_deployment_servers';
-export const UPLOAD_TO_DEPLOYMENT_SUFFIX = 'upload_to_deployment';
-export const DOWNLOAD_FROM_DEPLOYMENT_SUFFIX = 'download_from_deployment';
-export const GET_DEPLOYMENT_TASK_STATUS_SUFFIX = 'get_deployment_task_status';
-
-
-/** All of them: look at the servers, upload, download, then poll a transfer. */
-export const DEPLOYMENT_SUFFIXES = [
-  LIST_DEPLOYMENT_SERVERS_SUFFIX,
-  UPLOAD_TO_DEPLOYMENT_SUFFIX,
-  DOWNLOAD_FROM_DEPLOYMENT_SUFFIX,
-  GET_DEPLOYMENT_TASK_STATUS_SUFFIX,
-];
-
-/**
- * Does this request carry the tool called `suffix` under `prefix`?
- *
- * A malformed or missing snapshot answers "no": assuming a tool exists is the one
- * mistake that cannot be walked back once the model has read the guidance.
- *
- * Exported because the guidance asks this twice. The capability flags (below) ask
- * "does this request have the tool somewhere" (any project will do); the command
- * list next to each tool asks "under WHICH prefix", and that answer must be exact —
- * 提示词里点名一个模型调不到的命令,是这个模块唯一要防的失败。
- *
- * @param {Record<string, unknown> | undefined} tools
- * @param {string} prefix 该项目的工具前缀（含下划线）。
- * @param {string} suffix
- */
-export const servesTool = (tools, prefix, suffix) =>
-  Boolean(tools) && typeof tools === 'object' && `${prefix}${suffix}` in tools;
-
-/**
- * Which of the enhance plugin's tools **this project's prefix** carries in this
- * request.
- *
- * 返回布尔组合而不是名字列表：提示词要的是"这段能不能写",而且每个项目各算各的
- * —— 一个项目装了 enhance、另一个没装是可能的。
- *
- * 客户端版本差异同理：enhance 版本独立发布，旧版可能少几个工具，所以逐个判断,
- * 提示词绝不能点名一个模型调不到的工具。
- *
- * @param {Record<string, unknown> | undefined} tools This request's tool record
- *   (`event.tools` from the `context` hook).
- * @param {string} prefix 该项目的工具前缀（含下划线）。
- */
-export function runLifecycleCapabilities(tools, prefix) {
-  return {
-    canCreateRunConfiguration: servesTool(tools, prefix, CREATE_RUN_CONFIGURATION_SUFFIX),
-    canInspectRunConfiguration: servesTool(tools, prefix, INSPECT_RUN_CONFIGURATION_SUFFIX),
-    canUpdateRunConfiguration: servesTool(tools, prefix, UPDATE_RUN_CONFIGURATION_SUFFIX),
-    canDeleteRunConfiguration: servesTool(tools, prefix, DELETE_RUN_CONFIGURATION_SUFFIX),
-    canListRunningConfigurations: servesTool(tools, prefix, LIST_RUNNING_CONFIGURATIONS_SUFFIX),
-    canStopRunConfiguration: servesTool(tools, prefix, STOP_RUN_CONFIGURATION_SUFFIX),
-    canRerunRunConfiguration: servesTool(tools, prefix, RERUN_RUN_CONFIGURATION_SUFFIX),
-  };
-}
-
-/**
- * Same question for the deployment group, and the same answer shape — see
- * {@link runLifecycleCapabilities}.
- *
- * The names repeat the tool's subject rather than the group (`canUploadToDeployment`,
- * not `canUpload`): the guidance is one document about two groups, and a flag whose
- * owner is unclear is how the wrong section gets the wrong text.
- *
- * @param {Record<string, unknown> | undefined} tools
- * @param {string} prefix 该项目的工具前缀（含下划线）。
- */
-export function deploymentCapabilities(tools, prefix) {
-  return {
-    canListDeploymentServers: servesTool(tools, prefix, LIST_DEPLOYMENT_SERVERS_SUFFIX),
-    canUploadToDeployment: servesTool(tools, prefix, UPLOAD_TO_DEPLOYMENT_SUFFIX),
-    canDownloadFromDeployment: servesTool(tools, prefix, DOWNLOAD_FROM_DEPLOYMENT_SUFFIX),
-    canGetDeploymentTaskStatus: servesTool(tools, prefix, GET_DEPLOYMENT_TASK_STATUS_SUFFIX),
-  };
-}