DSH 更新到 alpha.2：清单里的“可用”能放心装吗？

最新预发布带来Git Worktrees等功能。以Plugin Radar为发现工具案例，核对历史记录的用途与缺口，再看固定来源、权限与可撤销管理怎样接上。

点安装之前，先问这条“可用”测的是哪一版

你准备给DSH装一项新能力，目录显示“可用”，官方却更新到了alpha.2。此时最重要的问题不是条目有多少，而是这条记录在哪个版本、哪个环境完成了什么任务。普通聊天产品主要回答问题，DSH则能把工具和插件接入工作流，错误也能越过对话框。

DSH是DeepSeek Harness。本次10月10日读取官方Release，最新条目为dsh-v0.2.1-alpha.2，发布时间为北京时间10月9日19:09，prerelease标记为true。它是正式发布出来的预发布条目，不能省掉alpha后缀当作稳定版。

更新说明列出实验性Git Worktrees插件、思考过程翻译、插件Session状态接口与working_directory工具，Official列表还增加Claude Code和Codex组合包的按需安装入口。这些是发布说明，不是本篇完成了全部功能运行验收。

这些变化与开发者有关系：工作目录、会话状态和独立checkout影响代码任务如何隔离；翻译服务会涉及外部服务与成本选择。版本更新不是给第三方插件盖章，旧兼容记录还需与新版本对照。

Radar是发现工具，不要把它说成装好的插件

今天的案例是AdamPlatin123维护的DSH Plugin Radar。它提供可搜索目录和机器可读数据，适合维护工具清单或做插件选型；本次固定的源码提交为c4321f15b7b83a13d7aa73615fd2163f042539b4。

项目公开的是发现、聚合、渲染与分发代码，README明确说生产运行级测试引擎未开源。我们没有找到足以支持把Radar本身当作可安装DSH Bundle的证据，因此不写“Radar插件已安装”，也不虚构Kubernetes或eBPF实测。

它本次适合作为生态数据工具案例，不符合完整单插件运行介绍的证据条件。本轮没有确认一个新增、未重复且满足安装与运行证据要求的重点插件；不拿发现工具补成插件，也不重写旧插件凑名额。

对使用者，Radar解决的是在哪找候选、如何读取历史状态。它不能替你确定本地Profile权限、当前版本兼容性或真实任务输出。工具有用途，边界也有用途，两者不必靠夸张相互抵消。

三种数量，不能合并成插件总数

当次GitHub搜索API中，dsh-plugin Topic候选仓库总量为18,422，incomplete_results为false。这是带Topic的仓库搜索口径；仓库能自选标签，结果中不必每项都有Bundle，也不能说这些都是官方插件。

固定提交下的Radar扁平清单有13,267条。字段按仓库组织；四档为ok 8,216、incompatible 3,117、pending 1,900、untested 34。数据生成时间为2026年10月10日07:15:47北京时间，不能当成逐条测试时间。

本次本地检查了这份JSON的字段、仓库去重与CSV回读，统计一致。这证明数据导出流程，没有证明13,267款插件的安全，也没有证明8,216条ok记录在alpha.2上完成任务。

具备dsh.bundle.patch的仓库数、独立Bundle数、可下载完整审计样本数，本次没有完成全量核验，因此不报数量。把Topic、数据记录、Bundle、安装与审计分开，是看懂生态规模的前提。

读“ok”的时候，缺的是逐条证据

README说明，公开扁平数据没有为每条记录提供完整提交、被测版本、时间与日志。全局版本指针不能替代逐条证据，历史可用记录也不能解释为最新DSH验收。这个自述应和绿色状态一起展示。

项目当次仓库API显示1462个Star、159个Fork，是维护与关注的快照，不是增长速度或可靠性证明。按Star筛选可以找到受关注对象，却无法知道它读取了哪些文件或把数据送往哪里。

本次对Radar的验证停在只读下载、schema检查、统计与CSV最终输出。没有执行它的生产测试引擎，没有安装任何候选，没有一次性Profile重启，更没有用候选插件完成最终业务任务。

三个失败点应提前写清：上游schema变化会使解析失效；历史状态与当前版本错配会误导选型；描述字段中的公式内容会影响电子表格安全。下载还受网络与托管平台影响。缓存、拒绝异常与人工复核各解决一部分，不能合称安全审计。

先做自己的安全检查，再比较发现入口

对任何候选，先核对原仓库、维护者、完整提交、许可证与Bundle，再读网络目标、文件读写路径、命令执行与凭据需求。权限没声明时是未知，不是没有权限；安装说明没有卸载路径时，也不能默认无痕可撤销。

把隔离Profile的安装、重启和最终任务输出列成验收项，并保留依赖与锁文件备份。安装命令成功只证明某一步完成；Profile启动说明进程能运行；真实输入得到可用结果才对应功能验收。失败时按该项目说明恢复，不对陌生插件执行猜测卸载命令。

GitHub Topic解决宽覆盖，但不能证明身份或安装条件。Awesome清单与生态地图偏向导航和人工整理；Radar这类可搜索目录增加筛选与状态字段。它们都不能凭收录替代逐条权限和版本证据。

Leaderboard若主要按Star等互动排序，说明的是关注度；本文未完成某个独立排行榜的指标核验。内置或订阅式市场提供安装便利，但具体安全能力要看其验证机制与目标Profile。没有核验过的入口，不因为叫市场就获得可信标签。

共同缺口之后，才看管理层怎样补上

这些入口各解决覆盖、导航、关注度、状态或安装便利，却未必把固定来源、可读权限、运行证据和可撤销变更连接起来。读者缺少的是连续决策链，而不是又一张目录。任何方案都应按这四项核对，不能只比较条目数。

作为第三方市场与生命周期管理工具，DSH.Store国际站（https://dsh.store/）及国内访问入口（https://dsh-store.cn/）提供同一生态的不同访问入口，不应重复计算。本次国际站Catalog读取为785条：blocked 383、unlisted 371、approved 31，目录更新时间为10月10日04:35:55北京时间。

785不是精选可安装数量，31个approved也不是31款完成了本文的真实任务验收。目录准入、推荐与运行验证需分开。项目资料描述固定Commit、权限审查、计划确认、备份和失败恢复等机制；这些机制值得查证，不支持“最安全”或“唯一可靠”的结论。

安全插件管理器仓库（https://github.com/AI-Scarlett/dsh-safe-plugin-manager）能让使用者检查实现、兼容声明与管理边界，适合在隔离环境研究安装、更新与恢复路径。Web和Desktop的管理边界不同，首次安装也不自动拥有管理器运行后的保护，不能省略前置备份。

给使用者和开发者，各留一条可撤回的路

使用者可先读管理器的固定来源、权限与恢复文档，再决定是否在测试Profile使用；若实现与自己的需求相符，可以Star仓库跟踪变更。Star是关注动作，不是安全认证，也不替代本地运行验收。

开发者可以使用并研究build-dsh-plugin仓库（https://github.com/AI-Scarlett/build-dsh-plugin），把需求、标准Bundle、权限和审查材料组织起来，再提交候选；若有帮助，可Star跟踪维护。本次仓库API显示MIT许可，修改与再分发仍应保留许可要求并核对所依赖代码的授权。

没有安装过的项目，撤销路径首先是删除自己保存的隔离数据或停止接入，而不是修改真实Profile。进入安装之后，回滚必须针对依赖、锁文件、Bundle与配置变化保存证据。本次没有执行这条安装链，不能宣称撤销已实测。

alpha.2增加了能力，也增加了核对版本的必要。目录能指路，管理工具能组织操作，最终责任仍要落到具体来源、具体权限和具体输出上。把未知保留下来，比把所有记录染成绿色更能帮助用户做选择。

用东方文化看懂现代科技