dsh-plugin-picker 是面向 DeepSeek Harness Web 编写器的独立插件：以本机缓存管理 Codex 插件包，在输入框用 @ 搜索并注入 skills，同时提供启停、中文昵称、增量同步和仅回环可访问的配置接口。
当 Codex 与 DSH 的插件包不在同一入口时，用户要反复查目录、复制 Skill、同步版本。dsh-plugin-picker 为 DSH Web 编写器补上 Codex 式插件管理，并保持独立，不依赖 dsh-web-ui family bundle。
问题与定位：让插件能力靠近输入框
插件包的价值通常发生在对话开始之前：用户需要从已安装能力中选出适合当前任务的一组指令。如果每次都去文件系统找目录、打开 README、复制 Skill，能力发现就变成上下文切换。
dsh-plugin-picker 把选择动作放回编写器：在输入框输入 @，列出已启用插件包的显示名和摘要，选中后把对应 skills 注入当前会话。
它并不重新实现 Skill，也不改变 DSH 的推理能力，负责的是本地插件包的索引、筛选、配置和注入桥接。
核心方案：一个事实源、两种同步方式
DSH 原生缓存与 Codex 增量同步
插件以 ~/.dsh/plugins/cache 作为 DSH 侧唯一事实源。启动时可从 ~/.codex/plugins/cache 同步缺失或旧版本的插件包；同步依据版本比对，而不是每次无条件复制。
资料中的设计说明，典型 Codex 缓存首次同步约 160 MB，后续主要做版本检查，这个数值只描述资料中的缓存量级，不代表运行性能承诺。也可以通过同步接口手动触发一次 Codex 到 DSH 的更新。
@ 触发菜单与本地化搜索
菜单展示显示名和摘要，同时匹配中文昵称、英文名称及 skill 名。选中后注入插件包声明的 skills，启用开关决定它是否进入路由和 @ 数据源。
配置持久化与 Loopback API
每个插件包有独立的启用状态和显示昵称，既可在 DSH 设置页插件配置区编辑，也可直接修改 ~/.dsh/plugin-picker.json。
插件提供仅限本机回环地址的配置接口：GET /api/dsh-plugin-picker/plugins 返回已启用插件包及应用昵称；GET /api/dsh-plugin-picker/config 读取完整列表和配置；PUT /api/dsh-plugin-picker/config 合并并持久化配置；POST /api/dsh-plugin-picker/sync 触发同步。
把接口限制在 Loopback，避免把本地插件目录和配置面暴露给外部网络。
关键工程实现：边界优先于“全盘扫描”
插件只管理包含 .codex-plugin/plugin.json 清单的插件包，不越界处理个人 skills。这个筛选条件让“可被宿主加载的包”和“用户个人指令目录”保持边界，也为菜单数据提供稳定入口。
配置项围绕少数职责展开：enabled 控制总开关，pluginsDir 指向 DSH 缓存，codexPluginsDir 指向同步来源，syncFromCodex 控制启动同步，configFile 指向启停和昵称持久化文件。
同步、索引、配置和注入各司其职：手动同步不改变配置，关闭插件也不必删除缓存。独立交付减少了对 DSH Web UI bundle 的耦合。
边界与验证
- 本项目管理的是插件包，不是个人 skills；判断依据是
.codex-plugin/plugin.json是否存在。 - Loopback API 的目标是本机管理，不应被描述为远程插件管理服务，也不应据此推断具备多用户权限体系。
- 应验证首次同步、缺失包、旧版本包、版本一致时的跳过、手动同步、包被禁用、中文昵称搜索、skill 名搜索和配置文件合并。
- 应验证插件清单缺失或格式不符合时不会进入菜单，配置文件损坏时的错误提示和恢复路径也应单独检查。
- 现有本地资料能证明接口、目录、配置字段和交互设计；正文不宣称安装量、同步耗时、并发能力或生产部署状态。
总结
dsh-plugin-picker 解决的是插件能力的“可发现、可选择、可复用”问题：以 DSH 缓存作为事实源，用版本比对连接 Codex 现有缓存，用 @ 菜单把选择放进编写器，再用启停、昵称和 Loopback API 管理本机配置。
它的工程取舍是小而清晰——不重写宿主、不碰个人 skills、不把本地配置开放到网络，把插件包管理作为独立层接入 DSH，因而更适合作为可验证的工具链补丁，而不是被夸大的平台能力。
评论