chore(release): mcp 1.3.3, so the --version fix reaches users and the declared ranges stop lying

[beyondnetPeru]

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.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[github-actions]

📊 Bilingual Coverage Impact

PR Changes

• Paired EN/ES files modified: 3
• New EN files needing ES translation: 0

Repository Coverage

Metric	Value
Total EN files	532
Total ES files	502
Paired files	0
Coverage	0%

✅ Good: All EN changes have ES counterparts.

---

Generated by GitHub Actions