ruflo

Upgrade to v3.10.33 or later, where --version/-V exits before loading the ONNX embedding model:

npx -y ruflo@3.10.33 --version
npx -y @claude-flow/cli@3.10.33 --version

The hang occurred on a cold cache because CLI initialization downloaded the 23 MB all-MiniLM-L6-v2 ONNX model from HuggingFace before printing the version. In v3.10.33, both ruflo and @claude-flow/cli read the version from package.json and exit immediately, reducing startup from over 60 seconds to about 33 ms.

If you must use an older release, prewarm the model cache once with a longer timeout:

timeout 180 npx -y ruflo@alpha --version

After the download completes, later invocations use the disk cache and start quickly. The broader lazy-loading/cli-core split remains tracked under ADR-100/#1760.

Install the declared npm dependencies before running verification. From the repository root, run:

npm ci && npm run build

Then invoke the verifier again, for example:

node plugins/ruflo-core/scripts/witness/verify.mjs --manifest verification/linux/manifest.md.json

For a local non-clean checkout, npm install from the repo root can also install the missing @noble/ed25519 dependency. Add npm ci && npm run build to the source-only verification runner's pre-flight step. Do not treat exit code 0 as success when the output says the Ed25519 check was skipped; successful verification must print the signature validation result and pass/drift/regressed/missing counts.

Upgrade to ruflo **3.10.33 or later** (npm install -g ruflo@3.10.33). In affected versions such as ruflo 3.10.13 / @claude-flow/cli 3.10.22, memory_search_unified without a namespace filter used a hardcoded list of six namespaces, so entries in namespaces such as knowledge-graph, causal-edges, brain-system, or custom namespaces were silently omitted. The fix uses dynamic namespace enumeration by default and adds: namespaces: string[], the CSV env var CLAUDE_FLOW_MEMORY_SEARCH_NAMESPACES, and namespaceSource in the response. Resolution priority is: explicit namespace → explicit namespaces → env override → dynamic enumeration → legacy fallback. On older versions, pass the target namespace explicitly, for example memory_search_unified({ query: "needle", namespace: "brain-system" }), or upgrade. Do not rely on edits under dist/; npm upgrades overwrite them.

Upgrade Ruflo to **v3.10.33 or newer**, which redirects third-party embedding/model-loading progress logs from stdout to stderr, keeping stdout reserved for MCP JSON-RPC frames.

Update your Codex MCP configuration to pin the fixed version:

[mcp_servers.ruflo]
command = "npx"
args = ["-y", "ruflo@3.10.33", "mcp", "start"]
enabled = true

Then restart Codex or the MCP server. The affected logs in v3.10.30 included:

Disk cache hit: all-MiniLM-L6-v2
🚀 Initializing 19 worker threads...
Loading model: all-MiniLM-L6-v2 (23MB)
  Downloading: ...

These caused strict MCP clients such as Codex to fail parsing the initialize response, so the mcp__ruflo... tools did not appear. Increasing the startup timeout alone does not fix older versions because the stdout stream is already corrupted with non-JSON text. After upgrading, increase the client timeout only if the first model-download/initialization run is still slow.

Upgrade ruflo-console to **0.40.5 or later**; the fix is in PR #3934 (merge 767f7a689). Version 0.40.3 incorrectly treated every non-zero CLI exit as a failure. Verdict commands use non-zero exits to indicate findings—for example, security defend/security scan exit 1 on threats, channel-scan/scan-plan exit 2 when a gate fires, and metaharness alert scripts exit 1 for an alert but exit 2 for an actual failure. The fixed runner parses the complete JSON response and accepts a declared non-zero exit as a valid verdict when the JSON confirms findings and no separate failure is reported. It also uses a shared failureReason helper that selects the actual [ERROR] line instead of the first stderr line, which may be a [WARN] notice. Restart the console/MCP service after upgrading. If upgrading is delayed, inspect and parse the command's stdout JSON directly and search stderr for [ERROR] rather than relying on the console's ok:false status or first stderr line.