upstream-radar 0.33.9 → 0.33.10

package/README.md

@@ -91,7 +91,7 @@ The useful part is the exact path and project-specific next step—not another g
 Want to try it on a real published DSH plugin immediately?
 
 ```bash
-npx --yes upstream-radar@0.33.9 inspect dsh-feishu-bot@0.15.4 --deep
+npx --yes upstream-radar@0.33.10 inspect dsh-feishu-bot@0.15.4 --deep
 ```
 
 This runs from an otherwise empty directory and returns a short admission,
@@ -101,7 +101,7 @@ Want to see a real author-actionable result? This exact published DSH plugin
 currently cannot produce a complete dependency graph in a clean npm resolver:
 
 ```bash
-npx --yes upstream-radar@0.33.9 inspect \
+npx --yes upstream-radar@0.33.10 inspect \
   @sanqi-normal/dsh-webui-market-plugin@0.5.4 \
   --deep --fail-on never
 ```
@@ -311,7 +311,7 @@ uses the real committed graph. Add `--package-path` for a nested plugin,
 `--lockfile` when you want to choose a particular lockfile:
 
 ```bash
-npx --yes upstream-radar@0.33.9 observe \
+npx --yes upstream-radar@0.33.10 observe \
   https://github.com/PlutoKeating/dsh-lark-bot \
   --state ./observations.json --report ./upstream-radar-observer.md
 ```
@@ -321,7 +321,7 @@ manifest is `dsh-lark-bot`, while its published npm package is
 `dsh-feishu-bot`:
 
 ```bash
-npx --yes upstream-radar@0.33.9 observe \
+npx --yes upstream-radar@0.33.10 observe \
   https://github.com/PlutoKeating/dsh-lark-bot \
   --package dsh-feishu-bot \
   --lockfile pnpm-lock.yaml --lockfile-type pnpm \
@@ -332,7 +332,7 @@ Then run one cycle:
 
 ```bash
 export GITHUB_TOKEN='a read-only GitHub token'
-npx --yes upstream-radar@0.33.9 observe \
+npx --yes upstream-radar@0.33.10 observe \
   ./targets.yml \
   --state ./observations.json \
   --report ./upstream-radar-observer.md
@@ -377,6 +377,10 @@ The checked-in workflow is a dogfood workflow for this repository: it checks out
 and builds Radar before running the observer. It persists only the observation
 point. A quiet run does not create a daily commit.
 
+For the shortest copy-paste setup, use the [minimal one-repository workflow](examples/github-actions/upstream-observer-minimal.yml).
+It uses the published npm CLI, needs no Radar checkout or build, and only asks
+you to change the repository URL (or enter one through `workflow_dispatch`).
+
 The workflow also supports three optional repository secrets—
 `ISSUE_LOCATOR_LLM_BASE_URL`, `ISSUE_LOCATOR_LLM_API_KEY`, and
 `ISSUE_LOCATOR_LLM_MODEL`. When all three exist, the job sends meaningful tasks
@@ -581,7 +585,7 @@ cd my-dsh-plugin
 pnpm install --ignore-scripts
 
 # Read the exact graph before adding the plugin to a DSH profile.
-pnpm dlx --package=upstream-radar@0.33.9 upstream-radar graph pnpm-lock pnpm-lock.yaml --json
+pnpm dlx --package=upstream-radar@0.33.10 upstream-radar graph pnpm-lock pnpm-lock.yaml --json
 ```
 
 The graph includes the exact DSH package versions and keeps unresolved optional peers visible. It does not load the generated plugin or run lifecycle scripts. After reviewing it, copy this complete workflow into `.github/workflows/upstream-radar.yml`:
@@ -603,7 +607,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
-      - uses: MicroMilo/upstream-radar@v0.33.9
+      - uses: MicroMilo/upstream-radar@v0.33.10
         with:
           fail-on: high
           fail-on-compatibility: breaking
@@ -614,7 +618,7 @@ The Action auto-detects the one `pnpm-lock.yaml`, checks the same exact graph, a
 To check a real published DSH artifact directly, run one command:
 
 ```bash
-npx --yes upstream-radar@0.33.9 inspect dsh-feishu-bot@0.15.4 --deep
+npx --yes upstream-radar@0.33.10 inspect dsh-feishu-bot@0.15.4 --deep
 ```
 
 The checked result is `REVIEW`: registry integrity, signature, provenance, and
@@ -771,7 +775,7 @@ To see the two-source vulnerability contract without contacting the network, run
 Before wiring a project into a compatibility gate, run the offline rule benchmark:
 
 ```bash
-pnpm dlx --package=upstream-radar@0.33.9 upstream-radar benchmark compatibility
+pnpm dlx --package=upstream-radar@0.33.10 upstream-radar benchmark compatibility
 ```
 
 It covers six contracts: a safe patch, a change that only needs project analysis, an incompatible DSH peer, a publisher-declared breaking release, a vulnerable candidate dependency, and an incomplete candidate graph. The command does not access the network, install a package, load a plugin, or start DSH. It checks the behavior of Radar's deterministic rules and the `breaking`/`any` gates; it is not a runtime compatibility proof.
@@ -784,7 +788,7 @@ When you have an exact plugin artifact and want to know whether one exact DSH re
 # Pack an exact npm release without running its lifecycle scripts.
 npm pack --ignore-scripts dsh-plugin@1.2.3
 
-pnpm dlx --package=upstream-radar@0.33.9 upstream-radar probe dsh-load \
+pnpm dlx --package=upstream-radar@0.33.10 upstream-radar probe dsh-load \
   ./dsh-plugin-1.2.3.tgz \
   --dsh-version 0.1.0-rc.6
 ```
@@ -810,7 +814,7 @@ It exercises a loadable bundle, a bundle patch DSH rejects, and a package that r
 To compare a plugin against more than one DSH release, use the matrix form:
 
 ```bash
-pnpm dlx --package=upstream-radar@0.33.9 upstream-radar probe dsh-matrix \
+pnpm dlx --package=upstream-radar@0.33.10 upstream-radar probe dsh-matrix \
   ./dsh-plugin-1.2.3.tgz \
   --dsh-version 0.1.0-rc.3 \
   --dsh-version 0.1.0-rc.6 \
@@ -826,7 +830,7 @@ If your team wants the shortest scheduled CI gate before wiring a machine to a l
 ```yaml
 steps:
   - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
-  - uses: MicroMilo/upstream-radar@v0.33.9
+  - uses: MicroMilo/upstream-radar@v0.33.10
     with:
       fail-on: high
       # Optional: also fail on deterministic DSH/plugin compatibility breaks.
@@ -835,12 +839,12 @@ steps:
       threat-intel: true
 ```
 
-The Action is a thin wrapper around `radar check --frozen --state :memory: --fail-on high --json`; when the optional compatibility input is enabled, it also passes `--fail-on-compatibility breaking` or `any`. `--frozen` is deliberate: it uses the graph in the reviewed config and does not try to read a developer's local DSH profile. `threat-intel` is false by default so an ordinary CI gate stays lean; set it to `true` when the Job Summary and raw JSON should include CISA KEV and FIRST EPSS prioritization evidence. Each run is independent, exits `2` when an active vulnerability or opted-in compatibility change meets its threshold, and exits `1` for an operational or source error. `breaking` catches confirmed or strong incompatibility signals; `any` catches every active compatibility event. The default is `never`, so vulnerability-only behavior stays unchanged. In addition to the raw JSON log, the Action writes a short escaped summary to the GitHub Job Summary so a scheduled failure immediately shows the affected package, exact path, published fix version when available, one-line priority evidence, and a suggested next step. The Action does not deliver a DSH Agent task or modify a branch; the native DSH bundle remains the always-on analysis path. Pin the Action to a release tag such as `v0.33.9`, and pin the checkout Action in your workflow according to your repository's policy.
+The Action is a thin wrapper around `radar check --frozen --state :memory: --fail-on high --json`; when the optional compatibility input is enabled, it also passes `--fail-on-compatibility breaking` or `any`. `--frozen` is deliberate: it uses the graph in the reviewed config and does not try to read a developer's local DSH profile. `threat-intel` is false by default so an ordinary CI gate stays lean; set it to `true` when the Job Summary and raw JSON should include CISA KEV and FIRST EPSS prioritization evidence. Each run is independent, exits `2` when an active vulnerability or opted-in compatibility change meets its threshold, and exits `1` for an operational or source error. `breaking` catches confirmed or strong incompatibility signals; `any` catches every active compatibility event. The default is `never`, so vulnerability-only behavior stays unchanged. In addition to the raw JSON log, the Action writes a short escaped summary to the GitHub Job Summary so a scheduled failure immediately shows the affected package, exact path, published fix version when available, one-line priority evidence, and a suggested next step. The Action does not deliver a DSH Agent task or modify a branch; the native DSH bundle remains the always-on analysis path. Pin the Action to a release tag such as `v0.33.10`, and pin the checkout Action in your workflow according to your repository's policy.
 
 If the repository has no committed Radar config yet, the smallest setup is to omit `config`, `pnpm-lock`, and `npm-lock`. After checkout, the Action automatically uses the only one of `pnpm-lock.yaml` or `package-lock.json` that exists, generates a temporary reviewed config, and runs the same frozen check:
 
 ```yaml
-- uses: MicroMilo/upstream-radar@v0.33.9
+- uses: MicroMilo/upstream-radar@v0.33.10
   with:
     fail-on: high
 ```
@@ -850,7 +854,7 @@ An existing `config` wins over auto-detection. If both lockfiles exist, or neith
 To review the exact plugin artifact before it enters DSH, add `inspect-package`:
 
 ```yaml
-- uses: MicroMilo/upstream-radar@v0.33.9
+- uses: MicroMilo/upstream-radar@v0.33.10
   with:
     inspect-package: dsh-cloudflare-browser-run@0.1.1
     # review is the safe default; use block only when incomplete coverage may pass.
@@ -862,7 +866,7 @@ This downloads that exact npm tarball, verifies the registry integrity/signature
 If the repository has a pnpm lockfile but no committed Radar config yet, the Action can generate the config in the same job. See the [copyable pnpm workflow](examples/github-actions/upstream-radar-pnpm.yml):
 
 ```yaml
-- uses: MicroMilo/upstream-radar@v0.33.9
+- uses: MicroMilo/upstream-radar@v0.33.10
   with:
     pnpm-lock: pnpm-lock.yaml
     fail-on: high
@@ -876,7 +880,7 @@ See the [copyable npm workflow](examples/github-actions/upstream-radar-npm.yml)
 The Action requires the caller to check out the repository first. It does not install the project's dependencies or run their lifecycle scripts; it only reads the committed graph and queries the configured upstream sources. For a fully explicit, lower-level invocation, the equivalent command is:
 
 ```bash
-pnpm dlx --package=upstream-radar@0.33.9 upstream-radar radar check \
+pnpm dlx --package=upstream-radar@0.33.10 upstream-radar radar check \
   ./upstream-radar.config.json --frozen --state :memory: --fail-on high \
   --fail-on-compatibility breaking --json
 ```
@@ -884,7 +888,7 @@ pnpm dlx --package=upstream-radar@0.33.9 upstream-radar radar check \
 To add the optional DSH load matrix for a published plugin, provide an exact npm package and at least two exact DSH versions:
 
 ```yaml
-- uses: MicroMilo/upstream-radar@v0.33.9
+- uses: MicroMilo/upstream-radar@v0.33.10
   id: radar
   with:
     config: upstream-radar.config.json

package/dist/src/version.d.ts

@@ -1,2 +1,2 @@
-export declare const TOOL_VERSION = "0.33.9";
+export declare const TOOL_VERSION = "0.33.10";
 //# sourceMappingURL=version.d.ts.map

package/dist/src/version.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"version.d.ts","sourceRoot":"","sources":["../../src/version.ts"],"names":[],"mappings":"AAAA,eAAO,MAAM,YAAY,WAAW,CAAA"}
+{"version":3,"file":"version.d.ts","sourceRoot":"","sources":["../../src/version.ts"],"names":[],"mappings":"AAAA,eAAO,MAAM,YAAY,YAAY,CAAA"}

package/dist/src/version.js

@@ -1,2 +1,2 @@
-export const TOOL_VERSION = '0.33.9';
+export const TOOL_VERSION = '0.33.10';
 //# sourceMappingURL=version.js.map

package/dist/src/version.js.map

@@ -1 +1 @@
-{"version":3,"file":"version.js","sourceRoot":"","sources":["../../src/version.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,YAAY,GAAG,QAAQ,CAAA"}
+{"version":3,"file":"version.js","sourceRoot":"","sources":["../../src/version.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,YAAY,GAAG,SAAS,CAAA"}

package/docs/README.zh-CN.md

@@ -85,7 +85,7 @@ FIRST EPSS estimated exploitation probability: 97.2% (percentile 100.0%)
 想立即检查一个真实发布的 DSH 插件，可以在空目录直接运行：
 
 ```bash
-npx --yes upstream-radar@0.33.9 inspect dsh-feishu-bot@0.15.4 --deep
+npx --yes upstream-radar@0.33.10 inspect dsh-feishu-bot@0.15.4 --deep
 ```
 
 它会直接输出简短的准入结论、覆盖情况、依赖数量、漏洞数量和下一步，不需要先
@@ -95,7 +95,7 @@ npx --yes upstream-radar@0.33.9 inspect dsh-feishu-bot@0.15.4 --deep
 npm 解析环境中目前无法建立完整依赖图：
 
 ```bash
-npx --yes upstream-radar@0.33.9 inspect \
+npx --yes upstream-radar@0.33.10 inspect \
   @sanqi-normal/dsh-webui-market-plugin@0.5.4 \
   --deep --fail-on never
 ```
@@ -279,7 +279,7 @@ targets:
 再加 `--lockfile`：
 
 ```bash
-npx --yes upstream-radar@0.33.9 observe \
+npx --yes upstream-radar@0.33.10 observe \
   https://github.com/PlutoKeating/dsh-lark-bot \
   --state ./observations.json --report ./upstream-radar-observer.md
 ```
@@ -288,7 +288,7 @@ npx --yes upstream-radar@0.33.9 observe \
 会额外指定 `--package`：
 
 ```bash
-npx --yes upstream-radar@0.33.9 observe \
+npx --yes upstream-radar@0.33.10 observe \
   https://github.com/PlutoKeating/dsh-lark-bot \
   --package dsh-feishu-bot \
   --lockfile pnpm-lock.yaml --lockfile-type pnpm \
@@ -347,6 +347,10 @@ Radar 只读取这次调用需要的接口地址、API key 和模型名，不会
 仓库里这份 workflow 会先 checkout 并构建 Radar，再观察这个公开的 DSH/飞书插件，
 所以既是 dogfood 也是一个真实插件示例。它只提交观察点；没有变化时不会每天制造一条 commit。
 
+如果想要最短的复制路径，使用[单仓库最小 workflow](../examples/github-actions/upstream-observer-minimal.yml)。
+它直接使用已发布的 npm CLI，不需要 checkout 或构建 Radar；只需修改仓库 URL，或者在
+`workflow_dispatch` 时填写 URL。
+
 这个 workflow 支持三个可选的 repository secret：
 `ISSUE_LOCATOR_LLM_BASE_URL`、`ISSUE_LOCATOR_LLM_API_KEY` 和
 `ISSUE_LOCATOR_LLM_MODEL`。三个值都有时，重要变化会交给 issue-locator/OpenAI 兼容
@@ -548,7 +552,7 @@ cd my-dsh-plugin
 pnpm install --ignore-scripts
 
 # 把插件放进 DSH profile 前，先读取精确依赖图。
-pnpm dlx --package=upstream-radar@0.33.9 upstream-radar graph pnpm-lock pnpm-lock.yaml --json
+pnpm dlx --package=upstream-radar@0.33.10 upstream-radar graph pnpm-lock pnpm-lock.yaml --json
 ```
 
 这棵图会保留精确的 DSH 包版本，也会把未解析的可选 peer 明确显示出来；它不会加载生成的插件，也不会运行 lifecycle script。审查后，把下面这个完整 workflow 复制到 `.github/workflows/upstream-radar.yml`：
@@ -570,7 +574,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
-      - uses: MicroMilo/upstream-radar@v0.33.9
+      - uses: MicroMilo/upstream-radar@v0.33.10
         with:
           fail-on: high
           fail-on-compatibility: breaking
@@ -581,7 +585,7 @@ Action 会自动识别唯一的 `pnpm-lock.yaml`，检查同一棵精确依赖
 也可以直接检查一个真实发布的 DSH 包：
 
 ```bash
-npx --yes upstream-radar@0.33.9 inspect dsh-feishu-bot@0.15.4 --deep
+npx --yes upstream-radar@0.33.10 inspect dsh-feishu-bot@0.15.4 --deep
 ```
 
 这次检查的结论是 `REVIEW`：registry 完整性、签名、provenance 和 89 个已解析包都
@@ -747,7 +751,7 @@ pnpm run try:dsh
 在把项目接入兼容性门禁前，可以先运行离线规则 benchmark：
 
 ```bash
-pnpm dlx --package=upstream-radar@0.33.9 upstream-radar benchmark compatibility
+pnpm dlx --package=upstream-radar@0.33.10 upstream-radar benchmark compatibility
 ```
 
 它覆盖六类契约：安全补丁、只需要项目分析的变化、不兼容的 DSH peer、发布者明确声明 breaking、候选传递依赖漏洞，以及候选依赖图不完整。这个命令不会联网、安装包、加载插件或启动 DSH；它验证的是 Radar 的确定性规则以及 `breaking`/`any` 门禁行为，不是运行时兼容性证明。
@@ -760,7 +764,7 @@ pnpm dlx --package=upstream-radar@0.33.9 upstream-radar benchmark compatibility
 # 打包精确版本，并明确不运行它的 lifecycle script。
 npm pack --ignore-scripts dsh-plugin@1.2.3
 
-pnpm dlx --package=upstream-radar@0.33.9 upstream-radar probe dsh-load \
+pnpm dlx --package=upstream-radar@0.33.10 upstream-radar probe dsh-load \
   ./dsh-plugin-1.2.3.tgz \
   --dsh-version 0.1.0-rc.6
 ```
@@ -786,7 +790,7 @@ pnpm run showcase:dsh-probe
 如果要比较多个 DSH 版本，可以使用矩阵入口：
 
 ```bash
-pnpm dlx --package=upstream-radar@0.33.9 upstream-radar probe dsh-matrix \
+pnpm dlx --package=upstream-radar@0.33.10 upstream-radar probe dsh-matrix \
   ./dsh-plugin-1.2.3.tgz \
   --dsh-version 0.1.0-rc.3 \
   --dsh-version 0.1.0-rc.6 \
@@ -804,7 +808,7 @@ JSON 结果结构见[矩阵结果 schema](../schemas/dsh-load-matrix.schema.json
 ```yaml
 steps:
   - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
-  - uses: MicroMilo/upstream-radar@v0.33.9
+  - uses: MicroMilo/upstream-radar@v0.33.10
     with:
       fail-on: high
       # 可选：把确定性的 DSH/插件兼容性破坏也作为 CI 失败条件
@@ -813,12 +817,12 @@ steps:
       threat-intel: true
 ```
 
-这个 Action 只是 `radar check --frozen --state :memory: --fail-on high --fail-on-compatibility breaking --json` 的薄封装。`--frozen` 是有意的：它只使用配置文件里的依赖图，不会尝试读取 runner 上不存在的本地 DSH profile。`threat-intel` 默认是 `false`，这样普通 CI 门禁不会因为额外查询变重；设置为 `true` 后，Job Summary 和原始 JSON 会包含 CISA KEV 与 FIRST EPSS 的优先级证据。每次运行彼此独立；发现达到阈值的漏洞或选择的兼容性变化时返回 `2`，运行或漏洞源出错时返回 `1`。`breaking` 只拦截有 confirmed/strong 信号的兼容性事件，`any` 会拦截所有活动兼容性事件，默认值是 `never`。除了原始 JSON 日志，Action 还会把经过转义的简短摘要写入 GitHub Job Summary，定时任务失败时可以直接看到受影响的包、准确依赖路径、已经发布的修复版本（如果有）、一行优先级证据和建议的下一步。这个入口不会投递 DSH Agent 任务，也不会修改分支；需要持续监控和项目级分析时，仍使用原生 DSH bundle。建议把 Action 固定到类似 `v0.33.9` 的发布标签，并根据团队策略固定 checkout Action。
+这个 Action 只是 `radar check --frozen --state :memory: --fail-on high --fail-on-compatibility breaking --json` 的薄封装。`--frozen` 是有意的：它只使用配置文件里的依赖图，不会尝试读取 runner 上不存在的本地 DSH profile。`threat-intel` 默认是 `false`，这样普通 CI 门禁不会因为额外查询变重；设置为 `true` 后，Job Summary 和原始 JSON 会包含 CISA KEV 与 FIRST EPSS 的优先级证据。每次运行彼此独立；发现达到阈值的漏洞或选择的兼容性变化时返回 `2`，运行或漏洞源出错时返回 `1`。`breaking` 只拦截有 confirmed/strong 信号的兼容性事件，`any` 会拦截所有活动兼容性事件，默认值是 `never`。除了原始 JSON 日志，Action 还会把经过转义的简短摘要写入 GitHub Job Summary，定时任务失败时可以直接看到受影响的包、准确依赖路径、已经发布的修复版本（如果有）、一行优先级证据和建议的下一步。这个入口不会投递 DSH Agent 任务，也不会修改分支；需要持续监控和项目级分析时，仍使用原生 DSH bundle。建议把 Action 固定到类似 `v0.33.10` 的发布标签，并根据团队策略固定 checkout Action。
 
 如果仓库还没有提交 Radar 配置，最短接入方式是省略 `config`、`pnpm-lock` 和 `npm-lock`。checkout 之后，Action 会自动使用唯一存在的 `pnpm-lock.yaml` 或 `package-lock.json`，生成临时的审查清单，再执行同一个 frozen 检查：
 
 ```yaml
-- uses: MicroMilo/upstream-radar@v0.33.9
+- uses: MicroMilo/upstream-radar@v0.33.10
   with:
     fail-on: high
 ```
@@ -828,7 +832,7 @@ steps:
 如果要在插件进入 DSH 前审查精确发布物，可以增加 `inspect-package`：
 
 ```yaml
-- uses: MicroMilo/upstream-radar@v0.33.9
+- uses: MicroMilo/upstream-radar@v0.33.10
   with:
     inspect-package: dsh-cloudflare-browser-run@0.1.1
     # review 是安全默认值；只有允许覆盖不完整时才使用 block
@@ -840,7 +844,7 @@ steps:
 如果仓库只有 pnpm 锁文件，还没有提交 Radar 配置，可以让 Action 在同一个 job 中生成配置；可直接复制[pnpm workflow 示例](../examples/github-actions/upstream-radar-pnpm.yml)：
 
 ```yaml
-- uses: MicroMilo/upstream-radar@v0.33.9
+- uses: MicroMilo/upstream-radar@v0.33.10
   with:
     pnpm-lock: pnpm-lock.yaml
     fail-on: high
@@ -854,7 +858,7 @@ npm 项目可以改用 `npm-lock: package-lock.json`；`pnpm-lock` 和 `npm-lock
 调用方需要先 checkout 仓库。这个 Action 不会安装项目依赖，也不会执行项目的 lifecycle script；它只读取提交到仓库的依赖图并查询配置中的上游漏洞源。如果需要完全显式的底层命令，等价写法是：
 
 ```bash
-pnpm dlx --package=upstream-radar@0.33.9 upstream-radar radar check \
+pnpm dlx --package=upstream-radar@0.33.10 upstream-radar radar check \
   ./upstream-radar.config.json --frozen --state :memory: --fail-on high \
   --fail-on-compatibility breaking --json
 ```
@@ -862,7 +866,7 @@ pnpm dlx --package=upstream-radar@0.33.9 upstream-radar radar check \
 如果还要检查一个已发布插件能否跨多个 DSH 版本加载，可以增加三个 input：
 
 ```yaml
-- uses: MicroMilo/upstream-radar@v0.33.9
+- uses: MicroMilo/upstream-radar@v0.33.10
   id: radar
   with:
     config: upstream-radar.config.json

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "upstream-radar",
-  "version": "0.33.9",
+  "version": "0.33.10",
   "description": "Always-on dependency security monitoring for DeepSeek Harness (DSH) plugins: find exact installed or candidate transitive vulnerable paths and breaking updates, then route evidence to a DSH Agent.",
   "type": "module",
   "license": "Apache-2.0",