@4da/mcp-server 5.0.4 → 6.0.1

package/CHANGELOG.md

@@ -0,0 +1,698 @@
+# Changelog
+
+## 6.0.1 — 2026-10-04
+
+### The server has its own repository
+
+`@4da/mcp-server` now lives at
+[github.com/4DA-Systems/4da-mcp-server](https://github.com/4DA-Systems/4da-mcp-server),
+with its full history, instead of a folder of the 4DA desktop app's monorepo.
+Issues, releases and the Claude Code plugin marketplace move with it:
+
+```bash
+claude plugin marketplace add 4DA-Systems/4da-mcp-server
+claude plugin install 4da@4da
+```
+
+The package, its name in the MCP Registry (`io.github.4DA-Systems/4da-mcp-server`)
+and every tool are unchanged.
+
+- **Published with provenance.** Releases are built and published from this
+  repository's `release.yml` through npm trusted publishing, so each version
+  carries a SLSA provenance attestation tying it to the commit it was built from.
+- **App-schema contract.** The server reads the desktop app's database, which
+  is now maintained in a different repository. `pnpm run contract` checks every
+  statement the server issues, and every column it probes for, against the
+  schema the app's migrations produce (`contract/app-schema.sql`, generated in
+  the app's CI). The app's CI runs the same check before a migration merges.
+- **Removed dead code.** `explainRelevance`, `getSourceItem`,
+  `recordAgentFeedback` and `getAgentFeedbackStats` had no callers since their
+  tools were removed; the standalone schema no longer creates the unused
+  `agent_feedback` table.
+- The Claude Code plugin pins the exact server version it was released with.
+
+## 6.0.0 — 2026-10-02
+
+### New: `upgrade_impact`
+
+What changes between the version you run and the one you want, for one npm
+or crates.io dependency: the releases in between (publish dates, npm
+deprecations, crates yanks), the changelog shipped inside the target
+version's own registry archive with every entry classified breaking /
+deprecation / security, the breaking entries that mention symbols your code
+imports from the package (`touches_your_code`), the files that import it, and
+the advisories the upgrade fixes or leaves. Only the package's registry and
+OSV.dev are contacted; when the archive ships no changelog (fastembed, vite and
+zod do not) the answer says so and gives the release-notes URL instead of
+guessing.
+
+Breaking changes in string literals are found too: the old syntax a breaking
+entry names (axum 0.8's `/:single` -> `/{single}`) is matched in the
+importing files' route and pattern strings, with file and line
+(`matched_literals`).
+
+Every entry carries the heading or parent bullet it sits under (`under`):
+"`rt::{Arbiter}` re-exports." means nothing until you see it sits under
+"Removed". Concise output keeps up to 20 plain changes per release under API
+or neutral headings ("Changed", "Methods", "Types") and 3 under additive ones,
+and says how many it left out.
+
+How far the "breaking" flags go, measured: five corpora of real upgrades,
+each rated blind by three independent raters. The last, 47 upgrades never
+used to build the rules, rated by raters who saw each entry's heading
+(Fleiss kappa 0.982), is the release measurement: 98.6% of entries flagged
+breaking were breaking (95% CI 94.9-99.6%) and about 65% of breaking entries
+were flagged. Earlier fresh corpora, before the last parser fixes, measured
+73-87%, so the summary says "flagged", every answer states the measurement in
+`_meta.classification`, and the agent is told to read every entry of a major
+upgrade. Counts are `null` when the changelog has no entry for the releases
+crossed, and labelled lower bounds when it covers only some. Changelog formats
+read: keep-a-changelog and changesets headings, category headings at the
+release's own level (date-fns), plain and bold label lines, releases as
+bullets (indexmap), History.md label lists (express), day-first dates (knex),
+RELEASE-NOTES.md (base64); layout markup (`<details>`) is skipped.
+
+### New: `dependency_check` — a verdict before you add or bump a dependency
+
+An agent calls it with up to 25 `{ ecosystem, package, to, from? }` items (npm
+and crates.io) before it edits a manifest; `to: "latest"` checks the newest
+stable release and reports which version that was (`to_requested`). Each item gets `proceed`, `wait`,
+`review`, `avoid` or `unknown`, a one-line reason, and the signals behind it,
+each with evidence: known OSV advisories on the target (and the ones the change
+fixes), release age (under 3 days is `wait`, unless the release fixes an
+advisory affecting the installed version), a drop in publish trust (trusted
+publisher > provenance attestation > neither), npm install scripts the target
+adds, runtime dependencies the target adds that were themselves first published
+under 30 days earlier, yanked / deprecated / unpublished targets, and the
+upgrade type. Against the axios 1.14.0 -> 1.14.1 compromise shape (token
+publish replacing a trusted publisher, plus a dependency created the day
+before) it answers `review` on both counts. A registry or OSV that cannot be
+reached gives `unknown`, never `proceed`; a name missing from the public
+registry says it may be private, misspelled or hallucinated.
+
+Registry requests carry the package name only. The installed and target
+versions are picked out of the full release list locally: npm's full packument
+(cached on disk with its ETag and revalidated with `If-None-Match`) and the
+crates.io versions API (spaced one request per second, with a descriptive
+User-Agent) plus the sparse index for per-version dependencies.
+
+### New: the `deps` prompt
+
+The server now declares the MCP `prompts` capability. `deps` is a user-invoked
+workflow: plan with `upgrade_planner`, vet each bump with `dependency_check`,
+apply only `proceed` items in small batches with the project's tests after
+each, report everything else with its evidence, and re-run
+`vulnerability_scan` at the end.
+
+### New: a Claude Code plugin, with a hook on dependency edits
+
+Install with `claude plugin marketplace add 4DA-Systems/4DA --sparse
+.claude-plugin mcp-4da-server` and `claude plugin install 4da@4da` (the
+repository now carries the marketplace manifest the plugin needed to be
+installable at all). After an Edit or MultiEdit that changes a dependency's
+version in `package.json`, `Cargo.toml`, `pyproject.toml`, `requirements.txt`
+or `go.mod`, the agent is told which packages moved and given the exact
+`dependency_check` and `upgrade_impact` calls. A tool is called when the agent
+thinks to; a hook fires on the edit itself. Plain Node, no network, silent for
+every other edit, and it can never fail the edit. Verified end to end in a real
+Claude Code session: the hook's context reaches the agent on the edit.
+
+### Fixed: the vulnerability scan read lockfiles losslessly
+
+Measured against osv-scanner on 12 projects, the matching was exact but the
+lockfile reading lost findings (precision 0.74, recall 0.48 per advisory). Now
+precision 1.00, recall 0.995:
+- every installed copy is scanned, not one version per package name (nested
+  npm copies, two versions of a crate: 4DA's own `rsa 0.9.10` was missed);
+- npm/pnpm/Pipfile/poetry dev flags make a transitive's dev scope known;
+- Go: full pseudo-versions and `+incompatible`, `replace` directives, Go's build
+  list from `go.mod` (and `go.sum` before go 1.17);
+- `requirements.txt` extras, dotted names, markers, comments and `--hash`
+  options; `poetry.lock` of any vintage, `uv.lock`, Poetry and PEP 621 manifests;
+- Cargo virtual workspaces, and standalone mode scans every independently
+  locked project under the root, honouring `.gitignore`;
+- `bun.lock` (Bun 1.2+), with dev scope from the workspaces;
+- PEP 440 version order and PEP 503 names when choosing the fix version.
+
+Before release the scan was re-run, from the packed tarball installed fresh,
+on those 12 projects and on 11 more never used to build the readers (npm,
+yarn v1, pnpm, bun, Cargo, Go, uv, Pipfile, Poetry): every project matches
+osv-scanner or an independent oracle (OSV queried directly; Go's own
+`go list -m all` build list, where the server reports modules osv-scanner
+misses). The only misses are transitives of a `requirements.txt` without a
+lockfile, documented below. Eight projects locked at current releases report
+zero findings.
+
+### Changed: answers only confirmed evidence can raise
+
+- `what_should_i_know` is built from the task: the dependencies it names,
+  their installed versions, version-confirmed vulnerabilities, majors crossed.
+  Feed headlines no longer drive the delegation verdict (a security keyword
+  in an arXiv paper or in OpenAI company news forced `human_only` for any task).
+- `get_actionable_signals` no longer classifies items by keyword; it shows the
+  desktop app's classifications only when its relevance judge accepted the item,
+  and a headline is never above medium unless it comes from an advisory database.
+- `get_relevant_content` and `knowledge_gaps` leave out judge-rejected items.
+- `upgrade_planner` targets the smallest version that fixes the advisories, not
+  the newest major; unmaintained-package notices are not counted as CVEs. It
+  and `dependency_health` run the OSV scan themselves when none has run (they
+  answered "run vulnerability_scan first", leaving the first answer of a
+  session CVE-blind),
+  and `package` finds a vulnerable transitive instead of calling it "not a
+  dependency".
+- `vulnerability_scan` takes `package`: one dependency's findings across every
+  installed copy, with a `package_note` saying what the lockfiles hold for it.
+  An agent asked about one transitive otherwise read the whole report.
+- A scan that finishes late no longer replaces a newer one: the startup scan
+  (devDependencies left out) could overwrite an agent's `include_dev` scan, and
+  the planner then sent the devDependency node-fetch 2.6.0 to the ESM-only 3.3.2
+  with no advisories (2 runs in 6). A plan or briefing that needs
+  devDependencies covered scans at that scope instead of reading a narrower scan.
+- Desktop mode finds the app's database on Linux (`$XDG_DATA_HOME/4da/data`, as
+  the app writes it) and honours the app's `FOURDA_DATA_DIR`.
+
+### Changed: the protocol surface
+
+- Every tool now lists all its parameters in `tools/list` (most were hidden).
+- Server `instructions` for hosts with tool search; argument errors come back as
+  `isError` with the fix; `structuredContent` beside the text; compact JSON;
+  invisible and control characters stripped from third-party text.
+- `tools/list` no longer waits for the project scan (6.6 s measured).
+- `agent_memory` and `decision_memory` match their published schemas (recall
+  takes `query`, store takes `subject`; the old schema could not be followed).
+
+### Breaking
+
+- Node.js 22 or later. better-sqlite3 publishes no Node 20 binary from 12.10,
+  so a Node 20 install compiled from source and failed on any machine without
+  Python and a C++ toolchain (every slim container); Node 20 reached end of
+  life in April 2026. Verified installs: Node 20 (with a toolchain), 22 and 24
+  on Windows; Node 22 on Debian and Alpine Linux; Node 24 on Debian.
+- npm 12 blocks dependency install scripts unless allowed, so better-sqlite3
+  is left unbuilt by both `npx` and `npm install`. `--doctor` now opens a
+  database instead of trusting the import; it had reported the bindings as
+  loaded while every tool failed with "Could not locate the bindings file".
+  That error now carries the fix: `npm config set
+  allow-scripts=better-sqlite3 --location=user` and `npx clear-npx-cache`, or
+  `npm install-scripts approve better-sqlite3` and `npm rebuild
+  better-sqlite3`. Each was verified on npm 12.2.0. npm 10 and 11, which every
+  current Node release ships, are not affected.
+- `upgrade_impact`'s summary says "N entries flagged breaking", not "N
+  breaking changes": the flags are a pre-sort, and every entry now carries its
+  heading (`under`).
+- `vulnerability_scan` answers in a concise form by default: `vulnerable_packages`
+  has one row per vulnerable package version (worst severity, the version that
+  fixes all its advisories, advisory count and first ids), the 40 most severe,
+  with 25 recommendations and a count of anything left out. `by_severity` still
+  counts every advisory. Pass `response_format: "detailed"` for the previous
+  full report, one row per advisory. One row per advisory came to about 25k
+  tokens on large projects, the size at which Claude Code cuts a tool answer
+  off.
+- `get_actionable_signals` returns fewer items: unclassified and judge-rejected
+  ones are gone by design.
+- Tool schemas are no longer separate JSON files (`dist/schemas/`); the
+  `4da://schema/<tool>` resources serve them from the tool definitions.
+- A standalone database is created in the user data folder, not in
+  `<cwd>/data/4da.db`. An existing one there is still found and used.
+- Hacker News is contacted only when `ecosystem_pulse` is called, never at startup.
+
+### Changed: `upgrade_planner` returns the 4DA app's plan when there is one
+
+The tool used to compute its own plan from the lockfiles in the current
+directory, even on a machine where the 4DA app had already computed one. An
+agent could be told a different target than the app showed for the same
+install. When the app's database holds its persisted Upgrade Plan (schema 4),
+the tool now returns that plan's work order with `provenance.mode: "app_plan"`:
+one step per package, keyed by the app's item id, with the ecosystem, each
+installed version and its minimum clean target, the upgrade type
+(patch/minor/major), the projects holding it (direct or transitive, dev or
+not) and the mechanism. `manifest_bump` means edit the manifest;
+`lockfile_or_parent_update` means the package is only transitive, so update its
+parent or refresh the lockfile rather than adding it as a direct dependency.
+Past the plan's `expires_at` the result says `stale: true` and is still the
+app's plan. Without a usable plan (no app database, nothing computed yet, or a
+snapshot from another app version) the tool runs the standalone heuristic as
+before and says why in `appPlanUnavailable`. The server reads the plan; it
+does not reimplement the app's matching. `package` narrows either plan to one
+package.
+
+## 5.1.0 — 2026-09-11
+
+### Fixed: scoped packages in pnpm and yarn lockfiles were never scanned
+
+`vulnerability_scan` asked OSV about `'@humanfs/node`, with a leading quote,
+instead of `@humanfs/node`. So GHSA-p498-v437-472g never appeared, although it
+was open as Dependabot alert 340 on this repository and the app showed it. The
+pnpm reader matched package keys with a pattern whose `\s` crossed the blank
+line pnpm writes between entries, and so kept the next key's quote. Every
+scoped package outside the importer blocks was affected: 525 names across five
+lockfiles in this repository (measured 2026-09-11). The test fixture had no
+blank lines, so it passed. The reader now matches keys by column on whole
+lines, reads pnpm lockfile v5, v6 and v9, and drops keys that pin no registry
+version (git, tarball, file) instead of querying them as names. The yarn
+reader could not match a header that starts with `@`, so it dropped every
+scoped package, and it never read yarn berry's `version: x` lines. Both are
+fixed. Expect more findings on a pnpm or yarn project after upgrading; they
+were always there.
+
+### Fixed: a patched lockfile no longer hides a vulnerable node_modules
+
+`mcp-4da-server/pnpm-lock.yaml` pinned hono 4.13.5 (the fix for
+CVE-2026-84363/-84364/-84365) while `mcp-4da-server/node_modules` held 4.13.1
+for 25 days, because activation ran `pnpm install` only at the repo root.
+Every 4DA surface reads the lockfile, so every surface reported hono fixed
+while the vulnerable copy was the one that ran (measured 2026-09-10). For npm
+direct dependencies resolved from a lockfile, the server now reads
+`node_modules/<name>/package.json` (scoped names included; hoisted workspaces
+by walking up to the repository root, at most six levels). A directory with
+no `node_modules` of its own is skipped, and a manifest-only resolution is
+never compared, because a specifier floor is not a pin. When the installed
+version differs, OSV is asked about the installed version too, so the answer
+is OSV's, not a guess.
+
+`vulnerability_scan` gains `install_drift: [{ package, dir, lockfile_version,
+installed_version, vulnerable_installed, lockfile_version_vulnerable, fix,
+note }]`, where `fix` is `pnpm install`, `npm ci` or `yarn install` according
+to the lockfile that pinned the version. Each affected vulnerability carries
+`installed_version`, `lockfile_version` and an `install_note` ("the lockfile
+is patched but node_modules still has 4.13.1 — run `pnpm install`"), and the
+recommendation is the reinstall, not an upgrade the lockfile is already past.
+`what_should_i_know` names a vulnerable installed copy with its reinstall
+command whatever the task, so the verdict is at least `review_needed` and
+never clean. That advisory is graded the way the app grades its install-drift
+row: high when the reinstall clears an advisory the running copy has (the
+hono case, though its three advisories are medium on their own), medium when
+the lockfile's pinned version is exposed too. `dependency_health` and `upgrade_planner` show `installedVersion`
+beside `currentVersion`, and `upgrade_planner` turns a drift-only row into a
+`reinstall` step. Expect `install_drift: []` on a healthy checkout.
+
+### Fixed: a long-running server answered for the dependency set it saw at startup
+
+Three server processes were live on the founder machine. Two had started
+before the pull that brought hono 4.13.5, and `vulnerability_scan` from one
+of them reported hono 4.13.3 (the lockfile at its start) with
+`_meta.cached: false`: versions were resolved once at init and never again,
+and `cached` only ever described the OSV lookup. Each resolution group now
+records the files it read as stat signatures (every lockfile candidate,
+present or absent; the manifest when the resolver fell back to it; for npm,
+the node_modules install state). `vulnerability_scan`, `what_should_i_know`,
+`dependency_health`, `upgrade_planner` and the briefing's scan wait re-run the
+same resolution when one changes, and drop the stored scan and the warmup so
+no answer describes a dependency set that no longer exists. Stat calls only:
+no timers, no watchers. The cargo host-platform memo is keyed on
+`Cargo.lock`/`Cargo.toml` too, so a re-resolution cannot mark newly added
+crates as not built on this host.
+
+### Added: resolution provenance
+
+`vulnerability_scan`'s `_meta` gains `resolution: { resolved_at, lockfiles:
+[{ path, kind, mtime }], re_resolved_this_call, note }` and `osv_cached` (the
+same value as `cached`, which stays for compatibility). The tool description
+now says that `cached` refers to the OSV advisory lookup, not to dependency
+resolution. `what_should_i_know` gains a `scan` block (`status`,
+`scanned_at`, `resolved_at`, `re_resolved_this_call`); `scan_status` stays.
+
+### Changed: one severity rule with the desktop app (AD-046)
+
+`vulnerability_scan` graded `sandbox@3.1.2`, a transitive of paddle-webhook
+whose dev/runtime scope is unknown, critical (`by_severity.critical: 1`; the
+briefing said "CRITICAL: Sandbox Breakout"), while the app graded the same
+advisory High. Every surface now presents one grade, the rule the app uses
+(`osv::identity::scope_adjusted_urgency`): a transitive-only dependency caps
+critical at high, then a dev-only dependency drops one level (critical to
+high, high to medium, medium to low; low and unknown stay). Unknown dev scope
+gets no discount. Applied in `vulnerability_scan`, `what_should_i_know` and
+`get_actionable_signals`; `severity_filter` and sorting use the presented
+grade. Nothing is hidden: every entry keeps the advisory's own tier as
+`advisory_severity` (with a `severity_note` when the two differ),
+`by_severity` counts the presented grade, and the new `advisory_by_severity`
+counts the raw tiers.
+
+In full-database mode a transitive's dev scope comes from the app's
+`dependency_instances` table. Only a real determination counts (`is_dev = 1`,
+or a `scope` of runtime, dev or build); the app's placeholder rows
+(`is_dev = 0, scope = 'unknown'`) stay unknown. Without `include_dev`, only
+direct devDependencies are left out of the scan: a transitive of known dev
+scope is graded down, not dropped, and one of unknown scope is no longer
+hidden because a direct devDependency shares its name.
+
+### Added: the database-recovery voice in data_freshness
+
+When the headless refresh engine restores `4da.db` from a backup, or
+quarantines it and starts a fresh empty one, it leaves `data/.db-recovered`
+beside it. A fresh database looks fresh by every other freshness field.
+`data_freshness` now surfaces the marker the way it surfaces `.engine-blocked`:
+`db_recovered_at`, `db_recovery_kind`, `db_recovery_detail`, and a note ("The
+database was restored from a backup / replaced with a fresh empty database by
+the background refresh at … — results may be incomplete or empty; the
+preserved file is …"). Read-only: the desktop app shows the marker once and
+deletes it.
+
+### Changed: ranked reads break ties by id
+
+`get_relevant_content` orders by `COALESCE(rank_score, relevance_score) DESC,
+id DESC`, mirroring the app's `RANKED_ORDER_EXPR`. 100 of 651 surfaced items
+sat at exactly 0.5000 (a hard score cap), and their order was whatever SQLite
+emitted.
+
+### Changed: dependency_health says when it has no CVE data
+
+`dependency_health` no longer says "all healthy" without a vulnerability scan
+behind it, and says so when CVE data is not loaded (no scan yet, or the
+dependencies changed since the last one).
+
+### Fixed: the briefing never answers "safe" without a vulnerability scan
+
+`what_should_i_know` awaited nothing. In full-database mode the live layer was
+initialised without a vulnerability scan, so the first call after start read
+an empty cache and reported `safe_to_delegate` for a task that named a package
+with an open advisory (verified live 2026-09-07: 0 advisories at t+0, 11 at
+t+7 min). The scan now warms at server start, the briefing awaits it (bounded,
+8 s), and the result carries `scan_status` (`ready` | `unavailable` |
+`disabled`). Without a ready scan the delegation level is the new `"unknown"`
+— treat the task as unreviewed, never as safe; `safe_to_delegate` is only
+emitted over a ready scan. Existing `human_only` evidence still wins.
+
+Security signals now also come through a 30-day feed pass (`since_hours` max
+raised from 168 to 720; windows past 7 days keep the current-pipeline-version
+guard), so a three-day-old advisory is no longer cut by the 72-hour window. A
+relevant security or breaking-change advisory yields at least `review_needed`.
+
+### Fixed: one signal per vulnerability
+
+`get_actionable_signals` injected one live signal per OSV record, so a
+GHSA/RUSTSEC pair for one bug read as two problems. Alias-connected records
+are clustered (union-find, scoped to package + version) and emitted once,
+every id in `triggers`. Platform-inactive advisories and maintenance notices
+drop to `low` with an explanatory action, and the briefing does not read them.
+
+A `signal_type` filter is now pushed into the database read: the general read
+is capped at the top 200 ranked items across every type, and on the live
+corpus that cap starved a security-only pass (both in-window stored security
+alerts ranked 299th and 582nd). The pipeline's stored priority vocabulary
+(`critical` / `alert` / `advisory` / `watch`) is mapped onto the tool's tiers
+instead of cast through unchanged — 92 of 93 stamped rows carried a priority
+no filter, sort, or briefing rule recognised.
+
+### Fixed: knowledge_gaps coverage and grading
+
+- Every direct dependency is scanned (a `LIMIT 100` left 43 of 143 live
+  dependencies unexamined); candidate items are loaded once.
+- Registry rows (`crates_io`, `npm_registry`, `pypi`, `go_modules`) are version
+  updates and grade `medium` regardless of title words — when the row is newer
+  than the installed version (the row for the version you run is not a gap).
+- An advisory names a dependency when the dependency is its subject package
+  (`[ID] package: …`), not when the title merely contains the word: `url` was
+  graded critical on a SurrealDB advisory ("via URL path"), `hmac` on a
+  Phalcon one.
+- An advisory the installed version is positively inside survives the 90-day
+  publish-date cut; unknown exposure does not exempt.
+- `osv_advisories` is consulted for the dependency's own ecosystem (the npm
+  and crates.io `jsonwebtoken` were being conflated).
+
+### Fixed: dependency_health counts vulnerable packages the way vulnerability_scan does
+
+`vulnerableCount` is the actionable set (built on this host, not a maintenance
+notice); `advisoryCount` reports every row so nothing is hidden. The health
+penalty and severity breakdown follow the same set.
+
+## 5.0.4 (2026-08-24)
+
+### Fixed: vulnerability_scan could recommend a downgrade
+
+`fixed_version` selection took the first OSV range's fix regardless of which
+range contains the installed version — live consequence: "Upgrade undici to
+6.28.0" while on 7.28.0. Selection is now branch-aware (the fix comes from the
+range containing the installed version), with a hard guard that a
+recommendation is never below the installed version — if no fix at or above it
+exists, the honest "no fix version published" line is emitted instead.
+
+### Changed: ranked reads follow the app's evidence/rank split
+
+`get_relevant_content` orders by `COALESCE(rank_score, relevance_score)`
+(schema 110, guarded for older databases); membership thresholds stay on the
+evidence score.
+
+## 5.0.3 (2026-08-23)
+
+### Fixed: standalone mode broke on its second session (critical)
+
+The minimal standalone schema created `dependencies` without the `is_direct`
+column, while the live-intelligence init queried it. Session 1 of a standalone
+install worked (fresh scan); session 2+ threw on init, the error was swallowed,
+and `vulnerability_scan` / `dependency_health` / `upgrade_planner` silently
+reported "no project detected" — blaming the user's setup. The column is now in
+the minimal schema and an `ensureColumn` upgrade heals existing standalone DBs
+on open.
+
+### Fixed: grounded tool output
+
+- `knowledge_gaps`: word-boundary matching with relevance/recency guards and
+  honest severity (previously substring matches like "invite" → vite, and
+  everything reported "critical").
+- `ecosystem_pulse`: returns headlines again (dependency prefetch + on-demand
+  fetch + 14-day recency window; previously reproducibly empty).
+- `what_should_i_know`: the decision-windows section was dead (ordered by a
+  column that does not exist on that table — `created_at` vs `opened_at`).
+- Version logic: no more prerelease "upgrades" (rsa 0.10.0-rc downgrade) or
+  phantom stable versions (React "19.0.8") — stable-semver comparison
+  throughout.
+- `dependency_health`: healthScore is proportional instead of collapsing to
+  0/100; feed output deduplicated (title similarity).
+
+### Changed: tools/list serves real schemas for required-param tools (AD-032)
+
+Tools whose schema declares required parameters (`record_feedback`,
+`decision_memory`, `agent_memory`, `check_decision_alignment`,
+`what_should_i_know`) now serve their real `inputSchema` in `tools/list` —
+the slim `{"type":"object"}` made them uncallable for clients that never read
+MCP Resources. All-optional tools stay slim; full schemas remain available at
+`4da://schema/{tool}`.
+
+## 5.0.2 (2026-08-17)
+
+### Docs: republish so npm serves the corrected README
+
+No code changes. 5.0.1 was published to npm on 2026-08-16 minutes before the
+AD-030 copy retirement (#469) landed the corrected README, so the npm package
+page still described "Compound intelligence (learns over time)" and content that "compounds over time" — claims the product retired. <!-- retired-ok: quotes the retired claims verbatim to document exactly what this republish removed from npm -->
+This release exists to put the current README (and the corrected app-vs-MCP
+comparison) on npm.
+
+## 5.0.1 (2026-08-16)
+
+### Security: HTTP transport accepted forged authentication tokens
+
+**Affects `--http` only. The default stdio transport was never exposed.**
+
+`extractAuthClaims` decoded the JWT payload and validated the claims inside it
+but never read the signature segment — no HMAC was ever computed, despite the
+function's own docstring claiming "HMAC-SHA256 verification against the shared
+relay secret". Any request could present
+`Authorization: Bearer x.<base64url({"team_id":"x","client_id":"y","role":"admin","exp":9999999999})>.x`
+and be accepted as a team admin.
+
+Three defects compounded it:
+
+- The transport's header claimed "Binds to 127.0.0.1 only", but `--host`
+  accepted any address, so `--http --host 0.0.0.0` served all 14 tools to the
+  network.
+- The DNS rebinding guard was written as `if (origin) { ...check... }`, so a
+  request with **no** `Origin` header — every non-browser client, and any
+  attacker — skipped it entirely.
+- `hasPermission()` existed but was never called, so even legitimate tokens got
+  no role enforcement: a `viewer` could invoke every write tool.
+
+Fixed:
+
+- **Real signature verification.** HMAC-SHA256 over
+  `base64url(header).base64url(payload)`, constant-time compared
+  (`crypto.timingSafeEqual`) against the shared secret, **before** any claim is
+  read. The algorithm is pinned to `HS256`, so `alg: none`, other HMAC widths,
+  and asymmetric-algorithm confusion are all refused. `exp` is now mandatory
+  (a signed token with no expiry is a permanent credential) and `nbf` is
+  honoured, both with the issuer's 60s leeway. No new dependency — Node's
+  built-in `node:crypto`.
+- **Fail closed.** With no secret configured (`MCP_AUTH_SECRET`, falling back
+  to `JWT_SECRET` for parity with a co-deployed relay), *every* token is
+  rejected. A server that cannot verify a signature must not trust claims.
+- **Host-header DNS rebinding guard on every request**, using the SDK's
+  `validateHostHeader`/`validateOriginHeader`. `Host` is mandatory, so the
+  check can no longer be skipped by omitting a header; a foreign `Origin` is
+  still refused when present.
+- **Safe `--host`.** 127.0.0.1 remains the default. A non-loopback bind is
+  **refused at startup** unless a secret is configured, prints a warning
+  banner, and forces authentication on for every request regardless of
+  `MCP_AUTH_REQUIRED`.
+- **Role enforcement wired up.** Every tool call is checked against the
+  verified role via the registry's existing `readOnlyHint` annotation:
+  `viewer` = read-only, `member`/`admin` = read + write. Unknown tools fail
+  closed as writes.
+- Removed `isNetworkTierAllowed()` — dead code with no tier data anywhere in
+  this package.
+
+**Behaviour change:** an existing `--http --host 0.0.0.0` deployment will now
+refuse to start until `MCP_AUTH_SECRET` is set, and only accepts localhost-class
+`Host` headers unless `MCP_ALLOWED_HOSTS` names the address clients use. This is
+deliberate: that deployment was previously reachable by anyone with forgeable
+admin credentials.
+
+## 5.0.0 (2026-08-11)
+
+### Breaking: Node.js 20+ required
+
+The server now requires Node.js >= 20 (previously >= 18; Node 18 has been EOL
+since April 2025). No tool behavior changes.
+
+### Changed: migrated to MCP TypeScript SDK v2 + 2026-07-28 protocol support
+
+Replaced the discontinued `@modelcontextprotocol/sdk` v1 with the v2 packages
+(`@modelcontextprotocol/server` + `@modelcontextprotocol/node`) and moved both
+transports onto the v2 serving entries:
+
+- **stdio** now goes through `serveStdio`, which negotiates the protocol era
+  per connection: 2025-era hosts (Claude Code, Claude Desktop, Cursor — the
+  classic `initialize` handshake) are served exactly as before, and hosts
+  speaking the new stateless 2026-07-28 revision (`server/discover`) are now
+  supported on the same endpoint.
+- **--http** now goes through `createMcpHandler` + `toNodeHandler`: stateless
+  serving for both eras from one factory — the previous per-request transport
+  wiring is gone. Health endpoint, localhost binding, Origin-header DNS
+  rebinding protection, and the optional JWT auth gate are unchanged.
+
+Existing clients need no changes — protocol version negotiation is untouched
+for 2025-era hosts and verified against a v1-SDK client.
+
+### Fixed: startup log reported a stale version
+
+The stdio startup line hardcoded "v4.6.3" regardless of the installed version;
+it now derives from package.json like `--version` and `serverInfo`.
+
+## 4.6.2 (2026-06-17)
+
+### Fixed: vulnerability_scan returned empty severity, fix versions, and summaries
+
+The scanner enumerated advisories via OSV's `/v1/querybatch` endpoint, which returns
+only `{ id, modified }` per vulnerability — but it then mapped that index-only object
+as if it were the full record. Every rich field collapsed to a default: `summary`
+became the bare advisory ID, `fixed_version` was always `null` (so every
+recommendation read "no fix version published"), `references` was always empty,
+`published` actually carried the *modified* timestamp, and severity was hardcoded
+(`medium` for any GHSA, `unknown` for anything else) rather than derived.
+
+The scanner now hydrates each matched advisory via `/v1/vulns/{id}` (cache-first,
+24h TTL, bounded concurrency over the vulnerable subset only) and derives severity
+honestly: a CVSS base score — computed from the vector string when OSV provides one
+(new `cvss.ts`, CVSS v3.0/3.1) — wins, then the GitHub-advisory severity label, then
+`unknown`. No more fabricated default buckets. Real fix versions, CVE aliases,
+summaries, and reference links now flow through.
+
+## 4.6.1 (2026-06-11)
+
+### Improved: prescriptive tool descriptions
+
+All 14 tool descriptions now state WHEN to call the tool, not just what it does
+(e.g. "Call when the user asks about security, vulnerabilities, or CVEs"). Both the
+slim tool list and the full schemas carry explicit triggers, so calling models select
+the right tool more reliably. A regression test enforces this going forward.
+
+### Changed: license
+
+Relicensed to Apache-2.0 (from MIT). The 4DA desktop app remains under
+FSL-1.1-Apache-2.0; this MCP connector is intentionally permissive to maximize adoption.
+
+## 4.6.0 (2026-04-24)
+
+### Breaking: Tool consolidation — 39 → 14 tools
+
+Removed 25 tools that returned empty, broken, or low-value data through MCP.
+Every remaining tool reliably returns useful, actionable information.
+
+**Kept (14):**
+- `vulnerability_scan` — live CVE scanning (standalone)
+- `dependency_health` — health score + version freshness (standalone)
+- `upgrade_planner` — ranked upgrade recommendations (standalone)
+- `what_should_i_know` — pre-task intelligence briefing (standalone)
+- `ecosystem_pulse` — filtered ecosystem news (standalone)
+- `get_context` — tech stack + interests (standalone)
+- `get_relevant_content` — scored content feed (full mode)
+- `get_actionable_signals` — classified alerts (full mode)
+- `knowledge_gaps` — dependency blind spots (full mode)
+<!-- retired-ok: historical release notes — describes that release's tool list verbatim -->
+- `record_feedback` — save/dismiss to teach the system (full mode)
+- `decision_memory` — persistent architectural decisions (standalone)
+- `check_decision_alignment` — verify tech choices (standalone)
+- `agent_memory` — cross-session persistent memory (standalone)
+- `developer_dna` — tech identity profile (full mode)
+
+**Removed:** explain_relevance, score_autopsy, trend_analysis, daily_briefing,
+context_analysis, topic_connections, signal_chains, semantic_shifts,
+attention_report, source_health, config_validator, llm_status,
+export_context_packet, reverse_mentions, project_health, tech_radar,
+agent_session_brief, delegation_score, autophagy_status, decision_windows,
+compound_advantage, record_agent_feedback, get_agent_feedback_stats,
+trust_summary, preemption_feed
+
+**Fixed:**
+- `get_relevant_content` now uses Rust-computed PASIFA scores when the desktop
+  app database is present, instead of the simplified TypeScript keyword scorer.
+  Results are dramatically more accurate.
+
+## 1.0.0 (2026-02-27)
+
+Initial public release.
+
+### Tools (27)
+
+**Content & Scoring**
+- `get_relevant_content` — Query filtered content by relevance, source, time
+- `explain_relevance` — Understand why an item scored the way it did
+- `record_feedback` — Teach 4DA what you like/dislike (click, save, dismiss)
+- `score_autopsy` — Deep forensic analysis of relevance scores
+
+**Intelligence & Analysis**
+- `daily_briefing` — Executive summary of discoveries
+- `trend_analysis` — Statistical patterns, anomalies, and predictions
+- `get_actionable_signals` — Classify content into actionable signals with priority levels
+- `signal_chains` — Get causal signal chains connecting related events over time
+- `semantic_shifts` — Detect narrative shifts in topics you follow
+- `topic_connections` — Build knowledge graphs from content
+
+**Developer Context**
+- `get_context` — Get user's interests, tech stack, learned affinities
+- `context_analysis` — Optimize your context for better relevance
+- `knowledge_gaps` — Detect knowledge gaps in your project dependencies
+- `project_health` — Project health radar for dependency freshness and security
+- `reverse_mentions` — Find where your projects are mentioned in sources
+- `attention_report` — Analyze attention allocation vs codebase needs
+- `developer_dna` — Export your Developer DNA — tech identity, dependencies, engagement, blind spots
+
+**Decision & Memory**
+- `decision_memory` — Manage developer decisions (record, list, check, update, supersede)
+- `tech_radar` — Generate tech radar from decisions and content signals
+- `check_decision_alignment` — Check if a technology aligns with active decisions
+- `decision_windows` — View time-bounded opportunities requiring attention
+- `compound_advantage` — Measures intelligence leverage for decisions
+
+**Agent Integration**
+- `agent_memory` — Cross-agent persistent memory — store and recall across sessions
+- `agent_session_brief` — Tailored session startup context for AI agents
+- `delegation_score` — Should the agent proceed or ask the human?
+- `export_context_packet` — Generate portable context packet for session handoff
+
+**System**
+- `source_health` — Diagnose source fetching and data quality issues
+- `config_validator` — Validate configuration and detect issues
+- `llm_status` — Check LLM/Ollama configuration and availability
+- `autophagy_status` — Intelligence metabolism status — calibration accuracy, anti-patterns
+
+### Features
+
+- 11 content sources: Hacker News, Reddit, Twitter/X, GitHub, RSS, YouTube, arXiv, Dev.to, Lobsters, Product Hunt, custom feeds
+- PASIFA scoring algorithm — 5-axis codebase-aware relevance with confidence calibration
+- Privacy-first — local SQLite reads; the only outbound call is vulnerability_scan (package names + versions to OSV.dev), zero telemetry
+- BYOK — bring your own API keys, never stored remotely
+- Works offline with Ollama fallback for embeddings
+- Dual transport: stdio (default) and Streamable HTTP
+- SQLite storage with automatic migrations
+- Compatible with Claude Code, Cursor, Windsurf, VS Code Copilot, and any MCP client