v3.38.7 — HNSW status honesty fix, cache-fingerprint follow-up
- Renamed bridgeSearchHNSW, bridgeAddToHNSW, and bridgeGetHNSWStatus to bridgeSearchBruteForceCosine, bridgeAddEmbedding, and bridgeGetVectorSearchStatus to reflect their actual implementations
- Vector search status functions now expose an algorithm field indicating 'hnsw' or 'brute-force-cosine'
- MCP memory tool responses now report the actual search algorithm in the backend field instead of the hardcoded value 'sql.js + HNSW'
- consolidate()'s graph-state.json write now includes the contentFingerprint stamp so that init()'s cache-hit gate correctly detects cache matches across consolidate/restart boundaries
- getHNSWStatus() and bridgeGetHNSWStatus() now accurately report whether HNSW acceleration is in use instead of unconditionally reporting available: true
Fixes
#2920 (follow-up) — consolidate()'s graph write was missing the contentFingerprint stamp that init()'s cache-hit gate checks. The v3.38.6 fix made consolidate() (the session-end path) rebuild graph-state.json unconditionally, but that write never included contentFingerprint — only init()'s own write did. So every init() immediately following a consolidate() saw nodeCount match but contentFingerprint undefined !== <real hash>, missed the cache, and did a full rebuild even with zero content changes. Fail direction was safe (extra rebuilds, never stale data), so it didn't block v3.38.6 — but it meant the 60s graph cache never actually fired across a consolidate/restart boundary.
#2922 — the memory bridge's brute-force cosine search was misreported as HNSW-accelerated. getHNSWStatus() returned available: true whenever the AgentDB v3 bridge was loaded, regardless of whether an HNSW index was actually in the request path — the bridge's default search is a full-table SELECT + brute-force cosine similarity loop that never touches @ruvector/core. Same issue in bridgeGetHNSWStatus (unconditional available: true) and in three misleadingly-named functions that do no HNSW work: bridgeSearchHNSW, bridgeAddToHNSW, bridgeGetHNSWStatus — renamed to bridgeSearchBruteForceCosine, bridgeAddEmbedding, bridgeGetVectorSearchStatus. Both status functions now expose an algorithm: 'hnsw' | 'brute-force-cosine' field. The memory_stats MCP tool response (and 6 others) previously hardcoded backend: 'sql.js + HNSW' regardless of which path ran — now reports the real algorithm.
Note: this changes the values returned in the backend field of 7 MCP memory tool responses (memory_store, memory_retrieve, memory_search, etc.) from the previous hardcoded 'sql.js + HNSW' to an accurate value — an observable but non-breaking change (the field's type and presence are unchanged).
Actually wiring AgentDBBackend's real HNSW implementation into the bridge's default search path is a larger architectural question, tracked as the remaining open scope on #2922.