feat(release): automate mcp/engine releases with release-please

[JSONbored]

Summary

• Adds `release-please-config.json` + `.release-please-manifest.json` (two components: `packages/gittensory-mcp` → `mcp-v`, matching the existing tag convention exactly; `packages/gittensory-engine` → `engine-v`) and `.github/workflows/mcp-release-please.yml`, modeled on metagraphed's `release-please.yml`: scheduled every other day, maintains a Release PR per component from conventional commits, and explicitly dispatches `npm-publish.yml`/`publish-engine.yml` on release (a `GITHUB_TOKEN`-created tag doesn't fire push-triggered workflows — both publish workflows already support `released_by_release_please` from their earlier hardening in fix(mcp): build gittensory-engine before the publish gate + switch to workflow_dispatch #4135/chore(engine): add publish-engine.yml, ready for the npm bootstrap #4148).
• `separate-pull-requests: true`, unlike metagraphed's combined-PR default — these two packages have independent release cadences and separate publish targets, and bundling them fights this repo's small-focused-PR convention.
• `package-lock.json`'s two workspace version fields get release-please's documented JSON-path `extra-files` updater, not a shell `npm install --package-lock-only` call (proven destructive to this monorepo's lockfile earlier this session — see refactor(mcp): depend on the published gittensory-engine, drop the hand-ports #4159's description).
• Retires `changelog:check:mcp` from `test:release:mcp` and the changelog-section check from `mcp:release-candidate`: release-please is now the authority on changelog freshness for its own PRs, and its output format differs from the custom generator's — keeping both active would immediately conflict. `checkChangelog`/`changelogHasVersionSection` stay in `mcp-release-candidate-core.mjs` (still tested, still correct) as an available utility for the manual-override path; only the automated report's call site is removed.
• `scripts/generate-mcp-changelog.mjs` and `mcp-release-watch.yml` are untouched — the watch issue remains the broader-coverage audit signal (release-please only scans each component's own subtree, missing `src/mcp/`/`mcp-compatibility.ts`/`local-branch.ts` changes that the custom classifier catches), and the custom generator stays available as a manual fallback.

Rollout (not done in this PR)

Per the plan: trigger this workflow manually (`workflow_dispatch`, not the cron) once, watch the Release PR(s) it opens, confirm changelog/version-pin correctness by eye before approving the merge — only let the cron run unattended after that first cycle completes cleanly through publish.

Test plan

• `npm run actionlint` — clean
• `npm run typecheck` — clean
• `npm run mcp:release-candidate` — 4 checks pass (tag/tarball/cliSmoke/tokenless), changelog check correctly no longer present
• `npx vitest run test/unit/mcp-release-candidate.test.ts` — 19 tests pass unchanged (tests the reusable core module directly, unaffected by the script's call-site change)
• Full `npm run test:release:mcp` — 11,983 passed, 1 pre-existing flake unrelated to this diff (`github-graphql-cache.test.ts`'s concurrency test, confirmed passing in isolation)
• `release-please-config.json`/`.release-please-manifest.json` validated as well-formed JSON

[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 93.72%. Comparing base (11fc55b) to head (a19ace4).
⚠️ Report is 3 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4162   +/-   ##
=======================================
  Coverage   93.72%   93.72%           
=======================================
  Files         387      387           
  Lines       36309    36309           
  Branches    13300    13300           
=======================================
  Hits        34032    34032           
  Misses       1621     1621           
  Partials      656      656           

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[loopover-orb]

Caution

🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥

🛑 Gittensory review result - fixes required

_{Review updated: 2026-07-08 09:05:20 UTC}

5 files · 1 AI reviewer · 2 blockers · readiness 93/100 · CI failing · blocked

🛑 Suggested Action - Manual Review

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Review summary
This PR wires up release-please for two independently-versioned packages (mcp, engine) via separate-pull-requests: true, and correctly avoids the GITHUB_TOKEN tag-push recursion problem by explicitly workflow_dispatch-ing the existing publish workflows with released_by_release_please=true, which matches those workflows' already-hardened released_by_release_please input and GitHub-release skip logic shown in npm-publish.yml. The package-lock.json version sync via a JSON-path extra-files updater instead of a shell npm install --package-lock-only call is the safer choice given the described lockfile-corruption history. The checkChangelog removal from check-mcp-release-candidate.mjs is scoped narrowly to the automated call site, with the utility itself left intact for the manual-override path per the description. I don't see a reachable correctness defect in the visible diff.

Nits — 7 non-blocking

• scripts/check-mcp-release-candidate.mjs:108-109 drops the changelog check from buildReleaseCandidateReport's input with no accompanying test change — confirm mcp-release-candidate-core.mjs's buildReleaseCandidateReport treats a missing `changelog` key as optional rather than assuming its presence.
• The PR description as provided doesn't surface a 'Closes #NNN'/issue link for this release-infra work — worth confirming there's a maintainer-authorized issue behind it per this repo's contributor-PR convention, since it reads as proactive infrastructure rather than a bug fix.
• release-please-config.json's extra-files jsonpath ($.packages['packages/gittensory-mcp'].version / ...-engine) hard-codes an assumption about package-lock.json's shape; a lockfile regeneration that changes those key paths would silently break the version sync with no test catching it.
• Add or extend a test in mcp-release-candidate-core.mjs's suite asserting buildReleaseCandidateReport still produces a valid report shape without a changelog entry, closing the coverage gap on scripts/check-mcp-release-candidate.mjs.
• State the backing issue number explicitly in the PR description for future maintainers scanning history.
• Diff looks like trivial or whitespace-only churn — Reduce whitespace-only or formatting-only churn and keep the diff focused on substantive changes.
• Code changes lack test evidence — Add focused regression tests or explain why existing coverage is sufficient.

Why this is blocked

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

CI checks failing

• validate
• validate-code

Signal	Result	Evidence
Code review	❌ 2 blockers	1 reviewer
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
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 (no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 52 registered-repo PR(s), 43 merged, 486 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 52 PR(s), 486 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, TypeScript, JavaScript, Ruby, Go, Kotlin, MDX, Shell
• Official Gittensor activity: 52 PR(s), 486 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

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.

_{🟩 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 Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review