ruflo@3.41.2 reports latest while executing cached @claude-flow/cli@3.33.0: wrapper dependency permits stale runtime

## Summary

The published `ruflo@3.41.2` wrapper permits `@claude-flow/cli: ^3.33.0`. We found a real existing npx installation containing:

| Component | Installed | Public npm latest on 2026-09-12 |
|---|---:|---:|
| ruflo | 3.41.2 | 3.41.2 |
| @claude-flow/cli actually resolved by that wrapper | 3.33.0 | 3.41.2 |

Running that installed wrapper with `--version` prints `ruflo v3.41.2`, even though its implementation package is 3.33.0. The installation's package-lock.json confirms both versions and the wrapper's `^3.33.0` dependency.

This is not a claim that npm violates semver: **3.33.0 satisfies the published range**. The defect is that a current wrapper and its version output can conceal an old runtime missing already-released fixes.

## Verified evidence

Environment: macOS arm64, Node 24.14.1, npm 11.11.0. The affected MCP launch is `npx -y ruflo@latest mcp start`.

Public registry checks (explicit registry used to exclude a local registry-cache explanation):

```sh
npm view ruflo@3.41.2 version dependencies.@claude-flow/cli --registry=https://registry.npmjs.org --json
# { "version": "3.41.2", "dependencies.@claude-flow/cli": "^3.33.0" }

npm view @claude-flow/cli@latest version --registry=https://registry.npmjs.org --json
# "3.41.2"
```

Published metadata: https://registry.npmjs.org/ruflo/3.41.2

The wrapper's `bin/ruflo.js`:
- handles `--version` by reading its own package.json, without reporting the resolved implementation;
- searches for `@claude-flow/cli`;
- delegates MCP execution to that package's `bin/cli.js`.

We read the installed implementation's package.json directly (not the wrapper's version label): **3.33.0**.

This report documents an observed existing installation. We have not reconstructed the precise historical sequence that created its lockfile, and do not claim that every clean install selects 3.33.0.

## User-visible consequence: #3051 remains observable behind a latest wrapper

A live MCP memory upsert accepted tags, but subsequent exact retrieval returned `tags: []` while preserving the value.

The installed 3.33.0 bridge populates its write-through cache with only:

```js
{ id, key, namespace, content: value, embedding: embeddingJson }
```

The cached retrieval path uses `cached.tags || []`.

We independently inspected the **published** CLI 3.41.2 tarball:
https://registry.npmjs.org/@claude-flow/cli/-/cli-3.41.2.tgz

Its `dist/src/memory/memory-bridge.js` includes the #3051 correction: invalidate the cache entry after writing rather than caching an incomplete metadata record. Thus the newer runtime contains the fix, but the current wrapper in our existing installation does not execute it.

No database dump, credentials, private project content, or direct database modifications are included. Some unrelated local source patches are installed; the package dependency declaration, launcher behavior, and newer tag-cache correction were checked against upstream published artifacts.

## Expected behavior

A release advertised as current should resolve an explicitly supported implementation that includes its intended fixes, or clearly disclose an older implementation. Wrapper-only version output must not be treated as runtime freshness proof.

## Proposed upstream remedy

1. Define the wrapper/runtime release contract. If they ship in lockstep, publish an exact matching runtime dependency. Otherwise raise the minimum to the runtime actually required/tested for that wrapper release.
2. Report wrapper version **and resolved runtime version** in diagnostics and machine-readable version output; do not require heavy runtime/model initialization just to inspect package metadata.
3. Make update/doctor checks examine the resolved runtime, not only the wrapper.
4. Add a published-artifact CI matrix covering both clean installation and an existing installation/cache with an older satisfying CLI dependency. Verify the post-upgrade resolved runtime and execute a bounded MCP behavior smoke test, including the #3051 tag round-trip.
5. Fail release checks when the intended runtime contract is violated. Do not silently kill existing MCP sessions during upgrades; distinguish installed bytes from live-process activation.

Directly launching the implementation package is a possible consumer mitigation, but should not be necessary to discover that a standard latest wrapper is using an older implementation.

## Related, but distinct

- #3051: tag handling/cache symptom already corrected in newer implementation.
- #411: older generated launcher/stale npx selection issue (closed). This report concerns the **published npm wrapper's dependency range and version visibility**, not that generated script.
- #2614: prior wrapper/runtime publication verification; checking both package versions and cached upgrade paths would strengthen that release proof.

Start by inspecting the published ruflo@3.41.2 metadata and bin/ruflo.js, then reproduce npx -y ruflo@latest mcp start with the npm registry checks shown. Compare the resolved @claude-flow/cli version and dist/src/memory/memory-bridge.js behavior against 3.41.2. Done means the release contract, runtime version reporting, and clean/cache installation checks are defined and verified.

Written by the indexing model from the issue text.