核验方法
每条记录都来自三步：从 npm 抓候选、拉发布包逐项复核、再富化排序。全部可复现，没有人工评级。
为什么不按 star 和下载量排
dsh 的第一个 npm 包发布于 2026-08-10，仓库 08-13 公开。这份目录里 719 个可安装插件全部发布于 08-13 之后——没有一个例外。社交信号还没有时间形成：下载量几乎全是 0，star 主要反映谁先发了推文。
所以排序用的是结构性证据：包装是否正确、依赖版本是否还在、元数据是否完整。下载量和 star 仍然计入，但取对数并封顶，避免它们在样本还没意义的时候主导排序。
七项复核
没有 dsh.bundle.patch 的包不会成为 profile 的一层。它可能是给别的插件 import 的库，也可能是作者以为自己发了个插件。
package.json 的 files 数组漏掉它不会有任何报错，直到 dsh 启动时找不到这个文件。
我们按 YAML 解析它（保留 cordis 的 !!js 表达式标签但不求值），数出它插入或替换了几行。
教程教本地开发者写绝对路径，作者原样发布出去，于是这一行指向的是作者自己的硬盘。这类包装上必坏。
我们按 exports["."]、main、module 的顺序取入口路径，然后在 tarball 的文件列表里找它。
预构建的包安装过程不跑这个包的任何代码。只发源码的包需要用户授权构建——那等于允许它在你机器上执行代码。
半数插件有浏览器半侧，它通过 exports["./client"] 加载。这个产物很容易漏进 files——漏了之后插件装得上、也能启动，界面就是永远不出现。
版本兼容这一项要单独说
dsh 三天里从 0.0.1-rc.1 走到 0.1.0-rc.6。判断一个插件的依赖区间是否还有效，参照的必须是「已发布的最高版本」，而不是 npm 的 latest 标签——dsh 的库包把当前版本发在 next 标签上，latest 还停在首日的 0.0.1-rc.1。拿 latest 去比，会把所有跟上进度的插件误判成过期。
当前分布：426 个版本当前，38 个已过期，206 个没有声明任何 dsh 依赖（靠宿主提升解析），48 个用了 * 这样的通配区间。
这些检查不告诉你什么
它们读的是包装，不是代码。一个通过全部七项的插件，代码可能依然是恶意的、无用的，或者只是不好用。复核能排除「装了必坏」，不能替你判断「值不值得装」——插件运行在 dsh 进程里，权限和 dsh 一样大。