ruflo v3.38.21

v3.38.21

v3.38.21 — MCP HTTP bridge memory-persistence fix

Fixed 2
  • Fixed entries stored via the bridge being unreadable after a bridge restart by correcting initializeMemoryDatabase() to seed the ControllerRegistry singleton with the dedicated agentdb-memory.db path instead of the memory.db path
  • Relaxed agentic-flow-agent.test.ts assertion on result.duration from strictly greater than 0 to greater than or equal to 0 to prevent flaking under coarse CI clock resolution

From ruflo

Fixed
  • #3155ruflo mcp start -t http: entries stored via the bridge were unreadable after a bridge restart (found:false, memory_list empty), even though .swarm/memory.db held them and the CLI read them fine. Root cause: initializeMemoryDatabase() seeded the process-wide ControllerRegistry singleton with the sql.js-facing memory.db path instead of the dedicated agentdb-memory.db path. Fixed in #3156.
  • #3059 (CI) — agentic-flow-agent.test.ts asserted result.duration strictly > 0; under coarse CI clock resolution a ~1ms task's duration could legitimately read 0, flaking the test-ratchet gate on main. Relaxed to >= 0.
Known, separately-tracked gap (not in this release)

@claude-flow/mcp is pinned to 3.0.0-alpha.10 in root/CLI package.json (bumped in the 3.38.20 release commit) but that exact version was never published standalone to npm — only alpha.9 exists on the registry. This breaks a fresh npm ci inside the ruvnet/ruflo monorepo itself (confirmed failing on CI). It does not affect end users installing ruflo/@claude-flow/cli from npm, since @claude-flow/mcp ships bundled inside those tarballs. Filed for follow-up.

View original

Upgraded? How did it go?

Discussion