为什么要在真实宿主里测发布制品？
选择： 隔离运行确切版本的宿主与插件制品，逐阶段检查生命周期，保留结构化报告。
取舍： 源代码单测和安装成功都可能漏掉启动时的依赖注入问题。实际制品测试更重，但能把“在我这里可用”转成维护者能重放的发现。
个人开源项目 · npm 0.4.2 已发布
dsh-testkit
DeepSeek Harness 插件真实宿主测试工具
安装成功不等于插件可用。用隔离的真实宿主检查启动、注册、行为与卸载，把兼容问题变成可复现、可交付给维护者的证据。
我的工作：需求识别 · 产品设计 · AI 协作实现 · 社区验证
交付与验证
将插件真实宿主生命周期检查做成 CLI 与 GitHub Action；发现 dsh-shelf 安装后启动失败的兼容问题，提供固定制品复现，外部维护者确认并提交源码修复。
- npm 0.4.2 / GitHub Action
- 公开发布的工具与固定版本输入
- 外部维护者确认并修复
- dsh-shelf 启动兼容问题；修复后新制品复测仍待完成
项目性质
独立、非官方的 MIT 社区工具，不调用模型，不需要模型 API Key。兼容结论只针对确切插件制品、宿主版本与运行环境，不构成安全认证或 DeepSeek 官方背书。
关键产品决策
源码修复之后，为什么还不能宣布通过？
选择： 等待新的不可变插件制品发布，再对该制品复测，不用本地补丁替代最终结论。
取舍： 用户安装的是制品而不是修复意图。源码、构建产物和分发版本可能不一致，结论必须绑定用户实际获得的版本。
项目背景与实现范围
一次外部验证
dsh-shelf 的固定制品通过安装和组装，却因 ctx.baseDir 未被宿主注入而在启动时失败。维护者根据复现确认了路径合同，并提交源码修复。新制品发布后的最终复测仍待完成，发现与修复不等于认证通过。