[Bug] DeepSeek Harness integration writes a plugin package.json without a version field, which makes every DeepSeek request fail

[Nerdless-ship-it]

Summary

Memmy's DeepSeek Harness integration deploys a DSH plugin package whose package.json has no version field. DSH's DeepSeek request-extension step re-reads that manifest before every model request and rejects a named plugin package without a non-empty version, so every DeepSeek request fails while the plugin row is mounted. The turn dies before any HTTP call — the model is never invoked.

Where

createDeepseekHarnessPluginPackageManifest() in dist/src/agent-source/integration/templates/memmy-deepseek-harness-plugin.js (around line 606) returns:

return {
    name: "@memmy/memmy-memory",
    private: true,
    type: "module",
    exports: {
        ".": "./index.mjs",
        "./client": "./client.js",
        "./package.json": "./package.json"
    },
    dsh: {
        client: {
            platform: "web",
            inject: [
                "@deepseek-ai/dsh-client-runtime",
                "@deepseek-ai/dsh-client-ui-conversation"
            ]
        }
    },
    peerDependencies: {
        "@deepseek-ai/dsh-llm": "*",
        "@deepseek-ai/dsh-tools": "*"
    }
};

There is no version. The deployed file (<DSH_HOME>/profiles/node_modules/@memmy/memmy-memory/package.json) matches this output field for field, so this function is the source. The caller is the DeepSeek Harness integration target (dist/src/agent-source/integration/deepseek-harness/target.js, PLUGIN_PACKAGE_NAME).

Observed error

DeepSeek request extension preparation failed        (code: REQUEST_EXTENSION)

with the underlying cause:

plugin-package-inventory-deepseek: <DSH_HOME>/profiles/node_modules/@memmy/memmy-memory/package.json
must declare non-empty name and version

The wrapper error carries no cause, so the session log only shows the first line.

Why it matters

@deepseek-ai/dsh-plugin-package-inventory-deepseek contributes the dsh_plugin_packages metadata field to official DeepSeek requests. It resolves the manifest of every active loader row on every request, and for a bare-name row (name: "@memmy/memmy-memory" in the DSH patch layer) it requires both a non-empty name and a non-empty version — documented in that package's own README ("malformed package metadata makes request preparation fail"). Because the failure happens during preparation, the whole request is aborted rather than just the metadata field being omitted. private: true prevents npm publishing; it does not make version optional for this consumer.

Reproduction

1. Let Memmy deploy its DSH integration: package at <DSH_HOME>/profiles/node_modules/@memmy/memmy-memory/ plus a mount row in <DSH_HOME>/cordis.patch.yml:

   - insert:
       - id: memmy-memory
         name: '@memmy/memmy-memory'
         config:
           memmyConfigPath: '<...>/config.yaml'

2. Start dsh web (profile web) and send any message on the DeepSeek official route.
3. The turn fails immediately with the error above, before any request reaches the API.

Observed failures start the moment the plugin row becomes active, and stop when it is removed.

Suggested fix

Emit a non-empty version in the generated manifest, e.g.:

return {
    name: "@memmy/memmy-memory",
    version: "1.0.0",
    private: true,
    // ...
};

Any non-empty string works; it only needs to be present so the package is a well-formed identity for consumers that resolve it by package name.

Environment

• Memmy 2.1.2 memory-service runtime (win-x64); Memmy.exe at D:\软件\Memmy
• DSH via npx @deepseek-ai/dsh, profile web, DeepSeek official route (deepseek-official)
• Windows 11 (10.0.26200), Node v26.8.2

Related: #318 — same DeepSeek Harness integration area (memmy-memory plugin could not activate on DSH 0.1.2-alpha.2).