npm nsolid-plugin@latest (1.1.0) was published from an unmerged branch; main, tags, manifests and nsolid-pi-plugin are out of sync, and ns-switch-org still pins 1.0.3 #70

Summary

nsolid-plugin@1.1.0 is latest on npm (published 2026-09-16T19:45Z). It was built from 4845cbe feat(cli): skills-only external MCP flow and full uninstall (1.1.0), which exists only on origin/cesar/comunity-plugin-test:

• git branch -r --contains 4845cbe shows only origin/cesar/comunity-plugin-test. No PR has that head branch (gh pr list --head cesar/comunity-plugin-test is empty). The related open items are docs: propose skills-only community plugin publication #67 and Propose skills-only community plugin publication #68, which are docs and proposal only.
• The newest tag is v1.0.3 (02ffc14). There is no v1.1.0 tag.
• main has version 1.0.3 in bundle.json, packages/core/bundle.json, packages/core/package.json, .claude-plugin/plugin.json, .claude-plugin/marketplace.json, .codex-plugin/plugin.json and packages/pi-plugin/package.json. 4845cbe bumps all of them to 1.1.0.
• 4845cbe bumps nsolid-pi-plugin to 1.1.0, but npm nsolid-pi-plugin@latest is still 1.0.3, which depends on nsolid-plugin: "1.0.3" exactly.

Separately, skills/ns-switch-org/SKILL.md:37 hardcodes npx -y nsolid-plugin@1.0.3 switch-org --harness <harness>. It is unchanged in 4845cbe, so the published 1.1.0 tarball ships a switch-org skill that runs the 1.0.3 CLI. The nsolid-skills-plugin repo's copy of the same skill correctly pins nsolid-plugin@1.1.0 … --external-mcp.

Impact

Mixing versions is mostly compatible at the MCP layer, but not entirely:

• Bridge and credentials are compatible. Both 1.0.3 wrappers and the 1.1.0 CLI use mcp-remote 0.1.38 under ~/.agents/nsolid-plugin/runtime/mcp-remote/0.1.38/ and the same ~/.agents/.nodesource-auth.json. There is no CLI-to-wrapper version check anywhere, and none is needed today. A native 1.0.3 plugin with npx nsolid-plugin setup (1.1.0) works. In fact 1.1.0 is currently the only published CLI that can provision the runtime the main-branch wrapper needs (see the companion issue about the repair command).
• Command behavior silently differs from main's docs. The README on main tells users to run unpinned npx -y nsolid-plugin …, which now resolves to 1.1.0 code that main does not contain:
  • uninstall changed from "Remove N|Solid Plugin skills for a harness" (main packages/core/src/cli.ts:59) to "Remove the selected harness's N|Solid skills, MCP entries, native plugin, and marketplace registration" (4845cbe cli.ts:59). A user following README "Manual uninstall / cleanup" now also loses the native plugin and marketplace registration.
  • New --external-mcp mode. Flagless setup/switch-org now refuse (EXTERNAL_MCP_ACTIVE) on a harness configured that way.
  • 1.1.0 treats nsolid-plugin as the "legacy" plugin name and nsolid-skills-plugin as canonical (packages/core/src/harnesses/plugin-name.ts).
  • Code reviewers cannot audit what latest does from main or from any tag.
• ns-switch-org runs a different CLI than the one installed. For users on 1.1.0, the pinned 1.0.3 CLI lacks the EXTERNAL_MCP_ACTIVE guard and the --external-mcp flag. On a Claude, Codex or Antigravity harness set up with setup --external-mcp, 1.1.0 would refuse a flagless switch-org. 1.0.3 instead switches the shared credentials and runs its plugin-owned setup path (credentials only, main packages/core/src/index.ts:211-229). That leaves the direct-HTTP MCP entries, which carry the previous org's expanded service token, pointing at the old org. That is the exact symptom the skill exists to fix. With the main-branch native plugin, the pinned 1.0.3 CLI also cannot provision the bridge runtime.
• Pi. nsolid-pi-plugin@1.0.3 bundles CLI 1.0.3 and its own 1.0.3 skills, which are internally consistent. The only 1.1.0 change to the Pi adapter is additive (installedIds for uninstall detection). Mixing it with a separately run npx nsolid-plugin 1.1.0 is benign. The problem is only that the 1.1.0 bump for the Pi package was committed but never published.

Steps to reproduce

npm view nsolid-plugin dist-tags time --json     # latest: 1.1.0, 2026-09-16
npm view nsolid-pi-plugin dist-tags dependencies  # latest: 1.0.3, nsolid-plugin: 1.0.3
git fetch --all --tags
git tag --sort=-v:refname | head -1              # v1.0.3
git branch -r --contains 4845cbe                 # origin/cesar/comunity-plugin-test only
git diff origin/main 4845cbe --stat              # 41 files, +8743/-357, incl. all version bumps
npm pack nsolid-plugin@1.1.0 && tar xzf nsolid-plugin-1.1.0.tgz
grep -n 'nsolid-plugin@' package/skills/ns-switch-org/SKILL.md
# 37:npx -y nsolid-plugin@1.0.3 switch-org --harness <harness>

Expected

• What npm latest points to is on main and tagged v<version>, the native manifests match it, and the Pi package is released in lockstep, or its hold is intentional and documented.
• Version pins inside skills track the release version automatically.

Actual

npm latest was published from an unmerged branch with no tag. Main, the manifests and the Pi package are still 1.0.3. ns-switch-org pins 1.0.3 both on main and inside the 1.1.0 tarball.

Root cause / evidence

• The wrapper's pin is generated from bundle.version (scripts/plugin-generators.mjs:42,191), so plugin:sync keeps it correct. The ns-switch-org pin is hand-written in SKILL.md. No sync script or test references it (grep -rn ns-switch-org packages/*/test scripts returns nothing). It was written at 1.0.3 in 72ad7a3 (feat: add switch-org command to change NodeSource organizations #58) and never updated.
• The release was run from a feature branch. No step requires the published commit to be on main and tagged.

Suggested fix

1. Decide what latest should be. Either merge 4845cbe's branch (via a PR) and tag v1.1.0 at the published commit, or, if 1.1.0 was meant as a community experiment, publish it under a non-latest dist-tag (for example npm dist-tag add nsolid-plugin@1.0.x latest after cutting a 1.0.x release from main) so unpinned npx nsolid-plugin matches main's docs.
2. Publish nsolid-pi-plugin in lockstep, or revert its bump on the branch.
3. Generate the ns-switch-org command from bundle.version during plugin:sync/skills:sync (or use a placeholder that sync replaces), and add a test asserting every nsolid-plugin@<x.y.z> in skills/** equals bundle.version. Consider documenting --external-mcp usage in the skill, as the nsolid-skills-plugin copy does.
4. Add the "published commit is tagged and on main" and "manifests share one version" checks to the release tooling in Add version-aware CLI and harness update workflow #53.

Related: #53 (version-aware update and release tooling), #67/#68 (skills-only community plugin proposal).

Found while writing the plugin docs page in nodesource/nsdocs#110.