Promotion: develop → main (pinned 6660704e — mcp 1.3.3) - #596
Merged
Conversation
… declared ranges stop lying (#595) chore(release): mcp 1.3.3, so the --version fix reaches users and the declared ranges stop lying 1.3.2 IS ON npm AND IS THE VERSION A TAG WOULD REGISTER. The MCP registry publish (`publish-mcp-registry`) only runs on a `v*` tag, and the next tag is now unblocked. Without this bump it would create the registry's first-ever listing pointing at `@beyondnet/evolith-mcp@1.3.2`, whose `--version` starts the MCP server instead of answering: stdin closed it exits 0 printing nothing, stdin open it never returns. That does not break MCP protocol use — clients never invoke the flag — but the listing is the first impression on the one channel where the install step IS the pitch, and asking a tool its version is the first thing anyone does after installing it. #590 fixed it in the repo; only a publish moves it. AND THE DECLARED RANGES WERE WRONG, WHICH IS THE LESS OBVIOUS HALF. `core-path.ts` imports at module top level: import { resolveCorpus, tryResolveCorpus } from '@beyondnet/evolith-infra-providers'; import { findCoreFromSatellite } from '@beyondnet/evolith-core-domain/application/paths/rulesets-location'; while the manifest declared `^1.2.0` for both. Verified against the PUBLISHED tarballs rather than taken on faith: core-domain@1.3.0 exports: RULESETS, describeRulesetsResolutionFailure, entriesLookLikeCorpus, probeRulesetsLocation, probeRulesetsLocationSync, rulesetsCandidatePaths core-domain@1.3.1 exports: ... plus findCoreFromSatellite infra-providers@1.2.0 files matching /corpus/: 0 grep resolveCorpus in dist: 0 infra-providers@1.2.1 files matching /corpus/: 3 `^1.2.0` admits both of the versions that LACK the symbols. It has been working on "npm picks the newest in range", not on the contract: any lockfile pin, offline mirror or `overrides` landing inside `^1.2.0` installs a server that dies at import. Tightened to `^1.3.1` and `^1.2.1` — the versions that actually contain what is imported, both already on the registry. SERVER.JSON, AND THE GUARD DOING ITS JOB ON THE FIRST TRY. Bumping package.json alone reproduced exactly the drift #570 introduced, and the parity assertion added in #574 caught it before anything shipped: package.json=1.3.3 server.json=1.3.2 packages[0]=1.3.2 ::error:: server.json declares 1.3.2 but package.json publishes 1.3.3 -> exit 1 Both server.json fields moved to 1.3.3; the check now exits 0. That is the first bump since the guard existed, and it earned its place immediately. VERIFIED packlist after a build: 799 files, dist/ 216, rulesets/ 574, dist/main.js present VALUE_FLAGS (the --version fix) present in the emitted dist/main.js mcp-server suite: 601 tests / 65 suites green guards 01, 03, 04, 66: exit 0 The build exits 1 in this worktree for an unrelated environment reason (`@nestjs/cache-manager` missing from the linked node_modules); it still emits, and the emitted output is what the packlist above measures. On the runner the build succeeds. CI: 32 SUCCESS, 2 SKIPPED, 0 failing.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
📊 Bilingual Coverage ImpactPR Changes
Repository Coverage
✅ Good: All EN changes have ES counterparts. Generated by GitHub Actions |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pinned to
6660704e. One commit: the mcp 1.3.3 bump.This is the last step before a
v*tag. The order matters and was chosen deliberately:main—publish-npmnow asks the registry before publishing, so a tag stops manufacturing a "Release Pipeline Failed" issue (publish-npm attempts a publish without asking whether the version already exists #569), andupload-assetsfinally declares therelease-gateit reads, so the GitHub Release gets a real tag name instead of"Release "against an empty tag.--versionanswers. The fix landed in fix(mcp,release): --version starts the server instead of answering, and the gate called that a pass #590; only a publish moves it to users, andpublish-mcp-registryruns on the tag.Verified on the branch: packlist 799 files (
dist/216,rulesets/574,dist/main.jspresent),VALUE_FLAGSin the emitted dist, mcp-server 601 tests green.The parity guard from #574 caught the
server.jsondrift on its first ever bump —package.json=1.3.3 server.json=1.3.2→ exit 1 — which is exactly the defect #570 introduced and it was written for.🤖 Generated with Claude Code