ci(release): let release-please bump server.json's version itself

[JSONbored]

Closes #9874. Unblocks #9780 (and every release PR after it).

Problem

check-server-manifest requires server.json's version and packages[0].version to equal @loopover/mcp's, and it runs in test:ci. release-please bumps the package but never touches server.json, so every generated release PR fails CI:

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

A manual fix provably does not hold

I fixed #9780 by hand first. release-please then regenerated the branch and discarded the commit — server.json is back to 3.15.2 there now. That is the whole reason this belongs in the config and not in a script a human runs: the branch that needs the fix is the one the bot rewrites.

It also rules out the repo's existing sync-release-manifest.ts idiom, which is a fine pattern but only ever runs when a human runs it.

The leading slash is load-bearing

release-please joins an extra-file path to the package directory unless it starts with / — strategies/base.js:

addPath(file) {
  if (!this.path || this.path === ROOT_PROJECT_PATH || file.startsWith('/')) {
    file = file.replace(/^\/+/, '');   // repo-root relative
  } else {
    file = `${this.path.replace(/\/+$/, '')}/${file}`;  // package relative
  }

So a plain "server.json" would have resolved to packages/loopover-mcp/server.json and silently updated nothing — the failure mode being fixed, but harder to spot. I flagged this as the open question on #9874 rather than guessing; this PR lands it only because it is now verified.

Verified, not assumed

Against the installed release-please 17.10.4, exercising its real addPath logic and its real GenericJson updater on this repo's actual server.json:

root-relative  '/server.json' -> server.json
pkg-relative   'server.json'  -> packages/loopover-mcp/server.json
after update -> version: 9.9.9 | packages[0].version: 9.9.9

Both jsonpaths resolve and rewrite; jsonpath-plus handles $.packages[0].version, and both targets are strings (the updater skips non-strings with a warning).

Effect

Once this is on main, release-please regenerates #9780 with server.json already carrying the new version, and server-manifest:check passes unaided. No human step between the bot opening a release PR and CI going green.

Config-only, 5 lines. Nothing to test locally beyond the verification above — the real confirmation is the next generated release PR, which is what #9874's acceptance asks for.

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-29 18:35:50 UTC}

1 file · 1 AI reviewer · no blockers · readiness 95/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This is a minimal, well-targeted config-only fix: it adds `extra-files` entries to release-please-config.json so release-please itself writes server.json's version and packages[0].version fields during the release-PR generation step, instead of relying on a manual sync script that gets discarded when the bot regenerates the branch. The PR body demonstrates the author verified the leading-slash behavior against the installed release-please version's actual addPath logic, which is the one subtle correctness point (a plain "server.json" path would silently resolve to the wrong location). The diff is small, config-only, closes a linked issue (#9874), and CI passed.

Nits — 5 non-blocking

• The PR relies on two separate extra-files entries pointing at the same server.json file for the top-level version and packages[0].version fields — worth a one-line comment in the config noting both must stay in sync with any future server.json schema changes, since JSON config files can't hold comments themselves so this would need to live in a README/CONTRIBUTING note instead.
• No test or CI step is added to assert server.json's version tracking actually gets updated by release-please on the next real release PR, so the fix is verified via out-of-band manual testing (per the PR description) rather than automated regression coverage in this repo.
• Consider linking to or referencing the release-please version pin (17.10.4) in a comment near the config or in CONTRIBUTING docs, since the leading-slash behavior described in the PR body is undocumented upstream and could change in a future release-please bump.
• If check-server-manifest (test:ci) can run against the generated release PR branch, add a lightweight assertion/test that catches regressions if release-please's extra-files JSONPath behavior changes in a future dependency bump.
• PR author also opened the linked issue — Link an issue that was opened by a different contributor, or provide a rationale for why this self-authored issue represents genuine discovery work.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#9874, #9780
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (2 linked issues).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 14 registered-repo PR(s), 13 merged, 334 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 14 PR(s), 334 issue(s).
Improvement	ℹ️ Insufficient signal	risk: clean · value: insufficient-signal · LLM: moderate

Linked issue satisfaction

Addressed
The PR adds the leading-slash `extra-files` entries to release-please-config.json for the loopover-mcp package, directly implementing the fix proposed in the issue and explicitly resolving the flagged open question about path resolution with a verified test against the installed release-please version.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is registered but has no active allocation in the current snapshot.
• Public profile languages: not available
• Official Gittensor activity: 14 PR(s), 334 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Then work through the remaining 2 steps in the Signals table above.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.87%. Comparing base (8e2d51d) to head (4e77bae).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9880      +/-   ##
==========================================
- Coverage   91.75%   90.87%   -0.88%     
==========================================
  Files         919      919              
  Lines      112987   112987              
  Branches    27193    27193              
==========================================
- Hits       103667   102676     -991     
- Misses       8034     9223    +1189     
+ Partials     1286     1088     -198     

Flag	Coverage Δ
backend	94.12% <ø> (-1.57%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 3 files with indirect coverage changes

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.