@dsh-workbench/core 0.1.15 → 0.1.16

package/README.md

@@ -36,6 +36,23 @@ npx @dsh-workbench/core                       # ② 起工作台，默认 :3081
 
 打开 <http://localhost:3081> 就是工作台。你原来那份 `dsh web` 继续用 `:3080`，两边互不影响。
 
+## 另一种装法：就在你那份 `dsh web` 里装（单 profile）
+
+不想多一个 profile、多一个端口、多一个进程？那就**在 `dsh web` 里装**——
+侧栏 **Plugins → Add plugin**，填 `@dsh-workbench/core`（包在公网 npm 上，默认源就能解析），
+**Install → Enable now**，然后**刷新一次页面**。左栏换成工作台，右侧多出面板列。
+
+- 装的是**你现在这个 profile**：会话、存储、附件接着用你原来的（**不分家**）；
+  面板与模块配置照旧落在 `~/.dsh/workbench/**`。
+- 外壳会**自己把缺的那几件补齐**（建隔离 opencli 的入口、把 `dsh-wb-module` 挂上 PATH、
+  后台把 DIY 工坊骨架建起来）—— 不需要跑 `setup`、也不需要启动器。后台脚本的输出在
+  `~/.dsh/workbench/seed.log`（DIY 工坊的依赖是几百 MB，第一次启动在后台下）。
+- 第一次打开照旧走启动体检，自己装隔离 opencli 运行时；装不上时给一条能照抄到终端的命令。
+- 与 `setup` 那条路的差别：**没有独立端口/进程**、**会话不隔离**、**改外壳源码不热重载**，
+  DIY 工坊的依赖是第一次启动在后台装的。取舍与理由见
+  [ADR-0037](https://github.com/code-farmer-i/dsh-workbench/blob/main/docs/adr/0037-workbench-installs-into-any-profile.md)。
+- 想回到"两条实例并存"，就删掉这个包（Plugins 页里卸载），再走上面的 `setup` 那条路 —— 数据都还在。
+
 ## 首次打开会自己做什么
 
 - **装 opencli 的隔离运行时**：启动体检自己装，落在 `~/.dsh/workbench/opencli/`，
@@ -61,6 +78,8 @@ npx @dsh-workbench/core                       # ② 起工作台，默认 :3081
 
 ## 和 `dsh web` 的关系
 
+（下面说的是 `setup` 那条路；装在 web 自己的 profile 里那条见上一节。）
+
 - **另一个 profile、另一个端口、另一个进程**：`workbench` profile 在 `~/.dsh/profiles/workbench`；
   会话 / 存储 / 附件 / 模块配置全走 `~/.dsh/workbench/**`，与 web **数据分家**。只有一样有意共享：
   API 凭据（`~/.dsh/.credentials.yaml`，一机一把 key）。

package/bin/dsh-workbench

@@ -258,8 +258,12 @@ fi
 # （症状：启动体检永远说"隔离运行时没装好"，而它其实是没权限跑）。
 # 所以这里写一个**我们自己拥有**的转发脚本，x 位由 chmod 当场给。
 # ⚠️ 先 rm -f：旧版本留下的软链还在时，`>` 会顺着软链把真脚本覆盖掉。
+# ⚠️ DSH_HOME 必须**钉在命令里**：执行缝不继承它，而 bin/opencli-isolated 用
+# `${DSH_HOME:-$HOME/.dsh}` 推根 —— 不钉的话，DSH_HOME 不是默认值的机器上，
+# 隔离运行时会被认成用户真家目录那一份（实测：同一条路上的 seed-workshop.sh
+# 就是这样把入口写进了 ~/.dsh，见 ADR-0037 的"执行缝不继承 DSH_HOME"）。
 rm -f "$OPENCLI_ROOT/bin/opencli"
-printf '#!/bin/sh\nexec bash %q "$@"\n' "$DSH_WORKBENCH_ROOT/bin/opencli-isolated" \
+printf '#!/bin/sh\nexec env DSH_HOME=%q bash %q "$@"\n' "$DSH_HOME" "$DSH_WORKBENCH_ROOT/bin/opencli-isolated" \
   >"$OPENCLI_ROOT/bin/opencli"
 chmod +x "$OPENCLI_ROOT/bin/opencli"
 export DSH_WORKBENCH_OPENCLI="$OPENCLI_ROOT/bin/opencli"

package/cordis.patch.yml

@@ -62,6 +62,28 @@
     # schemastery 的 Config 不吞未知键（已实测），所以这个选项会原样传进 chokidar。
     followSymlinks: false
 
+# ── 工作台运行时的**可写根**：让外壳在**任意 profile** 里自足 ──────────────
+#
+# 这一行与 `--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` 不在它下面。
+#
+# 为什么放**组合层**而不是让宿主自己改策略：`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')
+
 - insert:
     - id: workbench
       name: '@dsh-workbench/core'

package/dist/host/index.js

@@ -1,6 +1,8 @@
 import { createHash, randomUUID } from "node:crypto";
-import fs, { existsSync, readFileSync, readdirSync, realpathSync, statSync } from "node:fs";
-import path, { join, resolve, sep } from "node:path";
+import fs, { chmodSync, closeSync, existsSync, mkdirSync, openSync, readFileSync, readdirSync, readlinkSync, realpathSync, rmSync, statSync, symlinkSync, writeFileSync } from "node:fs";
+import path, { delimiter, dirname, join, resolve, sep } from "node:path";
+import { spawn } from "node:child_process";
+import { fileURLToPath } from "node:url";
 //#region ../shared/dist/config/constants.js
 var PLUGIN_ID = "@dsh-workbench/core";
 var API_PREFIX = "/workbench/api";
@@ -4028,6 +4030,153 @@ function assembleHostUnits(registry) {
 	for (const face of HOST_UNITS) registry.register(face);
 }
 //#endregion
+//#region src/shared/api/host/runtime-seed.ts
+var WORKSHOP_SKILLS_DIR = "workbench-module-diy";
+function runtimeSeedPaths(root) {
+	const opencliRoot = join(root, "opencli");
+	const opencliBinDir = join(opencliRoot, "bin");
+	const workshop = join(root, "diy");
+	return {
+		root,
+		entryDir: join(root, "bin"),
+		opencliRoot,
+		opencliBinDir,
+		opencliBin: join(opencliBinDir, "opencli"),
+		opencliHome: join(opencliRoot, "home"),
+		workshop,
+		workshopPackages: join(workshop, "packages"),
+		workshopManifest: join(workshop, "package.json"),
+		skillsLink: join(workshop, ".agents", "skills", WORKSHOP_SKILLS_DIR)
+	};
+}
+function runtimeSeedRootOf(ctx) {
+	const homePath = ctx.get("dshHomePath");
+	if (typeof homePath !== "function") return null;
+	try {
+		return homePath("workbench");
+	} catch {
+		return null;
+	}
+}
+function packageRootOf(moduleUrl) {
+	return dirname(dirname(dirname(fileURLToPath(moduleUrl))));
+}
+function isInstalledCopy(packageRoot) {
+	return packageRoot.split(sep).includes("node_modules");
+}
+function opencliWrapperScript(packageRoot, home) {
+	const script = join(packageRoot, "bin", "opencli-isolated");
+	return `#!/bin/sh\nexec env DSH_HOME=${quoteShellArg(home)} bash ${quoteShellArg(script)} "$@"\n`;
+}
+function workshopSeedPlan(packageRoot, home, root) {
+	const script = join(packageRoot, "scripts", "seed-workshop.sh");
+	const env = { DSH_HOME: home };
+	const log = join(root, "seed.log");
+	return {
+		entry: {
+			file: "bash",
+			args: [script, "entry"],
+			env,
+			log
+		},
+		full: {
+			file: "bash",
+			args: [script],
+			env,
+			log
+		}
+	};
+}
+function runDetached(command, onError, spawnImpl = spawn) {
+	let fd = null;
+	try {
+		fd = openSync(command.log, "a");
+		const child = spawnImpl(command.file, [...command.args], {
+			env: {
+				...process.env,
+				...command.env
+			},
+			detached: true,
+			stdio: [
+				"ignore",
+				fd,
+				fd
+			]
+		});
+		child.on("error", (error) => onError(`自举脚本没跑起来（${command.file}）：${String(error)}`));
+		child.unref();
+	} catch (error) {
+		onError(`自举脚本没跑起来（${command.file}）：${String(error)}`);
+	} finally {
+		if (fd !== null) closeQuietly(fd);
+	}
+}
+function closeQuietly(fd) {
+	try {
+		closeSync(fd);
+	} catch {
+		return;
+	}
+}
+function prependPath(entryDir, env = process.env) {
+	const parts = (env.PATH ?? "").split(delimiter).filter((part) => part !== "");
+	if (parts.includes(entryDir)) return false;
+	env.PATH = [entryDir, ...parts].join(delimiter);
+	return true;
+}
+function seedRuntimeFiles(options) {
+	const paths = runtimeSeedPaths(options.root);
+	const done = [];
+	try {
+		for (const dir of [
+			paths.entryDir,
+			paths.opencliBinDir,
+			paths.opencliHome,
+			paths.workshopPackages
+		]) mkdirSync(dir, { recursive: true });
+		const wanted = opencliWrapperScript(options.packageRoot, options.home);
+		if (readText(paths.opencliBin) !== wanted) {
+			rmSync(paths.opencliBin, { force: true });
+			writeFileSync(paths.opencliBin, wanted, "utf8");
+			chmodSync(paths.opencliBin, 493);
+			done.push(paths.opencliBin);
+		}
+		if (linkSkills(paths.skillsLink, join(options.packageRoot, "skills", "workbench-module-diy"), options.log)) done.push(paths.skillsLink);
+	} catch (error) {
+		options.log?.(`自举没做完：${String(error)}`);
+	}
+	return done;
+}
+function readText(file) {
+	try {
+		return readFileSync(file, "utf8");
+	} catch {
+		return null;
+	}
+}
+function readLink(link) {
+	try {
+		return readlinkSync(link);
+	} catch {
+		return null;
+	}
+}
+function linkSkills(link, source, log) {
+	if (!existsSync(source) || readLink(link) === source) return false;
+	try {
+		mkdirSync(dirname(link), { recursive: true });
+		rmSync(link, {
+			force: true,
+			recursive: true
+		});
+		symlinkSync(source, link, "dir");
+		return true;
+	} catch (error) {
+		log?.(`DIY 指引没挂上（${link}）：${String(error)}`);
+		return false;
+	}
+}
+//#endregion
 //#region src/shared/api/host/events.ts
 var HEARTBEAT_MS = 25e3;
 function frame(payload) {
@@ -5294,9 +5443,34 @@ var inject = ["webServer"];
 function asArgs(value) {
 	return typeof value === "object" && value !== null ? value : {};
 }
+function warn(ctx, message) {
+	ctx.logger?.warn?.(`[dsh-workbench] ${message}`);
+}
+function seedWorkbenchRuntime(ctx) {
+	const root = runtimeSeedRootOf(ctx);
+	if (root === null) return;
+	const home = dirname(root);
+	const packageRoot = packageRootOf(import.meta.url);
+	const paths = runtimeSeedPaths(root);
+	const log = (message) => warn(ctx, message);
+	for (const file of seedRuntimeFiles({
+		root,
+		home,
+		packageRoot,
+		log
+	})) log(`自举写下 ${file}`);
+	if (prependPath(paths.entryDir)) log(`PATH 前插 ${paths.entryDir}`);
+	const plan = workshopSeedPlan(packageRoot, home, root);
+	runDetached(plan.entry, log);
+	if (isInstalledCopy(packageRoot) && !existsSync(paths.workshopManifest)) {
+		log("DIY 工坊骨架不在：后台建起来（第一次会下载依赖，几百 MB）");
+		runDetached(plan.full, log);
+	}
+}
 function apply(ctx) {
 	const facts = createFactLog();
 	const values = createValueHandoff();
+	seedWorkbenchRuntime(ctx);
 	const opencli = opencliCommandOf(ctx);
 	const routes = {
 		health: healthHandler(ctx, opencli),

package/dist/types/shared/api/host/runtime-seed.d.ts

@@ -0,0 +1,40 @@
+import { spawn } from 'node:child_process';
+import type { DshHostContext } from '@dsh-workbench/shared';
+export declare const WORKSHOP_SKILLS_DIR = "workbench-module-diy";
+export type SeedLog = (message: string) => void;
+export interface RuntimeSeedPaths {
+    readonly root: string;
+    readonly entryDir: string;
+    readonly opencliRoot: string;
+    readonly opencliBinDir: string;
+    readonly opencliBin: string;
+    readonly opencliHome: string;
+    readonly workshop: string;
+    readonly workshopPackages: string;
+    readonly workshopManifest: string;
+    readonly skillsLink: string;
+}
+export interface RuntimeSeedOptions {
+    readonly root: string;
+    readonly home: string;
+    readonly packageRoot: string;
+    readonly log?: SeedLog;
+}
+export declare function runtimeSeedPaths(root: string): RuntimeSeedPaths;
+export declare function runtimeSeedRootOf(ctx: DshHostContext): string | null;
+export declare function packageRootOf(moduleUrl: string): string;
+export declare function isInstalledCopy(packageRoot: string): boolean;
+export declare function opencliWrapperScript(packageRoot: string, home: string): string;
+export interface SeedCommand {
+    readonly file: string;
+    readonly args: readonly string[];
+    readonly env: Readonly<Record<string, string>>;
+    readonly log: string;
+}
+export declare function workshopSeedPlan(packageRoot: string, home: string, root: string): {
+    readonly entry: SeedCommand;
+    readonly full: SeedCommand;
+};
+export declare function runDetached(command: SeedCommand, onError: SeedLog, spawnImpl?: typeof spawn): void;
+export declare function prependPath(entryDir: string, env?: NodeJS.ProcessEnv): boolean;
+export declare function seedRuntimeFiles(options: RuntimeSeedOptions): readonly string[];

package/dist/types/shared/api/host/runtime-seed.test.d.ts

@@ -0,0 +1 @@
+export {};

package/docs/HANDOFF.md

@@ -1,37 +1,55 @@
 # 把工作台给别人用
 
-工作台是一个 **dsh 插件包**，发在内网源上（地址只写在 `package.json` 的
-`publishConfig.registry` 一处）。别人装的是**独立 profile**（`workbench`）——
-他自己那份 `dsh web` 一行不改，两边可以同时开着。
+工作台是一个 **dsh 插件包**，现在发在**公网 npm** 上：`@dsh-workbench/core`
+（实测 `npm view @dsh-workbench/core version` 出号，`npm pack` 的产物里
+`dsh.bundle.patch` / `cordis.patch.yml` / `client.js` / `dist/host/index.js` 都在）。
+所以**对方不需要配任何私有源**就能装。
 
-一句话：**登录内网源 → `setup` → 起**。
+两种给法，先挑一种：
+
+| 给法 | 对方要做的事 | 换来的 |
+| --- | --- | --- |
+| **A. 装进他自己的 `dsh web`**（最短） | Plugins → Add plugin → `@dsh-workbench/core` → Enable now → **刷新页面** | 就在那份 web 里换成工作台；**同一个 profile、同一份会话**、同一个端口 |
+| **B. 独立实例**（要数据分家就选它） | `npx --yes @dsh-workbench/core@latest setup` → `npx @dsh-workbench/core` | 另一个 profile、另一个端口（:3081），他自己那份 `dsh web` **一行不改** |
+
+一条路径一句话：**A = 点一下装（单 profile）；B = `setup` 然后起（双 profile）**。
+取舍与代价见 [`docs/adr/0037`](../../../docs/adr/0037-workbench-installs-into-any-profile.md)。
 
 ## 一、对方机器上要有的
 
 | #   | 东西                         | 为什么                                                                                                                               | 怎么有                                       |
 | --- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------- |
 | 1   | `dsh`                        | 本体。本仓库在 `0.1.7-rc.2` 上验过                                                                                                   | `npm i -g @deepseek-ai/dsh`（公网 npm 上有） |
-| 2   | `node` + **`pnpm`**          | dsh 的 `plugin` 子命令是**转发给 pnpm** 的；没有 pnpm 会直接报 `dsh: pnpm was not found`                                             | 各自装                                       |
-| 3   | 跑过一次 `dsh web`           | `setup` 拿 `~/.dsh/profiles/web` 当模板（bundle 清单 + 设置快照 + patch 点名的依赖）。没有它会**明确报错**，不会静默建出半个 profile | `dsh web`                                    |
-| 4   | 内网源登录                   | 包带 `@pagoda` scope，公网上没有它                                                                                                   | 见第二节                                     |
-| 5   | Coding 账号 + opencli 登录态 | 面板的数据来自 opencli 的 coding 插件                                                                                                | 见第四节                                     |
+| 2   | `node` + **`pnpm`**          | dsh 的 `plugin` 子命令（以及 web 的 Plugins 页）都是**转发给 pnpm** 的；没有 pnpm 会直接报 `dsh: pnpm was not found`                 | 各自装                                       |
+| 3   | 跑过一次 `dsh web`           | 走 A 需要它给出那个 profile；走 B 时 `setup` 拿 `~/.dsh/profiles/web` 当模板。没有它会**明确报错**，不会静默建出半个 profile          | `dsh web`                                    |
+| 4   | 一个能解析这个包的源         | 包在**公网 npm** 上，默认源即可。只有将来改发内网源时，才要 `npm config set @<scope>:registry …` + `npm login`（带 scope 的包只去 `.npmrc` 里给这个 scope 指的源找） | `npm view @dsh-workbench/core version` 出号即可 |
+| 5   | Coding 账号 + opencli 登录态 | 面板的数据来自 opencli 的 coding 插件                                                                                                | 见第五节                                     |
 
-## 二、两步装
+## 二、A：装进他自己的 `dsh web`（插件页，一条龙）
 
-```bash
-# ① 让 pnpm/npx 知道 @pagoda 这个 scope 在哪个源，并登录（各一次）
-npm config set @pagoda:registry "$NPM_REGISTRY"
-npm login --registry=$NPM_REGISTRY
+在 `dsh web`（:3080）里：
+
+1. 侧栏 **Plugins → Add plugin**，填 `@dsh-workbench/core`；
+2. **Install → Enable now**；
+3. **刷新一次页面**（客户端 bundle 是页面加载时装进去的）。
+
+装完左栏就是工作台、右侧多出面板列。缺的那几件（隔离 opencli 的入口、`dsh-wb-module`、
+DIY 工坊骨架、可写根）由**外壳自己**补齐 —— 不用跑 `setup`，也不用起第二个实例。
+
+差别（先跟对方说清）：**会话 / 存储不分家**（接着用他原来那份）、**没有独立端口与进程**、
+**改外壳源码不热重载**、DIY 工坊依赖是首次启动在后台装的。
 
-# ② 建 profile + 把工作台装进去，然后起（占 :3081，dsh web 继续用 :3080）
+## 三、B：两步装（独立 profile，占 :3081）
+
+```bash
+# ① 建 profile + 把工作台装进去，然后起（占 :3081，dsh web 继续用 :3080）
 npx --yes @dsh-workbench/core@latest setup
 npx @dsh-workbench/core
 ```
 
-**为什么必须有 `@pagoda:registry` 那一行**：不带 scope 的 `dsh-workbench`
-公网上已经有别人的一个（`lee259/dsh-workbench`），所以我们的包必须带 scope；
-而带 scope 的包，pnpm / npx 只会去 `.npmrc` 里**给这个 scope 指的那个源**找它 ——
-不设这一行，症状是 `404 Not Found - GET https://registry.npmjs.org/@pagoda%2fdsh-workbench`。
+> 若团队后来把包改发到内网源，这两条命令之前要各加一次：
+> `npm config set @<scope>:registry "$NPM_REGISTRY"` 与 `npm login --registry=$NPM_REGISTRY`。
+> 不设的话症状是 `404 Not Found - GET https://registry.npmjs.org/@<scope>%2F…`。
 
 > ⚠️ **0.1.6 的已知缺陷**：`setup` 可能死在
 > `…/@dsh-workbench/core/scripts/seed-profile.sh: Permission denied`（发出去的包里随包脚本丢了
@@ -76,7 +94,7 @@ Settings → 插件里把 `@dsh-workbench/core` 关掉后，工作台会**退化
 要重新同步得重跑 `setup`。有意共享的只有两样：**API 凭据**（`~/.dsh/.credentials.yaml`，
 一机一把 key）和 `$DSH_HOME/cordis.patch.yml`（机器公共层，对所有 profile 实时生效）。
 
-## 三、不想用 npx？仓库副本也可以
+## 四、不想用 npx？仓库副本也可以
 
 `bin/dsh-workbench` 认得出自己是不是仓库副本（看有没有 `.git`）：
 
@@ -88,7 +106,7 @@ git clone <仓库> && cd dsh-workbench && pnpm install
 
 两种身份装出来的东西**同一个包名**，所以对方以后换成正装也不会打架。
 
-## 四、数据通路（面板要有数据）
+## 五、数据通路（面板要有数据）
 
 1. **opencli 隔离运行时**。第一次打开工作台，启动体检会**自己装**它（`@jackwener/opencli`，
    公网包），落在 `$DSH_HOME/workbench/opencli/toolchain/`，**与对方本机的 `opencli` 完全隔离**
@@ -142,35 +160,52 @@ git clone <仓库> && cd dsh-workbench && pnpm install
    装的时候 `bin/opencli-isolated` 会把 `~/.npmrc` 指回去，就为了拿到源的 token；
    npm 缓存则一律落在那台机器自己的隔离运行时里（**不碰** `~/.npm`）。
 
-## 五、不用管的
+## 六、不用管的
 
 - **`dsh web` 一行不改**：`./scripts/verify.sh` 是外部证据 —— 比对 web 的 profile 哈希、
   两个 profile 的组合树差异、数据是否分家，而不是自证。
 - 会话 / 存储 / 附件各自独立；工作台是**另一个端口、另一个进程**，可与 `dsh web` 同开。
 - 改工作台设置只落在 `profiles/workbench/cordis.patch.yml`。
 
-## 六、发版（发起人）
+## 七、发版（发起人）
 
 ```bash
 cd <仓库根>
-pnpm release:dry   # 门禁 + 发布计划 + 打包清单校验，不联网、不真发
-pnpm release             # 真发（发前会再跑一次门禁）
+pnpm release:dry   # 彩排：门禁 → 选版本号 → 构建 → publish --dry-run；不上传，结束回滚版本号
+pnpm release       # 真发：上面那一串 + 逐包上传 + git 收尾（提交 / tag / 推送）
 ```
 
-提版本号之后再发：`npm version patch`。脚本把几个坑写成了**硬失败**：
+不用先 `npm version`：版本号由脚本选（交互，或 `--target 0.2.0`），同步到根与所有包的
+manifest；彩排结束、以及「零上传」的失败，都会自动回滚。
+
+**门禁整次发布只跑一遍**（preflight 那次 `pnpm run check`；`--resume` 也跑）。发布走
+`pnpm -r publish --ignore-scripts`：各包的 `prepublishOnly` / `prepack` 是留给**手敲**
+`pnpm publish` 的人兜底的（外壳那份 = 整仓门禁）；不关掉它们，pnpm 会在**彩排与真发各再跑
+一遍**整门禁 —— 一次发布就是 3 遍门禁 + 3 遍 vitest + 每个包多两轮构建（实测 pnpm 10.32.1：
+`--dry-run` 一样触发）。来历见
+[`.scratch/dsh-ui-alignment/spec.md`](../../../.scratch/dsh-ui-alignment/spec.md) §18.45。
+
+脚本把这几件事变成**硬失败**（都在任何上传之前）：
+
+- **工作区不干净** → 默认拒（发布会把它们 `git add -A` 一起提交），`--allow-dirty` 才放行；
+- **目标版本必须高于当前版本**；目标版本若在源上**已完整存在**，直接拒（要补发用 `--resume`）；
+- **npm 没登录** → 就地拉起 `npm login`；
+- **彩排不过**（`publish --dry-run` 打不出包）→ 零上传退出。
+
+只能自己盯、脚本不查的两条：
 
 - **`dist/` 在 `.gitignore` 里**：npm 打包的兜底就是 `.gitignore`，不在 `files` 里显式列出
-  就会漏掉构建产物 —— 症状不是报错，而是"别人装上后宿主侧起不来"；
-- 版本号在源上已被占（pnpm 到最后一步才报，白等一轮门禁）；
-- `private: true` 没摘；
+  就会漏掉构建产物 —— 症状不是报错，而是"别人装上后宿主侧起不来"（外壳与 `module-hello` 的
+  `files` 都显式列了 `dist` / `client.js`，但发布脚本不核这件事）；
 - **随包脚本的可执行位**：`pnpm publish` 只给 `package.json#bin` 点名的那**一个**文件 755，
   其余在 tarball 里一律 644（`npm pack` 会保留，而 git 里的 x 位不进 tarball）——
   所以随包脚本一律不吃 x 位：启动器里 `bash` 呼 `seed-profile.sh`、opencli 那条稳定路径写成
-  自己拥有的转发脚本，`selfcheck` 有一条判据钉着。这类错**本机复现不出来**，只在别人机器上炸
+  自己拥有的转发脚本。这条由外壳 `selfcheck` 的判据钉着（门禁里跑）。
+  这类错**本机复现不出来**，只在别人机器上炸
   （0.1.6 就是这么坏在 `seed-profile.sh: Permission denied` 上的，见
   [`.scratch/dsh-ui-alignment/spec.md`](../../../.scratch/dsh-ui-alignment/spec.md) §18.41）。
 
-## 七、版本与兼容（实话）
+## 八、版本与兼容（实话）
 
 `package.json` 的 `peerDependencies` 里**没有** `@deepseek-ai/dsh`，这是有意的：
 dsh 目前是 `0.1.7-rc.2`（预发布），声明范围会让版本不一致的人**装不上**；不声明则是
@@ -195,29 +230,31 @@ dsh 会用这条做**安装预检**（`evaluatePluginCompatibility`），不满
 ## 发布（一个脚本，一条命令）
 
 ```bash
-pnpm release            # 门禁 → 计划 → 逐包：登录 → 版本没被占 → 打包清单 → 发
-pnpm release:dry        # 不联网：门禁 → 计划 → 打包清单校验
+pnpm release            # 门禁 → 选版本号 → 构建 → 彩排 → 逐包上传 → git 收尾
+pnpm release:dry        # 同上，但 publish 只 dry-run：零上传，结束回滚版本号
 ```
 
-`scripts/release.mjs` 是**唯一**的发布入口（曾经的 `publish.sh` + `release-plan.mjs` 已合并进来）。
-谁要发、发到哪、要发什么，全部从各包自述清单读，不写死名单：
+`scripts/release.mjs` 是**唯一**的发布入口。发什么、发到哪、谁先谁后，都从各包自述清单读：
 
-- **发不发** = 有 `publishConfig.registry`，或 `publishConfig.access === 'public'`（默认 npmjs）；`private: true` 一律不发；
-- **发什么** = 包自己声明的 `exports` / `bin` / `dsh.bundle.patch` 那几份文件必须在（`dist/`、`client.js` 在 `.gitignore` 里，漏了 `files` 的症状是"装上后宿主侧起不来"，不是报错）；
-- **什么顺序** = 依赖优先（`shared` → `core` → 用到它们的模块）；依赖的包这次不发就报错；
-- **公网包**用 `--access public`，内网源不加这个参数。
+- **发不发** = `packages/*` 一级目录里，非 `private` 且自述了 `publishConfig`（`access` 或 `registry`）；
+  私有模块必须显式写发布目标这条，由门禁的 `contracts` 判据守着（不许默认落到公网）；
+- **发到哪** = 包自己的 `publishConfig.registry`（pnpm 在 recursive publish 里逐包取它），没写的
+  落到脚本顶部的 `REGISTRY`（npmjs）；本仓现在这 4 个包都发公网，命令一律带 `--access public`。
+  注意 `inspectTarget` **只查 npmjs** —— "这个版本发出去没有"对发内网源的包看不准；
+- **什么顺序** = pnpm 自己拓扑排序（`shared` → `core` → 用到它们的模块）；
+- **发什么** = pnpm 按各包 `files` / `.gitignore` 打包；**打包清单没人替你核**（见上一章
+  「只能自己盯」）。要看清单用 `dsh-wb-module publish`：它只 dry-run、打印清单，不发布。
 
-它替你把四件事变成硬失败：**门禁绿 · 计划成立 · 打包清单真的有产物 · 这个版本号在源上还没人占**。
-发布用 `pnpm publish`（不是 `npm publish`）：只有 pnpm 会把 `workspace:*` 改写成真实版本，
+发布必须走 `pnpm publish`（不是 `npm publish`）：只有 pnpm 会把 `workspace:*` 改写成真实版本，
 `npm pack` / `npm publish` 不会 —— 直接发别人装不上。
 
-### 版本同步规则（脚本会替你拦）
+### 版本同步规则（约定 —— 门禁只守其中一条）
 
 | 关系 | 规则 |
 | --- | --- |
-| 模块 ↔ 外壳 | 模块 `peerDependencies['@dsh-workbench/core'] = ^0.1.0`。**`^0.x` 锁次版本**：外壳升到 `0.2.0` 时 `^0.1.0` 不再满足，脚本当场报 —— 要把每个模块的范围一起改（或一起升） |
+| 模块 ↔ 外壳 | 模块 `peerDependencies['@dsh-workbench/core'] = ^0.1.0`。**`^0.x` 锁次版本**：外壳升到 `0.2.0` 时 `^0.1.0` 不再满足 —— 要把每个模块的范围一起改（或一起升）。门禁只守"peer 依赖存在"（`contracts` 判据），**范围合不合体没人替你算**，靠自觉 |
 | `shared` ↔ 外壳/模块 | 依赖写的是 `workspace:*`，发布时会被改写成**当时那个版本号** → `shared` 必须先发；`shared` 升版后，用到它的包要重新发一次才会带上新范围 |
-| `module-tools` ↔ `init` 模板 | 模板里 `@dsh-workbench/core` / `module-tools` 的范围要跟着本仓版本走，否则 `init` 生成的是过期范围（脚本已检查这一条） |
+| `module-tools` ↔ `init` 模板 | 模板里 `@dsh-workbench/core` / `module-tools` 的范围要跟着本仓版本走，否则 `init` 生成的是过期范围 —— **现在没有任何判据检查它**（上一版 release 脚本查过，换成现在这份之后这条没了），升外壳次版本时记得一起改 |
 
 ### 中断了怎么续跑（发布是可中断的）
 
@@ -228,7 +265,8 @@ pnpm release:resume      # 从现场恢复；**已在源上的包自动跳过**
 ```
 
 - **不带 `--resume` 重跑会被拒**：目标版本必须高于当前版本；源上若已有同名同版本，脚本会说"先提版本号"。这正是为续跑设计的语义（不是 bug）。
+- **`--resume` 照样跑一遍门禁**：断了之后很可能改过包，而门禁整次发布只有 preflight 那一处。真要跳过用 `--skip-gate`（发布不会再补跑一遍）。
 - `pnpm release:dry` 是**彩排**：改版本号 → 构建 → `publish --dry-run` → **回滚本地版本号**，不上传。
 - 发布**成功之后**才做 git 收尾：`git add -A` → `commit -m "chore: 发布版本 v<ver>"` → `tag v<ver>` → `push` → `push origin v<ver>`。git 收尾失败时包已经发出去了，脚本会把该手打的命令打出来，并提示可以 `pnpm release:resume`。
-- 常用旗标：`--target <ver>` 跳出版本选择 · `-y/--yes` 跳过确认 · `--allow-dirty` · `--skip-gate`（不推荐） · `--skip-rehearsal`（不推荐）。
+- 常用旗标：`--target <ver>` 跳出版本选择 · `-y/--yes` 跳过确认 · `--allow-dirty` · `--skip-gate` / `--skip-rehearsal`（都不推荐） · `--skip-build`（用磁盘上现有产物 —— `prepack` 已关，不再兜底重建）。
 - 依赖：`enquirer`（交互选择版本）与 `semver`（版本比较）是根上的 devDependencies。

package/docs/OPERATIONS.md

@@ -28,7 +28,28 @@
 前提：`dsh` 和 `pnpm` 在 PATH 上（`dsh plugin` 是转发给 pnpm 的），
 且 `~/.dsh/profiles/web` 已存在（跑过一次 `dsh web` 即可）。
 
-**给别人用**（发包到内网源、对方要登录内网源 / Coding）见 [`HANDOFF.md`](HANDOFF.md)。
+**给别人用**（两条路：插件页装进他自己的 web / 独立实例 `setup`；包在公网 npm 上）见 [`HANDOFF.md`](HANDOFF.md)。
+
+### 变体：装进**当前** profile（在 `dsh web` 里装，不起第二个实例）
+
+`dsh web` 侧栏 **Plugins → Add plugin** → 填 `@dsh-workbench/core`（公网 npm 上有，默认源即可）
+→ **Install → Enable now** → **刷新页面**。装的就是 `dsh web` 自己那个 profile。
+
+**完成判据**：刷新后左栏是工作台的、右侧出现面板列；`$DSH_HOME/workbench/opencli/bin/opencli`
+存在且指向本包 `bin/opencli-isolated`；`$DSH_HOME/workbench/bin/dsh-wb-module` 可执行
+（这三条不再依赖启动器 —— 宿主自举写的）。
+
+这条路上没有启动器，缺的几件由**宿主自举**补齐（建目录、写隔离 opencli 入口、前插 `PATH`、
+后台建 DIY 工坊骨架），可写根由 bundle 层那一行 `sandbox-policy` 放行 —— 见
+[ADR-0037](../../../docs/adr/0037-workbench-installs-into-any-profile.md)。
+
+自举是**静默**的：它写了什么只在宿主日志里，后台脚本（工坊骨架 / 依赖）的输出在
+`$DSH_HOME/workbench/seed.log`。DIY 那个工坊“怎么都没建起来”时先看这两个地方。
+
+差别：**会话 / 存储不隔离**（接着用你原来那份）、**没有独立端口与进程**、
+**改外壳源码不热重载**、DIY 工坊依赖是首次启动在后台装的（几百 MB，失败只落日志）。
+
+撤销：Plugins 页卸载 `@dsh-workbench/core`（配置与数据不清）；`~/.dsh/workbench/**` 想清就手删。
 
 ## 日常
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dsh-workbench/core",
-  "version": "0.1.15",
+  "version": "0.1.16",
   "description": "个人工作台：Agent 工作台外壳（左栏 + 常驻对话 + 自研右侧数据面板）。",
   "type": "module",
   "icon": "./icon.svg",
@@ -22,7 +22,7 @@
   "bin": {
     "dsh-workbench": "./bin/dsh-workbench"
   },
-  "//files": "npm 的兜底是 .gitignore —— 而 dist/ 在 .gitignore 里，不显式列出就会**漏掉宿主入口**（exports['.'] 指向它）。发出去之前用 npm pack --dry-run 数一遍 dist/ 有几条。skills/ 是 DIY 模式挂给 agent 的指引（经 skill-filesystem 的 customSkillDirs 挂载），漏了不报错、只是 DIY 的 agent 什么都不知道 —— selfcheck 有一条判据盯着它。",
+  "//files": "npm 的兜底是 .gitignore —— 而 dist/ 在 .gitignore 里，不显式列出就会**漏掉宿主入口**（exports['.'] 指向它）。发出去之前用 npm pack --dry-run 数一遍 dist/ 有几条。skills/ 是 DIY 模式挂给 agent 的指引（经 skill-filesystem 的 customSkillDirs 挂载），漏了不报错、只是 DIY 的 agent 什么都不知道 —— selfcheck 有一条判据盯着它。scripts/ 下是**随包出货的脚本**：启动器与宿主自举都要跑它们（seed-profile.sh / seed-workshop.sh），漏一个的症状是「仓库里怎么都对、装出去那台静默什么也没做」。",
   "files": [
     "dist",
     "client.js",
@@ -33,6 +33,7 @@
     "skills",
     "preset",
     "scripts/seed-profile.sh",
+    "scripts/seed-workshop.sh",
     "README.md",
     "docs/HANDOFF.md",
     "docs/OPERATIONS.md"
@@ -81,12 +82,12 @@
     "vite": "^8.3.1",
     "vitest": "^5.0.2"
   },
-  "//publishConfig": "只影响**发布这个包**，不影响别人解析依赖。内网源地址在这一处（交接文档里写给对方的也是这一条）。",
+  "//publishConfig": "只影响**发布这个包**，不影响别人解析依赖。现在发**公网 npm**（scripts/release.mjs 走 registry.npmjs.org），所以这里只有 access；哪天真要改发内网源，地址写在这一段的 registry 里（release.mjs 会优先读它）。",
   "publishConfig": {
     "access": "public"
   },
   "dependencies": {
-    "@dsh-workbench/shared": "0.1.15"
+    "@dsh-workbench/shared": "0.1.16"
   },
   "scripts": {
     "build": "node scripts/build.mjs && node scripts/build-types.mjs",

package/scripts/seed-workshop.sh

@@ -0,0 +1,216 @@
+#!/usr/bin/env bash
+#
+# DIY 工坊：骨架 + 稳定入口（`dsh-wb-module`）。
+#
+# 由两处共用，所以逻辑只有**一份**：
+#   · `seed-profile.sh`（= `dsh-workbench setup`）—— 第一次把工坊建起来、装依赖；
+#   · `bin/dsh-workbench`（每次启动）—— 入口每次重写一遍（幂等），骨架不在才自愈。
+#
+# 为什么启动器要自愈而不是只提醒：干净机器上 agent 进工坊第一件事就是 build / check，
+# 而"不在 workspace 里"报出来的话指着别处（实测卡在这一步，它读到的像是"模板写错了"）。
+# 提醒是对人的；agent 读不到那句提醒。
+#
+# 用法:
+#   bash scripts/seed-workshop.sh            # 完整：骨架（缺才建）+ overrides + 依赖（缺才装）+ 入口
+#   bash scripts/seed-workshop.sh entry      # 只写入口（每次启动用；别的都不碰）
+#
+# 幂等：存在的文件不覆盖、依赖在就跳过安装、重复跑不产生副作用。
+
+set -euo pipefail
+
+DSH_HOME="${DSH_HOME:-$HOME/.dsh}"
+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)"
+MODE="${1:-skeleton}"
+
+# ── 这份副本到底是"仓库副本"还是"装出来的副本" ──────────────────────────────
+#
+# `git rev-parse --show-toplevel` 只是"往上第一个 .git"——**装出来的副本也可能落在别人的
+# 仓库下面**。实测：`DSH_HOME` 恰好在某个 git 仓库里时（开发机上就是本仓），
+# `<profile>/node_modules/@dsh-workbench/core` 一路往上找到了那个仓库，于是这份副本被当成
+# 仓库副本，去 link 一个不存在的 `../module-tools`，脚本当场死在 `cd` 上 —— 而它是**后台**
+# 被拉起来的（宿主自举 / 启动器），症状就是"工坊怎么都没建起来，一声不响"。
+#
+# 所以认仓库要认**本仓的形状**：根上同时有 packages/workbench 与 packages/module-tools。
+if [ -n "$GIT_TOP" ] && [ -f "$GIT_TOP/packages/workbench/package.json" ] &&
+  [ -f "$GIT_TOP/packages/module-tools/package.json" ]; then
+  IN_REPO=1
+else
+  IN_REPO=0
+fi
+
+# ── 稳定入口：$DSH_HOME/workbench/bin/dsh-wb-module ──────────────────────────
+#
+# 为什么要它：指引让 agent 写 `pnpm exec dsh-wb-module …`（到处都对，但它依赖 cwd 在工坊里、
+# 且那句 pnpm 前缀每次都要写对）。这里给一个**与 cwd 无关**的同名入口，启动器把它
+# 挂进 PATH —— 于是"在工坊里"和"在别的目录里"都叫得动同一个工具链。
+#
+# 转发脚本而不是软链：同 `bin/opencli-isolated` 那条坑 —— pnpm publish 之后包里的脚本没有 x 位，
+# 软链过去一执行就是 Permission denied。x 位由 chmod 当场给。
+# ⚠️ 先 rm -f：旧版本留下的软链还在时，`>` 会顺着软链把真脚本覆盖掉。
+ENTRY_DIR="$DSH_HOME/workbench/bin"
+mkdir -p "$ENTRY_DIR"
+rm -f "$ENTRY_DIR/dsh-wb-module"
+cat >"$ENTRY_DIR/dsh-wb-module" <<EOF
+#!/bin/sh
+BIN="$DSH_HOME/workbench/diy/node_modules/.bin/dsh-wb-module"
+if [ -x "\$BIN" ]; then exec "\$BIN" "\$@"; fi
+if command -v pnpm >/dev/null 2>&1; then
+  exec pnpm --dir "$DSH_HOME/workbench/diy" exec dsh-wb-module "\$@"
+fi
+echo "dsh-wb-module: 工坊的依赖还没装 —— 先跑 dsh-workbench setup" >&2
+exit 127
+EOF
+chmod +x "$ENTRY_DIR/dsh-wb-module"
+
+if [ "$MODE" = "entry" ]; then
+  echo "→ DIY 工坊入口：$ENTRY_DIR/dsh-wb-module"
+  exit 0
+fi
+
+# ── 第 6 步：建 DIY 工坊 ────────────────────────────────────────────────
+#
+# 工坊是 DIY 模式的落点：agent 在那里造模块（一个模块一个目录），
+# 而 **DIY 会话的 cwd 就是它** —— dsh 的沙箱把"会话 cwd"当作 workspace-write 的边界，
+# 所以源码写在工坊里天然放行，不需要给用户开 danger-full-access。
+#
+# 为什么它是一个 pnpm workspace 而不是随便一个目录：模块要构建就得有
+# module-tools / core / shared / react / typescript / vitest；把它做成 workspace 根，
+# 依赖只装一次，每个模块只是 packages/ 下多一个目录。而且 module-tools 的发现逻辑
+# 认 `pnpm-workspace.yaml`，于是模块单独跑 check 时能找到同仓的外壳（kit / standalone 两条判据
+# 才不会静默跳过 —— 跳过等于没验）。
+#
+# 两个身份同 bin/dsh-workbench：**仓库副本**把三个 @dsh-workbench/* 用 link 指进本仓
+# （改工具链立刻生效），**安装包副本**从源上按版本装。
+DIY_DIR="$DSH_HOME/workbench/diy"
+mkdir -p "$DIY_DIR/packages"
+
+if [ "$IN_REPO" = "1" ]; then
+  CORE_SPEC="link:$REPO_DIR"
+  TOOLS_SPEC="link:$(cd "$REPO_DIR/../module-tools" && pwd)"
+  SHARED_SPEC="link:$(cd "$REPO_DIR/../shared" && pwd)"
+else
+  CORE_SPEC="@dsh-workbench/core@^$(node -p "require('$REPO_DIR/package.json').version" 2>/dev/null || echo 0)"
+  TOOLS_SPEC="@dsh-workbench/module-tools@^$(node -p "require('$REPO_DIR/package.json').version" 2>/dev/null || echo 0)"
+  SHARED_SPEC="@dsh-workbench/shared@^$(node -p "require('$REPO_DIR/package.json').version" 2>/dev/null || echo 0)"
+fi
+
+# 工坊必须**钉住自己那一代 pnpm**（与仓库根钉的同一个）。
+#
+# 不钉的话它用用户机器上那个 pnpm —— 实测这台是 11.21.0，而仓库钉的是 10.32.1，
+# 而**两代的设置住址与键名都不一样**：`store-dir` 在 pnpm 10 从 `.npmrc` 读、
+# 在 pnpm 11 只认 `pnpm-workspace.yaml` 里的 `storeDir`；放行依赖构建的键
+# 在 pnpm 10 是 `onlyBuiltDependencies`、11 是 `allowBuilds`（11 还会往
+# pnpm-workspace.yaml 里写一行 `esbuild: set this to true or false` 占位）。
+# 结果是同一份工坊配置在这台机器上对、在另一台上错，而且错法都是静默或半静默的。
+# 钉了之后两边一致，且这一整轮验证过的就是这一代。
+PNPM_PIN=""
+if [ "$IN_REPO" = "1" ] && [ -f "$GIT_TOP/package.json" ]; then
+  PNPM_PIN="$(node -p "require('$GIT_TOP/package.json').packageManager || ''" 2>/dev/null || true)"
+fi
+PNPM_PIN="${PNPM_PIN:-pnpm@10.32.1}"
+
+if [ -f "$DIY_DIR/package.json" ]; then
+  echo "→ DIY 工坊已存在，跳过建骨架（要重来就先删掉 ${DIY_DIR}）"
+else
+  echo "→ 建 DIY 工坊 $DIY_DIR"
+  cat >"$DIY_DIR/package.json" <<EOF
+{
+  "name": "dsh-workbench-diy",
+  "version": "0.0.0",
+  "private": true,
+  "description": "DIY 工坊：工作台模块在这里造。这个目录由 dsh-workbench 的 setup 生成，手改会被覆盖。",
+  "packageManager": "$PNPM_PIN",
+  "devDependencies": {
+    "@dsh-workbench/core": "$CORE_SPEC",
+    "@dsh-workbench/module-tools": "$TOOLS_SPEC",
+    "@dsh-workbench/shared": "$SHARED_SPEC",
+    "@types/node": "^24.19.0",
+    "@types/react": "^19.3.0",
+    "esbuild": "^0.28.2",
+    "react": "^19.3.0",
+    "typescript": "5.9",
+    "vitest": "^5.0.2"
+  }
+}
+EOF
+  cat >"$DIY_DIR/pnpm-workspace.yaml" <<'EOF'
+packages:
+  - "packages/*"
+
+# esbuild 的构建脚本要放行：pnpm 默认不跑依赖的 postinstall，而模块的构建就是 esbuild。
+# 不放行的话每次 install 都会打一行
+# `[ERR_PNPM_IGNORED_BUILDS] Ignored build scripts: esbuild@0.28.2` —— 看着像失败，
+# 其实退出码是 0（实测踩过）。
+# 钉在 10.32.1 之后这个键名是对的（同一代 pnpm 也从 package.json 的 `pnpm` 段读它，
+# 仓库根就是这么放的）；换 pnpm 11 会变成 `allowBuilds`，所以上面那句「钉住 pnpm」是前提。
+onlyBuiltDependencies:
+  - esbuild
+EOF
+  cat >"$DIY_DIR/.npmrc" <<EOF
+# 工坊自己的 store 与 cache。
+#
+# 为什么必须指进来：agent 的 shell 跑在**会话沙箱**里，可写根就是会话 cwd（= 这个目录）。
+# 而 pnpm 默认的 store（例如 ~/Library/pnpm/store/v10）与 npm 默认的 cache（~/.npm）
+# 都在可写根**之外** —— 不指进来的话，agent 在会话里跑一次 pnpm install 会被沙箱拒（EPERM），
+# 而"给模块加一个依赖"只有这一条路。setup 时的安装由人跑，不受沙箱限制，但用的也是这份配置，
+# 于是装一次之后 agent 那边也能继续装。
+store-dir=$DIY_DIR/.pnpm-store
+cache-dir=$DIY_DIR/.npm-cache
+EOF
+  cat >"$DIY_DIR/README.md" <<'EOF'
+# DIY 工坊
+
+工作台模块在这里造。**一个模块一个目录**，都住在 `packages/` 下。
+
+- 这个目录是「DIY 会话」的工作目录 —— 在对话里让 agent 造模块，它就写在这里。
+- 依赖已经装好（`@dsh-workbench/core` / `module-tools` / `shared` / react / typescript / vitest）。
+- 造一个新模块：`dsh-wb-module init <名字> --dir packages/module-<名字>`
+  （`dsh-wb-module` 挂在 PATH 上、与 cwd 无关；写成 `pnpm exec dsh-wb-module …` 也对）
+- 每个模块自己的四件事：`pnpm build` / `pnpm typecheck` / `pnpm test` / `pnpm selfcheck`，
+  外加 `dsh-wb-module check` 的十条判据。
+
+不要手改这个目录下的 `package.json` / `pnpm-workspace.yaml` / `.npmrc`：
+它们是 `dsh-workbench setup` 生成的，模块要加依赖就加在**模块自己**的 `package.json` 里。
+EOF
+fi
+
+# 工坊里只该有**一份** `@dsh-workbench/*` —— 模块自己声明的 `^0.1.x` 也算。
+#
+# 不钉的话 pnpm 会给每个模块**另装一份来源上的包**，于是同一个工坊里两代工具链并存：
+# 模块自己的 `pnpm build` / `pnpm exec dsh-wb-module` 用的是源上那份（模板、判据、报错都是旧的，
+# `init --template diy` 还会直接报"模板不存在"），而工坊根 `.bin/dsh-wb-module` 是 link 到本仓那份；
+# `check --only kit` 比的也会是那份旧外壳（实测：0.1.13 与 0.1.14 两台工具并存，全程一声不响）。
+#
+# 用 pnpm 的 overrides 而不是改模块模板：模板里写死 link 路径会把"装到别人机器上"这条弄坏，
+# overrides 活在**这个工坊**里，模块的 package.json 仍旧是干净的 `^0.1.x`。
+# 放在第一次 `pnpm install` **之前**，这样一次装就是对的；已存在的工坊再跑一次 setup 也会被修好。
+if [ "$IN_REPO" = "1" ] && [ -f "$DIY_DIR/package.json" ]; then
+  node - "$DIY_DIR/package.json" "$CORE_SPEC" "$TOOLS_SPEC" "$SHARED_SPEC" <<'NODE'
+const [file, core, tools, shared] = process.argv.slice(2);
+const fs = require('node:fs');
+const manifest = JSON.parse(fs.readFileSync(file, 'utf8'));
+manifest.pnpm = {
+  overrides: {
+    '@dsh-workbench/core': core,
+    '@dsh-workbench/module-tools': tools,
+    '@dsh-workbench/shared': shared,
+  },
+};
+fs.writeFileSync(file, `${JSON.stringify(manifest, null, 2)}\n`);
+NODE
+fi
+
+if [ -d "$DIY_DIR/node_modules" ]; then
+  echo "→ 工坊依赖已装，跳过"
+elif ! command -v pnpm >/dev/null 2>&1; then
+  echo "→ ⚠️ PATH 上没有 pnpm，工坊依赖没装。装好 pnpm 后跑一次：" >&2
+  echo "     cd $DIY_DIR && pnpm install" >&2
+else
+  echo "→ 装工坊依赖（第一次会下载 react / typescript / vitest，几百 MB，之后不再下）"
+  (cd "$DIY_DIR" && pnpm install 2>&1 | tail -6)
+fi