opencode-idea 0.0.26 → 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +247 -392
- package/package.json +1 -1
- package/skills/idea-standalone/SKILL.md +1 -2
- package/src/ide-guidance.js +14 -2
- package/src/ide-guidance.template.md +90 -78
- package/src/mcp/idea.js +1 -1
- package/src/plugin.js +33 -15
package/package.json
CHANGED
|
@@ -43,6 +43,5 @@ description: "为项目固化 standalone(启动收口只有 IDEA run configurati
|
|
|
43
43
|
3. **新增**(文件里还没有标记块):在 `AGENTS.md` **末尾追加**标记块,文件既有内容原样保留;文件不存在则创建它。
|
|
44
44
|
只替换标记内内容、不动标记外 —— 尤其 **不要触碰**其他 skill 的标记块 (例如 `project-scaffold`)。
|
|
45
45
|
4. **更新**(已有标记块):只替换 `<!-- idea-standalone:begin -->` 与 `<!-- idea-standalone:end -->` 之间的内容,块外一字不动。
|
|
46
|
-
5.
|
|
47
|
-
**不要整文件重写**。
|
|
46
|
+
5. 改文件用原生 `edit` 替换标记块里那一段; **不要整文件重写**。
|
|
48
47
|
6. 复读并核对:标记块内逐段与模板一致,块外内容与改动前逐字一致,报告产物清单。
|
package/src/ide-guidance.js
CHANGED
|
@@ -11,8 +11,20 @@
|
|
|
11
11
|
// 1. Per tool: what it does, its parameters, and the positive flow for using
|
|
12
12
|
// it. No caveats or edge cases, and nothing about languages or frameworks —
|
|
13
13
|
// the project's own setup decides that.
|
|
14
|
-
// 2.
|
|
15
|
-
// stay on the native tools.
|
|
14
|
+
// 2. What the NATIVE tools cannot do, or do badly, is what gets routed here;
|
|
15
|
+
// reading, writing and searching stay on the native tools.
|
|
16
|
+
//
|
|
17
|
+
// Rule 2 used to read "only IDE-only capability" — but "IDE-only" is not a
|
|
18
|
+
// property of the tool, it is a property of the MODEL: OpenCode's own
|
|
19
|
+
// multi-file `patch` exists, it is just only exposed to GPT models, so on
|
|
20
|
+
// any other model `apply_patch` is the only multi-file writer there is. The
|
|
21
|
+
// question to ask is therefore not "does the native tool exist" but "can the
|
|
22
|
+
// native tool do this well here".
|
|
23
|
+
//
|
|
24
|
+
// The document is organised by THAT question, and the first section answers
|
|
25
|
+
// it by scope: inside a project the native tools lead and the IDE tools fill
|
|
26
|
+
// the gaps; outside a project the IDE tools do not apply at all (the IDE
|
|
27
|
+
// only resolves paths inside an opened project and errors on anything else).
|
|
16
28
|
//
|
|
17
29
|
// 校验 (lint / build) is one place that also carries a *when*, because the tools
|
|
18
30
|
// are not there to be offered — they are there to be used unprompted, and the
|
|
@@ -1,15 +1,14 @@
|
|
|
1
|
-
# IDE MCP
|
|
1
|
+
# IDE MCP:OpenCode 自带工具的补充
|
|
2
2
|
|
|
3
|
-
本会话接入了 {{projectCount}} 个 JetBrains
|
|
4
|
-
`<项目前缀>_
|
|
3
|
+
本会话接入了 {{projectCount}} 个 JetBrains 项目。**每个功能在所有项目下都各有一份工具**,命令名是
|
|
4
|
+
`<项目前缀>_<工具名>`;下文写 `<前缀>` 就是指这一截。
|
|
5
5
|
|
|
6
6
|
## 本会话接入的项目与各自的 MCP 工具
|
|
7
7
|
|
|
8
8
|
{{routeTable}}
|
|
9
9
|
|
|
10
10
|
**子项目就是根目录下的目录**,只是被另一个 IDE 单独打开、配了另一套工具。所以这里说的"根项目",指的是
|
|
11
|
-
|
|
12
|
-
就用根项目的工具。
|
|
11
|
+
**根目录中扣掉这些子项目之后的部分**。
|
|
13
12
|
|
|
14
13
|
**规则:操作哪个目录下的文件/代码,就用那个目录对应的命令。** IDE 是按项目解析的 —— 跨项目调用要么直接报错,
|
|
15
14
|
要么被解析到另一个项目上、作用在错误的代码上。
|
|
@@ -17,32 +16,41 @@
|
|
|
17
16
|
按需读文件:要了解某个子项目自己的约定,读它的 `<子项目目录>/AGENTS.md`(它不会自动进入本会话的上下文,
|
|
18
17
|
本会话是 root 打开的那一个)。
|
|
19
18
|
|
|
19
|
+
## 路由:先看路径在不在项目里
|
|
20
|
+
|
|
21
|
+
**IDE 工具只在项目内有意义。** 请求的路径必须落在**某个已打开项目**的目录树内,IDE 才会去解析它;
|
|
22
|
+
项目外的路径(`/tmp`、别的仓库、用户主目录)两个 IDE 都会直接报错。
|
|
23
|
+
|
|
24
|
+
- **项目内** —— **OpenCode 自带的工具为主**,它们更快。**它们做不了、或者做得很差的,才用 IDE 工具**:
|
|
25
|
+
符号检索、依赖实现、重构、格式化、校验、运行配置、跨文件补丁。
|
|
26
|
+
**两边都不顺手时,你自己判断用 `shell` 里的命令** —— 那是第三选择,不是第一选择。
|
|
27
|
+
- **项目外** —— 只有 OpenCode 自带的工具。IDE 工具在这里不参与(会报错),别去试。
|
|
28
|
+
|
|
20
29
|
## 总则 (所有项目通用)
|
|
21
30
|
|
|
22
|
-
-
|
|
23
|
-
|
|
24
|
-
-
|
|
25
|
-
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
31
|
+
- **OpenCode 自带的工具直接调用** —— 工具列表里直接列出的那些(`read` / `grep` / `glob` / `edit` / `write` / `shell`),
|
|
32
|
+
参数按各自 schema 传。不要包进 `execute`,也不要用 Code Mode 的 `search` 去找(它们不在那份目录里,搜不到)。
|
|
33
|
+
- **读文件用 `read` 工具** —— 要读某一段就传 `offset`(从第几行起)+ `limit`(读几行),别用 `shell` 里的 `sed -n`。
|
|
34
|
+
- **搜文本用 `grep` 工具** —— 它按 `.gitignore` 排除,`node_modules` / `dist` 不进结果,范围用 `path` 收窄。
|
|
35
|
+
别用 `shell` 里的 `grep` / `rg` / `find`:那些不看 `.gitignore`,还跟着符号链接扫进依赖包,慢且全是噪音。
|
|
36
|
+
- **改文件**:改一个符号用 `<前缀>_rename_refactoring`;改一段文字用 `edit` / `write` 工具;
|
|
37
|
+
同一段文字铺到多个文件用 `<前缀>_apply_patch`;跑命令用 `shell` 工具。
|
|
38
|
+
**别在 `shell` 里写脚本改代码** —— 脚本会把没让改的地方也重排掉,还可能覆盖掉别人的改动。
|
|
39
|
+
- **改完代码自己先查一遍**:`lint_files` / `build_project`,怎么挑见「校验」。
|
|
40
|
+
- **文档类文件 (Markdown / 文档) 改完之后,用 `<前缀>_reformat_file` 过一遍** —— 表格对齐、换行宽度、缩进都交给 IDE
|
|
41
|
+
统一,别手搓空格。它从磁盘重读,外部写完直接格式化是安全的。
|
|
29
42
|
- 某条功能下面没有你正要操作的那个项目的命令,就是那个项目没接上:提示用户执行 `/open-in-ide`,不要重试,也不要去别处找。
|
|
30
43
|
|
|
31
44
|
## 命令执行 (所有项目通用)
|
|
32
45
|
|
|
33
|
-
-
|
|
34
|
-
|
|
35
|
-
- **需要项目环境才跑得起来的命令**(依赖 IDE 里配好的 JDK / Node / Python 版本等):先看有没有现成的 run configuration ——
|
|
36
|
-
有就跑它 (常驻用 `rerun`,跑完即退用 `execute`);没有、又只是一次性的命令,用原生 `shell` 并显式指定解释器,
|
|
46
|
+
- **跑命令用 `shell` 工具**;要项目环境的(IDE 里配好的 JDK / Node / Python 等)先看有没有现成的 run configuration ——
|
|
47
|
+
有就跑它 (常驻用 `rerun`,跑完即退用 `execute`);没有、又只是一次性的,用 `shell` 工具并显式指定解释器,
|
|
37
48
|
**不要为它新建配置**。
|
|
38
|
-
-
|
|
49
|
+
- **建 / 改 / 删运行配置,走 `idea-run-config-manager` skill**(服务化应用的配置归 `idea-standalone`):
|
|
50
|
+
它落手用的就是「运行配置」里的那组工具。 **不要自己写文件、也不要自己删文件**。
|
|
39
51
|
{{#if canCreateRunConfiguration}}
|
|
40
|
-
- **建 / 改 / 删运行配置,走 `idea-run-config-manager` skill**(服务化应用的配置归 `idea-standalone`):要不要建、建什么、
|
|
41
|
-
怎么建、建完档案怎么记,全由它管;它落手用的就是「运行配置」里的那组工具。 **不要自己写文件、也不要自己删文件**。
|
|
42
52
|
{{else}}
|
|
43
|
-
|
|
44
|
-
档案怎么记由它管;本会话没有新建工具,"建"这一步它只能讲清配置名、实际执行的命令、工作目录、为什么值得留,
|
|
45
|
-
**请用户在 IDE 里创建**
|
|
53
|
+
本会话没有新建工具,"建"这一步它只能讲清配置名、实际执行的命令、工作目录、为什么值得留, **请用户在 IDE 里创建**
|
|
46
54
|
{{/if}}
|
|
47
55
|
|
|
48
56
|
## 工具 (每条第一行是各项目的命令,接着是它的用法)
|
|
@@ -51,21 +59,21 @@
|
|
|
51
59
|
|
|
52
60
|
**要读任何类 / 方法 / 字段的源码,就两步**:`<前缀>_search_symbol`(`q` 传名字, **带 `include_external: true`**)找到位置 →
|
|
53
61
|
`<前缀>_read_file` 原样读它给的路径。 **依赖库 / 三方包 / 平台 jar 里的实现**正是它最该用的场合 —— IDE 索引里那份就是项目
|
|
54
|
-
编译时真正用的依赖 (`javap` / 解包 jar /
|
|
62
|
+
编译时真正用的依赖 (`javap` / 解包 jar / 用 `shell` 里的 `grep` 按 jar 路径拼出来的往往是另一份,版本对不上),读出来还是反编译源码。
|
|
55
63
|
|
|
56
|
-
- {{cmd_search_symbol}} **`q` 传查询文本,固定带上 `include_external: true`。**
|
|
57
|
-
|
|
58
|
-
`grep`
|
|
64
|
+
- {{cmd_search_symbol}} **`q` 传查询文本,固定带上 `include_external: true`。** **本插件最不可替代的能力**在于它搜的是**符号**
|
|
65
|
+
(类 / 接口 / 方法 / 函数 / 字段 / 类型 / 常量这类 **有名字的定义**)的**声明位置**,不是"哪段文本提到过它"(那是
|
|
66
|
+
`grep` 工具的事);带上 `include_external` 才会连依赖库和标准库一起搜 —— 这是 `grep` / `glob` 工具够不着的地方。
|
|
59
67
|
- **查某个库的 API**:代码里 import 的包名就是线索,直接「包名 + 符号名」当 `q` —— Java 用全限定名
|
|
60
68
|
(`com.nimbusds.jose.util.Base64`)、Go 用 `pkg.Symbol`(`gorm.DeletedAt`)、Python 给全模块路径
|
|
61
|
-
(`torch.nn.Module`)、Node/TS 用 import 的那层包名(`vue.Teleport`)
|
|
62
|
-
|
|
69
|
+
(`torch.nn.Module`)、Node/TS 用 import 的那层包名(`vue.Teleport`)。**调研一个库有哪些 API**:拿包名当 `q`
|
|
70
|
+
(`fastapi` → 入口文件就是导出清单),再读它的入口。
|
|
63
71
|
- **Node/TS 例外**:带 `-` 或 `@scope/` 的包名这么拼是 0 条(`element-plus`);改用 import 的符号名,并用 `paths` 圈到
|
|
64
72
|
那个 `node_modules`(`paths: ['frontend/user/**']` 就收敛到一处)。
|
|
65
73
|
- **搜不到 = 依赖没进来**:先把它加进依赖,或改用 web 搜索 / GitHub 看源码;别反复换写法试。
|
|
66
74
|
- **同名符号往往有多处定义**(标准库 / 依赖 / 测试各一份):按调用处的 import 与参数类型选,别拿第一行当答案。
|
|
67
|
-
- **它返回的路径原样交给同一个项目的 `<前缀>_read_file`**
|
|
68
|
-
|
|
75
|
+
- **它返回的路径原样交给同一个项目的 `<前缀>_read_file`** —— 那个路径的基准是**它所在的项目**,不是会话工作目录,
|
|
76
|
+
**别交给 `read` 工具**:子项目的相对路径会落到错的位置。
|
|
69
77
|
- **依赖索引是按项目的**:用 **它所在项目** 前缀的工具搜,拿别的项目的工具搜不到库。
|
|
70
78
|
- {{cmd_get_symbol_info}} **一个符号的签名 / 文档 / 声明位置**:`filePath` + `line` + `column`。
|
|
71
79
|
- {{cmd_analyze_calls}} **调用关系**:`symbolFqn` 传符号名,`analysisKind` 取 `INCOMING_CALLS` / `OUTGOING_CALLS`;`depth`
|
|
@@ -79,21 +87,37 @@
|
|
|
79
87
|
- {{cmd_get_all_open_file_paths}} **用户在 IDE 里打开了哪些文件**(含当前激活的那个)。
|
|
80
88
|
- {{cmd_open_file_in_editor}} **把文件在 IDE 里打开并激活**,给用户看。
|
|
81
89
|
|
|
82
|
-
###
|
|
90
|
+
### 读文件
|
|
91
|
+
|
|
92
|
+
- {{cmd_read_file}} **按项目解析路径读文件** —— 普通文件用 `read` 工具就够,它只在三种情况下用得着:
|
|
93
|
+
`search_symbol` 返回的路径(它的基准是那个项目,不是会话工作目录);**压缩包内的条目**(`read` 工具打不开压缩包,
|
|
94
|
+
而它还能把 `.class` **反编译成源码**);路径按那个项目解析更省事的时候。
|
|
95
|
+
压缩包路径两种写法:`<路径>.jar!/<条目>`(相对或绝对都行)或 `jar://<**绝对**路径>.jar!/<条目>`(`jar://` 只认绝对路径)。
|
|
96
|
+
|
|
97
|
+
### 改代码 (重构 · 格式化 · 补丁 · 校验)
|
|
83
98
|
|
|
84
|
-
- {{
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
-
|
|
89
|
-
|
|
99
|
+
- {{cmd_rename_refactoring}} **改一个符号(变量 / 函数 / 类 / 字段 / 方法),哪怕散落在几十个文件里,优先用它** ——
|
|
100
|
+
它按**语义**更新所有**真引用**:跨文件一起改,类名连**文件名**一起改。
|
|
101
|
+
- **它只改代码**:注释、字符串字面量、别的语言的同名符号原样不动 —— 拿 `edit` / `apply_patch` 工具去改名,
|
|
102
|
+
会把这些一起改掉,那是改了程序的输出。
|
|
103
|
+
- 返回里 `with N usages` 的 N 是**真引用数**;比预期少,说明有引用没被解析到(文件没进 IDE 索引),
|
|
104
|
+
这时**先确认索引到那个模块**,别拿 `edit` 工具去"补"。
|
|
105
|
+
- 反过来也有该用 `edit` / `write` / `apply_patch` 工具的场合:改的本来就是文字(配置 key、模板占位符、文档、SQL)、
|
|
106
|
+
**你就是想改那句字符串**、或者那个文件 IDE 根本没索引(生成物、vendor 目录)。这时先用 `grep` 工具确认命中范围。
|
|
90
107
|
- {{cmd_reformat_file}} **按 IDE 的代码风格重排**。
|
|
108
|
+
- {{cmd_apply_patch}} **一次改多个文件**:`input` 传补丁正文,Codex 格式(`*** Begin Patch` / `*** Update File: <路径>`
|
|
109
|
+
/ `@@` / `-` 旧行 / `+` 新行)与 unified git diff 都收。`edit` / `write` 工具都只管一个文件。
|
|
110
|
+
- 它**按文本**改,适合同一段文字铺到多个文件;**改符号走上面那条**。
|
|
111
|
+
- 它**只碰补丁里写明的那几行**,不会重排你没让改的地方。
|
|
112
|
+
- 上下文对不上时那一个 hunk 失败、**该文件原样不动**,返回里点名是哪个文件(`<路径>: Hunk context not found`)。
|
|
113
|
+
- 多个文件是**逐个应用**的:返回里 `N out of M operations applied`,失败的那些读一下再改;
|
|
114
|
+
改完用 `grep` 工具确认落盘,别只信成功数。
|
|
91
115
|
- {{cmd_lint_files}} **批量检查**:`files` 传数组;只列有问题的文件。
|
|
92
116
|
- {{cmd_get_file_problems}} **单文件检查**:`filePath`;结果在 `errors`。
|
|
93
117
|
- {{cmd_build_project}} **构建校验**:`filesToRebuild` 可只构建指定文件;有问题返回在 `problems`,没返回即没问题。
|
|
94
118
|
|
|
95
|
-
**改完代码,自己先查一遍再收尾。**
|
|
96
|
-
|
|
119
|
+
**改完代码,自己先查一遍再收尾。** 查一次很便宜,而问题一旦漏到用户看见、或留到构建 / 测试炸了才暴露,回头纠正的
|
|
120
|
+
代价就高一个量级。 **别把校验整段省掉。** 但也不是每步都查 —— 查太勤和压根不查一样是错的,而"这一轮属于哪一种"只有你自己知道。
|
|
97
121
|
|
|
98
122
|
- **这次要改一大片**(多文件、跨模块、"顺手把这几处一起对齐")→ 全部改完再 `build_project` 一次。中途不查:
|
|
99
123
|
半成品状态下的检查结果只会误导你。
|
|
@@ -102,14 +126,8 @@
|
|
|
102
126
|
- **改了签名 / 接口 / import / 依赖**这类"别处会跟着坏"的地方 → 走 `build_project`;只动了文件内部的实现 →
|
|
103
127
|
lint 就够。
|
|
104
128
|
- 查出来的问题 **改掉,或说清为什么不改**,别把没处理的问题原样交给用户。
|
|
105
|
-
- 校验走上面这些工具,
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
### 读压缩包内的东西
|
|
109
|
-
|
|
110
|
-
- {{cmd_read_file}} **压缩包内的条目**只有它能读 —— 原生 `read` 打不开压缩包,而它还能把 `.class` **反编译成源码**
|
|
111
|
-
。两种路径写法:
|
|
112
|
-
`<路径>.jar!/<条目>`(相对或绝对都行)或 `jar://<**绝对**路径>.jar!/<条目>`(`jar://` 只认绝对路径);「符号」那条搜出来的路径原样传即可。
|
|
129
|
+
- 校验走上面这些工具, **不要用 `shell` 里临时编一遍代替**;也别先猜"索引还没同步 / 那个环境是另一个进程"就绕开 ——
|
|
130
|
+
先调一次,它真看不到会明说。
|
|
113
131
|
|
|
114
132
|
### 运行配置
|
|
115
133
|
|
|
@@ -118,46 +136,40 @@
|
|
|
118
136
|
存在 IDE 自己存储里 (不在项目目录)的那些,翻文件是看不到的。
|
|
119
137
|
- {{cmd_execute_run_configuration}} **跑已有配置**:配置里的 `EXECUTE_IN_TERMINAL` 要是 `false`(共享出去的配置都这样)
|
|
120
138
|
;覆盖参数 (`programArguments` / `workingDirectory` / `envs`)需配置支持 `supportsDynamicLaunchOverrides`,否则会直接报错。
|
|
121
|
-
|
|
139
|
+
{{#if canCreateRunConfiguration}}
|
|
122
140
|
- {{cmd_create_run_configuration}} **新建任意类型的项目级配置**:内容来源三选一 —— `cloneFrom`(复制一个现成的,最稳;
|
|
123
141
|
字段名不确定时只走它)、`configurationXml`(模板里的 XML 片段)、平台模板 + `options` / `attributes` / `envs` 补丁。
|
|
124
|
-
它是 **项目资产**,不是"跑命令"的手段 ——
|
|
125
|
-
|
|
126
|
-
|
|
142
|
+
它是 **项目资产**,不是"跑命令"的手段 —— 只是要跑一条命令就用 `shell` 工具。
|
|
143
|
+
**要不要建、建什么、怎么建、档案怎么记,全按上面那个 skill 走。** 判据只有一条: **这件事以后会不会以同样的形态再发生?**
|
|
144
|
+
会 (改表后同步 DDL、跑迁移、生成代码、打包、起 dev server、往某个环境部署这类)就 **主动提**一次
|
|
127
145
|
"要不要固化成 run configuration",并把配置名 / 类型 / 命令 / 工作目录 / 为什么值得留摊开;不会 (查条数据、看个日志、
|
|
128
|
-
试一条命令)
|
|
129
|
-
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
- **改完别忘了同步档案**:新增 / 删除 / 改名之后,用 `idea-run-config-manager` skill 更新 `AGENTS.md` 里的档案块 ——
|
|
133
|
-
档案和项目里的配置对不上,比没有档案更糟。
|
|
134
|
-
{{/if}}
|
|
135
|
-
{{#if canInspectRunConfiguration}}
|
|
146
|
+
试一条命令)就用 `shell` 工具跑完算,别给项目留垃圾。
|
|
147
|
+
**改完别忘了同步档案**:新增 / 删除 / 改名之后按 skill 更新 `AGENTS.md` 里的档案块 —— 档案和项目里的配置对不上,比没有档案更糟。
|
|
148
|
+
{{/if}}
|
|
149
|
+
{{#if canInspectRunConfiguration}}
|
|
136
150
|
- {{cmd_inspect_run_configuration}} **看一个配置的全貌**:定义 (options / envs / before-launch)、命名解析 (`win` /
|
|
137
151
|
mac-linux、base、env)、当前活实例、历史运行及各自的日志文件路径。 **改之前先用它拿当前值**;服务起没起来想看日志,先用
|
|
138
152
|
`list_running_configurations` 的 `logFile`,要翻"上一次为什么挂了"再走这里。
|
|
139
|
-
|
|
140
|
-
|
|
153
|
+
{{/if}}
|
|
141
154
|
{{#if canUpdateRunConfiguration}}
|
|
142
|
-
|
|
143
155
|
- {{cmd_update_run_configuration}} **改字段或改名**:`options` / `envs` / `attributes` 是补丁 (`null` = 删),`newName` 改名并
|
|
144
156
|
**连带更新别人对它的引用**、迁移历史日志。改之前先 `inspect` 拿 `configurationXml` 与当前值。
|
|
145
|
-
|
|
146
|
-
|
|
157
|
+
{{/if}}
|
|
158
|
+
{{#if canDeleteRunConfiguration}}
|
|
147
159
|
- {{cmd_delete_run_configuration}} **删配置**:在跑或被人引用时拒绝;`force = true` 才会连引用一起清掉。
|
|
148
|
-
|
|
149
|
-
|
|
160
|
+
{{/if}}
|
|
161
|
+
{{#if canListRunningConfigurations}}
|
|
150
162
|
- {{cmd_list_running_configurations}} **当前真正在跑的配置**(几个实例 / 各自 pid / 退出码,每个实例还带自己的日志文件路径
|
|
151
163
|
`logFile`):停 / 重启前后都先用它看状态。
|
|
152
|
-
|
|
153
|
-
|
|
164
|
+
{{/if}}
|
|
165
|
+
{{#if canStopRunConfiguration}}
|
|
154
166
|
- {{cmd_stop_run_configuration}} **停掉该配置的全部实例并等它们退出**:没在跑也返回成功。
|
|
155
|
-
|
|
156
|
-
|
|
167
|
+
{{/if}}
|
|
168
|
+
{{#if canRerunRunConfiguration}}
|
|
157
169
|
- {{cmd_rerun_run_configuration}} **启动 / 重启常驻进程**:在跑就重启、没在跑就启动 —— 改完代码要重启就直接用它,
|
|
158
170
|
有没有热重载都一样;读 `started` 判断新进程是否真的起来了。这次运行的输出在 `output`,完整日志文件路径在
|
|
159
171
|
`fullOutputPath`。不要用 `pkill` / `kill` / `shell` 代替。
|
|
160
|
-
|
|
172
|
+
{{/if}}
|
|
161
173
|
|
|
162
174
|
**配置名怎么读**:`[os@]base[@env]`,`@` 分割、最多三段 —— `os` = `win`(缺省 macOS / Linux)、`base` = 配置本体(必填)、
|
|
163
175
|
`env` = 环境名(缺省 = 默认环境)。`win@base`(换平台)与 `base@env`(换环境)都是 `base` 的 **变体**,跑哪一个:
|
|
@@ -167,7 +179,7 @@
|
|
|
167
179
|
变体、没有默认版的,就用它自己那个 —— "10 个服务"可以是"3 个 `@dev` + 7 个默认",不必逐条问。
|
|
168
180
|
- 一条配置同时有 `base` 与 `base@<env>`、又没说走哪个环境 → **问一次走哪个环境**,选定后本会话默认走这套,别反复问。
|
|
169
181
|
- 一个环境怎么接上(启动参数 / 环境变量 / 配置文件)是项目自己的事:照现成的同类变体来,或问用户。
|
|
170
|
-
|
|
182
|
+
{{#if canListDeploymentServers}}
|
|
171
183
|
|
|
172
184
|
### 服务器文件同步
|
|
173
185
|
|
|
@@ -177,17 +189,17 @@ IDE 在管的那一份。
|
|
|
177
189
|
- {{cmd_list_deployment_servers}} **本项目能用的部署服务器**:名称 (后面几条用它当 `serverName`)
|
|
178
190
|
、项目级还是应用级、协议、host / port、在本项目里的路径映射,以及 **项目级**的部署选项与危险组合告警。 **只读 IDE
|
|
179
191
|
配置、不联网**;动手前先看 `warnings[]`。
|
|
180
|
-
|
|
192
|
+
{{#if canUploadToDeployment}}
|
|
181
193
|
- {{cmd_upload_to_deployment}} **把映射到的本地目录传到服务器**(等同 IDE 的 Upload to …)。`mode` 默认 `mirror` ——
|
|
182
194
|
**会删掉服务器上多出来的文件**,使两边一致;要留住它们就传 `upload`。 **破坏性操作**。
|
|
183
|
-
|
|
184
|
-
|
|
195
|
+
{{/if}}
|
|
196
|
+
{{#if canDownloadFromDeployment}}
|
|
185
197
|
- {{cmd_download_from_deployment}} **把服务器上映射目录的内容拉回本地**(等同 IDE 的 Download from …), **以服务器为准**:
|
|
186
198
|
两边都有的文件会被远端覆盖 (内容相同则不写)。 **没有"保留我的版本"这个选项**。
|
|
187
|
-
|
|
188
|
-
|
|
199
|
+
{{/if}}
|
|
200
|
+
{{#if canGetDeploymentTaskStatus}}
|
|
189
201
|
- {{cmd_get_deployment_task_status}} **查一次传输的状态**:`handle` 用上传 / 下载返回的那个 —— **它自己不启动任何传输**。
|
|
190
|
-
|
|
202
|
+
{{/if}}
|
|
191
203
|
|
|
192
204
|
上传 / 下载都在 IDE 后台跑,单次调用只等到 `waitMs`(默认 10 秒)为止;返回 `in_progress` 是 **正常**的,不是失败 —— 拿
|
|
193
205
|
`handle` 去查进度, **别用重复调上传 / 下载代替**(那样拿不到进度)。
|
package/src/mcp/idea.js
CHANGED
|
@@ -127,7 +127,7 @@ export async function callTool(port, projectPath, name, args = {}, options = {})
|
|
|
127
127
|
params: {
|
|
128
128
|
protocolVersion: PROTOCOL_VERSION,
|
|
129
129
|
capabilities: {},
|
|
130
|
-
clientInfo: { name: 'opencode-idea', version: '0.0
|
|
130
|
+
clientInfo: { name: 'opencode-idea', version: '0.1.0' },
|
|
131
131
|
},
|
|
132
132
|
});
|
|
133
133
|
// The IDE's Streamable-HTTP endpoint binds follow-up requests to the session
|
package/src/plugin.js
CHANGED
|
@@ -151,16 +151,33 @@ const PLUGIN_TOOL_NAMES = new Set(['configure_ide_project']);
|
|
|
151
151
|
* it is the only way to read a file inside a jar (`<jar>!/<entry>`) or the
|
|
152
152
|
* JDK's `jrt://` image, so the guidance keeps it for exactly that and sends
|
|
153
153
|
* ordinary reads to the native tool.
|
|
154
|
-
* - Plain file **write**: `
|
|
155
|
-
*
|
|
156
|
-
*
|
|
157
|
-
*
|
|
158
|
-
*
|
|
159
|
-
*
|
|
160
|
-
*
|
|
161
|
-
*
|
|
162
|
-
*
|
|
163
|
-
*
|
|
154
|
+
* - Plain file **write**: `create_new_file` is **hidden** — the native `write`
|
|
155
|
+
* does the same job without the extra hop. `apply_patch` is **kept**, and the
|
|
156
|
+
* reason it used to be hidden turned out to be wrong.
|
|
157
|
+
* It was hidden because "the IDE's patch tool is brittle in a way that costs
|
|
158
|
+
* real time — it matches hunks by exact context text, so a quote or a corner
|
|
159
|
+
* bracket normalised somewhere on the way in fails the whole hunk
|
|
160
|
+
* (`Hunk context not found`)". Measured against a real IDE (2026.2.3), that
|
|
161
|
+
* brittleness is **contained, not destructive**: a hunk that does not match
|
|
162
|
+
* fails on its own and leaves the file untouched, and the tool names the file
|
|
163
|
+
* it failed on ("scratch/a.ts: Hunk context not found"). It is not a reason
|
|
164
|
+
* to hide the tool.
|
|
165
|
+
* What made it worth keeping is what it does that nothing else here does:
|
|
166
|
+
* **one call patches many files** (Codex `*** Update File:` sections or a
|
|
167
|
+
* unified git diff, both verified). The native `edit` / `write` are
|
|
168
|
+
* single-file. OpenCode has a multi-file `patch` of its own — a DIFFERENT
|
|
169
|
+
* tool, with a different parameter and a different patch dialect, and it is
|
|
170
|
+
* only exposed to GPT models — so on any other model there is nothing for a
|
|
171
|
+
* "same change across a dozen files" job. Measured, the model answered that
|
|
172
|
+
* gap by writing a Python script that rewrites whole files: slower, and it
|
|
173
|
+
* silently reformats the parts it was not asked to touch. `apply_patch`
|
|
174
|
+
* touches only the lines it declares, reports how many hunks applied, and
|
|
175
|
+
* names the ones that did not.
|
|
176
|
+
* The guidance never mentions the native `patch`: most models do not have it
|
|
177
|
+
* in their tool list, and naming a tool that is not there only makes the
|
|
178
|
+
* model look for it (or mix the two parameter names up).
|
|
179
|
+
* `rename_refactoring` and `reformat_file` stay: both are capabilities the
|
|
180
|
+
* native tools do not have.
|
|
164
181
|
* - IDE terminal: `execute_terminal_command` does NOT inherit the project's
|
|
165
182
|
* environment. It was exposed on the assumption that it ran with the SDKs the
|
|
166
183
|
* user configured in the IDE (JDK, Node, Python, ...), but measured against a
|
|
@@ -232,11 +249,12 @@ export const HIDDEN_IDE_TOOL_SUFFIXES = [
|
|
|
232
249
|
'search_text',
|
|
233
250
|
'search_regex',
|
|
234
251
|
'search_file',
|
|
235
|
-
//
|
|
236
|
-
// `
|
|
237
|
-
//
|
|
238
|
-
//
|
|
239
|
-
// the
|
|
252
|
+
// File WRITE: `create_new_file` is dropped (the native `write` covers it),
|
|
253
|
+
// but `apply_patch` STAYS — it is the only multi-file writer on models that
|
|
254
|
+
// do not get OpenCode's own `patch` tool (a DIFFERENT tool, GPT-only).
|
|
255
|
+
// `edit_file` is the companion plugin's own writer, dropped by the plugin
|
|
256
|
+
// itself — hiding it only covers the older installed copies.
|
|
257
|
+
'create_new_file',
|
|
240
258
|
'edit_file',
|
|
241
259
|
];
|
|
242
260
|
|