upstream-radar

dsh plugin --profile web add upstream-radar

<h1 align="center">Upstream Radar</h1>

<p align="center"><strong>Always-on compatibility testing for DeepSeek Harness plugins—across headless, Web, and TUI.</strong></p>

<p align="center">

<a href="README-zh-CN.md">简体中文</a> ·

<a href="https://github.com/MicroMilo/upstream-radar/actions/workflows/ci.yml"><img alt="CI" src="https://github.com/MicroMilo/upstream-radar/actions/workflows/ci.yml/badge.svg"></a>

<a href="https://www.npmjs.com/package/upstream-radar"><img alt="npm" src="https://img.shields.io/npm/v/upstream-radar"></a>

<a href="https://github.com/MicroMilo/upstream-radar/stargazers"><img alt="GitHub stars" src="https://img.shields.io/github/stars/MicroMilo/upstream-radar"></a>

<a href="LICENSE"><img alt="Apache-2.0" src="https://img.shields.io/badge/license-Apache--2.0-blue.svg"></a>

</p>

Upstream Radar binds exact plugin bytes to an exact DSH host and runtime, lets an

Agent derive a bounded environment from repository instructions and prior

evidence, then proves the relationship in disposable GitHub VMs. It runs again

when the ecosystem changes or evidence expires, so it tests the current

version—not only the diff.

It is built for the DeepSeek Harness (DSH)

plugin ecosystem. A static review is evidence about a package; an isolated

runtime review is evidence about one exact plugin × DSH × Node/profile pair.

Neither is presented as a timeless compatibility badge or a security certificate.

Listed by the DSH ecosystem in

awesome-dsh-plugin,

awesome-deepseek-harness, and

awesome-deepseek-harness-plugins.

The problem

A source repository can be green while the package users install is not ready

for the current DSH host:

• the README advertises a version that was never published;
• a plugin imports a newer DSH package than its peer range allows;
• package.json and the lockfile describe different releases;
• an install-time build or dependency script needs tools the user does not have;
• a DSH host dependency is missing, so the dependency graph cannot be completed.

These are ecosystem relationship problems. They are easy to miss when the two

repositories are checked separately.

What Radar does

1. Build one exact compatibility record (IR). Align the npm artifact,

source commit, DSH host, runtime/profile, dependency paths, and advisories.

2. Derive the environment. An Agent reads declared installation guidance

and failed evidence, then emits only a bounded install plan.

3. Prove each execution plane. Fresh, secret-free runners exercise headless

load, Chromium Web boot, or a real PTY TUI interaction.

4. Keep the result alive. DSH/plugin/dependency changes and evidence expiry

trigger retests; confirmed failures become fixable reports and clean retests

close the loop.

flowchart TB
  Trigger["Schedule / upstream change / evidence expiry"] --> IR["Exact IR: plugin bytes ↔ DSH ↔ runtime ↔ dependencies"]
  IR --> Agent["Agent derives a bounded install plan"]
  Agent --> VM{"Fresh secret-free GitHub VM"}
  VM --> Headless["Headless: install → register → load"]
  VM --> Web["Web: Chromium → boot handoff → client bundle"]
  VM --> TUI["TUI: PTY → frame → input → declared shutdown"]
  Headless --> Ledger["Versioned evidence ledger + reverse impact index"]
  Web --> Ledger
  TUI --> Ledger
  Ledger --> Decision{"Plugin-attributable failure?"}
  Decision -->|"yes"| Issue["Produce one fixable maintainer report"]
  Decision -->|"no / detector gap"| Hold["Hold the report and calibrate"]
  Issue -->|"author ships a fix"| Trigger
  Hold --> Trigger

The Agent may choose declared build packages, profile setup, and the next bounded

retry. Exact fingerprints decide which cell a report can satisfy, and the

disposable runner—not the model—establishes the result. Missing evidence can

never become a pass.

Try a real check

No local DSH profile is needed for this first check. It reviews one exact

published artifact without executing plugin code:

npx --yes upstream-radar@0.45.0 inspect \
  @sanqi-normal/dsh-webui-market-plugin@0.5.4 \
  --deep --fail-on never

This historical DSH plugin release returns review / incomplete because its

published host dependency chain reaches an unavailable package. That is a

useful, reproducible release/host-contract report—not a claim of malicious

behavior. See the [full evidence report](examples/dsh/reports/sanqi-market-plugin-dependency-resolution.md).

To review your own public repository without installing it:

npx --yes upstream-radar@0.45.0 scan \
  https://github.com/owner/dsh-plugin \
  --fail-on never

The repository scan reads source manifests, DSH metadata, and lockfiles. It does

not install dependencies, run lifecycle scripts, load the plugin, start DSH, or

call an LLM.

Run it on every change

Copy one of the maintained workflows into your repository:

• [Review one exact plugin across DSH versions](examples/github-actions/dsh-plugin-review-minimal.yml)

— a manual check with artifact evidence and an isolated load matrix.

• [Observe one plugin repository every day](examples/github-actions/upstream-observer-minimal.yml)

— compares commits, published versions, manifests, and dependency graphs, then

wakes an Agent only when there is a meaningful change.

• [Run the dependency gate in CI](examples/github-actions/upstream-radar.yml)

— checks the lockfile or reviewed Radar configuration before merge.

The isolated [headless](.github/workflows/observe-dsh-plugin-install.yml) and

[Web/TUI](.github/workflows/observe-dsh-plugin-surface.yml) observers use fresh

GitHub-hosted runners. They are not your workstation and re

…(truncated)