npm: main's source drifted from the published registry — 26 packages, and at least one differs in content, not just version

What I found

Comparing every non-private package under npm/packages/ against the registry:

• 29 in sync
• 26 with npm ahead of main — main declared versions that were never what users install
• 0 locally ahead

The version fields are now aligned on main (see the sync commit). But version alignment is not content alignment, and at least one package proves the deeper problem:

@ruvector/rvf-node — published 0.2.3 vs main
  index.js    published sha 6effab0127c3 (9191 bytes)
              main      sha e47cae662a8b (4510 bytes)   DIFFERENT
  index.d.ts  published sha 0c544448aa71
              main      sha 20d78e137226                DIFFERENT
  files       published ['index.js','index.d.ts','README.md','package.json']
              main      ['index.js','index.d.ts','*.node']

The published build is roughly twice the size of what main contains. So main is not merely behind on a version number — it does not contain the code that shipped.

Why it happens

Packages are being published from branches that never merge back. I hit this directly earlier: ruvector@0.2.40 was published from an unmerged feature branch, so main's copy sat at 0.2.39 and was missing the entire metaharness SDK/CLI/MCP surface. Publishing 0.2.41 straight from main would have silently regressed every user of that package — it only got caught because the release commit was diffed against the registry first.

Suggested remedies

1. Publish from main only — release from a merged commit, or require the release PR to merge before the publish step runs.
2. CI drift check — a job that fails when any npm/packages/*/package.json version is behind the registry, or when npm pack output diverges from the published tarball for the same version. Cheap, and would have caught all 26.
3. Reconcile the drifted content — @ruvector/rvf-node needs its published source brought back to main (or a decision that the published build is stale and should be republished from main). The full list of 26 is in the sync commit.
4. Consider a prepublishOnly guard that refuses to publish from a dirty tree or a non-main branch.

Related: the version fields on main were also internally inconsistent — the ruvllm platform packages were pinned at 2.0.1 by their consumer while main declared 2.0.0. That is fixed by the sync.

🤖 Generated with claude-flow

Start with the sync commit and the package manifests under npm/packages/, then compare @ruvector/rvf-node's npm pack output with its published files. Review the release and publishing workflow before choosing among the proposed remedies. Done means the 26-package drift is reconciled and future version or content divergence is detected before publishing.