rag-memory-epf-mcp 5.3.0-rc.1 → 5.3.0

package/README.md

@@ -153,7 +153,8 @@ storeDocument(id, content, metadata)
 
 ## Changelog
 
-### v5.3.0-rc.1
+### v5.3.0
+- (Published first as `5.3.0-rc.1` on the `next` dist-tag; promoted to `latest` after a canary run of the published artifact against a real project database: default call carries no `graph_boost` and equals explicit `useGraph:false`, the known-item probe from the 2026-08-17 measurement returns the correct gotcha at rank 1, opt-in `true` still exposes `graph_boost`, schema/MCP defaults read `false`.)
 - **Behavior change — `hybridSearch` graph re-ranking is now opt-in** (`useGraph` default `true` → `false`; tool schema, MCP exposure and the manager signature agree). Omitting the argument now means "no graph re-ranking" — a behavior change for callers that relied on the old default, hence a release-candidate first (`next` dist-tag, fleet canary) before stable. Measured 2026-08-17 on three real corpora (self-retrieval, usable samples 120/117/120, summaries off): with the additive graph boost on, the known-item chunk got worse in 46/49/52 samples and better in 3/2/0 (sign test p < 7e-11 per corpus), 106 targets left the top-10 entirely; reproduced on the summaries-on product path (HAL, 20 paired samples: hit@1 10→7, hit@5 18→13). Mechanism: only query-matched/connected entities score, but the per-entity boost saturates the cap quickly, so heavily-linked chunks can outrank the exact chunk even at `vector_similarity` 0. This is a harm-reduced default, not a validated graph improvement: the boost path is unchanged for `useGraph: true` (legacy/experimental re-ranker for back-compat and evaluation; the graph does not generate candidates — for relationship exploration use `openNodes` → `getNeighbors`). Regression lock: `test/search-graph-default.test.mjs`.
 - (v5.0.0–v5.2.0 notes live in the git tags / `docs/UPDATING.md`.)
 

package/docs/UPDATING.md

@@ -108,7 +108,7 @@ path and holder pid (e.g. `.download-<key>.lock`). Verify the holder process
 is genuinely gone or hung (`ps -p <pid>`), then remove the lock file manually;
 the next start becomes a clean download owner.
 
-## v5.3.0-rc.1 (schema v14, unchanged): `hybridSearch` graph re-ranking is opt-in
+## v5.3.0 (schema v14, unchanged): `hybridSearch` graph re-ranking is opt-in
 
 **What changed.** `useGraph` defaults to `false` (was `true`) — in the manager signature, the tool JSON
 schema, the zod schema (`validateToolArgs` fills `false`) and the MCP dispatch (`=== true`). Nothing else
@@ -124,9 +124,11 @@ a validated graph improvement — the graph's role (candidate generation vs. re-
 still open and will be decided on a graph-required query suite. Note that `useGraph: true` does not add
 candidates (it re-orders the vector/FTS pool): for relationship exploration use `openNodes` → `getNeighbors`.
 
-**Fleet rollout.** No migration, no schema change. Published first as a release candidate on the `next`
-dist-tag (omitting an argument changes behavior, so it gets a canary before `latest`): pin one project to
-`rag-memory-epf-mcp@next`, run its normal /start and /sync searches, then promote to stable. A caller that
+**Fleet rollout.** No migration, no schema change. Published first as `5.3.0-rc.1` on the `next`
+dist-tag (omitting an argument changes behavior, so it got a canary before `latest`): the published rc was
+installed fresh and run against a real project database — default call had no `graph_boost` and matched
+explicit `useGraph:false`, the known-item probe returned the right chunk at rank 1, opt-in `true` kept
+`graph_boost`, schema/MCP defaults read `false` — then `5.3.0` was published to `latest`. A caller that
 relied on graph re-ranking by default must now pass `useGraph: true`. Callers that already choose per query
 see no change. Regression lock: `test/search-graph-default.test.mjs`.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "rag-memory-epf-mcp",
-  "version": "5.3.0-rc.1",
+  "version": "5.3.0",
   "engines": {
     "node": ">=24"
   },