Bug: versionless profile manifests break DeepSeek requests for local modules

[cbp175]

Bug: DeepSeek request fails for local profile modules

Summary

A deepseek-official request fails with REQUEST_EXTENSION when a DSH profile loads a local module such as ./task-review-server-only.mjs.

plugin-package-inventory-deepseek: <profile>/package.json
must declare non-empty name and version

Cause

The plugin-package inventory treats the profile's own package.json as an installed plugin package when it resolves a local module. A DSH profile manifest has dsh.profile and does not require a version.

Fix

When resolving a loose local module, skip a nearest manifest that declares dsh.profile instead of adding it to dsh_plugin_packages.

if (allowAnonymous && (manifest.name === undefined || manifest.dsh?.profile !== undefined)) {
  return undefined
}

Verification

A regression test for a versionless profile with an active local module passes. The exact web-profile request-extension probe also succeeds after the patch.

Local tested commit: 8ec44bcdd2

[moonquake2004]

Confirmed, and it is not specific to your setup — with one detail that points at the smallest fix.

The code path. @deepseek-ai/dsh-plugin-package-inventory-deepseek (lib/index.js:34) validates identity through identityFromManifest(path, allowAnonymous):

if (allowAnonymous && manifest.name === void 0) return void 0;
if (typeof manifest.name !== "string" || manifest.name.length === 0
 || typeof manifest.version !== "string" || manifest.version.length === 0)
  throw new Error(`plugin-package-inventory-deepseek: ${path} must declare non-empty name and version`);

There is an escape hatch for an absent name (allowAnonymous), but no equivalent for an absent version. A DSH profile manifest has a name and no version — so it passes the anonymous check, fails the version check, and throws. Your dsh.profile-aware skip is the missing counterpart to allowAnonymous.

Independent confirmation that profiles are shaped this way by default. Both profiles on this machine have exactly the same shape:

web:   name="dsh-profile-web"   version=undefined   dsh.profile present
daily: name="dsh-profile-daily" version=undefined   dsh.profile present

i.e. this is what the harness itself generates, not a hand-edited manifest. So the exposure is not "a profile missing a version" but "any profile, the moment a loose local module is resolved from its root". Profiles with only registry/file: plugin dependencies (whose own manifests do carry versions) never reach it — which is presumably why it looks environment-specific in the wild.

We added a check for the precondition so it is visible before the request fails: dsh-doctor P18 reports a warn when a manifest has dsh.profile and no non-empty version, naming this code path and the trigger. It stays a warn rather than a failure precisely because it needs the loose-module resolution to fire.

On the workaround: adding "version": "0.0.0" to the profile manifest defuses the throw, but I'd treat that as a temporary unblock, not the fix — the profile manifest having no version is legitimate, and your proposal (skip a nearest manifest declaring dsh.profile when resolving a loose module, instead of adding it to dsh_plugin_packages) keeps the invariant intact.