dsh-mnemon 0.1.5 → 0.1.6

package/docs/en/architecture.md

@@ -1,133 +0,0 @@
-# Architecture
-
-[简体中文](../zh-CN/architecture.md) | **English** | [Documentation Center](./README.md)
-
-## Positioning
-
-`dsh-mnemon` is an integration and supervision layer between DSH and Mnemon, not a new database engine:
-
-- DSH provides the root Agent, lifecycle events, subagent providers, tools, commands, settings, and Web extension points;
-- the plugin provides the control plane for three knowledge layers, routing policies, transactional barriers, and UI;
-- the local `mnemon` CLI provides named Stores, SQLite persistence, four graph types, recall, relationships, and soft deletion, and defines the durable-data boundary shared with other Mnemon-enabled agents.
-
-## Component Diagram
-
-[![dsh-mnemon runtime architecture](../assets/diagrams/en/project-architecture.svg)](../assets/diagrams/en/project-architecture.svg)
-
-Solid lines show deterministic data or control paths; purple dashed lines show LLM-supervised paths. Runtime Memory and Documents use managed files directly. Only Memory Spaces call the local Mnemon CLI through `MnemonRunner`. Click the image to open the original SVG.
-
-Cross-agent interoperability therefore applies only to Memory Spaces in the diagram: agents share durable memories and relations inside Mnemon Stores, not DSH conversation context, Runtime projections, or the Documents control plane. The plugin never pushes data to another agent; participants share by aligning their local Mnemon root and Store.
-
-## Host Composition Root
-
-`src/index.ts::apply()` assembles the plugin in this order:
-
-```text
-settings.register("mnemon")
-  -> resolveConfig
-  -> createRunner
-  -> MnemonService
-  -> RuntimeMemoryController
-  -> DocumentManager
-  -> StorageScopeInspector
-  -> MnemonSubagentCoordinator
-  -> MnemonLifecycle
-  -> tools / commands / prompt sections
-  -> register RPC when a Web connection exists
-```
-
-The Host declares dependencies on `tools`, `settings`, `commands`, `agents`, and `subagents`. The Web client additionally depends on slots, connection, and DSH locale services.
-
-## Dual Paths for the Root Agent and Workers
-
-The same `mnemon_*` tools route calls according to whether the caller is a subagent, preventing recursive delegation:
-
-```text
-root Agent calls mnemon_recall
-  -> coordinator starts a bounded recall worker
-  -> worker calls mnemon_memory_bodies and mnemon_recall
-  -> tool sees origin=subagent
-  -> call reaches MnemonService directly
-  -> structured evidence returns to root Agent
-```
-
-Long-term semantic writes, relationships, soft deletion, and Memory Space creation, updates, and merges use the same pattern. Ordinary Runtime Memory and Document mutations first pass through the coordinator but are usually committed directly by the deterministic control layer; only capacity maintenance or archiving requires an additional worker.
-
-Physical Memory Space deletion is a separate deterministic destructive action. The WebUI must show a second confirmation, then invoke native Mnemon `store remove` through the loopback write RPC; the directory registration is removed only after the CLI deletion succeeds.
-
-## Two Types of Subagent
-
-### `spawn`
-
-`spawn` uses a new isolated context. For each task type, the plugin supplies:
-
-- a fixed persona;
-- a minimal tool allowlist;
-- a structured output schema within the subset supported by DSH;
-- `maxDepth: 1`;
-- a cancellable signal and bounded token budget.
-
-It is used for recall, long-term semantic writes, evidence-bound answers, hot-memory maintenance, and Document archiving.
-
-### `fork`
-
-Scored background review requires a provider named `fork` with `inheritsParentContext=true`. It inherits only a completed parent checkpoint and determines whether to maintain hot memory or at most one Project Document. It is not a continuation of the user's task, and it does not inject review reasoning into the main conversation.
-
-The current review allowlist excludes `mnemon_remember`, `mnemon_forget`, and Memory Space maintenance tools, so background review cannot modify long-term Memory Spaces directly.
-
-## Control Plane and Data Plane
-
-```text
-LLM-owned judgment                  Host-owned guarantees
-------------------                  ---------------------
-what is worth keeping               input validation
-which Memory Space fits             path boundary
-whether two items are duplicates    process timeout/cancel
-how to summarize a Document         file lock + atomic rename
-whether a reusable artifact exists  UTF-8 capacity accounting
-                                     revision conflict rejection
-                                     read/write RPC authority
-```
-
-Persona constraints must be distinguished from hard Host guarantees. For example, the MEMORY archival worker is instructed to cover every committed hot-memory item, but the Host can strictly validate only the structured action, revision, and byte budget; the Host does validate USER compaction source coverage item by item.
-
-## Web Boundary
-
-The WebUI does not start system processes or open SQLite directly:
-
-```text
-browser component
-  -> typed client wrapper
-  -> DSH RPC authority check
-  -> Host validation
-  -> controller / service / bounded worker
-  -> local CLI or managed files
-```
-
-Read channels require `trusted-host`; memory write channels and settings channels require `loopback`. When `writeEnabled=false`, the Host does not register memory write channels.
-
-## Internationalization
-
-`src/client/locales.ts` defines `MnemonKey` from the Chinese key set, and the English dictionary must satisfy the same set of keys; `src/client/index.ts` registers both dictionaries with the DSH locale. The main Web pages and settings card switch immediately with the DSH global language and reuse the global light or dark theme.
-
-Command output, tool-card titles, persisted compatibility-default Memory Space names, and some backend errors are still monolingual. This is a known gap on the Roadmap.
-
-## Key Modules
-
-| Module | Responsibility |
-|---|---|
-| `src/index.ts` | Host composition and registration |
-| `src/config.ts` | Configuration schema, defaults, and resolution |
-| `src/process.ts` | Bounded process execution without a shell |
-| `src/runner.ts` | CLI discovery, arguments, serialization, and JSON parsing |
-| `src/service.ts` | Application facade for long-term memory |
-| `src/memory-bodies.ts` | Memory Space catalog metadata |
-| `src/runtime-memory.ts` | Hot-memory source of truth and projections |
-| `src/documents.ts` | Documents control plane |
-| `src/subagent.ts` | Worker orchestration and capacity transactions |
-| `src/lifecycle.ts` | Per-root-Agent lifecycle |
-| `src/review-activity.ts` | Deterministic review scoring |
-| `src/tools.ts` | Model tools and root/worker routing |
-| `src/rpc.ts` | Web read/write channels |
-| `src/storage-scope.ts` | Read-only inventory of the three storage scopes |
-| `src/client/*` | Web workspace, settings, and locale |

package/docs/en/configuration.md

@@ -1,234 +0,0 @@
-# Configuration Reference
-
-[简体中文](../zh-CN/configuration.md) | **English** | [Documentation Center](./README.md)
-
-## Configuration Location and Activation
-
-The plugin registers the `mnemon` namespace with the DSH settings service. User configuration is stored in:
-
-```text
-$DSH_HOME/settings.yaml
-```
-
-The default is commonly `~/.dsh/settings.yaml`. All current settings are marked `live`; after Save, the Host initializes a candidate runtime graph and then switches to it atomically.
-
-The Web settings page edits `displayMode`, `storageScope`, and `dataDir`, plus the Turn memory and Save-to-memory switches under `mnemon-ui`. The same page also imports or exports a ZIP for the effective root. Other advanced settings must be changed directly in YAML.
-
-## Complete Example
-
-```yaml
-mnemon:
-  displayMode: sidebar # sidebar | buildin
-  storageScope: global # global | workspace | custom
-  # dataDir: ~/mnemon-data       # required for custom
-  # cliPath: /opt/homebrew/bin/mnemon
-  # store: legacy-store          # compatibility discovery hint, not a regular routing target
-  timeoutMs: 10000
-  defaultRecallLimit: 10
-  routingGuidance: true
-  lifecycleEnabled: true
-  recallMode: guided
-  writebackMode: guided
-  idleReviewMs: 30000
-  tabEnabled: true
-  writeEnabled: true
-```
-
-## Options
-
-| Setting | Default | Range | Implementation Semantics |
-|---|---:|---|---|
-| `displayMode` | `sidebar` | `sidebar` / `buildin` | `sidebar` mounts the dedicated sidebar workbench; `buildin` restores the native DSH conversation-area tab; saving switches live and never mounts both entries together |
-| `storageScope` | `global` | `global` / `workspace` / `custom` | Controls the root for Runtime, Documents, Memory Spaces, and reserved state as one unit |
-| `dataDir` | unset | absolute path, `~`, or `~/...` | Required for `custom`; legacy configurations that set only this option automatically resolve to `custom` |
-| `cliPath` | auto-discovered | executable path | Explicitly selects the Mnemon CLI |
-| `store` | unset | `[A-Za-z0-9][A-Za-z0-9_-]*` | Compatibility discovery/preference hint for legacy Stores; semantic operations are routed through Memory Spaces |
-| `timeoutMs` | `10000` | 100–120000 ms | Hard timeout for a single CLI call |
-| `defaultRecallLimit` | `10` | 1–50 | Default recall count for the service and UI; individual entry points may impose a lower limit |
-| `routingGuidance` | `true` | boolean | Whether to register an additional tiered-routing system section |
-| `lifecycleEnabled` | `true` | boolean | Whether to enable the pre-step cue and score-based background review |
-| `recallMode` | `guided` | `guided` / `off` | Whether to inject an on-demand recall cue; does not remove explicit recall |
-| `writebackMode` | `guided` | `guided` / `off` | Whether to inject the hot-memory cue and enable score-based background review; does not remove explicit writes |
-| `idleReviewMs` | `30000` | 5000–600000 ms | Required continuous idle time after the threshold is reached |
-| `tabEnabled` | `true` | boolean | Whether to mount the Web entry selected by `displayMode`; Host RPC, commands, and Agent tools remain registered when off |
-| `writeEnabled` | `true` | boolean | Whether to expose semantic write tools, write RPC, and write commands |
-| `mnemon-ui.turnBar` | `true` | boolean | Turn-tail memory activity bar; on by default, **applies live after saving** |
-| `mnemon-ui.saveAction` | `true` | boolean | “Save to memory” icon and confirmation on finalized assistant replies; on by default, **applies live after saving** |
-
-Both the `mnemon` Host/storage namespace and the `mnemon-ui` browser-presentation namespace apply live. The storage root switches atomically only after the new runtime graph initializes successfully. Legacy `mnemon.conversationInteraction` values remain a migration default, but new saves write only to `mnemon-ui`.
-
-## Storage Scopes
-
-### `global`
-
-```text
-MNEMON_DATA_DIR when non-empty
-  otherwise ~/.mnemon
-```
-
-Suitable for users who want Runtime, Documents, and Memory Spaces shared across multiple workspaces. Other Mnemon-enabled agents can also share the Mnemon Memory Spaces when they use the same root.
-
-### `workspace`
-
-```text
-Agent / tool / lifecycle: resolve(currentSession.header.cwd, ".mnemon")
-Web workbench inspection: resolve(workspaceRegistry.get(selectedWorkspaceId).path, ".mnemon")
-```
-
-Each DSH workspace owns an independent three-tier memory root. Agents, model tools, commands, and lifecycle hooks route by the current session cwd and are unaffected by the Web workbench's inspection target. The workbench can select only Host-registered workspaces, never an arbitrary path. When inspection and execution differ, the header shows both paths and offers one-click alignment with the current session. Agent-backed actions are rejected while misaligned to prevent writes to the wrong project.
-
-### `custom`
-
-```yaml
-mnemon:
-  storageScope: custom
-  dataDir: /absolute/path/to/mnemon-data
-```
-
-`~` and `~/...` are also allowed. Relative paths are rejected.
-
-### Choose a Cross-Agent Sharing Scope
-
-| Goal | Recommended scope | Notes |
-|---|---|---|
-| Share durable memory among local agents | `global` | Every participant uses `~/.mnemon` or the same `MNEMON_DATA_DIR` |
-| Share one explicit data root | `custom` | Every participant configures the same absolute directory for isolation and backup |
-| Share only inside one project | `workspace` | Every participant aligns its Mnemon root to that project's `<workspace>/.mnemon` |
-
-Only the Mnemon durable tier under `data/<store>/mnemon.db` has native cross-agent interoperability. Runtime, Documents, DSH activation state, and UI metadata remain managed by dsh-mnemon.
-
-## CLI Discovery Precedence
-
-```text
-config.cliPath
-  -> executable MNEMON_CLI_PATH
-  -> each PATH directory
-  -> Windows: GOBIN/mnemon.exe
-              first GOPATH/bin/mnemon.exe, or ~/go/bin/mnemon.exe
-              %LOCALAPPDATA%/Programs/mnemon/mnemon.exe
-              %ProgramFiles%/mnemon/mnemon.exe
-  -> Unix: ~/.local/bin/mnemon
-           /opt/homebrew/bin/mnemon
-           /usr/local/bin/mnemon
-           /usr/bin/mnemon
-```
-
-An explicit `cliPath` is accepted as configured; if it is not executable, actual calls return a launch error. Automatically discovered Windows commands must be regular `.exe` files. `.cmd` and `.bat` wrappers are intentionally excluded because process execution does not use a shell.
-
-## Compatibility Store Hint Precedence
-
-```text
-config.store
-  -> MNEMON_STORE
-  -> <storageRoot>/active
-  -> default
-```
-
-After the Memory Space directory has been established, long-term semantic operations use explicit Memory Space IDs and do not rely on the global active Store for routing.
-
-## Provider Requirements
-
-Regular workers prefer `spawn`. If no provider has that name, another provider with all of the following capabilities can be selected:
-
-```text
-outputSchema = true
-toolFilter   = true
-persona      = true
-depthLimit   = true
-```
-
-Background review has no fallback: a compatible provider named `fork` must exist and must have:
-
-```text
-inheritsParentContext = true
-```
-
-A missing `fork` does not block deterministic state or regular UI reads, but a subagent failure is recorded when the review threshold is reached.
-
-## Read-Only Configuration
-
-```yaml
-mnemon:
-  writeEnabled: false
-```
-
-Effects:
-
-- Model write tools are not registered;
-- `/dsh-mnemon-write` RPC is not registered;
-- `/mnemon remember` and `/mnemon forget` are rejected;
-- semantic mutations through `MnemonService` are rejected.
-
-This is feature-level read-only behavior, not a read-only filesystem mode: the Runtime controller may still initialize or repair projections, Document search updates LRU access times, and Mnemon read commands may trigger upstream database migrations. Do not treat `writeEnabled=false` as a safety guarantee for read-only mounts.
-
-## Switch Interactions
-
-```text
-writeEnabled=false
-  -> overrides all explicit semantic writes
-
-writebackMode=off
-  -> no write cue, no scored review
-  -> explicit writes remain when writeEnabled=true
-
-recallMode=off
-  -> no recall cue
-  -> explicit recall remains
-
-lifecycleEnabled=false
-  -> no lifecycle cues or review
-  -> UI, commands, and explicit tools remain
-
-routingGuidance=false
-  -> removes only mnemon:routing
-  -> runtime-memory prompt section remains
-```
-
-## Display Mode and the `tabEnabled` UI Switch
-
-`displayMode=sidebar` (the default) mounts the “Memory System” sidebar entry and its dedicated center-column workbench with a minimal, logo-free skin aligned with official DSH panels. `displayMode=buildin` instead registers the original DSH `conversation.view` tab and preserves its existing visuals. The modes share the functional workbench while keeping appearance definitions isolated. Saving first disposes the active entry and then mounts the target, so the two modes never appear simultaneously.
-
-`tabEnabled=false` removes the currently selected Web entry live. Host RPC, commands, and tools remain registered across display-mode and enablement changes so an Agent or command already in progress stays valid.
-
-## Profile Patch Overrides
-
-The bundled `cordis.patch.yml` provides the default config row. A DSH profile configuration with the same ID may replace that row as a whole. Do not add only `cliPath` to a final profile patch: use `MNEMON_CLI_PATH` or the `mnemon.cliPath` user setting instead. When a profile patch must be customized for another reason, retain every key that must remain enabled instead of assuming a deep merge.
-
-## Common Configurations
-
-Workspace isolation:
-
-```yaml
-mnemon:
-  storageScope: workspace
-```
-
-An explicit Windows CLI path:
-
-```yaml
-mnemon:
-  cliPath: 'C:\Users\alice\AppData\Local\Programs\mnemon\mnemon.exe'
-```
-
-A custom data volume and a longer CLI timeout:
-
-```yaml
-mnemon:
-  storageScope: custom
-  dataDir: /Volumes/AgentData/mnemon
-  timeoutMs: 30000
-```
-
-Keep explicit tools while disabling lifecycle behavior:
-
-```yaml
-mnemon:
-  lifecycleEnabled: false
-```
-
-Disable only background writeback decisions:
-
-```yaml
-mnemon:
-  writebackMode: off
-```

package/docs/en/development.md

@@ -1,198 +0,0 @@
-# Development and Verification
-
-[简体中文](../zh-CN/development.md) | **English** | [Documentation Center](./README.md)
-
-## Environment
-
-The repository does not declare minimum Node, pnpm, DSH, or Mnemon versions in `package.json`. Use the current DSH development environment and verify compatibility through the full validation chain whenever dependencies are upgraded.
-
-Install dependencies:
-
-```sh
-pnpm install
-```
-
-## Standard Commands
-
-```sh
-pnpm run typecheck  # tsc --noEmit
-pnpm test           # vitest run
-pnpm run build      # declarations + host/client bundles
-pnpm run verify     # typecheck + test + build
-```
-
-## Directory Structure
-
-```text
-src/
-+-- index.ts                  # Host composition root
-+-- config.ts                 # settings schema
-+-- process.ts / runner.ts    # local CLI execution
-+-- service.ts                # durable-memory facade
-+-- memory-bodies.ts          # Memory Space registry
-+-- runtime-memory.ts         # hot-memory authority
-+-- documents.ts              # managed Documents
-+-- subagent.ts               # bounded workers
-+-- lifecycle.ts              # root-Agent hooks
-+-- review-activity.ts        # activity score
-+-- tools.ts / commands.ts    # model and human interfaces
-+-- rpc.ts / settings.ts      # Web bridges
-+-- storage-scope.ts          # storage inventory
-+-- client/                   # React workspace and locales
-tests/                        # Vitest suites
-lib/                          # committed build artifacts
-docs/zh-CN/                   # Chinese documentation
-docs/en/                      # English mirror
-cordis.patch.yml              # DSH profile bundle patch
-```
-
-## Build Artifacts
-
-```text
-tsc -p tsconfig.build.json
-  -> lib/types/*              declarations, maps, intermediate ESM
-
-tsdown host bundle
-  -> lib/index.js             Node ES2024 ESM
-
-tsdown client bundle
-  -> lib/client.js            DSH browser module wrapper
-  -> lib/client.js.map
-
-lightningcss plugin
-  -> CSS Modules compiled and injected as scoped <style>
-```
-
-The Host keeps `cordis` and `schemastery` external. The client keeps React, ReactDOM, the JSX runtime, and Cordis external; all other dependencies are included in the bundle.
-
-`lib/` is part of the publishing input. After modifying `src/`, rebuild and inspect the generated diff. Do not edit `lib/` manually.
-
-## Test Layers
-
-The existing Vitest suites cover:
-
-- configuration parsing, CLI discovery, and process serialization;
-- Memory Space discovery, activation, routing, and merge;
-- recall-payload compatibility and graph parsing;
-- Runtime JSON/Markdown consistency, locks, capacity, UTF-8, and revisions;
-- Document paths, frontmatter, search, LRU, archiving, and conflicts;
-- worker tool isolation, the schema subset, and structured receipts;
-- lifecycle cues, scoring, idle debounce, cancellation, and watermark retention;
-- RPC authority, read-only behavior, and settings revisions;
-- the Web workspace, bilingual copy, and key interactions.
-
-These are primarily integration tests using temporary directories, fake runners, and a mock Host. They are not equivalent to automated end-to-end tests of the real DSH + Mnemon WebUI.
-
-## Real WebUI Verification
-
-Use an isolated environment before release to avoid contaminating personal memory:
-
-```text
-temporary DSH_HOME
-temporary MNEMON_DATA_DIR or custom storageScope
-temporary workspace
-independent Web port
-local link installation
-```
-
-Recommended scenarios:
-
-1. Empty root: the UI reports no errors and can create the first Memory Space.
-2. Regular conversation: only a short cue appears; recall and writes are not forced.
-3. Historical question: the Agent independently recalls and returns the correct space provenance.
-4. Explicit distillation: the worker deduplicates, selects a scope, and writes content that can be recalled again.
-5. Multiple spaces: reads cover only active spaces; writing to an inactive space activates it automatically afterward.
-6. Runtime: USER / MEMORY add, replace, remove, and projection consistency.
-7. Documents: create, retrieve, update, manually archive, and leave original project files unchanged.
-8. Score-based review: light tasks do not trigger it; after reaching the threshold it waits for idle; a new turn can cancel it while preserving the watermark.
-9. Read-only: write tools, write commands, and write RPC are rejected while reads remain available.
-10. Sidebar: all four primary tabs, four Memory Space secondary tabs, stable headings, filters, and progressive loading work.
-11. Conversation UI: Turn memory appears only for completed turns with activity; links land correctly; canceling Save to memory performs no write.
-12. Settings: Sidebar / Buildin, storage scopes, and both conversation switches apply live without refresh.
-13. ZIP: export can be previewed and merged into an isolated custom root; damaged checksums are rejected.
-14. Versions: checking never installs; link/manual sources offer no unsafe update; successful updates trigger a fresh status check.
-15. Status and browser console: no unhandled errors or warnings.
-
-Capacity limits, CLI timeouts, revision conflicts, and Host restarts should be verified in a dedicated fault-injection environment.
-
-## Maintaining Documentation Visuals
-
-Public UI screenshots live under `docs/assets/screenshots/`, shared by both language editions. Language-specific architecture diagrams live under `docs/assets/diagrams/zh-CN/` and `docs/assets/diagrams/en/`. When layout, primary copy, or defaults change:
-
-1. Use a real DSH Web profile, but first check that the frame contains no token, credential, or private personal data.
-2. Limit capture to inspection, filtering, expansion, and opening dialogs. When showing a write flow, stop before final confirmation.
-3. Replace screenshots with the same responsibility instead of accumulating versioned filenames. Add an asset only for a new user task.
-4. Refresh the README poster, GIF / MP4 demo, and both `ui-guide.md` files.
-5. Confirm PNG / JPEG extensions match actual encoding and that text is readable at original resolution.
-6. Remove unreferenced assets, stale Buildin layouts, and obsolete terminology.
-7. Run link/image checks, then open both READMEs and UI guides manually.
-
-README demo assets are `docs/assets/media/dsh-mnemon-memory-system-demo.*`. The demo should cover Status, Runtime, Memory Spaces, Documents, and in-conversation confirmation without actually submitting memory, updating components, or changing settings through automation.
-
-## Modifying Subagent Schemas
-
-DSH structured output supports only a compact JSON Schema subset:
-
-```text
-type, oneOf, properties, required, additionalProperties,
-items, enum, const, and annotation keywords
-```
-
-Do not add unsupported keywords such as `maxItems`. `assertDshOutputSchema()` recursively rejects unknown schema keys before starting a worker; result-count and similar limits are enforced by both the persona and the Host parser.
-
-## Modifying Storage Formats
-
-Runtime, Documents, and the Memory Space registry each have a version field or fixed structure. Changes require:
-
-1. Define how the old format is parsed;
-2. add a migration or rejection path;
-3. preserve temporary-file and atomic-rename behavior;
-4. add tests for concurrency and damaged inputs;
-5. update the Chinese and English storage, operations, and Roadmap documents;
-6. verify upgrade and rollback against a copied data root.
-
-There is currently no formal schema-migration framework, so persistent formats must not change silently.
-
-## Maintaining Documentation Internationalization
-
-`docs/zh-CN` and `docs/en` should contain matching filenames with the same section responsibilities. When changing defaults, workflows, or limitations:
-
-- update both languages;
-- keep commands, configuration keys, paths, and code symbols exactly the same;
-- cross-link corresponding language pages with relative paths;
-- prefer accessible SVGs with no scripts or external resources for architecture overviews; keep directory trees, commands, formulas, and short protocols as copyable `text` / ASCII;
-- keep only summaries in the root READMEs and place details on one authoritative docs page;
-- for every user-visible interface change, also inspect `ui-guide.md`, `getting-started.md`, `configuration.md`, and `operations.md`.
-
-When the Web locale changes, the Chinese key set remains the type source of truth. The English dictionary must satisfy `Record<MnemonKey, string>` and preserve the same placeholders.
-
-## Release Checklist
-
-```text
-[ ] pnpm run verify
-[ ] review source and generated lib diffs
-[ ] validate package file list includes README.md, README.zh-CN.md, docs/assets, and bilingual docs
-[ ] install the built/local bundle into an isolated Web profile
-[ ] run real Mnemon CLI and WebUI smoke tests
-[ ] verify Chinese and English workspaces
-[ ] verify global/workspace/custom paths as applicable
-[ ] record tested DSH and Mnemon versions
-[ ] back up any data root used for upgrade testing
-```
-
-`package.json.files` currently publishes `lib`, the patch, both root READMEs, centrally managed documentation visuals, the public bilingual docs, and the License.
-
-## Publishing to npm
-
-After publication, `dsh plugin --profile web add dsh-mnemon` resolves by registry name — the same path as dsh-better-sidebar. Steps:
-
-```sh
-npm pack --dry-run                 # inspect the tarball file list (cordis.patch.yml, lib, docs)
-pnpm publish --access public       # prepublishOnly runs pnpm run verify first
-```
-
-Credential convention: write NPM_TOKEN only to the user-level `~/.npmrc` (`npm config set "//registry.npmjs.org/:_authToken" "${NPM_TOKEN}" --userconfig ~/.npmrc`) and remove it after publishing. Do **not** commit the credential line to the repository `.npmrc`: pnpm 11 deliberately ignores unexpanded environment-variable credentials in project-level `.npmrc` (with a warning), and that file travels with the repo.
-
-2FA note: when the npm account has publish-level two-factor authentication, an interactive `pnpm publish --access public` prompts for the OTP; scripted/CI publishing needs a Classic **Automation** token or a Granular token allowed to bypass 2FA (a plain token from `npm login` cannot publish and fails with 403 Two-factor authentication required).
-
-Before publishing, check that `package.json` `repository`/`homepage`/`bugs` point at `omdsh-dev/dsh-mnemon` (npm page consistent with GitHub) and that the version has been bumped.