@yadsh DeepSeek Harness plugins

A collection of installable DeepSeek Harness (DSH) plugins. They add session workspace scoping, documentation-impact tracking, prompt-injection and firewall controls, draft sessions, localization overrides, KV persistence, git provenance, QA surfaces, and developer tooling to a harness profile — each one published as its own npm package and installable on its own.

DSH resolves plugins as npm packages, so install only what you need:

dsh plugin --profile <profile> add @yadsh/dsh-session-scope

Every published package is listed in the generated plugins.json catalog, which maps each npm name to its source directory here for marketplaces, indexes, and crawlers. Repositories and packages carry the dsh-plugin GitHub topic and the same canonical keywords (deepseek-harness, dsh, dsh-plugin, cordis).

Repository layout

@yadsh (Yet Another DSH) is a pnpm + Nx monorepo for independently versioned DeepSeek Harness plugins. Each directory under plugins/ is its own public npm package; shared runtime libraries and workspace tooling live under packages/.

Packages

Runtime plugin IDs remain unscoped (dsh-*) because DSH bundle composition and browser module loading use those IDs. The @yadsh scope is the npm package identity.

Development

Requirements: Node.js 22 or newer and pnpm 10.4.1.

pnpm install --frozen-lockfile
pnpm check
pnpm deps:check
pnpm tarball:verify

Nx runs project-local lint, typecheck, test, build, and verify scripts and caches their outputs. The dependency check enforces workspace boundaries, while the tarball check packs every public package, validates its manifest and exported files, and installs it in a clean consumer project.

plugins.json is generated from the workspace manifests. Regenerate it after changing a package description, keywords, or the package set — pnpm verify:packages fails while the catalog is stale:

pnpm plugins:manifest

Adding a plugin

pnpm nx g dsh-plugin <name> [--client] [--description "..."]

The generator defaults to the @yadsh npm scope and creates the package, Cordis patch, build configuration, tests, and public-package metadata. The scaffold is a starting point: before writing code, read the plugin guidelines — the canonical architecture, package-content, testing, documentation, and release rules every plugin must follow. Run pnpm plugins:manifest afterwards so the new package enters the catalog.

Documentation

• Architecture overview — layout, host/client split, build outputs, dependency rules
• Plugin guidelines — the canonical rulebook every plugin must follow
• Plugin logging — file logging API, formats, levels, console mirror
• Verification runbook — what each gate asserts, locally and in CI
• Releasing and compatibility policy

Releases

Packages use independent Nx Version Plans:

pnpm release:plan
pnpm release:check
pnpm release:dry-run -- --first-release

The GitHub release workflow builds and verifies selected package tarballs before publishing through npm Trusted Publishing. See the release runbook and compatibility policy.

License

MIT