@jackwener/opencli 1.4.1 → 1.5.1

package/docs/guide/electron-app-cli.md

@@ -0,0 +1,200 @@
+---
+description: How to turn a new Electron desktop app into an OpenCLI adapter
+---
+
+# Add a New Electron App CLI
+
+This guide is the **fast entry point** for turning a new Electron desktop application into an OpenCLI adapter.
+
+If you want the full background and deeper SOP, read:
+- [CLI-ifying Electron Applications](/advanced/electron)
+- [Chrome DevTools Protocol](/advanced/cdp)
+- [TypeScript Adapter Guide](/developer/ts-adapter)
+
+## When to use this guide
+
+Use this workflow when the target app:
+- is built with **Electron**, or at least exposes a working **Chrome DevTools Protocol (CDP)** endpoint
+- can be launched with `--remote-debugging-port=<port>`
+- should be automated through its real UI instead of a public HTTP API
+
+If the app is **not** Electron and does **not** expose CDP, use the native desktop automation pattern instead. See [CLI-ifying Electron Applications](/advanced/electron#non-electron-pattern-applescript).
+
+## The shortest path
+
+### 1. Confirm the app is Electron
+
+Typical macOS check:
+
+```bash
+ls /Applications/AppName.app/Contents/Frameworks/Electron\ Framework.framework
+```
+
+If Electron is present, the next step is usually to launch the app with a debugging port.
+
+### 2. Launch it with CDP enabled
+
+```bash
+/Applications/AppName.app/Contents/MacOS/AppName --remote-debugging-port=9222
+```
+
+Then point OpenCLI at that CDP endpoint:
+
+```bash
+export OPENCLI_CDP_ENDPOINT="http://127.0.0.1:9222"
+```
+
+### 3. Start with the 5-command pattern
+
+For a new Electron adapter, implement these commands first in `src/clis/<app>/`:
+
+- `status.ts` — verify the app is reachable through CDP
+- `dump.ts` — inspect DOM and snapshot structure before guessing selectors
+- `read.ts` — extract the visible context you actually need
+- `send.ts` — inject text and submit through the real editor
+- `new.ts` — create a new session, tab, thread, or document
+
+This is the standard baseline because it gives you:
+- a connection check
+- a reverse-engineering tool
+- one read path
+- one write path
+- one session reset path
+
+The full rationale and examples are in [CLI-ifying Electron Applications](/advanced/electron).
+
+## Recommended implementation workflow
+
+### Step 1: Build `status`
+
+Goal: prove CDP connectivity before touching app-specific logic.
+
+Typical checks:
+- current URL
+- document title
+- app shell presence
+
+If `status` is unstable, stop there and fix connectivity first.
+
+### Step 2: Build `dump`
+
+Do **not** guess selectors from the rendered UI.
+
+Dump:
+- `document.body.innerHTML`
+- accessibility snapshot
+- any stable attributes such as `data-testid`, `role`, `aria-*`, framework-specific markers
+
+Use the dump to identify real containers, buttons, composers, and conversation regions.
+
+### Step 3: Build `read`
+
+Target only the app region that matters.
+
+Good targets:
+- message list
+- editor history
+- visible thread content
+- selected document panel
+
+Avoid dumping the entire page text into the final command output.
+
+### Step 4: Build `send`
+
+Most Electron apps use React-style controlled editors, so direct `.value = ...` assignments are often ignored.
+
+Prefer editor-aware input patterns such as:
+- focus the editable region
+- use `document.execCommand('insertText', false, text)` when applicable
+- use real key presses like `Enter`, `Meta+Enter`, or app-specific shortcuts
+
+### Step 5: Build `new`
+
+Many desktop apps rely on keyboard shortcuts for “new chat”, “new tab”, or “new note”.
+
+Typical pattern:
+
+```ts
+const isMac = process.platform === 'darwin';
+await page.pressKey(isMac ? 'Meta+N' : 'Control+N');
+await page.wait(1);
+```
+
+## Where to put files
+
+For a TypeScript desktop adapter, the usual layout is:
+
+```text
+src/clis/<app>/status.ts
+src/clis/<app>/dump.ts
+src/clis/<app>/read.ts
+src/clis/<app>/send.ts
+src/clis/<app>/new.ts
+src/clis/<app>/utils.ts
+```
+
+If the app grows beyond the baseline, add higher-level commands such as:
+- `ask`
+- `history`
+- `model`
+- `screenshot`
+- `export`
+
+## What to document when you add a new app
+
+When the adapter is ready, also add:
+
+- an adapter doc under `docs/adapters/desktop/`
+- command list and examples
+- launch instructions with `--remote-debugging-port`
+- any required environment variables
+- platform-specific caveats
+
+Examples to study:
+- `docs/adapters/desktop/codex.md`
+- `docs/adapters/desktop/chatwise.md`
+- `docs/adapters/desktop/notion.md`
+- `docs/adapters/desktop/discord.md`
+
+## Common failure modes
+
+### CDP endpoint exists, but commands are flaky
+
+Usually one of these:
+- the wrong window/tab is selected
+- the app has not finished rendering
+- selectors were guessed instead of discovered from `dump`
+- the editor is controlled and ignores direct value assignment
+
+### The app is Chromium-based but not truly controllable
+
+Some desktop apps embed Chromium but do not expose a usable CDP surface.
+In that case, switch to the non-Electron desktop automation approach instead of forcing the Electron pattern.
+
+### You already have a browser workflow and wonder whether to reuse it
+
+If the app exposes a normal web URL and the browser flow is enough, a browser adapter is usually simpler.
+Use an Electron adapter only when the desktop app is the real integration surface.
+
+## Recommended reading order
+
+If you are starting from zero:
+
+1. This page
+2. [CLI-ifying Electron Applications](/advanced/electron)
+3. [Chrome DevTools Protocol](/advanced/cdp)
+4. [TypeScript Adapter Guide](/developer/ts-adapter)
+5. One concrete desktop adapter doc under `docs/adapters/desktop/`
+
+## Practical rule
+
+Do not start with a large feature surface.
+
+Start with:
+- `status`
+- `dump`
+- `read`
+- `send`
+- `new`
+
+Once those are stable, extend outward.

package/docs/guide/getting-started.md

@@ -55,3 +55,4 @@ opencli bilibili hot -v         # Verbose: show pipeline debug
 - [Plugins — extend with community adapters](/guide/plugins)
 - [All available adapters](/adapters/)
 - [For developers / AI agents](/developer/contributing)
+- [Add a new Electron app CLI](/guide/electron-app-cli)

package/docs/guide/plugins.md

@@ -31,12 +31,109 @@ Plugins live in `~/.opencli/plugins/<name>/`. Each subdirectory is scanned at st
 ### Supported Source Formats
 
 ```bash
+# GitHub shorthand
 opencli plugin install github:user/repo
+opencli plugin install github:user/repo/subplugin   # install specific sub-plugin from monorepo
 opencli plugin install https://github.com/user/repo
+
+# Any git-cloneable URL
+opencli plugin install https://gitlab.example.com/team/repo.git
+opencli plugin install ssh://git@gitlab.example.com/team/repo.git
+opencli plugin install git@gitlab.example.com:team/repo.git
+
+# Local plugin (for development)
+opencli plugin install file:///path/to/plugin
+opencli plugin install /path/to/plugin
 ```
 
 The repo name prefix `opencli-plugin-` is automatically stripped for the local directory name. For example, `opencli-plugin-hot-digest` becomes `hot-digest`.
 
+## Plugin Manifest (`opencli-plugin.json`)
+
+Plugins can include an `opencli-plugin.json` manifest file at the repo root to declare metadata:
+
+```json
+{
+  "name": "my-plugin",
+  "version": "1.0.0",
+  "opencli": ">=1.0.0",
+  "description": "My awesome plugin"
+}
+```
+
+| Field | Description |
+|-------|-------------|
+| `name` | Plugin name (overrides repo-derived name) |
+| `version` | Semantic version |
+| `opencli` | Required opencli version range (e.g. `>=1.0.0`, `^1.2.0`) |
+| `description` | Human-readable description |
+| `plugins` | Monorepo sub-plugin declarations (see below) |
+
+The manifest is optional — plugins without one continue to work exactly as before.
+
+## Monorepo Plugins
+
+A single repository can contain multiple plugins by declaring a `plugins` field in `opencli-plugin.json`:
+
+```json
+{
+  "version": "1.0.0",
+  "opencli": ">=1.0.0",
+  "description": "My plugin collection",
+  "plugins": {
+    "polymarket": {
+      "path": "packages/polymarket",
+      "description": "Prediction market analysis",
+      "version": "1.2.0"
+    },
+    "defi": {
+      "path": "packages/defi",
+      "description": "DeFi protocol data",
+      "version": "0.8.0",
+      "opencli": ">=1.2.0"
+    },
+    "experimental": {
+      "path": "packages/experimental",
+      "disabled": true
+    }
+  }
+}
+```
+
+### Installing
+
+```bash
+# Install ALL enabled sub-plugins from a monorepo
+opencli plugin install github:user/opencli-plugins
+
+# Install a SPECIFIC sub-plugin
+opencli plugin install github:user/opencli-plugins/polymarket
+```
+
+### How It Works
+
+- The monorepo is cloned once to `~/.opencli/monorepos/<repo>/`
+- Each sub-plugin gets a symlink in `~/.opencli/plugins/<name>/` pointing to its subdirectory
+- Command discovery works transparently — symlinks are scanned just like regular directories
+- Disabled sub-plugins (with `"disabled": true`) are skipped during install
+- Sub-plugins can specify their own `opencli` compatibility range
+
+### Updating
+
+Updating any sub-plugin from a monorepo pulls the entire repo and refreshes all sub-plugins:
+
+```bash
+opencli plugin update polymarket   # updates the monorepo, refreshes all
+```
+
+### Uninstalling
+
+```bash
+opencli plugin uninstall polymarket   # removes just this sub-plugin's symlink
+```
+
+When the last sub-plugin from a monorepo is uninstalled, the monorepo clone is automatically cleaned up.
+
 ## Version Tracking
 
 OpenCLI records installed plugin versions in `~/.opencli/plugins.lock.json`. Each entry stores the plugin source, current git commit hash, install time, and last update time. `opencli plugin list` shows the short commit hash when version metadata is available.

package/docs/zh/guide/electron-app-cli.md

@@ -0,0 +1,188 @@
+# 给新 Electron 应用生成 CLI
+
+这篇文档是把一个新的 Electron 桌面应用接入 OpenCLI 的**中文入口指南**。
+
+如果你需要更完整的背景和标准流程，继续看：
+- [Chrome DevTools Protocol（中文）](/zh/advanced/cdp)
+- [CLI-ifying Electron Applications（英文深度版）](/advanced/electron)
+- [TypeScript 适配器开发指南（英文）](/developer/ts-adapter)
+
+## 这篇文档适合什么场景
+
+当目标应用满足下面条件时，用这套流程：
+- 应用是 **Electron**，或者至少能暴露可用的 **CDP（Chrome DevTools Protocol）** 端口
+- 可以通过 `--remote-debugging-port=<port>` 启动
+- 你希望控制的是桌面应用本身，而不是它背后的公开 HTTP API
+
+如果应用**不是** Electron，或者不暴露 CDP，就不要硬套这套方案。那种情况应改用原生桌面自动化方案。可参考 [英文版说明](/advanced/electron#non-electron-pattern-applescript)。
+
+## 最短落地路径
+
+### 1. 先确认它是不是 Electron
+
+macOS 下常见检查方式：
+
+```bash
+ls /Applications/AppName.app/Contents/Frameworks/Electron\ Framework.framework
+```
+
+如果存在，通常就可以继续尝试 CDP。
+
+### 2. 带 CDP 端口启动应用
+
+```bash
+/Applications/AppName.app/Contents/MacOS/AppName --remote-debugging-port=9222
+```
+
+然后把 OpenCLI 指到这个端口：
+
+```bash
+export OPENCLI_CDP_ENDPOINT="http://127.0.0.1:9222"
+```
+
+### 3. 先做 5 个基础命令
+
+建议一个新 Electron 适配器先实现这 5 个命令：
+
+- `status.ts` —— 确认 CDP 连通
+- `dump.ts` —— 导出 DOM / snapshot，先做逆向再写逻辑
+- `read.ts` —— 读取当前上下文
+- `send.ts` —— 往真实编辑器里输入并发送
+- `new.ts` —— 新建会话 / 标签页 / 文档
+
+这是最稳妥的基线，因为它先把“能连上、能看见、能读、能写、能重置状态”这 5 件核心事情打通了。
+
+## 推荐开发顺序
+
+### 第一步：先做 `status`
+
+目标不是功能，而是先证明：
+- CDP 真的连上了
+- 你连到的是对的窗口/标签页
+- 应用当前页面确实可读
+
+如果 `status` 都不稳定，先不要继续往下做。
+
+### 第二步：做 `dump`
+
+**不要猜 selector。**
+
+先把这些导出来：
+- `document.body.innerHTML`
+- accessibility snapshot
+- 稳定属性：`data-testid`、`role`、`aria-*` 等
+
+然后再决定：
+- 消息列表在哪
+- 输入框在哪
+- 按钮在哪
+- 当前会话容器在哪
+
+### 第三步：做 `read`
+
+只读真正需要的区域，不要把整个页面文本都塞出来。
+
+常见目标：
+- 对话消息区
+- 当前线程内容
+- 当前编辑器历史
+- 当前文档主区域
+
+### 第四步：做 `send`
+
+很多 Electron 应用的输入框是 React 控制组件，直接改 `.value` 往往没用。
+
+更稳妥的方式通常是：
+- 先 focus 到可编辑区域
+- 能用时优先 `document.execCommand('insertText', false, text)`
+- 最后用真实按键提交，比如 `Enter`、`Meta+Enter`
+
+### 第五步：做 `new`
+
+很多桌面应用的新建动作其实更适合走快捷键，而不是点按钮。
+
+典型模式：
+
+```ts
+const isMac = process.platform === 'darwin';
+await page.pressKey(isMac ? 'Meta+N' : 'Control+N');
+await page.wait(1);
+```
+
+## 文件一般怎么放
+
+一个 TypeScript 桌面适配器，通常结构是：
+
+```text
+src/clis/<app>/status.ts
+src/clis/<app>/dump.ts
+src/clis/<app>/read.ts
+src/clis/<app>/send.ts
+src/clis/<app>/new.ts
+src/clis/<app>/utils.ts
+```
+
+当基础能力稳定后，再继续加：
+- `ask`
+- `history`
+- `model`
+- `screenshot`
+- `export`
+
+## 加完适配器后，还应该补什么文档
+
+至少补这几项：
+- `docs/adapters/desktop/` 下的适配器说明页
+- 命令列表和示例
+- 如何带 `--remote-debugging-port` 启动
+- 需要哪些环境变量
+- 平台限制和注意事项
+
+可以参考这些现成文档：
+- `docs/adapters/desktop/codex.md`
+- `docs/adapters/desktop/chatwise.md`
+- `docs/adapters/desktop/notion.md`
+- `docs/adapters/desktop/discord.md`
+
+## 常见问题
+
+### CDP 能连，但命令不稳定
+
+常见原因：
+- 连错窗口或标签页
+- 页面还没渲染完
+- selector 是猜的，不是从 `dump` 里找出来的
+- 输入框是受控组件，直接赋值不生效
+
+### 应用看起来像 Chromium，但就是不好控
+
+有些桌面应用虽然嵌了 Chromium，但并不真正暴露可用的 CDP 接口。
+这种情况不要强行走 Electron 方案，应该换到非 Electron 的桌面自动化方案。
+
+### 这个应用其实也有网页版本，还要不要做 Electron 适配器
+
+如果网页版本已经足够稳定，浏览器适配器通常更简单。
+只有当**桌面应用才是真正的集成面**时，再优先做 Electron 适配器。
+
+## 推荐阅读顺序
+
+如果你从零开始：
+
+1. 先看这篇
+2. 再看 [CLI-ifying Electron Applications（英文深度版）](/advanced/electron)
+3. 再看 [Chrome DevTools Protocol（中文）](/zh/advanced/cdp)
+4. 再看 [TypeScript Adapter Guide（英文）](/developer/ts-adapter)
+5. 最后找一个现成桌面适配器文档照着做
+
+## 最后一个实践建议
+
+不要一上来就做很大的命令面。
+
+先把下面 5 个做稳：
+- `status`
+- `dump`
+- `read`
+- `send`
+- `new`
+
+这 5 个稳定了，再往外扩，成本最低，返工也最少。

package/docs/zh/guide/getting-started.md

@@ -38,3 +38,4 @@ opencli bilibili hot -f csv     # CSV
 - [Browser Bridge 设置](/zh/guide/browser-bridge)
 - [所有适配器](/zh/adapters/)
 - [开发者指南](/zh/developer/contributing)
+- [给新 Electron 应用生成 CLI](/zh/guide/electron-app-cli)

package/docs/zh/guide/plugins.md

@@ -32,11 +32,76 @@ Plugins 存放在 `~/.opencli/plugins/<name>/`。每个子目录都会在启动
 
 ```bash
 opencli plugin install github:user/repo
+opencli plugin install github:user/repo/subplugin   # 安装 monorepo 中的指定子插件
 opencli plugin install https://github.com/user/repo
 ```
 
 如果仓库名带 `opencli-plugin-` 前缀，本地目录会自动去掉这个前缀。例如 `opencli-plugin-hot-digest` 会变成 `hot-digest`。
 
+## 插件清单 (`opencli-plugin.json`)
+
+插件可以在仓库根目录放置 `opencli-plugin.json` 来声明元数据：
+
+```json
+{
+  "name": "my-plugin",
+  "version": "1.0.0",
+  "opencli": ">=1.0.0",
+  "description": "我的插件"
+}
+```
+
+| 字段 | 说明 |
+|------|------|
+| `name` | 插件名称（覆盖从仓库名推导的名称） |
+| `version` | 语义化版本 |
+| `opencli` | 所需的 opencli 版本范围（如 `>=1.0.0`、`^1.2.0`） |
+| `description` | 描述 |
+| `plugins` | Monorepo 子插件声明（见下文） |
+
+清单文件是可选的——没有它的插件依然可以正常工作。
+
+## Monorepo 插件
+
+一个仓库可以通过在 `opencli-plugin.json` 中声明 `plugins` 字段来包含多个插件：
+
+```json
+{
+  "version": "1.0.0",
+  "opencli": ">=1.0.0",
+  "description": "我的插件合集",
+  "plugins": {
+    "polymarket": {
+      "path": "packages/polymarket",
+      "description": "预测市场分析",
+      "version": "1.2.0"
+    },
+    "defi": {
+      "path": "packages/defi",
+      "description": "DeFi 协议数据",
+      "version": "0.8.0"
+    },
+    "experimental": {
+      "path": "packages/experimental",
+      "disabled": true
+    }
+  }
+}
+```
+
+```bash
+# 安装 monorepo 中的全部子插件
+opencli plugin install github:user/opencli-plugins
+
+# 安装指定子插件
+opencli plugin install github:user/opencli-plugins/polymarket
+```
+
+- Monorepo 只 clone 一次到 `~/.opencli/monorepos/<repo>/`
+- 每个子插件通过 symlink 出现在 `~/.opencli/plugins/<name>/`
+- 更新任何子插件会拉取整个 monorepo 并刷新所有子插件
+- 卸载最后一个子插件时，monorepo 目录会被自动清理
+
 ## 版本追踪
 
 OpenCLI 会把已安装 plugin 的版本记录到 `~/.opencli/plugins.lock.json`。每条记录会保存 plugin source、当前 git commit hash、安装时间，以及最近一次更新时间。只要有这份元数据，`opencli plugin list` 就会显示对应的短 commit hash。

package/extension/package.json

@@ -6,6 +6,7 @@
   "scripts": {
     "dev": "vite build --watch",
     "build": "vite build",
+    "package:release": "node scripts/package-release.mjs",
     "typecheck": "tsc --noEmit"
   },
   "devDependencies": {