v0.5.27: DSH 0.2.1-alpha.2 Support and Memory Sources Beside dshmarket

This patch release publishes #360 and #361.

• Memory Sources beside dshmarket (#360, issue #359). dshmarket 1.66 mounts a second copy of every Profile dependency that ships a client but is not a bundle, and loads its host code there although that mount is meant to serve the client only. A Memory Source installed on its own in a Profile with dshmarket ran twice:

  • Memory Spaces warned at every start that mkt-client-dsh-mnemon-source-memory-spaces did not activate (Memory Spaces requires at least one explicit Provider child);
  • Runtime Memory and Project Documents registered a second instance. Status showed their cards twice, and the default layered Strategy failed every conversation turn with found ambiguous working-context Sources.

  Nothing installs under such a mount now, on every DSH version. Runtime Memory and Project Documents need only this Starter. A Memory Spaces copy the Profile maintains itself needs Memory Spaces 0.5.18; see Upgrade and compatibility.

• DSH 0.2.1-alpha.2 (#361). v0.5.26 adapted the memory subagents; this release follows the rest of what 0.2.1-alpha.2 changes:

  • its Plugins page no longer lists the Starter's grouping row, so the note about dsh-mnemon/bundle above the component list shows only where DSH lists that row;
  • it stops an Agent whose directory and original directory are both gone, so a background memory task for a workspace whose folder was deleted or moved now keeps working on that workspace's memory and runs from the first existing workspace, or where DSH started.

  Every root test, the real-host subagent tests, Headless and the Starter's activation contracts pass against the installed 0.2.1-alpha.2 and 0.2.0-rc.2, and the WebUI flows were checked on 0.2.1-alpha.2.

• Memory Spaces after enabling a Provider (#361). Saving or switching a Provider under Plugins now also reloads the Memory System's open page, so the Provider appears on Memory Spaces, and in its create dialog, without pressing Refresh.

#Upgrade and compatibility

From v0.5.22, use Memory System → Status → Check versions → Update, then restart DSH. To install or update to the exact version from the CLI:

dsh plugin --profile web add dsh-mnemon@0.5.27

Restart an existing DSH process after installation; a new installation can choose Enable now on the Plugins page. An explicit version keeps pnpm's 24-hour release window from picking an earlier one. For older desktop installations, see Compatibility and upgrades.

If your Profile maintains Memory Spaces itself (Check versions lists it as maintained by the Profile), update it to 0.5.18 too. Check versions does so where pnpm is on the Host's PATH; otherwise run:

dsh plugin --profile web add dsh-mnemon-source-memory-spaces@0.5.18

Removing that copy also works, since the Starter brings its own.

The supported host is DSH 0.2.0-rc.2 (npm latest and next); DSH 0.2.1-alpha.2 (npm alpha) passes the same checks. On 0.2.1-alpha.2 a memory task started under a conversation stays in its subagent list as continuable; continuing it from there runs it outside Mnemon's task rules, so leave these entries alone (Compatibility). Complete profiles use Node ^22.19.0 || >=24.0.0.

Existing memory needs no migration. No new Starter SDK export is required, so plugin peer floors stay unchanged.

#Changed packages

The Starter pins the new Memory Spaces version. Its other 16 component versions are unchanged, as are all locked external dependency versions.

#Verification

The versioned release acceptance installs the release packages through Add plugin on DSH 0.2.0-rc.2 and 0.2.1-alpha.2, and updates the setup from issue #359 from v0.5.26 through Check versions on both. The changes have their own records:

• Memory Sources under dshmarket's client-only mount
• dsh-mnemon on DSH 0.2.1-alpha.2

Publication verifies the complete pinned composition, the Registry installation and a real upgrade before creating the GitHub release.

Previous release: v0.5.26.