@4da/mcp-server 6.2.3 → 6.2.5

package/CHANGELOG.md

@@ -1,5 +1,525 @@
 # Changelog
 
+## 6.2.5 — 2026-10-26
+
+### Pre-publish adversarial audit fixes (2026-10-26)
+
+An independent six-track audit of the 6.2.5 candidate (oracle parity, fault
+injection, security, honesty, install/release, cross-engine parity) found the
+following. Each fix has a regression test that fails on the old code.
+
+- **Suggested commands never carry text a repository controls.** `cargo add`
+  put a Cargo.toml `[target.'cfg(...)']` header inside `--target "..."` and a
+  renamed key after `--rename`, where a shell would expand it. Every command
+  builder now checks every value it splices; anything else gets words, not a command.
+- **cargo runs from the server's own data directory**, not a fixed folder in
+  the shared temp directory where another account could plant a cargo config.
+- **An unchecked fix target is never said to "resolve" anything.** When the
+  target check runs out of time the line says NOT CHECKED; an alias group's fix
+  is the highest any of its records names (netmask: 2.0.1, not 1.1.0).
+- **A fix target is judged by what it installs.** A release that exact-pins (or
+  narrowly pins) an affected dependency is not offered: express 4.22.3, not
+  4.20.0, in vulnerability_scan, dependency_check and upgrade_planner.
+- **One OSV record no longer blinds the scan.** An `affected[]` entry with no
+  `package` (EEF-CVE-2026-56812, npm phoenix) made every dependency NOT CHECKED.
+- **Desktop mode reads a project the app does not track** from its own
+  lockfiles; the planner no longer answers "0 steps" for it.
+- **Fail-closed, further:** an answer from an expired cache, a cache row
+  fetched "in the future", a malformed querybatch entry, a stalled response
+  body or a registry outage is never presented as a current, complete answer.
+- **Malware** is critical in every tool, scan rows carry `malware`, and a copy
+  with a clean later release is an upgrade, not a removal.
+- **Honesty:** unsound RustSec advisories are never hidden as notices; Maven /
+  Gradle / .NET tasks are never `safe_to_delegate`; a Maven-only scan has null
+  totals; a Go scan says the standard library is not checked; a flat
+  requirements.txt says its dependencies were not checked; aliases are counted
+  once; two-part versions (Django 4.2 -> 5.2) are majors; a clean stable release
+  comes before a prerelease fix; recalled memories are labelled untrusted data;
+  the privacy wording names private package names, HN search and opt-ins.
+- **PyPI advice:** a compiled requirements file is re-compiled
+  (`--upgrade-package`), never hand-edited; pins of a fully pinned file are
+  re-resolved together.
+- **Paths:** symlinked requirements files and Cargo workspace members outside
+  the project are not read; `[build-dependencies]` are normal dependencies.
+- **Install:** `4da-mcp-setup` works on macOS and Linux (it was a no-op through
+  npm's symlinked bin); CI now installs the packed tarball on all three OSes;
+  the release verifies provenance on every run and pins npm.
+- **Performance:** a large pnpm-lock.yaml is read in linear time (200k entries:
+  409 s -> 0.6 s).
+
+### An incomplete scan is never a clean one (audit A1/B-1/B-2, critical)
+
+6.2.4 turned an OSV.dev outage, a 503, a timeout or its own rate limit into a
+clean report. Reproduced 2026-10-12 with an empty cache: the 4DA app's `src-tauri`
+(10,568 dependencies) came back `total_vulnerable_packages: 0`,
+`dependency_health` scored it 75/100 and `upgrade_planner` said
+`vulnerabilityDataAvailable: true`; the only trace was `_meta.offline`.
+
+- **Large trees are answered in full.** querybatch requests (1,000
+  dependencies each) go out as the query budget allows, waiting for it to
+  refill (60 s at most), instead of failing the whole scan past 10 batches.
+  The budget is 60 batches a minute. A failed batch is retried once. The same
+  tree, cold, now reports 11,203 dependencies and 431 vulnerable packages
+  (with `include_test_fixtures`; see below).
+- **What OSV did not answer is counted, and leads the answer.** Dependencies
+  with no answer (and no earlier cached one) are `unchecked`, never clean.
+  `vulnerability_scan` then starts with `summary: "NOT CHECKED: OSV.dev
+  unreachable (...) — N of M dependencies have no vulnerability answer"`,
+  `coverage.unchecked_dependencies` counts them, and `total_vulnerable_packages`,
+  `by_severity` and `clean_dependencies` are null (findings in the checked part
+  are under `found_in_checked_dependencies`).
+- `dependency_health` withholds `healthScore` and `vulnerableCount` (null) and
+  adds `vulnerabilityCoverage`; `upgrade_planner` sets
+  `vulnerabilityDataAvailable: false` and adds `vulnerabilityCoverage`. Both
+  summaries start with "NOT CHECKED". The tool descriptions and the server
+  instructions say an incomplete result is not a clean one.
+
+### dependency_health says what each number counts
+
+navcal read "Health: 19/100. 18 dependencies scanned, 26 vulnerable" (6.2.4
+too): 18 was the direct runtime dependencies checked against their registry
+(25 devDependencies left out), 26 the vulnerable packages among the 633
+installed. The summary now names both populations ("18 direct dependencies
+checked against their registries (25 devDependencies left out ...); 26
+vulnerable packages in the full tree of 633 installed (1 direct, 25
+transitive); 14 outdated (direct)"), the answer adds `treeDeps` and
+`vulnerableDirectCount`, and the score states its penalties ("100 minus 55 for
+vulnerabilities, 26 for outdated, 0 for deprecated") with `healthScoreBasis`.
+`ecosystem_filter` now narrows the vulnerability counts too, and a project with
+no direct dependencies reports 0, not 1.
+
+### Coverage stated, not implied
+
+- **Ruby and PHP are read** (audit A2): `Gemfile.lock` (RubyGems; git and path
+  gems are local code and are skipped, as the desktop app does) and
+  `composer.lock` (Packagist; `packages-dev` marked dev). Both are ratcheted at
+  1.0 in the conformance corpus (RubyGems 143/143 findings, Packagist 44/44).
+- **Ecosystems not read are listed.** Maven (`pom.xml`), Gradle, .NET
+  (`*.csproj`, `packages.lock.json`, ...), Pub, Hex, SwiftPM, CocoaPods and a
+  `Gemfile` / `composer.json` with no lockfile are reported in
+  `coverage.not_covered`, in mixed repositories too. A project made only of
+  them is told "NOT COVERED: ... Nothing was checked" instead of "No manifest
+  files found ... Run this tool from your project root directory".
+- **Test fixtures are not the project** (audit A3). Lockfiles under `tests/`,
+  `test/`, `fixtures/`, `testdata/`, `__fixtures__/`, `conformance/` and the like
+  are left out by default and counted in `coverage.not_scanned`;
+  `include_test_fixtures: true` scans them. The 4DA app's `src-tauri` is 905
+  dependencies of its own, not 10,568.
+- **An unreadable lockfile is named** (audit B-9): merge-conflict markers,
+  invalid JSON or a damaged file is listed in `coverage.unreadable_lockfiles`
+  with the reason, instead of falling through to "no lockfile".
+
+### Fix advice
+
+- **No deprecated or yanked release as a fix target** (audit B-8): lodash
+  4.17.15 is sent to 4.18.1, not the deprecated 4.18.0 ("Bad release"), and
+  the note says why. See the readiness section below for what counts as
+  withdrawn.
+- **`last_affected`-only advisories** get the first published release above the
+  installed version that no known advisory affects as a candidate, labelled as
+  such, instead of "no fix" (audit A6), in `vulnerability_scan` and
+  `upgrade_planner`.
+- **A parent that will not move** (deprecated, or already at its latest
+  release) turns "waiting on upstream" into `override_or_replace`, with the
+  syntax for npm `overrides`, pnpm `pnpm.overrides`, yarn `resolutions`, or
+  Cargo `[patch]` (audit A4).
+- npm `-security` placeholder packages (`fs@0.0.1-security`) are no longer
+  reported as malware (audit A5), as in the desktop app, under any advisory id
+  (see the readiness section below).
+- `vulnerability_scan` includes direct devDependencies by default, labelled
+  `is_dev` and graded one level down, as the desktop app does (audit A8);
+  `include_dev: false` leaves out every dev-only copy (see the final audit
+  section below).
+- `dependency_check` counts a vulnerability once across its alias records
+  (GHSA + RUSTSEC), keeping the most severe grade. tokio 1.18.0's "6
+  advisories" are 3, all moderate or low, so its `review` verdict was right
+  (audit A9).
+
+### Found in the pre-release readiness audit (2026-10-16 to 10-18)
+
+6.2.5 was held back after an adversarial audit of the release candidate found
+5 high, 7 medium and 8 low findings, and each fix below was reviewed again
+before it was accepted. Every rule shared with the desktop app is pinned by
+the shared rule vectors, which both engines run.
+
+**Fix targets and versions**
+
+- **Packagist and RubyGems are ordered as Composer and Gem::Version order
+  them** (H2). Two-part OSV bounds such as `6.4` are padded, so targets stay on
+  the installed line: symfony/process 5.1.0 goes to 5.4.51 and rack 2.0.6 to
+  2.2.23, not 8.0.5 and 3.2.6. A two-part `fixed` bound no longer makes a
+  vulnerable version look clean, and a Packagist lower bound with no stability
+  suffix admits that release's prereleases (`>=8.0` admits 8.0.0-RC1, as
+  Composer reads it). An advisory's enumerated `versions` list is honoured too.
+  A RubyGems beta is never offered as a stable target.
+- **A release its registry withdrew is never the target** (FX-H5, with the
+  app): crates.io and PyPI yanked releases, and npm deprecated releases when a
+  later, non-deprecated stable release exists on the same caret line. A
+  whole-major npm notice is not a withdrawal: glob 10.4.5 goes to 10.5.0, not
+  12.0.0. When every way out is withdrawn there is no target, `withheld` names
+  the withdrawn releases, and the answer says "No installable fix", never "No
+  fix published". The same rule applies to each advisory's own fix, in
+  vulnerability_scan, upgrade_planner, dependency_check and
+  what_should_i_know. If the registry cannot be read, the earlier answer stands
+  and the answer says the withdrawal check did not run.
+- **A deprecated or yanked release is excluded even when OSV's per-package
+  query fails** (H5): lodash 4.17.20 goes to 4.18.1, labelled
+  `installed_advisories_only`.
+
+**upgrade_planner**
+
+- **A transitive pinned by a parent that has a newer release is
+  `upgrade_parent`, not "waiting on upstream"** (H1). `parentUpgrades` names
+  the smallest parent release whose own requirement admits a clean version,
+  and every declared dependency it arrives through (`levers`). That release is
+  clear of the parent's own advisories (one with no published fix is named
+  instead: "remains affected by ... (no fix published)"), and a dependency gets
+  the same release on every row: NodeGoat's express goes to 4.22.3, on its own row and as the
+  lever for path-to-regexp. When the parent's new requirement still admits the
+  installed copy, the step names the refresh to run after the install, because
+  npm keeps the copy (`refreshCommands`). A parent the lockfile cannot tie to a
+  declared dependency gets no command (`leverUnknown`) and is
+  `upgrade_parent_unverified`, not counted as fixed; a move across a major is
+  flagged `breaking`.
+- **A direct bump is raised to the release that also clears the vulnerable
+  transitives it pins**, never onto a release its own advisories affect, and
+  across a major only when a row's only fix is across it (then `breaking`):
+  express 4.20.0 goes to 4.22.3.
+- **Commands keep how a dependency is declared** (E8, with the app): an exact
+  npm pin gets `--save-exact`, and `^`/`~` are kept and quoted (`npm install
+  "x@~1.2.6"`, also pnpm, yarn 1 and yarn berry; Cargo `cargo add` with
+  `--dev`/`--build`/`--target`/`--rename`; Go `go get`). No command is named
+  for a spec it cannot carry (`>=`, `||`, tags, git, `workspace:`), for a yarn
+  workspace member, or when the declaration does not admit the installed copy.
+  Commands run in the directory that declares the dependency.
+- **Dev-only vulnerable packages are planned by default**, labelled `isDev`,
+  and rows rank on the scan's scope-adjusted severity with runtime rows first
+  (H4). `include_dev: false` says what it left out.
+- Advisories are counted once per alias group (M1). An advisory with only
+  `last_affected` below the target is reported as resolved by it (M2).
+- **API:** a new `upgrade_parent` action; `parentUpgrades[]` with `levers[]`
+  (each with `commands`, `instructions` and `breaking`), `breaking`, `peer`,
+  `moreLevers`, `leverUnknown` and `refreshCommands`; direct rows can carry
+  `upgradeCommands` / `upgradeInstructions`.
+
+**Severity**
+
+- **One grade per advisory in every tool** (M6). An alias group no record of
+  which grades it takes the highest grade among all of its GHSA aliases: GO-2024-3333
+  is high, through GHSA-w32m-9786-jp63, in dependency_check,
+  vulnerability_scan, dependency_health and upgrade_planner alike.
+  `severity_from` names the alias the grade came from, and an alias that could
+  not be read within the 5 s budget or the cap is listed, never guessed. The
+  lookup uses the injected advisory source and makes no network call offline.
+
+**Coverage and dependency_health**
+
+- **Started inside a Maven, Gradle or fixtures-only project**, every tool says
+  NOT COVERED or "only test-fixture lockfiles" instead of "no manifest found"
+  (H3).
+- dependency_health counts advisories, not OSV records, so its counts match
+  vulnerability_scan's (pygoat 187, not 348). It counts the same population in
+  its registry and vulnerable figures and says whether dev-only copies are
+  included (L2).
+- **An unreadable lockfile withholds the health score**, with
+  `withheldReason` (M5). A refused requirements include, or a yarn.lock or
+  requirements entry over the length cap, is named under `refused_includes` /
+  `partial_lockfiles`. The score then covers the checked part only and says so
+  (`scoreCoverage`, "at least" counts) (M4, L5).
+- `--hash` options no longer push a requirements entry past the length cap.
+  Hashed `pip-compile` pins with many wheels were dropped silently before.
+- A `v`-prefixed version in an installed package.json is not install drift
+  (L1).
+
+**dependency_check and the rest**
+
+- **An unmaintained-package notice never moves the verdict** (L3). It is
+  listed in `maintenance_notices`, no longer counted in `affecting_to`, and no
+  longer turns `proceed` into `review`.
+- **npm security holding placeholders** (`0.0.<n>-security`) are not installed
+  code under ANY advisory id (L4). crossenv 0.0.2-security under
+  GHSA-c2m4-w5hm-vqjw read as malware when only MAL- ids were held. A
+  publisher's own `1.0.0-security` prerelease stays affected.
+- upgrade_impact reads every Cargo workspace member's features (M3).
+- Fix paths read a parent's registry requirements without peerDependencies
+  (L7).
+- In standalone mode, `resources/list` lists only the tools it serves, and the
+  startup line no longer claims working tools when the database is refused
+  (L6).
+
+### Found in the final release audit (2026-10-18)
+
+A last audit of the release candidate found 1 high, 5 medium and 7 low
+findings; the 4DA app's review of the same rules added three more. Each fix
+was checked live on NodeGoat, pygoat, xsv, navcal and victauri, and the rules
+shared with the app are pinned by the shared vectors.
+
+- **No tool offers a release an advisory affects** (H1). upgrade_planner sent
+  crossenv 0.0.2-security, npm's placeholder for removed malware, to 1.0.1, the
+  malware itself (GHSA-c2m4-w5hm-vqjw, last_affected 1.0.1); cross-env.js,
+  mongose, babelcli, d3.js, jquery.js, ffmepg, nodesass and nodefabric the
+  same. Every release a tool offers (the planner's newest-release target,
+  dependency_health's `latestSafeVersion`, what_should_i_know's `latest`) now
+  passes the advisory check dependency_check decides `proceed` by, and the
+  registry's withdrawals. A placeholder whose newer releases are all malware is
+  `remove_dependency` ("remove it"); otherwise the newest release that is
+  neither affected nor withdrawn is offered, or `hold_current` when none is.
+  dependency_health's `latestStableVersion` stays the registry's newest stable
+  release as published; when that release is affected or withdrawn,
+  `latestStableNote` says so and `latestSafeVersion` names the one offered.
+- **No release brings in an advisory the installed version does not have**,
+  fixed or not (the 4DA lead's rule for both engines): not a fix target, a
+  parent or lever release, or a newest-release offer. An advisory with no
+  published fix is skipped only when the installed version already has it.
+  When nothing qualifies, no release is named and the answer says "every
+  fixing release brings in <ids>", naming every such advisory across all the
+  releases blocked this way, sorted, not only the smallest one's. A parent or
+  lever whose only admitting release carries such an advisory reports the
+  outcome `introduces` (shared vector pr-010), not "no release admits".
+- **A maintenance notice never blocks a release** (both engines, the #994
+  review). An unmaintained or deprecated-package notice (the maintenance
+  predicate: OSV `informational`, or unmaintained wording) never makes a
+  release unclean, never leaves a row with no fix, and never produces
+  `introduces`. The copy's own fix-target walk and the clean-copy checks
+  behind parent moves and refreshes counted them before; a release affected
+  only by a notice is now the target.
+- **A fix that lands on malware says so.** When every release a fix could land
+  on is flagged malicious, the row names no release and reads "<pkg> is
+  flagged malicious (<id>): remove or replace <pkg>", not "still affected by
+  MAL-x".
+  dependency_health adds `latestSafeVersion` and `latestStableNote` and
+  measures `versionsBehind` to the safe release; what_should_i_know's `latest`
+  adds `registry_latest` and `note`.
+- **One clean-release rule everywhere, with the app** (#981). A malicious
+  advisory is never skipped:
+  a release it affects is never clean, never a target and never "newest", and
+  an installed copy it affects names no release ("... is flagged malicious:
+  remove or replace ..."). An advisory whose ranges cannot be read leaves the
+  decision undecided: no release, no command, and the reason. An advisory with
+  no published fix never blocks a move that fixes the rest, and the named
+  release says it "remains affected by ... (no fix published)". A parent's or
+  lever's newest release is the highest stable, non-withdrawn release no
+  malicious advisory affects, not its `latest` tag, which decides only the
+  "already its latest release" wording.
+- **One malware predicate** (the 4DA lead): a MAL- id, a MAL- alias, CWE-506
+  in `database_specific.cwe_ids`, or GitHub's fixed advisory title ("Malicious
+  Package in ..." / "Malicious code in ..." at the start, after leading
+  whitespace; ids and CWEs trimmed, any case: the app's is_malware exactly); no
+  other summary wording. GitHub's GHSA-c2m4-w5hm-vqjw ("crossenv is malware") has no MAL- id
+  and is malware by CWE-506; GHSA-28f8-hqmc-7ph8 ("Malicious Package in
+  ember-power-timepicker") has neither, and is malware by its title. It decides the offered release, the clean-release rule, parent
+  standing and the placeholder note, and an installed malicious copy is
+  critical in every tool. Scan rows carry `malware`; the advisory cache key
+  moved so rows cached without it are not reused.
+- **One grade per advisory, in every tool** (M2). vulnerability_scan kept the
+  grade of the record with the most detail; the other tools kept the most
+  severe. An alias group now takes the most severe own grade of its records,
+  each read by its curated label first and its CVSS band second (as the app
+  does: on the conformance corpus the label follows a CVSS v4 score neither
+  engine computes); a grade inherited from a GHSA alias applies only when no
+  record of the group has one. CVE-2026-4277 (GHSA-pwjp-ccjc-ghwg LOW,
+  PYSEC-2026-52 CVSS 9.8) is critical everywhere, and `severity_from` names the
+  record or alias the grade came from. dependency_health's
+  `vulnerabilitySummary` adds `unknown`, so it equals vulnerability_scan's
+  `advisory_by_severity`. upgrade_planner ranks by the scan's scope-adjusted
+  grade: a dev-only medium is low, an ungraded advisory medium, a MAL- record
+  high. The shared severity vectors run in the TypeScript runner.
+- **devDependencies are declarations** (M3). The lever walk read only
+  dependencies, optionalDependencies and peerDependencies, so a dev-only
+  transitive had "no declared dependency above" it; navcal's @vitest/mocker
+  and tinypool now name vitest. A workspace member's own dependency
+  (packages/a devDependencies minimist ^1.2.5) is declared there, and its
+  command runs in the member's directory.
+- **One release per dependency across all rows** (M4). NodeGoat named
+  express-session 1.18.1, 1.18.2 and 1.19.0 on three rows (1.18.1 still pins a
+  vulnerable on-headers); xsv crossbeam-channel 0.4.4 and 0.5.0. Each
+  dependency now gets the highest release its rows NEED (each lever's release,
+  and its own row's target when that row is a fix) that crosses no further
+  major and that its own advisories leave clean, on every row, with one
+  command; a freshness row follows that release and keeps the newest as
+  `latestVersion` (express-session 1.18.2 everywhere). The requirement,
+  `resolvesTo` and refresh are recomputed at that release. A release lifted
+  above its own smallest one records it (`smallest`); a lever through a
+  transitive parent records the parent's smallest admitting release (`floor`)
+  and the one it brings in (`brings`): NodeGoat's send copy reads "express
+  4.21.0 is the smallest express release that brings in a serve-static that
+  admits it, and express 4.22.3, the release express's own upgrade moves to,
+  also brings in serve-static 1.16.3".
+- **A declared bump that drops the package from the path comes before an
+  override** (M5). xsv's memoffset 0.2.1 and lock_api 0.1.3 go away with
+  crossbeam-channel, which no longer depends on crossbeam-epoch or
+  parking_lot: the step says "goes away" and names the command, instead of
+  pointing `[patch.crates-io]` at a fork (`goesAway`).
+- **`include_dev: false` means one thing** (M6): every dev-only copy (every
+  path to it is a dev one) is left out, in vulnerability_scan,
+  dependency_health and upgrade_planner, and each states the same population
+  ("N dev-only copies left out"; the scan's `dev_scope`). NodeGoat: 34
+  vulnerable packages in all three, where health said 82 and the planner
+  dropped 90 copies.
+- Smaller fixes: with OSV's per-package query and the registry both down, the
+  target says the withdrawal check did not run (7a); a lifted parent release
+  whose requirement no longer admits the installed copy names no refresh, and
+  none is named while another parent keeps the copy below the target (7b); a
+  parent upgrade whose levers name no release is `upgrade_parent_unverified`,
+  not "fixed by upgrading the parent" (7c); "admits" is said only of a
+  requirement that admits the target (7d); Go versions keep their `v` in
+  every target field (7e); a target with a whole-line npm deprecation notice
+  (glob 10.5.0) stays the target and says it is deprecated, as
+  dependency_check's `review` does (7f); a pin in a file included with `-r` is
+  declared, and its edit names that file (7g).
+- Parent and lever candidates follow the fix-target withdrawal rule (8a), and a
+  parent stands as the app's does: deprecated (its latest release is), then
+  already its latest release (the `latest` tag), then the walk. A vulnerable
+  row with no fix names no release.
+- **A declaration that already admits the fix is refreshed, not bumped** (with
+  the app). navcal's sharp, next and vite rows named `npm install "pkg@^x"` for
+  a `^` range that already admitted the target. The step is now the tool's
+  in-range refresh, each run live with the manifest left unchanged: `npm update
+  <pkg>`, `pnpm update <pkg> --no-save` (plain `pnpm update` rewrote the
+  range), `yarn upgrade <pkg>`, `yarn up -R <pkg>`, `cargo update -p
+  <crate>@<installed> --precise <target>`. Only an npm range bounded below the
+  next major (`^`, `~`, also on a prerelease base such as `^2.0.0-rc.4`) is
+  refreshed: a refresh installs the newest release in
+  range, so a `>=`, `||`, `*` or x-range could jump a major, and names nothing
+  (shared vector fc-059). A Cargo requirement is refreshed with `--precise`,
+  which pins the exact target. A row of refreshes reads "Fixable now with a lockfile
+  refresh (the declared range already admits the fix)"; a refresh among other
+  commands is labelled. An npm workspace member is refreshed in its own
+  directory, and a workspace-inherited, git, path or registry crate is never
+  refreshed this way.
+- The shared rule vectors `severity` (sv-001..sv-022) and `parent_release`
+  (pr-001..pr-012, with the graph lines run through the whole planner, and
+  Cargo lines) run in the TypeScript runner.
+- The conformance pin moves to 4DA 9450d1613 (#972, #976, #981, #986, #992,
+  #993, #994, #998, #1008, #1025): every shared vector line (435, nine files)
+  and the corpus suite pass at it. #1008's new lines hold the Rust engine to this
+  server's rules: a malware landing is named as malware (ft-070, ft-072), a
+  maintenance notice never blocks a target and is never one, even at its own
+  fixed bound (ft-071, ft-073, ring RUSTSEC-2025-0010), and a notice with a
+  published fix is still not graded from an alias (sv-023).
+- **An unmaintained-crate notice is a notice wherever RustSec puts the flag.**
+  RustSec writes `informational` on each `affected[]` entry, never on the
+  record, so RUSTSEC-2018-0017 (`tempdir` crate has been deprecated), net2 and
+  structopt were graded vulnerabilities. A record is now a notice for a package
+  when its summary says unmaintained, or `informational` is `unmaintained` or
+  `notice` on the record or on that package's affected entry; `unsound` stays
+  a vulnerability (smallvec). The same predicate as the 4DA app (#1025),
+  pinned by ft-074, ft-075, sv-024 and sv-025.
+- **A row's only fix across a major raises the row**, flagged `breaking`,
+  with the reason "the only release of <parent> that fixes <child> is <ver>, a
+  major upgrade" (the 4DA lead): xsv's crossbeam-channel row goes to 0.5.0,
+  the only release whose requirement admits a clean crossbeam-utils.
+- **Known difference from the desktop app:** the app's live path raises a
+  row across a major only for npm. For Cargo the app holds the rule in its
+  shared vector (pr-009) but not yet on live data, because a live Cargo raise
+  needs per-version dependency data it does not read yet. Until that lands,
+  this server and the app can give different answers for a live Cargo row
+  whose only fix is across a major.
+- **A lever that cannot move no longer hides its parent's release** (with the
+  app, shared vector pr-011). When a parent arrives through a declared
+  dependency that names no release (it is flagged malicious, every release
+  that would bring the fix in brings in an advisory it lacks, none does, or it
+  is at its latest), the parent's release is still named and that lever
+  carries `levers[].outcome` with its own reason ("no <lever> release is
+  named: ...", "replace <lever>"). The step stays `override_or_replace`,
+  with the override that forces the copy.
+- **API:** new actions `upgrade_parent_unverified`, `remove_dependency` and
+  `hold_current`; `parentUpgrades[].goesAway` and `smallest`;
+  `levers[].smallest`, `floor`, `brings` and `outcome`; `upgradeCommands[].refresh` and
+  `levers[].commands[].refresh`; local lockfile edges carry `dir` and
+  `section`.
+
+### Security: the working directory is never trusted (audit B-3/B-4/B-5/B-11)
+
+- A `data/settings.json` or `data/4da.db` in (or beside) the directory the
+  server starts in is no longer read. A cloned repository could use them to
+  send stored memory and decisions to a host of its choosing, or to plant
+  "decisions". Settings come from `FOURDA_SETTINGS_PATH`, the `settings.json`
+  beside `FOURDA_DB_PATH`, or the desktop app's data directory; the database
+  from `FOURDA_DB_PATH`, the desktop app's data directory, or the server's own.
+- A RELATIVE `FOURDA_DB_PATH` that names no file is refused with a clear error
+  instead of silently creating a database inside whatever directory the server
+  started in (`./data/4da.db`). An existing file still opens through a relative
+  path (4DA's own `.mcp.json` keeps working). An ABSOLUTE path that names no
+  file is created as a standalone database when its directory exists, as
+  before, and now says so: one stderr line and `_meta.database_note` in the
+  first tool answer; its directory missing is refused. The server used to pass
+  `FOURDA_DB_PATH` to the database as an explicit path, which skipped these
+  rules.
+- Requirements `-r` / `-c` includes stay inside the project: absolute, UNC,
+  drive-letter, or outside (also through a symlink) targets are not read.
+
+### Robustness
+
+- Hostile input no longer blocks the server (audit B-10): changelog headings and
+  yarn.lock version and dependency lines are parsed in linear time, and lines
+  over 4 KB are skipped (requirements files too). A crafted CHANGELOG or lockfile
+  line took 5–20 s or more.
+- `+build` metadata is not a prerelease (audit B-12): toml_edit's latest stable
+  is 0.25.17, not 0.23.9. PyPI `rc` / `a` / `b` / `.dev` versions now count as
+  prereleases in the latest-stable pick.
+
+### upgrade_impact (audit B-6/B-7)
+
+- A breaking entry that names a Cargo feature your manifest enables (reqwest
+  0.13's `rustls-tls` / `macos-system-configuration`) counts as touching your
+  code; the features are listed in `your_code.cargo_features`.
+- A GitHub PR line ("... by @user in <url>") is no longer a second change, and
+  replacement syntax after "use" / "instead" / ";" is no longer read as old
+  syntax (thiserror 2 flagged every `{name}` format string; `r#` raw
+  identifiers no longer match).
+- When the changelog is missing or partial, the answer says how to turn on the
+  opt-in GitHub fallback (`FOURDA_GITHUB_CHANGELOG=true`).
+
+### Protocol and docs (audit B-13 to B-19)
+
+- An unknown tool or prompt name is a JSON-RPC -32602 error, and an unknown
+  resource is resource-not-found, as the MCP spec says. `4da://schema/__proto__`
+  (and other names inherited from Object) no longer reach Object internals.
+  `4da://skills`, which never existed, is no longer advertised.
+- `get_context` marks dependency names read from repository lockfiles as
+  untrusted data.
+- README: the network-host list is complete (api.npmjs.org, index.crates.io,
+  hn.algolia.com and the opt-in hosts), and HTTP mode is documented as
+  single-tenant.
+- The conformance fetch works with Windows long paths, and a missing corpus
+  prints a visible warning (the suites used to skip silently).
+## 6.2.4 — 2026-10-12
+
+### Fix paths held to the 4DA rule vectors
+
+The fix-path rules (version order, OSV range evaluation, the fix target, the
+refresh-or-parent verdict, the refresh command, `range_check`) now run in CI
+against the shared rule vectors of the 4DA desktop app, the same 333 vectors
+its Rust engine runs (see `conformance/README.md`). All pass. The first run
+found these defects:
+
+- **pnpm workspaces: the refresh command missed members.** At a pnpm workspace
+  root, `pnpm update <pkg>` touches only the root project, so a member's
+  vulnerable transitive copy stayed (measured with pnpm 10.34.6). The command
+  is now `pnpm update -r <pkg> --depth Infinity` there, and
+  `pnpm update <pkg> --depth Infinity` elsewhere (vectors fc-005..fc-008).
+- **A blocking parent was not named when another parent's requirement could
+  not be read.** `upgrade_planner` gave up on the whole copy and kept a
+  generic "waiting on upstream". A requirement that excludes the target now
+  decides on its own, and the reason names it (rv-048).
+- **Unread requirements fall back to semver, and say so.** When not every
+  parent's requirement can be read (the registry did not answer) and none read
+  excludes the target, the verdict comes from semver compatibility: a target
+  in the installed version's caret range is a `lockfile_refresh` with
+  `refreshInferred: true` and a reason that says it was inferred; any other
+  target stays `waiting_on_upstream` (AD-055 ¶1; rv-002..rv-032 even ids,
+  rv-049, rv-050).
+- **npm aliases were unreadable requirements.** `"npm:string-width@^4.2.0"`,
+  how package-lock records cliui's `string-width-cjs`, is now read as `^4.2.0`
+  on string-width (rv-047).
+- **PEP 440 local labels did not order.** `1.0`, `1.0+abc.5`, `1.0+abc.7` and
+  `1.0+5` compared equal; they now order as PEP 440 says (vo-013..vo-015), so a
+  `last_affected` bound equal to a local-labelled install is read correctly.
+- Yarn 1 and bun have no command that moves one transitive copy in place, so
+  none is named; the manual steps (delete the lockfile entries, reinstall) are
+  unchanged.
+
 ## 6.2.3 — 2026-10-11
 
 ### Yarn 1 refresh instruction covers alias entries

package/README.md

@@ -106,15 +106,22 @@ Then ask your AI: **"What changes if I upgrade X to Y?"**, **"Scan for vulnerabi
 
 ## How It Works
 
-The server reads every lockfile of the project it is started in, including independently-locked projects below the root (a repo with `src-tauri/Cargo.lock` beside a root `pnpm-lock.yaml` is scanned whole) and skipping what `.gitignore` excludes: `package-lock.json` / `npm-shrinkwrap.json`, `pnpm-lock.yaml` (v5–v9), `yarn.lock` (v1 and berry), `bun.lock`, `Cargo.lock` (Cargo workspaces included), `poetry.lock`, `uv.lock`, `pdm.lock`, `Pipfile.lock`, requirements pins (`*requirements*.txt`, `requirements/*.txt`, with `-r` and `-c`), and `go.mod` / `go.sum` (Go's build list). Every Python source in a folder is read, not only the first. Every installed copy is scanned, not one version per name, with the lockfile's own dev flags. It re-reads them whenever a lockfile changes, and for npm it also checks what `node_modules` actually holds. The walk goes 4 levels down and up to 256 projects; whatever it leaves out, and every manifest with no lockfile (its declared ranges are not installs and are not scanned), is listed in the answer's `coverage` block, never dropped silently.
+The server reads every lockfile of the project it is started in, including independently-locked projects below the root (a repo with `src-tauri/Cargo.lock` beside a root `pnpm-lock.yaml` is scanned whole) and skipping what `.gitignore` excludes: `package-lock.json` / `npm-shrinkwrap.json`, `pnpm-lock.yaml` (v5–v9), `yarn.lock` (v1 and berry), `bun.lock`, `Cargo.lock` (Cargo workspaces included), `poetry.lock`, `uv.lock`, `pdm.lock`, `Pipfile.lock`, requirements pins (`*requirements*.txt`, `requirements/*.txt`, with `-r` and `-c`), `go.mod` / `go.sum` (Go's build list), `Gemfile.lock` (RubyGems; git and path gems are local code, not releases) and `composer.lock` (Packagist). Every Python source in a folder is read, not only the first. Every installed copy is scanned, not one version per name, with the lockfile's own dev flags. It re-reads them whenever a lockfile changes, and for npm it also checks what `node_modules` actually holds. The walk goes 4 levels down and up to 256 projects; whatever it leaves out, and every manifest with no lockfile (its declared ranges are not installs and are not scanned), is listed in the answer's `coverage` block, never dropped silently. So are manifests of ecosystems it does not read (Maven `pom.xml`, Gradle, .NET `*.csproj` / `packages.lock.json`, Pub, Hex, SwiftPM, CocoaPods: `coverage.not_covered`), lockfiles that exist but cannot be read (merge-conflict markers, invalid JSON: `coverage.unreadable_lockfiles`), and lockfiles under test-fixture directories (`tests/`, `test/`, `fixtures/`, `testdata/`, `__fixtures__/`, `conformance/` ...), which are not scanned as the project's own unless you pass `include_test_fixtures: true` (`coverage.not_scanned`).
+
+**An incomplete answer is never a clean one.** When OSV.dev cannot answer for some dependencies (outage, HTTP error, timeout, the query budget), `vulnerability_scan` starts with `summary: "NOT CHECKED: ... N of M dependencies have no vulnerability answer"`, counts them in `coverage.unchecked_dependencies`, and sets `total_vulnerable_packages` and `by_severity` to null (what the checked part found is under `found_in_checked_dependencies`); `dependency_health` withholds its score and vulnerable count, and `upgrade_planner` sets `vulnerabilityDataAvailable: false`. Large trees are queried in batches of 1,000 as OSV's budget allows, so a tree past 10,000 dependencies is answered in full.
 
 Measured against osv-scanner on 19 public repositories (npm, pnpm v5-v9, yarn v1 and berry, bun, Cargo, Poetry, uv, Pipfile, requirements, Go; 2026-10-10), every difference settled by OSV's own API: precision 1.00 over 19,115 findings, recall 19,115 of 19,116 on the lockfiles it reads (Maven/Gradle are not read). Newly read requirement files were also checked against pip-audit.
 
 - **OSV.dev** for known vulnerabilities, matched to exact installed versions
-- **npm registry, crates.io, PyPI, Go module proxy** for versions, deprecations and yanks
+- **npm registry, crates.io, PyPI, Go module proxy** (registry.npmjs.org, crates.io and index.crates.io, pypi.org, proxy.golang.org) for versions, deprecations and yanks
+- **npm download counts** (api.npmjs.org), for `dependency_health`'s weekly-downloads figure
 - **The package's own registry archive** (registry.npmjs.org, static.crates.io, files.pythonhosted.org, proxy.golang.org) for the changelog `upgrade_impact` reads; GitHub only if you opt in with `FOURDA_GITHUB_CHANGELOG=true` (below)
 - **npm full packument**, the **crates.io versions API**, the **PyPI JSON API** and the **Go proxy's version list** for `dependency_check` (publish times, yanks and retractions; on npm and crates.io also publishers, install scripts, per-version dependencies). These requests carry the package name only; the version you have installed is never sent to a registry, except that the Go proxy's list has no dates, so it is asked for the `.info` of the versions being judged (the same request `go get` makes). OSV.dev's advisory list for the package lets `dependency_check` name the safe releases in a constraint. Packuments are cached on disk and revalidated with `If-None-Match`; crates.io API reads are spaced one per second.
-- **Hacker News Algolia API**, only when you call `ecosystem_pulse`
+- **Hacker News Algolia API** (hn.algolia.com), only when you call `ecosystem_pulse`
+- **GitHub** (api.github.com, raw.githubusercontent.com), only with `FOURDA_GITHUB_CHANGELOG=true`
+- **Your embedding provider**, only if you configure one for semantic recall (a local Ollama URL, or api.openai.com; see below)
+
+Those are all the hosts the server contacts.
 
 Results are cached (24h for registry data, 1h for vulnerabilities, 30min for news) and rate-limited per source.
 
@@ -126,9 +133,11 @@ Results are cached (24h for registry data, 1h for vulnerabilities, 30min for new
 
 When the 4DA desktop app is installed, the server reads the app's database (`4da.db`) through a **read-only** connection and never creates or alters anything in it: no tables, no columns, no cache. The only writes are rows in the four app-owned tables the tools exist to fill, so the app sees them: decisions (`decision_memory` -> `developer_decisions`), agent memory (`agent_memory`), and feedback (`record_feedback` -> `interactions` and `feedback`, which the app's calibration reads). Those go through a separate write connection that waits briefly for the app's lock. If your app version lacks the table or a column a record needs, the record goes to `standalone.db` instead and the response says so in `_meta`. (Before 6.1 the server also created a `live_cache` table inside the app's database; it now keeps that cache in `cache.db`.)
 
+**Where configuration and the database come from:** `FOURDA_DB_PATH` if set (a relative path resolves against the server's working directory and must name an existing file; an absolute path that names no file is created as a new standalone database when its directory exists, and the first tool answer says so in `_meta.database_note`; otherwise it is refused with an error), else the desktop app's database in its data directory, else the server's own `standalone.db`. Embedding settings come from `FOURDA_SETTINGS_PATH`, else the `settings.json` beside `FOURDA_DB_PATH`, else the desktop app's data directory. Nothing is picked up from the directory the server is started in: until 6.2.5 a `data/settings.json` or `data/4da.db` inside (or beside) the working directory was adopted, so a cloned repository could redirect semantic recall to a host of its choosing or plant "decisions".
+
 > The one exception: if you *explicitly* configure an OpenAI embedding provider (`FOURDA_EMBED_PROVIDER=openai`) for semantic recall, the decision/memory text you store is sent to OpenAI to be embedded. The default — no embedding provider, or a local Ollama one — keeps everything on your machine, and `FOURDA_OFFLINE=true` overrides it regardless.
 
-**Ecosystems supported:** npm, crates.io (Rust), PyPI (Python), Go. `upgrade_impact` reads all four. PyPI: versions and dates from the PyPI JSON API, the changelog from the release's sdist, and import sites matched on the module the distribution installs: read from your virtualenv's metadata (`.venv`, `venv`, `env`: `top_level.txt` or `RECORD`), else a table of well-known differences (`PyYAML` -> `yaml`, `Pillow` -> `PIL`), else the distribution name, which the answer then labels an assumption. Go: versions and dates from proxy.golang.org, the changelog from the module zip, and a major version 2+ reported as the module path change it is (`github.com/jackc/pgx/v4` -> `/v5`), with the files that import the old path. `dependency_check` reads all four too; on PyPI and Go, where the registry exposes no publisher identity or install hooks, those signals say "not applicable".
+**Ecosystems supported:** npm, crates.io (Rust), PyPI (Python), Go; `vulnerability_scan` also reads RubyGems (`Gemfile.lock`) and Packagist (`composer.lock`). Maven, Gradle and .NET are not read, and are listed as not covered. `upgrade_impact` reads npm, crates.io, PyPI and Go. PyPI: versions and dates from the PyPI JSON API, the changelog from the release's sdist, and import sites matched on the module the distribution installs: read from your virtualenv's metadata (`.venv`, `venv`, `env`: `top_level.txt` or `RECORD`), else a table of well-known differences (`PyYAML` -> `yaml`, `Pillow` -> `PIL`), else the distribution name, which the answer then labels an assumption. Go: versions and dates from proxy.golang.org, the changelog from the module zip, and a major version 2+ reported as the module path change it is (`github.com/jackc/pgx/v4` -> `/v5`), with the files that import the old path. `dependency_check` reads all four too; on PyPI and Go, where the registry exposes no publisher identity or install hooks, those signals say "not applicable".
 
 **Known limits, stated plainly:** a `requirements.txt` without a lockfile names only your direct pins, so their transitive dependencies are not scanned (use `uv lock`, `poetry lock` or `pip-compile`). Many packages ship no changelog in their registry archive (fastembed, vite, zod among them); `upgrade_impact` then says so and gives the release-notes URL instead of guessing. Breaking entries are flagged from the changelog's headings and wording, and every entry carries the heading it sits under (`under`). Measured on a panel of 40 real upgrades across npm, crates.io, PyPI and Go (1,618 entries, gold from three blind raters with verbatim evidence; the panel and the measurement are in the test suite): on the 20 upgrades held out from rule-making, 95% of entries flagged breaking were breaking (95% CI 89-98%) and about 72% of breaking entries were flagged; Go release notes written as prose are the weakest (about 54% recall). Treat the flags as a pre-sort: read every entry of a major upgrade. Each answer says this in `_meta.classification`.
 
@@ -158,7 +167,7 @@ When the 4DA desktop app is installed, the server reads the app's database (`4da
 | `upgrade_impact` | What changes between the installed and a target version of one dependency (npm, crates.io, PyPI, Go): releases in between, changelog entries classified breaking / deprecation / security, the breaking ones that touch your code (symbols you import, and route or pattern syntax in your string literals, e.g. axum 0.8's `/:id` -> `/{id}`), the files that import it, advisories fixed. |
 | `vulnerability_scan` | Every installed copy in every lockfile matched against OSV.dev. Scope-adjusted severity, an upgrade target checked against every advisory of the package (the highest per-advisory fix can itself be affected by another), where each version is pinned, and a `coverage` block whenever the scan is partial. Concise by default (one row per vulnerable package version, the 40 most severe, about 4k tokens on a 290-advisory project); `package` for one dependency; `response_format: "detailed"` for every advisory. |
 | `dependency_health` | Version freshness, deprecation (of the version you run) and vulnerability counts per dependency. |
-| `upgrade_planner` | The smallest version no advisory affects for each vulnerable package, majors flagged (a 0.x minor counts as a major). Transitive fixes: `lockfile_refresh` with the exact command (`npm update`, `pnpm update`, `yarn up -R`, `cargo update -p ... --precise`) when every parent's declared requirement already admits a clean version, else `waiting_on_upstream` naming the requirement that blocks it. For one project: `project_path` (default: the project the server was started in; `"*"` for every project the desktop app tracks). `package` for a one-package plan. |
+| `upgrade_planner` | The smallest version no advisory affects for each vulnerable package, majors flagged (a 0.x minor counts as a major). Direct steps (`upgrade_direct`) carry `upgradeCommands`, the command per declaring project directory, keeping how the dependency is declared (`npm install x@v --save-exact` for an exact pin, `npm install "x@^v"`, `pnpm up`, `yarn upgrade` / `yarn up`, `cargo add` with `--dev` / `--build` / `--target` / `--rename`, `go get`; none for a `>=` / `||` / tag / git spec or a yarn workspace member), and a direct target is raised when a slightly newer release also clears a vulnerable transitive it pins. Transitive fixes: `lockfile_refresh` with the exact command (`npm update`, `pnpm update`, `yarn up -R`, `cargo update -p ... --precise`) when every parent's declared requirement already admits a clean version; `upgrade_parent` when a parent pins it but a newer release of that parent admits one, with `parentUpgrades` naming the smallest such release that is itself clear of the parent's advisories (read from the registry), the declared dependencies to bump (`levers`, with their commands; none when the lockfile cannot tie the parent to a declaration) and, when the new requirement still admits the installed copy, the refresh to run after the install (`refreshCommands`); `override_or_replace` with the override syntax (npm `overrides`, pnpm `pnpm.overrides`, yarn `resolutions`, Cargo `[patch]`) when the parent will not move (deprecated, already its latest release, or no release admits a clean version); `waiting_on_upstream` when the parent's releases could not be read, and for a copy bundled inside its owner's package, which only a new owner release (or replacing the owner) can move. Dev-only packages are included and labelled `isDev`, as in `vulnerability_scan`. For one project: `project_path` (default: the project the server was started in; `"*"` for every project the desktop app tracks). `package` for a one-package plan. |
 | `dependency_check` | Call before writing any dependency version into a manifest: adding, pinning, upgrading, bumping, downgrading. `to` is the exact version, or the constraint you were given (`"7.x"`, `"^1.20"`, `"~=3.1"`, `"v1"`): then `range_check` lists the smallest and newest release in it that no known advisory affects, and the verdict is for the one it picks. An exact version an advisory affects gets the safe releases on its line. Verdict per item (`proceed` / `wait` / `review` / `avoid` / `unknown`) with evidence: advisories on the target, release age (holds releases under 3 days unless they fix an advisory you have), publish-trust drop, new install scripts, brand-new transitive dependencies, yanked or deprecated, and a breaking version range (a major, or a 0.x minor) is `review` with a pointer to `upgrade_impact`. npm, crates.io, PyPI and Go (publisher trust, install scripts and new transitive dependencies are npm/crates.io signals and say "not applicable" elsewhere). |
 
 ### Intelligence
@@ -242,6 +251,12 @@ every request must carry a Bearer token whose HMAC-SHA256 signature verifies
 against that secret, and the token's role is enforced per tool (`viewer` is
 read-only; `member` and `admin` may write). Put TLS in front of it.
 
+**HTTP mode is single-tenant.** A token's `team_id` is verified but not used to
+separate data: every authenticated client shares one database, one agent memory
+and one set of decisions, and `project_path` lets any authenticated client scan
+any directory on the host the server can read. Run one server per team (or per
+trust boundary), and only behind clients you would give that access.
+
 ## CLI Reference
 
 ```
@@ -256,7 +271,8 @@ npx @4da/mcp-server --version    # Print version
 
 | Variable | Description | Default |
 |----------|-------------|---------|
-| `FOURDA_DB_PATH` | Path to 4DA's SQLite database | Auto-detected |
+| `FOURDA_DB_PATH` | Path to 4DA's SQLite database. An existing file is used. A relative path (resolved against the working directory) that names no file is refused. An absolute path that names no file is created as a standalone database if its directory exists (one stderr line and `_meta.database_note` in the first tool answer say so), and refused if the directory does not exist. | The desktop app's database, else the server's own |
+| `FOURDA_SETTINGS_PATH` | `settings.json` holding the optional `embedding` block for semantic recall | Beside `FOURDA_DB_PATH`, else the desktop app's data directory |
 | `FOURDA_OFFLINE` | Disable all network calls | `false` |
 | `FOURDA_GITHUB_CHANGELOG` | `upgrade_impact`: read GitHub release notes when the registry archive has no changelog for the range (`true` / `1` / `yes` / `on`) | Off |
 | `GITHUB_TOKEN` | Used only with `FOURDA_GITHUB_CHANGELOG`: raises GitHub's rate limit from 60 to 5,000 requests an hour | Unset |