@dsh-workbench/core 0.1.0

package/README.md

@@ -0,0 +1,55 @@
+# dsh-workbench
+
+基于 [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) 的 **Agent 工作台**。
+一个 dsh 插件包：换掉 dsh 的左栏，中列保留 dsh 的对话，右侧加一列工作台自研的数据面板。
+**dsh 本体一行不改**，两个实例同时跑。
+
+> **产品定位：所有事情都是「告诉 agent 去做」。**
+> 工作台不是操作台，是交代任务 + 看 agent 干得怎么样的地方。
+> 加任何功能前，先过 [`DESIGN.md`](../../DESIGN.md) 的四条硬规则与三个评审问题。
+
+```bash
+dsh web                        # :3080 —— 参考基线，原样不动
+./bin/dsh-workbench            # :3081 —— 工作台，与上面同时运行
+pnpm run dev                    # 改 src/** 后自动重建并热换（不重启、不刷新）
+```
+
+```
+dsh web (:3080)                       dsh workbench (:3081)
+┌ 左栏 ──────┬ 对话 ───┐             ┌ 左栏 ──────┬ 对话 ────┬ 数据面板 ──┐
+│ ◆ 品牌     │         │             │ ◆ 品牌     │          │ 看板       │
+│ [ + 新会话]│         │             │ [ + 新会话]│          │ 服务状态   │
+│ ◧ 面板     │         │             │ ▸ 项目     │          │ 缺陷分布   │
+│ 会话…      │         │             │  ▸ 会话    │ (常驻)    │ 最近缺陷   │
+└────────────┴─────────┘             └────────────┴──────────┴────────────┘
+```
+
+**当前进度**：宿主半侧（opencli 数据通路 + 只读投影 + agent 工具）已迁到 TypeScript 并跑通；
+左栏已实现并与 dsh 对齐；右侧数据面板列与「缺陷」看板模块正在从旧单文件 JS 迁到
+`src/app/client.tsx` + `src/modules/**`（见 [`docs/ARCHITECTURE.md`](../../docs/ARCHITECTURE.md)）。
+
+## 装一次
+
+```bash
+./scripts/verify.sh --record     # 记录 dsh web 的基线（用于事后证明它没被动过）
+./bin/dsh-workbench setup        # 建 workbench profile + 把工作台装进去（幂等，可重复跑）
+./bin/dsh-workbench             # 起工作台
+```
+
+`setup` 最后那一步等价于"在工作台会话里让 agent 执行 `install_bundle target=<本目录>`"
+—— 两条路都走 dsh 的 `runPluginCommand`，装完都会把 bundle 登记进 profile 清单。
+细节见 [`docs/OPERATIONS.md`](docs/OPERATIONS.md)。
+
+**给别人用**（发到内网源、对方的前置条件、Coding 登录）见
+[`docs/HANDOFF.md`](docs/HANDOFF.md)。
+
+## 从这里去哪
+
+| 触发 | 读 |
+|---|---|
+| 装机、起实例、验收、排障 | [`docs/OPERATIONS.md`](docs/OPERATIONS.md) |
+| 给别人用、发包到内网源、发版 | [`docs/HANDOFF.md`](docs/HANDOFF.md) |
+| 结构、层序、两个运行时、扩展位 | [`docs/ARCHITECTURE.md`](../../docs/ARCHITECTURE.md) |
+| 该不该做、做成什么形状 | [`DESIGN.md`](../../DESIGN.md) |
+| 术语 | [`CONTEXT.md`](../../CONTEXT.md) |
+| 为什么是这样 | [`docs/adr/`](../../docs/adr/) |

package/bin/dsh-workbench

@@ -0,0 +1,200 @@
+#!/usr/bin/env bash
+#
+# 工作台：建 profile / 起工作台。
+#
+#   ./bin/dsh-workbench setup                 # ① 建 profile 并把工作台装进去（幂等）
+#   ./bin/dsh-workbench                       # ② 起工作台，默认 :3081
+#   WORKBENCH_PORT=3091 ./bin/dsh-workbench   #    换端口
+#   ./bin/dsh-workbench --no-open             #    其余参数透传给 dsh web
+#   ./bin/dsh-workbench --help
+#
+# 与 `dsh web` 完全独立：不同的 profile 目录、不同的 node_modules、
+# 不同的端口、独立的进程。两个可以同时开着，互不干扰。
+#
+# ── 这份脚本有两种身份，它自己分得清 ──────────────────────────────────────
+#   · **仓库副本**（这个包落在一个 git 工作树里）：开发用。bundle 以 link 方式装本目录，
+#     改源码立刻生效（配合 `pnpm run dev`）。
+#   · **安装包**（从内网源下下来的）：`setup` 把 **registry 上那个包** 装进 profile。
+# 判据是「git 顶层在不在」—— `npm pack` 的产物里不含 .git（见 package.json 的 files）。
+# ⚠️ 不能判 `$REPO_DIR/.git`：workspace 之后 .git 在**仓库根**，不在这个包里（实测踩过，
+#    判错的症状是"仓库副本却去源上装"，改源码不再生效，而且不报错）。
+
+set -euo pipefail
+
+PKG='@dsh-workbench/core'
+DSH_HOME="${DSH_HOME:-$HOME/.dsh}"
+PROFILE="${WORKBENCH_PROFILE:-workbench}"
+PORT="${WORKBENCH_PORT:-3081}"
+PROFILE_DIR="$DSH_HOME/profiles/$PROFILE"
+
+# 本包的真实位置。**不能**直接 `dirname "$0"/..`：npx 是经 `node_modules/.bin/dsh-workbench`
+# 这条软链调进来的，那样算出来会停在 `node_modules`（实测），于是下面
+# `$REPO_DIR/bin/opencli-isolated` 与 `$REPO_DIR/profile/*` 全指着不存在的地方
+# —— 症状是隔离运行时那条软链变成死链、启动体检一直说"没装好"。
+# 所以先把软链解析到底，再取它的上一级。
+SELF="${BASH_SOURCE[0]}"
+while [ -L "$SELF" ]; do
+  SELF="$(cd "$(dirname "$SELF")" && pwd -P)/$(readlink "$SELF")"
+done
+REPO_DIR="$(cd "$(dirname "$SELF")/.." && pwd -P)"
+GIT_TOP="$(git -C "$REPO_DIR" rev-parse --show-toplevel 2>/dev/null || true)"
+
+if ! command -v dsh >/dev/null 2>&1; then
+  echo "dsh-workbench: PATH 上没有 dsh。先装：npm i -g @deepseek-ai/dsh" >&2
+  exit 1
+fi
+
+pkg_version() {
+  node -p "require('$REPO_DIR/package.json').version" 2>/dev/null || echo "0.0.0"
+}
+
+# ── setup：建 profile + 把工作台装进去 ─────────────────────────────────────
+#
+# 交给 dsh 自己的 `plugin` 子命令装，而不是我们自己拼 pnpm：它走的是与
+# install_bundle **同一条**通路（runPluginCommand）—— 兼容性预检、
+# profile 写锁、装完把 bundle 登记进 dsh.profile.bundles 全都在里面。
+# 自己拼 pnpm 会漏掉登记，症状是"包装上了但侧边栏不出现"。
+run_setup() {
+  "$REPO_DIR/scripts/seed-profile.sh"
+
+  if [ -n "$GIT_TOP" ]; then
+    SPEC="$REPO_DIR"
+    echo "→ 仓库副本：以 link 方式装本目录（${SPEC}）"
+  else
+    SPEC="$PKG@^$(pkg_version)"
+    echo "→ 从内网源装 ${SPEC}（源在 package.json 的 publishConfig.registry）"
+  fi
+
+  dsh plugin --profile "$PROFILE" add "$SPEC"
+
+  cat <<EOF
+
+装好了。起工作台：
+
+  $REPO_DIR/bin/dsh-workbench
+
+首次打开会走启动体检，它会自己把 opencli 的隔离运行时装好 —— 不用你动手。
+EOF
+}
+
+usage() {
+  sed -n '3,10p' "${BASH_SOURCE[0]}" | sed 's/^# \{0,1\}//'
+}
+
+case "${1:-}" in
+  setup)
+    shift
+    run_setup "$@"
+    exit 0
+    ;;
+  help | --help | -h)
+    usage
+    exit 0
+    ;;
+esac
+
+if [ ! -f "$PROFILE_DIR/package.json" ]; then
+  echo "dsh-workbench: profile '$PROFILE' 还不存在。" >&2
+  echo "  先运行: $REPO_DIR/bin/dsh-workbench setup" >&2
+  exit 1
+fi
+
+# 软提醒：bundle 没装的话面板不会出现，但服务照常起来。
+if ! grep -q "\"$PKG\"" "$PROFILE_DIR/package.json"; then
+  echo "dsh-workbench: 提醒 —— 工作台 bundle 还没装进 profile '$PROFILE'，" >&2
+  echo "  侧边栏不会出现「工作台」入口。运行: $REPO_DIR/bin/dsh-workbench setup" >&2
+fi
+
+# 清掉从父 dsh 会话继承来的身份变量。
+#
+# 它们描述的是**另一个** profile 和会话。如果你是在某个 dsh 会话的 shell 里
+# 启动工作台（很常见），不清掉的话 workbench 进程会认错身份 ——
+# 实测：跑在 :3081 的 workbench 进程继承了 DSH_PROFILE=web、
+# DSH_PROFILE_DIR=…/profiles/web、DSH_WEB_URL=…:3080、
+# 以及那个会话的 DSH_SESSION_ID。
+#
+# 保留 DSH_HOME：它是"harness 家目录在哪"的配置输入，应该被尊重。
+
+unset DSH_PROFILE DSH_PROFILE_DIR DSH_WEB_URL DSH_SESSION_ID DSH_SHELL
+
+# 告诉 profile 里的 hmr 条目该监听哪个目录（宿主侧的模块监听）。
+#
+# 监听**dsh 真正加载的那份代码**：profile 里那份优先，其次才是本目录 ——
+# 用 npx 起的安装包里，本目录在 npx 缓存里（会被回收），而 profile 里那份才是常驻的。
+# 那条通常是软链，用 `cd -P` 取真实路径：chokidar 收不到软链那头的事件。
+#
+# 为什么要环境变量：bundle 补丁里的相对路径以 profile 目录为基准，从 profile 目录
+# 出发走不到真实路径（实测 root: ['.'] 无效），所以由启动器给出绝对路径。
+PROFILE_COPY="$PROFILE_DIR/node_modules/$PKG"
+if [ -d "$PROFILE_COPY" ]; then
+  export DSH_WORKBENCH_ROOT="$(cd -P "$PROFILE_COPY" && pwd)"
+else
+  export DSH_WORKBENCH_ROOT="$REPO_DIR"
+fi
+
+# ── 把 web 的设置**叠加**上来（web → 工作台，单向、实时）────────────────────
+#
+# 为什么叠而不是复制：`seed-profile.sh` 是把 web 的设置**快照一份**过来，之后两边各自
+# 演进 —— 于是"在 web 里加了个模型供应商，工作台却少一个"这种漂移迟早发生（实测撞过）。
+# 叠加则是**同一个来源**：供应商 / 搜索源 / MCP 这类机器级设置只在 `dsh web` 里配一次。
+#
+# 为什么是这一层（`--patch`）而不是机器公共层 `$DSH_HOME/cordis.patch.yml`：
+# 公共层对所有 profile 生效且**没有 UI 写入路径**（配置编辑器只写当前 profile 的 patch）
+# —— 把设置放进去等于要求用户手编。而 `--patch` 叠的是 web 的 profile patch，
+# 用户在 web 的 Settings 页里配的就是它，配完即生效。
+#
+# 副作用（刻意的）：被这一层覆盖的行，在工作台的 Settings 页里会显示
+# `overridden by a home patch or command-line overlay` —— 那正是"这行由 web 管"的提示。
+# 反向不成立：工作台里配的只落在自己的 profile patch（差异层），web 看不到。
+WEB_PATCH="$DSH_HOME/profiles/web/cordis.patch.yml"
+PATCH_ARGS=()
+if [ -f "$WEB_PATCH" ]; then
+  PATCH_ARGS=(--patch "$WEB_PATCH")
+else
+  echo "dsh-workbench: 提醒 —— 找不到 ${WEB_PATCH}，这次不叠加 web 的设置（供应商等可能不全）。" >&2
+fi
+
+# ── 声明工作台运行时的**可写根**（执行缝的沙箱只放行 process.cwd()）──────────
+#
+# 工作台自己要跑命令：启动体检自动装 opencli、模块市场装/升插件、查源上新版。
+# 这些命令走 dsh 的执行缝，而那条缝带**文件沙箱**；插件发起的调用**没有会话**，
+# 回落到部署策略，出厂值是 `workspaceRoot: process.cwd()` —— 安装目标
+# `$DSH_HOME/workbench/...` 不在启动目录下，被拒写（EPERM），"自动装"死在第一步，
+# 界面只能退化成"让用户去终端抄一条命令"。这一层把可写根指到工作台运行时，
+# 那一整棵树（隔离工具链 + npm 缓存 + 模块专属文件夹 + 市场 prefix）就都放行了。
+#
+# 为什么是 `--patch` 叠加而不是改 profile 的 cordis.patch.yml：profile 可能是旧的
+# （交接出去的机器尤其如此），没人会回头重跑 seed；叠加层每次启动都生效。
+# ⚠️ 必须排在 web 的 patch **之后**：工作台的可写根要赢。
+SANDBOX_PATCH="$REPO_DIR/profile/sandbox.patch.yml"
+if [ -f "$SANDBOX_PATCH" ]; then
+  PATCH_ARGS+=(--patch "$SANDBOX_PATCH")
+else
+  echo "dsh-workbench: 提醒 —— 找不到 ${SANDBOX_PATCH}，这次不声明可写根（自动装会失败）。" >&2
+fi
+
+# 把 opencli 指到**隔离运行时**：所有 opencli 调用（探测、取数、装/卸插件）都走它，
+# 于是装/卸插件不碰用户本机的 ~/.opencli。
+#
+# 为什么隔离要用 HOME（而不是 OPENCLI_CONFIG_DIR）：opencli 的**插件目录只认 HOME**
+# —— 见 bin/opencli-isolated 开头的说明。
+#
+# 建一个**稳定路径**的软链：别处（包括给用户"复制这条命令"的文案）都能用
+# $DSH_HOME/workbench/opencli/bin/opencli 引用它，不必知道本目录在哪 ——
+# 而且从那里跑出来同样是隔离的。指向 profile 里那份，别指 npx 缓存（会回收）。
+OPENCLI_ROOT="$DSH_HOME/workbench/opencli"
+mkdir -p "$OPENCLI_ROOT/bin" "$OPENCLI_ROOT/home"
+ln -sfn "$DSH_WORKBENCH_ROOT/bin/opencli-isolated" "$OPENCLI_ROOT/bin/opencli"
+export DSH_WORKBENCH_OPENCLI="$OPENCLI_ROOT/bin/opencli"
+
+# 软提醒：隔离运行时没装的话，启动体检会**自己装**（沙箱已放行工作台运行时，
+# 见上面那层 SANDBOX_PATCH）；这条只是提前说一声，免得盯着全屏 loading 猜。
+if [ ! -x "$OPENCLI_ROOT/toolchain/node_modules/.bin/opencli" ]; then
+  echo "dsh-workbench: opencli 的隔离运行时还没装好 —— 启动体检会自己装，" >&2
+  echo "  装不上时它会给一条能直接照抄到终端的命令。" >&2
+fi
+
+# ⚠️ 顺序有讲究：`--patch` 是 **dsh 本体**的选项，必须排在 `--port`（应用参数）**之前** ——
+# 参数一旦进了应用的透传区（第一个应用自己的选项开始），后面的都直接交给应用，
+# `--patch` 会被应用当成未知选项（实测：`--port` 在前时报 `unknown option '--patch'`）。
+exec dsh "$PROFILE" ${PATCH_ARGS[@]+"${PATCH_ARGS[@]}"} --port "$PORT" "$@"

package/bin/opencli-isolated

@@ -0,0 +1,61 @@
+#!/usr/bin/env bash
+#
+# 工作台**隔离的** opencli：所有 opencli 调用都从这里过（探测、取数、装/卸插件）。
+#
+# 为什么需要它：opencli 的**插件目录只认 `HOME`** —— `dist/src/plugin.js` 里
+#
+#     function getHomeDir() {
+#       return process.env.HOME || process.env.USERPROFILE || os.homedir();
+#     }
+#
+# 而 `OPENCLI_CONFIG_DIR` 只管配置 / trace / browser-profiles。两套开关，别混。
+# 所以想让"工作台装的插件"与"用户本机装的插件"分开，唯一的开关是 `HOME`：
+# 指到工作台自己的目录，`~/.opencli` 就一个字节都不会被碰。
+#
+# 为什么必须是**单一路径、不含空格**：`DSH_WORKBENCH_OPENCLI` 既被**原样**当命令跑
+# （能力探测：`$DSH_WORKBENCH_OPENCLI plugin list -f json`），又被 `quoteShellArg`
+# 整体单引号包住（一键修那条 line）。写 `HOME=/x opencli` 会被包成 `'HOME=/x opencli'`，
+# 当成一个不存在的可执行文件。
+#
+# ⚠️ 落点必须与 `src/shared/api/host/opencli-runtime.ts` 一致（两边都从 $DSH_HOME 推）。
+#
+set -euo pipefail
+
+DSH_HOME="${DSH_HOME:-$HOME/.dsh}"
+ROOT="$DSH_HOME/workbench/opencli"
+REAL_HOME="$HOME"
+
+mkdir -p "$ROOT/home"
+
+# 隔离的 HOME：插件、plugins.lock.json、monorepo 克隆、trace 全落这下面。
+export HOME="$ROOT/home"
+
+# 换 HOME 会连带丢掉 ~/.npmrc —— 里面有私有源的 _authToken
+# （内网源地址由使用者自己配）。不指回去，从私有源装插件会 404/401（实测）。
+if [ -f "$REAL_HOME/.npmrc" ]; then
+  export NPM_CONFIG_USERCONFIG="$REAL_HOME/.npmrc"
+fi
+
+# npm 缓存**必须留在隔离运行时里**（与 `opencli-runtime.ts` 的 npmCacheDir() 同一落点）。
+#
+# ⚠️ **不能用 `${npm_config_cache:-…}`**：用 `npx` / `npm exec dsh-workbench` 起工作台时，
+# npm 会往进程里**注入** `npm_config_cache=/Users/<你>/.npm`（实测：`npm exec -- node -e …`
+# 打出来就是它），这个值一路继承到执行缝里的每条命令。带默认值等于"外面给什么就用什么"，
+# 于是隔离形同虚设 —— opencli 自己内部还会跑 npm（`plugin install` 就要，见它 dist 里
+# `execFileSync('npm', ['install', …])`），那次会去写 `~/.npm`；而执行缝只放行
+# `$DSH_HOME/workbench`，写入被拒 → 市场装插件**报错退出 1**，报的还是 npm 那句
+# "cache folder contains root-owned files"（那台机器上其实一个 root 文件都没有，是假话术）。
+# 所以这里是**无条件改写**：缓存落点只有这一处说了算。
+#
+# 另一条老账：`~/.npm` 里只要有一个 root 的文件（以前 `sudo npm` 留下的），npm 也会拒绝
+# 使用整个缓存。隔离运行时本来就有自己的缓存，没理由去赌用户那份。
+export npm_config_cache="$ROOT/npm-cache"
+
+BIN="$ROOT/toolchain/node_modules/.bin/opencli"
+if [ ! -x "$BIN" ]; then
+  echo "dsh-workbench: opencli 的隔离运行时还没装好（$ROOT/toolchain）。" >&2
+  echo "  打开工作台：启动体检会给出一条能直接照做的安装命令。" >&2
+  exit 127
+fi
+
+exec "$BIN" "$@"