[runyourempire]

Summary

Two defects, fixed in two commits, plus two commits that address the review.

A (HIGH, security): a release is checked against advisories before it is announced or offered a command

Until now scoring::release_grade never asked whether the announced release was safe to move to, and the advisory lanes only check the copies a project already runs. So a newly published malicious minor (OSV MAL-, or a GitHub malware advisory) inside a project's declared range showed up in the stack-change stream with a ready-to-run npm update <pkg>, which is the command that installs it. The Brief's upgrade facts had the same blind spot.

New module osv/release_advisories.rs (ReleaseChecker) checks the announced release itself, in this order:

1. Affected. The same predicate as "this version is clear" (parent_hint's is_clear): every stored, non-withdrawn advisory for the package must leave the version outside its window. A window the matcher cannot read counts as affected. An affecting advisory is reported even when the mirror is stale.
2. Withdrawn. fix(fix-target): never recommend a yanked or deprecated release (FX-H5) #976's release_facts: yanked, or npm-deprecated with a later clean release.
3. Unknown when the ecosystem's advisory data is not ready (osv::readiness::classify: no successful sync inside the 72 h trust horizon, failed, or still syncing). Also unknown when the advisory rows cannot be read: any row error makes the whole read unknown, never a silent skip. Also unknown when the registry gave no publish date.
4. Held when the release is younger than RELEASE_HOLD_DAYS = 3. A bare date counts from its last second, not from midnight.
   • The hold matches this repo's pnpm-workspace.yaml minimumReleaseAge: 4320 (a test pins it) and the MCP server's WAIT_DAYS.
   • The hold is never shorter than the trust horizon (also pinned), so a release past the hold always predates the sync it was checked against.
5. Clear. Only a clear release can carry a run_command.

Package names are matched the way the matcher does it (package_key, plus crates.io treating - and _ as the same name).

What the stack-change stream does with each verdict:

• Affected: the item is kept as a warning. There is no run_command. The title becomes pkg 4.2.0: malicious release, do not install (or affected by <ids>). The explanation names the advisory ids. Where the declared range admits the release, it also says that a lockfile refresh or an install without the lockfile would pull it in. The item gets osv citations and a review_security "Read the advisory" action. Malware is urgency High.
  • Exception: a non-malware release is left to the advisory lane only when every affecting advisory also hits (version-confirmed) every active project's installed copy. In that case the advisory lane already reports each one with a target that clears it.
  • Coverage is judged only on the copies of working projects. Scratch and dormant projects are filtered out before the check.
  • Malware is never dropped, whatever else is true.
  • An affected dev-only minor is no longer dropped as "tooling news", because install scripts run for dev dependencies too. Its range is read from the project's own devDependencies.
  • The "a refresh would pull it in" warning also reads the ranges declared in npm-family workspace members' manifests.
  • A refresh command is still only named for a runtime pin whose own manifest admits a release checked clear.
• Held: no command. The explanation says: "pkg 4.2.0 was published 1 day ago (2026-10-17); 4DA names no command for a release younger than 3 days, so a compromised publish can be caught and pulled first."
• Withdrawn: no command, and the item says the registry withdrew the release.
• Unknown: no command, plus a line saying the advisory status is unknown and why (stale, failed or never-synced mirror, unreadable data, or no publish date).
• Clear: unchanged.

release_item is split into release_explanation, release_citations and release_actions.

The Brief (brief_facts_build.rs, a 6-line hunk): an upgrade fact whose release is affected or withdrawn is dropped.

• Upgrade facts are only Breaking or Yanked releases, which a lockfile refresh does not pull in, and they carry no command, so dropping the nudge is the honest option.
• Annotating them instead would mean adding a field to UpgradeFact in brief_facts.rs, which is at 997 of 1000 lines and shared with three open PRs.
• Held and unknown releases are not dropped there: the Brief names no command for an upgrade, and it already prints its own "advisory check not complete" line when the mirror is not ready.

The npm 0.0.N-security placeholder handling is unchanged: it is still a prerelease that is never announced (test added), and the matcher's holding rule is untouched.

B (MEDIUM): workspace members' declared dependencies are direct

direct_names for JavaScript read only the lockfile directory's own package.json. A dependency that only an npm, yarn or pnpm workspace member declared was stored as transitive, so the parent walk (parent_hint, which stops at the first direct copy) found no lever for anything under it.

The direct set now also includes the members' dependencies and devDependencies. Members are found by ace::npm_local::workspace_member_dirs from:

• the root workspaces (array, or yarn's {packages: [...]});
• pnpm-workspace.yaml packages:, in block or flow style (packages: ['a/*']).

Negations are honoured with real glob matching: !**/test/** excludes packages/test, because an excluded package is not a member. dir/** still expands one level deep, which is documented in the code. The members' own package names are excluded (they are local code), as are protocol specs such as workspace:. Single-root projects are unchanged.

Attribution:

• Rows stay on the lockfile project, the workspace root. The data model has no "declared in" column, so naming the member would need a schema change (not done).
• Consistency with feat(fix-path): direct upgrades name the command that keeps how they are declared (E8, C2); security placeholders hold for any advisory (L4); H2 vectors #972: direct_upgrade::direct_fix reads the root package.json, does not find a member-only declaration, and names no command. The plan keeps "bump it where it is declared". Yarn members still decline by design.

Coordination

• osv/mod.rs: one line (pub(crate) mod release_advisories;), away from fix(upgrade-plan): name the parent release that fixes a nested advisory (audit H1) #981's lines.
• brief_facts_build.rs (feat(brief): a declared copy's bump names the command that keeps how it is declared (audit E8, C3) #982): one 6-line hunk in build_upgrade_facts.
• brief_facts.rs, parent_hint.rs, upgrade_plan.rs, pipeline_v2.rs, osv/types.rs and osv/identity.rs are not touched.

Follow-ups (not in this PR)

• The pipeline_v2 "New minor: X a -> b" feed row still announces a release without the check. It carries no command, and the file is fix(advisories): unversioned matches are never grounded; uncovered ecosystems say so (audit A2/E4) #974's.
• Knowledge Gaps' "behind" lane grades releases without the check.
• release_changelog::release_target grades releases (and fetches the new version's archive) without the check.
• release_grade::concerned_pins picks the largest gap before the scratch/dormant filter. When a scratch project is a major behind and an active project only a minor behind, active_pins is empty and the release says nothing for the active project, malware included. This was already the case before this PR; the fix is to filter liveness before picking the top gap.

Tests

All run after rebasing onto origin/main (which includes #974 and #982):

• cargo test --lib -- scoring:: evidence:: brief_facts ace_commands osv:: ace::npm_local briefing: 1703 passed, 0 failed (30 ignored).
• osv/release_advisories_tests.rs (16 tests):
  • malware detection: MAL- ids, MAL- aliases, GHSA "Malicious code in" summaries;
  • a window the matcher cannot read counts as affected;
  • an advisory is reported even when the mirror is stale;
  • coverage requires every active copy to be hit;
  • the hold: 1 day old is Held, 4 days old is Clear, a bare date ages from its last second;
  • an undated release is Unknown;
  • the hold is pinned to minimumReleaseAge (4320 minutes) and to the trust horizon;
  • a stale, failed or never-synced mirror is Unknown;
  • a withdrawn release is never clear;
  • an undecodable advisory row makes the read Unreadable;
  • package-name matching follows the matcher;
  • a database-backed checker test.
• evidence/stack_change_tests.rs:
  • a malicious minor gets no Run action, a "do not install" warning and urgency High;
  • a clean minor keeps its npm update;
  • an affected release names its advisories and gets no command;
  • unknown, held and withdrawn releases get no command;
  • review B2's exact shape: a scratch project on 2.0.5 and an active project on 2.0.0 (^2.0.0), with MAL- listing 2.0.5 and 2.1.0, still produces the warning;
  • malware is never left to the advisory lane;
  • an affected dev-only minor is announced, with its range read;
  • a range declared by a workspace member triggers the refresh warning, with no command;
  • the npm placeholder is unchanged.
• ace_commands/dependencies_tests.rs: npm array workspaces, yarn object form, pnpm block style with a negation, pnpm flow style plus wildcard negations, a single root unchanged, and an end-to-end walk where a member's dependency is stored as a direct row and its child stays transitive.
• cargo fmt --check: clean. cargo clippy --lib -- -D warnings: clean. check-file-sizes: warnings only, no errors.

🤖 Generated with Claude Code

https://claude.ai/code/session_018hjX3pEMmC7CHfG41PiPj7