提示词补全与终端DIV7NE/dsh-plugins

dshpluginsdev

DeepSeek Harness (DSH) web 插件，由 DIV7NE 开发。

每个插件都是本仓库中一个自包含的包。它们各自声明自己的 bundle patch，因此只需安装单个目录即可——DSH CLI 会将其追加到配置文件的 bundle 栈中，无需手动编辑任何配置文件。

| 插件 | 功能 |
|---|---|
| dsh-suggest-next-prompt/ | 将模型生成的下一句提示词放入聊天输入框的占位符中。按 Tab 粘贴，按 ↑/↓ 循环切换候选列表，按 Esc 关闭。 |
| dsh-chrome-agent/ | 通过一个固定版本的配套扩展来驱动你真实的、已登录的 Chrome，而不是使用单独的浏览器配置文件。 |
| dsh-run-in-terminal | 在每个聊天代码块上添加一个 Run 按钮，并在右侧边栏中提供一个集成终端来运行它。 |

安装插件

git clone https://github.com/DIV7NE/dshpluginsdev
cd dshpluginsdev/
npm install
npm run install:profile      # builds, packs, and installs into the web profile

然后为该配置文件重启 DSH 服务器——配置文件的 bundle 栈和浏览器的客户端模块图都在启动时构建，因此新插件无法出现在正在运行的服务器中。一旦插件进入模块图，之后的更改只需刷新页面即可。

Chrome 扩展

dsh-chrome-agent 从同一个目录发布两个产物，它们分别发布：

- DSH 插件（本仓库的包，像其同类插件一样安装）；
- Chrome 扩展，即 dsh-chrome-agent/extension/ 下的一个普通文件夹，由 scripts/pack-webstore.mjs 打包成根目录级别的 zip，这就是 Chrome 网上应用店上传的产物。它被构建并附加到 Releases 中，而不是通过 DSH 插件渠道发布。

在该目录中运行 npm run pack:webstore 可重新生成该 zip。CI 会运行它并断言该 zip 的根目录中仍包含 manifest.json，因为插件自身的测试不会发现打包器损坏的问题。

仓库布局

/            one self-contained DSH plugin package
src/               source
lib/               committed build output (see below)
cordis.patch.yml   the bundle patch that installs it
test/              hermetic tests, plus a non-hermetic live probe
README.md          what it does, how to configure it, its permissions and risks
docs/superpowers/    design, plan, and implementation notes

为什么 lib/ 会被提交。 DSH 插件不能运行 prepare 或 postinstall 脚本，因此安装时无法构建任何内容。因此构建产物以未压缩的形式随仓库一同发布。如果它与 src/ 不一致，CI 会失败。

开发

cd
npm run build        # esbuild
npm run typecheck    # tsc --noEmit
npm test             # node:test — hermetic
npm run install:profile

npm run build && npm run typecheck && npm test 与 CI 运行的检查相同。

发布状态
两个插件都通过了 DSH-Store 固定源预检。提交问题：

| 插件 | 问题 | 预检 |
|---|---|---|
| dsh-suggest-next-prompt | #778 | 通过，1 条警告 |
| dsh-run-in-terminal | #779 | 通过，2 条警告，部分扫描 |

预检是对固定提交进行的有界静态读取。它不是安全审计，不是运行时验证，也不是自动上架——随后的 Catalog 关卡会重新固定源，并在任何内容出现在商店中之前，应用更严格的许可证、依赖、生命周期、打包和运行时源检查。

两个已知限制，明确说明而非隐藏：

- 每个插件中的 scripts/install-profile.mjs 通过 child_process 调用 npm、npm pack 和 dsh CLI，以便一条命令即可完成重新构建并重新安装。两个插件的预检都会标记它。它是一个本地开发辅助工具：它不在 files 列表中，因此永远不会成为已发布包的一部分，也没有任何运行时代码路径会到达它。参数是固定字符串，不是用户输入。
- dsh-run-in-terminal 提交的浏览器包超出了扫描器每文件 256 KiB 的限制，因为它内联了 xterm。因此，商店报告扫描范围不完整。该包不能简单地缩小——内联是有意为之，因为 shell 不会在其模块表中为 xterm 播种，而且插件不得在安装时构建。

许可证

MIT。参见 LICENSE。

dsh-run-in-terminal

一个 DeepSeek Harness web 插件，它在聊天中的每个代码块上放置一个 Run 按钮，并为你提供一个真正的终端来运行它。

回复中的围栏代码块会在 DSH 已经绘制的 Copy 按钮旁边长出一个 Run 按钮。点击它会在右侧边栏中打开一个集成终端，将代码片段粘贴进去，然后按下 Enter。在终端内右键可 将所选内容附加为上下文（以及复制 / 粘贴 / 全选）：所选输出会作为围栏代码块追加到对话草稿中，随时可以发送。

安装

cd
npm install
npm run install:profile          # builds, packs, and installs into the web profile

然后为该配置文件重启 DSH 服务器（dsh web）并重新加载页面。重启是必需的，而非可选的：配置文件的打包栈和浏览器的客户端模块图都在启动时组合，因此新插件无法出现在正在运行的服务器中。

npm run install:profile 就是整个更新循环——在任何源代码更改后再次运行它并重启。它接受一个配置文件名称作为第一个参数（node scripts/install-profile.mjs myprofile，默认为 web）。

为什么使用 tarball 而不是本地链接

dsh plugin --profile web add  是安装树外插件的常用方式，而在这台机器上，对于位于与配置文件不同驱动器上的插件，它不起作用：pnpm 会创建 node_modules
与错误的目标连接（\\D:\projects\dshpluginsdev，它解析不到任何内容）。启动器随后无法读取包清单，永远看不到 dsh.bundle.patch，并报告 declares no dsh.bundle — installed as a plain dependency, not a profile layer。scripts/install-profile.mjs 通过从 npm tarball 安装来绕过这个问题，pnpm 会将其实体化为一个真实目录；随后 bundle 就能正确协调（已验证：dsh-run-in-terminal 被追加到 dsh.profile.bundles）。

每一半的作用

| 文件 | 作用 |
|---|---|
| src/index.ts | 宿主半部分：每个会话一个持久 pty，通过 GET /runterm/pty（WebSocket）提供服务，位于浏览器信任围栏之后。 |
| src/client/index.tsx | 注册 runterminal 右侧边栏页面类型以及代码块按钮传递。 |
| src/client/code-run.ts | 监视对话记录中的 .md-code-block 节点并附加 Run 按钮。 |
| src/client/terminal-view.tsx | xterm 窗格、其 socket 以及右键菜单。 |
| src/client/draft.ts | 通过对话服务将终端选择内容追加到编辑器草稿中。 |
| scripts/build.mjs | esbuild：node bundle，以及包裹在 window.__ModuleLoader__.load 样板中的浏览器 bundle。 |

Run 按钮如何到达 shell

openTab('runterminal', { params: { run } }) 作用于对话显示在屏幕上的会话，并按类型去重，因此点击要么创建终端，要么重新导航到已经打开的终端。标签页主体监视 navigation.revision，将代码片段以 {t:'run', code} 写入 pty，而宿主会将代码片段转换为 shell 输入：

- 行尾变为 CR（终端以 CR 发送 Enter），并附加一个最终的 CR 来提交，因此反斜杠续行的命令——聊天代码块中长命令的形态——会完全按所写内容运行；
- 末尾的空行会被丢弃，因此已经以换行符结尾的代码片段不会提交额外的空命令。

分帧逻辑有意放在宿主上：shell 读取的字节只有一个权威来源，而这正是 npm test 覆盖的部分。

代码文本本身是作为块内容节点的 textContent 读回的。DSH 使用 CSS 计数器绘制行号，从不作为 DOM 文本，因此这是确切的代码片段，而不是带编号的副本。

安全

该路由会生成进程，因此每个请求在到达进程之前都要通过浏览器信任围栏——与已发布的 /api 网关应用于其自身路由的围栏相同：

- Host 头必须指定回环地址（仅仅从别处解析到这里的名称是 DNS 重绑定攻击）；
- 浏览器标记为 Sec-Fetch-Site: cross-site 的请求会被拒绝；
- Origin（如果存在）必须指定相同的主机名。

这是 DNS 重绑定 / 跨站防御，不是身份验证。它不区分一个回环页面与另一个：从同一主机名但不同端口提供的页面共享该主机名并通过检查。如果你将 DSH 绑定到
一个非环回地址，这条路由会与其他所有内容一起暴露。

当客户端知道时，pty 会在会话的工作区根目录中启动，否则会在服务器自身的工作目录中启动；请求的目录如果不是已存在的目录，则会被忽略。

配置

在插件行中添加 config.shell 以选择 shell：

- id: run-in-terminal
name: 'dsh-run-in-terminal'
config:
shell: 'C:\\Program Files\\PowerShell\\7\\pwsh.exe'

默认值在 Windows 上是 pwsh.exe（当它在 PATH 中时）（否则为 powershell.exe），在 POSIX 上是 $SHELL —— 否则为 /bin/bash —— 并作为登录 shell 启动。

已知限制

- 每个对话会话一个终端，以会话 id 为键。关闭标签页会结束进程；隐藏或切换到其他标签页则不会。
- 多行片段会逐行提交，因此从聊天代码块运行的 shell 控制块（for … do … done、if … { }）需要其续行字符——这与粘贴到不支持括号粘贴的终端中相同。
- 该窗格位于 DSH 原生右侧边栏中，属于其自己的类型（runterminal）。它不会复用其他侧边栏插件注册的 terminal 类型，也不会与之冲突。
- 字符串仅支持英文；该插件不注册任何区域设置命名空间。

开发

npm run build          # esbuild: lib/index.js + the wrapped lib/client.js
npm run typecheck      # tsc --noEmit
npm test               # node --test test/host.test.mjs   (hermetic)
npm run install:profile

封闭测试套件涵盖字节帧、转录边界、shell 解析以及信任围栏。

test/live-probe.mjs 是非封闭的配套脚本：将其指向一个已加载此插件的运行中服务器，它会断言同源握手被接受、Run 帧通过真实 shell 往返，以及外部 Origin 被拒绝。

node test/live-probe.mjs http://127.0.0.1:3080 probe

浏览器打包细节：react 和 @deepseek-ai/* 保持外部化（shell 会将它们预置到其冻结的模块表中），而 xterm 及其 fit 插件则被内联，因此该打包无需 dsh.client.external 条目。