Introduction

When maintaining a DSH instance for a long time, configuration resources under $DSH_HOME easily become a confusing mess: files are manually copied in, mistakes break things without knowing where changes were made, two config packages overwrite each other when written to the same file sequentially, and after problems occur, neither can the source be traced nor can it be reverted. DSH’s philosophy is “everything is a plugin,” but making the distribution and uninstallation of data-type configuration resources into auditable transactions did not have existing tools before.

The dsh-vibe-pack introduced below addresses this problem: it turns the installation of resources into a transaction that can preview, then install, and roll back, while tracking file ownership throughout the entire process.

What is it

dsh-vibe-pack is an atomic, data-only configuration package manager for DeepSeek Harness, maintained by LeemanCheung, licensed under MIT. It provides five types of operations centered around $DSH_HOME: preview, install, diff, export, and uninstall, accompanied by integrity checks, ownership tracking, and failure rollback.

Current version 1.0.1, declares compatibility with DSH 0.1.2-rc.1’s web profile (>=0.1.2-rc.1 <0.1.3-0), verified by Windows QA.

Core Features

Pure Data Package Format

The source of a package is a local directory or a .dshpack/.zip archive containing dshpack.yaml and all listed payloads. A strict v1 manifest includes id, version, compatibility range, 1–10,000 files, SHA-256 for each file, create/replace/merge modes, and ownership metadata.

Accepted payloads are strictly data: JSON/YAML/.dshskin, Markdown/text/TOML/INI, PNG/JPEG/WebP/GIF images. Scripts, hooks, shell commands, JS modules, URL fetching, symlinks, YAML alias/tag/anchor, embedded credentials, path traversal, and duplicate archive paths are all rejected, as are executable files and unknown extensions. Archives are checked for compression, expansion, single-file, byte, and entry limits before payloads are used.

Preview and Ownership Confirmation

Preview is mandatory before installation, reporting create/replace/merge actions and conflicts; the installation action is bound to the preview digest. Explicit force selection is required in the following four cases:

  1. No owner file
  2. Files belonging to another package
  3. create mode conflicts
  4. Resources modified after installation

force only transfers ownership listed in the manifest and is not triggered implicitly.

Transactions and Rollback

Installation and uninstallation are serialized by a disk transaction lock. Before writing, every target is backed up, then written atomically in a fixed order; on failure, recovery happens in reverse order, reporting partial rollback errors. The ledger is atomically written to $DSH_HOME/.dsh-vibe-pack/ledger.json. Uninstallation also protects modified resources unless explicitly force.

Every managed read and write resolves the real filesystem location first. Before preview, backup, export, directory creation, writing, or removal, symlinks or Windows junctions are rejected as soon as they leave the configured DSH root.

Merge and Export

Merge mode accepts JSON or YAML objects, recursively merging object keys, and replacing arrays and scalars entirely, rejecting prototype keys and secrets, outputting deterministic data. Before export, installed resources are verified to still match the ledger, then a portable .dshpack archive is generated.

UI and CLI

After installation, DSH Web’s Settings → Vibe Pack panel provides forced preview, digest-bound installation, ledger history, diff, uninstall requiring independent confirmation, and .dshpack download; the generated Typert namespace is vibePack. The command line provides the dsh-pack tool with subcommands inspect/plan/install/history/diff/export/uninstall; --root defaults to $DSH_HOME and only needs to be passed when managing an explicitly specified test root.

Installation and Enabling

dsh plugin --profile web add github:LeemanCheung/dsh-vibe-pack

After installation, restart the existing DSH Web process and refresh the page; you will see the Vibe Pack panel in Settings.

Typical Usage

First check if the manifest and payloads of a package directory are compliant:

dsh-pack --root $env:DSH_HOME inspect ./my-pack

Generate an action plan before installation to confirm create/replace/merge and conflict situations:

dsh-pack --root $env:DSH_HOME plan ./my-pack.dshpack

After confirmation, execute the installation:

dsh-pack --root $env:DSH_HOME install ./my-pack.dshpack

After the above steps, you can use history to view the ledger history, diff to compare current differences, export to export the archive, and uninstall to remove the package:

dsh-pack --root $env:DSH_HOME history
dsh-pack --root $env:DSH_HOME diff my-pack
dsh-pack --root $env:DSH_HOME export my-pack > my-pack.dshpack
dsh-pack --root $env:DSH_HOME uninstall my-pack

The examples above use PowerShell’s $env:DSH_HOME syntax. --force should only be used after reviewing the reported ownership or modification conflicts.

To participate in development, you can run corepack pnpm typecheck, corepack pnpm test, corepack pnpm build, and corepack pnpm pack:check in the repository root. CI rebuilds the committed lib artifacts on Windows and Linux and rejects any differences; security acceptance test cases are in TEST_PLAN.md.

Use Cases and Notes

Suitable for developers who need to package, back up, migrate, and share data resources under $DSH_HOME, and care about “which files were changed by which change” and “whether it can be reverted”.

Note the following points before use:

  1. The plugin does not add prompts, tools, messages, token usage, or KV-cache content to the model; all checks and changes are explicitly executed via UI/CLI on the Host.
  2. The transaction lock will error (fail loud) after an abnormal process exit; you may need to manually remove it after confirming no Vibe Pack process is active.
  3. Remote operations are shared with trusted clients in the same DSH Web combination.
  4. The package format provides SHA-256 integrity and ownership verification but does not provide publisher signatures or network distribution.
  5. 1.0.1 only declares compatibility with DSH 0.1.2-rc.1’s web profile.
  6. The plugin runs with the permissions of the current dsh process; you should review the plugin source code and confirm the license (MIT, see repository LICENSE) before installation.

Conclusion

The value of dsh-vibe-pack lies in turning configuration resource installation from “manual copying and relying on memory” into a previewable, trackable, and rollbackable transaction. See the community directory page at https://www.skillhub.cn/plugins/LeemanCheung/dsh-vibe-pack, and source code and documentation at https://github.com/LeemanCheung/dsh-vibe-pack.