v0.5.4: Memory Space Terminology

v0.5.4 standardizes the persistent memory unit as memory space in English and 记忆空间 in Chinese. It includes PR #194, covering product copy, code models, public SDK names, responsive layouts, and documentation.

#Consistent terminology and usable layouts

• The workbench, settings, accessible labels, Agent guidance, command output, package READMEs, and bilingual guides use the same term. Individual memories, Runtime memory, and Documents keep their separate meanings.
• Canonical code names include MemorySpace, MemorySpaceRegistry, and service operations such as createSpace and mergeSpaces.
• Directory actions wrap within narrow layouts, Provider metadata and storage badges can wrap, and navigation spacing accommodates longer labels. Chinese and English directory and creation flows were checked at 390 × 844.
• Current documentation uses refreshed desktop and narrow-screen screenshots. Editable Chinese diagrams use the new term; historical screenshots, measurements, and recordings retain their original pixels and provenance.

#Compatibility and existing data

Existing v0.5.x integrations remain supported. Deprecated model names and service methods remain available; Provider factories accept the canonical authority name alongside the legacy context, and the old protected HTTP Provider field remains compatible with existing subclasses.

Published tool/RPC names, memoryBodyId(s) and related wire fields, registry file names and JSON shapes, Document/Pack lineage, and revision encoding keep their existing spellings. These identifiers still refer to memory spaces. Existing user-authored names are preserved, including names that contain the previous Chinese term. No data migration is required; IDs, data locations, Provider connections, management authorization, and read-only restrictions remain compatible.

#Packages and upgrade

The Starter and all sixteen official plugins advance to 0.5.4 because each has changed code or published documentation. Independent versioning remains in effect, and the Starter pins this tested composition exactly.

Install the release in the owning DSH Profile, then restart DSH:

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

Use headless instead of web for a Headless Profile. Mnemon CLI remains separately managed; this release does not change its version. Installation and update guidance continues to use the official @mnemon-dev/mnemon npm package. See Getting started and Operations.

To roll back, install dsh-mnemon@0.5.3 in the same Profile and restart DSH. No data conversion is needed. Restore independently installed plugins separately if they were updated.

#Verification and evidence

The implementation passed 783 root tests, 300 plugin tests, deterministic builds, workspace typechecks, real isolated DSH Headless activation, package validation, and independent verification of sixteen plugin repositories and seventeen tarballs. External SDK fixtures compile both old and new model names and a subclass overriding the legacy protected Provider field. Two opt-in Native/platform integration cases require their separate environments and were skipped locally.

Real bilingual UI evidence covers creation, editing, activation, browsing, settings, language switching, and cancellation with disposable synthetic data. The eighteen original JPEG captures were made before versioning, on the v0.5.3 base with the implementation now included in v0.5.4; their version badges identify that capture base. Model quality and cloud Provider behavior were not evaluated. The narrow-layout fixes do not broaden the evidence to every settings surface or remove other documented compatibility limits.

The release workflow verifies the versioned workspace and independent packages, freezes artifact integrity, publishes dependency layers before the Starter, installs the complete npm composition, and smoke-tests a Registry upgrade from v0.4.7 before creating the GitHub Release.

Previous release: v0.5.3.