DeepSeek Harness 插件市场误报兼容？engines.dsh 与 peerDependencies

插件只在 peerDependencies 里声明支持范围，市场却对从旧版到未来大版本一律显示兼容，这是市场侧的数据源缺了一截，不是你的范围写错了。 据讨论 #9907，compatibilityOf() 只从索引条目的 engines.dsh 构造 manifest，而索引校验把 engines 设为可选并在缺失时填 {}，于是「没有要求」被评估成「任意版本都兼容」。安装前的 preflight 反而会拒绝，形成列表与安装结论相反的现象；在 DSH 插件市场 里遇到这种标记，按下面的顺序排查。

DeepSeek Harness 插件市场说兼容，安装却说版本不满足

同一份插件，在市场和安装器里得到相反结论，说明两边读的不是同一份声明。 先把两边的输入摆出来：

1. 市场列表读取索引条目，预期字段只有版本、发布时间、来源和 engines。
2. 安装器读取包 manifest，预期同时看 engines.dsh 与 peerDependencies。
3. 条目缺 engines.dsh 时，市场拿到的是没有要求的 manifest，预期返回 compatible: true。
4. 安装器按 peerDependencies 算出真实范围，预期运行时不在范围内就整批拒绝。

DeepSeek Harness 断点：compatibilityOf 只拿到 engines.dsh

据讨论中社区核对源码，断点不在评估器，而在传给评估器的 manifest。 版本兼容的判定口径可以对照 DSH 插件版本兼容 看，这里只留四步：

1. compatibilityOf() 从索引条目拼出 { name, version }，预期只有 engines.dsh 存在时才补上 engines。
2. 索引校验器把 engines 当可选字段，缺失时填 {}，预期类型注释也写明「缺省表示任意版本」。
3. 兼容性评估器看到没有任何要求，预期返回 undefined，外层翻译成 compatible: true。
4. 于是只有 peerDependencies 的包，预期在市场里永远显示绿色，包括低于声明下限和任意未来大版本。

DeepSeek Harness 市场误报影响谁

错误的绿色标记影响的是选择阶段，而不是安装结果。 三类场景最明显：

1. 插件只在 peers 里声明多段范围时，预期市场对所有运行时都显示兼容。
2. 用户当前版本低于声明下限时仍看到绿色，预期点安装才被拒。
3. 未来大版本发布后，预期同一插件仍显示兼容，即使作者从未适配。
4. 第三方索引省略 engines 时，预期市场无法区分「没有要求」和「没有写」。
5. 用户把绿色标记当成承诺去选版本，预期装完才发现运行时不受支持，问题被推迟到运行期。

DSH插件修法：engines 必填、回退 peers 还是 preflight

三条路都能让兼容标记和真实范围对齐，差别在治格式、治读取，还是只把结论提前到选择阶段。 取舍可以按四点判断，再决定改哪一层：

1. 必填方案只改校验与生成约定，读取侧代码不动，预期评审面更小。
2. 回退方案要同时改索引类型、生成器与市场，预期任何一侧漏改都会继续误报。
3. 必填方案会让旧索引在升级后校验失败，预期发布方需要补数据。
4. 回退方案能兼容已有索引，预期会引入第二个解析器，范围折叠结果可能不一致。
5. 无论选哪条，预期索引条目和 manifest 最终使用同一份范围，标记与安装器不会再冲突。

路径一：索引格式要求 engines 必填

这是修复面最小、语义最一致的做法：让索引条目必须携带解析后的 engines.dsh，缺了就校验失败。 生成器本来就会从 peers 折叠出范围，把校验对齐即可。

1. 在索引 schema 里把 engines 从可选改为必填，engines.dsh 同样必填且非空，预期缺字段的条目被拒绝。
2. 让生成器继续按现有逻辑解析 peerDependencies，多段范围逐段求交并去重，预期输出是解析后的范围。
3. 同步更新格式说明，删掉与实现矛盾的「engines 可选」和「没有 peer 回退」表述，预期文档与校验器一致。
4. 对手写或第三方索引，在发布流程里加一次校验，预期缺字段的条目无法入库。
5. 预期结果：条目不可能再隐式表示「任意版本」，compatible: true 只在范围真的满足时出现。

路径二：市场侧回退读 peerDependencies

如果索引短期无法改格式，可以让市场在 engines.dsh 缺失时改用 peers 评估，但要接受多一个解析器。 据讨论回复，这条路的代价是生成器与读取侧各有一套范围解析，容易漂移。

1. 在索引版本类型里增加可选的 peerDependencies 字段，并让生成器原样带上，预期生成器能输出 peers 范围。
2. 在 compatibilityOf() 里先看 engines.dsh，缺失时再用 peers 构造 manifest，预期两种来源都能产出 manifest。
3. 把范围解析抽成共享实现，生成器与市场都调用同一个函数，预期只有一套解析逻辑。
4. 给 MarketCompatibility.requirements 增加来源标记，说明范围来自 engines 还是 peers，预期诊断信息能指出来源。
5. 预期结果：只在 peers 声明范围的插件也能得到正确的兼容结论，诊断信息不再指向作者 manifest 里不存在的字段。

路径三：安装期 preflight 兜底提示

前两条修的是展示，这一条保证即使展示错了，用户也能在点安装前看到真实原因。 安装器本来就会拒绝，缺的是把结论提前到选择阶段。

1. 在市场详情页加载时，用完整 manifest 调一次与安装器相同的评估函数，预期详情页拿到完整 manifest 的结论。
2. 不兼容时把安装按钮改为不可用，并显示所需范围与当前运行时版本，预期按钮被禁用。
3. 用户仍然尝试安装时，把 preflight 的拒绝原因原样展示，预期用户看到真实原因而不是一句失败。
4. 记录评估用的是 engines.dsh 还是 peerDependencies，并缓存到详情页，预期重复点击不重新计算。
5. 预期结果：安装不会再出现「看起来能装、点下去整批失败」的落差。

DeepSeek Harness 兼容标记的验证：三个运行时版本

至少用低于下限、范围内、未来大版本三个运行时各测一次，才能确认标记不再无条件为真。 验证顺序如下：

1. 选一个只在 peers 声明范围的插件，先确认索引条目里有没有 engines.dsh，预期你知道条目带的是哪种来源。
2. 在低于声明下限的运行时打开详情页，预期显示不兼容而不是绿色。
3. 在声明范围内的运行时打开，预期显示兼容。
4. 用一个高于所有声明段的版本再测，预期不兼容。
5. 点一次安装，预期 preflight 结论与页面标记一致。

DeepSeek Harness 作者与用户各自该怎么做

作者不要把市场标记当承诺，用户也不要把绿色标记当保证。 两边各有一条可执行的检查：

1. 作者在 manifest 里同时写 engines.dsh 与 peerDependencies，预期不同读取方都能拿到范围。
2. 作者发布后打开索引条目，确认 engines 字段存在且范围是解析后的结果，预期条目不再缺字段。
3. 作者在发布说明里写清实际适配的运行时区间，预期读者不只能看到市场的绿色标记。
4. 用户装前先在终端执行一次 dsh plugin add 的 dry-run 或查看安装器提示，预期能看到真实范围。
5. 用户遇到列表与安装结论冲突时，以安装器为准，并把索引条目缺失 engines 的情况反馈给市场，预期冲突只可能来自索引本身没更新。

来源：Discussion #9907。