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
- Publish from main only — release from a merged commit, or require the release PR to merge before the publish step runs.
- 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.
- 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.
- 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
What I found
Comparing every non-private package under
npm/packages/against the registry: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:
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.40was 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
npm/packages/*/package.jsonversion is behind the registry, or whennpm packoutput diverges from the published tarball for the same version. Cheap, and would have caught all 26.@ruvector/rvf-nodeneeds 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.prepublishOnlyguard 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.1by their consumer while main declared2.0.0. That is fixed by the sync.🤖 Generated with claude-flow