fix: include version in generated DSH plugin package.json (fixes #408)

[PerryLink]

Summary

Fixes #408.

The DeepSeek Harness integration writes the @memmy/memmy-memory plugin's package.json without a version field. DSH's plugin package inventory (@deepseek-ai/dsh-plugin-package-inventory-deepseek) re-reads that manifest before every DeepSeek request and rejects a bare-name plugin row unless both name and version are non-empty, so every DeepSeek request fails during preparation with REQUEST_EXTENSION / plugin-package-inventory-deepseek: ... must declare non-empty name and version. The turn dies before any HTTP call reaches the model.

Root cause

createDeepseekHarnessPluginPackageManifest() — the generator behind <DSH_HOME>/profiles/node_modules/@memmy/memmy-memory/package.json — returned a manifest with name but no version. private: true only prevents npm publishing; it does not make version optional for consumers that resolve the package by name.

Changes

• Memory/src/agent-source/integration/templates/memmy-deepseek-harness-plugin.ts: the generated manifest now includes version: MEMORY_SERVICE_VERSION (currently 2.1.2), imported from src/version.ts — the same convention the Memory-side OpenClaw and Hermes targets already use for their generated plugin manifests.
• App/backend/src/adapters/outbound/skill-writer/templates/memmy-deepseek-harness-plugin.ts: the parallel backend copy now includes version: MEMMY_VERSION (currently 1.1.4), imported from src/project-version.ts — the same convention the backend OpenClaw and Hermes targets already use.
• App/backend/src/adapters/outbound/skill-writer/deepseek-harness/tests/target.test.ts: the assertion that the generated manifest has no version is replaced with an assertion that it equals MEMMY_VERSION.

Both generators keep their manifest in sync with their workspace's own release version automatically, so the emitted version stays valid and non-empty on every future release without extra bookkeeping.

Verification

• npx vitest run src/adapters/outbound/skill-writer/deepseek-harness/tests/target.test.ts — 9/9 passed (includes the updated manifest assertion and the stale-manifest detection test).
• npx vitest run src/adapters/outbound/skill-writer/tests/l3-world-model-adapter-matrix.test.ts — 2/2 passed.
• npm run typecheck -w @memmy/backend — passed.
• npm run typecheck -w @memmy/memory — passed.
• Runtime smoke: executing both manifest generators directly now yields "version": "2.1.2" (Memory) and "version": "1.1.4" (backend) in the written package.json, alongside the existing fields.

Note: dependencies were installed with --ignore-scripts because the better-sqlite3 prebuild download timed out and node-gyp found no usable Python on the verification machine. The affected code paths and all tests above do not load native modules, so this does not affect the verification results.

[PerryLink]

Superseded by your own fix, so I am closing this rather than rebasing it.

eb5b725c98688ba73908ff9c12ec7cdfa65d2db3 -- "fix(dsh): give the memory plugin a package version" (Daoji Wang, 2026-09-30) -- added version: "1.0.0" to createDeepseekHarnessPluginPackageManifest() and updated the matching test assertion. That is the same change, in the same three files:

App/backend/src/adapters/outbound/skill-writer/deepseek-harness/tests/target.test.ts
App/backend/src/adapters/outbound/skill-writer/templates/memmy-deepseek-harness-plugin.ts
Memory/src/agent-source/integration/templates/memmy-deepseek-harness-plugin.ts

eb5b725c is an ancestor of main, so the premise of this PR -- a generated manifest with name but no version -- is no longer true, and there is nothing left here to merge. The branch is also ~467 commits behind, so rebasing a superseded patch would be work for its own sake.

One difference worth recording, offered as information rather than a request: eb5b725c writes the literal "1.0.0", whereas this PR derived the value from the workspace's own release version. A literal satisfies the inventory check just as well, so the simple form is a perfectly good choice; the only reason to prefer a derived value is that it keeps tracking releases without anyone updating the constant. Entirely your call, and it does not affect this close.

One loose end that is yours: #408 is still open with no comments, and it is the issue this fixed.

Thanks for turning the report around -- the diagnosis in the commit message is the same failure this PR set out to describe.