Candidate MCP/CLI artifact emitted into generated terminal MCP client
configurations.
This must name a version that is actually published to the public registry:
the generated .mcp.json / claude_desktop_config.json run
npx -y --package <pin> honua-mcp-proxy, so a pin that only exists in this
repository's release lineage produces an uninstallable configuration on a
clean machine. Repository release tags and mcp/CHANGELOG.md entries are
not evidence of publication - a tagged version whose npm publish failed
still appears there.
The pin previously read 0.1.7-beta.0, which the registry has never served.
@honua/sdk-js@0.1.7-beta.0 was published from a recovery branch rather than
from the sealed tag commit, so the coordinated 0.1.7 cut of @honua/mcp-server
(and create-honua-app) never happened at all. It was then held at
0.1.4-beta.0, the highest version the registry actually served, because
advancing it requires a real coordinated publish rather than an edit here.
Publication is necessary but not sufficient, and holding the pin back is what
exposed the second half of the rule (#1529). @honua/mcp-server
peer-depends on @honua/sdk-js, so the two are a pair, and npm's default
resolver rejects a pair whose peer range does not admit the SDK installed
beside it. A caret range over a prerelease admits exactly one
major.minor.patch tuple -- ^0.1.4-beta.0 does not accept
0.1.9-beta.0, and no widening of it would, because a prerelease satisfies a
range only when some comparator carries a prerelease on the same tuple.
Held at 0.1.4-beta.0 beside an 0.1.9-beta.0 SDK, the pinned pair therefore
failed npm install outright with ERESOLVE unless the customer passed
--legacy-peer-deps.
The pin consequently has to move in lockstep with this package's own version,
one coordinated cut at a time. 0.1.9-beta.0 is that cut: both halves were
published on 2026-08-29 and co-install with no flags.
Advancing it is npm run sync:mcp-pin, run after the coordinated
@honua/mcp-server publish, which rewrites this version and the integrity
below together from the registry. It is deliberately not a release-please
extra-files bump: release-please would advance the version at release-PR
time, before either half is published -- reintroducing exactly the
unpublished-pin failure described above -- and it cannot compute the tarball
integrity that has to move with it. Between a release bump and that publish
the pin legitimately lags this package's version; verify:client-pair is
what refuses to ship while it does.
test/local-install.test.ts proves the pin belongs to the repository's own
release lineage and never runs ahead of mcp/package.json;
npm run verify:mcp-pin additionally proves the pinned pair is co-installable
offline, and npm run verify:client-pair proves it by really installing both
halves with default npm resolution. The registry itself is only queried by
the opt-in HONUA_MCP_PIN_LIVE_ENABLED=true npm run verify:mcp-pin:live lane,
never in PR CI.
Candidate MCP/CLI artifact emitted into generated terminal MCP client configurations.
This must name a version that is actually published to the public registry: the generated
.mcp.json/claude_desktop_config.jsonrunnpx -y --package <pin> honua-mcp-proxy, so a pin that only exists in this repository's release lineage produces an uninstallable configuration on a clean machine. Repository release tags andmcp/CHANGELOG.mdentries are not evidence of publication - a tagged version whose npm publish failed still appears there.The pin previously read
0.1.7-beta.0, which the registry has never served.@honua/sdk-js@0.1.7-beta.0was published from a recovery branch rather than from the sealed tag commit, so the coordinated 0.1.7 cut of@honua/mcp-server(andcreate-honua-app) never happened at all. It was then held at0.1.4-beta.0, the highest version the registry actually served, because advancing it requires a real coordinated publish rather than an edit here.Publication is necessary but not sufficient, and holding the pin back is what exposed the second half of the rule (#1529).
@honua/mcp-serverpeer-depends on@honua/sdk-js, so the two are a pair, and npm's default resolver rejects a pair whose peer range does not admit the SDK installed beside it. A caret range over a prerelease admits exactly onemajor.minor.patchtuple --^0.1.4-beta.0does not accept0.1.9-beta.0, and no widening of it would, because a prerelease satisfies a range only when some comparator carries a prerelease on the same tuple. Held at0.1.4-beta.0beside an0.1.9-beta.0SDK, the pinned pair therefore failednpm installoutright with ERESOLVE unless the customer passed--legacy-peer-deps.The pin consequently has to move in lockstep with this package's own version, one coordinated cut at a time.
0.1.9-beta.0is that cut: both halves were published on 2026-08-29 and co-install with no flags.Advancing it is
npm run sync:mcp-pin, run after the coordinated@honua/mcp-serverpublish, which rewrites this version and the integrity below together from the registry. It is deliberately not a release-pleaseextra-filesbump: release-please would advance the version at release-PR time, before either half is published -- reintroducing exactly the unpublished-pin failure described above -- and it cannot compute the tarball integrity that has to move with it. Between a release bump and that publish the pin legitimately lags this package's version;verify:client-pairis what refuses to ship while it does.test/local-install.test.tsproves the pin belongs to the repository's own release lineage and never runs ahead ofmcp/package.json;npm run verify:mcp-pinadditionally proves the pinned pair is co-installable offline, andnpm run verify:client-pairproves it by really installing both halves with default npm resolution. The registry itself is only queried by the opt-inHONUA_MCP_PIN_LIVE_ENABLED=true npm run verify:mcp-pin:livelane, never in PR CI.