Pular para o conteúdo principal
D

dsh-openviking-status

dipertq/dsh-openviking-status

Minimalist OpenViking status chip and popover for DeepSeek Harness composer

Instalar

dsh plugin --profile web add github:dipertq/dsh-openviking-status

README

@dipertq/dsh-openviking-status

Minimalist OpenViking status chip and popover for DeepSeek Harness (DSH Desktop / Web).

Overview

This DSH UI plugin adds a chip to the composer stats row (conversation.composer.dock), alongside 24 turns 645 steps. It provides at-a-glance transparency into OpenViking memory management:

  • Server Health: Online / Offline indicator with live health checks.
  • Pending Tokens: Real-time counter of session tokens accumulated before the auto-commit threshold (20,000 tokens).
  • Recalled Memories: Count and list of the viking:// files injected into the current conversation.
  • Commit Trigger: Instant "Commit To Memory Now" action button.

Configuration & API Key

  • Zero-Config Auto-Discovery: When running locally, the plugin automatically discovers connection credentials from ~/.openviking/ovcli.conf, ~/.openviking/ov.conf, or the OPENVIKING_API_KEY environment variable.
  • DSH Settings Integration: Open DSH Settings → OpenViking to inspect connection health, run live connection tests, or customize your daemon endpoint and API token.
  • Seamless Remote Access (Tailscale / LAN / Mobile): Status requests proxy through the DSH Desktop host (/openviking-status/api/*), ensuring the chip and popover work reliably when accessing DSH remotely without CORS or localhost conflicts.

Architecture & Design

See CONTEXT.md, ADR 0001, and ADR 0002.

Installation in DeepSeek Harness

dsh plugin add @dipertq/dsh-openviking-status

Then restart DSH Desktop. That is the whole procedure: DSH reads the package's dsh.bundle.patch, adds it to dsh.profile.bundles itself, and the chip appears in the composer bar.

From a release tarball

Equivalent, and useful when the registry is unreachable. Use a version-pinned URL:

dsh plugin add https://github.com/dipertq/dsh-openviking-status/releases/download/v0.3.2/dipertq-dsh-openviking-status-0.3.2.tgz

Not /releases/latest/download/…: that URL keeps its name while its content changes, so pnpm records no integrity for it and every later pnpm install in the profile fails with ERR_PNPM_MISSING_TARBALL_INTEGRITY.

Why not github:dipertq/...?

That form works, but costs an extra manual step. A github: spec makes pnpm build the package on your machine, and pnpm blocks build scripts until the package is allowlisted. The pnpm shipped with DSH Desktop (11.8.0) only matches a commit-pinned key, which changes on every push — so the entry has to be re-added for each new version:

# ~/.dsh/profiles/desktop/pnpm-workspace.yaml
allowBuilds:
  "@dipertq/dsh-openviking-status@https://codeload.github.com/dipertq/dsh-openviking-status/tar.gz/<commit-sha>": true

Both recommended forms ship lib/ already compiled, so no build script runs and no allowlist entry is needed. See ADR 0004.

Troubleshooting: ERR_PNPM_IGNORED_BUILDS

If a previous github: attempt left entries in your profile's pnpm-workspace.yaml, pnpm may have written them with a literal placeholder:

allowBuilds:
  "@dipertq/dsh-openviking-status@https://...": set this to true or false

A placeholder means "not decided yet", so every install fails until it is a real boolean. Delete those stale entries — neither recommended install path needs any of them:

allowBuilds:
  node-pty: true

Releases & CI/CD

  • CI: Runs on every pull request and push to main (tsc, README install-URL check, pnpm test, pnpm run build).
  • Release: Pushing a v* tag builds the package, verifies it, and publishes a GitHub Release with the versioned .tgz.
  • Trigger a release:
    pnpm run release:patch  # 0.1.0 -> 0.1.1
    pnpm run release:minor  # 0.1.0 -> 0.2.0
    pnpm run release:major  # 0.1.0 -> 1.0.0
    
    Bump the install URL in this README to the new version — CI fails if it drifts.

npm publishing

Releases publish to npm through trusted publishing: GitHub Actions authenticates over OIDC with short-lived credentials, so there is no NPM_TOKEN secret to store or rotate, and each release carries a provenance attestation proving which commit and workflow built it.

This is already configured, so a release needs nothing beyond the usual pnpm run release:*. The one-time setup was: publish the first version by hand (trusted publishing is configured per package, so the package has to exist), then register a GitHub Actions publisher on the package's Settings → Trusted Publisher page — user dipertq, repository dsh-openviking-status, workflow release.yml, environment blank.

License

MIT

Plugins relacionados