Problem
scripts/check-server-manifest.ts requires server.json's version and packages[0].version to equal @loopover/mcp's package.json version, and it runs in test:ci as server-manifest:check.
release-please bumps packages/loopover-mcp/package.json but never touches server.json. So every release PR for the engine-and-dependents group fails CI on:
server.json has 2 problem(s) (#9526):
version: must equal @loopover/mcp's 3.17.0 (release automation owns it), got 3.15.2
packages[0].version: must equal @loopover/mcp's 3.17.0, got 3.15.2
Confirmed live on #9780, and fixed there by hand — which is the point: it needs re-fixing by hand on every release, and a machine-generated branch is exactly where a manual step gets forgotten.
Why the existing sync pattern does not apply
scripts/sync-release-manifest.ts (+ its --check) is the repo's idiom for this shape, but it does not help here: release PRs are generated by the bot, so a script a human has to run never fires on the branch that needs it.
The fix
release-please should write server.json itself when it creates the release PR, via extra-files on the packages/loopover-mcp entry in release-please-config.json:
"extra-files": [
{ "type": "json", "path": "server.json", "jsonpath": "$.version" },
{ "type": "json", "path": "server.json", "jsonpath": "$.packages[0].version" }
]The open question is path resolution. extra-files paths are documented as relative to the package's own directory, which would resolve to packages/loopover-mcp/server.json rather than the repo-root server.json. This needs to be confirmed against the release-please version actually in use (and the root-relative escape, if there is one) before landing — a wrong guess here silently breaks releases rather than failing loudly, which is why #9780 was fixed by hand instead.
Acceptance
A release PR for @loopover/mcp arrives with server.json already carrying the new version, server-manifest:check passes on it unaided, and no human step is required between release-please opening the PR and CI going green. Verify by watching the next generated release PR, not by running anything locally.
Problem
scripts/check-server-manifest.tsrequiresserver.json'sversionandpackages[0].versionto equal@loopover/mcp'spackage.jsonversion, and it runs intest:ciasserver-manifest:check.release-please bumps
packages/loopover-mcp/package.jsonbut never touchesserver.json. So every release PR for theengine-and-dependentsgroup fails CI on:Confirmed live on #9780, and fixed there by hand — which is the point: it needs re-fixing by hand on every release, and a machine-generated branch is exactly where a manual step gets forgotten.
Why the existing sync pattern does not apply
scripts/sync-release-manifest.ts(+ its--check) is the repo's idiom for this shape, but it does not help here: release PRs are generated by the bot, so a script a human has to run never fires on the branch that needs it.The fix
release-please should write
server.jsonitself when it creates the release PR, viaextra-fileson thepackages/loopover-mcpentry inrelease-please-config.json:The open question is path resolution.
extra-filespaths are documented as relative to the package's own directory, which would resolve topackages/loopover-mcp/server.jsonrather than the repo-rootserver.json. This needs to be confirmed against the release-please version actually in use (and the root-relative escape, if there is one) before landing — a wrong guess here silently breaks releases rather than failing loudly, which is why #9780 was fixed by hand instead.Acceptance
A release PR for
@loopover/mcparrives withserver.jsonalready carrying the new version,server-manifest:checkpasses on it unaided, and no human step is required between release-please opening the PR and CI going green. Verify by watching the next generated release PR, not by running anything locally.