upstream-radar 0.40.0 → 0.42.0

package/README.md

@@ -1,266 +1,97 @@
-# Upstream Radar
+<h1 align="center">Upstream Radar</h1>
 
-[![CI](https://github.com/MicroMilo/upstream-radar/actions/workflows/ci.yml/badge.svg)](https://github.com/MicroMilo/upstream-radar/actions)
-[![npm](https://img.shields.io/npm/v/upstream-radar)](https://www.npmjs.com/package/upstream-radar)
-[![License](https://img.shields.io/badge/license-Apache--2.0-blue.svg)](LICENSE)
+<p align="center"><strong>Know which DeepSeek Harness plugins break after every release—before users do.</strong></p>
 
-**The upstream dependency radar built into [DeepSeek Harness (DSH)](https://github.com/deepseek-ai/deepseek-harness) plugins.**
+<p align="center">
+  English · <a href="README.zh-CN.md">简体中文</a>
+</p>
 
-Upstream Radar is not another package-name vulnerability scanner. It follows one DSH plugin from admission to maintenance:
+<p align="center">
+  <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>
 
-| Product job | What Radar establishes |
-| --- | --- |
-| **DSH compatibility / admission** | Whether the exact published bundle can be installed, registered, and loaded by the DSH releases you care about, with an isolated execution lane for behavior evidence. |
-| **Real dependency graph** | Which exact package versions and physical paths the plugin brings into the DSH profile, including unresolved edges. |
-| **Continuous upstream monitoring** | Whether an advisory, npm release, DSH/Cordis change, or breaking signal changes the old → new situation. |
-| **Author-facing repair** | Which plugin, dependency path, version, lockfile, or DSH declaration gives the author a concrete next fix. |
+Upstream Radar continuously retests a maintained fleet of exact published
+plugins against changing
+[DeepSeek Harness (DSH)](https://github.com/deepseek-ai/deepseek-harness)
+releases in disposable runners. When a pair breaks, it produces a reproducible
+issue; when the author ships a fix, it retests and closes the loop.
 
-The deterministic scanner establishes package, graph, advisory, and compatibility facts. Only a meaningful affected change is handed to the DSH Agent for read-only, project-specific analysis; the model does not guess version matches or replace the evidence.
+**100 maintained install/load targets · 100 catalog entries across all 21 categories · 4 upstream reports closed**
 
-## The product loop
+[Latest full fleet run](https://github.com/MicroMilo/upstream-radar/actions/runs/32637649422):
+**96 executable catalog cells observed · 67 compatible · 29 need review · 0 reproduced incompatibilities · 4 source-only**.
+Review signals are never advertised as plugin failures.
 
-```mermaid
-flowchart TD
-  A["DSH plugin source or exact npm artifact"] --> B["Static review + DSH compatibility check"]
-  B --> C["Build the real plugin → dependency graph"]
-  C --> D["Monitor advisories, npm, DSH and Cordis changes"]
-  D --> E{"Meaningful affected change?"}
-  E -- "No" --> F["Update observation point and stay quiet"]
-  E -- "Yes" --> G["Calculate exact old → new impact paths"]
-  G --> H["Send bounded evidence to the DSH Agent"]
-  H --> I["Return a repairable action to the plugin author"]
-```
-
-This is the boundary: Radar decides **what changed and which exact path is involved**; DSH decides **what that means for the project**. A later website can visualize the saved graph, but the evidence and impact index are already useful without one.
-
-## The upstream/downstream alignment IR
+## Why it exists
 
-Every observer snapshot now carries a small, machine-readable alignment record:
+A healthy repository does not prove that its published plugin still works.
+The artifact users install must resolve against a specific DSH host, Node
+runtime, profile, and dependency set—and any of them can change overnight.
 
-```text
-upstream:   Git commit + package.json coordinate
-downstream: npm coordinate + lockfile graph root + graph coverage
-result:     aligned | mismatch | unknown
-```
-
-This catches a class of problems that a vulnerability scanner cannot: the source
-package, published package, and dependency graph may no longer describe the
-same thing. For example, the public DSH/Feishu target currently reports:
-
-```text
-source:    dsh-lark-bot@0.15.8
-published: dsh-feishu-bot@0.15.8
-graph root: dsh-lark-bot@0.15.8
-result:    mismatch
-```
-
-That is not a claim of malware or runtime incompatibility. It is an evidence
-gap: Radar cannot safely say that the source it watched produced the artifact
-users install. The IR is stored in `observations.json`, rendered in the first
-baseline report, and defined in [`schemas/upstream-downstream-ir.schema.json`](schemas/upstream-downstream-ir.schema.json).
-
-## Try it in 60 seconds
-
-```bash
-# No DSH profile, API key, or network state required
-npx --yes upstream-radar@0.40.0 demo
-
-# Scan a public DSH plugin repository without installing it
-npx --yes upstream-radar@0.40.0 scan \
-  https://github.com/PlutoKeating/dsh-lark-bot \
-  --fail-on never
-
-# Review a real browser plugin users would install, then check two DSH releases
-npx --yes upstream-radar@0.40.0 review dsh-plugin dsh-cloudflare-browser-run@0.1.1 \
-  --dsh-version 0.1.0-rc.6,0.1.0-rc.7
-```
+Upstream Radar checks the relationship, not just the two repositories. A local
+pre-publish check asks, “does this plugin pass today?” Radar asks, “which
+maintained plugins stopped passing after the ecosystem changed?”
 
-The important output is evidence, not a green badge: exact package identity, dependency paths, unresolved edges, install-time scripts, npm integrity/signature/provenance, advisory matches, and DSH load results.
+## The loop
 
-## The isolated execution lane
-
-Static metadata tells us that a lifecycle script exists; it cannot tell us what
-actually ran. The new [`dsh-install` workflow](.github/workflows/observe-dsh-plugin-install.yml)
-therefore uses a separate, deliberately untrusted lane:
-
-```text
-fresh GitHub-hosted VM (no secrets, read-only repository token)
-  → restricted container (no host workspace or Docker socket)
-  → npm pack exact package@version with scripts disabled
-  → enforce the artifact's declared Node range before plugin code can run
-  → record the exact Node and pnpm runtime used by the check
-  → DSH installs that same tarball with only the declared dependency-build approvals
-  → strace records child processes, network destinations and file writes
-  → DSH loads the registered bundle under the same exact release
-  → bounded JSON report survives and a non-compatible pair fails the check
-  → the container and VM are discarded
-```
-
-Use **Actions → Observe one DSH plugin install** and supply one exact plugin and
-one exact DSH version. The CLI also exposes `probe dsh-install`, but it refuses
-to run unless both `--execute` and `UPSTREAM_RADAR_ISOLATED_RUNNER=1` are present;
-it is not intended as a normal laptop command.
-
-This lane is wired into the always-on observer. Radar now watches the official
-`@deepseek-ai/dsh` `next` release channel (current DSH releases are prereleases
-rather than npm `latest`). A new exact DSH publication fans out the
-[nine-plugin maintained corpus](examples/dsh/install-observer/targets.json), one
-fresh VM per plugin. Six of those targets come from an identity-checked,
-[commit-pinned `awesome-dsh-plugin` cohort](examples/dsh/awesome-observer/README.md);
-two additional catalog targets are source-only because their real distribution
-is GitHub rather than npm. A mapped plugin publication retests only that plugin. Unchanged
-evidence keeps `observations.json` byte-stable, persistent source/publish drift
-does not wake the Agent again, and the DSH Agent/API key never enters the execution job.
-Build-script approvals are exact package names stored in the maintained target
-and copied into every report; an absent list approves nothing.
-
-The first implementation is intentionally honest about its limit: a container
-shares the hosted VM's kernel, and same-container `strace` evidence is not
-tamper-proof against determined malicious code. The outer VM is disposable and
-secret-free; a Firecracker collector is the later high-assurance backend, not a
-claim made by this report. See the [execution boundary and result semantics](examples/dsh/install-observer/README.md)
-and [`dsh-install-observation.schema.json`](schemas/dsh-install-observation.schema.json).
-
-## What we have already found
-
-These are real, reproducible cases in this repository—not synthetic “vulnerable package” demos.
-
-| Case | Finding | Why it matters |
-| --- | --- | --- |
-| [Live DSH `0.1.1-rc.1` isolated matrix](examples/dsh/install-observer/reports/2026-08-21-dsh-0.1.1-rc.1.md) | Eight exact artifacts install/register/load under their recorded contracts; OpenPencil is stopped before execution because it requires Node ≥24.11 while the isolated runner is Node 22.23; Better Sidebar passes only with its documented `node-pty` build approval and a real native toolchain | The imported awesome cohort found both a genuine runtime-pair incompatibility and a test-environment defect, while preserving the evidence that distinguishes them. |
-| [`dsh-cloudflare-browser-run@0.1.1`](examples/reports/dsh-cloudflare-browser-run-0.1.1.txt) | 18 resolved packages, 2 unresolved optional Cordis edges, 0 known vulnerabilities, and DSH rc.6/rc.7 both loaded the bundle | A real browser plugin demonstrates the DSH admission boundary and why incomplete edges stay visible. |
-| [50-plugin batch](examples/dsh/reports/dsh-batch-50-2026-08-17.md) / [real graph corpus](examples/dsh/first-batch/README.md) | 50 source scans, 30 exact npm reviews, 37 real plugin graphs indexed; 13 targets kept as missing evidence | The reverse index is now built from real DSH plugins, and missing graphs are not treated as clean. |
-| [`dsh-feishu-bot@0.15.8`](examples/dsh/reports/dsh-feishu-bot-0.15.8-review-2026-08-18.md) | 89-package graph, 12 unresolved optional edges, reachable `protobufjs` `postinstall`, DSH rc.6/rc.7 compatible | “No known CVE” is not the same as “no installation trust boundary.” |
-| [DSH-TUI source vs npm](examples/dsh/reports/dsh-tui-source-vs-npm-2026-08-18.md) | Source has `prepare`; published artifact does not | Source-only and artifact-only reviews answer different questions. |
-| [dsh-composer-expand](examples/dsh/reports/dsh-composer-expand-lockfile-feedback.md) | Committed lockfile root says `0.1.0` while source says `0.1.2` | A small author-fix can restore the identity of the monitored graph. |
-
-We report a confirmed vulnerability only when the affected exact version and runtime path are supported by the available evidence. Development-only hits, missing data, and advisory-source outages remain visibly different states.
-
-## Monitor the findings we already found
-
-The repository now has a focused watch for seven real DSH plugins from the first
-batch. It re-runs the source scan and the exact npm artifact review, then stores
-only trusted observations in [`state.json`](examples/dsh/finding-watch/state.json)
-and writes the current author-facing result to
-[`report.md`](examples/dsh/finding-watch/report.md).
-
-```bash
-pnpm run monitor:dsh-findings
-```
-
-The watch distinguishes `persisting`, `added`, `resolved`, `changed`, and
-`unknown`. A failed registry request never becomes “resolved”; a source fix also
-does not erase a finding that remains in the published npm artifact. The same
-loop runs daily in [the dedicated GitHub Actions workflow](.github/workflows/dsh-finding-watch.yml)
-and commits the state only when a trusted observation changes. It does not install
-plugins, execute lifecycle scripts, load DSH, or call an LLM.
-
-The current run is already useful: `dsh-msg-hub@0.1.8` has removed the old source
-lockfile findings, but its npm artifact still reaches `protobufjs@7.6.5` with a
-`postinstall`; `dsh-wsl-workspace` now resolves `koffi@3.1.6`, while the native
-install step remains. The other reviewed install/lifecycle findings persist.
-
-## The dependency graph behind every alert
-
-```text
-plugin@1.0.0
-├── framework@2.4.7
-│   ├── parser@3.2.1
-│   └── archive@1.8.0
-└── logger@4.0.2
-    └── parser@2.9.0  ← the affected physical node
-```
-
-Two copies of `parser` are different nodes. An alert names the exact version and path that entered the DSH profile; it does not page every plugin that happens to use the same package name.
-
-For a collection of saved reports, build the reverse index that turns an upstream package update into affected plugins:
-
-```bash
-npx --yes upstream-radar@0.40.0 graph reverse ./reports \
-  --output reverse-dependency-index.json
-
-# Ask: which plugins currently depend on this exact package?
-npx --yes upstream-radar@0.40.0 graph reverse ./reports \
-  --package parser@2.9.0
-
-# Rebuild the checked-in index from the real first 50 DSH plugin reports
-pnpm run refresh:dsh-batch
-```
-
-The generated JSON preserves exact paths such as:
-
-```text
-plugin@1.0.0 → logger@4.0.2 → parser@2.9.0
-```
-
-It also preserves whether the graph is complete or has unresolved optional/peer edges. A later website can visualize this index; the index and evidence remain the product foundation.
-
-To route an upstream old → new change to that index, pass it to the always-on
-observer:
-
-```bash
-npx --yes upstream-radar@0.40.0 observe ./targets.yml \
-  --reverse-index ./reverse-dependency-index.json \
-  --state ./observations.json \
-  --report ./upstream-radar-observer.md
+```mermaid
+flowchart TB
+  Schedule["Scheduled GitHub Action"] --> Watch["Watch DSH + plugin releases"]
+  Watch --> Matrix["Exact plugin × DSH matrix"]
+  Matrix --> Static["Static contract checks"]
+  Matrix --> Runtime["Disposable runner: install → register → load"]
+  Static --> Evidence["Reproducible compatibility evidence"]
+  Runtime --> Evidence
+  Evidence --> Issue["One fixable issue"]
+  Issue --> Fix["Author publishes a fix"]
+  Fix --> Watch
 ```
 
-The observer matches by package name, not only by the new exact version. If
-`parser@1.0.0` becomes `parser@2.0.0` upstream while a downstream plugin still
-uses `parser@1.0.0`, the report names that plugin and its path as a possible
-impact. `complete` or `incomplete` coverage stays attached to the result; this
-is an evidence-based routing signal, not a claim that the plugin is already
-broken. See the persisted index definition in
-[`schemas/reverse-dependency-index.schema.json`](schemas/reverse-dependency-index.schema.json).
+Radar establishes the result with deterministic evidence. An optional DSH
+Agent can explain impact and suggest the next action, but a model never turns
+missing evidence into a pass.
 
-The checked-in real-corpus replay makes this concrete: an observed
-`@deepseek-ai/cordis@4.0.1 → 4.0.2` change routes to 17 DSH plugins from the
-first 50-plugin batch. The route is marked `incomplete` because 26 of the 37
-reconstructed graphs contain unresolved edges; the other 13 targets are kept
-outside the index as missing evidence. Run `pnpm run showcase:observer` to
-replay baseline → one Agent task → quiet run without network access.
+## What you get
 
-## GitHub Action
+- An exact result for `plugin version × DSH version × Node/profile`, not a
+  timeless “compatible” badge.
+- Static dependency and peer-contract checks joined with real
+  install/register/load evidence from the published artifact.
+- A maintained result that is retested when DSH or the plugin changes.
+- One managed issue that is updated on repeat failures, reopened on regression,
+  and closed after a clean retest.
 
-The repository already contains a reusable, composite Action in [`action.yml`](action.yml). It runs the same frozen Radar check in CI and writes a short Job Summary.
+## Upstream reports now closed
 
-```yaml
-- uses: MicroMilo/upstream-radar@v0.40.0
-  with:
-    config: upstream-radar.config.json
-    fail-on: high
-```
-
-See the [consumer workflow](examples/github-actions/consumer/README.md) for config and lockfile examples. The GitHub Marketplace prompt is a distribution opportunity, not a separate scanning engine: the Action listing should follow a reviewed stable release, while exact tags remain copyable and auditable.
+We opened the following reports; their upstream maintainers have now closed
+them:
 
-## What it does—and does not do
+- [Sanqi-normal/dsh-webui-market-plugin#5](https://github.com/Sanqi-normal/dsh-webui-market-plugin/issues/5)
+- [1na-ko/dsh-hdc-bridge#3](https://github.com/1na-ko/dsh-hdc-bridge/issues/3)
+- [6Mikao9/dsh-wsl-workspace#6](https://github.com/6Mikao9/dsh-wsl-workspace/issues/6)
+- [3274375092/dsh-voice#2](https://github.com/3274375092/dsh-voice/issues/2)
 
-| It does | It does not claim |
-| --- | --- |
-| Reconstruct exact npm/pnpm dependency paths | An empty finding list is a safety certificate |
-| Query OSV and GitHub Advisory evidence for exact versions | A missing provenance statement proves maliciousness |
-| Compare source and published artifact evidence | Static review replaces runtime evidence |
-| Observe exact install/load behavior in a disposable VM and restricted container | One observed run proves adversarial code is safe |
-| Check DSH bundle/profile compatibility without business actions | “Compatible” means the plugin is secure |
-| Monitor old → new upstream observations | An LLM can repair evidence that was never collected |
-
-## Install and connect to DSH
+## Run one check
 
 ```bash
-pnpm add upstream-radar
-
-# Generate a reviewable DSH profile inventory from the installed profile
-npx --yes upstream-radar@0.40.0 setup
+npx --yes upstream-radar@0.42.0 review dsh-plugin \
+  <package>@<version> \
+  --dsh-version <dsh-version>
 ```
 
-For Feishu/webhook routing, DSH Agent handoff, observer state, report schemas, and troubleshooting, use the [full Chinese guide](docs/README.zh-CN.md). The [architecture notes](docs/architecture.md) explain the boundaries and evidence model.
+For code-executing checks, use the maintained
+[isolated observer workflow](.github/workflows/observe-dsh-plugin-install.yml):
+each pair receives a fresh, secret-free GitHub-hosted VM and restricted
+container.
 
-## Development
-
-```bash
-pnpm install
-pnpm test
-pnpm run release:check
-```
+Inspect the [live compatibility matrix](examples/dsh/install-observer/README.md),
+the [directory-consumable evidence feed](feeds/dsh-plugin-compatibility.md),
+the [first 50-plugin corpus](examples/dsh/first-batch/README.md), or the
+[architecture notes](docs/architecture.md).
 
-The project is Apache-2.0 licensed. Contributions that improve a real DSH plugin report, dependency resolution, advisory matching, or reproducible author feedback are especially welcome.
+<p align="center">
+  <strong>If Upstream Radar helps the DSH ecosystem stay compatible, <a href="https://github.com/MicroMilo/upstream-radar">please give it a Star</a> ⭐</strong>
+</p>

package/README.zh-CN.md

@@ -0,0 +1,89 @@
+<h1 align="center">Upstream Radar</h1>
+
+<p align="center"><strong>每次 DeepSeek Harness 发布后，在用户踩坑前找出哪些插件坏了。</strong></p>
+
+<p align="center">
+  <a href="README.md">English</a> · 简体中文
+</p>
+
+<p align="center">
+  <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 持续把一批真实插件发布物放到一次性隔离环境中，与不断变化的
+[DeepSeek Harness（DSH）](https://github.com/deepseek-ai/deepseek-harness)
+版本重新配对测试。某个组合坏了，就生成一条可复现的 Issue；作者发布修复后，
+Radar 会再次检查并关闭闭环。
+
+**维护 100 个安装/加载目标 · 覆盖目录全部 21 个类别 · 4 条上游报告已关闭**
+
+[最近一次全量运行](https://github.com/MicroMilo/upstream-radar/actions/runs/32637649422)：
+**观测 96 个可执行目录插件 · 67 个兼容 · 29 个需要复核 · 0 个复现不兼容 · 4 个仅源码目标**。
+需要复核的信号不会被宣传成插件故障。
+
+## 为什么需要它
+
+仓库看起来正常，不代表用户实际安装的插件仍然可用。真实发布物必须同时适配某个
+DSH 版本、Node 运行时、profile 和依赖组合；其中任何一项更新，都可能让插件一夜
+之间失效。
+
+Upstream Radar 检查的是这层真实关系，而不只是分别看两个仓库。本地发布前检查
+回答“这个插件今天能不能过”；Radar 回答“生态变化后，维护中的哪些插件不再能过”。
+
+## 完整闭环
+
+```mermaid
+flowchart TB
+  Schedule["定时 GitHub Action"] --> Watch["观察 DSH 与插件发布"]
+  Watch --> Matrix["精确的插件 × DSH 测试矩阵"]
+  Matrix --> Static["静态契约检查"]
+  Matrix --> Runtime["一次性环境：安装 → 注册 → 加载"]
+  Static --> Evidence["可复现的兼容性证据"]
+  Runtime --> Evidence
+  Evidence --> Issue["一条可修复的 Issue"]
+  Issue --> Fix["作者发布修复"]
+  Fix --> Watch
+```
+
+Radar 用确定性证据得出结果。DSH Agent 可以补充影响解释和下一步建议，但模型不能
+把缺失的证据说成通过。
+
+## 你会得到什么
+
+- `插件版本 × DSH 版本 × Node/profile` 的精确结果，而不是永不过期的“兼容”标签。
+- 把静态依赖和 peer 契约，与真实发布物的安装、注册、加载结果放在一起判断。
+- DSH 或插件变化后自动重新检查，而不是只生成一次报告。
+- 同一问题持续更新；回归时重新打开；干净复测通过后自动关闭。
+
+## 已关闭的上游报告
+
+以下报告由我们提出，目前均已被对应上游维护者关闭：
+
+- [Sanqi-normal/dsh-webui-market-plugin#5](https://github.com/Sanqi-normal/dsh-webui-market-plugin/issues/5)
+- [1na-ko/dsh-hdc-bridge#3](https://github.com/1na-ko/dsh-hdc-bridge/issues/3)
+- [6Mikao9/dsh-wsl-workspace#6](https://github.com/6Mikao9/dsh-wsl-workspace/issues/6)
+- [3274375092/dsh-voice#2](https://github.com/3274375092/dsh-voice/issues/2)
+
+## 检查一个插件
+
+```bash
+npx --yes upstream-radar@0.42.0 review dsh-plugin \
+  <包名>@<版本> \
+  --dsh-version <DSH版本>
+```
+
+需要执行插件代码时，请使用仓库维护的
+[隔离观察工作流](.github/workflows/observe-dsh-plugin-install.yml)：每个组合都会获得
+一台全新的、无密钥的 GitHub 托管虚拟机和受限容器。
+
+你还可以查看[实时兼容性矩阵](examples/dsh/install-observer/README.md)、
+[可供目录消费的兼容性结果](feeds/dsh-plugin-compatibility.md)、
+[第一批 50 个插件](examples/dsh/first-batch/README.md)和
+[架构说明](docs/architecture.md)。
+
+<p align="center">
+  <strong>如果 Upstream Radar 对 DSH 生态有帮助，欢迎<a href="https://github.com/MicroMilo/upstream-radar">点一个 Star</a> ⭐</strong>
+</p>

package/dist/src/cli.js

@@ -477,7 +477,7 @@ Usage:
   upstream-radar profile-check [profile-directory] [--patch <path>] [--report <path>] [--summary] [--json]
   upstream-radar probe dsh-load <package.tgz> [--dsh-version <exact-version>] [--timeout <seconds>] [--keep-profile] [--json]
   upstream-radar probe dsh-matrix <package.tgz> --dsh-version <v1>[,<v2>,...] [--timeout <seconds>] [--keep-profile] [--json]
-  upstream-radar probe dsh-install [npm:]<package>@<exact-version> --dsh-version <exact-version> --isolation-provider <github-actions-hosted-runner|firecracker|other> --execute [--allow-build <package>]... [--timeout <seconds>] [--report <report.json>] [--json]
+  upstream-radar probe dsh-install [npm:]<package>@<exact-version> --dsh-version <exact-version> [--case-id <stable-label>] --isolation-provider <github-actions-hosted-runner|firecracker|other> --execute [--allow-build <package>]... [--timeout <seconds>] [--report <report.json>] [--json]
   upstream-radar review dsh-plugin [npm:]<package>@<exact-version> --dsh-version <v1>,<v2>,... [--json]
   upstream-radar demo [--json]
   upstream-radar case dsh-web-ui [--json]
@@ -1284,6 +1284,7 @@ async function runDshInstallObservation(args) {
         throw new Error('probe dsh-install requires an exact npm package');
     }
     let dshVersion;
+    let caseId;
     let isolationProvider;
     let timeoutSeconds = 180;
     let reportPath;
@@ -1298,7 +1299,7 @@ async function runDshInstallObservation(args) {
         else if (argument === '--json') {
             json = true;
         }
-        else if (argument === '--dsh-version' || argument === '--isolation-provider' || argument === '--allow-build' || argument === '--timeout' || argument === '--report') {
+        else if (argument === '--dsh-version' || argument === '--case-id' || argument === '--isolation-provider' || argument === '--allow-build' || argument === '--timeout' || argument === '--report') {
             const value = args[index + 1];
             if (value === undefined || value.startsWith('-'))
                 throw new Error(`${argument} requires a value`);
@@ -1307,6 +1308,13 @@ async function runDshInstallObservation(args) {
                     throw new Error('probe dsh-install accepts only one --dsh-version');
                 dshVersion = value;
             }
+            else if (argument === '--case-id') {
+                if (caseId !== undefined)
+                    throw new Error('probe dsh-install accepts only one --case-id');
+                if (!/^[a-z0-9][a-z0-9._-]{0,63}$/.test(value))
+                    throw new Error('--case-id must be a short lowercase label');
+                caseId = value;
+            }
             else if (argument === '--isolation-provider') {
                 if (value !== 'github-actions-hosted-runner' && value !== 'firecracker' && value !== 'other') {
                     throw new Error('--isolation-provider must be github-actions-hosted-runner, firecracker or other');
@@ -1344,6 +1352,7 @@ async function runDshInstallObservation(args) {
     const report = await observeDshPluginInstall({
         packageSpec,
         dshVersion,
+        ...(caseId === undefined ? {} : { caseId }),
         allowExecution: true,
         isolationProvider,
         allowedBuilds,