最小插件工作台：构建 → 注册 → 卸载

这是一项可以在本地真正跑起来的离线实验，步骤是：

用仓库自己的 TypeScript 编译器构建一个插件；
用真实 Cordis Context 和 Loader 加载构建产物；
移除 Loader entry，检查插件提供的服务已经消失、计时器已经清理。

它只证明最小插件生命周期，不证明完整 DSH Host、Web、CLI、模型请求或跨平台发布兼容性。

你要得到什么

完成后，你应能解释三件事：tsc 怎样把工作台的 src/minimal-plugin.ts 变成 study-tools/minimal-plugin-workbench/dist/minimal-plugin.js；Loader 怎样从构建后的模块创建一个 entry 并激活插件 Fiber；ctx.loader.remove() 怎样触发 Fiber 的 effect 清理、取消心跳计时器并注销服务。

工作台位于 study-tools/minimal-plugin-workbench。它没有真实模型、API key、HTTP 服务或网络依赖，适合在 Codespaces 或本机先完成第一条运行证据。

先安装和构建

在仓库根目录执行：

pnpm install
pnpm --dir study-tools/minimal-plugin-workbench run build

构建命令只编译 study-tools/minimal-plugin-workbench/src/minimal-plugin.ts，并在被忽略的 study-tools/minimal-plugin-workbench/dist/build-manifest.json 中记录构建入口和 SHA-256。构建失败时不要手动创建 study-tools/minimal-plugin-workbench/dist/minimal-plugin.js；运行器会拒绝缺少构建产物的状态。

运行真实 Loader 全流程

pnpm --dir study-tools/minimal-plugin-workbench run verify

运行器实际执行下面的动作：

创建新的 Cordis Context，安装真实 @deepseek-ai/cordis-plugin-loader。
让 Loader 从 study-tools/minimal-plugin-workbench/dist/minimal-plugin.js 创建一个 entry；这一步是模块导入、插件注册和 Fiber 激活，不是打印一行“注册成功”。
读取插件提供的 studyMinimalPlugin 服务，等待心跳计数增加，证明 effect 已经在运行。
调用 ctx.loader.remove(entryId)，等待 Loader 完成卸载。
断言服务不再能从 Context 读取、entry 数量为零、服务快照进入 disposed，并确认心跳清理函数已经写入清理时间。

成功输出类似下面的结构；entryId 每次可能不同，因为 Loader 为未指定 id 的临时 entry 生成唯一 id：

json

{
  "result": "PASS",
  "registration": {
    "service": "studyMinimalPlugin",
    "phase": "active",
    "tickCount": 6
  },
  "unload": {
    "phase": "disposed",
    "serviceAbsent": true,
    "entriesRemaining": 0,
    "heartbeatStable": true
  },
  "externalServices": {
    "modelRequests": 0,
    "networkRequests": 0
  }
}

这里的 tickCount 是插件自己的定时器对实际生命周期的可观察信号；它不是模型调用，也不是用固定文本伪造的结果。serviceAbsent: true 和 entriesRemaining: 0 才是卸载断言的重点。

对照源码阅读

src/minimal-plugin.ts：看 ctx.provide() 如何注册服务，以及 ctx.effect() 如何返回定时器清理函数。
src/run.ts：看构建产物如何交给 Loader，和卸载后的断言。
study-tools/minimal-plugin-workbench/scripts/build.mjs：看构建命令和确定性 SHA-256 清单。
插件订阅与日志实验：把本页「注册 → 行为 → 卸载」的生命周期先在浏览器里走一遍可视化时间线。
Profile 解析顺序实验：理解 Loader entry 之前的 Bundle patch 层叠。
插件测试、卸载与版本证据：把这条最小流程放到更大的证据分层中。

先回答这四个问题，再继续往工具插件走：

如果 study-tools/minimal-plugin-workbench/dist/minimal-plugin.js 不存在，运行器为什么拒绝启动？
Loader entry、Cordis Fiber 和插件提供的 service 分别由谁拥有？
为什么必须等待 ctx.loader.remove() 完成后，才能检查服务已经消失？
这个实验没有证明哪些真实 DSH 能力？

证据边界

该实验是固定源码仓库中的最小 Context/Loader 运行证据。它没有覆盖 DSH profile/bundle 组合、真实 Host/Web 端口、浏览器交互、第三方 npm 安装、真实模型、凭据、子进程、跨平台行为或生产发布门禁。若要把插件提升为可分发扩展，仍需按插件测试、卸载与版本证据增加 Loader 组合、构建后消费者、失败、取消、真实宿主和平台矩阵证据。

最小插件工作台：构建 → 注册 → 卸载 ​

你要得到什么 ​

先安装和构建 ​

运行真实 Loader 全流程 ​

对照源码阅读 ​

证据边界 ​