@dsh-workbench/core 0.2.16 → 0.3.1

package/README.md

@@ -47,9 +47,13 @@ npx @dsh-workbench/core                       # ② 起工作台，默认 :3081
 - 外壳会**自己把缺的那几件补齐**（建隔离 opencli 的入口、把 `dsh-wb-module` 挂上 PATH、
   后台把 DIY 工坊骨架建起来）—— 不需要跑 `setup`、也不需要启动器。后台脚本的输出在
   `~/.dsh/workbench/seed.log`（DIY 工坊的依赖是几百 MB，第一次启动在后台下）。
+- **工坊工具链跟着外壳走**：外壳升级后不用管工坊 —— 每次启动都会把工坊里那三个
+  `@dsh-workbench/*` 与**正在跑的那份外壳**比一次，不同代就在后台增量同步到同代（所以升级后
+  **下一次启动**就对上了）。离线时停在旧一代，但 `workbench_diy_status` 会直说
+  「工坊工具链还是上一代（…）：<原因>」并给出修法。
 - 第一次打开照旧走启动体检，自己装隔离 opencli 运行时；装不上时给一条能照抄到终端的命令。
 - 与 `setup` 那条路的差别：**没有独立端口/进程**、**会话不隔离**、**改外壳源码不热重载**，
-  DIY 工坊的依赖是第一次启动在后台装的。取舍与理由见
+  DIY 工坊的依赖是第一次启动在后台装的（此后**每次启动工作台时**工具链会自动跟到同代，见上一条）。取舍与理由见
   [ADR-0037](https://github.com/code-farmer-i/dsh-workbench/blob/main/docs/adr/0037-workbench-installs-into-any-profile.md)。
 - 想回到"两条实例并存"，就删掉这个包（Plugins 页里卸载），再走上面的 `setup` 那条路 —— 数据都还在。
 
@@ -71,7 +75,7 @@ npx @dsh-workbench/core                       # ② 起工作台，默认 :3081
 | --- | --- |
 | 起工作台 | `npx @dsh-workbench/core` |
 | 换端口 | `WORKBENCH_PORT=3091 npx @dsh-workbench/core` |
-| 升级 | 重跑一次 `npx --yes @dsh-workbench/core@latest setup`（幂等），刷新一次页面即可（`dsh-hmr` 会重组；它报 `restartReason` 时才重启进程） |
+| 升级 | 重跑一次 `npx --yes @dsh-workbench/core@latest setup`（幂等），然后**重启一次工作台**才用得上新版（市场里那条「更新」也写「重启后生效」）。工坊工具链会在**下一次启动**工作台时自动跟到同代 —— 不必手动删工坊 |
 | 重建 profile | `mv ~/.dsh/profiles/workbench ~/.dsh/profiles/workbench.bak`，再跑一次 `setup` |
 | 彻底不用了 | 删 `~/.dsh/profiles/workbench` 与 `~/.dsh/workbench` 两个目录（都不影响 `dsh web`） |
 | 改设置 | 在 `:3081` 的 Settings 里改（模型供应商 / 搜索源 / MCP 也是这里） |

package/bin/dsh-workbench

@@ -176,6 +176,18 @@ else
   export DSH_WORKBENCH_ROOT="$REPO_DIR"
 fi
 
+# ── 告诉工坊自愈「当前外壳」是谁（**显式基准**；不设 = 这一轮不做代际比对）────────
+#
+# dsh 接下来加载的是 **profile 里那份**（$PROFILE_COPY），版本以它为准；启动器自己这份
+# （$REPO_DIR）可能比它旧。实测漂移（同一天两次）：启动器 0.3.0 / profile 0.3.1 / 工坊已跟到
+# 0.3.1 时，启动器先跑 entry（它在 `exec dsh` **之前**），拿自己那份当基准，把工坊**降级**到
+# 0.3.0；宿主随后再跑 entry，看到工坊"与它同代" → no-op，整场会话停在错的一代。
+# 所以基准给 profile 里那份，而且**只在它真的可读时才给**：干净机器上 profile 还没装出这一份，
+# 那时没有基准 —— 比对归 setup 之后的第一次启动。
+if [ -f "$PROFILE_COPY/package.json" ]; then
+  export DSH_WB_SHELL_ROOT="$DSH_WORKBENCH_ROOT"
+fi
+
 # ── 设置从哪来：工作台自己的 profile patch（不再叠 web 那一份）──────────────
 #
 # 以前每次启动都用 `--patch` 把 `profiles/web/cordis.patch.yml` 叠成**最高层**。
@@ -243,21 +255,11 @@ if [ ! -f "$DSH_HOME/workbench/diy/package.json" ]; then
   }
 fi
 
-# 工坊**自己带着** DIY 的指引：软链到随包出货的那一份（本包的 `skills/workbench-module-diy/`）。
-# 为什么放在这里、而不是靠 agent preset 的 `customSkillDirs`：DIY 会话的 cwd 就是工坊
-# （会话 cwd 即沙箱边界），而 dsh 的 skill-filesystem 是从 **cwd 下的 `.agents/skills/`**
-# 发现技能的 —— 本仓自己那条 `module-design` 就是这么被看见的。所以指引住进工坊，
-# 进工坊的会话就天然看得见它，**不用去改用户任何默认设置**（改默认 preset 会连带把
-# 用户后面新建的普通会话也变成 DIY 模式）。preset 留着，是给想**显式选模式**的用户，
-# 额外带 tool-cordis 与 plugin-manager 两处增量。
-# 软链而不是拷贝：指引只有一份（随包出货，字数与链接都有判据钉着），拷一份就是第二份真相。
-# 先 rm -f 再建：包换过位置/名字之后，旧软链会变成死链 —— 而那是**不报错**的失败。
-DIY_SKILLS="$DSH_HOME/workbench/diy/.agents/skills"
-if [ -d "$REPO_DIR/skills/workbench-module-diy" ]; then
-  mkdir -p "$DIY_SKILLS"
-  rm -f "$DIY_SKILLS/workbench-module-diy"
-  ln -s "$REPO_DIR/skills/workbench-module-diy" "$DIY_SKILLS/workbench-module-diy"
-fi
+# 工坊**自己带着** DIY 的指引（软链到随包出货的那份 `skills/workbench-module-diy/`）。
+# 这条链**不在这里挂** —— 写口只有一处，在 `scripts/seed-workshop.sh` 的 `link_workshop_skills`
+# （上面那次 `entry` 已经跑过它）。为什么收成一处：启动器与宿主自举都跑那个脚本，从前两处
+# 各写一遍（这里一段 bash + 宿主 TS 的 `linkSkills`），目标虽一致，却是**同一件事两个实现** ——
+# 哪天只有一边改了源或判据就会互相改指，而软链指到哪 skill 发现都**不报错**。
 # 稳定路径不直接软链到随包脚本：同上面那条 —— pnpm publish 之后
 # `bin/opencli-isolated` 是 644，软链过去一执行就是 Permission denied
 # （症状：启动体检永远说"隔离运行时没装好"，而它其实是没权限跑）。