@4da/mcp-server 6.0.2 → 6.2.0

package/CHANGELOG.md

@@ -1,5 +1,438 @@
 # Changelog
 
+## 6.2.0 — 2026-10-11
+
+### `dependency_check`: the release-age hold no longer leaves only vulnerable choices
+
+The 3-day hold on new releases is waived for a clean version when every safe
+release on its line is inside the hold too and every older release on that line
+has a known advisory: holding back would leave only vulnerable releases to
+write. The `release_age` signal then says `proceed` with
+`hold_waived: "no_settled_safe_release"`, names the line and the count of
+vulnerable older releases, and asks the agent to tell the user the version's
+age. A package whose only releases are new keeps the hold (that is the
+supply-chain case it exists for). Found by G7 (golang.org/x/net on 2026-10-11:
+the only safe releases were 1.8 and 2.8 days old, 59 of 61 v0 releases were
+vulnerable, and every run left go.mod unchanged).
+
+### `dependency_check`: PyPI and Go, safe versions in a constraint, and instructions that make agents call it
+
+The G7 agent evaluation (49 dependency tasks x 3 trials, 2026-10-11) found that
+when an agent called a 4DA tool, 0 of 60 runs wrote a vulnerable version, and
+when it did not, 41 of 78 did. The misses were runs that never called one:
+PyPI and Go adds (`dependency_check` took npm and crates.io only), pin tasks
+("pin ws 7.x" wrote 7.5.10 from memory; body-parser 1.20.3), and agents told
+they could not browse concluding they could not check versions at all.
+
+- **PyPI.** Releases, upload times and yanks from the PyPI JSON API (a release
+  is yanked when every file is; one with no files is not installable), PEP 440
+  ordering, OSV.dev for the exact version.
+- **Go.** Versions from proxy.golang.org, each judged version's date from its
+  `.info` (the list has none), `retract` directives in the latest go.mod
+  reported like a yank, `+incompatible` releases matched (`v2.0.0` finds
+  `v2.0.0+incompatible`), pseudo-versions dated and judged, and a major 2+
+  without its `/vN` path named as the different module it is.
+- Signals the registry cannot supply (publisher trust, install scripts, new
+  transitive dependencies on PyPI and Go) say "not applicable" with the
+  reason, never a made-up value or an `unknown` that blocks the verdict.
+- **Constraints.** `to` may be the constraint the agent was given: `"7.x"`,
+  `"^1.20"`, `"=0.17"`, `"~=3.1"`, `"3.1.*"`, `">=2,<3"`, `"v1"`. The item then
+  returns `range_check` (`smallest_safe_in_range`, `newest_safe_in_range`,
+  `safe_versions`, `smallest_safe_upgrade` above `from`), from every advisory
+  OSV.dev lists for the package evaluated against each release the constraint
+  admits, and the verdict is given for the version it picks: the smallest safe
+  upgrade above `from`, else the newest safe release past the 3-day hold. An
+  exact `to` an advisory affects gets the same `range_check` over its own line,
+  so "is ws 7.5.10 safe?" answers avoid and names 7.5.11. Withdrawn and
+  deprecated releases are never picked; maintenance notices do not make a
+  release unsafe. When nothing in the constraint is safe, the advisories that
+  affect all of it and the newest safe release outside it are named. A test
+  holds the local range evaluation to OSV.dev's own per-version answers on
+  recorded data (ws, Jinja2, golang.org/x/net).
+- **Instructions and descriptions.** The server instructions now open with
+  the rule "before writing any dependency version into a manifest or
+  lockfile, call dependency_check on that exact version, or on the constraint
+  you were given", name add / pin / upgrade / bump / downgrade / choose a
+  version for all four ecosystems, and say the server reads the registries
+  for the agent (so "I cannot browse" is not a reason to skip it).
+  `vulnerability_scan` says it judges installed versions and points at
+  `dependency_check` for a version about to be written.
+- The manifest-edit hook names a `dependency_check` call for PyPI and Go edits
+  too, and passes a range edit (`^7.0.0`) as a constraint instead of dropping it.
+- `ecosystem` is matched case-insensitively (`pypi`, `go`).
+
+### `upgrade_impact` reads PyPI and Go
+
+Until 6.1 it answered for npm and crates.io only, and pointed Python and Go
+upgrades at the briefing.
+
+- **PyPI.** Versions, publish dates and yanks from the PyPI JSON API, ordered
+  by PEP 440 (`2.0`, `3.0.0rc1` and `1.0.post1` are releases, not unreadable
+  semver); a two-part version such as pydantic `2.0` is that release, not a
+  line. The changelog is read from the target release's sdist on
+  files.pythonhosted.org (`CHANGES.rst`, `HISTORY.md`, ...); a release with
+  wheels only says so. Import sites are matched on the MODULE the
+  distribution installs, established from the project's virtualenv metadata
+  (`.venv` / `venv` / `env`: `top_level.txt`, else `RECORD`), else a table of
+  well-known differences (`PyYAML` -> `yaml`, `beautifulsoup4` -> `bs4`,
+  `Pillow` -> `PIL`), else the distribution name, which the answer labels an
+  assumption (`your_code.import_name_source`, `import_name_note`) instead of
+  guessing silently.
+- **Go.** Versions from proxy.golang.org (`/@v/list`, dates from `.info`), the
+  changelog from the module zip. A major version 2+ is a different module
+  path: `github.com/jackc/pgx/v4` -> `v5.0.0` reads the `/v5` module, lists
+  the rest of the v4 line and the v5 releases crossed, and reports
+  `module_path_change` with the files that import the old path. An up-to-date
+  module whose next major exists says so (`newer_major_module`). Import sites
+  come from `import "module/..."` specs, never counting another major's path.
+- The parser reads reStructuredText changelogs: titles underlined (or over-
+  and underlined) with any RST adornment, their `Released <date>` lines, and
+  non-release setext/RST titles as sub-headings. `CHANGELOG_PARSER_VERSION` is
+  4 (with the classifier changes below), so changelogs cached by 6.1 are re-read.
+- A zip reader (central directory only, stored and deflate entries, every
+  inflate capped) for Go module zips and zip sdists.
+
+### GitHub release notes, opt-in (`FOURDA_GITHUB_CHANGELOG`)
+
+Off by default: the default contract is unchanged, and only the package's
+own registry and OSV.dev are contacted. With `FOURDA_GITHUB_CHANGELOG=true`,
+when the archive has no changelog for the range, `upgrade_impact` reads the
+repository's GitHub releases (for PyPI, first a changelog file the project
+links on GitHub in `project_urls`), with the same parser and classifier.
+
+- The repository comes from registry metadata; for Go from the proxy's
+  recorded VCS origin, so vanity paths (`google.golang.org/grpc`) and
+  multi-module repositories (`service/s3/v1.50.0` tags) resolve. Monorepo tags
+  for other packages are skipped.
+- Unauthenticated REST API, or `GITHUB_TOKEN` when set. A rate limit is
+  reported with its reset time and how to raise it, and is not cached.
+  Results are cached under a key that carries `CHANGELOG_PARSER_VERSION`.
+- With the fallback off and no usable changelog, the answer says the
+  changelog is unavailable and gives `github_fallback.how_to_enable` (or says
+  enabling it would not help: no GitHub repository). `_meta.sources` and
+  `_meta.privacy` name GitHub whenever it was contacted.
+
+### Breaking-entry precision gate (G3)
+
+A held-out panel, re-measured by the test suite on every run
+(`src/__tests__/g3-breaking-precision.test.ts`, fixtures in
+`src/__tests__/fixtures/g3/`): 40 real upgrade pairs, 10 each from npm,
+crates.io, PyPI and Go, none of them a package the 6.1 rules were built on.
+Each pair records the changelog source the tool read live (registry archive or
+GitHub releases), trimmed to the range and checked to parse identically. Gold
+for each of the 1,618 entries shown is the majority of three blind raters
+working to a written rubric (`rubric.txt`), each label backed by a verbatim
+quote from the entry (Fleiss kappa 0.984; the raters were model instances,
+so agreement may be higher than independent human raters would reach). The
+test fails below 90% precision, overall or on the held-out half, and on any
+entry without a label.
+
+| | flagged | precision | recall |
+|---|---|---|---|
+| 6.1 rules, all 40 pairs | 246 | 94.7% | 55.0% |
+| 6.1 rules, 20 held-out pairs | 108 | 95.4% | 67.8% |
+| 6.2 rules, all 40 pairs | 326 | 97.2% (95% CI 94.8-98.5) | 74.8% |
+| 6.2 rules, 20 held-out pairs | 115 | 94.8% (95% CI 89.1-97.6) | 71.7% |
+
+The 6.2 rule changes were made from the 20 dev pairs' errors only:
+
+- An API change is read under any heading but a fix one. Covered: a leading
+  removal or rename of something API-shaped ("remove UMD build"), a changed
+  default, a type made private, a move or replacement, keyword-only
+  arguments, "now ... instead of", and "no longer comparable / usable /
+  subclasses".
+- Dropped runtimes and raised minimums break whatever the reason given
+  ("drop node 10.x to upgrade dev dependencies", "Replace go 1.21 with go 1.22
+  in go mod").
+- "Other Changes" / "Misc" headings are neutral, not additive: pgx 5 filed its
+  type removals there.
+- Fix headings are their own context.
+- "Previously-deprecated APIs have been removed" is a removal list.
+- `*Backwards-incompatible*` is an explicit marker.
+- Link targets, bare URLs and GitHub's "by @user in <PR>" are dropped before
+  classifying (a `go.dev/doc/...` link read "Drop support for Go 1.21" as a
+  docs change); RST ``literals`` read as code.
+- No longer breaking: entries that say they still work or have no effect on
+  users, private modules and `_names`, removing a deprecation notice,
+  restoring an API, relaxing a bound, renaming the repository, swapping a
+  dependency crate, and changes scoped to an example, docs or CI.
+
+Per ecosystem over all 40 pairs: npm 99.0% / 84.2%, crates.io 99.0% /
+81.3%, PyPI 95.7% / 72.5%, Go 92.0% / 54.1% (Go's GitHub release notes are
+largely PR titles and prose). `CHANGELOG_PARSER_VERSION` is 4.
+
+### Hook and briefing
+
+- The manifest-edit hook names the exact `upgrade_impact` call for
+  `pyproject.toml`, `requirements.txt` and `go.mod` edits (`ecosystem: "PyPI"`
+  / `"Go"`); `what_should_i_know`'s next step for a PyPI or Go package is
+  `upgrade_impact`.
+
+## 6.1.0 — 2026-10-10
+
+Fixes from an agent eval over stdio JSON-RPC against real projects (2026-10-07)
+and an engine-generalization test on 19 public repositories against
+osv-scanner, pip-audit and a fix-path oracle (2026-10-10): precision 1.00 over
+19,115 findings and recall 19,115 of 19,116 on the lockfiles the server reads
+(was 0.74 overall, with 44 langchain lockfiles dropped silently); the median
+`vulnerability_scan` over the corpus went from 27 s to 8.6 s.
+
+### Install: runs under npm 12 with no install scripts
+
+npm 12 blocks dependency install scripts unless allowed, so a default
+`npx @4da/mcp-server` or `npm install` left better-sqlite3's native module
+unbuilt and every tool failed (6.0.x documented an `allow-scripts` workaround).
+
+- The server uses Node's built-in `node:sqlite` when the runtime has it
+  (Node 22.13.0 and later; npm 12 itself requires 22.22.2+). No install
+  script, no native download. better-sqlite3 moved to `optionalDependencies`
+  and is used only where `node:sqlite` is missing (Node 22.0-22.12), if its
+  native module opens a database.
+- One driver interface (`src/sqlite-driver.ts`) covers what the server uses;
+  node:sqlite is adapted to match better-sqlite3: plain-object rows, BLOBs as
+  Buffers, error codes (`SQLITE_BUSY`, `SQLITE_NOTADB`, ...), the 5 s busy
+  timeout, savepoint-nested transactions, `readonly` / `fileMustExist`.
+  Read-only connections also set `PRAGMA query_only`.
+- With no usable driver at all the server no longer exits at import: it
+  starts, `vulnerability_scan`, `dependency_health`, `dependency_check` and
+  `upgrade_impact` run without a database (in-memory cache), and the other
+  tools return the fix (upgrade Node, or allow better-sqlite3's build).
+- `--doctor` reports the driver in use. `FOURDA_SQLITE_DRIVER=node|better|none`
+  forces one (tests, diagnostics). node:sqlite's one-time ExperimentalWarning
+  is filtered; other warnings pass.
+- Tests: the suite passes on each driver (CI runs it on both, and on Node
+  22.12, which has no node:sqlite); driver parity tests; the built server over
+  stdio with better-sqlite3's native module missing (fails on 6.0.2: every
+  tool answered "Could not locate the bindings file").
+
+### The server never changes the desktop app's schema
+
+The server opened the 4DA app's live `4da.db` read-write, created a
+`live_cache` table in it (2,774 rows on one machine) that the app's
+migrations do not own, and added `embedding` columns to app tables when an
+embedding provider was set.
+
+- Reads go through a `{ readonly: true, fileMustExist: true }` connection.
+  Nothing is created or altered in the app's database: no tables, columns
+  or indexes.
+- The response cache moved to `cache.db` in the server's own folder
+  (`%LOCALAPPDATA%\4da-mcp`, `~/Library/Application Support/4da-mcp`,
+  `~/.local/share/4da-mcp`; `FOURDA_MCP_HOME` moves it).
+- Decisions, agent memory and feedback still go into the app's own
+  `developer_decisions`, `agent_memory`, `interactions` and `feedback`
+  tables, so the app's decision UI and calibration see them. They go through a
+  separate write connection (busy timeout 3 s, one short transaction per
+  record). If the app's table or a column a record needs is missing (schema
+  drift), the record goes to the server's `standalone.db` and the response
+  says so in `_meta`; the server never creates it.
+- Semantic-recall embeddings are cached in the app's tables only when they
+  already have `embedding` / `embedding_model` columns; otherwise they are
+  computed per call.
+- Tests: the app's `sqlite_master` is identical after every tool ran, and
+  only those four tables gain rows; caching alone leaves the file
+  byte-for-byte unchanged.
+- The `live_cache` table already inside existing app databases is left
+  alone; the app owns that file and can drop it.
+
+### `upgrade_impact`
+
+- Reads changelog headings with inline HTML before the version (stripe:
+  `## <a id="23-0-0"></a>23.0.0 - 2026-09-30`). stripe 22.3.0 -> 23.0.0 went
+  from "no changelog" to 8 releases with 11 entries flagged breaking.
+- Bullets nested under an entry are that entry's `details`, not entries of
+  their own; a breaking detail makes the entry breaking. sqlx 0.8.6 -> 0.9.0
+  went from "83 entries flagged breaking" to 24 (its Breaking section's 23
+  bullets plus the MSRV statement).
+- "`Cargo.lock` Removed from Tracking" is no longer read as a Removed
+  category.
+- The parsed-changelog cache key carries the parser version
+  (`upgrade-impact:changelog:p2:...`). Parsed changelogs are cached for 7
+  days, so before this a parser fix in a release stayed invisible for a week
+  on every machine that had already read that package.
+
+### Breaking version ranges
+
+- `dependency_health` and `upgrade_planner` label a 0.x minor bump (and a
+  0.0.x patch bump) "major", as `upgrade_impact` and `dependency_check`
+  already did: under caret rules 0.12 -> 0.13 is breaking.
+- `dependency_check` returns `review` for a breaking range (a major, a 0.x
+  minor) with "breaking version range, run upgrade_impact". It returned
+  `proceed` for vitest 3 -> 5, reqwest 0.12 -> 0.13 and stripe 22 -> 23.
+- `what_should_i_know` counts a 0.x minor bump as a major one in
+  `majors_crossed` and the delegation verdict. It compared plain major
+  numbers, so "upgrade reqwest from 0.12 to 0.13" crossed 0 majors and came
+  back `safe_to_delegate`; it is now `review_needed`. Without a stated
+  "from", the furthest installed copy sets the distance.
+
+### Project scope
+
+- `upgrade_planner` and `what_should_i_know` take `project_path`. Default:
+  the project the server was started in; `"*"` for every project. Called
+  from 4DA, the app's plan led with navcal, verax and 4da-ledger steps; it
+  is now narrowed to the project's steps, lines and sites, and says how
+  many steps only touch other projects.
+
+### `what_should_i_know`
+
+- Expands the package families a task names ("all tauri plugins", "tauri
+  and its plugins", "@tauri-apps packages", "tauri-plugin-*") to the
+  project's direct dependencies in them. It matched only `tauri`.
+- For a task asking for the latest release, each package gets `latest`
+  (newest stable, installed vs latest major line, `on_latest_major`) and the
+  summary says which are already on the latest major.
+
+### `vulnerability_scan`
+
+- One recommendation per installed version, each advisory counted once.
+  "rsa 0.9.10 — 2 known vulnerabilities" was one advisory on two versions.
+
+### `vulnerability_scan` latency
+
+A cold scan (empty cache) through the server's own modules, same machine,
+same network, two runs each (2026-10-10):
+
+| Project | Dependencies | Before | After |
+|---|---|---|---|
+| superset | 4,516 | 71 s, 143 s | 9.4 s, 9.2 s |
+| proshop-mern | 1,545 | 34 s, 34 s | 6.5 s, 6.5 s |
+| nushell | 531 | 20 s, 17 s | 4.5 s, 4.4 s |
+
+- **Cache writes in one transaction.** A scan caches one row per dependency
+  and one per advisory, and each was its own autocommit: on superset the
+  network part of a cold scan ended at 12 s and the remaining ~40 s were
+  4,516 WAL commits. They are now one transaction per batch, and the cache
+  file runs `synchronous = NORMAL` (a cache: in WAL mode a crash can lose
+  only the last writes, never corrupt the file).
+- **Advisory details in a pool of 24, not rounds of 8.** OSV has no batch
+  endpoint for advisory records; rounds of 8 each waited for their slowest
+  request. A throttled (429), failed or timed-out detail request is retried
+  once instead of leaving the advisory without severity or summary.
+- **querybatch chunks (1,000 dependencies each) are sent 4 at a time**
+  instead of one after another; every chunk must answer or the scan fails, so
+  an unanswered chunk can never read as clean.
+- **No duplicate work beside the warm-up.** The startup warm-up scan and the
+  first tool call's scan ran side by side and both fetched every advisory
+  before either could cache it. An identical scan already running is now
+  awaited (a forced refresh still runs its own), and a detail request in
+  flight is shared by every scanner in the process.
+
+### What the standalone scan reads
+
+From the same 19-repository corpus, checked against osv-scanner and
+pip-audit.
+
+- **The project-tree walk is wider, and never silent about its bounds.**
+  langchain keeps 108 lockfiles up to three levels down; the walk (depth 2,
+  64 projects) read 64 and dropped 44 (4,852 advisory findings) without a
+  word in any answer. Bounds are now 4 levels and 256 projects (langchain:
+  about 2 s for the walk and every project scan). Past a bound the walk keeps
+  counting without scanning (up to 20,000 directories), and
+  `vulnerability_scan` returns a `coverage` block (concise and detailed:
+  `complete: false`, a note, `lockfiles_not_scanned`; detailed also lists
+  each skipped lockfile and why). `dependency_health` and `upgrade_planner`
+  say "Partial scan: ..." in their summaries.
+- **Python reads every source in a directory, merged:** poetry.lock, uv.lock,
+  pdm.lock (new), Pipfile.lock and every requirements file:
+  `*requirements*.txt` (requirements-dev.txt, _test_minimum_requirements.txt)
+  and the `.txt` files of a `requirements/` folder (superset keeps its 100
+  runtime pins in requirements/base.txt, which nothing read), plus a
+  `.txt` that `-r`-includes a requirements file and pins packages itself
+  (CTFd's development.txt). It read one source per directory, so langchain's
+  libs/community poetry.lock hid the _test_minimum_requirements.txt beside
+  it. `-r` includes are followed; a `-c` constraints file only gives a
+  version to a name a requirements file lists (it installs nothing by
+  itself). Against pip-audit on the newly read files: superset 149/152 rows
+  agree (the 3 others are advisories OSV lists and pip-audit's data does not
+  yet) and 262/262 of pip-audit's advisories are found; CTFd 6/6; langchain
+  libs 38/38 rows, 64/65 advisories (the miss is a langchainjs CVE pip-audit
+  files under the Python package).
+- A `dir/*/` .gitignore rule hid the files beside the ignored
+  subdirectories: `docs/api_reference/*/` made langchain's
+  docs/api_reference/requirements.txt look ignored. A directory-only rule now
+  ignores a file only through a directory above it.
+- **Dev scope from a requirements file's name, and only from it:**
+  requirements-dev.txt, requirements/testing.txt, docs-requirements.txt and
+  the like mark their packages dev. A package any other file lists keeps an
+  unknown scope (never "dev"), so a runtime package is never graded down by
+  a dev file that includes the runtime one.
+- **No lockfile: declared ranges are labelled, never scanned as installs.**
+  A package.json or Cargo.toml with no lockfile used to have its range
+  floors scanned as installed versions (nushell samples/wasm: 2 false
+  findings). Ranged dependencies now carry `declaredRange` ("^1.2.0") in
+  `dependency_health` and `upgrade_planner` and are not sent to OSV; exact
+  pins still are. `vulnerability_scan` lists each such manifest under
+  `coverage.unresolved_manifests` with the command that writes its lockfile.
+- A Cargo.toml read without Cargo.lock took `[package]`'s own `version =
+  "0.1.0"` and `edition = "2021"` for crates named "version" and "edition";
+  only dependency tables are read now.
+
+### Fix paths (`upgrade_planner`)
+
+From a fix-path oracle on 19 public repositories (2026-10-10): each
+recommended step was applied to a copy, the lockfile re-resolved and the
+project re-scanned with osv-scanner.
+
+- **A target is checked against every advisory of the package, not only the
+  ones the installed version has.** openssl 0.10.38 was sent to 0.10.79,
+  which GHSA-phqj-4mhp-q6mq affects (0.10.50 up to 0.10.80): the upgrade
+  traded old advisories for a new one. The target is now the smallest
+  published version at or above every per-advisory fix that no advisory
+  affects (0.10.80). The package's advisories come from one OSV `/v1/query`
+  per vulnerable package; versions from its registry (npm, crates.io sparse
+  index, PyPI, Go proxy), else from the advisories' own fix events. An
+  advisory no release fixes (braces GHSA-vfj7-8cjw-p6xm, last affected
+  3.0.3, the newest release) does not disqualify a target and is named in
+  the step. OSV `last_affected` events are read as closed ranges.
+- **"Waiting on upstream" only when a parent really blocks the fix.** Every
+  transitive finding used to be `waiting_on_upstream`; for minimist 1.2.5
+  (npm), braces 3.0.2 (pnpm) and mio 0.8.0 (Cargo) that was wrong: each
+  parent's declared requirement already admitted the fix, and a lockfile
+  refresh fixed all three. The planner now reads the parents of the
+  installed copy (package-lock v1-v3, yarn v1 and berry and bun.lock record
+  the ranges; pnpm and Cargo.lock do not, so the parent's requirement comes
+  from registry.npmjs.org or the crates.io sparse index) and returns
+  `action: "lockfile_refresh"` with `refreshCommands` (`npm update
+  minimist`, `pnpm update braces`, `yarn up -R`, `cargo update -p
+  mio@0.8.0 --precise 0.8.11`) when every requirement admits a clean
+  version. A step still waiting on upstream names the requirement that
+  blocks it (`left-pad 1.0.0 requires "1.2.5"`). Summary and
+  `lockfileRefreshes` count them.
+- A Cargo refresh names the locked crates `--precise` cannot move by itself.
+  `cargo update -p openssl@0.10.38 --precise 0.10.80` fails on nushell:
+  0.10.80 pulls syn 2, which needs quote ^1.0.25, and quote 1.0.15 is held
+  by rstest. The step is now `cargo update -p bytemuck@1.8.0 -p
+  proc-macro2@1.0.36 -p quote@1.0.15 && cargo update -p openssl@0.10.38
+  --precise 0.10.80`, found by walking the target's dependency requirements
+  against the lockfile.
+- Checked by applying every `lockfile_refresh` step of four plans to a copy
+  and re-scanning with osv-scanner: 104 of 104 steps cleared their
+  advisories (proshop-mern npm 45, taxonomy pnpm 21, chatgpt-tauri pnpm and
+  Cargo 26, nushell Cargo 12).
+- **`vulnerability_scan` and `what_should_i_know` run the same check** on
+  the targets they recommend. "Upgrade openssl 0.10.38 → 0.10.79" is now
+  "→ 0.10.80 (... 0.10.79, the highest per-advisory fix, is itself affected
+  by GHSA-phqj-4mhp-q6mq)". Concise rows carry `fix_checked`; detailed
+  output adds `fix_targets` per vulnerable package version, while each
+  advisory row keeps its own `fixed_version`. The check is cached and
+  bounded (5 s per call, most severe first); what it could not reach in time
+  says `installed_advisories_only`. On nushell, cold: 33 of 39 package
+  versions checked in the first call.
+- The test suite is offline by construction: `fetch` throws unless a test
+  stubs it (`FOURDA_TEST_NETWORK=1` lifts that), so no assertion can depend
+  on live OSV or registry data.
+- Each vulnerable step says how its target was checked: `fixPathChecked`
+  is `all_advisories`, or `installed_advisories_only` when OSV or the
+  registry did not answer (offline, or past the 25 s budget), and the
+  summary counts those.
+
+### Build
+
+- pnpm settings (overrides, onlyBuiltDependencies) moved from package.json
+  to pnpm-workspace.yaml: pnpm 11 ignores package.json's `pnpm` field, so
+  the CI audit ran without the security overrides. New override
+  source-map-js >= 1.2.2 (GHSA-68fv-2mgg-jv7q, high). Fixes the nightly CI
+  (#9).
+
 ## 6.0.2 — 2026-10-04
 
 ### `--setup` writes the files editors actually read

package/README.md

@@ -27,9 +27,7 @@ One command to install. No API keys. No accounts. Your code never leaves your ma
 
 Requires Node.js 22 or later.
 
-> **npm 12+:** npm 12 blocks dependency install scripts unless you allow them, which leaves the SQLite module (`better-sqlite3`) unbuilt. Allow it once, then clear the npx cache:
-> `npm config set allow-scripts=better-sqlite3 --location=user` and `npx clear-npx-cache`.
-> `npx @4da/mcp-server --doctor` checks this by opening a database. npm 10 and 11, which every current Node release ships, are not affected.
+The server uses Node's built-in `node:sqlite` (Node 22.13 and later), so it needs no install script and works with npm 12's default of blocking them. On Node 22.0-22.12 it uses the optional `better-sqlite3`, whose native module npm 10 and 11 build on install. `npx @4da/mcp-server --doctor` shows which one is in use.
 
 ```bash
 claude mcp add 4da -- npx @4da/mcp-server
@@ -108,25 +106,31 @@ 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`, `Pipfile.lock`, `requirements.txt` pins, and `go.mod` / `go.sum` (Go's build list). 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 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.
 
-Measured against osv-scanner on 12 projects (npm, pnpm, Cargo, Poetry, requirements.txt, Go): precision 1.00, recall 0.995; re-run before release from the installed package on those and 11 more never used to build the readers (yarn, pnpm, bun, uv, Pipfile, Go included), with every difference settled by OSV or Go's own build list.
+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
-- **The package's own registry archive** (registry.npmjs.org, static.crates.io) for the changelog `upgrade_impact` reads; never GitHub
-- **npm full packument** and the **crates.io versions API** for `dependency_check` (publish times, publishers, install scripts, per-version dependencies). These requests carry the package name only; the version you have installed is never sent to a registry. Packuments are cached on disk and revalidated with `If-None-Match`; crates.io API reads are spaced one per second.
+- **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`
 
 Results are cached (24h for registry data, 1h for vulnerabilities, 30min for news) and rate-limited per source.
 
 **What's sent over the network:** package names and versions (the same data visible in your lockfile), and, only for `ecosystem_pulse`, the names of a few of your dependencies as search terms. No source code, no file paths, no personal data. The call-site scan of `upgrade_impact` runs locally. Set `FOURDA_OFFLINE=true` to disable all network calls.
 
+**GitHub release notes (opt-in, off by default).** Many packages ship no changelog in their registry archive (vite, zod, cobra, most Go modules). With `FOURDA_GITHUB_CHANGELOG=true` in the server's environment, `upgrade_impact` reads the repository's GitHub releases when the archive has no changelog for the range (for PyPI, first a changelog file the project links on GitHub from its `project_urls`). GitHub then receives the repository name and the versions, nothing else. It uses the unauthenticated REST API (60 requests an hour) or `GITHUB_TOKEN` when set (5,000); a rate limit is reported with its reset time, never retried in a loop, and results are cached. With it off, an answer without a changelog says so and names the setting; nothing is guessed.
+
+**What's written to disk, and where:** only files the server owns, in its folder in your user data directory (`%LOCALAPPDATA%\4da-mcp`, `~/Library/Application Support/4da-mcp` or `~/.local/share/4da-mcp`; `FOURDA_MCP_HOME` moves it): `cache.db` (registry, OSV and changelog responses; safe to delete) and `standalone.db` (without the desktop app: your project scan and the decisions, agent memory and feedback you record). Nothing is written inside your repository.
+
+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`.)
+
 > 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`: npm and crates.io.
+**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".
 
-**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 47 upgrades never used to build the rules, against three blind raters who saw each entry's heading: 99% of entries flagged breaking were breaking (95% CI 95-100%) and about 65% of breaking entries were flagged. Earlier corpora, before the last parser fixes, measured 73-87%, so treat the flags as a pre-sort: read every entry of a major upgrade. Each answer says this in `_meta.classification`.
+**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`.
 
 ## What You Can Ask
 
@@ -136,6 +140,7 @@ Results are cached (24h for registry data, 1h for vulnerabilities, 30min for new
 "Scan for vulnerabilities"                    -> vulnerability_scan
 "Which deps should I upgrade first?"          -> upgrade_planner
 "Is it safe to bump axios to 1.14.1?"         -> dependency_check
+"Pin ws to a 7.x version"                     -> dependency_check (to: "7.x")
 "I'm about to bump fastembed 5 -> 7"          -> what_should_i_know
 "What's happening in the ecosystem?"          -> ecosystem_pulse
 "What's my tech stack?"                       -> get_context
@@ -150,23 +155,23 @@ Results are cached (24h for registry data, 1h for vulnerabilities, 30min for new
 
 | Tool | What it does |
 |------|-------------|
-| `upgrade_impact` | What changes between the installed and a target version of one dependency: 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, the fix version on your release line, where each version is pinned. 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. |
+| `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 that fixes each vulnerability, majors flagged, transitive fixes waiting on upstream. `package` for a one-package plan. |
-| `dependency_check` | Call before adding a dependency or applying a bump. 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. npm and crates.io. |
+| `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. |
+| `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
 
 | Tool | What it does |
 |------|-------------|
-| `what_should_i_know` | Pre-task briefing built from the task: the dependencies it names, their versions and confirmed vulnerabilities, majors crossed, your recorded decisions, and a delegation verdict only confirmed evidence can raise. |
+| `what_should_i_know` | Pre-task briefing built from the task: the dependencies it names (and the families it names: "all tauri plugins" adds the project's tauri-*, tauri-plugin-* and @tauri-apps/* packages; for "latest", whether each is already on the newest major), their versions and confirmed vulnerabilities, majors crossed, your recorded decisions, and a delegation verdict only confirmed evidence can raise. |
 | `ecosystem_pulse` | Hacker News headlines that name your dependencies, then your languages (labelled as such). Fetched only when called. |
 | `get_context` | Your tech stack, resolved dependency versions, interests, detected topics. |
 | `get_relevant_content`* | Scored content feed that passed the desktop app's relevance judge. |
 | `get_actionable_signals`* | Judge-accepted feed items the app classified (advisories, breaking changes), plus your live vulnerabilities. |
 | `knowledge_gaps`* | Dependencies with judge-accepted advisories or releases you have not looked at. |
-| `record_feedback`* | Save or dismiss items so 4DA can record explicit interaction history. |
+| `record_feedback`* | Save or dismiss items; recorded in the app's own feedback tables, which its calibration reads. |
 
 ### Decisions & Memory
 
@@ -204,7 +209,7 @@ The MCP server works without the desktop app. It keeps a small local database in
 | Tech stack detection + resolved versions | Yes | Yes |
 | Decision memory + alignment checking | Yes | Yes |
 | Agent memory (cross-session) | Yes | Yes |
-| Scored content feed (20+ sources) | -- | Yes |
+| Developer news judged against your stack (the app's feed) | -- | Yes |
 | Actionable signals + knowledge gaps | -- | Yes |
 | The analysis layer (Signal Chains, Knowledge Gaps, temporal analysis) | -- | Yes |
 
@@ -253,6 +258,9 @@ npx @4da/mcp-server --version    # Print version
 |----------|-------------|---------|
 | `FOURDA_DB_PATH` | Path to 4DA's SQLite database | Auto-detected |
 | `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 |
+| `FOURDA_MCP_HOME` | Folder for the files the server writes (`cache.db`, `standalone.db`) | Your user data folder + `4da-mcp` |
 | `MCP_AUTH_SECRET` | Shared secret for verifying Bearer tokens on `--http` (HMAC-SHA256). Falls back to `JWT_SECRET`. Unset means no token is accepted. | Unset |
 | `MCP_AUTH_REQUIRED` | Require auth on a **loopback** `--http` bind. Always required on a non-loopback bind. | `false` |
 | `MCP_ALLOWED_HOSTS` | Extra comma-separated hostnames accepted in `Host`/`Origin` (needed when binding to `0.0.0.0`). | localhost only |
@@ -260,10 +268,10 @@ npx @4da/mcp-server --version    # Print version
 ## FAQ
 
 **Does this send my code anywhere?**
-No. The server sends package names and versions to public APIs ([OSV.dev](https://osv.dev), npm registry, crates.io, PyPI, Go proxy), downloads the target version's archive from the package's own registry for `upgrade_impact`, and, only when you call `ecosystem_pulse`, sends a few dependency names as search terms to [HN Algolia](https://hn.algolia.com/api). No source code, no file paths, no personal data: the call-site scan runs locally. Set `FOURDA_OFFLINE=true` to disable all network calls. (The sole exception is opt-in OpenAI embeddings — see the network note above.)
+No. The server sends package names and versions to public APIs ([OSV.dev](https://osv.dev), npm registry, crates.io, PyPI, Go proxy), downloads the target version's archive from the package's own registry for `upgrade_impact` (and reads GitHub release notes only if you set `FOURDA_GITHUB_CHANGELOG=true`), and, only when you call `ecosystem_pulse`, sends a few dependency names as search terms to [HN Algolia](https://hn.algolia.com/api). No source code, no file paths, no personal data: the call-site scan runs locally. Set `FOURDA_OFFLINE=true` to disable all network calls. (The sole exception is opt-in OpenAI embeddings — see the network note above.)
 
 **Do I need the 4DA desktop app?**
-No. 11 tools work standalone: upgrade impact, pre-install dependency checks, vulnerability scanning, dependency health, upgrade planning, ecosystem news, pre-task briefings, project context, decision memory, alignment checking, and agent memory. The desktop app adds a scored content feed from 20+ sources, judged against your actual stack.
+No. 11 tools work standalone: upgrade impact, pre-install dependency checks, vulnerability scanning, dependency health, upgrade planning, ecosystem news, pre-task briefings, project context, decision memory, alignment checking, and agent memory. The desktop app is where the same engine runs day to day: one worklist across every project on the machine, a morning Brief of what changed in your stack, and an Upgrade Plan. With it installed, your agent also gets 5 more tools: signals, knowledge gaps, developer news judged against your stack, Developer DNA and feedback.
 
 **Which AI tools does this work with?**
 Any tool that supports [MCP](https://modelcontextprotocol.io): Claude Code, Claude Desktop, Cursor, Windsurf, VS Code (Copilot), and any custom MCP client.