@dsh-workbench/core 0.1.14 → 0.1.16

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.14",
+  "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.14"
+    "@dsh-workbench/shared": "0.1.16"
   },
   "scripts": {
     "build": "node scripts/build.mjs && node scripts/build-types.mjs",
@@ -95,7 +96,6 @@
     "typecheck": "tsc --noEmit",
     "arch": "arch-guard",
     "selfcheck": "node scripts/selfcheck.mjs",
-    "check:host": "node scripts/check-host.mjs",
     "check:runtimes": "node scripts/check-runtimes.mjs",
     "check": "npm run typecheck && npm run coverage && npm run arch && npm run check:runtimes && npm run selfcheck",
     "test": "vitest run",

package/scripts/seed-profile.sh

@@ -170,119 +170,10 @@ 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 [ -n "$GIT_TOP" ]; 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 [ -n "$GIT_TOP" ] && [ -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-<名字>`
-- 每个模块自己的四件事：`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
-
-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
+# 工坊是 DIY 模式的落点：agent 在那里造模块（一个模块一个目录），而 **DIY 会话的 cwd 就是它**。
+# 骨架 + 依赖 + 稳定入口都交给 `scripts/seed-workshop.sh` —— 启动器（bin/dsh-workbench）
+# 每次启动也调它（幂等），所以"干净机器上工坊是空的"这件事不再需要人来处理。
+bash "$REPO_DIR/scripts/seed-workshop.sh"
 
 # 装 bundle 的目标：开发态是这个仓库（link），安装包态是源上那个包。
 # 判据是「git 顶层在不在」—— npm pack 的产物里不含 .git（见 package.json 的 files）。