opencode-idea 0.0.25 → 0.0.27

package/README.md

@@ -169,9 +169,11 @@ IDE MCP 可用时,插件通过 **系统提示注入**告诉模型 **哪些事该
           `ide_download_from_deployment` / `ide_get_deployment_task_status`
     - **读、找文本、找文件用原生工具**(`read` / `grep` / `glob`)—— 这几件事走 IDE 只是多一跳,
       所以映射表里 **不出现** `ide_search_text` / `ide_search_regex` / `ide_search_file`,也不再禁止它们的原生对应物。
-    - **写文件反过来走 IDE**(`ide_apply_patch` / `ide_create_new_file`):原生 `write` / `edit` 是 **进程外**写,
-      IDE 对编辑器里开着的文件留着一份内存副本,要等 VFS 刷新才重读 —— 这期间 IDE 侧工具读到的是旧内容,
-      `reformat_file` 还会把旧副本存回磁盘把刚写的代码冲掉。走 IDE 写,内存与磁盘才是同一份。
+    - **写文件一律用原生 `write` / `edit`**:IDE 的 `apply_patch` / `create_new_file` 已收起 —— 补丁工具按上下文精确匹配,
+      标点被规范化就整块对不上(`Hunk context not found`),而原生写没有这层限制。IDE 侧只留 **重构**与**格式化**。
+      **`ide_reformat_file` 会从磁盘重读**,所以外部写完直接格式化是安全的(实测:新增 / 删除 / 改文本都不会被旧副本
+      冲掉);会丢内容的只有 **用户在编辑器里正改着的那份脏 buffer**,别对它跑 formatter。
+      **读**是另一回事:`ide_read_file` 可能给出旧快照,要它跟上得先跑一次 `ide_get_file_problems`。
     - **唯一例外是 `ide_read_file`**:它是读 **包内文件**的唯一手段 (`<jar>!/<entry>` 的依赖 jar 内文件、`jrt://` 的
       JDK 镜像),引导只在这个用途上点名它,并写明普通文件一律用 `read`。
 
@@ -429,9 +431,8 @@ loader 读的是 OpenCode 文档里的那个嵌套写法 (它自己的读取器
 `ShConfigurationType`
 (`<option>` 子元素)、`NodeJSConfigurationType`(全属性)三种写法并存,套错就是静默失效。
 
-**先过滤,再建档**:**服务化的配置不进这个块** —— 它们已经登记在 `AGENTS.md` 的 `idea-standalone` 块里 (端口 /
-热重载也写在那里),
-所以建档第一步是读那个块、把它登记过的名字记下来并排除, **剩下的**才是本块内容。
+**先过滤,再建档**:**服务化 / 常驻应用的配置一律不进这个块**(它们归 `idea-standalone`,端口与热重载写在那边的块里);
+有那个块时,再把它登记过的名字一并排除 —— **剩下的**才是本块内容。
 
 这个档案块 **以带前缀的工具为准**,不围绕 IDE 界面说话:各项目各有自己的前缀 (root 是 `ide`,子项目是它的目录名),枚举与执行都用
 **它自己那个前缀**的
@@ -442,20 +443,14 @@ loader 读的是 OpenCode 文档里的那个嵌套写法 (它自己的读取器
 删除 / 修改**
 (无论谁做的:工具建的、用户自己建的、用户删掉的)都要在文档里同步 **加条目 / 删条目 / 改条目**,否则它就开始骗人。
 
-**别的文档都指向这里**:引导文本与 `idea-standalone` skill 碰到"要建 / 删 / 改一个配置",不再让用户自己去 IDE 里摸,而是让用户调本
-skill ——
-增 / 删 / 改的流程入口只有这一个,而它只由用户触发。
+**别的文档都指向这里**:引导文本碰到"要建 / 删 / 改一个配置",不再让模型现编流程,而是让它加载本 skill ——
+增 / 删 / 改的流程与档案规则只有这一处。
 
-**它绕着"新建配置"这件事写**(新建只有配套插件 `idea-mcp-enhance` 能做),但 **这不影响它出不出现** —— 两个 skill
-都在插件加载时注册,
-不缺任何工具也照样在列表里;缺工具时由正文把流程交回用户 (`idea-standalone` 只要 `rerun_run_configuration`,门更松)
-。这是刻意的:
-一个只教模型"去建配置"、却没给建配置工具的 skill,只会把用户拖进一次注定失败的调用。
+**两个 skill 都是模型可自取的**(frontmatter 不带 `metadata: opencode/autoinvoke: false`):模型判断到场景就加载。
+「该不该建」的判断留在引导文本里(它每次请求都在),skill 负责动手时的流程与写法。
 
-**而且只能用户调**:它的 frontmatter 带 `metadata: opencode/autoinvoke: false`,loader 翻成定义的 `autoinvoke: false` ——
-skill 照常注册,但 **不进模型的可选列表**,模型不会自己挑上它,只有用户显式指定 (`@idea-run-config-manager`)才会加载。
-理由是它 **直接动手改项目文件与项目资产**:运行配置与 `AGENTS.md` 都由用户自己按这个 skill 的流程来改,模型不主动挑上它。
-「该不该建」的时机判断仍在引导文本的判据里 (那是模型该管的事), **动手权**留给人。
+**它绕着"新建配置"这件事写**,但不影响它出不出现 —— 两个 skill 都在插件加载时注册,缺工具时由正文把流程交回用户
+(`idea-standalone` 只要 `rerun_run_configuration`,门更松)。
 
 ## Deployment 全套 (配套插件 `idea-mcp-enhance`)
 
@@ -667,19 +662,19 @@ export { default } from "/Users/yutao/Projects/opencode-idea/src/index.js";
   不存在 —— 用错会让 `ctx.skill.transform` 抛 `SchemaError`,而 **任何 transform 失败都会禁用整个插件**(0.0.6 就是这样丢了
   `/open-in-ide`)。同理,`Skill.Info` 的完整字段是 `id` / `name` / `description?` / `autoinvoke?` / `path` / `content`。
 - 需要项目环境的命令走 `ide_execute_run_configuration`(run configuration 要先在 IDEA 里配好),不用原生 shell。
-- 一批用不到的 IDE MCP 工具被硬编码隐藏 (`src/plugin.js` 的 `HIDDEN_IDE_TOOL_SUFFIXES`, **共 47 个后缀**):
+- 一批用不到的 IDE MCP 工具被硬编码隐藏 (`src/plugin.js` 的 `HIDDEN_IDE_TOOL_SUFFIXES`, **共 49 个后缀**):
   VCS (`git_status` / `get_repositories`,版本控制走原生 `git`)、Router 派发工具 (`execute_tool`,未启用 router-only
   时冗余)、
   Debugger (全部 `xdebug_*`)、Dev Kit MCP、Inspection KTS MCP、解释器环境 MCP、 **IDE 内置终端 (`execute_terminal_command`:
   实测不继承项目环境,对原生 shell 没有优势)**、 **整个 Database 组**(数据源由用户在
-  IDE 里配置,而 IDE 也不是本插件设想的数据库客户端),以及 **有原生对应的文件搜索**
-  (`search_text` / `search_regex` / `search_file` 分别对应 `grep` / `grep -E` / `glob`)。 **文件"写"(`apply_patch` /
-  `create_new_file`)刻意不隐藏** —— 走 IDE 写才有"内存与磁盘是同一份"这件事 (见上面
-  「写文件反过来走 IDE」);配套插件自带的那个写文件工具则隐藏,同一个活儿不摆两个工具。
+  IDE 里配置,而 IDE 也不是本插件设想的数据库客户端)、 **有原生对应的文件搜索**
+  (`search_text` / `search_regex` / `search_file` 分别对应 `grep` / `grep -E` / `glob`),以及 **文件写**
+  (`apply_patch` / `create_new_file`:原生 `write` / `edit` 就够,补丁工具的上下文精确匹配反而脆 —— 见上面
+  「写文件一律用原生」)。配套插件自带的那个写文件工具同样隐藏。
 
   存的是 **后缀**,清洗时按当前每个项目前缀 **各删一遍** —— 只处理 `ide_` 会让子项目那几份原样送到模型面前。
-  实测数字 (拿运行中的 IDE MCP 拉 `tools/list`,单个项目):IDE 暴露 **76** 个 → 隐藏 47 → **模型可见 29 个**,
-  而且这 29 个 **恰好等于引导里点名的 29 个** —— 没有"能看见但没人告诉它用途"的残留。多项目就是 N × 29:
+  实测数字 (拿运行中的 IDE MCP 拉 `tools/list`,单个项目):IDE 暴露 **76** 个 → 隐藏 49 → **模型可见 27 个**,
+  而且这 27 个 **恰好等于引导里点名的 27 个** —— 没有"能看见但没人告诉它用途"的残留。多项目就是 N × 29:
   暴露面完全由插件决定,不需要 OpenCode 提供任何白名单能力,也不需要惰性注册。
 
 - **部署工具只在 Ultimate 上出现**:`ide_list_deployment_servers` / `ide_upload_to_deployment` /

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-idea",
-  "version": "0.0.25",
+  "version": "0.0.27",
   "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",

package/skills/idea-run-config-manager/SKILL.md

@@ -31,7 +31,7 @@ IDE (或那个 IDE 没装 `idea-mcp-enhance`)—— 让用户执行 `/open-in-id
         - **看一眼**:`<前缀>_inspect_run_configuration` —— 定义、命名解析、活实例、历史日志路径全在里面;
           构建 patch 之前先用它拿到当前值 (尤其 `configurationXml`)。
         - **模板是字段参考**:`assets/types/*.md` 用来查类型 id、看这个类型有哪些字段、`configurationXml` 该长什么样。
-        - **建带平台 / 环境变体的配置** → 名字按模板「怎么读配置名」的文法拼 (`win@base` / `base@env`);环境具体怎么接上问
+        - **建带平台 / 环境变体的配置** → 名字文法见 IDE 引导的「运行配置」(`win@base` / `base@env`);环境具体怎么接上问
           用户,或照项目里现成的同类配置来。
         - **没有模板**(矩阵之外)→ **走 `cloneFrom`**:复制一个同类型的现成配置再 patch 它的字段。
           字段名不确定时,这是 **唯一可靠**的路子 (照猜字段名 = 静默用默认值)。连一个同类型的现成配置都没有,
@@ -71,5 +71,5 @@ IDE (或那个 IDE 没装 `idea-mcp-enhance`)—— 让用户执行 `/open-in-id
 3. **路径宏**:`$PROJECT_DIR$` = 该项目根。 **项目内的路径一律用它**(`$PROJECT_DIR$/子目录/...`),不要写本机绝对路径 ——
    写死了别人 clone 下来就指到不存在的目录。
 
-名字怎么读、变体怎么选、每条登记什么,都在 [assets/AGENTS.template.md](assets/AGENTS.template.md) 的「怎么读配置名」
-「怎么选变体」与生成提示里 —— 本文件不重复那套规则。
+名字怎么读、变体怎么选 —— 见 IDE 引导的「运行配置」(每次请求都在);每条登记什么,见
+[assets/AGENTS.template.md](assets/AGENTS.template.md) 的生成提示。两处都不在本文件重复。

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

@@ -21,8 +21,6 @@
 
 ## run configuration 一览
 
-**「怎么读配置名」与「怎么选变体」两节是固定文本,照抄,不要改写、不要删条目** —— 它们是读名字与选变体的规则,下面那个列表靠它们才成立。
-
 <!-- 生成提示:begin -->
 
 **先过滤**:服务化 / 常驻应用的配置 **一律不进本块**(它们归 `idea-standalone`,端口与热重载写在那边)。有
@@ -32,12 +30,9 @@
 目录的那些 —— 翻文件看不到)。 **项目与各子项目里真正存在的、过滤后剩下的都要有。**
 **项目写在条目开头的括号里**(那套工具的前缀:root 写 `ide`,子项目写它的目录名):一条配置属于谁、该用哪套工具去看和跑,
 由它决定。条目里的配置名必须是该前缀下 **真实存在的名字**,不凭印象写;块里有、项目里已经没有的 **整个条目删掉**。 **只登记
-base,变体不另起条目**:run configuration 的名字是 `[os@]base[@env]`,`@` 分割、最多三段 —— os 段 (`win` = Windows,缺省 =
-macOS/Linux)、
-base 段 (配置本体)、env 段 (环境名,缺省 = 默认环境)。`win@base` 与 `base@env` 都是 **同一个 base 的变体**:
-平台不同 / 环境不同,事情是同一件。 **本块只登记 base**(`{配置名}` 不带任何 `@` 段),变体不另起条目 ——
-把"有哪些变体"写进 base 的 `desc` 一条即可;判断某个变体在哪个平台成立 **看命令与脚本内容本身**(有 `\` 路径、调用
-`.bat`、依赖 Windows 专属工具的,就是 Windows), **判断不了就问用户**,不猜。
+base,变体不另起条目**:`{配置名}` 不带任何 `@` 段 —— 名字文法与变体怎么选见 IDE 引导的「运行配置」;有哪些变体写进 base 的
+`desc` 一条即可。判断某个变体在哪个平台成立 **看命令与脚本内容本身**(有 `\` 路径、调用 `.bat`、依赖 Windows 专属工具的,
+就是 Windows), **判断不了就问用户**,不猜。
 
 **when** 只写两种,先把是哪一种写明:**用户授权触发** → 用户开口 (或在本会话里授权) 之后 AI 才跑,后面写用户通常在
 什么情况下会要它跑 (发版前 / 出安装包 / 回归);**AI 自己触发** → AI 判断到场景就自己跑, **必须把场景写具体**(改完某类代码要
@@ -94,21 +89,6 @@ base 段 (配置本体)、env 段 (环境名,缺省 = 默认环境)。`win@base`
 `应用` / `端口` / `热重载`。 **五项始终都在**:真没有内容就写 **`无`** —— 不省略,也不写 `-` / `N/A`。
 <!-- 生成提示:end -->
 
-### 怎么读配置名
-
-run configuration 的名字是 `[os@]base[@env]`,`@` 分割、最多三段:`os` = `win`(缺省表示:macOS / Linux)、`base` = 配置本体
-(必填)、`env` = 环境名(缺省表示:默认环境)。`win@base`(换平台)与 `base@env`(换环境)都是 `base` 的 **变种**:
-同一件事,平台 / 环境不同。 **只登记 base**,变体不另起条目 —— 有哪些变体写进 base 的 `desc`。
-
-### 怎么选变体
-
-- **平台**:macOS / Linux 用 `base`,Windows 用 `win@base` —— `win@base` 不存在就 **交回用户**,别拿 base 顶替。
-- **环境**:不带 `@` 的那条就是 **默认环境**。一起起一批时 **逐条解析**:有 `base@<要的环境>` 就用它,没有就用默认;只有
-  `@env` 变体、没有默认版的,就用它自己那个 —— "10 个服务"可以是"3 个 `@dev` + 7 个默认",不必逐条问。
-- **一条配置同时有 `base` 与 `base@<env>`**、又没说走哪个环境 → **启动前问一次用户走哪个环境**;选定后本会话默认走这套,
-  别反复问 —— 改代码 → 自己重启 → 同一套变体。
-- 一个环境怎么接上 (启动参数 / 环境变量 / 配置文件) 是项目自己的事:照现成的同类变体来,或问用户。
-
 ### base 登记
 
 - {配置名} (项目 {前缀})

package/skills/idea-standalone/SKILL.md

@@ -24,8 +24,8 @@ description: "为项目固化 standalone(启动收口只有 IDEA run configurati
 - 读 `<项目根>/AGENTS.md`:有没有 `idea-standalone` 标记块 (有则更新,没有就在文件末尾追加)。
 - 枚举:该项目的 `<前缀>_get_run_configurations` 直接调用,不传任何参数 —— 它给出 IDE 真正认的配置,连同启动细节 (程序参数、
   工作目录、环境变量、能否启动时覆盖)。 **条目里的 base 名与端口只能来自这里**,不用再去项目目录逐个翻配置文件。
-- **一条配置一个条目**:带 `@` 段的配置一律 **取 base 部分登记**,变体不另起一条 —— 文法、选变体、每一项怎么写,全在模板的
-  「怎么读配置名」「怎么选变体」与生成提示里。
+- **一条配置一个条目**:带 `@` 段的配置一律 **取 base 部分登记**,变体不另起一条 —— 文法与选变体见 IDE 引导的「运行配置」,
+  每一项怎么写见模板的生成提示。
 
 **缺口**(端口、热重载、`应用` 各自怎么定,模板的生成提示里写了;拿不准就 **问用户**,不猜)
 
@@ -43,6 +43,5 @@ description: "为项目固化 standalone(启动收口只有 IDEA run configurati
 3. **新增**(文件里还没有标记块):在 `AGENTS.md` **末尾追加**标记块,文件既有内容原样保留;文件不存在则创建它。
    只替换标记内内容、不动标记外 —— 尤其 **不要触碰**其他 skill 的标记块 (例如 `project-scaffold`)。
 4. **更新**(已有标记块):只替换 `<!-- idea-standalone:begin -->` 与 `<!-- idea-standalone:end -->` 之间的内容,块外一字不动。
-5. 改文件用 **IDE 的编辑命令** `<前缀>_apply_patch`(新建用 `<前缀>_create_new_file`),不要用原生 `write` / `edit`。
-   **不要整文件重写**。
+5. 改文件用原生 `edit` 替换标记块里那一段; **不要整文件重写**。
 6. 复读并核对:标记块内逐段与模板一致,块外内容与改动前逐字一致,报告产物清单。

package/skills/idea-standalone/assets/AGENTS.template.md

@@ -38,15 +38,12 @@ skill 一律不动。
 
 ## 二、standalone 下启动哪些应用 (必须经 IDEA run configuration)
 
-**「怎么读配置名」与「怎么选变体」两节是固定文本,照抄,不要改写、不要删条目** —— 它们是读名字与选变体的规则,下面那个列表靠它们才成立。
-
 <!-- 生成提示:begin -->
 
 一条一个 **run configuration**(服务化 / 常驻的那种)—— **应用只是它的一个属性**:同一个应用有多条配置 (前端 dev server +
 后端服务)就写多条,别合并成一条。 **括号里的项目是这条配置的归属**(root 写 `ide`,子项目写它的目录名):配置可能住在子项目
-里,跑它就用 **那个前缀**的工具 —— 拿不准就问用户。 **条目开头的名字填真实 base 名**(不带任何 `@` 段),平台与环境由名字里
-的段决定,见上面「怎么读配置名」。
-**变体不另起一条**:`win@base`(换平台)、`base@env`(换环境)都是同一个 base 的变种,写一条就够,怎么选走「怎么选变体」那节。
+里,跑它就用 **那个前缀**的工具 —— 拿不准就问用户。 **条目开头的名字填真实 base 名**(不带任何 `@` 段)—— 名字文法与变体怎么选
+见 IDE 引导的「运行配置」。 **只登记 base,变体不另起一条**:写一条 base 就够,有哪些变体写进 `desc`。
 
 **下面是两个示例**,照这个形状写 —— 一条把长的地方展开,一条全是短句 (生成产物时把示例删掉):
 
@@ -94,21 +91,6 @@ skill 一律不动。
 `AGENTS.md` 里,名字与顺序对上了才看得出哪些是服务、哪些是固定流程。 **某项确实没有内容就写 `无`**(不省略、也不写 `-`)。
 <!-- 生成提示:end -->
 
-### 怎么读配置名
-
-run configuration 的名字是 `[os@]base[@env]`,`@` 分割、最多三段:`os` = `win`(缺省表示:macOS / Linux)、`base` = 配置本体
-(必填)、`env` = 环境名(缺省表示:默认环境)。`win@base`(换平台)与 `base@env`(换环境)都是 `base` 的 **变种**:
-同一件事,平台 / 环境不同。 **只登记 base**,变体不另起条目 —— 有哪些变体写进 base 的 `desc`。
-
-### 怎么选变体
-
-- **平台**:macOS / Linux 用 `base`,Windows 用 `win@base` —— `win@base` 不存在就 **交回用户**,别拿 base 顶替。
-- **环境**:不带 `@` 的那条就是 **默认环境**。一起起一批时 **逐条解析**:有 `base@<要的环境>` 就用它,没有就用默认;只有
-  `@env` 变体、没有默认版的,就用它自己那个 —— "10 个服务"可以是"3 个 `@dev` + 7 个默认",不必逐条问。
-- **一条配置同时有 `base` 与 `base@<env>`**、又没说走哪个环境 → **启动前问一次用户走哪个环境**;选定后本会话默认走这套,
-  别反复问 —— 改代码 → 自己重启 → 同一套变体。
-- 一个环境怎么接上 (启动参数 / 环境变量 / 配置文件) 是项目自己的事:照现成的同类变体来,或问用户。
-
 ### 服务化配置
 
 一条一个 run configuration;`应用` 是它的属性 —— 同一个应用可以有多条配置。括号里的项目是它的归属:跑这条配置,用那个项目

package/src/ide-guidance.template.md

@@ -23,8 +23,11 @@
   也不要用 Code Mode 的 `search` 去找 (它们不在那份目录里,搜不到)。
 - **只有 IDE 才有的能力才用它们**:符号级检索、项目模型、检查与构建、重构与格式化、run configuration。
 - **读与搜索用原生工具**(`read` / `grep` / `glob`):不要为读一个文件、搜一段文本去绕 IDE 工具。
-- **改项目代码用 IDE 的编辑命令**(`<前缀>_apply_patch`,新建文件用 `<前缀>_create_new_file`),不要用原生 `write` / `edit` ——
-  那两个在进程外写,IDE 手里可能还是旧内容,紧接着的 IDE 侧工具会基于旧代码干活。项目目录之外的文件才用原生那两个。
+- **改文件一律用原生 `write` / `edit`** —— 不受补丁上下文匹配的限制(IDE 那个补丁工具按上下文精确匹配,标点被规范化就
+  整块对不上,已经收起不用)。IDE 侧的写操作只留 **重构**与**格式化**两件事。
+- **`reformat_file` 会从磁盘重读**,外部写完直接格式化是安全的(实测:新增 / 删除 / 改文本都不会被冲掉)。
+- **文档类文件 (Markdown / 文档) 改完之后,用 `<前缀>_reformat_file` 过一遍** —— 表格对齐、换行宽度、缩进都交给 IDE
+  统一,别手搓空格。
 - **改完代码自己先查一遍**:用 `lint_files` / `build_project`,怎么挑见下面「校验」。
 - 某条功能下面没有你正要操作的那个项目的命令,就是那个项目没接上:提示用户执行 `/open-in-ide`,不要重试,也不要去别处找。
 
@@ -79,13 +82,8 @@
 - {{cmd_get_all_open_file_paths}} **用户在 IDE 里打开了哪些文件**(含当前激活的那个)。
 - {{cmd_open_file_in_editor}} **把文件在 IDE 里打开并激活**,给用户看。
 
-### 改代码 (编辑 · 重构 · 校验)
+### 改代码 (重构 · 格式化 · 校验)
 
-- {{cmd_apply_patch}} **走 IDE 改文件**:`input` 传补丁 (两种格式都行 —— Codex 的 `*** Begin Patch` /
-  `*** Update File: <路径>` / `@@` / `*** End Patch`,或 unified git diff)。一个补丁里可混着 **Add / Update / Delete**
-  多个操作,`Update` 还能带 `*** Move to: <新路径>` 改名; **按上下文匹配**,`@@` 不用写行号。返回
-  `N out of M operations applied`,对不上的 hunk 会报 `Hunk context not found`。路径必须在项目内。
-- {{cmd_create_new_file}} **新建文件**:`pathInProject` + `text`;父目录自动建,`overwrite` 默认关 (文件已存在会报错)。
 - {{cmd_rename_refactoring}} **按符号改名**,项目内的引用一并更新。
 - {{cmd_reformat_file}} **按 IDE 的代码风格重排**。
 - {{cmd_lint_files}} **批量检查**:`files` 传数组;只列有问题的文件。
@@ -158,6 +156,15 @@
   有没有热重载都一样;读 `started` 判断新进程是否真的起来了。这次运行的输出在 `output`,完整日志文件路径在
   `fullOutputPath`。不要用 `pkill` / `kill` / `shell` 代替。
   {{/if}}
+
+**配置名怎么读**:`[os@]base[@env]`,`@` 分割、最多三段 —— `os` = `win`(缺省 macOS / Linux)、`base` = 配置本体(必填)、
+`env` = 环境名(缺省 = 默认环境)。`win@base`(换平台)与 `base@env`(换环境)都是 `base` 的 **变体**,跑哪一个:
+
+- **平台**:macOS / Linux 用 `base`,Windows 用 `win@base` —— `win@base` 不存在就 **交回用户**,别拿 base 顶替。
+- **环境**:不带 `@` 的就是 **默认环境**。一批一起起时 **逐条解析**:有 `base@<要的环境>` 就用它,没有就用默认;只有 `@env`
+  变体、没有默认版的,就用它自己那个 —— "10 个服务"可以是"3 个 `@dev` + 7 个默认",不必逐条问。
+- 一条配置同时有 `base` 与 `base@<env>`、又没说走哪个环境 → **问一次走哪个环境**,选定后本会话默认走这套,别反复问。
+- 一个环境怎么接上(启动参数 / 环境变量 / 配置文件)是项目自己的事:照现成的同类变体来,或问用户。
   {{#if canListDeploymentServers}}
 
 ### 服务器文件同步

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.0.25' },
+        clientInfo: { name: 'opencode-idea', version: '0.0.27' },
       },
     });
     // The IDE's Streamable-HTTP endpoint binds follow-up requests to the session

package/src/plugin.js

@@ -151,16 +151,18 @@ const PLUGIN_TOOL_NAMES = new Set(['configure_ide_project']);
  *   it is the only way to read a file inside a jar (`<jar>!/<entry>`) or the
  *   JDK's `jrt://` image, so the guidance keeps it for exactly that and sends
  *   ordinary reads to the native tool.
- * - Plain file **write**: `apply_patch` / `create_new_file` are **kept**, and
- *   they are the ones the guidance sends writes to. The native `write` / `edit`
- *   write from **outside** the IDE, and the IDE keeps an in-memory copy of every
- *   file it has open — that copy is only re-read when the VFS refreshes, so
- *   between the write and the refresh the IDE still sees the OLD text. Measured
- *   against a real IDE: after an external write, `read_file` still returned the
- *   old content; after `apply_patch` it returned the new one immediately. That
- *   gap is not cosmetic — `reformat_file` formats the in-memory copy and
- *   **writes it back**, silently discarding whatever was just written. Writing
- *   through the IDE (`apply_patch`) keeps the two copies the same thing.
+ * - Plain file **write**: `apply_patch` / `create_new_file` are **hidden** too.
+ *   Writes go through the native `write` / `edit`: they are simpler, and the
+ *   IDE's patch tool is brittle in a way that costs real time — it matches hunks
+ *   by exact context text, so a quote or a corner bracket normalised somewhere
+ *   on the way in fails the whole hunk (`Hunk context not found`).
+ *   Measured against a real IDE, the stale-copy concern does not justify keeping
+ *   them: `reformat_file` re-reads from disk (append / delete / edit all survived
+ *   it), and `apply_patch` is not what made the in-memory copy fresh — only
+ *   `ide_read_file` lags behind an external write, and the guidance tells the
+ *   model to read ordinary files with the native `read` anyway.
+ *   `rename_refactoring` and `reformat_file` stay: both are capabilities the
+ *   native tools do not have.
  * - IDE terminal: `execute_terminal_command` does NOT inherit the project's
  *   environment. It was exposed on the assumption that it ran with the SDKs the
  *   user configured in the IDE (JDK, Node, Python, ...), but measured against a
@@ -232,11 +234,12 @@ export const HIDDEN_IDE_TOOL_SUFFIXES = [
     'search_text',
     'search_regex',
     'search_file',
-    // The companion plugin's own write tool. The IDE's built-in `apply_patch` /
-    // `create_new_file` already cover writing through the IDE, so this one is
-    // hidden: two tools for the same job is a worse answer than one. The plugin
-    // has dropped it as well — this line only hides the copies still served by
-    // the plugin version installed before that.
+    // File WRITE: the native `write` / `edit` do the job, and the IDE's patch
+    // tool matches hunks by exact context text (a normalised quote fails the
+    // hunk). `edit_file` is the companion plugin's own writer, dropped by the
+    // plugin itself — hiding it only covers the older installed copies.
+    'apply_patch',
+    'create_new_file',
     'edit_file',
 ];