@dsh-workbench/core 0.3.10 → 1.0.0-beta.0

package/cordis.patch.yml

@@ -1,7 +1,6 @@
-# 工作台 bundle 的补丁层。做三件事：
-#   1. 关掉出厂的左栏 ui-sidebar —— 由我们接管 sidebar 槽；
-#   2. 打开宿主的模块监听 —— 让 `npm run dev` 重建后宿主插件能热换；
-#   3. 插入工作台插件本体。
+# 工作台 bundle 的补丁层。做两件事：
+#   1. 打开宿主的模块监听 —— 让 `npm run dev` 重建后宿主插件能热换；
+#   2. 插入工作台插件本体。
 #
 # 组合顺序（实测）：
 #   1. bundle 层（dsh.profile.bundles 顺序）   ← 本文件在这里
@@ -9,20 +8,53 @@
 #   3. 机器公共层（$DSH_HOME/cordis.patch.yml，对所有 profile 生效）
 #   4. --patch 叠加层
 #
-# 我们排在 bundle 列表最后，所以能覆盖 dsh-web-app 插入的 ui-sidebar 行。
+# 我们排在 bundle 列表最后，所以能覆盖 dsh-web-app 插入的行。
 
-# ── 为什么必须"关掉"而不是"运行时遮蔽" ────────────────────────────────
-# sidebar 是 single 槽，理论上可以用更低的 priority 遮蔽 ui-sidebar 的
-# SidebarRoot。但子座位（sidebar.panellist / sidebar.settings / …）的声明
-# 是**独占 claim**，SlotSpec 里没有 priority：两个 entry 声明同一批座位，
-# 后一个会抛错，导致 ui-sidebar 整个 entry 激活失败、前端直接白屏报
-# "Failed to load plugins"。
+# ── 左栏二选一：官方 ui-sidebar / 工作台自己的 ─────────────────────────
 #
-# 所以正确做法是在组合层把它摘掉，让工作台插件成为 sidebar 槽的唯一
-# 注册者。这也正是 profile 隔离的价值：只影响工作台，dsh web 一点不动。
-- id: ui-sidebar
-  name: '@deepseek-ai/dsh-client-ui-sidebar'
-  disabled: true
+# 默认是**官方**左栏（这一层不再摘 ui-sidebar）。Guest 的「设置 → 工作台设置 →
+# 会话列表」选「自定义」时，往 **profile 用户层**（profiles/<name>/cordis.patch.yml）
+# 写一行 `- id: ui-sidebar` + `disabled: true`；dsh-hmr 盯着 profile patch，
+# 变了会重组，刷新页面即生效（不用重启进程）。
+#
+# 为什么不能运行时遮蔽：sidebar 的子座位（sidebar.panellist / .settings / …）是
+# **独占 claim**，两个 entry 声明同一批座位会抛错；而运行时只给声明了 children 的
+# entry 发 `renderSlot`。所以两套左栏不能同时在场，只能按组合层二选一。
+# 证据：内部设计记录 §3。
+
+# ── 权限预设：多给一档「全盘写 + 保留审批」 ────────────────────────────
+# dsh 出厂只有「工作区内修改」（workspace-write + ask）与「完全权限」
+# （danger-full-access + never）。中间那档「文件边界全开、但审批策略仍是 ask」
+# 不在表里，用户选不到；这里把它加进选择器。
+#
+# 这一档是 dsh 层的权限档，不绑任何产品：名字与描述都不带产品字样。
+# 它只改变两个旋钮，谁读这两个旋钮（写闸门、升权审批、插件命令……）
+# 各自按自己的规则响应。
+#
+# `config` 是整体替换、不深合并：dsh 出厂那三档必须一起写全。
+# `defaultPreset` 不写，保持 dsh 按组合默认值推断（通常是 workspace-write）。
+#
+# id 用 `danger-full-access-ask`，不覆盖 `danger-full-access`：后者要留给
+# 真正「不问审批」的完全权限。代价是 dsh 客户端只对 `danger-full-access` /
+# `auto` 两个 id 弹全盘风险确认、也只给那四个内置 id 图标 —— 这一档点了直接切、
+# 而且没有图标（2026-10-22 明确接受）。
+- id: permission
+  config:
+    presets:
+      read-only:
+        sandbox: read-only
+        approval: ask
+      workspace-write:
+        sandbox: workspace-write
+        approval: ask
+      danger-full-access:
+        sandbox: danger-full-access
+        approval: never
+      danger-full-access-ask:
+        sandbox: danger-full-access
+        approval: ask
+        name: 完全权限（保留审批）
+        description: 允许写工作区外；需要审批的操作仍会继续询问。
 
 # ── 宿主侧热更新 ──────────────────────────────────────────────────────
 # 出厂默认 `root: []` = 不监听任何模块目录，改了宿主代码只能重启。
@@ -42,11 +74,11 @@
   config:
     root:
       - !!js process.env.DSH_WORKBENCH_ROOT ?? '.'
-      - !!js dshHomePath('workbench/diy')
+      - !!js process.env.DSH_WORKBENCH_HOME ?? dshHomePath('workbench/diy')
     # ★ followSymlinks: false（2026-10-11 实测：这就是"改了没反应、而且不报错"的根因）
     #
     # 两个根底下的 `node_modules/@dsh-workbench/*` 是一串**互相指向**的软链
-    # （工坊 → core → 本仓 packages/workbench → 它自己的 node_modules/@dsh-workbench/shared → …）。
+    # （工坊 → core → 本仓 packages/core → 它自己的 node_modules/@dsh-workbench/shared → …）。
     # 默认跟随软链时 chokidar 会一路走进去，而默认的 `ignored: ['**/node_modules', …]` 在
     # **根之外的路径**上根本不生效：chokidar 传给 ignored 的是 `relative(baseDir, path)`，
     # 根在 baseDir 之外时它长这样 —— `../../../../.dsh/workbench/diy/node_modules/…`，
@@ -94,27 +126,20 @@
       - '*(../)**/node_modules'
       - '*(../)**/.*'
 
-# ── 工作台运行时的**可写根**：让外壳在**任意 profile** 里自足 ──────────────
+# ── 可写根**不在这里**（2026-10-22 挪走）──────────────────────────────────
 #
-# 这一行与 `--patch profile/sandbox.patch.yml` 是同一件事（启动器每次启动都叠那一层）。
-# 为什么这里还要再来一份：外壳现在可以被**直接装进别人的 profile**（dsh web 的
-# Plugins 页 → Add plugin → `@dsh-workbench/core`）。那条路上没有启动器，
-# 而少了这一行，插件发起的命令（启动体检装隔离 opencli、市场装 opencli 插件、
-# opencli 自己的 trace / browser-profile 写入）全都撞文件沙箱 —— 可写根是
-# dsh-base 出厂那句 `process.cwd()`，`$DSH_HOME/workbench` 不在它下面。
+# 这一格曾经有一行 `sandbox-policy`（`workspaceRoot` → `$DSH_HOME/workbench`），
+# 为的是"装进别人的 profile 也就地放行"。它被挪走了，因为 **bundle 层是在线启用时
+# 才生效的**：dsh 0.2.1 的在线重组在改这一行时会重建 `session-controller`，与
+# `file-upload` 注销 resolver 赛跑 —— 启用当场把 session-controller 打成 failed，
+# 之后每次新建会话都是 `gateway/service-unavailable`（连 toggle 都救不回来，只能重启）。
 #
-# 为什么放**组合层**而不是让宿主自己改策略：`sandboxPolicy` 的 workspaceRoot 是
-# 启动时读的部署策略，插件没有正当入口改它（改服务字段是绕过策略，不是声明策略）。
-# bundle 层正好在 profile 用户层**下面** —— 所以"装了就生效"与"用户自己写一行就
-# 覆盖它"同时成立，这正是这一层该有的位置。
-#
-# 代价写在明处（ADR-0037）：这个 profile 里**无会话的**插件命令，可写根从
-# `process.cwd()` 变成 `$DSH_HOME/workbench`。有会话的命令不受影响（会话用自己的
-# cwd），工作台自己的命令本来也只该写这一棵树。
-- id: sandbox-policy
-  config:
-    mode: !!js process.env.DSH_PERMISSION_MODE ?? 'workspace-write'
-    workspaceRoot: !!js dshHomePath('workbench')
+# 证据与 A/B：ADR-0037 的 2026-10-22 补记。自带 profile 的可写根仍有两处：启动器每次启动
+# 叠的 `--patch profile/sandbox.patch.yml`，以及 `profile/isolation.patch.yml` 里同值的那一行
+# （seed-profile.sh 追加进 profile，给不带启动器的 `dsh workbench`）。装进别人的 profile 时，
+# 请把那一行写进那个 profile 的 `cordis.patch.yml` 再**重启**（在线写同一行也会撞同一个竞态）。
+# 少了它只会让"无会话的插件命令"被沙箱挡，不会再动会话接口；宿主启动时会就此打一条 warn
+# （见 runtime-seed 的 coversWritableRoot）。
 
 - insert:
     - id: workbench