DeepSeek Harness market says compatible, install rejects

A plugin declares its supported range only in peerDependencies, yet the market marks it compatible from old releases through any future major version. The market-side data source is missing a piece; the range itself is not wrong. According to Discussion #9907, compatibilityOf() builds a manifest only from the index entry's engines.dsh, while index validation makes engines optional and fills {} when it is absent, so "no requirement" is evaluated as "compatible with any version". The preflight before installation rejects the install, producing a contradiction between the list and the installer; when you see this badge in the DSH plugin market, check the following in order.

Contradiction in the DeepSeek Harness market: compatible, install rejects

When the same plugin gets opposite verdicts in the market and the installer, the two sides are not reading the same declaration. Lay out both inputs first:

1. The market list reads the index entry. Expected: its fields are only version, publish time, source, and engines.
2. The installer reads the package manifest. Expected: it looks at both engines.dsh and peerDependencies.
3. The entry lacks engines.dsh. Expected: the market receives a manifest with no requirements and returns compatible: true.
4. The installer computes the real range from peerDependencies. Expected: it rejects the batch when the runtime is outside that range.

DeepSeek Harness break: compatibilityOf only receives engines.dsh

According to the community's source review in the thread, the break is not in the evaluator but in the manifest passed to it. For the version rules, see DSH plugin version compatibility; four steps cover the failure:

1. compatibilityOf() builds { name, version } from the index entry. Expected: it adds engines only when engines.dsh exists.
2. The index validator treats engines as optional and fills {} when missing. Expected: its type comment says absence means any version.
3. The compatibility evaluator sees no requirement and returns undefined. Expected: the outer layer translates that to compatible: true.
4. A package with only peerDependencies is always green in the market. Expected: that includes runtimes below its lower bound and any future major version.

Who sees the false DeepSeek Harness green badge

The false green badge affects the selection stage, not the install result. Three cases are most visible:

1. A plugin declares a multi-segment range only in peers. Expected: the market shows it as compatible with every runtime.
2. The user's current version is below the declared lower bound. Expected: it still appears green and is rejected only after clicking install.
3. A future major version ships. Expected: the same plugin still appears compatible even though the author never adapted it.
4. A third-party index omits engines. Expected: the market cannot distinguish "no requirement" from "not written".
5. Users treat the green badge as a promise. Expected: they discover after install that the runtime is unsupported, pushing the problem into runtime.

DSH plugin fixes: require engines, fall back, or preflight

All three paths align the badge with the real range; they differ in whether you fix the format, the read path, or only surface the verdict earlier. Judge by four points before choosing a layer:

1. The required-field fix changes only validation and generation conventions. Expected: read-side code stays untouched and the review surface is smaller.
2. The fallback fix changes the index type, generator, and market together. Expected: missing any one side leaves the false report in place.
3. The required-field fix makes old indexes fail validation after the upgrade. Expected: publishers must backfill data.
4. The fallback fix stays compatible with existing indexes. Expected: it adds a second parser, and folded results may disagree.
5. Whichever path you choose, the index entry and the manifest must end up using the same range. Expected: the badge and the installer cannot disagree.

Path 1: make engines required in the index format

This has the smallest surface and the most consistent semantics: require every index entry to carry a resolved engines.dsh, and fail validation when it is missing. The generator already folds a range from peers, so validation only needs to align with it.

1. Change engines from optional to required in the index schema, and make engines.dsh required and non-empty. Expected: validation rejects an entry without the field.
2. Keep the generator's logic for parsing peerDependencies, intersecting multi-segment ranges and removing duplicates. Expected: output stays a resolved range.
3. Update the format documentation and delete statements that contradict the implementation, such as "engines is optional". Expected: the docs match the validator.
4. Add a validation step to the publishing flow for hand-written or third-party indexes. Expected: incomplete entries cannot enter the index.
5. Expected result: an entry can no longer implicitly mean "any version", and compatible: true appears only when the range is satisfied.

Path 2: let the market fall back to peerDependencies

If the index format cannot change in the short term, the market can evaluate peers when engines.dsh is missing, at the cost of a second parser. According to the reply in the thread, the generator and the read side would each parse ranges, which is prone to drift.

1. Add an optional peerDependencies field to the index version type and have the generator pass it through unchanged. Expected: the generator can emit peer ranges.
2. In compatibilityOf(), read engines.dsh first and build the manifest from peers when it is absent. Expected: both sources can produce a manifest.
3. Extract range parsing into a shared implementation called by both sides. Expected: one parser serves the generator and the market.
4. Add a source marker to MarketCompatibility.requirements stating whether the range came from engines or peers. Expected: diagnostics name the range source.
5. Expected result: plugins that declare a range only in peers get the correct verdict, and diagnostics no longer point at a field that does not exist.

Path 3: backstop with the installer's preflight

The first two paths fix the display; this one ensures that even when the display is wrong, users see the real reason before clicking install. The installer already rejects, but the verdict is not shown at the selection stage.

1. When loading the market detail page, call the same evaluation function the installer uses, with the full manifest. Expected: the page has a full-manifest verdict.
2. When incompatible, disable the install button and show the required range and the current runtime version. Expected: the install button is disabled.
3. If the user still tries to install, display the preflight rejection reason verbatim. Expected: the user sees the real reason instead of a generic failure.
4. Record whether the evaluation used engines.dsh or peerDependencies, and cache it on the detail page. Expected: repeated clicks do not recompute the verdict.
5. Expected result: no more "looks installable, then fails as a batch" gap.

Verifying the DeepSeek Harness badge against three runtimes

Test at least a runtime below the lower bound, one inside the range, and one future major version to confirm the badge is no longer unconditionally true. Verification order:

1. Pick a plugin that declares its range only in peers and check whether its index entry has engines.dsh. Expected: you know which source the entry carries.
2. Open the detail page on a runtime below the declared lower bound. Expected: incompatible, not green.
3. Open it on a runtime inside the declared range. Expected: compatible.
4. Test a version above every declared segment. Expected: incompatible.
5. Click install once. Expected: the preflight verdict matches the page badge.

What DeepSeek Harness authors and users should each do

Authors should not treat the market badge as a promise, and users should not treat a green badge as a guarantee. Each side has one executable check:

1. Authors write both engines.dsh and peerDependencies in the manifest. Expected: different readers can obtain the range.
2. Authors open the index entry after publishing and confirm engines exists with the resolved range. Expected: the entry is no longer missing the field.
3. Authors state the runtime interval they actually support in release notes. Expected: readers do not rely only on the market's green badge.
4. Users run a dsh plugin add dry-run or read the installer prompt before installing. Expected: the real range is visible.
5. When the list and the installer disagree, users trust the installer and report the missing engines field to the market. Expected: the conflict is traced to an index that was not updated.

Source: Discussion #9907.