最小插件示例与学习检查
这一课把“知道公开扩展点”变成一次不需要 API key 的小练习。你会打开一个学习用第三方 Bundle、运行它的单元测试和 lint、改一个由 cordis.patch.yml 传入的配置值，再写清这些检查没有证明什么。
这个示例故意不是 dsh-super-injector 那种运行时注入器。它只使用公开的 ctx.on('tools/result', ...)：观察最终工具结果、输出经过长度限制的文本预览、不改写结果，也不读取私有 registry、Loader、模块缓存、进程或 Windows Registry。
先看这张练习卡
| 项目 | 这一轮的答案 |
|---|---|
| 预计时间 | 约 20 分钟；前 5 分钟在 Pages 或 GitHub 阅读，后 15 分钟在终端修改和检查 |
| 前置条件 | 读取部分只需网页；运行部分需要完整 clone 或 Codespaces、Node 和 pnpm，不需要 API key |
| 你会产出 | 一次修改过的最小观察插件，以及 test/lint 的实际输出和一条证据分层记录 |
| 这一步不证明什么 | 真实 DSH Profile/Loader 已加载、Fiber 已卸载、模型 token/延迟改善、跨版本兼容或安全性 |
先看这张证据表
| 你做的动作 | 已经能支持的结论 | 仍然不能支持的结论 |
|---|---|---|
阅读 package.json 和 cordis.patch.yml | 示例声明了一个第三方 Bundle 入口，并给观察器配置了两个长度上限 | 真实 Profile 已经安装或加载它 |
| 运行 Node 单元测试 | 配置会被校验并应用，预览会限长、忽略非文本块，观察器不会改写给它的结果 | Cordis Fiber 已经在真实进程中卸载干净 |
| 运行 lint | 当前示例 JavaScript 已通过明确的静态规则 | 真实模型 token、延迟、工具选择质量或安全性 |
| 在隔离 Profile 中完成 Loader 组合测试 | manifest、patch、依赖和启动树可以一起工作 | 所有平台和所有上游版本都兼容 |
| 发送真实模型请求 | 某固定模型、provider、工具集合和平台上的一次行为 | 所有模型都会更快或更好 |
不要跳过最后一列。教材的重点是让每个结论恰好配得上证据。
第一步：打开示例目录
打开学习示例总目录，再进入最小观察插件。Pages 会把这两个 README 投影成站内学习页；继续点击 src/index.js、测试和配置文件时才会回到 GitHub 的源码页。这样网页阅读路径保持连贯，同时不把 README 页面误写成真实 DSH 运行结果。先读 README，不要先复制安装命令。
它的目录只有四类东西：
minimal-observer-plugin/
├── src/index.js # 公开事件观察器与配置校验
├── tests/plugin.test.js # 可运行的行为测试
├── cordis.patch.yml # Bundle 组合入口
└── package.json # 身份、peer 范围和本地检查命令你在这里看到的“Bundle”只表示配置层把这个包放进插件树；它不是源码 patch，也不授予官方身份。
第二步：先运行两个确定性检查
确认终端当前目录是仓库根目录 deepseek-harness-study，然后只复制下面三行：
pnpm --dir study-examples/minimal-observer-plugin run demo
pnpm --dir study-examples/minimal-observer-plugin run test
pnpm --dir study-examples/minimal-observer-plugin run lint先运行 demo。正常输出应接近下面这一行：
[study-observer] study_greet -> ["hello world","second block"]这个命令使用一个很小的 fake context 发出公开事件，只是让观察器的输入和输出可见；它没有启动 DSH、Profile、Loader、provider 或模型。然后再运行 test 和 lint：前者检查行为，后者检查 JavaScript 规则。三个命令都成功，才算完成本课的离线练习；仍然不能写成真实 DSH 已经加载插件。
第一个命令有四类行为断言：包声明 tools 服务依赖；默认文本预览保留三段并截断；传入配置可以改变上限；监听 tools/result 后输出预览且不修改传入结果。第二个命令使用该示例自己的 oxlint correctness/suspicious 规则，再做 Node 语法检查。
正常情况下，demo 会输出一行观察结果，test 会报告用例通过，lint 会返回退出码 0。输出文字或 oxlint 版本可能变化；关键是三条命令都没有失败，但这仍然只证明学习示例自己的行为和语法规则。
如果命令失败，先读失败用例的名称，再看对应的 src/index.js；不要先把测试删掉。测试名描述的是读者可观察到的行为，而不是内部变量名。
第三步：做一次安全修改
把 cordis.patch.yml 中的 maxPreviewCharacters: 160 改成 80，并把测试里直接传给 apply(ctx, config) 的对应值和预期同步改成 80。不要修改 src/index.js 的默认值；重新运行两个命令。
这一步让你亲手体验“测试和配置一起维护”：只改配置而不更新受测输入，或只改测试而没有对应行为，都没有意义。练习结束后把 cordis.patch.yml 和测试中的 80 恢复成原来的 160，或者明确把改动保存在你自己的分支；不要把临时练习误当成已经发布的插件版本。然后写下下面两句话：
已证明：最小观察器接受配置值，并把每段文本预览限制为我设定的长度。
未证明：我已经把插件装进真实 DSH、模型已少收 token、或插件在所有平台能卸载干净。第四步：把示例放回完整架构
这个例子只覆盖“观察”。想新增工具时，继续读如何写一个合规插件中的第二个例子，再把工具的 schema、结果和取消补齐。想限制一个 agent 看见的工具，继续读工具可见性与非侵入扩展；restrict() 让同一作用域的 schema 和工具查找一致，但不会自动做 OS 权限隔离。
完成 Node 单元测试后，不要直接说“插件可发布”。下一层应是插件测试、卸载与版本证据要求的 Loader/Profile 组合测试、卸载检查和构建产物检查。需要云端或本地终端时再看GitHub 网页、github.dev 与 Codespaces 学习路线。
这套示例为什么比“大而全 demo”更适合第一步
大 demo 往往同时包含 Profile、Web UI、模型、文件、网络、子进程、环境变量和热重载。第一次失败时，你无法知道是自己的插件、配置、依赖、权限、网络还是模型出了问题。这个示例只留下一个公开事件和一个纯函数，所以每个失败都能先在本地解释。
等你能正确说出这里的证据边界，再按同样结构增加第二个例子：注册一个纯内存工具；第三个例子：给一个 agent 限制工具解析和模型呈现集合；第四个例子：在隔离 Profile 中做 Loader 安装与卸载。每增加一层，先新增对应测试和清理证据，再增加功能。
完成标准
- [ ] 我能说出
src/index.js只使用了哪一个公开 DSH 事件。 - [ ] 我运行过示例的 test 和 lint，或能明确说明自己还没有运行。
- [ ] 我做过一个小修改，并同步修改对应行为测试。
- [ ] 我能区分单元测试、Loader 组合测试、真实模型测试和卸载测试。
- [ ] 我不会把“示例通过”写成“DSH 全部运行验证”。
完成后回到15 分钟动手任务单选择下一条路线，或打开学习仓库的质量检查与审阅理解 CI 和 Agent 审阅怎样处理这些检查结果；想决定下一种示例应优先补什么，再读后续研究路线。