dsh-plugin-preflight

社区插件清单有一套明确的贡献规范，但手工对照既慢又容易漏项。最常见的一类拒稿，是只声明了 dsh.client 却缺少可安装的 dsh.bundle；另一类隐蔽得多：Harness 常以预发布版本运行，而 peerDependencies 里的 semver 范围看起来宽松，却会在用户安装时悄悄排除他们实际在用的版本，最后变成需要手搓的 ERESOLVE。preflight 把清单贡献指南里「机器能核对」的那一部分做成可重复的检查，在提交或发布前先把结构性问题拦在门外。

它会覆盖 bundle 与补丁层、client 导出与 ModuleLoader 约定、依赖应放在 peer 而非 dependencies、files 是否包含 CLI、以及清单与描述里的常见硬伤。在 dsh profile 内运行时，还会对照当前环境已安装的 Harness 版本，具体判断 peer 范围是否真的能接纳它——这是工具存在的核心理由。没有可对照的版本时，它选择沉默而不是臆测，避免把正确清单误报成错误；唯一例外是裸 * 通配符，因为对任何预发布都无法成立。

退出码 0 表示没有阻塞项、1 表示有问题，可以直接挂进提交前脚本或 CI。作为 DSH 插件安装后，还会给 Agent 提供一个只读的 plugin_preflight 工具，方便在脚手架阶段自检。它刻意不做浏览器面板和设置页——这是面向维护者的诊断能力，不是日常功能。

适合正在打磨插件、准备上社区清单或 npm 发布的作者，以及希望把「清单合规」固化进工作流的团队。需要说明：检查是结构性的，无法判断描述是否夸大功能；仓库年龄、GitHub topic 等需要联网的规则也故意不纳入，以免每次提交都依赖外部 API。